Sem vložte zadání Vaší práce

Sem vložte zadání Vaší práce.

České vysoké učení technické v Praze Fakulta informačních technologií Katedra počítačových systémů

Diplomová práce

Rešerše kešovacích mechanizmů v systému Clondike Bc. Michal Salát

Vedoucí práce: Ing. Josef Gattermayer

6. května 2014

Poděkování Děkuji rodičům za podporu po celou dobu studia a zejména v době dokončování této práce.

Prohlášení Prohlašuji, že jsem předloženou práci vypracoval(a) samostatně a že jsem uvedl(a) veškeré použité informační zdroje v souladu s Metodickým pokynem o etické přípravě vysokoškolských závěrečných prací. Beru na vědomí, že se na moji práci vztahují práva a povinnosti vyplývající ze zákona č. 121/2000 Sb., autorského zákona, ve znění pozdějších předpisů. V souladu s ust. § 46 odst. 6 tohoto zákona tímto uděluji nevýhradní oprávnění (licenci) k užití této mojí práce, a to včetně všech počítačových programů, jež jsou její součástí či přílohou a veškeré jejich dokumentace (dále souhrnně jen „Dílo“), a to všem osobám, které si přejí Dílo užít. Tyto osoby jsou oprávněny Dílo užít jakýmkoli způsobem, který nesnižuje hodnotu Díla a za jakýmkoli účelem (včetně užití k výdělečným účelům). Toto oprávnění je časově, teritoriálně i množstevně neomezené. Každá osoba, která využije výše uvedenou licenci, se však zavazuje udělit ke každému dílu, které vznikne (byť jen zčásti) na základě Díla, úpravou Díla, spojením Díla s jiným dílem, zařazením Díla do díla souborného či spracováním Díla (včetně překladu), licenci alespoň ve výše uvedeném rozsahu a zároveň zpřístupnit zdrojový kód takového díla alespoň srovnatelným způsobem a ve srovnatelném rozsahu, jako je zpřístupněn zdrojový kód Díla.

V Praze dne 6. května 2014

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

České vysoké učení technické v Praze Fakulta informačních technologií c 2014 Michal Salát. Všechna práva vyhrazena.

Tato práce vznikla jako školní dílo na Českém vysokém učení technickém v Praze, Fakultě informačních technologií. Práce je chráněna právními předpisy a mezinárodními úmluvami o právu autorském a právech souvisejících s právem autorským. K jejímu užití, s výjimkou bezúplatných zákonných licencí, je nezbytný souhlas autora.

Odkaz na tuto práci Salát, Michal. Rešerše kešovacích mechanizmů v systému Clondike. Diplomová práce. Praha: České vysoké učení technické v Praze, Fakulta informačních technologií, 2014.

Abstrakt Tato práce se věnuje analýze současného stavu projektu Clondike, měření jeho výkonnosti a možností dalšího rozšíření. Je zde popsáno množství úprav, které vedly ke zprovoznění obrazu systému a úpravě výkonnostních parametrů. Taktéž je uveden popis systému souborů ProxyFS 2 a jeho potenciální využití v projektu. V rámci práce byla provedena úprava zdrojových kódů komponent, která umožňuje jejich překlad do podoby modulů jádra. Klíčová slova prostředek

klastr, Clondike, modul, systém souborů, ovladač, sdílený

Abstract This thesis addresses an analysis of the current state of the Clondike project, the measurements of its performance and possibilities for further improvements. There have been introduced several modifications that repaired the non-functional system image and led to a performance gain. This thesis contains a description of ProxyFS 2 file system along with feasibility analysis of its utilization in the project. Changes to source codes of the Clondike components have been made to enable compilation of those components in a kernel module form. ix

Keywords cluster, Clondike, module, filesystem, driver, shared resource

x

Obsah Úvod

1

1 Cíl práce 1.1 Struktura práce . . . . . . . . . . . . . . . . . . . . . . . . . . .

3 3

2 Seznámení s projektem Clodike 2.1 Komponenty Clondike . . . . . . . . . . . . . . . . . . . . . . . 2.2 Distribuce . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

5 5 7

3 Ověření funkčnosti obrazu 3.1 Popis testovacího prostředí . . 3.2 Testovací metodika . . . . . . . 3.3 Oprava serveru NPFS . . . . . 3.4 Upgrade knihovny Netlink . . . 3.5 Úpravy Simple Ruby Directoru 3.6 Výsledky měření . . . . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

15 15 16 18 18 19 23

4 ProxyFS 2 29 4.1 Stav implementace . . . . . . . . . . . . . . . . . . . . . . . . . 31 4.2 Srovnání s aktuálním stavem . . . . . . . . . . . . . . . . . . . 33 5 Instalace Clondike jako modul 5.1 Formát Kconfig . . . . . . . . 5.2 Formát Makefile . . . . . . . 5.3 Provedené úpravy . . . . . . . 5.4 Ověření funkčnosti . . . . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

37 37 38 40 41

6 Zhodnocení splnění cílů 43 6.1 Seznámení s Clondike a měření na obrazu systému . . . . . . . 43 6.2 Rešerše výsledků práce Ing. Maláta . . . . . . . . . . . . . . . . 43 xi

6.3

Clondike jako modul . . . . . . . . . . . . . . . . . . . . . . . .

44

Závěr

45

7 Budoucí práce

47

Literatura

49

A Seznam použitých zkratek

51

B Obsah přiloženého CD

53

xii

Seznam obrázků 2.1 2.2

Schéma propojení jednotlivých komponent projektu Clondike . . . Schéma propojení jednotlivých součástí nástroje BuildBot . . . . .

3.1

Výsledky měření doby výpočtu testovací úlohy za použití měřícího nástroje ve virtuálním prostředí . . . . . . . . . . . . . . . . . . . . Výsledky měření doby výpočtu testovací úlohy bez použití měřícího nástroje . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Výsledky měření doby výpočtu testovací úlohy za použití měřícího nástroje . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Výsledky měření zatížení procesoru (minutový průměr) jednotlivých uzlů . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Výsledky měření zatížení procesoru (okamžité) jednotlivých uzlů . Výsledky měření počtu procesů na jednotlivých uzlech . . . . . . .

3.2 3.3 3.4 3.5 3.6

xiii

8 9

24 25 26 27 27 28

Seznam tabulek 3.1

Zrychlení a efektivita v závislosti na počtu uzlů . . . . . . . . . . .

xv

28

Úvod Řešení náročných úloh je omezováno vysokou výpočetní složitostí, která způsobuje dlouhou dobu jejich zpracování. Výkon jednotlivých pracovních stanic však nelze navyšovat neomezeně. Jedním z možných řešení tohoto problému je seskupování počítačů do výpočetních klastrů. Projekt Clondike byl navržen jako nový typ klastru, který je sestaven z běžných pracovních stanic s operačním systémem Linux a simuluje jeden výkonný stroj (SSI - Single System Image). Jedinečnou vlastností Clondike je schopnost integrace pracovních stanic do klastru i bez jejich plné dedikace. To umožňuje uživatelům plně využít svoji pracovní stanici pro běžnou práci a poskytnout volné výpočetní kapacity pro využití v klastru.

1

Kapitola

Cíl práce Cílem této práce je provést analýzu současného stavu projektu Clondike, ověřit jeho funkčnost ve virtuálním prostředí a v laboratoři ČVUT, změřit výkon klastru a porovnat jej s předchozími výsledky. Následně provést rešerši práce Ing. Maláta, který se věnoval návrhu a implementaci ovladače systému souborů ProxyFS 2 podporujícího sdílení prostředků, a změřit navýšení výkonu při použití této komponenty. Posledním cílem je úprava zdrojových kódů umožňující instalaci jednotlivých komponent projektu jako modulů jádra.

1.1

Struktura práce

V kapitole 2 je představen projekt Clondike a jeho struktura. V první polovině kapitoly je popsáno, z jakých komponent se projekt skládá a co je jejich účelem. Druhá polovina je věnováná způsobu, jakým lze Clondike získat, jaké problémy byly při prvotních pokusech o jeho spuštění nalezeny a jak byly vyřešeny. V následující kapitole 3 je popsána metodika, pomocí které bylo provedeno ověření funkčnosti klastru sestaveného ze strojů obsahujících projekt Clondike a měření jeho výkonu. Stejně jako v předchozí části se vyskytlo několik problémů, jež byly následně popsány s dokumentací o jejich opravě. V závěru kapitoly byly zpracovány výsledky měření a provedeno jejich porovnání s výsledky uvedenými v předchozí práci [1]. V kapitole 4 je uveden popis současného způsobu sdílení prostředků v projektu Clondike a řešení navrhované Ing. Malátem v jeho diplomové práci [2]. Rovněž je analyzována funkčnost jím navrženého řešení a možnost, jak by bylo možné nahradit současný způsob sdílení prostředků. V předposlední kapitole 5 je popsáno, jakým způsobem pracuje konfigurační a sestavovací mechanismus jádra a jak je třeba jej upravit, aby bylo možné překládat komponenty Clondike v podobě modulů jádra. Poslední kapitola 6 sumarizuje a hodnotí dosažené výsledky a splnění zadání práce.

3

1

Kapitola

Seznámení s projektem Clodike Clondike je akronym pro CLuster Of Non-Dedicated Interoperating KErnels, což se volně překládá jako klastr nededikovaných spolupracujících jader operačních systémů. Klastr je skupina počítačů spolupracujících k dosažení společného cíle, které navenek mohou simulovat jeden velký stroj. Tak je tomu i v případě projektu Clondike, kde je klastr vytvářen na úrovni jádra operačního systému a tudíž je plně transparentní pro aplikace, které pracují v uživatelském prostoru. To umožňuje použití běžných aplikací naprogramovaných pro jeden stroj bez jakýchkoliv úprav. Klastry se rozdělují podle účelu využití na několik typů [3]: • výpočetní - cílem je zkrácení doby výpočtu úlohy • s vysokou dostupností - uzly klastru provádí stejnou činnost a v případě výpadku uzlu je úloha přesunuta na záložní uzel • s rozložením zátěže - úlohy jsou rozdělovány mezi jednotlivé uzly tak, aby nebyly přetěžovány a pracovaly s optimálním zatížením • úložné - zprostředkovává přístup k diskové kapacitě. Soubory jsou rozděleny mezi uzly a mohou být duplikovány k ochraně před ztrátou při výpadku Clondike reprezentuje výpočetní typ klastru. Jeho unikátní vlastností je, že stroje které jej vytváří, nejsou určeny výhradně pro práci v klastru, ale jejich majitelé je stále mohou využívat pro svoje potřeby.

2.1

Komponenty Clondike

Projekt se skládá z několika dílčích komponent: • Prostor jádra 5

2

2. Seznámení s projektem Clodike CCFS - Cache Clondike Filesystem Director TCMI - Task Checkpointing and Migration Infrastructure ProxyFS KKC - Kernel to Kernel Communication • Uživatelský prostor Simple Ruby Director C-API - aplikační rozhraní NPFS Tyto komponenty byly detailně popsány v bakalářské práci Bc. Jiřího Rákosníka [4] a proto jsou následující vysvětlení zestručněna. Schéma 2.1 zachycuje vzájemné závislosti komponent.

