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.2: Uk´azka vol´an´ı NSCA z PHP 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.3: 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 ” 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.

22

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 velkou9 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´ ykon10 a neˇreˇs´ı serverovou infrastrukturu, kabel´aˇz a dokonce ani virtualizaci serveru pro pˇrerozdˇelen´ı v´ ykonu. D´ıky elasticitˇe cloudov´ ych technologi´ı je 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 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. Technologie umoˇzn ˇuj´ıc´ı jednoduˇse nafouknout“ kter´ ykoliv ze server˚ u by n´am tedy 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ˇe 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 ˇra´dky. 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 nejˇcastˇeji myˇsleno v´ ykonnostn´ı pokryt´ı ˇ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[24], 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. 9 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. 10 Obvykle ud´ avan´ y jako v´ ykon Central Processing Unit (CPU) a mnoˇzstv´ı RAM.

23

Obr´azek 2.3: Technologie VPC

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, nebo 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 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ˇsi infrastrukturu je vidˇet na obr´azku A.5. V´ yhoda vyuˇzit´ı t´eto technologie m´ısto 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 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 [29]. 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 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 24

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´ı11 , 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 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´a rozhran´ı. Prvn´ı o rychlosti 100 Mbit 12 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 13 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. 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 nen´ı ˇza´douc´ı 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 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. 11

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

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´ı velk´a 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 loadbalanceru toto nen´ı 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 ve zdrojov´em k´odu 2.4 a 2.5. 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.4: /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.5: /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.6. 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.6: 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 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. • Vzrostla by komplikovanost produkce. Bylo by nutn´e pˇredˇelat logiku dlouho bˇeˇz´ıc´ıch u ´loh 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 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 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 ˇza´dn´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: 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 [8]. 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) nen´ı probl´em. • Web v´ yvoj´aˇr˚ u nab´ız´ı jak deb, tak rpm bal´ıˇcky14 . • GlusterFS pˇredpokl´ad´a pouze POSIX souborov´ y syst´em. Na jeho konkr´etn´ı implementaci uˇz nez´aleˇz´ı. Je moˇzn´e pouˇz´ıvat na jednom serveru 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´ y15 . • 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. • 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. 14 15

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) Za 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 ud´av´a potˇrebu kontrolovat aktu´alnost ” soubor˚ u na vˇsech brick pˇri urˇcit´em typu souborov´ ych operac´ı“ [7]. 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 tomu zv´ yˇs´ıme odezvu v druh´e z´onˇ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 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ˇca´teˇ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 soubory16 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. 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 16 ˇ

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

28

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. Nejdˇr´ıve bude provedena u ´pln´a rozd´ılov´a synchronizace. V tuto chv´ıli bude produkce st´ale bˇeˇzet. 2. Pozdˇeji 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 ve zdrojov´em k´odu 2.7. 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.7: 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 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 29

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 2.5.1

Failover datab´ az´ı Probl´ em

Kaˇzd´ y server m˚ uˇze selhat. M˚ uˇze se jednat o selh´an´ı disku, ˇspatn´e nastaven´ı serveru, selh´an´ı s´ıt’ov´e konektivity, v´ ypadek proudu, jin´e selh´an´ı hardwaru serveru, softwarov´e poˇskozen´ı dat na disku, atp. . . Moˇznost´ı je mnoho. Je proto dobr´e vˇzdy myslet na z´aloˇzn´ı ˇreˇsen´ı pro pˇr´ıpad v´ ypadku serveru. Pomˇernˇe speci´aln´ım pˇr´ıpadem je failover v pˇr´ıpadˇe datab´azov´eho serveru.

2.5.2

ˇ sen´ı Reˇ

Z´alohu datab´azov´eho serveru pro pˇr´ıpad jeho nenad´al´eho selh´an´ı jsme se rozhodli ˇreˇsit ”MySQL” master - slave replikac´ı. Novˇe vznikl´ y datab´azov´ y stroj db04 je replikov´an na db04-slave. D´ıky n´ızk´e n´aroˇcnosti replikac´ı jsme si mohli dovolit z´alohovac´ı stroje virtualizovat. Server db04-slave bˇeˇz´ı na slave01-host, jak je vidˇet na obr´azku A.7. T´ımto firma ˇsetˇr´ı n´aklady. Tento pˇr´ıpad je pˇresnˇe ten, ve kter´em je spr´avn´e a v´yhodn´e pouˇz´ıt virtualizaci server˚ u. D´ıky principu replikac´ı v softwaru ”MySQL” nevad´ı, pokud z´alohovac´ı server na nˇejakou dobu vypadne. V pˇr´ıpadˇe, ˇze by master server (db04 ) byl nen´avratnˇe poˇskozen, je moˇzn´e pouh´ ym nastaven´ım hostname na DNS serveru a vypnut´ım replikac´ı na z´alohovac´ım serveru produkci opˇet plnˇe zprovoznit.

