}w!"#$%&'()+,-./012345<ya

Transkript

1 }w!"#$%&'()+,-./012345<ya MASARYKOVA UNIVERZITA FAKULTA INFORMATIKY Testování výkonnosti virtualizačního prostředí Hyper-V DIPLOMOVÁ PRÁCE Libor Dušek Brno, jaro 2011

2 Prohlášení Prohlašuji, že tato diplomová práce je mým původním autorským dílem, které jsem vypracoval samostatně. Všechny zdroje, prameny a literaturu, které jsem při vypracování používal nebo z nich čerpal, v práci řádně cituji s uvedením úplného odkazu na příslušný zdroj. Vedoucí práce: Ing. Mgr. Zdeněk Říha, Ph.D. ii

3 Poděkování Na tomto místě bych rád poděkoval všem, kteří svými náměty a radami dopomohli ke vzniku této práce. Především vedoucímu práce panu Zdeňku Říhovi, rodině a přátelům. Dále pak firmě Kentico software s.r.o. za zapůjčení hardwarového vybavení a zaměstnancům CVT za ochotný přístup při asistenci s řešením hardwarových problémů. iii

4 Shrnutí Práce se zabývá problematikou provozu virtualizačního nástroje Hyper-V. Popisuje různé možnosti konfigurace virtualizačního prostředí se zaměřením na požadovanou funkcionalitu a výkon. Diskutuje nedostatky celého řešení a problémy se kterými se lze obvykle setkat. Praktická část práce je věnována testování výkonu reálných aplikací ve virtuálním prostředí a optimalizaci jejich provozu. iv

5 Klíčová slova virtualizace, Hyper-V, optimalizace, výkon, testování, SCVMM, Microsoft, Exchange 2010, Windows, PV175, PV176, Kentico software v

6 Obsah 1 Úvod Struktura práce Virtualizace Virtualizace platformy Plná virtualizace Paravirtualizace Virtualizace na úrovni jádra operačního systému Motivace k virtualizaci platforem Snížení počtu fyzických serverů a nákladů spojených s jejich provozem Zvýšení dostupnosti serverů Zvýšení flexibility serverů Nevýhody virtualizace Sdílení systémových prostředků Složitost systému a cena Hyper-V Architektura Hyper-V Přehled funkcionalit Stav virtuálního stroje Základní nastavení virtuálního počítače Reprezentace virtuálního počítače Virtuální pevné disky Zachycení stavu (Snapshot) Možnosti nastavení procesoru Integrační komponenty (Integration Services Components) Synchronizace času Zjištění dostupnosti (Heartbeat) Stínovaná kopie svazku (Volume Shadow Copy) Podpora vypínání (Shutdown) Výměna dat (Key/value pair exchange) Dynamická změna velikosti operační paměti za běhu počítače Virtuální sítě VLAN (802.1Q) v Hyper-V prostředí Přidělování MAC adres Podvržení MAC adresy Podvržení odpovědi ARP/ND (ARP/ND Spoofing) Spojení fyzických NIC do týmu (NIC Teaming) Zajištění vysoké dostupnosti virtuálních počítačů (Failover Hyper-V cluster) Konfigurace sdíleného úložiště Přemístění (migrace) virtuálního počítače za běhu vi

7 Konfigurace sítí v clusteru Nástroje pro správu, monitorování a zálohování Virtual Machine Manager (VMM) 2008 R2 SP Testování výkonnosti Hyper-V HW podpora virtualizace v Hyper-V Testovací prostředí Metodika testování a konfigurační prvky Ukazatele výkonu Optimalizace systému Procesor Operační pamět Sít ová komunikace Úložný subsystém Testovací scénáře pro prostředí výuky předmětu PV Výsledky testů pro prostředí výuky předmětu PV Testovací scénáře pro prostředí Exchange Výsledky testů pro prostředí Exchange Použití nástroje Virsto One pro Exchange Závěr Literatura vii

8 Kapitola 1 Úvod V kontextu výpočetní techniky je pojem virtualizace, neboli vytváření iluze něčeho, co fyzicky není k dispozici, používán již delší dobu. At už se jedná o koncept virtualizace operační paměti nebo třeba virtuálních sítí (VLAN). Perspektivním artiklem se však v dnešní době jeví virtualizace celých počítačů architektury x86 (často označováno jako virtualizace platformy nebo též systémová virtualizace). Firma VMWare, jakožto průkopník v této oblasti, je toho se stále rostoucími příjmy (2 miliardy dolarů za rok 2009 [57]) dobrým důkazem. Za další indicií lze považovat zprávu [37] poradenské firmy Gartner Inc., která uvádí, že v roce 2012 bude až 50 % veškerých běžících systémů na platformě x86 již virtualizováno. Odkud se ale bere ten nebývalý zájem o tuto technologii? Stále se zvyšující výkon dnešních počítačů umožňuje provozovat násobně více aplikací na jediném fyzickém počítači. Uvažme nyní použití klasického přístupu v podobě právě jednoho operačního systému (OS) a v něm provoz různých aplikací. Není tak těžké nahlédnout, že efektivně využít dostupného výkonu fyzického počítače může být přinejmenším problematické. Všechny aplikace nemusí být nutně vzájemně kompatibilní, v horším případě mohou rovnou vyžadovat odlišné verze OS. Netriviální je i zajištění bezpečnosti v takovémto prostředí. Zejména ve větších společnostech je běžné, že různé týmy jsou zodpovědné za provoz různých aplikací. A pokud se více takových týmů sejde na jednom serveru, velice snadno pak dochází k úpravám nějaké konfigurace systému, která má neblahý vliv na všechny ostatní aplikace. Nemluvě o nutnosti umožnit přístup většímu množství administrátorů k serveru, což pro kritické aplikace nemusí být žádoucí stav. Tyto a další aspekty jsou podrobněji diskutovány v kapitole 2.2, ale již nyní by mělo být patrné, že použití klasického přístupu mnohdy vede k neefektivnímu využívání zdrojů a potencionálně i vyšším nákladům. Virtualizace platforem může být poměrně snadné a dostupné řešení, které pokud je dobře navrženo a používáno přináší i další výhody. Provoz jakéhokoliv virtualizovaného prostředí má však své specifické vlastnosti. Tato práce se snaží detailně zmapovat poznatky pro optimální využití virtualizačního nástroje Hyper-V. 1.1 Struktura práce Druhá kapitola práce pojednává o virtualizaci platformy obecně, krátce popisuje používané metody virtualizace a hodnotí vlastnosti virtuálního prostředí. 1

9 1.1. STRUKTURA PRÁCE Třetí kapitola se detailně zaměřuje na popis jednotlivých částí virtualizačního nástroje Hyper-V a jejich používání. Zvláštní pozornost je věnována důsledkům jednotlivých nastavení na funkcionalitu celého prostředí. Čtvrtá kapitola práce se zaměřuje na testování výkonnosti virtualizačního prostředí s cílem optimalizace jeho provozu v praxi. 2

10 Kapitola 2 Virtualizace Tato část práce poskytuje základní přehled běžně používaných technik z oblasti virtualizace platforem. Diskutuje obecné důvody pro zavedení virtualizace platforem včetně problémů, které tuto změnu provází. 2.1 Virtualizace platformy Jako virtualizace platformy je označován mechanismus logického rozdělení fyzického počítače na jeden či více samostatných virtuálních počítačů. Virtuální prostředí v tomto případě poskytuje dostatečné prostředky pro běh operačního systému a aplikací takovým způsobem, jako by se jednalo o samostatný počítač. Virtuální prostředí sdílí systémové prostředky (CPU, RAM a vstupní/výstupní zařízení) fyzického prostředí, proto se často lze setkat s označením host a hostitel pro vyjádření virtuálního a fyzického počítače. Zejména starší operační systémy nebyly pro běh ve virtuálním prostředí vytvořeny, a proto obvykle předpokládají, že mají exkluzivní přístup ke všem fyzickým systémovým prostředkům. S tím úzce souvisí i fakt, že technické prostředky počítače oprávněně očekávají využívání právě jedním operačním systémem. Virtualizace však tento přístup mění a namísto operačního systému přebírá kontrolu nad fyzickými systémovými prostředky tzv. hypervizor. Mezi jeho hlavní úkoly patří přidělování systémových prostředků virtuálním počítačům a zajištění vzájemné izolace. Systémová virtualizace v podstatě zavádí multitasking na úrovni výpočetních prostředí řízených běžnými operačními systémy. Hostovaný systém můžeme přirovnat k procesu a hypervizor k operačnímu systému. Hypervizor musí v takovém případě zastat všechny bázové funkce operačního systému. Provádí plánování, přidělování a účtování zdrojů. Zprostředkovává hostovaným systémům privilegované rutiny, pro jejichž vykonání nemají dostatečná oprávnění. [10] Nejčastěji používané metody jsou diskutovány v samostatných podkapitolách. Uvedené popisy metod jsou pouze přehledové, zájemcům o detailní zpracování problematiky virtualizačních metod lze doporučit diplomovou práci Lukáše Patky [10] Plná virtualizace Pokud postupujeme tímto způsobem, tj. virtualizujeme důsledně všechny součásti počítače, hovoříme o tzv. plné virtualizaci (full virtualization). V takovémto případě nabízíme 3

11 2.1. VIRTUALIZACE PLATFORMY prostředí, v němž běžící operační systém nemůže žádným způsobem poznat, že nemá přístup k fyzickému technickému vybavení (hardware). Operační systém ani aplikační programy nepotřebují žádné modifikace. Jedná se v podstatě o ideální stav, kdy dochází k plnému oddělení fyzické vrstvy, veškeré programy běží pouze na virtuálním hardware a přístup k fyzickému vybavení je vždy zprostředkován. To má samozřejmě řadu výhod můžeme virtuální prostředí navrhnout tak, aby nám vyhovovalo (velikost paměti, typ procesoru, typ a kapacitu disku apod.). Programy jsou rovněž nezávislé na konkrétním technickém vybavení, jeho změna nemá na virtuální prostředí vliv (samozřejmě kromě výkonnostních charakteristik, tj. náš virtuální počítač může běžet rychleji nebo pomaleji, ale v každém případě poběží). U plné virtualizace nemusí existovat žádná jednoduchá vazba mezi virtuálním prostředím a konkrétním hardware, na němž je virtuální počítač provozován. To umožňuje plnou přenositelnost, operační systém a aplikace běžící na procesoru Intel s architekturou IA-32 můžeme spouštět třeba na počítačích, vybavených procesory PowerPC. A následně je můžeme přenést na počítače vybavené jiným procesorem, aniž bychom provedli jedinou úpravu na úrovni virtuálního počítače. Podobně můžeme vytvořit virtuální počítač vybavený procesorem, který je teprve ve vývoji návrh a ladění operačního systému a aplikací tak může probíhat paralelně s vývojem vlastního hardware. [8] Paravirtualizace Umožňuje, aby virtuální počítač přímo využíval některých zařízení fyzického počítače, což z hlediska využitelného výkonu působí pozitivně. Jakákoliv mezivrstva, která má interpretovat požadavky virtuálních prostředí, zákonitě spotřebuje část dostupného výkonu fyzického počítače. A pokud je tato mezivrstva redukována, je možné maximalizovat využití HW prostředků pro potřebu virtuálních prostředí. Typicky nedochází k emulaci procesoru, což se sice projevuje lepším výkonem, ale stále vyžaduje určitou režii na zajištění izolace. Je nezbytné ošetřit provádění operací, které by mohly způsobit narušení jiného virtuálního prostředí nebo samotného hypervizoru. Konkrétní metody pak vycházejí z možností daných architektur. Pro architekturu x86 je typickým příkladem použití tzv. binárního překladu, který za běhu zajišt uje bezpečné vykonání (emulaci) potencionálně nebezpečných instrukcí virtuálních počítačů. Postupem času uvedli výrobci hardwaru technologie pro přímou podporu virtualizace v jednotlivých komponentách počítače. Tento druh je často označován jako hardwarová podpora virtualizace. Například u procesorů architektury x86 lze pod označením AMD-V a Intel VT-x nalézt rozšířenou instrukční sadu a další optimalizace, které zjednodušují návrh a implementaci hypervizorů, nebot není potřeba používat čistě softwarové metody. Další metodou, která se řadí do paravirtualizace, je úprava samotného hostovaného OS pro provoz ve virtuálním prostředí. Takto upravený systém využívá pro komunikaci s virtualizovaným hardwarem programové rozhraní, které mu zprostředkovává hypervizor. Podobně jako když běžné programy využívají API operačního systému. Tato úprava umožňuje další zrychlení celého virtualizačního procesu. Nevýhoda je ale zjevná modifikace OS ne- 4

12 2.2. MOTIVACE K VIRTUALIZACI PLATFOREM musí být vždy možné řešení, například pro systémy s neveřejným zdrojovým kódem Virtualizace na úrovni jádra operačního systému Další zajímavou metodou je umístění virtualizační vrstvy na úroveň jádra hostitelského operačního systému. V tomto případě sdílejí virtuální počítače společný softwarový základ, každý stroj je však samostatný, je možné ho zapnout a vypnout stejně jako běžný počítač. Vzájemná izolace pak může využít některé existující mechanismy jádra operačního systému (jako je např. PID, UID, IPC atd.) doplněné o vazbu na konkrétní virtuální počítač včetně možnosti přidělování systémových prostředků. Ze všech uvedených metod vyžaduje tento přístup nejmenší režii na zajištění virtualizace, není potřeba duplikovat sdílené knihovny, souborový systém a jeho cache ani emulovat přístup k HW zařízením. Slabou stránkou tohoto přístupu je však vazba na hostitelský operační systém. Nelze provozovat různé OS zároveň (např. Linux a Windows), a mnohdy ani různé verze téhož OS. Do určité míry jsou tímto omezeny i možnosti přenášení takto virtualizovaného prostředí. Za povšimnutí stojí fakt, že díky odlišné vrstvě, na které probíhá virtualizace, je možné tuto metodu zkombinovat s některou z předchozích a získat tak výhody z obou. Mezi zástupce z řad virtualizačních nástrojů využívajících tuto metodu patří Linux-VServer, OpenVZ či Parallels Virtuozzo Containers. 2.2 Motivace k virtualizaci platforem První zmínky o nasazení konceptu virtualizace platforem jsou datovány k 60. létům minulého století [3]. Tehdy operační systém s označením CP-40 umožňoval běh několika virtuálních prostředí v rámci jednoho fyzického počítače mainframe firmy IBM. V těchto virtuálních prostředích byl pak provozován jednoduchý jednouživatelský operační systém. V té době se jednalo o jednu z metod, jak zajistit víceuživatelský model, bez nutnosti vytvoření komplexního operačního systému, který by takový přístup umožňoval sám o sobě. Dnes již běžně používané OS pro platformu x86 víceuživatelský přístup pochopitelně podporují, současný provoz několika OS (bez virtualizace) však nikoliv. Takový mechanismus je však užitečný hned z několika důvodů a právě těmi se zabývá tato část kapitoly Snížení počtu fyzických serverů a nákladů spojených s jejich provozem V prostředí, kde jsou provozovány různé druhy OS, je zpravidla nutné pro každý typ OS vyhradit vlastní fyzický počítač, bez ohledu na volnou kapacitu ostatních počítačů. Bez možnosti virtualizace je tento přístup v zásadě jediným možným řešením. Situace je podobná i v prostředích s jedním druhem OS. Důvody jsou však odlišné. Můžeme mezi ně zařadit požadavky samotných aplikací, které jsou natolik provázány s OS, že jiné aplikace či komponenty je činí vzájemně nekompatibilními. Z toho pak pramení i jistá míra obezřetnosti při zavádění nových aplikací. Raději než riskovat pozdější problémy způsobené aktualizacemi, úpravou konfigurace nebo požadavkem na delegování administrátorských oprávnění 5

13 2.2. MOTIVACE K VIRTUALIZACI PLATFOREM dalším osobám, je jednoduší pro každou novou aplikaci vytvořit samostatné prostředí. Nemluvě o nutnosti nejprve vše důkladně otestovat. Zároveň bývá při výběru fyzického počítače často počítáno s nereálně velkou rezervou (což je však lepší než server poddimenzovat), čemuž nahrává i fakt, že výkon serverů neustále stoupá. Dalším příkladem neefektivního využití zdrojů jsou testovací systémy. Mohou to být kopie produkčního prostředí, které je používáno pouze pro otestování dopadu nějaké změny, nebo plejáda různých konfigurací OS a nainstalovaných aplikací, které jsou používány pro testování během vývoje nějakého softwaru. Díky virtualizaci je možné konsolidovat systémy, které dostatečně nevyužívají systémové prostředky fyzického počítače, a zredukovat tak počet fyzických serverů. Základním předpokladem je, že fyzický počítač bude mít dostatečnou kapacitu pro vykrytí případných špiček všech hostovaných systémů během období zvýšené zátěže. Průměrné vytížení serverů je však nízké a pohybuje se kolem 30 až 40 %.[35] Snížením počtu fyzických počítačů lze dosáhnout úspor v podobě snížení spotřeby elektrické energie. Ačkoliv se na první pohled může zdát, že po převedení vhodných počítačů do virtuálního prostředí zůstává celkový spotřebovaný výkon a tedy i spotřeba zachována, není tomu tak. Požadavky na potřebný výkon s největší pravděpodobností stoupnou díky režii způsobené virtualizací, ale spotřeba klesne. Běžný server totiž spotřebuje až 50 % energie při pouhém 10% využití jeho kapacity[2]. Pro ilustraci je na obrázku 2.1 zobrazena spotřeba energie serveru v závislosti na využití jeho celkové kapacity. Snížením počtu fyzických serverů je následně možné snížit i náklady na zajištění dodávek energie pro další technologie, jako jsou sít ové prvky, transformátory, UPS jednotky či klimatizace, dále pak servisní služby nebo pojištění, a zároveň zmenšit obsazený prostor. Obrázek 2.1: Spotřeba a efektivita využití elektrické energie serveru v závislosti na jeho zátěži [2] 6

14 2.2.2 Zvýšení dostupnosti serverů 2.2. MOTIVACE K VIRTUALIZACI PLATFOREM Pro menší společnosti nemusí být snížení počtu fyzických serverů z pohledu úspor energie natolik zásadní, zejména pokud provozují jen malé množství serverů a nemají dedikované chlazení či další technologie. Virtualizace umožňuje, aby došlo i k situaci, že budou všechny kritické systémy umístěny na jediném fyzickém počítači, což by právě u malých společností, hledajících úsporu za každou cenu, mohlo snadno nastat. To se v porovnání s klasickým přístupem může jevit jako zásadní nevýhoda, kdy pád jednoho počítače znamená kompletní odstávku, zatímco dříve způsobil nedostupnost několika služeb. Při návrhu virtualizovaného prostředí je proto vhodné brát v úvahu i možné selhání hardwaru, nebot se hostitelský počítač stává kritickým místem. Nicméně ani takové selhání fyzického počítače nemusí být zásadní problém virtuální počítače totiž bývají v hostitelském počítači reprezentovány jako obyčejné soubory a dají se tak relativně snadno přesouvat mezi dalšími hostiteli. V případě výpadku pak není nic snazšího, než soubory přenést do jiného hostitele s dostatečnou volnou kapacitou a znovu je spustit. Taková obnova je mnohem rychlejší než příprava fyzického počítače. Přenos virtuálního počítače z hostitele na hostitele lze provádět i za běhu hostovaného systému. Tato technika, často označovaná jako migrace za běhu, je jednou z atraktivních vlastností virtualizace. Migraci za běhu lze s úspěchem využít například pro plánované odstávky fyzických počítačů z důvodu jejich údržby. Bez virtualizace nezbývá, než dočasný výpadek oželet. Případně musí být provozované aplikace natolik robustní, že se výpadek jednoho serveru v poskytovaných službách neprojeví, anebo jinými prostředky zajistit, že k výpadku nedojde. To zpravidla vyžaduje, aby aplikace podporovala běh v clusteru pro zajištění vysoké dostupnosti, nebo je nutné zajistit současný provoz záložního serveru a s ním spojenou vzájemnou synchronizaci aplikačních dat. Obě metody jsou však technicky i finančně náročnější. Bližší upřesnění si zaslouží pojem cluster. Pod pojmem cluster rozumíme několik víceméně samostatných počítačů (v tomto kontextu nazývaných uzly) propojených do jednoho funkčního celku. [6] S pomocí virtualizace je možné vytvořit cluster pro zajištění vysoké dostupnosti virtuálních počítačů, který v případě nečekaného selhání některého uzlu v clusteru, zajistí spuštění zasažených virtuálních počítačů na ostatních funkčních uzlech. V běžném pojetí je využití clusterů pro zajištění vysoké dostupnosti svázáno s podporu konkrétních aplikací, což omezuje možnosti jejich využití. V případě virtualizace platforem tento problém odpadá Zvýšení flexibility serverů Doba potřebná pro přípravu nového fyzického počítače je v porovnání s jeho virtuálním protějškem obrovská. I když uvážíme použití nějakého systému pro automatizované nasazení OS a aplikací, stále ještě musí někdo fyzický server někam umístit (za předpokladu, že ho má vůbec na skladě). Situaci navíc může komplikovat fakt, že z ekonomických důvodů není vždy používán stejný typ serveru a je nutné do automatizovaného systému pro nasa- 7

15 2.2. MOTIVACE K VIRTUALIZACI PLATFOREM zení OS nejprve zavést příslušné ovladače hardwaru a celý proces poté náležitě otestovat. Virtualizace poskytuje patřičnou abstrakci HW vybavení a vytvoření, úprava nebo zrušení virtuálního počítače jsou proto velmi rychlé. Často je v této souvislosti používáno konceptu tzv. šablon. Šablonou rozumíme již zkonfigurovaný počítač, který je vždy zkopírován a dodatečně upraven (od názvu počítače až po velikost RAM paměti). Obvykle je možné systém správy zpřístupnit přímo koncovým uživatelům, kteří tak získávají přímou kontrolu (v předem stanovených mezích) nad svým virtuálním počítačem. Uvažme například poskytovatele virtuálních serverů, který umožňuje svým zákazníkům měnit HW konfiguraci počítačů pomocí webového rozhraní. Zákazník si může okamžitě přidat více RAM paměti nebo třeba sít ových karet a systém mu automaticky naúčtuje patřičnou částku. Stejně tak vytvoření či zrušení počítače může proběhnout bez asistence technika. To vše snižuje náklady, možnou chybu způsobenou lidským faktorem a nakonec i zvyšuje samotnou rychlost celého procesu. V dnešní době je neobvyklé najít firmu, která se zabývá poskytováním hostingových služeb a v jejíž nabídce není nějaká forma virtuálních počítačů obsažena. Zálohování a obnova dat jsou nedílnou součástí provozu každého produkčního systému. Mimo použití klasických metod je díky virtualizaci možné využívat i zachycení okamžitého stavu virtuálního počítače (obsah RAM, stavy registrů, obsah připojených disků a nastavení). Jestliže hypervizor odebere konkrétnímu virtuálnímu počítači procesor, virtuální počítač se zastaví, ale "neví"o tom. V tomto stavu můžeme virtuální počítač "uklidit", tj. vzít veškerou pamět, kterou používá, a zkopírovat ji na disk. Takto vytvoříme obraz virtuálního počítače ve stavu, který odpovídá hibernaci operačního systému (bez virtualizace). Proti hibernovanému stavu, který zpravidla nelze spustit jinde než na tom počítači, kde došlo k hibernaci, můžeme virtuální obraz přesunout na jiný počítač a spustit jej tam přesunuli (migrovali) jsme tak celý virtuální počítač na jiný fyzický, aniž by jakkoliv došlo k narušení vnitřního stavu virtuálního počítače. [9] Na tomto místě je vhodné uvést, že tuto metodu nelze vždy použít (kvůli vzniku možných nekonzistencí dat v distribuovaných systémech) a mnohdy je využívána primárně testovacími systémy. Typickým příkladem je třeba testování různých aktualizací systému, kdy se po několikahodinovém procesu aktualizace zjistí, že systém nefunguje korektně a je nutné aktualizaci zase odinstalovat, a v horším případě rovnou obnovit systém ze zálohy. Konečně virtualizace platforem umožňuje i jejich jednodušší outsourcing, resp. poskytování formou služby. Zákazník nemusí servery hostovat ve svém datovém centru a starat se o veškeré náležitosti s tím spojené (pracovníky, hardware, klimatizaci, napájení, zálohování atd.), ale obvykle za poplatek odpovídající celkovému využití zdrojů v čase získává možnost spravovat virtuální prostředí pro provoz svých systémů. Odpadají tak počáteční náklady na nákup potřebného fyzického vybavení, což může být zajímavé nejen pro začínající společnosti, ale i pro projekty, u kterých nelze předem odhadnout potřebnou kapacitu výkonu nebo je nutné zajistit velkou škálovatelnost. To však neznamená, že je takový přístup vhodný pro všechny scénáře využití. Zajímavý pohled do světa virtualizovaného přístupu a využívaní jeho služeb nabízí publikace [1]. 8

16 2.3. NEVÝHODY VIRTUALIZACE 2.3 Nevýhody virtualizace V předcházejícím textu jsem zmínil především výhody virtualizace, bylo by však chybou předpokládat, že neexistují žádné nevýhody a problémy. V této sekci jsou proto diskutovány základní komplikace virtualizovaného přístupu Sdílení systémových prostředků Jednou z myšlenek virtualizace je sdílení systémových zdrojů. Zde je vhodné položit si otázku, co bude následovat, pokud některý z virtuálních počítačů začne nadměrným způsobem využívat sdílené prostředky? Všechny dnes běžně používané virtualizační nástroje pro platformu x86 umožňují definovat priority v přidělování systémových prostředků virtuálním počítačům. Bohužel jsou možnosti tohoto nastavení omezené typicky se jedná o využití procesoru, velikost operační paměti a dostupného diskového prostoru. Sít ová a úložná zařízení jsou pak obvykle sdílená na principu first-come, first-served. Jeden virtuální počítač pak může kompletně využít sdílené prostředky na úkor všech ostatních. Jedno z používaných řešení tohoto problému je vyhradit pro počítač s vyššími nároky dedikovaná I/O zařízení nebo speciální hostitele. Tím ale snižujeme dynamiku celého prostředí a navíc není vždy možné dopředu zjistit, jak intenzivně bude počítač využíván. Okamžitá migrace počítače, který nadměrně využívá sdílené zdroje, na jiného hostitele situaci nemění, pokud zůstane datové uložiště stejné. A přemístění desítek či stovek GB tvořících virtuální počítač do odděleného uložiště nějakou dobu potrvá. Pokud by ale systém automatické migrace reagoval příliš rychle, nedělal by nic jiného, než neustále přemíst oval nárazově využívané počítače. Nárazové zatížení může být způsobeno i tak obvyklou činností, jako je instalace aktualizací. Zatímco je běžné, že automatické stahování aktualizací (at už OS nebo aplikací) je rozloženo do nějakého časového úseku, doba jejich instalace je obvykle nastavena na konkrétní hodinu/den. V ryze fyzickém prostředí to pochopitelně nevadí, ale ve virtualizovaném ano. Například výchozí nastavení OS Windows instaluje aktualizace každý den v 03:00, přičemž nové aktualizace zveřejňuje spol. Microsoft každé druhé úterý v měsíci. Je tedy třeba počítat s dočasným snížením výkonu anebo rezervovat kapacitu jen pro tyto výkyvy, jednodušší je však úprava nastavení systémů a vyvarování se spouštění úloh ve stejný čas. Není to ale možné zajistit vždy (např. zákazníci hostingové společnosti by nemuseli takové zásahy do svých systémů ocenit) Složitost systému a cena Virtualizace zavádí novou vrstvu, které původní nástroje pro monitoring a správu fyzických prostředí nerozumějí a neumějí ji správně interpretovat. Ačkoliv se začínají objevovat nástroje, které jsou určeny pro správu virtuálního prostředí, každý výrobce používá svůj vlastní, specifický pro daný virtualizační software. Nástroj jedné firmy neposkytuje stejnou úroveň ovládání pro své prostředí jako nástroj druhé, obvykle se jedná o podporu 9

