Bankovní institut vysoká škola Praha Katedra matematiky, statistiky a informačních technologií
Virtualizace desktopů v prostředí vysokých škol Diplomová práce
Autor:
Bc. Petr Pejša Informační technologie a management
Vedoucí práce:
Praha
Ing. Vladimír Beneš
červen, 2012
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 Novém Strašecí dne
Bc. Petr Pejša
Poděkování Tímto bych chtěl poděkovat Ing. Vladimíru Benešovi za vedení, konzultace a cenné připomínky při zpracování této diplomové práce. Dále pak děkuji pracovníkům oddělení správy lokální sítě na Vysoké škole ekonomické v Praze za to, ţe mi umoţnili realizovat implementaci desktopové vizualizace, z níţ tato práce vychází.
Anotace Tato diplomová práce se zabývá moţnostmi vyuţití nástrojů pro virtualizaci desktopů při výuce na vysokých školách. Hlavním cílem je popis virtualizačních nástrojů od tří největších výrobců (VMware, Microsoft, Citrix) a poté nasazení jednoho z nich v počítačové učebně s vyuţitím zero klientů. Součástí nasazení je i cenová kalkulace a zhodnocení nákladů při srovnání s učebnou, která je vybavena klasickými PC. Klíčová slova: virtualizace desktopů, VDI, počítačová učebna, zero klient, náklady
Annotation This thesis deals with the possibilities of using desktop virtualization tools for teaching at universities. The main objective is to describe virtualization tools from the three largest producers (VMware, Microsoft, Citrix) and then use one of them in the computer lab using zero clients. Part of deployment is also pricing and evaluation costs in comparison with computer lab, which is equipped with a conventional PC. Key words: desktop virtualization, VDI, computer lab, zero client, costs
Obsah 1
Virtualizace – Druhy a principy ...................................................................................... 8 1.1 Co je to virtualizace ........................................................................................................ 8 1.2 Druhy virtualizace .......................................................................................................... 8 1.3 Výhody a nevýhody virtualizace .................................................................................... 9 1.4 Současné nástroje pro virtualizaci serverů ................................................................... 10
2
1.4.1
VMware ................................................................................................................ 10
1.4.2
Microsoft .............................................................................................................. 13
1.4.3
Citrix ..................................................................................................................... 14
Virtualizace desktopů ..................................................................................................... 16 2.1 Virtualizace desktopů – vývoj a pouţití ....................................................................... 16 2.2 Virtualizace desktopů – výhody a nevýhody................................................................ 16 2.3 Virtualizace desktopů v podání společnosti VMware .................................................. 17 2.3.1
Protokol PCoIP ..................................................................................................... 17
2.3.2
Architektura produktu VMware View.................................................................. 18
2.4 Virtualizace desktopů v podání společnosti Microsoft................................................. 24 2.4.1
Komponenty produktu Microsoft Remote Desktop Services .............................. 26
2.4.2
Základní nástroje pro správu Microsoft VDI ....................................................... 27
2.5 Virtualizace desktopů v podání společnosti Citrix ....................................................... 28 2.5.1
Architektura hostovaných VDI desktopů ............................................................. 28
2.6 Porovnání výhod a nevýhod jednotlivých produktů pro virtualizaci desktopů ............ 31
3
2.6.1
VMware View ...................................................................................................... 31
2.6.2
Microsoft VDI ...................................................................................................... 32
2.6.3
Citrix XenDesktop ................................................................................................ 33
Nástroje pro plánování nasazení VDI........................................................................... 34 3.1 VMware View Planner ................................................................................................. 34
4
Virtuální učebna – sizing, cenová kalkulace, SWOT analýza .................................... 36 4.1 Sizing serverového HW – zjištění potřebného výkonu ................................................ 36 4.1.1
Odhad potřebného výkonu dle dokumentace k produktu VMware View ............ 37
5
4.1.2
Zjištění potřebného výkonu pomocí online nástroje pro VDI sizing, který je
dostupný na webu myvirtualcloud.net .............................................................................. 40 4.2 Návrh a cenová kalkulace výsledné HW a SW konfigurace ........................................ 41 4.3 SWOT analýza.............................................................................................................. 42 5
Nasazení VMware View a potřebných součástí. .......................................................... 44 5.1 Konfigurace VMware ESXi ......................................................................................... 44 5.2 Instalace VMware vCenter Server................................................................................ 45 5.3 Komponenta VMware View Composer ....................................................................... 48 5.3.1
Příprava databáze pro View Composer ................................................................ 48
5.3.2
Vytvoření ODBC konektoru pro připojení View Composeru k databázi ............ 49
5.3.3
Instalace komponenty View Composer pro vCenter Server ................................ 49
5.4 Instalace a konfigurace sluţby VMware View Connection Server .............................. 50 5.5 Příprava klientského desktopu a instalace View agenta ............................................... 52 5.6 Vytvoření poolu virtuálních desktopů .......................................................................... 54 5.7 Instalace VMware View klienta a ověření funkčnosti poolu ....................................... 60 5.8 Vyuţití „Zero“ klienta pro připojení k VMware View poolu. ..................................... 62 6
Přechod z Windows XP na Windows 7 ve virtuální učebně ....................................... 63 6.1 Příklad pouţití migrační utility migprofile.exe ............................................................ 64
7
Srovnání provozních a investičních nákladů klasické a virtuální učebny osazené
zero klienty. ............................................................................................................................. 65 7.1 Porovnání spotřeby zero klientů a klasických PC ........................................................ 65 7.2 Porovnání investičních nákladů klasické a virtualizované učebny .............................. 68
6
Úvod Virtualizace serverů je dnes jiţ velice známým pojmem, který je skloňován ve všech pádech a bylo o něm napsáno jiţ mnoho. V současné době se ale zároveň začíná rozvíjet i virtualizace ostatních částí světa informačních technologií, jako např. virtualizace diskových úloţišť, síťových prvků, aplikací a desktopů. A právě virtualizace desktopů je hlavním předmětem této diplomové práce.
V teoretické části jsou popsány a přiblíţeny základní principy fungování, nejdříve serverové a poté i desktopové virtualizace, přičemţ je vysvětlena souvislost a rozdíly mezi nimi. V současné době se na trhu vyskytují 3 hlavní hráči v oboru virtualizace desktopů, a to VMware, Microsoft a Citrix. Cílem této teoretické části je tedy popis a technologické srovnání výhod a nevýhod produktů od těchto tří společností. Hlavním cílem celé této práce je návrh a zavedení virtualizovaných desktopů v počítačové učebně na vysoké škole, její cenová kalkulace a zhodnocení nákladů při srovnání s učebnou, která je vybavena klasickými PC. Tento cíl je realizován v praktické části, kde je demonstrován na jedné učebně s 21 PC. Na rozdíl o teoretické části je zde pro realizaci zvolen pouze jeden z popisovaných systémů pro virtualizace desktopů, a to VMware View. Součástí realizace virtuální učebny je, kromě samotného nasazení systému, také analýza silných a slabých stránek, výpočet finanční náročnosti a také analýza spotřeby elektrické energie a její porovnání s klasickou učebnou.
7
1 Virtualizace – Druhy a principy 1.1 Co je to virtualizace Jedná se o softwarovou technologii, která zásadním způsobem mění fungování IT prostředí. Dnešní výkonné x86 počítače byly navrţeny tak, aby na nich běţel pouze jeden operační systém, coţ bohuţel nechává většinu zdrojů zcela nevyuţitých. Virtualizace umoţňuje spuštění více různých operačních systémů s různými aplikacemi na jednom fyzickém stroji, coţ umoţňuje lepší vyuţití výkonu a tím i sníţení nákladů na hardware. Dá se tak říci, ţe primárním cílem virtualizace je schovat technické detaily systému pod virtualizační vrstvu, prostřednictvím které je pak k dispozici pouze jeho „výkon“ „V podstatě představuje iluzi, v níž nějaký zdroj (např. paměť, procesor, disk a další periferie) zmnožíme (tedy vytvoříme řadu kopií) a každý uživatel dostane jednu nebo více z těchto kopií k dispozici. Protože kopie vznikají pouze jako koncepty, hovoříme o virtuálních objektech - máme virtuální paměť, virtuální disk a samozřejmě také virtuální procesor. V konečném důsledku tak můžeme uživateli nabídnout celý virtuální počítač, který je tvořen z virtuálních komponent. Uživatel má tak pocit naprosté kontroly (vlastnictví), reálně přitom sdílí konkrétní fyzické zdroje s dalšími uživateli.“ [6]
1.2 Druhy virtualizace Způsobů, jak virtualizovat je více. Těmi hlavními jsou emulace, paravirtualizace, plná (nativní) virtualizace a virtualizace na úrovni operačního systému. Emulace – Tento typ virtualizace umoţňuje jako jediný provoz systémů i jiné architektury, neţ je samotný hostující systém. Výhodou tohoto přístupu je fakt, ţe hostované operační systémy a aplikace není nutné modifikovat. Na druhou stranu aby toto bylo moţné, musí se všechny operace prováděné v hostovaném systému interpretovat, coţ má za následek výrazné sníţení výkonu. U tohoto typu virtualizace nelze ani vyuţít hardwarovou podporu, kterou dnešní procesory nabízejí. [7] Paravirtualizace – U tohoto způsobu virtualizace není simulován hardware, ale je pro hostovaný systém k dispozici rozhraní přes které provádí volání sluţeb hypervizoru. Jedná se o podobný princip, jako systémová volání. Nevýhodou 8
paravirtualizace je nutná úprava hostovaného operačního systémů tak, aby byl schopen tyto sluţby vyuţívat, na druhou stranu umoţňuje efektivnější vyuţití prostředků neţ emulace. [7] Plná (nativní) virtualizace – zde je virtuálním strojem simulován dostatek hardwarových komponent na to, aby hostovaný operační systém nemusel být nijak upraven. Jedinou výjimkou je procesor, k tomu přistupuje hostovaný OS přímo, proto je také nutná jednotná architektura ve virtuálním stroji s fyzickým hardwarem. Pro tyto operace jsou výrobci do procesorů implementovány speciální instrukce. Výhodou je izolovanost hostovaného operačního systému od hostitelského a při vyuţití nativní podpory procesoru i poměrně efektivní vyuţití prostředků. Problém ale bývá s efektivitou I/O operací. [7] Virtualizace na úrovni operačního systému – „Virtualizuje se fyzický server na úrovni OS, což umožňuje běh více izolovaných bezpečných virtuálních serverů na jednom fyzickém serveru. Prostředí hostovaného OS sdílejí jeden OS s hostitelským systémem – tj. stejné jádro OS je použito pro implementaci hostovaného OS. Aplikace běžící v hostovaném prostředí jej však vnímají jako samostatný systém.“ [4] Výhodou tohoto řešení je jeho efektivita, nevýhodou naopak malá flexibilita v pouţití hostovaných OS. K dispozici jsou ještě několik dalších technik, jako např. aplikační virtualizace, ty se ale v praxi příliš často nevyskytují, proto se jimi zde nezabývám.
1.3 Výhody a nevýhody virtualizace Virtualizace je velice moderní slovo, které se skloňuje ve všech pádech, ale jaké výhody z pouţívání této technologie skutečně plynou? Úspora nákladů za hardware – při vyuţití virtualizace dosahuje běţně konsolidační poměr 30:1 u serverů a 70:1 u desktopů. Kromě samotných nákladů na pořízení hardwaru se tím sníţí i náklady na podporu a servis. Snížení spotřeby el. energie – sníţení počtu fyzických zařízení má samozřejmě za následek i sníţení spotřebované elektrické energie a to nejen na samotném napájení, ale i na jeho chlazení.
9
Nižší náklady na správu – díky automatizačním nástrojům, lze provádět některé operace na více virtuálních strojích najednou, coţ razantně sniţuje čas strávený správou systémů Vyšší flexibilita prostředí – vytváření, změna a zrušení virtuálního stoje, je otázkou několika minut. Většina virtualizačních nástrojů nabízí i moţnost stroje klonovat. V případě ţe přidělené zdroje přestanou stačit, lze je jednoduše rozšířit, popřípadě virtuální stroj přesunout na jiný fyzický server v rámci clusteru. Vyšší dostupnost – při pouţití vhodného virtualizovaného prostředí lze dosáhnout téměř stoprocentní dostupnosti virtuálních strojů. Bohuţel ne vţdy virtualizace přináší jen výhody, při nesprávném pouţití nebo chybném plánování, můţe provozovatele dostat do váţných potíţí. Nedostatečná redundance HW – tato technologie často svádí k nasazení veškeré firemní infrastruktury, včetně dat, na jediný fyzický server, coţ při selhání tohoto serveru vede k absolutnímu odstavení všech sluţeb. Nekontrolovaný růst – dalším problémem bývá právě aţ příliš jednoduché vytváření nových strojů, tento fakt vede často k nekontrolovatelnému růstu počtu virtuálních strojů, coţ se můţe velice prodraţit na pouţitých licencích.
1.4 Současné nástroje pro virtualizaci serverů 1.4.1 VMware VMware v současné době nabízí jak virtualizaci na úrovní OS, tak virtualizaci nativní. Zástupcem v první kategorii jsou produkty VMware Server a VMware Workstation, přičemţ tyto produkty jsou určeny především pro koncové uţivatele, jako nástroje pro vývoj a testování. Hlavním vizualizačním produktem společnosti VMware je vSphere Hypervisor (ESXi), který vyuţívá koncept nativní virtualizace. Samotný hypervisor je pouze virtualizační vrstva a vyšší funkce, jako rozloţení zátěţe, či vysokou dostupnost zajišťuje nástroj VMware vCenter Server. Architektura produktu VMware vSphere je zobrazena na obrázku 1-1.
10
Obrázek 1-1: Architektura VMware vSphere
Zdroj [20]
1.4.1.1 Základní technologie pro automatizaci a vysokou dostupnost používaných v produktu VMware vSphere vSphere High Availability (HA) – tato technologie zajišťuje, při výpadku jednoho fyzického serveru v clusteru, přesunutí virtuálního stroje na jiný fyzický server z tohoto clusteru. Ve skutečnosti to funguje tak, ţe virtuální stroj je sledován, zda běţí a pokud přestane odpovídat, proběhne pokus o jeho spuštění jinde (na jiném fyzickém serveru). [22] vSphere Fault Tolerance (FT) – zajišťuje podobnou funkčnost jako HA, ale s tím rozdílem, ţe přesun na jiný fyzický server v rámci clusteru proběhne bez výpadku. Funguje to tak, ţe virtuální stroj si udrţuje svojí přesnou kopii (kopírují se všechny operace a stav paměti) na jiném fyzickém serveru a při zjištění výpadku primárního stroje se vše okamţitě přesměruje na onu kopii. [22] vSphere VMotion – je technologie určená pro přesun virtuálních strojů na jiný fyzický server v rámci clusteru, aniţ by došlo k výpadku přesouvaného virtuálního 11
stroje. Pokud je do clusteru připojeno více diskových úloţišť, lze pouţít VMware Storage VMotion, který dokáţe za běhu, tedy bez výpadku, přesunout i virtuální disky na jiné fyzické úloţiště. [22] vSphere Distributed Resource Scheduler (DRS) – jedná se o technologii pro rozloţení zátěţe v rámci výkonového clusteru. Pro svou funkci vyuţívá jiţ zmíněný VMotion. [22]
1.4.1.2 Transparent Memory Sharing Jedná se o vlastnost VMware ESX hypervisoru, která významně sniţuje mnoţství spotřebované fyzické (RAM) paměti. Po načtení operačního systému a aplikací virtuálního stroje do paměti, VMware memory manager zjistí, zda nejsou některé data v paměti zapsána redundantně. Tyto redundance následně odstraní a data jsou sdílena více stroji najednou. Pokud tedy např. na jednom ESX hypervisoru běţí 4 stejné virtuální stroje s Windows XP, které mají přiděleno kaţdý 1 GB paměti, mělo by být celkem obsazeno 4 GB fyzické paměti. Díky sdílení se ale ve skutečnosti mnoţství obsazené paměti po čase ustálí na cca 500 MB (viz Obrázek 1-2). [13] Obrázek 1-2: Transparent Memory Sharing
Zdroj [13]
12
1.4.2 Microsoft Podobně jako VMware, nabízí společnost Microsoft virtualizaci na úrovni OS i plnou hardwarovou virtualizaci. Zástupcem virtualizace na úrovni OS je u Microsoftu nástroj Windows Virtual PC, který je stejně jako u VMware určen pro koncové uţivatele a jako testovací prostředí. Pro plnou virtualizaci je určen Microsoft Hyper-V. Hyper-V je dostupný buď jako součást operačního systému Microsoft Windows Server 2008 R2, nebo samostatně pouze hypervisor, který se nazývá Hyper-V Server 2008 R2. Na rozdíl od VMware vSphere nepotřebuje Hyper-V, pro funkce jako je vysoká dostupnost, ţádný další nástroj, ale pokud je potřeba spravovat rozsáhlejší infrastrukturu, je k dispozici Microsoft System Center. Tento administrační nástroj je schopen řídit a monitorovat nejen Hyper-V, ale i aplikace a systémy třetích stran, včetně VMware ESX(i). Obrázek 1-3: Architektura Microsoft Hyper-V
Zdroj: [5]
13
Na obrázku 1-3 je zobrazeno schéma architektury Hyper-V. „Základem virtualizační platformy Hyper-V je hypervizor, který zajišť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í.“ [3]
1.4.2.1 Základní technologie pro vysokou dostupnost používaných v produktu Microsoft Hyper-V Live Migration – umoţňuje přesun virtuálního stroje z jednoho Hyper-V serveru na jiný, bez ztráty síťového spojení, tedy bez výpadku pro uţivatele. Tuto technologii lze poté vyuţít jako nástroj pro automatizovaný přesun virtuálních strojů při výpadku nodu (serveru, který je součástí clusteru), nebo pro rozloţení zátěţe mezi servery. [9]
1.4.3 Citrix Společnost Citrix se zaměřuje hlavně na koncept paravirtualizace a plné hardwarové virtualizace, přičemţ v obou těchto kategoriích nabízí jeden produkt s názvem XenServer. Hostované OS tedy mohou běţet paravirtualizovaně (systémy postavené na unixu) nebo plně virtualizované (ostatní operační systémy, u kterých nelze upravit jádro). Výhodou XenServeru je, ţe některé pokročilé funkce pro HA a migrace nabízí jiţ ve verzi, která je k dispozici zdarma. Zdarma je také nástroj pro správu více hypervisorů z jednoho místa Citrix XenCenter.
14
1.4.3.1 Základní technologie pro vysokou dostupnost používaných v produktu Citrix XenServer XenMotion Live Migration – jedná se o základní nástroj pro přesun běţících virtuálních strojů mezi fyzickými servery bez výpadku. Tato funkce je dostupná jiţ ve verzi, která je k dispozici zdarma.
15
2 Virtualizace desktopů 2.1 Virtualizace desktopů – vývoj a použití Základní myšlenka virtualizace desktopů sahá jiţ do sedmdesátých let minulého století. V tu dobu se začalo pouţívat interaktivní rozhraní neboli „terminál“ pro připojení k sálovým počítačům (mainframům), pomocí vhodného síťového spojení. Terminál je pouze velice jednoduché zařízení, které slouţí pro zobrazování výstupu aplikací, které běţely na mainframu. Veškeré výpočetní operace tedy neprováděl terminál, ale sálový počítač. Dnešní podoba virtualizace desktopů funguje na podobném principu. Na serveru, popřípadě na několika serverech, běţí sluţba, která vzdálenému uţivateli poskytuje aplikace nebo kompletní operační systém a které jsou zobrazovány uţivateli pomocí protokolů pro přenos obrazu na vzdáleném terminálu. Obecně se systémy, které poskytují tyto sluţby, nazývají VDI (Virtual Desktop Infrastructure). Společností, zabývající se touto problematikou, je hned několik. Těmi nejvýznamnějšími jsou pak VMware, Citrix a Microsoft. Následující kapitoly jsou zaměřeny na popis a srovnání produktů pro nasazení virtuálních desktopů, které nabízejí tyto tři společnosti.
2.2 Virtualizace desktopů – výhody a nevýhody Desktopová virtualizace je velice zajímavou alternativou pro dnes tradiční PC, u kterých bývá často problém nad jejich kontrolou a údrţbou. I kdyţ je myšlenka vzdálených desktopů poměrně stará, tak nástroje pro VDI nejsou na trhu nijak dlouho, coţ se u některých projevuje jistou mírou nedokonalosti a je zde ještě velký prostor pro zlepšení. Hlavními výhodami, které přináší virtualizace desktopů, jsou: Centralizovaná správa a údržba – díky umístění desktopů v datacentru je správa mnohem snazší a tím i levnější. Flexibilita – vytvoření nového desktopu pro uţivatele je otázkou několika minut. Uţivatel můţe mít přístupných i více desktopů bez nutnosti nákupu koncových zařízení.
16
Dostupnost odkudkoliv – uţivatelé mají své desktopy přístupné z jakéhokoliv místa na světě, stačí pouze připojení k internetu. Kontinuita podniku – porucha koncového zařízení neznamená ztrátu dat uţivatele, vyměnit ho lze i za provozu. Bezpečnost – při ztrátě koncového zařízení nehrozí odcizení důvěrných firemních dat navíc lze lépe kontrolovat zabezpečení jednotlivých desktopů. Virtualizace desktopů ale přináší i některé nevýhody, těmi hlavními jsou: Vysoké vstupní investiční náklady – nasazení VDI sebou přináší, z důvodu nutnosti nákupu serverové infrastruktury a licencí, poměrně velké finanční náklady. Nutnost vyšší odbornosti správců systému – vzhledem k poměrně vysoké sloţitosti systémů pro VDI, jsou nutné mnohem komplexnější znalosti správců.
2.3 Virtualizace desktopů v podání společnosti VMware První pokusy o virtualizaci desktopů provedla společnost VMware jiţ v roce 2002. Jednalo se o point-to-point připojení pomocí RDP protokolu k Windows XP, které běţely na VMware ESX serveru. V roce 2005 pak byl poprvé otestován model připojení pomocí Connection serveru (server pro správu spojení). Skutečná revoluce ale přišla v roce 2009, kdy společnost VMware uvedla na trh produkt VMware View 4.0, kde začala jako primární protokol pro přenos obrazu pouţívat PCoIP. V tuto dobu je aktuálně k dispozici View ve verzi 5 (popř. 5.1) a tato verze je hlavním předmětem zkoumání této práce. [11]
2.3.1 Protokol PCoIP Před popisem konkrétních komponent produktu VMware View, je dobré přiblíţit komunikační protokol PCoIP pro přenos obrazu a zvuku, jeţ je základním stavebním kamenem celého systému. Tento protokol, který společnost VMware zakoupila společně se společností Teradici, pracuje při přenosu obrazu na principu rozloţení na jednotlivé pixely, přičemţ na kaţdý jednotlivý pixel pouţije co nejoptimálnější kompresi (multi-codec protokol). Navíc je do PCoIP protokolu zakomponován i přenos ostatních sluţeb, jako je USB konektivita nebo přenos zvuku, tzv. host rendering. Výhodou tohoto řešení je, ţe lze takto
17
lépe řídit latence všech vstupních a výstupních zařízení, podle kvality pouţitého připojení (Dynamic network adaptation). [8]
2.3.2 Architektura produktu VMware View Architektura produktu VMware View se skládá z několika komponent, které spolu navzájem komunikují (viz Obrázek 2-1). Základním kamenem celého systému je jiţ zmíněný hypervisor ESXi, kde běţí samotné virtuální desktopy a vCenter Server, pomocí kterého jsou tyto desktopy řízeny. Hypervisor se nijak neliší od toho, který se pouţívá pro serverovou virtualizaci, vCenter Server je ale rozšířen o některé další funkcionality (View Composer). Obrázek 2-1: Architektura produktu VMware View
Zdroj: [16]
18
Jak je vidět na obrázku 2-1, komponent v systému VMware View je opravdu hodně. V následujících sekcích je tedy postupně popsána jejich funkce a jejich význam pro systém jako celek.
2.3.2.1 Klientská zařízení Hlavní výhodou tohoto systému je právě nezávislost na pouţitém koncovém zařízení nebo místě, odkud se ke svému desktopu uţivatel připojuje. Uţivatel můţe pouţít firemní PC, jeho osobní notebook, tenkého klienta, Mac, nebo třeba tablet, ale stále bude mít k dispozici stejný desktop se stejným operačním systémem. V případě pouţití klasického Windows PC, Mac nebo tabletu se pro zobrazení virtuálního desktopu uţivatele pouţívá View Client. Výhodou tohoto klienta je, ţe lze pomocí něj prodlouţit morální ţivotnost starých PC nebo na non-Windows zařízeních provozovat Windows operační systémy a zvýšit tak jejich univerzálnost. View Client – jedná se o software, který slouţí pro připojení k View desktopu z operačního systému Windows, MacOS, Linux, ale také z mobilních systémů Android a iOS. K připojení lze pouţít protokol RDP, nebo PCoIP. Existují i neoficiální verze View klienta, např. VMware View Open Client pro linux, který je šířen pod LGPL licencí. Zde ale není integrována podpora pro PCoIP protokol. View Client with Local Mode – speciální verze View klienta, která je rozšířena o moţnost staţení virtuálního desktopu na klientský PC a pouţívat ho i bez připojení k síti. Po opětovném navázání spojení se změny provedené v reţimu offline sesynchronizují s desktopem umístěným na serveru. Klient s Local Mode je k dispozici pouze pro OS Windows. Tenký klient – jedná se o speciální PC, které je optimalizováno pro malou spotřebu elektrické energie a dlouhou ţivotnost. Většinou obsahují upravenou verzi systému Windows, nebo linux a s výrobcem upraveným View klientem. Výhodou je, ţe tyto zařízení většinou podporují širší škálu virtualizačních technologií. Zero klient – toto zařízení jiţ neobsahují ţádný operační systém a nemají tedy ţádnou aplikační logiku, slouţí pouze jako prezentační rozhraní. O přenášení obrazu (primárně pomocí protokolu PCoIP) se stará čip vyvinutý, stejně jako u protokolu PCoIP, společností Teradici. Obraz tedy není zpracováván softwarově, jako je tomu 19
u View klienta, ale hardwarově pomocí zmíněného čipu. Výhodou tohoto zařízení je velmi vysoká efektivita a nízké náklady na provoz, nevýhodou je ale velmi úzká moţnost vyuţití.
2.3.2.2 View Connection Server View Connection Server se instaluje jako sluţba na MS Windows Server a slouţí jako broker pro připojení klientů k virtuálním desktopům. Při pokusu o navázání spojení klienta ho nejprve ověří vůči adresářové sluţbě MS Active Directory a poté ho nasměruje na příslušný virtuální desktop, fyzický PC, nebo Terminal Services Server. View Connection server poskytuje následující funkcionalitu [16]: Ověření uţivatelů, přidělování oprávnění uţivatelů k virtuálním desktopům, přiřazení virtuálních aplikací VMware ThinApp k virtuálním desktopům, správu a monitoring navázaných spojení, navazování zabezpečeného spojení mezi uţivatelem a virtuálním desktopem, single sign-on, nastavování a aplikování politik.
2.3.2.3 View Agent View Agent komunikuje po navázání spojení s View klientem a poskytuje sluţby jako je monitorování spojení, tisky, přístup k lokálním USB zařízením nebo single sign-on a instaluje se na všechny virtuální desktopy, fyzické PC a terminálové servery, které mají být dostupné pomocí VMware View. Tento agent je také nutný pro správné fungování linkovaných klonů, které jsou popsány později. [16]
2.3.2.4 View Administrator Jedná se o webovou aplikaci pro správu a monitoring View Connection Serveru. Administrátor zde můţe vytvářet pooly (skupiny) virtuálních desktopů, nastavovat oprávnění k přístupu k těmto poolům, přiřazovat ThinApp aplikace, spravovat propojení s vCenter server, atd. [16]
20
2.3.2.5 View Composer Tato sluţba pro vytváření a správu virtuálních strojů se instaluje jako nadstavba pro vCenter Server, tedy i na stejný operační systém. VMware View Composer umoţňuje vytváření poolů tzv. linkovaných klonů, které vycházejí z jednoho „rodičovského“ virtuálního stroje. Kaţdý linkovaný klon se pro uţivatele jeví jako nezávislý virtuální stroj s unikátní IP adresou a jménem, ale ve skutečnosti se jedná pouze o rozdílový disk, který sdílí data operačního systému s rodičovským virtuálním strojem a na daný rozdílový disk zapisuje pouze změněná data. Tímto způsobem lze ušetřit aţ 90% diskové kapacity. Obrázek 2-2: VMware View Composer
Zdroj: [17]
Jelikoţ je obsah virtuálního stroje fyzicky rozdělen na operační systém, aplikace a uţivatelská data (viz Obrázek 2-2), je moţné měnit, patchovat nebo upgradovat samotný operační systém, aniţ by uţivatelé přišli o svá data nebo nainstalované aplikace. Toto řešení přináší obrovskou flexibilitu pro administrátory a pracovníky helpdesku. Pro optimalizaci vyuţití diskového prostoru je ve View Composeru k dispozici tzv. Refresh, Recompose a Rebalance [17]. Refresh – vrátí linkované klony do jejich původního stavu a velikosti. Smaţou se tedy veškeré změny provedené uţivatelem. 21
Recompose – provede změnu master image (rodičovského virtuálního disku) u všech linkovaných klonů v daném poolu při zachování uţivatelských dat. Tímto způsobem lze snadno provést distribuci upraveného operačního systému všem uţivatelům. Rebalance – provede rozloţení, či přesun linkovaných klonů na jiné datové úloţiště.
2.3.2.6 View Transfer server View Transfer server zprostředkovává přenos dat mezi datacentrem a View desktopem. Tato sluţba je potřeba pro podporu klientů pracujících v „Local mode“ reţimu [16]. Provádí přenos souborů mezi datacentrem a lokálním desktopem. Provádí synchronizaci uţivatelských dat, a to v časových intervalech, dle nastavených politik ve View Administrator.
2.3.2.7 VMware ThinApp Jedná se o nástroj pro virtualizaci aplikací, které tak izoluje od operačního systému a od ostatních aplikací. Pro fungování ThinApp aplikace není potřeba instalace agenta na hostitelský operační systém. ThinApp pracuje na principu zabalení všech souborů a registrů, potřebných pro běh dané aplikace, do jednoho spustitelného balíku, který můţe být distribuován na jakýkoliv operační systém (Windows). Umoţňuje tak provozovat i starší aplikace, které by normálně na moderních operačních systémech nebylo moţné spustit. ThinApp umoţňuje dva módy spouštění aplikací: 1. Streaming Execution mode – aplikace jsou umístěny centrálně na síťovém úloţišti a uţivatelé k nim přistupují pomocí zástupců umístěných na klientských PC (popřípadě také na síťovém úloţišti). V tomto módu se nepřenáší celá aplikace, ale pouze data, která jsou pro aktuální běh aplikace potřeba. Výhodou tohoto řešení je snadná správa z pohledu administrátora a síťový provoz rozloţený v čase. Průběh spouštění aplikací ve Streaming Execution módu [1]: 1. Při spuštění aplikace uţivatelem se nejprve přenese a spustí ThinApp runtime komponenta – zobrazuje GUI, které zobrazuje průběh načítání aplikace.
22
2. Spuštěný runtime nyní načte potřebné registry a soubory, které jsou uloţeny v 64KB blocích. Přenos dat probíhá pomocí standardního MS Windows sdílení. 3. Z prvního bloku dat jsou nejprve načteny registry a následně vlastní aplikace .exe. 4. Bloky, které jsou potřebné pro běh aplikace, jsou načteny přímo do Windows disk cache, která je logickou reprezentací pamětí na operačním systému lokálního PC. Pokud jsou data v ThinApp balíčku komprimována, do paměti jsou načtena jiţ nekomprimovaná. 5. Pokud uţivatel pouţije nějakou funkci aplikace během práce, která vyţaduje další data, provede se poţadavek na načtení dalších dat a uloţí se do paměti. Pokud vznikne poţadavek aplikace na data, která byla jiţ jednou načtena, pouţijí se z cache paměti. 6. Virtualizované aplikace většinou potřebují také nějaká data a uţivatelská nastavení zapisovat. Zápis těchto dat probíhá na úloţiště, které definuje administrátor při vytváření aplikace (tzv. Sandbox folder). Obrázek 2-3: ThinApp Streaming Execution mode
Zdroj [1]
2. Deployed Execution mode – v tomto módu jsou balíky s aplikacemi nakopírovány lokálně na klientské PC. Uţivatel tedy aplikace spouští ze svého pevného disku 23
a můţe je tak pouţívat i bez připojení k síti. Výhodou tohoto řešení je právě nezávislost na připojení k síti, ale nevýhodou je horší moţnost správy a vysoké nárazové vytíţení sítě. Zabezpečení ThinApp aplikací je řešeno definováním povolených skupin Active Directory při vytváření balíku a určuje, kdo ji můţe spustit, a kdo ne. Nově je nyní k dispozici nástroj Horizon Application Manager, který povyšuje distribuci ThinApp aplikací na úroveň software-as-a-service řešení (SaaS). Aplikace jsou uţivateli zpřístupněny pomocí webového portálu, přičemţ zobrazené aplikace lze řídit pomocí Active Directory oprávnění. Pro fungování tohoto systému je nutná instalace agenta na klientské zařízení. [14] Obrázek 2-4: Horizon Application Manager
Zdroj: [14]
2.4 Virtualizace desktopů v podání společnosti Microsoft Společnost Microsoft nabízí dva druhy desktopové virtualizace, a to lokální a vzdálenou. U lokální virtualizace desktopů běţí virtuální prostředí kompletně na uţivatelském PC a vyuţívají se při tom technologie, jako je Windows Virtual PC, Windows XP Mode, Microsoft Enterprise Desktop Virtualization (MED-V) a Microsoft Application Virtualization (App-V). Tento způsob virtualizace desktopů je ale určen především pro nasazení malého rozsahu a nelze jí srovnávat s VMware View, proto zde není podrobněji zkoumán. 24
Z pohledu enterprise nasazení je mnohem zajímavější virtualizace pomocí vzdálené plochy (Remote Desktop Virtualization), kde virtuální infrastruktura běţí na serveru (většinou Microsoft Windows Server). Remote Desktop Virtualization je sloţena z následujících částí [9]: Remote Desktop Services (RDS) – tato základní sluţba (původně Terminal Services) slouţí pro přístup uţivatelům ke vzdálené ploše, nebo virtuálnímu desktopu pomocí Remote Desktop Protocol (RDP). Microsoft Application Virtualization for Remote Desktop Services (App-V for RDS) – tato sluţba slouţí pro převod klasických aplikací do formy centrálně spravovaných sluţeb a umoţňuje jejich distribuci uţivatelům pomocí protokolu RDP. Aplikace pak tedy běţí na serveru a uţivateli se zobrazuje pomocí RDP na jeho klientské stanici. Microsoft Virtual Desktop Infrastructure (VDI) - Microsoft VDI je architektura skládající se z několika komponent, jako je Hyper-V, Remote Desktop Services, Microsoft Desktop Optimization Pack (MDOP), a produkty Microsoft System Center (viz Obrázek 2-5). Tento systém umoţňuje desktopovým systémům, jako je např. Windows 7 Enterprise běţet na hypervisoru v datacentru a uţivatel k němu pak přistupuje pomocí RDP protokolu. K dispozici jsou buď osobní virtuální desktopy, které jsou upraveny dle poţadavků uţivatele, nebo sdílené virtuální desktopy, které jsou všechny identické. Obrázek 2-5: Architektura Microsoft VDI
Zdroj: [9]
25
V poslední době společnost Microsoft začíná spolupracovat s některými partnery z oboru virtualizace desktopů, jako je např. společnost Citrix. Tato spolupráce umoţňuje vyuţít pokročilých komunikačních Citrix protokolů na infrastruktuře Microsoft Hyper-V.
2.4.1 Komponenty produktu Microsoft Remote Desktop Services Remote Desktop Connection Client (RDC) – jedná se o klienta pro připojení ke vzdálené ploše, aplikaci, nebo k virtuálnímu desktopu. Podpora pro VDI je u klienta od verze 7.0, který je automaticky dostupný ve Windows 7 (pro Windows Vista a Windows XP je k dispozici ke staţení jako update). [9] Remote Desktop Session Host (původně Terminal Services) – server, ke kterému se připojuje RDC a zajišťuje distribuci aplikací a vzdálené plochy uţivateli. [9] Remote Desktop Web Access – webové rozhraní, kde mají uţivatelé jednoduše a přehledné dostupné své vzdálené aplikace, vzdálené plochy a virtuální desktopy. [9] Remote Desktop Connection Broker – tato sluţba zajišťuje připojení klienta ke stejné session, ze které se jiţ dříve odpojil a rozloţení zátěţe při připojování k farmě terminálových serverů. [9] Remote Desktop Gateway – zajišťuje zabezpečené připojení klienta přes internet k firemním desktopům, které jsou za firewallem. Jedná se o alternativu k pouţití VPN. [9] Remote Desktop Licensing – tato sluţba umoţňuje správu licencí (RDS CALs), které jsou přidělovány klientům při připojení ke sluţbě Remote Desktop Services. Pro kaţdého uţivatele, nebo zařízení, které se chce připojit, musí být dostupná licence (CAL). [9] Remote Desktop Virtualization Host – podobně jako RD Session Host poskytuje uţivatelům přístup ke vzdáleným aplikacím a vzdáleným plochám, ale navíc ještě umoţňuje přístup k virtuálním desktopům běţících na Hyper-V. [9] Celková funkčnost a komunikace mezi těmito komponentami je znázorněna na obrázku 2-6.
26
Obrázek 2-6: Microsoft VDI – schéma komunikace komponent
Zdroj: [9]
2.4.2 Základní nástroje pro správu Microsoft VDI System Center Configuration Manager – nástroj pro komplexní správu, update a vytváření serverů, klientských PC, virtuálních desktopů, atd. Configuration Manager je primárně určen pro správu systémů na bázi Windows, ale můţe spravovat i jiné IT systémy. [9] System Center Operations Manager – nástroj pro správu softwaru od společnosti Microsoft. Zajišťuje větší efektivitu a vyšší kontrolu nad fyzickou a virtuální infrastrukturou. [9] System Center Virtual Machine Manager – produkt, který umoţňuje unifikovanou správu jak fyzických, tak virtuálních strojů, konsolidaci málo vyuţívaných fyzických serverů a rychlé vytváření nových virtuálních strojů. [9]
27
2.5 Virtualizace desktopů v podání společnosti Citrix Na rozdíl od ostatních společností, se Citrix u svého VDI řešení zaměřuje primárně na management nástroje a komunikační protokoly, přičemţ nezáleţí na tom, jaké virtuální prostředí pro běh desktopů je pouţito. Jako hypervisor lze tedy pouţít XenServer, ESX, Hyper-V, nebo třeba VirtualBox od společnosti Oracle. XenDesktop, jak společnost Citrix své VDI řešení pojmenovala, je postaveno na technologii přístupu k virtuálním desktopům Citrix FlexCast. FlexCast se skládá z následujících základních modelů virtuálních desktopů [2]: Hosted Shared – tento sdílený a hostovaný model poskytuje standardizované a uzamčené virtuální prostředí, které je určeno především pro uţivatele, kteří nepotřebují individualizované desktopy. Hosted VDI – tento model nabízí individualizované desktopy, ke kterým uţivatelé přistupují vzdáleně z jakéhokoliv zařízení. Hostované VDI desktopy mohou být buď sdílené více uţivateli, nebo dedikované pro kaţdého uţivatele zvlášť, přičemţ mohou být virtuální, nebo fyzické. Streamed VHD -
umoţňuje vyuţití výpočetního výkonu klientských zařízení,
přičemţ ale umoţňuje centralizovanou správu desktopů. Local VM – distribuuje centrálně spravovaný image desktopu na koncová zařízení a umoţňuje tak pracovat uţivatelům, i kdyţ nejsou připojeni k síti.
2.5.1 Architektura hostovaných VDI desktopů Aby bylo moţné srovnání s produkty ostatních společnostní, je tato část zaměřena právě na Hostované VDI. Architektura produktu XenDesktop je sloţena ze tří hlavních modulů: Control Module, Desktop Module (v tomto případě část zabývající se VDI) a Imaging Module (viz Obrázek 2-7). Jejich význam je postupně vysvětlen níţe.
28
Obrázek 2-7: Architektura Citrix Hosted VDI
Zdroj: [2]
2.5.1.1 Control Module Control Module je základní část, která slouţí pro přístup a ověření uţivatelů, doručování, správu a údrţbu virtuálních desktopů. Tento modul je sloţen z následujících sluţeb [2]: XenDesktop Controler – poskytuje ověření uţivatele a následné přidělení desktopu. Veškeré informace o místech ukládá do SQL databáze. Je doporučeno mít alespoň dva controllery, z důvodu vysoké dostupnosti a rozloţení zátěţe. Web Interface – po přihlášení poskytuje uţivateli snadný přístup k jemu dostupným zdrojům. Při rozsáhlejším nasazení se opět doporučuje zdvojení této sluţby, kvůli rozloţení zátěţe.
29
SQL Database - do databáze se ukládají veškeré informace o konfiguraci, stavu desktopů a jejich vyuţití. License Server – poskytuje licence pro všechny komponenty XenDesktop. Při nedostupnosti této sluţby jsou licence funkční ještě 30 dní.
2.5.1.2 Imaging Module Imaging Modul zajišťuje doručení instalačního image do virtuálních desktopů. Hlavním cílem tohoto modulu je sníţení počtu instalačních image na minimum. Tento modul se skládá z následujících sluţeb [2]: Installed Images – poskytují instalační image pro vzdálené virtuální nebo fyzické desktopy. Machine Creation Services – poskytuje image pouze pro virtuální desktopy, běţící na hypervisoru. Virtuální image jsou jiţ připraveny v daném poolu virtuální desktopů a jsou naklonovány dle potřeby. Následně se provedou úpravy, jako je změna jména, či SID. Provisioning Services – poskytuje image pro virtuální a fyzické desktopy za vyuţití bootování ze sítě.
2.5.1.3 Desktop Modules S ohledem na poţadavky uţivatelů na pouţívání desktopů, lze Desktop Moduly rozdělit na tři skupiny [2] - poolované a dedikované desktopy, streamované desktopy, fyzické a existující desktopy. 1. Poolované a dedikované desktopy – po zadání poţadavku uţivatele přes Web Interface, zajistí controller vytvoření virtuálního desktopu pomocí MCS (Machine Creation Service). MCS nemusí být ţádná samostatná sluţba, klidně lze vyuţít funkcionality pouţitého hypervisoru (ESXi, Hyper-V, atd..). U tohoto typu desktopů se veškeré změny provedené v desktopu ukládají na rozdílový disk a následně se, dle nastavení, data po restartu desktopu maţou, nebo zachovají.
30
Pooled – po restartu desktopu se rozdílový disk smaţe. o Pooled-Random – uţivatel se připojuje k libovolnému desktopu v rámci poolu. o Pooled-Static – uţivatel se pokaţdé připojuje ke stejnému desktopu. Dedicated – po restartu se rozdílový disk zapracuje a uloţí se. V tomto reţimu se uţivatel vţdy připojuje ke stejnému desktopu. 2. Streamované desktopy – Fungují stejně jako u předchozí skupiny desktopů, s tím rozdílem, ţe image jsou distribuovány pomocí Provisioning Service, za vyuţití bootování ze sítě (DHCP/TFTP/PXE). Tyto desktopy, díky bootování ze sítě, nejsou omezeny pouze na běh na hypervisoru, ale lze je distribuovat třeba i na blade PC, nebo jako Streamed VHD na koncové zařízení uţivatele. 3. Existující a fyzické desktopy – tento způsob se nejvíce podobá klasickému modelu s tradičními PC. Operační systém není vytvářen pomocí single-image management systému, ale je unikátní a je instalován, či klonován ručně. Existující desktopy – jedná se většinou o desktopy, které byly pomocí P2V (Physical to Virtual) nástrojů přimigrovány do virtuálního prostředí. Fyzické desktopy – tyto desktopy jsou většinou instalovány na sadu blade PC, které jsou umístěny v datacentru a uţivatelé k nim přistupují 1:1.
2.6 Porovnání výhod a nevýhod jednotlivých produktů pro virtualizaci desktopů Kaţdý z uvedených produktů pro virtualizaci desktopů má oproti konkurentům nějaké klady a zápory. Kromě komunikačních protokolů lze jen těţko porovnávat konkrétní parametry, protoţe kaţdý systém pouţívá trochu odlišný přístup. Proto je toto porovnání spíše na obecné rovině z pohledu administrátora a uţivatele.
2.6.1 VMware View VMware u svého VDI řešení těţí z velice vyspělé serverové virtualizace, kterou se zabývá uţ relativně dlouhou dobu a také díky protokolu PCoIP, který zakoupil jako patent 31
se společností Teradici. Díky tomu je View na opravdu vysoké úrovni a je tak vhodný pro nasazení i do enterprise prostředí. Klady Postaveno na stabilním a optimalizovaném virtuálním prostředí. Relativně jednoduchá implementace do existující firemní infrastruktury. Intuitivní administrace desktopů. Podpora hardwarové akcelerace protokolu PCoIP. Propracovaný systém sdíleného image (thin provisioning), který je vhodný pro nasazení do učeben a kiosků. Zápory Závislost na Active Directory prostředí. Koncová zařízení musí podporovat PCoIP (procesor musí mít min. instrukční sadu SSE2), připojení pomocí RDP není, v případě View, příliš pouţitelné.
2.6.2 Microsoft VDI VDI řešení od společnosti Microsoft je postaveno na jiţ existujícím Hyper-V hypervisoru a RDP protokolu, přičemţ byl pro potřeby VDI dopracován pouze management nástroj. I kdyţ je tento nástroj pro enterprise nasazení vysloveně určen, je reálné nasazení vzhledem jistým nedostatkům (právě RDP protokolu) minimálně diskutabilní. Klady Pouţití MS Windows operačního systému ve virtuálních desktopech je licenčně zvýhodněno v prostředí MS VDI. Cena. Komplexnost řešení. Zápory Konfigurace je rozmístěna do několika nástrojů, coţ značně znepříjemňuje administraci celého řešení. Chybí podpora pro sdílený image (thin provisioning). 32
2.6.3 Citrix XenDesktop Citrix je nejstarším zástupcem ve VDI řešeních, coţ se projevuje na komplexnosti a vyzrálosti tohoto produktu. Velkou výhodou je i nezávislost na pouţitém hypervisoru. Klady Komplexnost řešení. Nezávislost na pouţitém hypervisoru. Kvalitní protokol pro přenos obrazu a zvuku (Citrix HDX). Zápory Vysoká cena. Relativně vysoká sloţitost instalace a konfigurace.
33
3 Nástroje pro plánování nasazení VDI Před samotným nasazením VDI technologie je velice důleţité zjistit, kolik výkonu a diskové kapacity bude potřeba pro běh virtuálních desktopů. Podle tohoto zjištění poté probíhá nákup serverové infrastruktury. Této problematice je nutné věnovat velkou pozornost, aby nedošlo k poddimenzování výkonu, coţ by vedlo k uţivatelskému nekomfortu, nebo naopak ke zbytečnému předimenzování výkonu, coţ by zase vedlo ke značnému navýšení nákladů na celý projekt. Určení přesné potřeby výkonu je ale většinou poměrně sloţitá záleţitost a zesloţiťuje to i fakt, ţe moderní VDI nástroje nabízejí různé metody pro úsporu pamětí a diskové kapacity, proto v ţádném případě nestačí, při přechodu z klasických PC na VDI, pouhý součet pamětí, procesorových jader a diskové kapacity jednotlivých klientských PC. Z tohoto důvodu dávají výrobci k dispozici různé metodiky pro výpočet potřebného výkonu. Pomoci mohou ale také nástroje pro simulaci vytíţení virtuálního prostředí, jako je např. VMware View Planner nebo The Remote Desktop Load Simulation toolset od společnosti Microsoft. Bohuţel při testování těchto nástrojů jsem zjistil, ţe jejich flexibilita testovaného prostředí je velice malá, a proto je jejich pouţití v reálném světě přinejmenším sporné.
3.1 VMware View Planner Jedná se o zátěţový simulátor pro VMware View prostředí, který lze pouţít pro nasimulování práce daného mnoţství uţivatelů na virtuálních desktopech. Tímto nástrojem lze snadno zjistit následky změn nastavení virtuálních desktopů, jako je třeba změna mnoţství přidělené paměti nebo virtuálních CPU. Testování zátěţe můţe probíhat ve třech následujících módech [18]: Remote mode – v tomto reţimu je ke kaţdému virtuálnímu desktopu připojen jeden virtuální klient, který řídí vytíţení desktopu. Tento mód je nejvíce náročný na hardware, ale také nejvíce reprezentuje skutečné pouţití systému. Passive Client mode – v pasivním reţimu můţe být více virtuálních desktopů, neţ klientů, kteří jsou pouze „diváci“ a vytíţení si řídí sám virtuální desktop. Tento mód je méně náročný na HW neţ remote mode, ale stále ještě dostatečně simuluje reálné pouţití. 34
Local mode – v tomto reţimu se nepouţívají virtuální klienti a veškeré řízení i provádění testů probíhá ve virtuálních desktopech. Jelikoţ zde není generován ţádný síťový provoz, není tento reţim tak reprezentativní, jako předchozí dva módy. Obrázek 3-1: VMware View Planner – architektura
Zdroj: [18]
35
4 Virtuální učebna – sizing, cenová kalkulace, SWOT analýza Řešení pro virtuální desktopy je navrhováno pro jednu počítačovou učebnu, kde je umístěno 21 pracovních stanic, které budou vyuţívány studenty pro výuku kancelářského balíku MS Office a práci s internetem. Serverová část tohoto řešení je tedy navrţena pro méně výpočetně náročné aplikace, ale s ohledem na moţnost budoucího snadného rozšíření na další učebny, či jiná zařízení. Následující tabulky zobrazují poţadovaný cílový stav. Tabulka 4-1: Cílový stav učebny - klientská část
Klientská část Počet stanic v učebně
20 + 1 (vyučující)
Klientský OS
MS Windows XP SP3
Klientská zařízení
Zero klient (HW podpora PCoIP)
Zdroj: [Autor] Tabulka 4-2: Cílový stav učebny - serverová část
Serverová část Pouţitý serverový HW
Blade systém (min. 2x blade server, kvůli redundanci)
Diskové úloţiště
Fiber channel sdílené diskové pole
VDI
VMware View 5
Zdroj: [Autor]
4.1 Sizing serverového HW – zjištění potřebného výkonu Cílem této části je nalézt optimální výkonové parametry serverové části systému, a to tak, aby práce na virtuálních desktopech byla z hlediska výkonnosti dostatečně komfortní, ale zároveň investiční náklady nebyly nepřiměřeně vysoké. Jelikoţ se při testování ukázalo, ţe VMware View Planner není zcela vhodný pro výpočet reálně potřebného výkonu, je potřebný výkon určen především odhadem dle dokumentace a následné ověření a porovnání s výsledky online nástroje pro VDI sizing, který je dostupný na webu myvirtualcloud.net.
36
Metody zjišťování potřebné výkonnosti HW: 1. Odhad dle doporučení v dokumentaci k produktu VMware View pro virtuální desktopy s Windows XP. [13] 2. Porovnání odhadu s výsledky z online nástroje pro VDI sizing, který je dostupný na webu myvirtualcloud.net.
4.1.1 Odhad potřebného výkonu dle dokumentace k produktu VMware View Výsledkem těchto odhadů je vţdy minimální potřebný výkon/kapacita. Proto jsou uvaţovány spíše jako hodnoty, pod které se nesmí výsledná konfigurace serveru dostat. CPU – Dle dokumentace potřebuje 1 virtuální desktop s Windows XP průměrně pro svůj běh 130 Mhz, coţ dělá pro 21 virtuálních desktopů 2,73 Ghz cyklů CPU. Je nutné ale počítat také s reţií samotné vizualizační technologie a s výkonovými špičkami, které mohou u učeben nastat typicky na začátku vyučovací hodiny, kdy se všichni najednou přihlašují. Obecně se pro tyto účely přidává cca 25 % potřebného výkonu navíc. Celkově tedy je potřeba minimálně 3,41 Ghz procesorového výkonu. Paměť (RAM) -
U paměti je situace o něco sloţitější a to právě díky funkci
Transparent Memory Sharing. Pokud bych tuto funkci zanedbal a přidělil kaţdému virtuálnímu stroji 1 GB paměti, bylo by minimální mnoţství potřebné fyzické paměti 22 GB (21 GB virtuální stroje + 1 GB reţie virtualizace). Ve skutečnosti ale je, díky sdílení a optimalizaci, celkové mnoţství potřebné paměti, při vyuţití běţných aplikací, niţší (viz Tabulka 4-3). Tabulka 4-3: Minimální množství potřebné paměti
Aplikace
Unikátní minimální potřebné množství paměti
MS Windows XP SP3
125 MB
MS Word
15 MB
MS Excel
15 MB
Mozilla Firefox
30 MB
Adobe Reader
20 MB
37
Celkem
205 MB
Zdroj: [Autor]
Pokud tedy uvaţujeme minimální mnoţství paměti pro jeden virtuální desktop 205 MB, je celkem potřeba pro 21 desktopů alespoň 4,3 GB fyzické paměti. Stejně jako u CPU, je i zde nutné počítat s výkonovými špičkami, proto je potřeba toto minimum navýšit o dalších 25 %, coţ tedy celkem dělá 5,38 GB + 1 GB. Diskové úložiště (výkon) – Minimální diskový výkon, potřebný pro provoz jednoho virtuálního desktopu s Windows XP, je dle dokumentace 5 IOPS (I/O operací za sekundu), přičemţ poměr čtení/zápis je cca 30/70. Minimální datová propustnost je 115 KBps. Pro 21 desktopů je tedy potřeba minimálně 105 IOPS a 2415 KBps. Jelikoţ je celkový výkon na diskových operacích silně závislý, je pro výkonové špičky uvaţováno 50 % IOPS navíc. Celkový minimální diskový výkon tedy musí být 158 IOPS (47 IOPS čtení a 111 IOPS zápis) a datová propustnost 3019 KBps. Diskové úložiště (kapacita) – Minimum prostoru na systémovém svazku pro běh Windows XP je 10 GB. Dále je dobré počítat s tím, ţe systém Windows automaticky vytváří stránkovací a swapovací soubory ve velikosti přidělené paměti (RAM), o které je potřeba přidělenou diskovou kapacitu navýšit. Jednotlivé poloţky jsou rozepsány v tabulce 4-4. Tabulka 4-4: Minimální diskový prostor
Základní kapacita pro OS
10 GB
Reţim spánku (hyberfil)
1 GB
Swap
1 GB
Logy
100 MB
Celkem
12,1 GB
Zdroj: [Autor]
V případě, kdyţ by byly virtuální desktopy klonovány standardním způsobem, bylo by potřeba pro 21 strojů, i s rezervou 15 %, 292,2 GB diskového prostoru. Při vyuţití VMware View Composeru lze ale tento poţadovaný prostor sníţit o 50 – 90 %. Pokud tedy budu uvaţovat nejhorší variantu a úspora je pouze 50 %, minimální poţadovaný prostor je 146,1 GB.
38
Síťový provoz (LAN) – Při pouţití přenosového protokolu PCoIP je dle testů a dokumentace potřeba cca 50 – 150 kbps na jednoho klienta (způsob vyuţití je pro běţnou kancelářskou práci, nikoliv sledování videa, či hraní her). Kdyţ budeme počítat s nejhorší variantou, je při práci 21 klientů potřeba minimálně 3,15 Mbps přenosové kapacity. [15] Tabulka 4-5: Shrnutí odhadu minimálního potřebného výkonu dle dokumentace VMware View
Shrnutí odhadu minimálního potřebného výkonu dle dokumentace VMware View CPU
3,41 Ghz
Paměť (RAM)
6,38 GB
Diskové úloţiště (výkon)
158 IOPS, 3,02 MBps
Diskové úloţiště (kapacita)
146,1 GB (při použití View Composer)
Síťový provoz (LAN)
3,15 Mbps
Zdroj: [Autor]
39
4.1.2 Zjištění potřebného výkonu pomocí online nástroje pro VDI sizing, který je dostupný na webu myvirtualcloud.net Obrázek 4-1: Výpočet potřebného výkonu pomocí nástroje pro sizing VDI
Zdroj: [Autor]
Kdyţ porovnáme výkon vypočtený pomocí nástroje na webu myvirtualcloud.net (viz Obrázek 4-1) a výkon, který byl vypočten dle dokumentace k produktu VMware View, je vidět, ţe se výsledky v některých aspektech relativně významně liší. Odchylky jsou pravděpodobně dány tím, ţe autor kalkulátoru na webu myvirtualcloud.net se neřídí dokumentací, ale svými zkušenostmi se samotným produktem. Na tento fakt i sám autor upozorňuje. Nejvýznamnější odchylka je ve výpočtu potřebného CPU a IOPS. U CPU je, dle dokumentace, potřeba 3,41 GHz, zatímco dle kalkulátoru pouze 656MHz. Diskového výkonu ale je dle kalkulátoru potřeba místo 158 IOPS alespoň 420 IOPS. Co se týče paměti RAM, i zde je relativně velký rozdíl, ten je ale dán tím, ţe autor kalkulátoru pouţívá při výpočtu pouze násobky osmi a jedná se o nejhorší scénář vyuţití paměti (bez vyuţití sdílení paměti). Kapacita HDD více méně odpovídá výpočtu dle dokumentace.
40
Při volbě výsledné HW konfigurace je tedy vţdy počítáno s vyšší vypočtenou hodnotou.
4.2 Návrh a cenová kalkulace výsledné HW a SW konfigurace Při návrhu HW počítám s tím, ţe základní LAN a FC infrastruktura je jiţ v prostředí, kde je virtualizace desktopů nasazena, vybudována a potřebné investice tedy budou pouze do rozšíření o potřebný výkon. V tomto případě je infrastruktura zaloţena na IBM blade řešení s FC diskovým polem. Veškeré uvedené ceny jsou bez DPH a slev (ceníkové). Servery – 2x IBM BladeCenter HS22V Tabulka 4-6: Cena potřebných serverů
Blade Base 1: HS22V
23797 Kč
Intel Xeon Processor E5649 6C 2.53GHz 12MB Cache 1333MHz
22463 Kč
80w 32GB PC3L-10600 CL9 ECC DDR3 1333MHz VLP RDIMM
12880 Kč
Qlogic 8Gb Fibre Channel Expansion Card
17319 Kč
IBM USB Memory Key for VMWare ESXi 5.0
1430 Kč
3 Year Onsite Repair 24x7 4 Hour Response
8383 Kč
Celkem za BladeCenter HS22V
86272 Kč
Celkem za servery
172544 Kč
Zdroj: [Autor]
Diskové úložiště Vzhledem k jiţ existující infrastruktuře, je disková kapacita neceněna způsobem cena/GB diskové kapacity. Tato hodnota vychází z celkové ceny jiţ existujícího diskového pole. Tabulka 4-7: Cena potřebného diskového prostoru
Cena za 1GB na současném diskovém poli Cena za 300GB na současném diskovém poli
125 Kč 37500 Kč
Zdroj: [Autor]
Software Velkou výhodou při nasazení na vysoké škole je moţnost vyuţití tzv. Software Assurance smluv pro školství, které umoţňují nákup licencí produktů Microsoft 41
za velice zajímavé ceny. Díky této smlouvě je také moţné vyuţít nejnovější verze daného produktu. Pro školství jsou ale výhodnější ceny i od společnosti VMware, která u všech produktů nabízí tzv. academic licence. Tabulka 4-8: Cena potřebného softwaru
2x Windows Server Standard 2008 R2 Sngl (MS Select pro školství) 3x Academic VMware View 5 Premier Bundle: 10 Pack Celkem za software
3500 Kč 32329 Kč 107487 Kč
Zdroj: [Autor]
Zero Client Tato poloţka je volitelná a záleţí na tom, zda jsou, nebo nejsou k dispozici starší PC z původní učebny. Výhody a nevýhody obou řešení jsou popsány níţe. Pro přístup ze zero klientů na virtuální desktopy s operačním systémem MS Windows, je potřeba dokoupit VDA licence, které se platí za kaţdé zařízení na období tří let. Tabulka 4-9: Cena tenkých klientů
Dell FX100 Zero Client
9500 Kč
VDA SNGL SubsVL MVL (na 3 roky)
1152 Kč
Celkem 21 klientů
223692 Kč
Zdroj: [Autor]
Celková investice potřebná k vytvoření virtualizované učebny, která je vybavena tenkými klienty, činí 541223 Kč. Pokud jsou k dispozici starší PC, které lze vyuţít jako tenké klienty, potřebná prvotní investice, pro vybudování učebny, se sníţí na 317531 Kč.
4.3 SWOT analýza Pro potřebu veřejné správy, v tomto případě vysoké školy, je SWOT analýza trochu odlišná od běţných finančních analýz. Postup tvorby SWOT analýzy je dle [10] následující: „od zhodnocení stavu prostředí (T), přes zhodnocení možností řešitelské instituce (W-S), až po znovuzhodnocení stavu prostředí (O). V průběhu řešení je stanovený cíl řešitelskou institucí neměnitelný, vnitřní možnosti (strengths) musí přizpůsobit cíli.“
42
Tabulka 4-10: SWOT analýza pro projekt nasazení virtualizace desktopů
SWOT analýza pro projekt nasazení virtualizace desktopů
Přednosti
Strenghts (Silné stránky)
Opportunities (Příležitosti)
Dobrá finanční a organizační
Flexibilita systému – umoţňuje
podpora vedení organizace.
provozovat více konfigurací a verzí
Zvýhodněné licenční podmínky
OS v jednu chvíli.
potřebných produktů pro školství.
Snadná správa systému, a to i při
Vyuţití stávajících částí
větším rozsahu nasazení.
infrastruktury.
Moţnost přístupu studentů k desktopům i mimo výukové hodiny.
Nedostatky
Weaknesses (Slabé stránky)
Threats (Hrozby)
Neposkytnutí finančních prostředků
Přechod na Windows 7 (v současném
z rozpočtu (případně dotace).
stavu by byl velice sloţitý).
Odchod odborníků na danou
Poţadavky vyučujících nebude
problematiku z řešitelského týmu.
moţné splnit (Speciální SW, různé
Neočekávané technologické limity.
verze OS). Tlak ekologických organizací na vyuţívání technologií šetrným k ŢP.
Vnitřní
Vnější
Zdroj: [Autor]
43
5 Nasazení VMware View a potřebných součástí. Důleţitým předpokladem pro nasazení VMware View, je existence adresářové sluţby Microsoft Active Directory. Bohuţel zatím není moţnost pouţít jinou adresářovou sluţbu, neţ tu od společnosti Microsoft, jako např. OpenLDAP, Novell eDirectory, atd. AD jiţ v prostředí, ve kterém probíhá implementace, existuje a není tedy nutné v tomto ohledu podnikat další kroky. Neţ začneme s vlastní instalací a konfigurací VMware View, je potřeba si připravit virtuální prostředí, které je shodné s prostředím pro virtualizaci serverů (VMware ESXi a VMware vCenter Server). Rozdíl je pouze ve způsobu licencování vCenter serveru, kdy na rozdíl od licence pro serverovou virtualizaci je tato omezena na počet současně spuštěných virtuálních strojů.
Většina větších dodavatelů serverů jiţ nabízí moţnost dodání s
předinstalovaným ESXi hypervisorem na USB flash disku, který je připojen k USB portu přímo na základní desce uvnitř serveru. Instalaci hypervisoru je tedy moţné přeskočit a přejít rovnou k jeho konfiguraci. Pro kompletní nasazení VMware View je potřeba staţení následujících komponent ze stránek www.vmware.com: Tabulka 5-1: Komponenty potřebné pro nasazení VMware View
Komponenta
Instalační balíček
VMware center Server
VMware-VIMSetup-all-5.0.0-639890.exe
VMware View Connection Server (64-bit)
VMware-viewconnectionserver-x86_645.0.1-640055.exe
VMware View Agent (32-bit)
VMware-viewagent-5.0.1-640055.exe
VMware View Client (32-bit)
VMware-viewclient-5.0.1-640055.exe
VMware View Composer
VMware-viewcomposer-2.7.0-481620.exe
Zdroj: [Autor]
5.1 Konfigurace VMware ESXi Na ESXi serverech je potřeba pouze upravit nastavení management sítě, nastavit tedy IP adresu, masku sítě, gateway, atd. (viz obrázek 5-1, 5-2 a 5-3). Tato konfigurace se provádí přímo na konzoli serverů po stisku klávesy F12 a zadání jména a hesla. 44
Obrázek 5-1: Konfigurace ESXi
Obrázek 5-2: Konfigurace ESXi
Zdroj: [Autor]
Zdroj: [Autor]
Obrázek 5-3: Konfigurace ESXi
Zdroj: [Autor]
5.2 Instalace VMware vCenter Server Jakmile je nastavena síť na obou ESXi serverech, je moţné se k nim připojit pomocí VMware vSphere klienta a vytvořit zde virtuální stroj, který je určen pro instalaci produktu VMware vCenter Server. Nezáleţí na tom, který ze dvou ESXi serverů v tuto chvíli zvolíme. VMware vCenter Server musí být instalován na 64-bitový serverový operační systém Microsoft Windows. V tomto případě je pouţita nejnovější verze, tedy MS Windows Server 2008 R2. Verzi vSphere 5 je moţné nainstalovat i na starší serverové operační systémy (např. MS Windows Server 2003), podmínkou ale zůstává to, ţe se musí jednat o 64-bitovou verzi. Konfigurace příslušného virtuálního stroje je tedy následující:
45
Obrázek 5-4: Virtuální stroj pro VMware vCenter Server
[Zdroj: Autor]
Operační systém, na kterém je sluţba VMware vCenter Server instalována, lze nainstalovat v defaultní konfiguraci a není tedy potřeba zde tento postup popisovat. Adresace sítě je nastavena tak, aby se IP adresy všech serverů (včetně ESXi) potřebných pro VMware View nacházely ve stejném subnetu. Není to nutná podmínka, ale značně to usnadní konfiguraci. Operační systém pro vCenter server nemusí být nutně členem domény (Active Directory), ale z důvodu snazší správy celého systému je to doporučeno. Kdyţ je operační systém připraven, lze přejít k samotné instalaci sluţby vCenter Server. Během instalačního průvodce lze vybrat z moţnosti vyuţití existující databáze, nebo instalace databázového systému Microsoft SQL Server 2008 Express, který je zdarma. Volba instalace express verze se doporučuje pouze pro méně rozsáhlá nasazení (max. 5 ESXi hostů a/nebo 50 virtuálních stanic). Pro účel této učebny bude stačit databázový systém Microsoft SQL Server 2008 Express. VMware vCenter Server 5 podporuje následující verze databázových systémů [23]: Microsoft SQL Server 2008 Express R2, Microsoft SQL Server 2005 Standard/Enterprise edition (SP4) 32/64 bit, Microsoft SQL Server 2008 Standard/Enterprise Edition (SP1) 32/64 bit, Oracle 10g Standard/Enterprise edition (Release 2 [10.2.0.4]) (64 bit), Oracle 11g Standard/Enterprise edition, IBM DB2 9.5, 46
IBM DB2 9.7. V následujících několika krocích je pak moţnost volby účtu, pod kterým sluţba poběţí (v tomto případě lze pouţít systémový účet), umístění cílového adresáře pro instalaci a volba, zda vCenter je prvním, nebo zda je v tzv. “linked mode“ reţimu, který se vyuţívá při rozloţení clusteru mezi více datacenter (existuje více propojených vCenter serverů). Na dalších dvou obrazovkách je moţnost upravit síťové komunikační porty pro samotný vCenter Server a pro související sluţbu „Inventory service“, která slouţí pro ukládání informací o běhu virtuálních strojů. Pro případ této instalace lze porty ponechat v defaultním nastavení (viz Obrázek 5-5 a Obrázek 5-6). Obrázek 5-5: Síťové porty pro vCenter Server
Obrázek 5-6: Síťové porty pro Inventory Service
Zdroj: [Autor]
[Zdroj: Autor]
Nakonec je ještě potřeba vybrat plánovanou velikost (počet hostů a virtuálních strojů) řízeného clusteru. Dle této volby se určí mnoţství přidělené paměti pro vCenter server web services (viz Obrázek 5-7). Obrázek 5-7: Web service Inventory Size
[Zdroj: Autor]
47
Po dokončení instalace je potřeba oba ESXi servery připojit k vCenter Server a upravit jejich nastavení (LAN, HA, DRS, Diskové úloţiště, atd.), coţ je moţné provést po připojení klientem vSphere k této sluţbě. Konfigurace těchto částí není předmětem této práce, tudíţ zde není podrobně popisován. Důleţité ale je, aby ve výsledku byl nastaven cluster s ESXi servery tak, aby zde byla jednotná konfigurace sítě a diskového úloţiště a zároveň bylo funkční HA a DRS (viz Obrázek 5-8). Obrázek 5-8: VMware vSphere console
Zdroj: [Autor]
5.3 Komponenta VMware View Composer Jak je jiţ popsáno výše, View Composer je rozšířením pro vCenter Server, který umoţňuje vyuţití tzv. linkovaných klonů. Toto rozšíření není pro základní funkčnost systému nezbytně nutné, ale při vyuţití v učebně je velice přínosné a ušetří spoustu práce a diskového prostoru.
5.3.1 Příprava databáze pro View Composer Jelikoţ jiţ máme na serveru, kde je View Composer instalován, připravený databázová systém Microsoft SQL Server 2008 Express, můţeme jej vyuţít i pro uloţení databáze samotného View Composeru. Databázi lze vytvořit standardním způsobem, např. pomocí nástroje SQL Server Management Studio (viz Obrázek 5-9). 48
Obrázek 5-9: Vytvoření nové databáze pro View Composer
Zdroj: [Autor]
Následně je potřeba nastavit přístupová práva k nově vytvořené databázi. V tomto případě je pouţit účet z Active Directory.
5.3.2 Vytvoření ODBC konektoru pro připojení View Composeru k databázi Konektor k databázi lze vytvořit pomocí nativního systémového nástroje „odbcad32.exe“ na kartě „Systém DSN“ (viz Obrázek 5-10 a Obrázek 5-11). Obrázek 5-10: ODBC konektor
Obrázek 5-11: ODBC konektor
Zdroj: [Autor]
Zdroj: [Autor]
5.3.3 Instalace komponenty View Composer pro vCenter Server Jakmile je připravena databáze a ODBC konektor k ní, lze přejít k samotné instalaci View Composeru. Během instalačního průvodce je nejprve nutné vybrat umístění instalačních souborů, poté vyplnit údaje potřebné k připojení k databázi (jméno ODBC konektoru a jméno a heslo 49
uţivatele, který má do databáze přístup – viz Obrázek 5-12). Na poslední konfigurační obrazovce průvodce je moţné upravit SOAP komunikační port. V tomto případě ho lze nechat ve výchozím nastavení (port 18443). Obrázek 5-12: Instalace View Composer – Database Information
Zdroj: [Autor]
5.4 Instalace a konfigurace služby VMware View Connection Server Stejně jako u vCenter server, je i zde potřeba mít připravený operační systém MS Windows Server 2008 R2, na který je produkt View Connection Server nainstalován jako sluţba. Na rozdíl od serveru pro vCenter Server musí být tento operační systém zařazen v doméně (Active Directory). Další podmínkou je, ţe sluţba View Connection Server nesmí být nainstalována na stejném stroji jako je vCenter Server, takţe je potřeba pro ni vyhradit samostatný virtuální stroj. Konfigurace tohoto virtuálního stroje můţe být stejná, ale pokud by tento Connection Server obsluhoval více jak 50 virtuálních stanic, je dobré mu přidělit alespoň 10 GB paměti. Samotná instalace VMware View Connection serveru je velice jednoduchá a obsahuje jen několik málo kroků. Po odsouhlasení licenčních podmínek je třeba zvolit cestu pro instalaci, vybrat typ serveru (viz Obrázek 5-13) a zvolit, zda instalátor má, či nemá povolit komunikační porty na lokálním firewallu (viz Obrázek 5-14). Jako typ serveru je v tomto případě potřeba zvolit „View Standard Server“. Server typu „View Replica Server“ se pouţívá pro zvýšení dostupnosti sluţby (vytvoření redundance). 50
Význam ostatních typů je popsán výše v teoretické části této práce. Porty na firewallu je dobré povolit, pokud je tedy Windows firewall zapnutý. Obrázek 5-13: Výběr typu Connection Serveru
Obrázek 5-14: Povolení komunikačních portů
Zdroj: [Autor]
[Zdroj: Autor]
Jakmile je instalace dokončena, je moţné se k View Connection Serveru připojit, a to pomocí webového prohlíţeče (konfigurační frontend je dostupný přes zabezpečený http protokol). Administrace je tedy dostupná na URL http://jmeno.domena/admin. Obrázek 5-15: VMware View Connection Server login
Zdroj: [Autor]
Pro první přihlášení je nutné pouţít účet doménového administrátora (resp. účet, který je ve skupině „Domain Admins“), ţádný jiný tam zatím práva nemá. Obrázek 5-16: Konfigurace serverů ve View Administratoru
Zdroj: [Autor]
51
Po přihlášení se zobrazí dashboard, který ukazuje aktuální stav jednotlivých komponent a připojených klientů. Aby systém začal správně fungovat, je potřeba View Connection Server propojit s vCenter server. Toto propojení je moţné vytvořit v sekci „View Configuration -> Servers -> vCenter Servers“ (viz Obrázek 5-16). Po kliknutí na „Add..“ se zobrazí formulář pro vytvoření nového připojení, kde je potřeba vyplnit adresu serveru a přihlašovací údaje (viz Obrázek 5-17). Jelikoţ je operační systém, na kterém je nainstalován vCenter Server, v doméně, lze jako přihlašovací údaje pouţít doménový účet (např. Administrator). Dále je potřeba přidat doménu pro View Composer. View Composer můţe vyuţívat i více neţ jednu doménu (např. jednu doménu pro testovací desktopy a jednu pro ostré nasazení), v tomto případě je k dispozici ale pouze jedna. Obrázek 5-17: Nastavení propojení s vCenter Server
Obrázek 5-18: Vytvořené propojení s vCenter Server
Zdroj: [Autor]
Zdroj: [Autor]
5.5 Příprava klientského desktopu a instalace View agenta Jako klientský operační systém byl vybrán Microsoft Windows XP, a to z toho důvodu, ţe je stále ještě nejpouţívanějším systémem pro výuku na vysokých školách. Při přípravě virtuálního stroje, který bude slouţit jako tzv. „Golden Image“, bylo postupováno dle doporučení, která jsou uvedena v dokumentu „Windows XP Deployment Guide“. [21] Nejprve je tedy potřeba vytvořit nový virtuální stroj ve vCenter server managementu. Postup je stejný, jako u virtuálního stroje určeného pro serverový operační systém, rozdíl je pouze ve zvoleném řadiči disků a samozřejmě ve vybraném hostovaném operačním systému.
52
Konfigurace virtuálního stroje je následující: 1 vCPU, 1024 MB RAM, 12 GB HDD – SCSI na LSI Logic Parallel, Microsoft Windows XP Professional (32-bit). Následné optimalizaci operačního systému, jak je uvedeno v [21], je dobré věnovat velkou pozornost. Závisí na tom efektivita vyuţití přiděleného výpočetního výkonu a tím i vynaloţených investic. Jakmile je operační systém nainstalován (včetně VMware Tools) a odladěn, je potřeba do něj ještě doinstalovat VMware View agenta, který dělá prostředníka pro přístup z View prostředí ke sluţbám operačního systému. Samotná instalace agenta je velmi jednoduchá a důleţitý krok je zde pouze výběr instalovaných komponent (viz Obrázek 5-19). V tomto případě se nainstaluje vše, aţ na PCoIP Smartcard, která nebude potřeba. Obrázek 5-19: Výběr instalovaných komponent View agenta
Zdroj: [Autor]
Význam jednotlivých komponent: USB Redirection – zajišťuje připojení USB zařízení od klienta do virtuálního desktopu. View Composer Agent – slouţí pro zajištění potřebných úprav OS při klonování pomocí View Composeru.
53
Virtual Printing – umoţňuje tisk z virtuálního desktopu na tiskárnu, připojenou ke klientskému PC nebo na síťovou tiskárnu pomocí ThinPrint (přenesená data jsou šifrovaná a komprimovaná). PCoIP Server – umoţňuje komunikaci s virtuálním desktopem pomocí PCoIP protokolu. View Persona Management – jedná se o náhradu, či rozšíření tzv. roaming profilů neboli cestovních uţivatelských profilů. Po dokončení přípravy „Golden Image“ je potřeba na tomto virtuálním stroji vytvořit snapshot, který bude slouţit jako výchozí bod pro klonování pomocí View Composeru.
5.6 Vytvoření poolu virtuálních desktopů Nyní je vše připraveno a je jiţ moţné ve View Administratoru vytvořit pool virtuálních desktopů. Nový pool lze po přihlášení vytvořit v sekci „Inventory -> Pools“ a klikem na tlačítko „Add…“, které spustí konfiguračního průvodce. Na první obrazovce průvodce je nutné vybrat typ poolu. Na výběr je ze tří typů: Automated Pool – pro generování nových desktopů se pouţívá vCenter Server template, nebo snapshot virtuálního stroje. Manual Pool – umoţňuje připojení k existujícím systémům, na které lze nainstalovat View agenta. Terminal Services Pool – zprostředkuje Microsoft Terminal Services session jako virtuální desktop pomocí View klienta. Jelikoţ chceme pro desktopy vyuţít dynamické virtuální prostředí, je potřeba zvolit první moţnost, tedy „Automated Pool“. U automatizovaného, ale i manuálního poolu, lze vybrat způsob přidělování virtuálních desktopů uţivatelům (tzv. User assignment). Tento výběr probíhá na následující obrazovce průvodce a zvolit lze z následujících moţností: Dedicated – v tomto případě uţivatel dostane vţdy stejný virtuální desktop, který mu byl přidělen při prvním připojení. Toto přidělování lze provádět ručně, nebo automaticky. 54
Floating – zde uţivatel dostane přidělený, při kaţdém připojení, náhodně vybraný volný virtuální desktop z daného poolu. Pro účely klasické učebny, kdy není potřeba, aby kaţdý uţivatel měl svůj vlastní desktop (uţivatelů je mnohem více neţ klientských PC) je nejvhodnější volba Floating. Na další obrazovce je moţné zvolit, zda nové virtuální desktopy budou plné kopie, nebo linkované klony vytvořené pomocí View Composeru. Z důvodu úspory diskové kapacity jsou samozřejmě vhodnější volba linkované klony (viz Obrázek 5-20). Obrázek 5-20: Vytvoření poolu – vCenter Server
Zdroj: [Autor]
Po stisku tlačítka next se zobrazí obrazovka, na které je potřeba vyplnit identifikaci poolu (viz Obrázek 5-21). Pole, které musí být vyplněno, je „ID“ a text v něm pouţitý nesmí obsahovat mezery a speciální znaky. „Display name“ určuje jméno, které se zobrazí uţivateli při připojení k serveru. „View folder“ je pouze organizační sloţka ve View administratoru, která usnadňuje orientaci a vyhledávání ve virtuálních desktopech. Obrázek 5-21: Vytvoření poolu – identifikace
Zdroj: [Autor]
Na další obrazovce je pak moţné nastavit chování poolu. Jednotlivá nastavení jsou zde rozdělena do sekcí General, Remote Settings, Remote Display Protocol a Adobe Flash 55
Settings for Remote Sessions. Z hlediska této učebny jsou nejdůleţitější nastavení ze sekce Remote Settings, kde je potřeba udělat několik změn (viz Obrázek 5-22). 1. Remote Desktop Power Policy – změněno na „Power off“ - toto nastavení určuje, ţe virtuální desktopy, které se nevyuţívají a nejsou označeny jako „spare“, budou vypnuty. Lze takto ušetřit výpočetní výkon. 2. Automatically logoff after disconnect – změněno na „Immediate“ – zajišťuje automatické odhlášení uţivatele z operačního systému (např. kdyţ nebude relace řádně ukončena). 3. Delete or refresh desktop on logoff – změněno na „Refresh Immediately“ – po pouţití (odhlášení nebo vypnutí) se virtuální desktop automaticky vrátí do původního stavu. Obrázek 5-22: Vytvoření poolu – Pool Settings
Zdroj: [Autor]
Ostatní nastavení lze v tuto chvíli ponechat v defaultní konfiguraci. Po stisku tlačítka „Next“ se nabídne moţnost vyuţití tzv. Disposable files. V případě vyuţití této moţnosti, se dočasná data operačního systému (Temp, Pagefile, atd.) ukládají na samostatný disk, který je moţné v případě potřeby smazat. V tomto případě to ale není nutné, proto je vybrána volba „Do not redirect disposable files“. Na další obrazovce pak pokračuje průvodce nastavením provisioningu, kde je moţné určit pojmenování vygenerovaných virtuálních strojů a velikost poolu (viz Obrázek 5-23). Co se týče pojmenování, jsou zde dvě moţnosti: 1. Specify names manually – při výběru této moţnosti je moţné ručně zadat sadu jmen, která se budou přiřazovat nově vytvořeným virtuálním desktopům. Vytvoří se tolik desktopů, kolik jmen bylo zadáno. 2. Use a naming pattern – u této moţnosti je moţné zadat šablonu pro vytváření jmen. K dispozici je např. moţnost automatického číslování, přičemţ šablona můţe vypadat 56
následovně: “Ucebna1-{n:fixed=2}”. Písmeno „n“ v šabloně určuje pouţití číselného inkrementu a „fixed=2“ upravuje počet pouţitých číslic (v tomto případě 01, 02, 03, atd.). Dvoučíselné hodnoty jsou v tomto případě výhodné kvůli správnému řazení. Při volbě velikosti poolu (počtu vygenerovaných virtuálních desktopů), je dobré počítat s tím, ţe se občas můţe nějaký virtuální desktop dostat do nekonzistentního stavu. Proto je dobré mít připraveno více desktopů, neţ bude skutečný počet klientů. V připravované učebně je počítáno s 21 klienty, proto hodnota „Max number of desktops“ (maximální počet desktopů) je nastavena na 23 a „Number of spare desktops“ (počet zapnutých desktopů) je 21. Tyto hodnoty tedy určují, ţe bude vygenerováno maximálně 23 desktopů a zapnutých z toho bude minimálně 21. Lze si ještě určit, zda se všech 23 desktopů vygeneruje ihned, nebo dle potřeby. Obrázek 5-23: Vytvoření poolu – Provisioning
[Zdroj: Autor]
Předposlední obrazovkou průvodce je „vCenter Settings“, kde je potřeba nastavit zdrojový image, resource pool a cílového diskového úloţiště (viz Obrázek 5-24). Obrázek 5-24: Vytvoření poolu – vCenter Settings
Zdroj: [Autor]
57
Default image – zde je potřeba vybrat jiţ připravený golden image a jeho snapshot, který bude jako výchozí bod pro klonované virtuální desktopy. VM folder – zde je moţné určit organizační sloţku, do které se budou generovat virtuální desktopy. Tato sloţka musí být připravena ve vCenter server, nikoliv ve View Administratoru. Host or cluster – v tom výběru je potřeba určit, jaký výkonový cluster, popřípadě jednotlivý host, bude pouţit pro běh virtuálních desktopů. Resource pool – výkon kaţdého clusteru můţe být ještě rozdělen mezi tzv. resource pooly. V tomto případě ale ţádné vytvořené nejsou, takţe se pouţije výkon celého clusteru. Datastores – zde je potřeba vybrat na jaké datové úloţiště se budou ukládat data vygenerovaných virtuálních desktopů. Lze jich vybrat i více. Na závěr je ještě potřeba určit, jakým způsobem bude probíhat customizace jednotlivých virtuálních desktopů. Kaţdý jednotlivý desktop musí mít unikátní SID a jméno a s těmito údaji musí být vloţen do domény (Active Directory). Tyto parametry lze nastavit na další a zároveň poslední konfigurační obrazovce průvodce (viz Obrázek 5-25). Obrázek 5-25: Vytvoření poolu – Guest Customization
Zdroj: [Autor]
Kromě výběru domény a organizační jednotky, do které se budou virtuální zařazovat, je zde moţné určit způsob přípravy naklonovaného virtuálního desktopu. QuickPrep – potřebné úpravy operačního systému zajišťuje přímo View Composer.
58
Sysprep – úpravy jsou zajištěny pomocí nativních nástrojů z operačního systému MS Windows. Konfiguraci sysprepu je potřeba si předpřipravit (jako pojmenovaný objekt) ve vCenter serveru a následně ji zde vybrat. Pro účely této učebny je nejvhodnější a nejjednodušší pouţít QuickPrep, jelikoţ doba potřebná pro přípravu a náročnost na konfiguraci jednoho virtuálního stroje je menší, neţ při pouţití sysprepu. Aby byl pool plně funkční a začaly se generovat virtuální desktopy, je ještě nutné, po dokončení průvodce, přidat uţivatele nebo skupinu uţivatelů, kteří budou moci daný pool pouţívat. Přiřazení uţivatelů je moţné udělat v sekci „Inventory -> Pools -> Entitlements…“ (viz Obrázek 5-26). Obrázek 5-26: Vytvoření Poolu – Entitlements…
Zdroj: [Autor]
Po tomto kroku se jiţ začnou automaticky generovat virtuální desktopy. Průběh generování lze sledovat z View Administratoru, nebo přímo ve vCenter Server. Proces generování desktopů obsahuje následující kroky: 1. vytvoření klonu z vybraného snapshotu golden image (tento klon se následně vyuţívá jako sdílený image pro linkované klony), 2. vytvoření linkovaného klonu (rozdílový image), 3. úprava linkovaného klonu (změna SID, přejmenování, vloţení do domény, atd.).
59
5.7 Instalace VMware View klienta a ověření funkčnosti poolu Serverová část konfigurace je nyní připravena a lze tedy přistoupit k ověření funkčnosti pomocí View klienta. Oficiální View klient je k dispozici pro operační systémy MS Windows, ale kromě toho existují verze i pro Android, iPad, Linux a Mac OS X. Pro otestování funkčnosti bude pouţit klient pro OS Windows. Klienta pro MS Windows lze stáhnout z úvodní webové stránky View Connection serveru nebo přímo ze stránek společnosti VMware (na těchto stránkách je moţné nalézt i View klienty pro ostatní uvedené operační systémy). Proces instalace View klienta obsahuje jen několik málo kroků. Po klasickém odsouhlasení licenčních podmínek je moţné vybrat volitelné vlastnosti, které budou instalovány. Volit je moţno ze dvou: USB Redirection – zajišťuje přesměrování lokálně připojených USB zařízení do virtuálního desktopu. Log in as current user – umoţňuje vyuţít aktuální přihlašovací údaje (jméno a heslo) pro připojení k poolu a následně i do virtuálního desktopu. Zde lze ponechat veškerá nastavení ve výchozím stavu a dokončit instalačního průvodce. Je dobré podotknout, ţe aby bylo moţné vyuţít protokol PCoIP pro připojení k virtuálním desktopům, musí procesor klientského PC podporovat alespoň instrukční sadu SSE2. Po dokončení instalace je jiţ moţné se pomocí View klienta připojit k View Connection serveru a následně i k vlastnímu virtuálnímu desktopu. Po spuštění klienta je nejprve nutné zadat adresu View Connection serveru (viz Obrázek 5-27). Obrázek 5-27: View klient - připojení k serveru
Zdroj: [Autor]
60
Po stisku tlačítka „Connect“ se zobrazí obrazovka pro zadání uţivatelského jména a hesla (viz Obrázek 5-28), které budou pouţity pro přihlášení (pokud nebyla v předchozím kroku zaškrtnuta volba „Log in as current user“). V případě, ţe na klientském PC není nainstalován kořenový certifikát certifikační autority, kterou je podepsán certifikát vydaný pro View Connection server, předchází tomuto kroku ještě varovné hlášení o neověřené identitě serveru. Obrázek 5-28: View klient - přihlašovací údaje
Obrázek 5-29: View klient – výběr poolu
Zdroj: [Autor]
Zdroj: [Autor]
Po úspěšném přihlášení se zobrazí výběr z dostupných poolů pro daného uţivatele. Nyní uţ je moţné spustit virtuální desktop, coţ lze provést tlačítkem „Connect“ (viz Obrázek 5-29). Systém nyní automaticky vybere a přidělí volný desktop a pouţije uţivatelské jméno a heslo, které bylo zadáno pro ověření k View Connection serveru, pro přihlášení do operačního systému ve virtuálním desktopu (Single sign-on). Obrázek 5-30: View klient – virtuální desktop
Zdroj: [Autor]
61
5.8 Využití „Zero“ klienta pro připojení k VMware View poolu Jak jiţ bylo uvedeno při plánování kapacity, je v tomto projektu počítáno i s vyuţitím tzv. zero klientů. Tyto klienti mají výhodu v tom, ţe není potřeba nic instalovat, a jelikoţ jsou postavené na technologii o společnosti Teradici, je k nim k dispozici administrační nástroj (viz Obrázek 5-31) ve formě virtual appliance, kterým lze snadno spravovat a aktualizovat všechny zero klienty najednou. Obrázek 5-31: Teradici – nástroj pro správu zero klientů
Zdroj: [Autor]
Přihlášení k virtuálnímu desktopu pomocí zero klienta je stejné jako při vyuţití klienta pro OS Windows. Rozdíl je ale právě v moţnosti administrace a také v ţivotnosti (poruchovosti) nebo spotřebě elektrické energie.
62
6 Přechod z Windows XP na Windows 7 ve virtuální učebně Ve virtuální učebně s plovoucím (floating) přidělováním desktopů, je přechod z Windows XP na Windows 7 poměrně jednoduchý a obsahuje jen 3 kroky: 1. Příprava golden image s Windows 7 (Instalace a optimalizace byla provedena dle doporučení uvedených v [12]). 2. Úprava poolu (popř. příprava nového poolu, pokud mají být dostupné oba OS zároveň) – úprava zahrnuje pouze změnu zdrojového image a snapshotu. 3. Recompose poolu – přegenerování linkovaných klonů z nového golden image. Tuto operaci lze provést v sekci „Inventory -> Pools“, kde je potřeba vybrat kliknutím příslušný pool a poté spustit recompose pomocí tlačítka „View Composer -> Recompose“. Následně se zobrazí průvodce, kde je potřeba vybrat nový vzorový image a příslušný snapshot. Nakonec je moţné zvolit čas, kdy se akce provede. Přegenerování poolu probíhá průběţně a nedochází tedy k výpadku sluţby. Uţivatelé tedy v jednu chvíli pracují na Windows XP a pokud se odhlásí a znovu přihlásí, budou jiţ pracovat na Windows 7. Podmínkou ale je, ţe vzorové virtuální stroje s Windows XP a s Windows 7 musí mít shodné verze virtuálního HW (v tomto případě verze 8). O něco sloţitější situace pak nastává v případě vyuţití dedikovaných desktopů (přidělených konkrétnímu uţivateli). Zde je podmínkou vyuţívání tzv. persistentních disků nebo funkce View Persona Management, která zajišťuje přesměrování profilových dat uţivatelů. Při provedení recompose se pak změní pouze image s operačním systémem a data uţivatelů zůstávají na persistentním disku, nebo na síťovém disku, v případě pouţití View Persona Managementu. Po výměně operačního systému sice zůstaly uţivatelům jejich profily, ty jsou ale stále ve formátu pouţívaném ve Windows XP (V1). Pokud mají být tedy uţivatelské profily pouţitelné ve Windows 7, je nutné je zkonvertovat na novější verzi (V2). Pro tuto konverzi existuje hned několik nástrojů, v tomto případě je ale zajímavá migrační utilita od společnosti VMware. Jedná se o utilitu „migprofile.exe“, která je spouštěna z příkazového řádku a k
63
dispozici je na všech desktopech, kde je nainstalován View agent s komponentou View Persona Management, v adresáři „install_dir\VMware\VMware View\Agent\bin“.
6.1 Příklad použití migrační utility migprofile.exe Migrace všech V1 profilů umístěných na síťovém disku \\file01\profiles na profily V2: migprofile.exe /s:\\file01\profiles\* /takeownership
Vyuţití konfiguračního XML souboru: migprofile.exe migconfig.xml
Konfigurační soubor migconfig.xml: <migconfig version = "0.1"> <source> <profilepath>\\file01\profiles\*
<profilepath>\\file01\profiles
Zdroj: [19]
64
7 Srovnání provozních a investičních nákladů klasické a virtuální učebny osazené zero klienty. Toto srovnání je zaměřeno především na rozdíl ve spotřebované elektrické energii v kontextu s ţivotností jednotlivých zařízení, který lze jednoduše početně vyjádřit. Rozdíl je samozřejmě i v potřebné lidské práci, která je nutná pro správu těchto dvou řešení (administrace a servisní zásahy), ten je ale velice individuální (hlavně co se týče vynaloţení finančních prostředků), proto zde není početně vyjádřen. Obecně bývá úspora, na administraci a potřebných servisních zásazích, cca 50% ve prospěch virtualizované učebny, vybavené zero klienty. Tato výhoda vychází především z toho, ţe zero klienti neobsahují ţádné diskové jednotky a ani jiné pohyblivé části, které bývají nejčastějším zdrojem poruch. Další výhodou zero klientů od klasických PC je i jejich fyzická a morální ţivotnost. Fyzická ţivotnost těchto zařízení je, právě díky absenci pohyblivých částí, udávaná cca na 5-7 let. Morální ţivotnost ale můţe být, na rozdíl od klasické učebny, delší neţ ta fyzická, a to díky tomu, ţe není potřeba vysokého výpočetního výkonu. Pomocí virtualizace desktopů lze prodlouţit i morální ţivotnost starších klasických PC, a to tím, ţe je lze vyuţít jako tenké klienty. V tomto případě ale přicházíme o výhodu niţších nákladů na servis nebo výměnu těchto klientů.
7.1 Porovnání spotřeby zero klientů a klasických PC Jelikoţ u obou řešení jsou potřeba stejná periferní zařízení (monitor, klávesnice a myš), není jejich spotřeba v kalkulaci započítána. Pro výpočet ceny za spotřebovanou elektřinu je pouţita aktuální průměrná cena elektřiny (4,64Kč/kWh). Dále je potřeba určit, jak dlouho během jednoho dne, budou klienti / PC aktivně vyuţívány. V tomto případě bude učebna aktivně vyuţívána průměrně 8 hodin za den a ostatní část dne bude v reţimu „Stand-by“.
65
Tabulka 7-1: Spotřeba el. energie klasického PC
Spotřeba elektrické energie klasického desktopového PC Spotřeba el. energie za provozu [Wh]
87
Spotřeba el. energie v reţimu „Stand-by“ [Wh]
13
Celková spotřebovaná el. energie za den [Wh]
904
Zdroj: [Autor]
Celková spotřeba elektrické energie klasické učebny s 21 PC je tedy 18,98 kWh za jeden den. Tabulka 7-2: Spotřeba elektrické energie zero klienta
Spotřeba elektrické energie zero klienta (Dell FX100) Spotřeba el. energie za provozu [Wh]
12
Spotřeba el. energie v reţimu „Stand-by“ [Wh]
12
Celková spotřebovaná el. energie za den [Wh]
288
Zdroj: [Autor]
U zero klienta je spotřeba za provozu stejná jako v reţimu „Stand-by“. Je to dáno tím, ţe tento typ zero klienta zůstává pořád zapnutý a nelze je tlačítkem vypnout. Zapínací tlačítko zde slouţí pro připojení, nebo odpojení virtuálního desktopu. Tabulka 7-3: Spotřeba elektrické energie blade serveru
Spotřeba elektrické energie blade serveru Spotřeba el. energie při průměrném vytíţení [Wh]
270
Potřebný chladící výkon [Wh]
270
Celková spotřebovaná el. energie za den [Wh]
12960
Zdroj: [Autor]
U serveru je uveden i chladící výkon, který je potřeba pro provoz klimatizace. Obecně platí, ţe na 1 watt spotřebovaného výkonu, je potřeba 1 watt chladícího výkonu. Celková spotřeba elektrické energie virtuální učebny osazené zero klienty a potřebných serverů je celkem 31,97 kWh za den. V následující tabulce je uvedena celková spotřeba obou řešení za jeden rok (21 zero klientů + 2 servery a 21 PC v klasické učebně) a její peněţní vyjádření.
66
Tabulka 7-4: Celková spotřeba obou řešení za jeden rok
Celková spotřebovaná el. energie
Virtuální desktopy
Klasické
Rozdíl
(2 servery + 63 klientů)
desktopy
11669
6928
4741
54144
32146
21998
za rok [kWh] Celkové náklady na el. energii za rok [Kč] Zdroj: [Autor]
Z předchozího zkoumání vyplývá, ţe spotřeba elektrické energie virtualizované učebny je vyšší neţ u učebny klasické. Tento fakt je způsoben především vysokou spotřebou serverů, které běţí 24 hodin denně a jsou u tohoto řešení nutné. Tento problém se dá částečně řešit vyuţitím nástrojů pro power management, které nabízí virtualizační prostředí. Tyto nástroje umoţňují automatické vypínání a zapínání serverů podle aktuálního vytíţení. Je tedy moţné systém nastavit tak, aby při malém zatíţení (např. v noci) vypnul jeden ze dvou serverů v clusteru. Tímto způsobem lze sníţit spotřebu el. energie za den z 31,97 kWh na 23,33 kWh. Tabulka 7-5: Celková spotřeba obou řešení za jeden rok při využití power managementu
Virtuální desktopy
Klasické
(2 servery + 21 klientů)
desktopy
Celková spotřebovaná el. energie
Rozdíl
8515
6928
1587
39510
32146
7363
za rok [kWh] Celkové náklady na el. energii za rok [Kč] Zdroj: [Autor]
Další způsob, jak zvýšit efektivitu vizualizovaného řešení, je větší vytíţení jednotlivých serverů, tedy rozšíření zero klientů do více učeben. Pokud tedy uvaţujeme, ţe při dostatečném osazení serverů pamětí a procesorem, je moţné provozovat na jednom serveru cca 60-80 virtuálních desktopů (3 učebny), pak se poměr spotřeby el. energie obrátí ve prospěch virtualizované učebny.
67
Tabulka 7-6: Celková spotřeba obou řešení pro 3 učebny za jeden rok při využití power managementu
Virtuální desktopy
Klasické
(2 servery + 63 klientů)
desktopy
15137
20761
5624
70236
96331
26095
Celková spotřebovaná el. energie za rok [kWh] Celkové náklady na el. energii za rok [Kč]
Rozdíl
Zdroj: [Autor]
7.2 Porovnání investičních nákladů klasické a virtualizované učebny Do investičních nákladů jsou započítány náklady na nákup hardwaru a softwaru potřebného pro běh učebny. Tabulka 7-7: Investiční náklady na vybudování klasické učebny
Investiční náklady na vybudování klasické učebny 21 x PC (Dell Optiplex 390) Win 7 OEM
273000 Kč
licence 21 x monitor 17“
63000 Kč
Náklady celkem
336000 Kč
Zdroj: [Autor] Tabulka 7-8: Investiční náklady na vybudování virtualizované učebny
Investiční náklady na vybudování virtualizované učebny 2x server a diskové úloţiště
210044 Kč
Serverový software
107487 Kč
21 x zero klient + VDA licence
223692 Kč
21 x monitor 17“
63000 Kč
Náklady celkem
604223 Kč
Zdroj: [Autor]
Z předchozího zkoumání vyplývá, ţe investiční náklady na jednu virtualizovanou učebnu jsou téměř dvojnásobné oproti nákladům na učebnu klasickou. Stejně jako u provozních nákladů, by se investiční náklady začaly trochu přibliţovat, aţ při nasazení na větší počet učeben. 68
Nevýhodou vyuţití zero klientů je fakt, ţe licenční politika Microsoftu vyţaduje pronájem tzv. VDA licencí, které zvyšují provozní náklady virtuální učebny. Tyto speciální licence jsou potřeba pouze při vyuţití non-Windows klientů.
69
Závěr Tato diplomová práce je v teoretické části zaměřena především na popis a zhodnocení vlastností nástrojů pro virtualizaci od tří největších hráčů na trhu v této oblasti, a to jak serverů, tak desktopů. Detailnější pohled ale vţdy přináší na nástroje od společnosti VMware, pomocí kterých je následně vypracována praktická část práce. Jak jiţ bylo zmíněno, praktická část práce je zaměřena na instalaci a konfiguraci serverových a desktopových nástrojů od společnosti VMware, s cílem vytvořit virtualizovanou učebnu pro vyuţití k výuce na vysoké škole a její následné zhodnocení, a to jak po finanční, tak po technické stránce. Co se týká technické stránky vytvořené virtuální učebny, bylo zjištěno, ţe instalace a následná konfigurace potřebných součástí není nijak sloţitá, je ale potřeba mít důkladně připravené prostředí pro implementaci, tedy kvalitní síťovou infrastrukturu a plně funkční adresářovou sluţbu Active Directory. Přínosy takto vytvořené učebny jsou pak především v její flexibilitě a jednoduchosti správy. Zdůraznit bych chtěl především moţnost snadného přechodu z Windows XP na Windows 7 a široké moţnosti pro vyučujícího při přípravě individuálního virtuálního desktopu pro daný typ výuky. K dispozici přitom můţe mít hned několik virtuálních desktopů, které jsou přístupné z jediného koncového zařízení. Při volbě koncového zařízení lze přitom vybírat z poměrně širokého spektra, a to od klasických PC, přes zero klienty, aţ po dnes moderní mobilní zařízení, jako jsou např. tablety. Co se týká finanční stránky virtuální učebny, je zde jiţ situace o něco méně optimistická. Investice potřebná pro vytvoření jedné virtualizované učebny je téměř dvojnásobná oproti učebně klasické a ani provozní náklady, v podobě spotřebované elektrické energie, nejsou niţší. Nepříjemným faktem je i to, ţe při pouţití non-Windows klientských zařízení je potřeba, dle licenční politiky společnosti Microsoft, platit pronájem VDA licence za kaţdé takové zařízení. Dle zkoumání začíná být desktopová virtualizace finančně o něco výhodnější při nasazení na větší počet klientských zařízení (60 a více), a to díky efektivnějšímu vyuţití serverové části systému a niţší spotřebě elektrické energie zero klientů. Jisté sníţení nákladů je ale moţné docílit u správy virtualizovaného prostředí, a to díky jednoduchosti a efektivnosti administrativních nástrojů. I zde ale opět platí, ţe čím je větší rozsah nasazení, tím větší úspora můţe být.
70
Při úvaze, zda tedy virtualizaci desktopů v organizaci nasadit, či ne, je potřeba dobře zváţit, jestli by přínosy byly větší, neţ vícenáklady, které nasazení přináší a také počet klientů, na které je nasazení plánováno.
71
Seznam použité literatury [1] BLACK, Aaron. VMWARE, Inc. Streaming Execution Mode: Application Streaming with VMware® ThinApp™ [online]. 2011 [cit. 2012-04-28]. Dostupné z: http://www.vmware.com/files/pdf/VMware_ThinApp_Streaming_Execution_Mode_Info rmation_Guide.pdf [2] CITRIX SYSTEMS, Inc. XenDesktop 5: Reference Architecture [online]. 2010 [cit. 2012-05-02]. Dostupné z: http://support.citrix.com/article/CTX127587 [3] DUŠEK, Libor. Testování výkonnosti virtualizačního prostředí Hyper-V [online]. Brno, 2011 [cit. 2012-04-19]. Dostupné z: http://is.muni.cz/th/208035/fi_m/. Diplomová práce. Masarykova univerzita. Vedoucí práce Ing. Mgr. Zdeněk Říha, Ph.D. [4] MANAG A.S., Divize 52 - ICT. Virtualizace [online]. 2008, roč. 2008, č. 9 [cit. 201204-15]. Dostupné z: http://www.manag.com/public/data/data/Virtualizace_v1.3.pdf [5] Windows Server 2008 s Hyper-V: Funkce. MICROSOFT. Microsoft Česká republika: cloud computing, software, digitální svět, IT [online]. © 2012 [cit. 2012-04-19]. Dostupné z: http://www.microsoft.com/cze/windowsserver2008/hyper-v/features.aspx [6] MATYSKA, Luděk. Zpravodaj ÚVT MU Bulletin pro zájemce o výpočetní techniku na Masarykově univerzitě [online]. 2006, XVII, č. 2 [cit. 2012-04-08]. ISSN 1212-0901. Dostupné z: http://www.ics.muni.cz/bulletin/articles/540.html [7] PATKA, Lukáš. Virtualizační technologie [online]. Brno, 2009 [cit. 2012-04-19]. Dostupné z: http://is.muni.cz/th/72735/fi_m/. Diplomová práce. Masarykova univerzita. Vedoucí práce Ing. Mgr. Zdeněk Říha, Ph.D. [8] TERADICI CORPORATION. PC-over-IP remote display technology: true zero client desktop virtualization - PCoIP [online]. © 2012 [cit. 2012-06-06]. Dostupné z: http://www.teradici.com/ [9] TULLOCH, Mitch. Understanding Microsoft Virtualization Solutions, From the Desktop to the Datacenter [online]. Second edition. Redmond, Washington: Waypoint Press, 2010 [cit. 2012-04-19]. ISBN 9780735693821. Dostupné z: http://blogs.msdn.com/b/microsoft_press/archive/2010/02/16/free-ebook-understandingmicrosoft-virtualization-r2-solutions.aspx
72
[10] VELIČKO, Jiří. Metodika zpracování analýzy SWOT pro orgány veřejné správy. In: Vlastnicesta.cz: vše pro poradce a poradenství [online]. (c) 2006-2009 [cit. 2012-05-04]. Dostupné z: http://www.vlastnicesta.cz/metody/metody-management/metodikazpracovani-analyzy-swot-pro-organy-verejne-spravy/ [11] VIARENGO, Vittorio. The History of VDI. Virtualization Journey: The Pragmatic Journey to Cloud Computing [online]. 2011 [cit. 2012-04-25]. Dostupné z: http://journeytocloud.com/2011/06/27/the-history-of-vdi-view-vmware/ [12] VMWARE, Inc, Ensynch. VMware View Optimization Guide for Windows 7 [online]. 2010, 2012-01-12 [cit. 2012-05-20]. Dostupné z: http://www.vmware.com/files/pdf/VMware-View-OptimizationGuideWindows7-EN.pdf [13] VMWARE, Inc. Server and Storage Sizing For VMware VDI: A Prescriptive Approach [online]. 2008 [cit. 2012-04-19]. Dostupné z: http://www.vmware.com/files/pdf/VMware_VDI_Server_and_Storage_Sizing_120508.p df [14] VMWARE, Inc. Using VMware Horizon Application Manager to Manage Deployment and Entitlement of ThinApp Packages [online]. 2011 [cit. 2012-04-28]. EN-000752-00. Dostupné z: http://www.vmware.com/pdf/thinapp47-horizon-integration-guide.pdf [15] VMWARE, Inc. VMware View™ 5 with PCoIP: NETWORK OPTIMIZATION GUIDE [oline]. 2011 [cit. 2012-05-05]. Dostupné z: http://www.vmware.com/files/pdf/view/VMware-View-5-PCoIP-Network-OptimizationGuide.pdf [16] VMWARE, Inc. VMware View Architecture Planning [online]. 2012 [cit. 2012-04-26]. EN-000698-01. Dostupné z: http://pubs.vmware.com/view50/topic/com.vmware.ICbase/PDF/view-50-architecture-planning.pdf [17] VMWARE, Inc. VMware View™ Composer: Advanced Image Management and Storage Optimization for your VMware View Environment [online]. 2009 [cit. 2012-04-28]. Dostupné z: http://www.vmware.com/files/pdf/VMware-View-4-Composer-DS-EN.pdf [18] VMWARE, Inc. VMware View Planner Installation and User Guide [online]. 2. vyd. 2011 [cit. 2012-05-02]. EN-000224-02. Dostupné z: http://communities.vmware.com/docs/DOC-15578
73
[19] VMWARE, Inc. VMware View User Profile Migration [online]. 2012 [cit. 2012-05-20]. EN-000767-00. Dostupné z: http://pubs.vmware.com/view51/topic/com.vmware.ICbase/PDF/view-51-profile-migration.pdf [20] VMWARE, Inc. VMware vSphere Basics: ESXi 5.0, vCenter Server 5.0 [online]. 2011 [cit. 2012-04-15]. EN-000586-00. Dostupné z: http://pubs.vmware.com/vsphere50/topic/com.vmware.ICbase/PDF/vsphere-esxi-vcenter-server-50-basics-guide.pdf [21] VMWARE, Inc. Windows XP Deployment Guide [online]. 2008 [cit. 2012-05-18]. Dostupné z: http://www.vmware.com/files/pdf/XP_guide_vdi.pdf [22] VMware High Server Availability & Business Continuity via Virtualization. VMWARE, Inc. VMware Virtualization Software for Desktops, Servers & Virtual Machines for Public and Private Cloud Solutions [online]. © 2012 [cit. 2012-04-16]. Dostupné z: http://www.vmware.com/technical-resources/high-availability/index.html [23] Minimum system requirements for installing vCenter Server. In: VMware KB: Knowledge Base Articles for all VMware Products [online]. © 2012 [cit. 2012-06-07]. Dostupné z: http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayK C&externalId=1003882
74
Seznam použitých zkratek AD - Active Directory
OEM – Original Equipment Manufacturer
CAL - Client Access License
OS – Operating System
CPU – Central Processing Unit
P2V - Physical to Virtual
DHCP - Dynamic Host Configuration Protocol PC – Personal Computer DRS - Distributed Resource Scheduler
PCoIP – PC over IP
FC - Fibre Channel
PXE – Pre-boot Execution Environment
FT - Fault Tolerance
RAM – Random-Access Memory
GUI - Graphical user interface
RDC - Remote Desktop Connection Client
HA - High Availability
RDP – Remote Desktop Protocol
HDD - hard disk drive
RDS - Remote Desktop Services
HDX – High Definition user Experience
SaaS - software-as-a-service
HTTP - Hypertext Transfer Protocol
SCSI - Small Computer System Interface
HW – Hardware
SID - Security Identifier
I/O - Input/Output
SOAP - Simple Object Access Protocol
IHV - Independent hardware vendor
SQL - Structured Query Language
IOPS - Input/Output Operations Per Second
TFTP - Trivial File Transfer Protocol
IP - Internet Protocol
URL - Uniform Resource Locator
IT – Information Technology
USB – Universal Serial Bus
LAN – Local Area Network
VDA - Virtual Desktop Access
LGPL - Lesser General Public License
VDI – Virtual Desktop Infrastructure
MCS - Machine Creation Service
VSC – Virtualisation Services Consumers
MS - Microsoft
VSP - Virtualisation Services Provider
ODBC - Open Database Connectivity
WMI – Windows Management Instrumentation
Seznam použitých obrázků Obrázek 1-1: Architektura VMware vSphere .......................................................................... 11 Obrázek 1-2: Transparent Memory Sharing ............................................................................ 12 Obrázek 1-3: Architektura Microsoft Hyper-V ....................................................................... 13 Obrázek 2-1: Architektura produktu VMware View ............................................................... 18 75
Obrázek 2-2: VMware View Composer .................................................................................. 21 Obrázek 2-3: ThinApp Streaming Execution mode ................................................................. 23 Obrázek 2-4: Horizon Application Manager ........................................................................... 24 Obrázek 2-5: Architektura Microsoft VDI............................................................................... 25 Obrázek 2-6: Microsoft VDI – schéma komunikace komponent ............................................ 27 Obrázek 2-7: Architektura Citrix Hosted VDI ......................................................................... 29 Obrázek 3-1: VMware View Planner – architektura ............................................................... 35 Obrázek 4-1: Výpočet potřebného výkonu pomocí nástroje pro sizing VDI .......................... 40 Obrázek 5-1: Konfigurace ESXi .............................................................................................. 45 Obrázek 5-2: Konfigurace ESXi .............................................................................................. 45 Obrázek 5-3: Konfigurace ESXi .............................................................................................. 45 Obrázek 5-4: Virtuální stroj pro VMware vCenter Server ...................................................... 46 Obrázek 5-5: Síťové porty pro vCenter Server ........................................................................ 47 Obrázek 5-6: Síťové porty pro Inventory Service.................................................................... 47 Obrázek 5-7: Web service Inventory Size ............................................................................... 47 Obrázek 5-8: VMware vSphere console .................................................................................. 48 Obrázek 5-9: Vytvoření nové databáze pro View Composer .................................................. 49 Obrázek 5-10: ODBC konektor ............................................................................................... 49 Obrázek 5-11: ODBC konektor ............................................................................................... 49 Obrázek 5-12: Instalace View Composer – Database Information.......................................... 50 Obrázek 5-13: Výběr typu Connection Serveru ....................................................................... 51 Obrázek 5-14: Povolení komunikačních portů ........................................................................ 51 Obrázek 5-15: VMware View Connection Server login .......................................................... 51 Obrázek 5-16: Konfigurace serverů ve View Administratoru ................................................. 51 Obrázek 5-17: Nastavení propojení s vCenter Server .............................................................. 52 Obrázek 5-18: Vytvořené propojení s vCenter Server ............................................................. 52 Obrázek 5-19: Výběr instalovaných komponent View agenta ................................................ 53 Obrázek 5-20: Vytvoření poolu – vCenter Server ................................................................... 55 Obrázek 5-21: Vytvoření poolu – identifikace ........................................................................ 55 Obrázek 5-22: Vytvoření poolu – Pool Settings ...................................................................... 56 Obrázek 5-23: Vytvoření poolu – Provisioning ....................................................................... 57 Obrázek 5-24: Vytvoření poolu – vCenter Settings ................................................................. 57 Obrázek 5-25: Vytvoření poolu – Guest Customization .......................................................... 58 Obrázek 5-26: Vytvoření Poolu – Entitlements… ................................................................... 59 76
Obrázek 5-27: View klient - připojení k serveru ..................................................................... 60 Obrázek 5-28: View klient - přihlašovací údaje ...................................................................... 61 Obrázek 5-29: View klient – výběr poolu ................................................................................ 61 Obrázek 5-30: View klient – virtuální desktop ........................................................................ 61 Obrázek 5-31: Teradici – nástroj pro správu zero klientů ....................................................... 62
Seznam použitých tabulek Tabulka 4-1: Cílový stav učebny - klientská část .................................................................... 36 Tabulka 4-2: Cílový stav učebny - serverová část ................................................................... 36 Tabulka 4-3: Minimální mnoţství potřebné paměti ................................................................. 37 Tabulka 4-4: Minimální diskový prostor ................................................................................. 38 Tabulka 4-5: Shrnutí odhadu min. potřebného výkonu dle dokumentace VMware View ...... 39 Tabulka 4-6: Cena potřebných serverů .................................................................................... 41 Tabulka 4-7: Cena potřebného diskového prostoru ................................................................. 41 Tabulka 4-8: Cena potřebného softwaru .................................................................................. 42 Tabulka 4-9: Cena tenkých klientů .......................................................................................... 42 Tabulka 4-10: SWOT analýza pro projekt nasazení virtualizace desktopů ............................. 43 Tabulka 5-1: Komponenty potřebné pro nasazení VMware View .......................................... 44 Tabulka 7-1: Spotřeba el. energie klasického PC .................................................................... 66 Tabulka 7-2: Spotřeba elektrické energie zero klienta............................................................. 66 Tabulka 7-3: Spotřeba elektrické energie blade serveru .......................................................... 66 Tabulka 7-4: Celková spotřeba obou řešení za jeden rok ........................................................ 67 Tabulka 7-5: Celková spotřeba obou řešení za jeden rok při vyuţití power managementu .... 67 Tabulka 7-6: Celková spotřeba pro 3 učebny za jeden rok s vyuţitím power manag. ............ 68 Tabulka 7-7: Investiční náklady na vybudování klasické učebny ........................................... 68 Tabulka 7-8: Investiční náklady na vybudování virtualizované učebny.................................. 68
77
