Vysoká škola ekonomická v Praze

Vysoká škola ekonomická v Praze Fakulta informatiky a statistiky Katedra informačních technologií

Student : Jakub Jáchym Vedoucí bakalářské práce : Ing. Luboš Pavlíček Oponent bakalářské práce : doc. Ing. Norbert Žid, CSc.

TÉMA BAKALÁŘSKÉ PRÁCE

Využití virtuální stanice pro testování sítě

ROK: 2010

Čestné prohlášení Prohlašuji, ţe jsem tuto bakalářskou práci zpracoval samostatně a ţe jsem uvedl všechny pouţité prameny a literaturu, ze kterých jsem čerpal.

V Praze dne 8. 12. 2010

..................................................... Jakub Jáchym

2

Poděkování Děkuji vedoucímu mé bakalářské práce Ing. Lubošovi Pavlíčkovi, za odborné připomínky při psaní této bakalářské práce. Dále bych rád poděkoval mé rodině a přátelům za pomoc a podporu, kterou mi poskytli při jejím psaní.

3

Abstrakt Tato práce pojednává o vyuţití virtuální stanice pro testování sítě. Práce je rozdělena na dvě části – na teoretickou část a na případovou studii. Teoretická část pojednává o dvou tématech. Nejprve jsou popsány způsoby a typy virtualizace, následuje krátký popis fyzické a virtuální lokální sítě. Část o virtualizaci zakončuje popis produktů pro virtualizaci serverů od tří úspěšných společností na virtualizačním trhu a jejich krátké srovnání. Druhá část se zabývá testováním sítě. Zde jsou popsány charakteristiky sítě, které je vhodné testovat. V případové studii je popsána instalace jednoho vybraného produktu pro virtualizaci serveru. Na tomto serveru je poté spuštěno několik virtuálních stanic. Jedna virtuální stanice slouţí pro testování sítě LAN, do které je připojena, ostatní stanice generují provoz v této síti.

4

Abstract This work deals with using a virtual station for network testing. The work is segmented into two parts – a theory and a case study. The theory covers two topics. Virtualization methods and types are described first; short descriptions of physical and virtual local networks follow. The virtualization part concludes with a description and a short comparison of server virtualization products by three successful companies on a virtualization market. The second part addresses the network testing. Network attributes appropriate for testing are described therein. The case study describes an installation of a selected server-virtualization product. Then several virtual stations are run on the server. One virtual station is used for testing of a local area network which it is connected to; the other stations generate traffic in the network.

5

Obsah Abstrakt ........................................................................................................................ 4 Abstract ........................................................................................................................ 5 Úvod ............................................................................................................................. 8 1

2

3

4

Způsoby virtualizace .............................................................................................. 9 1.1

Bare-metal virtualizace .................................................................................... 9

1.2

Hostovaná virtualizace .................................................................................. 10

Typy virtualizace ................................................................................................. 11 2.1

Emulace ........................................................................................................ 11

2.2

Plná virtualizace ............................................................................................ 11

2.3

Paravirtualizace ............................................................................................. 12

2.4

Virtualizace na úrovni jádra operačního systému ........................................... 14

2.5

Aplikační virtualizace.................................................................................... 15

Virtuální sítě ........................................................................................................ 16 3.1

Fyzická LAN ................................................................................................. 16

3.2

Virtuální LAN ............................................................................................... 17

3.3

Připojení do VLAN ....................................................................................... 18

Virtualizace – softwarová řešení .......................................................................... 20 4.1

Citrix Systems ............................................................................................... 20 4.1.1

4.2

Microsoft ...................................................................................................... 22 4.2.1

4.3

5

Hyper-V Server 2008 R2............................................................. 23

VMware ........................................................................................................ 24 4.3.1

4.4

Citrix XenServer ......................................................................... 20

VMware vSphere Hypervisor 4.1.0 ............................................. 24

Srovnání produktů ......................................................................................... 26

Testování sítě ....................................................................................................... 28 5.1

Propustnost sítě (throughput) ......................................................................... 28 6

6

5.2

Zpoţdění (latency) ........................................................................................ 28

5.3

Míra ztrátovosti rámců .................................................................................. 29

5.4

Zpracování navazujících rámců ..................................................................... 29

5.5

Rychlost obnovy systému po přetíţení ........................................................... 30

5.6

Rychlost obnovy systému po resetu ............................................................... 30

5.7

Analýza paketů (packet sniffing) ................................................................... 30

Případová studie .................................................................................................. 32 6.1

Úvod ............................................................................................................. 32

6.2

Parametry fyzického serveru ......................................................................... 32

6.3

Virtuální server ............................................................................................. 32

6.4

Virtuální stanice ............................................................................................ 33

6.5

Příprava síťového prostředí pro testování ...................................................... 35

6.6

Vyuţití virtuální stanice pro testování sítě ..................................................... 38

6.7

6.6.1

Test propustnosti sítě .................................................................. 38

6.6.2

Test zpoţdění a míry ztrátovosti rámců ....................................... 39

6.6.3

Analýza paketů ........................................................................... 40

Závěr ............................................................................................................. 42

Závěr .......................................................................................................................... 43 Slovník pojmů ............................................................................................................ 45 Pouţité zdroje ............................................................................................................. 47

7

Úvod S rostoucím počtem počítačů (a ostatních tzv. „chytrých“ zařízení), roste i potřeba výměny dat mezi nimi, která by ideálně měla být rychlá, spolehlivá a neměla by být závislá na geografickém umístění zdroje a cíle. Tato potřeba vedla v posledních letech k rozmachu počítačových sítí – od malých domácích, kde jdou navzájem propojené dva počítače, po velké korporátní, kde počet propojených strojů můţe bez problémů dosahovat několika set. Rozvoj počítačových sítí vedl i k rozšíření sluţeb, které jsou jejich prostřednictvím poskytovány. Díky tomu se stále zvětšuje počet serverů, které tyto sluţby zajišťují. Pokud je kaţdý server (myšleno fyzický stroj) určen pro poskytování pouze jedné, případně omezeného (malého) počtu sluţeb, dochází k neefektivnosti ať jiţ z ekonomického hlediska (více strojů vyţaduje větší investici do pořízení a údrţby), tak ekologického (větší spotřeba elektrické energie na provoz a chlazení). Přitom většina poţadavků na serveru je vybavena rychle a zbytek času server „zahálí“. Z tohoto důvodu se v posledních letech přistupuje k virtualizaci serverů (ale i pracovních stanic, nebo samotného síťového prostředí), kdy nám virtuální server umoţní provozovat na jednom fyzickém stroji několik nezávislých virtuálních strojů, které pracují podobně výkonně, jako by běţely na samostatných fyzických serverech, ale s podstatnou úsporou elektrické energie i finančních prostředků. S integrací sítí do kaţdodenního ţivota souvisí i další problém a to zajištění dostupnosti poskytovaných sluţeb. Z tohoto důvodu je téměř nutností monitorovat a testovat parametry síťového prostředí. V této práci nejprve uvedu základní informace o virtualizaci, včetně virtualizace síťového prostředí. Dále popíši některá řešení pro virtualizaci serverů, nastíním základní metody pro testování sítě a v případové studii vytvořím na virtuálním serveru virtuální pracovní stanici, prostřednictvím které budu testovat ostatní stanice v lokální síti.

8

1 Způsoby virtualizace Standardně, pokud nevyuţíváme virtualizaci, lze PC rozdělit do tří vrstev – hardwarová vrstva, operační systém a aplikace.

Obrázek 1: Schéma základního rozdělení PC (bez virtualizace)

Chceme-li zavést virtualizaci, můţeme – jak vyplývá z předchozího obrázku – virtualizační vrstvu „vloţit“ do jedné ze dvou oblastí. Pokud zavedeme virtualizaci mezi hardwarovou vrstvu a operační systém, hovoříme o bare-metal virtualizaci a virtualizační vrstvu nazýváme hypervisor prvního typu, pokud virtualizaci zavedeme mezi operační systém a aplikace, pak se jedná o hostovanou virtualizaci a virtualizační vrstvu nazýváme hypervisor druhého typu.

1.1

Bare-metal virtualizace Pokud implementujeme virtualizační vrstvu hned nad hardwarovou vrstvu, ho-

voříme o bare-metal virtualizaci (z anglického „bare metal“ = „holé ţelezo“).

Obrázek 2: Schéma bare-metal architektury

V případě této virtualizace neexistuje hostitelský operační systém. Jeho funkci plně nahrazuje hypervisor, který obsahuje všechny potřebné instrukce pro práci s procesorem i pamětí. Z důvodu absence hostitelského operačního systému a z nutnosti správy hypervisoru (vytváření, modifikace, ovládání, apod. virtuálních strojů) je vţdy jeden virtuální stroj privilegovaný k těmto úkonům. Hypervisor prvního typu dále rozdělujeme na monolitický hypervisor, kdy virtuální vrstva emuluje hardware a virtuálním stanicím poskytuje k tomuto hardwaru přístup 9

přes vlastní ovladače, a na microkernel1 hypervisor, kdy ovladače k fyzickému hardwaru obsahuje aţ hostovaný operační systém a hypervisor zajišťuje, aby jednotlivé virtuální stanice nepřistupovaly ke stejnému hardwaru ve stejný okamţik.

1.2 Hostovaná virtualizace Je-li virtualizační vrstva provozována na jiţ existujícím operačním systému, hovoříme o hostované virtualizaci. Operační systém, na kterém je nainstalována virtualizační vrstva, se nazývá hostitelský operační systém 2. Operační systém virtuálního stroje se nazývá hostovaný operační systém3.

Obrázek 3: Schéma hostované architektury

Přístup virtuálního stroje k fyzickému hardwaru, mnoţství a druh hardwaru, který je emulován, to vše je dáno typem virtualizace. Základní typy virtualizace jsou popsány v kapitole 2.

1 2 3

Česky „mikro jádro“ Anglicky „Host OS“ Anglicky „Guest OS“

10

2 Typy virtualizace Existuje více typů virtualizace, kdy kaţdý typ odděluje více či méně fyzické zdroje – hardware – od virtuálního prostředí. Podívejme se nyní blíţe na jednotlivé typy.

2.1 Emulace Emulace (někdy označována jako simulace) je typ virtualizace, který umoţňuje provozovat na fyzickém, tzv. hostitelském stroji4, takový virtuální, tzv. hostovaný stroj5, který má naprosto odlišnou architekturu. Co to znamená? Pomocí emulace můţeme na hostitelském stroji – typicky klasické PC – spustit aplikace, které byly primárně napsány pro naprosto odlišné zařízení, například pro staré 8 bitové ZX Spectrum, nebo moderní herní konzole typu Playstation apod. Jak toho docílíme? Emulátor6 musí vytvořit virtuální procesor, včetně registrů a instrukční sady emulovaného zařízení, dále paměť ROM a také zbytek hardwaru, který emulované zařízení pouţívá. To ovšem vyţaduje rozsáhlé znalosti o emulovaném zařízení, které se většinou dají zjistit pouze prostřednictvím reverzního inţenýrství, coţ je „proces analýzy předmětného systému s cílem identifikovat komponenty systému a jejich vzájemné vazby a/nebo vytvořit reprezentaci systému v jiné formě nebo na vyšší úrovni abstrakce“ [1]. Vzhledem k rozdílnosti architektur obou systémů, musí emulátor překládat všechny instrukce pro práci s procesorem, pamětí i vstupně-výstupními zařízeními. Tento postup je zcela pochopitelně velice náročný na systémové zdroje, proto je emulace nejméně efektivní způsob virtualizace. Na druhou stranu je to ovšem také jediný způsob, jak skloubit dvě rozdílné architektury.

