Monitor zátěže serverů

České vysoké učení technické v Praze Fakulta elektrotechnická Diplomová práce Monitor zátěže serverů Marek Fiala Vedoucí práce: Ing. Michal Šoch, Ph.D. Studijní program: Elektrotechnika a informatika, strukturovaný, navazující magisterský Obor: Výpočetní technika Květen 2009

Poděkování Na tomto místě bych rád poděkoval především vedoucímu práce Ing. Michalovi Šochovi, Ph.D. za cenné rady a připomínky v průběhu zpracování diplomové práce.

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

Abstrakt Tato diplomová práce popisuje návrh a implementaci systému, který umožňuje zaznamenávat údaje o činnosti operačního systému unix serverů. Součástí práce je také webová aplikace, která umožňuje zobrazovat nasbíraná data ve formě grafů a tyto data statisticky zpracovávat. Abstract This diploma thesis describes the design and implementation of a system that allows to record data about the activity of UNIX servers. A part of the thesis is also a web application that enables to display collected data in graphs and the data can be processed statistically.

Obsah Seznam obrázků... 11 Seznam tabulek... 12 1. Úvod... 13 2. Požadavky na systém... 15 3. Existující systémy... 17 3.1. HotSaNIC... 17 3.2. Munin... 18 3.3. Cacti... 19 4. Analýza a návrh řešení... 21 4.1. Architektura systému... 21 4.2. Způsob ukládání naměřených dat... 22 4.2.1. Textové / XML / binární soubory... 22 4.2.2. Relační databáze... 23 4.2.3. RRD databáze... 23 4.3. Způsob ukládání dat pro Shel-Node... 24 4.4. Způsob ukládání dat pro Shel-Master... 25 4.5. Přidávání nových pluginů na měřený server... 27 4.6. Komunikace mezi Shel-Master a Shel-Node... 27 4.6.1. Vlastní protokol... 28 4.6.2. SSH... 28 4.6.3. XML-RPC / SOAP... 28 4.6.4. SNMP... 28 4.7. Shel-Node... 29 4.8. Shel-Master... 31 4.8.1. Databáze... 31 4.8.2. Datové úložiště... 33 4.8.3. Stahování dat z měřených serverů... 33 4.9. Webová aplikace... 34 4.9.1. Zobrazování a správa grafů... 36 4.9.2. Konfigurace měřených hodnot... 37 4.9.3. Přidávání nových pluginů... 38 5. Implementace... 39 5.1. Volba použitých technologií... 39 5.1.1. RRDTool... 39 5.1.2. Použité technologie pro Shel-master... 41 5.1.3. Použité technologie pro Shel-node... 41 5.1.4. Použité technologie na webovou aplikaci... 42 5.1.5. Použité technologie Databázový systém... 43 5.2. Volba vývojového prostředí... 43 5.3. Volba nástroje pro tvorbu grafů... 44 5.4. Implementace Shel-node... 45 5.4.1. Démon... 46 5.4.2. Měřící skripty... 47 5.4.3. Datové úložiště... 48 5.4.4. Komunikace s Shel-master serverem... 49 5.4.5. Konfigurační soubory a logování... 52 5.4.6. Shel-node balík pro Debian... 53 9

5.5. Implementace Shel-master... 54 5.5.1. Cron tabulka... 55 5.5.2. Datové úložiště... 56 5.5.3. Stahování dat... 57 5.5.4. Změna konfigurace pluginů/senzorů... 58 5.6. Zend Framework... 59 5.6.1. Bootstrap soubor (index.php)... 61 5.6.2. Model (model)... 61 5.6.3. Řadič (controller)... 62 5.6.4. Pohled (view)... 62 5.7. Implementace webové aplikace... 63 5.7.1. Struktura webové aplikace... 63 5.7.2. Grafy... 64 5.7.3. Autentizace a autorizace uživatelů... 67 5.7.4. Informace o stavu systému... 67 5.7.5. Další funkce webové aplikace... 68 6. Statistické zpracování naměřených dat... 69 7. Testování... 71 8. Závěr... 73 Seznam použité literatury... 75 Příloha A. Instalace měřeného serveru... 77 Příloha B. Implementace pluginů... 79 Příloha C. Databázové schéma... 87 Příloha D. Obsah přiloženého CD... 89 10

Seznam obrázků Obr. 1 - Webové rozhraní HotSaNIC... 17 Obr. 2 - Webové rozhraní nástroje Munin... 18 Obr. 3 - Grafy síťových spojení v Muninu... 19 Obr. 4 - Webové rozhraní Cacti... 20 Obr. 5 - Ukázka grafů v Cacti... 20 Obr. 6 - Architektura systému... 21 Obr. 7 - ER model dat. Úložiště... 23 Obr. 8 - Komponenty Shel-Node... 29 Obr. 9 - Komponenty Shel-Master... 31 Obr. 10 - Schéma databáze pro Shel-Master... 32 Obr. 11 - Proces stahování dat... 34 Obr. 12 - Rozvržení webového rozhraní... 35 Obr. 13 - Uživatelské role a základní případy užití... 35 Obr. 14 - Datový model pro senzory a pluginy... 37 Obr. 15 - Komponenty Shel-Node... 45 Obr. 16 - Změna konfigurace měřeného serveru... 51 Obr. 17 - Komponenty Shel-Master... 54 Obr. 18 - Diagram tříd podpory více komunikačních protokolů... 58 Obr. 19 - Část datového modelu grafů... 64 Obr. 20 - Ukázka grafu využití CPU... 65 Obr. 21 - Ukázka grafu využití webového serveru Apache... 65 Obr. 22 - Definice grafu... 66 Obr. 23 - Stránka serveru... 66 Obr. 24 - Stránka zobrazující stav měření... 68 Obr. 25 - Typický průběh využití CPU u webového serveru... 69 Obr. 26 - Výsledná podoba lineárního proložení... 70 Obr. 27 - Seznam měřených serverů... 77 Obr. 28 - Plugin počet běžících procesů... 79 Obr. 29 - Plugin forks... 80 Obr. 30 - Plugin CPU... 80 Obr. 31 - Plugin Load... 81 Obr. 32 - Plugin obsazení operační paměti... 82 Obr. 33 - Plugin obsazení disku... 83 Obr. 34 - Plugin datového toku na síťových rozhraních... 83 Obr. 35 TCP spojení... 84 Obr. 36 - Plugin Apache... 85 Obr. 37 - Plugin dotazy na MySQL databázi... 85 Obr. 38 ER model databáze... 87 11

Seznam tabulek Tabulka 1 Odhad množství ukládaných dat na Shel-Node... 24 Tabulka 2 Srovnání rychlosti SQL a RRD... 26 Tabulka 3 - Datové typy... 40 Tabulka 4 - Způsob agregace - consolidation function... 40 Tabulka 5 - příkazy login skriptu... 50 Tabulka 6 - Debian balík... 53 Tabulka 7 - hustota ukládaní dat na centrálním serveru... 56 Tabulka 8 - Seznam řadičů... 63 12

