Peanuts

Peanuts je název seriálu komiksových stripů, které přesně půl století (od r. 1950 do r. 2000) kreslil Charles M. Schulz. K označení celé KVM virtualizační platformy byl použit proto, že všechny virtualizační stroje, které do ní patřily či patří, mají jména podle postaviček z tohoto komiksu.

Počátky virtualizace na katedře DCE

S virtualizací se na katedře DCE začal na dvou identických strojích značky IBM Lukáš Moc, který nahradil Zdeňka Šebka, v průběhu r. 2007. Jako virtualizační prostředí byl vybrán Xen, který ve své době znamenal nejvýkonnější open source řešení. Na tyto stroje byl nainstalován SUSE LINUX 10.1

Xen vyžadoval podporu paravirtualizace v jádře hosta i hostitele. Protože šlo o virtualizační řešení, jehož vývoj neprobíhal v rámci hlavní větve linuxového jádra, bylo třeba u většiny distribucí aplikovat na zdrojové kódy linuxového jádra poměrně rozsáhlý patch. To nebylo nutné u distribuce SUSE LINUX 10.1, která měla upravené jádro a potřebné nástroje k jeho administraci dispozici již v podobě binárních balíčků.

Stroj se jménem k335host pak sloužil výhradně potřebám diskless infrastruktury.

• Přes NFS propagoval systémové adresáře pro bezdiskový Debian a domovské adresáře studentů, a zároveň..
• hostil virtuální stroj k909, který klientským strojům v laboratořích K2 (laboratoř) a L909 (Strojovna) přiděloval přes DHCP IP adresy a nabízel ke stažení přes TFTP server linuxový kernel s ramdiskem pro diskless Debian.

Tato infrastruktura běžela až do konce letního semestru v r.2009.

Druhý, pojmenovaný dcehost, hostil virtuální stroje, které měly nahradit stávající fyzické stroje sloužící potřebám katedry.

Nakonec byl na něj zvirtualizován pouze jediný stroj - profibus.cz. Ke skutečnému nasazení zbylých dvou virtuálních strojů cepot.cz a dcetest nikdy nedošlo.

Na stroj dcetest měl Lukáš Moc přemigrovat web katedry, který běžel - spolu s osobními stránkami uživatelů, e-learningovým systém moodle a dalšími projekty - na starším fyzickém stroji s operačním systémem BSD. Tento stroj, s hostname dce, už ale byl na hranici svých možností a především trpěl nedostatkem místa na disku.

Vedení katedry ale na jaře roku 2008 vybralo pro nový web katedry komerční řešení od fy. Netdirect, které bylo závislé na operačním systému fy. Microsoft. Paravirtualizace operačního systému MS Windows Server 2008 v Xenu tehdy nebyla možná, protože vyžadovala ovladače, resp. upravené jádro i u virtuálního stroje.

Za komerční řešení katederního webu loboval především Pavel Burget, který měl pod sebou vývoj projektu Eusophos, jehož výsledkem je LabLink. Který využívá MS Windows virtualizovaných na linuxových strojích přes VMware Workstation k výuce na vzdálených modelech.

Virtualizace přes VMware Workstation

Jednou z výhod, kterou má VMware Workstation oproti aplikacím pro serverové nasazení, byla možnost vícenásobného snapshotování, což se zdálo jako ideální řešení pro aktualizace systému virtuálního stroje.

Lukáš Moc, dostal ještě před definitivním podepsáním smlouvy výhodnější nabídku a odešel. Místo něj byl přijat Aleš Kapica. Ten měl již s virtualizacím prostředím VMware v linuxovém systému zkušenosti z předchozího působiště.

DCEwiki (červenec 2008)

Protože nebylo možné přeinstalovat žádný z IBM strojů, na kterých běžel Xen, byl pro virtualizaci v prostředí VMware Workstation použit obyčejný desktopový stroj (tower) s procesorem Intel Core Duo, který byl původně určen pro použití v laboratoři L909 (Strojovna). Měl již 64-bitový procesor, ale bez podpory hardwarové virtualizace.

Stroj dostal jméno snoopy a jako vůbec první virtuální stroj na něm byl spuštěn v červenci 2008 - linuxový support s touto wiki.

Dokumentace od Lukáše Moce obsahovala v podstatě pouze seznam webů, které se měly migrovat ze stávajícího stroje dce na dcetest, ale k existující infrastruktuře v ní nebylo nic. Lukáš Moc měl navíc dokončit rozjetou migraci ostatních webů a výukového systému moodle, protože za tento úkol dostal zaplaceno předem. Od května 2008, kdy Aleš Kapica nastoupil, sbíral informace o tom co, kde a jak se má vlastně spravovat. A tyto informace se od té doby ukládají sem.

Protože však jde o informace interní, u kterých není žádoucí přístup bez omezení, muselo být nejdřív do MediaWiki přidané rozšíření, které umožilo vytvářet stránky přístupné pouze oprávněným uživatelům. MediaWiki standardně nemá přístupová práva řešená na úrovni uživatelů, ale skupin. Cílem bylo, aby si uživatelé mohli sami určovat, kdo k jejich stránkám přístup mít bude a kdo ne.

Jedno takové rozšíření tehdy již existovalo, ale protože mělo určité nedostatky, bylo třeba napsat prakticky znovu. Výsledkem je rozšíření AccessControl, které je dnes součástí repozitářů oficiální MediaWiki

V říjnu 2008 k němu přibyl i tzv. "nový web" - virtuální stroj dce s operačním systémem MS Windows Server 2008 SP2.

Virtualizace v prostředí VMware Workstation však měla své slabiny.

• I když umožňuje, aby běžel spuštěný virtuál na pozadí, bylo možné některé operace provést pouze přes GUI, které bylo stále závislé na grafickém prostředí hostitele.

Virtuální stroje měly své disky uloženy jako lokální soubory v rámci souborového systému hostitele ve přírůstkovém formátu vmdk. Běžný provoz při obsluze virtálů přes konzoli byl vcelku bezproblémový, ale GUI VMware občas způsobilo zhroucení X serveru. Pak ovšem nebylo možné virtuální stroje korektně zastavit ani z příkazové řádky hostitele, neboť se díky provázanosti X serveru s jádrem obvykle zablokoval také přístup k virtuální konzoli i síťové rozhraní. Virtuální stroje sice zůstaly v běhu, ale nebylo je možné zastavit jinak, než z prostředí virtuálu. Hostitele bylo nutno natvrdo restartovat vypínačem a spolehnout se, že se virtuální stroje - které nebylo možné korektně zastavit - z toho nějak vzpamatují.

• Vždy byl nejistý výsledek aktualizace hostitelského stroje. Ta byla obvykle spojena s rekompilací jaderných modulů pro VMware. Nikdy nebylo možné předem říct, zda-li se s novou verzí jádra či VMware tato operace podaří, nebo ne.
• Veškeré I/O operace, které vyžadovaly práci s diskem - vytvoření snapshotu virtuálního stroje, jeho zálohování, atp. zatížení hostitele, trvaly neskutečně dlouho. Pokud byl některý z virtuálů v běhu, tak se běžící procesy přetahovaly o disk.

