Vliv virtualizace na výkon provozovaného systému

Transkript

1 Bankovní institut vysoká škola Praha Katedra informatiky a kvantitativních metod Vliv virtualizace na výkon provozovaného systému Diplomová práce Autor: Bc. Petr Oliva Informační technologie a management Vedoucí práce: Ing. Vladimír Beneš, Ph.D. Praha červen, 2015

2 Prohlášení: Prohlašuji, že jsem diplomovou práci zpracoval samostatně a v seznamu uvedl veškerou použitou literaturu. Svým podpisem stvrzuji, že odevzdaná elektronická podoba práce je identická s její tištěnou verzí, a jsem seznámen se skutečností, že se práce bude archivovat v knihovně BIVŠ a dále bude zpřístupněna třetím osobám prostřednictvím interní databáze elektronických vysokoškolských prací. V Praze, Bc. Petr Oliva

3 Velice děkuji vedoucímu mé diplomové práce Ing. Vladimíru Benešovi Petrovickému, Ph.D. za cenné rady a za čas, který mé práci věnoval. Můj dík patří také mé rodině za poskytnutou podporu, především mým rodičům za velkou pomoc s korekturou práce, a mé ženě a dceři za toleranci, trpělivost a velkou motivaci. Petr Oliva

4 Anotace Diplomová práce se zabývá vlivem virtualizace na výkon serverové infrastruktury. První část práce je věnována představení zkoumaných virtualizačních technologií a popisu testovacího prostředí. Druhá část představuje záznam průběhu jednotlivých měření. Obsahem třetí části je vyhodnocení a porovnání zjištěných hodnot se stanovením celkového výsledku zkoumání. Klíčová slova: virtualizace, VMware, vsphere, ESXi, Microsoft, Hyper-V, výkonnost Annotation The thesis deals with the influence of virtualization on performance of server infrastructure. The first part is devoted to the presentation of investigated virtualization technology and a description of used testing environment. The second part contains records of each measurement. Content of the third part is evaluation and comparison of measured values and the determination of the overall outcome of the examination. Key words: virtualization, VMware, vsphere, ESXi, Microsoft, Hyper-V, performance

5 Obsah Úvod Vymezení zkoumané oblasti Definice pojmů Popis zvoleného prostředí Zkoumané virtualizační technologie Hyper-V VMware Shrnutí virtualizačních technologií Testovací scénáře Testování výkonu paměti Testování výkonu procesoru Testování výkonu diskového úložiště Testování výkonu síťové vrstvy Testování výkonu aplikací Výkonové testy Fyzické prostředí Hyper-V prostředí VMware prostředí Paměť Fyzické prostředí Hyper-V VMware Procesor Fyzické prostředí Hyper-V VMware

6 2.4 Diskové úložiště Fyzické prostředí Hyper-V VMware Korekční test Síťová vrstva Fyzické prostředí Hyper-V VMware Aplikace MS SQL Fyzické prostředí Hyper-V VMware Vyhodnocení a porovnání výsledků Paměť Procesor Diskové úložiště Síťová vrstva Aplikace MS SQL Celkové hodnocení Závěr Seznam použité literatury

7 Úvod Slovo virtual by se z angličtiny dalo přeložit jako fiktivní nebo zdánlivý. Toto spojení by tedy mohlo evokovat zdání, že virtualizace je něco nereálného, či falešného. Faktem je, že princip této technologie je na určité fikci založen. I přes to, že uvnitř nějakého obalu se dějí unikátní procesy, vně tohoto obalu se celek tváří jako něco úplně jiného, strukturou jasně definovaného. Kdokoliv nebo cokoliv je pak v interakci s takovýmto objektem, nepochybuje o jeho relevantnosti. Z pohledu zaměření mojí práce lze podle mne též zjednodušeně říci, že virtualizace je systém sdílení zdrojů fyzického počítače mezi mnoho různých, na něm běžících prostředí. Virtualizace je pojem, který se v posledních letech stal v oblasti informačních technologií pojmem velmi výrazným. Za nespornou výhodu této technologie je pokládáno především výrazné snížení nákladů na správu a provozování serverové infrastruktury. Technologie jako taková však není pouze o virtualizaci serverů, případně klientských stanic, ale virtualizovat můžeme i jednotlivé aplikace. Existuje ještě celá řada dalších oblastí, které postupně doplňují virtualizační prostředí, například virtualizace celé síťové vrstvy, úložiště nebo dokonce celá virtuální datacentra. v následujícím textu se však budu podrobněji věnovat převážně virtualizaci serverů a vlivu virtualizace na výkon provozovaných aplikačních systémů. První kapitola mojí práce je věnována teoretickému základu. Představím virtualizační technologie, se kterými budu pracovat v praktické části, popíši prostředí, na kterém budu testování provádět a také zvolený postup testování a důvody, proč jsem postup testování použil. Ve druhé kapitole se budu věnovat samotnému provedení testů a seřazení relevantních výsledků. Ve třetí kapitole vyhodnotím výsledky zjištěné vlastním testováním a jejich shrnutí porovnám s informacemi dostupnými na internetu. 7

8 1 Vymezení zkoumané oblasti 1.1 Definice pojmů Samotnou virtualizaci jako definici jsem popsal již v úvodu a zaměřím se proto na definici několika dalších pojmů použitých v následujícím textu, jež mohou být pro čtenáře neznámé. Základem virtualizace je software, který samotnou virtualizaci umožňuje a v oblasti serverové virtualizace se tento software nazývá hypervizor. Tento software si můžeme velice zjednodušeně představit jako operační systém (kterým ale ve skutečnosti není) a jeho práce spočívá v poskytování fyzických hardwarových zdrojů virtuálním serverům a v kontrole toho, aby se virtuální servery dostaly pouze k těm zdrojům, které mají povoleno využít. Jedná se o mezivrstvu maskující fyzický hardware a kontrolující distribuci jeho zdrojů. Jak moc je ve své práci hypervizor efektivní a zda jím přidělené zdroje reálně odpovídají zdrojům samotného hardwaru, je hlavním cílem této práce. Je známo, že vývoj a architekturu hypervizorů pojal každý z výrobců po svém, přičemž dva lídři na poli virtualizace (podle Gartnera 2014 [2]) nemají technologicky prakticky nic společného. O to zajímavější bude právě jejich zařazení do porovnání. Jejich bližšímu představení se věnuji v podkapitole 1.3. Fyzický server, na kterém běží hypervizor se nazývá host. Toto označení je převzato z anglického jazyka, kde je slovem host označován hostitel. Anglickým protějškem českého významu slova host je slovo guest. Na první pohled je patrné, že výraz host reprezentuje v obou jazycích významové protiklady a proto může být v českých odborných textech problém správně porozumět významu. Autor proto obvykle v úvodu svého textu seznámí čtenáře s terminologií, kterou bude používat. Běžněji však odborná veřejnost tyto výrazy nepřekládá a používají se tvary anglické. Já v této práci pro lepší čitelnost používám pro anglické výrazy následující česká spojení: host - hostitel, případně hostitelský systém; guest - hostovaný systém. 1.2 Popis zvoleného prostředí Stanoveným cílem této práce je porovnání výkonu virtualizovaného serveru s výkonem serveru fyzického. v reálném světě, v reálném nasazení, se takové srovnání provádí poměrně těžko, protože výkon je měřen primárně na aplikaci, která na daném serveru běží. To, zda aplikace funguje dostatečně rychle, respektive zda má požadované odezvy, ovlivňuje mnoho 8

