Monitorovací systém firemní počítačové sítě na bázi open source řešení

Mendelova univerzita v Brně Provozně ekonomická fakulta

Monitorovací systém firemní počítačové sítě na bázi open source řešení Bakalářská práce

Vedoucí práce: Ing. Martin Pokorný, Ph.D.

František Vařacha

Brno 2014

Tímto bych chtěl poděkovat vedoucímu práce Ing. Martinu Pokornému, Ph.D. za užitečné rady a trpělivost při konzultacích. Dále bych chtěl také poděkovat společnosti, bez které by tuto práci nebylo možné realizovat. V neposlední míře svým přátelům a rodině za trpělivost a podporu ve vzdělávání.

Čestné prohlášení Prohlašuji, že jsem tuto práci: Monitorovací systém firemní počítačové sítě na bázi open source řešení vypracoval/a samostatně a veškeré použité prameny a informace jsou uvedeny v seznamu použité literatury. Souhlasím, aby moje práce byla zveřejněna v souladu s § 47b zákona č. 111/1998 Sb., o vysokých školách ve znění pozdějších předpisů, a v souladu s platnou Směrnicí o zveřejňování vysokoškolských závěrečných prací. Jsem si vědom/a, že se na moji práci vztahuje zákon č. 121/2000 Sb., autorský zákon, a že Mendelova univerzita v Brně má právo na uzavření licenční smlouvy a užití této práce jako školního díla podle § 60 odst. 1 Autorského zákona. Dále se zavazuji, že před sepsáním licenční smlouvy o využití díla jinou osobou (subjektem) si vyžádám písemné stanovisko univerzity o tom, že předmětná licenční smlouva není v rozporu s oprávněnými zájmy univerzity, a zavazuji se uhradit případný příspěvek na úhradu nákladů spojených se vznikem díla, a to až do jejich skutečné výše. V Brně dne 20. května 2014

_______________________________

Abstract Vařacha, F. Monitoring system of corporate computer networks based on open source solutions. Bachelor thesis. Brno: Mendel University, 2014. This bachelor thesis is concerned with extension of the existing monitoring system in a real business environment. The entire monitoring system is based on the open-source programs Munin and Nagios. In the practical part is explained the configuration and implementation of both of the programs and verification of the monitoring system in the form of tests. Keywords Nagios, Munin, monitoring, server, network.

Abstrakt Vařacha, F. Monitorovací systém firemní počítačové sítě na bázi open source řešení. Bakalářská práce. Brno: Mendelova univerzita v Brně, 2014. Tato bakalářská práce se zabývá rozšířením stávajícího monitorovacího systému v reálném firemním prostředí. Celý monitorovací systém je založen na bázi opensource programů Munin a Nagios. V praktické části je vysvětlena konfigurace a implementace obou programů a ověření funkčnosti monitorovacího systému v podobě testů. Klíčová slova Nagios, Munin, monitoring, server, síť.

Obsah

5

Obsah 1

Úvod

7

2

Cíl práce

8

3

Popis technologického aparátu

9

4

5

6

7

3.1

Síťové protokoly .................................................................................................................. 9

3.2

Sledované prostředky ..................................................................................................... 12

3.3

Použité prostředí .............................................................................................................. 14

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

15

4.2

Servery v síti ....................................................................................................................... 15

4.3

Ostatní prvky...................................................................................................................... 18

Analýza dosud publikovaných prací

19

5.1

Akademické práce ............................................................................................................ 19

5.2

Knižní publikace ............................................................................................................... 20

5.3

Internetové zdroje ........................................................................................................... 20

5.4

Závěrečné shrnutí ............................................................................................................ 21

Vlastní práce

22

6.1

Přehled vybraných open source monitorovacích systémů .............................. 22

6.2

Stávající stav monitorovacího systému ................................................................... 24

6.3

Návrh nového monitorovacího systému ................................................................. 25

6.4

Implementace .................................................................................................................... 28

6.5

Návrh testovacích scénářů............................................................................................ 37

6.6

Výsledky testovacích scénářů...................................................................................... 38

Ekonomické zhodnocení

45

7.1

Počáteční investice .......................................................................................................... 45

7.2

Provoz a údržba ................................................................................................................ 45

7.3

Úspory................................................................................................................................... 45

7.4

Shrnutí .................................................................................................................................. 46

Obsah

6

8

Závěr

47

9

Literatura

48

Úvod

7

1 Úvod Bakalářská práce, jak již z názvu vyplývá, se zabývá monitorovacími systémy a jejich aplikací do praxe. Monitoring obecně znamená získávání informací o sledovaných prostředcích. V informačních technologiích se jedná o sledování všech prvků připojených do sítě. Z důvodu velké nákladnosti a neefektivnosti se nevyplatí sledovat každý prvek zvlášťs, proto je vhodné vytvořit monitorovací systém. Výhoda monitoringu je dostupnost a rychlý přístup k informacím. Všechna data jsou uložena na jednom centrálním místě. To má za výsledek velmi rychlé zjištění a vyřešení vzniklého problému. Zadání a řešení této práce je odvozeno od reálných podmínek nejmenovaného podniku. Modelová síťová topologie je inspirována právě sítí z tohoto podniku. Z důvodu bezpečnosti jsou modelové adresy a názvy prvků v síti zaměněny za smyšlené.

Cíl práce

8

2 Cíl práce Cílem práce je rozšíření a vylepšení stávajícího monitorovacího systému o detailněji monitorované prostředky a nově přidané servery v reálně firemní síti tj. popis stávajícího monitorovacího systému, analýzou nových uživatelských požadavků, implementaci a otestování nového monitorovacího systému.


9

3 Popis technologického aparátu V této kapitole bude probírána použitá technologie v monitorovacím systému a vysvětlení pojmů u sledovaných prostředků.

3.1

Síťové protokoly

Množina protokolů zajišťující většinu síťové komunikace. 3.1.1

IP (Internet protokol)

Patří mezi základní protokoly. Pracuje na 3. vrstvě referenčního modelu ISO/OSI neboli síťové vrstvě. Je základní složkou rodiny protokolů TCP/IP, které poskytuje IP datagramy. V síti je IP odpovědný za posílání paketů ze zdrojové stanice na cílovou stanici a to i přes několik různých sítí. Paket se skládá z řídicích dat (metadat) a uživatelských dat (payload).(Kabelova a Dostálek, 2008) 3.1.2

SNMP (Simple Network Management Protokol)

Tento protokol se zaměřuje na získávání nebo nastavování hodnot z cílového zdroje. Jedná se o široce rozšířený a užitečný standardizovaný protokol pro monitoring a správu sítě. Podporován je na velkém počtu zařízení od tiskáren, počítačových čidel, síťových prvků až po software s ním pracující. (Bouška, 2006) Pracuje ve dvou režimech:  První je klasický model klient (manažer)/server (agent). Server posílá požadavky na klienta a reakce zpracovává. Výhodou tohoto je, že může být více serverů a každý žádá klienta o jiné hodnoty. Mohou se ptát nezávisle na ostatních.  Druhý je opačný, klient posílá hodnoty na server bez jeho požadavku. Tento děj nastává při předem definovaných situacích, jakými jsou např.: překročení maximální velikosti souboru, překročení teploty, velké zatížení procesoru. Tyto poslané informace se označují „trapy“. Pro přenos informací používá SNMP transportní protokol UDP, který je velmi rychlý, avšak ve starších verzích SNMP protokolu mohlo docházet ke ztrátám informací (paketů). Tato chyba byla ve verzi 2 (SNMPv2) ošetřena implementací kontroly doručení. Nyní se již využívá SNMP verze 3. (Mauro a Schmidt, 2005) Standardně se pro komunikaci používají porty 161 na straně klienta pro dotazy a 162 na straně serveru pro trapy. Poslání trapu funguje tak, že klient posílá z dynamicky zvoleného portu na své straně na port serveru 162.


3.1.3

10

MIB (Management Information Base)

Informace, které se dají získat protokolem SNMP, jsou přístupné v hierarchické struktuře MIB. Každá hodnota je definovaná pomocí číselného identifikátoru OID. (Bouška, 2006) 3.1.4

ICMP (Internet Control Message Protokol)

Jeden z nedůležitějších protokolů. Spadá pod skupinu IP protokolů. Využívá se ve všech operačních systémech a sítích. Má na starost posílání chybových, informativních a jiných zpráv. Nejpoužívanějším úkolem protokolu v monitoringu sítě jsou ICMP datagramy „Echo request“ a „Echo reply“. Oba dva datagramy jsou použity v příkazu „ping“, který ukazuje dosažitelnost cílového síťového prvku a jeho časovou odezvu. Dalším důležitým úkolem je i žádost o směrování a mnoho dalších funkcí. (Kabelová a Dostálek, 2008, s. 127-133). 3.1.5

HTTP (Hypertext Transfer Protocol)

Internetový protokol na principu dotaz/odpověď. Je uzpůsobený na výměnu hypertextových dokumentů ve formátu HTML. Dle RFC 2616 (1999) používá transportní protokol TCP většinou na portu 80. HTTP není šifrovaný protokol, a proto lze snadno komunikaci odposlechnout. Kvůli tomuto nedostatku byl vytvořen protokol HTTPS. Technicky to není protokol jako takový, ale jde spíše o vrstvení protokolu HTTP se šifrovacími protokoly SSL/TLS. (Wikipedia, 2014b) Defaultně je protokol umístěn na port 443 na transportním protokolu TCP. 3.1.6

SSL (Secure Sockets Layer)/TLS (Transport Layer Security)

Jsou to kryptografické protokoly. Zajišťují bezpečnou komunikaci po internetu především u webových stránek a elektronické pošty. Protokol SSL je předchůdcem TLS a jeho nynější verze 3 je podobná protokolu TLS verze 1.0. (Oppliger, 2009) Zabezpečená komunikace je trojího druhu:  Kryptografie s veřejným klíčem – DSA, RSA.  Symetrické šifrování – AES, 3DES.  Jednosměrné hašování – MD5, SHA-1, SHA-2. 3.1.7

