Vysoká škola ekonomická v Praze

Transkript

1 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

2 Č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 Jakub Jáchym 2

3 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

4 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

5 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

6 Obsah Abstrakt... 4 Abstract... 5 Úvod Způsoby virtualizace Bare-metal virtualizace Hostovaná virtualizace Typy virtualizace Emulace Plná virtualizace Paravirtualizace Virtualizace na úrovni jádra operačního systému Aplikační virtualizace Virtuální sítě Fyzická LAN Virtuální LAN Připojení do VLAN Virtualizace softwarová řešení Citrix Systems Citrix XenServer Microsoft Hyper-V Server 2008 R VMware VMware vsphere Hypervisor Srovnání produktů Testování sítě Propustnost sítě (throughput)

7 5.2 Zpoţdění (latency) Míra ztrátovosti rámců Zpracování navazujících rámců Rychlost obnovy systému po přetíţení Rychlost obnovy systému po resetu Analýza paketů (packet sniffing) Případová studie Úvod Parametry fyzického serveru Virtuální server Virtuální stanice Příprava síťového prostředí pro testování Vyuţití virtuální stanice pro testování sítě Test propustnosti sítě Test zpoţdění a míry ztrátovosti rámců Analýza paketů Závěr Závěr Slovník pojmů Pouţité zdroje

8 Ú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

9 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, hovoří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

10 přes vlastní ovladače, a na microkernel 1 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ém 3. 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 Česky mikro jádro Anglicky Host OS Anglicky Guest OS 10

11 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 stroji 4, takový virtuální, tzv. hostovaný stroj 5, 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átor 6 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 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

12 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řípad- 12

13 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 okruhy 7, 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

14 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 AMD- V). 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

15 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

16 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

17 Pokud potřebujeme pouze omezit broadcasty mezi subnety, můţeme pouţít např. router, nebo dnes častěji pouţívaný L3 switch 9. 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

18 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

19 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

20 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 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íčky 10, 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

21 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 em. 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

22 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

23 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 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í pod- 23

24 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 VMware vsphere Hypervisor 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

25 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

26 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 Microsoft HyperV Server 2008 R2 - VMware vsphere Hypervisor

27 Vlastnost Citrix XenServer Microsoft HyperV VMware vsphere Podporovaná architektura hostitelského stroje 64 bit 64 bit 64 bit Nutnost HW virtualizace (Intel VT-x nebo AMD-V) ano, pro spuštění ano ne neupravených OS Maximální počet fyzických CPU / velikost RAM 64 / 256 GB 64 / 1 TB 128 / 1 TB Podporovaná disková uložiště lokální disk, Fibre Channel, lokální disk, Fiber Chan- lokální disk, Fibre Chan- iscsi, NFS, SAS nel, iscsi, SAS nel, iscsi, NAS, SAS Podporovaná architektura hostovaných strojů 32 bit, 64 bit 32 bit, 64 bit 32 bit, 64 bit Podporované hostitelské OS a jejich min. verze CentOS 4.5, Debian Leny, Oracle Enterprise 5.0, RetHat 4.5, SUSE 10, Windows XP SP 2 RedHat Enterprise Linux 5 SUSE 10, Windows Server 2000 SP4, Windows XP SP3 CentOS 4.5, Debian 4.0, FreeBSD 6.3, RedHat Enterprise Linux 2.1, Windows 95, a další 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 8 / dle maxima OS / 2TB / 7 4 / 64 GB / 2 TB / 12 8 / 255 GB / 2 TB / 10 Možnost připojit virtuální stroj na virtuální switch ne, bez externích řešení ano ano Možnost připojit virtuální stroj přímo na fyzické síťové nezjištěno, ano ne rozhraní pravděpodobně ne Podpora VLAN ano ano ano Tabulka 1: Srovnání nástrojů pro virtualizaci serverů od různých výrobců

28 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í

29 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

30 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

31 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

32 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, 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 / 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 fy- 32

33 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 /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 MB RAM - 8GB pevný disk - 1x síťový adaptér Operační systém byl zvolen MS Windows XP Professional CZ 11. 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 rozhra- 11 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

34 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

35 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: Windows XP (2), stanice s nainstalovaným IIS, IP Windows XP (3), stanice generující síťový provoz, IP 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

36 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) : e44a e7a-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=e44a e7a-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=e44a e7a-5f18-42a3fe2c3aaf params=uuid,other-config Správně nastavená hodnota by měla vypadat takto: uuid ( RO) : e44a e7a-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

37 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 fd7-c898-37be28d5a9ee vm-name-label ( RO): Windows XP uuid ( RO) : 939ef4a7-528e-5de 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 fd7-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 fd7-c898-37be28d5a9ee Výstup musí obsahovat u parametru other-config hodnotu promiscuous: on: uuid ( RO) : f62b2c6e fd7-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-f network-name-label ( RO): Pool-wide network associated with eth1 io_read_kbs ( RO): io_write_kbs ( RO):

38 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 fd7-c898-37be28d5a9ee # xe vif-plug uuid=f62b2c6e fd7-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ě Test propustnosti sítě Pro test propustnosti sítě vyuţijeme konzolovou aplikaci NETIO - Network Throughput Benchmark 13. 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 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 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) Kai Uwe Rommel TCP server listening. UDP server listening. 13 Freeware utilita ke staţení ze stránek 38

39 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 bajtů. (Parametr t určuje TCP port, parametr b určuje velikost paketu v bajtech.): C:\>netio.exe -t -b 64b C:\>netio.exe -t -b 1518b 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) Kai Uwe Rommel TCP connection established. Packet size 64 bytes: KByte/s Tx, KByte/s Rx. Packet size 1518 bytes: KByte/s Tx, 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 bajtů je tedy při zápisu dosaţeno rychlosti rovné 71,5% teoretické propustnosti linky 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 Po odeslání zadaného počtu poţadavků dostaneme výsledek:... Odpověď od : bajty=32 čas < 1ms TTL=128 Statistika ping pro : 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

40 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 C:\>ping n 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 : bajty=32 čas=3ms TTL=128 Statistika ping pro : 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 Analýza paketů Pro analýzu paketů jsem zvolil program Wireshark 14, 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 Freewarovou aplikaci lze stáhnout z webových stránek 40

41 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 na ping stanice , 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 Obrázek 13: Wireshark, http požadavek na 41