Počítačová učebna v cloud computing

Bankovní institut vysoká škola Praha Katedra matematiky, statistiky a informačních technologií

Počítačová učebna v cloud computing

Diplomová práce

Autor:

Bc. Pavel Klápště Informační technologie a management

Vedoucí práce:

Ing. Vladimír Beneš

Praha

Duben 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 Jablonci nad Nisou, dne 24. 4. 2012

Pavel Klápště

Poděkování: Tímto bych chtěl poděkovat vedoucímu své diplomové práce Ing. Vladimíru Benešovi za konzultace a čas, který mi věnoval.

Anotace Cílem této práce je otestovat a navrhnout virtuální infrastrukturu pro provoz počítačové učebny v cloud computingu. Klíčová slova: virtualizace, cloud, VMware VDI, VMware View, Microsoft Hyper-V Annotation The goal of this thesis is to test and design virtual infrastructure for running computer classroom in the cloud computing. Key words: virtualization, cloud, VMware VDI, VMware View, Microsoft Hyper-V

Obsah 1

Popis virtualizace................................................................................................................ 9 1.1

1.1.1

Klasické desktopy s administrátorským přístupem .............................................. 9

1.1.2

Klasické desktopy bez administrátorských oprávnění........................................ 10

1.1.3

Klasické desktopy v síti Active Directory .......................................................... 11

1.1.4

Klonované obrazy ............................................................................................... 12

1.1.5

Bootování za sítě ................................................................................................ 14

1.2

2

Současná pouţívaná řešení .......................................................................................... 9

Řešení pomocí virtualizace ........................................................................................ 14

1.2.1

Webové aplikace................................................................................................. 15

1.2.2

Virtualizace......................................................................................................... 17

1.2.3

Microsoft Hyper-V ............................................................................................. 19

1.2.4

Remote Desktop Services ................................................................................... 21

1.2.5

VMware vShpere a View ................................................................................... 24

Analýza potřeb a poţadavků............................................................................................. 29 2.1

Cíle výsledného řešení ............................................................................................... 29

2.2

Výběr technologií ...................................................................................................... 33

2.2.1

Virtuální aplikace ............................................................................................... 33

2.2.2

Terminálový přístup ........................................................................................... 33

2.2.3

Virtuální desktopy .............................................................................................. 34

5

2.3

Obecný návrh řešení .................................................................................................. 34

2.4

Plánované testy .......................................................................................................... 35

2.4.1 3

Návrh řešení pomocí Microsoft Hyper-V......................................................................... 37 3.1

Remote Desktop Session Host ................................................................................... 37

3.1.1

Příprava prostředí ............................................................................................... 38

3.1.2

Průběh testů ........................................................................................................ 47

3.1.3

Vzniklé problémy ............................................................................................... 51

3.1.4

Hodnocení uţivatelů ........................................................................................... 52

3.1.5

Vyhodnocení....................................................................................................... 54

3.2

4

Testovací prostředí: ............................................................................................ 35

Remote Desktop Virtualization Host ......................................................................... 54

3.2.1

Průběh testu ........................................................................................................ 54

3.2.2

Vzniklé problémy ............................................................................................... 58

3.2.3

Hodnocení uţivatelů ........................................................................................... 58

3.2.4

Vyhodnocení....................................................................................................... 59

Návrh řešení pomocí VMware VDI ................................................................................. 60 4.1

VMware VDI ............................................................................................................. 60

4.1.1

Příprava prostředí ............................................................................................... 61

4.1.2

Průběh testu ........................................................................................................ 66

4.1.3

Vzniklé problémy ............................................................................................... 69

4.1.4

Hodnocení uţivatelů ........................................................................................... 69 6

4.1.5 5

Vyhodnocení....................................................................................................... 70

Srovnání obou řešení ........................................................................................................ 71 5.1

Microsoft .................................................................................................................... 71

5.2

VMware ..................................................................................................................... 72

7

Úvod Správa pracovních stanic je velmi náročná činnost, která vyţaduje velké mnoţství času od jednotlivých administrátorů a zároveň nemalé finanční investice do různých konfiguračních nástrojů. V této práci se budu zabývat popisem současně pouţívaných přístupů ke správě, jejich vlastnostmi a nevýhodami. Následně navrhnu jejich transformaci do moderního způsobu správy pomocí virtualizačních nástrojů a dva nejrozšířenější virtualizační nástroje porovnám. Jedná se o nástroje z rodiny Microsoft Remote Desktop a VMware VDI. Zaměřím se na jejich funkcionalitu a práci přes pomalé internetové připojení. Práce bude primárně vycházet z optimalizace počítačové učebny s pracovními stanicemi s nainstalovaným operačním systémem Microsoft Windows 7, nicméně uvedené postupy a zjištění se dají po adekvátních úpravách aplikovat na libovolnou počítačovou síť vybavenou pracovními stanicemi s operačním systémem na platformě Windows. Cílem práce bude tedy volba vhodné infrastruktury pro provoz počítačové učebny a její otevřenost pro další rozšiřování v případě potřeby.

8

1 Popis virtualizace 1.1 Současná používaná řešení V dnešní době se dají pouţívaná řešení rozdělit do dvou základních kategorií a to dle toho, na kterém místě se odehrává produktivní činnost uţivatele. Nejběţnější je vyuţívání klasických pracovních stanic, na kterých má uţivatel nainstalovány všechny potřebné aplikace, se kterými pracuje. Druhou kategorií je pouţívání tenkých klientů. Uţivatel má své pracoviště vybaveno zařízením, které mu pouze zprostředkuje připojení na server v datovém centu. Teprve tam je instalován operační systém a potřebné aplikace. Tenký klient tak do datového centra přenáší jednotlivé vstupy od uţivatele a zpátky k uţivateli přenáší obrazová data, případně zvuk a další výstupy. Podobným případem je například práce s webovou aplikací, kdy na straně uţivatele je potřeba pouze jednoduché zařízení schopné pracovat s HTML dokumenty a zbytek produktivní činnosti uţivatel vykonává na straně serveru. V následující části práce nejdříve přiblíţí nejběţnější způsoby práce a správy sítě s vyuţitím klasických pracovních stanic a následně se zaměří na přesun produkční činnosti mimo pracovní stanice.

1.1.1 Klasické desktopy s administrátorským přístupem Nejjednodušší způsob vytvoření sítě je propojení několika standardně nainstalovaných pracovních stanic pomocí vhodně nakonfigurovaného TCP/IP protokolu. V této konfiguraci má kaţdý uţivatel plné oprávnění k celému operačnímu systému, můţe si dle libosti instalovat různé programy a provádět změny v systému. Plné oprávnění k operačnímu systému můţe být v jistých případech výhodou, případně i nutností, většinou je ovšem neţádoucí. Toto řešení nemá ţádnou centrální správu systémů, ani jednotlivých uţivatelů a jejich oprávnění. Je proto zcela nevhodné k nasazení ve větší síti. V malých sítích bez administrátora se ale s tímto řešením lze často setkat, neboť se jedná o ţivelně tvořenou síť jednotlivými uţivateli, případně majitelem nebo provozovatelem. V případě poškození operačního systému je jeho obnova velmi sloţitá. Musí dojít k odzálohování veškerých uţivatelských dat a následné reinstalaci Windows, ovladačů a všech aplikací následovanou 9

jejich konfigurací. Tuto činnost zpravidla nevykonává přímo uţivatel, ale placená externí firma formou outsourcingu. Výhody -

Minimální nároky na prvotní konfiguraci.

-

Nulové náklady na software pro správu.

-

Plná kontrola nad operačním systémem.

Nevýhody -

Ţádná centrální správa.

-

Nemoţnost řídit oprávnění.

-

Sloţité zálohování.

-

Sloţitá obnova.

-

Plná kontrola nad operačním systémem.

1.1.2 Klasické desktopy bez administrátorských oprávnění Jedná se o velmi podobný případ jako předchozí. V tomto případě však existuje centrální autorita, která na jednotlivých stanicích definuje uţivatele a nastavuje jim potřebná oprávnění. Danou autoritou je zpravidla správce, učitel, nebo provozovatel. Při správné konfiguraci je podstatnou výhodou tohoto řešení, ţe daný uţivatel má přístup pouze k těm částem operačního systému a aplikacím, které pro svoji práci vyţaduje. Tím se do značné míry eliminuje riziko poškození konfigurace aplikace nebo celého operačního systému neodborným zásahem nebo chybou uţivatele. Značnou nevýhodou je nutnost manuální správy uţivatelských účtů, a aplikací na jednotlivých pracovních stanicích. Výhody -

Sníţení rizika poškození systému nebo aplikace uţivatelem.

Nevýhody -

Manuální správa uţivatelů.

-

Manuální správa aplikací. 10

Ostatní výhody a nevýhody jsou shodné s předchozím řešením.

1.1.3 Klasické desktopy v síti Active Directory Centralizované řešení pomocí Microsoft Active Directory je v dnešní době nejběţnější způsob správy koncových stanic a všeobecně celé ICT infrastruktury. Microsoft Active Directory představuje adresářovou sluţbu, která slouţí jako centrální místo pro ukládání konfigurací o sítí, stanicích, uţivatelích, zabezpečení atd. Zodpovídá za autentizaci a autorizaci uţivatelů i stanic, přiřazování a vynucování bezpečnostních politik pro všechny stanice v síti. Dále má na starosti instalaci a aktualizaci softwaru na jednotlivé stanice. Active Directory je zaloţená na protokolech Lightweight Directory Access Protocol (LDAP), Kerberos, NT LAN Manager (NTLM) a Domain Name System (DNS). Její databáze je postavena na technologii JET a skládá se z několika částí: Objekty -

Síťový objekt je cokoliv co má asociaci s počítačovou sítí, jako například uţivatel, stanice, skupina, tiskárna, aplikace, bezpečnostní politika atd. Objekty mohou obsahovat další vnořené objekty ve své struktuře. Kaţdý objekt je jednoznačně identifikován svým identifikátorem, a obsahuje určité atributy, které jsou dány schématem.

Schéma -

Popisuje atributy, vlastnosti a chování kaţdého objektu.

Servery na kterých je provozována role Active Directory se nazývají doménové řadiče. Celkový popis funkčnosti Active Directory je nad rámec této práce, nicméně v dalších částech budu vţdy předpokládat plně funkční Actice Directory infrastrukturu, nezbytnou pro provoz veškerých dále zmiňovaných systémů. Active Directory tedy představuje mocný nástroj pro celkovou správu pracovních stanic a uţivatelů z jednoho místa. Její výhodou je poměrně snadná základní obsluha a přitom značné moţnosti pokročilé konfigurace celé infrastruktury. Nevýhodou je nutnost její prvotní 11

instalace a konfigurace a potřeba provozu a správy serverového operačního systému Windows. Dále je zde nutnost pořizování vyšších verzí operačních systémů na stanice, které musí podporovat začlenění do Active Directory domény Výhody -

Sníţení nároků na správu sítě.

-

Zjednodušení správy identit.

-

Detailní nastavení bezpečnosti.

-

Moţnost hromadné instalace a konfigurace aplikací.

Nevýhody -

Nutnost provozovat server.

-

Sloţitější prvotní konfigurace.

-

Nutnost provozovat vyšší verze desktopových operačních systémů.

1.1.4 Klonované obrazy Instalace operačního systému a dalších aplikací se ve větších sítích zpravidla provádí pomocí předpřipravených obrazů. Tento přístup můţe mít dvě různé formy: 1) Jeden obraz pro všechny stanice V tomto případě administrátor nainstaluje operační systém a všechny potřebné aplikace na jednu vzorovou pracovní stanici. Tuto stanici a aplikace nakonfiguruje dle potřeb a následně provede její přípravu na distribuci pomocí nástroje sysprep. Nástroj sysprep se mimo jiné postará o změnu identifikátoru a o vynucení detekce nového hardware při následném spuštění. Z takto připravené stanice administrátor vytvoří obraz pro distribuci na ostatní počítače. Pro tento krok existuje velké mnoţství různých aplikací jak od společnosti Microsoft, tak dalších firem. Následně se tento obraz rozkopíruje na všechny stanice. Po jeho úspěšném spuštění se pracovní stanice začlení do domény Active Directory, ze které si stáhne podrobnou konfiguraci a aplikuje ji do svého nastavení. Výhodou tohoto přístupu je snadná obnova pracovní 12

stanice po selhání operačního systému nebo hardware. Nevýhodu představuje sloţitější příprava základního obrazu a nutnost rozsáhlých konfigurací za pomoci Active Directory. 2) Záložní obraz pro každou stanici Pokud se jednotlivé stanice do značné míry liší svojí konfigurací, nebo je potřeba obnovu provádět velmi často, můţe být vhodné zvolit metodu s obnovovacím obrazem pro

kaţdou stanici. Tento

způsob

se často

vyuţívá

například

právě

v

počítačových učebnách nebo internetových kavárnách, kde se předpokládá časté poškození operačního systému. V tomto případě administrátor instaluje operační systém a aplikace na kaţdý počítač zvlášť, případně pomocí vytvořeného obrazu jako v bodě 1. Následně z nakonfigurované stanice opět vytvoří obraz, který je moţné uloţit i na separátní oddíl pevného disku dané stanice. V případě problémů nebo v rámci pravidelné údrţby se stanice pouze restartuje s volbou obnovy celého systému a tím se dostane do stejného stavu, v jakém byla po instalaci. Výhodou tohoto přístupu je rychlá a snadná obnova, díky čemuţ je moţné uţivatelům zpřístupnit i administrátorská oprávnění na celý operační systém. Nevýhoda spočívá ve sloţitější správě celé sítě, neboť jakákoliv změna v konfiguraci, nebo aktualizace si vyţádá nové vytvoření všech obrazů na jednotlivých stanicích. Tyto dva přístupy jsou v současnosti nejrozšířenější a zpravidla se vhodně kombinují. Pro produkční stanice (například pro lektory) se pouţívá instalace z jednoho obrazu, protoţe se nepředpokládá jeho častá obnova. Pro studentské pracovní stanice se naopak vyuţívá záloţní klon uloţený na disku, neboť pravděpodobnost poškození instalace jejich operačního systému nebo instalovaných aplikací je značná. Výhody -

Snadná obnova poškozené stanice.

-

Moţnost naplánování automatické obnovy.

Nevýhody -

Sloţitější příprava základního obrazu. 13

-

Náročná další správa v případě změny nastavení nebo aktualizací.

1.1.5 Bootování za sítě Bezdiskové pracovní stanice postavené na systému Windows, které svůj operační systém načítají ze sítě, se v dnešní době příliš často nevyuţívají. Jedním z problémů je velikost celého systému, a tím i doba spouštění. Dalším problémem je například jeho nutné přizpůsobení danému uţivateli. Bootování ze sítě se ovšem často pouţívá v kombinaci s obnovou stanice pomocí instalačního obrazu. V případě selhání operačního systému na pevném disku se stanice restartuje s volbou zavedení operačního systému ze sítě. Místo plnohodnotného systému se ovšem spustí jeho upravená minimalizovaná verze s nainstalovaným nástrojem pro obnovu obrazu stanice. Dle konkrétního nastavení prostředí je moţné na stanici aplikovat buďto původní instalační obraz, nebo obraz, který byl vytvořen poslední pravidelnou zálohou. Výhody -

Moţnost rychlé bezzásahové obnovy celého operačního systému.

Nevýhody -

Sloţitější konfigurace sítě.

1.2 Řešení pomocí virtualizace V předchozí části uţivatel vţdy prováděl produktivní činnost na své pracovní stanici. Její výpadek tedy znamenal značné komplikace. Oprava pracovní stanice trvala od nepřijatelných několika dní nebo i týdnů při klasických desktopech, aţ po několik desítek minut v případě obnovy pomocí bootování ze sítě. Abychom těmto komplikacím zabránili, je nutné oprostit se od práce s aplikacemi pro produktivní činnost na konkrétních fyzických pracovních stanicích a přesunout ji do datových center.