SSH (Secure Shell)

Zabezpečený komunikační protokol. Umožňuje bezpečnou komunikaci mezi zařízeními, přenos dat, tunelování. Komunikuje přes TCP protokol při defaultním portu 22. Jeho výhodou je používání ověřovacích certifikátů, což umožnuje rychlý přístup bez zadávání hesla. (Lucas, 2012) SSH lze využít i ke komunikaci mezi procesy jako komunikační kanál. (Baret, 2005)


11

Nejrozšířenějším softwarem používající SSH protokol je OpenSSH. Pracuje na principu klient/server. 3.1.8

Protokoly elektronické pošty

Elektronická pošta je používána jako rychlý zdroj informací v případě nějakého problému. To znamená odesílání zpráv v případě kritických událostí. Nejznámější odesílací protokol je SMTP (Simple Mail Transfer Protocol). Zajišťuje doručení pošty pomocí přímého spojení mezi odesílatelem a adresátem. Když se výměna podaří, email je uložen do emailové schránky. Pracuje na transportním protokolu TCP a jeho defaultní port je 25 při nešifrovaném odesílání. Nejrozšířenější protokoly pro přístup do elektronické schránky jsou IMAP a POP3. IMAP (Internet Message Acces Protokol) jako novější protokol je nyní více používaný. Velkou výhodou je vlastnost synchronizace pošty s lokálními klienty. Veškerá pošta je uložena na serveru a přístup k ní je umožněn odkudkoliv. Protokol ve výchozím nastavení používá transportní protokol TCP na portu 143. Naproti tomu starší protokol POP3 se používá pro stahování emailových zpráv. Funguje také na TCP ale na portu 110. (Loshin, 1999) 3.1.9

Syslog

Systémový protokol pro generování, ukládání a přenášení systémových zpráv po síti. Je podporován širokou škálou zařízení (např.: tiskárny, směrovače). Dle RFC 5424 (2009). (RFC 5424, 2009) 3.1.10

Netflow

NetFlow je otevřený protokol vyvinutý společností Cisco Systems, určený původně jako doplňková služba k Cisco směrovačům. Jeho hlavním účelem je monitorování síťového provozu na základě IP toků, které poskytuje uživatelům podrobný pohled do provozu na jejich síti v reálném čase. IP tok je definován jako sekvence paketů se stejnými údaji (cílová/zdrojová IP adresa, cílový/zdrojový port, číslo protokolu). U jednoho toku sledujeme čas vzniknutí, délku jeho trvání, počet přenesených paketů. (RFC 3954, 2004) 3.1.11

NTP (Network Time Protocol)

Tento protokol se využívá pro synchronizaci času vnitřních hodin počítače. Celá synchronizace probíhá na transportním protokolu UDP na výchozím portu 123. Protokol je chráněn i proti proměnlivému zpoždění paketů. (RFC 5905, 2010)


3.2

12

Sledované prostředky

V této podkapitole budou vysvětleny nejdůležitější prostředky, které budou monitorovány. Mezi tyto prostředky patří například SMART (Self Monitoring And Reporting Technology) kontrola, MySQL stav apod. Vysvětlení principu měření a jakými kontrolami budou prostředky testovány. 3.2.1

Databáze

Sledování databáze patří k základním prvkům databázového serveru. Sleduje se zde vytíženost, obsazenost, počet aktivních spojení, náročné SQL dotazy a jejich doba trvání apod. Monitoring statistik je důležitý pro celkovou stabilitu systému a rozložení výpočetního výkonu. Například aby skripty s velkou výpočetní a paměťovou náročností nebyly spouštěny ve stejnou dobu. Dále je důležité mít monitorovací systém nastaven pro případ pádu, aby správce či uživatel získal aktuální informace. V systému je použita MySQL databáze, která je dostupná pod licencí GPL. Mezi sledované prvky patří:  MySQL připojení – zde je sledován počet aktivních spojení. Aktivní připojení spočítáme jako počet podprocesů hlavního procesu pro databázi (pro MySQL databázi je hlavní proces mysqld).  Dlouhé MySQL – tento plugin udává počet SQL dotazů trvajících delší dobu. Většinou se jedná o složité dotazy. Tato funkce je dobrá např.: při nasazení nové webové stránky a sledování dotazů, jestli není některý příliš náročný.  MySQL stav – tímto pluginem jsou sledovány statistiky, jako jsou průměrný počet dotazů za sekundu, počet otevřených tabulek, celkový čas provozu aj.  MySQL_dočasný diskový prostor – velmi užitečný plugin pro kontrolu alokovaného místa na disku pro dočasné soubory. Udává volné místo v MB. 3.2.2

Paměť

Sledovány jsou zde všechny druhy pamětí. Monitoruje se volné místo k dispozici. Údaje jsou vyjádřeny procentuálně a v MB. Sledovány jsou:  Operační pamět – sledování obsazenosti operační paměti.  SWAP – sledování obsazenosti swapovacího prostoru.  HDD – plugin pro sledování obsazenosti na pevném disku.  OSCACHE – monitoruje obsazenost prostoru v operační paměti vyhrazené na cachování webových aplikací. (OSCache, 2013)


3.2.3

13

Pevný disk (HDD)

Z důvodu velkého počtu disků je procházení disků jednotlivě časové náročné, proto musí být monitorovány globálně. Největší výhodou monitoringu je rychlé zjištění v případě chyby. U disků jsou sledovány vlastnosti:  SMART – je to technologie posuzující stav pevného disku, proto může odhalit disk, který za chvíli skončí svou dobu užívání.  Teplota – pro nejdelší životnost pevných disků je nutné udržení jejich optimální teploty. Na základě monitoringu regulujeme chlazení.  RAID – kontroluje stav RAID polí. Hlásí aktuální stav pole například při synchronizaci nebo degradaci pole. (Wikipedia, 2014d). 3.2.4

Informace o systému

Pro správný chod systému je potřebné vědět co nejvíce informací o jeho stavu. Níže vyjmenované sledované prostředky by neměly chybět u žádného serveru.  Load average – zjednodušeně řečeno je to, kolik procesů se chce dostat ke zpracování na CPU v dané časové jednotce. Hodnoty 0-3 jsou ještě v normě. Vyšší hodnoty už můžou být problém. Tato funkce ukazuje 3 hodnoty, které jsou od sebe časově oddělené – 1, 5, 15 posledních minut. S touto hodnotou úzce souvisí funkce I/O (input/output – operace s diskem) a context switch – přepínání řízení mezi procesy. (Andre, 2014).  Monitoring délky běhu systému bez vypnutí nebo restartování (Uptime).  Celkový počet procesů.  Zombie procesy – monitoruje počet procesů ve stavu zombie tj. proces, který ještě neuvolnil své alokované prostředky. Pokud procesů bude hodně, můžou nastat problém s nedostatkem systémových prostředků.  procesy programů (daemons) – sledování stavu hlavních procesů, které musí být na daném zařízení aktivní. Mezi ně obvykle patří sshd, mydns apod.  Ping – ping pracuje na straně monitorovacího serveru. Sleduje dostupnost. Bývá většinou poslední odpovídající sledovaný prostředek před havarií.  Síť – statistika a monitoring síťového provozu. Užitečná věc při optimalizování datových toků. 3.2.5

Informace o místnosti

Podstatnou věcí je sledování celé serverové místnosti. Na základě okolního počasí a vytížení serverů (při vyšší zátěži roste teplota) se musí hlídat stálá teplota a vlhkost v místnosti.


3.3

14

Použité prostředí

Pro všechny servery v monitorované síti byl zvolen operační systém Centos (Centos, 2014). CentOS (Community Enterprise Operating System) patří do rodiny GNU/Linux. Tento operační systém je založen na Red Hat Enterprise Linuxu a je s ním plně kompatibilní. K instalaci software používá nástroj yum. Avšak je možné i použití manuálních instalací v podobě balíčku RPM nebo přímou kompilace zdrojových kódů. Zvolený systém je velmi vhodný pro serverové řešení skrze velkou podporu a vývoj. Většina novinek, aktualizací a programů, které se objeví na Red Hat Enterprise Linuxu se rychle objeví i na CentOS.


15

4 Analýza uživatelských požadavků Bude vytvořen monitorovací systém počítačové sítě, která obsluhuje několik serverů. Každý server má předem danou funkci např.: webový, zálohovací, poštovní, doménový, databázový, souborový. Proto je důležité správně navrhnout prostředky, které mají být monitorovány, aby bylo zabráněno výpadku nebo vzniklá chyba byla rychle opravena. Důležitou věcí je předání informace o problému nebo předání průběžných statistik o běhu systému. K tomu poslouží přehledné webové rozhraní, kde budou všechny informace rozepsány. O akutních problémech se uživatel bude dozvídat prostřednictvím elektronické pošty, kde budou zobrazeny informace o vzniklém problému. Budou zde vypsány informace, kde se problém odehrává, jak vysoké nebo nízké hodnoty nastaly a stupeň problému např.: kritická hodnota, varování. Ty nejakutnější problémy mohou být posílány i na mobilní telefon prostřednictvím SMS brány. Budou uchovávány i průběžné statistiky sledovaných prostředků. Zde si uživatel může zobrazit informace za zvolené období v podobě grafů. 4.1.1

Zabezpečení monitorovaných dat

Komunikace programů bude probíhat po uzavřené síti LAN. Pro přístup k monitorovaným datům poslouží vyčleněný server. Uživatelské prostředí bude webová aplikace, do které se uživatel musí přihlásit pomocí jména a hesla. Webová aplikace bude přístupná z Internetu. 4.1.2

Servis a obsluha systému

Požadavek na obsluhu monitorovacího systému je pravidelná kontrola monitorovaných dat a řešení případných problémů.

