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

Monitorování, zálohování a optimalizace středně velké sítě Vratislav Pavel Skořepa

Vedoucí práce: Ing. Viktor Černý

14. května 2014

Poděkování V první řadě bych chtěl poděkovat Ing. Viktorovi Černému za odborné vedení této bakalářské práce, dále specialistům z technického oddělení společnosti Casablanca INT za poskytnuté konzultace a v neposlední řadě své mamince za celoživotní podporu, díky které jsem se dostal až sem.

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 spracová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 14. května 2014

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

České vysoké učení technické v Praze Fakulta informačních technologií c 2014 Vratislav Pavel Skořepa. 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 Skořepa, Vratislav Pavel. Monitorování, zálohování a optimalizace středně velké sítě. Bakalářská práce. Praha: České vysoké učení technické v Praze, Fakulta informačních technologií, 2014.

Abstrakt Tato práce se zabývá návrhem restrukturalizace počítačové sítě s důrazem na odolnost vůči výpadkům zařízení, volbou a následným nasazením do provozu vhodného systému z oblasti otevřeného softwaru pro monitorování sítě a zálohovaní dat, a to s ohledem na omezený rozpočet. Klíčová slova dohled, zálohování, linux, windows, počítačová síť, redundance, sms notifikace

Abstract This thesis deals with a proposal for restructing of a computer network with focus on the fault-tolerant design, a suitable choice of an open source software for network monitoring and data backup, and its deployment within limited budget. Keywords monitoring, backup, linux, windows, computer network, redundancy, sms notification

ix

Obsah Odkaz na tuto práci . . . . . . . . . . . . . . . . . . . . . . . . viii Úvod Cíl práce . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Obsah práce . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1 Analýza 1.1 Síťová infrastruktura . . . . . . . . . . . . . . . . . . 1.1.1 Současná architektura sítě . . . . . . . . . . . 1.1.2 Současná odolnost sítě vůči výpadkům . . . . 1.1.3 Kritické oblasti . . . . . . . . . . . . . . . . . 1.1.4 Plán pro návrh restrukturalizace . . . . . . . 1.1.5 Rizika při vytvoření smyček v síti . . . . . . 1.1.6 Odstraňování síťových smyček . . . . . . . . . 1.1.7 Redundance výchozí brány . . . . . . . . . . 1.2 Dohled sítě . . . . . . . . . . . . . . . . . . . . . . . 1.2.1 Současný aktivní dohled sítě . . . . . . . . . 1.2.2 Plány pro implementaci dohledového systému 1.3 Zálohování dat . . . . . . . . . . . . . . . . . . . . . 1.3.1 Současné řešení zálohování dat . . . . . . . . 1.3.2 Plány pro implementaci zálohovacího systému 1.3.3 Proč zálohovat . . . . . . . . . . . . . . . . . 1.3.4 Typy záloh . . . . . . . . . . . . . . . . . . . 2 Realizace 2.1 Návrh síťové restrukturalizace . . . . . . . . . . 2.1.1 Ideální řešení . . . . . . . . . . . . . . . 2.1.2 Optimalizace při minimálních nákladech 2.2 Nasazení dohledového systému Nagios . . . . . 2.2.1 Stručný popis systému . . . . . . . . . . xi

. . . . .

. . . . .

. . . . .

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

. . . . .

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

. . . . .

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

. . . . .

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

. . . . .

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

. . . . .

1 1 2

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

3 3 3 6 7 7 7 9 10 10 10 11 11 11 11 11 13

. . . . .

15 15 15 17 19 19

2.3

2.2.2 Instalace . . . . . . . . . . . . . . 2.2.3 Po instalaci . . . . . . . . . . . . 2.2.4 Vlastní adresářové struktury . . 2.2.5 Objekty v Nagiosu . . . . . . . . 2.2.6 Konfigurace . . . . . . . . . . . . 2.2.7 Příprava dohledovaných systémů Nasazení zálohovacího systému Bacula . 2.3.1 Stručný popis systému . . . . . . 2.3.2 Architektura systému Bacula . . 2.3.3 Instalace . . . . . . . . . . . . . . 2.3.4 Konfigurace directora . . . . . . 2.3.5 Konfigurace storage démona . . . 2.3.6 Konfigurace file démona . . . . . 2.3.7 Základy ovládání directora . . . 2.3.8 Disaster recovery scénáře . . . .

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

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

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

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

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

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

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

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

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

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

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

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

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

20 21 22 23 29 36 38 38 38 39 40 46 47 48 48

Závěr

51

Literatura

53

A Seznam použitých zkratek

55

B Obsah přiloženého CD

57

xii

Seznam obrázků 1.1

Schéma současné sítě Linky bezpečí . . . . . . . . . . . . . . . . .

4

2.1 2.2 2.3

Schéma návrhu ideálního řešení . . . . . . . . . . . . . . . . . . . . Schéma návrhu restrukturalizace při minimálních nákladech . . . . Schéma souvislostí konfiguračních souborů systému Bacula . . . .

16 18 41

xiii

Seznam tabulek 1.1 1.2 1.3 1.4 1.5 1.6 1.7

Legenda čar pro schéma 1.1 . . Popis zařízení ze schématu 1.1 Switch CISCO 1. část . . . . . Switch CISCO 2. část . . . . . Switch LinkSys . . . . . . . . . Switch Datový analytik . . . . Switch Sociální pracovník . . .

. . . . . . .

. . . . . . .

. . . . . . .

5 5 5 6 6 6 6

2.1

Seznam dostupných OID přes SFSNMP . . . . . . . . . . . . . . .

38

xv

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

Úvod V dnešní době značně vzrostla závislost chodu každé společnosti na její počítačové infrastruktuře. Každý výpadek služeb znamená nejen ztížení či dokonce znemožnění práce placeným zaměstnancům, ale může mít i velmi negativní dopad na jméno firmy z pohledu zákazníků. Ještě horší scénou je ztráta důležitých obchodních dat, která může mít pro firmu i likvidační následky. Z těchto důvodů je dnes tolik kladen důraz na vysokou dostupnost služeb. Každá taková IT infrastruktura musí být odolná vůči výpadkům zařízení, zajišťovat průběžné zálohování dat a v neposlední řadě neustále aktivně monitorovat své důležité zařízení a služby. Čím dříve jsme schopni problém odhalit, tím dříve na něj můžeme reagovat, což se pozitivně projeví na délce výpadku a od ní se odvíjejícího rozsahu dopadu na provoz společnosti. Avšak každá redundance je drahá a pro značnou část firem jsou na trhu nabízené enterprise řešení finančně nedostupné. Tato práce se zabývá renovací a restrukturalizací počítačové sítě s důrazem na odolnost vůči výpadkům zařízení, volbou a následným nasazením do provozu vhodného systému z oblasti otevřeného softwaru pro monitorování sítě a zálohovaní dat, a to s ohledem na omezený rozpočet organizace. Dále za využití vhodného hardwaru bude dohledovému systému umožněno zasílání notifikací formou SMS zpráv, aby bylo možné informovat správce sítě o problému i při nedostupnosti internetové konektivity.

Cíl práce Cílem této práce je navrhnout finančně dostupné řešení současných nedostaků počítačové infrastruktury v neziskové organizaci. Nejdříve bude nutné vytvořit dokumentaci této sítě, jelikož síť je již několik let v provozu a původní architekt již ve společnosti nepracuje a při stavbě sítě nebyla vytvořena dokumentace. Po důkladném zdokumentování budou navrhnuty dvě různé varianty restrukturalizace sítě. První verze bude navržena bez ohledu na finanční stránku. 1

Úvod Bude to ideální řešení sítě tak, jak by měla dnešní moderní odolná síť vypadat. Ve druhé verzi bude, po konzultaci s místním správcem sítě, navržena síť taková, aby zajišťovala redundantní linky pro kritické části infrastruktury při zachování minimálních nákladů pro nákup nových síťových prvků. Následně bude pro současnou infrastrukturu naimplementován aktivní dohledový systém, který bude sledovat požadovaná zařízení v síti a podle závažnosti problému bude notifikovat správce formou e-mailu nebo sms. Na závěr bude nasazen zálohovací systém, který umožní vytváření inkrementálních záloh v režimu klient - server, a to pro servery na platformách Linux i Windows. Která zařízení budou pravidelně zálohována bude opět konzultováno s místním správcem sítě. Tyto zálohy budou umožňovat v případě výpadku rychlou obnovu serveru na jiném hardwaru.

Obsah práce Nejprve bude nutné provést zdokumentování současné síťové infrastruktury a lokalizování jejích kritických částí. Poté bude nutné najít kompromis mezi velikostí investice a schopností zachování funkčnosti v případě nedostupnosti některého zařízení. Dalším krokem bude nasazení dohledového systému Nagios. Popsány budou všechny kroky nutné k jeho zprovoznění od instalace až po volání vlastních skriptů a zasílání SMS přes připojenou SMS bránu. Následně bude implementován zálohovací systém Bacula, který umožňuje centralizované zálohovaní dat, jelikož pracuje v režimu server - klient. Kromě popisu instalace jak na straně serveru, tak i na straně klienta (pro Linux i Windows), práce také zahrnuje vzorové disaster recovery scénáře s popisem jednotlivých kroků obnovy dat.

2

Kapitola

Analýza 1.1 1.1.1

Síťová infrastruktura Současná architektura sítě

Současná počítačová síť je v provozu již několik let a za dobu její existence této neziskové organizace se vystřídalo několik administrátorů. Její dokumentace byla minimální a z velké části již neaktuální, tudíž prvním nutným krokem bylo zmapovat aktuální stav.

1.1.1.1

Průběh mapování současné sítě

Jelikož tato nezisková společnost provozuje krizovou telefonní linku a je tudíž v provozu neustále, tak nebylo možné vygenerovat plánovaný výpadek ani v nočních hodinách. Z tohoto důvodu nebylo možné projít celou síť najednou. Další komplikací bylo vedení většiny kabelových rozvodů v podhledech a stěnách, protože tyto rozvody nebyly řádně označeny. Mapování sítě bylo prováděno postupným odpojováním jednotlivých koncových stanic ve dvou lidech za užití mobilní telefonické komunikace tak, aby se minimalizovala doba výpadku. Výsledkem bylo vytvoření diagramu sítě a přesného popisu jednotlivých portů na každém ze switchů ve formě tabulky s číslem fyzického portu, číselným označením zásuvky a slovním popisem zařízení, které je v současné době na portu aktivní.

1.1.1.2

Diagram sítě

Na následujícím schématu 1.1 je znázorněna současná struktura celé sítě organizace Linka bezpečí. Podrobnější popis znázorněných zařízení najdeme v tabulce 1.2. 3

1

1. Analýza

Obrázek 1.1: Schéma současné sítě Linky bezpečí

4

1.1. Síťová infrastruktura Plná čára Lomená čára Přerušovaná čára

Ethernetová linka DSL nebo ISDN linka Napájení z UPS

Tabulka 1.1: Legenda čar pro schéma 1.1

Označení GW+FW VGW SW-Linksys SW-NetGear SW-Analytik SW-Eko. odd. SW-Soc. prac. Siemens PBX CUCM01,02 Server Bacula Nagios WD NAS AP-Zyxel AP-TP Link HP LJ 4700 Xerox WC 245

Typ zařízení Windows server 2003 Cisco série 2800 s E1 kartou Linksys SR216 Netgear GS108GE neznámý TP Link neznámý Digitálně analogová ústředna Cisco UCS C220 M3BE Windows server 2003 Debian Wheezy x86 Debian Wheezy x86 WD Shared Storage Zyxel G570U TP Link HP Color LaserJet 4700 Xerox Workcentre Pro 245

Popis Výchozí brána do Internetu a firewall Výchozí brána pro hlasové služby Přepínač bez managementu Přepínač v racku bez managementu Přepínač bez managementu Přepínač bez managementu Přepínač bez managementu Ústředna pro analogové telefony Dvě VoIP ústředny pracující v klastru Hlavní server pro web a SQL Zálohovací server Dohledový server Hlavní datové úložiště AP pro WiFi ve 2. podlaží AP pro WiFi v přízemí Síťová tiskárna Síťová tiskárna

Tabulka 1.2: Popis zařízení ze schématu 1.1

1.1.1.3

Tabulky jednotlivých portů

PORT SOCKET POPIS PORT SOCKET POPIS

1 "N1" Server link 2 2 Spoj. 3

3 3 Stůl 9 4 "Chat" Stůl 8

5 8 Stůl 7 6 <–> Spoj. 1

7 14 Spoj. 2 8 18 Stůl 6

9 20 Stůl 5 10 22 Stůl 4

11 24 Stůl 3 12 26 Stůl 2

Tabulka 1.3: Switch CISCO 1. část 5

1. Analýza PORT SOCKET POPIS PORT SOCKET POPIS

13 28 Stůl 1 14 "N2" SW-NG

15 — — 16 1S SW-Anal

17 <–> VGW1 18 <–> UPS

19 <–> CUCM1 20 <–> CUCM2

21 <–> CUCM1-M 22 <–> CUCM2-M

23 "N3" GW+FW 24 <–> SW-LSys

Tabulka 1.4: Switch CISCO 2. část

PORT SOCKET POPIS PORT SOCKET POPIS

1 — — 9 — —

2 #?-P HR-vz. 10 — —

3 #?-P Řed. 11 63-P HR

4 76-P SW-Eko 12 72-P Eko. odd.

5 30 SW-Soc 13 <–> Tisk. HP

6 — — 14 <–> Debr.

7 — — 15 — —

8 <–> AP-Zyxel 16 <–> SW-CISCO

Tabulka 1.5: Switch LinkSys

PORT SOCKET POPIS

1 1S SW-CISCO

2 <–> PC Analytik

3 <–> PC Psych.

4 <–> WD NAS

5 <–> Test

