Virtualizace operačních systémů v serverech

České vysoké učení technické v Praze Fakulta informačních technologií Katedra počítačových systémů

Bakalářská práce

Virtualizace operačních systémů v serverech Tomáš Kábrt

Vedoucí práce: Šimeček Ivan Ing., Ph.D.

17. května 2012

Poděkování Tímto bych chtěl poděkovat vedoucímu práce Ing. Ivanovi Šimečkovi Ph.D. za cenné rady a připomínky a celé mojí rodině za podporu při studiu.

Prohlášení Prohlašuji, že jsem předloženou práci vypracoval samostatně a že jsem uvedl veškeré použité informační zdroje v souladu s Metodickým pokynem o etické přípravě vysokoškolských závěrečných prací. Beru na vědomí, že se na moji práci vztahují práva a povinnosti vyplývající ze zákona č. 121/2000 Sb., autorského zákona, ve znění pozdějších předpisů, zejména skutečnost, že České vysoké učení technické v Praze má právo na uzavření licenční smlouvy o užití této práce jako školního díla podle § 60 odst. 1 autorského zákona.

V Praze dne 17. května 2012

..................... 7

České vysoké učení technické v Praze Fakulta informačních technologií c 2012 Tomáš Kábrt. Všechna práva vyhrazena.

Tato práce vznikla jako školní dílo na Českém vysokém učení technickém v Praze, Fakultě informačních technologií. Práce je chráněna právními předpisy a mezinárodními úmluvami o právu autorském a právech souvisejících s právem autorským. K jejímu užití, s výjimkou bezúplatných zákonných licencí, je nezbytný souhlas autora.

Odkaz na tuto práci Tomáš Kábrt. Virtualizace operačních systémů v serverech: Bakalářská práce. Praha: ČVUT v Praze, Fakulta informačních technologií, 2012.

Abstract Server virtualization is becoming to be widespread technology that brings many benefits and thus it should be considered when building a new IT infrastructure or during its renovation. To make correct decision whether to use this rapidly developing technology in corporate environments, it is necessary to have theoretical knowledge of server virtualization and virtualization tools. The main aim of this thesis is to clarify these principles and further describe the three most popular virtualization products. To explain the differences in their approaches and describe advantages and disadvantages which come with them. Eventually we will verify out conclusions with number of tests. Keywords virtualization, vSphere Hypervisor, Hyper-V, XenServer

Abstrakt Serverová virtualizace se stává stále rozšířenější technologií, která přináší mnoho výhod. Její nasazení by mělo být zváženo při budování nové IT infrastruktury, či při její renovaci. Pro správné rozhodování, zda tuto rychle se rozvíjející technologii nasadit do firemního prostředí, je nutná teoretická znalost virtualizace serverů a fungování jejích nástrojů. Cílem této práce je objasnit tyto principy a blíže popsat tři nejrozšířenější produkty. Vysvětlíme rozdíly v přístupu a jejich 9

výhody a nevýhody. Na závěr provedeme řadu testů, které všechny probírané nástroje dostatečně prověří. Klíčová slova virtualizace, vSphere Hypervisor, Hyper-V, XenServer

10

Obsah Úvod

17

1 Teorie virtualizace 1.1 Historie . . . . . . . . . . . . . . 1.2 Základní požadavky . . . . . . . 1.3 Virtualizace na architektuře x86 1.4 Hypervisor . . . . . . . . . . . . 1.5 Architektura hypervisorů . . . . 1.6 Výhody a nevýhody virtualizace

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

19 19 20 20 22 23 24

2 Virtualizační nástroje 2.1 VMware vSphere Hypervisor 2.2 Citrix XenServer . . . . . . . 2.3 Microsoft HyperV . . . . . . 2.4 Hardwarové limity . . . . . . 2.5 Přehled klíčových vlastností .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

27 28 29 30 32 33

. . . . .

. . . . .

3 AMD Bulldozer 37 3.1 Architektura . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37 3.2 Virtualizace . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40 3.3 Zhodnocení . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41 4 Testování 4.1 Výběr testovacích nástrojů 4.2 Postup provádění testů . . 4.3 Testovací sestava . . . . . 4.4 Příprava na testy . . . . . 4.5 Výsledky testů . . . . . .

. . . . .

. . . . .

Závěr

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

43 43 44 45 45 48 55

11

Literatura

57

A Seznam použitých zkratek

61

B Výsledky testů

63

C Obsah přiloženého CD

71

12

Seznam obrázků 1.1 1.2 1.3 1.4 1.5

Virtualizace Typu1 . . . . . Virtualizace Typu2 . . . . . Virtualizace hybrid . . . . . Monolitic hypervisor . . . . Microkernelized hypervisor

. . . . .

21 22 23 23 24

3.1 3.2

Porovnání typů vícevláknového zpracování . . . . . . . . . . . . . . Architektura AMD Bulldozer . . . . . . . . . . . . . . . . . . . . .

38 39

4.1 4.2 4.3 4.4

XenCenter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . VMware vSphere Client . . . . . . . . . . . . . . . . . . . . . . . . HyperV Manager . . . . . . . . . . . . . . . . . . . . . . . . . . . . Porovnání virtualizačních platforem s fyzickým serverem v procesorových testech . . . . . . . . . . . . . . . . . . . . . . . . . . . . Porovnání virtualizačních platforem s fyzickým serverem v paměťových testech . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Porovnání virtualizačních platforem s fyzickým serverem v testech pevného disku . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Porovnání přetížených systémů v procesorových testech . . . . . . Porovnání přetížených systémů v paměťových testech . . . . . . . Porovnání přetížených systémů v diskových testech . . . . . . . . .

46 47 48

4.5 4.6 4.7 4.8 4.9

. . . . .

. . . . .

. . . . .

13

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

49 49 50 51 52 53

Seznam tabulek 1.1

Porovnání architektur hypervisorů . . . . . . . . . . . . . . . . . .

25

2.1 2.2

Porovnání hardwarových limitů . . . . . . . . . . . . . . . . . . . . Porovnání funkcí hypervisorů . . . . . . . . . . . . . . . . . . . . .

32 35

4.1

Konfigurace testovací sestavy . . . . . . . . . . . . . . . . . . . . .

45

B.1 Výsledky testů porovnání virtualizovaných a nevirtualizovaných systémů část 1. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . B.2 Výsledky testů porovnání virtualizovaných a nevirtualizovaných systémů část 2. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . B.3 Výsledky testů přetížených systémů část 1. . . . . . . . . . . . . . B.4 Výsledky testů přetížených systémů část 2. . . . . . . . . . . . . . B.5 Výsledky testů nepřetížených systémů část 1. . . . . . . . . . . . . B.6 Výsledky testů nepřetížených systémů část 2. . . . . . . . . . . . .

15

64 65 66 67 68 69

Úvod Tématem této bakalářské práce je virtualizace operačních systémů v serverech. V poslední době se slovo virtualizace začalo kolem nás objevovat čím dál tím více. V polovině roku 2011 bylo virtualizováno minimálně 40% serverů založených na architektuře x86. Odborníci se domívají, že do roku 2015 má toto číslo růst až k 75%.(12) Na přechod do virtualizovaného prostředí láká především úspora nákladů, vyšší produktivita a zjednodušená správa. Je ale dobré si uvědomit, že virtualizace sebou nese i problémy a nehodí se za každé situace. Byla by chyba ji slepě nasazovat bez předchozí analýzy provedené odborníkem. Nejprve si vysvětlíme základní pojmy, principy a fungování serverové virtualizace. Přiblížíme si situace, kdy je vhodné ji použít a kdy je naopak lepší se jí vyhnout. Blíže si představíme tři největší výrobce virtualizačních technologií a to VMware, Microsoft a Citrix a jejich produkty vSphere Hyprvisor, Hyper-V a XenServer. Provedeme srovnání, a to jak teoretické na základě jejich specifikace, tak i praktické za pomocí provádění testů. V rámci práce provedeme i test přetížení fyzického hardwaru, kdy budeme vytěžovat více prostředků, než je fyzicky k dispozici. Jednou z nejdůležitějších komponent pro virtualizaci je procesor, který může počtem jader, taktovací frekvencí a použitými instrukčními sadami rychlost virtualizace ovlivnit. AMD do svých procesorů přidává instrukční sady pro podporu virtualizace a my si vysvětlíme, čím pomáhají dosáhnout většího výkonu. Také si představíme novinku na poli procesorů a to AMD Bulldozer, která slibuje velký počet jader, které jsou členěny do modulů a mají vcelku dobrý výkon za příznivou cenu. Proto jsme se ho rozhodli využít při testování. Přínosem této práce bude představení novinek na poli rychle se rozvíjejícího odvětví virtualizace serverů a zjištění, jak si nové verze hypervisorů vedou v reálných testech. To nám pomůže odhalit, zda má některý výrobce významnou výkonovou výhodu. Také se dozvíme vhodnost nasazení platformy Bulldozer, která je jedním z posledních pokusů firmy AMD útočit na procesory Intel v oblasti serverových a desktopových procesorů. 17

Kapitola

Teorie virtualizace Virtualizace serverů nám umožňuje přistupovat k fyzickým prostředkům serveru jinak, než ve skutečnosti existují. Toto nám zajištuje vrstva mezi hardwarem a hostovaným operačním systémem zvaná hypervisor. Tato mezivrstva nám dovoluje na jednom fyzickém počítači spustit více nezávislých virtuálních strojů, které jsou od sebe odděleny a navzájem se neovlivňují. Lze říci, že primárním cílem virtualizace je skrýt technické detaily systému pod hypervisor, prostřednictvím kterého je k dispozici pouze výkon fyzického stroje.

1.1

Historie

Koncept virtualizace byl navrhnut v 60. letech firmou IBM. Díky této technologii bylo možné logicky rozdělit velký výpočetní výkon mezi oddělené virtuální stroje. To umožňovalo na mainframu spustit více procesů najednou. Většímu rozšíření bránila uzavřenost tohoto řešení právě na počítače typu mainframe. V 80. létech byla virtualizace prakticky odsouzena k záhubě. Do popředí se dostaly levnější řešení klient-server a tento trend pokračoval i v 90. letech. V té době se staly standardem servery na architektuře x86 a to především díky hustému nasazení serverových operačních systémů Linux a Windows. Tato situace vyvolala řadu problémů. Typický x86 server byl zatížen z 10% až 15%. Na jednom serveru byla spuštěna pouze jedna aplikace, aby se snížila šance, že pád jedné ovlivní chod druhé. Z tohoto plynulo, že bylo potřeba velké množství serverů, jejichž provoz stál nemalé prostředky za elektrickou energii na samotný běh serverů a na jejich chlazení. Správa takto velkých systémů byla náročná a bylo nutné zaměstnat více IT specialistů. Ani takto složité systémy neřešily problémy vysoké dostupnosti služeb, například při delším výpadku elektrické energie, napadení nebo živelné katastrofě. Při výčtu těchto nevýhod se nám do hry zase dostává skoro zapomenutá virtualizace. Průkopníkem se stala firma VMware, která v roce 1999 přichází s prvním produktem, který umožňuje virtualizaci počítačů platformy x86. O čtyři roky déle uvádí firma Connectix první verzi Virtual PC for Win19

1

