SEMESTRÁLNÍ PROJEKT 2

Transkript

1 Vysoké učení technické v Brně Fakulta elektrotechniky a komunikačních technologií Bakalářský studijní program Teleinformatika SEMESTRÁLNÍ PROJEKT 2 Modelování síťových aplikací a měření provozu v prostředí OPNET 2005/2006 Otto ZEMAN, Brno

2 Obsah 1 Opnet Modeler Úvod základní charakteristiky Opnet Modeler Základní prvky v OPNET Modeler Editory Editor projektu (Project Editor) Editor uzlu (Node Editor) Editor procesu (Process Editor) Editor procesu základní pravidla Modely síťových aplikací v prostředí Opnet Úvod Vzorová síť Obecný návrh vzorové sítě Nastavení aplikací Application Config Definice aplikací Application Config Předdefinované hodnoty Profile Config Profil aplikace Nastavení aplikací Nastavení serveru pro podporu aplikací Nastavení spojení klient server Nastavení spojení klient server Nastavení sledovaných parametrů statistik Simulace Nastavení a průběh simulace Výsledky simulace Hodnoty nastavení aplikací pro ověření výsledků simulace Naměřené hodnoty Aplikace Aplikace FTP Aplikace HTTP Aplikace Voice over IP (VoIP) Využití serveru Měření provozu Úvod Měřič toku dat Jednoduchý příklad z prostředí Opnet Výsledek měření pro jednoduchý příklad měriče Závěr Přílohy Výsledky naměřených hodnot Seznam obrázků Seznam tabulek Literatura Poděkování

3 1 Opnet Modeler 1.1. Úvod základní charakteristiky Opnet Modeler Program OPNET Modeler (OM) je simulační program, který slouží pro návrh, simulaci a analýzu sítí. Tento program dokáže modelovat velmi rozsáhlé sítě s vynikajícími vlastnostmi. Hlavní výhodou tohoto programu je jeho efektivnost a výkonnost. OPNET Modeler vyvinula firma OPNET Technologies Inc. Program umožňuje modelovat a zároveň simulovat jakékoliv architektury sítí. Základním kamenem OM je jeho grafické prostředí, díky kterému je práce v něm efektivnější a rychlejší. Velmi důležitou vlastností OM je široká možnost tvorby různých statistik z dané simulace. Tato vlastnost nabádá k použití OM všude tam, kde je třeba ověřit chování reálného objektu v různých extrémních podmínkách (např. chování serveru při vysoké zátěži apod.). S tím i souvisí, že někdy nemůžeme na reálnému objektu ověřit chování, které ani nemusí nastat, ale díky OM si jej můžeme nasimulovat, abychom znali výsledek chování reálného objetu v určité situaci a mohli díky této znalosti předcházet určitým popř. nežádoucím stavům. Výsledek určité statistiky můžeme generovat do zprávy ve formátech XML nebo HTML, nebo uložit data do tabulek. Opačně umí z těchto formátů načíst vstupní data. Dále obsahuje prohlížeč animací díky kterému můžeme názorně vidět průběh proběhlé simulace. Simulace probíhá s určitým zrychlením, takže je možné nasimulovat měsíční chování sítě v řádu hodin. Největší výhoda OM tkví v jeho objemných knihovnách, které mají dostupný zdrojový kód, z čehož plyne, že kód můžeme dále upravovat Základní prvky v OPNET Modeler Opnet Modeler má několik základních prvků a to: subnet podsíť (spojené stanice, servery, huby, switche apod.) node model model uzlu process model model procesu zde jsou definovány jednotlivé procesy modelu uzlu (např. vysílání řídích informací apod.) Podrobnější informace o jednotlivých prvcích viz. kap Editory Editory Jak už bylo napsáno v úvodu OM využívá objektově orientovaného programování a grafického editoru s aktuálními strukturami sítí. OM je jednoduchý hierarchický editor, který přesně popisuje spojení struktur, reálné sítě a protokolů. OM je tvořen z třech základních editorů: Project Editor editor projektu [viz kap 1.3.1] Node Editor editor uzlu [viz kap ] Process Editor editor procesu [viz kap ] - 2 -

4 Editor projektu (Project Editor) Editor projektu je grafický editor modelující topologii a komunikaci v síti. Síť obsahuje uzly (node) a odkazy na objekty konfigurovatelné přes dialogový box. Drag and drop funkce (táhni a pusť) editoru slouží k sestavení sítě. Dále je možné použití objektů z knihovny OM (Model Libary), nebo si vytvořit vlastní uzly a modely. Editor projektu má v sobě mapu, na které názorně představuje fyzické rozložení sítě. Editor projektu je zobrazen na obr. 1. Obr. 1 - Síťový model v editoru projektu Editor projektu - pracovní plocha V okně projektového editoru (viz obr. 1) je několik oblastí, které jsou důležité pro výstavbu a provedení modelu. Hlavní menu Tlačítka Textová oblast Tipy Hlavní menu - Každý editor má hlavní menu. Hlavní menu projektového editoru ukazuje názorné rozložení jednotlivých nabídek (viz obr. 2). Obr. 2 - Hlavní menu projektového editoru Tlačítka - Pod hlavním menu se nacházejí tlačítka, neboli buttons. Díky nim můžeme rychle aktivovat vybrané funkce editoru. Obr. 3 ukazuje rozložení tlačítek pro editor projektu

