Bankovní institut vysoká škola Praha Katedra Informatiky a kvantitativních metod Využití virtualizace pro malé a střední firmy Diplomová práce Autor: Bc. Jaroslav Moc Informační technologie a management Vedoucí práce: Ing. Jan Háněl Praha Duben, 2014
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, dne 27.04.2014 Jaroslav Moc
Poděkování Rád bych poděkoval vedoucímu mé diplomové práce Ing. Janu Hánělovi za odborné vedení a podnětné rady poskytnuté při psaní této práce. Dále bych chtěl poděkovat mé rodině za trpělivost a podporu během mého dosavadního studia a psaní této práce.
Anotace Cílem mé diplomové práce je popsat virtualizaci a virtualizační nástroje. Nejprve chci čtenáře seznámit s teorií virtualizace, s její historií, s jejími principy a možnostmi. Zaměřím se na dvě komerčně nejpoužívanější platformy od společností VMware a Microsoft. Dále připravím návrh řešení virtualizace tří virtuálních strojů na dvou fyzických serverech v CSV clusteru s možností replikace a zálohy těchto virtuálních strojů. V praktické části, pak porovnám výkony stejných virtuálních serverů, na virtualizačních platformách VMware a Microsoft. Klíčová slova: virtualizace, VMware, ESX, hyper-v, vsphere Annotation The objective of my diploma thesis is to describe virtuality and virtual tools. Firstly, I would like to familiarise the reader with virtuality theory, its history, principles and possibilities. I will be referring to the two most commercially used platforms from the VMware and Microsoft companies. Furthermore, I present a virtualization solution proposal of three virtual machines on two physical servers in a CSV cluster with the possibility for the replication and back up of these virtual machines. Thereafter, in the practical part, I compare the capacities of the same virtual servers on the virtualization platforms, VMware and Microsoft. Key words: virtualization, VMware, ESX, hyper-v, vsphere
Obsah Obsah... 5 Úvod... 7 1. Co to vlastně je, ta virtualizace?... 8 1.1. Jak to vidí společnost Gartner... 8 1.2. Princip a definice serverové virtualizace... 10 1.3. Historie... 11 1.4. Přínosy virtualizace... 13 1.5. Vrstvy virtualizace... 19 2. Techniky serverové virtualizace x86... 22 2.1. Architektury hypervisorů... 22 2.2. Architektury procesorů... 24 2.3. Typy hypervisorů... 30 2.4. Typy virtualizace... 31 2.5. Technologie virtualizace... 39 2.6. Vysoká dostupnost... 45 3. Virtualizační platformy... 48 3.1. VMware nebo Microsoft?... 48 3.2. VMware... 55 3.3. Hyper-V... 56 4. Návrh řešení pro malé firmy... 59 4.1. Jak vybírat optimální řešení... 59 4.2. Výběr software... 63 4.3. Výběr hardware... 64 4.4. Sestavení nabídky... 67 5. Srovnání platforem VMware a Microsoft... 70 5.1. Použitý hardware... 70 5.2. Testovací software... 74 5.3. Plán testů... 75 5.4. Výsledky měření základní přehled... 77-5 -
5.5. Výsledky měření 1x Windows servery s 16GB... 94 5.6. Výsledky měření 1x, 2x a 3x servery 2008 a 2012 se 16GB a 8x CPU... 96 Závěr... 102 Seznam použité literatury:... 105 Seznam obrázků:... 108 Seznam zkratek:... 110 Seznam příloh:... 110-6 -
Úvod V IT prostředí jsem se začal pohybovat v roce 1993, kdy jsem nastoupil jako servisní technik do malé začínající firmy. Sestavoval a opravoval jsem počítače, tehdy s procesory i286/i386, operační pamětí 256kB, pevnými disky 20MB, operačním systémem MS-DOS 5.0 a s MS Windows 3.1. Tehdy realizované datové sítě, byly postaveny na sběrnicové topologii, pomocí koaxiálních kabelů, a serverový operační systém byl nejčastěji Novell 3.1, protože Windows server ještě neexistoval. Technologie jako failover cluster, nebo load-balancing také neexistovaly, anebo byly dostupné jen velkým společnostem. Teprve až s příchodem virtualizace a s jejím vyspěním, se objevují cloudové služby, a cluster i load-balancing se stávají součástí moderních serverových operačních systémů a jsou běžně dostupné i menším společnostem. Dnes jsou všude okolo nás používány informační systémy a to jak v institucích veřejné správy, tak i v malých a středních podnicích. Nároky na jejich provoz jsou ale stále vyšší, musí splňovat požadavky na stabilitu, bezpečnost, funkčnost a dostupnost, přičemž správná funkčnost těchto systémů je závislá nejen na lokálních správcích, ale také na zvolené platformě. V oblasti virtualizace, které se budu věnovat ve své práci, jsou dnes komerčně nejúspěšnější řešení od společností VMware a Microsoft, která blíže představím. Dále připravím návrh řešení virtualizace tří virtuálních strojů na dvou fyzických serverech v CSV clusteru s možností replikace a zálohy virtuálních strojů pro malou společnost. V praktické části, provedu instalaci virtualizačních platforem VMware a Microsoft na dvou fyzických serverech do CSV clusteru. Na každé platformě provedu instalaci a testování stejných virtuálních strojů, na kterých spustím stejnou sadu testů. Následně zjištěné výsledky testů porovnám, vyhodnotím s cílem vyhledat výrazné rozdíly a anomálie. Cílem této práce není popisovat postupy, které by bylo vhodné aplikovat na straně dodavatele nebo zákazníka, kterými jsou bezpečnostní politiky, business continuity management, change management, aplication management, nebo project management. I když právě toto bývá problém malých společností. Z praxe vím, že pokud malá společnost zálohuje a o zálohách si vede záznamy, je to velký úspěch. V tomto směru může být ve výhodě společnost, která má implementován např. systém managementu kvality ISO:9001 a má potřebné postupy zpracovány ve svých interních předpisech. - 7 -
1. Co to vlastně je, ta virtualizace? Jedná o postupy a techniky, které umožňují k dostupným fyzickým zdrojům přistupovat jiným způsobem, než jakým fyzicky existují. Jde tedy o metody jak oddělit uživatele HW od fyzických komponent a nabídnout jim jen virtuální přístup k hardware. Takto oddělení uživatelé se domnívají, že s daným hardwarem pracují jen oni a využívají ho bez ohledu na ostatní hosty - operační systémy. Virtualizace se v IT používá již dlouho, ať už se jedná o virtuální realitu, která simuluje prostředí skutečného světa anebo jen o virtualizaci fyzického hardware, např. vytvoření virtuální paměti, virtuálních sítí (VLAN), anebo virtuálních úložišť, které zastupuje technologie RAID (Redundant Array of Inexpensive/Independent Disks), což jsou metody jak zabezpečit data proti selhání pevného disku. Zabezpečení je zde řešeno rozmístěním dat na více fyzických disků, které se systému virtuálně zobrazují jako jeden. Dnes je možné virtualizovat jakýkoli operační systém i jakýkoliv HW včetně toho, který prozatím existuje pouze jako návrh, nebo je těžce dostupný. 1.1. Jak vidí virtualizaci společnost Gartner Lídrem ve virtualizaci serverové infrastruktury jsou podle zprávy společnosti Gartner zveřejněné v červnu 2013 společnosti VMware s vsphere 5.1 a Microsoft s Windows Server 2012 a System Center VMM 2012. Na obrázku 1 jsou Magic Quadranty virtualizační infrastruktury serverů x86 z let 2010 až 2013. Zde je zajímavé sledovat pohyb v kvadrantech u společností VMware a Microsoft. VMware se virtualizaci věnuje již od roku 1998, ale Microsoftu, který je na trhu virtualizace serverů od roku 2005, se daří trh úspěšně narušit, svého konkurenta pomalu dohání a zabírá stále větší podíl trhu. Situace se velmi podobá nástupu Microsoftu při dohánění společnosti Oracle v oblasti databázových serverů. Oracle je dnes sice hráčem číslo jedna z pohledu obratu, má největší instalace, ale podle počtu prodaných řešení je lídrem Microsoft. - 8 -
Obrázek 1 Vývoj Magic Quadrantu pro oblast virtualizační infrastruktury serverů x86 v letech 2010 až 2013 (zdroj: www.gartner.com) V září 2013 zahájil Microsoft prodej nové verze Windows serveru 2012 R2 a System Center 2012 R2 a tím se opět přiblížil k VMware. Později vyšel VMware s novou verzí 5.5. Takže uvidíme, jak bude Magic Quadrant vypadat v červnu 2014. - 9 -
1.2. Princip a definice serverové virtualizace V praxi existuje několik typů virtualizace. Pro pochopení principu je však nejjednodušší model tzv. plné virtualizace, při které dochází k plné simulaci hardware, což umožňuje běh operačních systémů bez úprav tak, jako by běžely přímo na fyzickém hardware. Tradiční architektura Virtuální architektura Obrázek 2 - Tradiční a virtuální architektura (zdroj: www.colestock.com) V tradiční architektuře je možné spustit pouze jeden operační systém. Ve virtuální architektuře je nad fyzickým serverem instalován hypervisor, např. VMware, který umožňuje spustit více virtuálních počítačů. Toto téma je podrobněji popsáno v kapitole 2. V roce 1974 pánové Gerald J. Popek a Robert P. Goldberg stanovili podmínky, které musí virtualizační architektura splňovat, aby ji bylo možné považovat za plnohodnotnou virtualizaci. Jedná se vlastně o definici virtualizace. [7] Efektivita - Všechny instrukce, které neohrozí provoz ostatních hostovaných OS, jsou vykonány hardwarem přímo bez zásahu hostitele. Tato podmínka odlišuje virtualizaci od emulace. Ekvivalence - Provoz aplikace ve virtuálním prostředí musí odpovídat provozu aplikace na fyzickém stroji. Fyzické prostředky vždy přiděluje hostitel, který má kontrolu nad všemi požadavky přicházejícími z hostovaných systémů, které předává dále ke zpracování. Není přípustné, aby aplikace ovlivňovala systémové prostředky hostitele. Správa zdrojů - Hostované operační systémy musí být vzájemně izolované, nesmí při svém chodu ovlivňovat ostatní hostované systémy, musí pracovat samostatně se svým hardwarem, procesorem, pamětí, diskovým prostorem a dalšími připojenými zařízeními. Architektury procesorů IA-32 a x86-64 nemají přímé prostředky pro tvorbu virtualizovaných prostředí, která by splňovala kritéria podle Popeka a Goldberga. - 10 -
1.3. Historie Pojem virtuální stroj resp. dříve pseudo stroj byl poprvé použit v polovině 60. let 20. století při práci na projektu společnosti IBM s experimentálním počítačovým systémem M44/44X. IBM měla za cíl zvýšit efektivnost a výkon svých mainframů a snažila se rozložit výkon do několika virtuálních strojů a zpracovávat tak více než jeden proces současně. [16] Počítač IBM 7044 (označen M44 ) byl počítač druhé generace, který simuloval více počítačů 7044 (označených 44X ). Z toho vzniklo označení M44/44X. [6] Druhou generaci tvořily počítače s tranzistorovými obvody, které vznikaly od druhé poloviny 50. let až do poloviny 60. let. Počítače byly vybaveny registry s tranzistorovými klopnými obvody a feritovými pamětmi. Vnější paměti a periferní jednotky měly již vlastní řídící jednotky pro připojení k základní jednotce a pro řízení přenosu dat. Operační rychlost počítačů s tranzistorovými obvody se pohybovala mezi 10 4-10 5 operacemi za sekundu. [13] Systém IBM M44/44X byl navržen, sestaven a provozován zaměstnanci IBM. Existoval pouze v laboratoři a nikdy nedošlo k jeho komerčnímu využití. Nicméně přinesl průlom ve způsobu práce s pamětí, v ukládání dat do sekundární paměti po blocích, v její virtualizaci, v konceptu virtuálních strojů a v měření výkonu počítačů. [16] Až později v projektu CP-40, byl termín pseudo-stroj trvale nahrazen termínem virtuální stroj. CP-40 byl první operační systém, který prováděl kompletní virtualizaci. Všechny IT zdroje byly virtualizované procesor, paměť i úložiště. Technicky byl CP (Control Program) a CMS (Cambridge Monitor System) první operační systém, který rozděloval svůj strojový čas mezi jednotlivé virtuální stroje. [3] [16] [20] I další vývoj v historii virtualizace nadále přinášela hlavně společnost IBM v projektech CP-67 a CP-370, která dosahovala ve své době velmi dobrých výkonových výsledků. Každý proces, který byl v počítači spuštěn, pracoval s iluzí vlastního procesoru. [16] [20] Od roku 1972, kdy byl systém CP-370 představen, se základní způsob virtualizace příliš nezměnil. Stejně jako tehdy se i dnes jedná o sdílení systémových prostředků (paměti, procesoru, diskového úložiště, přerušení a instrukční sady) virtuálním strojům nebo aplikacím tak, aby nepoznali, že nemají výhradní přístup k hardwarovým zdrojům. Jednotlivé virtuální stroje, ačkoliv běží na jednom hardwaru, jsou od sebe izolovány a navzájem se neovlivňují. [3] - 11 -
Nástup modelu klient/server 1 v 80. letechpřinesl rychlý nástup architektury x86 a virtualizaci odsunul na vedlejší kolej". Hardware byl drahý a jeho výkon nebyl vysoký, takže příchod operačních typu MS Windows a Linux, který umožňoval na síťovém modelu klient/server zprovoznit z několika levných pracovních stanic a vytvořit levnou a funkční síť, slavil úspěch. S rozvojem počítačových technologií a nárůstem výkonu výpočetních zdrojů se na konci 90. let vrátily problémy, které řešila IBM v 60. letech. Jednalo se o nevyužívaný výkon provozovaného HW, vysoké náklady na jeho údržbu a řízení a relativně malá ochrana před výpadkem HW. A tak se virtualizace vrací zpět na scénu. Historie komerčního využití virtualizace začínala velmi pozvolna i na poli emulace. Začátkem roku 1987 představila společnost Insignia Solutions aplikaci pro softwarovou emulaci nazvanou SoftPC, která umožnila v UNIXu spouštět aplikace určené pro DOS. V roce 1989 byla vydána verze, která již pracovala pod MacOS a umožňovala spouštět aplikace určené pro Windows. Společnost Apple nabízí od roku 1997 vlastní virtualizační software VirtualPC, který se později stal nedílnou součástí MacOS. První, kdo nabídl virtualizaci serverového operačního systému pro komerční využití, byla společnost VMware, která roce 1999 vydala první verzi aplikace VMware Workstation určené jen pro Windows. Ta umožňovala spouštět různé instance operačních systémů architektury x86 na jednom PC. V roce 2001 vydala první verzi ESX a GSX serveru. ESX server byl hypervizor typu 1 (popsáno v kapitole 0), který běžel přímo na hostitelském hardware a skládal se pouze z vmkernelu a servisní konzole. GSX byl hypervizor typu 2, který běžel v prostředí operačního systému a z počátku byl určen jen pro prostředí MS Windows. Tím se VMware dostal do pozice jediného leadera na trhu virtualizačních technologií a tato pozice mu zůstala několik let. Až v roce 2001 se objevila společnost Connectix se svým VirtualPC for Windows původně určeným jen pro Apple. Akvizicí společnosti Connectix v roce 2003 vstoupil na trh virtualizace i Microsoft, který zařadil VirtualPC do svého portfolia. Zde byl nabízen pod názvy Microsoft Virtual PC 2004, Microsoft Virtual PC 2007 a dnes je jako Microsoft Virtual 1 Metoda klient/server jedná se o kombinaci síťové technologie a software. Server je počítač, který nabízí své služby a klienti jsou pracovní stanice, které žádné služby nenabízení, ale naopak tyto služby využívají. Servery můžeme dělit podle typu nabízené služby na file server, mail server, web server, www server, atd. - 12 -
PC součástí OS Windows Professional. Vedle toho pracoval Microsoft i na vývoji řešení virtualizace serverů a v roce 2005 uvolnil první verzi Virtual Server 2005 běžící pod OS Windows, za kterou následovaly verze pod názvem Hyper-V 2008 a Hyper-V 2012, které již pracují přímo nad hardwarem. Na konci roku 2003 byla představena první veřejná verze virtualizačního open-source řešení XEN, které vzniklo jako výzkumný projekt na univerzitě v Cambridge. V průběhu času se objevila řada virtualizačních technik, které se od sebe liší hlavně v principu prezentace hardwaru virtualizovanému software. Podrobněji se jim budu věnovat v kapitole 2. Virtualizace přestala být ojedinělou výjimkou a díky nárůstu výkonu hardware, snížení nákladů a výhodám se pomalu stává základem pro většinu IT infrastruktury. V současnosti jsou tedy na poli virtualizačních technologií hlavními lídry společnosti VMware a Microsoft. Moderní stroje mohou své zdroje rozdělit podobně jako mainframe v 60. letech a maximálně využít dostupný výkon. Další vývoj se ubírá směrem ke zdokonalování nástrojů, kterými jsou virtuální prostředí řízena, takže princip virtualizace se nemění, jen se rozšiřují její možnosti. 1.4. Přínosy virtualizace V předešlé kapitole jsem se již zmínil o důvodech, proč se virtualizace dostala mezi velmi populární technologie. Těmi důvody bylo - lepší využití volného výkonu hardware, a tím možnost snížení množství fyzického hardware, - zjednodušení správy tohoto hardware a zvýšení odolnosti proti výpadku. Dalším ještě nezmíněným přínosem virtualizace je - izolace jednotlivých virtuálních hostů nejen od hardware, ale i sama od sebe. Případná havárie jednoho virtuálního serveru, neovlivňuje provoz ani výkon ostatních virtuálních serverů. K pochopení důležitosti tohoto přínosu je potřeba se podívat trochu do historie. Po vydání operačního systému Microsoft Windows NT server 3.1, resp. 3.51 a 4.0 došlo k jejich relativně rychlému rozšíření. Jednalo o systémy s hybridním jádrem, jehož veškerý kód běžel ve stejném paměťovém prostoru, sdílel ovladače a DLL knihovny. V případě kolize jedné ze spuštěných aplikací mohlo dojít k zablokování ostatních aplikací, případně ke shození celého jádra. Často se pak objevila známá obrazovka modré smrti - BSoD (Blue Sceen of Death). - 13 -
Správci aplikací tento problém eliminovali instalací samostatných jednoúčelových serverů, kdy v případě problémů došlo k vyřazení jednoho serveru bez omezení ostatních serverů a aplikací. Zde je možné si povšimnout podobnosti s izolací virtuálních hostů. Toto řešení mělo své nevýhody: - mnohem vyšší pořizovací náklady na hardware, - zabrané místo v datovém rozvaděči, - vyšší spotřeba elektrické energie, - vyšší požadavky na chlazení, protože servery topí - ohřívají vzduch V rámci optimálního využití nákladů a vytížení serverů požadovali provozovatelé instalovat a provozovat na jednom fyzickém serveru více aplikací. K tomu bylo ale potřeba počítat s následujícími omezeními: - aplikace musí být vzájemně kompatibilní, - aplikace musí pracovat v jednom daném operačním systému, - v případě požadavku na restart serveru je třeba vypnout všechny aplikace. - každá aplikace má vlastního správce, který pro svou práci většinou vyžaduje administrátorská přístupová práva, což sebou nese nebezpečí, že jeho zásah do systému může způsobit zpomalení, zastavení, nebo i poškození ostatních aplikací. - při plánování hardwarových zdrojů před jejich nasazením požaduje každý správce pro svou aplikaci maximální možné zdroje, které aplikace nepotřebuje k běžnému provozu, ale jen ve zvláštních případech. Jedná se, např.: o aktualizaci databáze, ale díky tomu dochází k neefektivnímu využívání zdrojů a potencionálně i vyšším pořizovacím nákladům. - v případě havárie serveru je potřeba všechny aplikace znovu instalovat a zprovoznit, což zvyšuje RTO. I když moderní operační systémy Windows 2008 a 2012 jsou mnohem stabilnější a bezpečnější než první verze MS Windows NT a umí lépe izolovat aplikace, tak špatná zkušenost z minulosti zvyky správců serverů nezmění. Proto v každé serverovně bylo a je několik jednoúčelových serverů, které nevyužívají výkon svého hardware. A zde je právě řešením serverová virtualizace, jejíž hlavní výhody si nyní představíme. - 14 -
1.4.1. Konsolidace serverů na fyzický hardware Konsolidace serverů nám umožní maximalizovat využití hardwaru serveru. Jedná se o základní výhodu virtualizace, kdy můžeme na jednom fyzickém stroji provozovat několik strojů virtuálních. Z toho je ihned zřejmé, že potřebujeme méně hardware. Přínosem jsou tedy nižší náklady na hardware. Obrázek 3 - Konsolidace serverů (zdroj: www.vmware.com) Průměrné využití procesoru fyzického serveru se pohybuje mezi 10% až 30%. Převedením více serverů do virtuálního prostředí na jeden server dosáhneme využití fyzického hardwaru na 60 až 80%. A právě finanční úspory motivují provozovatele datových center po celém světě, aby nasadili virtualizaci co nejdříve. Sníží tak náklady nejen při pořízení hardware, ale hlavně při následném provozu celého datového centra. Méně fyzických serverů znamená menší požadavky na prostor, na příkon a na chlazení. A zároveň je tím podporováno rozšíření a další rozvoj virtualizace. [15] [22] 1.4.2. Flexibilita Virtualizace nám přináší flexibilitu, díky které můžeme rychle a dynamicky vybudovat nebo rozšiřovat vývojové či testovací prostředí. V klasickém prostředí by se jednalo o požadavek na další server, software a hlavně spousty práce s přípravou a instalací celého prostředí. Ve virtualizovaném prostředí předpokládáme, že lépe využijeme již nakoupený hardware, takže musíme jen nainstalovat servery. 1.4.3. Implementace nových serverů Jednou z dalších výhod virtualizace je skutečnost, že virtualizovaný stroj je fyzicky tvořen několika soubory na disku. V okamžiku, kdy je třeba vytvořit jeho klon, kopii nebo zálohu stačí těchto několik souborů zkopírovat. Z toho vyplývající výhodou je, že si můžeme připravit několik různých čistých virtuálních serverů - šablon, které můžeme později podle - 15 -
potřeby rychle klonovat a spouštět. Tato výhoda je současně i nevýhodou právě proto, že je server tvořen jen několika málo soubory, může při ztrátě, nebo poškození několika souborů dojít ke ztrátě celých serverů. Prvotní instalace Windows serveru do virtuálního prostředí je podobná instalaci v klasickém prostředí a jedná se o práci na několik hodin. Po instalaci vznikne stejná adresářová struktura, která je tvořena velkým množstvím podadresářů a souborů. Následně je třeba provést základní nastavení, instalaci service packů a aktualizací. Teprve pak je virtuální server připraven k použití nebo ke klonování. Vytvoření dalšího nového serveru se jeho kopírováním zkrátí z několika hodin na několik minut. Pro zjednodušení celého procesu nabízí výrobci ve svých administračních nástrojích funkce pro vytvoření kopie existujících virtuálních strojů. [15] Po naklonování je samozřejmě potřeba provést administrativní úpravy (sysprep), pojmenování serveru, zařazení do sítě, nastavení přístupových práv k aplikací a komponentám. Všechny tyto činnosti, bychom ale museli provést i v případě fyzické instalace. V praxi nám ale může toto jednoduché klonování serverů způsobit problémy, když si pro své testování může virtuální stroj vytvořit každý programátor. Během několika málo týdnů, bude testovací server plný nefunkčních a neoznačených virtuálních serverů, ke kterým se nikdo nebude hlásit. Takže bude potřeba celý server zkontrolovat, odstranit zbytečné virtuální servery a přidělit práva jen omezené skupině uživatelů. Zde je třeba upozornit a uvědomit si, že správce virtuální infrastruktury může svým neuváženým zásahem způsobit mnohem více problémů, než v případě správy jednoho serveru a že sdílené hardwarové zdroje jsou omezené a je třeba s nimi nakládat rozumně. 1.4.4. Distribuce aplikací Další výhodou, kterou bych zařadil mezi zvýšení flexibility je ta, že pro sdílení aplikací není nutné virtualizovat celý server, ale jen samotnou aplikaci. Z pohledu nasazení a aktualizace virtualizovaných aplikací dochází k výraznému zjednodušení jejich správy. Vedle toho dochází i ke zjednodušení a urychlení výměny klientských počítačů, protože aplikace není na stanici instalována a odpadají problémy s kompatibilitou aplikace na různých operačních systémech. Princip je následující. Ve speciální virtualizační aplikaci vytvoříme pro každou virtualizovanou aplikaci vlastní softwarový balíček, který obsahuje všechny soubory, - 16 -
knihovny a klíče registrů, které aplikace pro svůj běh požaduje. V případě MS se tato speciální aplikace jmenuje App-V Sequencer. Tyto vytvořené SW balíčky s aplikacemi jsou uloženy a připraveny na Site Serveru a odsud jsou spouštěny. Distribution Point pak zajišťuje doručení balíčku s aplikací na klientskou stanici. Aplikace je tedy spuštěna a provozována na klientské stanici a snižuje výkonovou zátěž serveru. Nevýhodou je větší přenos dat při spuštění aplikace, kterou si ale App-V ukládá do lokální cache. App-V Sequencer Aplikace pro Windows Configuration Manager Site Server Configuration Manager Distribution Point Site server zde jsou balíčky s aplikacemi uloženy Distribution Point - zajištuje distribuci aplikací na klienty App-V Sequencer - umožní vytvoření balíčků s aplikacemi Varianty distribuce aplikací VDI server Terminálový server Desktop Obrázek 4 - Princip virtualizace aplikací od Microsoftu - App-V (zdroj: www.microsoft.com, upraveno) Jednoduchou výměnou balíčku na serveru provedeme upgrade aplikace na všech klientech najednou bez nutnosti obcházet stanice nebo řešit rozdílné verze OS na klientech. Balíček s aplikací můžeme zpřístupnit jen vybraným uživatelům nebo je můžeme nastavit, že si uživatel může aplikaci spustit na jen na vybraných pracovních stanicích a v určeném čase. 1.4.5. Zálohování Jak je uvedeno v kapitole 1.4.3, virtuální počítač je tvořen pouze několika soubory (konfigurační soubory + virtuální disky). Stačí tedy provést kopii těchto souborů a záloha je hotová. Problém je, že takovou zálohu je třeba provést při vypnutém virtuálním počítači, což není nejlepší. Máme sice možnost na virtuální stroj instalovat zálohovací software a provádět zálohy stejně jako na fyzickém počítači, ale mnohem lepší je využít technologii, která nám umožní zálohovat běžící virtuální počítače bez výpadku. Tako technologie se jmenuje snapshot. - 17 -
Snapshot nám vytvoří kopii stroje k určitému času (Point-in-time-copy), ihned po vytvoření ho můžeme použít v jiných aplikacích, např. k zálohování. Původní stroj je nadále k dispozici bez přerušení provozu jen s minimálním pozastavením datového toku. [15] 1.4.6. Sdílení systémových prostředků Největší nevýhodou virtualizace je paradoxně problém vyplývající z jejích výhod. V případě, kdy máme servery a aplikace konsolidovány na jeden fyzický server, a dojde k poruše tohoto fyzického hardware, znamená to okamžitý výpadek a rozsáhlejší škody než v případě výpadku jednoho klasického serveru. Nejvhodnějším řešením je v tomto případě provozování virtuálních serverů v clusteru s minimálně dvěma nody, kdy při poruše jednoho nodu jsou virtuální servery okamžitě spuštěny na druhém nodu. 1.4.7. Migrace Jak jsem již uvedl, virtualizace odstraňuje závislost na fyzickém hardware, protože hypervisor nabízí všem virtuálním strojům stejný virtuální hardware, ať už je fyzický hardware serveru jakýkoliv. Přenos virtuálního stroje na jiný hypervisor stejného výrobce, je pak otázkou zkopírování souborů virtuálního stroje do prostředí druhého hypervisoru a jeho spuštění. Takže i plánovanou údržbu hardware je možné provádět levněji v průběhu pracovního dne, protože virtuální stroje je možné jednoduše přesunout, neboli migrovat, na jiný fyzický server. Podobný princip je využit i v případě zálohy a obnovy zálohy virtuálního stroje na jiný hypervisor. Hypervisor 1 Hypervisor 2 Diskové pole Obrázek 5 - zjednodušený popis migrace virtuálních serverů (zdroj: autor) - 18 -
Při nasazení služby MS Virtual Machine Live Migration je v případě problémů s jedním fyzickým serverem, automaticky spuštěna a provedena migrace virtuálních strojů na jiné servery. Migrovaný virtuální stroj je vytvořen na cílovém serveru, paměťové stránky jsou zkopírovány přes síť. K finálnímu přesunu dojde pozastavením virtuálního stroje a jeho zapnutí na cílové serveru. 1.5. Vrstvy virtualizace Virtualizační technologie jsou dnes velmi vyspělé a je možné je používat v různých vrstvách. Jednotlivé virtualizované aplikace, zdroje i prostředky ztrácí fyzické vazby na hardware a případně operační systém. Prezentační virtualizace (PresentV) Prezentační vrstva oddělená od procesu Virtuální profily (DeskV) Uživatelské profily/nastavení oddělené od OS Virtuální aplikace (AppV) Jakákoliv aplikace na jakémkoliv PC na vyžádání Virtuální hardware (SerV) OS může být přidělen jakémukoliv PC nebo serveru Virtuální storage (StoreV) Storage a zálohy přes síť Virtuální sítě (NetV) Sjednocení členěných zdrojů Obrázek 6 - Vrstvy virtualizace (zdroj: www.optimalizovane-it.cz) 1.5.1. Virtualizace prezentační vrstvy (PresentV) Typickým představitelem prezentační vrstvy jsou terminálové služby, tedy rozhraní pro zobrazení uživatelského rozhraní. Výhodou je centralizovaná správa aplikací poskytovaných koncovým uživatelům a možnost ke službě přistupovat odkudkoliv a z jakéhokoliv zařízení. - 19 -
1.5.2. Virtualizace desktopů (DeskV) V minulosti byla často využívána funkce roamingových profilů, která byla jakousi první verzí virtualizace desktopů. Uživatelské profily jsou odděleny od vlastního operačního systému. Tato funkce byla součástí serverových operačních systémů Windows. Umožnila přenést profil uživatele z klientské stanice na síťové virtuální úložiště a v případě přihlášení uživatele na jiné stanici mu bylo zobrazeno jeho prostředí, jeho nastavení a jeho dokumenty. Dnes je virtualizace desktopů řešena podobně jako terminálové služby. Po přihlášení do datového centra je uživateli zobrazen jeho profil, kde nalezne svůj virtualizovaný desktop, se svými aplikacemi. Připojení je podle nastavení možné odkudkoliv a z jakéhokoliv zařízení. Toto řešení přinese bezpečnost, centralizovanou správu a jednodušší údržbu systémů. [14] 1.5.3. Virtualizace aplikací (AppV) Toto řešení se v poslední době začíná významně prosazovat. Princip je následující. Aplikace nejsou na stanice instalovány klasickým instalačním procesem, ale na serveru je spuštěna služba AppV, která obsahuje aplikace připravené ke spuštění jako virtualizované. Po spuštění aplikace ze serveru je aplikace přenesena na koncovou stanici. Např. společnost Microsoft používá metodu přenosu celé aplikace včetně potřebných dll knihoven, nastavení registrů atd. Aplikace je spuštěna na hardwaru koncové stanice, což snižuje zátěž centrálního serveru, ale nezasahuje do jejího operačního systému. Výhody jsou: jednoduchost správy, centrální aktualizace, aplikace není třeba instalovat na koncové stanice, přístupová práva je možné přidělovat konkrétním uživatelům ke konkrétním aplikacím, uživatel není vázán na konkrétní pracovní stanici, po přihlášení na libovolné klientské stanici je mu umožněno spustit povolené aplikace, není nutné řešit konflikty mezi jednotlivými aplikacemi ani mezi aplikací a operačním systémem. Nevýhodou je větší přenos dat při spuštění aplikace. [14] [19] 1.5.4. Serverová virtualizace (SerV) Virtualizace serverů je zřejmě nejznámější vrstvou virtualizace. Umožňuje virtualizovat platformy x86 a x64 a dělí se na softwarovou SoftV a hardwarovou HardV. V případě SoftV je virtualizovaný operační systém spuštěn nad běžícím operačním systémem. HardV pracuje přímo nad hardwarem a virtualizovaný systém je spuštěn v hypervisoru. - 20 -
Virtualizovaný operační systém je možné v případě výpadku hardware přenést na jakýkoliv jiný hardware, čímž docílíme výhodnějšího rozložení zatížení fyzických serverů. [14] 1.5.5. Virtualizace uložišť (StoreV) V tomto případě se jedná o virtualizaci diskového systému, kdy jsou fyzické disky sloučeny v jeden nebo více disků virtuálních. Obvykle se jedná hlavně o disková pole, která nejsou k jednotlivým serverům připojena (DAS - Direct Attached Storage), ale jsou dostupná z více serverů. Diskové systémy dostupné více serverům či případně umístěné v různých lokalitách mohou být dostupné pomocí existujících sítí (NAS - Network Attached Storage) anebo sítí vyhrazených pro diskové systémy (SAN - Storage Area Network). [18] [19] 1.5.6. Virtualizace sítí (NetV) Virtualizace sítí je dnes běžně využívaná, její princip spočívá v provozu více fyzicky oddělených sítí (VLAN) v jednom síťovém prvku. Sítě mohou tvořeny staticky nebo mohou být na základě síťového zabezpečení v dané síťové infrastruktuře přidělovány klientům dynamicky. [18] - 21 -
2. Techniky serverové virtualizace x86 Starší operační systémy, jako byl např. DOS, Windows NT server, nebo Novell 3.12, byly napsány v době, kdy virtualizace nebyla běžně dostupná. Autoři tehdy psali software tak, že předpokládal, že má exklusivní přístup ke všem hardwarovým zdrojům. A na druhé straně i hardware očekával, že komunikuje jen s jedním operačním systémem. Virtualizace toto změnila, když mezi hardware a operační systém postavila softwarovou vrstvu nazvanou hypervisor. 2.1. Architektury hypervisorů Hypervisor (VMM, Virtual Machine Monitor), je softwarová aplikace, která umožňuje spouštět jeden nebo více virtuálních strojů (VM, Virtual Machine) na fyzickém serveru (hostiteli). Každý virtuální stroj je hostovaný systém, a fyzický server, na kterém hostovaný systém pracuje je hostitelský systém. Hypervisor přebírá kontrolu nad hardwarem a zajišťuje přidělování systémových zdrojů jednotlivým virtuálním strojům. Zároveň zajišťuje izolaci jednotlivých virtuálních strojů. Hypervisor tedy zajišťuje obsluhu privilegovaných instrukcí procesoru, obsluhu paměti, jejího stránkování a přidělování, dále virtualizaci I/O zařízení, resp. obsluhu požadavků na přidělení disku a síťových rozhraní. Hypervisory dělíme podle přístupu k ovladačům na monolitický a mikrokernel. 2.1.1. Monolitický hypervizor V případě monolitického hypervizoru emuluje virtuální vrstva hardware a přístup virtuálním strojů k tomuto hardwaru poskytuje přes vlastní speciální ovladače napsané přímo pro danou verzi hypervisoru. Tím je výrazně omezeno množství hardware, na kterém lze hypervisor provozovat. - 22 -
VM 1 (admin) VM 2 VM 3 HYPERVISOR Ovladače HARDWARE Obrázek 7 - Monolitický hypervisor (zdroj: autor) Protože hypervisor obsahuje větší množství kódu, je jeho velikost oproti mikrokernelu vyšší, a tím se zvyšuje i pravděpodobnost výskytu chyby. Na druhou stranu je možné speciálními ovladači určenými a testovanými pro virtualizaci dosáhnout vyšší optimalizace a tedy vyššího výkonu. Tento typ hypervisoru používá VMware a Xen. [8] [19] 2.1.2. Microkernel hypervizor Jedná se o minimalistický operační systém, který neobsahuje ovladače k fyzickému hardwaru, které obsahují až hostované operační systémy. Hlavní funkcí hypervisoru je, aby jednotlivé virtuální stanice nepřistupovaly ke stejnému hardwaru ve stejný okamžik. VM 1 ( parent ) Virtulization stack Ovladače VM 2 ( child ) Ovladače HYPERVISOR HARDWARE VM 3 ( child ) Ovladače Obrázek 8 - Microkernel hypervisor (zdroj: autor) Mezi zástupce této architektury patří Microsoft Hyper-V. Největším rozdílem oproti monolitické konstrukci je skutečnost, že Microsoft nemusí po výrobcích hardwaru vyžadovat nové verze ovladačů pro nový hypervisor. Všechny kompatibilní ovladače jsou k dispozici od výrobců zařízení fungujících pod Windows. Tímto je eliminována potřeba používat ovladače třetích stran a minimalizován možný útok, protože do hypervisoru není vložen žádný cizí kód. (Ovladače zařízení jsou vyráběny třetími stranami, a proto jsou z pohledu dodavatele považovány za cizí kód). Hypervisor je proto výrazně menší a může být spolehlivější, čímž je sníženo riziko nestability a zaručena vyšší bezpečnost a výkon. [8] [19] - 23 -
2.2. Architektury procesorů Architektury procesorů IA-32 a x86-64 nebyly navrhovány pro provoz virtualizovaných operačních systémů. Teprve až po příchodu virtualizace a nárůstu požadavků na virtuální technologie nabídly společnosti Intel a AMD novou řadu procesorů s instrukční sadou rozšířenou o instrukce umožňující tzv. hardwarově asistovanou virtualizaci. Společnost Intel pojmenovala svou technologii IVT (Intel Virtualization Technology) a společnost AMD pak AMD-V (AMD's Virtualization). I když se jedná o dvě různé technologie, jejich princip je ve výsledku stejný. Rozšiřují standardní stupně Ring 0 až Ring 3 o další dva režimy. Režim hostitele (Host mode) - V tomto režimu pracuje hypervisor, který zajišťuje vytváření virtuálních strojů, řídí přístupová práva a přepínání do režimu hosta. V případě hypervisoru typu II pracuje v tomto režimu i hostitelský operační systém. Režim hosta (Guest mode) - V tomto režimu jsou provozovány virtualizované systémy. Privilegované instrukce pak podle oprávnění přidělených od hypervisora mohou, ale nemusí vyvolat návrat do režimu hostitele. V režimu hosta i režimu hostitele jsou stále k dispozici standardní stupně oprávnění. Procesory splňují požadavky Popeka a Goldberga na plnou virtualizaci, ale stále není možné zamezit detekci běhu ve virtualizovaném prostředí. [5] V následující tabulce jsou seřazeny operační módy procesoru, odstíny odlišují, jak byly jednotlivé režimy postupně přidávány. IA32 x86-64 IVT a AMD-V Obrázek 9 - Operační mody procesorů Intel (zdroj: cs.wikipedia.org/wiki/x86-64, upraveno autorem) - 24 -
2.2.1. Podpora virtualizace od Intel (VT-x) V listopadu 2005 zahájil Intel prodej prvních dvou modelů procesorů Pentium 4 (model 662 a 672), ve kterých byla implementována podpora virtualizace VT-x. Tato technologie byla vyvíjena pod kódovým názvem Vanderpool. [10] Cílem podpory virtualizace od společnosti Intel bylo připravit pro virtuální stroje prostředí, které bude odpovídat instalaci a provozu operačních systémů ve fyzickém prostředí a tím umožnit virtualizaci i starších nemodifikovaných operačních systémů. Dále bylo cílem zvýšení stability, výkonu, ochrany a naopak snížení potřeby nepotřebných přepínání a specifických úprav hypervisorů nebo operačních systémů. [10] 2.2.1.1. Virtual Machine Extension (VMX) Podpora virtualizace je v procesoru zajištěna novými funkcemi nazvanými VMX operace. Tyto operace se dělí na dva druhy: root operace a non-root operace. Obecně platí, že hypervisory pracují v režimu VMX root a hostované systémy v režimu VMX non-root. Uživatelské Aplikace (nemodifikovaný) Hostovaný OS Ring 3 Ring 0 Hypervisor Ring -1 VMX Root Intel Virtualization Technology Fyzický hardware Obrázek 10 - Virtualizace podle Intelu - VMX (zdroj: autor) Přechod mezi VMX root a VMX non-root operacemi je nazýván VMX transition. Ten dělíme podle směru volání na: VM enter, který přepíná z režimu VMX non-root do VMX root a VM exit, a který přepíná z režimu VMX root do VMX non-root. [10] 2.2.1.2. Extended Page Tables (EPT) Extended Page Tables (EPT) je virtualizační technologie x86, druhé generace pro správy paměti (MMU Memory management unit). Podporu EPT najdeme jádrech procesorů Intel i3, i5 a i7. Jedná se o mechanismus, který slouží k podpoře virtualizace fyzické paměti, která zajistí rozdělení a přidělení paměti virtuálním počítačům, kdy každý host má vlastní stránkovací tabulku, která obsahuje adresy paměti. Bez podpory EPT by musel hypervizor - 25 -
vždy přerušit práci s VM, aby mohlo dojít k překladu adresy. EPT tedy výrazně snižuje výkonovou režii a zvyšuje rychlost. Translation Lookaside Buffer (TLB) je součástí procesoru a slouží k překladu virtuálních adres na fyzické. TLB obsahuje záznamy z naposledy použitých ze stránkovacích tabulek, v případě opakovaného přístupu na stejné adresy je není potřeba vyhledávat znovu. Výhodou TLB je snížení potřeby synchronizace stínových stránek (Shadow Page Tables). Synchronizaci shadow page tables, které mapují stránky hostů přímo do stránek fyzického stroje, zajišťuje hypervisor. Takže snížení potřeby synchronizace přinese další nárůst výkonu. [10] 2.2.1.3. Intel Virtualization Technology for Directed I/O (Intel VT-d) Jedná se o technologii, která zajišťuje oddělení přístupu virtuálních hostů od zařízení, které využívá jiný virtuální host. Řídí přidělování a přístup k I/O, dále řídí přemapování DMA, kdy zajišťuje izolaci potvrzení, že žadatel dostal povolení k přístupu na adresu a překládá adresy zařízení na adresy do fyzické paměti. Intel VT-d přemapování přerušení umožňuje snížit režii při přerušení virtualizace pro přiřazení zařízení. Umožňuje směrování a izolaci přerušení od zařízení, nahlašuje a zaznamenává chyby DMA a přerušení, která by jinak mohla způsobit komplikace v paměti.[9] [10] 2.2.1.4. Intel Virtual Machine Control Structure Shadowing (Intel VMCS Shadowing) Umožňuje přímé volání instrukcí procesoru virtuálním strojem, není tedy nutné předávat požadavky hypervisoru, který zajišťuje volání procesoru. Přímé přístupy k hardware jsou definovány a tím se zkracuje čas operací. Intel uvádí, že časová náročnost je 15x nižší, než v případě přepínání hypervisorem. [10] [11] 2.2.2. Procesory AMD Společnost AMD představila svou hardwarovou podporu virtualizace v roce 2004 pod názvem AMD Secure Virtual Machine (SVM), který později změnilo na AMD-V (AMD Virtualizaton). Vývoj technologií probíhal pod pracovním názvem Pacifica. První procesory s podporou HW virtualizace bylo uvedeno AMD na trh v květnu 2006 a jednalo se o modely Athlon 64, Athlon 64X2 a Athlon 64 FX. - 26 -
AMD-V rozšířilo funkce procesorů o podporu virtualizace a ochrany virtuálních strojů. Podporuje rychlé přepínání mezi hypervisorem a virtuálními stroji. V CPU je integrován paměťový řadič, který řeší oddělení systémů jednotlivých VM. (Tento řadič doplnila společnost Intel, až ve druhé generaci procesorů s VT-x, pod názvem EPT). AMD-V obsahuje následující rozšíření: Nový mód procesoru: Guest Mode Nová instrukce: VMRUN Nová datová struktura: Virtual Machine Control Block (VMCB) Nový paměťový mód: Real Mode w/ Paging External Access Protection through: Device Exclusion Vectors (DEV) Selective Interception, increasing performance and enabling para-virtualization Support for SKINIT ( secure kernel init) Tagged TLB Nested Page Table Support Interrupt architecture changes VM assists for interrupt handling Virtual interrupt support and APIC.TPR virtualization Do guest mode přechází procesor při zavolání instrukce VMRUN. V tomto režimu se některé instrukce x86 mění, aby usnadnily virtualizaci. [1] Postupně byla podpora virtualizace AMD-V doplněna o funkci Rapid Virtualization Indexing (RVI), která umožňuje hardwarovou správu paměti a AMD-V Extended Migration, které slouží k migraci virtuálních počítačů mezi procesory AMD Opteron. [25] 2.2.2.1. Virtual Memory Control Block (VMCB) Pro zefektivnění virtualizace přerušení je následující podpora poskytována pod kontrolou VMCB (Virtual Memory Control Block) příznaků: Zachycení doručení fyzického přerušení - tato funkce dovoluje hypervizoru pomocí hardwarového přerušení vyvolat přerušení libovolného VM. Virtuální přerušení - je funkce, při které hypervizor může aplikovat virtuální přerušení do virtuálního hosta. Pod kontrolou hypervizoru, jsou virtuální kopie EFLAG.IF s přerušovacím maskovacím bitem a virtuální kopie APIC registru priority úkolů, transparentně použity hostem, namísto fyzických zdrojů. - 27 -
Sdílení fyzických APIC - je funkce, při které hypervizor umožňuje více hostům sdílet stejnou fyzickou APIC a brání se škodlivým, nebo závadným hostům, kteří by mohli nechat přerušení s vysokou prioritou bez potvrzení a tím zablokovat použití přerušení pro ostatní hosty. [1] 2.2.2.2. Externí přístupová ochrana (External Access Protection) Hostům může být povolen přímý přístup k vybraným I/O zařízením. Podpora přímého přístupu je navržena tak, aby se nedošlo k přístupu do paměti, kterou vlastní jiný host nebo hypervizor. [1] 2.2.2.3. I/O Virtualization Umožňuje VM přímý přístup k zařízením, obchází hypervisor, takže zlepšuje výkon aplikací a izolaci virtuálních počítačů a zvyšuje integritu a bezpečnost. [25] 2.2.2.4. Značkované TLB (Tagged Translation Lookaside Buffer) Hardwarová funkce, která usnadňuje efektivní přepínání mezi virtuálními stroji pro lepší odpověď aplikací. Hypervizor je mapován v odlišném adresovém prostoru než virtuální stroje. Aby se snížila režie při přepínání paměti, označuje TLB pozice v paměti identifikátory (ASID), které rozlišují zápis hypervisoru od zápisu virtuálních strojů. Hypervisor používá stínové stránkovací tabulky pro každou stránku je vyhrazen ASID. Tím je umožněno přepínání mezi procesy bez potřeby zahození tabulky při přepínání mezi virtuálními stroji. [1] 2.2.2.5. Rapid Virtualization Indexing (RVI) Rapid Virtualization Indexing (RVI) je funkce, která umožňuje virtuálním strojům spravovat paměť přímo. Snižuje tak počet cyklů, které by hypervisor potřeboval pro manipulace související s pamětí. Vedle toho umožňuje procesoru velmi rychle přepínat mezi mnoha virtuálními stroji, což dále zvyšuje výkon virtualizace. Manipulace s paměti a přepínání je také podpořen v TLB, která mapuje paměť pro jednotlivé VM. Tím snižuje správu paměti a urychluje proces přepínání mezi virtuálními stroji. [25] 2.2.2.6. AMD-V Extended Migration Pomáhá virtualizačnímu softwaru s živými migracemi virtuálních strojů mezi dostupnými procesory AMD Opteron. - 28 -
- 29 -
2.3. Typy hypervisorů VM 1 VM 2 VM x VM 1 VM 2 VM x OS OS OS OS OS OS Hypervisor TYPE 2 Hypervisor TYPE 1 Fyzický hardware Operační systém Fyzický hardware Obrázek 11 - Hypervisor typu 1 a typu 2 (zdroj: autor) 2.3.1. Hypervisor type I. V případě, kdy hypervisor běží přímo nad HW bez operačního systému, se jedná o hypervisor typu 1, bývá také nazýván ho také bare-metal (native) hypervisor. Pro svou činnost vyžaduje hardwarovou podporu virtualizace. Hypervisor typu 1 zastupují produkty Microsoft Hyper-V, Citrix XenServer a VMware ESX Server. 2.3.2. Hypervisor type II. Hypervisor typu II běží v hostitelském operačním systému (Windows, Linux) a nazýváme ho proto hostitelský hypervisor. Tento typ hypervisoru zastupují produkty Microsoft Virtual Server (2005) a VMware Server. Za desktopové verze je to např. Microsoft Virtual PC. Provádění privilegovaných instrukcí hostovaných OS způsobí vyvolání výjimky obsluhované hypervisorem, který je v ring 0. Podrobněji popsáno v kapitole 2.4.2.1. Architekturu typu 2 zastupují Microsoft Virtual Server (2005) a VMware Server. Za desktopové verze je to Microsoft Virtual PC - 30 -
2.4. Typy virtualizace Serverovou virtualizace můžeme podle pohledů dělit na skupiny. Nyní rozebereme jednotlivé techniky, ale k tomu je ale nejprve potřeba, správně rozumět rozdílům v architektuře počítačového jádra. Virtualizační techniky Hypervisor Kontejnerový systém Plná virtualizace Para virtualizace Host OS virtualizace Obrázek 12 - Rozdělení virtualizačních technik podle použití hypervisoru (zdroj: autor) Částečná virtualizace Emulace Virtualizační techniky Softwarová virtualizace Hardwarová virtualizace Para virtualizace Virtualizace na úrovni OS Plná virtualizace s HW podporou IVT VT-x Plná virtualizace Virtualizace aplikací Plná virtualizace s HW podporou AMD-V SVM Obrázek 13 - Rozdělení virtualizačních technik podle SW a HW podpory (zdroj: autor) 2.4.1. Procesor bez virtualizace Nejprve je třeba vysvětlit rozdíl funkce procesoru x86 v klasickém prostředí a v prostředí virtualizace. V klasickém počítači bývá obvykle jeden procesor, který si pro sebe zabere instalovaný operační systém. Ale každý virtuální stroj běžící na hostiteli vyžaduje procesor jen pro sebe, nebo spíše svůj procesor. A zde se právě použije hypervisor, který konvertuje sadů procesorových volání z hostovaných operačních systémů, předává je fyzickému procesoru, přijímá od něho odpovědi a ty vrací zpět operačním systémům. - 31 -
Pro převod a předání příkazů procesoru existuje několik metod. Ring 3 Uživatelské Aplikace Nejvyšší úroveň ochrany Ring 2 Ring 1 I/O volání Ring 0 Operační Systém Privilegovaný přístup Fyzický hardware Nejnižší úroveň ochrany Obrázek 14 - Úroveň oprávnění architektury x86 bez virtualizace (zdroj: autor) Klasická instalace operačního systému běžící na platformě x86 je navržena tak, že předpokládá, že má veškerý přístup a výhradní kontrolu nad veškerým hardwarem. Architektura procesoru x86 pracuje se čtyřmi úrovněmi ochrany pro řízení přístupu k hardware - Ring 0, 1, 2 a 3. Uživatelská aplikace běží v Ring 3 a má nižší privilegia než operační systém, který pracuje v Ring 0. A i když je uživatelská aplikace v Ring 3 a operační systém v Ring 0, přesto aplikace může vyžadovat přímý přístup do paměti, nebo k hardware. To samé ale platí i pro virtuální stroje. Operační systém v hostovaných strojích požaduje pro svůj běh úroveň Ring 0, kterou požaduje i hostitelský operační systém. To je důvod, proč není virtualizace na platformě x86 zcela jednoduchá. Existuje několik metod řešení virtualizace procesoru x86, které se liší právě podle toho, na jaké úrovni (tj. kým) jsou zpracovávány privilegované příkazy požadované hostujícím operačním systémem. Podle těchto metod je virtualizace procesoru rozdělena na plnou virtualizaci, para virtualizaci, atd. Což se nyní pokusím vysvětlit. - 32 -
2.4.2. Plná virtualizace 2.4.2.1. Plná virtualizace bez HW podpory V plné virtualizace bez HW podpory běží hypervisor v Ringu 0 a jádro hostovaného virtuálního stroje se přesune do Ringu 1 (viz Obrázek 15). Uživatelské Aplikace (nemodifikovaný) Hostovaný OS Privilegovaný přístup Ring 3 Ring 1 Ring 0 Nejvyšší úroveň ochrany ovladač Binární překlad Hypervisor Nejnižší úroveň ochrany Fyzický hardware Obrázek 15 - Plná virtualizace (zdroj: autor) Požadavky hostovaného OS převáděny do strojového jazyka hostitelského systému přes binární překlad (BT binary translation). Tato technika překládá binární kód, který chce při běhu vykonat jádro hosta na upravený (bezpečný) kód. Aplikace běžící v uživatelském módu (Ring 3) vykonávají svůj kód přímo, ale v případě, kdy je požadováno vykonání nebezpečného kódu (privilegované instrukce), jako je například přístup k ovladači zařízení, pak je hypervisor zachytí a přes binární překlad zajistí bezpečné volání. [4] Pokud je například požadován přístup k fyzickému hardware (např. HDD), pak je tento požadavek přeložen jako požadavek přístupu k virtuálnímu hardware (vyhrazený oddíl na disku). Tímto překladem se kód, který by měl být spuštěný v ringu 0, přesune a je spuštěn až v ringu 3. Již přeložené instrukce, jsou pro další zrychlení ukládány do cache, takže je není třeba překládat znovu. Zpoždění nastává při uživatelském volání jádra (SYSCALL, SYSENTER), kdy se uživatelský program dorozumívá s jádrem a předpokládá se, že jádro je na úrovni 0. Tam je ale nyní přesunut hypervisor. Hypervisor obsluhuje veškeré požadavky na jádro systému, překládá je a předává řízení do ring 1, tedy jádru hostovaného OS. Po zpracování operace volá jádro SYSEXIT, protože ale je v úrovni ring 1, nemá dostatečná oprávnění, vrací CPU volání do ring 0, kde je hypervisor, který se již postará o emulování návratu. Díky této režii - 33 -
I/O volání systémová volání trvají mnohem delší dobu než volání bez virtualizace. Je uváděno 10 násobné zpoždění. Výhodou je možnost spustit na hypervisoru různé OS bez jakýchkoliv modifikací. Nevýhodou je rychlost, která je v důsledku konverze strojového kódu poněkud nízká. 2.4.2.2. Plná virtualizace s HW podporou V rámci zlepšování přišli výrobci procesorů Intel (Intel VT) a AMD (AMD-V) s HW podporou virtualizace a poskytují širokou škálu funkcí pro snížení virtualizační režie na hardwarové úrovni. Technologie jsou vyvíjeny tak, aby byl při plné virtualizaci dosažen tak dobrý výkon, jako je tomu v případě paravirtualizace. Ring 3 Ring 2 Ring 1 Ring 0 Ring -1 Uživatelské Aplikace Operační Systém Privilegovaný přístup Hypervisor I/O volání Nejvyšší úroveň ochrany Nejnižší úroveň ochrany Fyzický hardware Obrázek 16 - HW-asistovaná virtualizace (zdroj: autor) Procesor, který podporuje virtualizaci s hardwarovým řízením, nabízí navíc úroveň Ring -1. Hypervisor pak běží na úrovni Ring -1, zatímco OS běží v Ringu 0. Proto se nevyžaduje binární překlad pro privilegované příkazy a příkaz je proveden přímo na hardwaru přes hypervisor, což je mnohem rychlejší než metoda samotné plné virtualizace. To významně snižuje výkonnostní mezeru mezi plnou virtualizací a paravirtualizací. (viz Obrázek 17) [17] Uživatelské Aplikace Ring 3 Nejvyšší úroveň ochrany (nemodifikovaný) Hostovaný OS Ring 0 Privilegovaný přístup ovladač Hypervisor Ring -1 Nejnižší úroveň ochrany Fyzický hardware Obrázek 17 Plná virtualizace založená na 'Intel VT-x' (zdroj: autor) - 34 -
- 35 -
2.4.3. Paravirtualizace V případě paravirtualizace není privilegovaný příkaz, který má být vykonán hostujícím operačním systémem, předán do hypervisoru operačním systémem, ale přes systémové volání hypercall. Hypervisor obdrží tento hypercall, přistoupí k hardwaru a vrátí výsledek. Předním zástupcem Paravirtualizace je XEN (viz. Obrázek 18). Ring 3 Uživatelské Aplikace (modifikovaný) Hostovaný OS Virtuální ovladače Nejvyšší úroveň ochrany Ring 1 Privilegovaný přístup (hypercall) Ring 0 I/O volání Hostující OS Hypervisor ovladač Nejnižší úroveň ochrany Fyzický hardware Obrázek 18 - Paravirtualizace podle XENu (zdroj:autor) Paravirtualizace umožní hostujícímu OS přímé řízení zdrojů, jakými jsou CPU a paměť. Je relativně rychlejší než plná virtualizace, ale velkou nevýhodou je, že jádro hostovaného operačního systému musí být upraveno tak, aby bylo možné použít volání hypercall. To je dost veliké omezení, takže na rozdíl od plné virtualizace umožňuje para virtualizace spuštění pouze omezeného počtu upravených OS. V případě Linuxu je upraveno přibližně 20% z celého kódů jádra. [4] Ring 3 Ring 1 Uživatelské Aplikace (modifikovaný, Xen) Hostovaný OS Nejvyšší úroveň ochrany I/O volání Privilegovaný přístup VMI (paravirt-opt) Ring 0 ovladač Hypervisor Nejnižší úroveň ochrany Fyzický hardware Obrázek 19 Paravirtualizace podle VMWare (zdroj:autor) - 36 -
První verze VMware pracovaly hlavně s plnou virtualizací, postupem času byla doplněna podpora paravirtualizace. V současné době, je v režimu paravirtualizace na VMware provozováno mnoho virtuálních strojů (viz. Obrázek 19). Při porovnání podpory paravirtualizace u hypervisorů VMware a Xen najdeme je malý rozdíl ve funkčnosti i výkonu. 2.4.4. Virtualizace hostitelského OS Jedná se o metodu virtualizace hostitelského OS, při které OS poskytuje funkce hypervisoru sám sobě (viz Obrázek 20): Ostatní App. App. App. (nemodifikovaný) Hostovaný OS App. Hypervisor App. (nemodifikovaný) Hostovaný OS Ring 3 Hostující OS Ring 0 Fyzický hardware Obrázek 20 Virtualizace na úrovni OS (zdroj: autor) U této metody je virtualizační prostředí provozováno v hostitelském operačním systému. Tato metoda má slabiny při přidělování zdrojů pro VM, ve výkonu a v bezpečnosti. Například v případě problému hostitelského operačního systému může dojít k zastavení všech hostovaných VM. Nicméně můžeme tuto metodu použít, pokud budete virtualizovat více OS na svém počítači. [4] 2.4.5. Virtualizace na úrovni operačního systému Tento způsob virtualizace se též říká partitioning nebo kontejnery. Metoda je určena pouze pro hosty, kteří sdílejí jeden operační systém a jeho jedno jádro, a z tohoto důvodu je tato virtualizace poměrně lehká a vykazuje dobrou výkonnost. Izoluje hosty, ale nesnaží se virtualizovat hardware. - 37 -
Ostatní App. App. App. Virtual server Environment App. App. Virtual server Environment Ring 3 Hostující OS Ring 0 Fyzický hardware Obrázek 21 Virtualizace na bázi kontejnerů (zdroj: autor) Na místo toho, zde máme kontejner pro každé virtuální prostředí. Jádro poskytuje izolaci procesů a provádí správu zdrojů. Všechny virtuální stroje běží pod stejným jádrem, ale ve skutečnosti mají svůj vlastní souborový systém, procesy, paměť, zařízení, atd. Tato metoda je velmi využívaná při virtualizaci např. webových serverů. Podklad tvoří např. distribuce CentOS. Virtualizovaná prostředí pak mohou být různé jiné distribuce např. Debian, Red Hat (RHEL), Ubuntu a další, na kterých může běžet Apache, MySQL, Sendmail, Postfix, nebo Bind. Uživatelé nepoznají, jestli je systém spuštěn na fyzickém hardware, v hypervisoru, anebo v kontejneru. Nicméně nasazení se výrazně liší. Typickými zástupci této virtualizační platformy na x86 jsou OpenVz, Solaris Containers, Jail. 2.4.6. Emulace hardware Emulátor simuluje původní fyzický hardware a umožní spouštět a provozovat operační systémy nebo aplikace na jiném hardware, než pro který byly původně napsány. Výhodou emulace je 100% nezávislost na hardware. Základním principem emulátoru je překlad strojových instrukcí hostovaného systému na strojové instrukce hostitelského stroje. Emuluje se procesor včetně registrů, emuluje se ROM paměť cílové platformy a i zbytek hardware. Virtualizace pomocí emulace umožňuje přenositelnost mezi platformami, je možné emulovat mnohaprocesorový stroj na počítači s jedním procesorem. - 38 -
Ostatní App. Aplikace A Aplikace B Ring 3 Emulátor A Emulátor B Hostující OS Ring 0 Fyzický hardware Obrázek 22 - emulace (zdroj: autor) I přes různé optimalizace, kdy se např. jednou přeložené úseky aplikace ukládají do paměti, takže je není potřeba při příštím použití již překládat, se jedná o nejméně efektivní způsob virtualizace, výkonnostní režie je vyšší než 100%. Tento způsob virtualizace volíme, když není konkrétní hardware fyzicky dostupný, je zastaralý, nebo neexistující. K nejznámějším emulátorům patři Emulátor architektury i386 pro PowerPC, nebo Emulátor MIPS procesoru na x86, nebo emulátory BOCHS, PearPC, QEMU, dále emulátory umožňující vývoj aplikací pro mobilní telefony a tablety na platformě ARM, nebo operační systémy Android, ios. Existují i neseriózní emulátory zaměřené převážně na herní HW, např. starých 8mi bitových počítačů ZX Spectrum, Atari, Amiga, ale i novějších, jako jsou PlayStation, GameBoy. 2.5. Technologie virtualizace 2.5.1. Snapshot Snapshot nám umožní zaznamenat stav zařízení k danému okamžiku (Point-in-timecopy). Po jeho vytvoření je ihned k dispozici pro další použití v aplikacích - zálohování, testování či analýza dat. Původní zdrojová data jsou po celou dobu k dispozici bez přerušení provozu, pouze s minimálním snížením datového toku, nebo výkonu. Snapshot nám umožňuje se vrátit v čase do stavu například před smazáním dat nebo před instalací problémového driveru, a tím okamžitě a bez velkého úsilí obnovit funkci serveru bez potřeby použít obnovu ze zálohy. Vytváření snapshotů má nároky nejen na výkon HW, ale hlavně v závislosti na použité metodě tvorby snapshotů a na kapacitu datového úložiště. Metod vytváření snapshotů existuje několik, každá má nějaké své výhody i nevýhody. - 39 -
Metoda Copy-on-write kopie při zápisu Jedná se o nepoužívanější metodu, kdy jsou snapshoty vytvářeny ve svém, pro snapshoty vymezeném prostoru. Při úvodním vytvoření snapshotu, jsou zkopírována jen metadata s definicemi umístění bloků originálních dat. Při požadavku na přepis originálních dat jsou bloky, které mají být přepsány, nejprve zkopírovány do prostoru vyhrazeného pro snapshoty a až následně přepsány. Princip fungování metody Copy-on-write se dá shrnout do následujícího postupu: 1. Snapshot vytvoří logickou kopii dat. (tzv. Pointry, můžeme si představit jako zástupce na ploše) 2. Požadavek na přepis originálních dat způsobí nejprve zkopírování těchto dat do prostoru vyhrazenému pro snapshoty a pak teprve přepsání dat. 3. Čtení ze snapshotu je přesměrováno na originální data, pokud ještě nebyla změněna. 4. Čtení ze snapshotu dat, která již v originální lokaci byla změněna, je provedeno ze snapshotu. 5. V případě snapshotu s povoleným zápisem nemají zápisy do snapshotu vliv na originální data. Nevýhodou Copy-on-write snapshotů je vysoký nárok na výkon zařízení, které snapshoty vytváří, protože při změně originálních dat je nutné provést dvě operace. Zkopírovat originální data do prostoru pro snapshoty a následně provést jejich změnu. Z tohoto důvodu mají zařízení, používající tuto metodu, poměrně nízké limity na maximální množství vytvořených snapshotů. [2] Metoda Split-Mirror Tato metoda je známá také jako Clone, při níž dochází k zrcadlení dat na další disky. V případě požadavku na použití snapshotu dojde k přerušení zrcadlení. Výhodou metody je fyzické oddělení kopie dat, protože při vytvoření snapshotu nedochází k zatěžování disků s originálními daty. Nevýhodou je potřeba dvojnásobné kapacity diskového úložiště. [2] Metoda Redirect-on-Write - přesměrování při zápisu Tato metoda je asi nejzajímavější ze všech uvedených. Při vytvoření snapshotu jsou originální data zmrazena a nové zápisy jsou přesměrovány do volného diskového prostoru. To platí jak pro originální data, tak pro přepis dat ve snapshotu. Další vliv snapshotu na originální data pak minimální a k jejich zatěžování dochází pouze při intenzivních čtení snapshotu. V případě použití této metody je vytvoření snapshotu méně náročné než při použití - 40 -
metody Copy-on-Write. Nevýhodou je možný problém s fragmentací, který je ale možné řešit například Automatickým Storage Tieringem, tedy metodou optimalizace rozložení uložených dat na discích. [2] 2.5.2. Clustering Pod pojmem cluster si každý může představit něco jiného, záleží i na tom, v jakém kontextu se o clusteru hovoří. Proto je třeba si rozdělit a vysvětlit funkce, které se pod tímto pojmem mohou skrývat. V našem případě se jedná se o Network Load Balancing (NLB) a Windows Cluster. Network Load Balancing (NLB) je technologie, která umožňuje spojit do clusteru několik serverů, servery tak stanou nody clusteru a vystupují pod jednou společnou virtuální IP adresou (a ARP adresou), takže klienti, kteří s touto virtuální adresou komunikují, neví, s kterým serverem ve skutečnosti komunikují. Tím je zajištěna vysoká dostupnost nabízené služby, protože když některý z nodů neběží, klient komunikuje s ostatními nody. Velikou výhodou NLB je rozklad zátěže, kdy počet klientů na jednotlivých nodech může být rovnoměrně rozkládán. Servery v tomto případě sdílejí pouze síťové adresy a žádná data, NLB clustery tedy zvyšují výkon, nebo rychlost odezvy klientovi. Nejčastěji se používají na web serverech, DNS serverech, terminálových farmách a VPN serverech, apod. Windows Cluster naopak data sdílí, umožňuje několika serverům přistoupit k jednomu datovému úložišti tzv. CSV (Cluster Shared Volume), což je většinou diskové pole, které může mít i více nodů, kde jsou uloženy sdílená data, dnes nejčastěji virtuální servery nebo storage. Virtuální servery jsou pak rovnoměrně rozloženy a spouštěny jednotlivých serverech a teprve pokud dojde k na některém ze serverů k problému (k jeho přetížení, nedostupnosti, nebo hw, či sw havárii), dojde k přesunu nebo ke spuštění virtuálních serverů na ostatních serverech. Tento typ clusteru nezajistí vyšší výkon, ale zajistí vysokou dostupnost nabízených služeb. Při této technologii nám jednotlivé nody sdílejí data a proto se s ní setkáme typicky při požadavku zajištění vysoké dostupností mail serverů (Microsoft Exchange, Lotus Domino), databázových serverů (Microsoft SQL, Oracle), souborových a tiskových serverů (DFS).. - 41 -
Obrázek 23 - Konfigurace clusteru ve Windows serveru 2012 R2 (zdroj: autor) Obrázek 24 - Konfigurace převzetí serveru v clusteru na Windows 2012 R2 (zdroj: autor) Je třeba vědět, že nás žádný cluster neochrání před: - Ztrátou, nebo zničením sdíleného diskového prostoru - Síťovými problémy na klientské straně - Aplikačními problémy (špatná konfigurace) - Poškozením databází (Exchange, SQL) Zálohovací technologie mají stále své uplatnění a jsou stále potřeba. - 42 -
2.5.3. Zálohování Proces zálohování a obnovy dat by měl být součástí správy každého serveru nebo aplikace, resp. dat a dokumentů. Důležitost zálohování podtrhuje známé rčení, že firmy se dělí na ty, které zálohují a ty, které teprve o data přijdou. Z praxe mohu doplnit, že o zálohování a archivaci se zajímají spíše větší firmy, případně ty, kterým je zálohování a archivace uloženo předpisy. Malé a střední firmy důležitost zálohování snižují a příliš neřeší. I v případě, kdy jim zálohování připravíme a nastavíme a oni mají jen vyměňovat média, se stane, že je vymění jen občas, když si vzpomenou, případně nikdy. Proto je vhodné zálohování co nejvíce automatizovat, což právě virtuální prostředí umožňuje. Proces zálohování je třeba implementovat na základě požadavků a potřeb zákazníka s ohledem na RPO a RTO. Cílem je dosáhnout ideálního vyvážení mezi uvedenými ukazateli a finanční náročností. Zálohování ve virtuálním prostředí dělíme na dva základní modely: - Zálohování na úrovni hostů, kdy jsou v jednotlivých serverech instalování agenti, pomocí kterých je záloha realizována. - Zálohování na úrovni hypervisorů, kdy je prováděna kopie celých virtuálních strojů. Hypervisor Obrázek 25 - Zálohování řešené agenty instalovanými v jednotlivých OS (zdroj: wmvare.com upraveno) Hypervisor Obrázek 26 - Zálohování řešené na úrovni hypervisorů, kdy jsou zálohovány image virtuálních serverů (zdroj: wmvare.com upraveno) - 43 -
VMware nabízí pro zálohování svých virtuálních strojů aplikaci VMware Data Protection, která je dostupná ve všech edicích mimo verze VMware Essentials. Microsoft nabízí zálohovací aplikaci Windows Server Backup jako součást serveru Windows server 2012 R2. Alternativní aplikací pro zálohování serverů ve virtuálním prostředí na platformách VMware vsphere a Microsoft Hyper-V je Veeam Backup and Replication. Využívá komprimace a deduplikace dat, ale její hlavní předností je inkrementální zálohování na principu záznamu změněných bloků na úrovni hypervisoru (Tzv. CBT Changed Block Tracking). Zálohy jsou proto malé, rychlé a průběh zálohování nezatěžuje systém, takže může probíhat i za běhu virtuálních serverů. Veeam vezme všechny nebo vybrané virtuální pevné disky a konfigurační soubory do jedné komprimované zálohy, kterou je možné obnovit v jiném hostiteli. [23] 2.5.3.1. Přírůstková záloha Obrázek 27 - Přírůstková záloha (zdroj: www.veeam.com) V případě přírůstkové zálohy, může být např. vždy o víkendu provedena časově náročná, plná komprimovaná záloha a následně je pak každý prováděna záloha rozdílová. 2.5.3.2. Reverzní přírůstková záloha U reverzní rozdílové zálohy je první den provedena plná komprimovaná záloha a následující den je pak provedená záloha rozdílová. Denní rozdílová záloha je následně synteticky přepočtena na zálohu plnou a ze změn provedených při spojení vznikne soubor reverzní přírůstkové zálohy za předešlý den. Toto se denně opakuje. - 44 -
Obrázek 28 - Reverzní přírůstková záloha (zdroj: www.veeam.com) Metoda má výhodu v menších požadavcích na úložiště, protože máme jen jednu plnou zálohu, ale v případě obnovy o několik dnů zpět, je potřeba provést postupnou aplikaci rozdílových záloh. [23] Součástí každého procesu zálohování, by měl být plán záloh, kdy jednotlivé zálohy dělíme na denní, týdenní, měsíční (poslední den), kvartální a roční (roční záloha => archiv). Zálohování by mělo být automatizované a měla by probíhat pravidelná kontrola a evidence výsledků záloh, kontrola logů a plánované testy obnovy zálohovaných dat a mělo by pokračovat archivací dat. 2.6. Vysoká dostupnost 2.6.1. Co to je vysoká dostupnost? V dnešním světě je trvalá dostupnost 24/7 nabízených služeb nezbytná, protože pokud systémy neběží nebo mají časté nevyjasněné výpadky, jdou zákazníci jinam, hledají jiného dodavatele služeb. Cílem vysoké dostupnosti HA (High Availability) je udržet systémy, služby, aplikace, databázové a poštovní servery vždy dostupné. Problémů, které mohou způsobit nedostupnost služeb, je mnoho, od obrazně řečeno poškozeného ventilátoru na procesoru, vadného disku, zdroje, nebo routeru anebo jiného hardware, až po požár, nebo povodeň. Proto se služby vždy nabízejí s tzv. devítkami, kterými poskytovatel garantuje klientům dostupnost svých služeb. S každou přidanou devítkou se zvyšuje cena řešení, protože se musí minimálně zdvojovat veškerý hardware a software a tím se zvyšuje i cena nabízené služby. - 45 -
Procentuální dostupnost za rok (hodiny znamenají dobu výpadku) Dostupnost v % 24hodinový den 8hodinový den 90% 876 hodin (36.5 dní) 291.2 hodin (12.13 dní) 95% 438 hodin (18.25 dní) 145.6 hodin (6.07 dní) 99% 87.6 hodin (3.65 dní) 29.12 hodin (1.21 dní) 99.9% 8.76 hodin 2.91 hodin 99.99% 52.56 minut 17.47 minut 99.999% 5.256 minut 1.747 minut 99.9999% 31.536 sekund 10.483 sekund Výpadek nám může způsobit i zcela normální provozní činnost, kterou provádět musíme, jako jsou aktualizace operačních systémů, aktualizace aplikací, údržba a upgrade hardware, nebo aktualizace firmware a proto s ním musíme počítat. 2.6.2. Jak by mělo vypadat řešení HA Redundance veškerého hardware (síťové prvky, internetové konektivity, elektrické přívody) Dva a více serverů (redundance všeho) Každý serverový node může hostovat 1+ HA aplikací či služeb Každý node ví, co hostují ostatní nody díky cluster databázi (viz.: Obrázek 34) Cluster databáze je replikována napříč všemi nody Sdílené úložiště SAN je přístupné pro všechny nody Aplikační data jsou zapsána do sdíleného úložiště CSV Nody sledují zdraví ostatních nodů Pokud node havaruje, selže celková kontrola a nastane failover Další node ve své failover databázi ověří, co běželo na havarovaném nodu Virtuální server a aplikace nastartuje na dalším nodu ze sdíleného úložiště Klienti mohou zaznamenat krátký výpadek služby během startu na jiném nodu - 46 -
2.6.3. Typy clusteringu 2.6.3.1. Clustering hostitelů - Služba Cluster je spuštěna na fyzickém hostiteli a spravuje VM - VM se přesunují mezi nody clusteru Cluster Node 1 Node 2 SAN Diskové pole Obrázek 29 - Clustering hostitelů (zdroj: autor) 2.6.3.2. Clustering hostů - Služba Cluster je spuštěna ve VM - Aplikace a služby ve VM jsou spravovány clusterem - Aplikace se přesunují mezi nody clusteru Cluster Node 1 Node 2 iscsi Diskové pole Obrázek 30 - Clustering hostů (zdroj: autor) - 47 -
3. Virtualizační platformy Jak již bylo uvedeno, dnes nejrozšířenější a komerčně nejúspěšnější virtualizační platformy jsou vsphere od VMware a Hyper-V od Microsoftu. Jejich poslední dostupné verze jsou VMware vsphere 5.5 a Microsoft Server 2012 R2. 3.1. VMware nebo Microsoft? Co vybrat, VMware, nebo Microsoft? Obě platformy nabízí velké množství funkcí, které jsou si velmi podobné, jen se jinak jmenují, proto je jejich srovnání chvílemi připomíná srovnání jablka s pomerančem. I když jablku, resp. Applu by se to nemuselo líbit. 3.1.1. Základní cenové srovnání Obrázek 31 - srovnání cen Microsoft a VMware (zdroj:microsoft) V porovnání není uveden zvýhodněný balíček Essentials, který umožní instalovat ESX na 3 fyzické servery, každý s maximálně dvěma procesory. VMware vsphere 5.5 Essentials je v ceně cca 18.000,-Kč bez DPH a vsphere 5.5 Essentials +, který navíc přidává vmotion a HA je v ceně cca 120.000,-Kč bez DPH. [12] - 48 -
3.1.2. Základní porovnání MS Hyper-V a VMware vsphere System Resource Windows Server 2012 R2 Hyper-V vsphere Hypervisor vsphere 5.5 Enterprise Plus Logical Processors 320 320 320 Host Physical Memory 4TB 4TB 4TB Virtual CPUs per Host 2,048 4,096 4,096 Virtual CPUs per VM 64 8 64 1 VM Memory per VM 1TB 1TB 1TB Active VMs per Host 1,024 512 512 Guest NUMA Yes Yes Yes Cluster Maximum Nodes 64 N/A 2 32 Maximum VMs 8,000 N/A 2 4,000 1. vsphere 5.5 Enterprise Plus is the only vsphere edition that supports 64 vcpus. Enterprise edition supports 32 vcpu per VM with all other editions supporting 8 vcpus per VM 2. For clustering/high availability, customers must purchase vsphere [12] 3.1.3. Možnosti nasazení Capability Microsoft VMware Deployment from DVD Yes Yes Deployment from USB Yes Yes PXE Deployment - Stateful Yes WDS, MDT, SCCM, SCVMM Yes PXE/Auto Deploy 1 PXE Deployment - Stateless No Yes Auto Deploy 1. A Stateful option for Auto Deploy was introduced in vsphere 5.1 after previously only providing a stateless, in-memory version in 5.0. [12] - 49 -
3.1.4. Podpora úložišť Capability Hyper-V (2012 R2) vsphere Hypervisor vsphere 5.5 Enterprise Plus iscsi/fc Support Yes Yes Yes 3 rd Party Multipathing (MPIO) Yes No Yes (VAMP) 1 SAN Offload Capability Yes (ODX) No Yes (VAAI) 2 Storage Virtualization Yes (Spaces) No Yes (vsan) 3 Storage Tiering Yes No Yes 4 Network File System Support Yes (SMB 3.0) Yes (NFS) Yes (NFS) Data Deduplication Yes No No Storage Encryption Yes No No 1. vsphere API for Multipathing (VAMP) is only available in Enterprise & Enterprise Plus editions of vsphere 5.5 2. vsphere API for Array Integration (VAAI) is only available in Enterprise & Enterprise Plus editions of vsphere 5.5 3. vsphere vsan is still in beta 4. vsphere Flash Read Cache has a write-through caching mechanism only, so reads only are accelerated. vsan also has SSD caching capabilities built in, acting as a read cache & write buffer. [12] 3.1.5. Síťování Advanced Networking Capability Hyper-V (2012 R2) vsphere Hypervisor vsphere 5.5 Enterprise Plus Integrated NIC Teaming Yes Yes Yes Extensible Network Switch Yes No Replaceable Confirmed Partner Solutions 5 N/A 2 Private Virtual LAN (PVLAN) Yes No Yes 1 ARP Spoofing Protection Yes No vcloud/partner 2 DHCP Snooping Protection Yes No vcloud/partner 2 Virtual Port ACLs Yes No vcloud/partner 2-50 -
Trunk Mode to Virtual Machines Yes No Yes 3 Port Monitoring Yes Per Port Group Yes 3 Port Mirroring Yes Per Port Group Yes 3 1. The vsphere Distributed Switch (required for PVLAN capability) is available only in the Enterprise Plus edition of vsphere 5.5 and is replaceable (By Partners such as Cisco/IBM) rather than extensible. 2. ARP Spoofing, DHCP Snooping Protection & Virtual Port ACLs require the vcloud Networking & Security package, which is part of the vcloud Suite or a Partner solution, all of which are additional purchases 3. Trunking VLANs to individual vnics, Port Monitoring and Mirroring at a granular level requires vsphere Distributed Switch, which is available in the Enterprise Plus edition of vsphere 5.5. [12] 3.1.6. Cluster Capability Hyper-V (2012 R2) vsphere Hypervisor vsphere 5.5 Enterprise Plus Integrated High Availability Yes No 1 Yes 2 Maximum Cluster Size 64 Nodes N/A 32 Nodes Maximum VMs per Cluster 8,000 N/A 4,000 Failover Prioritization Yes N/A Yes 4 Affinity Rules Yes N/A Yes 4 Guest OS Application Monitoring Yes N/A Yes 3 Cluster-Aware Updating Yes N/A Yes 4 1. vsphere Hypervisor has no high availability features built in vsphere 5.1 is required. 2. VMware HA is built in to Essentials Plus and higher vsphere 5.1 editions 3. VMware App HA only available in 5.5 Enterprise Plus and requires deployment of 2 appliances per vcenter 4. Features available in all editions that have High Availability enabled. [12] Capability Hyper-V vsphere vsphere 5.5-51 -
(2012 R2) Hypervisor Enterprise Plus Max Size Guest Cluster (iscsi) Max Size Guest Cluster (Fiber) Max Size Guest Cluster (File Based) Guest Clustering with Shared Virtual Disk Guest Clustering with Live Migration Support 64 Nodes 5 Nodes 1 5 Nodes 1 64 Nodes 5 Nodes 2 5 Nodes 2 64 Nodes 5 Nodes 1 5 Nodes 1 Yes Yes 6 Yes 6 Yes N/A 3 No 4 Guest Clustering with Dynamic Memory Support Yes No 5 No 5 1. Guest Clusters can be created on vsphere 5.5 with a maximum of 5 nodes 2. Shared storage for Quorum and/or Data must be on Fibre Channel (FC) based RDMs (physical mode for clusters across physical hosts, virtual mode for clusters on a single host) 3. vmotion unavailable in the vsphere Hypervisor 4. VMware does not support vmotion and Storage vmotion of a VM that is part of a Guest Cluster 5. VMware does not support the use of Memory Overcommit with a VM that is part of a Guest Cluster 6. Guest Clustering with Shared Virtual Disks are only supported as a Cluster in a Box i.e. multiple VMs on a single host. [12] 3.1.7. Virtuální stroje Capability Hyper-V (2012 R2) vsphere Hypervisor vsphere 5.5 Enterprise Plus Virtual CPUs per VM 64 8 64 1 Memory per VM 1TB 1TB 1TB Dynamic Memory Yes Yes Yes Maximum Virtual Disk Size 64TB 62TB 62TB Online Virtual Disk Resize Yes Grow Only Grow Only - 52 -
Storage QoS Yes No Yes Virtual Fibre Channel Yes Yes Yes Dynamic Virtual Machine Queue Yes NetQueue 2 NetQueue 2 IPsec Task Offload Yes No No SR-IOV with Live Migration Yes No 3 No 3 Virtual Receive Side Scaling Yes Yes (VMXNet3) Yes (VMXNet3) Network QoS Yes No Yes VM Live Cloning Yes No Yes 4 1. vsphere 5.5 Enterprise Plus is the only vsphere edition that supports 64 vcpus. Enterprise edition supports 32 vcpu per VM with all other editions supporting 8 vcpus per VM 2. VMware vsphere and the vsphere Hypervisor support VMq only (NetQueue) 3. VMware s SR-IOV implementation does not support vmotion, HA or Fault Tolerance and is only available as part of the vsphere Distributed Switch 4. Live Cloning requires vcenter [12] 3.1.8. Migrace virtuálních strojů Capability Hyper-V (2012 R2) vsphere Hypervisor vsphere 5.5 Enterprise Plus VM Live Migration Yes No 1 Yes 2 VM Live Migration with Compression VM Live Migration over RDMA Yes No No Yes No No 1GB Simultaneous Live Migrations Unlimited 3 N/A 4 10GB Simultaneous Live Migrations Unlimited 3 N/A 8 Live Storage Migration Yes No 4 Yes 5 Shared Nothing Live Migration Yes No Yes 5 Live Migration Upgrades Yes N/A Yes - 53 -
1. Live Migration (vmotion) is unavailable in the vsphere Hypervisor vsphere 5.5 required 2. Live Migration (vmotion) and Shared Nothing Live Migration (Enhanced vmotion) is available in Essentials Plus & higher editions of vsphere 5.5 3. Within the technical capabilities of the networking hardware 4. Live Storage Migration (Storage vmotion) is unavailable in the vsphere Hypervisor 5. Live Storage Migration (Storage vmotion) is available in Standard, Enterprise & Enterprise Plus editions of vsphere 5.5 6. Live Cloning requires vcenter [12] 3.1.9. Další srovnání Podobných srovnání VMware vsphere a Microsoft Hyper-V je na internetu několik. Přehledné srovnání zveřejnil 15.10.2013 na svém blogu Keith Mayer. K dispozici je zde: http://blogs.technet.com/b/keithmayer/archive/2013/09/24/vmware-or-microsoftcomparing-vsphere-5-5-and-windows-server-2012-r2-at-a-glance.aspx#.uy9qwfmbmrv Ze srovnání jednotlivých funkcionalit je zřejmé, že možnosti obou platforem jsou velmi podobné, každá má své klady a své zápory, které je třeba posuzovat při zpracování návrhu konkrétního řešení. - 54 -
3.2. VMware VMware je dnes jedním lídrů na poli virtualizace a prakticky udává směr, jak bude virtualizace fungovat a jakým směrem se bude ubírat, ostatní ho zatím následují a dohánějí. Hypervisor ESXi vyšel z RedHat linuxu, dnes se ale jedná o placený projekt, zdrojové kódy jsou uzavřené a veřejně nedostupné. Funkcionality, které nabízí virtualizace na linuxových distribucích zdarma, je zde třeba zakoupit, i když po registraci je možné stáhnout a používat free verzi VMware vsphere Hypervisor, která má omezení 32GB RAM a 8 virtuálních CPU. Placené verze VMware vsphere je možné zakoupit ve verzích Standard, Enterprise a Enterprise Plus. K dispozici jsou i dvě zvýhodněné sady vsphere Essentials a Essentials Plus, které jsou omezeny na 3 fyzické servery, každý se dvěma procesory a další rozšíření není možné. Obě verze obsahují vcenter Centralized Management a Enterprise-class Server Consolidation. Verze Essentials Plus obsahuje navíc vmotion, High Availability a Data Recovery pro zajištění vysoké dostupnosti. K vytváření a správě virtuálních strojů je určený volně dostupný nástroj VMware vsphere Client. Podporované hostované operační systémy jsou, všechny verze Windows od verze 3.1 a Windows NT, dokonce i MS-DOS, dále Novell Netware, různé verze Linuxu a Solaris. 3.2.1. Funkce virtualizace od VMware O virtualizaci od VMware je na internetu dostupných mnoho informací, takže pro základní přehled vyberu jen ty základní a nejpoužívanější aplikace a funkcionality z www.vmware.com. Hlavní stavební částí virtualizace je produkt vsphere, ve verzi 5.5, která podporuje platformy Intel VT-x a AMD-V. Jedná se o nejnovější verzi virtualizační platformy VMware, která je také známá jako "ESXi", což je vlastně název pro hypervisor této architektury. Zdarma je možné použít vsphere Hypervisor, jedná se o stejný produkt jako VMware vsphere, kde se vložením licenčního čísla aktivují zakoupené funkce. Pro správu virtuálních serverů na jednom fyzickém serveru je možné použít vsphere, ale v případě že spravujeme více virtuálních strojů, je vhodné použít nástroj VMware vcenter Server, který je v případě verze Essentials součástí balíčku s omezením na licenci Essentials, ale jinak se jedná o placenou aplikaci. VMware vcenter Server je určený pro správu jednotlivých VMware vsphere, bez ohledu na počet virtuálních strojů. Poskytuje - 55 -
jednotnou správu všech hostitelů a virtuálních strojů z jednom ovládacím panelu se souhrnným monitoringem výkonu clusterů, hostitelů a virtuálních strojů. Nejpoužívanější nástroje jsou: - VMware High Availability (HA), která poskytuje vysokou dostupnost nezávislou na hardwaru pro virtuální stroje na VMware ESXi serverech. - VMware vmotion - Live Migration, je určena k migraci virtuálních strojů za běhu mezi hostiteli (fyzickými servery). Tato funkce odstraňuje prodlevy při upgradech a pravidelné údržbě a řeší i otázku přetížení serveru. - vsphere Data Protection, zajistí zálohu a obnovu virtuálních strojů bez agentů s minimálními požadavky na systémové prostředky. - vshield Endpoint, poskytuje antivirus a antimalware ochranu bez agentů pro bezpečnost Vašich virtuálních strojů. - vsphere Replication poskytuje nízkonákladovou replikaci virtuálních strojů 3.3. Hyper-V Microsoft Hyper-V je serverově orientovaný hypervizor architektury x86-64, jehož první verze byla vydána 26 června 2008 pro Windows Server 2008. Dnes je ve Windows Server 2012 R2 dostupná Hyper-V ve verzi 3. Podporuje platformy od Intel VT-x a AMD-V. Stejně jako u VMware i zde se jedná o komerční řešení, kdy Hyper-V doinstaluje jako role Windows serveru. Zdarma nabízí Microsoft, tzv. core instalaci bez managementu. Microsoft napsal svůj hypervizor tak, že obsahuje jen hlavní programové části a proto je relativně malý a snadněji udržovatelný, vše ostatní je delegováno do tzv. privilegovaného virtuálního počítače, který je označený jako Parent Partition, tímto počítačem, je celé prostředí řízeno. Zároveň má jako jediný počítač přímý přístup k hardwaru, který nabízí ostatním virtuálním počítačům označeným jako Child Partition. Veškerý hardware v Child Partition je virtuální a přístup k němu lze dělit na kategorie, emulovaný a paravirtualizační. Viz. kapitola 2.1.2 Rozsah oficiálně podporovaných hostovaných operačních systémů není tak rozsáhlý jako v případě VMware. Podporovány jsou všechny verze Windows Serveru od verze Windows Server 2000 s SP4 až po Windows Server 2012, desktopové operačních systémy s výjimkou home edicí. U linuxových distribucí je situace horší, protože oficiálně jsou podporovány jen distribuce SUSE, RHEL a CentOS. - 56 -
Problém může být ale v tom, že pod termínem podpora si VMware představuje něco jiného než Microsoft. Zatímco Microsoft uvádí, že podporuje jen produkty, u kterých je schopen zajistit skutečnou podporu výrobce, se kterým má smlouvu o spolupráci a podpoře, VMware uvádí všechny produkty, které jdou do vsphere instalovat a fungují, přičemž podporuje i Windows NT, které Microsoft již několik let nepodporuje. [12] 3.3.1. Funkce virtualizace od Microsoftu Microsoft má všechny funkce se základními funkcemi dostupné v aplikaci Hyper-V Manager, ve kterém je možné virtuální stroje instalovat, spravovat, je zde možné provést migraci, nastavit i repliku a cluster. Zálohu virtuálních strojů, je možné provést v aplikaci Windows Server Backup. Rozšířené možnosti správy pak Microsoft nabízí přes placený produkt System Center, který je ve verzích Standard a Datacenter a obsahuje: - Virtual Machine Manager zajišťuje správu virtualizovaného prostředí, rozdělování fyzických prostředků, umožňuje vytvářet šablony služeb. - Configuration Manager - nástroj pro řízení a správu koncových zařízení a serverů. Mezi klíčové vlastnosti tohoto nástroje patří detailní HW, SW inventarizace, měření skutečného využívání SW, porovnávání konfigurací počítačů pomocí definovaných šablon napříč organizací, zejména však distribuce aplikací a operačních systémů bez zásahu administrátora (zero-touch). - Endpoint Protection jedná se antimalware řešení, jehož správa je plně integrována do nástroje Configuration Manager. - Data Protection Manager - představuje ideální řešení pro zálohování a obnovu dat v prostředí Windows. [26] Další nástroje jsou určeny pro vyšší úroveň správy a dohledu: - Operations Manager - Proaktivní dohledový systém, který poskytuje expertní analýzu heterogenního IT prostředí. Umožňuje detailně monitorovat infrastrukturu, síťové prvky, operační systémy a aplikace. Poskytuje centrální pohled na zdraví celého IT prostředí a výrazně přispívá k efektivnímu řešení problémů a dodržování SLA. - Orchestrator - Nástroj pro automatizaci IT procesů, který snižuje provozní náklady a zvyšuje efektivitu IT díky tomu, že urychluje poskytování služeb a omezuje - 57 -
množství chyb. Dosahuje toho nahrazením ručně prováděných činností s vysokými nároky na prostředky standardizovanými a automatizovanými procesy. - Service Manager - Platforma pro centrální řízení a správu IT pomocí definovaných postupů a procesů. Tyto postupy vycházejí například ze specifikace Microsoft Operations Framework (MOF) nebo knihovny Information Technology Infrastructure Library (ITIL). Umožňuje vybudování vlastního katalogu služeb, který je pro uživatele publikován na portálu Service Manageru. Součástí procesů mohou být díky vysoké míře integrace využívány a řízeny další produkty System Center. [12][26] - 58 -
4. Návrh řešení pro malé firmy Máme za úkol navrhnout vhodné řešení virtualizace web serveru, SQL serveru a serveru pro běžnou agendu pro malou společnost s použitím dvou fyzických serverů zapojených ve failover clusteru a se zálohováním. Mějme vstupní informace, že společnost má 25 pracovníků, kteří budou serverové řešení využívat, budou využívat souborový server, tisk a poštovní server. K databázovému serveru bude přistupovat 15 pracovníků ekonomického a obchodního oddělení a vedení. Webový server je určen pro veřejnost. - Souborový server na platformě OS Windows o Pracovní dokumenty, sdílení adresářů, tisky o Neveřejná IP adresa - Databázový server na platformě OS Windows, MS SQL o SQL server pro účetní aplikaci o Neveřejná IP adresa - Webový server na platformě Linux, LAMP, Postfix o Internetová prezentace, emailový server o Veřejná IP adresa 4.1. Jak vybírat optimální řešení Návrh hardwarového a softwarového řešení musí vycházet z požadavků a potřeb zákazníka, nicméně v praxi, hlavně u malých firem je to často tak, že zákazník předpokládá, že mu bez potřebných informací předložíme nabídku o několika variantách, ze kterých si vybere. Domnívá se, že je to nejlepší postup k vyřešení jeho problémů s IT. Má svého IT správce, nemá ale stanovenu žádnou informační strategii, možná ani globální strategii. Výpočetní techniku nakupuje vždy podle aktuální potřeby a nyní potřebuje vyměnit servery. Zálohování mu v tuto chvíli funguje, takže ho bude řešit, až fungovat nebude. Naše otázky, kterými si chceme upřesnit jeho potřeby a požadavky, pak mohou působit nevhodně, zákazník se může začít domnívat, že si s jeho jednoduchým požadavkem nevíme rady, nebo že mu chceme prodat i další produkty, které nepotřebuje a nechce, že ho zbytečně zdržujeme a začne hledat jiného dodavatele. - 59 -
Proto je vhodné si se zákazníkem domluvit na základní analýze současného stavu a na sjednocení a pochopení požadavků a cílů, kterých chceme dosáhnout. V případě větší společnosti, je třeba se domluvit nejen s managementem, ale i se správcem IT a případně s klíčovými pracovníky společnosti, abychom si ověřili, že námi předložené řešení bude moderní, dostatečně dimenzované a že skutečně vyřeší problém. Může se totiž ukázat, že dodávka nového hardware by očekávané zlepšení nepřinesla. Problémy může ve skutečnosti způsobovat nevhodný, nebo špatně nastavený informační systém, nebo nechuť pracovníků tento systém používat, anebo třeba poruchové síťové aktivní prvky. Musíme zjistit, jakou stávající techniku chce zákazník zachovat a jakou vyměnit a kdy, co vše plánuje na nových serverech provozovat, jaké služby a aplikace, a v jakých verzích. Dále jaké bude předpokládané množství dat a jak rychle budou data přibývat, tedy jaké budou požadavky na kapacity diskového subsystému. A nesmíme zapomenout na zálohování. Tím se dostáváme k dalšímu velmi důležitému parametru, který výrazně ovlivňuje celé řešení a to jak cenou, tak svou složitostí. Jedná se o požadavky na dostupnost, resp. nedostupnost, tedy jakou bude zákazník tolerovat případnou nedostupnost některých aplikací, služeb, nebo celého řešení. Tyto hodnoty jsou definovány parametry RTO a RPO. RTO (Recovery Time Objective) - je maximální doba výpadku, tedy čas, kdy uživatelé nemohou pracovat. Tato doba se dá ovlivnit záložním hardwarem. RPO (Recovery Point Objective) je maximální přípustná ztráta dat. Tedy kam se vrátíme v čase po opravě a obnově dat, což je vlastně doba, kdy proběhla poslední záloha. Je asi jasné, že čím menší má být ztráta dat, nižší RTO, tím častější musí být prováděna záloha a tím dražší bude celé řešení. Z praxe vím, že vysvětlení této problematiky některým manažerům, nebo majitelům menších firem je velmi problematické. Domnívají se, že když se zálohuje, tak je vše bez problému a v případě havárie že uděláme cvak a vše bude fungovat dál. Často je tedy překvapí, že jen obnova dat bude trvat několik hodin a že budeme potřebovat nový, nebo druhý hardware, na kterém obnovená data, nebo servery spustíme. A opravu jim kolikrát nedochází, že když se zálohuje jen v noci, že není možné obnovit data do chvíle před výpadkem, který proběhl v poledne. O další technice budeme nyní předpokládat, že je bez problémů a nebudeme ji řešit. Tedy přívody 230V, záložní zdroje UPS, klimatizace, internetová konektivita, síťové prvky, routery, atd. - 60 -
4.1.1. Virtualizace Pro zvýšení spolehlivosti navrhovaného řešení, umožnění přesunu virtuálního serveru na jiný hardware a pro kvalitní a efektivní zálohování budeme používat virtualizaci. K uložení virtuálních strojů můžeme použít lokální disky serverů anebo diskové pole, které můžeme k fyzickým serverům připojit několika způsoby. Virtuální stroje můžeme spouštět a provozovat na: - lokálních discích v serveru - na diskovém poli, připojeném přes iscsi - na diskovém poli, připojeném přes SAS - na diskovém poli, připojeném přes FC Uvedené pořadí je srovnáno od nejpomalejšího, po nejrychlejší, resp. od nejlevnějšího řešení po nejdražší. 4.1.2. Replikace virtuálních serverů Máme sice připravit CSV cluster, ale je vhodné si ověřit, jestli ho zákazník opravdu potřebuje, protože existuje jednodušší a levnější varianta -> replikace. Máme dva stejné fyzické servery (hypervisor 1 a hypervisor 2) s virtuálními servery (SQL, FILE a WWW) a provádíme jejich replikace z jednoho fyzického serveru na druhý. Pro lepší rozložení zátěže máme na prvním serveru jen SQL server a na druhém pak server FILE a WWW. LAN Ethernet 1Gb/s Servery Servery SQL SQL FILE FILE WWW WWW Hypervisor 1 Hypervisor 2 Obrázek 32 - Replikace serverů (zdroj: autor) - 61 -
Provoz replikací může zajišťovat aplikace Veeam Backup and Replication, která podle nastavení v pravidelných intervalech provádí repliky jednotlivých hostů na druhý server. Viz. Obrázek 32. V případě problému s hardwarem jednoho fyzického serveru můžeme relativně rychle spustit virtuální servery na druhém serveru. V tomto případě je třeba počítat se ztrátou dat, která je daná četností replikace. V případě že replikace probíhá každých 15 minut, bude ztráta dat maximálně 15 minut. 4.1.3. Virtuálních servery v CSV clusteru Druhou, složitější a dražší variantou je uložení virtuálních serverů na diskovém poli, které je připojeno k dvěma fyzickým serverům. Virtuální servery jsou spouštěny z diskového pole. Pro lepší rozložení zátěže máme podobně jako v případě replikace na prvním serveru spuštěn SQL server a na druhém pak servery FILE a WWW. V případě potíží jednoho fyzického serveru dojde k přesunu a spuštění virtuálních serverů na druhém serveru. K přepnutí dojde v řádu sekund, výpadek síťové komunikace je skoro nezměřitelný. Konzole pro správce clusteru v serveru Windows 2012 R2 je na Obrázek 23. LAN Ethernet 1Gb/s Servery Servery Hypervisor 1 Hypervisor 2 Diskové pole Obrázek 33 Zapojení serveru v CSV clusteru (zdroj: autor) Připojení diskového pole k serverům, na obrázku 33 není záměrně upřesněno, může být řešeno přes iscsi, SAS nebo optický spoj. - iscsi je jednoduché a přitom výkonné řešení. Vychází z rozšířených a známých technologií, a to je SCSI rozhraní pro připojování disků v serverech, a technologie protokolu TCP/IP. - 62 -
- SAS (Serial Attached SCSI) je rozhraní "point-to-point", řadič je s každým zařízením propojen samostatným kabelem. Výhoda tohoto řešení je, že závada jednoho zařízení neohrozí komunikaci se všemi ostatními. - FC jedná se o SAN - Storage Area Network. K propojení serverů a diskového pole se používá technologie Fibre Channel, tedy optický kabel, který dokonale elektricky odděluje připojená zařízení a umožňuje propojení desítky i stovky metrů. 4.2. Výběr software Nyní musíme vybrat vhodné virtualizační prostředí a operační systémy pro aplikace a služby. Seznam virtuálních serverů již známe: - Souborový server platforma OS Windows - Databázový server platforma OS Windows, MS SQL - Webový server platforma Linux, LAMP, Postfix Budeme tedy instalovat 2x virtuální server Windows server 2012 R2 (aktuální verze) pro souborový a SQL server a 1x virtuální server linuxového serveru Centos 6.5 (aktuální verze) pro webový a poštovní server. V případě výběru virtualizační platformy se budeme rozhodovat mezi MS Hyper-V a mezi VMware. Výhodou řešení od Microsoftu je, že role Hyper-V je zakoupena společně s Windows serverem 2012 R2. Další výhodou je, že správa a ovládání virtuálního prostředí je podobné standardní správě serveru, takže technik, který ví, jak virtualizace pracuje, zvládne její zprovoznění během několika málo hodin. Výhodou se může zdát i lokalizace do češtiny, ale v případě řešení problémů, jsou chyby prezentované v českém jazyce hůře dohledatelné, nebo spíše nedohledatelné na internetu. V případě výběru řešení od VMware je třeba dokoupit licenci. Protože máme jen dva fyzické servery, bude nám stačit verze VMware vsphere 5.5 Essentials Plus, která je určena pro maximálně 3 fyzické servery, každý s maximálně 2x CPU, a která obsahuje funkcionality vmotion (bez možnosti plánování) a High Availability. Každý rok, je pak třeba zakoupit maintenance, která je v ceně 25% nové licence. V případě, že by nebyl vyžadován CSV cluster, ale stačila by replikace, bylo by možné zakoupit levnější VMware vsphere 5.5 Essentials bez HA a vmotion a pro replikace využít aplikaci Veeam Backup and Replication. - 63 -
4.2.1. Zálohování Pro plánovanou replikaci a zálohování je možné v případě VMware použít aplikace vsphere Replication a Data Protection. V případě virtualizace pod Microsoft Windows 2012 R2 pak Hyper-V Replica a Windows Backup. Případně je možné zvolit software Veeam Backup and Replication ve verzi Standard, který může pracovat na obou platformách. Zatímco v licenci Microsoft si uvedené aplikace zakoupíme a Microsoft po dobu podpory vydává aktualizace, tak v případě VMware a Veeam je třeba každý rok zakoupit maintenance, která nám umožňuje stáhnout a instalovat poslední aktuální verzi. Maintenance je v ceně 25% nové licence. 4.3. Výběr hardware Důležitým kritériem pro výběr hardware je jeho spolehlivost, budeme vybírat hardware se záruční dobou alespoň 3 roky a s dostupným pozáručním servisem. Pro rychlé řešení oprav či zkrácení případných výpadků HW, je vhodné zakoupit rozšířenou záruku, on-site v režimu 9x5, nebo 24x7. Ze zkušenosti ale vím, že si malé společnosti rozšířenou záruku nezakoupí a proto je vhodné jim doporučit nákup klíčových prvků na sklad. (např. pevný disk, náhradní zdroj, atd.) V případě zakoupení dvou serverů, je vhodné zakoupit dva stejné servery, nebo alespoň servery se stejným základem, ze stejné řady. 4.3.1. Konfigurace serveru Nyní musíme vybrat správnou konfiguraci serveru, jeho výkon, počet a typ procesorů, velikost paměti a diskové kapacity, vše musí být dimenzováno pro provoz požadovaných systémů, aplikací a služeb. Je potřeba získat hardwarové požadavky podle použitých operačních systémů od dodavatelů jednotlivých aplikací, případně sestavit požadavky podle praktických zkušeností. Požadavky můžeme sestavit například takto: - Hostitelský systém o Fyzický server - 1x CPU, 8GB RAM, 100GB - Hostované systémy o Server souborový 1xCPU, 8GB, 500GB o Server SQL 1x CPU, 16GB, 200GB o Server webový 1x CPU, 4GB, 100GB - 64 -
Celkem tedy můžeme sečíst a zakoupit dva servery v následující konfiguraci: - CPU min. 1x 4 jádrové - RAM min. 36GB - HDD RAID5 nebo RAID10 4x 300GB SAS, + 1x HotSpare 300GB SAS 4.3.2. Výběr disků a RAID Důležitým prvkem ovlivňujícím rychlost celého řešení je typ použitých pevných disků, které se liší nejen kapacitou, ale rychlostí otáček, tedy rychlosti čtení/zápis, ale hlavně rozhraním: Pevné disky SATA, 7200 otáček/10000 otáček Pevné disky SAS, 10000 otáček/15000 otáček SSD Disky je možné dále dělit podle typu provozu, pro který jsou určeny, jejich mechanika a elektronika může být připravena pro provoz v NAS, v RAID nebo v Enterprise řešeních. Nové modely diskových polí používají jako cache, rychlé SSD. RAID (Redundant Array of Inexpensive / Independent Disks) můžeme přeložit jako vícenásobné diskové pole laciných / nezávislých disků. Jedná se o metodu zabezpečení dat, která má ochránit data při selhání pevného disku. Principem je ukládání dat na více na sobě nezávislých pevných disků. Zapojením disků do RAID můžeme docílit nejen zvýšení celkové diskové kapacity, ale i zvýšení rychlosti diskového prostředí. K optimálnímu využití rychlosti disků a pole RAID je potřeba vhodný řadič disků. Zde opět předpokládáme, že řadič bude dodán jako součást serveru. Základní rozdělení RAID. RAID 0 několik disků je pouze spojeno do jednoho logického celku (při poruše jednoho členu ztratíme data). RAID 1 mirror, neboli zrcadlení (kopírování stejných) dat na dva nezávislé disky, při poruše jednoho o data nepřijdeme. RAID 5 data jsou rozprostřena na minimálně 3 disky, na discích jsou rovnoměrně rozloženy samo opravné kódy, ze kterých se při havárii jednoho pole dokáží ztracená data dopočítat. Je odolný vůči výpadku jednoho disku, rozložení dat na více disků umožní rychlejší čtení, ale díky výpočtu a zápisu samo opravného kódu je výrazně pomalejší zápis. - 65 -
RAID 10 jedná se o kombinaci RAID 1 a RAID 0. Data se nejdříve v diskových polích zrcadlí a teprve pak se tato pole, pro větší zrychlení přenosových rychlostí, vloží do dalšího diskového pole typu RAID 0. Maximální počet pevných disků, který může selhat bez jakýchkoliv následků, je jeden v každém poli. Tento typ RAID se často používá pro hodně vytížené databázové aplikace. Nemusí se totiž počítat paritní data, čímž se vše zrychluje (případně zlevňuje). Hot-Spare jedná se o disk, který je v případě výpadku jednoho z disků v poli RAID okamžitě automaticky aktivován, a jsou na něj dopočítána chybějící data z vypadlého disku. Hot-spare disk je možno sdílet mezi více poli. Pokud máme více RAID polí, hot-spare může být sdílen a aktivován jak při výpadku disku z prvního, tak z druhého pole. 4.3.3. Redundance Pro zvýšení spolehlivosti celého řešení je vhodné zdvojit důležité prvky. Pak můžeme říct, že je zkonstruováno jako NoSPOF 2 tedy že SAN i LAN konektivita klíčových komponent je duální. LAN Ethernet 1Gb/s Servery Gigabit EtherChannel Servery Hypervisor 1 Hypervisor 2 SAN FC 8Mb/s Diskové pole Obrázek 34 - Redundantní NoSPOF zapojení serverů v CSV clusteru (zdroj: autor) 2 SPOF (Single Point od Failure) systém, kde při selhání jediného prvku dojde k zastavení celého řešení. Výrazem NoSPOF je pak označeno řešení, kde tomu tak není, vše je zdvojeno. - 66 -
Máme dva servery, každý se dvěma napájecími zdroji, máme zdvojené síťové prvky, zdvojené spoje mezi servery a diskovým polem, v serverech a diskovém poli jsou dva řadiče. Případně budeme mít i dva nody diskového pole. V serverech a v diskovém poli použijeme Hot-Spare disky. K propojení serverů, switchů a sítě LAN použijeme dva Gb/s switchce ve stacku (například Cisco 2960S). Propoj mezi servery a switchi bude tvořen přes etherchannel složený ze dvou fyzických interface (kterých může jich být až 8) s protokolem LACP 3, na straně serverů bude nastaven NIC teaming také s protokolem LACP. Etherchannel používá load balancingu, aby optimálně rozložil zátěž na linky ve skupině. 4.4. Sestavení nabídky V předešlých kapitolách jsem uvedl, nad čím bych se zamýšlel a jak bych postupoval při návrhu řešení a vypracování nabídky. V malých společnostech většinou jednáme přímo s majiteli, pro které IT není to, co je živí a tak se na něm většinou snaží co nejvíce ušetřit. O nabídku požádají několik dodavatelů, aby si porovnaly ceny. Problémem je, že vlastně nevědí, co přesně chtějí, protože IT nerozumí, ale očekávají, že my jim vybereme a nabídneme to nejvhodnější řešení, které ale může každý dodavatel posoudit jinak. Proto doporučuji předložit nabídku a o dvou až třech variantách řešení. 4.4.1. Metoda 3 nabídek Tato metoda vychází z mé praktické zkušenosti. Jak jsem již uvedl, zákazník obvykle s žádostí o nabídku osloví několik dodavatelů, a protože se dá předpokládat, že se mezi nabídkami objeví i levné řešení, které my nebudeme považovat za vhodné, a protože je pravděpodobné, že by si tuto nabídku pro její nižší cenu mohl zákazník vybrat, je vhodné tuto levnou variantu zařadit do naší nabídky také a okomentovat. 3 LACP - Link Aggregation Control Protocol, nebo také IEEE 802.3ad slouží k automatickému vyjednání a vytvoření EtherChannelu. Pro vytvoření EtherChannelu můžeme použít 2 až 8 fyzických interfaců (L2 nebo L3). Podmínkou je, aby byly stejného typu a rychlosti, zařazené do stejné VLAN nebo v trunk módu se stejnými parametry. - 67 -
Je to proto, že kdybychom tuto levnější variantu neuvedli, byli bychom ihned vyřazeni pro vysokou cenu našeho řešení. Takto si vytvoříme prostor, abychom popsali nedostatky levného řešení, a mohli navrhnout druhou variantu, která již bude správná a 100% funkční. Nakonec připravíme i 3. variantu, ve které bude robustnější řešení s výkonovou rezervou pro případné aktualizace a rozšíření, které bude samozřejmě dražší a zákazník si ho většinou nevybere, protože mu druhá varianta dostačuje. Toto 3. řešení připravíme z podobného důvodu jako variantu 2. Může se objevit nabídka, která bude z důvodů, o kterých jsme nevěděli, naše řešení vyřazovat. Důvodem může být plánovaná výměna aplikačního software, nebo nákup dalšího nového aplikačního software, který klade vyšší požadavky na výkon. Případně se může stát, že ½ roku po dodání a instalaci nového řešení se zákazník ozve s reklamací, že námi dodané řešení je nevýkonné a že mu na něm nepracuje správně nová verze software, kterou si nechal instalovat. Pak můžeme reagovat, že naše nabídka obsahovala i dražší variantu, která počítala s případnou aktualizací, nebo s rozšířením software, ale zákazník jí z úsporných důvodů nezvolil. 1. Varianta levné řešení o Zákazník vidí, že umíme nabídnout i levné řešení o Nechceme dodat za každou cenu, ale uvedeme slabiny o Řešení je sice funkční, ale v provozu nebude 100% spolehlivé o Můžeme uvést, že vhodnější je následující varianta 2. Varianta optimální pro zákazníka o Toto je nabídka, kterou chceme dodat o Správné řešení, které splní zákazníkovi požadavky o Spolehlivé řešení 3. Varianta dražší řešení o Správné řešení, které splní zákazníkovi požadavky o Oproti předešlé nabídce je robustnější s výkonovou rezervou o Nechceme dodat za každou cenu, ale uvedeme výhody o Spolehlivé řešení - 68 -
4.4.2. Příklad nabídky Výrobci serverů, jakými jsou HP, DELL nebo IBM, mají v nabídce vždy několik konfigurací, ze kterých je možné vhodný model vybrat a jeho konfiguraci případně doplnit o paměť a disky. Pro příklad jsem vybral dva servery HP Proliant ML310, s rozšířením paměti a dvěma disky. K uložení virtuálních strojů pak NAS Synology, s 8mi pevnými disky SATA. Předpokládám pro rychlá DATA nastavení RAID 10 ze 4 kusů pevných disků s celkovou kapacitou 6TB a pro ostatní data RAID 5, složený z 3 kusů, s celkovou kapacitou 6TB, poslední disk 3TB, pak bude nastaven jako Hot-Spare. Podotýkám, že se jedná o jedno z nejlevnějších, ale funkčních řešení. Server 1 Model kusy cena za kus cena celkem HP ProLiant ML310eG8v2 E3-1220v3, 4GB, 2x1TB, 3NBD 1 15 606 Kč 15 606 Kč HP 8GB 2Rx8 PC3L-10600E-9 Kit 4 3 008 Kč 12 032 Kč HP MS WS12 Standard CZ + ENG OEM 1 13 668 Kč 13 668 Kč Server 2 HP ProLiant ML310eG8v2 E3-1220v3, 4GB, 2x1TB, 3NBD 1 15 606 Kč 15 606 Kč HP 8GB 2Rx8 PC3L-10600E-9 Kit 4 3 008 Kč 12 032 Kč HP MS WS12 Standard CZ + ENG OEM 1 13 668 Kč 13 668 Kč Klientské licence HP MS WS12 CAL 5 USR licence OEM 5 3 140 Kč 15 700 Kč Diskové pole Synology DS1813+ DiskStation (8 bay) 1 21 955 Kč 21 955 Kč HDD 3TB WD30EFRX RED 64MB SATAIII IntelliP.NAS 3RZ Instalace 8 2 760 Kč 22 080 Kč Instalace a konfigurace nového řešení 16 800 Kč 12 800 Kč Migrace dat ze stávajícího řešení 16 800 Kč 12 800 Kč Nastavení klientských stanic 8 600 Kč 4 800 Kč Nastavení zálohování 4 600 Kč 2 400 Kč Testy celého řešení 4 800 Kč 3 200 Kč Celkem Celkem s DPH Obrázek 35 Kalkulace hardware pro levný CSV cluster (zdroj: autor) 178 347 Kč 215 800 Kč - 69 -
5. Srovnání platforem VMware a Microsoft 5.1. Použitý hardware Ke srovnání obou platforem jsem měl k dispozici na omezenou dobu několika týdnů následující hardware: - 3x Server HP DL 360p Gen8 v konfiguraci: o 2x CPU Intel Xeon E5-2640 o 12 x 8 GB DIMM = 96 GB o 2 x 300 GB SAS (RAID1) o 2 x Optický interface 8Gb/s - 1x Úložiště EMC VNX5100-Primary o 24x HDD SAS - 1x SAN přepínač EMC Connetrix DS300-B o Aggregate bandwith: 408 Gb/s: 24 portů x 8.5 Gb/s (line rate) x 2 (full duplex) Obrázek 36 Každý server má dva CPU (zdroj: autor) - 70 -
Obrázek 37 - Rozložení pamětí v serverech - na CPU (zdroj: autor) Obrázek 38 - Rozložení disků do RAIDů v VNX5100 (zdroj: autor) Obrázek 39 - Velikost vytvořených RAID Group (zdroj: autor) - 71 -
Obrázek 40 - SAN switch - propojení diskového pole a serverů 5.1.1. Zapojení hardware pro testy LAN Ethernet 1Gb/s Servery Servery Hypervisor 1 Hypervisor 2 1 U SAN FC 8Gb/s 1 U EMC VNX 5100 Obrázek 41 - Fyzické zapojení hardware pro testování - (zdroj: autor) - 72 -
V zapojení na obrázku 41 nejsou zakresleny aktivní prvky pro připojení do lokální sítě, kde jsem použil 1x gigabitový switch Cisco 2960S a pro routování interních VLAN Cisco ASA 5510. U zákazníka bude použito 2x Cisco 2960S ve stacku a 2x Cisco ASA 5510 ve failover modu (active/passive). Nastavení jednotlivých prvků, rozdělení adresních prostorů a rozdělení do VLAN zde neuvádím. 5.1.2. Síťový graf Síťový graf, nám ukazuje propojení mezi jednotlivými prvky a cesty, které je možné použít. Viz. Obrázek 41. 1 - LAN 2 a 3 - Hypervisory s optickými interface 4 a 5 - Optické switche 6 - Diskové pole se dvěma dvou portovými řadiči 1 1Gb/s 1Gb/s 1Gb/s 1Gb/s 2 3 8Gb/s 8Gb/s 8Gb/s 8Gb/s 4 5 8Gb/s 8Gb/s 8Gb/s 8Gb/s 6 Obrázek 42 - Síťový graf - počet cest (zdroj: autor) S 1 1 2 3 4 5 6 S 2 1 2 3 4 5 6 S 3 1 2 3 4 5 6 1 0 2 2 0 0 0 1 0 0 0 4 4 0 1 0 0 0 0 0 16 2 0 0 0 1 1 0 2 0 0 0 0 0 4 2 0 0 0 0 0 0 3 0 0 0 1 1 0 3 0 0 0 0 0 4 3 0 0 0 0 0 0 4 0 0 0 0 0 2 4 0 0 0 0 0 0 4 0 0 0 0 0 0 5 0 0 0 0 0 2 5 0 0 0 0 0 0 5 0 0 0 0 0 0 6 0 0 0 0 0 0 6 0 0 0 0 0 0 6 0 0 0 0 0 0 o délce 3. Obrázek 43 - Matice sousednosti a její mocniny (zdroj: autor) Výsledkem je, že z bodu 1. (LAN) do bodu 6. (Diskové pole), existuje 16 různých cest - 73 -
5.2. Testovací software K testování jsem vybral aplikaci Passmark Performance test v8, která je ke stažení na http://www.passmark.com/. Aplikace používá on-line databázi baseline, do které je možné uložit naměřené hodnoty, porovnat je s měřením ostatních uživatelů. Ve výběrových řízeních bývá často jako kritérium uvedeno min. hodnota dle cpubenchmark.net, což by mělo odpovídat hodnotám naměřeným v testovací aplikaci. Provedené testy obsahovali následující měření. [21] 5.2.1. Test procesoru CPU Mark - Integer Math (Mops/s) - 64-bit addition, subtraction, multiplication and division using integer variables - Floating point (Mops/s) - 64-bit addition, subtraction, multiplication and division using floating point variables - Prime numbers (Kprimes/s *100) - Finds prime numbers - SSE (Mmatrices/sec *100) - 128-bit SSE operations - Compression (KBprocess/sec) - Adaptive encoding algorithm - Encryption (Mbtranfer/sec *10) - Blowfish enciphering algorithm - Physics (FPS) - Fluid Mechanics & game physics - String sorting (Kstrings/sec) - Sorts an array of 100,000 random strings each 25 characters long 5.2.2. Test paměti Memory Mark - Database Operations (Thousand operations per seconds) - Read Cached (MB/s) - time taken to read a small block of memory - Read Uncached (MB/s) - time taken to read a large block of memory. The block is too large to be held in cache. - Write (MB/s) - time taken to write information into memory - Available (MB available) - Latency (nanoseconds, lower is better) - Threaded (MB/s) - 74 -
5.2.3. Test pevných disků Disk Mark - Disk Seq/R (Mbtranfer/sec) - file is read sequentially from start to end - Disk Seq/W (Mbtranfer/sec) - file is written sequentially from start to end - Random R+W (Mbtranfer/sec) - file is read randomly 5.3. Plán testů Protože jsem měl hardware zapůjčen na omezenou dobu, sestavil jsem si plán testů, abych měl přehled, kolik mám času a mohl s ním lépe nakládat. ID Název úkolu Zahájení Dokončení Trvání 1 Start 3. 3. 2014 3. 3. 2014 0d. 2 III 2014 9 III 2014 16 III 2014 23 III 2014 30 III 2014 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 1 2 3 2 Sestavení hardware 3. 3. 2014 4. 3. 2014 2d. 3 Instalace a konfigurace hostitelů VMware 5. 3. 2014 7. 3. 2014 3d. 4 Instalace hostů - Windows 2008 a 2012 8. 3. 2014 8. 3. 2014 1d. 5 Příprava skriptů pro testy 9. 3. 2014 9. 3. 2014 1d. 6 Test VM - Windows 2008/4GB 10. 3. 2014 10. 3. 2014 1d. 7 Ladění skriptů pro automatický test 11. 3. 2014 11. 3. 2014 4hod. 8 Test VM - Windows 2008/8GB 11. 3. 2014 11. 3. 2014 1d. 9 Test VM - Windows 2008/16GB 12. 3. 2014 12. 3. 2014 1d. 10 Test VM - Windows 2012/4GB 13. 3. 2014 13. 3. 2014 1d. 11 Test VM - Windows 2012/8GB 14. 3. 2014 14. 3. 2014 1d. 12 Test VM - Windows 2012/16GB 15. 3. 2014 15. 3. 2014 1d. 13 Test VM - Windows 2x 2012/16GB 16. 3. 2014 16. 3. 2014 1d. 14 Test VM - Windows 3x 2012/16GB 17. 3. 2014 17. 3. 2014 1d. 15 Instalace hostitelů Windows 18. 3. 2014 20. 3. 2014 3d. 16 Test PM - Windows 2012 - lokální disk 21. 3. 2014 21. 3. 2014 1d. 17 Instalace hostů - Windows 2008 a 2012 21. 3. 2014 22. 3. 2014 2d. 18 Test PM - Windows 2012 - disk RAID 10 23. 3. 2014 23. 3. 2014 1d. 19 Test PM - Windows 2012 - disk RAID 5 24. 3. 2014 24. 3. 2014 1d. 20 Test HV - Windows 2008/4GB 25. 3. 2014 25. 3. 2014 1d. 21 Test HV - Windows 2008/8GB 26. 3. 2014 26. 3. 2014 1d. 22 Test HV - Windows 2008/16GB 27. 3. 2014 27. 3. 2014 1d. 23 Test HV - Windows 2012/4GB 28. 3. 2014 28. 3. 2014 1d. 24 Test HV - Windows 2012/8GB 29. 3. 2014 29. 3. 2014 1d. 25 Test HV - Windows 2012/16GB 30. 3. 2014 30. 3. 2014 1d. 26 Test HV - Windows 2x 2012/16GB 31. 3. 2014 31. 3. 2014 1d. 27 Test HV - Windows 3x 2012/16GB 1. 4. 2014 1. 4. 2014 1d. 28 Konec testování 2. 4. 2014 2. 4. 2014 0d. Obrázek 44 Plán instalací a testů (zdroj: autor) Po sestavení hardware a instalaci VMware jsem se dostal do problémů, kdy jsem musel reklamovat jeden z řadičů. Při této příležitosti byl proveden i upgrade firmware diskového pole, bez kterého se nedařilo zprovoznit komunikaci VMware 5.5 s diskovým polem. Oprava byla provedena v krocích 2 a 3 a nebylo potřeba posunovat čas. - 75 -
5.3.1. OS instalovaný na fyzický hardware 5.3.1.1. Instalace VMware - hypervisory VMware verze 5.5 Essentials Plus o 1x virtuální stroj - Windows 2008 R2 o 3x virtuální stroj - Windows 2012 R2 5.3.1.2. Instalace fyzického stroje - 1x fyzický stroj - Windows 2012 R2 Datacenter - použit jsem jeden ze serverů v node, ještě před instalací role Hyper-V 5.3.1.3. Instalace Hyper-V - Hypervisor Windows 2012 R2 Datacenter [24] o 1x virtuální stroj - Windows 2008 R2 o 3x virtuální stroj - Windows 2012 R2 5.3.2. Konfigurace testovaných strojů Testovány byly následující konfigurace: Fyzický stroj - Fyzický server Windows Server 2012R2 (1-8CPU) lokální disk - Fyzický server Windows Server 2012R2 (1-8CPU) disk v CSV RAID10 - Fyzický server Windows Server 2012R2 (1-8CPU) disk v CSV RAID5 Hypervisory VMware, VM uloženy v CSV clusteru v RAIDu 10 - VMware ESX 5.5 -> VM Windows 2008R2 (1-8CPU, 4GB RAM) - VMware ESX 5.5 -> VM Windows 2008R2 (1-8CPU, 8GB RAM) - VMware ESX 5.5 -> VM Windows 2008R2 (1-8CPU, 16GB RAM) - VMware ESX 5.5 -> VM Windows 2012R2 (1-8CPU, 4GB RAM) - VMware ESX 5.5 -> VM Windows 2012R2 (1-8CPU, 8GB RAM) - VMware ESX 5.5 -> VM Windows 2012R2 (1-8CPU, 16GB RAM) - VMware ESX 5.5 -> 2x paralelně VM Windows 2012R2 (1-8CPU, 16GB RAM) - VMware ESX 5.5 -> 3x paralelně VM Windows 2012R2 (1-8CPU, 16GB RAM) - 76 -
Hypervisory Hyper-V, VM uloženy v CSV clusteru v RAIDu 10 - Hyper-V 2012 R2 -> VM Windows 2008R2 (1-8CPU, 4GB RAM) - Hyper-V 2012 R2 -> VM Windows 2008R2 (1-8CPU, 8GB RAM) - Hyper-V 2012 R2 -> VM Windows 2008R2 (1-8CPU, 16GB RAM) - Hyper-V 2012 R2 -> VM Windows 2012R2 (1-8CPU, 4GB RAM) - Hyper-V 2012 R2 -> VM Windows 2012R2 (1-8CPU, 8GB RAM) - Hyper-V 2012 R2 -> VM Windows 2012R2 (1-8CPU, 16GB RAM) - Hyper-V 2012 R2 -> 2x paralelně VM Windows 2012R2 (1-8CPU, 16GB RAM) - Hyper-V 2012 R2 -> 3x paralelně VM Windows 2012R2 (1-8CPU, 16GB RAM) 5.4. Výsledky měření základní přehled V základním přehledu jsem porovnával stejné konfigurace virtuálních strojů na připravených hypervisorech Microsoft Windows server 2012 R2 a VMware 5.5. Pro prezentaci výsledků měření jsem použil sloupové grafy, pro Microsoft Hyper-V použil plnou barvu a pro VMware šrafovanou. Různé barvy pak odlišují jednotlivá měření. Hyper-V VMware Vybraná měření jsem rozdělil do kapitol a na konci každé jsem provedl krátké vyhodnocení zjištěných rozdílů měření. Zjištěné rozdíly většinou odpovídaly předpokladům. Asi největší rozdíl vznikl při spuštění paralelních serverů, kdy výkon výrazně spadl. Na konec práce jsem přidal dvě přílohy, ve kterých je výběr základních výsledků měření dvou stejných virtuálních serverů v konfiguraci Windows server 2012 R2 s 16GB a 8CPU, na platformách VMware a Hyper-V. Všechna měření jsou pak dostupná ve formátech XLS a CSV na přiloženém DVD. - 77 -
5.4.1. Srovnání - 1x Windows server 2008/4GB 5.4.1.1. 1x Windows server 2008/4GB měření CPU MARK 5.4.1.2. 1x Windows server 2008/4GB měření MEMORY MARK - 78 -
5.4.1.3. 1x Windows server 2008/4GB měření DISK MARK Hodnocení měření. Výkon CPU je shodný až do 5. procesoru, pak začne být výkonnější VMware, u pamětí je trvalá mírná převaha Hyper-V, v případě měření Threaded, situace obrací u 6. CPU, ve prospěch VMware. V případě měření rychlosti disků, je Hyper-V výrazně rychlejší. Zde je zajímavé, jak v případě VMware, při měření metodou Random R+W výkon kolísá. U lichého počtu CPU je rychlost nižší, nežli případě sudého počtu. Podle informace od technika společnosti Arrow ECS, která je zástupcem společnosti VMware v CŘ, je kolísání naměřených hodnot způsobeno zřejmě přidělováním vcpu v režimu hyperthreading 4. Pokud jsou v serveru dva fyzické procesory, měly by být vcpu hostovanému systému přidělovány střídavě vždy z každého CPU. Pokud je tomu jinak, je to prý možné, ale protože je systém již smazán a reinstalován, nemůžeme nastavení zkontrolovat a testy opakovat. 4 Hyper-threading technologie fungující na principu duplikace té části CPU, která obsahuje registry. Aplikace se domnívají, že procesorů je vícero a zasílají pro zpracování procesorem víc instrukcí a příkazů naráz. HT se jeví jako efektivní způsob zvýšení výkonu hlavně při početních operacích, umožňuje zvýšit výkon aplikačnímu softwaru, který umí pracovat s více vlákny současně (multithreading), anebo je schopný práce v režimu zpracování více úloh naráz (multitasking). - 79 -
5.4.2. Srovnání - 1x Windows server 2012/4GB 5.4.2.1. 1x Windows server 2012/4GB měření CPU MARK 5.4.2.2. 1x Windows server 2012/4GB měření MEMORY MARK - 80 -
5.4.2.3. 1x Windows server 2012/4GB měření DISK MARK Hodnocení měření. Výkon CPU je shodný až do 4. procesoru, pak začne být výkonnější VMware, u pamětí je trvalá mírná převaha Hyper-V, v případě měření Threaded, situace obrací u 5. CPU, ve prospěch VMware. V případě měření rychlosti disků, je Hyper-V výrazně rychlejší. V případě VMware, při všech měřeních výkon oproti hyper-v výrazně kolísá. - 81 -
5.4.3. Srovnání - 1x Windows server 2008/8GB 5.4.3.1. 1x Windows server 2008/8GB měření CPU MARK 5.4.3.2. 1x Windows server 2008/8GB měření MEMORY MARK - 82 -
5.4.3.3. 1x Windows server 2008/8GB měření DISK MARK Hodnocení měření. Výkon CPU je shodný až do 5. procesoru, pak začne být výkonnější VMware, u pamětí je trvalá mírná převaha Hyper-V, v případě měření Threaded, situace obrací u 7. CPU, ve prospěch VMware. V případě měření rychlosti disků, je Hyper-V výrazně rychlejší. Zde je zajímavé, jak v případě VMware, při měření metodou Random R+W výkon kolísá. U lichého počtu CPU je rychlost vyšší, nežli v případě sudého počtu. - 83 -
5.4.4. Srovnání - 1x Windows server 2012/8GB 5.4.4.1. 1x Windows server 2012/8GB měření CPU MARK 5.4.4.2. 1x Windows server 2012/8GB měření MEMORY MARK - 84 -
5.4.4.3. 1x Windows server 2012/8GB měření DISK MARK Hodnocení měření. Výkon CPU je shodný až do 5. procesoru, pak začne být výkonnější VMware, u pamětí je trvalá mírná převaha Hyper-V, v případě měření Threaded, situace obrací u 5. CPU, ve prospěch VMware. V případě měření rychlosti disků, je Hyper-V výrazně rychlejší. Zde je zajímavé, jak v případě VMware, při měření metodou Random R+W výkon kolísá. U sudého počtu CPU je rychlost vyšší, nežli v případě lichého počtu CPU. - 85 -
5.4.5. Srovnání - 1x Windows server 2008/16GB 5.4.5.1. 1x Windows server 2008/16GB měření CPU MARK 5.4.5.2. 1x Windows server 2008/16GB měření MEMORY MARK - 86 -
5.4.5.3. 1x Windows server 2008/16GB měření DISK MARK Hodnocení měření. Výkon CPU je shodný až do 5. procesoru, pak začne být výkonnější VMware, u pamětí je trvalá mírná převaha Hyper-V, v případě měření Threaded, je na rozdíl od ostatních měření trvale ve výhodě Hyper-V. V případě měření rychlosti disků, je Hyper-V výrazně rychlejší. Zde je zajímavé, že je u obou hypervisorů výkon disků na rozdíl od předešlých měření stabilní, bez kolísání. - 87 -
5.4.6. Srovnání - 1x Windows server 2012/16GB 5.4.6.1. 1x Windows server 2012/16GB měření CPU MARK 5.4.6.2. 1x Windows server 2012/16GB měření MEMORY MARK - 88 -
5.4.6.3. 1x Windows server 2012/16GB měření DISK MARK Hodnocení měření. Výkon CPU je shodný až do 3. procesoru, pak začne být výkonnější VMware, u pamětí je trvalá mírná převaha Hyper-V, v případě měření Threaded, situace obrací u 5. CPU, ve prospěch VMware. V případě měření rychlosti disků, je Hyper-V výrazně rychlejší. Je zajímavé, jak v případě VMware, při měření metodou Random R+W výkon kolísá. V případě lichého počtu CPU je rychlost vyšší, nežli v případě sudého počtu CPU. - 89 -
5.4.7. Srovnání - 2x Windows server 2012/16GB 5.4.7.1. 2x Windows server 2012/16GB měření CPU MARK 5.4.7.2. 2x Windows server 2012/16GB měření MEMORY MARK - 90 -
5.4.7.3. 2x Windows server 2012/16GB měření DISK MARK Hodnocení měření. V případě provozu dvou paralelních serverů je měření výrazně rozptýlené. Výkon CPU i pamětí jde ve prospěch VMware. V případě měření rychlosti disků při paralelním provozu, je výkon výrazně nižší, ale stále je mírně rychlejší nežli Hyper-V. - 91 -
5.4.8. Srovnání - 3x Windows server 2012/16GB 5.4.8.1. 3x Windows server 2012/16GB měření CPU MARK 5.4.8.2. 3x Windows server 2012/16GB měření MEMORY MARK - 92 -
5.4.8.3. 3x Windows server 2012/16GB měření DISK MARK Hodnocení měření. V případě provozu tří paralelních serverů je měření opět výrazně rozptýlené. Výkon CPU i pamětí jde ve prospěch VMware. V případě měření rychlosti disků při paralelním provozu tří serverů, je výkon výrazně nižší, ale oproti dvou paralelním serverům již ne takový. Stále je mírně rychlejší Hyper-V. - 93 -
5.5. Výsledky měření 1x Windows servery s 16GB Zde jsem se již zaměřil jen na servery s 16GB RAM a s 1x CPU, 2x CPU, 4x CPU a 8x CPU a porovnal je nad VMware a nad Hyper-v. Tyto počty CPU, jsou z mé zkušenosti nejčastěji používané v malých a středních firmách i ve vztahu k licenčním podmínkám, kdy se licence nabízí pro 2xCPU. 5.5.1. 1x Windows server 2012 s 1-2-4 a 8CPU, 16GB měření CPU MARK Hodnocení měření. V případě práce 1 až 4 procesorů je výkon srovnatelný, ale když srovnáme výkon serverů s 8mi procesory, je výrazně rychlejší VMware. Tento rozdíl je způsoben lepším přidělováním a řízením práce procesoru VMware. - 94 -
5.5.2. 1x Windows server 2012 s 1-2-4 a 8CPU, 16GB měření MEM MARK 5.5.3. 1x Windows server 2012 s 1-2-4 a 8CPU, 16GB měření DISK MARK Hodnocení měření. Zde sloučím hodnocení pamětí a disků. U obou měření je vidět, že počet procesorů nemá přímý vliv na rychlost pamětí a disků. Rychlost paměti je u obou platforem srovnatelná, ale v případě rychlosti disků je rychlejší Hyper-V. - 95 -
5.6. Výsledky měření 1x, 2x a 3x servery 2008 a 2012 se 16GB a 8x CPU Zde jsem se zaměřil na porovnání výkonu jednoho serveru 2008R2 a 2012R2, a dvou a tří serverů 2012R2 paralelně. Testoval jsem na hostitelích Hyper-V a VMware. 5.6.1. Windows server 2008-2012, 8CPU, 16GB měření CPU MARK Hodnocení měření. Stejně jako v předešlých měřeních jsem pro Hyper-V použil plnou barvu a pro VMware šrafovanou. V případě provozu více paralelních serverů je měření rozptýlené. Výkon CPU i pamětí jde ve prospěch VMware. - 96 -
5.6.2. Windows server 2008R2-2012R2, 8CPU, 16GB měření DISK MARK Hodnocení měření. V případě provozu jednoho virtuálního serveru je jednoznačným vítězem Hyper-V. Při paralelním provozu dvou virtuálních serverů, rychlosti čtení i zápisu výrazně klesnou a to jak u VMware, tak u Hyper-V. Z grafu lze vyčíst, že rychlost klesne na 10-20% rychlosti naměřené s jedním serverem. Při provozu tří paralelních serverů přenosová rychlost ještě klesne, ale oproti dvou serverům, již není rozdíl tak výrazný. Stále je mírně rychlejší Hyper- V. - 97 -
5.6.3. Windows server 2008-2012, 8CPU, 16GB měření CPU - Integer Math Hodnocení měření. Nejvyšší střední hodnotu vykazuje 1x-vm-s2012, kde je i nejmenší rozptyl. Největších rozptylů dosahují měření se 3mi paralelními servery 3x-hv-s2012 a 3x-vm-s2012, což je zřejmě způsobeno přidělováním a sdílením systémových prostředků. V případě 3x-hv-s2012 je zajímavé rozptýlení v tzv. 3. kvartilu (šedý sloupec), tedy 25% naměřených hodnot nahoru od mediánu. Pokud ale srovnáme měření se dvěma paralelními servery, 2x-hv-s2012 a 2x-vm-s2012, tak oproti třem serverům, jsou si obě měření podobnější, mají téměř shodné variační rozpětí, ale Hyper-v má oproti VMware rovnoměrné rozložení kvartilů, zatímco u VMware 4. kvartil skoro není vidět. Je zřejmé, že čím více virtuálních strojů je třeba obsloužit, tím je rozptyl větší. Pro srovnání servery 1x-vm-s2008 a 1xhv-s2008 (14222/13377) je pak VMware výkonnější o 6,3%. V případě serverů 2012, 1x-vm-s2012 a 1x-hv-s2012 (14259/13229) je opět VMware výkonnější, nyní o 6,0%. Můžeme uzavřít, že VMware je oproti Hyper-V výkonnější ve všech případech. - 98 -
5.6.4. Windows server 2008-2012, 8CPU, 16GB měření CPU - Floating Point Math Hodnocení měření. Nejvyšší střední hodnotu vykazuje 1x-vm-s2008, kde je i nejmenší rozptyl. Největších rozptylů dosahují měření více paralelními servery, což je opět způsobeno přidělováním a sdílením systémových prostředků. V případě 3x-hv-s2012 se opakuje zajímavé rozptýlení v tzv. 3. kvartilu (šedý sloupec), tedy 25% naměřených hodnot nahoru od mediánu. Měření s více servery mají v tomto případě oproti samostatným serverům výraznější variační rozpětí, ale rozložení minima a maxima je symetrické. Potvrzuje se, že čím více virtuálních strojů je třeba obsloužit, tím je rozptyl větší. Při srovnání 1x-vm-s2008 a 1xhv-s2008 (10218/8260), je VMware výkonnější o 23,7%. V případě serverů 2012, 1x-vm-s2012 a 1x-hv-s2012 (10175/8319) je opět VMware výkonnější, nyní o 22,3,0%. Můžeme uzavřít, že VMware je oproti Hyper-V výkonnější ve všech případech. - 99 -
5.6.5. Windows server 2008-2012, 8CPU, 16GB měření CPU - Compression Hodnocení měření. Nejvyšší střední hodnotu opět vykazuje 1x-vm-s2008, kde společně s 1x-vm.s2012 má nejmenší rozptyl. Největších rozptylů dosahují měření více paralelními servery, což je opět způsobeno přidělováním a sdílením systémových prostředků. V případě 3x-hv-s2012 se opakuje zajímavé rozptýlení v tzv. 3. kvartilu (šedý sloupec), tedy 25% naměřených hodnot nahoru od mediánu. Měření s více servery, mají v tomto případě oproti samostatným serverům výraznější variační rozpětí, ale rozložení minima a maxima není symetrické, jak tomu bylo v předešlém grafu. Opět platí, že čím více virtuálních strojů je třeba obsloužit, tím je rozptyl větší. Při srovnání 1x-vm-s2008 a 1xhv-s2008 (13575/11324) je VMware výkonnější o 19,8%. V případě serverů 2012, 1x-vm-s2012 a 1x-hv-s2012 (13393/11453) je opět VMware výkonnější o 16,9%. Můžeme uzavřít, že VMware je oproti Hyper-V výkonnější ve všech případech. - 100 -
5.6.6. Windows server 2008-2012, 8CPU, 16GB měření CPU - Encryption Hodnocení měření. Nejvyšší střední hodnotu opět vykazuje 1x-vm-s2012, kde společně s 1x-vm.s2008 má nejmenší rozptyl. Největších rozptylů opět dosahují měření více paralelními servery, což je způsobeno přidělováním a sdílením systémových prostředků. V případě 3x-hv-s2012 se opakuje zajímavé rozptýlení v tzv. 3. kvartilu (šedý sloupec), tedy 25% naměřených hodnot nahoru od mediánu. Měření s více servery mají v tomto případě oproti samostatným serverům výraznější variační rozpětí, ale rozložení minima a maxima je symetrické. Potvrzuje se, že čím více virtuálních strojů je třeba obsloužit, tím je rozptyl větší. Při srovnání 1x-vm-s2008 a 1xhv-s2008 (13575/11324), je VMware výkonnější o 19,8%. V případě serverů 2012, 1x-vm-s2012 a 1x-hv-s2012 (13393/11453) je opět VMware výkonnější o 16,9%. Můžeme uzavřít, že VMware je oproti Hyper-V výkonnější ve všech případech. Domnívám se, výrazný rozdíl měření 3x-hv-s2012 oproti 3x-vm-s2012, byl způsoben nějakou vnější chybou, která měření ovlivnila, a bylo by vhodné měření opakovat, aby se chyba vyloučila, nebo potvrdila. - 101 -
Závěr Domnívám se, že jsem splnil všechny zadané cíle. V kapitole 5 jsem vypracoval návrh CSV clusteru pro malou a střední společnost. CSV cluster jsem si podle mého návrhu vyzkoušel i prakticky instalovat a zprovoznit (viz. obrázek 23). Měl jsem k dispozici odpovídající, ale starší hardware, na který jsem Hyper-V cluster nainstaloval. Přesto, že jednalo o starší hardware, byl cluster funkční, a rychlost i odezvy systému byli dostačující pro předpokládaný provoz. Část práce zaměřenou na porovnání platforem VMware a MS Hyper-V jsem také splnil a je uvedená v kapitole 6. Realizace této části byla časově velmi náročná, provedl jsem instalaci clusterů na platformě VMware a na platformě MS Hyper-V a u každé provedl sady opakovaných testů. Po jejich vyhodnocení se domnívám, že by bylo vhodné některé testy pro jejich velký rozptyl opakovat, aby se vyloučila, nebo potvrdila případná chyba měření. Na obrázku 45 jsou porovnány naměřená rozdělení na virtuálních strojích s VMware a s Hyper-V s 8xCPU a 16GB RAM, konkrétně měření CPU - Integer Math, které zobrazují jen přibližně normální rozdělelní. Pro přesnější tvrzení, by bylo třeba zvýšit počet měření. Obrázek 45 Naměřená rozdělení VMware a Hyper-V s 8xCPU a 16GB RAM (zdroj: autor) - 102 -
Po ukončení testů jsem provedl další doporučené úpravy v nastavení a aktualizace firmware a provedl další měření, která již nejsou zahrnuty v této práci. Tyto změny pomohly Hyper-V, kdy se zvedl jeho výkon ve všech měřeních a vyrovnal se VMware. Přikládám obrázek 46, kde je nárůst výkonu Hyper-V a srovnání výkonu s VMware dobře vidět. Obrázek 46 - Nové porovnání VMware a Hyper-V (zdroj: autor) Z toho je zřejmé, že všechny naměřené hodnoty byly platné jen pro danou hardwarovou a softwarovou konfiguraci. Po aktualizaci jsou měřené hodnoty jiné, a tak mohu původní hodnoty jen porovnávat s novými. Nicméně doporučuji provádět podobné testy před nasazením jakéhokoliv řešení, první provedené testy mi pomohly odhalit problém se špatnou konfigurací řadiče, což nakonec skončilo jeho reklamací. Kdybych zátěžové testy neprováděl, přišli bychom na problém až v okamžiku spuštění ostrého provozu. Testy nám pomohly i k optimalizaci nastavení a ke zvýšení výkonu Hyper-V. Měření a následné vyhodnocení naměřených hodnot mě bavilo, a kdyby to bylo možné, pokračoval bych v testech a v dalším ladění" konfigurace. Výstupem mé práce je, že obě platformy jsou si velmi podobné, jsou výkonné, plně funkční a je možné je bez komplikací použít k nasazení virtualizace. V použité hardwarové - 103 -