Tabulka 1.6: Switch Datový analytik

PORT SOCKET POPIS

1 30 SW-LSys

2 <–> Ved. LB

3 <–> Org. pers. prac.

4 <–> Ved. online služeb

Tabulka 1.7: Switch Sociální pracovník

1.1.2

Současná odolnost sítě vůči výpadkům

I přes vysoké požadavky na dostupnost služeb, není současný návrh sítě ideální. Společnost disponuje jen jednou Internetovou konektivitou, a to formou vytáčeného ADSL PPPoE připojení. Telefonní hovory jsou přivedeny přes E11 linku a následně se v routeru dělí mezi VoIP a standardní digitální ústřednu. V síti není, kromě páru VoIP ústředen, zavedená aktivní redundance, která by v případě selhání jednoho z kritických zařízení umožňovala automatické přesměrování toku dat na záložní zařízení nebo linku. 1 E1 nebo ISDN30 je linka o přenosové kapacitě 2048 kbit/s, která umožňuje současně přenášet až 30 telefonních kanálů.

6

1.1. Síťová infrastruktura Ochrana vůči výpadku páteřních zařízení (v našem případě se jedná o zařízení VGW a SW-CISCO viz schéma 1.1) je zde řešena souběžným provozem dvou identických zařízení se shodnou konfigurací. Do sítě je vždy připojeno jen jedno z těchto redundantních zařízení, tudíž v případě výpadku je nutný zásah technika či jiného informovaného zaměstnance, který musí ručně každý kabel přepojit do stejného portu záložního zařízení.

1.1.3

Kritické oblasti

Pro tuto společnost je kritické zajistit neustálý chod alespoň části telefonních linek v jejím call centru2 Díky tomu, že jsou veškeré hlasové služby vedeny přes E1 linku, tak nejsou závislé na kvalitě a dostupnosti internetové konektivity. Využívané ústředny jsou nakonfigurovány, aby v případě nedostupnosti telefonu hovor směrovali na jednu ze spojovatelek, případně jinou přímou linku. Tudíž je nutné zajistit zachování lokální konektivity k jedné z ústředen a současně mít v provozu alespoň jednu z linek pro spojovatelky. Výpadek Internetové konektivity znemožňuje práci z domova externím pracovníkům, ale pro chod firmy to není kritické.

1.1.4

Plán pro návrh restrukturalizace

Při návrhu restrukturalizace sítě se budu snažit využít aktivně oba redundantní prvky tak, aby nebyl nutný manuální zásah pracovníka v případě jejich výpadku. V tomto návrhu bude zahrnuto i zajištění redundatní Internetové konektivity, aby zůstal zachován přístup na firemní servery pro externí pracovníky a v případě nutnosti bylo možné provádět nezbytné konfigurační úpravy na síťových prvcích pomocí vzdáleného přístupu.

1.1.5

Rizika při vytvoření smyček v síti

Zapojení redundantního zařízení či cesty v přepínané síti je příčinou vzniku smyček. Tyto smyčky mohou způsobit zacyklení komunikace, a tím zcela zahltit využívané síťové prvky, které pak nejsou schopny zpracovávat regulérní komunikaci a síť se stává nepoužitelnou. Pokud k tomuto problému dojde, tak je nezbytné tyto smyčky fyzicky rozpojit a zavést opatření, která předcházejí vzniku těchto zacyklení. 2 Call centrum je organizační jednotka, která slouží k hromadnému zpracování příchozícha odchozích telefonních hovorů.

7

1. Analýza 1.1.5.1

Nestabilita databáze MAC adres3

K tomuto jevu dochází, pokud jedno zařízení odešle broadcastem4 zprávu přes síťové přepínače, mezi nimiž existuje smyčka. Přepínače si evidují MAC adresu odesílatele z příchozích rámců do své CAM tabulky, díky které pak mohou unicastovou5 komunikaci přeposílat pouze na port, na kterém je cílové zařízení připojeno[6]. Představme si jednoduchou topologii, kde jsou tři přepínače zapojeny do trojúhelníku a na jednom z nich je připojen počítač, který do sítě vyšle broadcast. Přepínač, ke kterému je počítač připojen, obrží rámec, do MAC tabulky si uloží fyzickou adresu počítače a číslo portu, na kterém rámec obdržel. Poté zprávu přepošle na všechny aktivní porty s vyjimkou zdrojového. Zbývající přepínače obrží rámec a stejně jako první přepínač si upraví záznam v MAC tabulce. Do této chvíle bylo vše v pořádku, problém nastává až ve chvíli, kdy se rámec začne cyklit ve smyčce. Přepínače tuto zacyklenou duplicitní zprávu obdrží znovu na jiném portu, avšak stále se stejnou zdrojovou MAC adresou počítače, který původně tuto zprávu vygeneroval. Provedou tedy náležitou úpravu své MAC tabulky, takže přepínač má v tuto chvíli počítač svázán s nesprávným portem. K těmto nevyžádáným změnám v MAC tabulce dochází opakovaně s každým průchodem zprávy smyčkou. To má za následek nekorektní přeposílání unicastových rámců pro postižený počítač a ten se tak stává nedostupným. 1.1.5.2

Broadcast storm

Pokud přepínač obdrží broadcast rámec, tak jej rozešle na veškeré své aktivní porty, kromě portu ze kterého rámec obdržel. Tudíž, pokud se v síti vyskytují smyčky mezi přepínači, tak dojde k nekonečnému zacyklení tohoto rámce. Toto chování může mít za následek úplné zahlcení sítě. 1.1.5.3

Duplikace unicast rámců

K duplikaci unicast rámců dochází ve chvíli, kdy v síti obsahující smyčky chceme poslat zprávu konkrétnímu příjemci, ale některé přepínače ještě nemají ve své MAC tabulce záznam o cílovém zařízení. Pokud přepínač neví, na který port má rámec směrovat, tak jej rozešle podobně jako broadcast na všechny ostatní porty[6]. Představme si opět jednoduchou topologii tří přepínačů zapojených do trojúhelníku. Na jednom z nich je připojen odesílatel a na jednom ze zbývají3 MAC adresa neboli fyzická adresa zařízení je unikátní označení síťového rozhranní, které je na trvalo přiděleno jeho výrobcem. V sítích se využívá jako adresa pro komunikaci na linkové vrstvě. 4 Broadcast je typ zprávy, která je rozeslána všem zařízením v podsíti odesílatele. 5 Unicast je typ zprávy, která je určena pouze jednomu konkrétnímu příjemci.

8

1.1. Síťová infrastruktura cích dvou je připojen požadovaný příjemce. Záznam o cílovém zařízení v MAC tabulce má pouze přepínač, ke kterému je příjemce připojen. Odesílatel vyšle zprávu, nejbližší přepínač ji obdrží a přepošle na všechny porty kromě zdrojového. Jeden rámec tak obdrží přepínač, ke kterému je příjemce připojen, a ten jej již korektně směřuje na port, kde se nachází cílové zařízení. Druhý rámec však obdrží zbývající přepínač, který rovněž provede rozeslání na všechny porty vyjma zdrojového. Tím se zduplikovaný rámec dostane k přepínači příjemce, ze kterého je přeposlán cílovému zařízení. Tím bylo způsobeno, že příjemce obdržel identickou zprávu dvakrát. Tento problém není tolik závažný jako nestabilita databáze MAC adres nebo broadcast storm, protože drtivá většina protokolů vyšších vrstev je schopna tyto duplicitní zprávy detekovat, avšak veškerý zbytečný datový tok je v síti nežádoucí.

1.1.6 1.1.6.1

Odstraňování síťových smyček Ether channel

Ether channel je agregační technologie síťových linek, která se využívá v situaci, kdy potřebujeme dvě zařízení propojit současně několika fyzickými linkami. Ether channel z nich vytvoří jeden logický kanál, který zajišťuje nejen odolnost vůči výpadku některé z fyzických linek, ale navíc umožňuje využít celkovou propustnost všech fyzických kanalů současně.

1.1.6.2

Spanning-Tree Protocol

Spanning-Tree Protocol (dále jen STP) je algoritmus popsaný ve standardu IEEE 802.1D[15], který zabraňuje vzniku logických smyček mezi přepínači. Jednotlivé přepínače mezi sebou komunikují pomocí takzvaných BPDU zpráv. S jejich pomocí si sestaví současnou topologii sítě a zvolí porty, které budou blokovány tak, aby v síti existovala pouze jedna logická cesta. Pokud je port blokován, tak přes něj neprochází žádná komunikace dovnitř ani ven, vyjma BPDU zpráv. Pokud dojde ke změně v topologii sítě, například při náhlé nedostupnosti jednoho z přepínáčů, tak jsou provedeny potřebné změny v blokaci portů, aby zůstala v síti zachována jedna logická cesta. Současně jsou o této skutečnosti informováni všechny přepínače, protože je nutné snížit dobu udržování záznamů adres v MAC tabulce ze standardních 300 na 15 sekund. Díky tomu dochází k jejich rychlejší aktualizaci vzhledem ke změnám v síti, což je pro korektní směrování komunikace kritické. Doba síťové konvergence se liší podle implementace STP[7]. 9

1. Analýza 1.1.6.3

Stohovatelná zařízení

Spojení několika redundantních zařízení do jednoho logického celku, který se chová jako jeden síťový prvek, je posledním trendem v sítích s požadavkem na vysokou dostupnost. Tato technologie zatím nebyla standardizována a výrobci, kteří takovéto síťové prvky nabízí (například CISCO „Virtual switching system“ nebo Juniper „Virtual chassis“), mají vlastní proprietální řešení. Z fyzického hlediska se jedná o dvě nebo více vzájemně kompatibilní zařízení propojená speciálním kabelem. Pokud chceme zajistit odolnost vůči výpadku jednoho z fyzických zařízení, tak se síťová konektivita s dalšími prvky zajišťuje pomocí nejméně dvou linek agregovaných do ether channelu. Tyto agregované linky musí být fyzicky zapojeny alespoň do dvou z takto propojených zařízení. Výhodou tohoto řešení je, že není nutné v síti nasazovat Spanning-Tree Protocol. Tudíž v případě výpadku jednoho ze zařízení nebo linek, je síť nadále dostupná bez ztráty jediného packetu, protože není třeba čekat na její konvergenci.

1.1.7 1.1.7.1

Redundance výchozí brány Virtual Router Redundancy Protocol

Virtual Router Redundancy Protocol (dále jen VRRP) je neproprietální protokol umožňující redundanci na takzvaném prvním skoku. Využívá se, pokud máme v síti současně zapojeny dva nebo více směrovačů, které chceme využít jako výchozí bod pro přístup do jiné sítě (například Internetu). Směrovače provozované pod VRRP využívají společnou virtuální IP a MAC adresu. Aktivní je vždy jen jeden z fyzických směrovačů, zbývající zařízení jsou v pohotovosti jako záložní, kdyby se aktivní router stal nedostupným. Přepínání mezi těmito stavy řeší VRRP automaticky bez nutnosti zásahu administrátora[6].

1.2 1.2.1

Dohled sítě Současný aktivní dohled sítě

V současné chvíli je jediným aktivním dohledem počítačové sítě zasílání automatických e-mailových notifikací v případě výpadku napájení jednotkou UPS. Avšak výchozí brána nemá kvůli nízké kapacitě UPS zálohované napájení, tudíž se tyto notifikace ke správci sítě dostanou až po obnovení dodávky elektrické energie. 10

1.3. Zálohování dat

1.2.2

Plány pro implementaci dohledového systému

Nový dohledový systém bude schopen aktivně monitorovat nejen požadované síťové prvky, ale i přímo specifické služby, které na nich budou provozovány. Navíc bude umožňovat zasílání SMS přes připojenou GSM bránu, aby bylo možné upozornit administrátora na případné problémy i při nedostupnosti internetové konektivity.

1.3 1.3.1

Zálohování dat Současné řešení zálohování dat

Zálohování důležitých dat v současné chvíli zajišťuje zálohovací systém Cobian Backup[8]. Tento systém lze považovat za spolehlivý, ale má některé nedostatky. V současné době jsou firemní servery provozovány na platformě Windows Server, ale s plánovaným rozšířením infrastruktury bude nutné zálohovat i Linuxové servery, což současný systém neumožňuje. Další komplikací je zálohování databází. Cobian neumí nativně spolupracovat s databázemi, proto se jejich zálohování provádí pomocí naplánované úlohy, která zajistí export databáze do souboru, který je následně zazálohován. Avšak pokud z nějakého důvodu export databáze selže, tak se o tom zálohovací systém není schopen dozvědět. V neposlední řadě je nevhodné tento systém nasazovat do větší infrastruktury, protože neumožňuje centralizovanou správu záloh v režimu klient-server. Obnova dat po havárii některého ze zálohovaných zařízení není řešena ideálně, protože je nutné nejdříve nainstalovat „prázný“ systém, do něhož jsou poté obnovena ztracená data.

1.3.2

Plány pro implementaci zálohovacího systému

Nově nasazený zálohovací systém bude umožňovat centralizovanou správu záloh v režimu klient-server. Serverová část podporuje pouze platformu Linux, avšak klientem může být provozován pod operačním systémem na bázi Windows i Linux. Bude schopen schopen spouštět skripty před nebo po provedení zálohy, jako je například export databáze, a v případě problémů korektně reagovat. Jelikož společnost v současné době nedisponuje redundantním hardwarem pro své servery, bude systém zvolen tak, aby obnova na jiném fyzickém zařízení byla co možná nejrychlejší.

1.3.3

Proč zálohovat

Proč zálohovat? Jednoduchá odpověď zní: abychom nepřišli o důležitá data. Je avšak důležité zamyslet se i nad důvody, proč data můžeme ztratit. 11

1. Analýza 1.3.3.1

Chyba uživatele nebo administrátora

