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ě.

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

Čá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ů

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

Takovou virtualizační platformou bylo KVM. To sice stejně jako Xen vyžaduje hardwarovou podporu v procesoru hostitele, ale na rozdíl od něj mělo výhodu, že bylo od samého počátku vyvíjeno v rámci hlavní vývojové větve linuxového jádra.

Jenže virtuální stroj v KVM musí mít k dispozici virtio ovladače. V případě linuxových strojů s tím nebyl problém, protože jsou součástí distribučního jádra, ale u stroje na kterém běžel "nový web", mohla vést změna ovladačů k nepředvídatelným důsledkům. Navíc zásah do konfigurace jeho systému, mohl být důvodem pro ukončení záruky.

Tuto patovou situaci vyřešil nečekaný kolaps v pátek 14. ledna 2011, který jenom potvrdil naléhavou potřebu změny. Zcela rutinní přenos virtuálních strojů mezi hostiteli se tehdy - díky nečekané aktualizaci virtuálního stroje na kterém běžel "nový web" - 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álů na nový stroj spojený se zálohou. Na rozdíl od zaběhlého postupu však nebyl virtuální stroj s webem katedry pouze pozastaven, a Martin, coby administrátor "nového webu" usoudil, že bude lepší místo obvyklého zapauzování virtuální stroj vypnout. Bohužel nás nenapadlo provést snapshot běžícího stroje před tímto krokem, což se ukázalo jako osudná chyba. Windows totiž začaly místo vypnutí instalovat kolem čtyřiceti čekajících aktualizačních balíčků, které se na tom stroji za dobu co běžel bez restartu nastřádaly. Disk na hostitelském stroji se pomalu, ale jistě, začínal "vařit" a probíhající aktualizace ubila naprosto vše. Nebylo možné dělat nic jiného než čekat až to dojede. Nechali jsme tedy stroj zapauzovat, pro jistotu na něm alespoň dodatečně udělali snapshot a pak ho přehodili s tím, že jeho aktualizaci necháme dojet na novém stroji, aby neblokovala provoz ostatních virtuálů. Jenže ouha. Stroj na nové verzi VMware nefungoval. Poslední snapshot zastaveného stroje byl zase poměrně starý. Zprovoznili jsme tedy prozatím alespoň ten a Martin si ten stroj zkopíroval do prostředí VMware ESX serveru, který byl v té době volný aby se ho pokusil probrat k životu. Což se mu naštěstí během několika dnů podařilo. Na Peanuts tak zůstaly čistě linuxové stroje - ideální situace pro změnu a otestování KVM.