Dit artikel is geschreven om u te helpen de juiste oplossing voor uzelf te kiezen en de verschillen tussen SDS zoals Gluster, Ceph en Vstorage (Virtuozzo) te begrijpen.
De tekst maakt gebruik van links naar artikelen met een meer gedetailleerde beschrijving van bepaalde problemen, dus de beschrijvingen zullen zo kort mogelijk zijn, waarbij de belangrijkste punten worden gebruikt zonder onnodige flauwekul en inleidende informatie die u, als u dat wenst, zelfstandig op internet kunt verkrijgen.
In feite vereisen de onderwerpen die aan de orde komen natuurlijk de tonen van de tekst, maar in de moderne wereld houden steeds meer mensen er niet van om veel te lezen))), zodat je snel kunt lezen en een keuze kunt maken, en als er iets is niet duidelijk, volg de links of google onduidelijke woorden))), en dit artikel is als een transparante verpakking voor deze diepgaande onderwerpen, die de vulling laat zien - de belangrijkste kernpunten van elke beslissing.
gluren
Laten we beginnen met Gluster, dat actief wordt gebruikt door fabrikanten van hyperconverged platforms met SDS op basis van open source voor virtuele omgevingen en te vinden is op de website van RedHat in het opslaggedeelte, waar je kunt kiezen uit twee SDS-opties: Gluster of Ceph.
Gluster bestaat uit een stapel vertalers - diensten die al het werk uitvoeren van het distribueren van bestanden, enz. Brick is een dienst die één schijf bedient. Volume is een volume (pool) dat deze stenen verenigt. Vervolgens komt de service voor het distribueren van bestanden in groepen met behulp van de DHT-functie (gedistribueerde hashtabel). We zullen de Sharding-service niet opnemen in de beschrijving, omdat de onderstaande links de problemen beschrijven die ermee gepaard gaan.
Bij het schrijven wordt het volledige bestand in brick opgeslagen en wordt de kopie ervan tegelijkertijd naar brick op de tweede server geschreven. Vervolgens wordt het tweede bestand naar de tweede groep van twee stenen (of meer) op verschillende servers geschreven.
Als de bestanden ongeveer even groot zijn en het volume uit slechts één groep bestaat, dan is alles in orde, maar onder andere omstandigheden zullen de volgende problemen voortvloeien uit de beschrijvingen:
- de ruimte in groepen wordt ongelijkmatig gebruikt, dit hangt af van de grootte van de bestanden en als er niet genoeg ruimte in de groep is om een bestand te schrijven, krijgt u een foutmelding: het bestand wordt niet geschreven en wordt niet opnieuw gedistribueerd naar een andere groep ;
- bij het schrijven van één bestand gaat IO slechts naar één groep, de rest is inactief;
- je kunt geen IO van het hele volume krijgen als je één bestand schrijft;
- en het algemene concept ziet er minder productief uit vanwege het gebrek aan datadistributie in blokken, waar het gemakkelijker is om het probleem van uniforme distributie in evenwicht te brengen en op te lossen, en niet zoals nu het hele bestand in een blok gaat.
Uit de officiële beschrijving we komen ook onvrijwillig tot het inzicht dat gluster werkt als bestandsopslag bovenop klassieke hardware RAID. Er zijn ontwikkelingspogingen geweest om bestanden in blokken te knippen (Sharding), maar dit alles is een toevoeging die prestatieverlies oplegt aan de reeds bestaande architecturale aanpak, plus het gebruik van vrij gedistribueerde componenten met prestatiebeperkingen als Fuse. Er zijn geen metadataservices, die de prestaties en fouttolerantiemogelijkheden van de opslag beperken bij het distribueren van bestanden in blokken. Betere prestatie-indicatoren kunnen worden waargenomen met de “Distributed Replicated”-configuratie en het aantal knooppunten moet minimaal 6 zijn om een betrouwbare replica 3 met optimale belastingverdeling te organiseren.
Deze bevindingen hebben ook betrekking op de beschrijving van de gebruikerservaring en wanneer vergeleken met , en er is ook een beschrijving van de ervaring die heeft geleid tot inzicht in deze productievere en betrouwbaardere configuratie
De afbeelding toont de belastingsverdeling bij het schrijven van twee bestanden, waarbij kopieën van het eerste bestand worden verdeeld over de eerste drie servers, die worden gecombineerd in de volume 0-groep, en drie kopieën van het tweede bestand worden geplaatst op het tweede groepsvolume1 van drie servers. Elke server heeft één schijf.
De algemene conclusie is dat u Gluster kunt gebruiken, maar met dien verstande dat er beperkingen in de prestaties en fouttolerantie zullen zijn die problemen veroorzaken onder bepaalde omstandigheden van een hypergeconvergeerde oplossing, waarbij bronnen ook nodig zijn voor de computerbelasting van virtuele omgevingen.
Er zijn ook enkele Gluster-prestatie-indicatoren die onder bepaalde omstandigheden kunnen worden bereikt, beperkt tot
Ceph
Laten we nu naar Ceph kijken aan de hand van de architectuurbeschrijvingen die ik heb kunnen maken Er is ook een vergelijking tussen , waar u meteen begrijpt dat het raadzaam is om Ceph op afzonderlijke servers te implementeren, omdat de services alle hardwarebronnen onder belasting vereisen.
Architectuur complexer dan Gluster en er zijn diensten zoals metadatadiensten, maar de hele stapel componenten is behoorlijk complex en niet erg flexibel om deze in een virtualisatie-oplossing te gebruiken. De gegevens worden opgeslagen in blokken, wat er productiever uitziet, maar in de hiërarchie van alle services (componenten) zijn er verliezen en latentie onder bepaalde belastingen en noodsituaties, bijvoorbeeld de volgende
Uit de beschrijving van de architectuur is CRUSH het hart, waardoor de locatie voor het opslaan van gegevens wordt geselecteerd. Vervolgens komt PG - dit is de moeilijkste abstractie (logische groep) om te begrijpen. PG’s zijn nodig om CRUSH effectiever te maken. Het belangrijkste doel van PG is om objecten te groeperen om het resourceverbruik te verminderen, de prestaties en schaalbaarheid te verbeteren. Het rechtstreeks en afzonderlijk adresseren van objecten, zonder ze in een PG te combineren, zou erg duur zijn. OSD is een service voor elke afzonderlijke schijf.
Een cluster kan één of meerdere datapools hebben voor verschillende doeleinden en met verschillende instellingen. Pools zijn onderverdeeld in plaatsingsgroepen. Plaatsingsgroepen slaan objecten op waartoe clients toegang hebben. Dit is waar het logische niveau eindigt en het fysieke niveau begint, omdat aan elke plaatsingsgroep één hoofdschijf en meerdere replicaschijven wordt toegewezen (hoeveel hangt er precies af van de replicatiefactor van de pool). Met andere woorden: op logisch niveau wordt het object opgeslagen in een specifieke plaatsingsgroep, en op fysiek niveau - op de schijven die eraan zijn toegewezen. In dit geval kunnen de schijven zich fysiek op verschillende knooppunten of zelfs in verschillende datacenters bevinden.
In dit schema zien plaatsingsgroepen eruit als een noodzakelijk niveau voor de flexibiliteit van de gehele oplossing, maar tegelijkertijd als een extra schakel in deze keten, wat onwillekeurig een productiviteitsverlies suggereert. Bij het schrijven van gegevens moet het systeem deze bijvoorbeeld in deze groepen splitsen en vervolgens op fysiek niveau in de hoofdschijf en schijven voor replica's. Dat wil zeggen, de Hash-functie werkt bij het zoeken en invoegen van een object, maar er is een neveneffect: het zijn zeer hoge kosten en beperkingen bij het opnieuw opbouwen van de hash (bij het toevoegen of verwijderen van een schijf). Een ander hash-probleem is de duidelijk vastgelegde locatie van gegevens die niet kunnen worden gewijzigd. Dat wil zeggen, als de schijf op de een of andere manier zwaarder wordt belast, dan heeft het systeem niet de mogelijkheid om er niet naar te schrijven (door een andere schijf te selecteren), de hash-functie verplicht de gegevens te lokaliseren volgens de regel, hoe slecht ook de schijf is dat wel, dus Ceph eet veel geheugen bij het opnieuw opbouwen van de PG in het geval van zelfherstel of het vergroten van de opslagruimte. De conclusie is dat Ceph goed werkt (zij het langzaam), maar alleen als er geen sprake is van schaalvergroting, noodsituaties of updates.
Er zijn uiteraard mogelijkheden om de prestaties te verbeteren door middel van caching en cache sharing, maar dit vereist goede hardware en er zullen nog steeds verliezen zijn. Maar over het algemeen ziet Ceph er verleidelijker uit dan Gluster wat betreft productiviteit. Bij het gebruik van deze producten moet ook rekening worden gehouden met een belangrijke factor: dit is een hoog niveau van competentie, ervaring en professionaliteit met een grote nadruk op Linux, aangezien het erg belangrijk is om alles correct te implementeren, configureren en onderhouden. waardoor de beheerder nog meer verantwoordelijkheid en lasten krijgt.
Vopslag
De architectuur ziet er nog interessanter uit , die kan worden gebruikt in combinatie met een hypervisor op dezelfde knooppunten, op dezelfde , maar het is erg belangrijk om alles correct te configureren om goede prestaties te bereiken. Dat wil zeggen dat het implementeren van een dergelijk product uit de doos in elke configuratie zonder rekening te houden met de aanbevelingen in overeenstemming met de architectuur heel eenvoudig, maar niet productief zal zijn.
Wat kan er naast de diensten van de kvm-qemu-hypervisor naast de diensten van de kvm-qemu-hypervisor bestaan voor opslag, en dit zijn slechts een paar diensten waarbij een compacte, optimale hiërarchie van componenten is gevonden: clientservice gemonteerd via FUSE (gemodificeerd, niet open source), MDS-metadataservice (Metadataservice), service Chunk-servicedatablokken, die op fysiek niveau gelijk zijn aan één schijf en dat is alles. Qua snelheid is het natuurlijk optimaal om een fouttolerant schema met twee replica's te gebruiken, maar als je caching en logs op SSD-schijven gebruikt, kan fouttolerante codering (erase coding of raid6) behoorlijk worden overgeklokt op een hybride schema of zelfs beter op alle flitsers. Er is een nadeel aan EC (wiscodering): bij het wijzigen van één datablok is het noodzakelijk om de pariteitsbedragen opnieuw te berekenen. Om de verliezen die met deze operatie gepaard gaan te omzeilen, schrijft Ceph op een uitgestelde manier naar EC en kunnen prestatieproblemen optreden tijdens een bepaald verzoek, wanneer bijvoorbeeld alle blokken moeten worden gelezen en, in het geval van Virtuozzo Storage, het schrijven van gewijzigde blokken. wordt uitgevoerd met behulp van de “log-gestructureerde bestandssysteem”-benadering, die de kosten voor pariteitsberekening minimaliseert. Om ongeveer de opties in te schatten met versnelling van het werk met en zonder EC, zijn er – de cijfers kunnen bij benadering zijn, afhankelijk van de nauwkeurigheidscoëfficiënt van de fabrikant van de apparatuur, maar het resultaat van de berekeningen is een goede hulp bij het plannen van de configuratie.
Een eenvoudig diagram van opslagcomponenten betekent niet dat deze componenten niet absorberen maar als je vooraf alle kosten berekent, kun je rekenen op samenwerking naast de hypervisor.
Er is een schema om het verbruik van hardwarebronnen door Ceph- en Virtuozzo-opslagdiensten te vergelijken.
Als het voorheen mogelijk was om Gluster en Ceph te vergelijken met behulp van oude artikelen, met behulp van de belangrijkste regels daaruit, dan is het met Virtuozzo moeilijker. Er zijn niet veel artikelen over dit product en informatie kan alleen uit de documentatie worden gehaald of in het Russisch als we Vstorage beschouwen als opslag die wordt gebruikt in sommige hypergeconvergeerde oplossingen in bedrijven zoals en Acronis.
Ik zal proberen te helpen met een beschrijving van deze architectuur, dus er zal wat meer tekst zijn, maar het kost veel tijd om de documentatie zelf te begrijpen, en de bestaande documentatie kan alleen als referentie worden gebruikt door de tabel te herzien inhoud of zoeken op trefwoord.
Laten we het opnameproces bekijken in een hybride hardwareconfiguratie met de hierboven beschreven componenten: de opname begint te gaan naar het knooppunt van waaruit de client deze heeft geïnitieerd (de FUSE-mountpuntservice), maar de mastercomponent Metadata Service (MDS) zal dat natuurlijk doen stuur de client rechtstreeks naar de gewenste chunk-service (opslagservice CS-blokken), dat wil zeggen dat MDS niet deelneemt aan het opnameproces, maar de service eenvoudigweg naar het vereiste chunk stuurt. Over het algemeen kunnen we een analogie geven met opnemen door water in vaten te gieten. Elk vat is een datablok van 256 MB.
Dat wil zeggen, één schijf is een bepaald aantal van dergelijke vaten, dat wil zeggen het schijfvolume gedeeld door 256 MB. Elke kopie wordt gedistribueerd naar één knooppunt, de tweede bijna parallel aan een ander knooppunt, enz... Als we drie replica's hebben en er SSD-schijven zijn voor cache (voor het lezen en schrijven van logboeken), zal de bevestiging van het schrijven plaatsvinden na het schrijven het logbestand naar de SSD en de parallelle reset vanaf de SSD gaan door op de HDD, alsof ze op de achtergrond plaatsvinden. In het geval van drie replica's wordt het record vastgelegd na bevestiging door de SSD van het derde knooppunt. Het lijkt misschien dat de som van de schrijfsnelheid van drie SSD's door drie kan worden gedeeld en we de schrijfsnelheid van één replica krijgen, maar de kopieën worden parallel geschreven en de latentiesnelheid van het netwerk is meestal hoger dan die van de SSD. en in feite zullen de schrijfprestaties afhangen van het netwerk. In dit opzicht moet u, om echte IOPS te zien, de volledige Vstorage correct laden , dat wil zeggen het testen van de echte belasting, en niet van geheugen en cache, waarbij rekening moet worden gehouden met de juiste datablokgrootte, het aantal threads, enz.
Het bovengenoemde opnamelogboek op de SSD werkt zo dat zodra er data binnenkomen, deze direct door de dienst wordt gelezen en naar de HDD wordt geschreven. Per cluster zijn er meerdere metadataservices (MDS) en het aantal wordt bepaald door een quorum, dat werkt volgens het Paxos-algoritme. Vanuit het oogpunt van de klant is het FUSE-mountpunt een clusteropslagmap die tegelijkertijd zichtbaar is voor alle knooppunten in het cluster. Elk knooppunt heeft volgens dit principe een gekoppelde client, dus deze opslag is beschikbaar voor elk knooppunt.
Voor de prestaties van elk van de hierboven beschreven benaderingen is het erg belangrijk om in de plannings- en implementatiefase het netwerk correct te configureren, waarbij er sprake zal zijn van evenwicht als gevolg van aggregatie en correct geselecteerde netwerkkanaalbandbreedte. Bij aggregatie is het belangrijk om de juiste hashmodus en framegroottes te kiezen. Er is ook een zeer sterk verschil met het hierboven beschreven SDS, dit is gecombineerd met fast path-technologie in Virtuozzo Storage. Wat, naast de gemoderniseerde zekering, in tegenstelling tot andere open source-oplossingen, de IOPS aanzienlijk verhoogt en ervoor zorgt dat u niet wordt beperkt door horizontale of verticale schaling. Over het algemeen ziet deze er, vergeleken met de hierboven beschreven architecturen, krachtiger uit, maar voor dergelijk plezier moet je natuurlijk licenties kopen, in tegenstelling tot Ceph en Gluster.
Samenvattend kunnen we de top van de drie benadrukken: Virtuozzo Storage staat op de eerste plaats wat betreft prestaties en betrouwbaarheid van de architectuur, Ceph staat op de tweede plaats en Gluster staat op de derde plaats.
De criteria op basis waarvan Virtuozzo Storage is geselecteerd: het is een optimale set architecturale componenten, gemoderniseerd voor deze Fuse-aanpak met een snel pad, een flexibele set hardwareconfiguraties, minder resourceverbruik en de mogelijkheid om te delen met compute (computing/virtualisatie), dat wil zeggen, het is volledig geschikt voor een hypergeconvergeerde oplossing waar hij deel van uitmaakt. De tweede plaats is Ceph omdat het een productievere architectuur is vergeleken met Gluster, vanwege de werking in blokken, evenals flexibelere scenario's en de mogelijkheid om in grotere clusters te werken.
Er zijn plannen om een vergelijking te schrijven tussen vSAN, Space Direct Storage, Vstorage en Nutanix Storage, het testen van Vstorage op HPE- en Huawei-apparatuur, evenals scenario's voor het integreren van Vstorage met externe hardwareopslagsystemen, dus als je het artikel leuk vond, zou dat zo zijn leuk om feedback van je te krijgen, wat de motivatie voor nieuwe artikelen kan vergroten, rekening houdend met jouw opmerkingen en wensen.
Bron: www.habr.com