4.2

Servery v síti

Všechny monitorované servery mají nainstalovaný operační systém Centos. V síti jsou zapojeny servery s odlišným zaměřením:  Webový server,  poštovní server,  DNS server,  databázový server,  souborový server,  zálohovací server,  vývojářský server.


4.2.1

16

Společné prostředky

V této kapitole jsou sledované prostředky, které všechny servery mají společné. Tyto prostředky jsou sledovány na každém serveru bez ohledu na jeho specializaci. Proto pro lepší přehled jsou tyto prostředky zde shrnuty:  Ping – nejnižší úroveň vzdáleného testování dostupnosti. Používá ICMP zprávy kódu 8 (Echo request) a 0 (Echo reply). Výsledek je časový údaj v ms. Konečná zpráva monitoringu má dvě možnosti UP/DOWN.  RAID – sledování raidového pole. V jakém je stavu. Tato služba bude sledována jenom na fyzických strojích.  Celkový počet procesů – kritická hodnota je nastavena na 400 procesů.  Operační paměť – sledování volného místa a s ubývající hodnotou včasně varovat uživatele. Kritická hodnota je nastavena 7 % volného místa.  SWAP prostor – podobně jako u operační paměti je sledován stav volného místa v MB. Kritická hodnota je též nastavena na 7 % volného místa.  Průměrná zatíženost (Load Average) – důležitá hodnota pro zjištění aktuální zatíženosti serveru. Kritická hodnota je nastavena na čísla vyšší než 3.  Obsazenost disku – sledovat aktuální volné místo na určitém místě v MB. Procentuálně je kritická hodnota nastavena na zbývajícíh 10 % volného místa.  Délka běhu systému bez vypnutí nebo restartování – jde spíše o statistický údaj. Žádná kritická hodnota zde není nastavena.  Statistika celého serveru - vytvoření statistiky ze sledovaných hodnot. Údaje budou vykresleny v grafech. 4.2.2

Webový server

Jak již z názvu serveru vyplývá, jde o službu zobrazování webových stránek nebo aplikací. Nejběžnějším softwarem je pro tento účel Apache HTTP Server. Je to hodně robustní program se spoustou modulů a širokou škálou nastavení. Je volně ke stažení jako open source. Zde jsou monitorovány tyto prostředky:  HTTP – sledování odezvy HTTP Serveru v sekundách na zvolené stránce. Kritická hodnota je zvolena na 6 s. Zde je také monitorováno časté vychylování od průměrné hodnoty, neboli pokud služba „flapuje1“ mění se například často čas odezvy.  Počet podprocesů – sledujeme počet podprocesů daného webového démona. Kritická hodnota je zvolena na 50.

1

Flapping – pokud se často mění sledované hodnoty.


4.2.3

17

Poštovní server

Programy pro tuto situaci, jsou pro protokol SMTP Postfix a Sendmail. Pro poštovní schránku (IMAP/POP) je použit Dovecot. Zde jsou monitorovány tyto prostředky:  Odezva programů v sekundách na zvolených portech portech. Kritická časová hodnota byla zvolena delší než 3 s.  Stav programů – pokud je proces spuštěný/zastavený.  Mailová fronta pošty k odeslání – v případě zvýšení počtu neodeslaných zpráv nad stanovenou mez 40.  Počet podprocesů daných démonů – je potřeba evidovat využití každého programu zvláště. Kritická hodnota byla zvolena 50. 4.2.4

DNS server

Bude využit a monitorován open source program pro Unixové systémy MyDNS. Je zpravován přes webové rozhraní a všechny záznamy ukládá do SQL databáze (MySQL nebo PostgreSQL). Jako alternativu je možné využit programy BIND, PowerDNS. Zde jsou monitorovány tyto prostředky:  Stav a odezva démona v sekundách a rychlost dotazu na překlad zvolené domény. Kritická hodnota nastane, pokud nedojde odpověď do 2 s.  Stav a dostupnost webového rozhraní. Kritická hodnota na odpověď webového démona je 10 s. 4.2.5

Databázový server

Klíčová složka v každé infrastruktuře. Většina dat a přístup k nim zajišťuje právě tento server. Důraz je kladen na rychlost čtení a zapisování dat. Proto je zde důležité mít rychlé pevné disky a velkou operační paměť. Databáze k monitoringu byla zvolena MySQL z důvodu ceny a rozšířenosti. Je pro ni vyvinuto spoustu užitečných nástrojů a většina vývojářů s ní umí pracovat. Zde jsou monitorovány tyto prostředky:  Počet aktuálních připojení k databázi. Kritická hodnota byla zvolena 60 připojení.  Počet dlouho trvajících dotazů v sekundách. Dlouhotrvající dotaz je SQL dotaz spuštěný déle než 4 s. Kritický čas pro konání dotazu je stanoven na 600 s.  Velikost místa pro dočasné soubory – vyhrazené místo určené pro dočasné soubory databáze v MB. Kritická hranice je 7 % zbývajícího volného místa.  Průměrný počet dotazů za vteřinu – údaj vhodný do statistik k rovnoměrnému rozložení zátěže.


4.2.6

18

Souborový server

Tento typ serveru je užitečný při výměnách nebo sdílení souborů jakékoliv velikosti. Proto je zde vhodné mít co největší uložiště. Výhodou je dostupnost dat z různých míst a ochrana proti ztrátě. U tohoto serveru je důležité sledovat pevné disky a obsazenost. Kritická hranice je nastavena na zbývajících 10 % volného místa. 4.2.7

Zálohovací server

Zálohovací server je poslední záchranou na cestě při obnově ztracených nebo poškozených dat. Nemá vliv na funkčnost společnosti, pokud někde nenastane problém se ztrátou dat nebo poškozením nosičů. Proto je zde kladen důraz na spolehlivost. Zde jsou monitorovány tyto prostředky:  Teploty disků – kritická hodnota je nastavena na 43°.  SMART kontrola – technologie posuzující stav disku. Na základě monitoringu můžeme předejít neočekávaným pádům pevných disků a možného zhroucení RAID pole.  Monitoring stavu programů a skriptů na zálohování – dohlížení na pravidelné spouštění a neočekáváná zaseknutí programů. 4.2.8

Vývojářský a testovací server

Slouží k testování nových verzí programů a přípravu pro nasazení klientům. Dále je využíván pro programátory, grafiky a ostatní vývojáře, aby si zde otestovali své projekty. Z důvodu rozmanitosti služeb, které na tomto typu serveru musí fungovat, je těžké definovat výčet monitorovaných prostředků. A proto jsou zde požadovány monitorovat obecné prostředky (viz kap. 4.2.1) a na popud vývojářů jsou zde přidávány a odebírány specifické prostředky.

4.3

Ostatní prvky

Tato kapitola obsahuje ostatní sledované síťové prvky. 4.3.1

Přepínač (switch) a směrovač (router)

U těchto aktivních síťových prvků budou sledovány:  Stav UP/DOWN a odezva v ms.  SNMP informace – délka nepřerušeného aktivního stavu (uptime).


19

5 Analýza dosud publikovaných prací Základní složkou pro vyhledávání byla klíčová slova. Používána byla slova: Nagios, systém, monitoring, síť, Munin, SNMP. Samozřejmě u českých slov i jejich ekvivalenty v anglickém jazyce. Další složkou je místo vyhledávání. Byly procházeny archívy prací na různých univerzitách například na portálu theses.cz. Hledány byly knižní tituly na Amazon, elektronická knihovna Google. Mnoho užitečných informací bylo nalezeno v internetových článcích a na specializovaných webech. Jako kritérium byl zvolen rok vydání těchto publikací. Skrze neustálý vývoj programového a technologického aparátu byla mezní hranice vydání určena 5 let.

5.1

Akademické práce Systém pro monitoring síťových serverů a služeb

Zabývá se tvorbou monitorovacího systému, který poskytuje aktivní periodické monitorování serverů. Uživatelské rozhraní je v tomto případě klientská aplikace v podobě desktopové a Androidí verze. (Holubec, 2013) Monitoring hybridní síťové infrastruktury Tato bakalářská práce se věnuje vývoji univerzálního monitorovacího systému zařízení v hybridní síti pro společnost SELF servis. Systém slouží k ověření dostupnosti pomocí ICMP-paketů a ke sledování hodnot s využitím SNMP protokolu. V textu naleznete popis analýzy požadavků, návrhu systému a samotné implementace. (Janda, 2009) Monitoring lokální sítě prostřednictvím Nagiosu Tato bakalářská práce se zabývá monitoringem lokální sítě pomocí systému Nagios. Práce se postupně zaměřuje na tvorbu a implementaci pluginu pro tento systém. Výsledkem práce je plugin na monitoring tiskárny. (Szabo, 2012) Monitorování IT infrastruktury Práce se zabývá problematikou monitorovacích systémů. Ukazuje principy, na kterých jsou tyto systémy založené a požadavky, které jsou na ně kladeny. V práci jsou představeny 3 systémy, které jsou blíže probrány a zhodnoceny z několika hledisek. Součástí práce je i popis zhodnocení procesu nasazení vybraného monitorovacího systému do reálného provozu. (Hašuľ, 2010) Monitorování provozu distribuovaných informačních systémů V práci je shrnována problematika monitorovacích systémů a jejich správa. Jsou popisovány základní myšlenky monitorování a logika monitorování. Jsou zde představeny současné monitorovací systémy a srovnávány jejich schopnosti. Dále jsou představeny tři konkrétní monitorovací systémy. Na závěr je popsán vyvinutý monitorovací systém. (Géryk, 2008)


20

