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) |
LXC ( akronym angl. LinuxX Containers ) je tzv. kontejnerová virtualizační metoda, při které virtualizovaný systém využívá zdroje linuxového jádra a operačním systému hostitele. Aplikací cgroups, které se v jádře používají k řízení zdrojů, se ve jmenném prostoru jádra hostitele vytvoří oddělený kontejner, ve kterém běží další linuxový systém se svými vlastními procesy, konfigurací sítě, uživatelskými účty atp.
|
|
Výhodou LXC kontejnerů je, že nevyžadují upravené linuxové jádro. Z principu však mají jeden zásadní bezpečnostní problém - a to, že se root uživatel systému, spuštěného v LXC kontejneru, může nabourat do systému hostitele - podobně jako u chrootu.
Až od jádra verze 3.8 se objevily funkcionality, které umožnily LXC kontejner lépe zabezpečit tím, že jeho root je v rámci hostitelského systému namapován na jiného uživatele. To však lze ale považovat spíš za "workaround" než řešení. Tam kde jsou z hlediska bezpečnosti žádoucí skutečně izolované kontejnery je třeba zvolit jiné řešení. Ty ale, na rozdíl od LXC, bez výjimky vyžadují speciálně upravený linuxový kernel. |
Přístup na virtualizované stroje
Na virtualizované stroje lze přistupovat několika způsoby
- 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.)
- Prostřednictvím administrační konsole na hostiteli (VMware, Xen console, Qemu console)
- 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.