Návrh a implementace monitoringu síťových linek na platformě MikroTik

Mendelova univerzita v Brně Provozně ekonomická fakulta

Návrh a implementace monitoringu síťových linek na platformě MikroTik Bakalářská práce

Vedoucí práce:

Jan Dvořan

Ing. Martin Pokorný, Ph.D.

Brno 2012

Chtěl bych poděkovat svému vedoucímu práce Ing. Martinu Pokornému, Ph.D. za poskytnutí možnosti vypracování této práce a za přínosné rady při jejím zpracování. Dále bych chtěl poděkovat svému okolí a své rodině za podporu při studiu a podporu při vypracování této práce.

Prohlašuji, že jsem tuto práci vytvořil samostatně a za použití citovaných zdrojů, které jsou uvedeny v seznamu literatury.

Brno 20.5.2012

................................................................

4

Abstract Citation of work in English This work contains proposal solution and implementation of monitoring speed network links for each costumers of ISP who are connected to the Internet using PPPoE to MikroTik router. This work contains summary of existing products and process of create a new Web application that monitors each costumers and provides ability to view graphs of network load for each costumer. Created application collects data by SNMP protocol from MikroTik router. Application use a RRD Tool to store collected data and generate graphs of load costumers network links.

Abstrakt Citace práce v českém jazyce Tato práce se zabývá návrhem řešení a následné implementaci monitoringu rychlosti využití pronajatých linek koncovými zákazníky poskytovatele internetu, kdy každý zákazník se připojuje k síti pomocí protokolu PPPoE k zařízení na platformě MikroTik. V této práci je uvedeno shrnutí stávajících produktů na trhu a postup při návrhu a vytvoření nové webové aplikace, která monitoruje jednotlivé klienty sítě a poskytuje jim možnost zobrazení grafu historie rychlosti jejich síťové linky. Vytvořená aplikace sbírá data pomocí protokolu SNMP ze zařízení MikroTik a následně využívá program RRD Tool pro uchování získaných dat a tvorbu grafů reprezentující historii využití pronajaté linky.

5

OBSAH

Obsah 1 Úvod a cíl práce 1.1 Úvod . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.2 Cíl práce . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

8 8 8

2 Analýza uživatelských požadavků

9

3 Popis technologického aparátu 3.1 Point-to-Point Protocol . . . . . . . . Komunikace protokolu PPP . . . . . Tvar rámce PPP . . . . . . . . . . . 3.2 PPPoE . . . . . . . . . . . . . . . . . PPPoE spojení . . . . . . . . . . . . Ethernetový rámec a PPPoE . . . . 3.3 SNMP . . . . . . . . . . . . . . . . . Verze SNMP . . . . . . . . . . . . . OID a MIB . . . . . . . . . . . . . . Typy SNMP zpráv . . . . . . . . . . SNMP datagram . . . . . . . . . . . 3.4 RRD Tool . . . . . . . . . . . . . . . Struktura RRD dat . . . . . . . . . . Tvorba RRD souborů a RRD Create Aktualizace RRD souborů . . . . . . Tvorba grafů v RRD . . . . . . . . . 3.5 CPAN Minus . . . . . . . . . . . . . Instalace a spuštění CPAN Minus . . 3.6 Net::SNMP . . . . . . . . . . . . . . Hlavní funkce Net::SNMP . . . . . . 3.7 CRON . . . . . . . . . . . . . . . . . 4 Přehled stávajících produktů 4.1 Nagios . . . . . . . . . . . . 4.2 Cacti . . . . . . . . . . . . . 4.3 MRTG . . . . . . . . . . . . 4.4 Mikrotik Graphing Tool . . 4.5 PRTG . . . . . . . . . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . . . . . . . . . . . . . . . . . .

. . . . .

. . . . . . . . . . . . . . . . . . . . .

. . . . .

. . . . . . . . . . . . . . . . . . . . .

. . . . .

. . . . . . . . . . . . . . . . . . . . .

. . . . .

. . . . . . . . . . . . . . . . . . . . .

. . . . .

. . . . . . . . . . . . . . . . . . . . .

. . . . .

. . . . . . . . . . . . . . . . . . . . .

. . . . .

. . . . . . . . . . . . . . . . . . . . .

. . . . .

. . . . . . . . . . . . . . . . . . . . .

. . . . .

. . . . . . . . . . . . . . . . . . . . .

. . . . .

. . . . . . . . . . . . . . . . . . . . .

. . . . .

. . . . . . . . . . . . . . . . . . . . .

. . . . .

. . . . . . . . . . . . . . . . . . . . .

. . . . .

. . . . . . . . . . . . . . . . . . . . .

. . . . .

. . . . . . . . . . . . . . . . . . . . .

. . . . .

. . . . . . . . . . . . . . . . . . . . .

. . . . .

. . . . . . . . . . . . . . . . . . . . .

. . . . .

. . . . . . . . . . . . . . . . . . . . .

10 10 10 10 11 11 12 13 14 15 16 16 17 18 18 20 21 22 22 23 23 24

. . . . .

25 25 27 29 30 30

6

OBSAH

5 Přehled stávajících prací 32 5.1 BP - Beno Slávik - Využití speciálního operačního systému MikroTik RouterOS v sítích lokálních ISP . . . . . . . . . . . . . . . . . . . . . 32 5.2 DP - Jindřich Matúšů - Monitorování stavu rozsáhlých sítí . . . . . . 33 5.3 DP - Pavel Míča - Monitorovací a dohledový systém počítačové sítě . 34 6 Návrh řešení 6.1 I. celek: Sběr dat ze zařízení MikroTik a tvorba RRD souborů . . . . SNMP komunikace . . . . . . . . . . . . . . . . . . . . . . . . . . . . Tvorba RRD souborů . . . . . . . . . . . . . . . . . . . . . . . . . . . 6.2 II. celek: Webová aplikace pro tvorbu a prezentaci grafů pro uživatele Autentizace uživatele . . . . . . . . . . . . . . . . . . . . . . . . . . . Tvorba a prezentace grafů pro přihlášeného uživatele . . . . . . . . . Tvorba a prezentace grafů pro administrátora sítě . . . . . . . . . . . 6.3 Správa nevyužívaných RRD souborů . . . . . . . . . . . . . . . . . .

35 36 36 37 37 37 38 38 38

7 Implementace řešení 7.1 Implementace sběru dat ze zařízení Mikrotik a tvorby RRD souborů Instalace komponent pro skript sběru dat a tvorby RRD souborů . SNMP komunikace se zařízením MikroTik . . . . . . . . . . . . . . Tvorba nových RRD souborů . . . . . . . . . . . . . . . . . . . . . Aktualizace RRD souborů . . . . . . . . . . . . . . . . . . . . . . . Aktualizace RRD souborů neaktivních uživatelů . . . . . . . . . . . Spuštění scriptu pomocí CRON . . . . . . . . . . . . . . . . . . . . 7.2 Implementace webové aplikace pro tvorbu a prezentaci grafů . . . . Instalace nutných balíčků . . . . . . . . . . . . . . . . . . . . . . . Autentizace uživatelů . . . . . . . . . . . . . . . . . . . . . . . . . . Tvorba grafů pro běžného uživatele . . . . . . . . . . . . . . . . . . Tvorba grafů pro správce sítě . . . . . . . . . . . . . . . . . . . . . Správa nevyužívaných RRD souborů . . . . . . . . . . . . . . . . .

39 39 40 40 43 45 46 47 47 47 47 49 50 50

. . . . . . . . . . . . .

8 Ověření implementace 52 8.1 Ověření uživatelských požadavků a funkčnosti řešení . . . . . . . . . 52 8.2 Oveření uživatelské použitelnosti . . . . . . . . . . . . . . . . . . . . 55 9 Ekonomické zhodnocení

56

OBSAH

7

10 Závěr práce

58

11 Literatura

59

Přílohy

62

A Postup instalace programu RRD Tool

63

B SNMP komunikace Skriptu pro sběr dat pro RRD soubory

64

C Tvorba a aktualizace RRD souborů

65

D Aktualizace RRD souborů neaktivních rozhraní

66

E Autentizace uživatele oproti AD ve webové aplikaci

67

F Tvorba grafů vytížení síťových linek

68

G Tvorba grafů vytížení síťových linek pro správce

70

H Správa nevyužívaných RRD souborů

72

I

Zobrazení postupu připojení uživatele a správce do webové aplikace 73

1

ÚVOD A CÍL PRÁCE

1 1.1

8

Úvod a cíl práce Úvod

Tato práce vznikla na základě požadavků společnosti poskytující internetové služby. Tato společnost při komunikaci se svými klienty identifikovala problém při argumentaci v reklamacích, týkající se rychlosti připojení k internetu. Problém nastával ve chvílích, kdy klient společnosti měl ve svém počítači nějaký škodlivý software, který využíval připojení k internetu. V této situaci se klient cítil omezen rychlostí připojení k síti internet a požadoval reklamaci jemu poskytovaných služeb. Tato práce slouží jako návrh a implementace sledování síťových linek jednotlivých uživatelů tak, aby v případě potřeby mohl klient shlédnout graf reálného vytížení své linky, a tím se předcházelo nepříjemnostem při komunikaci se zákazníky, či případných výjezdů techniků společnosti.

1.2

Cíl práce

Cílem této práce je navrhnout a implementovat webovou aplikaci pro správce sítě a koncové zákazníky společnosti poskytující internetové připojení na bázi MikroTik a PPPoE spojů, která bude prezentovat grafy vytížení linek jednotlivých zákazníků za účelem usnadnění komunikace se zákazníky v případech, kdy zákazník není spokojen s kvalitou poskytovaných služeb.

2

2

ANALÝZA UŽIVATELSKÝCH POŽADAVKŮ

9

Analýza uživatelských požadavků

Je potřeba vytvořit aplikaci sledující rychlost vytížení linky každého připojeného uživatele k síti. Toto připojení je vytvořeno pomocí PPPoE spojení na router, který je vytvořen na platformě Mikrotik. Dále se požaduje, aby každý uživatel sítě se mohl po připojení přihlásit do webové aplikace, ve které by shlédl grafy vytížení rychlosti, neboli vytížení šířky pásma své linky v několikati časových rozlišeních. Graf vytížení linky se bude skládat z osy X - času, kdy byl uživatel připojený k síti a osy Y rychlost vytížení linky v Mb/s, a to jak ve směru dat tekoucích od uživatele, tak i tekoucích k uživateli. Časové rozlišení grafu je potřeba zvolit takové, aby bylo jasně patrné, jak byla uživatelská linka v daném okamžiku zatížena. Je potřeba sledovat vytížení linek za poslední hodinu, poslední den, týden a měsíc. Dále se od aplikace čeká, že uživatel, který se připojí k webové aplikaci shlédne pouze grafy vytížení pro svoji linku a pro nikoho jiného. Dalším nárokem na webovou aplikaci je možnost využití i síťovým administrátorem, který bude mít možnost shlédnout grafy vytížení linek jednotlivých uživatelů sítě v závislosti na jeho výběru.

3

POPIS TECHNOLOGICKÉHO APARÁTU

3 3.1

10

Popis technologického aparátu Point-to-Point Protocol

Point-to-Point Protocol neboli PPP je definovaný v RCF 1661. Tento protokol se nachází na linkové vrstvě ISO-OSI modelu. Primárním účelem tohoto protokolu bylo dle Banzala (2007, s. 265) využití pro přenos dat na sériových linkách, jako je například vytáčené spojení dial-up nebo ISDN spojení. Právě díky těmto možnostem se stal poměrně oblíbeným mezi poskytovateli internetu. Dle Longa (2006, s. 196) protokol PPP vznikl jako náhrada protokolu HDLC, aby bylo možné zapouzdřit do přenášených dat nejen protokol TCP/IP, ale i další jako IPX, AppleTalk. V dnešní době se protokol PPP téměř nepoužívá, ale využívá se při přenosech PPPoE a PPPoA, neboli přenosech protokolu PPP přes ethernetové nebo ATM rámce. Komunikace protokolu PPP Dle dokumentu RFC 1661 Simpson (1994) můžeme protokol PPP rozdělit na dvě části. Na protokol LCP (Link Control Protocol), který se stará o provoz na druhé vrstvě ISO-OSI modelu, kde vytváří, testuje a udržuje spojení s druhou stanou linky a na protokol NCP (Network Control Protocol), který se stará o přenášení samotných datagramů a zapouzdření jednotlivých protokolů (IP,IPX) do rámců. Samotné vytváření komunikace není velmi složité. Ve chvíli, kdy je rozhraní v zapnutém stavu, protokol LCP dle Banzala (2007) začne komunikovat na lince a začne vyjednávat podmínky přenosu na vrstvě lince ISO-OSI modelu. Následně pomocí LCP protokolu se ověří, zda druhá strana linky je oprávněna komunikovat. Autentikační protokoly uvádí Kozierok (2005, s. 193). Po té, co je druhá strana ověřena, začne protokol NCP vyjednávat o podmínkách přenosu na třetí vrstvě. Například pokud je přenášen protokol IP, tak NCP začne přidělovat adresy jednotlivým stranám linky. Po dohodnutí nastavení na třetí vrstvě protokol NCP začne přenášet zapouzdřená data pro příslušný protokol. Velmi pěkně je tento proces dohodnutí podmínek PPP linky zpracován v Learning portal Juniper (2010). Velkou výhodou protokolu PPP je možnost přenášení více protokolů třetí vrstvy současně. Pomocí protokolu NCP je možno vytvořit více spojení na třetí vrstvě na jednom linkovém spojení. Tvar rámce PPP Protokol PPP vychází z protokolu HDLC a rovněž struktura rámce PPP je stejná. Níže můžeme vidět na obr. 1 vyobrazený PPP rámec. Jediné proměnlivé části

3.2

PPPoE

11

v tomto rámci jsou pole protokolu, informace a kontrolního součtu rámce. Ostatní hodnoty jsou vždy konstantní a nabývají hodnot vyobrazených na obrázku Rámce PPP.

Obrázek 1: Rámec PPP zdroj, převzato z Longa (2006, s. 193, obr. 6-3)

Pole adresa je vždy stejné, protože protokol PPP je vytvářen na dvoubodovém spojení. Pole protokol nabývá hodnot, které označují, zda rámec přenáší protokol LCP nebo NCP. Hodnotou protokolu je i určeno, jaký typ zprávy je přenášen v poli informací (zda jsou přenášena samotná data třetí vrstvy nebo protokol LCP teprve stanovuje spojení a podobně).

3.2

PPPoE

Protokol Point-to-Point over Ethernet zajišťuje zapouzdření PPP paketů do ethernetových rámců. Jedná se tedy o takzvané point-to-point spojení přes multiaccess médium. Jak uvádí Mansfield a Antonakos (2005) tento typ spojení je velmi často používaný poskytovateli internetu k připojení uživatelů sítě na bázi DSL a kabelových modemů. Toto spojení je definováno dle RFC 2516 Mamakos (1999). Dle tohoto dokumentu PPPoE poskytuje možnost připojení se klientů ke vzdálenému Access Concentratoru, kdy Access Concentrator můžeme považovat za síťové zařízení, které zajišťuje možnost připojení jednotlivých klientů (router nebo vyhrazený server). PPPoE nám dává výhodu například v podobě snadného sledování doby připojení pro jednotlivé uživatele. PPPoE spojení Navázání spojení v PPPoE můžeme rozdělit do dvou procesů při komunikaci na lince. Prvním procesem je takzvaná průzkumná činnost (Discovery stage), kdy klient si najde svůj server (Access Concentrator), ke kterému se připojí. Tento proces můžeme rozdělit dle RFC 2516 do následujícího postupu. 1. PPPoE Active Discovery Initiation (PADI) paket. Klient pošle inicializační PADI paket na všesměrovou adresu sítě, aby zjistil, jaké jsou Access Concetratory na síti.

3.2

PPPoE

12

2. PPPoE Active Discovery Offer (PADO) paket. Jakmile Access Concentrator obdrží PADI paket, tak na něj může odpovědět PADO paketem. Do této zprávy musí Access Concetrator připojit své jméno a veškeré služby, které poskytuje. 3. PPPoE Active Discovery Request (PADR) paket. V následujícím kroku klient příjme jeden či více PADO paketů v závislosti na tom, kolik access concentratorů odpovědělo a z nich si vybere jeden, na který odpoví. Zašle tedy přímo zvolenému Access Concentratoru požadavek k připojení, ke kterému připojí název služby, o kterou žádá. 4. PPPoE Active Discovery Session-confirmation (PADS) paket. Access Concentrator odpovídá touto zprávou klientovi, jako reakci na PADR paket, ve chvíli, kdy vytvoří PPP relaci s klientem. Do této zprávy nadále připojí jedinečný identifikátor SESSION_ID, pod kterým budou spolu tato zařízení nadále komunikovat. Dále do zprávy připojí službu, pro kterou poskytl toto spojení. Ve stejnou chvíli vytvoří Access Concentrator virtuální PPPoE rozhraní, přes které bude následně prováděna komunikace. Po přijetí PADS zprávy klientem může začít PPP komunikace na lince, a to až do chvíle, dokud není odeslán PADT paket. 5. PPPoE Active Discovery Terminate (PADT) paket. Tento paket ukončuje komunikaci přes PPPoE. Druhým procesem je již samotný přenos (PPP Session Stage) dat mezi klientem a Access Concentratorem. Zde jsou data posílána jako zapouzdřený PPP rámec, obdobně jako v běžné komunikaci PPP, s tím rozdílem, že tento rámec je navíc ještě zabalen do PPPoE. Tento celek je posléze dále zapouzdřen do ethernetového rámce. Ethernetový rámec a PPPoE PPPoE využívá k přenosu Ethernetové linky. Níže na obr. 2 je vyobrazen ethernetový rámec, kde v části data je nyní zapouzdřen protokol PPPoE. Zdrojová a cílová adresa

Obrázek 2: Ethernetový rámec zdroj, převzato z Mamakose (1999, s. 2)

3.3

SNMP

13

je fyzická adresa rozhraní, které vysílá nebo přijímá rámce. Hodnota Ethernet type může nabývat při přenosu PPPoE hodnot 0x8863 pro Discovery stage nebo 0x8864 pro PPP Session Stage. Část rámce PPPoE je pro přehlednost vyznačen na obr. 3. V PPPoE rámci jsou hodnoty verze a typ neměnné. Pole Code určuje, jaký typ

Obrázek 3: PPPoE část Ethernetového rámce, převzato z Mamakose (1999, s. 3)

