XML Správa sít. Bc. Pavel imon. ƒeské vysoké u ení technické v Praze Fakulta elektrotechnická Katedra po íta. Diplomová práce

Transkript

1 ƒeské vysoké u ení technické v Praze Fakulta elektrotechnická Katedra po íta Diplomová práce XML Správa sít Bc. Pavel imon Vedoucí práce: Ing. Peter Macejko Studijní program: Elektrotechnika a informatika, strukturovaný, Navazující magisterský Obor: Výpo etní technika 1. ledna 2012

2 iv

3 v Pod kování Na tomto míst bych cht l pod kovat vedoucímu práce panu Ing. Peteru Macejkovy za jeho pomoc, rady a p edev²ím trp livost.

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 This work describes implementation of computer network management application. Communication between individual agents and managers is accomplished by XML based protocol. This protocol complements and extends common SNMP protocol. The management application is implemented as a JSP based web application. By implementing this application the long term project of creating a XML based network management system is accomplished. This work is continuation of this project, that has been started in another Master's Theses. Abstrakt Tato práce popisuje implementaci managerské aplikace pro správu za ízení na po íta ové síti. Pro komunikaci mezi jednotlivými agenty a managery je pouºíván XML protokol, který vhodným zp sobem dopl uje a zobec uje klasický protokol SNMP. Managerská aplikace je implementována jako webová aplikace za pomoci JSP. Provedená implmentace je zavr²ením snahy o vytvo ení systému správy sí ových za ízení s vyuºitím moºností XML, jehoº tvorba byla zahájena v jiných diplomových pracech. ix

8 x

9 Obsah 1 Úvod 1 2 SNMP a XML SNMP Standardy SMI a MIB SMI MIB Verze protokolu SNMPv SNMPv SNMPv XML XML schéma XSL Zpracování XML SAX DOM XML protokol pro správu sít Motivace Cíle Informa ní model Oznamovací zprávy Adresace dat Mapování MIB do XML Datové typy Import MIB P eklad MIB stromu Komunika ní model DICOVERY PUBLICATION GET SET RESPONSE EVENT xi

10 xii OBSAH SUBSCRIBE DISTRIBUTION Implementované projekty Java manager a brána Informa ní model Komunika ní model Zhodnocení XML-SNMP brána v C SNMP modul XML modul Zhodnocení Výsledky výzkumu TU Braunsweig POSTECH Web services for network management ƒínský výzkum XMLN over VoIP Zhodnocení Návrh systému Stav projektu Managerská aplikace Programovací jazyk Komunika ní modul Dohledový modul Uºivatelský modul Kongura ní modul Realizace Struktura aplikace Uºivatelský modul JSP Stránky Servlety Beany Pomocné t ídy Dohledový modul Kongura ní modul Komunika ní modul Úpravy XML-SNMP brány Výkonný cyklus aplikace

11 OBSAH xiii 8 Testování Testovací prost edí Výsledky test DISCOVERY GET SET SUBSCRIBE EVENT Ukládání dat Záv r 51 A Seznam pouºitých zkratek 57 B Instala ní a uºivatelská p íru ka 59 B.1 Kompilace B.2 Instalace B.3 Kongurace B.4 Pouºívání B.4.1 Status B.4.2 Discover B.4.3 Browse B.4.4 Events B.5 Testovací XML-SNMP brána C Obsah p iloºeného CD 65

12 xiv OBSAH

13 Seznam obrázk 2.1 Princip SNMP ([13]) P íklad MIB stromu ([13]) Mapování datových typ SMIv1 do XML schématu ([23]) Mapování makra OBJECT TYPE (simpletype) ([23]) Schéma prototypové brány ([27]) Schéma C++ brány ([20]) Vlákna a fronty SNMP modulu ([20]) Struktura POSTECH agenta ([19]) Architektura systému ([25]) Architektura systému ([15]) Schéma aplikace Formulá operace DICSOVERY Výsledek DISCOVERY Operace GET Výsledek GET Operace SET Výsledek SET Formulá operace SUBSCRIBE Výsledek SUBSCRIBE Dohledová operace P ijatá zpráva EVENT B.1 Stránka Status B.2 Stránka Discover B.3 Stránka Browse xv

14 xvi SEZNAM OBRÁZK

15 Seznam tabulek 7.1 Jednoduchý POST multipart POST Výpis logu XML-SNMP brány xvii

16 xviii SEZNAM TABULEK

17 Kapitola 1 Úvod I kdyº jsou po íta ové sít obor tém stejn starý jako po íta e samotné, tak o opravdovém rozmachu se dá hovo it aº s nástupem osobních po íta a internetu na p elomu osmdesátých a devadesátých let dvacátého století. A kam tento obor od té doby postoupil je tém nepochopitelné. Jak se na jedné stran roz²i uje po et do po íta ových sítí p ipojitelných za ízení - od osobních po íta jsme postoupili k notebook m, netbook m, inteligentním telefon m a tablet m. Tak na druhé stan roste snaha na r zné sluºby - televizi, rozhlas, telefonní hovory,... - pohlíºet ist jako na r zné druhy datových p enos. Není pak d vod na jejich p enos budovat speciální jednoú elové sít, ale pouºívat sít univerzální. Ruku v ruce s rostoucí poptávkou jde i poºadavek na kvalitu a dostupnost takových sluºeb. M ºe být tedy pon kud p ekvapivým zji²t ním, ºe základem moderních systém pro sledování a správu po íta ových sítí je tém tvrt století starý protokol, navíc navrºený jako do asné e²ení - Simple Network Management Protocol (SNMP). Ten ale není bez nedostatk. Od roku 2006 probíhá pod vedením Doc. Ing. Jane ka a pozd ji Ing. Macejka na fakult vývoj nového protokolu, který má zaru it kompatibilitu s SNMP a ostranit jeho hlavní nedostatky. Tato práce je pokra ováním tohoto projektu a klade si dva cíle. Za prvé revidovat p edchozí práce a jejich výstupy, porovnat je s výsledky podobných výzkumných projekt ve sv t. A za druhé na základ tohoto porovnání implementovat chyb jící ásti tak, aby byla výsledkem funk ní dvojice manager - agent. Kapitola 2 se zabývá popistem zálakdních technologií pouºitých v této práci - protokolu SNMP a jazyka XML. V kapitole 3 je popsán protokol navrºený Peterem Macejkem s úpravami z práce Tomá²e Hrocha. Kapitola 4 popí²e výstupy implementa ních prací Tomá²e Hrocha a Michala Tre²a. Tím bude ukon eno shrnutí výsledk p edchozích projekt. Porovnání výsledk p edchozích prací s výsledky podobn zam ených výzkumných projekt odsahuje kapitola 5. Analýza poºadavk na systém a diskuze zp sobu implementace je v Kapitole 6. V kapitole 7 je pak podrobný popis implementovaného systému a jeho funkcí. Ov ení funk nosti je popsáno v kapitole 8. 1

18 2 KAPITOLA 1. ÚVOD

19 Kapitola 2 SNMP a XML 2.1 SNMP Simple Network Management Protocol je dnes základem správy po íta ových sítí. Vznikl v roce 1988 jako vývojová v tev protokolu Simple Gateway Monitoring Protocol (SGMP). P vodn m l slouºit jen jako nástroj na správu nizkoúrov ových sí ových prvk. Postupn se ale stal de facto standardem pro celý obor. Základní princip protokolu SNMP je zachycen na obrázku 2.1. SNMP vyuºívá model agent-manager. Kde manager je aplikace, která sleduje a spravuje po ízené agenty. Agent je aplikace spu²t ná na spravovaném za ízení. Stará se o p eklad a vykonání p íkaz managera. B ºná komunikace mezi managerem a agentem pracuje na principu poºadavek-odpov. Manager za²le agentovi p íkaz, ten ho vykoná a ode²le odpov. Pokud ale u agenta nastane n jaká vyjíme ná situace m ºe managera informovat zasláním zprávy Trap, nebo Inform (popsány dále). Podle standardu m ºe SNMP vyouºívat r zné transportní protokoly. V naprosté v t²in p ípad se ale pouºívá nepotvrzovaný User Datagram Protocol (UDP). Obecn tedy není moºné zaru it bezchybnou komunikaci. N které zprávy nemusí v bec dorazit k cíli Standardy SMI a MIB SMI Pro správné fungování celého systému správy nesta í jen denovat formát p ená²ených zpráv. Také je nutné ur it zp sob reprezentace dat, jaká data se budou p ená²et a jaká bude jejich struktura. Za tímto ú elem byla do standartu za azena Structure and Identication of Management Information for TCP/IP-based Internet - krátce SMI. Ta popisuje základní datové struktury a datové typy. Základní datovou strukturou je objekt. Ten musí mít jméno, syntaxi a kódování. Jméno (Object identier - OID) slouºí jako jednozna ná identikace objektu. Syntaxe ur uje jeho datový typ a nastavení kódování umoº uje správnou serializaci p i p enosu. Pravidla dále ur ují, ºe jednotlivé objekty tvo í hierarchickou stromovou strukturu. Pro sestavování OID v této struktu e se pouºívá Abstract Syntax Notation One (ASN.1). Ta funguje na principu íslování potomk kaºdého uzlu a sestavování t chto ísel do OID od ko ene. RFC také ur uje jaká sekvence ísel (OID) je p i azena ko enu správní databáze. 3