1. Úvod Již delší dobu propagují firmy své produkty a služby prostřednictvím Internetu. V dnešní době však vznikají společnosti, pro které znamená Internet jediný zdroj příjmů. Tyto společnosti jsou na dostupnosti svých síťových služeb přímo závislé. Ať už jde o webové stránky, elektronickou poštu, nebo další služby, jsou poskytovány pomocí serverů připojených do sítě Internet. Správná a nepřetržitá funkčnost serverů v režimu 7/24/365 je tedy naprostá nutnost. Zajistit dostupnost služeb má za úkol zpravidla administrátor serveru. K tomu musí mít velmi podrobný přehled o tom, co se na serveru děje a to nejen v danou chvíli, ale především zpětně v rámci určitého časového úseku. Dostatečný zdroj informací o stavu serveru je samozřejmě potřebný také při řešení aktuálního problému. Pokud má administrátor na starost pouze jeden, případně dva servery, obejde se většinou bez dalších speciálních nástrojů. Počet uživatelů Internetu však velmi rychle stoupá a s tím i nároky na hardwarové vybavení serverů. Velké společnosti (Google, Yahoo) zjistili, že se finančně vyplatí nakoupit větší množství neznačkových levných serverů, oproti nákladným a výkonným zařízením renomovaných značek. Díky tomu nespravuje administrátor pouze několik serverů, ale jedná se zpravidla o desítky (u větších společností až stovky) serverů. Při tomto počtu je nezbytné mít centralizovaný nástroj, který bude poskytovat podrobné informace o běhu a stavu jednotlivých spravovaných serverů. Software pro sledování informací o stavu serveru (monitoring) lze rozdělit na dvě samostatné kategorie: 1. Sledování aktuální dostupnosti služeb. 2. Dlouhodobé sledování stavu serveru. Do první kategorie se řadí nástroje, které monitorují především aktuální stav služeb, případně zaznamenávají historii jednotlivých výpadků. Umožňují většinou také zasílání upozornění například pomocí SMS. Do druhé kategorie patří systémy, které sledují dlouhodobě různé parametry běhu systému a tyto informace ukládají k pozdějšímu zpracování (zobrazení grafů). Vzniklo však i několik aplikací, jejichž funkce a možnosti zasahují více či méně do obou výše uvedených kategorií. Tato práce popisuje aplikaci, která spadá do druhé zmiňované kategorie. Systém tedy nebude umožňovat měřit aktuální dostupnost služeb, ani zasílat informace 13

v případě výpadku služby. Popisovaný systém má sloužit jako nástroj především pro předcházení problémů při správě serveru a také jako důležitý zdroj informací při jejich řešení. Systém je určen především pro správu většího množství serverů. 14

2. Požadavky na systém Cílem této práce je vytvořit aplikaci, která bude umožňovat sledování různých parametrů o běhu unixových serverů to znamená určitým způsobem data na serveru měřit a zaznamenávat. Konkrétně půjde o využití CPU, obsazení operační paměti, počet a typ síťových spojení, okamžité množství přenášených dat, počet běžících procesů, parametry databázového systému a další. Systém by měl umožňovat následující funkcionalitu: Centralizovaná správa Měření serveru musí být snadno ovladatelné a konfigurovatelné a to z jednoho centrálního místa. Odlišný interval měření pro různé veličiny Každá měřitelná veličina má odlišné nároky na interval měření počet procesů čekajících na obsloužení je údaj, který se mění neustále a proto je vhodné jej zaznamenávat častěji, než například volné místo na disku. Minimální požadovaný interval měření je 5 sekund. Přístup k naměřeným datům i při nedostupném měřeném serveru Pokud je měřený server z nějakého důvodu nedostupný (výpadek konektivity, hardwarová porucha), je pro administrátora užitečné, když si může ihned zobrazit grafy o činnosti serveru, zatímco technik v datacentru zajišťuje obnovení dostupnosti serveru. Ošetření výpadku centrálního serveru Pokud dojde k výpadku centrálního serveru, nesmí dojít ke ztrátě dat z jednotlivých měřených serverů. Měření odlišných veličin na jednotlivých serverech Na každém serveru běží různé aplikace a je tedy nutné zaznamenávat různé veličiny. Možnost přidání dalších pluginů Systém by měl obsahovat rozhraní, pro přidávání nových typů měřených veličin bez zásahu do zdrojového kódu aplikace. Dostatečná škálovatelnost Systém je určen jak pro jednotlivce spravující několik serverů, tak i pro webhostingové společnosti, nebo firmy zabývající se pronájmem managed a dedikovaných serverů (v tomto případě se může jednat i o několik stovek serverů). 15

Naměřená data bude možné zobrazit ve formě grafů z centrálního serveru pomocí webové aplikace, která bude umožňovat nastavení konkrétních měřených veličin na konkrétních serverech. Požadavky na webovou aplikaci: Hierarchie uživatelů s rozdílnými právy Zobrazení několika veličin v jednom grafu Možnost definovat vlastní grafy Zobrazení dat z více serverů v jednom grafu Upozornit na servery, kde se nesbírají data Zobrazení statistických údajů z naměřených dat 16

3. Existující systémy V této kapitole jsou popsány systémy, jejichž funkcionalita více či méně splňuje zadání této práce. Je zde tedy uveden přehled a stručný popis nejpoužívanějších aplikací, které umožňují měření údajů o serveru a zobrazovaní naměřených dat ve formě grafů. 3.1. HotSaNIC HotSaNIC, nebo-li HTML overview to System and Network Information Center je sada skriptů napsaných v Perlu a postavených nad rrdtool 1. Práce na projektu začala již v roce 2000. Systém podporuje Linux a částečně i BSD 2. Obr. 1 - Webové rozhraní HotSaNIC 1 RRDTool je nástroj pro práci s časovou řadou dat. Podrobně je popsán v kapitole 5.1.1 RRDTool[5]. 2 BSD je odvozenina Unixu pocházející z univerzity v Berkeley. 17

Aplikace je napsaná modulárně, lze tedy snadno aktivovat a deaktivovat jednotlivé měřící moduly a vytvářet i moduly vlastní. Další výhodou je vzhledem k ostatním alternativám velmi krátký minimální interval měření a to 10 sekund. Grafy jsou vykreslovány pomocí rrdtool[5]. Nejsou však generovány až při požadavku na zobrazení, ale v pravidelných intervalech cca deseti minut. Webové rozhraní je velmi triviální, slouží pouze pro zobrazení grafů. Na úvodní obrazovce jsou zobrazeny náhledy jednotlivých grafů. Po kliknutí na náhled se zobrazí pod sebou grafy za poslední hodinu, den, týden, měsíc a rok. HotSaNIC patří sice mezi velmi jednoduché nástroje, ale v případě nasazení na jeden či dva servery jej lze bez problémů použít. Vzhledem k absenci centralizovaného rozhraní pro ovládání však není vhodný pro použití na větším množství serverů. 3.2. Munin Munin využívá oproti HotSaNICu master/node architekturu. Master se v pravidelných intervalech připojuje na jednotlivé měřené servery a žádá je o data. Munin je napsaný v Perlu 3 a využívá rrdtool a to jak k ukládání naměřených dat, tak i pro tvorbu výsledných grafů. Výhodou je snadné přidávání dalších měřících pluginů, kterých za dobu existence projektu vzniklo poměrně velké množství. Webové rozhraní je opět velmi jednoduché, zajišťuje pouze zobrazování grafů. Oproti HotSaNICu však umožňuje zobrazovat grafy z více serverů. Nevýhodou je interval měření, který je 5 minut. Grafy se zobrazují za poslední den, týden, měsíc a rok. Následující obrázky ukazují webové rozhraní Muninu. Obr. 2 - Webové rozhraní nástroje Munin 3 Perl je populární skriptovací jazyk [1]. Podrobnější popis tohoto jazyka je uveden v kapitole 5.1.2. 18

