13 DataGrid

13.1 Všeobecné informace

V roce 2003 probíhalo již třetím rokem řešení projektu DataGrid 5. rámcového programu EU. Projekt řešený více jak 20 partnery pod vedením CERNu se v tomto roce zaměřil především na vytvoření stabilnějšího gridového prostředí, na němž by již bylo možné vyzkoušet i rozsáhlejší aplikační výpočty.

Tým sdružení CESNET je součástí pracovní skupiny 1, odpovídající za správu zdrojů a vývoj komplexní Workload Management Service (WMS). Konkrétně pak odpovídáme za logovací službu a používané bezpečnostní protokoly. CESNET rovněž provozuje certifikační autoritu, jejíž certifikáty jsou uznávány všemi partnery jak tohoto, tak i dalších Evropských gridových projektů. CESNET se v rámci "neplacených" (unfunded) aktivit podílí společně s Fyzikálním ústavem i na zajištění provozu základního testbedu.

13.2 Logovací služba

Tým se v roce 2003 zabýval následujícími hlavními aktivitami:

Postupný přechod a podpora provozní verze 2.0.
Pokračující vývoj následné verze 2.1 (s výhledem na verzi 3).
Integrace logovací služby s R-GMA (Gridová monitorovací architektura).

13.2.1 Provozní verze 2.0

V únoru 2003 projekt DataGrid prošel úspěšným druhým hodnocením a vedení projektu rozhodlo o tom, že produkční testbed projektu přejde na novou verzi 2. Toto rozhodnutí umožnilo do konce prvního pololetí přejít na koncepčně nové řešení celé WMS, včetně pokročilých vlastností logovací služby. Ta kromě standardního asynchronního režimu doručování událostí podporuje prioritní a synchronní přenos (garantované okamžité doručení události až do bookkeeping serveru) a rovněž uživatelské události.

Nová architektura WMS je tvořena komponentami vzájemně si předávajícími řízení úlohy přes síťové spojení, diskové fronty požadavků nebo přímým voláním odpovídající procedury. Veškerá tato předání řízení jsou zaznamenána v podobě událostí logovací službou. Události jsou logovány vždy předávající i přejímající komponentou, což kromě robustnosti umožňuje i velmi podrobné post-mortem analýzy nečekaných stavů (ztráta informace o úloze, nepředpokládané race conditions apod.). Tomu byl uzpůsoben i logovací stavový automat, který zpracovává události a z nich rekonstruuje stav úloh.

13.2.2 Nová rozšíření

Nová produkční verze měla výrazně vyšší stabilitu a umožnila již rozsáhlé testy celého gridového prostředí. Soubory desítek tisíc úloh procházely s velmi vysokou úspěšností 95-97 % dokončených úloh. Tyto zátěžové testy však ukázaly omezení stávající architektury a na druhé straně generovaly nové požadavky uživatelů na schopnosti celé WMS a specificky i logovací služby. Přispěly také k výraznému zvýšení kvality produkovaného software.

Oproti předchozí verzi stavový automat nemá nadále funkci vyrovnávací paměti, ale počítá okamžitě nový stav každé úlohy, o níž server přijme událost. Výsledek výpočtu je uložen do databáze, takže ani v případě jejího zhroucení není nutné přepočítávat stav úloh. Tato verze stavového automatu současně podporuje vícenásobné úlohy, kde je závislost mezi jednotlivými podúlohami popsána orientovaným acyklickým grafem (DAG).

Rostoucí stabilita WMS a dalších middlewarových komponent DataGridu vedla k růstu zájmu o sběr statistických údajů o celém DataGridu a jeho účinnosti. Údaje jako poměr úspěšných vůči všem zadaných úlohám, délka čekání ve frontě, poměr čekání ve frontách vůči délce výpočtu atd. lze nejlépe čerpat z LB služby. Přímé použití uživatelského rozhraní pro přístup k těmto informacím však působí neakceptovatelnou zátěž na vlastní databázi.

Museli jsme proto navrhnout a implementovat dvojici příkazů dump/load, které umožňují kontrolované vytvoření kopie všech událostí v databázi a její nahrání do samostatné databáze, nad níž je možno provádět nezávislé vyhledávání. Posloupnost po sobě jdoucích příkazů dump přitom generuje přesnou kopii původní databáze, jak se vyvíjela v čase, při zachování i již dokončených úloh, které jsou z aktivní databáze po určité době vymazány. Operace purge umožní z databáze vymazat všechny dokončené úlohy, jejichž data si již uživatelé vyzvedli. Fyzické vymazání dat označených operací purge proběhne až po nejbližším příkazu dump, čímž je garantována úplnost dat tímto způsobem poskytovaných.