2.2 Plná virtualizace Plná virtualizace, někdy nazývána nativní virtualizace, je obdobou emulace s tím rozdílem, ţe se neemuluje procesor jiné architektury, neţ je procesor hostitelského systému. Také se neemuluje celý hardware virtuálního stroje, ale pouze některý hardware a 4

5

6

Hostitelský stroj je fyzický stroj, který je tvořen reálným hardwarem (tedy např. klasické PC) a který má k tomuto hardwaru výhradní přístup. Na hostitelském stroji jsou spouštěny virtualizační nástroje a teprve jejich prostřednictvím dochází k vytvoření virtuálních (tzv. hostovaných) strojů. Hostovaný stroj je virtuální stroj, který vyuţívá prostřednictvím virtualizačních nástrojů hardware hostitelského stroje. Aplikace zajišťující emulaci virtuálního stroje na fyzickém stroji

11

to takový, aby byl umoţněn běh neupraveného operačního systému hostovaného stroje. Při uţití tohoto typu virtualizace je hostovaný systém důsledně oddělený od fyzické vrstvy a nemůţe tedy zjistit, ţe nemá přístup ke „skutečnému“ hardwaru. Stejná architektura obou strojů, tj. jak hostitelského tak hostovaného, odstraňuje reţii spojenou s překladem instrukcí mezi procesory hostitelského a hostovaného stroje, virtualizačnímu nástroji stačí pouze instrukce předat fyzickému procesoru a následně z procesoru zpět předat výsledek do virtuálního stroje.

Obrázek 4: Schéma plné virtualizace

Na druhou stranu, vzhledem k výše uvedené emulaci některého hardwaru (především se jedná o vstupně-výstupní hardware), musí virtualizační nástroj stále překládat či jinak modifikovat instrukce pro práci s tímto hardwarem. Paravirtualizace je tedy obtěţkána reţií pro práci s emulovaným hardwarem. Ta není tak vysoká jako u čisté emulace (uvedené v kapitole 2.1), přesto značně vyšší neţ u čistě fyzického stroje. Oproti čisté emulaci má však nativní virtualizace několikanásobně vyšší výpočetní výkon (daný stejnou architekturou procesoru a tudíţ nenutností jakkoliv modifikovat instrukce), který je prakticky roven výpočetnímu výkonu fyzického stroje.

2.3 Paravirtualizace Pokud není nutná virtualizace hardwaru, případně postačí virtualizace jen minimálního mnoţství hardwaru, lze místo plné virtualizace vyuţít paravirtualizaci. Ta, na rozdíl od předchozích metod virtualizace, nabízí jen částečné oddělení virtuálního a fyzického stroje a tím virtuální prostředí podobné fyzickému hostitelskému stroji. Lze ji úspěšně pouţít tam, kde nepředpokládáme změny ve fyzickém hardwaru, anebo případ12

né změny budou pouze výkonového charakteru, tedy např. výkonnější procesor stejného výrobce, ze stejné nebo kompatibilní řady. Paravirtualizace nabízí výkon virtuálních strojů podobný výkonu fyzického stroje, coţ je dáno především minimální reţií pro ovládání emulovaného hardwaru (jak jiţ bylo uvedeno, při paravirtualizaci se hardware neemuluje buď vůbec anebo jen minimálně). Na druhou stranu s sebou paravirtualizace přináší problémy při přístupu k hardwaru. Tím, ţe se hardware neemuluje, je nutno ošetřit přístup k jednomu fyzickému hardwaru z několika virtuálních strojů. Jedním z problémů je virtualizace procesoru. Procesory fungují v minimálně dvou reţimech – v privilegovaném a v uţivatelském. Privilegovaný reţim je přístupný jádru operačního systému, které tak můţe kontrolovat, jak se která aplikace snaţí přistupovat k různému hardwaru, nebo virtuální paměti a tím např. zajistit, aby jedna aplikace nemohla přistupovat k datům uloţeným v paměti jinou aplikací. Uţivatelský reţim je naopak přístupný všem ostatním aplikacím. Ty v něm ale nemohou provádět operace privilegovaného reţimu a tyto musí obslouţit jádro OS. Problém, který je nutno vyřešit je ten, ţe virtualizační aplikace musí běţet v privilegovaném reţimu, aby měla výhradní přístup k hardware a mohla sama určovat, který virtuální stroj bude mít přístup k určitému hardwaru či části paměti – aby nedocházelo ke kolizím, nebo aby si jednotlivé stroje „nekradly“ nebo nepřepisovaly data v operační paměti. Zároveň ale v privilegovaném reţimu nemůţe běţet jádro operačního systému, protoţe by mohlo ovlivňovat činnost virtualizační aplikace. Řešení tohoto problému jsou v zásadě dvě a závisí na procesoru hostitelského systému. První variantou je modifikování jádra hostitelského OS (pro kaţdý virtuální stroj) a to tak, ţe se privilegované instrukce OS převedou na volání patřičných funkcí virtualizačního nástroje, který zajistí jejich správné vykonání. Rozsah modifikací závisí na architektuře procesoru. Je-li pouţíván procesor se třemi a více ochrannými okruhy7, pak stačí modifikovat pouze některé instrukce pro práci s pamětí. Pokud bychom takovýto procesor k dispozici neměli, jsou úpravy mnohem rozsáhlejší. 7

Anglicky „Protection rings“; Procesor je rozdělený do více okruhů, kdy aplikace běţící v okruhu s vyšším číslem nemohou modifikovat data aplikací běţících v okruhu niţším. Dnes se uţívají procesory se čtyřmi ochrannými okruhy, kdy uţivatelské aplikace běţí v ochranném okruhu s nejvyšším číslem (3) a operační systém v okruhu s nejniţším číslem (0). Zbývající dva okruhy bývají standardně nevyuţité. Virtualizační aplikace pak běţí v okruhu s číslem 1, v případě pouţití speciálních procesorů, podporujících virtualizaci, v okruhu s číslem -1 (minus 1), tzn., ţe je nadřazena OS běţícímu v okruhu 0.

13

Problém vzniká u systémů s neveřejnými zdrojovými kódy, případně pokud by to bylo v rozporu s licenční smlouvou mezi koncovým uţivatelem a výrobcem OS (proto například nelze upravit jádro operačních systémů od společnosti Microsoft), pokud tedy výrobce sám nevydá upravený operační systém. Druhou variantou je uţití moderního procesoru, který virtualizaci přímo podporuje (u procesorů Intel jde o technologii VT-x, u procesorů AMD o technologii AMDV). Pak není nutné modifikovat OS, protoţe kritické instrukce jsou odchyceny virtualizační vrstvou, která je v těchto procesorech nadřazena operačnímu systému. Ta zajistí jejich vykonání tak, aby došlo k ovlivnění stavu pouze té virtuální stanice, která poţadavek vyslala.

2.4 Virtualizace na úrovni jádra operačního systému Lze se setkat i s názvem „Virtuální privátní server“. Tento druh virtualizace je povaţován za nejefektivnější. Nedochází při něm k virtualizaci hardwaru, nýbrţ k virtualizaci operačního systému jako takového. Hostované operační systémy virtuálních strojů běţí nad společným jádrem hostitelského operačního systému fyzického stroje, které má plný přístup k fyzickému hardwaru, čímţ odpadá reţie na emulaci virtuálního hardwaru. Navíc jsou ušetřeny nemalé systémové prostředky díky faktu, ţe je v paměti zavedeno pouze jedno jádro operačního systému (a to na fyzickém stroji) a kaţdý jednotlivý hostovaný operační vyuţívá toto jádro, jako by bylo „jeho vlastní“. Z uvedeného principu vyplývá, ţe hostitelský i hostované operační systémy musí být stejné a to jak typ, tak verze. Nicméně jednotlivé instance hostovaných OS si lze libovolně nezávisle na sobě přizpůsobit, jakoby se jednalo o plnohodnotný fyzický systém. Při virtualizaci na úrovni jádra OS se nemusí upravovat jádro operačního systému. Na druhou stranu je nutné upravit ty systémové příkazy, které poskytují informace o stavu celého systému. Např. příkaz pro vrácení času, po který je systém spuštěn, musí vracet čas, po který je spuštěn daný virtuální, ne hostitelský systém.

14

Obrázek 5: Schéma virtualizace na úrovni operačního systému

2.5 Aplikační virtualizace Jedná se vlastně o „mini virtualizaci“, kdy konkrétní aplikace jsou spouštěny ve virtuálním prostředí, které je oddělené od ostatních aplikací v hostitelském operačním systému, díky čemuţ lze vyloučit vzájemné konflikty různých aplikací, případně různých verzí stejných aplikací.

Obrázek 6: Schéma aplikační virtualizace

Prostřednictvím aplikační virtualizace lze např. na různých platformách (operačních systémech) provozovat stejnou (neupravenou) aplikaci 8. Aplikační virtualizaci lze vyuţít také pro vzdálenou distribuci aplikací, tj. na centrálním serveru je připraven obraz aplikace, a pokud některá pracovní stanice poţaduje spuštění této aplikace, dojde k její distribuci do virtuálního prostředí na pracovní stanici, přičemţ nedojde k zásahu do hostitelského operačního systému (aplikace se nijak neinstaluje), přesto je aplikaci moţno pouţívat tak, jako by byla na hostitelském systému regulérně nainstalována. 8

Tento postup vyuţívá např. Java, kdy jsou aplikace naprogramované v Javě spouštěny ve virtuálním prostředí Java Virtual Machine, které existuje ve verzích pro operační systémy Apple, Linux, Solaris a Windows. Jeden program lze tedy spustit na všech uvedených OS a pokaţdé bude mít stejné vlastnosti.

15

3 Virtuální sítě Stejně jako lze virtualizovat pracovní stanice a servery, lze virtualizovat i počítačovou síť LAN. Virtuální LAN (tedy VLAN) lze vytvořit jak pro virtuální stanice za pomocí ryze virtuálních síťových prvků (např. virtuálních switchů), kdy VLAN slouţí ke komunikaci s okolním prostředím (ať jiţ virtuálním – tedy další virtuální stanicí, či nevirtuálním – tedy s fyzickým strojem), nebo lze provozovat VLAN jako jakousi „nadstavbu“ klasické fyzické LAN, kde ji vyuţívají fyzické stroje pro oddělení různého provozu v jednom fyzickém médiu. V následujících odstavcích nejprve nastíním řešení prostřednictvím klasické fyzické LAN (postavené na technologii Ethernet) a následně uvedu výhody, které přináší vyuţití virtuální sítě.

3.1 Fyzická LAN Tvoříme-li LAN pro desítky aţ stovky počítačů, není moţné a většinou ani ţádoucí, aby všechny tyto počítače spolu mohly navzájem komunikovat. Proto chceme jednotlivé počítače od sebe oddělit, čehoţ můţeme dosáhnout umístěním různých skupin počítačů do různých subnetů. Subnet slouţí k logickému rozdělení sítě na menší podsítě. Samotné oddělení sítí do různých subnetů ale nezajistí, ţe zařízení z různých subnetů spolu nebudou komunikovat. Pokud bychom subnety zapojili do společného switche (nebo do navzájem propojených switchů), který pracuje na druhé vrstvě modelu OSI a přistupuje k MAC adresám, které nic nevypovídají o zařazení zařízení do subnetu, pak by zařízení v různých subnetech mezi sebou mohla teoreticky komunikovat. Teoreticky proto, ţe zařízení standardně nepřijímají komunikaci z jiného subnetu (k jejímu oddělení dojde na třetí vrstvě OSI). Přesto však můţe dané zařízení vyuţívat útočník k zachytávání a odposlouchávání komunikace. V kaţdém případě se v tomto síťovém uspořádání budou mezi všemi subnety šířit broadcasty, které ve větší síti mohou způsobovat výkonové problémy. Pokud tedy chceme fyzicky oddělit subnety, a zabránit tak kompletně komunikaci mezi nimi, musíme jednotlivé sítě zapojit do oddělených switchů.

