Využití virtualizace pro malé a střední firmy

Transkript

1 Bankovní institut vysoká škola Praha Katedra Informatiky a kvantitativních metod Využití virtualizace pro malé a střední firmy Diplomová práce Autor: Bc. Petr Hejda Informační technologie a management Vedoucí práce: Ing. Martin Uher Praha Duben, 2015

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

3 Velice děkuji vedoucímu mé diplomové práce Ing. Martinu Uhrovi za cenné rady a čas, který mé práci věnoval. Můj dík patří také mé rodině za poskytnutou podporu, toleranci, trpělivost a tvrdý dohled, a také společnosti, ve které pracuji, ţe mi dovolila nahlídnout do některých poţadovaných materiálů Bc. Petr Hejda

4 Anotace Diplomová práce se zabývá představením virtualizace, jednotlivých nejvíce rozšířených technologií virtualizace, analýzou a návrhem virtualizačního prostředí pro potřeby běţných malých a středních IT firem a v konečné fázi také ekonomickým zhodnocením celého návrhu oproti realizaci na fyzickém HW. První část práce je především věnována obecnému představení tématu virtualizace, jednotlivých nejrozšířenějších technologií a obecným principům při implementaci v reálném prostředí. Druhá část obsahuje konkrétní návrh virtualizačního prostředí pro vyuţití v prostředí malých a větších firem, včetně testů a instalačních pracovních postupů. Obsahem pro třetí část je především finanční vyhodnocení přínosu virtualizačního prostředí oproti vyuţití fyzického HW. Klíčová slova: virtualizace, VMware, vsphere, ESXi, CentOS, Citrix, Xen Annotation The thesis covers the preview of virtualization as a topic, shows the most known virtualization technologies, also analysis and design of virtualization environment for common small or medium large IT companies. Final part will be economic comparison of whole virtualization design despite of physical hardware. The first part is primarily introducing virtualization as a topic, available technologies and common principals during implementation in real environment. The second part includes specific design of virtual environment including test and installation guides. Content of the final part is financial evaluation of virtual environment dispite of using physical hardware machines. Key words: virtualization, VMware, vsphere, ESXi, CentOS, Citrix, Xen

5 Obsah Úvod Současné poţadavky na ICT Běţné potřeby malé a střední firmy současnosti na IT Úvod do virtualizace Obecně o virtualizaci Typy virtualizací a jejich moţnosti Plná virtualizace Paravirtualizace Virtualizace na úrovni operačního systému Emulace Typy virtualizačních platforem VirtualBox KVM Citrix Xen Microsoft VMware Typy virtualizací Virtualizace serverů Virtualizace aplikací Virtualizace klientských stanic Virtualizace sítí Virtualizace úložišť Vysoká dostupnost a migrace za běhu Zálohování Návrh a testy řešení

6 3.1 Testování virtualizačních platforem Testovací software Test procesoru - CPU benchmark Test paměti - Memory benchmark Test disku Drive benchmark Test webového serveru Apache benchmark Test databázového serveru Database benchmark Popis testovacího prostředí Nastavení prostředí, výsledky a vyhodnocení testů Výběr virtualizační platformy Návrh řešení virtuálního prostředí Postup instalace řešení Instalace hostitelského serveru Vytvoření virtuálních strojů Instalace virtualizační platformy Finanční zhodnocení řešení Závěr Seznam pouţité literatury Seznam pouţitých zkratek Seznam obrázků Seznam tabulek

7 Úvod Cílem této práce je představit fenomén virtualizace jako celek, jednotlivé virtualizační moţnosti a nejpouţívanější komerční, ale i open-source technologie a jejich přiblíţení čtenáři. Nicméně hlavním cílem je především otestování virtualizačních platforem a navrhnutí efektivního virtualizačního prostředí, vzhledem k potřebám a současným poţadavkům na ICT běţných malých a středních firem, s výsledným finančním zhodnocením oproti postavení stejného prostředí na fyzické infrastruktuře, jak bylo do současnosti víceméně běţné řešení. Téma virtualizace se stalo v poslední době bezesporu fenoménem a v prostředí IT se s ním v dnešní době setkáváme prakticky na kaţdém kroku. Jeho největší výhodou je především úspora nákladů, technických prostředků a neméně výrazné sníţení potřeby zdrojů pro správu a následné provozování celé firemní infrastruktury. Virtualizace není v současné době ovšem pouze o virtualizování serverové infrastruktury, ale důleţitým tématem se postupně stalo také virtualizování koncových pracovních stanic firemních zaměstnanců, či dokonce jednotlivých aplikací. To ovšem nejsou konečné moţnosti, neboť existuje i celé řada dalších oblastí, kde nalézá virtualizace také své uplatnění, jako jsou například virtualizace sítí, jednotlivých úloţišť, nebo i celých datacenter. Během mé práce v oboru informatiky se s virtualizací setkávám velmi často a nejde pouze o podpůrné systémy, ale jednotlivé virtualizační platformy jiţ pokročili do takové úrovně, ţe jsou na nich provozovány i zákaznické kritické systémy přímo spjaté s firemními obchodními cíli. V následujícím textu se budu věnovat především nejznámějším a nejpouţívanějším virtualizačním platformám, z nichţ pro následný návrh prostředí a vytvoření instalačních pracovních postupů zvolím právě jednu. V první kapitole práce se budu soustředit na shrnutí současných poţadavků kladených na ICT sluţby z globálního hlediska, ale především se zaměřením na malé a střední firmy. Druhá kapitola bude slouţit jako představení tématu virtualizace jako celku. Zaměřím se jak na historický vývoj, tak na jednotlivé moţnosti a popíši především praktiky v jednotlivých oblastech virtualizace. Detailněji se zde budu také věnovat jednotlivým nejznámějším všeobecně vyuţívaným virtualizačním platformám a jejich představení. Budu se rovněţ 7

8 zabývat tématem přechodu na virtualizaci a moţných rizik a bezpečnostních otázek s tím spojených. V třetí kapitole se budu nejdříve zabývat výběrem virtualizační platformy a jeho odůvodněním, ale také konkrétním návrhem virtuálního prostředí firmy včetně otestování. Ve čtvrté kapitole popíši instalační postupy pro vytvoření navrţené virtualizované infrastruktury a v poslední kapitole zhodnotím finanční přínos pouţití virtualizačních technologií v navrţeném firemním prostředí oproti běţným současným řešením. Shrnu především moţnosti úspor nákladů za provoz a efektivitu vyuţití technických prostředků. Z důvodu zpřehlednění celé práce jsem v kapitole obsahující výsledky testování a v části věnující se popisu postupu instalace navrţeného řešení, vynechal číslování obrázků. Pro všechny tyto obrázky totiţ platí, ţe jsou vytvořeny autorem jako snímek obrazovky jednotlivých aplikací. 8

9 1. Současné požadavky na ICT 1.1 Běžné potřeby malé a střední firmy současnosti na IT Mění se pracovní svět. Rostou poţadavky na mobilitu, pruţnost a produktivitu společností i jejich zaměstnanců. V mnoha odvětvích schází kvalifikovaný personál. Konkurenceschopnost společností tak stále více závisí na tom, jestli se jim podaří přilákat nejtalentovanější pracovníky. Ţivot bez smartphonů a tabletů si uţ asi nedovedeme představit. Zvykli jsme si najít pro kaţdou úlohu správnou aplikaci a rádi vyuţíváme přístup k aplikacím a datům z kaţdého zařízení a v kteroukoli dobu. Data ukládáme do cloudu a podle potřeby je sdílíme online s přáteli a rodinou. Společnosti jsou nuceny reagovat na nové trendy. Především jim jde o zabezpečení dat a zachování souladu, ale důleţitá je i konkurenceschopnost v boji o talenty. Tím se zvyšuje tlak na oddělení IT společnosti, které potřebuje konstruktivní přístup a novou strategii práce koncových uţivatelů s počítači. Oddělené produkty ale problém neřeší, protoţe zvyšují náklady i celkovou sloţitost, která můţe dosáhnout stupně, kdy se vymyká jakékoli kontrole. Moderní pracovní stanice nejsou jen stolní nebo přenosné počítače. Je nutné podporovat všechna nová zařízení, jako jsou smartphony a tablety. Je nutné zajistit těmto zařízením odkudkoli nepřetrţitý přístup k podnikovým aplikacím a datům. Bezpečný a kontrolovaný přístup dokáţe zajistit jedině podnikové oddělení IT nebo vybraný poskytovatel sluţeb. S výše uvedeným souvisí i v dnešní době neustále skloňovaný výraz Next Generation Workspace, tedy jakési pracoviště budoucnosti. Existuje mnoho definic tohoto pojmu, ale o co vlastně jde? Problematika pracoviště budoucnosti zahrnuje v podstatě jakési tři klíčové oblasti. Mladší zaměstnanci v dnešní době povaţují za samozřejmost vyřizovat jak pracovní, tak nejlépe i soukromé záleţitosti z jednoho a to ještě nejlépe mobilního zařízení. První z klíčových oblastí je tedy umoţnění práce na vlastním zařízení, na které je pracovník zvyklý a většinou si ho i sám vybral. Tomuto konceptu se odborně nazývá BYOD. Zkratka vychází z anglického pojmu Bring your own device, tedy přines si své zařízení. Princip problematiky BYOD je sice funkčně jednoduchý, na společnost ale v konečném důsledku klade bezpečnostní a organizační poţadavky se kterými je třeba počítat a rozhodně se nedají 9

10 podcenit, nebo provést pouze s části. Jde totiţ, v konečném důsledku, o ochranu jak pracovníků, kteří vyuţívají svá soukromá zařízení k práci, tak i společnosti samé. Druhou oblastí je samotné pracovní místo zaměstnance. Nejde zde jiţ pouze jen o příjemné a ergonomické prostředí, ale především spíše o jeho dynamičnost. Dnešní flexibilní pracovníci potřebují, aby jejich pracovní prostředí co nejméně zasahovalo do konečného výkonu práce, ale bylo především účelné. Efektivní zaměstnanec v dnešní uspěchané společnosti musí, v konečném důsledku, mít moţnost pracovat bez překáţek odkudkoli. Například i z domova, tedy tzv. koncept Home office. Třetí, poslední, ale klíčovou oblastí jsou moderní technologie. Tvoří vlastně takový spojovací článek, bez kterého by se nepodařilo všechny oblasti úspěšně spojit. Jde zde jak o technologie podporující komunikaci, jako například různé videokonference, chaty, ale také o technologie, které umoţní zaměstnanci efektivní práci na svém vlastním virtuálním pracovním prostředí a pomocí aplikací, které dobře zná a dokáţe pomocí nich bezproblémově dojít k cíli. Mezi takové technologie bezesporu patří virtualizace pracovního prostředí a firemních aplikací, jejíţ nasazení a zprovoznění je předmětem této práce. 10

11 2. Úvod do virtualizace 2.1 Obecně o virtualizaci První myšlenky zabývající se moţným vyuţitím virtualizačních technologií odstartovaly reálnými krůčky pomocí plánů na vytvoření a umoţnění plné virtualizace počítačů na platformě x86. [1] Virtualizace byl pokrok především v tom, ţe umoţňovala lepší vyuţití výpočetní síly dostupných serverů a tím také dopomáhala organizacím k výraznému sníţení potřeby koupě fyzických serverů, coţ v konečném důsledku vede i ke sníţení vstupních a provozních nákladů vloţených do budování a provozování IT infrastruktury. Tudíţ se virtualizace okamţitě stala standardem při plánování infrastruktury v prostředí IT organizací, se kterým je dobré jiţ od počátku počítat. Výrazné ekonomické a konkurenční prostředí firem v současné době nutí velice se soustředit na sníţení provozních nákladů a plnění mnohdy dosti striktních rozpočtových plánů. Díky tomu začalo mnoho IT organizací přemýšlet a uskutečňovat projekty zabývající se plánem na virtualizaci svých serverů, a tím optimalizaci nákladů spojených s jejich provozem. [2] Jak se virtualizační technologie rozvíjely a zdokonalovali, začalo se také uvaţovat o pokročilejších virtualizačních funkcionalitách, a to řešení vysoké dostupnosti zpravovaných prostředků a alokování zdrojů, které jednotlivé aplikace potřebují jen přesně v daný okamţik kdy je jiţ potřeba, a tím umoţnit pokročilou optimalizaci zátěţe. [3] Díky těmto pokročilým funkcím se postoupilo od implementace virtualizace v malých měřítcích aţ k virtualizaci důleţitých pro obchod mnohdy kritických aplikací. Tyto aplikace jsou zpravidla velmi vyuţívané, potřebují mnoho zdrojů napříč organizací a v neposlední řadě jsou na ně kladeny vysoké nároky na dostupnost. Kaţdý okamţik, kdy nejsou koncoví uţivatelé (zaměstnanci organizace) schopni s jejich pomocí vykonávat kaţdodenní a pro organizaci nezbytnou činnost, dochází zpravidla k velkým finančním ztrátám. Z toho důvodu se virtualizaci kladou čím dál více stále vyšší nároky na spolehlivost, funkčnost a vysokou dostupnost. Vše tedy započalo myšlenkou virtualizace serverů, ale jak vývoj pokročil, začalo se o virtualizaci uvaţovat jiţ téměř ve všech částech IT infrastruktury. Vedle virtualizace serverů 11