9 faktorů, počínaje konfigurací operačního systému serveru, přes architekturu firemní sítě, diskových úložišť, až po klientské stanice, ze kterých je aplikace používána. Všechny tyto prvky mohou mít vliv na výkonnost aplikace, nicméně primární a zásadní vliv má opravdu server, na kterém je aplikace provozována. Výrobci aplikací také vždy definují minimální požadovanou konfiguraci serveru, na kterém aplikace může být provozována. Tato konfigurace je pak buď předepsána jako minimální doporučená, tedy taková, od které je běh dané aplikace výrobcem uznán jako optimální, nebo dokonce striktně doporučený, kdy výrobce dané aplikace nepodporuje a ani svými techniky neimplementuje nasazení na konfiguracích nižších. Neznamená to však, že na nižších konfiguracích nemůže aplikace fyzicky běžet a například při budování testovacího prostředí se tyto limity nedodržují, neboť vytížení v testovacím prostředí je minimální. Velmi zřídka jsou pak tyto předepsané konfigurace rozděleny na konfigurace pro fyzické servery a pro servery virtuální. Na základě toho lze předpokládat, že jsou požadavky buď dostatečně naddimenzovány, nebo je vliv samotné virtualizace natolik zanedbatelný, že ho výrobci neberou v úvahu. Výkon softwaru ovlivňuje vždy několik základních faktorů (prvků). Tím nejdůležitějším je výkon procesoru (CPU 1 ), dále pak rychlost pamětí (RAM 2 ), rychlost pevných disků, respektive obecně úložišť a v neposlední řadě rychlost síťové komunikace, pomocí které aplikace komunikuje s uživateli. Tyto prvky mezi sebou samozřejmě musí také komunikovat, neboť každý z nich provádí při běhu aplikace svůj díl práce. Vzájemnou komunikaci zajišťuje systémová sběrnice s řadiči, která je obsažena na základní desce každého počítače 3 a proto je samozřejmé, že i čipová sada základní desky bude mít vliv na výkon celého systému. v praktické časti práce, v kapitole 2, však nebudu tuto část systému testovat přímo, protože testovací nástroje jsou v této oblasti velmi omezené, nicméně pomocí testovacího scénáře na měření výkonu aplikace, bude spolu s dílčími výsledky z ostatních částí testování možné vliv virtualizace na výkon samotné čipové sady hrubě odhadnout. Jak jsem již zmínil v předchozí kapitole, virtualizované servery běží na softwaru zvaném hypervizor, který je nainstalován na serveru fyzickém, a jehož prací je rozdělovat dostupné hardwarové zdroje virtuálním serverům nad ním běžícím. Z toho je možné poměrně jasně odvodit fakt, že samotný hypervizor, jakožto software běžící na fyzickém serveru, spotřebovává určité zdroje daného fyzického serveru, což můžeme pokládat za výkonovou CPU Central Processing Unit RAM Random Access Memory Do moderních procesorů je například přímo integrován paměťový řadič a není tedy součástí čipové sady základní desky zajišťuje efektivnější a rychlejší práci procesoru s pamětí. 9

10 režii virtualizace. Tato režie je pro každý hypervizor jiná. v kapitole 1.3 se budu zmiňovat například o nárocích na diskový prostor a operační paměť, nicméně pro cíl této práce se jedná o položku nepodstatnou. Konsolidace virtuálních serverů na jednom hostu v ČR totiž dosahuje průměrně hodnotu 45:1 4 a vlastní režie hypervizoru je v poměru se spravovanými hardwarovými zdroji naprosto zanedbatelná ve všech ohledech. Přesto všechno, vzhledem k tomu, že se budu snažit srovnávat naprosto shodné konfigurace jak fyzického hardwaru, tak virtuálních serverů, mohla by režie hypervizoru samotného značně ovlivnit výsledky virtuálních serverů, samozřejmě v jejich neprospěch. Ze všech výše popsaných důvodů jsem zvolil testovací prostředí tak, aby pro testování virtuálních serverů existovala dostatečná výkonová rezerva fyzického serveru pro běh hypervizoru. Všechny výkonové testy budou probíhat na jednom jediném fyzickém serveru Dell PowerEdge Jedná se o rackový, dvouprocesorový server Dell deváté generace, který byl uveden do prodeje již v roce Jedná se tedy o 9 let starý hardware, nicméně právě stáří serveru, potažmo jeho nízký výkon v porovnání s aktuálními modely, může lépe ukázat případný rozdíl v měřené výkonosti. Server byl svým dizajnem určen k provozování infrastrukturních aplikací, webových aplikací, databází, souborových nebo tiskových serverů. Mohl obsahovat až dva čtyř-jádrové procesory Intel Xeon série 5300 o taktu až 3.0 GHz na jednom jádru, čipovou sadu Intel 5000X, dále až 32 GB paměti (s funkcemi FBD, ECC, SDDC 5 ) o rychlosti 533 nebo 667 MHz a až 4,5 TB vnitřní diskové kapacity (při použití šesti 750 GB SATA 7200 otáčkových pevných disků v surové kapacitě nebo v RAID 0 anebo v JBOD konfiguraci). Tato disková konfigurace je ve specifikaci serveru pouze s ohledem na kapacitu, běžněji se servery osazovaly mnohem rychlejšími disky SAS s 10 nebo 15 tisíci otáčkami, které se však podle velikosti disku dodávaly v daleko menších kapacitách (2,5 (max. 8 na server) GB pro 10k, 73 GB pro 15k; 3,5 (max. 6 na server) 400 GB pro 10k, 300 GB pro 15k). Na základní desce pak byla integrována dvouportová síťová karta s rychlostí 1 Gb/s. Na dnešní dobu jsou tyto parametry s ohledem na virtualizaci naprosto nedostačující, avšak v roce 2006 se hardware pro potřeby virtualizace ještě prakticky nenavrhoval. 4 5 Zdrojem informace je VMware Webtech porovnání ESXi vs Hyper-V, kde Vojtěch Morávek (Systems Engineer VMware) sděluje, že VMware Česká republika eviduje u největších instalací v ČR mezi 40 a 50 virtuálními servery na jednom host serveru. [22] FBD Fully Buffered Dimms; ECC Error Checking and Correction; SDDC Single Device Data Correction 10