zprávy je přenášen přes tento rámec (PADI,PADO). Pole Session ID je identifikátor relace PPPoE stanovený v Discovery stage. Pole délka definuje velikost pole Data PPP, ve kterém je již zabalen protokol PPP.

3.3

SNMP

Simple Network Manage Protocol je jednoduchý protokol, který umožňuje vzdáleně řídit zařízení vyskytující se na síti. Díky tomuto protokolu jsme schopni vzdáleně řídit nebo číst informace ze zařízení, které tento protokol podporují. Tato zařízení jsme pomocí SNMP schopni ovládat za pomoci jednoduchých požadavků. Leskiw (2011) ve své literatuře uvádí, že pomocí SNMP můžeme sledovat nebo nastavovat širokou škálu informací. Například můžeme ze vzdáleného zařízení vyčíst stav pevného disku, využití šířky pásma síťového připojení nebo využití prostředků procesoru a operační paměti. Dále můžeme pomocí SNMP protokolu zasílat na vzdálená zařízení požadavky pro jejich modifikaci. Jak je uvedeno podle Schmidta a Maura (2005) SNMP rozděluje zařízení do dvou typů. Prvním typem je SNMP agent. Za takového agenta si můžeme představit jakékoliv monitorované nebo řízené zařízení na síti. Druhým typem je SNMP manažer. Jak uvádí Bouška (2006), manažer se stará o zasílání požadavků jednotlivým agentům nebo přijímá chybové zprávy, které jednotliví agenti zaslali. Dle Leskiwse (2011) protokol SNMP pracuje na UDP protokolu. Přesněji, agent naslouchá zprávám od manažera na portu 161 a manažer čeká odpovědi na portu 162. SNMP je rozdělen na několik verzí, z nichž nejaktuálnější je SNMPv3. Výstižně jsou tyto verze popsány v úvodu Schmidta a Maura (2005).

3.3

SNMP

14

Verze SNMP SNMP verze 1 (SNMPv1) je definována v RFC 1157. Tato první verze definovala typy zpráv a komunikaci mezi SNMP manažery a agenty. Bezpečnost této verze vycházela z SNMP komunit (communities). Tyto komunity využívají hesla v textových řetězcích, jako ověření přístupu k zařízení. Pro přístup SNMP manažera k agentu stačí znát adresu agenta a tento textový řetězec. Nevýhodou je, že tento řetězec se přes síť zasílá jako nešifrovaný text a proto je snadno zcizitelný. Typicky se v SNMPv1 uvádějí tři komunity, read-only pro pouhé čtení dat ze zařízení, readwrite pro čtení i modifikaci dat na zařízení a trap pro zasílání chybových zpráv manažeru. SNMP verze 2 (SNMPv2) odbourává dle Skřivánka (2007) limity první verze. V SNMPv2 je možné získat větší množství dat pomocí jednoho požadavku, což nebylo u první verze možné. Další výhodou oproti první verzi je, že agent zasílá zprávu manažeru o nějakém problému i s detailním popisem tohoto problému a manažer se již dále nemusí dotazovat, o jaký problém se jedná. Hlavním úkolem SNMPv2 bylo zvýšení zabezpečení SNMP komunikace. Implementace SNMPv2 byla však v tomto ohledu příliš složitá, a proto SNMPv2 byl upraven na Community-Based SNMPv2 (SNMP v2c), který je hojně používán dodnes, i přesto, že obsahuje stejné zabezpečení jako SNMPv1. Následně z důvodu vyššího zabezpečení vznikl User-Based SNMPv2, který ověřuje jednotlivé SNMP uživatele zvlášť, ale nevyžaduje takovou složitost implementace jako SNMPv2. SNMP verze 3 je poslední verzí tohoto protokolu. Z hlediska funkcionality téměř kopíruje možnosti SNMPv2. Tato verze dle Schmidta a Maura (2005) zavádí kryptografické zabezpečení protokolu. Samotná SNMP komunikace je šifrována, a to včetně ověření uživatele. Při šifrování je ale použit pouze algoritmus DES (Data Encryption Standart), který je v dnešní době již zastaralý. Další změna v protokolu SNMPv3 nastává v definici SNMP manažerů a agentů. V této verzi se oba nazývají SNMP entita. Každá entita je složená z SNMP enginu a SNMP aplikací. Díky této změně bylo možno oddělit rozdílné kusy SNMP systému a zjednodušit jejich následnou komunikaci. V praxi to znamená, že každá aplikace se zabývá něčím rozdílným. Například SNMP aplikace Command generator se stará o tvorbu zpráv get, gedbulk, takže zasílá dotazy na jiné entity a Command responder zase na tyto dotazy odpovídá.

3.3

SNMP

15

OID a MIB SNMP protokol při své komunikaci žádá o to, jaký objekt se má modifikovat nebo o jakém objektu má agent zaslat manažeru informace. Tyto objekty jsou identifikovány pomocí jedinečných identifikátorů objektu zvaných OID (Object Identifier). Každý objekt, který může být při SNMP komunikaci vyžadován má svoji hodnotu definovanou pomocí OID. Všechny OID objekty jsou popsány jazykem SMI (Structure Management Information). SMI je jazyk, který definuje chování jakéhokoli OID, jeho vlastnosti a popis. O OID můžeme říci, že je to hodnota čísel oddělená tečkami. Každé číslo v hodnotě OID má svůj logický význam a je člověkem přesně definována. Hodnoty OID spadají do pomyslného stromu hodnot. Tyto stromy hodnot jsou popsány pomocí MIB (Management informaton base). MIB definuje každý uzel stromu a dle Schmidta a Maura (2005, s. 32) je každý tento uzel identifikován jedinečným OID a jeho názvem, případně jeho dalšími potomky, které právě MIB definuje. Část tohoto stromu můžeme vidět na obr. 4. Z obrázku je zřejmé, že když

Obrázek 4: Část stromu OID hodnot, převzato ze Schmidta a Maura (2005, s. 36, obr. 2-4)

chceme přistoupit například k položce rozhraní, tak je hodnota OID 1.3.6.1.2.1.2, když k položce systému, tak je hodnota OID 1.3.6.1.2.1.1. K zjištění dalších hodnot OID je postup stejný,

3.3

SNMP

16

Typy SNMP zpráv Aby protokol SNMP dokázal komunikovat mezi jednotlivými účastníky, využívá následujících zpráv. • Get zasílá SNMP manažer agentu společně s OID, jako žádost, aby agent zaslal informaci manažeru o požadované hodnotě uvedené v OID. • Getresponse zasílá agent jako odpověď SNMP manažeru s požadovaným OID a hodnotou. • Getnext stejně jako u Get zasílá SNMP manažer agentu, kdy manažer požaduje následující hodnotu následujícího objektu, než je uveden v hodnotě OID. • Getbulk (SNMPv2 a SNMPv3) zasílá SNMP manažer agentu, když požaduje víc OID zároveň, jako například všechny OID definované v interfaces. • Set je zpráva, kterou zasílá manažer agentu. Tato zpráva obsahuje OID s požadovanou hodnotu, která se má na agentu nastavit. • Trap zpráva je generována agentem při nějaké události a obsahuje adresu agenta, typ a kód chyby. • Notification (SNMPv2 a SNMPv3) dá se říci, že notifikace je optimalizovaný SNMP trap. Agent zasílá zprávu notifikace, když dosáhne námi předem definovaný stav. • Inform (SNMPv2 a SNMPv3) je zpráva, která zasílá informaci o změně stavu zařízení, na kterou je požadována potvrzující odpověď. • Report (SNMPv2 a SNMPv3) se používá při přeposílání zpráv mezi jednotlivými SNMP manažery. SNMP datagram Komunikace protokolu SNMP využívá pro komunikaci speciální datagramy, které se zapouzdřují do UDP/IP protokolu. Příklad tohoto datagramu je možno vidět na obr. 5. Jednotlivá pole jsou vysvětlena dle Skřivánka (2007) takto. Version určuje verzi protokolu SNMP. Comunity String určuje případnou komunitu. Request ID definuje, jaký typ zprávy je zaslán. Error status určuje u odpovědi, zda požadavek byl úspěšný. Error index říká, který OID požadovaný ve variable bindings vyge-

3.4

RRD Tool

17

Obrázek 5: SNMP datagram pro všechny zprávy mimo trap, převzato ze Skřivánka (2007)

neroval chybu. Variable bindings obsahují požadované hodnoty OID. V případné odpovědi jsou u OID přiřazené jejich aktuální hodnoty. Pokud ale SNMP posílá trap zprávu, je struktura datagramu jiná. Version a Comunity string jsou neměnné, ale další hodnoty jsou následující. Enterprise identifikuje typ objektu, který vygeneroval trap. Agent address je adresa objektu, který vygeneroval tuto zprávu. Generic trap type a Specific trap code identifikují typ a kód zprávy trap. Time stamp je čas, kdy byla vygenerována tato zpráva. Variable bindings je seznam OID a jejich hodnoty, které obsahují informace o dané chybové zprávě.

3.4

RRD Tool

RRD Tool je nástroj vyvinutý T. Oetikerem. Původně tento nástroj měl být vyvinut jako rozšíření programu MRTG (Multi Route Traffic Grapher), který monitoruje vytížení provozu síťových linek a následně tento provoz graficky znázorňuje na webové stránce. RRD Tool je ale natolik komplexním nástrojem, že je v něm možné monitorovat mnohem více, než je sledování vytížení síťových linek, což byl původní záměr. Pomocí RRD Toolu jsme totiž schopni uchovávat jakékoliv číselné hodnoty závislé v čase, jako je například teplota v serverovně, vytížení pevného disku nebo počet ujetých kilometrů na kole. Následně z těchto uchovaných hodnot je možno pomocí RRD Toolu vytvářet grafy v obrázkových formátech, jako je například PNG. Oetiker (2012A) uvádí, že právě tvorba těchto grafů je poměrně slušně vyřešená. RRD Tool je schopen grafy generovat jako obrázky, které potom můžeme jakýmkoli způsobem prezentovat. Tyto obrázky jsou generovány přitom pomocí jazyka C tak, aby tento proces nebyl příliš procesorově náročný. Ačkoli tento nástroj by měl být implementován do nové verze MRTG, zatím je v MRTG využíván pouze jako plugin. RRD Tool je ale využíván v mnoha dalších aplikacích, jako jsou například Cacti, Nagios, Collectd, kde řeší uchovávání dat a jejich následné generování do grafů.

3.4

RRD Tool

18

Struktura RRD dat RRD Tool je hlavně významný tím, jak uchovává data. Data jsou uchovávána ve speciálních RRD souborech zvaných Round-Robin Database. Tato databáze je zajímavá tím, že má přesně definovanou svoji velikost už při vytvoření. Data, která jsou do této databáze nahrávána, jsou cyklicky přepisována, proto round database. Tento princip si dovolím vysvětlit na příkladu. Máme databázi o pěti položkách. Jako první položku uložíme číslo 1. Následně čísla 2,3,4 a 5. Jakmile ale chceme do této databáze uložit šesté číslo, například 8, tak se v této databázi nahradí číslo 1 právě tímto číslem. Toto je velmi vhodné, například pokud sledujeme, jaká čísla se nám zobrazí na displeji za posledních pět minut, kdy se na displeji každou minutu zobrazí jiné číslo. V této chvíli nás totiž nezajímá, jaká byla hodnota před šesti minutami, ale jen jaké byly hodnoty za posledních pět minut. Tvorba RRD souborů a RRD Create Samotný soubor RRD je vytvořen tak, že jeden Round Robin Database obsahuje více RRA - Round Robin Archive částí. V záhlaví RRD je definováno, jaká data jsou monitorována, jak často ukládána a jakých hodnot mohou data nabývat. Potom v RRD souboru následují RRA archívy, které již přímo mají v sobě uložená data. Jeden RRA archív může ukládat hodnoty za poslední hodinu a je v něm připraveno místo, do kterého budeme ukládat hodnoty každých pět minut. Druhý RRA ukládá data za poslední den a hodnoty jsou v něm uloženy každou půlhodinu. Tento princip již souvisí s funkcí konsolidací dat, kterou právě RRD Tool využívá. Informace o konsolidaci dat jsou nejlépe popsány v dokumentaci RRD Toolu Oetiker (2012A). Zde je uvedeno, že při vytvoření RRD databáze můžete definovat interval, ve kterém by ke konsolidaci dat mělo dojít. Následně pomocí konsolidačních funkcí, například pomocí minima, průměru, maxima nebo poslední získané hodnoty je vytvořena potřebná hodnota, která bude uložena do RRD souboru. Konsolidační funkce nám řeší problém, který by nastal, pokud bychom chtěli monitorovat poslední rok po každé minutě. Tento postup by byl datově velmi náročný. Díky tomu, že je možno v RRD souboru definovat libovolný počet konsolidačních funkcí - RRA archivů, je zajištěno, že tato data jsou uchovávána po různě dlouhou dobu pro každý RRA archív. Výhodou také je, že každý RRA archív obsahuje data, která jsou uložena v jiných časových rozestupech. Právě díky použití těchto různých RRA archívů a využití konsolidačních funkcí dokážeme uchovávat staré hodnoty po dlouhou dobu, aniž by ztratili svůj účel. Starší data totiž nejsou tak náchylná na svoji přesnost, a proto

3.4

RRD Tool

19

můžeme postupem doby snížit jejich kvalitu. Snížením kvality se v tomto významu myslí, že u dat která jsou rok stará ,nepotřebujeme znát jakou mají hodnotu v jednotlivých minutách, ale stačí nám znát, jaké mají hodnoty třeba v úsecích patnácti minut. Pro lepší pochopení popíšeme v příkazu RRD Create. Syntaxe příkazu je vyobrazena pro jazyk Perl. RRDs :: create , --start <start time >, --step , --no -owerwrite , DS:ds - nazev :DST: heartbeat :min:max , RRA:CF:xff: stepn:rows;

Příkaz Create nám vrací buď hodnotu 0, pokud příkaz proběhl v pořádku nebo navrací popis chyby, proč nebylo možné vytvořit RRD soubor. Vlastnostmi tohoto příkazu dle dokumentace Oetikera (2012A) jsou následující. Filename je jméno vytvářeného RRD souboru. Start je čas, od kdy vkládáme monitorovaná data do RRD souboru. Step neboli krok nám udává, jak často máme v plánu RRD soubor aktualizovat. Defaultní hodnota kroku je 300 sekund. To znamená, že každých 300 sekund je očekávána hodnota zápisu do RRD souboru. Parametr –no-overwrite nám říká, že pokud již existuje zadaný název souboru, tak nebudeme tento soubor přepisovat. Další parametry DS:ds-nazev:DST:heartbeat:min:max přímo uvádějí, který druh dat a jakým způsobem budeme data monitorovat. Ds-název je námi zvolený název pro monitorovaná data. Hodnota heardbeat nám udává, za jak dlouho od plánované aktualizace RRD souboru bude zapsána do souboru neznámá hodnota, místo hodnoty očekávané. Další parametry min a max jsou rozsah povolených hodnot, které můžeme do této konsolidační funkce ukládat. Pokud získáme jinou hodnotu, bude do RRD souboru vloženo ’UNKNOWN’. Část DST, neboli Data source type nám uvádí, jak se RRD Tool bude chovat k hodnotám získaných při aktualizaci RRD souborů. DST může nabývat následujících hodnot. • Gauge - hodnota, která bude načtena, bude ve stejném tvaru i uložena do RRD souboru. Například počet spuštěných procesů, vytížení RAM, CPU nebo například monitorovaná teplota. • Counter - počítá s hodnotami, které se jenom zvětšují, jako jsou čítače. Counter říká, že data, která jsou ukládána do RRA archívu jsou vypočítána rozdílem

3.4

RRD Tool

20

nově příchozích hodnot a hodnot posledně uložených do RRD souboru. Výhoda couteru je, že počítá s přetečením čítačů. V případě přetečení RRD Tool dopočítává hodnoty tak, aby byla data správně uložena. • Derive - velice podobné jako counter, ale nepočítá s přetečením čítačů. • Absolute - data, která budeme číst, jsou po každém čtení nulována. Ukládána je tedy přímo tato hodnota, ale ve významu přírůstku k předcházející uložené hodnotě. • Compute - speciální případ dat, kdy nejsou ukládána data přímo čtená, ale jsou rúzně vypočítána například z hodnot, které jsme získali dříve. Dále musíme nadefinovat, v jakých rozlišeních a kolik dat jakého druhu budeme chtít mít uloženo. Toto ovlivníme parametry RRA:CF:xff:stepn:rows. CF je konsolidační funkce, jakou požadujeme použít. CF nabývá hodnot AVERAGE, MIN, MAX, LAST. Parametr xff nám udává, jaké procento neznámých dat může konsolidační funkce obsahovat tak, aby byla platná. Stepn zde uvádí kolikátý krok, neboli kolikátý zápis do RRD souboru bude uložen do konsolidační funkce Rows udává, kolik hodnot bude uloženo právě v této konsolidační funkci. Například pokud budeme aktualizovat RRD soubor každých 300 sekund a budeme chtít monitorovat poslední hodinu každých 5 minut, bude konsolidační funkce vypadat takto RRA:AVERAGE:0.5:1:12, kde číslo 1 nám říká, při každém kroku ulož získané číslo do konsolidační funkce a ulož zde 12 čísel. K číslu 12 jsme dospěli jednoduchým výpočtem. Chceme monitorovat 1 h = 3600 s a každý krok (update) trvá 300 s, proto 3600 / 300 = 12. Těchto dvanáct čísel nám odpovídá přesně intervalu jedné hodiny. Pokud bychom chtěli monitorovat posledních 6 hodin každých 10 minut, bude funkce následující RRA:AVERAGE:0.5:2:12. Krok máme stále 300 sekund. Aktualizujeme data každý druhý krok. Proto hodnota stepn = 2 a uchováváme 36 hodnot. Aktualizace RRD souborů Po té, co jsme vytvořili RRD soubory je potřeba je naplnit daty. K tomuto účelu slouží funkce Update. Tento příkaz má tvar RRDs::update -t ds-name[:ds-name]...] N:value[:value...]. Jeho vysvětlení je poměrně jednoduché. Filename je název RRD souboru, který chceme aktualizovat, parametr -t je pomyslný vzor, který udává pořadí hodnot konsolidačních funkcí. Tyto názvy funkcí

3.4

RRD Tool

21

