Lühike võrdlus SDS arhitektuurist või sobiva salvestusplatvormi leidmine (GlusterVsCephVsVirtuozzoStorage)

See artikkel on kirjutatud, et aidata teil valida sobiv lahendus ning mõista erinevusi selliste SDS-ide nagu Gluster, Ceph ja Vstorage (Virtuozzo) vahel.

Tekstis kasutatakse viiteid artikeltele, kus arutatakse erinevaid probleeme põhjalikumalt, seetõttu on kirjeldused võimalikult lühikesed ning sisaldavad peamisi punkte, vältides liialt pikkade seletuste ja sissejuhatuste jagamist, mida saate vajadusel ise internetist leida.

Tegelikult nõuavad käsitletavad teemad sõnumit, kuid tänapäeva maailmas ei soovi üha rohkem inimesi palju lugeda))), seega võite kiirelt üle vaadata ja otsustada, ning kui midagi jääb arusaamatuks, siis uurida viiteid või Google’ist otsida tundmatuid sõnu))), see artikkel on nagu läbipaistev kate nende sügavate teemade jaoks, näidates sisu – iga lahenduse peamised võtmeviidatud punktid.

Gluster

Alustame Glusterist, mida kasutatakse aktiivselt hüperkonsolideeritud platvormide tootjate seas, kes pakuvad open source baasil SDS-i virtuaalsete keskkondade jaoks, ja seda saab leida RedHati kodulehelt salvestuse jaotises, kus pakutakse valida kahe SDS variandi vahel: Gluster või Ceph.

Gluster koosneb tõlkeserveriteste – teenustest, mis teostavad kõik failide jaotamise tööd jne. Brick on teenus, mis teenindab ühte ketast, Volume – maht (plokk) – mis ühendab need brick'id. Edasi liigub failide jaotamise teenus gruppide vahel DHT (jaotatud räsi tabel) funktsiooni abil. Sharding teenust ei hakka siia kirjeldama, kuna allolevates linkides on kirjas sellega seotud probleemid.

Kirjutamisel pannakse fail tervikuna brick'i ja selle koopia kirjutatakse paralleelselt teise serveri brick'ile. Järgnev fail kirjutatakse siis teise gruppi kahest brick'ist (või rohkem) erinevates serverites.

Kui failid on umbes sama suurusega ja maht koosneb ainult ühest grupist, siis on kõik korras, kuid teiste tingimuste korral tekivad järgmistest kirjeldustest järgmised probleemid:

• ruumi grupis kasutatakse ebaühtlaselt, see sõltub failide suurustest ja kui grupis ei ole kirjutamiseks piisavalt ruumi — saate vea, fail ei salvestata ega jaotata teise gruppi;
• ühe faili kirjutamisel toimub IO vaid ühes grupis, teised aga ootavad;
• ühe faili kirjutamisel ei saa kogu mahu IO-d saada;
• ja üldine kontseptsioon tundub vähem tootlik, kuna puudub andmete jaotus plokkide vahel, kus tasakaalustamine ja probleemide lahendamine on lihtsam, mitte nagu praegu, kui fail asetub tervikuna brikkidesse.

Ametlikust kirjelduse arhitektuurist ka tuleb tahtmatult arusaam, et gluster töötab nagu failide salvestamise süsteem klassikalise riistvara RAID-i kohal. On tehtud katseid faile plokkideks jagada (Sharding), kuid see on kõik täiendav, mis toob kaasa tootlikuse kaotuse juba olemasolevale arhitektuurilisele lähenemisele, pluss selliste tasuta võimaluste kasutamine, millel on tootlikuse piirang nagu Fuse. Metandmete teenuseid pole, mis piiravad salvestuse tootlikkuse ja talitlushäiretõrje võimalusi failide jaotamisel plokkideks. Paremaid tootlikkuse näitajaid võib täheldada

need järeldused on seotud ka kogemuse kirjeldamisega Gluster ja võrdlemisel Ceph, samuti on olemas kogemuse kirjeldus selle tõhusama ja usaldusväärsema konfiguratsiooni mõistmise saavutamise kohta “Replicated Distributed”.


Pildil on näidatud koormuse jaotust kahe faili kirjutamisel, kus esimese faili koopiad jaotatakse kolmele esimesest serverist, mis on ühendatud mahtude rühmaga 0, ja kolme koopia teise faili asetatakse teise gruppi volume1 kolme serveri seast. Igal serveril on üks kõvaketas.

