SNMP/XML brána. Bc. Tomá² Hroch

Transkript

1 ƒeské vysoké u ení technické v Praze Fakulta elektrotechnická Katedra po íta Diplomová práce SNMP/XML brána Bc. Tomá² Hroch Vedoucí práce: Ing. Peter Macejko Studijní program: Elektrotechnika a informatika, strukturovaný, Navazující magisterský Obor: Výpo etní technika 12. kv tna 2009

2 iv

3 v Pod kování Na tomto míst bych rád pod koval vedoucímu práce panu Ing. Peteru Macejkovi za jeho rady a p ipomínky, které vedly ke zdárnému dokon ení práce. Zárove m j dík pat í i rodin za podporu po celou dobu mých studií.

4 vi

5 vii Prohlá²ení Prohla²uji, ºe jsem práci vypracoval samostatn a pouºil jsem pouze podklady uvedené v p iloºeném seznamu. Nemám závaºný d vod proti uºití tohoto ²kolního díla ve smyslu Ÿ60 Zákona. 121/2000 Sb., o právu autorském, o právech souvisejících s právem autorským a o zm n n kterých zákon (autorský zákon). V Praze dne

6 viii

7 Abstract The main aim of this project is to develop system, which could connect two communication protocols. The rst protocol is widely used SNMP and the second one is optimized XML-based protocol. The document describes implementation of the system which includes several optimalizations to reduce memory usage. The program is written in C++ programming language and is designed for OS Linux. Abstrakt Cílem tohoto projektu je implementovat systém, jenº by dovoloval spojení dvou komunika ních protokol. Prvním z nich je ²iroce roz²í ený protokol SNMP a druhým je navrºený optimalizovaný XML protokol. V dokumentu se krom samotné implementace programu klade d raz na optimalizace, které sniºují nároky na opera ní pam. Program je napsán v jazyce C++, cílový opera ní systém je Linux. ix

8 x

9 Obsah 1 Úvod 1 2 SNMP Správní struktura SMI, MIB standardy Verze SNMP protokolu XML protokol Obecný informa ní model Odvození typ Denice modul Popis za ízení Oznamovací zprávy Adresace dat Mapování MIB do XML Importy Datové typy MIB strom Zprávy Návrh systému Teoretické poºadavky XML SNMP Struktura programu SOAP vs. démon Navrhovaná aplikace Inicializace Transformace dat Zpracovávání poºadavk Správa protokolové brány XML manaºerská aplikace xi

10 xii OBSAH 5 Implementace T ídy, vlastnosti a jejich vztahy Pouºité knihovny Popis výkonného cyklu Inicializa ní fáze Transforma ní fáze Komunika ní moduly Zprávy Fronty a atomicita poºadavk Periodické zasílání informací Asynchronní události Pam ové optimalizace XML Manaºer Testování 49 7 Záv r 55 Literatura 57 A Struktura kongura ního souboru 59 B Uºivatelská p íru ka protokolové brány 63 C Uºivatelská p íru ka manaºerské aplikace 65 D Obsah p iloºeného CD 69

11 Seznam obrázk 2.1 Základní princip fungování SNMP spravované sít Komunikace mezi SNMP manaºerem a agentem Schéma datových paket protokolu SNMPv1 a v2 ([1]) Schéma datového paketu protokolu SNMPv3 ([1]) Popis za ízení v XML schématu ([1]) Mapování aplika ních typ SMIv1 do XML schématu ([1]) Struktura XML zprávy Schéma navrhovaného systému Obecná struktura XML dokumentu Struktura elementu device Struktura elementu info HTTP zprávy p edávané mezi manaºerem a bránou HTTP komunikace mezi manaºerem a agentem/bránou Fáze b hu programu Schéma t íd aplikace Inicializa ní fáze P íklad struktury hlavního XML dokumentu Zpracování manaºerského poºadavku Komunika ní vlákna brány pro spojení se SNMP agenty Chyba prioritního zpracování poºadavk Element subscription v rámci hlavního XML dokumentu xiii

12 xiv SEZNAM OBRÁZK

13 Seznam tabulek 3.1 Mapování makra OBJECT-TYPE, jednoduchý typ (SMIv1) ([1]) Mapování SEQUENCE, makro OBJECT-TYPE ([1]) Mapování SEQUENCE OF, makro OBJECT-TYPE ([1]) Mapování TRAP-TYPE makra ([1]) xv

14 xvi SEZNAM TABULEK

15 Kapitola 1 Úvod Správa velkých po íta ových sítí je v dne²ní dob naprosto samoz ejmým úkolem v t- ²iny administrátor. Velké mnoºství spravovaných sítí se neomezuje pouze na lokální prost edí dané rmy i instituce. M ºe být naopak rozprost ena v rámci jednoho m sta, státu i dokonce n kolika stát najednou. Efektivní spravování takové komunika ní infrastruktury je úkolem velice náro ným. Jedním z protokol, který takovouto vzdálenou správu umoº uje, je SNMP. Na jeho základ bylo vybudováno bezpo et aplikací, které mají za úkol sledovat provoz na síti, zatíºení ur itého systému a v neposlední ad umoºnit administrátorovi vzdálenou správu daného p epína e, routeru i pracovní stanice. Protokol SNMP byl navrºen v d ív j²ích dobách a nemusí pln vyhovovat dne²ním poºadavk m, a uº na bezpe nost nebo efektivní vyuºití p enosových médií. Pan Ing. Peter Macejko se ve své diplomové práci ([1]) zaobíral pouºitím technologií XML a návrhu protokolu, který by umoº oval minimáln stejnou funkcionalitu jako protokol SNMP a tento zefektivnil. Tato práce se zaobírá vytvo ením protokolové brány, která by umoºnila pouºít navrºený XML protokol ke správ stroj, které stále pouºívají protokol SNMP. Cílem je vytvo it softwarový produkt, který bude plnit úkol prost edníka mezi správcem a spravovaným strojem. Hlavními problémy jsou implementace navrºeného XML protokolu a jeho spojení s n kolika verzemi protokolu SNMP. D leºitým aspektem vývoje je i orientace na sníºení nárok na opera ní pam. Proto bude v kaºdé ásti programu kladen d raz na efektivní správu datových struktur. V kapitole 2 bude podrobn popsán protokol SNMP, jeho komunika ní struktury a typy zpráv. Kapitola 3 se zabývá rozborem navrºeného XML protokolu. Analýza systému a diskuse o moºných sm rech implementace bude popsána v kap. 4. V kapitole 5 bude probrána detailní funk nost implementovaného programu. Ov ení funkce a dal²í testování systému bude popsáno v kapitole 6. 1

16 2 KAPITOLA 1. ÚVOD

17 Kapitola 2 SNMP SNMP, nebo-li Simple Network Management Protocol, je v dne²ní dob jeden z nejroz²í en j²ích protokol na správu po íta ové sít. Je to aplika ní protokol, který je sou ástí TCP/IP rodiny protokol. Byl vyvinut skupinout IETF (Internet Engineering Task Force) a p ijat jako standard v roce Umoº uje sledovat sí ový provoz, hledat a e²it problémy, které se p i provozu vyskytnou. 2.1 Správní struktura SNMP je tvo en sadou standard, které popisují správu sít, zahrnující samotný komunika ní protokol, denici databázové struktury (SMI) a datové objekty (MIB). Základním funk ním principem je model Klient - Server ([2]). Struktura spravované sít se tak d lí na t i klí ové elementy - spravované za ízení, agenta a manaºera (viz obrázek 2.1). Obrázek 2.1: Základní princip fungování SNMP spravované sít 3