Integrace monitorovacího systému počítačové sítě na bázi open source a komerčních produktů Bakalářská práce se zabývá porovnáním jednotlivých monitorovacích nástrojů s důrazem na rozdíl mezi komerčními produkty a open-source produkty. Popisuje jednotlivé nástroje a jejich technické parametry. V další části je ukázáno reálné nasazení několika produktů na simulované firemní síti a prezentována jejich činnost. Na závěr jsou ekonomicky zhodnoceny jednotlivé produkty včetně nákladů na nasazení do firmy a nákladů na provoz. (Benda, 2011)

5.2

Knižní publikace

Nagios Core Administration Cookbook Kniha vám ukáže, jak používat Nagios jako monitorovací framework, který chápe vrstvy a jemnosti sítě pro inteligentní monitorování a oznamování chování. (Ryder, 2013) Nagios: Building Enterprise-Grade Monitoring Infrastructures for Systems and Networks (2nd Edition) Tato kniha je kompletní průvodce k budování efektivního, z hlediska nákladů, monitorovacího systému podnikové infrastruktury s použitím nejnovější komerční i open source verze Nagios. (Josephsen, 2013) Instant Nagios Starter Instant Nagios Starter je mocný nástroj, který učí, jak používat Nagios jako monitorovací řešení a jak ho lze nastavit pro inteligentní monitorování, jakož i reakce na incidenty. (Guthrie, 2013) Instant Munin Plugin Starter Tato práce je kompletní průvodce v programu Munin. Zabývá se tématy od instalace až po tvoření vlastních pluginů. Je to zdroj hodně užitečných informací o daném sledovacím programu. (Brinke, 2013)

5.3

Internetové zdroje Monitorování serveru pomocí nástroje Munin

Článek popisuje stručný návod instalace a konfigurace monitorovacího systému Munin. Lehce osvětluje, do které kategorie program patří a co uživateli umožňuje. (Dočekal, 2011) Munin - monitorování serverů Článek vysvětluje princip programu Munin. Jeho využití v praxi a stručnou instalaci. Práce také obsahuje návod na vytvoření vlastního pluginu. Jedná se o krátký, ale výstižný článek. (Čihař, 2014)


5.4

21

Závěrečné shrnutí

Při procházení různých prací na téma monitoring podnikové sítě bylo nalezeno mnoho návodů a tipů na instalaci a konfiguraci. Proto není vhodné se v bakalářské práci zaměřit pouze na některý program a zpracovat ho jako uživatelskou příručku. Ale co mi ve výše uvedených pracích chybělo, byl ucelený návod na kombinaci více monitorovacích programů dohromady, které uživateli nebo správci sítě poskytnou celkový přehled o sledované síťové infrastruktuře.

Vlastní práce

22

6 Vlastní práce V kapitole vlastní práce je popsána praktická část. Je zde uveden stávající stav monitoringu i nově navrhnutý monitorovací systém.

6.1

Přehled vybraných open source monitorovacích systémů

Existuje mnoho open source monitorovacích systémů a každý má výhody v jiných oblastech. Níže je uvedena tabulka vybraných nástrojů a jejich krátké specifikace. Tabulka vznikla na základě vlastního průzkumu, což obsahovalo především vyhledávání na internetu, v nalezených pracích a diskuzi s odborníky na předmětné téma. (Wikipedia, 2014a; Benda, 2011) Více o vyhledávání a používání klíčových slov je uvedeno v kap. 5. Tento přehled obsahuje nástroje, které splňovaly autorem zadaná kritéria (viz. Tab. 1). Z toho vyplývá, že programy v uvedené tabulce nejsou podloženy žádnými testy, které by vyhodnocovali jejich kvalitu a další vlastnosti. Tab. 1

Přehled open source monitorovacích systémů.

Nástroj

Platforma

Syslog

SNMP

Cacti Nagios

PHP C, PHP

ANO Plugin

ANO Plugin

Webová aplikace Plné ovládání Zobrazení

Plné ovládání

Zabbix

C, PHP

ANO

ANO

Icinga

C

Plugin

Plugin

Zenoss Ganglia Munin

Python C, PHP Perl

ANO NE NE

ANO Plugin ANO

Centreon

PHP, Perl, C Plugin

ANO

Plné ovládání Plné ovládání Zobrazení Zobrazení Plné ovládání

ANO ANO ANO

Ukládání informací RRD tool, MySQL Flat file, SQL Oracle, MySQL, PostgreSQL, IBM DB2, SQLite MySQL, PostgreSQL, Oracle ZODB, MySQL, RRD tool RRD tool RRD tool

ANO

MySQL, RRD

Pluginy ANO ANO

ANO ANO

Uživatelsky nejvíce podstatný je přístup k nastavování systému a dostupnost monitorovaných dat. U většiny systémů je webová aplikace s plným ovládáním, což znamená i nastavování samotné aplikace přes webové rozhraní, ale v ostatních případech je konfigurace možná pouze v konfiguračních souborech. Tato možnost je v tabulce uvedena jako zobrazení.

Vlastní práce

23

Platforma pro uživatele není podstatná, dokud není potřeba nějaké speciální funkce. Z tohoto hlediska je dobré zvážit výběr programu podle programovacího jazyka. Všechny nástroje mohou být rozšířeny doplňky. Tuto možnost uvádí tabulka ve sloupci pluginy. Tento požadavek byl jedním z hlavních kritérií, které byly při vyhotovování přehledu uplatněny. Důraz byl kladen na možnou rozšiřitelnost monitorovacího spektra. Sloupce Syslog a SNPM pojednávají o možném použití těchto protokolů (viz kap. 3). Uložení informací se liší asi nejvíce. Proto si uživatel může zvolit jaká forma uložení dat je pro něho nejpříjemnější nebo technicky vyhovuje jeho nárokům. 6.1.1

Zvolené programy

Vzhledem k dobrému hodnocení a předchozího nasazení na stávajícím monitorovacím systému, bylo rozhodnuto o použití programů Munin a Nagios. Každý má výhodu v odlišných funkcích a proto v kombinaci tvoří výkonný pár. Tyto aplikace jsou k dostání již delší dobu a proto i počty doplňků dosahují vysokých čísel. Skrze rozmanitost sledovaných prostředků v této situaci je to velká výhoda.

Vlastní práce

6.2

24

Stávající stav monitorovacího systému

Pro lepší přehled o celé práci je nutné rozepsat stávající stav celého monitorovacího systému. Stávající monitorovací systém nepodává dostatečné informace o aktuálním stavu všech prvků. Proto je nutné tyto nedostatky napravit. Bližší informace o struktuře systému a topologii sítě jsou napsány v nadcházející kapitole. 6.2.1

Topologie a struktura sítě

Adresy v rozsahu 192.168.0.0/24 simulují veřejné adresy, které jsou zaměněny za lokální z důvodu anonymity. Nakreslená topologie je zjednodušená, protože některé servery vykonávají tutéž úlohu, a proto jsou zobrazeny pouze jedním zástupcem.

Obr. 1

Stávající topologie.

Vlastní práce

25

Ve stávajícím systému jsou nedostatky, které je v novém monitorovacím systému nutné odstranit. Mezi tyto nedostatky patří:  Nedostatečné informace z monitoringu – v monitorovacím systému jsou sledovány prostředky, které nedostačují pro požadované informace z monitoringu. U serverů jsou sledovány základní prostředky jako dostupnost, zde je sledován stav on-line/off-line, průměrná zátěž na procesoru, celkový počet procesů, obsazenost disků, u fyzických serverů se sleduje stav RAID pole, u přepínače a směrovače je sledována dostupnost. Všechny požadované prostředky, které budou obsaženy v novém monitoringu, jsou vypsány v kap. 4.  Sledované prvky – ve stávajícím systému nejsou zahrnuty všechny požadované prvky (záložní mail server, nově zavedené webové servery, vývojářský server, některé fyzické servery).  Separace sítě - hierarchie monitorovacích nástrojů je řešena na stejné IP síti jako produkční provoz. Vše je řešeno veřejně přístupnými adresami. Pro předejití útoků na monitorovací systém z cele sítě Internet, musí být monitoring přesunut na jinou síť, nedostupnou veřejnosti.  Přístup k datům – přístup k datům zajišťuje protokol HTTP (nikoliv HTTPS). Jedinou ochranou dat je přístupové jméno a heslo. Vzhledem k veřejné adrese je přístup na webové rozhraní monitoringu umožněn odkudkoli.  Monitorovací server – serverové části monitorovacích nástrojů jsou nainstalovány na strojích, kde již fungují jiné služby. Úkolem je převést tyto části na vyhrazený server pouze pro monitoring. Síťová komunikace mezi monitorovacími programy je zabezpečena pomocí protokolu SSL v případě systému Nagios. U nástroje Munin je výměna dat omezena na povolené adresy. To znamená že, na klientské části je povolena adresa pouze serverové části Munin nástroje. Pro ohlašování kritických nebo jenom informativních zpráv uživateli je použita elektronická pošta nebo SMS zpráva.

6.3

Návrh nového monitorovacího systému

Do nové monitorovací sítě budou zahrnuty všechny prvky dle specifikací (viz kapitola 4). Odstraněny budou také i výše zmíněné bezpečnostní nedostatky. V reálné síti firmy se nachází vícero serverů plnící tutéž úlohu, z tohoto důvodu je v nákresu zobrazen pouze jeden zástupce od každého zaměření. 6.3.1

Realizace separace sítě

Existuje mnoho možností separace sítě například pomocí VLAN. Z důvodu delšího výpadku při konfiguraci a nepatrně vyšší účinnosti vzhledem k jiné možnosti, bylo řešení zamítnuto. Další možné řešení je OOB, (Wikipedia, 2014c) z důvodu chybějící technologie na některých strojích bylo vyloučeno. Možnost fyzického separování sítě bylo zamítnuto, z důvodu vysokých finančních nákladů.

Vlastní práce

26

Nejlepší možné řešení je vytvoření druhé IP sítě, která bude vyhrazena pro monitorovací systém. Komunikace bude probíhat na virtuálních síťových rozhraních. O přístup k monitorovaným datům se postará serverová část monitorovacího systému, která bude přístupná protokolem HTTPS z vnitřní sítě. Externí přístup bude zajišťovat VPN tunel do této sítě. 6.3.2

