Západočeská univerzita v Plzni Fakulta aplikovaných věd Katedra informatiky a výpočetní techniky. Automatizace procesů firmy v oblasti

Západoˇceská univerzita v Plzni Fakulta aplikovaných vˇed Katedra informatiky a výpoˇcetn´ı techniky

Diplomov´ a pr´ ace Automatizace proces˚ u firmy v oblasti spr´ avy a u ´ drˇ zby server˚ u

Plzeˇn, 2010

Michal Bryx´ı

Abstrakt ´ Uvodn´ ı pov´ıdán´ı o diplomové práci.

1

Prohl´ aˇ sen´ı Prohlaˇsuji, ˇze jsem svou diplomovou práci vypracoval samostatnˇe a pouˇzil jsem pouze podklady (literaturu, projekty, SW atd.) uvedené v pˇriloˇzeném seznamu.

V Plzni dne podpis

2

3

Obsah 1 Z´ akladn´ı rozbor 1.1 C´ıl práce a seznámen´ı s produktem . . . . . . . 1.1.1 Portál . . . . . . . . . . . . . . . . . . . 1.2 Dosavadn´ı ˇreˇsen´ı produkˇcn´ıch server˚ u . . . . . . 1.3 V´ ybˇer vhodného operaˇcn´ıho systému . . . . . . 1.3.1 Porovnán´ı v´ yhod jednotliv´ ych operaˇcn´ıch 1.3.2 Závˇer . . . . . . . . . . . . . . . . . . . 1.4 Virtualizace . . . . . . . . . . . . . . . . . . . . 1.4.1 V´ yhody virtualizace . . . . . . . . . . . 1.4.2 Nev´ yhody virtualizace . . . . . . . . . . 1.4.3 Typy virtualizace . . . . . . . . . . . . . 1.4.4 Závˇer . . . . . . . . . . . . . . . . . . . 1.5 Load balancing . . . . . . . . . . . . . . . . . . 1.5.1 Závˇer . . . . . . . . . . . . . . . . . . . 1.6 Failover . . . . . . . . . . . . . . . . . . . . . . 1.6.1 Failover pevného disku . . . . . . . . . . 1.6.2 Failover v´ ypoˇcetn´ıho serveru . . . . . . . 1.6.3 Failover uˇzivatelsk´ ych dat . . . . . . . . 1.6.4 Failover databáz´ı . . . . . . . . . . . . . 1.6.5 Failover server˚ u . . . . . . . . . . . . . . 1.6.6 Závˇer . . . . . . . . . . . . . . . . . . . 1.7 Zabezpeˇcen´ı . . . . . . . . . . . . . . . . . . . . 2 Vylepˇ sen´ı produkce 2.1 Náhodné s´ıt’ové v´ ypadky . . . . . . . . . . . . 2.1.1 Problém . . . . . . . . . . . . . . . . . 2.1.2 Prvotn´ı pˇr´ıˇcina . . . . . . . . . . . . . ˇ sen´ı . . . . . . . . . . . . . . . . . . 2.1.3 Reˇ 2.2 D˚ uvˇeryhodn´ y a uˇziteˇcn´ y monitorovac´ı nástroj 2.2.1 Problém . . . . . . . . . . . . . . . . . ˇ sen´ı . . . . . . . . . . . . . . . . . . 2.2.2 Reˇ

. . . . . . .

. . . . . . . . . . . . . . . . . . . . systém˚ u . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

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

. . . . . . .

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

. . . . . . .

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

. . . . . . .

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

. . . . . . .

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

. . . . . . .

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

. . . . . . .

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

. . . . . . .

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

. . . . . . .

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

. . . . . . .

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

1 1 1 1 3 4 7 7 7 8 8 10 10 11 11 11 13 13 14 15 15 15

. . . . . . .

17 17 17 18 19 19 19 20

Slovn´ık

22

A Obr´ azky

25

B Zdrojov´ e k´ ody 31 B.1 IP SNMP scanner . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

0

Kapitola 1 Z´ akladn´ı rozbor 1.1

C´ıl pr´ ace a sezn´ amen´ı s produktem

Tato práce byla vytvoˇrena s c´ılem restrukturalizace produkˇcn´ıho prostˇred´ı firmy, jeˇz se zab´ yvá v´ yvojem a bˇehem softwaru sociáln´ıch s´ıt´ı. Hlavn´ımi body zájmu z pohledu serverové infrastruktury jsou: stabilita, v´ ykonnost, failover. Z pohledu správy konfigurac´ı jde primárnˇe o: robustnost, jednoduchost, rozˇsiˇritelnost. Firma mˇela v dobˇe zapoˇcet´ı této práce nastaveny jen minimáln´ı procesy pro správu a konfiguraci server˚ u. Z tohoto d˚ uvodu bylo rozhodnuto ˇze primárn´ım prvkem této práce má b´ yt zaveden´ı procesu pro konfiguraci 1 server˚ u.

1.1.1

Port´ al

Hlavn´ı pˇredmˇet podnikán´ı firmy je sociáln´ı aplikace na kterou se v této práci budu odkazovat jako na port´ al. Ukázkovou tituln´ı stránku portálu lze vidˇet na obrázku 1.12 . Portál je prodáván jako sluˇzba a z tohoto vypl´ yvá nˇekolik d˚ usledk˚ u fungován´ı celé firmy. Spoleˇcnost mus´ı vlastnit serverovou infrastrukturu nutnou pro bˇeh této aplikace. Firma sama si mus´ı zajistit zabezpeˇcen´ı server˚ u, jejich zálohován´ı, stabilitu, instalaci aplikace a jej´ı aktualizace. Jiˇz ze samotné povahy sociáln´ıch s´ıt´ı vypl´ yvá vysok´ y poˇcet pˇr´ıstupu uˇzivatel˚ u s obˇcasn´ ymi ˇspiˇckami v návˇstˇevnosti portálu. Dále je zˇrejmé ˇze odstaven´ı produkce nen´ı u uˇzivatel˚ u portálu v´ıtan´ y jev, a proto je dobré se mu vyhnout. Uˇzivatelé dnes oˇcekávaj´ı vysok´ y standard od webov´ ych sluˇzeb, a proto je potˇreba ˇreˇsit i otázku rychlosti aplikace. V této práci bude rozebrána v´ ykonnost aplikace z pohledu server˚ u. Portál nab´ız´ı velké mnoˇzstv´ı sluˇzeb, namátkou: psan´ı ˇclánk˚ u, seskupován´ı do komunit, hromadné rozes´ılán´ı e-mail˚ u skupinám uˇzivatel˚ u, chat, diskuzn´ı fóra, fotogalerie, videa, statistiky uˇzivatelsk´ ych aktivit, a mnoho dalˇs´ıch. Z ˇsiroké nab´ıdky sluˇzeb vypl´ yvá velká mnoˇzina odpovˇednost´ı kdy je potˇreba dopˇredu promyslet d˚ usledky jakékoliv zmˇeny na cel´ y systém jako takov´ y. Nikoliv jen na jeho souˇcásti.

1.2

Dosavadn´ı ˇ reˇ sen´ı produkˇ cn´ıch server˚ u

Firma pro n´ıˇz je tato práce vytváˇrena je jiˇz nˇekolik let na trhu a dodává své produkty nˇekolika stovkám zákazn´ık˚ u. Za tuto dobu bylo jiˇz za potˇreb´ı ˇreˇsit otázky kolem infrastruktury server˚ u a problému s t´ımto tématem spojen´ ych. Pro stanoven´ı c´ıl˚ u této práce 1

Zjednoduˇsenˇe ˇreˇceno jde o vyvinut´ı softwaru, jenˇz by se dokázal postarat o konfiguraci server˚ u a vˇsech sluˇzeb potˇrebn´ ych pro bˇeh aplikace jenˇz firma vyv´ıj´ı. 2 Port´ al je upraven do stovek visu´ aln´ıch variant. Náhled je pˇriloˇzen pouze pro pˇribl´ıˇzen´ı aplikace ˇcten´ aˇri.

1

Obrázek 1.1: Ukázková tituln´ı obrazovka portálu

tedy pˇredcházela dlouhá doba seznamován´ı se s aktuáln´ım produkˇcn´ım ˇreˇsen´ım firmy. Pochopen´ı vˇsech proces˚ u firmy je pro takovouto práci velice d˚ uleˇzité. Na prvn´ı pohled ned˚ uleˇzit´ y detail m˚ uˇze zniˇcit i velice dobˇre a peˇclivˇe pˇripravovan´ y plán reorganizace. Pˇri implementaci jsme vytvoˇrili velké mnoˇzstv´ı test˚ u a simulac´ı, abychom pochopili jak bude pouˇz´ıvan´ y hardware reagovat na extrémn´ı podm´ınky ˇci jen zmˇenu zátˇeˇze. Aˇckoliv se na prvn´ı pohled m˚ uˇze jevit vytvoˇren´ı zátˇeˇzov´ ych test˚ u jako triviáln´ı záleˇzitost, opak se v praxi ukázal pravdou. Pˇrekvapivˇe velmi ˇcastou chybou bylo ˇspatné pochopen´ı c´ıle test˚ ua interpretace v´ ysledk˚ u testu. Takovéto chyby pak zp˚ usobovaly nelogické chován´ı systému pˇri implementaci nˇejakého ˇreˇsen´ı. Z´ıskané postˇrehy a zkuˇsenosti budou rozebrány dále. Na obrázku 1.2 lze vidˇet zjednoduˇsené schéma produkce firmy. Servery nepotˇrebné pro téma této práce jsou z obrázku vynechány. Tento obrázek bude postupnˇe doplˇ nován o dalˇs´ı body jeˇz budou diskutovány v dalˇs´ıch ˇca´stech práce. xen02 Vstupn´ı server pro poˇzadavky z internetu. Firewall a Virtual Private Network (VPN) server bˇeˇz´ı zde. Um´ıstˇen´ı firewallu do takto pˇredsunutého“ stroje má v´ yhodu ” v nezatˇeˇzován´ı load-balanceru. lb01 Load balancer - veˇskeré poˇzadavky na webové sluˇzby jdou pˇres tento server. On rozhodne do jaké ˇca´sti infrastruktury má poˇzadavek smˇeˇrovat. web0x V´ ypoˇcetn´ı servery3 , obsluha HTTP poˇzadavk˚ u. Kaˇzd´ y tento stroj má pˇripojen NFS svazek z file01. db0x Databázové servery, obsulah SQL dotaz˚ u. dev01 Sestavován´ı a distribuce zdrojov´ ych kód˚ u aplikace na v´ ypoˇcetn´ı servery. Takzvan´ y deploy. 3

Jiné servery v produkci samozˇrejmˇe také provádˇej´ı v´ ypoˇcty“. Poku ale bude dále v dokumentu ” odkazov´ ano na v´ ypoˇcetn´ı server, vˇzdy budou myˇsleny servery web0x.

2

Obrázek 1.2: Diagram p˚ uvodn´ıho produkˇcn´ıho schématu firmy

process01 Server zpracovávaj´ıc´ı dlouho bˇeˇz´ıc´ı u ´koly. Hromadné pos´ılán´ı e-mail˚ u, konverze dokument˚ u, . . . file01 Sd´ılen´ y prostor pro data jeˇz mus´ı b´ yt dostupná na vˇsech serverech. Pouˇz´ıvá protokol NFS ext01 Server pro podp˚ urné webové stránky jeˇz pˇr´ımo nesouvis´ı s produktem spoleˇcnosti. D´ıky viditelnosti z venku má také vlastn´ı firewall. mail01 Mail server zajiˇst’uj´ıc´ı jeden odchoz´ı uzel pro poˇstu.

1.3

V´ ybˇ er vhodn´ eho operaˇ cn´ıho syst´ emu

V´ ybˇer operaˇcn´ıho systému z velké ˇca´sti definuje v´ yslednou podobu celého produkˇcn´ıho prostˇred´ı. To kter´ y z existuj´ıc´ıch Operaˇcn´ı systém (OS) zvol´ıme nám vymezuje aplikace jeˇz bude moˇzné pouˇz´ıt. Nˇekteré aplikace totiˇz dokáˇz´ı bˇeˇzet jen na urˇcitém typu operaˇcn´ıch systém˚ u. Naˇstˇest´ı námi vybran´ y seznam potˇrebn´ ych aplikac´ı, respektive technologi´ı nen´ı 3