2.5.3

Z´ avˇ er

N´ami zvolen´e ˇreˇsen´ı dle standardn´ıch definic failoveru vlastnˇe failoverem v˚ ubec nen´ı. Nˇekter´e u ´kony mus´ı b´ yt provedeny manu´alnˇe. Nicm´enˇe dod´av´a cel´e produkci stabilitu a moˇznost rychl´eho zotaven´ı v pˇr´ıpadˇe nouze. Tato ˇca´st zlepˇsov´an´ı produkˇcn´ı infrastruktury je st´ale jeˇstˇe v rozvoji.

2.6 2.6.1

Memcached Probl´ em

Na naˇs´ı produkci existuj´ı urˇcit´a data, kter´a jsou velmi ˇcasto ˇctena v´ ypoˇcetn´ımi servery a mus´ı b´ yt pro vˇsechny v´ ypoˇcetn´ı servery stejn´a. Tato data mus´ı b´ yt jednou za ˇcas hromadnˇe, ve skupin´ach, invalidov´ana. Tato data mohou b´ yt smaz´ana, aniˇz by doˇslo k nˇejak´emu v´aˇzn´emu probl´emu. P˚ uvodn´ı pˇr´ıstup byl ukl´adat tato data na NFS. NFS sv´ ym principem vyhovovalo vˇsem v´ yˇse uveden´ ym podm´ınk´am. Tento pˇr´ıstup ale mˇel jist´e nev´ yhody. Pˇr´ıstup na NFS nen´ı v naˇsem prostˇred´ı dostateˇcnˇe rychl´ y. V pˇr´ıpadˇe ˇspatnˇe zvolen´e struktury se v jednom adres´aˇri mohlo vyskytnout statis´ıce soubor˚ u. Pˇr´ıstup k takov´emu adres´aˇri pˇres NFS je pak jeˇstˇe mnohem pomalejˇs´ı. Hromadn´a invalidace z´aznam˚ u tak´e nen´ı nejjednoduˇsˇs´ı.

30

2.6.2

ˇ sen´ı Reˇ

Pro ˇreˇsen´ı tohoto projektu jsme se rozhodli nainstalovat sd´ılen´ y memcached server, jeˇz by vyuˇz´ıvali vˇsechny v´ ypoˇcetn´ı servery. Software memcached je autory projektu popisov´an jako: Zdarma a open-source, vysoce v´ ykonn´ y, distribuovan´ y keˇsovac´ı syst´em, jeˇz je naprosto obecn´ y, vyv´ıjen´ y pro pouˇzit´ı k zrychlen´ı dynamick´ ych webov´ ych aplikac´ı zm´ırˇ nov´an´ım datab´azov´e z´atˇeˇze. Memcached je pamˇet’ov´e u ´loˇziˇstˇe hodnot typu kl´ıˇc-hodnota pro ukl´ad´an´ı mal´ ych, obecn´ ych dat (ˇretˇezce, objekty). Prim´arnˇe urˇcen´e pro v´ ysledky datab´azov´ ych vol´an´ı, vol´an´ı API ˇci cel´ ych webov´ ych str´anek [10]. Memcached m´a implementovan´e API ve velk´em mnoˇzstv´ı jazyk˚ u a je podporov´an jako modul velkou mnoˇzinou softwaru. Jedn´ım z m´ıst, kde lze memcached s v´ yhodou pouˇz´ıt jsou session. Session je u ´loˇziˇstˇe informac´ı o uˇzivateli, jenˇz se vztahuje k dan´emu sezen´ı (pˇrihl´aˇsen´ı). Tyto informace z d˚ uvod˚ u failoveru mus´ı b´ yt k dispozici na vˇsech v´ ypoˇcetn´ıch serverech. Souˇcasnˇe jsou potˇreba pˇri kaˇzd´em naˇcten´ı webov´e str´anky. Software PHP m´a zabudovanou podporu pro ukl´ad´an´ı session na memcached server. Staˇc´ı pouze pozmˇenit konfiguraci Hypertext Preprocessor (PHP) tak, jak je vidˇet na zdrojov´em k´odu 2.8 1 s e s s i o n . s a v e h a n d l e r = memcache 2 s e s s i o n . save path = ” tcp : / / 1 0 . 0 . 0 . 1 4 : 1 1 2 1 1 ”