11 Aktuální použitá konfigurace serveru Dell PowerEdge 2950 (Service Tag: DB3K23J, verze BIOS 1.3.7) se skládá ze dvou čtyř-jádrových procesorů Intel Xeon E5345 o taktu 2.33 GHz na každém jádru, s Level 2 cache o velikosti 2x4 MB. Rychlost systémové sběrnice je 1333 MHz. Celkem 4 GB operační paměti v osmi paměťových modulech po 512 MB - jedná se o plné osazení paměťových bank. Paměť je typu DDR2 o taktu 667 MHz, a jak jsem zmínil výše, jedná se o Full Buffered moduly s ECC (plná vyrovnávací paměť a hlídání a oprava chyb). Server je osazen šesti pevnými disky, z nichž jeden je 3,5 SATA disk Western Digital Caviar SE (WD800JD) o kapacitě 80 GB a rychlosti otáčení 7200 otáček za minutu, další dva jsou 3,5 disky SAS Seagate Cheetah 15K.7 (ST SS, ST SS) o kapacitě 300 GB a rychlosti otáčení otáček za minutu a další tři disky jsou 3,5 SATA Seagate Barracuda ES (2xST NS, 1xST N8) o kapacitě 750 GB a s rychlostí otáčení 7200 otáček za minutu. Všechny disky jsou zapojeny do fyzického RAID řadiče PERC 5/i (verze firmware a verzí BIOS MT28) s vlastní vyrovnávací pamětí DDR o kapacitě 256 MB a funkcí zápisové cache (zápisové požadavky se zapisují do vyrovnávací paměti řadiče, která je velmi rychlá, a následně se z paměti zapisuje na disky). Kvůli bezpečné funkci write back cache je řadič osazen zálohovací napájecí baterií, která v případě náhlého výpadku napájení udrží paměť řadiče v provozu, aby se data v ní uložená neztratila paměť řadiče je klasická DDR RAM, tedy po odpojení napájení se data v ní uložená ztratí. Tento konkrétní server je v řadě 2950 z poslední generace (třetí), a byl vyroben v září roku Dvouprocesorová konfigurace mi umožňuje na jednom fyzickém serveru otestovat jak výkon fyzického serveru, tak i výkon virtualizovaných serverů s dostatečnou výkonovou rezervou pro režii hypervizorů. Pro testování výkonu fyzického serveru osadím server pouze jedním procesorem a polovinou paměťových modulů. Dostanu tak fyzický server v konfiguraci s jedním čtyř-jádrovým procesorem, 2 GB paměti ve čtyřech 512 MB modulech. Po plném osazení serveru druhým procesorem a čtyřmi paměťovými moduly bude možné nadefinovat v hypervizorech virtuální server se stejnými parametry jako fyzický server s jistotou, že zbyde dostatek volných zdrojů pro režii hypervizoru, aby výsledky měření výkonu virtuálních serverů nebyly touto režií ovlivněny. Co se týče úložiště, server je osazen šesti pevnými disky, z nichž ten nejmenší (WD) bude určen k instalaci hypervizoru Hyper-V. Rychlé, 15-ti tisíci otáčkové disky, budou nakonfigurovány v RAID 1 (zrcadlení) a ten bude fyzicky rozdělen na tři virtuální disky, které budou určeny pro všechna testovaná prostředí (fyzický server, Hyper-V a VMware). v případě testování fyzického serveru bude operační systém na 11

12 disk nainstalován přímo, v případě testování virtuálních serverů bude z disku vyrobeno úložiště hypervizoru, na kterém budou umístěny všechny soubory virtuálního serveru, kromě swapovacího souboru hypervizoru, který by mohl výkonost úložiště ovlivnit v neprospěch virtuálních serverů (podrobněji popisuji problém v kapitole 1.5.3). Každý z hypervizorů používá jiný souborový systém pro virtuální úložiště, nicméně souborový systém testovaného serveru bude vždy NTFS. Zbývající tři velkokapacitní disky budou nakonfigurovány do skupiny RAID5 (stripe s paritou) a na ní budou vytvořeny také tři virtuální disky, na kterých budou umístěny soubory s databází pro test aplikačního výkonu 6. Tímto způsobem bude vždy v maximální možné míře poskytnuto testovanému serveru odpovídající prostředí a výsledky testů by tak měly reflektovat pouze vliv samotného zvirtualizování serveru do dvou různých virtualizačních technologií. Ostatní hardwarové komponenty již nejsou režií hypervizorů přímo dotčeny, protože je pro svůj běh nevyužívají. 1.3 Zkoumané virtualizační technologie Pro svoji práci jsem si vybral dvě virtualizační technologie předních představitelů podnikové virtualizace, a to VMware vsphere a Microsoft Hyper-V. i přes majoritní podíl produktů VMware se v praxi poměrně často setkávám právě s virtualizačními produkty od společnosti Microsoft. Ke splnění cílů této práce je porovnání výkonu fyzického serveru se dvěma největšími (a v praxi prakticky jedinými) zástupci virtualizačních platforem podle mne dostatečně průkazné Hyper-V Produkt Microsoft Hyper-V byl vyvíjen pod kódovým označením Viridian a obecně je znám jako Windows Server Virtualization. Je založen na bázi hypervizoru a je určen pro systémy x86 a x64. Beta verze Hyper-V byla vydána s určitými edicemi Windows Server 2008 a ostrá verze pak přišla automaticky přes Windows Update 26. června Hyper-V byl posléze vydán i jako samostatný produkt zdarma. Aktuální produkční verze je Hyper-V v3, která byla vydána v rámci produktové řady Microsoft Windows Hyper-V existuje ve dvou variantách, a to jako samostatný produkt zvaný Microsoft Hyper-V Server 2008, a dále jako instalovatelná role v serverech Windows Server 2008, 2008 R2, 2012 a v aktuální edici rodiny Windows Server 2012 R2. 6 Zvolené diskové skupiny jsou zvoleny s ohledem na krytí chyby při výpadku některého z disků, nikoliv s ohledem na výkon. v produkčním prostředí by tato konfigurace diskových skupin, i vzhledem k nízké rychlosti disků, byla nevhodná. 12