1. Teorie virtualizace dows. Tuto firmu později Microsoft odkoupil a na základech jejich technologií začal budovat produkt HyperV. Do boje se přidává také firma Citrix, která odkoupila XenSource. Velký zlom nastal v roce 2005 a 2006, kdy společnosti Intel a AMD začaly implementovat do svých procesorů technologie pro podporu virtualizace. Tím se otevřela cesta masivnímu nasazení virtualizace do středních a malých podniků.

1.2

Základní požadavky

V roce 1974 vyšel článek (25) napsaný dvojicí Gerald J. Popek a Robert P. Goldberg. V této práci jsou definovány základní vlastnosti, které musí hypervisor splňovat, aby virtualizace byla efektivní. Equivalence / Fidelity – Software spouštěný v rámci hypervisoru musí fungovat stejně, jako by byl spuštěn na ekvivalentním stroji bez hypervisoru. Resource control / Safety – Hypervisor musí mít kompletní kontrolu nad virtuálními prostředky. Efficiency / Performace – Naprostá většina instrukcí musí být spuštěna bez zásahu hypervisoru. Přestože jsou tato kritéria definována zjednodušeně, tak se stále dají použít pro rozhodnutí, zda daná architektura podporuje efektivní virtualizaci. Hlavní představitelé dnešních virtualizačních nástrojů nemájí problém s žádnými z nich.

1.3

Virtualizace na architektuře x86

Virtualizace systému na platformě x86 narážela ze začátku na řadu problémů. Tato architektura nabízí čtyři privilegované režimy. Nazýváme je Ring0 až Ring3. V části označované Ring0 je spuštěno jádro operačního systému, které má práva spouštět privilegované instrukce. Naopak v Ring3 jsou spuštěny uživatelské aplikace, které mají omezený přístup k paměti a k vstupním a výstupním jednotkám. Dnešní operační systémy se omezují na dvouvrstvé rozdělení a to na Ring0 a Ring3. Ring0 nazýváme privilegovaný nebo kernel mód. Ring3 nazýváme user mód. Operační systém v Ring0 má přímý přístup k hardwaru a tím pádem může provádět privilegované instrukce. Operační systémy na x86 platformě jsou navrženy tak, že vyžadují přímý přístup k hardwaru. Právě zde vzniká problém, protože při virtualizaci je potřeba umístit hypervisor do Ring0, který bude přímo přistupovat k hardwaru a dále ho přerozdělovat virtuálním strojům. Další problém nastal u některých instrukcí, které nebyly spouštěny z privilegovaného módu, takže nemohly být efektivně virtualizovány. Zachytávání a překlad těchto instrukcí byly natolik náročné, že se ze 20

1.3. Virtualizace na architektuře x86 začátku jevila virtualizace x86 architektury jako nemožná. Nakonec vznikají tři metody, jak s těmito instrukcemi zacházet. Full virtualization with binary translation - Veškeré požadavky od operačního systému jsou předávány hypervisoru, který je překládá a spouští na fyzickém hardwaru. Operační systém si není vědom, že je virtualizován. Hypervisor poskytuje virtuálním strojům všechny služby fyzického systému – virtuální BIOS, virtuální zařízení a správu pamětí. Tato technika plně odděluje operační systém od hardwaru, čímž je docílena nejlepší možná izolace a bezpečnost pro virtuální stroje. Paravirtualization – Operační systém si je vědom, že je virtualizován a jeho zdrojový kód je modifikován tak, aby byla odstraněna potřeba binárního překladu. Hlavní změnou je úprava kritických operací. Tato volání jsou nahrazena tzv. hypercally, které komunikují přímo s hypervisorem. Výhodou je zrychlení systémů. Nevýhodou je nutnost změny jádra operačního systému. Zatímco u open source systému jako je Linux nebo OpenBSB to není problém, tak u operačních systémů z dílny Microsoftu takováto změna možná není a tento typ je pro ně nedostupný. Hardware assisted virtualization (HAV) – S rostoucími požadavky na virtualizaci se rozhodly výrobci zaměřit na hardwarovou podporu virtualizace na úrovni procesorů, chipsetů, pamětí, řadičů disků a síťových karet. Základní myšlenkou je snažit se zachytávat všechny privilegované instrukce. Ty nechat zpracovat hypervisorem, který má práva pro jejich vykonání a poté předat řízení zpět virtuálnímu stroji. Každá z výše uvedených metod má svoje výhody a nevýhody, proto většina dnešních virtualizačních řešení nabízí jejich kombinaci.

Obrázek 1.1: Type1 architektura 21

1. Teorie virtualizace

Obrázek 1.2: Type2 architektura

1.4

Hypervisor

Hypervisor, někdy označovaný jako Virtual Machine Monitor, je jednoúčelový operační systém, který umožňuje spouštět paralelně více operačních systémů na jednom počítači. Tyto operační systémy se spouští v oddělených prostorech, které nazýváme virtuální stroje. Hypervisor je zodpovědný za přístup těchto virtuálních strojů k fyzickému hardwaru. John Scott Robin definoval ve své diplomové práci (26) rozdělení hypervisorů na tři typy a to dle jejich umístění. Type1 - Označovaný jako bare metal nebo nativní, označuje takový hypervisor, který je umístěn přímo na hardwaru (viz. obrázek 1.1). Hostovaný operační systém je spouštěn ve vrstvě nad hypervisorem. Tato metoda nám umožňuje úplné oddělení jednotlivých virtuálních počítačů. Do této skupiny patří VMWare VSphere Hypervisor, Microsoft HyperV a XenServer. Type2 - Nazývaný jako hostovaný, spouští hypervisor v rámci normálního operačního systému. Tím pádem hostované operační systémy jsou spuštěny až ve třetí vrstvě (viz. obrázek 1.2). Pokyny od hostovaných operačních systémů musí projít přes větší počet vrstev, což způsobuje zpomalení. Jako zástupce, kteří používají tento přístup, můžeme jmenovat KVM nebo VMware Workstation. Hybrid - Jak hostitelský operační systém, tak hypervisor jsou spuštěny vedle sebe přímo na hardwaru. Virtuální stroje jsou spuštěny nad hypervisorem (viz. obrázek 1.3). Hypervisor emuluje celé fyzické prostředí a všechny privilegované instrukce musí být softwarově překládány. Toto řešení stojí mezi Type1 a Type2. 22

1.5. Architektura hypervisorů

Obrázek 1.3: Hybridní architektura

Nás bude zajímat především Type1, který používají všechny tři blíže zkoumané virtualizační nástroje. Tento typ se hodí pro náročnou serverovou virtualizaci. Výhodu získává tím, že zde není přítomen hostitelský operační systém, přes který by procházely veškeré požadavky hostovaných operačních systémů k hardwaru a tím pádem je zpracování rychlejší.

1.5

Architektura hypervisorů

Hypervisor může mít dva typy architektury. Níže si popíšeme základní myšlenku obou přístupů a srovnáme výhody a nevýhody v tabulce B.6. Monolitic - Vlastní hypervisor v sobě obsahuje (viz. obázek 1.4) všechnu funkcionalitu, kterou očekáváme od operačního systému. Najdeme zde plánovač úloh, správu paměti, souborové systémy, rozhraní pro správu,

Obrázek 1.4: Monolitic hypervisor 23

1. Teorie virtualizace veškeré ovladače pro instalovaný hardware atd. Virtuální stanice poté přistupují k hardwaru prostřednictvím hypervisoru a ovladačů, které jsou v něm uloženy. Tyto ovladače musí být speciálně vytvořeny pro použití v hypervisoru. Z toho vyplývá, že by ovladače měly být stabilnější a rychlejší za cenu podporování menšího množství hardwaru a finančních nákladů na jejich vývoj a certifikaci. Ovladače v hypervisoru přináší bezpečnostní riziko tím, že do nejkritičtější části opračního systému zanášejí kód třetích stran. Microkernelized - Vlastní hypervisor má naprosté minimum funkcí, které jsou nezbytné ke sdílení hardwaru mezi virtuálními stroji. Jedním je plánovač úloh, který přiděluje fyzická jádra procesoru. Druhým je správa paměti, která zajišťuje, že žádné dva virtuální stroje nebudou přistupovat ke stejnému místu fyzické paměti. Ostatní funkčnost přebírá rodičovký oddíl. Ovladače pro fyzický hardware jsou spušeny v jeho kernel módu(viz. obrázek 1.5). Virtuální stroje komunikují pomocí hypervisoru a těchto ovladačů s vlastním hardwarem.

1.6

Výhody a nevýhody virtualizace

Na webových stránkách výrobců virtualizačních technologií je řada reklamních titulků, které lákají potencionální zákazníky na to, aby začali s virtualizací již dnes. Výhod je prý nepřeberně a o nevýhodách se nikdo nezmiňuje. My se nyní podíváme detailně na jednotlivé výhody. • Konsolidace serverů - Klasický server je většinu času velice málo zatížen a většina firem má z bezpečnostního hlediska jeden server dedikovaný pro jednu službu. Pomocí virtualizace lze snížit počet fyzických serverů

Obrázek 1.5: Microkernelized hypervisor 24

1.6. Výhody a nevýhody virtualizace tím, že je převedeme do virtuálního prostředí a spustíme je na jednom fyzickém serveru. • Snížení provozních nákladů - Jde v ruku v ruce s konsolidací serverů. Jelikož snížíme počet fyzických serverů, tak nám klesne spotřeba elektrické energie. Méně fyzických serverů vyprodukuje méně přebytkového tepla, takže klesne spotřeba elektrické energie na chlazení. • Zjednodušení obsluhy a administrace - Díky snížení počtu fyzických serverů, automatizované instalaci nových serverů ze šablon a jejich snadné přenositelnosti na jiný hardware nebo nástrojům pro centralizovanou správu jsou významně zjednodušeny úkony obsluhy. • Kontinuita provozu a vysoká dostupnost - i sebelepší hardware je poruchový a není otázkou zda se něco porouchá, ale kdy se něco porouchá. Virtuální server je oddělen od konkrétního fyzického hardwaru a je ho možné snadno zálohovat a obnovit na jiném hardwaru. Technologie živé migrace nám umožňuje přenést virtuální server na jiný fyzický server bez výpadku poskytované služby. Jak bylo již zmíněno výše, tak musíme mít na paměti i nevýhody. • Snížení výkonu - Oproti fyzickému serveru bude mít virtuální řešení vždy o něco menší celkový výkon. To je dáno režií přístupu k hardwaru prostřednictvím hypervisoru. Výrobci virtualizace se snaží tento rozdíl co nejvíce zmenšit neustálým vývojem hypervisoru. O zlepšní se snaží také výrobci hardwaru, kteří do svých produktů implementují instrukční sady podporující virtualizaci. V kapitole čtyři provedeme vlastní testy, které odhalí, jak velký je propad výkonu oproti nevritualizovanému řešení. Výhody Ovladače vyvíjeny a testovány přímo pro virtualizaci Virtuální stroje pracují nezávisle

Monolitic

Micro-kernelized

Menší velikost hypervisoru Širší podpora hardwaru Žádný kód třetích stran instalovaný v hypervisoru

Nevýhody Kód třetích stran instalovaný v hypervisoru Menší počet podporovaného hardwaru Větší velikost hypervisoru Chyba parent partition může ovlivnit všechny virtuální stroje Delší cesta k ovladačům

Tabulka 1.1: Porovnání architektur hypervisorů 25