Üldine järeldus on see, et Glusterit saab kasutada, kuid arvestades, et tootlikkuse ja talitlushäiretõrje osas on piirangud, mis loovad raskusi teatud hüperkonvergente lahenduse tingimustes, kus ressursse vajatakse ka virtuaalsete keskkondade arvutuskoormuseks.

On olemas ka mõned Glusteri tootlikkuse näitajad, mida saab saavutada teatud tingimustes piiratud talitlushäiretõrjes.

Ceph

Nüüd vaatame Cephi arhitektuuri kirjelduse, mida olen suutnud leida. Samuti on olemas võrdlus Glusterfs ja Ceph, kus saab kohe aru, et Cephi on soovitatav paigaldada eraldi serveritele, kuna selle teenused vajavad koormuste korral kõiki riistvara ressursse.

Arhitektuur Ceph on keerukam kui Gluster ja sellel on sellised teenused nagu metateenused, kuid kogu komponentide virna struktuur on üsna keeruline ja mitte eriti paindlik virtuaaliseerimise lahenduste kasutamiseks. Andmed salvestatakse plokkidena, mis näevad välja tootlikumad, kuid kõigi teenuste (komponentide) hierarhias esinevad kaotused ja latentsus teatud koormuste ja avariitingimuste korral, näiteks järgmised artikkel.

Arhitektuuri kirjeldusest on peamiseks komponendiks CRUSH, tänu millele valitakse andmete paiknemise koht. Järgmiseks on PG – see on kõige keerulisem abstraktsioon (loogiline rühm), mida on raske mõista. PG-d on vajalikud selleks, et CRUSH oleks efektiivsem. PG peamine eesmärk on objektide rühmitamine ressursikasutuse vähendamiseks, tootlikkuse suurendamiseks ja skaaleeritavuse tagamiseks. Objektide otsene ja eraldi adresseerimine, ilma nende PG-sse ühendamiseta, oleks väga kulukas. OSD on teenus iga eraldi ketta jaoks.

Klastril võib olla üks või mitu andmepooli, millel on erinevad eesmärgid ja seaded. Pooled jagunevad paigutusgruppideks. Paigutusgruppides hoitakse objekte, millele kliendid pöörduvad. Siit lõpeb loogiline tase ja algab füüsiline, kuna igale paigutusgrupile on määratud üks peamine ketas ja mitu koopiakettast (kui palju sõltub pooli kopeerimise tegurist). Teisisõnu, loogilisel tasemel hoitakse objekt konkreetsetes paigutusgruppides, samas kui füüsilisel tasemel hoitakse neid ketastes, mis on nende kaudu määratud. Samas võivad kettad füüsiliselt asuda erinevates sõlmedes või isegi erinevates andmekeskustes.

Selles skeemis näevad paigutusgrupid välja kui vajalik tasand kogu lahenduse paindlikkuse jaoks, kuid samas ka kui üleliigne lüli selles ahelas, mis sunnib mõtlema jõudluse kaotamisele. Näiteks, kui andmeid salvestatakse, peab süsteem need jagama nende gruppide vahel ja seejärel füüsiliselt peamisele kettale ning replikatsiooniketastele. See tähendab, et hash-funktsioon töötab objekti otsimisel ja lisamisel, kuid on ka kõrvalmõjusid – see toob kaasa väga suured kulud ja piirangud hash'i taastamisel (kui ketast lisatakse või eemaldatakse). Veel üks hash'i probleem on see, et andmete asukoht on rangelt määratletud, mida ei saa muuta. See tähendab, et kui mõni ketas kogeb suuremat koormust, ei saa süsteem kirjutada sellele (valides teise ketta), hash-funktsioon sunnib andmeid paigutama reegli järgi, sõltumata sellest, kui halvasti kettaga läheb, mistõttu Ceph sööb palju mälu PG-de taastamisel eneseparandamise või salvestusruumi suurendamise korral. Kokkuvõttes töötab Ceph hästi (kuigi aeglaselt), kuid ainult siis, kui ei toimu skaleerimist, hädaolukordi ega uuendusi.

