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

2 // / Hostname o f t h e machine where e r r o r o c c u r e d 3 // / <s v c d e s c r i p t i o n > B r i e f d e s c r i p t i o n o f t h e problem 4 // / 0=OK, 1=WARNING, 2=CRITICAL 5 // /

D e s c r i p t i o n o f t h e problem 6 7 $customer id = Config : : get ( ’ customer ’ , ’ i d ’ ) ; 8 $return code = 2; 9 $msg = s p r i n t f ( ’ l b 0 1 \tDB E r r o r \ t%d\ t%d − db e r r o r o c c u r e d . ’ , $ r e t u r n c o d e , $ c u s t o m e r i d ) ; 10 exec ( ’ echo −e ” ’ . $msg . ’ ” | / u s r / s b i n / s e n d n s c a −H watch01 ’ ) ;

Listing 2.1: Uk´azka vol´an´ı NSCA 1 2 3 4 5 6 7 8 9 10 11 12 13

define service { use host name check command service description passive checks enabled normal check interval } d e f i n e command { command name command line }

g e n e r i c −s e r v i c e lb01 dummy−ok DB E r r o r 1 15

dummy−ok echo ” A u t o m a t i c a l l y r e s t a r t e d ”

Listing 2.2: Uk´azka konfigurace nagiosu pro hl´ıd´an´ı chyb datab´aze Za povˇsimnut´ı stoj´ı nadefinov´an´ı pˇr´ıkazu dummy-ok jenˇz je pouˇzit jako aktivn´ı kontrola sluˇzby DB Error, jenˇz je spouˇstˇena kaˇzd´ ych 15 minut. Tento pˇr´ıkaz pouze vrac´ı ˇretˇezec Automatically restarted“ a jako n´avratovou hodnotu vrac´ı nulu. Pouˇzit´ım tohoto ” pˇr´ıkazu jako aktivn´ı kontroly v sluˇzbˇe DB Error dojde kaˇzd´ ych 15 minut k vynulov´an´ı pˇr´ıpadn´eho chybov´eho hl´aˇsen´ı. Toto je velmi v´ yhodn´e, jelikoˇz se ˇz´adn´ y z administr´ator˚ u o toto nebude muset ruˇcnˇe starat. Souˇcasnˇe bylo odhadnuto, ˇze onˇech 15 minut je ide´aln´ı interval vynulov´an´ı stavu. Pokud by byl interval menˇs´ı, pak by mohl vzniknout efekt blik´an´ı“, kdy by aktivn´ı kontrola vypnula poplach a vz´apˇet´ı by pasivn´ı kontrola poplach ” 22

zapnula. Souˇcasnˇe je potˇreba tento interval m´ıt co nejkratˇs´ı, aby obsluha nagiosu vidˇela kritick´ y stav produkce po co nejkratˇs´ı dobu.

2.3 2.3.1

Zvyˇ suj´ıc´ı se n´ aroky na v´ ykon v´ ypoˇ cetn´ıch server˚ u Probl´ em

Zvyˇsuj´ıc´ı se poˇcet z´akazn´ık˚ u, nar˚ ustaj´ıc´ı komplikovanost aplikace, nar˚ ustaj´ıc´ı data z´akazn´ık˚ u, zvyˇsuj´ıc´ı se poˇcet uˇzivatel˚ u aplikace. Toto byly hlavn´ı d˚ uvody postupn´eho sniˇzov´an´ı v´ ykonu aplikace a zvyˇsov´an´ı odezvy syst´emu jako celku. To bylo samozˇrejmˇe pro uˇzivatele, z´akazn´ıky a v koneˇcn´em d˚ usledku i pro firmu jako takovou nepˇr´ıjemn´e. Vznikl tedy projekt maj´ıc´ı za c´ıl nav´ yˇsen´ı v´ ykonu syst´emu. V n´asleduj´ıc´ıch kapitol´ach se pokus´ım nast´ınit zjiˇstˇen´e v´ ysledky, motivace jednotliv´ ych krok˚ u a dopady na n´asleduj´ıc´ı proveden´e kroky. Zjiˇstˇen´e z´avˇery jsou sice na m´ıru ˇsit´e naˇs´ı situaci, ale obecn´e pouˇcen´ı si lze vz´ıt pro jakoukoli stˇrednˇe velkou10 webovou aplikaci.

2.3.2

Projekt Amazon VPC

V posledn´ıch letech se hojnˇe mluv´ı o v´ ypoˇctech v takzvan´em cloudu“. Princip je vcelku ” jednoduch´ y. Z´akazn´ık si pronajme urˇcit´ y garantovan´ y v´ ypoˇcetn´ı v´ ykon11 a neˇreˇs´ı serverovou infrastrukturu, kabel´aˇz a ba dokonce ani virtualizaci serveru pro pˇrerozdˇelen´ı v´ ykonu. D´ıky elasticitˇe cloudov´ ych technologi´ı je totiˇz velmi snadn´e zv´ yˇsit ˇci sn´ıˇzit v´ ypoˇcetn´ı s´ılu serveru. Pˇrid´an´ı dalˇs´ıch procesor˚ u ˇci pamˇeti je tak ot´azka nˇekolika m´alo minut. Toto byla pro firmu samozˇrejmˇe velmi zaj´ımav´a technologie. Nikdo nedok´azal dostateˇcnˇe vˇerohodnˇe odhadnout r˚ ust aplikace a infrastruktury v pˇr´ıˇst´ıch nˇekolika letech. Tud´ıˇz by n´am technologie umoˇzn ˇuj´ıc´ı jednoduˇse nafouknout“ kter´ ykoliv ze server˚ u velmi pomohla. ” Pro tento projekt byla zvolena technologie Amazon Web Services (AWS), respektive jej´ı ˇca´sti Elastic Compute Cloud (EC2) a Virtual Private Cloud (VPC). AWS je souhrnn´ y n´azev pro vˇsechny sluˇzby jenˇz spoleˇcnost Amazon nab´ız´ı pro ˇreˇsen´ı webov´ ych projekt˚ u. Pod pojmem EC2 se pak skr´ yv´a vlastn´ı pron´ajem v´ ypoˇcetn´ıho prostoru na serverech Amazonu. Star´a se o manipulaci s v´ ykonem stroj˚ u, vytv´aˇren´ı nov´ ych, spr´avu existuj´ıc´ıch. Technologie VPC pak umoˇzn´ı rezervov´an´ı urˇcit´eho v´ ypoˇcetn´ıho v´ ykonu a jeho napojen´ı na naˇsi vlastn´ı serverovou infrastrukturu. Tyto servery jsou s infrastrukturou z´akazn´ıka (n´aˇs´ı) spojeny pˇres zabezpeˇcenou linku VPN. Tuto situaci zachycuje obr´azek 2.3 Amazon AWS nab´ız´ı krom webov´eho rozhran´ı tak´e velmi pˇr´ıjemnou sadu n´astroj˚ u pro spr´avu virtu´aln´ıch server˚ u z pˇr´ıkazov´e ˇr´adky. D´ıky tomu je moˇzn´e vytvoˇrit jednoduch´e skripty jenˇz budou napˇr´ıklad zvyˇsovat v´ ykon v´ ypoˇcetn´ıch server˚ u v pˇr´ıpadˇe potˇreby a naopak ho sniˇzovat pro uˇsetˇren´ı n´aklad˚ u. D´ıky sv´e popularitˇe jsou tyto n´astroje snadno instalovateln´e na vˇsechny pˇredn´ı linuxov´e distribuce. Amazon s´am nab´ız´ı uˇzivatelskou pˇr´ıruˇcku[3], pˇr´ıruˇcku pro jejich Application Programming Interface (API)[1] i pˇr´ıruˇcku pro pr´aci s cli rozhran´ım[2]. Popisovat do detail˚ u jednotliv´e technologie Amazon AWS je mimo rozsah tohoto dokumentu. Osobnˇe si mysl´ım ˇze maj´ı ˇsirok´e spektrum uplatnˇen´ı a nab´ız´ı jist´ y technologick´ y n´askok pˇred standardn´ım“ pˇr´ıstupem pron´ajmu dedikovan´ ych server˚ u. ” Zad´an´ı projektu bylo velmi jednoduch´e: Pˇripojit technologii Amazon VPC na st´avaj´ıc´ı infrastrukturu a zajistit spuˇstˇen´ı dostateˇcn´eho poˇctu v´ ypoˇcetn´ıch virtu´aln´ıch stroj˚ u, v pˇr´ıpadˇe ˇze nastane potˇreba. Potˇrebou bylo v nejˇcastˇejˇs´ım pˇr´ıpadˇe myˇsleno v´ ykonnostn´ı pokryt´ı 10

Stovky instanc´ı aplikace, kaˇzd´ a se stovkami aˇz des´ıtkami tis´ıc uˇzivatel˚ u. Aktivn´ıch je v jednu chv´ıli aˇz 1/1000 z celkov´eho poˇctu uˇzivatel˚ u. 11 Obvykle ud´ avan´ y jako v´ ykon Central Processing Unit (CPU) a mnoˇzstv´ı RAM.

23

Obr´azek 2.3: Technologie VPC

ˇspiˇcek. Jelikoˇz je aplikace pouˇz´ıv´ana v nˇekolika m´alo ˇcasov´ ych p´asmech, rozloˇzen´ı n´avˇstˇevnosti produktu pˇres den m´a charakteristiku Gaussovy kˇrivky[22], jak je vidˇet na obr´azku A.10. Je tedy potˇreba n´asobnˇe vyˇsˇs´ıho v´ ykonu v poledn´ıch hodin´ach oproti v´ ykonu potˇrebn´emu v noci. Dalˇs´ım momentem jsou skokov´e n´ar˚ usty n´avˇstˇevnosti, jenˇz obvykle nast´avaj´ı po nasazen´ı nov´e instance produktu, rozesl´an´ı hromadn´eho e-mailu uˇzivatel˚ um, ˇci na z´akladˇe nˇejak´e ud´alosti uvnitˇr komunity uˇzivatel˚ u produktu. N´ar˚ ust n´avˇstˇevnosti mezi dvˇema po sobˇe jdouc´ımi dny tak m˚ uˇze dos´ahnout aˇz dvojn´asobku. Tuto situaci ukazuje den 20 a 21 na obr´azku A.11. Amazon VPC bylo tedy naˇse teoretick´e ˇreˇsen´ı v´ yˇse popsan´ ych probl´em˚ u. A to d´ıky schopnosti t´eto technologie poskytnout bˇehem nˇekolika minut server s des´ıtkami gigabyt˚ u operaˇcn´ı pamˇeti a des´ıtkami procesor˚ u. Zjednoduˇsen´e sch´ema napojen´ı t´eto technologie na naˇs´ı infrastrukturu je vidˇet na obr´azku A.5. V´ yhoda vyuˇzit´ı t´eto technologie nam´ısto napˇr´ıklad pron´ajmu dalˇs´ıch dedikovan´ ych server˚ u je ta, ˇze m˚ uˇzeme dynamicky reagovat na potˇreby syst´emu a plat´ıme pouze za ˇcas, kdy jsou servery vyuˇz´ıv´any. Implementace Pˇri implementaci tohoto projektu jsme se setkali s efektem pro n´as do t´e doby nev´ıdan´ ym: Naprost´a degradace v´ ykonu syst´emu jako celku pˇri zv´ yˇsen´ı Round Trip Time (RTT). Dle wikipedie [27] je RTT definov´ano jako: V telekomunikaˇcn´ıch syst´emech je jako round-trip delay time“ nebo round” ” trip time“ oznaˇcov´an ˇcasov´ y interval potˇrebn´ y pro odesl´an´ı a pˇr´ıjem potvrzen´ı sign´alu. V kontextu poˇc´ıtaˇcov´ ych s´ıt´ı je t´ımto sign´alem obvykle oznaˇcov´an datov´ y paket a RTT je br´ano jako takzvan´ y ˇcas pingu“. Uˇzivatel poˇc´ıtaˇcov´e ” s´ıtˇe m˚ uˇze zjistit RTT pouˇzit´ım pˇr´ıkazu ping. RTT mezi servery st´avaj´ıc´ı infrastruktury se pohybuje v rozsahu 0.1ms aˇz 0.15ms. Po pˇripojen´ı testovac´ıho serveru VPC jsme zjistili ˇze ping ze server˚ u Amazonu na servery st´avaj´ıc´ı infrastruktury je pˇribliˇznˇe 30ms. Coˇz je pˇribliˇznˇe 300× n´asobek p˚ uvodn´ı hodnoty. Vysok´ y ˇcas RTT obvykle nevad´ı pˇri pˇrenosu velk´eho objemu dat, kter´ y je uskuteˇcnˇen 24

v jedn´e d´avce. Tehdy rozhoduje hlavnˇe kapacita pˇrenosov´e cesty. Bohuˇzel n´aˇs pˇr´ıpad byl ale zcela odliˇsn´ y. V naˇsem syst´emu prob´ıh´a pro zobrazen´ı kaˇzd´e webov´e str´anky mnoˇzstv´ı (ˇr´adovˇe stovky aˇz tis´ıce) ”MySQL” dotaz˚ u. D´ale zde jsou ˇra´dovˇe stovky dotaz˚ u na NFS server. V potaz je tˇreba br´at tak´e statick´e zdroje, jenˇz sebou kaˇzd´a dynamick´a str´anka pˇrin´aˇs´ı12 a jenˇz vytv´aˇr´ı dalˇs´ı HTTP dotazy. Z´ avˇ er Z´avˇer tohoto projektu byl tedy takov´ y, ˇze navzdory nˇekolikan´asobn´emu nav´ yˇsen´ı s´ıly v´ ypoˇcetn´ıch server˚ u se celkov´a doba odezvy syst´emu zv´ yˇsila. Mˇeˇren´ım bylo zjiˇstˇeno, ˇze doba odezvy se zv´ yˇsila na pˇribliˇznˇe deseti n´asobek. Tento v´ ysledek je vlastnˇe velice jednoduˇse matematicky dokazateln´ y. Pokud budeme uvaˇzovat poˇcet ”MySQL” dotaz˚ u jako a = 500, poˇcet NFS dotaz˚ u jako b = 100, poˇcet statick´ ych zdroj˚ u jako c = 10, dobu RTT mezi Amazonem a st´avaj´ıc´ı infrastrukturou jako R = 30ms, pak m˚ uˇzeme v´ yslednou minim´aln´ı dobu t potˇrebnou k naˇcten´ı jedn´e kompletn´ı webov´e str´anky odhadnou jako: t = (a + b + c) ∗ R t = (500 + 100 + 10) ∗ 30 t = 18300ms t = 18, 3s V´ ysledn´ y ˇcas bude samozˇrejmˇe jeˇstˇe vyˇsˇs´ı, jelikoˇz dan´ y vzorec nepoˇc´ıt´a s dobou pr´ace na jednotliv´ ych serverech. Tento projekt byl tedy ne´ uspˇeˇsn´y a od pouˇz´ıv´an´ı takto navrˇzen´eho syst´emu bylo nakonec upuˇstˇeno. Projekt ale pˇrinesl jeden d˚ uleˇzit´ y v´ ystup a to sice pozn´an´ı, ˇze nem´ame nalezena u ´zk´a hrdla syst´emu a nem´ame prozkoum´ano chov´an´ı syst´emu pˇri zmˇenˇe parametr˚ u (ping, odezva disk˚ u, odezva NFS serveru, propustnost s´ıtˇe, atp. . . ).

2.4

Projekt z´ ona 2“ ”