18 4 KAPITOLA 2. SNMP Spravovaný systém - je za ízení (p epína, router, atd.), na kterém je spu²t n SNMP agent. Toto za ízení shromaº uje sledované informace a pak je dává k dispozici manaºerovi pomocí SNMP protokolu. Agent - je software ur ený pro pro správný p eklad poºadavk manaºera a jejich vykonání na sledovaném systému. Navíc m ºe p i sledování posílat manaºerovi upozorn ní, ºe n co není se systémem v po ádku. Manaºer (NMS - Network Managemet System) - je aplikace, která sleduje a spravuje v²echny systémy na sledované síti. Tento systém získává od agent data, zpracovává je do vizuální podoby, ímº dává moºnost administrátorovi mít p ehled o celé síti. Zárove umoº uje m nit sledované parametry p ímo u agenta. Komunikace m ºeme rozd lit do dvou kategorií dle toho, kdo ji zapo al. Základní schéma je vyjád eno na obrázku 2.2 ([3]). Obrázek 2.2: Komunikace mezi SNMP manaºerem a agentem V první ásti schématu je vyobrazeno standardní chování managera, který posílá dotazy agentovi, který mu odpovídá. P esný výpis p íkaz a zpráv, které si mohou tyto dva systémy mezi sebou vym ovat, bude diskutován dále v této kapitole. Druhá ást schématu popisuje moment, kdy na sledovaném systému nastala n jaká extrémní situace (nap. zatíºení sí ového spoje se blíºí k maximu) a agent informuje manaºera pomocí zprávy Alert (v SNMP jsou to zprávy TRAP i INFORM, ob budou diskutovány dále). Je nutné zmínit, ºe SNMP protokol pracuje nad transportním protokolem UDP, který je nepotvrzovaný. Není tedy zaru eno, ºe bude komunikace probíhat bezchybn. Je moºné, ºe n které dotazy a p íkazy v bec nedojdou ke svému cíli, o emº se druhá strana nikdy nedozví. Tento fakt m ºe být p ekáºkou p i správ rozsáhlých sítí, kde jsou ²patné sí ové spoje.

19 2.2. SMI, MIB STANDARDY SMI, MIB standardy Jak jiº bylo zmín no d íve, SNMP je sada standard, která krom komunika ního protokolu musí denovat i strukturu sledované databáze a samotná data. Tyto informace byly denovány ve standardech SMI a MIB. SMI SMI je zkratkou pro Structure and Identication of Management Information for TCP/IPbased Internets. Tento standard ([4]) popisuje a denuje základní datové struktury a typy, které protokol vyuºívá. Jednotlivé objekty jsou pojmenovány a organizovány, aby bylo moºno k t mto dat m logicky p istupovat. Dle standardu musí mít kaºdý objekt jméno, syntaxi a kódování. Jméno jednozna n identikuje objekt. Datový typ ( íslo, et zec) je ur en syntaxí. Kódování zaji² uje správnou serializaci dat p i p enosu mezi systémy. Objekty, identikovány svým jménem (OID), jsou se azeny do hierarchické struktury. K identikaci je pouºito Abstract Syntax Notation One (ASN.1). Kaºdý OID identikátor je sloºen ze skupiny p irozených ísel, které vyjad ují jeho pozici v pomyslném stromu. Strom má ko en, který je spojen hranami s o íslovanými uzly. Kaºdý uzel m ºe mít vlastní d ti, ímº tvo í vlastní podstrom. Takto je moºno pokra ovat dále do zna né hloubky stromu. Tento standard téº specikuje, jaké objekty tvo í po átek správní databáze. MIB MIB je zkratka pro Management Information Base. Je to soubor denicí, které popisují parametry a vlastnosti sledovaného za ízení. Existuje více neº 100 r zných MIB, které popisují r zná za ízení. Kaºdý takovýto soubor denic musí spl ovat p edpisy SMI, aby byla zaru ena správná interpretace objekt. Kaºdý objekt (n kdy také nazýván MIB objekt) je unikátn identikován svým OID a v²echny dohromady jsou uspo ádány do stromové struktury tak, jak to bylo popsáno v minulém odstavci. Objekty v dané databázi se d lí na skalární a tabelární. Skalární objekty reprezentují jeden parametr sledovaného za ízení (nap. po et ethernetových karet v p epína i), kdeºto tabelární objekty jsou spojením n kolika sp ízn ných objekt (nap. routovací tabulka je spojením jednotlivých záznam, coby ádk dané tabulky). V rámci hierarchického uspo ádání jsou vyhrazeny vy²²í úrovn stromu (blíºe ko enu) jednotlivým standardizujícím organizacím, niº²í úrovn jsou poté zadány jednotlivými spole nostmi. Kaºdý výrobce si m ºe denovat svojí privátní v tev, do které umístí specické informace daného za ízení. MIB, které nebyly standardizovány a ociáln schváleny, jsou umíst ny do v tve experimentální.

20 6 KAPITOLA 2. SNMP 2.3 Verze SNMP protokolu Celkem byly doposud standardizovány t i verze protokolu SNMP. Kaºdá z nich denuje svoje specické datové typy a pouºívané datové rámce pro komunikaci. SNMPv1 V první verzi protokolu byly denovány dv skupiny datových typ : Základní datové typy (Simple data types) Aplika ní typy Základní typy jsou denovány v SNMPv1 SMI a denují základní pouºívané hodnoty: INTEGER - celá ísla od 2 31 do OCTET STRING OBJECT IDENTIFIER - identikace jednotlivých objekt v rámci normy ASN.1 Aplika ní specické typy pak jsou: Network Address - obecná sí ová adresa pro podporu mnoha rodin protokol IpAddress - p ímo denovaný typ pro IP adresu. SMIv1 podporuje pouze 32 bitovou adresu (IPv4) Counter - íta, vyjád en celým íslem bez znaménka; jeho hodnota se pouze zvy²uje a to aº do maxima a pak se vrací zp t na nulu Gauge - je denována jako nezáporné celé íslo; m ºe hodnotu zvy²ovat i sniºovat a to v denovaných mezích minima a maxima Time Ticks - po et hodinových tik od n jaké události, m eno v setinách vte iny Opaque - typ dovolující p ená²et libovolná data v kódování ASN.1. Tato data jsou zakódována jako OCTET STRING a následn p enesena médiem. Integers - celo íselný typ, který p edenovává specikaci v SMI Unsigned Integer - celo íselný typ bez znaménka, který stejn jako p edchozí p edenovává specikaci. Komunika ní mechanismus mezi manaºerem a agentem je denován pomocí datových rámc, které je moºné v rámci SNMPv1 p ená²et. Tyto jsou: Get Request - získání hodnoty uzlu identikovaného OID (zpráva od manaºera agentovi)