16

Pokud potřebujeme pouze omezit broadcasty mezi subnety, můţeme pouţít např. router, nebo dnes častěji pouţívaný L3 switch9. Tato zařízení zajišťují routování (směrování) mezi jednotlivými sítěmi (a subnety), čímţ umoţňují jejich vzájemnou komunikaci. Zároveň však nepropouštějí broadcasty do cizích subnetů.

3.2 Virtuální LAN Virtuální síť pouţíváme převáţně k vytváření oddělených sítí. Můţeme ji vytvořit buď na virtuálních zařízeních pro virtuální stroje, nebo na speciálních switchích, které podporují VLAN a pak do ní můţeme zapojit fyzická zařízení. V obou případech se jedná z funkčního hlediska o totéţ (oba typy sítí mají stejné vlastnosti). Hlavní výhodou VLAN je nezávislost na fyzickém místě připojení. Do stejné VLAN mohou být bez problémů zařazena zařízení např. v různých patrech budovy. Kaţdý port switche můţe patřit do jiné VLAN, navíc jeden a tentýţ port nemusí (ale můţe) být svázán s jednou neměnnou VLAN, ale k němu přiřazená virtuální síť se můţe dynamicky měnit. Mezi jednotlivými VLAN neprochází broadcasty, ani kdyţ jsou zapojeny do jednoho switche. K ostatní komunikaci mezi jednotlivými virtuálními sítěmi vyuţíváme, stejně jako v případě s fyzickou LAN, routování. V ideálním případě pouţijeme takový switch, který podporuje inter-VLAN routing a tak umoţňuje sám o sobě routovat mezi virtuálními sítěmi. Pokud takový switch k dispozici nemáme, propojíme switch (na kterém máme zařízení připojená do VLAN) pomocí trunku s routerem (nebo L3 switchem). Trunk je port, který slouţí k přenášení dat v rámci virtuálních sítí mezi switchi. Aby se data přenesla do správné VLAN na dalším switchi, je nutno data nějak označit. K tomuto účelu se pouţívá standard IEEE 802.1q, který pojednává o takzvaném značkování (tagování) rámců. Jedná se o jednoduchou metodu, kdy se hlavička datového rámce rozšíří o celkem čtyřbajtovou informaci – první 2 bajty jsou značka, ţe se jedná o protokol 802.1q, další 3 bity jsou priorita dle protokolu 802.1p, následuje 1 bitový příznak, zda-li je MAC adresa v kanonickém tvaru a posledních 12 bitů je ID VLAN. Následně se musí přepočítat kontrolní součet celého rámce, protoţe vloţením značky do hlavičky došlo k jeho změně. (Existují i proprietární řešení, např. ISL encapsulation od Cisca, která jsou ale podporována jen na (některých) zařízeních daného výrobce.)

9

L3 switch pracuje jako „obyčejný“ switch na druhé (linkové) vrstvě modelu OSI, ale navíc poskytuje sluţby třetí (síťové) vrstvy. Prakticky tedy dostáváme dvě zařízení v jednom – switch a router.

17

Zpravidla se trunkem přenáší data pro všechny VLAN, lze však nastavit, aby se přenášela data pouze pro určité virtuální sítě. Trunk se tedy pouţívá k propojení switchů, pokud potřebujeme zvětšit počet dostupných portů, nebo např. propojit switche na různých patrech. Zde je patrná výhoda oproti fyzické LAN, kdy pokud bychom chtěli propojit několik zařízení umístěných na více podlaţích do více oddělených podsítí, museli bychom pro kaţdý jednotlivý subnet táhnout speciální propojovací kabel. V případě virtuální sítě nám stačí pouze jeden trunk pro propojení switchů na různých podlaţích, do kterých můţeme zapojit zařízení do různých VLAN.

Obrázek 7: Princip VLAN se zařízeními na různých patrech [4]

3.3 Připojení do VLAN O příslušnost zařízení do konkrétní VLAN se standardně stará příslušný switch, do kterého je zařízení zapojeno. Existují dva modely přiřazování členství – statický a dynamický. Statický model spočívá v přiřazení VLAN na konkrétní port. To v praxi znamená, ţe jednotlivé porty switche jsou namapovány na konkrétní VLAN a zařízení, které se na switch připojí do daného portu má pak přístup k té virtuální síti, která je na daný port namapována. Pokud se zařízení připojí do jiného portu, změní se i VLAN, ke které 18

je připojen (za předpokladu, ţe na nový port není namapována stejná VLAN jako na původní). Dynamický model obsahuje více metod přiřazení členství do VLAN, jmenujme například přiřazení dle autentizace prostřednictvím protokolu IEEE 802.1x, nebo na základě MAC adresy. Přiřazení VLAN na základě autentizace pomocí protokolu IEEE 802.1x funguje tak, ţe po připojení neautentizovaného zařízení do switche je na tomto portu zablokovaná komunikace, případně lze nastavit přiřazení zařízení do určité „hostovské“ VLAN s omezeným přístupem k síťovým prostředkům. Poté, co zařízení prostřednictvím EAP protokolu zašle ţádost o autentizaci, dojde k ověření přihlašovacích údajů na RADIUS serveru a ten v případě úspěšné autentizace zašle switchi údaje o tom, do které VLAN má daného klienta připojit. Přiřazení do VLAN na základě zdrojové MAC adresy můţe probíhat dvěma způsoby. První moţnost je, ţe se podle MAC adresy prvního rámce přiřadí daný port do VLAN a v ní zůstane, dokud nedojde k odpojení zařízení z tohoto portu. Druhá moţnost je, ţe se testuje kaţdý rámec a kaţdý tento jednotlivý rámec se nasměruje do správné VLAN. Toto řešení je však náročné na výkon.

19

4 Virtualizace – softwarová řešení Na vytvoření virtuálních stanic či virtuálních serverů existuje na trhu široká nabídka produktů různých společností. Pro účely této práce se blíţe seznámíme s některými produkty vedoucích společností na virtualizačním trhu, a to Citrix Systems, Microsoft a VMware.[5]

4.1 Citrix Systems Společnost Citrix System nabízí řešení pro virtualizaci pracovních stanic, serverů a sítí. Dále nabízí řešení pro on-line spolupráci a nově i Cloud computing. Citrix XenServer je kompletní platforma pro serverovou virtualizaci postavená na hypervisoru Xen. Lze jej pořídit ve čtyřech edicích – Free, Advanced, Enterprise a Platinum. Free Edice je zdarma, nejdraţší Platinum edice přijde na 5 tisíc dolarů/server. 4.1.1 Citrix XenServer Z webových stránek společnosti Citrix lze zdarma stáhnout produkt XenServer. Staţený soubor je CD obraz ve formátu ISO, který je před instalací nutno vypálit na CD. Po vloţení disku do mechaniky, a nabootování z něj, se automaticky spustí instalace. Během ní se systém zeptá na několik parametrů, jako je rozloţení klávesnice, odkud chce uţivatel XenServer instalovat (z CD disku, z internetu, nebo prostřednictvím NFS), na který disk má XenServer ukládat virtuální stroje, jestli má uţivatel nějaké rozšiřující balíčky10, které chce nainstalovat, a zda-li se má otestovat nepoškozenost instalačního média. Dále pak uţivatel musí vytvořit heslo administrátora, to musí mít minimálně 6 znaků, nakonfigurovat síťové prostředí (který síťový adaptér se má pouţít pro správu serveru, jeho IP adresu, název serveru a DNS servery), zvolit časovou zónu, nastavit jakým způsobem se bude synchronizovat čas (manuálně, nebo prostřednictvím NTP). Následuje potvrzení, zda opravdu uţivatel chce XenServer nainstalovat a ţe přitom dojde ke ztrátě všech dat na cílovém disku. Po potvrzení začne instalace, která trvá necelých 5 minut. Následuje restart počítače a XenServer je připraven.

10

Anglicky „Supplemental Packs“

20

Obrázek 8: Úvodní obrazovka Citrix XenServer

XenServer nabízí na fyzickém serveru grafické rozhraní pro základní konfiguraci síťového prostředí, připojení vzdálených uloţišť, dále umoţňuje zobrazit informace o hardware serveru a monitorovat stav virtuálních stanic, které lze případně zapínat nebo vypínat. Ostatní moţnosti nastavení serveru, včetně vytváření virtuálních stanic, lze provést prostřednictvím konzole příkazového řádku přímo na serveru, nebo pomocí grafického rozhraní v aplikaci XenClient (pouze pro OS Windows). Tu lze nainstalovat např. z instalačního CD XenServeru. Instalace této aplikace je oproti instalaci XenServeru jednoduchá, uţivatel musí pouze zadat, kam chce XenCenter nainstalovat. Samotná instalace trvá několik vteřin. Po spuštění XenCenter a připojení ke XenServeru aplikace ověří platnost licence. V případě, ţe uţivatel chce pouţívat Free verzi, má moţnost v okně License Manager, které se zobrazí, pokud na serveru není nainstalována licence, kliknout na Request Activation Key a získat licenci pro free verzi, která mu po vyplnění osobních údajů přijde e-mailem. Její platnost je jeden rok. XenServer pracuje v reţimu paravirtualizace, z čehoţ vyplývá, ţe pro jeho plnou funkčnost je zapotřebí jej provozovat na systémech s podporou hardwarové virtualizace. V tomto případě lze na XenServeru provozovat

jakýkoliv operační systém

s neupraveným jádrem. Pokud hostitelský systém nepodporuje HW virtualizaci, pak lze na XenServeru provozovat pouze virtuální stanice s upraveným jádrem OS, viz kapitola 2.3 Paravirtualizace. Pro tyto účely je k dispozici rozšiřující balíček Linux Guest 21

Support (k dispozici na webových stránkách společnosti Citrix), který po nainstalování do XenServeru umoţní vytvořit virtuální stroje s OS Linux s upraveným jádrem. Navíc tento balíček obsahuje šablonu Demo Linux VM, která obsahuje virtuální stroj se základní verzí upraveného OS Linux Debian. XenServer podporuje tři typy sítí. Interní, externí a spojené (bonded) sítě. Interní sítí se rozumí síť, která spojuje virtuální stroje v rámci jednoho XenServeru. V rámci interní sítě není vytvořeno ţádné spojení s fyzickým síťovým rozhraním a stroje jsou izolovány od okolního světa. Tato síť se svou charakteristikou podobá virtuální síti – komunikovat spolu mohou jen počítače zapojené do té samé virtuální sítě. Externí síť je spojena s fyzickým síťovým rozhraním a poskytuje tak most mezi virtuálním a fyzickým prostředím a umoţňuje virtuálním zařízením přistupovat k prostředkům připojeným k fyzickému síťovému adaptéru. Spojené (bonded) sítě spojují dva fyzické síťové adaptéry a vytvářejí tak jeden výkonný kanál mezi virtuálními stroji a sítí. Na externích nebo spojených sítích lze provozovat VLAN. Interní síť VLAN nepodporuje, ale vzhledem k charakteristice této sítě, by to bylo i zbytečné. VLAN se vytváří nad specifickým síťovým adaptérem (nebo spojení dvou adaptérů), virtuální stanice lze pak připojit buď přímo na daný síťový adaptér, nebo na jeho instanci s nastaveným ID virtuální sítě. Prostřednictvím VLAN lze oddělit rozhraní pro správu XenServeru od ostatního provozu (síťový adaptér musí být připojen ve switchi v portu v reţimu access) nebo přiřazovat konkrétním virtuálním stanicím jednotlivé VLAN (síťový adaptér musí být připojen na port v reţimu trunk). Chce-li uţivatel pouţít oba uvedené způsoby, tj. oddělit správu serveru do VLAN a zároveň na stejném adaptéru mít vytvořené VLAN pro virtuální stanice, pak daný adaptér musí být připojen do switche na port v reţimu trunk s podporou nativní VLAN, přes kterou je pak spravován server.

