Denne artikkelen ble skrevet for å hjelpe deg med å velge den riktige løsningen for deg selv og forstå forskjellene mellom SDS som Gluster, Ceph og Vstorage (Virtuozzo).
Teksten bruker lenker til artikler med en mer detaljert avsløring av visse problemer, slik at beskrivelsene blir så korte som mulig, med nøkkelpunkter uten unødvendig fluff og introduksjonsinformasjon som du kan, hvis du ønsker, selvstendig skaffe på Internett.
Faktisk krever emnene som tas opp tekstens toner, men i den moderne verden liker flere og flere ikke å lese mye))), så du kan raskt lese og ta et valg, og hvis noe er ikke klart, følg lenkene eller google uklare ord))), og denne artikkelen er som en gjennomsiktig innpakning for disse dype emnene, og viser fyllingen - de viktigste nøkkelpunktene i hver beslutning.
Glans
La oss starte med Gluster, som brukes aktivt av produsenter av hyperkonvergerte plattformer med SDS basert på åpen kildekode for virtuelle miljøer og kan finnes på RedHats nettside i lagringsdelen, hvor du kan velge mellom to SDS-alternativer: Gluster eller Ceph.
Gluster består av en stabel med oversettere - tjenester som utfører alt arbeidet med å distribuere filer osv. Brick er en tjeneste som betjener én disk, Volume er et volum (pool) som forener disse klossene. Deretter kommer tjenesten for å distribuere filer i grupper ved å bruke funksjonen DHT (distribuert hashtabell). Vi vil ikke inkludere Sharding-tjenesten i beskrivelsen siden lenkene nedenfor vil beskrive problemene knyttet til den.
Når du skriver, lagres hele filen i kloss og kopien skrives samtidig til kloss på den andre serveren. Deretter vil den andre filen bli skrevet til den andre gruppen med to klosser (eller flere) på forskjellige servere.
Hvis filene er omtrent like store og volumet består av bare én gruppe, er alt i orden, men under andre forhold vil følgende problemer oppstå fra beskrivelsene:
- plass i grupper utnyttes ujevnt, det avhenger av størrelsen på filene og hvis det ikke er nok plass i gruppen til å skrive en fil, vil du få en feilmelding, filen vil ikke bli skrevet og vil ikke bli omdistribuert til en annen gruppe ;
- når du skriver en fil, går IO bare til en gruppe, resten er inaktive;
- du kan ikke få IO av hele volumet når du skriver én fil;
- og det generelle konseptet ser mindre produktivt ut på grunn av mangelen på datadistribusjon i blokker, hvor det er lettere å balansere og løse problemet med enhetlig distribusjon, og ikke som nå hele filen går inn i en blokk.
Fra den offisielle beskrivelsen vi kommer også ufrivillig til den forståelsen at gluster fungerer som fillagring på toppen av klassisk hardware RAID. Det har vært utviklingsforsøk på å kutte (Sharding) filer i blokker, men alt dette er et tillegg som påfører ytelsestap på den allerede eksisterende arkitektoniske tilnærmingen, pluss bruken av slike fritt distribuerte komponenter med ytelsesbegrensninger som Fuse. Det er ingen metadatatjenester, noe som begrenser ytelsen og feiltoleransen til lagringen ved distribusjon av filer i blokker. Bedre ytelsesindikatorer kan observeres med "Distributed Replicated"-konfigurasjonen, og antall noder bør være minst 6 for å organisere en pålitelig replika 3 med optimal lastfordeling.
Disse funnene er også relatert til beskrivelsen av brukeropplevelsen og sammenlignet med , og det er også en beskrivelse av opplevelsen som fører til en forståelse av denne mer produktive og mer pålitelige konfigurasjonen
Bildet viser lastfordelingen ved skriving av to filer, hvor kopier av den første filen er fordelt på de tre første serverne, som er kombinert i volum 0-gruppen, og tre kopier av den andre filen er plassert på den andre gruppen, volum1 av tre servere. Hver server har én disk.
Den generelle konklusjonen er at du kan bruke Gluster, men med den forståelsen at det vil være begrensninger i ytelse og feiltoleranse som skaper vanskeligheter under visse forhold for en hyperkonvergert løsning, hvor det også trengs ressurser for databelastningen i virtuelle miljøer.
Det er også noen Gluster-ytelsesindikatorer som kan oppnås under visse forhold, begrenset til
ceph
La oss nå se på Ceph fra arkitekturbeskrivelsene som jeg var i stand til Det er også en sammenligning mellom , hvor du umiddelbart kan forstå at det er tilrådelig å distribuere Ceph på separate servere, siden tjenestene krever alle maskinvareressursene under belastning.
arkitektur mer kompleks enn Gluster og det finnes tjenester som metadatatjenester, men hele stabelen med komponenter er ganske kompleks og lite fleksibel for å bruke den i en virtualiseringsløsning. Dataene er lagret i blokker, som ser mer produktive ut, men i hierarkiet av alle tjenester (komponenter) er det tap og latens under visse belastninger og nødforhold, for eksempel følgende
Fra beskrivelsen av arkitekturen er hjertet CRUSH, takket være hvilken plassering for lagring av data er valgt. Deretter kommer PG - dette er den vanskeligste abstraksjonen (logisk gruppe) å forstå. PG-er er nødvendig for å gjøre CRUSH mer effektiv. Hovedformålet med PG er å gruppere objekter for å redusere ressursforbruket, øke ytelsen og skalerbarheten. Å adressere objekter direkte, individuelt, uten å kombinere dem til en PG vil være veldig dyrt. OSD er en tjeneste for hver enkelt disk.
En klynge kan ha en eller flere datapooler for forskjellige formål og med forskjellige innstillinger. Puljene er delt inn i plasseringsgrupper. Plasseringsgrupper lagrer objekter som klienter får tilgang til. Det er her det logiske nivået slutter, og det fysiske nivået begynner, fordi hver plasseringsgruppe er tildelt én hoveddisk og flere replikadisker (hvor mange nøyaktig avhenger av poolreplikeringsfaktoren). Med andre ord, på det logiske nivået er objektet lagret i en bestemt plasseringsgruppe, og på det fysiske nivået - på diskene som er tilordnet det. I dette tilfellet kan diskene være fysisk plassert på forskjellige noder eller til og med i forskjellige datasentre.
I denne ordningen ser plasseringsgrupper ut som et nødvendig nivå for fleksibiliteten i hele løsningen, men samtidig som et ekstra ledd i denne kjeden, noe som ufrivillig antyder produktivitetstap. For eksempel, når du skriver data, må systemet dele dem inn i disse gruppene og deretter på det fysiske nivået i hoveddisken og disker for replikaer. Det vil si at Hash-funksjonen fungerer når man søker og setter inn et objekt, men det er en bieffekt – det er svært høye kostnader og restriksjoner på å gjenoppbygge hashen (når man legger til eller fjerner en disk). Et annet hash-problem er den tydelig spikrete plasseringen av data som ikke kan endres. Det vil si at hvis disken på en eller annen måte er under økt belastning, så har ikke systemet muligheten til å ikke skrive til den (ved å velge en annen disk), hash-funksjonen forplikter dataene til å bli lokalisert i henhold til regelen, uansett hvor dårlig disken er det, så Ceph spiser mye minne når han bygger om PG i tilfelle selvhelbredelse eller økende lagring. Konklusjonen er at Ceph fungerer bra (om enn sakte), men bare når det ikke er skalering, nødsituasjoner eller oppdateringer.
Det finnes selvfølgelig muligheter for å øke ytelsen gjennom caching og cache-deling, men dette krever god maskinvare og det vil fortsatt være tap. Men totalt sett ser Ceph mer fristende ut enn Gluster for produktivitet. Også når du bruker disse produktene, er det nødvendig å ta hensyn til en viktig faktor - dette er et høyt nivå av kompetanse, erfaring og profesjonalitet med stor vekt på Linux, siden det er veldig viktig å distribuere, konfigurere og vedlikeholde alt riktig, som pålegger administratoren enda mer ansvar og byrder.
Vlagring
Arkitekturen ser enda mer interessant ut , som kan brukes sammen med en hypervisor på de samme nodene, på den samme , men det er veldig viktig å konfigurere alt riktig for å oppnå god ytelse. Det vil si at å distribuere et slikt produkt fra esken på en hvilken som helst konfigurasjon uten å ta hensyn til anbefalingene i samsvar med arkitekturen vil være veldig enkelt, men ikke produktivt.
Hva kan eksistere side om side for lagring ved siden av tjenestene til kvm-qemu hypervisor, og dette er bare noen få tjenester der det er funnet et kompakt optimalt hierarki av komponenter: klienttjeneste montert via FUSE (modifisert, ikke åpen kildekode), MDS-metadatatjeneste (Metadatatjeneste), tjeneste Chunk-tjenestedatablokker, som på det fysiske nivået er lik en disk og det er alt. Hastighetsmessig er det selvsagt optimalt å bruke et feiltolerant opplegg med to replikaer, men hvis du bruker caching og logger på SSD-stasjoner, så kan feiltolerant koding (slett koding eller raid6) overklokkes anstendig på en hybrid ordning eller enda bedre på all flash. Det er noen ulemper med EC (slettekoding): når du endrer en datablokk, er det nødvendig å beregne paritetsbeløpene på nytt. For å omgå tapene knyttet til denne operasjonen, skriver Ceph til EC utsatt og ytelsesproblemer kan oppstå under en bestemt forespørsel, når for eksempel alle blokker må leses, og i tilfellet med Virtuozzo Storage, skrives endrede blokker ved å bruke "logg-strukturert filsystem"-tilnærmingen, som minimerer paritetsberegningskostnadene. For å estimere tilnærmet alternativene med akselerasjon av arbeid med og uten EC, er det – tallene kan være omtrentlige avhengig av nøyaktighetskoeffisienten til utstyrsprodusenten, men resultatet av beregningene er til god hjelp i planleggingen av konfigurasjonen.
Et enkelt diagram over lagringskomponenter betyr ikke at disse komponentene ikke absorberer men hvis du beregner alle kostnadene på forhånd, kan du regne med samarbeid ved siden av hypervisoren.
Det er en ordning for å sammenligne forbruket av maskinvareressurser til Ceph og Virtuozzo lagringstjenester.
Hvis det tidligere var mulig å sammenligne Gluster og Ceph ved å bruke gamle artikler, ved å bruke de viktigste linjene fra dem, så er det vanskeligere med Virtuozzo. Det er ikke mange artikler om dette produktet, og informasjon kan kun hentes fra dokumentasjonen på eller på russisk hvis vi anser Vstorage som lagring som brukes i noen hyperkonvergerte løsninger i selskaper som f.eks og Acronis.
Jeg skal prøve å hjelpe med en beskrivelse av denne arkitekturen, så det blir litt mer tekst, men det tar mye tid å forstå dokumentasjonen selv, og den eksisterende dokumentasjonen kan kun brukes som referanse ved å revidere tabellen av innhold eller søk etter nøkkelord.
La oss vurdere opptaksprosessen i en hybrid maskinvarekonfigurasjon med komponentene beskrevet ovenfor: opptaket begynner å gå til noden som klienten startet den fra (FUSE-monteringspunkttjenesten), men Metadata Service (MDS) masterkomponenten vil selvfølgelig diriger klienten direkte til ønsket chunk-tjeneste (lagringstjeneste CS-blokker), det vil si at MDS ikke deltar i opptaksprosessen, men sender rett og slett tjenesten til den nødvendige chunken. Generelt kan vi gi en analogi til opptak med å helle vann i fat. Hver tønne er en 256 MB datablokk.
Det vil si at én disk er et visst antall slike fat, det vil si diskvolumet delt på 256MB. Hver kopi distribueres til en node, den andre nesten parallelt med en annen node osv... Hvis vi har tre replikaer og det er SSD-disker for cache (for lesing og skriving av logger), så vil bekreftelse av skrivingen skje etter skriving loggen til SSD-en, og parallell tilbakestilling fra SSD-en fortsetter på HDD-en, som i bakgrunnen. I tilfelle av tre replikaer, vil posten bli begått etter bekreftelse fra SSD-en til den tredje noden. Det kan virke som om summen av skrivehastigheten til tre SSD-er kan deles på tre, og vi vil få skrivehastigheten til en kopi, men kopiene skrives parallelt og nettverkets latenshastighet er vanligvis høyere enn SSD-en, og faktisk vil skriveytelsen avhenge av nettverket. I denne forbindelse, for å se ekte IOPS, må du laste inn hele Vstorage på riktig måte , det vil si å teste den virkelige belastningen, og ikke minne og cache, der det er nødvendig å ta hensyn til riktig datablokkstørrelse, antall tråder osv.
Den ovennevnte opptaksloggen på SSD-en fungerer på en slik måte at så snart data kommer inn i den, blir den umiddelbart lest av tjenesten og skrevet til HDD-en. Det er flere metadatatjenester (MDS) per klynge, og antallet bestemmes av et quorum, som fungerer i henhold til Paxos-algoritmen. Fra klientens synspunkt er FUSE-monteringspunktet en klyngelagringsmappe som samtidig er synlig for alle noder i klyngen, hver node har en montert klient i henhold til dette prinsippet, så denne lagringen er tilgjengelig for hver node.
For ytelsen til noen av de ovenfor beskrevne tilnærmingene er det svært viktig, på planleggings- og distribusjonsstadiet, å konfigurere nettverket riktig, der det vil være balansering på grunn av aggregering og riktig valgt nettverkskanalbåndbredde. Ved aggregering er det viktig å velge riktig hashing-modus og rammestørrelser. Det er også en veldig sterk forskjell fra SDS beskrevet ovenfor, dette er sikring med fast path-teknologi i Virtuozzo Storage. Som i tillegg til den moderniserte sikringen, i motsetning til andre åpen kildekode-løsninger, øker IOPS betydelig og lar deg ikke begrenses av horisontal eller vertikal skalering. Generelt, sammenlignet med arkitekturene beskrevet ovenfor, ser denne kraftigere ut, men for en slik glede må du selvfølgelig kjøpe lisenser, i motsetning til Ceph og Gluster.
For å oppsummere kan vi trekke frem toppen av de tre: Virtuozzo Storage tar førsteplassen når det gjelder ytelse og pålitelighet av arkitekturen, Ceph tar andreplassen, og Gluster tar tredjeplassen.
Kriteriene som Virtuozzo Storage ble valgt etter: det er et optimalt sett med arkitektoniske komponenter, modernisert for denne Fuse-tilnærmingen med rask vei, et fleksibelt sett med maskinvarekonfigurasjoner, mindre ressursforbruk og muligheten til å dele med databehandling (databehandling/virtualisering), det vil si at den er helt egnet for en hyperkonvergert løsning , som han er en del av. Andreplass er Ceph fordi det er en mer produktiv arkitektur sammenlignet med Gluster, på grunn av driften i blokker, samt mer fleksible scenarier og evnen til å jobbe i større klynger.
Det er planer om å skrive en sammenligning mellom vSAN, Space Direct Storage, Vstorage og Nutanix Storage, testing av Vstorage på HPE- og Huawei-utstyr, samt scenarier for å integrere Vstorage med eksterne maskinvarelagringssystemer, så hvis du likte artikkelen, ville det vært hyggelig å få tilbakemeldinger fra deg, som kan øke motivasjonen for nye artikler, tatt i betraktning dine kommentarer og ønsker.
Kilde: www.habr.com