musí odpovídat názvům, které jsou nadefinované v příkazu create. N:value jsou hodnoty, kterými aktualizujeme příslušný RRD soubor. Tato funkce nám navrací hodnotu 0, když vše proběhlo v pořádku nebo v případě chyby navrací její popis. Tvorba grafů v RRD K vygenerování grafů v RRD Toolu slouží funkce graph. Tato funkce nám vygeneruje požadovaný graf a vytvoří z něj obrázek ve formátu PNG tak, jak si ho nadefinujeme. Samostatná definice bude uvedena níže při popisu funkce graph. Funkce graph nám navrací hodnotu 0, když se jí podaří vygenerovat graf jako obrázek, který uloží do souboru pod názvem, který definujeme jako parametr příkazu. V případě, když parametr názvu souboru je definovaný jako ’-’, funkce graph navrací datovou strukturu BLOB (Binary Large Object), ve které je uložen obrázek jako posloupnost znaků. Ostatní návratové hodnoty této funkce jsou známy jako chybové a udávají kód chyby, proč nebylo možné tento obrázek vytvořit. rrdtool graph . png --start = <pocatecni cas > --end = DEF: nazev = filename .rrd:< nazev RRA archivu v~rrd souboru >:CF LINE1 : nazev # FF0000 : popis krivky CDEF:x2=nazev ,2 ,* LINE2 :x2=#0000 FF: popis druhe krivky

Parametry počáteční a koncový čas jsou udávány v unixovém času a udávají, pro jaké období má být graf vygenerován. Toto časové období bude v grafu znázorněno na ose x. Následně příkaz pokračuje definicí RRD souborů (parametr DEF), ze kterých se mají čerpat data pro vypsání do grafu. Tato data si pracovně označíme proměnou nazev, se kterou dále budeme pracovat. Do této proměnné uložíme funkci, která je definovaná ve čteném RRD souboru DEF:nazev=filename.rrd:pocetPrenesBit:MAX. Do proměnné nazev by byla uložena dle zmíněného příkazu funkce maximálního počtu přenesených bitů ze souboru filename.rrd. Dále parametrem LINE1:nazevFF0000:popis krivky řekneme, že se má vypsat do grafu křivka, která je definovaná v proměnné nazev, má být vypsána dle FF0000 červenou barvou společně s námi definovaným popisem. Dále můžeme definovat CDEF (Compute Def). CDEF definuje data určitým výpočtem, který je uveden v postfixovém formátu. CDEF:x2=nazev,2,* znázorňuje zdvojnásobení funkce, která je uložena do proměnné název a uloží tento výsledek do proměnné

3.5

CPAN Minus

22

x2. Následně pomocí LINE2 vypíšeme druhou křivku (x2) do grafu modrou barvou. Tento příklad je vidět na následujícím obrázku 6. Samozřejmostí je, že můžeme

Obrázek 6: Příklad obrázku vygenerovaném funkcí graph, zdroj: vlastní

přidat popis grafu, jeho název, názvy jednotlivých os, minimální a maximální hodnoty. Veškeré tyto příkazy jsou dále rozebrány v dokumentaci uvedené v Oetikerovi (2012A, sekce Graph).

3.5

CPAN Minus

CPAN Minus je manažer Perl modulů, které se vyskytují na CPAN (Comprehensive Perl Archive Network). Kleinman (2010) říká, že CPAN je hlavním zdrojem rozšiřujících modulů pro jazyk Perl. Program CPAN Minus je jednoduchý program, který nám vyhledá modul na CPAN. Následně tento modul nainstaluje a to včetně veškerých závislých modulů. Dalo by se říci, že CPAN Minus je takovým balíčkovým systémem pro moduly do jazyka Perl. Instalace a spuštění CPAN Minus Tato instalace je popsána Kleinmanem (2010) a její postup je následující. yum i n s t a l l p e r l −d e v e l c u r l g c c cd / opt / c u r l h t t p s : / / raw . g i t h u b . com/miyagawa/ cpanminus / master /cpanm > cpanm chmod +x cpanm l n −s ~/ opt /cpanm / u s r / b i n / cpanm −−s e l f −upgrade −−sudo

Poté, co jsme nainstalovali a aktualizovali program CPAN Minus, můžeme nainstalovat jakékoli moduly, které jsou dostupné na CPAN. Instalace tohoto modulu je potom možná pomocí příkazu cpanm .

3.6

3.6

Net::SNMP

23

Net::SNMP

Net::SNMP je rozšiřující modul jazyka Perl, který nám umožní integrovat do jazyka Perl komunikaci přes SNMP protokol. Díky tomuto modulu dokážeme zasílat SNMP zprávy v protokolech SNMPv1, SNMPv2c a SNMPv3. Town (2010) uvádí, že Net::SNMP vytvoří objekt pro každou novou SNMP relaci. Následně díky voláním metod tohoto objektu se vytvářejí a zasílají SNMP zprávy. Dříve než tento modul můžeme použít, je potřeba ho nainstalovat. Instalace se provádí pomocí programu CPAN Minus, a to příkazem cpanm Net::SNMP. Hlavní funkce Net::SNMP Než začneme zasílat pomocí Net::SNMP modulu jednotlivé SNMP zprávy, musíme vytvořit novou instanci tohoto objektu. Tato nová instance se nám vytvoří automaticky zavoláním metody Net::SNMP->session(). Metoda a její parametry jsou vyobrazeny v následujícím kódu. use Net :: SNMP; ($session , $error ) = Net ::SNMP -> session ( Hostname => '192.168.1.2 ', Version => 'snmpv2c ', Community => 'monitoring ');

Prvním příkazem je zavedení modulu do našeho skriptu. Následně do proměnné $session je uložen ukazatel (pointer) na nově vytvořený objekt relace Net::SNMP. V metodě session jsou tři základní parametry. Hostname značí adresu vzdáleného zařízení, ke kterému chceme vytvořit SNMP relaci. Version označuje verzi protokolu SNMP, přes kterou budeme vedena komunikace. Comunity označuje, jakou komunitu chceme využít jako heslo pro připojení k tomuto zařízení. V případě, že nebylo možné vytvořit relaci, je do proměnné $error vložen popis chyby, proč nebylo možné tuto relaci navázat. Další volitelné parametry metody session jsou vypsány v dokumentaci CPAN Town (2010). Poté, co jsme vytvořili relaci ke vzdálenému zařízení, můžeme zasílat samotné SNMP zprávy. Tyto zprávy zasíláme pomocí metod vytvořeného objektu. Například zprávu SNMP Get zašleme následujícím příkazem. @oids = ('1.3.6.1.2.1.2.2.1.2.1 ') $result = $session -> get_request ( -varbindlist => \@oids , );

3.7

CRON

24

Metodě jako parametr -varbindlist připojíme odkaz na pole OID hodnot, které chceme vyčíst ze vzdáleného zařízení. Do proměnné $result je uložen výsledek zaslané zprávy ve tvaru hashe hodnot, kde klíče k hashi jsou požadované OID identifikátory a hodnoty hashe jsou námi požadovaná data. Následně, co získáme požadovaná data, je důležité tuto relaci ukončit příkazem $session->close() . Velice obdobně jsou definovány i další SNMP zprávy. Soupis veškerých těchto zpráv najdeme v dokumentaci CPAN Town (2010).

3.7

CRON

Tak, jak v systému Windows existují naplánované úlohy neboli příkazy, kdy systém má v určitý čas spustit daný program, tak v systémech Linux existuje program CRON. Matt (2012) uvádí, že program CRON automaticky spouští na pozadí námi definované programy ve stanovené době. Program CRON se konfiguruje pomocí příkazu crontab -e, který nám otevře jednoduchý textový editor. Tento editor očekává 6 hodnot na jednom řádku. Minutu, hodinu, den, měsíc, den v týdnu a cestu k programu, který se má v daný čas spustit. Veškeré položky jsou oddělené mezerami a uvedeny v editoru v tomto pořadí. Kocman (2002) uvádí velmi hezký příklad použití: 0 1 * * * /www/cgi -bin/ skript .cgi 5 1 * * * / backup / make_backup * 2 * * * wget http :// www. server .cz/ stahuj .php 0 0 1 * * / backup / delete_www_log 0 ,5 ,10 ,15 ,20 ,25 ,30 ,35 ,40 ,45 ,50 ,55 * * * * /www/cgi -bin/ generuj_sessions .cgi

První řádek spouští skript.cgi každý den v 1:00 ráno. Druhý řádek cronu říká, aby spouštěl program make_backup denně v 1:05 ráno. Třetí řádek bude volat program wget, který bude stahovat obsah zadané internetové adresy každou minutu od 2:00 do 2:59. (I když máme definovanou hodinu, nedefinovali jsme minutu, tudíž se cron bude pokoušet spouštět úlohu každou minutu v danou hodinu.) Čtvrtý řádek tohoto příkladu bude spouštět program, který zálohuje a následně vymaže log web serveru. Svou činnost bude provádět vždy na začátku nového měsíce. Poslední řádek bude spouštět skript každých pět minut (Kocman, 2002).

4

PŘEHLED STÁVAJÍCÍCH PRODUKTŮ

4

25

Přehled stávajících produktů

Tato kapitola obsahuje přehled produktů, které se využívají v oblasti sledování vytížení síťových linek. Je potřeba, aby hledaná aplikace odpovídala uživatelským požadavkům této práce. Aplikace tedy musí být schopná vytvářet grafy vytížení síťových linek jednotlivých uživatelů sítě, kteří se připojují pomocí PPPoE protokolu k routeru na platformě MikroTik. Jedním z klíčových požadavků na aplikaci je tedy možnost nastavit aplikaci tak, aby byla schopná číst data právě ze zařízení MikroTik. Během monitorování tohoto zařízení je možné využít fakt, že v zařízení MikroTik je pro každého připojeného PPPoE uživatele vytvořeno nové rozhraní. Na takto vytvořeném rozhraní je počítáno, kolik dat bylo během tohoto připojení přeneseno. Dále se po aplikaci požaduje schopnost zaznamenávat v grafu hodnoty počtu přenesených bitů za sekundu ve směru od uživatele a k uživateli. Aplikace dále musí být schopná, tyto grafy prezentovat připojenému uživateli přes webové rozhraní tak, aby každý uživatel viděl pouze graf vytížení své linky. V následujících sekcích této kapitoly, jsou uvedeny aplikace, které se k tomuto účelu nejčastěji používají.

4.1

Nagios

Nagios je, jak komerčně dostupný, tak i volně šiřitelný nástroj. Program Nagios Core je volně dostupnou variantou tohoto nástroje. Galstad (2012) uvádí, že Nagios Core je webová aplikace, která je primárně zaměřena na kontrolu dostupnosti síťových služeb a kontrolu prostředků síťového hardwaru. Nagios Core shromažďuje monitorované prvky do logické mapy podle toho, jak jsou zapojeny nebo umístěny tak, aby korespondovaly s reálnou topologií sítě. Následně tato logická mapa zobrazuje veškerá monitorovaná zařízení a jejich stav tak, aby v případě nějaké chybové události bylo zřejmé, na kterém prvku sítě se tato chyba vyskytuje. Monitoring sledovaných prvků můžeme rozdělit, jak zmiňuje Schroder (2009, s. 373), na zjišťování konektivity síťových prvků, dále na sledování služeb nebo procesů, které jsou spuštěny na monitorovaných zařízení a také na monitorování prostředků síťových prvků. Nagios Core se dokáže připojit pomocí SNMP protokolu k různým síťovým prvkům a následně sledovat, jaké je využití času procesoru, operační paměti nebo je schopen sledovat jaké je využití šířky pásma na jednotlivých rozhraních směrovačů a přepínačů. Nagios se tedy využívá pro administrativní sledování chodu sítě. Výhodou použití tohoto nástroje je možnost využití automatických upozornění administrátora sítě při chybových stavech, které může správce sítě předem definovat. Za chybový stav může být považován výpadek síťové služby, překročení míry volného místa na

4.1

Nagios

26

pevném disku serveru nebo například přechod stavu síťového rozhraní ze stavu Up do Down. Následně co tento stav nastane, Nagios vyšle upozornění administrátorovi pomocí emailu nebo zprávy SMS. Pokud bychom chtěli pomocí Nagios Core monitorovat využití šířky pásma jednotlivých rozhraní a následně z těchto dat vytvářet grafy vytížení síťových linek, museli bychom využít některé z dostupných rozšíření pro tento program. Nagiosgraph je nejpoužívanějším rozšířením tohoto druhu. Jak uvádí Brenner (2012) Nagiosgraph integruje do programu Nagios výpis grafů pro jednotlivá rozhraní síťových prvků. Nagiosgraph sbírá data pro každé monitorované rozhraní a pomocí RRD Toolu ukládá tato data do RRD souborů. Následně z těchto uložených dat vytváří grafy využití síťových linek, které prezentuje v programu Nagios. Výpis grafů pomocí pluginu Nagiosgraph je možno vidět na obr. 7.

Obrázek 7: Výpis grafů pomocí Nagiosgraph, převzato z Brenera (2012)

V případě využití tohoto programu pro monitorování stavu síťových linek a generování grafů vytížení síťových linek pro jednotlivé uživatele sítě se použití tohoto programu moc nehodí. Důvodem je, že pokud bychom chtěli monitorovat veškerá aktivní rozhraní na MikroTik routeru, narazili bychom na problém při monitorování virtuálních rozhraní pro každého PPPoE uživatele. Tato rozhraní by Nagios monitoroval až po té, co by byly administrativně přidány do konfigurace programu Nagios. Dalším limitem tohoto řešení je zobrazení grafů pro každého připojeného uživatele. Nagios Core totiž neumožňuje jednotlivým uživatelům zobrazit pouze graf vytížení určitého rozhraní, ale umožňuje zobrazit veškeré sledované grafy a prvky jednoho zařízení jako celku. V praxi by to znamenalo, že pro každého zákazníka bychom

4.2

Cacti

27

museli vytvořit nový účet do Nagios Core a po přihlášení by uživatel viděl grafy vytížení všech rozhraní.

4.2

Cacti

Cacti je dalším nástrojem pro sledování stavu sítě. Cacti je volně šiřitelná webová aplikace napsaná v jazyku PHP, která dle Berry Iana (2012) se zabývá sledováním vytížení síťových prostředků a síťových služeb, ze kterých Cacti následně generuje grafy jejich využití. Pomocí Cacti můžeme například vytvářet grafy vytížení síťových linek, teplot, vytížení disků serveru nebo doby odezvy síťových služeb a také i jakýchkoli dalších měřitelných hodnot v čase. Urban (2011, s. 20) uvádí, že Cacti využívá program RRD Tool pro ukládání dat a vytváření grafů. První verze Cacti vydaná v roce 2001 byla takovým webovým rozhraním pro program RRD Tool. Nyní je Cacti poměrně rozšířeným programem pro sledování stavu sítě. Cacti vypisuje grafy monitorovaných hodnot v pomyslném stromu zařízení. Dá se říci, že tento strom je tvořen větvemi (monitorovanými zařízeními) a listy na těchto větvích (grafy těchto monitorovaných hodnot). Tento strom hodnot je posléze velmi důležitý pro přehlednost výpisu grafů a případnou prezentaci jednotlivých větví nebo listů stromu vybraným uživatelům Cacti. Jak již bylo řečeno, veškerá monitorovaná data jsou ukládána do RRD souborů. Informace o nastavení jednotlivých RRD souborů, monitorovaných zařízeních jsou uložena v MySQL databázi. Po instalaci Cacti je potřeba nastavit, jaký prvek sítě chceme monitorovat. Tento krok je zabezpečen nahráním šablonových (template) souborů a skriptu pro sběr dat do konfigurace Cacti. Dle Berryho (2011, s. 53) existují tři typy šablonových souborů ve formátu XML. První definuje, o jaký typ monitorovaného zařízení se jedná, jak je k němu přistupováno a jakou hierarchii hodnot obsahuje. V druhém typu je popsáno, jaká monitorovaná data jsou získána pomocí skriptu pro sběr dat a jak se k těmto hodnotám má Cacti a RRD Tool chovat. Například tento XML soubor nám říká, jaký formát RRD souboru má být vytvořen. Posledním typem je šablona, která definuje, jak budou generovány grafy, jaké budou mít popisky, v jakých barvách a za jaké časové období. Ve skriptu pro sběr dat je uvedeno, jak tato data získat. Tento skript může používat SNMP komunikaci v případě, že chceme číst data ze vzdálených zařízení. Dále tento skript může využívat výstupů z programu ping nebo jakýchkoli dalších programů, které jsou nainstalovány na stejném serveru jako Cacti.

4.2

Cacti

28

Obrázek 8: Zobrazení grafu monitorovaného uživatele, zdroj: vlastní

V dnešní době jsou šablonové soubory vytvořeny pro prakticky všechny nejčastěji používané platformy síťových zařízení. Není problém získat šablonové soubory pro čtení přenesených dat na jednotlivých rozhraních routeru platformy MikroTik. Pokud ale chceme monitorovat jednotlivé PPPoE klienty připojené k routeru MikroTik, musíme ale počítat s tím, že jednotlivé virtuální rozhraní budou dynamicky přidávány a odebírány v závislosti na připojení PPPoE klientů. Tím se dostáváme do situace, kdy jeden PPPoE klient se může na síť MikroTik router připojit pomocí virtuálního rozhraní s hodnotou OID 1.3.6.1.2.1.2.2.1.X.1. Následně se tento uživatel odpojí a po pěti minutách znovu připojí na síť s jinou OID hodnotou. S tímto chováním ale standardní šablonové soubory nepočítají. Proto je nutné vytvořit nový skript pro sběr dat ze zařízení MikroTik a k němu nový šablonový soubor, ve kterých budeme definovat, že jednotlivá rozhraní nebudeme sledovat pomocí jejich OID hodnot, ale pomocí popisu těchto rozhraní. Tyto popisy jsou pro každého uživatele unikátní a na MikroTik směrovači mají neměnné hodnoty. Výstup z takto nastaveného programu Cacti můžeme vidět na obr. 8. Z hlediska správy tohoto řešení, by bylo potřeba, aby pro každého nového PPPoE klienta bylo v Cacti přidáno nové monitorované rozhraní. Následně by bylo nutné, aby se vytvořil nový uživatelský účet do Cacti, přes který by se mohl zákazník sítě do tohoto programu připojit. Tento uživatelský účet by musel být zařazen do nové skupiny osob, která by definovala, že tento nový uživatelský účet uvidí pouze jeden graf a to graf vytížení jeho síťové linky. Tato aplikace by tedy byla použitelná, ale