Topologie a struktura

Jak již bylo zmíněno v kapitole o bezpečnosti (viz 6.3.1), celá síť je rozdělena na dvě IP sítě. Síť 192.168.0.0/24 imituje veřejné adresy a slouží pro produkční provoz a síť 10.20.30.0/24, monitorovací síť, slouží pouze pro komunikaci mezi monitorovacími nástroji.

Obr. 2

Nová topologie.

Monitorovací síť je z většiny vytvořena na virtuálních síťových rozhraních každého sledovaného prvku v síti. Z toho vyplývá, že pokud daný přístroj má pouze jedno síťové rozhraní, tak musí být nakonfigurováno virtuální rozhraní například

Vlastní práce

27

eth0:0. Pokud jsou přítomny dvě fyzické síťové karty, může být nakonfigurována monitorovací síť na druhé síťové kartě. 6.3.3

Monitorovací server

Monitorovací nástroje mají hierarchii klient/server, což vyžaduje jeden vyčleněný administrátorský server, kam jsou posílána a ukládána všechna vysledovaná data. Tuto funkci bude obsluhovat virtuální server s adresou 10.20.30.21. Budou dva způsoby monitorování, aktivní a pasivní. Aktivní přístup monitorování vyžaduje určitou spolupráci sledovaného síťového prvku. Monitorovací server se pomocí protokolu SSL připojí ke vzdálenému démonovi běžící na klientovi, aby stáhnul požadované informace. Připojení pomocí SSL se využívá v systému Nagios a komunikační démon je nazýván NRPE. U programu Munin se komunikační démon nazývá Munin-node. Pasivní přístup nevyžaduje žádného aktivního démona u klienta. Sleduje prostředky, na které odpovídají jiné služby. Například ICMP zprávy (viz kapitola 3) nebo délka odezvy v milisekundách určité služby (webová stránka). Posílání zpráv uživateli se od stávajícího systému lišit nebude. Bude využita elektronická pošta a SMS pomocí internetové SMS brány. Posílány budou všechny kritické situace a v některých případech i varovaní. Varování bude zasíláno v případě rostoucího průměrného zatížení, protože pokud se úroveň dostane do kritických hodnot, většinou to znamená nějaké omezení pro klienty z důvodu výpadku nebo dlouhé odezvy služeb a této situaci je lepší předcházet. 6.3.4

Přístup k monitorovaným datům

Přístup k monitorovaným datům bude jen z vnitřní sítě a obstaráván protokolem HTTPS. Webový přístup bude zabezpečený uživatelským jménem a heslem. Pro externí přístup bude sloužit VPN (virtual private network) tunel na veřejnou adresu serveru, kterou zastupuje tato adresa 192.168.0.40, ze kterého se bude možné připojit na monitorovací server. VPN tunel bude zabezpečený certifikátem chráněný heslem.

Vlastní práce

Obr. 3

VPN tunel

6.3.5

Nároky na provoz a údržbu

28

Podle požadavků je nejvhodnějším kandidátem na provoz externista. Tím je namysli práce na částečný úvazek nebo dohoda o provedené práci. Vhodným kandidátem je například student. Akutní informace dostane prostřednictvím SMS zprávy nebo elektronické pošty. Musí být schopen v relativně krátké době vyřešit vzniklé potíže. K tomu bude mít vzdálený přístup na všechna zařízení. Bude mu také umožněn fyzický přístup do serverové místnosti.

6.4

Implementace

Část implementace popisuje instalaci a konfiguraci obou nástrojů, sítě a VPN tunelu. Jsou zde vysvětleny základní konfigurační příkazy a uvedeny některé příklady. 6.4.1

Implementace monitorovacího nástroje Nagios

Nagios je rozdělen na administrační a na síťovou část. Administrační část je obsluhována démonem nagios. Modulů pro síťovou komunikaci je více, ale použitý je modul NRPE (viz níže). Instalace V instalaci je použito jméno pro uživatele „admin“. Na nainstalovaný, již zmíněný, operační systém CentOS, je pomocí balíčkového open source programu yum, zadán příkaz k instalaci balíčku nagios: yum install nagios

Po provedení příkazu jsou naistalovány základní součásti systému Nagios. Lze využít i jiné typy instalací, ale tento postup je uživatelsky přívětivý. Vytvoření uživatele, pod kterým bude program pracovat, je proveden příkazem: /usr/sbin/useradd -M -s /sbin/nologin nagios

Přepínač „-M“ zajistí, že uživatel nagios bude bez domácího adresáře a přepínač „s“ znepřístupní přihlášení na tohoto uživatele.

Vlastní práce

29

Aby uživatel nagios mohl spouštět pluginy pod právy roota bez nutnosti zadávání hesla a spouštěné pluginy měly přístup k systémovým informacím, musí být přidán do „/etc/sudoers“, nejlépe pomocí příkazu „visudo“, příkaz povolující tyto privilegia: nagios ALL=(ALL) NOPASSWD: /usr/lib64/nagios/plugins/

Cesta k pluginům může být i jiná, proto všechny potřebné skripty a pluginy musí mít zde uvedené cesty. Konfigurační soubory:  cgi.cfg – nastavení webového přístupu.  htpasswd.users – seznam uživatelů a jejich hesel pro webový přístup k datům.  nagios.cfg – hlavní konfigurační soubor celého systému, zde jsou uvedeny cesty k ostatním konfiguračním souborům.  nrpe.cfg – konfigurační soubor pro síťový modul. Definují se zde příkazy a cesty k pluginům.  commands.cfg – definování příkazů. Každý příkaz obsahuje plugin a nějaké nastavení. Tyto příkazy se mohou opakovat u více sledovaných serverů.  contacts.cfg – nastavení způsobu informování o událostech.  hosts.cfg – definování všech sledovaných serverů a síťových prvků.  hostgroups.cfg – zde se definují skupiny sledovaných serverů a síťových prvků, například virtuální operační systémy, fyzické stroje, skupina webových serverů apod.  templates.cfg – vytvoření šablony nastavení (kontaktů, hostů, služeb), které lze využít podobně jako v případě příkazů v commands.cfg. Při definování lze šablonu použít příkazem „use“. Vyjmenovány jsou nejhlavnější konfigurační soubory. Existuje mnohem více souborů, které definují například přepínače, servery s operačním systémem Windows, tiskárny, časové periody. Konfigurace Po instalaci jsou konfigurační soubory nastaveny na výchozí hodnoty. Je doporučeno zálohovat si výchozí soubory a upravovat a konfigurovat kopie. Některé úpravy si nemusí uživatel pamatovat, a proto se může velmi snadno vrátit k výchozím hodnotám. V níže uvedených konfiguračních souborech budou vysvětleny hlavní konfigurační příkazy. Pro podrobnější informace je dobrý zdrojem (Nagios, 2014), což je domovská stránka celého projektu. cgi.cfg V tomto souboru se nastavuje obsluha webového přístupu. Je zde definována cesta ke zdrojovému kódu celého webu. Parametry autentizace a autorizace. Nastavení periody aktualizace stránky.

Vlastní práce

30

nagios.cfg Hlavní konfigurační soubor pro démona nagios. Definují se zde cesty k ostatním konfiguračním souborům, nastavuje se zde uživatel a skupina, pod kterou démon pracuje. Dále je zde nastavení logování a cest k souborům potřebným pro celkovou funkčnost programu (například složka dočasných souborů). commands.cfg Soubor pro definování příkazů, které jsou v ostatních konfiguracích volány jménem. To v praxi znamená, že nemusíme příkaz definovat u každého hosta znovu. Pro lepší pochopení je níže demonstrováno sledování odezvy pomocí příkazu ping: define command{ command_name

check_ping

command_line $USER1$/check_ping -H $HOSTADDRESS$ -w $ARG1$ -c $ARG2$ -p 5 }

Struktura definování příkazu je u všech podobná. Co stojí za zmínku je řádek command_line. Položka „$USER1$/“ je definována v souboru resource.cfg a vyjadřuje cestu k pluginům. Uživatel si může těchto proměnných definovat více pro snadnější ovládání. Parametry „-w“ a „-c“ určují u pluginů hranici sledovaných hodnot (warning, Critical). contacts.cfg Konfigurační soubor pro odesílání stavových zpráv. Definují se zde uživatelé a skupiny uživatelů, které mají být kontaktovány, a určuje se zde také způsob kontaktu: define contact{ contact_name

admin

use

generic-contact

alias

Nagios Admin

service_notification_options

w,u,c,r,f

host_notification_options

d,r,u,f

service_notification_commands

notify-service-by-email

host_notification_commands

host-notify-by-email

email

admin@domena

}

Řádky notification_options označují, které typy případů se budou odesílat tj. w – warnig (varování), u – unreachable (nedostupný), c – critical (kritické situace), r – recovery (oznámení poslané v případě vrácení hodnot do normálu), f – flapping (situace, které se často mění, viz kap. 3), d – down (pokud je sledovaný server zastaven).

Vlastní práce

31

Dvojice notification_commands volá příkazy ze souboru commangs.cfg, ve kterém jsou definovány zprávy pro služby (service) a pro servery (host). hosts.cfg Tento konfigurační soubor není ve výchozí instalaci, ale vytvořením se zpřehlední seznam hostů. define host{ use

generic-host

host_name

webserver

alias

virtualni_webserver

address

10.20.30.10

contacts

admin

parents

physical1

icon_image

centos40.png

statusmap_image

centos40.gd2

}