4.2 Microsoft Společnost Microsoft nabízí primárně operační systémy Windows a aplikace pro tyto operační systémy. V oblasti virtualizace nabízí řešení pro virtualizací serverů, pracovních stanic a aplikací. Microsoft Hyper-V Server 2008 R2 (dále jen Hyper-V Server) je, na rozdíl od modulu Hyper-V obsaţeného v systému Microsoft Windows Server 2008, samostatný produkt pro virtualizaci serverů, postavený na Windows hypervisoru. Hyper-V Server je k dispozici zdarma a obsahuje pouze jádro operačního systému Windows Server 2008. 22

To znamená, ţe neobsahuje prakticky ţádná grafická dialogová okna jako ostatní verze Windows. Chybí například i správce zařízení. Určité moţnosti nastavení systému zde jsou, ale pouze prostřednictvím příkazového řádku. 4.2.1 Hyper-V Server 2008 R2 Hyper-V Server lze zdarma stáhnout z webu společnosti Microsoft. Po vloţení DVD do mechaniky se automaticky spustí instalace s podobným scénářem i vzhledem jako instalace ostatních moderních OS Windows. Je nutno vybrat jazyk instalace a národní prostředí. Dále uţivatel zvolí, zda-li chce aktualizovat jiţ existující systém (migrace z předchozí verze), nebo provést kompletní instalaci. Následuje výběr disku a samotná asi půl hodinová instalace s několika restarty PC. Po dokončení instalace je uţivatel vyzván k vytvoření uţivatelského hesla pro administrátora. Heslo musí splňovat nároky na sloţitost (tj. min 6 znaků a obsahovat znaky alespoň ze tří skupin, které jsou: malá písmena, velká písmena, čísla, speciální znaky). Po přihlášení se zobrazí dvě okna – příkazový řádek a konzole Server Configuration, která umoţňuje provést některá základní nastavení. Ţádné další ovládací prvky typické z prostředí Windows (jako např. hlavní panel) nejsou k dispozici.

Obrázek 9: Úvodní obrazovka Microsoft Hyper-V Server 2008 R2

Pro více moţností nastavení a správu virtuálních stanic je nutno stáhnout z webu společnosti Microsoft Nástroje pro vzdálenou správu serveru pro systém Windows 7 (případně pro Windows Vista). Po spuštění instalace je nutno odsouhlasit licenční pod23

mínky. Instalace probíhá automaticky – jedná se o aktualizační balíček systému Windows. Po dokončení instalace je nutno funkcionalitu ručně zapnout v dialogovém okně Programy a funkce (v Ovládacích panelech), v levém sloupci odkaz Zapnout nebo vypnout funkce systému Windows a v seznamu zvolit Nástroje Hyper-V (jako poloţka pod Nástroje pro vzdálenou správu serveru a Nástroje pro správu rolí). Poté lze tento modul spustit kliknutím na tlačítko Start, výběrem Nástroje pro správu a Správce technologie Hyper-V. Nyní je nutno na serveru i na stanici, ze které chce uţivatel provádět správu, učinit další kroky, které umoţní přístup vzdálenému uţivateli. Tyto kroky se liší pro případ, kdy jsou stroje připojené k síti v doméně, nebo v pracovní skupině. Další postup lze vyhledat na stránkách společnosti Microsoft. V Hyper-V Serveru existují, obdobně jako v XenServeru, tři typy sítí – interní, externí a soukromé. Interní sítě umoţňují komunikaci virtuálních stanic pouze v rámci daného fyzického serveru a dále komunikaci virtuálních stanic s daným fyzickým serverem. Nejsou nijak spojeny s fyzickou sítí. Externí sítě umoţňují komunikaci jak v rámci daného fyzického serveru, tak s okolním fyzickým prostředím, nebo dalšími virtuálními stanicemi na jiném fyzickém serveru. Soukromé virtuální sítě jsou podmnoţinou interních sítí a slouţí k izolaci virtuálních stanic od síťového provozu fyzického serveru. To znamená, ţe virtuální stanice v soukromé virtuální síti nemohou komunikovat s fyzickým serverem.

4.3 VMware Společnost VMware se zabývá virtualizací pracovních stanic a serverů, déle nabízí řešení pro datová centra a Cloud computing. Pro virtualizaci serverů společnost nabízí produkt VMware ESX, nebo jeho novější variantu ESXi. Jedná se o bare-metal hypervisory, které lze pouţívat buď samostatně – variantu ESXi v rámci freewarového produktu VMware vSphere Hypervisor (dříve nazývaném VMware ESXi) – nebo např. v rámci produktu VMware vSphere, coţ je komplexní nástroj pro virtualizaci a Cloud computing. 4.3.1 VMware vSphere Hypervisor 4.1.0 Před staţením vSphere Hypervisoru je nutno se zaregistrovat na stránkách VMware. Po registraci se uţivatel dostane na stránku, kde je uvedeno licenční číslo pro vSphere Hypervisor, bez kterého nainstalovaný produkt po 60 dnech omezí funkcionali-

24

tu. Dále si můţe vybrat verzi vSphere Hypervisoru a zda chce instalovat nový vSphere, nebo aktualizovat z předchozí verze. Po staţení instalačního obrazu a nabootování z disku se načte boot manager, který umoţňuje spustit instalaci, nebo pokračovat v bootování z primárního pevného disku. Po spuštění instalace instalátor oznámí, ţe vSphere lze nainstalovat na většinu strojů, ale ţe jsou podporovány pouze ty, uvedené na webu VMware v Hardware Compatibility Guide. Nyní si uţivatel můţe vybrat, jestli chce opravit jiţ nainstalovaný vSphere, nebo provést novou instalaci. Při zvolení nové instalace odsouhlasí licenční podmínky, následuje výběr disku, na který chce vSphere nainstalovat, a pak jiţ začne samotná krátká instalace. Po restartu systému je vSphere připraven.

Obrázek 10: Úvodní obrazovka vSphere Hypervisor

Fyzicky lze přímo na serveru nastavit pouze heslo uţivatele root a parametry sítě pro vzdálenou správu serveru. Veškeré další konfigurační moţnosti nabízí vSphere Hypervisor vzdáleně po připojení přes vSphere Client, který je moţno stáhnout buď rovnou ze stránek VMware, nebo po zadání IP adresy, která je zobrazena na úvodní obrazovce nainstalovaného vSphere Hypervisoru. Instalace vSphere Client je standardní – odsouhlasení licenčních podmínek, vyplnění uţivatele a společnosti a výběr umístění kam klienta nainstalovat. Po spuštění vSphere Client je nutno zadat IP adresu serveru, uţivatelské jméno a heslo. Při úspěšném přihlášení se otevře přehledné uţivatelské prostředí pro správu a monitorování virtuálního serveru a virtuálních stanic. Pro instalaci a konfiguraci operačního systému a dalšího software do virtuálních stanic slouţí konzole, která v okně 25

zobrazuje obsah „monitoru“ virtuálního stroje a umoţňuje klávesnicí a myší tento stroj ovládat. Aby mohla virtuální stanice komunikovat se svým okolím – nezáleţí na tom, jestli virtuálním, nebo fyzickým – musí být připojena do virtuálního switche. Kaţdý virtuální switch můţe mít 8 aţ 4088 virtuálních portů. Pokud je ke switchi připojen alespoň jeden fyzický síťový adaptér, mohou virtuální stanice komunikovat s fyzickým okolím. V opačném případě je komunikace moţná pouze mezi virtuálními stanicemi navzájem. Je-li do switche zapojen více neţ jeden síťový adaptér, lze pouţít tzv. NIC teaming a rozloţit tak síťový provoz mezi tyto adaptéry, čímţ se zvýší propustnost sítě. Zároveň v případě, ţe jeden adaptér selţe, nedojde k výpadku síťového připojení na serveru, protoţe provoz převezme funkční adaptér. Kaţdý port na virtuálním switchi je připojen do port group (skupiny portů), coţ je logický prvek, který sjednocuje porty se stejnou konfigurací. Kaţdá skupina portů má v rámci jednoho virtuálního serveru unikátní název a také lze kaţdé skupině portů přiřadit ID virtuální LAN. To můţe být libovolné celé číslo od 1 do 4094, nebo „0“ (nula), pak skupina portů nenáleţí do ţádné VLAN, případně „4095“, kdy je skupina portů nastavena jako trunk.

4.4 Srovnání produktů V tabulce 1 na následující stránce jsou uvedeny některé parametry, které slouţí pro srovnání uvedených produktů. Srovnávány jsou produkty ve verzi: -

Cytrix XenServer 5.6

-

Microsoft HyperV Server 2008 R2

-

VMware vSphere Hypervisor 4.1

26

Vlastnost Podporovaná architektura hostitelského stroje Nutnost HW virtualizace (Intel VT-x nebo AMD-V) Maximální počet fyzických CPU / velikost RAM Podporovaná disková uložiště Podporovaná architektura hostovaných strojů Podporované hostitelské OS a jejich min. verze

Maximální počet virtuálních CPU / velikost RAM / velikost virtuálního pevného disku / počet virtuálních NIC v rámci jednoho virtuálního stroje Možnost připojit virtuální stroj na virtuální switch Možnost připojit virtuální stroj přímo na fyzické síťové rozhraní Podpora VLAN

Citrix XenServer 64 bit ano, pro spuštění neupravených OS 64 / 256 GB lokální disk, Fibre Channel, iSCSI, NFS, SAS 32 bit, 64 bit CentOS 4.5, Debian Leny, Oracle Enterprise 5.0, RetHat 4.5, SUSE 10, Windows XP SP 2

Microsoft HyperV 64 bit

VMware vSphere 64 bit

ano

ne

64 / 1 TB lokální disk, Fiber Channel, iSCSI, SAS 32 bit, 64 bit RedHat Enterprise Linux 5 SUSE 10, Windows Server 2000 SP4, Windows XP SP3

128 / 1 TB lokální disk, Fibre Channel, iSCSI, NAS, SAS 32 bit, 64 bit CentOS 4.5, Debian 4.0, FreeBSD 6.3, RedHat Enterprise Linux 2.1, Windows 95, a další

8 / dle maxima OS / 2TB / 7

4 / 64 GB / 2 TB / 12

8 / 255 GB / 2 TB / 10

ne, bez externích řešení

ano

ano

ne

ano

ano

ano nezjištěno, pravděpodobně ne ano

Tabulka 1: Srovnání nástrojů pro virtualizaci serverů od různých výrobců