Omylem smazaný, přepsaný či jen chybně upravený soubor je nejčastějším důvodem, proč dochází k obnově dat. I když to není na první pohled katastrofální scénář, tak takováto situace může mít velký dopad na provoz společnosti. Soubor mohl například obsahovat data sdílená mezi velkou skupinou zaměstnanců, kteří jej potřebují ke své práci. Ještě horší variantou je, pokud se takové chyby dopustí administrátor (například nedostatečně odladěným skriptem) a dojde k poškození systémových souborů, což může mít za následek nedostupnost některých služeb. K těmto problémům dochází v pracovních hodinách a obnova dat proto musí být rychlá. Kvůli záchraně jednoho souboru není vhodné provádět obnovu celého disku, jelikož kromě délky této operace by došlo i k nadměrnému zatížení sítě a s tím spojenou sníženou kvalitou služeb. 1.3.3.2

Selhání disků

Pevné disky jsou nejporuchovější komponentou dnešních počítačů. Kromě udržování záložní kopie na jiném fyzickém disku je vhodné mít na důležitých serverech disky spojené do pole, které dokáže odolat výpadku některého z disků. Popíšeme si ty nejběžněji používané. RAID 1 Toto pole se nazývá zrcadlem, jelikož udržuje zcela totožná data na dvou nebo více fyzických discích. Je odolné vůči výpadku N-1 disků, kde N je celkový počet disků v poli. Efektivní kapacita je rovna kapacitě nejmenšího z disků. RAID 5 U tohoto typu pole se používá k ochraně dat výpočet parity, která se rovnoměrně ukládá mezi všechny disky v poli. Díky tomu je pole odolné vůči výpadku jednoho disku, avšak při provozu v degradovaném6 stavu je nutné data při čtení dopočítávat z parity, což snižuje rychlost čtení. Efektivní kapacita je 1-1/N, kde N je celkový počet disků v poli. RAID 6 RAID 6 je odolnější verze RAIDu 5. K ochraně dat využívá jejich dvojitou paritu, rovnoměrně rozdělenou mezi všechny disky tak, aby se nikdy obě parity nenacházely na stejném fyzickém disku. Díky tomu je pole odolné vůči výpadku dvou disků, ale jeho efektivní kapacita je pouze 1-2/N, kde N je celkový počet disků v poli. 6

RAID pole se dostává do degradovaného stavu, pokud došlo k výpadku jednoho nebo více disků a současně je pole ještě schopné tuto ztrátu kompenzovat. I když pole zůstává stále dostupné, může dojít ke zhoršení rychlosti zápisu či čtení.

12

1.3. Zálohování dat 1.3.3.3

Selhání hardwaru

Je důležité nezaměňovat tuto příčinu s výpadkem disku. I když máme plně funkční disky v poli, může dojít ke ztrátě dat. Nejčastější příčinou bývá selhání diskového řadiče. Toto je velmi zrádný problém, protože v případě vadného disku dojde k jeho vyřazení z pole a notifikaci administrátora, ale selhání řadiče si většinou všimneme až ve chvíli, kdy jsou data na discích nenávratně poškozena. I když řadič pouze přestane korektně pracovat a data jsou nepoškozena, bývá problémem sehnat řadič stejný nebo kompatibilní, abychom data mohli znovu přečíst. Toto se stává zejména u starších zařízení nebo zařízení menších výrobců. 1.3.3.4

Přírodní katastrofy, havárie

Někteří lidé tuto příčinu zanedbávají, protože zrovna nežijí v oblasti častých výskytů zemětřesení, ale je nutné si uvědomit, že i požár nebo jen prasklina ve vodovodním potrubí může mít pro naše data stejné následky. Geograficky oddělené zálohy kritických dat jsou proto velice důležité. Pokud si plánujete pořídit externí zálohu v jiné lokalitě, tak nezapomínejte, že data je také nezbytné obnovit, proto je nutné takovou lokalitu vhodně zvolit. Měla by se nacházet dostatečně daleko, aby ji nezasáhly lokální nehody jako je výbuch plynu či výpadek napájení a současně v dostupném dosahu, abychom se k datům v případě potřeby dostatecně rychle dostali, protože obnovovat stovky gigabytů dat po Internetu může trvat několik dní. Pokud si nemůžeme dovolit aktivní replikaci dat, je vhodné alespoň provést občasnou kopii dat na externí disk a ten uložit na bezpečném místě. 1.3.3.5

Napadení systému vnějším útočníkem

I pokud nepracujeme v drsném konkurenčním prostředí, nesmíme opomenout možnost napadení našeho systému virem, automatem či náhodným hackerem7 „pro zábavu“. Rizikem tohoto útoku je, že s jistotou nevíme, co přesně se s našimi daty stalo. Navíc se o napadení často dozvíme až se značným časovým zpožděním. Proto je vhodné uchovávat si i starší zálohy.

1.3.4

Typy záloh

Abychom ušetřili diskovou kapacitu a urychlili průběh záloh (u velkých systémů může plná záloha probíhat i několik dní), využíváme takzvaných rozdílových (chytrých) záloh, které nám umožňují zálohovat pouze data, která se změnila od poslední zálohy. 7

Uživatel PC snažící se přes počítačové sítě proniknout do cizích systémů

13

1. Analýza 1.3.4.1

Popis jednotlivých typů záloh[21]

Níže jsou uvedeny jednotlivé úrovně záloh. Toto názvosloví se může občas lišit. Úplná/Úroveň 0 Kompletní záloha všech dat, využitelná samostatně. Úroveň 1 Inkrementální záloha všech změněných dat od poslední úplné zálohy. Pokud tuto zálohu opakujeme, vždy je vytvořena záloha všech dat od poslední úplné zálohy. Úroveň 2-9 Každá z těchto úrovní provádí zálohu dat, která byla pozměněna od poslední existující zálohy nejbližší nižší úrovně. U některých zálohovacích systémů se při opakování zálohy 9. úrovně zálohují pouze data, změněná od poslední zálohy 9. úrovně, ale toto řešení není příliš universální. Inkrementální Nejčastěji pod tímto názvem uvádíme rozdílové zálohy vůči poslední vytvořené (úplné nebo rozdílové) záloze. Diferenciální Většinou pod tímto názvem rozumíme rozdílovou zálohu vůči poslední provedené úplné záloze, avšak to není vždy úplně přesné. Ve Windows diferenciální zálohy nenulují příznakový bit archivovat. Tudíž, pokud vytvoříme úplnou zálohu a po ní několik diferenciálních záloh, tak vše funguje jako u klasických diferenciálních záloh. Avšak pokud ve Windows proběhne byť jen jediná inkrementální záloha, tak dojde k vynulování příznakového bitu archivovat a následující diferenciální záloha bude zálohovat jen data, která se změnila od poslední inkrementální zálohy. Proto nelze považovat diferenciální zálohu za synonymum pro zálohu úrovně 1. Souhrnná inkrementální Tento termín preferuji před diferenciální, znamená vytvoření zálohy, která zálohuje veškerá data, která se změnila od poslední úplné zálohy.

14

Kapitola

Realizace 2.1

Návrh síťové restrukturalizace

I když by měl tento návrh optimalizace sítě být vytvořen s důrazem na minimalizaci nákladů, rozhodl jsem se začít nejdříve od ideálního řešení, kde finanční stránka nebude brána v potaz. Díky tomu bude možné ekonomické řešení kvalitativně porovnat a zjistit jeho případné nedostatky. Ve schématech jsem pro přehlednost vypustil některá koncová zařízení. Obecně platí, že veškerá koncová zařízení budou připojena k přístupovým přepínačům.

2.1.1

Ideální řešení

Ve schématu 2.1.1 můžeme vidět, že pro ideální řešení je nutné zajistit redundantní internetovou a E1 konektivitu. Vzhledem k tomu, že směrování si budeme spravovat sami, není nutné mít obě internetové konektivity od stejného poskytovatele. Pro zapojení redundantních routerů je vhodné, aby nám byla internetová konektivita předána na dvou fyzických portech, v opačném případě musíme předřadit přepínač, který nám zajistí její rozdělení. Avšak u telefonních E1 linek je situace komplikovanější. V případě výpadku jedné z E1 linek je nezbytné, aby poskytovatel provedl přesměrování telefonních hovorů do záložní, není technicky možné provést tuto změnu směrování ze strany odběratele služeb. Proto musíme zvolit poskytovatele, který nám je schopen tuto službu zajistit. Architekturu sítě jsem zvolil typu „Collapsed core8 “ při využití dvou L3 přepínačů spojených do jednoho virtuálního přepínače. Pro toto schéma jsem využil CISCO technologii „Virtual Switching System“, ale je možné sáhnout po obdobné technologii levnějších výrobců (například Juniper „Virtual Chassis“). 8 Collapsed core je dvouvrstvá síťová architektura, kde jsou páteřní a distribuční vrstvy spojeny.

15

2

2. Realizace

Obrázek 2.1: Schéma návrhu ideálního řešení

Mezi směrovači bude nasazen Virtual Router Redundancy Protokol, který zajistí, že v případě výpadku primárního směrovače dojde k automatickému přepnutí na záložní a nejdojde k omezení přístupu do Internetu z vnitřní sítě. Jak si můžeme všimnout, přepínače a směrovače jsou mezi sebou propojeny 16

2.1. Návrh síťové restrukturalizace s využitím EtherChannelu, čímž jsme získali nejen redundantní fyzické linky, ale i dvojnásobnou přenosovou kapacitu. Telefonní linky jsou rozděleny mezi dva přístupové přepínače, tudíž v případě selhání jednoho z nic zůstane polovina call centra plně funkční. 2.1.1.1

Nedostatky

Tento návrh infrastruktury využívá poslední trendy v síťových technologiích, je velice robustní, avšak finančně velmi nákladný. Mezi jeho nedostatky bych uvedl jen jednu linku ke každému ze serverů, protože nedisponují redundantními síťovými kartami, avšak krátkodobý výpadek serverů není tolik kritický jako výpadek hovorů v call centru. Stejný problém se vyskytuje i u staré digitálně-analogové ústředny označené jako „Siemens PBX“, přes kterou jsou směrovány hovory do jednotlivých kanceláří. 2.1.1.2

Potřebná zařízení

Směrovače nám postačí stávající, stačí pouze do každého z nich dokoupit kartu s dvěma ethernetovými porty. Současné Cisco PoE přepínače využijeme na přístupové vrstvě pro call centrum. Pro páteřní vrstvu musíme zakoupit dva přepínače série Cisco Catalyst 6500 a pro rack jeden přístupový switch s podporou EtherChannelu, například Cisco Catalyst série 2960.

2.1.2

Optimalizace při minimálních nákladech

Při minimalizaci nákladů se pokusím maximálně využít všechna dostupná zařízení a současně ze sítě odstranit přebytečné aktivní prvky, jelikož jsou nejčastější příčinou výpadku sítě. Protože si společnost nemůže dovolit neustále platit za dvě internetové konektivity, navrhl jsem řešení se zálohou přes 3G modem. Dnes už jsou na trhu k dispozici jednodenní tarify, které se aktivují pomocí zaslání speciální SMS, a tudíž není nutné za konektivitu platit, pokud ji nevyužíváme. Dokonce tuto aktivaci lze provést automaticky za využití 3G routeru od výrobce MikroTik, který umožňuje vytvářet a automaticky spouštět vlastní skripty. Vzhledem k vyšším nákladům, není v tomto návrhu zahrnuta záložní fyzická E1 linka, takže pokud dojde k výpadku primární linky ze strany poskytovatele, nebude možné se do call centra dovolat. Abychom se alespoň vyhnuli výpadku hovorů z důvodu selhání jednoho ze směrovačů, je E1 linka rozdělena pomocí failover9 přepínače mezi oba aktivní směrovače. Tento speciální přepínač měří kvalitu linky a v případě zjištění problému ji okamžitě přesměruje na záložní port. Vždy je tedy aktivní jen jedna z takto rozdělených linek. 9

Převzetí služeb při selhání.

17

2. Realizace

Obrázek 2.2: Schéma návrhu restrukturalizace při minimálních nákladech

Přepínače mezi sebou budou propojeny EtherChannelem, přes který povede trunk pro telefonní a počítačovou vlan. Na každém z nich budou vytvořena dvě virtuální vlan rozhranní, jedno pro každou ze zmíněných vlan. V každém páru rozhraní ve stejné vlan bude spuštěna jedna instance VRRP 18

2.2. Nasazení dohledového systému Nagios protokolu, čímž bude možné přidělovat adresy od DHCP serveru tak, jako by se jednalo o jednu síť. Rozhraní ke směrovačům budou pracovat na síťové vrstvě. Takto navržená počítačová síť umožňuje ošetření redundantních cest OSPF protokolem, čímž se vyhneme čekání na konvergenci spanning-tree protokolu. 2.1.2.1

Nedostatky

Tato navržená infrastruktura je schopna v případě výpadku některého zařízení obnovit alespoň částečnou dostupnost sítě bez zásahu administrátora. Oproti ideálnímu řešení však tato obnova zabere několik vteřin, během kterých může dojít k rozpadům telefonních hovorů. Záložní konektivita přes 3G bude mít omezenou kapacitu a bude spíše sloužit k akutnímu vzdálenému přístupu než jako plnohodnotná linka. Navíc máme k dispozici pouze jednu fyzickou telefonní E1 linku, takže v případě jejího výpadku nebude možné telefonovat. Síť je rozdělena pouze na dvě velké domény, z toho důvodu bude v případě selhání jednoho z přepínačů postihnuta velká část koncových zařízení. Vždy však zůstane v provozu polovina call centra, což je hlavním kritériem. Samozřejmě i tady stále přetrvává problém s neredundantní linkou pro ústřednu „Siemens PBX“ a firemní servery. 2.1.2.2

Potřebná zařízení