Muidugi on olemas võimalusi jõudluse parandamiseks vahemälu ja vahemälu kihistamise abil, kuid selleks on vajalik hea riistvara ja ikkagi tekivad kaotused. Küll aga tundub Ceph üldiselt ahvatlevam kui Gluster tootmises. Samuti tuleb neid tooteid kasutades arvesse võtta oluline tegur – kõrge kompetentsuse, kogemuse ja professionaalsuse tase, keskendudes eriti Linuxile, kuna on äärmiselt oluline kõik õigesti seadistada, paigaldada ja toetada, mis seab administreerimisele veelgi suurema vastutuse ja koormuse.

Vstorage

Veelgi huvitavam arhitektuur on Virtuozzo storage (Vstorage), mida saab kasutada koos hyperviisoriga samadel sõlmedel, samas riistvaral, kuid on äärmiselt oluline kõik õigesti konfigureerida, et saavutada hea jõudlus. See tähendab, et kui selline toode paigaldatakse lihtsalt mingi konfiguratsiooni peale, järgimata arhitektuuri soovitusi, on väga lihtne seda teha, kuid tulemus ei ole tulemuslik.

Mis saab eksisteerida koos KVM-QEMU hüperviisori teenustega, see on vaid mõned teenused, kus leiti kompaktne optimaalne komponentide hierarhia: kliendi teenus, mis on ühendatud FUSE'i kaudu (muudetud, mitte avatud lähtekoodiga), metateenuste teenus MDS, andmeplokkide teenus Chunk, mis füüsilisel tasandil vastab ühele kettale ja sellega asi piirdub. Kiirus on loomulikult optimaalne kasutada kahe replikaga talitlushäiretesti, kuid kui kasutada vahemälu ja ajakirju SSD-kettal, siis saab vigade korrigeerimise kodeeringut (erase coding või raid6) märgatavalt kiirendada hübriidskeemil või isegi paremini all-flash skeemil. EC (erase coding) puhul on teatav miinus: ühe andmeploki muutmisel tuleb arvutada pariteetsummad uuesti. Selle operatsiooni kadude vältimiseks kirjutab Ceph EC-st viivitusega ja jõudlusega võivad tekkida probleemid teatud päringute korral, kui näiteks on vajalik lugeda kõiki plokke, samas kui Virtuozzo Storage'is toimub muudetud plokkide kirjutamine lähenemisviisi "log-structured file system" abil, mis minimaliseerib pariteedi arvutamise kulusid. Et ligikaudselt hinnata variante töö kiirendamiseks EC ja ilma, on. kalkulaator. – numbrid võivad olla ligikaudsed, sõltuvalt seadme tootja täpsuse koefitsiendist, kuid arvutustulemused aitavad hästi konfigureerimist planeerida.

Lihtne salvestuskomponentide skeem ei tähenda, et need komponendid ei tarbiks. rauda, aga kui kõiki kulusid ette arvestada, siis võib loota koostöös hüperviisoriga.
On olemas võrdlustabel Ceph'i ja Virtuozzo salvestus teenuste rauatarbimise kohta.

Kui varem sai Glusterit ja Cephi võrrelda vanade artiklite põhjal, kasutades nende olulisemaid ridu, siis Virtuozzot on keerulisem. Selle toote kohta ei ole palju artikleid ja teavet saab ammutada ainult dokumentatsioonist. inglise või vene keeles, kui vaadata Vstorage'i, kui salvestust, mida kasutatakse mõnes hüperkonvergentses lahenduses ettevõtetes nagu. Rospilatforma ja Acronis.

Püüan aidata selle arhitektuuri kirjeldamisega, seetõttu on tekst veidi pikem. Ent, et ise dokumentatsioonist aru saada, on vajalik palju aega ja olemasolevat dokumentatsiooni saab kasutada ainult viitena, vaadates sisukorda või otsides märksõna kaudu.

Vaatame hübriidkonfiguratsiooni riistvara salvestusprotsessi, kus osaleb eelpool kirjeldatud komponente: salvestus algab sellele sõlmele, kust klient (FUSE montaažiteenuse) selle algatab, kuid metandmete teenuse (MDS) komponent suunab kliendi otse vajaliku ploki salvestusteenuse (CS), s.t MDS ei osale salvestusprotsessis, vaid suunab lihtsalt vajaliku ploki teenusele. Üldiselt võib tuua analoogia salvestamise jaotumisega veekeeriste vahel. Iga keeris on 256 MB andmeplokk.