21 2.3. VERZE SNMP PROTOKOLU 7 Get Next Request - ºádost o hodnotu uzlu následujícího po zaslaném OID (od manaºera k agentovi) Set Request - nastavení hodnoty uzlu specikovaném OID (od manaºera k agentovi) Get Response - odpov agenta manaºerovi na Get a Set zprávy. Obsahují po- ºadovanou hodnotu Trap - zpráva od agenta manaºerovi, která upozor uje na nastalé situace na monitorovaném systému. Strukturu jednotlivých SNMP paket zobrazuje obrázek 2.3. Obrázek 2.3: Schéma datových paket protokolu SNMPv1 a v2 ([1]) Hlavní ást datového paketu je tvo ena poli Version a Community string. První popisuje verzi SNMP protokolu pouºitou p i komunikaci a druhé je heslo pro p ístup k poloºkám MIB. Blíºe k bezpe nosti v dal²ím odstavci. Druhá ást paketu se li²í dle typu zprávy. Paket odeslaný agentem p i výskytu monitorované události obsahuje informace, které popisují druh problému. Enterprise - identikuje typ za ízení, které zprávu poslalo Agent adress - adresa za ízení, kde b ºí agent Generic trap type - specikuje, zda-li se jednalo o n který z p eddenovaných typ událostí (linkdown, linkup, coldstart, aj.) Specic trap type - identikuje jednu z mnoha specických událostí Druhým typem zprávy jsou dotazy a odpov di, které zasílá manaºer a agent na n odpovídá. Jednotlivá pole mají následující význam:

22 8 KAPITOLA 2. SNMP Request ID - po adové íslo dotazu (aby manaºer v d l, na co p i²la odpov ) Error status - je nastaven pouze u odpov di a obsahuje druh problému, který se p i dotazu objevil Error index - asociuje problém s instancí objektu. Spole ným polem pro oba dva typy paketu jsou Variable bindings - jsou to dvojice polí, kde jedna ást identikuje objekt a druhá ást je jeho hodnota. Nap íklad p i dotazu p íkazem GET se nastaví název objektu a v odpov di p ijde nastavena i hodnota. Bezpe nost v této verzi protokolu je zaloºena pouze na takzvaném community stringu, který vystupuje jako heslo. Existují pouze dv úrovn zabezpe ení p ístupu a to - pouze pro tení (read only) a tení-zápis (read-write access). Je patrné, ºe se pouºívají pouze dv hesla, kaºdé pro jednu úrove. Je to velice slabé zabezpe ení, vezmeme-li v úvahu, ºe toto heslo se posílá neza²ifrované a kaºdý, kdo dokáºe odchytit jednotlivé pakety, si m ºe tento et zec p e íst. Tento nedostatek se pokou²ejí odstranit aº dal²í verze protokolu. SNMPv2 Druhá verze protokolu SNMP byla zam ena na odstran ní nedostatk verze první. Bohuºel bylo vydáno n kolik soupe ících specikací, ozna ované názvy SNMPv2c, SNMPv2u, SNMPv2*, které byly vzájemn nekompatibilní. Nicmén zlep²ení oproti první verzi bylo n kolik. Byly denovány nové datové typy, nové zprávy a zlep²ená práce s chybami. Nové datové typy zahrnují roz²í ení podpory z 32-bitových ísel na 64-bitová ( Integer32, Integer64, Counter32,...). P idané zprávy jsou: Get Bulk - tento operátor se snaºí efektivn ji vyuºít p enosovou kapacitu kanálu tím, ºe od agenta si vyºádá sérii informací pomocí jediného dotazu Inform - stejná funkcionalita jako zpráva Trap ve verzi 1, ale nutné je potvrzení od manaºera, ºe zprávu p ijal (Response paket) Response - odpov na p edcházející Inform zprávu (od manaºera k agentovi) Ostatní zprávy SNMPv2 p ebírá z p edchozí verze a zachovává jejich strukturu. Stejn tak je to i s bezpe ností, kde je stále pouºito heslo ve smyslu community stringu. SNMPv3 T etí verze protokolu SNMP je denována sadou standard, které nepostihují celkovou funk nost protokolu jako takového, ale dodávají do systému chyb jící prvky, hlavn bezpe nosti. P ímo v jednom ze standard [5] je e eno, ºe tato verze m ºe být chápána jako SNMPv2 s dodate nými administrativními a bezpe nostními schopnostmi. SNMPv3 denuje t i základní sluºby:

23 2.3. VERZE SNMP PROTOKOLU 9 Autentikaci - datový p enos od manaºera k agentovi m ºe být autentikován, aby se zajistilo ov ení identity odesílajícího. Soukromí - ²ifrování p ená²ených zpráv. P ístupová práva - agent m ºe denovat p ístupová práva, omezovat p ístup manaºer m pouze k n kterým akcím a ástem dat. Základním principem SNMPv3 je modularita. Kaºdá SNMP entita je tvo ena SNMP ídícím systémem a vlastní aplikací. ídící systém má za úkol p ijímat, odesílat, ²ifrovat a de²ifrovat v²echny zprávy a dále spravuje a kontroluje monitorované objekty. Tyto funkce jsou poté k dispozici jedné i více aplikací. Stejn jako p edchozí verze, je SNMPv3 zaloºena primárn na transportním protokolu UDP, ale není na n j vázána. Pro p enos dat tak m ºe být pouºit i jiný protokol. Vlastní aplika ní protokol SNMP je rozd len do dvou úrovní. První zpracovává datové pakety (PDU processing layer) a druhá zpracovává zprávy (message processing layer). Nejvy²²í úrove - PDU processing layer - se stará o zpracování p íkaz (Get, Get Next,...), které p ijdou v daném paketu. Zpracovaný paket pak p edá niº²í úrovni - message processing layer - která tomuto paketu dodá hlavi ku, kde jsou uloºena bezpe nostní data. Na obrázku 2.4 je vyobrazen formát SNMPv3 zprávy. První ást je tvo ena systémem zpracování zpráv. Nese informace ohledn verze protokolu, identikaci zprávy, maximální délce zprávy a nastavení bezpe nostího modelu. Druhá ást je generována bezpe nostním systémem a obsahuje informace o kódování a autorizaci. T etí ást obsahuje samotná data. D leºitou sou ástí nového standardu je i systém p ístupových práv (VACM - View- Based Access Control Model). Tento model umoº uje nakongurovat agenta tak, ºe specickému manaºerovi bude umoºn n p ístup pouze k ásti MIB. Je moºné omezit manaºera pro p ístup pouze k ásti databáze monitorovaných dat a zárove je²t omezit operace, které nad touto mnoºinou m ºe provád t. Omezení p ístupu se provádí pro denované skupiny, kde sou ástí jedné skupiny m ºe být více manaºer.

24 10 KAPITOLA 2. SNMP Obrázek 2.4: Schéma datového paketu protokolu SNMPv3 ([1])