14

Přesunem produkčních aplikací z fyzických pracovních stanic do datových center získáme řádově větší dostupnost a výkon. Datová centra jsou vybavena kvalitním, plně redundantním hardwarem, který zajistí téměř nepřetrţitý běh poţadované aplikace. Celé datové centrum můţe být navíc rozmístěno do více fyzických lokalit, aby nedocházelo k výpadkům sluţeb při kolapsu jedné lokality. Přesunout produkční aplikace do datového centra lze provést několika způsoby. Nejvhodnější způsob bude vţdy záleţet na konkrétní aplikaci a způsobu jejího pouţívání.

1.2.1 Webové aplikace Většina moderních aplikací je vyvíjena v souladu s vícevrstvou architekturou. Díky tomu není tvořena jedním velkým programem, ale několika vrstvami, které mezi sebou komunikují pomocí daného protokolu. Výhodou je poměrně snadná záměna jedné vrstvy za jinou v případě potřeby. Kaţdá tato vrstva můţe být, a zpravidla také bývá, provozována ve zcela jiném prostředí a na oddělených systémech. Nejběţnějším případem je třívrstvá architektura, která je velmi vhodná pro změnu aplikace z klasické desktopové na webovou. Třívrstvá architektura obsahuje tyto vrstvy -

Datová: slouţí k ukládání veškerých informací, se kterými aplikace pracuje. Zpravidla se jedná a vhodně vybranou SQL databázi provozovanou v datovém centru. Můţe se ale jednat o libovolný jiný systém pro ukládání dat.

-

Aplikační: zde probíhá vlastní zpracování informací, vyhodnocování a další vnitřní logika konkrétní aplikace. Aplikační vrstva je zpravidla provozována jako aplikace běţící na zvoleném operačním systému opět v datovém centru.

-

Prezenční: tato vrstva se stará o komunikaci s uţivatelem. Tedy o vykreslení uţivatelského rozhraní, zachytávaní vstupů od uţivatele a prezentaci poţadovaných

15

výstupů. Prezenční vrstva je v dnešní době zpravidla provozována jako aplikace běţící na pracovní stanici.1 Právě díky třívrstvé architektuře není velký problém zaměnit u jiţ existující aplikace prezenční vrstvu za modernější webovou a oprostit se tak od nutnosti instalace a provozování klientské části aplikace na pracovní stanici. Na pracovní stanici se tak místo instalace klientské části aplikace jen uloţí odkaz na patřičnou intranetovou, případně internetovou stránku. V některých specifických případech není úplně vhodné přecházet čistě na webové řešení, proto se zachovává i původní prezenční vrstva ve formě klasické aplikace, ale je distribuována pouze na nejnutnější stanice. Výhody -

Nemusí se instalovat na stanice.

-

Na stanicích odpadá nutnost jakékoliv správy.

-

Podstatně niţší nároky na hardware pracovní stanice.

-

Odpadá starost o lokálně uloţená data.

-

K aplikaci se dá přistoupit odkudkoliv a z jakéhokoliv zařízení vybaveného odpovídajícím prohlíţečem.

-

Snadná aktualizace aplikace.

-

Všichni uţivatelé pracují se stejnou verzí aplikace.

Nevýhody

1

-

Nutnost přeprogramování celé jedné vrstvy aplikace.

-

Nutnost optimalizace pro různé prohlíţeče.

-

Menší moţnosti interakce s operačním systémem na pracovní stanici.

ZENDULKA, J. Architektura klient/server a třívrstvá architektura [online]. 2012 [cit. 2012-04-24]. Dostupné z:

http://www.fit.vutbr.cz/study/courses/DSI/public/pdf/nove/10_clsrv.pdf

16

Všechny výše popsané případy předpokládají přidělení všech hardwarových zdrojů konkrétní pracovní stanice uţivateli, který s danou stanicí právě pracuje. Vzhledem k tomu, ţe ţádný uţivatel po celou dobu práce se stanicí není schopen vyuţít na 100 % všechny její zdroje, dochází ke značnému plýtvání. Ve firemní sféře je ještě častějším případem stálé přiřazení pracovní stanice jednomu konkrétnímu uţivateli, kdy její zdroje vyuţívá pouze v pracovní době, a většinu času je tak systém ve vypnutém stavu a nelze jeho výkon pouţít pro jiné účely. Tomuto plýtvání se dá zabránit konsolidací jednotlivých systémů na menší mnoţství fyzického hardwaru a přidělováním pouze takového mnoţství zdrojů, které daný uţivatel případně sluţba skutečně vyţaduje. Velkou výhodou této konsolidace je moţnost přidělení řádově vyšších hardwarových zdrojů v případě jejich krátkodobé potřeby. Této konsolidace jednotlivých systémů na malý počet fyzických hardwarových strojů se dosahuje pomocí virtualizace.

1.2.2 Virtualizace Kdyţ se mluví o virtualizaci, obvykle je tím myšlena virtualizace serverů, coţ znamená rozdělení jednoho fyzického serveru na několik serverů virtuálních. Kaţdý z těchto virtuálních serverů můţe pracovat se zařízeními, aplikacemi, daty nebo uţivateli stejně, jakoby se jednalo o samostatný fyzický server. Na jednotlivých serverech můţou běţet různé operační systémy a aplikace, které si mezi sebou dělí jednotlivé zdroje fyzického serveru, na němţ k virtualizaci dochází. Protoţe jsou od sebe jednotlivé virtuální servery izolovány, nedochází v případě pádu jednoho k ovlivnění ostatních. Virtualizaci serveru jako takovou umoţňuje software, který se nazývá hypervizor. Tento software bývá také nazýván virtualizační manaţer. Jeho místo je mezi hardwarem a operačním systémem, kde od sebe tyto vrstvy odděluje. Hypervizor řídí přerozdělování jednotlivých hardwarových prostředků, jako jsou například procesorový čas, operační paměť, diskové operace a další, mezi jednotlivé operační systémy a na nich běţící aplikace. Tímto způsobem se dá do značné míry ušetřit na hardwarových zdrojích, neboť mnoho uţivatelů a systémů sdílí jednu instanci operačního systému a zásadním způsobem tak klesá celkové mnoţství alokované paměti RAM a diskového prostoru pro uloţení jednotlivých operačních systémů. Klesá i potřeba výpočetního výkonu, protoţe na klasické pracovní stanici nebo serveru dochází k plnému vytíţení procesoru zpravidla jen ve velmi krátkých časových úsecích a po většinu času je procesor vytíţen jen minimálně. Vzhledem k tomu, ţe poţadavky na toto nárazové vyuţití 17

procesorového výkonu u jednotlivých uţivatelů nebo systémů nepřichází zpravidla ve stejnou dobu, je moţné na jeden procesor umístit i dvacet operačních systémů a tím dosáhnout aţ dvacetinásobné úspory na procesorech. Kromě pouţití virtualizační technologie na rozdělení jednoho fyzického serveru na několik virtuálních strojů, přináší virtualizace i opačné moţnosti, tedy kombinování více fyzických zdrojů do jednoho virtuálního. Dobrým příkladem tohoto vyuţití je virtualizace datových úloţišť. V tomto případě můţeme několik různých síťových úloţišť spojit do jednoho virtuálního a následně s ním mnohem jednodušeji a efektivněji pracovat. Mezi další typy virtualizace vhodné pro nasazení v datovém centru určeném pro konsolidaci serverů a virtuálních pracovních stanic patří: Virtualizace sítí, kde dochází k rozdělení dostupné přenosové kapacity do nezávislých kanálů, které mohou být přiřazeny jednotlivým serverům, zařízením, uţivatelům nebo sluţbám. Toto je důleţité pro garanci dostupnosti potřebné šířky pásma pro daný účel. Nesmí docházet k situacím, kdy například uţivatel zcela vytíţí datovou linku ukládáním velkého mnoţství dat na server, a tím nezbude dostatečné pásmo pro fungování jiných sluţeb jako třeba elektronické pošty. Aplikační virtualizace, která odděluje aplikace od hardwaru a operačního systému. Tyto virtualizované aplikace jsou zapouzdřeny do kontejnerů, které umoţňují jednoduchou manipulaci bez vlivu na zbytek systému. Díky aplikační virtualizaci je moţné provozovat aplikace na operačním systému bez nutnosti jejich instalace nebo konfigurace. Další výhodou je moţnost provozovat aplikace, které ke své funkčnosti potřebují odlišně nakonfigurované prostředí operačního systému. Typickým příkladem je potřeba odlišná verze Java Runtime Engine, nebo .NET Framework, kdy by bez aplikační virtualizace nebylo moţné tyto aplikace provozovat nad jednou instancí operačního systému. V neposlední řadě přináší aplikační virtualizace i moţnost provozování aplikací, které nejsou kompatibilní s novou verzí operačního systému. Je tedy moţné například na 64 bitových Windows 7 spouštět starou verzi Internet Exploreru 6 současně s novou verzí 9. Virtualizace pracovních stanic umoţňuje centralizovat pracovní stanice v datovém centru, coţ usnadňuje jejich správu, zabezpečení, zálohování a upgrade. Uţivatelé k těmto pracovním 18

stanicím přistupují vzdáleně pomocí tenkých klientů. Takto virtualizované pracovní stanice mohou být spouštěny ze samostatných disků, nebo z jednoho společného systémového a na oddělené disky ukládat pouze uţivatelská data. Podrobněji se virtuálním desktopům bude práce věnovat v následujících kapitolách. Virtualizace byla poprvé představena v roce 1960 firmou IBM pro lepší vyuţití velkých a drahých sálových počítačů jejich rozdělením na menší podsystémy, z nich kaţdý mohl zpracovávat jiné úlohy. V následujících letech se výpočty přesunuly spíše na distribuovaný model, kde mnoho levných x86 systémů hostovalo jednotlivé aplikace. Tehdy virtualizace spíše stagnovala, ale v posledních letech se opět stává velkým trendem kvůli své flexibilitě a větší efektivitě. V dnešní době nabízí různá virtualizační řešení mnoho firem. Mezi nejznámější patří VMware, Citrix, Microsoft, IBM, RedHat a mnoho dalších. Tato práce se bude věnovat řešením vybudovaných na systémech vSphere 5 od společnosti VMware a Remote Desktop Services vyuţívajících hypervizor Hyper-V 2.0, které jsou součástí Windows Server 2008 R2 od společnosti Microsoft.2

1.2.3 Microsoft Hyper-V Hyper-V nabízí

dynamickou, spolehlivou a

škálovatelnou virtualizační platformu

kombinovanou s jednotnou sadou nástrojů pro správu jak fyzických, tak virtuálních zdrojů. Díky tomu umoţňuje vytvořit stabilní dynamické datové centrum. Mezi hlavní vlastnosti a oblasti vyuţití Hyper-V patří:3 Dynamická paměť umoţňuje administrátorům lépe vyuţít paměťové zdroje Hyper-V hostitele tím, ţe vyvaţuje rozloţení operační paměti mezi jednotlivé virtuální stroje. Operační paměť tak můţe být dynamicky přerozdělována v reakci na aktuální pracovní vytíţení a poţadavky virtuálních strojů. Dynamická paměť tak umoţňuje efektivnější vyuţití paměti při zachování konzistentního pracovního výkonu a škálovatelnosti. Implementace dynamické

2

KLÁPŠTĚ, Pavel. Software v nabídce sluţeb: Bakalářská práce. Praha: Bankovní institut vysoká škola, 2010. 55 s. 3

Microsoft Windows Server 2008 R2 Hyper-V Overview. MICROSOFT [online]. 2010 [cit. 2012-04-24]. Dostupné z: http://www.microsoft.com/en-us/server-cloud/windows-server/hyper-v-overview.aspx

19

paměti tedy znamená větší moţnosti konsolidace virtuálních serverů s minimálním dopadem na jejich výkon. Dynamická paměť znamená také větší mnoţství virtuálních pracovních stanic na jednom Hyper-V hostiteli. Výsledkem je efektivnější vyuţití drahých zdrojů serverového hardwaru a niţší nároky na celkovou správu. Konsolidace serverů slouţí k usnadnění správy a sníţení nákladů při zachování výhod, jako je flexibilita, spolehlivost, škálovatelnost a zabezpečení. Základní vyuţití virtualizace pro pomoc s konsolidací mnoha serverů na jeden výsledný systém při zachování jejich izolovanosti je základem pro spolehlivé řešení v rámci datového centra. Jedním z hlavních přínosů konsolidace serverů jsou niţší celkové náklady na vlastnictví (TCO) a to nejen ve sníţení poţadavků na hardware, ale také z důvodů niţších nároků na napájení, chlazení a celkovou správu. Zajištění kontinuity provozu je schopnost minimalizovat jak plánované, tak neplánované výpadky. To zahrnuje čas ztracený při běţných operacích, jako je plánovaná údrţba nebo zálohování, stejně jako při neočekávaných výpadcích. Hyper-V zahrnuje výkonné nástroje pro podporu kontinuity provozu jako například zálohování běţících virtuálních strojů pomocí Volume Shadow Copy Service, rychlou migraci na jiný fyzický server a zajištění vysoké dostupnosti. Tyto prostředky pomáhají splnit přísné nároky na dostupnost sluţeb v rámci datacentra. Disaster recovery (zotavení po havárii) je klíčové pro zajištění kontinuity provozu. Přírodní katastrofy, cílené útoky, nebo jen obyčejné konfigurační problémy, jako například softwarové konflikty mohou ochromit dostupnost sluţeb do té doby, neţ administrátor problémy nevyřeší, případně neobnoví data ze záloh. Díky schopnostem clusterových sluţeb serveru Windows 2008 R2 podporuje Hyper-V zotavení po havárii v rámci IT prostředí i napříč datovými centry. Rychlé a spolehlivé zotavení po havárii pomáhá zajistit minimální ztrátu dat a finančních prostředků. Testování a vývoj jsou často první funkce, které dokáţou plně vyuţívat virtualizační technologie. Pomocí virtuálních pracovních stanic můţe vývojový tým vytvořit a otestovat celou řadu scénářů v bezpečném izolovaném prostředí, které co nejvíce kopíruje činnost fyzických serverů a stanic. Hyper-V maximalizuje vyuţití testovacího hardwaru, coţ

20

napomáhá sníţení nákladů, zlepšení správy ţivotního cyklu testovacích systémů a vzhledem k rozsáhlé podpoře různých operačních systémů rozšiřuje moţné testovací scénáře. Virtual Desktop Infrastrukture - mnoho zájmu v oblasti virtualizace je v dnešní době věnováno převáţně virtualizaci serverové. Nicméně značného pokroku se u Hyper-V dosahuje i v oblasti virtualizace desktopů, kdy zpracování probíhá na serverové infrastruktuře v datovém centru, která je optimalizovaná pro potřebnou kapacitu a vysokou dostupnost. Hypervizor Hyper-V na platformě Windows Server 2008 R2 tak poskytuje dobrou funkcionalitu pro vybudování kompletního virtualizovaného datového centra včetně provozu virtuálních pracovních stanic. Zároveň poskytuje řešení pro zabezpečení vysoké dostupnosti a dobré škálovatelnosti. Další výhodou je jednotná platforma zaloţená na produktech firmy Microsoft a jejich vzájemná provázanost.