5 Testování sítě Pro zajištění kvalitního síťového připojení, nestačí mít jen kvalitní hardware (který by však měl být samozřejmostí, protoţe zajišťuje lepší parametry sítě, neţ levný hardware s nejistým výrobcem). V dnešní době bývá většina problémů s připojením v rámci sítě způsobena softwarem. Síťové prostředí můţe být špatně nakonfigurováno, nebo v rámci útoku na síť můţe dojít k jejímu cílenému zahlcení, coţ vede ke sníţení schopnosti, nebo dokonce úplné neschopnosti sítě poskytovat sluţby. Pro odhalení problémů existuje řada softwarových, ale i hardwarových řešení. Můţe se jednat o nepřetrţité automatické monitorování, které je důleţité v rámci větších sítí a umoţňuje správci včas odhalit vznikající problém. Další moţností je testování parametrů sítě „ručně“, tj. spuštěním příslušných diagnostických nástrojů správcem v okamţiku, kdy si přeje jednorázově zjistit parametry sítě. Zpravidla se testují parametry jako propustnost sítě, zpoţdění, míra ztrátovosti rámců, zpracování navazujících rámců, rychlost obnovy systému po přetíţení a rychlost obnovy systému po resetu.[6] Další moţností testování sítě, je analyzovat síťový provoz z hlediska jeho obsahu, tzn. analyzovat co se sítí přenáší, odkud a kam. K tomuto účelu slouţí analýza paketů.

5.1 Propustnost sítě (throughput) Propustnost sítě je maximální přenosová rychlost, při které ještě nedochází k zahazování rámců, tj. maximální rychlost, při které síťové zařízení „stíhá“ zpracovávat všechny příchozí rámce. Testování probíhá tak, ţe se na cílové zařízení odesílá zvolený počet rámců určitou rychlostí. Pokud počet rámců doručených odpovídá počtu odeslaných, pak se zvýší rychlost a celý proces se opakuje, dokud počet doručených rámců nebude niţší, neţ počet odeslaných. Pak se jako propustnost sítě označí nejvyšší dosaţená rychlost, při které byly doručeny všechny odeslané rámce. (Postup lze i obrátit a naopak sniţovat rychlost z teoretického maxima daného pouţitou architekturou.)

5.2 Zpoždění (latency) Zpoţdění je definováno nepatrně odlišně pro dva typy zařízení. V případě zařízení typu store and forward je definováno jako čas mezi okamţikem, kdy poslední bit rámce dorazí do zařízení a okamţikem, kdy první bit rámce zařízení opustí. U zařízení

typu bit forwarding je zpoţdění definováno jako čas mezi okamţikem, kdy do zařízení dorazí konec prvního bitu rámce a okamţikem, kdy začátek prvního bitu rámce opustí zařízení. Pro testování zpoţdění je nutno nejprve zjistit propustnost sítě pro danou velikost rámce. (Pro ethernetové sítě je doporučeno odesílat rámce o velikosti 64, 128, 256, 512, 1024, 1280, 1518 bajtů.[6]) Poté se zvolí rámec o určité velikosti a začne se odesílat na cílové zařízení maximální rychlostí. Vysílání by mělo trvat minimálně 120 vteřin, po 60 vteřinách by měl být jeden rámec identifikovatelně označen. Časový úsek mezi okamţikem, kdy je rámec odeslán a okamţikem, kdy označený rámec dorazí na cílové zařízení je hodnota zpoţdění. Test by se měl opakovat minimálně 20 krát a výsledná hodnota zpoţdění by měla být aritmetickým průměrem naměřených hodnot.

5.3 Míra ztrátovosti rámců Míra ztrátovosti rámců udává počet rámců, které při konstantním zatíţení sítě, byly odeslány, ale vlivem nedostatku zdrojů nebyly doručeny na cílové zařízení. Testování je realizováno odesláním daného počtu rámců a zjištěním, kolik rámců skutečně dorazilo na cílové zařízení. Míra ztrátovosti se pak vyjádří v procentech jako

Test by měl být proveden při rychlosti odpovídající 100% propustnosti sítě pro danou velikost rámce, dále při 90% a 80% této rychlosti. Testy by měli být opakovány (pokaţdé se sníţením rychlosti přenosu o 10%) tak dlouho, dokud dva po sobě jdoucí testy nevrátí 0% ztrátovost.

5.4 Zpracování navazujících rámců Udává počet úspěšně přenesených rámců o stejné velikosti v rámci skupiny těchto rámců. V rámci testu se na testované zařízení odešle skupina rámců o stejné velikosti s velmi krátkým intervalem mezi jednotlivými rámci. Pokud cílové zařízení přijme všechny odeslané rámce v pořádku, zvýší se počet rámců ve skupině a test se opakuje, dokud je počet odeslaných rámců roven počtu doručených. (Naopak, pokud při prvním pokusu nejsou doručeny všechny odeslané rámce, pak se počet rámců sníţí a test se opakuje, dokud nejsou doručeny všechny odeslané rámce.)

29

Kaţdý test musí trvat minimálně 2 vteřiny a mělo by být uskutečněno alespoň 50 testů. Výsledkem je aritmetický průměr z výsledků testů (délky nejdelší úspěšně doručené skupiny rámců).

5.5 Rychlost obnovy systému po přetížení Rychlost obnovy systému po přetíţení je čas, který je potřebný pro uvedení síťového zařízení zpět do provozu. Přetíţením se rozumí kaţdý stav zařízení, kdy toto zahazuje rámce. K uskutečnění testu je nejprve nutno znát propustnost sítě. Poté se zahájí vysílání rychlostí 110% maximální rychlosti sítě po dobu minimálně 60 sekund. Poté se rychlost vysílání sníţí na 50% maximální rychlosti a od tohoto okamţiku se měří čas, který uplyne do okamţiku, neţ zařízení přestane zahazovat rámce. Tento čas je rychlost obnovy systému po přetíţení. Test by měl být několikrát opakován.

5.6 Rychlost obnovy systému po resetu Charakterizuje čas, který je zapotřebí proto, aby síťové zařízení obnovilo svou činnost po svém resetu. K testu je zapotřebí zjistit propustnost pro nejmenší velikost rámce, který je na daném médiu přenositelný. Poté se začnou takto veliké rámce vysílat na testované zařízení. Rychlost obnovy systému po resetu je čas od okamţiku, kdy poslední rámec dorazí do zařízení před jeho restartem, do okamţiku, kdy první rámec dorazí do zařízení po jeho restartu. Obdobně lze provést i test rychlosti obnovy systému po vypnutí zařízení s tím rozdílem, ţe zařízení musí být minimálně 10 vteřin vypnuté.

5.7 Analýza paketů (packet sniffing) Pro analýzu paketů slouţí softwarové, nebo hardwarové nástroje, které se připojí na komunikační médium a transparentně (aniţ by ho modifikovaly) odchytávají veškerý síťový provoz, který skrz ně prochází. Analýza paketů pak lze pouţít k detailní analýze síťového provozu, např. které stanice mezi sebou komunikují a na kterých portech. Také je moţné zobrazit obsah jednotlivých paketů. Pokud je analyzátor paketů řešen softwarově, je nutné, aby byla síťová karta, na které je poţadováno zachytávání paketů, v tzv. promiskuitním reţimu. Standardně totiţ síťový adaptér filtruje příchozí komunikaci a pakety, které pro něj nejsou určené (nejsou 30

adresovány na jeho MAC adresu) zahazuje. V promiskuitním reţimu je tento prvek vypnut a síťový adaptér přijímá všechen síťový provoz, který na jeho rozhraní dorazí.

31

6 Případová studie 6.1 Úvod Cílem této případové studie je popsat instalaci a konfiguraci virtuální stanice, prostřednictvím které budou testovány parametry lokální sítě, do které je tato stanice připojena. Protoţe cílem práce není testování síťového řešení, nebudou prováděny opakované testy pro zpřesnění výsledků. Nejprve bude nainstalován zvolený software pro virtualizaci serveru. Na tomto virtuálním serveru budou poté nainstalovány tři totoţné virtuální stanice, z nichţ jedna bude následně nakonfigurována pro testování sítě a analýzu síťového provozu prostřednictvím analyzátoru paketů. Poznámka: Analýza paketů je v této práci pouţita jako prostředek pro správce sítě k monitorování provozu na této síti a k odhalení případných problémů. Rozhodně toto není návod k vytvoření stanice pro nelegální nebo nemorální činnost!

6.2 Parametry fyzického serveru Jako fyzický server byla zvolena sestava postavená na platformě AMD, jejíţ parametry jsou následující: -

Základní deska Gigabyte GA-770TA-UD3

-

Procesor AMD Phenom II X4 945, 3GHz, podpora virtualizační technologie AMD-V

-

Operační paměť Kingston 2x2 GB DDR3, 1 333 MHz, CL7

-

pevný disk WD400, 40 GB, PATA

-

integrovaný síťový adaptér s čipem Realtek 8111D (10/100/1000 Mbit)

-

PCI síťový adaptér Intel 82557/8/9/0/1 Ethernet Pro 100

Oba síťové adaptéry jsou připojené k ADSL routeru AirLive WT2000ARM (4 portový), který zajišťuje připojení k internetu a poskytuje prostřednictvím DHCP IP adresy v lokální síti. Vzdálená správa serveru byla prováděna z notebooku, který byl k routeru připojený prostřednictvím Wi-Fi. IP adresa routeru, který je pouţíván jako brána, je 192.168.2.1/24.

6.3 Virtuální server Jako virtuální server byl zvolen XenServer ve verzi 5.6 od společnosti Citrix. Tento produkt byl zvolen z důvodu moţnosti připojení virtuálního stroje přímo na fy32

zické síťové rozhraní a z důvodu bezproblémové instalace a konfigurace. Testované konkurenční produkty buď neumoţňují připojit virtuální stroj na fyzické síťové rozhraní (VMware vSphere Hypervisor), nebo je jejich konfigurace zbytečně sloţitá (Microsoft HyperV Server). Popis instalace virtuálního serveru XenServer a aplikace XenCenter je uveden v kapitole 4.1.1, proto zde jiţ nebude opakován. Síťové rozhraní eth0 (NIC Realtek) je vyhrazeno pro správu serveru a má nastavenu statickou IP adresu 192.168.2.200/24. Síťové rozhraní eth1 (NIC Intel) je vyhrazeno pro připojení virtuálních strojů do externí sítě.

6.4 Virtuální stanice Jako virtuální stanice byly vytvořeny tři identické stroje s následujícími parametry virtuálních komponent: -

1x CPU

-

512 MB RAM

-

8GB pevný disk

-

1x síťový adaptér

Operační systém byl zvolen MS Windows XP Professional CZ11. Vytvoření nové virtuální stanice je v prostředí XenCenter jednoduché. Po připojení ke XenServeru stačí kliknout pravým tlačítkem myši na tento server v levém sloupci a zvolit „New VM…“. Otevře se průvodce, kde se v prvním kroku zvolí šablona virtuálního stroje. Tyto šablony obsahují doporučené nastavení virtuálního prostředí pro optimální chod hostovaného OS. V našem případě byla zvolena šablona Windows XP SP2 (32 bit) (viz. Obrázek 11). V následujícím kroku se vyplní název a případný popis virtuálního stroje. Následuje výběr instalačního média. Na výběr je optická mechanika na fyzickém serveru, nebo instalace po síti. Další krok slouţí pro zvolení hostitelského serveru. V našem případě máme pouze jeden server, takţe zde nemáme moţnost cokoliv změnit. Následuje konfigurace hardware, nejprve se volí počet CPU a velikost RAM, v dalším kroku se nastavuje uloţiště, zde vytvoříme nový virtuální disk v Local storage, tedy na fyzickém pevném disku na serveru. Poslední krok průvodce slouţí pro nastavení síťového rozhra11