I tady si vystačíme se stávajícími, již vlastněnými směrovači, tentokrát nám stačí dokoupit jednoportovou ethernetovou kartu do každého z nich. V tomto návrhu dokonce ani není nutné kupovat další přepínače, ale pokud bychom chtěli síť rozdělit na více domén, není problém ještě další přepínače přidat. Pokud se rozhodneme pro záložní internetovou konektivitu formou 3G připojení, tak je nejvhodnejším zařízením MikroTik RB411U, který má integrovaný 3G modem a má rozshálé možnosti konfigurace včetně skriptování, které můžeme využít pro automatickou aktivaci internetu. Výběr vhodného failover přepínače pro E1 linku doporučuji nejdříve konzultovat s poskytovatelem hlasových služeb.

2.2 2.2.1

Nasazení dohledového systému Nagios Stručný popis systému

Projekt Nagios[13] je komplexní enterprise řešení dohledu sítě a síťových služeb v oblasti otevřeného softwaru na platformě Linux. Jeho vznik se datuje k roku 1999, původní název „NetSaint“ byl v roce 2002 změnen na současný „Nagios“ kvůli problémům s autorskými právy[19]. 19

2. Realizace Za dobu své existence se stal jedním z lídrů v oblasti síťového monitoringu. Nezanedbatelná část velkých společností na poli informačních technologií ho nasazuje jako primární dohledový systém kvůli jeho snadné modifikovatelnosti prostřednictvím pluginů. Kromě standardního zjišťování dostupnosti zařízení pomocí pingu10 , disponuje Nagios i řadou nástrojů pro kontrolu dostupnosti služeb, jako jsou například HTTP, SMTP, SSH a mnoho dalších. Pokud potřebujeme dohledovat služby, které Nagios standardně nepodporuje, tak máme k dispozici databázi pluginů[12] a pokud ani tam nenajdeme potřebné rozšíření, tak není problém napsat si vlastní plugin. Tyto pluginy nevyžadují znalost žádného specifického programovacího či skriptovacího jazyka, jelikož Nagios je schopen spouštěť skripty přímo z příkazové řádky a vyhodnocovat stav podle jejich návratového kódu. V případě, že je zaznamenán problém, je schopen notifikovat požadované osoby e-mailem, či spustit námi definovaný příkaz z příkazové řádky. Toho bude využito v rámci této práce, kdy se bude volat skript pro odeslání textové zprávy. Stav sítě lze pohodlně sledovat přes webové rozhraní a případně jej lze exportovat přes API do dalších aplikací. To je využitelné například chceme-li zákazníkovi poskytnout kontrolu dostupnosti některých zařízení v síti. Navíc webové GUI umožňuje přidávat komentáře a dočasně vypínat notifikace, například pokud probíhá plánovaný servis zařízení. To je velice praktické, pokud síť spravuje více techniků. Mezi další funkce, které jsou dostupné až ve zpoplatněné verzi, patří například generování reportů o procentuální dostupnosti jednotlivých zařízení či jejich skupin. To se nejčastěji využívá, pokud chceme ověřit, zdali dostupnost služeb byla v určitém časovém rozmezí odpovídající smluvní SLA.

2.2.2

Instalace

Nagios podporuje většinu linuxových i unixových systémů. Já jsem zvolil Debian ve verzi Wheezy pro jeho snadnou údržbu díky balíčkovacímu systému. Pro provoz Nagiosu se doporučuje oddělit diskový oddíl pro „/var“, jelikož produkuje velké množství logů. Tím zamezíme havárii celého systému v případě vyčerpání dostupné diskové kapacity. Na tomto serveru byly vytvořeny oddělené diskové oddíly pro „/“, „/var“, „/tmp“, „/home“, „/boot“, „/swap“. Pro swapovací oddíl se doporučuje využít 2x velikost dostupné RAM (pokud máme dostatek diskové kapacity, je lepší zvolit 4x velikost RAM pro případné budoucí rozšíření). 10

Ping neboli echo request je jedním z nástrojů protokolu ICMP, sloužící k ověření dostupnosti zařízení v síti. Jeho název byl odvozen od sportu ping-pong, jelikož tazatel při zjišťování dostupnosti zařízení odešle dotaz na dostupnost (ping) a cílové zařízení mu na něj odpovídá (pong)

20

2.2. Nasazení dohledového systému Nagios Instalace je díky předpřipravenému balíčku pro Debian jednoduchá, provádí se tedy pomocí apt-get install. Na Debianu je v balíčku „nagios3“ obsažen i balíček „nagios-plugins“, který obsahuje předpřipravené skripty pro ověřování dostupnosti základních služeb. V některých systémech je nutné tento balíček doinstalovat samostatně. Pro plnou funkci všech pluginů je potřeba doinstalovat SNMP protokol11 . Ten jen k dispozici v balíčcích „snmp“ a „snmpd“. Pro snadnější práci a korektní funkci některých pluginů je vhodné doinstalovat i MIB databázi12 , která není kvůli licenčním podmínkám dostupná ze základních repositářů Debianu. Je tedy potřeba nejdříve přidat repozitář, to se provede přidáním následujících řádků do souboru „/etc/apt/sources.lst“: „deb http://http.us.debian.org/debian wheezy main contrib non-free“ „deb http://security.debian.org wheezy/updates main contrib non-free“ Po tomto kroku je nutné provést aktualizaci repozitářů pomocí „apt-get update“. Nyní již můžeme nainstalovat balíček „snmp-mibs-downloader“. Posledním krokem je odkomentování řádku v „/etc/snmp/snmp.conf“ a spuštění příkazu „download-mibs“. Pokud chceme, aby Nagios zasílal e-mailové notifikace, tak si ještě musíme zprovoznit MTA agenta. Původně jsem k tomuto účelu využíval Postfix, ale naprosto dostačující je i Exim, který je v Debianu předinstalován. Posílání mailů Nagios provádí zavoláním příkazu „sendmail“, takže by neměl být problém využít libovolného MTA agenta. Pro komunikaci s GSM bránou jsem zvolil skriptovací jazyk Kermit[9]. Tento jazyk byl vyvinut Kolumbijskou universitou speciálně pro komunikaci po sériovém portu. Pro Debian je k dispozici v balíčku „ckermit“.

2.2.3

Po instalaci

Pokud chceme využívat webové rozhraní nejen k nahlížení na stav sítě, ale i ke komentování či vyvolávání okamžitých kontrol stavu, musíme provést následující úpravu přístupových práv. Tento problém by se měl týkat pouze systémů postavených na Debianu. Zavolání následujících příkazů nám zajistí plnou funkčnost webového rozhranní: „dpkg-statoverride –update –add nagios www-data 2710 /var/lib/nagios3/rw“ „dpkg-statoverride –update –add nagios nagios 751 /var/lib/nagios3“ Nyní povolíme volání externích příkazů v souboru „/etc/nagios3/nagios.cfg“ tím, že odkomentujeme řádek „check_external_commands=1“. Protože budeme využívat Nagios k zasílání SMS notifikací pomocí GSM brány, jež komunikuje přes sériový port, je nezbytné přidat uživatele „nagios“ do skupiny „dialout“. To se provede příkazem „usermod -G dialout nagios“. 11 12

SNMP protokol je určen pro správu vzdálených zařízení v IP síti MIB je databáze sloužící k překladu čísel ve stromové struktuře SNMP na slovní názvy

21

2. Realizace

2.2.4

Vlastní adresářové struktury

Tento krok není povinný a vzhledem k rozměrům síťové infrastruktury, kterou bude tento systém dohledovat, by někteří mohli namítnout, že i zbytečný. Avšak je lepší připravit systém důkladně hned po instalaci, než ho pak zpětně upravovat již za provozu. Konfigurace Nagiosu se skládá z textových souborů. Takových souborů může být nekonečný počet. Je výhodné této vlastnosti využít a konfiguraci přehledně rozdělit do více souborů, protože během provozu budou přibývat další zařízení a konfigurace by se stala nepřehlednou. Dobrým zvykem je tyto soubory od počátku řadit do vlastní adresářové struktury. Vlastní strukturu pak už jen stačí přidat do hlavního konfiguračního souboru systému Nagios, který se nachází v „/etc/nagios3/nagios.cfg“.[20] V našem případě stačí přidat řádek: „cfg_dir=/etc/nagios3/objects“. Nagios reaguje na změny v konfiguračních souborech až po restartování. To se provádí zavoláním jeho init skriptu v podobě „/etc/init.d/nagios3 restart“ Struktura, kterou jsem vytvořil já, vypadá následovně: / etc/ nagios3/ commands.cfg nagios.cfg..4 conf.d/ contacts.cfg extinfo.cfg services.cfg timeperiods.cfg ORIG......................Záložní kopie původních souborů *.cfg.ORIG objects/ ........................ Vlastní adresářová struktura hostgroups.cfg commands/ hosts/ voice/ misc/ network/ plugins/ services/ templates/ generic-host-templates.cfg generic-services-templates.cfg Sestavení výše uvedené adresářové struktury, včetně vytvoření záložních kopií původních souborů a nastavení potřebných práv, je k dispozici v přilo22

2.2. Nasazení dohledového systému Nagios ženém BASH skriptu „nagios.sh“, který stačí po instalaci balíčků spustit jako superuživatel.

2.2.5

Objekty v Nagiosu

Než začneme s konfigurací, je potřeba porozumět, jaké máme v Nagiosu k dispozici objekty, jak jsou provázány a jak funguje dědičnost. Tento systém má i své vlastní specifické proměnné, které nám například umožňují přistupovat k určitým parametrům definovaných objektů, jejichž kompletní popis najdeme v dokumentaci projektu. 2.2.5.1

Dědičnost a šablony

Konfiguračních parametrů je velké množství. Abychom je nemuseli všechny opakovaně inicializovat při každé definici nového hosta či služby, máme k dispozici schopnost dědit parametry ze šablon. Pokud tímto způsobem dědíme parametry a současně v potomkovi tento parametr nastavíme, tak dojde k jeho nahrazení a platná je hodnota definovaná v potomkovi[20]. Definice šablon se provádí stejným způsobem jako u běžného hostitele nebo služby, liší se pouze v parametru „register“, který musí být u šablon nastaven na 0. Například si můžeme vytvořit kompletní šablonu „linux-servertemplate“, kde nastavíme parametry společné pro většinu hostitelů a při následných individuálních definicích pouze nastavíme unikátní název a IP adresu. Ukázka definice šablony: define host { host_name alias check_command check_interval retry_interval max_check_attempts check_period contact_groups notification_interval notification_period notification_options register }

linux-server-template Template for Linux servers check-host-alive 5 1 3 24x7 admins_email 0 24x7 d,u,r 0

Popisem nejdůležitějších parametrů se budeme zabývat v dalších kapitolách, podrobný popis všech parametrů naleznete v dokumentaci projektu Nagios. Tato ukázka slouží pro demonstraci, kolik práce nám ušetří využívání 23

2. Realizace šáblon a dědičnosti. Všimněte si, že v šabloně není uvedena žádna IP adresa a parametr register je nastaven na 0. Dědičnost může být i víceúrovňová, je tedy možné si předdefinovat šablonu „server-template“, z ní dědit parametry v další šabloně „linux-servertemplate“ a tuto šablonu nakonec využít při definici reálného hostitele. Těchto vlastností se vyplatí využívat nejen kvůli usnadnění práce, ale i zachování přehlednosti a konzistence konfiguračních souborů. Dobrá praxe je mít pro každý typ zařízení vlastní šablonu. Při definici takových šablon můžeme navíc dědit od základích předdefinovaných šablon přímo v Nagiosu, které obsahují všechny nutné parametry pro korektní funkčnost dohledu. Pro hostitele je připravena šablona pod názvem „generic-host“ a pro služby „generic-service“. 2.2.5.2

Hostitel

Hostitelem nazýváme jakékoli zařízení, které chceme pomocí Nagiosu dohledovat. V příkladu si uvedeme jednoduchou definici hostitele a popíšeme nejčastěji využívané paramatery. Ukázka definice hostitele: define host { use host_name alias address parents register }

generic-host dns1 Primary Google DNS server 8.8.8.8 default-gateway 1

Popis parametrů: use Parametr use určuje, z jaké šablony budeme dědit ostatní parametry. V tomto příkladu je použita základní šablona „generic-host“. host_name Parametr host_name označuje název hostitele. Pod tímto názvem bude hostitel veden v dohledovém systému. Tento název se používá i v případě, že bychom se na tuto definici chtěli odkazovat jako na šablonu pro dědění. alias Parametr alias je uživatelsky přívětivější název či jednoduchý popis hostitele. Tento název se zobrazuje ve webovém rozhraní. 24

2.2. Nasazení dohledového systému Nagios address Parametr address určuje IP adresu zařízení, na které bude dohledový systémem kontrolovat dostupnost hostitele. parents Parametr parents slouží k vytvoření korektní mapy sítě. Do jeho hodnoty zapíšeme „host_name“ zařízení, které je z pohledu dohledového systém předposledním skokem před hostitelem. Díky tomuto parametru, nebudeme chybně notifikováni o nedostupnosti hostitele, pokud dojde k výpadku sítě již před ním. Vzhledem k našemu příkladu, pokud dojde k výpadku „default-gateway“, nebudeme notifikováni o výpadku public Google DNS serveru na adrese 8.8.8.8. register Parametr register slouží k určení, zdali se jedná o existujícího hostitele, kterého požadujeme dohledovat, či pouze definujeme šablonu. Výchozí hodnotou je 1, která vyjadřuje existujícího hostitele. Pokud chceme vytvořit šablonu je nutné hodnotu nastavit na 0. 2.2.5.3

Skupiny

Individuální hostitele můžeme pro snadnější správu sdružovat do skupin neboli „hostgroup“. K těmto skupinám pak můžeme jednoduše přidávat služby, bez nutnosti upravovat definici u jednotlivých hostitelů. Ukázka definice skupiny hostitelů: define hostgroup { hostgroup_name alias members }