Obr. 3 - Grafy síťových spojení v Muninu 3.3. Cacti Oproti výše uvedeným systémům je Cacti komplexní nástroj. Aplikace je kompletně napsána v jazyku PHP. Opět se jedná o klient/server architekturu, která umožňuje monitorovat více zařízení a ovládat je pomocí centrálního webového rozhraní. Pro přenos dat z měřených serverů je použit protokol SNMP 4, díky kterému lze snadno monitorovat i síťová zařízení (router, switch), pro které byla původně aplikace vyvinuta. Naměřená data jsou ukládána do RRD souborů, ze kterých jsou pomocí rrdtool generovány grafy. Cacti však využívá pro ukládání dalších informací i SQL databázi. Cacti umožňuje velmi detailní konfiguraci měření. Nejprve je nutné přidat zařízení, které chceme monitorovat a poté přiřadit zdroje dat (Data Sources), ze kterých se poté budou vytvářet grafy. Grafy lze poté přidat do skupiny (Graph Trees). Poměrně složitou konfiguraci jednotlivých částí velmi usnadňují předdefinované šablony (Templates). 4 Protokol SNMP (Simple Network Management Protocol) slouží pro monitorování síťových zařízení. 19

Obr. 4 - Webové rozhraní Cacti Mezi další funkce Cacti patří: Možnost vytváření vlastních skriptů pro měření dat. Přednastavené šablony pro grafy, zdroje dat a měřená zařízení. Stromové řazení grafů, které umožňuje vytvářet vlastní hierarchii. Správa uživatelů s rozdílnými úrovněmi oprávnění. Každý uživatel si může definovat svoje vlastní nastavení grafů. Obr. 5 - Ukázka grafů v Cacti Mezi největší výhody Cacti patří propracované webové rozhraní, které umožňuje detailní konfiguraci všech částí systému, dobrá škálovatelnost a rychlé generování grafů. Nevýhodou je, vzhledem k použití protokolu SNMP, dlouhý interval měření (5 minut). 20

4. Analýza a návrh řešení V této kapitole je popsán návrh řešení jednotlivých částí systému - tedy architektura systému, způsob ukládání dat, centrální server, měřený server, způsob síťové komunikace a webová aplikace. U každé části jsou probrané různé možnosti řešení včetně jejich výhod a nevýhod. Systém je pojmenován jako Shel. Od tohoto názvu se odvíjí pojmenování jednotlivých komponent (Shel-Master, Shel-Node). 4.1. Architektura systému Základním požadavkem je centralizované řízení systému. Z toho vyplývá, že veškerá logika musí být uložena na jednom místě, tím je centrální server Shel- Master. Architektura systému je zobrazena na následujícím obrázku. Obr. 6 - Architektura systému Dalším požadavkem je zobrazování grafů i při nedostupném měřeném serveru. Nasbíraná data tedy bude nutné ukládat na centrálním serveru. Nabízejí se tedy dvě možnosti: 1. Data ukládat pouze na centrální server. 2. Data ukládat zároveň na centrální i měřený server. Výhodou prvního způsobu řešení je především jednoduchost. Nenastávají problémy s duplicitou dat a jejich aktualizací. Nevýhodou bude obrovské množství síťových spojení mezi centrálním serverem a měřenými servery, což může výrazně snížit škálovatelnost celého systému. Výhody a nevýhody duplicitního uložení dat jsou opačné jako u prvního způsobu. Další výhodou je, že při výpadku centrálního serveru bude stále možné zaznamenávat naměřená data. 21

Vzhledem k požadavkům (dostatečná škálovatelnost a krátký interval měření), je nutné zvolit metodu duplicitního uložení dat. Nasbíraná data na měřeném serveru budou sloužit ke dvěma účelům: a) Dočasná záloha při výpadku hlavního serveru b) Centrální server nemusí stahovat data v reálném čase, ale pouze v určitých intervalech (např. po 5-10 minutách) Z výše uvedených bodů vyplývá, že není nutné uchovávat na měřeném serveru celou historii dat, ale stačí uchovávat pouze data zpětně za několik dní (čas, po který může být centrální server nedostupný). 4.2. Způsob ukládání naměřených dat Naměřená data tedy bude nutné ukládat na centrální (Shel-Master) i na měřený server (Shel-Node). Nic však nebrání tomu, aby byl způsob uložení dat pro Shel-Master a Shel-Node odlišný. Při ukládání dat postačí pouze dvě hodnoty čas měření (unix timestamp 5 ) a naměřená hodnota. Možností, jak ukládat nasbíraná data, je několik a jsou popsány v následujících odstavcích. Každý způsob má své výhody a nevýhody. 4.2.1. Textové / XML / binární soubory Výhodou tohoto řešení je, že nebude potřeba instalovat další software. Bude však nutné implementovat rozhraní pro čtení a zápis dat. Jak již bylo uvedeno výše, data na měřeném serveru stačí uchovávat jenom pár dní, proto bude nutné zajistit rotování dat. 5 Unix timestamp je způsob jak uložit datum a čas jako jediné číslo. Jde o počet sekund od 1. 1. 1970 00:00:00 UTC. 22

4.2.2. Relační databáze Oproti textovým souborům nepřináší databáze na první pohled žádné výhody. Opět bude nutné vyřešit rotování dat, navíc databázový systém je pro tento účel zbytečně komplexní a zbytečně by se musel instalovat na systémy, kde není potřeba. Výhodou je snadný výběr dat pomocí jazyka SQL. Kostra ER modelu datového úložiště by mohla vypadat podobně jako na Obr. 7. K uchovávání dat se použijí tři tabulky. Tabulka servers, kde je uložen seznam měřených serverů, tabulka sensors, kde je výčet měřených senzorů (veličin) a poslední tabulka values,, která obsahuje cizí klíče odkazující na tabulku serverů a senzorů a dále čas měření a naměřenou hodnotu. Obr. 7 - ER model dat. Úložiště Předpokládejme, že data jsou ukládána v intervalu pěti sekund. Chceme zobrazit graf v rámci delšího časového úseku a požadujeme jednu hodnotu za 100 sekund (agregace - zprůměrování 20-ti hodnot na jednu). Zároveň požadujeme zobrazení i maximálních a minimálních hodnot. SQL dotaz pro výběr dat by vypadal následovně: SELECT (Time / 100)*100 AS t, AVG(value), MAX(value), MIN(value) FROM time GROUP BY t 4.2.3. RRD databáze RRD databáze neboli Round Robin Database jsou speciální soubory, které slouží k uchovávání série časových údajů - tedy to, co potřebujeme. eme. Nevýhodou je opět instalace dalšího software. Ten je však snadno dostupný jak pro Linux, tak i Solaris, AIX a další. 23