5 Obr. 3 - Tlačítka projektového editoru Vysvětlení tlačítek: 1. Otevřít paletu objektů 2. Ověření shody odkazu 3. Chybně vybraný objekt 4. Odebrat vybraný objekt 5. Zpět k rodičovské podsíti 6. Zvětšit náhled 7. Zmenšit náhled 8. Konfigurovat jednotlivé události simulace 9. Ukázat výsledek simulace 10. Ukázat základní webové zprávy 11. Skrýt nebo zobrazit grafy Textová oblast - Je umístěna dole v okně modeleru. Zprostředkovává informace o stavu provedené akce. Dále se tato ikona využívá pro zjištění poslední provedené operace (viz obr. 4). Obr. 4 Textová oblast projektového editoru Tipy - Pokud najedete kursorem na tlačítka nebo na položky menu, zobrazí se Vám bublina s kontextovou nápovědou (viz obr. 5). Obr. 5 Zobrazení tipů v projektového editoru Editor uzlu (Node Editor) Editor uzlu představuje rozhraní nižší úrovně než editor projektu. Ukazuje např. architekturu síťového zařízení nebo systému a vzájemné vztahy mezi funkčními modely a volanými funkcemi. Uzel se skládá z modulů. Moduly typicky představují aplikace, protokolové vrstvy, algoritmy a fyzické prostředky takové jako jsou buffery, porty a sběrnice. Každý modul může generovat, posílat a přijímat pakety od ostatních modulů uvnitř celého uzlu. Dále je možné komunikovat mezi uzly i jinak než pomocí znázorněných vazeb. To pomocí signálu zasílaných přímo konkrétnímu uzlu (procesu). To vyplívá z vlastnosti OM, a to že jsou prvky všech úrovní řazeny do stromové struktury celého modelu. Proto pokud chci poslat zprávu nějakému procesu s kterým nejsem přímo propojen a znám jeho jméno zjistím si ID rodičovského prvku a díky němu pak zjistím ID prvku, kterému pak zprávu pošlu. Další důležitou vlastností, která je užívaná v OM, je předávání hodnot atributů do vyšších úrovní. Díky této vlastnosti mohu klíčové parametry simulace, zobrazit u objektů nejvyšší úrovně a nemusím se složitě "proklikávat" k objektu, kterého se daný parametr konkrétně týká (např. IP adresy definované na procesním modelu popisujícím proces IP vrstvy)

6 Obr. 6 Editor uzlu Editor procesu (Process Editor) Editor procesu je rozhraní nejnižší úrovně. Slouží pro tvorbu konečného stavového automatu (FSM - Finite State Machines) přizpůsobeného snaze specifikovat všechny úrovně modelu do detailu (protokolu, prostředku aplikaci a algoritmu). Stavy a přechody jsou definovány v grafickém diagramu (viz. Obr. 7). Každý stav a proces modelu obsahuje kód v C/C++ podporovaný rozsáhlou knihovnou s funkcemi vytvořenými pro protokolové programování. Obr. 7 Editor procesu - 5 -

7 Editor procesu základní pravidla Zde jsou uvedeny základní pojmy, které jsou potřebné k práci v proces editoru. Jedná se hlavně o pojmy stav a přechod. Jak vypadá okno editoru procesu je možné vidět na Obr. 7 Editor procesu. Hlavní prvky, editoru procesu jsou: Stav (state) - představuje stav procesu. Proces může být např. čekání na zprávu od vysílače. Přechod (transition) - je změna stavu v odpovědi na událost Opnet vždy přidává do každého FSM fragment kódu C/C++. Máme 3 základní místa, kam můžeme vložit C/C++ kód v reprezentaci stavu. A to: Vstupní pozice (Enter Executive) - kód, který je vykonán ihned po přechodu do nového stavu procesu. Výstupní pozice (Exit Executive) - kód, který je proveden když proces opouští stav při přechodu do jiného stavu. Přechodová pozice (Transition Executive) - kód, který je proveden v odpovědi na specifickou událost. V prvních dvou případech je kód vykonán nezávisle na typu události, ale v posledním případě pouze při výskytu specifické události. Obr. 8 Editor procesu vstupní a výstupní pozice Dále definujeme typ stavu procesu. Ten může být dvojího typu: Vynucený (Forced) [v OM - zelený] - při přechodu procesu do tohoto stavu se vykoná kód, který tento stav obsahuje, a automaticky dojde k přechodu do dalšího stavu. Nevynucený (Unforced) [v OM - červený] - po přechodu do tohoto stavu v něm proces zůstává tak dlouho, dokud nedojde k další události. Každá událost je definována přerušením

8 Obr. 9 Editor procesu vynucený a nevynucený stav Dále definujeme přechod procesu. Ten může být taktéž dvojího typu: Podmíněný (Conditional) - je stanovena podmínka, která určuje pravidla přechodu do nového stavu, je li splněna, uskuteční se přechod do dalšího stavu. Nepodmínění (Unconditional) - stav přechází okamžitě do dalšího stavu. 2 Modely síťových aplikací v prostředí Opnet 2.1 Úvod Modely síťových aplikací budou vysvětleny ve vzorové síti, kde vytvořím několik různých aplikací jako např. http, ftp či . Tyto aplikace budou spuštěny v námi přesně definovaných intervalech. Výsledkem simulace budou statistky, které potvrdí naše nastavení a teoretické předpoklady. 2.2 Vzorová síť Vzorová síť obsahuje 5 podsítí, které představují jednotlivé města v ČR (Brno, Praha, Pardubice, Ostrava a Plzeň). Každá podsíť bude obsahuje tyto objekty: LAN Client jde o objekt, díky němuž můžeme definovat více stanic se stejnými vlastnostmi. Příklad je uveden na obr. Obr. 10. Obr. 10 Vzorový příklad pro LAN Client Každá pracovní stanice v LAN Clientu bude podporovat tyto aplikace o o o o HTTP - Zde bude provozován klient služby http. Půjde tedy o brouzdaní po internetu. FTP - Zde bude provozován klient aplikace ftp. Bude proveden upload a download souborů ze serveru. - Zde bude provozována klient aplikace . Voice - Půjde o telefonování pomocí VoIP klienta

