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 stroji dcetest měl původně běžet web katedry, který byl spolu s osobními stránkami uživatelů, e-learningovým systém moodle a dalšími projekty na jediném fyzickém stroji s operačním systémem BSD. Tento postarší stroj už však 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.

VMware

V rámci projektu Eusophos se na katedře pracovalo s virtualizací strojů s MS Windows přes VMware Workstation, proto i nový virtualizační stroj, určený k budoucí virtualizaci stroje s novým webem katedry měl používat toto virtualizační prostředí.

Místo Lukáše Moce, který v téže době dostal výhodnější nabídku a odešel, byl přijat Aleš Kapica, který měl s virtualizací v prostředí VMware zkušenosti z předchozího působiště. Výhodné bylo, že měl zároveň zkušenosti s linuxovým prostředím, protože Lukáš Moc si předáním stávající infrastruktury příliš hlavu nelámal.

snoopy

Protože nebylo jasné zda-li je možné přeinstalovat některý z IBM strojů, na kterých běžel Xen, byl pro VMware virtualizaci 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ál na něm byl spuštěn v červenci 2008 - linuxový support s touto wiki.

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.

Slabiny řešení na VMware Workstation

Závislost 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í.

Nejistý výsledek aktualizace

Noční můru představovala aktualizace hostitelského systému. Ta totiž byla obvykle spojena s rekompilací jaderných modulů pro VMware a nikdy nebylo možné předem říct, zda se to s novou verzí jádra či VMware podaří.

Problém představovaly také akce, které vyžadovaly práci s diskem - vytvoření snapshotu virtuálního stroje, jeho zálohování, atp. Pokud se prováděly za běhu, trvaly neskutečně dlouho, protože se běžící virtuály přetahovaly o disk.

Zálohování u VMware

Vytvořit funkční zálohu virtuálního stroje u VMware bylo možné několika způsoby:

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

Proto byly na jaře 2009 zakoupen nový virtualizační stroj, vybaven čtyřjádrovým procesorem AMD Phenom, který měl jako všechny 64-bitové procesory od AMD podporu hardwarové virtualizace. Použitá základová deska byla vůbec první, která pracovala s paměťovými moduly typu DDR 3. Její předností také byly dvě integrované 1GB síťové karty a 8 SATA 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éna 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 zakoupeny další dva stroje, ve stejné HW konfiguraci. Původní stroj snoopy nejprve nahradil stroj linus a hostname odstaveného stroje podědil v dubnu 2010 snoopy.

Nyní byly všechny virtualizační stroje po hardwarové stránce identické, a 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 soubory virtuálních disků nemusely kopírovat po síti či přes externí HDD.

Obvykle se přesun prováděl tak, že..

1. se virtuální stroje pouze zapauzovaly..
2. fyzický stroj zastavil..
3. do nového stroje se přehodil pouze jeden disk z raidového pole..
4. z něj se sestavilo neúplné RAID zařízení..
5. a po jeho namountování se postupně spouštěly virtuální stroje.

Pokud spouštění proběhlo v pořádku, tak se do RAID zařízení přidal chybějící disk a disk na původním hostiteli zůstal k dispozici jako záloha.

I když zavedení šuplíků umožňujících hotswap znamenalo zvýšení administrátorského komfortu, problém se zálohováním virtuálů stále nebyl uspokojivě vyřešen. Díky metodě dvou bezprostředně následujících snapshotů sice byla situace se zálohováním mnohem lepší než dřív a navíc při po přesunu virtuálních strojů vždy zůstávala v záloze druhá polovina replikovaného pole. Ale z dlouhodobého hlediska to nebylo moc praktické řešení.

Zpočátku, kdy strojů bylo jen pár a velikost jejich virtálních disků 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ál totiž nebylo možné zálohovat tak jako linuxové stroje na úrovni souborového systému, jelikož jeho webový administrační systém byl doinstalován jako "black box" externí firmou.

Chtělo to najít řešení, které by zlepšilo možnosti zálohování a umožnilo přesun virtuálních strojů bez ruční manipulace s disky.

Takovou změnu bylo optimální spojit rovněž se změnou virtualizační platformy a tím jednou provždy vyřešit problémy s aktualizací systému virtualizačních strojů.

KVM sice stejně jako Xen vyžadovalo hardwarovou podporu v procesoru, ale na rozdíl od něj je již několik let součástí hlavní vývojové větve linuxového jádra. Jenže přehodit virtuály do KVM znamenalo mít ve virtuálním stroji doinstalované virtio ovladače. V případě linuxových strojů to nebyl problém, protože jsou součástí distribučního jádra, ale u stroje na kterém běžel "nový web", by změna ovladačů znamenala zásah do konfigurace systému, který by mohl být důvodem pro ukončení záruky.

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. Co se vlastně přihodilo?

Byl pátek odpoledne 14.ledna 2011, těsně před koncem pracovní doby. Chtěli jsme provést rutinní přesun virtuálů na nový stroj 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.