Data jsou uložena v tzv. Round-robin archivu. V jednom RRD souboru může být těchto archivů několik. Při jeho vytváření se definuje, v jakých intervalech se mají data ukládat (průměrovat). Při zapisování se tato data cyklicky přepisují (odtud název Round-Robin). Pokud tedy nastavíme velikost archivu na 7 dní, vyřeší se tím problém rotování dat. Cyklické přepisování má výhodu v tom, že velikost RRD souboru se od jeho vytvoření v průběhu času nezmění. Pro manipulaci s RRD soubory slouží nástroj rrdtool, který umožňuje vkládání a výběr dat. Vkládání dat do RRD souboru pak vypadá například takto: rrdtool update file.rrd time1:x time2:y time3:z Čtení dat: rrdtool fetch file.rrd AVERAGE resolution 300 --start time1 end time2 4.3. Způsob ukládání dat pro Shel-Node Na měřeném serveru se bude jednat o relativně malé množství dat (vzhledem k velikosti pevných disků stovky GB). Doba uchovávání dat Minimální interval měření Velikost časová značky Velikost naměřené hodnoty 7 dní 5s 8B 8B Počet senzorů (veličin) 50 Tabulka 1 Odhad množství ukládaných dat na Shel-Node Pokud budou ukládána data po dobu sedmi dní a minimální interval měření je 5s, jde o cca 120 000 hodnot pro jednu veličinu. Pro 100 senzorů po 16B vychází celkový zabraný prostor na disku na cca 90MB. Toto číslo je velmi nadsazené, protože u většiny senzorů bude postačovat interval měření desetinásobný. 24

Zvolit SQL variantu a instalovat databázový systém na měřený server, který může sloužit pouze jako poštovní nebo webový server, není vhodné řešení. Vzhledem ke snadnosti použití a žádnému omezení bude zvoleno ukládání dat do RRD souborů. 4.4. Způsob ukládání dat pro Shel-Master Na centrálním serveru bude nutné uchovávat obrovské množství dat. Zároveň je nutné zajistit co nejkratší dobu pro ukládání a výběr dat. Pevné disky dosahují velkých kapacit a není problém vytvořit pole o velikosti několika TB. Limitem bude spíše množství dat, které bude nutné zpracovávat a ukládat v reálném čase. Data se budou periodicky (např. v intervalu 5-10 minut) stahovat z měřených serverů na centrální 6. Vezmeme-li v úvahu cca 50 měřených hodnot na server, interval měření od pěti sekund, velikost ukládaných dat 16B a systém bude nasazen v hostingové společnosti, která spravuje cca 200 serverů. Jednoduchým vynásobením výše uvedených čísel dostaneme 72GB dat, které bude nutné ukládat každý měsíc. Na Shel-Master serveru se bude provádět vykreslování grafů a zpracování naměřených dat, proto by se hodila flexibilita jazyka SQL, tedy uložení dat do relační databáze. Vzhledem k tomu, že databázový systém musí při ukládání dat počítat s integritními omezeními, transakcemi a podobně, bude rychlost v porovnání s RRD soubory pravděpodobně mnohem menší. Provedeme tedy výkonnostní srovnání obou přístupů. Pro otestování rychlosti relační databáze byl zvolen open-source databázový systém PostgreSQL. Byla vytvořena tabulka s náhodně vygenerovanými daty o velikosti cca 30 miliónů záznamů 7. 6 Proces stahování dat je podrobně popsán v kapitole 4.8.3 - Stahování dat z měřených serverů 7 Pro zajímavost spočítání řádků v této tabulce trvalo přes 40 sekund tento údaj však nevypovídá nic o rychlosti výběru dat 25

Tabulka 2 Srovnání rychlosti SQL a RRD 8 V tabulce číslo 2 je uveden přehled naměřených časů pro SQL a RRD variantu (měření bylo provedeno 10 krát a výsledné hodnoty jsou vypočteny aritmetickým průměrem). Měřen byl čas vložení 1000 hodnot a výběr dat v časovém úseku dvou hodin. Z výsledků je vidět, že RRD je v operaci insert více než 22 krát rychlejší než SQL varianta. Při výběru dat je RRD cca 4 krát rychlejší. Ve spodní části tabulky jsou pro přehlednost časy převedeny na počet operací za sekundu. 1. Varianta PostgreSQL databázový systém a) Výhody: téměř neomezené možnosti při výběru dat b) Nevýhody: řádově pomalejší vkládání 2. Varianta RRD soubory a) Výhody: rychlost b) Nevýhody: horší možnosti vybírání dat (lze kompenzovat na aplikační úrovni) Pokud vezmeme v úvahu data ukládaná po pěti sekundách, 50 senzorů na server a interval stahování dat na centrální server 5 minut, vychází nutnost uložit 3000 hodnot pro jeden server. V SQL variantě bude trvat uložení cca 30 sekund (dle tabulky č. 2 cca 100 operací za sekundu). To znamená omezení počtu serverů na 10. Z tohoto jednoduchého výpočtu vyplývá, že použití SQL varianty pro ukládání dat je při nasazení systému na větší množství serverů nemožné. 9 Stejně jako pro Shel-Node je tedy zvoleno ukládání dat pro Shel-Master do RRD souborů. 8 Měření bylo prováděno na poměrně starém serveru s HW konfigurací: P4 2,8Ghz, 2GB RAM DDR, PATA disky 9 Tento výpočet je značně zjednodušený průměrný interval měření nebude 5 sekund, ale několikrát vyšší. Měření rychlosti bylo prováděno na poměrně starém HW. Zároveň je však nutné brát zřetel na to, že server není určen pouze k ukládání dat, ale bude také vykreslovat grafy a podobně. 26

4.5. Přidávání nových pluginů na měřený server Dle požadavků v úvodní části by měl systém obsahovat rozhraní pro přidávání dalších měřených veličin (pluginů). To lze řešit dvěma způsoby: 1. Kód nového pluginu se nahraje na měřený server a ihned se spustí. 2. Kód už bude na měřeném serveru a pouze se pošle příkaz ke spuštění. Výhodou prvního způsobu je především jednoduchost a možnost okamžitého měření nových veličin. Z bezpečnostního hlediska však nejde o nejvhodnější řešení. Pokud by se někomu podařilo odesílaný kód změnit (Man in the middle 10 ), mohlo by dojít k narušení bezpečnosti, nebo ztrátě dat na měřeného serveru. Výše uvedený bezpečnostní problém řeší druhý způsob. Kód pro měření je již umístěný na měřeném serveru a nemůže ho tedy nikdo změnit. Měřící kódy mohou být součástí zdrojových kódů (Shel-Node) a jejich rozšiřování a aktualizaci zajistí balíčkovací systém, který je dostupný na většině unixových systémů. Integritu měřících kódů zajistí digitální podpis balíku. Nevýhodou je nutnost aktualizovat balík při přidávání nového pluginu. Toto je však obecný koncept, kdy při požadavku na další funkce software se musí provést jeho aktualizace. Z bezpečnostních důvodů bude preferován druhý způsob přidávání pluginů. Bude se tedy zasílat pouze příkaz o zapnutí daného pluginu. 4.6. Komunikace mezi Shel-Master a Shel-Node Komunikaci mezi centrálním a měřeným serverem lze rozdělit do dvou kategorií. Komunikace bude uskutečněna skrze společnou ethernetovou síť. Prvním typem komunikace je žádost centrálního serveru o zaslání nově nasbíraných dat a druhým jsou řídící příkazy, jako je například aktivování měření dalších veličin, zjištění počtu síťových rozhraní nebo nahlédnutí do logovacího souboru. Jakým způsobem tedy zajistit vzájemnou komunikaci? Existuje samozřejmě několik možností, přičemž nic nebrání tomu, aby se data stahovala jiným způsobem, než budou probíhat řídící příkazy. 10 Man in the middle, neboli člověk uprostřed je způsob útoku, kde útočník odposlechne komunikaci mezi účastníky a stane se aktivním prostředníkem. 27