20 4 KAPITOLA 2. SNMP A XML Obrázek 2.1: Princip SNMP ([13]) MIB Zkratka MIB znamená Management Information Base. Jedná se o databázi ve které se ukládání objekty vytvo ené pravidel ur ených SMI. Jak uº bylo uvedeno v ásti v nované SMI, objekty v MIB tvo í stromovou strukturu. Za OID nejblíºe ko enu zodpovídají standartiza ní organizace. Níºe umíst né OID pak spravují jednotliví výrobci. Kaºdá spole nost si m ºe vytvo it svou privátní v tev a do ní uloºit specické informace svých za ízení. V dne²ní dob existuje více neº 100 takových MIB (uvádí se i více neº 200). P íklad ásti MIB stromu je na obrázku 2.2. Pro objekty, které nepro²ly procesem ociálního schválení a standartizace je vyhrazena experimentální v tev. Objekty MIB je moºné rozd lit na dv kategorie. První jsou skalární objekty. Ty p edstavují jeden parametr za ízení - nap íklad po et odeslaných TCP segment. Druhou jsou tabelární objekty vzniklé spojením n kolika souvisejících objekt - nap íklad tabulka informací o sí ových rozhraních za ízení.

21 2.1. SNMP 5 Obrázek 2.2: P íklad MIB stromu ([13]) Verze protokolu SNMP byl poprvé standartizován v roce Od té doby vznikly t i hlavní verze. Nov j²í verze vznikaly hlavn za ú elem zlep²ení bezpe nostního modelu, p ípadn dopln ní dal²ích funkcí, nebo datových typ SNMPv1 První verze protokolu byla popsána ve standardu RFC 1068 [10], pozd ji RFC 1157 [21] v roce Protokol byl navrhován s minimální náro ností na zdroje agenta. Tento cíl se povedlo úsp ²ne splnit. P enos SNMP paketu byl moºný p es jeden z podporovaných protokol ni²²ích vrstev - User Datagram Protocol (UDP), Internet Protocol (IP), Novell Internet Packet Exchange (IPX) a dal²í. Byly denovány tyto operace: Get Request Dotaz na hodnotu uzlu ur eného OID. Sm r od managera agentovi.

22 6 KAPITOLA 2. SNMP A XML Get Next Request Dotaz na odnotu uzlu následujícího po OID. Sm r od managera agentovi. Set Request Nastavení hodnoty uzlu identikovaného OID. Sm r od managera agentovi. Get Response Odpov d na p íkaz GET, nebo SET s hodnotou uzlu. Sm r od agenta managerovy. Trap Asynchronní informace o významné události, nebo chyb. Sm r of agenta managerovi. Nejv t²í slabinou první verze je velmi jednoduché zabezpe ení. Kaºdý SNMP paket je podepsán tzv. Community Stringem. Ten slouºil pro ov ení práv p ístupu k poloºkám MIB. Protoºe Community String není nijak ²ifrován, je jeho zji²t ní ze odposlechnuté komunikace velmi snadné. Také není moºné jedním dotazem získat hodnotu více objekt. Kaºdý musí být zvlá² získám vým nou zpráv Get a Response. Komunika ní reºije tedy zabírá nezanedbatelnou ást komunka ního kanálu SNMPv2 Hlavním d vodem vzniku druhé verze protokolu bylo zlep²ení velmi ²patného zabezpe ení verze první. Ale proces schvalování standard RFC [3] byl velmi sloºitý a nakonec neúsp ²ný. Výsledkem byly ty i vzájemn nekompatibilní verze ozna ované jako SNMPv2 party-based, SNMPv2u, SNMPv2* a SNMPv2c. Z konkuren ních standard se nejlépe uplatnila verze SNMPv2c. Ta p ebrala nové operace a datové typy druhé verze a zachovala p vodní systém zabezpe ení zaloºený na Community Stringu. Nové operace jsou: Get Bulk zefektivn ní vyuºití kanálu pomocí p ená²ení v t²ího mnoºství dat jednou operací. Inform Stejná funkce jako TRAP, ale manager musí p íjem zprávy potvrdit. Response Potvrzení p ijetí zprávy INFORM managerem. Zasílá manager agentovi SNMPv3 Zabezpe ení protokolu zlep²ila aº verze 3, standartizovaná jako RFC [3]. Novinkou bylo i umoºn ní vzdálené kongurace agenta. Model zabezpe ení je postaven na dvou základních komponentách - User Security model (USM) a View-based Access Control Model (VACM). USM má na starosti autentikaci a ²ifrování SNMP paket a VACM spravuje p ístupová práva k dat m v MIB. Návrh USM se zam il na tato bezpe nostní rizika: Integrita dat zajistit, ºe p i p enosu nejsou data zm n na t etí stranou. P vod dat zajistit, se aby t etí strana nemohla vydávat jednoho z ú astník komunikace Utajení dat zabránit t etí stran íst obsah p edávaných zpráv Po adí zpráv zajistit, aby t etí strana nemohla zm nit po adí zpráv.

23 2.2. XML 7 Autentikaci a soukromí zaji² uje systém uºivatel a tajných klí. Autentikace je zaji²t na pomocí Hash-based Message Authentication Code - (HMAC-MD5)[18] a (HMAC- SHA)[18] s soukromí pomocí Data Encryption Standard (DES)[2]. VACM umoº uje vytvá et skupiny uºivatel a p i azovat jim p ístupová práva. Je moºné omezit jak p ístup k ástem MIB, tak ur it jaké operace m ºe skupina nad MIB vykonávat. Vzdálená kongurace se provádí pomocí nastavnování (operace SET) hodnot ur itých poloºek MIB. 2.2 XML Extensible Markup Language (XML) [26] vznikl odvozením ze Standard Generalized Markup Language (SGML)[7]. SGML je velmi univerzální, ale sou asn komplikovaný zna ovací jazyk. Díky své univerzálnosti se stal velmi oblíbeným a jeho sloºitost vedla k odvozování jednodu²²ích jazyk. Takto krom XML vznikl i jiný dnes velmi d leºitý jazyk - HyperText Markup Language (HTML) [14]. XML vzniká jako jazyk pro vytvá ení strojov itelných dokument p ená²ených po Internetu. Dal²ími klí ovými poºadavky byla maximální jednoduchost a univerzálnost. I p es d raz na strojové zpracování m l být XML dokument pro lov ka itelný. Pracovní skupina okolo Jona Bosaka tyto poºadavky nejen sestavila, ale i dokázala úsp ²n vy e²it. World Wide Web Consortium (W3C) p ijako XML jako standard v roce Jako zna kovací jazyk pouºíva XML zna ky(tagy) pro vytvá ení struktury dokumentu. Základním prvkem dokumentu je element tvo ený párem zna ek (nap. <ulice>... <\ulice>). Ten m ºe mít denované atributy a m ºe obsahovat dal²í elementy. Elementy se nesm jí p ekrývat(element vloºený do jiného musí být uzav en p ed svým rodi em). Dob e sestavený XML dokument má stromou strukturu s jedním ko enovým elementem a jeho potomky. Na rozdíl od HTML XML neur uje význam jednotlivých zna ek. Na to je moºné pouºít bu star²í Document Type Denition (DTD) [26], nebo nov j²í XML schéma(xsd, nebo WXS) [9] XML schéma Jak uº bylo uvedeno v p edchozím textu XML schéma je nástroj na denování struktury a obsahu dokumentu. Oproti strar²ímu DTD vyuºívá syntaxe XML. Je ho tedy moºné zpracovávát pomocí stejných nástroj jako XML dokumenty. Za hlavní zlep²ení je ale povaºován systém denice dat. Ten oproti DTD umoº uje kontrolovat datový typ atributu nebo elementu. Specikace XSD denuje 19 primitivních datových typ [11] a formuluje pravidla pro vytvá ení dal²ích. T i základní zp soby jsou: Omezení mnoºiny hodnot. Sestavení posloupnosti hodnot. Moºnost vybrat hodnoty z n kolika datových typ. Pomocí t chto pravidel bylo ve specikaci denováno dal²ích 25 datových typ [11]. Dal²í klí ovou vlastností XSD je vytvá ení prostor jmen. Tím se dají velmi snadno e²it konikty p i slu ování dokument.