4.3

MRTG

29

z hlediska správy veškerých klientů, by byla poměrně časově náročná.

4.3

MRTG

Multi Router Traffic Grapher dále jen MRTG je aplikace, která se zabývá primárně sledováním vytížení jednotlivých rozhraní síťových prvků. Ze získaných dat aplikace MRTG generuje grafy vytížení jednotlivých sledovaných rozhraní, které prezentuje na webové stránce jako jednotlivé PNG obrázky. MRTG aplikace je volně dostupná a v dnešní době hojně využívaná. Tobias Oetiker (2012B) uvádí, že MRTG lze používat nejen na sledování stavu vytížení jednotlivých rozhraní, ale i na sledování vytížení času procesoru nebo operační paměti. Jediným limitem k získání dat pro tato sledování je, že tato data musí být získána pouze pomocí protokolu SNMP, přesněji přes program Net-SNMP. Schmidt (2009) uvádí, že získaná data z SNMP komunikace budou ukládána dle námi definovaného klíče. V MRTG je možno rozhodnout, zdali data budou uložena pod názvem monitorovaného rozhraní, jeho OID hodnotou, jeho popisem nebo pomocí IP adresy přidělené pro toto rozhraní. Získané hodnoty uchovává MRTG v logových souborech. Logové soubory mají konstantní velikost a ukládají monitorovaná data po dobu dvou let. Následně kdy MRTG získá a uloží tato data, vygeneruje z nich grafy ve formátu PNG pro různá časová období. Všechny vygenerované grafy jsou poté interpretovány na webové stránce. Při generování těchto grafů narážíme na limit aplikace MRTG. Všechny obrázky grafů jsou totiž vytvářeny najednou. Pokud bychom monitorovali vice zařízení a generovali grafy pro několik desítek různých rozhraní, nastal by problém z hlediska vytížení času procesoru. I přesto, že k vytváření těchto grafů jsou použity moduly napsané v jazyce C, mohli bychom poměrně snadno zahltit procesor, a tím snížit výkon celého serveru. Další nevýhodou aplikace MRTG je, že pokud bychom při SNMP komunikaci nedostali odpověď z monitorovaného zařízení, byla by do logových souborů zapsána nulová hodnota, která by ale nemusela odpovídat pravdivé situaci. Tento problém by ale mohl být odstraněn použitím pluginu RRD Toolu, který má být v nové verzi implementován přímo do aplikace MRTG. Pokud bychom chtěli použít aplikaci MRTG v této práci, nastal by problém při výpisu grafů jednotlivým uživatelům. Aplikace MRTG umožňuje vypsat pouze celou webovou stránku se všemi vytvářenými grafy najednou. Z tohoto důvodu není aplikace MRTG pro použití v této práci velmi vhodná.

4.4

4.4

Mikrotik Graphing Tool

30

Mikrotik Graphing Tool

Mikrotik Graphing Tool je nástroj nainstalovaný v každém zařízení MikroTik. Mikrotik Graphing tool je MRTG aplikace, která je upravená pro chod na zařízeních s nainstalovaným MikroTik Router OS. Tato aplikace sleduje počty přenesených dat na veškerých dostupných rozhraních MikrotTik routeru, vytížení procesoru, pamětí a také sleduje počty přenesených dat přes veškeré definované datové fronty na zařízení MikroTik. Z těchto hodnot následně Graphing tool vytváří grafy, které prezentuje stejně jako klasická aplikace MRTG přes webové rozhraní. Velkou výhodou této aplikace je její jednoduché a automatické spuštění. Nedostatkem tohoto nástroje je nulová možnost modifikace. V této aplikaci se nedá ani nastavit podle jakého klíče mají být vytvářeny logové soubory, jak je tomu v klasickém MRTG. Tyto logové soubory jsou ukládány vždy pomocí OID jednotlivých zdrojů dat. Další nevýhodou je, že logové soubory jsou odstraněny pokaždé, kdy monitorované rozhraní není aktivní. To znamená, že pokud by se PPPoE zákazník odpojil od routeru, veškerá jeho historie monitorovaných dat by byla smazána. Vzhledem k uvedeným nedostatkům není možné tuto aplikace využít.

4.5

PRTG

Dalším nástrojem pro tvorbu síťových grafů je Paessler Router Traffic Grapher, dále jen PRTG. Tento nastroj je dostupný pouze pro platformu Windows. Aplikace PRTG jsou dostupné v různých licencích. Originální nástroj je komerčně dostupný na http://www.paessler.com/prtg/. Zdarma k dispozici je zkušební verze dostupná na dobu 30 dní. PRTG se principiálně liší od ostatních, běžně dostupných aplikací, protože k ukládání dat nevyužívá RRD nebo logových souborů. Aplikace PRTG totiž využívá pro uložení pracovních dat svoji vlastní databázi souborů. Tato databáze se skládá z drobných souborů uložených na disku a dalších doplňkových dat, která jsou ukládána do registrů systému Windows. Díky této kombinaci je PRTG schopen dle Paesslera (2012) zajistit velmi rychlé zpracování dat pro jejich další využití a generování grafických výstupů. Aplikace PRTG je poměrně jednoduchá na instalaci a nastavení. Lze říci, že za pomoci vytvořených šablonových (teplmlate) souborů dokážeme monitorovat síť během chvíle. Tomuto napomáhá i funkce Auto-Discover, která prohlédne sama celou zadanou síť, na které následně vyhledá zařízení, které by mohly být monitorovány. Následně PRTG zjistí, jaké jsou dostupné sensory na těchto zařízeních. Za takový sensor můžeme považovat jakýkoli monitorovatelný zdroj dat, jako je počet přenesených bajtů na rozhraní, stav vytížení pevného disku

4.5

PRTG

31

a podobně. Výhodou této aplikace je její snadná možnost rozšíření. Není problém nastavit tuto aplikaci nejen pro monitorování jednotlivých síťových prvků, ale i například pro NetFlow monitoring tak, abychom věděli jaký druh dat je přenášen přes sledovanou síť. V souvislosti s touto prací a sledováním PPPoE rozhraní na MiktoTik routeru není tento nástroj ale velmi vhodný. Prvním problémem je, že pro MikroTik snad jako pro jedinou platformu, neexistuje spolehlivě funkční konfigurační šablona, která by zajistila komunikaci mezi MikroTik routerem a PRTG aplikací. Dalším problémem by byla případná správa jednotlivých zákazníků sítě. Při použití zkušební verze PRTG nebylo možné definovat viditelnost jednotlivých grafů jednotlivým uživatelům, ale bylo pouze možné vytvořit uživatelské účty pro čtení veškerých dat v PRTG.

5

PŘEHLED STÁVAJÍCÍCH PRACÍ

5

32

Přehled stávajících prací

V této kapitole jsou zmíněny některé vysokoškolské kvalifikační práce, které řeší sledování stavu síťových linek a následné generování grafů vytížení těchto linek na Mikrotik routeru. Tyto práce byly hledány na portálu Theses.cz pod klíčovými slovy monitoring+mikrotik,mikrotik+sledování, mikrotik+pppoe+monitoring, mikrotik+graf a mikrotik+rrdtool Dále byly tyto práce hledány na stránkách VUT Brno http://www.vutbr.cz/studium/zaverecne-prace. Vyhledávání bylo zadáváno pod stejnými klíčovými slovy jako na portálu Theses. Na základě abstraktu těchto prací byly vybrány následující, které řeší obdobnou problematiku, jako je řešena v této práci.

5.1

BP - Beno Slávik - Využití speciálního operačního systému MikroTik RouterOS v sítích lokálních ISP

Bakalářská práce je volně dostupná v systému Theses. Beno Slávik se ve své práci zabývá vytvořením sítě internetového poskytovatele, která je postavena na systému MikroTik RouterOS. Tento internetový poskytovatel využívá bezdrátového spojení na 5 GHz k šíření svého signálu mezi zákazníky. Poskytovatel počítá s tím, že každý zákazník, který se chce připojit do jeho sítě si musí pořídit MikroTik router. Princip připojení jednotlivých uživatelů do sítě je lehce odlišný od principu, který je použit v této práci. Nevyužívá se zde vytáčeného spojení PPPoE, ale využívá se fakt, že každý zákazník má MikroTik router. Na tomto routeru je uložena konfigurace, která se stará o značkování veškerých paketů jednotlivých uživatelů, které proudí na síť. Na základě takto označených paketů Slávik (2007, kap. Reálný management datových toků) vytváří datové fronty pro každého uživatele sítě. Slávik dále u těchto front nastavuje limity počtu přenesených dat. Veškerá tato připojení jsou monitorována pomocí Mikrotik Graphing Toolu, ve kterém jsou vykresleny grafy počtu přenesených dat přes jednotlivé definované fronty. Takto nasazený Mikrotik Graphing Tool funguje bez problémů, ale pouze jako výpis grafů pro síťového administrátora. Slávik ve své práci navíc použil program Nagios. Přes tento program je sledováno, zdali jsou jednotlivé routery koncových zákazníků připojeny do sítě a případně monitoruje, jaká je úroveň signálu takto připojených routerů. V programu Nagios již dále není řešeno sledování počtu přenesených bajtů pro jednotlivé klienty. K tomuto účelu je používán pouze Graphing Tool. Tato varianta by vypisovala zákazníkům grafy hodnot tak, že každý zákazník by mohl shlédnout i graf vytížení linky jiného

5.2

DP - Jindřich Matúšů - Monitorování stavu rozsáhlých sítí

33

zákazníka, proto si myslím, že není velmi vhodná k využití pro koncové zákazníky, ale spíše pro využití z administrátorského hlediska.

5.2

DP - Jindřich Matúšů - Monitorování stavu rozsáhlých sítí

Diplomová práce je volně dostupná v systému Theses. Jindřich Matůšů řeší obdobnou problematiku jako Beno Slávik. Práce řeší monitorování sítě poskytovatele internetu vybudované přes bezdrátová spojení. V této síti se počítá s tím, že každý klient sítě dostane od poskytovatele nastavený router, který bude mít definovanou statickou IP adresu pro připojení do sítě internet. Poskytovatel dále počítá s tím, že uživatel nemůže měnit nastavení tohoto routeru, pomocí kterého se připojuje k přístupovým bodům. Díky použití statické neměnné IP adresy poskytovatel identifikuje každého zákazníka sítě. Na základě těchto nastavení jsou dále definovány na jednotlivých přístupových bodech datové fronty, které jsou vytvářený na základě IP adres jednotlivých uživatelů sítě. Ke sledování této sítě je použita aplikace Cacti, která řeší monitoring veškerých přístupových bodů sítě. Ke konfiguraci Cacti je použita běžně dostupná šablona pro monitorování zařízení MikroTik. Sledování jednotlivých přístupových bodů a jejich spojení do sítě internet je využita šablona Wireless Registration Tables. Tato šablona zaručuje dle Matúše (2008) výpis veškerých připojených zařízení na jednotlivých bezdrátových rozhraních. V tomto výpisu lze nalézt informace o síle signálu připojeného klientského zařízení a jeho aktuální přenosovou rychlostí. Ke sledování jednotlivých připojených zákazníků je použita šablona Mikrotik Simple Queue, která monitoruje počet přenesených bajtů v každé datové frontě vytvořené pro jednotlivé uživatele, kteří jsou připojeni na přístupovém bodu. Pro zobrazení mapy sítě a její rychlý přehled je použit rozšiřující plugin Weathermap, který řeší grafický výpis stavu linek mezi jednotlivými přenosovými body a stavu linek mezi přístupovými body a zákaznickými routery. Tyto prvky jsou zobrazeny do mapy, reprezentující reálnou topologii sítě. S takto použitým pluginem Wheathermap bylo dosaženo poměrně velké přehlednosti sítě, a to i v případě chybové situace. Pokud by nastala na nějakém prvku sítě chyba, aplikace by hned označila tento prvek a zobrazila by o jakou chybu se jedná. Takto řešený monitoring sítě je dle mého názoru poměrně slušně vyřešený. Je zde i řešeno monitorování jednotlivých klientů, ale pouze z pohledu administrativní správy. Administrátor se může podívat, jak je linka daného uživatele vytížená, ale samotný uživatel tuto možnost nemá.

5.3

5.3

DP - Pavel Míča - Monitorovací a dohledový systém počítačové sítě

34

DP - Pavel Míča - Monitorovací a dohledový systém počítačové sítě

Diplomová práce Pavla Míči je dostupná k nahlédnutí v knihovně fakulty informačních technologií VUT Brno. Práce se zabývá vytvořením dohledové webové aplikace bezdrátové sítě. Tato síť je tvořena z jednotlivých bezdrátových routerů vytvořených na platformě MikroTik. Dohledová aplikace se stará dle Míči (2008) o vzdálenou konfiguraci MikroTik routerů pomocí SSH připojení a následného čtení dat z těchto zařízení pomocí protokolu SNMP. Ze získaných dat tato aplikace upozorňuje administrátora sítě na případné chyby, jako je například snížení signálu na bezdrátovém spojení mezi jednotlivými routery. Dále je v této aplikaci monitorován přenos dat mezi jednotlivými routery. K tomuto účelu je využit program RRD tool, který ukládá získaná data do RRD souborů. Následně jsou z těchto souborů vytvářeny grafy přenosových rychlostí pro jednotlivá rozhraní MikroTik routerů. Tyto grafy jsou vygenerovány jako PNG obrázky, které jsou posléze zobrazeny pomocí jazyka PHP ve webové aplikaci. Přínosem této práce je vytvoření dohledové aplikace sítě využívající program RRD Tool. Bohužel tato práce již neobsahuje vysvětlení jednotlivých pojmů při použití právě RRD Toolu. Je zde vysvětleno, jak vypadá například příkaz RRD Create, ale nejsou zde popsány jednotlivé parametry příkazu tak, aby bylo naprosto zřejmé co jednotlivý parametr ve skutečnosti znamená. Tato aplikace je sice vytvořena pro administrátorský dohled sítě, ale dokládá možnost použití RRD Toolu pro webové aplikace. Na základě těchto informací víme, že je možné vytvořit vlastní webovou aplikaci, která by splňovala uživatelské požadavky této práce.

6

6

NÁVRH ŘEŠENÍ

35

Návrh řešení

Při návrhu řešení této práce je potřeba si uvědomit její uživatelské požadavky. Ty nám říkají, že je potřeba nasadit aplikaci pro koncové zákazníky poskytovatele internetu, která zajistí výpis grafů pronajímaných síťových linek jednotlivým zákazníkům sítě. Jednotlivé grafy vytížení síťových linek budou složeny z funkce přijatých a z funkce odeslaných dat zákazníkem. Tyto funkce budou zachyceny v grafu hodnot, kde osa x bude reprezentována časem a osa y bude reprezentována rychlostí vytížení síťové linky v Mbit/s. Jednotlivé grafy vytížení síťových linek mají být prezentovány jednotlivých klientům tak, že každý klient sítě se bude moci připojit do webové aplikace, ve které shlédne pouze svůj graf vytížení pronajaté linky. Při návrhu řešení je dále potřeba zahrnout fakt, že informace o jednotlivých klientech sítě budou získávána z MikroTik routeru pomocí SNMP komunikace. Pomocí právě MikroTik routeru je zajištěno vytváření jednotlivých PPPoE spojení pro všechny klienty, kteří se připojují k síti internet. Ve chvíli, kdy se zákazník sítě připojí pomocí PPPoE k Mikrotik routeru, je na něm automaticky vytvořeno nové rozhraní, přes které bude probíhat komunikace. Toto rozhraní je potřeba monitorovat na základě jeho popisu (description), a nikoli pomocí jemu přiřazené OID hodnoty. OID hodnota je totiž generována dynamicky, a mohlo by se stát, že uživatel, který byl připojen k síti na rozhraní s OID, by se podruhé mohl připojit s jiným. Z tohoto důvodu nelze přesně určit na základě OID hodnot, kterému uživateli odpovídá jednotlivé rozhraní, a proto je nutné využít popisů jednotlivých PPPoE rozhraní, ve kterých jsou obsažena jednotlivá uživatelská jména klientů sítě. Dále navrhované řešení musí zajistit co nejjednodušší správu aplikace tak, aby bylo možné snadno zahájit monitorování jednotlivých klientů sítě a také, aby bylo snadno nastavitelné omezení výpisu grafů využití síťové linky jen náležitému uživateli. Z tohoto důvodu není možné využít velké množství aplikací, jako například Cacti, které by dokázalo monitorovat zadanou síť, ale z hlediska nastavení jednotlivých klientů sítě by nasazení bylo velmi časově náročné. Při analýze stávajících produktů jsem nenalezl žádnou dostupnou aplikaci, která by řešila nejen možnost monitorování PPPoE rozhraní na platformě MikroTik, ale i výpis grafů jednotlivým zákazníkům sítě, při její časové nenáročné správě. Z tohoto důvodu jsem se rozhodl vytvořit vlastní aplikaci na sledování využití rychlosti síťových linek jednotlivých uživatelů sítě, která bude výše zmíněné požadavky zahrnovat. Navrhovaná aplikace bude zajišťovat čtení, zpracování a uchovávání dat ze zařízení MikroTik. Následně z uchovávaných hodnot bude aplikace schopna přes webové

6.1

I. celek: Sběr dat ze zařízení MikroTik a tvorba RRD souborů

36

rozhraní prezentovat jednotlivým uživatelům sítě grafy vytížení jejich síťových linek. K ukládání získaných hodnot a k tvorbě jednotlivých grafů bude tato aplikace využívat program RRD Tool. Aplikaci bychom mohli logicky rozdělit na dva celky, které mezi sebou budou úzce spolupracovat. Prvním celkem bude program, jenž bude zajišťovat čtení dat ze zařízení MikroTik a ukládání těchto dat do RRD souborů. Druhým celkem bude webová aplikace, která bude jednotlivým uživatelům sítě vytvářet a prezentovat grafy vytížení jejich síťových linek. Nákres principu této aplikace můžeme vidět na obrázku 9.

Obrázek 9: Návrh principu aplikace a její komunikace s okolními prvky

6.1

I. celek: Sběr dat ze zařízení MikroTik a tvorba RRD souborů