9 Router pro spojení jednotlivých podsítí Server bude součástí podsítě Brno. Poskytuje server služby pro dané aplikace (HTTP, FTP, Voice, ). Výsledný vzorový příklad modelu síťových aplikací je možné vidět na Obr Obecný návrh vzorové sítě Nejdříve jsem si v OM vytvořil nový projekt a na jeho plochu umístit tyto objekty: Application Config Profile Config Subnet - podsíť Objekty vložíme na plochu po kliknutí na ikonu Object Palette - Configure Palette a vybereme položku LAN_Mod_Model_List. Poté co máme na ploše všechny tyto objekty, klikneme 2x na objekt subnet. Zde vložíme na plochu tyto dva objekty: 10BaseT_LAN pro vložení většího počtu stanic viz Obr. 10 BN_BLN_4s_e4_f_sl8 tr4 router Po té tyto objekty, propojíme síťovou technologií 10BaseT a to objektem z položky Object Palette - 10BaseT. Nyní je konfigurace podsítě hotova. Proto můžeme přejít o úroveň výše. K tomuto účelu použijeme ikonu Go to Parent Subnet. Zde pomocí známých příkazů Ctrl + c a Ctrl + v zkopírujeme 4x podsíť. Jména jednotlivých podsítí nastavíme na Brno, Praha, Pardubice, Ostrava a Plzeň. Dále musíme v jedné podsíti vložit objekt server pro podporu již zmíněných, provozovaných síťových aplikací. Proto opět 2x klineme na podsíť Brno a zde vložíme tyto objekty: Ethernet_server server BN_Accelar1050_1s_ae12_ge1 - přepínač Server propojíme síťovou technologií 10BaseT s vloženým přepínačem. Přepínač také propojíme toutéž technologií se směrovačem této podsítě. Nyní je konfigurace celé sítě hotova a jediné co zbývá, je pospojovat jednotlivé směrovače podsítí. To provedeme pomocí objektu PPP_DS1. Tento objekt představuje linku o přenosové rychlosti Mbps. Výsledná síť je zobrazena na Obr. 12 a na Obr. 11 je zobrazen příklad podsítě Brno. Obr. 11 Vzorový příklad pro podsíť Brno - 8 -

10 2.4 Nastavení aplikací Obr. 12 Vzorový příklad modelu s objekty subnet Každá aplikace je v OM tvořena dvěma objekty a to: Application Config uvedení aplikací, které se budou v síti provozovat, čili definice aplikací viz kap Profile Config aplikacím se zde přiřadí hodnoty, dle kterých např. aplikace budou spouštěny apod. viz kap Application Config Definice aplikací Pro definici aplikací se v OM používá objekt Application Config, který jsme si již umístili na plochu. Abychom mohli editovat jednotlivé aplikace, musíme kliknout pravým tlačítkem na objekt a z kontextového menu a zvolit Edit Attributes. Dále budeme editovat položku s názvem Application Definitions. Zde se zobrazí položka rows, která udává maximální počet námi definovaných aplikací. V položce name definujeme jméno aplikace. Jméno by mělo co nejlépe vystihovat danou aplikaci. Můžeme mít např. více FTP aplikací, proto vytvořenou aplikaci pojmenujeme např. FTP High Load. Abychom mohli definovat podrobnější chování aplikace klikneme na položku description. Pro standardní aplikace jako FTP, HTTP, apod. jsou již předdefinované hodnoty jako např. Low Load, Medium Load a High Load. Při výběru provozovaných aplikací máme na výběr z těchto možností: Custom vytvoření vlastní aplikace Database FTP HTTP Print Remote Login Video Conferencig Voice Tyto aplikace mají určité předdefinované hodnoty. Ty jsou více rozebrány v kap

11 Obr. 13 Příklad nastavení ftp aplikace V dalších kapitolách bude rozebrána nabídka předdefinovaných hodnot a také vytvoření vlastních hodnot, čili specifické nastavení aplikace Application Config Předdefinované hodnoty Pokud nebudeme chtít tvořit jedinečné aplikace, můžeme použít předdefinované hodnoty aplikací. OM má 16 předdefinovaných aplikací. Jsou to: Database Access (Heavy) Database Access (Light) (Heavy) (Light) File Transfer(Heavy) File Transfer (Light) File Print (Heavy) File Print (Light) Telnet Session (Heavy) Telnet Session (Light) Video Conferencing (Heavy) Video Conferencing (Light) Voice over IP Call (PCM Quality) Voice over IP Call (GSM Quality) Web Browning (Heavy HTTP 1.1) Web Browning (Light HTTP 1.1) U každé předdefinované aplikace lze samozřejmě editovat její charakteristické hodnoty. V dalším textu bude u 3 základních aplikací ( , FTP, HTTP) podrobněji rozebráno editování charakteristický hodnot. tato aplikace dovoluje nastavit následují hodnoty Send Interarrival Time (seconds) čas mezi dvěma poslanými y Send Group Size počet ů ve skupině před odesláním Receive Interarrival Time (seconds) - čas mezi dvěma přijatými y Receive Group Size - počet ů ve skupině před přijmutím Size (bytes) průměrná velikost u Symbolic Server Name symbolické jméno serveru s kterým klient komunikuje

