Peanuts

Peanuts je název seriálu komiksových stripů, které přesně půl století (od r. 1950) kreslil Charles M. Schulz. Použil jsem ho k označení virtualizační platformy kterou spravuji z toho důvodu, že i mé virtualizační stroje jsou pojmenovány podle postaviček z tohoto komiksu.

Vývoj

V roce 2008 běžel web katedry, osobní stránky uživatelů, e-learningový systém moodle a další weby na jediném fyzickém stroj s operačním systémem BSD. Virtualizovaný stroj běžel pouze jeden - k2, paravirtualizovaný přes Xen. V prostředí Xenu však tehdy nebylo možné provozovat virtuální stroje s operačním systémem MS Windows, protože paravirtualizace vyžadovala podporu v jádře virtualizovaného operačního systému.

Proto bylo třeba zvolit jiné virtualizační prostředí.

VMware

V rámci projektu se na katedře využívalo k virtualizaci strojů s MS Windows VMware Workstation, proto i nový virtualizační stroj, určený k budoucí virtualizaci stroje s novým katedrálním webem měl toto virtualizační prostředí.

Byl to obyčejný desktopový stroj (tower) s procesorem Intel Core Duo, který sice byl 64-bitový, ale neměl podporu hardwarové virtualizace. Stroj dostal hostname snoopy a jako vůbec první virtuální stroj na něm byl spuštěn v červenci 2008 - linuxový support s DCEwiki.

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.

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ý virutalizač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.