Virtualizace koncových stanic Desktop Virtualization
ZADÁNÍ
UNICORN COLLEGE Katedra informačních technologií BAKALÁŘSKÁ PRÁCE Virtualizace koncových stanic Autor BP: Petr Lenz Vedoucí BP: Ing. Tomáš Kroček 2014 Praha
Čestné prohlášení Prohlašuji, že jsem svou bakalářskou práci na téma Virtualizace koncových stanic vypracoval samostatně pod vedením vedoucího bakalářské práce a s použitím výhradně odborné literatury a dalších informačních zdrojů, které jsou v práci citovány a jsou také uvedeny v seznamu literatury a použitých zdrojů. Jako autor této bakalářské práce dále prohlašuji, že v souvislosti s jejím vytvořením jsem neporušil autorská práva třetích osob a jsem si plně vědom následků porušení ustanovení 11 a následujících autorského zákona č. 121/2000 Sb. V Praze dne 30. 4. 2014.
Poděkování Děkuji vedoucímu práce Ing. Tomáši Kročkovi za účinnou metodickou, pedagogickou a odbornou pomoc a další cenné rady při zpracování mé bakalářské práce.
Virtualizace koncových stanic Desktop Virtualization 6
Abstrakt Tato bakalářská práce si klade za cíl popsat přehled aktuálních virtualizačních řešení na trhu, a to jak z hlediska samotné virtualizace, tak z hlediska na ní se zakládající virtualizace koncových stanic - desktopů. První část bakalářské práce popisuje aktuální řešení a dosavadní poznatky v oblasti virtualizace. Druhá část je zaměřena na implementaci tohoto nového přístupu v komerčním sektoru a zabývá se jím jak z hlediska procesního, tak nákladového. Poslední část práce obsahuje vhodná doporučení a zhodnocení. Klíčová slova: virtualizace, koncové stanice, servery, licence Abstract The goal of this Bachelor s dissertation is to describe an overview of present virtualization solutions on the market, both from the point of view of the virtualization itself and from the perspective of how virtualization manifests itself at end workstations, such as desktops. The first part of the Bachelor s dissertation describes current solutions and present findings in virtualization area. The second part is focused on implementation of this new approach in commercial sector and pursues this approach from the point of view of both procedure and costs. The final part contains suitable recommendations and evaluation Keywords: virtualization, end workstations, servers, licenses 7
Obsah 1 ÚVOD 11 2 REŠERŠE 14 2.1 Dostupná virtualizační řešení na trhu 14 2.2 Klasifikace virtualizace 16 2.2.1 Podle typu hypervisoru 16 2.2.2 Podle vazby na fyzický hardware 17 2.3 Přehled možných způsobů nasazení VDI 18 2.3.1 Nasazení technologie VDI na platformě Microsoft 18 2.3.2 Nasazení technologie VDI na platformě Citrix 26 2.3.3 Nasazení technologie VDI na platformě VMware 32 2.4 Licencování zmiňovaných virtualizačních platforem 37 2.4.1 Licencování Microsoft VDI 37 2.4.2 Licencování Citrix VDI 38 2.4.3 Licencování VMware VDI 39 3 Plánování přechodu na virtuální prostření 41 3.1 Plánování rozpočtu a typické manipulace 41 3.2 Odhad pracnosti přípravy VDI prostředí 45 3.2.1 Odhad pracnosti nasazení Microsoft VDI 45 3.2.2 Odhad pracnosti nasazení Citrix VDI 46 3.2.3 Odhad pracnosti nasazení VMware VDI 46 3.2.4 Shrnutí odhadu pracnosti 46 3.3 Proces přechodu na VDI 48 3.3.1 Identifikace potřeb a analýza možností 48 3.3.2 Nasazení vybraného řešení 50 3.4 Oblasti dotčené přechodem na VDI 51 3.5 Rizika spojená s přechodem na VDI 53 4 Ekonomická analýza virtualizace koncových stanic 57 4.1 Předpoklady 58 8
4.2 Náklady na HW pro VDI 59 4.2.1 Serverová infrastruktura 59 4.2.2 Koncové stanice, koncové body 61 4.3 Náklady na software 62 4.3.1 VDI na platformě Microsoft 62 4.3.2 VDI na platformě Citrix 62 4.3.3 VDI na platformě VMware 63 4.3.4 Společnost nemá licence zařazené v programu Software Assurance 63 4.3.5 Společnost má licence zařazené v programu Software Assurance 64 4.4 Náklady na správu 64 4.5 Náklady na migraci do prostředí VDI 66 4.6 Náklady na spotřebu elektrické energie 66 4.7 Průměrné náklady na VDI 68 4.8 Porovnání mezních nákladů na nového uživatele 70 5 Diskuze 72 6 Závěr 74 7 Seznam použitých zkratek 76 8 Seznam použité literatury 78 9 Seznam obrázků 79 10 Seznam tabulek 81 11 Seznam grafů 82 9
CÍL PRÁCE Cílem mé práce je nejen identifikovat aktuálně dostupná řešení na trhu virtualizace koncových stanic z hlediska licenčního a hlediska technologického, ale pokusit se i identifikovat vhodné aplikace této technologie a zaměřit se na samotný proces implementace, který je často opomíjen a mnohdy hraje kritickou roli v dopadu na úspěšnost celého projektu. Tato oblast je v současné době elektronické komunikace velmi důležitá a neúspěšnost projektu migrace celé infrastruktury, která je pro chod firmy toliko kritická, může mít fatální následky nefunkčnost celé organizace. Dílčími cíli je zpracovat analýzu dostupných řešení na trhu virtualizace koncových stanic, popsat obecné principy samotné technologie virtualizace, popsat a analyzovat proces implementace virtualizace koncových stanic, analyzovat dotčené oblasti a zároveň možná rizika, která mohou nastat během implementace. Projekt virtualizace koncových stanic je pro společnost strategickou investicí, a proto je třeba zabývat se i kalkulací nákladů a jejich porovnáním pro ucelení představy o rozdílech mezi jednotlivými produkty na trhu. 10
1 ÚVOD V poslední době se desktop pro mnoho firem a především pro jejich IT oddělení stává klasickou spotřební záležitostí, jejíž strategická hodnota nijak nepřekračuje ostatní vybavení kanceláří. Proto ani nejsou předmětem diskusí a zájmů, kde je postupně nahrazují moderní technologie poskytované formou internetu (Cloud, Saas). Nelze se proto pozastavovat nad faktem, že se tyto technologie mohou a velmi často se také objevují na strategických dokumentech při plánování vnitropodnikové ICT infrastruktury, kde jsou především podporovány mladší generací IT profesionálů, která nemá zkušenosti s érou nedávnou a nezažili tak tradiční projekty a jejich řešení. Apriorní neznalost řešení problémů typických pro již zmiňovanou desktopovou infastrukturu může vyústit ve snadnou manipulovatelnost jak mediálními prostředky, tak dveře neuvolnivši obchodními zástupci firem, kteří se snaží prodávat VDI virtualizaci koncových stanic. Zatímco lidé, kteří byli součástí zmiňované éry, odešli či změnili pozice, ve většině firem stále přetrvává krabicová IT strategie. Krabicová proto, že správa počítačů ve firmě jednoduše znamená objednání palety nových počítačů, rozbalení, nasazení připraveného firemního image, konfigurace pro konkrétního uživatele, migrace dat, spravování. Ač lidé prosazující VDI mohou namítat, že tento postup je zastaralý, není na něm ve skutečnosti vůbec nic špatného. Je již 15 let funkční a prověřený. Je také úzce spjatý s jedním z typických projektů téměř všech společností, a to migrací na nové generace operačních systémů, naposledy z Windows XP na Windows 7. Ve skutečnosti se jedná o mnohem větší transformaci IT, než jakou aktuálně představuje VDI. Takovýto přechod je pro větší společnosti kritický a přináší mnoho výzev. Je potřeba se vypořádat s kompatibilitou aplikací, kompatibilitou hardware, 64 bit architekturou, novým modelem zabezpečení a novým modelem uživatelských profilů. Naštěstí je tento proces transformace stejný již po dlouhá léta, protože stejně tak probíhal přechod z Windows 2000 na Windows XP, přechod z Windows 98 na Windows XP atd. Ve skutečnosti se jedná o další riziko neuváženého přechodu na VDI, neboť zvládání zmiňovaných výzev a zkušenosti s těmito projekty se nedají očekávat u mladé generace, ale u zkušených profesionálů, kteří již nemusí být součástí projektového týmu. Zaleknutí se obtížné situace tak láká k použití snazší cesty, kterou VDI může na první pohled být, ač tomu tak, jak si později ukážeme, vůbec není. 11
Velmi důležité je také si uvědomit, že virtualizace desktopů je diametrálně odlišná od virtualizace serverů. Obě oblasti mají jiná kritéria pro hodnocení úspěšnosti projektu a jiné požadavky na fyzický hardware. Pokud je management nadšen tím, jak efektivní je infrastruktura pro virtualizaci serverů, je potřeba si uvědomit, že virtualizace desktopů se nemusí a velmi pravděpodobně ani nebude odvíjet ve stejném duchu. Virtualizace serverů je oblast, která je známá již dlouhá léta, ale až v nedávné době došlo na její definitivní akceptaci i ve firemním prostředí a dnes je téměř 100 % serverů virtualizovaných. Téměř pouze z toho důvodu, že pro některé aplikace je to technologie principiálně nevhodná a je nutné použít bare-metal instalaci. Může se jednat například o doménové řadiče, u kterých je toto zatím doporučováno. Majoritní zastoupení technologie na trhu je způsobeno obrovskými přínosy, kde mezi hlavními jsou úspory z konsolidace serverů. Původní model představoval nákup serveru, na kterém byl nainstalovaný jediný operační systém a který byl vytížený například na 20 % výkonu. Virtualizace serverů přinesla možnost provozovat na jediném fyzickém serveru například 6 virtuálních serverů, které tak dokáží potenciál fyzického hardware efektivně využít. Projeví se to nejen v úsporách na hardware, ale s tím spojených úsporách za datová pole, energetickou spotřebu, chlazení. Další nezanedbatelnou výhodou virtualizace serverů je centralizovaná správa z jedné konzole a možnosti automatizace. Centralizovaná správa přináší flexibilitu, kterou business v poledních letech vyžaduje. IT oddělení společnosti je tak schopné velmi rychle reagovat na měnící se požadavky a nasazovat či upravovat infrastrukturu ve velmi krátkém čase na vyžádání. Automatizace je více cílena na privátní oblast cloudu. Zde umožňuje například zpřístupnit některé funkce virtualizačního prostředí businessu v lidské formě a následně tyto funkce automatizovat. Jako příklad lze uvést požadavek oddělení společnosti na vytvoření virtuálního serveru pro testování aplikace. Pro takovéto požadavky je zřízen centrální interní web společnosti, ve kterém je připraven (kromě seznamu možných požadavků) formulář. Uživatel ve formuláři vyplní název virtuálního stroje a jeho charakteristiky, formulář odešle. Tento požadavek dorazí na definované zodpovědné osoby a čeká na schválení. Přes všechny klady je nezbytné pracovat s evidentními riziky virtualizace serverů. Flexibilita snadno svádí správce k vytváření mnoha virtuálních serverů na jednom fyzickém hostu. Typicky tak na jednom hostitelském serveru sídlí veškeré síťové 12
služby a porucha hostitelského serveru končí nedostupností všech hostovaných serverů. Dopady uvnitř organizace mohou být při takovéto neuváženosti naprosto katastrofální. Je třeba zdůraznit, že technologie pokročily a zmiňovaná porucha představuje hlavně poruchu hardware. Porucha řídícího serveru běžně neohrozí chod hostovaných serverů. 13
2 REŠERŠE 2.1 Dostupná virtualizační řešení na trhu Na trhu virtualizace hrají 3 významní hráči: Microsoft, VMware, Citrix. Nejtradičnější společností je zde Citrix, který s myšlenkou virtualizace přišel jako první. Jednalo se o produkt Citrix WinFrame, který byl v podstatě víceuživatelskou verzí Windows NT 3.51, díky které se mohli uživatelé přihlašovat na WinFrame server a spouštět aplikace. Microsoft v tomto řešení identifikoval příležitost a již společnými silami se společností Citrix dal vzniknout speciální edici Windows NT 4.0 Terminal Server. Později Microsoft přijal tuto technologii jako samostatnou součást Windows, ač dnes již pod názvem Remote Desktop Services, a tento výsledek společného snažení můžeme využívat i v posledních verzích produktů Microsoft: Windows 8 a Windows Server 2012 R2. Implementace firmou Microsoft neznamenala pro Citrix konec. Tato firma nadále vyvíjí samostatně své produkty a posledním počinem je řešení XenApp, které slouží pro aplikační virtualizaci a umožňuje uživatelům spouštět business aplikace umístěné na centrálním serveru. Pro záměry této práce je však důležitější produkt Citrix XenDesktop, který slouží jako komplexní řešení pro virtualizaci koncových stanic. Nutno podotknout, že velká část Citrix virtualizačních nástrojů je distribuována zdarma a licenční náklady jsou spojené s pořizováním nástrojů pro správu prostředí. VMware se ujal slova na scéně kolem roku 1999, kdy se datuje vznik populárního nástroje VMware Workstation, který přinesl první virtualizaci desktopu na trhu. Produkt byl přijat zpočátku jako prostředí pro virtuální laboratoř, tedy prostředí, kde bylo možné provozovat za účelem vývoje či testování rozličné operační systémy. Úspěch předjímal rozšíření na trh serverů, ale lidé zpočátku nepovažovali virtualizaci za řešení, do kterého by svěřili svá produkční prostředí. K tomuto kroku došlo, když si firmy uvědomily, že na virtualizaci lze ušetřit nemalé finanční prostředky. Možnost nasadit na jeden fyzický server více virtuálních serverů znamená efektivní využití nejen jeho výkonnostního potencionálu a úspory, které jsem zmiňoval v předchozí kapitole, ale také efektivní využití IT infrastruktury z pohledu nabízení služeb a zdrojů. Pro provoz nové služby již není nezbytně nutné pořizovat fyzický server, což se projevuje také v rychlosti nasazení nového serveru. U virtuálních serverů rovněž částečně odpadá starost o HW ovladače, protože komunikaci s HW zajišťuje samotný hypervisor pomocí 14
tzv. integračních komponent. Celá infrastruktura je navíc spravovaná z centrální konzole pro správu. Jednotlivé nástroje si popíšeme v dalších kapitolách. Pro business je díky virtualizaci relativně snadné zabezpečení vysoké dostupnosti. Vysokou dostupností (high availability = HA) se rozumí taková konfigurace, kdy dostupnost služeb celku není závislá na jednom fyzickém serveru, resp. kdy výpadek jednoho serveru či služby může být okamžitě kompenzován dalšími servery. V reálném prostředí je tato technologie řízena právě centrální konzolí pro správu, která zajistí přesun služby z havarovaného fyzického serveru na druhý domluvený funkční server. V aktuální etapě vývoje virtualizačních nástrojů potom může dle zakoupené verze management prostředí dojít buď ke krátkému výpadku anebo není zaznamenán výpadek vůbec. Pokud se, například v důsledku chybného návrhu, objeví v infrastruktuře uzel, jehož selhání vede k nedostupnosti všech služeb, hovoříme o tzv. jediném bodu selhání (Single Point of Failure). Protože pro tento výraz není zaběhnutý český překlad, dovolím si nadále používat pouze anglický název. V oblasti virtualizace serverů se ale už bavíme o produktech VMware ESX / ESXi Server. Ač jsme Microsoft zmiňovali v úvodu ve spojení se společností Citrix, služba Microsoft Server nazvaná Remote Desktop Services pod tíhou posledních trendů nezůstala dlouho osamocena a Microsoft přišel s technologií Hyper-V, která představuje vstupní bránu této společnosti do světa virtualizace serverů a koncových stanic. Hyper-V je k dispozici buď jako tzv. role instalovaná do operačního systému Windows Server anebo jako samostatná a zdarma distribuovaná edice Microsoft Hyper-V Server. Přehled všech dodavatelů virtualizačních technologií znázorňuje následující obrázek od společnosti Gartner. 15
Obrázek 1 Přehled pozice poskytovatelů virtualizačních technologií na trhu Zdroj: Gartner (2014) 2.2 Klasifikace virtualizace 2.2.1 Podle typu hypervisoru Zaměříme-li se pouze na virtualizaci pevných stanic, tedy opomineme virtualizaci uživatelského profilu (RDSH), můžeme identifikovat dva typy hypervisoru. Hypervisor je obecně softwarová komponenta, firmware nebo hardware, který umožňuje vytváření, běh a správu virtuálních počítačů. Těmto virtuálním počítačům tedy poskytuje buď přístup k fyzickému HW, nebo jej emuluje [1]. Mírně matoucí může být anglická terminologie, která hostující zařízení nazývá Host a hostované zařízení Guest. Type 1 Tento typ se také nazývá bare-metal nebo nativní. Z toho vyplývá, že tento hypervisor opravdu běží přímo na HW vrstvě, spravuje HW a spravuje hostované (Guest) operační systémy. Hostované operační systémy (Guest) běží přímo nad hypervisorem a komunikují proto přímo s HW. Systémy jsou dokonale oddělené a nejsou závislé na žádném jiném operačním systému. 16
Type 2 Tento typ hypervisoru je na rozdíl od Type 1 nainstalovaný v operačním systému, na kterém je také závislý. Plynou z toho dvě zásadní informace. Tou první je, že systém hostovaný takovým hypervisorem není schopný běhu, aniž by nastartoval hostující operační systém. Druhá přímo implikuje z té první. Hostovaný operační systém nemá přímý přístup k HW vybavení a veškeré dotazy na přerušení jsou překládány. Obě vlastnosti vedou k poklesu výkonu virtuálního hostovaného počítače. Obrázek 2 - Grafické znázornění obou typů hypervisoru VM1 VM2 VM3 VM4 VM1 VM2 VM3 VM4 Hypervisor Hardware Hypervisor OS Hardware Zdroj: Vlastní zpracování Type 1 Type 2 2.2.2 Podle vazby na fyzický hardware Emulace Emulace je takový typ virtualizace, kdy celý virtuální stroj je podporovaný pouze softwarově. Jedná se tedy o emulaci hardware, na kterém je spuštěn virtuální operační systém. Z principu tento stroj nemá žádný přístup k hardware a veškeré požadavky na tento hardware je potřeba interpretovat. To má velmi negativní dopad na rychlost/výkon. Hlavní výhodou a důvodem pro používání tohoto typu virtualizace proto zůstává pouze možnost provozovat operační systémy jiné architektury, než je architektura hostitelského OS. Velmi často se toho využívá pro testování mobilních aplikací, kdy se spouští emulovaný mobilní OS. Ukázkou budiž emulace Windows Phone z prostředí Visual Studio. 17
Paravirtualizace Tento typ se uplatňuje u unixových operačních systémů, na Microsoft platformě je nedostupný. Příčina spočívá v nutnosti úpravy jádra OS. Tato úprava zajišťuje přesměrování požadavků na hardware na rozhraní, které volá služby hypervisoru. Toto rozhraní se nazývá ABI (Application Binary Interface). Hardwarově asistovaná virtualizace Vzhledem k rostoucím požadavkům na výkon virtualizovaných řešení v důsledku expanze virtualizace do produkčních prostředí se virtualizaci dostalo podpory ze strany výrobců HW, resp. majoritně ze strany výrobců procesorů Intel a AMD. Tato virtualizace představuje tzv. bare metal instalaci hypervisoru, tedy instalaci přímo nad HW. Zpracování požadovaných instrukcí potom tento hypervisor provádí přímo za asistence HW. K tomuto výše zmiňovaní výrobci Intel a AMD vybavují své procesory instrukcemi pro podporu virtualizace. V případě společnosti Intel se tato technologie nazývá Intel-VT a v případě AMD se nazývá AMD-V. 2.3 Přehled možných způsobů nasazení VDI Tato kapitola představuje přehled možných způsobů nasazení technologie virtualizace koncových stanic. Na trhu existuje více společností zabývajících se problémovou oblastí, ale můj výběr je omezený na dle mého názoru tři hlavní představitele této technologie na světovém trhu. Jsou jimi Microsoft, Citrix a VMware. Zabývat se analýzou všech možných řešení a produktů není cílem této práce a není to možné ani z hlediska rozsahu práce. 2.3.1 Nasazení technologie VDI na platformě Microsoft Společnost Microsoft nenabízí pro účely virtualizace koncových stanic přímo dedikovaný produkt, ale jedná se o roli Windows Server, aktuálně ve verzi Windows Server 2012 R2. Tento produkt je nabízen ve čtyřech následujících edicích: Foundation, Essentials, Standard, Datacenter. Technologie VDI je podporována u edic Standard a Datacenter, verze Essentials a Foundation jsou cílené především na malé a začínající firmy jako levná cesta k budování IT infrastruktury. Technologicky se edice Standard a Datacenter nijak neliší, případné rozhodování je tak spíše business charakteru, protože zatímco edice Standard umožňuje provozovat 2 virtuální instance, edice Datacenter 18
umožňuje provozovat neomezený počet virtuálních instancí! Z principu poskytování virtualizace koncových stanic formou role OS Windows Server jasně plyne nutnost provozovat tuto technologii pouze na hypervisoru Microsoft Hyper-V. Hyper-V se instaluje jako role systému Microsoft Windows Server. Tato role se automaticky instaluje i v případě instalace role pro virtualizaci koncových stanic (Remote Desktop Services). Během instalace této role dojde k tomu, že mezi doposud fyzicky nainstalovaný OS Windows Server a HW se vsune virtualizační vrstva a tento systém se tak stává také virtuálním a nazývá se Parent Partition. Podporované hostované operační systémy (guests) 1 Microsoft Windows Server Microsoft Windows Vista Microsoft Windows XP Microsoft Windows Home Server Microsoft Small Business Server Microsoft Windows 7 Microsoft Windows 8, 8.1 CentOS a Red Hat Enterprise Linux Debian Oracle Linux Ubuntu Instalace Remote Desktop Services Role je velmi snadná a obnáší pouze volbu scénáře, v našem případě nasazení VDI pomocí virtuálních koncových stanic (Virtual machinebased deployment) a dále rozložení jednotlivých komponent této role (RD Connection Broker, RD Web Access, RD Virtualization Host) na disponibilní servery. Role je díky tomu možné delegovat na více serverů, ale stejně tak je možné všechny provozovat na jednom jediném. 1 Podrobný přehled podporovaných verzí a jejich omezení je k dispozici online na adrese http://technet.microsoft.com/en-us/library/hh831531.aspx 19
Obrázek 3 - Volba scénáře VDI Zdroj: Vlastní zpracování (snímek obrazovky z instalace role RDS) Obrázek 4 - Distribuce komponent role RDS na jediný server Zdroj: Vlastní zpracování (snímek obrazovky z instalace role RDS) Druhým krokem je vytvoření kolekce virtuálních stanic. Důležitou volbou je typ kolekce, který může být buď osobní (Personal virtual desktop collection) nebo sdružený 20
(Pooled virtual desktop collection). Osobní kolekce přiděluje připojujícím se uživatelům neustále ten samý virtuální počítač s jeho daty a poskytuje administrátorská práva, sdružená kolekce přiděluje virtuální počítače připojujícím se uživatelům vždy nově vygenerované podle šablony obrazu referenčního systému, uživatelská data ukládá na odděleném profilovém disku a neposkytuje administrátorská oprávnění! V dalším kroku se zvolí referenční operační systém, který bude sloužit jako šablona pro vytvářené a přidělované virtuální operační systémy. Šablonu lze vytvořit z virtuálních počítačů nainstalovaných rovněž v Hyper-V, je zde tedy vhodné mít připravený virtuální počítač s požadovanou aplikační sadou a nainstalovanými integračními komponentami. Tento virtuální počítač musí být zobecněn pomocí nástroje sysprep! Při přípravě instalace, tedy spouštění nástroje sysprep je nutné mít na paměti, že tento nástroj můžete spouštět, kolikrát chcete, ale rearm - tedy vynulování aktivace může být spuštěno pouze třikrát. Pokud připravujete počítač pro imaging, můžete v labu použít SkipRearm v odpovědním XML souboru, který použijete společně s nástrojem sysprep [2]. Obrázek 5 - Zobecnění pomocí nástroje Sysprep Zdroj: Vlastní zpracování 21
Obrázek 6 - Volba šablony virtuálních počítačů Zdroj: Vlastní zpracování (snímek obrazovky z konfigurace kolekce VDI) Následují snadné kroky jako nastavení samoobslužné instalace pomocí průvodce nebo vloženého souboru, počet virtuálních počítačů vytvářené kolekce, jejich zařazení v Active Directory (proto je nezbytné instalovat VDI na počítači připojeném do domény), alokace zdrojů, umístění souborů virtuálních desktopů (virtuálních disků) a nakonec umístění uživatelských disků (obsahující data uživatelského profilu ve scénáři Pooled virtual desktop collection). 22
Obrázek 7 - Definice úložiště pro virtuální počítače Zdroj: Vlastní zpracování (snímek obrazovky z konfigurace kolekce VDI) Nástroje pro správu řešení Řešení VDI prostředí Microsoft lze spravovat dvěma továrními nástroji. Prvním nástrojem je Hyper-V Manager, který je součástí nástrojů pro správu systému Windows, případně je ke stažení v rámci balíku Remote Server Administration Tools 2. Po instalaci tohoto balíku je ještě nutné tuto funkcionalitu povolit ve funkcích systému Windows. Obrázek 8 - Povolení nástrojů pro správu technologie Hyper-V Zdroj: Vlastní zpracování (snímek obrazovky Windows, správa funkcí Windows) 2 Aktuální verze pro Windows 8.1: http://www.microsoft.com/en-us/download/details.aspx?id=39296 23
Obrázek 9 - Hyper-V Manager Zdroj: Vlastní zpracování (snímek obrazovky Hyper-V Manager) Hyper-V Manager zastává roli základního nástroje pro správu Hyper-V infrastruktury, podporuje správu virtuálních počítačů, správu virtuální infrastruktury, správu snímků virtuálních počítačů, jejich replikace atd. Ve verzi 2012 Microsoft vyslyšel přání odborné komunity a implementoval do Hyper-V podporu virtuálních switchů a virtuálních sítí. To mimo jiné otevřelo cestu k používání softwarových firewallů třetích stran. Například společnost 5nine Software poskytuje aplikaci 5nine Cloud Security for Hyper-V 3 jako doplněk do Hyper-V Extensible Switch, díky čemuž je možné zabezpečit virtuální počítače bez jakékoliv klientské instalace antivirových řešení. Pokročilým nástrojem je System Center Virtual Machine Manager, aktuálně ve verzi 2012 R2. System Center Virtual Machine Manager (dále jen SCVMM) je nástroj z rodiny System Center. Jeho hlavním přínosem je zvýšení efektivity a podpora maximální možné dostupnosti virtualizačního prostředí. Zajímavé je, že pomocí tohoto 3 Webová prezentace projektu: http://www.5nine.com/5nine-security-for-hyper-v-product.aspx#compare 24
nástroje je možné spravovat nejen Hyper-V prostředí, ale rovněž prostředí VMware. Zde je souhrn hlavních funkcí, které podporují zmíněné přínosy 4 : Živé migrace úložiště v rámci stejného hostitele a mezi hostiteli s minimálními výpadky virtuálních strojů. Řazení živých migrací umožňující provádět několik živých migrací, aniž by bylo nutné sledovat prostředí, zda již nějaké migrace neběží. Migrace fyzického PC na virtuální PC pomocí snadného průvodce a jednoduchého agenta nainstalovaného na převáděný fyzický PC. Režim údržby, který dokáže z virtualizačního serveru migrovat virtuální stroje na jiný virtualizační server, umožňuje snadno provádět údržby nebo upgrade virtualizačních serverů. Integrace s nástrojem System Center Operation Manager (SCOM) umožňující optimalizaci výkonu zdrojů pomocí funkce Performance and Resource Optimization obsažené v SCVMM. Jednotlivá varování SCOM mohou být promítnuta do SCVMM, například v případě překročení definovaných hraničních hodnot se spustí load-balancing nebo migrace virtuálních strojů mezi servery. Delegování správy pomocí uživatelských rolí, které umožňuje pomocí přiřazení uživatelů do stanovených rolí určit jejich pravomoci ve virtualizačním prostředí. Pravomoci se pohybují od správy celé infrastruktury po jasně definované činnosti v rámci jednoho virtuálního stroje pomocí portálu System Center App Controller 2012 (dříve Self Service Portal). System Center Virtual Machine Manager vyžaduje plnou verzi Microsoft SQL Serveru a aktuálně podporovaná verze je 2008 R2! Microsoft SQL Server 2012 není prozatím podporován. 4 Kompletní přehled funkcí vizte: http://social.technet.microsoft.com/forums/systemcenter/en- US/08b2f1f3-f88d-4c1c-8b3b-11a8952f9a52/things-that-you-can-not-do-with-scvmm-but-hypervconsole?forum=virtualmachinemanager 25
Obrázek 10 - System Center Virtual Machine Manager 2012 R2 Zdroj: Vlastní zpracování (snímek obrazovky SCVMM z testovacího prostředí) 2.3.2 Nasazení technologie VDI na platformě Citrix Společnost Citrix nabízí pro účely virtualizace koncových stanic produkt XenDesktop. Tento je v době psaní práce dostupný ve verzi 7.1 a předpokládá nasazení v OS Windows Server, kde nejnovější podporovanou verzí je OS Windows Server 2008 R2. Nový Windows Server 2012 / 2012 R2 prozatím podporovaný není. Teoreticky není podstatné na jakém hypervisoru bude tento serverový OS nainstalován, ba dokonce ani není podstatné, jestli bude virtualizován. Společnost Citrix pro tyto účely poskytuje vlastní Citrix XenServer, aktuálně ve verzi 6.2. XenServer je k dispozici ke stažení a nasazení zcela zdarma. Celkem je zde tedy možnost provozovat infrastrukturu na následujících hypervisorech: Citrix XenServer Microsoft Hyper-V VMware ESXi 26
Podporované hostované operační systémy (guests) 5 Microsoft Windows 7 Microsoft Windows Server Microsoft Windows Vista Microsoft Windows XP CentOS Red Hat Enterprise Linux SUSE Linux Enterprise Server Oracle Enterprise Linux Debian Ubuntu Nutno podotknout, že nasazení XenDesktop předpokládá instalaci tohoto prostředí do virtuálního počítače platformy Windows, z principu VDI potom vyplývá, že to musí být Windows Server, ideálně ve verzi 2008 R2. Tento server musí být připojený do podnikové domény a musí mít nainstalované tzv. XenTools, které jsou ovladači virtuálního počítače pro komunikaci s fyzickým HW a jsou součástí XenServer instalace. Není proto potřeba obdobně jako u VMware či Microsoft stahovat další médium, stačí pouze daný obraz připojit (mount). Dále je potřeba povolit na Windows Serveru funkci. NET 3.5 (tato se neinstaluje, ale takto povoluje). Po splnění těchto kroků je konečně možné nainstalovat XenDesktop. Prostředí vyžaduje přítomnost databáze, proto lze v rámci instalace volitelně nainstalovat Microsoft SQLExpress. 5 Podrobný přehled podporovaných verzí a jejich omezení je k dispozici online na adrese https://support.citrix.com/servlet/kbservlet/download/30196-102-673808/guest_support_6.0.2.pdf 27
Obrázek 11 - Výběr komponent při instalaci XenDesktop Zdroj: Vlastní zpracování (snímek instalace XenDesktop) Obrázek 12 - Konfigurace portů firewallu Zdroj: Vlastní zpracování (snímek instalace XenDesktop) První spuštění nainstalovaného XenDesktop je provázeno konfigurací připojení k databázovému serveru a připojení k hypervisoru, připojení k licenčnímu serveru (tento 28
může být instalován i lokálně), definicí a připojením zdrojů poskytovaných XenServerem (síťová rozhraní), výběrem úložišť pro virtuální počítače a případně pro personální disky uživatelů. Posledním krokem je volba, zda se bude využívat aplikační virtualizace. Tímto je dokončená instalace prostředí XenDesktop z pohledu softwarových komponent, což je velmi snadné ověřit pomocí nástroje konfigurace nastavení. Výsledkem je rozsáhlý report s podrobnými informacemi o veškeré konfiguraci. Tímto je možné začít používat Citrix Studio ke správě VDI prostředí. Základním krokem je vytvoření katalogu počítačů. Tento nám definuje, jakou formu virtualizace chceme poskytovat v rámci našeho prostředí (Windows Desktop OS, Windows Server OS, Remote PC Access) a zda bude infrastruktura postavena na základě fyzických nebo virtuálních počítačů. Za důležitou volbu považuji způsob přidělování virtuálních počítačů uživatelům, neboť je zde možnost vybrat mezi přidělováním nového náhodného virtuálního počítače, nebo přidělováním pokaždé toho samého virtuálního počítače. Ve druhém případě je potřeba definovat správu uživatelských dat, která mohou být ukládána na separátní virtuální disk (Personal vdisk), na lokální disk virtuálního počítače anebo jednoduše zahozena. Dle mého názoru velmi pracný krok spočívá v přípravě Master Image, tj. referenčního disku, na jehož základě se budou vytvářet požadované virtuální počítače v případě, že budujete infrastrukturu s poskytováním virtuálních počítačů, ať již statických, či náhodně přidělovaných. Je proto potřeba zvážit, jaké aplikace chceme touto formou uživatelům doručovat a do obrazu je integrovat. Toto je ovšem volba, která je závislá na každém projektu a jeho specifických požadavcích. Co musí ovšem každý Master Image obsahovat, jsou XenTools (jsou součástí XenServer, jak jsem již zmiňoval) a Virtual Desktop Agent (je součástí instalačního DVD XenDesktop!). Bez těchto dvou komponent neprojde import Master Image. 29
Obrázek 13 - Instalace VDA Zdroj: Vlastní zpracování (snímek instalace Virtual Delivery Agent z prostředí XenDesktop) Výhodou řešení od Citrix je bezesporu fakt, že pro potřeby Master Image není potřeba zdrojový nainstalovaný a připravený operační systém zobecňovat pomocí nástroje Sysprep, neboť Master Image se vytvoří automaticky z jeho snímku. Obrázek 14 - Výběr virtuálního počítače pro tvorbu Master Image Zdroj: Vlastní zpracování (snímek obrazovky prostředí XenDesktop) 30
Pro vytvářený Master Image je ještě potřeba definovat zdroje, které bude používat (síťová rozhraní), počet virtuálních počítačů poskytovaných v rámci aktuálně vytvářeného katalogu a nakonec globální výkonnostní parametry (počet virtuálních procesorů, velikost RAM, velikost personálního uživatelského disku) společné pro definovaný počet virtuálních počítačů poskytovaných v rámci aktuálně vytvářeného katalogu. Posledním krokem je výběr organizační jednotky Active Directory, do které budou nové virtuální počítače zařazeny a pod jakým názvem (proto je nezbytné instalovat XenDesktop na server připojený do doménové sítě). Role pro nově vytvořené virtuální počítače a oprávnění pro přístup k nim definujeme pomocí tzv. Delivery Groups. Nástroje pro správu řešení Řešení XenServer lze pohodlně spravovat pomocí nástroje XenCenter, který je zdarma k dispozici. Jedná se o Windows aplikaci, aktuální verze je 6.2 (build 1377). Lze pomocí ní, jak lze očekávat, spravovat virtuální stroje a jim přidělované zdroje, monitorovat aktivitu jak hypervisoru XenServer, tak aktivity jednotlivých hostujících virtuálních strojů (guests). Rovněž poskytuje integrovanou konzoli pro grafický výstup virtuálního počítače, správu snímků (snapshots) a logů. Obrázek 15 Prostředí XenCenter Zdroj: Vlastní zpracování (snímek obrazovky z XenCenter) 31
Poslední funkce, kterou bych rád zmínil, je správa aktualizací hypervisoru XenServer, která je ovšem podmíněna platným předplatným XenServer. Toto je nabízeno jako roční v ceně 363,77 nebo jako trvalé předplatné v ceně 909,42. Obrázek 16 Dialogové okno aktualizací, patrná nemožnost aktualizace bez předplatného Zdroj: Vlastní zpracování (snímek dialogového okna XenCenter) 2.3.3 Nasazení technologie VDI na platformě VMware Podle mého názoru nejznámější společnost na poli virtualizace v České republice, VMware, poskytuje pro virtualizaci koncových stanic prostředí, které je nově pojmenované VMware Horizon View. Aktuální dostupná verze nese označení 5.3.0 a předpokládá nasazení v OS Windows Server, kde nejnovější podporovanou verzí je OS Windows Server 2008 R2. Nový Windows Server 2012 a 2012 R2 prozatím podporovaný není. Teoreticky není podstatné na jakém hypervisoru bude tento serverový OS nainstalován, ba dokonce ani není podstatné, jestli bude virtualizován. Společnost VMware pro tyto účely poskytuje vlastní hypervisor ESXi, který je k dispozici zdarma ke stažení. Aktuální verze je 5.5.0. Celkem je zde tedy možnost provozovat infrastrukturu na následujících hypervisorech: Citrix XenServer Microsoft Hyper-V VMware ESXi 32
Podporované hostované operační systémy (guests) 6 : Windows 8 Enterprise a Professional Windows 7 Enterprise a Professional Windows Vista Business a Enterprise Windows XP Professional Windows 2008 R2 Terminal Server Windows 2008 Terminal Server Pro instalaci Horizon View je potřeba stáhnout VMware View Connection Server. Verzování je platné pro všechny komponenty Horizon View, poslední verze je tedy také 5.3.0. Předpokladem pro úspěšnou instalaci je instalace na server se statickou IP adresou a volný tcp/ip port 80. Pokud je tento port již používán, instalaci není možné spustit. Instalace na webový server je proto nevhodná a pravděpodobně by obnášela mnoho komplikací jak se změnou výchozího portu webového serveru, tak s provozem řešené virtualizační infrastruktury. Cílový server musí být také zapojen do domény. Samotný proces instalace je velmi snadný a zabere několik minut. Vyplňuje se pouze heslo pro funkci data recovery, možnost automaticky nastavit FW OS pro potřeby provozu View Connection Serveru a přístupové údaje k doméně. Tuto instalaci považuji za nejjednodušší ze všech testovaných a není zde místo, kde by se mohly vyskytnou vážnější obtíže. Po instalaci je k dispozici na adrese http://<servername>/admin webová konzole, ze které je možné prostředí spravovat. V tomto prostředí je již možné zahájit konfiguraci, především potom konektivitu k vcenter Serveru. Ten slouží, jak jsem již zmiňoval, jako zdroj šablon, tzv. templates, které zde mají naprosto stejný význam jako ve vcenter. Je zde tedy na místě nejprve připravit virtuální počítač s požadovaným OS a aplikační sadou a před tím, než bude tento převeden do šablony, je nutné do něj nainstalovat balíček VMware View Agent pro požadovanou architekturu. Pokud se rozhodnete využít také technologie VMware Blast, která slouží k plnohodnotné práci s virtuálním desktopem v prostředí internetového prohlížeče, je potřeba doinstalovat ještě balíček Horizon View Remote Experience Agent. 6 Podrobný přehled podporovaných verzí a jejich omezení je k dispozici online na adrese http://pubs.vmware.com/view-52/topic/com.vmware.icbase/pdf/horizon-view-52-installation.pdf 33
Obrázek 17 - Rozšiřující vlastnosti balíčku Remote Experience Agent Zdroj: Vlastní zpracování (snímek obrazovky z instalace rozšiřujícího balíčku Remote Experience Agent) Z takto připraveného virtuálního počítače je již v prostředí vcenter Console možné provést konverzi do šablony (template). Není zde nutné provádět generalizaci OS pomocí nástroje Sysprep. Z hlediska konfigurace prostředí je dalším krokem vytvoření poolu virtuálních desktopů, a to automatického, manuálního nebo založeného na Terminal Services. Rozdíl mezi automatickým a manuálním poolem je ve využití komponenty View Composer u automatického poolu. Následně je potřeba definovat, zda budou virtuální počítače poskytované poolem vyhrazené anebo volné. V případě vyhrazených virtuálních počítačů bude uživatel pokaždé připojen k jednomu stejnému virtuálnímu počítači. Druhá možnost potom přiděluje virtuální počítače náhodně. Tím je hotové nastavení chování poolu a v následujících několika krocích dojde k definování vlastností poolu. 34
Obrázek 18 - Definování vlastností virtuálních počítačů poolu Zdroj: Vlastní zpracování (konfigurace poolu virtuálních počítačů) Za pozornost stojí volba přenosového protokolu, resp. výchozího přenosového protokolu pokud je povoleno, aby uživatel měl možnost přenosový protokol si vybrat. Pro někoho může být nejasné použití protokolu RDP z licenčního hlediska. Využití protokolu RDP ale ve skutečnosti neznamená, že se k připojení používá některá komponenta Remote Desktop Services OS Windows Server a proto není nutné licencovat pomocí RDS CAL licencí! Další důležitá nastavení jsou definice počtu virtuálních počítačů poolu, jejich jmenné konvence a chování (kolik virtuálních počítačů má být nastartování v zásobě ). 35
Obrázek 19 -Chování a počet virtuálních počítačů Zdroj: Vlastní zpracování (snímek obrazovky z konfigurace poolu) Poslední důležité nastavení je výběr šablony (template) z vcenter prostředí a cílového prostředí pro virtuální desktopy. Tímto je konfigurace poolu dokončena. Pro každý pool je nezbytné definovat uživatele, kteří se budou moci připojit k infrastruktuře virtuálních desktopů. Uživatele je možné vyhledávat v podnikové doméně. Zvolili-li jsme dedikované přiřazení desktopu uživatelům bez možnosti automatického přiřazení (při prvním přístupu), je nezbytné definovat oprávněného uživatele pro každý jednotlivý virtuální počítač. Jinak bude uživateli oznámena chybová hláška o nedostatečném oprávnění. 36
2.4 Licencování zmiňovaných virtualizačních platforem 2.4.1 Licencování Microsoft VDI Společnost Microsoft nabízí u svého řešení VDI několik způsobů licencování: Software Assurance Virtual Desktop Access (VDA) Windows Intune Companion Subscription License (CSL) Software Assurance (SA) SA je licenční program, který zákazníkovi zajišťuje možnost přechodu na nejnovější verzi produktu, a to kdykoliv během trvání SA smlouvy. SA lze zakoupit v dvouletých (OLP) 7 nebo tříletých (SA, EA) 7 multilicenčních programech. K produktům pořizovaným v některé multilicenční smlouvě lze Software Assurance přidat pouze v okamžiku nákupu licence. Po skončení smlouvy se (s výjimkou smluv nájemních) pokračuje v dalším cyklu již jen platbou za Software Assurance. Operační systémy a serverové produkty koupené jako OEM lze do Software Assurance zahrnout nejpozději do 90 dnů od jejich nákupu [3]. Pokud má organizace platnou smlouvu Software Assurance, může v rámci VDI využívat následujících výhod: přístup k Windows 8 Enterprise, možnost přistupovat z licencovaného zařízení až ke čtyřem virtuálním počítačům (současně), roaming oprávnění pro přístup z nekorporátních zařízení, možnost využívat Windows Thin PC zdarma, možnost dokoupit MDOP (Microsoft Desktop Optimization Pack). Další možnosti Pokud organizace naopak nemá platnou smlouvu Software Assurance, musí využít jedné ze zbývajících možností. 7 Podrobnosti o multilicenčních smlouvách: http://www.daquas.cz/articles/246-typy-multilicencnichsmluv-microsoft.aspx 37
VDA licence je licencí placenou ročně za jedno zařízení, ze kterého se přistupuje k virtuálním počítačům. Velmi důležité je především zmíněné omezení na jedno zařízení! Znamená to, že pokud se rozhodneme licencovat VDI pomocí VDA licencí a uživatel používá pro přístup k virtuálnímu počítači soukromý notebook a soukromý tablet, je nezbytné koupit na 1 rok 2 licence VDA. V ostatních parametrech je licence shodná se Software Assurance. Podle mého názoru je nejméně známou možností licencování VDI Windows Intune. Windows Intune je cloudová služba pro pokročilou správu počítačů a dalších koncových zařízení, která však zároveň poskytuje stejná oprávnění a možnosti, jako Virtual Desktop Access licence. Je to tedy další funkční možnost licencování VDI. Poslední možnost nazvaná Companion Subscription License je zcela nová licence, která přišla s OS Windows 8. Tato licence je volitelnou rozšiřující licencí pro primární uživatele Software Assurance a poskytuje oprávnění přistupovat k virtuálnímu počítači ve VDI prostředí ze 4 zařízení. Tato mohou být soukromé notebooky, tablety či mobilní telefony s RDP aplikací. Zahrnuje Windows To Go a VDA licence. Její hlavní výhoda tkví v tom, že již není nutné kupovat pro každé zařízení zvlášť jednu VDA licenci, ale je možné je pokrýt touto jednou CSL licencí. CSL licence je automaticky součástí veškerých Windows RT zařízení! Velmi důležité je rovněž si uvědomit, že technologie VDI založená na platformě Microsoft rovněž využívá role Remote Desktop Services. Je proto nutné licencovat i toto pomocí tzv. RD CAL (Remote Desktop Client Access License). 2.4.2 Licencování Citrix VDI Citrix je v licencování velmi benevolentní z pohledu volby typu licencování. Nabízí totiž tři způsoby 8 licencování: Uživatelská licence vhodné pro přístup jednoho uživatele ke svému dedikovanému virtuálnímu počítači Licence zařízení vhodné pro licencování sdílených pracovních stanic a zařízení Licence konkurenčního přístupu vhodné pro anonymní přístup nebo příležitostný přístup 8 Přehled licencování: http://www.citrix.cz/products/xendesktop/how-it-works/licensing.html 38
XenDesktop je aktuálně nabízen ve třech verzích: Citrix XenDesktop 7.5, Platinum Edition Enterprise verze s podporou cloudu, HDX technologie a FlexiCast technologie, pokročilé možnosti správy, monitoringu a zabezpečení Citrix XenDesktop 7.5, Enterprise Edition Enterprise verze s podporou HDX technologie a FlexiCast technologie Citrix XenDesktop 7.5, VDI Edition VDI řešení pro poskytování virtuálních desktopů s podporou HDX technologie. Uživatelská licence umožňuje uživateli přistupovat k jeho virtuálnímu počítači a virtuálním aplikacím z libovolného počtu zařízení. Naproti tomu licence zařízení umožňuje přistupovat neomezenému počtu uživatelů ke svému virtuálnímu desktopu z jednoho konkrétního zařízení. Licencování konkurenčního přístupu nahlíží na uživatele jako na anonymní subjekt, který této licence využívá pouze v době, kdy přistupuje k jedné nebo více aplikacím nebo virtuálnímu desktopu. Jakmile se uživatel odpojí, je tato využívaná licence uvolněna zpět do poolu licencí a je k dispozici pro dalšího anonymního uživatele. Uživatelská licence nahlíží na uživatele jako na osobu, která je jasně definovaná pomocí jednoznačného identifikátoru, typicky pomocí účtu v Active Directory. Pokud jeden uživatelský účet využívá více uživatelů, je požadována licence pro každého z nich. Uživatel, který má platnou licenci je oprávněn přistupovat do VDI prostředí z jakéhokoliv zařízení, dokonce je i možné, aby různá uživatelova zařízení byla k VDI prostředí připojena zároveň. Důležité je, že v jednom prostředí je možné používat jak uživatelské licence, tak licence zařízení. Jednotlivé licence mohou být v případě ukončení pracovního poměru se zaměstnancem nebo vyřazení počítače odebírány (zrušení přiřazení). Stávají se tak opět dostupné pro další využití. 2.4.3 Licencování VMware VDI VMware Horizon View je možné koupit ve dvou verzích, které se liší pouze v poskytované technické podpoře. Verze Basic zahrnuje podporu 12 hodin denně v pracovních dnech, zatímco verze Production je rozšířena na podporu poskytovanou 24 hodin denně 7 dní v týdnu. U obou verzí platí, že je možné je koupit na 1 rok nebo 39
na 3 roky a vždy se jedná o balíček 10 uživatelských licencí. Pro 100 uživatelů to samozřejmě znamená nákup 10 balíčků. V čem se jednotliví výrobci často rozcházejí, je chápání potřebných počtů uživatelských licencí. VMware požaduje mít zakoupeno tolik licencí, kolik je aktivně připojených uživatelů, nikoliv kolik jich je celkem. V licenčním ujednání lze nalézt definici, že je možné provozovat libovolný takový počet hostů, který dokáže zajistit současné připojení tolika uživatelů, na kolik je nakoupeno licencí. Jedinou odlišností je zde tzv. Local Mode, který dokáže uživatelský virtuální počítač načíst do fyzického počítače a umožnit tak uživateli pracovat s virtuálním počítačem i v době, kdy nemá konektivitu do VMware Horizon prostředí. V takovém případě je třeba tento virtuální počítač brát v úvahu jako neustále aktivní připojení uživatele, z čehož vyplývá, že je potřeba jej do počtu licencí započítat, ať je zapnutý či nikoliv. Všechny licence VMware Horizon View obsahují vsphere Desktop, kterýžto funkcionalitou odpovídá vsphere Enterprise Plus. Je zde ovšem jedno zásadní omezení, a to na provozování pouze desktopových systémů. Ve vsphere Desktop se nesmí provozovat servery s výjimkou těch serverů, které slouží pro podporu a správu prostředí VMware Horizon View. Tím je umožněno zde provozovat servery pro View Manger, vcenter, případně další Connection Broker server pro zajištění vysoké dostupnosti, správu desktopů ale i například server monitorující celkové zatížení systému. Společnost VMware dále specifikuje podmínku, která vymezuje OS desktopového virtuálního počítače. Za desktopový počítač je považován pouze takový, který obsahuje některý z následujících OS: Windows 95/98 Windows 2000 Professional Windows XP Professional Windows Vista Ultimate, Business, Enterprise Windows 7 Windows 8 40
3 Plánování přechodu na virtuální prostření 3.1 Plánování rozpočtu a typické manipulace Součástí plánování přechodu na virtualizované prostředí je samozřejmě i kalkulace finanční stránky. Ta musí být racionální a vycházet z jasně definovaných parametrů. Bohužel realita je velmi často jiná a do výpočtů se zahrnují položky, které dávají smysl pouze z hlediska dosažení požadovaného výsledku finanční analýzy. Lze jednoznačně tvrdit, že pokud člověk zastupující dodavatele VDI řešení kalkuluje náklady potencionálního řešení, může kdykoliv a níže zmíněnými způsoby jakkoliv zkreslit výsledky tak, aby jeho řešení vycházelo výhodněji. Samozřejmě je to možné provádět i opačně, ale to lze očekávat spíše od zástupce klasické desktopové školy. Jak si nyní ukážeme, je to skutečně snadné, a to pomocí následujících bodů: zahrnutí soft costs přenesení skrytých nákladů tam, kde nejsou vidět zneužití neměřitelných dat odůvodnění úspor funkcionalitou, která nebude nikdy využita přizpůsobení si aktuálního stavu ignorování úsilí potřebného k implementaci zahrnutí úsilí potřebného k implementaci z high-end na low-end komplexita, která zaujme ignorování dat, která odporují požadovanému výsledku likvidace finančních modelů [4] Zahrnutí soft costs Soft costs představují nejjednodušší metodu, jak nasměrovat výsledky požadovaným směrem. Soft costs se zde rozumí náklady, které představují kvalitativní parametry vyjádřitelné peněžní hodnotou. Nejčastěji se jedná o efektivitu práce, spokojenost uživatelů atp. Reálně se lze dočíst o zcela nereálných nákladech. Jako příklad si můžeme uvést vypočítání nákladů na 1 hodinu, kdy uživatel není schopen v důsledku výpadku pracovat. Pokud takové náklady stanovíme například na 2000 Kč, definujeme, že VDI ušetří každému zaměstnanci pět hodin ročně, kde počet uživatelů je 200, tak dojdeme 41
k výsledku 2 000 000 Kč. Tyto náklady je samozřejmě možné rozšiřovat o daně, odvody, náklady navíc za správu atp. Ve skutečnosti jsou to virtuální náklady, které velmi snadno ovlivní požadovaný výsledek. Přenesení skrytých nákladů tam, kde nejsou vidět Další možnou metodou je přesouvání nákladů tam, kde nejsou tolik zřetelné. O VDI se mluví jako o řešení, které umožnuje pracovat odkudkoliv. Lze tak usuzovat, že pokud uživatelé nemusí být přítomní v prostorách firmy, dojde k úsporám za energie, chlazení, vodné, stočné a další, které si jistě snadno dovedete představit. Ve skutečnosti se náklady pouze přesouvají ze zaměstnavatele na zaměstnance, kteří z dlouhodobého hlediska pravděpodobně budou chtít kompenzaci. Zneužití neměřitelných dat Nezřídka kdy je jako klad VDI řešení uváděna energetická efektivnost. Vychází se z předpokladu používání tenkých klientů nebo zero klientů. Prvním nedostatkem v této kalkulaci je porovnávání spotřeby dle specifikací zařízení. Udávaná spotřeba je vždy maximální dosažitelný výkon zdroje na jeho výstupu, nikoliv příkon. V mém případě pracovní PC se zdrojem o výkonu 400W spotřebovává průměrně 100W. Běžné kancelářské stanice se pohybují kolem 65 W- 70 W spotřebované energie. Server, který mám k dispozici pro testování, odebírá přibližně 300 W (2x Intel Xeon 5148, 12 GB RAM, 8x HDD). Největší část spotřeby odebírá velmi pravděpodobně diskové pole. Při hlubším zamyšlení dojdeme k druhému nedostatku, kterým je nemožnost definovat spotřebu přesně. Výše zmiňovaná čísla platí aktuálně v době měření a nereflektují skutečnost, že spotřeba je velmi závislá na vytížení PC/serveru v čase. Teoreticky lze tuto hodnotu odhadovat u serverů, které lze monitorovat a které evidentně vykonávají činnost, která může být jasně daná a neměnná. I přesto se jedná pouze o odhad, který nezahrnuje to, jakým způsobem může kolísat využívání HW zdrojů v návaznosti například na velikost vstupních dat dané úlohy. Zjednodušeně řečeno server, který běžně spotřebovává 300W, může při vyšším požadavku na výkon zvýšit spotřebu k 500W a více. Příkladem budiž spotřeba souborového serveru při 42
spuštění zálohovací úlohy, nebo spotřeba mail serveru při hromadném odesílání vánočních přání. U uživatelských stanic nelze spotřebu predikovat téměř vůbec, protože chování uživatele a způsob jeho práce jsou velmi rozmanité. Odůvodňování úspor funkcionalitou, která nebude nikdy využita Při počítání modelů nákladovosti se lze snadno dopracovat k číslům, která nemusí být v souladu se záměrem prodat technologii. Bohužel je i velmi jednoduché dopracovat se v takovém případě čísel, která naopak záměr prodeje podpoří. Opět se může jednat o pokusy kvantifikovat penězi efektivitu uživatele, uživatelský komfort, ale dobře poslouží i tabulky specifikací jednotlivých virtualizačních serverů. Kalkulace úspory přenosové kapacity v důsledku volby optimalizovaného protokolu nedává smysl, pokud se jedná o implementaci na síti typu LAN, kalkulovat s maximálním počtem podporovaných fyzických procesorů nedává smysl, pokud nebudujete datové centrum. Přizpůsobení si aktuálního stavu Zde je potřeba si uvědomit, že při kalkulacích VDI projektu se jedná zásadně o porovnávání dvou stavů. Stavu před potencionálním VDI, tedy aktuálním stavu, a stavu po implementaci potencionálního VDI. Kalkulace pouze stavu po implementaci bez kontextu je sice přitažlivá myšlenka, neboť zobrazuje náklady řešeného projektu, ale bez kontextu současné situace je tato bezcenná. Dvě možné cesty manipulace se přímo nabízejí. Pokud za žádnou cenu nepodporujete VDI, bude kvantifikace současného stavu tento vyzdvihovat jako velmi úsporný a efektivní. Pokud naopak chcete dokázat, že VDI je ten opravdový zásah do černého, dokážete stejně tak kvantifikovat současný stav jako velmi nákladově náročný a neefektivní. Deset minut práce. Ignorování úsilí potřebného pro implementaci Častou chybou, avšak poměrně významnou, je opomíjení implementace nového VDI řešení. Kalkulovat je potřeba nejen s nakoupením potřebného HW vybavení, SW vybavení. Implementace nakoupeného HW a SW je ve většině případů tou jednodušší částí celého procesu. Po ní následují aktivity, které by se daly shrnout pod pojem integrace do firemního prostředí. Jedná se tedy o migraci uživatelů a jejich profilů, migraci zabezpečení, migraci dat včetně nastavených oprávnění. Velmi důležité je také pečlivě naplánovat, jak se budou virtualizovat aplikace. 43
Všechny tyto aktivity vyžadují nemalé úsilí za pomoci mnoha zdrojů a jejich ignorování může vést k velmi překvapivým výsledkům procesu migrace do virtuálního prostředí! Zahrnutí úsilí potřebného pro implementaci Tak jako lze opomenutím nákladů na proces implementace vyšvihnout projekt VDI, tak jej lze zdevastovat zahrnutím obrovských nákladů na implementaci. Z high-end na low-end Je potřeba si uvědomit, že úspory nákladů jsou v případě VDI spojeny s přechodem z velmi výkonných stanic, které dávají uživatelům vysoký výkon a pocit bezprostřední reakce uživatelského rozhraní, na sdílené prostředí s omezenými zdroji (v dalších částech se budeme zabývat proč je toto vhodné). Komplexita, která zaujme Často se můžeme potkávat s lidmi, kteří o určité problematice nevědí nic, ale přesto dokáží zaujmout především tím, že o ničem dokáží povídat všechno. Zkrátka nic neví, ale o všem mluví. To samé se snaží uplatnit i při tvorbě finančního modelu. Nečekejte proto jednoduchý pragmatický a možná nezáživný finanční model na pár řádkách. Místo toho dostanete gigantický prudce sofistikovaný model, který nikdo nechápe a někdo si může pomyslet, že takto propracovaný model musí být přece správně. Nakonec se s různými generátory finančních modelů a analyzátory finanční stránky VDI lze setkat na webových stránkách poskytovatelů VDI. Nutno podotknout, že tyto nástroje tvoří lidé zaměstnaní u poskytovatele VDI, výsledky mohou proto být předvídatelné. Ignorování dat, která odporují požadovanému výsledku Protože je IT velmi mladá disciplína a velmi komplexní, neexistují žádné normy či seznamy položek, které je nutné mít ve finanční analýze ICT společnosti zahrnuté. Je to logické, vzhledem ke zmiňované komplexnosti je jen velmi obtížné generalizovat jednu oblast a definovat funkční rámec pro finanční analýzy jedné oblasti. Důsledkem je fakt, že pokud prodejce z rozpočtu vypustí oblast, která se prostě nehodí, málokdo si toho 44
všimne. Finanční model Vás zároveň přesvědčí, že volba jakékoliv jiné VDI technologie je katastrofální. Likvidace finančních modelů Pokud se osoba vytvářející finanční model dostane do situace, ve které se rozhoduje o implementaci VDI řešení a vedení společnosti dostane jiný model, který vše ukazuje reálným pohledem na věc, jednoduše tato osoba přijde s tvrzením, že finanční modely jsou nesmysl s odkazem na výše zmiňované body. 3.2 Odhad pracnosti přípravy VDI prostředí Odhad pracnosti zakládám na svém reálném testování nasazení jednotlivých řešení (Microsoft, VMware, Citrix), kdy jsem vždy vyzkoušel celý proces od instalace hypervisoru až po finální nasazení a převedení do plně funkčního stavu. Testování jsem prováděl na již funkční LAN, a proto jsou mé odhady oproštěné od pracnosti pro přípravu a konfiguraci samotné LAN. Je vhodné si uvědomit, že VDI je prostředí pro poskytování virtuálních desktopů, tedy desktopových OS. Z toho vyplývá jedna velmi důležitá informace, a to že během implementace budeme potřebovat připravený vzorový operační systém, tzv. Master Image. Těchto vzorových OS je samozřejmě možné použít více, záleží pouze na požadavcích a potřebách organizace. 3.2.1 Odhad pracnosti nasazení Microsoft VDI Tabulka 1 - Odhad pracnosti nasazení Microsoft VDI Instalace hypervisoru 1,0 MD Instalace role Remote Desktop Services včetně role Hyper-V 0,5 MD Konfigurace VDI (kolekce virtuálních desktopů, konfigurace uživatelských práv) 2,0 MD Příprava Master Image 1,0 MD Celkem 4,5 MD Zdroj: Vlastní zpracování 45
3.2.2 Odhad pracnosti nasazení Citrix VDI Tabulka 2 - Odhad pracnosti nasazení Citrix VDI Instalace Hypervisoru 0,5 MD Instalace Windows Server 2008 R2 1,0 MD Instalace a konfigurace XenDesktop (kolekce virtuálních desktopů, konfigurace uživatelských práv) 1,0 MD Příprava Master Image 1,0 MD Celkem 3,5 MD Zdroj: Vlastní zpracování 3.2.3 Odhad pracnosti nasazení VMware VDI Tabulka 3 - Odhad pracnosti nasazení VMware VDI Instalace Hypervisoru 0,5 MD Instalace Windows Server 2008 R2 1,0 MD Instalace a konfigurace VMware Horizon View (kolekce virtuálních desktopů, konfigurace uživatelských práv) 1,0 MD Příprava Master Image 1,0 MD Celkem 3,5 MD Zdroj: Vlastní zpracování 3.2.4 Shrnutí odhadu pracnosti Z uvedených tabulek je zřejmé, že pracnost na všech řešeních je velmi podobná, jedině implementace řešení od Microsoft je časově náročnější. Důvod tkví především v tom, že instalace Hyper-V formou role Windows Serveru obnáší kompletní instalaci OS Windows Server a ačkoliv jsem vždy používal nejnovější instalační zdroje dostupné na MSDN, bylo nutné nainstalovat i značné množství bezpečnostních aktualizací a ostatních komponent (například.net Framework, SQL Server). Proti instalaci čistých hypervisorů od Citrix nebo VMware je tento proces výrazně časově náročnější. Obrázek 20 - Instalace VDI na Windows Serveru 2012 R2 Windows Server 2012 R2 role Remote Desktop Services (zahrnuje roli Hyper-V) Windows Server 2012 R2 (Parent Partition) Virtualizační vrstva VMs Hardware Hardware Zdroj: Vlastní zpracování 46
Obrázek 21 - Instalace VDI na ostatních platformách Windows Server 2008R2 VMware ESXi / Citrix XenServer Hardware VMs Zdroj: Vlastní zpracování Microsoft mimo jiné poskytuje také produkt Microsoft Hyper-V Server, který je svým charakterem velmi podobný zmiňovaným hypervisorům konkurence a jeho instalace je poté stejně nenáročná, ale tento způsob nasazení nedoporučuji ze dvou důvodů. První důvod je licenční, protože Windows Server Datacenter edice poskytuje neomezené množství virtuálních kopií, což je velmi vhodné pro nasazení nástrojů pro správu VDI a dalších pomocných serverů. Druhý důvod je doporučení provozovat nástroje pro správu VDI na dedikovaném virtuálním serveru. Časová náročnost bude tedy dokonce vyšší a zároveň společnost přijde o neomezené množství licencí na virtuální kopie. Z uvedených výsledků také vyplývá, že nejvíce časově náročné je vytvoření Master Image pro tvorbu kolekcí virtuálních desktopů. Doporučuji proto mít tyto Master Image připravené dopředu a zbytečně se nezdržovat jejich tvorbou při konfiguraci VDI prostředí. Lze tím velmi snadno zkrátit náročnost implementace o 1 MD! Pokud společnost používá prostředí Windows Server, je optimální využít službu Windows Deployment Services (WDS). Windows Deployment Services (WDS) umožňuje nasazení operačních systémů Windows prostřednictvím sítě, což znamená, že není třeba instalovat každý operační systém přímo z disku CD nebo DVD [5]. Podstatné pro naše potřeby je možnost vytvářet bitové kopie referenčních počítačů a přidávat balíčky ovladačů. Vzorový virtuální počítač je vždy potřeba mít nainstalovaný ve virtualizačním prostředí a jeho instalace z WDS je otázkou přibližně 20 minut. Tímto bych rád apeloval i na možnost zvážení použití WDS jakožto nástroje pro zefektivnění IT procesů. WDS je součástí každého OS Windows Server a společně se sadou nástrojů Windows Assessment and Deployment Kit (WAIK) umožňuje proces instalace klientských počítačů zcela automatizovat, včetně převedení uživatelského profilu. 47
Zvažuje-li firma nasazení VDI mimo jiné kvůli dlouhé době obnovy uživatelské stanice do funkčního stavu, je toto alternativní řešení číslem jedna. 3.3 Proces přechodu na VDI Proces přechodu na VDI je podle mého názoru jedním z nejvíce rozhodujících faktorů přechodu společnosti na tento moderní způsob poskytování virtuálních koncových stanic. Definovat jeden správný postup/proces je ale samozřejmě nemožné, vždy bude záležet na konkrétní situaci a technologickém vývoji nejen v oblasti VDI. Obecně lze ale přechod na VDI vnímat ve dvou fázích. 3.3.1 Identifikace potřeb a analýza možností Základním stavebním kamenem je identifikace jakési neefektivnosti IT/ICT procesů ve společnosti. Tyto neefektivnosti je potřeba správně identifikovat a racionálně ohodnotit, protože z nich vyplývají požadavky, které musí VDI řešení splnit. Jak jsem již v úvodu své práce zmiňoval, je v současnosti trendem mladého managementu společnosti uchylovat se k řešením na první pohled jednoduchým, což ne vždy musí být správné. Proto v procesu identifikace potřeb a analýza možností uvádím podle mého názoru důležitý bod, a to identifikování alternativních způsobů pro řešení neefektivní oblasti IT. Má profesní zkušenost často ukazuje, že největším problémem může ve skutečnosti být neznalost či neochota IT profesionálů společnosti, především ve smyslu využívání plného potencionálu, který současná infrastruktura poskytuje. Vizte zmiňovaný deployment pomocí WDS, WAIK a další postupy pro automatizaci infrastruktury (PowerShell, Group Policies, atp.). 48
Obrázek 22 - Obecný proces identifikace potřeb a analýza možných řešení Zdroj: Vlastní zpracování 49
3.3.2 Nasazení vybraného řešení Zde uvádím proces nasazení vybraného prostředí do infrastruktury společnosti, který je v podstatě shodný pro všechna testovaná VDI řešení. Slouží proto pouze pro ilustraci sledu obvyklých činností a vytvoření představy o časovém sledu událostí. Během mého testování se mi velmi vyplatilo připravit si Master Image všech OS, které jsou potřeba pro provoz VDI infrastruktury formou virtuálních desktopů potřebné. Instalaci jakéhokoliv OS včetně aktualizací a potřebných SW nástrojů jsem byl schopný zkrátit přibližně na 1 hodinu. Ačkoliv logicky činnost vytváření Master Image zapadá mezi činnosti instalace VDI prostředí a Vytváření kolekce virtuálních počítačů, doporučuji, pokud je znám cílový OS, připravit si tyto Master Image dopředu, pokud již nejsou využívány. Obrázek 23 - Proces nasazení vybraného řešení Zdroj: Vlastní zpracování 50
3.4 Oblasti dotčené přechodem na VDI Z manažerského úhlu pohledu je přechod na virtualizaci koncových stanic velmi efektivní řešení, které umožní provozovat flexibilní IT procesy ve společnosti. S efektivitou je samozřejmě spjata vidina úspor především finančních. V tomto případě potom úspor energetických, snížení nákladů na HW, snížení nákladů na personál. Je ale obtížné hodnotit danou problematiku takto obecně a bez znalosti dalších podrobností o fungování společnosti. Samotný přechod na VDI potom nesporně zasáhne následující oblasti společnosti: IT podpora společnosti Přechod na virtualizaci koncových stanic znamená zásah do způsobu, jakým je celá infrastruktura spravována. Zda je tento zásah drastický či pouze zanedbatelný, to záleží na konkrétní implementaci. Obecně lze ale tvrdit, že znalostní nároky na správu infrastruktury značně vzrostou. Obrázek 24 - Nárok na znalosti IT zaměstnanců Zdroj: Vlastní zpracování Licencování SW Virtualizace koncových stanic ve své podstatě předpokládá využívání některého z multilicenčních plánů společností Microsoft. VDI bez multilicenčního plánu postrádá efektivitu ze dvou důvodů. Prvním je nemožnost používat Enterprise verzi OS Windows a druhým je nemožnost rychlého nasazování virtuálních pracovních stanic ba dokonce poskytování virtuálních koncových stanic na vyžádání. 51
Obrázek 25 -Nový systém licencování Zdroj: Vlastní zpracování Skladování dat K virtualizaci koncových stanic neodmyslitelně patří sdílené datové pole typu SAN, které dokáže poskytnout dostatečný výkon především v oblasti vstupně výstupních (I/O) operací. Je potřeba si uvědomit, že zatímco v tradičním nasazení pevných uživatelských počítačů využívá každý uživatel diskových operací na svém vlastním disku, v případě VDI musí diskové pole obsloužit diskové operace všech uživatelů. Obrázek 26 - Vysoké požadavky na datová pole Zdroj: Vlastní zpracování Zálohování, disaster recovery VDI znamená nové postupy zálohování dat, a to nejenom z pohledu nutnosti zálohovat pole typu SAN, ale i z pohledu práce s uživatelskými daty, které mohou být v některých způsobech implementace VDI ukládána odlišně (například na personálním pevném disku v případě dynamického přidělování volných virtuálních počítačů). S tímto úzce 52
souvisí i zásah do disaster recovery plánů, které musí mapovat nové postupy a lze očekávat, že povedou ke zkrácení výpadků. Obrázek 27 - Nový přístup k zálohování Zdroj: Vlastní zpracování Uživatelská oprávnění Je možné, že v některých oborech nebo specifických společnostech, jsou uživatelům ponechána oprávnění lokálního administrátora. S příchodem VDI toto nemusí být žádoucí, a to především v případě dynamického přidělování virtuálních počítačů (tzv. přidělování z poolu), nebo dokonce naprosto nepřípustné v případě využívání terminálových služeb jakožto formy VDI. Obrázek 28 - Dopadem restrikce uživatelských oprávnění je naštvaný uživatel Zdroj: Vlastní zpracování Zmiňované oblasti se samozřejmě projevují i v následující kapitole a rizicích přechodu na VDI. 3.5 Rizika spojená s přechodem na VDI Přechod na VDI infrastrukturu má charakter projektu a tak jako každý projekt, i tento svá rizika. Níže popisuji dle mého názoru ty nejčastější. 53
Nepochopení licenční politiky MS Licenční politika společnosti Microsoft je velmi složitá, což dobře vystihuje axiom Pokud budete o licencích mluvit s deseti lidmi z Microsoftu, dostanete 11 odlišných odpovědí [4]. Je proto nezbytné licenční politiku dobře nastudovat a dojít k jejímu pochopení. Velmi často se při plánování zanedbává licencování kancelářských aplikací, což může vést k drastickému růstu nákladů. Kancelářská sada MS Office je licencovaná podle počtu zařízení, která se používají pro přístup k MS Office. Zjednodušeně to znamená, že jeden uživatel, který přistupuje ke svému virtuálnímu počítači z pracovní stanice a z domácího notebooku, potřebuje dvě licence MS Office! Nedostatečné znalosti pro správné nasazení VDI VDI je velmi složitá oblast, protože kromě klasických znalostí desktopové infrastruktury je potřeba ovládat mnoho dalších oblastí. Pravděpodobně budou potřeba další expertní znalosti serverové infrastruktury, datových úložišť, VPN, tenkých klientů a další. Navrhovat VDI infrastrukturu pouze na domněnce výborných znalostí virtualizace je proto nedostatečné a nelze to doporučit. Obrázek 29 - Zvýšení nároku na znalosti IT Vysoká dostupnost Datová pole Aplikační servery Webové servery Desktop Databáze Zálohování Zdroj: Vlastní zpracování Špatný návrh datových polí Návrh datového úložiště je jedna z nejvíce kritických oblastí celého projektu. Existují dvě možnosti, jak s daty pracovat. Tou první je použití persistentních disků pro každý virtuální počítač. To znamená, že každý uživatel má na svém virtuálním počítači vyhra- 54
zený virtuální disk. To může být výhodné z hlediska přizpůsobení a uložení uživatelských dat, ale na druhou stranu to v podstatě nepřináší mnoho změn oproti tradičním fyzickým desktopům. Opět je zde potřeba spravovat každý zvlášť. Druhou možností je použití sdíleného master disku. Ten je sdílený pro všechny virtuální počítače (nebo pro zvolenou skupinu virtuálních počítačů), což vede k usnadnění správy. Stačí spravovat jeden jediný master disk a změny budou platné pro všechny virtuální počítače. Pracuje se zde také s myšlenkou umístění tohoto sdíleného disku na rychlé diskové pole, případně na SSD diskové pole a to pro zajištění vysokého výkonu celého prostředí. Problém nastává v situaci, kdy si uvědomíme, že jeden disk nemůže být sdílený pro více počítačů najednou. Ve skutečnosti je sdílený master image pouze pro čtení, což zjednodušeně znamená, že jakékoliv změny uživatel provede, je potřeba je zapisovat jinam. Zapisují se na tzv. delta disky, které obsahují změny a data vygenerované uživatelem. Na první pohled je patrné, že s přibývajícími změnami se instance virtuálního počítače přesouvá více na delta disky. Obrázek 30 - Problém sdílení master image v rámci VDI čtení Sdílený master image Cache / SSD Rychlé pole Desktop zápis změn čtení změn Čtení/zápis Delta disk Zdroj: Vlastní zpracování Příliš mnoho změn pro uživatele Uživatel si s sebou často nese různé pracovní zvyky a návyky a je často náchylný i na drobné změny pracovního prostředí. To je riziko z hlediska loajálního přístupu k zaměstnancům, ale může se jednat i o zásah do produktivity společnosti. Uživatel, který není schopný se sžít s novým prostředím a práce je pro něj dokonce obtížná, pracuje s menší efektivitou. Je proto obecně vhodnější přistupovat ke změnám s rozvahou, 55
dělat je postupně. Zásadní zásah může být například přechod na VDI se sdíleným standardizovaným obrazem virtuálního OS (tj. pevně dané prostředí, často automaticky generované podle obrazu OS sloužícího jako šablona). Menší dopady bude mít tento proces rozdělený na oddělené fáze. Je tedy možné nejprve nasadit sdílený obraz OS a po určité době přesunout uživatele do prostředí VDI. Nasazení sdíleného obrazu OS je v prostředí Windows možné díky technologii Windows Deployment Service (WDS), která je součástí OS Windows Server. Podobně jako Hyper-V či Remote Desktop Service, i tato se instaluje jako role. Podle mého názoru je WDS a obecně automatizace IT infrastruktury řešení, které může řešit veškeré problémy, díky kterým firma zvažuje zavedení VDI. Společnost Microsoft má pro tuto oblast dostatečně efektivní a robustní nástroje, které mohou firemní IT zefektivnit bez znatelných nákladů. Princip je velmi podobný VDI. Tuto myšlenku mohu podpořit osobní zkušeností z mnoha společností, které možnost automatizace mnoha IT procesů buď ignorují, nebo o jejich možnosti nevědí. Druhým a stejně tak nepříjemným důsledkem příliš agilního postupu je obecná nespokojenost uživatelů, díky čemuž může dojít k nabytí dojmu, že projekt byl neúspěšný! Obrázek 31 - Příliš mnoho změn předjímá problém User Nový OS Master image Omezená oprávnění Problem Zdroj: Vlastní zpracování Staré zvyky v novém prostředí Stejně jako uživatel má své zvyky, tak je může mít i administrátor. Některé z nich jsou ale pro VDI nevhodné a je lepší na ně zapomenout. Jedním z nich může být naplánované spuštění antivirové kontroly na všech stanicích, které by pravděpodobně vyprovodilo datové pole stropem ven z místnosti. 56
4 Ekonomická analýza virtualizace koncových stanic Ekonomické hledisko virtualizace koncových stanic je jeden z hlavních motivátorů přechodu na toto řešení. Na jednu stranu je zde lákavá úspora za koncové stanice, na druhou stranu jsou tu náklady na novou infrastrukturu, která musí zajišťovat vysokou dostupnost služeb. Změna financování je oproti tradičnímu modelu koncových stanic obrovská a její hodnocení je proto optimální na základě TCO (Total Costs of Ownership). Tyto náklady se skládají z nákladů na licence, nákladů na správu koncových stanic (bodů), nákladů na správu serverů, nákladů na energie atd. Porovnání proto provedu na jednotlivých bodech TCO, protože pokládám taková data za jasně prokazatelná a pro společnost, která se potřebuje zorientovat v dané problematice, jednodušší pro čtení. Obrázek 32 - High Level pohled na TCO Zdroj: Vlastní zpracování 57
4.1 Předpoklady Firma Blue Offices má 150 zaměstnanců s tradičními desktopy (40%) nebo notebooky (60%). S firmou dále spolupracuje 25 externích spolupracovníků, kteří také potřebují přistupovat do infrastruktury. Z celkových 175 uživatelů jich 40 hodlá používat další koncová zařízení (mobilní telefony, tablety) pro přístup do prostředí VDI. 30 uživatelů použije maximálně jedno další koncové zařízení, 10 uživatelů použije dvě další koncová zařízení. Obrázek 33 - Znázornění řešené organizace Zdroj: Vlastní zpracování Všechny počítače společnosti mají nainstalovaný OS Windows 7 Professional. Vzhledem k tomu, že společnost aktuálně již používá Windows Server 2008 R2 Standard a službu Active Directory, má pro každého uživatele koupenou uživatelskou licenci User CAL. Společnost rovněž provozuje vlastní MS Exchange Server, ale to není v naší analýze důležité. 58
4.2 Náklady na HW pro VDI 4.2.1 Serverová infrastruktura Pro účely dimenzování hw konfigurace serveru se mi osvědčil nástroj VDI Calculator od autora Andrei Lebovice 9. Tento nástroj umožňuje velmi snadnou cestou definovat představu o VDI infrastruktuře a vypočítá přibližnou konfiguraci, která bude pro běh virtuálních desktopů potřebná. Autor nabízí i přehlednou dokumentaci, kde lze vyčíst doporučené parametry, u kterých si není člověk zcela jistý. Obrázek 34 - Přehled nastavených parametrů nástroje VDI Calculator Zdroj: Vlastní zpracování (snímek obrazovky z nástroje VDI Calculator) Na základě tohoto nástroje jsem pro zamýšlené VDI prostředí vypočítal následující požadované parametry: 9 Webový portál produktu: http://myvirtualcloud.net/?page_id=1076 59