V´ ystupy a zjiˇstˇen´ı z ne´ uspˇeˇsn´eho projektu minul´e kapitoly poslouˇzily jako z´aklad projektu dalˇs´ıho. Jak uˇz bylo ˇreˇceno RTT hraje v naˇsem prostˇred´ı velmi v´ yznamnou roli. Kaˇzd´ y server m´a dvˇe s´ıt’ov´e rozhran´ı. Prvn´ı o rychlosti 100 Mbit 13 je pˇripojeno na routery server-housingov´e spoleˇcnosti a slouˇz´ı pro pˇripojen´ı stroje do internetu. Druh´e o rychlosti 1 Gbit 14 slouˇz´ı pro komunikaci server˚ u mezi sebou. Bohuˇzel d´ıky poˇctu server˚ u v naˇs´ı infrastruktuˇre jsme dos´ahli technologick´eho maxima pˇripojen´ ych stroj˚ u v jednom Gigabitov´em switchi pro rozhran´ı eth1, tedy pro komunikaci po vnitˇrn´ı s´ıti. Pˇrid´av´an´ı dalˇs´ıch v´ ypoˇcetn´ıch, ˇci datab´azov´ ych server˚ u tud´ıˇz nebylo jednoduˇse moˇzn´e. Respektive: Pˇrid´an´ı dalˇs´ıch server˚ u samozˇrejmˇe moˇzn´e je, ale byly by spojeny pouze“ 100 Mbit s´ıt´ı na u ´rovni ” rozhran´ı eth0. Toto samozˇrejmˇe nen´ı ˇz´adouc´ı situace z d˚ uvodu zv´ yˇsen´ı doby odezvy mezi jednotliv´ ymi servery. Zvyˇsov´an´ı poˇctu v´ ypoˇcetn´ıch a datab´azov´ ych server˚ u je ale v naˇs´ı situaci nevyhnuteln´e. A tak bylo potˇreba vymyslet zp˚ usob, jak dovolit rozdˇelen´ı produkce do nˇekolika v´ıcem´enˇe nez´avisl´ ych z´on. V r´amci z´ony by komunikace mezi servery prob´ıhala rychlost´ı 1 Gbit a jednotliv´e z´ony mezi sebou by pak komunikovaly rychlost´ı 100 Mbit. Samozˇrejmˇe za pˇredpokladu co nejmenˇs´ıho v´ ykonnostn´ıho dopadu pˇri vz´ajemn´e nevyhnuteln´e komunikaci pˇres rozhran´ı eth0. 12

Obr´ azky, kask´ adov´e styly, soubory JavaScriptu, a podobn´e. . . Pro jednoduˇsˇs´ı orientaci jej budu oznaˇcovat jako eth0 14 Pro jednoduˇsˇs´ı orientaci jej budu oznaˇcovat jako eth1 13

25

2.4.1

Probl´ em vzd´ alenosti mezi datab´ azov´ ymi a webov´ ymi servery

Jak jiˇz bylo naznaˇceno v minul´e kapitole, v´ ypoˇcetn´ı servery prov´adˇej´ı relativnˇe velk´e mnoˇzstv´ı dotaz˚ u do datab´az´ı. Je tedy velmi d˚ uleˇzit´e zajistit, aby vzd´alenost (ping) mezi webov´ ym serverem a datab´azov´ ym serverem byla co nejmenˇs´ı. Z principu fungov´an´ı naˇseho load-balanceru toto nen´ı ˇza´dn´ y probl´em. Load-balancer lze nastavit tak, ˇze dotazy na urˇcit´ y hostname, nebo-li dom´enu bude smˇeˇrovat vˇzdy jen na urˇcitou skupinu v´ ypoˇcetn´ıch server˚ u. T´ımto nastaven´ım a rozm´ıstˇen´ım z´akaznick´ ych datab´az´ı na odpov´ıdaj´ıc´ı datab´azov´e stroje pak lze dos´ahnout toho, ˇze dan´eho z´akazn´ıka budou vˇzdy obsluhovat pouze ty v´ ypoˇcetn´ı stroje, jenˇz maj´ı bl´ızko k datab´azov´emu stroji dan´eho z´akazn´ıka. Tuto situaci zachycuje obr´azek A.6. Ukazuje situaci pˇri pˇrid´an´ı dvou nov´ ych v´ ypoˇcetn´ıch server˚ u (web04, web05) a jednoho datab´azov´eho serveru (db04). Dotazy na dom´enu www.X.cz a www.Y.cz jsou load-balancerem posl´any na jeden z v´ ypoˇcetn´ıch server˚ u z´ony 1 (web02, ˇci web03 ). Tyto se pak dotazuj´ı datab´azov´ ych stroj˚ u db01 (pro URL www.X.cz), nebo db03 (pro URL www.Y.cz). Pro z´onu 2 je pak postup obdobn´ y. Tohoto chov´an´ı lze dos´ahnout vytvoˇren´ım konfiguraˇcn´ıch soubor˚ u apache s obsahem uveden´ ym v zdrojov´em k´odu 2.3 a 2.4. 1 2 BalancerMember h t t p : // web02:80 r o u t e=web02 3 BalancerMember h t t p : // web03:80 r o u t e=web03 4

Listing 2.3: /etc/apache2/zone01.cnf 1 2 BalancerMember h t t p : // web04:80 r o u t e=web04 3 BalancerMember h t t p : // web05:80 r o u t e=web05 4

Listing 2.4: /etc/apache2/zone02.cnf Tyto definice se pak jednoduˇse pouˇzij´ı v definic´ıch virtual host˚ u jednotliv´ ych dom´en ’ jak ukazuje zdrojov´ y k´od 2.5. Pouˇzit´ı jin´eho konfiguraˇcn´ıho souboru zajiˇst uje direktiva Include. 1 2 3 4 5 6 7 8 9 10 11 12 13 14

ServerName www.X. c z I n c l u d e zo ne 01 . c n f ServerName www.Y. c z I n c l u d e zo ne 01 . c n f ServerName www. Z . c z I n c l u d e zo ne 02 . c n f

Listing 2.5: Uk´azkov´a definice virtual host˚ u

2.4.2

Probl´ em vzd´ alen´ eho u ´ loˇ ziˇ stˇ e uˇ zivatelsk´ ych soubor˚ u

Pro naˇse prostˇred´ı plat´ı, ˇze u ´loˇziˇstˇe uˇzivatelsk´ ych soubor˚ u mus´ı b´ yt kdykoli dostupn´e pro kaˇzd´ y v´ ypoˇcetn´ı server. Se zaveden´ım z´ony 2 se ale n´ami pouˇz´ıvan´a technologie NFS uk´azala jako nedostaˇcuj´ıc´ı. V´ ypoˇcetn´ı servery z´ony 2 maj´ı daleko“ na server uˇzivatelsk´ ych ” dat file01. Vytv´aˇret nov´ y souborov´ y server (file02 ), jenˇz by uchov´aval uˇzivatelsk´e soubory pouze pro z´akazn´ıky z´ony 2 se n´am nezd´alo pˇr´ıliˇs vhodn´e. • T´ımto by vzrostla komplikovanost produkce. Bylo by nutn´e pˇredˇelat logiku dlouho bˇeˇz´ıc´ıch u ´loh bˇeˇz´ıc´ıch na serveru process01, kter´e by musely br´at v potaz z´onu, z kter´e dan´ y z´akazn´ık bˇeˇz´ı. 26

• Pˇresun z´akazn´ık˚ u mezi z´onami by nutnˇe znamenal v´ ypadek aplikace pro vˇsechny pr´avˇe pˇresouvan´e z´akazn´ıky. V dobˇe kop´ırov´an´ı dat mezi file01 a file02 mus´ı b´ yt aplikace vypnut´a. Jinak by mohlo doj´ıt k nekonzistenci uˇzivatelsk´ ych dat. • St´ale by nebyl vyˇreˇsen probl´em failoveru uˇzivatelsk´ ych dat nast´ınˇen´ y v kapitole 1.6.3. Hledali jsme tedy technologii pro vzd´alen´ y pˇr´ıstup k soubor˚ um na lok´aln´ı s´ıti, se schopnost´ı replikace dat mezi v´ıce servery. Moˇznost´ı nepˇreruˇsen´eho bˇehu i za pˇredpokladu ˇze nˇekter´ y ze server˚ u vypadne. Technologie mus´ı b´ yt schopna bˇeˇzet i na starˇs´ım linuxov´em j´adru, konkr´etnˇe 2.6.22. Nesm´ı vyˇzadovat ˇz´adn´e speciality jako patchov´an´ı j´adra, ˇci kompilaci jak´ehokoliv softwaru ze zdrojov´ ych k´od˚ u. Technologie by mˇela b´ yt z administr´atorsk´eho pohledu co nejjednoduˇsˇs´ı. V´ yˇcet distribuovan´ ych souborov´ ych syst´em˚ u je v dneˇsn´ı dobˇe relativnˇe ˇsirok´ y: DRDB, GFS, OCFS, GlusterFS, Lustre, OpenAFS. . . Po peˇcliv´em uv´aˇzen´ı jsme vybrali GlusterFS. GlusterFS je dle slov autor˚ u [8]: GlusterFS je open source, clusterov´ y souborov´ y syst´em, schopn´ y pojmout data v ˇra´dech petabajt˚ u a obsluhovat tis´ıce klient˚ u. Servery zapojen´e do GlusterFS tvoˇr´ı stavebn´ı bloky pˇres Infiniband RDMA a/nebo TCP/IP propojen´ı. Sd´ıl´ı pˇritom diskov´ y prostor, operaˇcn´ı pamˇet’ pro spr´avu dat v jedin´em glob´aln´ım jmenn´em prostoru. GlusterFS je zaloˇzeno na modul´arn´ım designu v uˇzivatelsk´em prostoru a dok´aˇze pˇrin´est v´ yjimeˇcn´ y v´ ykon pro r˚ uzn´e druhy u ´loh. GlusterFS pouˇz´ıv´a v´ yraz volume pro diskov´ y odd´ıl jenˇz vytv´aˇr´ı a poskytuje klient˚ um pro ˇcten´ı/z´apis. V´ yraz brick je pak pouˇzit pro jednotliv´e stavebn´ı komponenty volume. Technologii GlusterFS jsme pl´anovali pouˇz´ıt pro vytvoˇren´ı replikovan´eho volume s t´ım, ˇze kaˇzd´ y server bude poskytovat pr´avˇe jeden brick. V naˇsem pˇr´ıpadˇe byly hlavn´ı d˚ uvody pro v´ ybˇer pr´avˇe t´eto technologie n´asleduj´ıc´ı: • GlusterFS je zaloˇzen´ y na Filesystem in userspace (FUSE). Instalace na starˇs´ı j´adro (kernel) tedy nen´ı probl´em. • Web v´ yvoj´aˇr˚ u nab´ız´ı jak deb, tak rpm bal´ıˇcky15 . • GlusterFS pˇredpokl´ad´a pouze POSIX souborov´ y syst´em. Na jeho konkr´etn´ı implementaci uˇz nez´aleˇz´ı. Je tedy moˇzn´e pouˇz´ıvat na jednom server ext3 a na jin´em ext4 • Z pˇredchoz´ıho bodu nepˇr´ımo vypl´ yv´a snadn´a integrace do jiˇz existuj´ıc´ıho syst´emu, kdy je jako GlusterFS odd´ıl oznaˇcen pouze nˇejak´ y adres´aˇr a nikoliv cel´ y souborov´ y syst´em. • GlusterFS je velmi snadno nastaviteln´ y a ovladateln´ y16 . • Technologie nab´ız´ı vlastn´ı protokol pro pˇr´ıstup k soubor˚ um. Pˇri pouˇzit´ı tohoto protokolu automaticky z´ısk´ame failover. • GlusterFS automaticky nab´ız´ı pˇr´ıstup k soubor˚ um tak´e pˇres NFS. V´ yhodn´e pro zachov´an´ı pˇr´ıpadn´e nutn´e zpˇetn´e kompatibility. 15 16

Na produkci je pouˇzito OpenSUSE (rpm) a Debian (deb). Toto tvrzen´ı prohlaˇsuji pouze o GlusterFS verze 3.1 a vyˇsˇs´ı

27

Zdrojov´ y server file01 file02 file01 file02 file01 file01 + file02 file01 file02

Typ s´ıt’ov´eho pˇripojen´ı 100 Mbit 100 Mbit 100 Mbit 100 Mbit 1 Gbit 1 Gbit + 100 Mbit 1 Gbit 1 Gbit

Protokol pˇripojen´ı klienta NFS NFS GlusterFS, 1 brick GlusterFS, 1 brick GlusterFS, 1 brick GlusterFS, 2 bricks NFS NFS

ˇ Cas 5m 55s 8m 14s 5m 32s 4m 43s 0m 17s 2m 36s 0m 15s 0m 22s

Tabulka 2.1: V´ ykon GlusterFS (pˇrenos 1,5 GB r˚ uznˇe velik´ ych soubor˚ u) • Je moˇzn´e prov´est poˇca´teˇcn´ı synchronizaci dat replikovan´ ych brick a n´aslednˇe vytvoˇrit volume bez jak´ ychkoliv probl´em˚ u s poˇc´ateˇcn´ı synchronizac´ı velk´eho objemu dat. Naopak ze nev´ yhody zjiˇstˇen´e praktick´ym pouˇz´ıv´an´ım povaˇzuji: 1. Velmi laxn´ı pˇr´ıstup autor˚ u k dokumentaci. Odpovˇedi na vˇetˇsinu ot´azek jsem z´ıskal aˇz pˇri komunikaci pˇr´ımo s autory / uˇzivately GlusterFS. 2. GlusterFS ukl´ad´a data o replikaci pˇr´ımo do rozˇs´ıˇren´ ych atribut˚ u dan´ ych soubor˚ u. ˇ C´ımˇz se o cca 1/4 zvˇetˇs´ı velikost zabran´eho m´ısta na disku. 3. V pˇr´ıpadˇe ˇze by nˇekdo zapsal data pˇr´ımo do fyzick´eho souboru jenˇz je pouˇzit v GlusterFS volume, pak dojde k nedefinovan´emu stavu a obsah souboru je prakticky ztracen. Princip replikace popsan´ y v dokumentaci GlusterFS [7], ud´av´a potˇrebu kontrolovat aktu´alnost soubor˚ u na vˇsech brick pˇri urˇcit´em typu souborov´ ych operac´ı. Toto samozˇrejmˇe pˇrin´aˇs´ı ot´azku optim´aln´ıho rozm´ıstˇen´ı server˚ u pro jednotliv´e brick. Probl´emem je zde slab´a konektivita mezi z´onami. Pokud bychom um´ıstili oba brick do jedn´e z´ony, v´ yraznˇe sn´ıˇz´ıme odezvu v t´eto z´onˇe, ale u ´mˇernˇe tomuto zv´ yˇs´ıme odezvu v z´onˇe druh´e. Na druhou stranu um´ıstˇen´ı brick do r˚ uzn´ ych z´on m˚ uˇze znamenat m´ırn´e zv´ yˇsen´ı odezvy pro obˇe z´ony. Testy, pˇri kter´ ych jsme pˇren´aˇseli bal´ık r˚ uznˇe velik´ ych soubor˚ u, a jejichˇz v´ ysledky jsou shrnuty v tabulce 2.1 tuto domnˇenku potvrzuj´ı. Rozhodli jsme se pro ˇreˇsen´ı, kdy kaˇzd´a z´ona obsahuje jeden brick. Technologicky pro n´as bylo daleko snadnˇeji realizovateln´e a preferov´an´ı vysok´eho v´ ykonu jen pro urˇcit´e z´akazn´ıky pro n´as nebylo pˇrijateln´e. Poˇ c´ ateˇ cn´ı synchronizace Jak bylo pops´ano v´ yˇse: V pˇr´ıpadˇe, ˇze m´ate jiˇz existuj´ıc´ı uˇzivatelsk´a data, je moˇzn´e prov´est jejich poˇca´teˇcn´ı synchronizaci mezi jednotliv´ ymi brick. T´ım zamez´ıte obrovsk´emu pˇret´ıˇzen´ı server˚ u, jenˇz se budou snaˇzit replikovan´ y volume dostat do konzistentn´ıho stavu pro vˇsechny brick. Pro poˇc´ateˇcn´ı synchronizaci byl v naˇsem pˇr´ıpadˇe pouˇzit program rsync. Objem dat byl ∼ 200 GB. V pˇr´ıpadˇe pouˇzit´ı 100 Mbit s´ıtˇe by tedy pˇrenos mˇel trvat cca 4 hodiny 30 minut. Celkov´a doba poˇca´teˇcn´ı synchronizace se ale vyˇsplhala na pˇribliˇznˇe 20 hodin. Na vinˇe je velk´e mnoˇzstv´ı mal´ych soubor˚ u. Pˇri pokusu s nˇekolika m´alo velk´ ymi soubory17 byla rychlost pˇrenosu prakticky limitov´ana pouze rychlost´ı s´ıt’ov´eho rozhran´ı. N´asledn´ y pokus synchronizace rozd´ılu dat mezi servery trval pˇribliˇznˇe 4 hodiny. 17 ˇ