Jednoduché definování hosta na základě šablony generic-host. Označíme jméno, adresu, obrázek pro lepší vizuální dojem, rodiče pro snadnější přehled ve vygenerované mapě všech zařízení. V šabloně se nachází nastavení, které se použije pro všechny servery. Zde se uvádí perioda sledování. Výchozí nastavení je 24x7 což je nepřetržité monitorování. Dále zapnutí nebo vypnutí informačních služeb jako jsou například zapnutí „flapovací“ detekce, zapnutí oznámení apod. nrpe.cfg Modul Nagios systému pro sběr dat ze vzdálených zařízení. Zajišťuje šifrovanou komunikaci SSL (viz kap. 3). Sběr dat probíhá mezi dvěma NRPE procesy, kdy administrátorská část vyzve klientskou část k předložení dat, která jsou nakonfigurována ve výše zmíněných konfiguračních souborech. Pokud klientský NRPE proces předloží správná data vše je vyhodnoceno a dále zpracováváno. Ve druhém případě se vyhodnotí nečitelný vstup a uživateli se zobrazí varovná zpráva.

Vlastní práce

32

Obr. 4

funkčnost modulu NRPE. Převzato z Nagios Core (2012).

6.4.2

Implementace Munin

Program Munin je rozdělen na serverovou a klientskou část. Klientská část obsahuje démon munin-node, ke kterému se serverová část připojuje a získává informace. Serverová část má cronem (opakující se naplánovaná úloha) spouštěný skript, který stáhne informace od klientů a vykreslí z nich grafy. Instalace Jako v přechozím případě použijeme instalační program yum: yum install munin

Pokud je instalována pouze klientská stanice, postačí nainstalovat pouze klientský program Munin-node. Konfigurační soubory  munin.conf – hlavní konfigurační soubor serverové části. Definuje místa, kde se budou ukládat logy a webové části. Zde se také definují klienti a jejich adresy.  munin-node.conf – konfigurační soubor klientské části. Určuje adresy, které k démonovi mohou přistoupovat. Nastavuje uživatele, prostřednictvím kterého proces operuje na serveru.  munin-htpasswd – zde se definují uživatelé a jejich hesla.  plugins – adresář obsahující aktivní pluginy.  plugin-conf.d – obsahuje konfigurační soubory pro pluginy. Definuje se zde oprávnění pro nástroje (například postfix, hddtemp). Konfigurace Ve srovnání s programem Nagios je konfigurace méně náročná. Většina příkazů je dostatečně objasněna přímo v konfiguračních souborech. Pro detailnější rozbor příkazů je doporučena domovská stránka. (Munin, 2014) munin.conf V tomto souboru se nastavují všechny klientské stanice a způsob a rozměry generování grafů: dbdir

/var/lib/munin

Vlastní práce

33

htmldir

/var/www/munin

logdir

/var/log/munin

rundir

/var/run/munin

graph_strategy

cron

html_strategy

cron

[webserver] address 10.20.30.10 use_node_name yes

První 4 řádky jsou určení míst, kam se bude ukládat RDD databáze, webový výstup, logovací výstup a údaje o procesu (pid). Řádky se strategií určují generování grafů. V tomto případě se volí generování pomocí cronů. Lze použít i generování prostřednictvím cgi (common gateway interface) skriptů. Poslední tři řádky nastavují klienta. V hranatých závorkách se definuje název, který bude zobrazen na webovém přístupu. Řádka use_node_name rozhoduje, jestli se bude využívat jméno klienta, které určí jeho démon. Tento příkaz poslouží, pokud chceme použít jiné jméno klienta. munin-node.conf Soubor pro konfiguraci sledovacího démona. log_level 4 log_file /var/log/munin-node/munin-node.log pid_file /var/run/munin/munin-node.pid user root group root ignore_file allow ^127\.0\.0\.1$ allow ^10\.20\.30\.1$ host * port 4949

Log_level nastavuje způsob logování démonu v rozmezí 0-4. Úroveň 4 loguje všechno dění a označuje se jako debug. Další dva příkazy nastavují cesty k logu a číslu procesu. Řádky user a group určují oprávnění, pod kterými bude démon pracovat. Příkaz ignore_file určuje pomocí regulárních výrazů soubory, které nebudou brány jako pluginy. Zbylé nastavení má na starosti síťový přístup k démonu. plugins a plugin-conf.d Adresář plugins obsahuje všechny použité pluginy. Podmínkou, aby plugin byl aktivní, jsou spustitelná práva. Druhou podmínkou pro aktivní plugin je, že nesmí vyhovovat regulárnímu výrazu za příkazem ignore_file v souboru munin-

Vlastní práce

34

node.conf. Pokud jsou splněny obě podmínky, jsou výsledky z příslušného pluginu vykreslovány do grafu. Druhý adresář obsahuje konfigurace. V konfiguračním souboru se obvykle uvádí uživatel, pod jehož právy se plugin bude vykonávat, kritická a varovací hodnotu a definování proměnných, které jsou nutné pro správné vykonání pluginu. [pluginname] user

username

group

groupname

env.variablename obsah promene

6.4.3

env.critical

92

env.warning

95

Implementace sítě

Nastavení sítě je provedeno vytvořením konfiguračního souboru virtuálního rozhraní pomocí textového editoru Vi: vi /etc/sysconfig/network-scripts/ifcfg-eth0:0

Do nově vzniklého souboru je zapsána konfigurace monitorovací sítě: DEVICE=eth0:0 ONBOOT=yes BOOTPROTO=none HWADDR=1b:36:b3:fe:6c:d4 IPADDR=10.20.30.20 NETMASK=255.255.255.0 NETWORK=10.20.30.0 BROADCAST=10.20.30.255

Po uložení souboru musí být restartováno síťové připojení. Toto nastavení se opakuje na každém stroji lišící se v IP adrese, Mac adrese a případně v zařízení. Posledním krokem je povolení portů ve firewallu na příslušné rozhraní: /sbin/iptables -I Firewall 1 -i eth0:0 -m tcp -p tcp -dport 4949 -j ACCEPT

Uvedený port je výchozí pro program Munin. Celý příkaz přidá do bloku Firewall na první místo v tabulce povolení pro port 4949 na rozhraní eth0:0. Nyní stačí firewall uložit.

Vlastní práce

6.4.4

35

VPN implementace

Pro řešení VPN tunelu je použit volně dostupný program OpenVPN. Je to uživatelsky přívětivý, robustní, a dobře konfigurovatelný VPN démon, který bezpečně spojí dvě nebo více sítí pomocí šifrovaného tunelu. (OpenVPN, 2014) Instalace Opět jako v předchozích případech využijeme balíčkový program yum: yum install openvpn

Konfigurace První krok povede ke generování certifikátů pomocí nástrojů v instalaci. Je doporučeno si skripty zkopírovat na jiné umístění, aby nebyly při aktualizaci balíčku přepsány: rsync -av /usr/share/doc/openvpn/easy-rsa /etc/openvpn/

Konfigurace proměnných pro generování certifikátů se upravuje v souboru „/easyrsa/2.0/vars“. Zde je vhodné nastavit atributy klíče: název, země, email, velikost klíče. Vše je exportováno do prostředí skriptem: . ./vars

pokud jsou v adresáři „keys“ vzorové klíče, je vhodné je vymazat skriptem „clean_all“. Poté jsou klíče vygenerovány příkazy: /build-ca ./build-key-server server ./build-key-pass client1 ./build-dh

Je vhodné certifikáty zkopírovat na jiné místo nejlépe ke konfiguračním souborům. Nastavení VPN serveru se provádí v adresáři „/etc/openvpn/“, kde je vytvořený nebo z instalačních souborů zkopírovaný soubor „server.conf“ a přepsán na požadované nastavení: port 1194 proto tcp dev tap ca /etc/openvpn/keys/ca.crt cert /etc/openvpn/keys/pdevel.crt key /etc/openvpn/keys/pdevel.key dh /etc/openvpn/keys/dh2048.pem ifconfig-pool-persist ipp.txt server-bridge 10.20.30.0 255.255.255.0 10.20.30.0 10.144.1.10

Vlastní práce

36

client-to-client keepalive 10 120 comp-lzo status /var/log/openvpn/openvpn-status.log log /var/log/openvpn/openvpn.log log-append /var/log/openvpn/openvpn.log verb 4

Bylo možné si vybrat ze dvou možných zařízení komunikujících na jiných vrstvách ISO/OSI modelu. TUN zařízení pracuje na 3. síťové vrstvě. Bylo vyloučeno skrze problémy ve směrování, protože VPN server není spuštěn na výchozí bráně a monitorovací server by musel obsahovat záznamy ve směrovací tabulce. S použitím druhého zařízení není modifikace ostatních prvků v síti nutná. Je použito zařízení TAP, které pracuje na 2. linkové vrstvě. V konfiguračním souboru jsou definovány cesty ke klíčům a cesty k logům. Příkaz server-bridge nastavuje do jaké sítě a v jakém rozsahu bude klient dostávat adresy. Položka keepalive definuje testování stavu klienta. První parametr značí periodu v sekundách spouštění příkazu na dostupnost a druhý parametr určuje maximální dobu v sekundách pro odpověď na tento příkaz. Řádek comp-lzo povoluje funkci komprimace při výměně dat. Funkce je doporučována vzhledem k zvýšení rychlosti výměny dat. Poslední řádek verb definuje úroveň logování, kde nejvyšší číslo 9 se používá pro ladění nastavení, protože jsou do logu zapisovány všechny možné informace. Nastavení klienta je obdobné jako v případě serveru. Protokol a zařízení musí být stejně nastaveno jako na serveru. Klient musí mít pro přístup staženou certifikační autoritu, svůj certifikát a klíč k certifikátu. Celé nastavení se liší v těchto řádcích: client remote 192.168.0.40 1194 ns-cert-type server

Vzhledem k použité technologii je na serveru nutné vytvořit síťový most mezi rozhraním k monitorovací síti a TAP zařízením. K tomu poslouží předpřipravené skripty z instalace „/usr/share/doc/openvpn/sample-scripts/bridge-start“ a „/usr/share/doc/openvpn/sample-scripts/bridge-stop“. Použít lze také manuální postup pomocí nástroje brctl : /usr/sbin/brctl br0 /usr/sbin/brctl addbr br0 /usr/sbin/brctl addif br0 tap0 /usr/sbin/brctl addif br0 eth1