24 8 KAPITOLA 2. SNMP A XML XSL Protoºe XML neur uje význam zna ek, bylo pot eba najít zp sob jak m nit formát dokumentu. e²ení se nazývá XML Stylesheet language (XSL) [11]. Tvo í ho t i ásti. XSLT [12] - jazyk pro transformování XML dokument, XPath [22] - jazyk pro prohledávání XML dokument a slovník pro formátování XML dokument - XSL Formating Objects [11]. XSLT je nejd leºit j²í ástí XSL standardu. Umoº uje vytvo it transforma ní ²ablonu. Ta denuje pravidla podle kterých jeden, nebo více vstupních dokument transformováno na jiné dokumenty. Trasformace m ºe obná²et zm nu XML schématu, nebo nap íklad jen odstranit ást dokumentu. Výstupním formátem nemusí být jen XML. XSTL se b ºn pou- ºívá na p eklad XML dokument do HTML nebo XHTML. Dal²í moºností je transformace dokumentu do XML Formatting Objects. Takový výstup pak m ºe být p eveden do dal²ích formát, mezi jinými do PDF, nebo PostScript. Pro prohledávání dokumentu vyuºívá XPath jeho stromové struktury. Pro vyjád ení cesty ve stromu se pouºívá lomítková notace, podobná zp sobu adresování v souborovém systému. Takto vyjád ená cesta nemusí být absolutní, tedy nemusí za ínat v ko enu stromu. Výsledek dotazu je dále moºné omezit nap íklad podle hodnoty atributu. Více informací o XPath se dá nalézt nap íklad zde [22] Zpracování XML Do v²eobecného pouºívání se dostaly dva zp soby strojového zpracování XML dokument. První, známý pod zkratkou SAX (Simple API for XML), zpracovává dokument proudov. Druhý, nazývaný DOM (Document Object Model) zpracovává dokument do struktury objekt se stejnou hierarchií. Pro oba p ístupy jsou dostupné imlementace ve v t²in hlavních programovacích jazyk SAX P i proudovém zpracování je dokument postupn ten od za átku do konce. P i p e tení rozpoznané ásti dokumentu (za átek, nebo konec elementu, jeho t lo, nebo atribut apod.) je vyvolána událost. Zpracování dokumentu je tedy záleºitostí obsluhy série událostí. Tento p ítup je velmi rychlý a má malou pam ovou náro nost. Ale u sloºit strukturovaných dokument m ºe být implementa n velmi náro ný. Pokud je pot eba k dokumnetu p istupovat náhodn a ne jen sekven n není moºné tuto metodu pouºít DOM Document Object Model je v mnoha sm rech opakem SAX. P i zpracování je celý dokument na ten do pam ti jako stromová struktura objekt. V této struktu e p edstavuje kaºdý objekt jeden element dokumentu. Hlavní výhodou je práv na tení celého dokumentu do pam ti. Úpravy dokumentu se dají provád t velmi snadno. P edev²ím je nad dokumentem moºné provád t dotazy jazykem XPath. Na t ní dokumentu do pam ti je sou asn i hlavní nevýhodou. Pam ová náro nost je oproti SAX v t²í. Také vytvá ení struktury objekt je (relativn ) pomalej²í. U malých dokument nejsou tyto rozdíly p íli² patrné, ale u v t²ích uº mohou být zna né.

25 Kapitola 3 XML protokol pro správu sít Jak jiº bylo uvedeno, ve své diplomové práci Peter Macejko navrhl systém pro správu po íta- ových sítí zaloºený na XML. Cílem této kapitoly je poskytnout stru né vysv tlení motivace vývoje takového protokolu a poskytnout jeho základní popis. Detailní informace je moºné najít v p vodním textu Petera Macejka [23]. 3.1 Motivace SNMP je dnes standardem v problematice správy po íta ových sítí. Jsou pro to dva d leºité d vody: Implementace SNMP agent jsou dostupné pro naprostou v t²inu sí ových prvk - od po íta p es tiskárny po routery. SNMP je roz²í itelný protokol. Systém MIB umoº uje bez komplikací komunikovat s tak rozdílnými za ízeními jako jsou routery a tiskárny. Sou asn moºnost denovat vlastní MIB zp ístupní i specické vlastnosti konkrétního za ízení, nebo výrobce. P esto se nejedná o dokonalé e²ení. Mnoho nedostatk pramení z p vodní specikace protokolu. V dob jeho vzniku byl rozsah a sloºitost sítí na kterých je dnes pouºíván jednodu²e nep edstavitelný. Za hlavní nedostatky je povaºováno: P es "Simple"v názvu a malou náro nost na systémové prost edky je protokol náro ný na implementaci. Pomalé získávání v t²ích objem dat z MIB. P es ur itá zlep²ení (nap. operace Get Bulk) je kaºdá poloºka získávána samostatn vým nou ºádosti a odpov di mezi managerem a agentem. Kaºdá taková operace je zatíºena zpoºd ním a ztrátami p i p enosu sítí. Neefektivní vyuºívání kapacity kanálu. Roli zde hraje jednoduché kódování paket, p ená²ení dlouhého (a stále stejného) prexu OID a tzv. overshoot([23] kapitola 2.2.4) u operace Get Bulk. 9

26 10 KAPITOLA 3. XML PROTOKOL PRO SPRÁVU SÍT P enost tabulek je velmi sloºitý. Problémy jsou hlavn p i p enosu "d ravých"tabulek(viz. [23] kapitola 2.2.4). Uº mnohokrát zmín né zabezpe ení protokolu je nedostate né. Zde není na vin ani tak specikace protokolu, jako spí²e selhání standartiza ních snah v této oblasti. Jen mén roz²í ená verze 3 má praktické zabezpe ení. Ale i ta je citlivá na slovníkové útoky a útoky hrubou silou. Pouºití transportního protokolu UDP pak nabízí moºnost podvrºení paket t etí stranou. Bezpe nostní funkce SNMPv3 by ale m ly tomuto útoku zabránit. Ohroºeny tímto zp sobem tedy jsou jen star²í verze. 3.2 Cíle Na základ zmín ných nedostatk a studia podobn zam ených publikací stanovil Peter Macejko základní poºadavky na navrhovaný protokol takto: Musí vyuºívat XML dokumenty pro p enos dat a musí vyuºívat informa ní model zaloºený na XML schématu. M l by být nenáro ný na implementaci. Musí být pouºitený na existujících za ízeních. Musí obsahovat mechanizmy pro autentikaci a ²ifrování p ená²ených dat. Sou asn ale musí umoº ovat i nezabezpe ený provoz. (Slabina zlep²ování zabezpe ení SNMP byla v jeho vynucování za kaºdých okolností) informa ní model musí být roz²í itelný. Aby bylo moºné tyto poºadavky splnit bylo nutné vy e²it n kolik díl ích problém. Nejprve bylo nutné navrhnout informa ní model pro popis datových struktur a jejich vztah. Pro zaji²t ní kompatibility s SNMP byl navrºen zp sob mapování MIB do XML schémat. Dále byl ur en zp sob jakým bude probíhat komunikace a zp sob jejích zabezpe ení. 3.3 Informa ní model Ú elem infroma ního modelu je mapování vlastností n jakého za ízení do jasn ur ené struktury. P i e²ení této otázky hrálo hlavní roli zaji²t ní kompatibility s MIB SNMP. Nabízely se dv moºnosti - zaloºit model na MIB, nebo ignorovat MIB model a budovat model na základ objektového paradigma. P ímé mapování MIB strom - XML strom je velmi snadné na implementaci a nabízí moºnost automatického p evodu mezi MIB a XML schématem. Sou asn ale nep iná²í ºádné zlep²ení proti MIB a vytvá í p ímou závislost XML stromu na MIB. Není tedy moºné upravit XML strom bez úpravy MIB. XML slouºí jen jako p enosový protokol a není mnoho prostoru na uplatn ní jeho vlastností. Protoºe objektové mapování nevyuºívá struktury MIB není moºné p evod MIB do tohoto infroma ního modelu provád t automaticky. Pro kaºdý MIB objekt se musí ru n ur it kam