13 Samostatná verze Hyper-V, jak již bylo zmíněno, je k dispozici zcela zdarma a byla vydána 1. října Jedná se vlastně o instalaci jádra systému Windows Server 2008 s plnou funkcionalitou Hyper-V, avšak bez možnosti instalovat ostatní role a s omezenými službami Windows serveru. Tato edice také neobsahuje grafické uživatelské rozhraní (GUI) a veškeré operace se provádí příkazy v prostředí Power Shell (jedná se o vylepšený systém příkazové řádky v systémech Windows, umožňující především psaní a spouštění skriptů, atd.). Vzhledem ke skutečnosti, že veškeré operace jsou prováděny z příkazové řádky, jsou k dispozici ke stažení mnohé hotové skripty, usnadňující správu systému. Správa a konfigurace hosta i guesta je pak možné provádět i přes rozšířené MMC (Microsoft Management Console) nainstalované na klientské systémy Windows 7 a novější, případně Windows Server 2008 a novější. Tato možnost již nabízí grafické prostředí pro správu a monitorování Hyper-V Serveru ovládané myší, nicméně je vhodné spíše pro jednodušší operace a udržování plně nakonfigurovaného prostředí, provedeného dříve přes Power Shell konzoli. Zde bych rád podotkl, že díky architektuře samostatného Hypervizoru, tedy celého jádra Windows Server, je Hyper-V ze své přímé konkurence (XEN a ESXi) největší, co se obsazeného místa na disku a obsazené paměti týče. Architektura systému je založena na vzájemně oddělených částech, zvaných partition. Přímo nad hardwarem počítače operuje hypervizor (Hyper-V), nad kterým musí být alespoň jedna zdrojová část (parent partition) s běžícím podporovaným operačním systém Windows Server (2008, 2008 R2, 2012 nebo 2012 R2). Virtualizační vrstva běží ve zdrojové části a má přímý přístup k hardwarovým zařízením. Zdrojová část pak vytváří podřízené části (child partition), které hostují operační systémy virtuálních strojů. Virtualizované části nemají přístup k samotnému fyzickému procesoru, ani nemohou pracovat se skutečnými přerušeními. Podřízené části nemají ani přímý přístup k hardwarovým zdrojům. Místo toho jsou pomocí zdrojové vrstvy vytvořeny jejich virtuální obrazy, virtuální zařízení. Jakýkoliv požadavek na virtuální zařízení je přesměrován skrz rozhraní VMBus na zařízení ve zdrojové části, která jej dále zpracuje. VMBus je logický kanál, který umožňuje komunikaci mezi jednotlivými částmi systému. Stejně tak odezva fyzického zařízení je skrze VMBus přesměrována zpět na virtuální zařízení. Pokud je zařízením ve zdrojové části jiné virtuální zařízením, požadavek je přesměrováván dál a dál, dokud nedosáhne tu zdrojovou část, která umožní přímý přístup na fyzické zařízení. Zdrojové části dále obsahují Virtualization Service Provider (VSP), službu, která se připojuje k VMBusu a ovládá požadavky na zařízení z podřízených částí. Podřízené části obsahují službu Virtualization Service Client (VSC), která přesměrovává požadavky do 13

14 VSP v základních částech skrz VMBus. Celý tento proces je pro hostovaný OS 7 transparentní. Schéma architektury znázorňuje obrázek 1. 8 Virtuální zařízení také mohou využít výhod funkce Windows Server Virtualizace zvané Enlightened I/O. Tato funkce umožňuje speciálním vysokoúrovňovým komunikačním protokolům, jakými je třeba SCSI, komunikovat přímo s VMBusem, čímž obchází vrstvu emulace zařízení. Tím je komunikace mnohem efektivnější a virtualizované systémy mohou běžet mnohem rychleji, než kdyby využívaly emulovaný hardware. Hostované systémy (guest) musí ovšem tuto funkci podporovat. Funkce může pracovat s procesy ukládání dat, síťové komunikace, grafickými podsystémy a další. Obrázek 1 Architektura Hyper-V (zdroj: [10]) Hyper-V ve Windows Serveru 2008 nepodporuje funkci live migration, tedy stěhování běžících virtuálních serverů mezi hosty. Místo toho Hyper-V na edicích Server 2008 Enterprise a Datacenter podporuje funkci quick migration, kde je při přesunu virtuální stroj 7 8 OS Operační systém Na obrázku stojí mimo jiné za povšimnutí, že Microsoft v této architektuře využívá pouze dvou ochranných pásem procesoru (ring 0 a ring 3). Důvodem je základ v operačním systému Windows, který tímto omezeným způsobem pracuje napříč všemi edicemi. Není však mým záměrem označit toto chování za špatné nebo dokonce chybné uvádím pouze jako zajímavost. 14

15 na jednom hostiteli uspán a na druhém poté spuštěn. Operace odstaví virtuální stroj z provozu na dobu potřebnou k přesunu celé uložené aktivní paměti z jednoho hostitele na druhý. i přes to, že se jedná o časy v řádu několika sekund, může to vyvolat v určitých případech značné nepříjemnosti. S vydáním Windows Serveru 2008 R2 je již v rámci Hyper-V funkce Live Migration podporována při použití sdílených disků Windows Clusteru (CSV Cluster Shared Volumes). v edici Windows Server 2012 pak přibyla možnost využít funkci live migration bez nutnosti sdíleného úložiště a lze pomocí jí stěhovat běžící virtuální servery dokonce i mezi dvěma samostatnými Hyper-V servery. Tato funkce je označována jako Shared Nothing Live Migration, tedy živá migrace bez čehokoliv sdíleného. K tomu Microsoft přidal i funkci zvanou Hyper-V Replica, která běžící virtuální servery replikuje v nastavených pravidelných intervalech (ve verzi Hyper-V 2012 R2 je to 30s, 5 minut nebo 15 minut) na jiného hosta (případně klastr) a tím zajistit rychlé obnovení daného serveru v případě problému primární lokality zajištění takzvané Business Continuity. Hyper-V 2012 R2 navíc přidalo možnost nastavit repliku z repliky a tím zajistit dvojí jištění. v cílové lokalitě jsou replikované servery vypnuté, a tedy nespotřebovávají žádné výpočetní zdroje, samozřejmě kromě diskového prostoru. Na principu funkce live migration je také realizováno vyvažování zátěže hostujících serverů tak, že se jednotlivé virtuální stroje přesouvají z jednoho člena clusteru (nodu) na druhý, pokud je jeden enormně vytížen na úkor druhého. Tato funkce je nazývána Automatic workload balancing, neboli automatické vyvažování pracovní zátěže. [10] Mezi podporovanými hostovanými operačními systémy na hypervizoru Hyper-V v3, tedy v aktuální verzi, najdeme výhradně produkty z dílny Microsoft. Jedná se konkrétně o Windows Server 2008, 2008 R2, 2012, 2012 R2 a klientské OS Windows Vista, 7 a 8. Všechny systémy ve variantách 32 i 64 bitové architektury, pokud jsou k dispozici (Windows Server 2008 R2, 2012, 2012 R2 jsou výhradně 64 bitové). Po stížnostech z řad uživatelů přidal Microsoft i podporu pro Linuxové platformy Red Hat 6, SUSE 11 a CentOS 6, opět pro obě varianty architektury. Tato podpora je však podporou ve smyslu možné instalace těchto operačních systémů na hypervizor Hyper-V. Například správa paměti nebo zálohování s Linux platformou vůbec nepočítají a takových oblastí je mnoho. [5] 15

