See artikkel on kirjutatud selleks, et aidata teil valida enda jaoks õige lahendus ja mõista SDS-ide (nt Gluster, Ceph ja Vstorage (Virtuozzo)) erinevusi.
Tekstis kasutatakse linke artiklitele, milles on teatud probleemide üksikasjalikum avastus, nii et kirjeldused on võimalikult lühikesed, kasutades põhipunkte ilma tarbetu kohevuseta ja sissejuhatavat teavet, mida saate soovi korral iseseisvalt Internetist hankida.
Tegelikult nõuavad tõstatatud teemad muidugi teksti toone, kuid tänapäeva maailmas ei meeldi üha enam inimestele palju lugeda))), nii et saate kiiresti lugeda ja teha valiku ning kui midagi on pole selge, järgige linke või googeldage ebaselgeid sõnu))) ja see artikkel on nende sügavate teemade jaoks nagu läbipaistev ümbris, mis näitab täitmist - iga otsuse peamisi võtmepunkte.
Hägune
Alustame Glusteriga, mida kasutavad aktiivselt avatud lähtekoodiga virtuaalkeskkondadele mõeldud SDS-iga hüperkonvergeeritud platvormide tootjad ja mille leiab RedHati kodulehelt salvestusruumist, kus saab valida kahe SDS-i valiku vahel: Gluster või Ceph.
Gluster koosneb virnast tõlkidest - teenustest, mis täidavad kogu failide levitamise jne tööd. Brick on teenus, mis teenindab ühte ketast, Volume on köide (bassein), mis ühendab need tellised. Järgmisena tuleb teenus failide rühmadesse jaotamiseks, kasutades DHT (distributed hash table) funktsiooni. Me ei lisa Shardingi teenust kirjeldusse, kuna allolevad lingid kirjeldavad sellega seotud probleeme.
Kirjutamisel salvestatakse kogu fail telliskivisse ja selle koopia kirjutatakse samaaegselt telliskivisse teises serveris. Järgmisena kirjutatakse teine fail erinevatesse serveritesse kahe (või enama) tellise teise rühma.
Kui failid on ligikaudu ühesuurused ja maht koosneb ainult ühest rühmast, siis on kõik korras, kuid muudel tingimustel tekivad kirjeldustest järgmised probleemid:
- gruppide ruumi kasutatakse ebaühtlaselt, see sõltub failide suurusest ja kui grupis pole faili kirjutamiseks piisavalt ruumi, kuvatakse veateade, faili ei kirjutata ja seda ei jaotata teise rühma ;
- ühe faili kirjutamisel läheb IO ainult ühte rühma, ülejäänud on jõude;
- ühe faili kirjutamisel ei saa te kogu köite IO-d hankida;
- ja üldine kontseptsioon näeb vähem produktiivne välja andmete puudumise tõttu plokkidesse, kus on lihtsam tasakaalustada ja lahendada ühtlase jaotuse probleem, mitte nii, nagu praegu läheb kogu fail plokki.
Ametlikust kirjeldusest Samuti jõuame tahes-tahtmata arusaamisele, et gluster toimib failisalvestusena klassikalise riistvaralise RAIDi peal. On tehtud arenduskatseid (Sharding) faile plokkideks lõigata, kuid see kõik on täiendus, mis toob kaasa jõudluskadu juba olemasolevale arhitektuurilisele lähenemisele, millele lisandub selliste jõudluspiirangutega vabalt levitatavate komponentide kasutamine nagu Fuse. Puuduvad metaandmeteenused, mis piiravad failide plokkideks jaotamisel salvestusruumi jõudlust ja tõrketaluvust. Paremaid jõudlusnäitajaid saab jälgida konfiguratsiooniga "Distributed Replicated" ja optimaalse koormuse jaotusega usaldusväärse koopia 6 korraldamiseks peaks sõlmede arv olema vähemalt 3.
Need leiud on seotud ka kasutajakogemuse kirjeldusega ja kui võrrelda , ja seal on ka kogemuse kirjeldus, mis aitab mõista seda produktiivsemat ja usaldusväärsemat konfiguratsiooni
Pildil on koormuse jaotus kahe faili kirjutamisel, kus esimese faili koopiad jaotatakse esimese kolme serveri vahel, mis liidetakse grupi 0 köite hulka ja teise faili kolm eksemplari asetatakse teise rühma köide1 kolmest serverid. Igal serveril on üks ketas.
Üldine järeldus on, et saate Glusterit kasutada, kuid mõistmisega, et jõudluses ja tõrketaluvuses on piiranguid, mis tekitavad raskusi hüperkonvergeeritud lahenduse teatud tingimustes, kus ressursse on vaja ka virtuaalsete keskkondade arvutuskoormuste jaoks.
Samuti on mõned Glusteri jõudlusnäitajad, mida saab teatud tingimustel saavutada, piirdudes sellega
ceph
Vaatame nüüd Cefi arhitektuurikirjeldustest, mida ma suutsin Võrdlus on ka vahel , kus saate kohe aru, et Ceph on soovitatav juurutada eraldi serveritesse, kuna selle teenused nõuavad kõiki koormuse all olevaid riistvararessursse.
arhitektuur keerulisem kui Gluster ja on selliseid teenuseid nagu metaandmete teenused, kuid kogu komponentide virn on üsna keeruline ega ole virtualiseerimislahenduses kasutamiseks eriti paindlik. Andmed salvestatakse plokkidesse, mis näeb välja produktiivsem, kuid kõigi teenuste (komponentide) hierarhias esineb teatud koormuste ja hädaolukordade korral kadusid ja latentsust, näiteks järgmistel juhtudel.
Arhitektuuri kirjeldusest on südameks CRUSH, tänu millele valitakse andmete salvestamise koht. Järgmisena tuleb PG – see on kõige raskemini mõistetav abstraktsioon (loogiline rühm). PG-sid on vaja CRUSHi efektiivsemaks muutmiseks. PG peamine eesmärk on rühmitada objekte, et vähendada ressursitarbimist, suurendada jõudlust ja skaleeritavust. Objektide adresseerimine otse, individuaalselt, ilma neid PG-ks ühendamata, oleks väga kulukas. OSD on teenus iga üksiku ketta jaoks.
Klastris võib olla üks või mitu andmekogumit erinevatel eesmärkidel ja erinevate seadistustega. Basseinid on jagatud paigutusrühmadesse. Paigutusrühmad salvestavad objekte, millele kliendid pääsevad juurde. Siin lõpeb loogiline tase ja algab füüsiline tase, sest igale paigutusrühmale on määratud üks põhiketas ja mitu koopiaketast (kui palju täpselt, sõltub kogumi replikatsioonifaktorist). Teisisõnu, loogilisel tasemel salvestatakse objekt kindlasse paigutusrühma ja füüsilisel tasemel - sellele määratud ketastele. Sel juhul võivad kettad füüsiliselt asuda erinevates sõlmedes või isegi erinevates andmekeskustes.
Selles skeemis näivad paigutusrühmad kogu lahenduse paindlikkuse jaoks vajaliku tasemena, kuid samal ajal selle ahela lisalülina, mis tahes-tahtmata viitab tootlikkuse vähenemisele. Näiteks andmete kirjutamisel peab süsteem jagama need nendeks rühmadeks ja seejärel füüsilisel tasandil põhikettaks ja koopiate ketasteks. See tähendab, et räsifunktsioon töötab objekti otsimisel ja sisestamisel, kuid sellel on kõrvalmõju - see on väga suured kulud ja piirangud räsi uuesti ülesehitamisel (ketta lisamisel või eemaldamisel). Teine räsiprobleem on andmete selgelt naelutatud asukoht, mida ei saa muuta. See tähendab, et kui ketas on kuidagi suurenenud koormuse all, siis pole süsteemil võimalust sellele mitte kirjutada (valides teise ketta), räsifunktsioon kohustab andmeid reegli järgi asuma, ükskõik kui halvasti ketas on, nii et Ceph sööb palju mälu PG ümberehitamisel, kui see ise paraneb või salvestusruum suureneb. Järeldus on, et Ceph töötab hästi (ehkki aeglaselt), kuid ainult siis, kui pole skaleerimist, hädaolukordi ega värskendusi.
Muidugi on võimalusi jõudluse suurendamiseks vahemällu salvestamise ja vahemälu jagamise kaudu, kuid selleks on vaja head riistvara ja kahjusid tuleb ikkagi ette. Kuid üldiselt tundub Ceph tootlikkuse osas ahvatlevam kui Gluster. Samuti on nende toodete kasutamisel vaja arvestada ühe olulise teguriga - see on kõrge pädevuse, kogemuste ja professionaalsuse tase, pöörates suurt tähelepanu Linuxile, kuna on väga oluline kõike õigesti juurutada, konfigureerida ja hooldada, mis paneb haldurile veelgi suurema vastutuse ja koormuse.
Vstorage
Arhitektuur tundub veelgi huvitavam , mida saab kasutada koos hüperviisoriga samadel sõlmedel, samal , kuid hea jõudluse saavutamiseks on väga oluline kõik õigesti konfigureerida. See tähendab, et sellise toote juurutamine karbist mis tahes konfiguratsioonis, võtmata arvesse soovitusi vastavalt arhitektuurile, on väga lihtne, kuid mitte produktiivne.
Mis saab kvm-qemu hüperviisori teenuste kõrval salvestuseks eksisteerida ja need on vaid mõned teenused, kus on leitud kompaktne optimaalne komponentide hierarhia: FUSE kaudu monteeritud klienditeenindus (modifitseeritud, mitte avatud lähtekoodiga), MDS metaandmete teenus (Metaandmete teenus), teenus Chunk teenuse andmeplokid, mis füüsilisel tasemel võrdub ühe kettaga ja see on kõik. Kiiruse mõttes on muidugi optimaalne kasutada kahe koopiaga tõrketaluvusega skeemi, kuid kui kasutate SSD-draividel vahemällu salvestamist ja logisid, saab veakindlat kodeerimist (kustutage kodeering või raid6) korralikult üle kiirendada. hübriidskeem või isegi parem kõigil välklambidel. EC-l (erase coding) on üks miinus: ühe andmeploki muutmisel on vaja paarsussummad ümber arvutada. Selle toiminguga seotud kadude vältimiseks kirjutab Ceph EC-le edasi ja teatud päringu ajal võivad tekkida jõudlusprobleemid, kui näiteks on vaja lugeda kõiki plokke ja Virtuozzo Storage'i puhul tehakse muudetud plokkide kirjutamine kasutades "logistruktuuriga failisüsteemi" lähenemisviisi, mis minimeerib paarsuse arvutamise kulud. Et hinnata ligikaudselt võimalusi töö kiirendamisega EC-ga ja ilma, on olemas – arvud võivad olla ligikaudsed olenevalt seadmetootja täpsuskoefitsiendist, kuid arvutuste tulemus on heaks abiks konfiguratsiooni planeerimisel.
Lihtne salvestuskomponentide diagramm ei tähenda, et need komponendid ei imenduks aga kui kõik kulud ette arvutada, siis võib hüperviisori kõrval loota koostööle.
Cephi ja Virtuozzo salvestusteenuste riistvararessursside tarbimise võrdlemiseks on olemas skeem.
Kui varem sai Glusterit ja Cephi võrrelda vanade artiklite abil, kasutades nendest kõige olulisemaid ridu, siis Virtuozzoga on see keerulisem. Selle toote kohta pole palju artikleid ja teavet saab koguda ainult selle toote dokumentatsioonist või vene keeles, kui käsitleme Vstorage'i salvestusruumina, mida kasutatakse mõnes hüperkonvergeeritud lahenduses sellistes ettevõtetes nagu ja Acronis.
Püüan aidata selle arhitektuuri kirjeldusega, nii et teksti tuleb natuke rohkem, kuid dokumentatsioonist ise aru saamine võtab palju aega ja olemasolevat dokumentatsiooni saab kasutada ainult viitena tabelit üle vaadates sisu või märksõna järgi otsimine.
Vaatleme salvestamise protsessi ülalkirjeldatud komponentidega hübriidriistvarakonfiguratsioonis: salvestus hakkab liikuma sõlme, kust klient selle algatas (ühenduspunkti teenus FUSE), kuid metadatateenuse (MDS) põhikomponent läheb loomulikult suunata klient otse soovitud tükiteenuse juurde (salvestusteenuse CS-plokid), see tähendab, et MDS ei osale salvestusprotsessis, vaid suunab teenuse lihtsalt vajalikule tükile. Üldiselt võime tuua analoogia salvestamisele vee tünnidesse valamisega. Iga barrel on 256 MB andmeplokk.
See tähendab, et üks ketas on teatud arv selliseid barreleid, st ketta maht jagatud 256 MB-ga. Iga koopia jaotatakse ühele sõlmele, teine peaaegu paralleelselt teisele sõlmele jne... Kui meil on kolm koopiat ja vahemälu jaoks on olemas SSD kettad (logide lugemiseks ja kirjutamiseks), siis pärast kirjutamist toimub kirjutamise kinnitus logi SSD-le ja paralleelne lähtestamine SSD-lt jätkub HDD-l justkui taustal. Kolme koopia puhul tehakse kirje pärast kolmanda sõlme SSD-lt kinnitust. Võib tunduda, et kolme SSD kirjutuskiiruse summa saab jagada kolmega ja saame ühe koopia kirjutamiskiiruse, kuid koopiad kirjutatakse paralleelselt ja võrgu latentsuskiirus on tavaliselt suurem kui SSD-l, ja tegelikult sõltub kirjutamise jõudlus võrgust. Sellega seoses peate tõelise IOPS-i nägemiseks laadima kogu V-salvestusruumi õigesti , ehk siis reaalse koormuse, mitte mälu ja vahemälu testimine, kus on vaja arvestada õiget andmeploki suurust, lõimede arvu jne.
Ülalmainitud salvestuslogi SSD-l töötab nii, et niipea, kui sinna satuvad andmed, loeb teenus need kohe läbi ja kirjutab HDD-le. Klastris on mitu metaandmete teenust (MDS) ja nende arvu määrab kvoorum, mis töötab Paxose algoritmi järgi. Kliendi seisukohalt on FUSE ühenduspunkt klastri salvestuskaust, mis on üheaegselt nähtav kõikidele klastri sõlmedele, igal sõlmel on selle põhimõtte järgi ühendatud klient, seega on see salvestuskoht igale sõlmele saadaval.
Ülalkirjeldatud lähenemisviiside toimimiseks on väga oluline planeerimise ja juurutamise etapis õigesti konfigureerida võrk, kus toimub tasakaalustamine agregatsiooni ja õigesti valitud võrgukanali ribalaiuse tõttu. Kokkuvõttes on oluline valida õige räsirežiim ja kaadri suurused. Samuti on väga tugev erinevus ülalkirjeldatud SDS-ist, see on Virtuozzo Storage'i kiirtee tehnoloogiaga kaitsme. Mis lisaks moderniseeritud kaitsmele suurendab erinevalt teistest avatud lähtekoodiga lahendustest oluliselt IOPS-i ja võimaldab mitte lasta end piirata horisontaalse või vertikaalse skaleerimisega. Üldiselt näeb see ülalkirjeldatud arhitektuuriga võrreldes võimsam välja, kuid sellise naudingu jaoks tuleb erinevalt Cephist ja Glusterist muidugi litsentsid osta.
Kokkuvõtteks võime neist kolmest esile tõsta: Virtuozzo Storage saavutab jõudluse ja arhitektuuri usaldusväärsuse poolest esikoha, Ceph on teisel kohal ja Gluster kolmandal kohal.
Kriteeriumid, mille alusel Virtuozzo Storage valiti: see on optimaalne arhitektuursete komponentide komplekt, mis on selle Fuse-lähenemise jaoks kaasajastatud kiire teekonna, paindliku riistvarakonfiguratsioonide komplekti, väiksema ressursikulu ja võimalusega jagada arvutiga (arvutamine/virtualiseerimine), see tähendab, et see sobib täielikult hüperkonvergeeritud lahenduseks, mille osa ta on. Teisel kohal on Ceph, kuna see on Glusteriga võrreldes produktiivsem arhitektuur, seda nii plokkidena toimimise kui ka paindlikumate stsenaariumide ja suuremate klastrite töötamise võimaluse tõttu.
Plaanis on kirjutada vSAN, Space Direct Storage, Vstorage ja Nutanix Storage võrdlus, Vstorage testimine HPE ja Huawei seadmetes, samuti stsenaariumid Vstorage'i integreerimiseks väliste riistvarasalvestussüsteemidega, nii et kui artikkel teile meeldis, oleks see Tore saada teilt tagasisidet, mis võib teie kommentaare ja soove arvesse võttes suurendada motivatsiooni uute artiklite jaoks.
Allikas: www.habr.com