Listing 2.8: Nastaven´ı PHP pro ukl´ad´an´ı session na memcached server Dalˇs´ım m´ıstem, kde se v naˇs´ı aplikaci nech´a memcached pouˇz´ıt jsou z´akaznick´e konfigurace. Aplikace pˇred spuˇstˇen´ım vlastn´ıho k´odu str´anky, mus´ı zjistit jak´eho z´akazn´ıka obsluhuje a naˇc´ıst si vˇsechny jeho konfiguraˇcn´ı soubory. Konfiguraˇcn´ı soubory aplikace potˇrebuje pˇri kaˇzd´em sv´em bˇehu. Implementaci ukl´ad´an´ı uˇzivatelsk´ ych konfigurac´ı do memcached zde prob´ırat nebudu. Zaj´ımav´a je ale discipl´ına hromadn´e invalidace dat. Data uloˇzen´a do memcached nesm´ı b´ yt povaˇzov´ana za trval´a. Proto aplikace funguje tak, ˇze se nejprve pod´ıv´a do memcached, zda obsahuje z´aznam o nastaven´ı uˇzivatel˚ u. Pokud ho nenalezne, pak si pˇr´ısluˇsn´a data naˇcte ze sd´ılen´eho diskov´eho prostoru (NFS) a n´aslednˇe uloˇz´ı tato data do memcached. Pˇri pˇr´ıˇst´ım bˇehu jsou tak data jiˇz k dispozici v rychl´em u ´loˇziˇsti. Probl´em ale nast´av´a ve chv´ıli, kdy chceme data v memcached invalidovat. Tento software nenab´ız´ı moˇznost pr´ace pˇres z´astupn´e znaky. Museli bychom tedy ruˇcnˇe definovat sadu dat, jeˇz se m´a invalidovat. To nen´ı hezk´e ˇreˇsen´ı. Ofici´alnˇe doporuˇcovan´ y postup v takov´eto situaci je pˇredˇradit pˇred kaˇzd´ y kl´ıˇc nˇejak´ y identifik´ator. Napˇr´ıklad, y kl´ıˇc bude pokud by p˚ uvodn´ı kl´ıˇc byl uzivatel a a identifik´atr 1234, pak re´alnˇe pouˇzit´ 1234 uzivatel a. Dokud bude identifik´ator stejn´ y, budou naˇc´ıt´ana stejn´a data. Ve chv´ıli, kdy se identifik´ator zmˇen´ı, nebudou ˇz´adn´a data naˇctena a aplikace uloˇz´ı do memcached data nov´a. Tento identifik´ator ukl´ad´ame na NFS a v pˇr´ıpadˇe potˇreby ho um´ıme zmˇenit. Pro zajiˇstˇen´ı unik´atnosti identifik´atoru jsme pouˇzili ˇc´ıslo revize v subversion (svn). Soubory uˇzivatelsk´eho nastaven´ı se na produkci dost´avaj´ı pouze pˇres svn. Je tedy jasnˇe dan´e, ˇze revize z svn dostateˇcnˇe jedineˇcnˇe urˇcuje n´ami poˇzadovan´ y identifik´ator.

2.6.3

Z´ avˇ er

Prozat´ım se n´am podaˇrilo u ´spˇeˇsnˇe implementovat ukl´ad´an´ı session a z´akaznick´ ych nastaven´ı na memcached server. Odhadovan´e zrychlen´ı odezvy syst´emu jako celku nepˇres´ahlo 5%. Coˇz nen´ı mnoho. Tento projekt pˇresto pˇrinesl velmi zaj´ımav´ y v´ ystup. A to zamˇeˇren´ı 31

pozornosti na technologii memcached a jej´ı propojen´ı v n´ami pouˇz´ıvan´em PHP frameworku.

2.7 2.7.1

chat01 Probl´ em