Samostatnou kapitolu představovalo zálohování. Vytvořit funkční zálohu virtuálního stroje u VMware bylo možné několika způsoby, ale ani jeden z nich nebyl ideální:

Naklonováním přes GUI

Klonovat bylo možné pouze zastavený stroj. Čas potřebný k provedení zálohy závisel na velikosti virtuálních disků. Neuralgickým bodem byla nutnost použít grafické rozhraní. Viz výše zmíněný problém s X serverem.

Zkopírováním pozastaveného stroje

Kopírování pozastaveného stroje mělo tu výhodu, že nebylo třeba čekat na zdlouhavé provedení snapshotu. Na druhou stranu zde existovalo riziko, že takový stroj nepůjde spustit. Občas totiž měla nová verze VMware změnu v konfiguraci, která znemožnila běh stroje s nastavením v jaké měl při spuštění.

Zkopírováním zastaveného stroje

Kopírování zastaveného virtuálního stroje bylo méně riskantní. Pokud virtuál nebylo možné kvůli nějakým změnám v konfiguraci spustit, stačilo pouze provést úpravu konfigurace a zkusit stroj spustit. Ovšem i zde bylo riziko že zastavení stroje neproběhne korektně. Kvůli potvrzení pro vytvoření snapshotu se totiž muselo realizovat v grafickém prostředí X serveru.

Zkopírováním běžícího stroje

Zjistil jsem, že relativně bezpečnou zálohu bylo možné provést zkopírováním běžícího stroje, z namountovaného předposledního snapshotu. To ovšem vyžadovalo provést těsně po sobě dva snapshoty. Ten poslední, který byl aktivní, nebylo možné namountovat, ale ten předposlední v případě potřeby ano a data z něj vykuchat. Virtuální stroj však musel být během vytváření snapshotu pozastavený a to jak dlouho záleželo na velikosti virtuálního disku, množství změn od posledního snapshotu a pochopitelně také také na aktuálním zatížení disku virtualizačního stroje.

Přechod na AMD (květen 2009)

Částečně byly nedostatky způsobeny tím, že nestíhal použitý hardware. Proto byl na jaře 2009 zakoupen nový virtualizační stroj, vybavený čtyřjádrovým procesorem AMD Phenom, který již měl - jako všechny 64-bitové procesory od AMD - podporu hardwarové virtualizace.

Použitá základová deska byla vůbec první model, který pracoval s paměťovými moduly typu DDR 3. Její předností byly dvě integrované 1GB síťové karty a 8 SATA II portů.

Stroj byl vybaven diskovým boxem se čtyřmi šuplíky, který umožnil hotswap výměnu SATA disků bez toho, že by bylo nutné kvůli výměně či přehození HDD zastavit a rozebírat stroj.

Tento stroj dostal jméno charlie-brown a byl spuštěn v květnu 2009. Byl výrazně výkonnější, ale rozdílná architektura obou virtualizačních strojů sebou přinášela konfigurační problémy při přehazování virtuálních strojů. Proto byly rok na to (2010) zakoupeny další dva stroje, ve stejné HW konfiguraci. Původní stroj snoopy byl nahrazen strojem linus a hostname odstaveného stroje podědil v dubnu 2010 snoopy.

Nyní byly všechny virtualizační stroje po hardwarové stránce identické. Tím odpadly problémy spojené rozdílnou architekturou procesoru. Díky diskovým boxům bylo překlopení virtuálních strojů na jiného hostitele záležitostí na pár minut, protože se virtuální stroje s velkými virtuálními disky nemusely kopírovat po síti či přes externí HDD zapojený do USB portu.

O kvalitě vybraného hardware svědčí fakt, že se tyto stroje stále v infrastruktuře Peanuts používají a výkonově nezaostávají.

Zálohování virtuálních strojů (duben 2010)

I když zavedení šuplíků umožňujících hotswap znamenalo zvýšení administrátorského komfortu, stále nebyl uspokojivě vyřešen problém se zálohováním virtuálů.

Díky metodě dvou bezprostředně následujících snapshotů sice byla situace s vytvořením zálohy lepší než dřív a také po každém přestěhování virtuálních strojů vždy zůstala v záloze polovina RAID pole. Přesto se to nedalo považovat za uspokojivé řešení.

Jak probíhal přesun virtuálních strojů mezi hostiteli:

1. Virtuální stroje se zapauzovaly.
2. Po jejich zapauzování se fyzický hostitel vypnul.
3. Do nového (spuštěného) hostitele se přehodil pouze jeden z disků RAID pole.
4. Tam se z něj se sestavilo pole v degradovaném stavu.
5. A po jeho namountování se postupně znovu spouštěly pozastavené virtuální stroje.

Pokud spouštění proběhlo v pořádku, tak se do běžícího pole přidal chybějící disk, na který se zreplikovaly aktuální data a disk, který zůstal na původním hostiteli se uložil jako záloha.

Problém se zálohováním se navíc stával navíc stále palčivějším. Zpočátku, kdy virtuálních strojů bylo jen pár a jejich celková velikost nepřesahovala 5GB to nebyl takový problém, ale situace se změnila v okamžiku, kdy se měl tzv. "nový web" stát úložištěm i pro multimediální soubory.

Už tak nenažraná černá skříňka s MS Windows, jejíž virtuální disk měl obludných 40GB, zabírala po každém snapshotu stále víc a víc místa. Tento virtuální stroj totiž nebylo možné odzálohovat tak jako ostatní linuxové stroje na úrovni souborového systému, jelikož jeho webový administrační systém byl do něj doinstalován jako "black box".

Hledalo se tedy řešení, které by zlepšilo možnosti zálohování a také umožnilo přesun virtuálních strojů bez ruční manipulace s disky.

Taková změna ale vyžadovala změnu virtualizační platformy, kterou se jednou provždy vyřešil problém s aktualizací systému na straně hostitele.

Virtualizace přes KVM

KVM je závislé na podpoře virtualizace v procesoru hostitele, v tom problém nebyl. Na rozdíl Xenu je od samého počátku vyvíjeno v rámci hlavní vývojové větve linuxového jádra.

KVM mělo navíc pro MS Windows již k dispozici virtio ovladače, ale u stroje na kterém běžel "nový web", mohla vést změna ovladačů vést k nepředvídatelným důsledkům. Navíc zásah do jeho systému, mohl být záminkou pro ukončení záruky.

Patovou situaci vyřešil nečekaný kolaps v pátek 14. ledna 2011, který potvrdil naléhavou potřebu změny. Zcela rutinní přenos virtuálních strojů se tehdy - díky nečekané aktualizaci virtuálního stroje na kterém běžel web katedry - změnil v nepříjemný boj o data.