17 2.3. NEVÝHODY VIRTUALIZACE velmi základního charakteru, která je určena spíše pro přechod od jednoho výrobce k druhému. Navíc stále chybějí nástroje propojující jak fyzický tak virtuální svět. Pokud uživatelé hlásí problém s propustností sítě na nějakém virtuálním serveru, o kterou sít se tedy jedná? O virtuální nebo o fyzickou? A pokud fyzickou, je problém na straně fyzického adaptéru hostitele, příjemce nebo jiných sít ových prvků? Podobně nelze přepokládat, že najednou budou všechny systémy virtuální, a tak nelze původně používané nástroje jednoduše opustit. Správce systému by měl být schopen jednoduše získat ze všech relevantních systémů požadované informace pro diagnostiku problémů. Pokud však bude nucen projít několik různých na sobě nezávislých systémů a ručně si spojovat jednotlivé části, zabere mu to více času a snáze udělá chybu. Důvody pro nasazení nějakého monitorovacího nástroje přibývají s množstvím spravovaných počítačů a jejich důležitostí. Pokud navíc nejsou stanovena pravidla a implementovány kontrolní mechanismy pro provoz nových virtuálních počítačů, dochází k jejich nekontrolované tvorbě, zvláště pokud je tato možnost poskytnuta koncovým uživatelům. To je ostatně stejné jako s jakýmkoliv jiným zdrojem srovnejte například s neomezenou kapacitou domácího adresáře nebo sdílené složky a chováním běžného uživatele. Celá řada OS a aplikací navíc není poskytována zdarma, a je proto žádoucí provozovat jen to množství systémů, které je skutečně potřeba. Do nákladu na provoz virtualizovaného prostředí je nutné započítat nejen náklady na hardware (pokud nebude použit stávající), ale i zaškolení personálu a licence (nebo technickou podporu) pro potřebné monitorovací a virtualizační nástroje a aplikace. Celá řada výrobců aplikací dnes nabízí licenční model vhodný pro použití ve virtuálním prostředí. Stále však existují takoví, kteří striktně trvají na licencování vázaném na fyzické parametry počítače, jako je třeba počet procesorů. Aby bylo možné využít migrace anebo clusteru pro zajištění vysoké dostupnosti, je nutné licencovat každý fyzický počítač, na kterém se aplikace může potencionálně vyskytnout. Horší jsou už jen ti výrobci, kteří trvají na licencování všech procesorů ve fyzickém počítači, nejen těch, které má virtuální počítač přiděleny a může je používat. Dalším faktorem může být problematická podpora různého hardwaru, který není z fyzického prostředí možno prezentovat do virtuálního, např. různé hardwarové licenční klíče či zvukové karty. Důležitý je i aspekt zabezpečení. Je patrné, že kdo má kontrolu nad hypervizorem, fakticky ovládá virtuální počítače, nebot může libovolně manipulovat jak uloženými daty na disku, tak pamětí i prováděnými operacemi. Narušení izolace mezi jedním virtuálním počítačem a hypervizorem pak může ohrozit všechny na něm hostované počítače. V každém populárním virtualizačním nástroji již byly takové chyby nalezeny. Jednou ze zmiňovaných výhod virtualizace byla přenositelnost díky reprezentaci virtuálních počítačů jakožto několika souborů. Několik souborů se však dá lépe zkopírovat v porovnání s celým fyzickým počítačem a zabezpečení sdíleného uložiště tak nabírá na důležitosti. Podobně jednoduše lze s přístupem k uložišti modifikovat i obsah virtuálních počítačů. Jako protiopatření lze využít šifrování a digitální podpisy. 10

18 Kapitola 3 Hyper-V V roce 2008 vydala společnost Microsoft první verzi svého virtualizačního nástroje s názvem Hyper-V, který je určen pro systémovou virtualizaci na platformě x86. Nástroj byl distribuován jako volitelná součást OS Windows Server 2008 v 64 bitové verzi (WS2008x64) a zároveň jako samostatný produkt s názvem Hyper-V Server Zatímco Hyper-V Server 2008 je k dispozici zdarma a jedná se o speciální variantu Server Core instalace (minimalizovaná verze Windows, neobsahuje klasické grafické rozhraní a má menší systémové nároky), WS2008x64 zdarma není, a je nabízen v několika edicích lišících se primárně cenou a další podporovanou funkcionalitou. Tento systém členění zůstal zachován i nadále. V době vzniku této diplomové práce nesla nejnovější verze OS označení Windows Server 2008 R2 Service Pack 1 (veřejně dostupná od ) a pokud není výslovně uvedeno jinak, je nadále pod označením Hyper-V myšlena varianta s volitelnou součástí Hyper-V v plné instalaci nejnovější verze Windows edice Datacenter. V této kapitole je nejprve představena architektura a základní části Hyper-V a poté i podrobný popis důsledků jednotlivých nastavení. 3.1 Architektura Hyper-V Na obrázku 3.1 je zobrazeno obecné schéma architektury Hyper-V. Základem virtualizační platformy Hyper-V je hypervizor, který zajišt uje vzájemnou izolaci jednotlivých virtuálních prostředí označovaných jako Partition. Hypervizor řídí přístup ke kritickým systémovým zdrojům, jako je například obsluha přerušení, plánování CPU nebo RAM, které by mohly vzájemnou izolaci narušit. Na rozdíl od klasických OS Windows však neobsahuje žádné ovladače hardwaru ani jinou dodatečnou funkcionalitu, jako například příkazy pro práci se soubory nebo textový editor. Microsoft zkonstruoval svůj hypervizor tak, že obsahuje jen nejnutnější programové části (a je proto relativně malý a snáze udržovatelný) a vše ostatní je delegováno do tzv. privilegovaného virtuálního počítače. Privilegovaný virtuální počítač, označovaný jako Parent Partition, musí být typu Windows Server 2008 v 64 bitové verzi (případně 2008 R2+) a tímto počítačem je celé virtualizační prostředí ovládáno. Zároveň má jako jediný počítač přímý přístup k hardwaru, který zprostředkovává pro ostatní virtuální počítače označované jako Child Partition. Veškerý hardware v Child Partition je virtuální a přístup k němu lze rozdělit na dvě kategorie, emulovaný a paravirtualizační. 11

19 3.1. ARCHITEKTURA HYPER-V Obrázek 3.1: Obecné schéma architektury Hyper-V, šipky znázorňují komunikaci jednotlivých komponent [7] Pokud jsou do hostovaných OS (Child Partitions) nainstalovány tzv. integrační komponenty (v originále Integration Services Components nebo také Enlightments ), dochází v nich k vytvoření syntetických zařízení (označují se jako syntetická proto, že neodpovídají žádnému existujícímu fyzickému zařízení) a přístup k fyzickým zařízením je skrze ně zprostředkován. Ovladače syntetických zařízení jsou označovány jako VSC (Virtualization Service Client) a pomocí vysokorychlostního logického mechanismu VMBus komunikují s VSP (Virtualization Service Provider) v Parent Partition. VSP pak s pomocí standardních ovladačů zpracovávají I/O požadavky od virtuálních zařízení na fyzickém hardwaru. Bez nainstalovaných integračních komponent dochází v Child Partition k emulaci hardwaru, např. virtuální sít ový adaptér v takovém případě odpovídá fyzickému adaptéru Intel based PCI Fast Ethernet Adapter. OS v Child Partition pak používá ovladače odpovídající tomuto adaptéru a hypervizor musí I/O požadavky zachytávat a přesměrovávat do Parent Partition. To je však pomalejší než v případě syntetických zařízení, protože dochází k přepínání kontextu, které je nutné pro obsloužení emulovaného zařízení. Pro ilustraci je na obrázku 3.2 zobrazena cesta I/O požadavku v systému pro emulovaný a syntetický sít ový adaptér. Proces označovaný jako Worker Process je vytvořen pro každou jednotlivou spuštěnou nebo konfigurovanou Child Partition. Jedním z jeho úkolů je právě emulace zařízení pro daný virtuální počítač. 12

20 3.1. ARCHITEKTURA HYPER-V Obrázek 3.2: Obecné schéma architektury Hyper-V, šipky znázorňují komunikaci jednotlivých komponent. [7] Integrační komponenty zpřístupňují hostovanému OS nejen rychlejší zpracování I/O požadavků, ale i rozhraní pro komunikaci s hypervizorem, které je použito například pro zefektivnění překladu fyzických adres nebo synchronizaci času. V současné době existují integrační komponenty pro většinu OS Windows a některé distribuce OS Linux, konkrétní seznam je uveden zde [39]. V souvislosti s hypervizorem bych rád upozornil na tvrzení, které je často prezentováno při různých porovnáních. Tedy, že díky minimalistickému pojetí konstrukce hypervizoru Hyper-V se snižuje možnost programové chyby a protože se zároveň nepoužívá ani žádný cizí kód (např. ovladače zařízení), je prostor pro případné narušení bezpečnosti systému redukován na minimum. Takový přístup ale vyžaduje použití privilegovaného počítače, který je neustále v provozu v případě Hyper-V se tedy jedná o celou instalaci Windows (případně Server Core variantu). Ta je však v porovnání s hypervizorem, který by obsahoval veškerou funkcionalitu k zajištění virtualizace a její správy (ale nic víc), obrovská. Narušení zabezpečení privilegovaného počítače pak umožňuje libovolně manipulovat s ostatními virtuálními počítači na hostiteli. 13

21 3.2. PŘEHLED FUNKCIONALIT 3.2 Přehled funkcionalit V této části jsou podrobně diskutována nastavení systému Hyper-V a jejich vliv na virtualizační prostředí Stav virtuálního stroje Pro jednodušší strukturování textu je pojem Snapshot používán ještě před jeho kompletním vysvětlením. Jedná se o mechanismus, který umožňuje zachytit konfiguraci a okamžitý stav virtuálního počítače včetně obsahu připojených virtuálních pevných disků (VHD) a později se k němu vrátit. Virtuální počítač se může nacházet právě v jednom z následujících stavů: Starting zapínání počítače. Tento stav trvá jen velmi krátkou chvíli (inicializace virtuálního hardwaru). Stopping vypínání počítače. PowerOff vypnutý počítač (odpojené napájení počítače). Pausing pozastavování počítače. Paused pozastavený počítač. Running spuštěný počítač, normální provoz. Resuming obnovování počítače z uloženého (Saved) stavu. Saving přechod do uloženého stavu počítače. Saved uložený počítač. Obsah RAM paměti a stav zařízení je uložen na pevném disku fyzického počítače a virtuální počítač je v hibernovaném stavu. Migrating migrace počítače z jednoho uzlu clusteru na jiný. Snapshotting stav kdy je vytvářen Snapshot počítače. Paused-Critical pokud jsou používány dynamické nebo diferenciální VHD disky a v hostitelském systému, kde jsou tyto VHD disky uloženy, začne docházet místo na disku (méně jak 200MB), dojde k pozastavení virtuálních strojů a jejich stav je změněn na Paused-Critical. Pro jejich opětovné zapnutí (stav Running) je nezbytně nutné nejprve uvolnit místo na disku hostitele. 14

22 3.2. PŘEHLED FUNKCIONALIT Základní nastavení virtuálního počítače Veškeré konfigurovatelné části lze měnit pouze v Parent Parititon, Child Partition samo o sobě nastavení měnit nemůže. Mezi konfigurovatelné části každého virtuálního počítače patří následující: BIOS nabízí pouze možnost aktivovat NumLock a zvolit pořadí zařízení, ze kterých se má BIOS pokusit provést zavedení OS. Operační pamět definuje velikost operační paměti virtuálního počítače. K dispozici jsou 2 způsoby přidělování paměti, statický a dynamický. Statický způsob alokuje při startu virtuálního počítače předem definovanou velikost paměti, bez ohledu na to, zda ji virtuální počítač bude schopen patřičně využívat. Velikost takto přiřazené paměti lze měnit pouze pokud je počítač vypnutý. Druhý režim spočívá v dynamickém přidělování paměti na základě požadavků virtuálních počítačů. Vlastnosti tohoto přístupu jsou podrobněji diskutovány v části Ani v jednom případě však nelze v součtu přes všechny virtuální počítače přidělit více operační paměti, než je její volná kapacita v rámci fyzického počítače. Virtuálnímu počítači lze bez ohledu na použitou metodu přidělit nejvýše 64GB RAM. Procesor po nainstalování role Hyper-V do systému Windows dojde ke změně v plánování fyzického procesoru. Roli přebírá od OS hypervizor a všechny logické procesory, které jsou prezentovány jednotlivým Partition, jsou od té chvíle virtuální. Zatímco Parent Partition má k dispozici všechny virtuální procesory, Child Partition lze přidělit nejvýše 4 (v závislosti na konkrétním OS to ale může být i jen 1). Další vlastnosti procesoru jsou diskutovány v části Řadič IDE umožňuje připojení virtuální CD/DVD mechaniky a virtuálních pevných disků pomocí IDE řadiče. CD/DVD disky mohou být ve formě ISO obrazů nebo lze využít fyzickou CD/DVD mechaniku. Virtuální pevné disky mohou být ve formě VHD disků nebo lze využít libovolných pevných disků připojených k hostiteli. IDE řadič je na rozdíl od virtuálního SCSI řadiče dostupný i bez nainstalovaných integračních komponent (jedná se tedy o emulované zařízení) a lze ho proto využít pro připojení virtuálního disku, ze kterého se bude zavádět OS. Pokud jsou však nainstalovány integrační komponenty, je po spuštění systému IDE řadič přepnut do režimu využívajícího paravirtualizační přístup (mění se na syntetické zařízení) a dosahuje srovnatelné rychlosti jako SCSI řadič. Lze připojit až dva virtuální IDE řadiče, přičemž na každý z nich lze připojit nejvýše 2 zařízení. Řadič SCSI je syntetický typ zařízení pro připojení virtuálních pevných disků a disků připojených k hostiteli, který je přístupný až po zavedení systému s nainstalovanými integračními komponentami. Na rozdíl od IDE řadiče, je možné připojit a odpojit disky i za běhu virtuálního počítače. Mezi další rozdíly patří největší možná velikost I/O požadavku, pro IDE je maximum 128KB, zatímco pro SCSI 8MB [58]. 15

23 3.2. PŘEHLED FUNKCIONALIT Nejvýše lze připojit 4 virtuální SCSI řadiče, přičemž na každý lze připojit nejvýše 64 disků. Sít ový adaptér k dispozici jsou dva druhy adaptérů, syntetický (network adapter) a emulovaný (legacy network adapter). Pokud je virtuální počítač vypnutý, lze přidávat a odebírat adaptéry, nejvýše lze připojit 8 syntetických a 4 emulované adaptéry. Ačkoliv emulovaný adaptér odpovídá kartě standardu Fast Ethernet s maximální rychlosti 100Mbit/s, není systémem Hyper-V rychlost omezována a je možné dosáhnout rychlosti vyšší. Syntetický adaptér má definovanou maximální rychlost 10Gbit/s. Jedním z důvodu proč použít emulovaný adaptér i pro počítač, který umožňuje použití syntetických zařízení, je podpora PXE (zavedení systému ze sítě namísto lokálního úložiště). Konfigurace virtuálních sít ových adaptérů a sítí je podrobně diskutována v části COM port umožňuje zpřístupnit COM porty virtuálního počítače. Virtuálnímu počítači jsou prezentovány dva neodstranitelné COM porty, které lze v hostiteli napojit na pojmenovanou rouru (named pipe). Nelze jej však napojit na fyzické COM porty hostitele. Pokud virtuální počítač vyžaduje přístup na fyzický COM port, lze jej zprostředkovat pouze pomocí nástrojů třetích stran. Pojmenovaná roura je mechanismus komunikace mezi procesy v rámci více počítačů přes sít nebo v rámci jednoho počítače. Disketová mechanika umožňuje načtení souboru s obrazem virtuální diskety (koncovka.vfd) o velikosti 1,44MB nebo 720KB. Mechanika je neodstranitelnou součástí každého virtuálního počítače, načtení obrazu diskety je možné v zapnutém i vypnutém stavu. Přímé napojení fyzické disketové mechaniky na virtuální není v Hyper-V možné bez nástrojů třetích stran. I v dnešní době je disketová mechanika nenahraditelný pomocník, například u starších OS, které během procesu instalace či zavádění neumějí pracovat s ničím jiným. Jméno a popis jméno a popis počítače slouží výhradně pro potřeby správy v systému Hyper-V. Ačkoliv lze zvolit libovolný název, který nekoresponduje s DNS či jiným názvem virtuálního počítače, je vhodné definovat nějaký systém (jmenné konvence) a důsledně jej dodržovat. Pokud má DNS název virtuálního počítače odpovídat názvu v Hyper-V, je třeba při jeho změně provést patřičnou aktualizaci na obou místech. Zároveň je na základě tohoto jména vytvořen adresář, do kterého jsou umístěny soubory virtuálního počítače (pokud není zvoleno výchozí umístění souborů). Jméno počítače lze libovolně měnit, ale adresář změnu automaticky nereflektuje, což může na první pohled zmást obsluhu virtuálního prostředí. Integrační komponenty lze zapínat/vypínat jednotlivé integrační komponenty. Jejich popis je uveden v části Akce při startu a vypnutí počítače umožňuje definovat akci, která bude vykonána v případě spuštění fyzického počítače. Lze volit mezi spustit počítač, pokud byl 16

24 3.2. PŘEHLED FUNKCIONALIT spuštěn, než došlo k vypnutí služby Hyper-V či vždy automaticky spustit virtuální počítač nebo žádnou akcí. Pro kritické virtuální počítače může být vhodné zvolit automatické spouštění. Dále lze definovat časovou prodlevu před spuštěním počítače, čehož lze využít pro dřívější spuštění počítačů, na kterých závisí další služby (například řídicí systémy, či databázové servery). Akce pro vypnutí počítače jsou uložení stavu (Save), vypnutí (Shut Down) a odpojení napájení (Turn Off) Reprezentace virtuálního počítače Každý virtuální počítač je v hostitelském systému reprezentován jako několik souborů, konkrétně: XML obsahuje nastavení virtuálního počítače (např. velikost RAM, počet CPU a konfiguraci sít ových adaptérů, připojené pevné disky... ). XML soubor existuje vždy pro každý virtuální počítač a každý existující Snapshot. Jako jméno souboru je vždy použito GUID (Globally unique identifier) virtuálního počítače. BIN v případě, že je virtuální počítač v uloženém (Save) stavu nebo se jedná o o zachycený stav (Snapshot), je v tomto souboru uložen obsah jeho operační paměti. Soubor je však vytvořen ihned při startu počítače a jeho velikost odpovídá přidělené operační paměti virtuálnímu počítači. Smyslem tohoto chování je rezervace diskového prostoru pro případ, že dojde k situaci, kdy je potřeba bezpečně uložit stav virtuálního počítače (např. při restartování hostitele a spouštění akcí definovaných při vypnutí počítače nebo v případě nedostatku volného prostoru na disku hostitele). Service Pack 1 pro Windows Server 2008 R2 přidal novou funkcionalitu nazvanou Dynamická pamět (Dynamic Memory), která za běhu systému umožňuje měnit velikost operační paměti a tedy i velikost BIN souboru. To ale může vést k situaci, že nelze hostovanému systému zvětšit velikost operační paměti i když je volná pamět k dispozici pokud není dostatek volného prostoru na disku hostovaného systému pro zvětšení BIN souboru [40]. VSV plní podobnou funkci jako soubor BIN, ale v tomto případě je obsahem souboru stav virtuálních zařízení. VHD (Virtual Hard Disk) je soubor s obsahem virtuálního pevného disku. AVHD (Automatic VHD) je diferenciální typ VHD disku používaný pro Snapshot. Ve výchozí konfiguraci jsou tyto soubory ukládány do dvou adresářů, přičemž v jednom jsou pouze VHD soubory %PUBLIC%\Documents\Hyper-V\Virtual Hard Disks\ a v druhém všechny ostatní %PROGRAMDATA%\Microsoft\Windows\Hyper-V\. Běžně se však při vytváření nových virtuálních počítačů volí odlišné umístění, než je výchozí pak jsou všechny soubory jednoho virtuálního počítače umístěny v jedné složce. Tento přístup 17