1.2.4 Remote Desktop Services Remote Desktop Services (starý název Terminal Services) je role serverového operačního systému Windows, která odděluje místo, kde se s produkční aplikací nebo celou pracovní plochou pracuje a kde ve skutečnosti běţí. Tato role zároveň poskytuje moţnost zpřístupnit mnoho současných klientských relací na jednom jediném serveru, ke kterému se uţivatelé připojují vzdáleně pomocí protokolu Remote Desktop Protocol (dále RDP). Na poslední verzi Windows Server 2008 R2 se dají Remote Desktop Services nakonfigurovat do několika různých podob, kde kaţdá představuje trochu jiný přístup k řešení poţadovaného problému pro přesun produkčních aplikací do datacentra. Seznam rolí pro Remote Desktop Services:4 Remote Desktop Virtualization Host je úzce integrován s rolí Hyper-V tak, aby poskytoval virtuální stroje pro připojení pomocí RemoteApp, případně Remote Desktop Connection (připojení ke vzdálené ploše). Remote Desktop Virtualization Host můţe být nastaven tak, ţe kaţdý uţivatel má přiřazen svůj vlastní virtuální stroj nebo je dynamicky přesměrován na

4

Overview of Remote Desktop Session Host (RD Session Host). MICROSOFT. Microsoft Technet [online]. 2010 [cit. 2012-04-24]. Dostupné z: http://technet.microsoft.com/en-us/library/cc742806.aspx

21

první volný stroj z předdefinované sdílené skupiny. Remote Desktop Virtualization Host vyuţívá Remote Desktop Connection Broker ke zjištění, kam má být uţivatel přesměrován. Pokud má uţivatel přiřazenou vlastní virtuální pracovní stanici, Remote Desktop Connection Broker ho přesměruje na odpovídající virtuální stroj. Pokud je daný stroj vypnutý Remote Desktop Connection Broker jej zapne a po jeho spuštění na něj uţivatele připojí. Jestliţe uţivatel vlastní virtuální pracovní stanici přiřazenou nemá a připojuje se tak do sdílené skupiny, Remote Desktop Connection Broker nejprve ověří, zdali uţivatel jiţ nemá vytvořenou relaci z předchozí doby, od které byl pouze odpojen. Jestliţe tuto relaci nalezne, znovu k ní daného uţivatele připojí. V opačném případě dojde k přiřazení volného stroje ze sdílené skupiny. Oba přístupy mají svá specifika a je vţdy nutné vybrat ten vhodnější pro daný účel. Pro vyuţití ve virtuální učebně je výhodnější přístup s dynamickým přidělováním virtuálních pracovních stanic, neboť v opačném případě by bylo nutné vytvoření vlastní pracovní stanice pro kaţdého studenta, přestoţe je velmi nepravděpodobná práce všech studentů v jeden okamţik. Remote Desktop Session Host je server, který hostuje aplikace postavené na platformě Windows, případně celé Windows plochy pro připojující se klienty. Uţivatel se k serveru Remote Desktop Session Host připojuje, aby mohl spouštět vybrané programy, ukládat soubory, nebo vyuţívat síťové zdroje. K tomuto připojení můţe dojít pomocí Remote Desktop Connection, nebo pomocí RemoteApp, kdy se k uţivateli přenáší pouze zobrazení dané aplikace, nikoliv celá plocha systému Windows. Pokud se uţivatel připojí k takto nakonfigurovanému serveru, poţadovaný program se vţdy spustí v jeho vlastní nově vytvořené relaci, kterou daný server spravuje a je zcela nezávislá na ostatních relacích. Tento přístup k práci s produkčními aplikacemi přináší výhody v podobě jednoduchého nasazení a správy aplikací, neboť se nacházejí pouze na jednom případně několika málo Remote Desktop Session Host serverech. Další výhodou je moţnost přistupovat k takto vypublikovaným aplikacím nezávisle z různých zařízení, jako například domácí počítač, různé tablety nebo jiné zařízení, které neběţí na operačním systému Windows. Této výhody lze vyuţít i v případě potřeby práce s aplikací, která vyţaduje vysokou datovou propustnost mezi klientskou částí a aplikační částí. Pokud je s touto aplikací nutné pracovat přes pomalou datovou přípojku, je výhodnější ji přesunout na Remote Desktop Session Host server a pracovat s ní vzdáleně, čímţ se značně zredukuje datová náročnost na datovou linku. 22

Remote Desktop Connection Broker sleduje jednotlivé uţivatelské relace v Remote Desktop Session Host serverech případně v Remote Desktop Virtualization Host virtuálních strojích ať uţ se jedná o pevně přiřazené, nebo dynamicky přidělované. Remote Desktop Connection Broker ukládá informace o stavu relace, jejím ID, přiřazeném uţivateli a serveru, na kterém je relace otevřena. Tyto informace vyuţívá k přesměrování uţivatele, který se snaţí připojit, na server nebo virtuální stroj, na kterém jiţ jeho relace existuje. Pokud je na serveru Remote Desktop Connection Broker povolena funkce Load Balancing, dochází ke sledování mnoţství relací otevřených na jednotlivých serverech Remote Desktop Session Host. V případě poţadavku na vytvoření nové relace dojde k jejímu vytvoření na serveru s nejmenším mnoţstvím existujících relací a následnému přesměrování uţivatele. Tato funkce bohuţel neumoţňuje sledování reálného vytíţení jednotlivých Remote Desktop Session Host serverů, takţe dochází k vyvaţování pouze na základě počtu relací. Remote Desktop Session Host v redirection režimu Jestliţe v rámci sítě existuje farma Remote Desktop Session Host serverů a Remote Desktop Connection Broker, dochází k automatickému přesměrování uţivatele na nejvhodnější server. K tomu ovšem dojde aţ v okamţiku jeho připojení na libovolný Remote Desktop Session Host. Po úspěšné autentizaci a připojení si Remote Desktop Session Host ověří u Remote Desktop Connection Brokeru nejvhodnější server a v případě ţe jím není on sám, dojde k přesměrování uţivatele na vhodnější server, coţ přináší jistou reţii pro poměrně vytěţované servery. Je tedy moţné dedikovat roli Remote Desktop Session Host v redirection reţimu pouze jako vstupní bod, kde se pro klienta najde vhodný server a dojde k jeho přesměrování na plnohodnotný Remote Desktop Session Host. Remote Desktop Web Access umoţňuje zpřístupnit RemoteApp, případně celé pracovní plochy, uţivatelům přes webový přístup. V případě přístupu z operačního sytému Windows 7 zpřístupňuje připojení k RemoteApp přímo z menu Start. Remote Desktop Gateway zpřístupňuje autentizovaným vzdáleným uţivatelům přístup ke zdrojům ve vnitřní síti přes internet z libovolného zařízení, které obsahuje Remote Desktop Connection klienta. Mezi podporované zdroje ve vnitřní sítí patří Remote Desktop Session

23

Host servery, Remote Desktop Session Host servery provozující RemoteApp, virtuální stroje, nebo počítače se zapnutým Remote Desktop.

1.2.5 VMware vShpere a View Podobně jako řešení od společnosti Microsoft postavené na Remote Desktop Services a hypervizoru Hyper-V slouţí pro vybudování komplexní virtuální infrastruktury produkt vSphere od společnosti VMware. K vytvoření infrastruktury pro virtuální pracovní stanice slouţí doplněk VMware View5. Celé prostředí VMware vSphere se skládá z mnoha komponent. Pro vytvoření prostředí vhodného k hostování infrastruktury virtuálních pracovních stanic vyuţijeme především následující součásti. VMware ESXi – základní hypervizor instalovaný přímo na fyzické servery. Slouţí k rozdělení fyzického serveru a jeho hardwarových zdrojů na jednotlivé oddíly určené ke konsolidování mnoha virtuálních serverů a aplikací. Jedná se o stěţejní produkt pro virtualizaci jako takovou. Samotný ESXi server poskytuje pouze základní moţnosti virtualizace. Pro plnohodnotné vyuţití všech jeho moţností a vytvoření skutečné virtualizační infrastruktury je nutné jeho připojení k VMware vCenter serveru. VMware vCenter Server – centrální prvek celé virtuální infrastruktury postavené na vSphere. K vCenter serveru se připojují ESXi servery, konfigurují se v něm datacentra, clustery, pravidla pro vysokou dostupnost a všechny ostatní součásti celé vSphere infrastruktury. VMware vSphere Client – klient pro správu VMware infrastruktury. Pomocí tohoto klienta je moţné spravovat jak samostatné VMware ESXi hypervizory, tak VMware vCenter servery případně celé clustery. VMware VMotion – zajišťuje plynulou migraci běţících virtuálních serverů mezi jednotlivými fyzickými stroji. Tato funkcionalita je velmi důleţitá pro garanci vysoké

5

VMware Products. VMWARE. VMware Products [online]. 2010 [cit. 2012-04-24]. Dostupné z: http://www.vmware.com/products

24

dostupnosti sluţeb, neboť umoţňuje provádět údrţbu na jednotlivých fyzických serverech, aniţ by bylo nutné vypnout virtuální stroje. VMware Distributed Resource Scheduler (DRS) – průběţné monitorování všech fyzických zdrojů ve virtuální infrastruktuře a jejich dynamické přidělování jednotlivým virtuálním strojům dle potřeby pro co nejlepší rozloţení zátěţe na všechny fyzické servery. Jakmile stoupne zatíţení některého virtuálního stroje, DRS zajistí migraci ostatních méně vytíţených virtuálních strojů na jiný fyzický server pomocí VMware VMotion a vytíţenému serveru tak můţe přidělit mnohem více hardwarových zdrojů. VMware Distributed Power Management (DPM) – průběţně optimalizuje spotřebu datového centra. Jakmile je DRS cluster málo zatíţený, přesune pomoci VMotion virtuální servery na nejmenší nezbytně nutný počet fyzických serverů a ostatní vypne. Jakmile vzroste zatíţení, automaticky dojde k zapnutí dalších serverů a pomocí DRS k rozloţení zátěţe. VMware vStorage – virtualizace datových úloţišť. Součástí vStorage je VMware vStorage Thin Provisioning, který umoţňuje dynamické přidělování kapacity na základě reálných poţadavků a tím minimalizuje nutnost nákupu dalšího úloţného prostoru. VMware vStorage je zaloţen na výkonném clustrovém souborovém systému VMFS, který k jednomu svazku umoţňuje přístup mnoha ESXi serverům pomocí uzamykání na úrovni jednotlivých souborů. VMware vNetwork – virtualizace síťových sluţeb. VMware vSphere poskytuje bohaté moţnosti konfigurace síťového prostředí pomocí virtuálních switchů, případně virtuálních distribuovaných switchů. Je tedy moţné nastavit základní věci jako VLAN, port trunking, failovery atd., případně do infrastruktury doplnit virtuální distribuovaný switch Cisco Nexus 1000V, který je moţné spravovat Cisco nástroji a zpřístupní tak plnou funkcionalitu klasických Cisco switchů. VMware Storage Vmotion – díky této technologii je moţné přesouvat běţící virtuální servery mezi jednotlivými datovými úloţišti bez výpadku poskytovaných sluţeb. Tato funkcionalita je výhodná především při migraci z nevyhovujícího uloţiště na vhodnější, například při vyuţití sluţby VMware vSphere Storage DRS.

25

VMware vSphere Storage DRS – tato sluţba průběţně monitoruje diskovou kapacitu a I/O operace nad definovanými datovými uloţišti a inteligentně přesunuje virtuální stroje tak, aby došlo k optimálnímu vyuţívání úloţného prostoru. VMware High Availability (HA) – nástroj pro zajištění vysoké dostupnosti poskytovaných sluţeb. V případě selhání sluţby, systému nebo hardwaru se pokusí podniknout kroky vedoucí k rychlé obnově funkcionality. Mezi tyto kroky patří například restart sluţby uvnitř operačního systému, restart celého virtuálního stroje nebo spuštění virtuálního stroje na jiném fyzickém serveru. VMware Fault Tolerance – systém pro garanci maximální dostupnosti sluţby. Běţící virtuální server v reálném čase klonuje na záloţní hardware a v případě selhání primárního fyzického serveru dochází ihned k failoveru bez výpadku sluţby nebo ztráty dat. VMware Data Recovery – nástroj pro zálohování a obnovu virtuálních serverů. Tento nástroj vyuţívá VMware Storage API, které udrţuje informace o změněných diskových blocích. V případě zálohy tak není nutné načítat celý diskový image virtuálního stroje, ale pouze změny vzniklé od poslední zálohy. Data Recovery v sobě dále obsahuje integrační mechanizmy s Windows Volume Shadow Copy Service, díky kterým umoţňuje vytvoření konzistentní zálohy běţícího operačního systému včetně veškerých aplikací kompatibilních s touto sluţbou. VMware vShield – bezpečností sluţby, které slouţí pro konfiguraci firewallů, antivirových systémů, ochranu citlivých dat a podobně. VMware Operations Management Suite – dohledové centrum. Tato komponenta neustále sleduje zatíţení a dostupnost celé virtuální infrastruktury a na základě získaných dat je schopna predikovat budoucí problémy, nebo pomoci se získáním informací o volných zdrojích v infrastruktuře.

26

Obrázek 1- Schéma VMware View (Zdroj: www.vmware.com)

VMware View – rozšíření VMware vSphere pro práci s virtuálními pracovními stanicemi. Umoţňuje jejich tvorbu, správu, rozdělování do skupin přiřazování uţivatelů atd. Součástí tohoto rozšíření jsou následující komponenty. VMware View Connection Server - tento server funguje jako zprostředkovatel pro připojení klientů a jejich ověření vůči Active Directory. Po vytvoření zabezpečeného spojení a ověření klienta dojde k jeho přesměrování na příslušný virtuální stroj, přiřazení jeho virtuální plochy a aplikací zabalených pomocí ThinApp. VMware ThinApp - aplikační virtualizace. Její pomocí lze většinu klientských aplikací zabalit do jediného spustitelného souboru, který lze velmi jednoduše přiřazovat konkrétním uţivatelům nebo skupinám. Kompletně tak odpadá správa aplikací na desktopech View Client – software určený pro přístup k virtuálním pracovním stanicím. Mezi podporované platformy v současnosti patří Windows, Mac, Linux, Android a Apple iOS. Po autentizaci se uţivateli zobrazí seznam pracovních ploch, ke kterým má oprávnění a ze 27

kterých si vybere dle potřeby. View Client podporuje autentizaci pomocí Active Directory, UPN, smart card nebo RSA SecurID token. Následná komunikace probíhá pomocí protokolu PC over IP (PCoIP) nebo RDP, přičemţ rychlost a kvalita zobrazení pomocí PCoIP se blíţí zobrazení na lokální fyzické stanici. View Client na vybraných platformách dále podporuje Local Mode (lokální reţim), který umoţňuje stáhnutí virtuálního stroje na lokální systém a jeho offline provoz v případě nemoţnosti připojení do datacentra. View Portal – slouţí pro staţení případně spuštění View Clienta pomocí webového prohlíţeče. Přestoţe je ohlášen HTML 5 klient, který by umoţnil přístup k virtuální pracovní stanici přímo z prohlíţeče, v současné době je zatím vţdy potřebná instalace nativního View Clienta. View Agent – sluţba, která musí být instalována na kaţdé virtuální pracovní stanici, ke které se přistupuje pomocí View klienta. Stará se o monitorování připojení, virtuální tiskárny nebo přesměrování lokálních USB zařízení. View Administrator – webové rozhraní, které slouţí ke konfiguraci View Connection Serveru, vytváření a správy virtuálních pracovních stanic, řízení uţivatelských oprávnění a odstraňování potíţí koncových uţivatelů. View Composer – slouţí pro tvorbu virtuálních pracovních stanic. View Composer umoţňuje vytvoření skupiny linkovaných klonů z jednoho hlavního obrazu. Takto vytvořené linkované klony se chovají jako nezávislé pracovní stanice, s vlastním jménem a IP adresou, které vyţadují mnohem méně místa na datovém uloţišti, neboť všechny sdílejí původní hlavní obraz. Díky tomu je moţné s minimálním úsilím provádět správu všech virtuálních pracovních stanic, jako jsou aktualizace nebo patchovaní. S touto technologii stačí pouze upravit hlavní obraz a při dalším restartu jiţ virtuální pracovní stanice nastartují s aktualizovanou verzí. View Transfer Server – řídí a usměrňuje datové přenosy mezi datacentrem a pracovními stanicemi které pracují v offline reţimu.