4.6.1. Vlastní protokol Řešení komunikace pomocí vlastního protokolu je nejsložitější. Bude nutné zajistit šifrování komunikace a autentizaci. Na měřeném serveru by musela běžet aplikace, která bude například poslouchat na určitém portu a umožní komunikaci s centrálním serverem. 4.6.2. SSH Protokol SSH přináší mnoho výhod, i když nebyl navržen pro takovýto typ komunikace. SSH je dostupné na všech unixových systémech, nebude tedy nutné instalovat další software. Dále je vyřešeno šifrování a autentizace. Nevýhodou je, že pokud někdo získá přístup na centrální server, dostane tak přístup i na všechny měřené servery. 4.6.3. XML-RPC / SOAP Nevýhodou je instalace XML-RPC případně SOAP serveru na měřený server. K tomu může posloužit například webový server Apache, ale ne na každém serveru je Apache nainstalován. Také bude nutné vyřešit zabezpečení komunikace. 4.6.4. SNMP SNMP, neboli Simple Network Management Protocol je protokol, který slouží pro správu a monitorování síťových prvků. Umožňuje zasílat monitorovanému zařízení SNMP dotazy. Zařízení odpoví na základě přijatého OID 11 hodnotou. Vzhledem k požadovanému minimálnímu intervalu a řídících příkazů (zobrazování logovacího souboru) není SNMP příliš vhodné. Z výše uvedených možností komunikačních protokolů bude vybráno SSH. Na každém monitorovaném zařízení bude vytvořen speciální uživatel shel. Přihlašování z centrálního serveru bude zajištěno pomocí RSA klíče. Nevýhodou je shell přístup na měřený server (i když se nejedná o superuživatele). Tuto nevýhodu lze odstranit velmi 11 OID je posloupnost čísel oddělená tečkou, které jednoznačně identifikují měřený parametr. 28

jednoduše, a to nastavením tzv. login skriptu 12 místo shellu. Login skript (Command skript) bude umožňovat ovat provedení pouze předem definovaných akcí, jako např. stažení dat, zobrazení logu apod. Tímto způsobem se dá velmi jednoduše výrazně zvýšit bezpečnost komunikace. Případný útočník, který by získal přístup na centrální server, by mohl z jednotlivých serverů maximálně stáhnout naměřená data, případně aktivovat měření dalších pluginů/senzorů. Ať už z důvodu budoucího rozšíření, nebo osobních preferencí správce měřeného serveru, by měl systém umožňovat přidání dalších protokolů pro komunikaci a to jak individuálně ě pro jednotlivé servery, tak i pro daný typ komunikace (stahování dat nebo řídicí příkazy). 4.7. Shel-Node Úkolem Shel-Node bude v definovaných intervalech měřit informace o činnosti serveru a lokálně je zaznamenávat. Musí také umět zpracovávat příkazy Shel-Master serveru. Tedy poskytnout naměřená data, případně začít/přestat měřit danou veličinu. Komponenty Shel-Node jsou zobrazeny na Obr. 8. Obr. 8 - Komponenty Shel-Node Jak již bylo uvedeno v kapitole 4.3, měřená data se budou lokálně ukládat do RRD souborů. Samotné měření hodnot budou zajišťovat měřící skripty (pool skripty), což bude úsek kódu ve skriptovacím jazyce (např. bash nebo Perl), který zajistí odečítání a ukládání hodnot do RRD souborů. Vzhledem k tomu, že se bude jednat o poměrně velké množství měřených hodnot (50 i více), bude vhodné rozdělit měření na několik nezávislých skriptů. Jeden bude měřit údaje o procesoru a jiný zase o databázi. Výhodou tohoto rozdělení je, že 12 Tento skript se spustí ihned po přihlášení uživatele místo klasického shell interpreteru (např. bash). 29

pokud nebude v daném okamžiku možno odečíst údaje např. o databázi (nedostupnost databázového serveru), všechny ostatní data bude možné i nadále zaznamenávat. Měřená data by bylo vhodné určitým způsobem hierarchicky rozdělit. Byla tedy navržena následující struktura. Nejvyšší úrovní bude kategorie pluginů (pro každou bude samostatný měřicí skript), který bude zajišťovat měření např. MySQL databáze. Kategorie pluginů bude rozdělena na pluginy. Příkladem pluginu bude (vzhledem k výše zmíněné MySQL) využití cache nebo počet dotazů za jednotku času. Samotný plugin bude dále rozdělen na senzory. Každý senzor bude představovat jednu měřenou hodnotu. Vzhledem k počtu dotazů bude mezi senzory patřit např. počet update nebo insert dotazů. Výsledkem je tedy následující rozdělení: kategorie pluginů > plugin > senzor. Otázkou tedy zůstává, jakým způsobem zajistit nepřetržitý běh všech pool skriptů. Tento problém lze řešit opět několika způsoby. Je třeba počítat s tím, že se může bezdůvodně ukončit (výše zmíněná nedostupnost databáze apod.). Proto by bylo nevhodné skripty pouze spustit při startu systému. Problém lze vyřešit jedním z následujících způsobu: a) Cron tabulka je Linux/Unix systémový nástroj, který umožňuje spouštět příkazy v předem definovaných intervalech. Je však navržen pro spouštění v minimálním intervalu jedna minuta, což vzhledem k minimálnímu požadovanému intervalu 5s nestačí. I kdyby to však bylo možné, režie při tak malém intervalu spouštění by byla příliš velká. Tento nedostatek lze obejít tím, že skript bude měření provádět ve smyčce, která potrvá určitý interval např. 5 nebo 10 minut. Cron pak zajistí spouštění v tomto intervalu. Zbývá tedy zaručit přesnou dobu běhu skriptu, což lze zajistit odečtením doby samotného měření a dopočítáním času čekání. Cron pak zajistí, že při pádu skriptu bude opět spuštěn. Toto řešení je poměrně jednoduché. b) Démon 13 další možností je použít démona, který zajistí spuštění a nepřetržitý běh všech pool skriptů. Pokud některý ze skriptů neočekávaně skončí, démon zaručí jeho opětovné spuštění. Démon se při svém ukončení postará také o ukončení všech pool skriptů. 13 Démon je označení programu, který je spuštěn obvykle při startu operačního systému a není v přímém kontaktu s uživatelem. Démon běží na pozadí a zpracovává požadavky od systému. 30

Jak bylo naznačeno výše, všechny měřící kódy budou uloženy na měřeném serveru a budou součástí balíku a jejich rozšíření bude možné pouze při jeho aktualizaci. Dále bude nutné mít uložené informace o tom, co se na daném serveru má měřit. Na základě těchto dat budou generovány jednotlivé pool skripty. Konkrétní způsob uložení dat a generování skriptů bude popsán v implementační části. 4.8. Shel-Master Shel-Master server bude tvořit jádro celého systému. Bude sloužit jako centrální úložiště nasbíraných dat, dále na něm poběží webová aplikace, pomocí které se bude systém ovládat a bude umožňovat zobrazit nasbíraná data ve formě grafů. Jednotlivé komponenty Shel-Master serveru jsou zobrazeny na následujícím obrázku. Obr. 9 - Komponenty Shel-Master 4.8.1. Databáze Důležitou částí Shel-Masteru je databáze. V té bude uložen seznam měřených serverů, seznam pluginů, které jsou aktivovány na jednotlivých serverech, uživatelé a jejich práva, definice jednotlivých grafů a mnoho dalších informací. Zjednodušené schéma databáze je na Obr. 10. 31