Aplikace port´alu obsahuje modul pro Instant messaging (IM). Uˇzivatel´e si mohou zaloˇzit diskusn´ı m´ıstnosti a v re´aln´em ˇcase zde komunikovat. Pro zjiˇst’ov´an´ı existence nov´ ych zpr´av uˇzivatele je pouˇzito periodick´e pos´ıl´an´ı Asynchronous JavaScript and XML (AJAX) dotaz˚ u na server. Pˇri bliˇzˇs´ım prozkoum´an´ı jsme zjistili, ˇze tento typ poˇzadavk˚ u tvoˇr´ı pˇribliˇznˇe 70% z celkov´eho poˇctu dotaz˚ u. Nepodaˇrilo se n´am pˇredem zjistit, jak velkou ˇc´ast z´atˇeˇze m´a tento typ poˇzadavk˚ u na svˇedom´ı. V´ ypoˇcty v takto komplikovan´em prostˇred´ı neb´ yvaj´ı moc spolehliv´e.

2.7.2

ˇ sen´ı Reˇ

M´ısto odhadov´an´ı z´atˇeˇze, bylo rozhodnuto, o proveden´ı experimentu jeˇz mˇel odklonit tento typ poˇzadavk˚ u mimo produkci. D˚ uleˇzit´ ymi body v tomto projektu jsou: • Pro cel´ y syst´em kontroly nov´ ych zpr´av byl vyhrazen vlastn´ı server. Nazv´an byl chat01 a lze ho vidˇet na obr´azku A.7. • P˚ uvodn´ı dotaz ˇsel pˇres lb01 na nˇekter´ y z v´ ypoˇcetn´ıch server˚ u. Nyn´ı tedy nebudou zatˇeˇzov´any ani v´ ypoˇcetn´ı servery a ani load balancer. Dotazy jdou pˇr´ımo na server chat01. • Pro co nejvˇetˇs´ı separaci chat01 od zbytku produkce bylo nutn´e vymyslet postup kontroly nov´ ych zpr´av, jenˇz by nevyˇzadoval pˇr´ıstup do datab´aze. Detaily implementace zde rozeb´ırat nebudu.

2.7.3

Z´ avˇ er

D´ıky nasazen´ı serveru chat01 se sn´ıˇzila z´atˇeˇz server˚ u pˇri ˇspiˇcce o pˇribliˇznˇe 30%. Coˇz je dle m´eho n´azoru vynikaj´ıc´ı v´ ysledek. Abych nezkresloval v´ ysledky vlastn´ım v´ ykladem, mus´ım poznamenat, ˇze tento projekt nemˇel ˇz´adn´y, nebo jen minim´aln´ı vliv na pr˚ umˇernou dobu odezvy mimo ˇspiˇcku. Lze tedy ˇr´ıci, ˇze se n´am podaˇrilo stabilizovat pr˚ umˇernou dobu odezvy aplikace tak, aby byla m´enˇe n´achyln´a na poˇcet aktu´alnˇe pˇripojen´ ych uˇzivatel˚ u.

2.8 2.8.1

Zjednoduˇ sen´ı definic virtual host˚ u Probl´ em

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.

32

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

Listing 2.9: mod macro

2.8.2

ˇ sen´ı Reˇ

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 opakov´an´ı. Pouˇzili jsme proto modul apache mod macro, kter´ y jak jiˇz n´azev napov´ıd´a, 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: ... 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!) [6]

33

Uk´azka pouˇzit´ı mod macro je vidˇet na zdrojov´em k´odu 2.9. 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. Modul mod macro um´ı pouze jednu vˇec. Administr´ator si nadefinuje takzvan´a makra, jeˇz jsou uzavˇrena v p´arov´em tagu <Macro>. Otev´ırac´ı tag m˚ uˇze pˇreb´ırat parametry. Obsah tˇechto maker je pak pˇredloˇzen programu apache vˇzdy, kdyˇz je makro zavol´ano pomoc´ı pˇr´ıkazu Use. Pˇr´ıpadn´e parametry foo a bar se pak objev´ı v tˇele makra jako $par a, resp. $par b. Tˇelo makra m˚ uˇze obsahovat jin´e makro.

2.8.3

Z´ avˇ er