12 se tedy začalo i s virtualizací uloţišť, síťových prostředků, ale také třeba koncových uţivatelských stanic. [4] Na trh s virtualizací začalo vstupovat stále více a více nových vývojových firem, coţ začalo mít dopad na rapidní vývoj cenových politik virtualizačních hypervizorských systémů. Trh se začal také více formovat. Někteří výrobci se soustředili pouze na organizace patřící do velkých hráčů na trhu, ale objevili se i tací, kteří se s velkým úspěchem prosadili také v oblasti malých a středních firem. Přijímání virtualizace jednotlivými organizacemi tedy začalo nezastavitelných tempem stoupat, nicméně penetrace této technologie napříč všemi organizacemi je stále na dosti nízké úrovni a trh je pro tuto technologii tedy ještě relativně nenasycený. [5] Jedním z mnoha důvodů můţe být také například to, ţe mnoho organizací vyuţívá virtualizačních technologií na stále docela malé části své IT infrastruktury a zdaleka tak nevyuţívá jejího plného potenciálu. Z pohledu rozsahu organizací se také většinou liší způsob nasazování virtualizačních technologií. Zatímco velké organizace zpravidla postupují po menších částech, od méně důleţitých prvků své infrastruktury, aţ k těm kritickým, malé organizace mají většinou postup svéráznější a z pohledu své infrastruktury udělají spíše rázný krok k virtualizaci. Tento postup je logicky dán také moţnostmi odlišných typů těchto organizací. Rozsah IT prostředí v malé a střední organizaci bývá omezený a tyto organizace si tak většinou klidně mohou dovolit vystavět virtualizovanou architekturu paralelně s tou stávající, nebo začínají rovnou s implementací virtualizované architektury namísto budování fyzického hardwaru. Na druhou stranu velké organizace, nebo chceme-li korporace, si takový přístup nemohou vzhledem ke sloţitosti a poţadavkům kladených na stávající infrastrukturu dovolit. Postup je zde tedy z velké části vţdy do velké míry testován a prováděn s velkou obezřetností. Další důvod je bezesporu také to, ţe kdyţ se tyto velké organizace dostávali na trh, tak zpravidla virtualizační technologie ještě neexistovaly, nebo byly ještě u svých počátků a nikdo o nich při návrhu prostředí ani neuvaţoval. Nicméně co se týče úspor, je virtualizace pro velké firmy s mnoha IT prostředky určitě z ekonomického hlediska velké lákadlo. [6] Ţivotní cyklus virtualizačních technologií je ale zatím stále na svém počátku a výrobci těchto technologií stále usilují o to, aby jednou byl výsledek takový, ţe bude moţné virtualizovat kompletně celou IT infrastrukturu beze zbytku. Virtualizační technologie vedou k velké míře automatizace IT prostředí a daly tak prostor k poloţení základních stavebních kamenů pro IT sluţby a prostředky nabízené přes Internet 12

13 jako měřené sluţby ve veřejném, či privátním cloudu. Vzhledem k tomu, ţe zatím neexistuje jeden odsouhlasený termín, který by definoval termín cloud jako takový, nápad za ním je takový, ţe jde vlastně o IT sluţby, které jsou měřitelnou formou nabízené skrz Internet, ovšem s omezenými závazky na obou stranách, tedy jak poskytovatele, tak konzumenta, co se kvality sluţeb a poplatků za ně vynaloţené týče. [7] Cloud computing je tedy definován sdíleným, nebo soukromým prostředím, které je do velké míry škálovatelné a to jak směrem dolů, tak směrem nahoru, (uţivatel si můţe určit rozsah zdrojů nebo výpočetní výkon, který bude reálně vyuţívat) coţ zaručí jeho velikou míru flexibility. Organizace se tedy mohou svobodně rozhodnout, jestli chtějí své pro obchod kritické aplikace pouţít vlastní privátní cloud, nebo některý z veřejně dostupných externích cloudových prostředí nabízených třetími stranami. Privátním cloudem je v tomto smyslu míněna IT infrastruktura, která je vlastněna a provozována přímo danou organizací a umoţňuje tedy této organizaci mít přímou správu a kontrolu nad svým prostředím. Takto provozovaný cloud je ještě zpravidla dobře zabezpečen a umístěn za firewallem organizace, coţ dává organizaci dobrý přehled o jeho zabezpečení. Tyto přímé implementace jsou také označované jako on-premis. Na druhou stranu veřejný cloud je datacentrum vlastněné externí organizací, která je označována jako poskytovatel cloudových sluţeb, a nabízí IT sluţby široké veřejnosti, nebo velkým korporátním firmám. Veřejný cloud je tedy sdílené prostředí, které můţe být vyuţívané mnoha organizacemi, a kde za tyto sluţby organizace platí jen do míry prostředků, které opravdu reálně vyuţívají. Na základě potřeby tedy mohou být vyuţívané prostředky uměle navyšovány, nebo poniţovány. [7] Současně s privátními a veřejnými cloudovými prostředími do určité míry existují ještě takzvané hybridní prostředí, které kombinují výhody obou předešlých dedikovaných řešení. Tedy, ţe kritická infrastruktura firmy je zpravidla spravována organizací napřímo s pomocí interních prostředků a zbývající infrastruktura, která neovlivňuje přímo kritické obchodní aktivity organizace je zpravidla přesunuta do externího cloudového prostředí a prostředky potřebné na její provoz jsou nakupovány. Jakým způsobem si lze představit hybridní cloud je názorně zobrazeno na následující m obrázku. 13

14 Obrázek 1: Názorné schéma hybridního cloudového prostředí (Zdroj: autor) Nicméně úspěšné provozování opravdu velkých virtualizačních prostředí umoţňující hostování sluţeb pro externí zákazníky je co do rozsahu a náročnosti opravdu velmi komplexní problém a pro úspěšné zvládnutí této problematiky je potřeba zvládnout a vyřešit mnoho komplikovaných problémů. Jelikoţ pracuji pro společnost, mezi jejíţ globální hlavní obchodní cíle patří budování velkých datových a zákaznických center, mohu komplexnost a náročnost na případné know-how sledovat na denní bázi. V současné době nicméně existují jiţ i úspěšní globální poskytovatelé cloudových sluţeb, jako jsou Google nebo Amazon. Google například úspěšně provozuje cloudovou sluţbu App Engine, která umoţňuje koncovým uţivatelům provozovat své webové aplikace na IT infrastruktuře spravované Googlem. Nicméně společností snaţících se uplatnit a stát se lídrem v oblasti virtualizovaných cloudových sluţeb se v současné chvíli objevuje mnoho a jejich cesta není určitě jednoduchá. [8] V oblasti virtualizace je bezesporu ještě mnohé co zdokonalovat. Většina lídrů mezi výrobci se v poslední době soustředí především na zdokonalení svých produktů v oblasti jednoduchého managementu jejich řešení, či na rozvoj schopností virtualizačních technologií. [1] 14

15 2.2 Typy virtualizací a jejich možnosti V následující kapitole se zaměřím především na jednotlivé typy moţných virtualizačních technik a jejich bliţší specifikaci Plná virtualizace Při vyuţití tohoto typu virtualizace docílíme důsledné virtualizace všech součástí počítače a vytvoříme takové prostředí, které prakticky znemoţňuje běţícímu operačnímu systému poznat, ţe nemá přímý přístup k hardwarovému vybavení fyzického serveru. Tudíţ nepotřebuje operační systém nebo programy instalované na virtualizovaném počítači ţádné modifikace. Je to tedy ideální stav, kdy jsme úplně oddělili fyzickou vrstvu (hardware) a vytvořili novou, která umoţňuje vyuţívat virtuální hardware, který přístup na ten fyzický a skutečný pouze zprostředkovává. [14] Obrázek 2: Plná virtualizace (Zdroj: autor) Je zde samozřejmě řada výhod. Hlavní je především ta, ţe si můţeme takto vzniklý virtuální stroj navrhnout podle našich představ, nebo poţadavků. Můţeme si tedy zvolit přesně kolik operační paměti stroji přidělíme, jaký bude typ procesoru, nebo také typ a cílovou kapacitu pevného disku. Programy instalované na takto vytvořený stroj jsou rovněţ nezávislé na konkrétním vybavení a obejdeme se tak s problémy způsobenými jejich změnou. Další 15

16 výhodou je také neexistující vazba mezi virtuálním prostředím a konkrétním hardwarem, na němţ je virtuální stroj provozován. Můţeme tedy tento virtuální stroj migrovat dle potřeb i mezi virtualizačními prostředími, kde není shodné jejich hardwarové vybavení. Mezi profesionální systémy, které podporují plnou virtualizaci a se kterými se běţně během své praxe setkávám, jsou například VMware ESXi server nebo Microsoft Virtual server Paravirtualizace Plná virtualizace je samozřejmě výhodná a má své právoplatné zastoupení. Ale dokonce i s vytvořeným virtuálním strojem, který je, co se hardwaru týče, věrnou kopií stroje na kterém virtualizovaný server běţí, prakticky nemoţné dosáhnout plného potenciálního výkonu. Paravirtualizací se myslí postup, kdy umoţňujeme virtuálnímu stroji komunikovat přes modifikovaný operační systém s některým typem hardwarových komponent napřímo, bez nutnosti vytváření vrstvy virtualizovaného hardwaru. Pro takovýto způsob virtualizace jsou samozřejmě přívětivě vyuţitelné především open source operační systémy, jako například Linux, neboť je jejich kód veřejně dostupný, a tudíţ i otevřený pro modifikaci kýmkoliv. [14] U Paravirtualizace je tedy jako základní předpoklad skutečnost, ţe minimálně některé systémové zdroje se budou shodovat jak pro hostovaný, tak pro hostující systém. Není pak úplně nezbytné kaţdou instrukci překládat, jako je to nutné při vyuţití plné virtualizace, ale je umoţněno některým instrukcím přímo přistupovat k potřebnému systémovému prostředku. Například ale instrukce, které by mohli modifikovat, smazat, nebo číst data z jiného systému, je potřeba mít pod dohledem a případně zakazovat jejich přístup, nebo provádění. Pro paravirtualizaci byl zaveden specifický model tzv. model 4 kruhů, kde kaţdý z těchto kruhů má svá určitá práva. Nejvyšší práva má hypervisor, neboli hostující stroj, který se stará o ty instrukce, které si ţádají přístup k privilegované části. Ostatní instrukce jiţ běţí přímo na hardwaru. Další úroveň je určena pro jádro hostovaného operačního systému. Následující úroveň je nevyuţita a v posledním kruhu, který zároveň disponuje nejniţšími oprávněními, běţí koncové uţivatelské aplikace. K lepšímu pochopení principu Paravirtualizace jsem vytvořil následující přehledové schéma. [14] 16

17 Obrázek 3: Schéma paravirtualizované architektury (Zdroj: autor) Ovšem největší limitací paravirtualizace je právě fakt, ţe hostovaný operační systém musí být modifikován, kvůli čemuţ nelze pouţít jakékoliv operační systémy a před jejich pouţitím je vţdy třeba ověřit jejich kompatibilitu a případná omezení, která mohou nastat Virtualizace na úrovni operačního systému Tento typ virtualizace je odvozen od fungování standartní linuxové funkce chroot, která má na starost změnu kořenové sloţky volajícího procesu na specifikovanou cestu. [12] Funkce funguje tak, ţe původní kořenová sloţka OS se pro volající proces a jeho sub procesy stane nedostupnou a jako kořenová se pro tento proces stane nová specifikovaná sloţka. Proces ani nemá moţnost se z této sloţky posunout o úroveň výše. (Dokonce se o existenci vyšší úrovně ani nedozví) Hostovaný systém, který je nazývaný kontejner, tedy této funkce vyuţívá a běţí v souborovém systému hostitelského systému odděleně. Oddělení ale nemusí být zcela úplné. Typicky některé společné zdroje, jako například knihovny, mohou být sdíleny do souborového systému hostovaného virtuálního stroje, coţ vede zároveň ke sníţení nároku na fyzický adresní prostor a v některých případech i ke zjednodušení aktualizace těchto sdílených zdrojů. Ač se zdá, ţe je toto sdílení zdrojů výhodné, je tomu tak pouze za předpokladu, ţe se aktualizací neporuší kompatibilita některé z aplikací, která tyto zdroje vyuţívá ke svému běhu. 17