12 Type of Service parametr QoS, kterým se určuje priorita provozovaných aplikací RSVP Parameters parametr pro rezervování šířky pásma FTP - tato aplikace dovoluje nastavit následují hodnoty Command Mix (Get / Total) poměr mezi příkazy pro download a všemi příkazy Inter-Request Time (seconds) doba, mezi dvěma žádostmi File size (bytes) průměrná velikost souboru Symbolic Server Name - symbolické jméno serveru s kterým klient komunikuje Type of Service - parametr QoS, kterým se určuje priorita provozovaných aplikací RSVP Parameters - parametr pro rezervování šířky pásma HTTP - tato aplikace dovoluje nastavit následují hodnoty HTTP Specification > o HTTP Version jméno podporované HTTP verze o Max Connections maximální počet HTTP připojení na server o Max Idle Period (seconds) maximální nevyužitá doba po spojení o Pipeline Buffer Size (requests) maximální počet žádostí, které můžou být společně buffrovány jednou aplikací o Page Interarrival Time (seconds) doba mezi dvěma staženými stránkami Page Properties > o Object size (bytes/object) průměrná velikost objektu o Number of Objevte (objects/page) počet objektů na stránce o Location symbolické jméno serveru, kde je objekt uložen Type of Service parametr QoS, kterým se určuje priorita provozovaných aplikací RSVP Parameters parametr pro rezervování šířky pásma Všechny tyto hodnoty lze buď vytvořit nové, nebo měnit již předefinované nastavení Profile Config Profil aplikace Pro definici profilu aplikace se používá objekt Profile Config. Ten už máme také na ploše. Opět přes položku Edit Attributes se dostaneme hlouběji do menu. Zde je opět položka rows, která nám nyní udává počet profilů. Důležité je, že počet profilů se nemusí rovnat počtu aplikací. Je tudíž možno, aby jeden profil měl v sobě více aplikací. Po zadání rows např. 1 se ukáží další položky, které platí pro námi vytvořený profil. Položky tohoto menu jsou: Profile Name jméno profilu Application zde vložíme aplikaci, kterou jsme vytvořili v objektu Application config o Rows počet aplikací, které se budou spouštět s tímto profilem o Name jméno aplikace, které jsme vytvořili v objektu Application config o Start Time Offset (seconds) zde nastavíme čas kdy se daná aplikace spustí. Když nastavíme např. 0, tak aplikace se bude spouštět ihned po začátku profilu. Tedy tento parametr závisí také na volbě Start Time profilu

13 o Duration doba trvání dané aplikace o Reapeatability udává počet opakování a časový odstup k dalšímu zopakování Operation Mode - definuje jak se budou dané aplikace spouštět o Serial (Ordered - spořádaný) - Může být spuštěna nejdříve jedna pak další aplikace. Pořadí je přesně určené od rows 1 až 2,3... o Serial (Random - náhodný) - Může být spuštěna nejdříve jedna pak další aplikace. Pořadí je náhodně určené. o Simultaneous - Všechny aplikace startují ve stejný čas. Start Time (sek) - definuje kdy bude profil spuštěn Duration (sek) - definuje dobu trvání profilu Reapeatability - udává se zde počet opakování a časový odstup k dalšímu zopakování U položky Start Time Offset je možné nastavit buď, aby aplikace začínala v přesně stanovený okamžik položka constant, nebo např. start v určitém časovém rozmezí, které je vyjádřené pravděpodobnostní funkcí. Položka pro tuto funkci je uniform. Samozřejmě je zde velké množství nastavení těchto funkcí např. (poisson, geomteric, lognormal, bernoulli atd.) Nastavení aplikací Pokud máme již nastavené definice a profily aplikací můžeme přejít k nastavení aplikací. Přejdeme tedy k editaci atributů klienta kliknutím na klienta a pravým tlačítkem vyvoláme menu, kde zvolíme položku Edit Attribites. Zde rozklikneme položku Application: Supported Profiles. Přidáme požadovaný počet položek v rows a zvolíme námi předem vytvořený profil aplikace. Obr. 14 Příklad nastavení aplikace FTP na Klient FTP V položce Application: Destination Preference zvolíme požadovanou aplikaci. Tato položka určuje spojení mezi specifickou definicí aplikace s reálným uzlem. Tato položka je podrobněji vysvětlena v kap Nastavení spojení klient server

14 2.4.4 Nastavení serveru pro podporu aplikací Objekt server máme již vložený na pracovní ploše. Budeme editovat jeho atributy a to položku Application: Destination Preference a Application: Supported Profiles a Application: Services. U poslední položky vložíme do Name jméno naší podporované služby a pole Description field nastavíme na Supported čili (podporováno). Obr. 15 Příklad nastavení podporovaných služeb na serveru Stejným způsobem se provede i konfigurace serverů pro služby http a Nastavení spojení klient server Toto nastavení je důležité pokud chceme vybrat konkrétní spojení mezi serverem a klientem. Pokud toto nastavení neprovedeme OM zvolí náhodně vybraný server a klienta v síti a provede na nich zvolené události. Proto tedy pokud chceme, aby určitý klient pracoval s určitým serverem musíme mu nastavit atribut Application: Destination Preference. Ten umožňuje mapovat symbolické jméno na aktuální jméno serveru. Jelikož každá aplikace používá symbolické jméno k odvolání se na určitý server. Server může zároveň mapovat více symbolických jmen. Proto pro výběr serveru je zde položka Selection Weight. Hodnota této položky řídí výběr serveru. Hodnota Server address identifikuje server podle jména, tato hodnota musí být pro každý server unikátní. Jestliže nespecifikujeme žádný cílový server, bude vybrán náhodný server podporující požadovanou aplikaci. Přidělíme unikátní jméno pro server nebo klienta nastavením jeho TPAL adresy. Tato adresa se přiřazuje editováním atributu pro server Server address, pro klienta Klient address a LAN Server name pro LAN Nastavení spojení klient server Nyní jednoduchý příklad jak nastavit spojeni klient server. Jelikož podrobně vysvětlený popis, jak nastavit aplikace a vytvoření jednoduché sítě je v kap. 2, popíší zde jenom problém spojení klient server. Další potřebně věci jsou uvedeny v kap. 2. Vytvořil jsem projekt a na plochu umístil 2 x LAN Client. Jeden LAN Client obsahuje 10 PC. Dále jsem vložil na plochu 2 x server a 1 x směrovač. Aplikace, která bude v sítí provozována je HTTP. Vytvořenou síť je možné vidět na Obr