Byl pátek odpoledne, těsně před koncem pracovní doby a Aleš Kapica s Martinem Samkem (administrátorem tohoto virtuálu) chtěli provést rutinní přesun virtuálu na nový stroj, spojený se zálohou. Na rozdíl od zaběhlého postupu však nebyl tentokrát virtuální stroj s MS Windows pouze pozastaven.

Martin usoudil, že bude lepší stroj místo obvyklého pauznutí vypnout. Bohužel ani jednoho nenapadlo provést před vypnutím - pro jistotu - snapshot běžícího stroje, což se ukázalo jako osudná chyba.

Stroj totiž již delší dobu neprošel restartem a za tu dobu se na něm nastřádalo kolem čtyřiceti čekajících aktualizačních balíčků, které systém začal okamžitě místo vypnutí instalovat.

Disk na hostiteli se pomalu, ale jistě, začal "vařit" a probíhající aktualizace ubila naprosto vše. Nebylo možné dělat nic jiného než čekat až aktualizace dojede.

Protože nebylo vůbec jasné jak dlouho to bude trvat, a čas tlačil, zapauzovali stroj v tom ve stavu jakém byl a pro jistotu na něm alespoň dodatečně udělali snapshot. Pak přesun dokončili s tím, že nechají aktualizaci doběhnout na novém stroji, aby neblokovala provoz ostatních virtuálů.

Jenže ouha. Pozastavený stroj se s novou verzí VMware odmítnul spustit. Poslední snapshot zastaveného stroje byl zase poměrně starý. Spustili tedy prozatím alespoň ten a Martin původní zapauzovaný stroj zkopíroval do prostředí svého VMware ESX serveru, který byl v té době prázdný, aby se ho na něm pokusil probrat k životu. To se mu naštěstí během několika dnů podařilo.

Od té doby běží dce mimo virtualizační platformu Peanuts, která tak zůstala vyhrazena čistě pro linuxové stroje. A tato veskrze nepříjemná událost vytvořila ideální situaci pro změnu a testování nových řešení, založených na KVM virtualizaci.

První stroj, na kterém měla proběhnout zatěžkávací zkouška byl moodle. Tento e-learningový systém totiž do té doby běžel na stejném virtuálním stroji jako tato wiki a jeho aktualizovaná verze ... byla mnohem náročnější na systémové prostředky, než stávající.

Tento samostatný virtuální stroj, s novou verzí měl po nějaký čas běžet paralelně se starou verzí. V letním semestru 2011 proto aby si vyučující měli možnost aktualizovanou verzi otestovat a od zimního semestru, kdy měla jet naostro, aby se dostali k věcem, které bylo třeba přesunout ze staré verze.

Sdílené úložiště (březen 2011)

Zásadním nedostatkem při stěhování virtuálních strojů mezi virtualizačními stroji bylo, že se během přesunu ocitly oba disky z původního RAID pole v degradovaného stavu.

Aby k tomu nedocházelo, bylo potřeba sdílené úložiště. Dalo se sice použít NFS server, který byl součástí infrastruktury diskless Debianu, ale správce Aleš Kapica chtěl, aby bylo zároveň pokud možno nezávislé na vnější síťové infratruktuře. V té době (březen 2011) běžel jako hlavní virtualizační stroj linus. Proto bylo sdílené úložiště vytvořeno mezi stroji charlie-brown (192.168.0.100) a snoopy (192.168.0.200). Každý dostal další síťovou kartu, a ty se pak propojily ethernetovým kabelem bez toho že by po cestě procházely nějakým switchem (bonding).

Pak vytvořil z vyhrazených logických oddílů sdílené DRBD pole, které naformátoval na clusterový souborový systémem OCFS2. Clusterový souborový systém byl nezbytný, aby bylo možné s tímto blokovým zařízením pracovat na obou strojích současně. I když lze DRBD pole používat podobně jako by šlo o iSCSI disk běží-li v režimu Primary/Primary, nejde o jedno fyzické zařízení! DRBD se stará pouze o replikaci datových bloků, ale aby stroje nezapisovaly do stejného místa musí ošetřit clusterový souborový systém.

Jak se ukázalo časem, mělo to své omezení. Pokud začaly na DRBD pole zapisovat oba stroje současně, nestíhala synchronizace a došlo k jeho rozpadu. Resynchronizace, podobně jako u RAID 1 znamená, že data z validního zařízení přepíšou data zařízení, které je označeno jako nevalidní.

Zatím co u fyzického disku, který vypadne z pole je situace vcelku jasná, v případě rozpadlého DRBD pole záleží na administrátorovi, aby určil na kterém stroji lze data považovat za validní.

Proto to nakonec vypadalo tak, že na jednom ze strojů vždy běžely virtuální stroje v produkčním režimu a na tom druhém pouze v režimu testovacím

Pacemaker (duben 2011)

Sdílené úložiště umožnilo rychlé přestěhování virtuálních strojů na jiného hostitele bez zdlouhavého kopírování či fyzické manipulace s disky, ale bylo třeba ošetřit vzájemnou komunikaci strojů v reálném čase.

Proto na ně byl nainstalován Pacemaker a tím de fakto vzniknul symetrický HA cluster o dvou nodech.

Agenta, který umožňuje spravovat DRBD pole poskytuje Linbit, který tuto technologii vyvíjí, ale agent, který by umožnil korektní nahození OCFS2 byl zastaralý a s aktuálním linuxovým jádrem nefungoval. Proto bylo třeba vytvořit nový (viz repozitář crm_agents).

NBD (květen 2011)

Nad tímto sdíleným úložištěm byla následně provedena série pokusů.

Během nich se ukázalo, že pokud virtuální stroj pracoval s lokálním souborem uloženým na sdíleném úložišti, tak se rapidně snížila rychlost IO operací v prostředí virtuálu. DRBD pole díky vyššímu zatížení procesoru a paměti nestíhalo synchronizaci poměrně velkého množství dat na pozadí, což vedlo prakticky vždy k jeho rozpadu.

Toto zjištění vyústilo v myšlenku oddělit virtualizační stroj od stroje, na kterém byla uložená data a disk ze sdíleného úložiště připojit do virtuálu přes NBD.

Tuto myšlenku bylo možné realizovat díky tomu, že zhruba o měsíc později (v květnu 2011) přibyly mezi Peanuts další dva starší IBM stroje lucy a patty. Čímž se skupina Peanuts změnila ve vícenodový asymerický HA cluster, kde dva stroje (AMD), které měly diskové boxy umožňující hotswap, mohly střídavě fungovat jako NBD server a další dva (IBM) se mohly věnovat čistě virtualizaci.

VDE2 (září 2011)