18 Rychlost tohoto typu virtualizace se jiţ blíţí rychlosti operačního systému běţícího na fyzickém hardwaru bez pouţití virtualizace. Díky nízké reţii lze tuto metodu doporučit i v případě, ţe má na fyzickém stroji fungovat pouze jeden operační systém. Výhodou je především snadné zálohování kompletního funkčního systému a jeho následné moţné přesunutí na jiný fyzický stroj. Za velkou nevýhodu se můţe naopak povaţovat fakt, ţe metoda pouţívá sdílení zdrojů a především třeba jádra hostujícího operačního systému. Jako důsledek v případě přerušení běhu jádra nějakou fatální chybou, je pád všech hostovaných operačních systémů. [13] Emulace V případě emulace dochází k simulování veškerého hardwaru nebo softwaru. Lze tak pomocí této metody pouštět aplikace, které jsou určeny pro zcela odlišnou architekturu. Velké vyuţití tato metoda nalézá například při testování jednoduchých embedded systémů, nebo mobilních operačních systémů při pouţití standartních počítačových architektur typu x86, nebo x64. Emulace je také vyuţívána pro zpětnou kompatibilitu v případě pouţití aplikací, které jiţ nejsou aktivně vyvíjeny a vzhledem k rychlému tempu modernizace a optimalizace operačních systémů, nejsou jiţ podporovány a nemohou být na těchto systémech spuštěny. Jedním z nejznámějších emulátorů pro Linux operační systémy je například Wine, díky kterému je moţné na operačních systémech Linux pouštět i aplikace určené pro operační systém Windows. Při vyuţití emulace je ovšem nutné počítat s velkou reţií. Všechny instrukce, které bychom mohli vyuţívat na nativním stroji, musí být pro úspěšnou emulaci přepsány na jinou architekturu. Kaţdá architektura a zvláště pak procesor má odlišnou instrukční sadu, stavbu mezipaměti, registru, nebo obsluhu přerušení. Pokud tedy emulující architektura pokryje kompletně všechny, nebo alespoň většinu emulovaných instrukcí, dosahuje potom emulace vysoké efektivity. Ostatní instrukce, které nelze v emulátoru jednoduše implementovat se pak musí obcházet za pomocí vyuţití kombinace více instrukcí a vzrůstá tím také algoritmická sloţitost. 18

19 Obrázek 4: Emulace (Zdroj: autor) Základ emulace tedy není rozhodně efektivnost vyuţití fyzických prostředků pro více operačních systémů, ale moţnost zjednodušení kvůli kompatibilitě. Obrovskou nevýhodou ale zůstává velmi vysoké vyuţití výpočetního výkonu a to i vzhledem k optimalizacím, kdy se například jiţ některé jednou přeloţené úseky aplikace ukládají do paměti a nemusejí se tedy při příští potřebě pouţití znovu překládat. 2.3 Typy virtualizačních platforem VirtualBox VirtualBox je multiplatformní virtualizační software, který je od roku 2010 pod záštitou firmy Oracle, nicméně původně byl vytvořený společností Innotek, která byla posléze odkoupena společností Sun Microsystems. K instalaci Virtualboxu je potřeba mít jiţ nainstalovaný host operační systém, v rámci kterého bude VirtualBox spouštěn a umoţní pak instalací dalšího hostovaného OS, neboli guesta. Původní verze softwaru byla licencována, a tudíţ musel její uţivatel platit licenční poplatky. Výjimkou byl akorát případ, kdy chtěl uţivatel software vyuţívat pro osobní nekomerční účely. V takové případě bylo pouţití zdarma. Virtualbox je určený především k virtualizaci koncových uţivatelských stanic, tedy desktopů. Jako jedna z výhod, kterými se můţe produkt chlubit, je široká škála podporovaných operačních systémů, které mohou být pouţity pro vytvořený hostovaný počítač a jsou mezi nimi opravdu všechny běţné a v dnešní době nejrozšířenější OS. 19

20 20

21 Solaris Linux Mac OS X Windows Podporované operační systémy Typ OS Verze OS 32-bit 64-bit Windows XP X Windows Server X Windows Vista X X Windows Server 2008 X X Windows 7 X X Windows 8 X X Windows Server 2012 X 10.6 X X 10.7 X X 10.8 X 10.9 X Ubuntu X X Debian X X Oracle X X Redhat X X Fedora X X Gentoo X X OpenSUSE X X Mandriva X X 10 X X 11 Tabulka 1: Podporované operační systémy (Zdroj: [15]) Virtualbox také podporuje export virtuálních PC do formátu Open Virtualization Format (OVF), coţ je všeobecně uznaný standart určený k takovýmto účelům. Stejně tak jako export, tak Virtualbox umoţňuje i import a to dokonce virtuálních PC, které byly vytvořeny na jiné platformě. Podporuje také plnou hardwarovou virtualizaci a technologie hardwarové virtualizace společností Intel a AMD. [15] KVM KVM, neboli Kernel-based Virtual Machine je typ virtualizační platformy určený především Linux operační systémy, který vyuţívá jejich jádra pro vytvoření hypervisoru. Tato funkcionalita byla zařazena do hlavní řady Linux jádra verze od roku [16] KVM byl produkt vývoje firmy Qumranet, která byla zaloţena jako technologický startup. Později ale byla společnost odkoupena společností Redhat, která tak vzala virtualizační 21

22 technologii KVM pod svá křídla a postavila nad ní svůj komerční produkt RedHat Enterprise Virtualization. [17] Firma Red Hat tuto technologii kompletně začlenila do své Linuxové distribuce Red Hat Enterprise Linux, či případně je moţné ji vyuţít i v její zdarma odnoţi v podobě distribuce CentOS a udělala z ní kompletní virtualizační řešení pro virtualizace jak serverových, tak i koncových uţivatelských stanic. [17] Obrázek 5: Schéma virtualizačního řešení firmy Red Hat (Zdroj: [18]) Citrix Xen Xen byl původně zaloţen jako výzkumný projekt Cambridgeské university vedený docentem Ian Prattem, pozdějším zakladatelem společnosti XenSource, Inc., která nyní podporuje především vývoj OpenSource projektu Xen a také prodává Enterprise verze licencí. Vůbec první verze Xen byla uveřejněna v roce Později v roce 2007 společnost XenSource, Inc. Koupila společnost Citrix, která následně upravila všechny Xen produkty tak, aby nesly její značku. Xen je zaloţen na paravirtualizaci a podle toho také vypadá jeho struktura. Nejniţší vrstvou, ale zároveň vrstvou s největšími oprávněními a privilegovaným přístupem je Xen Hypervisor. Nad ním jsou poté jednotlivé hostované operační systémy tzv. Quest OS, kterým hypervizor 22

23 pomocí své logiky přiděluje přístup a výkon fyzického procesoru hostitelského stroje. Terminologie Xen nazývá tyto vrstvy svým vlastním způsobem. Po spuštění hostitelského fyzického stroje jako se jako první spouští operační systém hypervizorů a tato vrstva je nazývána jako doména dom0. Této doméně jsou automaticky přidělena všechna administrátorská práva a má také přímý přístup k veškerému fyzickému vybavení hostitelského stroje. Systémový administrátor pak můţe této domény vyuţívat ke správě všech ostatních hostovaných OS, které jsou zařazeny do podřízené domény tzv. domu. Obrázek 6: Schéma architektury Xen (Zdroj: [19]) Jako doména dom0 můţou být pouţity například upravené operační systémy typů Linux, Solaris nebo NetBSD. V doméně domu jsou podporovány opět téměř všechny varianty operačních systémů Linux, ale mohou zde běţet také operační systémy zaloţené na platformě Microsoft Windows a další patentově chráněné operační systémy. Jednou ze zajímavých funkcí Xen serveru, kterou je potřeba zmínit je podpora tzv. Live Migration, coţ je funkce umoţňující přesun virtuálních hostovaných strojů mezi hostitelskými fyzickými stroji po lokální síti a to dokonce bez výpadkově. Není to tedy úplně bez výpadku, je zde prodleva asi do 300ms, neţ dojde k aktivaci virtuálního stroje na záloţním umístění, ale pro koncového uţivatele je takto krátký interval zpravidla povaţován jako zanedbatelný. Funkce se chová podobně, jako běţná clusterová technologie pro vysokou dostupnost. Virtuální stroj existuje na obou umístěních a z místa, kde je virtuální stroj aktivní 23

24 se online kopíruje obsah jeho paměti do místa, kde je umístěna vypnutá záloţní kopie. V případě výpadku se tak vlastně záloţní virtuální stroj aktivuje s téměř aktuálním obsahem paměti dosud aktivního stroje. Společnost Citrix přistupuje k technologii Xen dvojím způsobem a tedy, ţe nabízí verzi jak pro profesionální komerční vyuţití, tedy produkt Xen Server, tak i pod licencí GPL (GNU General Public License), která umoţňuje volné šíření produktu a pouţití zdarma. Verze zdarma ovšem určitě není určena pro nasazení jako velká virtualizační komerční platforma, ale spíše pro nekomerční účely, nebo pro platformy určené pro virtualizaci nekritických systémů Microsoft Virtual PC Microsoft vstoupil do problematiky virtualizace poměrně nedávno, o tom v roce 2003, kdy zakoupil licence společnosti Connectix, která od roku 1996 vyvíjela vlastní produkt nazvaný Virtual PC. Virtual PC byl z počátku určený pro platformu Macintosh. První verze připravená pro systém na platformě Microsoft Windows byla aţ verze Virtual PC 4, která spatřila světlo světa v roce Connectix svůj produkt distribuoval především jako balík s jinými hostovanými OS, ať uţ Windows, nebo Red Hat Linux. Ke koupi společnosti Connectix přistoupil Microsoft převáţně z důvodu, ţe začal sledovat zvýšenou poptávku po virtualizaci a začal si postupně uvědomovat její obrovský potenciál. V roce 2006 vydala společnost Microsoft pro svůj operační systém zdarma verzi produktu Virtual PC 2004 SP1. Pro ostatní konkurenční platformy byl tento produkt placený. Dalším důleţitým milníkem ve vývoji produktu Virtual PC byl rok 2007, kdy se vydala první verze určená pouze pro Windows platformy, ale podporující jiţ plnou hardwarovou virtualizaci Virtual Server Virtual Server od společnosti Microsoft je řešení, které umoţňuje především provoz virtuálních počítačů s operačními systémy Windows XP, Windows Vista a Windows Server Původně byl, stejně jako Virtual PC zmiňovaný výše, vyvinut společností Connectix a právě i z tohoto produktu také vychází. 24

25 Jedná se nicméně o mnohem propracovanější nástroj, který především umoţňuje vytváření a správu virtuálních storojů buď přes webové rozhraní vyuţívající webového serveru IIS dodávaného společně s operačním systémem společnosti Microsoft, nebo klientský nástroj v podobě Windows aplikace VMRCplux. Oba tyto přístupy umoţňují centralizovanou správu a jsou tedy vhodné pro pouţití spíše v komerční sféře v rámci větších virtualizačních platforem. Produkt také podporuje optimalizaci pro víceprocesorové prostředí, pokročilé zálohování vytvořených virtuálních strojů a samozřejmostí je i podpora Linuxových operačních systémů. Virtual Server byl nicméně nahrazen pokročilejším produktem Hyper-V Hyper-V Hyper-V virtualizační platforma Microsoftu pokrývá široké spektrum potřeb, od jednoduchých scénářů konsolidace serverů, aţ po vysoce výkonná, škálovatelná a samoobsluţná datová centra o stovkách a tisících serverů. Základní stavební kamenem této technologie je vrstva hypervisoru Hyper-V, který byl vyvinut v roce 2008 jako součást některých verzí operačního systému Windows Server Za krátko poté následovala další generace, která jiţ byla dostupná jako serverová role ve Windows Serveru 2008 R2, nebo jako samostatný produkt Micorsoft Hyper-V Server 2008 R2, který byl k dispozici zdarma. Funkcionality ještě doplnili technologie Dynamic Memory a RemoteFX, které byly integrovány do Service Packu 1 pro Windows Server 2008 R2. Následující, tedy jiţ třetí generace, je jiţ součástí nejnovějšího serverového operačního systému Windows Server 2012 R2, nebo klientské verze Windows 8.1 Pro a Enterprise. [21] V rámci Hyper-V jsou podporovány následující operační systémy: Windows Server od verze 2003 výše Windows Client od verze XP Professional SP2 výše SUSE Linux Enterprise Server verze 10 a 11 Oracle Linux 6.4 a vyšší Open SUSE 12.3 Red Hat Enterprise Linux verze 5.5 a vyšší CentOS Linux 5.5 a vyšší Ubuntu a vyšší 25