Operační systém byl staţený v rámci programu MSDN z webových stránek MSDN Academic Alliance Software Center, kde mám jako student VŠE vytvořený účet. Operační systém nebyl aktivován a po dokončení testování byl spolu s celým virtuálním serverem odstraněn.

33

ní, resp. pro přidělení fyzických / virtuálních síťových adaptérů. V našem případě zvolíme Network 1, která představuje NIC 1 (a tedy eth1). Poslední krok průvodce zobrazuje shrnutí zvolených nastavení. Po zaškrtnutí Start the new VM automatically se virtuální stroj po svém vytvoření automaticky spustí. Vloţíme instalační médium do DVD mechaniky na fyzickém serveru a klikneme na Finish.

Obrázek 11: Vytvoření virtuálního stroje, první krok - výběr šablony

Po vytvoření virtuálního stroje na serveru se tento stroj spustí. Proběhne bootování z CD a spustí se instalace operačního systému. Přepneme se na tento virtuální stroj kliknutím na jeho název v levém panelu a vpravo zvolíme záloţku Console. Nyní můţeme tento stroj ovládat stejně, jako jakoukoliv jinou pracovní stanici. (S výjimkou trojkombinace CTRL + ALT + DELETE, která se vykoná na stroji, ve kterém běţí XenCenter. Pro zaslání této trojkombinace virtuálnímu stroji slouţí na panelu Console speciální tlačítko.) Instalace OS je zcela standardní a proto ji zde nebudu popisovat. Po nainstalování OS (resp. i v jeho průběhu) bychom mohli proces vytvoření virtuální stanice opakovat znovu, pro vytvoření zbývajících stanic. V tomto případě je ale

34

lepším řešením vytvořit tzv. Snapshot (snímek) čerstvě nainstalované stanice a vytvořit virtuální stroj jako kopii tohoto stroje. Přepneme se tedy na nově nainstalovaný virtuální stroj, zvolíme záloţku Snapshots a klikneme na tlačítko Take Snapshot… Zadáme název snímku a případný popis. Po potvrzení se vytvoří kopie disku (ve verzi zdarma není moţno vytvářet snímek operační paměti virtuálního stroje). Nyní spustíme průvodce pro vytvoření virtuálního stroje a jako šablonu zvolíme námi vytvořený snímek. Zbylé kroky průvodce můţeme přeskočit a po kliknutí na Finish se vytvoří identická kopie původního virtuálního stroje. Nyní je nutné změnit název počítače v OS Windows, protoţe jinak by stejné názvy v síti kolidovaly. IP adresu systém získává z DHCP serveru, takţe zde problém nebude. Na stanici Windows XP (2) nainstalujeme Internetovou Informační Službu (IIS) a to tak, ţe v Ovládacích panelech zvolíme Přidat nebo odebrat programy, dále Přidat nebo odebrat součásti systému a zde zvolíme Internetová Informační Služba. Po potvrzení se IIS nainstaluje. Poté v adresáři C:\Inetpub\wwwroot vytvoříme soubor index.asp s obsahem: Nyní je: <%response.write(date())%> <%response.write(time())%>

Skript bude po načtení stránky zobrazovat aktuální datum a čas, čímţ zabráníme uloţení stránky do cache prohlíţeče, a stránka bude vţdy stahována znovu. Máme tedy nainstalovány tři virtuální stanice: -

Windows XP, testovací stanice, IP: 192.168.2.102

-

Windows XP (2), stanice s nainstalovaným IIS, IP 192.168.2.104

-

Windows XP (3), stanice generující síťový provoz, IP 192.168.2.105

6.5 Příprava síťového prostředí pro testování Pro běţné testy sítě, jako jsou testy propustnosti, zpoţdění, ztrátovost paketů apod. není nutno dělat ţádné úpravy (snad jen správně nastavit firewall). Aby ale bylo moţné stanici vyuţít pro zachytávání paketů, které se po síťovém rozhraní pohybují, je nutno nastavit toto rozhraní do promiskuitního reţimu. XenServer reprezentuje kaţdé fyzické síťové rozhraní jako objekt typu PIF a kaţdé virtuální síťové rozhraní jako objekt typu VIF. Je-li virtuální stanice součástí externí sítě, tj. můţe komunikovat s nevirtuálním prostředím (nebo virtuálním prostředím na jiném fyzickém serveru), pak je prostřednictvím objektu VIF připojena na síťové 35

rozhraní reprezentované objektem PIF. Pro potřebu analýzy paketů je nutno oba objekty (PIF i VIF), ke kterým je testovací stanice připojena nastavit do promiskuitního reţimu. To lze udělat pouze v konzoli příkazového řádku XenServeru. Spustíme tedy konzoli (buď přímo na fyzickém serveru, nebo prostřednictvím okna Console v XenCenter při zvoleném virtuálním serveru v levém sloupci). Nejprve je nutno zjistit uuid (unikátní ID) objektu PIF. Toho docílíme tímto příkazem: # xe pif-list params=uuid,device,network-name-label

Uvedený příkaz nám vrátí tento výsledek 12: uuid ( RO)

: e44a0232-9612-3e7a-5f18-42a3fe2c3aaf device ( RO): eth1 network-name-label ( RO): Pool-wide network associated with eth1

uuid ( RO)

: 1a19105e-e5b5-2f7f-1780-d6bb11f768b0 device ( RO): eth0 network-name-label ( RO): Pool-wide network associated with eth0

Protoţe virtuální stanice je připojena k rozhraní Network 1, které je hostováno na NIC 1, coţ je alias pro eth1, bude nás zajímat první uvedené zařízení. Nyní toto zařízení nastavíme do promiskuitního reţimu: # xe pif-param-set uuid=e44a0232-9612-3e7a-5f18-42a3fe2c3aaf other-config:promiscuous="on"

Hodnotu uuid není nutno opisovat celou, XenServer nabízí funkci dokončování parametrů a po zadání prvních písmen hodnoty stačí stisknout klávesu TAB a hodnota se dopíše automaticky. Správné provedení příkazu si ověříme zadáním: # xe pif-list uuid=e44a0232-9612-3e7a-5f18-42a3fe2c3aaf params=uuid,other-config

Správně nastavená hodnota by měla vypadat takto: uuid ( RO) : e44a0232-9612-3e7a-5f18-42a3fe2c3aaf other-config (MRW): promiscuous: on

Nyní musíme nastavit promiskuitní reţim i pro objekt VIF, proto si vypíšeme seznam těchto objektů příkazem: # xe vif-list params=uuid,vm-name-label

12

UUID je unikátní ID a proto je v kaţdé instalaci XenServeru jiné, náhodně vygenerované.

36

Jako výsledek je nám vrácen seznam objektů VIF a název virtuální stanice, která je k němu připojena: uuid ( RO) : f62b2c6e-2784-3fd7-c898-37be28d5a9ee vm-name-label ( RO): Windows XP uuid ( RO) : 939ef4a7-528e-5de0-1279-be10c1ab8b3b vm-name-label ( RO): Windows XP (2) uuid ( RO) : 7b5dcf8d-8e4e-04f2-646b-32192d4909bd vm-name-label ( RO): Windows XP (3)

Pro testování sítě budeme pouţívat stanici s názvem Windows XP (bez čísla). Nastavíme tedy její VIF do promiskuitního reţimu: # xe vif-param-set uuid=f62b2c6e-2784-3fd7-c898-37be28d5a9ee other-config:promiscuous="on"

Opět nemusíme opisovat uuid celé, stačí první znak a stisknout klávesu TAB. Zkontrolujeme správnost nastavení: # xe vif-param-list uuid=f62b2c6e-2784-3fd7-c898-37be28d5a9ee

Výstup musí obsahovat u parametru other-config hodnotu promiscuous: on: uuid ( RO)

: f62b2c6e-2784-3fd7-c898-37be28d5a9ee vm-uuid ( RO): b29d7721-ba7b-253a-8e80-2e63b1802ab7 vm-name-label ( RO): Windows XP allowed-operations (SRO): attach; unplug current-operations (SRO): device ( RO): 1 MAC ( RO): 92:c1:57:c2:39:e1 MAC-autogenerated ( RO): false MTU ( RO): 0 currently-attached ( RO): true qos_algorithm_type ( RW): qos_algorithm_params (MRW): qos_supported_algorithms (SRO): other-config (MRW): promiscuous: on network-uuid ( RO): af4e12c6-0fef-daec-f400-336501667339 network-name-label ( RO): Pool-wide network associated with eth1 io_read_kbs ( RO): 0.013 io_write_kbs ( RO): 0.009

37

Nyní uţ zbývá pouze restartovat síťové rozhraní. Proto odpojíme a následně znovu připojíme nastavovaný VIF: # xe vif-unplug uuid=f62b2c6e-2784-3fd7-c898-37be28d5a9ee # xe vif-plug uuid=f62b2c6e-2784-3fd7-c898-37be28d5a9ee

Tímto krokem je síťové rozhraní nastaveno pro analýzu paketů. Virtuální stanice Windows XP má nyní plný přístup k síťovému provozu na rozhraní Network 1. Ostatní virtuální stanice tento přístup nemají a tak nemohou zachytávat pakety.

6.6 Využití virtuální stanice pro testování sítě 6.6.1 Test propustnosti sítě Pro test propustnosti sítě vyuţijeme konzolovou aplikaci NETIO - Network Throughput Benchmark13. Aplikace funguje v reţimu klient – server, tedy musí být spuštěna jak na testované stanici (v reţimu server), tak na testovací stanici (v reţimu klient). V reţimu server naslouchá NETIO standardně na TCP a UDP portech číslo 18767. Klient se při testování připojuje jen na jeden port v jeden okamţik, tj. buď na TCP nebo na UDP. Dále lze zvolit velikost přenášených paketů v bajtech. V rámci této práce otestujeme propustnost sítě mezi stanicemi Windows XP (klient) a Windows XP (2) (server) s nejmenším a největším paketem, který je doporučován pro testy v rámci ethernetových sítí, tj. s pakety o velikosti 64 a 1 518 bajtů, na portu TCP. Nejprve spustíme na testované stanici NETIO v reţimu server: C:\>netio.exe -s NETIO - Network Throughput Benchmark, Version 1.31 (C) 1997-2008 Kai Uwe Rommel TCP server listening. UDP server listening.

13

Freeware utilita ke staţení ze stránek http://www.ars.de/netio

38

Nyní se přepneme do testovací stanice a spustíme test na TCP portu s paketem o velikosti 64 bajtů, po jeho dokončení spustíme test s paketem o velikosti 1 518 bajtů. (Parametr –t určuje TCP port, parametr –b určuje velikost paketu v bajtech.): C:\>netio.exe -t -b 64b 192.168.2.104 C:\>netio.exe -t -b 1518b 192.168.2.104

Po spuštění kaţdého testu se zobrazí výstup jako v následujícím rámečku. (Z důvodu úspory místa jsem sloučil oba výstupy do jednoho rámečku.) NETIO - Network Throughput Benchmark, Version 1.31 (C) 1997-2008 Kai Uwe Rommel TCP connection established. Packet size 64 bytes: 1224.91 KByte/s Tx, 872.88 KByte/s Rx. Packet size 1518 bytes: 9158.34 KByte/s Tx, 5408.12 KByte/s Rx. Done.