Problém však byl v tom, jak těmto virtuálním strojům zajistit nezbytnou konektivitu do vnější sítě. Jednotlivé stroje v rámci Peanuts totiž spolu komunikovaly přes oddělený "hloupý" switch, který vůbec nebyl připojen k vnější síti. Pouze jeden stroj měl k dispozici trunk, na který připojit virtuální stroje.

Strojem, který měl připojení na trunk byl snoopy a k virtualizačním strojům patty a lucy již bylo nutné dostat konektivitu prostřednictvím interní sítě clusteru. To umožnilo nasazení VDE.

• VDE má ohromnou výhodu v tom, že umožňuje vytvořit zcela nezávislou interní síť, bez toho že by bylo nutné zasahovat do konfigurace fyzického switche.
• K zajištění vnější konektivity stačil pouze jeden fyzický port s trunkem na switchi.
• Celou interní síť a virtuální switche bylo možno spravovat vzdáleně a podle potřeby je zapínat a vypínat.
• VDE má navíc k dispozici pluginy, které umožňují virtuální porty monitorovat a také regulovat průtok dat na virtuálním drátu

Pouze jeden trunkový port byl k dispozici proto, že se správce sítě - František Vaněk, obával, že by v rámci této virtuální infrastruktury mohlo dojít k něčemu, co by mohlo vést k nabourání sítě celého objektu budovy E na Karlově náměstí.

I tak se během prvních testovacích pokusů podařilo díky nepozornosti shodit hlavní switch. U VDE totiž lze - na rozdíl od fyzického ethernetového drátu - do jedné zásuvky strčit dva dráty ;-) Tento problém však se však ošetřil parametrem, který brání vytvoření duplicitního drátu.

Na stroji snoopy byl "trunk" rozebrán na jednotlivé VLAN, které byly prostřednictvím utility vde2_plug zapojeny každá do vlastního virtuálního switche, a ten pak byl přes virtuální drát připojen do virtuálního switche na virtualizačním stroji patty (resp. lucy). Virtuál, který na tom stroji běžel, měl systémový disk připojen přes NBD ke stroji charlie-brown (který tak nesl hlavní nápor IO operací) a konektivitu bral přes své virtuální síťové karty z lokálních VDE switchů.

Jako další zatěžkávací stroj byl nainstalován a v testovacím provozu vyzkoušen nový stroj k2, který měl nahradit stávající infrastrukturu pro diskless Debian využívající virtualizace přes Xen.

Od reálného nasazení ale bylo upuštěno z toho důvodu, že se konektivita jevila subjektivně horší než u stávajícího řešení.

Tento test vedly k důkladnému zkoumání a optimalizaci výkonu síťového připojení přes VDE, a výsledek byl zpracován do manuálové stránky - KVM (konfigurace sítě).

Byly odhaleny a odstraněny následující úzká hrdla:

• Připojení do vnější sítě bylo realizováno na úrovni TUN přes vde_pcapplug, což sebou neslo vyšší režii při kontrole paketů. Proto bylo nově zapojení VLAN do virtuálních switchů provedeno na úrovni TAP přes vde_plug2tap.
• Pokusně byl u virtuálních drátů použit wirefilter, který umožňoval regulaci průtoku dat, ale jeho režie sama o sobě snižovala o 10% reálné množství prošlých paketů. Proto byl z virtuálních drátů odstraněn.
• Virtuální switche měly defaultně zapnuto STP (spannig tree protocol), který sice hledá "inteligentním" způsobem pro pakety nejrychlejší cestu, ale sám je schopen za určitých okolností svými pakety připojení umlátit. Proto bylo STP vypnuto.
• Vzhledem k tomu, že obvykle do jednoho virtuálního switche nebylo zapojeno víc strojů než jeden, bylo zbytečné aby fungoval jako skutečný switch. Výhodnější bylo aby se defaultně spouštěl v režimu HUB, což navíc umožnilo monitoring datového toku přes externí nástroje (jako např. tcpdump).
• Virtuální dráty přestaly být realizovány tunelem přes ssh, které má samo o sobě interně limitovanou rychlost připojení, ale sestavovaly se rovnou přes VDE utilitu vde_cryptcab, která má menší režii a žádné omezení rychlosti.

Na základě těchto opatření došlo k rapidnímu zlepšení síťové propustnosti, proto byly stávající stroje definitivně přesunuty na KVM.

Výsledné řešení se jevilo z hlediska výkonu jako dobré a stabilní. Mělo ovšem jednu slabinu.

K nahození virtuálního drátu muselo dojít na obou stranách - tj. nejprve v režimu LISTEN na straně stroje snoopy a pak na straně virtualizačního stroje. V případě, že došlo k přerušení spojení na straně virtualizačního stroje, stačilo pouze znovu připojit virtuální drát. Ovšem pokud bylo přerušeno spojení ze stroje snoopy, musela se nahodit skriptem znovu konektivita pro celou virtuální infrastrukturu. Tento skript však nebylo možné reálně včas odzkoušet a jak se ukázalo - obsahoval chybu.

RAID 6 (listopad 2011)

Během náporu při začátku zimního semestru 2011 se ale začal se objevovat další problém. Virtuální stroj moodle začal znenadání občas tuhnout, přitom ostatní virtuální stroje běžely bez problémů dál. V takové situaci nezbývalo než virtuál přes konzoli odstřelit a spustit znovu.

Než však byla odhalena skutečná příčina a dopsán obslužný skript, který měl zjednodušit správu celé infrastruktury, včetně nahazování konektivity, došlo 28. září 2011, kdy správce této virtualizační infrastruktury Aleš Kapica byl na dovolené, k havárii. Ta vedla k revizi celého řešení.

Na počátku bylo opět vytuhnutí stroje moodle. K vyřešení v podstatě stačilo provést obvyklý restart virtuálního stroje. Jenže Martin Samek, který situaci řešil, si zřejmě špatně vyložil instrukce které dostal prostřednictvím e-mailu a jako první krok, udělal ten co měl udělat jako poslední a pouze v případě, že by selhalo všecho jiné - restartoval stroj snoopy.

Tím v podstatě odstřelil úplně všechno, protože Pacemaker na to reagoval restartem stroje charlie-brown. Díky tomu se rozpadlo DRBD pole, se kterým ještě neměl žádné zkušenosti a instrukce, které měl mu byly tím pádem k ničemu.

V časové tísni tedy zkopíroval virtuální disky stroje moodle z diskového oddílu, který zřejmě nebyl zcela beze zbytku synchronizován na svůj vlastní stroj s KVM yrden a tam virtuál po menším zápolení spustil.

V nastalé situaci to bylo asi to nejlepší co mohl udělat, protože jak se dodatečně ukázalo - i kdyby se mu podařilo DRBD pole správně sestavit, tak by díky překlepu v obslužném skriptu nedošlo k nahození virtuálního drátu na straně stroje snoopy, který zajišťoval konektivitu.

