Č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:
16
•
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
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 rrdtool1. Práce na projektu začala již v roce 2000. Systém podporuje Linux a částečně i BSD2.
Obr. 1 - Webové rozhraní HotSaNIC
1 2
RRDTool je nástroj pro práci s časovou řadou dat. Podrobně je popsán v kapitole 5.1.1 RRDTool[5]. 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 Perlu3 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 SNMP4, 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 zp ukládání dat, centrální server, měřený ěřený server, způsob síťové komunikace a webová aplikace. aplikace U každé části jsou probrané robrané různé r 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 Master, Shel-Node). Shel
4.1.
Architektu systému Architektura
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ě, míst tím je centrální server – „ShelMaster“. 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řii nedostupném měřeném m serveru. Nasbíraná data tedy bude nutné ukládat na centrálním serveru. Nabízejí se tedy dvě dv možnosti: 1. Data ukládat pouze na centrální server. 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 edevším jednoduchost. Nenastávají problémy s duplicitou licitou dat a jejich aktualizací. aktualizací Nevýhodou bude obrovské množství síťových spojení mezi centrálním ce serverem a měřenými 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é opačné jako u prvního způsobu. Další výhodou je, že při p i výpadku centrálního serveru bude stále možné zaznamenávat naměřená ěř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 timestamp5) 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í ční databáze Oproti textovým ovým souborům soubor nepřináší ináší databáze na první pohled žádné výhody. Opět bude nutné vyřešit řešit „rotování“ dat, navíc avíc databázový systém je pro tento účel ú zbytečně komplexní a zbytečně zbyte by se musel instalovat na systémy, kde není potřeba. pot Výhodou ýhodou je snadný výběr výb dat pomocí jazyka SQL. Kostra ER modelu datového úložiště by mohla vypadat podobně podobn jako na Obr. 7. K uchovávání dat se použijí tři tabulky. Tabulka servers, servers kde je uložen seznam měřených serverů, tabulka abulka sensors, kde je výčet měřených senzorů senzor (veličin) a poslední tabulka values,, která obsahuje cizí klíče klí odkazující na tabulku serverů server a senzorů a dále čas měření a naměřenou ěřenou hodnotu.
Obr. 7 - ER model dat. Úložiště
Předpokládejme, edpokládejme, že data jsou ukládána v intervalu int pěti sekund. Chceme zobrazit graf v rámci delšího časového asového úseku a požadujeme jednu hodnotu za 100 sekund (agregace - zprůměrování ěrování 20-ti 20 hodnot na jednu). Zároveň požadujeme zobrazení i maximálních a minimálních hodnot. SQL dotaz pro výběr výb dat by vypadal ypadal následovně: následovn SELECT (Time / 100)*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 n „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 en 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
7 dní
Minimální interval měření
5s
Velikost časová značky
8B
Velikost naměřené hodnoty
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ů 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 7
25
Tabulka 2 – Srovnání rychlosti SQL a RRD 8
V tabulce číslo 2 je uveden přehled p naměřených časů pro SQL a RRD variantu (měření bylo provedeno 10 krát a výsledné hodnoty jsou vypočteny ny aritmetickým průměrem). Měřen byl čas as vložení 1000 hodnot a výběr výb dat v časovém 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 ru dat je RRD cca 4 krát rychlejší. Ve spodní části tabulky ta jsou pro přehlednost časy převedeny evedeny na počet po operací za sekundu. 1. Varianta PostgreSQL databázový systém a)
Výhody: téměř neomezené možnosti při p 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č ační úrovni) Pokud vezmeme v úvahu data ukládaná po pěti p sekundách, 50 senzorů 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ě variant bude trvat uložení cca 30 sekund (dle tabulky č. 2 – cca 100 operací za sekundu). ). To znamená omezení počtu po serverů na 10. Z tohoto jednoduchého výpočtu tu vyplývá, že použití SQL varianty pro ukládání dat je při nasazení systému na větší tší množství serverů server nemožné. 9 Stejně jako pro Shel-Node Node je tedy zvoleno ukládání dat pro Shel-Master Master do RRD souborů. 8
Měření bylo prováděno na poměrně ě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 n vyšší. Měření ní rychlosti bylo prováděno provádě na poměrně starém HW. Zároveň je však nutné brát zřetel z na to, že server není určen pouze k ukládání dat, ale bude také vykreslovat grafy a podobně. 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 middle10), 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 OID11 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 skriptu12 místo shellu. Login ogin skript (Command skript) bude umožňovat ovat provedení pouze předem p definovaných akcíí, jako např. stažení dat, zobrazení logu apod. Tímto způsobem sobem se dá velmi jednoduše výrazně výrazn zvýšit bezpečnost nost komunikace. Případný P útočník, který by získal přístup ístup na centrální server, by mohl z jednotlivých serverů server maximálně stáhnout naměřená ená data, případně p aktivovat měření dalších pluginů/senzor senzorů. Ať už z důvodu ůvodu budoucího rozšíření, rozší ení, nebo osobních preferencí správce měřeného serveru, by měl mě systém umožňovat přidání dalších protokol kolů 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 Node
Úkolem Shel-Node Node bude v definovaných intervalech měřit ěřit informace o činnosti serveru a lokálně je zaznamenávat. zaznamenávat Musí také umět zpracovávat příkazy př Shel-Master serveru. Tedy poskytnout poskytnou naměřená data, případně začít/přestat estat měřit měř danou veličinu. Komponenty Shel-Node Node jsou zobrazeny na Obr. 8.
Obr. 8 - Komponenty Shel-Node
Jak již bylo uvedeno v kapitole 4.3, měřená ená data se budou lokálně lokáln ukládat do RRD souborů. Samotnéé měření m hodnot budou zajišťovat měřící ící skripty (pool ( skripty), což bude úsek kódu ve skriptovacím jazyce (např.. bash nebo Perl), Per který zajistí odečítání a ukládání hodnot do RRD souborů. soubor Vzhledem k tomu, že se bude b jednat o poměrně velké množství množs měřených hodnot (50 i více),, bude vhodné rozdělit rozd měření na několik kolik nezávislých skriptů. skript Jeden bude měřit it údaje o procesoru a jiný zase zase o databázi. Výhodou tohoto rozdělení rozd je, že
12
Tento skript se spustí ihned po přihlášení p ihlášení uživatele místo klasického shell interpreteru (např. (n 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émon13 – 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 v měřící ící kódy budou uloženy na měřeném serveru a budou součástí balíku a jejich rozšíření ro ení bude možné pouze při p 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 ěchto dat budou generovány jednotlivé pool skripty. Konkrétní způsob uložení dat a generování skriptů skript bude popsán v implementační ční části.
4.8.
Shel-Master Master
Shel-Master Master server bude tvořit 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 n poběží ží webová aplikace, pomocí které se bude systém ovládat a bude umožňovat umož zobrazit nasbíraná data ve formě mě grafů. Jednotlivé komponenty Shel-Master Master serveru erveru jsou zobrazeny na následujícím obrázku. obrázku
Obr. 9 - Komponenty Shel-Master
4.8.1. Databáze Důležitou částí ástí Shel-Masteru Shel je databáze. V té bude uložen en seznam měřených m serverů, seznam pluginů inů, které jsou aktivovány na jednotlivých serverech, uživatelé a jejich práva,, definice jednotlivých grafů graf a mnoho dalších informací. informac Zjednodušené schéma databáze je na Obr. 10.
31
Obr. 10 - Schéma databáze pro Shel-Master14
V tabulce servers je uložen seznam měřených m serverů. Ke každému serveru jsou přiřazeny azeny jednotlivé pluginy a senzory, y, které se na daném serveru měří. měř V tabulce graphs je definice jednotlivých grafů. graf Každý graf je definován seznamem senzorů, senz které zobrazuje, razuje, popisky os a rozměry. rozm Další části schématu chématu jsou podrobně rozebrány v kapitole 4.9 Webová aplikace. aplikace
Ke každému pluginu jsou přiřazeny p měřící kódy (tabulka measure_codes). measure_codes Pro každý operační systém (případn řípadně konkrétní verzi jádra) může být měřící ěřící kód odlišný. Proto je v databázi uložen i údaj, ke kterému operačnímu opera 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ý urč výchozí (default) měřící kód. Přii exportování expor měřících kódů pro další typ operačního č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 opera sytému. Pokud by některé které kódy chyběly chyb (například íklad by byly dostupné pro jinou verzi jádra), pokusil by se vybrat výchozí v 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 nainstalo na měřený ený server. V případech, kde by měření ení selhalo, by se kódy upravili uprav pro daný operační ní systém a přidaly p 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 ehlednost jsou zobrazeny pouze jednotlivé tabulky a vztahy vztahy mezi nimi, bez jednotlivých atributů. atribut Kompletní schéma je uvedeno v příloze, ří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á webov aplikace, která představuje edstavuje výstup celého systému.
Rozhraní bude umožňovat provádět provád tyto akce: a) Zobrazování grafů z naměřených hodnot b) Konfigurace měřen ěření na jednotlivých serverech c) Správa grafů d) Správa pluginůů a měřících měř kódů Základní ákladní rozvržení prvků prvk stránky je na Obr. 12. V levém horním rohu je logo, logo pod kterým je vodorovněě umístěné umíst hlavní menu, které určuje rozdělení ělení webu do hlavních sekcí. Pod menu je umístěná umíst tzv. drobečková navigace15, která umož možňuje přejít na jakoukoliv stránku v cestě na jediné kliknutí. Navigace avigace na stránce s konkrétním grafem může vypadat například říklad takto: Hlavní stránka > měřený ený server > kategorie graf grafů > konkrétní graf. Na hlavní části stránky budou zobrazeny grafy, případně p ě formuláře formulá pro
konfiguraci měřených ených serverů. Na konci stránky bude zobrazena standardní patička.
15
Drobečková navigace znázorňuje ňuje uje pozici aktuální stránky v hierarchii webu nezávisle na cestě, cest po které se na ni uživatel dostal.
34
Obr. 12 - Rozvržení webového rozhraní
I přesto, esto, že výstupem jsou pouze „grafy o využití serveru“, jsou obecně tato data považována za důvěrná, ěrná, proto je nutné zajistit autorizaci a autentizaci uživatelů. Každý uživatel by měl mít přístup řístup pouze do těch t částí, ástí, se kterými bude pracovat. Proto je nutné rozdělit lit uživatele do skupin, které bývají zpravidla hierarchicky provázané. Na Obr. 13 jsou zobrazené jednotlivé skupiny uživatelů 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í Obr.
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 m hodnot
U každého serveru bude možno přímo p z webového rozhraní určovat, ur jaké pluginy resp. senzoryy se budou měřit. m Vzhledem k tomu, že měřící ící kódy jsou uloženy na měřeném serveru již při ř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 ást datového modelu, kde je zaznamenáno, co se bude na jednotlivých serverech měřit. m Pro každý server bude v databázi uložen seznam senzorů,, kde každý senzor patří pat k právě jednomu pluginu. Dále je nutné mít i informaci o tom, jaké pluginy jsou přiřazeny p azeny ke konkrétnímu serveru. Tím vzniká v databázovém modelu cyklus, který bude nutné ošetřit ošet na aplikační úrovni. Vztah mezi plugi luginem a serverem je nutný kvůli pluginům, ům, kde není předem znám počet senzorů. Jde například nap o plugin, který měříí obsazení jednotlivých oddílů oddíl pevného disku, nebo měření měř datového toku na síťových ových rozhraních. Při P přiřazování takového pluginu k serveru není znám konkrétní počet oddílů nebo síťových sí 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 m na serveru další veličiny, iny, jednoduše si pomocí formuláře přidá idá jednotlivé senzory a pluginy a systém se postará tará o vytvoření vytvo RRD souborů na centrálním i měřeném serveru a zajistí vygenerování a spuštění spušt měřících kódů.. Celý proces bude detailně 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 COUNTER DERIVE ABSOLUTE COMPUTE
Uchovávání okamžité hodnoty - teplota Pro neustále se zvyšující čítače – odeslané bajty Stejné jako COUNTER, ale bez kontroly přetečení Pro COUNTER, který se nuluje při čtení Pro ukládání výsledků výpočtu hodnot z jiných zdrojů dat Tabulka 3 - Datové typy
AVERAGE MIN MAX LAST
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 Frameworky16. 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
externích knihoven a Frameworků, kdy po zvládnutí základních principů téměř odpadá nutnost nahlížet do dokumentace. Webová aplikace byla odladěna pro internetový prohlížeč Firefox s využitím rozšíření FireBug. Tento nástroj představuje komplexní ladící prostředí integrované přímo do prohlížeče. Umožňuje zobrazit objektový model stránky (DOM), debugger JavaScriptu a nástroj pro ladění vzhledu stránky (CSS). Pro tvorbu UML diagramů byl použit software Visual paradigm Comunity Edition. Tento nástroj nabízí propracované IDE pro vizuální návrh architektury aplikací pomocí notace jazyka UML.
5.3.
Volba nástroje pro tvorbu grafů
Naměřené hodnoty z jednotlivých serverů budou interpretovány ve formě grafů. Implementovat vlastní nástroj pro tvorbu grafů, který by umožňoval detailní konfiguraci zobrazení grafu, by bylo časově velmi náročné a nad rámec této práce. Použije se tedy existující software pro tvorbu grafů a to buď nástroj, který je součástí RRDTool, nebo nějaký jiný volně dostupný open-source nástroj. RRDTool umožňuje generovat obrázky grafů přímo z RRD souborů. Grafy se generují pomocí příkazu rrdtool graph, kterému je nutné předat několik parametrů (název výstupního souboru, rozsah časové osy, názvy RRD souborů a barvy zobrazení jednotlivých veličin). Kód pro vykreslení grafu může vypadat následovně: rrdtool graph load.png --start 920804400 --end 920808000 DEF:load=load.rrd:load:AVERAGE LINE:load#FF0000
Přestože rrdtool umožňuje široké možnosti nastavení výsledné podoby grafů, mohl by do budoucna představovat určité omezení. Pokud bychom požadovali například jiný typ grafu (koláčový), nebo vkládání komentářů přímo do grafu, bylo by nutné použít jiný nástroj. Z výše uvedených důvodů byl tedy zvolen JpGraph, který patří mezi jeden z nejpokročilejších volně dostupných17 řešení pro tvorbu grafů [4]. Tento nástroj
17
Volně dostupná verze JpGraph je pod licencí QPL 1.0, což nedovoluje použití v komerčních aplikacích.
44
umožňuje uje vše, co umí rrdtool a navíc neobsahuje žádné z výše uvedených omezení. Nevýhodou v porovnání s rrdtool však bude složitější jší implementace. JpGraph umožňuje umožň téměř „neomezené“ mezené“ možnosti nastavení výsledné podoby grafů. Lze vytvářet et grafy mnoha typů typ (sloupcové, čárové, árové, kruhové, 3D grafy). U grafu lze volit mezi lineárními a logaritmickými souřadnicemi, sou přidat idat legendu, či obrázek na pozadí.
5.4.
Implementace Shel-node Shel
Úkolem Shel-Node Node je měření m ení a zaznamenávání informací o činnosti serveru v definovaných intervalech. Dále musí umět um reagovat na příkazy íkazy centrálního serveru, tedy především edevším poskytnutí naměřených nam dat a změnu konfigurace měření. ěření.
Obr. 15 - Komponenty Shel-Node
Pro připomenutí ipomenutí z analýzy: data se budou ukládat lokálněě do RRD souborů. soubor O sběr dat (resp. nepřetržitý etržitý běh pool skriptů) se postará démon. mon. Komunikace s centrálním serverem bude zajištěna ěna přes p protokol SSH pomocí skriptu, který se spustí spust po přihlášení Shel-master serveru. Požadovaná funkčnost funk Shel-node node je implementována v Perlu metodou objektově orientovaného programování. Na měřeném eném serveru je nutné vytvořit vytvo uživatele shel, přes es kterého bude probíhat pomocí protokolu SSH komunikace s centrálním entrálním serverem. Tento uživatel bude vlastník zdrojových souborů aplikace a poběží pob pod ním i jednotlivé pool skripty. Standardní S umístění ní zdrojových souborů soubor aplikace je následující:
45
/opt/shel-node/ lib/Shel/* rrd/* poolers/* config/db.xml config/config.xml dataLoader.pl login.pl multiple.pl shel-node.pl updater.pl
/var/log/shel-node/ shel.log /etc/ init.d/shel-node logrotate.d/shel-node shel-node.conf shel-node-plugins.conf
V adresáři lib/Shel/ jsou pomocné třídy, které využívají skripty pro změnu konfigurace měření, poskytnutí naměřených dat a další. Adresář rrd obsahuje lokální úložiště naměřených hodnot. V adresáři poolers jsou uloženy vygenerované pool skripty. Soubor config/db.xml obsahuje všechny dostupné měřící kódy pro daný typ operačního systému a v souboru config/config.xml je uložen seznam aktuálně měřených pluginů a senzorů. Za pomoci těchto konfiguračních souborů a skriptu updater.pl jsou generovány jednotlivé pool skripty. Skript dataLoader.pl poskytuje naměřená data, login.pl
se spouští po přihlášení centrálního serveru a obsluhuje jeho požadavky, shel-
node.pl
spouští démona. Init-skript /etc/init.d/shel-node slouží pro ovládání démona při
startu a ukončení operačního systému. Dále jsou zde konfigurační soubory, které uchovávají hodnoty, které jsou specifické pro jednotlivé měřené servery.
5.4.1. Démon Implementace démona je v souboru shel-node.pl s využitím modulu lib/Shel/Daemon.pm. Jeho úkolem je spuštění měřících skriptů (poolerů) při startu systému a zajištění jejich nepřetržitého běhu. Pokud některý z měřících skriptů nepředpokládaně skončí, démon se jej za několik desítek sekund pokusí opět spustit. Časová prodleva před spuštěním měřícího skriptu je velmi důležitá, protože při 46
opakovaném pádu pooleru ihned po jeho spuštění by nastalo cyklické spouštění, které by vedlo k okamžitému vyčerpání všech systémových prostředků. Běh jediné instance démona je zajištěn typickým způsobem pomocí souboru, do kterého démon po startu zapíše svůj PID18. Démon musí být naprosto nezávislý na svém okolí, a proto je nutné provést po spuštění několik kroků: • • • •
Vytvoření souboru s PID procesu. Odpoutání od běžícího terminálu. Změna pracovního adresáře. Nastavení práv.
Vzhledem k tomu, že se jedná o monitorovací systém, je vhodné, aby neběžel s právy superuživatele. Po spuštění démona je tedy UID19 a EUID20 resp. GID a EGID procesu změněno na uživatele shel. Při ukončení běhu démona se démon postará o ukončení všech měřících skriptů.
5.4.2. Měřící skripty Úkolem měřícího skriptu (pooleru) je v definovaných intervalech odečítat požadované hodnoty a zaznamenávat je do RRD souborů. Pro každou kategorii měřených hodnot (systém, databáze, diskový systém) je jeden pooler. Ten je vygenerován
na
základě
měřících
kódů
(db.xml)
a
aktuálně
nastavených
pluginů/senzorů (config.xml). Formát XML byl zvolen z důvodu snadného parsování a zpracování dat za použití knihoven, které jsou v Perlu dostupné. Nepřetržitý běh poolerů zajišťuje démon. Pooler je realizován nekonečným cyklem, ve kterém je inkrementována řídící proměnná. Pomocí operace modulo se v cyklu testuje u jednotlivých pluginů, zda se má v daný čas příslušný kód provést. Základní interval je 5 sekund a intervaly měření u jednotlivých pluginů musí být jejím násobkem. Na konci smyčky se odečte doba samotného měření a dopočítá čas, po který bude daný pooler v režimu sleep. Pokud například samotné měření trvalo 0.01 sekundy, na konci smyčky se proces na 4.99 sekundy uspí. Tím je zajištěný poměrně přesný interval odečítání měřených hodnot.
18
PID je unikátní číslo, které identifikuje proces po dobu jeho běhu. UID (GID) identifikuje reálného uživatele (skupiny) a ovlivňují právo posílat signály. 20 EUID (EGID) ovlivňuje vlastnictví a přístup uživatele (skupiny) k souborům. 19
47
Samotné měření (například pro počet systémového volání fork za sekundu) vypadá následovně: if(($i % 5) == 0) { my $forks = `cat /proc/stat| grep processes`; ($forks) = $forks =~ m/processes (.*)/; chomp($forks); $now = time(); RRDs::update("/opt/shel-node/rrd//1_pcid/8_pgid/20_pid.rrd", "$now:".$forks); }
Kompletní seznam implementovaných pluginů, které jsou součástí této práce, je uveden v příloze.
5.4.3. Datové úložiště Naměřená data jsou ukládána do RRD souborů, kde pro každý senzor je vytvořen jeden soubor. Jednotlivé soubory jsou rozděleny do adresářů nejprve podle kategorie pluginu a poté podle pluginu. Například rrd/2_pcid/14_pgid/41_pid.rrd. Toto rozdělení je stejné jako na centrálním serveru, kde je z důvodu velkého množství souborů. Na měřeném serveru stačí uchovávat data pouze po dobu, než jsou odeslány do centrálního datového úložiště. Z důvodu možného výpadku centrálního serveru byl tento interval zvolen na 7 dní. I při tomto relativně dlouhém intervalu budou naměřená data zabírat při průměrném počtu aktivovaných senzorů cca 30MB, což je vzhledem k velikosti pevných disků zanedbatelné. Umožňuje nám to dovolit si velmi dlouhý výpadek centrálního serveru. Pro uchování dat tedy bude stačit jeden archiv, kde počet hodnot je nastaven na počet sekund za 7 dní dělený periodou měření pro daný plugin. Kód pro vytvoření RRD souboru vypadá následovně: my $rows = 604800 / $self->{period}; RRDs::create($rrdfile, "--start", time, "--step", $self->{period}, "DS:$sens->{ds_name}:$sens->{source_type}:" . 2*$self->{period}. ":$sens->{min}:$sens->{max}", "RRA:AVERAGE:0.5:1:$rows"); if(RRDs::error) { croak("Cannot create RRD file: $rrdfile: $err"); }
48
5.4.4. Komunikace s Shel-master serverem Komunikace s centrálním serverem probíhá pomocí protokolu SSH. Na měřeném serveru je vytvořen speciální uživatel shel, kterému se však po přihlášení nespouští klasický bash, ale tzv. login skript. Toto nastavení lze provést v souboru /etc/passwd, který uchovává základní informace o uživatelských účtech systému. Typicky vypadá záznam v tomto souboru například pro uživatele root takto: root:x:0:0:root:/root:/bin/bash Jednotlivé parametry jsou odděleny dvojtečkou. První udává jméno uživatele. Druhým parametrem je heslo, kde znak „x“ říká, že je uloženo v zašifrované podobě v souboru /etc/shadow. Třetí a čtvrtý parametr udává identifikátor uživatele a skupiny. Další parametry jsou komentář a domácí adresář. Posledním, v našem případě nejdůležitějším, parametrem je shell, případně příkaz, který se provádí při přihlášení uživatele. Typicky je zde uveden /bin/bash, případně /bin/false pro uživatele, kteří nemají právo se k danému systému přihlásit. Pro uživatele shel je tedy nastavena u posledního parametru cesta ke skriptu, který bude ovládat komunikaci s centrálním serverem. Záznam pro uživatele shel v souboru /etc/passwd vypadá tedy následovně: shel:x:30022:30022::/home/shel:/opt/shel-node/login.pl
Pokud se tedy uživatel přihlásí z Shel-master serveru na měřený server, spustí se skript login.pl a místo klasického bashe se zobrazí následující výstup: ################################ # Shel-node Controller # # To quit type "exit" # # To show help type "?" # ################################
Login skript je realizován jako nekonečná smyčka, kterou lze ukončit zadáním příkazu exit, případně uzavřením spojení na druhé straně, tedy z centrálního serveru. Na začátku cyklu je očekáván příkaz zadaný na standardní vstup. Možné příkazy jsou uvedeny v tabulce číslo 5. Pro každý příkaz se spustí specifický obslužný kód, přičemž neznámé příkazy jsou ignorovány. příkaz dataLoader updater Multiple pgid
Popis vrací naměřená data přegeneruje jednotlivé pool skripty spouští multiple kód pro daný plugin
49
loadConfig showLog Status Version ?
přečte hlavní konfigurační soubor zobrazí log soubor zobrazí běžící procesy uživatele shel vrací verzi shel-node zobrazí seznam příkazů Tabulka 5 - příkazy login skriptu
Nejdůležitější příkaz dataLoader slouží k odeslání naměřených dat. Centrální server musí nejprve na měřený server odeslat časy posledního stažení dat pro jednotlivé rrd soubory resp. senzory. Tyto informace se uloží do souboru rrd/lastUpdates, kde na každém řádku je uložena cesta k rrd souboru vzhledem k datovému úložišti a čas poslední aktualizace ve formátu Unix Timestamp. Řádek tedy vypadá například takto: 1_pcid/12_pgid/38_pid.rrd:1239634845.
Po úspěšném uložení časů
posledních aktualizací je spuštěn skript dataLoader.pl. Ten pro každý řádek času aktualizace provede načtení dat z příslušného RRD souboru. Časové rozmezí dat udává poslední aktualizace a aktuální čas. Data se vypíší na standardní výstup v následujícím formátu: #cesta k rrd souboru:čas poslední aktualizace čas:hodnota čas:hodnota čas:hodnota #cesta k dalšímu rrd souboru:čas poslední aktualizace čas:hodnota čas:hodnota čas:hodnota ...
Příkaz updater slouží pro konfiguraci seznamu měřených pluginů/senzorů. Proces změny konfigurace je zobrazen na Obr. 16. Shel-master odešle měřenému serveru seznam pluginů resp. senzorů, které mají být aktivní. Shel-node po přijmutí zastaví démona a spustí skript updater.pl, který zajistí vygenerování jednotlivých měřících skriptů. Poté spustí démona, který spustí nově vygenerované pool skripty. Celý proces bude ještě popsán v následující kapitole z pohledu centrálního serveru. Existují pluginy, kde není předem znám počet senzorů. Tyto pluginy jsou označovány jako „multiple“, jde např. o využití jednotlivých oddílů pevného disku, nebo měření datového toku na síťových rozhraních. Údaje o počtu senzorů je však nutné dostat na centrální server, aby bylo možné vytvořit příslušné rrd soubory a záznamy v databázi. K tomu slouží příkaz multiple, kterému je nutné předat jeden parametr a tím je id pluginu. Po spuštění příkazu se spustí příslušný multiple kód a výstup se zapíše 50
na standardní výstup, který zpracuje centrální server. Multiple pluginy budou podrobně popsány ještě z pohledu centrálního serveru.
Obr. 16 - Změna konfigurace měřeného serveru
Příkaz loadConfig vypíše na standardní výstup konfigurační konfigu soubor Shelnode, tedy /etc/shel-node.conf. /etc/shel Shel-master musí mít v některých ně případech informaci o umístění ní Shel-node Shel na měřeném eném serveru. Tyto informace jsou uloženy ve výše uvedeném souboru. Zobrazení konfigurace parametrů jednotlivých pluginů plugin (/etc/shel-node-plugins plugins.conf) není záměrně umožněno, ěno, protože jsou zde uložena například íklad hesla pro přístup p k databázi apod. Do login skriptu bylo přidáno p ještě několik pomocných příkazů říkazů. Ty mají za účel pomoci s diagnostikou systému na těch měřených ených serverech, kam k nemá správce aplikace klasický SSH přístup. p Konkrétně jde o příkazy showLog, status a version. ShowLog zobrazí posledních 50 řádků logovacího souboru, status zobrazí všechny běžící ěžící procesy uživatele shel a příkaz version aktuální nainstalovanou verzi Shel el-node.
51
5.4.5. Konfigurační soubory a logování Aplikace Shel-node potřebuje pro svůj běh nastavit několik parametrů. Ty jsou uloženy v souboru /etc/shel-node.conf. Konkrétně jde o kořenový adresář aplikace, adresář s měřícími skripty a datovým úložištěm, dále jde o cestu k logovacímu souboru a souboru s uloženým PID démona. Dalším konfiguračním souborem je /etc/shel-node-plugins.conf. Zde jsou uloženy parametry některých pluginů – například přístupové údaje k databázi, které jsou specifické pro každý měřený server a nemohou být tedy součástí samotného měřícího kódu. Čtení konfiguračních souborů je zajištěno pomocí modulu Shel::Config. Ten je implementován pomocí návrhového vzoru singleton, který zajišťuje vytvoření pouze jediné instance daného objektu. Třída má jeden vstupní parametr a tím je cesta ke konfiguračnímu souboru. Třída je tedy univerzální pro všechny konfigurační soubory. Návratovou hodnotou je asociativní pole, které obsahuje jednotlivé konfigurační volby jako klíč. Proces logování stavových informací a chybových hlášení je implementován pomocí balíku Log4Perl[6], což je komplexní systém pro řízení logování. Log4Perl umožňuje řídit logování na různých úrovních (Info, Debug, Error, Fatal), snadno přepínat mezi logováním na standardní výstup a do souboru a také nastavovat podobu výstupu pomocí zástupných znaků (PatternLayout). Systém provádí měření ve velmi krátkých intervalech. Pokud by měření pravidelně selhávalo, bude vznikat velké množství informací k logování. To lze omezit nastavením úrovně logování. Další možností je rotování logovacího souboru. Logovací soubor je pravidelně po překročení velikosti nebo stanoveného intervalu archivován a označen číselnou příponou, která se zvětšuje se stářím souboru. Počet archivů lze omezit a archivy nad definovaný počet budou pravidelně mazány. O rotování logovacího souboru se postará nástroj logrotate, který je pravidelně spouštěn pomocí
programu
cron.
Konfigurace
rotování
je
umístěna
v
/etc/logrotate.d/shel-node. Velikost souboru je omezena na 10MB a počet souborů na 4.
52
5.4.6. Shel-node balík pro Debian Pro snadnou instalaci aplikace na měřený server byl vytvořen instalační balík Shel-node pro operační systém Debian GNU/Linux. Instalační balík umožňuje pohodlnou instalaci aplikací na daný operační systém. Největší výhodou je především automatická instalace všech závislých balíku. Soubor s balíčkem má příponu .deb a je možné jej nainstalovat pomocí nástroje dpkg. Pokud je balík zařazen do repositáře (centrální server, na kterém jsou umístěné jednotlivé balíky), instaluje se pomocí správce balíčků apt-get nebo aptitude. Zdrojové soubory aplikace je nutné nahrát do zvláštního adresáře (např. package). V tomto adresáři se poté vytvoří stejná adresářová struktura, jako je na instalovaném operačním systému.
Pokud tedy chceme, aby se soubor shel-
node.conf při instalaci nahrál do adresáře /etc, vytvoříme adresář package/etc a nahrajeme do něj soubor shel-node.conf. Takto rozmístíme všechny zdrojové soubory aplikace. V adresáři package je nutné ještě vytvořit adresář debian. Do tohoto speciálního adresáře se umístí soubory, které slouží k řízení instalačního procesu a obsahují informace o daném balíku. Přehled souborů je v níže uvedené tabulce. soubor
popis
control
základní informace o balíčku
changelog
seznam změn mezi jednotlivými revizemi
copyright
informace o licenci
preinst
skript spuštěný před instalací
postinst
skript spuštěný po instalaci
prerm
skript spuštěný před odstraněním
postrm
skript spuštěný po odstranění
rules
pravidla pro make, pomocí kterých se balík kompiluje Tabulka 6 - Debian balík
Samotný balík se vytváří pomocí nástroje dpkg, konkrétně zadáním příkazu dpkg-buildpackage
–rfakeroot. Balíčky by se měly kompilovat pod
uživatelem root, aby bylo možné vytvářet soubory se správnými právy. Toto však není bezpečná cesta, a proto vznikl wrapper fakeroot, který předstírá, že proces běží
53
pod uživatelem root a přístupy řístupy na soubory emuluje tak, aby přístupová p ístupová práva zůstala z zachována po dobu jeho běhu. ěhu. Pro kompilační kom ní proces tak vše vypadá, že běží b pod superuživatelem, ale ve skutečnosti skuteč se používá běžný účet uživatele. Spuštěním Spušt výše uvedeného příkazu íkazu vzniká soubor s příponou .deb,, který už lze instalovat opět pomocí nástroje dpkg.
5.5.
Implementace Shel-master Shel
Shel-Master Master slouží jako centrální úložiště úložišt nasbíraných dat z měřených ěřených serverů. server Zajišťuje pravidelné stahování ní naměřených nam dat z jednotlivých serverů. Na Obr. 17 jsou zobrazeny hlavní komponenty, včetně v webového rozhraní, které je popsané pops v další kapitole.
Obr. 17 - Komponenty Shel-Master
Na Shel-master master serveru je vytvořen vytvo uživatel shel-master.. Tento uživatel je vlastník všech zdrojových souborů soubor aplikace a pomocí svého klíčee se přihlašuje př přes SSH protokol na měřené ené servery. Soubory Shel-master jsou rozmístěny ny následovně: následovn /opt/shel-master/ src rrd run tmp transactions /var/log/shel-master/ shel.log error.log /etc/ shel-master.conf
54
V adresáři src jsou umístěny zdrojové soubory aplikace, rrd tvoří centrální datové úložiště, kam se stahují data z jednotlivých měřených serverů. Adresář run slouží pro ukládání informací, které jsou potřeba k běhu aplikace – konkrétně jde o soubory, které zprostředkovávají komunikaci webové aplikace a Shel-master serveru. Adresář tmp slouží k ukládání dočasných souborů, typicky jde o soubory, které se poté odesílají na měřený server (časy posledních aktualizací, konfigurace pluginů/senzorů). Do adresáře transactions se ukládají naměřená data z jednotlivých serverů před zpracováním. Součástí Shel-master serveru je také konfigurační soubor (/etc/shelmaster.conf), kde je uložena cesta k aplikaci, datovému úložišti a nastavení přístupových údajů k databázi. Údaje o činnosti a chybách jsou zaznamenávány do souboru shel.log a error.log ve /var/log/shel-master/. Konkrétní umístění logovacích souborů lze nastavit v konfiguračním souboru. Zdrojové soubory aplikace (adresář src) jsou rozděleny do třech podadresářů: lib, bin a cron. V lib jsou pomocné třídy, které využívají skripty pro stahování naměřených dat, konfiguraci měřených serverů apod. V adresáři bin jsou spustitelné skripty. Konkrétně jde o db-xml-export.pl, který po spuštění vygeneruje XML soubor, ve kterém jsou informace o senzorech a pluginech včetně měřících kódů. Tento soubor je poté součástí Shel-node a na jeho základě jsou generovány měřící skripty. Dále je zde soubor nodeReconfigure.pl, který zajišťuje vygenerování XML souboru s aktuálně nastavenými pluginy/senzory a jeho odeslání na konkrétní měřený server. Popis jednotlivých skriptů, které jsou v adresáři cron, je uveden v následující kapitole.
5.5.1. Cron tabulka Důležitou součástí Shel-master serveru je cron tabulka, která zajišťuje spouštění skriptů v definovaných intervalech. Jedná se o cron tabulku uživatele shel-master, pod kterým budou jednotlivé skripty spouštěny. Záznam v cron tabulce má 6 parametrů, které se oddělují pomocí mezer, nebo tabulátorů. Prvních pět parametrů udává dobu resp. interval spouštění (popořadě minuta,
55
hodina, den v měsíci, měsíc, den v týdnu) a poslední parametr je příkaz, který se má v definovaný čas vykonat. Záznam v tabulce může vypadat následovně: 10
0 * * * /opt/shel-master/src/cron/getVersions.pl
Skript getVersion.pl se bude dle výše uvedeného záznamu spouštět každý den v čase 0:10. Pokud je potřeba provádět určitý příkaz např. po pěti minutách, není nutné vypisovat jednotlivé časy spouštění (5,10,15…), ale stačí zadat */5. Pro Shel-master zajišťuje cron tabulka spouštění následujících skriptů (podrobnější popis jednotlivých skriptů je uveden v dalších kapitolách): • • •
loader-parallel.pl – stahování dat z měřených serverů collectChanges.pl – změna konfigurace senzorů/pluginů u měřených serverů getVersion.pl – zjištění verze shel-node
5.5.2. Datové úložiště Naměřená data jsou z jednotlivých měřených serverů stahována a ukládána do RRD souborů v centrálním datovém úložišti. Z těchto souborů budou poté vykreslovány požadované grafy. Pokud bude systém monitorovat větší množství serverů, bude v úložišti poměrně velké množství souborů. Lze očekávat také velké nároky na dostatek volného prostoru na disku, které závisí především na nastaveném intervalu měření. Jednotlivé soubory jsou tedy rozděleny do adresářů podobně jako na měřeném serveru. Nejprve dle serveru, poté kategorie pluginu a nakonec pluginu. Umístění RRD souboru tedy vypadá například takto: rrd/1_sid/4_pcid/6_pgid/48_pid.rrd. Na Shel-master serveru už nestačí uchovávat data pouze několik dní, jako tomu bylo na měřeném serveru. Uchovávat data po celou dobu ve stejném rozlišení, jako se provádí samotné měření, by bylo extrémně náročné na místo na pevném disku. V každém rrd souboru je tedy definováno několik archivů, každý s jiným rozlišením. Konkrétně bylo zvoleno následující rozdělení (pro interval měření 5 sekund): Interval 0 – 7 dní 0 – 2 měsíce 0 – 1 rok 0 – 10 let
Hustota ukládání dat 5 sekund 60 sekund 5 minut 1 hodina
Tabulka 7 - hustota ukládaní dat na centrálním serveru
56
Vzhledem k tomu, že data v hrubších intervalech se budou dopočítávat (průměrovat), jsou vytvářeny nejen archivy typu AVERAGE, ale i MAX. Z důvodu pozdější změny nebo rozšíření jsou parametry jednotlivých archivů uloženy v databázi a přiřazeny k jednotlivým senzorům zvlášť. Příkaz pro vytvoření RRD souboru na centrálním serveru vypadá například takto: RRDs::create ($rrd_file, ”—start”, $start, ”—step”, 5, “DS:$dataSource:GAUGE:10:U:U”, “RRA:AVERAGE:0.5:1:120960”, “RRA:AVERAGE:0.5:12:89280”, “RRA:MAX:0.5:12:89280”, “RRA:AVERAGE:0.5:60:105120”, “RRA:MAX:0.5:60:105120”, “RRA:AVERAGE:0.5:720:87600”, “RRA:MAX:0.5:720:87600” );
5.5.3. Stahování dat Jak již bylo řečeno výše, data jsou z jednotlivých měřených serverů stahována na centrální server v pravidelných intervalech. Spouštění skriptu, který stahuje data, zajišťuje program cron. Interval spouštění by měl být relativně krátký, aby na centrálním serveru byly data aktuální. To znamená interval v řádu jednotek minut. Shel-master musí být schopný v daném intervalu stáhnout data ze všech serverů. Při průměrném množství senzorů se za 5 minut na měřeném serveru nasbírá maximálně několik desítek KB dat. Pokud předpokládáme, že měřený i centrální server jsou propojeny pomocí 100Mb ethernetu, je samotná doba přenosu dat velmi krátká. Rychlost stahování dat tedy nebude záviset na jejich objemu, ale především na režii při komunikaci. Připojovat se postupně k jednotlivým serverům sekvenčně by bylo vzhledem k výše uvedené režii časově náročné. Proto je stahování dat realizováno paralelně. Pro každý server se před samotným připojením tedy vytvoří samostatný proces, čímž se výrazně sníží doba stahování dat. Aby bylo možné v budoucnu systém rozšířit o další komunikační protokoly21, je zde použit návrhový vzor Factory. Diagram tříd je zobrazen na Obr. 18. Předpokladem je existence několika tříd, které mají společného předka, ale poskytují různé služby nad různými daty (v našem případě komunikaci přes různé protokoly). Vzor Factory 21
Součástí této práce je implementace komunikace pomocí protokolu SSH
57
dovoluje poté za běhu programu zvolit, z jaké třídy se vytvoříí instance (který protokol se použije ke komunikaci).
Obr. 18 - Diagram tříd t podpory více komunikačních protokolů
Celý proces je zobrazen na Obr. 11. Nejprve je nutné načíst z databáze seznam serverů,, ze kterých se mají data stahovat. Pro každý server se poté poté pomocí systémového volání fork()vytvoříí samostatný proces. O samotné stáhnutí dat se stará třída t ShelDataLoaderSSH. Nejprve je nutné projít všechny RRD soubory na centrálním serveru a zjistit časy asy posledních aktualizací pro jednotlivé senzory.. Poté se připojit k měřenému enému serveru a odeslat mu tyto údaje spolu s příkazem dataLoader. dataLoader Měřený server odešle naměřená ená data, vzhledem k časům, které dostal k jednotlivým senzorům. Samotný proces ukládání dat je rozdělen rozd len na dva samostatné kroky: data jsou nejprve stažena tažena do textového souboru a poté parsována a ukládána do jednotlivých RRD souborů. To umožňuje uje rychlé stažení dat a ukončení ukon spojení a poté časově časov relativně náročné né zapisování do jednotlivých RRD souborů. Druhý krok je nezávislý na použitém komunikačním protokolu a jeho implementace je tedy umístěna umíst v rodičovské rodič třídě ShelDataLoaderAbstract Abstract. Po samotném zápisu do RRD souboru je do databáze uložen aktuální čas as u daného senzoru a serveru. Na základě těchto chto údajů lze poté ve webové aplikaci zobrazovat výpadky výpadk měření pro jednotlivé senzoryy na daných serverech.
5.5.4. Změna na konfigurace pluginů/senzorů plugin Změnou nou konfigurace je míněno mín aktivování resp. deaktivování některých ěkterých senzorů nebo pluginů u vybraného serveru. To lze provést pomocí webové aplikace. aplikace Webový server Apache běží ží pod uživatelem www-data. Tento uživatel nemá přístupová řístupová práva k přihlašování na měřené ené servery. Je tedy nutné zajistit komunikaci mezi webovou webov aplikací a Shel-master servereem. Nejjednodušším způsobem je použít komunikaci skrze 58
soubory. Pokud uživatel změní konfiguraci měřeného serveru, je tato informace (pouze id daného serveru) zapsána do souboru, konkrétně do run/changes. Změnu konfigurace měřených serverů zajišťují skripty collectChanges.pl a nodeReconfigure.pl. Pomocí programu cron je zajištěno jeho pravidelné spouštění (každých několik minut). Proces je zobrazen na Obr. 16. Skript si ze souboru run/changes načte seznam serverů, u kterých má provést změnu konfigurace. Pro každý server je poté na základě údajů v databázi vygenerován seznam aktivovaných pluginů/senzorů ve formě XML souboru. Tento soubor je poté uložen na měřený server a pomocí příkazu updater se provede přegenerování měřících skriptů. Pro urychlení celé operace je opět implementováno paralelní spuštění pro jednotlivé servery.
5.6.
Zend Framework
Webová aplikace je implementována v PHP za použití Zend Frameworku [2][3]. V této kapitole jsou tedy popsány základní principy, které je nutné znát při vytváření aplikací v tomto Frameworku. Pro snadnější pochopení a představu je popis doplněn jednoduchými příklady. Adresářová struktura zdrojových souborů je následující: /www /application /controllers /forms /models /views /library /log /public /css /images /js
Document
root22
je
nastavený
na
adresář
public.
V adresáři
application jsou veškeré zdrojové soubory (jsou tedy mimo document root, což zvyšuje bezpečnost zdrojového kódu). V library je samotný Framework, dále vlastní rozšíření Frameworku pro konkrétní aplikaci a další knihovny třetích stran.
22
Document root je kořenový adresář, ze kterého webový server Apache servíruje požadované soubory.
59
Zend Framework implementuje návrhový vzor Front
controller
pattern, kde všechny požadavky jsou přesměrovány na jediný soubor (index.php umístěný v adresáři public), kterému se říká bootstrap soubor. Přesměrování požadavků lze zajistit pomocí mod_rewrite23 a souboru .htaccess24, který vypadá následovně: RewriteEngine on RewriteRule !\.(js|ico|gif|jpg|jpeg|png|css|txt|pdf|xml)$ index.php
Nejprve je nutné aktivovat přepisování adres. Samotné přesměrování požadavků na soubor index.php zajistí výše uvedené pravidlo (RewriteRule). Je však nutné nepřesměrovávat požadavky na fyzické soubory (např. obrázky, soubory se styly a JavaScript), což je zajištěno pomocí jednoduchého regulárního výrazu. Jak již bylo řečeno, jedná se o MVC Framework. Aplikace je rozdělená na tři nezávislé části: model (model), view (pohled) a controller (řadič). Stejně tak jsou rozděleny i zdrojové soubory do zvláštních adresářů. Model představuje vrstvu nad databází nebo datovým úložištěm, pohled slouží k zobrazení požadovaných informací a řadič zajišťuje zpracování událostí a propojení mezi modelem a pohledem. Příklad použití MVC architektury: 1. Uživatel provede nějakou akci (např. odešle formulář s registračními údaji). 2. Tuto informaci zpracuje řadič a údaje z formuláře předá modelu a určí, jakou akci má model s daty provést. 3. Model zpracuje předaná data - aktualizuje údaje v databázi (např. přidá záznam o novém uživateli). 4. Model předá informace o dokončení akce řadiči a ten na jejich základě připraví data pro pohled 5. Pohled se postará o vygenerování HTML kódu stránky a odeslání k prohlížeči. 6. Systém očekává další akci od uživatele a celý proces se opakuje.
Výhodou výše uvedeného rozdělení je snadná implementace změn. Pokud bude potřeba například implementovat ovládání webové aplikace pomocí příkazové řádky, stačí se zabývat pouze úpravou pohledu (view), model a řadič zůstanou beze změn.
23 24
Mod_rewrite umožňuje přepisovat požadovaná url a „mapovat“ je na fyzické soubory. Soubor .htaccess umožňuje měnit konfiguraci webového serveru Apache.
60
5.6.1. Bootstrap soubor (index.php) Jak bylo řečeno v úvodní části této kapitoly, na soubor index.php jsou směrovány všechny požadavky. Provádí se zde tedy nastavení různých parametrů aplikace a inicializace objektů, které jsou obecně nutné ke zpracování kteréhokoliv požadavku. Konkrétně jde o Zvolení časového pásma Nastavení cest ke zdrojovým souborům Konfigurace globálních proměnných Připojení k databázi Inicializace objektu ACL, který zajišťuje autorizaci uživatelů Inicializace Zend_Controller_Front objektu, který zajišťuje zpracování požadavků 7. Zpracování chybových stavů
1. 2. 3. 4. 5. 6.
5.6.2. Model (model) Model je část aplikace, která má na starost práci s databází (výběr a aktualizaci dat). Samotné připojení k databázi je implementováno v bootstrap souboru. Pro každou databázovou tabulku je vytvořena třída, která je potomkem třídy Zend_Db_Table25. Třída poskytuje metody pro mnoho běžných operací (select, insert, update), které jsou nezávislé na použitém databázovém systému. Třída umí pracovat s většinou běžně dostupných databázových systémů. Postará se také o načtení všech potřebných informací (metadat) o tabulce, které jsou nutné k provádění požadovaných operací. Níže je uveden jednoduchý příklad třídy reprezentující tabulku uživatelů, kde je implementována funkce, pro výběr informací o uživateli z databáze na základě Id: class Users extends Zend_Db_Table { protected $_name = 'users'; protected $_primary = 'uid'; function getUserById($uid) { $where = $this->db->quoteInto('uid = ?', $uid); $user = $this->fetchRow($where); return $user; } }
25
Třída Zend_Db_Table implementuje návrhový vzor Table Data Gateway
61
5.6.3. Řadič (controller) Řadič zajišťuje zpracování událostí a propojení s modelem a pohledem. Každá událost, která na stránce nastane (kliknutí na odkaz, odeslání formuláře), je označována jako akce (action). Související akce jsou sdruženy do jednoho řadiče. Příkladem může být třeba controller user a akce add, delete a edit. Který řadič a akce obslouží požadavek je určeno na základě požadované URL. Tento proces se nazývá routování. Pokud uživatel klikne na odkaz http://www.domena.cz/server/add, zavolá se funkce, která obsluhuje akci add v řadiči server. Toto je standardní způsob routování, který lze změnit napsáním vlastního routeru, což je v mnoha případech nezbytné z důvodu SEO (optimalizace stránek pro vyhledávače). V Zend Frameworku je řadič implementován jako třída, která se musí jmenovat {název Controlleru}Controller a musí být uložena v souboru se stejným jménem a příponou .php v adresáři controllers. Každá akce je implementována jako funkce, která musí být pojmenována {název akce}Action. V níže uvedeném příkladu je implementován řadič user a akce showuser, která zajistí zobrazení informací o uživateli na základě jeho Id (uid). Akce se tedy volá při požadavku na URL ve tvaru/user/showUser?uid=3. class UserController extends Zend_Controller_Action { public function showuserAction() { $uid = $this->_request->getParamd("uid"); $users = new Users(); $user = $users->getUsersById($uid); $this->view->user = $user; } }
5.6.4. Pohled (view) Pohled slouží k prezentaci dat (vygenerování HTML kódu), které dostane od řadiče resp. modelu. Zend Framework umožňuje použít pro generování HTML i šablonovací systémy, jako např. Smarty. Pro implementaci pohledů bylo použito klasické PHP.
62
Pro každou akci je nutné vytvořit zvláštní soubor, který se umístí do views/scripts/{controller-name}/{action-name}.phtml. Data se do pohledu předávají v řadiči pomocí $this->view->{proměnná} = ${proměnná}. Tato proměnná je poté v pohledu dostupná jako $this->{proměnná}. Níže je uveden příklad view skriptu, který zobrazí informace o uživateli (za použití výše uvedené implementace modelu a řadiče).
user->nick; ?>
| Name: | user->name; ?> |
| Surname: | user->surname; ?> |
| E-mail: | user->email; ?> |
5.7.
Implementace webové aplikace
Webová aplikace představuje hlavní část celého systému. Umožňuje zobrazování grafů naměřených hodnot, konfiguraci měření na jednotlivých serverech, správu grafů, pluginů a měřících kódů. Zajišťuje také autorizaci a autentizaci uživatelů systému.
5.7.1. Struktura webové aplikace Požadovanou funkčnost zajišťuje několik řadičů. Jejich seznam s krátkým popisem je uveden v následující tabulce. AuthController GraphController HelpController PluginController SenzorController ServerController ShelController UserController
Autentizaci uživatelů Správa a zobrazení grafů Zobrazování nápovědy Správa pluginů Správa senzorů Správa serverů Stavové informace Správa uživatelů Tabulka 8 - Seznam řadičů
63
5.7.2. Grafy Grafy jsou generovány pomocí nástroje JpGraph[4] do formátu PNG26. Implementace je rozdělena lena na několik částí. Soubor models/GraphData.php models/GraphDat slouží jako datový model. Zajišťuje Zajiš načtení potřebných dat z RRD souborů soubor a jejich zpracování. Soubor JpGraph.php slouží k nastavení všech potřebných ebných parametrů parametr výsledného grafu. Předání edání dat mezi výše uvedenými soubory je realizováno v GraphControlleru.. Vygenerovaný obrázek je přímo p odeslán lán webovému prohlížeči.
Obr 19 - Část datového modelu grafů Obr.
Přii generování grafu je nejprve nutné vytvořit vytvo objekt třídy GraphData, GraphData který zajistí načtení tení požadovaných dat pro graf z databáze. Grafy rafy lze definovat přímo p z webového rozhraní. Informace o grafu (které veličiny veli iny budou zobrazeny, rozměry rozm grafu, barvy atd.) jsou uloženy v databázi. Část ást modelu databáze, kde jsou uloženy informace o grafech, je zobrazen na Obr. 19. Konstruktor třídy GraphData přijímá několik kolik povinných parametrů (id serveru a grafu, časové rozpětí). tí). Na základě základ těchto parametrů zjistí z databáze informace o umístění umíst RRD souborů a načte na z nich požadovaná data. Datový model (objekt třídy t GraphData) je předán třídě řídě JpGraph. Zde se nejprve nastaví parametry grafu (rozměry, (rozm mřížka,, osy atd.). O samotné vygenerování grafu se stará metoda generate(), která zajišťuje uje vložení dat do grafu a přidání legendy.
26
PNG (Portable Network Graphics) je grafický formát pro bezztrátovou kompresi rastrové grafiky.
64
Generování grafů, které zobrazují data z více senzorů, je poměrně náročné na systémové prostředky. Náročnost lze snížit zavedením tzv. mezipaměti (cache). Pokud vezmeme v úvahu, že např. roční graf se změní jednou za den, bude vhodné obrázek po vygenerování uložit. Velikost obrázku je v jednotkách KB, proto bohatě postačí ukládání na straně serveru. Server poté při opětovném požadavku odešle již vygenerovaný graf. Načtení již zpracovaného grafu je nutné časově omezit vzhledem k časovému rozsahu požadovaného grafu (tzv. zneplatnění mezipaměti).
Obr. 20 - Ukázka grafu využití CPU
Obr. 21 - Ukázka grafu využití webového serveru Apache
Funkce, které zajišťují definici a správu grafů jsou implementovány v řadiči GraphController. Uživatel si může definovat další grafy a určovat, které senzory budou zobrazovat. Na Obr. 22 je vidět stránka s definicí grafu.
65
Obr. 22 - Definice grafu
Jednotlivé grafy jsou rozděleny do kategorií, které usnadňují procházení grafů. Stránka serveru je zobrazena na Obr. 23. Je na ni seznam kategorií grafů a dva nejdůležitější grafy (využití CPU a Load27). Nad grafy je uvedena informace o senzorech, které se sice měří, ale nejsou zobrazovány v žádném grafu.
Obr. 23 - Stránka serveru
27
Load udává okamžitý počet procesů, které čekají ve frontě na obsloužení.
66
5.7.3. Autentizace a autorizace uživatelů Autentizace (ověření identity uživatele) je zajištěna pomocí komponenty Zend_Auth a řadiče AuthController. Údaje z přihlašovacího formuláře jsou porovnány s údaji v databázi. V případě úspěšného ověření identity je vytvořena relace28 (session), do které jsou přihlašovací údaje uloženy. Autorizace je proces, při kterém je uživateli na základě dostupných informací přidělen nebo odepřen přístup k dané části systému. V Zend Frameworku je pro tyto účely vytvořená komponenta Zend_Acl. Základním kamenem systému autorizace jsou role (roles) a zdroje (resources). Role je v tomto případě role uživatele, která je uložena v databázi. Zdrojem je akce určitého řadiče (controller), případně celý řadič. Pomocí objektu Zend_Acl se definují jednotlivé role a k nim odpovídající akce, které mohou uživatelé provádět (výchozím nastavením je zákaz přístupu ke všem zdrojům). Role lze mezi sebou hierarchicky provázat (a to i do stromové struktury). Pokud tedy např. povolíme vybranou akci pro roli user, je automaticky povolena i pro roli admin. Příklad definice přístupových práv je uveden níže. Parametry metody allow jsou: role, řadič a akce. Pokud není uveden poslední parametr, pak platí pravidlo pro všechny akce u daného řadiče. $this->allow('user', 'graph', 'showDetail'); $this->deny('user', 'graph', 'delete');
Pokud uživatel žádá o provedení akce, ke které nemá oprávnění, je automaticky přesměrován na stránku s odmítnutím přístupu. Výše uvedené řešení umožňuje velmi snadnou a flexibilní správu přístupu uživatelů k různým částem systému. Při jakékoliv změně v autorizaci stačí upravit jediný soubor a není tedy nutné procházet celý zdrojový kód.
5.7.4. Informace o stavu systému Měření informací o serveru může z několika důvodů selhat (např. soubor, ve kterém jsou uloženy měřené informace nejde otevřít, nebo měřená databáze není spuštěna apod.). Vzhledem k tomu, že je webové rozhraní pro všechny měřené servery 28
HTTP je bezestavový protokol a relace je způsob, jak uchovávat informace o stavu aplikace (přihlášení uživatelé)
67
centralizované, lze na jednom místě snadno zobrazovat informace o stavu měření na jednotlivých serverech (Obr. 24). Po stáhnutí naměřených dat ze serveru, je v databázi u každého senzoru upravena časová značka poslední aktualizace. Díky tomu lze vypsat u jednotlivých senzorů dobu výpadku měření. Pro úplnost je ještě zobrazeno posledních několik desítek řádků logovacího souboru.
Obr. 24 - Stránka zobrazující stav měření
5.7.5. Další funkce webové aplikace Rozhraní umožňuje mnoho dalších funkcí, jejichž konkrétní implementaci není nutné podrobně popisovat. Jedná se o správu uživatelů (vytvoření uživatele, změna hesla), správu serverů (přidání serveru, odstranění, aktivování stahování dat), správu výchozích pluginů a senzorů a další.
68
6. Statistické zpracování naměřených dat Statistické zpracování dat je soubor metod, které slouží k získání dat a jejich následné analýze. V této práci je popsána jednoduchá metoda, jejímž cílem je zobrazení trendu měřené veličiny v delším časovém úseku. Výsledek bude reprezentován v podobě přímky, která bude zobrazena přímo v grafu. Rovnici přímky lze zjistit pomocí lineární regrese, což je aproximace naměřených hodnot polynomem prvního řádu. Otázkou tedy je, jaké hodnoty se budou aproximovat. Typický průběh zatížení serveru (ať už jde o využití CPU, počtu běžících procesů Apache, nebo počet procesů ve frontě) je na Obr. 25.
Obr. 25 - Typický průběh využití CPU u webového serveru
Vzhledem k nerovnoměrnému rozložení zatížení během dne bude vhodné brát v potaz pouze jednu hodnotu za celých 24 hodin. Na tyto hodnoty se poté aplikuje lineární regrese a výsledkem bude požadovaná přímka zobrazující trend. Zbývá tedy určit metodu, která poskytne z údajů za celý den pouze jednu hodnotu. Aritmetický i geometrický průměr je naprosto nevhodný vzhledem k nerovnoměrnému rozložení dat. Další možností je modus29 nebo medián30, které jsou však také nevhodné. Podobně maximální hodnota, vzhledem k možným špičkám. Pokud však odstraníme ze vzestupně seřazených dat například 5% největších hodnot, a vezmeme ze zbytku největší hodnotu, dostáváme poměrně dobře vypovídající údaj o zatížení. Tato hodnota je označována jako percentil 95%.
29 30
Modus je hodnota, která se vyskytuje nejčastěji. Medián rozděluje seřazenou řadu čísel na dvě stejné poloviny.
69
Nejprve jsou tedy vypočítány percentily pro jednotlivé dny. Tyto hodnoty jsou poté pomocí lineární regrese proloženy přímkou, která určuje trend měřené veličiny. Přímka je poté zobrazena v grafu. Výsledek je zobrazen na Obr. 26.
Obr. 26 - Výsledná podoba lineárního proložení
70
7. Testování Otestovat popisovanou aplikaci na všechny typy unixových operačních systémů, by bylo nad rámec této práce. Testování tedy proběhlo pouze na operačním systému Debian GNU/Linux. Pro tento OS byl vytvořen instalační balíček komponenty ShelNode (měřený server). V rámci testování byla aplikace nasazena v jedné webhostingové společnosti na cca 30 serverů. Při instalaci na jednotlivé servery se objevilo několik problémů. Ve všech případech šlo o chyby v pre/post instalačních skriptech balíčku, kde se projevily odlišnosti jednotlivých serverů. Při postupné instalaci se také rozšiřoval seznam závislostí balíku. Součástí
testování
webové
aplikace
bylo
také
jednoduché
testování
použitelnosti, neboli useability testování, což je měření snadnosti použití produktu, nebo softwaru. Provádí se pozorováním uživatele při práci s testovaným objektem. Vzhledem k testování v domácím prostředí byl potřebný HW nahrazen softwarem. Byla použita trial verze programu BB FlashBack, který umožňuje snímání obrazovky včetně zaznamenávání zvuku a videa z webové kamery. Při přehrávání uloženého záznamu je zvýrazněn kurzor myši a každé kliknutí je doprovázeno grafickým efektem, dále je vidět i např. použití kolečka myši a stisk jednotlivých kláves. Testovací scénář vypadal následovně: •
Vysvětlit cíle testu + rychlý průchod jednotlivými úkoly kvůli případným nejasnostem (důvodem je co nejmenší zásah v průběhu testování).
•
Zdůraznit testované osobě, že pokud si nebude s něčím vědět rady, tak to není jeho chyba, ale chyba tvůrců aplikace.
•
Požádat testovaného, aby „přemýšlel nahlas“ a nebál se sdělit svůj názor a kritiku.
•
Upozornit na to, že se bude nahrávat zvuk a obraz.
Testované osobě byly předloženy tyto úkoly: 1. Přihlásit se do webového rozhraní. (Účet byl předem vytvořen administrátorem). 2. Zobrazit graf využití procesoru u zadaného serveru.
71
3. Definovat vlastní graf, který bude zobrazovat datový tok na síťových rozhraních eth0 a loopback. 4. Nainstalovat Shel-Node na server, přidat jej do systému a zvolit, které hodnoty se mají měřit. K testování byly vybrány čtyři osoby, které pracují jako linux administrátoři (jde o předpokládanou cílovou skupinu). Úkoly 1,2 a 4 zvládli všechny testované osoby bez problémů. U dvou osob však nastaly drobné problémy s úkolem číslo 3. Na základě těchto problémů bylo rozhraní pro definici vlastních grafů přepracováno a doplněno o nápovědu. Dále byl přidán popis pojmů, které nemusí být na první pohled zřejmé. Pokud si uživatel nebude vědět rady, klikne na otazník, kde nalezne další informace, s jejichž pomocí by měl být schopný dosáhnout požadovaného cíle. V porovnání s existujícími systémy (kapitola 3) řeší popisovaný systém většinu jejich nevýhod. Jde především o decentralizované řízení systému a dlouhý minimální interval měření. Vzhledem k testování pouze na Debianu však systém zaostává oproti existujícím řešením v podpoře dalších operačních systémů.
72
8. Závěr Výsledkem této práce je funkční systém, který umožňuje dlouhodobě sledovat činnost a stav serveru s nainstalovaným operačním systémem Debian GNU/Linux. Systém se skládá ze tří částí. První část (Shel-Node) se instaluje na měřený server a zajišťuje měření a ukládání dat o činnosti serveru. Další komponenta (Shel-Master) se stará o stahování dat z měřených serverů a je umístěna na centrálním serveru. Poslední částí je webové rozhraní, které umožňuje zobrazování naměřených dat ve formě grafů a zároveň slouží k ovládání celého systému. Hlavní cíle práce tedy byly splněny. Pro implementaci Shel-Node a Shel-Master byl použit skriptovací jazyk Perl. Webové rozhraní bylo implementováno v PHP za pomoci Zend Frameworku. Jak již bylo zmíněno v kapitole 7, systém byl otestován na operačním systému Debian GNU/Linux. Vyladění aplikace pro použití na všech typech unix systémů (včetně různých verzí jádra apod.) a především implementace příslušných měřících kódů by byla nad rámec této práce. Další rozvoj této práce by měl být tedy zaměřen na podporu dalších operačních systémů. Jde především o úpravu vlastních měřících kódů, vytvoření instalačních balíčků pro Shel-Node, případně i pro Shel-Master. Systém by mohl také umět monitorovat síťové zařízení jako například routery nebo switche. Bylo by tedy nutné rozšířit jej o podporu protokolu SNMP, pomocí kterého lze tyto zařízení monitorovat. Vzhledem k centralizovanému přístupu na měřené servery se nabízí rozšířit systém o funkce, které umožní zobrazení hardwarové konfigurace jednotlivých serverů. Měřený server by po svém startu, případně v určitém intervalu, poskytl centrálnímu serveru svoji aktuální hardwarovou konfiguraci. Tyto informace by spolu s nasbíranými daty31 mohli sloužit k analýze a výkonové optimalizaci aplikací, které běží na měřených serverech. Možnosti k rozšíření jsou také u webového rozhraní, které v současné době nabízí základní funkce. Bylo by vhodné zapracovat na uživatelském komfortu např.
31
Jednalo by se o porovnání serverů podobné hardwarové konfigurace vzhledem k zatížení a počtu požadavků, které musí server obsloužit.
73
využitím technologie AJAX32. Konkrétně zobrazování grafů, které by šli posouvat podobně jako například podklad v online mapách.
32
AJAX - Asynchronous JavaScript and XML je technologie pro vývoj interaktivních webových aplikací, které mění svůj obsah bez nutnosti opětovného načtení celé stránky.
74
Seznam použité literatury 1.
Dařena, František - Myslíme v jazyku Perl - Praha: Grada, první vydání, 2005. 700 stran, ISBN 80-247-1147-8
2.
Allen, Rob; Lo, Nick; Brown, Steve – Zend Framework in Action, Manning Publications, 2008. 425 stran, ISBN 978-1933988320
3.
Zend Framework dokumentace, dostupné na http://framework.zend.com/manual/en/
4.
JpGraph dokumentace, dostupné na http://www.aditus.nu/jpgraph/
5.
RRDTool, popis a specifikace, dostupné na http://oss.oetiker.ch/rrdtool/
6.
Log4Perl
dokumentace
logovacího
balíku,
dostupné
na
http://search.cpan.org/~mschilli/Log-Log4perl-1.21/lib/Log/Log4perl.pm
75
76
Příloha A.
Instalace měřeného serveru
Instalace Shel-Node komponenty33 na operačním systému Debian GNU/Linux proveďte příkazem: dpkg –i shel-node.deb
Instalační proces provede mimo jiné následující akce: •
Vytvoří uživatele shel.
•
Zajistí přístup pro centrální server (RSA klíč pro SSH).
•
Zajistí spouštění démona po startu operačního systému.
Konfigurační soubor je umístěn v /etc/shel-node.conf a není nutné v něm po instalaci nic měnit. Nastavení jednotlivých pluginů je v /etc/shel-nodeplugins.conf. Po samotné instalaci balíku je nutné přidat server do systému pomocí webového rozhraní. V menu klikněte na položku servers a poté na add new server. Zde vyplňte hostname a IP adresu měřeného serveru (centrální server se bude připojovat na základě IP adresy). Přidaný server se objeví na seznamu serverů, viz Obr. 27.
Obr. 27 - Seznam měřených serverů
Přidanému serveru se automaticky přiřadí výchozí senzory, pluginy a grafy. Nyní můžete upravit nastavení na požadované pluginy, případně senzory. Nakonec stačí aktivovat stahování dat z měřeného serveru kliknutím na odkaz ve sloupci pooling. Po uplynutí intervalu pro stahování dat se začnou vykreslovat grafy.
33
Popis instalace centrálního serveru je na přiloženém CD.
77
78
Příloha B.
Implementace pluginů
Plugin je skupina senzorů (veličin), které se odečítají na měřeném serveru. Základem je měřící kód, který odečítá požadované hodnoty a ukládá je do proměnných. Název proměnné s měřenou hodnotou poté odpovídá senzoru. Co všechno lze zaznamenávat o činnosti serveru omezují dvě kritéria. Tím prvním jsou informace, které dokáže poskytnout operační systém. Druhým je režie při samotném měření, která by neměla přesáhnout jednotky procent zatížení měřeného serveru. Součástí této práce je implementace několika pluginů, které budou měřit nejdůležitější údaje o činnosti serveru. Jedná se např. o využití CPU, obsazení diskových oddílů, nebo datový tok na jednotlivých síťových rozhraních. Jednotlivé pluginy jsou popsány v následujících odstavcích. U každého pluginu je příslušný měřící kód a příklad grafu. 1. Processes count Tento plugin měří aktuální počet spuštěných procesů. Obsahuje dva senzory. Jeden měří celkový počet procesů a druhý počet běžících procesů webového serveru Apache. Implementace tohoto pluginu je velmi triviální. my $p_count = `ps -ef | wc -l`; my $apache = `ps –ef | grep apache2 -c`;
Obr. 28 - Plugin počet běžících procesů
79
2. Forks Plugin Forks měří okamžitý počet systémového volání fork (vytvoření nového procesu). Tento údaj je uložen v souboru /proc/stat. Oproti počtu běžících procesů odhalí tento plugin i cyklické spouštění a ukončování aplikace. my $forks = `cat /proc/stat | grep processes`; ($forks) = $forks =~ m/processes (.*)/;
Obr. 29 - Plugin forks
3. CPU Tento plugin měří jednu z nejdůležitějších informací a tím je využití procesoru. Plugin obsahuje 7 senzorů, které zaznamenávají, jak dlouho34 provádí procesor různé typy operací.
Obr. 30 - Plugin CPU my $cpu_info = `cat /proc/stat | grep ^cpu\\ `; chomp($cpu_info); my ($user, $nice, $system, $idle, $iowait, $irq, $softirq) = $cpu_info =~ m/cpu..(\d+) (\d+) (\d+) (\d+) (\d+) (\d+) (\d+)/; 34
Hodnoty jsou v setinách sekundy pro jednotlivá jádra procesoru.
80
• • • • • • •
User - proces v uživatelském módu Nice - proces spuštění s jinou prioritou Systém - proces v kernel módu Idle - neprobíhá žádná činnost Iowait - čekání na vstupně/výstupní zařízení Irq - obsluhující přerušení Softirq - obsluhující soft přerušení35
4. Load Plugin load měří okamžitý počet procesů, které čekají ve frontě na obsloužení. V souboru /proc/loadavg je uveden průměrný počet procesů za poslední minutu, 5 minut a 15 minut. my @_load = split( / /, `cat /proc/loadavg | awk '{print \$1" "\$2" "\$3}'` );
Obr. 31 - Plugin Load
5. Memory Plugin Memory slouží k měření obsazení operační paměti a odkládacího souboru. Tyto informace jsou uloženy v souboru /proc/meminfo. my %mems = (); open (IN, "/proc/meminfo"); while (
) { if (/^(\w+):\s*(\d+)\s+kb/i) { $mems{"$1"} = $2 * 1024; } 35
Mechanizmus softirq rozděluje obsluhu přerušení na část, která je potřeba vykonat hned (přijetí přerušení) a na část, kterou lze vykonat později.
81
} close (IN); my my my my my my
$_memTotal $_memFree $_buffers $_cached $_swapUsed $_shared
= = = = = =
$mems{"MemTotal"}; $mems{"MemFree"}; $mems{"Buffers"}; $mems{"Cached"}; $mems{"SwapTotal"} - $mems{"SwapFree"}; $_memTotal - $_memFree - $_buffers - $_cached;
Obr. 32 - Plugin obsazení operační paměti
6. Partitions Tento plugin měří velikost a obsazení logických oddílů disků (Linux MD RAID). Jedná se o tzv. multiple plugin, kde není předem znám počet senzorů (diskových oddílů). Po přiřazení pluginu ve webovém rozhraní je odeslán požadavek na spuštění multiple kódu na měření server. Multiple kód vypadá následovně: df | grep ^/dev/md |awk '{ print $1 }'|sed s/\\/dev\\///g;
Samotný kód pro měření celkového a volného místa vypadá takto: my @part = split(/\n/, `df | grep ^/dev/m`); my @_md_size = (); my @_md_used = (); foreach my $p (@part) { my ($i) = $p =~ m/^\/dev\/md(\d+)/; ($_md_size[$i], $_md_used[$i]) = $p =~ m/\/dev\/md\d\s+(\d+)\s+(\d+)/; $_md_size[$i] *= 1024; $_md_used[$i] *= 1024; }
82
Obr. 33 - Plugin obsazení disku
7. Traffic eth Tento plugin slouží k měření okamžitého datového toku na jednotlivých ethernetových rozhraních. Opět není předem znám jejich počet, a proto je nutné použít multiple kód: cat /proc/net/dev| grep -E 'eth'
|awk '{print $1}'| sed s/:[0-9]*//g;
Měřící kód vypadá následovně: my @if = split(/\n/, `cat /proc/net/dev | grep eth`); my @_eth_rec = (); my @_eth_trans = (); foreach my $p (@if) { my ($i) = $p =~ m/eth(\d+)/; ($_eth_rec[$i], $_eth_trans[$i]) = $p =~ m/eth\d+:\s*(\d+)\s+\d+\s+\d+\s+\d+\s+\d+\s+\d+\s+\d+\s+\d+\s+(\d+)/; $_eth_rec[$i] *= 8; $_eth_trans[$i] *= 8; }
Obr. 34 - Plugin datového toku na síťových rozhraních
83
8. Netstat Tento plugin sleduje stav a počet jednotlivých TCP36 spojení. Tyto informace jsou uloženy v souboru /proc/net/tcp. Měřící kód není vzhledem ke své délce uveden.
Obr. 35 – TCP spojení
9.
Apache status Plugin poskytuje informace o stavu webového serveru Apache. Jde především o
počet instancí, které se věnují jednotlivým úlohám (odesílání odpovědi, logování, vyčkávání na klienta apod.). Aby mohl Apache tyto informace poskytovat, je nutné zapnout tzv. Extended status pomocí následují volby: ExtendedStatus On SetHandler server-status Allow from 127.0.0.1
36
TCP je základní internetový protokol, který pracuje na transportní vrstvě.
84
Měřící kód není vzhledem ke své délce uveden.
Obr. 36 - Plugin Apache
Implementovány byly ještě další pluginy. Zde je uveden pouze jejich seznam s krátkým popisem. • • • • •
Traffic lo – měří aktuální datový tok skrze rozhraní loopback37. Uptime – zjišťuje dobu běhu systému. Users – měří aktuální počet přihlášených uživatelů k systému (jak přihlášených přímo přes konzoli, tak i vzdáleně) Queries PG – měří okamžitý počet dotazů (insert, update, delete) na PostreSQL databázi. Queries MySql – měří počet dotazů na MySQL databázi (insert, update, select, replace, delete, cache_hits)
Obr. 37 - Plugin dotazy na MySQL databázi 37
Loopback odkazuje na vyhrazenou IP adresu 127.0.0.1 a umožňuje aplikacím využívajícím protokol IP komunikovat sama se sebou.
85
86
Příloha C.
Databázové schéma
Na následujícím obrázku je zobrazen ER model databáze. Pro přehlednost p jsou u každé tabulky uvedeny pouze ty nejdůležitější nejd atributy.
Obr. 38 – ER model databáze
Součástí ástí modelu jsou také tabulky, tabul které slouží k ukládání výchozích pluginů, plugin senzorů a grafů.. Dále tabulky, které uchovávají informace, na základě základ kterých se generují RRD soubory na centrálním serveru. Tyto tabulky nejsou pro přehlednost p na Obr. 38 uvedeny.
87
88
Příloha D.
Obsah přiloženého CD
•
/src - zdrojové kódy Shel-Master a Shel-Node
•
/pkg – instalační balík Shel-Node pro debian
•
/txt - text práce
•
abstract_cz.txt
•
abstract_en.txt
89