1. Teorie virtualizace • Jeden bod selhání - S konsolidací nastává riziko, že hardwarová závada na jednom fyzickém serveru vyřadí z provozu několik služeb. Proti tomuto je důležité se bránit alespoň dvounodovým clusterem, v rámci kterého může probíhat migrace virtuálních strojů. Také je důležité mít záložní linky k zákazníkům a ke sdíleným diskovým polím. Pokud máme kritickou službu, tak musíme přemýšlet nad clusterem, který je umístěn na několika místech, která jsou od sebe dostatečně vzdálená, aby nebyly ovlivněné stejnými výpadky proudu, či živelnými katastrofami. • Nutné počáteční investice - Pro využití všech možností, které virtualizace nabízí, je nezbytné, aby IT pracovníci byli s touto technologií dostatečně seznámeni a proškoleni. Také při přechodu na virtualizaci je často nutné vyměnit servery, dokoupit sdílená uložitě, či pozměňit licencování softwaru. Samotná migrace stávající infrastrukury do virtualizované podoby může být časově dost náročná a může citelně ochromit chod společnosti. Dobré je si uvědomit, že pokročilé verze námi probíraných hypervisorů, které jsou určeny do produkčního prostředí, jsou zpoplatněny a v případě VMwaru to nejsou částky malé. Další výdaje jsou spojeny s pokročilými administračními nástroji.

26

Kapitola

Virtualizační nástroje Virtualizační řešení v dnešní době nabízí několik desítek společností, ale pouze několik jich je komerčně úspěšných a technologicky dobře vybavených. Dle studie společnosti Gartner (12) jsou na trhu s virtualizací tři leadeři. Předním výrobcem s největším zastoupením na trhu je firma VMware, která jako první dokázala virtualizovat platformu x86 a dodnes si svojí hlavní roli udržuje. Citrix založil svůj produkt na open source hypervisoru Xen a je důstojným soupeřem VMwaru. Nejmladší zástupce je HyperV od společnosti Microsoft, který byl uveden na trh v roce 2008. Svým rychlým vývojem a zajímavou cenovou politikou již předehnal podílem na trhu Citrix a začíná se přibližovat VMwaru. Získat přesný přehled podílů jednotlivých výrobců na trhu je složité a i odhady odborníků se liší. Nejčastěji přiřazují Citrixu 15%, Microsoftu 25% a VMwaru přes 50%. Na dalších řádcích si tyto produkty představíme a srovnáme, jak jsou navrženy a kde jsou rozdíly. Pro pochopení si nejprve definujeme několik pojmů:

Nod nazýváme jeden fyzický server, který je členem clusteru. Cluster je skupina nodů, které jsou mezi sebou propojeny a na venek se tváří jako jeden systém. V rámci clusteru může probíhat migrace virtuálních strojů, vyrovnávání zátěže, vypínání jednotlivých procesorů, či celých nodů. Integrační komponenty obsahují sadu ovladačů a služeb, které pomáhají virtuálnímu stroji k lepšímu výkonu. Pokud jsou nainstalovány v hostitelském systému, tak dochází k vytvoření syntetických zařízení (označují se jako syntetická proto, že neodpovídají žádnému existujícímu fyzickému zařízení) přes které je zprostředkován přístup na zařízení fyzická. 27

2

2. Virtualizační nástroje

2.1

VMware vSphere Hypervisor

Nejznámějším výrobcem na trhu serverové virtualizace je VMware. První produkt určený do tohoto segmentu byl vydán v roce 2001 pod názvem ESX. Tento nástroj obsahoval dva základní prvky: VMkernel je vlastní hypervisor. Což je operační systém, který je speciálně navržen pro běh více virtuálních strojů a má tři základní komponenty a to plánovač zdrojů, I/O zásobník, ovladače k hardwaru. Servisní konzole je virtuální stroj, ve kterém je nainstalována upravená linuxová distribuce Rad Hat. Tento stroj slouží jako zavaděč VMkernelu a jako administrační prostředí virtuálních strojů. V roce 2007 byl představen vylepšený hypervisor ESXi, který se od ESX liší v zásadní věci a tou je přítomnost servisní konzole. Úlohy, které zastávala, byly převedeny do hypervisoru nebo jejich úlohu převzaly externí programy, které komunikují přes externí komunikační rozhraní. ESXi zabírá na disku pouze 32MB oproti 2GB, které zabírá ESX. To ukazuje, že jsou dostupné opravdu pouze nejnutnější funkce. Administrace přímo na stroji se provádí pomocí Direct Console User Interface (DCUI) a zmenšila se na nastavení síťového rozhraní a administrátorského hesla, prohlížení logů, reset do původního nastavení a provádění jednoduchých síťových testů. (4) Pokročilá administrace se provádí vzdáleně přes síťové rozhraní pomocí externích programů. Přímo od VMware lze použít nástroj vSphere Client. Pro administraci clusteru virtualizovaných serverů lze zakoupit produkt vCenter. Oba administrační programy jsou výhradně pro operační systémy Windows. Z marketingových důvodů dochází v roce 2010 k přejmenování VMWare ESXi na VMware vSphere Hypervisor. (10) Z technické stránky řadíme produkt VMwaru do skupiny monolitických hypervisorů s binárním překladem instrukcí. Použití tohoto modelu je dáno tím, že tento hypervisor je nepřetržitě vyvíjen na stejných základech od roku 2001, kdy nebyly dostupné operační systémy a procesory, které by zvládaly paravirtualizaci, či podporovaly virtualizační technologie. V roce 2004 (22) představuje VMware podporou 64 bitových operačních systémů v produktu ESX. Pro virtualizaci těchto systémů využívá nových instrukčních sad v procesorech Intel a AMD. Další krok bylo představení paravirtualizačního rozhraní Virtual Machine Interface (VMI). Toto rozhraní slouží ke komunikaci mezi operačním systémem a hypervisorem. V roce 2009 VMware oznamuje, že nové produkty nebudou dále VMI podporovat, protože technologický pokrok hardwarově asistované virtualizace byl natolik rychlý, že nejen dohnal výkonovou ztrátu, ale v mnoha ohledech již začínal mít výhodu.(23) I z finanční stránky nebylo pro VMware vhodné udržovat větev, která nemá do budoucna využití. 28

2.2. Citrix XenServer V aktuální verzi vSphere Hypervisor si hypervisor sám vybírá pro jednotlivé virtuální stroje, zda použije binární překlad nebo hardwarově asistovanou virtualizaci tak, aby bylo dosaženo co nejvyššího výkonu.(24) Výběr probíhá podle vlastností procesoru, hostovaného operačního systému a aplikací, které jsou spuštěny. Popřípadě lze provést ruční změnu nastavení pomocí administrátorských nástrojů.

2.2

Citrix XenServer

Hypervisor Xen vznikl jako výzkumný projekt na univerzitě v Cambridge. V roce 2002 byl Xen uvolněn jako open source a umožňoval široké veřejnosti se podílet na vývoji a testování. Oficiální vydání Xen 1.0 proběhlo v roce 2003 a krátce na to byla vydána verze 2.0. V této době hlavní tvůrce projektu založil firmu XenSource, která dodávala řadu vylepšení a komerčních nástrojů umožňujících nasazení v podnikové sféře. Tato verze používala výhradně paravirtualizaci, takže bylo možné virtualizovat pouze upravené verze operačního systému Linux. V roce 2005 vychází verze 3.0, která přidává možnost použít hardwarově asistovanou virtualizaci. Tímto krokem se otevřely dveře do Xen virtualizačního světa i operačním systémům firmy Microsoft. V roce 2007 přichází na scénu společnost Citrix Systems, která kupuje XenSource a na základě jejich dosavadního produktu XenEnterprise staví XenServer 3.0 (21). Ten představuje důkladně otestované prostředí s důrazem na funkce pro korporátní sektor, jako je migrace v reálním čase nebo vysoká dostupnost. XenSource už je distribuován jako balík obsahující hypervisor Xen, přednastavený rodičovský oddíl a aplikaci XenCenter. Nyní je aktuální verze 6.0, která přináší novou verzi hyprvisoru Xen a dále vylepšení v oblasti vysoké dostupnosti, podpory operačních systémů, velikosti hardwarových limitů a možnost integrace s Microsoft System Center 2012. Xen řadíme do skupiny mikrokernelizovaných hypervisorů využívajících jak paravirtualizaci, tak hardwarově asistovanou virtualizaci. Po instalaci XenServeru se nám objeví mezi hardwarem a softwarem hypervisor a vznikne první virtuální stroj, který nazýváme Domain 0 (Dom0). V něm je instalován upravený operační systém CentOS a dva důležité ovladače a to pro síťové připojení (Network Backend Driver) a pro diskové úložiště (Block Backend Driver). Přes tyto ovladače jsou zpracovány požadavky od podřízených virtuálních strojů. Také je zde přípojný bod pro komunikaci s podřízenými virtuálními stroji nazývaný Event Channel (EC) a rozhraní pro externí správu (xe) (6). Podřízené virtuální stroje, které nazýváme Domain N (DomN), můžeme rozdělit do tří skupin podle způsobu komunikace s fyzickými zařízeními: Paravirtualizované linuxové operační systémy , které májí upravené jádro pro použití s hypervisorem Xen. Systémová volání jsou nahrazena takzvanými hypercally, které komunikují přímo s hypervisorem a Dom0 s použitím EC, čím je dosaženo pouze malého zpomalení systému. 29

2. Virtualizační nástroje Operační systémy s integračními komponenty , což jsou vlastně operační systémy, které nemají modifikované jádro, ale jsou na nich instalovány paravirtualizované ovladače. Díky těmto ovladačům je minimalizována ztráta výkonu při přístupu k I/O zařízením, protože se přistupuje přímo k ovladačům v Dom0 přes EC. Tento typ nejčastěji používají Microsoft operační systémy. Nemodifikované operační systémy nemají upravené jádro a nejsou pro ně dostupné či nainstalované integrační komponenty. V takovémto případě je použita emulace zařízení, která je výpočetně nejnáročnější a tím dochází k výraznému zpomalení systému. Paravirtualizované linuxové operační systémy s integračními komponenty mohou komunikovat s Dom0, skrze EC sběrnici a mohou synchronizovat čas, vytvářet snapshoty, kontrolovat dostupnost virtuálního stroje atd.

2.3

Microsoft HyperV

Microsoft Hyper-V, vyvíjený pod označením Viridian, je virtualizační platforma pro 32 a 64 bit systémy. Beta verze byla dostupná ve vybraných edicích Windows Serveru 2008, který byl vydán na začátku roku 2008 (11). Finální verze byla vydána v polovině roku 2008 a distribuce byla provedena přes službu Windows Update. HyperV je od té doby dostupný zdarma ve Windows serverových operačních systémech. Microsoft také nabízí úplně zdarma produkt Microsoft Hyper-V Server, což je vlastně core instalace Windows Serveru 2008 s rolí HyperV. Tento produkt je vhodný pro vyzkoušení virtualizace, či na virtualizování menšího prostředí. Jelikož je založen na core instalaci Windows Serveru, tak postrádá jakékoli grafické rozhraní. Ovládání a nastavování systému probíhá pouze přes příkazovou řádku, či vzdáleně pomocí Microsoft Management Console. V roce 2009 (20) přišel na trh Windows Server 2008 R2, jehož součástí byl i vylepšený hypervisor HyperV 2.0. Nová verze přinesla několik funkcí, díky kterým se technologicky přiblížila konkurenci. Jednalo se především o live migration, přibyla možnost připojit úložiště přes SCSI řadič za běhu virtuálního stroje, rozšířila se podpora procesorů a jejich technologií pro lepší řízení spotřeby a vyššího výkonu. Poslední vydanou důležitou aktualizací, která výrazněji mění HyperV je SP1 pro Windows Server 2008 R2. Přidává funkci dynamického přerozdělování paměti mezi virtuálními stroji. Pro správu používá vzdálený přístup a to konkrétně produkt HyperVManager. Pro pokročilou správu clusteru, či při budování cloudu je využíváno rodiny produktů System Center. HyperV řadíme do skupiny mikrokernelizovaných hypervisorů využívajících hardwarově asistovanou virtualizaci. Tím pádem pro běh HyperV je nutné 30