25 Kapitola 3 XML protokol Pan Ing. Peter Macejko ve své diplomové práci navrh systém vzdálené správy stroj pomocí komunika ního protokolu, vyuºívajícího XML. V této kapitole budou shrnuty v²echny navrºené postupy od mapování SNMP informa ního modelu aº, po komunika ní struktury vyuºívané správcem a spravovanými za ízeními. 3.1 Obecný informa ní model Informa ní model je nedílnou sou ástí celého systému správy dat. Do n j jsou mapována ve²kerá monitorovaná data a jsou zde i vyjád eny vztahy mezi daty. Ve skute nosti omezuje po et a druh moºných dotaz. Výsledný systém, který byl pro popis jednotlivých za ízení navrºeni, vychází z n kolika r zných p ístup abstrakce a popisu dat. Nejprve byla analýza problému zaloºena na dvou moºnostech - p ímém mapování MIB stromu do XML dokumentu, kdy by jednotlivé uzly p esn odpovídaly MIB struktu e; objektov orientovaném vyuºívajícím objektové paradigma. První p ístup má výhodu ve snadném p evodu MIB databáze do nového formátu, ale naopak ztrácí výhodu snadné roz²i itelnosti, která je vlastní XML technolgoii. Problém objektového mapování je nejednozna né rozmíst ní uzl ve stromu na objekty. Takovéto mapování by bylo nutno provád t neautomatizovan, tj. za asistence lov ka. Výsledkem analýzy problému je systém vyuºívající kousek od obou p ístup. Na nejvy²²í úrovni abstrakce je kaºdé za ízení sloºeno z modul. Kaºdý modul obsahuje jistou funkcionalitu, která je úpln odd lena od t ch zbývajících. Mezi tyto moduly pat í i v této práci navrhovaná brána, která propojuje za ízení bez XML podpory s ostatními ástmi sít. V této chvíli se jedná pouze o obecný návrh kaºdého za ízení Odvození typ Odvozování typ je zaloºeno na principu d di nosti. Denice jako takové jdou od abstraktního aº po detailní popis. 11

26 12 KAPITOLA 3. XML PROTOKOL Denice modul Jak jiº bylo e eno, kaºdé za ízení se skládá z modul. Jednotlivé moduly jsou téº popsány XML schématem. Kaºdé takové schéma musí spl ovat p esné poºadavky na poskytované informace. Musí být detailn popsána funk nost, p id leno unikátní jméno, typ a cesta ve stromové struktu e, pouºitá pro adresaci jednotlivých uzl. SNMP moduly mají denován ko enový element, který je vyuºit pro spojování více MIB informa ních bází dohromady. P esný popis je moºné nalézt v [1] v kapitole Popis za ízení Pro popis za ízení je vyuºito XML schéma, stejn jako pro popis dal²ích ástí (modul apod.). Na obrázku 3.1 je znázorn no, jak vypadá za ízení popsané od nejvy²²í úrovn. Obrázek 3.1: Popis za ízení v XML schématu ([1]) Oznamovací zprávy Oznámení jsou takové zprávy, které jsou zasílány manaºerovi v p ípad, ºe se na monitorovaném za ízení vyskytne n jaká událost (shodné s SNMP Trap zprávami). V rámci SNMP jsou tyto zprávy sou ástí datového modelu, nicmén tyto specické uzly MIB stromu nenesou ºádná data, a jsou tudíº pouºité pouze p i generování typu chyby i události. V navrºeném systému jsou v²echna moºné upozorn ní (a jiº p eddenované, i de- nované administrátorem) umíst ny ve speciálním uzlu stromu notifications, kde je velice jednoduché dohledat, jaké události mohou zp sobit zaslání oznamuvací zprávy. Kaºdý modul pak m ºe mít specikován speciální typ NotificationType, který popisuje práv onu událost.

27 3.2. MAPOVÁNÍ MIB DO XML Adresace dat Pro adresaci dat je moºno vyuºít postup XPath a XQuery. Jednotlivými výrazy a uº v jednom i druhém p ípad se bude manaºer dotazovat na jednotlivé uzly v rámci spravované databáze. 3.2 Mapování MIB do XML V p edchozí ásti byl rozebrán ist obecný model popisu za ízení. Pro monitorované stroje, které nejsou kompatibilní s XML protokolem, musí existovat brána, která bude p ekládat dotazy z jednoho protokolu na druhý a stejn tak i odpov di. Je tedy nutné p esn denovat postup p episu MIB na XML. Je nutné vy e²it t i základní problémy - jak importovat jednotlivé MIB do sebe; jak p edenovat datové typy a jak konvertovat celý MIB strom Importy V rámci jednotlivých MIB jsou asté odkazy na báze vy²²í úrovn, kdy pak na niº²ích úrovních denujeme jenom ást podstromu. V rámci XML budou denovány odkazy jako prostory jmen, které jsou odvozeny od názvu daného MIB. Odkaz na jiné schéma bude proveden pouºitím odkaz na typ s p íslu²ným názvem prostoru jmen Datové typy V SNMP, jak bylo e eno v p edchozí kapitole, existuje n kolik druh datových typ. Jednoduché (integer, string,...), aplika n roz²í ené (Gauge, IpAddress,...) a uºivatelem denované. Jednoduché typy budou mapovány na jejich XML ekvivalent. Na obrázku 3.2 je soupis v²ech aplika n roz²í ených typ a jejich popis pomocí XML schématu (v rámci standardu SMIv1). Sou ástí SMI je i moºnost denovat vlastní typy. I pro tyto p ípady je nutno uvést denici p ekladu. Existují t i základní omezení p i vytvá ení vlastních typ - vý et, délka et zce a rozmezí hodnot. V²echny tyto typy jsou detailn popsány a vyobrazeny v [1], kapitola MIB strom Navrºený systém vyuºívá p i mapování celého stromu odd lení denicí typ od samotné struktury stromu. Typy jsou denovány globáln a zárove separátn od struktury a to z d vodu moºného pouºití typ v rámci jiného modulu a zárove p i omezení p ístupových práv do dané oblasti stromu. V MIB jsou objekty denovány makry (specikované v

28 14 KAPITOLA 3. XML PROTOKOL Obrázek 3.2: Mapování aplika ních typ SMIv1 do XML schématu ([1])... <xsd:element name="nodename" type="mibname:nodenametype"/>... <xsd:simpletype name="nodenametype"> <xsd:annotation> <xsd:documentation xml:lang="en">descrtext</xsd:documentation> <xsd:appinfo> <status>statustype</status> <access>accesstype</access> <oid>absoluteoid</oid> </xsd:appinfo> </xsd:annotation> <xsd:restriction base="nodetype"/> </xsd:simpletype> Tabulka 3.1: Mapování makra OBJECT-TYPE, jednoduchý typ (SMIv1) ([1])

29 3.2. MAPOVÁNÍ MIB DO XML <xsd:element minoccurs="0" maxoccurs="unbounded" name="nodename" type="mibname:nodenametype"/>... <xsd:complextype name="nodenametype"> <xsd:sequence> <xsd:element name="..child.." type="..childtype.."/>... </xsd:sequence> </xsd:complextype> Tabulka 3.2: Mapování SEQUENCE, makro OBJECT-TYPE ([1])... <xsd:element name="attable"> <xsd:complextype> <xsd:sequence> <xsd:element..sequence.. /> </xsd:sequence> </xsd:complextype> </xsd:element>... Tabulka 3.3: Mapování SEQUENCE OF, makro OBJECT-TYPE ([1]) SMI), které popisují n kolik základních typ uzl. SMIv1 specikuje OBJECT-TYPE a TRAP-TYPE makra. OBJECT-TYPE makro denuje uzel, který obsahuje n jaká data. M ºe to být samotná hodnota, poloºka, nebo celá ádka tabulky. Mapování pak závisí na poloºce SyntaxType v samotné denici makra. Pakliºe je hodnota poloºky základním, roz²í eným i uºivatelsky denovaným typem, bude vytvo ena globální denice typu a poloºka bude tvo ena elementem s jednoduchým typem. Schematicky vyjád eno v tabulce 3.1. Jestli bude hodnotou SEQUENCE, bude vytvo en " ádkový" typ (tabulka 3.2). Hodnota SEQUENCE OF pak vyjad uje mnoºinu ádkových typ (tabulka 3.3). Dal²ím typem objektu jsou upozorn ní denované pomocí TRAP-TYPE makra. Tyto denují uzly bez hodnot, pouze specikují danou událost. V navrºeném systému tedy nemusí být sou ástí stromu, ale pouze globálních typových denicí. Bude pouºit jednoduchý typ popisující as a den (datetime type) se speciálním elementem v ásti appinfo.