2.1.1

Cache Clondike Filesystem

CCFS je speciální souborový systém, který byl vytvořen pro účely laboratorních měření výkonosti projektu. Slouží jako vyrovnávací paměť pro omezení objemu dat přenášených po síti při migraci procesů.

2.1.2

Director

Tato komponenta zprostředkovává řízení všech operací skrze definované zprávy. Používá rodinu socketů Netlink [5] ke komunikaci s komponentou Simple Ruby Director, která tvoří jeho protějšek v uživatelském prostoru.

2.1.3

TCMI

TCMI je nejdůležitější a nejsložitější komponenta celého projektu. Provádí veškeré operace vedoucí k úspěšné migraci a běhu procesů jako je spojení jednotlivých uzlů, uložení, transport a obnovení stavu aplikace během přesunu na vzdálený uzel a další. Implementuje vlastní ovladač souborového systému, pomocí kterého je řízena z uživatelského prostoru. Aktuální implementace používá protokol 9P[6] a server NPFS[7] k přístupu ke vzdáleným souborům.

2.1.4

ProxyFS

ProxyFS je systém souborů, který byl vytvořen k doplnění funkcionality serveru NPFS, který neumožňuje sdílení speciálních souborů jako např. roury nebo sockety. 6

2.2. Distribuce

2.1.5

KKC

KKC je komunikační knihovna, která pomocí síťového protokolu propojuje jádra operačních systémů. Z toho důvodu byla zvolena jako komunikační prostředek jak pro ProxyFS tak i TCMI.

2.1.6

Simple Ruby Director

Tato komponenta řídí celý projekt Clondike. Zpracovává všechny zprávy získané z ostatních komponent a na jejich základě rozhoduje, který proces bude migrován a na jaký uzel. Taktéž zajišťuje vyhledávání a připojování jednotlivých uzlů. V současné implementaci je k vyhledávání uzlů použita adresa broadcast, což omezuje umístění uzlů pouze na lokální síť. Nicméně probíhá aktivní vývoj nového vyhledávacího mechanismu využívající protokol podobný DHT, který používá např. nástroj pro peer-to-peer distribuci souborů BitTorrent [8].

2.1.7

C-API

Tato komponenta vytváří rozhraní mezi komponentami Director a Simple Ruby Director. Je napsaná v jazyce C a používá knihovnu libnl [9] implementující protokol Netlink.

2.2

Distribuce

Potenciální uživatel Clondike má 2 možnosti jak jej začít využívat. Projekt nabízí obraz virtuálního stroje postavený na distribuci Debian a upraveném jádře verze 2.6.33 nebo lze využít zdrojové kódy uložené v Git repozitáři na adrese https://github.com/FIT-CVUT/Clondike.

2.2.1

BuildBot

Obraz virtuálního stroje je vytvářen na serveru clondike.fit.cvut.cz pomocí nástroje pro automatickou kompilaci BuildBot. Tento nástroj umožňuje automatické sestavení projektu z verzovacích repozitářů (Git, Subversion, Mercurial a další). Nástroj BuildBot reaguje na různé události, mezi které patří např. nahrání upravených zdrojových kódů do repozitáře, vypršení přednastaveného časového limitu a další. Po vzniku události následně spustí úlohu, která sestaví obraz virtuálního stroje. BuildBot pracuje v režimu Master-Slave. Master je hlavní uzel, stará se o řízení a přidělování úloh, interpretaci výsledků a smí existovat pouze jeden. Také obsahuje konfigurace všech úloh, které jsou systému známy. Slave uzly jsou podřízené hlavnímu uzlu, pracují na základě jeho příkazů a může jich být libovolný počet. Pro komunikaci mezi hlavním a podřízenými uzly se používá síťový protokol TCP, takže jednotlivé podřízené uzly mohou být umístěny na 7

2. Seznámení s projektem Clodike cmp Clondike Uživatelský Prostor Klastr

ProxyFS

«use»

KKC «flow»

«use» «use» TCMI

«flow» Director

Prostor Jádra

Řízení spojení

«flow»

«flow» C-API

Řízení migrace «flow»

Simple Ruby Director

«flow»

Obrázek 2.1: Schéma propojení jednotlivých komponent projektu Clondike

různých strojích. To například umožňuje překládání a testování aplikací pro různé operační systémy. V průběhu této práce byly z důvodu udržení stability zdrojových kódů vytvořeny v repozitáři čtyři vývojové větve projektu: salat-prod, salat-dev, dht a master. V této práci byly použity větve salat-prod a salat-dev, na kterých byly prováděny veškeré úpravy a měření. Větev dht používá ve své práci kolega Bc. Pavel Tvrdík pro implementaci své diplomové práce. Větev master byla ponechána jako stabilní. Obraz virtuálního stroje z ní sestavený se tedy používá jako produkční a distribuční verze. Všechny větve by měly být po dokončení vývoje a otestování sjednoceny (operace merge) do větve master. 8

2.2. Distribuce cmp BuildBot Výsledky «flow» Zm ě ny

Master

Řízení

«flow»

Webov ý Serv er

«flow» Repozitá ř

Sestavovací p říkazy

Výsledky

«flow»

«flow»

Zdrojové kódy «flow» Slav e

Slave uzl ů m ů že být libovolný po č et

Obrázek 2.2: Schéma propojení jednotlivých součástí nástroje BuildBot

2.2.2

Původní stav

Pro snadnější seznámení se s projektem byl využit obraz virtuálního stroje. Obraz nefungoval, operační systém nešel spustit a jeho start končil v konzoli initial ramdisku s chybovým hlášením o chybějícím kořenovém systému souborů. Původní odhad o chybě v konfiguraci zavaděče Grub2 se ukázal jako chybný, protože systém obsahoval i druhé (starší) jádro. To podle informací od vedoucího neobsahovalo komponenty Clondike, ale spustit šlo. Po úspěšném startu systému se starším jádrem se objevil druhý problém. Nebylo známo heslo pro žádného uživatele systému. Proto bylo nutné provést reset hesla. K tomuto účelu lze použít parametr init jádra, který umožňuje vstup do tzv. single user režimu, kde systém nevyžaduje přihlášení a automaticky pracuje s nejvyššími oprávněními. Tento parametr lze jádru předat v konfiguraci zavaděče. linux /boot/vmlinuz-2.6.32-5-amd64 \ root=UUID=1e322664-0cc6-46f9-8ca9-a361489b72e0 \ ro proxyfs.server=tcp:0.0.0.0:1112 \ quiet init=/bin/bash Tento řádek konfigurace zavaděče předává jádru několik parametrů: • root - kořenový filesystém je uložen na oddílu určený pomocí UUID, které následuje • ro - filesystém bude po dobu startování systému připojen pouze pro čtení • proxyfs.server - parametr pro komponentu Clondike, na které adrese má projekt očekávat spojení • quiet - nastavuje nejnižší úroveň pro ladící výpisy jádra 9

2. Seznámení s projektem Clodike • init - určuje, který program bude spuštěn jako první po startu jádra Parametr init byl nastaven na /bin/bash, tedy na výchozí příkazový procesor. Tím byl nahrazen standardní spouštěcí proces init, který zajišťuje připojení kořenového systému souborů, jeho přepnutí do režimu umožňujícího zápis, spuštění všech systémových služeb a přihlašovacího programu. To ovšem znamená, že po spuštění příkazového interpreta bash nebude možné zapsat nové heslo do souborů /etc/passwd a /etc/shadow, které obsahují uživatelské údaje. Proto je nutné přepnout kořenový systém souborů do tohoto režimu příkazem: mount -o remount,rw / Pak je již možné použít standardní příkaz passwd pro změnu hesla superuživatele (root). Po následném restartu systému již bylo možné přihlášení s novým heslem. Byla zkontrolována konfigurace obou jader, která se nachází v adresáři /boot, a bylo zjištěno, že všechny potřebné ovladače byly správně nakonfigurovány. Problém spočíval v jejich špatné instalaci. Některé ovladače byly určeny k překladu do podoby modulů. Takové ovladače je třeba po překladu jádra nainstalovat do adresáře /lib/modules//. V systému však chyběly, což byl důvod, proč nebylo možné systém nastartovat.

2.2.3

Analýza problému

V době, kdy byla zahájena práce na projektu Clondike, obsahoval nástroj BuildBot dva podřizené uzly pojmenované PVslave a examle-slave. Oba měly přidělen stejný úkol sestavit virtuální obraz z master větve projektu. Uzel PVslave však podle záznamů nedokončil korektně ani jedno sestavení. Pozornost byla soustředěna na konfiguraci uzlu example-slave. Veškeré informace o úlohách a jejich přiřazení na jednotlivé podřízené uzly jsou uloženy v hlavním konfiguračním souboru nástroje BuildBot. Uzlu example-slave byl přiřazen úkol jménem runtests, který prováděl následující sadu příkazů: • stáhni větev master z repozitáře do složky build/clondike • spusť skript precompile.sh • přelož jádro a jeho moduly • spusť skript cpmodules.sh pomocí nástroje sudo • spusť skript umount.sh pomocí nástroje sudo 10

2.2. Distribuce 2.2.3.1

Skript precompile.sh

Tento skript zařizuje stažení zdrojových kódů jádra 2.6.33.1, které je použito jako výchozí pro stávající verzi Clondike. Následně aplikuje záplatu obsahující specifické úpravy jádra nutné pro korektní běh projektu, nakopíruje zdrojové kódy modulů Clondike a konfigurační soubor jádra. 2.2.3.2

Skript cpmodules.sh

Skript připojí (mount) virtuální obraz systému, do kterého bude Clondike nainstalován, a nakopíruje do něj přeložené jádro a jeho moduly. Dále zajistí překlad a kopírování dalších součástí Clondike, které pracují v uživatelském prostoru (Director, NPFS server). 2.2.3.3

Skript umount.sh

Skript pouze provede odpojení obrazu disku pomocí příkazu umount. 2.2.3.4

Popis problému

Na základě chybového hlášení byla stanovena hypotéza, že chyba je způsobena špatnou instalaci modulů. Po analýze výše uvedených skriptů byla hypotéza potvrzen. Přestože skripty provedou kopii nově přeložených modulů do systému, nedojde při sestavování k vytvoření initial ramdisku. To by samo o sobě nemuselo způsobovat nefunkčnost systému, protože jádro je schopno pracovat i bez něj. Spuštění systému bez initial ramdisku je možné pouze v případě, že jsou všechny potřebné ovladače přeložené přímo do jádra a jádro nepotřebuje žádné další nástroje pro připojení kořenového systému souborů. Ani jedna z těchto podmínek není v případě systému s Clondike splněna, protože zařízení obsahující kořenový systém souborů je určeno pomocí UUID, které jádro neumí zpracovat, a ovladače pro použitý systém souborů jsou přeloženy do podoby modulů. Analýza odhalila další problém, který spočíval v způsobu překladu veškerých komponent Clondike pro uživatelský prostor na serveru. Před překladem žádné komponenty nebylo vyčištěno překladové prostředí od starých objektových souborů a v některých případech ani k překladu nedošlo, protože potřebné příkazy byly zakomentované. To vedlo k používání starých verzí komponent z předchozích sestavení. Navíc v průběhu překladu docházelo i k instalaci některých komponent pomocí příkazu make install, který přeložené komponenty instaloval do složek serveru a nikoliv do obrazu systému.