28

2 Analýza potřeb a požadavků Vybudování kvalitní počítačové učebny má mnoho společného s tvorbou vnitřní firemní sítě. V obou případech je nutné vytváření uţivatelských účtů, účtů pro pracovní stanice, instalace operačních systémů, přiřazování odpovídajících aplikací, řešení oprávnění, následná správa atd. Podstatným rozdílem je častá změna uţivatelů na jednotlivých stanicích, kdy se ve firemním prostředí očekává spíše pevné přiřazení pracovní stanice ke konkrétnímu uţivateli, zatímco v učebně je toto prakticky nemoţné. Dalším rozdílem je častější poškození základní instalace operačního systému a aplikací, ať jiţ z výukových důvodů, chybnou obsluhou, nebo úmyslně. V neposlední řadě se u studentů předpokládá častější změna vyţadovaných aplikací, dle aktuálně studovaných předmětů nebo kurzů.

2.1 Cíle výsledného řešení Snížení nároků na správu Správa počítačové sítě nebo učebny se při nevhodném řešení stává velmi náročnou na lidské zdroje a tím i finance. Správce musí řešit instalace operačních systémů, instalaci a konfiguraci aplikací, aktualizace, zálohování dat, jejich přenášení na nové pracovní stanice v případě výpadku původní a mnoho dalších časově náročných činností. Cílem tedy musí být maximální eliminace těchto činností, případně jejich zjednodušení do té míry, aby je zvládl i běţný uţivatel. Centralizace správy Jestliţe je společnost rozprostřená mezi několik lokalit, zpravidla má na kaţdé lokalitě vybudovanou síť LAN s několika potřebnými servery a pracovními stanicemi. Do ostatních lokalit je připojena pomocí pomalejší sítě WAN, která neumoţňuje pohodlný aplikační přístup do centrálního datacentra společnosti. V kaţdé lokalitě tak vzniká do jisté míry nezávislá síť, která vyţaduje pravidelnou správu jak pracovních stanic, tak serverů. Další 29

nevýhodou je právě nutnost serverů v kaţdé lokalitě. Tím dochází k nutnosti vybudování malého datového centra v kaţdé lokalitě, jeho fyzickému zabezpečení, zabezpečení záloh, vysoké dostupnosti a dalších činností, které je nutné provádět. Cílem je tedy centralizace veškerých systémů do primárního datacentra. Snadná změna instalovaných aplikací Instalace nové nebo změna jiţ nainstalované aplikace je bez automatizačních nástrojů časově a finančně velmi náročná. Aplikaci je třeba nejdříve dostatečně otestovat na všech rozdílných systémech, ověřit její kompatibilitu s ostatními aplikacemi a aţ následně distribuovat na jednotlivé pracovní stanice. V případě ţe je nutné nasadit aktualizovanou verzi dané aplikace v jeden okamţik v celé síti (například z důvodů aktualizace její serverové části, kdy by klientské aplikace přestaly fungovat) je prakticky nutné vyuţít nějaký distribuční nástroj. Cílem bude maximální nezávislost aplikací na pracovních stanicích a jejich snadná správa. Možnost konfigurace aplikací dle uživatelů, nikoliv pracovních stanic Vzhledem k velké fluktuaci uţivatelů u jednotlivých pracovních stanic a jejich rozdílným poţadavkům na aplikační výbavu je vhodné přiřazovat aplikace jednotlivým uţivatelům, a nikoliv pracovním stanicím. Pokud jsou aplikace přiřazovány jednotlivým uţivatelům, a nikoliv stanicím, není pro uţivatele problém přihlásit se k libovolné pracovní stanici, na které bude mít ihned k dispozici všechny aplikace, které potřebuje. Tento poţadavek vychází z předchozího cíle snadné změny instalovaných aplikací. Snížení nákladů a času přechodu na nové verze operačních systémů V rámci jednodušší správy sítě je vţdy výhodnější provozovat všechny pracovní stanice se stejným operačním systémem. V případě vydání nového operačního systému tak dochází k několika problémům, které nemají jednoduché řešení. Pokud se v síťové infrastruktuře vyskytují pracovní stanice s různým hardware, je prakticky nemoţné na všech provozovat stejný operační systém. Staré stanice totiţ zpravidla jiţ nebývají s novou verzí operačního systému kompatibilní, případně pro něj nemají dostatečný výkon, zatímco plná funkcionalita nových pracovních stanic nemusí být při instalaci staré verze operačního systému plně vyuţitá. Pokud jsou starší stanice s novou verzí operačního systému kompatibilní a mají 30

dostatečný výkon, stále je nutné jejich sloţité přeinstalování, které se neobejde bez důkladného testování, zálohování dat, reinstalace operačního systému a následné instalace a konfigurace aplikací. Cílem je tedy co největší nezávislost operačního systému na hardware pracovní stanice. Prodloužení životního cyklu koncových zařízení/pracovních stanic Pokrok v ICT technologiích je poměrně rychlý a hardware pracovních stanic tak poměrně rychle morálně zastarává. V rámci udrţení práce nebo výuky na nejmodernějších zařízeních je nutné provádět časté obměny, které bývají zpravidla značně finančně nákladné. Pokud je moţné provozovat operační systém zcela nezávisle na hardware pracovní stanice, ţivotní cyklus koncového zařízení lze značně prodlouţit. Snížení prostojů v případě havárie koncového zařízení Jestliţe dojde k selhání pracovní stanice, zpravidla to znamená několikahodinovou odstávku, která vyústí v nemoţnost práce zaměstnance, nebo výuky studenta a nutného zásahu správce. Cílem je moţnost práce z libovolného zařízení, případně jeho snadná výměna. Přístup z libovolného místa Zaměstnanec či student by měl mít ke svým aplikacím přístup kdykoliv a odkudkoliv to bude potřebovat. Pokud tedy student potřebuje pomocí školní aplikace vypracovat projekt, nemusí proto nutně pouţívat pracovní stanice ve školní učebně, ale můţe se bez problémů připojit vzdáleně z domova. V kombinaci s vhodným softwarem pro ţivé meetingy je také moţné provádět lektorskou činnost prakticky bez nutnosti existence učebny jako takové, kdy kaţdý student můţe být v jiné části světa a pro výuku mu stačí pouze zařízení schopné připojení ke školní infrastruktuře. Cílem je uţivatelům umoţnit vzdálený přístup k jejich aplikacím. Možnost plného přístupu k pracovní stanici

31

Plný přístup k pracovní stanici je zpravidla neţádoucí u běţného zaměstnance, nicméně například u programátorů, nebo studentů můţe být podmínkou nutnou k jejich efektivní práci, případně studiu. Odhlučnění učeben, úspora energie Dnešní běţné pracovní stanice mají zpravidla nezanedbatelný příkon, jenţ přeměňují na teplo, které je následně odváděno pomocí soustav hlučných ventilátorů. Dalším zdrojem hluku je pevný disk, který je nezbytný pro běh operačního systému. Snadná rozšiřitelnost V prvotním návrhu se počítá s pilotním nasazením virtualizovaných pracovních stanic pro jednu počítačovou učebnu umístěnou v hlavní lokalitě a jednu učebnu mimo hlavní budovu. Další testovací skupinou budou studenti, kteří budou mít umoţněn přístup z libolného místa. Tato skupina by se po skončení pilotního provozu měla rozrůst na většinu studentů, kteří mají do počítačových učeben přístup. Dále je v plánu pilotní nasazení pro pět zaměstnanců, kteří by měli být schopni vyuţívat virtualizovanou pracovní stanici pro všechny své pracovní úkony. Pokud budou výsledky pilotního provozu pozitivní, počítá se s postupnou virtualizací dalších učeben a pracovních stanic zaměstnanců. Celý systém tedy musí být snadno rozšířitelný o další výpočetní výkon stejně jako operační paměť a diskový prostor. Ideálním řešením by byl nárůst diskového prostoru pouze o uţivatelská data, nikoli o jednotlivé kopie operačních systémů. Oprava poškozené instance operačního systému bez zásahu administrátora Vhledem k moţnosti plného přístupu k operačnímu systému můţe často docházet k jeho fatálnímu poškození. Je tedy vhodné, aby případnou obnovu do provozního stavu zvládl svépomoci přímo uţivatel a nemusel se spoléhat na zásah administrátora. Snadná obnova koncových zařízení Přestoţe v tomto případě bude k morálnímu zastarávání koncových zařízení docházet mnohem pomaleji neţ v případě běţných pracovních stanic, jejich obnova musí být snadná a rychlá.

32

Práce s lokálními periferiemi Při práci s virtuálním desktopem musí být zachována moţnost práce s lokálními zařízeními, jako je například tiskárna, scanner flashdisk nebo jiné periferie.

2.2 Výběr technologií Virtualizovat aplikace či celé pracovní stanice uţivatelů lze v zásadě těmito způsoby: •

pouţívat virtuální aplikace,

•

terminálově přistupovat k aplikacím běţícím na pracovní ploše serveru,

•

terminálově přistupovat k virtuálním desktopům uţivatelů a odtud spouštět aplikace.

2.2.1 Virtuální aplikace Virtuální aplikace běţí na serveru, na místní počítač se nic neinstaluje. Aplikace na místní počítač jen promítá svoje okno a čte vstupy uţivatele (typicky klávesnici a myš). Konfigurace je dána centrálně a nelze ji uţivatelsky měnit. Výhodou jsou malé nároky na zdroje pro provoz aplikací. Pruţné centrální změny konfigurace. Publikace (zpřístupnění aplikace uţivatelům) či její zrušení je otázkou několika kliknutí myší (obvykle se provádí skupinovou politikou). Některé aplikace nelze na serveru provozovat bez podstatné úpravy. Tento přístup není pro zadané cíle vhodný, neboť stále vyţaduje přítomnost klasické pracovní stanice s plnohodnotným operačním systémem, přinášející výše popsané nevýhody. Nicméně tvoří vhodný doplněk k plnohodnotnému terminálovému přístupu.

2.2.2 Terminálový přístup Uţivatel pouţívá operační systém serveru, aplikace běţí také na serveru. Virtuální desktop uţivatele se vytváří v paměti terminálového serveru. Uţivatel má k dispozici pouze svůj profil a aplikace instalované na terminálovém serveru.

33

Na serveru běţí jen profily přihlášených uţivatelů a aplikační klienti (relativně malé nároky na zdroje serveru). Některé aplikace nelze na terminálovém serveru provozovat bez podstatné úpravy, je proto nutné jejich otestování. Všichni uţivatelé musejí mít stejnou verzi serverového operačního systému. Tento způsob práce umoţňuje role Windows Server 2008 R2 Remote Desktop Services.

2.2.3 Virtuální desktopy Klientská aplikace – poskytuje set operačního systému a aplikací dohromady na pracovní stanici. Operační systém i aplikace jsou fyzicky uloţené na virtuální pracovní stanici v datacentru. Uţivatel můţe mít k dispozici více různých operačních systémů a aplikací, například pro testování. Uţivatel můţe mít plné oprávnění k úpravám konfigurací aplikací i operačního systému. Toto řešení je vhodné, protoţe není nutné nijak modifikovat stávající (ani budoucí) aplikace a nehrozí ani vzájemné ovlivňování aplikací a hostitelských systémů na jednotlivých virtuálních PC. Toto řešení nabízí jak Windows Server 2008 R2 Remote Desktop Services, tak VMware View a obě budou podrobně rozebrány v následujících částech.

