Sem vložte zadání Vaší práce

Sem vložte zadání Vaší práce.

České vysoké učení technické v Praze Fakulta informačních technologií Katedra počítačových systémů

Bakalářská práce

Analýza, návrh a řešení síťové infrastruktury Jihočeské vědecké knihovny v Českých Budějovicích Ondřej Hájek

Vedoucí práce: Ing. Jiří Nechvátal 11. května 2013

Poděkování Chtěl by poděkovat svému vedoucímu práce Ing. Jiřímu Nechvátalovi za podnětné připomínky a pomoc při tvorbě této práci. Dále také děkuji své rodině a přátelům nejen za podporu při psaní této práce, ale i za podporu po celou dobu mého studia.

Prohlášení Prohlašuji, že jsem předloženou práci vypracoval samostatně a že jsem uvedl veškeré použité informační zdroje v souladu s Metodickým pokynem o etické přípravě vysokoškolských závěrečných prací. Beru na vědomí, že se na moji práci vztahují práva a povinnosti vyplývající ze zákona č. 121/2000 Sb., autorského zákona, ve znění pozdějších předpisů. V souladu s ust. § 46 odst. 6 tohoto zákona tímto uděluji nevýhradní oprávnění (licenci) k užití této mojí práce, a to včetně všech počítačových programů, jež jsou její součástí či přílohou a veškeré jejich dokumentace (dále souhrnně jen „Dílo“), a to všem osobám, které si přejí Dílo užít. Tyto osoby jsou oprávněny Dílo užít jakýmkoli způsobem, který nesnižuje hodnotu Díla a za jakýmkoli účelem (včetně užití k výdělečným účelům). Toto oprávnění je časově, teritoriálně i množstevně neomezené. Každá osoba, která využije výše uvedenou licenci, se však zavazuje udělit ke každému dílu, které vznikne (byť jen zčásti) na základě Díla, úpravou Díla, spojením Díla s jiným dílem, zařazením Díla do díla souborného či zpracováním Díla (včetně překladu), licenci alespoň ve výše uvedeném rozsahu a zároveň zpřístupnit zdrojový kód takového díla alespoň srovnatelným způsobem a ve srovnatelném rozsahu, jako je zpřístupněn zdrojový kód Díla.

V Praze dne 11. května 2013

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

České vysoké učení technické v Praze Fakulta informačních technologií c 2013 Ondřej Hájek. Všechna práva vyhrazena.

Tato práce vznikla jako školní dílo na Českém vysokém učení technickém v Praze, Fakultě informačních technologií. Práce je chráněna právními předpisy a mezinárodními úmluvami o právu autorském a právech souvisejících s právem autorským. K jejímu užití, s výjimkou bezúplatných zákonných licencí, je nezbytný souhlas autora.

Odkaz na tuto práci Hájek, Ondřej. Analýza, návrh a řešení síťové infrastruktury Jihočeské vědecké knihovny v Českých Budějovicích. Bakalářská práce. Praha: České vysoké učení technické v Praze, Fakulta informačních technologií, 2013.

Abstract This thesis deals with analysis, design, and solutions for network infrastructure in the Research Library of South Bohemia in Ceske Budejovice, including a monitoring solution proposal with infrastructure monitoring software Nagios. The first part contains an analysis of existing network elements and their services. The second part describes the design of a new network infrastructure with justification of choices. Last part is dedicated to Nagios and simulation of integration into Bohemian Research Library’s network using virtualization tools. Keywords JVK, Nagios, NRPE, HP, design, infrastructure, library, stack, switch, chassis.

Abstrakt Tato práce se zabývá analýzou, návrhem a řešením síťové infrastruktury pro potřeby Jihočeské vědecké knihovny v Českých Budějovicích včetně návrhu ix

řešení dohledu s využitím systému Nagios. První část obsahuje analýzu stávajících síťových prvků a jejich služeb. Druhá část popisuje návrh nové síťové infrastruktury se zdůvodněním výběru. Poslední část seznamuje se systémem Nagios a simulací jeho integrace do sítě Jihočeské vědecké knihovny v Českých Budějovicích pomocí virtualizačních nástrojů. Klíčová slova JVK, Nagios, NRPE, HP, návrh, infrastruktura, knihovna, stoh, přepínač, šasi.

x

Obsah Úvod

1

1 Analýza síťové infrastruktury 1.1 Popis knihovny . . . . . . . 1.2 Motivace . . . . . . . . . . . 1.3 Simulační prostředí . . . . . 1.4 Topologie sítě . . . . . . . . 1.5 Hardware . . . . . . . . . . 1.6 Operační systémy . . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

3 3 3 4 4 6 15

2 Návrh nové infrastruktury 2.1 Popis stavu . . . . . . . . . . . . . . . . 2.2 Požadavky na novou infrastrukturu . . . 2.3 Obecné řešení . . . . . . . . . . . . . . . 2.4 Budova Lidická . . . . . . . . . . . . . . 2.5 Budova Na Sadech - Sklad . . . . . . . . 2.6 Budova Na Sadech - Vila . . . . . . . . . 2.7 Kompromisy návrhu . . . . . . . . . . . 2.8 Srovnání s návrhem od společnosti Power

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . System s.r.o.

. . . . . . . .

. . . . . . . .

. . . . . . . .

19 19 20 21 23 27 29 29 31

3 Implementace 3.1 Počáteční konfigurace . . . 3.2 Nagios . . . . . . . . . . . 3.3 Testování . . . . . . . . . 3.4 Další optimalizace síťového

. . . .

. . . .

. . . .

. . . .

35 35 36 41 44

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . . . . . . . . . . . provozu

Závěr

. . . . . .

. . . .

. . . . . .

. . . .

. . . . . .

. . . .

. . . . . .

. . . . . .

. . . .

. . . . . .

. . . .

. . . . . .

. . . .

. . . . . .

. . . .

. . . . . .

. . . .

. . . . . .

. . . .

. . . .

47 xi

Literatura

49

A Seznam použitých zkratek

53

B Seznam tabulek

57

C Obsah přiloženého CD

59

xii

Seznam obrázků 1.1 1.2 1.3 1.4 1.5 1.6

Topologie budovy Lidická . . . . . . . . . . Topologie serverovny v budově Lidická . . . Topologie budovy Na Sadech . . . . . . . . iSCSI SAN topologie . . . . . . . . . . . . . Zapouzdření iSCSI v ethernetových rámcích Struktura VMware ESX . . . . . . . . . . .

. . . . . .

7 8 9 12 13 16

2.1 2.2

Návrh rozmístění páteřních prvků a jejich propojení . . . . . . . Návrh switchů a jejich zapojení s virtuálními servery . . . . . .

23 30

3.1 3.2

Grafické znázornění serverů . . . . . . . . . . . . . . . . . . . . Tabulka dns a mail serveru a jejich služeb . . . . . . . . . . . .

41 43

xiii

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

Seznam tabulek B.1 Modul scheduledDowntime.sh . . . . . . . . . . . . . . . . . . .

xv

57

Úvod Tématem této práce je obměna síťové infrastruktury v Jihočeské vědecké knihovně v Českých Budějovicích a implementace dohledového systému Nagios. V posledních letech se knihovna začala potýkat s problémem, spojeným se stářím použitých síťových prvků. Tyto prvky postupně přestávaly plnit svou funkci a bylo nutné je měnit. Výměna všech těchto prvků se jevila jako nevyhnutelná, a tak se knihovna rozhodla pro jejich kompletní jednorázovou obměnu. Protože se však jedná o instituci zřizovanou Jihočeským krajem, jejíž finanční možnosti jsou omezené, pokusím se v této práci sestavit konfiguraci přesně podle potřebných parametrů s důrazem na co nejnižší cenu, která zároveň nebude významně ovlivňovat výkon. Před samotným návrhem nejdříve zanalyzuji situaci v této knihovně, popíši, které síťové prvky jsou momentálně používány a vyhodnotím, zda by nebylo možné některé z nich popřípadě zachovat. Součástí bude i analýza současného softwarového vybavení, která bude sloužit jako podklad pro konfiguraci dohledového systému. V další části se budu zabývat samotným návrhem nové síťové infrastruktury, ve kterém se při výběru prvků zaměřím kromě výkonu a ceny také na jejich sjednocení, ať už z důvodu jednodušší administrace nebo nižších výdajů za náhradní díly. Novou infrastrukturou bude třeba i vyřešit problém se zálohami, které jsou nyní umístěny v blízkosti hlavního serveru. Zároveň v této části srovnám a vyhodnotím vlastní návrh s řešením, které pro JVK navrhla specializovaná firma. V poslední části se zaměřím na dohledový systém Nagios, se kterým chce JVK sledovat dostupnost svých serverů a služeb. Součástí tohoto systému bude i implementace vlastního modulu napsaného ve skriptovacím jazyku Bash. Před nasazením tohoto systému do produkčního prostředí provedu simulaci ve virtuálním prostředí, abych ověřil správnost návrhu a neohrozil 1

Úvod tak reálný provoz v případě možného problému.

2

Kapitola

Analýza síťové infrastruktury 1.1

Popis knihovny

Jihočeská vědecká knihovna v Českých Budějovicích provozuje celkem 4 pobočky (Čtyři Dvory, Rožnov, Suché Vrbné, Vltava), klášter s historickým fondem (Zlatá Koruna) a 2 ústřední budovy (Lidická 1, Na Sadech 27), ve kterých jsou mimo jiné umístěny hlavní sklady a datové centrum. Celkový fond čítá k dnešnímu datu přes 1 000 000 svazků, z toho 525 554 titulů je zpřístupněno v elektronickém katalogu IPAC1 . Pro registrované čtenáře jsou na všech pobočkách zdarma přístupné počítače. Na všech počítačích je přístup do elektronického katalogu IPAC, do Internetu a do vnitřní sítě se systémem Ultra*Net, ve kterém je databáze s multimediálními naučnými CD-ROMy. Ústřední budovy a pobočka Čtyři Dvory mají navíc zřízen pro čtenáře přístup k Internetu prostřednictvím WiFi připojení.[15] Všechna data, se kterými systémy pracují, jsou uložena v serverové místnosti v budově Lidická 1 a jejich záloha se provádí do druhé serverovny, která je umístěna ve stejné budově. V současnosti se v JVK nachází 212 osobních počítačů (z toho 94 pro čtenáře), 9 fyzických serverů, 8 virtuálních serverů, 37 tiskáren (z toho 16 síťových) a 43 dalších síťových zařízení.

1.2

Motivace

Přestože existují již hotová řešení různých topologií sítě, požadavky Jihočeské vědecké knihovny jsou tak specifické, že hlavně s ohledem na cenu 1

IPAC - Internet Public Access Catalog

3

1

1. Analýza síťové infrastruktury nelze tato řešení použít. Je tedy nutné vytvořit řešení přesně pro potřeby JVK s důrazem na co nejnižší cenu.

1.3

Simulační prostředí

Součástí této práce je i implementace dohledového softwaru Nagios[19]. Abych tento software neimplementoval přímo do produkčního prostředí bez předchozího testování, provedu tuto část v simulačním prostředí. Protože je v JVK použit virtualizační systém VMware vSphere (více v kapitole 1.6.2), zdálo by se použití VMware Workstation jako virtualizačního nástroje ideální. Workstation i vSphere jsou produkty společnosti VMware, přesto jsou ale tyto nástroje rozdílné. Hlavním rozdílem je, že dle rozdělení podle [7] vSphere obsahuje nativní hypervizor, tzv. „Type 1“, zatímco Workstation obsahuje hostovaný hypervizor, tzv. „Type 2“. Z důvodu této rozdílnosti není nutné zůstávat u shareware softwaru VMware Workstation a raději zde zvolím Oracle VM VirtulBox od firmy Oracle Corporation dostupný pod licencí GNU General Public License, který také obsahuje hostovaný supervizor. [24][21] Oracle VM VirtulBox bude nakonfigurovaný s podporou VT-x/AMD-V technologie, tedy s hardwarovou akcelerací virtualizace s přímým přístupem k hardwaru. Každý hostovaný systém bude mít k dispozici 1 jádro procesoru s podporou PAE/NX2 , 1024 MB operační paměti, 12 MB video paměti bez 2D/3D akcelerace, připojení do vnitřní sítě a Internetu pomocí síťového mostu a 8 GB dynamicky alokovaného úložiště.