16 Podporu Linuxových platforem je proto třeba brát s rezervou, neboť, dle mého názoru, v reálném nasazení zatím neobstojí. Nicméně Microsoft uvažuje podporované hostované OS jako ty, které je on sám schopen pro své zákazníky podporovat, tedy svými technickými pracovníky, případně vlastním komunikačním kanálem s výrobcem daného OS. Zákazníci s platnou podporou na Hyper-V se tak mohou vždy obrátit s jakýmkoliv problémem přímo na technickou podporu Microsoft, která zajistí řešení vlastními zdroji nebo zajistí řešení u výrobce podporovaného OS. Pro zákazníky tak odpadá hrozba tzv. ping-pongu, kdy si technická podpora dvou nebo více výrobců svázaných technologií přehazuje vzniklý problém mezi sebou při neustálém přesouvání zodpovědnosti na druhé (je příčina problému v OS nebo Hypervizoru?).(Oliva, 2013) VMware Společnost VMware, Inc. byla založena v roce 1998 a sídlí v Palo Alto, v Kalifornii v USA (Silicon Valley). Jejím většinovým spoluvlastníkem je společnost EMC Corporation. [12] Produktové portfolio společnosti VMware se týká výhradně virtualizace, za to však v plné šíři a na vrcholu jak technologickém, tak funkčním. Kromě základní virtualizace na klientských stanicích (Workstation, Fusion, Player) a virtualizace serverové (ESXi a vcenter) se v dnešní době věnuje především virtualizaci sítí a úložišť (NSX a Virtual SAN) a s pomocí nástrojů na orchestraci a automatizaci se soustředí na virtualizaci kompletního datacentra (vcloud Suite). Cílem je tedy koncept Softwarově definovaného datacentra. Další oblastí je pak virtualizace desktopů a jejich správa (skupina produktů Horizon), správa mobilních zařízení a BYOD 9 (AirWatch) a konečně platforma pro virtualizace celého firemního pracovního prostředí (Workspace Suite). Cíl této práce je zaměřen na základní stavební kámen virtualizace, kterým je hypervizor. VMware software poskytuje kompletní virtualizaci hardwaru pro hostovaný operační systém. Virtualizuje se hardware pro grafický adaptér, síťový adaptér a adaptéry pevných disků (řadiče). Hostující systém poskytuje průchod pro ovladače USB portů, sériových a paralelních zařízení. Díky tomu se virtuální stroje VMware staly vysoce přenositelnými mezi různými počítači, protože pro hostující OS se každý host tváří téměř identicky. v praxi to znamená, že systémový administrátor může pozastavit běžící virtuální stroj na jednom počítači, přesunout nebo jej zkopírovat na jiný, a obnovit jeho běh přesně tam, kde byl na 9 BYOD Bring Your Own Device Firmy umožňují zaměstnancům využívat vlastní zařízení k přístupu k firemním informacím. 16

17 původním stroji pozastaven. Na podnikových serverech obdobnou funkci nazýváme vmotion. Ta opět umožňuje přesunutí běžícího virtuálního stroje z jednoho serveru na druhý v rámci jednoho úložiště. Zde však přesuny probíhají pro všechny uživatele daných virtuálních strojů prakticky bez povšimnutí (při spuštěném průběžném pingu na přesouvaný stroj je vidět přerušení provozu a to viditelně time outem jednoho z pingů, což některé aplikace nemusí snést bez problémů). Další důležitou funkcí je vytváření mnohonásobných bodů obnovení (snapshot), což umožňuje vytvoření jakéhosi stromu uložených stavů, kde se v každém okamžiku můžete přesunout na libovolný z nich. Například je tak možné vytvořit si z jednoho virtuálního stroje celou řadu testovacích strojů různých konfigurací a dle potřeby se mezi nimi přesouvat. Výhodou je především to, že všechny snapshoty na stejné úrovni stromu mají jeden základ a ukládá se tedy vždy pouze datový rozdíl. Výsledná velikost takového stromu je mnohokrát menší, než kdyby každý bod byl samostatným strojem. i při jejich vytváření je práce obdobným způsobem velmi usnadňována. Tato funkce je jednoduše neocenitelným pomocníkem především pro testery a vývojáře. Využití je však obecné a velmi široké. 17

18 Obrázek 2 VMware Workstation - správce snapshotů (zdroj: [14]) VMware ESXi server je v současné době jediný produkt určený pro podnikovou sféru, který je společností VMware vyvíjen. Přináší výrazně vyšší výkonnost než jeho předchůdce ESX server nebo dříve volně dostupný VMware Server a to především díky nižší režii. Jak již bylo zmíněno, jedná se o samostatný produkt, který ke svému běhu nepotřebuje hostující OS a zavádí se přímo na hardware fyzického počítače. Nejprve se nastartuje jádro systému Linux, které nahraje do paměti různé specializované virtualizační komponenty, včetně VMkernel. Následně se tento zprvu zavedený Linux stane prvním virtuálním strojem a dále je nazýván servisní konzolí. Při normálním běhu je tedy VMkernel spuštěn přímo na fyzickém počítači a servisní konzole na bázi Linuxu běží jako první virtuální stroj. VMkernel sám má tři rozhraní do okolního světa - hardware, hostované systémy (guests) a servisní konzoli. Zajímavost ohledně názvu produktu, který učinil ze společnosti VMware jednu z největších softwarových společností světa, tedy ESX serveru je, že se jedná o akronym pro 18

19 Elastic Sky X, avšak až na velmi vzácné výjimky se tento název v oficiálních materiálech VMware neobjevuje. Verze ESXi pak vznikla vydáním nové, technologicky odlišné, verze hypervizoru, který byl plně integrován a nepotřeboval žádný hostující OS. [13] Rozdíl mezi verzemi ESX a ESXi je tedy poměrně zásadní co se architektury týče a i přes to, že se v případě ESXi jedná o následníka ESX, a že poměrně dlouho koexistovaly a byly souběžně vyvíjeny. Oba tyto produkty jsou úzce vázány na správcovské prostředí vcenter, podle kterého jsou také verzovány. ESX jako první produkt rodiny vznikl v první produkční verzi s typickým označením 1.0. Od verze 3.0 pak přibyl v portfoliu produkt ESXi, který je aktuálně jediným pokračovatelem a to ve verzi 6.0. Projekt ESX byl ukončen verzí 4.1 z 13. července 2010, která však dostala poslední update ještě 30. srpna Původně vznikla ESXi varianta jako odlehčený hypervizor, zabírající jen 32GB místa na lokálním disku, která měla být spravovaná vzdáleně přes síť skrze VMware Infrastrukture Client Interface. To umožnilo využití více zdrojů na provozované VM. Myšlenka to byla natolik dobrá, že od verze 5 již jiná možnost ani není nabízena. Správa ESXi je prováděna vzdáleně, tedy z libovolného počítače v síti s nainstalovanou aplikací VMware vsphere Client, nově pak i přes webové rozhraní, které má časem, plně nahradit tlustého klienta. Dle původních informací měl být tlustý klient 10 zcela opuštěn od verze 5.1. Je faktem, že od verze 5.5 je mnoho nových funkcí nastavitelných pouze z webového klienta, avšak zcela opustit tlustého klienta se nepodařilo ani s aktuální verzí 6.0. Důvodem je dlouhé ladění webového klienta, aby byl pro uživatele a tedy zákazníky odpovídající náhradou. Důkazem může být velké množství změn, které byly provedeny s vydáním verze 6.0 a to na základě připomínek komunity uživatelů z předchozích verzí. Cíl je tedy stále stejný a časem webový klient bude jedinou možností, jak virtuální prostředí VMware spravovat. I přes to, že ESXi server s novou architekturou je již na trhu mnoho let, rozdíly v architekturách ESX a ESXi bych zde také rád krátce přiblížil, neboť ukazují jistý trend leadera virtualizací, který budou ostatní výrobci, dle mého názoru, muset nějakým způsobem následovat, pokud chtějí v konkurenčním boji obstát (konkurence využívá architekturu podobnou ESX). Graficky tento rozdíl znázorňují obrázky 3 a Tlustý klient aplikace, která vyžaduje instalaci na počítač uživatele, aby skrze ní mohl přistupovat ke službám serveru. 19