2.3. Microsoft HyperV mít server osazen procesory, které podporují virtualizační technologie. Instalace probíhá trochu jiným způsobem než u konkurence. Nejprve je nainstalován samotný Windows Server a poté je přidávána role HyperV, která nainstaluje mezi hardware a operační systém mezivrstvu hypervisor a původní operační systém je přesunut do takzvaného rodičovského oddílu. Ten má přímý přístup k fyzickým zařízením a obsahuje tyto základní komponenty: (7) Virtualization stack (VS), který má přímý přístup k fyzickým zařízením počítače a řídí podřízené virtuální stroje. Pro každý podřízený virtuální stroj je vytvořen jeden worker proces, který je zodpovědný za jeho sledování a umožňuje manipulaci se snapshoty. Také zde najdeme rozhraní Windows Management Instrumentation (WMI), přes které lze kompletně spravovat hypervisor a virtuální stroje. Virtualization Service Provider (VSP) je komponenta, která slouží podřízeným virtuálním strojům jako přípojný bod pro vyřizování I/O požadavků. Virtualization Machine Bus (VMB) je vysokorychlostní komunikační kanál mezi podřízenými virtuálními stroji a rodičovským strojem. Ovladače hardwaru , které jsou využívány při zprostředkování komunikace od podřízených virtuálních strojů k fyzickým zařízením. Ostatní virtuální stroje jsou spouštěny v takzvaných podřízených oddílech. Tyto oddíly můžeme podle instalovaného operačního systému, který definuje, jak se bude přistupovat k hardwaru rozdělit do tří kategorií: Windows operační systémy s integračními komponenty pro přístup k fyzickým zařízením je použito VSC, které komunikuje přes VMB s rodičovským oddílem. Takovýto systém by měl být nejrychlejší a dovoluje další komunikaci mezi rodičovským a podřízeným oddílem, která slouží například k synchronizaci času a posílání heartbeat signálu. Ostatní operační systémy s integračními komponenty fungují analogicky s výše uvedenými Windows operačními systémy. Na vývoji API pro HyperV, které dovoluje komunikaci s linuxovými integračními komponenty, se podílela firma XenSource. Operační systémy bez integračních komponent nedokáží komunikovat s rodičovským oddílem pomocí VMbus sběrnice. Hardware na tomto virtuálním stroji musí být emulován a hypervisor poté musí jeho požadavky odchytávat a přesměrovávat na rodičovský virtuální stroj a tím dochází ke zpomalení. (15) Integrační komponenty jsou dostupné pro Windows Server 2003, Windows XP SP2 a novější a z Linuxového světa Red Hat Enterprise Linux 5.2, SUSE Linux Enterprise Server 10 with SP4, CentOS 5.2 a jejich vyšší verze. 31

2. Virtualizační nástroje Jak oddíly rodičovské, tak oddíly podřízené nemají přístup k procesoru a operační paměti. Místo toho mají virtualizovaný pohled na procesor a jsou spuštěny v soukromém virtuálním adresním prostoru. Pomocí takzvaných hypercall volání se dorozumívají s hypervisorem, který tyto požadavky řídí a předává z hardwaru k virtuálním strojům a naopak.

2.4

Hardwarové limity

Maximální počet logických procesorů Maximální velikost RAM Maximální počet vCPU na virtuální stroj Maximální velikost vRAM na virtuální stroj Připojeni za běhu Maximální velikost clusteru Podporované typy uložišť

vSphere Hypervisor 160

HyperV

XenServer

64

64

2 TB

1 TB

1TB

32

4

16 (Windows), 32 (Linux)

1 TB

64 GB

128 GB

CPU, operační paměť, disky, síťové karty 32 nodů

SCSI disky

Disky karty

16 nodů

16 nodů

DAS, NAS, iSCSI, FC, FCoE, SSD na swap

DAS, iSCSI, FC, SAS

DAS, NAS, iSCSI, FC, SAS

a

síťové

Tabulka 2.1: Porovnání hardwarových limitů

Všechny hypervisory mají omezení, kolik hardwarových prostředků mohou spravovat a kolik jich mohou přidělovat jednotlivým virtuálním strojům. Tyto limity se s každou další verzí hypervisoru výrazně navyšují (19).V tabulce 2.1 jsou sepsány limity u aktuálních verzí hypervisorů. Podle zde uvedených čísel je jasné, že tyto limity nebudou omezovat 99% zákazníků, protože v dnešních verzích jsou tato čísla tak velká, že problém by mohl nastat maximálně u nadnárodních datacenter. 32

2.5. Přehled klíčových vlastností

2.5

Přehled klíčových vlastností

Společně s virtualizací se váže několik funkcí, které je důležité znát. Na dalších řádcích si tyto funkce představíme a popíšeme, jak fungují. Nakonec v tabulce uvidíme, jaký výrobce podporuje jaké funkce. Pokud výrobce danou funkci podporuje, tak je v tabulce 2.2 uveden i název, který pro něho ve své nabídce používá, protože ne vždy koresponduje s obecným názvem funkce. Live migration slouží k přemístění virtuálního stroje z jednoho fyzického serveru na druhý bez výpadku poskytované služby. Technologicky je toho docíleno tak, že se začne kopírovat obsah operační paměti z jednoho serveru na druhý. Když se dokončí první kopírování, tak se vypočtou změny, které vznikly na původním systému a tyto změny se začnou kopírovat. Proces kopírování se opakuje tak dlouho, dokud není operační paměť na obou stranách stejná. Poté se přesměrují požadavky na novou virtuální stanici a původní je vypnuta. Quick migration slouží také k přemístění virtuálního stroje z jednoho serveru na druhý, ale již to není řešení bezvýpadkové. Virtuální stroj je vypnut na původním hostiteli, operační paměť překopírována na druhého hostitele a virtuální stroj je zase zapnut. V některých případech se tento starší typ přesunu hodí pro virtuální stroje, které pracují intenzivně s operační pamětí. Live migration může trvat i hodiny, protože stále vznikají rozdíly, které se nestíhají dokopírovávat. Toto řešení sice způsobí krátký výpadek dostupnosti, ale přesun virtuálního stroje může být v závislosti na velikosti operační paměti a rychlosti síťového připojení v řádech jednotek minut. Storage migration slouží k přemístění virtuálního disku, který používá virtuální stroj mezi rozličnými diskovými poli. Memory balooning umí přerozdělovat operační paměť mezi spuštěnými virtuálními stroji. Hypervisor nemůže zjistit, jak moc je operační paměť přidělená virtuálnímu stroji využívána. Při nedostatku volné paměti hypervisor posílá příkaz virtuálnímu stroji, aby se vzdal paměti, kterou nevyužívá. Tato operační paměť může být nabídnuta jinému virtuálnímu stroji, který ji potřebuje. (16) Memory compression je metoda pro práci s pamětí. Místo swapování na pevný disk se využije komprese a komprimované stránky se uloží do operační paměti. Pomocí této metody lze uložit do paměti více dat, než je její fyzická velikost. Nevýhodou je zpomalení oproti klasické operační paměti, protože komprimace a dekomprimace zabere čas. Výhodou je až o několik řádů vyšší rychlost než při swapování na pevný disk. (16) 33

2. Virtualizační nástroje Transparent Page Sharing má za úkol zajistit, zda virtuální stroje nepoužívají obsahově identické kusy operační paměti. Toto může nastat, když jsou spuštěny stejné operační systémy, programy nebo se pracuje se stejnými uživatelskými daty. Pokud hypervisor zjistí, že jsou nějaké stránky stejné, tak se do fyzické operační paměti uloží pouze jedna kopie. Shodnost dat se kontroluje na základě hashe. Pokud je potřeba udělat změna na sdílené paměti, tak je vyvolána vyjímka, následně je vytvořena kopie sdílené části a tato kopie je přiřazena virtuálnímu stroji, který může bezpečně provést změny. Tato funkce ztrácí trochu na důležitosti s novými operačními systémy, které mají velké stránky a tím pádem je složitější najít shodu. (16) Vysoká dostupnost se používá u serverů spojených v clusteru, což je seskupení minimálně dvou nodů k zajištění vysoké dostupnosti služeb. Ve světě virtualizace a obzvlášť serverové virtualizace je téma vysoké dostupnosti a clusterů velice důležité. Ztráta způsobená z důvodu hardwaravé chyby je umocněna počtem virtuálních serverů, které na daném fyzickém stroji byly provozovány. Z těchto důvodů se cluster považuje za nedílnou součást při stavbě virtuální serverové infrastruktury. Všechny fyzické servery jsou spojeny s další sítí, přes kterou je vysílán takzvaný heartbeat signál, který má za úkol zjistit, zda nějaký nod nepřestal fungovat. Pokud dojde k výpadku, tak postižené virtuální stroje jsou spuštěny na ostatních funkčních nodech a poskytování služby pokračuje. Při návrhu vysoké dostupnosti je důležité zajistit zálohy serverů, vysokou dostupnost sdíleného diskového prostoru a síťového připojení k uživatelům dané služby. Snapshot je zajímavou funkcí, která slouží k uložení stavu virtuálního stroje v určitém čase. V okamžiku vytvoření snapshotu vznikne vedle každého VHD souboru použitého ve virtuálním serveru ještě AVHD soubor. Do toho se začnou ukládat všechny změny oproti VHD souboru od okamžiku vytvoření snapshotu. VHD soubor je od tohoto okamžiku neměnný. Kdykoli je možné vrátit se do původního bodu se všemi daty a nastavením, které bylo ve virtuálním počítači uloženo. Tato funkce se výborně hodí pro testování softwaru nebo provádění aktualizací systému. Nevýhodou je zpomalení systému. Tabulka 2.2 zobrazuje přehled nejdůležitějších funkcí, které virtualizační nástroje nabízejí. Je vidět, že rozdíly mezi jednotlivými produkty nejsou velké, ale liší se pouze v detailech. Na první pohled je ale relativně malá podpora operačních systémů ze strany HyperV. Microsoft pojmem podporované systémy označuje pouze ty systémy, pro které jsou v případě problémů schopny dodat podporu jak ze strany hypervisoru, tak ze strany operačního systému, který je virtualizován. VMware a Citrix nabízí podporu pouze ze strany hy34

2.5. Přehled klíčových vlastností

Podporované systémy

Centrální správa Live migration Storage gration

Mi-

Paměťové funkce Vysoká dostupnost Snapshots