30 16 KAPITOLA 3. XML PROTOKOL <xsd:simpletype name="nodenametype"> <xsd:annotation> <xsd:documentation xml:lang="en">descrtext</xsd:documentation> <xsd:appinfo> <enterprise>enterprisename</enterprise> <variable>variabletype</variable> <reference>referencetype</reference> <trapnumber>trapnumber</trapnumber> </xsd:appinfo> </xsd:annotation> <xsd:restriction base="xsd:datetime"/> </xsd:simpletype> 3.3 Zprávy Tabulka 3.4: Mapování TRAP-TYPE makra ([1]) Navrhovaný systém by m l vyuºívat spolehlivého a potvrzovaného p enosového protokolu, na rozdíl od nepotvrzovaného SNMP. Zarove by m lo být moºno p ená²et zprávy v co nejjednodu²²ím formátu. Proto bylo rozhodnuto o pouºití protokolu HTTP, který vyuºívá p enosový protokol TCP, ímº je zaji²t n spolehlivý p enos. V²echa data se budou p ená²et pomocí HTTP zprávy POST. HTTP je bezestavový protokol. Ve²kerá komunikace se sestává z dvojice dotaz a odpov. Na serveru se neudrºují jakékoliv dal²í informace ohledn probíhajícího spojení. Tato nenáro nost dovoluje implementaci na velice r znorodém hardwaru. Bezpe nost p enosu m ºe být e²ena za pouºití tunelování paket (IPSec, STunel,...), nebo je moºno vyuºít výhody HTTPS (HTTP over SSL). Ve²kerá p ená²ená data budou ve formátu XML dokumentu s ko enovým uzlem message. Tento uzel má n kolik atribut, které specikují jeho zpracování a p ístupová práva. Jsou to queue, password, context. První atribut ur uje frontu (m ºe být zaloºeno na prioritním zpracování), ve které bude poºadavek zpracován. V principu ale nejsou agenti ani brány povinni takovouto funk nost implementovat. Zprávy pak budou zpracovány sekven n a odpov di budou generovány v p esném po adí tak, jak p i²ly dotazy. Zbylé dva atributy slouºí pro vymezení p ístupu uºivatele (context) na ur itý podstrom dat. Bylo jiº nazna eno, ºe zpráva m ºe obsahovat n kolik jednotlivých dotaz. Struktura zprávy je vyjád ena na obrázku 3.3. Dotazy a odpov di, které denují komunikaci mezi manaºerem a klientem, jsou popsány níºe. P esné XML schéma denující úplnou strukturu zpráv obsahuje ([1], p íloha D).

31 3.3. ZPRÁVY 17 Obrázek 3.3: Struktura XML zprávy DISCOVERY Tato zpráva je první, kterou za²le manaºer agentovi, aby zjistil, jaká monitorovaná data jsou k dispozici. Povinným atributem je íslo verze protokolu (protocolversion) a nepovinným je fulldescription pro bliº²í specikace typ spravovaných dat. <message context="honza"> <discovery protocolversion="1.0" msgid="123" /> </message> PUBLICATION Agentova odpov na manaºer v dotaz DISCOVERY. V rámci zprávy je uvedeno, jakou verzi protokolu agent pouºívá a jaká data spravuje. Tato data jsou pak manaºerem zpracována a pouºita jako informa ní model. <publication msgid="123"> <info> <xpath>1.0</xpath>... </info> <datamodel>... XML schema popisující spravovaná data... </datamodel> </publication> Pakliºe agent nepodporuje danou verzi protokolu, musí odpov d t chybovou zprávou: <publication msgid="123"> <error code="1">protocol not supported</error> </publication>

32 18 KAPITOLA 3. XML PROTOKOL GET Tímto dotazem se manaºer ptá agenta na hodnotu n jakého uzlu. Pro specikaci jakého je nutno pouºít XPath i XQuery. <get msgid="123"> <xpath> device/data/interface </xpath> </get> SET Zpráva SET je ur ena pro nastavení hodnoty uzlu. Struktura je podobná zpráv GET, ale obsahuje navíc element value. <set msgid="123"> <xpath> device/data/interface/status </xpath> <value>4</value> </set> RESPONSE Odpov na zprávy GET a SET. V p ípad GET nese zpráva p íslu²ná data. Pakliºe je to odpov na SET, je to pouze potvrzení, ºe hodnota uzlu byla úsp ²n nastavena. <response msgid="123"> <value>4</value> </response> <response msgid="123" /> EVENT Pro oznamování asynchronních událostí je tu zpráva EVEN (stejná funkcionalita jako TRAP u SNMP). P ená²ené informace specikují, která událost vyvolala toto oznámení, kdo to poslal, datum a as, p ípadn n jaká dal²í data, která by mohla být p i e²ení problému uºite ná.

33 3.3. ZPRÁVY 19 <event msgid="123" timestamp="" senderid="router1" eventspec="/device/notifications/dhcp/nof <data> <value valuelocation="/data/services/dhcp/leases/free">0</value> <value valuelocation="/data/services/dhcp/leases/used">50</value> </data> </event> Je nutné, aby doru ení této zprávy bylo potvrzeno. Coº bude dodrºeno pouºitým protokolem. SUBSCRIBE Touto zprávou se manaºer p ihlásí k opakovanému zasílání dat. Potvrzením je pak první doru ení dat - zpráva DISTRIBUTION - nebo chybové zprávy, ºe je n co v nepo ádku. Je moºné specikovat je²t nepovinný atribut frequency - doba ve vte inách, po které mají být opakovan zasílány zprávy. Dal²í nepovinné atributy distrid a delete jsou vyuºity pro editaci i smazání daného p ihlá²ení. <subscribe msgid="123" frequency="150"> <xpath>/device/data/interface/status</xpath> </subscribe> DISTRIBUTION Zpráva obsahuje data, o která si manaºer ekl. Je nutné, aby odesílaná data byla ve stejném po adí, ve kterém byla ve zpráv SUBSCRIBE. Povinný atribut distrid je ur ený k identikaci p íchozích dat u manaºera. <distribution msgid="123" distrid="5678"> <value>1</value> <valuea>500</value> </distribution> P íjem t chto dat je téº nutné potvrdit, coº zajistí transportní protokol.

