Šis straipsnis buvo parašytas siekiant padėti jums pasirinkti tinkamą sprendimą ir suprasti skirtumus tarp SDS, tokių kaip Gluster, Ceph ir Vstorage (Virtuozzo).
Tekste naudojamos nuorodos į straipsnius, kuriuose išsamiau atskleidžiamos tam tikros problemos, todėl aprašymai bus kuo trumpesni, naudojant pagrindinius punktus be nereikalingo pūkavimo ir įvadinę informaciją, kurią, jei norite, galite savarankiškai gauti internete.
Tiesą sakant, žinoma, keliamos temos reikalauja teksto tonų, tačiau šiuolaikiniame pasaulyje vis daugiau žmonių nemėgsta daug skaityti))), todėl galite greitai perskaityti ir pasirinkti, o jei kažkas yra neaišku, sekite nuorodas arba google neaiškius žodžius))), o šis straipsnis yra tarsi skaidrus įvyniojimas šioms gilioms temoms, parodantis užpildymą – pagrindinius kiekvieno sprendimo kertinius punktus.
Blizgesys
Pradėkime nuo Gluster, kurį aktyviai naudoja hiperkonverguotų platformų su atvirojo kodo virtualioms aplinkoms pagrindu veikiančių SDS gamintojai ir kurį galima rasti RedHat svetainės saugyklos skiltyje, kur galima rinktis iš dviejų SDS parinkčių: Gluster arba Ceph.
Gluster susideda iš krūvos vertėjų – paslaugų, kurios atlieka visus failų platinimo darbus ir pan. Brick – tai paslauga, aptarnaujanti vieną diską, Volume – tomas (puldas), jungiantis šias plytas. Toliau pateikiama paslauga, skirta failams paskirstyti grupes naudojant DHT (distributed hash table) funkciją. Į aprašą neįtrauksime „Sharding“ paslaugos, nes toliau pateiktose nuorodose bus aprašytos su ja susijusios problemos.
Rašant visas failas saugomas brike, o jo kopija tuo pačiu metu įrašoma į plytą antrajame serveryje. Tada antrasis failas bus įrašytas į antrąją dviejų (ar daugiau) blokų grupę skirtinguose serveriuose.
Jei failai yra maždaug tokio paties dydžio, o tomas susideda tik iš vienos grupės, tada viskas gerai, tačiau kitomis sąlygomis iš aprašymų kils šios problemos:
- vieta grupėse išnaudojama netolygiai, tai priklauso nuo failų dydžio ir jei grupėje neužtenka vietos įrašyti failą, gausite klaidą, failas nebus įrašytas ir nebus perskirstytas kitai grupei ;
- rašant vieną failą, IO eina tik į vieną grupę, likusieji yra neaktyvūs;
- rašydami vieną failą negalite gauti viso tomo IO;
- ir bendra koncepcija atrodo ne tokia produktyvi dėl to, kad trūksta duomenų paskirstymo į blokus, kur lengviau subalansuoti ir išspręsti vienodo paskirstymo problemą, o ne taip, kaip dabar visas failas patenka į bloką.
Iš oficialaus aprašymo mes taip pat nevalingai suprantame, kad gluster veikia kaip failų saugykla ant klasikinės aparatinės įrangos RAID. Buvo kūrimo bandymų supjaustyti (Sharing) failus į blokus, tačiau visa tai yra papildymas, dėl kurio jau egzistuojantis architektūrinis požiūris praranda našumą, taip pat naudojami tokie laisvai platinami komponentai su veikimo apribojimais kaip Fuse. Nėra metaduomenų paslaugų, kurios riboja saugyklos našumą ir atsparumo gedimams galimybes paskirstant failus į blokus. Geresnius našumo rodiklius galima pastebėti naudojant „Distributed Replicated“ konfigūraciją, o mazgų skaičius turėtų būti bent 6, kad būtų sukurta patikima kopija 3 su optimaliu apkrovos paskirstymu.
Šios išvados taip pat yra susijusios su vartotojo patirties aprašymu ir lyginant su , taip pat pateikiamas patirties aprašymas, leidžiantis suprasti šią produktyvesnę ir patikimesnę konfigūraciją
Paveikslėlyje parodytas apkrovos pasiskirstymas rašant du failus, kur pirmojo failo kopijos yra paskirstytos per pirmuosius tris serverius, kurie yra sujungti į 0 tomo grupę, o trys antrojo failo kopijos dedamos ant antrosios grupės tomas1 iš trijų serveriai. Kiekvienas serveris turi vieną diską.
Bendra išvada yra tokia, kad galite naudoti Gluster, tačiau suprasdami, kad bus našumo ir gedimų tolerancijos apribojimai, dėl kurių kyla sunkumų esant tam tikroms hiperkonverguoto sprendimo sąlygoms, kai ištekliai taip pat reikalingi virtualių aplinkų skaičiavimo apkrovoms.
Taip pat yra keletas „Gluster“ veiklos rodiklių, kuriuos galima pasiekti tam tikromis sąlygomis, tik
Cef
Dabar pažiūrėkime į Cephą iš architektūros aprašymų, kuriuos galėjau padaryti Taip pat yra palyginimas tarp , kur iš karto galite suprasti, kad patartina Ceph diegti atskiruose serveriuose, nes jo paslaugoms reikalingi visi apkraunami aparatūros ištekliai.
Architektūra sudėtingesnis nei Gluster ir yra paslaugų, tokių kaip metaduomenų paslaugos, tačiau visas komponentų krūvas yra gana sudėtingas ir nėra labai lankstus naudoti virtualizacijos sprendime. Duomenys saugomi blokuose, kurie atrodo produktyviau, tačiau visų paslaugų (komponentų) hierarchijoje atsiranda nuostolių ir delsos tam tikromis apkrovomis ir avarinėmis sąlygomis, pvz.
Iš architektūros aprašymo širdis yra CRUSH, kurios dėka parenkama duomenų saugojimo vieta. Toliau ateina PG – tai sunkiausiai suprantama abstrakcija (loginė grupė). PG reikalingi, kad CRUSH būtų efektyvesnis. Pagrindinis PG tikslas yra grupuoti objektus, siekiant sumažinti išteklių suvartojimą, padidinti našumą ir mastelį. Objektų adresavimas tiesiogiai, individualiai, nejungiant jų į PG, būtų labai brangus. OSD yra paslauga kiekvienam atskiram diskui.
Klasteris gali turėti vieną arba kelis duomenų telkinius, skirtus skirtingiems tikslams ir su skirtingais parametrais. Baseinai skirstomi į išdėstymo grupes. Vietų grupėse saugomi objektai, kuriuos pasiekia klientai. Čia baigiasi loginis lygis ir prasideda fizinis lygis, nes kiekvienai talpinimo grupei priskiriamas vienas pagrindinis diskas ir keli kopijų diskai (kiek tiksliai priklauso nuo telkinio replikacijos faktoriaus). Kitaip tariant, loginiu lygmeniu objektas saugomas tam tikroje talpinimo grupėje, o fiziniame – jam priskirtuose diskuose. Tokiu atveju diskai fiziškai gali būti skirtinguose mazguose ar net skirtinguose duomenų centruose.
Šioje schemoje įdėjimo grupės atrodo kaip būtinas viso sprendimo lankstumo lygis, bet tuo pačiu ir kaip papildoma grandis šioje grandinėje, kuri netyčia rodo produktyvumo praradimą. Pavyzdžiui, rašant duomenis, sistema turi juos suskirstyti į šias grupes, o tada fiziniu lygiu į pagrindinį diską ir diskus kopijoms. Tai yra, Hash funkcija veikia ieškant ir įterpiant objektą, tačiau yra šalutinis poveikis – tai labai didelės išlaidos ir apribojimai atkuriant maišą (pridedant ar pašalinant diską). Kita maišos problema yra aiškiai nustatyta duomenų vieta, kurios negalima pakeisti. Tai yra, jei diskas kažkaip yra padidintas, tada sistema neturi galimybės į jį nerašyti (pasirinkus kitą diską), maišos funkcija įpareigoja duomenis rasti pagal taisyklę, kad ir kaip blogai diskas yra, todėl Ceph suvalgo daug atminties, kai atkuria PG savaiminio išgydymo ar padidinimo saugyklos atveju. Daroma išvada, kad Ceph veikia gerai (nors ir lėtai), bet tik tada, kai nėra mastelio, avarinių situacijų ar atnaujinimų.
Žinoma, yra galimybių padidinti našumą naudojant talpyklą ir talpyklos bendrinimą, tačiau tam reikia geros aparatinės įrangos ir vis tiek bus nuostolių. Tačiau apskritai Ceph atrodo patraukliau nei Gluster produktyvumui. Be to, naudojant šiuos produktus, būtina atsižvelgti į svarbų veiksnį - tai aukštas kompetencijos, patirties ir profesionalumo lygis, daug dėmesio skiriant Linux, nes labai svarbu viską teisingai įdiegti, konfigūruoti ir prižiūrėti, o tai administratoriui užkrauna dar didesnę atsakomybę ir naštą.
Vstorage
Architektūra atrodo dar įdomiau , kuris gali būti naudojamas kartu su hipervizoriumi tuose pačiuose mazguose, tame pačiame , tačiau labai svarbu viską teisingai sukonfigūruoti, kad būtų pasiektas geras našumas. Tai reiškia, kad tokio produkto įdiegimas iš dėžutės bet kokioje konfigūracijoje, neatsižvelgiant į rekomendacijas pagal architektūrą, bus labai lengvas, bet neproduktyvus.
Kas gali egzistuoti saugojimui šalia „kvm-qemu“ hipervizoriaus paslaugų, ir tai tik kelios paslaugos, kuriose buvo rasta kompaktiška optimali komponentų hierarchija: klientų aptarnavimas, montuojamas per FUSE (modifikuotas, ne atviro kodo), MDS metaduomenų paslauga (Metaduomenų paslauga), paslauga Chunk paslaugų duomenų blokai, kurie fiziniu lygiu yra lygūs vienam diskui ir viskas. Kalbant apie greitį, žinoma, optimalu naudoti gedimams atsparią schemą su dviem kopijomis, tačiau jei SSD diskuose naudojate talpyklą ir žurnalus, klaidoms atsparus kodavimas (kodavimo trynimas arba raid6) gali būti tinkamai padidintas. hibridinė schema arba dar geriau visose blykstėse. Su EC (erase coding) yra tam tikras trūkumas: keičiant vieną duomenų bloką, reikia perskaičiuoti pariteto sumas. Siekdamas apeiti su šia operacija susijusius nuostolius, Ceph rašo į EC atidėtai ir tam tikros užklausos metu gali kilti našumo problemų, kai, pavyzdžiui, reikia nuskaityti visus blokus, o Virtuozzo Storage atveju rašomi pakeisti blokai. naudojant „loginės struktūros failų sistemos“ metodą, kuris sumažina pariteto skaičiavimo išlaidas. Norint apytiksliai įvertinti darbo pagreitinimo galimybes su EC ir be jos, yra – skaičiai gali būti apytiksliai priklausomai nuo įrangos gamintojo tikslumo koeficiento, tačiau skaičiavimų rezultatas yra gera pagalba planuojant konfigūraciją.
Paprasta saugojimo komponentų schema nereiškia, kad šie komponentai neįsisavina bet jei visas išlaidas paskaičiuosite iš anksto, galite tikėtis bendradarbiavimo šalia hipervizoriaus.
Yra Ceph ir Virtuozzo saugojimo tarnybų techninės įrangos išteklių sunaudojimo palyginimo schema.
Jei anksčiau buvo galima palyginti Gluster ir Ceph naudojant senus straipsnius, naudojant svarbiausias jų eilutes, tai su Virtuozzo tai yra sunkiau. Straipsnių apie šį produktą nėra daug, o informaciją galima gauti tik iš dokumentacijos arba rusų kalba, jei „Vstorage“ laikome saugykla, naudojama kai kuriuose hiperkonverguotuose sprendimuose tokiose įmonėse kaip ir Acronis.
Pabandysiu padėti šios architektūros aprašymu, tad bus šiek tiek daugiau teksto, bet pačiam suprasti dokumentaciją užtrunka nemažai laiko, o esama dokumentacija gali būti naudojama tik kaip nuoroda peržiūrėjus lentelę turinio arba paieška pagal raktinį žodį.
Panagrinėkime įrašymo procesą naudojant hibridinę aparatinės įrangos konfigūraciją su aukščiau aprašytais komponentais: įrašymas pradedamas vesti į mazgą, iš kurio klientas jį inicijavo (FUSE prijungimo taško paslauga), bet, žinoma, metaduomenų tarnybos (MDS) pagrindinis komponentas. nukreipti klientą tiesiai į norimą gabalo paslaugą (saugyklos paslaugos CS blokai), tai yra, MDS nedalyvauja įrašymo procese, o tiesiog nukreipia paslaugą į reikiamą gabalą. Apskritai galime pateikti analogiją įrašymui su vandens pilimu į statines. Kiekviena statinė yra 256 MB duomenų blokas.
Tai yra, vienas diskas yra tam tikras tokių statinių skaičius, tai yra, disko tūris padalintas iš 256 MB. Kiekviena kopija paskirstoma vienam mazgui, antra beveik lygiagrečiai kitam mazgui ir t.t... Jei turime tris kopijas ir yra SSD diskai talpyklai (logams skaityti ir rašyti), tai parašius įvyks rašymo patvirtinimas. žurnalas į SSD, o lygiagretus atstatymas iš SSD bus tęsiamas HDD, tarsi fone. Trijų kopijų atveju įrašas bus atliktas patvirtinus trečiojo mazgo SSD. Gali atrodyti, kad trijų SSD diskų įrašymo greičio sumą galima padalyti iš trijų ir gausime vienos replikos įrašymo greitį, tačiau kopijos rašomos lygiagrečiai ir tinklo latentinis greitis dažniausiai būna didesnis nei SSD, ir iš tikrųjų rašymo našumas priklausys nuo tinklo. Šiuo atžvilgiu, norėdami pamatyti tikrą IOPS, turite teisingai įkelti visą Vstorage by , tai yra tikros apkrovos, o ne atminties ir talpyklos testavimas, kur reikia atsižvelgti į teisingą duomenų bloko dydį, gijų skaičių ir pan.
Minėtas įrašymo žurnalas SSD veikia taip, kad kai tik į jį patenka duomenys, servisas jį iškart perskaito ir įrašo į HDD. Viename klasteryje yra kelios metaduomenų paslaugos (MDS), o jų skaičius nustatomas pagal kvorumą, kuris veikia pagal Paxos algoritmą. Kliento požiūriu FUSE prijungimo taškas yra klasterio saugyklos aplankas, kurį vienu metu mato visi klasterio mazgai, kiekvienas mazgas turi prijungtą klientą pagal šį principą, todėl ši saugykla yra prieinama kiekvienam mazgui.
Norint atlikti bet kurį iš aukščiau aprašytų metodų, labai svarbu planavimo ir diegimo etape teisingai sukonfigūruoti tinklą, kuriame bus balansavimas dėl agregavimo ir tinkamai parinkto tinklo kanalo pralaidumo. Apibendrinant svarbu pasirinkti tinkamą maišos režimą ir kadrų dydžius. Taip pat yra labai didelis skirtumas nuo aukščiau aprašyto SDS, tai yra saugiklis su greito kelio technologija Virtuozzo Storage. Kuris, be modernizuoto saugiklio, skirtingai nei kiti atvirojo kodo sprendimai, žymiai padidina IOPS ir leidžia neapsiriboti horizontaliu ar vertikaliu mastelio keitimu. Apskritai, lyginant su aukščiau aprašytomis architektūromis, ši atrodo galingesnė, tačiau tokiam malonumui, žinoma, reikia įsigyti licencijas, skirtingai nei Ceph ir Gluster.
Apibendrinant, galime išskirti geriausius iš trijų: „Virtuozzo Storage“ užima pirmąją vietą pagal architektūros našumą ir patikimumą, „Ceph“ užima antrąją vietą, o „Gluster“ – trečią.
Kriterijai, pagal kuriuos buvo pasirinkta „Virtuozzo Storage“, yra optimalus architektūrinių komponentų rinkinys, modernizuotas pagal šį „Fuse“ metodą su greitu keliu, lanksčiu aparatinės įrangos konfigūracijų rinkiniu, mažesniu išteklių suvartojimu ir galimybe dalytis su skaičiavimu (kompiuterija / virtualizacija), tai yra, jis visiškai tinka hiperkonverguotam sprendimui , kurio dalis jis yra. Antroji vieta yra Ceph, nes ji yra produktyvesnė architektūra, palyginti su Gluster, dėl savo veikimo blokuose, taip pat dėl lankstesnių scenarijų ir galimybės dirbti didesniuose klasteriuose.
Planuojama parašyti vSAN, Space Direct Storage, Vstorage ir Nutanix Storage palyginimą, Vstorage testavimą HPE ir Huawei įrangoje, taip pat Vstorage integravimo su išorinėmis aparatūros saugojimo sistemomis scenarijus, tad jei straipsnis patiko, malonu gauti iš jūsų atsiliepimų , kurie gali padidinti motyvaciją naujiems straipsniams, atsižvelgiant į jūsų pastabas ir pageidavimus.
Šaltinis: www.habr.com