vSphere Hypervisor Windows 95, 98, ME, XP, Vista, 7, Server 2003, 2008, Red Hat Ent. Linux 5.2-5.7, 6.0, 6.1; CentOS 5.2-5.7, 6.0, 6.1; SUSE Linux Ent. Server 10, 11; Oracle Linux 5.0-5.8; Mac OSX 10.7.2, 10.7.3 a další vCenter Server

HyperV

XenServer

Windows XP SP2, XP SP3, Vista, 7, Server 2003, 2008, Red Hat Ent. Linux 5.2-5.7, 6.0, 6.1; CentOS 5.2-5.7, 6.0, 6.1; SUSE Linux Ent. Server 10, 11

Windows XP SP2, XP SP3, Vista, 7, Server 2000, 2003, 2008, Red Hat Ent. Linux 3.6-6.0, 6.0, 6.1; CentOS 4.5-4.7, 5.2-5.6, 6.0; SUSE Linux Enterprise Server 10, 11; Debian 5, 6 a další

SCVMM

Ano - vMotion

Ano - Live Migration S malým výpadkem - Quick Storage Migration Dynamic Memory

XenCenter a SCVMM Ano - XenMotion

Ano - Storage vMotion Balooning, compression, transparent page sharing Ano - VMware HA Ano

Ano - Microsoft Failover Cluster Ano

Ne

Dynamic Memory Control Ano - XenServer HA Ano

Tabulka 2.2: Porovnání funkcí hypervisorů

pervisorů. V případě chyby na straně operačního systému odkazují na jeho výrobce.

35

Kapitola

AMD Bulldozer Bulldozer je kódové jméno nejnovější platformy procesorů společnosti AMD, která byla vydána v říjnu roku 2011. Při vývoji se nenavazovalo na starší projekty, ale začínalo se od čistého papíru. Toto byla první radikální přeměna procesorů AMD od roku 2003, kdy byly představeny Athlon 64 a Operon. AMD hodlá procesory postavené na architektektuře Bulldozer nahradit procesory Athlon a Phenom ve skupině osobních počítačů a procesory Opteron v třídě serverových počítačů. Bulldozer je první procesor vyráběný 32nm výrobním procesem od firmy AMD. Distribuovány jsou v konfiguraci 4, 6, 8 a 16 jader na jednom čipu. Silnou stránkou Bulldozeru jsou instrukční sady. Jedná se především o instrukční sady SSE 4.1 a 4.2, AVX (Advanced Vector eXtensions), AES-NI (šifrování), FMA4 (FMAC), XSAVE nebo XOP. Celkově tato architektura poskytuje vysoký výkon pro široké spektrum aplikací. AMD se také zaměřilo na řízení spotřeby. Důležitou funkcí je Turbo Core 2.0, které dokáže měnit pracovní frekvenci procesoru podle zatížení a TDP procesoru. Pokud je příkon pod stanovným TDP, může být v případě potřeby zvýšena frekvence na zatížených jádrech. Podporována je hned dvojice Turbo frekvencí. Další úspornou funkcí je takzvaný power gating, který umí odpojit od elektrické energie nepoužívané výpočetní jednotky procesoru nebo celá jeho jádra.

3.1

Architektura

Nové platformy počítačů se již nespoléhají na vysoký výkon jednoho jádra, ale používají paralelní zpracování více instrukcí. Tohoto lze dosáhnou několika způsoby: CMP je první varianta, kde každé vlákno má své vlastní výpočetní jádro. Všechna vlákna se vykonávají stejně rychle a s maximálním výkonem. Na obrázku 3.1 je naznačeno použítí dvou jader, které zpracovávají dvě 37

3

3. AMD Bulldozer

Obrázek 3.1: Porovnání typů vícevláknového zpracování (1)

vlákna paralelně. V takovémto případě dostáváme dvojnásobný výkon oproti jednoprocesorovému systému. Toto řešení je vykoupeno vyššími náklady, protože dvě plnohodnotná jádra zaberou více místa na čipu a spotřebují více energie. Tento model používají například procesory rodiny Phenom od firmy AMD. SMT představila pod názvem Hyper-Threading společnost Intel u procesoru Pentium 4. Tato technologie umožňuje paralelní zpracování dvou vláken jedním jádrem. To je docíleno tím, že každé vlákno využívá jinou část procesoru, která by za normálního stavu zahálela. Z principu je jasné, že pokud se sejdou dvě instrukce využívající například aritmeticko-logickou jednotku, která je v procesoru pouze jedna, tak hyperthreading nebude využit a zpracováváno bude pouze jedno vlákno. Pro funkčnost se musí ve vlastním procesoru provést úpravy v oblasti sledování následující instrukce, zásobníku a registrů, protože pro zpracování dvou vláken je nutné zachovat integritu výpočtů. (9) Teoreticky získáme oproti klasickému procesoru výkonovou výhodu až 30%, ale praktické testy naznačují spíše zlepšení kolem 16%. (5) 38

3.1. Architektura

Obrázek 3.2: Architektura AMD Bulldozer (3)

CBM je třetí možností, kterou právě využívá AMD v modulární architektuře Bulldozer. Hlavní jednotkou je modul obsahující dvě výpočetní jádra, která sdílejí výpočetní jednotku pro práci s plovoucí desetinou čárkou a cache. Takové jádro je levnější, jelikož zabere méně místa (druhé jádro v modulu zabere pouze 13% plochy navíc) a spotřebuje méně energie. Daní je samozřejmě nižší výkon oproti CMP. Pro podrobnější popis architektury AMD Bulldozer nejlépe poslouží obrázek 3.2, na kterém je zobrazen detail jednoho modulu, ze kterého je výsledný procesor vytvořen. Instrukce z instrukční cache, která je sdílená 64KB pro obě jádra míří do sběrače (Fetch), který je schopen pojmout celkem čtyři za takt a přeposlat je k dekodéru (Decode). V dekodéru se převedou x86 instrukce do RISC instrukcí, se kterými pracují všechny dnešní procesory. Dekódování složitějších instrukcí zabere více strojových cyklů, protože se musí převést do několika mikroinstrukcí. Zatímco jednoduché instrukce jsou většinou převedeny v jednom cyklu. Poté co jsou instrukce dekódovány, jsou poslány do příslušného plánovače (Scheduler). Dle AMD převažují celočíselné operace, proto si každé jádro zachovalo vlastní celočíselný plánovač, dvě symetrické instrukční aritmetickologické jednotky, dvě jednotky pro generaci adres (pipeline) a L1 DCache. 39

3. AMD Bulldozer K většímu využití samotných pipeline napomáhá technologie, kterou Intel používá již dlouhou dobu a to slepování operací (Branch Fusion). Více operací se tak dá spojit a dekódovat jako jedna. Plánovače a pipeline pro výpočty v plovoucí desetinné čárce jsou sdílené oběma jádry, podobně jako 2MB L2 cache. Zajímavostí je pak možnost spojit obě 128bitové pipeline do virtuální 256bitové a počítat s vyšší přesností. V praxi to znamená možnost využít nových instrukcí FMAC4, které jsou vhodné k rozsáhlým aritmetickým operacím. Na úrovni celého čipu je pak sdílena L3 cache a funkce severního můstku. Jednou z funkcí severního můstku je paměťový řadič. Je od základu přepracován a nyní podporuje operační paměti DDR3-1600. K připojení dalších periferií má každý čip tři HyperTransport 3.0 linky.

3.2

Virtualizace

Pro naši práci nás především zajímá hardwarová podpora virtualizace. Jako všechny dnes vyvíjené procesory, tak i Bulldozer přichází s funkcemi, které mají za úkol zlepšit výkon a zajistit větší bezpečnost virtualizace. Blíže představíme ty, které platforma Bulldozer využívá: AMD-V je rozšíření architektury AMD64, které zavádí dva módy - host a guest. V módu host je spuštěn hypervisor a v módu guest jsou spuštěny virtuální stroje. Hypervisor je přesunut do Ring-1 a virtuální stroje jsou spuštěny v Ring0. Tím pádem operační systémy mají stejná práva jako na nevirtualizovaném systému. Bezpečné instrukce jsou spušteny přímo a krtické instrukce jsou řešeny vyvoláním výjímky VMexit. Ta předá řízení hypervisoru, který instrukci provede a vyvoláním VMentry vrátí řízení zpět virtuálnímu stroji. Přepínání mezi virtuálním strojem a hypervisorem může zabrat až stovky cyklů procesoru, a proto se počet těchto cyklů snaží výrobci snížit. Tagged TLB slouží k rychlejšímu přepínání mezi virtuálními stroji. To je docíleno tím, že je udržována pro každý virtuální stroj vlastní TBL tabulka (TBL tabulka slouží k udržování adres naposled přistupovaných kusů paměti). Protože se při přepínání mezi virtuálními stroji tyto tabulky neresetují, tak nedochází pokaždé k načítání hodnot a přístup do paměti je rychlejší. AMD-RVI je technologie, která umožňuje překlad virtuálních adres na fyzické. Bez technologie AMD-RVI si hypervisor udržuje tabulku sPT (shadw page table), ve které je namapována paměť virtuálního stroje na fyzickou virtuální paměť. Do této tabulky nemůže virtuální stroj přistupovat a proto si vede svojí tabulku gPT (guest page table). Hyper má za úkol sledovat změny v gPT tabulce a zapisovat je do sPT tabulky. Pro 40

3.3. Zhodnocení udržování konzistence gPT a sPT existují dvě metody, které zde nebudeme detailně popisovat, ale ve výsledku jsou obě pomalé. S AMD-RVI je zavedena takzvaná NPT (nested page table), kterou spravuje virtuální počítač a ve které je uveden přímo překlad virtuální adresy na fyzickou adresu. Hypervisoru odpadá starost se synchronizací a virtuální stroj může přistupovat přímo do paměti. (2) AMD Extend migration řeší problém migrace virtuálních strojů mezi různými verzemi procesorů AMD. Starší verze nemusí vždy umět všechny instrukce, jako umí verze nové. Jedním řešením je překlad těchto rozdílných instrukcí, což není příliš často využíváno, protože přináší zpomalení systému. Častějším řešením je zpřístupnit pouze ty instrukce, které umí všechny fyzické počítače, mezi kterými může migrace probíhat. AMD-Vi někdy také označováno jako AMD IOMMU (input/output memory management unit), která dokáže přemostit hypervisor a přiřadit virtuálnímu stroji přímý přístup k fyzickému zařízení (síťová karta, grafická karta a řadiče disku). Tento přístup je možný skrze DMA a přemapování přerušení.

3.3

Zhodnocení

Na závěr bych shrnul výhody, které tato nová architektura přináší. • Vyrovnání spotřeby elektrické energie s konkurenčními procesory. • Velice dobrý výkon ve zpracování vícevláknových aplikací, díky použítí modulů. Toto je důležité pro virtualizaci, v níž tento typ zátěže převažuje. • Modulární architektura umožňuje jednoduchou výměnu jakékoli součásti procesoru, což je dobré pro budoucí vývoj. • Lze koupit serverový procesor až se 16 jádry (8 modulů). Může ušetřit nemalé peníze při licencování softwaru formou per socket. • Příznivá cena. A nesmíme zapomenout ani na nevýhody. • Problém s dostupností. • Průměrný výkon v jednovláknových aplikacích. • Intel v polovině roku 2012 začne prodávat novou architekturu jejich procesorů, které budou založeny na 22nm výrobním procesu s vylepšeným výkonem a spotřebou elektrické energie.