u na desetinu. • D´ıky modulu mod macro jsme dok´azali sn´ıˇzit poˇcet ˇr´adek virtual host˚ Modul jeˇstˇe nen´ı pouˇzit na vˇsech m´ıstech, kde by to bylo moˇzn´e. Pˇredpokl´ad´ame, ˇze se m˚ uˇzeme dostat aˇz na 5% p˚ uvodn´ı d´elky definic virtual host˚ u. • Velmi se zlepˇsila pˇrehlednost konfiguraˇcn´ıch soubor˚ u. • D´ıky jednoduchosti pouˇzit´ı mod macro je mnohem menˇs´ı prostor pro chyby v definic´ıch virtual host˚ u. • Nasazen´ı t´eto technologie umoˇznilo zapoˇcet´ı refactoringu virtual host˚ u. D´ıky tomu, ˇze jsou definice uvedeny pouze jednou, bez opakov´an´ı, je moˇzn´e snadno dˇelat u ´pravy v aplikaci, kter´e vyˇzaduj´ı glob´aln´ı zmˇeny virtual host˚ u.

34

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 aktualizov´any. 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 neˇz 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).

35

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´ı se v oboru konfiguraˇcn´ıho managementu pouvaˇzuj´ı za nev´ yhodu [13]. 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 nen´ı podepˇren 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 na zpˇetn´em pohledu 36

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 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 [19]. 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´ı stroj, 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 ˇz´adaj´ı ho o svou konfiguraci. Tato situace je zn´azornˇena na obr´azku 3.1. Dotazov´an´ı je zajiˇstˇeno spuˇstˇen´ ym d´emonem na kaˇzd´em klientovi. Obdobn´ y d´emon bˇeˇz´ı i na serveru a komple” tuje“ konfigurace 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 jednoduch´a. V distribuci Debian staˇc´ı pˇres bal´ıˇckovac´ı syst´em nainstalovat bal´ıˇcek puppet - na klientsk´ ych stroj´ıch ˇ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ˇz´adat 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 37

Obr´azek 3.1: Model klient-server softwaru puppet

Obr´azek 3.2: Kompletace manifest˚ u puppet masterem

38

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 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 a vytvoˇr´ı z nich katalog3 . Pˇr´ıruˇcka Puppet best practices 2.0 [14] 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 ve 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 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 3.3 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 [17] 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. 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. . . 3 Postup je re´ alnˇe daleko sloˇzitˇejˇs´ı. 4 Samozˇrejmˇe situace nen´ı tak jednoduch´a a urˇcit´e probl´emy d´ıky r˚ uzn´ ym distribuc´ım z˚ ustanou. 2

39

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 [18]. 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 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 takov´ y ˇze pˇri pˇrenesen´ı jeho adres´aˇre na jin´e prostˇred´ı, je tento modul schopen fungovat. Jedn´a se tedy o jakousi organizaˇcn´ı jednotku ve struktuˇre puppetu. Uzavˇren´ y celek, jenˇz obstar´av´a nˇejakou funkcionalitu. Modul m˚ uˇze m´ıst z´avislosti na jin´e moduly. 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 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/postcommit 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 40

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 5 6 nastaven´ı PS1 , rozd´ıln´e nastaven´ı doplˇ nov´an´ı tabul´atoru, r˚ uzn´e chov´an´ı editoru vim , 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ˇc´ateˇ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 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˚ uvodu 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. 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.

41

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. K´od se l´epe 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 bylo velmi nepraktick´e, proto jsem nejprve pˇredpokl´adal, ˇze vytvoˇr´ım obecn´ y node a od nˇeho pot´e oddˇ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 [16]. Promˇenn´a, nastaven´a v potomkovi, se nevypropaguje do rodiˇce. Tˇr´ıdy vloˇzen´e v rodiˇci nelze ˇza´dn´ ym zp˚ usobem z potomka parametrizovat, jednalo by se o znaˇcn´e omezen´ı. M´ısto tohoto postupu se bˇeˇznˇe m´ısto rodiˇcovsk´eho node vytv´aˇr´ı tˇr´ıda, 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 dos´ahnout jednotnosti verz´ı technologie Gluster na jednotliv´ ych serverech, bez ohledu na distribuci ˇci verzi distribuce. Toho 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´ı moˇzn´e 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. Nyn´ı je moˇzn´e 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 m´e neznalosti technologie 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, 7

Z Debian Lenny na Debian Squeeze