27 3.4. MAPOVÁNÍ MIB DO XML 11 je mapován. Z druhé strany stromová struktura XML dokumentu omezuje moºnosti jako mapování provád t - v závislostech objekt obecn mohou být cykly. Po analýze se jako nejvhodn j²í ukázala kombinace obou p ístup. Model simuluje objektovou d di nost pomocí odvození a roz²í ení XML schématu. Spravovaný objekt pak tvo í moduly. T ch existuje n kolik druh. Z hlediska této práce je d leºitá kategorie speciálních modul - tzv. bran. Jejich úkolem je zajistit kompatibilitu se za ízeními nepodporujícími XML protokol. Tedy p eklad XML p íkaz do formátu srozumitelného pro dané za ízení. Brána sou asn reprezentuje nekompatibilní za ízení jako své moduly. Pro odvození typ se pouºívá d di nost. Od abstraktních (nap. "Interface") se postupuje ke kontrétním (nap."ethernetinterface"). Popis modulo je postaven na XSD schématu. Na schéma modulu jsou kladeny ur ité poºadavky. Musí být popsána funk nost, typ a cesta pro adresaci jednotlivých uzl. Modul musí mít p id leno unikátní jméno a denovaný ko enový element. Ten se vyuºívá p i spojování více modul dohromady. Popis za ízení je také zaloºen na XML schématu. To íká kam se mají mapovat jednotlivé moduly Oznamovací zprávy Sou ástí specikace je i popis jakým zp sobem jsou e²eny zprávy upozorující managera na mimo ádnou událost u agenta (oznamovací zprávy). V SNMP jsou sou ástí datového modelu i kdyº neobsahují ºádná data. V navrºeném systému je jim vyhrazen speciální modul za ízení. Manager proto m ºe snadno zjistit jaké oznamovací zprávy m ºe za ízení zaslat Adresace dat Poslední ástí specikace informa ního modelu je zp sob adresace dat. Protoºe je zaloºen na XML je moºné vyuºít dotazy zaloºené na XPath, nebo XQuery. 3.4 Mapování MIB do XML Pro komunikaci se za ízeními nepodporujícími XML protokol mají slouºit d íve zmín né protokolové brány. Vzhledem k roz²í ení protokolu SNMP je XML-SNMP brána prioritou. Aby bylo v bec moºné zahájit implementa ní práce, musel být navrºen zp sob mapování MIB za ízení do XML schématu brány. Tento úkol znamenal vy e²it t i díl í problémy. Prvním byl p eklad datových typ, druhým jak importovat a skládát jednotlivé MIB do sebe a t etím samotné konverze MIB stromu Datové typy Primitivní datové typy (integer, string,...) je moºné mapovat p ímo na jejich ekvivalenty v XML schématu. Mapování datových typ specických pro SNMP (Gauge, IpAddress,...) si ºádalo vytvo ení zvlá²tních pravidel. Na obrázku 3.1 je uveden zp sob mapování datových typ SMIv1 do XML schématu. Protoºe SMI umoºnuje denovat nové datové typy bylo nutné navrhnout i zp sob konverze pro tyto p ípady. Detailní popis v²ech navrºených pravidel je uveden v kapitole v [23].

28 12 KAPITOLA 3. XML PROTOKOL PRO SPRÁVU SÍT Obrázek 3.1: Mapování datových typ SMIv1 do XML schématu ([23]) Import MIB Návrh protokolu po ítá s p id lením unikátního prostoru jmen kaºdé MIB odvozením z jejího názvu. Importy jsou provád ny odkazem na typ s uvedením jeho jmenného prostoru P eklad MIB stromu P i mapování MIB stromu dojde k odd lení denic typ od struktury stromu. Denice je pak moºné pouºívat i v jiném modulu, nebo pokud má uºivatel omezená p ístupová práva k ásti stromu. Objekty jsou v MIB denovány pomocí maker popisujících n kolik typ uzl. V SMIv1 jsou specikována makra OBJECT TYPE a TRAP TYPE. OBJECT TYPE denuje uzel obsahující data. Takovým uzlem m ºe být jednoduchá hodnota, poloºka tabulky, nebo celý ádek tabulky. Transformace se ídí hodnotou v ásti SYNTAX makra. Na obrázku 3.2 je uveden p íklad transformace základního datového typu (simpletype). Zp sob mapování dal²ích typ je op t uveden v [23]. Makro TRAP TYPE denuje schopnost za ízení odeslat zprávu o mimo ádné události. Protoºe neobsahuje data není jeho p ítomnost ve stromu nezbytná. Je proto mapováno mezi denice typ. Povaºuje se za typ jednoduché datum a as (datetime) se zvlá²tním tagem v elementu appinfo. Pro spojení t chto uzl vyuºívá MIB makra OBJECT IDENTIFIER. Dal²í makra jsou denována v SMIv2. Jedná se o MODULE IDENTITY slouºící jako ko en MIB stromu a OBJECT IDENTITY, který lze zjednodu²en popsat jako pojmenovaný OBJECT IDENTI- FIER. SMIv2 také nahrazuje makro TRAP TYPE makrem NOTIFICATION TYPE. Pravidla jejich p evod jsou také uvedena v [23].

29 3.5. KOMUNIKAƒNÍ MODEL 13 Obrázek 3.2: Mapování makra OBJECT TYPE (simpletype) ([23]) 3.5 Komunika ní model Jako zlep²ení proti nepotvrzovanému p enosu SNMP by protokol m l vyuºívat spolehliv j²í potvrzovaný p enos. Sou asn by zprávy m ly mít co nejednodu²²í formát. Jako nejvhodn j²í se ukázalo pouºít protokol HTTP s p enosovým protokolem TCP. Takto se zajistí spolehlivost p enosu. Zprávy protokolu jsou p ená²eny jako XML dokumenty pomocí HTTP zprávy POST. HTTP pouºívající webové rozhraní mají dnes i velmi levná/jednoduchá za ízení. Pouºití t chto protokol tedy nep edstavuje významné zvý²ení HW náro nosti protokolu v porovnání s SNMP. Pouºití HTTP také velmi usnad uje otázku bezpe nosti. Pro zabezpe ení HTTP komunikace existují vyzkou²ené a osv d ené postupy (HTTPS, IPSec,...). XML dokument zprávy má jasn daný formát. Ko enovým uzlem je element message. Ten má n kolik atribut. Nepovinný atribut queue ur uje prioritu zprávy. Agenti a brány ale nemusí prioritu zpráv zohled ovat. Dal²í atributy - password a context slouºí k vymezení p ístupových práv uºivatele. Element message pak m ºe obsahovat n kolik dotaz. Podporované dotazy jsou popsány dále DICOVERY Zpráva kterou si manager vyºádá popis monitorovaných dat. Atribut protocolversion ur- uje jakou verzi protokolu manager pouºívá. objectid ur uje o popis kterého za ízení má manager zájem. Hodnota 0 pak slouºí k získání seznamu za ízení agenta. <message password="1234"> <discovery protocolversion="1" objectid="0" msgid="1" /> </message> PUBLICATION Odpov agenta na DISCOVERY. Obsahuje informace o verzi protokolu a spravovaných za ízeních, nebo detailní popis jednoho za ízení.

30 14 KAPITOLA 3. XML PROTOKOL PRO SPRÁVU SÍT <message> <publication msgid="1"> <info> <xpath>1.0</xpath>... </info> <datamodel> XML schéma spravovaného za ízení </datamodel> </publication> </message> GET Dotaz na hodnotu n jakého uzlu. Uzel je specikován pomocí XPath. <message password="1234"> <get msgid="1" objectid="1">"; <xpath> iso/org/dod/internet/mgmt/mib-2/system/sysdesc </xpath> </get> </message> SET Podobná zpráva jako GET, ale slouºí k nastavení hodnoty uzlu. Obsahuje tedy navíc element value s novou hodnotou. <message password="1234"> <get msgid="1" objectid="1"> <xpath> iso/org/dod/internet/mgmt/mib-2/system/sysdesc </xpath> <value>testovaci zarizeni</value> </get> </message> RESPONSE Odpov na zprávu GET, nebo SET. Obsahuje hodnotu uzlu. U zprávy SET obsahuje hodnotu uzlu po provedení p íkazu. Slouºí tedy jako kontrola, jestli operace usp la. <response msgid="1"> <value>testovaci zarizeni</value> </response>

31 3.5. KOMUNIKAƒNÍ MODEL EVENT Asynchonní zpráva od agenta managerovi o mimo ádné události. Obsahuje informace speci- kující mimo ádnou událost, odesílatele, datum a as. <message> <event msgid="1" senderid="1" eventspec="device/notifications/linkdown"> <data> </data> </event> </message> SUBSCRIBE Pomocí této zprávy se manager p ihlásí k opakovanému odb ru hodnoty n jakého uzlu. Pokud je operace úsp ²n provedena agent odpoví první zprávou DISTRIBUTION s hodnotou uzlu. Atribut frequency ur uje dobu ve vte inách po které mají být zprávy zasílány. Atributy distrid a delete se pouºívají p i ru²ení pravidelného zasílání. <message password="1234"> <subscribe msgid="1" objectid="1" frequency="10"> <xpath> iso/org/dod/internet/mgmt/mib-2/tcp/tcpinsegs </xpath> </subscribe> </message> DISTRIBUTION Zpráva obsahuje pravideln zasílaná data. Pokud je sou asn odebíráno více hodnot, mají ve zpráv stejné po adí jako v ºádosti SUBSCRIBE. Atribut distrid identikuje data na stran managera. <distribution msgid="3" distrid="25"> <value>9450</value> </distribution>

32 16 KAPITOLA 3. XML PROTOKOL PRO SPRÁVU SÍT

33 Kapitola 4 Implementované projekty 4.1 Java manager a brána Teoretický návrh XML protokolu a XML-SNMP brány bylo nutné prakticky ov it. To bylo cílem práce Michala Tre²a. V rámci své diplomové práce implementoval prototyp agenta(xml- SNMP brány) a jednoduchého managera pro navrhovaný protokol. Pro implementaci zvolil programovací jazyk Java, p esn ji platformu J2SE 1.5. Sou ástí návrhu bylo i uºivatelské (webové) rozhraní zaloºené na servletech. Z asových d vod bylo nakonec implementováno ovládání jen pomocí administra ní konzole. Pro ukládání dat bylo zvoleno ukládání do souborového systému. Obrázek 4.1: Schéma prototypové brány ([27]) 17