nijak omezuj´ıc´ı, protoˇze aplikace podporuj´ıc´ı potˇrebné technologie existuj´ı na vˇsech bˇeˇznˇe pouˇz´ıvan´ ych platformách. Jedno z prvn´ıch omezen´ı, které padne na kteroukoli skupinu rozhoduj´ıc´ı se pro ten ˇci onen produkt jsou pˇredchoz´ı zkuˇsenosti. To jak daná technologie dokázala b´ yt nápomoc´ı ˇci pˇrekáˇzkou pˇredchoz´ıch projekt˚ u jasnˇe urˇcuje nasazen´ı této v projektu dalˇs´ım. Pokud si dokáˇzeme pˇriznat ˇze nˇejak´ y ne´ uspˇech nen´ı vinou operaˇcn´ıho systému, n´ ybrˇz naˇs´ı neznalosti, pak je toto kritérium pˇri rozhodován´ı urˇcitˇe správné. Náˇs v´ ybˇer bude dále zuˇzovat rozpoˇcet projektu. Cena za operaˇcn´ı systém m˚ uˇze b´ yt kdekoliv od nuly aˇz po tis´ıce korun za instalaci. Do finanˇcn´ı stránky mus´ıme zanést i náklady na administraci a udrˇzován´ı operaˇcn´ıho systému, pˇr´ıpadné nároky na speciáln´ı hardware potˇrebn´ y pro bˇeh OS, omezen´ı na pˇr´ıpadn´ y dalˇs´ı software kter´ y je nutn´ y pro bˇeh daného operaˇcn´ıho systému a dalˇs´ı. Vˇsechny tyto hodnoty shrnuje ukazatel Total cost of ownership (TCO). Masovˇejˇs´ı rozˇs´ıˇren´ı tohoto ukazatele se datuje k roku 1987 a od této doby bylo vydáno mnoho studi´ı porovnávaj´ıc´ıch TCO jednotliv´ ych operaˇcn´ıch systém˚ u. Naneˇstˇest´ı r˚ uzné studie docház´ı k naprosto odliˇsn´ ym závˇer˚ um. Napˇr´ıklad studie R Cybersource - Linux vs. Windows - Total Cost of Ownership - Comparison[13] jednoznaˇcnˇe mluv´ı pro ˇreˇsen´ı postavená na základˇe linuxov´ ych operaˇcn´ıch systém˚ u. Oproti R

tomu porovnán´ı spoleˇcnosti Microsoft - Compare Windows to Red Hat[6] z roku 2003 ukazuje na TCO jednoznaˇcnˇe niˇzˇs´ı u ˇreˇsen´ı zaloˇzen´ ych na platformˇe Windows server. Existuj´ı i dalˇs´ı studie s opˇet naprosto odliˇsn´ ymi v´ ysledky. Vzhledem k osobn´ı zkuˇsenosti, politice firmy a stávaj´ıc´ımu ˇreˇsen´ı jsme se rozhodli zaˇradit na seznam pˇrijateln´ ych OS pouze ty jeˇz jsou zaloˇzeny na linuxu. Dalˇs´ım zaj´ımav´ ym rozhodovac´ım prvkem m˚ uˇze b´ yt spolehlivost systému. Spolehlivost nám udává jak dlouho dokáˇze dan´ y server bez odstávky bˇeˇzet. V roce 2008 provedl Institute for Advanced Professional Studies v´ yzkum této hodnoty u nejbˇeˇznˇeji pouˇz´ıvan´ ych operaˇcn´ı systém˚ u a vydal zprávu 2008 Server OS Reliability Survey[1]. V´ yn ˇatek z této zprávy je vidˇet na obrázku 1.3. Ve zprávˇe jsou uvedeny opravdu n´ızké ˇcasy odstávek koncov´ ych klient˚ u. Roˇcnˇe to dˇelá jednotky hodin. Z pˇredchoz´ıch projekt˚ u v´ıme, ˇze si vˇcasn´ ym nahláˇsen´ım odstávky sluˇzeb a naplánován´ım odstávky do noˇcn´ıch hodin m˚ uˇzeme dovolit celkovou roˇcn´ı odstávku sluˇzeb v daleko delˇs´ıch ˇcasech. Tento u ´daj nám tedy pouze poslouˇz´ı jako identifikátor pˇredpokládan´ ych odstávek dan´ ych volbou operaˇcn´ıho systému. Jelikoˇz v tomto projektu pˇredpokládáme nasazen´ı vˇetˇs´ıho poˇctu server˚ u, bude pro nás hrát d˚ uleˇzitou roli schopnost hromadné administrace v´ıce stroj˚ u. schopnost administrace OS v pˇr´ıpadˇe nouze, podpora monitorován´ı a hromadn´ ych report˚ u sluˇzeb serveru, kvalita a rozsah zdroj˚ u pro popis nestandardn´ıch stav˚ u. Naˇstˇest´ı v dneˇsn´ı dobˇe existuje velké mnoˇzstv´ı takov´ ychto nástroj˚ u pro vˇsecny bˇeˇznˇe pouˇz´ıvané operaˇcn´ı systémy, takˇze se nemus´ıme moc omezovat. Spoleˇcnˇe s schopnost´ı administrovat serverové instalace nás také bude zaj´ımat moˇznost aktualizac´ı operaˇcn´ıho systému a vˇsech d´ılˇc´ıch program˚ u. Tato vlastnost se ukáˇze jako kriticka vˇzdy v nejnevhodnˇejˇs´ı okamˇzik. A to ve chv´ıli, kdy nˇekdo nalezne bezpeˇcnostn´ı chybu v softwaru nainstalovaném na naˇsich serverech. Tehdy se ukáˇze v´ yhoda pravideln´ ych aktualizac´ı stejnˇe jako nev´ yhoda zastaralosti softwaru pro nˇekteré druhy OS.

1.3.1

Porovn´ an´ı v´ yhod jednotliv´ ych operaˇ cn´ıch syst´ em˚ u

Pros´ım berte na vˇedom´ı, ˇze v´ yhody a nev´ yhody zde uvedené jsou vázány na naˇ s´ı situaci a naˇ sim znalostem. V jin´ ych situac´ıch se v´ yhody mohou stát nev´ yhodami a naopak. Windows Server 2008 • Neznámé technologie na poli server˚ u a virtualizace 4

Obrázek 1.3: 2008 Server OS Reliability Survey

• Komerˇcn´ı, vysoké pˇr´ımé poˇca´teˇcn´ı náklady ˇ • Sirok´ a moˇznost podpory • Rozsáhlá dokumentace na jednom m´ıstˇe - MSDN Tento operaˇcn´ı systém je pro nás velkou neznámou a nemáme jeho moˇznosti dobˇre prozkˇ potˇrebn´ oumané. Cas y k jeho prozkoumán´ı by tedy byl opravdu vysok´ y. Jedná se o komerˇcnˇe prodávan´ y OS u kterého pˇredpokládáme nutnost dokoupen´ı velkého mnoˇzstv´ı dalˇs´ıch aplikac´ı, abychom mohli tento sysém efektivnˇe provozovat. Tento operaˇcn´ı systém jsme kv˚ uli v´ yˇse uveden´ ym d˚ uvod˚ um vyˇskrtli z naˇseho seznamu jiˇz na zaˇca´tku. Community enterprise operating system - CentOS • Systém zaloˇzen´ y na linuxu • Kv˚ uli stabilitˇe pouˇz´ıvá starˇs´ı software • Velmi slabá komunitn´ı podpora • Bal´ıˇcky zaloˇzené na RPM Tento operaˇcn´ı systém vycház´ı z distribude Red Hat. Zkuˇsenost s n´ım máme z jin´ ych projekt˚ u. Bohuˇzel tato zkuˇsenost je naprosto odrazuj´ıc´ı. Jedná se konkrétnˇe o zastaralost vˇetˇsiny pouˇzitého softwaru, chybˇej´ıc´ı základn´ı bal´ıˇcky v repozitáˇr´ıch, amatérská komunita s nedostateˇcnou dokumentac´ı, nepˇr´ıvˇetivé chován´ı bal´ıˇckovac´ıho systému yum. Bohuˇzel ani tento OS se nám nejevil jako vhodná volba.

5

OpenSUSE • Komunitn´ı distribuce se siln´ ym partnerem - firmou Novell • Rozsáhlá dokumentace na pˇrijatelné u ´rovni • Bal´ıˇcky zaloˇzené na RPM Red Hat Enterprise Linux for Servers • K jakémukoliv pouˇzit´ı zdarma, placená pouze podpora • Kv˚ uli stabilitˇe pouˇz´ıvá starˇs´ı software • Neznámá komunitn´ı podpora • Bal´ıˇcky zaloˇzené na RPM Zde plat´ı vˇetˇsina toho, co bylo napsáno v odstavci pro CentOS. Gentoo • Velmi kvalitn´ı, aktuáln´ı a rozsáhlá dokumentace • Aktivn´ı, vysoce vzdˇelaná komunita • Aktuáln´ı bal´ıˇcky, které obˇcas trp´ı nedostateˇcn´ ym testován´ım • Hardened profil, kter´ y zakazuje verze softwaru u kter´ ych nen´ı jistota stability a bezpeˇcnosti • Bal´ıˇckovac´ı systém umoˇzn ˇuj´ıc´ı u nˇekter´ ych bal´ıˇck˚ u paraleln´ı existenci r˚ uzn´ ych verz´ı • Rolling updates • Nároˇcná distribuce, nevhodná pro zaˇcáteˇcn´ıky • V pˇr´ıpadˇe ˇspatné pˇr´ıpravy dlouhá doba pro opraven´ı problému Gentoo je z mého pohledu velice kvalitn´ı distribuc´ı se ˇspiˇckov´ ym bal´ıˇckovac´ım systémem. Bohuˇzel v´ ymˇenou za jeho flexibilitu je i nároˇcnost na znalosti, které mus´ı systémov´ y administrátor m´ıt pro jeho bezproblémovou u ´drˇzbu. Pˇres mnoho v´ yhod které tato distribuce nab´ız´ı jsme se rozhodli od pouˇzit´ı této distribuce opustit. Zastupitelnost administrátor˚ u v projektu, jednoduché pˇredán´ı know-how pro nás byly pˇrednˇejˇs´ı. Debian • Projekt s velmi dlouhou tradic´ı, ˇsiroce rozˇs´ıˇren • Rozumn´ y bal´ıˇckovac´ı systém s dostateˇcnˇe aktualizovan´ ym software • Pˇrijatelná dokumentace, aktivn´ı komunita • Jednoduchá distribuce • Bal´ıˇcky zaloˇzené na DEB D´ıky svému rozˇs´ıˇren´ı a ˇsiroké uˇzivatelské základnˇe je Debian dobˇre funguj´ıc´ı distribuce. Obˇcas bohuˇzel naraz´ıme na komunitn´ı návody které jsou bud’ neaktuáln´ı, nebo velice amatérské. Tento jev je dan´ı za velké rozˇs´ıˇren´ı distribuce. 6

BSD, Solaris, unix Ostatn´ı zde nejmenované distribuce jsme vyˇradili na základˇe jednoduchého principu naˇs´ı neznalosti. To, ˇze jsme si vybrali k bliˇzˇs´ımu zkoumán´ı nˇekterou z v´ yˇse uveden´ ych distribuc´ı je dáno jistou zkuˇsenost´ı a historick´ ym v´ yvojem. Jin´ y ˇclovˇek m˚ uˇze m´ıt na vˇec jin´ y pohled. Nen´ı v silách ˇzádného ˇclovˇeka do detail˚ u prozkoumat vˇsechny operaˇcn´ı systémy které existuj´ı.

1.3.2

Z´ avˇ er

Firma pro n´ıˇz je tento projekt vytváˇren zpoˇcátku pouˇz´ıvala OpenSUSE - 10.3. Postupnˇe upgradovala potˇrebné servery aˇz do OpenSUSE 11.1. A v posledn´ıch letech jsou vˇsechny servery postupnˇe migrovány na Debian Lenny. Situace rozloˇzen´ı jednotliv´ ych distribuc´ı pˇred zapoˇcet´ım prac´ı je vidˇet na obrázku A.1. Stanoven´ ym c´ılem je tedy vˇsechny budouc´ı servery postavit na OS Debian. Jako dlouhodob´ y c´ıl je pak stanoveno postupnˇe nahradit vˇsechny OpenSUSE servery distribuc´ı Debian.

1.4

Virtualizace