2.2.4

Náprava

Byl vytvořen nový podřízený uzel se jménem slave_salat, jemuž byla přiřazena nová úloha salat_production. Pro úvodní konfiguraci byla použita 11

2. Seznámení s projektem Clodike kopie úlohy běžící na analyzovaném podřízeném uzlu. Aby nebyl poškozen stávající obraz systému, byla vytvořena jeho kopie pod názvem clondike.vmdk a přesunuta do adresáře virtual v pracovní složce úlohy. Z existujících skriptů byl použit skript precompile.sh beze změn. Příkazy pro sestavení jádra a modulů byly přesunuty z konfiguračního souboru hlavního uzlu do samostatného skriptu build.sh, kde je lze v případě potřeby změnit bez nutnosti zásahu do konfiguračních souborů a jejich nového načítání. Zásadně byl přepracován systém instalace modulů a jádra samotného. Instalace původně probíhala do složek serveru, odkud byla následně kopírována do obrazu systému. Ty pak bylo nutné vymazat ze serveru, aby nemohlo dojít k nežádoucí změně jeho konfigurace. Nyní probíhá instalace přímo do připojeného obrazu systému. K tomu byly použity parametry INSTALL_MOD_PATH a INSTALL_PATH, které určují, kam se při volání make modules_install (resp. make install) provede instalace. Výsledné příkazy pak mají následující podobu: make INSTALL_MOD_PATH=/mnt/vmdk modules_install 2> ../modinst.err make INSTALL_PATH=/mnt/vmdk install 2> ../kerninst.err Cesta /mnt/vmdk je bod připojení obrazu systému. Problém s chybějícími ovladači pro systém souborů byl vyřešen přidáním příkazu pro sestavení initial ramdisku. K tomu slouží nástroj mkinitramfs. Jeho výchozí konfigurace je dostačující a není třeba nic měnit. Příkaz pro jeho spuštění na serveru vypadá takto: chroot /mnt/vmdk /usr/sbin/mkinitramfs 2.6.33.1\ -o /boot/initrd.img-2.6.33.1 Nástroj je nutné spustit v prostředí obrazu systému, protože korektní moduly jsou nainstalovány pouze tam. K tomu slouží nástroj chroot, který použitím stejnojmenného systémového volání změní kořenový adresář pro příkaz předaný jako první parametr a všechny jeho potomky. Vzhledem k povaze obou příkazů je nutné mít oprávnění superuživatele. Pro překlad komponent pracujících v uživatelském prostoru byl vytvořen samostatný skript build-userspace.sh, který je taktéž spouštěn v obrazu systému pomocí změny kořenového adresáře. Překlad a následná instalace tedy probíhá v obrazu systému a tím je zajištěna instalace do správného umístění. Součástí skriptu je i čištění prostředí pro překlad, takže při nekorektní funkci je snažší najít chybu. Během testovacích sestavení se vyskytl problém se zámkem obrazu systému. Nástroj vmware-mount, který je použit pro připojení obrazu systému, vytváří zámek, aby nebylo možné vícenásobně připojit jeden obraz a byla zajištěna konzistence dat. V původních skriptech byl použit standardní systémový příkaz umount pro odpojení obrazu, ten ale neprovede smazání zámku. 12

2.2. Distribuce Přestože toto chování v případě následného připojení způsobí pouze varovné hlášení o existenci zámku, je lepší mu předejít a použít parametr -d pro wmware-mount, který provede korektní odpojení včetně smazání zámku.

13

Kapitola

Ověření funkčnosti obrazu Cílem této kapitoly je ověřit, zda-li provedené změny směřovaly k úspěšnému vyřešení problémů s funkčností obrazu systému s Clondike.

3.1

Popis testovacího prostředí

K ověření funkčnosti systému po provedení všech úprav byl použit virtualizační nástroj VirtualBox 4.3.6 pracující na počítači s následující konfigurací: • 64 bitový systém Windows 7 • Intel Core i5-4670K 3.4GHz (4 fyzická jádra) • 16GB DDR3 operační paměti • 7200 rpm 1TB ST2000VX000-1CU1 SATA2 Seagate pevný disk • plná HW virtualizace Intel VT-x K měření byly použity celkem čtyři virtuální stroje, každý s jedním procesorovým jádrem, 1GB paměti, jednou síťovou kartou v módu vnitřní sítě simulující kartu Intel PRO 1000MT. Každý stroj měl připojenu vlastní kopii obrazu systému získanou z nástroje BuildBot. Měření byla taktéž provedena ve školní laboratoři T9:348, které se přezdívá bourací. Konfigurace tamějších strojů vypadá takto: • Intel Core i5-3470 (4 fyzická jádra) • 8GB DDR3 operační paměti • 7200 rpm 500GB SATA2 Western Digital pevný disk 15

3

3. Ověření funkčnosti obrazu

3.2 3.2.1

Testovací metodika Testovací úloha

Měření probíhalo na úloze překladu staršího jádra 2.6.32.5 s konfiguračním souborem popsaným v práci Ing. Josefa Gattermayera [1] (dále jen referenční práce). V konfiguračním souboru jsou všechny volby vybrané pro překlad přímo do jádra a nikoliv jako samostatných modulů, aby byla omezena časová složitost linkovací fáze. Tato úloha byla vybrána kvůli velkému množství dílčích nezávislých překladových částí, kde je možné plně využít možností paralelního zpracování a zároveň je překladová úloha poměrně časově náročná. Během měření byly migrovány pouze procesy kompilátoru. To je dáno výchozím nastavením projektu Clondike. V závěru kapitoly byly srovnány výsledky tohoto měření s výsledky referenční práce.

3.2.2

Měřené veličiny

Projekt Clondike obsahuje samostatný měřící nástroj, který sleduje celkovou dobu měřené úlohy a pro každý zapojený uzel také minutový průměr zatížení procesoru jak jej měří nástroj uptime[10], okamžité zatížení procesoru a počet aktuálně běžících procesů, které jsou součástí úlohy.

3.2.3

Parametry měření

Měření v referenční práci byla prováděna na strojích s následující konfigurací: • Intel Pentium Processor G6950 (2 fyzická jádra) • 4GB DDR2 operační paměti • 7200 rpm SATA pevný disk (nespecifikovaný výrobce a velikost)

Překlad jádra byl prováděn pomocí příkazu : make -j <pocet_procesu> vmlinux Parametr pocet_procesu byl v referenční práci, po zhodnocení prvotních výsledků, určen pomocí následujího vztahu: pocet_procesu = pocet_uzlu ∗ (pocet_vypocetnich_jader + 1) Tento parametr byl při měření zachován za účelem možnosti porovnání výsledků. 16

3.2. Testovací metodika

3.2.4

Odvozené hodnoty

Ná základě měření byly vypočítány a porovnány hodnoty zrychlení a efektivity, získané pomocí vztahů uvedených níže. [11] Zrychlení: S(n, p) =

T0 (n) T (n, p)

E(n, p) =

S(n, p) p

Efektivita:

3.2.5

Instalace

Obě měření byla prováděna pomocí stejného obrazu systému získaného po provedení všech úprav popsaných v této práci z nástroje BuildBot, který jej sestavil z Git repozitáře z větve salat-prod. V případě měření virtualizačním nástrojem byl virtuální disk nakopírován pro každý stroj zvlášť. V případě měření v bourací učebně byla instalace složitější. Na cílovém stroji byla spuštěna živá linuxová distribuce z USB disku. Distribuce obsahovala nainstalované nástroje VMWare pro správu virtuálních disků. Následně bylo provedeno připojení obrazu systému s projektem Clondike a jeho následné překopírování na pevný disk stroje pomocí nástroje dd. Po dokončení kopírování byl stroj restartován, odpojen USB disk a proveden test funkčnosti překladu testovací úlohy. Použitá metoda instalace je zdlouhavá pro použití na více strojů a proto byl k distribuci systému na další stroje použit nástroj, který je dostupný na strojích učebny. Ten umožňuje nahrát obsah disku na server, ze kterého lze obraz nainstalovat do libovolného stroje v učebně. Nahrává se vždy od začátku disku do konce prvního oddílu a obraz je komprimován pro úsporu místa na serveru a snížení objemu přenášených dat. Z toho důvodu je vhodné v systému nahradit volný diskový prostor nulami k dosažení lepší úrovně komprese. Za tímto účelem byl použit nástroj dd: dd if=/dev/null of=/nuly Po spuštění příkazu došlo k vytvoření souboru nuly, který obsahoval pouze nuly a postupně zaplnil veškeré volné místo na disku. Po jeho smazání byl systém připraven k nahrání obrazu na server. Ostatní stroje použité k měření byly nainstalovány pomocí nástroje učebny. 17


3.3

Oprava serveru NPFS

Během testování se vyskytovala chyba v serveru NPFS, který je používán při sdílení souborů mezi stroji. Při prvním pokusu o migraci docházelo k chybě Segmentation fault a následnému pádu aplikace. Chybu bylo velmi obtížné identifikovat, protože ladící nástroje vykazovaly v průběhu ladění nestandardní skoky mezi příkazy a překladač generoval velké množství varovných hlášení. Mezi hlášeními se vyskytovala následující dvojice: socksrv.c:212:3: warning: implicit declaration of function ‘np\_fdtrans\_create\_tcp’ socksrv.c:212:9: warning: assignment makes pointer from integer without a cast [enabled by default] trans = np_fdtrans_create_tcp(csock, csock); První varování hlásilo, že funkce np_fdtrans_create_tcp nebyla deklarována a překladači tedy není znám její prototyp. Překladač předpokládá, že návratová hodnota funkce je typu integer (celé číslo se znaménkem). Druhé varování upozorňovalo na přiřazení datového typu integer do proměnné, která je typu ukazatel, bez explicitního přetypování. Protože překlad probíhal pro 64 bitový systém, má datový typ integer velikost 4B a ukazatel 8B. Navíc ukazatel na rozdíl od integeru není znaménkový typ. Překladač před přiřazením do proměnné trans musí provést znaménkové rozšíření. Funkce np_fdtrans_create_tcp provádí alokaci paměti pro objekt a jeho adresu předává jako svou návratovou hodnotu. Kdykoliv je alokovaná paměť umístěna do virtuální paměti na hranici 2 GB (adresy 0x80000000 a vyšší) dojde při znaménkovém rozšíření k poškození předávané hodnoty a tím pádu aplikace, protože horní polovina adresního prostoru je vyhrazena pro prostor jádra [12]. Oprava spočívala ve vytvoření hlavičkového souboru, ve kterém byly uvedeny všechny chybějící deklarace.