20 vsphere ESX (~2GB diskového prostoru) VMware a agenti třetích stran běží v COS (Console operating system operační systém běžící na Hostu určený pro správu hypervizoru) Většina funkcí pro správu poskytovaných agenty běží také v COS vsphere ESXi (~150MB diskového prostoru) VMware agenti běží přímo na VMkernelu Autorizovaní agenti třetích stran běží také přímo na VMkernelu a poskytují monitoring hardwaru a také ovladače hardwaru (přímá podpora specifických zařízení). Uživatelé se musí přihlásit do COS, aby mohli spouštět příkazy pro konfiguraci a diagnostiku VMware komponenty a komponenty třetích stran se aktualizují nezávisle Tabulka 1 Porovnání hlavních rozdílů architektur ESX a ESXi (zdroj: vlastní) Obrázek 3 Architektura ESX (zdroj: [7]) 20

21 Obrázek 4 Architektura ESXi (zdroj: [7]) Z tohoto jednoduchého porovnání je na první pohled zřejmé, že nároky na prostředky lokálního serveru jsou v případě ESXi nesrovnatelně nižší a efektivita celého virtuálního prostředí je tak daleko vyšší. To je pro uživatele primární faktor, neboť vyšší potřeba zdrojů generuje další náklady. Nesmím zapomenout i na lepší možnosti při správě a monitoringu, kdy je zajištěn přímý přístup k jádru ESXi serveru. Virtuální HOST servery jsou spojovány do celých clusterů či farem a v takovém nasazení je zbytečné, aby každý jednotlivý HOST server měl vlastní administrační konzoli, tedy celý robustní operační systém. Podstata myšlenky virtualizace je maximální využití fyzických prostředků serveru na generování užitné hodnoty a tedy minimalizaci všech procesů, které vlastní užitnou hodnotu negenerují. Pro lepší představu, jak mohou být tyto úspory v případě ESXi serveru přínosné, bych rád uvedl konkrétní hodnotu zabrané operační paměti po čisté instalaci ESXi verze 5.1. Jedná se o pouhých 9 MB! 11 Pro správu paměti používá VMware hypervizor také několik velmi zajímavých funkcí. Jejich popis bude sledově odpovídat jejich postupné aplikaci. Základní funkcí, která je aplikována vždy je Transparent Page Sharing (TPS), kterou znázorňuje obrázek 5. Tato technologie zvyšuje densitu fyzických serverů, tedy jejich možné obsazení virtuálními stroji, až o 20 % 11 Čistá instalace ESXi 5.1 bez zavedených ovladačů hardwaru a spuštěných virtuálních strojů, testováno v laboratoři při školení VMware vspehere: Install, Configure, Manage ve společnosti Arrow,

22 oproti konkurenčním hypervizorům. TPS dokáže identifikovat stejné bloky v paměti a ty sloučit tak, že se v paměti drží pouze jednou. Všechny operační systémy, které dané bloky paměti potřebují, si však myslí, že je jim tato paměť dedikována. Obrázek 5 Transparent Page Sharing (zdroj: [5]) Druhým nástrojem pro efektivnější distribuci paměti je Memory Balooning. Tato technika spočívá ve vypůjčování již přiřazené operační paměti virtuálním strojům tomu stroji, který ji zrovna potřebuje. Konkrétně to funguje tak, že pomocí nástroje VMware Tools požádá virtuální stroj, kterému paměť schází, hypervizor o zapůjčení další paměti. Ten pak poptá ostatní virtuální stroje, zda nemají nějakou volnou, sobě naalokovanou paměť. Pokud ano, VMware Tools na těchto strojích spustí proces, který virtuálně spotřebuje takovou velikost paměti, kterou je daný stroj schopen nabídnout a hypervizor pak tuto paměť uvolní virtuálnímu stroji, který požadavek podal. Ve chvíli, kdy již dodatečnou paměť nepotřebuje nebo ji její původní držitel potřebuje, je zpětným procesem navrácena. Tato technologie velmi pomáhá, zvlášť pokud je virtuálním strojům paměť přímo rezervována. Většina operačních systému a řada aplikací (velice pověstné je tím například MS SQL) si alokuje více paměti, než ve skutečnosti potřebuje a proto tento nástroj pomáhá k jejímu efektivnějšímu využití napříč virtuálními stroji. Pokud nestačí nárokům na paměť virtuálních strojů žádný z předchozích nástrojů, nastupuje třetí nástroj, a tím je komprese paměti. Obsah paměťových bloků je v paměti jednoduše zkomprimován. Komprese paměti však již má vliv na výkon celého systému, a pokud se ve výkonnostních grafech začne tento parametr objevovat, je to pro správce systému signál k tomu, aby situaci začal nějakým způsobem řešit. 22

23 Ve chvíli, kdy již ani komprese paměti nestačí, nastupuje poslední technologie, obecně známá z operačních systémů. Nazývá se swapováním paměti a ve své podstatě se jedná o odkládání méně potřebných, respektive méně žádaných částí paměti, na pevné disky souborového systému. Vezmeme-li v úvahu, že dnešní paměťové moduly mají prostupnost od 8 do 12 GB/s a nejrychlejší současné SSD pevné disky mají rychlost od 0,5 do 1 GB/s, je již na první pohled patrné, jak velký vliv na výkonnost celého host serveru bude nástup této technologie mít 12. Swapování paměti je nástroj pro udržení přetíženého host serveru v provozu a tedy jako nouzová možnost. Rozhodně není určena k běžnému užívání a počítat s ní při návrhu serverové kapacity bych označil přinejmenším za hazard. VMware ESXi může být integrováno do již zmíněného systému VMware vcenter, který nabízí zvláštní služby pro vylepšenou dostupnost a správu virtuálních serverů. Nabízí tak služby jako je: VMotion přesun běžícího virtuálního stroje z jednoho ESXi hostitele na druhý (obdoba live migration ). Storage VMotion možnost přesunout běžící virtuální stroj z jednoho úložiště na druhé. DRS (Dynamic Resource Scheduler) automatické vyvažování zátěže v rámci ESXi clusteru za použití funkce VMotion a nově i Storage VMotion (od verze 5.1). HA (High Availability) v případě, že dojde k selhání hardwaru v rámci ESXi clusteru, virtuální stroje se automaticky restartují na jiném nodu tohoto clusteru. FT (Failure tolerance) vylepšená funkce HA, která v případě selhání hardwaru v rámci ESXi clusteru, přesune virtuální stroje na jiný node a to bez sebemenšího výpadku. Samotný server ESXi je ke stažení i užívání zcela zdarma, stejně tak, jak je tomu i u konkurence. Licence za vcenter edice, které nabízejí všechny výše zmíněné pokročilé funkce, jsou však poměrně drahé. Zájemci o provozování virtualizačního prostředí od VMware si pak musí dobře promyslet, zda a kterou edici do své společnosti pořídí a zda poměrně vysoké pořizovací náklady přinesou i odpovídající protihodnotu do zamýšleného konkrétního nasazení. Nabízené edice jsou v současné době tři, základní Standard, střední Enterprise a nejvyšší Enterprise Plus. Všechny výše zmíněné služby, jsou dostupné již 12 Rychlost běžných pevných disků a levnějších NAS serverů je kolem 0.1 GB/s, běžné SSD pevné disky dosahují 0,5 GB/s, SSD paměťové karty až 1 GB/s. Rychlost nejvýkonnějších Fibre Channel diskových polí je 8 Gb/s, což je zhruba na hranici 1 GB/s (B byte = 8x b bit). 23