dns-servers DNS Servers dns1,dns2,dyndns

Popis parametrů: hostgroup_name Parametr hostgroup_name označuje název skupiny. Pod tímto názvem bude skupina přístupná v Nagiosu. alias Parametr alias je uživatelsky přívětivější název či jednoduchý popis skupiny. Tento název se zobrazuje ve webovém rozhraní. members Parametr members slouží k přidávání jednotlivých hostitelů do skupiny. Alternativní možností je použí parametr hostgroups v definici hostitele, kam vypíšeme seznam skupin, do kterých jej chceme zařadit. 25

2. Realizace 2.2.5.4

Služby

Službami v Nagiosu rozumíme veškeré periodické kontroly prováděné nad hostiteli. Základní službou je kontrola dostupnosti, kterou není nutné manuálně definovat. Mezi další služby patří například HTTP, DNS, využití disků, vytížení procesoru atd. Služby se z pohledu Nagiosu dělí na aktivní a pasivní. Aktivní kontroly provádí samostatně Nagios pravidelným volaní některého ze skriptů nebo pluginů. Tyto kontroly jsou nejběžnější. Pasivní kontroly nejsou iniciovány přímo Nagiosem, ale spouští je externí aplikace či proces. Tato funkce se využívá pro dohledování služeb, které se chovají asynchronně a je velice obtížné je monitorovat v periodických interavlech. Dobrým příkladem takové služby je SNMP trap13 . Ukázka definice služby: define service { use service_description hostgroup_name check_command notification_interval }

generic-service DNS dns-servers check_dns 0

Popis parametrů: use Parametr use určuje z jaké šablony budeme dědit ostatní parametry. V tomto příkladu je použita základní šablona „generic-service“. service_description Parametr service_description je uživatelsky přívětivější název či jednoduchý popis služby. Tento název se zobrazuje ve webovém rozhraní. hostgroup_name Parametr hostgroup_name označuje název skupiny, pro kterou se bude kontrola dostupnosti této služby provádět. check_command Parametr check_command určuje, jakým příkazem se bude ověřovat dostupnost této služby. Pokud používáme některý z vestavěných skriptů v Nagiosu, stačí zadat jen jeho název, jako je uvedeno v ukázce. Pokud však chceme, aby se spouštěl plugin třetí strany, tak je nutné uvést celou cestu k tomuto souboru. 13 SNMP klient pošle notifikaci dohledovému SNMP serveru ve chvíli, kdy nastane nějaká událost (trap neboli past).

26

2.2. Nasazení dohledového systému Nagios notification_interval Parametr notification_interval slouží k nastavení, v jakém časovém interavlu chceme být o nedostupnosti této služby notifikováni. Pro hodnotu 0 nám Nagios zašle zprávu jen ve chvíli, kdy došlo ke změně stavu (výpadek nebo obnovení dostupnosti). Číslo větší než 0 určuje dobu prodlevy mezi opakovanou notifikací v minutách. Pokud tedy nastavíme hodnotu na 10, bude nám každých 10 minut zaslána notifikace o nedostupnosti služby. 2.2.5.5

Kontakty a skupiny kontaktů

Kontakty fungují jako adresář osob, kterým budeme zasílat notifikace v případě zjištěných problémů. Do skupin sdružujeme kontakty, které spolu logicky souvisí. Prvním kritériem bývá druh kontaktní osoby (například administrátor nebo zákazník). Jako druhé kritérium zpravidla volíme jakým způsobem budeme tyto osoby notifikovat (e-mail, sms, ...). Tyto skupiny pak můžeme přidělovat k hostitelům, jako notifikační kontakty. Ukázka souboru contacts.cfg: define contact { use contact_name alias email }

generic-contact-email skorepa_email Vratislav Pavel Skorepa [email protected]

define contact { use contact_name alias pager }

generic-contact-sms skorepa_sms Vratislav Pavel Skorepa 739667xx8

define contactgroup { contactgroup_name alias members } define contactgroup { contactgroup_name alias

admins_email Nagios Administrators Mail skorepa_email

admins_sms Nagios Administrators SMS 27

2. Realizace members

skorepa_sms

}

Všimněme si, že máme definovány dva podobné kontakty, které se liší v položce „email“/ „pager“. Obě tyto položky by bylo možné přiřadit k jednomu kontaktu, a tím je sloučit, avšak toto rozdělení nám umožňuje pro jednotlivé hostitele rozhodnout, zdali je budeme notifikovat formou e-mailu, SMS nebo oběma kanály současně. Ze stejných důvodů máme definovány dvě skupiny, díky kterým tyto kontakty můžeme přiřazovat k hostitelům. Popis parametrů: use Parametr use určuje z jaké šablony budeme dědit ostatní parametry. V tomto příkladu jsou použity upravené šablony, vycházející z „genericcontact“. contact_name Parametr contact_name definuje název kontaktu v rámci dohledového systému Nagios. contactgroup_name Parametr contact_name definuje název kontaktní skupiny v rámci dohledového systému Nagios. alias Parametr alias zpravidla nese u kontaktu reálné jméno kontaktní osoby a u skupiny její stručný popis. email Parametr email slouží k zadání e-mailové adresy, na kterou chceme pro daný kontakt zasílat notifikace. pager Parametr pager je určen pro uložení telefonního čísla, na které budeme požadovat zasílání notifikačních SMS. members Parametr members slouží k přiřazování jednotlivých kontaktů do skupiny. 2.2.5.6

Časové periody

Časové periody v Nagiosu slouží jako časový plán, podle kterého můžeme řídit aktivní dohled a notifikace. Umožňují rozdělit den na pracovní a nepracovní hodiny, dny v týdnu na pracovní a nepracovní a tak podobně. 28

2.2. Nasazení dohledového systému Nagios Těchto časových vymezení následně využíváme při rozhodování, zdali bude v tomto okamžiku zaslána notifikace dané kontaktní osobě případně jejich skupině. Této funkce nejčastěji využívají větší společnosti, které mají své administrátory mimo pracovní dobu v pohotovosti na telefonu. Jak můžeme vidět v následující ukázce, časový formát je uživatelsky přívětivý a dobře čitelný. Tato vzorová časová perioda zahrnuje celý týden. Využívá se jako základní časový plán notifikací v předdefinovaných šablonách. Jednoduše řečeno, notifikace budou zasílány v jakoukoliv hodinu, kterýkoliv den v týdnu. Ukázka definice jedné časové periody: define timeperiod { timeperiod_name alias sunday monday tuesday wednesday thursday friday saturday }

24x7 24 Hours A Day, 7 Days A Week 00:00-24:00 00:00-24:00 00:00-24:00 00:00-24:00 00:00-24:00 00:00-24:00 00:00-24:00

Popis parametrů: timeperiod_name Parametr timeperiod_name definuje název časového plánu v rámci dohledového systému Nagios. alias Parametr alias zpravidla využíváme jako srozumitelný popis časové periody, například „workhours“.

2.2.6

Konfigurace

V této kapitole se podrobněji podíváme na jednotlivé části konfigurace již nainstalovaného systému Nagios. 2.2.6.1

Příprava skupin pro hostitele

Abychom si ušetřili práci, je dobré si nejdříve vypsat různé typy systémů, zařízení a služeb, které budeme chtít dohledovat. Vhodný návrh skupin nám ušetří spoustu zbytečného kódu. Na základě komunikace se správcem sítě v této společnosti, jsem vytvořil následující schéma hostitelských skupin: 29

2. Realizace windows-servers Do této skupiny budou zařazeny veškeré servery na platformě Windows. S touto skupinou budou svázány dohledy specifických služeb pro tuto platformu (vytížení CPU, obsazení disků a sledování teploty). Hostitelé v této skupině budou notifikování formou e-mailů i SMS. linux-servers Do této skupiny budou zařazeny veškeré servery na platformě Linux. S touto skupinou budou svázány dohledy specifických služeb pro tuto platformu (vytížení CPU, obsazení disků a sledování teploty). Hostitelé v této skupině budou notifikování formou e-mailů i SMS. http-servers U hostitelů zařazených do této skupiny bude dohledována dostupnost webových služeb. Nedostupnost této služby bude notifikována formou e-mailů i SMS. dns-servers U hostitelů zařazených do této skupiny bude dohledována funkčnost překladu doménových jmen. Nedostupnost této služby bude notifikována formou e-mailů i SMS. ssh-servers U hostitelů zařazených do této skupiny bude dohledována dostupnost SSH. Nedostupnost této služby bude notifikována pouze formou e-mailů. voice-servers Do této skupiny budou zařazeny veškeré telefonní ústředny. Jejich nedostupnost bude notifikována formou e-mailů i SMS. storage-servers Skupina pro datová úložiště, notifikace budou zasílány formou e-mailu i SMS. hypervisors Skupina připravená pro plánované nasazení virtualizovaných serverů. Notifikace budou zasílány formou e-mailů i SMS. network-devices V této skupině budou zařazeny všechny dohledovatelné aktivní síťové prvky. Jejich nedostupnost bude notifikována formou e-mailů i SMS. ups UPS jednotky se budou nacházet v této skupině, jejich nedostupnost bude notifikována formou e-mailů i SMS. 30

2.2. Nasazení dohledového systému Nagios printers Skupina určená pro sítové tiskárny, v případě jejich nedostupnosti nebudou zasílány žádné notifikace. workstations-office Důležité pracovní stanice, u kterých bude nutné dohledovat dostupnost, budou zařazeny zde. Notifikace budou zasílány formou e-mailu i SMS. workstations-callcenter V této skupině budou zařazeny všechny pracovní stanice z call centra. Notifikace nebudou aktivně zasílány, kontrola dostupnosti bude možná přes webové rozhranní systému Nagios. 2.2.6.2

Práce s pluginy

I když Nagios obsahuje velké množství pluginů již v balíčku „nagios-plugins“, může se stát, že si budeme nuceni pro méně obvyklé služby nakonfigurovat plugin třetí strany nebo dokonce napsat vlastní. V jednoduché ukázce si ukážeme, jak práce s takovými pluginy vypadá. Ukázka definice nového příkazu: define command{ command_name win_load command_line /root/cpuload.pl $ARG1$ $ARG2$ $ARG3$ $ARG4$ } Popis parametrů: command_name Tento parametr určuje název nového příkazu, přes který budeme tento plugin volat. command_line Do tohoto parametru vložíme přesný příkaz tak, jako bychom ho volali z příkazové řádky. Je vždy nutné uvést absolutní cestu k tomuto příkazu. Plugin v této ukázce nemá žádné přepínače, ale obecně není problém je v příkazu použít. Argumenty „$ARG#$“ určují pořadí, v jakém bude Nagios předávat hodnoty do toho příkazu, pro pochopení se podívejme na další ukázku. Ukázka definice nové služby: define service { hostgroup_name service_description

windows-load CPU Load 31

2. Realizace check_command ...

win_load!$HOSTADDRESS$!public!10!50

} Popis parametrů: hostgroup_name Název skupiny hostitelů, pro kterou se bude provádět kontrola této služby. service_description Srozumitelný popis služby. check_command Tento parametr určuje, jaký příkaz se bude pro kontrolu této služby volat. Vykřičníky jsou odděleny jednotlivé argumenty, které mu budou předány. Když se podíváme na předchozí ukázku, tak vidíme, že například „$ARG2$“ bude mít hodnotu „public“. „$HOSTADDRESS$“ Je speciální vnitřní proměnná, která obsahuje adresu hostitele. Na http://exchange.nagios.org/ najdeme největší databázi dostupných pluginů třetích stran volně ke stažení. 2.2.6.3

Dohledování jednotlivých služeb

Dohled DNS serverů Dohled služeb DNS je obsažen v základní instalaci systému Nagios pod příkazem „check_dns“. Stačí pouze nadefinovat tuto službu a přes skupinu (v našem případě „dns-servers“) ji provázat s požadovanými hostiteli. Dohled HTTP serverů Dohled služeb DNS je obsažen v základní instalaci systému Nagios pod příkazem „check_http“. Stačí pouze nadefinovat tuto službu a přes skupinu (v našem případě „http-servers“) ji provázat s požadovanými hostiteli. Dohled vytížení procesoru Pro Linuxové hostitele je již v základním balíčku „nagios-plugins“ připraven příkaz „snmp_load“, kterému předáváme hodnoty vytížení CPU v procentech v následujícím pořadí: varování - průměr 1 minuta, varování - průměr 5 minut, varování - průměr 15 minut, kritické - průměr 1 minuta, kritické - průměr 5 minut, kritické - průměr 15 minut. 32