3.4

Upgrade knihovny Netlink

Při měření se vyskytovala chyba, kdy i přes fakt, že byly stroje navzájem propojeny, nebyl systém schopen na některé uzly migrovat. V záznamech bylo nalezeno hlášení o chybě při čtení z netlink socketu, který je použit pro komunikaci mezi jádrem a uživatelským prostorem. V uživatelském prostoru byla použita knihovna libnl ve verzi 1 a aktuální stabilní verze má dle stránek projektu číslo 3. Rozhodl jsem se tedy provést upgrade na tuto verzi. Verze 3 není dostupná pro Debian v podobě balíčku a bylo nutné ji instalovat ze zdrojových kódů. Překlad této knihovny má několik prerekvizit, které nebyly v systému přítomny a bylo třeba je doinstalovat. Jednalo se o nástroje flex a bison, které jsou dostupné z repozitářů. Po stažení kódů nové 18

3.5. Úpravy Simple Ruby Directoru verze knihovny libnl byla provedena konfigurace, kterou bylo určeno umístění výsledných binárních souborů do složky /usr/lib: ./configure --prefix=/usr --sysconfdir=/etc Následoval překlad a instalace: make && make install Dále bylo nutné v Makefile souborech zajistit změnu cest k hlavičkovým a binárním souborům nové knihovny a její linkování. K tomu slouží přepínač -I pro hlavičkové a -L pro binární soubory. Knihovna libnl od verze 2 umožňuje koexistenci více verzí v jednom systému a proto byl upraven i přepínač linkované knihovny na -lnl-3, aby bylo zajištěno použití správné verze. Mezi verzemi 1 a 3 došlo ke změně aplikačního rozhraní. Byla změněna struktura, která udržuje identifikátor socketu používaného při komunikaci, a jména některých funkcí. Vzhledem ke kvalitnímu návrhu byly všechny změny lokalizované do jediného souboru director-api.c. Detailní popis jednotlivých změn není třeba uvádět. Ani nová verze knihovny neměla kýžený dopad na kvalitu měření a bylo nutné provést další změny.

3.5

Úpravy Simple Ruby Directoru

Na základě faktu, že spojení mezi prvky existovalo a podle výpisu z komponenty TCMI bylo stabilní, byla k další analýze určena komponenta Simple Ruby Director (dále SRD). Během důkladného prostudování záznamů z neúspěšných měření nebylo nalezeno žádné chybové hlášení, které by ukazovalo na možnou příčinu nežádoucího chování. Z toho důvodu byla provedena kontrolu algoritmů na vyvažování zátěže, které jsou zodpovědné za rozhodování, které procesy budou migrovány a na jaký uzel. Současná implementace obsahuje 4 vyvažovací algoritmy rozhodující na základě následujících faktorů: • náhodný • zatížení CPU • počet úloh • pořadí uzlů Je možné, že algoritmus nebude schopen vybrat uzel pro migraci, a proto byl SRD implementován tak, že v případě potřeby je možné jednotlivé algoritmy řetězit do komplexnějších celků a tím vytvořit nový mechanismus, který bude vhodnější pro konkrétní problém. 19


3.5.1

Náhodné vyvažování

Náhodné vyvažování je nejjednodušším typem vyvažování. Tento algoritmus je uložen v souboru RandomBalancingStategy.rb a určuje cílový uzel pomocí volání Ruby funkce rand. Tato funkce náhodně vybírá z připojených uzlů včetně lokálního. Je tedy možné, že bude rozhodnuto o ponechání procesu na lokálním uzlu.

3.5.2

Vyvažování dle zatížení CPU

Při použití tohoto vyvažovacího algoritmu, je pevně stanovena hranice 95% zatížení CPU. Algoritmus se nachází v souboru CpuLoadBalancingStrategy.rb. Pokud je tato hranice překročena na lokálním stroji, algoritmus přistoupí k výběru uzlu kam bude provedena migrace. Výběru vhodného uzlu obsahoval chybu v hodnotící metrice uzlů. Uzly byly vybírány na základě vyššího zatížení, což by vedlo ke zvyšování zátěže na určitém uzlu. Byla provedena úprava, která násobí zatížení -1 a tudíž platí, že migrace bude provedena na nejméně zatížený uzel.

3.5.3

Vyvažování dle pořadí uzlů

Tento algoritmus používá index uzlu k určení pořadí v jakém mu bude přidělena úloha v případě rozhodnutí o migraci. Jeho kód je uložen v souboru RoundRobinBalancingStrategy.rb. Pokud je úloha migrována na poslední uzel v pořadí, následující úloha bude migrována na první. V SRD lze určit, zda-li bude použita varianta počítající i s lokálním uzlem nebo nikoliv.

3.5.4

Vyvažování dle počtu úloh

Vyvažování dle počtu úloh se opírá se o dvě základní hodnoty: • minimální počet lokálních úloh • maximální počet úloh na ostatních uzlech Zdrojový kód je uložen v souboru QuantityLoadBalancingStrategy.rb. V tomto algoritmu bylo provedeno nejvíce změn, protože jeho výsledky neodpovídaly požadavkům na rovnoměrné rozložení počtu úloh mezi všechny uzly. V původním algoritmu se počet úloh ponechaných lokálně určoval pomocí proměnné udržující hodnotu minimálního počtu procesů spuštěných na lokálním uzlu. Tato hodnota byla určena na základě celkového počtu jader všech CPU lokálního uzlu. Hodnota minima byla rovna součtu jader na lokálním uzlu. Algoritmus se pokusí o migraci pokud počet procesů běžících na lokálním uzlu překročí hodnotu minima. Na základě měření provedených v předchozích pracích [1] byla tato hodnota navýšena o jedna, protože umožňuje efektivnější využití výpočetních prostředků. Tato hodnota je používána jen jako výchozí. 20

3.5. Úpravy Simple Ruby Directoru Pro účely vyvažování je určena funkce getCurrentLocalMinimum, která byla definována definována takto: def getCurrentLocalMinimum() remoteCount = @counter.getRemoteCount(@nodeRepository.selfNode) return 0 if ( remoteCount > 3 && @membershipManager.coreManager.detachedNodes.size > 2 ) return @defaultMinimumTasksLocal end Návratová hodnota funkce byla rovna nule, pokud počet uzlů v klastru byl větší než dva a zároveň počet úloh běžících na ostatních uzlech byl vyšší než tři. To mělo za následek vyšší zatížení vzdálených uzlů. Z toho důvodu byla funkce upravena takto: def getCurrentLocalMinimum() # if nodes become overloaded more tasks than minimum over_cnt = 0 @membershipManager.coreManager.detachedNodes.each { |node| next if !node over_cnt += 1 if @counter.getCount(node) > @minimumTasksRemote } # when all nodes are overloaded if ( @membershipManager.coreManager.detachedNodes.size == over_cnt ) # compute average number of tasks per node total = @counter.getRemoteCount(@nodeRepository.selfNode) + @counter.getCount(@nodeRepository.selfNode) average = total / ( 1 + over_cnt) return average + 1 end return @defaultMinimumTasksLocal end Po úpravě funkce kontroluje, zda-li nejsou vzdálené uzly přetížené (tj. počet úloh, které zpracovávají je vyšší než maximum). Pokud jsou přetížené všechny, dojde k navýšení maxima pro vzdálené uzly na hodnotu průměru napříč všemi uzly v klastru (včetně lokálního) a tato hodnota je zároveň použita jako minimum pro lokání uzel. Proměnná udržující hraniční hodnotu pro maximální počet úloh na jednotlivých uzlech byla poměrně zmatečně pojmenována minimumTasksRemote a její hodnota byla nastavena na 200. Uzel byl vyřazen ze skupiny uzlů na něž 21

3. Ověření funkčnosti obrazu byla povolena migrace, pokud jeho okamžitý počet úloh překročil tuto hodnotu. Proměnnou byla přejmenována na maximumTasksRemote a její hodnota nastavena shodně s minimálním počtem lokálních úloh. Touto změnou nemůže dojít k přetěžování díky změnám provedeným ve funkci getCurrentLocalMinimum a faktu, že pokud jsou všechny uzly přetížené a nelze vybrat vhodný uzel k migraci, je použit algoritmus vyvažující dle pořadí uzlů. Tím je dosaženo rovnoměrného rozdělení úloh mezi uzly.

3.5.5

Úprava datových typů

Po provedení všech změn a vylepšení ve vyvažovacích algoritmech bylo provedeno nové měření. Tentokrát bylo přidáno několik ladících výpisů pro lepší přehled o operacích, které probíhají v rámci vyvažování zátěže. Ladící výpisy ukázaly, že pokud neprobíhá migrace korektně, je důvod v chybějících statistických informacích o jednotlivých uzlech. Tyto informace jsou uloženy v objektu NodeInfo. Tento objekt je součástí objektu Node, který udržuje veškeré informace o uzlech. Během hledání místa původu této chyby byla objevena další potenciální příčina problému s migrací. Šlo o způsob jakým se pracovalo s instancemi objektů Node při zpracování určitého druhu zpráv. Problém byl ve funkci handleFrom objektu PublicKeyDisseminationMessageHandler. def handleFrom(message, from) node = Node.new message.nodeId, from.ipAddress @nodeRepository.addOrReplaceNode node end Ta vytvářela novou instanci objektu Node při zpracování zprávy a tím docházelo k zahození obsahu struktury NodeInfo, protože konstruktor objektu Node provádí inicializaci na hodnotu nil, neboli nulový ukazatel. Funkce byla opravena následujícím způsobem: def handleFrom(message, from) @nodeRepository.getOrCreateNode message.nodeId, from.ipAddress end Po úpravě se funkce pokusí získat instanci požadovaného objektu z repozitáře a pokud neexistuje, vytvoří se instance nová. ¨ Tato změna vedla k odhalení chyby v datových typech¨. Uvozovky jsou uvedeny, protože Ruby je dynamický programovací jazyk a jediným datovým typem je objekt. Chyba způsobovala hlášení o pokusu o připojení se špatným parametrem. V ukázce je uvedena i správná varianta hlášení. # špatně: Cannot connect to #(NetworkAddress:0x0000006F4A2B007A) 22

3.6. Výsledky měření # správně: Cannot connect to 192.168.0.10 NetworkAddress je objekt, který udržuje informace o IP adrese a portu. Používá se při předávání informací o zprávách. SRD používá pro identifikaci uzlu jeho IP adresu. V jediném případě byla místo IP adresy použita instance objektu NetworkAddress. To nastávalo ve funkci handleFrom objektu InformationDistributionStrategyMessageHandler. Po opravě se špatná hlášení už neobjevila a byla tím opravena i chyba s chybějícími informacemi o uzlech.

3.6

Výsledky měření

3.6.1

Virtuální prostředí