Obr. 10 - Schéma databáze pro Shel-Master 14 V tabulce servers je uložen seznam měřených serverů. Ke každému serveru jsou přiřazeny jednotlivé pluginy a senzory, které se na daném serveru měří. V tabulce graphs je definice jednotlivých grafů. Každý graf je definován seznamem senzorů, které zobrazuje, popisky os a rozměry. Další části schématu jsou podrobně rozebrány v kapitole 4.9 Webová aplikace. Ke každému pluginu jsou přiřazeny měřící kódy (tabulka measure_codes). Pro každý operační systém (případně konkrétní verzi jádra) může být měřící kód odlišný. Proto je v databázi uložen i údaj, ke kterému operačnímu systému daný kód patří, dále verze jádra, případně konkrétní typ distribuce. Každý plugin bude mít určitý výchozí (default) měřící kód. Při exportování měřících kódů pro další typ operačního systému by se postupovalo tak, že by se systém pokusil vybrat kódy přesně pro daný typ operačního sytému. Pokud by některé kódy chyběly (například by byly dostupné pro jinou verzi jádra), pokusil by se vybrat výchozí kódy pro daný systém. Pokud by nebyly ani ty, vybral by úplně obecné kódy. Výsledkem výše uvedeného sestupného modelu by byly nejlepší možné dostupné kódy. Ty by se nainstalovaly na měřený server. V případech, kde by měření selhalo, by se kódy upravili pro daný operační systém a přidaly do databáze. Pomocí tohoto postupu by se poměrně snadno rozšiřovala ovala podpora pro další operační systémy. 14 Pro přehlednost jsou zobrazeny pouze jednotlivé tabulky a vztahy mezi nimi, bez jednotlivých atributů. Kompletní schéma je uvedeno v příloze, 32

4.8.2. Datové úložiště Data na centrálním serveru se budou ukládat do RRD souborů (viz kapitola 4.4). Vzhledem k počtu měřených serverů a počtu senzorů na server se bude jednat o poměrně velké množství souborů. RRD soubory se tedy rozdělí do složek a to následujícím způsobem: Cesta_k_úložišti/server/kategorie/plugin/senzor.rrd Pro každý senzor tedy bude zvláštní RRD soubor. 4.8.3. Stahování dat z měřených serverů Data z měřených serverů se budou periodicky stahovat na centrální server. Stahovat se budou pouze nově naměřená data, proto by bylo zbytečné, stahovat celé RRD soubory. Zabalením dat do XML by zbytečně narostl jejich objem, proto bude zvolen vlastní jednoduchý formát, který se bude podobat výstupu příkazu rrdtool fetch. Vzhledem k tomu, že se budou grafy vykreslovat z dat na centrálním serveru, je nutné dodržet relativně krátký interval stahování dat. Dle počtu měřených serverů bude vhodné zvolit cca 1 až 10 minut. Pravidelné spouštění stahování dat zajistí cron. Proces stahování je zobrazen na následujícím obrázku. Nejprve bude nutné načíst z databáze seznam serverů, ze kterých se budou stahovat data. Na daný server se poté odešle seznam senzorů a čas jejich poslední aktualizace. Měřený server na základě těchto údajů vrátí nasbíraná data, ty se poté uloží do centrálního úložiště. 33

Obr. 11 - Proces stahování dat 4.9. Webová aplikace Důležitou částí bude webová aplikace, která představuje výstup celého systému. Rozhraní bude umožňovat provádět tyto akce: a) Zobrazování grafů z naměřených hodnot b) Konfigurace měření na jednotlivých serverech c) Správa grafů d) Správa pluginů ů a měřících kódů Základní rozvržení prvků stránky je na Obr. 12. V levém horním rohu je logo, pod kterým je vodorovně ě umístěné hlavní menu, které určuje rozdělení webu do hlavních sekcí. Pod menu je umístěná tzv. drobečková navigace 15, která umožňuje přejít na jakoukoliv stránku v cestě na jediné kliknutí. Navigace na stránce s konkrétním grafem může vypadat například takto: Hlavní stránka > měřený server > kategorie grafů > konkrétní graf. Na hlavní části stránky budou zobrazeny grafy, případně ě formuláře pro konfiguraci měřených serverů. Na konci stránky bude zobrazena standardní patička. 15 Drobečková navigace znázorňuje pozici aktuální stránky v hierarchii webu nezávisle na cestě, po které se na ni uživatel dostal. 34

Obr. 12 - Rozvržení webového rozhraní I přesto, že výstupem jsou pouze grafy o využití serveru, jsou obecně tato data považována za důvěrná, proto je nutné zajistit autorizaci a autentizaci uživatelů. Každý uživatel by měl mít přístup pouze do těch částí, se kterými bude pracovat. Proto je nutné rozdělit uživatele do skupin, které bývají zpravidla hierarchicky provázané. Na Obr. 13 jsou zobrazené jednotlivé skupiny uživatelů včetně nejdůležitějších jších akcí, které budou typicky vykonávat. Obr. 13 - Uživatelské role a základní případy užití 35

Jsou zde definovány tři typy uživatelů. Prvním typem uživatele je majitel serveru, kterému běží na měřeném serveru služby. Pravděpodobně jde o nějakého manažera. Ten má povoleno pouze zobrazování grafů, případně definici vlastních grafů. Tato skupina by se mohla dále rozdělit na konkrétní uživatele, kteří mají možnosti zobrazovat grafy konkrétních serverů. Další skupinu tvoří administrátoři serverů, kteří mají stejná práva jako manažeři. Dále mohou určovat, jaké pluginy a senzory budou měřeny na jednotlivých serverech a přidávat další měřené servery. Posledním typem uživatele je správce systému. Jeho úkolem bude bezproblémový provoz celého systému a správa uživatelů, dále bude vytvářet nové pluginy a spravovat měřící kódy. 4.9.1. Zobrazování a správa grafů Naměřené hodnoty z jednotlivých serverů je nutné určitým způsobem interpretovat. K tomu se hodí nejlépe grafy, kde na ose x je vynesen čas a na ose y daná měřená hodnota. V jednom grafu může být zobrazeno více měřených veličin (senzorů), které se odliší barvou. Stejně jako byly jednotlivé pluginy rozděleny do kategorií, budou rozděleny pro přehlednost podobně i grafy. U konkrétního serveru a typu grafu se zobrazí na stránce graf za poslední hodinu, den, týden a rok. Dále bude možnost určit konkrétní časový úsek (od-do) pro zobrazení grafu. Typicky bude definován pro každý plugin jeden graf. Bude zde však možnost definovat další grafy, které budou zobrazovat senzory nezávisle na tom, z jakého jsou pluginu. Grafy pak bude možné přiřadit k vybraným serverům, to umožní zobrazit si v jednom grafu například počet běžících procesů Apache a využití CPU, což může usnadnit analýzu incidentů. Při definici nového grafu bude muset uživatel zadat název grafu, kategorii a případně rozměry. Dále bude muset určit, zda půjde o tzv. Stacked graf. Tedy jestli se dané veličiny v grafu budou překrývat, nebo se budou sčítat a skládat nad sebe. Poté bude muset přiřadit k novému grafu jednotlivé senzory. U každého senzoru definuje barvu, zda se bude jednat pouze o čáru, nebo vyplněnou plochu (Line/Area) a také prioritu senzoru. Priorita určuje pořadí při překreslování jednotlivých senzorů a u stacked grafů pořadí skládání senzorů na sebe. 36