24 v základní edici Standard. Jedinou výjimku tvoři funkce DRS, která je k dispozici až od verze Enterprise. Ceny produktů se určuji vždy za každý použitý fyzický procesor klastru a na celkovou cenu má vliv mnoho dalších faktorů. Pro lepší představu však alespoň uvedu, že základní cena edice Standard je nyní 1565 za každý použitý procesor, edice Enterprise 3265 za každý použitý procesor a u edice Enterprise Plus je to 3815 za každý použitý procesor. [7] Ze všech virtualizačních platforem má VMware ESXi server i nejširší základu podporovaných hostovaných operačních systémů. Z důvodu rozsahu a zaměření mé práce zde nebudu zařazovat seznam všech podporovaných operačních systémů tak, jako u ostatních platforem, ale v použitých zdrojích přímo odkazuji na oficiální materiál VMware HOS Compatibility Guide [8]. Za zmínku však jistě stojí, že VMware již do podporovaných OS nezařazuje systémy jako je MS-DOS 6.22, Solarix, či MacOS X, které sice na platformě běží, nicméně firma VMware není schopna jejich podporu zajistit.(oliva, 2013) 1.4 Shrnutí virtualizačních technologií Pro následující část práce týkající se vyhodnocení vlivu samotných hypervizorů na výkon aplikací provozovaných na fyzickém serveru jsem vybral pouze dva výše představené virtualizační nástroje, konkrétně Microsoft Hyper-V 2012 R2 a VMware vsphere 5.5. Důvodem je jejich rozšíření jako systémů pro podnikovou virtualizaci a bez ohledu na značně lišící se čísla různých výzkumů, jsou tyto dva představitelé virtualizace jedinými zástupci virtualizačního trhu, se kterými jsem se ve své praxi v desítkách státních, podnikatelských a jiných organizací setkal. Společnost VMware se na svých stránkách odkazuje na studii věhlasné společnosti Gartner, vyhodnocující virtualizační platformy v polovině roku s ohledem na relevantnost zdroje a faktu, že tento odkaz je mezi hlavními marketingovými odkazy produktových stránek o virtualizaci i v současné době, tedy v polovině roku 2015, dovolím si pokládat jejich hodnocení za stále aktuální. Analytici společnosti Gartner (Thomas J. Bittman, Mark A. Margevicius, Philip Dawson) ve studii popisují velmi podrobně stav na poli virtualizace z různých pohledů a pozice jednotlivých účastníků spolu s jejich silnými stránkami a hrozbami. Shrnuto je pak vše graficky v Magickém kvadrantu, kde jsou v sekci 24

25 lídrů pouze 2 výše zmínění zástupci, z nichž je s velkým odstupem vedoucí VMware, následovaný Microsoft Hyper-V 13. [2] Vojtěch Morávek ze společnosti VMware se ve svém Webtechu Porovnání hypervizorů očima VMware zaměřuje na porovnání konkrétních funkcí převážně u VMware a Hyper-V. Podíváme-li se do historie virtualizace, koncept jaký známe dnes, oznámila společnost VMware v roce v roce 2008 ohlásila použití a využití cloudů. v té samé době, vyšlo první Microsoft Hyper-V. Dlouhé roky náskoku ve vývoji byly opravdu znát, neboť jakékoliv porovnání těchto dvou, v té době jediných platforem použitelných pro virtualizaci serverové infrastruktury, bylo absolutně jednostranné, samozřejmě ve prospěch VMware. Na jaře roku 2012 Microsoft oznámil vydání Windows Serveru 2012 a spolu s ním i Hyper-V verze 3. Tato verze již může být skutečně produktem hodným srovnání s VMware, kde, alespoň v oblasti škálovatelnosti a limitů pro virtuální stroje, Microsoft na vývoji velmi zapracoval. Stále však zůstal u stejné technologie a velmi tak zaostává v densitě a výkonnosti, jak je popsáno výše v samostatném oddílu o Hyper-V. Tato technologie však má ještě jednu, a v případě Microsoft produktů velmi výraznou, slabinu. Je jí vlastní operační systém, v kterém hypervizor běží, tedy Windows Server. Na platformu Windows je totiž vydáváno velmi často velmi mnoho updatů a značná část z nich vyžaduje po své aplikaci restart celého serveru. Tabulka 2, převzatá z výše zmíněného Webtechu, názorně dokazuje, jak neefektivní toto spojení v daném ohledu je. Microsoft vydává své patche pravidelně každé první úterý v měsíci. V období od července roku 2011 do června 2012 bylo každý měsíc vydáno na platformu Windows Server obsahující pouze roli Hyper-V 14 několik důležitých či kritických patchů a po jejich aplikaci byl vždy vyžadován restart serveru. Důležitý je zde však fakt, že žádný z těchto patchů se netýkal vlastní virtualizační platformy a z druhého pohledu i fakt, že samotný operační systém je z hlediska bezpečnosti tím nejslabším místem, který je nutné neustále opravovat a hlídat. Pro úplnost dodám, že tabulka 2 prezentuje hodnoty pro edici Windows Server 2008 R2. v září roku 2012 byla vydána nová verze Windows Server 2012, nicméně ze své zkušenosti nepředpokládám zásadní změnu v aplikaci distribuovaných patchů a nutnosti post-instalačního restartu serveru prakticky pokaždé. [5] Materiál společnosti Gartner je licenčně chráněn proti distribuci bez souhlasu společnosti a nemohu tedy přímo citovat ani použít grafické zobrazení Magického kvadrantu. Odkaz na studii je však z webu VMware veřejný a je proto součástí použitých zdrojů. Rozhodně doporučuji do ní nahlédnout. Patche jsou vydávány pro všechny edice Windows Serveru, nicméně tabulka ukazuje pouze ty, které byly nutné pro čistou instalaci Windows Serveru s rolí Hyper-V a tedy netýkající se jiných rolí, které operační systém může obsahovat. Celkově jich bylo tedy více, než je v tabulce znázorněno. 25