26 FreeBSD 8.2 Debian 7.0 a vyšší U výše zmíněných systémů je od společnosti Microsoft garantovaná technická podporu při řešení problémů s virtualizací. Nicméně to neznamená, ţe ostatní systémy, které v seznamu nejsou, nemohou na Hyper-V fungovat, ale ţe pro ně akorát Microsoft neposkytuje oficiální podporu. Seznam podporovaných OS se ale neustále vyvíjí, a tudíţ je dobré nahlíţet vţdy do aktuální verze dostupné zde Pokud je dostupný dostatečně dimenzovaný hardware, lze při vyuţití Windows Server 2008 R2 Hyper-V na jednom fyzickém serveru provozovat aţ 384 virtuálních strojů a pokud máme vytvořen Hyper-V cluster, tak aţ 1000 virtuálních strojů. Pokud navíc vyuţijeme nejnovější serverový OS od Microsoftu, lze dosáhnout ještě o něco lepších výsledků a to aţ 1000 virtuálních hostů na jednom hostiteli a v rámci clusteru dokonce 8000 hostů. [21] Virtualizace Microsoft udělala rozhodně velký mílový krok kupředu a díky pokročilým moţnostem dynamické správy paměti, odděleného síťového provozu a podpoře síťových úloţišť ji lze vyuţít jak při základní konsolidaci serverů v prostředí malé firmy, tak i pro vybudování komplexních datových center, coţ mohu potvrdit i z vlastní zkušenosti, protoţe v rámci práce na své pozici dodavatelských způsobem provozujeme u zákazníka sluţby monitoringu právě nad takovou architekturou virtualizační platformy VMware Společnost VMware je na trhu virtualizačních platforem vůbec jedním z nejstarších hráčů. Dalo by se tedy čekat, ţe budou, vzhledem k velikosti a stáří firmy, její produkty moţná začínat zastarávat a nebudou se drţet nejmodernějších trendů, jak tomu obvykle u společností, které jsou na trhu jiţ dlouhou dobu, většinou je. VMware je ale pravý opak. Nejen, ţe jeho produkty neztrácejí časem na lesku a nestačili by jít s dobou, VMware je po většinu svého působení na trhu virtualizace povaţován za největšího lídra a inovátora a z této pozice většinou i tvoří trendy ve virtualizaci, které se ostatní snaţí napodobovat, nebo se funkcionalitami alespoň přiblíţit k moţnostem VMwaru. Jako příklad mohu uvést svou vlastní praktickou zkušenost, jelikoţ jednou z náplní mé práce je analyzovat moţnosti nasazení a implementovat u zákazníků systém pro správu mobilních zařízení AirWatch. 26

27 Společnost VMware získala společnost AirWatch, čímţ rozšířila portfolio řešení pro práci koncových uţivatelů s počítači i nabídku mobilních řešení. Touto akvizicí získala společnost VMware vedoucí postavení v oblasti správy podnikových mobilních zařízení a mobilního zabezpečení. Ţádná jiná společnost nenabízí tolik komplexních podnikových řešení, určených pro desktopy, přenosné počítače, tablety a smartphony, a nástrojů na spolupráci na obsahu, které splňují poţadavky oddělení IT v éře mobilního cloudu. [10] VMware vsphere VMware vsphere je vlastně kompletní platforma určená především pro virtualizaci datových center. Produkt jako takový obsahuje mnoho komponent a nástrojů, jako například: ESXi hypervisor, který slouţí jako virtualizační vrstva, která je schopna odstínit hardware hostitelského počítače pro pouţití běţícími virtuálními stroji, Distributed Power management, který optimalizuje energetické nároky hostitelského stroje, vstorage Thin Provisioning, který dokáţe v případě potřeby dynamicky přidělovat diskovou kapacitu virtuálním serverům, vnetwork Switch, který slouţí k řízení virtuální síťové infrastruktury mezi virtuálními stroji, Store vmotion, který dokáţe migrovat vytvořené virtuální prostředky napříč úloţištěmi a tedy poskytnout plynulý chod virtuální infrastruktury, Hight Availability, který slouţí jako řešení pro efektivní způsob dostupnosti virtuálních zdrojů, pokud dojde k poruše nebo selhání systému, VMware vcenter Jedná se o platformu určenou pro správu virtuální infrastruktury postavené nad technologií VMware vsphere. Nabízí přehlednou a centralizovanou správu všech hostitelských i hostovaných strojů v rámci firemního IT prostředí. Slouţí především jako nástroj pro koncové administrátory, který jim umoţní zefektivnit a tedy i zlevnit správu celé virtuální infrastruktury. IT administrátoři mohou pro přístup a správu platformy vcenter vyuţívat buď klienta vsphere Client, jenţ je ve své podstatě aplikace určená pro operační systémy Microsoft Windows, nebo také tenkého klienta v podobě webového portálu vcenter Web Access. 27

28 2.4 Typy virtualizací Virtualizace serverů Podíváme-li se do historie operačních systémů, Microsoft a Linux začali být populární a akceptovány jako operační systém vhodný pro datacentra především v devadesátých letech dvacátého století. [1] Hlavní problémem operačního systému je především to, ţe aplikace na něm provozované mohou skončit s chybou a způsobit tak pád celého systému. Z toho důvodu začali administrátoři aplikovat filozofii jednoúčelových serverů, tedy ţe na jednom serveru poběţí pouze jedna aplikace, která je pro chod organizace důleţitá, aby se tím sníţilo riziko postiţení dalších kritických aplikací v důsledku jejího pádu. [1] Dalším důvodem byl také pohled bezpečnosti. Pokud se útočníkovi povede kompromitovat jeden ze serverů společnosti, ovlivní tím chod pouze jedné aplikace a dopad tohoto útoku bude pro společnost mírnější. Tento přístup ale vede k tomu, ţe společnost vlastní nemalé mnoţství serverů, jejichţ výpočetní výkon není zdaleka plně vyuţíván. [10] Tento problém řeší právě serverová virtualizace, kdy je vytvořeno několik virtuálních serverů, které jsou umístěny na jeden fyzický server a dojde tak k jeho optimálnímu vyuţití. Tomuto přístupu se také říká serverová konsolidace a její ilustrace je znázorněna na obrázku níţe. Obrázek 7: Serverová konsolidace (Zdroj: [10]) Serverová konsolidace je nejčastěji vyuţívána u serverů, které vyuţívají malého mnoţství svého výpočetního výkonu. Lze touto cestou zredukovat celkové mnoţství potřebných 28

29 fyzických serverů a tedy i ušetřit náklady spojené s jejich provozem. Je ale důleţité brát na zřetel, ţe kriticky důleţité aplikace pro obchod mohou vyuţívat velké mnoţství výpočetního výkonu a pokud by na hostitelském stroji bylo více takovýchto serverů s těmito aplikacemi, můţe dojít k vyčerpání výpočetních zdrojů a tedy i k degradaci výkonu provozovaných aplikací. Je tedy nutné dimenzovat řešení vţdy tak, aby měl hostitelský počítač vţdy dostatečné prostředky pro zvládnutí moţných výpočetních poţadavků ze strany hostovaných stanic Virtualizace aplikací V současné době dochází k významným změnám v poţadavcích firem na moderní pracovní prostředí. Tradiční model, tedy ţe firemní zaměstnanci pracují na korporátních zařízeních v prostředí své kanceláře, prochází dramatickými změnami směrem k poţadavkům koncových expertních zaměstnanců na mobilitu v jejich pracovních moţnostech a v konečném důsledku na umoţnění práce odkudkoliv a prakticky na jakémkoliv koncovém zařízení. S těmito poţadavky přicházejí také nové příleţitosti pro jejich řešení a tedy umoţnění práce ze soukromých zařízení zabezpečenou formou na firemních zdrojích. Jedním z těchto řešení je bezesporu virtualizace, která umoţňuje centralizaci firemních aplikací a pracovních stanic v datacentru firmy a jejich bezpečné doručení koncovým uţivatelům v případě potřeby prakticky kamkoli, kdykoli a na jakékoli zařízení. [10] Organizace dnes stále více virtualizují podnikové aplikace a platformy 1. vrstvy, jako jsou databáze, systémy ERP a CRM, ová řešení, nástroje na spolupráci, middleware Java, nebo například také aplikace Business Intelligence. Pokud IT organizace chtějí u aplikací 1. vrstvy ve virtuálním prostředí zajistit kvalitu sluţeb a dodrţování smluv SLA, musí se zaměřit nejen na virtualizované komponenty projektu, odolnou správu a monitorování virtualizovaných podnikových aplikací, ale také na dodrţování podnikových pokynů, které se týkají kontinuity činnosti a zotavení po havárii. Virtualizované aplikace nabízejí vyšší výkon a vyšší stupeň dostupnosti, zotavení po havárii, jsou rychlejší, pruţnější a jsou připravené na fungování v cloudu. [9] Stejně, jako je tomu u virtualizace serverů, kde virtualizace umoţní oddělení operačního systému od fyzického hardwaru, ale virtualizace aplikace odděluje aplikační spustitelné a konfigurační soubory a jejich závislosti od operačního systému. Kaţdá virtualizováná aplikace pak běţí ve svém vlastním prostředí, které zahrnuje záznamy registrů, knihovny a vše ostatní, co je vyţadováno k úspěšnému spuštění a provozování aplikace. Jelikoţ tedy 29

30 aplikace nepouţívá prostředky mimo své prostředí, dovoluje to takto virtualizované aplikace spouštět i na operačních systémech, pro které nebyla aplikace navrţena. Výhodné je také to, ţe jsou jednotlivé aplikace od sebe izolovány a tudíţ je výrazně sníţeno riziko jejich konfliktů na úrovni operačního systému. Díky tomuto oddělení také můţeme bok po boku pouštět různé verze té samé aplikace, coţ se můţe hodit nejenom pro vývojové účely a následné testování, ale také pro jednoduchý přechod mezi verzemi v případě potřeb kompatibility. [11] Organizace můţe mít při vyuţití technologie virtualizace aplikací jednoduchou moţnost centrální správy, kontroly a historie vyuţívání aplikací, coţ v konečném důsledku lze vyuţít při analýze ceny licencí na základě zvoleného modelu a jeho případné optimalizaci. Doručení virtuálních aplikací můţe být ještě zjednodušeno v případě vyuţití technologie nazývané ondemand Application streaming. Tato technologie umoţňuje doručovat pouze nezbytně potřebnou část virtualizované aplikace do klientského zařízení a zrychluje tedy spuštění a běh samotné aplikace. Jednotlivé přenesené části jsou rovněţ uloţeny v lokální dočasné paměti, aby nemuseli být znovu posílány. Největšími hráči na trhu virtualizace aplikací jsou podle celosvětově uznávaného průzkumu společnosti Gartner především Microsoft s produktem App-V, VMware s produktem ThinApp a také Citrix Xen se svým XenApp Virtualizace klientských stanic Zajišťování desktopů formou spravované sluţby umoţňuje rychleji reagovat na měnící se poţadavky a nové prodejní příleţitosti. Rychlé a snadné zajišťování virtuálních desktopů a aplikací pro pobočky, zaměstnance na externích nebo outsourcovaných místech a pro mobilní zaměstnance s tablety, sniţuje náklady a zvyšuje kvalitu sluţeb. Škálovatelné, konzistentní, bezpečné a široce dostupné řešení desktopů je zárukou maximální provozuschopnosti a produktivity. [10] Důleţitou a bezesporu obrovskou výhodou při virtualizaci klientských stanic je především jejich centralizovaný management, který se stává pro IT administrátory velmi uţitečným nástrojem. Umoţňuje jednoduché a rychlé vytváření virtuálních uţivatelských stanic a pracovních prostředí pro zaměstnance firmy a zahrnuje také důleţité bezpečnostní prvky. Například lze provést vzdálené uzamčení klientské stanice v případě, ţe by mohlo docházet k neautorizovanému přístupu, manipulaci, nebo spouštění závadných aplikací. [20] 30