42

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. ´ 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 ˇz´adn´ y z uˇzivatel˚ u nevzpomene na d˚ uvod existence toho ˇci onoho souboru. 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 mus´ı vytvoˇrit ˇcasem podle krit´eri´ı specifick´ ych pro dan´ y server. Ve zdrojov´em k´odu 3.7 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 web03ˇ a migrace bohuˇzel nebyla moˇzn´a. Naˇstˇest´ı ale nem´a bˇeh serveru lb01 vliv na jeho host. Ziv´ 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.

43

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 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. V´ ypoˇ cetn´ı servery a nastaven´ı virtual host˚ u 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ˇca´st´ı tohoto modulu jsou obecn´e definice apache a 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´ı 8

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

44

manaˇzer11 . 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.

11

http://plathrop.tertiusfamily.net/

45

Kapitola 4 Zhodnocen´ı Implementace vˇsech projekt˚ u popisovan´ ych v t´eto pr´aci prob´ıhala iterativnˇe, na z´akladˇe aktu´aln´ıch potˇreb. V´ ystupy a zkuˇsenosti jednoho projektu se obvykle pouˇzily v nˇekter´em z dalˇs´ıch projekt˚ u. Nˇekter´e projekty, jenˇz dle m´eho soudu jen okrajovˇe souvisely s t´ematem konfiguraˇcn´ıho managementu a spr´avy server˚ u jsem vynechal u ´plnˇe. Z´ıskan´e zkuˇsenosti z tˇechto projekt˚ u jako celku bych shrnul do n´asleduj´ıc´ıch bod˚ u: • Kvalitn´ı monitorovac´ı syst´em je z´akladem kaˇzd´eho produkˇcn´ıho prostˇred´ı. Pokud se objevuje jen nepatrn´e procento faleˇsnˇe pozitivn´ıch hl´aˇsen´ı, administr´atoˇri zaˇcnou tato hl´aˇsen´ı velice rychle ignorovat a snadno se stane, ˇze pˇrehl´ednou nˇejak´e opodstatnˇen´e hl´aˇsen´ı. Souˇcasnˇe je potˇreba zajistit, aby monitorovac´ı sluˇzba sledovala vˇsechny zn´am´e probl´emov´e ˇc´asti syst´emu. • Osobn´ı znalost chov´an´ı produkˇcn´ıho prostˇred´ı je nenahraditeln´a a nem˚ uˇze j´ı zastoupit sebelepˇs´ı dokumentace. Je proto dobr´e pravidelnˇe distribuovat informace ohlednˇe zmˇen produkˇcn´ıho prostˇred´ı mezi v´ıce lid´ı. A zav´est zvyk, ˇze opakuj´ıc´ı se probl´emy nespravuje pouze jeden ˇclovˇek. • Dokumentace by nikdy nemˇela b´ yt podceˇ nov´ana. I pouh´ y v´ ypis z konzole pˇriloˇzen´ y k tiketu je lepˇs´ı, neˇz ˇza´dn´a dokumentace. • Je dobr´e prov´est ˇreˇsen´ı dan´eho probl´emu v duchu Keep It Simple and Stupid (KISS) principu. Do sloˇzit´ ych (komplexn´ıch) ˇreˇsen´ı je tˇeˇzˇs´ı proniknout. Jsou obvykle h˚ uˇre modifikovateln´a. A z m´e osobn´ı zkuˇsenosti pˇrin´aˇs´ı jen malou pˇridanou hodnotu. Je dobr´e se drˇzet pravidla 80/20 1 . ˇ adn´e nav´ • Z´ yˇsen´ı v´ ykonu HW nem˚ uˇze vyˇreˇsit v´ ykonnostn´ı probl´emy ˇspatnˇe napsan´eho Software (SW). • Don’t Repeat Yourself (DRY) princip je velice ˇcasto zanedb´avan´ y, coˇz vede obvykle k aplikov´an´ı postupu Ctrl+C, Ctrl+V. N´aslednˇe je k´od ˇci konfigurace velmi tˇeˇzko udrˇzovateln´ y. Kop´ırov´an´ı konfigurac´ı se zprvu m˚ uˇze zd´at jako nejrychlejˇs´ı ˇreˇsen´ı, ale ve v´ ysledku obvykle zabere daleko v´ıce ˇcasu neˇz dodrˇzov´an´ı DRY pˇr´ıstupu. • CMS puppet n´am, pˇres velmi vysok´e poˇc´ateˇcn´ı n´aklady, uˇsetˇril velk´e mnoˇzstv´ı ˇcasu pˇri spr´avˇe server˚ u. • Puppet je jednoduch´ y n´astroj pro tvorbu dokumentace konfigurac´ı produkˇcn´ıch server˚ u. T´ım, ˇze jsou konfigurace puppetu v svn, m˚ uˇzeme jednoduˇse sledovat motivace jednotliv´ ych z´aznam˚ u v konfigurac´ıch. Jako dokumentace slouˇz´ı i koment´aˇre v jednotliv´ ych manifestech puppetu. 1