Výsledek zobrazuje maximální dosaţenou rychlost zápisu (klient  server, Tx – Transmit) a čtení (server  klient, Rx – Receive). Z výsledků vyplývá, ţe paket o větší velikosti cestuje sítí rychleji, neţ malý paket. Vzhledem k tomu, ţe síťový adaptér, ke kterému jsou připojené virtuální stanice je typu Fast Ethernet, je maximální dosaţitelná přenosová rychlost 12,5 MB/s. Při velikosti paketu 1 518 bajtů je tedy při zápisu dosaţeno rychlosti rovné 71,5% teoretické propustnosti linky. 6.6.2 Test zpoždění a míry ztrátovosti rámců Pro tento test pouţijeme standardní ICMP ping, který je součástí OS Windows XP. V tomto testovacím prostředí můţeme zanedbat moţnost zkreslení hodnot vlivem niţší priority ICMP paketů vůči ostatním paketům. Test provedeme odesláním 100 ping poţadavků z testovací stanice Windows XP na stanici Windows XP (2): C:\>ping –n 100 192.168.2.104

Po odeslání zadaného počtu poţadavků dostaneme výsledek: ... Odpověď od 192.168.2.104: bajty=32 čas < 1ms TTL=128 Statistika ping pro 192.168.2.104: Pakety: Odeslané = 100, Přijaté = 100, Ztracené = 0 (ztráta 0%), Přibližná doba do přijetí odezvy v milisekundách: Minimum = 0ms, Maximum = 1ms, Průměr = 0ms

39

Tento výsledek vypovídá o tom, ţe zpoţdění mezi jednotlivými virtuálními stroji prakticky neexistuje. Počet ztracených paketů roven nule vypovídá o stabilitě linky. Pro ověření zpoţdění jsem provedl ping z testovací stanice Windows XP i mimo virtuální prostředí a to na notebook, ze kterého je prováděna správa virtuálního serveru, který je připojen k routeru bezdrátově. IP adresa notebooku je 192.168.2.100. C:\>ping –n 100 192.168.2.104

Hodnoty tohoto testu jiţ vypadají reálněji. Dokonce se zde vyskytuje i jeden ztracený paket, který při 100 odeslaných testovacích paketech znamená 1% ztrátu. ... Odpověď od 192.168.2.100: bajty=32 čas=3ms TTL=128 Statistika ping pro 192.168.2.100: Pakety: Odeslané = 100, Přijaté = 99, Ztracené = 1 (ztráta 1%), Přibližná doba do přijetá odezvy v milisekundách: Minimum = 1ms, Maximum = 71ms, Průměr = 2ms

6.6.3 Analýza paketů Pro analýzu paketů jsem zvolil program Wireshark14, který jsem nainstaloval na testovací stanici Windows XP. Instalace je standardní, nejprve je nutno odsouhlasit licenční podmínky, v dalším kroku se volí instalované součásti. Následuje volba vytvoření zástupců v nabídce Start a na ploše a moţnost asociace souborů vytvářených Wiresharkem. V dalším kroku uţivatel zadá, kam chce Wireshark nainstalovat. Posledním krokem je volba, zda se má nainstalovat WinPcap. Ten je důleţitý při instalaci Wiresharku na systém s OS Windows, protoţe umoţňuje nízko-úrovňový přístup k síťovému adaptéru, který jinak z prostředí OS Windows není moţný. Po kliknutí na tlačítko Install začne samotná instalace. Po jejím dokončení lze spustit Wireshark, který je připravený k zachytávání paketů. V úvodním okně tedy klikneme na Capture Options v sekci Capture. Zde vybereme poţadovaný síťový adaptér, na kterém chceme zachytávat komunikaci (v našem případě máme pouze jeden síťový adaptér), zkontrolujeme, zda je zaškrtnuto Capture packets in promiscuous mode. Zbylá nastavení jsou volitelná, a je můţeme ponechat beze změny. Po kliknutí na Start bude automaticky zahájeno zachytávání komunikace na daném síťovém adaptéru. Jako první test jsem zvolil ICMP ping ze stroje Windows XP (3) na stroj Windows XP (2). Výsledek zobrazuje Obrázek 12.

14

Freewarovou aplikaci lze stáhnout z webových stránek http://www.wireshark.org/

40

Obrázek 12: Wireshark, zachycené pakety při ICMP pingu

Ze zachycených paketů lze vyčíst, ţe po úvodním poţadavku ze stanice s IP 192.168.2.105 na ping stanice 192.168.2.104, byl vyslán prostřednictvím protokolu ARP dotaz na MAC adresu stanice, jeţ zaslala ping poţadavek. ARP protokolem byla tato MAC adresa vrácena a následovně byla zaslána odpověď na ping. Přesto, ţe byl mezi dotaz a odpověď vloţen poţadavek na zjištění MAC adresy, byla výsledná hodnota zpoţdění < 1 ms, coţ je vidět ve sloupci Time, kde lze vyčíst, ţe od vyslání poţadavku, do odpovědi uplynulo 0,394 ms. Druhý zaslaný paket v rámci pingu cílové stanice jiţ nevyvolal dotaz na MAC adresu. V druhém testu byla ze stanice Windows XP (2) otevřena ve webovém prohlíţeči stránka http://www.vse.cz/.

Obrázek 13: Wireshark, http požadavek na www.vse.cz

41

Z obrázku je patrné, ţe stránka byla načtena za 1,258 sekundy. Pro její načtení bylo vyuţito celkem 524 paketů. První dva pakety patřily dotazu na MAC adresu routeru prostřednictvím protokolu ARP, následovaly dva pakety protokolu DNS s dotazem na www.vse.cz. Odpovědí bylo, ţe www.vse.cz je CNAME (alias) pro devetsil.vse.cz s IP adresou 146.102.16.4. Následovaly pakety protokolu TCP, které přenášely obsah webové stránky a pakety protokolu HTTP, které odkazovaly na další stránky, které poté byly opět prostřednictvím protokolu TCP přeneseny.

6.7 Závěr Cílem této případové studie bylo vytvořit virtuální stanici pro testování sítě. Během psaní této práce jsem otestoval tři různá řešení pro virtualizaci serveru. Jako nejvhodnější pro splnění cíle jsem shledal produkt XenServer společnosti Citrix, který jako jediný splňoval obě podmínky, které jsem si k výběru stanovil a to: -

moţnost připojit virtuální stanici přímo na fyzické síťové rozhraní

-

snadnost a přehlednost konfigurace

V případové studii se podařilo zvoleného cíle dosáhnout – virtuální stanice byla úspěšně připojena přímo na fyzický síťový adaptér a tento byl na serveru nastaven tak, aby umoţňoval stanici přímý přístup k datům, která po něm proudí. Na samotné virtuální stanici pak byl mimo jiné nainstalován program pro analýzu paketů, který úspěšně zachytával komunikaci ostatních stanic. Moţnosti testovací stanice pro testování sítě jistě nebyly v této práci vyčerpány. Stanice je však po provedení uvedených kroků připravena k nasazení jakéhokoliv testovacího software. Závěrem bych chtěl ještě jednou upozornit, ţe popis instalace softwaru pro zachytávání paketů nemá slouţit k vytvoření stanice pro jakékoliv nezákonné či nemorální monitorování síťové komunikace. Uvedený software má slouţit pouze pro účely správy síťového prostředí.

42

Závěr V dnešní moderní době se setkáváme s virtualizací čím dál častěji. Cílem této práce bylo nejprve uvést teoretický základ k virtualizaci, její typy a druhy a následně ukázat i jeden moţný způsob jejího vyuţití. Nejprve jsem v první kapitole popsal rozdíl mezi bare-metal a hostovanou virtualizací, ve druhé kapitole jsem uvedl jednotlivé typy virtualizace a ve třetí kapitole jsem popsal virtuální lokální sítě. Informace z těchto tří kapitol tvoří základ pro porozumění čtvrté kapitole o řešeních pro virtualizaci. Všechna uvedená řešení pracují jako baremetal hypervisory, virtualizace stanic probíhá v reţimu paravirtualizace a ve všech těchto virtuálních serverech se setkáváme s virtuální lokální sítí. Ve čtvrté kapitole jsem popsal instalaci a základní informace o řešení sítí ve třech vybraných produktech pro virtualizaci serveru. Byly zvoleny produkty od vedoucích společností na virtualizačním trhu. Z testovaných produktů mi subjektivně nejlepší přišel vSphere Hypervisor od VMware. Jeho instalace je rychlá, prvotní konfigurace jednoduchá. Klient pro vzdálenou správu má příjemné a intuitivní prostředí. Provedené změny v nastavení virtuální stanice se většinou provedou i při spuštěné virtuální stanici (včetně případu, ţe na této stanici nejsou nainstalovány nástroje VM Tools). V těsném závěsu za vSphere subjektivně hodnotím XenServer od Citrixu, který také nabízí bezproblémovou instalaci a prvotní konfiguraci, i vcelku intuitivní prostředí pro vzdálenou správu. Některá nastavení však jsou moţná jen přes konzoli příkazového řádku na serveru a navíc změny některých vlastností virtuálního stroje nelze aplikovat, pokud stroj běţí a nejsou na něm nainstalovány VM Tools, například změna síťového adaptéru. Jako poslední na pomyslném ţebříčku skončil Hyper-V Server od Microsoftu. Nejen, ţe instalace trvá nepoměrně dlouho oproti konkurenčním produktům, ale pro úspěšné nastavení vzdáleného přístupu pro konfiguraci serveru je nutno provést mnoho nastavení, která ani nejsou nikde rozumně zdokumentována a uţivatel si je musí najít na blogu Microsoftu. Toto řešení je dle mého názoru velice nešťastné. V páté kapitole jsem popsal základní moţnosti pro testování sítě, které jsou uváděny v RFC 2544, z nichţ některé jsem pak pouţil i v případové studii, ve které jsem úspěšně nainstaloval a nakonfiguroval virtuální stanici pro testování sítě.

43

Cíl práce, kterým bylo uvést informace o moţnosti virtualizace a vytvořit virtuální stanici pro testování sítě, tak byl splněn. Jako základní přínos práce shledávám, ţe v době psaní práce se této tématice – tedy vyuţití virtuální stanice pro testování sítě – nevěnuje ţádný ucelený materiál a to ani v českém, ani v anglickém jazyce. Tato práce můţe slouţit jako jednoduchý a srozumitelný návod na vytvoření virtuální testovací stanice.

44

Slovník pojmů EAP Zkratka z anglického „Extensible Authentication Protocol“ (rozšiřitelný autentifikační protokol). Protokol slouţí k autentizaci uţivatele. Umoţňuje pouţít různé autentizační metody, od pouţití jednorázového hesla, aţ po bezpečnostní certifikáty. ISP Zkratka z anglického „Internet Service Provider“ – posktovatel internetu LAN Zkratka z anglického „Local Area Network“ označující místní (lokální) síť. „Počítačová síť vznikne ve chvíli, kdy dva (někdy se říká minimálně tři) nebo více počítačů propojíme dohromady pomocí telekomunikačního systému za účelem sdílení zdrojů.“ [3] LAN označuje počítačovou síť v malém geografickém území, typicky v rámci jedné budovy, patra, nebo místnosti. Live OS Označuje operační systém, který je moţné spustit z vyměnitelného média (CD, DVD, USB flash disk, …). Tyto OS nevyţadují instalaci a jejich spuštěním nedojde k modifikaci dat uloţených na pevných discích. Jejich běh je zajištěn pouze v rámci operační paměti počítače. MAC adresa Zkratka z anglického „Media Access Control“. Jedná se o jedinečný identifikátor síťového zařízení sloţený z 12 hexadecimálních čísel. Prvních šest je přiděleno výrobci centrálním správcem adresního prostoru, dalších šest přiřazuje výrobce. Ţádná dvě zařízení by neměla mít stejnou MAC adresu. (Ve skutečnosti však lze u moderních síťových karet tuto adresu změnit a nastavit ji na libovolnou jinou.) NFS Zkratka anglického „Network File System“. Jedná se o protokol, který umoţňuje připojit k místnímu počítači disk, který je fyzicky zapojený ve vzdáleném (síťovém) počítači. S tímto diskem je pak moţno pracovat stejně, jako by byl fyzicky připojený k lokálnímu počítači.