2.2. Nasazení dohledového systému Nagios U Windows serverů je k dispozici volně dostupný plugin třetí strany zvaný „check_win_snmp_cpuload.pl“[16]. Po vytvoření příkazu mu předáváme parametry v pořadí: IP adresa hostitele, SNMP community string, hodnota vytížení v procentech pro varování, hodnota vytížení v procentech pro kritickou hranici. Dohled obsazenosti disků Pro Linuxové hostitele je připraven v základním balíčku „nagios-plugins“ příkaz „snmp_disk“, kterému předáváme hodnoty v tomto pořadí: SNMP community string, identifikační číslo disku, spodní mez obsazenosti disku v procentech pro varování, horní mez obsazenosti disku v procentech pro varování, spodní mez obsazenosti disku v procentech pro kritický stav, horní mez obsazenosti disku v procentech pro kritický stav. Pro Windows server můžeme využít například volně stažitelný plugin pod názvem „check_win_snmp_disk.pl“[17], kterému nadefinujeme příkaz pro parametry v tomto pořadí: IP adresa hostitele, SNMP community string, pořadové číslo disku, mez zaplnění disku v procentech pro varování, mez zaplnění disku v procentech pro kritický stav. Dohled teplotních čidel V tomto případě už se ani u Linuxu neobejdeme bez pluginu třetí strany. Jedním z nejuniversálnějších je „check_snmp_temperature.pl“[18]. Tento plugin umožňuje sledovat teploty mnoha druhů zařízení jako jsou například CISCO síťové prvky a tak podobně. Jeho konfigurace avšak není zcela triviální, je nutné si manuálně dohledat správnou SNMP větev teplotního čidla a zahrnout ji do konfigurace příkazu. Následně se mu parametry předávají v pořadí: IP adresa hostitele, SNMP community string, číselné označení teplotního čidla, korekce teploty vůči čidlu včetně jednotky (C/F), hodnota ve stupních bez jednotky pro varování, hodnota ve stupních bez jednotky pro kritický stav. Pro Windows je situace ještě složitější, zejména protože Windows Server nativně nepodporuje zjišťování teploty přes SNMP protokol. Tímto problémem se budeme zabývat později v sekci 2.2.7.2. Ze strany Nagiosu je nutné použít plugin „check_sfan.pl“[1], který přijímá parametry v tomto pořadí: řetězec „temp“, IP adresa hostitele, SNMP community string, číselné označení teplotního čidla, horní (MAX) a dolní (MIN) mez teploty ve tvaru "x>MAX||x<MIN"pro varování, horní (MAX) a dolní (MIN) mez teploty ve tvaru "x>MAX||x<MIN"pro kritickou hodnotu. 2.2.6.4

Notifikace formou e-mailu

Jak už bylo řečeno v návodu pro instalaci, pro e-mailové notifikace postačuje korektní konfigurace libovolného MTA agenta. Já jsem pro tyto účely využil 33

2. Realizace „EXIM“, který je součastí distribuce Debian. Ukážeme si jak připravit příkaz pro zaslání e-mailové notifikace. Ukázka definice e-mailové notifikace: define command{ command_name notify-host-by-email command_line /usr/bin/printf "%b" \ "***** Nagios *****\n\n\ Notification Type: $NOTIFICATIONTYPE$\n\ Host: $HOSTNAME$\n\ State: $HOSTSTATE$\n\ Address: $HOSTADDRESS$\n\ Info: $HOSTOUTPUT$\n\n\ Date/Time: $LONGDATETIME$\n"\ | /usr/bin/mail -s "** $NOTIFICATIONTYPE$ Host Alert: \ $HOSTNAME$ is $HOSTSTATE$ **" $CONTACTEMAIL$ } Popis parametrů: command_name Unikátní název, přes který budeme tento příkaz volat. command_line Přesné znění příkazu, který se bude volat z příkazové řádky. $NOTIFICATIONTYPE$ Typ notifikace (warning/critical/recovery). $HOSTNAME$ Název hostitele, kterého se notifikace týká. $HOSTSTATE$ Aktuální stav hostitele. $HOSTADDRESS$ IP adresa hostitele. $HOSTOUTPUT$ Výstup příkazu, který byl použit při kontrole. $LONGDATETIME$ Datum a čas v dlouhém formátu. $CONTACTEMAIL$ E-mailová adresa, která byla uvedena u kontaktu. 34

2.2. Nasazení dohledového systému Nagios Nyní stačí přiřadit příkaz „notify-host-by-email“ ke kontaktu a e-mailové notifikace budou funkční. 2.2.6.5

Notifikace formou SMS

GSM brány určené rpo připojení k počítači jsou i v dnešní době velmi nákladné, nejlevnější začínají na částce 6000 Kč. Já jsem se rozhodl pro tyto účely využít starý GSM modem Siemens ES75i, který dříve nabízel Eurotel k mobilnímu GPRS Internetu. Tento modem komunikuje po sériovém portu formou AT příkazů, tudíž nepotřebuje žádné speciální ovladače a bude fungovat s každým zařízením disponujícím sériovým portem RS232. Zakoupil jsem jej požitý za 600 Kč, čímž jsem se dostal na pohých 10% nákladů oproti koupi nové GSM brány. Pro komunikaci s bránou jsem zpočátku využíval program „minicom“ a jeho skriptovací internet „runscript“, avšak jeho omezené možnosti práce s proměnnými mě donutili hledat jiné řešení. Kolumbijská Universita vyvinula skriptovací jazyk určený speciálně pro komunikaci přes sériové porty, který byl pojmenován Kermit. I když byl tento projekt 1. července 2011 zastaven, jeho schopnosti jsou velmi rozsáhlé a pro účely této práce se ukázal jako zcela ideální. S jeho pomocí byl vytvořen skript pro odesílání SMS zpráv za užití AT příkazů. Skript se nazývá „sms.ksc“ a je k dispozici na přiloženém CD. Nebudeme zabíhat do detailů syntaxe jazyka Kermit a podíváme se rovnou na použité AT příkazy. Zaslání SMS za pomoci AT příkazů: AT+CMGF=1 > OK AT+CMGS=739667xx8 > Testovací sms.^D > OK

; ; ; ; ;

přepni do modu sms potvrzení zadej číslo příjemce zadej text zprávy a ukonči CTRL+D zpráva odeslána