34 20 KAPITOLA 3. XML PROTOKOL

35 Kapitola 4 Návrh systému V p edchozích dvou kapitolách byla rozebrána teoretická ást problému. V této kapitole shrneme poºadavky vyplývající z teorie, které je nutno zakomponovat do výsledného systému. Nejprve bude schématicky vyjád ena obecná funkcionalita systému, která se následn bude rozebírat detailn ji. 4.1 Teoretické poºadavky Nároky na systém, které vyplývají z teorie m ºeme rozd lit do t í ástí - implementace SNMP protokolu, implementace navrºeného XML protokolu a propojení t chto dvou protokol dohromady. Hlavním poºadavkem, který vyplývá i ze zadání práce, je vytvo it modulární systém, který bude nejenom spojovat sou asné verze protokol, ale bude po ítat i s potenciálním roz²í ením do budoucna. Obecné schéma navrhovaného systému zobrazuje obrázek 4.1. Obrázek 4.1: Schéma navrhovaného systému 21

36 22 KAPITOLA 4. NÁVRH SYSTÉMU Zde je vid t, ºe oba dva protokolové moduly jsou na sob nezávislé a jejich interakce spo ívá v p edávání si zpráv. Nyní p ejd me k detailn j²ím poºadavk m na vý²e zmín né ásti systému. V rámci SNMP protokolu je poºadováno implementace komunika ních struktur protokol SNMPv1 a SNMPv2 p evzetí bezpe nostního schématu z tohoto protokolu XML orientovaná ást programu má za úkol implementovat komunika ní struktury navrºeného protokolu navrhnout efektivní správu XML struktur v pam ti poskytnout XML manaºer m transparentní získání dat z monitorovaných za ízení mapovat roz²í enou mnoºinu funkcí v rámci XML protokolu do SNMP s manaºery komunikovat pouze p es HTTP/HTTPS protokol Spojením protokol je my²len p echod od databázových struktur jednoho protokolu k druhému. V na²em p ípad je to transformace SNMP MIB do XML, jak bylo vysv tleno v kapitole XML Nejprve se zam íme na reprezentaci dat, které budou v rámci XML popisovat jak bránu, tak monitorované za ízení. Z p edchozích kapitol vyplynulo, ºe bude pouºito áste n objektového p ístupu a p ímého mapování MIB. Strukturu dat bude popisovat XML dokument, strom, který má strukturu vyjád enou na obrázku 4.2. Ko enový uzel specikuje celé za ízení vystupující jako protokolová brána, obsahuje tyto elementy: info - tento element obsahuje text, kterým je popsáno dané za ízení services - element vymezující poskytované sluºby (p i ²ir²í implementaci m ºe obsahovat sluºby DNS, DHCP, apod.) xmlbnmgate - na²e sluºba poskytující spojení XML a SNMP protokolu device - je podelementem xmlbnmgate a vymezuje jedno monitorované za ízení Prvky device jsou do XML dokumentu p idávány na základ informací v kongura ním souboru (viz kapitola 4.2). Strukturu elementu device popisuje obrázek 4.3. Kaºdý takovýto element bude obsahovat následující informace:

37 4.1. TEORETICKÉ POšADAVKY 23 Obrázek 4.2: Obecná struktura XML dokumentu Obrázek 4.3: Struktura elementu device

38 24 KAPITOLA 4. NÁVRH SYSTÉMU info - stejn jako ko enový element popisuje dané za ízení notications - obsahuje elementy a typy upozorn ní (TRAP zprávy v rámci SNMP), na které manaºer eká subscriptions - obsahuje informace o datech, které si nechává manaºer posílat v pravidelných intervalech (více v popisu komunikace) data - d tmi tohoto elementu jsou ve²kerá data p ímo z MIB. Samotný element má atribut id, coº je jeho identikace v rámci xml dokumentu. Dle tohoto unikátního ísla je pak moºné v sad dotaz rozpoznat, ke kterému za ízení se dotaz vztahuje. Element info obsahuje elementy, které specikují jméno a popis za ízení (viz obrázek 4.4). Obrázek 4.4: Struktura elementu info Jednotlivé podelementy uzlu subscriptions musí z podstaty v ci obsahovat informace, které ur ují, jaké objekty chce manaºer pravideln sledovat, identikovat manaºera, aby mu mohla být data doru ena a specikovat asový interval, tj. frekvenci sledování p íslu²né veli iny. D ti uzlu notications ur ují, které typy událostí jsou sledovány u daného za ízení. V rámci kongurace systému je nezbytné, aby pro kaºdé za ízení bylo jasn denováno, kam mají být p íslu²né zprávy o událostech zasílány. Tato informace bude sou ástí kongura ního souboru a systém ji bude intern zpracovávat. Samotný XML tag bude obsahovat unikátní identika ní íslo (OID) dané události, aby jej bylo moºno poté identikovat a správn formulovat XML zprávu manaºerovi. Mapování dat z MIB bylo obecn popsáno v kapitole 3 a p esný algoritmus bude specikován v následující kapitole. Pro adresaci jednotlivých objekt je, jak bylo jiº nastín no v p edchozí kapitole, pouºito mechanism XPath i XQuery. Dotaz na poloºku z MIB m ºe vypadat následovn /iso/org/dod/internet/mgmt/mib-2/... D leºitým faktem je, ºe manaºer se ptá p ímo na uzly datového stromu. Nemusí tedy uvád t cestu v rámci celého stromu, který popisuje strukturu brány.

39 4.1. TEORETICKÉ POšADAVKY 25 Zprávy Zprávy, které budou posílány mezi manaºerem a bránou, mají formu XML dokumentu. Schématicky je znázorn na a popsána v kapitole 3, obrázek 3.3. Ko enový element message obaluje ve²kerá posílaná data. M ºe obsahovat n kolik díl ích dotaz, nastavení a ostatních informací, které budou vykonávány postupn jedna po druhé. V rámci teorie byla nastín na moºnost pouºití n kolika r zných front, které by byly specikovány identikátorem a zaru ovaly by r znou prioritu zpracování. Navrhovaný systém bude podporovat rozd lení komunika ních front dle monitorovaných za ízení. Zajistí se tím správné po adí vykonání p íchozích poºadavk. Komunikace mezi manaºerem a bránou je na XML úrovni omezena na zprávy Get Set Discovery Publication Subscription Distribution Event P esná struktura a popis funkce jednotlivých zpráv byla popsána v p edchozí kapitole. Komunika ní protokol Od protokolu SNMP se XML ást komunikace li²í také tím, ºe bude probíhat na spolehlivém a potvrzovaném protokolu - HTTP. Kaºdá zpráva, která je poslána, musí mít potvrzeno doru ení, coº tento aplika ní protokol, vyuºívající transportního protokolu TCP, nabízí. Informace budou posílány ve formátu HTTP POST zprávy. Strukturu dotazu a odpov di zobrazuje obrázek 4.5 a komunikaci obrázek 4.6. Otázka bezpe ného p enosu dat byla e²ena v p edchozí kapitole a byl zvolen protokol HTTPS. Zaji²t ní distribuce a zpracování certikát bude diskutováno dále v této kapitole.