2.3 Obecný návrh řešení Základní myšlenkou pro virtualizaci pracovních stanic je, ţe uţivatel bude mít k dispozici jakoukoliv stanici či terminál, se kterou se bude schopen připojit na centrální servery ke svému desktopu, případně aplikacím. Ihned po zapnutí stanice se objeví přihlášení k virtuálnímu desktopu (na pracovní stanici můţe být speciálně upravený operační systém, který umoţní pouze připojení k virtuálnímu desktopu

pomocí

vhodného

klienta

(Remote

Desktop

Client,

VMware

View).

Komunikace mezi aplikacemi a jejich serverovými částmi pak bude probíhat přímo v rámci

34

datacentra, na stanici (tenkého klienta) se bude přenášet pouze obrazovka či tisk na lokální tiskárnu. Zpětně se budou přenášet znaky z klávesnice a pohyby myši. Přihlášení uţivatelů bude okamţité a mohou ihned vyuţívat všechny aplikace podobně, jako by seděli fyzicky v rámci datacentra. Veškerá infrastruktura ze vzdálené lokality, kromě tiskáren a dalších periferií, bude migrována do datacentra. Na jednotlivých lokalitách zůstanou pouze původní či nově zakoupené stanice-terminály (Tenkých klientů) uţivatelů a samotná periferní zařízení (tiskárny, skenery, multifunkce). Virtualizované pracovní stanice uţivatelů pak poběţí v datacentru, stejně jako např. Active Directory, sdílené soubory i tiskové sluţby. Motivací je jednodušší správa infrastruktury i virtualizovaných pracovních stanic. Z pohledu aplikací nebude např. jiţ nutné provozovat lokální dokumentové úloţiště, záloţní Active Directory, nebude nutné provozovat lokální systémy aplikací jako je například zálohování, SQL a další. Tím dojde k dalším úsporám ve správě a licencích.

2.4 Plánované testy Všechna předkládaná řešení je nutné podrobit důkladnému testování na několika úrovních. Jedná se o testy kompatibility aplikací, hardware a náročnosti na kvalitu přenosových linek. Pro tyto testy bylo vytvořeno prostředí, které je s několika úpravami moţné nasadit přímo v produkční síti. Mezi tyto úpravy patří především doplnění dalších dvou serverů pro zajištění vysoké dostupnosti a pouţití diskového pole místo integrovaných pevných disků v kaţdém serveru.

2.4.1 Testovací prostředí: Jako testovací server byl pouţit Cisco UCS C210M2 s těmito parametry: CPU: 2 x Intel Xeon 2,66Ghz 35

RAM: 48 GB HDD: 4 x 146 GB SAS 10k Server z rodiny Cisco byl zvolen především díky jeho jedinečnému systému Cisco Unified Computing System (dále UCS), který představuje radikální zjednodušení tradiční architektury datacentra. Architektura UCS se skládá z výpočetního hardware, podpory virtualizace, síťové infrastruktury a nástrojů pro správu. Všechny tyto části jsou v rámci UCS integrovány do jedné kompaktní platformy, která můţe být spravována jako jeden celek.6 Pro simulaci práce přes pomalé datové připojení a ověření nároků na linku byl pouţit router Cisco 2600 zapojen na linku, přes kterou uţivatelé přistupovali do virtuální infrastruktury. Router musel být připojen na zvláštní datovou linku, neboť nesměla být ovlivněna ani měřena komunikace mezi infrastrukturou virtuálních desktopů a ostatní infrastrukturou v testovacím datacentru. Měření mnoţství přenesených dat bylo měřeno pomocí technologie Netflow a testování kvality práce na různých rychlostech WAN linky bylo docíleno nastavením shapingu na vstupním a výstupním rozhraní. Na této testovací infrastruktuře byla postupně zprovozněna dvě řešení zaloţená na Microsoft Windows Server 2008 R2 a jeho rolích Remote Desktop Services a Hyper-V a dále jedno řešení postavené na VMware View Virtual Desktop Infrastructure (VDI). V kaţdém řešení byly zprovozněny následující aplikace: Microsoft Office 2010 Microsoft Visual Studio 2010 Opera Browser Adobe Reader Adobe Flash Software602 Form Filler CorelDRAW Graphics Suite X5 GNU Image Manipulation Program (GIMP)

6

Unified Computing and Servers [online]. 2012 http://www.cisco.com/en/US/products/ps10265/technology.html

36

[cit.

2012-04-24].

Dostupné

z:

XNView K této testovací infrastruktuře následně dostalo přístup deset vybraných uţivatelů, kteří byli poţádání o plnění maximálního mnoţství svých pracovních úkolů pomocí tohoto prostředí. Testy probíhaly vţdy týden, kaţdý den s niţší rychlostí simulované WAN linky. V pondělí byla rychlost neomezena, komunikace probíhala v rámci rychlosti LAN, tedy 100 Mbit/s. V úterý byla nastavena maximální rychlost na 5 Mbit/s, ve středu na 4 Mbit/s, ve čtvrtek na 3 Mbit/s a v pátek na 2 Mbit/s. Uţivatelé byli následně poţádání o krátké hodnocení komfortu práce a případných problémů. Pokud se problém vyskytl jiţ v průběhu testu, došlo k pokusu o jeho odstranění.

3 Návrh řešení pomocí Microsoft Hyper-V Jak jiţ bylo výše popsáno, společnost Microsoft nabízí dva odlišné přístupy pro virtualizaci pracovních stanic pomocí sluţeb Remote Desktop Services. První z nich je virtualizace pracovních ploch na jeden nebo více serverů pomocí Remote Desktop Session Host a druhý virtualizace celých pracovních stanic pomocí Remote Desktop Virtualization Host. Tyto role se v rámci infrastruktury vhodně doplňují, proto proběhla jejich instalace a konfigurace současně. Vzhledem k omezenému mnoţství operační paměti ve fyzickém serveru byly zapnuty vţdy jen ty servery, které byly pro konkrétní test nutné.

3.1 Remote Desktop Session Host Prvním testovacím scénářem byl provoz virtuálních ploch v terminálovém reţimu pomocí Remote Desktop Session Host. Celé infrastruktura potřebná pro běh Remote Desktop Session Host čítá několik běţících instancí Windows 2008 R2 Serveru a z důvodů dostupnosti pouze jednoho testovacího fyzického serveru, bylo nutné pouţít serverovou virtualizaci. Vzhledem k tomu, ţe celé řešení bude postavené na technologiích společnosti Microsoft, byl za hypervizor zvolen Microsoft Hyper-V 2.0 obsaţený jako role Windows 2008 R2 Serveru. Z důvodů vytváření clusteru pro zajištění vysoké dostupnosti pro role Remote Desktop Session Host je nutné vyuţít edice Windows 2008 R2 Server Enterprise, (která byla pouţita) nebo vyšší. 37

Celá infrastruktura se tedy skládala z těchto serverů a rolí: -

Srv01: Hyper-V zároveň s Remote Desktop Virtualization Host

-

Srv02: Active Directory pro testovací prostředí

-

Srv03: Remote Desktop Session Host 1

-

Srv04: Remote Desktop Session Host 2

-

Srv05: Remote Desktop Connection Broker zároveň s Remote Desktop Host serverem běţícím v redirection módu

-

Srv06: Remote Desktop Web Access

-

Srv07: Remote Desktop Gateway

-

VDI_01 – VDI_10: Virtuální pracovní stanice

3.1.1 Příprava prostředí Srv01 – Hyper-V Parametry serveru: CPU: 2 x Intel Xeon 2,66Ghz RAM: 48 GB HDD: 4 x 146 GB SAS 10k Operační systém: Windows Server 2008 R2 Enterprise Instalované role: Hyper-V Na fyzickém serveru bylo nakonfigurováno síťové rozhraní se dvěma LAN adaptéry, kdy jeden byl zapojen přímo do lokální sítě a druhý přes router Cisco. Následně byly nakonfigurovány disky do pole RADI5, čímţ vznikl diskový prostor o velikosti cca 420 GB, na který proběhla instalace operačního systému. Při instalaci bylo zvoleno výchozí rozdělení diskového prostoru, tedy 100 MB zaváděcí oddíl bez následného zpřístupnění pomocí písmenka a zbytek jako systémový oddíl C. Toto rozdělení neodpovídá doporučením od společnosti Microsoft, pro provozování role Hyper-V nicméně v rámci zjednodušení pro testovací prostředí jej takto lze provozovat.

38

Instalace role Hyper-V7 Instalace rolí v operačním systému Windows 2008 R2 Server můţe probíhat třemi různými způsoby. Prvním z nich je instalace pomocí grafického rozhraní, kdy se spustí Server Manager, v něm se zvolí přidat roli a projde se grafickým průvodcem. Druhou moţností je instalace z příkazového řádku pomocí nástroje servermanagercmd.exe. V tomto případě instalace probíhá zadáním příkazu servermanagercmd -i Hyper-V -restart který následně provede restart. Třetí moţností je vyuţití powershellu. V tomto případě je nutné nejprve naimportovat modul servermanager a následně provést instalaci role Hyper-V. Příkazy vypadají takto: Import-Module servermanager Add-WindowsFeature Hyper-V Po jejich provedení je nutné manuálně restartovat server. Při konfiguraci role Hyper-V je nutné zvolit přiřazené síťové adaptéry, které bude moţné vyuţívat virtuálními servery. V produkčním prostředí je doporučeno nechat jeden adaptér čistě pro potřeby systému instalovaného přímo na fyzický hardware. Toto řešení by ovšem vedlo ke sloţitějšímu síťovému zapojení, a proto od něj bylo v rámci testu upuštěno. Adaptér zapojený do místní sítě byl tedy nakonfigurován jako sdílený jak pro operační systém na fyzickém serveru, tak pro virtuální stroje. Adaptér zapojený do měřícího routeru Cisco byl nakonfigurován pouze pro vyuţití virtuálními stroji. Takto nakonfigurovaný server byl aktualizován posledními aktualizacemi a připraven k instalaci dalších virtuálních serverů.

7

Installing Hyper-V on Windows Server 2008 R2 [online]. 2012 [cit. 2012-04-24]. Dostupné z: http://www.petri.co.il/installing-hyper-v-on-windows-server-2008-r2.htm

39

Srv02: Active Directory pro testovací prostředí Vzhledem k dočasnosti testovacího prostředí není vhodné vytvářet účty pro jednotlivé servery a sluţby v produkční Active Directory doméně. Z tohoto důvodu byl vytvořen Srv02, na kterém byla nakonfigurována role Active Directory a vytvořena nová subdoména rdptest. Vzhledem k instalaci do virtuálního prostředí vytvořeného serverem Srv01 bylo nutné nakonfigurovat nový virtuální stroj s následujícími parametry: Parametry serveru: CPU: 1 jádro RAM: 4 GB HDD: 40 GB dynamický Operační systém: Windows Server 2008 R2 Enterprise Instalované role: Active Directory Pomocí konzole Virtual Machine Manager (konzole pro správu role Hyper-V) byl spuštěn průvodce New Virtual Machine Wizard, do kterého byly zadány výše uvedené parametry. Po jeho dokončení systém vygeneruje prázdný virtuální stroj, do kterého je nutné nainstalovat operační systém. V produkčním prostředí se pro tuto činnost zpravidla pouţívají předpřipravené šablony s jiţ nainstalovanými systémy, v tomto prostředí však k jejich tvorbě nedošlo. Po instalaci operačního systému došlo k jeho zařazení do jiţ existující domény a instalaci role Active Directory. Jakmile byla role nainstalována, došlo k aktualizaci celého systému následovaného restartem. V tento okamţik bylo moţné vytvořit novou Active Directory subdoménu rdptest spuštěním příkazu DCPROMO, který vyvolá konfiguračního průvodce. Po jeho dokončení byl server připraven poskytovat funkcionalitu Active Directory pro celou testovací infrastrukturu v subdoméně rdptest. Srv03 a Srv04: Remote Desktop Session Host 1 a 2

40

Servery Srv03 a Srv04 slouţily jako terminálové servery v load balancingové farmě. Byla mezi ně tedy rozdělována připojení od jednotlivých uţivatelů. Z tohoto důvodu musely být nakonfigurovány zcela identicky jak po stránce systémové, tak aplikační.8 Parametry serverů: CPU: 2 jádra RAM: 8 GB HDD: 100 GB dynamický Operační systém: Windows Server 2008 R2 Enterprise Instalované role: Remote Desktop Session Host, uţivatelské aplikace Po vytvoření nových virtuálních strojů na Srv01 a odpovídající instalaci operačních systémů byly nakonfigurovány role Remote Desktop Session Host následujícím způsobem. V Server Manageru byl spuštěn průvodce přidáním role a v něm zvoleno Remote Desktop Session Host. V dalším kroku se průvoce ptá na volbu Require Network level Authentication. Tato volba rohoduje o tom, zda se k budoucí virtuální ploše bude schopen připojit pouze klient, který Network Level Authentication podporuje. Vzhledem k poţadavkům na připojení různých klientů byla nastavena na Do not require Network level Authentication, neboť někteří klienti touto technologií nedisponují. Průvodce dále vyţaduje zadání licenční metody – na uţivatele, nebo na koncové zařízení, případně konfigurovat později. Pokud je zvolena tato moţnost, je moţné provozovat Remote Desktop infrastrukturu po 120 dní bez zadání licence. Tato doba je pro testovací prostředí dostatečná, byla tedy zvolena moţnost Configure later. Následujícím krokem je konfigurace Client Experience. Zde je moţnost nakonfigurovat podporu přenosu audia a zapnout podporu pro zobrazení pomocí Windows Aero. Tyto volby byly potvrzeny a instalace byla dokončena.

8

Windows Server 2008 R2 Remote Desktop (RD) Services [online]. 2012 [cit. 2012-04-24]. Dostupné z: http://www.techotopia.com/index.php/Windows_Server_2008_R2_Remote_Desktop_(RD)_Services

41

Dalším krokem bylo přidání vybraných uţivatelů do skupiny s oprávněním vyuţívat vzdálenou plochu. To proběhlo nastavením v cestě Control Panel -> System and Security -> System -> Remote settings -> Select Users, kde byli zvoleni všichni testovací uţivatelé. V tento okamţik byly servery po systémové stránce připraveny a přistoupilo se k instalaci jednotlivých aplikací. Terminálové servery je před kaţdou instalací nutné přepnout pomocí příkazu change user /install do instalačního reţimu a po dokončení instalace pouţít příkaz change user /execute coţ bylo při kaţdé instalaci provedeno. Jednotlivé aplikace se nainstalovaly jejich výchozím způsobem a bylo ověřeno jejich bezproblémové spouštění. V posledním kroku došlo k instalaci tiskáren. Vzhledem k testovacímu prostředí nedošlo k připojení všech provozních tiskáren, ale pouze vybrané skupiny nejčastěji vyuţívaných. Srv05: Remote Desktop Connection Broker zároveň s Remote Desktop Host serverem běžícím v redirection módu Srv05 hostí roli Remote Desktop Connection Broker a vzhledem k její malé náročnosti na výpočetní zdroje je moţné ji provozovat spolu s rolí Remote Desktop Host v redirection módu.9 Parametry serveru: CPU: 1 jádro RAM: 4 GB

9

Deploying a Windows Server 2008 R2 Remote Desktop Server Farm using RD Connection Broker [online]. 2012 [cit. 2012-04-24]. Dostupné z: http://www.techotopia.com/index.php/Deploying_a_Windows_Server_2008_R2_Remote_Desktop_Server_Far m_using_RD_Connection_Broker

42

HDD: 40 GB dynamický Operační systém: Windows Server 2008 R2 Enterprise Instalované role: Remote Desktop Connection Broker, Remote Desktop Host v redirection módu Instalace probíhala běţným způsobem, tedy vytvořením virtuálního stroje na Srv01, instalací operačního systému, obou rolí a aktualizací. Instalace role Remote Desktop Connection Broker automaticky vytvoří skupinu Session Broker Computers, do které je nutné vloţit oba Remote Desktop Host servery Srv03 a Srv04 a dále Remote Desktop Host v redirection módu, tedy Srv05. Po přidání do skupiny bylo nutné servery připojit k Remote Desktop Connection Brokeru, coţ bylo provedeno pomocí konzole Remote Desktop Session Host Configuration v sekci Member of farm in RD Connection Broker. Zde bylo nutné vyplnit název vytvořené farmy a jméno Remote Desktop Connection Brokeru. Servery Srv03 a Srv04 byly nastaveny jako Farm member, zatímco server Srv05 byl nastaven jako Dedicated farm redirection. Srv06: Remote Desktop Web Access Parametry serveru: CPU: 1 jádro RAM: 4 GB HDD: 40 GB dynamický Operační systém: Windows Server 2008 R2 Enterprise Instalované role: Remote Desktop Web Access Po vytvoření virtuálního stroje na Srv01 byl nainstalován operační systém a přidána role Remote Desktop Web Access. Role Remote Desktop Web Access pro svůj běh dále vyţaduje

43

roli IIS web server, která byla automaticky zvolena pro instalaci. Po instalaci rolí byl proveden restart serveru a jeho aktualizace.10 Jakmile byl dokončen restart serveru, bylo moţné přistoupit na nově vytvořené webové rozhraní na adrese https://srv06/RDweb. Role Remote Desktop Web Access pro zpřístupnění obsahu vyuţívá JScript, coţ je implementace JavaScriptu z dílen společnosti Microsoft. Bylo proto nutné přidat uvedenou adresu do důvěryhodných. To bylo provedeno spuštěním Internet Exploreru a volbou internet options. V zobrazeném dialogu byla adresa přidána do trusted sites na záloţce security. Tento krok bylo nutné provést na kaţdé pracovní stanici, ze které se přistupovalo na webové sluţby role Remote Desktop Web Access. Srv07: Remote Desktop Gateway Parametry serveru: CPU: 1 jádro RAM: 4 GB HDD: 40 GB dynamický Operační systém: Windows Server 2008 R2 Enterprise Instalované role: Remote Desktop Gateway Stejně jako u ostatních serverů byl vytvořen virtuální stroj a nainstalován operační systém s rolí Remote Desktop Gateway, vyţadovaným IIS Web serverem a posledními aktualizacemi.11 Po instalaci byl spuštěn Remote Desktop Gateway Manager, ve kterém byl přiřazen odpovídající certifikát pro webový server, nastavena skupina uţivatelů s oprávněním přístupu přes Remote Desktop Gateway a vytvořena skupina zdrojů, které bude tato sluţba publikovat.

10

Configuring Windows Server 2008 RD Web Access [online]. 2012 [cit. 2012-04-24]. Dostupné z: http://www.techotopia.com/index.php/Configuring_Windows_Server_2008_RD_Web_Access 11 Building a Remote Desktop Gateway (RDG) / RD Gateway Server [online]. 2012 [cit. 2012-04-24]. Dostupné z: http://www.rayheffer.com/953/building-a-remote-desktop-gateway-rdg-rd-gateway-server/

44

Do této skupinu zdrojů byly zařazeny servery Srv03 a Srv04. Následně byla ověřena funkčnost serveru Srv07 pomocí klienta pro vzdálené připojení. Srv01: Remote Desktop Virtualization Host Vzhledem k potřebě ostatních rolí pro instalaci Remote Desktop Virtualization Host došlo k instalaci této role aţ v poslední fázi přípravy celého testovacího prostředí. Role byla instalována standardním průvodcem pro správu rolí ve výchozí konfiguraci.12 V takto vytvořeném prostředí bylo nutné vytvořit jednotlivé virtuální pracovní stanice, provést jejich konfiguraci a následné přiřazení uţivatelům. Tento krok je moţné do jisté míry automatizovat, nicméně v testovacím prostředí s malým mnoţstvím virtuálních pracovních stanic je to spíše kontraproduktivní, a proto od automatické konfigurace bylo upuštěno. VDI_01 – VDI_10: Virtuální pracovní stanice Parametry stanice: CPU: 1 jádro RAM: 2 GB HDD: 40 GB dynamický Operační systém: Windows 7 Enterprise 64 bit Po vytvoření virtuální pracovní stanice následovala instalace operačního systému Windows 7 Enterprise a jeho aktualizace. Virtuální pracovní stanice byla následně přiřazena do testovací domény Active Directory. Následně byla virtuální pracovní stanice nakonfigurována podobným způsobem jako klasická pracovní stanice. Došlo tedy k instalaci aplikací a jejich konfiguraci pro jednotlivé uţivatele. Následovala instalace a konfigurace vybraných síťových tiskáren. Jakmile byla takto vytvořená virtuální pracovní stanice plně funkční, přistoupilo se k jejímu začlenění do Remote Desktop infrastruktury pomocí následujících kroků:

12

Building VDI using Remote Desktop Services (RDS) [online]. 2010 [cit. 2012-04-24]. Dostupné z: http://www.ms4u.info/2010/03/part-1-building-vdi-using-remote.html

45

1) Povolení Vzdálené plochy: a. Přihlášení se do virtuální pracovní stanice pomocí účtu s administrátorským oprávněním. b. Otevření vlastností na „Tento počítač“. c. V záloţce Vzdálená plocha zaškrtnutí Povolit připojení z libovolné verze klienta. d. Pod tlačítkem Uživatelé přidat skupinu testovacích uţivatelů. e. Dialogy potvrdit a uzavřít. 2) Povolení vzdáleného volání procedur (Remote RPC) a. Přihlášení se do virtuální pracovní stanice pomocí účtu s administrátorským oprávněním. b. Spuštění regedit.exe. c. V klíči HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\TerminalSer ver nastavit parametr AllowRemoteRPC na hodnotu 1. d. Dialog potvrdit a ukončit regedit.exe. 3) Povolení výjimky na firewallu pro vzdálenou správu a. Přihlášení se do virtuální pracovní stanice pomocí účtu s administrátorským oprávněním. b. Spuštění konfigurace Windows Firewall v ovládacích panelech. c. Přidání výjimky zaškrtnutím volby u Remote Service Management d. Potvrzením dialogu a uzavřením ovládacích panelů. 4) Přidání oprávnění pro protokol RDP a. Přihlášení se do virtuální pracovní stanice pomocí účtu s administrátorským oprávněním. b. Spuštěním příkazové řádky přes volbu „Spustit jako správce“ c. Zadáním následujících příkazů: d. wmic /node:localhost RDPERMISSIONS where TerminalName="RDP-Tcp" CALL AddAccount "Srv01$",1 e. wmic /node:localhost RDACCOUNT where "(TerminalName='RDP-Tcp' or TerminalName='Console')