15 Obr. 16 Spojení klient server příkladová síť V této sítí se budeme snažit, aby sk1 a sk2 komunikovala s objektem server1 a objekt server2 aby nebyl využíván. To zajistíme nastavením atributu Application: Destination Preference. Nejprve, ale musíme nastavit hodnoty Server Address na jednotlivých serverech. To nastavíme pomocí položky Edit Attributes - Server Address. Pro náš případ je hodnota server1 nastavena na adnode3 a pro server2 na adnode4. Příklad nastavení unikátní adresy je na Obr. 17. Obr. 17 Příklad nastavení unikátní adresy serveru Nyní můžeme kliknout levým tlačítkem myši na objekt sk1 a vybereme položku Edit Attributes. Zde zvolíme položku Application: Destination Preference. Zde budeme moci editovat tyto položky: Appliacation vybereme aplikaci, kterou chceme provozovat na server1. V našem případě je to aplikace http. Symbolic Name zde vložíme symbolické jméno serveru. Např. HTTP Server. Actual Name zde zvolíme položku Edit a tím se dostaneme do dalšího menu o Name zde vložíme adresu serveru s kterým náš klient bude pracovat. V našem případě tedy adnode3 o Selection Weight zvolíme hodnotu např. 10 Příklad tohoto nastavení je zobrazen na Obr

16 Obr. 18 Příklad nastavení Application: Destination Preference Toto samé nastavení provedeme i pro objekt sk2. Dále je nutné vybrat na objektu serveru statistiky, které budeme sledovat. Vybereme proto pro každý server položkou Choose Individulal DES Statistic statistku Server HTTP. Nyní můžeme celý projekt odsimulovat. To provedeme tlačítkem Run v hlavní nabídce DES nebo kliknutím na ikonu. Poté co proběhla simulace můžeme se podívat na její výsledky. Ty pro každý server zobrazíme položkou View Result. Naměřené hodnoty grafy jsou zobrazeny v kap. 5 - Přílohy - Obr. 24. Výsledek simulace dokazuje, že klienti ze sk1 a sk2 komunikovali pouze s objektem server1. Drobný přenos dat má i objekt server2, ale to je dáno pouze dotazy na server. Celkové zhodnocení zní, že se nám povedlo spojit určené klienty s určeným serverem. 2.5 Nastavení sledovaných parametrů statistik Jde o nastavení výstupu simulace, čili zachycení naměřených hodnot. Tyto hodnoty jsou zobrazovány v grafech, kde na ose je vynášen čas a na ose y je vynášena měřená veličina. Abychom mohli zobrazit výsledek (určitý graf) musíme nejprve přes položku Choose Individual DES Statistic vybrat jednotlivé sledované parametry. Tyto parametry můžeme nastavovat dvěma způsoby: Globálně pokud vybereme parametry v této sekci, budeme sledovat vybrané parametry na každém objektu v sítí Lokálně - pokud vybereme parametry v této sekci, budeme sledovat vybrané parametry jen na určitém objektu v sítí Příklad jednotlivých nastavení i s ukázkami bude ukázán v kap Simulace. 2.6 Simulace Pokud již máme celou síť nastavenou (definované aplikace, profily aplikací, podporované profily na straně klientů a serveru a vybrané sledované parametry statistiky), můžeme přejít k simulaci chování naší vytvořené sítě

17 2.6.1 Nastavení a průběh simulace Pro nastavení parametrů simulace zvolíme v hlavní nabídce položku DES - Configure/Run DES Event Simulation. Pro nastavení parametrů se používají tyto hodnoty: Duration (sek) - doba, kterou chceme odsimulovat v síti. V našem případě nastavíme hodnotu 200 seconds. Seed generátor náhodného čísla. Tato hodnota se mění v různých simulacích než dosáhne požadované statistické hodnoty ve výsledku. Values per statistic - počet hodnot, které budou sloužit k zobrazení statistky popř. grafu. Např Update interval - při simulaci udává, jak často se budě měnit křivka počtu událostí probíhající simulace (viz Obr. 19 Průběh simulace). Nastavil jsem hodnotu např událostí. Poté co již máme nastavené tyto parametry spustíme simulaci tlačítkem Run. Průběh simulace je zobrazen na Obr. 19 Průběh simulace. Obr. 19 Průběh simulace 2.7 Výsledky simulace Zde budou ukázány výsledky simulace. Pro porovnání výsledků, zde uvedu nastavené parametry pro jednotlivé aplikace. Každá aplikace na klientovi je spouštěna jedním profilem, který je spuštěn po 100 sekundách od začátku simulace Hodnoty nastavení aplikací pro ověření výsledků simulace Profil: LAN Client Start Time: uniform Duration: End of Simulation Operation Mode: Simultaneous

