Tento článok bol napísaný, aby vám pomohol vybrať si pre seba správne riešenie a pochopiť rozdiely medzi SDS, ako sú Gluster, Ceph a Vstorage (Virtuozzo).
V texte sú použité odkazy na články s detailnejším popisom niektorých problémov, takže popisy budú čo najstručnejšie, s kľúčovými bodmi bez zbytočných zbytočností a s úvodnými informáciami, ktoré si môžete, ak chcete, samostatne získať na internete.
V skutočnosti si nastolené témy, samozrejme, vyžadujú tóny textu, ale v modernom svete stále viac ľudí neradi číta veľa))), takže môžete rýchlo čítať a vybrať si, a ak niečo je nie je jasné, postupujte podľa odkazov alebo si vygooglite nejasné slová))) a tento článok je ako priehľadný obal pre tieto hlboké témy, ktorý zobrazuje náplň - hlavné kľúčové body každého rozhodnutia.
Trblietanie
Začnime Glusterom, ktorý aktívne využívajú výrobcovia hyperkonvergovaných platforiem s SDS na báze open source pre virtuálne prostredia a nájdete ho na stránke RedHat v sekcii storage, kde si môžete vybrať z dvoch možností SDS: Gluster alebo Ceph.
Gluster pozostáva zo zásobníka prekladateľov - služieb, ktoré vykonávajú všetku prácu pri distribúcii súborov atď. Brick je služba, ktorá obsluhuje jeden disk, Volume je zväzok (pool), ktorý tieto kocky spája. Nasleduje služba na distribúciu súborov do skupín pomocou funkcie DHT (distribuovaná hašovacia tabuľka). Službu Sharding nezahrnieme do popisu, pretože nižšie uvedené odkazy popisujú problémy s ňou spojené.
Pri zápise sa celý súbor uloží do tehly a jeho kópia sa súčasne zapíše do tehly na druhom serveri. Potom bude druhý súbor zapísaný do druhej skupiny dvoch kociek (alebo viacerých) na rôznych serveroch.
Ak sú súbory približne rovnakej veľkosti a zväzok pozostáva iba z jednej skupiny, potom je všetko v poriadku, ale za iných podmienok z popisov vyplynú nasledujúce problémy:
- priestor v skupinách sa využíva nerovnomerne, závisí od veľkosti súborov a ak v skupine nie je dostatok miesta na zapísanie súboru, zobrazí sa chyba, súbor sa nezapíše a nebude prerozdelený do inej skupiny ;
- pri zápise jedného súboru ide IO len do jednej skupiny, ostatné sú nečinné;
- pri zápise jedného súboru nemôžete získať IO celého zväzku;
- a všeobecná koncepcia vyzerá menej produktívne kvôli nedostatku distribúcie údajov do blokov, kde je jednoduchšie vyvážiť a vyriešiť problém rovnomernej distribúcie, a nie ako teraz celý súbor ide do bloku.
Z oficiálneho popisu mimovoľne tiež prichádzame na to, že gluster funguje ako úložisko súborov nad klasickým hardvérovým RAID. Vyskytli sa vývojové pokusy o rozrezanie (Sharding) súborov na bloky, ale toto všetko je prídavok, ktorý spôsobuje straty výkonu na už existujúcom architektonickom prístupe, plus použitie takých voľne distribuovaných komponentov s obmedzeniami výkonu, ako je Fuse. Neexistujú žiadne služby metadát, čo obmedzuje výkon a schopnosti úložiska odolávať chybám pri distribúcii súborov do blokov. Lepšie ukazovatele výkonu možno pozorovať pri konfigurácii „Distributed Replicated“ a počet uzlov by mal byť aspoň 6, aby sa zorganizovala spoľahlivá replika 3 s optimálnym rozložením zaťaženia.
Tieto zistenia súvisia aj s popisom používateľskej skúsenosti a pri porovnaní s a je tam aj popis skúseností vedúcich k pochopeniu tejto produktívnejšej a spoľahlivejšej konfigurácie
Obrázok ukazuje rozloženie zaťaženia pri zápise dvoch súborov, kde kópie prvého súboru sú distribuované cez prvé tri servery, ktoré sú spojené do skupiny zväzku 0, a tri kópie druhého súboru sú umiestnené na zväzku druhej skupiny1 z troch serverov. Každý server má jeden disk.
Všeobecným záverom je, že môžete použiť Gluster, ale s tým, že budú existovať obmedzenia vo výkone a odolnosti voči chybám, ktoré spôsobujú ťažkosti za určitých podmienok hyperkonvergovaného riešenia, kde sú potrebné zdroje aj na výpočtovú záťaž virtuálnych prostredí.
Existujú aj niektoré ukazovatele výkonnosti Gluster, ktoré je možné dosiahnuť za určitých podmienok, obmedzené na
CEF
Teraz sa pozrime na Ceph z popisov architektúry, ktoré sa mi podarilo Existuje aj porovnanie medzi , kde okamžite pochopíte, že je vhodné nasadiť Ceph na samostatné servery, keďže jeho služby vyžadujú všetky hardvérové zdroje pod záťažou.
architektúra zložitejšie ako Gluster a existujú služby ako metaúdajové služby, ale celý balík komponentov je dosť zložitý a nie je príliš flexibilný na použitie vo virtualizačnom riešení. Dáta sa ukladajú do blokov, čo vyzerá produktívnejšie, ale v hierarchii všetkých služieb (komponentov) dochádza pri určitých záťažiach a núdzových podmienkach k stratám a oneskoreniu, napr.
Z popisu architektúry je srdcom CRUSH, vďaka ktorému sa vyberá miesto pre ukladanie dát. Nasleduje PG - toto je najťažšia abstrakcia (logická skupina) na pochopenie. PG sú potrebné na zefektívnenie CRUSH. Hlavným účelom PG je zoskupovať objekty s cieľom znížiť spotrebu zdrojov, zvýšiť výkon a škálovateľnosť. Adresovanie objektov priamo, jednotlivo, bez ich kombinovania do PG by bolo veľmi drahé. OSD je služba pre každý jednotlivý disk.
Klaster môže mať jednu alebo viacero oblastí údajov na rôzne účely a s rôznymi nastaveniami. Bazény sú rozdelené do skupín umiestnení. Skupiny umiestnení ukladajú objekty, ku ktorým klienti pristupujú. Tu končí logická úroveň a začína fyzická úroveň, pretože každej skupine umiestnení je priradený jeden hlavný disk a niekoľko replikových diskov (koľko presne závisí od faktora replikácie fondu). Inými slovami, na logickej úrovni je objekt uložený v špecifickej skupine umiestnení a na fyzickej úrovni - na diskoch, ktoré sú mu priradené. V tomto prípade môžu byť disky fyzicky umiestnené na rôznych uzloch alebo dokonca v rôznych dátových centrách.
V tejto schéme vyzerajú skupiny umiestnení ako nevyhnutná úroveň pre flexibilitu celého riešenia, ale zároveň ako ďalší článok v tomto reťazci, ktorý mimovoľne naznačuje stratu produktivity. Napríklad pri zápise dát ich systém potrebuje rozdeliť do týchto skupín a potom na fyzickej úrovni na hlavný disk a disky pre repliky. To znamená, že funkcia Hash funguje pri vyhľadávaní a vkladaní objektu, ale má to vedľajší efekt - sú to veľmi vysoké náklady a obmedzenia pri prestavbe hashu (pri pridávaní alebo odoberaní disku). Ďalším problémom hash je jasne označené umiestnenie údajov, ktoré nemožno zmeniť. To znamená, že ak je disk nejakým spôsobom zvýšený, systém nemá možnosť naň nezapísať (výberom iného disku), hašovacia funkcia zaväzuje údaje lokalizovať podľa pravidla, nech je akokoľvek zlé disk je, takže Ceph žerie veľa pamäte pri prestavbe PG v prípade samoliečenia alebo zvýšenia úložiska. Záver je, že Ceph funguje dobre (aj keď pomaly), ale iba vtedy, keď nedochádza k žiadnemu škálovaniu, núdzovým situáciám alebo aktualizáciám.
Existujú samozrejme možnosti na zvýšenie výkonu pomocou vyrovnávacej pamäte a zdieľania vyrovnávacej pamäte, ale to si vyžaduje dobrý hardvér a stále budú straty. Celkovo však Ceph vyzerá z hľadiska produktivity lákavejšie ako Gluster. Taktiež pri používaní týchto produktov je potrebné brať do úvahy dôležitý faktor - ide o vysokú úroveň kompetencie, skúseností a profesionality s veľkým dôrazom na Linux, keďže je veľmi dôležité všetko správne nasadiť, nakonfigurovať a podporovať, čo na správcu kladie ešte väčšiu zodpovednosť a záťaž.
Vskladovanie
Architektúra vyzerá ešte zaujímavejšie , ktorý možno použiť v spojení s hypervízorom na rovnakých uzloch, na tom istom , ale pre dosiahnutie dobrého výkonu je veľmi dôležité všetko správne nakonfigurovať. To znamená, že nasadenie takéhoto produktu z krabice na akúkoľvek konfiguráciu bez zohľadnenia odporúčaní v súlade s architektúrou bude veľmi jednoduché, ale nie produktívne.
Čo môže existovať pre úložisko vedľa služieb hypervízora kvm-qemu, a to je len niekoľko služieb, kde sa našla kompaktná optimálna hierarchia komponentov: klientska služba namontovaná cez FUSE (upravená, nie open source), služba metadát MDS (služba metadát), servisné bloky údajov služby Chunk, ktoré sa na fyzickej úrovni rovnajú jednému disku a to je všetko. Z hľadiska rýchlosti je samozrejme optimálne použiť schému odolnú voči chybám s dvomi replikami, ale ak použijete cachovanie a logy na SSD diskoch, potom sa kódovanie odolné voči chybám (erase coding alebo raid6) dá slušne pretaktovať na hybridnú schému alebo ešte lepšie na všetky blesky. Pri EC (erase coding) existuje určitá nevýhoda: pri zmene jedného dátového bloku je potrebné prepočítať paritné čiastky. Aby sa obišli straty spojené s touto operáciou, Ceph zapisuje do EC odloženým spôsobom a pri určitej požiadavke môžu nastať problémy s výkonom, keď je napríklad potrebné prečítať všetky bloky a v prípade Virtuozzo Storage zapisovať zmenené bloky. sa vykonáva pomocou prístupu „súborového systému so štruktúrou denníka“, ktorý minimalizuje náklady na výpočet parity. Na odhad približne možností so zrýchlením práce s a bez EC existuje – čísla môžu byť približné v závislosti od koeficientu presnosti výrobcu zariadenia, ale výsledok výpočtov je dobrou pomôckou pri plánovaní konfigurácie.
Jednoduchá schéma skladovacích komponentov neznamená, že tieto komponenty neabsorbujú ale ak si vopred spočítate všetky náklady, môžete počítať so spoluprácou popri hypervízore.
Existuje schéma na porovnanie spotreby hardvérových zdrojov úložnými službami Ceph a Virtuozzo.
Ak bolo predtým možné porovnať Gluster a Ceph pomocou starých článkov pomocou najdôležitejších riadkov z nich, potom s Virtuozzo je to ťažšie. O tomto produkte nie je veľa článkov a informácie je možné získať len z dokumentácie na alebo v ruštine ak Vstorage považujeme za úložisko používané v niektorých hyperkonvergovaných riešeniach vo firmách ako napr a Acronis.
Pokúsim sa pomôcť s popisom tejto architektúry, takže textu bude trochu viac, ale pochopenie dokumentácie si vyžaduje veľa času a existujúcu dokumentáciu je možné použiť iba ako referenciu pri revízii tabuľky obsahu alebo vyhľadávanie podľa kľúčového slova.
Zoberme si proces nahrávania v hybridnej hardvérovej konfigurácii s komponentmi opísanými vyššie: nahrávanie začne smerovať do uzla, z ktorého ho klient inicioval (služba bodu pripojenia FUSE), ale hlavný komponent Metadata Service (MDS) samozrejme nasmerovať klienta priamo na požadovanú službu chunk (bloky CS ukladacej služby), to znamená, že MDS sa nezúčastňuje procesu nahrávania, ale jednoducho nasmeruje službu na požadovaný chunk. Vo všeobecnosti môžeme dať prirovnanie k nahrávaniu s nalievaním vody do sudov. Každý barel je dátový blok s veľkosťou 256 MB.
To znamená, že jeden disk je určitý počet takýchto sudov, to znamená, že objem disku vydelený 256 MB. Každá kópia je distribuovaná do jedného uzla, druhá takmer paralelne s iným uzlom atď... Ak máme tri repliky a sú tam SSD disky pre cache (na čítanie a zápis logov), tak po zápise dôjde k potvrdeniu zápisu log na SSD a paralelný reset z SSD bude pokračovať na HDD, akoby na pozadí. V prípade troch replík bude záznam potvrdený po potvrdení z SSD tretieho uzla. Môže sa zdať, že súčet rýchlosti zápisu troch SSD sa dá vydeliť tromi a dostaneme rýchlosť zápisu jednej repliky, no kópie sa zapisujú paralelne a rýchlosť latencie siete je zvyčajne vyššia ako pri SSD, a v skutočnosti bude výkon zápisu závisieť od siete. V tomto ohľade, aby ste videli skutočné IOPS, musíte správne načítať celé úložisko V , teda testovanie reálnej záťaže, a nie pamäte a cache, kde je potrebné brať do úvahy správnu veľkosť bloku dát, počet vlákien atď.
Vyššie spomínaný záznam záznamu na SSD funguje tak, že akonáhle sa do neho dostanú dáta, okamžite ich služba načíta a zapíše na HDD. V jednom klastri je niekoľko metadátových služieb (MDS) a ich počet je určený kvórom, ktoré pracuje podľa algoritmu Paxos. Z pohľadu klienta je bod pripojenia FUSE priečinok úložiska klastra, ktorý je súčasne viditeľný pre všetky uzly v klastri, každý uzol má na tomto princípe pripojeného klienta, takže toto úložisko je dostupné pre každý uzol.
Pre realizáciu ktoréhokoľvek z vyššie opísaných prístupov je veľmi dôležité, vo fáze plánovania a nasadenia, správne nakonfigurovať sieť, kde bude dochádzať k vyvažovaniu vďaka agregácii a správne zvolenej šírke pásma sieťového kanála. Pri agregácii je dôležité zvoliť správny režim hashovania a veľkosti snímok. Je tu tiež veľmi výrazný rozdiel od vyššie opísanej SDS, ide o poistku s technológiou rýchlej cesty vo Virtuozzo Storage. Čo okrem modernizovanej poistky na rozdiel od iných open source riešení výrazne zvyšuje IOPS a umožňuje neobmedzovať sa horizontálnym ani vertikálnym škálovaním. Vo všeobecnosti, v porovnaní s vyššie popísanými architektúrami, táto vyzerá výkonnejšie, ale pre takéto potešenie je samozrejme potrebné zakúpiť licencie, na rozdiel od Ceph a Gluster.
Aby sme to zhrnuli, môžeme vyzdvihnúť top z troch: Virtuozzo Storage je na prvom mieste z hľadiska výkonu a spoľahlivosti architektúry, Ceph je na druhom mieste a Gluster na treťom mieste.
Kritériá, podľa ktorých bol Virtuozzo Storage vybraný: ide o optimálnu sadu architektonických komponentov modernizovaných pre tento prístup Fuse s rýchlou cestou, flexibilný súbor hardvérových konfigurácií, menšiu spotrebu zdrojov a schopnosť zdieľať s výpočtovou technikou (výpočet/virtualizácia), to znamená, že je úplne vhodný pre hyperkonvergované riešenie, ktorého je súčasťou. Na druhom mieste je Ceph, pretože ide o produktívnejšiu architektúru v porovnaní s Glusterom, vďaka fungovaniu v blokoch, ako aj flexibilnejším scenárom a schopnosti pracovať vo väčších klastroch.
V pláne je napísať porovnanie medzi vSAN, Space Direct Storage, Vstorage a Nutanix Storage, testovanie Vstorage na zariadeniach HPE a Huawei, ako aj scenáre integrácie Vstorage s externými hardvérovými úložnými systémami, takže ak by sa vám článok páčil, bol by je pekné, že od vás dostávam spätnú väzbu, ktorá by mohla zvýšiť motiváciu pre nové články, berúc do úvahy vaše komentáre a želania.
Zdroj: hab.com