and

ModifyPermissions 0,1 46

AccountName='

Srv01'"

CALL

f. wmic /node:localhost RDACCOUNT where "(TerminalName='RDP-Tcp' or TerminalName='Console')

and

AccountName='

Srv01$'"

CALL

ModifyPermissions 2,1 g. wmic /node:localhost RDACCOUNT where "(TerminalName='RDP-Tcp' or TerminalName='Console')

and

AccountName='

Srv01$'"

CALL

ModifyPermissions 9,1 h. Restart virtuální pracovní stanice Tyto kroky byly provedeny na kaţdé virtuální pracovní stanici, čímţ byla vytvořena infrastruktura virtuálních pracovních stanic. Po otestování funkčnosti došlo k vypnutí jednotlivých virtuálních pracovních stanic, neboť hardwarové zdroje testovacího serveru byly omezené a první test byl zaměřen na práci s Remote Desktop Session Host servery, pro který nebyly potřeba. Uživatelské stanice Na plochu pracovní stanice uţivatelů, kteří byli vybráni pro testování, byl nakopírován zástupce klienta vzdáleného připojení a v něm přednastavena adresa pro připojení k Remote Desktop Session Host v Redirection reţimu. Další parametry byly nastaveny následovně: Display configuration Colors Remote audio playback Remote audio recording Apply Windows key combinations Local devices and resources Connection speed

Full Screen True Color (24 bit) Play on this computer Do not record On the remote computer Printers, Clipboard, Other supported PnP devices Low-speed broadband Tabulka 1 - nastavení RDP klienta

3.1.2 Průběh testů Uţivatelé byli instruováni ohledně pouţívání testovacího prostředí, jeho funkčnosti, vlastností a podobně. Práce pomocí virtuální plochy jim byla předvedena a byly zodpovězeny případné dotazy. Následně byli uţivatelé poţádáni o vykonávání svých běţných pracovních úkolů pomocí testovací infrastruktury. Během testování byla měřena celková doba připojení, 47

přenesená data a průměrná rychlost datového toku. Naměřené hodnoty jsou uvedeny v následujících tabulkách. Trvání (s)

Přeneseno MB

bitů/s

Uţivatel4

28 585

1 188

348 502

Uţivatel9

18 165

752

347 305

Uţivatel7

27 260

710

218 536

Uţivatel1

13 034

642

413 111

Uţivatel10

31 939

586

154 009

Uţivatel6

14 570

432

248 792

Uţivatel8

32 531

410

105 722

Uţivatel3

26 744

385

120 846

Uţivatel2

14 323

320

187 229

Uţivatel5

13 723

271

165 849

Tabulka 2 - Hodnoty při rychlosti 100 Mbit/s

Jak je vidět z naměřených dat, rychlost jednotlivých datových toků byla velice proměnlivá. Špičkové hodnoty dosahovaly rychlosti 400 Kbit/s na stanici, zatímco v některých případech byla rychlost komunikace poloviční. Uţivatelé nebyli omezování v rychlosti. Z pohledu rychlosti práce na virtuální ploše prakticky nepoznali rozdíl mezi běţnou prací na klasické pracovní stanici a na virtuální ploše.

48

Trvání (s)

Přeneseno MB

bitů/s

Uţivatel4

17 689

612

290 418

Uţivatel1

12 362

553

375 555

Uţivatel6

17 652

476

226 175

Uţivatel2

23 145

470

170 208

Uţivatel9

12 348

465

315 732

Uţivatel7

20 833

452

182 113

Uţivatel5

14 812

266

150 772

Uţivatel10

13 834

212

128 341

Uţivatel3

13 383

161

100 705

Uţivatel8

11 881

136

96 111

Tabulka 3 - Hodnoty při rychlosti 5 Mbit/s

V tomto dni byla rychlost na měřícím routeru sníţena ze 100 Mbit/s na 5 Mbit/s, coţ mnoţství přenášených dat do značné míry ovlivnilo. U graficky velmi náročných aplikací začalo být patrné občasné překreslování obrazu, pokud s danou aplikací pracovalo v jeden okamţik více uţivatelů. K tomuto jevu ovšem docházelo pouze zřídka a nebyla tím ovlivněna schopnost práce s virtuální pracovní plochou. Trvání (s)

Přeneseno MB

bitů/s

Uţivatel4

24 102

695

242 015

Uţivatel9

17 818

610

287 029

Uţivatel1

11 754

478

341 414

Uţivatel2

25 064

462

154 735

Uţivatel5

22 584

369

137 065

Uţivatel6

14 840

364

205 613

Uţivatel7

12 972

256

165 558

Uţivatel10

13 726

175

106 951

Uţivatel3

11 878

119

83 921

Uţivatel8

11 612

111

80 092

Tabulka 4 - Hodnoty při rychlosti 4 Mbit/s

49

Ve třetím testovacím dni byla maximální rychlost nastavena na 4 Mbit/s. Jediný pozorovatelný rozdíl v kvalitě práce s virtuální pracovní plochou spočíval v častějším výskytu pomalejšího překreslování obrazu u graficky náročných aplikací. Toto překreslování jiţ bylo v některých případech nepříjemné a způsobovalo zhoršení kvality práce. Trvání (s)

Přeneseno MB

bitů/s

Uţivatel1

25 455

863

284 512

Uţivatel4

24 978

601

201 679

Uţivatel6

22 942

469

171 344

Uţivatel7

25 648

460

150 507

Uţivatel9

10 399

297

239 191

Uţivatel10

21 853

253

97 228

Uţivatel5

12 611

187

124 605

Uţivatel8

21 520

171

66 744

Uţivatel2

10 859

167

128 946

Uţivatel3

16 607

138

69 934

Tabulka 5 - Hodnoty při rychlosti 3 Mbit/s

Pro čtvrtý testovací den byla nastavena rychlost 3 Mbit/s. Při této rychlosti jiţ bylo patrné překreslování i u graficky méně náročných aplikací, nicméně práce s nimi byla stále přijatelná. S graficky náročnými aplikacemi se práce stala velmi nepohodlnou aţ nemoţnou, zvláště při současné práci více uţivatelů.

50

Trvání (s)

Přeneseno MB

bitů/s

Uţivatel9

24 509

635

217 446

Uţivatel7

20 106

328

136 824

Uţivatel1

11 324

320

237 093

Uţivatel5

25 179

312

103 837

Uţivatel2

20 965

269

107 455

Uţivatel6

13 691

254

155 768

Uţivatel10

21 904

212

81 023

Uţivatel4

10 250

205

168 066

Uţivatel3

26 151

182

58 278

Uţivatel8

11 190

81

60 676

Tabulka 6 - Hodnoty při rychlosti 2 mbit/s

Poslední testovací den byla maximální rychlost nastavena na 2 Mbit/s, coţ uţivatelé pociťovali negativně na délce odezev u všech aplikací. Graficky nenáročné aplikace bylo moţné při této rychlosti s jistými omezeními pouţívat, nicméně graficky náročné aplikace se staly prakticky nepouţitelnými.

3.1.3 Vzniklé problémy Během testování se vyskytlo několik problémů, které bylo nutné řešit. Některé z nich bylo moţné odstranit během testu, jiné jsou systémové a jejich odstranění by si ţádalo větší zásah do infrastruktury, případně instalovaných aplikací. Mezi závaţnější problémy patří: -

Nemoţnost připojit lokální scanner. Tento problém je systémový a s pouţitím infrastruktury Remote Desktop je jediným řešením pouţití síťových scannerů.

-

Problémy s přepínáním výchozí tiskárny. Uţivatelé s připojenou lokální tiskárnou si často stěţovali na změnu výchozí tiskárny v prostředí virtuálního desktopu. Tento problém byl odstraněn přenastavením tiskového manaţeru.

51

-

Časté pády aplikace formfiller. Dle vyjádření společnosti 602.cz nepodporuje současná verze běh v terminálovém prostředí postaveném na Windows 2008 R2. Zde je jediným řešením vyčkat na aktualizovanou verzi.

-

Prostředí GNU Image Manipulation Program bylo velmi pomalé. Přes veškerou snahu se během testů nepodařilo objevit příčinu, v laboratorním prostředí se GNU Image Manipulation Program choval korektně a jeho běh byl sviţný.

-

Uţivatelé neměli oprávnění pro instalaci ActiveX rozšíření, které vyţadovali některé webové stránky. Řešením je vytvoření seznamu poţadovaných ActiveX a jejich instalace správcem serveru.

-

Problémy s absencí administrátorského oprávnění u aplikace Microsoft Visual Studio 2010.

3.1.4 Hodnocení uživatelů Na závěr byli uţivatelé poţádáni o vyhodnocení jejich práce v tomto reţimu. Uživatel1: Rychlost většinou stejná, pouze pomalejší otevírání dokumentů a ke konci testu velmi pomalé načítání map. Jak velké nepohodlí je pro Vás spouštění terminálového reţimu? Ţádné. Vidíte velký rozdíl oproti běţné práci na stanici? Nijak zásadní. Uživatel2: Zřetelně pomalejší reakce při scrollování obrazovky nebo při procházení vysunovacích roletek, v nahlíţení do mapy bylo ve druhé fázi testování výrazně pomalejší zapnutí ortofotomapy – obrázek se vykresloval postupně v pruzích, které se navíc postupně ztmavovaly; podobně tomu bylo při otvírání souborů JPG o větší velikosti (fotografie). Jak velké nepohodlí je pro Vás spouštění terminálového reţimu? Bez problému. Vidíte velký rozdíl oproti běţné práci na stanici? Ne. Uživatel3: 52

Při rychlé síti a běţné práci v zásadě rozdíl oproti práci na lokální stanici nebyl. Jak velké nepohodlí je pro Vás spouštění terminálového reţimu? Nečiní mi to problém. Vidíte velký rozdíl oproti běţné práci na stanici? Ne. Uživatel4: Změny jsem nezaznamenala. Uživatel5: Rychlost naprosto nedostačující ve všech aplikacích po celou pracovní dobu! Uživatel6: Pomalejší reakce systému. Uživatel7: Pouze částečné omezení – neměla jsem větší problémy, aţ na tisknutí mi terminálový reţim nevadil – dalo se to celkem zvládnout. Velký rozdíl není – pouze pomalejší otvírání souborů, neostré písmo. Uživatel8: Většinou jsem nepozoroval výrazné zpomalení, problém se však vyskytoval při načítání map. Velký rozdíl nevidím. Uživatel9: Subjektivní dojem: nepouţitelné pro běţnou práci – vše trvá příliš dlouho Uživatel10: Ano, rozdíl je viditelný

53

3.1.5 Vyhodnocení Testování virtuálních pracovních ploch ukázalo, ţe potřebný datový tok mezi Remote Desktop Session Host serverem v datovém centru a samotným pracovním terminálem je velice závislý na samotné činnosti, kterou uţivatel na terminálovém klientovi provádí (častá obnova obrazovky v graficky sloţitých aplikacích je náročná na přenosy dat). Tyto faktory nejvíce ovlivňují celkové nároky na jednoho uţivatele. Rychlost připojení do infrastruktury virtuální učebny je pro 10 uţivatelů terminálovém reţimu tedy alespoň 4 Mb/s. Samozřejmě platí obecně více je lépe. Dále bylo zjištěno několik dalších problémů, které úspěšnému nasazení Remote Desktop Session Host brání. Především se jedná o problémy s kompatibilitou aplikací s tímto reţimem a nemoţností přiřadit uţivatelům administrátorská oprávnění. Dalším nepřekonatelným problémem byla nemoţnost práce s lokálními zařízeními, jako jsou například scannery, čtečky čipových karet atd. Tento způsob přesunu aplikací do datacentra je tedy vhodný hlavně pro graficky málo náročné aplikace, které nevyţadují administrátorská oprávnění. Pro vybudování univerzální virtuální počítačové učebny se jedná o nevhodné řešení.

3.2 Remote Desktop Virtualization Host Druhým testovacím scénářem byl provoz celých virtuálních pracovních stanic pomocí sluţeb Remote Desktop Virtualization Host. Testovací prostředí bylo jiţ vytvořeno v rámci minulého testu, došlo tedy pouze k drobným úpravám v konfiguraci. Byly vypnuty servery Remote Desktop Session Host, zapnuty virtuální pracovní stanice VDI_01 – VDI_10 a uţivatelům bylo změněno výchozí připojení tak, aby odkazovalo na odpovídající virtuální pracovní stanici místo Remote Desktop Session Host serveru. Ostatní nastavení zůstalo nezměněno.

3.2.1 Průběh testu Test měl zcela stejný průběh jako u Remote Desktop Session Host serveru. Uţivatelé tedy byli instruováni v základním ovládání a poţádaní o vykonávání svých běţných pracovních

54

povinností. Během týdne se měřilo mnoţství přenesených dat a pozvolna se sniţovala maximální přenosová rychlost. Naměřené hodnoty jsou uvedeny v tabulkách.

55

Trvání (s) Přeneseno MB

bitů/s