31 Nejčastěji vyuţívanou technologií pro virtualizaci uţivatelských stanic je technologie nazývaná VDI, která rovněţ přináší více zabezpečení pro uţivatelská data a výhody centrálního správy. Třeba takto vytvořené stanice mohou být jednoduše centrálně aktualizovány proti nejnovějším bezpečnostním útokům a zranitelnostem operačního systému. Stanice jsou také okamţitě dostupné pro široku škálu koncových zařízení prakticky z jakéhokoliv místa na zemi, kde má koncový uţivatel přístup k internetu. Coţ dodává tomuto způsobu virtualizace pro uţivatele velkou míru volnosti. [20] Virtualizace klientských stanic sebou nese také problematiku ceny a licencování. Je zde prakticky stejný problém, jako v případě virtualizace aplikací a to ten, ţe je potřeba mít na paměti, ţe kaţdá virtuální klientská stanice musí být korektně licencována. Tudíţ pokud je jedinou motivací organizace pro přechod na virtuální klientské stanice ušetření nákladů, nemusí to být v tomto případě tak úplně pravda. Navíc vytvoření virtualizační platformy sebou také nese nemalé náklady na hardware, úloţiště a síťové prostředky Virtualizace sítí Virtualizace sítí je především krok ke kompletnímu nahrazení fyzické sítě pomocí softwaru. V dnešní době jiţ virtuální sítě nabízejí totoţné funkce jako sítě fyzické, ale mají navíc výhody hardwarové nezávislosti virtualizace, jako především rychlé vytváření, nenásilné nasazení a automatizovanou správu pomocí jednotného managementu. Virtualizované sítě mohou nabídnout připojovaným komponentám takové logické síťové zařízení a sluţby, které jsou běţně realizované i ve fyzických sítích a to například logické porty, přepínače, směrovače, brány, firewall, moduly pro inteligentní řízení zátěţe, VPN a další. Pomocí virtualizované sítě lze vytvořit vysoce adaptibilní síťovou topologii, která poskytuje koncovému uţivateli vyšší úroveň provozní efektivity a flexibility, rychlejší řešení potíţí díky moţnostem monitorování, ale také funkce jako zabezpečení, či klonování sítí. Neméně důleţitou výhodou síťové virtualizace je také fakt, ţe při ní výrazně redukujeme potřebu pouţití fyzických síťových zařízení, coţ vede v konečném důsledku také k nemalým finančním úsporám. 31

32 2.4.5 Virtualizace úloţišť Virtualizace úloţiště v podobě jeho definovaných vrstev nabízí lepší výkon a efektivnější vyuţití zdrojů, aniţ byste museli nakupovat další hardware pro úloţiště. Hardware musí umoţňovat rychlé zajišťování, aby bylo moţné nastavit efektivní a přiměřeně velké úloţiště stejně rychle jako samotné virtuální stroje. Virtuální úloţiště musí umoţňovat takový způsob správy, který je zaměřený na virtuální stroje a správci ho mohou intuitivně ovládat. Virtuální prostředí přinášejí správcům více úkolů. Proto je nutné, aby model správy bylo moţné integrovat do hypervizorové platformy a vyuţívat známé, nativní pracovní postupy. Virtualizace úloţiště je kombinací funkcí, které nabízejí abstraktní vrstvu zdrojů v podobě fyzických úloţišť. Fyzické disky jsou sloučeny do jednoho nebo více virtuálních úloţišť. Obvykle se jedná převáţně o disková pole, která jsou dostupná jednomu nebo více serverům v závislosti na tom, jestli budeme poţadovat například migraci zdrojů z jednoho hostitelského systému na druhý. Při zajišťování virtualizace jsou tyto úloţné zdroje vyhodnocovány, spravovány a optimalizovány. Správa úloţných zdrojů virtuální infrastruktury s vyuţitím virtualizačních technologií je mnohem efektivnější a přináší následující moţnosti: vyšší vyuţití zdrojů úloţiště a větší flexibilita, jednoduší opravy OS a menší poţadavky na ovladače bez ohledu na topologii úloţiště, větší provozuschopnost aplikací a zjednodušení rutinních procesů, optimální vyuţití a rozšíření stávající infrastruktury úloţišť. 2.5 Vysoká dostupnost a migrace za běhu Hypervizory jsou v dnešní době vybaveny mnoha technologiemi, které jsou závislé pouze na jednotlivých výrobcích. Avšak jsou zde běţné technologie, které jsou velice rozšířené a vyuţívané napříč virtualizačním portfoliem. Mezi tyto technologie bezesporu patří vysoká dostupnost, tedy Hight Availability (HA), nebo také technologie migrace za běhu, tedy Live migration. [23] Tyto názvy začaly být jako první pouţívány společností VMware, která s těmito technologiemi přišla na trh jako první. Jelikoţ se jak funkcionalita, tak názvy v praxi uchytily, začaly být pouţívány i v případě ostatních výrobců. HA, neboli vysoká dostupnost je technologie, která neustále monitoruje všechny virtuální stroje v rámci našeho tzv. virtuálního resource pool a snaţí se nalézt hardwarovou chybu. [1] Virtuální resource pool je skupina fyzických hostitelských serverů, 32

33 na kterých provozujeme hostované virtuální stroje. Pokud některý z fyzických serverů selţe, virtuální stroj je automaticky spuštěn na jiném dostupném fyzickém serveru. Názorná ukázka tohoto principu je naznačena na následujícím obrázku. Obrázek 8: Princip vysoké dostupnosti (Zdroj: [24]) Obrázek 8 zobrazuje tři fyzické servery, kde server B má poruchu a virtuální stroje B1 a B2, které na něm běţely, jsou migrovány a spouštěny na serverech A a C. Toho můţe být dosaţeno, protoţe jednotlivé virtuální stroje jsou umístěny v úloţišti Storage system, které je k fyzickým hostitelským serverům připojeno. Ovšem v závislosti, jak jsou v danou chvíli virtuální stroje B1 a B2 zrovna aktivně vyuţívány, můţe dojít v rámci tohoto přepnutí ke ztrátě některých dat. Současný stav virtuálního stroje totiţ není ukládán a na úloţišti existuje pouze čistá záloha jednotlivých virtuálních strojů. Nicméně tento problém řeší technologie zvaná fault tolerance (FT). FT jde v této problematice o krok dopředu a v případě výpadku startuje na záloţním fyzickém serveru identickou kopii daného virtuálního stroje. Jako výsledek zde není ţádná ztráta uţivatelských nebo systémových dat. Princip se nastíněn na následujícím obrázku. Obrázek 9: Princip technologie fault tolerance (Zdroj: [23]) 33

34 Další zmiňovaná technologie, tedy ţivá migrace, neboli live migration (LM) je technologie umoţňující přesun jednotlivých virtuálních strojů napříč různými fyzickými servery. Příklad LM je znázorněn na následujícím obrázku. Obrázek 10: Live migration (Zdroj: [23]) Obrázek 10 znázorňuje migraci virtuálního stroje A3 z fyzického serveru A na fyzický server B. K této migraci můţe být několik moţných důvodů. Například z důvodu, ţe server A začíná být velmi vytíţen a je tak třeba rovnoměrně rozdělit zátěţ, nebo také čistě pouze za účelem plánované odstávky serveru A. Zátěţ fyzického serveru je výpočetního výkonu, který fyzický server vynakládá v určitý čas. Jelikoţ je virtuální stroj hardwarově nezávislý, není závislý na umístění na konkrétním fyzickém serveru. Pomocí této technologie je tedy moţné balancovat zátěţ na jednotlivých fyzických serverech a zajistit tak, ţe kaţdý virtuální zdroj bude mít dostatečné mnoţství potřebných prostředků. [23] 2.6 Zálohování I přesto, ţe jsme ve své infrastruktuře pouţili technologie zmíněné v kapitole Vysoká dostupnost a migrace za běhu, můţe dojít k takové havárii, při které bude potřeba obnovit systém nebo jednotlivé virtuální stroje ze zálohy. Kaţdý virtuální, ale i fyzický server by tedy měl být pravidelně zálohován. Zálohování lze rozdělit do několika úrovní. Odděleně bychom měli dělat pravidelně zálohy hostitelského systému, neboli hypervizorů, zálohy jednotlivých virtuálních strojů, ale také operačního systému nebo aplikací, který jsou na nich provozovány. Ze své vlastní praxe vím, ţe je dobré provádět zálohování jednotlivých části virtualizované architektury pravidelně. Zálohování jednotlivých virtuálních strojů je dobré dělat na denní bázi a úplnou zálohu hostitelského systému na týdenní bázi, případně vyuţít rozdílového 34

35 zálohování. Zálohy by měli být prováděny do externího systému nebo úloţiště, abychom se vyhnuli jejich případné ztrátě. Rovněţ se musí myslet na to, ţe virtualizační proces vyţaduje určité a někdy ne zrovna malé vyuţití systémových prostředků a mohl by tedy ovlivnit i chod ostatních virtuálních strojů, které jsou provozovány v rámci stejného hostitelského systému. Stejně tak jako zálohování, tak neméně důleţité je také provádět testy obnovení systému ze záloh a sestavení plánu pro obnovu v případě havárie systému tzv. Disaster recovery plan. 35

36 3. Návrh a testy řešení 3.1 Testování virtualizačních platforem K testování jednotlivých virtualizačních prostředí pro rozhodnutí o volbě konečné virtualizační platformy pro cílové řešení jsem vybral jednoho z open-source lídrů v provádění automatizovaných testů a benchmarkingu a tedy Phoronix Test Suite verze Konkrétní virtualizační platformy, které podrobím testování, jsou: XEN Citrix Xen VMware Testovací software Phoronix Test Suite je zaloţen na rozsáhlém testování a interních nástrojích vyvíjených firmou Phoronix Media jiţ od roku 2004 se současnou podporou od lídrů na trhu v podobě výrobců hardwaru a softwaru. Tento program je open-source dostupný zdarma a šířený pod licencí GNU GPL. Software byl prvotně vyvinut pro automatizované testování Linuxových distribucí, ale od té doby byl rozvinut pro testování také nad dalšími platformami, jako jsou například Apple OS X, Microsoft Windows, BSD a operační systémy typu Solaris. Program vyuţívá odlehčené jádro zvané (pts-core) a kaţdý benchmark test je zaloţen na xml konfiguračním souboru a vyuţití potřebných skriptů. Postup od instalace frameworku po konečné provádění jednotlivých testů je velice automatizovaný a jednoduchý, vyţadující pouze uţivatelské potvrzení jednotlivých akcí. Phoronix Test Suite můţe být integrován s on-line databází výsledků, jednotlivých testových balíčků, pokročilých analytických nástrojů a jiných funkcionalit dostupných na stránkách OpenBenchmarking.com. Phoronix má ještě nespornou výhodu v dostupném pokročilém webovém uţivatelském rozhraní a moţností vzdáleného plánování jednotlivých testů. Instalace softwaru Phoronix se provádí pomocí následujícího postupu: 36

37 Krok 1. Stažení testovacího softwaru Phoronix phoronix-test-suite-<version>.tar.gz #wget #tar -xzvf phoronix-test-suite-<version>.tar.gz #cd phoronix-test-suite Krok 2. Spuštění instalačního skriptu #./install-sh Instalace jednotlivých testů nebo testovacích balíčků se provádí příkazem: #phoronix-test-suite install [Název testu Název balíčku] Spuštění samotného testu se provede příkazem: #phoronix-test-suite run [Název testu Název balíčku] Test procesoru - CPU benchmark Testy procesoru virtualizovaného serveru budu provádět pomocí několika testů z aktuálního testového balíčku pts/cpu softwaru Phoronix. Konkrétně se bude jednat o testy: Pts/encode-flac testuje dobu potřebnou pro enkódování wav souboru do flac formátu Pts/x264 test CPU při enkódování x264 H.264/AVC Pts/c-ray - raytracer navrţený pro testování výkonosti CPU při práci s plovoucí čárkou Test paměti - Memory benchmark Pro testování operační paměti virtuálního stroje běţícího na testované virtualizované platformě vyuţiji aktuální balík testů pts/memory softwaru Phoronix vytvořeného Michaelem Larabelem a navrţeného speciálně pro testování RAM. Balíček obsahuje testy pro testování jak výkonnosti, tak i propustnosti. Konkrétně: pts/stream testování výkonnosti operační paměti pts/cachebench testování výkonosti cache paměti 37