Vlastní práce

6.5

37

Návrh testovacích scénářů

Testování nového systému bude probíhat v několika krocích. Důraz je kladen především na rychlost a dostatečnou rozmanitost. 1. Rychlost Testování proběhne simulací ztráty dostupnosti na síti. Bude provedeno vytáhnutí UTP kabelu ze síťové karty a sledování doby reakce od ztráty konektivity až po přijetí emailové zprávy o chybě. 2. Spolehlivost Spolehlivostí je v tomto systému myšleno co nejméně přerušované generování grafů v nástroji Munin. Cílem je získání co nejspojitějších dat bez žádných výpadků. Výsledek bude poměr mezi součtem časů výpadků a součtem času naměřených dat. 3. Test sítě Bude proveden odposlech komunikace monitorovacích nástrojů z vnitřní sítě za účelem zjištění přihlašovacích údajů a monitorovaných dat. Externí přístup je zajištěn VPN tunelem chráněným zaheslovanými certifikáty, proto přístup z Internetu byl vyhodnocen jako bezpečný a testována bude možnost odposlechu z vnitřní sítě. 4. Dostatečná rozmanitost sledovaných prostředků Tento scénář má za úkol otestovat spolehlivost v odhalování malých problémů na sledovaném prvku. Bude prováděno vypnutí démonu, zaplňování operační paměti, zaplněním náhodné části disku (home, var, tmp), přetěžování mailové fronty. Dobrý výsledek tohoto testu bude, pokud monitorovací systém zjistí chybu alespoň do 30 minut.

Vlastní práce

6.6

38

Výsledky testovacích scénářů

1. Rychlost V tomto testování hodně záleželo na nastavené periodě obnovování, která je nastavena na 90 vteřin. Emailová zpráva informující o výpadku byla doručena do 3 minut a má strukturu, viz obr. 5. Proto je výsledek testu hodnocen jako dobrý a monitorovací systém splnil požadavky.

Obr. 5

Nagios – email o ztrátě konektivity.

Vlastní práce

39

2. Spolehlivost Cílem testu bylo zjistit spolehlivost generování grafů v průběhu 1 měsíc. Testování proběhlo na náhodně vybraných sledovaných prostředcích a na různých strojích. Zapojen do testu byl:  Webový server – MySQL dotazy

Obr. 6

MySQL – měsíční souhrn SQL dotazů za sekundu.

 Databázový server – dlouhotrvající dotazy

Obr. 7

DB server – měsíční souhrn dlouhotrvajících SQL dotazů za sekundu.

Vlastní práce

40

 Zálohovací server – průměrné zatížení procesoru

Obr. 8

Průměrné zatížení procesoru – zálohovací server.

 Webový server – počet sezení

Obr. 9

Apache/PHP – počet sezení.

Za celý měsíc se na těchto grafech nevyskytla delší mezera v monitorování, proto tento nástroj splnil očekávání. Za výhodu se dá považovat i přenositelnost uchovaných dat z instalace na druhou instalaci. Tato situace byla vyzkoušena při reinstalaci Muninu. Nově nainstalovaný program dokázal navázat na data předchozí instalace bez problému.

Vlastní práce

41

3. Test sítě Pomocí programu Wireshark byla odchytávána komunikace webového přístupu a komunikace síťových modulů daných nástrojů (NRPE, munin-node). Odposlech probíhal spuštění zachytávání paketů na obou stranách (klient i server). V odposlechnutých paketech již nebylo možné nalézt přihlašovací údaje, protože webový přístup byl omezen pouze na šifrovaný protokol HTTPS (viz kap. 3). Síťový modul systému Nagios pro komunikaci mezi serverem a klientem využívá šifrované spojení zajištěné protokolem SSL. Proto odposlechnutá komunikace neobsahuje žádná relevantní data. U systému Muninu je dovoleno se na síťový modul munin-node připojit jen z povolených adres v konfiguračním souboru. U většiny je povolena pouze adresa serveru. Proti odposlouchávání komunikace mezi serverem a klientem je od verze 1.4 umožněno využít protokol TLS (viz kap. 3.1.6). Proto v odposlechnuté komunikaci nebyly opět řádná relevantní data. Externí přístup VPN tunelem dopadl nejhůře ze všech testovaných okruhů, skrze uživatelskou náročnost. Nutnost mít na každém přístupovém bodu nainstalovaného VPN klienta i s certifikáty, je dosti nepříjemná věc, zvláště když se jedná jen o rychlou kontrolu stavu sítě z veřejně přístupného bodu např.: knihovna, vypůjčený počítač.

Vlastní práce

42

4. Test dostatečné rozmanitosti monitorovacího systému Z hlediska požadavků na systém je toto nejdůležitější test. Simulace proběhne na namátkou vybraných prvcích a službách. Výsledek tohoto testu není rychlost odpovědi systému, ale reakce na danou situaci.  Vypnutí démona httpd (Apache) – test byl vyvolán posláním „KILL -9“ signálu na hlavní proces httpd. Doba reakce systému od provedení až k poslání emailové zprávy trvala: 3 minuty 55 sekund.

Obr. 10

Nagios – zpráva o pádu webového serveru.

 Zaplňování operační paměti na zálohovacím serveru – na zaplnění paměti byl vytvořen skript s nekonečnou smyčkou a skládání řetězců do proměnné. Od spuštění skriptu po doručení chybové zprávy: 5 minut 30 sekund.

Obr. 11

Nagios – email s překročení kritické hodnoty na operační paměti.

Vlastní práce

43

 Zaplnění disku „/tmp“ na DB serveru – na rychlé zaplňování adresáře byl použit podobný skript jako v minulém případě, ale data byla ukládána do souboru. Celkový čas od spuštění skriptu po reakci systému byl 6 minut 20 sekund.

Obr. 12

Nagios – email s překročením maximální hranice na zbývající volné místo.

 Zaplnění mailové fronty na poštovním serveru – tento test byl vyvolán cyklem odesílání emailové zprávy. Po dosažení určitého počtu neodeslaných emailů by měl monitorovací systém zahlásit problém. Celý proces od spuštění odesílání zpráv až po reakci od systému uplynula doba: 8 minut a 36 sekund.

Obr. 13

Nagios – překročení kritického počtu neodeslaných mailů.

Vlastní práce

6.6.1

44

Souhrn výsledků testů

Všechny testy byly splněny překvapivě v rychlé odezvě, proto se dá odvodit, že systém je nastaven správně a připraven pro nasazení do produkčního provozu. Na základě testu pro externí přístup pravděpodobně bude upraven požadavek na VPN tunel, protože dostupnost webového přístupu k monitorovaným datům odkudkoliv bez nutnosti certifikátu se stane požadavkem.


45

7 Ekonomické zhodnocení Tato kapitola nastíní finanční stránku daného řešení. Ve výpočtech je uvedena osoba dostávající v průměru 150 Kč na hodinu.

7.1

Počáteční investice

Vzhledem k faktu, že v celé práci se objevují jen open source programy, tak investice do programového vybavení jsou minimální. Jediné vyšší investice se vztahují k pracovní době osoby, která tento systém implementuje. Odhad na rozšíření stávajícího systému o výše zmiňované prvky a prostředky je 20 – 30 hodin práce i s testováním. Je uvedeno rozmezí hodin, protože závisí na odbornosti osoby. Prvotní náklady na monitorovací server jsou nulové, protože bude vytvořen virtuální stroj na již běžícím serveru. Výkon fyzického stroje by měl postačit na provoz monitorovacího serveru. Součet všech počáteční investic činní v maximálním možném čase 4 500 Kč.

7.2

Provoz a údržba

Provoz a údržba vyžadují dohledovou osobu dle specifikací. (viz kap. 6.3.4) Osoba bude placená hodinově za odvedenou práci, kterou musí vykázat do informačního systému společnosti. Cena bez předchozích statistik lze hůře odhadnout, a proto jsou náklady jen orientační. Měsíc bude počítán se 30 dny. Pokud osoba každý den vynaloží hodinovou práci na analýzu monitorovaných dat, je to ve výsledku měsíční mzdy 4 500Kč. Protože systém nevyžaduje každodenní analýzu, je v částce již započítán čas na řešení případných problémů. Nároky na provoz monitorovacího serveru jsou pouze ve vyšší elektrické spotřebě fyzického serveru. Na serveru je zdroj o výkonu 300W, a spuštěny jsou na něm dva virtuální servery. Průměrná zátěž je odhadována na 200W tj. 75W na monitorovací server, protože není tak zatěžovaný jako druhý produkční virtuální server. Provoz na měsíc je tedy při ceně 5Kč za kWh 270Kč. Celková průměrná cena na provoz a údržbu je 4 770Kč.

7.3

Úspory

Ztrátových položek může vzniknout hned několik. Primárně se jedná o delší výpadky produkčních služeb zapříčiněné nedostatečně rychlým odstraněním problému. Tím vzniká nárok klienta na slevu používané služby a v krajním případě i ztrátu klienta. Tutu ztrátu lze cenově velmi obtížně odhadnout, protože vše závisí na individualitě klienta.


46

Další ztráta může vzniknout, pokud monitoring nebude dostatečně informovat například o teplotě. Při vyšší teplotě disků se zkracuje životnost a to má za následek nečekané pády a nutnost koupě nových pevných disků. V extrémních případech může situace dojít až ke ztrátě dat na poškozeném serveru. Díky vylepšenému monitorovacímu systému budou tyto situace, které představují pro firmu snížení cash-flow a ušlý zisk, nastávat s výrazně nižší frekvencí a v menším rozsahu, tudíž díky novému monitorovacímu systému bude realizována větší finanční úspora.