34 18 KAPITOLA 4. IMPLEMENTOVANÉ PROJEKTY Informa ní model Informa ní model implementované brány se drºí princip popsaných v kapitole 3. Oproti p vodnímu návrhu ale bylo provedeno n kolik zm n. P edev²ím XSD schéma neumoº uje do jednoho souboru vkládát denice z více jmenných prostor. To pon kud komplikuje vytvo ení jednoho XSD schématu popisujícího celou bránu, pokud její popis tvo í více MIB soubor. esením se ukázalo p ekládát více MIB do jednoho schématu se spole ným jmenným prostorem. Jeho jmého je ur eno z jmen jednotlivých MIB. Pro dotazování nad XML reprezentací brány má být pouºívám jazyk XPath. Ten ale pracuje s prohledávaným dokumentem jako s b ºným XML, tedy není schopen pracovat p ímo s XSD schématem brány. Z toho d vodu brána ze schémat generuje instance XML dokument a dotazování provádí nad nimi. Z t chto d vod tedy probíhá p eklad MIB do XML ve dvou fázích. V první je MIB dokument(y) p eloºen do XSD schématu a ve druhé je z n j vygenerována XML instance. P i p ekladu je MIB z dokumentu pomocí knihovny Mibble vytvo ena stromová struktura. Na ní pak jsou rekurzivn od ko ene aplikována transforma ní pravidla. Výsledkem jsou dv XSD schémata. Jedno obsahující stromovou reprezentaci MIB a druhé denice typ. Generování XML instance pak probíhá velmi podobn. Je tedy budována rekurzivním pr chodem stromu XSD schématu. P i tomto postupu je MIB objekt mapován na element XML dokumentu. Jeho atributy, v XSD schématu reprezentované jako elementy, jsou ukládány jako atributy element. Výsledný dokument tedy není proti svému schématu validní. To ale nep edstavuje problém, protoºe XPath adresace bude probíhat jen pomocí názv element a ne jejich atribut Komunika ní model Ob strany komunikace (brána i manager) musí být, bez ohledu na konkrétní implementaci, schopny dvou základních komunika ních úkon. Prvním je odesílání zpráv. V p ípad brány se jedná o zprávy EVENT a v p ípad managera o zprávy DISCOVERY, GET, SET a SUB- SCRIBE. Speciální p ípad pak p edstavují zprávy DISTRIBUTION. Druhým komunika ním úkonem je p íjem zpráv. Manager odesílá zprávy DISCOVERY, GET, SET a SUBCRIBE. Brána pak zprávy EVENT a DISTRIBUTION. Komunikace probíhá pomocí protokolu HTTP na principu vým ny ºádostí (request) a odpov dí (response). Strana p ijímající zprávy se v n m nazývá HTTP server. Ten je v práci realizován jako vloºený (embedded) pomocí knihovnycom.sun.net.httpserver. Aby se zabránilo jeho zahlcení p ijímanými zprávami implementoval Bc. Tre²o v brán systém p ijímacích front. Kaºdá zpráva(http request) je p ijata serverem a p edána do pracovní fronty. Pokud je fronta plná, zpráva není p ijata a komunice je ukon ena. Z fronty jsou poºadavky vybírány ve stejném po adí v jakém dorazily. U poºadavku jsou nejprve ov ena p ístupová práva. Pokud má uºivatel právo operaci provézt je po adavek za azen podle priority do jedné z front k provedení. Po provedení je vygenerována odpov a zaslána managerovi jako HTTP response. Pro odesílání zpráv EVENT a DISTRIBUTION pouºívá brána podobný systém. V p ípad zpráv EVENT modul brány p ijímá zprávy TRAP SNMP protokolu. Po obdrºení takové zprávy vytvo í objekt a za adí ho do pracovní fronty. Ta plní stejný ú el jako fronta

35 4.2. XML-SNMP BRÁNA V C++ 19 p ijímaných zpráv - tedy zabránit zahlcení brány. Objekty jsou z fronty vybrány, dopln ny o data z informa ního modelu a za azeny do odesílací fronty. Z ní je vybírá HTTP klient a odesílá manager m. U zpráv DISTRIBUTION se postupuje stejn. Jen jejich objekty nejsou generovány p íjmem SNMP zprávy, ale asova em v infroma ním modelu. Ten je nastaven p i zpracování zprávy SUBSCRIBE Zhodnocení Tato implementace úsp ²n ov ila pouºitelnost navrºeného protokolu. Jako prototyp ale má ur ité nedostatky. Implementace managera poskytuje jen velmi základní funkce (odesílání a p íjem p íkaz ). Ovládání pomocí administra ní konzole také není zcela uspokojivé. Uº autor zmi uje, ºe pouºití jazyka Java pro implementaci XML-SNMP brány není zcela ² astné. P edpokládá se, ºe roli brány mohou plnit i relativn jednoduchá za ízení (nap. router). Základním poºadavkem na takovou bránu tedy je pokud moºno co nejmen²í náro nost na systémové prost edky. Jazyk Java není z tohoto hlediska p íli² vhodný. V Jav napsaná aplikace také k fungování vyºaduje Java Virtual Machine (JVM), respektive Java Runtime Enviroment (JRE). Na takto jednoduchém za ízení nemusí být jejich provoz moºný. 4.2 XML-SNMP brána v C++ S v domím t chto nedostatk p istoupil k implementaci XML-SNMP brány Tomá² Hroch. Pro implementaci brány pouºil jazyk C++ a v noval pozornost omezení náro nosti na systémové prost edky. Protoºe mnoho (i jednoduchých) sí ových za ízení pouºívá opera ní systém LINUX je tato volba velmi vhodná. P i zvládnutí náro n j²í implementace je aplikace napsaná v C++ mén náro ná na zdroje, neº pokud by byla napsaná v Jav. Také s jejím provozem na opera ním systému LINUX je velmi málo komplikací. Po volb této implementa ní platformy se ukázalo jako logické bránu strukturovat jako démona. Za cenu hor²í p enositelnosti a platformové nezávisloti se tak povedlo dosáhnout rychlé reak ní doby. Brána byla navrºena tak, aby podporovala verze protokolu SNMPv1 a SNMPv2c v etn modelu zabezpe ení. Aby se usnadnilo pozd j²í roz²í ení, byla brána navrºena jako modulární systém. V rámci implementace tedy musel být navrºen SNMP modul, XML modul a zp sob propojení obou modul. Oba moduly jsou popsány dále v této kapitole. Komunikace mezi nimi probíhá pomocí zasílání poºadavk. Aby se zabránilo zahlcení modul jsou jejich vstupy a výstupy e²eny jako fronty. B h programu brány probíhá podobn jako v p edchozí implementaci. Brána nejprve na te kongura ní soubor. V n m jsou uloºeny informace o spravovaných za ízeních a konguraci samotné brány. Popis kaºdého za ízení obsahuje adresu za ízení a seznam jeho MIB. B hem inicializace SNMP modul ov í, ºe je za ízení popsané v kongura ním souboru aktivní. V dal²ím kroku je provedena transformace dat z kongura ního souboru a odkazovaných MIB do XML. Pro kaºdé za ízení a pro samotnou bránu je vygenerován samostatný XML dokument. Tato úprava si vyºádala zm nu komunika ního protokolu, p esn ji zprávy DISCOVERY. Brána na první zprávu tohoto typu zareaguje odesláním jen svého popisu (v etn seznamu p ipojených za ízení). Schémata konkrétních zaºízení si pak manager vyºádá dal²ími zprávami pomocí atributu objectid. V posledním kroku pln ini-

36 20 KAPITOLA 4. IMPLEMENTOVANÉ PROJEKTY Obrázek 4.2: Schéma C++ brány ([20]) cializovaná brána p ijímá poºadavky manager, p ekládá je do protokolu SNMP a vrací výsledky SNMP modul Obrázek 4.3: Vlákna a fronty SNMP modulu ([20]) I tento modul vyuºívá systému front. Pro kaºdé pod ízené za ízení je v modulu vyhrazeno obsluºné vlákno a fronta zpráv. Pro komunikaci v SNMP protokolu pouºívá modul knihovnu net-snmp. Kaºdé obsluºné vlákno vykonává v nekone ném cyklu n kolik díl ích úkon. Nejprve zjistí jestli nemá ve své front n jaký poºadavek. Pokud ne, tak se uspí. Pokud ano, tak vyjme v²echny poºadavky a zpracuje je. Poºadavky na nastavení, nebo zji²t ní hodnoty