18 Aplikace: 1. File Transport (Heavy) o Start Time Offset: 0 sek o Duration: End of Profile 2. (Heavy) o Start Time Offset: 100 sek o Duration: End of Profile 3. Web Browning (Heavy) o Start Time Offset: 10 sek o Duration: End of Profile 4. Voice over IP Call (GSM Duality) o Start Time Offset: 150 sek o Duration: End of Profile Z toho nastavení vyplývá, že aplikace FTP bude spuštěna zároveň se zavedením profilu, tedy ve rozmezí sekundách. aplikace bude spuštěna po 100 sekundách od zavedení profilu, tedy cca po 200 sekundách od spuštění simulace. Dále HTTP aplikace bude spuštěna po 10 sekundách od zavedení profilu, tedy cca po 110 sekundách od spuštění simulace. Poslední aplikace VoIP bude spuštěna po 150 sekundách od zavedení profilu, tedy caa po 250 sekundách od spuštění simulace. Toto nastavení stručněji zobrazuje Tab. 1. Aplikace Čas po zavedení profilu [sek] Čas od zavedení simulace [sek] File Transport (Heavy) (Heavy) Web Browning (Heavy) Voice over IP Call (GSM Duality) Tab. 1 Nastavení spouštění jednotlivých aplikací profilu Naměřené hodnoty Zde jsou předvedeny výsledky jednotlivých aplikací. Pro ověření našeho správného nastavení použijeme hodnoty z kap Z grafů je patrné, že aplikace nezačínají přesně na sekundu dle našich hodnot. To je způsobeno zavedením profilu v rozmezí sekund s určitou pravděpodobností. V našem případě byl profil zaveden zhruba 90 sekund po spuštění simulace Aplikace Grafy tohoto měření jsou zobrazeny v kap. 5. Dle teoretických předpokladů aplikace měla být spuštěna po 200 sekundách od spuštění simulace, což z Obr. 25 a z Obr. 26 je zřejmé, že tento předpoklad je správný a platí. Obr. 25 zobrazuje tok dat, které jsou odeslány přes aplikaci v celé síti a Obr. 26 zobrazuje tok dat, které jsou odeslány přes aplikaci v podsíti Brno

19 Aplikace FTP Grafy tohoto měření jsou zobrazeny v kap. 5. Dle teoretických předpokladů aplikace FTP měla být spuštěna po 10 sekundách od zavedení profilu. Tento provoz je patrný Obr. 27 a Obr. 28, což dokazuje naše teoretické předpoklady Aplikace HTTP Grafy tohoto měření jsou zobrazeny v kap. 5. Dle teoretických předpokladů aplikace HTTP měla být spuštěna ihned od zavedení profilu. To také je patrné z Obr. 29 a Obr. 30. Tyto obrázky zobrazují výsledek měření odesílaného a přijímaného toku dat FTP aplikace v celé síti, resp. v podsítí Brno Aplikace Voice over IP (VoIP) Grafy tohoto měření jsou zobrazeny v kap. 5. Dle teoretických předpokladů aplikace VoIP měla být spuštěna po 150 sekundách od zavedení profilu. To je patrné z Obr. 31 a Obr. 32. Tyto obrázky zobrazují výsledek měření odesílaného a přijímaného toku dat VoIP aplikace v celé síti, resp. v podsítí Brno Využití serveru Grafy tohoto měření jsou zobrazeny v kap. 5. na Obr. 33 a Obr. 34. Tyto grafy zobrazují využití šířky pásma pro tři vybrané aplikace ( , HTTP, FTP). Obr. 33 zobrazuje využití šířky pásma ve směru ze serveru (např. download dat klientů ze serveru) a Obr. 34 ve směru na server (např. upload dat klientů na server). Z těchto grafů lze jednoznačně usuzovat, že nejnáročnější služba na požadavek šířky pásma je FTP aplikace poté HTTP aplikace a sní je co se týče šířky pásma rovnocenná aplikace . 3 Měření provozu 3.1 Úvod Model pro měření provozu může být aplikován v každém protokolu, který používá adresy s identifikátorem uzlu a identifikátorem příslušné sítě. Uživatelé smějí specifikovat pravidla pro měření toku dat, tedy data, která budou zpracována do statistik a data, která budou ignorována. Sesbíraná data slouží k výměně a porovnání více platforem. Tyto data se používají: K znalostem provozu v existující síti K rozvoji sítě K posouzení kvantifikace sítě K zajištění kvality služeb (QoS) K zjištění využití sítě uživatelem

20 3.2 Měřič toku dat Hlavní častí měření provozu je síťová entita, která se nazývá meter - měřič. Měřič sleduje pakety, které procházejí určitým bodem na jejich cestě sítí a dále je rozdělí do tříd. Pro každou třídu změří měřič datový tok od zákazníka s jeho datovým profilem. Datovým profilem rozumíme dohodnuté podmínky mezi zákazníkem a poskytovatelem. Ty pakety, které odpovídají danému profilu mohou vstoupit do sítě, zatímco ty, které neodpovídají jsou podmíněné podle TCS (Transparent Cache Switching propustné cache přepínání). Akce které mohou být provedeny jsou tvarování, přeznačení a zahození provozu. Datové profily jsou typicky popisované v pomocí definovaných token bucket parametrů. Většina meřičů je implementovaná jako token bucket. Token bucket je vysvětleno v kap Tocken Bucket r - rychlost doplňování tokenů Token bucket b velikost nádoby pakety, jejichž odchod byl povolen tokeny přicházející pakety zahozené pakety Obr Token bucket Token bucket je nejvíce využívaným mechanismem pro řízení toku dat. Tato technologie slouží k vyrovnávání různě velkého objemu dat přicházející nepravidelnými rychlostmi na vstupní porty směrovače v síti tak, aby nemohlo dojit k překročení výstupní kapacity linky, tj. k jejímu zahlcení. Metoda token bucket patří do komponentu měření a může být použita pro ovlivnění značkování nebo rozhodnutí o policing (zahození paketu, předávání či podržení ve vyrovnávací paměti). Token bucket si můžeme představit jako nádobu, která obsahuje v každém okamžiku určitý počet tokenů. Každý z nich je povolením k odeslání určitého objemu dat. Na počátku je nádoba plná. Po příchodu paketu se ověří, zda počet tokenů v nádobě alespoň odpovídá velikosti paketu. Pokud ano, je paket zařazen do fronty a odeslán na výstupní port, nebo může být příslušným způsobem označen. Zároveň je z nádoby odebrán určitý počet tokenů, který odpovídá velikosti paketu. Pokud ne, paket může být zahozen, uložen do vyrovnávací paměti, kde bude pozdržen do doby, než se nádoba naplní dostatečným počtem tokenů, nebo označen jiným způsobem. Tokeny jsou do nádoby plynule doplňovány stálou rychlostí, dokud není nádoba plná. Token bucket lze tedy popsat dvěma parametry: rychlostí doplňování tokenů r a velikostí nádoby b. Největší povolený shluk přicházejících paketů tedy odpovídá hloubce token bucketu b a dlouhodobá průměrná rychlost zpracování příchozích dat odpovídá rychlosti doplňování tokenů do nádoby r. Dlouhodobý průměr rychlosti přicházejících dat tedy nesmí překročit rychlost doplňování tokenů a krátkodobé špičky nesmí překročit velikost nádoby, jinak může dojít k zahození paketů nebo jiné odpovídající akci