Pravidlo 80/20 ˇr´ık´ a, ˇze 80 procent vˇsech v´ ysledk˚ u vznik´a z 20 procent pˇr´ıˇcin.

46

• CMS velmi zpˇr´ıjemˇ nuje kaˇzdodenn´ı interakci se servery, jelikoˇz dok´aˇze sjednotit pˇr´ıstup administr´atora k r˚ uzn´ ym OS ˇci verz´ım OS. • S vˇetˇs´ı integrac´ı puppetu do naˇs´ı produkce, pˇr´ımo u ´mˇernˇe vzr˚ ust´a m´ıra z´asah˚ u, jenˇz v syst´emu dok´aˇzeme prov´est za jednotku ˇcacu. • Pˇred implementac´ı jak´ekoliv zmˇeny je dobr´e z dostupn´ ych dat vytvoˇrit hypot´ezy ohlednˇe v´ ykonnostn´ıch dopad˚ u, sepsat seznam syst´em˚ u na kter´e budou m´ıt zmˇeny vliv a urˇcit rizikov´a m´ısta implementace. Je moˇzn´e, ˇze se uk´aˇze, ˇze zmˇena nepˇrinesla k´ yˇzen´ y v´ ykonnostn´ı efekt. Nebo ˇze zmˇena ovlivn´ı syst´em takov´ ym zp˚ usobem, jenˇz si nem˚ uˇzeme dovolit. • Murphyho z´akon: Co se m˚ uˇze pokazit, to se pokaz´ı. Co se nem˚ uˇze pokazit, to se ” pokaz´ı taky, ale aˇz za delˇs´ı dobu“ je platn´ y. • Tvrzen´ı: Kaˇzd´ y zdrojov´ y k´od o alespoˇ n dvou ˇra´dc´ıch obsahuje alespoˇ n jednu chybu.“ ” je tak´e platn´e.

4.1

Z´ avˇ er

V tomto dokumentu jsem se snaˇzil popsat m´e sezn´amen´ı s produkc´ı firmy, moj´ı motivaci pro implementaci CMS puppet a jednotliv´e projekty, jenˇz byly do t´eto doby udˇel´any. Prov´adˇen´ı zmˇen na produkci, bylo d´ıky brzk´e integraci puppetu velmi zjednoduˇseno. Projekty v tomto dokumentu popsan´e trvaly bezm´ala jeden kalend´aˇrn´ı rok. Z toho pˇribliˇzn´e 6 mˇes´ıc˚ u je vyuˇz´ıv´an puppet. Nˇekter´e projekty dopadly ne´ uspˇechem a jedin´ y pˇr´ınos mˇely v podobˇe pouˇcen´ı pro projekty budouc´ı. Produkce nen´ı v ˇz´adn´em pˇr´ıpadˇe v dokonal´em stavu. Proces vylepˇsov´an´ı st´ale pokraˇcuje. Z projektu vzeˇslo velk´e mnoˇzstv´ı zkuˇsenost´ı a dalˇs´ıch d´ılˇc´ıch projektu, kter´e ˇcekaj´ı na realizaci.

47

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´ı.. 15, 24, 25, 30 ´ ”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´ı.. 16 ”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, 20 ˇ 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“.. 35 AJAX Asynchronous JavaScript and XML. 32 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, 33–35 API Application Programming Interface. 23, 31 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

48

CARP Common Address Redundancy Protocol. 44 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. 35, 36, 41–44, 46, 47 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.. 36, 37, 39, 45 DNS Domain Name Server. 17, 19, 30, 39 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 ” DRY Don’t Repeat Yourself. 46 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, 30 FQDN Fully Qualified Domain Name. 39 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 49

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.. 41 GPL GNU General Public License. 36 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.. 39 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 . 11, 18 HW Hardware. 10, 15, 46 IM Instant messaging. 32 IP Internet Protocol. 18, 19 KISS Keep It Simple and Stupid. 46 kontejner Kontejner, anglicky container je pojem zn´am´ y pˇredevˇs´ım z prostˇred´ı OpenVZ . 7 KVM Kernel-based Virtual Machine. 9 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. 43 memcached Keˇsovac´ı server, jenˇz ukl´ad´a data do pamˇeti. Vyznaˇcuje se rychl´ ym pˇr´ıstupem a velmi omezenou mnoˇzinou funkc´ı.. 31, 32 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, 24–27, 29–31, 42 NSCA Nagios Service Check Acceptor. 22 NTP Network Time Protocol. 21, 41 OID Object Identifier. 19 50