1.4

Topologie sítě

Stěžejní část sítě JVK je umístěna v budově Lidická 1. Přístup k Internetu je zajištěn zájmovým sdružením právnických osob CESNET3 pomocí optického jednovidového vlákna o parametrech 9/125 µm, které je následně přes převodník Signamax WDM a 10/100 To 100FX převedeno na metalický kabel a ten je připojen do switche 3com SuperStack II Switch 3300. Následně na tento switch je napojen firewall, který je řešen jako klasické PC se softwarem GB-OS. Firewall obsahuje další 2 síťová rozhraní. 2

Physical Address Extension - pomocí této technologie může i 32bitový x86 procesor přistupovat k více než 4 GB paměti RAM a to přidáním dalších 4 bitů k adrese. Se 36 bity je poté možné adresovat až 64GB paměti. Také některé operační systémy přímo vyžadují tuto technologii pro spuštění ve virtuálním stroji. 3 Sdružení založené v roce 1996 provozující páteřní akademickou počítačovou síť České republiky. Více na http://www.cesnet.cz

4

1.4. Topologie sítě Jedno z těchto rozhraní je připojeno na páteřní switch, druhé rozhraní je napojeno na switch TP-LINK TL-SF101, který obsluhuje WiFi přístupové body sestávajících z prvků 3com Wireless 8760 Dual-Radio 11a/b/g PoE. Připojení poboček je řešeno přes síť inet4 s.r.o, která svou sítí připojuje pobočky knihovny, a v budově Lidická 1 vyúsťuje v optické jednovidové vlákno o parametrech 9/125 µm. Toto vlákno v sobě obsahuje dvě VLANy, z čehož jedna VLANa obsahuje provoz z WiFi sítě a druhá ostatní provoz poboček. Následně se optické vlákno převede pomocí převodníku Repotec RP-1002MG na ethernetový kabel zapojený do switche MikroTik RouterBoard 1000, který se stará o rozeslání paketů podle VLAN, kde VLANu s WiFi provozem odešle na switch TP-LINK TL-SF1016 a ostatní provoz odešle do páteřního switche. Páteřní switch zde tvoří stack 8 switchů a to konkrétně tři switche Alcatel OmniStack 6124, Alcatel OmniStack 6148, Alcatel OmniStack 6024, Alcatel OmniSwitch 6800-U24, Alcatel OmniSwitch 6624 a TP-LINK TLSF1048. Přes tyto switche proudí valná většina síťového provozu. Na páteřní switch jsou napojeny jednak všechny počítače v budově Lidická 1, ale i kamerový systém, telefonní ústředna, UPS a backup server, na který se provádějí pravidelně zálohy dat ze všech serverů. Součástí této páteře je i switch HP A5120-24G El JEO68A, který komunikuje přes vícevidové optické vlákno o parametrech 50/125 µm s identickým switchem ve druhé serverovně. Na každý z těchto switchů je napojen jeden datový server HP LeftHand P4300 G2. Data jsou uložena na serveru v místnosti s páteřním switchem a replikují se synchronně na server v druhé serverové místnosti. Na těchto serverech jsou uloženy databáze a ostatní nestatická data (jako například dokumenty uživatelů, multimediální soubory, naučné databáze a zálohy). Data mezi těmito servery proudí pomocí sítě SAN. Na switch HP A5120-24G El JEO68A ve druhé serverové místnosti je napojen i Ultra*Net server, UPS pro tuto serverovnu a celé datové úložiště se všemi virtuálními servery. Jako virtuální technologie zde funguje virtualizační software VMWare, který funguje celkem na třech fyzických serverech a to na dvou HP ProLiant DL380 G7 a HP ProLiant DL380 G5. Vyskytuje se zde i server HP ProLiant DL380, který slouží jako datové úložiště o kapacitě 1.4 TB a na kterém se nacházejí digitalizovaná periodika a monografie ve sbírkách JVK. Z páteřního switche také vede připojení k budově Na Sadech 27. Toto spojení je realizováno pomocí optického jednovidového vlákna o parametrech 9/125 µm, které je v obou budovách opatřen převodníkem Allied Telesis AT-MC1008/SP a v budově Na Sadech 27 je zakončeno v páteřním switchy, který obsahuje zařízení Alcatel OmniStack 6124 a Alcatel OmniSwitch 6624. Na tento páteřní switch je napojen také WiFi AP s přístupovými 5

1. Analýza síťové infrastruktury body 3com Wireless 8760 Dual-Radio 11a/b/g PoE, dále také síťový videorekordér s bezpečnostními kamerami, všechny osobní počítače v budově, telefonní ústředna a nakonec switch 3com SuperStack II Switch 3300, který se stará o připojení počítačů v budově skladu. Více na obrázcích 1.1, 1.2 a 1.3.

1.5 1.5.1

Hardware Připojení k Internetu

Jak již bylo zmíněno výše, připojení k Internetu je realizováno pomocí sítě CESNET. Síť CESNET je v JVK využívána pro obecnou konektivitu do Internetu. Technicky je síť spojená pomocí singlemode (jednovidového) optického vlákna o parametrech 9/125 µm, a to ze vzdálenosti přibližně 3 km. Rychlost je momentálně stanovena na 100 Mbps, ovšem v blízké době se počítá s navýšením rychlosti na 1000 Mbps. Optické vlákno se přes převodník Signamax WDM a 10/100 To 100FX převádí na metalický kabel, a dále pokračuje do switche 3com SuperStack II Switch 3300. Tento switch je použit na připojování zařízení k externí adrese sítě CESNETu bez zásahu firewallu. Toto řešení je výhodné například při identifikaci chyby sítě ve chvíli, kdy nevíme, zda chyba vznikla ve firewallu nebo u poskytovatele připojení.

1.5.2

Připojení poboček

Společnost inet4 s.r.o. pronajímá JVK vlastní datový okruh spojující pobočky Čtyři Dvory, Rožnov, Suché Vrbné a Vltava s budovou Lidická 1. Připojení na straně poboček je realizováno pomocí mikrovlnných pojítek MW link ORCAVE 2222. Mikrovlnné pojítko se skládá ze 3 částí. Mikrovlnná jednotka zajišťuje vysílání a příjem vysokofrekvenčního signálu. Další částí je komunikační jednotka sloužící k převodu dat na signál, který je koaxiálním kabelem přenášen do mikrovlnné jednotky a obráceně, a poslední součástí je parabolická anténa. Výhodou mikrovlnného spojení je vysoká odolnost vůči rušivým vlivům, čehož je dosaženo vysokofrekvenční povahou přenosu, nevýhodou je naopak nutnost přímé viditelnosti obou zařízení. Pokud některá pobočka chce komunikovat přes Internet, tato komunikace se přes síť inet4 s.r.o. připojí do hlavní budovy Lidická 1, kde prochází přes centrální switch a firewall až do externí sítě CESNET. Technické řešení v budově Lidická 1 je stejné jako u sítě CESNET, tedy jednovidové optické 6

1.5. Hardware

Obrázek 1.1: Topologie budovy Lidická

7

1. Analýza síťové infrastruktury

Obrázek 1.2: Topologie serverovny v budově Lidická

vlákno 9/125 µm. Jako převodník z optického vlákna na metalický kabel je zde použit Repotec RP-1002MG, který dále vede do routeru MikroTik RouterBoard 1000. Tento router odděluje VLAN na část, která přišla z WiFi sítě, a na ostatní komunikaci a poté se pošle na příslušný switch.

1.5.3

Firewall

Firewall slouží ke kontrole příchozí a odchozí komunikace do a z Internetu a podle navolených pravidel filtruje komunikaci na bázi stavového paketového filtru. Paketový filtr funguje na 3. vrstvě OSI4 modelu a filtruje komunikaci na základě atributů paketu, jako je například IP adresa, port, TTL, cílová služba nebo protokol. Stavový paketový filtr si ještě navíc drží informace o navázaných spojeních. Pokud příchozí paket vyhovuje záznamu v tabulce navázaných spojení, není tento paket více analyzován a projde firewallem dále. V opačném případě je tento paket považován za nové spojení. Součástí firewallu je i služba NAT, která se stará o překlad externí adresy na interní rozsah sítě. Při inicializaci spojení z vnitřní sítě NAT pozmění v paketu hodnoty odchozí IP adresy z interní IP na externí IP, pozmění odchozí port a vypočítá nový kontrolní součet paketu. Při odeslání paketu si 4

Open Systems Interconnection - model charakterizující a standardizující funkce komunikačního systému v abstraktních vrstvách, kde podobné komunikační funkce jsou seskupiny do logických vrstev. Každá vrsta je poskytovatel služeb vyšší vrstvy a zároveň uživatel služeb nižší vrstvy

8

1.5. Hardware

Obrázek 1.3: Topologie budovy Na Sadech

9

1. Analýza síťové infrastruktury uloží do tabulky port a interní adresu počítače, která inicializovala spojení. Poté po odpovědi NAT podle portu pozná, komu paket patří a odešle ho příslušnému stroji. Implementačně je firewall řešen jako samostatné PC Office 3000 od firmy Autocont, na kterém běží aplikace GB-OS 5.3.4. Unrestricted od firmy Global Technologies Associates, Inc.5 , která zastává funkci firewallu. Firewall obsahuje celkem 3 síťová rozhraní. První rozhraní slouží pro komunikaci s Internetem a je napojeno do switche 3com SuperStack II Switch 3300. Druhé rozhraní obstarává komunikaci, která přišla přes jakékoliv WiFi zařízení, ať už z hlavní budovy, nebo i z poboček. Na tomto rozhraní jsou z bezpečnostních důvodů zakázány na firewallu všechny služby a porty kromě služeb HTTP, HTTPS, DNS dotazů, DHCP, FTP, POP3, IMAP, IMAPS, ICQ a porty 50, 323 a 1080. Třetí rozhraní slouží pro všechnu ostatní komunikaci a je připojeno přímo do páteřního switche. Zde je jako ochrana proti rozesílání nevyžádané pošty zakázán port 25 (port pro komunikaci SMTP serveru) a také porty 137 a 139, na kterých komunikují služby NetBIOS. Jelikož je JVK veřejnou knihovnou, má ze zákona povinnost umožnit přístup k informacím na Internetu. V JVK se tedy nachází několik počítačů, ke kterým má přístup široká veřejnost. Kvůli nemožnosti identifikaci uživatele jsou tyto počítače z bezpečnostních důvodů napojeny na WiFi rozhraní. [22] [26]

1.5.4

WiFi

WiFi připojení slouží pro přístup k Internetu čtenářům JVK, kteří disponují vlastním notebookem s WiFi modulem nebo jiným přístrojem podporujícím bezdrátové připojení. Jako přístupové body slouží po celé knihovně několik AP 3Com Wireless 8760 Dual-Radio 11a/b/g PoE, které jsou všechny napojeny pomocí ethernetového kabelu na switch TP-LINK TL-SF1016. Tyto přístupové body podporují standardy IEEE 801.11a, 801.11b a 801.11g. IEEE 801.11a vysílá v licencovaném pásmu 5GHz a podporuje rychlost až 54 Mbps, zatímco podle standardu IEEE 801.11b a IEEE 801.11g se vysílá v nelicencovaném 2.4 GHz pásmu s rychlostí až 11Mbps, respektive 54Mbps. Pro rovnoměrné pokrytí celé budovy JVK signálem je použito více WiFi prvků. Přístupové body si dokáží mezi sebou připojeného klienta přepínat podle toho, které zařízení má právě v daném místě silnější signál, čímž umožňují stálé připojení k síti i při pohybu po budově. Z těchto důvodů 5