Při měření bylo použito virtuální prostředí pro testování základní funkčnosti systému, klastru a reakce na prováděné změny. Díky tomu byla nalezena chyba serveru NPFS popsaná v kapitole 3.3. Graf 3.1 zobrazuje závislost doby výpočtu testovací úlohy na počtu připojených uzlů. Navzdory znatelnému zpomalení při zapojení druhého uzlu je toto chování pochopitelné, protože výkon virtuálních strojů je silně závislý na zatížení hostitelského stroje. Navíc soubory udržující obsah pevných disků virtuálních strojů byly umístěné na stejném pevném disku hostitelského stroje, což způsobuje značné snížení výkonu jednotlivých strojů v okamžiku, kdy běží všechny najednou. Navzdory tomu bylo virtuální prostředí neocenitelným pomocníkem při hledání závad a validaci výsledků oprav. Po ověření základních funkcí bylo zahájeno měření v bourací laboratoři.

3.6.2

Bourací laboratoř

V bourací laboratoři byly naměřeny výsledky pro jeden až sedm uzlů. Více strojů se propojit nepodařilo, protože docházelo k chybám ve dvou komponentách: • TCMI - funkce tcmi_comm_thread • Simple Ruby Director - v autentifikaci uzlů V případě SRD docházelo k vypršení časového kvanta určeného pro dokončení autentizace a v případě TCMI jmenovaná funkce blokovala své vlákno na dobu delší než 120s, což je standardní limit linuxového jádra po němž dojde k zobrazení chybového hlášení. Toto blokování je pravděpodobně způsobeno funkcí kkc_sock_recv provádějící příjem dat ze socketu, která je volána funkcí tcmi_comm_thread s parametrem požadujícím blokující mód příjmu dat. Pokud je požadovaná velikost dat větší, než kolik bylo odesláno, funkce bude 23


Doba výpočtu [s]

Závislost doby výpočtu na počtu uzlů 2100 2040 1980 1920 1860 1800 1740 1680 1620 1560 1500 1440 1380 1320 1260 1200 1140

Doba výpočtu 1

2

3

4

Počet uzlů

Obrázek 3.1: Výsledky měření doby výpočtu testovací úlohy za použití měřícího nástroje ve virtuálním prostředí

blokovat dokud nepřijme všechna požadovaná data nebo nenastane chyba v komunikačním protokolu. Komponenta KKC používá komunikační protokol TCP, jehož parametr tcp_retries2 určuje, kolikrát bude odeslán paket, než systém ohlásí chybu. Manuálové stránky protokolu TCP (tcp(7))[13] uvádí výchozí hodnotu tohoto parametru rovnou 15, což spolu s doporučeným časovým limitem 100s pro odeslání zprávy dle RFC 1122 [14] určuje 25 minutový interval, po který čeká vlákno na dokončení přenosu. Zdroj této chyby se nepodařilo odhalit kvůli komplexnosti komponenty TCMI a synchronizačnímu charakteru chyby.

3.6.3

Původní stav

V této kapitole bylo popsáno několik úprav, kterými byla vyřešena počáteční nefunkčnost klastru a pomocí kterých byl upraven celkový výkon. První měření bylo provedeno pomocí měřícího nástroje integrovaného v Clondike. Protože doba výpočtu testovací úlohy narůstala s rostoucím počtem připojených uzlů, byla provedena analýzu možných problémů. V referenční práci nebyl použit měřící nástroj, protože v době publikace práce projekt Clondike tento nástroj neobsahoval. Z toho důvodu bylo rozhodnuto provést zkušební měření bez tohoto nástroje pro ověření, zda má nástroj vliv na výsledky měření. Graf 3.2 zobrazuje dobu výpočtu testovací úlohy bez použití měřícího nástroje. Čas byl měřen standardním linuxovým nástrojem time a v grafu je zanasena hodnota real, udávající dobu reálně strávenou výpočtem úlohy. 24

3.6. Výsledky měření

Závislost doby výpočtu na počtu uzlů (bez měřícího nástroje) 330

Doba výpočtu

320

Doba výpočtu [s]

310 300 290 280 270 260 250 240 230

1

2

3

4

5

6

7

Počet uzlů

Obrázek 3.2: Výsledky měření doby výpočtu testovací úlohy bez použití měřícího nástroje

Z grafu zřetelně vyplývá zvýšení doby výpočtu při zapojení více jak třech uzlů. To bylo způsobeno chybou SRD, konkrétně vyvažovače zátěže. Tato chybu byla popsána a opravena v kapitole 3.5.4.

3.6.4

Stav po změnách

Po provedení všech dříve uvedených úprav, byly naměřeny nové hodnoty, tentokrát pomocí měřícího nástroje, pro ověření správnosti úprav a porovnání s referenční prací. 3.6.4.1

Doba výpočtu

V grafu 3.3 je znázorněna doba výpočtu testovací úlohy pro jednotlivé počty uzlů. Z průběhu vyplývá, že chyba způsobující nárůst doby výpočtu pro čtyři a více uzlů byla úspěšně odstraněna. V porovnání s referenční prací znatelně poklesla doba výpočtu. To je dáno rozdílnými parametry výpočetních prostředků. 3.6.4.2

Zatížení procesoru

V grafu 3.4 je zanesen průběh minutového průměru zatížení procesoru na jednotlivých uzlech. Z grafu vyplývá, že lokální uzel vykazuje vyšší zatížení než vzdálené uzly, což je způsobeno dodatečnou zátěží vzniklou v SRD, který 25


Závislost doby výpočtu na počtu uzlů 300

Doba výpočtu

290

Doba výpočtu [s]

280 270 260 250 240 230 220 210 200

1

2

3

4

5

6

7

Počet uzlů

Obrázek 3.3: Výsledky měření doby výpočtu testovací úlohy za použití měřícího nástroje

hledá vhodné uzly k migraci a sbírá veškeré statistiky, a také faktem, že měření migruje pouze procesy kompilátoru, takže linkování a další operace obstarává lokální uzel. V referenční práci byly rozdíly v zatížení mezi vzdálenými uzly velmi malé, ale lokální uzel na rozdíl od naměřených výsledků vykazoval nejmenší zatížení ze všech zapojených uzlů. To je způsobeno úpravami vyvažovacích algoritmů, které nyní mírně preferují lokální uzel, aby se omezila režie způsobená migrací. Lepší náhled na zatížení lokálního uzlu přináší graf 3.5, kde lze pozorovat 100% zatížení lokálního uzlu s malými odchylkami po celou dobu měření. Plné zatížení reflektuje velikost režie migrace. To dokládá graf 3.6, do kterého byl zanesen průběh počtu procesů náležících testovací úloze běžících na jednotlivých uzlech po dobu měření. Očekávaný počet procesů na jednom uzlu v každém okamžiku byl roven pěti, což je dáno nastavením vyvažovače zátěže. Na základě grafu lze toto očekávání potvrdit.

26

3.6. Výsledky měření

Zatížení procesoru v čase 20

Zatížení [%]

15

10

5

0 00:00

00:30

01:00

01:30

02:00

02:30

03:00

03:30

Čas [min:sek] Lokální Uzel Server 1 Server 2

Server 3 Server 4 Server 5

Server 6

Obrázek 3.4: Výsledky měření zatížení procesoru (minutový průměr) jednotlivých uzlů

Zatížení procesoru v čase (okamžité) 100

Zatížení [%]

80 60 40 20 0 00:00

00:30

01:00

01:30

02:00

02:30

03:00

03:30



Server 6

Obrázek 3.5: Výsledky měření zatížení procesoru (okamžité) jednotlivých uzlů

27


Počet procesů na jednotlivých uzlech 6

Počet procesů

5 4 3 2 1 0 00:00

00:30

01:00

01:30

02:00

02:30

03:00

03:30



Server 6

Obrázek 3.6: Výsledky měření počtu procesů na jednotlivých uzlech

3.6.4.3

Odvozené hodnoty

V tabulce 3.1 jsou uvedeny vypočtené hodnoty zrychlení a efektivity pro jednotlivé počty připojených uzlů. V porovnání s referenční prací bylo dosaženo výrazně nižších hodnot u obou veličin. Práce uvádí hodnotu zrychlení 1,67 s efektivitou 83% při zapojení dvou uzlů a 2,35 s efektivitou 58% při zapojení čtyř uzlů. Důvodem pro tyto rozdíly jsou jisté závislosti mezi překládanými soubory a kratší čas výpočtu. Tabulka 3.1: Zrychlení a efektivita v závislosti na počtu uzlů Počet Uzlů Zrychlení Efektivita [%]

3.6.5

2 1,097 0,548

3 1,194 0,398

4 1,277 0,319

5 1,392 0,278

6 1,392 0,232

7 1,425 0,204

Vyhodnocení

Z výše uvedených grafů a porovnání průběhů s referenční prací vyplývá, že došlo ke zlepšení vlastností vyvažovače zátěže, díky kterým systém škáluje i pro sedm připojených uzlů. V referenční práci byly rozdíly v době výpočtu mezi pěti a sedmi připojenými uzly minimální. Pozorované přetížení lokálního uzlu však není žádoucí a jeho odstranění by přispělo k dalšímu zkrácení doby výpočtu.

28

Kapitola

ProxyFS 2 Systém souborů ProxyFS 2 je samostatný ovladač pro systém Linux, který slouží ke sdílení souborů, sdílené paměti a synchronizačních prvků jako např. semafory. Ke komunikaci používá protokol SCTP, který je standardně dostupný jádře. Tento protokol byl vytvořen skupinou IETF (The Internet Engineering Task Force) pro účely přenosu telefonní signalizace, z čehož vyplývá několik vlastností, které jsou vhodné pro použití v ProxyFS 2. Jednou z nich je dodržování hranice zpráv a doručení zprávy jako celku nebo signalizace nedoručení. Dále protokol umožňuje vytváření tzv. asociací, což jsou spojení jednoho stroje s více uzly využívající pouze jednoho soketu. To zjednodušuje obsluhu příjmu zpráv, protože není nutné pro každý uzel používat samostatné vlákno obsluhující komunikaci. Přesto lze v případě potřeby z asociace spoj oddělit a připojit ho pomocí nového socketu a tím využít vícevláknového zpracování. ProxyFS 2 zprostředkovává sdílené prostředky jako soubory virtuálního systému souborů s cestou:

/peer/id_uzlu/id_prostredku

ID uzlu je získáno pomocí kódování jeho jména a adres do slova s abecedou obsahující 64 tisknutelných ASCII znaků. Jméno uzlu je určeno unikátním 64bitovým identifikátorem, jehož jedinečnost je kontrolována při připojení. Spojení, které by tuto vlastnost narušilo, je odmítnuto. Identifikátor je následován všemi síťovými adresami uzlu. Toto kódování funguje oboustranně. ID prostředku je generováno stejným způsobem a jedinečnost je zajištěna v rámci uzlu. ProxyFS 2 obsahuje celkem tři rozhraní pro komunikaci s modulem: rozhraní pro uživatelský prostor, pro prostor jádra a rozhraní pro virtuální systém souborů (VFS). 29

4

4. ProxyFS 2

4.0.6

Rozhraní pro uživatelský prostor