7.4

Shrnutí

V tabulkách níže je souhrn finančních nákladů na nový monitorovací systém. Tab. 2

Jednorázové investice nového monitoringu

Programové vybavení Pracovník Celkem Tab. 3

Jednorázové investice (Kč) 0 4500 4500

Pravidelné měsíční náklady monitorovacího systému

Pravidelné měsíční náklady (Kč) Spotřeba el. Energie 270 Pracovník 4500 Celkem 4770

Závěr

47

8 Závěr Dobře navrhnutý a implementovaný monitorovací systém tvoří základ každého serverového seskupení. Tato práce se zabývala rozšířením stávajícího systému o několik nových zařízení a implementací nových sledovaných prostředků do stávajících serverů. V práci bylo vytyčeno několik postupně na sebe navazujících cílů:  Popis stávající monitorovacího systému – tato část měla za úkol analyzovat stávající topologii a zkoumat stávající monitorovací systém. Bylo odhaleno hned několik nedostatků, mezi které se řadily nedostatečně detailní informace o každém typu aktivní služby např.: o frontě na mailovém serveru, sledování počtu připojení k databázi, sledování celkového počtu podprocesů daných služeb. Další nedostatek byl v podobě nešifrovaného externího přístupu.  Analýza uživatelských požadavků – práce na tomto bodu spočívala ve shromažďování informací nutných pro rozšíření množiny sledovaných prostředků na serverech. Náplň práce spočívala v diskuzi s vedením podniku o požadavcích na monitorovaná data. Poté následovala vlastní úvaha nad daty a vyhotovení seznamu sledovaných prostředků zvlášť pro každý server.  Implementace nového systému – v této části práce bylo cílem uvést do chodu celý nově navrhnutý monitorovací systém. V implementaci sítě a monitorovacích nástrojů, až na drobnou komplikaci v konfiguračním souboru programu Munin s názvy serverů, se cíl podařilo splnit. Problém nastal v implementaci VPN tunelu, kde místo virtuálního síťového rozhraní musela být použita druhá síťová karta s vlastním rozhraním eth1, protože se autorovi nepodařilo vytvořit síťový most mezi virtuálním rozhraním eth0:0 a rozhraním tap0 vytvořené program OpenVPN.  Testování – tato část probíhala jako simulace možných problémů a čekání na reakci systému. Pro autora by byl dostačující výsledek reakce systému do 20 min u většiny služeb. Tento údaj neplatí u testu dostupnosti, protože reakce systému u tohoto testu, by byla dostatečná do 5 min. Výsledek testu proto byl překvapující, protože všechny testované problémy byly odhaleny a odeslány na email administrátorovi maximálně do 10 min a dostupnost serveru do 3 min. Důraz byl kladen na včasné odhalení vznikajících problémů, které mohou vyústit i do finančních ztrát. Tento požadavek byl podle testů splněn, a proto práce splnila požadované cíle. Monitorovací systém je již plně funkční a nasazen. Za dobu působení nebyla shledána žádná chyba, proto autor tento monitorovací systém doporučuje.

Literatura

48

9 Literatura ANDRE. Understanding Linux CPU Load: when should you be worried?. [online]. [cit. 2014-01-29]. Dostupné z: http://blog.scoutapp.com/articles/2009/07/31/understanding-loadaverages BARRETT, D., SILVERMAN, R., BYRNES, R. SSH, the secure shell: the definitive guide. 2nd ed. Sebastopol, CA: O'Reilly, c2005, xviii, 645 p. ISBN 05-960-0895-3. BENDA, L. Integrace monitorovacího systému počítačové sítě na bázi open source a komerčních produktů. Brno, 2011. Bakalářská práce. Mendelova univerzita v Brně. Vedoucí práce Ing. Martin Pokorný, Ph.D. BOUŠKA, P. SNMP: Simple Network Management Protocol. 2006 [online]. [cit. 201401-28]. Dostupné z: http://www.samuraj-cz.com/clanek/snmp-simplenetwork-management-protocol/ BRINKE, B. Instant Munin plugin starter write custom scripts to monitor, analyze, and optimize any device in your network. Online-Ausg. Birmingham: Packt Pub, 2013. ISBN 18-496-9674-8. CENTOS PROJECT. Centos. 2014 [online]. [cit. 2014-02-07]. Dostupné z: http://www.centos.org/ ČIHAŘ, M. Munin: monitorování serverů. [online]. [cit. 2014-02-25]. Dostupné z: http://cihar.com/publications/linuxsoft/munin-monitorovani-serveru.html DOČEKAL, M. Správa linuxového serveru: Monitorování serveru pomocí nástroje Munin. [online]. 2011 [cit. 2014-02-25]. Dostupné z: http://www.linuxexpres.cz/praxe/sprava-linuxoveho-serveru-monitorovaniserveru-munin GÉRYK, J. Monitorování provozu distribuovaných informačních systémů. Brno, 2008. Diplomová práce. CVT FI MU. Vedoucí práce doc. Ing. Michal Brandejs, CSc. GUTHRIE, M. Instant Nagios Starter. Packt Publishing, 2013. ISBN 978-178-2162506. HAŠUĽ, M. Monitorování IT infrastruktury. Brno, 2010. Diplomová práce. KPSK FI MU. Vedoucí práce doc. Ing. Jan Staudek, CSc. HOLUBEC, P. Systém pro monitoring síťových serverů a služeb. Brno, 2013. Bakalářská práce. Vysoké učení technické v Brně. Vedoucí práce Ing. Pavel Očenášek, Ph.D. JANDA, M. Monitoring hybridní síťové infrastruktury. Brno, 2009. Bakalářská práce. FIT VUT v Brně. Vedoucí práce Smrž Pavel, doc. RNDr., Ph.D. JOSEPHSEN, D. Nagios: building enterprise-grade monitoring infrastructure for systems and networks. Second edition. Prentice Hall, 2013, xix, 275 pages. ISBN 01-331-3573-X. KABELOVÁ, A., DOSTÁLEK, L. Velký průvodce protokoly TCP/IP a systémem DNS. 5., aktualiz. vyd. Brno, 2008, 488 s. ISBN 978-80-251-2236-5.

Literatura

49

LOSHIN, P. Essential email standards: RFCs and protocols made practical. New York: John Wiley, 1999, xxii, 339 s. ISBN 04-713-4597-0. LUCAS, M. SSH Mastery OpenSSH, PuTTY, tunnels and keys. S.l., 2012. ISBN 14-7006971-7. MAURO, D., SCHMIDT, K. Essential SNMP. 2nd ed. Beijing: O´Reilly, 2005, 442 s. ISBN 05-960-0840-6. MUNIN. Munin-monitoring. [online]. 2014, 03/28/14 22:55:06 [cit. 2014-05-06]. Dostupné z: http://munin-monitoring.org/ NAGIOS CORE. Nagios Addons. Nagios.sourceforge.net [online]. Nagios Core Development Team and Community Contributors, 2009-2012 [cit. 2014-05-19]. Dostupné z: http://nagios.sourceforge.net/docs/3_0/addons.html NAGIOS. Nagios: The Industry Standard in IT Infrastructure Monitoring. [online]. 2014 [cit. 2014-04-15]. Dostupné z: http://www.nagios.org/ OPENVPN TECHNOLOGIES. OpenVPN [online]. 2002-2014 [cit. 2014-05-06]. Dostupné z: http://openvpn.net/ OPPLIGER, R. SSL and TLS: theory and practice. Boston: Artech House, c2009, xxi, 257 p. Artech House information security and privacy series. ISBN 15-9693447-6. OSCACHE. Java.net [online]. 2013 [cit. 2014-05-18]. Dostupné z: https://java.net/projects/oscache RFC 2616. Hypertext Transfer Protocol. [online]. 1999 [cit. 2014-05-19]. Dostupné z: http://tools.ietf.org/html/rfc2616 RFC 3954. Cisco Systems NetFlow Services Export Version 9. Ietf.org [online]. 2004 [cit. 2014-05-15]. Dostupné z: http://www.ietf.org/rfc/rfc3954.txt RFC 5424. The Syslog Protocol. [online]. 2009 [cit. 2014-02-25]. Dostupné z: http://tools.ietf.org/html/rfc5424 RFC 5905. NTPv4 Specification. [online]. 2010 [cit. 2014-02-26]. Dostupné z: https://tools.ietf.org/html/rfc5905 RYDER, T. Nagios core administration cookbook: develop an integrated monitoring solution for virtually any kind of network. Online-Ausg. Birmingham [u.a.]: Packt Publ, 2013. ISBN 18-495-1556-5. SZABO, G. Monitoring lokální sítě prostřednictvím Nagiosu. Brno, 2012. Bakalářská práce. KPSK FI MU. Vedoucí práce doc. RNDr. Eva Hladká, Ph.D. WIKIPEDIA, THE FREE ENCYCLOPEDIA, Comparison of network monitoring systems. [online]. 2014a [cit. 2014-03-19]. Dostupné z: http://en.wikipedia.org/wiki/Comparison_of_network_monitoring_systems WIKIPEDIA, THE FREE ENCYCLOPEDIA, HTTP Secure. [online]. 27. 04. 2014b, [citováno 24. 02. 2014]. Dostupný z:http://en.wikipedia.org/w/index.php?title=HTTP_Secure&oldid=60600352 9.

Literatura

50

WIKIPEDIA, THE FREE ENCYCLOPEDIA, Out-of-band management. [online]. 2014c [cit. 2014-04-23]. Dostupné z: http://en.wikipedia.org/wiki/Out-ofband_management WIKIPEDIA, THE FREE ENCYCLOPEDIA, RAID. [online]. 2014d [cit. 2014-01-28]. Dostupné z: http://cs.wikipedia.org/wiki/RAID

Monitorovací systém firemní počítačové sítě na bázi open source řešení

Recommend Documents