41

Kapitola

Testování Pro objektivní srovnání výkonosti jednotlivých hypervisorů provedeme sérii testů, které nám poodhalí rozdíly výkonu mezi jednotlivými výrobci. Do souboru testů zahrneme testy výpočtů čísel celých a s plovoucí desetinnou čárkou, výpočet prvočísel a rychlost práce s operační pamětí. Nejprve testy provedeme na nevirtualizovánem stroji, abychom získali výsledek, ke kterému můžeme vztahovat ostatní výsledky. Poté testy provedeme na virtualizovaném stroji a to ve stavu, kdy bude k dispozici dostatek hardwarových prostředků. Nakonec provedeme testy přetíženého systému.

4.1

Výběr testovacích nástrojů

V dnešní době je nepřeberné množství všech možných testovacích softwaru. Dokonce existují dva speciální programy na testování virtualizace v serverech. První pochází od firmy VMware a jmenuje se VMmark, který používá kombinaci open source a komerčních programů v jednotlivých virtuálních strojích. Například je použit Apache HTTP Server nebo Microsoft Exchange Server. Nevýhodou je ale možnost testovat pouze virtualizaci postavenou nad vSphere Hypervisorem. Minimální hardwarové požadavky na spuštění je dvounodový cluster, čtyři logická jádra na jeden nod a 27GB operační paměti. Takovéto požadavky jsou úplně mimo naše možnosti. (18) Druhý specializovaný nástroj SPECvirt_sc2010, který provádí testování spouštěním takzvaných tiles, což je skupina šesti virtuálních strojů, mezi které se rozdělí těchto šest rolí: podpůrný server, webový server, mailový server, aplikační server, databázový server a nezatížený server. Nevyjšší výkon systému je zjištěn postupným spouštěním více tiles, dokud se nedosáhne hranice, kdy se nezlepšují naměřené hodnoty, či jsou překročeny QoS metriky. Tento program není pro naše testování vhodný, protože je určen pro testování velkých virtualizačních řešení a v neposlední řadě je prodáván pro akademické účely za $1500. (14) 43

4

4. Testování Když ani jeden z těchto profesionálních nástrojů nepřipadal v úvahu, tak jsme si definovali klíčové vlastnosti, co by měl námi hledaný testovací program umět. První byla možnost provádět jednotlivé testy nejvíce zatěžovaných komponent v serverech - procesor, operační paměť a pevný disk. Druhým byla podpora nejrozšířenějšího serverového operačního systému Microsoft Server 2008. Dále bylo otázkou, zda jít cestou několika různých programů, pro testování jednotlivých komponent, či vybrat jeden komplexní. Po prozkoumání jednotlivých hledisek jsme se rozhodli pro program PerformanceTest od společnosti Passmark, který kombinuje zátěžové testy pro všechny důležité komponenty, které jsme jmenovali výše s oficiální podporou operačního systému Windows Server 2008.(13) Tento produkt je distribuován jako shareware trial na 30 dní, což na jednorázové testování bohatě dostačuje. Z celého balíku jsme vybrali tyto testy: Procesor výpočty s celými čísly, výpočty s plovoucí desetinnou čárkou, komprese a enkrypce. Operační paměť alokace malých bloků, čtení cachované paměti, čtení necachované paměti a zápis. Pevný disk sekvenční zápis, sekvenční čtení, náhodné čtení a zápis.

4.2

Postup provádění testů

Prováděné testy lze rozdělit na dva typy. Jeden je porovnání výkonu nevirtualizovaného stroje se všemi virtualizačními platformami. Druhý je test přetížení hardwaru, který nám ukáže, jak si dokáží poradit hypervisory s nedostatkem fyzických zdrojů. Nejprve provedeme celou sadu testů na nevirtualizovaném operačním systému Windows Server 2008 R2. Toto měření bude sloužit jako laťka nejvyššího možného výkonu. Poté postupně nainstalujeme jednotlivé virtualizační nástroje, provedeme základní konfiguraci, aby byly dostupné pro vzdálenou administraci pomocí programů dodávaných výrobcem. Nejprve spustíme jeden virtuální stroj, kterému přidělíme maximum fyzických prostředků a budeme sledovat, jak velký je propad výkonu oproti klasicky instalovanému systému a jak si vedou jednotliví výrobci mezi sebou. Při druhém testu spustíme tři virtuální stroje, kdy každému přiřadíme dva procesory a 3 GB operační paměti (v HyperV a XenServeru nastavíme dynamockou paměť na rozpětí 1,5 - 3 GB). Na dvou virtuálních strojích spustíme daný test v programu PassMark na délku 60 sekund a ve třetím spustíme na 20 sekund. Ze třetího virtuálního stroje budeme odečítat výsledky. Touto metodou bude zajištěno, že bude opravdu vytěžována daná komponenta na maximum po celou dobu daného testu. Hypervisor bude pod velkým tlakem a bude zajímavé ho sledovat. Abychom měli další srovnání, tak celou sadu 44

4.3. Testovací sestava Název sestavy Procesor Operační pamět Pevný disk DVD mechanika Zdroj

HAL3000 Platinum 8416 AMD FX-4100, 4 jádra (2 moduly), 3,6Ghz, 12MB cahce, socket AM3+ KINGMAX DDR3, 6GB, 1333MHz Samsung SpinPoint T HD403LJ, 400GB, 7200ot/min, 16M cache SAMSUNG DVD-R/-RW/RAM SH-S222AB SATA CHIEFTEC ANP-355A12 355W

Tabulka 4.1: Konfigurace testovací sestavy

testů spustíme pouze na jednom virtuálním stroji se stejným početem procesorů a velikostí operační paměti. Tím získáme představu o propadu výkonu přetíženého stroje oproti nepřetíženému. Každé měření provedeme třikrát, čímž snížíme statistickou odchylku a vypočteme průměr. Výsledné hodnocení všech tří virtualizačních platforem zaneseme do grafu a slovně zhodnotíme.

4.3

Testovací sestava

Testy byly prováděny na sestavě od firmy HAL3000. Tato sestava byla určena do domácího segmentu se zaměřením na multimedia a hry, což se diametrálně líší od serverového zatížení. Nám šlo především o otestování procesoru založeného na architektuře AMD Bulldozer a o porovnání tří virtualizačních produktů. Oba dva požadavky tato sestava splňovala. Přesný seznam komponent, kterými byla sestava osazena, je uveden v tabulce 4.1.

4.4

Příprava na testy

Zde si popíšeme, jak probíhala instalace, nastavení a vytváření virtuálních strojů v jednotlivých virtualizačních nástrojích. Popíšeme si problémy, na které je možné narazit a jak jsme tyto problémy řešili.

4.4.1

Citrix XenServer

Jako první jsme si vybrali virtualizační nástroj XenServer, který je v základní verzi možné stáhnout z oficiálních webových stránek Citrixu. Instalace je velice rychlá a vyžaduje pouze pár základních informací, jako je heslo správce, cílový disk, zeměpisné informace, nastavení sítě a zda se má instalovat Linux pack, který je nutný pro virtualizování operačních systémů Linux. Citrix ve svých reklamích materiálech popisuje délku instalace sloganem „Ten minutes to XenServer“, což lze potvrdit. 45

4. Testování

Obrázek 4.1: XenCenter

Na instalovaném počítači je možné provádět základní natavení sítě a diagnostiky, prohlížní logů a virtuálních strojů. Pohodlnější a pokročilá správa se provádí přes síťové připojení z jiného počítače pomocí nástroje XenCenter. Uživatelské rozhraní tohoto programu je dobře navrženo, ovládání je jednoduché a intuitivní. Přes tento program je možné založit virtuální stroj a nainstalovat Windows Server 2008 R2 SP1. Instalace operačního systému probíhala srovnatelně rychle s normálním počítačem. Po instalaci byly doinstalovány XenTools, které slouží pro lepší výkon ovladačů. Po provedení aktualizace operačního systému a instalace testovacího programu lze ze stroje jednoduše vytvořit šablonu. Pomocí šablony byla otázka několika minut vytvoři tři stejné stroje, které byly potřeba pro testvání přetížení hardwaru. Pro toto testování byla potřeba funkce dynamic memory, která umožnuje dynamické přidělování operační paměti mezi virtuálními stroji. Jelikož tato funkce se nachází až ve vyšších edicích XenServeru, tak jsme byli nuceni jít cestou trial verze, která je řešena stažením takzvané Trial Virtual Appliance. To je virtuální počítač, který po spuštění funguje jako licenční server. Poté stačí vyplnit IP adresu tohoto virtuálního licenečního serveru a v XenServeru jsou povoleny na omezení počet dní nadstandartní funkce.

4.4.2

VMware vSphere Hypervisor

Druhý v pořadí byl instalován vSphere Hypervisor. Jedná se o bezplatnou edici, která nabízí omezené funkce. Její obraz je možné stáhnout zdarma z oficiálního webu VMwaru. Instalace samotného hypervisoru probíhála také rychle a vyžadovala pouze heslo administrátora. Poté bylo možné spustit systém a objeví se nám DCUI, což je administrační prostředí, ve kterém můžeme pouze změnit nastavení síťe a prohlédnout 46

4.4. Příprava na testy

Obrázek 4.2: VMware vSphere Client

logy. Dalším krokem bylo připojení se přes program VMware vSphere Client, přes který je možné dělat administrátorské úkony. Tento program nabízí největší možnosti nastavení a mnohem důkladnější monitorování systémových prostředků serveru. Instalace virtuálních strojů byla komplikovanější. Jelikož šablony jsou podporované až v placených edicích, bylo tedy nutné instalovat všechny tři virtuální strojě ručně. Instalace byly spuštěny paralelně. První virtuální stroj se nainstaloval po třech hodinách a poslední po pěti. Je pochopitelné, že instalace tří instancí zabere více času, což je dáno použítím stejného instalačního média. Nejdéle z celé instalace trvala fáze rozbalování souborů, které by měly být již nahrány na pevný disk. Nakonec byly nainstalovány VMtools, který také zlepšují výkonost ovladačů a přidávají integraci myši s přetahováním souborů do virtuálního stroje a zpět.

4.4.3

Micrososft HyperV Server

Poslední byla provedena instalace Micrososft HyperV Server. Tato zjednodušená verze byla zvolena ze dvou důvodů. První důvod je cena, protože Microsoft ho nabízí zdarma. Druhý důvod je, aby bylo srovnání férové a nezpomaloval ho běh plného Windows Serveru, který by zabíral více systémových prostředků. Instalace probíhala stejným způsobem jako instalace Windows Serveru 2008. Po spuštění systému nás uvítá klasická přihlašovací obrazovka systémů Windows. Po přihlášení se otevře pouze klasická konzole. V našem případě nebyla rozpoznána síťová karta a bylo nutné ručně doinstalovat ovladače. Pro vzdálenou administraci bylo potřeba doinstalovat RSAT (Remote Server Administration Tools) na jiný PC v síti. Jedním z nástrojů toho balíku je HyperV Manager, který se dokáže připojit k HyperV Serveru a spravovat ho. Pro na47

4. Testování

Obrázek 4.3: HyperV Manager