37 4.2. XML-SNMP BRÁNA V C++ 21 koncovéhu uzlu jsou provedeny jako Set, nebo Get p íkazy SNMP. Pokud není cílem koncový uzel, je poºadavek proveden jako série p íkaz GetNextRequest protokolu SNMP. Po získání v²ech dat je vytvo ena odpov pro XML modul XML modul XML modul aplikace se stará o p eklad MIB do XML a o zpracovávání zpráv XML protokolu. P eklad MIB do XSD schématu probíhá i v této práci pomocí rekurzivního sestupu MIB stromem a aplikaci p ekladových pravidel. Kaºdému uzlu je p i azeno identika ní íslo (OID), datový typ a p ístupová práva. Uzel je pak za azen na své místo ve stromové struktu e XSD schématu. Paraleln s tímto schématem je vytvá ena i jeho XML instance na provád ní dotaz. Pokud je poºadavek sm rován na centrální uzel. Pro zpracování kaºdého p íchozího poºadavku se pouºívá samostatné vlákno. To nejprve ov í, ºe je p ijatá zpráva typu POST. Pokud není, pak je odeslána chybová odpov a ukon eno spojení. Jinak je pomocí XML parseru ov eno, ºe zpráva má správný formát. Kdyº je v²e v po ádku, je vytvo en poºadavek a za azen do vstupní fronty SNMP modulu. V p ípad zpráv typu SUBSCRIBE je je²t tato operace zaznamenána v XML dokumentu brány. XML modul se pak stará a pravidelné zasílání poºadavku SNMP modulu a zaslání hodnoty managerovi. Vlákno po odeslání poºadavku kontroluje frontu odpov dí XML modulu a eká aº SNMP modul ºádost zpracuje. Po doru ení výsled je sestavena a odeslána odpov. I v této práci musela být vy e²ena otázka volby HTTP serveru. Podobn jako práci Bc. Tre²a se ukázalo vhodn j²í pouºít vloºený (embedded) server, tentokáte z knihovny libmicrohttpd Zhodnocení Poºadované funkce tato brána plní dob e. Protoºe spl uje i poºadavek malé náro nosti, je vhodné jí pouºít p i dal²í práci na projektu. P i implementaci managera (viz. dále v této práci) se objevilo n kolik drobných nedostatk. Ale jejich oprava byla velmi snadná. V t²ina z nich navíc byla zp sobena nedokumentovanými vlastnostmi pouºitých knihoven.

38 22 KAPITOLA 4. IMPLEMENTOVANÉ PROJEKTY

39 Kapitola 5 Výsledky výzkumu P vodní práce Petera Macejka obsahovala shrnutí výsledk podobných výzkumných projekt. Protoºe od jejího sepsání ub hlo jiº nekolik let je na míst pokusit se o podobné srovnání znovu. P i hledání podklad pro tuto kapitolu bylo prvním cílem zjistit aktuální stav projekt uvedených v práci Petera Macejka. Dal²í postup pak sm oval k nalezení jiných, p vodn neuvedených, prací a v porovnání jejich výsledk s navrhovaným protokolem a aplikacemi. Hledání dal²ích výsledk p vodn uvedených projekt se neukázalo jako p íli² úsp ²né. N které projekty se uº nepovedlo v bec najít. U jiných se povedlo najít dal²í publikované výsledky, ale jejich zhodnocení je obtíºné z jazykových d vod, nebo pro chyb jící datum publikace. P es tyto problémy se povedlo najít n kolik zajímavých publikací. 5.1 TU Braunsweig Práce výzkumné skupiny F. Strausse z Technische Universität Braunschweig je zmi ována uº v práci Petera Macejka. Ta publikovala v období n kolik lánk na téma vyu- ºití XML a SMNP. Podle webových stránek[17] byl projekt aktivní aº do roku Zjistit detailní informace je ale sloºité. Webová prezentace obsahuje jen základní uºivatelské informace ve form manuálových stránek. Podrobnosti jsou s nejv t²í pravd podobností obsaºeny v jednotlivých studentských pracích. Ty se ale nejsou k dispozici. I v p ípad, ºe by se je povedlo získat, by bylo zpracování n mecky psaných technických text pro autora této práce p inejmen²ím obtíºné. 5.2 POSTECH Výzkum provedený na universit v Pohangu v Jiºní Korei je také citován v p vodní práci ing. Macejka. Vyuºití a nalezení dal²ích výsledk velmi komplikuje tém neexistující datování t chto prací. P esto je vhodné zmínit lánek An Embedded Web Server Architecture for XML-Based Network Management[19] z roku V sí ových prvcích se stále ast ji objevují vestav né (embedded) webové servery. Tento trend sice v mnoha sm rech usnadnil konguraci jednotlivých za ízení, ale zatím nep inesl ºádné zlep²ení v oblasti centralizované správy. Kolektiv autor zde navrhuje zlep²ení práv v této oblasti. Navrhovaný postup se v mnoha sm rech podobá námi navrhovanému e²ení. Tedy pouºít p es HTTP p ená²ené 23

40 24 KAPITOLA 5. VÝSLEDKY VÝZKUMU XML zprávy pro komunikaci mezi agenty a managery. Agenti pak slouºí jako protokolové brány mezi XML protokolem a jinými protokoly - nap. SNMP. Roli agent mají plnit práv zmi ované vestav né webové servery. Struktura takového agenta je na obrázku 5.1. Agent si udrºuje DOM objekt reprezentující spravovaná za ízení a data. Nad ním pak provádí XPath dotazy zaslané managerem. Toto e²ení ale není jediné moºné. V dal²ím láku[28] je analyzováno n kolik moºností, jak realizovat p eklad XML protkolu na SNMP. Popisované moºnosti jsou: P eklad na úrovni Managera: Manager udrºuje DOM odpovídající MIB stromu zpravovaných za ízení. Dotaz na list DOM stromu je p eloºen na SNMP p íkaz a odesán SNMP agentovi. P eklad na úrovni Klienta: Manager odesílá HTTP request s XPath, nebo XQuery jako parametry. Agent si udrºuje DOM a dotazy na jeho listy p ekládá na SNMP dotazy. Hlavním rozdílem je tedy p esun DOM stromu a souvisejících funkcí z managera do agenta. Pouºití SOAP: Princip fungování je stejný jako v p edchozím p ípad. Jen XPath/XQuery dotaz není posílán v URI, ale proveden jako volání vzdálené funkce pomocí SOAP. Obrázek 5.1: Struktura POSTECH agenta ([19]) Oba lánky obsahují mnoho podn tných my²lenek, ale nejsou bez nedostatk. V návrhu není kladen ºádný d raz na omezené HW prost edky sí ových prvk. P edev²ím pam ov náro ný DOM m ºe být nad jejich moºnosti. 5.3 Web services for network management Práce[25] Bernarda Thurma z university v Karlsruhe nabízí mnoho poznatk o realizaci skute n distribuovaného systému správy sít. Základní my²lenkou je rozd lení funkcí správy

41 5.4. ƒínský VÝZKUM 25 na logické celky a ty realizovat jako samostatné moduly. Kaºdý modul pak poskytuje své funkce jako sluºby pomocí XML a SOAP. Podle úkol je systém rozd len na ty i vrstvy. Celá struktura systému je na obrázku 5.2. Nejvy²²í vrstvou jsou r zná uºivatelská rozhraní tlustý klient, webová aplikace, nebo klient do mobilního telefonu. O úrove níºe jsou moduly infrastrukturních sluºeb. Ty fungující jako adapta ní vrstva mezi klienty a vrstvou managerských sluºeb. Na této vrstn se také nacházejí moduly spravující politiky a "submoduly". Vrstvu managerských slouºeb pak tvo í moduly starající se o samotné vykonávání úkon správy. Protoºe modul se spravovanými za ízeními komunikuje p ímo, tak musí obsahovat submoduly starajících se o p eklad p íkaz do formátu srozumitelného pro cílové za ízení. Práv pro centralizovanou správu takových p ekladových modul slouºí repozitá modul ve vrstv infrastrukturních sluºeb. Obrázek 5.2: Architektura systému ([25]) Velkou výhodou této práce je, jak promy²lený návrh, tak existence pokusné implementace pro správu MPLS (Multiprotocol Label Switching) sítí. Za nedostatky lze povaºovat snad jen nedostate né zd vodn ní pouºitých technologií a chyb jící moºnost vytvá ení víceúrov ové struktury managementu. 5.4 ƒínský výzkum Problematikou uplatn ní XML v managementu po íta ových sítí se zabývá i n kolik ƒínských v dc. Publikované práce ale v t²inou neposkytují mnoho informací. Anglicky psaný text je velmi ²patn srozumitelný. V citacích uvedené práce v t²inou nejde mimo ƒínu sehnat. V pozitivním smyslu lze zmínit práci od Meijuan Wei, Debao Xiao a Jintao Guo [15].

42 26 KAPITOLA 5. VÝSLEDKY VÝZKUMU Tato práce nabízí n kolik zajímavých podn t. P edev²ím zmi uje problematiku hierarchie manager a s tím souvisejících poºadavk na výstupy(sledování trend ). Také se zabýva bezpe ností a konzistencí vzhledem k existenci n kolika rozhraní na koncových za ízeních (SNMP, Web, telnet). Zajímavý je d raz na správu zaloºenou na formulování politik. Struktura navrhovaného systému je na obrázku 5.3. Obrázek 5.3: Architektura systému ([15]) Jednotlivé prvky mají tyto funkce: Manager, GUI ƒást p edstavující prezentaci stavu systému pro uºivatele, nebo managerskou aplikaci vy²²í úrovn. Management Server Manaºer poskytjící webové rozhraní pro uºivatele a rozhraní pro nad azené managerské aplikace. Independent Management Entity Agent starající se o vykonávání p íkaz a vynucování ur ené politiky na pod ízených za ízeních. Sou ástí lánku je i popis experimentální implementace. V n m ale chybí, nebo je z textu nejasné, vysv tlení funkcí a vlastností n kterých základních prvk. Za mén poda ený lze ozna it lánek od Wenli Dong[16]. V lánku jsou o navrhované aplikaci jen základní informace a práce uvedené v referencích není moºné najít. V podstat