R´ adovˇe des´ıtky megabajt˚ u na soubor.

28

V´ yˇse popsan´e zjiˇstˇen´ı bylo samozˇrejmˇe velmi nepˇr´ıjemn´e. Teoreticky bychom mˇeli vypnout produkci pro vˇsechny z´akazn´ıky, prov´est ˇc´asteˇcnou synchronizaci a pot´e opˇet produkci zapnout. Toto by znamenalo v´ ypadek pˇres 4 hodiny pro vˇsechny z´akazn´ıky, coˇz samozˇrejmˇe nebylo pˇrijateln´e ˇreˇsen´ı. Po delˇs´ı dobˇe str´aven´e nad t´ımto probl´emem jsme dospˇeli ke kompromisu. Ono obrovsk´e mnoˇzstv´ı mal´ ych soubor˚ u bylo v naprost´e vˇetˇsinˇe souˇca´st´ı doˇcasn´eho adres´aˇre. Do tohoto adres´aˇre si naˇse aplikace napˇr´ıklad ukl´ad´a: v´ ysledky vyhled´av´an´ı jeˇz obsahuj´ı velkou mnoˇzinu dat, zmenˇsen´e n´ahledy obr´azk˚ u, pdf soubory obsahuj´ıc´ı exporty dat. . . Tento adres´aˇr tedy obsahuje pouze data, jenˇz je moˇzn´e kdykoliv vygenerovat znovu. Testy uk´azaly ˇze synchronizace bez adres´aˇre doˇcasn´ ych soubor˚ u potrv´a 20 minut. Tento v´ ysledek samozˇrejmˇe nen´ı dokonal´ y, ale pro n´aˇs pˇr´ıpad byl dostaˇcuj´ıc´ı. Proto doˇslo k rozhodnut´ı prov´est poˇca´teˇcn´ı synchronizaci n´asleduj´ıc´ım zp˚ usobem: 1. Nejprve bude provedena u ´pln´a rozd´ılov´a synchronizace. V tuto chv´ıli bude produkce st´ale bˇeˇzet. 2. Pot´e bude produkce odstavena a bude provedena rozd´ılov´a synchronizace, ale s vynech´an´ım adres´aˇre pro doˇcasn´e soubory. Skript pro synchronizaci zm´ınˇenou v bodu 2 je vidˇet v zdrojov´em k´odu 2.6. Za povˇsimnut´ı zde stoj´ı zp˚ usob napojen´ı v´ ystupu programu find na vstup programu rsync pro vynech´an´ı adres´aˇr˚ u doˇcasn´ ych soubor˚ u. Toto ˇreˇsen´ı se experiment´alnˇe uk´azalo jako nejefektivnˇejˇs´ı. Takto n´am tedy vznikl nov´ y server pro uˇzivatelsk´a data. D´ıky napojen´ı klient˚ u protokolem GlusterFS nam´ısto p˚ uvodn´ıho NFS jsme z´ıskali schopnost failoveru. 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23

#! / b i n / b a s h # This i s our s o u r c e b a s e p a t h which we want t o s y n c h r o n i z e BASE= ’/ s r v / n f s / data1 ’ # Get a l l f i r s t l e v e l sub−f o l d e r s WD=‘ l s −−c o l o r=none $ {BASE} ‘ # Record when we s t a r t e d d a t e | t e e /tmp/ s t a r t . t x t # For b e t t e r o v e r v i e w o f ” what i s h a p p e n i n g ” , sync f i r s t −l e v e l s u b f o l d e r s one a t a time f o r i i n $WD; do # Show us what s u b f o l d e r a r e we s y n c h r o n i z i n g echo $ i # Go t o t h i s s u b f o l d e r cd $ {BASE}/ $ i # Make f a s t sync # −−d e l e t e −az = make p e r f e c t copy # −i = show what was changed # −− f i l e s −from = p r o v i d e l i s t o f f i l e which s h o u l d be s y n c h r o n i z e d # −prune = when f i n d mathces t h e p a t h ( ” . / custom /∗/ temp ”) i t w i l l i m m e d i a t e l l y s t o p e x p l o r i n g i t and any s u b d i r e c t o r y RSYNC PASSWORD= ’[ password ] ’ time r s y n c −−d e l e t e −a z i −− f i l e s −from=<( f i n d . −path ” . / custom /∗/ temp” −prune −o −p r i n t ) . r s y n c : / / r s y n c @ f i l e 0 2 : : / volume01 / $ i done # Record when we f i n i s h e d d a t e | t e e /tmp/ s t o p . t x t

Listing 2.6: Skript pro ˇca´steˇcnou rychlou synchronizaci file server˚ u Z´ avˇ er Rozˇs´ıˇren´ım produkce o z´onu 2 jsme z´ıskali potˇrebn´ y v´ ypoˇcetn´ı v´ ykon. Poledn´ı ˇspiˇcky byly ˇca´steˇcnˇe pokryty, takˇze odezva produkce byla m´enˇe ovlivˇ nov´ana poˇctem pr´avˇe pˇripojen´ ych uˇzivatel˚ u. Souˇcasnˇe jsme z´ıskali failover serveru pro uˇzivatelsk´a data. Bohuˇzel jsme t´ımto projektem nedos´ahli poˇzadovan´eho sn´ıˇzen´ı odezvy produkce jako celku. Pro zv´ yˇsen´ı v´ ykonu produkce tedy mus´ıme hledat jinou cestu. V budoucnu bude 29

potˇreba vyˇreˇsit probl´em n´ızk´e pˇrenosov´e rychlosti s´ıtˇe mezi z´onami (100 Mbit), pˇres kterou nyn´ı mus´ı t´eci uˇzivatelsk´a data pomoc´ı technologie GlusterFS. V´ ysledn´e pouˇzit´ı technologie GlusterFS v naˇs´ı infrastruktuˇre je vidˇet na obr´azku A.7. Replikace mezi servery je naznaˇcena vybarvenou fialovou ˇsipkou. Napojen´ı klient˚ u je pak naznaˇceno pr´azdnou fialovou ˇsipkou. Z principu fungov´an´ı tohoto protokolu se klienti ˇ pˇripojuj´ı k obˇema server˚ um z´aroveˇ n. Sipka pouze naznaˇcuje server, k nˇemuˇz se klient pokus´ı pˇripojit jako prvn´ı.

2.5

Failover datab´ az´ı

2.6

Memcached

2.7

chat01

2.8

Zjednoduˇ sen´ı definic virtual host˚ u

Virtual host, nebo-li virtu´aln´ı server lze povaˇzovat za z´akladn´ı jednotku v kter´e se pˇri konfiguraci apache pohybujeme. Kaˇzd´ y virtual host pˇredstavuje jednu, nebo v´ıce dom´en, kter´e na serveru bˇeˇz´ı. Prostˇred´ı virtual host˚ u produkce je v naˇsem pˇr´ıpadˇe pˇrev´aˇznˇe homogenn´ı. D´ıky absenci koncepˇcn´ıho pˇr´ıstupu k vytv´aˇren´ı virtual host˚ u, v nich nebyl p˚ uvodnˇe ˇz´adn´ y poˇr´adek. Zvykem bylo kop´ırovat jiˇz existuj´ıc´ı definice a pˇreps´an´ım dom´eny vytvoˇrit definici novou. Tento pˇr´ıstup naprosto znemoˇzn ˇoval jak´ekoliv u ´pravy, kter´e by se mˇely dotknout vˇsech z´akazn´ık˚ u nar´az. 1 2 3 4 5 6 7 8 9 10 11

# Macro t o d e f i n e per−customer c o n f i g u r a t i o n . Example : # $customer − Name o f custom f o l d e r # $ v e r s i o n − A p p l i c a t i o n v e r s i o n ( v44svncustom , v47−s t a b l e , e t c . . ) <Macro IWCustomer $ c u s t o m e r $ v e r s i o n > # custom s p e c i f i c r e s o u r c e s Use I W o l d r e s o u r c e 3 $ v e r s i o n $ c u s t o m e r # send t o f u l l i n t e g r a t i o n RewriteCond %{REQUEST URI} ! . ∗ \ . ( j s | i c o | g i f | j p g | png | c s s | html | xml | t x t | s w f ) RewriteCond %{REQUEST URI} ˆ/ $ c u s t o m e r / . ∗ R e w r i t e R u l e ! \ . ( j s | i c o | g i f | j p g | png | c s s | html | xml | t x t | s w f ) $ %{DOCUMENT ROOT}/ $ v e r s i o n / p o r t a l / c o r e / p u b l i c / i n d e x . php [ L , NS ]

12 13 Use I W L i b f u l l $ v e r s i o n 14 15 16 <Macro I W o l d r e s o u r c e 3 $ v e r s i o n $customer> 17 # o l d p o r t a l r e s o u r c e s such as images and s c r i p t s 18 RewriteCond %{REQUEST URI} ˆ/ $ c u s t o m e r / . ∗ 19 R e w r i t e R u l e / ( [ ˆ / ] ∗ ) / ( . ∗ ) \ . ( j s | i c o | g i f | j p g | png | c s s | html | xml | t x t | s w f ) $ %{DOCUMENT ROOT }/ $ v e r s i o n / a p p l i c a t i o n / $2 . $3 [ L ] 20 21 22 <Macro I W L i b f u l l $ v e r s i o n > 23 # d o j o l i b r a r y 24 RewriteCond %{REQUEST URI} [ ˆ / ] ∗ / dojo−l i b / . ∗ 25 R e w r i t e R u l e [ ˆ / ] ∗ / dojo−l i b / ( . ∗ ) %{DOCUMENT ROOT}/ $ v e r s i o n / l i b / d o j o / a c t u a l / $1 [ L ] 26 # f c k e d i t o r l i b r a r y 27 RewriteCond %{REQUEST URI} [ ˆ / ] ∗ / f c k e d i t o r −l i b / . ∗ 28 R e w r i t e R u l e [ ˆ / ] ∗ / f c k e d i t o r −l i b / ( . ∗ ) %{DOCUMENT ROOT}/ $ v e r s i o n / l i b / f c k e d i t o r / a c t u a l / $1 [ L ] 29 30 31 Use IWCustomer c u s t o m e r a a p p l i c a t i o n −47 s t a b l e 32 Use IWCustomer c u s t o m e r b application44 33 Use IWCustomer c u s t o m e r c a p p l i c a t i o n −p r e 4 6 34 Use IWCustomer c u s t o m e r d application44

30

