Verden så den første prototype af objektlagring i 1996. Om 10 år lancerer Amazon Web Services Amazon S3, og verden begynder systematisk at gå amok med et fladt adresseområde. Takket være dens metadatahåndtering og dens evne til at skalere uden at falde under belastning, er objektlagring hurtigt blevet standarden for de fleste cloud-lagringstjenester og mere. En anden vigtig funktion er dens gode tilpasningsevne til lagring af arkiver og lignende sjældent brugte filer. Alle involveret i datalagring jublede og bar den nye teknologi på hånden.
Men folks rygter var fulde af rygter om, at objektlagring kun handler om store skyer, og hvis man ikke har brug for løsninger fra de forbandede kapitalister, så bliver det meget svært at lave sine egne. Der er allerede skrevet meget om at implementere din egen cloud, men der er ikke nok information om at skabe de såkaldte S3-kompatible løsninger.
Derfor vil vi i dag finde ud af, hvilke muligheder der er "At være som voksne, og ikke CEPH og en større fil", vi vil implementere en af dem, og vi vil kontrollere, at alt fungerer ved hjælp af Veeam Backup & Replication. Det hævder støtte til at arbejde med S3-kompatible lager, og vi vil tjekke denne erklæring.
Hvad med andre?
Jeg foreslår at starte med et lille overblik over markedet og muligheder for objektopbevaring. Den generelt anerkendte leder og standard er Amazon S3. De to nærmeste forfølgere er Microsoft Azure Blob Storage og IBM Cloud Object Storage.
Er det alt? Er der ingen andre konkurrenter? Selvfølgelig er der konkurrenter, men nogen går deres egen vej, som Google Cloud eller Oracle Cloud Object Storage, med ufuldstændig understøttelse af S3 API. Nogen bruger gamle versioner af API'en, som Baidu Cloud. Og nogle, som Hitachi Cloud, kræver anvendelse af speciel logik, hvilket helt sikkert vil forårsage sine egne vanskeligheder. Under alle omstændigheder sammenlignes alle med Amazon, som kan betragtes som branchestandarden.
Men i on-premise løsninger er valget meget større, så lad os skitsere de kriterier, der er vigtige for os. I princippet er kun to nok: Understøttelse af S3 API og brugen af v4-signering. Hånden på hjertet er vi som kommende kunde kun interesserede i grænseflader til interaktion, og vi er ikke så interesserede i selve lagerets indre køkken.
Tja, mange løsninger passer til disse simple forhold. For eksempel klassiske virksomheders sværvægtere:
- DellEMC ECS
- NetApp S3 Storage Grid
- Nutanix spande
- Pure Storage FlashBlade og StorReduce
- Huawei FusionStorage
Der er en niche af rene softwareløsninger, der fungerer ud af boksen:
- Red Hat Ceph
- SUSE Enterprise Storage
- Cloudian
Og selv dem, der kan lide at omhyggeligt behandle med en fil efter samling, blev ikke fornærmet:
- CEPH i sin reneste form
- Minio (Linux-version, fordi der er mange spørgsmål om Windows-versionen)
Listen er langt fra komplet, det kan diskuteres i kommentarerne. Bare glem ikke at kontrollere systemets ydeevne ud over API-kompatibilitet før implementering. Den sidste ting, du ønsker, er tab af terabyte data på grund af fastlåste anmodninger. Så indlæs gerne tests. Generelt har al voksensoftware, der fungerer med store mængder data, i det mindste kompatibilitetsrapporter. I tilfælde af Veeam Der er på gensidig test, som giver os mulighed for dristigt at erklære vores produkters fulde kompatibilitet med specifikt udstyr. Dette er allerede et tovejsarbejde, ikke altid hurtigt, men vi udvider hele tiden afprøvede løsninger.
Sammensætter vores stand
Jeg vil gerne snakke lidt om valg af testfag.
Først ville jeg finde en mulighed, der ville fungere lige ud af boksen. Nå, eller i det mindste med den maksimale sandsynlighed for, at det vil fungere uden behov for at lave unødvendige bevægelser. Det er meget spændende at danse med en tamburin og vælge konsollen om natten, men nogle gange vil man have det til at virke med det samme. Og den samlede pålidelighed af sådanne løsninger er normalt højere. Og ja, eventyrlysten forsvandt i os, vi holdt op med at klatre gennem vinduerne til vores elskede kvinder osv. (c).
For det andet, for at være ærlig, opstår behovet for at arbejde med objektopbevaring i ret store virksomheder, så dette er netop tilfældet, når man ser hen imod løsninger på virksomhedsniveau ikke blot ikke skammer sig, men endda opmuntres. Jeg kender i hvert fald endnu ikke eksempler på, at nogen er blevet fyret for at købe sådanne løsninger.
På baggrund af ovenstående faldt mit valg på Dell EMC ECS Community Edition. Dette er et meget interessant projekt, og jeg anser det for nødvendigt at fortælle dig om det.
Det første, der kommer til at tænke på, når du ser tilføjelsen EF-udgave - at dette blot er et sporingspapir fra et fuldgyldigt ECS med nogle restriktioner, der fjernes ved køb af en licens. Så nej!
Husk:
!!!Community Edition er et separat projekt skabt til test og uden teknisk support fra Dell!!
Og det kan ikke laves om til et fuldgyldigt ECS, selvom man virkelig vil.
Lad os finde ud af det
Mange mennesker tror, at Dell EMC ECS næsten er den bedste løsning, hvis du har behov for objektlagring. Alle projekter under ECS-mærket, herunder kommercielle og virksomhedsprojekter, er . En slags gestus af velvilje fra Dell. Og ud over den software, der kører på deres brandede hardware, er der en open source-version, der kan implementeres selv i skyen, selv på en virtuel maskine, selv i en container, selv på enhver af din hardware. Ser vi fremad, er der endda en OVA-version, som vi vil bruge.
Selve DELL ECS Community Edition er en miniversion af den fuldgyldige software, der kører på Dell EMC ECS-mærkede servere.
Jeg har identificeret fire hovedforskelle:
- Ingen krypteringsunderstøttelse. Det er en skam, men ikke kritisk.
- Der er intet stoflag. Denne ting er ansvarlig for at bygge klynger, administrere ressourcer, opdatere, overvåge og gemme Docker-billeder. Her er det allerede meget skuffende, men Dell kan også forstås.
- Den mest grimme konsekvens af det foregående punkt: størrelsen af noden kan ikke udvides efter installationen er afsluttet.
- Ingen teknisk support. Dette er et produkt til test, som ikke er forbudt at bruge i små installationer, men jeg ville personligt ikke turde uploade petabytes af vigtige data der. Men teknisk set kan ingen forhindre dig i at gøre dette.
Hvad er der i den store version?
Når vi galopperer gennem Europa, så lad os gennemgå jernløsningerne for at få et mere komplet billede af økosystemet.
Jeg vil ikke på en eller anden måde bekræfte eller afkræfte udsagnet om, at DELL ECS er den bedste on-prem-objektlagring, men hvis du har noget at sige om dette emne, vil jeg med glæde læse det i kommentarerne. I hvert fald ifølge versionen Dell EMC kommer trygt ind i de fem bedste OBS-markedsledere. Selvom der ikke tages højde for cloud-baserede løsninger, er dette en separat samtale.
Fra et teknisk synspunkt er ECS et objektlager, der giver adgang til data ved hjælp af cloud storage-protokoller. Understøtter AWS S3 og OpenStack Swift. For fil-aktiverede buckets understøtter ECS NFSv3 til fil-for-fil-eksport.
Processen med at skrive information er ret usædvanlig, især efter de klassiske bloklagringssystemer.
- Når der kommer nye data, oprettes et nyt objekt, der har et navn, selve dataene og metadata.
- Objekter er opdelt i 128 MB bidder, og hver chunk skrives til tre noder på én gang.
- Indeksfilen opdateres, hvor identifikatorer og lagerpladser registreres.
- Logfilen (record log) opdateres og skrives også til tre noder.
- Der sendes en besked til klienten om en vellykket registrering.
Alle tre kopier af dataene er skrevet parallelt. Skrivningen anses kun for vellykket, hvis alle tre kopier blev skrevet med succes.
Det er nemmere at læse:
- Klienten anmoder om data.
- Indekset leder efter et sted at opbevare data.
- Data læses fra én node og sendes til klienten.
Der er en del servere selv, så lad os se på den mindste Dell EMC ECS EX300. Det starter ved 60Tb, med evnen til at vokse op til 1,5Pb. Og hans ældre bror Dell EMC ECS EX3000 giver dig allerede mulighed for at opbevare så meget som 8,6 Pb pr. rack.
Indsætte
Teknisk set kan Dell ECS CE implementeres så stort som ønsket. I hvert fald fandt jeg ikke eksplicitte begrænsninger. Al skalering udføres dog bekvemt ved at klone den allerførste node, som vi har brug for:
- 8 vCPU'er
- 64GB RAM
- 16 GB til operativsystem
- 1TB direkte til opbevaring
- Seneste udgivelse af CentOS minimal
Dette er en mulighed for tilfældet, når du vil installere alt selv fra begyndelsen. For os er denne mulighed ikke relevant, fordi. Jeg vil bruge et OVA-image til at implementere.
Men under alle omstændigheder er kravene meget onde, selv for en knude, og hvis du nøje følger lovens bogstav, har du brug for fire sådanne knudepunkter.
ECS CE-udviklere lever dog i den virkelige verden, og installationen er vellykket selv med en enkelt node, og minimumskravene er:
- 4 vCPU'er
- 16 GB RAM
- 16 GB til operativsystem
- 104 GB lagerplads
Det er disse ressourcer, der er nødvendige for at implementere OVA-billedet. Allerede meget mere human og realistisk.
Selve installationsknuden kan tages fra embedsmanden . Der er også detaljeret dokumentation om implementering af alt-i-en, men du kan også læse på den officielle . Derfor vil vi ikke dvæle ved implementeringen af OVA i detaljer, der er ingen tricks. Det vigtigste - glem ikke, før du starter det, enten udvid disken til det ønskede volumen eller vedhæft de nødvendige.
Vi starter maskinen, åbner konsollen og bruger de bedste standardcreds:
- login: admin
- Adgangskode: changeme
Så kører vi sudo nmtui og konfigurerer netværksgrænsefladen - IP / maske, DNS og gate. Med tanke på, at der ikke er nogen net-værktøjer i CentOS minimal, tjekker vi indstillingerne via ip-adr.
Og da kun de modige erobrer havene, laver vi yum update, hvorefter vi genstarter. Det er faktisk ret sikkert. al implementering sker gennem playbooks, og alle vigtige docker-pakker er låst til den aktuelle version.
Nu er det tid til at redigere installationsscriptet. Ingen smukke vinduer eller pseudo-brugergrænseflade til dig - alt er gennem din yndlingsteksteditor. Rent teknisk er der to måder: du kan køre hver kommando manuelt eller køre videploy-konfiguratoren med det samme. Det vil blot åbne konfigurationen i vim, og ved afslutning vil det begynde at tjekke det. Men det er ikke interessant at forenkle dit liv bevidst, så lad os udføre to kommandoer mere. Selvom det ikke giver nogen mening, advarede jeg dig =)
Så vi laver vim ECS-CommunityEdition/deploy.xml og laver de optimale minimumsændringer, så ECS tænder og virker. Listen over parametre kan forkortes, men jeg gjorde det sådan her:
- licensed_accepted: true Du behøver ikke at ændre det, så når du implementerer vil du udtrykkeligt blive bedt om at acceptere det og vise en pæn sætning. Det kan endda være et påskeæg.
- Fjern kommentarer til linjerne autonames: og brugerdefineret: Indtast mindst ét ønsket navn for noden - værtsnavnet vil blive erstattet med det under installationsprocessen.
- install_node: 192.168.1.1 Angiv nodens rigtige IP. I vores tilfælde angiver vi det samme som i nmtui
- dns_domain: indtast dit domæne.
- dns_servere: Indtast din dns.
- ntp_servers: Enhver kan specificeres. Jeg tog den første fra puljen 0.pool.ntp.org (den blev 91.216.168.42)
- autoname: brugerdefineret Hvis den ikke kommenteres, vil månen blive kaldt Luna.
- ecs_block_devices:
/ Dev / sdb
Af en eller anden ukendt årsag kan der være en ikke-eksisterende bloklagerenhed /dev/vda - storage_pools:
medlemmer:
192.168.1.1 Her angiver vi igen nodens rigtige IP - ecs_block_devices:
/dev/sdb Vi gentager operationen med at skære ikke-eksisterende enheder.
Generelt er hele filen beskrevet meget detaljeret i men hvem vil læse den i sådan en turbulent tid. Det er også skrevet der, at det minimum, der er tilstrækkeligt, er at specificere IP og maske, men i mit laboratorium startede sådan et sæt ikke godt, og jeg var nødt til at udvide det til det, der er angivet ovenfor.
Efter at have afsluttet editoren, skal du køre update_deploy /home/admin/ECS-CommunityEdition/deploy.yml, og hvis alt er gjort korrekt, vil dette blive rapporteret eksplicit.
Så skal du stadig starte videploy, vente på, at miljøet opdaterer, og du kan starte selve installationen med kommandoen ova-step1, og efter dens succesfulde afslutning, kommandoen ova-step2. Vigtigt: stop ikke scripts i hånden! Nogle trin kan tage lang tid, tage længere tid end første forsøg og se ud som om alt er gået i stykker. Under alle omstændigheder skal du vente på færdiggørelsen af scriptet på en naturlig måde. Til sidst skulle du se noget som dette.
Nu kan vi endelig åbne WebUI-kontrolpanelet ved hjælp af den IP, vi kender. Hvis den ikke blev ændret på konfigurationsstadiet, vil standardkontoen være root/ChangeMe. Du kan endda bruge vores S3-kompatible lager med det samme. Den er tilgængelig på porte 9020 for HTTP og 9021 for HTTPS. Igen, hvis intet er blevet ændret, så access_key: object_admin1 og secret_key: ChangeMeChangeMeChangeMeChangeMeChangeMe.
Men lad os ikke gå foran os selv og starte i orden.
Ved første login vil du blive bedt om at ændre adgangskoden til en passende, hvilket er helt korrekt. Hovedbetjeningspanelet er ekstremt overskueligt, så lad os gøre noget mere interessant end at forklare de åbenlyse målinger. Lad os for eksempel oprette en bruger, som vi vil bruge til at få adgang til depotet. I en verden af serviceudbydere kaldes disse lejere. Dette gøres i Administrer > Brugere > Ny objektbruger
Når vi opretter en bruger, bliver vi bedt om at angive et navneområde. Teknisk set forhindrer intet os i at starte dem så mange, som der vil være brugere. Og omvendt. Dette gør det muligt at administrere ressourcer uafhængigt for hver lejer.
Derfor vælger vi de funktioner, vi har brug for, og genererer brugernøgler. S3/Atmos vil være nok for mig. Og glem ikke at gemme nøglen 😉
Brugeren er oprettet, nu er det tid for ham at vælge spanden. Gå til Administrer > Spand, og udfyld de påkrævede felter. Alt er enkelt her.
Nu har vi alt klar til en temmelig kampbrug af vores S3-lagerplads.
Opsætning af Veeam
Så, som vi husker, er en af de vigtigste anvendelser af objektlagring langtidslagring af information, der sjældent tilgås. Et ideelt eksempel er behovet for at gemme sikkerhedskopier på et eksternt sted. I Veeam Backup & Replication kaldes denne funktion Capacity Tier.
Lad os starte opsætningen ved at tilføje vores Dell ECS CE til Veeam-grænsefladen. På fanen Backup Infrastructure skal du starte guiden til tilføjelse af et nyt lager og vælge objektlageret.
Vi vælger, hvad alt blev startet til - S3-kompatibel.
Skriv det ønskede navn i vinduet, der vises, og gå til kontotrinnet. Her skal du angive Servicepunktet i formularen , regionen kan efterlades som den er, og den oprettede bruger kan tilføjes. En gateserver er påkrævet, hvis dit lager er placeret på et eksternt websted, men dette er allerede et emne om infrastrukturoptimering og en separat artikel, så du kan roligt springe det over her.
Hvis alt er specificeret og konfigureret korrekt, vil en advarsel om certifikatet poppe op og derefter et vindue med en bøtte, hvor du kan oprette en mappe til vores filer.
Vi videregiver guiden til slutningen og nyder resultatet.
Det næste trin er enten at oprette et nyt Scale-out Backup Repository eller tilføje vores S3 til det eksisterende - det vil blive brugt som et Kapacitetsniveau til arkivlagring. Funktionen til at bruge S3-kompatible depoter direkte, ligesom et almindeligt lager, er ikke i den aktuelle udgivelse. Der er for mange temmelig ikke-oplagte problemer til at dette kan løses, men alt kan være.
Vi går ind i lagerindstillingerne og slår Kapacitetsniveauet til. Alt er gennemsigtigt der, men der er en interessant nuance: Hvis du ønsker, at alle data skal sendes til objektlagring så hurtigt som muligt, skal du bare indstille det til 0 dage.
Efter at have gennemgået guiden, hvis du ikke vil vente, kan du trykke på ctrl+RMB på lageret, køre Tiering-jobbet med magt og se graferne kravle.
Det er alt for nu. Jeg tror, at jeg klarede opgaven med at vise, at blokopbevaring ikke er så skræmmende, som det almindeligvis antages. Ja, løsninger og muligheder for udførelse af en vogn og en lille vogn, men det er umuligt at dække alt i en artikel. Så lad os dele vores oplevelse i kommentarerne.
Kilde: www.habr.com