4.9.2. Konfigurace měřených hodnot U každého serveru bude možno přímo z webového rozhraní určovat, jaké pluginy resp. senzory se budou měřit. Vzhledem k tomu, že měřící kódy jsou uloženy na měřeném serveru již při instalaci resp. aktualizaci balíku, musí být v databázi u každého serveru uložena verze balíku Shel-node. Poté bude možno přiřadit řadit k serveru pouze ty pluginy, které jsou v dané verzi dostupné. Obr. 14 - Datový model pro senzory a pluginy Na Obr. 14 je zobrazena část datového modelu, kde je zaznamenáno, co se bude na jednotlivých serverech měřit. Pro každý server bude v databázi uložen seznam senzorů, kde každý senzor patří k právě jednomu pluginu. Dále je nutné mít i informaci o tom, jaké pluginy jsou přiřazeny ke konkrétnímu serveru. Tím vzniká v databázovém modelu cyklus, který bude nutné ošetřit na aplikační úrovni. Vztah mezi pluginem a serverem je nutný kvůli pluginům, kde není předem znám počet senzorů. Jde například o plugin, který měří obsazení jednotlivých oddílů pevného disku, nebo měření datového toku na síťových rozhraních. Při přiřazování takového pluginu k serveru není znám konkrétní počet oddílů nebo síťových rozhraní. Takovéto pluginy budou v textu dále označovány ovány jako tzv. multiple pluginy. Pokud bude chtít uživatel měřit na serveru další veličiny, iny, jednoduše si pomocí formuláře přidá jednotlivé senzory a pluginy a systém se postará o vytvoření RRD souborů na centrálním i měřeném serveru a zajistí vygenerování a spuštění měřících kódů. Celý proces bude detailně popsán v implementační části. 37

4.9.3. Přidávání nových pluginů Jak již bylo zmíněno v předchozích kapitolách, jednotlivé měřící kódy jsou uložené přímo na měřeném serveru, kam se nahrají při instalaci, resp. aktualizaci. Aby bylo možné měřící kódy určitým způsobem spravovat, musí být uložené i na centrálním serveru. Pro uložení by stačily obyčejné textové soubory, ale kvůli již zmíněnému systému výběru kódu pro daný operační systém bude mnohem vhodnější uložit kódy přímo do databáze. Konkrétně do tabulky measure_codes, viz Obr. 14. Přidat nový plugin bude možné přímo z webového rozhraní pomocí formuláře. Uživatel bude muset definovat kromě samotného měřícího kódu také kategorii pluginů a periodu měření. Samotný měřící kód musí obsahovat vhodně pojmenované proměnné, které budou uchovávat požadované měřené hodnoty. K nově přidanému pluginu bude poté nutné přidat jednotlivé senzory. U každého senzoru definuje uživatel k jakému pluginu patří a jméno proměnné, která obsahuje požadovanou měřenou hodnotu. Aby bylo možné aplikovat nový plugin na měřený serveru, je nutné aktualizovat instalační balíček, který se poté nainstaluje na měřený server. 38

5. Implementace V úvodu této kapitoly je popsána volba programovacího jazyka, databázového systému a vývojového prostředí. Dále je zde popsána na základě předchozí analýzy implementace všech částí systému. Jde o implementaci webové aplikace, centrálního (Shel-Master) a měřeného (Shel-Node) serveru a jejich vzájemné komunikace. Implementace všech částí systému byla odladěná a otestovaná na operačním sytému Debian GNU/Linux, pro který byl také vytvořen instalační balíček Shel-node. 5.1. Volba použitých technologií Volba konkrétní použité technologie (programovacího jazyka) může usnadnit nebo naopak zvýšit náročnost celé implementace. V mnoha případech však bývá volba provedena na základě autorových preferencí. Vzhledem k nasazení systému v unixovém prostředí budou preferovány open source technologie. Systém se skládá z několika relativně nezávislých částí, a proto je nutné zvážit volbu dané technologie pro jednotlivé části zvlášť. 5.1.1. RRDTool Naměřená data se budou ukládat do RRD souborů, a to jak na měřeném, tak i na centrálním serveru. RRDTool, neboli round-robin database tool je nástroj pro práci s časovou řadou dat [5]. Umožňuje tato data ukládat do speciálních souborů, které se při zápisu cyklicky přepisují. Výhodou tohoto řešení je, že soubory od vytvoření nemění svoji velikost a nemůže tak dojít během provozu k nepředpokládanému zaplnění pevného disku. Nástroj umožňuje nejen data z RRD souborů číst, ale také vykreslovat grafy. Data se ukládají v RRD souborech do tzv. archivů. Každý archiv slouží k ukládání v jiném časovém rozlišení. Například můžeme vytvořit RRD soubor se třemi archivy, který bude uchovávat data za poslední den po 5 sekundách, za poslední měsíc po 60 sekundách a za poslední rok po dnech (86400 sekund). Čas se v RRDTool ukládá jako Unix Timestamp. RRD soubor lze vytvořit pomocí příkazu rrdtool create. Syntaxe příkazu je následující: 39

rrdtool create filename [--start -b start time] [--step -s step] [DS:ds-name:DST:dst arguments] [RRA:CF:cf arguments] rrdtool create temperature.rrd --start 920804400 --step=300 DS:temperature:COUNTER:600:U:U RRA:AVERAGE:0.5:1:24 RRA:AVERAGE:0.5:6:10 Výše uvedený příklad vytvoří soubor temperature.rrd. Data se budou ukládat v intervalu 300 sekund. Databáze bude obsahovat jeden zdroj dat, který je pojmenovaný temperature a je typu COUNTER. Jednotlivé typy jsou uvedeny v tabulce číslo 3. Dále jsou vytvořeny dva archivy (RRA - round robin archive). V prvním archivu se ukládají přímé hodnoty (24 vzorků, tj. 24 * 5 minut = 2 hodiny). V druhém se agregují (průměrné hodnoty - AVERAGE, viz tabulka číslo 4) z šesti vzorků (6 * 5 minut = ½ hodiny) a ukládá se 10 hodnot, tedy data za posledních 5 hodin. GAUGE Uchovávání okamžité hodnoty - teplota COUNTER Pro neustále se zvyšující čítače odeslané bajty DERIVE Stejné jako COUNTER, ale bez kontroly přetečení ABSOLUTE Pro COUNTER, který se nuluje při čtení COMPUTE Pro ukládání výsledků výpočtu hodnot z jiných zdrojů dat AVERAGE MIN MAX LAST Tabulka 3 - Datové typy Průměrná hodnota Minimální hodnota Maximální hodnota Poslední hodnota Tabulka 4 - Způsob agregace - consolidation function Pro zápis do RRD souboru slouží příkaz rrdtool update. Zápis naměřené teploty do souboru temperature.rrd v definovaný čas se provede následovně: rrdtool update temperature.rrd 920904800:20.3 Pro čtení dat z RRD databáze se používá příkaz rrdtool fetch. Pokud chceme načíst naměřené hodnoty ze souboru temperature.rrd v definovaném intervalu a požadujeme zprůměrovaná data, použijeme níže uvedený příkaz. RRDTool se postará o zvolení nejvhodnějšího archivu pro poskytnutí požadovaných dat. rrdtool fetch temperature.rrd AVERAGE --start 920804400--end 920809200 40