10

více na http://www.gta.com/

1.5. Hardware mají některé prvky v JVK omezený výkon, čímž se nastavuje priorita zařízení v daném místě, a zároveň se tímto způsobem dá dělit provoz mezi více prvky a nezatěžovat pouze jeden, který by byl umístěn na takovém místě, kde by signálem pokrýval většinu budovy. Další funkcí přístupových bodů je funkce Dual-Radio, která dokáže vysílat dvě sítě s různými SSID a typem zabezpečení, čehož je v knihovně také využito. První vysílaná síť s SSID jvk je šifrovaná pomocí technologie WPA2 s šifrou AES podle standardu IEEE 802.11i. Přístup do této sítě má každý registrovaný čtenář, který si zažádal o heslo. Správnost přihlašovacích údajů se následně ověřuje proti RADIUS serveru. Z důvodu kompatibility se staršími zařízeními je druhá síť s SSID jvkfree bez šifrování a tudíž dostupná komukoliv v dosahu sítě. Kromě pravidel na firewallu a některých explicitně zakázaných IP adres, jsou zde také blokovány stránky s erotickým obsahem. [25] [1]

11

1. Analýza síťové infrastruktury

1.5.5

Storage Area Network

Obrázek 1.4: Topologie sítě iSCSI SAN s hostiteli ESX6 používající VMFS7 úložiště

Hlavní úloha sítě SAN je přenos dat mezi počítačovými systémy a datovými úložišti, jako jsou disková pole, páskové mechaniky nebo další zálohovací zařízení. SAN představuje centralizovaný virtualizovaný systém pro správu úložišť a jako takový také poskytuje výhody virtualizace – tedy například jako efektivnější využití prostředků a jednodušší údržbu. Kromě těchto výhod dosahuje také velké propustnosti dat. V JVK je SAN použita jako síť mezi dvěma datovými servery HP LeftHand P4300 G2 umístěných v oddělených místnostech, na kterých je uložena většina dat. Datové servery fungují jako aktivní-aktivní systém úložišť, což znamená, že tento systém umožňuje simultánní přístup ke všem logickým jednotkám skrze všechny porty, které jsou dostupné, a to bez významného výkonového poklesu. Všechny cesty jsou po celou dobu aktivní, pokud některá cesta neselže. 6

VMware ESX – Jádro systému VMware vSphere, který slouží jako virtualizační serverový systém od firmy VMWare, Inc. 7 VMFS – Virtual Machine File System, clusterový filesystém umožňující pracovat s daty na svazku, který je připojen k více než jednomu operačnímu systému

12

1.5. Hardware Jelikož se jedná o data, která jsou kritická pro provoz JVK, je zde několik stupňů ochrany, které minimalizují případnou nedostupnost těchto dat. Konzistentní a synchronní diskové pole Na oba servery jsou ukládána identická data a servery se zároveň mezi sebou udržují v konzistentním stavu pří synchronním přenosu dat, tzn. pokud selže zápis na jeden server, data se nezapíší ani na druhý. RAID 5 Pro bezpečnost již uložených dat je zde použita technologie RAID 5, která počítá paritu dat pomoci funkce XOR. Zápis paritního bloku probíhá v rámci pole cyklicky, tedy na paritu není vyhrazen pouze jeden paritní disk, ale na každém disku je část paritního záznamu. Multipathing a Path Failover v případě poruchy některého síťového zařízení mezi těmito servery jsou všechny prvky redundantní a je využita technologie Multipathing. Multipathing dovoluje existenci více než jedné fyzické cestu z ESX hostitele k logické jednotce diskového pole. Jedna cesta z hostitele k datovému úložišti sestává z iSCSI řadiče, portů přepínače, propojovacích kabelů a portů řadiče datového disku. Pokud jakýkoliv komponent v této cestě selže, hostitel vybere jinou vhodnou cestu. Tomuto procesu detekování vadné cesty a přepnutí na jinou se říká path failover.

Obrázek 1.5: Zapouzdření iSCSI v ethernetových rámcích

Samotná síť SAN využívá protokol iSCSI, jehož hlavní výhoda oproti protokolu Fibre Channel je možnost použití stávající ethernetové infrastruktury bez nutnosti pořizování specializovaných prvků využitelných pouze protokolem Fibre Channel. Když hostitel vyšle požadavek na komunikaci se vzdáleným datovým úložištěm, operační systém vytvoří příslušné SCSI příkazy společně s požadavkem, které projdou zapouzdřením. Před vlastním odesláním se k tomuto požadavku přidává ještě vlastni TCP/IP hlavička. 13

1. Analýza síťové infrastruktury Takovýto paket se odešle po ethernetové síti ke svému cíli, kde proběhne zpětné rozložení a dekódování paketu. SCSI příkazy se odešlou na SCSI controller, který je předá SCSI datovému úložišti. [18] [23] [12]

1.5.6

Síť

Celá vnitřní síť knihovny je rozdělena na celkem 2 virtuální sítě pomocí technologie VLAN. VLAN sítě rozdělují jednotlivé fyzické segmenty, které by normálně tvořily jednu velkou broadcastovou doménu, na několik logicky oddělených (ale menších) broadcastových domén. Toto rozdělení snižuje provoz na síti a má tedy pozitivní vliv na celkový výkon. Síť 172.30.148.0/24 slouží pro veškerý provoz přes WiFi připojení, nepočítá se s tím, že by bylo naráz připojeno více jak 250 klientů. Součástí rozsahu je i několik statických IP adres přiřazených přístupovým bodům. Síť 172.30.0.0/16 slouží jako síť pro všechna ostatní spojení – patří sem jak servery, tak i klientské počítače. Tato síť se dále logicky dělí na 4 podsítě, které ovšem nejsou oddělené pomocí VLAN: • 172.30.144.0/24 obsahuje všechny virtuální servery a obecně novější servery pořízené v posledních letech; postupně se přidávají servery z rozsahu 182.30.145.0/24 • 172.30.145.0/24 obsahuje backup server, Ultra*Net server, telefonní ústřednu a další starší servery • 172.30.146.0/24 obsahuje všechny pracovní stanice • 172.30.147.0/24 obsahuje stanice připojené do elektronického katalogu IPAC

1.5.7

Kamerový systém

Všechny kamery, které snímají venkovní i vnitřní prostory knihovny, jsou kromě síťových videorekordérů napojeny také na video server. Video server digitalizuje analogový obrazový signál a posílá zdigitalizované snímky přes IP síť. Tímto způsobem je možné sledovat výsledný záznam i online obraz například přes webový prohlížeč. V JVK je jako video server použit Axis 241Q, který dokáže najednou zpracovávat 4 nezávislé video kanály, a to rychlostí 17 snímků za vteřinu ve standardu PAL při MPEG-4 kompresi.[4] Z důvodu bezpečnosti nebudou další detaily ohledně kamerového systému zveřejněny. 14

1.6. Operační systémy

1.5.8

UPS

Jako nepřerušitelný zdroj energie slouží v JVK prvky řady APC SmartUPS 2200VA. Tato zařízení při aktuální zátěži dokáží v případě výpadku dodávky elektrické energie napájet servery po dobu přibližně 25 minut. Tato doba je dostatečná na uložení všech neuložených dat, které se právě vyskytují v síti. V hlavní serverovně se navíc nacházejí dva UPS prvky (APC Smart-UPS 2200VA a APC Smart-UPS 2200VA XL), které jsou napojeny na přepínač APC SU044-1 Redundant Switch. Tento přepínač je napojen na všechna zařízení, která nemají redundantní zdroj. Pokud se primární napájecí zdroj stane nedostupným, přepínač přejde na napájení ze sekundárního zdroje, aniž by došlo k přerušení napájení připojených zařízení. Pro lepší správu obsahuje přepínač také síťový modul pro vzdálenou správu. [3] [2]

1.5.9

Budova Na Sadech

V budově Na Sadech se, kromě datového prostoru pracovních stanic, nenachází žádné servery ani disková pole. V této budově jsou pouze switche, kamerový systém a telefonní ústředna. Veškerá komunikace probíhá pomocí jednovidového vlákna o parametrech 9/125 µm přes budovu Lidická, kde jsou také uložena veškerá data, se kterými se v celé síti pracuje.

1.6 1.6.1

Operační systémy Nevirtualizované operační systémy

I když je v JVK největší část serverů virtualizována, jsou zde umístěny 2 servery s nevirtualizovaným operačním systémem. Prvním tímto serverem je zálohovací server běžící na systému Debian GNU/Linux 6.0. V režimu 24/7 tento server zálohuje veškerá data, kterými knihovna disponuje. Druhý nevirtualizovaný systém je server Ultra*Net. Tento server běží na systému Microsoft Windows 2000 Server. Z důvodu závislosti licence systému Ultra*Net na hardwarovém klíči není možné tento server převést na virtuální server.

1.6.2

Virtualizované operační systémy

Virtualizování serverů je technika, při které lze provozovat více virtuálních systémů na jednom fyzickém serveru. Tyto systémy jsou provozovány v na15

1. Analýza síťové infrastruktury vzájem nezávislých prostředích, které využívají virtuální prostředky. Hlavní výhody používání virtuálních serverů jsou: • efektivnější využití systémových prostředků • nižší náklady na provoz a hardware serverů • možnost migrace serverů za provozu • testování nových verzí softwaru bez ohrožení provozu • jednodušší administrace VMware

Obrázek 1.6: Struktura VMware ESX

V JVK se využívá virtualizačních nástrojů sytému VMware vSphere 5.0. Jádrem tohoto systému je tzv. hypervizor pojmenovaný VMware ESX. Tento hypervizor tvoří virtualizační vrstvu sloužící jako základ ostatním částem systému. ESX se dále dělí na 2 spolupracující komponenty: • Service Console – komponenta odvozená z Linuxu obsahující většinu základních služeb klasických operačních systémů. Některé služby ovšem chybí z důvody zbytečnosti pro virtualizaci. Service Console nepřistupuje na samotný hardware, ale zajišťuje přístup k VMkernel. • VMkernel – základ virtualizačního procesu, který zajišťuje přístup virtuálních počítačů k základnímu fyzickému hardwaru. 16

1.6. Operační systémy V knihovně se vyskytuje celkem 10 virtuálních serverů (z toho 4 testovací) na 3 fyzických serverech. Na těchto serverech běží služby jako DNS, doménová služba, RADIUS server, knihovní systém (používající databázi Cache), SAMBA, ekonomický systém, veškeré databáze (pomocí databází Postgres a MySQL) nebo také správa ESX hostitelů (VMware vCenter). Diskový prostor na serveru je využit pouze pro zavedení konfigurace serverů a jejich nastartování, všechna ostatní data virtuálních serverů jsou uložena na sdíleném diskovém poli SAN. [18] [11]

17

Kapitola

Návrh nové infrastruktury 2.1

Popis stavu

Jihočeská vědecká knihovna v roce 2013 plánuje provést celkový upgrade síťové infrastruktury z důvodů nevyhovujícího stávajícího stavu, a to zejména ze třech hlavních důvodů: • značná zastaralost techniky • umožnění jednodušší správy systému • nedostatečná odolnost proti výpadku klíčové části • snadnější záloha dat Jelikož většina prvků síťové infrastruktury je stará až 8 let, nevyhovuje v současné době ani svým výkonem, ani spolehlivostí a další předpokládanou životností. S narůstajícím věkem zařízení se zvyšuje pravděpodobnost možné poruchy zařízení. Nejenže veškeré opravy probíhají již mimo záruku, ale velkým problémem je i dostupnost náhradních dílů. Z těchto důvodů je ekonomičtější provést jednorázový upgrade celé sítě. Dalším problémem stávajícího řešení je velká diverzita síťových prvků, která souvisí právě se stářím a postupným budováním sítě. Když některý prvek sítě přestal fungovat a jeho oprava již nebyla ať už z technických nebo finančních důvodů možná, byl nahrazen jiným prvkem s podobnými vlastnostmi, který byl aktuálně dostupný na trhu. Touto výměnou a postupnou pomalou modernizací došlo k tomu, že se v celé infrastruktuře vyskytuje několik druhů stejných síťových prvků, a ke každému je třeba mít některé základní náhradní díly, popřípadě, pokud se jedná o klíčový prvek, je třeba mít celý náhradní prvek, aby se mohla případná porucha rychle řešit pouze 19