38 3.1.4 Test disku Drive benchmark K otestování IO operací disku virtuálního stroje vyuţiji existující aktuální balík pts/aio-stress určený pro I/O benchmark, který byl vytvořen vývojáři SuSE a vyuţívá 2048MB testovací soubory a velikost záznamu 64KB Test webového serveru Apache benchmark Pro testování webového serveru běţícího na virtuálním stroji testované virtualizované platformy vyuţiji aktuální test pts/apache softwaru Phoronix vytvořeného s vyuţitím ab, tedy benchmark programu přímo od Apache. Tento test měří v podstatě kolik poţadavků za sekundu je daný systém schopný obslouţit Test databázového serveru Database benchmark Pro otestování chování a performance databáze provozované na virtualizovaném serveru vyuţiji aktuální test pts/sqlite softwaru Phoronix, který provádí jednoduché měření časů potřebných pro zápis předem definovaných dat do indexované databáze Popis testovacího prostředí Aby byla zaručena objektivita testů je nezbytné všechny testované virtualizační platformy otestovat jednotlivě na stejném hardwaru. Hardwarové vlastnosti virtualizačního stroje jsou zachycené v následující tabulce. Základní deska Mobile Intel HM65 Express with Intel Turbo Boost Technology 2.0 Procesor Vendor: GenuineIntel Model: Intel(R) Core(TM) i5-2540m 2.60GHz Speed: 2594 MHz Max Turbo Speed: 3.2 GHz Grafika Intel HD Graphics 3000 Paměť 4 GB (DDR MHz) Disk 250 GB SATA HDD Síť Gigabit Broadcom Ethernet card Tabulka 2: HW konfigurace virtualizačního stroje Jako předmět testování budou virtualizační platformy XEN a VMware. Testovat budu nejdříve jednotlivé platformy instalované jako dedikovaný hypervizor, tedy XEN Server 6.5 a VMware vspehere Hypervisor 6.0. Poté otestuji ještě open-source variantu XEN virtualizace a tedy, ţe jako doménu dom0 zvolím jako hostitelský operační systém CentOS 38

39 6.6. CentOS 6 sice není poslední verzí tohoto OS, ale nejnovější verze 7 zatím nemá plnou podporu pro pouţití XEN jádra v rámci projektu XEN4 CentOS. Porovnám tedy jak virtualizaci s dedikovaným hypervizorem, tak i virtualizaci vyuţívající hostitelský operační systém jako doménu nultého řádu. Virtuální stroj bude vytvořen vţdy se stejnou konfigurací, viz Chyba! Nenalezen zdroj odkazů.. Vyuţit bude operační systému Ubuntu verze LTS určený pro servery, jelikoţ testovací software Phoronix má na tomto operačním systému velikou podporu a instalační balíček je součástí základních repositářů, coţ usnadní přípravné instalační fáze před samotným testováním. LTS vychází z anglické zkratky pro Long term support, neboli verze operačního systému s prodlouţenou dobou podpory. Verze operačního systému Ubuntu splňující tuto definici vycházejí zpravidla kaţdé dva roky a pro Ubuntu do verze platilo obecně, ţe prodlouţená doba podpory pro systém určený operačním stanicím měl podporu 3 roky, oproti tomu serverová verze měla podporu prodlouţenou aţ na 5 let. Od verze se situace poněkud zjednodušila a oba typy operačních systémů mají nyní stejnou dobu prodlouţené podpory a to 5 let. Verze testovaného virtualizovaného OS lze stáhnout z oficiálních stránek výrobce zde: Počet procesorů 1 Velikost operační paměti 2GB Velikost disku 10GB Tabulka 3: Konfigurace virtualizovaného serveru Pro komfortnější moţnou vzdálenou správu a bezproblémovou konfiguraci následně vytvořeného virtuálního serveru budu jak hostitelský fyzický počítač, tak svůj notebook, pomocí kterého budu provádět vzdálenou správu, připojovat k síťovému routeru, který bude nastaven následovně. Pro síť, ve které bude testování probíhat, bude router automaticky přiřazovat adresy a síťové nastavení jednotlivým připojeným stanicím pomocí protokolu DHCP. Router bude zároveň připojen k internetové lince, abych mohl po vytvoření virtuálního serveru jednoduše stáhnout potřebné systémové balíčky a balíčky pro instalaci testovacího softwaru phoronix a jeho závislostí. 39

40 3.1.8 Nastavení prostředí, výsledky a vyhodnocení testů Nastavení XEN platformy Při instalaci a nastavení prostředí pro testování virtualizační platformy XEN jsem, v případě hostitelského OS CentOS 6.6, vyuţíval podporu projektu Xen4 CentOS. [15] Zprovoznění virtualizace Xen nad hostitelským OS není úplně snadné a je potřeba provést mnoţství konfigurací a instalací balíčků na hostitelský počítač. Po instalaci operačního systému CentOS 6.6 bylo potřeba doinstalování několika balíčků potřebných pro zprovoznění Xen virtualizace a také provést několik konfiguračních úprav systému tak, aby byl připraven pro testování. 40

41 Nejdříve je potřeba vypnout SELinux a provést restart počítače. #sed -i -e's/enforcing/disabled/' /etc/sysconfig/selinux #reboot Následně jsem musel provést potřebné síťové nastavení a konfiguraci síťového rozhraní v módu bridge, tedy aby následně vytvořený virtuální server byl umístěn ve stejné síti, jako hostitelský počítač a můj notebook pro vzdálenou správu a nemusel jsem tak konfigurovat přeposílání portů, abych mohl ze svého notebooku vzdáleně server spravovat. Nastavení jsem provedl následujícím způsobem. 1. Nejprve jsem ze systému odstranil síťového manaţera, abych měl síťové konfigurační soubory plně pouze pod svou správou, a nainstaloval balíček bridge-utils pomocí příkazů: #yum -y erase NetworkManager #yum -y install bridge-utils 2. Poté jsem si vytvořil konfigurační soubor bridge rozhraní, jak kopii jiţ existujícího konfiguračního souboru síťového rozhraní p6p1 a provedl v něm konfigurační úpravy potřebné pro funkční bridge rozhraní: #cp -p /etc/sysconfig/network-scripts/ifcfg-{p6p1,br0} #sed -i -e'/hwaddr/d' -e'/uuid/d' -e's/p6p1/br0/' -e's/ethernet/bridge/' /etc/sysconfig/network-scripts/ifcfg-br0 #echo DELAY=0 >> /etc/sysconfig/network-scripts/ifcfg-br0 #echo 'BOOTPROTO="none"' >> /etc/sysconfig/network-scripts/ifcfg-p6p1 #echo BRIDGE=br0 >> /etc/sysconfig/network-scripts/ifcfg-p6p1 3. Jako poslední krok je nutné restartovat síťová nastavení a ověřit, ţe jejich spuštění proběhne v pořádku pomocí příkazu: #service network restart 41

42 Nyní byl systém připraven a mohl jsem přistoupit k instalaci samotného Xenu. Vyuţil jsem k tomu balíčky od Xen4CentOS dostupné v repozitářích CentOS. Jediný poţadavek je, aby byly zapnuté i balíčky z CentOS-Extras repozitáře. Samotnou instalaci lze spustit pomocí sledu příkazů: #yum y install centos-release-xen #yum y install xen Nakonec provedeme restart systému a systém se jiţ spustí s Xen hypervisorem, který běţí nad jádrem operačního systému CentOS. Administraci takovéto platformy jsem prováděl vzdáleně pomocí grafického uţivatelského rozhraní Virtual Machine Manager. Nastavení připojení lze vidět na obrázku níţe. Obrázek 11: Virtual Machine Manager (Zdroj: autor) Nastavení Citrix Xen platformy Zprovoznění a nastavení platformy Citrix Xen bylo jiţ vzhledem ke konfiguraci Xenu nad hostitelským operačním systémem jednoduché. Nejprve bylo potřeba stáhnout instalační médium pro instalaci Citrix Xen Serveru 6.5 ze stránek společnosti Citrix, tedy Poté nastavit počítač tak, aby zaváděcí sekvence načetla toto 42

43 medium a mohla začít samotná instalace. Instalace je interaktivní a není nijak sloţitá. Po úspěšné instalaci je počítač restartuje a systém Xen Server hypervizor se spustí jiţ z lokálního disku. Po spuštění se na monitoru počítače objeví pouze jednoduché konfigurační rozhraní podobné systému BIOS, viz obrázek níţe. Obrázek 12: XenServer 6.5 serverová konzole (Zdroj: autor) Pro následnou správu systému a jednotlivých virtuálních hostovaných strojů existuje pro Xen Server grafický uţivatelský software Citrix XenCenter viz následující obrázek. Obrázek 13: Citrix XenCenter (Zdroj: autor) Nastavení VMware platformy Nastavení platformy VMware se co do postupu, instalace a nastavení prakticky skoro vůbec neliší od nastavení a instalace Citrix Xen platformy. Je tedy potřeba opět ze stránek VMware 43

44 stáhnout instalační médium a provést interaktivní instalaci. U VMware je akorát potřeba dobře si zkontrolovat, jestli počítač nebo server, na který systém instalujeme, splňuje hardwarové poţadavky. VMware si toto striktně hlídá a při detekci hardwaru, který není obsaţen v seznamu, je instalace ihned zastavena a zobrazena chybová hláška. Pro správu platformy VMware existuje software VMware vsphere Client, který vyvíjí přímo VMware. Obrázek 14: VMware vsphere Client (Zdroj: autor) Nastavení hostovaného stroje Hostovaný stroj byl ve všech případech vytvořen stejně a to jako virtuální server s Ubuntu LTS. Instalaci jsem prováděl ze standartního instalačního média určeného pro 64bit platformu dostupného z Jako typ instalace jsem zvolil pouze minimální serverovou instalaci s podporou ssh. Po provedené instalaci systému jsem mohl přistoupit k instalaci produktu phoronix a jednotlivých testových balíčků popsaných v kapitolách aţ Instalaci testovacího softwaru a potřebných doplňků jsem provedl pomocí příkazů: #sudo apt-get install phoronix-test-suite build-essential autoconf perl perl-base perl-modules libsdl-perl libperl-dev libpcre3-dev libaio-dev yasm mesa-utils unzip Instalaci jednotlivých testových balíčků jsem provedl příkazem: #phoronix-test-suite install pts/sqlite pts/apache pts/aio-stress pts/cachebench pts/stream pts/c-ray pts/x264 pts/encode-flac Následné spuštění všech testů jsem prováděl příkazem: 44

45 #phoronix-test-suite run pts/sqlite pts/apache pts/aio-stress pts/cachebench pts/stream pts/cray pts/x264 pts/encode-flac Výsledky testů procesoru 45

46 Výsledky testů paměti 46

47 47

48 Výsledky testů disku Výsledky testů webového serveru 48

49 Výsledky testů databázového serveru Vyhodnocení testů Po nastavení jednotlivých testovaných platforem, které jsem popsal v kapitolách a , aţ jsem provedl na kaţdé platformě sérii 10 průběhů všech navrţených testů a poté tyto výsledky zprůměroval do jednoho vypovídajícího výsledku. Testovací software phoronix jednotlivé výsledky zapisuje do xml souboru s přehlednou strukturou a tudíţ mi na to stačila jednoduchá XSLT transformace. Kdyţ jsem tedy měl pro kaţdou platformu jiţ pouze jeden xml soubor s výsledky jednotlivých testů, mohl jsem pomocí softwaru phoronix provést jejich sloučení (funkce merge s parametry názvů jednotlivých testů) do přehledné tabulky, která lze exportovat jako obrázek, viz následující obrázek. 49

50 Obrázek 15: Shrnutí výsledků testů (Zdroj: Vygenerováno programem phoronix) Výsledky jednotlivých testů jsou vizuálně odlišeny barevnou škálou: Červená platforma dosáhla v daném testu nejhorších výsledků Modrá platforma dosáhla v daném testu průměrných výsledků Zelená platforma dosáhla v daném testu nejlepších výsledků Na základě výsledkové tabulky dopadla poměrně jednoznačně nejhůře platforma Xen, která byla provozována nad hostitelským operačním systémem CentOS 6. Prohrála osm ze třinácti testů. Naopak ale platforma Xen provozovaná jako nejnovější hypervizor XenServer 6.5 vyhrála deset z třinácti testů a v jednom se umístila pouze těsně za platformou VMware. Je poměrně zajímavé, ţe platforma VMware, která je podle všech dostupných průzkumů lídrem na trhu virtualizace, podlehla v testech na hardwarové konfiguraci, kterou jsem pouţíval, 50