See tähendab, et üks ketas on mingi hulk selliseid keeriseid, st ketta maht jagada 256 MB-ga. Iga koopia jaotatakse ühele sõlmele, teine peaaegu samal ajal teisele sõlmele jne... Kui meil on kolm koopia ja SSD kettad, mida kasutatakse vahemälu jaoks (lugemiseks ja kirjutuslogideks), siis kirjutamise kinnitamine toimub pärast logi kirjutamist SSD-le ja paralleelne tagasi määrimine SSD-lt jätkub HDD-le, nagu taustal. Kolme koopia puhul toimub kirjutamise kinnitamine pärast kinnitust kolmanda sõlme SSD-lt. Võib tunduda, et kolme SSD kirjutamiskiirus jagatakse kolme ja saame ühe koopia kirjutamiskiirus, kuid koopia kirjutamine toimub paralleelselt ja võrgu latentsus on tavaliselt suurem kui SSD-l, seega sõltub kirjutamise jõudlus võrgust. Sel põhjusel, et näha reaalseid IOPS-e, on vajalik koormata kogu Vstorage õigesti meetodi, st testida reaalselt koormust, mitte mälu ja vahemälu, kus on oluline arvestada andmeploki õige suuruse, voogude arvu jne.

Üles nimetatud SSD logifail töötab nii, et niipea kui andmed sinna jõuavad, loetakse need koheselt teenuse poolt ja kirjutatakse HDD-le. Metaandmete teenuseid (MDS) on klastris mitu ning nende arv määratakse kvoorumiga, mis töötab Paxos algoritmi põhjal. Klientide jaoks on FUSE-mount punkt klastrihalduse kaust, mis on samaaegselt nähtav kõigile klastrinodele; igal noodil on see mountitud kliendi kaudu, mistõttu on sellele salvestusele igas nodis ligipääs.

Iga eelpool kirjeldatud lähenemise jõudluse jaoks on väga oluline, et plaanimise ja juurutamise etapis oleks õige võrgu seadistamine, kus toimub tasakaalustus aggregeerimise ja õigesti valitud võrguühenduse läbilaskevõime kaudu. Aggregeerimises on oluline õigesti valida hashimise režiim ja raamide suurused. Samuti on suur erinevus eelpool kirjeldatud SDS-de ja Technoloogia fast path fuse vahel Virtuozzo Storage'is. See, erinevalt teiste avatud lähtekoodiga lahendustest, suurendab IOPS-e ja võimaldab mitte piirduda horisontaalse või vertikaalse skaleerimisega. Üldiselt tundub see eelpool kirjeldatud arhitektuuride võrreldes tugevam, kuid sellise rõõmu eest tuleb siiski litsentse osta, erinevalt Cephist ja Glusterist.

Kokkuvõtteks võib rõhutada kolme parimat: esikoha jõudluse ja usaldusväärsuse osas hoiab Virtuozzo Storage, teisel kohal on Ceph ja kolmandal Gluster.

Kriteeriumid, mille põhjal valiti Virtuozzo Storage: see on optimaalne komponentide komplekt arhitektuurist, fuse on moderniseeritud selle lähenemise jaoks fast path tehnoloogiaga, paindlik riistvara konfiguratsiooni komplekt, madalam ressursitarve ja võimalus koos kasutada arvutusvõimet (virtualiseerimisega), see tähendab, et see sobib täielikult hüperkonvergente lahendusse, mille osana see on. Teisel kohal on Ceph, kuna see on tõhusam arhitektuur kui Gluster, operatiivsete plokkide tõttu, samuti paindlike stsenaariumide ja võimaluse tõttu töötada suuremates klastrites.

Plaanide hulgas on soov kirjutada võrdlus vSANi, Space Direct Storage'i, Vstorage'i ja Nutanix Storage'i vahel, testida Vstorage'i HPE ja Huawei riistvaraga ning samuti Vstorage'i integreerimise stsenaariumeid välistesse riistvaralistesse andmesalvestusse. Seetõttu, kui artikkel teile meeldis, oleks tore saada teie tagasisidet, mis võiks suurendada motivatsiooni uute artiklite kirjutamiseks, arvestades teie märkusi ja soove.

Allikas: habr.com