Toto rozhraní je určeno pro programy vytvářené v uživatelském prostoru. K modulu se přistupuje pomocí systémového volání ioctl(), které se obecně používá pro nastavování parametrů ovladačů [15]. Volání ioctl má následující prototyp: int ioctl( int fd, unsigned long request, ... ); kde fd je popisovač souboru, který slouží pro komunikaci s ovladačem a request je kód příkazu (resp. požadavku) za nímž následují volitelné parametry. Jedinou operací, kterou lze v ProxyFS 2 pomocí tohoto volání provést, je export prostředku. Za export je považováno předání prostředku do správy ovladači. Obsahuje tři příkazy, určující jaký typ prostředku bude exportován: • PROXYFS_EXPORT_FILE - provede export otevřeného souboru s daným popisovačem (file descriptor) • PROXYFS_EXPORT_SHM - provede export vytvořené sdílené paměti určené adresou • PROXYFS_EXPORT_SEM - provede export všech semaforů volajícího procesu K předávání parametrů a návratové hodnoty slouží struktury se jménem control_file_export_*_s, kde je hvězdičkou nahrazeno označení typu prostředku (file, shm, sem). Návratovou hodnotou je 64 bitový identifikátor prostředku.

4.0.7

Rozhraní pro prostor jádra

Rozhraní pro prostor jádra bylo navrženo tak, aby kopírovalo funkcionalitu rozhraní pro uživatelský prostor a k tomu byly určeny funkce proxyfs_export_*, ale dle provedené analýzy zdrojových kódů nebyla implementace provedena.

4.0.8

Rozhraní VFS

Jádro obsahuje ovladač VFS, který slouží pro jednotný přístup k různým souborovým systémům. Je tak možné mít v rámci jednoho adresářového stromu připojeno několik souborových systémů, kde každý může používat svůj způsob přístupu k datům. Souborové systémy lze chápat konvenčním způsobem jako organizaci dat uložených na fyzické médium, anebo jako strukturovaná data, která fyzicky vůbec nemusí existovat a jsou generována v okamžiku požadavku na jejich čtení. Mezi první skupinu patří systém souborů ext3, který je použit pro 30

4.1. Stav implementace ukládání souborů v obrazu systému obsahující Clondike. Druhou skupinu reprezentuje systém souborů procfs, který poskytuje informace o procesech běžících v systému. Tato data nejsou nikde fyzicky uložená, ovladač je generuje při požadavku na čtení. ProxyFS 2 využívá tohoto rozhraní pro přístup ke sdíleným prostředkům.

4.1

Stav implementace

Zdrojové kódy ProxyFS 2 nebyly dostupné v GIT repozitáři projektu a byly získány z CD přiloženého k diplomové práci a jedná se jediný exemplář. ProxyFS 2 byl navržen a implementován pro jádro 2.6.28 a později upraven pro jádro 2.6.31. Vyjma zmíněného chybějícího rozhraní pro prostor jádra byla implementace úplná tak, jak je popsána v diplomové práci. Autor v práci nedokumentoval požadované parametry pro modul ovladače ani předpokládaný postup k úspěšnému exportování prostředku a jeho využití na vzdáleném uzlu. Tyto informace byly získány analýzou zdrojových kódů a testováním. Při testování a pokusech s ProxyFS 2 bylo objeveno několik faktů, které bránily jeho použití. Testování proběhlo pomocí stejného obrazu systému jako v případě měření výkonosti klastru. Ten však obsahuje novější verzi jádra 2.6.33.1, která není plně zpětně kompatibilní a přestože se podařilo ovladač pro novější jádro přeložit a zavést, při pokusu o získání exportovaného souboru docházelo k pádu celého jádra. Po úpravě zdrojových kódů na novější verzi API jádra toto chování zmizelo. Ovladač ke své činnosti potřebuje dva parametry. První určuje adresu, na které bude naslouchat příchozím spojením. Jeho jméno je listen_on, datový typ je řetězec znaků a adresa má formát IP_addr:port. Při testování byla použita hodnota 0.0.0.0:1113, která způsobí naslouchání na všech adresách, které jsou stroji přiřazené. Za zmínku stojí rozdíl oproti implementaci komponenty ProxyFS v současné verzi projektu, která ke komunikaci používá komponentu KKC a formát adresy má tvar protokol:addr:port. Druhým parametrem je worker_count, jehož typ je celé číslo bez znaménka (unsigned int) a udává počet vláken, které budou zpracovávat požadavky klientů. Tento parametr má výchozí hodnotu rovnou čtyřem. Navíc samostatný soubor Makefile, který byl k ovladači přiložen nebyl funkční. Ovladač v něm byl nastaven k překladu do podoby modulu. Ovladač používá mnoho funkcí jádra, jejichž symboly nejsou exportované a nelze je využívat v kódu, který není přímo zakompilován do jádra. Zde se nabízela dvě možná řešení. Buď upravit zdrojové kódy jádra tak, aby byly potřebné symboly exportovány a nebo překonfigurovat Makefile tak, aby zařadil ovladač ke kompilaci přímo do jádra. Nakonec bylo vybráno druhé řešení, protože je z programátorského hlediska čistější. Zvolené řešení však přineslo další komplikaci v podobě pořadí spouštění inicializační funkce ovladače. Při prvním úspěšném překladu byly zdrojové 31

4. ProxyFS 2 kódy ovladače umístěny do složky clondike/ v adresářovém stromu jádra a soubor Makefile jádra byl upraven tak, aby zařadil ovladač ke kompilaci spolu s ostatními ovladači (cíl drivers). Po spuštění systému s ovladačem se objevilo ladící hlášení, že inicializace ovladače se nezdařila. Hlášení bylo stručné a nedalo se z něj přesně určit místo selhání. Do zdrojových kódů bylo přidáno množství ladících výpisů, s jejichž pomocí a po prostudování inicializačních funkcí bylo identifikováno místo výskytu chyby na inicializaci socketu pro komunikaci. Její návratová hodnota indikovala neznámý komunikační protokol. Následně byla provedena kontrola konfigurace jádra pro ujištění, že je požadovaný protokol SCTP skutečně zařazen do jádra. Konfigurace byla provedena správně. Problém spočíval v již zmíněném pořadí volání inicializačních funkcí. Protože je cíl drivers uveden v souboru Makefile před cílem net, který mimo jiné obsahuje také protokol SCTP, byla inicializace ovladače ProxyFS 2 volána před inicializací ovladače SCTP. Z toho důvodu selhávala inicializace ProxyFS 2. V době jejího volání ještě nebyl protokol SCTP v jádře zaregistrován a nebylo možné jej používat. Dočasným řešením tohoto problému bylo přesunutí zdrojových kódů ProxyFS 2 do složky net/proxy2 a úprava konfigurace cíle net tak, aby bylo ProxyFS 2 překládáno až po SCTP. Sestavovací nástroj tak zařadí inicializační funkci ProxyFS 2 až po SCTP. Toto chování sestavovacího nástroje není dokumentováno a nelze se na něj spoléhat pro produkční nasazení. Jádro poskytuje možnost zvolení úrovně, do které ovladač patří. První inicializační funkce z dané úrovně se zavolá až v okamžiku, když jsou dokončeny všechny funkce z úrovně předchozí. Toto řešení je lepší a je vhodné pro produkční nasazení. Pořadí úrovní od nejnižší je: • core - základní součásti jádra • postcore - důležité součásti jádra závislé na ovladačích z předešlé úrovně • arch - ovladače specifické pro architektury • subsys - ovladače subsystémů (např. USB) • fs - ovladače souborových systémů • rootfs - inicializace kořenového systému souborů • device - ovladače zařízení • late - ostatní SCTP k registraci své inicializační funkce stejně jako ProxyFS 2 používá funkci module_init, která registruje do úrovně device. K přesunutí do vyšší úrovně (pozdější inicializace) je potřeba změnit registrační funkci inicializační funkce z module_init na late_initcall. 32

4.2. Srovnání s aktuálním stavem Test funkčnosti byl proveden pomocí dvou strojů exportováním souboru na prvním stroji pomocí testovacího programu filetest dostupného ve zdrojových kódech ProxyFS2. Program byl upraven tak, aby po exportu počkal na stisk klávesy a nezavíral popisovač exportovaného souboru, protože v okamžiku uzavření popisovače je export ukončen. Následně byl z ladících výpisů získán identifikátor exportovaného prostředku. Na vzdálen stroji byla sestavena kompletní cesta k exportovanému prostředku a ten byl pomocí nástroje cat otevřen. Z výše uvedeného lze odvodit postup pro export a migraci prostředku. Mějme stroje A a B, stroj A vlastní prostředek k exportování a stroj B jej chce použít. Stroj A musí prostředek otevřít (soubor) nebo vytvořit (sdílená paměť, semafor) a vypsat identifikátor, pod kterým je reprezentován v ProxyFS 2. Stroj B pak pomocí otevření souboru reprezentujícího prostředek s daným identifikátorem získá přímo popisovač souboru nebo ProxyFS 2 zařídí registraci prostředku jako by byl vytvořen na stroji B.

4.2 4.2.1

Srovnání s aktuálním stavem Plan 9 a NPFS

Síťový protokol Plan 9 byl vytvořen pro stejnojmenný distribuovaný operační systém vytvořený společností BelLabs [6]. Jeho cílem bylo zajistit sdílení prostředků napříč uzly, na nichž systém běžel. V projektu Clondike je sdílení souborů vyřešeno pomocí serveru využívajícího knihovnu NPFS [7], která implementuje protokol Plan 9 dle specifikace 9P2000. Stejné jméno nese i systém souborů, který v Linuxu zprostředkovává přístup ke sdíleným prostředkům [16]. Samotný server NPFS je schopen sdílet pouze obyčejné soubory. Speciální soubory jako jsou např. roury jsou sdíleny pomocí komponenty ProxyFS. Při migraci procesu mezi uzly, dojde na původním stroji k získání všech jmen souborů, které jsou aktuálně otevřeny. Po přesunutí všech informací a struktur reprezentující migrovaný proces je na straně cílového uzlu provedeno připojení celého kořenového systému souborů původního uzlu. Komponenta TCMI přesune migrovaný proces do prostředí chroot v místě připojení systému souborů původního uzlu. Soubory, které byly otevřeny v době migrace, jsou znovu otevřeny na cílovém stroji, aby byla zachována platnost popisovačů souborů.

4.2.2

Specifikace kritérií

Cílem této kapitoly je revize dosažené úrovně implementace práce Ing. Maláta a měření nárůstu výkonu oproti původnímu stavu. Protože ovladač ProxyFS 2 nebyl autorem doveden do stavu, který umožňuje nasazení do projektu Clondike a naměření testovací úlohy, bylo provedeno porovnání obou metod sdílení 33

4. ProxyFS 2 prostředků a vyhodnoceno, zda-li je výhodnější zůstat u stávající implementace nebo upravit ProxyFS 2 a zařadit jej do Clondike. Pro porovnání byla vybrána tři kritéria. Prvním kritériem při porovnávání obou řešení byl počet dostupných operací se soubory. Zvolené řešení musí podporovat minimálně množinu souborových operací umožňující otevření, čtení, zápis, posun ukazatele, volání ioctl a uzavření souboru. Druhé kritérium byla bezpečnost informací uložených na uzlech. Cílový uzel by měl mít přístup pouze k souborům, které nutně potřebuje ke své činnosti. Třetí kritérium bylo množství funkcí, které řešení nabízí.