Výsledkem další série pokusů je stránka QEMU (bloková zařízení). Jako absolutně nejvýkonnější z hlediska výkonu při I/O operacích a zároveň odolné proti výpadku některého datového stroje se ukázalo RAID 6 pole, sestavené ze čtyř NBD zařízení přímo na virtualizačním stroji. Do virtuálu ovšem zpropagované jako lokální blokové zařízení.

Ukázalo se, že příčinou tuhnutí stroje moodle nebyl problém v konektivitě mezi Peanuts, ale ve strojích IBM. Na to aby fungovaly uspokojivě jako virtualizační stroje měly jejich procesory příliš omezenou instrukční sadu a pomalé paměti (pouze DDR 1). Po přestěhování virtuálů na stroje s AMD, byl výkon virtualizovaných strojů mnohem lepší a problémy s tuhnutím přestaly

Bohužel IBM stroje nebylo možné využít ani pro sdílené datové úložiště.

• Oba měly pouze dvě síťové karty a jako datové stroje by potřebovaly minimálně jedno další síťové rozhraní pro bonding.
• Jejich řadiče neumožňovaly hotswap připojení disku a také nešly nakonfigurovat tak, aby disk zpropagovaly do systému, aniž by došlo k destrukci uložených dat, což znemožnilo zálohování uložených dat pouhým vyjmutím replikovaného disku - zálohu by totiž nebylo možné obnovit.

Na druhou stranu se zdálo že by byla škoda zcela zahodit jejich výpočetní potenciál. Proto bylo stávající řešení přepracováno. Již z předchozích pokusů bylo zřejmé, že výkon při IO operacích je vyšší, když se použije SW RAID 6 složený z nezávislých blokových zařízení.

• Linuxový systém pracuje pouze s daty, které potřebuje. Při virtualizaci s disky publikovanými přes NFS by se do síťové komunikace promítla i režie souborového systému ve virtuálu. Přes NBD se ale honí už pouze datové bloky, které se načítají nebo ukládají.
• RAID 6 složený z NBD zařízení má navíc rozloženy datové bloky na více strojů. A protože komunikace probíhá po síti, která má lepší propustnost než lokální diskový řadič při práci s pomalými fyzické disky, jsou IO operace - obzvláště ty spojené se čtením - rychlejši.
• Je-li načítání dat rychlejší, tak se zkracuje čas, po který IO operace okupují procesor.
• Replikace dat mezi bloková zařízení na různých strojích snižuje pravděpodobnost ztráty dat v případě, že jeden ze strojů odpadne. V případě, že se použije SW RAID 6, který vyžaduje minimálně 4 bloková zařízení, je taková infrastruktura schopný ustát dokonce výpadek dvou strojů.
• SW RAID 6, který je složený ze čtyř NBD zařízení má zhruba dvojnásobnou kapacitu, než jaká je velikost souborů, které jsou přes NBD server vypublikovány.

Celé virtualizační řešení Peanuts bylo přepracováno.

• Jako virtualizační hostitel sloužil z dvojice snoopy - charlie-brown vždy pouze jeden stroj. Na ten druhý se pak pouze replikovalo sdílené úložiště.
• Virtuály se přehazovaly až když bylo třeba stávajícího hostitele aktualizovat. Původní záměr byl - přehazovat virtuální stroje tak aby byly virtualizační stroje rovnoměrně zatížené.
• Do starých IBM strojů se daly jejich původní SCSI disky a na každém z nich pak bylo k dispozici cca 100GB prostoru, na který se mohly uložit soubory s virtuálními disky.
• Znovu byl do infrastruktury zapojen stroj linus (AMD), který byl dosud nevyužitý, protože DRBD umí aktivně využívat pouze dva nody. Třetí nod by mohl fungovat pouze jako SPARE u RAID zařízení. Na to, aby linus fungoval jako SPARE však neměl k dispozici dostatečný počet síťových karet ani disky. Nicméně měl - stejně jako stroje lucy, patty, snoopy a charlie-brown - na RAID 1 poli se systémem k dispozici 100GB volného prostoru pro uložení souborů virtuálních disků publikovaných přes NBD.
• Z každého nodu byly soubory s virtuálními disky zpropagovány přes xnbd-server, připojeny na NBD zařízení virtualizačního stroje. Z těchto NBD zařízení se pak pro každý virtuální stroj sestavil vlastní SW RAID 6, který byl do prostředí virtuálu zpropagován přes virtio jako jeden systémový disk.

28. listopadu 2011 byla u všech AMD strojů navýšena jejich paměť na 16GB - původně měly polovinu. Byl zakoupen 32GB kit se čtyřmi moduly DDR3 pamětí značky Corsair CL10 Vengeance o taktu 1600MHz, který byl rozhozen po dvou modulech mezi stroje charlie-brown a linus. Na stroji snoopy zaplnily všechny 4 banky původní 4GB DDR3 moduly značky Kingston HyperX Blue o taktu 1333MHZ. Od té doby začala u do té doby na 100% spolehlivých strojů "záhadná" tuhnutí virtuálních strojů a panikaření. Koho by ale napadlo, že jsou ze čtyř nových modulů hned dva vadné a navíc rozhozené mezi oba stroje. Časem padlo podezření na paměť, ale nebyly k dispozici jiné DDR3 moduly, kterými by bylo možné nahradit ty stávající, ani vhodný stroj, ve kterém by je bylo vůbec možné důkladně otestovat.

Stav blokových zařízení virtuálních strojů za normálního provozu.

Stav blokových zařízení virtuálních strojů při výpadku dvou datových nodů.

Praxe ukázala, že toto řešení bylo schopno se v rámci možností s výpadky na straně HW vyrovnat. Navíc umožnilo z dostupného hardware vyždímat po všech stránkách maximální výkon. Nicméně přes své nesporné výhody mělo jeden významný nedostatek. Mezi nástroji xNBD nebyl nástroj, který by zajistil bezpečné nahození NBD serveru a jeho spojení s lokálním NBD zařízením na vzdáleném stroji. K dispozici byl pouze jednoduchý skript pro nahození xNBD wrapperu.

Na druhou stranu xNBD klient mohl zavolat při přerušení spojení externí skript, který provedl veškeré akce potřebné pro korektní vyhození NBD zařízení z RAID pole.

Protože pro RAID6 stačily pouze čtyři zařízení, byly soubory jednoho z nodů připojeny jako SPARE. Pokud některá z nodů vypadnul, skript okamžitě označil nejprve příslušné NBD zařízení jako FAILED, což odstartovalo proces replikace dat na záložní NBD zařízení, a pak je i korektně odstranil.

V případě, že z nějakého důvodu vypadlo veškeré spojení mezi nody - což se občas stalo kvůli tomu, že odpadnul switch přes který celá infrastruktura komunikovala - se nedělo nic. Po jeho restartu stačilo připojit NBD zařízení, sestavit znovu RAID a opět spustit virtuál.