stavení stanice a serveru lze použít skript, který je možné stáhnout i s popisky z webu (8). Po zprovoznění spojení bylo možné z HyperV Manageru vytvářet nové virtuální stroje a spravovat je. Problém nastal při pokusu o spuštění virtuálního stroje, kdy HyperV Manager hlásil chybu, že virtuální stroj nemůže být spuštěn, protože není spuštěn hypervisor. Problém byl způsoben tím, že HyperV neumí pracovat s novou instrukční sadou AVX, kterou procesory AMD Bulldozer obsahují. Microsoft vydal hotfix (17), který tuto chybu odstraňuje. Poté již bylo možné přidávat virtuální stroje a instalovat na ně operační systém. Instalace operačního systému probíhala rychle a bez problémů. Při instalaci operačního systému Windows Server 2008 R2 SP1 se zrovna samy nainstalovaly integrační komponenty.

4.5 4.5.1

Výsledky testů Porovnání výkonu virtualizovaného systému s nevirtualizovaným

Prvním typem testů je porovnání všech blíže představovaných produktů mezi sebou a s nevirtualizovaným systémem. Výkon nevirtualizavaného serveru je v grafu znázorněn jako 0%, výsledky ostatních produktů jsou k tomuto výsledku vztaženy a přepočítány na procenta. 4.5.1.1

Procesorové testy

V testech procesorového výkonu můžeme vidět nevyrované výkony XenServeru a vSphere Hypervisoru. První jmenovaný ztrácí zejména při výpočtu s celými čísly a především trpí velkým propadem ve výpočtech s plovoucí desetinou čárkou. V testech komprese, kryptování a řazení řetězců je naopak výkonějšší 48

4.5. Výsledky testů

Obrázek 4.4: Porovnání virtualizačních platforem s fyzickým serverem v procesorových testech

než nevritualizaovaný systém. Podobnou tendenci má vSphere Hypervisor, který ale netrpí tak velkými propady při počítní s plovoucí desetinnou čárkou. HyperV podává ve všech testech stejný výkon bez většího výkyvu. 4.5.1.2

Paměťové testy

Obrázek 4.5: Porovnání virtualizačních platforem s fyzickým serverem v paměťových testech U testů operační paměti jsou zajímavé rychlejší výsledky virtualizovaných systémů oproti nevirtualizovanému systému. Tento jev si vysvětlujeme tím, že virtuálnímu stroji byla přiřazena maximální velikost fyzické paměti, od 49

4. Testování které byla odečtena paměť spotřebovaná hypervisorem. Tím pádem virtuální stroje pracovaly s měnším rozsahem než nevirtualizovaný stroj. Jasným vítězem v této sekci je XenServer, který je ve všech testech bezkonkurenčně nejrychlejší. U práce s velkými paměťovými bloky nastává velký propad u vSphere Hypervisor, který je pravděpodobně způsben použitím paměťových technologií, které potřebují pro svoji práci výpočet ze strany procesoru.

4.5.1.3

Diskové testy

Obrázek 4.6: Porovnání virtualizačních platforem s fyzickým serverem v testech pevného disku U testů pevného disku nedošlo k žádným překvapením a všechny virtualizační nástroje ztrácí na nevirtualizovaný systém. Nejlepší výsledky podává vSphere Hypervisor. Nejvyrovnanjší výsledky předvádí XenServer.

4.5.2

Porovnání výkonu přetížených virtualizačních systémů

Druhým typem je přetížení zdrojů. V níže uvedených grafech najdeme vždy danou virtualizační platfromu, na které jsou spuštěny tři virtuální stroje (přetížení) a poté jeden virtuální stroj. To proto, abychom viděli, jak velký propad nastane.

4.5.2.1

Procesorové testy

Výkonost platformy XenServer a HyperV je při přetížení procesoru podobná. Průměrný propad oproti jednomu stejně výkonému stroji je u HyperV 42% a u XenServeru 44%, což je citelná ztráta. Naopak vSphere Hypervisor v těchto testech se ukazuje v dobrém světle. Průměrný propad ve výkonu je 22%, což je poloviční propad oproti soupeřům. 50

4.5. Výsledky testů

Obrázek 4.7: Porovnání přetížených systémů v procesorových testech

4.5.2.2

Paměťové testy

V prvních čtyřech testech operační paměti jsou výsledky všech produktů víceméně stejné a nezaostávají ani přetížené systémy. Je vidět, že přístup do paměti není problém ani při velkém zatížení. Porovnatelné výsledky přetíženého a nepřetíženého stroje lze vysvětlit na straně HyperV, s XenCentru tak, že používají dynamickou paměť, takže nikdy se nepracuje s více operační paměti než je fyzicky k dispozici. O to zajímavější jsou výsledky vSphere Hypervisoru, který umožňuje přetěžování operační paměti a stejně jeho výsledky 51

4. Testování

Obrázek 4.8: Porovnání přetížených systémů v paměťových testech

jsou vyrovnané. V testu práce s velkými paměťovými bloky propadá přetížený vShere Hypevisor a překvapivě také HyperV a to jak přetížený, tak nepřetížený. 4.5.2.3

Diskové testy

HyperV vykazuje značné propady při sekvenčním čtení a při náhodném čtení a zápisu. Naopak dobré výkony podává vSphere Hypervisor. XenServer v přetížení dokonce při sekvenčním zápisu lehce převyšuje nepřetížený systém, ale 52

4.5. Výsledky testů

Obrázek 4.9: Porovnání přetížených systémů v diskových testech

tento jev bych spíše přiřadil statistické chybě. Při provádění přetížených testů byly všechny produkty neovladatelné a těžko odhadovat, zda a v jaké míře docházelo k přístupu jednotlivých virtuálních strojů k pevnému disku. Výsledky, které ukazují stejné hodnoty u stroje přetíženého i nepřetíženého jsou překvapivé. Na druhou stranu při použití virtualizace v produkčním prostředí nejsou použity klasické pevné disky, ale většinou je použito sdílené datové úložiště, které je připojeno přes síť či FC. Výrobci úložišť přímo spolupracují s výrobci virtualizací, tak aby bylo dosaženo optimálního výkonu.

53

Závěr Cílem této práce bylo seznámit se s principiálním fungováním virtualizace, popsat produkty nejrozšířenějších poskytovatelů serverové virtualizace a představit novou procesorovou architekturu Bulldozer. Na závěr provést testy blíže popisovaných virtualizačních nástrojů na stroji, který byl osazen novinkou od společnosti AMD. V první kapitole jsme se zmínili o historii vývoje virtualizace, kdy vznikla, proč byla odsunuta do pozadí a proč se nyní vrací. Představili jsme si typy virtualizace, co je to hypervisor a jaké jsou výhody a nevýhody jeho různých architektur. Nakonec jsme zhodnotili klady, které nám nasazení virtualizace může přinést. Neopomněli jsme ani zápory, na které při návrhu virtualizačního řešení nesmíme zapomenout. Poté jsme si představili virtualizační produkty od firem VMware, Citrix a Microsoft. Znalosti z teoretické části jsme použili při detailním popisu jejich fungování. VMware jako průkopník od začátku vývoje spoléhá na postupné vylepšování a nyní je technologicky na špici. Citrix a Microsoft stavěli na stejných základech a liší se především v použitém rodičovském operačním systému. AMD Bulldozer je pokus AMD dohnat technologicky vyspělejší Intel a dostat se do popředí jak v desktopových tak i serverových procesorech. Zatímco pro domácí použíti byl výkon Bulldozeru trochu zklamáním, tak pro serverové využití se jeví jako zajímavá volba a to především díky použití velkého počtu jader na jednom fyzickém procesoru, výkonu při paralelním zpracování úloh, pokročilému power managementu a výhodné ceně. Nevýhodou je horší dostupnost a menší výkon v jednovláknových aplikacích. Celkově je serverová část procesorů AMD Bulldozer povedená a při stavbě nové serverové infrastruktury by měl být tento produkt brán jako možná alternativa. Poslední kapitola je zaměřena na syntetické testy, jejichž cílem bylo zjistit rozdíly ve výkonu jednotlivých virtualizačních platforem, propad výkonu virtualizovaného operačního systému oproti nevirtualizovanému a nakonec jak si poradí. Poté jsme provedli ještě jednu sadu testů, při níž jsme vytěžovali 55

Závěr více prostředků, než bylo fyzicky k dispozici. Tím jsme dostali hypervisor pod velký tlak. Ve srovnání virtualizovaného a nevirtualizovaného systému nebyl propad výkonu tak drastický. Nejlépe na tom byl vSphere Hypervisor. HyperV podával vyrovnaný výkon ve všech testech. XenServer naopak občas překvapil dobrými výsledky a občas znatelnými propady. Přetížení hardwaru nejhůře zvládal HyperV, který byl v několika testech i o polovinu pomalejší než soupeři. Výkonově vyniká zase vSphere Hypervisor, kterému v některých testech sekunduje XenServer. Přetížení hardwaru by mělo být použito pouze při dočasných výpadcích hardwaru nebo při instalaci aktualizací. Obecně je výkon virtualizačních platforem na velice dobré úrovni a není tak daleko od nevirtualizovaného stroje. Všechny námi probírané virtualizační produkty jsou použitelné v produkčním prostředí. VMware je nejpokročilejší a nejvýkonnější řešení, ale také cena produktů může být až několikrát větší než u konkurence. XenServer nabízí zajímavý výkon za rozumnou cenu, problém jsou občasné výkyvy výkonu. Výhodou HyperV je integrace s Windows Serverem a vyrovnaný výkon. V návaznosti na tuto práci by bylo možné provést syntetické testy na operačním systému Linux nebo provést reálné testy s použitím webového a mailového serveru. V průběhu letošního roku se chystá vydání operačního systému Windows 8 Server, který bude obsahovat HyperV ve verzi 3.0. Jistě by bylo zajímavé porovnat starou verzi, novou verzi a konkurenční produkty. Vhodné by bylo zužitkovat tyto převážně teoretické zkušenost při návrhu a implementaci reálného virtualizovaného systému.

56

Literatura (1) AMD Bulldozer procesory FX-8150 a 8120 v testu (1/2). Dostupné z WWW: (2) AMD Nested Paging. Dostupné z WWW: (3) A close look at AMD Bulldozer. Dostupné z WWW: (4) ESXi architecture. VMware. Dostupné z WWW: (5) How CPU Features Affect CPU Performance. Dostupné z WWW: (6) How does Xen work. XenSource. Dostupné z WWW: (7) Hyper-V Architecture. Microsoft. Dostupné z WWW: (8) Hyper-V Remote Management Configuration Utility. Dostupné z WWW: (9) Intel Hyper-Threading Technology overview. Intel. Dostupné z WWW: (10) Introducing VMware vSphere Hypervisor 4.1 - the free edition of VMware vSphere 4.1. Dostupné z WWW: 57

Literatura (11) Livecycle of Microsoft Products. Microsoft. Dostupné z WWW: (12) Magic Quadrant for x86 Server Virtualization Infrastructure. Dostupné z WWW: (13) PassMark PerformanceTest. PassMark. Dostupné z WWW: (14) SPECvirt_sc2010. SPEC. Dostupné z WWW: (15) Supported guest operating systems. Microsoft. Dostupné z WWW: (16) Understanding Memory Resource Management in VMware ESX Server 4.1. VMware. Dostupné z WWW: (17) Virtual machine does not start on a computer that has an AMD CPU that supports the AVX feature and that is running Windows Server 2008 R2. Dostupné z WWW: (18) VMware VMmark. VMware. Dostupné z WWW: (19) VMware vSphere 5.0 What is New and Exciting. Techhead. Dostupné z WWW: (20) When to expect Windows Server 2008 R2 RTM. Microsoft. Dostupné z WWW: (21) XenServer Revision History Table. Citrix Systems. Dostupné z WWW: (22) VMware Announces Support for 64-bit Computinge. VMware, 2004. Dostupné z WWW: (23) Support for guest OS paravirtualization using VMware VMI to be retired from new products in 2010-2011. VMware, 2008. Dostupné z WWW: 58