21 3.3 Jednoduchý příklad z prostředí Opnet Zde bude předveden jednoduchý model pro měření paketů z prostředí Opnet. Jelikož všechny nutné znalosti byli uvedeny v kapitole 1 Opnet Modeler, bude tento příklad vysvětlen jednoduše a srozumitelně. Nyní můžeme začít s vytvořením nového modelu procesu. Na plochu vložíme tří stavy (state) a pojmenujeme je: init idle arrival Stav init a stav arrival je vynucený. Stav idle bude stavem nevynuceným. Více o stavech již bylo napsáno v kap Editor procesu základní pravidla. Dále mezi stavem init a idle vytvoříme nepodmíněný přechod. Také mezi stavem arrival a idle vytvoříme přechod, resp. dva přechody. Podmíněný idle -> arrival s podmínkou ARRIVAL Nepodmíněný arrival ->idle Poslední přechod je podmíněný s hodnotou default, který vytvoříme u stavu idle. Výsledný model editoru procesu je možné vidět na Obr. 21. Obr. 21 Měřič paketů v editoru procesu V dalším kroku definuji makro ARRIVAL kliknutím na ikonu Block. Tímto příkazem definuji makro ARRIVAL: Edit Leader #define ARRIVAL (op_intrpt_type () == OPC_INTRPT_STRM) /*zde se porovnává zjištěný typ přerušení (op_intrpt_type ())s s konstantou přerušení OPNETU (OPC_INTRPT_STRM), slouží pro porovnání jestli přicházející packet způsobil přerušení */ Dále také přes ikonu Edit State Variables definujeme použité proměnné. Typ Jméno Komentář int pk_count Celkový počet paketů Stathandle pk_cnt_stathandle Statistika k zaznamenání počtu paketů Tab. 2 Použité proměnné v editoru procesu Dále v menu Interfaces Local statistic nastavíme Start Name na hodnotu packet count

22 kód. Nyní již můžeme přejít k nastavení vstupní pozice do stavu init. Zde vložíme tento pk_count = 0; // Nastavení počtu paketů na 0 pk_cnt_stathandle = op_stat_reg ("packet count", OPC_STAT_INDEX_NONE, OPC_STAT_LOCAL); /* Registruje packet count statistiku a zvýší handle pro ARRIVAL stav, který použije při nahrávaní počtu přijatých paketů. */ Dále také ve vstupní pozici stavu arrival provedeme tento kód: ++pk_count; //zvýší hodnotu pk_count o 1 op_pk_destroy (op_pk_get (op_intrpt_strm ())); /*zruseni ukazatele paketu*/ op_stat_write (pk_cnt_stathandle, pk_count); //provedení zápisu aktuální hodnoty do statistiky Pro zkontrolování námi vložených kódů do stavů, můžeme využít funkci Show Line Count, která nám zobrazí počet vložených řádků ve stavu a to ve formátu počet vstupních/výstupních řádků (např. 2/0). Poslední úkon, který musíme provést je nastavení rozhraní procesu. To se nastavuje přes nabídku Interfaces Process Interfaces. Zde nastavíme tyto hodnoty: begsim intrpt -> enabled /*zajistí doručení přerušení simulačnímu jádru, jako na začátku simulace*/ endsim intrpt, failure intrpts, intrpt interval, recovery intrpts a super priority -> disabled priority -> 0 Poté celý projekt můžeme zkompilovat. Tady naše práce s editorem procesu končí a nyní přejdeme k editoru uzlu. Zde založíme nový projekt a na plochu vložíme tři modely procesu. Tyto objekty propojíme objektem Create Packet Stream. Jednotlivé modely procesu pojmenujeme takto: Src1 - zdroj 1 Count počítadlo paketů Src2 - zdroj 2 Propojení objektů a jejich pojmenování je zobrazeno na Obr. 22. Obr. 22 Editor uzlu moduly procesu Pomocí položky Edit Attributes Process Model nastavíme zdroj 1 (src1) na hodnotu simple_source. Pomocí tohoto úkonu přiřadíme měřiči (count) hodnotu našeho vytvořeného procesního modelu (viz ) a na zdroji 2 (src2) nastavíme opět hodnotu simple_source s exponenciálním průběhem. Posledním úkolem bude nastavení v položce Interface Node Statistic Orig. Name na hodnotu count.packet count

