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

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:

Praha

Ing. Vladimír Beneš, Ph.D.

červen, 2015

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, 29. 6. 2015

Bc. Petr Oliva

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

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

Obsah Úvod ........................................................................................................................................... 7 1

2

Vymezení zkoumané oblasti ............................................................................................... 8 1.1

Definice pojmů ............................................................................................................ 8

1.2

Popis zvoleného prostředí ............................................................................................ 8

1.3

Zkoumané virtualizační technologie .......................................................................... 12

1.3.1

Hyper-V.......................................................................................................................... 12

1.3.2

VMware ......................................................................................................................... 16

1.4

Shrnutí virtualizačních technologií ............................................................................ 24

1.5

Testovací scénáře ....................................................................................................... 29

1.5.1

Testování výkonu paměti .............................................................................................. 29

1.5.2

Testování výkonu procesoru ......................................................................................... 30

1.5.3

Testování výkonu diskového úložiště ............................................................................ 32

1.5.4

Testování výkonu síťové vrstvy ..................................................................................... 34

1.5.5

Testování výkonu aplikací ............................................................................................. 36

Výkonové testy .................................................................................................................. 37 2.1.1

Fyzické prostředí ........................................................................................................... 39

2.1.2

Hyper-V prostředí .......................................................................................................... 40

2.1.3

VMware prostředí ......................................................................................................... 41

2.2

Paměť ......................................................................................................................... 44

2.2.1

Fyzické prostředí ........................................................................................................... 44

2.2.2

Hyper-V.......................................................................................................................... 45

2.2.3

VMware ......................................................................................................................... 46

2.3

Procesor ..................................................................................................................... 48

2.3.1

Fyzické prostředí ........................................................................................................... 48

2.3.2

Hyper-V.......................................................................................................................... 49

2.3.3

VMware ......................................................................................................................... 50

5

2.4

2.4.1

Fyzické prostředí ........................................................................................................... 53

2.4.2

Hyper-V.......................................................................................................................... 55

2.4.3

VMware ......................................................................................................................... 57

2.4.4

Korekční test.................................................................................................................. 59

2.5

Síťová vrstva .............................................................................................................. 61

2.5.1

Fyzické prostředí ........................................................................................................... 61

2.5.2

Hyper-V.......................................................................................................................... 62

2.5.3

VMware ......................................................................................................................... 63

2.6

3

Diskové úložiště ......................................................................................................... 51

Aplikace – MS SQL ................................................................................................... 63

2.6.1

Fyzické prostředí ........................................................................................................... 64

2.6.2

Hyper-V.......................................................................................................................... 64

2.6.3

VMware ......................................................................................................................... 64

Vyhodnocení a porovnání výsledků .................................................................................. 66 3.1

Paměť ......................................................................................................................... 66

3.2

Procesor ..................................................................................................................... 68

3.3

Diskové úložiště ......................................................................................................... 69

3.4

Síťová vrstva .............................................................................................................. 72

3.5

Aplikace – MS SQL ................................................................................................... 73

3.6

Celkové hodnocení .................................................................................................... 73

4

Závěr.................................................................................................................................. 75

5

Seznam použité literatury .................................................................................................. 76

6

Ú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

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

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 (CPU1), dále pak rychlost pamětí (RAM2), 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če3 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 1 2 3

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

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:14 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 2950. Jedná se o rackový, dvouprocesorový server Dell deváté generace, který byl uveden do prodeje již v roce 2006. 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, SDDC5) 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) - 146 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

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 (ST3300567SS, ST3300655SS) o kapacitě 300 GB a rychlosti otáčení 15000 otáček za minutu a další tři disky jsou 3,5“ SATA Seagate Barracuda ES (2xST3750640NS, 1xST3750330N8) 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 1.03.10-0216 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 2007. 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

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ýkonu6. 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é.

1.3.1 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 2008. 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 2012. 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

Samostatná verze Hyper-V, jak již bylo zmíněno, je k dispozici zcela zdarma a byla vydána 1. října 2008. 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

VSP v základních částech skrz VMBus. Celý tento proces je pro hostovaný OS7 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

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

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)

1.3.2 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 BYOD9 (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

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

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

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 2012. 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ý klient10 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 4.

10

Tlustý klient – aplikace, která vyžaduje instalaci na počítač uživatele, aby skrze ní mohl přistupovat ke službám serveru.

19

vSphere ESX (~2GB diskového prostoru)

vSphere ESXi (~150MB 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

VMware agenti běží přímo na VMkernelu

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

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í).

Tabulka 1 – Porovnání hlavních rozdílů architektur ESX a ESXi (zdroj: vlastní)

Obrázek 3 – Architektura ESX (zdroj: [7])

20

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, 5.10.2012.

21

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

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ít12. 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

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 2014. 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

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 2001. 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]

13

14

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

Důležité a kritické patche pro jádro OS* Počet updatů týkajících se virtualizace Vyžadován restart?

7/11

8/11

9/11

10/11

11/11

12/11

1/12

2/12

3/12

4/12

5/12

6/12

2

5

2

3

2

4

1

4

3

2

4

3

0

0

0

0

0

0

0

0

0

0

0

0

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

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%

158

100%

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

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

1.5 Testovací scénáře Všechna měření budu opakovat minimálně 10x, v případě velkého rozptylu výsledků přidám další měření v násobcích pěti. Tím, že testování bude probíhat uvnitř běžícího operačního systému, který sám o sobě spotřebovává hardwarové zdroje, budou jím výsledky měření značně ovlivněny. Opakovaná měření by měla poskytnout základ pro interpolaci výsledků a určení finální hodnoty pro celkové srovnání. Některé komponenty budou operačním systémem ovlivněny více, jiné prakticky vůbec a je tedy možné, že například u testování výkonu pevných disků, respektive úložiště, bude potřeba měření opakovat vícekrát. Operační systém však bude u všech tří testovaných prostředí totožný, rozdíly v měření tedy budou ovlivněny vždy pouze aktuálním stavem a aktivitou systémových služeb. Služby, které v operačním systému provádí operace pro vlastní funkci systému nedůležité, jako je například služba Windows search, budou vypnuty, protože jejich nároky na systémové zdroje jsou v čase velmi nestálé a měření tím pádem mohou znehodnotit.

1.5.1 Testování výkonu paměti Testování pamětí budu provádět testovacím nástrojem MaxxMEM2 od vývojáře M. Bicana. Jedná se o nástroj určený pro všechny Windows platformy, což mým požadavkům zcela vyhovuje. Jedná se o velice malý nástroj zabírající něco málo přes 1 MB diskového prostoru a nevyžaduje žádnou instalaci. Dokáže měřit rychlost paměti RAM při čtení, zápisu a kopírování, a navíc dokáže zobrazit i latenci paměti (její reakční dobu na požadavky). Z hlediska testování paměti tento nástroj poskytuje velmi detailní informace a na testování výkonu paměti ho budu pokládat za hlavní.

29

Obrázek 7 – MaxxMEM2 (zdroj: vlastní)

Výkonové testy paměti jsou obsaženy i v dalších nástrojích, které budu používat, pro ověření výsledků provedu sérii testů i v komplexním nástroji PassMark Performance Test, který umožňuje testovat čtení a zápis do paměti bloky různých velikostí a testování paměti tak bude velmi komplexní.

