Virtualizace

Virtualizační metody používané v rámci DCE

VMware, původně vznikl jako virtualizační nástroj, který měl usnadnit práci vývojářům. Jako takový tedy běžel vždy v rámci jiného OS, skrz který bylo možné se dostat na jeho administrační konzoli. Teprve později (s VMware GSX serverem) se objevila administrační konzole založená na přístupu klient-server. Jelikož se fa. VMware snažila o zachovávat platformní neutralitu, založila své řešení pro přístup k virtualizovaným strojům na VNC protokolu. Využila tak s výhodou již existujícího řešení s řadou klientů pro nejrůznější platformy.

Xen, je virtualizační nástroj, který měl být původně open source variantou komerčního VMware ESX serveru. Jeho hypervizor byl - stejně jako hypervizor pro VMware ESX server - odvozen z linuxového jádra a navíc vyžadoval od virtualizovaného stroje podporu v jádře jeho OS. Proto se Xen, jehož první použitelná verze byla uvolněna v r.2003, využívá především pro virtualizaci linuxových strojů s upraveným jádrem.

Jelikož Xen neřešil nic jiného než vlastní virtualizaci a sám o sobě neobsahoval žádnou konzoli pro vzdálený přístup, nebyl nepovažován firmou VMware za konkurenci. To se však změnilo v okamžiku, kdy firmu XenSource ( která hypervizor vyvíjí ) odkoupila fa. CITRIX (22. října 2007). Hlavní parketou Citrixu byl do té doby byl aplikační server, který umožňoval sdílený přístup k aplikacím, spouštěným v rámci OS Microsoft Windows Server. Na rozdíl od nativního RDP protokolu jejich klient používá ke komunikaci patentově chráněný ICA protokol.

Citrix byl svými produkty vždy úzce spjat s Microsoftem, takže je otázkou v čí hlavě se zrodil nápad využít kapitál skrytý v možnostech ICA protokolu a vytvořit tak konkurenci vůči VMware.

Microsoft přišel v roce 2008 s vlastním virtualizačním řešením Hyper-V, postaveným na platformě Windows Server 2008. To však mělo stejný problém jako Xen, ovšem v obráceném gardu. Plnou virtualizaci bylo možné použít pouze u systémů s upraveným jádrem, zatím co při virtualizaci jiných OS se použila paravirtualizace, která pochopitelně degraduje výkon. Navíc RDP protokol používaný pro vzdálený přístup má daleko k optimalizovanému ICA protokolu.

Citrix ponechal vývoj samotného hypervizoru pod GPL licencí, ale z pochopitelných důvodů neměl zájem na vývoji otevřeného protokolu pro vzdálený přístup. Že se kují nekalé pikle, které mají za cíl z trhu vyšachovat VMware začalo být jasné když v září 2008 většinový podíl v Citrixu v tichosti získala fa. Microsoft.

KVM je zkratkou z anglického názvu této virtualizační metody Kernel-based Virtual Machine, neboli česky: "Virtualizační stroj založený na [linuxovém] kernelu". Jeho vývoj iniciovali vývojáři z fy. Red Hat prakticky ihned poté, co se ukázalo, že vývojáři Xenu nejsou příliš ochotni začlenit kód hypervizoru přímo do linuxového jádra. Red Hat, který z velké části vývoj linuxového jádra financuje, tím pádem neměl do budoucna zajištěno, že nemůže dojít k uzavření kódu hypervizoru Xenu. Tato hrozba se stala reálnou zvláště po odkoupení fy. XenSource Citrixem.

Když začal Microsoftu usilovat o rozhodující podíl v Citrixu, Red Hat - pro který byla tato akvizice přímým ohrožením ochodních zájmů - odkoupil 4. července 2008 za 107 miliónů dolarů firmu Qumramnet, která těsně předtím oznámila vývoj protokolu SPICE, který by se měl stát open source alternativou ICA protokolu. Tímto krokem Red Hat do budoucna zabránil ev. uzavření jeho vývoje.

V praxi jde o stejný virtualizační princip jako používá VMware ESX server či Xen, kdy mezi fyzickým hardware a virtuálními stroji běží tzv. hypervizor, který se stará o rozdělování fyzických prostředků hostitele mezi jednotlivé virtuály.

Na rozdíl VMware ESX serveru či Xenu, KVM nepoužívá paravirtualizaci proto procesor hostitele musí mít hardwarovou podporou virtualizace. Tuto podmínku splňují všechny 64-bitové procesory fy. AMD (včetně mobilních), ovšem u procesorů fy. INTEL to až tak jednoznačné není. Také je třeba dávat pozor na nastavení biosu, ve kterém lze podporu virtualizace vypnout (AMD), nebo naopak zapnout (INTEL)

Přístup na virtualizované stroje

Na virtualizované stroje lze přistupovat několika způsoby

1. Nativně, prostřednictvím standardních nástrojů pro vzdálenou správu (rdp, vnc) resp. poskytovaných serverových služeb (web, ftp, ssh, atd.)
2. Prostřednictvím administrační konsole na hostiteli (VMware, Xen console, Qemu console)
3. Pomocí řešení klient-server (VMware console, Citrix, Spice, VNC,...)

Nativní přístup k virtuálu

Podmínkou pro nativní přístup je funkční síťový přístup z virtuálního stroje do vnější internetové sítě.

Administrační konsole

