Denne artikel blev skrevet for at hjælpe dig med at vælge den rigtige løsning for dig selv og forstå forskellene mellem SDS såsom Gluster, Ceph og Vstorage (Virtuozzo).
Teksten bruger links til artikler med en mere detaljeret afsløring af visse problemer, så beskrivelserne bliver så korte som muligt med nøglepunkter uden unødvendige fnug og indledende information, som du, hvis du ønsker det, selvstændigt kan skaffe på internettet.
Faktisk kræver de rejste emner selvfølgelig tekstens toner, men i den moderne verden kan flere og flere ikke lide at læse meget))), så du kan hurtigt læse og træffe et valg, og hvis noget er ikke klart, følg linkene eller google uklare ord))), og denne artikel er som en gennemsigtig indpakning for disse dybe emner, der viser fyldet - de vigtigste nøglepunkter i hver beslutning.
Glans
Lad os starte med Gluster, som aktivt bruges af producenter af hyperkonvergerede platforme med SDS baseret på open source til virtuelle miljøer og kan findes på RedHats hjemmeside i lagerafsnittet, hvor du kan vælge mellem to SDS-muligheder: Gluster eller Ceph.
Gluster består af en stak oversættere - tjenester, der udfører alt arbejdet med at distribuere filer mv. Brick er en service, der betjener én disk, Volume er en volumen (pulje), der forener disse klodser. Dernæst kommer tjenesten til at distribuere filer i grupper ved hjælp af DHT-funktionen (distributed hash table). Vi vil ikke inkludere Sharding-tjenesten i beskrivelsen, da nedenstående links vil beskrive de problemer, der er forbundet med den.
Ved skrivning gemmes hele filen i klods, og dens kopi skrives samtidigt til klods på den anden server. Dernæst vil den anden fil blive skrevet til den anden gruppe af to klodser (eller flere) på forskellige servere.
Hvis filerne har omtrent samme størrelse, og volumen kun består af én gruppe, er alt fint, men under andre forhold vil følgende problemer opstå fra beskrivelserne:
- plads i grupper udnyttes ujævnt, det afhænger af størrelsen på filerne, og hvis der ikke er plads nok i gruppen til at skrive en fil, vil du modtage en fejl, filen vil ikke blive skrevet og vil ikke blive omfordelt til en anden gruppe ;
- når du skriver en fil, går IO kun til én gruppe, resten er inaktive;
- du kan ikke få IO af hele volumen, når du skriver en fil;
- og det generelle koncept ser mindre produktivt ud på grund af den manglende datafordeling i blokke, hvor det er lettere at balancere og løse problemet med ensartet distribution, og ikke som nu hele filen går i en blok.
Fra den officielle beskrivelse vi kommer også ufrivilligt til den forståelse, at gluster fungerer som fillagring oven på klassisk hardware RAID. Der har været udviklingsforsøg på at skære (Sharding) filer i blokke, men alt dette er en tilføjelse, der påfører ydeevnetab på den allerede eksisterende arkitektoniske tilgang, plus brugen af sådanne frit distribuerede komponenter med ydeevnebegrænsninger som Fuse. Der er ingen metadatatjenester, hvilket begrænser lagerets ydeevne og fejltolerancekapacitet, når filer distribueres i blokke. Bedre ydeevneindikatorer kan observeres med "Distributed Replicated"-konfigurationen, og antallet af noder bør være mindst 6 for at organisere en pålidelig replika 3 med optimal belastningsfordeling.
Disse resultater er også relateret til beskrivelsen af brugeroplevelsen og sammenlignet med , og der er også en beskrivelse af oplevelsen, der fører til en forståelse af denne mere produktive og mere pålidelige konfiguration
Billedet viser belastningsfordelingen ved skrivning af to filer, hvor kopier af den første fil er fordelt på de første tre servere, som er kombineret i bind 0-gruppen, og tre kopier af den anden fil er placeret på den anden gruppe bind1 af tre servere. Hver server har én disk.
Den generelle konklusion er, at du kan bruge Gluster, men med den forståelse, at der vil være begrænsninger i ydeevne og fejltolerance, der skaber vanskeligheder under visse betingelser for en hyperkonvergeret løsning, hvor der også er brug for ressourcer til computerbelastningen i virtuelle miljøer.
Der er også nogle Gluster-ydeevneindikatorer, der kan opnås under visse betingelser, begrænset til
ceph
Lad os nu se på Ceph fra de arkitekturbeskrivelser, som jeg var i stand til Der er også en sammenligning mellem , hvor du umiddelbart kan forstå, at det er tilrådeligt at installere Ceph på separate servere, da dets tjenester kræver alle hardwareressourcer under belastning.
arkitektur mere kompleks end Gluster og der er tjenester som f.eks. metadatatjenester, men hele stakken af komponenter er ret kompleks og ikke særlig fleksibel til at bruge den i en virtualiseringsløsning. Dataene er lagret i blokke, som ser mere produktive ud, men i hierarkiet af alle tjenester (komponenter) er der tab og latens under visse belastninger og nødsituationer, for eksempel følgende
Fra beskrivelsen af arkitekturen er hjertet CRUSH, takket være hvilket placeringen for lagring af data er valgt. Dernæst kommer PG - dette er den sværeste abstraktion (logisk gruppe) at forstå. PG'er er nødvendige for at gøre CRUSH mere effektiv. Hovedformålet med PG er at gruppere objekter for at reducere ressourceforbrug, øge ydeevne og skalerbarhed. At adressere objekter direkte, individuelt, uden at kombinere dem til en PG ville være meget dyrt. OSD er en service for hver enkelt disk.
En klynge kan have en eller flere datapuljer til forskellige formål og med forskellige indstillinger. Puljerne er opdelt i placeringsgrupper. Placeringsgrupper gemmer objekter, som klienter får adgang til. Det er her det logiske niveau slutter, og det fysiske niveau begynder, fordi hver placeringsgruppe er tildelt én hoveddisk og flere replikadiske (hvor mange afhænger nøjagtigt af poolreplikeringsfaktoren). Med andre ord, på det logiske niveau er objektet gemt i en bestemt placeringsgruppe og på det fysiske niveau - på de diske, der er tildelt det. I dette tilfælde kan diskene være fysisk placeret på forskellige noder eller endda i forskellige datacentre.
I denne ordning ser anbringelsesgrupper ud som et nødvendigt niveau for fleksibiliteten i hele løsningen, men samtidig som et ekstra led i denne kæde, hvilket ufrivilligt tyder på et produktivitetstab. For eksempel, når du skriver data, skal systemet opdele dem i disse grupper og derefter på det fysiske niveau i hoveddisken og diske til replikaer. Det vil sige, at Hash-funktionen virker, når man søger og indsætter et objekt, men der er en bivirkning – det er meget høje omkostninger og restriktioner på at genopbygge hashen (når man tilføjer eller fjerner en disk). Et andet hash-problem er den tydeligt naglede placering af data, som ikke kan ændres. Det vil sige, hvis disken på en eller anden måde er under øget belastning, så har systemet ikke mulighed for ikke at skrive til den (ved at vælge en anden disk), hash-funktionen forpligter dataene til at blive lokaliseret i henhold til reglen, uanset hvor dårligt disken er, så Ceph æder meget hukommelse, når han genopbygger PG'en i tilfælde af selvhelbredelse eller øget lagring. Konklusionen er, at Ceph fungerer godt (omend langsomt), men kun når der ikke er nogen skalering, nødsituationer eller opdateringer.
Der er selvfølgelig muligheder for at øge ydeevnen gennem caching og cache-deling, men det kræver god hardware, og der vil stadig være tab. Men generelt ser Ceph mere fristende ud end Gluster for produktivitet. Når du bruger disse produkter, er det også nødvendigt at tage højde for en vigtig faktor - dette er et højt niveau af kompetence, erfaring og professionalisme med stor vægt på Linux, da det er meget vigtigt at implementere, konfigurere og vedligeholde alt korrekt, hvilket pålægger administratoren endnu mere ansvar og byrde.
Vlager
Arkitekturen ser endnu mere interessant ud , som kan bruges sammen med en hypervisor på de samme noder, på samme , men det er meget vigtigt at konfigurere alt korrekt for at opnå god ydeevne. Det vil sige, at implementere et sådant produkt fra boksen på enhver konfiguration uden at tage hensyn til anbefalingerne i overensstemmelse med arkitekturen vil være meget let, men ikke produktivt.
Hvad kan eksistere side om side for lagring ved siden af tjenesterne i kvm-qemu hypervisor, og det er blot nogle få tjenester, hvor der er fundet et kompakt optimalt hierarki af komponenter: klientservice monteret via FUSE (modificeret, ikke open source), MDS metadata service (Metadata service), service Chunk service datablokke, som på det fysiske niveau er lig med én disk og det er alt. Hastighedsmæssigt er det selvfølgelig optimalt at bruge en fejltolerant ordning med to replikaer, men hvis du bruger caching og logs på SSD-drev, så kan fejltolerant kodning (slet kodning eller raid6) pænt overclockes på en hybrid ordning eller endnu bedre på alle flash. Der er en vis ulempe ved EC (slet kodning): når du ændrer en datablok, er det nødvendigt at genberegne paritetsbeløbene. For at omgå tabene forbundet med denne operation, skriver Ceph til EC forsinket, og der kan opstå ydeevneproblemer under en bestemt anmodning, når for eksempel alle blokke skal læses, og i tilfælde af Virtuozzo Storage udføres skrivning af ændrede blokke ved hjælp af "log-struktureret filsystem" tilgang, som minimerer paritetsberegningsomkostninger. For at estimere tilnærmelsesvis mulighederne med acceleration af arbejde med og uden EC, er der – tallene kan være omtrentlige afhængigt af udstyrsproducentens nøjagtighedskoefficient, men resultatet af beregningerne er en god hjælp til planlægning af konfigurationen.
Et simpelt diagram over lagerkomponenter betyder ikke, at disse komponenter ikke absorberer men hvis du beregner alle omkostningerne på forhånd, kan du regne med samarbejde ved siden af hypervisoren.
Der er en ordning til at sammenligne forbruget af hardwareressourcer af Ceph og Virtuozzo storage-tjenester.
Hvis det tidligere var muligt at sammenligne Gluster og Ceph ved hjælp af gamle artikler ved at bruge de vigtigste linjer fra dem, så er det vanskeligere med Virtuozzo. Der er ikke mange artikler om dette produkt, og information kan kun hentes fra dokumentationen på eller på russisk, hvis vi betragter Vstorage som storage, der bruges i nogle hyperkonvergerede løsninger i virksomheder som f.eks og Acronis.
Jeg vil forsøge at hjælpe med en beskrivelse af denne arkitektur, så der kommer lidt mere tekst, men det tager meget tid at forstå dokumentationen selv, og den eksisterende dokumentation kan kun bruges som reference ved at revidere tabellen indhold eller søgning efter nøgleord.
Lad os overveje optagelsesprocessen i en hybrid hardwarekonfiguration med komponenterne beskrevet ovenfor: optagelsen begynder at gå til den node, hvorfra klienten startede den (FUSE-monteringspunkttjenesten), men Metadata Service (MDS) masterkomponenten vil selvfølgelig diriger klienten direkte til den ønskede chunk-tjeneste (storage service CS-blokke), dvs. MDS deltager ikke i optagelsesprocessen, men dirigerer blot tjenesten til den nødvendige chunk. Generelt kan vi give en analogi til optagelse med at hælde vand i tønder. Hver tønde er en 256 MB datablok.
Det vil sige, at en disk er et vist antal sådanne tønder, det vil sige diskvolumen divideret med 256MB. Hver kopi distribueres til én node, den anden næsten parallelt med en anden node osv... Hvis vi har tre replikaer, og der er SSD-diske til cache (til læsning og skrivning af logs), så vil bekræftelse af skrivning ske efter skrivning loggen til SSD'en, og parallel nulstilling fra SSD'en fortsætter på HDD'en, som i baggrunden. I tilfælde af tre replikaer vil posten blive begået efter bekræftelse fra SSD'en for den tredje node. Det kan se ud til, at summen af skrivehastigheden for tre SSD'er kan divideres med tre, og vi får skrivehastigheden for en kopi, men kopierne skrives parallelt, og netværkets Latency-hastighed er normalt højere end SSD'ens, og faktisk vil skriveydelsen afhænge af netværket. I denne forbindelse, for at se ægte IOPS, skal du indlæse hele Vstorage korrekt med , altså test af den reelle belastning, og ikke hukommelse og cache, hvor det er nødvendigt at tage højde for den korrekte datablokstørrelse, antal tråde osv.
Den ovennævnte optagelseslog på SSD'en fungerer på en sådan måde, at så snart data kommer ind i den, læses den straks af tjenesten og skrives til HDD'en. Der er flere metadatatjenester (MDS) pr. klynge, og deres antal bestemmes af et kvorum, som fungerer i henhold til Paxos-algoritmen. Fra klientens synspunkt er FUSE-monteringspunktet en cluster storage-mappe, der samtidigt er synlig for alle noder i klyngen, hver node har en monteret klient efter dette princip, så denne storage er tilgængelig for hver node.
For udførelsen af enhver af de ovenfor beskrevne tilgange er det meget vigtigt på planlægnings- og implementeringsstadiet at konfigurere netværket korrekt, hvor der vil være balancering på grund af aggregering og korrekt valgt netværkskanalbåndbredde. Ved aggregering er det vigtigt at vælge den rigtige hashing-tilstand og rammestørrelser. Der er også en meget stærk forskel fra SDS beskrevet ovenfor, dette er sikring med hurtig vej teknologi i Virtuozzo Storage. Hvilket udover den moderniserede sikring i modsætning til andre open source-løsninger øger IOPS markant og gør, at du ikke bliver begrænset af horisontal eller vertikal skalering. Generelt, sammenlignet med de ovenfor beskrevne arkitekturer, ser denne mere kraftfuld ud, men for en sådan fornøjelse skal du selvfølgelig købe licenser i modsætning til Ceph og Gluster.
For at opsummere kan vi fremhæve toppen af de tre: Virtuozzo Storage indtager førstepladsen med hensyn til ydeevne og pålidelighed af arkitekturen, Ceph indtager andenpladsen, og Gluster indtager tredjepladsen.
Kriterierne for, at Virtuozzo Storage blev valgt: det er et optimalt sæt af arkitektoniske komponenter, moderniseret til denne Fuse-tilgang med hurtig vej, et fleksibelt sæt hardwarekonfigurationer, mindre ressourceforbrug og evnen til at dele med computere (computing/virtualisering), det vil sige, at den er fuldstændig egnet til en hyperkonvergeret løsning, som han er en del af. Andenpladsen er Ceph, fordi det er en mere produktiv arkitektur sammenlignet med Gluster, på grund af dens drift i blokke, samt mere fleksible scenarier og evnen til at arbejde i større klynger.
Der er planer om at skrive en sammenligning mellem vSAN, Space Direct Storage, Vstorage og Nutanix Storage, test af Vstorage på HPE- og Huawei-udstyr, samt scenarier for integration af Vstorage med eksterne hardware-lagringssystemer, så hvis du kunne lide artiklen, ville det være rart at få feedback fra dig, hvilket kunne øge motivationen for nye artikler, under hensyntagen til dine kommentarer og ønsker.
Kilde: www.habr.com