26 Důležité a kritické patche pro jádro OS* Počet updatů týkajících se virtualizace 7/11 8/11 9/11 10/11 11/11 12/11 1/12 2/12 3/12 4/12 5/12 6/ Vyžadován restart? A A A A A A A A A A A A * všechny instalace Hyper-V tyto patche vyžadovaly Tabulka 2 Microsoft patch Tuesdays - vliv patchů OS na virtualizaci (zdroj: [5]) S ohledem na požadovanou vysokou dostupnost aplikací v podnikovém prostředí, je restart hypervizoru, na kterém běží v průměru 45 virtuálních serverů 15, nelehký úkol pro server management. Vlastní restart serveru může trvat i desítky minut, kapacita na přesun virtuálních serverů na jiné hosty bývá značně omezená a vše se v případě Microsoft Windows Serveru děje s měsíční pravidelností. ESXi server lze nazvat tenkým hypervizorem, který kompletně abstrahuje hardwarovou platformu a poskytuje logické zdroje virtuálním serverům. Takto postavenou technologii má aktuálně pouze hypervizor od VMware, jak jsem již podrobněji popsal v sekci týkající se právě ESXi serveru. Oproti tomu ostatní výrobci mají své hypervizory postaveny jako doplňky k operačním systémům (Windows nebo Linux platformy) a jsou na něm více, či méně závislé. Takto fungují jak Hyper-V (Windows Server), tak XEN server (Linux). Pokud celý ESXi server je vyvíjen pouze za jediným účelem a tím je virtualizace, operační systémy pod hypervizory dalších výrobců jsou vyvíjeny se zcela odlišným cílem. Musejí být univerzální a musejí být schopny provozovat i vše ostatní, co se od samotného operačního systému očekává. Virtualizační část od toho celku nelze oddělit a celkově to tedy má negativní dopad na výkonnost a škálovatelnost. v tuto chvíli lze namítnout, že například Hyper-V existuje ve verzi Core, která by měla být čistě jen virtualizační platformou. Marketingově je to jistě nesporné, technologicky však ne zcela. Hyper-V Core zabírá po instalaci pouhých 5 GB diskového prostoru oproti vice než 8 GB plného Windows Serveru 2012, nicméně například Citrix XEN server potřebuje něco přes 1 GB a jak již bylo také zmíněno, ESXi serveru stačí pouhých 144 MB. Z čísel obsazenosti diskového prostoru je patrné, že v případě Hyper-V Core se nejedná o čistě virtualizační prostředí. Tato edice je vlastně jádrem operačního systému Windows Server s přidanou rolí Hyper-V, avšak bez grafického uživatelského rozhraní a bez možností přidávat další role a funkce jako u běžných edic Windows Server. ESXi server je naproti tomu jediným hypervizorem, který může běžet 15 Zdrojem informace je VMware Webtech porovnání ESXi vs Hyper-V, kde Vojtěch Morávek (Systems Engineer VMware) sděluje, že VMware česká republika eviduje u největších instalací v ČR mezi 40 a 50 virtuálními servery na jednom host serveru. [22] 26

27 z flash paměti a toto užití je také oficiálně podporováno. Výrobci hardwaru již řadu let instalují do serverů speciální řadiče osazené SD kartami, které jsou k tomuto účelu určeny (Dell, jako zatím jediný výrobce, má tento řadič v režimu RAID 1, tedy zrcadlení dvou SD karet pro zvýšení dostupnosti). Servery pro virtualizaci v případě VMware hypervizoru tedy nemusí obsahovat drahé diskové řadiče s pevnými disky a tedy jsou mnohem levnější a úspornější. v tomto ohledu jde VMware technologicky hodně dopředu a s odstupem času, od vydání první verze ESXi, lze říci, že se ubírá správným směrem. [5] Společnost Wikibon prováděla v srpnu 2012 průzkum zaměřený na produkty VMware, v němž oslovila 158 respondentů z řad společností, které provozují virtualizační prostředí a každá z nich produkty společnosti VMware provozovala. Pro vedoucího na poli virtualizace to nebylo velkým překvapením. Zajímavý byl podíl ostatních virtualizačních platforem, jakožto dalších provozovaných systémů těchto společností. Celých 43 % respondentů provozovalo pouze produkty VMware, dalších 35 % firem provozovalo kromě VMware i jeden z dalších hypervizorů. Tabulka 3 ukazuje celkový poměr využívaných hypervizorů. Průzkum se nedotazoval na důvody nasazení dalších hypervizorů v organizaci a tak nelze zcela jasně určit váhu podílu dalších hypervizorů na trhu. [3] Použití Hypervizorů u respondentů VMware 68 43% VMware + 1 další 56 35% VMware + 2 další 26 16% VMware + 3 další 6 4% VMware + 4 další 2 1% VMware + 5 další 0 0% Celkem % Tabulka 3 Poměr nasazených hypervizorů dle průzkumu Wikibon 2012 (zdroj: [3]) Ve vlastní praxi jsem se setkal s nasazením hypervizorů od různých výrobců v rámci jedné organizace, přičemž mnohdy se jedná o testování alternativních prostředí pro případnou migraci na levnější řešení vyhovující po technické stránce nárokům státních, podnikatelských a jiných organizací, jindy o dvě produkční řešení, kde druhé, tedy to, které sekunduje VMware produktu, je využíváno pro provoz méně důležitých systémů, neboť je provozováno v režimu zdarma, tedy bez placené podpory, licencí nebo subscription. Velice zajímavý je obrázek 6, který ukazuje podíl druhotných instalací hypervizorů u dotazovaných oraganizací. 27

28 o malý kousek je mezi dalšími ve vedení Hyper-V před XEN serverem od Citrixu. Oba tyto produkty jsou v základních verzích zdarma, jak jsem zmínil v odstavcích věnujících se jim konkrétně, a z pohledu jejich provozovatele tedy nic nebrání tomu, aby testovali jejich nabízené možnosti například na již zmíněných méně důležitých systémech nebo výhradne ve zkušebním režimu. i když se Hyper-V i XEN server prezentují jako produkty zdarma, jejich nasazení v produkčním prostředí s sebou nese vždy provozní náklady, a to buď v podobě placené podpory nebo dalších produktů, které je nutné pro takové prostředí dokoupit (v případě Microsoft produktů to mohou být plná verze MS SQL, System Center 2012, atd.). Obrázek 6 Podíl ostatních hypervizorů provozovaných vedle VMware (zdroj: [3]) Z předcházejících odstavců lze celkem jednoznačně vyvodit závěr, že nejoblíbenější a také světově nejrozšířenější je virtualizace postavená na VMware ESXi serverech, vcenter managementu a v mnoha dalších rozšířeních, které se souhrnně nazývají VMware vsphere. v oblasti virtualizace je společnost VMware také předním inovátorem a spolu s omezeným rozsahem této práce to jsou důvody, proč následující řádky práce budou věnovány právě a jen produktům od společnosti VMware. Celkový přehled možností, které poskytuje virtualizace v serverové infrastruktuře, bude tak obsažen zcela, přičemž některé z následujících technik a funkcí je pak v nějaké obdobě možno velmi snadno přenést i na prostředí ostatních zmíněných výrobců (časem, jak vývoj konkurenčních produktů bude postupovat, bude jich jistě většina). (Oliva, 2013) 28