open source Software s volnˇe dostupn´ ymi zdrojov´ ymi k´ody. 8 OS Operaˇcn´ı syst´em. 4–10, 17, 39, 40, 42, 47 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 PHP Hypertext Preprocessor. 31, 32, 44, 45 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.. 41 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.. 36, 37, 39–42, 44, 46, 47 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.. 36, 39, 40 SNI Server Name Indication. 18 SNMP Simple Network Management Protocol. 19, 21, 41 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 51

SSH Secure Shell. 21 SSL Secure Sockets Layer. 18, 19 svn subversion. 31, 40, 46 SW Software. 46 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 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.. 41 VPC Virtual Private Cloud. 23, 24 VPN Virtual Private Network. 2, 23 XEN V IT se pod pojmem XEN rozum´ı virtualizaˇcn´ı technologie. 10

52

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] Dormando. What is memcached? http://memcached.org/, 2009. [Online; pˇr´ıstupn´e 22.05.2011]. [11] 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]. [12] The Apache Software Foundation. Ssl/tls strong encryption: Faq. l, 2011. [Online; pˇr´ıstupn´e 29.3.2011]. [13] 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].

53

[14] 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]. [15] Kirill Kolyshkin. Virtualization in Linux. http://download.openvz.org/doc/ openvz-intro.pdf, 2006. [Online; pˇr´ıstupn´e 9.2.2011]. [16] Puppet Labs. Docs: Troubleshooting. http://docs.puppetlabs.com/guides/ troubleshooting.html#common-misconceptions, 2011. [Online; pˇr´ıstupn´e 19.04.2011]. [17] Puppet labs. Docs: Type reference. http://docs.puppetlabs.com/references/ latest/type.html, 2011. [Online; pˇr´ıstupn´e 16.04.2011]. [18] Puppet Labs. Docs: Using puppet templates. http://docs.puppetlabs.com/ guides/templating.html, 2011. [Online; pˇr´ıstupn´e 17.04.2011]. [19] Puppet Labs. Glossary of terms. http://projects.puppetlabs.com/projects/ puppet/wiki/Glossary_Of_Terms, 2011. [Online; pˇr´ıstupn´e 17.04.2011]. [20] 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]. [21] 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]. [22] 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]. [23] Wikipedia. Failover. http://en.wikipedia.org/wiki/Failover, 2011. [Online; pˇr´ıstupn´e 22.2.2011]. [24] Wikipedia. Gaussova funkce. http://cs.wikipedia.org/wiki/Gaussova_funkce, 2011. [Online; pˇr´ıstupn´e 11.04.2011]. [25] Wikipedia. Kernel-based Virtual Machine. http://en.wikipedia.org/wiki/ Kernel-based_Virtual_Machine, 2011. [Online; pˇr´ıstupn´e 2.2.2011]. [26] Wikipedia. Network file system. http://cs.wikipedia.org/wiki/Network_File_ System, 2011. [Online; pˇr´ıstupn´e 27.3.2011]. [27] Wikipedia. RAID. http://cs.wikipedia.org/wiki/RAID#RAID_1_.28zrcadlen. C3.AD.29, 2011. [Online; pˇr´ıstupn´e 20.3.2011]. [28] Wikipedia. Soubˇeh. http://cs.wikipedia.org/wiki/Soub%C4%9Bh, 2011. [Online; pˇr´ıstupn´e 05.04.2011]. [29] Wikipedie. Round-trip delay time. http://en.wikipedia.org/wiki/Round-trip_ delay_time, 2011. [Online; pˇr´ıstupn´e 11.04.2011].

54

[30] 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].

55

Pˇ r´ıloha A Obr´ azky

56

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

57

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

58

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

59

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

60

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

61

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

62

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

63

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

64

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

65

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

66

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” )

67

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 ,

68

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

69

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. 70

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.

71

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. 72