Uživatel9

28506

1184

348502

Uživatel1

24908

1124

378685

Uživatel4

19759

750

318363

Uživatel8

22244

660

248792

Uživatel7

19797

516

218536

Uživatel2

26826

422

131832

Uživatel6

17755

351

165849

Uživatel5

23283

320

115333

Uživatel10

13011

290

187229

Uživatel3

13309

244

154009

Tabulka 7 - Hodnoty při rychlosti 100 Mbit/s

Trvání (s) Přeneseno MB

bitů/s

Uživatel9

28848

1090

316820

Uživatel4

16469

568

289421

Uživatel8

19939

493

207327

Uživatel1

11035

453

344259

Uživatel7

20164

438

182113

Uživatel6

26292

433

138208

Uživatel3

28239

432

128341

Uživatel5

28652

358

104848

Uživatel10

17522

326

156024

Uživatel2

12050

172

119847

Tabulka 8 - Hodnoty při rychlosti 5 Mbit/s

56

Trvání (s) Přeneseno MB

bitů/s

Uživatel1

28248

1054

312963

Uživatel4

26052

817

263110

Uživatel9

23206

730

264017

Uživatel8

19759

407

172772

Uživatel7

20331

368

151761

Uživatel6

23971

359

125643

Uživatel10

22804

353

130020

Uživatel2

23821

309

108952

Uživatel3

14961

191

106951

Uživatel5

17863

186

87374

Tabulka 9 - Hodnoty při rychlosti 4 Mbit/s

Trvání (s) Přeneseno MB

bitů/s

Uživatel9

27576

789

240015

Uživatel4

23572

616

219258

Uživatel8

24743

425

143977

Uživatel1

11155

378

284512

Uživatel10

28868

373

108350

Uživatel6

27104

338

104703

Uživatel7

17917

295

137965

Uživatel2

26739

289

90793

Uživatel5

29204

253

72811

Uživatel3

14024

163

97228

Tabulka 10 - Hodnoty při rychlosti 3 Mbit/s

57

Trvání (s) Přeneseno MB

bitů/s

Uživatel1

24496

692

237093

Uživatel9

22030

573

218196

Uživatel4

11314

269

199326

Uživatel10

21327

250

98500

Uživatel6

23279

242

87252

Uživatel8

14799

231

130888

Uživatel3

20988

221

88389

Uživatel7

10629

159

125422

Uživatel2

10214

92

75661

Uživatel5

10870

86

66192

Tabulka 11 - Hodnoty při rychlosti 2 Mbit/s

Subjektivní dojem z kvality práce při různých rychlostech přenosové linky byl shodný s předchozím testem. U niţších rychlostí tedy docházelo k viditelnému překreslování, které při rychlosti 2 Mbit/s vedlo k téměř nepouţitelnému prostředí.

3.2.2 Vzniklé problémy Vzhledem k vyuţití virtuálních desktopů nebyly zaznamenány ţádné potíţe s kompatibilitou aplikací, ani připojených lokálních USB zařízení, které byly bez problému rozeznány, nainstalovány a připraveny k pouţití.

3.2.3 Hodnocení uživatelů Na závěr byli uţivatelé opět poţádáni o vyhodnocení jejich práce v tomto reţimu a srovnání s předchozím testem. Uživatel1: Rychlost práce v aplikaci je vyšší, občasné překreslování obrazovky zůstává. Další rozdíl nepozoruji Uživatel2:

58

Lepší rychlost překreslování i při niţších rychlostech, ke konci týdne velmi pomalý tisk na lokální tiskárně. Uživatel3: Nevidím rozdíl ve srovnání s minulým testem. Uživatel4: Práce v tomto prostředí mi přijde sviţnější. Uživatel5: Rychlost je opět naprosto nedostačující! Uživatel6: Zlepšení vidím v lepších reakcích. Uživatel7: Oproti předchozímu testu bezproblémový provoz tiskáren. Uživatel8: Zůstávají problémy s vykreslováním map. Uživatel9: Pozoruji určité zrychlení, nicméně stále je to na hranici pouţitelnosti. Uživatel10: Mnohem podobnější práci na mém počítači.

3.2.4 Vyhodnocení Testování virtuálních pracovních stanic ukázalo, ţe potřebný datový tok mezi Remote Desktop Virtualization Host serverem v datovém centru a samotným pracovním terminálem je velmi podobný jako v předchozím testu. Komunikace je velmi závislá na konkrétní činnosti a 59

zobrazování pouţívané aplikace. Podstatný rozdíl můţe vzniknout při pouţívání lokálních USB zařízení, kdy můţe tisk na lokální tiskárnu velmi zatíţit linku a zpomalit tak práci všech ostatních. Tento jev se v naměřených hodnotách neprojevil, neboť v testované skupině k tiskům na lokální tiskárnu téměř nedocházelo. Proti předchozímu řešení je tento způsob pro virtuální učebnu mnohem vhodnější, neboť umoţňuje vytvoření virtuální pracovní stanice přesně na míru potřebám daného lektora a nemusí vůbec limitovat jednotlivé uţivatele. Nevhodný je pouze pro výuku v graficky náročných aplikacích při přístupu přes pomalejší datové linky, kde se projevuje efekt překreslování obrazovky.

4 Návrh řešení pomocí VMware VDI Společnost VMware nabízí pro provoz virtuálních pracovních stanic systém VMware VDI, nově přejmenované na VMware View. Tento systém je nadstavbou nad VMware vSphere, která slouţí převáţně pro virtualizaci serverové infrastruktury. Díky tomu je moţné na jednom fyzickém serveru provozovat jak virtuální servery nutné pro provoz infrastruktury, tak i samotné virtuální pracovní stanice.

4.1 VMware VDI Infrastruktura potřebná pro provoz virtuálních pracovních stanic se skládá z následujících rolí: -

Srv11: ESXi hypervizor

-

Srv12: Active Directory pro testovací prostředí

-

Srv13: VMware vCenter server spolu s View Composer server

-

Srv14: VMware Connection server

-

Srv15: VMware Security server

-

VDI_11 – VDI_20: Virtuální pracovní stanice

60

4.1.1 Příprava prostředí Srv11 – ESXi hypervizor Parametry serveru: CPU: 2 x Intel Xeon 2,66Ghz RAM: 48 GB HDD: 4 x 146 GB SAS 10k Operační systém: ESXi hypervizor 5.0 Na fyzickém serveru bylo nakonfigurováno síťové rozhraní se dvěma LAN adaptéry, kdy jeden byl zapojen přímo do lokální sítě a druhý přes router Cisco. Následně byly nakonfigurovány disky do pole RADI5, čímţ vznikl diskový prostor o velikosti cca 420 GB, na který proběhla instalace operačního systému. Při instalaci bylo zvoleno výchozí rozdělení diskového prostoru, čímţ zůstalo přibliţně 400 GB na VMFS oddílu pro umístění virtuálních strojů. Instalace hypervizoru ESXi dále proběhla s výchozími volbami.13 Po instalaci byla provedena konfigurace pomocí VMware vSphere Clienta. Při této konfiguraci došlo k nastavení virtuálních switchů a jejich přiřazení k síťovým adaptérům. Jeden adaptér byl opět vyhrazen pro komunikaci přes router Cisco a druhý pro veškerou ostatní. Vzhledem k omezenému mnoţství síťových adaptérů nebylo moţné provést konfigurace podle doporučení společnosti VMware, nicméně na plánované testy nemá pouţité zapojení vliv. Srv12: Active Directory pro testovací prostředí Stejně jako v minulém testu bylo přikročeno k instalaci dočasného Active Directory pro testovací účely. Z tohoto důvodu byl vytvořen Srv12, na kterém byla nakonfigurována role Active Directory a vytvořena nová subdoména vditest. Vzhledem k instalaci do virtuálního

13

ESXi – Partitions layout of system disk [online]. 2011 http://vinfrastructure.it/en/2011/12/esxi-partitions-layout-of-system-disk/

61

[cit.

2012-04-24].

Dostupné

z:

prostředí vytvořeného serverem Srv11 bylo nutné nakonfigurovat nový virtuální stroj s následujícími parametry: Parametry serveru: CPU: 1 jádro RAM: 4 GB HDD: 40 GB dynamický Operační systém: Windows Server 2008 R2 Enterprise Instalované role: Active Directory Pomocí konzole VMware vSphere Client byl spuštěn průvodce New Virtual Machine, do kterého byly zadány výše uvedené parametry. Po jeho dokončení systém vygeneruje prázdný virtuální stroj, do kterého je nutné nainstalovat operační systém. V produkčním prostředí se pro tuto činnost zpravidla pouţívají předpřipravené šablony s jiţ nainstalovanými systémy, v tomto prostředí však k jejich tvorbě nedošlo. Po instalaci operačního systému došlo k jeho zařazení do jiţ existující domény a instalaci role Active Directory.

Jakmile byla role

nainstalována, došlo k aktualizaci celého systému následovaného restartem. V tento okamţik bylo moţné vytvořit novou Active Directory subdoménu vditest spuštěním příkazu DCPROMO, který vyvolá konfiguračního průvodce. Po jeho dokončení byl server připraven poskytovat funkcionalitu Active Directory pro celou testovací infrastrukturu v subdoméně vditest. Srv13: VMware vCenter server spolu s View Composer server VMware vCenter Server je centrálním řídícím bodem celé VMware infrastruktury, je tedy vhodné jej nainstalovat co nejdříve a další konfiguraci provádět pomocí něho. Parametry serveru: CPU: 1 jádro RAM: 4 GB 62

HDD: 40 GB dynamický Operační systém: Windows Server 2008 R2 Enterprise Instalované role: Microsoft SQL Server 2008 R2 Express, Microsoft .NET 3.5 SP1 Framework, VMware vCenter Server, View Composer Po vytvoření virtuálního stroje a instalaci operačního systému Windows Server 2008 R2 včetně posledních aktualizací byla nainstalována SQL databáze Microsoft SQL Server 2008 R2 Express, která je nutná pro běh VMware vCenter Serveru. Následovala instalace Microsoft .NET 3.5 SP1 Framework a její poslední aktualizace. Na takto připraveném serveru byla spuštěna instalace VMware vCenter Serveru. Při instalaci byla zvolena SQL databáze běţící na lokálním stroji. V dalším kroku byl zvolen reţim standalone, neboť Linked reţim s vysokou dostupností nebyl pro testovací prostředí vyţadován. Další parametry byly ponechány ve výchozím stavu a instalace byla dokončena. Po dokončení instalace byl VMware vSphere Client odpojen od VMware ESXi hypervizoru a připojen k nově vytvořenému VMware vCenter Serveru. V něm byl spuštěn průvodce Add new host, ve kterém bylo nakonfigurováno spojení s VMware ESXi hypervizorem a tím se dal následně spravovat. Veškerá další konfigurace virtualizační infrastruktury tak nadále probíhala výhradně přes tento VMware vCenter Server. Další instalovanou rolí byl View Composer. Při jeho instalaci byla taktéţ zvolena SQL databáze běţící na lokálním stroji a ostatní parametry byly ponechány na výchozích hodnotách. Srv14: VMware Connection server VMware Connection server není vhodné instalovat na server spolu s jinou rolí, neboť pro svůj běh vyţaduje lokální LDAP databázi, u které je doporučován samostatný běh. Parametry serveru: CPU: 1 jádro RAM: 4 GB

63

HDD: 40 GB dynamický Operační systém: Windows Server 2008 R2 Enterprise Instalované role: VMware Connection server Instalace VMware Connection serveru byla spuštěna na nově vytvořeném virtuálním serveru s Windows 2008 R2. Během instalace byly zadány informace o testovacím VMware vCenter Serveru a ostatní parametry byly ponechány ve výchozím stavu. Srv15: VMware Security server VMware Security server slouţí pro zabezpečení připojení jednotlivých uţivatelů. V praxi je doporučena instalace do DMZ, pro účely testu bylo od této konfigurace ovšem upuštěno. Parametry serveru: CPU: 1 jádro RAM: 4 GB HDD: 40 GB dynamický Operační systém: Windows Server 2008 R2 Enterprise Instalované role: VMware Security server Stejně jako v předešlých případech byl vytvořen virtuální stroj, na který byl nainstalován systém Windows 2008 R2 a plně aktualizován. Následovala instalace VMware Security serveru, během které byly zadány parametry jiţ existující infrastruktury. VDI_11 – VDI_20: Virtuální pracovní stanice Příprava operačního systému pro běh v reţimu virtuální pracovní stanice na platformě VMware VDI má jistá specifika, která je vhodná dodrţet. Jedná se například o instalaci VMware View agenta, zakázání vybraných sluţeb a další drobné optimalizace. Parametry stanice:

64

CPU: 1 jádro RAM: 2 GB HDD: 40 GB dynamický Operační systém: Windows 7 Enterprise 64 bit Po vytvoření virtuální pracovní stanice následovala instalace operačního systému Windows 7 Enterprise a jeho aktualizace. Pro lepší integraci s virtualizační platformou VMware byly do operačního systému doinstalovány VMware tools a VMware View agent. Virtuální pracovní stanice byla následně přiřazena do testovací domény Active Directory. Následně byla virtuální pracovní stanice nakonfigurována podobným způsobem jako klasická pracovní stanice. Došlo tedy k instalaci aplikací a jejich konfiguraci pro jednotlivé uţivatele. Následovala instalace a konfigurace vybraných síťových tiskáren a konfigurace sluţeb. Pomocí konzole services.msc bylo zakázáno spouštění následujících sluţeb14: BitLocker Drive Encryption Service, Block Level Backup Engine Service, Session Manager, Disk Defragmenter, Diagnostic Policy Service, Home Group Listener, Home Group Provider, Microsoft iSCSI Initiator Service, Microsoft Software Shadow Copy Provider, Secure Socket Tunneling Protocol Service, Security Center, Superfetch, Tablet PC Input Service, UPnP Host Service, Volume Shadow Copy Service, Windows Backup, Windows Error Reporting Service, Windows Media Center Receiver Service,Windows Media Center Scheduler Service, WLAN AutoConfig, WWAN AutoConfig, SSDP Discovery. Jakmile byla takto vytvořená virtuální pracovní stanice plně funkční, přistoupilo se k jejímu začlenění do VMware VDI infrastruktury pomocí průvodce VMware View administrator a k jejímu přiřazení konkrétnímu uţivateli. Uživatelské stanice

14

VMware View Optimization Guide for Windows 7 [online]. 2012 [cit. 2012-04-24]. Dostupné z: http://www.vmware.com/resources/techresources/10157

65

Na plochu pracovní stanice uţivatelů, kteří byli vybráni pro testování, byl nakopírován zástupce klienta VMware View Client a v něm přednastavena adresa pro připojení k VMware View Connection serveru.

4.1.2 Průběh testu Stejně jako v předchozích testech byli uţivatelé zaškoleni v práci s virtuálním desktopem a poţádáni a vykonávání své práce. Celý týden se měřila náročnost na přenesená data a postupně se sniţovala rychlost na cílové 2 Mbit/s. Naměřené hodnoty jsou v tabulkách. Trvání (s) Přeneseno MB

bitů/s

Uživatel4

19216

729

318363

Uživatel7

23746

567

200325

Uživatel10

24858

555

187229

Uživatel9

15509

535

289275

Uživatel8

17689

525

248792

Uživatel1

10003

352

295352

Uživatel5

25450

321

105722

Uživatel6

16162

320

165849

Uživatel3

11495

230

168010

Uživatel2

12729

183

120846

Tabulka 12 - Hodnoty při rychlosti 100 Mbit/s