Literatura (24) Performance Best Practices for VMware vSphere 5.0. VMware, 2011. Dostupné z WWW: <www.vmware.com/pdf/Perf_Best_Practices_ vSphere5.0.pdf> (25) Popek, G. J.; Goldberg, R. P.: Formal Requirements for Virtualizable Third Generation Architectures. 1974. (26) Robin, J. S.: Analyzing the Intel Pentium‘s capability to support a secure virtual machine monitor. 1999.

59

Příloha

Seznam použitých zkratek API Application Programming Interface API Application Programming Interface AVHD Assisted Virtual Hard Disk CBM Cluster Based Multithreading CMP Chip Multiprocessor DAS Direct Attached Storage DMA Direct memory access FC Fibre Channel FCoE Fibre Channel over Ethernet HA High Availability iSCSI Internet Small Computer System Interface KBPS KBytes per second MBPS MBytes per second MOOPS Millions of Operation per second OPS Operation per second QoS Quality of Services SAS Serial Attached SCSI SCVMM System Center Virtual Machine Manager SMT Simultaneous Multithreading 61

A

A. Seznam použitých zkratek SSD Solid-state drive TDP Thermal Design Power TOPPS Thousand of Strings per second VHD Virtual Hard Disk VM Virtual Machine

62

Příloha

Výsledky testů

63

B

64 XenServer II. III. 751,8 749,7 2087,4 2089,1 1206,4 1205,9 5399 5419,6 16,3 16,3 3260 3102,2 4075,3 4060,5 1855,6 1850 1808,3 1806,4 1271,1 1319,6 1919 1911,1 56,3 56,1 54,5 56,9 2,37 2,48 Průměr 751,1 2091,6 1205,1 5397,7 16,3 3188,8 3958,5 1857,8 1810,7 1278,0 1917,4 55,8 55,7 2,4

I. 817 2567,9 1207,1 5415,7 16,2 3101,6 3986,9 1880,5 1806,4 1115,9 581,6 66,3 67 2,4

vSphere Hypervisor II. III. Průměr 818,9 818,4 818,1 2565,9 2540,7 2558,2 1200,3 1203,1 1203,5 5404,9 5407,6 5409,4 15,9 16,3 16,1 3155,3 3192,9 3149,9 3983,7 3195,1 3721,9 1875,1 1876,9 1877,5 1803,2 1791,3 1800,3 1165,7 1156,4 1146,0 682,7 583,6 616,0 66,1 65,7 66,0 66,8 67,3 67,0 2,4 2,4 2,4

Tabulka B.1: Výsledky testů porovnání virtualizovaný a nevirtualizovaný systémů část 1.

Počítání v celých číslech Výpočty s plovoucí desetinnou čárkou Hledání prvočísel Komprese Kryptování Řazení řetězců Alokace malých bloků Čtení cachované paměti Čtení necachované paměti Zápis do paměti Práce s velkými paměťovými bloky Sekvenční čtení Sekvenční zápis Náhodný čtení a zápis

I. 751,7 2098,2 1203,1 5374,6 16,3 3204,2 3739,7 1867,8 1817,4 1243,2 1922,2 55,1 55,6 2,43

B. Výsledky testů

65

HyperV II. III. 779,1 797,5 2627,3 2664 1104,4 1140,8 5159,1 5274,2 15,3 15,4 3222,7 3234,6 3128,7 3049,5 1792,8 1740,3 1610,4 1743,3 1086,6 1190,5 1673,6 1767,4 64,7 60 65,2 65,1 2,3 2,1 Průměr 789,7 2666,0 1126,8 5203,9 15,2 3224,9 3188,0 1774,3 1640,1 1116,9 1721,9 59,3 50,0 2,3

I. 826,7 2720,7 1150,9 5302 15,5 3313 3750,3 1871,4 1686,4 1196,8 1425,2 64,2 65,8 2,5

Bez hypervisoru II. III. 814,5 813,2 2713,8 2702,5 1152,2 1153 5303,3 5301,4 15,5 15,5 3199,8 3342,1 3879,1 3780,4 1816,1 1885,1 1688,1 1691,3 1186,2 1190,5 1429,1 1435,4 64,9 64,9 64,7 65,1 2,9 2,9

Tabulka B.2: Výsledky testů porovnání virtualizovaný a nevirtualizovaný systémů část 2.

Výpočty s celými čísly Výpočty s plovoucí desetinnou čárkou Hledání prvočísel Komprese Kryptování Řazení řetězců Alokace malých bloků Čtení cachované paměti Čtení necachované paměti Zápis do paměti Práce s velkými paměťovými bloky Sekvenční čten Sekvenční zápis Náhodný čtení a zápis

I. 792,6 2706,6 1135,2 5178,5 14,8 3217,4 3385,8 1789,7 1566,6 1073,7 1724,7 53,3 19,8 2,5

Průměr 818,1 2712,3 1152,0 5302,2 15,5 3285,0 3803,3 1857,5 1688,6 1191,2 1429,9 64,7 65,2 2,8

66 XenServer II. III. 247,5 246 703,2 700,9 529,8 530,4 1813,2 1818,9 5,4 5,4 1038,9 1042,5 3608,2 3621,5 1787,6 1817 1699,4 1692,1 1040,1 1055,4 794,9 792,4 52,7 25,6 57,4 56,8 1,1 0,8 Průměr 247,5 699,8 529,8 1807,1 5,5 1036,9 3602,2 1801,0 1698,7 1049,4 796,1 39,5 58,5 0,9

I. 357,2 1171,4 704,3 2443,7 7,2 1400,8 3385,2 1823,2 1808,3 1004 376 18,3 61,5 1,5

Tabulka B.3: Výsledky testů přetížených systémů část 1.

Počítání v celých číslech Výpočty s plovoucí desetinnou čárkou Hledání prvočísel Komprese Kryptování Řazení řetězců Alokace malých bloků Čtení cachované paměti Čtení necachované paměti Zápis do paměti Práce s velkými paměťovými bloky Sekvenční čtení Sekvenční zápise Náhodný čtení a zápis

I. 249 695,2 529,3 1789,1 5,6 1029,3 3577 1798,5 1704,7 1052,8 801,1 40,2 61,4 0,9

vSphere Hypervisor II. III. Průměr 350,6 357,2 355,0 1124,4 1164,3 1153,4 670,8 704,4 693,2 2380,5 2395,2 2406,5 6,8 7,2 7,1 1365,4 1305,5 1357,2 3399,7 3404,8 3396,6 1844,7 1850,1 1839,3 1802,3 1775 1795,2 982,7 988,3 991,7 474,2 445,6 431,9 61,5 58,3 46,0 58,4 55,1 58,3 1,4 1,3 1,4

B. Výsledky testů

67

HyperV II. III. 245 267,7 825,6 862,4 621,8 523,3 1516,2 2071,5 5,1 4,5 1015,3 986,1 3491 3473,9 1839,1 1831,6 1699,4 1677,8 1069,2 1011,8 424,1 421,7 18,8 17,5 65,2 58 0,9 0,92

Tabulka B.4: Výsledky testů přetížených systémů část 2.

Počítání v celých číslech Výpočty s plovoucí desetinnou čárkou Hledání prvočísel Komprese Kryptování Řazení řetězců Alokace malých bloků Čtení cachované paměti Čtení necachované paměti Zápis do paměti Práce s velkými paměťovými bloky Sekvenční čtení Sekvenční zápise Náhodný čtení a zápis

I. 234,9 860,4 598,1 1728,6 3,95 1017,2 3424,9 1835 1706,4 1086,4 421,6 9,5 51,5 0,85

Průměr 249,2 849,5 581,1 1772,1 4,5 1006,2 3463,3 1835,2 1694,5 1055,8 422,5 15,3 58,2 0,9

68 XenServer II. III. 450,7 448,5 1393,4 1394,2 960,7 966,6 3018,1 3013,4 8,3 8,4 1957,6 1983,8 4033,3 4054,9 1870,8 1875,3 1824,5 1833 1307,4 1243,8 857,1 863,1 55,9 55,8 56,7 56,5 2,4 2,4 Průměr 448,9 1390,6 957,4 3016,5 8,4 1968,0 4042,6 1881,3 1828,7 1264,5 862,1 55,8 56,6 2,4

I. 416,4 1777,4 987,1 3004,8 8,2 1720,2 3397,7 1840,2 1782 1137,7 1021,7 60,6 61,5 2,4

vSphere Hypervisor II. III. Průměr 481,9 482,1 460,1 1325,4 1774,7 1625,8 955,9 800,6 914,5 2957 3012,5 2991,4 8,3 8,3 8,3 1898 1934,6 1850,9 3373,5 3392,6 3387,9 1814,3 1881 1845,2 1748,5 1763,8 1764,8 1230,1 1149,3 1172,4 994,2 1023 1013,0 61,2 61 60,9 14,1 60,3 45,3 1,8 2,5 2,2

Tabulka B.5: Výsledky testů nepřetížených systémů část 1.

Počítání v celých číslech Výpočty s plovoucí desetinnou čárkou Hledání prvočísel Komprese Kryptování Řazení řetězců Alokace malých bloků Čtení cachované paměti Čtení necachované paměti Zápis do paměti Práce s velkými paměťovými bloky Sekvenční čtení Sekvenční zápise Náhodný čtení a zápis

I. 447,6 1384,2 944,9 3017,9 8,4 1962,5 4039,7 1897,9 1828,6 1242,3 866,1 55,8 56,7 2,4

B. Výsledky testů

69

HyperV II. III. 429,8 425,4 1666,8 1841,1 918,2 905,4 2828 2812,9 7,9 7,7 1876,9 1845,5 3508,1 3502,6 1848,6 1812,1 1737,6 1740,4 1069,2 1011,8 524 520,6 66,2 64,9 64,7 65,1 2,1 1,8

Tabulka B.6: Výsledky testů nepřetížených systémů část 2.

Počítání v celých číslech Výpočty s plovoucí desetinnou čárkou Hledání prvočísel Komprese Kryptování Řazení řetězců Alokace malých bloků Čtení cachované paměti Čtení necachované paměti Zápis do paměti Práce s velkými paměťovými bloky Sekvenční čtení Sekvenční zápise Náhodný čtení a zápis

I. 417,3 1853,3 887,8 2832,6 7,7 1651,1 3494,3 1853,5 1745,7 1086,4 527,4 64,4 64,1 1,9

Průměr 424,2 1787,1 903,8 2824,5 7,8 1791,2 3501,7 1838,1 1741,2 1055,8 524,0 65,2 64,6 1,9

Příloha

Obsah přiloženého CD

readme.txt........................................stručný popis prace thesis...........adresář se zdrojovými kódy práce ve formátu LATEX BP_kabrt_tomas_2012.pdf .............. text práce ve formátu PDF 71

C