13.2.3 R-GMA a logovací služba

V průběhu roku 2003 jsme dokončili spojení L&B služby s R-GMA (Relational Grid Monitoring Architecture). Hlavním problémem dlouhého vývojového cyklu byly trvalé změny a nestabilita kódu R-GMA. V současné době máme k dispozici rozšíření bookkeeping serveru, který je schopen průběžně posílat informace o nových stavech úloh do základní R-GMA architektury. Data přichází na StreamProducer, který je dále rozesílá dalším vrstvám infrastruktury R-GMA. Vždy vyšší vrstva se registruje u té předchozí a definuje výběrovou funkci (SQL výraz), která určuje, jaká data bude přijímat. Na konci tohoto řetězce je buď uživatel (např. odebírající všechny stavy své úlohy) nebo jednoduchá notifikační služba - pokud nastane takový a takový stav, pak zašli e-mail nebo SMS zprávu uživateli.

Bohužel současná R-GMA implementace neposkytuje všechny potřebné stavební kameny, nezbytné pro plnohodnotné využití této infrastruktury. Především není k dispozici žádná bezpečnost, data mezi jednotlivými uzly putují v otevřené podobě a i uzly samotné nejsou nijak autentizovány (natož autorizovány). Takováto infrastruktura je příliš náchylná útokům na to, aby se dala použít na produkčním gridu.

Dalším nedostatkem implementace je neexistence některých persistentních komponent. LB posílá data do R-GMA trvale a spoléhá na to, že R-GMA žádnou informaci neztratí - to však není pravda. Rovněž není možné zeptat se R-GMA na poslední hodnotu stavu konkrétní úlohy.

Na závěr roku 2003 jsme proto začali pracovat na vlastní variantě R-GMA infrastruktury, která by využívala komponenty LB služeb a poskytovala persistenci a plnou bezpečnost.

13.3 Bezpečnost

Bezpečnost v rámci DataGridu (podobně jako ve většině gridových projektů) je založena na certifikátech. Certifikáty jsou vždy vydávány na časově omezenou dobu, což ovšem komplikuje situaci tam, kde úloha čeká ve frontě nebo počítá příliš dlouho. Může tak dojít k předčasnému vypršení doby platnosti certifikátu a vyřazení úlohy z dalšího zpracování. Použití certifikátů s příliš dlouhou dobou platnosti zase zvyšuje riziko jejich krádeže a zneužití. Řešením je prodlužování životnosti certifikátů před vypršením jejich doby platnosti - toto řešení jsme navrhli již v předcházejícím roce.

V současné době prodlužujeme proxy certifikáty pro úlohy, které jsou svěřeny WMS (ať již běží nebo čekají v nějaké frontě). Na základě našich návrhů a oprav byl změněn Myproxy server tak, aby podporoval průběžné obnovování lístků. Byl rovněž změněn jobmanager Globusu, aby bylo možné změnit certifikáty i pro běžící úlohy. Změny byly otestovány vývojáři systému Condor a spolu s jejich změnami byly prosazeny i do stabilní verze Globusu. Zajišťujeme lístky na WMS, Condor se postará o přenesení nových certifikátů i na stroje, kde běží úloha.

V rámci projektu DataGrid byla v roce 2003 implementována autorizační služba prostřednictvím tzv. Virtual Organization Management Service (VOMS). Ta drží základní autorizační informace, které poskytuje subjektům v podobě atributových (de facto autorizačních) certifikátů. Rozšířili jsme službu Myproxy tak, aby se při obnovování certifikátu dotázala i VOMS serveru a zajistila aktualizaci atributového (autorizačního) certifikátu.

Naše skupina patří mezi tzv. "early adopters" VOMS, autorizační informace používáme pro autorizaci přístupu k datům v LB. Podporujeme běžné manipulace s ACL (Acces Control List), v ACL akceptujeme DN uživatelů nebo VOMS skupiny atd. Bohužel zatím tyto informace využíváme v rámci pracovní skupiny 1 pouze my (a jinde je využívá jen malá část pracovní skupiny 4). WMS proto zatím není schopna nabízet a podporovat pokročilé autorizační operace, jako je třeba možnost zrušit jinou než vlastní úlohu. VOMS informace rovněž zatím nepropagujeme do R-GMA.

Infrastruktura logovací služby je připravena pro důsledné využití autentizačních i autorizačních informací, např. kontrolu certifikátu interloggeru atd. Zatím ale nejsou požadavky na zajištění bezpečnosti v rámci projektu DataGrid tak vysoké.

