Úvod do desktopového gridového počítání s BOINC
Technická zpráva CESNETu 21/2010
Michal Krsek1, Ivan Doležal2
1CESNET, z.s.p.o.
2Ostravská univerzita v Ostravě
Received 29.11.2010
Abstrakt
The text aims to attract the attention of those interested in starting their projects using Grid computing without deploying dedicated resources and to give them a hint to easily run the BOINC where original documentation is rather discouraging. Additionally it partially documents the use in a real world example.
Klíčová slova: BOINC, desktop, distributed computing, grid computing, FreeBSD
1 Úvod
Zpráva vznikla na základě praktických zkušeností s využitím open-source softwaru BOINC v projektu, jehož účelem je optické rozpoznávání znaků (OCR) ve videozáznamech. Jeho princip: videozáznam je předem rozdělen – „destilován“ na jednotlivé obrázky. Ty jsou odesílány pomocí řídicího serveru na jednotlivé počítače – klienty s OCR softwarem. OCR software rozezná texty (výpočetně náročná část) a odešle je zpět řídicímu serveru, který je předá dále k zaindexování.
Úlohu bylo možné řešit pomocí standardního gridu, to však nebylo záměrem řešitelů. Software BOINC byl jasnou volbou. Není sice prvním projektem svého druhu pro distribuované počítání na desktopech (projekt Distributed.net), ale celý jeho zdrojový kód je k dispozici. Má své kořeny v projektu SETI@home a za sebou vývoj od roku 2002. Výpočetní program, pokud je napsán multiplatformně, lze snadno začlenit do BOINC klienta pro Windows, Linux, Apple. Pro stejnou třídu úloh existuje i systém Condor. Jeho konfigurace na serverové straně by byla i snazší. Při nasazování jsme však přihlíželi i k rozšíření platforem. Nelze předpokládat, že uživatelé BOINCu by současně využívali i mnohem méně rozšířený systém Condor.
Zatímco pojem „BOINC server“ je intuitivní, „BOINC klient“ je speciální software, který se pouze obecně stará o přidělování strojového času počítací aplikaci (například našemu OCR programu) v nevyužitých strojových cyklech, zajišťuje přísun dat této aplikaci ze serveru a o vracení vypočítaných výsledků, zajišťuje automaticky update počítací aplikace u uživatelů, ověření uživatelů u BOINC serveru a další režijní operace. BOINC klient není samotnou výpočetní aplikací. Uživatel, který se rozhodne věnovat své strojové cykly projektu, musí v prvním kroku nainstalovat BOINC klienta, ve druhém kroku jej pak „připojit“ (attach) k projektu zadáním URL.
Dvojice <vstupní data; aplikace> se nazývá workunit. Každá pracovní jednotka má své jednoznačné označení, pod kterým ji lze sledovat.
Získaný výsledek se nazývá result.
Další text popíše, jak co nejjednodušeji realizovat software pro klienta i řídicí server.
2 Wrapper
Nejjednodušší variantou tvorby aplikace je použití programu „The BOINC Wrapper“, který zajistí integraci výpočetní aplikace bez znalosti API BOINCu za cenu redukce vizuálních efektů. Program je na stránkách projektu ke stažení v binární formě pro všechny podporované platformy.
V rozebíraném příkladu se původní aplikace pro OCR spouští z příkazové řádky tak, že argumentem příkazové řádky je jméno konkrétního souboru s obrázkem. Původní aplikace jménem imageProcessing ukládá rozeznaný text vždy do souboru se stejným názvem result.txt.
Pro Wrapper proto bylo potřeba připravit soubor job.xml, který vypadá takto:
<job_desc> <task> <application>imageProcessing</application> <command_line>in</command_line> </task> </job_desc>
Protože je systém BOINC velmi dynamický, předpokládá se, že se s rozvojem výpočetní aplikace časem změní i obsah tohoto souboru. Aby jej bylo možno u klientů snadno verzovat, musí se soubor přejmenovat na job.xml=job_X.Y
.xml (např. job.xml=job_1.3.xml), kde X.Y
je číslo verze v rozsahu 0-100 a slouží pouze k tomu, aby při příštím updatu mohl být správně nahrazen vyšším číslem verze. Obdobně je potřeba verzovat i původní aplikaci.
Detailní popis ovládání Wrapperu a všech jeho parametrů lze nalézt v [1].
3 Server
Aby byla maximálně zjednodušena obsluha distribuovaného počítání, systém pro destilaci obrázků pouze ukládá běžným způsobem soubory do zadaného adresáře. Systém pro indexaci si zase výsledky periodicky odebírá z jiného adresáře. Oba okolní systémy tak nepotřebují nic vědět o struktuře dat a chování BOINCu.
3.1 Instalace
Aby při této metodice důsledně rozčleněného, izolovaného a simplifikovaného zpracování nedocházelo k problémům s výkonem a s přeplňováním souborového systému, byl zvolen operační systém FreeBSD 7.2, který v okamžiku startu projektu disponoval jako jeden z mála implementací vysoce robustního, škálovatelného a „neomezeného“ souborového systému ZFS. Toto rozhodnutí přivodilo pouze menší komplikace (například v úpravách cest k souborům). BOINC server per se využívá pouze standardní komponenty: MySQL 5.0, Apache 2.2, PHP 5.2, Python 2.6. OpenSSL. Část kódu je napsána v C. Autoři BOINC serveru zjevně preferují jako běhovou platformu Debian Linux, pro který je software k dispozici jak ve formě balíčků, tak jako Virtual Machine. Navíc Linux po zahájení projektu získal své výkonné souborové systémy.
Přesto uvedeme informace i pro potenciální uživatele FreeBSD: kromě zmíněných základních komponent je potřeba zejména přidat balíčky py-MySQLdb, subversion, gmake, libtool22, php5-mysql, php5-gd, php5-extensions, libxml2.
V OS je nutno založit skupinu boinc, a zařadit do ní účty boincadm, www. Pro FreeBSD je zvláštní informací, že těmto uživatelům byla upravena defaultní maska pro vytvářené soubory vytvořením nové třídy v /etc/login.conf a příkazy cap_mkdb a pw promítnuta do nastavení OS.
Parametry jádra byly změněny pro optimalizaci ZFS:
/etc/sysctl.conf
kern.ipc.shmall=32768 kern.ipc.shmmax=134217728 kern.ipc.semmap=256
/boot/loader.conf
kern.ipc.semmni=256 kern.ipc.semmns=512 kern.ipc.semmnu=256
Kompilace BOINC stabilního serveru zabere asi 2 minuty:
cd /usr/local/src/ svn co http://boinc.berkeley.edu/svn/branches/server_stable ./_autosetup ./configure gmake #!!! GNU MAKE je nezbytností
Na FreeBSD není zapotřebí knihovna libdl, na kterou se zdrojové texty odkazují a lze ji bezpečně umazat. gmake install umístí cílové soubory bezpečně do /usr/local/lib, /usr/local/include/boinc, /usr/local/bin.
Nově vytvořenému uživateli boincadm se přidělí heslo a přístupová práva k tabulkám MySQL příkazy
GRANT ALL ON *.* TO 'boincadm'@'localhost' SET PASSWORD FOR 'boincadm'@'localhost'=''
Samotné heslo se nastaví v souboru config.xml v projektu. 32 MySQL tabulek vytvoří projekt při instalaci automaticky (stejně jako odvede i většinu ostatní práce). Udržují informace o uživatelích, připravené i odvedené práci, verzích aplikace, rozeslaných e-mailech, dokonce najdete i tabulku donation_paypal. Ne všechny tyto možnosti jsme použili, některé ani podrobněji nezkoumali.
Po této základní instalaci je možno vytvořit první projekt.
3.2 Projekt
Projekt je největší celek BOINC technologie, který sdružuje aplikace (v rámci jednoho projektu jich může být i víc!), tabulky, data. Zpracovávaný projekt dostal jméno „ocr“. Jméno projektu by nemělo obsahovat jiné než alfanumerické znaky.
boincadm:/usr/local/src/server_stable/tools$ ./make_project ocr
Výsledkem příkazu je
- soubor s doporučeným nakonfigurováním cronu pro kontrolu běhu démonů každých 5 minut
- soubor s doporučenou částí konfigurace httpd.conf
- vytvořená struktura adresářů na serveru v adresáři uživatele ~boincadm/projects/
jménoprojektu
(dále PROJECT_ROOT).
V něm se nachází
- podadresář bin s provozními nástroji v Pythonu a v C. Nejzajímavější jsou v něm na počátku práce skripty start a stop.
- podadresář html se strukturou webových stránek, z nichž podadresář ops je potřeba nejlépe ihned zajistíme pomocí vhodného .htaccess! Tento podadresář je uživateli webserveru k dispozici jako
http://server/jménoprojektu_ops
a projekt z něj lze do značné míry monitorovat a ovládat (včetně např. rušení výpočtů). Dále je zde několik předem vytvořených webových stránek s informacemi a jednoduchý RSS zdroj zpráv pro uživatele - soubor config.xml, pomocí kterého jsou definována zejména umístění adresářů, úroveň ladění, rotace logů, heslo k databázi, specifické kvantitativní údaje pro zpracování, nastavení validátoru a asimilátoru (viz dále) apod.
- kratší project.xml, který udržuje seznam aplikací a cílových platforem
- podadresář cgi-bin s několika soubory, využívaný hlavně pro upload dat od klientů
- podadresáře upload, download a sample_results pro odesílání a příjem výsledků
- podadresář templates, ve kterém jsou uloženy šablony popisující předání dat mezi aplikací a serverem
- podadresář apps pro ukládání samotných aplikací
3.3 Přidání aplikace
Všechny soubory každé aplikace pro každou platformu mají svůj adresář a jsou verzovány. Například aplikaci Wrapper ve verzi 9.4 pro 32bitové Windows je nejprve potřeba uložit v adresáři
~boincadm/projects/ocr/apps/imageProcessing/wrapper_9.4_windows_intelx86.exe/
Zde je potřeba uložit původní binární soubor pro Windows imageProcessing verzovaný rovněž pomocí rovnítka (viz výše), DLL knihovny, které program potřebuje ke svému běhu, řídicí soubor job.xml a program, který realizuje wrapper. (jméno adresáře musí být totožné se jménem BOINC aplikace a tou pro nás nadále není imageProcessing, ale právě wrapper):
DevIL.dll ILU.dll imageProcessing=imageProcessing_9.2_windows_intelx86.exe job.xml=job_1.3.xml wrapper_9.4_windows_intelx86.exe
Pojmenovávání souborů ve tvaru jméno
_X.Y
_platforma
je povinné. Zatímco čísla verzí jsou v režii autora aplikace, u názvů platforem je potřeba se řídit hodnotami ze souboru project.xml - jde o řetězce, kterými se identifikují BOINC klienti.
Po přípravě souborů výše popsaným způsobem je potřeba začlenit ji do projektu příkazem bin/xadd.
Aplikace se přenese do diskového prostoru pro download, odkud si ji stáhnou BOINC klienti.
Pokud vše proběhlo správně, na URL http://server/projekt_ops
se aplikace objeví v seznamu aplikací a v seznamu verzí aplikací.
Dalším krokem před zveřejněním projektu je tvorba šablon. Jde o XML soubory popisující předávání dat mezi aplikací a serverem, jejich bodové ohodnocení, způsob ověření správnosti dat (data je možno si nechat počítat na více serverech, platformách) apod. Pro popsanou aplikaci vypadala šablona pro odeslání dat ze serveru k aplikaci (označovaná zpravidla jako workunit template) takto:
<file_info> <number>0</number> <copy_file/> </file_info> <workunit> <file_ref> <file_number>0</file_number> <open_name>in</open_name> <copy_file/> </file_ref> <min_quorum>1</min_quorum> <target_nresults>1</target_nresults> <credit>1</credit> <rsc_fpops_bound>1000000000000</rsc_fpops_bound> <rsc_fpops_est>1000000000000</rsc_fpops_est> </workunit>
a šablona pro příjem výsledku (result template):
<file_info> <name><OUTFILE_0/></name> <generated_locally/> <upload_when_present/> <max_nbytes>5000000</max_nbytes> <url><UPLOAD_URL/></url> </file_info> <result> <file_ref> <file_name><OUTFILE_0/></file_name> <open_name>result.txt</open_name> <copy_file/> </file_ref> </result>
Popis tvorby šablon je rozsáhlé téma, které překračuje text této zprávy. Zájemcům doporučujeme původní literaturu [2].
3.4 Zadání výpočtu
Jak zmíněno výše, BOINC server byl navržen v době, kdy uživatelé souborových systémů mohli pociťovat jejich limity zejména při zpracování většího počtu souborů v jednom adresáři. Proto BOINC server ukládá soubory hierarchicky. Celou hierarchii vybuduje a soubory z flat adresáře přemístí program tvůrců BOINCu:
$ bin/dir_hier_move adresář_se_soubory_dat/. \ /adresář_pro_hierarchické_uložení/. 1024
Hodnota 1024 značí, že v každém adresáři vznikne 1024 podadresářů. V případě souborového systému ZFS jde o číslo neovlivňující výkon celého řešení, neboť počet souborů v jednom adresáři je omezen počtem 248 a operace nad adresáři trvají konstantní dobu. Používání adresářů bylo proto technicky nevýhodné a zdržující.
Po takto provedeném hromadném zařazení souborů je potřeba postupně po jednom zařadit data k výpočtu („submit job“) programem opakovaně volaným ze shell skriptu
$ bin/create_work -appname imageProcessing \ -wu_name jméno_workunity -wu_template templates/wu \ -result_template templates/result jméno_souboru_s_daty
Poznamenejme, že BOINC má dokumentované programátorské rozhraní v C a např. zařazování k výpočtu lze samozřejmě provádět rychleji vlastním programem.
Při řešení našeho úkolu jsme však zařazení k výpočtu prováděli v 5minutových intervalech spouštěním z cronu (vstupy pro BOINC byly průběžně připravované jiným programem). Kromě popsaných operací navíc naše řešení zajišťuje jednoznačné pojmenování zpracovávaných souborů, které je pro celý proces kritické.
Všimněte si, že při zadávání výpočtu nelze nijak upřesnit nutné číslo verze, která má konkrétní vstupní soubor dat (workunit) zpracovat. Při změně formátu dat je proto nejlépe vydat v rámci projektu zcela novou aplikaci a té začít data v novém formátu přiřazovat. Její distribuci na klienty přihlášené k projektu zajistí samotný systém BOINC.
3.5 Získání výsledků
BOINC zajišťuje i validaci dat. To je démonem realizovaná povinná operace, která rozhodne o platnosti výpočtu – nejjednodušeji tak, že se spolehne na informaci BOINC klienta o době trvání výpočtu. BOINC server ale může validaci provést i tak, že sám zadá výpočet dvakrát a porovná přesnou shodu obou výsledků porovnáním bajt po bajtu. Výše popsané dvě metody validace již autoři BOINCu napsali (sample_trivial_validator, sample_bitwise_validator) a při nasazení stačí pouze některý z validátorů zvolit v souboru config.xml.
Poslední fází je asimilace. Asimilátor je program, který přebírá validované výsledky a ukládá je do adresáře, do databáze apod. BOINC nabízí jako nejjednodušší řešení použití dodaného asimilátoru sample_assimilator, který pouze zapíše platné výsledky do adresáře PROJECT_ROOT/sample_results nebo připíše chybový záznam do souboru PROJECT_ROOT/sample_results/errors.
3.6 Nasazení
Praktické nasazení proběhlo později, než plánováno a projekt byl ukončen dříve, než došlo k nasazení ve významnějším rozměru. Jiné projekty probíhající ve světě však ukazují, že škálovatelnost řešení není jeho slabinou.
4 Závěr
Ačkoliv nasazení BOINC serveru není tak triviální, jak sugeruje tento informativní text a pro jeho rozsah jsme zde i pominuli otázky ladění, přesto jej lze doporučit k využití všude tam, kde čas k výpočtu významně překračuje čas potřebný k přenosu zadávaných dat a výsledků, lze zajistit dostatečný počet počítačů, najdou se alespoň minimální programátorské kapacity a kde je možno operovat vlastní webový server.
Literatura
[1] | BOINC Project. The BOINC Wrapper. [cit. 2010-11-30]. Available online. |
[2] | BOINC Project. Submitting Jobs. [cit. 2010-11-30]. Available online. |