40 26 KAPITOLA 4. NÁVRH SYSTÉMU Obrázek 4.5: HTTP zprávy p edávané mezi manaºerem a bránou Obrázek 4.6: HTTP komunikace mezi manaºerem a agentem/bránou

41 4.2. STRUKTURA PROGRAMU SNMP Druhou ást komunikace tvo í SNMP protokol. Z kapitoly 2 vychází seznam zpráv, které je nutné implementovat: Get Set Response GetNext Trap V rámci komunikace se v této práci budeme zaobírat verzemi SNMPv1 a SNMPv2. Samotná implementace a mapování SNMP zpráv na XML dotazy bude diskutována aº v kapitole 5. Bezpe nost se v SNMP omezuje pouze na komunitní heslo. V rámci XML protokolu je bezpe nost zaloºena jednak na ²ifrovaném p enosu dat mezi manaºerem a bránou, druhak na p ístupovém heslu, které vymezuje tecí i zápisová práva p i p ístupu k za ízení. 4.2 Struktura programu P ed samotným návrhem jednotlivých funk ních element je nutno zvolit, jak bude program fungovat a jevit se globáln. Vzhledem k nabízeným sluºbám a komunikaci, je moºné zvolit koncepci podobnou webovým sluºbám (zaloºených na principu SOAP). Druhým moºným p ístupem je zvolit na pozadí b ºící aplikaci - démona, který bude po celou dobu svého b hu monitorovat a zpracovávat p íchozí poºadavky SOAP vs. démon Kompozice struktury jako webové sluºby zaloºené na SOAP architektu e má n kolik p edností. Je tím hlavn p enositelnost a jednoduchost nasazení. V²e, co je pot eba k b hu, je aplika ní server. Nainstalování a spu²t ní sluºby je jiº pak otázkou okamºiku. Samotná struktura kódu je téº o n co jednodu²²í, neº v p ípad démona. Je nutné se starat pouze o p íchozí poºadavek a jeho zpracování. Bohuºel tento p ístup má ale i mnoho nevýhod. Zaprvé je to reak ní doba, za kterou je systém schopen zaslat manaºerovi odpov. Pro samotné zpracování poºadavku je nutno v pam ti ( i v souboru) udrºovat XML reprezentaci MIB tak, jak bylo popsáno d íve. P i pouºití tohoto postupu se po kaºdém p ijatém poºadavku musí na íst informace ze souboru a teprve poté je moºno data zpracovat.

42 28 KAPITOLA 4. NÁVRH SYSTÉMU Dal²ím sporným bodem je periodické zasílání zpráv manaºer m, kte í o to poºádali zprávou Subscription. V takovém p ípad musí b ºet jeden proces, který v ur ených intervalech zasílá SNMP dotazy na monitorované za ízení, coº je neslu itelné se základní my²lenkou webových sluºeb. Asi nejv t²í nevýhodou tohoto p ístupu je transformace dat z MIB do XML. P i spu²t ní webové sluºby je nutné, aby jiº v²echna za ízení m la své monitorované informace uloºeny v XML formátu, protoºe p i poºadavku jiº není as data transformovat. Tento akt by musel být od sluºby odd len a bu sv en periodicky se spou²t nému skriptu, nebo by jej administrátor musel provést pokaºdé, kdyº se zm ní po et, druh i monitorované údaje jednotlivých za ízení. Oproti tomu stojí druhý p ístup - strukturovat aplikaci jako démona. Je pravdou, ºe výsledný kód aplikace je sloºit j²í, p enositelnost hor²í a není zde moºné mluvit o platformové nezávislosti (co se implementace v C++ tý e). Nicmén získáme tím výhodu v podob relativn malé reak ní doby, protoºe ve²keré informace jsou za b hu uloºeny v opera ní pam ti a není je nutno na ítat z pevného disku. Systém periodického monitorování za ízení m ºe být jednodu²e spravován jedním vláknem procesu, zatímco ostatní vlákna se starají o p íchozí a odchozí poºadavky. Transformace dat pak m ºe být bez úhony sou ástí samotného programu Navrhovaná aplikace Fáze b hu navrhovaného systému zobrazuje diagram na obrázku 4.7. Obrázek 4.7: Fáze b hu programu Inicializace V první, inicializa ní, fázi je na ten kongura ní soubor, jehoº specikace bude popsána v kapitole 5. Tento soubor obsahuje ve²keré informace o monitorovaných za ízeních, stejn tak jako základní nastavení protokolové brány. Kaºdé za ízení musí mít denováno SNMP

43 4.2. STRUKTURA PROGRAMU 29 spojení (adresu), seznam MIB, které vyjad ují v²echny nabízené informace. Dále bude obsahovat nastavení ohledn asynchronních událostí a jakému manaºerovi je nutno je p eposílat. D leºitým nastavením je i verze SNMP protokolu, jakou za ízení podporuje. Protokolová brána bude mít sama o sob speciální ást, která bude denovat komunika ní porty, na kterých budou p ijímány a zpracovávány poºadavky, cesty k r zným logovacím soubor m a cesty k adresá i s MIB a XML soubory. Sou ástí inicializace je i ov ení, zda-li v²echna monitorovaná za ízení fungují. Pakliºe n které nebudou funk ní, systém je ze seznamu vy²krtne a nebude je nabízet manaºer m ke správ Transformace dat Transformace dat p edstavuje samotné mapování MIB do XML tak, jak bylo popsáno d íve. Pro kaºdé za ízení m ºe být specikováno n kolik r zných MIB, jak ve ejné, tak proprietární. Pro kaºdé za ízení je tedy nutno vytvo it XML dokument, popisující ve²keré MIB informace. V tomt míst jsou moºné dv cesty, jak vybudovat výstupní XML dokument. Jednou moºností je zahrnout ve²keré informace o v²ech za ízeních do jednoho souboru, který potom bude rozesílán kaºdému manaºerovi, jenº si o n j ekne. Tato varianta je sice praktická, ale neefektivní. Pro za ízení s velkým mnoºstvím informací by byl výsledný dokument opravdu veliký. Kdyby manaºer cht l spravovat pouze jediné za ízení, byl by stejn nucen stáhnout velký objem dat, neº by mu bylo dovoleno pracovat dále. Proto bude pouºito následujícího schématu. Systém bude p i prvním kontaktu s manaºerem publikovat pouze informace týkající se po tu a typu za ízení, které spravuje. Jednotlivá za ízení budou mít sv j samostatný soubor s daty. Manaºer si pak bude moci zvolit pouze ur itá data, která ho zajímají. Tím se velmi sníºí po áte ní zatíºení linky Zpracovávání poºadavk Po úsp ²ném pr chodu ob ma p echozími fázemi se program dostává do situace, kdy vy kává na p íchozí poºadavky, a jiº ze strany manaºera i SNMP za ízení. Jak jiº bylo popsáno na za átku této kapitoly, o komunikaci se starají dva moduly - SNMP a XML. Proto taky komunika ní rozhraní se d lí na dv ásti. SNMP modul bude komunikovat pomocí protokolu UDP, posíláním SNMP zpráv. Tato ást rozhraní bude blíºe popsána v následující kapitole. Komunikace v rámci XML je na bázi HTTP protokolu. Pro zpracování mnoha po- ºadavk, které je nutno o ekávat, bude pouºito HTTP serveru. V tomto p ípad se nám nabízí dv moºnosti e²ení - vyuºijeme n jakého jiº stávajícího webového serveru (Apache, Tomcat,...), na kterém budeme spou²t t CGI script a tak komunikovat s na²ím programem, nebo do aplikace n jaký jednoduchý server naimplementujeme. Výhodou jiº existujícího e²ení by byla pouhá konstrukce komunika ního kanálu mezi protokolovou

