Verden så den første prototypen av objektlagring i 1996. Om 10 år vil Amazon Web Services lansere Amazon S3, og verden vil systematisk begynne å gå amok med et flatt adresseområde. Takket være arbeidet med metadata og dets evne til å skalere uten å synke under belastning, ble objektlagring raskt standarden for de fleste skydatalagringstjenester, og ikke bare det. En annen viktig funksjon er at den egner seg godt for lagring av arkiver og lignende sjelden brukte filer. Alle som var involvert i datalagring gledet seg og bar den nye teknologien i armene.
Men folks rykter var fulle av rykter om at objektlagring bare handler om store skyer, og hvis du ikke trenger løsninger fra de fordømte kapitalistene, vil det være veldig vanskelig å lage dine egne. Mye er allerede skrevet om å distribuere din egen sky, men det er ikke nok informasjon tilgjengelig om å lage såkalte S3-kompatible løsninger.
Derfor vil vi i dag finne ut hvilke alternativer det er "Slik at det er som voksne, ikke CEPH og en større fil," vi vil distribuere en av dem, og vi vil sjekke at alt fungerer med Veeam Backup & Replication. Den hevder å støtte arbeid med S3-kompatible lagringer, og vi vil teste denne påstanden.
Hva med andre?
Jeg foreslår at du starter med en liten oversikt over markedet og alternativene for lagring av objekter. Den generelt anerkjente lederen og standarden er Amazon S3. De to nærmeste forfølgerne er Microsoft Azure Blob Storage og IBM Cloud Object Storage.
Er det alt? Er det virkelig ingen andre konkurrenter? Selvfølgelig finnes det konkurrenter, men noen går sin egen vei, som Google Cloud eller Oracle Cloud Object Storage, med ufullstendig støtte for S3 API. Noen bruker eldre versjoner av API, som Baidu Cloud. Og noen, som Hitachi Cloud, krever spesiell logikk, som helt sikkert vil forårsake sine egne vanskeligheter. Uansett sammenlignes alle med Amazon, som kan betraktes som bransjestandarden.
Men i lokale løsninger er det mye flere valgmuligheter, så la oss skissere kriteriene som er viktige for oss. I prinsippet er bare to nok: støtte for S3 API og bruk av v4-signering. Hånden på hjertet er vi som fremtidig oppdragsgiver kun interessert i grensesnitt for samhandling, og vi er ikke så interessert i det innvendige kjøkkenet til selve lageret.
Mange løsninger passer til disse enkle forholdene. For eksempel klassiske tungvektere for bedrifter:
- DellEMC ECS
- NetApp S3 StorageGrid
- Nutanix bøtter
- Pure Storage FlashBlade og StorReduce
- Huawei FusionStorage
Det er en nisje av rene programvareløsninger som fungerer ut av boksen:
- Red Hat Ceph
- SUSE Enterprise Storage
- Cloudian
Og selv de som liker å arkivere nøye etter montering ble ikke fornærmet:
- CEPH i sin reneste form
- Minio (Linux-versjon, fordi det er mange spørsmål om Windows-versjonen)
Listen er langt fra komplett, den kan diskuteres i kommentarfeltet. Bare ikke glem å sjekke systemytelsen i tillegg til API-kompatibilitet før implementering. Det siste du ønsker er å miste terabyte med data på grunn av spørsmål som sitter fast. Så ikke vær sjenert med belastningstester. Generelt har all voksen programvare som fungerer med store datamengder minst kompatibilitetsrapporter. I tilfelle Veeam det er på gjensidig testing, som lar oss trygt erklære at produktene våre er kompatible med spesifikt utstyr. Dette er allerede et toveis arbeid, ikke alltid raskt, men vi utvider stadig testede løsninger.
Montering av standen vår
Jeg vil gjerne snakke litt om valg av prøveemne.
Først ønsket jeg å finne et alternativ som ville fungere rett ut av esken. Vel, eller i det minste med størst sannsynlighet for at det vil fungere uten at du trenger å gjøre unødvendige bevegelser. Å danse med en tamburin og tukle med konsollen om natten er veldig spennende, men noen ganger vil du at det skal fungere med en gang. Og den generelle påliteligheten til slike løsninger er vanligvis høyere. Og ja, eventyrlysten har forsvunnet i oss, vi sluttet å klatre inn i vinduene til våre elskede kvinner osv. (c).
For det andre, for å være ærlig, oppstår behovet for å jobbe med objektlagring i ganske store selskaper, så dette er selve tilfellet når man ser mot løsninger på bedriftsnivå ikke bare ikke er skammelig, men til og med oppmuntret. I alle fall kjenner jeg ennå ikke til noen eksempler på at noen har fått sparken for å kjøpe slike løsninger.
Basert på alt det ovennevnte falt valget mitt på Dell EMC ECS Community Edition. Dette er et veldig interessant prosjekt, og jeg anser det som nødvendig å fortelle deg om det.
Det første du tenker på når du ser tillegget Community Edition - at dette kun er en kopi av en fullverdig ECS med noen restriksjoner som fjernes ved å kjøpe en lisens. Så nei!
Husk:
!!!Community Edition er et eget prosjekt laget for testing, og uten teknisk støtte fra Dell!!
Og det kan ikke gjøres om til et fullverdig ECS, selv om du virkelig ønsker det.
La oss finne ut av det
Mange tror at Dell EMC ECS nesten er den beste løsningen hvis du har behov for objektlagring. Alle prosjekter under ECS-merket, inkludert kommersielle og bedrifter, er basert på . En slags velviljegest fra Dell. Og i tillegg til programvaren som kjører på deres merkede maskinvare, er det en åpen kildekode-versjon som kan distribueres i skyen, på en virtuell maskin, i en container eller på hvilken som helst av din egen maskinvare. Ser vi fremover, er det til og med en OVA-versjon, som vi skal bruke.
Selve DELL ECS Community Edition er en miniversjon av fullverdig programvare som kjører på merkede Dell EMC ECS-servere.
Jeg identifiserte fire hovedforskjeller:
- Ingen krypteringsstøtte. Det er synd, men ikke kritisk.
- Stofflag mangler. Denne tingen er ansvarlig for å bygge klynger, ressursadministrasjon, oppdateringer, overvåking og lagring av Docker-bilder. Det er her det allerede er veldig støtende, men Dell kan også forstås.
- Den mest motbydelige konsekvensen av forrige punkt: størrelsen på noden kan ikke utvides etter at installasjonen er fullført.
- Ingen teknisk støtte. Dette er et produkt for testing, som ikke er forbudt å brukes i små installasjoner, men jeg personlig ville ikke turt å laste opp petabyte med viktig data dit. Men teknisk sett kan ingen stoppe deg fra å gjøre dette.
Hva er i den store versjonen?
La oss galoppere over Europa og gå gjennom jernkledde løsninger for å få en mer fullstendig forståelse av økosystemet.
Jeg vil ikke på en eller annen måte bekrefte eller avkrefte påstanden om at DELL ECS er den beste lokale objektlagringen, men hvis du har noe å si om dette emnet, vil jeg gjerne lese det i kommentarene. I hvert fall i henhold til versjonen Dell EMC er trygt blant de fem beste OBS-markedslederne. Selv om skybaserte løsninger ikke er tatt hensyn til der, er dette en egen samtale.
Fra et teknisk synspunkt er ECS en objektlagring som gir tilgang til data ved hjelp av skylagringsprotokoller. Støtter AWS S3 og OpenStack Swift. For filaktiverte bøtter, støtter ECS NFSv3 for fil-for-fil-eksport.
Prosessen med å registrere informasjon er ganske uvanlig, spesielt etter klassiske blokklagringssystemer.
- Når nye data kommer, opprettes et nytt objekt som har et navn, selve dataene og metadata.
- Objekter er delt inn i 128 MB biter, og hver del skrives til tre noder samtidig.
- Indeksfilen oppdateres, hvor identifikatorer og lagringssteder registreres.
- Loggfilen (loggoppføringen) oppdateres og skrives også til tre noder.
- En melding om vellykket opptak sendes til klienten
Alle tre kopiene av dataene skrives parallelt. Skrivingen betraktes som vellykket bare hvis alle tre kopiene ble skrevet vellykket.
Det er lettere å lese:
- Klienten ber om data.
- Indeksen ser etter hvor dataene er lagret.
- Data leses fra én node og sendes til klienten.
Det er ganske mange servere selv, så la oss se på den minste Dell EMC ECS EX300. Den starter fra 60 TB, med muligheten til å vokse opp til 1,5 PB. Og den eldre broren, Dell EMC ECS EX3000, lar deg lagre så mye som 8,6 PB per stativ.
Utplassere
Teknisk sett kan Dell ECS CE distribueres så stort du vil. Jeg fant i alle fall ingen eksplisitte begrensninger. Imidlertid er det praktisk å gjøre all skalering ved å klone den aller første noden, som vi trenger:
- 8 vCPUer
- RAM 64GB
- 16 GB for OS
- 1TB direkte lagring
- Siste utgivelse av CentOS minimal
Dette er et alternativ når du vil installere alt selv helt fra begynnelsen. Dette alternativet er ikke relevant for oss, fordi... Jeg vil bruke OVA-bildet for distribusjon.
Men i alle fall er kravene veldig onde selv for en node, og hvis du strengt følger lovens bokstav, trenger du fire slike noder.
Imidlertid lever ECS CE-utviklere i den virkelige verden, og installasjonen er vellykket selv med en node, og minimumskravene er:
- 4 vCPUer
- 16 GB RAM
- 16 GB for OS
- 104 GB lagring i seg selv
Dette er ressursene som trengs for å distribuere OVA-bildet. Allerede mye mer human og realistisk.
Selve installasjonsnoden kan fås fra tjenestemannen . Det er også detaljert dokumentasjon om alt-i-ett-distribusjon, men du kan også lese på den offisielle . Derfor vil vi ikke dvele i detalj ved utfoldelsen av OVA, det er ingen triks der. Det viktigste er at før du starter den, ikke glem å enten utvide disken til ønsket volum eller legge ved de nødvendige.
Vi starter maskinen, åpner konsollen og bruker de beste standardlegitimasjonene:
- pålogging: admin
- passord: ChangeMe
Deretter kjører vi sudo nmtui og konfigurerer nettverksgrensesnittet - IP/maske, DNS og gate. Med tanke på at CentOS minimal ikke har nett-verktøy, sjekker vi innstillingene via ip-adr.
Og siden bare de modige erobrer havene, gjør vi en yum-oppdatering, hvoretter vi starter på nytt. Det er faktisk ganske trygt fordi... all distribusjon gjøres gjennom playbooks, og alle viktige docker-pakker er låst til gjeldende versjon.
Nå er det på tide å redigere installasjonsskriptet. Ingen fancy vinduer eller pseudo-brukergrensesnitt for deg - alt gjøres gjennom din favoritt tekstredigerer. Teknisk sett er det to måter: du kan kjøre hver kommando manuelt eller umiddelbart starte videoploy-konfiguratoren. Den vil ganske enkelt åpne konfigurasjonen i vim, og ved avslutning vil den begynne å sjekke den. Men det er ikke interessant å bevisst forenkle livet ditt, så la oss kjøre to kommandoer til. Selv om dette ikke gir mening, advarte jeg deg =)
Så la oss lage vim ECS-CommunityEdition/deploy.xml og gjøre de optimale minimale endringene slik at ECS er oppe og går. Listen over parametere kan forkortes, men jeg gjorde det slik:
- licensed_accepted: true Du trenger ikke å endre det, så når du distribuerer vil du bli eksplisitt bedt om å godta det og vil bli vist en fin setning. Kanskje dette til og med er et påskeegg.
- Fjern kommentarene til linjene autonames: og custom: Skriv inn minst ett ønsket navn for noden - vertsnavnet vil bli erstattet med det under installasjonsprosessen.
- install_node: 192.168.1.1 Spesifiser den virkelige IP-en til noden. I vårt tilfelle indikerer vi det samme som i nmtui
- dns_domene: skriv inn domenet ditt.
- dns_servers: skriv inn dns.
- ntp_servers: du kan spesifisere hvilken som helst. Jeg tok den første jeg kom over fra pool 0.pool.ntp.org (den ble 91.216.168.42)
- autonaming: custom Hvis du ikke avkommenterer, vil månen hete Luna.
- ecs_block_devices:
/ Dev / sdb
Av en eller annen ukjent grunn kan det være en ikke-eksisterende blokklagringsenhet /dev/vda - storage_pools:
medlemmer:
192.168.1.1 Her indikerer vi igjen den virkelige IP-en til noden - ecs_block_devices:
/dev/sdb Vi gjentar operasjonen med å kutte ut ikke-eksisterende enheter.
Generelt er hele filen beskrevet i detalj i , men hvem vil lese den i en så urolig tid. Det står også at minimum som er tilstrekkelig er å spesifisere IP og maske, men i laboratoriet mitt startet et slikt sett ganske dårlig, og jeg måtte utvide det til det spesifiserte ovenfor.
Etter å ha avsluttet editoren, må du kjøre update_deploy /home/admin/ECS-CommunityEdition/deploy.yml, og hvis alt er gjort riktig, vil dette bli eksplisitt rapportert.
Da må du fortsatt starte videoploy, vente på at miljøet oppdateres, og du kan starte selve installasjonen med kommandoen ova-step1, og etter vellykket gjennomføring, kommandoen ova-step2. Viktig: ikke stopp skriptene for hånd! Noen trinn kan ta betydelig tid, kan ikke fullføres ved første forsøk, og kan se ut som alt er ødelagt. I alle fall må du vente på at skriptet fullføres naturlig. På slutten bør du se en melding som ligner denne.
Nå kan vi endelig åpne WebUI-kontrollpanelet ved å bruke IP-en vi kjenner. Hvis konfigurasjonen ikke ble endret på stadiet, vil standardkontoen være root/ChangeMe. Du kan til og med bruke vår S3-kompatible lagring med en gang. Den er tilgjengelig på portene 9020 for HTTP, og 9021 for HTTPS. Igjen, hvis ingenting ble endret, så access_key: object_admin1 og secret_key: ChangeMeChangeMeChangeMeChangeMeChangeMe.
Men la oss ikke gå for i forkant og begynne i orden.
Når du logger inn for første gang, vil du bli tvunget til å endre passordet ditt til et tilstrekkelig, som er helt korrekt. Hoveddashbordet er ekstremt oversiktlig, så la oss gjøre noe mer interessant enn å forklare de åpenbare beregningene. La oss for eksempel opprette en bruker som vi skal bruke for å få tilgang til lagringen. I tjenesteleverandørenes verden kalles disse leietakere. Dette gjøres i Administrer > Brukere > Ny objektbruker
Når du oppretter en bruker, blir vi bedt om å spesifisere et navneområde. Teknisk sett er det ingenting som hindrer oss i å lage like mange av dem som det er brukere. Og vice versa. Dette lar deg administrere ressurser uavhengig for hver leietaker.
Følgelig velger vi funksjonene vi trenger og genererer brukernøkler. S3/Atmos vil være nok for meg. Og ikke glem å lagre nøkkelen 😉
Brukeren er opprettet, nå er det på tide å tildele ham en bøtte. Gå til Administrer > Bøtte og fyll ut de obligatoriske feltene. Alt er enkelt her.
Nå har vi alt klart for ganske strid bruk av S3-lagringen vår.
Setter opp Veeam
Så, som vi husker, er en av hovedbrukene for objektlagring langsiktig lagring av informasjon som man sjelden får tilgang til. Et ideelt eksempel er behovet for å lagre sikkerhetskopier på et eksternt sted. I Veeam Backup & Replication kalles denne funksjonen Capacity Tier.
La oss begynne å konfigurere ved å legge til vår Dell ECS CE i Veeam-grensesnittet. På Backup Infrastructure-fanen starter du veiviseren Legg til nytt depot og velger Objektlagring.
La oss velge hva det hele startet for - S3-kompatibel.
I vinduet som vises, skriv ønsket navn og gå til kontotrinnet. Her må du spesifisere Servicepunktet i skjemaet , regionen kan forlates som den er og den opprettede brukeren kan legges til. En gateserver er nødvendig hvis lagringen din er plassert på et eksternt nettsted, men dette er allerede et emne for optimalisering av infrastruktur og en egen artikkel, så du kan trygt hoppe over det her.
Hvis alt er spesifisert og konfigurert riktig, vises en advarsel om sertifikatet og deretter et vindu med en bøtte hvor du kan opprette en mappe for filene våre.
Vi går gjennom veiviseren til slutten og nyter resultatet.
Det neste trinnet er å enten opprette et nytt Scale-out Backup Repository, eller legge til vår S3 til den eksisterende - den vil bli brukt som et kapasitetsnivå for arkivlagring. Det er ingen funksjon for å bruke S3-kompatibel lagring direkte, som et vanlig depot, i den nåværende utgivelsen. For mange ganske uopplagte problemer må løses for at dette skal skje, men alt er mulig.
Gå til depotinnstillingene og aktiver Capacity Tier. Alt er gjennomsiktig der, men det er en interessant nyanse: Hvis du vil at alle data skal sendes til objektlagring så snart som mulig, setter du den til 0 dager.
Etter å ha gått gjennom veiviseren, hvis du ikke vil vente, kan du trykke ctrl+RMB på depotet, starte Tiering-jobben kraftig og se grafene krype.
Det er alt for nå. Jeg synes jeg lyktes i oppgaven med å vise at blokklagring ikke er så skummelt som folk tror. Ja, det finnes løsninger og alternativer for en vogn og en liten vogn, men du kan ikke dekke alt i én artikkel. Så la oss dele vår erfaring i kommentarene.
Kilde: www.habr.com