Z naměřených dat u vyuţití protokolu PCoIP je patrný pokles jednotlivých datových toků proti předešlým řešením, které vyuţívala protokol RDP. U nejnáročnějších uţivatelů se rychlost pohybovala kolem 300 Kbit/s, coţ představuje zhruba čtvrtinový pokles. Při rychlosti datové linky 100 Mbit/s bylo praticky nemoţné rozeznat práci na vzdálené virtuální pracovní stanici od práce na lokální stanici.

66

Trvání (s) Přeneseno MB

bitů/s

Uživatel9

27378

787

241062

Uživatel8

23315

629

226175

Uživatel6

29256

482

138208

Uživatel4

12701

402

265302

Uživatel10

21475

399

156024

Uživatel7

20001

398

166937

Uživatel1

10542

337

268502

Uživatel3

18128

303

140008

Uživatel5

27105

285

88102

Uživatel2

12922

169

109860

Tabulka 13 - Hodnoty při rychlosti 5 Mbit/s

Po sníţení rychlosti na 5 Mbit/s byl zřetelný pokles grafického výkonu pouze u graficky náročných aplikací. Tento pokles se ovšem neprojevoval pomalejším překreslováním plochy, nýbrţ jejím lehkým rozmazáním v částech kde docházelo k překreslování a následným „doostřením“. Tento efekt byl subjektivně vyhodnocen jako mnohem méně rušivý, neţ pomalejší překreslování celé obrazovky v případě protokolu RDP. Trvání (s) Přeneseno MB

bitů/s

Uživatel1

28364

825

244092

Uživatel9

26120

626

200885

Uživatel8

23379

525

188479

Uživatel4

19788

522

221085

Uživatel6

25322

379

125643

Uživatel7

20161

334

139114

Uživatel10

20523

318

130020

Uživatel3

19097

290

127280

Uživatel5

26467

232

73418

Uživatel2

11576

138

99873

Tabulka 14 - Hodnoty při rychlosti 4 Mbit/s

67

V tomto testovacím dni byla rychlost sníţena na 4 Mbit/s, coţ mělo proti předchozímu dni téměř neznatelné následky. Rozdíl byl patrný pouze v lehce pomalejším doostření graficky náročných aplikací, které ovšem nemělo vliv na kvalitu práce. Trvání (s) Přeneseno MB

bitů/s

Uživatel4

24134

530

184238

Uživatel8

25090

512

171344

Uživatel9

25559

510

167404

Uživatel10

28973

408

118200

Uživatel1

13371

324

203410

Uživatel3

25129

318

106067

Uživatel6

23681

296

104703

Uživatel2

16710

166

83227

Uživatel7

10907

151

115929

Uživatel5

11822

86

61182

Tabulka 15 - Hodnoty při rychlosti 3 Mbit/s

Při rychlosti 3 Mbit/s byla jiţ práce s graficky náročnými aplikacemi poměrně nepohodlná. Práce s ostatními aplikacemi byla nadále bez problémů. Trvání (s) Přeneseno MB

bitů/s

Uživatel9

22446

373

139504

Uživatel4

18515

339

153531

Uživatel1

16562

335

169509

Uživatel10

24743

317

107455

Uživatel3

22508

237

88389

Uživatel6

18926

215

95184

Uživatel2

23856

197

69356

Uživatel7

16722

193

96607

Uživatel8

10763

183

142787

Uživatel5

27421

167

50985

Tabulka 16 - Hodnoty při rychlosti 2 Mbit/s

68

Konečná rychlost 2 Mbit/s představovala značný problém pro graficky náročné aplikace, kdy jejich vykreslení zabralo zpravidla nepříjemně dlouho dobu. S graficky nenáročnými aplikacemi byla práce nadále moţná a nepůsobila rušivě.

4.1.3 Vzniklé problémy Stejně jako v případě virtuální infrastruktury postavené na Microsoft Virtualization Host nebyly zaznamenány ţádné potíţe s kompatibilitou aplikací, ani připojených lokálních USB zařízení, které byly bez problému rozeznány, nainstalovány a připraveny k pouţití.

4.1.4 Hodnocení uživatelů Po dokončení testů byli uţivatelé opět poţádáni o subjektivní hodnocení a srovnání s předchozím řešením. Uživatel1: Proti minulému testu vidím rozdíl pouze v jiném zobrazování, které mi přijde lepší. Chování je jinak stejné. Uživatel2: Vykreslování map a fotografií bylo o poznání lepší neţ v předešlých případech. Pomalejší bylo spouštění aplikací. Uživatel3: Všechny tři testy mi přišly velmi podobné. Nejlepší byl asi test druhý, kde mi přišla reakce aplikací nejvyšší. Uživatel4: Obrázky se vykreslovaly postupně, u ostatních aplikací mi přišlo zobrazení stejné. Uživatel5: Obraz byl často rozmazaný, aplikace se spouštěly velmi pomalu ve všech testech.

69

Uživatel6: Nejlepší výsledky byly v posledním testu. Aplikace se mi spouštěly velmi sviţně i jejich zobrazení bylo bez problémů. Uživatel7: Ani v tomto testu jsem nezaznamenala problémy s tiskem. Naopak se mi zdálo mírně rozmazané některé písmo – jiné bylo bez problémů. Uživatel8: Ve všech třech testech vidím největší problém se zobrazením ortofotomap. Uživatel9: Ani v jednom z případu se nejednalo o plnohodnotnou náhradu mého počítače. Práce je pomalá. Uživatel10: Poslední verze mi přišla nejfunkčnější.

4.1.5 Vyhodnocení Pracovní stanice virtualizované pomocí VMware VDI infrastruktury ze se systémového a aplikačního hlediska chovaly stejně jako stanice virtualizované pomocí Microsoft Remote Desktop Virtualization Host. Nedocházelo k problémům s kompatibilitou a po funkční stránce jsou schopny plně nahradit fyzické pracovní stanice. Podstatný rozdíl byl v protokolu, který se vyuţívá pro připojení k virtuálním pracovním stanicím. Protokol PCoIP se ukázal jako úspornější co se týče datové náročnosti a zároveň uţivatelsky příjemnější při plném vytíţení linky.

70

5 Srovnání obou řešení 5.1 Microsoft Během testů byly odzkoušeny dvě řešení postavené na virtualizačních produktech společnosti Microsoft a jedno řešení postavené na produktech společnosti VMware. Řešení postavené na Microsoft Remote Desktop Session Host serverech se ukázalo jako nevhodné pro svá omezení. Jednalo se o nemoţnost uţivateli přidělit administrátorská oprávnění, poskytnout mu větší moţnosti v konfiguraci parametrů operačního systému a v nemoţnosti provozovat lokální USB zařízení. Dalším podstatným problémem byla kompatibilita aplikací s tímto reţimem provozu. Některé naráţely na problémy s absencí administrátorských oprávnění, jiným způsobovalo potíţe několik současných spuštění stejné aplikace na jednom serveru pod různými uţivateli. Toto řešení je tedy vhodné pro práci s nenáročnými aplikacemi, které jsou pro běh v tomto prostředí optimalizované. Microsoft Virtualization Host si na druhé straně vedl o poznání lépe. Nebyly zjištěny ţádné potíţe s kompatibilitou aplikací, uţivatelům mohlo být přiděleno administrátorské oprávnění umoţňující přizpůsobení virtuálního desktopu jejich poţadavkům. Další výhodou je moţnost vytvoření různých virtuálních pracovních stanic dle nároků konkrétních uţivatelů. Je tedy moţné vytvořit virtuální pracovní stanice pro běţnou kancelářskou činnost, kterým bude přiděleno méně hardwarových zdrojů. Zároveň je moţné vytvořit virtuální pracovní stanice, které budou mít dostatek přidělených zdrojů na běh velmi náročných aplikací. Tento přístup by u Microsoft Remote Desktop Session Host serverů vyţadoval vytvoření oddělené serverové farmy pro různě náročné aplikace. Vybudování virtualizační infrastruktury postavené na technologiích Microsoftu se ovšem během testů ukázalo jako poměrně náročné. Jednotlivé části jsou spíše univerzální a jejich integrace do funkčního celku vyţaduje značné manuální úpravy v konfiguracích jak jednotlivých serverů, jejich rolí, tak i virtuálních pracovních stanic. Celkově se toto řešení ukázalo jako funkční, nicméně ne zcela optimální pro nasazení do produkčního prostředí.

71

5.2 VMware Pro vytvoření infrastruktury virtuálních pracovních stanic nabízí společnost VMware software VMware VDI. Instalace a konfigurace VMware VDI infrastruktury je poměrně snadná, neboť jednotlivé součásti jsou optimalizované pro daný účel a není nutná jejich zdlouhavá a sloţitá konfigurace. V případě poţadavku na sloţitější konfiguraci však poskytuje dostatek moţností celé prostředí přizpůsobit na míru. Jedná se například o tvorbu linkovaných klonů, kde se jednotlivé pracovní stanice dynamicky vytvářejí z jediného původního obrazu, automaticky se přidávají do domény a pomocí aplikace ThinApp jsou schopny spouštět připravené aplikace. Podstatnou výhodou VMware VDI je pouţití protokolu PCoIP, který se v testech ukázal jako podstatně výhodnější, co se týče náročnosti na datové linky. Má menší datovou náročnost a při plném vytíţení linky bylo jeho chování subjektivně hodnoceno pozitivněji neţ u protokolu RDP.

72

Závěr V průběhu této práce jsem vytvořil tři testovací prostředí, abych ověřil jejich pouţitelnost pro vytvoření počítačové učebny v cloudu. První dvě byla postavena na produktech společnosti Microsoft a třetí na produktech společnosti VMware. Řešení postavené na Microsoft Remote Desktop Session Host serverech (dříve označované jako terminálový server) se pro toto nasazení ukázalo jako nevhodné. Nesplnilo funkcionality, které jsou pro plné vyuţití v podobě virtuální počítačové učebny klíčové. Technologie Microsoft Remote Desktop Virtualization Host předpoklady splnila a lze ji pro vybudování virtuální učebny pouţít. Její slabá místa spatřuji v pouţití protokolu RDP, ve sloţitější přípravě celé infrastruktury a menších moţnostech konfigurace v případě potřeby. Pokud bude zajištěna dostatečná konektivita mezi virtuální infrastrukturou a klientem a nebudou kladeny vysoké nároky na speciální konfiguraci, lze toto řešení doporučit. Poslední testovanou variantou byla virtuální infrastruktura VMware VDI. Jedná se o vyspělou technologii s širokými moţnostmi konfigurace. Základní instalace je poměrně snadná a rychlá, ale v případě potřeby je moţné provádět detailní nastavení a vše tak přizpůsobit konkrétním poţadavkům. Další výhodou je vyuţití protokolu PCoIP, který má menší nároky na datovou konektivitu a je tak vhodný pro přístup k virtuálním pracovním stanicím přes méně kvalitní linky. Obě řešení splní poţadovaný cíl, kterým je zrušení počítačových učeben v jejich současném běţném provedení. Tyto učebny jsou poměrně náročné na správu, neumoţňují jednoduše měnit prostředí dle poţadavků na výuku a vyţadují pravidelnou obnovu. Virtuální počítačová učebna můţe být vybudována ve vlastním datovém centru, nebo pořízena formou sluţby od externího poskytovatele. V tomto případě jsou předem známy veškeré náklady a případná rizika přecházejí na stranu poskytovatele.

73

Seznam použité literatury: 1. ZENDULKA, J. Architektura klient/server a třívrstvá architektura [online]. 2012 [cit. 2012-04-24]. Dostupné z: http://www.fit.vutbr.cz/study/courses/DSI/public/pdf/nove/10_clsrv.pdf 2. KLÁPŠTĚ, Pavel. Software v nabídce sluţeb: Bakalářská práce. Praha: Bankovní institut vysoká škola, 2010. 55 s. 3. Microsoft Windows Server 2008 R2 Hyper-V Overview. MICROSOFT [online]. 2010 [cit. 2012-04-24]. Dostupné z: http://www.microsoft.com/en-us/servercloud/windows-server/hyper-v-overview.aspx 4. Overview of Remote Desktop Session Host (RD Session Host). MICROSOFT. Microsoft Technet [online]. 2010 [cit. 2012-04-24]. Dostupné z: http://technet.microsoft.com/en-us/library/cc742806.aspx 5. VMware Products. VMWARE. VMware Products [online]. 2010 [cit. 2012-04-24]. Dostupné z: http://www.vmware.com/products 6. Unified Computing and Servers [online]. 2012 [cit. 2012-04-24]. Dostupné z: http://www.cisco.com/en/US/products/ps10265/technology.html 7. Installing Hyper-V on Windows Server 2008 R2 [online]. 2012 [cit. 2012-04-24]. Dostupné z: http://www.petri.co.il/installing-hyper-v-on-windows-server-2008-r2.htm 8. Windows Server 2008 R2 Remote Desktop (RD) Services [online]. 2012 [cit. 201204-24]. Dostupné z: http://www.techotopia.com/index.php/Windows_Server_2008_R2_Remote_Desktop_ (RD)_Services 9. Deploying a Windows Server 2008 R2 Remote Desktop Server Farm using RD Connection Broker [online]. 2012 [cit. 2012-04-24]. Dostupné z: http://www.techotopia.com/index.php/Deploying_a_Windows_Server_2008_R2_Rem ote_Desktop_Server_Farm_using_RD_Connection_Broker 10. Configuring Windows Server 2008 RD Web Access [online]. 2012 [cit. 2012-04-24]. Dostupné z: http://www.techotopia.com/index.php/Configuring_Windows_Server_2008_RD_Web _Access

74

11. Building a Remote Desktop Gateway (RDG) / RD Gateway Server [online]. 2012 [cit. 2012-04-24]. Dostupné z: http://www.rayheffer.com/953/building-a-remote-desktopgateway-rdg-rd-gateway-server/ 12. Building VDI using Remote Desktop Services (RDS) [online]. 2010 [cit. 2012-04-24]. Dostupné z: http://www.ms4u.info/2010/03/part-1-building-vdi-using-remote.html 13. ESXi – Partitions layout of system disk [online]. 2011 [cit. 2012-04-24]. Dostupné z: http://vinfrastructure.it/en/2011/12/esxi-partitions-layout-of-system-disk/ 14. VMware View Optimization Guide for Windows 7 [online]. 2012 [cit. 2012-04-24]. Dostupné z: http://www.vmware.com/resources/techresources/10157

75

Seznam tabulek Tabulka 1 - nastavení RDP klienta ........................................................................................... 47 Tabulka 2 - Hodnoty při rychlosti 100 Mbit/s .......................................................................... 48 Tabulka 3 - Hodnoty při rychlosti 5 Mbit/s .............................................................................. 49 Tabulka 4 - Hodnoty při rychlosti 4 Mbit/s .............................................................................. 49 Tabulka 5 - Hodnoty při rychlosti 3 Mbit/s .............................................................................. 50 Tabulka 6 - Hodnoty při rychlosti 2 mbit/s .............................................................................. 51 Tabulka 7 - Hodnoty při rychlosti 100 Mbit/s .......................................................................... 56 Tabulka 8 - Hodnoty při rychlosti 5 Mbit/s .............................................................................. 56 Tabulka 9 - Hodnoty při rychlosti 4 Mbit/s .............................................................................. 57 Tabulka 10 - Hodnoty při rychlosti 3 Mbit/s ............................................................................ 57 Tabulka 11 - Hodnoty při rychlosti 2 Mbit/s ............................................................................ 58 Tabulka 12 - Hodnoty při rychlosti 100 Mbit/s ........................................................................ 66 Tabulka 13 - Hodnoty při rychlosti 5 Mbit/s ............................................................................ 67 Tabulka 14 - Hodnoty při rychlosti 4 Mbit/s ............................................................................ 67 Tabulka 15 - Hodnoty při rychlosti 3 Mbit/s ............................................................................ 68 Tabulka 16 - Hodnoty při rychlosti 2 Mbit/s ............................................................................ 68

76