44 30 KAPITOLA 4. NÁVRH SYSTÉMU branou a zmín ným serverem. Je ale pravd podobné, ºe bude pot eba mít v t²í kontrolu nad p ijímanými a odesílanými zprávami, coº vlastní implementovaný server poskytuje. P ednostn tedy bude vybrána varianta s embedded HTTP serverem. Ve spojitosti s protokolem HTTP je nutné zmínit pouºití certikát pro zabezpe ený p enost a pouºití protokolu HTTPS. Pakliºe by bylo vyuºito externího webového serveru, bude ponechána ve²kerá zodpov dnost a kongurace na administrátorovi serveru, který se bude muset postarat o obdrºení a distribuci certikátu. Jestli bude server sou ástí protokolové brány, bude nutno p iloºit certikát k aplikaci a v kongura ním souboru zajistit jeho pouºití. 4.3 Správa protokolové brány V rámci spravovaných za ízení se naskýtá otázka, jestli by bylo moºno spravovat i samotnou bránu p es navrºený XML protokol (je my²lena aplikace jako taková). Navrºený systém tuto skute nost neumoº uje. Samotná brána nebude vykazovat vlastnosti agenta. Ke správ stroje, na kterém brána pob ºí, bude nutné pouºít XML i SNMP agenta, který tuto funkcionalitu bude zaji² ovat. Je moºné pak v kongura ním souboru nastavit, aby brána nabízela komunikaci se SNMP agentem na tomtéº stroji. XML agent bude komunikovat s manaºerem p ímo na denovaném portu. Implementace takového agenta ale jiº p esahuje rámec této práce. Správa aplikace je pak omezena pouze na kongura ní soubor a bude ji nutné p i kaºdé zm n restartovat (jak je tomu nap íklad i u kongurace webových server ). Je to z d vodu zachování integrity poskytovaných dat. P i zm n informa ních bází jednotlivých za ízení, p idání i odebrání monitorovaných stroj, je nutno p egenerovat v²echny XML dokumenty, které jsou pak distribuovány manaºer m. Nekorektnost dat, které manaºer obdrºel a které by byly aktuální, kdyby se zm nily za plného provozu, by mohla mít pak váºné následky na data, která by manaºe i dostali zp t. 4.4 XML manaºerská aplikace Sou ástí této práce je i implementace základního XML manaºera tak, aby dovolil ukázat ve²keré funk ní aspekty protokolové brány. Program bude mít implementován celý XML komunika ní protokol tak, jak byl navr- ºen v kapitole 3. Tudíº základní p íkazy - Discovery, Publication, Get, Set, Subscription, Distribution. Správu monitorovaných za ízení zahajuje komunikací bu p ímo s agentem i bránou. Vyºádá si od nich dokument, který popisuje nabízené informace. Pakliºe se jedná o komunikaci s bránou, tak nejprve zjistí, jaká za ízení jsou k dispozici a pak si n které vybere a teprve pak poºádá o jejich XML popis dat. Algoritmus budování XML stromu pouºitelného pro dal²í interakci se za ízeními je stejný jako v p ípad brány a bude popsán v dal²í kapitole.

45 4.4. XML MANAšERSKÁ APLIKACE 31 Aplikace bude napsána v jazyce C++ stejn jako protokolová brána. Vyuºití podpory grackého rozhraní je moºné.

46 32 KAPITOLA 4. NÁVRH SYSTÉMU

47 Kapitola 5 Implementace Vlastní implementace protokolové brány je v této kapitole vysv tlena v rámci n kolika ástí. Nejprve je popsána struktura programu, popis t íd, jejich vztah mezi sebou a hlavní funkce, kterou plní. Následuje p ehled v²ech pouºitých knihoven pro lep²í pochopení dal- ²ího popisu funkce aplikace. Dal²í ást tvo í vysv tlení výkonného cyklu programu krok za krokem od spu²t ní aº po zpracování jednotlivých zpráv. Jsou vysv tleny dosaºené výsledky p i pam ové optimalizaci a detailn rozebrán systém komunika ních front. Jako poslední je popsán XML manaºer, který byl navrºen v p edchozí kapitole. 5.1 T ídy, vlastnosti a jejich vztahy Jak bylo p edesláno v p edchozí kapitole, p i tvorb byl dáván velký d raz na modularitu jednotlivých sou ástí programu. V praxi to znamená, ºe jednotlivé komunika ní jednotky brány nemají tu²ení, jak ta druhá provádí konkrétní operace, ale jediným spojením jsou p esn denované struktury obsahující ve²keré nutné informace. Strukturu programu tvo í ty i t ídy: SnmpXmlGate - hlavní t ída, která ovládá b h programu. P i spou²t ní inicializuje ve²keré datové struktury, p ipraví oba komunika ní moduly a p edá jim ízení. SnmpModule - komunika ní modul pro zpracování ve²kerých SNMP poºadavk. Plní dv funkce. První je získávání dat z agent v reakci na dotaz od manaºera (resp. XML modulu). Druhou je zpracování asynchronních událostí (Trap, Noti- cation), které se na agentech vyskytnou a získané informace za²le denovaným manaºer m. Mib2Xsd - transforma ní t ída pro p eklad MIB databáze do XML schématu. Netvo í v²ak jenom tento popis, ale zárove i vytvá í nální XML dokument, se kterým pak hlavní program pracuje. 33

48 34 KAPITOLA 5. IMPLEMENTACE XmlModule - druhý komunika ní modul pro zpracování XML poºadavk. Tato t ída je vlastní implementací navrºeného XML protokolu a je pro tuto práci st - ºejní. Vzájemné vztahy t chto t íd jsou vyjád eny na obrázku 5.1. Obrázek 5.1: Schéma t íd aplikace 5.2 Pouºité knihovny P i tvorb programu bylo pouºito n kolik knihoven, které zaji² ují pot ebné vyuºívané funkce. Xerces-C++ a Xalan-C++ - knihovny zaji² ující manipulace s XML dokumenty, vyhledávání pomocí XPath výraz ([6], [7]). Net-SNMP - knihovna napsaná v jazyce C, ur ená pro interpretaci a manipulaci s daty MIB databází, zasílání a p ijímání datových SNMP paket ([8]).