V posledn´ıch nˇekolika letech je v IT firmách módou propagovat a implementovat takzvané virtualizované servery. Virtuáln´ı server (nˇekdy téˇz naz´ yvan´ y jako domU, kontejner ˇci hostovan´ y systém je takov´ y, jenˇz nebˇeˇz´ı pˇr´ımo na hardwaru daného poˇc´ıtaˇce. Pˇr´ımo na hardwaru pak bˇeˇz´ı takzvan´ y hardwarový stroj. Nˇekdy se mu také ˇr´ıká hostovac´ı OS, dom0 ˇci Hardware Node (HN). Virtuáln´ı server si lze velice zjednoduˇsenˇe pˇredstavit jako bˇeˇzn´ y program jenˇz bˇeˇz´ı v poˇc´ıtaˇci. T´ımto programem je ale cel´ y operaˇcn´ı systém. Takˇze pak bˇeˇz´ı jeden operaˇcn´ı systém v jiném. Virtualizace obecnˇe má nˇekolik jiˇz znám´ ych v´ yhod a nˇekolik nev´ yhod s nimiˇz je dobré se seznámit pˇred jej´ım pouˇzit´ım.

1.4.1

V´ yhody virtualizace

ˇ ren´ı prostˇ Setˇ redky Jelikoˇz bˇeˇz´ı v´ıce operaˇcn´ıch systém˚ u na jednom serveru zároveˇ n velmi ˇcasto je zapotˇreb´ı menˇs´ı mnoˇzstv´ı server˚ u neˇz to, které bychom potˇrebovali bez pouˇzit´ı virtualizace. Tato v´ yhoda nab´ yvá na v´ yznamu pokud je napˇr´ıklad potˇreba vysok´ y v´ ykon pro jeden server ve dne a pro jin´ y v noci. V´ ypoˇcetn´ı prostˇredky se mohou pˇrerozdˇelit podle aktuáln´ı potˇreby. Nˇekteré servery ze své podstaty nemaj´ı vysoké nároky na CPU/RAM. Webhousingové spoleˇcnosti ale obvykle nenab´ızej´ı malé“ konfigurace. Pokud se v´ıce tˇechto mal´ ych virtuáln´ıch stroj˚ u um´ıst´ı na jeden ” silnˇejˇs´ı HN, pak se m˚ uˇze jednat o u ´sporu v ˇra´du aˇz des´ıtek server˚ u. Flexibilita V pˇr´ıpadˇe ˇze chcete pˇridat v´ ypoˇcetn´ı prostˇredky do serveru kter´ y nen´ı virtualizovan´ y, obvykle se neobejdete bez fyzické pˇr´ıtomnosti technika v serverovnˇe a vypnut´ı serveru. V pˇr´ıpadˇe serveru virtualizovaného je pˇridán´ı napˇr´ıklad v´ıce pamˇeti otázkou nˇekolika málo pˇr´ıkaz˚ u. Obvykle ani nen´ı potˇreba vyp´ınat virtuáln´ı server. Jednoduˇ sˇ s´ı spr´ ava Kaˇzd´ y správce server˚ u se dˇr´ıve ˇci pozdˇeji setká s problémem kdy si zruˇs´ı pˇr´ıstup k serveru a jediná moˇznost jak problém opravit je fyzická pˇr´ıtomnost kohosi v serverovnˇe. Samozˇrejmˇe sluˇsné server housingové spoleˇcnosti nab´ız´ı moˇznost vzdálené správy napˇr´ıklad v podobˇe zpˇr´ıstupnˇen´ı klávesnice a monitoru serveru pˇres

7

internet. Jenˇze vˇsechny tyto ˇreˇsen´ı maj´ı urˇcitou prodlevu neˇz je vzdálená správa instalována. Pokud pouˇz´ıváte virtuáln´ı servery, pak máte pˇr´ım´ y pˇr´ıstup k jejich disku a k tlaˇc´ıtku“ restart. ” Moˇ znost omezen´ı V nˇekter´ ych prostˇred´ıch je v´ yhodné m´ıt moˇznost omezit zdroje serveru. Opˇet v pˇr´ıpadˇe fyzického serveru jde o komplikovanou proceduru. V pˇr´ıpadˇe serveru virtuáln´ıho pak o nˇekolik pˇr´ıkaz˚ u. Migrace Jelikoˇz i poˇc´ıtaˇce stárnou a jelikoˇz je pˇredpoklad ˇze Moore˚ uv zákon bude jeˇstˇe nˇekolik let platit je moˇznost jednoduchého pˇresunu OS i se vˇsemi daty velice d˚ uleˇzitá.

1.4.2

Nev´ yhody virtualizace

Administrace Virtualizace sebou pˇrináˇs´ı spoustu nov´ ych vlastnost´ı a obvykle i technologi´ı s kter´ ymi mus´ı b´ yt administrátor obeznámen. Pouˇzit´ı kaˇzdé dalˇs´ı technologie samozˇrejmˇe pˇrináˇs´ı potenciáln´ı riziko chyb a problém˚ u. V´ ykon V´ yrobci virtualizaˇcn´ıch ˇreˇsen´ı se snaˇz´ı uˇzivatele jejich produkt˚ u pˇresvˇedˇcit ˇze nákaldy na provoz virtualizace jako takové jsou nulové. Osobnˇe jsem ze zkuˇsenosti pˇresvˇedˇcen ˇze toto nen´ı pravda a ˇze v jist´ ych specifick´ ych situac´ıch m˚ uˇze b´ yt overhead virtualizace problém. Chybovost Jak jiˇz bylo ˇreˇceno v´ yˇse pouˇzit´ı virtualizace nutnˇe zesloˇzit’uje cel´ y proces správy server˚ u. Administrátor se pak m˚ uˇze omylem dopustit chyb které by u nevirtualizovaného systému ˇreˇsit nemusel. Druh´ ym typem chyb, které jsou bohuˇzel dle mé zkuˇsenosti relativnˇe ˇcasté jsou chyby v samotné virtualizaˇcn´ı technologii. Chyby tohoto charakteru se obvykle velmi ˇspatnˇe odhaluj´ı a obvykle vedou k pádu celého virtualizovaného serveru.

1.4.3

Typy virtualizace

V´ ybˇer vhodné virtualizaˇcn´ı technologie je velmi d˚ uleˇzit´ y krok pˇri stavbˇe serverové infrastruktury. Pro bezproblémov´ y bˇeh je dobré, aby vˇsechny virtualizované stroje pouˇz´ıvaly stejnou technologii. Napˇr´ıklad migrace virtuáln´ıch stroj˚ u mezi stroji fyzick´ ymi se tak velmi zjednoduˇs´ı. Samozˇrejmˇe kaˇzdá z dnes nab´ızen´ ych technologi´ı pˇrináˇs´ı jisté klady a jisté zápory. Nelze ˇr´ıci ˇze by v této oblasti existovala technologie jeˇz by pro vˇsechny pˇr´ıpady pˇredbˇehla technologie ostatn´ı. V následuj´ıc´ım srovnán´ı uvaˇzujeme pouze open source nástroje které jsou schopné bˇeˇzet pod a hostovat unixové OS a bˇeˇz´ı na platformˇe amd644 . Dnes bˇeˇznˇe pouˇz´ıvané technologie v této oblasti jsou: XEN, KVM, OpenVZ. Velmi pravdˇepodobnˇe existuj´ı i dalˇs´ı projekty které by splˇ novaly podm´ınky definované v´ yˇse. Autor tohoto dokumentu je bud’ povaˇzoval za nevyhovuj´ıc´ı, nebo je v˚ ubec neznal. KVM V IT je Kernel-based Virtual Machine (KVM) implementac´ı virtuáln´ıho stroje ” vyuˇz´ıvaj´ıc´ı jádro operaˇcn´ıho systému. Tento pˇr´ıstup obvykle pˇrináˇs´ı v´ yˇsˇs´ı v´ ykon neˇz ˇreˇsen´ı zaloˇzené na virtuáln´ıch stroj´ıch jenˇz závis´ı na ovladaˇc´ıch v uˇzivatelském prostoru. KVM se nejˇcastˇeji vztahuje k infrastruktuˇre v Linuxovém kernelu. KVM nab´ız´ı nativn´ı virtualizaci na x86 procesorech jenˇz poskytuj´ı rozˇs´ıˇren´ı Intel VT-x ˇci AMD-V. Linuxové jádro 2.6.20 jako prvn´ı obsahovalo implementaci KVM. V´ yhodou KVM je moˇznost bˇehu jakéhokoliv druhu OS nezávisle na OS v HN.“[10] 4

jinak také zn´ am´ y jako x86 64

8

OpenVZ OpenVZ je virtualizace zaloˇzená na principu kontejner˚ u[4]. Umoˇzn ˇuje vytvoˇrit velké mnoˇzstv´ı izolovan´ ych kontejner˚ u na jednom fyzickém serveru pˇriˇcemˇz zajist´ı izolaci proces˚ u. Kaˇzd´ y kontejner se chová jako samostatn´ y server. M˚ uˇze b´ yt samostatnˇe restartován, m´ıt vlastn´ı uˇzivatele, pamˇet’, procesy, i aplikace. Velkou v´ yhodou OpenVZ je ˇsiroká podpora uˇzivatelsk´ ych skript˚ u a vyuˇz´ıván´ı dalˇs´ıch technologi´ı. Otázka vytvoˇren´ı diskového odd´ılu pro um´ıstˇen´ı kontejneru je tak vyˇreˇsena pouh´ ym pˇridán´ım pˇrep´ınaˇce do pˇr´ıkazu pro vytvoˇren´ı kontejneru. Dalˇs´ı velkou v´ yhodou OpenVZ je lehkost s jakou se s danou technologi´ı pracuje. Administrátor HN má automaticky k dispozici administrátorsk´ y u ´ˇcet vˇsech virtuáln´ıch stroj˚ u. Pˇrerozdˇelován´ı v´ ypoˇcetn´ıho v´ ykonu se dˇeje za bˇehu virtuáln´ıch stroj˚ u a to vˇcetnˇe obvykle komplikovaného pˇrerozdˇelován´ı diskového prostoru. XEN XEN je jednou z nejstarˇs´ıch a nejznámˇejˇs´ıch technologi´ı na poli virtualizaˇcn´ıch nástroj˚ u. Pro bˇeh XENu je zapotˇreb´ı takzvan´ y hypervizor jenˇz se stará o zaveden´ı a chod dom0. Jelikoˇz se XEN zat´ım nedostal do oficiáln´ı vˇetve linuxového kernelu je nev´ yhodou této technologie nutnost speciáln´ıho jádra. Naˇstˇest´ı tento problém je d´ıky adopci této technologie vˇetˇsinou hlavn´ıch distribuc´ı zanedbateln´ y. XEN má sám o sobˇe základn´ı nástroje pro správu virtuáln´ıch stroj˚ u. Umoˇzn ˇuj´ı hl´ıdat aktuáln´ı vyuˇzit´ı systému jednotliv´ ymi kontejnery, provádˇet migrace i automaticky nainstalovat OS na virtuáln´ı server. V´ ybˇer virtualizaˇcn´ı technologie by nemˇel b´ yt ponechán náhodˇe. Snadno se m˚ uˇze stát ˇze aˇz po implementaci zjist´ıme ˇze bychom potˇrebovali vlastnost kterou námi adoptovaná technologie nenab´ız´ı. V pˇr´ıpadˇe tohoto projektu ale musel v´ ybˇer nejvhodnˇ ejˇ s´ıho ustoupit daleko d˚ uleˇzitˇejˇs´ımu kritériu a to zachov´ an´ı homogenity prostˇ red´ı. Homogenita je v takov´ ychto projektech velmi d˚ uleˇzitá. Administrace v´ıce druh˚ u je vˇzdy daleko sloˇzitˇejˇs´ı a pˇrináˇs´ı vˇetˇs´ı mnoˇzstv´ı chyb. Jelikoˇz firma má zabˇehnuto nemalé mnoˇzstv´ı stroj˚ u vyuˇz´ıvaj´ıc´ıch technologii XEN, zvolili jsme pro budouc´ı rozˇsiˇrován´ı infrastruktury právˇe tuto technologii. Nutno podotknout ˇze XEN se v této firmˇe osvˇedˇcil a tud´ıˇz nen´ı problém s jeho dalˇs´ım nasazován´ım. Na obrázku 1.2 jsou znázornˇeny dom0 stroje p´ıskovou barvou a domU stroje barvou ˇsedou. Vazba mezi dom0 a domU je pak znázornˇena ˇsedou pˇreruˇsovanou ˇca´rou. Na schématu si lze povˇsimnout jedné zvláˇstnosti. A to sice virtualizace 1:1. Neboli nasazen´ı jednoho virtuáln´ıho stroje na jednom stroji fyzickém. Zkuˇsenost z tohoto nasazen´ı je následuj´ıc´ı: • M´ırnˇe vzrostla komplikovanost administrace. M´ısto aktualizace a konfigurace jednoho mus´ı sysadmin spravovat dva operaˇcn´ı systémy. • Obˇcasnˇe vznikaj´ı pády systému zp˚ usobené pˇr´ımo XENem. • Za dobu existence produkˇcn´ıho prostˇred´ı popsaného v´ yˇse nebylo zapotˇreb´ı provádˇet migraci stroje. K potˇrebˇe provést migraci nedoˇslo z r˚ uzn´ ych d˚ uvod˚ u. Jednak pˇrechodem 5 na jinou distribuci OS. Pak také d´ıky potˇrebˇe r˚ ustu do ˇs´ıˇrky souˇcasnˇe s upgradem 6 serveru do v´ yˇsky . A v neposledn´ı ˇradˇe d´ıky zastarán´ı daného ˇreˇsen´ı, jenˇz vedlo k manaˇzerskému rozhodnut´ı postavit dan´ y server znovu. Ukazuje se, ˇze v nˇekter´ ych pˇr´ıpadech tento postup uˇsetˇr´ı spoustu ˇcasu. • Dle studie A Performance Comparison of Hypervisors[8] má pouˇzit´ı XENu za následek jistou v´ ykonostn´ı penalizaci. Firma nikdy nedˇelala test propadu v´ ykonosti d´ıky 5 6

R˚ ust do ˇs´ıˇrky - Rozdˇelen´ı sluˇzby mezi v´ıce server˚ u. Obvykle spojeno se zmˇenami v topologii. R˚ ust do v´ yˇsky - v´ ymˇena serveru za v´ ykonˇejˇs´ı.

9

pouˇzit´ı virtualizace, ale dle zkuˇsenost´ı z extern´ıch referenc´ı pˇredpokládáme ˇze bude ˇcinit cca 5 − 10% v závislosti na typu pouˇzité virtualizaˇcn´ı technologie.

1.4.4

Z´ avˇ er

D´ıky v´ yˇse uveden´ ym d˚ uvod˚ um doˇslo k následuj´ıc´ım zmˇenám v pˇr´ıstupu k administraci a správˇe server˚ u: Postupná eliminace virtualizace 1:1 v m´ıstech kde evidentnˇe nen´ı potˇreba. Napˇr´ıklad v´ ypoˇcetn´ı servery (web02, web03) a databázové servery (db01, db02, db03) pro nás jsou jasn´ ym pˇr´ıkladem ˇspatnˇe uˇzité virtualizace 1:1. Tyto virtuáln´ı servery totiˇz jiˇz naplno vyuˇz´ıvaj´ı vˇsech v´ ypoˇcetn´ıch prostˇredk˚ u server˚ u fyzických na kter´ ych bˇeˇz´ı. Pravdˇepodobnost ˇze tento fyzick´ y server by hostoval nˇejak´ y dalˇs´ı domU je tedy naprosto minimáln´ı. Souˇcasnˇe je minimáln´ı pravdˇepodobnost komplikac´ı pˇri pˇresunu dané instance OS na nov´ y (v´ ykonˇejˇs´ı) hardware. Z povahy pouˇzitého server-housingu jde totiˇz pouze o sekvenci u ´kon˚ u: vypnut´ı serveru, vyndán´ı pevn´ ych disk˚ u, namontován´ı pevn´ ych disk˚ u do nového serveru, zapojen´ı nového serveru. Dále je pravdˇepodobnost nutnosti migrace dané instance OS k jinému poskytovateli server-housingu velmi malá. A to z d˚ uvodu nutnosti udrˇzen´ı minimáln´ı odezvy mezi jednotliv´ ymi servery. Odezva na m´ıstn´ı 100Mbit lince je obvykle okolo 0.5ms, odezva na 1Gbit lince pak b´ yvá 0.1ms a doba odezvy mezi jednotliv´ ymi server-housingov´ ymi spoleˇcnostmi nab´ yvá aˇz 30ms. Takovéto zpoˇzedˇen´ı je pro hladk´ y bˇeh aplikace naprosto nepˇr´ıpustné a je tedy nutné hostovat vˇsechny servery pˇr´ımo zodpovˇedné za bˇeh produkce udrˇzet co nejbl´ıˇze“ u sebe. ”

1.5

Load balancing

V poˇcátku v´ yvoje vˇetˇsiny webov´ ych projekt˚ u je pravdˇepodobné ˇze se aplikace vejde na jeden server. Kódy aplikace, databáze, HTTP server, i uˇzivatelská data. Ve chv´ıli kdy aplikace pˇreroste v´ ykon hardwaru serveru obvykle se zakoup´ı server vˇetˇs´ı (v´ ykonnˇejˇs´ı). Pokud aplikace pˇreroste i tento server, zakoup´ı se jeˇstˇe v´ ykonnˇejˇs´ı. A tak dále. Toto koleˇcko bohuˇzel nelze opakovat donekoneˇcna. V´ ykon jednoho serveru je shora omezen´ y a v jednu chv´ıli se dostaneme do bodu kdy jiˇz dostupné Hardware (HW) technologie nestaˇc´ı. Tento typ ˇskálován´ı je obecnˇe znám´ y jako ˇskálován´ı do v´ yˇsky, nebo-li ”scale up”. Proto se obvykle pˇristupuje k ˇskálován´ı do ˇs´ıˇrky nebo-li ”scale out”. Pˇri tomto typu ˇskálován´ı jsou pˇridávány do systému dalˇs´ı servery a zátˇeˇz je rovnomˇernˇe rozdistribuována mezi tyto servery. V´ yhodou tohoto ˇreˇsen´ı je ˇze má obecnˇe daleko vˇetˇs´ı ˇskálovatelnost7 . Nav´ıc nav´ yˇsen´ı v´ ykonu touto metodou v zabˇehnutém systému nevyˇzaduje ˇzádnou, nebo pouze minimáln´ı odstávku. Stav infrastruktury jenˇz byl pˇred zapoˇcet´ım prac´ı na tomto projektu lze vidˇet na obrázku A.2. Jedná se o postupnou pˇrirozenou evoluci kdy zvˇetˇsuj´ıc´ı se sluˇzby jsou postupnˇe odsouvány na vlastn´ı servery (process01, mail01 ). Tento krok je logick´ y a velmi odlehˇcil jak pˇret´ıˇzen´ ym v´ ypoˇcetn´ım server˚ um, tak administrátor˚ um jenˇz mohou tyto ’ sluˇzby obsluhovat zvláˇst . HTTP nebo HTTPS poˇzadavek do infrastruktury firmy vcház´ı pˇres hraniˇcn´ı stroj xen02. Jelikoˇz internet nen´ı ani zdaleka poklidné m´ısto s uˇzivateli kteˇr´ı by mˇeli dobré u ´mysly je nutné pˇredsunout pˇred jakékoliv zpracován´ı dat z vnˇejˇsku infrastruktury firewall. xen02 pak dále pˇredá poˇzadavek na lb01, kter´ y slouˇz´ı k rozdistribuován´ı zátˇeˇze rovnomˇernˇe mezi v´ ypoˇcetn´ı servery (load balancing). Za povˇsimnut´ı stoj´ı fakt ˇze dále 7

Schopnost dané technologie pˇr´ır˚ ustkov´ ym zp˚ usobem zvyˇsovat sledované parametry v pˇr´ıpadˇe, ˇze nastane takov´ a potˇreba.

10

jiˇz putuje pouze HTTP poˇzadavek. Krom v´ yhody znaˇcnˇe zjednoduˇsené konfigurace je v tomto ˇreˇsen´ı v´ yhoda správného rozm´ıstˇen´ı zátˇeˇze. lb01 pouze pˇreb´ırá HTTPS poˇzadavky, rozbal´ı je, urˇc´ı c´ılov´ y v´ ypoˇcetn´ı server a poˇsle dál jako HTTP poˇzadavek. C´ılov´ y v´ ypoˇcetn´ı server se tak nemus´ı starat o odstraˇ nován´ı SSL/TLS vrstvy. Dalˇs´ı v´ yhodou tohoto ˇreˇsen´ı je failover, kter´ y pˇrináˇs´ı existence v´ıce v´ ypoˇcetn´ıch server˚ u. Pokud je napˇr´ıklad web02 vyˇrazen z provozu, pak jeho práci automaticky pˇrevezme web03. V´ ypoˇcetn´ı servery dále poˇzaduj´ı data od databázov´ ych server˚ u. Jelikoˇz velikost jedné databáze zat´ım nepˇresáhla velikost jednoho databázového stroje, nebylo zat´ım zapotˇreb´ı load balancing8 na u ´rovni databáz´ı ˇreˇsit. Webov´ y server se rozhodne pro správnou databázi na základˇe konfigurace. Tyto konfigurace se nacház´ı na sd´ıleném diskovém prostoru jenˇz je mountován pomoc´ı protokolu NFS. Tento fakt zachycuje obrázek A.3. Zákaznické konfigurace samozˇrejmˇe nen´ı nezbytnˇe nutné distribuovat pomoc´ı sd´ıleného filesystému, ale toto ˇreˇsen´ı znaˇcnˇe zjednoduˇs´ı jejich správu kdy zmˇenou na jednom m´ıstˇe dojde k okamˇzité zmˇenˇe na vˇsech m´ıstech.

1.5.1

Z´ avˇ er

Schopnost aplikace ˇskálován´ı do ˇs´ıˇrky je pro tento projekt velmi d˚ uleˇzitá a z obecného pohledu velmi v´ yhodná. Dává nám relativnˇe jednoduchou cestu zvyˇsován´ı v´ ykonu. Nelze ale oˇcekávat lineárn´ı nár˚ ust v´ ykonu spoleˇcnˇe s poˇctem zapojen´ ych v´ ypoˇcetn´ıch server˚ u. Brzy se totiˇz objev´ı dalˇs´ı u ´zká hrdla v podobˇe propustnosti s´ıtˇe, schopnost´ı databáz´ı ˇci sd´ıleného diskového prostoru. Problémy na které jsme narazili pˇri rozˇsiˇrován´ı infrastruktury budou rozebrány dále.

1.6

Failover V IT se pod pojmem failover rozum´ı schopnost systému automaticky pˇrepnout na redundantn´ı server, systém ˇci poˇc´ıtaˇcovou s´ıt’ pˇri poruˇse nebo abnormáln´ım vypnut´ı dˇr´ıve bˇeˇz´ıc´ı aktivn´ı aplikace, serveru, systému ˇci s´ıtˇe. Failover nastává bez lidského zásahu a obvykle bez varován´ı.[9]

Nad systémem jenˇz by jako celek beze zbytku splˇ noval v´ yˇse uvedenou definici by jistˇe zajásal kaˇzd´ y systémov´ y administrátor. Bohuˇzel vybudován´ı takovéto infrastruktury stoj´ı ´ velké mnoˇzstv´ı ˇcasu a u ´sil´ı. Uprava jiˇz existuj´ıc´ıho produkˇcn´ıho systému, jenˇz nebyl takto od zaˇca´tku budovan´ y, je pak jeˇstˇe mnohem nároˇcnˇejˇs´ı. Je proto velmi dobré si na zaˇca´tku budován´ı rozdˇelit produkci na ˇca´sti jenˇz mohou potenciálnˇe selhat a u tˇechto pak urˇcit zda je nutn´ y failover ˇci ne. Pˇr´ıkladem kdy je dobré m´ıt failover je v´ ypoˇcetn´ı server webov´ ych stránek. Nedostupnost webov´ ych stránek je pro firmu, vydˇelávaj´ıc´ı na webové platformˇe velk´ y problém. Naopak celkem zbyteˇcné je zálohovat server provádˇej´ıc´ı zpracován´ı dávkov´ ych operac´ı. Pozdrˇzen´ı odeslán´ı hromadn´ ych e-mail˚ u, ˇci vytvoˇren´ı náhled˚ u u vide´ı, je velmi dobˇre tolerovatelné. Nyn´ı by bylo dobré si probrat nˇekolik pˇr´ıpad˚ u ve kter´ ych se bˇeˇznˇe vyuˇz´ıvá failover.

1.6.1

Failover pevn´ eho disku

Pokud selˇze systémov´ y disk serveru, m˚ uˇze se doba obnovy havárie pohybovat kdekoliv od nˇekolika málo minut aˇz po nˇekolik hodin. V nˇekter´ ych pˇr´ıpadech dlouhá obnova nevad´ı, ale ˇcas ˇclovˇeka na tento u ´kon vynaloˇzen´ y je zbyteˇcnˇe ztracen´ y. Nejbˇeˇznˇejˇs´ım ˇreˇsen´ım failoveru 8

Spr´ avnˇejˇs´ı pojem by zde byl clustering“. ”

11

Obrázek 1.4: RAID 1

pevného disku je Redundant Array of Independent Disks (RAID). RAID zjednoduˇsenˇe ˇreˇceno vezme data jenˇz by mˇela b´ yt zapsána na disk a urˇcit´ ym zp˚ usobem je zap´ıˇse na v´ıce disk˚ u. Podle zp˚ usobu zápisu je pak RAID dˇelen na podkategorie. Nás bude zaj´ımat RAID 1 jenˇz je dle definice z wikipedie[12]: Nejjednoduˇsˇs´ı ale pomˇernˇe efektivn´ı ochrana dat. Provád´ı se zrcadlen´ı (mirroring) obsahu disk˚ u. Obsah se souˇcasnˇe zaznamenává na dva disky. V pˇr´ıpadˇe v´ ypadku jednoho disku se pracuje s kopi´ı, která je ihned k dispozici. Ukázku RAID 1 lze vidˇet na obrázku 1.4. RAID 1 nás zaj´ımá pˇredevˇs´ım proto, ˇze zajiˇst’uje pro náˇs pˇr´ıpad potˇrebn´ y failover. Souˇcasnˇe je d´ıky automatické dodávce server˚ u se dvˇema totoˇzn´ ymi disky u námi pouˇzitého server-housingu RAID 1 nejjednoduˇsˇs´ım a finanˇcnˇe nejménˇe nároˇcn´ ym ˇreˇsen´ım. Ohlednˇe souboje softwarov´ y RAID vs hardwarov´ y RAID toho bylo jiˇz napsáno mnoho. Kdyˇz pomineme ˇclánky spoleˇcnost´ı vyv´ıjej´ıc´ı moduly hardwarového RAIDu a ˇclánky v´ yvojáˇr˚ u komerˇcn´ıch linuxov´ ych distribuc´ı, jde obvykle o osobn´ı zkuˇsenost t´ ymu kter´ y danou implementaci pˇripravuje. A na základˇe této zkuˇsenosti je pak vydáno rozhodnut´ı. Pomˇernˇe pˇekn´ y nestrann´ y ˇclánek k této tématice byl v roce 2008 vydán na serveru http://linux.com [5]. Osobn´ı zkuˇsenosti autora by pak bylo moˇzno shrnout takto: • HW RAID vyˇzaduje rozsáhlé studován´ı dokumentace a ovládán´ı obsluˇzného softwaru. • Ani relativnˇe drah´ y modul HW RAIDu od renomované firmy nemus´ı znamenat jistotu bezpeˇc´ı dat. • Komplexita pˇridaná SW RAIDem je minimáln´ı. • Jednotnost pˇr´ıstupu k diagnostice SW RAIDu a jednotnost jeho administrace velmi zjednoduˇsuje u ´drˇzbu vˇetˇs´ıho mnoˇzstv´ı stroj˚ u. • Oproti server˚ um bez RAIDu nebylo pozorováno ˇzádné kritické zpomalen´ı na serverech s RAIDem. D´ıky tˇemto vyjmenovan´ ym a nˇekolika dalˇs´ım zkuˇsenostem jsme se rozhodli pro nasazen´ı SW RAIDu na vˇsech produkˇcn´ıch serverech. Jiná skupina by d´ıky jin´ ym argument˚ um mohla doj´ıt k zcela odliˇsnému závˇeru.

12

Velmi zaj´ımavou studii na téma ˇzivotnosti rotaˇcn´ıch mechanick´ ych pevn´ ych disk˚ u vydala v roce 2007 spoleˇcnost Google pod názvem Failure Trends in a Large Disk Drive Population[2]. V této studii stoj´ı za povˇsimnut´ı dva body: 1. Disk selˇze s relativnˇe vysokou pravdˇepodobnost´ı v prvn´ıch tˇrech mˇes´ıc´ıch fungován´ı. Pokud neselˇze v tomto ˇcase je velká pravdˇepodobnost ˇze bude fungovat aˇz do doby v´ ymˇeny za novˇejˇs´ı model, ˇci kompletn´ı v´ ymˇeny serveru. 2. M´ırnˇe zv´ yˇsená provozn´ı teplota pevnému disku témˇeˇr nevad´ı. Ba naopak n´ızké provozn´ı teploty pˇrinesly kratˇs´ı ˇzivotnost mechanick´ ych pevn´ ych disk˚ u.

1.6.2

Failover v´ ypoˇ cetn´ıho serveru

Jak jiˇz bylo probráno v kapitole 1.2 a 1.5 je pro naˇse v´ ypoˇcetn´ı prostˇred´ı velmi d˚ uleˇzitá schopnost nepˇreruˇseného bˇehu s v´ ypadkem jakéhokoliv v´ ypoˇcetn´ıho stroje. V´ ypadky server˚ u se stávaj´ı a nelze jim nikdy stoprocentnˇe zabránit. V´ ypadek m˚ uˇze nastat d´ıky poruˇse 9 ’ hardwaru, selhán´ı disku , v´ ypadku na s´ıt ovém segmentu, selhán´ı ze strany aplikac´ı ˇci operaˇcn´ıho systému, nebo jen o pouhou“ chybu v konfiguraci serveru. ” V pˇr´ıpadˇe ˇze bychom byli odkázáni pouze na jeden v´ ypoˇcetn´ı stroj a doˇslo by k jeho selhán´ı, pak se aplikace jako celek jevila jako nedostupná. Tomuto nepˇr´ıjemnému jevu bylo zabránˇeno pˇredsunut´ım load balanceru pˇred vˇsechny v´ ypoˇcetn´ı servery. Tuto situaci znázorˇ nuje obrázek 1.5. Vlastnosti tohoto ˇreˇsen´ı jsou následuj´ıc´ı: • V pˇr´ıpadˇe v´ ypadku kteréhokoliv v´ ypoˇcetn´ıho serveru, pˇrevezme automaticky jeho práci jin´ y. • Zátˇeˇz je rovnomˇernˇe rozdˇelena mezi v´ ypoˇcetn´ı servery a nedocház´ı tak k jevu pˇret´ıˇzen´ı jednoho, zat´ımco ostatn´ı nemaj´ı co na práci. • Nam´ısto nˇekolika m´ıst jejichˇz v´ ypadkem by byla aplikace nedostupná vznikl Single Point Of Failure (SPOF) v podobˇe load balanceru. Tato situace samozˇrejmˇe nen´ı ideáln´ı, ale je rozhodnˇe lépe kontrolovatelná. • Odstávky v´ ypoˇcetn´ıch server˚ u nejsou v tomto prostˇred´ı problém. Toto je velmi d˚ uleˇzit´ y fakt z d˚ uvodu aktualizace jádra, pov´ yˇsen´ı distribuce, ˇci v´ ymˇeny disku. Administrátoˇri budou m´ıt nav´ıc volnˇejˇs´ı ruce k experimentován´ı pro r˚ uzné nastaven´ı systému, softwaru, ˇci aplikace samotné. Nemus´ı se totiˇz bát ˇze by chybn´ ym zásahem do systému ohrozili produkci.

1.6.3

Failover uˇ zivatelsk´ ych dat

Nainstalovat aplikaci na kaˇzd´ y v´ ypoˇcetn´ı server je relativnˇe snadná záleˇzitost. Instalace aplikace lokálnˇe na kaˇzd´ y server je v´ yhodná hned z nˇekolika d˚ uvod˚ u. Je zrychleno naˇc´ıtán´ı aplikace do pamˇeti daného v´ ypoˇcetn´ıho serveru. Provoz tohoto serveru nen´ı pak nijak závisl´ y na jin´ ych serverech. A v neposledn´ı ˇradˇe tak vzniká moˇznost doˇcasn´ ych experi10 mentáln´ıch u ´prav pˇr´ımo na produkci. 9

Teoreticky jde jen o speci´ aln´ı pˇr´ıpad poruchy hardwaru“, ale v IT jde o tak specifick´ y jev, ˇze jsem ” ho radˇeji zd˚ uraznil. 10 Posledn´ı jmenovan´ y bod nen´ı sice tak ˇcast´ y a ani nen´ı pˇr´ıliˇs populárn´ı, ale pro nalezen´ı chyb simulovateln´ ych pouze na produkˇcn´ıch serverech b´ yvá obˇcas jedin´ ym ˇreˇsen´ım.

13

Obrázek 1.5: Load balancer

Pokud jde ale o distribuci uˇzivatelsk´ ych dat, nen´ı situace tak jednoduchá. Uˇzivatelsk´ ymi daty jsou myˇsleny dokumenty, obrázky, ˇsablony, kaskádové styly a podobné jenˇz do systému nahraj´ı sami uˇzivatelé, ˇci zákazn´ıci jenˇz si aplikaci objednali. Nejv´ yhodnˇejˇs´ı by samozˇrejmˇe bylo m´ıt data uloˇzena na daném v´ ypoˇcetn´ım serveru jenˇz se o daného zákazn´ıka stará. Toto bohuˇzel z principu popsaném v kapitole 1.6.2 nen´ı moˇzné. Kteréhokoliv zákazn´ıka m˚ uˇze obsluhovat kter´ ykoliv v´ ypoˇcetn´ı server, a proto nen´ı moˇzné data ukládat lokálnˇe. V p˚ uvodn´ım produkˇcn´ım ˇreˇsen´ı byla data distribuována pˇres protokol NFS. Network File System (NFS) je internetov´ y protokol pro vzdálen´ y pˇr´ıstup k ’ soubor˚ um pˇres poˇc´ıtaˇcovou s´ıt . Protokol byl p˚ uvodnˇe vyvinut spoleˇcnost´ı Sun Microsystems v roce 1984, v souˇcasné dobˇe má jeho dalˇs´ı v´ yvoj na starosti organizace Internet Engineering Task Force (IETF). Funguje pˇredevˇs´ım nad transportn´ım protokolem UDP, avˇsak od verze 3 je moˇzné ho provozovat také nad protokolem TCP. V praxi si m˚ uˇzete prostˇrednictv´ım NFS klienta pˇripojit disk ze vzdáleného serveru a pracovat s n´ım jako s lokáln´ım. V prostˇred´ı Linuxu se jedná asi o nejpouˇz´ıvanˇejˇs´ı protokol pro tyto u ´ˇcely.[11] V p˚ uvodn´ım ˇreˇsen´ı byl jako server pro uˇzivatelská data pouˇzit file01 jak je vidˇet na obrázku A.3. Pouˇzit´ı NFS pro file01 ˇreˇs´ı pouze otázku distribuce, ale nijak neˇreˇs´ı problém failoveru uˇzivatelsk´ ych dat. Nav´ıc je dobré, si uvˇedomit ˇze d´ıky faktu, ˇze jsme si o pár ˇra´dk˚ u v´ yˇse dokázali nutnost“ pouˇzit´ı load balanceru, jsme fakticky vytvoˇrili dalˇs´ı SPOF ” v podobˇe file01. Pokud nep˚ ujde file01, pak budou ovlivnˇeni vˇsichni zákazn´ıci. Pokud bychom mˇeli ˇreˇsen´ı bez load balanceru (zmiˇ nované v´ yˇse), pak bychom se do takovéto situace v˚ ubec nedostali. Failover uˇzivatelsk´ ych dat je tedy jeden z bod˚ u, jenˇz je souˇcást´ı praktické ˇcásti této práce a bude tedy do detail˚ u rozebráno dále.

1.6.4

Failover datab´ az´ı

Firma pouˇz´ıvá pro ukládán´ı dat primárnˇe databázové servery ”MySQL”. Jedná se pˇredevˇs´ım o historické rozhodnut´ı, podpoˇrené pˇredchoz´ımi zkuˇsenostmi. D´ıky vysoké stabilitˇe databáz´ı ”MySQL” firma nemusela failover databáz´ı ˇreˇsit. Na obrázku 1.2 je naznaˇceno rozm´ıstˇen´ı databázov´ ych server˚ u. Nejedná se o clusterované ˇreˇsen´ı. Jde tedy pouze o situaci n zákazn´ık˚ u na m stroj´ıch, kde n > m. Jak uˇz bylo v´ yˇse ˇreˇseno, ˇzádn´ y zákazn´ık svoj´ı databáz´ı zat´ım nepˇresáhl v´ ykon jednoho databázového serveru. Nen´ı tedy nutné ˇreˇsit clustering, ale pouze failover. Ten bude rozebrán v dalˇs´ıch kapitolách. 14

1.6.5

Failover server˚ u

K selhán´ı hardwaru docház´ı v IT naprosto bˇeˇznˇe a nemus´ı se jednat jen o pevné disky. Zaˇzili jsme vyhoˇren´ı“ s´ıt’ové karty, procesoru, základn´ı desky, ale i routeru a RAID ˇradiˇce. ” Jelikoˇz pˇredmˇetem podnikán´ı této firmy nen´ı správa a u ´drˇzba hardwaru a s´ıt’ové infrastruktury, byl uˇcinˇen logick´ y krok pˇrenechán´ı správy HW infrastruktury jiné firmˇe. Jedná se o obyˇcejn´ y server-housing u kterého jsou pronajaty jejich vlastn´ı servery. Toto ˇreˇsen´ı má mnoho v´ yhod: • Firma nemus´ı vydávat vysoké ˇca´stky pˇri poˇr´ızen´ı nového serveru. • Firma si pronaj´ımá server jako celek, takˇze provozovatel server housingu je odpovˇedn´ y za jeho bezvadnost. Tud´ıˇz odpadnou starosti a náklady na v´ ymˇenu komponent server˚ u. • Nároky na v´ ykon server˚ u se postupnˇe zvyˇsuj´ı a dnes zakoupen´ y v´ ykonn´ y server je za rok povaˇzován sv´ ym v´ ykonem za pr˚ umˇern´ y. Serverhousingová firma samozˇrejmˇe ˇcasem zakoup´ı v´ ykonnˇejˇs´ı servery jeˇz za vynaloˇzen´ı minimáln´ıch náklad˚ u nahrad´ı ty stávaj´ıc´ı. • Vzhledem k obvykle nemalé dojezdové vzdálenosti k serverovnˇe je v´ yhodn´ y fakt ˇze veˇskeré servisn´ı zásahy budou ˇreˇsit technici tˇret´ı strany.

1.6.6

Z´ avˇ er

Nelze ˇr´ıci, ˇze by bylo moˇzné nalézt ˇreˇsen´ı pro failover obecnˇe. Dokonce nelze ani ˇr´ıci jak obecnˇe vyˇreˇsit failover té ˇci oné sluˇzby. Vˇzdy záleˇz´ı na konkrétn´ım produktu, pouˇzitém hardwaru, ˇci vyuˇz´ıvan´ ych technologi´ıch. Nˇekde se prax´ı ukáˇze ˇze okrajová sluˇzba m˚ uˇze znefunkˇcnit systém jako celek, a proto mus´ı b´ yt zálohovaná. Jinde naopak m˚ uˇze doj´ıt k situaci, ˇze v´ ypadek sluˇzby jenˇz se zdá kl´ıˇcovou pro bˇeh celého systému, vlastnˇe v˚ ubec 11 nevad´ı a nijak neohroz´ı produkci . V textu v´ yˇse jsou tedy rozebrány hlavn´ı prvky serverového prostˇred´ı, jenˇz pro bezv´ ypadkové fungován´ı aplikace firmy potˇrebuj´ı failover. V textu dále pak bude rozebráno, jak jsme daná ˇreˇsen´ı aplikovali v praxi.

1.7

Zabezpeˇ cen´ı

U rychle se vyv´ıjej´ıc´ıch projekt˚ u autoˇri ˇcasto v˚ ubec, nebo jen velmi povrchnˇe dbaj´ı na zabezpeˇcen´ı. Je to chyba a obvykle se autor˚ um dˇr´ıve ˇci pozdˇeji vymst´ı. Zabezpeˇcen´ı opˇet m˚ uˇze prob´ıhat na nˇekolika u ´rovn´ıch. Velmi dobr´ y postup pro definován´ı potˇrebn´ ych prvk˚ u zabezpeˇcen´ı je metoda otázek. Lidé jenˇz vytváˇr´ı prostˇred´ı pro bˇeh projektu, se navzájem ptaj´ı na jakékoliv otázky jenˇz je k zabezpeˇcen´ı napadnou. Sep´ıˇs´ı je na pap´ır. Seˇrad´ı do skupin podle tématicky podobn´ ych a pokus´ı se navrhnout nejlépe jedno opatˇren´ı jenˇz pokryje celou skupinu. Takov´ ymi otázkami m˚ uˇze b´ yt napˇr´ıklad: • Jak zajist´ıme ˇze se do databáze nebude moci nabourat neoprávnˇen´ y uˇzivatel pˇres ”brute force” u ´tok? • Jak zajist´ıme ˇze uˇzivatel jenˇz zciz´ı heslo k databázi nebude moci tohoto hesla vyuˇz´ıt k stahován´ı citliv´ ych dat? 11

Toto tvrzen´ı se zd´ a celkem paradoxn´ı, ale na pˇr´ıkladu dále bude vysvˇetleno.

15

• Jak doc´ıl´ıme toho, aby u ´toˇcn´ık jenˇz z´ıskal pˇr´ıstup k sluˇzbám serveru nemohl pole svého vlivu rozˇsiˇrovat? • Jak zjist´ıme ˇze se nˇekdo pokouˇs´ı sluˇzby serveru kompromitovat? • Jak odhal´ıme bezpeˇcnostn´ı chyby v naˇs´ı aplikaci? • Jak odhal´ıme bezpeˇcnostn´ı chyby v aplikac´ıch pouˇz´ıvan´ ych na serverech? • Jak zabrán´ıme zneuˇzit´ı bezpeˇcnostn´ıch chyb bˇeˇznˇe pouˇz´ıvan´ ych Open Source Software (OSS) aplikac´ı? Toto je samozˇrejmˇe pouze ilustraˇcn´ı seznam otázek. Ve skuteˇcnosti b´ yvá daleko delˇs´ı a vytváˇren´ y za pochodu“. Námi nalezené skupiny otázek stran zabezpeˇcen´ı a jejich ˇreˇsen´ı ” budou probrány v dalˇs´ıch kapitolách. Samostatnou kapitolou jenˇz u ´zce souvis´ı se zabezpeˇcen´ım je pak monitoring. Mnoho lid´ı tyto dva pojmy velmi snadno spoj´ı v jedin´ y bod. Dle mého názoru jde ale o dvˇe velmi odliˇsné discipl´ıny. Osobnˇe bych tyto prvky definoval jako: Zabezpeˇ cen´ı Slouˇz´ı k ochranˇe systému, aplikace ˇci dat pˇred známými vlivy ˇci u ´toky. Slouˇz´ı jako prevence pˇred náhodn´ ymi ˇci c´ılen´ ymi pokusy o infiltrován´ı infrastruktury produkce. Monitoring Slouˇz´ı k sledován´ı hodnot systému a jeho log˚ u pro odhalen´ı znám´ ych i neznámých nebezpeˇc´ı. Monitoring znám´ ych problém˚ u lze obvykle definovat jednoduchou sadou pravidel. Monitoring neznámých problém˚ u je pak obvykle zaloˇzen na sledován´ı a anal´ yze odchylek v standardn´ıch hodnotách systému. Parsován´ı a anal´ yze systémov´ ych a aplikaˇcn´ıch log˚ u. Jednotlivé prvky a ˇreˇsen´ı monitorován´ı pouˇzité pˇri ˇreˇsen´ı této práce budou probrány v dalˇs´ıch kapitolách.

16

Kapitola 2 Vylepˇ sen´ı produkce Hlavn´ı motivac´ı pro vznik této práce, bylo rozˇsiˇrován´ı aplikace, jenˇz mˇelo za následek rozˇsiˇrován´ı serverové infrastruktury za u ´roveˇ n, jeˇz by bylo moˇzné zvládnout dˇelat jen tak na kolenˇe“. Tato situace si vyˇza´dala vznik specializované pracovn´ı pozice takzvaného ” konfiguraˇcn´ıho manaˇzera, jenˇz má za u ´kol dohl´ıˇzet na veˇskeré prvky produkce od instalace aplikace, pˇres softwarovou v´ ybavu aˇz po smˇerován´ı paket˚ u na s´ıti. Ve chv´ıli, kdy konfiguraˇcn´ı manaˇzer nastoup´ı do své práce jako prvn´ı by se mˇel seznámit s kaˇzd´ ym detailem produkce jenˇz by ho mohl pˇri práci jen trochu zaj´ımat. Nastaven´ı routovac´ıch tabulek, konfigurace firewallu, pouˇzité distribuce OS, verze distribuc´ı OS, zp˚ usob instalace aplikace, software nainstalovan´ y na jednotliv´ ych serverech, software instalovan´ y mimo bal´ıˇckovac´ı systém, nastaven´ı virtuáln´ıch stroj˚ u, speciáln´ı záznamy v /etc/hosts, nastaven´ı Domain Name Server (DNS) server˚ u, konfigurace a u ´ˇcel proxy server˚ u, zp˚ usob správy konfigurac´ı, proces aktualizace server˚ u, proces vzdálené administrace server˚ u, nastaven´ı monitorován´ı prostˇred´ı, rozloˇzen´ı know-how o produkci mezi zamˇestnanci firmy, spolehlivost jednotliv´ ych sluˇzeb a server˚ u, známé a neznámé problémy produkce, kritické servery a sluˇzby pro bˇeh produkce, krizové kontakty. . . V´ yˇcet by mohl pokraˇcovat jeˇstˇe mnohem dále. Pro jinou firmu by byl tento seznam odliˇsn´ y, ale velmi pravdˇepodobnˇe by nˇekteré body sd´ılel se seznamem uveden´ ym v´ yˇse. Je d˚ uleˇzité si tedy uvˇedomit ˇze objem znalost´ı potˇrebn´ y pro rozumné zapracován´ı do pozice konfiguraˇcn´ıho manaˇzera je obrovsk´ y a odv´ıj´ı se od potˇreb dané firmy. Abychom pronikli do prostˇred´ı námi zkoumané firmy a do koresponduj´ıc´ıch potˇreb po pozici konfiguraˇcn´ıho manaˇzera, uvedeme si nˇekolik zaj´ımav´ ych problém˚ u na neˇz jsem pˇri ˇ sen´ı zde uvedená se za dané situace s dan´ práci narazil a na jejich ˇreˇsen´ı. Reˇ ymi prostˇredky jevila vˇzdy jako nejvhodnˇejˇs´ı. Pokus´ım se vˇzdy i vysvˇetlit jaká byla motivace právˇe toho ˇci onoho ˇreˇsen´ı.

2.1 2.1.1

N´ ahodn´ e s´ıt’ov´ e v´ ypadky Probl´ em

Firma pouˇz´ıvá jako monitorovac´ı systém ”nagios”, kter´ y jednoho dne zaˇcal zobrazovat rozporuplná hláˇsen´ı ohlednˇe stavu produkce. Obˇcas nahlásil nedostupnost jednoho konkrétn´ıho serveru. Pˇri manuáln´ı kontrole docházelo k r˚ uznorod´ ym v´ ysledk˚ um. V jednu chv´ıli se dan´ y server jevil jako dostupn´ y, pˇri dalˇs´ı kontrole o pár minut pozdˇeji jako nedostupn´ y, obˇcas vznikaly stavy kdy server sice odpov´ıdal na pokusy o spojen´ı, ale vykazoval velk´ y packet loss. Produkce bˇeˇzela v poˇra´dku dál bez viditeln´ ych problém˚ u.

17

2.1.2

Prvotn´ı pˇ r´ıˇ cina

Jelikoˇz byla produkce v dobˇe vzniku tohoto problému ˇreˇsena ad hoc, mˇeli zamˇestnanci staraj´ıc´ı se o instalaci nov´ ych zákazn´ık˚ u nauˇcen mechanick´ y postup pro instalaci a zprovoznˇen´ı Secure Sockets Layer (SSL) certifikát˚ u. Kaˇzd´ y SSL certifikát potˇrebuje vlastn´ı Internet Protocol (IP) adresu1 . Tento problém je velmi pˇeknˇe vysvˇetlen v manuálov´ ych stránkách Apache[3]: D˚ uvod je velmi technick´ y, a ponˇekud pˇripom´ıná znám´ y problém slepice a ve” jce“. Protocol SSL vrstvy je pod a obaluje HTTP protokol. Kdyˇz je zahájeno ´kol vyjednat parameSSL spojen´ı (HTTPS) modul Apache/mod ssl má za u try SSL komunikace s klientem. Pro toto mod ssl mus´ı konzultovat konfiguraci virtuáln´ıho serveru (napˇr´ıklad mus´ı vyhledat ˇsifrovac´ı sadu, certifikát serveru, atp. . . ). Ale k tomu, aby mohl nalézt správn´ y virtuáln´ı server Apache mus´ı znát poloˇzku Host hlaviˇcky HTTP protokolu. K tomu aby toto vykonal mus´ı pˇreˇc´ıst hlaviˇcku HTTP poˇzadavku. Toto nelze provést pˇred t´ım, neˇz je dokonˇcena fáze takzvaného SSL handshake, ale tato informace je potˇreba k dokonˇcen´ı SSL handshake. Bingo! Na vstupu do naˇs´ı infrastruktury (xen02 2 ) je tedy nastaveno velké mnoˇzstv´ı IP adres. Tyto IP adresy se pˇrekládaj´ı na IP vnitˇrn´ı s´ıtˇe jak je vidˇet na obrázku A.43 . Z historick´ ych d˚ uvod˚ u jsou tyto IP adresy ze stejného rozsahu jako pouˇz´ıvaj´ı produkˇcn´ı servery pro komunikaci mezi sebou. Bylo tedy jen otázkou náhody, neˇz se t´ımto zp˚ usobem pˇriˇrad´ı IP adresa jiˇz bˇeˇz´ıc´ıho serveru nˇekterému z novˇe pˇr´ıchoz´ıch zákazn´ık˚ u. Problém takovéto situace je ten, ˇze pˇri správné souhˇre náhod se i pˇri opakované kontrole m˚ uˇze server jevit jako dostupn´ y. Administrátor systému má tak myln´ y pocit, ˇze v nepoˇra´dku je monitorovac´ı software (nagios). Toto je vlastnˇe velmi pˇekn´ y pˇr´ıklad soubˇehu. Soubˇeh je dle wikipedie [7] definovan´ y jako: Soubˇeh (anglicky race condition) je chyba v systému nebo procesu, ve kterém jsou v´ ysledky nepˇredv´ıdatelné a závislé na poˇrad´ı nebo naˇcasován´ı jednotliv´ ych operac´ı. Soubˇeh m˚ uˇze nastat v elektronick´ ych systémech (zvláˇstˇe u logick´ ych ˇclen˚ u) a v poˇc´ıtaˇcov´ ych programech (zejména ve v´ıce´ ulohov´ ych a v´ıceprocesorov´ ych systémech). V naˇsem pˇr´ıpadˇe doˇslo k soubˇehu na u ´rovni ARP protokolu. Uvaˇzujme pˇr´ıklad kdy v jedné pods´ıti existuj´ı dva poˇc´ıtaˇce se stejnou IP adresou. Jelikoˇz na jednom segmentu s´ıtˇe neexistuje mechanismus jenˇz by takovému stavu zabránil, m˚ uˇze se na dané pods´ıti vyskytovat hned nˇekolik variant ARP odpovˇed´ı proti jednomu ARP dotazu. Toto jednoduˇse ˇreˇceno povede k nepˇredv´ıdateln´ ym záznam˚ um v ARP tabulkách r˚ uzn´ ych zaˇr´ızen´ı. Pro 4 pˇr´ıklad: lb01:~ # arp -n Address 10.0.0.11

HWtype ether

HWaddress 00:14:3e:a4:86:4d

1

Flags Mask C

Iface eth0

Toto tvrzen´ı nen´ı zcela pˇresné. Pˇri pouˇzit´ı technologie Server Name Indication (SNI) je moˇzné m´ıt IP adresu jedinou. Z business d˚ uvod˚ u ale nebylo moˇzné v dobˇe ˇreˇsen´ı tohoto problému SNI pouˇz´ıt. 2 Viz obr´ azek A.2 3 IP adresy jsou pouze ilustraˇcn´ı. 4 Pˇr´ıklad je opˇet pouze ilustraˇcn´ı.

18

watch01:~ # arp -n Address HWtype 10.0.0.11 ether

HWaddress 00:27:4b:c4:16:49

Flags Mask C

Iface eth0

V koneˇcném d˚ usledku se tak jeden stroj m˚ uˇze jevit z jednoho m´ısta jako dostupn´ ya z m´ısta jiného jako nedostupn´ y.

2.1.3

ˇ sen´ı Reˇ

Business poˇzadavkem pro tento projekt bylo nalézt ˇreˇsen´ı rychle i s rizikem toho, ˇze bude jen doˇcasné. Rozdˇelen´ı adresn´ıho prostoru klient˚ u a server˚ u tedy nepˇripadalo v u ´vahu. Taková akce by zabrala mnoho ˇcasu. Vytvoˇren´ı statické mapy IP adres pouˇz´ıvan´ ych na produkci zase nemuselo pˇrinést ani doˇcasné v´ ysledky, nebot’ by lidskou chybou v takovémto seznamu mohly vzniknout nepˇresnosti. Jedinou rozumnou moˇznost´ı se tedy jevilo vytvoˇren´ı dynamického seznamu IP adres. Zamˇestnanci instaluj´ıc´ı nové SSL certifikáty tak mohou v jak´ ykoliv okamˇzik zkontrolovat zda nepouˇzij´ı jiˇz zabranou IP adresu. Nav´ıc se v´ ystup tohoto projektu bude hodit pro dokumentaci produkce. V´ ystup skenován´ı s´ıt’ˇe mus´ı b´ yt importován do firemn´ıch wiki stránek. Pro tento projekt jsme bohuˇzel nenalezli ˇzádn´ y hotov´ y software. Museli jsme tedy naimplementovat vlastn´ı ˇreˇsen´ı. Jako programovac´ı jazyk byl zvolen Python. Pro sb´ırán´ı dat o aktuálnˇe pˇriˇrazen´ ych IP adresách byl zvolen protokol Simple Network Management Protocol (SNMP), jenˇz je na produkci jiˇz zabˇehnut a vyuˇz´ıvá se k nˇekolika dalˇs´ım u ´ˇcel˚ um. ’ SNMP je v principu jednoduch´ y s´ıt ov´ y protokol umoˇzn ˇuj´ıc´ı sbˇer dat z router˚ u, server˚ u a jin´ ych zaˇr´ızen´ı. SNMP je dnes implementováno ve valné vˇetˇsinˇe zaˇr´ızen´ı a je k dispozic ve vˇetˇsinˇe distribuc´ı. Protokol na základˇe standardizovan´ ych identifikátor˚ u takzvan´ ych Object Identifier (OID) exportuje r˚ uzné hodnoty o stavu serveru. Napˇr´ıklad o: Vyuˇzit´ı CPU, volném m´ıstˇe na disku, teplotˇe procesoru, atp. . . Protokol SNMP je snadno rozˇsiˇriteln´ yo vlastn´ı funkce. Nemus´ı slouˇzit pouze k ˇcten´ı, ale nab´ız´ı i moˇznost ovlivˇ novat stav a bˇeh daného zaˇr´ızen´ı. Tato vlastnost je ale vyuˇz´ıvána jen zˇr´ıdka. Ve v´ ysledku byl vytvoˇren jedno´ uˇcelov´ y script procházej´ıc´ı seznam znám´ ych server˚ u5 a na kaˇzd´ y server poˇsle dva SNMP dotazy. Jeden zjiˇst’uje seznam vˇsech ethernetových rozhran´ı serveru a druh´ y k tˇemto rozhran´ım dohledává pˇr´ısluˇsné IP adresy. Pro pohodl´ı uˇzivatel˚ u je pak jeˇstˇe proveden dotaz na reverzn´ı DNS záznam6 . V´ ysledek je vrácen jako tabulka ve wiki syntaxi. Script je k nahlédnut´ı v kapitole B.1. Volán je pak z cronu a pˇres cli rozhran´ı tracu je jeho v´ ystup importován do wiki. Ukázka v´ ystupu je pak k nahlédnut´ı na obrázku 2.1.

2.2 2.2.1

D˚ uvˇ eryhodn´ y a uˇ ziteˇ cn´ y monitorovac´ı n´ astroj Probl´ em

Jak jiˇz bylo ˇreˇceno v´ yˇse, firma pouˇz´ıvá k monitorován´ı server˚ u a sluˇzeb ”nagios”. Takov´ yto monitorovac´ı nástroj je neodmyslitelnou souˇca´st´ı kaˇzdé produkce. Nen´ı v silách ˇzádného ˇclovˇeka m´ıt neustál´ y a dokonal´ y pˇrehled o zdrav´ı kaˇzdého serveru a kaˇzdé jeho sluˇzbˇe jeˇz je souˇca´st´ı produkce. Monitorovac´ı server dokáˇze zavˇcasu upozornit na pˇr´ıpadné budouc´ı, ˇci právˇe vzniklé problémy. Základn´ı pˇredpoklady kaˇzdého monitorovac´ıho systému jsou: 5 6

Tento seznam se mˇen´ı relativnˇe zˇr´ıdka. Reverzn´ı DNS z´ aznam pˇriˇrazuje IP adrese doménové jméno

19

Obrázek 2.1: IP SNMP scanner

1. Monitorovac´ı server mus´ı leˇzet mimo monitorovan´ y systém. Pokud by totiˇz doˇslo k v´ ypadku s´ıt’ové konektivity, jen tˇeˇzko by monitorovac´ı nástroj ohlásil problémy, pokud by byl na postiˇzené s´ıti. 2. Monitorovac´ı server nesm´ı b´ yt ovlivˇ nován ˇzádn´ ymi vnˇejˇs´ımi vlivy jako je napˇr´ıklad zat´ıˇzen´ı s´ıtˇe na které bˇeˇz´ı, ˇci vyt´ıˇzen´ı serveru ze kterého je spuˇstˇen. 3. Mus´ı sledovat vˇsechny známé kritické sluˇzby a servery, jenˇz mohou ovlivnit dostupnost produkce. Problém existuj´ıc´ıho monitorovac´ıho serveru byl ve vˇsech tˇrech v´ yˇse zm´ınˇen´ ych bodech. Fyzicky byl um´ıstˇen v kanceláˇri firmy, jej´ıˇz servery souˇcasnˇe monitoroval. Jelikoˇz v kanceláˇr´ıch firmy prob´ıhá ˇcil´ y s´ıt’ov´ y provoz, bylo vyvoláváno relativnˇe velké mnoˇzstv´ı faleˇsnˇe pozitivn´ıch poplach˚ u d´ıky s´ıt’ov´ ym problém˚ um na stranˇe nagiosu. A v neposledn´ı ˇradˇe d´ıky delˇs´ı dobˇe od posledn´ı u ´pravy konfigurac´ı nagiosu, nesledoval tento vˇsechny potˇrebné sluˇzby.

2.2.2

ˇ sen´ı Reˇ

Za velmi zaj´ımavé zjiˇstˇen´ı bˇehem realizace tohoto projektu osobnˇe povaˇzuji souvislost mezi vyt´ıˇzen´ım serveru na kterém bˇeˇz´ı nagios a poˇctem faleˇsnˇe pozitivn´ıch hláˇsen´ı. P˚ uvodn´ı idea byla pˇrenést spoleˇcnˇe s nagiosem na nov´ y server i cacti7 . Toto se ale v praxi ukázalo jako nepouˇzitelné ˇreˇsen´ı. Cacti svoj´ı pˇr´ıtomnost´ı vytˇeˇzovalo monitorovac´ı server velmi v´ yznamn´ ym zp˚ usobem. Po jeho odsunut´ı na jin´ y server byl zredukován poˇcet faleˇsnˇe pozitivn´ıch hláˇsen´ı na cca 1/3. Po prostudován´ı moˇzn´ ych ˇreˇsen´ı bylo rozhodnuto ˇze se nagios pˇrestˇehuje na cloud 8 spoleˇcnosti Amazon . D˚ uvody pro tuto volbu byly následuj´ıc´ı: • D´ıky elasticitˇe cloudu je zv´ yˇsen´ı v´ ypoˇcetn´ı s´ıly serveru velmi jednoduché. D˚ uleˇzitá vlastnost d´ıky v´ yˇse zm´ınˇen´ ym faleˇsnˇe pozitivn´ım hláˇsen´ım. • Známá vysoká spolehlivost této sluˇzby pˇrináˇs´ı jistotu dostupnosti a bˇehu nagiosu. • D´ıky oddˇelen´ ym zónám by v´ ypadek jedné nemˇel ovlivnit jiné. Navzdory um´ıstˇen´ı ve stejné geografické lokaci. 7

Software pro sbˇer statistik o hodnotách serveru a jejich zobrazen´ı do grafu. Pˇresnˇeji Amazon Elastic Compute Cloud (Amazon EC2). Tato sluˇzba bude rozebrána v dalˇs´ıch kapitol´ ach této pr´ ace. 8

20

• EC2 byla plánována k bliˇzˇs´ımu prozkoumán´ı. Takˇze byl v´ yhodn´ y fakt ˇze v´ ystup této elaborace poslouˇz´ı jako základ pro dalˇs´ı práci.

21

Slovn´ık ”MySQL” MySQL je databázov´ y systém, vytvoˇren´ y ˇsvédskou firmou MySQL AB, nyn´ı vlastnˇen´ y spoleˇcnost´ı Sun Microsystems, dceˇrinou spoleˇcnost´ı Oracle Corporation. Jeho hlavn´ımi autory jsou Michael Monty“ Widenius a David Axmark. Je povaˇzován ” za u ´spˇeˇsného pr˚ ukopn´ıka dvoj´ıho licencován´ı – je k dispozici jak pod bezplatnou licenc´ı GPL, tak pod komerˇcn´ı placenou licenc´ı.. 14 ´ ”brute force” Utok hrubou silou (anglicky brute force attack) je vˇetˇsinou pokus o rozluˇstˇen´ı ˇsifry bez znalosti jej´ıho kl´ıˇce k deˇsifrován´ı. V praxi se jedná o systematické testován´ı vˇsech moˇzn´ ych kombinac´ı nebo omezené podmnoˇziny vˇsech kombinac´ı.. 15 ”nagios” Nagios je populárn´ı open source systém pro automatizované sledován´ı stavu poˇc´ıtaˇcov´ ych s´ıt´ı a jimi poskytovan´ ych sluˇzeb. Je vyv´ıjen primárnˇe pro Linux, ale je moˇzné ho provozovat i na jin´ ych unixov´ ych systémech. Je vydáván pod GPL licenc´ı. Je vyv´ıjen a udrˇzován Ethanem Galstadtem a mnoha dalˇs´ımi v´ yvojáˇri plugin˚ u.. 17 ˇ alován´ı do ˇs´ıˇrky je obvykle ˇreˇseno pˇridán´ım server˚ ”scale out” Sk´ u a rozdistribuován´ım zátˇeˇze mezi tyto jednotlivé servery. 10 ˇ alován´ı do v´ ˇ alován´ı pˇri kterém jsou do serveru pˇridány v´ ”scale up” Sk´ yˇsky. Sk´ ypoˇcetn´ı zdroje (CPU, RAM) pro zv´ yˇsen´ı v´ ykonu. 10 ARP Address Resolution Protocol (ARP) se v poˇc´ıtaˇcov´ ych s´ıt´ıch s IP protokolem pouˇz´ıvá k z´ıskán´ı ethernetové MAC adresy sousedn´ıho stroje z jeho IP adresy. Pouˇz´ıvá se v situaci, kdy je tˇreba odeslat IP datagram na adresu leˇz´ıc´ı ve stejné pods´ıti jako odesilatel. Data se tedy maj´ı poslat pˇr´ımo adresátovi, u nˇehoˇz vˇsak odesilatel zná pouze IP adresu. Pro odeslán´ı prostˇrednictv´ım napˇr. Ethernetu ale potˇrebuje znát c´ılovou ethernetovou adresu.. 18 DNS Domain Name Server. 17 dom0 Dom0, nebo domain zero je prvn´ı server jenˇz je spuˇstˇen hypervizorem XENu pˇri bootu. 7, 9 domU DomU, nebo domain U je kaˇzd´ y dalˇs´ı server jenˇz je spuˇstˇen nad“ dom0. 7, 9, 10 ” failover Schopnost prostˇred´ı bezchybného bˇehu i za situace selhán´ı nˇekter´ ych server˚ u. 1, 11, 15 HN Hardware Node. 7–9 HTTP Hypertext transfer protocol je dnes nejrozˇs´ıˇrenˇejˇs´ı protokol pro distribuci obsahu webov´ ych stránek. 2, 10, 11, 18 22

HTTPS Hypertext transfer protocol secure je nadstavba nad klasick´ y HTTP protokol o zabezpeˇcen´ı v podobˇe protokolu SSL/TLS . 10, 11, 18 HW Hardware. 10, 15 IP Internet Protocol. 18, 19 kontejner Kontejner, anglicky container je pojem znám´ y pˇredevˇs´ım z prostˇred´ı OpenVZ . 7 KVM Kernel-based Virtual Machine. 8 Load balancer Server jeˇz zajiˇst’uje rovnomˇerné rozm´ıstˇen´ı zátˇeˇze na v´ ypoˇcetn´ıch stroj´ıch. 2 Moore˚ uv z´ akon Sloˇzitost souˇca´stek se kaˇzd´ y rok zdvojnásob´ı pˇri zachován´ı stejné ceny http://en.wikipedia.org/wiki/Moore%27s_law. 8 mount Mountován´ı“, je v IT pojem pro oznaˇcen´ı procesu pˇripraven´ı diskového odd´ılu ” pro pouˇzit´ı operaˇcn´ım systémem. 11 NFS Network File Storage - protokol pro pˇripojován´ı s´ıt’ov´ ych disk˚ u. 2, 3, 11, 14 open source Software s volnˇe dostupn´ ymi zdrojov´ ymi kódy. 8 OS Operaˇcn´ı systém. 3–5, 7–10, 17 OSS Open Source Software. 16 overhead Zdroje jeˇz mus´ı b´ yt vydány nav´ıc a nesouvis´ı pˇr´ımo s poˇzadovan´ ym c´ılem. 8 packet loss Packet loss je jev pˇri kterém jeden, nebo v´ıce paket˚ u v poˇc´ıtaˇcové s´ıti nedosáhne svého urˇceného c´ıle.. 17 RAID Redundant Array of Independent Disks. 12 Rolling updates Aktualizace se uskuteˇcn ˇuje pomoc´ı bal´ıˇckovac´ıho systému pr˚ ubˇeˇznˇe, dennˇe jsou do zdroj˚ u doplˇ novány nejnovˇejˇs´ı stabiln´ı verze softwaru. 6 SNI Server Name Indication. 18 SPOF Single Point Of Failure. 13, 14 SQL Structured Query Language je standardizovan´ y dotazovac´ı jazyk pouˇz´ıvan´ y pro práci s daty v relaˇcn´ıch databáz´ıch. 2 SSL Secure Sockets Layer. 18, 19 VPN Virtual Private Network. 2 XEN V IT se pod pojmem XEN rozum´ı virtualizaˇcn´ı technologie. 9

23

Literatura [1] Laura DiDio. Yankee Group 2007-2008 Server OS Reliability Survey. http: //www.iaps.com/exc/yankee-group-2007-2008-server-reliability.pdf, 2008. [Online; pˇr´ıstupné 12.12.2010]. [2] edpin,wolf,[email protected]. Failure trends in a large disk drive population. http://labs.google.com/papers/disk_failures.html, 2007. [Online; pˇr´ıstupné 22.3.2011]. [3] The Apache Software Foundation. http://httpd.apache.org/docs/2.0/ssl/ssl_ faq.html, 2011. [Online; pˇr´ıstupné 29.3.2011]. [4] Kirill Kolyshkin. Virtualization in Linux. http://download.openvz.org/doc/ openvz-intro.pdf, 2006. [Online; pˇr´ıstupné 9.2.2011]. [5] linux.com. Benchmarking hardware raid vs. linux kernel software raid. http://www.linux.com/news/hardware/servers/ 8222-benchmarking-hardware-raid-vs-linux-kernel-software-raid, 2008. [Online; pˇr´ıstupné 20.3.2011]. [6] Microsoft. Compare Windows to Red Hat. http://www.microsoft.com/ windowsserver/compare/windows-server-vs-red-hat-linux.mspx, 2003. [Online; pˇr´ıstupné 13.12.2010]. [7] Soubˇeh. http://cs.wikipedia.org/wiki/Soub%C4%9Bh, 2011. [Online; pˇr´ıstupné 05.4.2011]. [8] VMware, Inc. A Performance Comparison of Hypervisors . http://www.cc.iitd. ernet.in/misc/cloud/hypervisor_performance.pdf, 2007. [Online; pˇr´ıstupné 10.1.2011]. [9] Wikipedia. Failover. http://en.wikipedia.org/wiki/Failover, 2011. [Online; pˇr´ıstupné 22.2.2011]. [10] Wikipedia. Kernel-based Virtual Machine. http://en.wikipedia.org/wiki/ Kernel-based_Virtual_Machine, 2011. [Online; pˇr´ıstupné 2.2.2011]. [11] Wikipedia. Network file system. http://cs.wikipedia.org/wiki/Network_File_ System, 2011. [Online; pˇr´ıstupné 27.3.2011]. [12] Wikipedia. RAID. http://cs.wikipedia.org/wiki/RAID#RAID_1_.28zrcadlen. C3.AD.29, 2011. [Online; pˇr´ıstupné 20.3.2011]. [13] Cybersource XXX. n. http://www.cyber.com.au/about/linux_vs_windows_ tco_comparison.pdf&ei=SyYVTcPQPMWa8QOK_vTfDw&usg=AFQjCNGNPQMsfTKO_ AU5gBC6gIOsjGxxIA&sig2=f8P3b0FOgaM-DnCdQq_eRQ, 2002. [Online; pˇr´ıstupné 13.12.2010]. 24

Pˇ r´ıloha A Obr´ azky

25

Obrázek A.1: P˚ uvodn´ı produkce s vyznaˇcen´ ymi verzemi Operaˇcn´ıch Systém˚ u

26

Obrázek A.2: Schéma zpracován´ı HTTP/HTTPS poˇzadavku

27

Obrázek A.3: Pˇripojen´ı sd´ılen´ ych NFS odd´ıl˚ u

28

Obrázek A.4: Pˇreklad vnˇejˇs´ı IP adresy na vnitˇrn´ı

Obrázek A.5: Vyt´ıˇzen´ı serveru (nagios + cacti)

29

Obrázek A.6: Vyt´ıˇzen´ı serveru (pouze nagios)

30

Pˇ r´ıloha B Zdrojov´ e k´ ody B.1 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38

IP SNMP scanner

#! / u s r / b i n / python import os , sys , g e t p a s s , s u b p r o c e s s , re , s o c k e t , d a t e t i m e SERVERS = [ ’ xen02 ’ , ’ db01 ’ , ’ db02 ’ , ] # Vycet s e r v e r u j e j e n u k a z k o v y TMP FILE = ’ /tmp/ t r a c i p . t x t ’ TRAC ROOT = ’ / var / l i b / t r a c / t e s t ’ COMMUNITY = ’XXX ’ data=d i c t ( ) c l a s s SnmpScanner : data = d i c t ( ) INTERFACE NAME = ’ i n t e r f a c e n a m e ’ IP = ’ i p s ’ DNS = ’ dns ’ def f i n d i n t e r f a c e s ( s e l f ) : f o r s e r v e r in SERVERS: s e l f . data [ s e r v e r ] = d i c t ( ) s h e l l = s u b p r o c e s s . Popen ( ”snmpwalk −c ”+COMMUNITY+” −v 2 c ”+ s e r v e r+” ifName ” , s h e l l=True , s t d o u t=s u b p r o c e s s . PIPE ) m i b t a b l e = s h e l l . communicate ( ) [ 0 ] . s p l i t ( ”\n” ) f o r m i b r e c o r d in m i b t a b l e : m a t c h o b j e c t = r e . s e a r c h ( ’ ifName . ( \ d ∗ ) = STRING : ( \ S ∗ ) $ ’ , m i b r e c o r d , r e . MULTILINE) i f m a t c h o b j e c t != None : i n t e r f a c e i d = m a t c h o b j e c t . group ( 1 ) i n t e r f a c e n a m e = m a t c h o b j e c t . group ( 2 ) s e l f . data [ s e r v e r ] [ i n t e r f a c e i d ] = d i c t ( ) s e l f . data [ s e r v e r ] [ i n t e r f a c e i d ] [ s e l f .INTERFACE NAME] = interface name def f i n d d n s ( s e l f ) : f o r s e r v e r in SERVERS: f o r i n t e r f a c e i d , i n t e r f a c e in s e l f . data [ s e r v e r ] . i t e m s ( ) : try : f o r i p in i n t e r f a c e [ s e l f . IP ] : try : hostname = s o c k e t . g e t h o s t b y a d d r ( i p ) s e l f . data [ s e r v e r ] [ i n t e r f a c e i d ] [ s e l f . IP ] [ i p ] = hostname [ 0 ] except :

31

39 40 41 42 43 44 45 46 47 48 49

50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84

pass #s e l f . d a t a [ s e r v e r ] [ i n t e r f a c e i d ] [ s e l f .DNS] = ”−−−” except : i n t e r f a c e [ s e l f . IP ] = d i c t ( )

def f i n d i p s ( s e l f ) : f o r s e r v e r in SERVERS: i f s e r v e r not in s e l f . data : # TODO: u g l y , make b e t t e r s e l f . data [ s e r v e r ] = d i c t ( ) s h e l l = s u b p r o c e s s . Popen ( ”snmpwalk −c ” + COMMUNITY + ” −v 2 c ” + s e r v e r + ” i p A d d r e s s I f I n d e x . i p v 4 ” , s h e l l=True , s t d o u t= s u b p r o c e s s . PIPE ) m i b t a b l e = s h e l l . communicate ( ) [ 0 ] . s p l i t ( ”\n” ) f o r m i b r e c o r d in m i b t a b l e : #r e . f i n d i t e r ( ’ \ S∗ $ ’ , tmp2 , r e . MULTILINE) : m a t c h o b j e c t = r e . s e a r c h ( ’ i p v 4 . ” ( [ ˆ ” ] ∗ ) ” = INTEGER: ( \ d ∗ ) $ ’ , m i b r e c o r d , r e . MULTILINE) i f m a t c h o b j e c t != None : i = m a t c h o b j e c t . group ( 2 ) i f s t r ( i ) not in s e l f . data [ s e r v e r ] : # TODO: u g l y , make better s e l f . data [ s e r v e r ] [ s t r ( i ) ] = d i c t ( ) i f s e l f . IP not in s e l f . data [ s e r v e r ] [ s t r ( i ) ] : # TODO: r e a l l y u g l y , make b e t t e r s e l f . data [ s e r v e r ] [ s t r ( i ) ] [ s e l f . IP ] = d i c t ( ) s e l f . data [ s e r v e r ] [ s t r ( i ) ] [ s e l f . IP ] [ m a t c h o b j e c t . group ( 1 ) ] = ”” def p r i n t i n f o ( s e l f ) : print ( ”= E x p e r i m e n t a l IP l i s t =” ) print ( ” This page i s g e n e r a t e d ’ ’ ’ a u t o m a t i c a l l y ’ ’ ’ . Do not modify i t . Your c h a n g e s w i l l be o v e r w r i t t e n . ” ) print ( ”The ’ ’ l o c a l h o s t ’ ’ r e c o r d r e f e r s t o ’ ’ xen02 ’ ’ . ” ) print ( ” L i s t i s g e n e r a t e d by a t i v e IP s c a n n e r . So i t maps ’ ’ a c t u a l ’ ’ s t a t e o f s e r v e r s . Not t h e one i n c o n f i g u r a t i o n s . ” ) print ( ” This page r e f e r s t o s t a t e a t ” + s t r ( d a t e t i m e . d a t e t i m e . now ( ) )) wiki page = ”” f o r s e r v e r n a m e , s e r v e r in s e l f . data . i t e m s ( ) : w i k i p a g e += ”== ”+s e r v e r n a m e+” ==\n” f o r i n t e r f a c e i d , i n t e r f a c e in s e r v e r . i t e m s ( ) : w i k i p a g e += ” | | ’ ’ ’ ”+ ( i n t e r f a c e [ s e l f .INTERFACE NAME] i f s e l f .INTERFACE NAME in i n t e r f a c e e l s e ”−−−” ) + ” ’ ’ ’ | | ” f o r ip , dns in i n t e r f a c e [ s e l f . IP ] . i t e m s ( ) : #i f s e l f . d a t a [ s e r v e r ] [ s e l f .INTERFACE NAME] != ”” and i n t e r f a c e != ” l o ” : w i k i p a g e += ” ’ ’ ’ ” + i p + ” ’ ’ ’ ” i f dns != ” ” : w i k i p a g e += ” = ” + dns w i k i p a g e += ” , ” #w i k i p a g e += s t r ( s e l f . d a t a [ s e r v e r ] [ i n t e r f a c e ] [ ’ h o s t ’ ] [ 0 ] ) +” | | \ n” w i k i p a g e += ” | | \ n” print w i k i p a g e

32

85 86 87 88 89

o b j = SnmpScanner ( ) obj . f i n d i n t e r f a c e s () obj . f i n d i p s () obj . find dns () obj . p r i n t i n f o ()

Listing B.1: IP SNMP scanner

33

Západočeská univerzita v Plzni Fakulta aplikovaných věd Katedra informatiky a výpočetní techniky. Automatizace procesů firmy v oblasti

Recommend Documents