43 5.5. XMLN OVER VOIP 27 jde celý lánek shrnout do jedné v ty: "Pomocí mapování MIB do XML lze vytvo it systém pro správu sít ". 5.5 XMLN over VoIP Tato práce[24] pochází ze soukromého sektoru. Popisuje po áte ní fáze implementace na XML zaloºeného protokolu pro správu sít. Zmínka o Voice Over IP (VoIP) v názvu souvisí s hlavním oborem innosti rmy Qovia. V popisu e²ení nemá ºádné uplatn ní. Protoºe se jedná o po áte ní implementaci, bez rozsáhlé analýzy, má projekt mnoho závaºných nedostatk. I kdyº pouºívá XML, tak nevyuºívá moºnosti vytvá et strukturované dokumenty. MIB není do XML mapováno jako strom, ale jen jako mapa klí MIB kód. Struktura XML zpráv mezi agenty a managery je také p íli² jednoduchá. Obsahuje jen páry klí hodnota. Pokud manager zji² uje stejné informace od více za ízení, není pak moºné poznat, od koho odpov p i²la. 5.6 Zhodnocení Ve v t²in prostudovaných lánk se na realizaci navrhuje pouºití technologií odvozených od jazyka Java. Je na míst otázka jestli se jedná o optimální e²ení. U manager se dá o ekávat d raz na budování hierarchické struktury a pot ebu sloºitých výstup. Sou asn se dá p edpokládat dostate n výkonný HW. Pro managery je tedy pouºití Javy, aplika ních server a JSP logické a vhodné. U agent uº to tak jednozna né není. Agent musí fungovat s výrazn mén zdroji. Proto je pouºití mén náro ného C++ výhodn j²í. Je ale také pot eba zváºit, jestli je vhodné vytvá et a udrºovat dva zdrojové kódy ve dvou jazycích. Opakovan je jako hlavní nedostatek SNMP uvád na jen dvouúrov ová struktura agentmanager. Nalezené lánky tuto problematiku ale tém ne e²í. Bylo by tedy na míst jí v novat pozornost. Pozornost by také bylo vhodné v novat zaji²t ní bezpe nosti a konzistence v XMLBNM. Zhodnocení vhodnosti pouºitých technologií a návrhu vlastností navrhovaného systému se v nuje následující kapitola.

44 28 KAPITOLA 5. VÝSLEDKY VÝZKUMU

45 Kapitola 6 Návrh systému 6.1 Stav projektu Ob p edchozí implementa ní práce se zam ily na ov ení konceptu XML/SNMP brány. První zkoumala, jestli je v bec moºné takovou bránu napsat. Druhá se snaºila je²t splnit striktní poºadavky na malou náro nost na systémové prost edky. V C++ provedená brána od Bc. Hrocha tyto poºadavky zcela splnila. Ob práce ale obsahují jen velmi základní implementaci managera, vhodnou jen na ov ení základních funkcí brány. Pro dal²í vývoj projektu je tedy nutné navrhnout serverovou/managerskou aplikaci. Tak bude dokon ena pilotní implementace projektu pouºití XML p i správ po íta ových sítí. V del²ím horizontu by pak managerská aplikace mohla poslouºit jako odrazový m stek pro napojení na dal²í systémy vy²²í úrovn. Tím by se m lo poda it splnit poºadavek na vytvo ení víceúrov ového systému pro správu a dohled na po íta ové sít. Tento poºadavek je uvedený jak v p vodní specikaci protokolu, tak opakovan zmi ovaný v publikovaných v deckých láncích. 6.2 Managerská aplikace Hlavním úkolem managerské aplikace je spravovat a dohlíºet na za ízení s pomocí XML/SNMP brány. Aby mohla plnit tento úkol musí navrhovaná aplikace poskytovat tyto funkce: P ipojit se k XML/SNMP brán. Brána odpoví seznamem sledovaných za ízení a jejich parametr. Tedy dojde k vým n zpráv DISCOVERY a PUBLICATION. Ze získaného seznamu jde vybrat n jaký parametr a je moºné zjistit, nebo nastavit jeho hodnotu. To odpovídá vým n zpráv typu GET/SET a RESPONSE. P jde vytvo it dohledovou operaci. Vybere se parametr, který se má sledovat. Ur í se frekvence sledování a nastaví horní a dolní meze hodnot. Po úsp ²né vým n zpráv SUBSCRIBE a DISTRIBUTION se check za adí do dohledového systému. Dohledový systém poskytuje informace o stavu sledovaných za ízení a upozor uje ho na p ekro ení nastavených parametr. Aplikaci musí být moºné snadno a p ehledn ovládat. 29

46 30 KAPITOLA 6. NÁVRH SYSTÉMU Krom vý²e uvedených poºadavk je poºadována je²t jedna vlastnost. Je to maximální modularita. Ú elem je umoºnit dal²í rozvoj managerské aplikace prostým nahrazením n jakého modulu a také moºnost pouºít samostatný modul jako knihovnu v dal²ím projektu. Pomocí vý²e uvedených poºadavk si aplikaci m ºeme rozd lit do ty základních modul : komunika ní dohledový uºivatelský kongura ní Dále je uvedena jejich detailn j²í specikace, alternativy e²ení a zd vodn ní volby implementa ní platformy Programovací jazyk Prvním krokem je volba vhodného programovacího jazyka. Nabízejí se dv moºnosti. Bu pouºít jazyk C++, pak bude moºné vyjít z uº existujícího kódu XML/SNMP brány a dosáhnout dobré úrovn sjednocení kódu. Nebo pouºít jazyk Java. Pro C++ hovo í men²í nároky na systémové prost edky. Nevýhodou jsou vy²²í nároky na programátora a s tím související vy²²í pravd podobnost výskytu chyb. Vzhledem k p edpokládanému navázání managerské aplikace na programy vy²²í úrovn (nap íklad informa ní systém) je vhodné zmínit snadné vyuºívání technologií, jako jsou webové sluºby, nebo vzdálené volání funkcí v Jav. Protoºe hlavní poºadavek na XML/SNMP bránu malé nároky na systém není u managera nutné uplat ovat tak striktn a sou asn se v Jav snadno integrují dal²ích technologie jeví se tento jazyk jako vhodn j²í. To ale neznamená, ºe je moºné se úpln vzdát snahy o minimalizaci náro nosti aplikace. V n kolika podobných výzkumných projektech se auto i p i volb technologií spoléhají na zbyte n náro né a robustní technologie, jmenovit Javu Enterprise Edition. Tato volba není asto ani nijak zd vodn na. Vzhledem k plánovanému rozsahu aplikace je dostate né pouºít technologii Java SE (p esn ji Java SE 1.6). Sou ástí poºadavk na managerskou aplikaci je i p ehledné uºivatelské rozhraní. Java SE obsahuje nástroje pro tvorbu jak b ºných, tak webových, uºivatelských rozhraní. Jako nástroj pro vytvá ení webových rozhraní nabízí technologii Java Server Pages (JSP). Aby tuto technologii bylo moºné pouºít, je pot eba do poºadavk aplikace za adit funk ní instalaci vhodného servlet kontejneru (nap íklad Apache Tomcat 6.0). Náro nost takového kontejneru je ale výrazn men²í, neº kompletního aplika ního serveru, jako je Sun Glasssh Komunika ní modul Ú elem tohoto modulu je zaji² ování komunikace pomocí navrºeného XML protokolu. Na jedné stran musí modul obsahovat rozhraní pro odesílání a p íjem zpráv a na druhé rozhraní pro komunikaci se zbytkem aplikace. Aby modul dokázal správn komunikovat s XML/SNMP bránou musí ovládat tyto komunika ní funkce navrºeného protokolu:

47 6.2. MANAGERSKÁ APLIKACE 31 vytvá ení a odesílání zpráv DISCOVERY, p íjem odpov dí PUBLICATION vytvá ení a odesílání zpráv GET, SET, p íjem odpov dí RESPONSE p íjem zpráv EVENT vytvá ení a odesílání zpráv SUBSCRIBE, p íjem zpráv DISTRIBUTION Ze strany zbytku aplikace je nejvhodn j²í ovládání modulu e²it jako volání funkcí. Aby se zabránilo zahlcení aplikace p ijímanými zprávami bude pot eba vytvo it mechanizmus front zpráv v obou sm rech komunikace. Podle navrºeného protokolu probíhá komunikace pomocí HTTP, respektive HTTPS. Ten vyuºívá principu vým n ºádost-odpov (request-response). Strana zahajující komunikaci se nazývá HTTP klient a strana p ijímající ºádosti HTTP server. Do návrhu komunika ního modulu je tedy pot eba za adit i zp sob realizace HTTP klienta a serveru. Nabízejí se t i moºná e²ení: naprogramovat vlastní http/https server a klienta vyuºít server a klienta z existující knihovny pouºít API http serveru pracujícího mimo aplikaci. Vzhledem k tomu, ºe provád ná HTTP komunikace není nijak sloºitá, mohlo by se první e²ení jevit jako nejhospodárn j²í. P i bliº²ím pohledu se ale ukáºe, ºe to tak není. P edev²ím se ani od serveru, ani od klienta neo ekávají jiné, neº naprosto standartní vlastnosti. Není proto d vod nepouºít n jakou uº existující implementaci. Pro tuto moºnost hovo í problematika zabezpe ení protokolu. V sou asné implementaci není komunikace nijak zabezpe ena. Specikace XML protokolu ale hovo í o moºnosti komunikaci ²ifrovat. P i pouºití vlastní implementace HTTP serveru, nebo klienta by se i taková funk nost musela programovat. Naopak vhodn zvolená knihovna uº v sob pot ebnou funk nost bude obsahovat. Proti poslední moºnosti hovo í poºadavek na modularitu aplikace. Pouºití externího HTTP serveru by omezilo moºnosti samostatného pouºití tohoto modulu. HTTP server a klient budou tedy v aplikaci e²eny pomocí existujících knihovních implementací. P i volb konkrétních knihoven je na míst uplatit zku²enosti z prototypové implementace. Jako server bude pouºíta implementaci z balíku com.sun.net.httpserver [6]. I p es svou jednoduchost tato volba pln spl uje poºadavky na funk nost. Volba vhodného klieta je o n co sloºit j²í. Nabízí se moºnost pouºít t íd z balíku Java.net [5]. Výhodou je, ºe je b ºnou sou ástí Javy. P idání funkcí souvisejících se zabezpe ením komunikace protokolem HTTPS by bylo ale v budoucnu sloºit j²í. Výhodn j²í tedy bude pouºít knihovnu HTTP Client [1] od Apache Software Foundation. Jedná se o robustní a sou asn snadno ovladatelnou knihovnu s mnoha uºite nými vlastnostmi Dohledový modul Uº název by m l nazna ovat, ºe tento modul je jádrem navrhované aplikace. Plní roli prost edníka mezi uºivatelskou, komunika ní a kongura ní ástí aplikace. Sou asn se musí starat o fungování dohledových operací. Jeho funkce se dají shrnout do t í axiom :

48 32 KAPITOLA 6. NÁVRH SYSTÉMU na základ vstup z komunika ního modulu upravovat informace prezentované v uºivatelském modulu podle vstup z uºivatelského modulu volat operace v komunika ním modulu. Udrºovat informace o spravovaných za ízeních a o provád ných dohledových operacích. Sou ástí modulu musí být i mechanizmy pro informování uºivatele o nestandardních událostech na sledovaných za ízeních. M ºe se jednat bu o asynchronní události typu EVENT, nebo o p ekro ení stanovených limit u dohledové operace. Moºností jak takové upozorn ní provést je více. Základem je zobrazení takové informace v uºivatelském modulu, ale nabízejí se i dal²í moºnosti nap íklad odeslání upozorn ní em Uºivatelský modul Tento modul zprost edkovává komunikaci mezi uºivatelem a zbytkem aplikace. Moºností jak toto zajistit je mnoho. P edchozí implementace managera se spokojily s pouºitím p íkazové ádky. To je implementa n nejjednodu²²í, ale uºivatelsky nejmén pohodlné e²ení. V rámci této implementace by m lo být pouºito n jaké pohodln j²í e²ení. Jako nejvhodn j²í se jeví ovládaní aplikace pomocí webového rozhraní. To nabízí podobný komfort jako gra- cké rozhraní a sou asn umoº uje k aplikaci p istupovat z jakéhokoliv po íta e vybaveného webovým prohlíºe em. Jak uº bylo zmín no v ásti v nované volb programovacího jazyka, nabízí Java pro tvorbu webových rozhraní/aplikací technologii JSP. Ta je postavena na principech návrhového vzoru Model-View-Controller (MVC). Roli Modelu, tedy objektu obsahujícího n jaká data, plní tzv. Beany. Ty jsou implementovány jako t ídy v jazyku Java. V JSP se jim nastavuje rámec (scope), který ur uje jejich ºivotnost. Moºností je více, ale na tomto míst posta í zmínit moºnosti "application"a "session". P i rámci application existuje bean po celou dobu b hu aplikace. P i volb session pak po dobu trvání sezení uºivatele. View ur uje zp sob, jakým jsou data z model reprezentována v uºivatelském rozhraní. V JSP k tomu slouºí JSP stránky, podle kterých je tato technologie pojmenována. JSP stránka pouºívá syntaxi jazyka HTML dopln nou o vlastní sadu zna ek (tag ). Umoº uje také denovat nové zna ky. P i prvním p ístupu na stránku jí servletový kontejner p eloºí na servlet. Ten podle pravidel generuje HTML stránky zobrazené uºivatel m. Servlet je druhem t ídy v jazyce Java, která roz²i uje funkce serveru a vyuºívá model ºádost-odpov. Servlety bývají také popisovány jako applety b ºící na serveru a ne v prohlíºe i uºivatele. Jejich pouºití p i p ekladu JSP stránek je ale pro uºivatele i programátora vícemén skryté. Mnohem viditeln j²í je jejich uplatn ní p i realizaci poslední ásti návrhového vzoru MVC, tedy Controller. Ty zpracovávájí vstupy od uºivatele a podle nich upraví data v modelech a aktualizují View. Je velmi zajímavé, ºe naprostá v t²ina na internetu dostupných materiál se vý²e popsaných princip nedrºí. P edev²ím vytvá ejí dojem, ºe správné pouºití JSP a p edev²ím servlet spo ívá v generování HTML stránek. Tento p ístup poru²uje celou sérii paradigmat o odd lení obsahu od jeho prezentace. Sou asn se velmi málo zdroj zabývá problematikou nad rámec naprostých základ.

49 6.2. MANAGERSKÁ APLIKACE Kongura ní modul Aby mohly moduly managerské aplikace plnit poºadované úkoly budu si muset dokázat ukládat nezanedbatelné mnoºství informací. Uº v této fázi návrhu je jasné, ºe se bude jednat minimáln o: vlastní kongurace komunika ní porty a adresy kongura ní informace aplikace informace o sledovaných XML/SNMP branách adresy a porty p ihla²ovací údaje sledovaná za ízení probíhající dohledové operace Kdyº vynecháme primitivní a sou asn nepraktickou moºnost pevného nastavení výchozích hodnot ve zdrojovém kódu programu, nabízejí se tyto moºnosti: ukládat informace do soubor ve vlastním formátu ukládat do soubor ve standardním formátu nap íklad XML, nebo Property jazyku Java pouºít plnohodnotnou databázi Komunika ní protokol pouºívá dokumenty ve formátu XML a s tímto formátem bude muset pracovat velká ást navrhované aplikace. Pouºít na ukládání kongura ních dat XML dokumenty je pak jen dal²ím pouºitím uº jednou vyzkou²ených postup. Pouºití databáze by jen uvalilo dal²í poºadavek na provoz aplikace a p i navrhovaném rozsahu nep ineslo ºádnou výraznou výhodu. Kongurace aplikace a informace o p ipojených XML-SNMP branách tedy bude ukládána do XML dokument na pevný disk.

50 34 KAPITOLA 6. NÁVRH SYSTÉMU

51 Kapitola 7 Realizace V této kapitole je popsána implementace managerské aplikace. Nejprve je vysv tlena struktura aplikace a popsány její moduly. U kaºdého modulu je uvedena jeho struktura, popis d leºitých t íd a jejich vztah. Také je uvedeno, jaké knihovny modul vyuºívá. V dal²í ásti jsou vysv tleny nutné zm ny v kódu XML-SNMP brány. V poslední ásti je popsán výkonný cyklus aplikace od spu²t ní, p es provád ní p íkaz aº po ukon ení. Schéma aplikace s p íkladem volání pro operaci SUBSCRIBE je na obrázku 7.1. Obrázek 7.1: Schéma aplikace 7.1 Struktura aplikace Podle návrhu v kapitole 6 má být aplikace ovládána pomocí webového rozhraní vyuºívajícího JSP. Sou asn má být ale maximáln modulární. Tedy musí být funk ní i bez tohoto rozhraní, respektive bez závisloti na JSP. Aby byl spln n tento poºadavek, tvo í aplikaci dv ásti. Jednu je nejlep²í popsat jako "pracovní". Tvo í jí komunika ní a kongura ní modul, zast e²ené modulem dohledovým. Tato ást zabezpe uje samotnou funk nost aplikace. Tedy odesílání a p íjem zpráv, ukládání a aktualizaci dat o p ipojených branách a základní aplika ní logiku. Druhou ást tvo í samotný uºivatelský modul. Jeho jedinou funkcí je prezentovat data uºivateli a poskytovat mu nástroje na ovládání aplikace. Z technického 35