Hierdie artikel is geskryf om jou te help om die regte oplossing vir jouself te kies en die verskille tussen SDS soos Gluster, Ceph en Vstorage (Virtuozzo) te verstaan.
Die teks gebruik skakels na artikels met 'n meer gedetailleerde openbaarmaking van sekere probleme, dus sal die beskrywings so kort as moontlik wees, deur sleutelpunte te gebruik sonder onnodige pluis en inleidende inligting wat jy, as jy wil, onafhanklik op die internet kan bekom.
Trouens, die onderwerpe wat geopper word vereis natuurlik die toon van die teks, maar in die moderne wêreld hou meer en meer mense nie daarvan om baie te lees nie))), sodat jy vinnig kan lees en 'n keuse kan maak, en as iets is nie duidelik nie, volg die skakels of google onduidelike woorde))), en hierdie artikel is soos 'n deursigtige omhulsel vir hierdie diep onderwerpe, wat die vulling wys - die belangrikste sleutelpunte van elke besluit.
Glans
Kom ons begin met Gluster, wat aktief gebruik word deur vervaardigers van hipergekonvergeerde platforms met SDS gebaseer op oopbron vir virtuele omgewings en kan gevind word op die RedHat webwerf in die berging afdeling, waar jy kan kies uit twee SDS opsies: Gluster of Ceph.
Gluster bestaan uit 'n stapel vertalers - dienste wat al die werk verrig om lêers te versprei, ens. Brick is 'n diens wat een skyf bedien, Volume is 'n volume (poel) wat hierdie stene verenig. Vervolgens kom die diens vir die verspreiding van lêers in groepe met behulp van die DHT-funksie (verspreide hash-tabel). Ons sal nie die Sharding-diens by die beskrywing insluit nie, aangesien die skakels hieronder die probleme wat daarmee verband hou, sal beskryf.
Wanneer daar geskryf word, word die hele lêer in baksteen gestoor en die kopie daarvan word gelyktydig na baksteen op die tweede bediener geskryf. Vervolgens sal die tweede lêer na die tweede groep van twee stene (of meer) op verskillende bedieners geskryf word.
As die lêers ongeveer dieselfde grootte is en die volume net uit een groep bestaan, is alles in orde, maar onder ander omstandighede sal die volgende probleme uit die beskrywings ontstaan:
- spasie in groepe word oneweredig benut, dit hang af van die grootte van die lêers en as daar nie genoeg spasie in die groep is om 'n lêer te skryf nie, sal jy 'n fout ontvang, die lêer sal nie geskryf word nie en sal nie na 'n ander groep herverdeel word nie ;
- wanneer een lêer geskryf word, gaan IO net na een groep, die res is ledig;
- jy kan nie IO van die hele volume kry wanneer jy een lêer skryf nie;
- en die algemene konsep lyk minder produktief as gevolg van die gebrek aan dataverspreiding in blokke, waar dit makliker is om die probleem van eenvormige verspreiding te balanseer en op te los, en nie soos nou die hele lêer in 'n blok gaan nie.
Uit die amptelike beskrywing ons kom ook onwillekeurig tot die begrip dat gluster as lêerberging bo-op klassieke hardeware RAID werk. Daar was ontwikkelingspogings om (Sharding) lêers in blokke te sny, maar dit alles is 'n toevoeging wat prestasieverliese op die reeds bestaande argitektoniese benadering plaas, plus die gebruik van sulke vrylik verspreide komponente met prestasiebeperkings soos Fuse. Daar is geen metadatadienste nie, wat die werkverrigting en fouttoleransievermoëns van die berging beperk wanneer lêers in blokke versprei word. Beter prestasie-aanwysers kan waargeneem word met die "Distributed Replicated"-konfigurasie en die aantal nodusse moet ten minste 6 wees om 'n betroubare replika 3 met optimale vragverspreiding te organiseer.
Hierdie bevindinge hou ook verband met die beskrywing van die gebruikerservaring en wanneer dit vergelyk word met , en daar is ook 'n beskrywing van die ervaring wat lei tot 'n begrip van hierdie meer produktiewe en meer betroubare konfigurasie
Die prent wys die ladingverspreiding wanneer twee lêers geskryf word, waar kopieë van die eerste lêer oor die eerste drie bedieners versprei word, wat in die volume 0-groep gekombineer word, en drie kopieë van die tweede lêer op die tweede groep volume1 van drie geplaas word bedieners. Elke bediener het een skyf.
Die algemene gevolgtrekking is dat jy Gluster kan gebruik, maar met die verstandhouding dat daar beperkings in werkverrigting en fouttoleransie sal wees wat probleme skep onder sekere toestande van 'n hipergekonvergeerde oplossing, waar hulpbronne ook nodig is vir die rekenaarlading van virtuele omgewings.
Daar is ook 'n paar Gluster-prestasie-aanwysers wat onder sekere omstandighede bereik kan word, beperk tot
Sef
Kom ons kyk nou na Ceph uit die argitektuurbeskrywings wat ek kon Daar is ook 'n vergelyking tussen , waar jy dadelik kan verstaan dat dit raadsaam is om Ceph op aparte bedieners te ontplooi, aangesien sy dienste al die hardewarehulpbronne onder vrag vereis.
Argitektuur meer kompleks as Gluster en daar is dienste soos metadatadienste, maar die hele stapel komponente is redelik kompleks en nie baie buigsaam om dit in 'n virtualiseringsoplossing te gebruik nie. Die data word in blokke gestoor, wat meer produktief lyk, maar in die hiërargie van alle dienste (komponente) is daar verliese en latensie onder sekere vragte en noodtoestande, byvoorbeeld die volgende
Uit die beskrywing van die argitektuur is die hart CRUSH, waardeur die plek vir die stoor van data gekies word. Volgende kom PG - dit is die moeilikste abstraksie (logiese groep) om te verstaan. PG's is nodig om CRUSH meer effektief te maak. Die hoofdoel van PG is om voorwerpe te groepeer om hulpbronverbruik te verminder, werkverrigting en skaalbaarheid te verhoog. Om voorwerpe direk, individueel, aan te spreek sonder om dit in 'n PG te kombineer, sal baie duur wees. OSD is 'n diens vir elke individuele skyf.
'n Groepering kan een of baie datapoele vir verskillende doeleindes en met verskillende instellings hê. Poele word in plasingsgroepe verdeel. Plasingsgroepe stoor voorwerpe waartoe kliënte toegang het. Dit is waar die logiese vlak eindig, en die fisiese vlak begin, want aan elke plasingsgroep word een hoofskyf en verskeie replikaskywe toegeken (hoeveel presies hang af van die poelreplikasiefaktor). Met ander woorde, op die logiese vlak word die voorwerp in 'n spesifieke plasingsgroep gestoor, en op die fisiese vlak - op die skywe wat daaraan toegewys is. In hierdie geval kan die skywe fisies op verskillende nodusse of selfs in verskillende datasentrums geleë wees.
In hierdie skema lyk plasingsgroepe na 'n noodsaaklike vlak vir die buigsaamheid van die hele oplossing, maar terselfdertyd as 'n ekstra skakel in hierdie ketting, wat onwillekeurig 'n verlies aan produktiwiteit suggereer. Byvoorbeeld, wanneer data geskryf word, moet die stelsel dit in hierdie groepe verdeel en dan op die fisiese vlak in die hoofskyf en skywe vir replikas. Dit wil sê, die Hash-funksie werk wanneer 'n voorwerp gesoek en ingevoeg word, maar daar is 'n newe-effek - dit is baie hoë koste en beperkings op die herbou van die hash (wanneer 'n skyf bygevoeg of verwyder word). Nog 'n hash-probleem is die duidelik vasgespykerde ligging van data wat nie verander kan word nie. Dit wil sê, as die skyf op een of ander manier onder groter las is, het die stelsel nie die geleentheid om nie daarna te skryf nie (deur 'n ander skyf te kies), die hash-funksie verplig die data om volgens die reël opgespoor te word, ongeag hoe sleg die skyf is, so Ceph eet baie geheue wanneer die PG herbou word in die geval van selfgenesing of groter berging. Die gevolgtrekking is dat Ceph goed werk (hoewel stadig), maar slegs wanneer daar geen skaal, noodsituasies of opdaterings is nie.
Daar is natuurlik opsies om werkverrigting te verhoog deur kas en kas te deel, maar dit vereis goeie hardeware en daar sal steeds verliese wees. Maar oor die algemeen lyk Ceph meer aanloklik as Gluster vir produktiwiteit. Ook, wanneer hierdie produkte gebruik word, is dit nodig om 'n belangrike faktor in ag te neem - dit is 'n hoë vlak van bevoegdheid, ervaring en professionaliteit met 'n groot klem op Linux, aangesien dit baie belangrik is om alles korrek te ontplooi, op te stel en te ondersteun, wat nog meer verantwoordelikheid en las op die administrateur lê.
Vberging
Die argitektuur lyk selfs meer interessant , wat gebruik kan word in samewerking met 'n hipervisor op dieselfde nodusse, op dieselfde , maar dit is baie belangrik om alles korrek op te stel om goeie prestasie te behaal. Dit wil sê, om so 'n produk uit die boks op enige konfigurasie te ontplooi sonder om die aanbevelings in ooreenstemming met die argitektuur in ag te neem, sal baie maklik wees, maar nie produktief nie.
Wat kan saam bestaan vir berging langs die dienste van die kvm-qemu hipervisor, en dit is net 'n paar dienste waar 'n kompakte optimale hiërargie van komponente gevind is: kliëntdiens gemonteer via FUSE (gewysig, nie oopbron nie), MDS-metadatadiens (Metadata diens), diens Chunk diens data blokke, wat op die fisiese vlak gelyk is aan een skyf en dit is al. Wat spoed betref, is dit natuurlik optimaal om 'n foutverdraagsame skema met twee replikas te gebruik, maar as jy caching en logs op SSD-aandrywers gebruik, kan foutverdraagsame kodering (vee kodering of raid6) ordentlik oorgeklok word op 'n hibriede skema of selfs beter op alle flits. Daar is 'n paar nadeel met EC (vee kodering uit): wanneer een datablok verander word, is dit nodig om die pariteitsbedrae te herbereken. Om die verliese wat met hierdie operasie geassosieer word te omseil, skryf Ceph op 'n uitgestelde wyse aan EC en prestasieprobleme kan tydens 'n sekere versoek voorkom, wanneer, byvoorbeeld, alle blokke gelees moet word, en in die geval van Virtuozzo Storage, die skryf van veranderde blokke word uitgevoer met behulp van die "log-gestruktureerde lêerstelsel"-benadering, wat pariteitsberekeningskoste tot die minimum beperk. Om ongeveer die opsies met versnelling van werk met en sonder EC te skat, is daar – die syfers kan benaderd wees, afhangende van die akkuraatheidskoëffisiënt van die toerustingvervaardiger, maar die resultaat van die berekeninge is 'n goeie hulp met die beplanning van die konfigurasie.
'n Eenvoudige diagram van bergingskomponente beteken nie dat hierdie komponente nie absorbeer nie maar as jy al die kostes vooraf bereken, kan jy op samewerking langs die hipervisor staatmaak.
Daar is 'n skema om die verbruik van hardewarehulpbronne deur Ceph en Virtuozzo-bergingsdienste te vergelyk.
As dit voorheen moontlik was om Gluster en Ceph met ou artikels te vergelyk, deur die belangrikste reëls van hulle te gebruik, dan is dit met Virtuozzo moeiliker. Daar is nie baie artikels oor hierdie produk nie en inligting kan slegs uit die dokumentasie verkry word of in Russies as ons Vstorage beskou as berging wat gebruik word in sommige hipergekonvergeerde oplossings in maatskappye soos en Acronis.
Ek sal probeer help met 'n beskrywing van hierdie argitektuur, so daar sal 'n bietjie meer teks wees, maar dit neem baie tyd om die dokumentasie self te verstaan, en die bestaande dokumentasie kan slegs as 'n verwysing gebruik word deur die tabel te hersien van inhoud of soek volgens sleutelwoord.
Kom ons kyk na die opnameproses in 'n hibriede hardeware-konfigurasie met die komponente hierbo beskryf: die opname begin om te gaan na die nodus vanwaar die kliënt dit geïnisieer het (die FUSE-monteerpuntdiens), maar die Metadata Service (MDS) meesterkomponent sal natuurlik rig die kliënt direk na die verlangde deeldiens (bergingsdiens CS-blokke), dit wil sê, MDS neem nie deel aan die opnameproses nie, maar rig die diens bloot na die vereiste deel. Oor die algemeen kan ons 'n analogie gee aan opname met die giet van water in vate. Elke vat is 'n 256MB datablok.
Dit wil sê, een skyf is 'n sekere aantal sulke vate, dit wil sê die skyfvolume gedeel deur 256MB. Elke kopie word na een nodus versprei, die tweede amper parallel met 'n ander nodus, ens... As ons drie replikas het en daar is SSD-skywe vir kas (vir lees en skryf logs), dan sal bevestiging van die skryf plaasvind na skryf die logboek na die SSD, en parallelle herstel vanaf die SSD sal voortgaan op die HDD, asof in die agtergrond. In die geval van drie replikas, sal die rekord gepleeg word na bevestiging van die SSD van die derde nodus. Dit mag lyk asof die som van die skryfspoed van drie SSD's deur drie gedeel kan word en ons sal die skryfspoed van een replika kry, maar die kopieë word parallel geskryf en die netwerk Latency-spoed is gewoonlik hoër as dié van die SSD, en in werklikheid sal die skryfprestasie van die netwerk afhang. In hierdie verband, om werklike IOPS te sien, moet jy die hele Vstorage korrek laai deur , dit wil sê om die werklike las te toets, en nie geheue en kas nie, waar dit nodig is om die korrekte datablokgrootte, aantal drade, ens.
Die bogenoemde opnamelogboek op die SSD werk so dat sodra data daarin kom, dit onmiddellik deur die diens gelees en na die HDD geskryf word. Daar is verskeie metadatadienste (MDS) per groepering en hul getal word bepaal deur 'n kworum, wat volgens die Paxos-algoritme werk. Vanuit die kliënt se oogpunt is die FUSE-monteerpunt 'n groepberging-lêergids wat gelyktydig vir alle nodusse in die groepering sigbaar is, elke nodus het 'n gemonteerde kliënt volgens hierdie beginsel, so hierdie berging is beskikbaar vir elke nodus.
Vir die uitvoering van enige van die bogenoemde benaderings is dit baie belangrik, tydens die beplannings- en ontplooiingstadium, om die netwerk korrek op te stel, waar daar balansering sal wees as gevolg van samevoeging en korrek geselekteerde netwerkkanaalbandwydte. In samevoeging is dit belangrik om die regte hashing-modus en raamgroottes te kies. Daar is ook 'n baie sterk verskil van die SDS hierbo beskryf, dit is 'n samesmelting met vinnige pad tegnologie in Virtuozzo Storage. Wat, bykomend tot die gemoderniseerde lont, anders as ander oopbron-oplossings, IOPS aansienlik verhoog en jou toelaat om nie deur horisontale of vertikale skaal beperk te word nie. Oor die algemeen, in vergelyking met die argitekture hierbo beskryf, lyk hierdie een kragtiger, maar vir sulke plesier moet jy natuurlik lisensies koop, anders as Ceph en Gluster.
Om op te som, kan ons die top van die drie uitlig: Virtuozzo Storage neem die eerste plek in terme van prestasie en betroubaarheid van die argitektuur, Ceph neem die tweede plek en Gluster neem die derde plek.
Die kriteria waarvolgens Virtuozzo Storage gekies is: dit is 'n optimale stel argitektoniese komponente, gemoderniseer vir hierdie Fuse-benadering met 'n vinnige pad, 'n buigsame stel hardeware-konfigurasies, minder hulpbronverbruik en die vermoë om met rekenaar te deel (rekenaar/virtualisering), dit wil sê, dit is heeltemal geskik vir 'n hipergekonvergeerde oplossing , waarvan hy deel is. Tweede plek is Ceph omdat dit 'n meer produktiewe argitektuur is in vergelyking met Gluster, as gevolg van sy werking in blokke, sowel as meer buigsame scenario's en die vermoë om in groter groepe te werk.
Daar is planne om 'n vergelyking tussen vSAN, Space Direct Storage, Vstorage en Nutanix Storage te skryf, Vstorage op HPE- en Huawei-toerusting te toets, asook scenario's vir die integrasie van Vstorage met eksterne hardewarebergingstelsels, so as jy van die artikel hou, sal dit wees lekker om terugvoer van jou te kry, wat motivering vir nuwe artikels kan verhoog, met inagneming van jou kommentaar en wense.
Bron: will.com