Ta članek je bil napisan, da bi vam pomagal izbrati pravo rešitev zase in razumeti razlike med SDS, kot so Gluster, Ceph in Vstorage (Virtuozzo).
Besedilo uporablja povezave do člankov s podrobnejšim razkritjem določenih problemov, zato bodo opisi čim krajši, z uporabo ključnih točk brez nepotrebnega napihovanja in uvodnih informacij, ki jih lahko po želji samostojno pridobite na internetu.
Pravzaprav seveda obravnavane teme zahtevajo tone besedila, vendar v sodobnem svetu vse več ljudi ne mara veliko brati))), tako da lahko hitro preberete in se odločite, in če je kaj ni jasno, sledite povezavam ali google nejasne besede))), in ta članek je kot prozoren ovoj za te globoke teme, ki prikazuje polnilo - glavne ključne točke vsake odločitve.
gluster
Začnimo z Glusterjem, ki ga aktivno uporabljajo proizvajalci hiperkonvergiranih platform z SDS, ki temeljijo na odprti kodi za virtualna okolja in ga najdete na spletni strani RedHat v razdelku za shranjevanje, kjer lahko izbirate med dvema možnostma SDS: Gluster ali Ceph.
Gluster je sestavljen iz niza prevajalcev - storitev, ki opravljajo vse delo distribucije datotek itd. Brick je storitev, ki servisira en disk, Volume je volumen (pool), ki te zidake združuje. Sledi storitev za razdeljevanje datotek v skupine s pomočjo funkcije DHT (distributed hash table). Storitve Sharding ne bomo vključili v opis, saj bodo spodnje povezave opisale težave, povezane z njo.
Pri pisanju se celotna datoteka shrani v opeko, njena kopija pa se istočasno zapiše v opeko na drugem strežniku. Nato bo druga datoteka zapisana v drugo skupino dveh kock (ali več) na različnih strežnikih.
Če so datoteke približno enake velikosti in je nosilec sestavljen samo iz ene skupine, potem je vse v redu, pod drugimi pogoji pa bodo iz opisov nastale naslednje težave:
- prostor v skupinah je neenakomerno izkoriščen, odvisno od velikosti datotek in če v skupini ni dovolj prostora za pisanje datoteke, se prikaže napaka, datoteka ne bo zapisana in ne bo prerazporejena drugi skupini ;
- pri pisanju ene datoteke gre IO le v eno skupino, ostale so v mirovanju;
- pri pisanju ene datoteke ne morete dobiti IO celotnega nosilca;
- in splošni koncept je videti manj produktiven zaradi pomanjkanja porazdelitve podatkov v bloke, kjer je lažje uravnotežiti in rešiti problem enotne porazdelitve, in ne kot zdaj gre celotna datoteka v blok.
Iz uradnega opisa nehote pridemo tudi do spoznanja, da gluster deluje kot shramba datotek povrh klasičnega strojnega RAID-a. Obstajajo razvojni poskusi razreza (Sharding) datotek na bloke, vendar je vse to dodatek, ki povzroča izgube zmogljivosti že obstoječemu arhitekturnemu pristopu, poleg tega pa se uporablja tudi prosto distribuirana komponenta z omejitvami zmogljivosti, kot je Fuse. Ni metapodatkovnih storitev, kar omejuje zmogljivost in zmožnosti tolerance napak shranjevanja pri razdeljevanju datotek v bloke. Boljše kazalnike učinkovitosti je mogoče opaziti s konfiguracijo »Distributed Replicated«, število vozlišč pa mora biti vsaj 6, da se organizira zanesljiva replika 3 z optimalno porazdelitvijo obremenitve.
Te ugotovitve so povezane tudi z opisom uporabniške izkušnje in v primerjavi z , na voljo pa je tudi opis izkušenj, ki vodijo do razumevanja te bolj produktivne in zanesljivejše konfiguracije
Na sliki je prikazana porazdelitev obremenitve pri pisanju dveh datotek, kjer so kopije prve datoteke porazdeljene po prvih treh strežnikih, ki so združeni v skupino nosilcev 0, tri kopije druge datoteke pa so nameščene na nosilcih 1 druge skupine treh strežniki. Vsak strežnik ima en disk.
Splošni zaključek je, da lahko uporabljate Gluster, vendar ob upoštevanju, da bodo obstajale omejitve v zmogljivosti in toleranci napak, ki povzročajo težave pod določenimi pogoji hiperkonvergirane rešitve, kjer so viri potrebni tudi za računalniške obremenitve virtualnih okolij.
Obstaja tudi nekaj kazalnikov uspešnosti Gluster, ki jih je mogoče doseči pod določenimi pogoji, omejenimi na
ceph
Zdaj pa poglejmo Cepha iz opisov arhitekture, ki sem jih lahko Obstaja tudi primerjava med , kjer lahko takoj razumete, da je Ceph priporočljivo namestiti na ločene strežnike, saj njegove storitve zahtevajo vse vire strojne opreme pod obremenitvijo.
arhitektura bolj zapleten kot Gluster in obstajajo storitve, kot so metapodatkovne storitve, vendar je celoten nabor komponent precej zapleten in premalo prilagodljiv za uporabo v virtualizacijski rešitvi. Podatki so shranjeni v blokih, kar je videti bolj produktivno, vendar v hierarhiji vseh storitev (komponent) prihaja do izgub in zakasnitev ob določenih obremenitvah in izrednih razmerah, npr.
Iz opisa arhitekture je srce CRUSH, zahvaljujoč kateremu je izbrana lokacija za shranjevanje podatkov. Sledi PG - to je najtežje razumljiva abstrakcija (logična skupina). PG so potrebni, da postane CRUSH učinkovitejši. Glavni namen PG je združevanje predmetov v skupine za zmanjšanje porabe virov, povečanje zmogljivosti in razširljivosti. Naslavljanje objektov neposredno, posamično, brez njihovega združevanja v PG bi bilo zelo drago. OSD je storitev za vsak disk posebej.
Gruča ima lahko eno ali več podatkovnih skupin za različne namene in z različnimi nastavitvami. Bazeni so razdeljeni v skupine umestitev. Skupine umestitev shranjujejo predmete, do katerih odjemalci dostopajo. Tukaj se konča logična raven in začne fizična raven, ker je vsaki umestitveni skupini dodeljen en glavni disk in več replik diskov (koliko natanko je odvisno od faktorja replikacije bazena). Z drugimi besedami, na logični ravni je predmet shranjen v določeni umestitveni skupini, na fizični ravni pa na diskih, ki so mu dodeljeni. V tem primeru se lahko diski fizično nahajajo na različnih vozliščih ali celo v različnih podatkovnih centrih.
V tej shemi so umestitvene skupine videti kot nujen nivo za fleksibilnost celotne rešitve, a hkrati kot dodaten člen v tej verigi, ki nehote nakazuje izgubo produktivnosti. Na primer, pri zapisovanju podatkov mora sistem le-te razdeliti v te skupine in nato na fizičnem nivoju na glavni disk in diske za replike. To pomeni, da funkcija Hash deluje pri iskanju in vstavljanju predmeta, vendar obstaja stranski učinek - to so zelo visoki stroški in omejitve pri obnovi zgoščene vrednosti (pri dodajanju ali odstranjevanju diska). Druga težava z zgoščevanjem je jasno določena lokacija podatkov, ki jih ni mogoče spremeniti. To pomeni, da če je disk nekako pod povečano obremenitvijo, potem sistem nima možnosti, da ne bi pisal nanj (z izbiro drugega diska), funkcija zgoščevanja zahteva, da se podatki nahajajo v skladu s pravilom, ne glede na to, kako slabo disk je, tako da Ceph poje veliko pomnilnika pri obnovi PG v primeru samozdravljenja ali povečanja pomnilnika. Zaključek je, da Ceph deluje dobro (čeprav počasi), vendar le, če ni skaliranja, izrednih situacij ali posodobitev.
Seveda obstajajo možnosti za povečanje zmogljivosti s predpomnjenjem in skupno rabo predpomnilnika, vendar to zahteva dobro strojno opremo in še vedno bodo izgube. Toda na splošno je Ceph glede produktivnosti videti bolj mamljiv kot Gluster. Prav tako je pri uporabi teh produktov potrebno upoštevati pomemben dejavnik - to je visoka raven usposobljenosti, izkušenj in profesionalnosti z velikim poudarkom na Linuxu, saj je zelo pomembno, da vse pravilno namestite, konfigurirate in vzdržujete, kar skrbniku nalaga še večjo odgovornost in obremenitev.
Vstorage
Arhitektura je videti še bolj zanimiva , ki se lahko uporablja v povezavi s hipervizorjem na istih vozliščih, na istem , vendar je zelo pomembno, da vse pravilno konfigurirate, da dosežete dobro delovanje. To pomeni, da bo uvajanje takšnega izdelka iz škatle v katero koli konfiguracijo brez upoštevanja priporočil v skladu z arhitekturo zelo enostavno, vendar ne produktivno.
Kaj lahko soobstaja za shranjevanje poleg storitev hipervizorja kvm-qemu in to je le nekaj storitev, kjer je bila najdena kompaktna optimalna hierarhija komponent: storitev odjemalca, nameščena prek FUSE (spremenjena, ne odprtokodna), storitev metapodatkov MDS (Metapodatkovna storitev), storitev Chunk service data blocks, ki je na fizičnem nivoju enaka enemu disku in to je vse. Kar zadeva hitrost, je seveda optimalno uporabiti shemo, ki je tolerantna na napake, z dvema replikama, če pa uporabljate predpomnjenje in dnevnike na pogonih SSD, potem lahko kodiranje, ki je tolerantno na napake (izbriši kodiranje ali raid6), spodobno pospešite na hibridna shema ali še bolje na all flash. Pri EC (kodiranju brisanja) je nekaj slabosti: pri spreminjanju enega podatkovnega bloka je treba ponovno izračunati paritetne zneske. Če želite zaobiti izgube, povezane s to operacijo, Ceph začasno piše v EC in med določeno zahtevo lahko pride do težav z zmogljivostjo, ko je na primer treba prebrati vse bloke, v primeru Virtuozzo Storage pa se izvede pisanje spremenjenih blokov. z uporabo pristopa "dnevniško strukturiranega datotečnega sistema", ki minimizira stroške izračuna paritete. Če želite približno oceniti možnosti s pospeševanjem dela z in brez EC, obstajajo – številke so lahko približne, odvisno od koeficienta točnosti proizvajalca opreme, vendar je rezultat izračunov dobra pomoč pri načrtovanju konfiguracije.
Preprost diagram komponent za shranjevanje ne pomeni, da te komponente ne absorbirajo če pa vnaprej izračunate vse stroške, lahko računate na sodelovanje ob hipervizorju.
Obstaja shema za primerjavo porabe virov strojne opreme s storitvami za shranjevanje Ceph in Virtuozzo.
Če je bilo prej mogoče primerjati Gluster in Ceph s starimi članki, z uporabo najpomembnejših vrstic iz njih, potem je z Virtuozzo težje. O tem izdelku ni veliko člankov in informacije je mogoče pridobiti le iz dokumentacije ali v ruščini, če Vstorage obravnavamo kot shrambo, ki se uporablja v nekaterih hiperkonvergiranih rešitvah v podjetjih, kot je npr in Acronis.
Poskušal bom pomagati z opisom te arhitekture, tako da bo besedila malo več, vendar potrebujete veliko časa, da sami razumete dokumentacijo, obstoječo dokumentacijo pa lahko uporabite le kot referenco s popravkom tabele vsebine ali iskanje po ključnih besedah.
Oglejmo si postopek snemanja v konfiguraciji hibridne strojne opreme z zgoraj opisanimi komponentami: snemanje začne iti v vozlišče, iz katerega ga je sprožil odjemalec (storitev točke namestitve FUSE), vendar bo glavna komponenta storitve metapodatkov (MDS) seveda odjemalca usmeri neposredno na želeno chunk storitev (storage service CS blocks), to pomeni, da MDS ne sodeluje pri procesu snemanja, ampak preprosto usmeri storitev na zahtevani chunk. Na splošno lahko podamo analogijo snemanja z nalivanjem vode v sode. Vsak sod je 256 MB velik podatkovni blok.
To pomeni, da je en disk določeno število takih sodov, to je prostornina diska, deljena z 256 MB. Vsaka kopija je razdeljena na eno vozlišče, druga skoraj vzporedno na drugo vozlišče, itd... Če imamo tri replike in so SSD diski za predpomnilnik (za branje in pisanje dnevnikov), potem bo potrditev pisanja po pisanju. dnevnik na SSD, vzporedna ponastavitev s SSD-ja pa se bo nadaljevala na HDD, kot v ozadju. V primeru treh replik bo zapis potrjen po potrditvi SSD-ja tretjega vozlišča. Morda se zdi, da lahko vsoto hitrosti pisanja treh SSD-jev delimo s tri in dobimo hitrost pisanja ene replike, vendar se kopije pišejo vzporedno in hitrost omrežne zakasnitve je običajno višja od hitrosti SSD-ja, in dejansko bo zmogljivost pisanja odvisna od omrežja. V zvezi s tem, če želite videti dejanske IOPS, morate pravilno naložiti celotno Vstorage do , torej testiranje realne obremenitve in ne pomnilnika in predpomnilnika, kjer je treba upoštevati pravilno velikost podatkovnega bloka, število niti ipd.
Zgoraj omenjeni snemalni dnevnik na SSD deluje tako, da takoj, ko vanj pridejo podatki, jih servis takoj prebere in zapiše na HDD. Na gručo je več metapodatkovnih storitev (MDS), njihovo število pa določa kvorum, ki deluje po algoritmu Paxos. Z vidika odjemalca je FUSE mount point mapa za shranjevanje gruče, ki je hkrati vidna vsem vozliščem v gruči, vsako vozlišče ima po tem principu nameščenega odjemalca, tako da je ta shramba na voljo vsakemu vozlišču.
Za izvedbo katerega koli od zgoraj opisanih pristopov je zelo pomembno, da v fazi načrtovanja in uvajanja pravilno konfigurirate omrežje, kjer bo prišlo do uravnoteženja zaradi združevanja in pravilno izbrane pasovne širine omrežnega kanala. Pri združevanju je pomembno izbrati pravi način zgoščevanja in velikosti okvirjev. Obstaja tudi zelo velika razlika od zgoraj opisanega SDS, to je zlitje s tehnologijo hitre poti v Virtuozzo Storage. Kar poleg posodobljene varovalke za razliko od drugih odprtokodnih rešitev bistveno poveča IOPS in omogoča, da niste omejeni s horizontalnim ali vertikalnim skaliranjem. Na splošno je ta v primerjavi z zgoraj opisanimi arhitekturami videti zmogljivejša, vendar je za takšno veselje seveda treba kupiti licence, za razliko od Cepha in Glusterja.
Če povzamemo, lahko izpostavimo vrh trojice: Virtuozzo Storage zaseda prvo mesto glede zmogljivosti in zanesljivosti arhitekture, Ceph drugo mesto, Gluster pa tretje mesto.
Kriteriji, po katerih je bil izbran Virtuozzo Storage: je optimalen nabor arhitekturnih komponent, posodobljen za ta pristop Fuse s hitro potjo, prilagodljivim naborom konfiguracij strojne opreme, manjšo porabo virov in možnostjo deljenja z računalništvom (računalništvo/virtualizacija), to pomeni, da je popolnoma primeren za hiperkonvergirano rešitev, katere del je. Na drugem mestu je Ceph, ker je bolj produktivna arhitektura v primerjavi z Glusterjem, tako zaradi delovanja v blokih kot tudi zaradi bolj prilagodljivih scenarijev in zmožnosti dela v večjih grozdih.
Načrtuje se pisanje primerjave med vSAN, Space Direct Storage, Vstorage in Nutanix Storage, testiranje Vstorage na opremi HPE in Huawei, kot tudi scenariji za integracijo Vstorage z zunanjimi sistemi za shranjevanje strojne opreme, tako da če vam je bil članek všeč, bi bil Lepo je dobiti povratne informacije od vas, kar bi lahko povečalo motivacijo za nove članke, ob upoštevanju vaših komentarjev in želja.
Vir: www.habr.com