V případě že dojde k nějakému problému s nastavením sítě, síťového zařízení, nebo služby, která zajišťuje vzdálený přístup, je takový stroj nedostupný. Pokud taková situace nastane, pak lze využít administrační konsole buď přímo na hostiteli. V případě že se problém s připojením týká i hostitele, je přístup přes lokální konzoli jediným možným.

Přístup klient - server

Aby bylo možné přistupovat k virtualizovaným strojům vzdáleně, bez ohledu na to zda samy o sobě podporují vzdálený přístup, využívají všechny virtualizační metody také (kromě přístupu přes lokální konzoli) řešení klient - server, kdy na hostiteli běží nějaká služba (démon), na kterou se lze připojit prostřednitvím klientské aplikace z jiného stroje.

Administrace virtuálních strojů

Administrace virtuálních strojů

Virtuální stroj

Vliv IO operací na výkon virtualizovaného stroje

Pro vytvoření optmalizovaného virtuálního stroje, je třeba si ujasnit jaký vliv na výkon virtualizovaného stroje má typ zvoleného virtuálního disku a jak s tím souvisí IO operace (čtení a zápis na disk).

Unixový OS

U nevirtualizovaného unixového stroje je z praktických důvodů výhodné, je-li systém rozdělen na několik samostatných diskových oddílů. I když pochopitelně lze mít (podobně jako u MS Windows celý systém na jednom spojitém disku.

/boot

Samostatný diskový oddíl /boot se zavaděčem, umístěný hned na prvním diskovém oddíle minimalizuje pravděpodobnost, že by se v případě nějakých hrátek s diskovými oddíly systém nepodařilo nabootovat.

• velikost dat v něm obvykle nepřesáhne 80MB
• počet souborů které obsahuje je zanedbatelný
• Z IO operací se u něj uplatňuje pouze čtení při zavádění operačního systému. Zapisuje se do něj pouze je-li aktualizován zavaděč nebo jádro OS

swap

Význam odkládacího diskového oddílu (swap) se mění podle množství dostupné paměti a rychlosti s jakou systém stíhá zpracovávat obsah paměti. Do swapu se data z paměti odkládají pouze pokud nestačí množství přidělené paměti jinak ne.

• "Swapovací diskový oddíl" se obvykle dělá 1,5krát větší než je velikost dostupné paměti, neboť se využívá také při uspávání OS na disk.
• Je-li paměti dostatek a neplánujeme uspávát OS není swap zapotřebí
• Z IO operací se u něj uplatňuje pouze zápis při odkládání obsahu paměti při velké zátěži, nebo při uspání OS na HDD.

Kořenový adresář /

Sám o sobě není nějak velký, pokud jsou jeho adresáře s největším množstvím dat připojeny jako samostatné diskové oddíly. Obvykle jde o následující adresáře:

/usr

Do tohoto adresáře se ukládá většina instalovaných aplikací. Také v něm administrátor může kompilovat jádro. Jeho oddělení od zbytku systému je výhodné z toho důvodu, že kontrolu jeho souborového systému lze provádět za běhu (diskový oddíl je přemountován aby byl ve stavu read-only). Tím lze mnimalizovat čas pro obnovu systému.

/srv

Tento adresář se používá pro serverové aplikace (web, ftp, aj.) U desktopu je většinou prázdný

/home

U desktopu adresář s největším mnosžstvím dat na kterém jsou umístěny uživatelské účty. Tím že je oddělený od systému, lze aktualizovat systém, aniž by hrozilo riziko ztráty či poškození uživatelských dat.

/var

Z hlediska objemu dat které obsahuje nejde o nijak velký adresář, ovšem z hlediska IO zatížení je zatížený nejvíc ze všech, jelikož se do něj odkládají logy a další systémové soubory.

"Raw" a "grow" formát disku

Při virtualizaci lze použít jak fyzický, síťový nebo virtuální disk. Virtuální disk ve formátu RAW není nic jiného než lokální soubor s obrazem disku, stejný jako když použijeme k zálohování příkaz 'dd'.

Na výkon virtualizovaného stroje pak nemá vliv jen rychlosti IO operací mezi virtualizovaným OS a jeho virtuálním diskem, ale také rychlost IO operací při ukládání změn v souboru virtuálního disku na disk fyzický.

Je-li virtuální disk v RAW formátu, je místo kam se budou data ukládat předem alokováno, kdežto u formátů které podporují "rostoucí" (growable) disk musí hostitelský systém před uložením data přerovnat, což pochopitelně vede k dalším IO operacím a tím i zpomalení IO operací ve virtualizovaném stroji.

Pochopitelně čím větší virtuální disk, tím větší zátěž. Proto je-li to možné, je lepší diskové oddíly virtuálního stroje u nichž probíhá mnoho IO operací, vytvořit jako samostatné virtuální disky v RAW formátu.

Použití "virtio" ovladačů

Pokud virtualizovaný systém používá pro přístup k virtuálnímu disku "virtio" ovladač, dojde k jeho výraznému zrychlení, protože veškeré IO operace mezi virtuálním strojem a jeho diskem probíhají v RAM, a teprve čas od času se uloží do souboru na lokálním fyzickém disku.

Na druhou stranu, když už na ukládání dojde, může být zátěž při ukládání změn tak velká, že může vést ke znatelnému zpomalení (až pozastavení) virtualizovaného stroje, neboť je tímto procesem přiškceno načítání z virtuálního disku. Zcela typicky se to projevuje tak, že to co je již načteno v paměti virtuálního stroje nabíhá bez problémů, kdežto to co vyžaduje načtení dalších dat z disku zdánlivě nereaguje.