Když další nod vypadnul dřív, než doběhla replikace, tak se pořád nic nedělo, protože SW RAID 6 v takovém případě degraduje na RAID 5. Teprve když zůstaly v běhu pouze dva nody, byla situace kritická - nikoliv však ztracená.

V provizorním skriptu pro obsluhu celé infrastruktury, však tikal závažný problém, který se projevil fatální havárií stroje support dne 21. července 2012.

Byl jsem si vědom tohoto nebezpečí, proto jsem během června usilovně pracoval na skriptu, který by umožnil řízení xNBD přes Pacemaker. V pátek 29. června 2012 mi měla začít třítýdenní dovolená a chtěl jsem s ním být hotov ještě před odjezdem.

Jenže v noci ze čtvrtka na pátek opět zkolaboval stroj charlie-brown, což vedlo k vyhození jím sdílených xNBD disků z raid polí virtuálních strojů. Dal jsem vše do pořádku a protože bylo evidentní, že i kdybych skript dopsal, už ho nestihnu odzkoušet. Proto jsem sepsal - pro jistotu - e-mail kolegům, kde bylo popsáno jak v určitých situacích v případě nutnosti postupovat.

Věděl jsem, že pokud stroj charlie-brown opět vypadne, tak to do mého návratu vydrží, ale bylo třeba popsat kolegům jakým způsobem nahodit celou infrastrukturu v případě, že by došlo k totálnímu výpadku el. proudu celé serverovny, jako se to stalo o rok dříve - 29. června 2011.

V průběhu mé dovolené, zhruba o týden později - 8. července - opět zkolaboval stroj stroj charlie-brown. Za normálních okolností by jeho disky nahradily disky stroje linus připojené jako spare, jenže ten jsem za účelem testování nástroje pro řízení xNBD těsně před dovolenou z clusteru vyřadil. To se ukázalo jako osudová chyba.

V podstatě nešlo o nic mimořádného a celá věc klidně mohla počkat až na můj návrat z dovolené, ale kolega Martin Samek paradoxně nechtěl riskovat ztrátu dat, proto ihned po restartu stroje charlie-brown nahodil podle instrukcí xNBD a postupně přidával virtuální disky zpět do RAID polí, ze kterých vypadly. Jenže si nevšimnul, že při opakovaném zadávání příkazu pro připojení virtuálních disků k NBD zařízením v jednom případě nenastavil správné parametry. A právě toto drobné přehlédnutí zadělalo na budoucí havárii.

Když jsem se 19. července vrátil z dovolené, tak mi Martin ihned oznámil, že se mu jedno z polí nedařilo sestavit. V onu chvíli mne však nenapadlo, že příčina je v tom, že díky překlepu připojil jeden z disků tohoto virtuálu do raid pole jiného stroje.

Jako obvykle jsem tedy vynuloval superblok, došlo k replikaci RAID pole a všechno se zdálo v pořádku. Ale nebylo, neboť tím pádem se na jeden virtuální disk pokoušely zapisovat současně dva virtuální stroje, což mne ovšem nenapadlo.

Kromě toho bylo ještě rozpadlé DRBD pole. Nechal jsem ho synchronizovat, s tím, že se druhý den, až bude synchronizace dokončena, na to podívám důkladně. Nepočítal jsem ale s tím, že po dokončení synchronizace DRBD dojde nejenom k restartu stroje charlie-brown ale i snoopy.

Je velmi pravděpodobné, že kdyby nebylo došlo k oné "drobné" chybě, tak by se nic nedělo, jenže takto, když byl po restartu RAID znovu nahozen byly najednou u jednoho stroje všechny disky v RAID poli označeny jako SPARE. V té chvíli jsem ještě vůbec netušil proč, a tak začal vršit chybu za chybou.

Nakonec to dopadlo tak, že některé soubory zmizely. A pak přišlo to vůbec nejhorší zjištění - a to, že jsem ve stresu před odjezdem na dovolenou nezkontroloval, jestli se spouští zálohovací skript.

Tak jsem poprvé za celou svou kariéru přišel o nějaká svěřená data, a to mne vedlo k přehodnocení celé strategie stávajícího virtualizačního řešení.

Použití xNBD sice bylo z hlediska výkonu virtuálních strojů nejlepší variantou, ale bohužel díky absenci kontrolních mechanismů NBD a nástrojů pro automatickou konfiguraci xNBD zařízení, to byla příliš choulostivá koncepce.

To však nebyl jediný důvod proč zvolit jiné řešení.

Místo v racku

Peanuts tvořilo celkem pět strojů. Dvě 2U IBM a tři 4U AMD. Kromě toho dosluhovaly dva 4U IBM stroje k909a a k909b. Na prvním z nich byl v prostředí XEN virtualizován stroj k2, který obsluhoval laboratoře a na druhém bezdiskový stroj postel určený pro studenty. Obojí bylo třeba přesunout do infrastruktury Peanuts. Celkem všechny tyto stroje zabíraly v racku 24 jednotek a zrušením všech IBM strojů jich bylo možné uvolnit 10.

Energetické nároky

Pro zajištění provozu bylo třeba mít všechny stroje na UPS. Spotřeba každého z IBM strojů se pohybovala v průměru kolem 200 Watů. takže jejich celkový odběr mohl být kolem 1kW za hodinu. AMD stroje byly úspornější a přitom zároveň i výkonnější. Zrušení IBM strojů tedy představovalo i významnou energetickou úsporu.

Chlazení

Každý spuštěný stroj vydává teplo a to i když nic nedělá. Toto odpadní teplo pak zvyšuje nároky na klimatizaci v serverovně. IBM stroje se starými procesory od Intelu byly nejenom žravé, ale také řádně topily.

Síťové porty

Každý stroj na switchi obsadil minimálně 2 porty - jeden pro vnitřní komunikaci a druhý pro přístup z vnější sítě. Virtualizační stroje navíc obsadily ještě po jednom portu pro přístup na "trunk", takže celkem Peanuts obsadily 12 portů switche. Stroje k909a a k909b obsadily další čtyři. Zrušení nadbytečných strojů znamenalo uvolnění 10 portů na switchi.

KVM konzole

Aby bylo možné pracovat s lokální konzolí virtualizačních strojů, měl každý z nich připojenu také jednu konzoli KVM přepínače. Celkem tedy obsadily 5 konzolí KVM (+ další dvě pro k909a a k909b)

Spolehlivost strojů

Jeden z IBM strojů a stroj charlie-brown se v zátěži chovaly dost podivně, což nakonec vedlo i k poslední havárii. Nemělo tedy smysl nadále udržovat v provozu stroje, na které se nelze spolehnout.

To byly tedy dost pádné důvody k tomu vyřešit celou infrastrukturu Peanuts jinak.

Přechod na diskless (září 2012)

Rozhodnul jsem se aplikovat bezdiskové řešení - stejné, jako se do té doby využívalo pouze pro laboratorní stroje, ovšem pochopitelně bez překrytí systémové disku. Je založené na schopnosti linuxového jádra pracovat se systémem umístěným v adresáři publikovaném ze vzdáleného serveru přes NFS protokol.