13.4 Projekt EGEE

Již v předchozím roce jsme se zapojili společně s téměř stovkou partnerů ze všech zemí Evropy, Ruskem i USA do přípravy celoevropského projektu 6. rámcového projektu EU EGEE (Enabling Grids for E-science and industry in Europe). Tento projekt, opět vedený CERNem, si klade za cíl vytvoření skutečně produkční, stabilní celoevrospké gridové infrastruktury.

Projekt úspěšně prošel oponentním řízením a jeho zahájení je plánováno na 1. dubna 2004. S rozpočtem téměř 32 milionů Euro na dva roky si tento projekt klade za cíl propojit všechny evropské národní, regionální i tematicky orientované gridy do jednotné evropské gridové infrastruktury. Ta by měla být následně k dispozici všem akademickým zájemcům o výpočetní nebo datové kapacity. Současně by měla dále akcelerovat možnosti spolupráce jak na evropské, tak i globální úrovni.

Hlavním řešitelem projektu je CERN, centrum evropského výzkumu v oblasti fyziky vysokých energií. Na řešení projektu se má celkem podílet na 70 institucí, zastoupení České republiky zajišťuje sdružení CESNET. Řada zemí je zapojena podobně jako ČR prostřednictvím národního operátora akademických sítí nebo národní gridové agentury, v ostatních případech se pak na řešení budou podílet konkrétní výzkumné instituce a univerzity. Je explicitně zapojeno i Rusko a stále se hledá nejvhodnější forma zapojení Spojených Států a Japonska (podmínkou je jejich finanční spoluúčast).

Očekává se, že každý partner do projektu přinese národní, regionální či tematickou gridovou infrastrukturu (počítače, datové kapacity, počítačovou konektivitu) a EGEE poskytne finanční prostředky primárně na správu celého systému a do jisté míry i na nezbytný vývoj a úpravu (re-engineering) potřebného programového vybavení. Většina partnerů projektu bude mít roli regionálních podpůrných center se školicí povinností a úkoly v oblasti šíření informací o gridech a EGEE.

V roce 2004 má být vlastní gridová infrastruktura postavena na 25 uzlech, s celkovou kapacitou cca 5 tisíc procesorů a 50 TB disků. Na konci dvouletého projektu by mělo být do EGEE gridu zapojeno na 100 uzlů s 50 tisíci procesory a jedním PB diskové kapacity. Cílem EGEE je všechny tyto kapacity zpřístupnit co nejširší komunitě vědeckých pracovníků Evropy, a to co nejjednodušším a snadno ovladatelným způsobem.

Projekt EGEE je možno z určitého pohledu považovat za přirozené pokračování končícího projektu DataGrid 5. rámcového programu EU. Předpokládá se, že EGEE bude v první fázi využívat právě software, který byl v rámci projektu DataGrid vyvinut a který v současné době je adaptován na potřeby CERNu a jeho uživatelů. Kromě primární cílové skupiny fyziků vysokých energií se počítá s aplikacemi v oblasti bioinformatiky, později věd o Zemi (dálkový průzkum Země), astrofyziky, chemie a dalších. Součástí návrhu projektu byly první tři oblasti, zapojení uživatelů z dalších oblastí je jedním z explicitních cílů projektu EGEE.

Projekt sám je organizován do několika vzájemně souvisejících aktivit. Kromě již zmíněného vlastního provozu evropského gridu a rovněž aktivit v oblasti vzdělávání a šíření informací jsou to následující čtyři oblasti s vlastním vývojovým obsahem:

vývoj a integrace gridového middleware
zajištění kvality výsledného software
bezpečnost
specifické síťové služby

CESNETu, především díky úspěšnému zapojení do projektu EU DataGrid, se jako jediné organizaci ve střední Evropě podařilo získat přímé financované zapojení do jedné z těchto vývojových aktivit, a to konkrétně do dalšího vývoje middleware. Přizvání k účasti na vývojových aktivitách je přitom možno považovat za jasné prokázání vysoké kvality gridového týmu, který v CESNETu působí.

Současně se vstupem do EU se tedy můžeme těšit na novou celoevropskou infrastrukturu v oblasti rozsáhlých distribuovaných systémů. Explicitní a rozsáhlé zapojení (nejrozsáhlejší ze všech partnerů ve Střední Evropě) CESNETu umožní přímé a bezprostřední využití evropského gridu i všem zájemcům o toto prostředí v ČR.

předchozí

obsah

následující