Den här artikeln skrevs för att hjälpa dig att välja rätt lösning för dig själv och förstå skillnaderna mellan SDS som Gluster, Ceph och Vstorage (Virtuozzo).
Texten använder länkar till artiklar med en mer detaljerad beskrivning av vissa problem, så beskrivningarna blir så korta som möjligt, med nyckelpunkter utan onödigt fluff och inledande information som du kan, om du vill, självständigt skaffa på Internet.
Faktum är att naturligtvis de ämnen som tas upp kräver tonerna i texten, men i den moderna världen gillar fler och fler inte att läsa mycket))), så du kan snabbt läsa och göra ett val, och om något är inte klart, följ länkarna eller googla på oklara ord))), och den här artikeln är som ett genomskinligt omslag för dessa djupa ämnen, som visar fyllningen - de viktigaste nyckelpunkterna i varje beslut.
Glans
Låt oss börja med Gluster, som aktivt används av tillverkare av hyperkonvergerade plattformar med SDS baserade på öppen källkod för virtuella miljöer och som finns på RedHats webbplats i lagringssektionen, där du kan välja mellan två SDS-alternativ: Gluster eller Ceph.
Gluster består av en stapel översättare - tjänster som utför allt arbete med att distribuera filer osv. Brick är en tjänst som servar en disk, Volym är en volym (pool) som förenar dessa klossar. Därefter kommer tjänsten för att distribuera filer i grupper med funktionen DHT (distributed hash table). Vi kommer inte att inkludera Sharding-tjänsten i beskrivningen eftersom länkarna nedan kommer att beskriva problemen förknippade med den.
Vid skrivning lagras hela filen i tegel och dess kopia skrivs samtidigt till tegel på den andra servern. Därefter kommer den andra filen att skrivas till den andra gruppen med två block (eller fler) på olika servrar.
Om filerna är ungefär lika stora och volymen bara består av en grupp, är allt bra, men under andra förhållanden kommer följande problem att uppstå från beskrivningarna:
- utrymme i grupper utnyttjas ojämnt, det beror på storleken på filerna och om det inte finns tillräckligt med utrymme i gruppen för att skriva en fil kommer du att få ett felmeddelande, filen kommer inte att skrivas och kommer inte att omdistribueras till en annan grupp ;
- när du skriver en fil går IO bara till en grupp, resten är inaktiva;
- du kan inte få IO för hela volymen när du skriver en fil;
- och det allmänna konceptet ser mindre produktivt ut på grund av bristen på datadistribution i block, där det är lättare att balansera och lösa problemet med enhetlig distribution, och inte som nu hela filen går i ett block.
Från den officiella beskrivningen vi kommer också ofrivilligt till insikten att gluster fungerar som fillagring ovanpå klassisk hårdvaru-RAID. Det har gjorts utvecklingsförsök att klippa (Sharding) filer i block, men allt detta är ett tillägg som medför prestandaförluster på den redan existerande arkitektoniska metoden, plus användningen av sådana fritt distribuerade komponenter med prestandabegränsningar som Fuse. Det finns inga metadatatjänster, vilket begränsar lagringens prestanda och feltoleransmöjligheter vid distribution av filer i block. Bättre prestandaindikatorer kan observeras med "Distributed Replicated"-konfigurationen och antalet noder bör vara minst 6 för att organisera en pålitlig replika 3 med optimal lastfördelning.
Dessa fynd är också relaterade till beskrivningen av användarupplevelsen och jämfört med , och det finns också en beskrivning av erfarenheten som leder till en förståelse för denna mer produktiva och mer tillförlitliga konfiguration
Bilden visar belastningsfördelningen vid skrivning av två filer, där kopior av den första filen distribueras över de tre första servrarna, som kombineras till volym 0-gruppen, och tre kopior av den andra filen placeras på den andra gruppen volym1 av tre servrar. Varje server har en disk.
Den allmänna slutsatsen är att du kan använda Gluster, men med insikten att det kommer att finnas begränsningar i prestanda och feltolerans som skapar svårigheter under vissa förhållanden för en hyperkonvergerad lösning, där resurser också behövs för datorbelastningen i virtuella miljöer.
Det finns också några Gluster-prestandaindikatorer som kan uppnås under vissa förhållanden, begränsade till
Ceph
Låt oss nu titta på Ceph från de arkitekturbeskrivningar som jag kunde Det finns också en jämförelse mellan , där du omedelbart kan förstå att det är tillrådligt att distribuera Ceph på separata servrar, eftersom dess tjänster kräver alla hårdvaruresurser under belastning.
Arkitektur mer komplex än Gluster och det finns tjänster som metadatatjänster, men hela stacken av komponenter är ganska komplex och inte särskilt flexibel för att använda den i en virtualiseringslösning. Data lagras i block, vilket ser mer produktivt ut, men i hierarkin av alla tjänster (komponenter) finns det förluster och latens under vissa belastningar och nödsituationer, till exempel följande
Från beskrivningen av arkitekturen är hjärtat CRUSH, tack vare vilket platsen för lagring av data väljs. Därefter kommer PG - detta är den svåraste abstraktionen (logisk grupp) att förstå. PG:er behövs för att göra CRUSH mer effektivt. Huvudsyftet med PG är att gruppera objekt för att minska resursförbrukning, öka prestanda och skalbarhet. Att adressera objekt direkt, individuellt, utan att kombinera dem till en PG skulle bli mycket dyrt. OSD är en tjänst för varje enskild disk.
Ett kluster kan ha en eller flera datapooler för olika ändamål och med olika inställningar. Poolerna är indelade i placeringsgrupper. Placeringsgrupper lagrar objekt som klienter kommer åt. Det är här den logiska nivån slutar och den fysiska nivån börjar, eftersom varje placeringsgrupp tilldelas en huvuddisk och flera replikdiskar (hur många exakt beror på poolreplikeringsfaktorn). Med andra ord, på den logiska nivån lagras objektet i en specifik placeringsgrupp och på den fysiska nivån - på de diskar som är tilldelade det. I det här fallet kan diskarna vara fysiskt placerade på olika noder eller till och med i olika datacenter.
I detta schema ser placeringsgrupper ut som en nödvändig nivå för flexibiliteten i hela lösningen, men samtidigt som en extra länk i denna kedja, vilket ofrivilligt antyder en produktivitetsförlust. Till exempel, när du skriver data måste systemet dela upp det i dessa grupper och sedan på den fysiska nivån i huvuddisken och diskar för repliker. Det vill säga, Hash-funktionen fungerar när man söker och sätter in ett objekt, men det finns en bieffekt – det är väldigt höga kostnader och restriktioner för att bygga om hashen (när man lägger till eller tar bort en disk). Ett annat hashproblem är den tydligt spikade platsen för data som inte kan ändras. Det vill säga, om disken på något sätt är under ökad belastning, då systemet inte har möjlighet att inte skriva till den (genom att välja en annan disk), hashfunktionen tvingar data att lokaliseras enligt regeln, oavsett hur dåligt disken är det, så Ceph äter mycket minne när han bygger om PG:n i händelse av självläkning eller ökad lagring. Slutsatsen är att Ceph fungerar bra (om än långsamt), men bara när det inte finns någon skalning, nödsituationer eller uppdateringar.
Det finns givetvis alternativ för att öka prestandan genom cachning och cachedelning, men detta kräver bra hårdvara och det blir fortfarande förluster. Men totalt sett ser Ceph mer lockande ut än Gluster för produktivitet. När du använder dessa produkter är det också nödvändigt att ta hänsyn till en viktig faktor - detta är en hög nivå av kompetens, erfarenhet och professionalism med stor tonvikt på Linux, eftersom det är mycket viktigt att distribuera, konfigurera och underhålla allt korrekt, vilket medför ännu mer ansvar och börda på handläggaren.
Vlagring
Arkitekturen ser ännu mer intressant ut , som kan användas tillsammans med en hypervisor på samma noder, på samma , men det är mycket viktigt att konfigurera allt korrekt för att uppnå bra prestanda. Det vill säga att distribuera en sådan produkt från lådan på vilken konfiguration som helst utan att ta hänsyn till rekommendationerna i enlighet med arkitekturen kommer att vara mycket enkelt, men inte produktivt.
Vad kan samexistera för lagring bredvid tjänsterna i kvm-qemu hypervisor, och dessa är bara några tjänster där en kompakt optimal hierarki av komponenter har hittats: klienttjänst monterad via FUSE (modifierad, inte öppen källkod), MDS-metadatatjänst (Metadatatjänst), tjänst Chunk-tjänstdatablock, som på fysisk nivå är lika med en disk och det är allt. Hastighetsmässigt är det förstås optimalt att använda ett feltolerant schema med två repliker, men om du använder cachning och loggar på SSD-enheter så kan feltolerant kodning (radera kodning eller raid6) hyggligt överklockas på en hybridschema eller ännu bättre på all flash. Det finns en viss nackdel med EC (raderingskodning): när du ändrar ett datablock är det nödvändigt att räkna om paritetsbeloppen. För att kringgå förlusterna som är förknippade med denna operation skriver Ceph till EC på ett uppskjutet sätt och prestandaproblem kan uppstå under en viss begäran, när till exempel alla block behöver läsas, och i fallet med Virtuozzo Storage, skriver ändrade block utförs med hjälp av metoden "loggstrukturerat filsystem", vilket minimerar paritetsberäkningskostnaderna. För att uppskatta ungefär alternativen med acceleration av arbete med och utan EC, det finns – siffrorna kan vara ungefärliga beroende på utrustningstillverkarens noggrannhetskoefficient, men resultatet av beräkningarna är till god hjälp vid planering av konfigurationen.
Ett enkelt diagram över lagringskomponenter betyder inte att dessa komponenter inte absorberar men om du beräknar alla kostnader i förväg kan du räkna med samarbete bredvid hypervisorn.
Det finns ett schema för att jämföra förbrukningen av hårdvaruresurser av Ceph och Virtuozzo lagringstjänster.
Om det tidigare var möjligt att jämföra Gluster och Ceph med gamla artiklar, med de viktigaste raderna från dem, så är det svårare med Virtuozzo. Det finns inte många artiklar om denna produkt och information kan endast hämtas från dokumentationen på eller på ryska om vi betraktar Vstorage som lagring som används i vissa hyperkonvergerade lösningar i företag som t.ex och Acronis.
Jag ska försöka hjälpa till med en beskrivning av denna arkitektur, så det blir lite mer text, men det tar mycket tid att förstå dokumentationen själv, och den befintliga dokumentationen kan endast användas som referens genom att revidera tabellen innehåll eller sökning med nyckelord.
Låt oss överväga inspelningsprocessen i en hybridhårdvarukonfiguration med komponenterna som beskrivs ovan: inspelningen börjar gå till noden från vilken klienten initierade den (FUSE-monteringspunktstjänsten), men Metadata Service (MDS) masterkomponenten kommer naturligtvis att dirigera klienten direkt till den önskade chunktjänsten (lagringstjänst CS-block), det vill säga MDS deltar inte i inspelningsprocessen, utan dirigerar helt enkelt tjänsten till den önskade chunken. I allmänhet kan vi ge en analogi till inspelning med att hälla vatten i fat. Varje fat är ett 256 MB datablock.
Det vill säga att en disk är ett visst antal sådana fat, det vill säga diskvolymen dividerat med 256MB. Varje kopia distribueras till en nod, den andra nästan parallellt med en annan nod, etc... Om vi har tre repliker och det finns SSD-diskar för cache (för att läsa och skriva loggar), så kommer bekräftelse av skrivningen att ske efter skrivning loggen till SSD, och parallell återställning från SSD kommer att fortsätta på hårddisken, som i bakgrunden. I fallet med tre repliker kommer posten att utföras efter bekräftelse från SSD:n för den tredje noden. Det kan tyckas som om summan av skrivhastigheten för tre SSD-enheter kan delas med tre och vi kommer att få skrivhastigheten för en kopia, men kopiorna skrivs parallellt och nätverkets Latency-hastighet är vanligtvis högre än SSD:n, och i själva verket kommer skrivprestandan att bero på nätverket. I detta avseende, för att se riktig IOPS, måste du ladda hela Vstorage korrekt med , det vill säga testa den verkliga belastningen, och inte minne och cache, där det är nödvändigt att ta hänsyn till korrekt datablockstorlek, antal trådar, etc.
Den ovan nämnda inspelningsloggen på SSD:n fungerar på ett sådant sätt att så fort data kommer in i den läses den omedelbart av tjänsten och skrivs till hårddisken. Det finns flera metadatatjänster (MDS) per kluster och deras antal bestäms av ett kvorum, som fungerar enligt Paxos-algoritmen. Ur klientens synvinkel är FUSE-monteringspunkten en klusterlagringsmapp som samtidigt är synlig för alla noder i klustret, varje nod har en monterad klient enligt denna princip, så denna lagring är tillgänglig för varje nod.
För prestanda för någon av de ovan beskrivna tillvägagångssätten är det mycket viktigt, i planerings- och distributionsstadiet, att korrekt konfigurera nätverket, där det kommer att finnas balansering på grund av aggregering och korrekt vald nätverkskanalbandbredd. Vid aggregering är det viktigt att välja rätt hashläge och ramstorlekar. Det finns också en mycket stark skillnad mot SDS som beskrivs ovan, detta är en säkring med snabb vägsteknologi i Virtuozzo Storage. Som, förutom den moderniserade säkringen, till skillnad från andra lösningar med öppen källkod, avsevärt ökar IOPS och låter dig inte begränsas av horisontell eller vertikal skalning. I allmänhet, jämfört med de ovan beskrivna arkitekturerna, ser den här mer kraftfull ut, men för ett sådant nöje måste du naturligtvis köpa licenser, till skillnad från Ceph och Gluster.
För att sammanfatta kan vi lyfta fram toppen av de tre: Virtuozzo Storage tar förstaplatsen när det gäller prestanda och tillförlitlighet hos arkitekturen, Ceph tar andraplatsen och Gluster tar tredjeplatsen.
Kriterierna för vilka Virtuozzo Storage valdes: det är en optimal uppsättning arkitektoniska komponenter, moderniserad för denna Fuse-metod med snabb väg, en flexibel uppsättning hårdvarukonfigurationer, mindre resursförbrukning och förmågan att dela med datorer (beräkning/virtualisering), det vill säga den är helt lämplig för en hyperkonvergerad lösning, som han är en del av. Andra plats är Ceph eftersom det är en mer produktiv arkitektur jämfört med Gluster, på grund av dess drift i block, samt mer flexibla scenarier och förmågan att arbeta i större kluster.
Det finns planer på att skriva en jämförelse mellan vSAN, Space Direct Storage, Vstorage och Nutanix Storage, testa Vstorage på HPE- och Huawei-utrustning, samt scenarier för att integrera Vstorage med externa hårdvarulagringssystem, så om du gillade artikeln skulle det vara trevligt att få feedback från dig, vilket skulle kunna öka motivationen för nya artiklar, med hänsyn till dina kommentarer och önskemål.
Källa: will.com