Ú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

Other formats: PDF, EPUB

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

V něm se nachází

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.
další weby:fond rozvojemetacentrumCzechLightpřenosyvideoservereduroameduID.cz