4.2.3 4.2.3.1

Porovnání obou metod Dostupné souborové operace

V předchozích kapitolách byl popsán způsob sdílení souborů u obou řešení. Využití protokolu 9P a serveru NPFS v současné implementaci uspokojuje požadavek na podporované souborové operace. ProxyFS 2 podporuje pouze čtení, zápis, posun ukazatele a volání ioctl. Z toho plyne zásadní nevýhoda ProxyFS 2. Není možné otevřít soubor, který se nachází na vzdáleném počítači. Z tohoto hlediska je ProxyFS 2 nedostatečný. 4.2.3.2

Bezpečnost informací

Současné řešení při migraci souborů připojuje celý kořenový souborový systém zdrojového uzlu. Toto připojení je dostupné po celou dobu, kdy je uzel do klastru zapojen. Navíc uživatel, pod kterým běží server na straně zdrojového uzlu, má práva superuživatele a tudíž jsou přístupné všechny soubory. Superuživatel cílového uzlu může procházet libovolné soubory na zdrojovém uzlu a může tak dojít k úniku informací. Toto chování je v rozporu s požadavkem na minimální množinu souborů, které jsou sdíleny. Naproti tomu při práci s prostředky prostřednictvím ProxyFS 2 je nutné prostředky před sdílením exportovat, čímž je zajištěno, že soubory jež nejsou přímo vyžadovány migrovaným procesem nebudou na cílovém uzlu dostupné. Exportovaný prostředek zaniká v okamžiku uzavření jeho popisovače a tudíž je doba jeho dostupnosti limitována na minimum. K bezpečnosti částečně přispívá i metoda pojmenování prostředků pomocí identifikátorů a způsob jejich získávání. Identifikátory souborů jsou generovány sekvenčně při exportu a proto stejný soubor exportovaný několikrát po sobě bude mít jiný identifikátor. Tím je ztížena identifikace i těch souborů, které jsou sdíleny záměrně. 4.2.3.3

Množství funkcí

Současné řešení nabízí pouhé sdílení souborů. Řešení s ProxyFS 2 navíc umožňuje migrovat sdílenou paměť a synchronizační prvky. S tím souvisí i několik 34

4.2. Srovnání s aktuálním stavem dalších úprav komponenty TCMI, které byly představeny v práci Ing. Maláta a které zavádí podporu vícevláknových aplikací. 4.2.3.4

Vyhodnocení

Po zvážení všech výše uvedených vlastností obou řešení bych doporučil rozšíření implementace ProxyFS 2 o chybějící souborové operace a nahrazení stávajícího řešení. Tím by byla odstraněna závislost na NPFS, jejíž nejnovější verze již s Clondike nefunguje.

35

Kapitola

Instalace Clondike jako modul V původní verzi Clondike byly všechny komponenty pracující v prostoru jádra kompilovány přímo do binárního obrazu jádra. To mělo za následek fakt, že komponenty lze distribuovat pouze jako celek spolu s jádrem. Není tedy možné přidat podporu pro Clondike bez překladu celého jádra. Z toho důvodu vznikl požadavek na instalaci projektu v podobě modulu, který umožní zavedení podpory do již běžícího jádra. K tomu je potřeba upravit konfigurační soubory jádra Kconfig, které obsahují definice volitelných součástí jádra, a souborů Makefile pro komponenty Clondike. V následujících sekcích je uveden formát obsahu obou souborů. Popis je zjednodušen a obsahuje pouze informace o částech, které byly upraveny v rámci této práce. Kompletní specifikace se nachází v dokumentaci jádra [12]

5.1

Formát Kconfig

Souborů Kconfig se mezi zdrojovými kódy jádra nachází několik. Jejich smyslem je vytvořit logické členění voleb do stromové struktury, kterou je možné zobrazit v konzoli pomocí příkazu make menuconfig a v grafickém rozhraní pomocí make xconfig (a ekvivalentů). Taktéž definují identifikátory, na které se lze odkazovat jak ze zdrojových kódů, tak v souborech Makefile. Ve zdrojových kódech lze např. pomocí direktivy #ifdef IDENTIFIKATOR určovat, které části kódu budou začleněny a tím do jisté míry měnit chování výsledného modulu. V souborech Kconfig jsou definovány jednotlivé konfigurační volby takto: config MODVERSIONS bool "Set version information on all module symbols" depends on MODULES help Usually, modules have to be recompiled whenever you switch to a new kernel. 37

5

5. Instalace Clondike jako modul Tato volba definuje nový identifikátor MODVERSION. Všem symbolům z Kconfig je přidána předpona CONFIG_ a tak je získán symbol CONFIG_MODVERSION. Tento symbol může mít několit možných typů, určených klíčovými slovy: • tristate - hodnoty ano (y), ne (n), modul (m) – bool - hodnota ano/ne, graficky označováno hvězdičkou, pokud má volba hodnotu ano • string - řetězec znaků – hex - číslo v šestnáctkové soustavě – int - číslo v desítkové soustavě Typ tristate zpravidla určuje jakým způsobem bude ovladač zařazen do jádra. Hodnota y znamená přímý překlad do výsledného binárního obrazu jádra. Hodnota n způsobí ignorování daného ovladače a hodnota m určí ovladač k překladu v podobě modulu, který je možné za běhu jádra načíst. Typ tristate lze použít i jinak, ale z dokumentace vyplývá, že toto je jeho primární určení. Typ bool je odvozený od tristate sjednocením hodnot y a m, typy hex a int jsou odvozené od string a pouze určují, jaké číslo je v řetězci zapsáno. O kontrolu vstupu a převod na správný datový typ se musí postarat programátor. Klíčové slovní spojení depends on určuje identifikátory, které musí být definovány a zapnuty pro správnou funkčnost volby. Poslední informací je nápověda uvedena klíčovým slovem help, kterou lze zobrazit při konfiguraci jádra a informuje uživatele, co daná volba znamená a často také jaká je její bezpečná hodnota.

5.2

Formát Makefile

Pro překlad jádra se používá překladový framework KBuild. Tento framework obsahuje 5 základních skupin souborů, které řídí překlad: • hlavní Makefile • soubor .config • architerkturní Makefile • Kbuild soubory • Makefile soubory s pravidly 38

5.2. Formát Makefile Hlavní Makefile soubor je zodpovědný za řízení celého překladu jádra. Nachází se v kořenovém adresáři se zdrojovými kódy jádra. Prochází adresářovou strukturu a na základě informací v ostatních definičních souborech frameworku KBuild sestaví seznam souborů a způsob, jakým budou přeloženy. Soubor .config obsahuje symboly vytvořené z identifikátorů z Kconfig souborů a jejich hodnoty. Slouží jako přenosná databáze vybraných voleb. Pokud dvě jádra stejné verze byly přeloženy za použití stejného .config souboru, pak poskytují identickou funkcionalitu. Architekturní Makefile se nachází ve složce arch// a obsahuje specifické informace o dané procesorové architektuře (např. x86, sparc). Tyto soubory jsou nutné kvůli rozdílným parametrům procesorů, jako jsou dostupné funkční jednotky, instrukční sady apod. Kbuild soubory obsahují informace o závislostech mezi jednotlivými objektovými soubory, způsobu zařazení do jádra a popř. specifické informace pro překladové nástroje jako jsou např. přepínače pro překladač nebo linker. Makefile soubory s pravidly obsahují direktivy, které spolu s Kbuild soubory určí, jakým způsobem bude překlad probíhat. Direktivy Makefile souborů mají následující formát: cíl : požadavky recept1 recept2 ... foo.o : foo.c lib.h cc foo.c -o foo.o Cíl je soubor, který vznikne překladem zdrojových kódů. V příkladu je jako cíl uveden objektový soubor foo.o. Požadavky jsou soubory, které jsou nutné k sestavení cíle. Vlastností cíle je expirace. Jedná se o logickou proměnnou, která nabývá hodnoty pravda právě tehdy, když cílový soubor neexistuje nebo libovolný z požadavků má novější čas úpravy. V případě, že cíl expiroval, se provedou všechny recepty. Recepty jsou příkazy, které se spouští v příkazovém interpretu, standardně /bin/sh. Na základě umístění zdrojových kódů lze ovladače překládat uvnitř adresářového stromu zdrojových kódů jádra (in-tree) a nebo mimo něj (out-of-tree). Při překladu mimo strom se používá výše popsaný Makefile soubor. V případě překladu uvnitř stromu je použit definiční soubor Kbuild jehož formát je popsán na Kbuild souboru filesystému EXT2: #fs/ext2/Makefile obj-$(CONFIG_EXT2_FS) += ext2.o ext2-y := balloc.o dir.o file.o ialloc.o inode.o ioctl.o \ 39

5. Instalace Clondike jako modul namei.o super.o symlink.o ext2-$(CONFIG_EXT2_FS_XATTR) += xattr.o xattr_user.o \ xattr_trusted.o Příklad obsahuje ukázku překladového cíle. Klíčové slovo obj určuje, že cílem je objektový soubor ovladače, a jeho parametr $CONFIG_EXT2_FS specifikuje, jakým způsobem bude cíl zařazen do překladu. Parametr může být uveden i přímo hodnotou (viz řádek začínající ext2-y). Následuje seznam závislostí, podobně jako v souborech Makefile. Závislost může být udána i v podobě cesty ke složce, pak KBuild použije navíc i definiční soubor v dané složce. V případě, že závislost fyzicky neexistuje (nejedná se o soubor nebo složku), KBuild hledá cíl s ekvivalentním jménem (přípony jsou ignorovány). V ukázce je uvedena závislost ext2, která je v případě potřeby ( tj. konfigurační symbol CONFIG_EXT2_FS má hodnotu m nebo y) vždy přeložena, protože její parametr je nastaven na hodnotu y. Na posledním řádku jsou deklarovány dodatečné závislosti, jejichž zařazení je podmíněno vlastním konfiguračním symbolem CONFIG_EXT2_FS_XATTR. Překladový nástroj KBuild hledá ve složkách primárně soubory Kbuild. Pokud je nenalezne, použije soubory Makefile, které mohou mimo svých standardních definic obsahovat shodné direktivy jako soubory Kbuild. Standardní direktivy Makefile jsou pak ignorovány.

5.3

Provedené úpravy