První celek aplikace se tedy bude starat o čtení dat ze zařízení MikroTik pomocí SNMP komunikace. Z následně získaných dat aplikace vytvoří nebo aktualizuje RRD soubory, které budou použity pro uchovávání získaných hodnot. SNMP komunikace Sběr veškerých dat bude zajištěn SNMP komunikací s routerem MikroTik. Při SNMP komunikaci bude aplikace požadovat získání hodnot o veškerých aktivních rozhraních, které budou dostupné na routeru MikroTik. Z těchto rozhraní budou čerpána

6.2

II. celek: Webová aplikace pro tvorbu a prezentaci grafů pro uživatele

37

data o jejich popisu a počtu přenesených bajtů tekoucích do a z rozhraní. Informace o počtu přenesených bajtů budou získány pomocí hodnot jednotlivých čítačů (counters), které počítají celkový počet přenesených bajtů. Na základě popisu jednotlivých rozhraní budeme moci identifikovat jednotlivé uživatele sítě. Popis každého rozhraní, které je vytvořené pro jednotlivé PPPoE uživatele se skládá z příznaku, že se jedná o PPPoE rozhraní a z uživatelského jména, pod kterým se klient připojuje na síť. Uživatelské jméno je jedinečné pro každého klienta sítě a proto můžeme každého klienta jednoduše identifikovat. Komunikace se zařízením MikroTik bude probíhat přes protokol SNMPv2, protože vyšší protokol není na zařízení podporován. Tvorba RRD souborů Následně ze získaných dat vytvoříme nebo aktualizujeme jednotlivé RRD soubory, které budou příslušet jednotlivým uživatelům sítě. Názvy RRD souborů budou odpovídat uživatelským jménům využívající PPPoE spojení. Do těchto RRD souborů budou ukládány informace o počtu přenesených dat na jednotlivých aktivních rozhraních. Tato sekce se dále bude starat i o RRD soubory uživatelů, které v dané chvíli nebudou aktivně připojeni k síti. Pro nepřipojené uživatele na MikroTik routeru nebude vytvořeno aktivní PPPoE rozhraní, a proto nebude možné v daný okamžik získat informace o přenesených datech. RRD soubory neaktivních uživatelů budeme aktualizovat také, ale s hodnotou reprezentující nula přenesených bajtů. Pokud bychom tak neučinili, u těchto uživatelů by v grafech mohla být vypsána mezera mezi získanými daty a graf by se mohl stát méně čitelným.

6.2

II. celek: Webová aplikace pro tvorbu a prezentaci grafů pro uživatele

Druhý celek bude přímo komunikovat s jednotlivými uživateli sítě pomocí webové aplikace. Tato aplikace autentizuje jednotlivé uživatele, pro které vygeneruje a zobrazí grafy vytížení síťové linky. Autentizace uživatele Každý uživatel sítě bude při vstupu do aplikace požádán o autentizaci na základě uživatelského jména a hesla. V této částí aplikace bude využito faktu, že poskytovatel internetového připojení má uložené veškeré informace o svých klientech v adresářové službě Microsoft Active Directory. Tato adresářová služba je využita i pro

6.3

Správa nevyužívaných RRD souborů

38

získávání informací pro tvorbu jednotlivých PPPoE spojení na routeru MikroTik. Při ověření nového PPPoE spojení je požadováno uživatelské jméno a heslo, které musí odpovídat údajům získaných právě z této adresářové služby. Proto můžeme využít stejného postupu při autentizaci jednotlivých uživatelů a pomocí protokolu LDAP ověřit každého klienta vstupujícího do webové aplikace. Tvorba a prezentace grafů pro přihlášeného uživatele Po ověření uživatele budou pomocí RRD Toolu vytvořeny grafy využití jeho síťové linky pro různá časová období. Tato časová období budou pro lepší demonstraci vytížení linky následující. Poslední hodina, posledních šest hodin, poslední den, poslední týden a poslední měsíc. Tyto grafy budou dynamicky vytvořeny jako jednotlivé obrázky, které budou předány na webovou stránku. Obrázky nebudou nikde ukládány a budou přímo zobrazeny na webové stránce. Takto vytvořené obrázky budou reprezentovat grafy hodnot tak, aby uživatel mohl vidět reálné vytížení své linky a srovnat je s dohodnutou rychlostí připojení k internetu. Tvorba a prezentace grafů pro administrátora sítě Ve chvíli, kdy se připojí do webové aplikace administrátor sítě, bude mít na výběr, pro kterého zákazníka sítě chce zobrazit vytížení síťové linky. Postup posléze bude stejný, jako u přihlášeného uživatele.

6.3

Správa nevyužívaných RRD souborů

Aby byl zajištěn bezúdržbový chod aplikace, a aby na tuto aplikaci nebyly kladeny požadavky z hlediska lidského faktoru při jejím provozu, bude její další částí správa nevyužívaných RRD souborů. Tato část se bude starat o již vytvořené RRD soubory, u kterých bude kontrolovat, zda jsou využívané. V případě, že jejich poslední využití, neboli poslední aktivita na lince bude delší než jeden měsíc, budou odstraněny. Tím bude zaručeno, že když nějaký uživatel sítě přestane využívat služeb internetového poskytovatele, bude automaticky odebrán i z aplikace pro sledování stavu síťových linek.

7

IMPLEMENTACE ŘEŠENÍ

7

39

Implementace řešení

Kapitola implementace se zabývá postupem vytvoření navrhovaného řešení. V této kapitole je uveden postup při vytváření aplikace pro monitorování jednotlivých síťových uživatelů využívající PPPoE spojení k routeru MikroTik a následný postup při generování a prezentaci grafů využití síťových linek pro jednotlivé uživatele sítě. Jak je zmíněno v návrhu řešení, můžeme implementaci aplikace rozdělit na dvě nezávislé části. První částí popsanou v implementaci je postup při vytváření skriptu pro sběr dat ze zařízení Mikrotik a následná tvorba RRD souborů. Druhou částí popsanou v implementaci řešení je popis tvorby samotné webové aplikace, která bude komunikovat přímo s jednotlivými zákazníky sítě, vytvářet pro ně grafy vytížení jejich síťové linky a prezentovat je na webové stránce. Zde uvedené návody a skripty jsou vytvořeny pro platformu Linux CentOS 6. Níže uvedené zdrojové kódy by měly být plně funkční i na jiných platformách včetně Windows, a to pouze za předpokladu jiného postupu při instalaci využívaných programů a modulových balíčků.

7.1

Implementace sběru dat ze zařízení Mikrotik a tvorby RRD souborů

Tato část aplikace bude napsána jako skript programovacího jazyka Perl. Volba tohoto programovacího jazyka byla zvolena v návaznosti na použití programu RRD Tool, který budeme používat pro tvorbu a naplnění RRD souboru. RRD Tool při instalaci dodá do programovacího jazyka Perl své moduly, kterými můžeme jednoduše ovládat jednotlivé funkce RRD Toolu. Níže popsaný postup komunikuje pomocí protokolu SNMP se zařízením MikroTik, ze kterého získá potřebná data, která posléze uloží do RRD souborů. Tento skript se musí každou minutu spouštět, aby sbíral data ze zařízení MikroTik a jimi aktualizoval příslušné RRD soubory. Toto spouštění je možné zabezpečit pomocí spuštění skriptu jako démon, kdy po každém vykonání skriptu bude program pomocí metody sleep na minutu uspán a následně se znovu provede. Dále je možné tento skript každou minutu spouštět programem CRON, kdy skript se provede a ukončí. Díky tomu, že tento skript je poměrně jednoduchý a časově není velmi náročný, tak by se nemělo stát, že by délka jeho vykonávání byla větší než jedna minuta. Z tohoto důvodu se nemusíme obávat, že by byl skript spuštěn vícenásobně a opakované spouštění aplikace zajistíme právě programem CRON.

7.1

Implementace sběru dat ze zařízení Mikrotik a tvorby RRD souborů

40

Instalace komponent pro skript sběru dat a tvorby RRD souborů Pro SNMP komunikaci s MikroTik routerem bude využit rozšiřující modul Perlu Net::SNMP. Tento modul a jeho instalace je popsána v kapitole Popisu technologického aparátu. K zajištění instalace tohoto balíčku využijeme program CPAN Minus, ve tvaru cpanm Net::SNMP. Následující potřebnou komponentou je program RRD Tool, který zajišťuje tvorbu RRD souborů a následné vytváření grafů vytížení síťových linek. Při instalaci tohoto programu doporučuji se vyvarovat návodu uveřejněném v dokumentaci RRD Toolu nebo instalaci pomocí balíčkovacího systému yum. RRD Tool je zmíněnými způsoby uložen na disk, ale ne v kompletní verzi s rozšiřujícími moduly jazyka Perl. Doporučený postup pro instalaci je následující. Pomocí balíčkovacího systému yum nainstalujeme všechny závislé programy programu RRD Tool. Dále stáhneme archív RRDToolu, který rozbalíme, zkonfigururujeme a nainstalujeme ručně. Sada těchto příkazů je zobrazena v příloze A. Instalaci můžeme ověřit spuštěním samotného RRD Toolu nebo spuštěním testovacího souboru dostupného ve složce /opt/rrdtool-1.4.7/share/rrdtool/examples. SNMP komunikace se zařízením MikroTik Čtení dat ze zařízení MikroTik je zabezpečeno pomocí SNMP protokolu. Abychom mohli přenášet SNMP data z MikroTik routeru do této aplikace, musíme tuto komunikaci na MikroTik routeru předem povolit. Je potřeba spustit program Winbox pro správu MikroTiku. Kliknout na záložku IP -> SNMP a tlačítkem ’+’ přidat novou komunitu (SNMP community), kterou je zapotřebí pojmenovat monitoring. Této komunitě dále přiřadíme adresu serveru, na kterém bude uložena aplikace pro čtení potřebných dat. Tlačítkem SNMP Settings ověříme, zda je SNMP protokol vůbec povolen. Tento proces je zobrazen na obr. 10. K SNMP komunikaci ve skriptu pro sběr dat je využit modul Net::SNMP, který se stará o zasílání a přijímání jednotlivých SNMP zpráv. Tento modul zavedeme do vytvářeného skriptu a vytvoříme pomocí metody session novou relaci se zařízením MikroTik. use Net :: SNMP; ($session , $error ) = Net ::SNMP -> session ( Hostname => '192.168.1.2 ', Version => 'snmpv2c ', Community => 'monitoring '); die " session error : $error " unless ( $session );

7.1

Implementace sběru dat ze zařízení Mikrotik a tvorby RRD souborů

41

Obrázek 10: Povolení SNMP protokolu na zažízení MikroTik, zdroj: vlastní

Při vytváření této relace předáme jako parametr IP adresu MikroTik routeru, dále komunitu, kterou jsme vytvořili na routeru a také verzi, přes kterou budeme komunikovat. Tato verze je nastavena jako SNMPv2c. Po vytvoření nové relace se vzdáleným prvkem je zapotřebí požadovat ze vzdáleného zařízení informace o veškerých aktivních rozhraních. Z každého rozhraní je potřeba získat popis rozhraní (descripton) a informace o počtu přenesených bajtů proudících z a do rozhraní. Získaná hodnota počtu přenesených bajtů bude získána ve formě čítačů (couters). Tyto čítače označují, kolik bajtů proteklo za celou dobu přes rozhraní. Získaný popis jednotlivých rozhraní nám umožní identifikovat jednotlivé uživatele sítě. Každý popis PPPoE rozhraní se totiž skládá z příznaku PPPoE linky a uživatelského jména PPPoE klienta (). Samotná komunikace se bude skládat z jednotlivých SNMP zpráv. Pomocí zprávy Get si zažádáme o popis (ifDescr) prvního rozhraní a dále o hodnoty počtu přenesených vstupních (ifInOctets) a výstupních (ifOutOctets) dat tekoucích přes toto rozhraní. Tyto hodnoty identifikujeme podle jedinečných identifikátorů objektů OID, které přiložíme do této zprávy. Pro vyhledání OID hodnot lze využít SNMP Object Navigator dostupný na http://tools.cisco.com/Support/SNMP/public.jsp. Pomocí tohoto nástroje zjistíme, že OID popisu (ifDescr) prvního interfejsu je 1.3.6.1.2.1.2.2.1.2.1. Tato OID hodnota reprezentuje informace o iso(1). org(3). dod(6). internet(1). mgmt(2). mib-2(1). interfaces(2). ifTable(2). ifEntry(1). ifDescr(2).1, kde poslední 1 je číslo

7.1

Implementace sběru dat ze zařízení Mikrotik a tvorby RRD souborů

42

prvního rozhraní. Dále je potřeba získat počet přenesených vstupních bajtů (ifInOctets) - 1.3.6.1.2.1.2.2.1.10.1 a výstupních bajtů (ifOutOctets) - 1.3.6.1.2.1.2.2.1.16.1. Více informací o OID, jeho hodnotách a přístupu k nim naleznete v části SNMP. Zprávou Get dostaneme tedy popis a hodnoty počtu přenesených bajtů na prvním rozhraní. Je ale potřeba získat hodnoty ze všech rozhraní, které jsou dostupné na MikroTik routeru a nejen pouze hodnoty náležící prvnímu rozhraní. K tomuto účelu využijeme zprávu Get next, která si automaticky vyžádá následující hodnotu OID, než je zaslána v odeslané zprávě. Když zašleme zprávu Get Next s hodnotou OID, která bude identifikovat první rozhraní na MikroTik routeru, tak jako odpověď dostaneme zprávu, ve které budou hodnoty, jaké jsou obsaženy na druhém rozhraní. Každou zprávou Get Next budeme tedy dostávat informace o následujícím rozhraní, než jsme již získali. Abychom zjistili v přijaté zprávě ze zařízení MikroTik, pro jaké OID hodnoty nám router zaslal odpověď, využijeme metodu var_bind_names. Tato metoda dokáže zjistit, jaké hodnoty OID jsou v příchozí zprávě obsaženy. Pokud jsme ve zprávě Get next požadujeme OID 1.3.6.1.2.1.2.2.1.2.1, tak po přijetí odpovědi metoda var_bind_names nám řekne, že byla příjmuta zpráva s hodnotou OID 1.3.6.1.2.1.2.2.1.2.2, neboli byla příjmuta informace o druhém rozhraní. Tím, že budeme dále zasílat další zprávy Get Next, dostaneme informace o všech rozhraních. Zprávy Get Next přestaneme zasílat ve chvíli, kdy dostaneme informace o posledním rozhraní, které se na MikroTik routeru nachází. Zde využijeme fakt, že pokud zašleme zprávu Get Next s OID hodnotou, která bude reprezentovat na MikroTik routeru poslední dostupné rozhraní, tak zařízení MikroTik zašle jako odpověď informaci o typu linky prvního rozhraní. My ale tento typ linky již nepotřebujeme číst, a proto přestaneme zasílat další požadavky na zařízení MikroTik. Vzhledem k tomu, že typ linky prvního rozhraní má OID hodnotu 1.3.6.1.2.1.2.2.1.3.1, budeme tedy číst data z MikroTik routeru tak dlouho, dokud při testování přijaté zrávy metodou var_bind_names nedostaneme tuto OID hodnotu. Veškeré přijaté hodnoty, které jsme získali pomocí jednotlivých zpráv uložíme do námi vytvořeného hashe hodnot. Jako klíče hashe budeme definovat jednotlivé popisy rozhraní (uživatelská jména) a příslušné hodnoty hashe pod tímto klíčem budou obsahovat počet přenesených bajtu z (out) a do (in) rozhraní. Tento hash tedy uložíme pro další zpracování. Následující příklad demonstruje pro lepší představu zprávy Get a Get next zaslané přes modul Net::SNMP. Celý algoritmus SNMP komunikace je zobrazen v příloze B. # Vytvoreni SNMP Get request s pozadovanymi OID my @oid = ('1.3.6.1.2.1.2.2.1.2.1 ','1.3.6.1.2.1.2.2.1.10.1 ',

7.1

Implementace sběru dat ze zařízení Mikrotik a tvorby RRD souborů

43