Pro vytváření grafů slouží příkaz rrdtool graph. Níže uvedený příklad vytvoří soubor temparature.png, který zobrazí graf teploty v požadovaném čase. Hodnoty pro vytvoření grafu budou načteny ze souboru temparature.rrd. Teplota bude zobrazena jako zelená čára o tloušťce 2 pixely. rrdtool graph temperature.png --start 920804400 --end 920808000 DEF:temp=temparature.rrd:temperature:AVERAGE LINE2:temp#FF0000 5.1.2. Použité technologie pro Shel-master Úkolem Shel-master serveru je periodicky stahovat data z měřených serverů a ukládat je do RRD úložiště. Dále musí zajistit veškerou komunikaci s měřeným serverem. Použitý programovací jazyk musí umět pracovat s RRD soubory a komunikovat přes síť s měřeným serverem přes SSH (je nutné počítat do budoucna i s dalšími protokoly jako např. SOAP). RRDTool byl implementován v několika jazycích, většinou jde o skriptovací jazyky. Například bash, perl, php ale i C. Pro implementaci Shel-master serveru byl zvolen Perl. Perl [1] je interpretovaný programovací jazyk, který vytvořil Larry Wall v roce 1987. Jazyk byl původně navržen pro zpracování textů a téměř definoval standard pro regulární výrazy. Od verze 5 umožňuje perl také objektově orientované programování. Kolem jazyka vznikla obrovská komunita, rozsáhlá dokumentace a tisíce volně dostupných modulů. Mezi nevýhody patří mnoho způsobů zápisu i základních konstruktů jazyka. Zdrojový kód se pak stává velmi snadno obtížně čitelný. 5.1.3. Použité technologie pro Shel-node Úkolem Shel-Node je v definovaných intervalech měřit informace o činnosti serveru, zaznamenávat je do RRD souborů a reagovat na příkazy od centrálního serveru. Vzhledem k tomu, že kódy pro měření se generují na základě požadavků od Shel-master serveru, bude vhodné použít skriptovací jazyk. Perl bude v tomto případě opět vyhovovat. 41

5.1.4. Použité technologie na webovou aplikaci Při vývoji webových aplikací se používá v součastné době velké množství programovacích jazyků. Mezi nejpoužívanější patří PHP,.NET a J2EE v kombinaci s mnoha dostupnými Frameworky 16. Všechny využívají podobného principu. Na základě požadavku od klienta vygenerují stránku, kterou odešlou ve formě (X)HTML kódu webovému prohlížeči. Pro úpravu vzhledu stránek se používá výhradně CSS..NET není dostupný na unixovém prostředí, zbývá tedy volba mezi PHP a J2EE. Jazyk musí opět umět pracovat s RRD soubory, protože zde bude realizováno generování grafů. RRDTool byl implementován jak v PHP, tak i v Javě. Vzhledem k tomu, že J2EE se hodí spíše pro rozsáhlé systémy, bylo zvoleno PHP, díky obrovskému rozšíření a komunitě. Pro usnadnění práce bude použit Zend Framework [2][3]. Jako webový server je použit Apache. PHP (PHP: Hypertext Preprocessor) je skriptovací jazyk určený pro vytváření dynamických webových stránek. PHP umožňuje pracovat s databázemi, s velkým množstvím internetových protokolů (IMAP, POP3, SMTP), dokáže vytvářet obrázky a PDF soubory. V současné době se používá verze 5, která přinesla kompletní podporu objektově orientovaného programování. Pro PHP bylo napsáno velké množství Frameworků. Mezi nejúspěšnější patří Zend Framework, který pochází přímo od společnosti Zend a podílí se na něm více než 300 vývojářů. Framework je napsaný kompletně metodou objektově orientovaného programování s využíváním návrhových vzorů. Jedná se o tzv. MVC (model-viewcontroll) Framework. MVC je softwarová architektura, která rozděluje datový model aplikace (model), uživatelské rozhraní (view) a řídicí logiku (controll) do tří nezávislých komponent tak, že modifikace některé z nich má minimální vliv na ostatní. K Frameworku je dostupná rozsáhlá dokumentace s příklady. Framework je rozdělen na několik desítek komponent, které lze používat i samostatně. Každá komponenta řeší konkrétní úlohu, která se typicky objevuje ve většině webových aplikací. Například Zend_Db umožňuje komunikaci s databází, Zend_Auth autorizaci uživatelů a Zend_Form snadné odesílání a validaci formulářů. 16 Framework je softwarová struktura, která má za úkol řešit typické problémy, se kterými se vývojář setkává při práci. Vývojář se tak může soustředit více přímo na svoji konkrétní aplikaci. 42

Framework řeší například vytváření PDF dokumentů, práci s webovými službami, správu uživatelských oprávnění a jazykovou lokalizaci. Použití Frameworku přináší mnoho výhod. Nejdůležitější výhodou je, že programátorovi odpadá nutnost řešit typické problémy, ale může se zaměřit přímo na svoji konkrétní aplikaci. Pokud programátor používá doporučené postupy a metody, je jeho kód čitelnější a snadno rozšiřitelný. Mezi nevýhody patří počáteční časová investice pro nastudování Frameworku a mírné snížení výkonnosti zpracování skriptů. 5.1.5. Použité technologie Databázový systém Pro uchování seznamu měřených serverů, pluginů, senzorů, uživatelů systému a dalších informací je nutné použít relační databázový systém. Mezi nejpoužívanější open source databázové systémy pro unixové prostředí patří MySQL, PostgreSQL a Firebird. Popisovaný systém neklade žádné speciální požadavky (jak funkční, tak výkonnostní) na databázový sytém, proto by mohl být zvolen jakýkoliv databázový sytém z výše uvedených. Byl zvolen PostgreSQL. 5.2. Volba vývojového prostředí Implementace Shel-Master i Shel-Node byla realizována pomocí klasického unixového editoru vim. Práce s tímto editorem je sice ze začátku poněkud těžkopádná, ale po zvládnutí nejdůležitějších funkcí se stává práce velmi efektivní, bez nutnosti používat myš. Pro implementaci webové aplikace bylo zvoleno open source vývojové prostředí NetBeans. Toto IDE usnadňuje a urychluje vývoj aplikací vzhledem k obrovskému množství užitečných funkcí a snadnému přehlednému ovládání. NetBeans verze 6.5 má přímo podporu pro PHP, včetně HTML a CSS. Podporou je myšlena zvýrazněná syntaxe a tzv. Code Completion, což je nástroj pro automatické doplňování kódu. Nástroj zobrazí po zadání několika znaků možnosti, které chce uživatel pravděpodobně napsat. Tedy například výčet metod, které lze volat u daného objektu včetně možných parametrů a dokumentace. To je velmi výhodné při používání 43