Po aplikaci záplaty přidávající do jádra podporu pro Clondike a nakopírování zdrojových souborů projektu se nachází konfigurační soubory projektu ve složce clondike/. Protože veškeré komponenty jsou na sobě závislé a pro korektní práci je nutné, aby byly zavedené všechny, bylo rozhodnuto použít stávající konfigurační symbol CONFIG_TCMI pro všechny komponenty. Clondike nepoužívá soubory Kbuild, ale veškeré informace jsou uloženy v souborech Makefile. Hlavní Makefile soubor projektu je velmi jednoduchý a obsahuje: obj-y += tcmi/ ifeq ($(CONFIG_TCMI),y) obj-y += src/ Většina komponent Clondike se nachází v podsložce src/ a z výpisu je zřetelné, že základní podpora pro komponentu TCMI se zařadí vždy přímo do jádra. Ostatní komponenty jsou zařazeny pouze v případě, že má symbol CONFIG_TCMI hodnotu y. Symbol je definován typem tristate a uživatel může jeho hodnotu nastavit na m. Obecně by mělo dojít k překladu komponenty v podobě modulu, ale v tomto případu se tak nestane. Toto chování může být matoucí a bylo odstraněno jednoduchou záměnou: 40

5.4. Ověření funkčnosti obj-y += tcmi/ obj-($CONFIG_TCMI) += src/ Ostatní soubory Makefile nebylo třeba upravovat, neboť všechny byly závislé na vybraném konfiguračním symbolu.

5.4

Ověření funkčnosti

Po změně konfigurace jádra pro překlad komponent Clondike do podoby modulů byl proveden překlad, který nepřinesl žádná chybová hlášení. Nástroj KBuild také správně určil pořadí modulů v jakém musí být načteny, aby byly uspokojeny všechny závislosti. Po restartu systému byl načten modul tcmi, který je závislý na všech ostatních modulech. K načtení modulu slouží nástroj modprobe, který se také postará a načtení všech závislostí: modprobe tcmi Nástroji modprobe je nutné předat parametr pro modul proxyfs, který určuje adresu na které bude komponenta naslouchat. To nelze provést pomocí dodatečného parametru příkazu výše, protože by modprobe předal parametr modulu tcmi a ne proxyfs. Parametr je možné nastavit buď prostřednictvím zavaděče jádra jak bylo popsáno v sekci 2.2.2, nebo prostřednictvím konfiguračního souboru libovolného jména s příponou .conf uloženého do složky /etc/modprobe.d, kde je uložena konfigurace nástroje modprobe. Konfigurační soubor byl pojmenován proxyfs.conf a jeho obsah je: options proxyfs server=tcp:0.0.0.0:1112 Direktiva options přiřazuje modulu, jehož jméno následuje, parametry ve formátu jméno=hodnota. Takto předávaných parametrů může být libovolný počet. Načtení proběhlo v pořádku a stejně tak provedení testovací úlohy uvedené v kapitole 3 Pro pohodlnější načítání modulů je možné přidat jejich jména do souboru /etc/modules a jejich načtení pak proběhne automaticky při startu systému.

41

Kapitola

Zhodnocení splnění cílů 6.1

Seznámení s Clondike a měření na obrazu systému

V rámci seznámení se s projektem jsem narazil na několik chyb, které způsobovaly kompletní nefunkčnost nejen operačního systému jako takového, ale také samotného projektu. Tyto chyby jsem opravil a ověřil funkčnost oprav pomocí měření testovací úlohy ve virtuálním prostředí. Současně jsem upravil konfiguraci sestavovacího nástroje BuildBot tak, aby byl výsledný obraz systému sestaven správně, a oddělil jsem několik vývojových větví projektu v Git repozitáři, čímž jsem umožnil paralelní práci několika vývojářů bez toho, aby si navzájem zasahovali do práce. Měřením v bourací laboratoři jsem objevil další chyby v několika komponentách projektu. Některé se mi podařilo úspěšně opravit a zlepšit tak výkon projektu. Některé se mi opravit nepodařilo, protože jsem nebyl schopen určit pravou příčinu. U těchto chyb jsem provedl odhad příčin a nastínil možné řešení. Z těchto důvodů považuji zadání této části za úspěšně splněné.

6.2

Rešerše výsledků práce Ing. Maláta

Po důkladném prostudování diplomové práce Ing. Maláta a zdrojových kódů v ní obsažených jsem došel k závěru, že navzdory počátečním předpokladům nebyla práce nikdy dovedena do stavu, ve kterém umožňuje měření testovací úlohy. Z toho důvodu jsem měření požadované zadáním své práce neprovedl. Zhodnotil jsem možnosti, které projekt systému ProxyFS2 nabízí a navrhl jsem jeho možné rozšíření, které by vedlo k nahrazení serverů NPFS a 9P2000. Proto považuji zadání za splněné. 43

6

6. Zhodnocení splnění cílů

6.3

Clondike jako modul

Clondike byl ve větší míře na přidání podpory překladu do podoby modulů dobře připraven. Bylo nutné upravit několik definičních souborů. Zdrojové kódy neobsahovaly reference na žádné neveřejné symboly jádra nebo jeho modulů, které by znemožňovaly přidání této podpory bez velkých zásahů do zdrojových kódů jádra samotného. Popsal jsem formát všech upravovaných souborů a úpravy, které jsem provedl včetně jejich účelu a následků. Funkčnost řešení jsem ověřil stejně jako v předchozích částech pomocí měření testovací úlohy s pozitivním výsledkem a považuji tuto část za úspěšně splněnou.

44

Závěr Cílem této práce bylo ověření funkčnosti obrazu systému obsahující projekt Clondike. Při zpracování jsem identifikoval a úspěšně opravil množství chyb, které způsobovaly nefunkčnost obrazu systému. Zároveň jsem narazil na chyby, které ovlivňovaly stabilitu připojování nových uzlů do klastru a jejichž oprava překračuje rozsahem tuto práci a proto byly navrženy pro další zpracování. Následným měřením bylo ověřeno, že vyjma uvedených chyb je po úpravách systém funkční a došlo ke zlepšení některých parametrů. V porovnání s referenční prací bylo dosaženo horších hodnot zrychlení a efektivity, což je dáno výrazným rozdílem ve výkonosti strojů, kratším časem provádění úlohy a vyšším projevením režijní zátěže klastru. Taktéž jsem provedl rešerši stavu implementace systému souborů ProxyFS 2, při níž bylo zjištěno, že jej není možné zařadit do projektu Clondike a tudíž ani provést měření navýšení výkonu. Z toho důvodu byla provedena analýza možností ProxyFS 2 a porovnání se stávající implementací, z které vyplývá, že je systém souborů ProxyFS 2 po nutném rozšíření a úpravě vhodný k zařazení do projektu Clondike. V rámci této práce také byly upraveny zdrojové kódy projektu tak, aby bylo možné je překládat do podoby modulů jádra a distribuovat je např. jako softwarové balíčky systému Linux.

45

Kapitola

Budoucí práce V předchozích kapitolách bylo zmíněno několik chyb, jejichž opravu z různých důvodů nebylo možné v rámci této práce provést. Pro další úspěšné pokračování projektu Clondike je nutné tyto chyby opravit, protože do značné míry omezují funkčnost projektu. Hlavním představitelem této skupiny je chyba komponenty TCMI, popsaná v kapitole docházelo k blokování komunikačního vlákna v prostoru jádra, a problémy s připojováním uzlů. Ve stejné kapitole byla popsána vlastnost vyvažovače zátěže, která způsobuje přetěžování procesoru zdrojového uzlu. Úpravou parametrů vyvažovače by bylo pravděpodobně možné dosáhnout vyššího výkonu klastru. Posledním námětem je rozšíření ProxyFS 2 o chybějící souborové operace a úpravu komponenty TCMI ke vzájemné spolupráci.

47

7

Literatura [1]

Gattermayer, J.; Tvrdík, P.: Different approaches to distributed compilation. In Parallel and Distributed Processing Symposium Workshops & PhD Forum (IPDPSW) proceedings, 2012.

[2]

Malát, P.: Podpora vícevláknových aplikací v projektu Clondike. Diplomová práce, České Vysoké Učení Technické, 2010.

[3]

Buyya, R.; Jin, H.; Cortes, T.: Cluster computing [online]. [cit. 2014-0410]. Dostupné z: http://www.cloudbus.org/papers/FGCS-Cluster.pdf

[4]

Rákosník, J.: Úpravy Clondike pro představení open source komunitě. Bakalářská práce, České Vysoké Učení Technické, 2013.

[5]

The Linux Kernel Organization: Netlink man page. [cit. 2014-04-10]. Dostupné z: http://man7.org/linux/man-pages/man7/netlink.7.html

[6]

Bell Labs: Plan 9 Protocol Wiki [online]. [cit. 2014-04-10]. Dostupné z: http://www.plan9.bell-labs.com/wiki/plan9/plan_9_wiki/

[7]

Ionkov, L.: NPFS Homepage [online]. [cit. 2014-04-10]. Dostupné z: http: //npfs.sourceforge.net/

[8]

BitTorrent Inc.: BitTorrent Homepage [online]. [cit. 2014-04-10]. Dostupné z: http://www.bittorrent.com/

[9]

Graf, T.: Netlink Protocol Library Suite [online]. [cit. 2014-04-10]. Dostupné z: http://www.carisma.slowglass.com/~tgr/libnl/

[10] Gunther, N.: UNIX Load Average Part 1: How It Works [online]. [cit. 2014-04-10]. Dostupné z: http://www.teamquest.com/pdfs/ whitepaper/ldavg1.pdf [11] Pool, M.: Distcc, a fast free distributed compiler. In proceedings of linux.conf.au, Adelaide, 2004. 49

Literatura [12] The Linux Kernel Organization: Linux Kernel Documentation [online]. [cit. 2014-04-10]. Dostupné z: https://www.kernel.org/doc/ Documentation/kernel-parameters.txt [13] Thomas Graf: TCP man page [online]. [cit. 2014-04-10]. Dostupné z: http://linux.die.net/man/7/tcp [14] IETF - Internet Society: RFC1122 Requirements for Internet Hosts – Communication Layers [online]. [cit. 2014-04-10]. Dostupné z: http:// tools.ietf.org/html/rfc1122 [15] Jelínek, L.: Jádro Systému Linux. Computer Press, 2008. [16] OSS Organisation: A sane distributed file system [online]. [cit. 2014-0410]. Dostupné z: http://9p.cat-v.org/

50

Příloha

Seznam použitých zkratek API Aplication Programming Interface - programovací rozhraní CPU Central Processing Unit - hlavní výpočetní jednotka, v této práci se používá jako ekvivalent procesoru TCP Transmission Control Protocol - komunikační protokol IP Internet Protokol - komunikační protokol TCMI Task Checkpointing and Migration Infrastructure KKC Kernel to Kernel Communication - komunikační knihovna SRD Simple Ruby Director VFS Virtual File System - obecné rozhraní pro ovladače souborových systémů UUID Universally Unique Identifier - unikátní identifikátor v rámci systému ASCII American Standard Code for Information Interchange - standard pro kódování znaků SSI Single System Image

51

A

Příloha

Obsah přiloženého CD

readme.txt...................................stručný popis obsahu CD src/..................................zdrojové kódy projektu Clondike measure/........................výsledky měření a zdrojové kódy grafů thesis/ ........................ zdrojová forma práce ve formátu LATEX thesis.pdf ................................ text práce ve formátu PDF 53

B

Sem vložte zadání Vaší práce

Recommend Documents