1.5.2 Testování výkonu procesoru V zadávacích dokumentacích výběrových řízení na dodávku hardwaru se v naprosté většině případů (z těch, se kterými se potkávám v praxi) udávají požadavky na výkon procesoru jako minimální skóre PassMark testu. Výrobce tohoto nástroje pak na svých stránkách dává volně k dispozici přehledovou tabulku s výsledky testů různých procesorů a na základě této tabulky jsem pak schopen snadno vybrat typ procesoru, který bude odpovídat zadávací dokumentaci výběrového řízení (https://www.cpubenchmark.net/cpu_list.php). Právě na základě širokého přijetí tohoto nástroje odbornou veřejností budu výkon procesoru měřit nástrojem PassMark Performance Test. PassMark Performance Test je však komplexní nástroj na testování výkonu celého počítače. Testuje, kromě již zmíněného výkonu CPU a paměti, i výkon 2D a 3D grafiky, výkon

30

pevných disků, optických mechanik, sítě, testování přímých výpočtů fyziky pomocí CPU (rozšířený CPU test) a přímých výpočtů pomocí GPU a DirectX 11 (test výpočetní síly grafického čipu). Vlastní test CPU obsahuje, kromě klasických matematických operací, i test pomocí komprimace, kryptování, SSE a 3DNow! instrukčních sad. Jedná se o software, jehož pořízení stojí v době, kdy sepisuji tuto práci, $24.30 USD, nicméně výrobce poskytuje 30 dní zkušební lhůtu.[6] Nástroj, kterým budu výsledky měření výkonu CPU ověřovat, je CPU Free BenchMark 2.2. Jedná se opět o velmi jednoduchý nástroj na testování CPU, který nevyžaduje žádnou instalaci a zabírá pouhých 200 kB diskového prostoru. v rámci testování pak aplikace provede 3 testy, kdy první jsou operace s registry, druhý test měří operace v plovoucí desetinné čárce a třetí test jsou operace s celými čísly. Tyto testy pak aplikace provede třikrát za sebou a celkový výsledek je pak složen poměrově ze všech 3 měření. První měření má váhu 20%, druhé a třetí po 40%. Celkovým výsledkem je pak čas, za který byly všechny testy dokončeny. Nedozvíme se sice, kolik operací testované CPU dokáže za sekundu spočítat například v plovoucí desetinné čárce, ale pro porovnání třech testovaných prostředí je prezentovaný výsledek dostatečný.

Obrázek 8 – CPU Free BenchMark 2.2 (zdroj: vlastní)

Při samotném testování nástrojem CPU free BenchMark 2.2 jsem zjistil, že dokáže efektivně zatížit pouze jedno jádro, proto výsledek multiprocesorového prostředí nebude zcela

31

odpovídající. Všechna jádra jsou však na všech testovaných systémech stejná a tak i tento test může být pokládán za relevantní.

1.5.3 Testování výkonu diskového úložiště Testování úložiště je ze všech výkonových testů prováděných v této práci zřejmě to nejsložitější. Nemyslím to však ve smyslu složitosti samotného testování, ale z hlediska zajištění takového nastavení jednotlivých prostředí, aby výsledky testů byly srovnatelné. Pevný disk je v dnešní době asi nejslabší článek výkonu celého počítače. Výkon procesorů a pamětí se zrychluje obrovským tempem, ale rychlost úložišť toto tempo nedokázalo udržet. i běžný uživatel dobře pozná, že počítač nereaguje tak, jak by si přál a vliv na to má především rychlost pevného disku, ze kterého jsou načítána data do paměti operačního systému. Výrobci pamětí situaci začali měnit k lepšímu od roku 2007, kdy byla představena první SSD16 PCIe karta s kapacitou až 320 GB a rychlostí 100000 vstupně/výstupních operací za sekundu (IOPS). i oproti těm nejrychlejším rotačním diskům té doby to bylo zrychlení v několika řádech, dokonce tato rychlost překonávala i výkonná disková pole. Cenově však tyto karty byly na svou kapacitu velmi drahé a navíc byly velmi limitované v počtu přepisů jednotlivých buněk (tranzistorů) uvnitř flash pamětí. v roce 2009 se pak již objevily 2,5“ SSD disky s rozhraním SATA, jak je známe dnes. Jejich rychlost nebyla tak oslnivá, ale cenově již byly dostupné širší veřejnosti. Podnikové prostředí nezůstalo pozadu a v SSD technologii vidělo velkou budoucnost. v roce 2008 společnost EMC poprvé použila pro SSD disky označení EFD (Enterprise flash drives), které označuje disky určené do podnikového prostředí – vyšší rychlost a především spolehlivost. Dlouhou dobu pak byly SSD disky používány v diskových polích jako cache, tedy část kapacity s velmi rychlým zápisem, kam se zapisovala data, které pak systém diskového pole ve volných chvílích přesouval na část kapacity s klasickými rotačními disky, kde byla většina úložné kapacity diskového pole. Od roku 2013 se začínají objevovat disková pole složená pouze ze SSD disků. Tento trend jen ukazuje na fakt, že rychlost úložišť je stále pozadu za výpočetní silou počítačů a i přes stále výrazně vyšší jednotkovou cenu za jednotku kapacity jsou zákazníci ochotni pořizovat rychlá SSD úložiště.[11] U virtualizace je vzhledem ke konsolidaci mnoha serverů na jedno úložiště situace citelnější. Veškeré soubory virtuálních počítačů jsou obsaženy ve virtuálním pevném disku, který je reprezentován jedním nebo několika soubory v úložišti. Obsah tohoto souboru se virtuálnímu 16

SSD – Solid State Drive – jedná se o disk bez pohyblivých částí založen na technologii flash pamětí, tedy paměti stálé, která udržuje informaci i bez přívodu napájení a je přepisovatelná.

32

serveru jeví jako fyzický pevný disk. Na stejném úložišti však jsou i další soubory, které používá hypervizor ke správě virtuálního serveru a tím, který by mohl nejvíce testování ovlivnit je swapovací soubor. Operační systém virtuálního serveru má vlastní swap soubor uvnitř virtuálního disku, stejně jako fyzický server na disku fyzickém. Hypervizor má však pro každý virtuální server další vlastní swap soubor pro případ, že by mu došly hardwarové zdroje17. Tento swapový soubor pro účely testování přemístím na úložiště k vlastnímu hypervizoru, aby jeho případný vliv negativně neovlivnil testování virtuálních prostředí (vzhledem k velikosti operační paměti fyzického serveru by k tomu mohlo dojít u testování Hyper-V). Hlavním nástrojem pro testování rychlosti pevného disku bude HD Tune Pro 5.6. Tento software je opět jednoduchý, nepotřebuje instalaci a zabírá 2 MB diskového prostoru. Kromě zobrazení detailních informací o pevných discích, jako jsou funkce obsažené v pevném disku, doba provozu, počet spouštěcích cyklů a informací ze S.M.A.R.T. logu disku, dokáže skenovat povrch disku s detekcí chybných sektorů a pro tuto práci nejpodstatnější měření rychlosti pevného disku spolu s přístupovou dobou. u rotačních disků je toto měření prováděno postupně od vnější stopy disku směrem je středu a ze zobrazeného grafu je pak jasně patrné, jak rychlost disku od vnější stopy směrem ke středu otáčení klesá, zatím co přístupová doba je u okraje disku nejnižší a směrem ke středu stoupá. v případě testování SSD disků je přístupová doba až na malé odchylky prakticky konstantní, stejně tak rychlost disku samotného, jenž zaznamenává jisté výkyvy způsobené požadavky na disk z operačního systému – pokud je testován disk, na kterém je operační systém instalován. Pro test rychlosti je možné v nástroji konfigurovat velikost bloku od 512 bajtů do 8 MB po krocích dvojnásobku předchozího (512 bajtu, 1 kB, 2 kB, atd.). Testování budu provádět na třech velikostech bloku (4 kB, 512 kB, 4 MB), protože rozdíly ve výsledných rychlostech budou značně odlišné a pro celkové porovnání by mohly být přínosem. Velké bloky neznamenají tolik požadavků na disk a výkon disku se pak jeví vyšší. Výchozí velikost alokační jednotky NTFS souborového systému ve Windows, v kterém bude testování probíhat, je 4 kB. Testování rychlosti disku je prováděno čtením i zápisem. Samotný software je komerční a za jeho užívání je potřeba uhradit licenční poplatek, který aktuálně činí USD $34.95. Pro vlastní 17

Virtuální server má například přiděleny 2 GB paměti, běžně využívá pouze 1 GB a hypervizor přerozdělí veškerou volnou paměť jiným virtuálním serverům. Paměť, na rozdíl od CPU, lze na hypervizoru overalokovat, tedy přidělit virtuálním serverům více paměti, než má hypervizor k dispozici. Pokud pak takový virtuální server potřebuje více paměti a hypervizor nemá žádnou k dispozici, musí jí hypervizor přidělit z vlastního swap souboru a pro virtuální operační systém toto maskovat. Hypervizory mají sice ještě další techniky, které nastupují před vlastním swapem, ale v nejhorších případech může dojít i na něj.

33

testování opět využiji 15 denní zkušební lhůtu. Pro osobní užití je volně k dispozici lehčí verze produktu HD Tune 2.55, která u testování rychlosti disku provádí pouze test čtením a neobsahuje mnoho pokročilých funkcí. Obě verze jsou k dispozici z internetových stránek výrobce (dostupné z http://www.hdtune.com).

Obrázek 9 – HD Tune 2.55 (zdroj: vlastní)

Druhým nástrojem pro testování rychlosti disku bude opět PassMark Performance Test. Testování bude probíhat stejně jako v případě HD Tune, jen bude rozděleno na fáze sekvenčního čtení/zápisu a náhodného čtení/zápisu. Druhou metodou pak bude specifický pokročilý test obou disků v operačním systému.

1.5.4 Testování výkonu síťové vrstvy Testování síťové vrstvy budu testovat pouze nástrojem PassMark Performance Test, jelikož se jedná o zhodnocení hrubé přenosové kapacity síťové karty. PassMark nabízí velmi pohodlně konfigurovatelný testovací nástroj s přehledným výstupem, vhodným ke srovnání. Je v něm velmi snadné nadefinovat shodné podmínky pro všechna uskutečněná měření. Nástroj bude spuštěn jak v testovaném operačním systému virtuálního nebo fyzického serveru, tak ještě na druhém počítači v síti. Tyto dvě instance softwaru si budou data posílat mezi sebou. Mezi testovaným serverem a párovým počítačem bude pouze jeden aktivní síťový prvek (switch). Testy provedu jak pro protokol TCP, tak i pro protokol UDP, nicméně pouze v rámci IPv4.

34

Obrázek 10 – PassMark Advanced Network Test (zdroj: vlastní)

V rámci tohoto testování však jako doplňující test provedu testování rychlosti síťové komunikace mezi dvěma virtuálními servery v rámci jednoho virtuálního switche na jednom hypervizoru. Tento test nebudu zařazovat do hodnocení výsledků při komparaci různých prostředí, ale zařadím ho pro ověření deklarované vyšší rychlosti komunikace mezi virtuálními servery v rámci jednoho hosta. Tato rychlost bude velmi závislá na rychlosti fyzického procesoru hypervizoru a bude znamenat jeho režii. Absolutní číslo přenosové rychlosti, které z testování vyplyne, bude platit pouze pro testovaný systém a není možné ho pokládat za obecně maximální. Důvodem tohoto testu je zjištění zvýšení efektivity síťové komunikace mezi dvěma servery jejich zvirtualizováním a umístěním na jednoho hosta. Případů, kdy je taková architektura žádoucí, je v praxi mnoho. Typicky víceúrovňová

35

architektura aplikace využívající front-end server pro komunikaci s uživateli a back-end server, který spravuje data, je kvůli bezpečnosti dat takto budována běžně.

1.5.5 Testování výkonu aplikací Aplikace jako software využívají komplexně veškeré zdroje počítače, tedy CPU, operační paměť RAM, úložiště a mnohdy i síťovou vrstvu, kterou však v tomto testu nebudu uvažovat. Základem naprosté většiny aplikací je nějaký typ databáze spravovaný SŘBD, tedy systémem řízení báze dat. Samotný SŘBD umí velice dobře vytížit veškeré zdroje počítače. Moje testování této oblasti tedy bude spočívat ve vytížení SŘBD Microsoft SQL Server 2012. Na serveru umístím rozsáhlejší databázi obsahující několik miliónů záznamů. Sestavením složitějšího SELECT-u, který bude vypisovat výběr dat z dostupných záznamů, navíc pomocí spojení pěti tabulek pomocí funkce JOIN, budu testovat dobu, za kterou server tento příkaz vykoná. To je hodnota, kterou testem budu vyhodnocovat. Velikost databáze na datovém úložišti je zhruba 1 GB a SŘBD tedy bude schopno větší část databáze umístit do operační paměti. Měření tedy provedu dvakrát, jednou pro databázi neobsaženou v paměti, podruhé pro databázi načtenou. v prvním případě před každým měřením restartuji Windows službu „SQL Server (MSSQLSERVER)“, čímž se databáze z paměti uvolní. Skript, kterým budu testování provádět je následující: SELECT a.SMS_ID AS ID, a.ARCHIVE_ID, a.DIRECTION, a.MSG_SENT, a.MSG_INSERTED, a.PRIORITY_TYPE, p.DESCRIPTION AS PRIORITY_TYPENAME, a.MESSAGE_TYPE, m.DESCRIPTION AS MESSAGE_TYPENAME, a.GW_TYPE AS GATEWAY_TYPE, g.GW_NAME AS GATEWAY_TYPENAME, a.FROM_NAME, a.FROM_NUMBER, a.LINE_ALLOW_REROUTE, a.DISPLAY_ONLY, a.REPLY_REQUIRED, a.NOMODIFY, a.MAIL_IN_DRREQUIRED, a.FINAL_STATUS, a.PARTS_SENT, a.MAIL_IN_INFOMAIL_REQUIRED, a.SMS_SEND_DRREQUIRED, a.SMS_SEND_INFOMAIL_REQUIRED, a.USER_APP_ID, a.SENDERSYSTEM, a.SUBJECT, a.MESSAGE, a.MESSAGE_MMS, a.PDU, a.SCHEDULE, a.EXPIRATION, a.FIX_DR, a.FIX_NDR, a.FIX_INFOMAIL, a.OPERATOR_ID, o.DESCRIPTION AS OPERATOR_NAME, a.FROM_SMTP, a.USER_UGROUP AS USER_GROUP, a.TO_PHONE_NR_STD, a.FROM_EMAIL, a.CALENDAR_NAME FROM dbo.MX_ARCHIVE AS a LEFT OUTER JOIN dbo.MX_MESSAGE_TYPE AS m ON a.MESSAGE_TYPE = m.MESSAGE_TYPE LEFT OUTER JOIN dbo.MX_GATEWAY AS g ON a.GW_TYPE = g.GW_TYPE LEFT OUTER JOIN dbo.MX_PRIORITY AS p ON a.PRIORITY_TYPE = p.PRIORITY_TYPE LEFT OUTER JOIN dbo.MX_OPERATOR AS o ON a.OPERATOR_ID = o.OPERATOR_ID

36

2 Výkonové testy Ve vlastním porovnání budu pracovat s hypervizory VMware ESXi server 5.5.0 Update 2 a Hyper-V z edice Microsoft Windows Server 2012 R2. i přes to, že aktuální dostupnou verzi VMware ESXi serveru je verze 6.0, mnou zvolené verze obou testovaných platforem jsou z vývojového hlediska srovnatelné a použitím aktuálně vydané verze ESXi serveru bych mohl ovlivnit výsledky v neprospěch hypervizoru Hyper-V od společnosti Microsoft, který další významný update ještě nevydal. Diskový prostor je rozdělen následovně. Na diskové skupině 0 složené v RAID1 jsou vytvořeny následující virtuální disky LUN0, LUN1, LUN2 (v dalším textu budou disky vždy identifikovány označením LUNx18). Disková skupina 1 složená v RAID0 obsahuje pouze jeden fyzický disk, který je operačním systémům prezentován jako LUN3. Disková skupina 2 složená v RAID5 je rozdělena na virtuální disky LUN4, LUN5 a LUN6. Následující tabulka 4 přehledně shrnuje rozdělené úložiště a využití jednotlivých disků. Označení

Velikost

Prostředí

Účel

Disková skupina

LUN0

92,77 GiB Fyzické

OS

Skupina 0 (RAID1)

LUN1

92,77 GiB Hyper-V

Virtuální OS

Skupina 0 (RAID1)

LUN2

93,33 GiB VMware

Virtuální OS

Skupina 0 (RAID1)

LUN3

74,80 GiB Hyper-V

Hypervizor

Skupina 1 (RAID0)

LUN4

463,87 GiB Fyzické

Databáze

Skupina 2 (RAID5)

LUN5

463,87 GiB Hyper-V

Databáze

Skupina 2 (RAID5)

LUN6

468,52 GiB VMware

Databáze

Skupina 2 (RAID5)

Tabulka 4 – Přehled použitých diskových oddílů (zdroj: vlastní)

V tabulce, u velikosti pevných disků, je z konfigurace raidového řadiče serveru správně použita jednotka GiB. V počítačové terminologii se již řadu let nesprávně používají předpony násobků SI soustavy pro jednotku byte u deklarace kapacity úložišť. Místo násobků tisíců se u dané jednotky jedná ve skutečnosti o násobky hodnoty 1024, které vycházejí z principů dvojkové soustavy a tedy hodnotě 210. Tento princip je založen na binární technologii adresování operační paměti počítače (například 16-ti bitový registr může adresovat 216 tj. 64x1024 neboli 64 kilo paměťových buněk). Z počátku bylo toto označování myšleno jako 18

LUN – Logical Unit Number, je běžně používané označování virtuálních disků diskových polí, sloužící k identifikaci virtuálního disku v systému, do kterého se disk připojuje.

37

zaokrouhlování, později se však stalo nepsaným pravidlem. Se značně rostoucí kapacitou pevných disků a nečestným marketingem některých výrobců však takovéto značení začalo působit velké problémy spotřebitelům. Z toho důvodu Mezinárodní elektrotechnická komise (International Electrotechnical Commission, IEC) doporučuje vydáním mezinárodního standardu IEC 60027-2 používat pro mocniny čísla 2 blízké hodnotám SI soustavy nové předpony, které mají zkratku násobku rozšířeny o znak „i“. Jejich vlastní názvy vychází ze zkráceniny prvních dvou písmen slovního spojení označení násobků SI soustavy a přídomku „Binary“ a běžně používané binární násobky by měly být správně pojmenovávané jako: kibi, mebi, gibi, tebi, pebi. Norma IEC byla s platností od 1. dubna 2004 přejata do systému českých technických norem pod číslem ČSN IEC 60027-2. Někteří výrobci pevných disků již začali, kvůli četným stížnostem zákazníků, že jejich disky nemají deklarovanou kapacitu, velikost svých disků značit správně. Pro příklad, u pevného disku o správně zapsané velikosti 300 GiB je jeho reálně zobrazená velikost v jednotkách GB, se kterými pracuje operační systém, pouhých 279 GB.[9] Jednotlivá prostředí ještě v následujících podkapitolách konkrétně popíši, včetně postupu jejich tvorby. Důvodem je ukázání všech možných detailů, které mohou následující výkonové testy ovlivnit. Ty by pak měly objasnit možné nejasnosti ve volbě konkrétních prostředí, a s tím i důvody, proč byla zvolena jejich právě použitá konfigurace. Ve výsledku jsou pak z pohledu operačního systému testovaných serverů všechna tři prostředí prakticky totožná, což je zřetelně patrné z následujících obrázků pořízených ze záložky „výkon“ ve správce úloh každého z operačních systémů.

Obrázek 11 – Detail fyzického prostředí z OS (zdroj: vlastní)

38

Obrázek 12 – Detail Hyper-V prostředí z OS (zdroj: vlastní)

Obrázek 13 – Detail ESXi prostředí z OS (zdroj: vlastní)

2.1.1 Fyzické prostředí Fyzická konfigurace serveru použitého pro testy fyzického prostředí je zredukována o jedno CPU a o polovinu paměťových modulů a obsahuje tedy pouze jeden fyzický procesor Intel® XEON® E5345 se čtyřmi jádry o taktu 2,327 GHz na každém jádru. Čtyři kusy paměťových modulů DDR2 ECC o taktu 667 MHz a kapacitě 512 MB a celkové kapacitě 2048 MB. Těmito parametry pak přesně odpovídá nastavení virtuálních serverů v prostředích Hyper-V a VMware. Instalovaným operačním systémem je Microsoft Windows 2012 R2 x64 (build X19-53588). Instalována je verze Standard v anglickém jazyce, v lokalizaci pro ČR. Instalace operačního systému je provedena na diskový oddíl LUN0, přičemž vytvoření logických oddílů a jejich formátování je ponecháno na instalátoru. Ten vytvoří primární oddíl o velikosti 300 MB pro potřeby samotného OS a zbytek prostoru zaplní druhým primárním oddílem, ze kterého se 39

stane systémový disk C:. Formátováno obou oddílů je do souborového systému NTFS s výchozí velikostí alokační jednotky a formátování rychlé. Po dokončení instalačního průvodce je pak v samotném operačním systému přidána funkce .NET Framework 3.5, která je nutná k instalaci a provozování serveru Microsoft SQL Server 2012 ve verzi Standard. Pevným diskem pro umístění databáze je oddíl LUN4, na kterém je vytvořen primární oddíl formátovaný souborovým systémem NTFS (plnohodnotné formátování, nikoliv rychlý formát) s velikostí alokační jednotky ponechané ve výchozím nastavení, což v případě OS Windows znamená 4kB. v konfiguraci síťových adaptérů je zakázán adaptér odpovídající portu 1 (ve virtuálních serverech se vyskytovat nebude), síťovému adaptéru pro port 0 je nastavena IP adresa 192.168.96.147, maska sítě 255.255.255.0, výchozí brána 192.168.96.1, primární server DNS 192.168.1.25 a sekundární server DNS 192.168.1.27. Protokol IPv6 je na síťovém adaptéru zakázán. Tato konfigurace odpovídá prostředí, ve kterém je server umístěn, aby bylo možné provést výše popsaný test propustnosti sítě mezi testovaným serverem a druhým serverem v síti. v konfiguraci komponenty Windows Update jsem nastavil volbu „nikdy nevyhledávat aktualizace“, a to kvůli jejímu nahodilému spouštění a možnému nepravidelnému a nepředvídatelnému ovlivnění výkonových testů. Po čisté instalaci se v systému další komponenty s tímto chováním nenacházejí (např. Windows search, Windows defender) a vlastní operační systém tímto pokládám za připravený. Dalším krokem přípravy prostředí je instalace databázového serveru Microsoft SQL 2012 Standard. Z instalačního média je pomocí instalačního průvodce nainstalován nový stand-alone SQL server. Pro instalaci jsou vybrány pouze role jádra databázového serveru a nástroje pro správu, přičemž cíl instalace je systémový disk operačního systému. Disk pro databázi je určen výhradně pro umístění databázového souboru a souboru s transakčními logy. v konfiguraci samotného databázového stroje jsem neprováděl žádné optimalizační úpravy, vše je ponecháno ve výchozím nastavení. Databázové prostředí po dokončení instalace pokládám za připravené.

2.1.2 Hyper-V prostředí Instalace prostředí Hyper-V je provedena z instalačního obrazu operačního systému Microsoft Windows 2012 R2 x64 (build X19-53588). Cílem instalace je virtuální disk LUN3. Instalována je verze Standard a v samotném operačním systému je pak přidána role Hyper-V a funkce .NET Framework 3.5 a Telnet client. Operačnímu systému jsou dále přidány disky LUN1 a LUN5, z nichž první je určen pro úložiště virtuálních serverů a druhý jako prostor pro databázi MS SQL. Pro komunikaci samotného hypervizoru na síti jsem vyčlenil síťový 40

port 1 a nakonfiguroval mu IP adresu 192.168.96.148/24 s ostatními parametry shodnými s konfigurací fyzického prostředí. Opět jsem na síťové kartě zakázal protokol IPv6. V konfiguraci role Hyper-V jsem vytvořil virtuální switch (přepínač), který je nastaven jako externí, tedy umožňuje komunikaci i mimo fyzický server hypervizoru (další možnosti jsou interní, který umožňuje komunikaci mezi v něm připojenými virtuálními servery a hypervizorem, a privátní, který umožňuje komunikaci pouze mezi v něm připojenými virtuálními servery). Jako uplink port jsem nakonfiguroval síťový port 0. Uplink port slouží virtuálnímu přepínači ke komunikaci s vnější fyzickou sítí. Dále jsem vytvořil jeden virtuální server generace 2, kterému jsem přiřadil čtyři procesory (odpovídá jednomu čtyř-jádrovému procesoru) a 2 GB operační paměti (přesně 2048 MB). Dále jsem virtuálnímu serveru vytvořil virtuální disk o kapacitě 92 GB, který je na hypervizoru fyzicky reprezentován jedním souborem s příponou „.vhdx“ na úložišti disku LUN1. Nakonec jsem virtuální server jedním virtuálním síťovým adaptérem připojil k dříve vytvořenému virtuálnímu přepínači. Zbývá nakonfigurovat druhý pevný disk pro umístění databáze, ale tento krok provedu až po instalaci operačního systému virtuálního serveru. Instalace operačního systému virtuálního serveru a databázového serveru MS SQL je totožná s instalací operačního systému ve fyzickém prostředí, jež je popsáno v kapitole 2.1.1. Po přípravě operačního systému jsem virtuální server vypnul a v jeho konfiguraci přidal druhý virtuální disk pro umístění databáze. Opět ho na úrovní hypervizoru reprezentuje soubor s příponou „.vhdx“, který jsem umístil na úložiště LUN5. Virtuální disk má kapacitu 463 GB a je v režimu „fixed size“ (celá jeho kapacita je předem alokována). Tento režim je ve virtuálním prostředí pro umístění databázových souborů výrobci doporučován z důvodu nejvyšší možné výkonosti, protože je virtuální disk v tomto režimu technologicky nejblíže disku fyzickému. Formátování tohoto disku je provedeno stejně jako ve všech předchozích prostředích plnohodnotné. Samotná instalace a konfigurace MS SQL serveru je totožná s instalací na fyzickém prostředí v kapitole 2.1.1.

2.1.3 VMware prostředí Instalace VMware ESXi serveru 5.5.0 Update 2 je provedena z instalačního obrazu modifikovaného společností Dell. Modifikace spočívá v integrování vlastních hardwarových ovladačů do instalačního obrazu pro plnou podporu celého portfolia serverů Dell, včetně všech podporovaných přídavných karet (typicky přídavné síťové karty a HBA adaptéry).

41

Cílem instalace hypervizoru VMware ESXi je USB 2.0 flash disk o velikosti 4 GB, ze kterého bude hypervizor vždy zaváděn. Instalátor automaticky USB disk rozdělí na pět diskových oddílů o velikostech 4 MB, 250 MB, 250 MB, 110 MB a 286 MB. Na blogu vInfrastructure velice přehledně strukturu popisuje Andrea Mauro. První diskový oddíl o velikosti 4 MB je systémová partition. Druhý a třetí oddíl o velikostech 250 MB jsou nativní linux oddíly obsahující banku zaváděcích, respektive alternativních zaváděcích souborů hypervizoru. Čtvrtý oddíl o velikosti 110 MB je určen pro diagnostická data hypervizoru a poslední pátý oddíl je opět nativní linux oddíl určen jako úložiště hypervizoru. Pokud velikosti diskových oddílů sečteme, dostaneme 900 MB, což je minimum pro instalaci hypervizoru ESXi a flash disk o velikosti 1 GB by byl pro tento účel naprosto vyhovující. Andrea Mauro dále ve svém popisu pokračuje dvěma dalšími oddíly, které jsou při instalaci ESXi serveru na cílovém disku vytvořeny, nicméně ne nevyhnutelně, a v mnou připraveném prostředí, kvůli použitému flash disku, tak vytvořeny nejsou. Šestým oddílem by byl nativní linux oddíl o velikosti 4 GB, který by se vytvořil v případě, že by flash disk měl kapacitu alespoň 8 GB, a byl by určen jako doplňkové úložiště pro hypervizor (například pro umístění logů). Poslední, sedmý oddíl se vytváří pouze v případě, že cílovým diskem není disk typu flash a jednalo by se VMFS úložiště o velikosti zbylé kapacity cílového disku. To pak slouží jako úložiště hypervizoru dostupné pro správce a lze na něj umisťovat virtuální servery, šablony virtuálních serverů apod. [4] Po instalaci hypervizoru jsem nastavil síťový adaptér pro správu, kterým se stal síťový port 1, na němž jsem zakázal IP adresaci verze 6 a nastavil IP adresu 192.168.96.149/24 pro vzdálené připojení aplikací vSphere Client (ostatní parametry síťové konfigurace jsou opět shodné s fyzickým prostředím). v konzoli hypervizoru se ještě běžně nastavuje heslo, pojmenovává server, případně povoluje přístup přes SSH. Pro účely mého testování však tyto nastavení provádět nemusím a další konfigurační kroky tedy budu provádět ze vzdálené správy. Prvním krokem po připojení se pomocí aplikace vSphere Client je nastavení úložišť. Přidal jsem oddíly LUN2, který jsem v hypervizoru pojmenoval OS, a LUN6, pojmenovaný Database, a oběma nastavil jako souborový systém novější verzi nativního VMware souborového systému VMFS5. Dále jsem vytvořil nový virtuální switch vSwitch1, ke kterému budu připojovat pouze testovaný virtuální server, a tomuto přepínači jsem přiřadil jako uplink síťový port 0. Poslední změnou v konfiguraci je změna fyzické cesty pro umístění 42

logů ESXi serveru. Vzhledem k již zmíněnému použití flash disku o velikosti pouhé 2 GB pro instalaci serveru ESXi nebyl vytvořen šestý oddíl o velikosti 4 GB, na který je ve výchozím stavu vytváření logů směrováno. Tím jsem dokončil nejnutnější konfiguraci hypervizoru ESXi a pokládám jeho instalaci za připravenou. Dále vytvořím virtuální stroj, na který bude nainstalován testovací server. Soubory tohoto virtuálního stroje jsou umístěny na úložišti OS. Virtuální stroj je vytvořen s verzí hardwaru 8. Serveru je přiřazen jeden fyzický procesor o čtyřech jádrech, nicméně se jedná pouze o architekturu, kterou uvidí operační systém virtuálního serveru a nejedná se o fyzické přiřazení jednoho ze dvou fyzických procesorů v hypervizoru. Server dále dostal k dispozici 2 GB operační paměti a síťovou kartu VMXNET3, zapojenou do virtuálního switche vSwitch1. Ovladač virtuálních disků je ponechán ve výchozím nastavení, tedy adaptér LSI Logic SAS. Virtuální disk je vytvořen o kapacitě 90 GB a je ve formátu19 Thin Provision, fyzicky tedy soubor virtuálního disku zabírá na datovém úložišti pouze tolik kapacity, kolik obsahuje fyzicky dat. s rostoucím obsahem dat roste také soubor virtuálního disku na úložišti. u systémových disků virtuálních serverů jsem toto nastavení použil proto, že je to běžně využívaná konfigurace v produkčním prostředí, a také bude možné porovnat i vliv takto nastavených virtuálních disků. Po vytvoření virtuálního serveru jsem pak v jeho nastavení přidal druhý virtuální disk o velikosti 460 GB pro databázi, který jsem umístil na úložiště Database a nastavil formát Thick Provision Eager Zeroed. Tento formát vytvoří soubor virtuálního disku zabírajícího jeho plnou kapacitu, a navíc jsou všechny jeho sektory přepsány na 0. Při ukládání dat jsou přepisovány pouze ty bity, které mají obsahovat 1 a je tím zajištěna nejvyšší možná výkonnost. Jedná se o ekvivalent virtuálního disku pro databáze použitého u hypervizoru Hyper-V (fixed size, plnohodnotné formátování). Do vytvořeného virtuálního serveru jsem nainstaloval operační systém Windows Server 2012 R2 Standard, a to podle shodného postupu, jako v případě serveru fyzického. Po dokončení instalace operačního systému a provedení konfiguračních úprav jsem do něho nainstaloval podpůrné nástroje „VMware Tools“, které virtuálnímu serveru poskytnou optimalizované ovladače pro běh v prostředí ESXi hypervizoru. Jedná se o obdobu nástrojů společnosti Microsoft v případě hypervizoru Hyper-V, kde jsou nazývány „Integrační komponenty“. Dále jsem připravil pevný disk pro databázi, opět přesně podle postupu popsaného výše u přípravy fyzického serveru, a nainstaloval databázový server Microsoft SQL Server 2012 Standard, 19

Anglický výraz je Provisioning, který se v komunitě nepřekládá. Pro lepší čtivost jsem však použil český výraz „formát“, který je také přípustný, nicméně se s ním v tomto kontextu prakticky nesetkáte.

43

rovněž dle shodného postupu. Prostředí v hypervizoru VMware ESXi tímto pokládám za připravené, a vše je tedy připraveno na provedení výkonových testů.

2.2 Paměť Všechna testovaná prostředí mají přiděleny 2 GB operační paměti, což jsem dokázal pohledy do vlastností jednotlivých operačních systémů všech testovaných prostředí, konkrétně obrázky na straně 38.

2.2.1 Fyzické prostředí Výsledky testů na fyzickém prostředí budu pokládat za referenční, záznam všech výsledků měření je v příloze 1. Testování zahajuji nástrojem MaxxMEM2, jehož deset měření jsem zpřehlednil v tabulce 5. 1

2

3

4

5

6

7

8

9

10

Průměr

4700

4704

4696,1

3756

3757

3755,3

4599

4609

4610,5

4,18

4,18

4,184

91,2

91,4

91,31

Memory Copy – kopírování (MB/s) 4700

4693

4689

4700

4693

4700

4689

4693

Memory Read – čtení (MB/s) 3754

3755

3756

3758

3756

3756

3750

3755

Memory Write – zápis (MB/s) 4602

4611

4614

4619

4614

4607

4614

4616

Memory Score – dosažené skóre (GB/s) 4,18

4,18

4,19

4,19

4,19

4,18

4,18

4,19

Memory Latency – latence (ns) 91,4

91,4

91,3

91,3

91,2

91,3

91,3

91,3

Tabulka 5 – MaxxMEM2 výsledky fyzické prostředí (zdroj: vlastní)

Následuje deset měření v testovacím nástroji PassMark Performance test 8. Jejich výsledky obsahuje tabulka 6.

1

2

3

4

5

6

7

8

9

10

Průměr

600

600

596

599

601

599

598,6

Memory Mark (celková známka) 591

600

600

600

Memory – Database Operations – databázové operace (tisíce operací za sekundu) 24,3

26,2

26,4

26,1

26,0

26,1

44

26,2

26,2

26,3

26,0

25,98

Memory – Read Cached – čtení kešované (megabajty přenesené za sekundu) 11380 11397+ 11384 11393 11401 11393 11386 11392 11392 11394

11391,2

Memory – Read Uncached – čtení nekešované (megabajty přenesené za sekundu) 4322

4320

4306

4322

4304

4327

4307

4327

4294

4254

4308,3

1742

1742

1737,1

1074

1075

1064,3

53,5

53,5

53,53

3231

3233

3231,8

Memory – Write – zápis (megabajty přenesené za sekundu) 1741

1742

1743

1741

1742

1742

1693

1743

Memory – Available RAM – dostupná paměť (v megabajtech) 1036

1068

1068

1069

1069

1070

1057

1057

Memory – Latency – latence (v nanosekundách, méně je lépe) 53,6

53,5

53,6

53,5

53,5

53,5

53,5

53,6

Memory – Threaded – (megabajty přenesené za sekundu) 3232

3232

3231

3232

3231

3232

3232

3232

Tabulka 6 – PassMark Memory výsledky fyzické prostředí (zdroj: vlastní)

Výsledky paměťových měření ve fyzickém prostředí pokládám za uspokojivé a postoupím tedy k měření v prostředích virtuálních.

2.2.2 Hyper-V V prostředí Hyper-V jsem začal testování operační paměti opět nástrojem MaxxMEM2. Jeho výsledky jsem zapsal do tabulky 7. 1

2

3

4

5

6

7

8

9

10

Průměr

4129

4062

4158

4093

4139

4143

4117,4

3915

3908

3910

3921

3910

3904

3900,4

3379

3379

3378

3377

3382

3378

3374,4

3,64

3,64

3,65

3,65

3,64

3,637

98,9

99,3

99,3

99,5

99,5

99,23

Memory Copy – kopírování (MB/s) 4118

4100

4139

4093

Memory Read – čtení (MB/s) 3905

3860

3858

3913

Memory Write – zápis (MB/s) 3371

3349

3367

3384

Memory Score – dosažené skóre (GB/s) 3,64

3,60

3,61

3,65

3,65

Memory Latency – latence (ns) 99,2

99,0

99,4

99,2

99,0

Tabulka 7 – MaxxMEM2 výsledky Hyper-V (zdroj: vlastní)

Výsledky MaxxMEM2 testu jsou konzistentní a následují tedy testy provedené nástrojem PassMark Performance test. Jejich výsledky obsahuje tabulka 8.

45

1

2

3

4

5

6

7

8

9

10

Průměr

547

548

554

552

553

553,2

Memory Mark (celková známka) 545

560

557

559

557

Memory – Database Operations – databázové operace (tisíce operací za sekundu) 12,7

13,8

13,6

14,0

13,7

13,0

13,3

14,1

13,8

13,57

13,7

Memory – Read Cached – čtení kešované (megabajty přenesené za sekundu) 11305 11273 11305 11290 11267 11252 11284 11306 11303 11249

11283,4

Memory – Read Uncached – čtení nekešované (megabajty přenesené za sekundu) 3298

3302

3280

3309

3224

3300

3303

3274

3312

3302

3290,4

1554

1581

1613,4

1097

1094,8

57,8

57,7

57,78

5567

5559

5563,6

Memory – Write – zápis (megabajty přenesené za sekundu) 1597

1682

1674

1634

1709

1601

1555

1547

Memory – Available RAM – dostupná paměť (v megabajtech) 1099

1096

1097

1096

1080

1095

1096

1097

1095

Memory – Latency – latence (v nanosekundách, méně je lépe) 57,8

57,9

57,7

57,9

57,7

57,9

57,7

57,7

Memory – Threaded – (megabajty přenesené za sekundu) 5575

5568

5570

5585

5510

5566

5563

5573

Tabulka 8 – PassMark Memory výsledky Hyper-V (zdroj: vlastní)

Rozptyl výsledků jednotlivých měření je pro mě akceptovatelný a testování paměti v prostředí Hyper-V považuji za ukončené. Záznamy všech měření jsou obsaženy v příloze 2.

2.2.3 VMware Testovací nástroj MaxxMEM 2 - test mi bohužel ve virtuálním serveru v prostředí hypervizoru ESXi nefungoval korektně, a výsledky jeho měření tedy nebudu v celkovém vyhodnocení zohledňovat do výsledného porovnání všech prostředí. Provedu pouze dílčí porovnání fyzického prostředí a hypervizoru Hyper-V. V testech paměti testovacího nástroje PassMark je v prostředí VMware zobrazeno pouze 1024 MB paměti, operační systém má však přiděleny celé 2 GB operační paměti. Obrázek 14 toto tvrzení dokazuje. Z celkové paměti operačního systému je 938 MB použito, volné paměti je k dispozici 1,1 GB, a testovací nástroj PassMark vidí v operačním systému celé 2 GB. Zobrazený údaj o velikosti paměti ve výsledkové tabulce PassMark testu budu ignorovat.

46

Obrázek 14 – Paměť v OS hypervizoru ESXi a v nástroji PassMark (zdroj: vlastní)

Testovacím nástrojem PassMark jsem provedl deset po sobě jdoucích měření výkonu paměti a jejich výsledky jsem zapsal opět do přehledné tabulky 9. 1

2

3

4

5

6

7

8

9

10

Průměr

473,1

438,2

441,5

433,9

469,5

443,94

Memory Mark (celková známka) 384,5

416,7

439,6

500

442,4

Memory – Database Operations – databázové operace (tisíce operací za sekundu) 5,7

7,8

8,7

9,4

7,2

8,8

7,5

7,6

7,4

8,2

7,83

Memory – Read Cached – čtení kešované (megabajty přenesené za sekundu) 10944 11130 11231 11182 11126 11224 11142 11079 11157 11146

11136,1

Memory – Read Uncached – čtení nekešované (megabajty přenesené za sekundu) 2949

2085

1878

2973

2768

2733

2457

2506

2373

2656

2537,8

1576

1689

1523,3

1120

1116

72,4

61,1

71,26

5355

5476

5439,2

Memory – Write – zápis (megabajty přenesené za sekundu) 1257

1240

1559

1838

1486

1538

1532

1518

Memory – Available RAM – dostupná paměť (v megabajtech) 1120

1126

1119

1123

1124

1120

1104

1101

1103

Memory – Latency – latence (v nanosekundách, méně je lépe) 93,3

77,1

70,3

67,1

66,9

67,1

69,1

68,2

Memory – Threaded – (megabajty přenesené za sekundu) 5452

5498

5299

5498

5571

5584

5292

5367

Tabulka 9 – PassMark Memory výsledky VMware (zdroj: vlastní)

47

Ani v tomto případě nebudu provádět další měření, neboť výsledky pokládám za dostatečně průkazné. Záznamy všech měření jsou obsaženy v příloze 3.

2.3 Procesor Ve všech třech testovaných prostředích je v testovacím nástroji CPU identifikováno naprosto shodně, tedy jeden fyzický CPU se čtyřmi jádry a dalšími vlastnostmi odpovídajícími skutečně typu použitého fyzického procesoru. Obě virtuální prostředí skutečně poskytují virtuálním serverům přístup na fyzický procesor a jejich prací je v tomto případě omezování jeho využití a přerozdělování procesorového času. Následující testy by měly ukázat, jak efektivně si při této práci vedou.

2.3.1 Fyzické prostředí Testy provedené na fyzickém prostředí budu opět pokládat za referenční. První test výkonu CPU na fyzickém prostředí provedu v nástroji CPU Free BenchMark 2. Výsledky testovacích měření obsahuje tabulka 10.

Score

1

2

3

4

5

6

7

8

9

10

Průměr

29,28

29,90

29,90

29,85

29,82

29,72

29,80

29,79

29,27

29,79

29,712

Tabulka 10 – CPU Free Bench Mark 2.2 výsledky fyzické prostředí (zdroj: vlastní)

Následuje test v nástroji PassMark Performance Test 8, jehož hodnoty z jednotlivých měření jsou v tabulce 11. 1

2

3

4

5

6

7

8

9

10

Průměr

3217

3212

3202

3188

3216

3181

3201,1

CPU Mark (celková známka) 3200

3211

3176

3208

CPU – Integer Math – celočíselné výpočty (miliony operací za sekundu) 5190

5189

5190

5191

5191

5191

5190

5191

5189

5190

5190,2

CPU – Floating Point Math – výpočty desetinné (miliony operací za sekundu) 3029

3028

3028

3029

3028

3028

3029

3029

3029

3029

3028,6

8,3

8,85

8,5

8,5

5324

5321,9

CPU – Prime Numbers – prvočísla (miliony prvočísel za sekundu) 8,9

9,1

8,4

9,1

9,1

9,1

8,9

8,5

9,1

CPU – Extended Instructions (SSE) (miliony matic za sekundu) 8,5

8,5

8,5

8,5

8,5

8,5

8,5

8,5

8,5

CPU – Compression – komprese (kilobajty zpracované za sekundu) 5308

5324

5322

5324

5324

5324

5323

48

5323

5323

CPU – Encryption – šifrování (megabajty přenesené za sekundu) 663

663

663

663

663

662

663

663

663

662,9

191,7

193,7

193,9

193,0

2989

3020

3018

2989,2

663

CPU – Physics – výpočty fyziky (snímků za sekundu) 193,3

191,7

192,6

192,9

193,2

194,9

192,1

CPU – Sorting – třídění (tisíce řetězců za sekundu) 2963

3002

2945

2968

3018

2987

2982

CPU – Single Threaded – jednovláknové výpočty (miliony operací za sekundu) 938

938

938

937

938

937

938

938

938

938

937,8

Tabulka 11 – PassMark CPU výsledky fyzické prostředí (zdroj: vlastní)

Výsledky jsou bez výrazných rozptylů a další měření provádět nebudu. Záznamy všech měření jsou obsaženy v příloze 4.

2.3.2 Hyper-V Testování procesoru virtuálního serveru na platformě Hyper-V jsem započal nástrojem CPU Free BenchMark 2.2, jehož výsledky obsahuje tabulka 12.

Score

1

2

3

4

5

6

7

8

9

10

Průměr

29,80

29,84

30,02

30,10

30,22

30,03

30,05

29,88

30,04

30.06

30,058

Tabulka 12 – CPU Free Bench Mark 2.2 výsledky Hyper-V (zdroj: vlastní)

Výsledné hodnoty deseti měření jsou konzistentní a přejdu tak na testování nástrojem PassMark Performance Test. Jeho výsledky jsou zapsány v tabulce 13. 1

2

3

4

5

6

7

8

9

10

Průměr

3424

3318

3420

3314

3341

3378

3383

CPU Mark (celková známka) 3362

3432

3430

3411

CPU – Integer Math – celočíselné výpočty (miliony operací za sekundu) 4965

4995

4994

4995

4964

4973

4988

4998

4993

4994

4985,9

CPU – Floating Point Math – výpočty desetinné (miliony operací za sekundu) 2640

2697

2699

2696

2701

2696

2681

2661

2687

2697

2685,5

15,1

16,92

8,4

8,38

5298

5205,8

CPU – Prime Numbers – prvočísla (miliony prvočísel za sekundu) 16,7

19,0

18,9

17,5

19,0

15,4

18,9

12,4

16,3

CPU – Extended Instructions (SSE) (miliony matic za sekundu) 8,4

8,4

8,4

8,4

8,4

8,4

8,3

8,3

8,4

CPU – Compression – komprese (kilobajty zpracované za sekundu) 5293

5291

5295

5290

5294

4425

5290

49

5295

5287

CPU – Encryption – šifrování (megabajty přenesené za sekundu) 649

658

658

658

659

656

657

649

658

656

253,5

230,2

253,6

249,58

3013

2850

3019

3000,6

658

CPU – Physics – výpočty fyziky (snímků za sekundu) 237,9

253,1

254,1

252,9

255,5

252,3

252,7

CPU – Sorting – třídění (tisíce řetězců za sekundu) 3017

3027

3009

3006

3018

3023

3024

CPU – Single Threaded – jednovláknové výpočty (miliony operací za sekundu) 880

890

893

890

882

891

889

891

890

890

888,6

Tabulka 13 – PassMark CPU výsledky Hyper-V (zdroj: vlastní)

I zde jsou jednotlivá měření bez výrazných rozptylů a testování procesoru proto na této platformě pokládám za ukončené. Záznamy všech měření jsou obsaženy v příloze 5.

2.3.3 VMware Prvním z provedených testů na platformě ESXi je opět test nástrojem CPU Free BenchMark 2.2. Výsledky z deseti po sobě jdoucích měření shrnuje následující tabulka 14.

Score

1

2

3

4

5

6

7

8

9

10

Průměr

30,26

30,22

30,25

30,19

30,22

30,18

30,34

30,23

30,18

30.28

30,235

Tabulka 14 – CPU Free Bench Mark 2.2 výsledky VMware (zdroj: vlastní)

Výsledky měření nástroje CPU Free Bench Mark 2.2 mají ve VMware prostředí velmi malý rozptyl, a proto považuji deset provedených měření za měření dostatečně průkazná. Druhým nástrojem pro otestování výkonu procesoru je PassMark Performance Test 8.0. v konfiguraci testovacího nástroje je po kontrole výchozího stavu správně nastaveno využití čtyř vláken pro test procesoru. Provedl jsem opět postupně deset měření, jejichž výsledky shrnuje tabulka 15.

1

2

3

4

5

6

7

8

9

10

Průměr

3256

3310

3119

3315

3322

3243

3260,2

CPU Mark (celková známka) 3184

3260

3263

3330

CPU – Integer Math – celočíselné výpočty (miliony operací za sekundu) 4893

4817

4830

4908

4891

4907

4887

4899

4908

4909

4884,9

CPU – Floating Point Math – výpočty desetinné (miliony operací za sekundu) 2564

2513

2524

2564

2586

2568

2565

50

2565

2566

2558

2557,3

CPU – Prime Numbers – prvočísla (miliony prvočísel za sekundu) 14,1

17,3

17,2

17,7

14,1

17,7

9,3

16,8

13,9

15,57

8,3

8,31

5144

5203,2

17,6

CPU – Extended Instructions (SSE) (miliony matic za sekundu) 8,3

8,2

8,2

8,3

8,4

8,4

8,3

8,4

8,3

CPU – Compression – komprese (kilobajty zpracované za sekundu) 5209

5171

5160

5256

5202

5247

5178

5203

5262

CPU – Encryption – šifrování (megabajty přenesené za sekundu) 652

641

641

654

642

653

651

652

651

648,9

227,4

223,7

215,2

214,95

2972

2976

2969

2956,8

652

CPU – Physics – výpočty fyziky (snímků za sekundu) 177,3

218,1

220,4

227,3

215,0

214,7

210,4

CPU – Sorting – třídění (tisíce řetězců za sekundu) 2971

2883

2896

2972

2962

2977

2990

CPU – Single Threaded – jednovláknové výpočty (miliony operací za sekundu) 866

858

856

866

871

860

861

865

866

861

863

Tabulka 15 – PassMark CPU výsledky VMware (zdroj: vlastní)

Výsledky i v tomto případě byly poměrně konzistentní, a tak i v tomto případě považuji deset provedených měření za měření dostatečně průkazná. Záznamy všech měření jsou obsaženy v příloze 6.

2.4 Diskové úložiště Před samotným testováním výkonu diskových úložišť pokládám za potřebné upřesnit detail, který by komparativnost mnou připravených prostředí mohl degradovat. Rozdělení diskových skupin RAIDů na jednotlivé virtuální disky použité pro jednotlivá testovaná prostředí, může mít vliv na rozdílné výkony. Disk je fyzicky na jednotlivé virtuální disky rozdělen po stopách, a tak je jeden z virtuálních disků umístěn fyzicky více u středu otáčení, druhý uprostřed, a třetí na prstenci u vnějšího okraje diskových ploten. Virtuální disk umístěný u vnějšího okraje je tak teoreticky umístěn na nejideálnějším místě pro jeho nejlepší výkonnost. Abych tento předpoklad ověřil, provedu ještě testování rychlosti jednotlivých virtuálních disků z prostředí operačního systému s hypervizorem Hyper-V, který je fyzicky umístěn na disku, který testováním podroben není, a který všechny testované virtuální disky vidí a dokáže je připojit. Po ukončení všech ostatních testů provedu vyčištění diskových oddílů na všech šesti virtuálních discích diskových skupin, a vytvořím oddíly čitelné z operačního systému hypervizoru Hyper-V. Na všech vytvořených oddílech pak provedu stejnou sadu testů rychlosti disků a vyhodnotím celkem dva výsledky pro dvě diskové skupiny (RAID1 51

a RAID5). Ze získaných výsledků vyjdou opravné koeficienty, kterými budu korigovat výsledky diskových testů jednotlivých prostředí. Tím budou všechny testy diskových úložišť postaveny na stejnou základní úroveň a jejich vyhodnocení bude relevantní. Testovacím nástrojem HD Tune Pro 5.60 jsem na disku C: provedl 3 sady testů s různou velikostí bloků (4 kB, 512 kB, 4 MB). Různé velikosti bloku jsem zvolil tak, že 4 kB jsou výchozí hodnotou velikosti alokační tabulky pro NTFS souborový systém ve Windows, přičemž bloky o větších kapacitách mají umožnit testovacímu nástroji dostat se na samou hranici možností přenosové kapacity fyzického disku, což bude patrné i ze získaných výsledků. Na disku D: jsem provedl pouze jednu sadu testu s velikostí bloku 64 kB, což je výchozí velikost bloku testovacího nástroje. Testování je na discích operačního systému prováděno pouze na čtení, neboť testování zápisu vyžaduje čistý disk bez diskových oddílů. U obou hypervizorů výsledky testů z nástroje HD Tune ukazují, jak hypervizor pracuje s dynamicky rostoucím diskem. Ze všech průběhů testů je patrné, že v prvních zhruba 18 GB diskového prostoru (prostor obsazen operačním systémem) je rychlost prakticky konstantní a pohybuje se kolem výsledného rychlostního minima. Následně vyskočí strmě nahoru, a to do takových hodnot, které jsou zcela mimo fyzické možnosti použitých disků v rozdílu řádů. Obdobně se to pak jeví u výsledků průměrné doby přístupu. Výsledné hodnoty odpovídají spíše diskům SSD a z grafů průběhu je zřejmé, jak několik málo žlutých bodů reprezentujících jednu naměřenou hodnotu přístupové doby leží v prostoru mezi čtyřmi a jedenácti milisekundami, a naprostá většina bodů je seskupena do úsečky těsně nad osou grafu. Příčinou takto zmatených výsledků je fakt, že hypervizor testovacímu nástroji předává z operační paměti reálně neexistující sektory virtuálního disku z prostoru, který není fyzicky na úložišti umístěn. Testy pro disk C: ve virtuálních serverech budu proto všechny opakovat a kvůli porovnatelnosti výsledků bude v testovacím nástroji nastaven limit na 8 GB (původní výsledky přiložím pouze do příloh). v tomto rozmezí jsou všechny provedené testy v oblasti reálných možností fyzického disku. Z tohoto testu budu v plné kapacitě hodnotit pouze výsledky disku D:, které odpovídají jeho fyzickým možnostem. Jeho soubor virtuálního disku je, jak jsem popisoval u přípravy testovacích prostředí, alokován v celé své kapacitě. Pro testování v prostředí PassMark Performance Test jsem se rozhodl použít kromě klasického testu pevných disků i funkci Advanced Disk test, protože ten umožňuje nastavení specifického testu nezávisle pro oba v operačním systému použité disky. Do testu jsem přidal dvě testovací vlákna, jedno pro systémový disk C:, kterému jsem nastavil konfiguraci typu

52

„Workstation“ a druhý pro databázový disk D:, kterému jsem přiřadil konfiguraci „Database“ s nastavenou délkou fronty „IO Queue Length“ na hodnotu 128. Přístupové metody pro obě vlákna jsou nastaveny na volbě „Standard Win32 API (Uncached)“. Doba jednoho testovacího běhu je ponechána na výchozí hodnotě 60 sekund. Oba testy provedené tímto testovacím nástrojem testují, na rozdíl od nástroje HD Tune Pro, pro čtení i zápis.

2.4.1 Fyzické prostředí Testy diskového úložiště na fyzickém prostředí budu pokládat za referenční. Prvním testovacím nástrojem je HD Tune Pro. Kvůli problémům s výsledky testu na disku C: v obou hypervizorech, jsem byl pro zachování komparativnosti hodnot měřit i na fyzickém prostředí pouze prvních 8 GB diskového oddílu. Výsledky měření obsahuje tabulka 16. Disk

Blok

1

2

3

4

5

6

7

8

9

10

Průměr

Transfer Rate – Minimum (minimální přenosová rychlost) – MB/s C:

4 kB

30,3

30,5

28,0

26,9

26,6

31,7

25,8

26,3

27,2

27,8

28,11

C:

512 kB

34,4

177,7

120,5

119,3

174,0

180,9

34,4

34,4

34,4

34,4

94,44

C:

4 MB

177,9

184,0

38,3

38,3

38,1

38,2

179,7

38,3

186,5

177,8

109,71

D:

64 kB

109,1

115,7

118,3

116,8

117,6

112,9

115,7

106,1

115,5

120,5

114,82

Transfer Rate – Maximum (maximální přenosová rychlost) – MB/s C:

4 kB

34,5

34,6

34,6

34,7

34,7

34,7

34,7

34,7

34,7

34,7

34,66

C:

512 kB

198,9

198,8

198,5

198,6

198,8

198,9

198,7

198,5

198,5

198,7

198,69

C:

4 MB

208,2

207,6

207,3

207,4

207,2

207,6

207,4

208,2

207,8

207,8

207,65

D:

64 kB

161,5

162,5

162,4

162,1

161,9

162,4

162,5

161,7

162,4

162,2

162,16

Transfer Rate – Average (průměrná přenosová rychlost) – MB/s C:

4 kB

34,2

34,3

32,9

33,3

31,6

34,3

29,6

30,3

33,5

32,2

32,62

C:

512 kB

153,3

194,1

176,7

172,1

194,1

194,3

147,8

155,2

157,3

149,0

169,39

C:

4 MB

197,1

197,2

196,2

195,9

196,3

196,2

197,3

196,1

196,8

196,9

196,6

D:

64 kB

124,8

149,9

149,9

149,9

149,8

145,1

149,7

149,6

149,8

153,5

147,2

Access Time (přístupová doba) – ms C:

4 kB

3,20

3,23

3,18

3,12

3,20

3,18

3,10

3,15

3,12

3,16

3,164

C:

512 kB

3,21

3,24

3,18

3,15

3,22

3,18

3,17

3,17

3,18

3,14

3,184

C:

4 MB

3,12

3,21

3,22

3,21

3,17

3,15

3,17

3,19

3,23

3,24

3,191

D:

64 kB

4,17

4,08

3,99

4,09

4,06

4,04

4,02

4,05

4,05

4,04

4,059

53

Burst Rate (rychlost rozhraní) – MB/s C:

4 kB

131,9

131,2

132,4

145,7

138,4

145,6

145,8

145,2

145,2

145,1

140,65

C:

512 kB

131,5

132,0

132,4

131,8

131,2

145,8

145,4

145,6

144,9

146,1

138,67

C:

4 MB

145,0

132,5

131,7

131,9

131,3

145,7

131,2

145,9

144,9

132,3

137,24

D:

64 kB

132,0

132,1

131,2

131,7

131,5

131,5

131,8

132,1

132,4

146,4

133,27

CPU Usage (využití procesoru) – % C:

4 kB

6,5

6,2

5,9

6,4

5,8

6,0

5,2

5,3

6,1

5,9

5,93

C:

512 kB

1,3

0,7

0,5

0,6

0,8

0,7

0,6

0,5

0,5

1,1

0,73

C:

4 MB

0,8

0,7

0,7

0,6

0,8

0,6

0,8

0,6

0,7

0,6

0,69

D:

64 kB

2,0

1,5

1,7

1,8

2,1

1,5

1,7

1,7

2,4

2,7

1,91

Tabulka 16 – HDTune HDD test fyzické prostředí (zdroj: vlastní)

Následují měření v nástroji PassMark Performance Test 8. Prvním je standardní diskový test a výsledky jsou obsaženy v tabulce 17. Disk

1

2

3

4

5

6

7

8

9

10

Průměr

Disk Mark (celková známka) C:

1076

1121

1120

1050

1176

1111

1085

1053

1119

1120

1103,1

D:

611

621

614

584

615

592

598

618

563

624

604,0

Disk – Sequential Read – sekvenční čtení (megabajty přenesené za sekundu) C:

161,3

166,4

166,4

145,2

183,2

165,3

152,6

152,5

175,5

171,0

163,94

D:

151,4

151,7

151,9

143,2

150,6

142,4

147,3

150,3

136,1

150,9

147,58

Disk – Sequential Write – sekvenční zápis (megabajty přenesené za sekundu) C:

111,2

118,2

118,0

119,8

117,1

117,2

122,2

113,4

108,4

113,3

115,88

D:

10,6

12,8

10,6

11,7

12,1

13,8

10,8

13,6

12,6

14,5

12,31

Disk – Random Seek + RW – náhodné čtení a přepis (megabajty přenesené za sekundu) C:

25,1

25,3

25,3

25,3

25,0

24,6

25,2

25,4

25,6

25,4

25,22

D:

7,0

7,3

7,3

6,7

7,5

7,3

7,3

6,8

7,1

7,3

7,16

Tabulka 17 – PassMark HDD test fyzické prostředí (zdroj: vlastní)

Druhý test je rozšířený test a výsledky shrnuje tabulka 18.

54

Disk

1

2

3

4

5

6

7

8

9

10

Průměr

Rychlost disku (MB/s) C:

4,11

4,12

4,13

4,12

4,13

4,13

4,14

4,13

4,12

4,14

4,127

D:

1,06

1,06

1,02

1,02

1,01

1,06

1,03

1,06

1,04

1,06

1,042

Tabulka 18 – PassMark Advanced HDD test fyzické prostředí (zdroj: vlastní)

Výsledky všech diskových testů na fyzickém prostředí jsou konzistentní, a proto deset provedených pokusů pokládám za dostatečné. Záznamy všech měření jsou obsaženy v příloze 7.

2.4.2 Hyper-V Testy výkonu pevného disku zahájím opět nástrojem HD Tune Pro. Jak jsem zmínil v úvodu kapitoly 2.4, testy na disku C: jsem byl nucen opakovat kvůli nekorektním výsledkům způsobených jeho formátem. v tabulce 19 uvádím pouze výsledky druhého měření, kde byl omezen test na prvních 8 GB kapacity.

Disk

Blok

1

2

3

4

5

6

7

8

9

10

Průměr

Transfer Rate – Minimum (minimální přenosová rychlost) – MB/s C:

4 kB

15,6

16,5

14,6

15,0

15,7

13,9

15,7

12,9

15,9

15,5

15,13

C:

512 kB

116,2

116,2

90,0

110,1

116,2

116,2

107,0

112,9

105,9

116,2

110,69

C:

4 MB

162,0

162,1

159,5

158,8

155,2

148,1

142,5

151,3

161,3

169,4

157,02

D:

64 kB

50,2

66,5

69,7

68,3

70,9

66,9

70,0

73,2

72,1

69,7

67,75

Transfer Rate – Maximum (maximální přenosová rychlost) – MB/s C:

4 kB

67,7

69,7

47,6

47,6

68,9

47,7

69,3

68,9

69,3

47,6

60,43

C:

512 kB

964,1

1048,0

977,8

1013,8

879,0

835,9

886,9

1027,2

1256,3

1005,3

989,43

C:

4 MB

815,0

928,9

833,4

847,8

868,2

899,5

861,7

865,4

818,9

911,4

865,02

D:

64 kB

101,1

100,8

101,0

100,2

99,7

101,4

100,9

99,5

99,6

100,4

100,46

Transfer Rate – Average (průměrná přenosová rychlost) – MB/s C:

4 kB

19,2

19,4

18,6

18,7

19,0

18,8

19,1

18,5

19,5

18,7

18,95

C:

512 kB

189,8

190,6

189,7

192,3

188,6

187,4

188,7

192,1

192,5

190,0

190,17

C:

4 MB

194,0

200,9

194,6

194,5

195,6

200,5

195,6

194,9

194,3

201,5

196,64

D:

64 kB

88,8

89,0

88,6

88,6

88,4

89,1

89,1

88,7

88,9

88,8

88,80

55

Access Time (přístupová doba) – ms C:

4 kB

3,27

3,29

3,20

3,40

3,29

3,35

3,31

3,24

3,32

3,31

3,298

C:

512 kB

3,30

3,30

3,27

3,26

3,26

3,28

3,27

3,28

3,28

3,27

3,277

C:

4 MB

3,32

3,39

3,34

3,29

3,32

3,33

3,30

3,36

3,35

3,30

3,330

D:

64 kB

10,4

10,2

10,1

10,7

10,0

10,1

10,1

10,1

10,2

10,2

10,21

Burst Rate (rychlost rozhraní) – MB/s C:

4 kB

105,5

108,1

105,3

107,0

107,1

109,2

106,9

108,1

106,3

106,5

107,00

C:

512 kB

106,6

108,0

105,1

108,5

103,7

108,9

103,8

108,0

106,1

108,2

106,69

C:

4 MB

115,6

119,3

117,5

104,4

118,0

115,0

118,3

105,5

116,1

105,7

113,54

D:

64 kB

131,2

131,6

135,2

129,3

131,1

133,9

134,2

135,7

135,5

127,0

132,47

CPU Usage (využití procesoru) – % C:

4 kB

3,2

3,1

3,2

3,4

3,2

3,1

3,1

3,7

3,2

3,1

3,23

C:

512 kB

1,8

1,4

1,8

1,1

1,6

1,7

1,3

0,9

1,3

1,4

1,43

C:

4 MB

1,3

1,6

1,1

1,2

1,2

0,8

1,3

2,5

1,0

0,8

1,28

D:

64 kB

1,5

1,4

1,4

2,0

1,5

1,4

1,5

1,6

1,4

2,0

1,57

Tabulka 19 – HDTune HDD test Hyper-V (zdroj: vlastní)

Maximální rychlost u disku C: nemá smysl hodnotit, protože v tomto případě představuje dvě výrazné odchylky, které, jak je patrno z grafu průběhu měření, se objevují pravidelně ve dvou místech průběhu měření. Jedná se o prostor disku, který neobsahuje reálná data, a tak naměřená rychlost neodpovídá rychlosti fyzického disku, na který se měřením zaměřuji. Na průměrnou rychlost nemají prakticky vliv, a proto ostatní hodnoty tohoto testu budu v celkovém hodnocení zohledňovat. Dalším provedeným měřením je standardní test v PassMark Performance Test 8, jehož hodnoty obsahuje tabulka 20. Po něm bude následovat ještě kombinovaný rozšířený test a jeho výsledky jsou obsaženy v tabulce 21. Disk

1

2

3

4

5

6

7

8

9

10

Průměr

Disk Mark (celková známka) C:

1003

997

989

1011

965

997

980

1016

992

1026

997,6

D:

572

574

567

579

577

582

582

577

583

557

575,0

Disk – Sequential Read – sekvenční čtení (megabajty přenesené za sekundu) C:

139,2

141,3

139,9

141,4

130,4

139,6

137,3

141,7

140,4

147,4

139,86

D:

136,2

137,9

136,2

137,9

137,8

139,9

138,8

139,1

139,2

133,0

137,60

56

Disk – Sequential Write – sekvenční zápis (megabajty přenesené za sekundu) C:

112,8

109,5

108,4

113,4

111,0

110,0

109,2

113,9

108,0

110,6

110,68

D:

14,8

13,8

13,5

15,2

14,8

14,1

15,2

13,5

15,0

14,1

14,40

Disk – Random Seek + RW – náhodné čtení a přepis (megabajty přenesené za sekundu) C:

25,2

25,0

25,1

24,8

25,4

26,1

24,6

25,3

26,0

25,6

25,31

D:

7,1

7,0

7,0

7,1

7,0

7,0

7,0

7,0

7,0

7,0

7,02

Tabulka 20 – PassMark HDD test Hyper-V (zdroj: vlastní)

Disk

1

2

3

4

5

6

7

8

9

10

Průměr

Rychlost disku (MB/s) C:

4,27

4,02

4,05

4,23

4,31

4,24

4,20

4,32

4,25

4,25

4,214

D:

1,04

1,01

1,03

1,02

1,01

1,02

1,00

1,02

1,02

1,02

1,019

Tabulka 21 – PassMark Advanced HDD test Hyper-V (zdroj: vlastní)

Obě měření jsou bez výraznějších odchylek, a proto pokládám měření výkonu pevného disku v prostředí Hyper-V za uzavřené. Záznamy všech měření jsou obsaženy v příloze 8.

2.4.3 VMware Po instalaci testovacího nástroje HD Tune Pro 5.60 v prostředí virtuálního serveru jsem provedl naplánované testy. u disku C: jsem také musel provést všechny testy znovu, a to ze stejného důvodu jako u druhého hypervizoru. Výsledky nově provedených testů shrnuje tabulka 22.

Disk

Blok

1

2

3

4

5

6

7

8

9

10

Průměr

Transfer Rate – Minimum (minimální přenosová rychlost) – MB/s C:

4 kB

12,6

13,0

12,7

12,7

10,2

12,5

12,1

12,4

12,7

12,6

12,35

C:

512 kB

65,0

63,5

64,2

66,1

59,3

65,1

62,9

64,4

64,1

67,0

64,16

C:

4 MB

91,2

97,7

96,0

97,0

91,4

90,2

90,2

93,0

99,9

95,3

94,19

D:

64 kB

71,2

67,0

66,6

67,9

68,1

67,9

69,8

62,7

67,1

62,6

67,09

Transfer Rate – Maximum (maximální přenosová rychlost) – MB/s C:

4 kB

34,2

59,4

62,2

62,3

62,8

62,4

64,5

60,6

48,8

37,5

55,47

C:

512 kB

1718,8

1621,9

1742,5

1948,3

1911,6

1699,4

1762,9

1354,6

1696,5

1544,3

1700,08

C:

4 MB

1695,1

1751,1

1745,7

1659,6

1672,7

1743,2

1734,3

1609,1

1676,6

1764,8

1705,22

D:

64 kB

102,0

106,0

101,3

103,8

102,0

102,7

102,9

104,4

103,6

103,3

103,20

57

Transfer Rate – Average (průměrná přenosová rychlost) – MB/s C:

4B

15,0

15,4

15,1

15,3

15,9

15,6

15,1

15,3

14,9

15,6

15,32

C:

512 kB

112,6

110,4

111,2

111,9

115,5

110,5

111,1

108,8

110,9

111,0

111,39

C:

4 MB

151,3

151,6

150,5

147,3

148,5

149,0

150,8

151,0

150,4

149,0

149,94

D:

64 kB

89,5

90,0

90,1

89,9

89,8

90,1

90,1

90,2

89,9

90,3

89,99

Access Time (přístupová doba) – ms C:

4 kB

3,42

3,34

3,50

3,26

3,29

3,35

3,38

3,41

3,61

3,30

3,386

C:

512 kB

3,27

3,27

3,28

3,30

3,31

3,27

3,30

3,33

3,28

3,25

3,286

C:

4 MB

3,28

3,41

3,37

3,26

3,43

3,27

3,29

3,38

3,55

3,34

3,358

D:

64 kB

12,7

10,9

10,8

11,0

11,1

11,0

11,1

10,9

11,0

10,9

11,140

Burst Rate (rychlost rozhraní) – MB/s C:

4 kB

115,0

111,8

116,3

104,0

103,1

109,8

111,0

113,4

114,2

101,5

110,01

C:

512 kB

101,0

102,7

103,1

111,9

101,3

103,1

103,9

103,3

104,4

101,4

103,61

C:

4 MB

101,6

111,5

104,3

103,1

110,2

101,9

102,8

113,1

110,4

110,1

106,90

D:

64 kB

125,2

122,7

123,7

126,2

124,2

123,9

124,3

124,3

124,6

126,3

124,54

CPU Usage (využití procesoru) – % C:

4 kB

6,8

6,6

6,6

6,2

7,6

6,5

6,3

6,5

6,4

6,9

6,64

C:

512 kB

2,4

1,2

1,3

1,2

1,4

1,1

2,3

1,3

1,5

1,0

1,47

C:

4 MB

1,2

2,5

1,2

1,0

1,2

1,1

1,4

1,3

1,1

2,8

1,48

D:

64 kB

2,4

2,8

2,8

2,7

2,3

2,7

2,7

2,6

2,4

2,6

2,60

Tabulka 22 – HDTune HDD test VMware (zdroj: vlastní)

Opět zde nebudu hodnotit maximální rychlost, neboť i zde jsou v průběhu měření stejné dvě výrazné odchylky, které váhu tohoto parametru degradují. Doplňující testy provedené nástrojem PassMark Performance Test obsahuje tabulka 23 a výsledky Advanced disk testu tabulka 24. Disk

1

2

3

4

5

6

7

8

9

10

Průměr

Disk Mark (celková známka) C:

897

894

908

869

888

883

911

908

913

894

896,5

D:

323,0

324,1

324,2

320,6

316,1

321,2

322,8

323,6

322,5

322,9

322,1

Disk – Sequential Read – sekvenční čtení (megabajty přenesené za sekundu) C:

134,8

135,6

138,4

129,0

134,1

134,9

139,1

138,4

138,3

135,0

135,76

D:

77,3

77,3

77,4

76,8

75,2

76,8

77,3

77,5

77,3

77,0

76,99

58

Disk – Sequential Write – sekvenční zápis (megabajty přenesené za sekundu) C:

88,7

86,9

89,0

86,8

86,9

84,3

87,5

87,4

88,8

87,5

87,38

D:

5,6

5,9

5,9

5,4

5,7

5,5

5,5

5,6

5,4

5,8

5,63

Disk – Random Seek + RW – náhodné čtení a přepis (megabajty přenesené za sekundu) C:

24,5

24,7

23,7

24,6

24,7

25,0

25,2

25,2

25,3

24,6

24,75

D:

6,4

6,4

6,4

6,4

6,5

6,5

6,5

6,4

6,5

6,5

6,45

Tabulka 23 – PassMark HDD test VMware (zdroj: vlastní)

Disk

1

2

3

4

5

6

7

8

9

10

Průměr

Rychlost disku (MB/s) C:

4,00

3,98

3,97

4,01

4,00

3,99

4,00

3,96

3,98

4,01

3,990

D:

0,86

0,88

0,87

0,87

0,88

0,88

0,86

0,88

0,88

0,88

0,874

Tabulka 24 – PassMark Advanced HDD test VMware (zdroj: vlastní)

Výsledky byly v obou testovacích nástrojích a na všech testech s malými odchylkami dosaženy a proto jsem další testy k upřesnění výsledků provádět nemusel. Záznamy všech měření jsou obsaženy v příloze 9.

2.4.4 Korekční test Korekční test rychlosti pevných disků na diskových oddílech, které byly testovány v různých prostředích, jsem provedl z operačního systému hypervizoru Hyper-V. Důvodem je umístění tohoto operačního systému na jiném pevném disku, než jsou ty testované. Odstranil jsem všechny testované oddíly a vytvořil na nich oddíly nové, všechny formátované souborovým systémem NTFS a plným formátem. Provedl jsem testy pouze nástroji HD Tune Pro a standardní

test

v PassMark

Performance

Test,

přičemž

jsem

zredukoval

počet

vyhodnocovaných parametrů. Počet testovacích běhů jsem také zredukoval na 3 pro každý oddíl. Výsledky měření z nástroje HD Tune Pro jsou zapsány v tabulce 25. Oba disky jsem v tomto případě testoval při nastavené standardní velikosti bloku na 64 kB. Fyzické prostředí Disk

1

2

3

Hyper-V P

1

2

3

VMware P

1

2

3

P

Transfer Rate – Average (průměrná přenosová rychlost) – MB/s C:

123,3

123,3

123,3

123,3

111,1

111,1

111,1

111,1

100,1

100,1

100,1

100,1

D:

116,6

116,6

116,6

116,6

116,1

116,1

116,2

116,1

99,3

99,3

99,2

99,3

59

Access Time (přístupová doba) – ms C:

4,57

4,56

4,52

4,55

4,52

4,52

4,52

4,52

4,20

4,19

4,22

4,20

D:

9,90

10,1

9,93

9,98

10,1

10,4

10,1

10,20

10,5

11,0

10,8

10,77

Tabulka 25 – Korekční test HD Tune (zdroj: vlastní)

Měření v nástroji PassMark Performance Test 8 při použití standardního disk testu jsou obsažena v tabulce 26. Fyzické prostředí Disk

1

2

3

Hyper-V P

1

2

3

VMware P

1

2

3

P

Disk Mark (celková známka) C:

953

969

1173

1032

1065

967

1002

1011

952

818

980

917

D:

616

610

603

610

580

585

564

576

500

496,8

495,8

498

Disk – Sequential Read – sekvenční čtení (megabajty přenesené za sekundu) C:

131,7

132,4

185,9

150,0

157,5

129,8

138,0

141,8

144,0

105,2

151,0

133,4

D:

151,3

146,6

146,9

148,3

140,1

140,0

136,4

138,8

118,7

118,2

119,5

118,8

Disk – Sequential Write – sekvenční zápis (megabajty přenesené za sekundu) C:

115,9

119,5

121,9

119,1

113,3

113,5

115,0

113,9

95,5

95,7

96,1

95,8

D:

11,8

14,9

12,7

13,1

13,1

14,6

12,3

13,3

12,6

12,2

10,6

11,8

Disk – Random Seek + RW – náhodné čtení a přepis (megabajty přenesené za sekundu) C:

16,1

16,1

16,5

16,2

23,7

24,1

23,9

23,9

23,7

25,3

24,0

24,3

D:

7,2

7,2

7,1

7,2

7,2

7,2

7,2

7,2

7,0

7,0

6,9

7,0

Tabulka 26 – Korekční test PassMark (zdroj: vlastní)

Posledním korekčním testem pevných disků, advanced disk test provedený opět nástrojem PassMark, obsahuje tabulka 27. Fyzické prostředí Disk

1

2

Hyper-V

VMware

3

P

1

2

3

P

1

2

3

P

Rychlost disku (MB/s) C:

4,21

4,20

4,22

4,21

4,19

4,22

4,20

4,20

4,35

4,38

4,38

4,37

D:

1,04

1,06

1,05

1,05

0,97

0,96

0,97

0,97

1,00

1,00

1,01

1,00

Tabulka 27 – Korekční test PassMark Advanced (zdroj: vlastní)

Z podílu výsledných průměrů naměřených hodnot vzniknou korekční koeficienty, které budu v kapitole 3.3 používat při vyhodnocování výsledků. Záznamy všech měření jsou obsaženy v příloze 10. 60

2.5 Síťová vrstva Testy síťové propustnosti budou prováděny pouze nástrojem PassMark Performance Test 8. Protistranou nutnou k provedení tohoto testu bude pro všechna testovací prostředí fyzický server Dell, který má nainstalován čistý operační systém Microsoft Windows Server 2012. Služby využívající síťové rozhraní jsou v tomto operačním systému omezeny na nezbytné minimum, aby neovlivňovaly testy prováděné. Síťové karty obou serverů, stejně tak i síťový přepínač, který je mezi servery umístěn, podporují přenosovou rychlost 1 Gb/s. Jednotlivé testovací přenosy protokolů TCP i UDP mají nastaven čas datového přenosu na 20 sekund a pevnou velikost bloku 16384 Bytů.

2.5.1 Fyzické prostředí Testy fyzického prostředí jsou opět ve výsledcích pokládány za testy referenční. Výsledky deseti měření pro protokoly TCP a UDP obsahuje tabulka 28. Vytížení procesoru u těchto testů bylo kolem 6% pro protokol TCP a kolem 9% pro protokol UDP, jak ilustrují obrázky 15 a 16. Operační systém bez běžícího testu odebíral 0-2% procesorového času, a to ve všech třech prostředích, proto nebudu dále tento fakt zmiňovat.

Obrázek 15 – PassMark TCP síťový test ¨na fyzickém prostředí (zdroj: vlastní)

Obrázek 16 – PassMark UDP síťový test na fyzickém prostředí (zdroj: vlastní)

61

1

2

3

4

5

6

7

8

9

10

Průměr

Average Speed – průměrná rychlost (megabity za sekundu) TCP

905,5

905,7

905,7

905,7

905,7

905,7

905,7

905,7

905,7

905,7

905,68

UDP

696,1

711,0

726,7

685,9

667,8

729,7

725,8

720,6

726,2

719,0

710,88

Tabulka 28 – PassMark síťový test fyzické prostředí (zdroj: vlastní)

Výsledky měření jsou akceptovatelné a nebudu tedy přidávat další sadu testů. Záznamy všech měření jsou obsaženy v příloze 11.

2.5.2 Hyper-V Stejnou sadu testů jsem provedl v prostředí hypervizoru Hyper-V. Přehledně jsou seskupeny v tabulce 29. Vytížení procesoru u těchto testů bylo kolem 4% pro protokol TCP a kolem 7% pro protokol UDP, jak ilustrují obrázky 17 a 18.

Obrázek 17 – PassMark TCP síťový test Hyper-V (zdroj: vlastní)

Obrázek 18 – PassMark UDP síťový test Hyper-V (zdroj: vlastní)

1

2

3

4

5

6

7

8

9

10

Průměr

Average Speed – průměrná rychlost (megabity za sekundu) TCP

905,0

905,3

905,4

905,1

905,4

905,6

905,5

905,6

905,4

905,1

905,34

UDP

425,4

317,3

315,8

319,9

407,5

314,4

319,9

316,1

306,2

314,5

335,7

Tabulka 29 – PassMark síťový test Hyper-V (zdroj: vlastní)

Výsledky jsou pro všechna měření protokolu TCP prakticky shodná. Protokol UDP má z deseti měření jen dva výrazné odskoky a vzhledem k nestabilitě přenosu tohoto protokolu

62

jako takového, nebudu další měření provádět. Záznamy všech měření jsou obsaženy v příloze 12.

2.5.3 VMware Výsledky měření síťové rychlosti v prostředí VMware jsou obsaženy v tabulce 30. Vytížení procesoru u těchto testů bylo kolem 16% pro protokol TCP a kolem 6% pro protokol UDP, což je ilustrováno obrázky 19 a 20.

Obrázek 19 – PassMark TCP síťový test VMware (zdroj: vlastní)

Obrázek 20 – PassMart UDP síťový test VMware (zdroj: vlastní)

1

2

3

4

5

6

7

8

9

10

Průměr

Average Speed – průměrná rychlost (megabity za sekundu) TCP

905,3

904,8

905,7

904,0

904,3

903,5

905,7

905,4

905,6

903,5

904,78

UDP

369,0

368,5

337,6

387,0

372,9

344,6

371,8

385,4

365,0

373,4

367,52

Tabulka 30 – PassMark síťový test VMware (zdroj: vlastní)

Výsledky i v tomto případě pokládám za dostatečné, a další testování nebude potřeba. Záznamy všech měření jsou obsaženy v příloze 13.

2.6 Aplikace – MS SQL Jak jsem již popsal v části 1.5.5, testování SQL budu provádět a vyhodnocovat ve dvou krocích. Nejprve budu hodnotit dobu provedení definovaného skriptu bez načtené databáze v paměti. Toto zajistím restartem služby SQL serveru a důkazem toho, že se jím systém vrátí z pohledu stavu databáze do čistého stavu, jsou následující hodnoty obsazené paměti.

63

Stav operační paměti po spuštění a dokončení testovacího SELECT skriptu:

Stav operační paměti systému po restartu služby SQL Server (MSSQLSERVER):

Výsledky samotných testů pak správnost tohoto předpokladu potvrzují také, neboť první běh s čistou pamětí je vždy po restartu celého serveru a výsledky dalších běhů se od něj prakticky neliší (testy A). Testy s databází v paměti mají oproti tomu časy provedení skriptu výrazně kratší (testy B). Všechny naměřené hodnoty jsou v sekundách.

2.6.1 Fyzické prostředí Testy na fyzickém prostředí budou opět pokládány za referenční a jejich výsledky jsou obsaženy v tabulce 31. 1

2

3

4

5

6

7

8

9

10

Průměr

A

33

33

33

33

33

33

33

34

33

33

33,1

B

20

21

20

21

20

21

20

20

20

20

20,3

Tabulka 31 – Microsoft SQL test na fyzickém prostředí (zdroj: vlastní)

Záznamy všech měření jsou obsaženy v příloze 14.

2.6.2 Hyper-V Výsledky měření z virtuálního serveru v prostředí Hyper-V obsahuje tabulka 32. 1

2

3

4

5

6

7

8

9

10

Průměr

A

40

40

40

39

40

39

41

39

39

40

39,7

B

23

23

22

23

23

23

23

23

23

23

22,9

Tabulka 32 – Microsoft SQL test na Hyper-V (zdroj: vlastní)

Záznamy všech měření jsou obsaženy v příloze 15.

2.6.3 VMware Poslední z testovaných prostředí, tedy hypervizor ESXi, má naměřené hodnoty zapsány do tabulky 33.

64

1

2

3

4

5

6

7

8

9

10

Průměr

A

49

47

48

48

47

47

47

48

47

47

47,5

B

26

26

26

26

26

25

26

26

26

26

25,9

Tabulka 33 – Microsoft SQL test ve VMware (zdroj: vlastní)

Záznamy všech měření jsou obsaženy v příloze 16. Ve všech třech prostředích byly naměřené hodnoty testů prakticky bez výkyvu a není tak pro korektní vyhodnocení třeba provádět další měření.

65

3 Vyhodnocení a porovnání výsledků Vyhodnocení výsledků provedu tak, jak byly měřeny, tedy po jednotlivých měřených komponentách, a následně vyhodnotím všechna tři testovaná prostředí celkově. v tabulkách jsou seskupeny průměrné hodnoty jednotlivých měření pro všechna prostředí. Hodnoty fyzického prostředí jsou vždy považovány za referenční a mají tedy váhu 100%. Hodnoty ostatních prostředí jsou pak od výsledků fyzického prostředí hodnoceny absolutní hodnotou v procentech, tedy kolika procent dosahuje průměrná hodnota parametru virtuálního prostředí průměrné hodnoty naměřené ve fyzickém prostředí.

3.1 Paměť První provedený test paměti byl proveden nástrojem MaxxMEM 2, který však nefungoval ve virtuálním serveru na hypervizoru ESXi, a proto nebudu jeho výsledky uvažovat v celkovém hodnocení. Použiji jej však za test srovnávací k výsledkům testu nástroje PassMark Performance Test. Tabulka 34 představuje srovnání výsledků mezi fyzickým prostředím a hypervizorem Hyper-V. Fyzické prostředí

Hyper-V

Hyper-V vs. Fyzické

4117,4

88%

3900,4

104%

3374,4

73%

3,637

87%

99,23

92%

Memory Copy – kopírování (MB/s) 4696,1 Memory Read – čtení (MB/s) 3755,3 Memory Write – zápis (MB/s) 4610,5 Memory Score – dosažené skóre (GB/s) 4,184 Memory Latency – latence (ns) 91,31

Tabulka 34 – Vyhodnocení Maxx MEM2 testu (zdroj: vlastní)

Z výsledků je patrné, že hypervizoru nedělá příliš problém čtení paměti a v této oblasti dosahuje prakticky stejných výsledků, jako prostředí fyzické. Naopak zápis do paměti je pro virtuální server největším hendikepem. Ostatní hodnoty, včetně celkové známky, se pohybují

66

na hranici 90%. Vyhodnocení výkonu paměti testovacím nástrojem Maxx MEM2 tedy ukazuje, že virtuální server na hypervizoru Hyper-V je o zhruba 10% nižší, než u serveru běžícího přímo na serveru fyzickém. Testovací nástroj PassMark Performance Test 8 již fungoval bez problémů na všech srovnávaných prostředích, a srovnání výsledků všech měření obsahuje tabulka 35. Fyzické

Hyper-V

Hyper-V váha

VMware

VMware váha

Memory Mark (celková známka) 598,6

553,2

92%

443,9

74%

Memory – Database Operations – databázové operace (tisíce operací za sekundu) 25,98

13,57

52%

7,83

30%

Memory – Read Cached – čtení kešované (megabajty přenesené za sekundu) 11391,2

11283,4

99%

11136,1

98%

Memory – Read Uncached – čtení nekešované (megabajty přenesené za sekundu) 4308,3

3290,4

76%

2537,8

59%

Memory – Write – zápis (megabajty přenesené za sekundu) 1737,1

1613,4

93%

1523,3

88%

Memory – Latency – latence (v nanosekundách, méně je lépe) 53,53

57,78

93%

71,26

75%

Tabulka 35 – Vyhodnocení PassMark memory testu (zdroj: vlastní)

Srovnám-li nejdříve výsledky předešlého srovnání s výsledky v tomto nástroji, je zřejmé, že dle celkové známky je i zde hypervizor Hyper-V o zhruba 10% slabší. i přes různé měřící techniky se tedy závěry obou testovacích nástrojů shodují. Na výsledcích z nástroje PassMark je na první pohled patrné, že hypervizor ESXi od společnosti VMware svým virtuálním serverům neposkytuje tolik paměťového výkonu, jako hypervizor Hyper-V. V absolutním hodnocení je to až o 25% méně, než u serveru na fyzickém stroji. Největší problém oběma virtuálním serverům činil test databázových operací a nekešované čtení, kde jsou absolutní hodnoty výsledků výrazně pod referenčními hodnotami. Naopak u kešovaného čtení se oba hypervizory dostaly prakticky na úroveň serveru fyzického. Celkově mně značně nepříznivé výsledky hypervizoru ESXi v porovnání s Hyper-V velice překvapily.

67

3.2 Procesor Procesor je jediná část počítače, která se nedá nahradit nějakou částí virtuální, a v hypervizorech je to také jediná část, jejíž zdroje nelze spotřebovávat nad limit fyzické kapacity host serveru. To neplatí například pro operační paměti, které lze virtuálním serverům přidělit v součtu více, než kolik jí obsahuje fyzický host. Předpokladem proto je, že virtuální servery by v této oblasti neměly výrazně zaostávat za serverem fyzickým. První test byl proveden nástrojem CPU Free BenchMark 2.2 a srovnání jeho výsledků shrnuje tabulka 36. Fyzické

Hyper-V

Hyper-V váha

VMware

VMware váha

29,712

30,058

99%

30,235

98%

Tabulka 36 – Vyhodnocení CPU Free BenchMark 2.2 testu (zdroj: vlastní)

Z výsledků je zřejmé, že virtualizace nemá prakticky žádný vliv na hrubý výpočetní výkon serveru. i přes to, že rozdíl ve výsledcích je prakticky mizivý, je zde opět hypervizor ESXi v absolutních číslech slabší než jeho protějšek Hyper-V. v počtu provedených měření a konzistenci jejich výsledků nemohu tento fakt pokládat za nepodstatný. Druhá sada testů byla provedena opět nástrojem PassMark Performance Test 8 a srovnání jejich výsledků je obsaženo v tabulce 37.

Fyzické

Hyper-V

Hyper-V váha

VMware

VMware váha

106%

3260,2

102%

CPU Mark (celková známka) 3201,1

3383

CPU – Integer Math – celočíselné výpočty (miliony operací za sekundu) 5190,2

4958,9

96%

4884,9

94%

CPU – Floating Point Math – výpočty desetinné (miliony operací za sekundu) 3028,6

2685,5

89%

2557,3

84%

CPU – Prime Numbers – prvočísla (miliony prvočísel za sekundu) 8,85

16,92

191%

15,57

176%

CPU – Extended Instructions (SSE) (miliony matic za sekundu) 8,5

8,38

99%

8,31

98%

CPU – Compression – komprese (kilobajty zpracované za sekundu) 5321,9

5205,8

98%

68

5203,2

98%

CPU – Encryption – šifrování (megabajty přenesené za sekundu) 662,9

656

99%

648,9

98%

214,95

111%

2956,8

99%

CPU – Physics – výpočty fyziky (snímků za sekundu) 193,0

249,58

130%

CPU – Sorting – třídění (tisíce řetězců za sekundu) 2989,2

3000,6

100%

CPU – Single Threaded – jednovláknové výpočty (miliony operací za sekundu) 937,8

888,6

95%

863

92%

Tabulka 37 – Vyhodnocení PassMark CPU testu (zdroj: vlastní)

Celkové výsledky tohoto testu jsou značně nevěrohodné. Není fyzicky možné, aby virtuální server byl z pohledu procesoru výkonnější, než server fyzický, při využití totožné výpočetní jednotky. Příčinou jsou výsledky dvou měřících metod a to výpočet prvočísel a výpočet fyziky. Nebyl jsem zatím schopen zjistit, proč jsou tyto dvě metody ve virtuálních serverech o tolik výkonnější. Spolu s enormně nestandardními výsledky je proto nebudu uvažovat do celkového hodnocení. Stav je pak podobný, jako u testu předchozího, kdy virtuální servery dosahují prakticky totožných výsledků, až na výpočty v pohyblivé čárce a jednovláknové výpočty, kde jsou výsledky hypervizorů výrazněji slabší. Při pohledu na výsledky jednotlivých metod se zde opět potvrzuje výkonová ztráta hypervizoru ESXi za Hyper-V a to ve všech položkách.

3.3 Diskové úložiště Jak jsem již zmínil v podkapitole 2.4, výsledky měření výkonu pevných disků jsem byl nucen pro správnost vynesených závěrů korigovat o koeficienty, které vyrovnávají rozdíly ve fyzickém umístění testovaných oddílů na plotnách pevných disků serveru. Jsem si vědom, že takto získané hodnoty nejsou přesné, a v celkovém hodnocení to zohledním. První hodnocené výsledky jsou z testovacího nástroje HD Tune PRO a jsou zpracovány v tabulce 38.20

20

Vyhodnocovací tabulky testů diskových úložišť obsahují v záhlaví označení: Fyz - fyzický server; Hyp - Hyper-V; Koef. - korekční koeficient; index k – výsledná hodnota upravena korekčním koeficientem; index v – váha vůči referenční hodnotě.

69

Disk

Blok

Fyz

Hyp

Koef.

HypK

HypV

ESX

Koef.

ESXK

ESXV

Transfer Rate – Average (průměrná přenosová rychlost) – MB/s C:

4 kB

32,62

18,95

1,11

21,04

65%

15,32

1,23

18,84

58%

C:

512 kB

169,39

190,17

1,11

211,09

125%

111,39

1,23

137,01

81%

C:

4 MB

196,6

196,64

1,11

218,27

111%

149,94

1,23

184,43

94%

D:

64 kB

147,2

88,8

1,00

88,8

60%

89,99

1,17

105,29

72%

Access Time (přístupová doba) – ms C:

4 kB

3,164

3,298

0,99

3,265

97%

3,386

0,92

3,115

102%

C:

512 kB

3,184

3,277

0,99

3,244

98%

3,286

0,92

3,023

105%

C:

4 MB

3,191

3,330

0,99

3,297

97%

3,358

0,92

3,089

103%

D:

64 kB

4,059

10,21

0,98

10,006

41%

11,14

0,93

10,360

39%

Tabulka 38 – Vyhodnocení HD Tune PRO testu (zdroj: vlastní)

Výsledky měření systémového disku všech prostředí, tedy disku C:, nebudu zahrnovat do celkového hodnocení. Důvodem je nevhodně zvolený formát disků ve virtuálních serverech, který výsledky testů znehodnotil. Nepokládám to za chybu přípravy, tento typ jsem na systémových discích zvolil cíleně, jakožto alternativu k pevně formátovanému disku. Zajímal mě vliv takového formátování na výkonnost. Testy pak z tohoto důvodu byly provedeny jen na malé části disku, konkrétně na prvních 8 GB ve všech prostředích, a i přes to byly v měřeních ve virtuálních prostředích přítomny anomálie. Za povšimnutí stojí, jak velikost bloku ovlivňuje výkonost pevného disku. Velmi malé bloky výkon výrazně snižují, na druhou stranu zase efektivněji ukládají data a zvyšují tak využitelnou diskovou kapacitu. Z pohledu latence je vliv virtualizace na systémovém disku prakticky nulový. Rovné podmínky v tomto testu byly v měření disku D:, který je na všech prostředích určen pro uložení databáze, a tato měření proto hodnotit ve srovnání budu. Testy byly nastaveny na velikost bloku 64 kB, stejně jako u korekčních měření. Z výsledků je zřejmé, že zde virtuální servery velmi výrazně zaostávají za serverem fyzickým, a to jak v samotné rychlosti, tak i v přístupové době. Zatímco rychlost je u virtuálních serverů na úrovní 60% v případě Hyper-V, respektive 72% v případě ESXi serveru, přístupová doba je u obou na hranici 40% hodnoty serveru fyzického. Zde je ESXi server od VMware lepší než konkurenční Hyper-V. Výsledky z testovacího nástroje PassMark Performance Test 8 jsou obsaženy v tabulce 39.

70

Disk

Fyz

Hyp

Koef.

HypK

HypV

ESX

Koef.

ESXK

ESXV

Disk Mark (celková známka) C:

1103,1

997,6

1,02

1017,6

92%

896,5

1,13

1013,1

92%

D:

604,0

575,0

1,06

609,5

101%

322,1

1,23

396,2

66%

Disk – Sequential Read – sekvenční čtení (megabajty přenesené za sekundu) C:

163,94

139,86

1,06

148,25

90%

135,76

1,12

152,05

93%

D:

147,58

137,60

1,07

147,23

100%

76,99

1,25

96,24

65%

Disk – Sequential Write – sekvenční zápis (megabajty přenesené za sekundu) C:

115,88

110,68

1,05

116,21

100%

87,38

1,24

108,35

94%

D:

12,31

14,40

0,99

14,26

116%

5,63

1,11

6,25

51%

Disk – Random Seek + RW – náhodné čtení a přepis (megabajty přenesené za sekundu) C:

25,22

25,31

0,68

17,21

68%

24,75

0,67

16,58

66%

D:

7,16

7,02

1,00

7,02

98%

6,45

1,03

6,64

93%

Tabulka 39 – Vyhodnocení PassMark disk test (zdroj: vlastní)

Ani zde nebudu hodnotit výsledky testu systémového disku C:, i když pro zajímavost uvádím, že po započítání korekčních koeficientů jsou výsledky obou hypervizorů srovnatelné. U databázového disku D: je však v tomto případě výsledek jiný, než v případě výsledků předchozího testovacího nástroje. Důvodem může být princip, jakým oba nástroje s diskem pracují. HD Tune Pro provádí čtení přímo z fyzického nosiče a nebere v potaz použitý souborový systém, velikost jeho alokační jednotky, atd. Oproti tomu PassMark test pracuje s diskem logickým a operace tedy provádí na souborovém systému měřeného disku. Výsledky ukazují, že v tomto případě je virtuální server na hypervizoru Hyper-V prakticky srovnatelný s fyzickým serverem, zatím co hypervizor ESXi celkově o zhruba 35% slabší. Příčinu toho vidím právě v použitých souborových systémech. Zatím co u Hyper-V je diskové úložiště hypervizoru i virtuálního serveru formátováno souborovým systémem NTFS, hypervizor ESXi používá svůj vlastní souborový systém VMFS3, který je optimalizovaný pro prostředí klastrů. Proto výsledky hypervizoru ESXi v tomto testu prakticky odpovídají výsledkům testu předchozího a hypervizor Hyper-V zde z jednotných souborových systémů výrazně profituje. Posledním testem diskových úložišť je rozšířený test v nástroji PassMark Performance Test. Tomuto testu budu dávat největší váhu a výkonost diskových úložišť budu hodnotit právě z něj. Testovací nástroj totiž nejprve vytvoří na disku testovací data o velikost 1 GB pro nastavení „Workstation“, respektive 2 GB pro nastavení „Database“ a z těchto dat pak fyzicky

71

data čte a přepisuje. Chová se tedy jako běžná aplikace pracující s daty na pevném disku. Výsledky jsou obsaženy v tabulce 40. Disk

Fyz

Hyp

Koef.

HypK

HypV

ESX

Koef.

ESXK

ESXV

Rychlost disku (MB/s) C:

4,127

4,214

1,00

4,214

102%

3,990

0,96

3,830

93%

D:

1,042

1,019

1,08

1,10

106%

0,874

1,05

0,918

88%

Tabulka 40 – Vyhodnocení PassMark advanced disk test (zdroj: vlastní)

V tomto testu hodnotím výsledky pro oba disky, neboť jejich formát nehraje roli. i v tomto testu je zřejmé, že jednotnost souborových systémů virtuálního serveru a hypervizoru HyperV hraje velkou roli na výkon a dosahuje prakticky stejného výkonu jako server fyzický. Virtuální server na hypervizoru ESXi je v obou případech v této oblasti o zhruba 10% slabší.

3.4 Síťová vrstva Výsledky srovnání měřených prostředí v rychlosti síťové komunikace jsou obsaženy v tabulce 41. Fyzické

Hyper-V

Hyper-V váha

VMware

VMware váha

TCP

905,68

905,34

100%

904,78

100%

UDP

710,88

335,7

47%

367,52

52%

Tabulka 41 – Vyhodnocení PassMark síťového testu (zdroj: vlastní)

Můj předpoklad byl v tomto případě z části potvrzen. v případě hojněji využívaného protokolu TCP, je rychlost přenosu na všech prostředích stejná. Na protokolu UDP pak ale virtuální servery dokáží komunikovat pouze na poloviční rychlosti serveru fyzického. Z pohledu využití si dovolím tvrdit, že důležitější data jsou vždy přenášena protokolem TCP, neboť je vyžadováno, aby příjemce obdržel vše, co mu bylo odesláno. Protokol UDP ztráty dat během přenosu neřeší, nevyhodnocuje zpětnou vazbu od příjemce a používá se proto převážně tam, kde se jisté ztráty dat akceptují (převážně živé přenosy multimédií). Z principu funkce protokolu UDP a naměřených výsledků proto vyvozuji, že hypervizory, potažmo jejich virtuální síťové přepínače, způsobují zhruba o polovinu více ztrát při přenosu.

72

3.5 Aplikace – MS SQL Posledním z testů bylo měření výkonu konkrétní aplikací. Tento test měl na běžně používané aplikaci vyhodnotit celkový vliv virtualizace, který pocítí její uživatel. Vzhledem k tomu, že první set testů (označen A) byl prováděn z paměťově čistého prostředí a databázový server tedy neměl žádnou část testované databáze uloženou v operační paměti, zavedl jsem do jeho výsledků také korekční koeficient získaný pro test diskových úložišť. Veškerá data pro zpracování SŘBD jsou totiž čtena z pevného disku a jeho rychlost tedy toto měření výrazně ovlivňuje. Pro druhý set měření, který pracuje s databází načtenou v operační paměti, jsem o použití korekčního koeficientu neuvažoval. Výsledky pak zachycuje tabulka 42. Disk

Fyz

Hyp

Koef.

HypK

HypV

ESX

Koef.

ESXK

ESXV

A

33,1

39,7

0,95

37,715

88%

47,5

0,80

38

87%

B

20,3

22,9

1,00

22,9

89%

25,9

1,00

25,9

78%

Tabulka 42 – Vyhodnocení výsledků SQL testu (zdroj: vlastní)

Výsledky ukazují, že v případě čistého běhu, bez databáze v operační paměti, jsou oba hypervizory o zhruba 10% pomalejší. v případě databáze načtené v operační paměti je virtuální server na hypervizoru ESXi o 10% pomalejší než virtuální server na hypervizoru Hyper-V, který je o zhruba 10% pomalejší, než server fyzický. Tyto výsledky přesně odpovídají rozdílům ve výkonnosti testovaných prostředí v oblasti operační paměti, která je v tomto testu využívána velmi výrazně. v testu a byla výrazně limitujícím faktorem rychlost diskového úložiště, proto je rozdíl mezi hypervizory prakticky nulový.

3.6 Celkové hodnocení Z porovnání jednotlivých výsledků měření je zřejmé, že samotná virtualizace serverů prakticky nemá vliv na hrubý výpočetní výkon serveru a na rychlost síťové komunikace. Oproti tomu vliv poměrně výrazný má na výkon operační paměti a diskových úložišť. Hendikep výkonosti diskových úložišť lze kompenzovat například tím, že se k virtuálním serverům připojí diskové oddíly z diskového pole přímo (VMware tuto funkci nazývá „raw device mapping“, Hyper-V „Pass-through disk“), což do značné míry eliminuje vliv samotného hypervizoru a jeho virtuálních ovladačů diskového řadiče. Výkonnost operační paměti však virtualizací serveru trpí, a výkonovou ztrátu není možné kompenzovat, pouze je s ní při návrhu virtuální architektury nutno počítat a akceptovat ji.

73

Celkový vliv virtualizace na výkon serverové infrastruktury tak, jak vyšel z výše uvedených testů, hodnotím ztrátou 10% výkonnosti v případě hypervizoru Microsoft Hyper-V, a ztrátou 20% výkonnosti v případě hypervizoru VMware ESXi.

74

Závěr Výsledky mnou provedených měření do jisté míry potvrdily obecně akceptované paradigma, že virtualizace snižuje výkon infrastruktury až o 30%. Testy provedené na totožném hardwaru prokázaly vliv virtualizace na úrovni 10-20%, podle typu použitého hypervizoru. Je pro mne osobně velkým překvapením, že lídr na poli virtualizace je na tom, co se týče efektivity fungování svého produktu hůře, než jeho přímý konkurent, a že rozdíl v absolutní hodnotě je tak výrazný. Přes to, že mnou provedené testy diskových úložišť je možné pokládat za ne zcela přesné, testy operační paměti, kterou pokládám za základ výpočetního výkonu serveru, byly provedeny tak, že jejich komparace a výsledky lze pokládat za zcela přesné. Své závěry proto o tento fakt opírám. Jsem přesvědčen, že i když samotná virtualizace má negativní vliv na efektivitu výpočetních systémů, je nutné se na problém dívat z širšího pohledu. Virtualizace totiž do prostředí podnikové výpočetní techniky přináší celou řadu funkcí a možností, které jsou bez virtualizace jen velmi těžko dosažitelné, mnohdy nejsou dosažitelné vůbec. Jedná se například o možnosti vysoké dostupnosti serverové infrastruktury, kterým jsem se věnoval ve své bakalářské práci[1], nezávislosti na použitém hardwaru, snadného zálohování, obnovování jednotlivých serverů nebo dokonce celých datacenter, a v neposlední řadě o velice výrazné zvýšení efektivity celé infrastruktury, což přináší nejen značné finanční úspory provozovatelům, ale také výrazně snižuje zátěž životního prostředí. Virtualizace je tedy rozhodně správnou cestou, kterou se informační technologie musí nadále ubírat. Bez virtualizace by nebyl cloud, což je v dnešním světě slovo představující synonymum budoucnosti světa IT. Cíl této diplomové práce pokládám za splněný a s jejími výsledky jsem spokojen, i když z pohledu certifikovaného specialisty na obě virtualizační platformy21, též značně překvapen.

21

Jsem držitelem certifikací „VMware Certified Professional 5 – Data Center Virtualization“ a „Microsoft Certified Professional“ se specializací „Server Virtualization with Windows Server Hyper-V and System Center Specialist.“

75

Seznam použité literatury Bibliografie [1]

OLIVA, Petr. Virtualizace: vysoká dostupnost serverové infrastruktury. Praha, 2013. Bakalářská práce. Bankovní institut vysoká škola, Katedra matematiky, statistiky a informačních technologií. Vedoucí práce Ing. Vladimír Beneš.

Elektronické dokumenty [2]

BITTMAN, Thomas J., Mark A. MARGEVICIUS a Philip DAWSON. Magic Quadrant for x86 Server Virtualization Infrastructure. Gartner [online]. 2014 [cit. 2015-06-29]. Dostupné z: http://www.gartner.com/technology/reprints.do?id=11WR7CAC&ct=140703&st=sb

[3]

LOWE, Scott. VMware's hypervisor hold may be waning. Wikibon [online]. 2012, 2012-08-23 [cit. 2015-06-29]. Dostupné z: http://wikibon.org/wiki/v/VMware's_hypervisor_hold_may_be_waning

[4]

MAURO, Andrea. ESXi - Partitions layout of system disk. VInfrastructure Blog: Virtualization, Cloud and Storage [online]. 2011, 2011-10-20 [cit. 2015-06-29]. Dostupné z: http://vinfrastructure.it/2011/12/esxi-partitions-layout-of-system-disk/

[5]

MORÁVEK, Vojtěch. VMware WebTech: Porovnání hypervizorů očíma VMware. VMware CZ & SK - Google+ [online]. 2012 [cit. 2015-06-29]. Dostupné z: http://goo.gl/JE7zh

[6]

PassMark PerformanceTest: PC benchmark software. PassMark Software: PC Benchmark and Test Software [online]. 2015 [cit. 2015-06-29]. Dostupné z: http://www.passmark.com/products/pt.htm

[7]

VMWARE, INC. VMware Virtualization for Desktop & Server, Public & Private Clouds [online]. 2015 [cit. 2015-06-29]. Dostupné z: http://www.vmware.com/

[8]

VMWARE, INC. Host OS Compatibility Guide [online]. 2014, 2014-12-16 [cit. 2015-06-29]. Dostupné z: http://www.vmware.com/resources/compatibility/pdf/VMware_HOS_Compatibility_Gu ide.pdf

Wikipedia [9]

Binární předpona. Wikipedia: the free encyclopedia [online]. San Francisco (CA): Wikimedia Foundation, 2001-, 2014-08-14 [cit. 2015-06-29]. Dostupné z: https://cs.wikipedia.org/wiki/Bin%C3%A1rn%C3%AD_p%C5%99edpona

[10] Hyper-V. Wikipedia: the free encyclopedia [online]. San Francisco (CA): Wikimedia Foundation, 2001-, 2015-06-08 [cit. 2015-06-29]. Dostupné z: https://en.wikipedia.org/wiki/Hyper-V

76

[11] Solid-state drive. Wikipedia: the free encyclopedia [online]. San Francisco (CA): Wikimedia Foundation, 2001-, 2015-06-23 [cit. 2015-06-29]. Dostupné z: https://en.wikipedia.org/wiki/Solid-state_drive [12] VMware. Wikipedia: the free encyclopedia [online]. San Francisco (CA): Wikimedia Foundation, 2001-, 2015-06-20 [cit. 2015-06-29]. Dostupné z: http://en.wikipedia.org/wiki/Vmware [13] VMware ESX. Wikipedia: the free encyclopedia [online]. San Francisco (CA): Wikimedia Foundation, 2001-, 2015-06-23 [cit. 2015-06-29]. Dostupné z: http://en.wikipedia.org/wiki/VMware_ESX [14] VMware Workstation. Wikipedia: the free encyclopedia [online]. San Francisco (CA): Wikimedia Foundation, 2001-, 2015-06-24 [cit. 2015-06-29]. Dostupné z: https://en.wikipedia.org/wiki/VMware_Workstation

77

Seznam obrázků Obrázek 1 – Architektura Hyper-V (zdroj: [10]) ..................................................................... 14 Obrázek 2 – VMware Workstation - správce snapshotů (zdroj: [14]) ..................................... 18 Obrázek 3 – Architektura ESX (zdroj: [7]) .............................................................................. 20 Obrázek 4 – Architektura ESXi (zdroj: [7])............................................................................. 21 Obrázek 5 – Transparent Page Sharing (zdroj: [5]) ................................................................. 22 Obrázek 6 – Podíl ostatních hypervizorů provozovaných vedle VMware (zdroj: [3]) ............ 28 Obrázek 7 – MaxxMEM2 (zdroj: vlastní) ................................................................................ 30 Obrázek 8 – CPU Free BenchMark 2.2 (zdroj: vlastní) ........................................................... 31 Obrázek 9 – HD Tune 2.55 (zdroj: vlastní) .............................................................................. 34 Obrázek 10 – PassMark Advanced Network Test (zdroj: vlastní) ........................................... 35 Obrázek 11 – Detail fyzického prostředí z OS (zdroj: vlastní) ................................................ 38 Obrázek 12 – Detail Hyper-V prostředí z OS (zdroj: vlastní) .................................................. 39 Obrázek 13 – Detail ESXi prostředí z OS (zdroj: vlastní) ....................................................... 39 Obrázek 14 – Paměť v OS hypervizoru ESXi a v nástroji PassMark (zdroj: vlastní) ............. 47 Obrázek 15 – PassMark TCP síťový test ¨na fyzickém prostředí (zdroj: vlastní) .................... 61 Obrázek 16 – PassMark UDP síťový test na fyzickém prostředí (zdroj: vlastní) .................... 61 Obrázek 17 – PassMark TCP síťový test Hyper-V (zdroj: vlastní) .......................................... 62 Obrázek 18 – PassMark UDP síťový test Hyper-V (zdroj: vlastní) ......................................... 62 Obrázek 19 – PassMark TCP síťový test VMware (zdroj: vlastní) ......................................... 63 Obrázek 20 – PassMart UDP síťový test VMware (zdroj: vlastní) .......................................... 63

Seznam tabulek Tabulka 1 – Porovnání hlavních rozdílů architektur ESX a ESXi (zdroj: vlastní) .................. 20 Tabulka 2 – Microsoft patch Tuesdays - vliv patchů OS na virtualizaci (zdroj: [5]) .............. 26 Tabulka 3 – Poměr nasazených hypervizorů dle průzkumu Wikibon 2012 (zdroj: [3]) .......... 27 Tabulka 4 – Přehled použitých diskových oddílů (zdroj: vlastní)............................................ 37 Tabulka 5 – MaxxMEM2 výsledky fyzické prostředí (zdroj: vlastní) ..................................... 44 Tabulka 6 – PassMark Memory výsledky fyzické prostředí (zdroj: vlastní) ........................... 45 Tabulka 7 – MaxxMEM2 výsledky Hyper-V (zdroj: vlastní) .................................................. 45 Tabulka 8 – PassMark Memory výsledky Hyper-V (zdroj: vlastní) ........................................ 46 Tabulka 9 – PassMark Memory výsledky VMware (zdroj: vlastní) ........................................ 47 78

Tabulka 10 – CPU Free Bench Mark 2.2 výsledky fyzické prostředí (zdroj: vlastní) ............. 48 Tabulka 11 – PassMark CPU výsledky fyzické prostředí (zdroj: vlastní) ............................... 49 Tabulka 12 – CPU Free Bench Mark 2.2 výsledky Hyper-V (zdroj: vlastní) .......................... 49 Tabulka 13 – PassMark CPU výsledky Hyper-V (zdroj: vlastní) ............................................ 50 Tabulka 14 – CPU Free Bench Mark 2.2 výsledky VMware (zdroj: vlastní) .......................... 50 Tabulka 15 – PassMark CPU výsledky VMware (zdroj: vlastní) ............................................ 51 Tabulka 16 – HDTune HDD test fyzické prostředí (zdroj: vlastní) ........................................ 54 Tabulka 17 – PassMark HDD test fyzické prostředí (zdroj: vlastní) ....................................... 54 Tabulka 18 – PassMark Advanced HDD test fyzické prostředí (zdroj: vlastní) ...................... 55 Tabulka 19 – HDTune HDD test Hyper-V (zdroj: vlastní) ...................................................... 56 Tabulka 20 – PassMark HDD test Hyper-V (zdroj: vlastní) .................................................... 57 Tabulka 21 – PassMark Advanced HDD test Hyper-V (zdroj: vlastní) ................................... 57 Tabulka 22 – HDTune HDD test VMware (zdroj: vlastní) ...................................................... 58 Tabulka 23 – PassMark HDD test VMware (zdroj: vlastní) .................................................... 59 Tabulka 24 – PassMark Advanced HDD test VMware (zdroj: vlastní) ................................... 59 Tabulka 25 – Korekční test HD Tune (zdroj: vlastní) .............................................................. 60 Tabulka 26 – Korekční test PassMark (zdroj: vlastní) ............................................................. 60 Tabulka 27 – Korekční test PassMark Advanced (zdroj: vlastní) ............................................ 60 Tabulka 28 – PassMark síťový test fyzické prostředí (zdroj: vlastní) ...................................... 62 Tabulka 29 – PassMark síťový test Hyper-V (zdroj: vlastní) .................................................. 62 Tabulka 30 – PassMark síťový test VMware (zdroj: vlastní) .................................................. 63 Tabulka 31 – Microsoft SQL test na fyzickém prostředí (zdroj: vlastní)................................. 64 Tabulka 32 – Microsoft SQL test na Hyper-V (zdroj: vlastní)................................................. 64 Tabulka 33 – Microsoft SQL test ve VMware (zdroj: vlastní)................................................. 65 Tabulka 34 – Vyhodnocení Maxx MEM2 testu (zdroj: vlastní) .............................................. 66 Tabulka 35 – Vyhodnocení PassMark memory testu (zdroj: vlastní) ...................................... 67 Tabulka 36 – Vyhodnocení CPU Free BenchMark 2.2 testu (zdroj: vlastní)........................... 68 Tabulka 37 – Vyhodnocení PassMark CPU testu (zdroj: vlastní) ............................................ 69 Tabulka 38 – Vyhodnocení HD Tune PRO testu (zdroj: vlastní) ............................................ 70 Tabulka 39 – Vyhodnocení PassMark disk test (zdroj: vlastní) ............................................... 71 Tabulka 40 – Vyhodnocení PassMark advanced disk test (zdroj: vlastní) ............................... 72 Tabulka 41 – Vyhodnocení PassMark síťového testu (zdroj: vlastní) ..................................... 72 Tabulka 42 – Vyhodnocení výsledků SQL testu (zdroj: vlastní) ............................................. 73

79

Seznam příloh Všechny přílohy jsou vzhledem k velkému objemu dat umístěny na elektronickém nosiči. Příloha 1 – Výsledky měření paměti fyzického serveru

(CD:\Priloha1)

Příloha 2 – Výsledky měření paměti Hyper-V

(CD:\Priloha2)

Příloha 3 – Výsledky měření paměti VMware

(CD:\Priloha3)

Příloha 4 – Výsledky měření procesoru fyzického serveru

(CD:\Priloha4)

Příloha 5 – Výsledky měření procesoru Hyper-V

(CD:\Priloha5)

Příloha 6 – Výsledky měření procesoru VMware

(CD:\Priloha6)

Příloha 7 – Výsledky měření diskového úložiště fyzického serveru

(CD:\Priloha7)

Příloha 8 – Výsledky měření diskového úložiště Hyper-V

(CD:\Priloha8)

Příloha 9 – Výsledky měření diskového úložiště VMware

(CD:\Priloha9)

Příloha 10 – Výsledky korekčního měření diskového úložiště

(CD:\Priloha10)

Příloha 11 – Výsledky měření sítě fyzického serveru

(CD:\Priloha11)

Příloha 12 – Výsledky měření sítě v Hyper-V

(CD:\Priloha12)

Příloha 13 – Výsledky měření sítě ve VMware

(CD:\Priloha13)

Příloha 14 – Výsledky měření aplikace SQL fyzického serveru

(CD:\Priloha14)

Příloha 15 – Výsledky měření aplikace SQL na Hyper-V

(CD:\Priloha15)

Příloha 16 – Výsledky měření aplikace SQL na VMware

(CD:\Priloha16)

80