2

2. Návrh nové infrastruktury výměnou. Toto řešení je ale velice finančně náročné. Největším bezpečnostním rizikem stávajícího řešení je nedostatečné řešení záloh. Přestože se provádí zálohy v pravidelných časových intervalech a data jsou zálohována jak na hlavní tak záložní server, není tato záloha dostatečná především s ohledem na umístění záložního serveru, který se nachází na stejném patře ve vzdálenosti ca 40 metrů od hlavního serveru. Například v případě většího požáru je velice pravděpodobná ztráta veškerých dat. Podle revizní zprávy požárního technika, je prohoření otázka 15-20ti minut.

2.2

Požadavky na novou infrastrukturu

Kromě odstranění nedostatků z předchozího bodu, je zde ještě několik dalších podmínek, které musí budoucí infrastruktura splňovat: • 1 Gbps porty - Jelikož dojde k navýšení rychlosti propoje na CESNET ze 100 Mbps na 1 Gbps, musí nová infrastruktura tyto rychlosti podporovat a to v normě 1000Base-BX. Není ovšem nutné mít všechny porty podporující tuto rychlost, tiskárny a obecně všechna zařízení, která nebudou profitovat z rychlosti 1 Gbps, mohou využívat porty s přenosovou rychlostí maximálně 100 Mbps. • PoE porty - v JVK se stále využívá analogová telefonní linka a z důvodu možného přechodu na IP telefonii v řádech měsíců, by měly switche obsahovat alespoň tolik PoE portů, kolik je v knihovně telefonů. Kromě telefonů se už nyní v knihovně využívají některá PoE zařízení (přístupové body WiFi a kamery). • příprava na zokruhování připojení k Internetu - Z důvodu závislosti internetového připojení na funkčnosti linky ze sdružení CESNET, která není redundantní, by bylo vhodné vést zároveň i náhradní trasu a vytvořit okruh. Při přerušení tohoto spoje, ať už na trase CESNETLidická nebo mezi budovami Lidická-Na Sadech, se jedna nebo obě budovy ocitnou bez připojení k Internetu (v závislosti na tom, který spoj byl přerušen). V roce 2014 se plánuje zbudování náhradní trasy ze sdružení CESNET do budovy Na Sadech, čímž by se vytvořil požadovaný okruh. Nová infrastruktura by s tímto měla již počítat, aby nebylo nutno vyměňovat nově zakoupená zařízení za jiná. • zachování novějších stávajících prvků - Přestože většina zařízení v knihovně je již zastaralá, jsou zde i novější prvky jako servery HP LeftHand 20

2.3. Obecné řešení P4300 G2, servery řady HP ProLiant a switche HP A5120-24G El JEO68A, které jsou stále v záruční době. Tyto prvky v nové infrastruktuře zůstanou zachovány.

2.3

Obecné řešení

Nejzávažnější problém aktuální topologie, tedy uchovávání záloh v blízkosti datového centra, bude vyřešen zrušením serverovny v budově Lidická a zbudováním nové serverovny v budově Na Sadech, a to konkrétně ve skladu. Do této nové serverovny se přesune jeden server HP LeftHand P4300 G2, switch HP A5120-24G El JEO68A a backup server z budovy Lidická. Z důvodu vyhovění požadavku na jednotnost prvků a zároveň zachování některých stávajících serverů od firmy Hewlett-Packard, jsem se rozhodl pro sestavení nové infrastruktury výhradně z prvků Hewlett-Packard.

2.3.1

Páteřní switch

Nabízejí se 2 řešení jak řešit páteřní switch, a to použití tzv. stohovatelného (stackable) switche nebo šasi (chassis). Stohovatelný switch Stohovatelný switch je switch, který dokáže fungovat nejenom jako samostatné zařizení, ale také ve spojení s jedním nebo více dalšími switchy (tzv. stoh). Tato skupina switchů je v síti reprezentována jako jeden switch s tolika porty, jako je součet portů této skupiny. Oproti samostatnému switchy mají tyto výhody: • odolnost spojení – Pokud jeden prvek selže nebo je odstraněn ze stohu, data stále proudí přes ostatní funkční zařízení bez výpadku. • flexibilní nasazení – Stohovatelné switche mohou fungovat jako rychlá náhrada například v případě poruchy. Switch může být přemístěn ze stohu do jiné lokality, kde pak může pracovat samostatně. • jednodušší správa – Ať už se jedná o jeden switch nebo o stoh switchů, správa může probíhat pomocí pouze jednoho rozhraní a ne pro každý fyzický switch zvlášť. 21

2. Návrh nové infrastruktury • škálovatelnost – s tím, jak se rozšiřuje počet počítačů zapojených do sítě, je možné dokupovat další stohovatelné switche a jednoduše rozšiřovat počet portů. [20] Šasi Šasi je síťový switch, který je konfigurovatelný různými moduly podle vyžadovaného typu a množství rozhraní. Samotná šasi obsahuje jeden společný backplane8 , napájecí zdroj a chladící ventilátory (většinou vše redundantní). Oproti stohovatelným switchům má šasi náísledující výhody: • vysoká dostupnost – Šasi sdružuje ovládací prvky, napájecí zdroj a chladící ventilátory pro všechny moduly a pomocí dalších modulů je možné mít tyto prvky redundantní. Tímto systémem se dá výrazně snížit možnost výskytu jediného bodu selhání (single point of failure), protože všechny klíčové prvky systému budou redundantní. • efektivnost – Protože více prvků je společných pro celou šasi, lépe rozdělená zátěž většinou vyústí ve vyšší míru efektivity a celkově lepší využití těchto prvků. • škálovatelnost – v případě nedostatečného množství portů či rozhraní, lze přidat moduly s požadovaným rozhraním do prázdných slotů a tedy systém libovolně škálovat až do velikosti šasi. • vyšší výkon — Jelikož šasi obsahuje vysokorychlostní backplane, je možné dosáhnout neblokující konfigurace pro packety libovolné velikosti, a to při provozu jako L2 i L3 switch. • výměna modulů za běhu — Většina prvků šasi podporuje výměnu modulů za běhu systému (hot-swap), není tedy nutné plánovat odstávku celého šasi i při výměně klíčových prvků (i díky redundanci). Na druhou stranu nevýhody šasi oproti stohovatelným switchům jsou: • vyšší pořizovací cena a cena dílů (modulů) – Na rozdíl od ceny samostatných switchů, u kterých cena klesá s dobou, od kdy bylo dané zařízení uvedeno na trh, u modulů se cena výrazně neliší od ceny v době jejich uvedení. 9 8

backplane – vysokorychlostní konstrukční prvky na zadní straně šasi, sloužící k potřebnému propojení jednotlivých zásuvných modulů – tedy konektory, které svým zapojením a vzájemným propojením vytváří nejrůznější sběrnice. 9 Na základě srovnání HP E5500-48 (JE100A), u kterého klesla cena o 32% za 7 měsíců, zatímco u modulu HP 24-port SFP v2 zl Module (J9537A) klesla cena o 3% za stejnou dobu. [14] [13]

22

2.4. Budova Lidická

Obrázek 2.1: Návrh rozmístění páteřních prvků a jejich propojení

• moduly jedné značky – Pokud bude třeba vyměnit některý modul je nutné pořídit model stejné značky a nelze použít jinou alternativu. • nesamostatnost modulů – v případě potřeby, například v případě poruchy jiného zařízení, není možné oddělit modul ze šasi a provozovat ho samostatně.[17]

2.4

Budova Lidická

Jak již bylo řečeno v minulé sekci, v budově Lidická 1 dojde ke zrušení druhé serverovny, která se přesune do prostor první serverovny, a backup server, server HP LeftHand P4300 G2 a switch HP A5120-24G El JEO68A z první serverovny se přesunou do budovy skladu Na Sadech (schéma 2.1).

2.4.1

Počty portů

Celkem je v budově Lidická třeba alespoň (včetně rezervy): • 48x 10/100 Mb port – tiskárny a kamerový systém • 164x 1 Gbit port – všechny servery a počítače. Z toho 2 porty pro přípojení poboček a do Internetu pomocí optických vláken. • 1x 10 Gbit port – připojení do skladu v budově Na Sadech - Sklad 23

2. Návrh nové infrastruktury

2.4.2

Páteřní switch