51 platformě Xen. Dokonce dopadla v případě testování výkonosti operační paměti nejhůře ze všech testovacích platforem. 3.2 Výběr virtualizační platformy Pro finální rozhodnutí o konečné volbě virtualizační platformy jsem se rozhodl provést několik benchmark testů virtualizačních platforem, jejichţ výsledky jsou nastíněny v kapitole Vyhodnocení testů. Jako další rozhodující faktor také vyuţiji přihlédnutí k v současné době nejznámějšímu a u řady firem respektovanému reportu z výzkumu virtualizačních platforem od firmy Gartner. Konkrétně report s názvem Magic Quadrant for x86 Server Virtualization Infrastructure. [22] Na základě výsledků testů virtualizačních platforem a přihlédnutí k reportu společnosti Gartner, kde jsem zkoumal, jestli je daná platforma vůbec mezi identifikovanými platformami a na případné silné a slabé stránky dané platformy, jsem se rozhodl navrhnout virtuální prostředí pro virtualizaci uţivatelských stanic a aplikací nad platformou Citrix Xen. Další z důvodů, proč jsem si vybral právě tuto platformu, je ten, ţe s platformou VMware se setkávám během své práce téměř na denní bázi, ale s platformou Citrix Xen mám zatím pouze povrchní zkušenosti. 3.3 Návrh řešení virtuálního prostředí Navrhnuté řešení pro virtualizaci uţivatelských stanic a aplikací bude na základě výsledků testů a vybrané virtualizační platformě postaveno na technologiích Citrix Xen. Celou virtualizační architekturu jsem rozdělil do tří logických vrstev a pro lepší názornost a pochopení jsem vytvořil její schéma, které je zachyceno na následujícím obrázku. 51

52 Obrázek 16: Návrh virtuálního prostředí Nejniţší vrstva, tedy vrstva uţivatelských aktiv je nezbytným poţadavkem pro úspěšné provozování celé virtualizační architektury. Je potřeba mít v rámci firemního prostředí funkční úloţiště uţivatelských dat, tedy Microsoft Active Directory. Active Directory je implementace adresářových sluţeb, která umoţňuje administrátorům správu bezpečnostních politik, instalovaných programů, ale co je pro naší virtualizační platformu důleţité, správu 52

53 organizace skupiny počítačů, uţivatelů a domén. Pro potřeby správného fungování distribuce virtuálních aplikací a uţivatelských stanic bude potřeba mít všechny virtuální stroje v doméně řízené právě Active Directory. Souvisejícími poţadavky, které by se dali zařadit do vrstvy mimo virtualizační architekturu, je také funkční DHCP server, který se bude starat o přidělování IP adres a síťových nastavení jednotlivým virtuálním strojům, a také DNS server, který bude slouţit jako překladatel IP adres na doménové názvy. Následuje stěţejní vrstva celé architektury, a to Virtualizační vrstva. Tato vrstva ve své podstatě představuje fyzický hostitelský server, na kterém bude platforma provozována. Ač to není doporučované, tak pro potřeby malé firmy, či pro účely pouţití tohoto návrhu jako prostředí pro demonstraci jednotlivých funkcí virtualizační platformy potenciálním zákazníkům, tedy pro tzv. Proof of concept, bude postačovat fyzický server se 4 CPU a 48GB operační paměti. Na fyzický server bude jako hypervizorský systém nainstalován XenServer 6.5. V rámci hypervizorského systému bude poté potřeba vytvořit několik virtuálních strojů a provést jejich konfiguraci, případně nainstalovat na ně komponenty nezbytné pro funkčnost celé architektury. Pro naše účely budeme potřebovat vytvořit virtuální stroje podle následující tabulky. Virt. stroj Operační systém Účel VM1 Windows Server 2012 Server pro Delivery controler, StoreFront, Licence server a Databázový server MS SQL Express VM2 Windows Server 2012 Server pro Virtual Delivery agenta slouţící jako master image VM3 Windows 8.1 Desktop pro Virtual Delivery agenta slouţící jako master image Tabulka 4: Přehled potřebných virtuálních strojů a jejich popis Konfigurace těchto virtuálních strojů bude mít následující specifikace. Pro serverové operační systémy Windows Server 2012 budeme vytvářet stroj s 2 virtuálními procesory, 4GB operační paměti, 30GB úloţného prostoru na virtuálním disku. Pro Desktop operační systém Windows 8.1 budeme vytvářet virtuální stroj s 2 virtuálními procesory, 2GB operační paměti a s kapacitou 24 GB diskového úloţiště. Všechny virtuální stroje musí být řízeny firemním Active Directory. A obsahovat uţivatelské účty, které mají lokální administrátorská práva a práva na úrovni doménových administrátorů. 53

54 V produkčních systémech není nutné mít role doménových administrátorů, jelikoţ poţadovaná oprávnění jsou administrátorským účtům přiřazovaná na základě jejich rolí. Virtuální stroj VM1 bude klíčový prvek celé architektury a bude běţet pod serverovým operačním systémem Windows Server Na serveru budou nainstalovány všechny klíčové komponenty potřebné pro úspěšné provozování celé platformy a to: Citrix License server komponenta slouţící pro správu a distribuci licencí Citrix Store Front komponenta, která umoţňuje administraci a prezentaci publikovaných virtuálních aplikací nebo uţivatelských stanic MS SQL Express databáze databáze slouţící pro uloţení konfiguračních poloţek jednotlivých komponent Delivery Controler klíčová komponenta zajišťující logiku a administraci celého řešení Virtuální stroj VM2 a VM3 budou v naší architektuře slouţit pro umoţnění distribuce jednotlivých virtuálních uţivatelských stanic nebo aplikací. K tomuto účelu budou muset být tyto aplikace na stroji nainstalované. Na stroji musí být rovněţ nainstalovaná komponenta Virtual Delivery Agent (VDA), která toto publikování umoţní. Předposlední vrstvou celé architektury je prezenční a doručovací vrstva. Tato vrstva slouţí především jako oddělení aplikační logiky celé platformy a přehledného uţivatelského prostředí, které je vhodné pro koncové uţivatele. Klíčovou součástí pro tuto vrstvu je komponenta Citrix Store Front, která je fyzicky umístěna ve vrstvě popisované výše, ale vystavuje pro koncové uţivatele webové uţivatelské rozhraní, pomocí kterého k celé platformě přistupují a mohou obsluhovat kancelářské aplikace, nativní windows aplikace nebo aplikace pro podporu obchodu, případně své virtuální uţivatelské stanice, ke kterým mají oprávnění přidělená správcem systému. 54

55 Obrázek 17: Webové uţivatelské rozhraní StoreFront (Zdroj: autor) Poslední vrstvou jsou jiţ samotní uţivatelé, kteří jsou konzumenti virtualizovaného obsahu. Výhodou celé platformy pro uţivatele je fakt, ţe mohou obsluhovat přidělený virtualizovaný obsah z jakéhokoliv zařízení, od stolních počítačů přes tablety aţ po mobilní telefony. Při vyuţití této moţnosti ke své práci se okamţitě stávají velice flexibilními, mobilními a v případě, ţe jsou tyto vlastnosti k vykonávání jejich pracovní činnosti potřebné, tak i produktivními. Systém ovšem neumoţňuje pouze obsluhu virtualizovaných zdrojů, ale poskytuje o sobě i informace, které mohou být určeny různým skupinám uţivatelů v rámci firemního prostředí. Pro technické pracovníky je moţné poskytovat informace dohledové povahy o stavu systému, či jeho částí, případně generovat notifikace při výskytu události, kterou je potřeba brát na vědomí a vyřešit. (Výpadek systému, nedostatek zdrojů, chyby systému) Pro manaţery, ať uţ z IT oddělení, či z vedení firmy zase můţe systém poskytnout přehledné informace a vyuţívání systému koncovými uţivateli, stavu čerpání jednotlivých licencí na aplikace či operační systémy. 55

56 4. Postup instalace řešení 4.1 Instalace hostitelského serveru Nejdříve je nutné nainstalovat hypervizorský operační systém XenServer 6.5. Neţ ale k instalaci přistoupíme, je nutné ověřit a splnit poţadavky, které systém na fyzický hostitelský počítač klade. XenServer je určen především pro serverový hardware, nicméně je moţné ho provozovat i na spoustě dalších modelech stolních počítačů nebo notebooků. Kompletní výčet podporovaného hardwaru lze najít zde Minimální poţadavky jsou ale následující: Jeden nebo více 64-bit procesorů s taktovací frekvencí minimálně 1,5 GHz (Doporučeno je ovšem více multijádrových procesorů s taktovací frekvencí 2 GHz a více) Pro podporu vytváření virtuálních strojů s OS Windows je nutný systém zaloţený na Intel VT nebo AMD-V Minimální velikost operační paměti 2 GB (Doporučeno 4 GB a více) Minimální velikost lokálního úloţiště 16 GB (Doporučeno je ovšem 60 GB a více) Pokud náš hardware splňuje poţadavky pro instalaci hypervizorů XenServer. Můţeme přistoupit k instalaci. Nejdříve si musíme stáhnout instalační médium, které je dostupné zde Medium vypálíme na DVD, nastavíme počítač, aby bootoval z DVD mechaniky, vloţíme do mechaniky počítače vypálené instalační médium a restartujeme počítač. Nyní jiţ postupujeme následovně: 1. Je zobrazena uvítací obrazovka instalace systému XenServer. Pro instalaci zvolíme OK. 2. Následně je zobrazeno licenční ujednání. Zvolíme Accept EULA. 3. Pro čistou instalaci nyní zvolíme OK. 56

57 4. Nyní musíme zvolit disk, na který chceme systém nainstalovat. Zvolíme tedy poţadovaný lokální disk a stiskneme OK. 4.1 Pro optimalizaci systému na následné pouţití v rámci XenDesktop ještě můţeme zaškrtnout tlačítko Enable thin provisioning (v případě vytváření VM se nebude předalokovávat nastavený diskový prostor) 5. Nyní zvolíme instalaci z lokálního instalačního média a stiskneme OK. 6. Zvolíme, ţe nechceme instalovat dodatečné balíčky. Tlačítko No. 7. Pro přeskočení ověření instalačního média zvolíme Skip verification a stiskneme Ok. 8. Nastavíme administrátorské heslo pro uţivatele root. Stiskneme Ok. 9. Nyní jsme v nastavení sítě. Pokud budeme pouţívat konfiguraci získanou z DHCP serveru, zvolíme Automatic configuration a stiskneme Ok. Pro instalaci hostitelského počítače je ale dobré, aby měl systém statickou a předem známou adresu, na kterou se následně připojíme administrátorským softwarem XenCenter. Zvolíme tedy static a nastavíme IP adresu, výchozí bránu a síťovou masku. (IP address: , Gateway: , Network mask: ) Konfiguraci potvrdíme Ok. 10. Nyní nastavíme název serveru (například xenserver) a vyplníme adresu DNS serveru (např ) Konfiguraci potvrdíme Ok. 11. Vybereme časovou zónu (Prague). Potvrdíme Ok. 12. Zvolíme Using NTP pro nastavení serveru pro synchronizaci času. Potvrdit Ok. 13. Zadáme adresu NTP serveru. (např. cz.pool.ntp.org) Zvolit Ok. 14. Nyní jsme jiţ vloţili všechny poţadované informace a můţeme zvolit Install XenServer. 15. Po úspěšné instalaci se zobrazí okno Installation complete. Vyjmeme instalační medium z mechaniky a Potvrdíme Ok. 16. Systém se restartuje a po startu se jiţ spustím konzole XenServer 57