Jak můžeme vidět, používání AT příkazů není nic složitého a poskytuje nám nezávislost na firmwaru. Příkaz pro zasílání SMS notifikací z Nagiosu pak vypadá následovně: Příkaz pro zasílání SMS notifikací: define command{ command_name notify-host-by-sms command_line /etc/nagios3/objects/plugins/sms.ksc \ $CONTACTPAGER$ "Nagios \ $NOTIFICATIONTYPE$: $HOSTNAME$ \ State:$HOSTSTATE$ \ 35

2. Realizace Info:$HOSTOUTPUT$ $TIME$" } Popis parametrů: command_name Unikátní název, přes který budeme tento příkaz volat. command_line Přesné znění příkazu, který se bude volat z příkazové řádky. $CONTACTPAGER$ Telefonní číslo, které bylo uvedeno u kontaktu. $NOTIFICATIONTYPE$ Typ notifikace (warning/critical/recovery). $HOSTNAME$ Název hostitele, kterého se notifikace týká. $HOSTSTATE$ Aktuální stav hostitele. $HOSTOUTPUT$ Výstup příkazu, který byl použit při kontrole. $TIME$ Čas v krátkém formátu.

2.2.7

Příprava dohledovaných systémů

Aby byl Nagios schopen získávat všechny požadované informace, je nutné provést úpravu konfigurace i na straně dohledovaných zařízení. 2.2.7.1

Linux

U serverů na platformě Linux není konfigurace nějak komplikovaná. Základním předpokladem je mít povolenou odpověď na ICMP echo request neboli ping. Pokud používáme IPtables k blokaci všech nevyžádáných požadavků, povolení odpovědi na ping se provede pomocí přidání následujících pravidel: iptables -A INPUT -p icmp --icmp-type echo-request -j ACCEPT iptables -A OUTPUT -p icmp --icmp-type echo-reply -j ACCEPT Pro získávání podrobnějších informací o serveru, jako je například vytížení procesoru, je nutné naistalovat SNMP démona. To provedeme spuštěním příkazu „apt-get install snmpd“. Po instalaci je nutné zpřístupnit čtění hodnot přes SNMP dohledovému serveru. To provedeme přidáním následujícího řádku do „/etc/snmpd/snmpd.conf“ 36

2.2. Nasazení dohledového systému Nagios rocommunity MY-COMMUNITY-STRING default MY-COMMUNITY-STRING Řetězec, který budeme používat jako heslo pro čtení hodnot přes SNMP. default Tato hodnota umožňuje přístup z libovolné IP adresy. Lze ji nahradit konkrétní IP adresou serveru pro větší bezpečnost. Po úpravě konfigurace je nutné restartovat SNMP démona. Funkčnost si můžeme otestovat pomocí příkazu: snmpwalk -v 2c -c MY-COMMUNITY-STRING localhost Pokud chceme dohledovat teplotní čidla, je nutné naistalovat balíček „lmsensors“. Po jeho instalaci je nutné spustit jeho automatickou konfiguraci příkazem „sensors-detect“. Pokud se podaří čidla korektně detekovat, budou teploty přístupné přes SNMP. 2.2.7.2

Windows Server

Pro dohledování Windows serveru14 je potřeba povolit ICMP echo request. To je možno provést přes firewall konzoli, kde si zvolíme „inbound rules“, v tabulce vyhledáme pod skupinou „File and Printer Sharing“ položku „Echo Request - ICMPv4-In“ a povolíme ji kliknutím na tlačítko „enable rule“. Jestliže chceme dohledovat i pokročilejší služby než jen dostupnost (například obsazenost disků), je nutné doinstalovat služby SNMP. Otevřeme si Server Manager konzoli a v levém sloupci zvolíme položku „features“, pak klikneme na tlačítko „Add Features“, které se objeví po pravé straně. Nyní se otevřelo okno „Add Features Wizard“. V nabídnce nalezneme položku „SNMP services“, zaškrtneme a klikneme na „Next“ a následně „Install“. Po dokončení instalace si otevřeme „Computer Management“ v levém sloupci zvolíme „Services and Applications“ -> „Services“. V nabídce vyhledáme „SNMP service“, klikneme na ni pravým tlačítkem a zvolíme „Start“. Následně je nutné přidat SNMP community string, pod kterým budeme k datům přistupovat. Opět klikneme pravým tlačítkem na „SNMP service“ v tabulce „Services“ a tentokrát zvolíme položku „Properties“. V tomto okně přepneme na záložku „Security“ a v tabulce „Accepted community names“ klikneme na tlačítko „Add“. V položce „Community rights“ zvolíme „READ ONLY“ a do řádku „Community Name“ napíšeme náš SNMP community string, pak klikneme na tlačítko „Add“. Pro větší bezpečnost je možné v této záložce nastavit pouze konkrétní IP adresy, které budou mít možnost číst SNMP data. Nyní restartujeme službu SNMP. 14

Následující popsané kroky byly otestovány na Windows Server 2008 Enterprise.

37

2. Realizace Pokud chceme na Windows serveru číst hodnoty z teplotních čidel, musíme sáhnout k aplikacím třetích stran. Já jsem pro tyto účely zvolil kombinaci aplikace SpeedFan[10] a SpeedFan SNMP injektoru[14]. Nejdříve stáhneme a nainstalujeme SpeedFan. Po instalaci se sám spustí, je nutné ho před instalací injektoru vypnout. Po provedení instalace SFSNMP přejdeme do složky C:\Program Files\SpeedFan, klikneme pravým tlačítkem na soubor „Injektor.exe“ a zvolíme možnost „Run as administrator“. Tím se spustí program SpeedFan a zpřístupní se nám detekována čidla přes protokol SNMP. OID .1.3.6.1.4.1.30503.1.1.1 .1.3.6.1.4.1.30503.1.1.2 .1.3.6.1.4.1.30503.1.1.3 .1.3.6.1.4.1.30503.1.2.x .1.3.6.1.4.1.30503.1.3.x .1.3.6.1.4.1.30503.1.4.x

Popis Počet teplotních čidel Počet otáček ventilátorů Počet napětí Teploty Otáčky ventilátorů Napětí

Tabulka 2.1: Seznam dostupných OID přes SFSNMP

2.3 2.3.1

Nasazení zálohovacího systému Bacula Stručný popis systému

Bacula[23] je soubor programů z oblasti otevřeného softwaru, sloužící k vytváření a správě záloh počítačových systémů na různých platformách, připravený k nasazení do produkce v enterprise sféře. Umožňuje data zálohovat na téměř všechny druhy médií a nabízí rozšířenou podporu pro užití magnetických pásek. Pracuje v režimu server-klient a díky své modulární architektuře je schopný růst s infrastrukturou od malých až po rozsáhlé sítě čítající stovky počítačů. Je také velmi variabilní při obnově dat. Umožňuje jak obnovení ztracených jednotlivých souborů, tak i kompletní obnovu systému na čistém hardwaru po havárii.[5]

2.3.2 2.3.2.1

Architektura systému Bacula Director

Director je hlavním mozkem systému, který se využívá pro plánování a vytváření záloh. Spravuje archvivaci veškerých dat a jejich případné obnovování. Současně dohlíží na korektní dokončení veškerých požadovaných operací a v případě problémů je schopen informovat administrátora. 38

2.3. Nasazení zálohovacího systému Bacula 2.3.2.2

Storage

Storage démon zajišťuje přístup k zálohovacím médiím a veškerou jejich správu pro directora. Může být provozován i na jiném fyzickém serveru než director (například na NAS serveru). 2.3.2.3

File

File démon je klientskou částí systému, které komunikuje s directorem. Je provozován na počítačích, u kterých chceme provádět zálohy nebo obnovy dat. 2.3.2.4

Catalog

Catalog je databáze všech indexů zálohovaných souborů, fyzických médií a provedených úloh. Umožňuje administrátorovi rychlé dohledání a obnovení požadovaných souborů bez nutnosti procházení reálné zálohy. V současné době jsou podporovány tři různé databáze: MySQL, PostgreSQL a SQLite. 2.3.2.5

Console

Console je textové rozhraní sloužící administrátorovi k ovládání všech funkcí directora.

2.3.3 2.3.3.1

Instalace Server

Při instalaci serveru je nutné, vzhledem k zálohovacím účelům, počítat s následnými roustoucími nároky na kapacitu diskového úložiště. Proto jsem se rozhodl použít řízení logických disků LVM, které umožňují případné budoucí zvětšování diskových oddílů i přes několik fyzických médií. Nejprve je nutné nainstalovat kompatibilní databázový server, máme na výběr z MySQL, PostgreSQL a SQLite. Já jsem zvolil MySQL, jelikož s ním mám nejvíce zkušeností. MySQL je v Debianu k dispozici v balíčku „mysql-server“. Po instalaci se ujistíme, že je databázový server spuštěný. Nyní můžeme přistoupit k instalaci systému Bacula. Začneme instalací directora pomocí balíčku „bacula-director-mysql“. Během instalace budeme vyzváni k zadání hesla pro registraci directora s databází. Pokud toto heslo nevyplníme, bude vygenerováno náhodné. Po instalaci zkontrolujeme, zdali byla databáze korektně vytvořena a director je zapnutý. V případě problémů s navázáním komunikace s databází, můžeme ručně spustit databázové konfigurační skripty ve složce „/usr/share/bacula-director/“. Když máme zprovozněného directora, nainstalujeme storage démona z balíčku „bacula-sd-mysql“, file démona z balíčku „bacula-fd“ a také konzoli, 39

2. Realizace abychom mohli celý systém ovládat. Konzole je k dispozici v balíčku „baculaconsole“. Ověříme, že všichni démoni běží a případně je ručně zapneme. Tím je instalace dokončena. Pokud používáme na serveru firewall, je nutné povolit porty, které Bacula používá pro komunikaci. Konkrétně se jedná o porty 9101, 9102 a 9103.

2.3.3.2

Klient pro Linux

Klienta můžeme na Debianu a jemu příbuzných systémech nainstalovat z balíčku „bacula-fd“. Pokud nemáme balíček k dipozici, je možné si veškeré potřebné soubory stáhnout z http://sourceforge.net/projects/bacula/ files/bacula/ a ručně si jej zkompilovat. Pokud máme zapnutý firewall, tak je nutné povolit porty 9101, 9102 a 9103.

2.3.3.3

Klient pro Windows

Instalační soubory pro operační systém Windows jsou ke stažení na adrese http://sourceforge.net/projects/bacula/files/Win32_64/, zvolíme nejaktuálnější verzi a vybereme 32bit nebo 64bit verzi podle typu operačního systému. Při instalaci zvolíme typ „automatic“ a následně budeme vyzvání k doplnění informací o directorovi. Tyto informace opíšeme z konfiguračního souboru našeho directora, který se je umístěn v „/etc/bacula/bacula-dir.conf“. Potřebné údaje nalezneme v bloku „Director“. Do položky „DIR Name“ opíšeme hodnotu „Name“, do „DIR Password“ hodnotu „Password“ a do „DIR Address“ napíšeme IP adresu serveru, na kterém běží director démon. V závěru instalace budeme dotázáni, kam uložit konfigurační soubor file démona tohoto počítače. Tento soubor budeme potřebovat pro spojení directora s klientem. Nakonec v nastavení firewallu povolíme porty 9101, 9102 a 9103.

2.3.4

Konfigurace directora

Pro snažší pochopení souvislostí mezi konfiguračními soubory, se podívejme na jednoduché schéma 2.3, které znázorňuje vazby mezi nejdůležitějšími direktivami. 40

2.3. Nasazení zálohovacího systému Bacula

Obrázek 2.3: Schéma souvislostí konfiguračních souborů systému Bacula [22]

Hlavní konfigurační soubor pro directora se nachází v „/etc/bacula/baculadir.conf“. Nyní se podrobněji podíváme na definice jednotlivých sekcí a jejich nejpodstatnějších parametrů. Kompletní dokumentace konfiguračních souborů je k dispozici v manuálu[3]. 41

2. Realizace 2.3.4.1

Director {. . . }

Name Definuje unikátní název tohoto directora. Password Heslo pro připojení konzole k direktorovi. DIRport Port, na kterém bude director poslouchat, defaultní hodnotou je 9101. Pokud nemáme vážný důvod, nedoporučuje se port měnit. DIRaddress IP adresa, na které bude director očekávat spojení. Pokud tento parametr odstraníme, bude director poslouchat na všech dostupných IP adresách. 2.3.4.2

JobDefs {. . . }

Tato sekce slouží jako šablona pro usnadnění definice jednotlivých úloh (Job). Pokud budou některé parametry nadefinovány jak v šabloně, tak i v definici úlohy, bude platná hodnota nastavená v úloze. Name Název šablony, který budeme využívat při definici úkolů. Type Druh úlohy k provedení (backup, restore, verify, admin). Level Parametr platný pouze pro úlohy typu backup. Možné druhy jsou full, incremental a differential viz kapitola 1.3.4. Schedule Časový plán záloh viz 2.3.4.5. Storage Parametr určující, které datové úložiště bude použito viz 2.3.4.6. Pool Tento parametr určuje, který svazek bude pro tuto úlohu použit viz 2.3.4.7. 2.3.4.3

Job {. . . }

Pomocí této sekce definujeme jednu úlohu. Kromě níže vyjmenovaných parametrů může obsahovat i všechy parametry zmíněné v šabloně JobDefs 2.3.4.2. 42

2.3. Nasazení zálohovacího systému Bacula Name Název úlohy, který se bude zobrazovat v konzoli. Client Název klienta 2.3.4.8, u kterého bude úloha vykonávána. JobDefs Název šablony, která bude pro definici úlohy použita. FileSet Tento parametr určuje, které soubory budou zálohovány viz 2.3.4.4. Where Tento parametr slouží pro úlohy typu „restore“. Určuje, do které složky (na straně klienta) budou soubory obnoveny. Client Run Before Job Hodnotou tohoto parametru je příkaz, který se u klienta spustí před provedením zálohy (například vytvoření dumpu databáze). Client Run After Job Hodnotou tohoto parametru je příkaz, který se u klienta spustí po provedení zálohy (například odstranění dumpu databáze). 2.3.4.4

FileSet {. . . }

Nastavení množiny souborů, které budou u klienta zálohovány. Tento prostředek je dále rozdělen na podčásti „Include {. . . }“ (zahrnout do zálohy) a „Exclude {. . . }“ (vyjmout ze zálohy). Name Název file setu. File Cesta k souboru nebo složce, kterou chceme zálohovat či vyjmout ze zálohy. Pozor, pokud máme u Linuxu rozdělen systém na více diskových oddílu, tak nestačí zálohovat pouze kořenový adresář, ale je nutné zahrnout všechny související mountpointy15 . Enable VSS Parametr určující, zdali bude k záloze využita služba „Volume Shadow Copy Service“ systému Windows. Možné hodnoty jsou yes/no. 2.3.4.5

Schedule {. . . }

Sekce schedule se používá k časovému plánování záloh. Její konfiguraci nejlépe pochopíme z příkladu. 15

Složka nebo soubor, kam je disk nebo diskový oddíl logicky namapován.

43

2. Realizace Ukázka definice časového plánu: Schedule { Name = "WeeklyCycle" Run = Full 1st sun at 23:05 Run = Differential 2nd-5th sun at 23:05 Run = Incremental mon-sat at 23:05 } Name Název časového plánu. Run Parametr definující typ zálohy a termín jejího provedení. Full 1st sun at 23:05 Úplná záloha každou první neděli v měsíci ve 23:05. Differential 2nd-5th sun at 23:05 Diferenciální záloha vůči poslední existující úplné každou další neděli v měsíci ve 23:05. Incremental mon-sat at 23:05 Inkrementální záloha každý den kromě neděle ve 23:05 2.3.4.6

Storage {. . . }

V této sekci definuje storage démony, které chceme využívat pro ukládání záloh. Name Název storage démona, který jsme nastavili při jeho konfiguraci. Address IP adresa, na které storage démon poslouchá. Pozor, nikdy zde nepoužívejte localhost nebo 127.0.0.1, jinak nebudou klienti schopni navázat spojení. SDport Port, na kterém storage démon poslouchá, defaultní hodnotou je 9103. Password Heslo pro připojení ke storage démonovi. Musí se shodovat s heslem nastaveným na straně storage démona. Device Zařízení na straně storage démona, na které budeme zapisovat. 44

2.3. Nasazení zálohovacího systému Bacula Media type Typ média, na které budeme zapisovat. Protože v našem případě to bude disk, typem média budou soubory. Hodnota tedy bude „File“. 2.3.4.7

Pool {. . . }

Sekce určená pro definici množin úložišťových svazků (soubory, pásky, ...), které budou pro zálohování použity. S jejich pomocí je například možné oddělit úplné zálohy od diferenciálních a tak podobně. Name Název svazku. Pool type Typ svazku, v současné verzi je dostupný pouze „Backup“. Maximum Volumes Maximální počet úložišť ve svazku. Pro neomezený počet nastavíme na 0 Maximum Volume Bytes Maximální velikost jednoho úložiště, například 50G. Volume Retention Jak dlouho budou v databázi uchovávány záznamy o obsahu úložiště od posledního zápisu do úložiště. Například pro jeden rok nastavíme hodnotu na „365 days“. AutoPrune Automatické odstranění záznamů z databáze po vypršení „Volume Retention“ doby. Hodnoty yes/no. Recycle Automatické přepsání úložiště po vypršení „Volume Retention“ doby novými zálohami. Hodnoty yes/no. Label Format Parametr nastavující formát automatického pojmenovávání úložišť (souborů), například „MyPool-${Year}-${Month}-${Day}“ 2.3.4.8

Client {. . . }

Tato sekce slouží pro definici jednotlivých klientů, kteří budou s tímto directorem provázáni. Name Název klienta (file démona), který jsme nastavili při jeho konfiguraci. 45

2. Realizace Address IP adresa, na které file démon poslouchá. FDport Port, na kterém file démon poslouchá, defaultní hodnotou je 9102. Password Heslo pro připojení k file démonovi. Musí se shodovat s heslem nastaveným na straně file démona.

2.3.5

Konfigurace storage démona

Hlavní konfigurační soubor storage démona se nachází v „/etc/bacula/baculasd.conf“. Nyní se podrobněji podíváme na definice jednotlivých sekcí a jejich nejpodstatnějších parametrů. Kompletní dokumentace konfiguračních souborů je k dispozici v manuálu[3]. 2.3.5.1

Storage {. . . }

V této sekci konfigurujeme samotného storage démona. Name Definuje název tohoto storage démona, který bude director používat pro připojení. SDport Port, na kterém bude storage démon poslouchat, defaultní hodnotou je 9103. Pokud nemáme vážný důvod, nedoporučuje se port měnit. SDaddress IP adresa, na které bude storage očekávat spojení. Pokud tento parametr odstraníme, bude storage démon poslouchat na všech dostupných IP adresách. 2.3.5.2

Director {. . . }

Tato sekce slouží k povolení připojení od našeho directora. Name Definuje název tohoto directora, který se bude ke storage démonovi připojovat. Password Heslo pro připojení k tomuto storage démonovi, musí se shodovat s heslem nastaveným u directora. 46

2.3. Nasazení zálohovacího systému Bacula 2.3.5.3

Device {. . . }

Tato sekce slouží k definici zařízení (disk, páska,...), které chceme poskytnout directorovi pro zálohování. Name Název zařízení, pod kterým bude přístupné directorovi. Media type Parametr, kterým sdělíme systému Bacula skutečný typ média, možné hodnoty jsou „File“, „Tape“ a „Fifo“. Archive Device Do tohoto parametru zapíšeme ve formě řetězce systémovou cestu k zařízení. Pro pevný disk ( „File“) použijeme cestu ke složce, pokud používáme například zálohovací pásky, tak použijeme přímou cestu k zařízení (například „/dev/nst0“).

2.3.6

Konfigurace file démona

Na Linuxu se konfigurační soubor file démona nachází v „/etc/bacula/baculafd.conf“. Pokud konfigurujeme file démona pro Windows, tak konfigurační soubor otevřeme přes „Start“ -> „All Programs“ -> „Bacula“ -> „Configuration“ -> „Edit Client Configuration“. Kompletní dokumentace konfiguračních souborů je k dispozici v manuálu[3]. 2.3.6.1

FileDaemon {. . . }

V této sekci konfigurujeme samotného file démona. Name Definuje název tohoto file démona, který bude director používat pro připojení. FDport Port, na kterém bude file démon poslouchat, defaultní hodnotou je 9102. Pokud nemáme vážný důvod, nedoporučuje se port měnit. FDaddress IP adresa, na které bude klient očekávat spojení. Pokud tento parametr odstraníme, bude klient poslouchat na všech dostupných IP adresách. 2.3.6.2

Director {. . . }

Tato sekce slouží k povolení připojení od našeho directora. Name Definuje název directora, který se bude ke klientovi připojovat. 47

2. Realizace Password Heslo pro připojení k tomuto klientovi, musí se shodovat s heslem nastaveným u directora. Posledním krokem je definice klienta viz sekce 2.3.4.8 a zálohovacích (obnovovacích) úloh viz sekce 2.3.4.3 na straně directora.

2.3.7

Základy ovládání directora

Ovládání veškerých funkcí directora se ovládá pomocí speciální textové konzole, kterou spustíme příkazem „bconsole“. Níže je uveden seznam nejpoužívanějších příkazů: status Pomocí tohoto příkazu se dostaneme ke všem informacím o directorovi, storage, připojených klientech a provedených úlohách. messages Tento příkaz slouží k vypsání logu posledních událostí. run Tímto příkazem můžeme ručně spustit úlohy nadefinované v „bacula-dir.conf“. restore Hlavní nabídka pro obnovování souborů. Mimo jiné umožňuje detailně nastavovat, které soubory chceme obnovit a k jakému datu. help Nápověda pro bconsole, vypíše seznam všech dostupných příkazů s jejich popisem.

2.3.8 2.3.8.1

Disaster recovery scénáře Obnova jednotlivých souborů

Obnovení vybraných souborů je poměrně jednoduchý úkon. Následující kroky jsou popsány pro manuální obnovu bez předem nakonfigurované úlohy. 1. Spustíme konzoli u directora příkazem „bconsole“ 2. Napíšeme příkaz „restore“ 3. Nyní si zvolíme „5: Select the most recent backup for a client“ 48

2.3. Nasazení zálohovacího systému Bacula 4. Vybereme si klienta, ze kterého chceme obnovu provést 5. Zvolíme si FileSet, ve kterém se soubor nachází (nejčastěji Full Set) 6. Nyní se nacházíme v kořenovém adresáři zálohy. Pohybujeme se v něm podobně jako v Linuxové příkazové řádce. Základní příkazy: „ls“-vypíše obsah složky, „cd“-změna aktuální složky, „mark“-označení souboru pro obnovu, „unmark“-zrušení označení souboru 7. Po označení všech souborů, které chceme obnovit, si zkontrolujeme jejich počet příkazem „count“ 8. Pokud je vše v pořádku, výběr ukončíme příkazem „done“ 9. Nyní nám zobrazí podrobnosti k obnově ke kontrole, máme na výběr z možností „OK to run? (yes/mod/no):“ - zvolíme „mod“ 10. Zobrazí se nám nabídka možných úprav, zvolíme „9: Where“ 11. Nyní zadáme cestu ke složce, do které chceme soubor obnovit. Pokud chceme soubor obnovit přesně do místa, odkud byl zálohován, tak nastavíme cestu jen jako „/“ 12. Překontrolujeme si parametry obnovy a pokud je vše v pořádku, tak obnovu spustíme příkazem „yes“ Pokud bychom chtěli změnit i klienta, na kterém chceme obnovu provést, lze tak učinit v kroku 9. volbou „5: Restore Client“ 2.3.8.2

Obnova Windows serveru

Kvůli problémům s registry a systémovými soubory nepodporuje Bacula v bezplatné verzi kompletní obnovu systému Windows na čistém hardwaru do původního stavu. Tuto funkci je možné dokoupit v rámci enterprise podpory pod názvem Bare Metal Backup[2] Pokud tuto funkci nemáme zakoupenou, doporučeným postupem je nejdříve nainstalovat nový operační systém, do kterého následně obnovíme veškerá uživatelská data podobně jako v sekci 2.3.8.1. Můžeme ušetřit čas přímou obnovou dat bez předchozí instalace operačního systému, ale nemáme jistotu, že po obnově bude systém plně funkční. Následné odstranění nedostatků pak může celkovou dobu výpadku ve výsledku prodloužit. 49

2. Realizace 2.3.8.3

Obnova Linux serveru

Tento návod[4] slouží k obnově Linuxového serveru po havárii na novém hardwaru. 1. Nabootujeme z Live CD, například SystemRescueCd[11] (již obsahuje bacula-fd) 2. Zprovozníme přístup k síti 3. Vytvoříme si stejné diskové oddíly jako na původním serveru 4. Naformátujeme disk 5. Připojíme si disk: mount /mnt/disk /dev/sda1 6. Nakonfigurujeme directora pro připojení k tomuto klientovi viz 2.3.4.8 7. Spustíme file démona /etc/init.d/bacula-fd start 8. Spustíme konzoli u directora příkazem „bconsole“ 9. Napíšeme příkaz „restore“ 10. Nyní si zvolíme „5: Select the most recent backup for a client“ 11. Vybereme si klienta, ze kterého chceme obnovu provést 12. Z nabídky FileSet si zvolíme Full Set 13. Napíšeme příkazy „mark *“ a „done“ 14. Nyní nám zobrazí podrobnosti k obnově ke kontrole, máme na výběr z možností „OK to run? (yes/mod/no):“ - zvolíme „mod“ 15. Zvolíme „5: Restore Client“ a vybereme klienta na novém serveru 16. Poté vybereme „9: Where“ a nastavíme cestu k přípojnému bodu připraveného disku, v našem případě je to „/mnt/disk“ 17. Překontrolujeme si parametry obnovy a pokud je vše v pořádku, tak obnovu spustíme příkazem „yes“ 18. Na nově obnoveném serveru nainstalujeme grub do MBR: /sbin/grub-install --root-directory=/mnt/disk /dev/sda 19. Restartujeme server Pokud nám server po restartu korektně nenabootoval, je nejsnažším řešením spustit systém znovu z SystemRescueCd a najít chybu. Nejčastěji se vyskytují problémy s nastavením grub a fstab. 50

Závěr V rámci práce jsem navrhl dvě různé možnosti restrukturalizace současné síťové infrastruktury, které jsou odstupňované podle nákladů na jejich provedení. V případě omezeného rozpočtu jsem návrh směřoval k tomu, abych využil ideálně veškerá dostupná zařízení, která v současnosti společnost vlastní. Výsledkem je možnost optimalizace sítě bez nutnosti nákupu nových síťových prvků, která v případě výpadku některého ze zařízení, což je pro krizovou linku kritické, zajistí dostupnost alespoň části sítě bez nutnosti zásahu administrátora. Současně jsem pro tuto optimalizaci navrhl levnější alternativu k redundantní Internetové konektivitě v podobě 3G modemu s předplacenou kartou, který umožňuje v případě potřeby Internet aktivovat pomocí SMS zprávy jen na určité časové období a není tudíž nutné platit měsíční paušál za záložní konektivitu. Pro telefonní E1 linku je možnost zakoupit failover přepínač, který v případě výpadku jednoho ze směrovačů linku přepne na záložní. Ve druhém návrhu jsem nebral v úvahu finanční stránku a sestavil jsem síťovou infrastrukturu tak, aby odpovídala dnešním standardům pro vysokou dostupnost. Použil jsem takzvanou collapsed core architekturu s využitím agregovaných linek a dvou fyzických zařízení spojených v jeden logický celek na distribuční úrovni sítě. Tento logický celek se v síti chová jako jedno virtuální zařízení, které zůstává v provozu i v případě výpadku některého z fyzických zařízení. Pro tento návrh doporučuji zřídit plnohodnotnou redundantní Internetovou a telefonní E1 konektivitu. Obě navrhovaná řešení odstraňují současnou závislost celé sítě na jediném síťovém prvku. Díky tomu není nutná okamžitá výměna vadného zařízení, neboť zůstane v provozu alespoň část call centra krizové linky. Dohledový systém Nagios jsem v síti nasadil v plném rozsahu. Provádí periodické kontroly dostupnosti všech požadovaných zařízení, měří jejich odezvu (to je důležité zejména pro hlasové služby - tedy v našem případě), ověřuje dostupnost kritických služeb vyšších vrstev (DNS, DHCP, HTTP, SSH) a u požadovaných serverů kontroluje vytížení procesoru, obsazenost disků, případně i jejich teplotní čidla. Pokud dojde ke zjištění problému, okamžitě je 51

Závěr notifikován správce sítě formou e-mailu i SMS zprávy. Do této chvíle byl dohled sítě prováděn pouze ze strany UPS, která je schopna zasílat notifikace jen formou e-mailu. Toto řešení bylo nedostačující, jelikož v případě výpadku internetové konektivity nebylo možné e-mail odeslat. Nagios je spolehlivé řešení pro monitorování sítě, které využívá i řada internetových poskytovatelů. Díky jeho modulárnosti bude možné reagovat na budoucí rozvoj síťové infrastruktury a zavádění nových služeb. Pro zálohování důležitých serverů a počítačů jsem nasadil systém Bacula. Jedná se o robustní enterprise řešení, které podporuje inkrementální i diferenciální zálohování pro většinu dnešních platforem (Unix, Linux, Windows, Mac). Umožňuje centralizované zálohování po síti v režimu klient - server, čímž se značně usnadňuje správa dat v případě většího počtu zařízení. Oproti současnému řešení, využívajícímu Cobian Backup, je systém Bacula připraven zálohovat i Linuxové servery, které společnost plánuje nasadit v průběhu letošního roku. Navíc je možné, v případě havárie některého ze zálohovaných Linuxových serverů, provést obnovu dat na novém hardwaru za pomoci Live CD bez nutnosti předchozí instalace operačního systému, což znatelně zkracuje dobu výpadku.

52

Literatura [1]

Archambault, S.: check_sfan [online]. [cit. 2014-05-08]. Dostupné z: http://exchange.nagios.org/directory/Plugins/System-Metrics/ Environmental/Speed-fan/details

[2]

Bacula Systems: Bacula Bare Metal Recovery [online]. [cit. 2014-05-12]. Dostupné z: http://www.baculasystems.com/products/bare-metalrestore

[3]

Bacula.org: Bacula Main Reference [online]. [cit. 2014-05-10]. Dostupné z: http://www.bacula.org/5.2.x-manuals/en/main/main/

[4]

Bacula.org: Disaster Recovery Using Bacula [online]. [cit. 201405-12]. Dostupné z: http://www.bacula.org/5.0.x-manuals/en/main/ main/Disaster_Recovery_Using_Bac.html

[5]

Bacula.org: What is Bacula [online]. [cit. 2014-04-17]. Dostupné z: http: //blog.bacula.org/about-bacula/what-is-bacula

[6]

Cisco Systems, Inc.: Cisco Networking Academy v5.0 Curriculum [online]. [cit. 2014-04-19]. Dostupné z: http://www.netacad.com

[7]

Cisco Systems, Inc.: Understanding Spanning-Tree Protocol Topology Changes [online]. [cit. 2014-04-19]. Dostupné z: http: //www.cisco.com/c/en/us/support/docs/lan-switching/spanningtree-protocol/12013-17.pdf

[8]

Cobian, L.: Cobian Backup [online]. [cit. 2014-05-12]. Dostupné z: http: //www.cobiansoft.com/

[9]

Columbia University: C-Kermit [online]. [cit. 2014-05-12]. Dostupné z: http://www.kermitproject.org/ck90.html

[10] Comparetti, A. M.: SpeedFan [online]. [cit. 2014-05-12]. Dostupné z: http://www.almico.com/speedfan.php 53

Literatura [11] Dupoux, F.: SystemRescueCD [online]. [cit. 2014-05-12]. Dostupné z: http://www.sysresccd.org/ [12] Galstad, E.: Nagios Exchange [online]. [cit. 2014-05-12]. Dostupné z: http://exchange.nagios.org/ [13] Galstad, E.: Nagios [online]. [cit. 2014-05-08]. Dostupné z: http:// www.nagios.org/ [14] Gembe, A.: SpeedFan SNMP Extension [online]. [cit. 2014-05-12]. Dostupné z: http://deve.loping.net/projects/sfsnmp/ [15] IEEE: 802.1D standard: Local and metropolitan area networks [online]. [cit. 2014-05-12]. Dostupné z: https://standards.ieee.org/ getieee802/download/802.1D-2004.pdf [16] Jakubowski, B.: Check Windows CPU Load [online]. [cit. 2014-0508]. Dostupné z: http://exchange.nagios.org/directory/Plugins/ Operating-Systems/Windows/Check-Windows-CPU-Load/details [17] Jakubowski, B.: Enhanced SNMP Windows Disk Check [online]. [cit. 2014-05-08]. Dostupné z: http://exchange.nagios.org/directory/ Plugins/System-Metrics/File-System/Enhanced-SNMP-WindowsDisk-Check/details [18] Leibzon, W.: check_snmp_temperature [online]. [cit. 2014-05-08]. Dostupné z: http://exchange.nagios.org/directory/Plugins/ Hardware/Environmental/check_snmp_temperature/details [19] Nagios Enterprises, LLC.: Nagios history [online]. [cit. 2014-04-17]. Dostupné z: http://www.nagios.org/about/history [20] Noens, K.: The Definitive Quickstart Beginners Guide to Nagios in 24 hours for Dummies [online]. [cit. 2014-04-17]. Dostupné z: http: //users.telenet.be/mydotcom/howto/nagios/index.html [21] Preston, W. C.: Backup & Recovery: Inexpensive Backup Solutions for Open Systems. Sebastopol, CA: O’Reilly, 2007, ISBN 9780596102463, [vlastní překlad]. [22] Rummel, R.: Bacula backup tutorial [online]. [cit. 2014-05-08]. Dostupné z: http://webmodelling.com/webbits/miscellaneous/bacula.aspx [23] Sibbald, K.: Bacula [online]. [cit. 2014-05-12]. Dostupné z: http:// www.bacula.org/

54

Příloha

Seznam použitých zkratek ADSL Asymmetric Digital Subscriber Line AP Access Point API Application Programming Interface BPDU Bridge Protocol Data Units CAM Content Addressable Memory CUCM Cisco Unified Communications Manager DHCP Dynamic Host Configuration Protocol DNS Domain Name System GSM Groupe Spécial Mobile GUI Graphical User Interface HP Hewlett-Packard HR Human resources HTTP Hypertext Transfer Protocol ICMP Internet Control Message Protocol IEEE Institute of Electrical and Electronics Engineers IP Internet Protocol ISDN Integrated Services Digital Network LAN Local Area Network LB Linka bezpečí 55

A

A. Seznam použitých zkratek LVM Logical Volume Management MAC Media Access Control MBR Master Boot Record MIBS Management Information Base NAS Network Attached Storage OID Object Identifier PC Personal Computer PPPoE Point-to-Point Protocol over Ethernet SFSNMP SpeedFan SNMP SIP Session Initiation Protocol SLA Service Level Agreement SMS Short Message Service SMTP Simple Mail Transfer Protocol SNMP Simple Network Management Protocol SSH Secure Shell STP Spanning-Tree Protocol SW Switch UPS Uninterruptible Power Supply VGW Voice Gateway VLAN Virtual Local Area Network VoIP Voice over Internet Protocol VSS Volume Shadow Copy Service WAN Wide Area Network WD Western Digital

56

Příloha

Obsah přiloženého CD

CtiMe.txt....................................stručný popis obsahu CD manualy ............................................ přiložené manuály src konfiguracni_soubory ................ použité konfigurační soubory skripty..........................................vytvořené skripty thesis ...................... zdrojová forma práce ve formátu LATEX text ....................................................... text práce BP_Skorepa_Vratislav_Pavel_2014.pdf.text práce ve formátu PDF 57

B