O plánované akci jsme se dozvěděli 18. září a přesně za čtrnáct dnů měl být celý cluster rozebrán, počítače zabaleny do krabic a odeslány. Několik dní nám zabralo pátrání po internetu, sbírání informací a hledání potřebného softwaru. Naši nadřízení vyjádřili k pokusu sympatie, kolegové však projevovali značnou skepsi a málokdo věřil, že se nám podaří v tak krátké době cluster postavit. Ani veselé prohlášení jednoho kolegy, že u nich na fakultě rozbíhali cluster půl roku, nás však neodradilo.
A tak jsme se hned začátkem následujícího týdne dali do práce. Po zevrubném studiu rozličných dokumentů nám vyplynuly pouze dvě možnosti dostupné k realizaci celého clusteru, a to jedna varianta postavená dle specifikace projektu Beowulf a druhá vystavěná na modifikaci linuxového jádra Mosix, potažmo OpenMosix. Naše volba padla jak jinak než na OpenMosix. Hlavním důvodem, proč jsme se takto rozhodli, byla převážně nižší náročnost na zprovoznění nežli u projektu Beowulf, což nám dávalo šanci, že pravděpodobně stihneme termín.
K nastudování „jak zprovoznit OpenMosix“ však nedošlo, jelikož jsme již v první fázi zprovozňování narazili na projekt KnoppixCluster. Myslím, že častým čtenářům ROOTa netřeba linuxovou distribuci Knoppix představovat, ale pro nováčky jen řekněme, že se jedná o distribuci Debian GNU/Linuxu běžící přímo z CDčka, a co se týče její clusterové modifikace, tak ještě navíc rozšířenou o plně funkční OpenMosix implementaci. S tou pak již byla celá práce hračka, i když jsme na pár problémů mimo dokumentaci samozřejmě narazili. I přesto, že se zde zmiňujeme jen o dvou variantách, nejsou jedinými dostupnými řešeními výpočetního clusteru, ale jsou bohužel jedinými řešeními, která jsou OpenSource, a tudíž zadarmo.
Trocha teorie nikoho nezabije
Kdo z vás se již někdy zajímal o to, jak výpočetní clustery fungují, zjistil, že to celé není až tak jednoduché. Pro zvýšení výpočetního výkonu existuje například superpočítač od společnosti SGI, vystavěný nad technologií a architekturou NumaFlex, kde se víceprocesorová mašina tváří jako jeden stroj, a tak netřeba běžící aplikaci pro větší výkon jakkoliv modifikovat. Má to však jeden háček, a tím je výše pořizovacích nákladů. Zde přicházejí na řadu právě clustery. Ty takovouto pokročilou technologií nedisponují, a tudíž je schopnost rozkladu zátěže řešena například nadstavbou systému pomocí technologie MPI. Když chcete postavit cluster na těchto technologiích, je třeba si nainstalovat pár linuxových mašin a na nich pak rozeběhnout některou z variant implementace MPI démona. Abyste mohli za pomoci těchto technologií provádět výpočetní úkony a především rozkládat zátěž, musíte pro naprogramování použít příslušné MPI knihovny, s pomocí kterých si způsob komunikace a migrace budete muset zajistit, ohlídat a tak trochu doprogramovat. V podstatě se dá říct, že zde leží břemeno napůl na démonovi MPI a napůl na programátorovi výpočetního úkolu.
OpenMosix se v tomto ohledu od výše zmíněné technologie MPI liší. Jeho základní podstatou je modifikace jádra Linuxu tak, že nadstavba Mosix přebírá kontrolu nad procesy ve chvíli volání například fork(), což umožňuje využití této technologie bez nutnosti větší úpravy kódu. Pouhým štěpením na procesy lze dosáhnou jednoduchého šíření po nódech clusteru. OpenMosix se ve své podstatě skládá z patche na linuxové jádro, z OpenMosix démona, z OpenMosix Colectoru sbírajícího data z jednotlivých nódů a z obslužných programů a knihoven potřebných ke komunikaci s mosixem a k monitorování. Při běhu mosix disponuje speciální částí souborového systému /proc, kde lze na jakémkoliv nódu získat informace o nódech ostatních, a taktéž svým vlastním souborovým systémem MFS. Ten poskytuje rychlý přístup z uzlu na uzel bez nutnosti přihlašování. No a to je tak asi ve zkratce z teorie. Na toto téma by se bezesporu dalo ještě dlouho mluvit, ale to není účelem tohoto článku, a tak se raději vraťme k popisu samotné realizace.
Během tří dnů práce nám už openMosix běhal na malém clustříku ze tří starších počítačů a několik pokusných procesů (věčných smyček) vesele migrovalo z jednoho nodu na druhý. Začali jsme se tedy pokoušet o spuštění nějaké zajímavější aplikace napsané v MPI. To se nám ale nakonec nepodařilo, nebyl čas prostudovat všechny návody ani upravit používanou distribuci Knoppixu.
Ve čtvrtek 24. 9. jsme dostali k dispozici tři z počítačů, ze kterých měl být cluster postavený, a i na nich se openMosix bez problémů rozeběhl. Až na jeden problém s náběhem jednotlivých nódů, který se nám povedlo vyřešit až později při ostrém nasazení. V úterý 30. 9. jsme pak tuto sestavu naložili do auta, odvezli do sídla Tecomu a megaakce mohla začít.
Velká zkouška naostro
Když jsme dorazili do sídla firmy Tecom, už nás čekala celá armáda 50 Pentií 4 (včetně našich tří zapůjčených) na 2,4 Ghz s 512 MB RAM a samozřejmě s gigabitovou síťovou kartou. No řekněte – není to snad ideální hardware na experimenty s Linuxem :-). Samozřejmě nechyběly ani síťové gigabitové prvky zapůjčené na tuto akci od společnosti 3Com. Následně jsme začali zapojovat jednotlivé počítače do sítě a modifikovat u 47 nódů nastavení BIOSu pro bootování ze sítě pomocí intelovské technologie PXE (tou disponuje většina novějších karet nejen od Intelu).
Během úterka se nám podařilo zapojit do clusteru 15 počítačů. Vzhledem k teplu, které vydávaly, jsme se rozhodli nenechávat je bez dozoru a přes noc je vypnout, takže jsme ve středu začínali znovu. Začali jsem tím, že jsme jedním vypínačem zapnuli všech padesát počítačů najednou… Pokračovalo se pochopitelně hledáním hlavního jističe od celé firmy :-).
Poučení pro příště – vypínat nejen počítače, ale i zdroje, a zapínat je postupně.
Jak jsme se již zmínili výše, nebylo vše bez problémů. Během výstavby nás postihly dva klíčové problémy, které jsme museli řešit. Tím prvním byla nemožnost připojení více než jednoho root filesystemu z NFS po nabootování jádra. Tuto chybu jsme prozatím řešili pravidelným restartem NFS démona na hlavním počítači. Finální řešení se naskytlo až den před prezentací, neboť nás napadlo, že celý problém může mít souvislost s modifikací volání jádra, a tak jsme nakonec rozeběhli NFS server na notebooku s nemodifikovaným kernelem a úspěch se brzy dostavil.
Druhá nepříjemná situace nastala, když jsme na místě určení započali sestavovat naši dovezenou a odzkoušenou sestavu, ale již první nód se nechtěl připojit – i když u nás na firmě vše šlapalo takřka perfektně. I rozlousknutí tohoto oříšku na sebe nechalo den čekat, neboť celé chování bylo velice zvláštní. Vždy každá přibližně sedmá stanice vykazovala problémy s připojením do clusteru. Toto chování bylo zcela chaotické a náhodné. Až další den jsme si všimli, že jedna stanice se sice do clusteru nepřipojila, ale vidí další tři nódy v okolí, které již v clusteru byly (dobrý výkon z dvaceti :-) ). To nás dovedlo na stopu, že jedinou změnou oproti původní kofiguraci je zde síťové prostředí. Po krátkém telefonátu s člověkem od 3Comu bylo řešení na světě. Aktivní prvky byly totiž nastaveny tak, že mezi sebou nepropouštěly multicasty, a když, tak jenom stopově. Deaktivace tohoto filtru se ukázala pravým řešením na pravém místě a už jsme nemuseli obcházet všechny počítače s LCD displayem.
O naší výpočetní úloze
A tak se nám ve středu podařilo vychytat ty nejhorší mouchy a rozběhnout testovací aplikaci. Původně jsme samozřejmě chtěli spustit aplikaci, která by počítala něco rozumného. Zjistili jsme ale, že upravit naši aplikaci, která počítá „něco rozumného“ (a která by velmi, velmi potřebovala běžet rychleji) tak, aby se rozdělila na více procesů, není v tak krátké době v našich silách. Proto jsme vytvořili alespoň aplikaci, která byla schopná cluster zatížit.
V céčku jsme napsali jednoduchý program, který pomocí fork() postupně spouštěl 500 dceřiných procesů. Každý z nich hledal jedno prvočíslo – první hledal pětitisící prvočíslo v pořadí, druhý 5001. prvočíslo, až poslední hledal 5499. prvočíslo (a musel tedy najít i všech 5498 předchozích). Prvočíselnost se zjišťovala nejjednodušším možným způsobem – testováním nedělitelnosti daného čísla žádným menším číslem kromě jedničky. Celkem tedy program identifikoval více než 2,6 milionů prvočísel. (Ano, ovšem že je snadné naprogramovat Eratosthenovo síto, ale to by to měly ty počítače moc lehké.) Program měl dvě přednosti – jednak byl opravdu jednoduchý, nebyl delší než dvacet řádek, a jednak byl opravdu výpočetně náročný – na jednom počítači běžel asi patnáct minut. Jednotlivé procesy trvaly dostatečně dlouho na to, aby bylo možné na Mosix MigrationMonitoru pozorovat, jak migrují na jiné nody.
Samozřejmě, ani ten nejjednodušší prográmek se nepovede napoprvé. Ani ten náš nebyl výjimkou. Běžel hezky, ale nějak nechtěl doběhnout. Než nám došlo, že tam chybí jeden malinký „break“ a kvůli tomu se procesy množí exponenciálně, bylo už procesů tolik, že cluster zcela zahltily, hlavní počítač nereagoval na naše pokyny, nebylo možné úlohu killnout a museli jsme potupně použít vypínač.
Poučení číslo dvě: spustíte-li neodladěný program, nechoďte na kávu a raději ho podezřívavě pozorujte.
Po odstranění téhle drobné chybičky jsme začali měřit, jak dlouho trvá výpočet, když se zapojí různý počet uzlů. Jak známo, jestliže jeden dělník vykope metr širokou studnu za osm dní, pak dva dělníci ji vykopou za čtyři dny, ale nelze očekávat, že by 1024 dělníků vykopalo studnu za 11 minut a 15 sekund. Byli jsme zvědaví, při jakém počtu nodů se tento efekt projeví.
Zhodnocení sesbíraných dat
Výsledky nejsou nezajímavé. Pro malý počet uzlů roste rychlost výpočtu lineárně, již někde mezi 5 – 10 uzly se ale křivka láme a přidávání dalších uzlů už má jen malý význam. Je to způsobeno pravděpodobně relativně rostoucí režií organizace výpočtu. Zatížení sítě v tomto konkrétním případě nehrálo valnou roli. Při více než 15 nodech už ani MosixMonitor moc nestíhal překreslovat obrazovku. Přitom ukazoval „load balancing efficiency“ 50–70%, kdežto při zapojení jen několika nodů byla efektivnost okolo 98%.
Zkusili jsme prográmek mírně modifikovat, aby spouštěl 2000 procesů a hledal menší prvočísla – od padesátého dál. Pracovalo tedy více procesů, ale každý z nich doběhl rychleji. V této modifikaci byl – podle očekávání – pokles rychlosti výpočtu pro více nodů ještě horší. Zajímavé ale bylo, že výpočet na pěti uzlech byl více než pětkrát rychlejší než na jednom. Nevíme, čím si to vysvětlit, ale může to být prostě chyba měření.
Určitě by bylo zajímavé proměřit přesněji hodnoty pro menší počet uzlů (1–10), ale času bylo málo a cluster o několika málo nodech snad budeme mít možnost ještě někdy otestovat.
Je zřetelně vidět, že efektivita využití většího clusteru je velmi závislá na struktuře použitého software; je potřeba vhodně nastavit velikost jednotlivých procesů – třeba tak, že se několik kratších kousků vždycky „zabalí“ do většího balíčku.
Pro opravdové zhodnocení výkonu clusteru bychom potřebovali udělat spoustu dalších měření, hlavně vyzkoušet jiné typy úloh: úlohy náročné na paměť a úlohy, které kladou velké nároky na přenos dat po síti. Propustnost sítě bývá u paralelního zpracování úloh klíčovým problémem a obě testovací úlohy síť zatížily podle měření jen nepatrně. Hezký (a praktický) nápad, zpracovat na clusteru několik set fotografií z dovolené – upravit na velikost vhodnou pro web, pro palmtop, vytvořit náhledy a webové album – jsme už zrealizovat nestihli.
Nicméně i tak se ukázalo, že linuxový cluster skutečně postavit jde a vůbec nevadí, jestli je pro něj k dispozici jen pár počítačů, naopak – malý cluster sice není moc pozoruhodný, ale jeho výkonnost může být velmi příznivá.
Finalní den prezentace
Poslední den akce, čtvrtek, byl poněkud hektický. Potřetí jsme rozběhli cluster – tentokrát už běželo 43 počítačů (těch posledních pár jsem před prezentací nestihli), připravili jsme grafy, zapojili dataprojektor a na desátou hodinu již byli pozvaní hosté na narychlo svolanou prezentaci. Po ní jsme ještě stihli udělat pár měření a ve 12:00 přesně podle dohody přišel pan Höfner a odnesl nám switche, které putovaly na docela jinou akci.
Závěr
Než jsme stáhli konfigurace a výsledky měření z hlavního počítače a rozmotali klubko kabelů, byly už ostatní počítače zabaleny do krabic, naloženy do dodávky a odeslány ke svému novému majiteli. My jsme byli bohatší o zkušenosti a o vědomí, „že to opravdu funguje“, a dokonce, že by výpočetní cluster na bázi openMosixu byl pro naši firmu vhodným řešením.
Samotné zprovoznění clusteru je samozřejmě pouhý začátek. Pro skutečně efektivní použití budeme muset vyřešit spoustu detailů i větších problémů – od topologie sítě po organizaci výpočtu. Ze všeho nejvíc bude potřeba zapracovat na softwaru výpočtů, které chceme provádět. Onen půlrok, kterým nás kolega strašil, je asi poměrně realistický odhad. Ale je to slibný začátek.
Poděkování
Komu bychom chtěli za povedenou akci poděkovat? Především firmě Tecom, která nám nejen půjčila na hraní padesát zbrusu nových počítačů a další potřebný hardware, ale poskytla nám i plný servis, zázemí a erudici svých techniků a neomezené množství elektrického proudu a kávy. Rovněž všem technikům a dalším zaměstnancům této firmy, bez jejichž pomoci bychom cluster nebyli schopni zprovoznit (schválně si spočítejte, jak dlouho by dvěma lidem trvalo jen přenést padesát počítačů do místnosti a zapojit je do proudu a do sítě :-)), jmenovitě pak panu Lukáši Höfnerovi, strůjci a organizátorovi celé akce. Dále pak naší mateřské firmě AŽD Praha a našim nadřízeným, kteří měli dostatek pochopení pro šílený nápad dvou vývojářů. Firmě 3Com, která zapůjčila aktivní prvky pro výstavbu gigabitové sítě. Všem ostatním, kdo nám přispěli radou či pomocí. Jirkovi Franklovi a jeho notebooku leovi, který ochotně převzal funkci distribučního NFS serveru.
Linky
www.beowulf.org
www.mosix.org
openmosix.sourceforge.net
both.be/clusterknoppix