45

NIC teaming Termín pro spojení několika fyzických síťových adaptérů do jednoho logického. Zvyšuje propustnost linky a předchází výpadkům síťového spojení při selhání adaptéru v týmu (za předpokladu, ţe zůstane alespoň jeden funkční). NTP Zkratka anglického „Network Time Protocol“. Protokol pro synchronizaci času v počítačích prostřednictvím počítačové sítě. OSI model Zkratka z anglického „Open System Interconnection Reference Model“. OSI model popisuje sedm vrstev, prostřednictvím kterých jsou transportována data mezi počítači v síti. RADIUS server Zkratka z anglického „Remote Authentication Dial In User Service“ (Uţivatelská vytáčená sluţba pro vzdálenou autentizaci). RADIUS server ověřuje za pouţití autentizačních schémat, jako např. EAP, zadané autentizační údaje, které mu byly zaslány prostřednictvím RADIUS protokolu. Pokud údaje souhlasí, pak server autorizuje přístup a má moţnost zaslat zpět mnoţství dalších informací (např. ID VLAN, do které má uţivatel přístup). ROM Zkratka z anglického „Read-Only Memory“ (paměť pouze pro čtení). Je v ní mimo jiné uloţen BIOS (zkratka z anglického Basic Input-Output Sytem), který zajišťuje inicializaci vstupně-výstupních zařízení při startu počítače. VLAN Zkratka z anglického „Virtual Local Area Network“ označující virtuální místní (lokální) síť. Hlavní výhodou je moţnost logického rozdělení sítě nezávislého na fyzickém uspořádání.

46

Použité zdroje Zdroje citací [1] Sochor, Jiří: Zpravodaj ÚVT MU - Údrţba softwaru Elektronický zdroj, publikován v lednu 1996, pouţit 2. dubna 2010 http://www.ics.muni.cz/zpravodaj/articles/61.html [2] Křenek, Michal: AbcLinuxu - nat - výkladový slovník Elektronický zdroj, publikován 16. srpna 2006, pouţit 3. dubna 2010 http://www.abclinuxu.cz/slovnik/nat [3] Bouška, Petr: Počítačové sítě a jejich typy Elektronický zdroj, publikován 9. července 2007, pouţit 1. června 2010 http://www.samuraj-cz.com/clanek/pocitacove-site-a-jejich-typy/

Zdroje obrázků [4] Bouška, Petr: VLAN – Virtual Local Area Network Elektronický zdroj, publikován 6. června 2007, pouţit 3. června 2010 http://www.samuraj-cz.com/clanek/vlan-virtual-local-area-network/ Umístění obrázku: http://www.samuraj-cz.com/gallery/000459.jpg

Ostatní odkazované zdroje [5] Kenneth Hess: Top 10 Virtualization Technology Companies Elektronický zdroj, publikován 20. dubna 2010, pouţit 20. listopadu 2010 http://www.serverwatch.com/trends/article.php/3877576/Top-10-VirtualizationTechnology-Companies.htm [6] S. Bradner, J. McQuaid: Request for Comments: 2544 (Benchmarking Methodology for Network Interconnect Devices) Elektronický zdroj, publikován v březnu 1999, pouţit 1. prosince 2010 http://www.ietf.org/rfc/rfc2544.txt [7] Citrix, Inc.: Citrix XenServer 5.6 Administrator's Guide Elektronický zdroj, publikován v červnu 2010, pouţit 5. září 2010 http://support.citrix.com/servlet/KbServlet/download/23735-102-646135/ Administrators_Guide.pdf [8] VMware, Inc.: ESXi Configuration Guide Elektronický zdroj, publikován v roce 2010, pouţit 3. září 2010 http://www.vmware.com/pdf/vsphere4/r41/vsp_41_esxi_server_config.pdf 47

Ostatní neodkazované zdroje WARD, B. VMware: provozujeme více operačních systémů na jednom počítači. Tištěný zdroj, vydal Computer Press, 2004 ISBN 80-251-0129-0 Tulloch M.: Understanding Microsoft Virtualization Solutions. Elektronická kniha, vydal Microsoft Corporation, 2009 ISBN: 9780735693371 http://download.microsoft.com/download/5/B/4/5B46A838-67BB-4F7C-92CBEABCA285DFDD/693821ebook.pdf Understanding Full Virtualization, Paravirtualization, and Hardware Assist Elektronický zdroj, publikován v roce 2007, pouţit 5. dubna 2010 Gössel, František: Virtualizace (opět) jako paradigma pro datacentra Elektronický zdroj, datum publikace nezjištěno, pouţit 3. dubna 2010 http://www.novell.cz/cs/aktuality/technicke-clanky/virtualizace-opet-jakoparadigma-pro-datacentra.html Miho: Typy virtualizace Elektronický zdroj, publikován 30. července 2008, pouţit 3. dubna 2010 http://miho.blog.zive.cz/2008/07/typy-virtualizace/ Matyska, Luděk: Techniky virtualizace počítačů (2) Elektronický zdroj, publikován 3. února 2007, pouţit 3. dubna 2010 http://www.ics.muni.cz/zpravodaj/articles/545.html Randhir I B: Server Virtualization: Just how many types are there? Elektronický zdroj, publikován 8. července 2009, pouţit 3. dubna 2010 http://www.infosysblogs.com/engineering-software/2009/07/ server_virtualization_just_how.html Stüble, Christian: The Hypervisor Layer Elektronický zdroj, datum publikace nezjištěno, pouţit 3. dubna 2010 http://www.perseus-os.org/content/pages/Hypervisor.htm Tomeček, Jaroslav: Virtualizace na úrovni jádra operačního systému Elektronický zdroj, publikován 31. července 2007, pouţit 4. dubna 2010 http://www.abclinuxu.cz/clanky/system/virtualizace-na-urovni-jadra-operacnihosystemu

48

Microsoft Technet: Protokol EAP (Extensible Authentication Protocol) Elektronický zdroj, datum publikace nezjištěno, pouţit 10. června 2010 http://technet.microsoft.com/cs-cz/library/cc782159(WS.10).aspx Bouška, Petr: Rozumíme počítačovým sítím Elektronický zdroj, publikován 9. května 2010, pouţit 10. června 2010 http://www.samuraj-cz.com/clanek/rozumime-pocitacovym-sitim/ Bouška, Petr: TCP/IP - adresy, masky, subnety a výpočty Elektronický zdroj, publikován 11. srpna 2008, pouţit 10. června 2010 http://www.samuraj-cz.com/clanek/tcpip-adresy-masky-subnety-a-vypocty/ Bouška, Petr: Víte, jak pracuje switch? Elektronický zdroj, publikován 25. května 2010, pouţit 10. června 2010 http://www.samuraj-cz.com/clanek/vite-jak-pracuje-switch/ Bouška, Petr: Ethernet - CSMA/CD, kolizní doména, duplex Elektronický zdroj, publikován 3. srpna 2007, pouţit 10. června 2010 http://www.samuraj-cz.com/clanek/ethernet-csmacd-kolizni-domena-duplex/ Bouška, Petr: VLAN - Virtual Local Area Network Elektronický zdroj, publikován 2. června 2007, pouţit 10. června 2010 http://www.samuraj-cz.com/clanek/vlan-virtual-local-area-network/ Bradner, S.: Request for Comments: 1242 (Benchmarking Terminology for Network Interconnection Devices) Elektronický zdroj, publikován v červenci 1991, pouţit 1. prosince 2010 http://www.ietf.org/rfc/rfc1242.txt

Citrix XenServer Citrix, Inc.: Citrix XenServer ® 5.6 Administrator's Guide Elektronický zdroj, aktualizován 16. června 2010, pouţit 20. června 2010 http://support.citrix.com/servlet/KbServlet/download/23735-102646135/Administrators_Guide.pdf Přehled produktů společnosti Citrix, Inc. Elektronický zdroj, datum publikace nezjištěno, pouţit 20. června 2010 http://citrix.com/English/ps2/products/product.asp?contentID=1857200

49

Citrix, Inc.: XenServer features by edition Elektronický zdroj, datum publikace nezjištěno, pouţit 20. června 2010 http://www.citrix.com/English/ps2/products/subfeature.asp?contentID=2300456 Citrix, Inc.: XenServer VLAN Networking Elektronický zdroj, publikován 28. prosince 2009, pouţit 20. června 2010 http://support.citrix.com/article/CTX123489

Microsoft Hyper-V Server 2008 R2 Microsoft Technet: Overview of Hyper-V Elektronický zdroj, publikován v prosinci 2008, pouţit 21. června 2010 http://technet.microsoft.com/cs-cz/library/cc816638(WS.10).aspx Microsoft Technet: Hyper-V Getting Started Guide Elektronický zdroj, publikován v červenci 2009, pouţit 21. června 2010 http://technet.microsoft.com/cs-cz/library/cc732470(WS.10).aspx Microsoft Technet: Configuring Virtual Networks Elektronický zdroj, publikován v únoru 2009, pouţit 21. června 2010 http://technet.microsoft.com/cs-cz/library/cc816585(WS.10).aspx Armstrong, Ben: Configuring Remote Management of Hyper-V Server - in a workgroup Elektronický zdroj, publikován 11. listopadu 2010, pouţit 16. listopadu 2010 http://blogs.msdn.com/b/virtual_pc_guy/archive/2010/11/11/configuring-remotemanagement-of-hyper-v-server-in-a-workgroup.aspx Howard, John: Hyper-V: What are the uses for different types of virtual networks? Elektronický zdroj, publikován 17. června 2008, pouţit 21. června 2010 http://blogs.technet.com/b/jhoward/archive/2008/06/17/hyper-v-what-are-the-usesfor-different-types-of-virtual-networks.aspx Microsoft Technet: Requirements and Limits for Virtual Machines and Hyper-V in Windows Server 2008 R2 Elektronický zdroj, aktualizován 25. srpna 2010, pouţit 5. prosince 2010 http://technet.microsoft.com/en-us/library/ee405267(WS.10).aspx

50

VMware vSphere Hypervisor VMware, Inc.: Introducing VMware vSphere Hypervisor 4.1 - the free edition of VMware vSphere 4.1 Elektronický zdroj, publikován 13. července 2010, pouţit 2. října 2010 http://blogs.vmware.com/vsphere/2010/07/introducing-vmware-sphere-hypervisor41-the-free-edition-of-vmware-vsphere-41.html Shimonski, Robert J.: Using VMware: Understanding the Virtual Switch Elektronický zdroj, publikován 3. září 2008, pouţit 2. října 2010 http://www.virtualizationadmin.com/articles-tutorials/vmware-esx-articles/ installation-deployment/vmware-understanding-virtual-switch.html VMware, Inc.: Performance Best Practices for VMware vSphere™ 4.1 Elektronický zdroj, publikován v roce 2010, pouţit 2. října 2010 http://www.vmware.com/pdf/Perf_Best_Practices_vSphere4.1.pdf VMware, Inc.: Configuration Maximums Elektronický zdroj, publikován v roce 2010, pouţit 5. prosince 2010 http://www.vmware.com/pdf/vsphere4/r41/vsp_41_config_max.pdf

51