58 Obrázek 18: Konfigurační konzole XenServer 6.5 (Zdroj: autor) 4.2 Vytvoření virtuálních strojů Po úspěšné instalaci hypervizoru musíme ještě vytvořit nezbytné virtuální stroje potřebné pro chod virtualizační platformy XenDesktop 7.6. Nejdříve je nutné nainstalovat si program XenCenter určený pro administraci XenServeru. Instalační soubor lze stáhnout zde Po spuštění programu XenCenter je nutné ho nejdříve spojit s běţících XenServer systémem. Klikneme na ikonu Add new server Otevře se dialogové okno, kam je nutné vyplnit IP adresu serveru a heslo uţivatele root zadané při instalaci Xen Server. Potvrdíme Add. Proběhne spojení se serverem, vzájemná synchronizace a nový server se přidá pod poloţku XenCenter v levém hierarchickém menu. Nyní můţeme přejít k vytváření virtuálních strojů popsaných v tabulce Tabulka 4: Přehled potřebných virtuálních strojů a jejich popis a související kapitole 3.3 Návrh řešení virtuálního prostředí. Budeme vytvářet celkem tři virtuální stroje a bude potřebovat dvě různá instalační média. Jedno pro Windows Server 2012 a druhé pro Windows 8.1. Obě média je moţné stáhnout ze stránek společnosti Microsoft. Nejjednodušší způsob, jak instalační médium připojit pro následnou instalaci do virtuálního stroje je ho vypálit na DVD disk a vloţit do 58

59 mechaniky hostitelského serveru s instalovaným XenServer systémem, nebo jej umístit na sdíleném disku a připojit tento disk k XenServeru pomocí programu XenCenter. (poloţka Create new storage ) Následně začneme s vytvářením jednotlivých virtuálních strojů. Vybereme poloţku New VM v menu VM programu XenCenter Vybereme šablonu podle typu operačního systému, který chceme instalovat. (Windows Server 2012 R2, nebo Windows 8) Pojmenujeme vznikající virtuální stroj Instalační medium ponecháme DVD drive. (Případně zvolíme jiné, pokud máme instalační medium umístěno jinde) Vybereme domácí server. (např. xenserver) Nastavíme počet virtuálních procesorů a velikost operační paměti Jako úloţiště ponecháme Local storage a nastavíme poţadovanou velikost virtuálního disku Virtuální síť ponecháme na výchozí Network 0. Potvrdíme Create machine. 4.3 Instalace virtualizační platformy Po úspěšné instalaci hypervizoru a vytvoření potřebných virtuálních strojů můţeme přejít k instalaci jednotlivých komponent platformy na vytvořené virtuální stroje VM1 aţ VM3. Nejdříve budeme konfigurovat centrální a klíčový virtuální server VM1. Jelikoţ jednotlivé Citrix komponenty vyţadují validní licence, první přijde na řadu instalace Citrix License serveru ve verzi Instalační soubor lze stáhnout ze stránek výrobce zde Rovněţ budeme potřebovat licenční soubor s příponou *.lic, který na nainstalovaný server umístíme. Licenční soubor dostaneme buď po zakoupení produktu od výrobce, nebo jako verzi pro testování a můţeme si ho vygenerovat v rámci účtu vytvořeného na stránkách výrobce v sekci Activate and Allocate License. Tyto informace jsou nám zaslány v informačním u spolu s licenčním kódem, který je nezbytný k vygenerování licenčního klíče. Po spuštění instalačního postupujeme následovně: Potvrdíme licenční ujednání 59

60 Zvolíme cestu, kam se má aplikace License Server nainstalovat (výchozí cesta je C:\Program Files x86\citrix) Potvrdíme konfiguraci portů, na kterých bude aplikace dostupná a zaškrtneme povolení instalačnímu programu provést změny na našem lokálním firewallu Klikneme na Install. Po úspěšném nainstalování je administrační rozhraní licenčního serveru dostupné z Přihlásíme se jako lokální administrátor Klikneme na poloţku Vendor Daemon Configuration a následně na Import License. 60

61 Následně vybereme umístění, kde máme uloţený licenční soubor s příponou.lic vygenerovaný ze stránek výrobce a zvolíme Import License Po úspěšném importu licenčního souboru je zobrazena následující zpráva Nyní můţeme přejít na instalaci produktu XenDesktop 7.6 a to konkrétně komponenty Delivery controller na virtuální server VM1. Nezbytné instalační médium ve formátu ISO lze stáhnout podle pokynů z informačního mailu od výrobce zde Po staţení se provede připojení ISO souboru k virtuálnímu serveru pomocí XenCenter. Ve virtuálním serveru se jeví připojené medium jako DVD vloţené do mechaniky. Další postup je následující: Spustíme autorun z DVD a zobrazí se hlavní nabídka. Zvolíme moţnost start u poloţky Xen Desktop Klikneme na poloţku Delivery Controller v následující nabídce 61

62 Odsouhlasíme licenční podmínky produktu Zaškrtneme všechny dostupné komponenty. (licenční server jiţ není zobrazen, jelikoţ jeho instalaci uţ máme úspěšně za sebou) V našem případě instalujeme vše na jeden server, ale pro větší instalace je doporučované instalovat tyto klíčové komponenty na oddělené servery. Zaškrtneme dodatečné komponenty. (Nainstaluje se například potřebný MS SQL server express) Potvrdíme nastavení firewallu a zvolíme moţnost automatického nastavení firewall pravidel Zrevidujeme shrnutí instalace a klikneme na Install Po úspěšném nainstalovaní všech komponent zaškrtneme na závěrečné obrazovce poloţku Launch studio 62

63 Nyní dojde k prvnímu spuštění Citrix Studia. Při prvním spuštění nám Citrix Studio pomůţe s vytvořením nové Site neboli kontejneru, který obsahuje vše, co budeme na této platformě provozovat, skupiny aplikačních serverů a uţivatelských stanic nazývané jako Machine catalog a přiřazení koncových uţivatelů do těchto skupin, neboli vytvoření tzv. Delivery groups. Dále tedy postupujeme následovně: Klikneme na poloţku Deliver desktop and Application to your users Nastavíme název Site např. Xen Nastavíme údaje pro konfiguraci databáze. Jelikoţ jsme databázi nainstalovali jako komponentu na lokální server, zadáme do pole Database server location hodnotu.\sqlexpress. Do pole název databáze zadáme například CitrixXen. Zvolíme Next. 63

64 Potvrdíme automatické vytvoření databáze Ok Zadáme adresu License serveru a zvolíme existující licenci Na záloţce Connection vybrat No machine management Vybrat výchozí síť hypervizorů Network 0 a pojmenovat ji. (např. LAN) Vybrat lokální úloţiště XenServeru a moţnost vyuţívání stejného úloţiště jak pro virtuální stroje tak i personální virtuální disky V záloţce App-V publishing zaškrtnout moţnost No Kliknout na tlačítko Finish Nyní máme vytvořenou novou Site. Neţ budeme pokračovat s konfigurací dalšího kroku v Citrix Studiu, tedy vytvoření Machine Catalogu, nainstalujeme si na virtuální server VM2 64

65 a virtuální stanici VM3 komponentu Virtual Delivery Agent. Instalační médium, ze kterého budeme instalaci provádět je shodné jako v případě instalace Delivery controlleru. Připojíme si ho tedy stejným způsobem k VM2 a VM3. Jako první nainstalujeme Virtual Delivery agenta na VM2 tedy na serverový OS. Postup bude následující: Nainstalujeme na server.net 3.5 framework. V server manageru zvolíme Add roles and futures a přidáme roli Application server. Spustíme instalační médium a v hlavní nabídce zvolíme Virtual Delivery Agent for server OS Ponecháme vychozí hodnotu Create a master image Ponecháme výchozí výběr instalovaných komponent V záloţce Delivery controller vybereme moţnost Let machine creation Services do it automatically V záloţce výběru funkcí a nastavení firewallu ponecháme výchozí hodnoty Na záloţce shrnutí klikneme na Install Pro instalaci některých komponent je potřeba restartovat stanici. Ovšem instalace Delivery agenta po tomto restartu automaticky pokračuje Po úspěšné instalaci ještě nainstalujeme aplikace, které budeme později publikovat jako virtuální a nakonec můţeme vypnout virtuální stroj Nyní můţeme naisntalovat Virtual Delivery Agenta na virtuální stanici VM3, na které běţí operační systém Windows 8.1. Postup pro instalaci agenta je totoţný s instalací na serverový OS viz výše. Jediný rozdíl je zvolení moţnosti Virtual delivery agent for Windows desktop OS v hlavní nabídce. 65

66 Jelikoţ máme na obou typech virtuálních strojů jiţ nainstalované delivery agenty, můţeme pokračovat s konfigurací dalšího kroku v Citrix Studiu, tedy vytvoření Machine Catalogu. Tento postup budeme provádět celkem dvakrát, s tím rozdílem, ţe poprvé zvolíme jako typ operačního systému pro Machine catalog Windows server OS a podruhé Windows Desktop OS. Postup tedy bude následující: V menu Citrix studia klikneme na druhou poloţku, tedy Set up machines Jako typ pro Machine catalog zvolíme Windows server OS (stejný postup provedeme i při vytváření katalogu pro Desktop OS) V záloţce Machine management ponecháme výchozí hodnoty V záloţce Master image zvolíme master image, který jsme vytvářeli při instalaci delivery agentů. Tedy Windows server OS (stejný postup provedeme i při vytváření katalogu pro Desktop OS) V záloţce Virtual machines nastavíme poţadovaný počet klonovaných strojů, které chceme vytvářet. Např. 5 V záloţce Computer accounts zvolíme poloţku Create new active directory accounts a do poloţky Account naming scheme zadáme XEN-##. (hodnota ## bude nahrazována sekvenčním číslem) Na záloţce shrnutí pojmenujeme náš Machine catalog. Například WinSer 2012 a potvrdíme kliknutím na Finish 66

67 Nyní zbývá poslední krok v rámci Citrix studia a to vytvoření tzv. Delivery Group. Jde v podstatě o nastavení jakým uţivatelům budou přiřazeny jaké virtuální aplikace nebo stanice. Postup bude následující: V menu Citrix studia klikneme na třetí poloţku, tedy Create delivery group, applications and Assign users Vybereme vytvořený Machine catalog. Například WinSer Delivery type zvolíme Desktop and applications V záloţce users přidáme skupinu uţivatelů z Active Directory, kteří budou mít přístup k virtualizované platformě. V následující záloţce zvolíme aplikace, které budeme chtít publikovat koncovým uţivatelům. Zvolíme StoreFront server Pojmenujeme Delivery Group a potvrdíme Finish 67

68 Pro úspěšnou konfiguraci virtualizační platformy nám nyní zbývá uţ pouze konfigurace jediné poloţky a tou je Citrix Store Front. Citrix Sotre Front je vyspělé webové uţivatelské rozhraní, které umoţňuje přistupovat koncovým uţivatelům k virtualizovanému obsahu, který jim administrátor systému zpřístupnil. V našem případě běţí Store Front na serveru VM1, jako ostatní klíčové komponenty. Konfigurační konzole pro Store Front je nyní integrována do Citrix studia, konfigurace tedy probíhá z jednoho centrálního místa a je následující: Store Front je doporučené provozovat v zabezpečené verzi, která komunikuje přes protokol https. Jako první tedy budeme muset v IIS manageru lokálního serveru nastavit Site Binding na nový self-signed certifikát Klikneme na poloţku Create a new deployment na hlavní obrazovce Zadáme URL adresu pro nové prostředí 68

69 Zadáme název pro nový Store. Například xen. Nadefinujeme nakonfigurovaný Delivery controller V záloţce Remote access ponecháme výchozí hodnoty a klikneme na Create. Úspěšná konfigurace vytvoří uţivatelské rozhraní dostupné v našem případě na adrese Nyní jsme úspěšně nakonfigurovali webové uţivatelské rozhraní a můţeme se tedy vyzkoušet přihlásit k naší virtualizační platformě jako bychom byli koncoví uţivatelé. Webové rozhraní platformy vystavené pomocí komponenty Store Front je dostupné na adrese dns VM1 IP]/Citrix/xenWeb. V našem případě to bude Po otevření stránky v prohlíţeči se nám objeví uţivatelský přihlašovací formulář. Přihlášení můţeme provést, buď jako administrátorský uţivatel, který má lokální administrátorská práva na našem systému, nebo jako kterýkoliv uţivatel, kterého přidáme do skupiny Xen v Active Directory, protoţe této skupině jsme přidávali v rámci konfigurace Delivery Group práva pro přístup k publikovanému virtuálnímu obsahu. 69

70 Po přihlášení musí uţivatel nejprve souhlasit s licenčními podmínkami společnosti Citrix a nainstalovat si plugin Citrix Receiver, který bude zprostředkovávat doručení publikovaného virtuálního obsahu. Uţivatel jiţ provedl všechny kroky k tomu, aby se mohl stát konzumentem publikovaného obsahu, a můţe začít pracovat s pomocí virtuálních aplikací a virtuální uţivatelských stanic, které mu byly IT administrátory zpřístupněny. 70