25 3.2. PŘEHLED FUNKCIONALIT je více intuitivní a má i výhodu v jednodušší konfiguraci NTFS oprávnění pro regulaci přístupu k souborům. Za předpokladu, že název virtuálního počítače je FileServer a všechny soubory jsou v jedné složce, dostáváme následující strukturu (uvedený příklad vychází z [11]): D:\VMs\FileServer D:\VMs\FileServer\HardDisk.VHD D:\VMs\FileServer\Snapshots D:\VMs\FileServer\Snapshots\[Snapshot #1 GUID] D:\VMs\FileServer\Snapshots\[Snapshot #1 GUID]\[Snapshot #1 GUID].BIN D:\VMs\FileServer\Snapshots\[Snapshot #1 GUID]\[Snapshot #1 GUID].VSV D:\VMs\FileServer\Snapshots\[Snapshot #1 GUID].XML D:\VMs\FileServer\FileServer_[Snapshot #1 GUID].AVHD D:\VMs\FileServer\Snapshots\[Snapshot #2 GUID] D:\VMs\FileServer\Snapshots\[Snapshot #2 GUID]\[Snapshot #2 GUID].BIN D:\VMs\FileServer\Snapshots\[Snapshot #2 GUID]\[Snapshot #2 GUID].VSV D:\VMs\FileServer\Snapshots\[Snapshot #2 GUID].XML D:\VMs\FileServer\FileServer_[Snapshot #2 GUID].AVHD D:\VMs\FileServer\Virtual Machines D:\VMs\FileServer\Virtual Machines\[VM GUID] D:\VMs\FileServer\Virtual Machines\[VM GUID]\[Virtual Machine GUID].BIN D:\VMs\FileServer\Virtual Machines\[VM GUID]\[Virtual Machine GUID].VSV D:\VMs\FileServer\Virtual Machines\[Virtual Machine GUID].XML Pokud jsou všechny soubory všech virtuálních počítačů ukládány do společného adresáře (nebo tak jak je výchozí konfigurace do dvou), je na základě GUID poměrně náročné rozpoznat, o jaký počítač se vlastně jedná (v grafickém rozhraní se pracuje téměř výlučně se jménem počítače, a nikoliv s GUID). Jak již bylo zmíněno, pro každý běžící virtuální počítač existuje Worker Process, který v hostovaném systému reprezentuje některé funkce virtuálního počítače. Tento proces pak přistupuje k výše popsaným souborům. Aby proces nemohl přistoupit k jiným souborům ani prostředkům hostovaného systému, má přidělen zvláštní SID (Security Identifier jednoznačný identifikátor entity v systému) tvaru NT VIRTUAL MACHINE\VMID, kde VMID je GUID virtuálního počítače. Kdykoliv je pomocí standardních nástrojů pro správu přidělen nějaký zdroj virtuálnímu počítači (např. další VHD disk či vytvořen snapshot), je virtuálnímu počítači přidáno příslušné oprávnění k přístupu, obráceně pak při odebrání zdroje. Manuální úprava NTFS oprávnění může systém uvést do nekonzistentního stavu. Uvažme například situaci, kdy je potřeba dočasně přemístit soubory tvořící virtuální počítač na jiný diskový oddíl a poté je vrátit zpět. Tento přesun však ve výchozím nastavení a za použití obvyklých nástrojů nezachovává NTFS oprávnění a virtuální počítač nebude možné spustit. Stejný problém by mohl nastat, pokud by k úpravě konfigurace (např. přidání VHD disku) došlo přímou editací XML souboru. 18

26 3.2. PŘEHLED FUNKCIONALIT Doporučovaný způsob umístění všech souborů jednoho virtuálního počítače do jediné složky bohužel není vždy možný, například pokud se VHD soubory nachází na různých diskových oddílech kvůli optimalizaci zátěže. Z tohoto důvodu je jedinou podporovanou metodou pro přemístění souborů v rámci jednoho počítače export a import. Neboli, společnost Microsoft poskytuje technickou podporu pro tuto funkcionalitu, ale neznamená to, že to nelze provést i jinak. Export počítače je možný, pouze pokud je vypnutý nebo v uloženém stavu, a spočívá ve vytvoření jediného adresáře s kopiemi všech potřebných souborů (během exportu tak nedochází k odstranění virtuálního stroje, na druhou stranu je potřeba dostatek volného diskového prostoru). Tento nový adresář lze libovolně přemíst ovat, a jakmile je na správném místě, je možné jej importovat. Během importu lze v grafickém rozhraní zvolit namísto přímého importu duplikaci, což znamená, že importovaný adresář bude zkopírován, a je tak možné proces znovu opakovat. Volbu duplikace během importu lze pak využít pro klonování virtuálních počítačů, přičemž je zajištěno, že (z pohledu Hyper- V) je každý stroj unikátní a příslušně izolovaný Virtuální pevné disky Virtuální pevný disk, označovaný jako VHD (Virtual Hard Disk), je soubor v hostitelském systému reprezentující disk virtuálního počítače. Z pohledu hostovaného systému je k nerozeznání od fyzického, z pohledu hostitelského systému však rozlišujeme několik druhů VHD: Fixní (Fixed) velikost VHD souboru je alokována při vytváření virtuálního disku a odpovídá jeho maximální kapacitě. Například virtuální disk o maximální kapacitě 20GB zabírá 20GB na disku hostitelského systému, nehledě na to, kolik dat je reálně na virtuálním disku uloženo. Dynamické (Dynamic) velikost VHD souboru je alokována až v momentě zápisu dat do virtuálního disku. Například virtuální disk o maximální kapacitě 20GB zabírá 5GB na disku hostitelského systému, pokud je v něm zapsáno 5GB dat. Dynamický disk je automaticky zvětšován po 2MB částech, na druhou stranu však není automaticky zmenšován. Proces zmenšení (Compact) je nutné inicializovat manuálně a během jeho provádění nelze s diskem pracovat. Diferenciální (Differencing) je navázán na jiný libovolný virtuální disk, který je následně označován jako rodič. Veškeré změny dat jsou zaznamenány do diferenciálního disku namísto rodiče, zatímco čtení (nezměněných/původních) dat je stále realizováno z rodičovského disku. Disk je vytvořen jako dynamický (zvětšuje se tedy až v momentě zápisu dat), ale jeho velikost nemůže přesáhnout maximální velikost rodičovského disku (odpovídá přepisu všech dat na rodičovském disku). Teoretická maximální velikost (podle specifikace) fixních disků je 16TB, s pomocí grafického rozhraní pro správu Hyper-V (Hyper-V Manager) je možné vytvořit a používat fixní disk 19

27 3.2. PŘEHLED FUNKCIONALIT pouze o velikosti 2040GB. U dynamických a diferenciálních disků je však tato velikost jejich maximální možnou [20], nehledě na způsob jejich vytvoření. Typické použití diferenciálních disků (mimo Snapshot) je pro rychlé klonování nějakého počítače. Uvažme například situaci, kdy je vytvořen virtuální počítač, nainstalovány desítky aplikací a upravena konfigurace do požadovaného stavu. Tento počítač je potřeba zpřístupnit pro několik stovek dalších uživatelů. Zkopírování VHD disku pro každého uživatele je pochopitelně jedno z možných řešení, ale zbytečně plýtvá dostupným místem na hostitelském systému, nebot disky virtuálních počítačů budou (alespoň z počátku) identické. Namísto toho, vytvoření diferenciálního disku pro každého uživatele je téměř okamžité a zároveň ušetří i diskový prostor, který by jinak byl obsazen duplicitními daty. Nevýhodou je však sdílený zdroj (rodičovský disk), který může být vystaven nadměrnému zatížení, a navíc jej nelze jednoduše modifikovat. V momentě, kdy je rodičovský disk modifikován, jsou všechny na něm navázané diferenciální disky nepoužitelné, nebot obsahují jen změny v diskových blocích oproti rodičovskému disku, a nikoliv původní data. Proto je vhodné rodičovský disk označit NTFS atributem jen pro čtení a dbát zvýšené opatrnosti při manipulaci s tímto diskem. Diferenciální disk lze snadno exportovat do nového (případně sloučit do původního) virtuálního fixního nebo dynamického disku, který pak obsahuje výsledná data (rodič + potomek). Sloučení je mimo jiné používáno i pro aktualizaci uloženého VHD souboru namísto přenášení celého (nového) disku. Diferenciální disky mohou vytvářet složitější hierarchii, kdy je diferenciální disk jednoho rodičovského disku rodičem jiného diferenciálního disku. Zřetězení diferenciální disků za sebe, může obsahovat nejvýše 1024 disků. Níže jsou sumarizovány vlastnosti jednotlivých typů virtuálních disků. Fixní virtuální disk Výhody: Nejlepší výkon [58]. Méně náchylné k fragmentaci na úrovni hostitelského systému. Vychází z faktu, že diskový prostor pro VHD soubor je alokován hned při vytváření. To pochopitelně neznamená, že pokud je najednou vytvářeno více fixních VHD souborů v jednom uložišti, nebo jsou VHD soubory následně přemíst ovány, nedojde nikdy k jejich fragmentaci. Odpadá problém s možným nedostatkem volného místa v hostitelském systému a následným přepnutím počítače do Pause-Critical stavu. Zároveň může u dynamických a diferenciálních disků dojít ke ztrátě dat, pokud během jejich zvětšení dojde k výpadku napájení [46]. Nejedná se přímo o výhodu, ale v případě některých aplikací není jejich výrobcem poskytována technická podpora, pokud jsou data umístěna na jiném typu disku než na fixním. Nevýhody: 20

28 Obsazení diskového prostoru, aniž by byl reálně využit PŘEHLED FUNKCIONALIT Dlouhá doba potřebná pro vytvoření disku. Veškerý alokovaný prostor pro VHD je totiž nejprve přepsán (samé 0). Jinak by mohla nastat situace, že se z virtuálního počítače lze dostat na původní data, která se nacházela na fyzickém disku. Zmíněné přepisování za cenu možné kompromitace dat lze obejít použitím dalších nástrojů pro práci s VHD soubory, například VHDTool ( Dynamický a diferenciální virtuální disk Výhody: Minimální doba potřebná pro vytvoření disku. Minimalizace obsazeného prostoru na fyzickém disku a s tím spojená i rychlejší manipulace s VHD souborem. Nevýhody: Nižší výkon. Defragmentace uvnitř virtuálního diferenciálního disku způsobí zvětšení VHD souboru a výsledek operace s největší pravděpodobností nepřinese žádné zvýšení výkonu. Maximální velikost omezena na 2040GB. Změna rodičovského disku způsobí ztrátu dat u diferenciálního typu disku. Formátování disku, které přepisuje všechna data, způsobí zvětšení VHD souboru na formátovanou kapacitu. Může dojít k vytvoření dynamických disků, jejichž celková maximální kapacita překračuje kapacitu úložného systému. Hrozí tak, že postupem času dojde k přeplnění úložného systému, ačkoliv bude v rámci virtuálního počítače prezentován dostatek volného místa na disku (který odpovídá virtuálnímu disku, a nikoliv úložišti, kde je disk umístěn). Samostatnou kategorii pak tvoří přímé připojení disku z hostitelského systému (označováno jako pass-through disk). Jinými slovy, umožňuje virtuálnímu počítači přímý přístup (jako by byl připojen lokálně) k disku hostitelského počítače. Nedochází tak k vytváření VHD souboru ani není omezena maximální velikost připojeného disku. Není však možné vytvořit Snapshot počítače, který by zachoval data na přímo připojeném disku, ani jednoduše (jako VHD soubory) zkopírovat disk do jiného umístění či k němu vytvořit diferenciální disk. Přímo připojený disk je napojen na SCSI nebo IDE řadič virtuálního počítače. Dále jsou ve výchozím nastavení všem přímo připojeným disků z bezpečnostních důvodů filtrovány předávané SCSI příkazy. Pokud je vyžadován přístup k plné sadě SCSI příkazů (například aplikace spravující diskové pole), lze filtrování vypnout pro jednotlivé virtuální počítače. 21

29 3.2. PŘEHLED FUNKCIONALIT Zachycení stavu (Snapshot) Slouží k zachycení konfigurace a stavu virtuálního počítače v nějakém okamžiku a umožňuje se k němu později vrátit. Základem Snapshot mechanismu jsou diferenciální disky, které zajišt ují, že původní data nebudou modifikována. Pokud má virtuální počítač přímo připojený disk (pass-through) z hostitelského systému, nelze snapshot použít. Podobně, pokud má virtuální počítač připojen další disk, který není součástí jeho konfigurace (není uložen v XML souboru, a Hyper-V o něm tedy neví ) například pomocí iscsi nebude snapshot fungovat správně. Zachycení stavu se skládá z: 1. Pozastavení virtuálního počítače. 2. Vytvoření diferenciálního disku k momentálně používanému virtuálnímu disku. 3. Vytvoření kopie stávající konfigurace. 4. Upravení konfigurace virtuálního počítače tak, aby používal nově vytvořený diferenciální disk. 5. Obnovení činnosti virtuálního počítače. 6. Zatímco virtuální počítač běží, původní obsah jeho operační paměti a stav zařízení je ukládán na disk. 7. Jakmile je obsah operační paměti a stav zařízení uložen na disku, operace je dokončena. Pozastavení virtuálního počítače během zachycení stavu je krátkodobé. Zachytit stav lze pouze, pokud je počítač vypnutý nebo zapnutý. Pokud je virtuální počítač vypnutý, proces je totožný, ale nedochází k pozastavení a obnovení činnosti ani k ukládání stavu operační paměti a zařízení. Pro každý virtuální počítač lze zachytit nejvýše 50 stavů. Na obrázku 3.3 je pomocí kořenového grafu vyobrazena možná struktura zachycených stavů pro jeden virtuální počítač. V daném případě se jedná o využití Snapshot mechanismu pro testování OS a různých aplikací v různých verzích. Mezi jednotlivými stavy lze velmi rychle přecházet (pokud byl virtuální počítač zapnutý, postačí nyní jen načíst uložený obsah operační paměti a zařízení). Například pokud se měl změnit aktuální stav virtuálního počítače na OS + Aplikace B + Aplikace C, je nutné se nejprve rozhodnout, co se stane s aktuálním stavem. Tedy zda se uloží (a vznikne tak fakticky nový Snapshot), anebo zda se má smazat. Předpokládejme tedy, že se aktuální stav zachová. Cílový stav je načten tak, že je nejprve vytvořen nový diferenciální disk k cílovému stavu a poté obnoven obsah uložené paměti. Pokud by nový diferenciální disk nebyl vytvořen, došlo by k nežádoucí modifikaci cílového stavu a nebylo by možné se znovu do stejného stavu vrátit. Situace po této změně je zobrazena na obrázku 3.4. Pokud je uložený stav smazán pomocí nástrojů pro správu Hyper-V, jsou provedeny následující kroky: 22

30 3.2. PŘEHLED FUNKCIONALIT Obrázek 3.3: Stuktura zachycených stavu (Snapshot) jednoho virtuálního počítače pro testování různých aplikací [7] 1. Smazání uložené konfigurace. 2. Smazání uloženého obsahu operační paměti a stavu zařízení. 3. Jakmile je virtuální počítač vypnutý, dojde ke sloučení diferenciálního virtuálního disku s jeho rodičovským diskem. To platí pouze v případě, že mazaný stav má nějakého následníka (tím může být i aktuální stav). Pokud je mazaný stav bez následníků, je diferenciální disk odstraněn okamžitě a žádné sloučení není provedeno. Smazání souborů tvořících snapshot jiným způsobem než pomocí nástrojů pro správu způsobí narušení konfigurace a problémy při spouštění počítače. Pokud je navíc smazán nějaký disk po cestě od kořene k aktuálnímu stavu, dojde ke ztrátě dat. Jiným typickým scénářem pro použití snapshot mechanismu je zachycení stavu těsně před úpravou konfigurace virtuálního počítače. Pokud provedená úprava nezpůsobí problémy, je možné snapshot později odstranit a pokud ano, je možné se velice rychle vrátit do původního stavu. Používání snapshot mechanismu má však několik nevýhod: Nelze později změnit velikost virtuálního disku. Změna velikosti kořenového disku by totiž znamenala zneplatnění všech diferenciálních. Chybí možnost automatizované aktualizace uložených stavů. Pokud je snapshot využíván pro testování různých konfigurací OS a aplikací, může být žádoucí pro- 23

31 3.2. PŘEHLED FUNKCIONALIT Obrázek 3.4: Stuktura zachycených stavu (Snapshot) jednoho virtuálního počítače po na načtení uloženého stavu "OS + Aplikace B + Aplikace C"[7] vádět jejich aktualizace (či změny konfigurace, např. změna velikosti paměti, či přidání sít ového adaptéru). To ale znamená aktualizovat každý uložený stav zvlášt, po jednom (v jeden okamžik může být aktivní jen jeden stav) a manuálně (alternativně si lze naprogramovat vlastní nástroj). Proces sloučení disku po vymazání uloženého stavu je proveden pouze pokud je virtuální počítač vypnutý. To znamená, že do té doby jsou data ukládána do diferenciálního disku, který je však pomalejší než fixní disk. Zejména pro systémy, které ve velké míře využívají úložiště (a z toho důvodu i fixní disk, který je nejrychlejší), může být zpomalení nežádoucí. Navíc nelze přesně odhadnout dobu potřebnou pro sloučení disků. Pokud je odstraněno více uložených stavů současně, jejich sloučení i tak probíhá po jednom, sériově. Po aktualizaci systému Hyper-V z verze Windows Server 2008 na Windows Server 2008 R2 není možné spustit Snapshot, který byl vytvořen za běhu virtuálního počítače ve starší verzi Hyper-V [41]. Je pravděpodobné, že i další aktualizace bude fungovat obdobně. Je zjevné, že Snapshot mechanismus není náhradou zálohování, protože data jsou ve výchozí konfiguraci ukládána do stejného adresáře (i kdyby nebyla ukládána do stejného adresáře, závisí vše na kořenovém virtuálním disku, který však není nikde duplikován). Zároveň virtuální počítač neví, že byl takto uložen a pokud je obnoven z uloženého stavu a aplikace takový stav neočekávají, může snadno dojít k opakování akcí, které již byly ve skutečnosti jednou provedeny. Což u zálohovacího mechanismu nebývá očekáváná vlastnost. 24

32 3.2. PŘEHLED FUNKCIONALIT Často je proto namísto snapshot mechanismu využíváno pouze diferenciálních disků a samostatných virtuálních počítačů, což sice neřeší všechny nevýhody, ale zato je možné používat počítače zároveň. Pro srovnání obou přístupů lze nahlédnout na obrázek 3.4 tak, že by nyní nereprezentoval jeden jediný virtuální počítač a jeho zachycené stavy, ale každý diferenciální disk bez následníků by reprezentoval samostatný virtuální počítač s vlastní konfigurací Možnosti nastavení procesoru Tato část diplomové práce o možnostech nastavení procesoru je sumarizací této [12] série článků. Hyper-V umožňuje řídit přidělování procesorového času několika způsoby. Pro přehlednost jsou prezentovány funkcionality v příkladech, kdy má fyzický stroj vždy 2 logické procesory (např. 1jádrový procesor s technologií HyperThreading). Pro každý virtuální stroj je možné zarezervovat část výkonu procesoru. Tato rezervace je vyjádřena jako procentuální hodnota celkového času přidělených virtuálních procesorů. Pokud tedy nastavíme hodnotu 100 % jako rezervaci pro virtuální počítač s 2 virtuálním procesory, nelze na hostiteli spustit žádný další počítač s rezervací, protože jsou všechny dostupné procesory fyzického systému rezervované (nehledě na skutečné využití procesoru tímto jedním počítačem). Rezervace nelze chápat jako konstantní přidělení výkonu, ale jako spodní hranici, pod kterou výkon procesoru nikdy nepoklesne. V případě, že je celkové využití všech logických procesorů ve fyzickém systému nižší než 100 % (jinými slovy je stále dostatek výkonu procesoru), není rezervace žádným způsobem u již spuštěných počítačů uplatňována. V momentě kdy již nelze plně uspokojit požadavky počítačů s rezervací, dochází k jejich upřednostňování. Řečeno příkladem, je k dispozici 1 virtuální počítač s 100% rezervací procesoru a 20 dalších bez rezervace (fakticky s rezervací 0 %). Jakýkoliv počítač může využít maximum procesorových prostředků, ale pouze do té doby, než se začne nedostávat prostředků počítači s rezervací tedy než začne vykonávat nějakou činnost. V ten okamžik jsou počítače bez rezervace omezovány. Vzhledem k tomu, že nelze spustit více počítačů s rezervací, než je maximum celkového výkonu, je vždy zaručeno, že lze rezervovaný výkon zajistit. Uvažme však ještě jednu modelovou situaci s 2 virtuálními počítači, každý s 1 virtuálním procesorem a rezervací 70 %. Uvažovaný fyzický počítač s 2 logickými procesory je tedy nyní rezervován ze 70 % své celkové kapacity a 30 % dvou logických procesorů je stále k dispozici. Pokud bychom se nyní pokusili spustit další virtuální počítač s pouze 1 virtuálním procesorem a rezervací 40 %, nebude to možné. Ačkoliv se zdá, že hodnota celkové rezervace fyzického procesoru by v takovém případě byla 90 %, bude Hyper-V v případě dalšího stroje hledat jeden logický procesor s 40% kapacitou. Ale k dispozici jsou jen 2 logické procesory, každý s 30% kapacitou. Dalším způsobem řízení přidělování CPU je omezení (v anglické dokumentaci označováno jako limit ). Omezením, lze nastavit maximální hodnotu využití virtuálního procesoru vyjádřenou v procentech, kterou virtuální počítač nemůže překročit. Omezení se vztahuje na každý jednotlivý přidělený virtuální procesor, nikoliv na součet jejich výkonu. Ve 25

33 3.2. PŘEHLED FUNKCIONALIT výchozím nastavení má každý virtuální počítač nastaveno omezení na 100 %, tj. může využít maximum kapacity virtuálního procesoru. Posledním způsobem je tzv. váha, která se udává jako číslo od 1 do Pokud není během procesu vytváření virtuálního počítače váha specifikována, je automaticky nastavena na hodnotu 100. Váhu si lze představit jako prioritu jednotlivých virtuálních procesorů. Uplatňována je však až v momentě nedostatku volných prostředků, kdy jsou počítače s vyšší váhou upřednostňovány. Zatímco rezervace a omezení definují dolní, resp. horní meze využití procesoru, váha je více relativní. Nezaručuje, že virtuální počítač dostane nějakou předem známou část procesorového času, ale že bude preferován před ostatními. Ačkoliv se všechny uvedené způsoby dají využívat zároveň, obvykle je využíván pouze jeden. Typické použití rezervace je pro garantování výkonu kritických služeb (serverů). Omezení je typické pro odstínění vlivu aplikací, které mají tendenci využívat veškerý dostupný výkon nebo jsou špatně napsány a nelze tento problém řešit jinak. Typické využití váhy je k rozdělení virtuálních počítačů do kategorií (např. na produkční a testovací). Je však záhodno definovat váhy jednotným způsobem. Například pokud jeden administrátor definuje váhu pro produkční počítače 200 a všem ostatních ponechá výchozí hodnotu 100, bude vše v pořádku až do okamžiku, kdy další administrátor definuje pro nové produkční počítače hodnotu váhy 101. Nevýhodu však spatřuji v tom, že nejen toto nastavení, ale ani žádné jiné vztahující se k prioritám systémových prostředků, nelze řídit pomocí mechanismu skupin, ale pouze pro jednotlivé virtuální počítače. Alternativou je vytvoření skriptu, který by kontroloval všechny virtuální počítače a priority upravoval podle daného nastavení (pro zařazení virtuálních počítačů do skupin lze využít pole pro popisek). Dalšími konfiguračními možnostmi virtuálního procesoru jsou dva druhy omezení funkcionality. První nazvaný Run An Older Operating System, Such As Windows NT umožňuje odfiltrovat vlastnosti procesoru, který Windows NT neumí zpracovat podrobný popis lze nalézt v [5]. A druhý nazvaný Migrate To A Physical Computer With A Different Processor Version odfiltruje odlišnosti ve funkcionalitě procesorů podporujících virtualizaci. Jinými slovy, virtuálními počítači jsou zpřístupněny pouze ty nejzákladnější vlastnosti procesoru. Takový virtuální počítač je možné za běhu přenést na jiný fyzický počítač i s odlišným fyzickým procesorem, což je jinak limitující podmínkou pro migraci za běhu či spouštění uloženého stavu na jiném počítači. Kompatibilita je však zajištěna jen v rámci procesorů jednoho výrobce, tj. nelze přenést počítač z procesoru Intel na procesor AMD. Nevýhoda je zjevně v tom, že nelze využít pokročilých vlastnosti procesu, níže je uveden jejich příklad: AMD: SSSE3, SSE4.1, SSE4.A, SSE5, POPCNT, LZCNT, Misaligned SSE, 3DNow! Intel: SSSE3, SSE4.1, SSE4.2, POPCNT, Misaligned SSE, XSAVE, AVX Společnost Microsoft poskytuje technickou podporu pouze pokud je poměr pro virtuální : logický procesor menší nebo roven 8 : 1. Neboli, na fyzickém počítači s jedním 2jádrovým procesorem a technologií HyperThreading (4 logické procesory) lze přidělit nejvýše 32 virtuálních procesorů (může tedy provozovat 32 virtuálních počítačů s 1 virtuálním procesorem, nebo 16 virtuálních počítačů s 2 virtuálními procesory atd). Pokud jsou všechny hostované 26

34 3.2. PŘEHLED FUNKCIONALIT počítače s OS Windows 7, je poskytována technická podpora pro poměr 12 : 1. Logických procesorů může být přitom nejvýše Integrační komponenty (Integration Services Components) Všechny integrační komponenty komunikují výlučně pomocí mechanismu VMBus. Jedná se o software, který se instaluje do Child Partition a je aktivní pouze pokud je počítač zapnutý a integrační komponenty jsou spuštěny (jinými slovy, nefungují při zavádění OS, ale až po startu příslušných služeb v hostovaném OS). Instalátor integračních komponent je uložen ve formě ISO obrazu na disku hostitele v adresáři %SYSTEMROOT%\system32\VMGuest. iso. ISO soubory se dají jednoduše připojit do virtuální mechaniky hostovaného systému. Primárně umožňují hostovanému systému využivat paravirtualizační přístup. Zároveň integrační komponenty obsahují několik samostatně konfigurovatelných služeb: Synchronizace času (Time synchronization). Zjištění dostupnosti (Heartbeat). Stínovaná kopie svazku (Volume Shadow Copy). Podpora vypínání (Shutdown). Výměna dat (Key/value pair exchange) Synchronizace času V každém běžném počítači lze (obvykle v podobě integrovaného obvodu) nalézt hodiny reálného času (RTC real-time clock), které udržují údaj o aktuálním čase. Většina OS však tento zdroj pro systémový čas nepoužívá, přesněji používá ho pouze při spuštění systému, kdy načte aktuální hodnotu, ale dále čas počítá na základě jiného mechanismu. Přičemž tento mechanismus je založen na běžném chování fyzického hardwaru, který však ve virtuálním prostředí není stejný, a to způsobuje odchylky v čase (čím více virtuálních strojů, tím větší odchylka). Dobře zpracovaný popis mechanismu synchronizace času ve fyzickém prostředí lze nalézt v prvních částech dokumentu [33]. Hyper-V pomocí služby synchronizace času umožňuje synchronizovat čas hostovaného systému podle Parent Partition. Při spuštění virtuálního počítače je do jeho virtuálních RTC předán aktuální čas z fyzických RTC, nehledě na to, zda jsou, nebo nejsou nainstalovány integrační komponenty. Tento přístup však nebere v potaz existenci různých časových pásem, ačkoliv každý virtuální počítač může být nastaven odlišně od Parent Partition. Nicméně, krátce po plném naběhnutí systému přebírá funkci integrační komponenta a zajišt uje správné nastavení času zohledňující časové pásmo virtuálního počítače (časové pásmo se automaticky zjišt uje z virtuálního počítače). Poté komponenta zajišt uje, že čas virtuálního počítače nebude příliš odlišný od toho v Parent Partition, nikoliv však, že bude v každém okamžiku naprosto stejný. 27

35 3.2. PŘEHLED FUNKCIONALIT Za povšimnutí stojí fakt, že by problém s rozdílným časem během startu mohl být elegantně vyřešen používáním UTC času v RTC, bohužel však většina OS Windows (od Windows Vista SP1+ již, lze viz [42]) čas v UTC formátu v BIOSu nepodporuje, tj. do RTC se vždy ukládá/načítá hodnota lokálního času ovlivněná časovým pásmem. Z uvedeného zároveň plyne, že pokud je tato integrační služba vypnuta a čas není ve virtuálním počítači synchronizován nějakým jiným způsobem s externím zdrojem, nebude čas odpovídat skutečnosti. Pokud je zvolen mechanismus synchronizace času s externím zdrojem je vhodné ověřit, zda je interval dostatečný, nebot ke ztrátě přenosnosti dochází ve virtuálním prostředí mnohem rychleji než ve fyzickém. Poměrně často se lze setkat s doporučením deaktivace integrační komponenty pro synchronizaci času u počítačů, které jsou samy zdrojem času pro ostatní počítače konkrétním příkladem jsou doménové řadiče Active Directory provozované ve virtuálním prostředí (faktem je, že toto doporučení vycházelo přímo z oficiálních stránek Microsoftu a teprve nedávno bylo opraveno). Doménový řadič je obvykle nastaven tak, aby se sám synchronizoval s externím zdrojem času a ostatní počítače připojené v Active Directory jsou pak synchronizovány podle času doménového řadiče. Větší časové rozdíly mezi jednotlivými počítači pak způsobují problémy s používaným autentizačním mechanismem Kerberos. Úplnou deaktivací integrační komponenty pro synchronizaci času však dojde i k vypnutí již diskutované funkce, která zajišt uje úpravu času po startu systému na základě správného časového pásma. Za správné řešení je proto považována tzv. částečná deaktivace, která ponechá funkcionalitu úpravy času po startu, ale další synchronizace je pak závislá na externím zdroji [43] Zjištění dostupnosti (Heartbeat) Tento mechanismus umožňuje Parent Partition zjišt ovat dostupnost Child Partition. Přesněji, Parent Partition periodicky posílá požadavky do komponenty v Child Partition a pokud neobdrží odpověd v určitém časovém úseku, zaznamená tuto skutečnost do systémového logu Applications and Services Logs\Microsoft\Windows\Hyper-V Integration. Jedná se tedy o velmi jednoduchou formu monitorování virtuálního počítače. Je pak na obsluze virtuálního prostředí, jak s touto informací naloží Stínovaná kopie svazku (Volume Shadow Copy) Umožňuje zálohování dat virtuálních počítačů v konzistentním stavu. Pokud nějaká aplikace provádí změnu v souboru, který je během jejího provádění zkopírován, nelze obvykle zaručit, že zkopírovaná data jsou v konzistentním stavu z pohledu aplikace (například převod peněz z účtu na účet, kdy je z jednoho účtu nutné peníze odečíst a k druhému přičíst). Aby bylo možné zálohovat data, ke kterým je neustále přistupováno, jako jsou například různé databázové soubory či právě virtuální disky (VHD) virtuálních počítačů, je ve Windows používán mechanismus stínované kopie svazku (Volume Shadow Copy). Ten zajišt uje, že si aplikace na vyžádání uloží svá data v konzistentním stavu na disk (je patrné, že 28

36 3.2. PŘEHLED FUNKCIONALIT tento systém vyžaduje určitou implementaci podpory přímo v aplikaci). V okamžiku, kdy jsou data bezpečně uložena, je vytvořena stínovaná kopie svazku, odpovídající stávajícím datům, která je určena pouze pro čtení. Vytvoření stínované kopie je relativně rychlé a aplikace mohou nerušeně pokračovat v práci (po dobu jejího vytváření jsou IO požadavky ukládány do fronty k pozdějšímu zpracování). Následně je udržována stínovaná kopie v původním stavu pomocí mechanismu využívajícího monitorování přístupu k diskovým blokům. Před tím, než jsou jednotlivé diskové bloky po vytvoření stínované kopie změněny, jsou vytvořeny jejich kopie v dočasném úložišti (což může být klidně i stejný diskový svazek). Stínová kopie tak neustále reprezentuje původní data v době svého vytvoření diskové bloky, které nebyly změněny, se nacházejí v původním umístění a ty, které byly změněny, jsou v dočasném úložišti. Čím rychleji se však bude měnit obsah původních dat, tím více bude potřeba diskového prostoru pro uchování stínované kopie. Tato integrační služba zajišt uje, že (podporované) aplikace uvnitř virtuálního počítače uloží svá data na disk, OS vyprázdní vyrovnávací paměti, dokončí probíhající transakce atd. Hostitelský OS může následně vytvořit stínovanou kopii virtuálních disků virtuálního počítače. Takto lze vytvořit zálohu celého virtuálního počítače za běhu a s konzistentními daty. Operační systémy, které nepodporují tuto službu (což jsou zejména všechny platformy Linux), nebo ji mají vypnutou, pak musí být pro vytvoření zálohy tohoto druhu vypnuty (jinak nemusejí být data uložená na virtuálních discích konzistentní). Případně lze akceptovat riziko a namísto vypnutí počítače použít jen dočasné pozastavení Podpora vypínání (Shutdown) Umožňuje bezpečně vypnout virtuální počítač bez toho, aby bylo potřeba se k němu vzdáleně přihlásit (např. pomocí SSH, RDP nebo jiného mechanismu). V momentě, kdy Hyper-V obdrží od hostovaného systému potvrzení o předání požadavku na vypnutí, je v grafickém rozhraní Hyper-V zobrazen ukazatel průběhu vypnutí. Ten však reálnému průběhu vypínání virtuálního stroje neodpovídá jednoduše proto, že v momentě, kdy dojde k ukončení integračních komponent, nezbývá nic, co by dále sledovalo tento průběh. Pokud do 5 minut nedojde k vypnutí stroje, je zobrazena chybová zpráva bez ohledu na to, že vypínání počítače může mezitím nadále pokračovat Výměna dat (Key/value pair exchange) Umožňuje výměnu dat mezi hostem a hostitelem pomocí registru. Ve výchozím nastavení to jsou informace o verzi OS a názvu počítače, ale lze jej doplnit o libovolnou další. Vzhledem k tomu, že se na platformě Linux registr nevyskytuje, není tato funkce pro tento druh OS dostupná Dynamická změna velikosti operační paměti za běhu počítače Dynamická změna velikosti operační paměti za běhu virtuálního počítače je v systému Hyper-V podporována jen pro velmi omezený počet verzí OS Windows [44] s nainstalova- 29

37 3.2. PŘEHLED FUNKCIONALIT nými integračními komponentami. Zejména jej tedy nelze použít pro OS Linux. Na základě informací z hostovaných OS je dynamicky přidělována a odebírána část operační paměti virtuálním počítačům. Tato část je definována pro každý virtuální počítač na základě následujících parametrů: Spouštěcí velikost určuje velikost v MB, která slouží pro zavedení OS a zároveň odpovídá i minimální velikosti, pod kterou nemůže pamět klesnout. Minimální velikost, nezávisle na spouštěcí, lze nastavit pomocí WMI. Maximální velikost určuje velikost v MB, kterou nemůže virtuální počítač překročit (výchozí hodnota je 64GB). Vyrovnávací velikost určuje velikost v procentech, která se má navíc přidělit pro virtuální počítač jako rezerva oproti zjištěné aktuální potřebě. Například virtuální počítač požaduje 1000MB paměti (zjištěno na základě ukazatelů výkonu, které poskytuje hostovaný OS) a vyrovnávací velikost je 20 % (výchozí hodnota), celková přidělená pamět pak bude 1200MB. Váha podobně jako v případě CPU určuje prioritu v přidělování paměti. Ta je uplatňována až v okamžiku jejího nedostatku. Protože proces přidělení paměti není okamžitý (zejména zjištění potřeby další paměti), je vhodná definice parametrů nezbytným předpokladem správné funkcionality [45]. Pamět určená vyrovnávací velikostí je hostovaným operačním systémem obvykle využívaná pro různé vyrovnávací paměti (např. souborový systém) a slouží k okamžitému použití, než stihne Hyper-V zareagovat a přidělit další pamět. Zatímco zvětšování je řešeno pomocí zvláštní podpory v jádře OS, odebírání je řešeno pomocí tzv. ballooning mechanismu (časté je i označení balloon driver ). V tomto případě ovladač v jádře hostovaného systému alokuje operační pamět (pomyslné nafouknutí balónku ), kterou navrátí hypervizoru a ten jí následně může přiřadit jinému virtuálnímu počítači. V momentě, kdy má ovladač již nějakou pamět alokovanou, může její navrácení virtuálnímu počítači proběhnout jako její dealokace (pomyslné splasknutí balónku ). Jinými slovy, zatímco přidávání paměti se v hostitelském OS projevuje (alespoň z počátku) jako navyšování celkové kapacity, odebírání celkovou kapacitu nemění. Proces dynamické úpravy paměti však může způsobit komplikace pro následující chování aplikací: Alokují co nejvíce operační paměti a následně ji používají pro vlastní potřebu (například různé databázové systémy). Použití dynamické paměti pro tyto aplikace znamená, že po určité době si virtuální počítač vyžádá maximální velikost operační paměti bez ohledu na skutečnou potřebu. Alokují pamět během svého startu. Takové aplikace nemohou využít pamět, která je systému dynamicky přidávána po jejich spuštění. 30

38 3.2. PŘEHLED FUNKCIONALIT Provádějí kontrolu kapacity paměti před spuštěním (typicky různé instalátory). Například virtuální počítač má aktuálně přiřazeno 1GB a této velikosti odpovídá i celková kapacita. Maximálně je možné přidělit počítači 4GB, ale pro spuštění nějaké aplikace jsou vyžadovány 2GB. V takovém případě nelze aplikace spustit bez nějakého umělého vyvolání požadavku na přidání paměti v hostovaném OS. Jeden z poněkud krkolomných zato však osvědčených postupů, je otevření programu malování (Mspaint.exe) a nastavení velkého rozměru pro plátno (šířku a výšku obrázku). Tato operace alokuje velké množství paměti, čímž dojde k vyvolání požadavku na další pamět, a pokud je tato pamět přidělena, pak dojde i ke zvětšení celkové kapacity paměti. Následně je možné malování zavřít (čímž se uvolní pamět, která je posléze vrácena hypervizoru, ale velikost celkové paměti se již nezmění) a program je možné spustit. Stávající implementace dynamické paměti může vyžadovat dodatečnou úpravu aplikací, v opačném případě pak bude docházet k výše popsaným problémům. Parametry ovlivňující přidělování paměti nelze bohužel měnit za běhu virtuálního počítače. Jinými slovy, přidání konkrétní velikosti operační paměti za běhu virtuálního počítače je ve stávající verzi nerealizovatelné. Použití dynamické paměti může být v některých, na první pohled ideálních, případech diskutabilní. Například u hostingových společnosti je ustálen model placení za pevně danou kapacitu operační paměti, a nikoliv za právě přidělenou pamět v čase. Z teoretického hlediska by byla změna výhodná pro obě strany (zákazník zaplatí o něco méně a hostingová společnost může zvýšit využití fyzického počítače). Nelze však plně zaručit, že v případě náhlého výkyvu zátěže bude dostatek paměti pro všechny virtuální počítače. A nelze zaručit ani dostatečně rychlé přidělování paměti v závislosti na právě provozované aplikaci Virtuální sítě Virtuální sítě v prostředí Hyper-V jsou tvořeny pomocí virtuálních přepínačů operujících na druhé vrstvě referenčního ISO/OSI modelu. K těmto virtuálním přepínačům je možné připojit virtuální počítače pomocí virtuálních sít ových adaptérů. Samotné virtuální přepínače však mezi sebou nelze v Hyper-V přímo propojovat, takové propojení by muselo být realizováno externě. V rámci Hyper-V se rozlišují 3 druhy virtuálních sítí: Privátní umožňuje komunikaci pouze mezi připojenými virtuálními počítači (hostitelský počítač nelze do této sítě připojit). Interní podobně jako privátní umožňuje komunikaci mezi připojenými virtuálními počítači, ale zároveň je do této sítě připojen i hostitelský počítač. Externí na rozdíl od přechozích dvou přístupů, je externí sít přímo navázána na právě jeden fyzický sít ový adaptér (NIC Network Interface Card). Do této sítě 31

39 3.2. PŘEHLED FUNKCIONALIT je možné připojit i hostitelský počítač, a umožnit tak sdílení fyzického adaptéru. Pokud je sít vyhrazena pouze pro provoz virtuálních počítačů (bez hostitelského počítače), lze se setkat s označením dedikovaná externí sít. Zapojení virtuálních sítí je ilustrováno na obrázcích 3.5 a 3.6. V hostitelském systému je externí sít reprezentována tak, že z fyzického adaptéru, na který je tato sít navázána, jsou odebrány všechny konfigurační vlastnosti (nastavení IPv4, IPv6, sdílení souborů a tiskáren a další). A je přidána jediná konfigurační vlastnost s názvem Virtual Network Switch Protocol. Je-li tento adaptér zároveň jediným fyzickým adaptérem ve fyzickém počítači, znamená to, že hostitelský systém po dokončení operace ztratí možnost komunikovat pomocí tohoto adaptéru. Pokud je externí sít sdílena i s hostitelským OS, dochází zároveň k vytvoření nového virtuálního adaptéru v hostitelském počítači, který zdědí původní konfigurační vlastnosti fyzického adaptéru (nastavení IPv4, IPv6, sdílení souborů a tiskáren a další), a umožní tak hostiteli připojení do fyzické sítě. Obrázek 3.5: Dvě varianty připojení virtuální externí sítě. Na levé straně není externí virtuální sít (fyzický adaptér) sdílena s hostitelským systémem, zatímco na pravé ano. [4] VLAN (802.1Q) v Hyper-V prostředí Pro řízení komunikace mezi virtuálními a fyzickými počítači je možné využívat i známou technologii VLAN (802.1Q). Za předpokladu, že fyzická infrastruktura podporuje použití VLAN, lze VLAN identifikátor (ID) definovat na několika různých místech v systému: V Parent Partition na fyzickém adaptéru, který je navázaný na virtuální externí sít všechna data odeslaná tímto adaptérem (tedy i z Child Partition) jsou označena příslušným VLAN ID, příchozí data jsou přijata, odpovídají-li definovanému VLAN 32

40 3.2. PŘEHLED FUNKCIONALIT Obrázek 3.6: Zapojení interní a privátní sítě. Interní sít je sdílena s hostitelským systémem, zatímco privátní nikoliv [4] ID. Nutno podotknout, že toto chování se může lišit v závislosti na výrobci, použité verzi ovladačů a nastavení sít ového adaptéru. Proto není tato varianta příliš používána. V Parent Partition na virtuálním adaptéru, který je navázaný na virtuální externí sít obdobně jako v předchozím případě pouze s rozdílem, že nebudou ovlivněny Child Partition připojené do stejné externí sítě. Tato volba se nejčastěji používá v případě, že má hostitelský počítač jen jeden fyzický adaptér, který musí sdílet s virtuálními počítači. Aby nemohly virtuální počítače přistupovat k hostiteli (typicky z bezpečnostních důvodů), je nutné použít odlišný VLAN pro Parent Partition. V Child Partition na virtuálním adaptéru, který je navázaný na virtuální externí nebo interní sít pomocí grafického rozhraní lze definovat pouze jeden VLAN ID na každý virtuální adaptér. Virtuální počítač tak může být připojen nevýše do 12 VLAN sítí (8 syntetických + 4 emulované adaptéry). Pomocí WMI (jeden z mechanismů pro přístup a sdílení informací pro správu Windows) lze upravit konfiguraci virtuálního adaptérů tak, aby přijímal data z více než jedné VLAN. Konfigurace (čehokoliv) přímo pomocí WMI bohužel není z uživatelského pohledu příliš přívětivá. Na obrázku 3.7 je ilustrována konfigurace VLAN v Hyper-V prostředí. Každý virtuální počítač, včetně hostitelského (Parent Partition), má virtuální adaptér přidělen v nějaké VLAN síti. Žádný z virtuálních počítačů nemůže přímo komunikovat s hostitelským počítačem, 33

41 3.2. PŘEHLED FUNKCIONALIT zatímco mezi sebou ve dvojicích 1+3 a 2+4 ano. Všechny VLAN sítě jsou následně zpřístupněny na fyzickém adaptéru. Obrázek 3.7: Konfigurace VLAN v prostředí Hyper-V. Přímo spolu mohou komunikovat jen stroje ve dvojicích 1+3 a 2+4 (za předpokladu, že dále na fyzické síti nedochází ke spojení VLAN 5 a VLAN 3). Ve výchozí konfiguraci jsou všechny VLAN ID z virtuální externí sítě zpřístupněny na fyzickém adaptéru jako součást 802.1Q trunk. Výchozí chování lze upravit tak, aby trunk obsahoval jen vybrané VLAN ID, změnu však nelze provést jinak než pomocí úpravy registrů, WMI nebo SCVMM (nástroj pro správu virtualizačního prostředí). Z virtuálního počítače nelze přidělené VLAN ID adaptéru změnit, lze jej tedy používat pro izolaci virtuálních počítačů na virtuální síti. Potenciální problémy však hrozí, pokud je tato možnost zpřístupněna přímo koncovým uživatelům virtuálních počítačů (např. pomocí webového rozhraní pro správu). Obvykle se proto tato úroveň konfigurace běžným uživatelům nezpřístupňuje, anebo je omezena jen na vyhrazenou virtuální privátní sít, kde nemůže ovlivnit další uživatele systému. Použití VLAN může být z pohledu správy systému vhodnější varianta než vytvoření velkého množství samostatných virtuálních sítí. Uvažme například situaci, kdy je na jednom serveru provozováno 200 virtuálních počítačů, které mají být po 2 členných skupinkách propojené izolovanou sítí. Jedna z možností je vytvořit 100 virtuálních privátních sítí a do každé z nich připojit tyto 2 počítače takové řešení však spotřebuje (minimálně) 100MB operační paměti hostitelského systému (1 virtuální sít alokuje ve výchozím nastavení 1MB 34

42 3.2. PŘEHLED FUNKCIONALIT pro vyrovnávací pamět [14]) a grafické konfigurační nástroje budou zaplněné množstvím virtuálních sítí. Druhá možnost spočívá ve vytvoření jediné privátní sítě a přidělené vlastní VLAN každým 2 počítačům. Tato jediná virtuální sít se však může stát úzkým hrdlem a zpomalovat komunikaci mezi počítači, přidání dalších virtuálních sítí by v takovém případě bylo nevyhnutelné Přidělování MAC adres Ve výchozí konfiguraci je každému virtuálnímu adaptéru (a také virtuálnímu přepínači) dynamicky přidělena MAC adresa při jeho první inicializaci (spuštění virtuálního počítače). Jakmile je tímto způsobem MAC adresa adaptéru přidělena, zůstává neměnná až na případy vyjmenované dále. Hyper-V přiděluje dynamické MAC adresy z rozsahu, který je vygenerován při instalaci role Hyper-V do hostitelského systému. Rozsah začíná vždy hodnotou D, dalších 16bitů MAC adresy je získáno z posledních 16 bitů IP adresy prvního adaptéru v hostitelském systému. Například je-li IP adresa prvního adaptéru hostitele , pak poslední dva oktety ( ) odpovídají v hexadecimálním zápisu 1E-28 a celý rozsah pak vypadá následovně: D-1E až D-1E-28-FF. Neboli 256 použitelných MAC adres. Rozsah lze však definovat i manuálně. Je-li však ponechána výchozí konfigurace a hostitelský počítač je bez dalších úprav klonován (zkopírování OS na další počítače), budou na těchto hostitelích vznikat virtuální počítače s duplicitními MAC adresami. Hyper-V umí ošetřit pouze situaci, kdy jsou duplicitní MAC adresy v rámci jednoho hostitelského systému. Klonování hostitelského systému je podporováno pouze za předpokladu použití nástroje SysPrep, v takovém případě dojde k regeneraci rozsahu, ze kterého jsou dynamické MAC adresy přidělovány. Hyper-V si udržuje informaci o dynamicky přidělených MAC adresách a při požadavku na přidělení nové použije první neobsazenou (prochází seznam od nejnižší adresy). MAC adresa je změněna (vygenerována nová), pokud nastane jedna z následujících situací [12]: Je spouštěn virtuální počítač a jeho virtuální adaptér má aktivované dynamické přidělování MAC adres, ale uvedená adresa neodpovídá rozsahu hostitelského počítače, ze kterého jsou MAC adresy přidělovány (může nastat, pokud je počítač přenesen z jednoho hostitele na druhý). Je spouštěn virtuální počítač a jeho virtuální adaptér má aktivované dynamické přidělování MAC adres, ale uvedenou adresu již používá jiný virtuální počítač. Pokud je virtuální počítač spouštěn z uloženého stavu (Save) nikoliv tedy z vypnutého a nastane jedna z výše uvedených situací, nebude virtuální adaptér připojen do žádné virtuální sítě do doby, než bude restartován, jinými slovy, ztratí možnost komunikace pomocí tohoto adaptéru. Hyper-V v tomto případě neumožňuje změnu MAC adresy virtuálního adaptéru, pokud je virtuální počítač zapnutý (nebo v uloženém stavu). Alternativou je manuální definice tzv. statické MAC adresy pro virtuální sít ový adaptér, kterou Hyper-V za žádných okolností nemění. 35

43 3.2. PŘEHLED FUNKCIONALIT Podvržení MAC adresy Ve výchozí konfiguraci virtuálního přepínače je zajištěno, že virtuální adaptér v Child Partition může odesílat pouze pakety se zdrojovou MAC adresou, která odpovídá přiřazené hodnotě [19]. Stejně tak příjem dat je povolen pouze, pokud cílová (příchozí) MAC adresa koresponduje s nastavením virtuálního adaptéru. Důsledkem je, že OS virtuálního počítače nemůže změnit MAC adresu virtuálního adaptéru, resp. změnit ji může, ale tato změna bude virtuálním přepínačem ignorována. Požadavek na změnu MAC adresy z OS virtuálního počítače nebo definování více MAC adres pro jeden adaptér může být ale legitimní, například mechanismus použitý ve Windows pro rozložení zátěže (NLB). Proto lze pro jednotlivé virtuální počítače povolit volbu Enable spoofing of MAC adresses, která umožňuje odesílání a příjem paketů s libovolnou MAC adresou. Zároveň tato volba mění způsob, jakým virtuální přepínač nakládá s pakety s neznámou MAC adresou. Za normálních okolností jsou virtuálnímu přepínači dopředu známy všechny MAC adresy připojených virtuálních adaptérů, a proto nemusí zaplavovat všechny porty (virtuální adaptéry), ale nejvýše jeden (pokud se jedná o virtuální externí sít ). Jinými slovy, na rozdíl od fyzického protějšku proces učení MAC adres virtuálních adaptérů neprobíhá z analýzy provozu, ale z načtení informací o virtuálních adaptérech (které jsou uloženy v konfiguračním souboru každého virtuálního počítače). Pokud je však povolena výše zmíněná volba pro nějaký virtuální adaptér, chování virtuálního přepínače se pro porty s touto volbou mění, a odpovídá více běžnému chování přepínače z fyzického světa. Proces učení MAC adres probíhá na základě analýzy provozu a pakety s neznámou cílovou MAC adresou jsou zaplavovány na všechny porty virtuálního přepínače, které mají volbu Enable spoofing of MAC adresses povolenou. Virtuální adaptéry, které tuto volbu povolenu nemají, však zaplavovány nejsou a ani nelze virtuální přepínač přeučit jejich MAC adresu na jiný adaptér. Dochází tak v podstatě k rozdělení virtuálních adaptérů do dvou skupin, přičemž ty ve výchozí skupině (kdy je volba vypnutá) jsou na tom z pohledu možného podvržení MAC adresy bezpečněji. Chování virtuálního adaptéru v Parent Partition je odlišné. MAC adresa tohoto adaptéru je vždy v předstihu načtena do paměti virtuálního přepínače (a nelze ji tedy ve virtuálním přepínači přepsat), ale zároveň je umožněn příjem a odesílání dat s libovolnou MAC adresou (a s tím spojené zaplavování v případě neznámé MAC adresy ze strany virtuálního přepínače) Podvržení odpovědi ARP/ND (ARP/ND Spoofing) Pomocí WMI lze pro každý virtuální adaptér definovat IP adresy, které může adaptér prezentovat ostatním zařízením v síti pomocí protokolu ARP a ND. Definice těchto IP adres je manuální, statická a především svázána s konkrétním virtuálním přepínačem. Pokud je tedy virtuální počítač přemístěn na jiného hostitele nebo virtuální adaptér připojen do jiné virtuální sítě, je nutné provést nastavení znovu. 36

44 Spojení fyzických NIC do týmu (NIC Teaming) 3.2. PŘEHLED FUNKCIONALIT Lze očekávat, že ve virtuálním prostředí bude jeden fyzický adaptér (virtuální externí sít ) sdílen více virtuálními počítači. To ale není příliš robustní řešení z pohledu možného výpadku. Za předpokladu, že virtuální počítače mají jen jediný virtuální adaptér připojený do externí sítě, může selhání příslušného fyzického adaptéru (či spoje obecně) způsobit ztrátu komunikace všem virtuální počítačům. Nabízí se triviální řešení v podobě přidání dalšího fyzického adaptéru/spoje a přidání druhých virtuálních adaptérů všem virtuálním počítačům. Takové řešení ale může přinést nové problémy. Uvažme například následující situaci: dva virtuální adaptéry nějakého aplikačního serveru mají každý přiřazenou unikátní IP adresu. Za předpokladu, že je aplikace schopna naslouchat na obou adaptérech, se klient pokusí využít služeb serveru. Typicky nejprve přeloží DNS název, v tomto případě obdrží 2 IP adresy, jednu z nich vybere a začne se serverem komunikovat. Vše je v pořádku až do chvíle, kdy na straně serveru dojde k výpadku spoje, který obsluhoval tohoto klienta. Pokud klientská část aplikace nemá vnitřní logiku, která by se pokusila využít druhou IP adresu, bude se z pohledu klienta jevit server jako nedostupný. Popisovaný příklad přitom není nijak nereálný, takto by například vypadala reakce většiny internetových prohlížečů na platformě Windows. Jiné mnohem pohodlnější řešení spočívá ve spojení fyzických sít ových adaptérů do jednoho logického celku, označovaného jako tým. Tým se může skládat z několika fyzických sít ových adaptérů, které se z pohledu OS jeví jako jeden jediný. Na rozdíl od jiných OS však nemá Windows pro vytváření týmu nativní podporu a vše je řešeno v režii výrobce sít ového adaptéru. Proto se liší nejen konkrétní postupy vytváření týmu, ale i možnostmi, které nabízejí. Spojením adaptéru do týmu se primárně sledují dva cíle, zajištění vysoké dostupnosti a zvýšení přenosové kapacity (resp. rozložení zátěže na více adaptérů). V prvním případě postačuje, pokud data přenáší jen jeden adaptér z týmu a ostatní jsou redundantní (pasivní). Dojde-li k výpadku spoje, jeho roli převezme další člen týmu, který se stane aktivním. V druhém případě se obvykle očekává, že všechny fyzické adaptéry v týmu jsou aktivní a využívány pro přenos dat. Běžně používané metody pro spojení adaptéru do týmu, které jsou funkční pro jeden fyzický počítač, však nemusí správně fungovat pro virtuální prostředí. Pro ilustraci je na obrázku 3.8 zobrazena běžná konfigurace sítě. Všechny zobrazené počítače jsou připojeny do jednoho fyzického přepínače. Každý ze dvou klientských počítačů má jeden sít ový adaptér s MAC adresou MAC1, respektive MAC2. Fyzický počítač má dva fyzické adaptéry s MAC adresami MAC3 a MAC4, které jsou spojené do týmu (LBFO Load Balancing and Failover). V Hyper-V prostředí je vytvořena virtuální externí sít, která v Parent Parition vytváří virtuální adaptér s MAC adresou jednoho z fyzických adaptérů, v tomto případě s MAC3. Dále jsou do virtuální externí sítě připojené dva virtuální počítače, každý s jedním adaptérem a MAC adresami MAC5 a MAC6. Komunikaci uvnitř virtuální externí sítě zajišt uje virtuální přepínač, ovladač fyzické sít ové karty pro vytvoření týmu ji proto neovlivňuje. Veškerá komunikace mezi klienty a Hyper-V prostředím však skrze tento ovladač projít musí. Bez virtualizace implementuje ovladač běžně spojení počítač + 37

45 3.2. PŘEHLED FUNKCIONALIT přepínač, nyní je však situace přepínač + přepínač a to přináší některé komplikace. Obrázek 3.8: Použité MAC adresy během komunikace pomocí fyzického adaptéru v týmu [7] Pokud je metoda pro vytvoření týmu založena na IEEE 802.3ad (Link Aggregation), funguje vše očekávaným způsobem, je však vyžadována podpora od fyzického přepínače. Existují metody, které nevyžadují podporu od fyzického přepínače a mohou bezproblémově fungovat s Hyper-V. Aby bylo patrné, jaké problémy mohou nastat, popisuje následující příklad metodu, která fungovat nebude. Odeslání dat přes týmový adaptér způsobí modifikaci zdrojové MAC adresy každého paketu tak, aby odpovídal konkrétnímu fyzickému adaptéru z týmu, který ji přenáší. Tedy odchozí pakety virtuálních počítačů budou mít zdrojovou adresu nastavenou na MAC3 nebo MAC4 podle fyzického adaptéru, který data přenese, a nikoliv podle své vlastní tj. MAC5 nebo MAC6. Cílová MAC adresa zůstává zachována. Fyzický přepínač operující na druhé vrstvě ISO/OSI modelu se do styku s MAC adresami virtuálních počítačů (MAC5, MAC6) nedostane. Takto odeslaná data v pořádku dorazí ke klientským počítačům, ale obrácený směr komunikace nebude fungovat nejlépe. Virtuální počítače totiž budou pomocí ARP oznamovat svoji skutečnou MAC adresu, tedy MAC5 a MAC6 a tu si zároveň do své vyrovnávací paměti uloží klientské počítače. Fyzický přepínač však o těchto MAC adresách neví, a musí proto odesílat data pro tyto příjemce na všechny porty kromě příchozího. A to je zjevně nevhodné řešení nejen z bezpečnostního, ale i výkonového hlediska. Jak již bylo v úvodu této části zmíněno, každý výrobce si řeší metody pro spojení adaptérů do týmu dle vlastního uvážení a není tedy divu, že nemají ani stejné označení, natož pak 38

46 3.2. PŘEHLED FUNKCIONALIT stejnou funkcionalitu. Některé metody pro zvýšení propustnosti fungují jen v určitých případech (např. pro IPv4 protokol) a mají další omezení (např. požadavek na připojení všech spojů do jednoho přepínače, všechny adaptéry musí být stejného typu a připojené stejnou rychlostí, dodatečné postupy pro vytváření VLAN, omezení offloading technologií atd.). Někteří výrobci mají dokonce metody určené výhradně pro Hyper-V (Intel Virtual Machine Load Balancing). Další podrobnosti lze obvykle nalézt v dokumentaci k nejnovějším verzím ovladačů. Dovolím si poznamenat, že pokud fyzický přepínač a adaptér podporuje IEEE 802.3ad, jedná se zpravidla o nejlepší variantu. Pozoruhodný je i způsob, jakým Microsoft poskytuje technickou podporu, pokud systém používá libovolnou formu NIC týmu. Shledá-li operátor podpory, že problém může způsobovat spojení NIC do týmu, požádá o jeho kompletní zrušení a pokud to problém vyřeší, je to problém na straně výrobce. Zákazník je odkázán na technickou podporu výrobce sít ové karty. Z ryze subjektivní zkušenosti mohu podoktnout, že pokud se jedná o serverovou variantu sít ové karty, je reakce výrobců (Broadcom, Intel, HP) veskrze kladná a rychlá, v opačném případě však nelze počítat s řešením dříve než v řádu měsíců Zajištění vysoké dostupnosti virtuálních počítačů (Failover Hyper-V cluster) Virtuální počítače lze nakonfigurovat pro provoz v clusteru pro zajištění vysoké dostupnosti. Vysokou dostupností se zde rozumí ochrana proti výpadku v případě plánovaných i neplánovaných odstávek fyzického počítače. Mezi plánované odstávky patří například instalace aktualizací OS (a následné restartování), výměna HW, přemístění fyzického počítače do jiné lokality atd. Neplánované odstávky jsou pak projevem závad hardwarového vybavení, přírodních katastrof, výpadku napájení atd. Je důležité upozornit na fakt, že vysokou dostupnost nelze zajistit jen za použití clusteru, ale zpravidla se vyžaduje použití redundantních komponent v celém řešení (klimatizace, komunikační trasy, sít ové prvky, nezávislé zdroje napájení atd.). Cluster se skládá z 2 až 16 fyzických počítačů, které sdílejí alespoň jedno datové úložiště a jsou vzájemně propojeny komunikační sítí. Jednotkou pro zajištění vysoké dostupnosti je virtuální počítač. Neplánovaný výpadek nějakého uzlu clusteru způsobí ve výchozí konfiguraci automatické restartování postižených virtuálních počítačů na zbývajících funkčních uzlech. Plánovaný výpadek lze vyřešit přemístěním (migrací) virtuálních počítačů za běhu bez pozorovatelného výpadku. Selhání aplikace uvnitř virtuálního počítače však žádnou akci z pohledu clusteru nevyvolá. Ochrana před takovým selháním by vyžadovala vytvoření aplikačního clusteru v rámci virtuálních počítačů, viz obrázek 3.9. Při takovém nastavení je nutné použít patřičné metody, diskutované např. v následujícím článku [16], které zajistí, aby na jednom uzlu nebyly zároveň umístěny všechny virtuální počítače tvořící jeden aplikační cluster (selhání takového fyzického počítače by způsobilo kompletní výpadek aplikace). Jakmile je vytvořen cluster pro Hyper-V, je používání obvyklého nástroje pro správu Hyper-V (Hyper-V Manager) namísto nástroje pro správu clusteru nepraktické. Klasický nástroj pro správu Hyper-V prostředí totiž nemá o existenci clusteru povědomí a zejména 39

47 3.2. PŘEHLED FUNKCIONALIT Obrázek 3.9: 2 aplikační clustery provozované na 4 virtuálních počítačích uvnitř dvou fyzických hostitelů spojených do Hyper-V clusteru [4] nezajišt uje replikaci provedených změn na všechny uzly clusteru. Což se pak projevuje jako ztráta nastavení při přemístění virtuálního počítače na jiný uzel. V clusteru lze provozovat nejvýše 1000 virtuálních počítačů, přičemž nelze umístit více než 384 virtuálních počítačů na jeden uzel Konfigurace sdíleného úložiště Aby bylo možné počítače v rámci clusteru přemíst ovat (a tedy i spustit na jiném uzlu v případě selhání), musí mít všechny cílové uzly přístup do společného úložiště, kde jsou umístěny soubory, které tvoří virtuální počítač. Hyper-V nabízí tři přístupy jak jej zajistit. Přičemž uvedené přístupy lze podle potřeby kombinovat (doporučuji však používat jen jeden pro všechny virtuální disky jednoho virtuálního počítače). Prvním z nich je umístění všech virtuálních počítačů na jednu logickou jednotku tzv. LUN (Logical Unit Number v terminologii SCSI adresovatelná entita (zařízení), část disku, celé diskové pole, nebo část diskového pole). Používaný souborový systém ve Windows (NTFS) ale neumožňuje souběžný přístup více uzlů na jednu LUN, a k souborům tvořícím virtuální počítače tak může přistupovat vždy jen jeden uzel. Proto lze provozovat všechny virtuální počítače umístěné na společné LUN jen na jediném uzlu clusteru [26]. V této konfiguraci vyžaduje přemístění jednoho virtuálního počítače na jiný uzel zkopírovaní/přemístění příslušných souborů na odlišnou LUN. Přemístění všech počítačů v rámci jedné LUN je možné realizovat maskováním LUN. Druhým způsobem je umístění každého virtuálního počítače do samostatné LUN. Přemístění jednoho i více virtuálních počítačů lze realizovat maskováním LUN. Tento přístup má ale několik zásadních nevýhod: Klasické úložné systémy alokují pro každou LUN diskový prostor. Je tedy nutné předem správně odhadnout její velikost (zmenšení není bez ztráty dat obvykle 40

48 3.2. PŘEHLED FUNKCIONALIT možné). V rámci takto vytvořené LUN je používání virtuálních dynamických disků z hlediska úspory diskového prostoru zbytečné prostor je již pevně vyhrazen a lze do něj umístit jen jeden virtuální počítač. Pro každý virtuální počítač je třeba vytvořit LUN. To se však neděje automaticky a zautomatizování celého procesu vyžaduje použití dalších nástrojů (skriptů). Dodávané nástroje pro správu takovou funkcionalitou bez dalších úprav nedisponují. Podobně i smazání virtuálního počítače pomocí integrovaných nástrojů pro správu neznamená odstranění LUN. Ta musí být smazána externím nástrojem. Počet vytvořených LUN v úložném systému může být omezen (např. i z licenčních důvodů). Podobně je zde i limitace samotného OS Windows, která činí 256 LUN na jeden cíl. Rychlost migrace (maskovaní LUN) může být pomalá (záleží na konkrétním úložišti). Konečně třetím způsobem je využití filtru (jakési nadstavby) souborového systému NTFS označovaného jako CSV (Cluster Shared Volume) a všechny virtuální počítače umístit na jednu LUN. CSV implementuje hybridní přístup ke sdílení LUN, ve kterém je jeden z uzlů clusteru jeho vlastníkem, který koordinuje přístup ostatních uzlů k jednotlivým souborům. Koordinující uzel může přímo přistupovat ke všem metadatům (adresářová struktura) LUN. Jinými slovy, všechny uzly mohou přímo přistupovat k souborům na svazku, zatímco určité operace, jako je například vytváření, mazání či změna velikosti souboru, jsou přes sít přesměrovány na uzel vlastnící CSV. V případě selhání koordinujícího uzlu se stane vlastníkem CSV jiný uzel v clusteru a všechny operace pokračují i nadále. Svazky v CSV jsou prezentovány všem uzlům jako adresáře konzistentním způsobem. Ve výchozím nastavení jsou umístěny v %SYSTEMDRIVE%\ClusterStorage\Volume<N>, kde N je číslo od 1 a označuje pořadí LUN v nastavení clusteru. Jednotné pojmenování je důležité proto, že v konfiguračních souborech virtuálních počítačů jsou používány i absolutní cesty k souborům. V případě přemístění na jiný uzel clusteru musí být cesty zachovány, nebo by je bylo nutné aktualizovat jiným způsobem. Proto je nezbytné, aby všechny uzly měly stejné písmeno systémové jednotky (tedy i proměnné %SYSTEMDRIVE%), tj. ve výchozím nastavení C:. Možnost přesměrování diskových operací je jednou z klíčových vlastností CSV, která však s sebou přináší i komplikace. K přesměrování IO požadavků totiž dochází i v případě výpadku konektivity fyzického počítače se sdíleným úložištěm, viz obrázek To je jistě dobrá vlastnost, protože zajišt uje dodatečnou ochranu před selháním. Samotné přesměrování je pak realizováno SMB protokolem (používá sdílení souborů a tiskáren). Rychlost přesměrování ovlivňuje primárně kapacita spoje komunikační sítě. Komplikace spočívají v tom, že k přesměrování dochází i v dalších případech, konkrétně [30]: Manuální aktivace uživatelem. 41

49 3.2. PŘEHLED FUNKCIONALIT Zálohování CSV svazku (tedy souborů, které tvoří virtuální počítač, nikoliv zálohování uvnitř virtuálního počítače). Nekompatibilní filtr s CSV (NTFS filtry běžně využívají i další aplikace, například různé antivirové systémy). Obrázek 3.10: Přesměrování I/O požadavků uzlu s CSV po selhání všech (jeho) spojů se sdíleným úložištěm K bezpečnému zálohování (takovému, které zachovává konzistenci dat z pohledu aplikace) je ve Windows používán mechanismus stínované kopie svazku, který ale funguje jenom v případě, že je OS schopen monitorovat všechny přístupy k diskovému svazku. V případě CSV však žádný z uzlů nezachytává data, která jsou modifikována na svazku jiným uzlem. Aby bylo možné využít tento mechanismus, musí být všechny IO požadavky pro CSV svazek přesměrovány po celou dobu provádění zálohy (tj. vytvoření stínované kopie a zkopírovaní souborů) přes jeden uzel, který bude provádět stínovanou kopii CSV svazku. Záleží pak na parametrech sítě určené pro provoz CSV, zda se přesměrování negativně projeví na výkonu virtuálních počítačů či nikoliv. Důležitou roli zde hraje počet virtuálních počítačů, potažmo doba potřebná pro jejich zálohování. Snadno totiž může dojít k situaci, že systém nebude dělat nic jiného, než zálohovat virtuální počítače a přesměrování IO požadavků (tedy potencionálně i nižší výkon) bude neustále aktivní. K tomu přispívá i zajímavá vlastnost CSV, která v případě výskytu chyby během vytváření zálohy pomocí stínované 42

50 3.2. PŘEHLED FUNKCIONALIT kopie svazku ponechá CSV v přesměrovaném režimu do doby, než bude manuálně přepnut zpět do přímého přístupu. Jednou z metod, jak toto omezení obejít, je použití hardwarové podpory namísto softwarového řešení stínované kopie svazku. Mechanismus je veskrze podobný tomu softwarovému (přesná implementace záleží na výrobci HW) s tím rozdílem, že je obvykle rychlejší a zároveň i dražší (často licencováno jako dodatečná funkcionalita). Ačkoliv k přesměrování IO požadavků dojde i v tomto případě, rozdíl je v tom, že přesměrování bude aktivní jen po dobu vytváření stínované kopie v HW, což je výrazně kratší, než doba potřebná pro následné zkopírovaní. Alternativou je použití jiného souborového systému, například Virsto One či Sanbolic Melio FS, které ale mohou do systému přinést zase jiné komplikace. Jinou metodou je vypnutí (či přepnutí do uloženého stavu) virtuálních počítačů a jejich zkopírování. Nejpoužívanější způsob je však mnohem jednodušší: nepoužívat zálohování v rámci hostitelského počítače, ale pouze klasické v rámci hostovaných systémů. Jen je potřeba vhodně rozvrhnout časový plán, nebot by mohlo docházet k nadměrnému zatížení sdíleného úložiště, pokud by se zálohování spouštělo na všech virtuálních počítačích současně. Další vlastností CSV je nutnost povolení staršího autentizačního protokolu NTLM mezi všemi uzly v clusteru. Ačkoliv je často z bezpečnostních důvodů používání NTLM v sítích Windows nahrazeno pomocí protokolu NLTMv2 nebo Kerberos, je v tomto případě nutné učinit výjimku. Důsledkem toho je i důležité omezení pro provoz doménových řadičů (DC Domain Controller) Active Directory umístěných na CSV. K CSV nelze bez existence autentizačních služeb poskytovaných DC přistupovat. V případě, že jsou umístěny všechny DC jako virtuální počítače v clusteru, nastává jejich vypnutím nepříjemná situace. Pro přístup k CSV je totiž vyžadována autentizace pomocí DC, který se ale nachází na CSV a nelze ho tudíž spustit. Proto je doporučováno neumíst ovat všechny DC do virtuálního prostředí v clusteru. Pokud je však alespoň jeden DC umístěn na klasickém svazku, je možné i přes to cluster zprovoznit. Idea postupu je následující; nejprve je nutné přihlásit se na nějaký uzel pomocí přihlašovacích údajů ve vyrovnávací paměti (cached credentials) nebo lokálního účtu, následně spustit clusterovou službu (pokud má cluster více než 2 uzly použít přepínač /forcequorum) a spustit doménový řadič. Následně stačí jen restartovat clusterovou službu na všech zbývajících uzlech. Na závěr této části několik upozornění; nástroje používané pro vytváření nových virtuálních počítačů by měly pro vytváření příslušných souborů využívat výhradně uzel vlastnící dané CSV. V jiném případě bude docházet k přesměrování IO požadavků. Monitorování IO přesměrování je důležitým prvkem správy clusterového prostředí. CSV je vyhrazen výhradně pro použití s Hyper-V, Microsoft neposkytuje technickou podporu, pokud jsou v rámci CSV svazku ukládány jiné soubory než ty používané v Hyper-V. Zároveň je doporučeno použít vyhrazenou sít s dostatečnou kapacitou pro CSV komunikaci a přesměrování IO požadavků, ke kterým bude během provozu určitě docházet. 43

51 Přemístění (migrace) virtuálního počítače za běhu 3.2. PŘEHLED FUNKCIONALIT V prostředí clusteru je možné přemíst ovat virtuální počítače za běhu z uzlu na uzel (označováno jako Live Migration ). Technika přemístění je založena na principu zkopírování konfigurace, obsahu operační paměti a stavu zařízení a předání přístupu k VHD či jiným diskům. Není vyžadována podpora ze strany virtuálního počítače (přemístění přistupuje k virtuálnímu počítači jako k černé skříňce). Proces přenesení obsahu paměti prochází přes všechny stránky operační paměti a každá zkopírovaná stránka je označena příznakem, který je odstraněn v případě její změny. Tím se vytváří seznam tzv. špinavých/změněných stránek, které je nutné přenést znovu. Jakmile jsou všechny stránky přeneseny nebo je proces přenesení v páté iteraci (aplikace uvnitř virtuálního počítače může výrazně využívat pamět a než jsou všechny stránky přenesené, jsou vždy nějaké další modifikovány), dojde k pozastavení virtuálního počítače, přenesení nezkopírovaných stránek a přenesení stavu zařízení. Následně si cílový uzel převezme VHD a další soubory tvořící virtuální počítač (použitá metoda je v závislosti na konfiguraci úložiště) a pak jeho provoz obnoví na cílovém uzlu. Rychlost přemístění závisí na: Velikosti operační paměti virtuálního počítače. Frekvenci změn operační paměti virtuálního počítače. Parametrech sítě použité pro přenos. Konfiguraci přístupu ke sdílenému úložišti(typicky je LUN masking pomalejší než změna v CSV). Obvykle ale ani k výpadku virtuálního počítače z pohledu uživatele nedojde, protože je závěrečná fáze migrace (pozastavení počítače na původním uzlu a obnovení na druhém) dokončena dříve, než vyprší časový limit (timeout) TCP připojení v běžné LAN síti. Protože bude cílový uzel clusteru připojen do jiného portu fyzického přepínače, než byl zdrojový uzel, musí dojít k aktualizaci informací o MAC adresách a příslušných portech v přepínači. Ačkoliv Hyper-V tuto aktualizaci zajišt uje, pokud není MAC adresa virtuálního počítače definovaná staticky, dochází během migrace k její změně. Takové chování může způsobit problémy zejména OS, které vážou konfiguraci adaptéru na jeho MAC adresu (např. některé distribuce Linuxu [47]). Cílový uzel musí mít k dispozici stejné sítě jako zdrojový (resp. musí mít virtuální sít, která do této sítě umožní připojení virtuálnímu počítači), v opačném případě se neobejde přemístění virtuálního počítače bez ztráty komunikace. Existence stejných sítí však ještě nezaručuje úspěch, pojmenování všech sítí (které používá migrovaný virtuální počítač) se v rámci každého uzlu musí naprosto shodovat (rozlišují se velká a malá písmena). Pokud tomu tak není, nebude po přemístění virtuálního počítače jeho virtuální adaptér připojen do žádné virtuální sítě. Dalším omezením je množství přemíst ovaných virtuálních počítačů každý uzel clusteru se může účastnit nejvýše jednoho přemístění v jeden okamžik (at už jako zdroj, nebo 44

52 3.2. PŘEHLED FUNKCIONALIT cíl), tedy v clusteru s 16 uzly může v jeden okamžik probíhat nejvýše 8 přemístění. Pro minimalizaci doby potřebné pro přemístění je vhodné vyhradit samostatnou a dostatečně rychlou sít. Například přemístění všech virtuálních počítačů nějakého uzlu, řekněme se 100GB operační paměti, by přes běžně používaný Gigabit Ethernet v teoretickém případě trvalo zhruba 13 minut. V praxi to bude ale mnohem více, protože reálná přenosová rychlost není 1Gbit/s (režie protokolů, ztráta paketů... ) a migrace každého virtuálního počítače vyžaduje dodatečný čas pro inicializaci a dokončení, kromě samotného přenosu paměti. Navíc nelze očekávat, že by byl obsah paměti u všech počítačů po celou dobu jejich migrace neměnný. Reálná doba může být proto až násobně delší. Ačkoliv lze přemístění za běhu realizovat i přes WAN sítě, doba přenosu je výrazně větší než na LAN sítích. Existují nástroje třetích stran, které se pokoušejí toto chování vylepšit, viz např. [36]. Dalším nezbytným předpokladem pro přemístění za běhu je i přístup cílového uzlu ke všem zdrojům virtuálního počítače. Zdrojem se v tomto případě rozumí jak všechny VHD disky, které virtuální počítač používá, tak přímo připojené disky nebo ISO obrazy načtené ve virtuální mechanice. Podobně je nutné, aby měl cílový uzel i dostatek systémových prostředků pro provoz virtuálního počítače. Přemístění za běhu lze s výhodou využít pro automatické rovnoměrné rozkládání zátěže mezi uzly, nebo naopak maximalizaci využití uzlů. K tomu lze využít různé monitorovací nástroje, které jsou schopny dynamicky reagovat na měnící se podmínky, např. přidání, selhání, odebrání, obnovení uzlů v clusteru, změna zátěže virtuálních počítačů (CPU, RAM, úložiště) či změna konfigurace a zatížení komunikační sítě. Drobným nedostatkem je fakt, že takové nástroje nejsou v současnosti okamžitě dostupné, resp. vyžadovaly by velkou míru úprav a ladění pro obsažení všech uvedených aspektů. V případě vypnutí či restartování některého uzlu nedochází k přemístění virtuálních počítačů, ale ke spuštění akcí definovaných pro každý virtuální počítač (akce při startu a vypnutí virtuálního počítače). Pro přemístění virtuálních počítačů na ostatní uzly v clusteru je nutné bud manuálně iniciovat migraci (jednoho virtuálního počítače po druhém, kvůli omezení na max. 1 přenos současně), nebo si vytvořit nějaký skript. Restartování může být problematické zejména při instalaci aktualizací pro jednotlivé uzly. Pokud by byly všechny uzly clusteru nastaveny na automatickou instalaci aktualizací (často spojenou s restartováním) ve stejný čas, došlo by k výpadku hostovaných virtuálních počítačů, protože by se zhruba ve stejnou chvíli všechny uzly restartovaly. Možné řešení je použití dalších nástrojů, například Virtual Machine Servicing Tool (VMST), který mimo jiné zajišt uje bezpečnou aktualizaci celého clusteru. VMST přemístí virtuální počítače z daného uzlu před zahájením instalace aktualizací a v případě úspěšné aktualizace systému pokračuje dalším uzlem, nedojde tak k situaci, kdy by se několik uzlů clusteru restartovalo, a nebyl tak dostatek volných systémových prostředků pro běh všech virtuálních počítačů. Prvotním předpokladem je fakt, že cluster musí mít dostatečnou rezervu, aby byl schopen pokrýt výpadek alespoň jednoho uzlu. 45

53 3.2. PŘEHLED FUNKCIONALIT Konfigurace sítí v clusteru Provoz Hyper-V systému v clusteru vyžaduje použití některých dalších sítí, celkové požadavky na sít ovou konfiguraci jsou shrnuty níže. Druh Účel Požadavky Úroveň přístupu Komunikace clusteru a CSV Sdílené úložiště Komunikace clusteru a CSV Správa Hyper-V Provoz virtuálních počítačů Přemístění za běhu Komunikace clusteru slouží ke konfiguraci a zjišt ování stavu jednotlivých uzlů (zda jsou funkční). CSV je nutné pro přesměrování I/O požadavků. Správa serveru a zálohování. K zajištění komunikace virtuálních počítačů s okolním prostředím. Pro přemístění virtuálních počítačů za běhu systému. Přístup k sdílenému úložišti nejčastěji pomocí Fibre Channel, iscsi či SAS technologie. Většinou malá propustnost, nízké zpoždění. V případě přesměrování I/O vysoká propustnost. Obvykle malá propustnost. Pokud je spojeno i se zálohováním, pak vysoká propustnost. Různé. Pro přemístění virtuálních počítačů za běhu systému. Tabulka 3.1: Požadavky na sítě pro provoz Hyper-V prostředí [48]. Obvykle vyhrazená sít pouze pro účely přístupu k úložišti (záleží na konkrétním typu). Obvykle vyhrazená sít, pouze uzly v clusteru. Obvykle vyhrazená sít (z důvodu zajištění izolace). Přístup pro administrátory a nástroje pro správu. Obvykle vyhrazená sít. Přístup podle požadavků virtuálních počítačů. Obvykle vyhrazená sít, pouze uzly v clusteru. Pokud by byl přesně dodržen doporučovaný postup a každé síti vyhrazen vlastní port (alespoň Gigabit Ethernet) nějakého sít ového adaptéru, bude potřeba pro fyzický počítač v clusteru minimálně 5 portů. Taková konfigurace by ale nezajistila vysokou dostupnost (přičemž by nemusela dostačovat ani propustnost), jednoduchým zdvojením se však dostáváme na 10 portů (a minimálně 2 adaptéry). Takový počet ale může být problematické umístit do menších serverů i v případě použití více portových sít ových adaptérů. Jednou z metod, jak snížit počet potřebných portů, je definování alternativních sítí pro CSV a přemístění za běhu, v případě výpadku jejich vyhrazené sítě může být použita sít pro správu serveru apod. Dále je patrné, že s velkou pravděpodobností nebudou všechny porty/sítě trvale využívány, a nabízí se tak možnost sdílení některých sítí s omezením ma- 46

54 3.3. NÁSTROJE PRO SPRÁVU, MONITOROVÁNÍ A ZÁLOHOVÁNÍ ximálního využití (např. pomocí QoS) pro danou aplikaci tak, aby byla garantována odpovídající funkcionalita. Počet sít ových portů v serveru (a tedy i kabelů, adaptérů a obsazených portů v přepínačích) je možné snížit, aniž by bylo nutné obětovat vysokou dostupnost. Pochopitelně lze zvolit i jiný přístup a na místo 1 Gigabit Ethernet používat jeho 10 Gigabit variantu. Pro tyto účely se hodí CNA (Converged Network Adapters) adaptéry, které jsou schopny přenášet jak Ethernet, tak iscsi či FCoE po stejném fyzickém médiu současně. 3.3 Nástroje pro správu, monitorování a zálohování Integrované nástroje ve Windows poskytují jen základní možnosti pro správu virtualizovaného prostředí. Správa více než jednotek hostitelských počítačů je bez použití dalších nástrojů zdlouhavá a vyžaduje nepřiměřeně úsilí, podobně v případě desítek virtuálních počítačů v rámci jednoho hostitele. Primárně jsou integrované nástroje určené pro správu jednoho hostitele/clusteru. Funkce jako konvertování fyzických počítačů do virtuálního prostředí, tvorba virtuálních počítačů na základě šablon či přístup přes webové rozhraní nejsou dostupné vůbec. Microsoft pro ovládání prostředí doporučuje několik vlastních (samostatně licencovaných) produktů rodiny System Center: Virtual Machine Manager (VMM) ovládání virtuálního prostředí. Operation Manager (OM) komplexní monitorovací nástroj. Data Protection Manager (DPM) zálohování a obnova dat V následující části jsou popsány zkušenosti z používání produktu VMM. Další dva produkty (OM a DPM) jsou natolik rozsáhlé, že by popis nastavení a doporučení pro provoz vystačil na samostatnou práci. Monitorování a zálohování je však nedílnou součástí provozu virtuálního prostředí (podobně jako fyzického), bez náležitých nástrojů je odpovídající diagnostika a řešení problémových situací prakticky nerealizovatelná. Výběr nástroje by měl vždy záviset na více parametrech než jen doporučení výrobce, zejména pro menší provozy je možné použít integrované nástroje. Pochopitelně není potřeba používat výše zmíněné nástroje vůbec a lze bezproblémově použít nástroje jiných výrobců. Ty by však měly virtuálnímu prostředí rozumět, v opačném případě musí být obsluha o to znalejší, aby správně rozpoznala chybové stavy a adekvátně reagovala. Na druhou stranu zálohování ve virtuálním prostředí ve většině případů nevyžaduje žádné podstatnější změny, protože je často realizováno uvnitř virtuálního počítače a nástroje používané ve fyzickém prostředí fungují stejně dobře i ve virtuálním. Pro zálohování CSV je však specifická podpora aplikace nezbytná. O to zajímavější je fakt, že ani nástroj vyvíjený a doporučovaný společností Microsoft DPM v aktuální verzi 2010 neumí bez dodatečných a manuálních úprav (pravidelné spouštění PowerShell skriptu, který generuje XML soubor s nastavením pro DPM [49]) správně zálohovat CSV. 47

55 3.3. NÁSTROJE PRO SPRÁVU, MONITOROVÁNÍ A ZÁLOHOVÁNÍ Virtual Machine Manager (VMM) 2008 R2 SP1 System Center Virtual Machine Manager 2008 R2 představuje řešení pro správu virtualizovaného datacentra současnosti. Umožňuje centralizovanou správu IT infrastruktury, lepší využití serverů a dynamickou optimalizaci prostředků na různých virtualizačních a fyzických platformách. [50] Takto, poněkud pompézním způsobem, je prezentován nástroj na hlavních stránkách výrobce. Mé zkušenosti s používáním ale tak optimistické nejsou. VMM se skládá z několika komponent. Tou nejdůležitější je VMM Server, který zajišt uje komunikaci všech ostatních komponent a ovládání hostitelských počítačů. VMM Server pro ukládání konfiguračních a jiných dat vyžaduje MSSQL server, přičemž zdarma dostupná verze (MSSQL Express) kromě obvyklých omezení velikosti DB neumožňuje použití dynamické optimalizace systémových prostředků (PRO Performance and Resource Optimization) a generování přehledových zpráv (reporting). Mezi další patří agent, který se instaluje do hostitelského OS a umožňuje jeho ovládání pomocí VMM a získávání informací. Pro grafické ovládání programu slouží konzole, kterou je možné nainstalovat na téměř libovolný počítač. Ukládání dodatečných dat, jako jsou například ISO obrazy CD/DVD disků, šablony virtuálních počítačů, či pomocné skripty, zajišt uje knihovna. Přičemž není knihovna nic jiného než sdílená složka na serveru. Další, ale tentokrát volitelná součást, je samoobslužný portál (Self-Service Portal), který poskytuje nejzákladnější možnosti přístupu k virtuálním počítačům přes webové rozhraní. VMM zjišt uje informace o virtuálním prostředí v periodických intervalech z hostitelských počítačů. Mají-li se proto zobrazovat v VMM aktuální informace, musí správa virtuálního prostředí probíhat výhradně jeho prostřednictvím. V opačném případě budou obsluze prezentovány chybné informace, např. velikost alokované paměti, stav virtuálního počítače atd. Jednotlivé úkoly (např. vytvoř virtuální počítače, změň konfiguraci virtuální sítě) jsou zpracovávány paralelně, což je obrovská výhoda pro ovládání stovek virtuálních počítačů současně. Bohužel však tato vlastnost působí i zásadní problémy. VMM totiž není možné škálovat do šířky (přidávat další servery), a tak všechny požadavky závisí na jednom jediném serveru. Základním předpokladem pro umístění komponenty VMM server je pochopitelně splnění systémových požadavků, pokud požadavky splněny nejsou, nelze očekávat plynulý provoz. Ačkoliv je maximální podporovaná konfigurace 400 hostitelských a 8000 virtuálních počítačů, rychlost a stabilita VMM může být ovlivněna i při jednom hostitelském systému. Zpomalení je patrné zejména při zpracovávání úkolu na stovkách virtuálních počítačů zároveň. Je však nutno podotknout, že i některé operace v grafických integrovaných nástrojích pro správu Hyper-V jsou v případě stovek virtuálních počítačů zpomalené, např. načtení informace o konfiguraci virtuálního počítače. V rámci VMM je jedním z možných řešení rozdělení hostitelů do více skupin a správa každé skupiny vlastním VMM serverem potom je však správa fakticky rozdělena na 2 nezávislé celky, což nemusí být vhodné. Jiné řešení [23] spočívá v celé řadě úprav interních vlastností VMM. Od snížení intervalů pro periodické zjišt ování informací z hostitelských počítačů, úpravou časových limitů (timeout) pro vypršení úkolu až po dobu mazání historie starých úkolů. Poslední jmenovaná úprava 48

56 3.3. NÁSTROJE PRO SPRÁVU, MONITOROVÁNÍ A ZÁLOHOVÁNÍ je v praxi naprosto nezbytnou záležitostí, protože výchozí hodnota 90 dnů znamená i při běžném používání existenci několika tisíc úkolů v historii, které činí konzoli pro ovládání téměř neovladatelnou. Tyto úpravy je nutné provádět přímou editací v registru systému. O kvalitě programového kódu VMM jistým způsobem vypovídá i počet chyb, které byly ve verzi 2008 R2 opraveny [51]. K dnešnímu dni ( ) je opraveno 20 chyb, které jsou pro jednodušší instalaci distribuovány v souhrnných balíčcích. Druhou kategorii oprav tvoří změny v samotném Hyper-V, které jsou nutné pro používání VMM. Jejich počet se liší v závislosti na verzi OS v Parent Partition. Pro WS2008R2 to jsou jen dvě, přičemž obě opravují problémy s nestabilitou WMI služby, kterou agent v rámci hostitelského systému používá pro správu Hyper-V prostředí. Existují však další problémy, které jsou považovány za vlastnost či nejsou natolik závažné a mají být opraveny až v další verzi produktu, která nese název SCVMM 2012 a je v současnosti ve stádiu veřejné beta verze. Například Hyper-V podporuje použití GPT (GUID Partition Table) disků v rámci virtuálního počítače, bohužel nástroj VMM nikoliv. Přesněji podpora je omezena jen na jeden disk typu GPT [18]. V případě porušení tohoto pravidla a přidání dalšího disku, dojde k přepnutí virtuálního počítače do nepodporovaného stavu a v rámci VMM s ním již nelze nijak pracovat (kromě smazání). To je ostatně častý stav, který provází VMM i při chybách s konfigurací virtuálních počítačů. Někdy je jediným možným řešením odebrání hostitelského počítače z VMM, čímž dojde k odstranění všech virtuálních počítačů a ztrátě všech jejich nastavení, jako jsou přístupová práva pro webový portál, označení stroje (tag) a další. Vznikly proto postupy, jak tato nastavení exportovat a ochránit je tak před smazáním a opětovnou konfigurací [25]. Jiným příkladem problému s neexistující opravou je nemožnost současně upravovat konfiguraci těch virtuálních počítačů, které používají diferenciální disky a mají společný rodičovský disk. Úpravou konfigurace se v tomto případě rozumí i obyčejné hromadné spuštění. Namísto spuštění všech počítačů však dojde ke spuštění jen několika a ostatní úkoly (po dlouhém čekání) selžou. Samotné řešení problémů spojených s VMM je navíc komplikováno nicneříkajícími chybovými zprávami, které ve většině případů na příčinu problému vůbec neukazují. Přesto je VMM často používán, jiná řešení totiž trpí podobnými problémy, nebo mají redukovanou funkcionalitu. VMM umožňuje [52]: Vyhledání kandidátů (fyzické počítače) na převod do virtuálního prostředí. Vyhledání kandidátů probíhá na základě analýzy využití systémových prostředků za určité období. Je ale nutné vzít v úvahu, že všechny aplikace v těchto systémech nemusí nutně podporovat provoz ve virtuálním prostředí. Stejně tak monitorované období nemusí být dostatečně dlouhé, např. pokud jsou systémy využívány jen nárazově. Pro účely analýzy využití je používán produkt OM, pokud není nainstalován, nelze tuto funkci použít. Tuto funkcionalitu lze však nahradit jinými nástroji pro identifikaci vhodných kandidátů, které navíc mohou pomoci s identifikováním provozovaných aplikací. Převod fyzického počítače (P2V) do virtuálního prostředí. Převod je podporován 49

57 3.3. NÁSTROJE PRO SPRÁVU, MONITOROVÁNÍ A ZÁLOHOVÁNÍ jen pro počítače s OS Windows a spočívá v kontrole použitého OS (a případném doporučení aktualizací), zkopírování obsahu fyzických disků do virtuálních, zkopírování MAC adres všech adaptérů a jejich přiřazení virtuálním adaptérům, úpravě zaváděcího procesu (nutné pro OS řady 2003) a instalaci integračních komponent. Mezi základní nedostatky však patří ignorace rozdělení fyzického disku na diskové oddíly. Namísto jednoho virtuálního disku, který by byl patřičně rozdělen, je vytvořeno tolik virtuálních disků, kolik je diskových oddílů. Zároveň je proces velmi závislý na správné konfiguraci sít ového prostředí. Mnohdy je mnohem rychlejší použít jiné nástroje, jako je například Disk2VHD, který převede disk fyzického počítače do virtuálního, a zbylé změny provést ručně. V závislosti na konkrétním typu nástroje lze s úspěchem použít i zálohovací nástroje a obnovit fyzický počítač do virtuálního prostředí. Převod z jiného virtuálního prostředí (V2V). Převod je podporován jen z některých virtuálních prostředí, přesněji z několika verzí VMware ESX a staršího nástroje pro virtualizaci z dílny Microsoft s názvem Virtual Server Pro převod z ESX je vyžadováno připojení hostitele do VMM, což je ryze manuální proces a především vyžaduje existenci nějakého nástroje pro správu VMware prostředí (VirtualCenter či vsphere), přes které VMM s hostitelem komunikuje. V případě jednotek virtuálních počítačů je proto jednodušší použít nástroje, které zkonvertují virtuální disk do VHD formátu používaného v Hyper-V. V každém případě je však nutné odinstalovat z hostovaného počítače VMware tools (obdoba integračních komponent). Doporučení vhodného hostitele při umíst ování virtuálního počítače (označováno jako Intelligent Placement). Na základě přidělených systémových prostředků virtuálnímu počítači a historických dat o jeho využívání (což vyžaduje použití produktu OM) je vyhledán vhodný hostitel s dostatečnými systémovými prostředky. Hostitel zároveň musí splňovat podmínky konfigurace virtuálního počítače, např. počítač s vysokou dostupností nelze umístit mimo cluster. Hledání vhodného hostitele lze dále ovlivnit nastavením, které určuje, zda má být preferováno rovnoměrné využití všech hostitelů, nebo maximalizace využití jednotlivých hostitelů. Dále lze upravit algoritmus definováním vlivu CPU, paměti, diskového a sít ového přístupu. Nevýhodou je bohužel fakt, že se jedná o globální definici pro všechny hostitele. Nastavení nelze vztáhnout na skupiny hostitelů. Stejně tak nelze určit priority pro umíst ování virtuálních počítačů na jednotlivé hostitele. Přemíst ování virtuálních počítačů mezi hostiteli. VMM umožňuje využít několik druhů přemístění. Kromě přemístění virtuálního počítače za běhu v rámci clusteru je to i rychlá migrace úložiště, která spočívá v zachycení stavu virtuálního počítače čímž dojde k vytvoření diferenciálního disku a zkopírování rodičovského disku do cílového umístění (což může být i nový hostitel). Jakmile je rodičovský disk přenesen, je virtuální počítač přepnut do uloženého stavu a přenesen je i diferenciální disk do cílového umístění. Výhoda je v tom, že po dobu přenosu rodi- 50

58 3.3. NÁSTROJE PRO SPRÁVU, MONITOROVÁNÍ A ZÁLOHOVÁNÍ čovského disku může virtuální počítač pokračovat v práci. Nevýhodou je vytvoření diferenciálního disku, který bude při nejbližším vypnutí počítače sloučen s rodičovským (navíc se průběh sloučení ve VMM nijak nezobrazuje) do té doby může být zpomalen výkon virtuálního počítače. Posledním druhem migrace je prosté přenesení souborů, během kterého musí být virtuální počítač vypnutý nebo v uloženém stavu. Pokud je virtuální počítač v uloženém stavu nebo existuje snapshot, neumožní VMM přenesení na hostitele s odlišným typem procesoru (nešel by spustit), výjimkou je virtuální počítač s omezením procesorových vlastností viz Přemíst ování virtuálních počítačů mezi hostiteli. VMM umožňuje využít několik druhů přemístění. Kromě přemístění virtuálního počítače za běhu v rámci clusteru je to i rychlá migrace úložiště, která spočívá v zachycení stavu virtuálního počítače čímž dojde k vytvoření diferenciálního disku a zkopírování rodičovského disku do cílového umístění (což může být i nový hostitel). Jakmile je rodičovský disk přenesen, je virtuální počítač přepnut do uloženého stavu a přenesen je i diferenciální disk do cílového umístění. Výhoda je v tom, že po dobu přenosu rodičovského disku může virtuální počítač pokračovat v práci. Nevýhodou je vytvoření diferenciálního disku, který bude při nejbližším vypnutí počítače sloučen s rodičovským (navíc se průběh sloučení ve VMM nijak nezobrazuje) do té doby může být zpomalen výkon virtuálního počítače. Posledním druhem migrace je prosté přenesení souborů, během kterého musí být virtuální počítač vypnutý nebo v uloženém stavu. Pokud je virtuální počítač v uloženém stavu nebo existuje snapshot, neumožní VMM přenesení na hostitele s odlišným typem procesoru (nešel by spustit), výjimkou je virtuální počítač s omezením procesorových vlastností viz Tvorbu virtuálních počítačů pomocí šablon. Šablona je libovolná konfigurace virtuálního počítače, která se skládá z hardwarového profilu (definuje nastavení HW) a VHD disků. Obvykle jsou šablony vytvořeny jako virtuální počítače s nainstalovaným OS, aplikacemi a patřičným nastavením, které stačí jenom zkopírovat, což značně snižuje čas potřebný pro přípravu nového virtuálního počítače. VMM podporuje vytváření šablon z existujících virtuálních počítačů, např. pro OS Windows je automaticky spuštěn nástroj SysPrep (připraví OS pro klonování). Součástí procesu vytváření virtuálního počítače pomocí šablony může být spuštění dodatečných skriptů či úprava základních nastavení, např. pro OS Windows zadání licenčního čísla, hesla pro účet administrátora atd. Jak hardwarové profily, tak samotné šablony jsou však uloženy v SQL databázi, jejich přenos na jinou instanci VMM je možný jen manuálním exportem přímo z DB. Vytvořené šablony, potažmo jejich virtuální disky, však může být žádoucí postupem času aktualizovat, at už se jedná o bezpečnostní či funkční záležitosti. K tomuto účelu slouží jiný nástroj Virtual Machine Servicing Tool, který různými metodami danou funkcionalitu umožňuje. Dynamickou optimalizaci systémových prostředků (PRO Performance and Resource Optimization). Na základě dat z monitorovacího nástroje OM umožňuje au- 51

59 3.3. NÁSTROJE PRO SPRÁVU, MONITOROVÁNÍ A ZÁLOHOVÁNÍ tomatické přemíst ování virtuálních počítačů. Základní možnosti jsou omezeny na monitorování CPU a paměti, výchozím chováním je migrace virtuálního počítače při překročení určité (kritické) hodnoty. Někteří výrobci HW však toto chování rozšířili a systém může různě reagovat na překročení teploty serveru, zvýšenou zátěž úložiště či další parametry. Bohužel podpora není ze stran výrobců stejná, a tak se výsledky značně odlišují. Zajímavá jsou například rozšíření pro optimalizaci spotřeby elektrické energie (spotřebování méně energie při zajištění stejného výkonu/služeb), která vypínají a zapínají hostitelské systémy a dynamicky mezi nimi přemíst ují počítače. Podporu skriptů v PoweShell (PS). Umožňuje vykonávat veškeré akce, které jsou přístupné pomocí grafického rozhraní i pomocí skriptů. Navíc existují některé akce, které jsou dostupné výhradně pomocí skriptů, jako je například vytvoření virtuálního počítače s novým diferenciálním diskem. To však není na škodu, protože skripty jsou mnohonásobně flexibilnější než pevně definované grafické rozhraní. Na druhou stranu je třeba uvést, že v grafickém rozhraní obsahuje téměř každý průvodce tlačítko zobrazit skript, které zvolenou funkcionalitu zobrazí ve formě PS skriptu. To značně zlehčuje situaci obsluze, která není se skriptováním v PS a VMM obeznámena. Jedna z vlastností, které značně urychlují nasazení virtuálního počítače, je využití služeb úložiště pro zkopírování souboru se šablonou pro tuto funkcionalitu je nezbytně nutné vytvořit skript. Zkopírování několika desítek GB pak může být v porovnání s používanou metodou v rámci VMM (BITS Background Intelligent Transfer Service, využívající HTTPS) zlomek potřebné doby. Dokonce i obyčejné zkopírování souboru ve Windows je rychlejší než přenos pomocí BITS technologie a skript je jediná možnost, jak toto omezení automatizovaně obejít. Správu jiného virtualizačního prostředí než Hyper-V. VMM podporuje správu nástroje Microsoft Virtual Server 2005 a několika verzí VMware ESX. Jak již bylo uvedeno výše, podpora pro ESX vyžaduje existenci VMware nástrojů pro správu. Nejedná se tedy o přímou správu VMware prostředí, ale o navázání se na nástroje, které se pro správu daného prostředí používají. Zásadním způsobem jsou však limitovány vlastnosti, které lze v rámci VMM na daných hostitelích ovládat. Osobně se domnívám, že podpora nikdy nebyla určena pro správu VMware prostředí, ale výhradně pro migraci z konkurenční platformy na Hyper-V. Ovládání virtuálního prostředí prostřednictvím webového rozhraní. Samoobslužný portál pro správu umožňuje na základě definovaných oprávnění přístup k virtuálnímu počítači přes web a základní možnosti jeho správy. Zároveň je možné definovat uživatelům různá omezení, jako je omezení počtu spuštěných počítačů, použití jen některých šablon či hardwarových profilů. Bohužel je rozhraní určeno jen pro prohlížeč IE, a ostatní prohlížeče (a OS) tak nelze k přístupu použít. V praxi se však ukazuje, že toto rozhraní má příliš limitovanou funkcionalitu. Namísto toho je pou- 52

60 3.3. NÁSTROJE PRO SPRÁVU, MONITOROVÁNÍ A ZÁLOHOVÁNÍ žíván nástroj Self Service Portal 2.0, což je i přes stejný název odlišný produkt, jehož funkcionalita je oproti původním možnostem samoobslužného portálu značně rozšířena. Je možné lépe řídit proces vytváření virtuálního počítače a jeho další existenci v rukách koncových uživatelů. Například schvalovat konfigurace virtuálních strojů, definovat automatické smazání (stroje pro testovací účely), definovat různé ceny za zdroje a provádět podle nich vyúčtování či umožnit spouštění vlastních PS skriptů pro definované akce. 53

61 Kapitola 4 Testování výkonnosti Hyper-V Výkonnost virtualizační platformy je důležitým aspektem, který jistě ovlivní všechny virtuální počítače. Je proto víc než žádoucí zaměřit se na způsoby optimalizace výkonu virtualizačního systému. Ačkoliv lze k navyšování výkonu přistupovat čistě z HW stránky v podobě výměny serverů a úložišt za modernější, lze zvolit i mnohem sofistikovanější postup a pokusit se nejprve identifikovat problémová místa a ta upravovat. Bez patřičných znalostí celého výpočetního prostředí, kde je Hyper-V provozován, lze jen s obtížemi provádět nějaké optimalizace výkonu. Některé komponenty (např. konfigurace sítí) mohou ovlivňovat výkon celého prostředí a samy o sobě představovat úzká hrdla. Neustálé monitorování a vyhodnocování výkonu všech komponent je jedinou možností, jak bezpečně předejít zpomalení prostředí na neúnosnou úroveň. Není rozumné předpokládat, že po provedení nějakých optimalizací zůstane celé prostředí v té nejlepší možné konfiguraci na věky. Během provozu bude neustále docházet k přizpůsobování prostředí novým požadavkům, aplikacím a konečně i uživatelům. Tyto změny prostředí dělají z optimalizace výkonu proces, a nikoliv nějaký pevný stav, kterého by bylo možné jednou provždycky dosáhnout. Klasické přístupy k optimalizaci výkonu serveru často spočívají v kategorizaci jeho využití (např. souborový, databázový či ový) a použití obvyklých doporučení. Ve virtuálním prostředí, kde se očekává, že se hostované systémy dynamicky přesouvají, mohou být takto specifické optimalizace nemožné. Zrychlení jedné kategorie virtuálních počítačů může způsobit zpomalení jiné. Což nemusí být na škodu, pokud je jedna kategorie mnohem důležitější než všechny ostatní. Ale ani v případě různých, podobně důležitých kategorií virtuálních počítačů není nic ztraceno. Obvykle jsou v takovém případě vytvořeny kategorie hostitelů se specifickými úpravami pro provoz daných virtuálních počítačů. Naneštěstí není takové řešení vždy finančně možné či z praktického hlediska reálné, např. v situacích, kdy není kategorie využití virtuálního počítače známa, případně se neustále mění. V této kapitole jsou prezentovány některé metody pro optimalizaci výkonu virtuálního prostředí Hyper-V a na základě provedených testů i srovnání vlivu vybraných konfigurací úložného subsystému na výkon různých aplikací. 4.1 HW podpora virtualizace v Hyper-V Na každý fyzický počítač lze nahlížet jako na několik různých subsystémů (CPU, pamět, sběrnice, úložiště, sít, video). Přičemž některé z nich mohou být pro určité kategorie ser- 54

62 4.1. HW PODPORA VIRTUALIZACE V HYPER-V verů využívány více než ostatní, např. souborový server obvykle nevyužije video ani audio subsystém, zatímco úložiště, sít a operační pamět budou využívány nejvíce. Přístup k jednotlivým subsystémům však může být virtualizací negativně ovlivňován. V úvodní části práce byly diskutovány některé metody virtualizace a zmíněna jejich přímá podpora implementovaná v HW vybavení počítače. Tato podpora je dobrým začátkem pro další optimalizace, nebot s její pomocí je možné dosáhnout lepšího výkonu prakticky nejsnáze. Bohužel je oblíbeným nešvarem prezentování technologií pro podporu hardwarové virtualizace spolu se slovem Hyper-V, které lze spatřit nejen v prezentačních materiálech [17], ale i důvěryhodnějších textech [7]. Přičemž na jedné straně prezentuje výrobce HW různé metody pro obecnou podporu virtualizace, na druhé straně je v nějakém kontextu zmiňován nástroj Hyper-V. Což může vyvolávat mylný dojem, že všechny prezentované technologie jsou v Hyper-V použitelné. Drobnému chaosu v pojmech přispívá i fakt, že každý výrobce používá pro označení svých technologií odlišný název a Microsoft tyto rozličné názvy sjednocuje po svém, například pod označením Second Level Address Translation (SLAT) jsou zahrnuty funkčně podobné technologie firmy Intel Extended Page Table (EPT) a firmy AMD Nested Page Table (NPT) nebo častěji Rapid Virtualization Indexing (RVI). Nalézt přesnou odpověd na otázku, zda je daná technologie podporována, či nikoliv, není proto vždy jednoduché. Pro technologie firmy Intel lze nalézt odpověd zde [28]. Výběr vhodného HW pro použití nástroje Hyper-V by tedy neměl být primárně ovlivněn technologiemi, které není možné okamžitě využít. Na druhou stranu je nutné konstatovat, že novější verze Hyper-V mohou v budoucnu využití daných technologií podporovat a případná investice se tedy může vyplatit. Některé technologie pro zvýšení výkonu určené nejen pro virtuální prostředí však vyžadují kromě samotné přítomnosti podpory v HW a Hyper-V i dodatečné nastavení na různých místech v systému. Typickým příkladem jsou technologie pro podporu sít ového provozu, například: TCP Offload Engine (TOE) / TCP Chimney přemístění zpracovávání TCP/IP do sít ového adaptéru. Virtual Machine Queue (VMQ) přemístění zpracování paketů (hledání MAC adresy, ověření VLAN ID) do sít ového adaptéru spolu s přiřazením vlastní fronty pro jednotlivé virtuální počítače. Tato fronta je napojena přímo do adresového prostoru virtuálního počítače, a nedochází tak k násobnému kopírování dat při zpracovávání paketů. Recieve Side Scaling (RSS) umožňuje zpracovávat přijatá data z jednoho sít ového adaptéru na více logických procesorech v multiprocesorovém počítači. Zatímco VMQ a TCP Chimney nelze použít zároveň a vyžadují aktivaci jak v rámci virtuálního, tak i fyzického počítače, RSS je možné aktivovat výlučně na fyzickém počítači. Jednotlivé postupy a omezení pro nastavení a ověření sít ové HW podpory v Hyper-V lze nalézt v následující sérii článků [15] a [53]. 55

63 4.2. TESTOVACÍ PROSTŘEDÍ Samotná konfigurace serveru, jako je např. správné umístění modulů operační paměti do jednotlivých slotů, je esenciálním předpokladem pro libovolné optimalizace. Výrobce daného HW obvykle poskytuje přesné návody pro konkrétní výrobek. Základní principy, které je třeba dodržet, spolu s odpovídajícím komentářem a srovnáním výkonu pro některé subsystémy je výborně zpracováno v publikaci [32]. 4.2 Testovací prostředí Pro účely výuky předmětu Správa MS Windows I a II (PV175 a PV176) na Fakultě informatiky Masarykovy univerzity je používán nástroj Hyper-V ve verzi WS2008R2. Konfigurace prostředí probíhala v rámci diplomové práce [10] a podrobnosti lze najít v 5. kapitole odkazovaného dokumentu. Prostředí bylo od původního návrhu postupem času modifikováno a nyní vypadá následovně: Fyzický server: HP ProLiant DL785 G5 (AK233A) Windows Server 2008 R2 Enterprise 8x AMD Opteron 8358 SE 2,4Ghz (4 jádra) 256GB RAM (8x4GB/CPU -- NUMA) 1x HBA: HP FC2242SR 4Gb PCI-e DC Fibre Channel Adapter -- 2 porty (A8003A) OS: WS2008R2 Diskové pole: MSA 2012FC G1 Dual Controller (AJ743A) 2 rozšiřující police (AJ750A) s~maximální kapacitou 12 disků Celkem 31 použitelných 300GB SAS RPM disků Aktivován Interconnect hostitelských portů 16 disků RAID 10, 64KB Chunk -- LUN pro výuku 12 disků RAID 10, 64KB Chunk -- LUN pro hostování individuálních počítačů 2 disky jako Global Spare a 1 disk se nepoužívá Server připojen do obou řadičů přímo pomocí FC (2 porty na kartě) Zájem studentů o absolvování daných předmětů každoročně vzrůstá a s ním i nároky na virtualizační prostředí. Stejně tak vzrůstají i požadavky na samotné virtuální počítače, zatímco pro předmět PV176 v semestru 2010 postačily každému studentovi 3 virtuální počítače, v roce 2011 to byly už 4. Specifikem tohoto prostředí je druh zátěže, který spočívá v provozování testovacích virtuálních počítačů s prakticky čistou instalací OS Windows 7 a Windows Server 2008 R2 bez dalších aplikací. V rámci výuky se studenti seznamují s OS Windows a ověřují praktické dopady jednotlivých nastavení, což samo o sobě představuje jen minimální zátěž. Tedy až do okamžiku, než je virtuálních počítačů několik set, v ten moment může docházet ke zpomalení reakcí virtuálních počítačů. Cílem optimalizace je zjistit vhodnou konfiguraci prostředí pro provoz co největšího počtu virtuálních počítačů pro účely výuky zmíněných předmětů. Druhým testovacím prostředím je virtualizační server ve firmě Kentico software s.r.o., který byl určen pro provoz ového serveru Microsoft Exchange 2010 ve virtuálním pro- 56

64 středí. Prostředí má následující konfiguraci: Fyzický server: IBM x3650m3 (7945-K3G) Windows Server 2008 R2 Datacenter 2x Intel Xeon E5620 2,40GHz 48GB RAM (6x8GB) DDR3 1333MHz 2x HBA IBM 6Gb SAS HBA PCI3E OS: WS2008R2 Diskové pole: IBM DS3512 Express Dual Controller 7x 300GB RPM 6Gbps SAS 5x 2TB NL 7200 RPM 6Gbps SAS 1x 300GB disk je vyhrazen pro jiné použití 1x 2TB disk je vyhrazen pro jiné použití 4.3. METODIKA TESTOVÁNÍ A KONFIGURAČNÍ PRVKY V tomto případě je cílem zjistit vhodnou konfiguraci úložiště pro provoz produktu Exchange 2010 v zamýšleném typu nasazení. 4.3 Metodika testování a konfigurační prvky Srovnání výkonu (benchmark) libovolného systému lze řešit různými postupy. Od primitivních programů, simulujících zátěž prováděním několika instrukcí ve smyčce, až po sofistikované nástroje testující celé prostředí, které může čítat desítky počítačů, aplikací a dalších zařízení. Cíl je přitom vždy stejný, nějakým způsobem změřit (vyčíslit) dosáhnutý výkon. Obecně se dají srovnání rozdělit do 3 skupin: Standardizované testy jedná se o testy spravované nezávislými organizacemi, například testy TPC-C, TPC-E či SPEC CPU2006. Subjektivní testy pro testování jsou použita reálná data nějakého subjektu a jím používané aplikace a nastavení. Alternativně jsou použity nástroje pro simulování zátěže dané aplikace. Ostatní do této kategorie lze zařadit všechny jednokomponentové testovací nástroje. Standardizované testy jsou obvykle používány pro relativní porovnání systémů mezi sebou a neodpovídají výkonu, který lze v reálných podmínkách obdržet. Hardwarová konfigurace je v těchto testech často nereálná a v produkčních podmínkách se vyskytuje zřídka, např. používání RAID 0 v diskových polích či maximální osazení diskového pole všemi disky, které navíc používají jenom nejrychlejší vnější stopy (short-stroking). Podobně je nutné brát v úvahu i fakt, že se jedná o špičkový výkon a pro návrh nějakého řešení je vždy nutné počítat s rezervou pro vykrytí případných špiček. 57

65 4.3. METODIKA TESTOVÁNÍ A KONFIGURAČNÍ PRVKY Subjektivní testy lze použít pro přesnější odhad potřebného výkonu a zároveň pro měření vlivu změn konfigurace systému. Je však třeba zajistit, aby podmínky testu byly opakovatelné, tj. nebyly závislé na nějakém momentálním stavu systému. V obou případech však platí, že se jedná o časově náročné úkoly, které vyžadují systematický přístup Ukazatele výkonu Je na místě klást si otázku, jakým způsobem měřit okamžitou výkonnost virtualizačního prostředí či případných subjektivních srovnávacích testů. Není obvyklé, aby aplikace zobrazovaly hodnotu označenou výkon, podle které by bylo možné srovnání jednoduše provést. A i kdyby, jakým způsobem pak postupovat v optimalizacích? Je potřeba zrychlit procesor či přidat operační pamět? Odpověd na tyto otázky se pokouší přinést tato část. Pro optimalizaci výkonu lze využít metodu založenou na monitorování jednotlivých subsystémů a postupně zjištěná úzká hrdla v systému eliminovat. Tato metoda zjevně nemusí být použitelná vždy, protože nezahrnuje pohled uživatele systému, který s provozovanou aplikací pracuje (aplikace může být špatně nastavená nebo vyčkávat na nějaké operace a přitom minimálně využívat systémové zdroje). I tak lze tímto jednoduchým postupem dosáhnout slušných výsledků. Před výběrem konkrétních ukazatelů pro měření jednotlivých subsystému je vhodné získat co nejvíce informací o systému jako celku. Například pokud je optimalizován existující systém, který je nějakým způsobem zpomalen, je dobré zaměřit se na informace, jako jsou: detailní popis konfigurace, přesné projevy zpomalení, zda postihuje problém všechny, nebo jen omezenou skupinu uživatelů, kdy se problém poprvé objevil, zda se postupem času zhoršuje, nebo zda se vyskytuje jen v určitý časový okamžik, je možné reprodukovat problém, existují nějaké záznamy o provozu (logy, monitorovací systémy) a zda se v poslední době neměnila konfigurace systému. Pokud jsou informace zjišt ovány formou rozhovoru s obsluhou, ze zkušeností doporučuji poslední uvedenou otázku klást až v samém závěru. Ačkoliv je celá řada náhlých problémů způsobena právě změnou konfigurace (aktualizace systému, ovladačů, nový disk, výměna kabelu atd.), není obvykle přiznání obsluhy považováno za polehčující okolnost a zjištění příčiny problému tak může být uměle směřováno špatným směrem. Uvedené informace pomohou s omezením výběru nutných ukazatelů výkonu či jednodušší diagnostikou úzkého hrdla (stanovení monitorovací doby, frekvenci snímání vzorků, konkrétních uživatelů, zda je možné reprodukovat problém v testovacím prostředí, nebo je nutné provádět diagnostiku na produkčním prostředí). Ideální je monitorování jen několika málo klíčových ukazatelů subsystému a v případě překročení kritických hodnot je přistoupeno k podrobnějšímu zkoumání. Seznam možných ukazatelů a kritických hodnot je uveden níže a vychází z [32] a je doplněn o specifika virtuálního prostředí [31]: Procesor zatímco v rámci fyzického počítače je měření výkonu procesoru relativně přímočaré a postačí ukazatele Processor\% Processor Time_Total a % Proccesor 58

66 4.3. METODIKA TESTOVÁNÍ A KONFIGURAČNÍ PRVKY Time (N), v rámci Hyper-V má každý Partition přidělen procesor virtuální. Použití stejného ukazatele v Hyper-V měří jen využití času virtuálního procesoru, který byl Partition hypervizorem přidělen. Není však známo, kolik času fyzického/logického procesoru přidělil hypervizor danému virtuálnímu procesoru. Pozoruhodné je, že i nástroj VMM v kombinaci s OM používá právě tento ukazatel pro generování přehledových zpráv o výkonu jednotlivých virtuálních počítačů. Stejný ukazatel používá i oblíbený nástroj pro okamžitou kontrolu využití CPU ve Windows nazvaný správce úloh (Task Manager). Vhodnější je však ukazatel Hyper-V Hypervisor Logical Processor\% Total Run Time, který poskytuje informace o celkovém využití fyzických/logických procesorů. Přičemž je nutné monitorovat všechny logické procesory samostatně, a nikoliv jen jejich celkový součet, například sít ový adaptér bez podpory RSS (Recieve Side Scaling) by mohl být limitován rychlostí jednoho logického procesoru, zatímco ostatní by nebyly využity. Za kritickou hodnotu (resp. indikátor možných problémů) je považováno dlouhodobé překročení rozpětí %. Jistým upřesněním jsou ukazatele ze skupiny Hyper-V Hypervisor Root Virtual Processor a Hyper-V Hypervisor Virtual Processor, které v prvním případě odpovídají využití Parent Partition a v druhém jednotlivým virtuálním počítačům. Pro virtualizované prostředí jsou vhodné i ukazatele %Guest Run Time a %Hypervisor Run Time, které odpovídají rozdělení procesorového času virtuálního či logického procesoru mezi hostovaný systém a hypervizor. Pokud je hodnota využití procesoru hypervizorem vyšší než 25 %, může být systém zaneprázdněn nadměrným zpracováváním I/O požadavků nebo jsou provozovány systémy bez syntetických zařízení (nebo bez integračních komponent). Ukazatel hypervizoru tak v zásadě odpovídá běžnému % Kernel Run Time ve fyzickém prostředí. Operační pamět nejpoužívanějším ukazatelem je bezesporu Memory\Available MBytes, který udává velikost operační paměti v MB, jenž lze okamžitě přidělit nějakému procesu. Za kritickou hodnotu bývá považováno množství, které je menší než 20-25% instalované paměti. Některé aplikace, jako jsou např. databázové servery, však alokují co nejvíce dostupné paměti, a v takovém případě je pak ukazatel volné paměti nevhodný. Stejně zavádějící může být procentuální vyjádření v případě hostovaných systémů, které používají dynamickou změnu velikosti operační paměti (Dynamic Memory). V takovém případě celková velikost operační paměti nemusí odpovídat právě přidělené (instalované) kapacitě, a je tak v různých okamžicích vzájemně neporovnatelná. Pro monitorování hostitelského systému lze však tento ukazatel relativně dobře použít. Relativně proto, že může být dočasně vyžadováno větší množství dostupné paměti než je 20-25% z libovolného množství, např. jenom pro zpracování I/O požadavků sít ové karty Broadcom BCM57710 to mohou být podle počtu adaptérů ve špičce až 4GB [34]. Často proto bývá údaj o použitelné paměti doplněn o nějakou formu detekce stránkování. Většinou pomocí ukazatele Memory\Pages/sec, který odpovídá počtu čtení nebo zápisu stránek z disku za sekundu. Ačkoliv k načítání stránek dochází obvykle při 59

67 4.3. METODIKA TESTOVÁNÍ A KONFIGURAČNÍ PRVKY výpadku stránky v operační paměti, lze ve Windows použít stejný mechanismus i v případě přístupu k jiným souborům [22]. Jinými slovy, aplikace nemusí načítat do paměti celý soubor, nebo využívat běžný přístup, ale pomocí mapování si zpřístupní jen některé jeho části (stránky) podle toho, jak je k nim přistupováno. To ale znamená, že je nutné rozlišit mezi přístupem k souboru pagefile.sys, kam jsou běžně stránky z operační paměti umíst ovány a přístupem k jiným souborům, k čemuž je nutné využít další nástroje. Sít ová komunikace ověření výkonu sít ové komunikace bývá obvykle komplikované. Jednoduše proto, že na samotném serveru je možné změřit jen data tímto serverem procházející, zatímco ke zpomalení může docházet v jiném místě. Ačkoliv jsou často doporučovány ukazatele ze skupiny Network Interface, jako jsou Packets/Sec, Bytes Received Send/Sec nebo Packets Receive Errors, určení kritické hodnoty je bez znalosti konkrétního sít ového adaptéru a podmínek sítě prakticky nemožné. Obecně je považováno za kritické (hodné pozoru), pokud je hodnota větší než 60-70% očekávané kapacity. Alternativně lze využít Network Interface(*) \ Output Queue Length, kde jsou za kritickou hodnotu považována více než 2 čekající vlákna. I když lze v rámci virtuálního prostředí využít ukazatele výkonu pro virtuální přepínač i jednotlivé virtuální adaptéry, je obtížné definovat nějakou kritickou hodnotu adaptéry nemají pevně stanovenou maximální rychlost. Jedná se o ukazatele ze skupiny Hyper-V Virtual Switch a dvojice Hyper-V Virtual Legacy Network Adapter. Úložný subsystém obvykle nejpomalejším a z hlediska výkonu nejproblémovějším místem systému je právě úložiště. Zatímco přístup do operační paměti je měřen v řádu jednotek nanosekund, diskové operace jsou zpravidla měřeny v řádu jednotek milisekund. Ve virtuálním prostředí lze použít běžné ukazatele pro měření výkonu fyzického disku, tedy Physical disk\ Avg. Disk sec/transfer a Physical Disk\ Avg. Disk Queue Length. V případě prvního ukazatele je měřena doba potřebná pro vykonání I/O požadavku, u běžných rotačních disků je kritická hodnota udávána jako 25ms (záleží na typu provozované úlohy a použitém subsystému). V druhém případě se jedná o množství I/O požadavků čekajících ve frontě na zpracování, kde je kritická hodnota obvykle udávána jako 2 až 3 požadavky na jeden aktivní fyzický rotační disk. Je patrné, že manuální výběr ukazatelů a hlavně jejich analýza může být časově náročný úkol, zvláště pokud jsou pravidelně analyzovány desítky serverů nebo prováděno více měření. Pro dlouhodobý sběr a automatické vyhodnocování lze použít například již zmiňovaný monitorovací nástroj Operation Manager. Pro účely optimalizace daných testovacích prostředí jsem pro analýzu hostitelského systému zvolil nástroj PAL (Performance Analysis of Logs < který využívá integrovaných nástrojů pro měření výkonu, ale provádí automatizované vyhodnocení uložených měření logů. Nástroj obsahuje sady vhodných ukazatelů a kritických hodnot pro specifická prostředí (například 60

68 4.3. METODIKA TESTOVÁNÍ A KONFIGURAČNÍ PRVKY klientské PC, Hyper-V či SQL) a pro prezentaci výsledků generuje odpovídající pomocné grafy Optimalizace systému Jakmile je na základě uvedených ukazatelů v předchozí části vytipován subsystém, který pravděpodobně způsobuje zpomalení celého systému, je nutné přistoupit k dalšímu zpřesnění. Smyslem zpřesnění je potvrdit, že zpomalení skutečně způsobuje daný subsystém a určit, jaké změny je možné provést pro jeho urychlení. Zatímco pro iniciální monitorování si lze vystačit s integrovanými nástroji ve Windows (Performance Monitor), pro zpřesnění může být nutné použití dalších nástrojů. V každém případě je však důležité vhodně určit monitorovací intervaly, tj. dobu měření a rychlost vzorkování. Příliš krátké intervaly nedokážou zaznamenat výkyvy a pokud dochází jen ke krátkodobým zpomalením, nemusí se je podařit v měření zachytit. K tomu přispívá i fakt, že integrovaný monitorovací nástroj ve Windows je schopen zaznamenávat ukazatele jen každou 1 sekundu. Pro detailní měření lze však s úspěchem využít zdarma dostupné nástroje, jako je Xperf či nástroje rodiny SysInternals. Příliš rychlá frekvence vzorkování zase naopak vyžaduje větší množství diskového prostoru pro uložení logu. Samotné monitorování navíc ovlivňuje výkon, proto by nemělo být monitorováno víc ukazatelů, než je nezbytně nutné. Pokud je měřeno úložiště, neměl by být log ukládán na právě měřený disk. Jednotlivá doporučení vycházejí z [32] a mých osobních zkušeností s provozem Hyper-V Procesor Vzhledem k tomu, že procesor ovlivňuje chod celého počítače, bývá zpomalení nejčastěji přisuzováno tomuto subsystému. Pravdou však je, že dnešní procesory většinou nebývají úzkým hrdlem serverového systému. Zatímco identifikace procesu, který nadměrně využívá CPU je snadná, otázkou zůstává, jak jej snížit. V ten moment do úvahy vstupuje několik zásadních faktů [29]: V případě vícejádrových procesorů dochází k sdílení některých fyzických zdrojů, jako je cache pamět procesoru, což v závislosti na provozovaných aplikacích může značně ovlivnit výkon (pozitivně i negativně). Přiřazení procesu konkrétnímu logickému procesoru zajišt uje OS (často je používán termín afinita procesoru). Ačkoliv lze v ryze fyzickém prostředí přiřazení měnit, v rámci virtuálního počítače to tak snadné není. Virtuální procesor počítače není pevně spojen s konkrétním logickým procesorem a o jeho plánování rozhoduje hypervizor. Většina dnešních multiprocesorových x86 systémů používá NUMA (Non-Uniform Memory Acccess) architekturu, viz 4.1, ve které je systém rozdělen do několika uzlů (typicky 1 uzel pro každý fyzický procesor). Komunikace v rámci uzlu, tj. mezi logickými procesory a operační pamětí, je rychlá, zatímco komunikace mezi různými 61

69 4.3. METODIKA TESTOVÁNÍ A KONFIGURAČNÍ PRVKY uzly je pomalejší. Jak výrazně je komunikace pomalejší, závisí na konkrétní implementaci v daném serveru. Hyper-V se snaží přidělit celou operační pamět virtuálního počítače do jednoho uzlu a následně plánovat jeho virtuální procesory nad logickým procesory daného uzlu tak, aby byl výkon co možná nejlepší. Pokud však není dostatek paměti v rámci žádného uzlu pro umístění virtuálního počítače, musí dojít k rozdělení mezi několik uzlů, a výkonnost systému může být v závislosti na provozovaných aplikacích ovlivněna. K přiřazování virtuálních počítačů do jednotlivých uzlů dochází během jejich spouštění. Může však dojít k situaci, že v jednom uzlu bude nepoměrně více virtuálních počítačů využívající procesor než v jiném, což se projeví snížením dostupného výkonu pro dané virtuální počítače. Řešením je znovuspuštění počítače, čímž může dojít ke změně uzlu, ve kterém je virtuální počítač spuštěn. Alternativně lze manuálně přidělit virtuální počítače ke konkrétnímu uzlu [24]. Některé funkce pro snížení spotřeby elektrické energie mohou zkreslovat poskytované informace. Kupříkladu ukazatel Processor\% Processor Time_Total je vyhodnocován na základě aktuální frekvence procesoru, nikoliv však maximální. Přičemž právě různé funkcionality pro snížení spotřeby dynamicky mění frekvenci procesoru v závislosti na potřebném výkonu. Některé z nich lze řídit z OS (ve Windows v nastavení spotřeby elektrické energie), jiné lze řídit jen prostřednictvím BI- OSu. Jeden ze způsobů, jak odstínit vliv těchto funkcí během měření, je jejich dočasná deaktivace. Obrázek 4.1: Znázornění počítače s NUMA (Non-Uniform Memory Access) architekturou a bez 62

70 4.3. METODIKA TESTOVÁNÍ A KONFIGURAČNÍ PRVKY Další úvahy o optimalizaci mohou směřovat k lepšímu rozdělení virtuálních procesů. Pomocí již zmíněných ukazatelů je možné měřit využití virtuálních a logických procesorů. Pokud je využití virtuálních procesorů vysoké a logických procesorů nízké, znamená to, že některé virtuální počítače nemají přidělené dostatečné množství procesorů. Pokud už další procesory virtuálním počítačům přidělit nelze (nebo redukovat jejich využití uvnitř virtuálních počítačů), může být nutné rozložit provozovanou aplikaci na více virtuálních počítačů. V případě obrácené situace, tedy využití virtuálních procesorů je nízké a logických vysoké, je výkon procesoru spotřebováván na jiné aktivity, jako je například zpracování I/O požadavků nebo přepínání kontextu, které je potřebné pro obsloužení každého virtuálního procesoru. Obecně lze v takových případech doporučit snížení počtu virtuálních procesorů či další diagnostiku, například pomocí nástroje Xperf a dodatečných ukazatelů. Určení přesné příčiny obvykle vyžaduje rozsáhlé znalosti OS, ze zkušenosti však mohu říci, že je často způsobeno ovladači hardwaru či antivirovými (nebo jinými rezidentními) programy. A tak je namísto zdlouhavé diagnostiky jednodušší provést aktualizaci ovladačů na novější verzi nebo upravit nastavení daných programů. Optimalizace uvnitř virtuálního počítače závisí na provozované aplikaci a OS, obecně lze doporučit: Vypnutí nepoužívaných služeb a naplánovaných úloh. Vypnutí spořičů obrazovky (ve virtuálním prostředí postrádají smysl, nikdo u virtuálních počítačů nesedí, přesto se musí vykreslovat změny spořiče). Nainstalovat do všech virtuálních počítačů integrační komponenty. Používat jenom syntetická zařízení pro virtuální počítače (zejména virtuální sít ové adaptéry). Odstranění virtuální DVD mechaniky (Hyper-V periodicky testuje, jestli je vloženo nějaké médium). Nepoužívat antivirus v Parent Partition (pokud je to nutné, vytvořit výjimky pro VHD soubory, konfiguraci virtuálních počítačů a služby Hyper-V) Operační pamět Problémy s operační pamětí lze obvykle zahrnout do kategorie nedostatečná kapacita (záleží však na provozované aplikaci). V případě Hyper-V jde tedy především o správné odhadnutí velikosti přidělené operační paměti virtuálním počítačům. Samotná rychlost paměti nebývá problém, a pokud ano, pak ji z pravidla lze řešit jen fyzickou výměnou za rychlejší, či úpravou aplikace. Stále však platí, že nejlepším způsobem je použití HW podpory virtualizace operační paměti. U počítačů s NUMA architekturou je nutné pamatovat na pomalejší přístup v rámci rozdílných uzlů. Způsob jakým ověřit, zda je pamět virtuálního počítače umístěna v jednom 63

71 4.3. METODIKA TESTOVÁNÍ A KONFIGURAČNÍ PRVKY uzlu je popsán v [24]. Během provozu virtuálního počítače s funkcí dynamické změny velikosti operační paměti za běhu (Dynamic Memory) může dojít k přidělení operační paměti z jiného uzlu (pouze v případě, že v lokálním uzlu již není dostatek volné paměti), což může negativně ovlivnit výkon. Tuto funkcionalitu lze vypnout (NUMA node spanning), a pamět v takovém případě bude přidělována jen z lokálního NUMA uzlu. K odhadu velikosti paměti, který virtuální počítače ke svému běhu potřebuje, lze v rámci OS Windows použít několik ukazatelů Memory\Standby Cache Reserve Bytes a Memory\Free & Zero Page List Bytes. V obou případech se doporučuje, aby hodnota byla 200 MB pro systém s 1GB instalované operační paměti a 300 MB pro systém s více než 2GB operační paměti. Nedostatek operační paměti způsobí stránkování, což může značně zpomalovat celý systém Sít ová komunikace Diagnostika sít ové komunikace a problémů na síti může být vzhledem k různým prvkům sítě a specifickým konfiguracím velmi náročný úkol. Jeho popis je nad rámec zadání této práce. Obecně však v rámci jednoho serveru může docházet ke 2 základním problémům. Často je při diagnostice používáno jen hledisko propustnosti sít ového adaptéru, ale opomíjí se fakt, že samotné adaptéry mohou být zahlceny množstvím I/O požadavků, a dochází k přetížení jejich vlastního procesoru. Přitom se z pohledu propustnosti může adaptér jevit jako téměř nevyužitý. Pro některé serverové sít ové adaptéry publikují výrobci maximální hodnoty I/O požadavků v závislosti na jejich velikosti, které je adaptér schopen zpracovat. Což lze pro diagnostiku a nastavení různých varování využít. Pro optimalizaci nastavení OS Windows lze využít doporučení uvedená v dokumentech [54] a [53], které se věnují možným nastavením TCP/IP a dalších používaných protokolů Úložný subsystém Optimalizace úložného subsystému se liší v závislosti na použitém HW a je vhodné využít doporučení výrobce. V této části se proto zaměřuji na doporučení [27] a [38] od výrobců diskových polí testovacích prostředí. Obecně lze jakoukoliv zátěž (I/O operace) diskového subsystému rozdělit do dvou kategorií: Velké množství malých I/O požadavků, malá propustnost z praktického hlediska se jedná o nejčastější kategorii. Důležitým rysem je, že jednotlivé I/O požadavky jsou náhodné, tj. data se zapisují, nebo čtou z různých míst na disku, nikoliv souvisle (sekvenčně) za sebou. Malé množství velkých I/O požadavků, velká propustnost typickým příkladem tohoto druhu zátěže je právě sekvenční čtení/zápis dat na disk, např. kopírování. 64

72 4.3. METODIKA TESTOVÁNÍ A KONFIGURAČNÍ PRVKY Pod pojmy malý/velký I/O požadavek se v této práci rozumí velikost datového bloku v samotném I/O požadavku. Z uvedených kategorií pak vycházejí i používané způsoby optimalizací v prvním případě je klíčový počet zpracovaných I/O požadavků, zatímco v druhém případě je zásadní celková propustnost. V rámci jednoho fyzického disku je zkombinování obou kategorií zátěží kontraproduktivní. Pokud má disk v jeden okamžik sekvenčně číst/zapisovat nějaká data a zároveň přistupovat na jiná místa na disku, bude se disková hlavička neustále přesouvat mezi různými stopami, a propustnost tak bude zásadně omezena. Počet zpracovaných náhodných I/O požadavků je limitován především použitými disky. Pokud uvážíme jeden rotační disk s RPM pak lze, v závislosti na přístupové době disku, obdržet zhruba 150 I/O operací za sekundu. Další zvýšení je možné jen s použitím více disků, typicky v nějaké RAID konfiguraci, nebo omezením používaného prostoru disku (tzv. short-stroking). Vzhledem k tomu, že největší časovou prodlevu způsobuje přesun diskových hlaviček na danou diskovou stopu a čekání na správný sektor, stačí omezit používaný prostor disku (typicky 10% vnější nejrychlejší části disku) a v tomto místě dojde ke koncentraci dat. Přístup k těmto datům pak bude výrazně rychlejší, ale nevýhoda je zřejmá zbylé místo zůstane nevyužito. Uvedený příklad však ukazuje jednu vlastnost, kterou je třeba při testování neopomenout. Tedy, že testovací data by měla odpovídat reálnému rozsahu, a nikoliv jen malé části. Čím se bude využívaný prostor disku zvětšovat, tím se bude zpomalovat výkon (delší čas potřebný pro přemístění diskových hlaviček). Mezi další prvky, které nejvíce ovlivňují výkon úložiště, patří následující: Varianta RAID. Konfigurace LUN. Velikost segmentu/bloku a alokačních jednotek. Konfigurace vyrovnávací paměti. Varianta RAID Obvykle je v diskovém poli používán více než jeden disk a spojení disků je realizováno nějakou variantou RAID. Z celé řady různých variant jsou obvykle používány jen 3 a to RAID 10, RAID 5 a v omezené míře i RAID 6. Při srovnatelném počtu disků dosahuje RAID 5 obvykle nejlepšího výkonu v oblasti čtení, protože používá nejvíce aktivních disků. Bohužel může být zápis vzhledem k nutnosti počítat paritu značně zpomalen. Dále je nutné uvažovat možné zpomalení, které nastane při výpadku disku. V takovém případě bude výkon celé RAID skupiny disků v případě RAID 5 i 6 negativně ovlivněn. Jak již bylo uvedeno výše, množství a typ disků použitých pro vytvoření RAID skupiny je poměrně zásadním parametrem. V některých případech ale může být počet disků omezen, konkrétně testovací diskové pole MSA 2012fc umožňuje do RAID 1, 5 a 6 zahrnout jen 16 disků. Ačkoliv se může zdát, že by z hlediska výkonu bylo vhodné vytvořit jednu RAID skupinu ze všech disků v poli, má takové řešení několik nevýhod: 65

73 4.3. METODIKA TESTOVÁNÍ A KONFIGURAČNÍ PRVKY Selhání jednoho disku ovlivní celou skupinu a všechny logické jednotky (LUN). Nelze odstínit vliv různých kategorií zátěže, čtení a zápis probíhají do stejné množiny fyzických disků. Disková RAID skupina nemusí odpovídat požadavkům všech serverů, které diskové pole využívají. Proto je obvykle vytvořeno více diskových RAID skupin, minimálně jedna pro každou kategorii zátěže. Pro dosažení lepšího výkonu může být žádoucí rozložit zátěž na všechny komponenty diskového pole, tj. namísto jedné diskové skupiny po 16 discích, vytvořit 2 po 8 discích a každou přiřadit jednomu diskovému řadiči. Taková konfigurace umožní rozložit zátěž mezi oba dva diskové řadiče. Konfigurace LUN Aby mohl OS využívat RAID skupinu je nutné v ní nejprve vytvořit logickou jednotku (LUN). Pro obě testovací pole platí, že LUN lze přiřadit právě jednomu diskovému řadiči. Tato vlastnost ovlivňuje možnosti rozložení zátěže mezi diskové řadiče. I když je v obou testovacích prostředích připojen server k oběma diskovým řadičům, jsou I/O požadavky zpracovávány jen jedním diskovým řadičem. Pro rozložení zátěže mezi oba dva řadiče je nutné vytvořit dostatečný počet LUN. Nevýhoda je, že se zatížení generované připojenými servery může v čase změnit a pak je nutné přiřazení LUN řadičům manuálně upravit, aby nedocházelo k přetížení jednoho řadiče. Velikost segmentu/bloku a alokačních jednotek Pro vytvoření logické jednotky je nutné specifikovat velikost použitého bloku (označováno také jako stripe unit, chunk nebo také segment unit). Data jsou do LUN zapisována po blocích tak, že je vždy zapsán nejprve jeden blok na jeden aktivní disk a potom další blok na další aktivní disk RAID skupiny (označováno také jako block level striping ). Všechny bloky dohromady od prvního do posledního aktivního disku RAID skupiny jsou označovány jako pruh (Stripe). Velikost pruhu je ovlivněna počtem disků a velikostí bloku. Vztah mezi blokem a pruhem je znázorněn na obrázku 4.2. Na bloky lze tedy nahlížet jako na mechanismus, kterým je distribuována zátěž na fyzické disky v rámci logické jednotky. Jakým způsobem však bude zátěž distribuována, záleží na velikost I/O požadavků, které obdrží úložiště od připojených serverů. Pokud je velikost I/O požadavků rovna velikosti pruhu, jsou všechny disky v RAID skupině rovnoměrně využity. V případě, že je: Velikost I/O požadavku menší nebo rovna velikosti bloku, lze tento I/O požadavek uspokojit jediným diskem. Velikost I/O požadavku větší než velikost bloku, je nutné použít více disků pro obsloužení požadavku. 66

74 4.3. METODIKA TESTOVÁNÍ A KONFIGURAČNÍ PRVKY Obrázek 4.2: Vztah mezi blokem (stripe unit) na disku a pruhem (stripe) [32] Pro maximalizaci počtu zpracovaných I/O požadavků je obvykle volena varianta s větší velikostí bloku, než jsou samotné I/O požadavky, protože ostatní disky zůstávají volné, a mohou tak obsloužit další požadavky. Například pokud je velikost I/O požadavků 4 KB a diskové pole sestává ze skupiny 3 disků v RAID 0 o velikosti bloku 8 KB, bude každý požadavek obsloužen nejvýše jedním diskem. To ale nebude stejné v případě RAID 5 (ani RAID 6), kde je nutné přepočítat paritu v případě modifikace nějakého bloku. Pokud jsou upravena nějaká data v bloku, musí být upraven celý blok, což obvykle vyžaduje 2 operace čtení (původní parita a původní blok) a 2 operace zápisu (nový blok a nově přepočítaná parita). To je oproti 1 operaci pro zápis, nebo 2 v případě RAID 10 značný posun k horšímu. Pokud ale velikost I/O požadavků odpovídá velikosti pruhu, může být parita spočítána ve vyrovnávací paměti (není potřeba načítat původní data) a všechna data jsou zapsána najednou. Tento mechanismus bývá označován jako full stripe write. V případě RAID 5 je velikost pruhu určena z aktivních datových bloků, tj. nepočítá se disk s paritou, vzorec pro výpočet velikosti pruhu by tedy vypadal následovně:(počet disků v RAID 5 skupině - 1) * velikost bloku. Velikost I/O požadavků je možné měřit na několika úrovních: Přímo na serveru. V případě OS Windows k tomu lze použít ukazatel Physical disk\avg. Disk Bytes/Transfer, případně jeho Read/Write variantu. V rámci diskového pole. Použité nástroje se liší v závislosti na konkrétním diskovém poli. V rámci sítě pro komunikaci s úložištěm. Použité nástroje se liší v závislosti na konkrétním druhu sítě. Pozornost je potřeba věnovat interpretaci ukazatelů pokud je pro optimalizaci diskového subsystému použita průměrná hodnota velikosti I/O požadavku, nemusí být ve skutečnosti žádný I/O požadavek průměrné velikosti. Vhodnější tak může být použití mediánu, který 67

75 4.3. METODIKA TESTOVÁNÍ A KONFIGURAČNÍ PRVKY však nástroj ve Windows přímo nezobrazuje, a je tak nutné naměřené hodnoty dále vyhodnotit. Podobně se mohou lišit hodnoty naměřené ze serveru a diskového pole, protože v rámci HBA karet může docházet k dalším úpravám požadavků, primárním zdrojem by proto měla být data z diskového pole. Pro maximalizaci počtu provedených I/O operací, by dle popsaných doporučení měla být velikost bloku diskového pole větší nebo rovna než velikost většiny I/O požadavků. Obrázek 4.3: Souborový systém hostitele je zarovnán s bloky diskového pole [55] Do úvahy je však nutné zahrnout i další parametr a totiž zarovnání bloků oddílu OS s bloky logické jednotky úložiště. Situace je znázorněna na obrázku 4.3. Z historického hlediska jsou OS prezentovány informace o logické geometrii jednotky, kterou by měl OS použít pro efektivní rozdělení a naformátování disku. V dnešní době je však geometrie virtuální a neodpovídá fyzickému popisu [55] disku, a tak tyto informace nelze použít. Některé nástroje, jmenovitě ty používané pro rozdělení disku v OS Windows založených na verzi 2003 a nižších, však mají předpoklady pro zarovnání diskového oddílu mimo hranice bloku. Toto zarovnání používá souborový systém pro ukládání dat a může dojít k situaci, že úložný subsystém bude pro čtení, či zápis potřebovat přečíst 2krát více bloků, než ve skutečnosti potřebuje OS. Tato situace je znázorněna na obrázku 4.4. V rámci Hyper-V je však třeba uvážit i virtuální pevné disky, v takovém případě přibude ještě jedna úroveň, viz obrázek 4.5. Obrázek 4.4: Souborový systém hostitele není zarovnán s bloky diskového pole. Pro přečtení jednoho bloku v rámci hostitele je nutné přečíst 2 bloky v rámci diskového pole. [55] Od verze OS Windows 2008 probíhá ve výchozím nastavení (a při použití MBR) zarov- 68

76 4.3. METODIKA TESTOVÁNÍ A KONFIGURAČNÍ PRVKY Obrázek 4.5: Souborový systém hostitele ani hostovaného OS není zarovnán s bloky diskového pole [55] nání diskových oddílů na velikost 1 MB, což je obvykle dostačující pro libovolnou velikost bloku. Pro ověření správného zarovnání stačí použit nástroj msinfo32 a v sekci Components > Storage > Disks najít hodnotu partition starting offset. Vzhledem ke způsobu, jakým jsou v hostitelském Hyper-V systému zvětšovány VHD soubory dynamických a diferenciální disků, je jejich zarovnání problematické [55]. Pokud je v rámci optimalizace přistoupeno k zarovnání, je nutné použít fixní virtuální disky. Souborové systémy obvykle organizují disk pomocí alokačních jednotek (klastrů), které reprezentují nejmenší množství prostoru pro uložení souboru v rámci disku (fakticky velikost bloku). Čím větší je alokační jednotka, tím menší je režie potřebná pro zpracování souborů. Nevýhodou velkých alokačních jednotek je neefektivní využití místa, například je-li velikost alokační jednotky 64 KB a soubor obsahuje pouze 1 KB dat, bude stejně obsazeno 64 KB diskového prostoru. V OS Windows je výchozí alokační jednotka 4 KB (pro disky do velikosti 16 TB). Nastavení alokační jednotky na stejnou velikost jako je velikost I/O požadavků může pozitivně ovlivnit výkon úložného subsystému. Tyto optimalizace jsou však pro dynamické prostředí poněkud nevhodné, dojde-li totiž ke změně velikosti I/O požadavků, je nutné změnit příliš mnoho částí, coř navíc většinou nelze provést bez formátování. Proto je jednodušší používat násobně větší velikost bloku, než je velikost I/O požadavků, a tím minimalizovat množství zbytečných I/O operací, které je pro obsloužení požadavků nutno provést i na špatně zarovnaných discích (či virtuálních dynamických discích). 69

77 4.3. METODIKA TESTOVÁNÍ A KONFIGURAČNÍ PRVKY Konfigurace vyrovnávací paměti Vyrovnávací pamět umožňuje skrýt rozdíly v různých rychlostech komunikace mezi subsystémy, což v případě toho nejpomalejšího, kterým úložiště bezesporu je, může ovlivnit celkový výkon. Různých vyrovnávacích pamětí je však celá řada a lze je nalézt nejen jako SW implementaci v OS, ale v každém adaptéru, procesoru, diskovém řadiči i disku samotném. Vyrovnávací pamět řadičů obou diskových polí je sdílena jak pro čtení, tak zápis. Společnými konfiguračními rysy obou diskových řadičů jsou: Volba mezi write-back a write-through metodou zápisu pro jednotlivé LUN. Pokud je řadič nastaven pro použití metody write-back, oznámí serveru vykonání I/O požadavku na zápis ihned po jeho přijetí a uložení do vyrovnávací paměti. Vyrovnávací pamět je synchronizována mezi oběma řadiči z důvodu zajištění vysoké dostupnosti v případě výpadku jednoho z nich. Synchronizaci lze vypnout, a tím dosáhnout většího výkonu za cenu možné ztráty dat. Metoda write-throught oznámí serveru vykonání I/O požadavku na zápis až v momentě, kdy jsou data skutečně uložena na discích. Ačkoliv je obvykle metoda zápisu write-back rychlejší, je potřeba vzít v úvahu i situace, jako je sekvenční zápis či zahlcení diskového pole I/O požadavky na zápis. V takových případech může být write-through metoda rychlejší. Povolení/zakázání vyrovnávací paměti pro čtení. V momentě kdy jsou data z disků přečtena a odeslána serveru, mohou být umístěna do vyrovnávací paměti. Požadavek na stejná data je následně uspokojen z vyrovnávací paměti. Pokud je známo, že se data opakovaně nečtou, lze vypnutím této funkce uvolnit pamět ový prostor pro jiné účely. Načítání dat v předstihu do vyrovnávací paměti (dynamic read prefetch, readahead-cache). Načítání dat v předstihu umožňuje do vyrovnávací paměti řadiče umístit více dat, než bylo požadováno I/O operací. Předpokládá se totiž, že další I/O operace může tato data použít, což je pravda zejména u sekvenčního čtení. V případě pole DS3512 je množství dat načítaných v předstihu konfigurováno automaticky, na základě analýzy zpracovaných I/O požadavků, pro pole MSA2012fc je možné zvolit velikost načítaných dat z nabídky 64, 128, 256, nebo 512 KB a 1, 2, 4, 8, 16, nebo 32 MB. K načítání v předstihu dochází u MSA2012fc po zpracování dvou po sobě jdoucích bloků, u pole DS3512 se mi nepodařilo používaný algoritmus zjistit. U obou polí lze načítání zcela vypnout. Pro pole DS3512 lze konfigurovat velikost bloku, která se použije pro segmentování vyrovnávací paměti. To při správném nastavení umožní minimalizaci počtu I/O operací vyrovnávací paměti a zároveň efektivní využití prostoru paměti. Nastavení se vztahuje pro celé diskové pole a ovlivní všechny logické jednotky. Čím menší je velikost bloku vyrovnávací paměti, tím lepší je využití prostoru. Na druhou stranu čím více je bloků, tím více I/O operací je potřeba k jejich zpracování. Pro sekvenční I/O požadavky je doporučována větší velikost bloku vyrovnávací paměti, zatímco pro náhodné menší. 70

78 4.3. METODIKA TESTOVÁNÍ A KONFIGURAČNÍ PRVKY Mezi další konfigurovatelné prvky s vlivem na výkon úložného subsystému lze zařadit spoj serveru a diskového úložiště, např. iscsi, SAS, FC nebo FCoE. Diagnostika jednotlivých sítí pro úložiště však může být značně náročná a vzhledem k použité technologii testovacího prostředí, tj. přímé propojení, ji netřeba výrazně uvažovat. Ke zpomalení tak může docházet jen v HBA kartách serverů, použitých kabelech či diskovém poli. V případě HBA karet může mít značný vliv použitá verze ovladačů, firmware a další nastavení adaptéru, jako je například velikost současně zpracovávaných diskových požadavků (queue depth), případně i algoritmus, jakým jsou mezi jednotlivé spoje serveru a diskového pole směřovány požadavky (MPIO Multi Path I/O). U pole MSA2012fc je specifické použití propojení hostitelských portů řadičů (host port interconnect), které umožňuje prezentovat logické jednotky pomocí obou diskových řadičů zároveň. Přesněji, port 0 jednoho řadiče je spojen pomocí interního přepínače s portem 1 druhého řadiče. V případě selhání jednoho ze spojů mezi serverem a řadičem tak nedojde k výpadku. Deaktivace této vlastnosti však může zlepšit výkon úložného subsystému Testovací scénáře pro prostředí výuky předmětu PV175 Ke srovnání vlivu jednotlivých optimalizací na testovací prostředí byly stanoveny následující testovací scénáře. Pro účely výuky předmětu PV175 na FI MU jsem na základě půlročního monitorování provozu hostitelského systému vyhodnotil situace, kdy docházelo z pohledu studentů a učitelů ke zpomalení virtuálních počítačů. V záznamech korelovalo hlášení o zpomalení s intervaly s vysokou dobou potřebnou ke zpracování I/O požadavku (až na 100ms) a vysokou frontou (až 300) čekajících I/O požadavků na zpracování. V situacích s násobně menšími hodnotami těchto ukazatelů nebyla patrná žádná zpomalení. Problémy byly způsobeny vysokou mírou zápisu a čtení do stránkovacích souborů jednotlivých virtuálních počítačů. Což nebylo nečekané, protože 600 MB operační paměti, jež bylo virtuálním počítačům přiděleno, bylo po otevření několik nástrojů pro správu okamžitě obsazeno. K tomuto efektu docházelo primárně na seminářích, kde více studentů pracovalo s virtuálními počítači současně. Protože měl server v té době jen 128 GB RAM a počet současně spuštěných virtuálních počítačů byl pevně stanoven (počet studentů), nebylo možné přidělit virtuálním počítačům více operační paměti. Ačkoliv by se v tomto prostředí dalo s výhodou využít funkce dynamické změny velikosti operační paměti za běhu (Dynamic Memory), nebyla příslušná verze Hyper-V ještě k dispozici. Server byl proto na konci roku 2010 rozšířen o dalších 128 GB RAM paměti na celkovou kapacitu 256GB RAM pro umožnění současného běhu více virtuálního počítačů. Jakmile byla velikost operační paměti virtuálním počítačům zvětšena, k zápisu a čtení do stránkovacího souboru docházelo minimálně. Nárůst celkového počtu množství virtuálních počítačů však způsobil zpomalení přístupu k úložišti. Srovnání vlivů různých konfigurací diskového subsystému je proto logickým krokem k další optimalizaci provozu. Otestovány byly následující konfigurace: RAID 10 a RAID 5 při počtu 16 disků. 71

79 Velikost bloku LUN: 64 a 32KB METODIKA TESTOVÁNÍ A KONFIGURAČNÍ PRVKY Velikost alokační jednotky v hostitelském systému, kde jsou uloženy virtuální disky: 64 a 4KB. Velikost alokační jednotky v hostovaném systému: 64, 32, 16, 8 a 4KB. Použití dynamických a fixních virtuálních disků. Write-back a write-through nastavení vyrovnávací paměti. Read-ahead-cache nastavení vyrovnávací paměti: 128 a 512 KB, 2MB, maximum a deaktivované. Použití různých strategií MPIO pro rozložení zátěže mezi více diskových adaptérů. Vliv nastavení host port interconnect. V hostitelském systému bylo vždy spuštěno 110 (kvůli omezené diskové kapacitě) virtuálních testovacích počítačů s OS Windows 7 Enterprise x64 s 1 GB RAM, 1 virtuálním procesorem a 1 syntetickým virtuálním sít ovým adaptérem. Pro simulování zátěže jsem vytvořil jednoduchý skript v PowerShellu, který je uložen v souboru perf.ps1 a je přiložen na CD. Skript v rámci jedné iterace spustil několik programů používaných pro správu OS, v nichž se studenti často pohybují, dále provedl zkopírování několika souborů a vytvoření 30 adresářů, pro které změnil nastavení NTFS oprávnění. Jedním z posledních kroků skriptu bylo vytvoření několika uživatelských skupin a přiřazení uživatelů do těchto skupin. Na závěr iterace byly smazány vytvořené adresáře, soubory, uživatelé a skupiny a ukončily se spuštěné nástroje pro správu. Tato iterace se opakovala po dobu 5 minut s náhodnou přestávkou v délce 1 až 20 sekund. Skript byl vždy opakovaně spouštěn na 55 a pak na 110 virtuálních počítačích. Běh každého testu byl zaznamenán pomocí integrovaných nástrojů pro monitorování ve Windows a následně analyzován již zmíněným nástrojem PAL ve verzi Zároveň byly zaznamenány statistiky, které o zatížení poskytuje webové rozhraní diskového pole. V každém testu byla provedena nejvýše jedna změna konfigurace. Virtuální počítače byly mezi změnami restartovány, každý první běh skriptu generujícího zátěž vykazoval horší výsledky než opakovaný, to přisuzuji vlivu vyrovnávací paměti uvnitř virtuálního počítače. Testy byly opakovány 2krát. Hned v prvním testu, který zachycoval výchozí stav po zapnutí virtuálních počítačů, byla patrná velká disková aktivita prakticky každého virtuálního počítače. Ačkoliv tato aktivita zhruba po 2 až 3 hodinách ustala, bylo by zbytečné před každým spuštěním testu čekat, než se disková aktivita počítačů ustálí. Při bližším zkoumání jsem identifikoval několik programů, které tuto aktivitu způsobovaly, a proto byla konfigurace virtuálních počítačů upravena následovně: Zakázání spouštění služby Search indexování obsahu disku. 72

80 4.3. METODIKA TESTOVÁNÍ A KONFIGURAČNÍ PRVKY Zakázání spouštění služby Defender kontrola počítače na přítomnost malware. Zakázání spouštění služby SuperFetch načítání dat do vyrovnávací paměti v předstihu. Zakázání spouštění služby Windows update aktualizace systému, periodická kontrola. Zakázání spouštění služby Volume Shadow Copy tvorba automatických bodů obnovení a minulých verzí souboru. Vypnutí automatické defragmentace disku defragmentace probíhá každou středu. Takto upravené virtuální počítače vykazovaly po spuštění minimální diskovou aktivitu. Zároveň nepředstavuje vypnutí služeb z hlediska výuky daných předmětů problém, a lze jej proto aplikovat i v normální výuce, kde je jakékoliv snížení počtu diskových operací vítaným prvkem Výsledky testů pro prostředí výuky předmětu PV175 Následující obrázky prezentují naměřené údaje, v záhlaví je vždy uvedeno, k jaké konfiguraci se údaje vztahují formou písmena a čísla, kde písmena odpovídají: R varianta RAID. B velikost bloku (KB). H velikost alokační jednotky systému hostitele (KB). G velikost alokační jednotky hostovaného systému (KB). Obrázek 4.6: Vliv počtu virtuálních počítačů se spuštěným skriptem generujícím zátěž Jen minimální vliv dvojnásobného počtu počítačů, viz 4.6, přisuzuji relativně nenáročnému skriptu, který simuloval ve virtuálních počítačích zátěž. Většina I/O požadavků tak 73

81 4.3. METODIKA TESTOVÁNÍ A KONFIGURAČNÍ PRVKY Obrázek 4.7: Vliv nastavení write-back a write-throught vyrovnávací paměti mohla být uspokojena ve vyrovnávací paměti diskového pole. To potvrzuje i vliv měření write-back a write-through, jak lze spatřit na obrázku 4.7, ve kterém je patrný nárůst zpoždění při deaktivované vyrovnávací paměti pro zápis. Skript generující zátěž však odpovídal typu i množství zátěže, se kterým je možné se při běžném provozu setkat. Obrázek 4.8: Vliv nastavení načítání dat v předstihu do vyrovnávací paměti Výsleky měření pro načítání dat v předstihu do vyrovnávací paměti (read-ahead-cache) jsou zobrazeny na obrázku 4.8, rozdíl mezi výchozím nastavením a vypnutým načítáním je jen drobný. Pravděpodobně k aktivaci načítání dat v předstihu docházelo jen v omezené míře. V případě různých MPIO strategií byly k porovnání zvoleny 3 metody. Doposud používaná Round Robin, která rovnoměrně rozděluje požadavky na všechna dostupná spojení s diskovým polem. Dále pak Round Robin with subset, která rozděluje požadavky na všechna optimalizovaná spojení, přičemž záleží na použitém MPIO ovladači, který opti- 74

82 4.3. METODIKA TESTOVÁNÍ A KONFIGURAČNÍ PRVKY Obrázek 4.9: Vliv různých algoritmů pro nastavení MPIO (Multi Path I/O) malizovaná spojení specifikuje. A konečně třetí zvolená metoda Least queue depth rozděluje požadavky na základě nejmenšího počtu nevyřízených I/O požadavků jednotlivých spojení. Výsledky jsou zobrazeny na obrázku 4.9, je z nich patrné, že nastavení Round Robin with subset není pro toto prostředí vhodné. Obrázek 4.10: Vliv nastavení host port interconnect Vliv nastavení host port interconnect je zobrazen na obrázku Dynamický virtuální disk vykazoval lepší výkonnostní parametry než fixní virtuální disk, viz obrázek 4.11, což lze přisoudit mnohem menšímu diskovému prostoru, který dynamické virtuální disky obsadily. Zatímco fixní disky využily téměř celý fyzický diskový prostor, dynamické využily zhruba 30 %, a proto je při jejich použití přístupová doba menší. Čím více se budou dynamické disky zvětšovat, tím větší bude pravděpodobnost, že dojde ke zpomalení minimálně na úroveň fixních disků, pravděpodobně však více. Vliv velikosti alokační jednotky v rámci hostovaného systému je zobrazen na obrázcích 4.12 a Rozdíly byly jen drobné. Se změnou velikosti alokační jednotky v rámci hostova- 75

83 4.3. METODIKA TESTOVÁNÍ A KONFIGURAČNÍ PRVKY Obrázek 4.11: Vliv použití dynamických a fixních virtuálních disků Obrázek 4.12: Vliv velikosti alokační jednotky disku hostovaného systému v RAID 10 ného systému souvisela i změna využití diskového prostoru hostovaných systémů, ta je zobrazena na obrázku Pozoruhodný je však negativní dopad velikosti alokační jednotky při nastavení vyrovnávací paměti do režimu write-throught, viz obrázek To naznačuje, že použití menší alokační jednotky bude v případě zahlcení pole těmito požadavky vhodnější varianta, protože data budou rychleji zapsána na fyzické disky (vyrovnávací pamět bude v době zahlcení plná). Z grafu 4.16 plyne, že malá alokační jednotka v rámci hostitelského systému způsobuje nezávisle na velikosti alokační jednotky hostovaného systému a variantě RAID pomalejší odezvu. Tento jev byl patrný i v druhém testovacím prostředí a odpovídá obecnému doporučení používat větší alokační jednotku pro práci s velkými soubory. V případě použití varianty RAID 5 pro konfiguraci diskového pole byly výsledky obecně horší, ačkoliv se počet aktivních disků zvětšil (oproti 8 v RAID 10 na 15 v RAID 5). Vzhledem k převaze zápisu a malé velikosti I/O požadavků však nemohl být tento potenciál plně 76

84 4.3. METODIKA TESTOVÁNÍ A KONFIGURAČNÍ PRVKY Obrázek 4.13: Vliv velikosti alokační jednotky disku hostovaného systému v RAID 5 Obrázek 4.14: Využití diskového prostoru instalací OS Windows 7 Enterprise v závislosti na velikosti alokační jednotky hostovaného systému využit. Velikost pruhu byla 960 KB, což se jako velikost I/O požadavku neobjevuje příliš často, a proto se běžně pro vytvoření varianty RAID 5 používá lichý počet disků. Nicméně, největší zaznamenaná velikost I/O požadavku na zápis byla 128 KB a medián byl 12 KB, pro teoretickou optimalizaci zápisu do RAID 5 by proto bylo potřeba použít menší počet disků s menší velikostí bloku. Menší velikost bloku měla negativní vliv z pohledu výkonu na měřené ukazatele pro libovolnou velikost alokační jednotky hostovaného systému. Výsledky měření jsou zobrazeny na obrázku Jako vhodnou konfiguraci pro provoz virtuálních počítačů na FI MU pro účely výuky předmětu PV175 a PV176 (za stávajících podmínek) doporučuji následující: Používat dynamický nebo diferenciální virtuální disk pro virtuální počítače. 77

85 4.3. METODIKA TESTOVÁNÍ A KONFIGURAČNÍ PRVKY Obrázek 4.15: Vliv velikosti alokační jednotky hostovaného systému při aktivním writethrought režimu vyrovnávací paměti diskového pole Obrázek 4.16: Porovnání různých variant RAID při různých velikostech alokační jednotky hostitelského systému Vypnout Read-ahead-cache nastavení vyrovnávací paměti diskového pole. Zvolit MPIO strategii Least queue depth. Velikost bloku ponechat na 64KB, RAID 10. Ponechat stávající velikost alokační jednotky hostitele na 64KB a hostovaného systému 4KB. Používat upravené konfigurace OS s vypnutými službami. Vliv takto upraveného prostředí lze oproti původnímu porovnat na obrázku Zároveň bylo takto nastavené prostředí použito pro výuku předmětu PV176 v semestru jaro

86 4.3. METODIKA TESTOVÁNÍ A KONFIGURAČNÍ PRVKY Obrázek 4.17: Vliv velikosti bloku a alokační jednotky hostovaného systému a umožnilo bezproblémový (z pohledu výkonu) provoz až 200 virtuálních počítačů zároveň pro výuku studentů. Dalšího zvýšení počtu provozovaných virtuálních počítačů lze dosáhnout použitím Dynamic Memory (což vyžaduje instalaci SP1 do OS) a sloučením vyhrazené jednotky v rámci diskového pole, která je momentálně využívána pro hostovaní individuálních počítačů (využívá se jen minimálně). Alternativně použitím RAID 5, což může vyžadovat ověření rychlosti reakcí uvnitř virtuálního počítače. Vzhledem k tomu, že lze vytvořit RAID 10 jen ze 16 disků, bude nutné v případě sloučení vytvořit více LUN a jednotlivé virtuální počítače mezi ně rovnoměrně distribuovat. Alternativně lze vytvořit dvě stejně velké LUN a spojit je v rámci OS Windows do jednoho oddílu pomocí dynamických disků (neplést s dynamickými virtuálními disky VHD), které umožňují vytvořit softwarový RAID 0. V takovém případě budou požadavky rovnoměrně rozdělovány (po 64 KB blocích) na obě LUN a potencionálně na oba diskové řadiče. Provedená měření poukázala na vhodné i vyloženě nevhodné možnosti konfigurace. Ačkoliv byla výsledná konfigurace jen nepatrně změněna od té původní, bylo možné provozovat více virtuálních počítačů (především díky přechodu na dynamické virtuální disky) najednou jen s minimálními dopady na výkon. Dalším požadovaným testem bylo zjištění vlivu NUMA architektury na provoz velkého množství počítačů s OS Windows 7. Kromě již popsaného principu fungování a možných následků v Hyper-V, bylo původně zamýšleno spustit všechny virtuální počítače na jednom NUMA uzlu a zkoumat vliv na běžné používání OS. V rámci Hyper-V ale není možné spustit virtuální počítač, pokud je pevně přiřazen do nějakého NUMA uzlu a tento uzel nemá dostatek lokální paměti. Operační pamět z jiného uzlu je přidělena jen v případě, že virtuální počítač není do žádného uzlu pevně přirazen. V případě kdy není pevně přiřazen, rozhoduje hypervizor, který ale distribuuje virtuální počítače rovnoměrně. To znemožnilo 79

87 4.3. METODIKA TESTOVÁNÍ A KONFIGURAČNÍ PRVKY ověřit původně zamýšlenou testovací variantu, která spuštění více počítačů v rámci jednoho uzlu předpokládala. Obrázek 4.18: Porovnání ukazatelů výkonu v původním nastavení a optimalizované konfiguraci Každý NUMA uzel má v rámci testovaného systému k dispozici 32GB RAM (8 procesorů, 256GB RAM celkem), spustil jsem proto na hostiteli 248 virtuálních počítačů s 1GB RAM. Virtuální počítače se rozdělily mezi uzly rovnoměrně a v rámci každého NUMA uzlu zbývalo k alokaci 1GB operační paměti. Pokud byl v tento okamžik spuštěn virtuální počítač s 2GB RAM, trvala alokace paměti 4 minuty (stav virtuálního počítače starting ). Tímto způsobem se mi podařilo docílit spuštění virtuálního počítače s operační paměti ze dvou NUMA uzlů. Z čistě subjektivního pohledu jsem nepozoroval žádný rozdíl v odezvě systému používal jsem tento systém jeden semestr pro výuku předmětu PV Testovací scénáře pro prostředí Exchange ový server Exchange 2010 je možné provozovat v celé řadě různých konfigurací a sestává z několika víceméně samostatných komponent. Testována byla komponenta, která má běžně největší požadavky na výkon úložného subsystému, a to Mailbox server, v němž jsou uloženy a zpracovávány y uživatelů. Tato komponenta byla testována ve virtuálním počítači s 1 virtuálním procesorem a 8GB RAM s OS Windows Server 2008 R2. Pro testování a měření výkonu jsem postupoval podle oficiální dokumentace [21]. Využil jsem při tom nástroj JetStress ve verzi , který je pro účely testování Mailbox serveru speciálně určený. Nejprve však bylo nutné odhadnout patřičné velikosti a nastavení databázových souborů. K výpočtu jsem použil oficiální dokument v programu Excel nazvaný Mailbox Role Calculator ve verzi 14.1, který na základě požadované konfigurace vypočítá vhodné rozmístění a předpokládané velikosti databázových souborů. Použité hodnoty pro výpočet jsou uloženy v dokumentu na přiloženém CD v souboru s názvem Exchange_calculator.xlsx. Vstupem pro výpočet byly i statistické údaje ze stávajícího ového serveru, jako je počet přijatých a odeslaných ů za den či průměrná 80

88 4.3. METODIKA TESTOVÁNÍ A KONFIGURAČNÍ PRVKY velikost ů. Tyto údaje byly zjištěny pomocí nástroje Microsoft Exchange Server Profile Analyzer ve verzi Na základě doporučení z dokumentu jsem vytvořil dva 200GB fixní VHD disky (dynamické VHD disky nejsou podporovány, tudíž je nemělo smysl testovat), do kterých byly vygenerovány nástrojem JetStress ové databáze o velikosti 164GB a transakční logy. Otestovány byly následující konfigurace: RAID 10 a RAID 5 při počtu 4 disků, použity byly 300GB RPM a 2TB 7200 RPM disky. Velikost bloku LUN: 64KB, 128KB a 256KB. Velikost alokační jednotky oddílu v hostitelském systému, kde jsou uloženy virtuální disky: 64, 16 a 4 KB. Velikost alokační jednotky v hostovaném systému: 64, 16 a 4KB. Write-back, write-through a dynamic read nastavení vyrovnávací paměti. Velikosti bloku vyrovnávací paměti 4, 8, 16 a 32KB. Použití nástroje Virsto One je popsáno v samostatné části. MPIO nebylo zařazeno do testovacích scénářů, protože způsob připojení serveru k diskovému poli neumožňuje využít jiný režim než failover, kdy je využito jen jedno spojení a pokud selže, použije se druhé. Nastavení nástroje JetStress proběhlo v souladu s doporučením a pro fyzické 300GB disky byla určena hodnota 5 vláken a pro 2TB disky 2 vlákna. Čím více je vláken, tím větší je generovaná zátěž. Jejich počet se určuje metodou pokusu a omylu, přesněji začne se na nějaké hodnotě a ta se zvětšuje (respektive zmenšuje) do té doby, než je test vyhodnocen jako neúspěšný (respektive úspěšný). Kritérium pro úspěch je dosažení průměrné hodnoty zpoždění při čtení databáze nejvýše 20ms a při zápisu do transakčního logu nejvýše 10ms. Druhým kritériem, které nevyhodnocuje nástroj automaticky, je odhadované potřebné množství I/O požadavků. Toto množství je výstupem dokumentu a bylo stanoveno na 5 I/O operací za sekundu pro jednu databázi a celkově na 11 pro celé prostředí. Je patrné, že tyto požadavky jsou skutečně minimální, nicméně vycházejí z naměřeného profilu stávajícího využití ových služeb a odhadovaného růstu v nejbližších 2 letech. Vzhledem k velké kapacitě databází, potažmo virtuálních disků, bylo potřeba použít alespoň čtyři 300GB disky ve variantě RAID 10, ačkoliv výkonově by dostačovalo použití 1 disku. Doba běhu testu byla stanovena na 20 minut, i když obvyklá doba je 2 hodiny diskové pole nevykazovalo žádné rozdíly v 20 minutovém ani 24 hodinovém testu. Výstup z měření generuje nástroj JetStress a tyto hodnoty jsou prezentovány dále. Monitorování testu bylo dále zajištěno pomocí integrovaných nástrojů v rámci hostitelského systému a vyhodnoceno nástrojem PAL. Data zjištěna oběma způsoby se však shodovala. 81

89 Výsledky testů pro prostředí Exchange METODIKA TESTOVÁNÍ A KONFIGURAČNÍ PRVKY Systém zkratek a značení grafů v záhlaví byl rozšířen o následující: Avg. Disk sec/read Průměrná doba v ms potřebná pro vykonání I/O požadavku čtení v databázi. Avg. Disk sec/write Průměrná doba v ms potřebná pro vykonání I/O požadavku zápisu do databáze. Obrázek 4.19: Vliv nastavení vyrovnávací paměti Obrázek 4.20: Vliv nastavení vyrovnávací paměti Vypnutí načítání do vyrovnávací paměti v předstihu 4.19 a 4.20 mělo pozitivní vliv na výkon. Nicméně v některých případech (údržba a kontrola) používá aplikace Exchange 2010 sekvenční přístup k databázi a logům, a v takovém případě bude přístup s vypnutým načítáním v předstihu pravděpodobně pomalejší. Pozitivní vliv velikosti bloku vyrovnávací paměti byl patrný i v ostatních testovaných konfiguracích RAID i alokačních jednotek viz Je však třeba upozornit na fakt, že velikost bloku je globální nastavení a ovlivní celé diskové pole. Vzhledem k tomu, že pro uspokojení požadavků aplikace v daném prostředí stačí násobně menší výkon, doporučuji zvolit velikost bloku tak, aby vyhovovala aplikaci, která vyžaduje nejvíce výkonu. Nejlepší výsledky jak pro 2TB, tak pro 300GB disky jsou patrné pro nastavení s blokem o velikost 256KB a totožnou velikostí alokační jednotky, tj. 64KB, viz obrázek Což koreluje s oficiálním doporučením. Považuji za důležité upozornit na fakt, že je třeba srovnávat 82

90 4.3. METODIKA TESTOVÁNÍ A KONFIGURAČNÍ PRVKY Obrázek 4.21: Vliv velikosti bloku vyrovnávací paměti jak počet provedených I/O požadavků, tak průměrnou dobu přístupu. V zásadě lze říci, že je možné vyměnit přístupovou dobu za větší počet I/O operací a naopak. Zároveň lze pozorovat stejný trend jak pro 300GB, tak pro 2TB disky s téměř jedinou výjimkou, a to v případě shodných 64KB alokačních jednotek, což lze přisoudit chybě měření. V případě varianty RAID 5 jsou při některých konfiguracích vidět stejné výkyvy v měření, jako v případě varianty RAID 10, viz Shodný je i nejlepší výsledek. Je tedy zřejmé, že některé varianty jsou pro provoz Exchange serveru v požadované konfiguraci vyloženě nevhodné. Pokud by byla použita výchozí varianta všech nastavení (OS Windows a diskového pole), byl by výsledek druhý nejhorší, a to jistě není pozitivní zpráva. Srovnání nejlepších variant lze nalézt na obrázku Vzhledem k naprosto minimálním nárokům provozované aplikace, doporučuji nevyhrazovat RAID skupiny jenom pro tuto aplikaci, ale umístit příslušné virtuální disky spolu s ostatními virtuálními počítači. Samostatné vyhrazení diskového prostoru znamená v případě čtyřech 300GB disků až 60násobnou rezervu oproti předpokládané zátěži. Namísto výkonu považuji za vhodnější se zaměřit na kapacitu. Ve výpočtu bylo uvažováno se zhruba 2GB na jednoho uživatele, což je v době, kdy existují služby zdarma, jako je Gmail (pro firmy Google Apps) s kapacitou 7GB, poměrně málo. 83

91 4.3. METODIKA TESTOVÁNÍ A KONFIGURAČNÍ PRVKY Obrázek 4.22: Srovnání nejlepších variant z jednotlivých kategorií 84

92 4.3. METODIKA TESTOVÁNÍ A KONFIGURAČNÍ PRVKY Obrázek 4.23: Vliv velikostí alokačních jednotek, disků a bloků 85

93 4.3. METODIKA TESTOVÁNÍ A KONFIGURAČNÍ PRVKY Obrázek 4.24: Vliv velikostí alokačních jednotek, disků a bloků 86

94 Použití nástroje Virsto One pro Exchange 4.3. METODIKA TESTOVÁNÍ A KONFIGURAČNÍ PRVKY Posledním provedeným testem bylo otestování nástroje Virsto One ve verzi 1_3_33_10101 pro Exchange konfiguraci. Nástroj používá vlastní souborový systém, který pomocí NTFS filtru prezentuje virtuální disky v systému Virsto (označované jako vdisk) jako klasické fixní virtuální disky (VHD soubory). S VHD soubory pak Hyper-V pracuje nativním způsobem. Pro použití jsou vyžadovány 2 logické jednotky. Na jednu je umístěn log (žurnál), do kterého jsou zaznamenány veškeré I/O požadavky na zápis. Log je následně v konfigurovatelných intervalech analyzován a data jsou přesouvána do hlavního úložiště druhé logické jednotky. Záznam I/O požadavků na zápis je prováděn do logu sekvenčně (tedy podobně, jako je žurnál v relačních databázích), a potencionálně tak dochází ke snížení doby potřebné pro vykonání požadavků. Přesun dat do hlavního úložiště je následně optimalizován tak, aby se provedl co nejrychleji [56]. Celá situace je znázorněna na obrázku Obrázek 4.25: Způsob použití hlavního úložiště a logu v nástroji Virsto One [56] Detailní popis principů jakým Virsto ukládá a přistupuje k datům je nad rámec této práce a lze jej nalézt v patentu US 2010/ A1. Pro otestování jsem se rozhodl použít stejný počet disků, aby mohl být výsledek srovnatelný s předchozím měřením. Umístění obou logických jednotek do stejné RAID skupiny (stejné fyzické disky) způsobilo snížení výkonu, viz To ale bylo vzhledem k popsané funkcionalitě očekávané. Varianta s použitím 3 disků jako hlavního úložiště v RAID 5 a 1 disku pro log byla nejlepší dosažitelná konfigurace pro Virsto One v porovnání s klasickým přístupem. Výsledky tohoto testu jsou zobrazeny na obrázku Na rozdíl od klasického přístupu by ale v případě selhání disku použitého pro log došlo ke ztrátě dat. Srovnání však není zcela korektní, protože měl klasický systém k dispozici jen 3 disky, zatímco Virsto fakticky 4. 87