Vedly mne k tomu následující premisy:

• NFS z hlediska IO propustnosti sice nemá tak vysoký výkon, jako když se použije NBD, ale to se projeví pouze tehdy, provádí-li systém větší množství IO operací.
• V reálu je největší nápor na IO operace při spuštění stroje, kdy se systém načítá do paměti, ale pak už jádro s NFS pracuje pouze tehdy, když potřebuje systém načíst něco co dosud nemá v paměti.
• Prakticky nikdy nejsou všechny stroje zatíženy na maximum současně, takže NFS server má dost času na to aby postupně vyřizoval jejich požadavky
• Připojení přes NFS, je přizpůsobeno k tomu, aby bylo schopné ustát i výpadek připojení. U NBD výpadek připojení vede k trvalému rozpadu komunikace.
• U NFS jsou všechny virtuální stroje uloženy na serveru v normální adresářové struktuře, kterou lze procházet, vytahovat z ní data a zálohovat na úrovni souborů.

• Klasický virtuální disk, který se chová jako blokové zařízení obvykle mívá uvnitř souborový systém, který se může stát za určitých okolností nekonzistentní.
• S rostoucím objemem dat uvnitř virtuálního stroje narůstá i doba potřebná ke kontrole souborového systému takového disku
• Zálohování celých virtuálních disků znamená, že spoustu místa zaberou "hluchá" data - bloky dat, které má sice vnitřní souborový systém označen jako volné, ale ve skutečnosti je přepisuje až když na ně přijde řada.

• U NFS lze využívat celou diskovou kapacitu diskového pole bez omezení a volné místo je skutečně volné.

Na druhou stranu má bezdiskové řešení i své nedostatky - špatně se s ním snáší databáze. Proto s předěláním virtuálních strojů na bezdiskové byla spojena i centralizace našich MySQL databází na centrálním databázovém serveru. To sebou ovšem přineslo další závislosti na okolní infrastruktuře.

Přechod probíhal v průběhu srpna až září 2012, souběžně s využitím stávající infrastruktury. Teprve po převedení všech virtuálních strojů na bezdiskové umožnio zrušit již nepotřebné stroje. Protože se celá infrastruktura Peanuts stala mnohem složitější, začal být pro instalaci a údržbu hostelských i virtuálních strojů využíván Puppet.

1. První takto předený stroj byl git. U kterého to bylo poměrně snadné, jelikož se na něm žádná databáze nepoužívá. Tento stroj začal vůči sobě i ostatním strojům fungovat jako Puppet master.
2. Po něm následoval stroj, na kterém byla spuštěna aktualizovaná verze moodle, který bylo tak jako tak třeba reinstalovat.
3. Třetí následoval drupal na kterém běžely webové prezentace, které již byly napojeny na externí databázový server dříve.
4. Zatěžkávací zkoušku, která měla ověřit rychlost odezvy NFS, představoval stroj samba. Ten sice nepoužívá žádnou databázi, ale pracuje s poměrně velkým objemem uložených dat.
5. Nejnáročnějším strojem přesunutým do tohoto prostředí byla k2. To si totiž vyžádalo úpravy i na straně NFS serveru. Předtím totiž tento stroj sám fungoval vůči strojům v laboratořích jako NFS server. Nyní jim pouze dodává přes DHCP síťovou konfiguraci a přes PXE zavaděč. Dále se pak již laboratorní stroje připojují přímo na NFS server, ze kterého běží i virtuální servery. Tzn. že oproti dřívějšku razantně klesly nároky na propustnost sítě u stroje k2.
6. Pak byl konvertován stroj - support, což překvapivě proběhlo naprosto hladce.
7. Problémy nedělal ani testovací stroj x32bit
8. A nakonec byl přesunut stroj buildinglab, využívá lokální PostgreSQL databázi. Jak se postupem času ukázalo NFS mu nedělá problém.

Využití Btrfs k denním zálohám studentských účtů (říjen 2012)

Protože byly do infrastruktury spravované přes Peanuts zahrnuty i laboratoře, které měly do té doby svůj vlastní hardware, bylo rozhodnuto prozatím upozadit "nespolehlivý" stroj charlie-brown a jeho 8GB paměťové moduly přidat stroji linus. Tato operace proběhla 11. září 2012. A 5. října 2012 - došlo k vytuhnutí do té doby relativně spolehlivého stroje linus. Vynutil jsem si tedy koupi nových paměťových modulů, aby bylo možné provést jejich výměnu a ty stávající konečně mohl podrobit testu na jednom z nových strojů pro laboratoře, které již měly DDR3 sloty. Když jsem moduly testoval samostatně, tak se zdály v pořádku, ale chyba se v memtestu objevila v okamžiku, kdy byly zapojeny v páru. Postupně jsem je tedy prostřídal a ukázalo se, že z původního kitu se čtyřmi moduly jsou hned dva vadné. To byla tedy skutečná příčina všech problémů, které se táhly téměř rok! Díky těmto mizerným dvěma modulům "záhadně" tuhly virtuály i jejich hostitelské stroje a byla nalomena důvěra vůči jinak velmi spolehlivým AMD strojům

Vyřazení AMD strojů z infrastruktury Peanuts (leden 2015)

Uplynul téměř rok provozu na plně automatizované infrastruktuře.

Během té doby se ukázalo jak jeden špatně napsaný agent pro Pacemaker dokáže v případě problému torpédovat celou infrastrukturu.

DRBD agent společnosti Linbit nepočítá s provozem v prostředí vícenodového asymetrického clusteru. Kromě toho v něm není správně ošetřeno, jak řešit rekonstrukci služby v situaci, kdy jsou na něm závislé další služby.

Podstata problému s DRBD spočívá v tom, že pokud se do clusteru zapojí další nod, tak chce DRBD agent automaticky přehodit Master na jiný nod - bez ohledu na to, že s ním nově zapojený nod nemá absolutně nic společného.

Toto chování má několik nepříjemných důsledků:

pokud byla nastavena závislost NFS služby na místě, kde je spuštěn DRBD Master

Došlo k "odstřelu" IP adres všech rozhraní přes které komunikoval stávající NFS server. Tím pádem došlo zablokování a následnému odstřelu celé infrastruktury závislé na NFS. Neboť akce promote skončila (celkem logicky) selháním DRBD zdroje, který se pokusil spustit Master "někde jinde"

po zrušení závislosti NFS na DRBD zdroji

Sice nedošlo k selhání IP adres a spuštěných zdrojů, ale přestalo pro změnu korektně fungovat nahození služeb v případě, že došlo selhání stroje na kterém běžel stávající NFS server. Příčina je v tom, že ke spuštění NFS serveru dojde dřív, než je připojeno DRBD zařízení s daty. Následně tak selže i spuštění následujících zdrojů a Pacemaker ukončí veškeré pokusy o jejich spuštění chybou.