'1.3.6.1.2.1.2.2.1.16.1 '); my $result = $session -> get_request (- varbindlist => \@oid ,); do{ # zaslani dalsi get zpravy vyzadujici nasledujici OID hodnoty $result =$session -> get_next_request (- varbindlist => \@oid ,); # zjisteni OID hodnot ve prijmute zprave @oid = $session -> var_bind_names (); } until ($oid [0] eq '1.3.6.1.2.1.2.2.1.3.1 ');

V případě, kdy není možné navázat SNMP relaci s MikroTik směrovačem je skript pro sběr dat a tvorbu RRD souborů ukončen, aniž by aktualizoval jednotlivé RRD soubory. V této chvíli do RRD souborů je automaticky zapsána neznámá hodnota. V případě výpisu této neznámé hodnoty do grafu RRD Tool sám dopočítá pomocí interpolačních funkcí, jaká hodnota se pravděpodobně má vyskytovat na daném místě v grafu. Tvorba nových RRD souborů Hodnoty, které jsme přes SNMP komunikaci získali do hashe hodnot, nyní zpracujeme pomocí RRD Toolu. Musíme zjistit, zdali při SNMP komunikaci jsme získali informace o rozhraní, které již monitorovaná aplikace zná nebo jsme získali informace o nově přidaném PPPoE rozhraní na routeru Mikrotik. V případě získaných informací o novém PPPoE rozhraní, musíme vytvořit nový RRD soubor, do kterého budeme následně ukládat monitorované hodnoty. V případě, že budou přijata data o již známém monitorovaném rozhraní, budeme pouze aktualizovat příslušný RRD soubor. Postup je tedy následující. Procházíme získaný hash hodnot po jednotlivém rozhraní a v případě, že název rozhraní neodpovídá žádnému existujícímu souboru, vytvoříme nový pomocí příkazu RRDs::create. V opačném případě budeme aktualizovat již vytvořený RRD soubor pomocí příkazu RRDs::update. Dříve, než začneme pracovat s jednotlivými funkcemi programu RRD Tool je potřeba zavést jeho modul do vytvářeného skriptu. Toto zavedení zajistíme následujícími příkazy. use lib qw( /opt/rrdtool -1.4.5/ lib/perl ); use RRDs;

Po zavedení modulu, můžeme začít pracovat s jednotlivými částmi programu RRD Tool. Procházíme získaný hash hodnot a pro každý klíč (uživatelské jméno) testujeme, zdali existuje RRD soubor se stejným názvem jako uživatelské jméno.

7.1

Implementace sběru dat ze zařízení Mikrotik a tvorby RRD souborů

44

Pokud ne, vytvoříme nový RRD soubor pomocí funkce Create programu RRD Tool. V příkazu Create definujeme, že RRD soubor bude uchovávat dvě funkce. Funkci přenesených dat ven z rozhraní a funkci přenesených dat do rozhraní. Využijeme faktu, že RRD Tool má již v sobě definovaný datový typ COUNTER, který zajišťuje bezproblémové ukládání získaných čítačů z SNMP komunikace. Obě funkce v novém RRD souboru budou uchovávat průměrnou získanou hodnotu, a to za několik časových období. Tato časová období jsou zadána z návrhu řešení jako jedna hodina, šest hodin, den, týden a jeden měsíc. Vzhledem k tomu, že potřebujeme co nejpřesnější získané hodnoty pro vypsání v grafech, budeme tato data vkládat do RRD souboru každých 60 sekund. Následně data, která budou uložena v jednotlivých RRA archívech budou uložena každou minutu pro graf jedné hodiny, každé 3 minuty pro graf posledních šesti hodin, každých 5 minut pro graf posledního dne, každých 10 minut pro graf posledního týdne a každých 15 minut pro graf posledního měsíce. Část algoritmu průchodu hodnot hashe získaném při SNMP komunikaci a případném vytvoření nového RRD souboru s požadovanými vlastnostmi můžeme vidět na následujícím příkladu. $rrdfolder = '/ cesta kde jsou ulozeny rrd soubory '; foreach $rrd (keys % hodnoty ) {# pruchod hasem hodnot z~SNMP komunikace kdy klic je název uzivatele if (! -e " $rrdfolder /$rrd.rrd") {# vytvoreni noveho rrd pro $rrd interface ; RRDs :: create " $rrdfolder /$rrd.rrd", "-s~60", "DS:down: COUNTER :120:0:12500000 ", # vytvoreni funkce down "DS:up: COUNTER :120:0:12500000 ", # vytvoreni funkce up "RRA: AVERAGE :0.5:1:60 ", # vytvoreni archivu po dobu 1h "RRA: AVERAGE :0.5:3:120 ", #6 hodin se 120 hodnotami "RRA: AVERAGE :0.5:5:288 ", #1 den s 288 hodnotami "RRA: AVERAGE :0.5:10:1008 ", #1 tyden s 1008 hodnotami "RRA: AVERAGE :0.5:15:2880 "; #1 mesic s 2880 hodnotami } }

Parametr -s 60 nám říká, že RRD soubor bude aktualizován každých 60 vteřin. DS:down:COUNTER:120:0:12500000 znamená, že v RRD souboru se má uchovávat funkce s názvem down, do které budeme ukládat hodnoty čítačů (counter). Hodnota 120 nám říká, že pokud nezaktualizujeme RRD soubor 120 vteřin od

7.1

Implementace sběru dat ze zařízení Mikrotik a tvorby RRD souborů

45

poslední aktualizace bude do něj vložena neznámá hodnota. Následující dvě hodnoty 0:12500000 udávají rozmezí povolených hodnot. Minimální hodnota je nula a maximální 12500000. Tato hodnota udává maximální počet přenesených bajtů na 100 Mbit lince a protože data uložená v RRD souboru jsou v bajtech tak 100000000 / 8. Následně vytvoříme jednotlivé RRA archívy. RRA:AVERAGE:0.5:1:60 říká, že se má vytvořit archív pro průměrnou hodnotu. Dále tento archív bude platný, pokud v něm bude zapsána více než polovina platných hodnot 0,5. Dále tento archív bude uchovávat hodnotu každé aktualizace 1 a to po dobu jedné hodiny 60 (hodnoty vkládané každou minutu, které jsou uchovány v 60 hodnotách proto jedna hodina). Více informací o vytváření RRD souborů je uvedeno v kapitole Analýzy technologického aparátu. Jednotlivé RRD soubory vytvoříme pod názvem přihlašovacího jména každého uživatele. Dále tyto RRD soubory uložíme do složky, kterou předem definujeme. Doporučuji použít složku /var/www/html/snmp. Tato složka bude lehce dostupná při přístupu z webové aplikace, ale při implicitním nastavení bude i dostupná pro jakýkoli přístup ze sítě, pomocí protokolu HTTP. Z tohoto důvodu musíme nastavit omezený přístup k této složce, abychom zakázali přístup ze sítě a povolili pouze přístup z lokálního počítače. Proto je nutné vytvořit v adresáři /etc/httpd/conf.d/ nový soubor pod názvem snmp.conf, který bude obsahovat následující řádky. Order Deny , Allow Deny from all Allow from 127.0.0.1 Allow from localhost

Aktualizace RRD souborů Pokud v získaných hodnotách z SNMP komunikace se nachází rozhraní, pro které již máme vytvořený RRD soubor, tak budeme RRD soubor pouze aktualizovat. Spustíme tedy funkci RRDs::update, které jako parametr předáme název příslušného RRD souboru a také počty přenesených bajtů získaných při SNMP komunikaci. Hodnoty přenesených bajtů jsou sice ve tvaru jednotlivých čítačů (counterů), ale RRD soubor je na přijímání těchto čítačů připraven. Při aktualizaci RRD souboru je počítán rozdíl uplynulé doby mezi nynější a poslední aktualizací a rozdíl stavu jednotlivých čítačů. Z těchto hodnot je následně vypočítáno, kolik bajtů bylo prů-

7.1

Implementace sběru dat ze zařízení Mikrotik a tvorby RRD souborů

46

měrně přeneseno za sekundu. Při naplňování jednotlivých RRD souborů daty je nutné si uvědomit, že klient sítě má prohozené směry komunikace, než jsou uvedené na jednotlivých rozhraních. Pro klienta směr down znamená počet přenesených bajtů směrem k sobě na zařízení, ale pro jednotlivá rozhraní je tento směr reprezentován směrem ven z rozhraní (out). Proto při ukládání do RRD souborů musíme prohodit tyto směry toku dat, kdy počet tekoucích bajtů z rozhraní uložíme jako down a počet tekoucích bajtů do rozhraní uložíme jako up. Příklad uložení získaných hodnot z SNMP komunikace a jejich uložení do RRD souboru je zobrazen níže. RRDs :: update " $rrdfolder /$rrd.rrd","-t", "up:down","N: $hodnoty {$rrd }{'in '}: $hodnoty {$rrd }{' out '}";

Veškeré příkazy pro průchod hodnotami hashe získaného při komunikaci s MikroTik routerem, vytváření nových RRD souborů a jejich aktualizace jsou k dispozici v příloze C. Aktualizace RRD souborů neaktivních uživatelů Je potřeba aktualizovat i RRD soubory uživatelů, kteří nejsou v dané chvíli připojeni k síti. Pokud bychom neaktualizovali tyto RRD soubory, byla by do nich automaticky zapsána neznámá hodnota. My ale víme, že tato hodnota není neznámá, ale že nabývá hodnoty nula přenesených bajtů. Protože jednotlivé RRD soubory jsou aktualizovány čítači, nemůžeme použít funkci RRDs::update s hodnotou nula, ale musíme do nich vložit hodnotu naposledy uloženou do RRD souboru. Abychom zajistili tuto aktualizaci RRD souborů pro neaktivní rozhraní musíme zjistit, jaké RRD soubory jsou aplikaci známé a odečíst od nich veškeré soubory, které byly zpracovány daty ze SNMP komunikace. Po té, co získáme seznam neaktualizovaných RRD souborů získáme pomocí funkce RRD Toolu last poslední zapsané hodnoty do příslušného souboru. Bohužel funkce last z modulu RRDs::last umí vrátit pouze datum poslední aktualizace, nikoli hodnoty naposledy vložené do RRD souboru. Z tohoto důvodu musíme použít program RRD Tool a jeho funkci lastupdate. Program RRD Tool spustíme z tohoto skriptu a jeho výstup následně zpracujeme. Výstup funkce rrdtool lastupdate vrátí text, ve kterém jsou na posledním řádku uloženy poslední vložené hodnoty do RRD souboru oddělené dvojtečkou. Tento výstup tedy zpracujeme a získané hodnoty použijeme ve funkci RRDs::update k uložení nových hodnot. Tento postup je zachycen v příloze D.

7.2

Implementace webové aplikace pro tvorbu a prezentaci grafů

47

Spuštění scriptu pomocí CRON Vytvořený skript nyní musíme spouštět každou minutu tak, abychom zajistili pravidelnou aktualizaci dat. Automatické spuštění zajistíme programem CRON. Pomocí příkazu crontab -e, otevřeme textový editor, do kterého zapíšeme následující hodnotu. * * * * * /snmp/snmp.pl >> /snmp/snmp.log

Tímto způsobem zajistíme pravidelné spouštění vytvořeného skriptu, který je uložen ve složce snmp. Výstup z tohoto skriptu přesměrováváme do souboru snmp.log.

7.2

Implementace webové aplikace pro tvorbu a prezentaci grafů

Webová aplikace, jak bylo zmíněno v návrhu řešení se stará o autentizaci uživatele a následné generování a vypisování grafů. Pro implementaci této aplikace jsem se rozhodl využít jazyk PHP. Po připojení uživatele do této webové aplikace je zobrazena titulní stránka, která žádá o ověření uživatele na základě uživatelského jména a hesla. Ověření je zajištěno protokolem LDAP oproti adresářové službě MS Active Directory, ve které jsou uloženy informace o veškerých klientech sítě. Následně je rozhodnuto, který z uživatelů se připojil k aplikaci. V případě běžného uživatele sítě jsou zobrazeny na webové stránce grafy vytížení jeho síťové linky. V případě, že do aplikace se připojil správce sítě, je mu dána možnost výběru uživatele, pro kterého chce zobrazit grafy využití síťové linky. Instalace nutných balíčků Pro zprovoznění webové aplikace je potřeba nainstalovat webovou službu Apache a interpretor jazyka PHP. Toto je možné zajistit pomocí balíčkovacího systému yum příkazem yum install httpd php. Z důvodu autentizace jednotlivých uživatelů sítě oproti MS Active Directory pomocí protokolu LDAP musíme využít rozšiřující modul jazyka PHP, který bude toto ověření zprostředkovávat. Z tohoto důvodu byl zvolen modul PHP LDAP, který je možné nainstalovat rovněž pomocí balíčkovacího systému yum a to příkazem yum install php-ldap. Autentizace uživatelů Při vstupu uživatele do aplikace se ověří na základě identifikátoru relace session, zda je uživatel již přihlášen nebo zdali vstupuje poprvé. V případě prvního vstupu

7.2

Implementace webové aplikace pro tvorbu a prezentaci grafů

48

je přesměrován tok dat na skript login.php, který na obrazovku vypíše jednoduchý formulář obsahující textové pole pro zápis uživatelského jména a hesla. Po odeslání formuláře jsou pomocí globálních proměnných $_POST[’username’] a $_POST[’password’] předány informace o uživatelském jménu a heslu do skriptu login.php. Skript ověří obsah těchto proměnných pomocí ereg("[̂A-Za-z0-9]", $_POST['username']), zda obsahují pouze povolené znaky. V případě, že by do proměnné byl zadán nepovolený text, skript vyžádá nové zadání hodnot. Toto ověření obsahu proměnných zabraňuje vložení nevhodného kódu do aplikace, který by následně mohl změnit její funkčnost. Pokud je uživatelské jméno a heslo zadáno ve správném tvaru skript login.php vytvoří pomocí příkazu ldap_connect() novou relaci s adresářovou službou Active Directory, pomocí které budeme ověřovat jednotlivé uživatele. Do funkce ldap_connect předáme adresu serveru, na kterém je spuštěna služba Active Directory. Po vytvoření relace využijeme funkci ldap_bind(), pomocí které ověříme, zda přihlašovaný uživatel má vytvořený účet v adresářové službě s příslušným heslem. Funkci ldap_bind() předáme parametry relace, kterou jsme vytvořili pomocí ldap_connect(), dále předáme doménové jméno požadované adresářové služby a uživatelské jméno s heslem, získané z proměnných $_POST. Příklad připojení k adresářové službě je zobrazen na následujícím příkladu. $ldapconn = ldap_connect () $ldaprdn = " spolecnost "."\\". $_POST [" username "]; $ldapbind = ldap_bind ($ldapconn , $ldaprdn , $_POST [" password "]); if ( $ldapbind ) { # uspesne overeni uzivatele }else {# overeni se nezdarilo }

V případě úspěšného ověření uživatele uložíme do globální proměnné $_SESSION ['username'] uživatelské jméno a nastavíme $_SESSION['loggedin'] = 1, jako příznak ověřeného uživatele. V případě, že uživatel bude do aplikace vstupovat pod identifikátorem relace, pro které je na serveru nastavena hodnota loggedin = 1, bude považován jako ověřený. Dále z hlediska vyššího zabezpečení a nemožnosti zcizení identifikátoru relace regenerujeme ID relace pomocí příkazu session_regenerate_id(). Jako poslední příkaz v případě úspěšného ověření uživatele je přesměrování na úvodní stránku aplikace pomocí vyslání hlavičky s adresou index.php (header("Location: ./index.php"). Soupis veškerých příkazů ověření uživatele oproti MS Active Directory a nastavení vlastností relace je dostupný v příloze E. Vzhledem k tomu, že využíváme přihlášení uživatelů na bázi relací, je důležité, aby se v konfiguračním souboru PHP serveru zabránilo načí-

7.2

Implementace webové aplikace pro tvorbu a prezentaci grafů

49

tání proměnné session z jiného místa, než je uloženo na serveru. Nastavíme tedy session.use_only_cookies aby bylo aktivní a také nastavíme register_globals na vypnuté, aby nebylo možné podstrčit parametr globální neinicializované proměnné do skriptu neoprávněně. Tvorba grafů pro běžného uživatele Po té, co je uživatel po úspěšném přihlášení přesměrován na úvodní stránku, je zjištěno na základě uživatelského jména předaného v $_SESSION['username'], zdali je považován za správce sítě nebo za běžného uživatele. Rozhodnutí je vytvořeno na základě shody uživatelského jména s jmény spravce nebo administrator. Následně je pro běžného uživatele zavolán skript graph.php, který ověří, zda předávané ID relace připadá přihlášenému uživateli a následně vypíše na obrazovku jednotlivé obrázky reprezentující grafy vytížení jeho síťové linky. Tento výpis je zajištěn vypsáním HTML tagu na stránku. Zdrojová adresa obrázku je dána jako skript grafuj.php, kterému je předán v proměnné $_GET['cas'] časový usek, pro jaký má být graf vytvořen. Skript grafuj.php převezme z proměnné $_SESSION['username'] název uživatele, pro kterého má vytvářet graf hodnot a spustí funkci program RRD Tool Graph. Aby byl zajištěn výstup skriptu grafuj.php ve formě znaků reprezentující obrázek ve tvaru PNG, není možné využít modul RRD Toolu pro jazyk PHP, protože funkce graph tohoto modulu nedokáže vrátit posloupnost požadovaných znaků obsahující obrázek. Z tohoto důvodu je nutné využít funkci system(), která spustí funkci Graph programu RRD Tool na příkazové řádce a její výstup vypíše do PHP skriptu. Funkci RRT Tool Graph spustíme s názvem výstupního souboru nastaveným na ’-’ a parametry nastavující velikost obrázku na 600x80 px (-w 600 -h 80). Jako další parametry předáme popis osy y a popis celého grafu. Osa y je popsána v bitech za sekundu (--vertical-label=bits/s) a popis grafu odpovídá zadanému času v proměnné $_GET['cas'] pomocí parametru --title. Dále je předán název zdrojového RRD souboru, který odpovídá uživatelskému jménu uloženého v proměnné $_SESSION['username']. Z RRD souboru jsou čteny funkce up a down (DEF:up=<username>.rrd:up:AVERAGE), které jsou vynásobeny osmi, jako přepočet z přenesených bajtů za sekundu, získaných z čítačů jednotlivých rozhraní na bity za sekundu (CDEF:upbits=up,8,*), které mají být vypsány v grafu. Následně vypíšeme do grafu jednotlivé přepočtené funkce pomocí parametrů (LINE1:upbits336600:Upload). Ke křivkám dále přiložíme jejich statistické

7.2

Implementace webové aplikace pro tvorbu a prezentaci grafů

50

hodnoty pro maximální, průměrnou a aktuální hodnotu (GPRINT:upbits:'MAX: Max:%5.1lf %s'). Následně, co RRD Tool zpracuje spuštěný příkaz s požadovanými parametry předá výstup (tok znaků reprezentující obrázek) do PHP skriptu, který jej zobrazí jako obrázek. Veškeré příkazy funkce graph.php a grafuj.php jsou zobrazeny v příloze F. Tvorba grafů pro správce sítě V případě, že se do aplikace připojí správce sítě, bude místo skriptu graph.php zavolán skript admingraph.php. Následně je na obrazovku vypsán formulář pro výběr uživatele sítě, pro kterého administrátor požaduje zobrazit grafy vytížení linky. V tomto kroku je využit fakt, že pro každého monitorovaného zákazníka je v této aplikaci vytvořen RRD soubor. Při naplnění jednotlivých možností pro výběr zákazníka je využit cyklus while (false !== (dir("/var/www/html/snmp")->read())), který postupně prochází jednotlivé názvy RRD souborů dostupných ve složce, do které jsou ukládány RRD soubory. Možnosti formuláře jsou posléze naplněny jednotlivými názvy RRD souborů (uživatelskými jmény zákazníků). Po odeslání formuláře s požadovaným uživatelským jménem se vypíší na obrazovku jednotlivé grafy vybraného zákazníka. Postup je stejný jako u výpisu grafů pro běžného uživatele s jediným rozdílem, že jako zdroj obrázku je volán skript admingrafuj.php, který generuje grafy hodnot pro uživatele předaného v proměnné $_SESSION['zakaznik']. Při zpracování formuláře výběru zákazníka uložíme vybraného zákazníka do této proměnné a vygenerujeme graf obdobně, jako pomocí skriptu grafuj.php. Zdrojové kódy souborů admingrafuj.php a admingraph.php jsou zobrazeny v příloze G. Správa nevyužívaných RRD souborů Abychom zajistili nulové nároky z hlediska administrativní správy aplikace je potřeba odstranit nevyužívané RRD soubory. Nepoužívané soubory budou odstraněny, pokud do nich za poslední měsíc nebyla zapsána žádná hodnota. Z tohoto důvodu, je vytvořen skript inactive.pl, který bude procházet všechny vytvořené RRD soubory. Z důvodu, že neexistuje žádná informativní funkce, která by dokázala zjistit a uložit do proměnné průměrnou hodnotu ukládaných hodnot, je potřeba využít program RRD Tool nekorektně. Funkce RRD Tool graph umí vypsat do grafu statistické hodnoty pro jednotlivé definované funkce. My ale potřebujeme získat statistickou hodnotu do skriptu pro správu neaktivních RRD souborů. Z tohoto důvodu zavoláme funkci graph, ve které definujeme, že chceme získat funkci hodnot z příslušného

7.2

Implementace webové aplikace pro tvorbu a prezentaci grafů

51

RRD souboru (DEF:ds=$i:up:AVERAGE) za poslední měsíc a z těchto hodnot získat průměrnou hodnotu (PRINT:ds:AVERAGE:%6.2lf). Dále nebudeme chtít nic vypsat do grafu. V takto použitém příkazu RRD Tool nevrátí vygenerovaný graf, ale pouze hodnotu průměrně přenesených bajtů. Tento postup popsal v internetovém fóru programu RRD Tool Alex Bogaerdt (2006). Spustíme program RRD Tool a jeho výstup zpracujeme na požadovanou průměrnou hodnotu. Pokud tato průměrná hodnota se bude rovnat nule nebo neznáme hodnotě, znamená to, že do RRD souboru nebyla zapsána za poslední měsíc žádná nová hodnota a tento soubor odstraníme. Tento skript pomocí programu CRON budeme pouštět každý měsíc. Jednotlivé příkazy skriptu pro odebrání nevyužívaných RRD souborů jsou zobrazeny v příloze H.

8

OVĚŘENÍ IMPLEMENTACE

8

52

Ověření implementace

Vytvořenou aplikaci je potřeba ověřit, zdali splňuje uživatelské požadavky a zda pracuje korektně. Dále je potřeba ověřit, zda běžný uživatel sítě se dokáže do této aplikace připojit a zobrazit grafy vytížení jeho uživatelské linky.

8.1

Ověření uživatelských požadavků a funkčnosti řešení

Pro ověření funkčnosti této aplikace je zapotřebí vytvořit nového testovacího zákazníka sítě, pro kterého budeme chtít zobrazit grafy vytížení síťové linky. Postup je následující. V adresářové službě Active Directory vytvoříme nového zákazníka sítě pod uživatelským jménem uzivateltest. Následně uživatele pomocí protokolu PPPoE připojíme do sítě. Ve chvíli, kdy se uživatel poprvé připojí k síti, musí monitorovací aplikace automaticky začít sledovat rychlosti připojení tohoto uživatele. Ověříme tedy, zda ve výpisu logu ze snmp.txt se zobrazil řádek s informací o přidání nového monitorovaného rozhraní s názvem uzivateltest. Pro jistotu, ještě ověříme, zdali byl nový RRD soubor, do kterého se budou ukládat informace o přenesených datech, vytvořen ve složce s ostatními RRD soubory. Následně z hlediska testování funkčnosti výpisu grafů zatížíme uživatelskou linku stahováním souboru ze sítě internet tak, aby připojení využívalo svojí maximální rychlost, která je nastavena na 1 Mbit/s. Toto využití rychlosti totiž musí být zachyceno i v grafu aplikace, který se vypíše uživateli. Dříve než zatížíme uživatelskou linku, otevřeme v systému Windows správce zdrojů, ve kterém budeme sledovat záložku síť a graf vytížení síťové linky, abychom ověřili funkčnost a přesnost monitorovací aplikace. V čase 13:36 spustíme stahování souboru ze sítě internet. Vytížení síťové linky dle grafu v monitorovací aplikaci v systému Windows dosahuje po začátku stahování rychlosti okolo 1 Mbit/s. Tento graf je možno vidět na obr. 11. V grafu je zachycen celkový provoz

Obrázek 11: Sledování vytížení sítě v systému Windows

na lince. Dle správce stahování aplikace Firefox byla průměrná rychlost stahování souboru 123 kB/s. Pokud tuto rychlost přepočteme na přenášené bit/s dostaneme

8.1

Ověření uživatelských požadavků a funkčnosti řešení

53

hodnotu 984 kbit/s. V čase 11:40 odpojíme uživatelskou linku od sítě a tím přerušíme stahování souboru. Následně v čase 11:43 opětovně připojíme uživatele k síti a zahájíme nové stahování souboru o velikosti 121 MB ze sítě internet. Konec stahování souboru nastal v čase 11:43. Za 18 minut bylo tedy staženo 121 MB. Pro kontrolu otevřeme vytvořenou aplikaci a ověříme, zda tyto hodnoty byly opravdu naměřeny. V aplikaci přihlásíme uživatele uzivateltest a následně zobrazíme grafy vytížení uživatelské linky. Na obr. 12 je vidět graf za poslední hodinu. Z grafu je patrné, že uživatelská linka byla zatížena stahováním v čase od 11:36

Obrázek 12: Graf rychlosti vytížení linky za poslední hodinu v monitorované aplikaci

do 11:41. Maximální rychlost stahování oscilovala kolem rychlosti 1 Mbit/s. Tato rychlost tedy odpovídá rychlosti naměřené v systému Windows a maximální rychlosti linky. V čase 11:41 je z grafu vidět, že uživatelská linka byla odpojena od sítě. Následně v čase 11:43 se uživatel znovu připojil k síti a začal stahovat soubor do času 12:02, kdy rychlost stahování se opět pohybovala kolem maximální možné rychlosti na lince. Reálné vytížení linky tedy odpovídá hodnotám zobrazeným v grafu aplikace. Zachycené obrazovky postupu připojení k této aplikaci a výpis grafů pro testovacího uživatele můžeme vidět v příloze I. Rovněž je potřeba ověřit možnost, zda správce sítě dokáže shlédnout graf vytížení rychlosti síťové linky pro uživatele sítě. Přihlásíme správce sítě do aplikace . Po přihlášení správce vidí možnost výběru jednotlivých uživatelů sítě, dle jejich uživatelského jména, pro které je možno zobrazit grafy vytížení jejich linky. V tomto případě vybereme uživatele uzivateltest. Na obrazovce se vypíší stejné grafy vytížení síťové linky, jako v předcházející chvíli. Zachycené obrazovky postupu zobrazení grafů správcem pro vybraného uživatele je možno vidět v příloze I. Z hlediska dalšího testování byla uživatelská linka zatížena v čase od 11:40 stahováním souboru o velikosti 1,1 GB. Toto stahování bylo ukončeno v čase 17:33 a linka byla až do 20:52 nevyužívaná. Kolem jednadvacáté hodiny bylo na lince zobrazeno několik internetových stránek. Tuto komunikaci zachycuje obrazovka na

8.1

Ověření uživatelských požadavků a funkčnosti řešení

54

obr. 13, která ukazuje využití aplikace správcem sítě a zobrazení vytížení grafů linky pro uživatele uzivateltest.

Obrázek 13: Grafy vytížení rychlosti linky zobrazené pro správce sítě

Z důvodu otestování automatického odebírání nevyužívaných souborů byl ručně vytvořen RRD soubor, který byl naplněn daty obsahující nula přenesených bajtů za poslední měsíc a byl uložen do složky s ostatními RRD soubory. Následně byl spuštěn skript pro odebrání nevyužitých RRD souborů. Po spuštění skriptu byl vytvořený soubor odstraněn. Tímto krokem byla ověřena funkce automatického odebírání klientů z aplikace pro monitorování. Aplikace tedy dokáže sledovat vytížení linek jednotlivých zákazníků sítě, pro které přes webové rozhraní dokáže zobrazit grafy hodnot reprezentující historii jejich reálné přenosové rychlosti k síti internet. Dále aplikace umožňuje správci sítě zobrazit grafy vytížení uživatelské linky pro vybraného klienta. Implementované řešení tedy splňuje zadané uživatelské požadavky na tuto práci.

8.2

8.2

Oveření uživatelské použitelnosti

55

Oveření uživatelské použitelnosti

Vytvořená aplikace byla testována i z hlediska intuitivnosti ovládání a uživatelské použitelnosti. K tomuto účelu bylo využito testovacího uživatele, bez informatického vzdělání. Tento uživatel měl demonstrovat použití aplikace běžným zákazníkem sítě. Testovacímu uživateli byly předány následující instrukce: ”Připojte se na webovou stránku (název stránky), na které zadejte Vaše uživatelské jméno a heslo, pod kterým se připojujete k síti internet (uzivateltest,heslo123). Následně uvidíte grafy vytížení Vaší linky, které si můžete prohlédnout.”. Testovaný uživatel byl při tomto procesu pozorován, aby se zjistilo, jak aplikaci využívá a které kroky podniká. Veškerý postup práce s aplikací byl uživatel schopen vykonat bez komplikací. Problém ale nastal ve chvíli, kdy byl dotázán, na význam jednotlivých grafů. Uživatel přesně nedokázal vysvětlit, jaké hodnoty jsou v grafech zachyceny a co znamenají. Z tohoto důvodu byla pod grafy hodnot zobrazena legenda v následujícím znění: ”Zobrazené grafy zachycují historii vytížení Vaší uživatelské linky. Modrá funkce (Download) zachycuje, jakou rychlostí jste přijímal data ze sítě internet (zobrazoval WWW stránky, stahoval soubory). Zelená funkce (Upload) zachycuje, jakou rychlostí jste odesílal data. Námi poskytovaná rychlosti připojení je udávána v bitech za sekundu (bit/s). Při stahování souborů ze sítě internet Váš prohlížeč zobrazuje rychlost stahování v přenesených bajtech za sekundu (kB/s nebo MB/s). Při přepočtu na bity za sekundu je potřeba tuto rychlost vynásobit osmi (stahování rychlostí 100 kB/s = 800 kbit/s). Pokud se Vám zdá, že Vaše rychlost připojení k síti internet je pomalá, prosím zavřete všechny programy, které by mohly využívat připojení na síť a nechte počítač se zapnutým připojením 5 minut volně běžet. Následně prosím znovu shlédněte graf vytížení Vaší linky. Pokud v posledních pěti minutách byla tato linka vytížena větší rychlostí jak 80 až 100 kbit/s, je velmi vysoká pravděpodobnost, že Váš počítač obsahuje nějaký škodlivý software, který využívá Vaše připojení k síti internet. V tomto případě prosím nainstalujte antivirový program nebo využijte služeb odborníka.”.

9

9

EKONOMICKÉ ZHODNOCENÍ

56

Ekonomické zhodnocení

Dle Konečného (2007, s. 50) lze výši zisku ovlivnit faktory, které působí na náklady nebo na výnosy podniku. Tyto faktory jsou zejména spokojenost zákazníků, snížení fixních a variabilních nákladů, zrychlení doby obratu oběžného majetku nebo změna struktury prodávaných výrobků. Implementovaná aplikace dokáže ovlivnit ukazatel spokojenosti zákazníků a také dokáže snížit variabilní náklady. Snížením variabilních nákladů se myslí snížení nákladů potřebných při komunikaci se zákazníky ve věci reklamace jemu poskytovaných služeb. Snížením variabilních nákladů na každého zákazníka je možné dosáhnout snížením očekávané doby reklamace u každého klienta sítě. Dle statistik Eurostatu (2011) o Informační společnosti lze zjistit, že podíl počtu zavirovaných počítačů v České republice je 27 %. To znamená, že na 100 klientů sítě připadá 27 klientů, u kterých je využíváno připojení k síti internet nějakou škodlivou aplikací. Klient se zavirovaným počítačem subjektivně pociťuje zpomalenou rychlost připojení a proto žádá o reklamaci této služby. Je očekáváno, že alespoň 20 zákazníků z každého sta klientů bude chtít za rok reklamovat tuto službu. Průměrná doba reklamace před zavedením této aplikace trvala minimálně jednu hodinu a náklady na řešení reklamace byly 250 Kč (hodinová sazba technika sítě) plus případné náklady na provoz automobilu v případě výjezdu technika za zákazníkem. Pokud zanedbáme náklady na automobil, protože nebyl využitý, ke každému výjezdu, dostaneme hodnotu variabilních nákladů za rok 5000 Kč (250 Kč * 20 reklamací ročne) na 100 klientů sítě. Po nasazení aplikace se očekává snížení doby jedné reklamace z hodiny na deset minut. Správce sítě totiž bude moci využít monitorovací aplikaci a podívat se, zda na lince je vidět její maximální vytížení. V případě nejasností může správce sítě poprosit klienta, aby nechal 5 minut počítač volně běžet s aktivním připojením na internet. Pokud se na lince bude vyskytovat provoz, tak správce sítě může jednoduše usoudit, že na zákazníkově počítači se nalézá nějaký škodlivý software a jako důkaz nasměruje zákazníka sítě na webovou aplikaci. Náklady tedy na jednu reklamaci se sníží z 250 Kč na 42 Kč (10 minut z hodinové mzdy technika). Variabilní náklady na 100 klietů sítě budou tedy 840 Kč (42 Kč * 20 reklamací ročně na 100 zákazníků). Rozdíl variabilních nákladů před a po zavedení monitorovací aplikace je 4160 Kč na každých 100 klientů sítě a to v případě, že jsme zanedbali náklady na automobil při řešení těchto reklamací. Z důvodu poměrně nízkého očekávaného využití této aplikace a jejím nízkým nárokům na systémové požadavky, může vytvořená aplikace být provozována na

9

EKONOMICKÉ ZHODNOCENÍ

57

nějakém již vytvořeném málo využívaném serveru. V případě, že takto aplikaci nasadíme do provozu, budou náklady na zavedení a počáteční otestování aplikace asi 500 Kč (dvě hodiny práce technika sítě). Dále po nasazení aplikace je potřeba zajistit kontrolu jejího stavu. Plánovaná kontrola by měla být vykonána týden po zavedení do provozu a následně po prvním měsíci provozu aplikace. Čas potřebný k jedné kontrole je odhadován na půl hodiny. Celkové náklady na nasazení a otestování aplikace jsou tedy 750 Kč (2 * 0,5 h * 250 Kč/h + 500 Kč na nasazení aplikace). Protože aplikace bude umístěna na již fungující server sítě, můžeme říci, že náklady spojené s provozem serveru můžeme zanedbat. Provoz aplikace ale bude kontrolován, zda pracuje korektně. Tato kontrola je plánována každé čtvrtletí a její plánovaná délka je odhadována na půl hodiny práce technika sítě (125 Kč). Náklady na roční kontrolu aplikace jsou tedy 500 Kč (4 * 125 Kč). Celkové náklady na zavedení a první rok provozu aplikace, kdy je předpokládán její bezproblémový provoz jsou 1250 Kč. V případě, že poskytovatel sítě má 300 klientů bude snížení nákladů (přínosy) této aplikace dosahovat hodnoty 12400 Kč (4160 Kč * 3). Ve chvíli, kdy porovnáme přínosy s náklady na tuto aplikaci zjistíme, že aplikace se začne vyplácet již 37 den od zavedení do provozu. Tento čas byl dopočítán z podílu ročních nákladů oproti ročním přínosům to celé vynásobeným počtem dnů v roce (1250 Kč / 12400 Kč). Faktor spokojenosti zákazníka se dokáže zvýšit poskytnutím důkazu (grafu zachycené rychlosti provozu), že jeho linku opravdu využívá nějaký škodlivý software, o kterém on sám si není vědom. Zákazník sítě se totiž nebude cítit být odbytý při řešení reklamace. Pokud zákazník se v budoucnu dostane do opětovné situace, kdy bude mít problém s rychlostí připojení k síti internet, bude mít možnost si nejdříve sám ověřit stav, zda jeho linka není zatížena škodlivým softwarem pomocí vytvořené webové aplikace. Tím zvýšíme spokojenost zákazníka, protože si bude moci tento stav sám odstranit a to bez komunikace se správcem sítě.

10

10

ZÁVĚR PRÁCE

58

Závěr práce

Implementované řešení dokáže poskytnout jednotlivým zákazníkům sítě webovou aplikaci, která zachycuje vytížení rychlosti jejich připojení k síti internet. Vytvořená aplikace je zejména přínosná, ve chvílích, kdy zákazník sítě má pocit, že jemu poskytovaná rychlost připojení k síti internet je pomalá a nedosahuje hodnot dohodnutých ve smlouvě. Ve chvíli případné reklamace služeb dokáže jak zákazník, tak správce sítě shlédnout ve vytvořené aplikaci grafy reálného vytížení uživatelské linky, a rozhodnout, zda linka komunikuje skutečně rychlostí uvedené ve smlouvě nebo je problém na straně poskytovatele služeb. Díky této aplikace se předpokládá snížení nároků na čas strávených při neoprávněných reklamacích zákazníky sítě, kdy připojení zákazníka využívá nějaký škodlivý software.

11

11

LITERATURA

59

Literatura

Banzal, S. Data and Computer Network Communication. New Dehli: Firewall media, 2007. 776 s. ISBN: 978-81-318-0139-0.. Bouška, P. SNMP Simple Network Management Protocol [online]. 2006. [cit. 5.2.2012]. Dostupné na internetu: http://www.samuraj-cz.com/clanek/snmp-simple-network-managementprotocol/. Bogaerdt, A. RRDtool Users Mailinglist - RRDtool fetch simple perl [online]. 2006. [cit. 19.4.2012]. Dostupné na internetu: oss.oetiker.ch/rrdtool/forum.en/html#nabble-td1072180. Brenner Alan, Wall Matthew a kolektiv. Nagiosgraph [online]. 2012. [cit. 27.2.2012]. Dostupné na internetu: http://nagiosgraph.sourceforge.net/. Eurostat. Information society statistics [online]. 2011. [cit. 8.5.2012]. Dostupné na internetu: http://epp.eurostat.ec.europa.eu/statistics_explained/index.php/ Information_society_statistics. Galstad, a kolektiv. Nagios Core [online]. 2012. [cit. 27.2.2012]. Dostupné na internetu: http://www.nagios.org/projects/nagioscore. Ian, B. a kolektiv. Cacti [online]. 2012. [cit. 27.2.2012]. Dostupné na internetu: http://www.cacti.net. Juniper Networks. Learning Portal [online]. 2010. [cit. 29.4.2012]. Dostupné na internetu: https://learningportal.juniper.net/juniper/. Kleinman S. Manage CPAN modules with CPAN Minus [online]. 2010. [cit. 11.4.2012]. Dostupné na internetu: www.library.linode.com/linux-tools/utilites/cpanm#sph_installing -cpan-minus. Kocman, J. Jak na démona Cron [online]. 2002. [cit. 15.4.2012]. Dostupné na internetu: http://interval.cz/clanky/jak-na-demona-cron/. Konečný, M. Podniková ekonomika. Akademické nakladatelství CERM, 2007. 184 s. ISBN: 978-80-214-3465-3. .

11

LITERATURA

60

Kozierok, M. Charles. TCP/IP Guide. San Francisco: No Strach Press, 2005. 1616 s. ISBN: 978-159327-047-6.. Leskiw, A. What is SNMP & How Do I Use line]. 2012. [cit. 19.4.2012]. Dostupné na http://www.networkmanagementsoftware.com/snmp-tutorial.

It? [oninternetu:

Long, J. Storage networking protocol fundamentals. Indianapolis: Cisco Press, 2006. 552 s. ISBN: 1-58705-160-5.. Mamakos, L a kol. RFC 1661 A Method for Transmitting PPP Over Ethernet (PPPoE) [online]. 1999. [cit. 3.2.2012]. Dostupné na internetu: http://www.ietf.org/rfc/rfc2516.txt. Mansfiel, D., Kenneth C. a Antonakos, L. James. Computer Networking From LANs to WANs: Hardware, Software and Security. Boston: Course Technology, 2009. 949 s. ISBN: 1-423-90316-1.. Matúšů, J. Monitorování stavu rozsáhlých sítí, 2008 . Diplomová práce. Univerzita Tomáše Bati ve Zlíně, Fakulta aplikované informatiky. Vedoucí práce Tomáš Dulík. Míča, P. Monitorování Monitorovací a dohledový systém počítačové sítě, 2008 . Diplomová práce. Vysoké učení technické, Fakulta informačních technologií. Vedoucí práce Roman Trchalík. Oetiker, T. RDD Tool [online]. 2012A. [cit. 28.2.2012]. Dostupné na internetu: http://oss.oetiker.ch/rrdtool/index.en.html. Oetiker, T. The Multi Router Traffic Grapher [online]. 2012B. [cit. 28.2.2012]. Dostupné na internetu: http://oss.oetiker.ch/mrtg/. Paessler, D. PRTG Network monitor [online]. 2012. [cit. 29.2.2012]. Dostupné na internetu: http://www.paessler.com/prtg/. Rasnake, M. Linux Toolbox: crontab [online]. 2012. [cit. 15.4.2012]. Dostupné na internetu: http://www.coffeemonk.com/2012/04/linux-toolbox-crontab/. Schmidt, K. a Mauro, D. Essential SNMP, 2nd Edition. Sebastopol: Reilly Media, 2005. 460 s. ISBN: 0-596-00840-6..

11

LITERATURA

61

Schroder, C. Linux - kuchařka administrátora sítě. Brno: Computer Press, 2009. 608 s. ISBN: 978-80-251-2407-9.. Simpson, W. RFC 1661 The Point-to-Point Protocol (PPP) [online]. 1994. [cit. 29.1.2012]. Dostupné na internetu: http://www.ietf.org/rfc/rfc1661.txt. Skřivánek, L. Simple Network Management Protocol [online]. 2007. [cit. 5.2.2012]. Dostupné na internetu: http://skriv.wz.cz/MPS/SNMP/index.html. Slávik, B. Využití speciálního operačního systému ”Mikrotik RouterOS”v sítích lokálních ISP” [online]. 2007 [cit. 2012-03-02]. Bakalářská práce. Jihočeská univerzita v Českých Budějovicích, Pedagogická fakulta. Vedoucí práce Michal Šerý. Dostupné z: . Town, David M.. Net::SNMP [online]. 2010. [cit. 12.4.2012]. Dostupné na internetu: http://search.cpan.org/d̃town/Net-SNMP-v6.0.1/lib/Net/SNMP.pm. Urban, T. Cacti 0.8 Beginner’s Guide. Birmingham: Packt Publishing Ltd., 2012. 348 s. ISBN: 978-1-849513-92-0..

Přílohy

A

A

POSTUP INSTALACE PROGRAMU RRD TOOL

63

Postup instalace programu RRD Tool

Většinu příkazů je potřeba vykonat jako root. wget http :// oss. oetiker .ch/ rrdtool /pub/rrdtool -1.4.7. tar.gz tar zxvf libpng -1.2.18. tar.gz cd rrdtool -1.4.7 yum install cairo - devel libxml2 - devel pango -devel pango libpng -devel ./ configure make make install

B

B

SNMP KOMUNIKACE SKRIPTU PRO SBĚR DAT PRO RRD SOUBORY

64

SNMP komunikace Skriptu pro sběr dat pro RRD soubory

use Net :: SNMP; # vytvoreni SNMP relace s MikroTik zarizenim ($session , $error ) = Net ::SNMP -> session ( Hostname => '192.168.1.2 ', Version => 'snmpv2c ', Community => 'monitoring '); die " session error : $error " unless ( $session ); # Pozadovane OID hodnoty my @oid = ('1.3.6.1.2.1.2.2.1.2.1 ','1.3.6.1.2.1.2.2.1.10.1 ', '1.3.6.1.2.1.2.2.1.16.1 '); # Vytvoreni SNMP Get request s~ pozadovanymi OID my $result = $session -> get_request (- varbindlist => \@oid ,); die " request error : ".$session -> error unless ( defined $result ); % hodnoty =(); do{ # uprava hodnoty interfejsu pro lepsi zapis v~hashi hodnot $int = $result ->{ $oid [0]}; $int =~ s/\//g; # nacteni hodnot do hashe $hodnoty {$int }{ 'in '}= $result ->{ $oid [1]}; $hodnoty {$int }{ 'out '}= $result ->{ $oid [2]}; # vyzadani dalsich OID $result =$session -> get_next_request (- varbindlist => \@oid ,); # zjisteni OID hodnot ve prijmute zprave @oid = $session -> var_bind_names (); } until ($oid [0] eq '1.3.6.1.2.1.2.2.1.3.1 ' && !$session ->{ ErrorStr }); $session -> close ;

C

TVORBA A AKTUALIZACE RRD SOUBORŮ

65

C Tvorba a aktualizace RRD souborů foreach $rrd (keys % hodnoty ){ # pruchod ziskanym hashem hodnot if (! -e " $rrdfolder /$rrd.rrd") #dotaz na existenci souboru { # tvorba noveho RRD souboru RRDs :: create " $rrdfolder /$rrd.rrd", "-s~60", "DS:down: COUNTER :300:0:12500000 ", "DS:up: COUNTER :300:0:12500000 ", "RRA: AVERAGE :0.5:1:60 ", "RRA: AVERAGE :0.5:3:120 ", "RRA: AVERAGE :0.5:5:288 ", "RRA: AVERAGE :0.5:10:1008 ", "RRA: AVERAGE :0.5:15:2880 "; my $ERROR = RRDs :: error ; die "$0: unable to create `$rrd ': $ERROR \n" if $ERROR ; print " Vytvoreni nove databaze pro rozhrani $rrd"; # naplneni noveho souboru prvni hodnotou RRDs :: update " $rrdfolder /$rrd.rrd","-t", "up:down","N: $hodnoty {$rrd }{'in '}: $hodnoty {$rrd }{' out '}"; }else{ # aktualizace prislusneho RRD souboru RRDs :: update " $rrdfolder /$rrd.rrd","-t", "up:down", "N: $hodnoty {$rrd }{'in '}: $hodnoty {$rrd }{' out '}"; } }

D

D

AKTUALIZACE RRD SOUBORŮ NEAKTIVNÍCH ROZHRANÍ

66

Aktualizace RRD souborů neaktivních rozhraní

my % noupdate = (); # oznaceni vsech rozhrani jako nekativni foreach $i ~( <*.rrd >) { my $name = $i; $name =~ s /.*\/// g; $name =~ s/\. rrd .*//g; $noupdate { $name }=1; } foreach $rrd (keys % hodnoty ) { # odstraneni aktivniho rozhrani z~ neakivnich delete $noupdate {$rrd }; } # prochazeni vsech rrd souboru pro neaktivni rozhrani foreach $i ~( keys % noupdate ) { my $name = $i; $file = "/opt/rrdtool -1.4.5/ bin/ rrdtool lastupdate $rrdfolder /$name.rrd"; # spusteni RRD Tool lastupdate prislusneho souboru $result = qx/$file /; # formatovani vystupu pro ziskani poslednich ulozenych hodnot $result =~ s/\n\s//g; $result =~ s/^\ sdown \sup //g; $result =~ s/^\d*:\s//g; $up = $result ; $result =~ s/\d*\ s$ //g; #down $result =~ s/\ s$ //g; $up =~ s/^\d*\s*//g; chomp $result ; chomp $up; # aktualizace nekativniho rozhrani poslednimi pridanimi hodnotami RRDs :: update " $rrdfolder / $name .rrd","-t", "up:down","N:$up: $result "; }

E AUTENTIZACE UŽIVATELE OPROTI AD VE WEBOVÉ APLIKACI

67

E Autentizace uživatele oproti AD ve webové aplikaci Soubor login.php

žUivatelské jméno	< input type=´'text ' name='username '>
Heslo :	< input type='password ' name='password '>
	< input type='submit ' name='act ' value='Login '>

68

F TVORBA GRAFŮ VYTÍŽENÍ SÍŤOVÝCH LINEK

F Tvorba grafů vytížení síťových linek Soubor graph.php ";echo ""; echo "";echo ""; echo ""; echo ""; RRD image '>"; RRD image '>"; RRD image '>"; RRD image '>";

Soubor grafuj.php " Vytizeni sitoveho pripojeni za posledni hodinu ", '-6h' => " Vytizeni sitoveho pripojeni za poslednich 6 hodin", " -1d" => " Vytizeni sitoveho pripojeni za posledni den", " -1w" => " Vytizeni sitoveho pripojeni za posledni týden", " -1m" => " Vytizení sitoveho pripojeni za posledni ěmsíc" ,); # spusteni funkce pro vytvoreni grafu $user = $_SESSION ['username '] vytvor ($user , $_GET ['cas '], $casovac [$_GET['cas ']]); function vytvor ($user , $start , $title ) { # nalezeni souboru pro prihlaseneho uzivatele

F TVORBA GRAFŮ VYTÍŽENÍ SÍŤOVÝCH LINEK

$file = dirname ("/var/")."var/www/html/snmp/".$user.".rrd"; # nastaveni parametru funkce RRDTool graph $options ="--slope -mode"."--start ". $start ." --title='". $title . " '--vertical - label =bits/s~"."--lower =0"." -h 80 "."-w 600 ". "--base =1000 "." -a~"."PNG"." DEF:up=".$file.":up: AVERAGE ". " DEF:down=". $file .":down: AVERAGE "." CDEF: upbits =up ,8,*". " CDEF: downbits =down ,8 ,*"." LINE1 : upbits #336600: Upload ". " GPRINT : upbits :'MAX: Max \\: %5.1 lf %s'". " GPRINT : upbits :' AVERAGE : Avg \\: %5.1 lf %S'". " GPRINT : upbits :'LAST: Current \\: %5.1 lf %Sbits/sec \\n'". " LINE1 : downbits #0033 CC: Download ". " GPRINT : downbits :'MAX: Max \\: %5.1 lf %s'". " GPRINT : downbits :' AVERAGE : Avg \\: %5.1 lf %S'". " GPRINT : downbits :'LAST: Current \\: %5.1 lf %Sbits/sec \\n'"; # spusteni funkce RRD Tool graph s prislusnymi hodnotami $ven = system (" rrdtool graph - $options ",$pom ); }; ?> #pro prehlednost jsou parametry vypsany zde #--slope -mode -zaobli funkce hodnot #--start ". $start - cas od kdy je vypisovan graf #--title = '". $title - popis grafu #--vertical - label =bits/s - popis osy y #--lower =0 -h 80 -w 600 - min y v~grafu , rozmery 600 x80 #--base =1000 -a~PNG - zaklad vypisovane jednotky a~typ obr. #DEF:up =". $file .": up: AVERAGE - definice funkce up #DEF:down =". $file .": down: AVERAGE - definice funkce down # nasobeni funkci *8 aby byli v bit/s #CDEF: upbits =up ,8 ,* CDEF: downbits =down ,8 ,*"." #LINE1 : upbits #336600: Upload - tisk funkce do grafu #vypis statistickych hodnot funkce do grafu # GPRINT : upbits :'MAX: Max \\: %5.1 lf %s' # GPRINT : upbits :' AVERAGE : Avg \\: %5.1 lf %S' # GPRINT : upbits :'LAST: Current \\: %5.1 lf %Sbits/sec \\n' #LINE1 : downbits #0033 CC: Download - tisk 2. funkce do grafu #vypis statistickych hodnot 2. funkce do grafu # GPRINT : downbits :'MAX: Max \\: %5.1 lf %s' # GPRINT : downbits :' AVERAGE : Avg \\: %5.1 lf %S' # GPRINT : downbits :'LAST: Current \\: %5.1 lf %Sbits/sec \\n'

69

G

G

TVORBA GRAFŮ VYTÍŽENÍ SÍŤOVÝCH LINEK PRO SPRÁVCE

70

Tvorba grafů vytížení síťových linek pro správce

Soubor admingraph.php

Vyberte žuivatelské jméno zákazníka :

<select name=' zakaznik '>"; $dir = dir("/var/www/html/snmp"); #cteni souboru ve slozce a odstraneni pripony .rrd while ( false !== ( $soubor = $dir ->read ())) { $soubor = substr ($soubor ,0 , -4); if( strlen ( $soubor )!==0){ $soubory [] = $soubor ;} } sort( $soubory ); # naplneni moznosti vyberu jednotlivymi zakazniky foreach ( $soubory as $soubor ) {if (( $soubor == $_POST ['zakaznik ']) and ( $selected )) {$sel = " selected ";} else {$sel=''}; echo "". $soubor ." "; } echo "

< input type=' submit ' name='vyber ' value=' Zobraz '>

"; #pokud byl odeslan formular s pozadovanym uzivatelem if( $_POST ['vyber '] == " Zobraz "){ $_SESSION ['zakaznik ']= $_POST ['zakaznik ']; echo " Zobrazen graf pro žuivatele : ". $_SESSION ['zakaznik ']." "; $img = 'admingrafuj .php?cas='; echo "";echo "";echo "";echo "

"; echo ""; echo "

"; echo ""; echo "

"; echo ""; echo "

"; echo ""; echo "

"; echo ""; echo "

";} ?>

G

TVORBA GRAFŮ VYTÍŽENÍ SÍŤOVÝCH LINEK PRO SPRÁVCE

71

Soubor admingrafuj.php " Vytizeni sitoveho pripojeni za posledni hodinu ", '-6h' => " Vytizeni sitoveho pripojeni za poslednich 6 hodin", " -1d" => " Vytizeni sitoveho pripojeni za posledni den", " -1w" => " Vytizeni sitoveho pripojeni za posledni týden", " -1m" => " Vytizení sitoveho pripojeni za posledni ěmsíc"�,); # spusteni funkce pro vytvoreni grafu $user = $_SESSION ['zakaznik '] vytvor ($user , $_GET ['cas '], $casovac [$_GET['cas ']]); function vytvor ($user , $start , $title ) { # nalezeni souboru pro pozadovaneho uzivatele ; $file = dirname ("/var/")."var/www/html/snmp/".$user.".rrd"; # nastaveni parametru funkce RRDTool graph $options ="--slope -mode"."--start ". $start ." --title='". $title . " '--vertical - label =bits/s~"."--lower =0"." -h 80 "."-w 600 ". "--base =1000 "." -a~"."PNG"." DEF:up=".$file.":up: AVERAGE ". " DEF:down=". $file .":down: AVERAGE "." CDEF: upbits =up ,8,*". " CDEF: downbits =down ,8 ,*"." LINE1 : upbits #336600: Upload ". " GPRINT : upbits :'MAX: Max \\: %5.1 lf %s'". " GPRINT : upbits :' AVERAGE : Avg \\: %5.1 lf %S'". " GPRINT : upbits :'LAST: Current \\: %5.1 lf %Sbits/sec \\n'". " LINE1 : downbits #0033 CC: Download ". " GPRINT : downbits :'MAX: Max \\: %5.1 lf %s'". " GPRINT : downbits :' AVERAGE : Avg \\: %5.1 lf %S'". " GPRINT : downbits :'LAST: Current \\: %5.1 lf %Sbits/sec \\n'"; # spusteni funkce RRD Tool graph s prislusnymi hodnotami $ven = system (" rrdtool graph - $options ",$pom ); }; ?>

H

H

SPRÁVA NEVYUŽÍVANÝCH RRD SOUBORŮ

Správa nevyužívaných RRD souborů

Soubor inactive.pl #!/ usr/bin/perl use lib qw( /opt/rrdtool -1.4.5/ lib/perl ); use RRDs; $rrdfolder ="/var/www/html/snmp"; # pruchod vsemi vytvorenymi hodnotami foreach $i~(< $rrdfolder / *.rrd >) { # priprava na spusteni programu RRD Tool $file = " rrdtool graph whatever --start -1m DEF:ds=$i:up: AVERAGE PRINT :ds: AVERAGE :%6.2 lf"; $result = qx/ $file /; # spusteni RRD graph $result =~ s/0 x0\n//g; chomp $result ; # formatovani vystupu a~test jeho obsahu if (( $result eq ' 0 ,00 ') or ( $result eq ' -nan ')) { unlink $i; # odstaneni nevyuzivaneho RRD print "Bylo odstraneno rozhrani $i";} }

72

I

ZOBRAZENÍ POSTUPU PŘIPOJENÍ UŽIVATELE A SPRÁVCE DO WEBOVÉ APLIKACE

73

I Zobrazení postupu připojení uživatele a správce do webové aplikace

Obrázek 14: Žádost o ověření uživatele

I

ZOBRAZENÍ POSTUPU PŘIPOJENÍ UŽIVATELE A SPRÁVCE DO WEBOVÉ APLIKACE

Obrázek 15: Zobrazené grafy uživateli sítě

74

I

ZOBRAZENÍ POSTUPU PŘIPOJENÍ UŽIVATELE A SPRÁVCE DO WEBOVÉ APLIKACE

Obrázek 16: Výběr požadovaného uživatele správcem sítě

75

I

ZOBRAZENÍ POSTUPU PŘIPOJENÍ UŽIVATELE A SPRÁVCE DO WEBOVÉ APLIKACE

Obrázek 17: Zobrazený graf požadovaného uživatele vybraný správcem sítě

76