Dobrý den, čtenáři Habra. Tímto článkem otevíráme sérii, která bude hovořit o hyperkonvergovaném systému AERODISK vAIR, který jsme vyvinuli. Původně jsme chtěli vše o všem říct v prvním článku, ale systém je poměrně složitý, takže slona budeme jíst po částech.
Začněme příběh historií vzniku systému, ponoříme se do souborového systému ARDFS, který je základem vAIR, a také si povíme něco málo o umístění tohoto řešení na ruském trhu.
V budoucích článcích budeme hovořit podrobněji o různých architektonických komponentách (cluster, hypervisor, load balancer, monitorovací systém atd.), procesu konfigurace, nastolíme problémy s licencí, samostatně ukážeme crash testy a samozřejmě budeme psát o zátěžovém testování a dimenzování. Komunitní verzi vAIR budeme věnovat také samostatný článek.
Je Aerodisk příběhem o úložných systémech? Nebo proč jsme vůbec začali dělat hyperkonvergenci?
Zpočátku k nám nápad vytvořit vlastní hyperkonvergenci přišel někdy kolem roku 2010. V té době nebyl na trhu Aerodisk ani podobná řešení (komerční krabicové hyperkonvergované systémy). Náš úkol byl následující: ze sady serverů s lokálními disky, spojených propojením přes ethernetový protokol, bylo potřeba vytvořit rozšířené úložiště a spustit tam virtuální stroje a softwarovou síť. To vše se muselo realizovat bez úložných systémů (protože na úložné systémy a jejich hardware prostě nebyly peníze a vlastní úložné systémy jsme ještě nevynalezli).
Vyzkoušeli jsme mnoho open source řešení a nakonec jsme tento problém vyřešili, ale řešení bylo velmi složité a obtížně opakovatelné. Kromě toho bylo toto řešení v kategorii „Funguje to? Nedotýkejte se! Proto jsme po vyřešení tohoto problému dále nerozvíjeli myšlenku transformace výsledku naší práce do plnohodnotného produktu.
Po onom incidentu jsme od této myšlenky ustoupili, ale stále jsme měli pocit, že tento problém je zcela řešitelný a přínosy takového řešení byly více než zřejmé. Následně vydané HCI produkty zahraničních firem tento pocit jen potvrdily.
Proto jsme se v polovině roku 2016 k tomuto úkolu vrátili v rámci tvorby plnohodnotného produktu. V té době jsme ještě neměli žádné vztahy s investory, takže jsme museli koupit developerský stánek za vlastní nepříliš velké peníze. Po shromáždění použitých serverů a přepínačů na Avitu jsme se pustili do práce.
Hlavním prvotním úkolem bylo vytvořit vlastní, byť jednoduchý, ale vlastní souborový systém, který by dokázal automaticky a rovnoměrně distribuovat data ve formě virtuálních bloků na n-tém počtu uzlů clusteru, které jsou propojeny propojovacím rozhraním přes Ethernet. Zároveň by měl FS dobře a snadno škálovat a být nezávislý na sousedních systémech, tzn. být odcizen od vAIR ve formě „pouze skladiště“.
První koncept vAIR
Záměrně jsme opustili používání hotových open source řešení pro organizaci natažených úložišť (ceph, gluster, luster a podobně) ve prospěch vlastního vývoje, protože jsme s nimi již měli mnoho projektových zkušeností. Tato řešení jsou samozřejmě sama o sobě vynikající a před prací na Aerodisku jsme s nimi realizovali nejeden integrační projekt. Jedna věc je ale realizovat konkrétní úkol pro jednoho zákazníka, vyškolit personál a třeba si koupit podporu velkého dodavatele a druhá věc je vytvořit snadno replikovatelný produkt, který bude sloužit pro různé úkoly, které my jako prodejce, možná o sobě ani vědět nebudeme. Pro druhý účel pro nás stávající open source produkty nebyly vhodné, a tak jsme se rozhodli vytvořit distribuovaný souborový systém sami.
O dva roky později dosáhlo několik vývojářů (kteří spojili práci na vAIR s prací na klasickém úložném systému Engine) určitého výsledku.
Do roku 2018 jsme napsali jednoduchý souborový systém a doplnili jej o potřebný hardware. Systém spojil fyzické (lokální) disky z různých serverů do jednoho plochého fondu prostřednictvím interního propojení a „rozřezal“ je do virtuálních bloků, z virtuálních bloků pak byla vytvořena bloková zařízení s různou mírou odolnosti proti chybám, na kterých byla vytvořena virtuální. a provedeny pomocí KVM hypervisor cars.
S názvem souborového systému jsme si příliš hlavu nelámali a stručně jsme ho nazvali ARDFS (hádejte, co to znamená))
Tento prototyp vypadal dobře (samozřejmě ne vizuálně, ještě neexistoval žádný vizuální návrh) a vykazoval dobré výsledky z hlediska výkonu a škálování. Po prvním reálném výsledku jsme dali tento projekt do pohybu, zorganizovali jsme plnohodnotné vývojové prostředí a samostatný tým, který se zabýval pouze vAIR.
Právě do té doby dozrála obecná architektura řešení, která zatím nedoznala zásadních změn.
Ponoření do systému souborů ARDFS
ARDFS je základem vAIR, který poskytuje distribuované úložiště dat odolné proti chybám v celém clusteru. Jednou z (ale ne jedinou) charakteristickou vlastností ARDFS je, že nepoužívá žádné další dedikované servery pro metadata a správu. To bylo původně koncipováno pro zjednodušení konfigurace řešení a pro jeho spolehlivost.
Skladovací struktura
V rámci všech uzlů clusteru organizuje ARDFS logický fond ze veškerého dostupného místa na disku. Je důležité pochopit, že fond ještě nejsou data nebo naformátovaný prostor, ale jednoduše označení, tj. Všechny uzly s nainstalovaným vAIR jsou po přidání do clusteru automaticky přidány do sdíleného fondu ARDFS a diskové prostředky se automaticky sdílejí v celém clusteru (a jsou dostupné pro budoucí ukládání dat). Tento přístup vám umožňuje přidávat a odebírat uzly za chodu bez jakéhokoli vážného dopadu na již běžící systém. Tito. systém lze velmi snadno škálovat „v kostkách“ a v případě potřeby přidat nebo odebrat uzly v clusteru.
Virtuální disky (úložné objekty pro virtuální stroje) jsou přidány na horní část fondu ARDFS, které jsou sestaveny z virtuálních bloků o velikosti 4 MB. Virtuální disky přímo ukládají data. Schéma odolnosti proti chybám je také nastaveno na úrovni virtuálního disku.
Jak jste již možná uhodli, pro odolnost diskového subsystému proti chybám nepoužíváme koncept RAID (Redundantní pole nezávislých disků), ale RAIN (Redundantní pole nezávislých uzlů). Tito. Tolerance chyb je měřena, automatizována a spravována na základě uzlů, nikoli disků. Disky jsou samozřejmě také úložným objektem, jsou jako všechno ostatní monitorovány, můžete s nimi provádět všechny standardní operace včetně sestavování lokálního hardwarového RAID, ale cluster funguje specificky na uzlech.
V situaci, kdy opravdu chcete RAID (například scénář, který podporuje více selhání na malých clusterech), vám nic nebrání použít místní řadiče RAID a vybudovat natažené úložiště a architekturu RAIN. Tento scénář je poměrně živý a je námi podporován, proto si o něm povíme v článku o typických scénářích pro použití vAIR.
Schémata tolerance chyb úložiště
Pro virtuální disky ve vAIR mohou existovat dvě schémata odolnosti proti chybám:
1) Faktor replikace nebo jednoduše replikace – tato metoda odolnosti proti chybám je jednoduchá jako hůl a lano. Synchronní replikace se provádí mezi uzly s faktorem 2 (2 kopie na cluster) nebo 3 (3 kopie). RF-2 umožňuje virtuálnímu disku odolat selhání jednoho uzlu v clusteru, ale „sežere“ polovinu užitečného objemu a RF-3 odolá selhání 2 uzlů v clusteru, ale rezervuje si 2/3 užitečný objem pro jeho potřeby. Toto schéma je velmi podobné RAID-1, to znamená, že virtuální disk nakonfigurovaný v RF-2 je odolný proti selhání kteréhokoli uzlu v clusteru. V tomto případě bude s daty vše v pořádku a ani I/O se nezastaví. Když se padlý uzel vrátí do provozu, začne automatická obnova/synchronizace dat.
Níže jsou uvedeny příklady distribuce dat RF-2 a RF-3 v normálním režimu a v situaci selhání.
Máme virtuální stroj s kapacitou 8 MB unikátních (užitečných) dat, který běží na 4 uzlech vAIR. Je jasné, že ve skutečnosti je nepravděpodobné, že bude tak malý objem, ale pro schéma, které odráží logiku provozu ARDFS, je tento příklad nejsrozumitelnější. AB jsou virtuální bloky o velikosti 4 MB obsahující jedinečná data virtuálního stroje. RF-2 vytvoří dvě kopie těchto bloků A1+A2 a B1+B2. Tyto bloky jsou „rozloženy“ mezi uzly, čímž se zabrání průniku stejných dat na stejném uzlu, to znamená, že kopie A1 nebude umístěna na stejném uzlu jako kopie A2. To samé s B1 a B2.
Pokud některý z uzlů selže (například uzel č. 3, který obsahuje kopii B1), tato kopie se automaticky aktivuje na uzlu, kde není žádná kopie jeho kopie (tj. kopie B2).
Virtuální disk (a tedy VM) může snadno přežít selhání jednoho uzlu ve schématu RF-2.
Replikační schéma, i když je jednoduché a spolehlivé, trpí stejným problémem jako RAID1 – nedostatek použitelného prostoru.
2) K vyřešení výše uvedeného problému existuje kódování výmazu nebo kódování výmazu (také známé jako „redundantní kódování“, „kódování výmazu“ nebo „redundantní kód“). EC je schéma redundance, které poskytuje vysokou dostupnost dat s nižší režií na disku ve srovnání s replikací. Princip fungování tohoto mechanismu je podobný jako u RAID 5, 6, 6P.
Při kódování proces EC rozdělí virtuální blok (ve výchozím nastavení 4 MB) na několik menších „datových bloků“ v závislosti na schématu EC (například schéma 2+1 rozděluje každý blok o velikosti 4 MB na 2 bloky po 2 MB). Dále tento proces generuje „paritní bloky“ pro „datové bloky“, které nejsou větší než jedna z dříve rozdělených částí. Při dekódování EC generuje chybějící kousky čtením „přežívajících“ dat v celém clusteru.
Například virtuální disk se schématem 2 + 1 EC, implementovaný na 4 uzlech clusteru, bez problémů odolá výpadku jednoho uzlu v clusteru stejně jako RF-2. V tomto případě budou režijní náklady nižší, konkrétně koeficient užitečné kapacity pro RF-2 je 2 a pro EC 2+1 bude 1,5.
Abych to popsal jednodušeji, podstatou je, že virtuální blok je rozdělen na 2-8 (proč od 2 do 8, viz níže) „kusů“ a pro tyto kusy se počítají „kusy“ parity podobného objemu.
Výsledkem je, že data a parita jsou rovnoměrně rozděleny mezi všechny uzly clusteru. Současně, stejně jako u replikace, ARDFS automaticky rozděluje data mezi uzly tak, aby se zabránilo ukládání identických dat (kopií dat a jejich parity) na stejném uzlu, aby se eliminovala možnost ztráty dat v důsledku k tomu, že data a jejich parita najednou skončí na jednom storage nodu, který selže.
Níže je uveden příklad se stejným virtuálním strojem 8 MB a 4 uzly, ale se schématem EC 2+1.
Bloky A a B jsou rozděleny na dva kusy po 2 MB (dva protože 2+1), tedy A1+A2 a B1+B2. Na rozdíl od repliky není A1 kopií A2, je to virtuální blok A, rozdělený na dvě části, totéž s blokem B. Celkem získáme dvě sady po 4 MB, z nichž každá obsahuje dva dvouMB kusy. Dále se pro každou z těchto množin vypočítá parita s objemem ne větším než jeden kus (tj. 2 MB), získáme další + 2 kusy parity (AP a BP). Celkem máme 4×2 data + 2×2 paritu.
Dále jsou kusy „rozloženy“ mezi uzly tak, aby se data neprotínala s jejich paritou. Tito. A1 a A2 nebudou na stejném uzlu jako AP.
V případě výpadku jednoho uzlu (např. i třetího) bude spadlý blok B1 automaticky obnoven z parity BP, která je uložena na uzlu č. 2, a bude aktivován na uzlu, kde je žádná B-parita, tzn. kus BP. V tomto příkladu se jedná o uzel č. 1
Jsem si jist, že čtenář má otázku:
"Vše, co jste popsal, je již dlouho implementováno jak u konkurence, tak v open source řešeních, jaký je rozdíl mezi vaší implementací EC v ARDFS?"
A pak tu budou zajímavé funkce ARDFS.
Vymazat kódování se zaměřením na flexibilitu
Zpočátku jsme poskytli poměrně flexibilní schéma EC X+Y, kde X se rovná číslu od 2 do 8 a Y se rovná číslu od 1 do 8, ale vždy je menší nebo rovno X. Toto schéma je poskytnuto pro flexibilitu. Zvýšení počtu datových kusů (X), na které je virtuální blok rozdělen, umožňuje snížit režijní náklady, tedy zvýšit využitelný prostor.
Zvýšení počtu paritních bloků (Y) zvyšuje spolehlivost virtuálního disku. Čím větší je hodnota Y, tím více uzlů v clusteru může selhat. Zvýšení objemu parity samozřejmě snižuje množství využitelné kapacity, ale to je cena za spolehlivost.
Závislost výkonu na EC obvodech je téměř přímá: čím více „kusů“, tím nižší výkon, zde je samozřejmě potřeba vyvážený pohled.
Tento přístup umožňuje správcům konfigurovat roztažené úložiště s maximální flexibilitou. V rámci fondu ARDFS můžete použít libovolná schémata odolnosti proti chybám a jejich kombinace, což je podle našeho názoru také velmi užitečné.
Níže je tabulka srovnávající několik (ne všechna možná) schémata RF a EC.
Tabulka ukazuje, že i ta nejvíce „froté“ kombinace EC 8+7, která umožňuje ztrátu až 7 uzlů v clusteru současně, „žere“ méně využitelného prostoru (1,875 oproti 2) než standardní replikace a chrání 7krát lépe. , což činí tento ochranný mechanismus, byť je složitější, mnohem atraktivnější v situacích, kdy je potřeba zajistit maximální spolehlivost v podmínkách omezeného místa na disku. Zároveň musíte pochopit, že každé „plus“ k X nebo Y bude představovat další výkonovou režii, takže v trojúhelníku mezi spolehlivostí, úsporou a výkonem musíte vybírat velmi pečlivě. Z tohoto důvodu budeme věnovat zvláštní článek velikosti mazání kódování.
Spolehlivost a autonomie souborového systému
ARDFS běží lokálně na všech uzlech clusteru a synchronizuje je pomocí vlastních prostředků prostřednictvím vyhrazených ethernetových rozhraní. Důležité je, že ARDFS nezávisle synchronizuje nejen data, ale také metadata související s úložištěm. Při práci na ARDFS jsme současně studovali řadu existujících řešení a zjistili jsme, že mnohá synchronizují meta souborového systému pomocí externí distribuované DBMS, kterou pro synchronizaci také používáme, ale pouze konfigurace, nikoli metadata FS (o tomto a dalších souvisejících subsystémech v dalším článku).
Synchronizace metadat FS pomocí externího DBMS je samozřejmě funkční řešení, ale pak by konzistence dat uložených na ARDFS závisela na externím DBMS a jeho chování (a upřímně řečeno, je to vrtošivá dáma), která v náš názor je špatný. Proč? Pokud dojde k poškození metadat FS, lze říci „sbohem“ i samotným datům FS, takže jsme se rozhodli jít složitější, ale spolehlivější cestou.
Subsystém synchronizace metadat pro ARDFS jsme vytvořili sami a žije zcela nezávisle na sousedních podsystémech. Tito. žádný jiný subsystém nemůže poškodit data ARDFS. Podle nás je to nejspolehlivější a nejsprávnější způsob, ale zda tomu tak skutečně je, ukáže až čas. Tento přístup má navíc další výhodu. ARDFS lze použít nezávisle na vAIR, stejně jako natažené úložiště, které jistě využijeme v budoucích produktech.
V důsledku toho jsme vývojem ARDFS získali flexibilní a spolehlivý souborový systém, který dává na výběr, kde můžete ušetřit na kapacitě nebo se vzdát všeho na výkonu, nebo vytvořit ultra spolehlivé úložiště za rozumnou cenu, ale snížit požadavky na výkon.
Spolu s jednoduchou licenční politikou a flexibilním modelem poskytování (do budoucna je vAIR licencován uzlem a dodáván buď jako software nebo jako softwarový balík) vám to umožňuje velmi přesně přizpůsobit řešení široké škále požadavků zákazníků a pak snadno udržet tuto rovnováhu.
Kdo potřebuje tento zázrak?
Na jednu stranu můžeme říci, že na trhu již existují hráči, kteří mají seriózní řešení v oblasti hyperkonvergence, a k tomu vlastně směřujeme. Zdá se, že toto tvrzení je pravdivé, ALE...
Na druhou stranu, když vyrážíme do terénu a komunikujeme se zákazníky, my i naši partneři vidíme, že to tak úplně není. Úkolů pro hyperkonvergenci je mnoho, někde lidé prostě nevěděli, že taková řešení existují, jinde se jim zdála drahá, jinde neúspěšné testy alternativních řešení a jinde kvůli sankcím nákup vůbec zakazují. Obecně se ukázalo, že pole je nezorané, takže jsme šli pěstovat panenskou půdu))).
Kdy je úložný systém lepší než GCS?
Při práci s trhem se nás často ptají, kdy je lepší použít klasické schéma s úložnými systémy a kdy hyperkonvergentní? Mnoho společností vyrábějících GCS (zejména ty, které nemají ve svém portfoliu úložné systémy) říká: „Úložné systémy jsou zastaralé, pouze hyperkonvergované!“ To je odvážné tvrzení, ale zcela neodráží realitu.
Ve skutečnosti se trh úložiště skutečně pohybuje směrem k hyperkonvergenci a podobným řešením, ale vždy existuje „ale“.
Za prvé, datová centra a IT infrastruktury vybudované podle klasického schématu s úložnými systémy nelze snadno přestavět, takže modernizace a dostavba takových infrastruktur je na 5–7 let stále dědictvím.
Za druhé, infrastruktura, která se v současné době z velké části buduje (myšleno Ruská federace), je budována podle klasického schématu s využitím úložných systémů, a to ne proto, že by lidé o hyperkonvergenci nevěděli, ale proto, že hyperkonvergenční trh je nový, řešení a standardy ještě nebyly zavedeny, IT lidé ještě nejsou vyškoleni, mají málo zkušeností, ale potřebují budovat datová centra tady a teď. A tento trend bude trvat dalších 3-5 let (a pak další dědictví, viz bod 1).
Za třetí, existuje čistě technické omezení v dalších malých zpožděních 2 milisekundy na zápis (samozřejmě s výjimkou místní mezipaměti), což jsou náklady na distribuované úložiště.
No, nezapomeňme na použití velkých fyzických serverů, které milují vertikální škálování diskového subsystému.
Existuje mnoho nezbytných a oblíbených úloh, kde se úložné systémy chovají lépe než GCS. Zde s námi samozřejmě nebudou souhlasit ti výrobci, kteří nemají ve svém produktovém portfoliu úložné systémy, ale jsme připraveni se rozumně hádat. My jako vývojáři obou produktů samozřejmě určitě porovnáme úložné systémy a GCS v některé z našich budoucích publikací, kde jasně ukážeme, co je za jakých podmínek lepší.
A kde budou hyperkonvergovaná řešení fungovat lépe než úložné systémy?
Na základě výše uvedených bodů lze vyvodit tři zřejmé závěry:
- Tam, kde nejsou kritické další 2 milisekundy latence pro záznam, které se trvale vyskytují u jakéhokoli produktu (teď nemluvíme o syntetice, nanosekundy lze zobrazit na syntetice), je vhodný hyperkonvergentní.
- Tam, kde lze zátěž z velkých fyzických serverů přeměnit na mnoho malých virtuálních a rozdělit je mezi uzly, tam bude dobře fungovat i hyperkonvergence.
- Tam, kde má horizontální škálování vyšší prioritu než vertikální škálování, bude GCS fungovat dobře i tam.
Jaká jsou tato řešení?
- Veškeré standardní infrastrukturní služby (adresářová služba, mail, EDMS, souborové servery, malé nebo střední ERP a BI systémy atd.). Říkáme tomu „obecné počítání“.
- Infrastruktura cloudových poskytovatelů, kde je potřeba rychle a standardizovat horizontálně rozšiřovat a jednoduše „ořezávat“ velké množství virtuálních strojů pro klienty.
- Infrastruktura virtuálních desktopů (VDI), kde mnoho malých uživatelských virtuálních strojů běží a tiše „pluje“ v jednotném clusteru.
- Pobočkové sítě, kde každá pobočka potřebuje standardní, proti chybám odolnou, ale nenákladnou infrastrukturu 15-20 virtuálních strojů.
- Jakékoli distribuované výpočty (například služby velkých dat). Kde náklad nejde „do hloubky“, ale „do šířky“.
- Testovací prostředí, kde jsou přijatelná další malá zpoždění, ale jsou zde omezení rozpočtu, protože se jedná o testy.
V tuto chvíli jsme právě pro tyto úkoly vyrobili AERODISK vAIR a právě na ně se (zatím úspěšně) zaměřujeme. Možná se to brzy změní, protože... svět nestojí.
Tak…
Tím je první část velké série článků hotová, v dalším článku si povíme něco o architektuře řešení a použitých komponentách.
Vítáme dotazy, návrhy a konstruktivní spory.
Zdroj: www.habr.com