Världen såg den första prototypen av objektlagring 1996. Om 10 år kommer Amazon Web Services att lansera Amazon S3, och världen kommer systematiskt att börja bli galen med ett platt adressutrymme. Tack vare arbetet med metadata och dess förmåga att skala utan att sjunka under belastning blev objektlagring snabbt standarden för de flesta molndatalagringstjänster, och inte bara det. En annan viktig funktion är att den är väl lämpad för att lagra arkiv och liknande sällan använda filer. Alla inblandade i datalagring gladde sig och bar den nya tekniken i famnen.
Men folks rykten var fulla av rykten om att objektlagring bara handlar om stora moln, och om du inte behöver lösningar från de förbannade kapitalisterna kommer det att bli väldigt svårt att göra din egen. Mycket har redan skrivits om att distribuera ditt eget moln, men det finns inte tillräckligt med information om att skapa så kallade S3-kompatibla lösningar.
Därför kommer vi idag att ta reda på vilka alternativ som finns "Så att det är som vuxna, inte CEPH och en större fil", kommer vi att distribuera en av dem, och vi kommer att kontrollera att allt fungerar med Veeam Backup & Replication. Det hävdar att det stöder arbete med S3-kompatibla lagringar, och vi kommer att testa detta påstående.
Hur är det med andra?
Jag föreslår att du börjar med en liten översikt över marknaden och alternativ för objektförvaring. Den allmänt erkända ledaren och standarden är Amazon S3. De två närmaste förföljarna är Microsoft Azure Blob Storage och IBM Cloud Object Storage.
Är det allt? Finns det verkligen inga andra konkurrenter? Naturligtvis finns det konkurrenter, men vissa går sin egen väg, som Google Cloud eller Oracle Cloud Object Storage, med ofullständigt stöd för S3 API. Vissa använder äldre versioner av API:t, som Baidu Cloud. Och vissa, som Hitachi Cloud, kräver speciell logik, vilket säkert kommer att orsaka sina egna svårigheter. Alla jämförs i alla fall med Amazon, som får anses vara branschstandard.
Men i lösningar på plats finns det mycket fler valmöjligheter, så låt oss skissera de kriterier som är viktiga för oss. I princip räcker bara två: stöd för S3 API och användning av v4-signering. Handen på hjärtat är vi som framtida uppdragsgivare bara intresserade av gränssnitt för interaktion och vi är inte så intresserade av själva förrådets interna kök.
Många lösningar passar dessa enkla förhållanden. Till exempel klassiska företags tungviktare:
- DellEMC ECS
- NetApp S3 StorageGrid
- Nutanix hinkar
- Pure Storage FlashBlade och StorReduce
- Huawei FusionStorage
Det finns en nisch av rena mjukvarulösningar som fungerar direkt:
- Red Hat Ceph
- SUSE Enterprise Storage
- Cloudian
Och även de som gillar att noggrant fila efter monteringen blev inte förolämpade:
- CEPH i sin renaste form
- Minio (Linux-version, eftersom det finns många frågor om Windows-versionen)
Listan är långt ifrån komplett, den kan diskuteras i kommentarerna. Glöm bara inte att kontrollera systemets prestanda utöver API-kompatibilitet innan implementering. Det sista du vill är att förlora terabyte data på grund av fastnade frågor. Så var inte blyg med belastningstester. I allmänhet har all programvara för vuxna som fungerar med stora mängder data åtminstone kompatibilitetsrapporter. I fall att Veeam finns på ömsesidig testning, vilket gör att vi med säkerhet kan deklarera att våra produkter är fullständiga kompatibla med specifik utrustning. Detta är redan ett tvåvägsarbete, inte alltid snabbt, men vi expanderar hela tiden testade lösningar.
Montering av vår monter
Jag skulle vilja prata lite om att välja ett testämne.
Först ville jag hitta ett alternativ som skulle fungera direkt ur lådan. Tja, eller åtminstone med största sannolikhet att det kommer att fungera utan att behöva göra onödiga rörelser. Att dansa med en tamburin och pyssla med konsolen på natten är väldigt spännande, men ibland vill man att det ska fungera direkt. Och den övergripande tillförlitligheten för sådana lösningar är vanligtvis högre. Och ja, äventyrsandan har försvunnit i oss, vi slutade klättra in i våra älskade kvinnors fönster, etc. (c).
För det andra, om jag ska vara ärlig, uppstår behovet av att arbeta med objektlagring i ganska stora företag, så detta är just fallet när man tittar mot lösningar på företagsnivå inte bara inte är skamligt, utan till och med uppmuntras. Jag känner i alla fall ännu inte till några exempel på att någon har fått sparken för att ha köpt sådana lösningar.
Baserat på allt ovan föll mitt val på Dell EMC ECS Community Edition. Detta är ett mycket intressant projekt, och jag anser att det är nödvändigt att berätta om det.
Det första du tänker på när du ser tillägget Community edition - att detta bara är en kopia av en fullfjädrad ECS med vissa restriktioner som tas bort genom att köpa en licens. Så nej!
Kom ihåg:
!!!Community Edition är ett separat projekt skapat för testning och utan teknisk support från Dell!!
Och det kan inte förvandlas till ett fullfjädrat ECS, även om du verkligen vill.
Låt oss ta reda på det
Många tror att Dell EMC ECS nästan är den bästa lösningen om du har ett behov av objektlagring. Alla projekt under ECS varumärke, inklusive kommersiella och företag, är baserade på . En sorts goodwill-gest från Dell. Och förutom mjukvaran som körs på deras märkesvaror, finns det en öppen källkodsversion som kan distribueras i molnet, på en virtuell maskin, i en behållare eller på någon av din egen hårdvara. Framöver finns det till och med en OVA-version som vi kommer att använda.
Själva DELL ECS Community Edition är en miniversion av fullfjädrad programvara som körs på märkesvaror Dell EMC ECS-servrar.
Jag identifierade fyra huvudsakliga skillnader:
- Inget krypteringsstöd. Det är synd, men inte kritiskt.
- Tyglager saknas. Den här saken är ansvarig för att bygga kluster, resurshantering, uppdateringar, övervakning och lagring av Docker-bilder. Det är här det redan är väldigt stötande, men Dell kan också förstås.
- Den mest äckliga konsekvensen av föregående punkt: storleken på noden kan inte utökas efter att installationen är klar.
- Ingen teknisk support. Detta är en produkt för testning, som inte är förbjuden att användas i små installationer, men jag skulle personligen inte våga ladda upp petabyte med viktig data dit. Men tekniskt sett kan ingen hindra dig från att göra detta.
Vad finns i den stora versionen?
Låt oss galoppera över Europa och gå igenom järnklädda lösningar för att få en mer fullständig förståelse av ekosystemet.
Jag kommer inte på något sätt att bekräfta eller motbevisa påståendet att DELL ECS är den bästa objektlagringen på plats, men om du har något att säga om detta ämne, kommer jag gärna att läsa det i kommentarerna. Åtminstone enligt versionen Dell EMC är med säkerhet bland de fem bästa OBS-marknadsledarna. Även om molnbaserade lösningar inte beaktas där, är detta ett separat samtal.
Ur teknisk synvinkel är ECS en objektlagring som ger tillgång till data med hjälp av molnlagringsprotokoll. Stöder AWS S3 och OpenStack Swift. För filaktiverade buckets stöder ECS NFSv3 för fil-för-fil-export.
Processen att registrera information är ganska ovanlig, särskilt efter klassiska blocklagringssystem.
- När ny data kommer in skapas ett nytt objekt som har ett namn, själva datan och metadata.
- Objekt är uppdelade i 128 MB bitar, och varje bit skrivs till tre noder samtidigt.
- Indexfilen uppdateras, där identifierare och lagringsplatser registreras.
- Loggfilen (loggposten) uppdateras och skrivs även till tre noder.
- Ett meddelande om lyckad inspelning skickas till klienten
Alla tre kopiorna av data skrivs parallellt. Skrivningen anses vara framgångsrik endast om alla tre kopiorna har skrivits framgångsrikt.
Det är lättare att läsa:
- Kunden begär data.
- Indexet letar efter var data lagras.
- Data läses från en nod och skickas till klienten.
Det finns en hel del servrar själva, så låt oss titta på den minsta Dell EMC ECS EX300. Den börjar från 60 TB, med möjligheten att växa upp till 1,5 PB. Och dess äldre bror, Dell EMC ECS EX3000, låter dig lagra så mycket som 8,6 PB per rack.
Distribuera
Tekniskt sett kan Dell ECS CE distribueras så stort som du vill. Jag hittade i alla fall inga uttryckliga begränsningar. Det är dock bekvämt att göra all skalning genom att klona den allra första noden, för vilken vi behöver:
- 8 vCPU:er
- 64GB RAM
- 16 GB för OS
- 1TB direktlagring
- Senaste utgåvan av CentOS minimal
Detta är ett alternativ när du vill installera allt själv från första början. Det här alternativet är inte relevant för oss, eftersom... Jag kommer att använda OVA-avbildningen för distribution.
Men i alla fall är kraven väldigt onda även för en nod, och om du strikt följer lagens bokstav behöver du fyra sådana noder.
ECS CE-utvecklare lever dock i den verkliga världen, och installationen är framgångsrik även med en nod, och minimikraven är:
- 4 vCPU:er
- 16 GB RAM
- 16 GB för OS
- 104 GB lagring i sig
Det här är resurserna som behövs för att distribuera OVA-avbildningen. Redan mycket mer humant och realistiskt.
Själva installationsnoden kan erhållas från tjänstemannen . Det finns också detaljerad dokumentation om allt-i-ett-distribution, men du kan också läsa på den officiella . Därför kommer vi inte att uppehålla oss i detalj vid utvecklingen av OVA, det finns inga knep där. Det viktigaste är att innan du startar det, glöm inte att antingen expandera disken till önskad volym eller bifoga de nödvändiga.
Vi startar maskinen, öppnar konsolen och använder de bästa standarduppgifterna:
- inloggning: admin
- lösenord: ChangeMe
Sedan kör vi sudo nmtui och konfigurerar nätverksgränssnittet - IP/mask, DNS och gate. Med tanke på att CentOS minimal inte har nätverktyg kontrollerar vi inställningarna via ip-adr.
Och eftersom bara de modiga erövrar haven gör vi en yum-uppdatering, varefter vi startar om. Det är faktiskt ganska säkert eftersom... all distribution sker genom playbooks, och alla viktiga docker-paket är låsta till den aktuella versionen.
Nu är det dags att redigera installationsskriptet. Inga snygga fönster eller pseudo-gränssnitt för dig - allt görs genom din favorittextredigerare. Tekniskt sett finns det två sätt: du kan köra varje kommando manuellt eller omedelbart starta videoploy-konfiguratorn. Det kommer helt enkelt att öppna konfigurationen i vim, och när det avslutas kommer det att börja kontrollera det. Men det är inte intressant att medvetet förenkla ditt liv, så låt oss köra två kommandon till. Även om detta inte är meningsfullt, jag varnade dig =)
Så låt oss göra vim ECS-CommunityEdition/deploy.xml och göra de optimala minimala ändringarna så att ECS är igång. Listan över parametrar kan förkortas, men jag gjorde det så här:
- licensed_accepted: true Du behöver inte ändra det, då när du distribuerar kommer du uttryckligen att bli ombedd att acceptera det och kommer att visas en trevlig fras. Kanske är detta till och med ett påskägg.
- Avkommentera raderna autonames: och anpassad: Ange minst ett önskat namn för noden - värdnamnet kommer att ersättas med det under installationsprocessen.
- install_node: 192.168.1.1 Ange nodens verkliga IP. I vårt fall anger vi detsamma som i nmtui
- dns_domain: ange din domän.
- dns_servers: ange din dns.
- ntp_servers: du kan ange vilken som helst. Jag tog den första jag stötte på från poolen 0.pool.ntp.org (den blev 91.216.168.42)
- autonaming: custom Om du inte avkommentarer kommer månen att heta Luna.
- ecs_block_devices:
/ Dev / sdb
Av någon okänd anledning kan det finnas en icke-existerande blocklagringsenhet /dev/vda - lagringspooler:
medlemmar:
192.168.1.1 Här anger vi återigen nodens verkliga IP - ecs_block_devices:
/dev/sdb Vi upprepar operationen att klippa bort icke-existerande enheter.
I allmänhet beskrivs hela filen i detalj i , men vem kommer att läsa den i en så orolig tid. Det står också att det minsta tillräckliga är att specificera IP och mask, men i mitt labb startade en sådan uppsättning ganska dåligt, och jag var tvungen att utöka den till den som anges ovan.
Efter att ha avslutat redigeraren måste du köra update_deploy /home/admin/ECS-CommunityEdition/deploy.yml, och om allt görs korrekt kommer detta att rapporteras explicit.
Då måste du fortfarande köra videoploy, vänta på att miljön ska uppdateras, och du kan starta själva installationen med kommandot ova-step1, och efter att det har slutförts, kommandot ova-step2. Viktigt: stoppa inte skripten för hand! Vissa steg kan ta en betydande tid, kanske inte slutföras vid första försöket och kan se ut som att allt är trasigt. I vilket fall som helst måste du vänta tills skriptet slutförs naturligt. I slutet bör du se ett meddelande som liknar detta.
Nu kan vi äntligen öppna WebUI-kontrollpanelen med den IP vi känner till. Om konfigurationen inte ändrades i skedet kommer standardkontot att vara root/ChangeMe. Du kan till och med använda vår S3-kompatibla lagring direkt. Den är tillgänglig på portarna 9020 för HTTP och 9021 för HTTPS. Återigen, om inget ändrades, då access_key: object_admin1 och secret_key: ChangeMeChangeMeChangeMeChangeMeChangeMe.
Men låt oss inte gå för långt och börja i ordning.
När du loggar in för första gången kommer du att tvingas ändra ditt lösenord till ett adekvat, vilket är helt korrekt. Huvudinstrumentpanelen är extremt tydlig, så låt oss göra något mer intressant än att förklara de uppenbara måtten. Låt oss till exempel skapa en användare som vi kommer att använda för att komma åt lagringen. I tjänsteleverantörernas värld kallas dessa hyresgäster. Detta görs i Hantera > Användare > Ny objektanvändare
När vi skapar en användare ombeds vi att ange ett namnområde. Tekniskt sett hindrar ingenting oss från att skapa lika många av dem som det finns användare. Och vice versa. Detta gör att du kan hantera resurser oberoende för varje hyresgäst.
Följaktligen väljer vi de funktioner vi behöver och genererar användarnycklar. S3/Atmos kommer att räcka för mig. Och glöm inte att spara nyckeln 😉
Användaren har skapats, nu är det dags att tilldela honom en hink. Gå till Hantera > Hink och fyll i de obligatoriska fälten. Allt är enkelt här.
Nu har vi allt klart för ganska strid användning av vår S3-lagring.
Konfigurera Veeam
Så, som vi minns, är en av de viktigaste användningsområdena för objektlagring långtidslagring av information som sällan nås. Ett idealiskt exempel är behovet av att lagra säkerhetskopior på en avlägsen plats. I Veeam Backup & Replication kallas denna funktion för kapacitetsnivå.
Låt oss börja konfigurera genom att lägga till vår Dell ECS CE till Veeam-gränssnittet. På fliken Backup Infrastructure startar du guiden Lägg till nytt arkiv och väljer Objektlagring.
Låt oss välja vad det hela började för - S3-kompatibel.
I fönstret som visas skriver du önskat namn och går till kontosteget. Här måste du ange Servicepunkt i formuläret , kan regionen lämnas som den är och den skapade användaren kan läggas till. En gateserver är nödvändig om din lagring är placerad på en fjärrplats, men detta är redan ett ämne för optimering av infrastruktur och en separat artikel, så du kan säkert hoppa över det här.
Om allt är specificerat och konfigurerat korrekt kommer en varning om certifikatet att dyka upp och sedan ett fönster med en hink där du kan skapa en mapp för våra filer.
Vi går igenom guiden till slutet och njuter av resultatet.
Nästa steg är att antingen skapa ett nytt Scale-out Backup Repository eller lägga till vår S3 till det befintliga - det kommer att användas som en Capacity Tier för arkivlagring. Det finns ingen funktion för att använda S3-kompatibel lagring direkt, som ett vanligt arkiv, i den aktuella versionen. Alltför många ganska icke-uppenbara problem måste lösas för att detta ska hända, men allt är möjligt.
Gå till förvarets inställningar och aktivera Capacity Tier. Allt är transparent där, men det finns en intressant nyans: om du vill att all data ska skickas till objektlagring så snart som möjligt, ställ bara in den till 0 dagar.
Efter att ha gått igenom guiden, om du inte vill vänta, kan du trycka på ctrl+RMB på förvaret, kraftfullt starta Tiering-jobbet och se graferna krypa.
Det var allt tills vidare. Jag tycker att jag lyckades med uppgiften att visa att blocklagring inte är så skrämmande som folk tror. Ja, det finns lösningar och alternativ för en vagn och en liten vagn, men du kan inte täcka allt i en artikel. Så låt oss dela vår erfarenhet i kommentarerna.
Källa: will.com