I přes některé nesporné výhody šasi řešení, jako je vyšší stupeň redundance, je pro potřeby knihovny ekonomičtější zvolit variantu se stohovatelnými switchy. Jelikož knihovna není klasická firma, ve kterém by výpadek v řádech desítek minut znamenal velkou finanční ztrátu, může si knihovna dovolit ušetřit na těchto síťových prvcích na úkor redundance a nižší ochrany proti výpadkům, a zároveň i v budoucnu ušetřit provozní náklady při výpadku některého zařízením pořízením levnějšího switche než dražšího modulu (více v kapitole 2.3.1. Jelikož nepotřebují všechny počítače v síti navzájem komunikovat, rozhodl jsem se rozdělit páteřní switch na 2 logické části, a to výkonné jádro a uživatelské stanice. Výkonné jádro Na výkonné jádro budou napojeny všechny servery v budově Lidická, připojení poboček i připojení k Internetu. Z důvodu redundance bude toto jádro obsahovat 2 switche a to konkrétně HP 5500-48G HI. Jedná se o switch s information rate10 192 Gbps při 143 Mpps s možností plnohodnotného dynamického směrování (RIP, OSPF a PIM protokoly) na L2 i L3 vrstvě, bezpečnostních pravidel (ACL), dynamickou ochranou ARP, DHCP nebo STP. Obsahuje také pokročilou správu QoS včetně možnosti konfigurace parametrů vyprazdňovacích funkcí, realokace bufferů, určení počtu front a prioritizace podle nejrůznějších pravidel. Přepínač také obsahuje řadu funkcí pro sledování provozu (sFlow11 , RMON). Tento switch byl zvolen pokročilejším funkcím oproti nižší řadě HP 5120 EI. Jedná se například o plnohodnotné L3 směrování nebo propracovanější správu QoS – řada HP 5500 dokáže například omezit broadcast, multicast i neznámý unicast provoz pro snížení nechtěné zátěže sítě. Řada HP 5120 dokáže ve stejné situaci omezit pouze multicast provoz.[10][9] Přestože k připojení všech serverů k těmto jádrům by stačily switche s pouze 24 porty, v konfiguraci jsou úmyslně použity switche s 48 porty z důvodu redudance. Každý server bude připojen minimálně jedním 1 Gbit spojem ke každému switchy z výkonného jádra, tzn. dohromady bude každý server připojen minimálně 2 ethernetovými kabely. Některé switche, pro které by 10

information rate – hypotetická kapacita linky bez hlavičky protokolu fyzické vrstvy sFlow je technologie pro monitorování sítí a hostitelů podle RFC 3176, která místo analýzy všech paketů analyzuje pouze reprezentativní vzorek, čímz se nestává zcela přesná, ale za to je rychlejší a neovlivňuje rychlost switche. 11

24

2.4. Budova Lidická mohl 1 Gbit spoj znamenat výkonové omezení, budou propojeny i více spoji. Toto se týká například propojení switchů se serverem HP LeftHand P4300 G2, na kterém jsou uloženy všechna data – a je tedy třeba toto spojení vhodně dimenzovat. Proto bude toto propojení realizováno alespoň dvěma 1 Gbit kabely na každý switch (tedy celkem čtyři), podle zátěže je navíc možné přidat k tomuto spojení další porty. Toto zapojení je možné díky protokolu Link Aggregation Control Protocol (LACP)[5]. Pro zvýšení odolnosti proti výpadku by bylo vhodné pořídit i redundantní napájení, které tato řada také podporuje. Uživatelské stanice Na další sadu switchů budou připojeny všechny uživatelské stanice (to jak zaměstnanců, tak i veřejně přístupné stanice) a jiná nenáročná zařízení (jako např. tiskárny). Jelikož připojená zařízení nemají výraznější síťový provoz ani nepředstavují klíčové prvky pro funkci JVK, není u jejich připojení k síti vyžadována velká redundance ani pokročilé funkce. Z těchto důvodů jsem zde zvolil nižší řadu switchů HP 5120 EI, a to konkrétně čtyři switche HP 5120-48G EI a jeden HP 5120-24G EI (použitý ze stávající konfigurace). Řada HP 5120 na rozdíl od HP 5500 nepodporuje směrování pomocí protokolů OSPF ani PIM a podporuje pouze směrování na L2 vrstvě a L3 Lite12 s podporou protokolu ARP (pouze ale se statickým směrováním). Rozdíl je také v méně propracované technologii QoS (například chybějící technologie WFQ a WRED pro prioritizaci provozu), ale v ostatních parametrech se tyto řady od sebe téměř neliší. Díky tomu, že se jedná o switche pouze pro pracovní stanice, u kterých se neočekává velký provoz, jsou tyto funkce postradatelné výměnou za ušetřené finanční prostředky. Řada 5120 EI byla zvolena také proto, že ve stávající infrastruktuře již existují dva novější switche HP 5120-24G. Tyto switche tedy není nutné obměňovat a mohou být pro ušetření nákladů použityi v nové infrastruktuře.[10][9] Přestože v požadavcích je zadáno pouze 212 portů (a to včetně připojení serverů a tiskáren), v mém návrhu figurují switche s cekovým počtem 216 portů. Tyto porty navíc oproti požadavkům mají své opodstatnění. Jelikož propojení výkonného jádra s každým switchem je realizováno jedním 1 Gbit portem, v závislosti na zátěži by se právě toto spojení mohlo stát úzkým hrdlem tohoto systému. Počítá se zde tedy s využitím agregace portů a to až do celkové velikosti 5 Gbit na switch (tedy 5 portů na každém switchy). V maximální možné kombinaci bychom přišli o 50 portů (25 portů 12

L3 Lite, na rozdíl od plnohodnotného L3 směrování, podporuje pouze funkce L2 switche s přidáním statického směrování na L3 vrstvě.

25

2. Návrh nové infrastruktury z uživatelských stanic a 25 z výkonného jádra), ale stále by byly splněny požadavky na počet portů. V reálném provozu bude při aktuální zátěži postačovat i poloviční rychlost. Z důvodu využití redundance je opět možnost propojit každý server na oba switche z výkonného jádra a také použít redundantní napájecí zdroj.

2.4.3

Strukturovaná kabeláž

Servery Protože v budově Lidická budou od sebe servery vzdálené pouze v řádech desítek centimetrů, nemá zde smysl tedy využití optických kabelů. Místo nich je zde využita kroucená dvoulinka a to kategorie Cat5e, která se hodí jak pro 100BASE-TX i 1000BASE-T Ethernet. Spojení s budovou Na Sadech - Sklad Pro spojení z budovy Lidická s budovou Na Sadech, a to konkrétně s budovou skladu, bude využit již existující pár single-mode optických vláken s parametry 9/125 µm. Vzdálenost mezi těmito budovami je přibližně 3 km, proto zde bude použita varianta 10GBASE-LR, která je vhodná pro komunikaci na vzdálenost až 10 km a poskytuje duplexní spojení na vlnové délce 1310 nm. V případě využití tohoto existujícího optického vlákna je třeba do serveru, který má komunikovat s budovou Na Sadech, pořídit příslušný transceiver, v tomto případě ve standartu SFP+, a to konkrétně HP X130 10 Gbit SFP+ LC LR Transceiver. Připojení poboček Připojení poboček zůstane řešeno stávajícím způsobem z důvodu smluvních podmínek s firmou, která zajišťuje toto spojení. Konkrétně se bude jednat o single-mode optické vlákno, které bude připojeno na převodník Repotec RP-1002MG, který převádí spojení na 10/100Mb ethernetový kabel. Připojení k Internetu Připojení k Internetu je zbytečné řešit pomocí 10 Gbit spoje, protože maximální rychlost připojení je nastavena na 1 Gbps. Vzdálenost od připojení k CESNETu je přibližně 4 km a již je zde také zaveden pár single-mode optických vláken s parametry 9/125 µm. Z těchto důvodu jsem zde použil 1 Gbit SFP transceiver a to konkrétně HP X121 1 Gbit SFP LC LX Transceiver. 26

2.5. Budova Na Sadech - Sklad Intelligent Resilient Framework Intelligent Resilient Framework (IRF) je technologie, která spojuje 2 a více switchů do jednoho virtuálního switche. Základní myšlenka této technologie je podobná jako u konkurenční technologie Virtual Switching System firmy Cisco. Hlavní výhody této technologie jsou ve vyvažování zátěže, agregaci a redundanci na všech úrovních a všech funkcích. [8] Těchto výhod se využije v propojení switchů HP 5500 HI, u kterých je důležitá vysoká dostupnost, což je zajištěno právě technologií IRF. Propojení je řešeno pomocí 10 Gbit SFP+ Direct Attach kabelů, které jsou tvořeny dvěma páry twinaxiálních kabelů. Na rozdíl od klasického optického spoje je toto řešení levnější, s nízkou odezvou a také nižší spotřebou energie. Na druhou stranu je tento spoj vhodný pouze do vzdálenosti deseti metrů při použití pasivní technologie, respektive okolo patnácti metrů při aktivní technologii (přesné hodnoty záleží na výrobci).[16]

2.5

Budova Na Sadech - Sklad

V této budově je pouze několik počítačů, nejsou tedy potřeba téměř žádné síťové prvky. Jelikož se sem však také přesune server HP LeftHand P4300 G2, UPS zdroj SmartUPS 2200 a backup server z budovy Lidická, je třeba nové síťové prvky dostatečně dimenzovat.

2.5.1

Počty portů

Celkem je v budově skladu třeba alespoň (včetně rezervy): • 5x 10/100 Mbit port – tiskárny a WiFi přístupové body • 20x 1 Gbit port – všechny počítače a připojení do hlavní budovy Na Sadech • 1x 10 Gbit port – připojení do budovy Lidická

2.5.2

Páteřní switch

Protože v budově skladu je potřeba malé množství portů, páteřní switch bude řešen jako jediný fyzický switch, a to konkrétně pomocí switche HP 5500-48G HI, který byl vybrán ze stejných důvodů, jako je zdůvodněno v 2.4.2. Na tento switch budou napojeny všechny prvky ve skladu, tedy všechny počítače, tiskárny, přístupové body, server HP LeftHand P4300 G2, UPS zdroj SmartUPS 2200, připojení do hlavní budovy Na Sadech 27

2. Návrh nové infrastruktury a připojení do budovy Lidická. Přestože by se mohlo zdát, že v tomto případě by bylo z důvodu redundance vhodnější použití dvou switchů, v konkrétní situaci toto řešení nemá velký smysl. Veškeré spojení z budov Na Sadech musí směrovat přes budovu Lidická a toto spojení je řešeno pomocí pouze jednoho páru optických vláken. V případě výpadku switche, který je napojen na budovu Na Sadech, by tedy toto spojení zůstalo stále přerušeno, a s tím by byla přerušena i veškerá síťová komunikace.

2.5.3

UPS

Do této serverovny bude také přesunut UPS zdroj SmartUPS 2200 ze zrušené serverovny v budově Lidická. Výkonem tato UPS dostačuje i na mnohem vyšší zátěž, než jaká bude vyžadována síťovými prvky v budově skladu.

2.5.4

Strukturovaná kabeláž

Spojení s budovou Lidická Z důvodu použití transceiveru HP X130 10 Gbit SFP+ LC LR Transceiver v budově Na Sadech pro spojení s budovou Lidická (více v kapitole 2.4.3 v sekci Spojení s budovou Na Sadech - Sklad), je nutné využít tento standard i zde, a to také ve formě SFP+ transceiveru.

Spojení s budovou Na Sadech - Vila Budova vily je od budovy skladu vzdálena pouze přibližně 10 metrů, bylo by zde tedy možné použít multi-mode optické vlákno. Přesto jsem ale do návrhu zahrnul klasickou kroucenou dvoulinku a to celkem s maximální rychlostí 4 Gb s využitím agregace 1 Gb spojů. Toto řešení jsem zvolil čistě z důvodu úspory finančních prostředků. Jelikož se jedná o relativně krátkou vzdálenost a již je zde použit metalický spoj, se kterým co se týče kvality není žádný problém, toto řešení zůstano zachováno. Pokud by se tento spoj nahrazoval optickými vlákny, znamenalo by to výdaje nejen na samotné optické vlákno, ale zároveň i na dva 10 Gbit transceivery (zapojení 1 Gbit transceiverů by pro tento spoj mohlo být limitující). 28

2.6. Budova Na Sadech - Vila

2.6

Budova Na Sadech - Vila

Zde se nacházejí přístupové body pro WiFi připojení, 35 počítačů (jak zaměstnanců tak i stanice pro čtenáře), kamerový systém a tiskárny.

2.6.1

Počty portů

Celkem je v budově skladu třeba alespoň (včetně rezervy): • 13x 10/100 Mbit port – tiskárny, WiFi přístupové body a kamerový systém • 40x 1 Gbit port – všechny počítače a připojení do budovy skladu Na Sadech

2.6.2

Páteřní switch

Jako páteřní switch bude sloužit jeden HP 5120-48G EI a jeden HP 512024G EI (použitý ze stávajícího řešení) ze stejných důvodů, jako je popsáno v sekci 2.4.2. Redundance tohoto prvku není plánována, ale alespoň částečné redundance lze docílit zapojením switchů do jednoho logického switche pomocí technologie IRF a rozdělení spojení do budovy skladu na polovinu, kde polovina bude zapojena na jeden switch a druhá polovina na druhý switch.

2.6.3

Strukturovaná kabeláž

Spojení s budovou Na Sadech - Sklad Zde budou použity celkem čtyři 1 Gb agregované metalické spoje, jak je popsáno v sekci 2.5.4.

2.7

Kompromisy návrhu

Přestože jsem se snažil v návrhu minimalizovat veškeré nedostatky, z důvodu velké priority co nejnižší ceny bylo nutné udělat některé kompromisy. Propojení switchů Žádný z použitých switchů ze sekce 2.4.2 není s ostatními propojen do jednoho velkého virtuálního switche (ani pomocí backplane spoje či jiného řešení), administrace těchto switchů tedy probíhá odděleně a každý se musí 29

2. Návrh nové infrastruktury

Obrázek 2.2: Návrh switchů a jejich zapojení s virtuálními servery

konfigurovat samostatně. Také veškerá komunikace mezi uživatelskými stanicemi probíhá přes switche z výkonného jádra, protože je ale tato komunikace minimální a výjimečná, nemělo by toto řešení způsobovat žádné výkonnostní problémy. PoE porty Přestože v podmínkách pro novou infrastrukturu jsou zmíněny PoE porty, v návrhu s nimi z důvodu ceny nepočítám. PoE porty by byly využity výhradně pro IP telefony a WiFi přístupové body, které tuto technologii podporují. Nyní jsou všechna tato zařízení zapojena do elektrické sítě pomocí adaptérů a PoE nevyužívají. Jelikož tyto elektrické zástrčky pro všechna dnes instalovaná zařízení již existují a jiné využití pro ně zatím neexistuje, není tedy naprostou nutností PoE zde využívat a vzhledem k ceně, kde switche s technologií PoE jsou přibližně o 20-30% dražší, než totožné switche bez této technologie, je finančně výhodnější zvolit levnější variantu. Pokud by knihovna ale na této technologii trvala, návrh sítě by se nijak nezměnil, pouze by se switche nahradily stejným modelem s PoE technologií (jak série HP 5500 tak i HP 5120 má v nabídce switche s PoE technologií). 30

2.8. Srovnání s návrhem od společnosti Power System s.r.o. Neúplná redundance V návrhu nové infrastruktury by bylo možné navrhnout síť zcela redundantní (přestože by to zřejmě bylo nerentabilní), ale úzkým hrdlem celé sítě by stále zůstal optický spoj z budovy Lidická do budovy skladu Na Sadech. Toto propojení je realizováno pouze jedním párem optického vlákna a v případě poruchy switche, kterými jsou budovy propojeny, zůstane celá budova Na Sadech bez připojení do sítě. Tento problém se dá vyřešit pouze zokruhováním celé sítě (tj. zavedení spoje mezi společností CESNET a budovou Na Sadech – ať již s vilou nebo přímo skladem), což je plánováno v některých dalších letech. Tento spoj by poté sloužil jako záložní spojení a o funkčnost tohoto řešení by se staral protokol STP, který by blokoval porty tak, aby v síti nevznikaly smyčky.

Dva druhy switchů V návrhu infrastruktury jsou použity dvě řady switchů od firmy HewlettPackard a to konkrétně řada HP 5500 pro připojení serverů a dvou vzdálených budov a řada HP 5120 pro ostatní síťová zařízení. Použití pokročilejších a dražších switchů HP 5500 v celé síti by bylo finančně velmi náročné, navíc pokročilé funkce by zůstaly z valné části nevyužity. Pokud by se použily prvky výhradně řady HP 5120, mohl by vznikat výkonnostní problém při vyšší zátěži serverů (například v kombinaci nadměrných požadavků na HTTP server a databázi knihovny současně s právě probíhajícím zálohováním všech dat). Na druhou stranu se díky tomuto řešení podařilo do návrhu zahrnout již dva existující switche HP 5120-24G bez vlivu na jednotnost prvků.

2.8

Srovnání s návrhem od společnosti Power System s.r.o.

Páteřní switch Firma Power System s.r.o. postavila celý návrh na šasi switchech ze série HP 5400 zl a to ve všech serverovnách. Výkonově jsou tyto šasi srovnatelné se switchy ze série HP 5500 HI, které navrhuji ve svém návrhu. Po stránce funkčnosti obsahují tato šasi některé pokročilé bezpečnostní funkce, jako je detekce útoků a jejich předcházení (Virus throttling, ICMP throttling), a také dále vylepšenou správu QoS, 31

2. Návrh nové infrastruktury jako je například podpora Traffic shaping13 pro regulaci šířky přenosového pásma a limitaci využití linky podle nastavených pravidel.[6] Výhody či nevýhody tohoto řešení oproti mému řešení plynou z obecných výhod a nevýhod šasi oproti stohovatelným switchům, které jsou popsány v sekci 2.3.1. Strukturovaná kabeláž V návrhu pro budovu Lidická jsou použity dva 10 Gbit LR SFP+ optické transceivery pro spojení s pobočkami a s budovou knihovny a jeden 1 Gbit LR SFP transceivery pro spojení se sítí CESNET. Pro vnitřní komunikaci po budově je zde k dispozici celkem 48 Fast Ethernet portů a 168 gigabit Ethernet portů. V budově Na Sadech ve skladu jsou použity dva 10 Gbit LR SFP+ optické transceivery pro spojení s budovou knihovny a s budovu skladu. Pro připojení zařízení obsažených ve skladu je zde k dispozici 44 gigabit Ethernet portů. V budově Na Sadech ve vile je použit jeden 10 Gbit LR SFP+ optický transceivery pro spojení s budovou skladu a pro připojení prvků v budově je zde k dispozici celkem 24 Fast Ethernet portů a 44 gigabit Ethernet portů. Diskuze návrhu Oproti mému řešení má řešení zvolené firmou Power System s.r.o. několik výhod i nevýhod. • Redundance – Z důvodu použití šasi ve všech 3 serverovnách má toto řešení o něco vyšší stupeň redundance než návrh s pomocí stohovatelných switchů – zvláště v budově skladu Na Sadech. i přesto tento návrh obsahuje stále jediný bod selhání, a to spoj mezi budovou Na Sadech a Lidická, kde tento problém nelze vyřešit jinak, než vybudováním nové trasy. Zvýšení redundance oproti mému návrhu je tedy nadbytečné a ve výsledném efektu se neprojeví. • Cena – Pořizovací cena i cena dílů je v případě šasi mnohem vyšší než u stohovatelných switchů a v současné ekonomické situaci je toto kritérium velice důležité. 13

Technologie Traffic shaping klasifikuje provozu podle různých kriterií jako je například port nebo protokol a podle těchto informací dále zvyšuje využitelnost šířky pásma pro některé druhy paketů a zpožďuje jiné druhy pakety.

32

2.8. Srovnání s návrhem od společnosti Power System s.r.o. • Funkce – Přestože je šasi řady 5400 zl funkčně vybavenější než stohovavelné switche, tyto nabízené funkce nejsou pro provoz knihovny klíčové a při současné zátěži by nebyly plně využívány. Z tohoto důvodu by tedy nebylo velmi finančně výhodné pořizovat dražší šasi. • Trasa sklad-vila – Firma Power System s.r.o. řešila tuto trasu pomocí optického vlákna. Tuto možnost jsem také zvažoval, ale důvody proč jsem jsem toto řešení nakonec nepoužil, jsou vysvětleny v sekci 2.5.4. i přes toto jsem ale přesvědčen, že použití single-mode 10GBASELR propojení na vzdálenost několika metrů, jak je navrženo firmou Power System s.r.o., je ekonomicky velice nevýhodné. Toto řešení vzniklo zřejmě snahou o unifikování spojů, tedy nepoužívat zde jiný druh transceiveru než 10Gb tranceiver, kterým je již zajištěno spojení mezi budovami Lidická a Na Sadech – sklad. Toto řešení však není finančně výhodné pro kratší vzdálenost. Mnohem vhodnější by bylo použití transceiveru založeném na multi-mode 10GBASE-SR řešení, který je přibližně o 42% levnější.14

14

Na základě srovnání cen z internetových stránek Hewlett-Packard, kde 10GBASELR SFP+ J9150A transceiver stojí $3153.17 a 10GBASE-SR SFP+ J9151A transceiver stojí $1327.17.

33

Kapitola

Implementace 3.1

Počáteční konfigurace

Do virtuálního stroje (popsáno v sekci ?? ) jsem vytvořil celkem 5 serverů, všechny s operačním systémem Ubuntu Server 12.04.2 LTS založeným na Debian GNU/Linux. Na každém stroji jsem nainstaloval a zkonfiguroval některou ze služeb, která se používá v produkčním prostředí JVK. Konkrétně se jedná o tyto stroje se službami: • DNS – DNS server překládající interní rozsah virtuálních serverů do domény nagios.jvk pomocí programu bind9; jako forwarder zde slouží externí DNS server poskytovatele připojení. • RADIUS – RADIUS server implementován pomocí projektu FreeRADIUS v2.2.0 pro ověřování přihlašovacích údajů s lokální MySQL databází. • PostgreSQL – PostgreSQL databázový stroj s několika databázemi s testovacími daty. • HTTP a mail server – Mail server s MTA agentem (Postfix v2.10), MDA agentem (Dovecot v2.2.1.) a webmailem (Squirrelmail v1.4.22). Součástí toho serveru je i Apache HTTP Server v2.2.22 pro webmail. • Nagios server – Nagios Core v3.5.0 server se základními pluginy pro monitoring s Apache HTTP Serverem v2.2.22 pro webové rozhraní systému Nagios. 35

3

3. Implementace

3.2

Nagios

Nagios[19] je dohledový systém, který stále kontroluje stav hostitelů a různých služeb, které na těchto strojích běží. Hlavním účelem takového systému je nalezení a oznámení chyby administrátorovy dříve, než na tuto chybu narazí běžný uživatel. Nagios jako takový ale žádné kontroly neprovádí. Tyto kontroly provádí pluginy, které hlásí stav kontroly a Nagios tato hlášení pouze zpracuje, popřípadě nahlásí problém, pokud plugin narazil na chybu u hostitele nebo služby. Pluginy do takového systému mohou být napsány v kterémkoliv programovacím jazyce, stačí aby jejich výstupem byl příznak stavu služby (OK, WARNING, CRITICAL nebo UNKNOWN) a doprovodné informace o stavu, které se ale nijak nezpracovávají a slouží především jako informace pro administrátory. Výstupem také může být číselná hodnota (například procento volného disku nebo teplota procesoru), kde Nagios nastaví odpovídající stavový kód podle zadaného rozsahu hodnot u těchto stavů. Tímto řešením se stává Nagios neuvěřitelně škálovatelný a pomocí pluginů může kontrolovat prakticky jakoukoliv činnost serverů. Když už se některý server nebo jeho služba stane nedostupná, Nagios rozlišuje tzv. Soft a Hard stav. Při první detekci chyby se přepne tato služba do Soft stavu a zvýší se frekvence kontrol. Pokud se služba do určeného počtu pokusů stane znovu dostupná, Nagios nenahlásí žádnou chybu. Pokud se ale služba nezpřístupní, přepne se do Hard stavu a upozorní e-mailem administrátora, že daná služba se stala nedostupná. Tento systém dokáže pracovat ve dvou vzájemně kombinovatelných režimech, a to aktivní a pasivní kontrola. Při aktivní kontrole si Nagios sám odesílá požadavky na zkontrolování pluginem, zatímco při pasivním režimu pluginy samy odesílají informace bez vyžádání, například v nepravidelných intervalech, když zjistí, že některá služba neběží (v případě, že služba běží, neposílají žádné informace).

3.2.1

Struktura konfiguračních souborů

Po instalaci Nagios Core v3.5.0., pluginů Nagios Plugins v1.4.16 a agenta NRPE v2.14 vzniknou konfigurační soubory v cestě zadané při kompilaci zdrojových souborů (v mém případě složka /etc/nagios). Konfigurační soubory mohou být uloženy všechny v jednom souboru, pro přehlednost jsou však rozděleny do těchto souborů: 36

3.2. Nagios nagios.cfg Hlavní konfigurační soubor systému Nagios, obsahuje cestu k dalším konfiguračním souborům, popřípadě celým složkám. Dále se zde nachází UID a GID uživatele, pod kterým beží Nagios, nastavení logování nebo povolení externích příkazů pro externí příkazový soubor. Tento konfigurační soubor obsahuje ještě mnoho dalších parametrů, tyto jsou ale ty nejdůležitější pro moji konfiguraci. resource.cfg Tento soubor obsahuje definice maker, která mohou být dále použita v příkazech pro Nagios. Implicitně je definována pouze cesta k pluginům, lze zde ale definovat i cokoliv dalšího, například uživatele a hesla, která pak nejsou psána přímo v příkazech. objects/commands.cfg Zde se definují příkazy, které jsou poté použity v systému Nagios. Tyto definice mají formát: define command { command_name command_line

jmeno_prikazu / cesta / prikaz -H IP_serveru \ -c prah_crit -w prah_warn \ -u uzivatel -p heslo

}

objects/templates.cfg Zde jsou definovány šablony, které pak jednotlivé konfigurační soubory používají pro zkrácení délky. Mohou zde být definovány jak šablony pro kontakty, tak i pro služby a servery. Formát pro definování šablony pro tiskárnu je: define host { name notifications_enabled event_handler_enabled flap_detection_enabled failure_prediction_enabled pro cess_p erf_da ta retain_status_information retain_nonstatus_information n o ti f i ca t i on _ p er i o d check_period

printer - temp 1 1 1 1 1 1 1 workhours 24 x7

37

3. Implementace check_interval retry_interval ma x_ ch ec k_ at te mp ts contact_groups check_command register }

5 1 10 admins check - host - alive 0 # sablona

objects/contacts.cfg V tomto souboru jsou definováni uživatelé a skupiny, kterým chodí upozornění, pokud je některá služba nebo server nedostupný. Nacházejí se zde ve formátu: define contact { contact_name use alias email }

p re z d i vk a _ uz i v at e l e jmeno_sablony jmeno_uzivatele mail@domena . cz

define contactgroup { con tactgr oup_na me alias members }

pr ezdivk a_skup iny jmeno_skupiny contact_name_uzivatele

objects/hostgroups.cfg Tento konfigurační soubor obsahuje definice skupin serverů v jednoduchém formátu: define hostgroup { hostgroup_name alias }

3.2.2

pr ezdivk a_sku piny jmeno_skupiny

Vlastní konfigurace

Před konfigurací bylo třeba na všechny servery doinstalovat také NRPE agenta, který se stará o spouštění příkazů na vzdálených serverech. Na všech serverech se sledují aktualizace systému, zátěž procesoru a samotná funkčnost serveru pomocí utility PING založené na protokolu ICMP posílající Echo Request. Protože na každém serveru je spuštěna jiná služba, bylo třeba tyto služby hlídat. Konkrétně se sleduje: 38

3.2. Nagios • Nagios server – Volné místo na disku a stav Apache HTTP Serveru • DNS server – Funkčnost DNS služby, počet procesů a počet tzv. „zombie“ procesů • RADIUS server – Počet procesů a stav MySQL serveru • PostgreSQL server – Volné místo na disku, stav PostgreSQL databáze, volné místo v odkládacím prostoru, počet procesů a počet tzv. „zombie“ procesů • HTTP a mail server – Volné místo na disku, počet přihlášených uživatelů, stav Apache HTTP Serveru, stav SMTP serveru, volné místo v odkládacím prostoru, počet procesů a počet tzv. „zombie“ procesů • pracovní stanice s OS Windows – Volné místo na disku, využití paměti RAM, verze programu NSClient++ a doba provozu od posledního vypnutí • router D-Link – Pouze funkčnost pomocí utility PING (jedná se o jednoduchý router pro domácnost, který nepodporuje SNMP protokol) Kromě Nagios serveru, kde se jedná o lokální systém, byly všechny služby sledovány pomocí NRPE agenta. Pro sledování systémů s OS Windows byl používán agent NSClient++. Na sledování výše uvedených parametrů byly využity pluginy (v abecedním pořadí): check_apt, check_disk_all, check_dns, check_http, check_load, check_mysql, check_pgsql, check_smtp, check_swap, check_total_procs, check_users, check_zombie_procs.

3.2.3

Plugin scheduledDowntime pro Nagios

Protože se v JVK mimo pracovní dobu vypínají některé části síťové infrastruktury, jako jsou WiFi AP nebo volně přístupné počítače pro uživatele (které bychom rádi sledovali pomocí Nagiosu), bylo by dobré, aby Nagios tato zařízení v tuto dobu nemonitoroval. Nagios funkci na dočasné zrušení kontroly podporuje, ovšem nedokáže tento proces pravidelně opakovat a je tedy nutné odstávku ručně vždy potvrdit. Proto jsem se rozhodl napsat pro tuto činnost plugin, který tuto činnost zautomatizuje. Ve skriptu je nejjednodušší využití externích příkazů pomocí souboru „nagios.cmd“, který je pouze pojmenovaná roura, na které Nagios přijímá externí příkazy. Po sledování chování této roury jsem zjistil, že příkaz pro odstávku serveru musí mít přesně tento formát: 39

3. Implementace [ timestamp ] S C H E D U L E _ H O S T _ D O W N T I M E ; host ; start ; end ; fixed ;\ triggered_host ; duration ; author ; comment

kde timestamp je aktuální čas ve formátu tzv. „Unix epoch“15 , host je jméno serveru, start a end jsou začátek, respektive konec naplánované odstávky ve stejném formátu jako timestamp, fixed je příznak, zda se jedná o fixní nebo flexibilní odstávku, triggered_host značí, která služba tuto odstávku způsobila, duration je maximální délka flexibilní odstávky ve vteřinách, author je jméno autora odstávky a comment je libovolný komentář k odstávce. Pokud bychom chtěli odstavit pouze některou službu, příkaz je téměř stejný, pouze míst textu SCHEDULE_HOST_DOWNTIME je zde text SCHEDULE_SVC_DOWNTIME a za proměnou host je zde ještě název služby. Vstupní parametry a výstupní hodnoty skriptu jsou popsány v tabulce B.1. Skript na automatizování odstávky bude napsán ve skriptovacím jazyku Bash a bude využívat konfigurační soubor, ve kterém budou zapsány hodnoty proměnných ve stejném pořadí, jako je uvedeno výše, ale s několika rozdíly: • první proměnná bude indikovat, zda se jedná o službu nebo celý server • oddělovač nemusí být nutně středník, je možné použít jakýkoliv speciální symbol kromě dvojtečky a pomlčky (a tedy s výjimkou alfanumerických znaků) • čas začátku a startu není zadáván v Unix epoch formátu, ale pomocí lidsky čitelného formátu, tedy yyyy-mm-dd hh:mm:ss oddělený pomocí oddělovače • pokud chceme využívat script automatizovaně, což je účelem scriptu, fixní datum ve formátu velice překáží. Proto lze datum nahradit klíčovým slovem today, které je pak ve scriptu při spuštění převedeno na správné datum. Nedílnou součástí scriptu jsou i defaultní cesty ke konfiguračnímu a nagios.cmd souboru, pokud nejsou specifikovány při spuštění scriptu. S tímto souvisí také testování vstupních souborů – zda soubory existují a máme práva čtení nebo zápisu a také správný formát konfiguračního souboru a dat uvnitř. Script také loguje svou činnost a všechny události zapisuje do vlastního logu. 15

40

jedná se o UTC čas přepočítaný na vteřiny od data 1.1.1970

3.3. Testování Automatické spouštění tohoto scriptu lze vyřešit například pomocí démonu Cron, který bude každý den v určenou hodinu tento script spouštět, čímž se načte konfigurace pro odstávky na daný den.

3.3 3.3.1

Testování Nagios

Obrázek 3.1: Grafické znázornění serverů

Testování celého systému probíhalo simulováním náběhu všech serverů a následným vypnutím některého serveru či jeho služby. 1. zapnutí všech serverů 2. vypnutí serveru postgres 3. vypnutí služby HTTP na serveru mail 41

3. Implementace 4. zapnutí serveru postgres 5. vypnutí routeru dlink (na kterém závisí stroj win7 ) 6. zapnutí služby HTTP na serveru mail 7. zapnutí routeru dlink Zkrácený výstup logu po těchto operacích: [1367891057] SERVICE ALERT : postgres ; All Disks ; CRITICAL ; SOFT ;1; CHECK_NRPE : Socket timeout after 10 seconds . [1367891067] HOST ALERT : postgres ; DOWN ; SOFT ;1; CRITICAL Host Unreachable (192.168.0.14) ... [1367891257] SERVICE ALERT : mail ; HTTP ; CRITICAL ; SOFT ;1; Connection refused [1367891377] SERVICE ALERT : mail ; HTTP ; CRITICAL ; SOFT ;2; Connection refused [1367891427] HOST ALERT : postgres ; DOWN ; HARD ;10; CRITICAL Host Unreachable (192.168.0.14) [1367891427] HOST NOTIFICATION : nagiosadmin ; postgres ; DOWN ; notify - host - by - email ; CRITICAL - Host Unreachable (192.168.0.14) [1367891497] SERVICE ALERT : mail ; HTTP ; CRITICAL ; HARD ;3; Connection refused [1367891497] SERVICE NOTIFICATION : nagiosadmin ; mail ; HTTP ; CRITICAL ; notify - service - by - email ; Connection refused ... [1367891637] HOST ALERT : postgres ; UP ; HARD ;1; PING OK - Packet loss = 0% , RTA = 0.51 ms [1367891637] HOST NOTIFICATION : nagiosadmin ; postgres ; UP ; notify - host - by - email ; PING OK - Packet loss = 0% , RTA = 0.51 ms [1367891717] HOST ALERT : dlink ; DOWN ; SOFT ;1; CRITICAL - Host Unreachable (192.168.0.1) [1367891737] HOST ALERT : win7 ; UNREACHABLE ; SOFT ;1; CRITICAL Host Unreachable (192.168.0.191) ... [1367892297] HOST ALERT : win7 ; UNREACHABLE ; SOFT ;9; CRITICAL Host Unreachable (192.168.0.191) [1367892347] HOST ALERT : dlink ; DOWN ; HARD ;10; CRITICAL - Host Unreachable (192.168.0.1) [1367892347] HOST NOTIFICATION : nagiosadmin ; dlink ; DOWN ; notify - host - by - email ; CRITICAL - Host Unreachable (192.168.0.1) [1367892367] HOST ALERT : win7 ; UNREACHABLE ; HARD ;10; CRITICAL Host Unreachable (192.168.0.191) [1367892407] SERVICE ALERT : mail ; HTTP ; OK ; HARD ;3; HTTP OK : HTTP /1.1 200 OK - 452 bytes in 0.001 second response time

42

3.3. Testování [1367892407] SERVICE NOTIFICATION : nagiosadmin ; mail ; HTTP ; OK ; notify - service - by - email ; HTTP OK : HTTP /1.1 200 OK - 452 bytes in 0.001 second response time [1367892477] HOST ALERT : dlink ; UP ; HARD ;1; PING OK - Packet loss = 0% , RTA = 0.61 ms [1367892477] HOST NOTIFICATION : nagiosadmin ; dlink ; UP ; notify host - by - email ; PING OK - Packet loss = 0% , RTA = 0.61 ms [1367892487] HOST ALERT : win7 ; UP ; HARD ;1; PING OK - Packet loss = 0% , RTA = 0.37 ms

Obrázek 3.2: Tabulka dns a mail serveru a jejich služeb

3.3.2

Plugin scheduledDowntime

Testování pluginu probíhalo pomocí simulování možných různých chyb, ať už chybějící práva nebo špatně zadaný soubor. Testováno bylo v následujícím pořadí: 1. vložen správný formát pro odstávku mail serveru 43

3. Implementace 2. neexistující konfigurační soubor 3. jeden špatný oddělovač (simulující překlep) 4. špatná cesta k nagios.cmd 5. chybějící jeden parametr v konfiguračním souboru Výstup z logu pluginu po těchto operacích: [2013 -05 -07/04:32:53] Host schedule OK ; host = mail ; start =2013 -05 -07/04:30:30; end =2013 -05 -07/04:34:00 [2013 -05 -07/04:33:17] General schedule ERROR ; Path to config file not specified , tried to use default path "/ etc / nagios / sc hedule dDown time . conf " which doesn ’ t exist ( or missing permissions ) [2013 -05 -07/04:33:50] Host schedule ERROR ; Bad format of command . Probably wrong delimiter , using delimiter " ," while getting delimiters " , , , , , , ,; , ," [2013 -05 -07/04:34:24] General schedule ERROR ; The Nagios CMD with path "/ var / nagios / nagios . cmd " doesn ’ t exist or missing permissions [2013 -05 -07/04:34:30] Host schedule ERROR ; Bad format of command . Probably wrong number of parameters .

Výstup z logu Nagiose pro tyto příkazy: [1367893973] EXTERNAL COMMAND : S C H E D U L E _ H O S T _ D O W N T I M E ; mail ; 1 3 6 7 8 9 3 8 3 0 ; 1 3 6 7 8 9 4 0 4 0 ; 1 ; 0 ; 7 2 0 0 ; Schedu ledDo wntime ; Automatic Schedule [1367893974] HOST DOWNTIME ALERT : mail ; STARTED ; Host has entered a period of scheduled downtime [1367894040] HOST DOWNTIME ALERT : mail ; STOPPED ; Host has exited from a period of scheduled downtime

3.4

Další optimalizace síťového provozu

V JVK se nachází celkem 94 veřejné přístupných pracovních stanic pro čtenáře. Pokud bychom chtěli všechny tyto stanice kontrolovat, s ohledem na síťový provoz bych určitě nedoporučoval kontrolu služeb. Za předpokladu, že by kontrola probíhala každých 5 minut, vznikalo by 1128 paketů za hodinu pouze na kontrolu stavu těchto strojů. Pokud bychom kontrolovaly i služby těchto strojů, počet paketů by násobně rostl s počtem narůstajících služeb. Nagios dokáže předcházet tomuto většímu vytížení sítě a to nastavením 44

3.4. Další optimalizace síťového provozu minimálního rozestupu mezi příkazy. Na druhou stranu toto nastavení snižuje četnost příkazů a při nastaveném 5-ti minutovém intervalu, může tento interval být reálně i 7 minut.

45

Závěr Cílem mé práce bylo provést analýzu síťové infrastruktury v Jihočeské vědecké knihovně v Českých Budějovicích, navrhnout vlastní řešení eliminující problémy stávající infrastruktury, srovnat a vyhodnotit toto řešení s řešením navrženým specializovanou firmou, navrhnout a implementovat dohledový systém Nagios a nakonec navrhnout případnou další optimalizaci síťového provozu. V první kapitole své práce jsem zanalyzoval všechny síťové prvky používané v knihovně a přiblížil jejich funkce v JVK. U každé poskytované služby jsem popsal, k čemu je v JVK využívána, popřípadě jak je tato služba omezena a z jakého důvodu. Součástí analýzy je i výběr virtuálního prostředí pro konfiguraci systému Nagios. Toto řešení je výhodné hlavně z toho důvodu, že systém nebude implementován přímo do produkčního prostředí bez testování a tedy se téměř eliminuje možnost chyby. Ve druhé kapitole jsem popsal nedostatky stávajícího řešení síťové infrastruktury v JVK. Navrhl jsem řešení s diskuzí použitých prvků, a tím jsem tyto zjištěné nedostatky eliminoval. Návrh probíhal hlavně s důrazem na co nejmenší vynaložené finanční prostředky, a to jak na pořízení hardwaru, tak i na jeho další provoz (tedy i případné opravy). Na konci kapitoly jsem srovnal a vyhodnotil svůj návrh s návrhem firmy Power System s.r.o., která knihovně dodala také vlastní řešení návrhu. Toto řešení bylo strukturou velmi podobné mému návrhu, přesto v něm figurovaly některé síťové prvky se stejným výkonem, avšak dvojnásobně dražší. Ve třetí a závěrečné kapitole jsem popsal funkci dohledového systému Nagios, základní popis jeho fungování a strukturu jeho konfiguračních souborů. Toto jsem pak využil při vlastní konfiguraci, kdy jsem server nakonfiguroval tak, aby monitoroval testovací servery a jejich služby. Největší síla systému Nagios je v jeho neuvěřitelné škálovatelnosti a zároveň jednodu47

Závěr chosti. Samotný Nagios bez pluginů neobsahuje příliš mnoho funkcí, proto jsem napsal skript pro automatické plánování odstávky jakékoliv služby nebo serveru. Poté bylo třeba celý systém Nagios včetně mého pluginu otestovat, což jsem provedl pomocí simulace různých chybových událostí, které by mohly v reálném provozu nastat a tím jsem ověřil požadované chování celého systému. Nakonec jsem provedl doporučení pro další optimalizaci síťového provozu. Těmito kroky jsem nejen splnil zadání své bakalářské práce, ale také nejdůležitější úlohu své práce – ušetřit JVK nemalé finanční prostředky za pořízení nové infrastruktury, kde můj návrh vyjadřuje optimální poměr mezi využitelností výkonu a cenou za pořízení i provoz síťových prvků. Jako další přínos pro JVK vidím i zjednodušení práce administrátorů. Ti mají celý systém pod dohledem pomocí systému Nagios a mohou případný síťový problém řešit dříve, než je na to upozorní uživatelé. Díky mému pluginu navíc není třeba každý den řešit odstávku zařízení, která se mimo pracovní dobu vypínají, protože Nagios v tuto dobu nebude daná zařízení kontrolovat. Jako možnost pro další vylepšení sítě vidím ve vytvoření nové trasy mezi společnosti CESNET a budovou knihovny Na Sadech. Díky této trasy by vznikl síťový okruh a celá síť by se stala ještě odolnější a bez výskytu jediného bodu selhání.

48

Literatura R Wireless 8760 Dual-Radio 11a/b/g PoE [1] 3Com Corporation: 3Com Access Point. 2007, [online]. [cit. 2013-02-21]. Available at WWW:

[2] APC by Schneider Electric: APC Redundant Switch User’s Manual. [online]. [cit. 2013-03-04]. Available at WWW: [3] APC by Schneider Electric: APC Smart-UPS 2200VA/3000VA 3U Rack Mount Uninterruptible Power Supply 230VAC/120VAC. [online]. [cit. 2013-03-04]. Available at WWW: [4] Axis Communications AB: AXIS 241Q/241S Video Servers Datasheet. 2008, [online]. [cit. 2013-03-04]. Available at WWW: [5] Baldi, M.; Nicoletti, P.: Link Aggregation - IEEE 802.3ad. 2002, [online]. [cit. 2013-04-11]. Available at WWW: <"http:// www.studioreti.it/slide/08_LinkAggr_E_A.pdf"> [6] Cisco Systems, Inc: Policing and Shaping Overview. [online]. [cit. 201304-18]. Available at WWW: <"http://www.cisco.com/en/US/docs/ ios/12_2/qos/configuration/guide/qcfpolsh.html"> [7] Goldberg, R.: Architectural principles for virtual computer systems. Master’s thesis, Hardward University, 1972. 49

Literatura [8] Hangzhou H3C Technologies Co., Ltd: IRF2.0 Technology White Paper. 2010, [online]. [cit. 2013-04-15]. Available at WWW: <"http: //www.h3c.com/portal/Products___Solutions/Technology/IRF/ Technology_White_Paper/200901/624932_57_0.htm"> [9] Hewlett-Packard Development Company, L.P.: HP 5120 EI Switch Series - Data sheet. 2012, [online]. [cit. 2013-04-11]. Available at WWW: [10] Hewlett-Packard Development Company, L.P.: HP 5500 HI Switch Series - Data sheet. 2012, [online]. [cit. 2013-04-11]. Available at WWW: [11] IBM Corporation: Power Systems: Introduction to Virtualization. 2009, [online]. [cit. 2013-03-22]. Available at WWW: <"http://pic.dhe.ibm.com/infocenter/powersys/v3r1m5/topic/ iphb2/iphb2.pdf"> [12] International Technical Support Organization: Introduction to Storage Area Networks and System Networking. 2012, [online]. [cit. 201303-03]. Available at WWW: <www.redbooks.ibm.com/redbooks/pdfs/ sg245470.pdf> [13] HP 24-port SFP v2 zl Module (J9537A) Price chart. [online]. [cit. 201304-03]. Available at WWW: [14] HP E5500-48 (JE100A) Price chart. [online]. [cit. 2013-04-03]. Available at WWW: [15] Jihočeská vědecká knihovna v Českých Budějovicích: Struktura služeb. [online]. [cit. 2013-02-04]. Available at WWW: [16] Ko, T.: The ABC of Direct Attach Cables. BICSI, 2012, [online]. [cit. 2013-04-15]. Available at WWW: <"http://tinyurl.com/ ABCofDAC"> [17] Kollu, R.: Advantages of Chassis based Network Switches. 2012, [online]. [cit. 2013-04-03]. Available at WWW: 50

Literatura [18] Lowe, S.: Mistrovství ve VMware vSphere 4. Brno: Computer Press, a.s., 2010, ISBN 978-80-51-2915-9. [19] Nagios Enterprises: Nagios Core. 2013, [software]. [cit. 2013-04-25]. Available at WWW: [20] NETGEAR Inc.: Small Business Stackable Switch White Paper. 2001, [online]. [cit. 2013-04-01]. Available at WWW: <"http:// kbserver.netgear.com/pdf/FS524Swp_white_paper.pdf"> [21] Oracle Corporation: Oracle VM VirtualBox User Manual. 2013, [online]. [cit. 2013-02-15]. Available at WWW: [22] Strebe, M.: Firewally a proxy-servery: praktický průvodce. Brno: Computer Press, 2003, ISBN 80-7226-983-6. [23] VMware, Inc.: iSCSI SAN Configuration Guide. [online]. [cit. 201303-03]. Available at WWW: <www.vmware.com/pdf/vsphere4/r41/ vsp_41_iscsi_san_cfg.pdf> [24] VMware, Inc.: VMware Workstation 9 Datasheet. 2012, [online]. [cit. 2013-02-15]. Available at WWW: [25] Wi-Fi Alliance: Wi-Fi CERTIFIEDTM n : Longer-Range, FasterR Networks. 2009, [online]. [cit. Throughput , Multimedia-Grade Wi-Fi 2013-02-21]. Available at WWW: [26] Zákon č. 257/2001 Sb. Zákon o knihovnách a podmínkách provozování veřejných knihovnických a informačních služeb (knihovní zákon). [online]. [cit. 2013-02-21]. Available at WWW:

51

Příloha

Seznam použitých zkratek ACL Access control list AES Advanced Encryption Standard AP Access point ARP Address Resolution Protocol DHCP Dynamic Host Configuration Protocol DNS Domain Name System FTP File Transfer Protocol Gbit Gigabit Gbps Gigabits per second GHz Gigahertz GID Group identifier HP Hewlett-Packard HTTP Hypertext Transfer Protocol HTTPS Hypertext Transfer Protocol Secure IEEE Institute of Electrical and Electronics Engineers ICMP Internet Control Message Protocol IMAP Internet Message Access Protocol 53

A

A. Seznam použitých zkratek IMAPS Internet Message Access Protocol Secure IP Internet Protocol IPAC Internet Public Access Catalog IRF Intelligent Resilient Framework iSCSI Internet Small Computer System Interface JVK Jihočeské vědecká knihovna v Českých Budějovicích L2 Layer 2 L3 Layer 3 Mbit megabit Mbps megabits per second MB megabyte MDA Mail Delivery Agent MPEG Moving Picture Experts Group MTA Message Transfer Agent NAT Network address translation NRPE Nagios Remote Plugin Executor OS Operating system OSI Open Systems Interconnection OSPF Open Shortest Path First PAL Phase Alternating Line PIM Protocol Independent Multicast PING Packet Internet Groper PoE Power over Ethernet POP3 Post Office Protocol 3 QoS Quality of Service 54

RAID Redundant Array of Independent Disks RIP Routing Information Protocol RMON Remote Network Monitoring SAN Storage Area Network SCSI Small Computer System Interface SFP Small Form-factor Pluggable SMTP Simple Mail Transfer Protocol SNMP Simple Network Management Protocol SSID Service Set Identifier STP Spanning Tree Protocol TCP Transmission Control Protocol TTL Time to live UID User identifier UPS Uninterruptible Power Supply VLAN Virtual Local Area Network VMFS Virtual Machine File System WFQ Weighted Fair Queuing WPA Wi-Fi Protected Access II WRED Weighted Random Early Detection XOR Exclusive OR

55

Příloha

Seznam tabulek Tabulka B.1: Modul scheduledDowntime.sh

Parametry

0 1 64

scheduledDowntime.sh [-h help] [-n nagios.cmd] [-l logfile] [-d delimeter] Návratové hodnoty Úspěch, odstávka naplánována Neúspěch, špatný formát dat Neúspěch, neexistující cesta k souboru

57

B

Příloha

Obsah přiloženého CD

readme.txt ................................ stručný popis obsahu CD src conf .................. zdrojové kódy konfigurace a pluginu Nagios thesis....................zdrojová forma práce ve formátu LATEX text.....................................................text práce thesis.pdf...........................text práce ve formátu PDF 59

C