23 Obr. 23 Editor uzlu moduly procesu Pro spuštění celého projetu nakonec založíme nový projekt. V položce Object Palette Configure Palette Node Model načteme námi vytvořený Node Model a vložíme ho na plochu. Pokud chceme můžeme v položce Edit Attributes src2.packet Interarrival Time měnit průběh zdroje 2 paketů. Nyní již zbývá spustit simulaci. 3.4 Výsledek měření pro jednoduchý příklad měriče Výsledek našeho měření spočívá v počítání paketů. Tuto událost je vidět v kap. 5 na Obr. 35. Tento graf dokazuje, že námi vytvořený měrič počítá pakety, které přicházejí od zdrojů. Dále je možné vidět rozdíl mezi konstantním zdrojem [modrá char.] a exponenciálním zdrojem [červený char.]. 4 Závěr V této práci jsem se podrobně seznámili se základními editory prostředí OPNET Modeler. Cílem této práce bylo prozkoumání a modelování síťových aplikací. Proto bylo zjištěno jak vybrané aplikace fungují a jak nastavovat jejich základní parametry v prostředí OPNET. Po prozkoumání základních parametrů bylo důležité naše teoretické poznatky odsimulovat a dokázat, že jsou naše úvahy správné. To se povedlo a výsledky (grafy) jednotlivých aplikací jsou zobrazeny v kap. 5. Dále byl vytvořen v prostředí OPNET měřič pracující na principu Token-Bucket, který počítá pakety přicházející od zdroje. Zde byly využity naše poznatky z kap. 1 Opnet Modeler. Realizace měřiče byla úspěšně provedena a výsledky měření je možné vidět v kap

24 5 Přílohy 5.1 Výsledky naměřených hodnot Obr. 24 Naměřené hodnoty pro př. Klient server (1. graf download z server1, 2. graf upload na server1, 3. graf download z server2, 4. graf upload na server2)

25 Obr. 25 Naměřené hodnoty pro aplikaci v celé síti

26 Obr. 26 Naměřené hodnoty pro aplikaci v podsíti Brno

27 Obr. 27 Naměřené hodnoty pro aplikaci FTP v celé síti

28 Obr. 28 Naměřené hodnoty pro aplikaci FTP v podsíti Brno

29 Obr. 29 Naměřené hodnoty pro aplikaci HTTP v celé síti

30 Obr. 30 Naměřené hodnoty pro aplikaci HTTP v podsíti Brno

31 Obr. 31 Naměřené hodnoty pro aplikaci VoIP v celé síti

32 Obr. 32 Naměřené hodnoty pro aplikaci VoIP v podsíti Brno

33 Obr. 33 Odesílaná data ze serveru pro aplikace / FTP / http

34 Obr. 34 Přijatá data na server pro aplikace / FTP / HTTP

35 Obr. 35 Měřič počet čítaných paketů

36 5.2 Seznam obrázků Obr. 1 - Síťový model v editoru projektu... 3 Obr. 2 - Hlavní menu projektového editoru... 3 Obr. 3 - Tlačítka projektového editoru... 4 Obr. 4 Textová oblast projektového editoru... 4 Obr. 5 Zobrazení tipů v projektového editoru... 4 Obr. 6 Editor uzlu... 5 Obr. 7 Editor procesu... 5 Obr. 8 Editor procesu vstupní a výstupní pozice... 6 Obr. 9 Editor procesu vynucený a nevynucený stav... 7 Obr. 10 Vzorový příklad pro LAN Client... 7 Obr. 11 Vzorový příklad pro podsíť Brno... 8 Obr. 12 Vzorový příklad modelu s objekty subnet... 9 Obr. 13 Příklad nastavení ftp aplikace Obr. 14 Příklad nastavení aplikace FTP na Klient FTP Obr. 15 Příklad nastavení podporovaných služeb na serveru Obr. 16 Spojení klient server příkladová síť Obr. 17 Příklad nastavení unikátní adresy serveru Obr. 18 Příklad nastavení Application: Destination Preference Obr. 19 Průběh simulace Obr Token bucket Obr. 21 Měřič paketů v editoru procesu Obr. 22 Editor uzlu moduly procesu Obr. 23 Editor uzlu moduly procesu Obr. 24 Naměřené hodnoty pro př. Klient server Obr. 25 Naměřené hodnoty pro aplikaci v celé síti Obr. 26 Naměřené hodnoty pro aplikaci v podsíti Brno Obr. 27 Naměřené hodnoty pro aplikaci FTP v celé síti Obr. 28 Naměřené hodnoty pro aplikaci FTP v podsíti Brno Obr. 29 Naměřené hodnoty pro aplikaci HTTP v celé síti Obr. 30 Naměřené hodnoty pro aplikaci HTTP v podsíti Brno Obr. 31 Naměřené hodnoty pro aplikaci VoIP v celé síti Obr. 32 Naměřené hodnoty pro aplikaci VoIP v podsíti Brno Obr. 33 Odesílaná data ze serveru pro aplikace / FTP / http Obr. 34 Přijatá data na server pro aplikace / FTP / HTTP Obr. 35 Měřič počet čítaných paketů

37 5.3 Seznam tabulek Tab. 1 Nastavení spouštění jednotlivých aplikací profilu Tab. 2 Použité proměné v procesním editoru

38 5.4 Literatura [1] OPNET Technologies, OPNET Modeler Product Documetation Release 11.0, součást instalace simulačního prostředí OPNET Modeler, 2005 [2] OPNET Technologies, OPNET Modeler, General Tutorials, součást instalace simulačního prostředí OPNET Modeler, 2005 [3] BROWNLEE N., MILLS C., RUTH G., Traffic Flow Measurement Architecture, RFC 2722, The Internet Engineering Task Force, [4] ZHENG WANG, Internet QoS, Architectures and Mechanisms for Quality of Service, 2001 [5] PUŽMANOVÁ R., TCP/IP v kostce, 2004, ISBN [6] DOLEJŠ O., OPNET Modeler Networks Simulation

39 5.5 Poděkování Touto větou bych zde chtěl poděkovat Ing. Karolu Molnárovi Ph.D. za jeho vstřícný přístup, motivaci a velkou ochotu konzultovat naše poznatky