Listing 2.7: mod macro Vznikl proto projekt zjednoduˇsen´ı definic virtual host˚ u“. Z´akladn´ı v´ yrazov´e prostˇredky ” konfigurac´ı apache nedovoluj´ı jednoduˇse obs´ahnout konfigurace naˇs´ı produkce bez zbyteˇcn´eho y jak jiˇz n´azev napov´ıd´a, opakov´an´ı. Pouˇzili jsme proto modul apache mod macro, kter´ dovoluje psan´ı maker v konfigurac´ıch apache. Existuj´ı i sloˇzitˇejˇs´ı moduly, umoˇzn ˇuj´ıc´ı pouˇz´ıv´an´ı cykl˚ u, promˇenn´ ych, funkc´ı, atp. . . Takov´eto moduly jsme ale nepouˇzili. Chtˇeli jsme se vyhnout pˇr´ıliˇsn´e komplikaci definic virtual host˚ u. Bylo by sice sympatick´e, ˇze by se definice stovek z´akazn´ık˚ u veˇsly na nˇekolik m´alo ˇr´adk˚ u. Bylo by n´am to ale ve v´ ysledku k niˇcemu, pokud bychom se v nich nedok´azali jednoduˇse orientovat. Tuto myˇslenku koneckonc˚ u prosazuje i s´am autor mod macro na domovsk´e str´ance tohoto projektu [6]: ... In my opinion, this stuff MUST NOT grow to a full language. It should just grow to what is needed to manage configuration files simply and elegantly, and to avoid unnecessary copy-pastes. I may consider adding a foreach repetition section, if proven useful. I may also consider reimplementing a working Include since the current one does not work properly (bug #3169/#3578). But no while, no arithmetics, no variables, no recursion, no goto, no sql, no extended regexpr... Never: I’ll stick to the KISS Principle. (Keep It Simple, Stupid!) Uk´azka pouˇzit´ı mod macro je vidˇet na zdrojov´em k´odu 2.7. Opˇet se jedn´a pouze o uk´azku. Definice zde uveden´a nen´ı shodn´a s tou, jeˇz je pouˇz´ıv´ana na naˇs´ı produkci.

31

Kapitola 3 Syst´ em pro automatickou spr´ avu konfigurac´ı server˚ u Z t´emat prob´ıran´ ych dˇr´ıve v t´eto pr´aci a zejm´ena z kaˇzdodenn´ıch potˇreb pˇri interakci s produkc´ı vznikl n´asleduj´ıc´ı seznam poˇzadavk˚ u na spr´avu produkˇcn´ıho prostˇred´ı: Dokumentace Produkce vznikala dlouhou dobu ad-hoc, bez dlouhodob´eho konceptu, za u ´ˇcasti r˚ uzn´ ych administr´ator˚ u. Dokumentace byla tedy omezena na nˇekolik m´alo wiki str´anek, kter´e ke vˇsemu nebyly dlouhou dobu aktualizovan´e. Obecn´ y probl´em dokumentac´ı je ten, ˇze je m´alokdo dˇel´a r´ad. Proto poˇzadavkem na tento syst´em byla alespoˇ n minim´aln´ı schopnost automatick´e dokumentace. Automatizace Na produkci je prov´adˇeno velk´e mnoˇzstv´ı u ´kon˚ u, kter´e by bylo moˇzn´e t´ımto syst´emem automatizovat. Pˇrev´aˇznˇe jde o konfigurace apache pro jednotliv´e z´akazn´ıky, aktualizace d˚ uleˇzit´ ych bal´ıˇck˚ u syst´emu, hromadn´a instalace nov´eho software, atp. . . Jednotnost Kaˇzd´ y administr´ator do produkce vnesl vlastn´ı specifick´a ˇreˇsen´ı. To obvykle nen´ı probl´em, pokud je ˇreˇsen´ı nˇejak´eho probl´emu pouˇzito napˇr´ıˇc celou produkc´ı. Pokud by se napˇr´ıklad zp˚ usob nastaven´ı apache v´ yraznˇe liˇsilo mezi jednotliv´ ymi v´ ypoˇcetn´ımi servery, mohlo by zbyteˇcnˇe doch´azet k omyl˚ um. ˇ od ˇcasu se m˚ Ovladatelnost Cas uˇze st´at, ˇze syst´em bude muset ovl´adat osoba neznal´a detail˚ u produkce. V takov´em pˇr´ıpadˇe je potˇreba, aby i neznal´ y ˇclovˇek dok´azal prov´est alespoˇ n z´akladn´ı u ´kony pro vyˇreˇsen´ı probl´emu. Rozˇ siˇ ritelnost Syst´em mus´ı b´ yt jednoduˇse rozˇsiˇriteln´ y nad r´amec pr´ace vykonan´e pˇri vzniku tohoto dokumentu. Sebelepˇs´ı ˇreˇsen´ı, jenˇz nen´ı moˇzn´e d´ale rozˇsiˇrovat je k niˇcemu. Nez´ avislost Syst´em nesm´ı b´ yt v´az´an licenc´ı omezuj´ıc´ı jeho pouˇzit´ı, ˇci u ´pravy. Tyto podm´ınky definuj´ı z´akladn´ı r´amec aplikace pro spr´avu konfigurac´ı, jeˇz je hlavn´ım pˇredmˇetem t´eto pr´ace. Potˇreba spravovat konfigurace server˚ u historicky vznikla v dobˇe, kdy si jedna spoleˇcnost mohla dovolit vlastnit v´ıce jak jeden server. N´astup virtualizaˇcn´ıch technologi´ı tuto potˇrebu silnˇe umocnil. Jeden hardwarov´ y server dok´aˇze dnes v jist´ ych situac´ıch hostovat aˇz des´ıtky server˚ u virtu´aln´ıch. Jakkoli velk´a skupina administr´ator˚ u v dneˇsn´ı dobˇe jednoduˇse nem˚ uˇze ruˇcnˇe spravovat takov´e mnoˇzstv´ı stroj˚ u. Pojd’me si tedy pˇredstavit v dneˇsn´ı dobˇe nejzn´amˇejˇs´ı Configuration Management Software (CMS).

32

3.1 3.1.1

Pˇ rehled CMS cfengine

Cfengine je software pro spr´avu konfigurac´ı zaloˇzen´ y na modelu klient-server. Kter´ ykoliv klient, jeˇz se svoj´ı konfigurac´ı odklon´ı od poˇzadovan´eho stavu je do nˇej zpˇet uveden. Stav konfigurace je uv´adˇen pomoc´ı deklarativn´ıho jazyka. Osobnˇe mi cfengine svoj´ı syntax´ı pˇriˇsel velmi matouc´ı. Pˇri pokusu o seps´an´ı z´akladn´ı konfigurace testovac´ıho serveru nebylo zˇrejm´e jak na to“. Syntaxe jazyka pro mˇe nem´a nˇejak´ y zˇrejm´ y, pohledovˇe“ ” ” pˇrehledn´ y form´at. Syst´em s´am o sobˇe nab´ız´ı rozumn´e mnoˇzstv´ı podp˚ urn´ ych prostˇredk˚ u. Instalace bal´ıˇck˚ u, definice soubor˚ u a jejich obsahu, definice mount˚ u, atp. . . Mezi velk´e ´ y v´ spoleˇcnosti vyuˇz´ıvaj´ıc´ı cfengine patˇr´ı napˇr´ıklad: AMD, Disney, Nokia, FedEx. Upln´ yˇcet je k nalezen´ı na webu cfengine [4]. Prvn´ı ofici´aln´ı vyd´an´ı je datov´ano rokem 1993, zdrojov´e k´ody jsou v jazyce C a licence je GNU General Public License (GPL).

3.1.2

chef

Chef je naps´an v ruby a je licencov´an pod Apache License. Prvn´ı vyd´an´ı je datov´ano k poˇc´atku roku 2009. Pˇri seznamov´an´ı s t´ımto softwarem jsem mˇel velk´e probl´emy s pochopen´ım principu fungov´an´ı a z´akladn´ıch princip˚ u. Z´akladn´ı nastaven´ı jednoho serveru a jednoho klienta trvalo velmi dlouho a vyˇzadovalo velkou ˇradu krok˚ u. Konfiguraˇcn´ı soubory jsou rozˇs´ıˇren´ y jazyk Ruby, coˇz nˇekteˇr´ı lid´e pohybuj´ıc´ı v oboru konfiguraˇcn´ıho managementu pouvaˇzuj´ı za nev´ yhodu [12]. Za velkou nev´ yhodu povaˇzuji nestandardn´ı postup instalace na n´ami prim´arnˇe pouˇz´ıvan´e distribuci - Debian.

3.1.3

puppet

Puppet je naps´an v Ruby, vyd´av´an je pod Apache License a prvn´ı vyd´an´ı je datov´ano k roku 2005. Je obsaˇzen jako standardn´ı bal´ıˇcek ve vˇsech n´ami pouˇz´ıvan´ ych distribuc´ıch. Syntax konfigurac´ı je velmi jednoduch´ y, pˇr´ıjemn´ y na ˇcten´ı a pˇrehledn´ y. Puppet pouˇz´ıvaj´ı napˇr´ıklad firmy Oracle SUN, digg, twitter, a dalˇs´ı. . . Tento software nab´ız´ı nativn´ı podporu pro spr´avu velk´eho mnoˇzstv´ı r˚ uzn´ ych souˇc´ast´ı syst´emu.

3.1.4

Z´ avˇ er

V´ yˇcet CMS zde uveden´ y rozhodnˇe nen´ı nijak vyˇcerp´avaj´ıc´ı a nezach´az´ı do detail˚ u moˇznost´ı a vlastnost´ı jednotliv´ ych softwarov´ ych produkt˚ u. Pˇri m´em seznamov´an´ı s jednotliv´ ymi CMS jsem se u kaˇzd´eho setkal s probl´emy, nebo nepˇr´ıjemn´ ymi vlastnostmi, jeˇz mne od pouˇzit´ı pr´avˇe toho, ˇci onoho produktu zrazovaly. Nejl´epe v m´em experimentov´an´ı dopadl puppet, kter´ y byl velmi jednoduch´ y na instalaci a z´akladn´ı konfiguraci. Nab´ız´ı velmi snadn´e n´avody pro zaˇc´ateˇcn´ıky. D˚ uvod pro zvolen´ı tohoto produktu jako naˇseho syst´emu ˇ pro spr´avu konfigurac´ı je tedy kombinac´ı n´asleduj´ıc´ıch faktor˚ u: Casov´ y pres, nut´ıc´ı technologie pouˇz´ıvat nam´ısto toho si s nimi hr´at“. Velmi jednoduch´a poˇc´ateˇcn´ı konfigurace ” a strm´a kˇrivka uˇcen´ı. Rozs´ahl´a dokumentace s kvalitn´ımi pˇr´ıklady jak na ofici´aln´ım webu, tak na webech fanouˇsk˚ u. Pocitovˇe v´ yrazn´e zamˇeˇren´ı dneˇsn´ı internetov´e komunity konfiguraˇcn´ıch manaˇzer˚ u pr´avˇe na puppet. V´ ybˇer pr´avˇe tohoto softwaru tedy nen´ı podepˇren nˇejakou rozs´ahlou anal´ yzou schopnost´ı softwaru, jeho budouc´ıho v´ yvoje, ˇci vhodnosti pouˇzit´ı pro n´aˇs pˇr´ıpad. Firma jako takov´a se nezab´ yv´a dod´av´an´ım softwaru pro spr´avu konfigurac´ı. Puppet byl p˚ uvodnˇe zam´ yˇslen jako okrajov´ y podp˚ urn´ y software, ale pˇrirozenou evoluc´ı z nˇej vznikl mocn´ y n´astroj pro podporu serverov´ ych proces˚ u firmy. Obh´ajen´ı m´eho v´ ybˇeru tedy bude st´at 33

na zpˇetn´em pohledu a prok´az´an´ı toho, ˇze nasazen´ı pr´avˇe t´eto technologie bylo pro firmu pˇr´ınosem. Samozˇrejmˇe pokud bychom bˇehem adopce t´eto technologie narazili na z´avaˇzn´e probl´emy, pak by se pr´ace pozastavily a zapoˇcali bychom s bliˇzˇs´ım zkoum´an´ım jin´e technologie.

3.2

Puppet

Software puppet byl vybr´an pro n´aˇs projekt pˇrevzet´ı produkce“. Pod pojmem pˇrevzet´ı ” je myˇsleno zmapov´an´ı veˇsker´eho pouˇz´ıvan´eho softwaru, vytvoˇren´ı produkˇcn´ı dokumentace, sjednocen´ı pouˇz´ıvan´ ych postup˚ u napˇr´ıˇc servery a automatizace ˇcasto pouˇz´ıvan´ ych ’ postup˚ u. To je pomˇernˇe ˇsirok´ y z´abˇer u ´kol˚ u na jeden software. Pojd me si tedy nejprve probrat z´akladn´ı principy fungov´an´ı puppetu. Puppet m´a velmi specifick´ y jazyk pro popis stavu syst´emu. Vzniklo tedy n´azvoslov´ı charakteristick´e pro tento jazyk. Pojmy jsou obˇcas n´apadnˇe podobn´e pojm˚ um ze svˇeta tradiˇcn´ıho“ programov´an´ı. V´ yznam je ale obvykle trochu posunut´ y. Proto bych se nyn´ı ” r´ad odk´azal na anglick´ y slovn´ık staˇzen´ y pˇr´ımo z webu v´ yvoj´aˇr˚ u puppetu [17]. Slovn´ık lze nal´ezt v pˇr´ıloze C.1

3.2.1

Jak puppet funguje

Hlavn´ı c´ıl v´ yvoj´aˇr˚ u puppetu je poskytnout dostateˇcnˇe elegantn´ı a efektivn´ı jazyk pro popis konfigurace (stavu) syst´emu. Tento jazyk mus´ı umoˇznit definovat stav vˇsech prvk˚ u operaˇcn´ıho syst´emu a n´aslednˇe tyto prvky do onˇech definovan´ ych stav˚ u uv´est. Puppet tedy vynucuje stav operaˇcn´ıho syst´emu dle konfiguraˇcn´ıch soubor˚ u, takzvan´ ych manifest˚ u. Vyuˇz´ıv´a pˇritom architektury klient - server. Klientem se rozum´ı server, jenˇz je konfigurov´an. Serveru se bˇeˇznˇe ˇr´ık´a puppet master a pr´avˇe na nˇem je uloˇzena konfigurace vˇsech klient˚ u. Klienti se ve standardn´ım sc´en´aˇri pravidelnˇe pˇripojuj´ı na server a ˇza´daj´ı ho o svou konfiguraci. Tato situace je zn´azornˇena na obr´azku 3.1. Toto je zajiˇstˇeno spuˇstˇen´ ym d´emonem na kaˇzd´em klientu. Obdobn´ y d´emon pak bˇeˇz´ı i na serveru a kompletuje“ kon” figurace pro jednotliv´e klienty z jednotliv´ ych manifest˚ u do takzvan´eho katalogu. Tato situace je vidˇet na obr´azku 3.2. Instalace puppetu je, jak uˇz bylo ˇreˇceno v´ yˇse, jednoduch´a. V distribuci Debian staˇc´ı pˇres bal´ıˇckovac´ı syst´em nainstalovat bal´ıˇcek puppet - na klientsk´ ych stroj´ı, ˇci puppetmaster - na serveru. Jelikoˇz serverov´ y stroj s´am o sobˇe tak´e potˇrebuje konfigurovat, je doporuˇcen´ ym postupem nastavit ho souˇcasnˇe i jako klientsk´ y stroj. Pro z´akladn´ı bˇeh serveru nen´ı potˇreba dˇelat nic speci´aln´ıho. Klient potˇrebuje vˇedˇet na jak´em stroji bˇeˇz´ı server, viz uk´azka ve zdrojov´em k´odu 3.2. Spojen´ı klient˚ u se serverem je z´avisl´e na autentikaci pomoc´ı certifik´at˚ u. Pro spr´avn´e fungov´an´ı si klient u serveru mus´ı zaˇza´dat o registraci sv´eho veˇrejn´eho kl´ıˇce. Teprve po registraci tohoto kl´ıˇce je povoleno obsluhov´an´ı klienta serverem. Tento postup je vidˇet ve v´ ypisu konzole 3.1. 1 2 3 4 5 6 7

# Zazadame o z a r e g i s t r o v a n i c e r t i f i k a t u na s e r v e r u web03 : ˜ # p u p p e t d −−w a i t f o r c e r t 60 −−debug −−v e r b o s e −−no−daemonize 2> / dev / n u l l # Pro z o b r a z e n i p r a v e c e k a j i c i c h r e g i s t r a c i dev01 : ˜ # p u p p e t c a −− l i s t web03 . mydomain . t l d # Timto p r i k a z e m sparujeme c e k a j i c i r e g i s t r a c i c e r t i f i k a t u pro dany s e r v e r dev01 : ˜ # p u p p e t c a −−s i g n web03 . mydomain . t l d

Listing 3.1: Uk´azka sp´arov´an´ı klienta se serverem - puppet 1 [ main ] 2 server

= dev01 . mydomain . t l d

Listing 3.2: Uk´azka konfigurace puppet klienta /etc/puppet/puppet.conf 34

Obr´azek 3.1: Model klient-server softwaru puppet

Obr´azek 3.2: Kompletace manifest˚ u puppet masterem

Po t´eto s´erii pˇr´ıkaz˚ u by na puppet masteru, jenˇz je nainstalovan´ y na stroji dev01 mˇel b´ yt nainstalov´an certifik´at pro server web03. Od t´eto chv´ıle tedy m˚ uˇze server web03 ˇza´dat o jemu patˇr´ıc´ı katalogy. Velmi ˇcast´ y probl´em tohoto kroku je ten, ˇze servery nepouˇz´ıvaj´ı plnˇe kvalifikovan´e dom´enov´e jm´eno1 (Fully Qualified Domain Name (FQDN)), a proto m´a klient probl´em s registrac´ı certifik´atu na serveru. Doporuˇcen´ ym ˇreˇsen´ım tak je pouˇz´ıvat FQDN na vˇsech m´ıstech: Pro z´aznamy v /etc/hosts, DNS z´aznamy, hostname server˚ u, konfigurace puppetu.

3.2.2

Z´ aklady jazyka manifest˚ u puppetu

Puppet master vˇzdy zaˇc´ın´a souborem manifests/site.pp, kter´ y pˇri kompletaci katalogu naˇcte do pamˇeti a hled´a z´aznam typu node, jenˇz se shoduje s hostname pr´avˇe obsluhovan´eho klienta. Pot´e nalezne odkazy na veˇsker´e zdroje 2 , jejich z´avislosti, potˇrebn´e soubory 1

Napˇr´ıklad: web03.mydomain.tld Zdrojem se v puppetu rozum´ı nˇejak´a vlastnost syst´emu. Napˇr´ıklad soubor, nastaven´ı nˇejak´e hodnoty OS, existence bal´ıˇcku, atp. . . 2

35

a vytvoˇr´ı z nich katalog3 . Pˇr´ıruˇcka Puppet best practices 2.0 [13] je dle m´eho n´azoru velmi kvalitn´ı referenc´ı k z´akladn´ımu fungov´an´ı puppetu a n´avod jak ps´at kvalitn´ı puppet manifesty. Tato pˇr´ıruˇcka doporuˇcuje pouˇz´ıt soubor manifests/site.pp pouze pro definici prvk˚ u spoleˇcn´ ych vˇsem server˚ um, ˇci glob´aln´ıch definic. A definici jednotliv´ ych server˚ u vloˇzit do souboru manifests/nodes.pp jenˇz bude v site.pp naˇc´ıt´an. Jelikoˇz nem´ame dokonale heterogenn´ı prostˇred´ı, um´ıstili jsme do site.pp tak´e definice, jeˇz m˚ uˇze vyuˇz´ıvat kter´ ykoliv ze server˚ u. Uk´azka tohoto souboru je v zdrojov´em k´odu B.2. Takov´eto definice se velmi hod´ı pˇri zmˇenˇe verze, ˇci distribuce operaˇcn´ıho syst´emu. Na tomto pˇr´ıkladu je hezky vidˇet pr´ace puppetu s elementem typu package. Puppet pouˇz´ıv´a takzvan´e providery, neboli poskytovatele pro obsluhu jednotliv´ ych bal´ıˇckovac´ıch syst´em˚ u. Poskytovatel´e se mˇen´ı podle pouˇzit´e distribuce OS klienta. Pokud je na klientu pouˇzit Debian, pak se pouˇzije provider apt, pokud Gentoo, pak bude pouˇzit poskytovatel portage. Je tak vlastnˇe teoreticky jedno jakou distribuci puppet obsluhuje, pˇr´ıstup ve vˇsech ostatn´ıch manifestech by mˇel b´ yt na pouˇzit´e distribuci nez´avisl´ y4 . Pro z´ısk´av´an´ı informac´ı o operaˇcn´ım syst´emu klienta puppet pouˇz´ıva open-source Ruby knihovnu facter. Facter m´a za u ´kol pˇrin´aˇset jednotn´e rozhran´ı pro z´ısk´av´an´ı z´akladn´ıch ifnormac´ı o serveru bez z´avislosti na typu OS, ˇci specifik´ach dan´ ych distribuc´ı. Uk´azka pr´ace facteru je vidˇet na zdrojov´em k´odu ?? 1 2 3 4 5 6 7 8 9 10

dev01 : ˜ # f a c t e r a r c h i t e c t u r e => amd64 domain => mydomain . t l d f a c t e r v e r s i o n => 1 . 5 . 1 fqdn => dev01 . mydomain . t l d h a r d w a r e i s a => unknown hardwaremodel => x 8 6 6 4 hostname => dev01 i d => r o o t i n t e r f a c e s => eth0 , tap

Listing 3.3: Uk´azka pr´ace knihovny facter Puppet dle dokumentace [? ] nativnˇe podporuje velk´e mnoˇzstv´ı typ˚ u zdroj˚ u. Je tak moˇzn´e spravovat z´aznamy v /etc/crontab, pˇrid´avat syst´emov´e bal´ıˇcky, instalovat soubory konfigurac´ı, definovat pravidla firewallu, pˇrid´avat a odeb´ırat syst´emov´e uˇzivatele, upravovat syst´emov´e mounty, ukl´ızet nepoˇr´adek“ na disku, atp. . . Moˇznost´ı je opravdu hodnˇe ” a neexistuje pouze jeden postup pro dosaˇzen´ı nˇejak´eho c´ıle. Puppet m˚ uˇze vyuˇz´ıvat takzvan´e erb templaty pro definici obsahu soubor˚ u. ERB template nen´ı nic sloˇzitˇejˇs´ıho, neˇz ˇsablona do n´ıˇz jsou na z´astupn´a m´ısta doplnˇeny hodnoty promˇenn´ ych. ERB samozˇrejmˇe umoˇzn ˇuje vˇetven´ı, cykly, promˇenn´e a dalˇs´ı vlastnosti zn´am´e z bˇeˇzn´ ych programovac´ıch jazyk˚ u. Vznik´a tak elegantn´ı moˇznost nahr´an´ı konfiguraˇcn´ıch soubor˚ u jednotliv´ ych bal´ıˇck˚ u OS, aniˇz by administr´ator musel b´ yt odk´az´an na neflexibiln´ı statick´e soubory. V´ıce o ERB si lze pˇreˇc´ıst v dokumentaci Ruby [5], ˇci ˇ v dokumentaci puppetu [16]. Sablony jsou uloˇzeny v podadres´aˇri /template. Jazyk puppetu umoˇzn ˇuje definovat z´avislosti. A to hned dvoj´ıho druhu: require Pokud je instance nˇejak´eho zdroje z´avisl´a na jin´e instanci, lze tuto z´avislost oznaˇcit touto vlastnost´ı. Puppet pot´e zaˇr´ıd´ı, ˇze instance na n´ıˇz je naˇse instance z´avisl´a bude vyhodnocena dˇr´ıve. notify Pokud se dan´a instance zmˇen´ı (nejˇcastˇeji zmˇena obsahu souboru), pak je instance na n´ıˇz ukazuje tato vlastnost o t´eto zmˇenˇe uvˇedomˇena. Obvykle se jedn´a o restart ´ celem tohoto dokumentu ale nen´ı vyˇcerp´avaj´ıc´ı popis Postup je re´ alnˇe samozˇrejmˇe daleko sloˇzitˇejˇs´ı. Uˇ vnitˇrn´ıho fungov´ an´ı puppetu. 4 Samozˇrejmˇe situace nen´ı tak jednoduch´a a urˇcit´e probl´emy d´ıky r˚ uzn´ ym distribuc´ım z˚ ustanou. 3

36

d´emona v pˇr´ıpadˇe zmˇeny jeho konfiguraˇcn´ıch soubor˚ u. Puppet umoˇzn ˇuje tvorbu modul˚ u. Modulem se rozum´ı ucelen´a mnoˇzina manifest˚ u, ˇsablon, soubor˚ u, provider˚ u, podp˚ urn´ ych skript˚ u, atp. . . Princip modulu je ten, aby pˇri pˇrenesen´ı adres´aˇre modulu na jin´e prostˇred´ı, byl tento modul schopen fungovat. Jedn´a se tedy o jakousi organizaˇcn´ı jednotku ve struktuˇre puppetu. Pokud je modul vloˇzen do pr´avˇe zpracov´avan´eho manifestu pˇres kl´ıˇcov´e slovo Include, pak se ihned vyhled´a a zpracuje manifest modulu init.pp. Ve standardn´ı konfiguraci se puppet klient pˇripojuje na server jednou za 30 minut. Tato doba m˚ uˇze b´ yt v krizov´ ych situac´ıch neakceptovatelnˇe dlouh´a. A nejen tehdy. Mohou napˇr´ıklad existovat pˇr´ıpady, kdy je potˇreba prov´est zmˇenu na v´ıce serverech najednou. Tehdy by se hodila moˇznost nakopnout“ klienty, aby si zaˇza´dali o nov´ y, aktualizovan´ y ” katalog. Tato moˇznost opravdu existuje a v puppetu se j´ı pˇr´ıhodnˇe ˇr´ık´a puppet kick. Tuto moˇznost m´a puppet master a to pouze tehdy, pokud je k tomu dan´ y klient nakonfigurovan´ y a pokud na klientu bˇeˇz´ı puppet d´emon. Uk´azka skriptu, jenˇz vyuˇz´ıv´a t´eto vlastnosti je vidˇet na zdrojov´em k´odu 3.4. 1 2 3 4 5 6 7 8

#! / b i n / b a s h NODES=(web02 web03 web04 web05 ) DOMAIN=’mydomain . t l d ’ f o r node i n ” $ {NODES[@] } ” ; do puppet k i c k −−f o r e g r o u n d −−debug ” $ { node } . $ {DOMAIN} ” done

Listing 3.4: Uk´azka puppet kick Konfiguraci puppetu m´ame uloˇzenou v subversion (svn). Pro vˇetˇs´ı pohodl´ı pr´ace jsme vyuˇzili schopnost´ı svn serveru reagovat pˇri urˇcit´ ych ud´alostech. Vytvoˇrili jsme svn hook, kter´ y pˇri kaˇzd´em commitu zkontroluje, zda nebyly zmˇenˇeny soubory puppetu. Pokud ano, automaticky je aktualizuje u puppet mastera. Tento skript je uloˇzen na svn serveru v hooks/post-commit a jeho obsah je vidˇet na zdrojov´em k´odu 3.5 1 2 3 4 5 6 7 8 9 10 11

#! / b i n / sh REPOS=” $1 ” REVISION=” $2 ” s v n l o o k changed $ {REPOS} | g r e p ’ puppet ’ r e t c o d e=$ ? i f [ $ r e t c o d e −eq 0 ] ; then # Was p u p p e t r e p o changed ? svn up / e t c / puppet / # Update p u p p e t master r e p o s i t o r y fi

Listing 3.5: SVN hook pro automatickou aktualizaci puppet mastera

3.2.3

Pˇ r´ıpady uˇ zit´ı puppetu

Hlavn´ı ˇca´st pr´ace t´eto kapitoly byla jiˇz ˇc´asteˇcnˇe obsaˇzena v kapitol´ach pˇredchoz´ıch. Napˇr´ıklad ruku v ruce s pˇrechodem produkce na GlusterFS musely b´ yt upraveny definice mount˚ u jednotliv´ ych server˚ u. V t´eto kapitole se tedy pokus´ım probrat jednotliv´e pˇr´ıpady, kter´e puppet obsluhuje a s kter´ ymi n´am v´ yraznˇe zjednoduˇsil pr´aci. Sjednocen´ı prostˇ red´ı Za relativnˇe kr´atkou dobu, co pracuji v oboru konfiguraˇcn´ıho managementu, mus´ım ˇr´ıci ˇze m´alokter´a vlastnost server˚ u dok´aˇze naˇstvat v´ıce, neˇz je nejednotnost prostˇred´ı. R˚ uzn´e

37

nastaven´ı PS15 , rozd´ıln´e nastaven´ı doplˇ nov´an´ı tabul´atoru, r˚ uzn´e chov´an´ı editoru vim6 , absence z´akladn´ıch bal´ıˇck˚ u, atp. . . Vˇsechny tyto body dˇelaj´ı pr´aci se servery komplikovanou a nepˇr´ıjemnou. D´ıky pouˇzit´ı CMS puppet se n´am podaˇrilo tyto nepˇr´ıjemnosti odstranit. Kaˇzd´ y server, jenˇz je puppetem ovl´ad´an dostane automaticky z´akladn´ı sadu bal´ıˇck˚ u a nastaven´ı nˇekter´ ych program˚ u. Pro pˇr´ıklad: ´ /etc/motd.tail Uvodn´ ı zpr´ava, jenˇz se vyp´ıˇse po pˇrihl´aˇsen´ı uˇzivatele. Vˇetˇsina distribuc´ı pˇrid´av´a sv´e velmi dlouh´e zpr´avy o licenˇcn´ım ujedn´an´ı, naposledy pˇrihl´aˇsen´ ych uˇzivatel´ıch, ˇci informace o tom kde sehnat n´apovˇedu. Tyto informace rozhodnˇe nejsou potˇreba a pˇri pr´aci jen zbyteˇcnˇe rozptyluj´ı. /etc/aliases Vˇetˇsina program˚ u pos´ıl´a hl´aˇsen´ı na u ´ˇcet uˇzivatele root. Tento soubor m˚ uˇze definovat na jakou e-mailovou adresu pak tento e-mail dojde. vim Vim je velice mocn´ y textov´ y editor. Osobnˇe nezn´am lepˇs´ı n´astroj pro u ´pravu konfiguraˇcn´ıch soubor˚ u, ˇci jen zdrojov´ ych k´od˚ u. Pˇres velmi tˇeˇzk´e poˇca´teˇcn´ı zauˇcen´ı vim vˇrele doporuˇcuji kaˇzd´emu administr´atorovi. logwatch Logwatch sleduje logy syst´emu a vytv´aˇr´ı pravideln´e reporty. Nejednou jsme tak byli varov´an´ı na bl´ıˇz´ıc´ı se probl´em. puppet Puppet je zde jmenov´an z d˚ uvod˚ u aktualizace tohoto bal´ıˇcku. Z principu jiˇz nainstalovan´ y b´ yt mus´ı. git Git je distribuovan´ y verzovac´ı syst´em. Kaˇzd´ y server v m´e spr´avˇe m´a verzovan´ y adres´aˇr /etc/. Velmi vˇrele tuto praktiku doporuˇcuji kaˇzd´emu, kdo pˇreb´ır´a jiˇz existuj´ıc´ı server po jin´em administr´atorovi. Omyly se st´avaj´ı a m´ıt z´alohu konfiguraˇcn´ıch soubor˚ u je ˇcasto k nezaplacen´ı. bash Bˇeˇznˇe pouˇz´ıvan´ y shell. Opˇet uveden pouze z d˚ uvod˚ u pravideln´e aktualizace. Souˇcasnˇe s puppet modulem pro bash pˇrijde i jednotn´e nastaven´ı PS1. snmpd Velk´e mnoˇzstv´ı sluˇzeb a program˚ u souvisej´ıc´ıch se spr´avou server˚ u vyuˇz´ıv´a protokol SNMP. Tento bal´ıˇcek je nutn´ y uˇz z d˚ uvod˚ u monitorov´an´ı probran´eho v kapitole 2.2 ntp Velk´e mnoˇzstv´ı sluˇzeb a program˚ u pro sv´e spr´avn´e fungov´an´ı vyˇzaduje spr´avnˇe seˇr´ızen´e syst´emov´e hodiny. Program NTP se o toto dok´aˇze postarat. Toto je z´akladn´ı sada bal´ıˇck˚ u a konfiguraˇcn´ıch soubor˚ u, jenˇz povaˇzuji za nepostradatelnou na kaˇzd´em serveru. Instalaci bal´ıˇck˚ u jsem v puppetu ˇreˇsil jako samostatn´e moduly. L´epe se pak k´od udrˇzuje. Zejm´ena pokud k bal´ıˇck˚ um patˇr´ı i nˇejak´e konfiguraˇcn´ı soubory, ˇci ˇsablony. Prov´adˇet vloˇzen´ı (include) tˇechto modul˚ u v kaˇzd´em node by ale bylo velmi nepraktick´e. Proto jsem nejprve pˇredpokl´adal, ˇze vytvoˇr´ım obecn´ y node a od nˇeho pot´e od dˇed´ım vˇsechny ostatn´ı nody. Bohuˇzel v puppetu dˇediˇcnost nod˚ u nefunguje jako v bˇeˇzn´em objektov´em jazyce. Tento fakt zachycuje i dokument Common puppet misconceptions [15]. Promˇenn´a nastaven´a v potomkovi se nevypropaguje do rodiˇce. Tˇr´ıdy vloˇzen´e v rodiˇci pak nelze ˇz´adn´ ym zp˚ usobem z potomka parametrizovat. Jednalo by se tedy o znaˇcn´e omezen´ı. M´ısto tohoto postupu se tedy bˇeˇznˇe m´ısto rodiˇcovsk´eho node vytv´aˇr´ı tˇr´ıda, 5ˇ

R´ adek, jenˇz je vytiˇstˇen do pˇr´ıkazov´e ˇr´adky po kaˇzd´em ukonˇcen´em pˇr´ıkazu, jenˇz pˇred´a vol´an´ı zpˇet do shellu. 6 Nebo jin´eho editoru.

38

kter´a se pouze vkl´ad´a. Zde pˇredefinov´an´ı promˇenn´ ych jiˇz funguje. N´ami vytvoˇren´a tˇr´ıda se jmenuje base node class a uk´azka jej´ıho pouˇzit´ı je vidˇet na zdrojov´em k´odu 3.6. T´ımto jednoduch´ ym k´odem si pˇriprav´ıme server db01 tak, aby se pro n´as v z´akladn´ıch bodech choval stejnˇe jako vˇsechny ostatn´ı. 1 node db01 { 2 include base node class 3 }

Listing 3.6: Uk´azka pouˇzit´ı base node class GlusterFS a adres´ aˇ re uˇ zivatelsk´ ych dat Jak jiˇz bylo probr´ano v kapitole 1.6.3, server s adres´aˇri uˇzivatelsk´ ych dat proˇsel za dobu zpracov´an´ı tohoto projektu v´ yznamn´ ymi zmˇenami. Pˇredevˇs´ım se jedn´a o pˇrechod z technologie NFS na technologii GlusterFS. Bˇehem t´eto realizace n´am puppet v´ yznamnˇe pomohl s vypropagov´an´ım zmˇen na vˇsechny potˇrebn´e servery. V p˚ uvodn´ım ˇreˇsen´ı (NFS) byla uˇzivatelsk´a data ˇreˇsena modulem nfs-mounts, jenˇz je pˇriloˇzen k t´eto pr´aci. Nov´e ˇreˇsen´ı, zaloˇzen´e na technologii GlusterFS je obsaˇzeno v modulu gluster. Tato technologie obsahuje mezi jednotliv´ ymi verzemi razantn´ı zmˇeny. Potˇrebovali jsme tedy dos´ahnout jednotnosti verz´ı technologie Gluster na jednotliv´ ych serverech, bez ohledu na distribuci, ˇci verzi distribuce. Tohoto lze za pomoc´ı puppetu pomˇernˇe elegantnˇe dos´ahnout. Manifesty nap´ıˇseme tak, ˇze si nejprve st´ahneme ze serveru bal´ıˇcky pro jednotliv´e distribuce. Pot´e je, obvykle za pomoc´ı jin´ ych provider˚ u, nainstalujeme. Vˇse mus´ı b´ yt pro spr´avnou funkˇcnost podpoˇreno odpov´ıdaj´ıc´ımi z´avislostmi (viz obr´azek A.12). Pokud nen´ı st´ahnut instalaˇcn´ı soubor, nem´a cenu se pokouˇset ho instalovat. Dokud nen´ı nainstalov´an, nem´a smysl pokouˇset se o pˇripojen´ı adres´aˇr˚ u. Stejnˇe tak nen´ı pˇripojit vzd´alen´e adres´aˇre do doby, neˇz jsou vytvoˇreny vˇsechny odpov´ıdaj´ıc´ı lok´aln´ı adres´aˇre. Atp. . . Bootstrap konfigurace serveru Puppet vlastnˇe nab´ız´ı kompletn´ı moˇznost konfigurace serveru. Ve chv´ıli, kdy je server v bootovateln´em stavu, je nainstalov´an bal´ık puppet, a na puppet masteru je nainstalov´an certifik´at dan´eho stroje. V tuto chv´ıli je moˇzn´e jiˇz veˇsker´ y ˇzivotn´ı bˇeh konfigurace serveru ˇr´ıdit pˇres CMS. A zkonfigurovat si tak server pˇresnˇe podle dan´ ych pravidel bez nutnosti ruˇcn´ıho z´asahu. Tuto teorii jsme si ovˇeˇrili u serveru watch01, jenˇz byl vybr´an pro pokusnou aktualizaci distribuce OS7 . Bohuˇzel d´ıky naˇs´ı neznalosti s technologi´ı EC2 se tento projekt nepovedl. Bylo tedy rozhodnuto, ˇze watch01 bude nainstalov´an znovu a to pˇr´ımo na novˇejˇs´ı verzi OS. Po instalaci zabere nastaven´ı puppetu pˇribliˇznˇe 5 minut. Pot´e staˇc´ı tento software spustit a za cca 20 minut je server pˇripraven´ y pˇresnˇe v takov´e podobˇe v jak´e byl pˇred zapoˇcet´ım v´ yˇse zmiˇ novan´eho projektu. Z t´eto zkuˇsenosti jsme vyvodili n´asleduj´ıc´ı d˚ usledky: • Obrovsk´ y n´ar˚ ust moˇznost´ı expanze produkce z pohledu instalace nov´ ych server˚ u. Administr´ator m´a d´ıky CMS jistotu, ˇze nov´e stroje se budou chovat oˇcek´avan´ ym zp˚ usobem. • D´ıky puppetu m´ame menˇs´ı z´avislost na poskytovateli server-housingu. • Pouˇzit´ı CMS ve v´ ysledku uˇsetˇr´ı mnoho ˇcasu administr´atora. 7

Z Debian Lenny na Debian Squeeze

39

´ Uklid serveru Disk kaˇzd´eho serveru je dˇr´ıve ˇci pozdˇeji zaneˇr´adˇen velk´ ym mnoˇzstv´ım soubor˚ u, kter´e byly ˇ administr´atorem, ˇci jin´ ymi uˇzivateli vytvoˇreny a zapomenuty. Casem si ˇza´dn´ y z uˇzivatel˚ u nevzpomene na d˚ uvod existence toho, ˇci onoho souboru. Jelikoˇz disky nemaj´ı nekoneˇcnou kapacitu, m˚ uˇze se st´at, ˇze se dˇr´ıve ˇci pozdˇeji zapln´ı. Proto vznikla potˇreba vytvoˇrit syst´em, jenˇz by nepotˇrebn´e soubory ˇcas od ˇcasu promazal. Puppet nativnˇe zn´a typ tidy. Tento, jak uˇz n´azev napov´ıd´a m´a za u ´kol odstraˇ nov´an´ı nepotˇrebn´ ych soubor˚ u. Seznam takov´ ych soubor˚ u se samozˇrejmˇe mus´ı vytvoˇrit ˇcasem, podle krit´eri´ı specifick´ ych pro dan´ y server. V zdrojov´em k´odu ?? je vidˇet pˇr´ıklad odstranˇen´ı bˇeˇzn´eho nepoˇra´dku z /tmp. 1 t i d y { ” /tmp” : 2 r e c u r s e => 1 , # No s u b d i r e c t o r i e s ! 3 backup => f a l s e , # Do n o t c r e a t e b a c k u p s 4 # Usual g a r b a g e f i l e s p a t t e r n 5 matches => [ ” ∗ . gz ” , ” ∗ . bz2 ” , ” ∗ . g i f ” , ” ∗ . s q l ” , ” ∗ . l o g ” , ” ∗ . i c o ” , ” ∗ . i n c ” , ” ∗ . xsd ” , ” ∗. conf ” , ” ∗. txt ” , ” ∗. zip ” ] , 6 age => ” 1m” # Only d e l e t e f i l e s o l d e r than one month 7 }

Listing 3.7: Uk´azka typu tidy Failover lb01 Na obr´azku A.7 je nevybarven´ y server lb02. Vznikl pouze n´ahodou pˇri projektu pov´ yˇsen´ı distribuce na v´ ypoˇcetn´ıch serverech web02 a web03. Bylo zjiˇstˇeno, ˇze dom0 lenny, nem˚ uˇze hostovat domU squeeze. Proto bylo nutn´e pov´ yˇsit i web02-host a web03-host. Na web02host ale bˇeˇz´ı server lb01, kter´ y je nezbytn´ y pro bˇeh produkce jako celku. Proto nebylo moˇzn´e riskovat aktualizaci hardwarov´eho stroje, kter´a v pˇr´ıpadˇe probl´em˚ u mohla ohrozit dostupnost produkce. Proto bylo rozhodnuto, ˇze po dobu aktualizace web02-host bude lb01 pˇresunut na ˇ a migrace bohuˇzel nebyla moˇzn´a. Naˇstˇest´ı ale nem´a bˇeh serveru lb01 vliv web03-host. Ziv´ na jeho stav. Jin´ ymi slovy kopie lb01, jenˇz by nˇejakou dobu nebˇeˇzela dok´aˇze plnˇe nahradit funkci p˚ uvodn´ıho serveru, jeˇz celou dobu bˇeˇzel. Pro porovn´an´ı: Napˇr´ıklad datab´azov´e stroje, ˇci file-servery takovouto vlastnost nemaj´ı. Kopie lb01 tedy byla vytvoˇrena pomoc´ı Logical Volume Manager (LVM) snapshotu. Vytvoˇren´ı snapshotu je d˚ uleˇzit´e, protoˇze jinak by bˇehem p˚ uvodn´ıho stroje mohlo doj´ıt k poˇskozen´ı soubor˚ u na stroji nov´em. Obraz disku byl na druh´ y hostitelsk´ y syst´em pˇrenesen pomoc´ı programu scp a dd. V jednu chv´ıli byly servery ve sv´e funkci vymˇenˇeny. Celkov´a doba v´ ypadku nepˇres´ahla jednu minutu. Praktick´a uk´azka tohoto pˇrenesen´ı je vidˇet na zdrojov´em k´odu 3.8. 1 2 3 4 5 6 7 8 9 10 11 12 13

web02−h o s t : ˜ # s c p / e t c / xen / l b 0 1 web03−h o s t : / e t c / xen / web03−h o s t : ˜ # l v c r e a t e −L 10G −n l b 0 1 r o o t sy s te m web02−h o s t : ˜ # l v c r e a t e −L 10G −s −n l b 0 1 r o o t b a c k u p / dev / s ys t e m / l b 0 1 r o o t web02−h o s t : ˜ # dd i f =/dev / sy s t em / l b 0 1 r o o t b a c k u p b s=4M | pv −s 10 g | s s h web03−h o s t dd o f =/dev / s y st e m / l b 0 1 r o o t b s=4M 2560+0 r e c o r d s out 10737418240 b y t e s ( 1 1 GB) c o p i e d , 4 9 4 . 3 1 1 s , 2 1 . 7 MB/ s 10GB 0 : 0 8 : 1 4 [ 2 0 . 7MB/ s ] [=====================================================>] 100% 0+557755 r e c o r d s i n 0+557755 r e c o r d s out 10737418240 b y t e s ( 1 1 GB) c o p i e d , 4 9 4 . 4 4 7 s , 2 1 . 7 MB/ s # The p r o c e s s t o o k us 8min 12 s web02−h o s t : ˜ # xm shutdown l b 0 1 web03−h o s t : ˜ # xm c r e a t e l b 0 1

Listing 3.8: Uk´azka manu´aln´ı migrace domU pomoc´ı scp a dd. Tato zkuˇsenost n´am vnukla n´apad z´aloˇzn´ıho load-balanceru. Ide´aln´ı ˇreˇsen´ı by bylo v podobˇe hork´e z´alohy, napˇr´ıklad na z´akladˇe bˇeˇz´ıc´ıho stroje a protokolu Common Address Redundancy Protocol (CARP). Tato myˇslenka ale byla mimo rozsah t´eto pr´ace. A proto 40

jsme pouze zadokumentovali, ˇze v pˇr´ıpadˇe selh´an´ı web03-host 8 staˇc´ı zapnout lb01 na web02-host a produkce by mˇela jen s mal´ ym pˇreruˇsen´ım bˇeˇzet d´ale. V tomto hraje velmi d˚ uleˇzitou roli puppet, jenˇz dok´aˇze po zapnut´ı n´ahradn´ıho loadbalanceru automaticky aktualizovat jeho konfigurace. Bez zapojen´ı CMS do procesu konfigurace produkce by takov´ato moˇznost v˚ ubec nevznikla. Distribuce pravidel firewallu Puppet se na produkci star´a o distribuci pravidel firewall˚ u na jednotliv´e servery. Jde o soubor obsahuj´ıc´ı definice, jeˇz dok´aˇze pˇreˇc´ıst program iptables-restore. S komplexn´ımi softwary typu firewall builder m´ame ˇspatn´e zkuˇsenosti. Jejich integrace do syst´emu je pomˇernˇe agresivn´ı a administr´ator m´a velkou ˇsanci, ˇze neopatrn´ ym poˇc´ın´an´ım v gui aplikace nˇeco zniˇc´ı. Proto byl zvolen tento jednoduch´ y, ale funkˇcn´ı princip. Modul puppetu pro apache Nejvˇetˇs´ı a nejv´ıce pouˇz´ıvanou sluˇzbou, kterou puppet na naˇs´ı produkci obsluhuje jsou konfigurace apache jednotliv´ ych v´ ypoˇcetn´ıch server˚ u. Jedn´a se pˇredevˇs´ım o definice virtual host˚ u, kter´e se mˇen´ı relativnˇe ˇcasto. Modul puppetu nese oznaˇcen´ı web-xx. Sekund´arn´ı, mˇenˇe intenzivnˇe vyuˇz´ıvanou souˇc´ast´ı tohoto modulu jsou obecn´e definice apache a Hypertext Preprocessor (PHP) v´ ypoˇcetn´ıch server˚ u. Modul byl navrˇzen pro maxim´aln´ı jednoduchost pˇri pˇrid´av´an´ı nov´ ych virtual host˚ u. V adres´aˇri web-xx/files/apache2/sites-available jsou um´ıstˇeny jednotliv´e soubory virtual host˚ u. Tyto jsou automaticky pˇreneseny na vˇsechny v´ ypoˇcetn´ı servery do /etc/apache2/sitesavailable. Apache je po vzoru distribuce debian nakonfigurov´an, aby automaticky naˇcetl vˇsechny konfigurace z adres´aˇre /etc/apache2/sites-enabled. Nikoliv tedy z adres´aˇre, do kter´eho jsou soubory puppetem um´ıstˇeny. Jejich aktivace je provedena pouˇzit´ım definovan´eho typu 9 . Jin´ ymi slovy po syntakticky spr´avn´em um´ıstˇen´ı n´azvu virtual hostu do web-xx/manifests/vhosts.pp bude dan´ y virtual host aktivov´an. Abych nevynal´ezal znovu kolo“, rozhodl jsem se pro modul obsluhuj´ıc´ı z´akladn´ı bˇeh ” apache pouˇz´ıt jiˇz napsanou knihovnu puppetu. Nejv´ıce vyhovuj´ıc´ı implementaci10 jsem naˇsel od ˇclovˇeka jm´enem Paul Lathrop, kter´ y se v souˇcasn´e dobˇe ˇziv´ı jako konfiguraˇcn´ı 11 manaˇzer . Princip jeho modulu spoˇc´ıv´a v odstranˇen´ı vˇsech specifik, kter´e s sebou jednotliv´e operaˇcn´ı syst´emy pˇrin´aˇs´ı a n´asledn´e konfigurace po vzoru distribuce Debian. Modul web-xx d´ale jako z´avislosti pˇrin´aˇs´ı modul gluster pro adres´aˇre uˇzivatelsk´ ych dat. Doplˇ nkov´e bal´ıˇcky a moduly apache a PHP a jejich konfigurace. Modul postfix pro y je nastaven´ı odes´ıl´an´ı poˇsty v´ ypoˇcetn´ıch server˚ u. Definiˇcn´ı soubor worker cookie, kter´ nezbytn´ y pro spr´avnou pr´aci load balanceru. Jednotliv´e soubory virtual host˚ u jsou obyˇcejn´e, ruˇcnˇe psan´e definice konfigurac´ı apache. Zde by se samozˇrejmˇe nab´ızela moˇznost pouˇzit´ı erb ˇsablon a dynamick´eho generov´an´ı virtual host˚ u, za vyuˇzit´ı spoleˇcn´ ych ˇca´st´ı. Tato moˇznost se n´am nezd´ala pˇr´ıliˇs vhodn´a. Zkompilovan´e virtual hosty by se v pˇr´ıpadˇe krizov´e situace ˇspatnˇe hromadnˇe upravovaly. Nav´ıc zanesen´ı komplexn´ı technologie jakou jsou erb ˇsablony, do tak citliv´ ych konfigurac´ı jak´ ymi jsou virtual hosty, by mohlo m´ıt za n´asledek skryt´e, tˇeˇzko odhaliteln´e chyby. Proto jsme se rozhodli pro pouˇzit´ı technologie mod macro popsan´e v kapitole 2.8. 8

Nov´ y domU pro lb01 Viz defined type“ v slovn´ıku puppetu ” 10 https://github.com/plathrop/puppet-module-apache 11 http://plathrop.tertiusfamily.net/ 9

41

V´ ypoˇ cetn´ı servery a nastaven´ı virtual host˚ u

42

Slovn´ık ”MySQL” MySQL je datab´azov´ y syst´em, vytvoˇren´ y ˇsv´edskou 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´an ” za u ´spˇeˇsn´eho pr˚ ukopn´ıka dvoj´ıho licencov´an´ı – je k dispozici jak pod bezplatnou licenc´ı GPL, tak pod komerˇcn´ı placenou licenc´ı.. 14, 25 ´ ”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´an´ı. V praxi se jedn´a o systematick´e testov´an´ı vˇsech moˇzn´ ych kombinac´ı nebo omezen´e podmnoˇziny vˇsech kombinac´ı.. 15 ”nagios” Nagios je popul´arn´ı open source syst´em pro automatizovan´e sledov´an´ı stavu poˇc´ıtaˇcov´ ych s´ıt´ı a jimi poskytovan´ ych sluˇzeb. Je vyv´ıjen prim´arnˇe pro Linux, ale je moˇzn´e ho provozovat i na jin´ ych unixov´ ych syst´emech. Je vyd´av´an pod GPL licenc´ı. Je vyv´ıjen a udrˇzov´an Ethanem Galstadtem a mnoha dalˇs´ımi v´ yvoj´aˇri plugin˚ u.. 17, 19 ˇ alov´an´ı do ˇs´ıˇrky je obvykle ˇreˇseno pˇrid´an´ım server˚ ”scale out” Sk´ u a rozdistribuov´an´ım z´atˇeˇze mezi tyto jednotliv´e servery. 10 ˇ alov´an´ı do v´ ˇ alov´an´ı pˇri kter´em jsou do serveru pˇrid´any v´ ”scale up” Sk´ yˇsky. Sk´ ypoˇcetn´ı zdroje (CPU, RAM) pro zv´ yˇsen´ı v´ ykonu. 10 ad-hoc Ad hoc [ad h´ok] (nˇekdy Ad-hoc) je latinsk´ y term´ın, znamenaj´ıc´ı doslova k to” muto“, pˇrekl´adan´ y jako za urˇcit´ ym u ´ˇcelem“ nebo pro tento jednotliv´ y (konkr´etn´ı) ” ” pˇr´ıpad“.. 31 apache Apache HTTP Server je softwarov´ y webov´ y server s otevˇren´ ym k´odem pro GNU/Linux, BSD, Solaris, Mac OS X, Microsoft Windows a dalˇs´ı platformy. V souˇcasn´e dobˇe dod´av´a prohl´ıˇzeˇc˚ um na cel´em svˇetˇe vˇetˇsinu internetov´ ych str´anek.. 26, 30, 31 API Application Programming Interface. 23 ARP Address Resolution Protocol (ARP) se v poˇc´ıtaˇcov´ ych s´ıt´ıch s IP protokolem pouˇz´ıv´a k z´ısk´an´ı ethernetov´e MAC adresy sousedn´ıho stroje z jeho IP adresy. Pouˇz´ıv´a se v situaci, kdy je tˇreba odeslat IP datagram na adresu leˇz´ıc´ı ve stejn´e pods´ıti jako odesilatel. Data se tedy maj´ı poslat pˇr´ımo adres´atovi, u nˇehoˇz vˇsak odesilatel zn´a pouze IP adresu. Pro odesl´an´ı prostˇrednictv´ım napˇr. Ethernetu ale potˇrebuje zn´at c´ılovou ethernetovou adresu.. 18 AWS Amazon Web Services. 23 CARP Common Address Redundancy Protocol. 39

43

cli Pˇr´ıkazov´ y ˇr´adek (zkratka CLI, anglicky Command Line Interface) pˇredstavuje uˇzivatelsk´e rozhran´ı, ve kter´em uˇzivatel s programy nebo operaˇcn´ım syst´emem komunikuje zapisov´an´ım pˇr´ıkaz˚ u do pˇr´ıkazov´eho ˇra´dku. Na rozd´ıl od textov´eho rozhran´ı a grafick´eho uˇzivatelsk´eho rozhran´ı nevyuˇz´ıv´a myˇs ani menu a nedovede pracovat s celou plochou obrazovky (termin´alu).. 19, 23 cloud Cloud computing je na Internetu zaloˇzen´ y model v´ yvoje a pouˇz´ıvan´ı poˇc´ıtaˇcov´ ych technologi´ı. Lze ho tak´e charakterizovat jako poskytov´an´ı sluˇzeb ˇci program˚ u uloˇzen´ ych na serverech na Internetu s t´ım, ˇze uˇzivatel´e k nim mohou pˇristupovat napˇr´ıklad pomoc´ı webov´eho prohl´ıˇzeˇce nebo klienta dan´e aplikace a pouˇz´ıvat prakticky odkudkoliv. Uˇzivatel´e neplat´ı (za pˇredpokladu, ˇze je sluˇzba placen´a) za vlastn´ı software, ale za jeho uˇzit´ı. Nab´ıdka aplikac´ı se pohybuje od kancel´aˇrsk´ ych aplikac´ı, pˇres syst´emy pro distribuovan´e v´ ypoˇcty, aˇz po operaˇcn´ı syst´emy provozovan´e v prohl´ıˇzeˇc´ıch, jako je napˇr´ıklad eyeOS, Cloud ˇci iCloud.. 20 CMS Configuration Management Software. 31, 32, 37, 38, 40 CPU Central Processing Unit. 23 cron Cron je softwarov´ y d´emon, kter´ y v operaˇcn´ıch syst´emech automatizovanˇe spouˇst´ı v urˇcit´ y ˇcas nˇejak´ y pˇr´ıkaz resp. proces (skript, program apod.). Jedn´a se vlastnˇe o specializovan´ y syst´emov´ y proces, kter´ y v operaˇcn´ım syst´emu slouˇz´ı jakoˇzto pl´anovaˇc u ´loh, jenˇz umoˇzn ˇuje opakovan´e spouˇstˇen´ı periodicky se opakuj´ıc´ıch proces˚ u (napˇr. noˇcn´ı bˇehy d´avkov´ ych u ´loh pˇri hromadn´em zpracov´an´ı dat) apod.. 19 Debian Debian GNU/Linux je jednou z nejstarˇs´ıch doposud vyv´ıjen´ ych distribuc´ı GNU/Linuxu, kterou nevyv´ıj´ı komerˇcn´ı subjekt, ale je pˇripravov´ana velk´ ym mnoˇzstv´ım dobrovoln´ık˚ u z cel´eho svˇeta. Je zn´ama pˇredevˇs´ım svou konzervativnost´ı. Pˇresto je to jedna z nejrozˇs´ıˇrenˇejˇs´ıch linuxov´ ych distribuc´ı na svˇetˇe.. 32, 33, 35, 40 DNS Domain Name Server. 17, 19, 34 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 ” EC2 Elastic Compute Cloud. 23 failover Schopnost prostˇred´ı bezchybn´eho bˇehu i za situace selh´an´ı nˇekter´ ych server˚ u. 1, 11, 15, 27, 29 FQDN Fully Qualified Domain Name. 34 FUSE Filesystem in userspace. 27 GlusterFS GlusterFS je open source, clusterov´ y souborov´ y syst´em, schopn´ y pojmout data v ˇra´dech petabajt˚ u a obsluhovat tis´ıce klient˚ u. Servery zapojen´e do GlusterFS tvoˇr´ı stavebn´ı bloky pˇres Infiniband RDMA a/nebo TCP/IP propojen´ı. Sd´ıl´ı pˇritom diskov´ y prostor, operaˇcn´ı pamˇet’ pro spr´avu dat v jedin´em glob´aln´ım jmenn´em prostoru. GlusterFS je zaloˇzeno na modul´arn´ım designu v uˇzivatelsk´em prostoru a dok´aˇze pˇrin´est v´ yjimeˇcn´ y v´ ykon pro r˚ uzn´e druhy u ´loh.. 36 GPL GNU General Public License. 32 44

HN Hardware Node. 7–9 hostname Hostname je jm´eno identifikuj´ıc´ı dan´ y server. Pouˇz´ıv´a se v syst´emu DNS, ˇ ejˇs´ı je obr´acen´ kdy IP adrese m˚ uˇze b´ yt pˇridˇelen hostname. Castˇ y pˇr´ıpad, kdy zn´ame hostname a DNS serveru se pt´ame na koresponduj´ıc´ı IP adresu. V tomto pˇr´ıpadˇe jde zejm´ena o zjednoduˇsen´ı, aby si ˇclovˇek nemusel pamatovat IP adresy. V pˇr´ıpadˇe ˇze hostname je ve form´atu host.mydomain.tld, pak hovoˇr´ıme o takzvan´em plnˇe kvalifikovan´em dom´enov´em jm´enu, neboli FQDN.. 34 HTTP Hypertext transfer protocol je dnes nejrozˇs´ıˇrenˇejˇs´ı protokol pro distribuci obsahu webov´ ych str´anek. 2, 10, 11, 18, 25 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´am´ 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´e rozm´ıstˇen´ı z´atˇeˇze na v´ ypoˇcetn´ıch stroj´ıch. 2 LVM Logical Volume Manager. 39 Moore˚ uv z´ akon Sloˇzitost souˇca´stek se kaˇzd´ y rok zdvojn´asob´ı pˇri zachov´an´ı stejn´e ceny http://en.wikipedia.org/wiki/Moore%27s_law. 8 mount Mountov´an´ı“, je v IT pojem pro oznaˇcen´ı procesu pˇripraven´ı diskov´eho odd´ılu ” pro pouˇzit´ı operaˇcn´ım syst´emem. 11 NFS Network File Storage - protokol pro pˇripojov´an´ı s´ıt’ov´ ych disk˚ u. 2, 3, 11, 14, 25–27, 29, 38 NSCA Nagios Service Check Acceptor. 22 NTP Network Time Protocol. 21, 37 OID Object Identifier. 19 open source Software s volnˇe dostupn´ ymi zdrojov´ ymi k´ody. 8 OS Operaˇcn´ı syst´em. 4, 5, 7–10, 17, 35, 38 OSS Open Source Software. 16 overhead Zdroje jeˇz mus´ı b´ yt vyd´any nav´ıc a nesouvis´ı pˇr´ımo s poˇzadovan´ ym c´ılem. 8 packet loss Packet loss je jev pˇri kter´em jeden, nebo v´ıce paket˚ u v poˇc´ıtaˇcov´e s´ıti nedos´ahne sv´eho urˇcen´eho c´ıle.. 17 45

PHP Hypertext Preprocessor. 40 POSIX POSIX (zkratka z Portable Operating System Interface) je pˇrenositeln´e rozhran´ı pro operaˇcn´ı syst´emy, standardizovan´e jako IEEE 1003 a ISO/IEC 9945. Vych´az´ı ze syst´em˚ u UNIX, a urˇcuje, jak maj´ı POSIX-konformn´ı syst´emy vypadat, co maj´ı umˇet, co se jak dˇel´a apod.. 27 ˇ adek, jenˇz je vytiˇstˇen do pˇr´ıkazov´e ˇr´adky po kaˇzd´em ukonˇcen´em pˇr´ıkazu, jenˇz PS1 R´ pˇred´a vol´an´ı zpˇet do shellu.. 37 puppet Puppet je open-source n´astroj pro spr´avu konfigurac´ı. Je naps´an v Ruby a je vyd´av´an pod licenc´ı GPL aˇz do verze 2.7.0. Od t´eto verze d´ale je vyd´av´an pod licenc´ı Apache 2.0.. 32–38, 40 Python Python je dynamick´ y objektovˇe orientovan´ y skriptovac´ı programovac´ı jazyk, kter´ y v roce 1991 navrhl Guido van Rossum. Python je vyv´ıjen jako open source projekt, kter´ y zdarma nab´ız´ı instalaˇcn´ı bal´ıky pro vˇetˇsinu bˇeˇzn´ ych platforem (Unix, Windows, Mac OS); ve vˇetˇsinˇe distribuc´ı syst´emu Linux je Python souˇca´st´ı z´akladn´ı instalace.. 19 RAID Redundant Array of Independent Disks. 12 Rolling updates Aktualizace se uskuteˇcn ˇuje pomoc´ı bal´ıˇckovac´ıho syst´emu pr˚ ubˇeˇznˇe, dennˇe jsou do zdroj˚ u doplˇ nov´any nejnovˇejˇs´ı stabiln´ı verze softwaru. 6 rsync rsync je poˇc´ıtaˇcov´ y program p˚ uvodnˇe pro Unixov´e syst´emy, kter´ y synchronizuje soubory a adres´aˇre mezi r˚ uzn´ ymi m´ısty za pouˇzit´ı co nejmenˇs´ıho pˇrenosu dat. Tam, kde je to moˇzn´e, pˇren´aˇs´ı pouze rozd´ıly mezi soubory (delta).. 28 RTT Round Trip Time. 24, 25 Ruby Ruby je interpretovan´ y skriptovac´ı programovac´ı jazyk. D´ıky sv´e jednoduch´e syntaxi je pomˇernˇe snadn´ y k nauˇcen´ı, pˇresto vˇsak dostateˇcnˇe v´ ykonn´ y, aby dok´azal konkurovat zn´amˇejˇs´ım jazyk˚ um jako je Python a Perl. Je plnˇe objektovˇe orientovan´ y – vˇse v Ruby je objekt.. 32, 35 SNI Server Name Indication. 18 SNMP Simple Network Management Protocol. 19, 21, 37 SPOF Single Point Of Failure. 13, 14 SQL Structured Query Language je standardizovan´ y dotazovac´ı jazyk pouˇz´ıvan´ y pro pr´aci s daty v relaˇcn´ıch datab´az´ıch. 2 SSH Secure Shell. 21 SSL Secure Sockets Layer. 18, 19 svn subversion. 36 trac Trac je open source webov´ y syst´em pro spr´avu projekt˚ u a tiket˚ u. Program je inspirov´an softwarem CVSTrac a byl p˚ uvodnˇe pojmenov´an svntrac kv˚ uli sv´e schopnosti napojen´ı na Subversion. Je vyv´ıjen a udrˇzov´an firmou Edgewall Software.. 19 46

vim Vim je open source textov´ y editor, kter´ y lze spustit v prostˇred´ı vˇetˇsiny operaˇcn´ıch syst´em˚ u. Je obl´ıben´ y zejm´ena mezi zkuˇsen´ ymi uˇzivateli operaˇcn´ıch syst´em˚ u unixov´eho typu. Kromˇe klasick´eho Vimu existuje cel´a ˇrada editor˚ u, kter´e jsou zaloˇzeny na principu Vimu, ale maj´ı nˇejak´e specifick´e vlastnosti napˇr. KVim pro prostˇred´ı KDE.. 37 VPC Virtual Private Cloud. 23, 24 VPN Virtual Private Network. 2, 23 XEN V IT se pod pojmem XEN rozum´ı virtualizaˇcn´ı technologie. 9

47

Literatura [1] Amazon ec2 - api reference. http://awsdocs.s3.amazonaws.com/EC2/latest/ ec2-api.pdf, 2011. [Online; pˇr´ıstupn´e 10.04.2011]. [2] Amazon ec2 - command line reference. http://awsdocs.s3.amazonaws.com/EC2/ latest/ec2-clt.pdf, 2011. [Online; pˇr´ıstupn´e 10.04.2011]. [3] Amazon elastic compute cloud - user guide. http://awsdocs.s3.amazonaws.com/ EC2/latest/ec2-ug.pdf, 2011. [Online; pˇr´ıstupn´e 10.04.2011]. [4] Cfengine AS. cfengine users. http://www.cfengine.com/pages/companies, 2011. [Online; pˇr´ıstupn´e 12.04.2011]. [5] James Britt and Neurogam. Erb — ruby templating. http://ruby-doc.org/ stdlib/libdoc/erb/rdoc/classes/ERB.html, 2011. [Online; pˇr´ıstupn´e 17.04.2011]. [6] Fabien Coelho. Apache 2.2 module mod macro 1.1.11. http://www.cri.ensmp.fr/ ~coelho/mod_macro/, 2010. [Online; pˇr´ıstupn´e 20.04.2011]. [7] GlusterFS community. Gluster 3.1: Understanding replication. http: //www.gluster.com/community/documentation/index.php/Gluster_3.1: _Understanding_Replication, 2010. [Online; pˇr´ıstupn´e 11.04.2011]. [8] GlusterFS community. Glusterfs 3.1 documentation. http://gluster.com/ community/documentation/index.php/Gluster_3.1:_Introducing_GlusterFS, 2010. [Online; pˇr´ıstupn´e 11.04.2011]. [9] 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´e 12.12.2010]. [10] 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´e 22.3.2011]. [11] The Apache Software Foundation. Ssl/tls strong encryption: Faq. l, 2011. [Online; pˇr´ıstupn´e 29.3.2011]. [12] John from Bitfield Consulting. Puppet versus chef: 10 reasons why puppet wins. http://bitfieldconsulting.com/puppet-vs-chef, 2010. [Online; pˇr´ıstupn´e 13.04.2011]. [13] Digant C Kasundra. Puppet best practices 2.0. http://projects.puppetlabs. com/projects/puppet/wiki/Puppet_Best_Practice, 2010. [Online; pˇr´ıstupn´e 15.04.2011].

48

[14] Kirill Kolyshkin. Virtualization in Linux. http://download.openvz.org/doc/ openvz-intro.pdf, 2006. [Online; pˇr´ıstupn´e 9.2.2011]. [15] Puppet Labs. Docs: Troubleshooting. http://docs.puppetlabs.com/guides/ troubleshooting.html#common-misconceptions, 2011. [Online; pˇr´ıstupn´e 19.04.2011]. [16] Puppet Labs. Docs: Using puppet templates. http://docs.puppetlabs.com/ guides/templating.html, 2011. [Online; pˇr´ıstupn´e 17.04.2011]. [17] Puppet Labs. Glossary of terms. http://projects.puppetlabs.com/projects/ puppet/wiki/Glossary_Of_Terms, 2011. [Online; pˇr´ıstupn´e 17.04.2011]. [18] 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´e 20.3.2011]. [19] Microsoft. Compare Windows to Red Hat. http://www.microsoft.com/ windowsserver/compare/windows-server-vs-red-hat-linux.mspx, 2003. [Online; pˇr´ıstupn´e 13.12.2010]. [20] VMware, Inc. A Performance Comparison of Hypervisors . http://www.cc.iitd. ernet.in/misc/cloud/hypervisor_performance.pdf, 2007. [Online; pˇr´ıstupn´e 10.1.2011]. [21] Wikipedia. Failover. http://en.wikipedia.org/wiki/Failover, 2011. [Online; pˇr´ıstupn´e 22.2.2011]. [22] Wikipedia. Gaussova funkce. http://cs.wikipedia.org/wiki/Gaussova_funkce, 2011. [Online; pˇr´ıstupn´e 11.04.2011]. [23] Wikipedia. Kernel-based Virtual Machine. http://en.wikipedia.org/wiki/ Kernel-based_Virtual_Machine, 2011. [Online; pˇr´ıstupn´e 2.2.2011]. [24] Wikipedia. Network file system. http://cs.wikipedia.org/wiki/Network_File_ System, 2011. [Online; pˇr´ıstupn´e 27.3.2011]. [25] Wikipedia. RAID. http://cs.wikipedia.org/wiki/RAID#RAID_1_.28zrcadlen. C3.AD.29, 2011. [Online; pˇr´ıstupn´e 20.3.2011]. [26] Wikipedia. Soubˇeh. http://cs.wikipedia.org/wiki/Soub%C4%9Bh, 2011. [Online; pˇr´ıstupn´e 05.04.2011]. [27] Wikipedie. Round-trip delay time. http://en.wikipedia.org/wiki/Round-trip_ delay_time, 2011. [Online; pˇr´ıstupn´e 11.04.2011]. [28] 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´e 13.12.2010].

49

Pˇ r´ıloha A Obr´ azky

50

Obr´azek A.1: P˚ uvodn´ı produkce s vyznaˇcen´ ymi verzemi Operaˇcn´ıch Syst´em˚ u

51

Obr´azek A.2: Sch´ema zpracov´an´ı HTTP/HTTPS poˇzadavku

52

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

53

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

54

Obr´azek A.5: Napojen´ı technologie Amazon VPC

55

Obr´azek A.6: Fungov´an´ı load-balanceru pˇri pouˇzit´ı z´on

56

Obr´azek A.7: V´ ysledn´e sch´ema produkce

57

Obr´azek A.8: Vyt´ıˇzen´ı serveru (nagios + cacti)

Obr´azek A.9: Vyt´ıˇzen´ı serveru (pouze nagios)

Obr´azek A.10: Rozloˇzen´ı n´avˇstˇevnosti v jednom dni

58

Obr´azek A.11: Rozloˇzen´ı n´avˇstˇevnosti v jednotliv´ ych dnech mˇes´ıce

59

Obr´azek A.12: Graf z´avislost´ı puppetu pro vytvoˇren´ı GlusterFS mount˚ u

60

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 39 40 41 42 43 44 45 46 47 48 49 50

IP SNMP scanner

#! / u s r / b i n / py t h on import os , s y s , 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 = ’ / v a r / 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] = i n t e r f a c e n a m e 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 : 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” )

61

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 b e t t e r 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 ( )

51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73

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

74 75 76 77 78 79 80 81 82 83 84 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

B.2

site.pp

1 F i l e { i g n o r e => [ ’ . svn ’ , ’ . g i t ’ ] } # Do n o t b o t h e r w i t h t h o s e f i l e n a m e p a t t e r n s when s o l v i n g e n s u r e=>d i r e c t o r y , r e c u r s e=>t r u e 2 Exec { path => ” / u s r / b i n : / u s r / s b i n / : / b i n : / s b i n ” } # This s e t s t h e p a t h v a r i a b l e g l o b a l l y . No more p a t h d e f i n i t i o n s i n c l a s s e s / nodes 3 4 e x e c { ” apt−g e t update ” : # Update p a c k a g e s l i s t 5 a l i a s => ” a p t g e t u p d a t e ” , 6 r e f r e s h o n l y => true ; 7 } 8 9 case $ o p e r a t i n g s y s t e m { # S p e c i a l s e t t i n g s f o r d i f f e r e n t d i s t r i b u t i o n s 10 OpenSuSE : { 11 Package { p r o v i d e r => yum } 12 13 case $ o p e r a t i n g s y s t e m r e l e a s e { # S p e c i a l s e t t i n g s f o r d i f f e r e n t d i s t r i b u t i o n releases 14 ” 10.3 ” : { 15 yumrepo { 16 ” puppet repo ” : 17 descr => ” puppet r e p o s i t o r y f o r SLE 10 ” , 18 e n a b l e d => 1 ,

62

19

b a s e u r l => ” h t t p : / / download . o p e n s u s e . o r g / r e p o s i t o r i e s / system : / management/ SLE 10 / ” ; # p u p p e t d 0 . 2 5 . 5 ” paderborn 10 3 ” : descr => ” paderborn−openSUSE −10.3 ” , e n a b l e d => 1 , b a s e u r l => ” f t p : / / f t p . uni−p a d e r b o r n . de /pub/ l i n u x / o p e n s u s e / d i s t r i b u t i o n /10.3/ repo / oss / suse /” ;

20 21 22 23

} } ” 11.0 ” : { yumrepo { ” puppet repo ” : descr => ” puppet r e p o s i t o r y f o r openSUSE 11 . 1 ” , b a s e u r l => ” h t t p : / / download . o p e n s u s e . o r g / r e p o s i t o r i e s / system : / management/ SLE 11 / ” , e n a b l e d => 1 , gpgcheck => 0 ; ” base ” : descr => ”OpenSuSE 1 1 . 1 ” , b a s e u r l => ” h t t p : / / download . o p e n s u s e . o r g / d i s t r i b u t i o n / 1 1 . 1 / r e p o / o s s / s u s e / ” , # p u p p e t d 0 . 2 5 . 4 ( and many o t h e r p a c k a g e s ) e n a b l e d => 1 , gpgcheck => 0 ; ” updates ” : descr => ”OpenSuSE 1 1 . 1 u p d a t e s ” , b a s e u r l => ” h t t p : / / download . o p e n s u s e . o r g / update / 1 1 . 1 / ” , e n a b l e d => 1 , gpgcheck => 0 ; } }

24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54

} } } $ p u p p e t i z e d f i l e=” /tmp/ p u p p e t i z e d $ { o p e r a t i n g s y s t e m } $ { o p e r a t i n g s y s t e m r e l e a s e } ” f i l e { $ p u p p e t i z e d f i l e : # This i s j u s t a way t o mark s e r v e r s as p u p p e t i z e d ensure => p r e s e n t } i mpo rt ” nodes ” # Get node d e f i n i t i o n s

Listing B.2: site.pp

63

Pˇ r´ıloha C Ostatn´ı C.1

Slovn´ık pojm˚ u jazyka puppet (anglicky)

As developers have found time and time again, terminology is critical to successful projects. The Puppet community has begun to coalesce around certain terms found to be useful in working with Puppet: catalog A catalog is the totality of resources, files, properties, etc, for a given system. class A native Puppet construct that defines a container of resources, such as File resources, Package resources, User resources, custom-defined resources (see also defined type), etc. A class can inherit from another class using the inherits keyword, and can also declare other classes. agent or agent node An operating system instance managed by Puppet. This can be an operating system running on its own hardware or a virtual image. declare (v.) To state that a class or a resource should be included in a given configuration. Classes are declared with the include keyword or with the class ”foo”: syntax; resources are declared with the lowercase file ”/tmp/bar”: syntax. define (v.) To specify the contents and behavior of a class or defined resource type. defined resource type or defined type (older usage: definition) A Puppet resource type defined at the application level. Defined types are created in the Puppet language and are analogous to macros in some other languages. Contrast with native type. fact A detail or property returned by Facter. Facter has many built-in details that it reports about the machine it runs on, such as hostname. Additional facts can easily be returned by Facter (see Adding Facts). Facts are exposed to your Puppet manifests as global variables. manifest A configuration file written in the Puppet language. These files should have the .pp extension. module A collection of classes, resource types, files, and templates, organized around a particular purpose. See also Module Organisation. native type A type written purely in Ruby and distributed with Puppet. Puppet can be extended with additional native types, which can be distributed to agent nodes via the pluginsync system. See the documentation for list of native types. 64

node (general noun) An individual server; for the purposes of discussing Puppet, this generally refers to an agent node. node (Puppet language keyword) A collection of classes and/or resources to be applied to the agent node whose unique identifier (“certname”) matches the specified node name. Nodes defined in manifests allow inheritance, although this should be used with care due to the behavior of dynamic variable scoping. parameter (custom type and provider development) A value which does not call a method on a provider. Eventually exposed as an attribute in instances of this resource type. See Custom Types. parameter (defined types and parameterized classes) One of the values which can be passed to this class or instances of this resource type upon declaration. Parameters are exposed as resource or class attributes. parameter (external nodes) A global variable returned by the external node classifier. pattern colloquial community expression for a collection of manifests designed to solve an issue or manage a particular configuration item, for example an Apache pattern. plugin, plugin types a Puppet term for custom types created for Puppet at the Ruby level. These types are written entirely in Ruby and must correspond to the Puppet standards for custom-types. plusignment operator An operator that allows you to add values to resource parameters using the +¿ (‘plusignment’) syntax. Available since version 0.23.1: property (custom type and provider development) A value which calls a method on a provider. Eventually exposed as an attribute in instances of this resource type. See Custom Types. provider A simple implementation of a type; examples of package providers are dpkg and rpm, and examples of user providers are useradd and netinfo. Most often, providers are just Ruby wrappers around shell commands, and they are usually very short and thus easy to create. realize a Puppet term meaning to declare a virtual resource should be part of a system’s catalog. See also virtual resources. resource an instantiation of a native type, plugin type, or definition such as a user, file, or package. Resources do not always directly map to simple details on the client — they might sometimes involve spreading information across multiple files, or even involve modifying devices. resource object A Puppet object in memory meant to manage a resource on disk. Resource specifications get converted to these, and then they are used to perform any necessary work. resource specification The details of how to manage a resource as specified in Puppet code. When speaking about resources, it is sometimes important to differentiate between the literal resource on disk and the specification for how to manage that resource; most often, these are just referred to as resources.

65

subclass a class that inherits from another class. Subclasses are useful for expanding one logical group of resources into another similar or related group of resources. Subclasses are also useful to override values of resources. For instance, a base class might specify a particular file as the source of a configuration file to be placed on the server, but a subclass might override that source file parameter to specify an alternate file to be used. A subclass is created by using the keyword inherits: templates templates are ERB files used to generate configuration files for systems and are used in cases where the configuration file is not static but only requires minor changes based on variables that Puppet can provide (such as hostname). See also distributable file. template class template classes define commonly used server types which individual nodes inherit. A well designed Puppet implementation would likely define a baseclass, which includes only the most basic of modules required on all servers at the organization. One might also have a genericwebserver template, which would include modules for apache and locally manageable apache configurations for web administrators. Template classes can take parameters by setting them in the node or main scope. This has the advantage, that the values are already available, regardless of the number of times and places where a class is included: This structure maps directly to a external node classifier and thus enables a easy transition. type abstract description of a type of resource. Can be implemented as a native type, plug-in type, or defined type. variable variables in Puppet are similar to variables in other programming languages. Once assigned, variables cannot be reassigned within the same scope. However, within a sub-scope a new assignment can be made for a variable name for that sub-scope and any further scopes created within it: virtual resource a Puppet term for an resource that is defined but will not be made part of a system’s catalog unless it is explicitly realized. See also realize. 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21

c l a s s apache { s e r v i c e { ” apache ” : r e q u i r e => Package [ ” httpd ” ] } } c l a s s apache− s s l i n h e r i t s apache { # h o s t c e r t i f i c a t e i s r e q u i r e d f o r SSL t o f u n c t i o n S e r v i c e [ apache ] { r e q u i r e +> F i l e [ ” apache . pem ” ] } } node mywebserver { include genericwebserver } node mywebserver { $web fqdn = ’www. example . com ’ include singledomainwebserver } c l a s s ClassB i n h e r i t s ClassA { . . . } $myvariable = ” something ”

Note that there are certain seemingly built-in variables, such as $hostname. These variables are actually created by Facter. Any fact presented by Facter is automatically available as a variable for use in Puppet. 66