Řešením takové situace pak je pouze restart NFS serveru, a opakované zastavení a spuštění spojené s operací cleanup (aby došlo k odstranění chyby) všech závislých zdrojů.

Bohužel stejně pitomě se chová DRBD agent i v případě restartu některého z nodů. Pacemaker ještě navíc komplikuje tím, že se vždy pokouší přehodit služby po "oživení" původního nodu zpět.

Situaci mohlo vyřešit spouštění virtuálních strojů na původních AMD strojích, jenže ty v té době ještě nepoužívaly openvswitch a jejich systém nutně vyžadoval aktualizaci. Svými restarty pak ovlivňovaly stabilitu produkčního prostředí, proto byly z clusteru Peanuts dočasně vyřazeny. Tím se ale otevřela cesta pro vytvoření a otestování nového clusterového řešení, které by již nepoužívalo k replikaci DRBD.

Problém s místem (duben 2015)

Nedlouho poté se ukázal další problém, který se objevil - zcela nečekaně - při rušení zastaralých snapshotů. Ve stávajícím úložišti Peanuts, sdíleného přes NFS, totiž začalo docházet volné místo.

V podstatě to nemělo představovat větší problém, neboť Btrfs mělo alokováno velké množství extentů snapshoty. Jenže hned první pokus o jejich zrušení ukázal, že to nebude tak snadné jak se zdálo.

• Největším kamenem úrazu totiž byl fakt, že při odstraňování snapshotů kolaboval NFS server, dokud pracoval s obsahem snapshotovaného adresáře. Bohužel stroj jako takový při tomto selhání nešel do restartu. "Pouze" přestal komunikovat. A když došlo po selhání k přehození DRBD pole - zůstala větší část rušených snapshotů zachována. Jenomže v tom okamžiku se do toho vložil zmíněný vadný DRBD agent a bylo zle.
• Nedocházelo k tomu, pokud byl disklessový virtuál odstaven a dočasně vyhozen z NFS. Jenže se ukázalo, že odstranění několika desítek tisíc snapshotů nebude rozhodně záležitost na minutu.

Přechod na distribuovaná úložiště

Problémy s odstraňováním snapshotů v dubnu 2015 ukázaly, že DRBD agent pro Pacemaker bude vždy představovat achillovu patu clusterového řešení.

Nastal tedy čas podívat se, jak pokročil vývoj technologií zkoušených již v listopadu 2011.

Díky tomu, že v lednu 2015 byly z infrastruktury Peanuts vyřazeny tři AMD stroje, bylo možné provést sérii zkušebních testů, aniž by tím dokázelo k nabourávání provozní infrastruktury.

GlusterFS (květen 2015)

První volba padla na GlusterFS, který oproti roku 2011 udělal významný pokrok. Především v tom smyslu, že se objevil BD xlator - vrstva, která umožňuje blokový přístup k obsahu virtuálních disků. GlusterFS totiž replikuje data na úrovni souborů. Což má své klady, ale i zápory.

• Jde o distribuovaný souborový systém, který neběží v jádře, ale v uživatelském prostoru, kde jsou operace se soubory z hlediska IO výkonu náročnější, neboť otevření souboru a jeho korektní uzavření v případě malých souborů "stojí" více IO operací, než vlastní změna jejich obsahu. Při práci s velkým množstvím malých souborů tak je výkon distribuovaného souborového systému významně degradovaný.
• U velkých souborů je sice režie spojená s otevřením a zavřením souboru v poměru k objemu dat zanedbatelná, ale mají zas jiný zádrhel. Při resynchronizaci bricků - kterou GlusterFS svazek dělá vždy, když se opět zapojí nod, který byl z nějakého důvodu offline - se přepočítávají kontrolní součty souborů a dokud nejsou repliky na všech nodech OK, je soubor zamčený. Je-li takovým souborem virtuální disk, tak s ním po tu dobu virtuál nemůže pracovat. Což některé souborové systémy ustojí (Btrfs), ale jiné ne (Ext4).

Na druhou stranu, tím že jsou soubory replikované, lze s nimi v případě nouze pracovat lokálně a tak je použít i pokud GlusterFS z nějakého důvodu přestal data synchronizovat.

Stroje charlie-brown, snoopy a linus podstoupily systémový upgrade a byl z nich sestaven nový cluster - Schrot s nezávislou sítí, aby nedocházelo ke kolizím s produkčním prostředím Peanuts:

• Pro distribuci konfiguračních souborů a správu nodů je využíván Puppet
• Systémové disky všech nodů jedou nad Btrfs v RAID1
• Pro uložení dat GlusterFS svazků se využívají přírůstkové oddíly v rámci Thin LVM
• Protože GlusterFS svazky jsou dostupný na všech nodech, stará se Pacemaker pouze o spouštění virtuálů - odpadly problémy s komplexním nastavením závislostí služeb

Jistota, kterou poskytuje GlusterFS pro uložená data, je na úkor IO výkonu. Pro optimální výkon GlusterFS je tedy nezbytná rychlá síť, výkonné řadiče a svižné SAS disky s podporou asynchronních operací. To ovšem znamená vysoké náklady na hardware.

Použité AMD stroje nic toho neměly. Jejich jedinou výhodou byl dostatek paměti, šuplíkové boxy na pevné disky a poměrně výkonné desktopové procesory.

Učinili jsme tedy pokus a pro ukládání dat pořídili hybrydní 4TB SSHD disky Seagate, což se poměrně záhy ukázalo jako ne zrovna šťastné řešení:

• Vyšší IO výkon těchto disků se projevoval max do 4GB dat. Po jejich přenesení GlusterFS "zamrznul" a pokračovaly až po učitém prodlení - opět dalším kusem cca 4GB dat.
• Tyto disky nebyly v raid poli - z hlediska fungování GlusterFS se to zdálo zbytečné
• Vrcholem všeho ovšem bylo selhání tohoto disku na jednom z nodů, které nějakým způsobem způsobilo i narušení dat na systémovém Btrfs oddíle v režimu raid1. Při následné kontrole stavu 4TB disků na zbylých nodech se ukázalo, že stejný typ disku již začal vykazovat chyby i na dalším z nich.

Na základě těchto zjištění byly nody přeorganizovány. Původně byl systémový disk na jednom Btrfs oddíle, který měl v režimu raid1 dva 2TB rotační 7200 ot. disky Seagate. Ten jsme zmenšili na 200GB a nad zbylým prostorem byl sestaven SW RAID1, na který se přesunula LVM skupina ze stávajících 4TB disků.

To ovšem pochopitelně vedlo k další degradaci IO výkonu při replikaci souborů GlusterFS. Situace se poněkud zlepšila po upgrade GlusterFS z verze 3.6.2 na 3.7.6, ale i tak zůstal výkon virtuálních disků tristní.