BUDAPESTI MŰSZAKI ÉS GAZDASÁGTUDOMÁNYI EGYETEM VILLAMOSMÉRNÖKI ÉS INFORMATIKAI KAR MÉRNÖK INFORMATIKUS SZAK
Diplomaterv Alkalmazásfejlesztés Támogatása Grid Környezetben
Készítette:
Nagy Ákos Zoltán Konzulens:
Dr. Szeberényi Imre
IRÁNYÍTÁSTECHNIKA ÉS INFORMATIKA TANSZÉK 2009.
KIÍRÁS HELYE
2
Nyilatkozat
Alulírott, Nagy Ákos Zoltán, a Budapesti Műszaki és Gazdaságtudományi Egyetem hallgatója kijelentem, hogy ezt a diplomatervet meg nem engedett segítség nélkül, saját magam készítettem, és a diplomatervben csak a megadott forrásokat használtam fel. Minden olyan részt, melyet szó szerint, vagy azonos értelemben de átfogalmazva más forrásból átvettem, egyértelműen, a forrás megadásával megjelöltem.
…………………. Nagy Ákos
3
Kivonat A kutatók, mérnökök munkájuk megkönnyítésére gyakran írnak programokat, azonban sokszor olyan feladattal találják szembe magukat, melyek lefuttatása a számítógépükön beláthatatlan időbe telne. E problémákat nagyon gyakran meg lehetne oldani, ha beküldenék őket valamilyen elosztott környezetbe, például a gridbe. Ez azonban számukra sok esetben túlságosan nehéz feladat. Emiatt született meg a Saleve keretrendszer, amely leveszi ezt a terhet a vállukról: képes a feladatok beküldésére, menedzseli őket, és végül letölti a végeredményt. A Saleve a paramétertanulmányok témakörébe tartozó problémák megoldására használható. Két részből: szerverből és kliensből áll. Kliens írásakor három részre kell felbontani egy programot: paraméter-tartomány felbontására, a részeredmények kiszámítására, és ezeknek az összegzésére. A kliens beküldi a feladatokat a szervernek, amely többféle elosztott környezetben is le tudja futtatni őket. Ezek közül a dolgozat szempontjából a legfontosabb az EGEE grid, amely Európa legnagyobb grid infrastruktúrái közé tartozik. A Saleve szerverben az elosztott környezettel való kapcsolattartást viszonylag önálló egységek, úgynevezett pluginok végzik. Az én feladatom egy olyan plugin készítése volt, amely az EGEE griddel, pontosabban annak köztesrétegével, a gLite-tal tud együttműködni. Három megoldási lehetőség merült fel: a gLite parancssoros felület, a gLite programkönyvtár, illetve webszolgáltatások használata. Ezen lehetséges alternatívák elemzését, valamint az érvek és ellenérvek számba vételét követően a gLite programozói felület használata mellett döntöttem. A plugin fejlesztése kapcsán bemutatom, milyen problémákkal találtam szemben magamat a feladatok beküldése és menedzselése során, és ezeket hogyan oldottam meg.
4
Abstract Researchers and engineers often write programs to facilitate their work, but they frequently face problems whose solution would need vast time on their computers. These problems could often be solved by sending them to a distributed system, such as a grid. But this proves to be too difficult in many cases. That is why the Saleve framework has been created, which takes the load off the researchers’ mind. It submits the jobs, handles them, and finally retrieves the results. Saleve can be used to solve parameter study tasks. It consists of two parts: server and client. When writing a client, programs have to be divided into three parts: partitioning the parameter space, calculating the sub results and summarizing them. The client submits the jobs to a server that can run them on various types of distributed systems, among which the EGEE grid is the most important from this project’s point of view. That grid is one of the largest grid infrastructures in Europe. The Saleve is connected to distributed systems by fairly separated parts called plug-ins. My task was to write a plug-in to collaborate with the EGEE grid, more precisely with its middleware: gLite. Three possible solutions have been considered: the command line interface of gLite, its programming interface, and the use of web services. After analysing these alternatives and taking into account the pros and cons, the gLite API proved to be the best. In connection with the development of the plug-in, I present the problems faced when submitting and managing jobs, together with my solutions.
5
Tartalomjegyzék 1
Bevezetés .................................................................................................................... 7
2
Alapfogalmak ............................................................................................................. 8 2.1
Elosztott számítás ....................................................................................................... 8
2.2
Grid ............................................................................................................................. 8 A Grid története .......................................................................................................... 9 Virtuális szervezetek ................................................................................................ 10 Tanúsítvány .............................................................................................................. 11 Webszolgáltatások .................................................................................................... 13 Feladatok futtatása az EGEE griden ......................................................................... 13
2.3
Paraméterelemzés ..................................................................................................... 18
2.4
Saleve ....................................................................................................................... 18 A Saleve célja ........................................................................................................... 18 A Saleve felépítése ................................................................................................... 20
3
Alkalmazástervezés a griden .................................................................................... 23 3.1
Probléma ................................................................................................................... 23
3.2
Lehetőségek összehasonlítása .................................................................................. 23 Parancssoros felület .................................................................................................. 24 gLite API C++ nyelven ............................................................................................ 25 Webszolgáltatások .................................................................................................... 26 Döntés ....................................................................................................................... 26
3.3
Saleve plugin tervezése ............................................................................................ 27
4
Megvalósítás és tesztelés .......................................................................................... 31
5
Összegzés ................................................................................................................. 33
6
Irodalom ................................................................................................................... 34
6
1
Bevezetés
A tudósok, mérnökök jelentős része ír programokat munkája támogatására, megkönnyítésére. Sok esetben viszont jelentős számításigényű problémákat kellene megoldaniuk, amelyek elvégzéséhez már nem elegendő a rendelkezésükre álló számítógép, mert belátható időn belül nem tudná elvégezni őket. Ezen feladatok esetén érdemes kihasználni az elosztott rendszerek nyújtotta lehetőségeket, amelyek lehetővé teszik, hogy egyetlen probléma megoldásán egyszerre több számítógép is dolgozzon. Ezek egyik típusát alkotják a gridek, amelyek egymástól fizikailag távol levő gépeket is egyetlen rendszerbe foglalhatnak, és így jelentős mennyiségű erőforrást bocsátanak felhasználóik rendelkezésére, amelyekkel már nagy komplexitású feladatok is megoldhatók. A grid technológiája, gyakori változásai többeket elriaszthatnak attól, hogy kiaknázzák mindezen lehetőségeket. Ezt a problémát hidalja át a Saleve (kiejtés: szalev) keretrendszer, amely kapcsolódni tud különböző elosztott rendszerekhez, többek között a gridhez is, ugyanakkor könnyű a használata. E rendszer azon komponensének fejlesztésében vettem részt e munka keretében, amely a griddel való kapcsolattartást végzi. Először, a második fejezetben bemutatom magát a gridet, és a hozzá kapcsolódó olyan alapfogalmakat, mint a virtuális szervezet, amely a felhasználókat tömöríti és lehetővé teszi számukra a különböző erőforrásokhoz való hozzáférést; a tanúsítvány, amely a felhasználókat azonosítja; illetve a webszolgáltatás, amely a távoli gépek közti kommunikációra szolgál. Ezt követi magának a Saleve programnak az ismertetése a 2.4 részben, és a főbb részeinek a bemutatása, különös tekintettel arra a komponensére, amely a griddel kommunikál. Mindezek után rátérek magára a programfejlesztésre: ennek első lépéseként a 3. fejezetben bemutatom a szóba jövő megoldási lehetőségeket, majd leírom, ezek közül melyiket választottam, és miért, végül pedig a 4. fejezetben a megvalósítás részleteit ismertetem.
7
2
Alapfogalmak
2.1
Elosztott számítás
Elosztott feldolgozásról akkor beszélünk, ha különböző feladatokat több erőforrás, számítógép között osztunk szét. Ennek egy lehetséges megvalósítási formája a fürt, amely többnyire egymáshoz közel lévő, hasonló felépítésű gépekből áll, és célja egy vagy néhány szolgáltatás biztosítása magasabb színvonalon. A gépek között van kitüntetett, központi gép, mely a feladatok ütemezését és elosztását végzi, a többi gépen pedig a feladatok végrehajtása folyik. A fürtök egyik gyakran alkalmazott feladat-ütemező és -elosztó programja a Condor [20]. A grid egy sokkal általánosabb célú és felépítésű architektúra, amit részletesen a következő alfejezetben ismertetek.
2.2
Grid
A grid mai formáját megalkotó Ian Foster és Carl Kesselman [1] könyvében szereplő „definíció” szerint a számítási grid egy olyan hardver és szoftver-infrastruktúra, amely megbízható, kiegyensúlyozott, széles körben elterjedt és olcsó hozzáférést biztosít jó minőségű számítási kapacitásokhoz. A grid egy olyan információs rendszer, melynek lényege a számítógépes erőforrások, például a számítási és az adattárolási kapacitás összegyűjtése és újraosztása olyan eszközök között, amelyek egymástól fizikailag akár nagy távolságokra vannak. Fizikailag hálózatba kötött számítógépek összessége, amely virtualizálja a rendelkezésére álló – sokszor nagy mértékben eltérő, heterogén – erőforrásokat, és egy egységes interfészen bocsátja a felhasználók rendelkezésére őket. Célja az, hogy a számítógépek globális hálózatát egy bárhonnan elérhető óriási számítógépes erőforráshalmazzá alakítsa. A grid egy olyan szolgáltatás, amely az előfizetői rendelkezésére bocsátja az erőforrásait, amelyeket a felhasználók szabadon használhatnak. Az erőforrások elérése független a fizikai helytől. Nincs szükség arra sem, hogy az előfizetők felhasználói azonosítóval rendelkezzenek az elérni kívánt erőforráson; ehelyett általánosabb célú tanúsítványt (lásd ugyanezen fejezetben később) kapnak, melyet minden erőforrás elismer. Működését sok mindenben az elektromos hálózatéhoz lehet hasonlítani. Ahogyan a konnektorból bármikor áramhoz juthatunk, ugyanúgy bármikor hozzáférhetünk a grid által rendelkezésre bocsátott erőforrásokhoz, például számítási teljesítményhez vagy tárolókapacitáshoz. És a fizikai távolságok sem számítanak – az áram esetében sem kell azzal foglalkoznunk, hogy melyik
8
erőműben termelt áramot fogyasztunk, százhalombattait, paksit, esetleg külföldről származót, és az hogyan jut el hozzánk. Ezt az analógiát sugallja maga a grid szó is, ugyanis köznapi szóhasználatban az elektromos hálózatra (electrical grid) használhatjuk a „grid” kifejezést. A griden egy olyan szimuláció, amely egy személyi számítógépen akár hetekig tartana, órák alatt lefuthat. Ezáltal jelentősen felgyorsítja a kutatásokat. Így lehetőséget biztosít a nagy komplexitású problémákat kutató tudósok számára olyan kérdések megválaszolásához, mint például hogy mi történt az ősrobbanás után, a globális felmelegedés hogyan fogja befolyásolni az életünket, illetve létezik-e gyógymód a rák vagy a malária ellen. A következőkben bemutatom a grid történetét röviden a [3] forrás alapján, majd ismertetem a használatához szükséges alapfogalmakat.
A Grid története A grid egyes elemei már nagyon régóta jelen vannak a számítástechnikában. A gépi teljesítmény megosztása már a ’60-as években felmerült; sőt, akkoriban ez uralta az informatikát. Ugyanis ekkoriban még hatalmas méretűek voltak a számítógépek, és egy-egy darabon egész szervezetek osztoztak. Az 1965-ös fejlesztésű Multics operációs rendszer (a Unix, és ezen keresztül a Linux őse) például arra az elképzelésre épült (többek között), hogy a számítógépeket ugyanúgy lehet majd használni, mint a telefon-, vagy a villamosenergiahálózatot, azaz amikor éppen szükségünk van rá, akkor kapcsolódunk a szolgáltatóhoz, és használhatjuk is a számítógépet. Az 1990-es években megjelenő, az amerikai szuperszámítógépek összekötését célzó projektek már a grid közvetlen ősének tekinthetők. Ezeket nevezték meta-számítástechnikának. A legfontosabbak a FAFNER és az I-WAY projektek voltak. A FAFNER (Factoring via Network-Enabled Recursion) projekt célja a nagyon nagy számok faktorizálása volt. Ez a biztonság, illetve a titkosítás szempontjából volt kiemelkedő fontosságú; sőt a probléma fontossága máig megmaradt, például az RSA titkosítással kapcsolatosan. Az I-WAY (Information Wide Area Year) projekt új hálózat építése nélkül, meglevő hálózatok összekapcsolásával kötött össze szuperszámítógépeket (és egyéb eszközöket is). Ez a legtöbb grid magját képező Globus Projektre [22] volt nagy hatással.
9
Meg kell még említeni a Legion projektet, amelynek célja, hogy akár sok millió összekötött számítógépet egyetlen virtuális szuperszámítógépként kezelhessünk. Ezzel a projekttel együtt létrejött az Applied Meta vállalat, amelynek neve ma már Avaki Corporation, és kereskedelmi grid megoldásokat fejleszt. A metaszámítástechnikán kívül is számos projekt rendelkezik grid-szerű vonásokkal. Ezek egyike a Condor, amelyet a Wisconsin egyetemen fejlesztettek, és amelynek célja a szabad processzor-kapacitások felhasználása. Az eredeti, helyi hálózatra szánt Condor után kifejlesztettek egy újabb, Condor-G változatot is, amely már griddel is együtt tud működni. A grid mai fogalma 1997 szeptemberében született meg a chicagói Argonne Nemzeti Laboratórium műhelyében. Majd 1998-ban kiadták az Ian Foster és Carl Kesselman által szerkesztett „The Grid: Blueprint for a New Computing Infrastructure” című könyvet [1], amelyet gyakran a grid bibliájának is neveznek. Ennek 2004-ben megjelent a második kiadása is. Manapság rengeteg projekt fut szerte a nagyvilágban, amelyek a grid különböző részeinek fejlesztésére koncentrálnak. Számos kereskedelmi grid kezdeményezés is nagyvilágot látott, amelyekben olyan vezető cégek is részt vesznek, mint az IBM, a Sun és az Amazon. Az egyik legnagyobb európai grid az Enabling Grids for E-sciencE (EGEE) projekt során kialakított infrastruktúra. Ennek létrehozása óta egyik fő célja, hogy fogadja és feldolgozza a svájci CERN1 kutatóközpontban található Large Hadron Collider (LHC) részecskegyorsító érzékelői által összegyűjtött adatokat – ez évente körülbelül 15 petabájt adatot jelent. Az EGEE ma már több mint 20 tudományág – többek között a bioinformatika, az energetika, a gyógyszerészet, a klímaváltozással kapcsolatos kérdések – kutatóit segíti munkájukban. Összesen 50 ország – köztük Magyarország is – vesz részt az EGEE projektben, amelynek körülbelül 10000 felhasználója van, és naponta akár 400000 feladat lefuttatására is képes. [2] [8]
Virtuális szervezetek A grides erőforrásokat különböző virtuális szervezetek (VO: Virtual Organisation) bocsátják a felhasználók rendelkezésére. A virtuális szervezetek hasonló érdekeltségű, hasonló erőforrásokat
igénylő
felhasználókból,
intézményekből
1
állnak,
akik
egymással
CERN: A betűszó ma az Organisation Européenne pour la Recherche Nucléaire-t, azaz a nukleáris kutatások európai szervezetét jelöli
10
együttműködhetnek, vagy erőforrásokat, például adatokat oszthatnak meg. Minden erőforráshoz meghatározható, hogy mely VO-k tagjai használhatják, és egy-egy erőforrás egyszerre több VO rendelkezésére is állhat. Ahhoz, hogy csatlakozzunk egy virtuális szervezethez, rendelkeznünk kell egy olyan érvényes tanúsítvánnyal, amelyet az adott szervezet elfogad. Számunkra különös fontossággal bír a VOCE (Virtual Organisation for Central Europe) nevű virtuális szervezet, ugyanis ez tömöríti a közép-európai kutatókat, akik ennek segítségével férhetnek hozzá az EGEE gridhez. Másik említésre méltó virtuális szervezet a Hungrid. Ez a magyar szervezet jelenleg 235 CPU-t és 36 terabyte tárhelyet bocsát a felhasználók rendelkezésére. Mivel a Hungrid az EGEE egyik virtuális szervezete, ezért erőforrásai e projekt keretében is használhatók. [9] A GILDA virtuális szervezetet az olaszországi INFN (Istituto Nazionale di Fisica Nucleare – Nemzeti Magfizikai Intézet) intézet hozta létre. A betűszó a Grid INFN Laboratory for Dissemination Activities kifejezésből származik. E projekt szintén kapcsolatban áll az EGEE projekttel. Jelentőségét számomra az adja, hogy lehetőséget nyújt bárkinek a grid használatának kipróbálására és működésének megismerésére. Rendelkezik egy saját tanúsítvány kiadó hatósággal (GILDA Certification Authority – GILDA CA), amely ideiglenes, csupán 2 hétig érvényes tanúsítványokat bocsát ki, viszont az egyszerű igénylés érdekében ennek során nincs szükség semmilyen személyes azonosításra. [10]
Tanúsítvány A tanúsítványok elsődlegesen a felhasználók személyazonosságának igazolására szolgálnak, emellett titkosítási célra is használhatjuk őket. A grid világában az X.509 ITU-T szabványú tanúsítványok terjedtek el. [21] Ezekhez tartozik egy nyilvános és egy titkos kulcs. A felhasználó nyilvános kulcsához a nevének megfelelően bárki hozzájuthat, míg a titkos kulcsot csak a felhasználó ismeri. A felhasználó a titkos kulcsával titkosítja az üzeneteit, melyeket a nyilvános kulcs segítségével lehet dekódolni. Ez azért nyújt lehetőséget az azonosításra, mert ha egy üzenetet valakinek a nyilvános kulcsával tudtunk dekódolni, akkor biztosak lehetünk benne, hogy az az ő titkos kulcsával volt kódolva, vagyis az üzenet küldője ismerte a feladó titkos kulcsát. A titkos kulcs előállítása a nyilvános alapján manapság belátható időn belül nem megoldható, a felhasználó pedig nem osztja meg senkivel a titkos
11
kulcsát. Mindezek alapján tehát az üzenet letagadhatatlan: valóban attól kaptuk, aki a feladónak mondja magát. A tanúsítványokat úgynevezett tanúsítványkiadó hatóságok (Certificate Authority – CA) bocsátják ki és hitelesítik. Magyarországon például a NIIF (Nemzeti Információs Infrastruktúra Fejlesztési Intézet) bocsát ki tanúsítványokat. Ha tőlük igénylünk tanúsítványt, akkor egyszer mindenképpen személyesen is be kell menni az irodájukba, ekkor ellenőrzik a személyazonosságunkat, és ennek alapján bocsátják ki a tanúsítványt. Ez meghatározott ideig, például egy évig érvényes; amennyiben ezt követően is szükségünk van rá, akkor meg lehet hosszabbíttatni. Azt, hogy egy adott tanúsítvány hiteles, és valóban egy adott entitáshoz tartozik, a CA digitális aláírása bizonyítja, ami szintén a tanúsítvány része. A gridbe való feladatbeküldéskor azonosítani kell magunkat, amelyhez hiteles tanúsítványt kell felmutatni. Azonban erre az azonosításra szükség van akkor is, amikor a grid terheléselosztó rendszere (lásd később a 2.2 fejezetben) továbbítja a feladatainkat, tehát annak is rendelkeznie kell egy hiteles tanúsítvánnyal. Viszont az előzőekben leírtak alapján a hosszú távú tanúsítványunk titkos kulcsát nem adhatjuk ki a kezünkből. Ezt a problémát az ideiglenes vagy proxy tanúsítványok oldják fel. Ezeket az eredeti tanúsítvány alapján lehet generálni, és ugyanúgy hitelesen azonosítanak minket. Viszont csak rövid ideig (általában 12 órán át) érvényesek, tehát a hozzájuk tartozó titkos kulcs elküldése nem jelent akkora biztonsági kockázatot. A generáláskor meg kell adni egy virtuális szervezetet: a proxy tanúsítvánnyal ehhez a szervezethez fogunk tudni feladatokat beküldeni. A sikeres generáláshoz természetesen szükséges, hogy tagja legyünk a megadott szervezetnek. Ha egy másik szervezethez szeretnénk majd jobot küldeni, akkor új tanúsítványt kell generálni, még akkor is, ha a korábbi még nem járt le. A lefutott feladat eredményeinek letöltéséhez ismét azonosítani kell magunkat, tehát ismét szükség van az ideiglenes tanúsítványra. De előfordulhat, hogy mire a job lefut, addigra a proxy érvényességi ideje lejár. Kézenfekvő lehetőség, hogy akkor generáljunk újat magunknak. Azonban lehetőség van ennek az automatizálására is: a tanúsítványunkat delegálhatjuk egy MyProxy szerverre, amely szükség esetén új ideiglenes tanúsítványt generál számunkra.
12
Webszolgáltatások A webszolgáltatások segítségével távoli gépeken tudunk metódusokat meghívni. A kommunikáció SOAP (Simple Object Access Protocol) [11] protokollon keresztül zajlik, amelyben az elemi adatstruktúrák mellett a komplexebbek is jól reprezentálhatók. Az átvitt üzenetek XML formátumban tartalmazzák az adatokat. Mindezek az üzenetek http vagy https protokoll felett kerülnek átvitelre, megtartva annak minden előnyét, például a tűzfalakon való szabad átjutást. A távoli függvényhívások megvalósítására már sokféle lehetőséget kidolgoztak, de manapság ez a legelterjedtebb alternatíva. Mivel a távoli metódushívás egy meghatározott interfészen keresztül, adott formátumú üzenetekkel történik, így nem kötődik egyetlen programnyelvhez sem; sőt arra is lehetőséget nyújt, hogy különböző nyelveken megírt programok kommunikáljanak. A webszolgáltatásokat WSDL (Web Service Description Language) nyelvű leírással kell megadni. Ez leírja a távolról meghívható metódusokat, valamint a távoli eléréshez szükséges paramétereket. Az üzenetekhez hasonlóan a WSDL is XML formátumú. Legújabb verziója a 2.0-s, amely W3C ajánlás. [23]
Feladatok futtatása az EGEE griden
gLite köztesréteg A köztesrétegek olyan programcsomagok, amelyek – a jelenlegi technológia szerint – az operációs rendszerrel integrálva használhatóak. Számos szolgáltatást nyújtanak (például erőforrások felderítése, lefoglalása, monitorozása), amelyek egy új réteget alkotnak a fizikai erőforrások és az alkalmazások között – innen ered elnevezésük is. Segítségükkel történik a gridre való feladat-beküldés is. Az EGEE gridhez tartozó köztesréteg a gLite, amely moduláris felépítésű, a szolgáltatásai az első ábrán láthatóak. Ezek közül a szakdolgozat szempontjából fontosabbakat a következőkben ismertetem. A biztonsági rendszer elemei közül egyrészt a hitelesítést emelném ki, amely a tanúsítványok használatán alapul (lásd a 2.2 fejezetben korábban), másrészt pedig a hozzáférés engedélyezést, amely a virtuális szervezetekhez köthető. Minden erőforrásra meg van határozva, hogy mely VO-k tagjai milyen jogokkal rendelkeznek az adott erőforráson.
13
A feladatkezelő szolgáltatások működése a következő: A terheléselosztó rendszer (Workload Management System – WMS) fogadja a beérkező feladatokat, átmenetileg tárolja őket, egy globális ütemezési politika szerint párosítja őket a megfelelő erőforrásokkal, nyomon követi az állapotukat, majd letölti az elkészült eredményeiket. A feladatok végrehajtásáért a számítási egységek (Computing Element – CE) a felelősek. Ezek továbbá a helyi szolgáltatásokról és az aktuális állapotukról információt biztosítanak, például a WMS felé. [17] – [19], [24]
Job Description Language A gridbe beküldendő feladatok tulajdonságait egy Job Description Language (JDL) nyelven írt fájlban kell megadni. Ez egy olyan szöveges fájlt jelent, amely név – érték párosokból épül fel. Ha egy értéknek több kifejezést szeretnénk megadni, akkor listába kell foglalni őket. A következő kötelező paramétereket mindig meg kell adni: •
Executable: A programot elindító fájl neve. Lehetőség van egy helyi vagy egy távoli gridFTP szerveren elérhető fájlt megadni – ilyenkor itt csak a fájl nevét kell megadni, a pontos elérési utat az InputSandbox tulajdonságban kell specifikálni – vagy megadhatunk egy a futtató számítógépen elérhető programot – ekkor a program teljes elérési útját meg kell adni, szükség esetén környezeti változók segítségével.
1. ábra A gLite felépítése
14
•
VirtualOrganisation: Azon virtuális szervezet neve, amely nevében az adott feladatot be szeretnénk küldeni.
•
Requirements: A feladat végrehajtásához szükséges feltételek. Egy logikai kifejezést kell megadni, és csak olyan helyre fog továbbítódni a feladat, amelyre ezek a feltételek teljesülnek. Ha nincs semmilyen feltétel, akkor a mindenre illeszkedő true kifejezés használható.
•
Rank: A feltételeket teljesítő CE-k közül azon fog történni a végrehajtás, amelyre az itt megadott kifejezés értéke a legnagyobb. Ha egy konstanst aduk meg, a kiválasztás véletlenszerűen fog történni, míg a Rank = -other.GlueCEStateEstimatedResponseTime; kifejezés esetén az a CE fogja végrehajtani a feladatot, amelyre a feladat sorra kerülése előtti várakozási idő becsült értéke a legkisebb.
A következő paraméterek megadása nem kötelező, de sok esetben szükségesek: •
Type: A beküldendő feladat típusa. 3-féle értéket vehet fel: o Job: „Egyszerű” feladat. Ez az alapértelmezett érték, tehát ha nem adjuk meg ezt a paramétert, akkor egy Job kerül beküldésre. o DAG: Egymástól függő feladatok olyan halmaza, amely egy irányított körmentes gráffal (Directed Acyclic Graph – DAG) írhatók le. o Collection: Egymástól független feladatok halmaza. Az utóbbi két esetben egyetlen jdl fájllal több feladatot is beküldhetünk, és ezekre a későbbiek során egyetlen azonosítóval hivatkozhatunk. A paraméterek bizonyos mértékben eltérőek Job, illetve DAG / Collection esetén. Mivel a Saleve program esetén csak a Job típust kell használni, ezért a többi paraméter bemutatásakor ezt a típust feltételeztem.
•
Arguments: A feladat parancssori argumentumait lehet itt megadni.
•
StdInput: Az itt megadott fájlt fogja a futtatott feladat a standard bemenetén megkapni. Megadása ugyanúgy történik, mint az Executable paraméteré.
15
•
StdOutput: A program standard kimenetét ebbe a fájlba szeretnénk elmenteni.
•
StdError: A program hibaüzeneteit ebbe a fájlba szeretnénk elmenteni. Megadható ugyanaz a fájl is, amelybe a standard kimenet mentése történik.
•
InputSandbox: A program futtatása előtt ezeket a fájlokat kell a végrehajtást végző számítógépre eljuttatni. Megadhatók helyi (a kliens-gépen található) vagy távoli szerverekről elérhető fájlok.
•
OutputSandbox: A program végrehajtása után ezeket a fájlokat szeretnénk letölteni a számítógépre. Az StdOutput-ban és StdError-ban megadott fájlokat is meg kell adni, ha le szeretnénk tölteni őket.
Részletes információ a Job Description Language-ről a [14] dokumentumban található.
Feladatok állapota a griden A gridbe beküldött feladatok a végrehajtás fázisától függően különböző állapotokban tartózkodhatnak. Az egyes állapotok közti átmeneteket a 2. ábra szemlélteti, az állapotok jelentése pedig a következő: •
Submitted: A beküldött feladat megérkezett a WMS rendszerbe, a bemeneti fájlok feltöltésre kerültek.
•
Waiting: A feladat arra vár, hogy a terheléselosztó (Workload Manager – WM) feldolgozza, vagy ez éppen folyamatban van. Ebben az állapotban van a feladat például amikor a terheléselosztónak nincs szabad kapacitása, amikor az nem talált még megfelelő számítási egységet (CE), vagy éppen amikor a feladat erőforrások lefoglalására vár
•
Ready: A feladatot feldolgozta a terheléselosztó (WM), talált megfelelő számítási egységet (CE), és a job készen áll az oda történő eljuttatásra.
•
Scheduled: A feladat eljutott a megfelelő számítási egységre (CE), és annak várakozási sorában tartózkodik.
•
Running: A feladat végrehajtás alatt áll a kiválasztott számítási egységen (CE).
16
•
Done: A feladat futása befejeződött. A Done(failed) állapotba például akkor kerülhet egy feladat, ha nem sikerült elküldeni a számítási egységre (CE), és már nem is visszaállítható.
•
Aborted: A WMS megszakította a feladat futását. Például a megengedettnél több erőforrás használata miatt, vagy azért, mert a felhasználó ideiglenes tanúsítványa lejárt, vagy túl sokáig várakozott terheléselosztó várakozási sorában vagy a számítási egységen.
•
Cancelled: A felhasználó megszakította a feladat futtatását.
•
Cleared: A feladat kimeneti állományait letöltötte a felhasználó, vagy azok törlésre kerültek az időkorlát túllépése miatt.
Ha a beküldött feladat típusa nem Job (az előző részben ismertettem a lehetséges feladattípusokat), akkor a lehetséges állapotok az előbb leírttól kissé eltérnek. [16] [19]
2. ábra Feladatok állapotai a gridben, és a köztük lehetséges átmenetek. Keret jelöli azokat az állapotokat, amelyeket egy sikeresen lefutó feladat érint.
17
2.3
Paraméterelemzés
Paraméterelemzés (Parameter Study, Parameter Scan) feladatoknak azokat a feladatokat nevezzük, amelyek megoldása során azonos algoritmust kell lefuttatnunk többször különböző paraméterekkel egy viszonylag nagy paramétertérben. Ezt a feladatot úgy is elvégezhetjük, hogy a különböző futtatásokat egymás után egy számítógépen hajtjuk végre, vagy a paramétertartományokat kisebb intervallumokra osztjuk, ezeken egymástól függetlenül, de párhuzamosan végezzük el a műveleteket, majd a kapott eredményeket valamilyen módon összesítjük, esetleg azok közül valahogyan kiválasztjuk a legmegfelelőbbet. Egyszerű példa egy függvény numerikus integrálása adott tartományon: Itt a paramétertér sok-sok pontjában ki kell kiszámolni a függvényértéket, majd ezek alapján összegezni a részintegrálokat. Ez a feladat is elvégezhető úgy, hogy az integrálási tartományt felosztjuk kisebb partíciókra, ezeken elvégezzük az integrálást, majd összesítjük, jelen esetben összeadjuk a kapott részeredményeket. Számos tudományág számtalan problémaköre tartozik a paraméterelemzések közé. Például a nagyenergiájú részecskefizika, az asztrofizika, a génkutatás, a gyógyszerkutatás és a földrengés-kutatás bizonyos problémái, de akár a statikában is találhatunk ide sorolható feladatokat. Mivel a részfeladatok végrehajtása egymástól független, vagyis nem épülnek a részeredmények
egymásra,
ezért
tetszőleges
sorrendben,
akár
párhuzamosan
is
végrehajthatók. Ezáltal lehetőség nyílik kihasználni azt, ha több processzorral, esetleg több számítógéppel rendelkezünk, vagy – célszerűen nagyobb problémák esetén – beküldhetjük őket egy gridbe, ahol akár az összes részfeladat egymással párhuzamosan futhat, és így jelentősen lerövidülhet a végrehajtáshoz szükséges idő.
2.4
Saleve
A Saleve célja A tudósok jelentős része rendelkezik valamilyen programozási tudással, például ismeri a C vagy C++ nyelvet, és ezeken ír kisebb programokat munkája során. Viszont többnyire a grid felépítését, vagy a feladatbeküldés menetét már nem ismerik, és általában nincs is annyi idejük, energiájuk, hogy ezeket megismerjék. Tovább nehezíti a helyzetüket, hogy a felhasználói felület viszonylag gyakran változik. Így nem is tudják kihasználni a grid vagy más elosztott számítási infrastruktúrák (pl. fürt) által nyújtott lehetőségeket, pedig ez sok 18
3. ábra A Saleve használati lehetőségei esetben jelentősen felgyorsítaná a programjaik futását, és olyan számításokat is lehetővé tenne, amit talán még csak nem is reméltek. Ennek a problémának az áthidalására született meg a Saleve: egy nyílt forráskódú, C++ nyelven írt program, melynek használati lehetőségeit a 3. ábra szemlélteti. A program elvégzi a végfelhasználó helyett a feladatok beküldését az elosztott infrastruktúrába, követi azok végrehajtását, és végül a felhasználóhoz visszaküldi az eredményeket. A felhasználónak ehhez nem kell ismernie sem a mögöttes infrastruktúra (grid, fürt, ...) felépítését, sem a kezelőfelületét, és a programok változatlan formában képesek futni akkor is, ha megváltozik a grid interfésze, vagy egy másik típusú griden kell futtatni őket. Mindezt a Saleve elrejti előlük. Csupán egyszer, a Saleve-re való áttéréskor kell kisebb változásokat eszközölni a régi programon. [25] A programot Molnár Zsolt kezdte el fejleszteni a Budapesti Műszaki és Gazdaságtudományi Egyetem Irányítástechnikai és Informatikai Tanszékén, és jelenleg is e tanszék folytatja a fejlesztést.
19
A Saleve felépítése A Saleve két fő komponensből áll: Saleve szerverből és Saleve kliensből. A következőkben a [4] - [7] források alapján ismertetem ezek működését.
Saleve kliens A Saleve kliens az eredeti, egyszálú program egy enyhén módosított változata, amely a Saleve kliens függvénykönyvtárral összeszerkesztve állítható elő. A függvénykönyvtárnak egy 3 metódusból álló interfésze van, ezeket kell a felhasználónak megvalósítania. Ez a gyakorlatban azt jelenti, hogy szét kell választani a paraméter-tartomány felbontását, a részeredmények kiszámítását, és ezeknek az összegzését. A kliens egyrészt futtatni tudja a programot azon a számítógépen, ahol őt elindították, – több processzoros számítógép esetén már ez is gyorsulást okoz, ugyanis lehetőség van a párhuzamos feldolgozásra – viszont ezen felül képes arra is, hogy elküldje a lefordított programot, és vele együtt a hozzá tartozó bemeneti állományokat is egy Saleve szervernek, majd a lefutást követően letöltse az eredményeket, és összegezze őket. Ennek a folyamatát mutatja be a 4. ábra. A kommunikáció webszolgáltatások segítségével történik. Mivel a kliens egy meghatározott interfészen keresztül kapcsolódik a szerverhez, így lehetőség van saját kliensek írására is. További előnye a kliens és a szerver szétválasztásának, hogy a szerver a felhasználó elől elrejti a további műveleteket, azaz a kód végrehajtása, esetleges továbbküldése a kezdeményező számára teljesen átlátszóan zajlik. Miután megtörtént a feladat beküldése, a kliens akár meg is szakíthatja a kapcsolatot a szerverrel, és később újra csatlakozva letöltheti az eredményeket. Ez több előnnyel is jár. Egyrészt hibatűrőbbé teszi a működést, mert nincs szükség folyamatos kapcsolatra a kliens és a szerver között, és így az esetleges hálózati hibák tolerálhatóvá válnak. Másrészt akár másik gépről is letölthetjük az eredményeket, mint ahonnan beküldtük a feladatot.
20
4. ábra A feladat végrehajtása
Saleve szerver A Saleve szerver, miután kap egy végrehajtandó feladatot egy klienstől, első megoldásként le tudja futtatni azt helyben. Már önmagában ez is előnyös a kliensen való futtatáshoz képest, mivel a szerverek általában gyorsabbak és nagyobb kapacitással rendelkeznek, mint az átlagos otthoni számítógépek. Viszont ezen túlmenően a Saleve szerver képes továbbítani is a feladatot. Ez történhet egy helyi fürtre, vagy pedig valamely gridre. Ilyen esetekben szükség van a továbbküldött feladatok felügyeletére és hibaellenőrzésre, vagyis figyelni kell a beküldött feladatok állapotát, és ha lefutottak, akkor le kell tölteni az eredményeket, amelyeknek pedig valami miatt megszakadt a futása, azokat újra el kell küldeni. Az elkészülő részeredményeket a szerver ideiglenesen tárolja, majd eljuttatja őket a klienshez. A Saleve egyik célja, hogy többféle ütemezővel, köztesréteggel tudjon együttműködni; illetve mivel ezek interfésze gyakran változhat, lényeges, hogy könnyen követhetők legyenek a változások a Saleve programban. Ezért az elosztott környezettel való kommunikáció pluginokban került megvalósításra. Így egy új környezethez való adaptáció alkalmával, vagy valamely interfész megváltozásakor csak egy új pluginra van szükség, és nem kell az egész programot újraírni. A szervert és a hozzá kapcsolódó pluginokat az 5. ábra mutatja be. Jelenleg 3 plugin létezik: a feladatok helyi végrehajtásához, amely párhuzamosan futtatja az egyes részfeladatokat; a Condor ütemezőhöz, amely a helyi fürtök gyakori ütemezője; és
21
gLite köztesréteghez, amellyel például az EGEE gridbe lehet feladatot beküldeni. Ez utóbbi újratervezése és elkészítése e szakdolgozat feladata. A Saleve szerver egyszerre csak egy plugin kezelésére képes, tehát új környezetre való váltáskor a szerver újraindítására van szükség. A pluginon kívül a szerver tartalmazza még egyrészt a felhasználók és a feladatok kezeléséhez szükséges komponenseket, másrészt azokat a webszolgáltatásokat, amelyeken keresztül a kliensek el tudják érni őket. Ezek a gSoap implementációját használják. [12] [13] Több-felhasználós környezetről lévén szó, nagyon fontos a biztonság kérdése. Ez két lépcsőben történik. Egyrészt a kliensnek hitelesítenie kell magát a szerver irányában, – ez egy felhasználónév - jelszó páros megadásával történik – másrészt a szervernek is szüksége lehet hitelesítésre attól függően, hogy hová továbbítja a feladatokat. Ezt a megfelelő pluginban kell megtenni. Így a hitelesítés is teljesen átlátszó marad a felhasználó számára, nem neki kell megfelelő tanúsítványokat beszereznie, és újabb pluginok létrehozásakor nincs szükség a kliens kódjának módosítására.
5. ábra A Saleve architektúrája
22
3
Alkalmazástervezés a griden
3.1
Probléma
A Saleve program megnyitja a kutatók, mérnökök számára az elosztott számítási környezetek világát, ahogy ezt már a bevezetésben kifejtettem. Segítségével viszonylag egyszerűen tudják egy szervergépen, vagy egy Condor ütemezésű fürtön lefuttatni a programjaikat. Azonban további jelentős előrelépés számukra, ha kihasználhatják a grid nyújtotta lehetőségeket is. Mivel Európa egyik legnagyobb gridje az EGEE grid, és e projektben a BME is részt vesz, ezért célszerű volt ennek a támogatása. Ezt a gridet a felhasználók a gLite köztesrétegen keresztül tudják elérni, így a Saleve programban is a gLite köztesréteggel való kommunikációt kellett megvalósítani. A Saleve programban a különböző számítási környezetekkel való együttműködés viszonylag elkülönült egységekben, úgynevezett pluginokban történik. Tehát a gLite támogatásához is egy plugint kellett megírni, és ennek a fejlesztésébe kapcsolódtam be először az önálló laboratórium, majd e szakdolgozat keretében.
3.2
Lehetőségek összehasonlítása
Amikor bekapcsolódtam a Saleve program fejlesztésébe, már létezett egy majdnem kész plugin, amely a parancssoros felületet használta, azonban a felület megváltozása miatt már nem volt működőképes. Ezen keresztül megismertem a pluginok felépítését, működését, majd működőképes állapotúra hoztam azt. Ezt követően felmerült a kérdés, hogy lehetne-e egy még jobb megoldást találni a Saleve szerver gridhez való kapcsolódására. A Saleve és a grid közötti kapcsolat megteremtésére három alapvető megoldási lehetőség merült fel, melyeket a gLite köztesréteg is támogat: •
Parancssoros felület
•
gLite programkönyvtár C++ nyelvhez
•
Webszolgáltatások
Ezek vázlatos felépítését szemlélteti a 6. ábra. A következőkben ismertetem a különböző megvalósítások alapvető működését, előnyeiket és hátrányaikat.
23
Plugin
gLite CLI
Plugin
parancssoros felület gLite API
gLite API
programozói felület
programozói felület
Webszolgáltatások
Webszolgáltatások
Plugin
Webszolgáltatások
6. ábra A gLite plugin megvalósítási lehetőségei Mindhárom lehetőség esetén fel kell tölteni a Saleve szervert futtató számítógépre a felhasználó tanúsítványát, vagy a Saleve szerver saját tanúsítványát.
Parancssoros felület A parancssoros felület használata előtt telepíteni kell a számítógépre a megfelelő programokat a függőségeikkel együtt. Ideiglenes tanúsítványt az állandó alapján a glite-voms-proxy-init paranccsal generálhatunk.
A
glite-voms-proxy-info
paranccsal
lekérdezhetjük,
hogy
rendelkezünk-e érvényes tanúsítvánnyal, és ha igen, akkor az mikor fog lejárni. Továbbá azt is megtudhatjuk, hogy melyik virtuális szervezethez szól az aktuális proxy tanúsítvány. A beküldendő feladathoz létre kell hozni egy jdl (Job Description Language) típusú fájlt, amelyben leírjuk az adott job tulajdonságait. Ezt kell paraméterül megadni a beküldést végző glite-wms-job-submit parancsnak. Sikeres beküldés esetén a képernyőn olvashatjuk a feladatunkat azonosító URL-t. Ezt meg kell jegyezni, mivel az összes későbbi parancsnál ezzel hivatkozhatunk majd a feladatra. A beküldött feladatok állapotról a glite-wms-job-status paranccsal nyerhetünk információt. A 2.2 szakasz leírja, hogy egy feladat milyen állapotokban lehet a gridben; a program ezeknek a nevét írja ki. Done (Success) esetén a feladat sikeresen lefutott, és az
24
eredmények készen állnak a letöltésre. Ezt a glite-wms-job-output paranccsal tudjuk letölteni. A program a feladathoz tartozó (jdl fájlban megadott) összes kimeneti fájlt letölti, általában a /tmp könyvtárban létrehozott új alkönyvtárba, ahol elolvashatjuk, illetve ahonnan átmásolhatjuk, áthelyezhetjük őket. Ha meg szeretnénk szakítani egy beküldött feladatunk futtatását, akkor a glite-wms-jobcancel parancsot kell használni. Ennek szintén a feladatot azonosító URL-t kell megadni paraméterül. A parancssoros felület használatáról részletes információ a [15] forrásban található. A parancssoros felület használatának legfontosabb előnye az egyszerűsége. Néhány parancs segítségével szinte minden elvégezhető, amire egy átlagos felhasználónak szüksége lehet. Viszont a Saleve programban való használatának több lényeges hátránya is van. Egyrészt viszonylag sűrűn változik, és ez azt jelenti, hogy minden egyes változáskor át- vagy újra kell írni a plugint. Ezen túlmenően a parancsok a felhasználó általi közvetlen használatra készültek, így a kimenetüket a standard outputra, többnyire szöveges formában írják ki. Tehát a
parancsok
kimenetét
a
program
számára
elérhetővé
kell
tenni,
és
ezután
szövegfeldolgozásra van szükség. A szövegből való információkinyerés nem praktikus megoldás, mert ha a kiírt szöveg csak kis mértékben is megváltozik, az már zavarokat okozhat a program működésében, és ezért a plugint újra kell írni. Meg kell még említeni, hogy ahhoz, hogy a parancsokat futtatni tudjuk, telepíteni kell a megfelelő programokat a Saleve szervert futtató gépre, ki kell elégíteni az általuk megkövetelt feltételeket, és mindezeknek a programoknak folyamatosan elérhetőknek is kell lenni. Ha az adott eszközön nem rendelkezünk adminisztrátori jogkörökkel, akkor a telepítés jelentős problémát okozhat, de még ha rendelkezünk vele, akkor is nagy nehézséget jelenthet. Ahhoz, hogy a Saleve megtalálja a feltelepített programokat, bele kell tenni őket a PATH-ba is. A Saleve szerverhez készült gLite plugin kezdetben ezzel a módszerrel működött, kihasználva ennek egyszerűségét, de az előbb felsorolt hátrányok miatt ezt már akkor is csak ideiglenes megoldásnak szánták.
gLite API C++ nyelven Mivel a gLite függvénykönyvtár már programozói felhasználásra készült, így a parancssoros felület hátrányainak túlnyomó többségét kiküszöböli. E megoldás használata esetén nem kell különálló programokat elindítani. Ez egyrészt azért előnyös, mert sok különálló program 25
elindítása jelentős mértékben terheli a számítógépet, másrészt a szerveren sok esetben nincs jogosultságunk korlátlan számú folyamatot indítani. A kimenetet sem a standard outputra írják ki, hanem változókban adják vissza. És a függvények interfésze többnyire csak új gLite verzió kiadásakor változik. Viszont mindezekért cserébe azt az árat kell fizetni, hogy bonyolultabb a használata. A parancssoros felület használatához hasonlóan ebben az esetben is szükség van külön telepítésre a használat előtt, csak most nem programokat, hanem a gLite API függvénykönyvtárát kell telepíteni a Saleve szervert futtató számítógépre. A parancssoros programokhoz hasonlóan ennek is jelentős függőségei vannak, így összességében viszonylag sok programcsomagot kell telepíteni, illetve később frissíteni, naprakészen tartani.
Webszolgáltatások Webszolgáltatások használata esetén semmilyen gLitehoz kötődő új programra nincs szükség, csak a web-service-ek valamely implementációját kell a szerver gépre telepíteni. Ez jóval kevesebb helyet, időt, erőforrást igényel, mint az előző két esetben szükséges programok, programkönyvtárak telepítése. Sőt, mivel a Saleve kliens és szerver közötti kommunikáció is web service alapú, és ez a webszolgáltatások gSoap implementációját használja, ezért ha a pluginban is ezt használjuk, akkor a plugin miatt a Saleve programnak semmilyen új függősége nem lesz. Azonban a webszolgáltatásokat inkább belső használatra fejlesztik, – hiszen a programozók számára elérhető a gLite API is – és ennek következtében a webszolgáltatások használata sokkal bonyolultabb, mint a parancssoros felületé vagy a programkönyvtáré. Továbbá ebben az esetben sem lehetünk biztosak abban, hogy egy új verzió kiadásakor nem fog megváltozni a felület, ez pedig azt jelenti, hogy újra kell írni az egész plugint.
Döntés A fenti elemzés alapján a három lehetőségből a gLite programkönyvtár használata tűnik a legmegfelelőbbnek, annak megfelelően, hogy ezt szánják programozási célokra. A parancssoros felületnek, mint ahogy már leírtam, jelentős hátrányai vannak a gLite API-hoz képest, például szövegesen írja ki az eredményeket, illetve új programokat kell indítanunk a használata során. Mindezeket a hátrányokat hosszú távon nem kompenzálja fő előnye, az egyszerűsége. A webszolgáltatások ellen az szól, hogy nem közvetlen használatra szánták őket, tehát alkalmazásuk esetén mélyen bele kellene merülni a gLite felépítésébe, működésébe. És ezt ráadásul nem is csak egyszer kéne megtenni, mert elképzelhető, hogy új gLite verzió esetén újra kellene írni az egész plugint. Ennek következtében a
26
webszolgáltatások használata jelenleg nem tűnik célszerűnek. Tehát a választás a gLite API mellett történt. De nem csak a másik két alternatíva hátrányai miatt, hanem azért is, mert ez a megoldás jelentős előnyökkel rendelkezik, amelyek közül azt emelném ki, hogy programozási célra megírt C++ függvényekkel dolgozhatunk benne.
3.3
Saleve plugin tervezése
Pluginok készítésekor a következő alapvető feladatokat kell megvalósítani: feladatok beküldése a gridbe, a beküldött jobok menedzselése, és a lefutott feladatok eredményeinek letöltése. Ezen általános képességeken kívül további funkciók megvalósítására is szükség lehet egy plugin elkészítésekor, jelen esetben ilyen a tanúsítványok kezelése. A 2.4 fejezet alapján nem kell minden felhasználónak saját tanúsítvánnyal rendelkeznie, hanem a Saleve szerver rendelkezik eggyel, és amikor szükség van rá, ennek alapján generál a szerver ideiglenes tanúsítványt. A proxy tanúsítványok használatát a 2.2 fejezetben fejtettem ki. A
pluginok
megvalósítása
egy
absztrakt
osztályból
(IServiceAdapter)
való
származtatással történik. Ez két fontos megvalósítandó metódust tartalmaz. A launch azon feladatokat tartalmazza, amelyeket egy új feladat szerverre történő beérkezése után kell végrehajtani, a getUnfinished pedig később, bizonyos időközönként meghívódik – itt lehet lekérdezni a futó feladatok állapotát, és amennyiben valamelyik befejeződött, letölteni a végeredményét. Mivel mindkét feladat viszonylag összetett, ezért érdemes funkcionális dekompozícióval részfeladatokra bontani őket. Ennek legfontosabb előnye, hogy így egy-egy problémát elég egyszer megoldani, és nem kell minden alkalommal, amikor felmerül. Ez nagyban megkönnyíti a későbbi változtatásokat is, mert elég csak egy helyen módosítani, és nem kell az összes előfordulásnál külön-külön. A plugin megírása során az objektumorientáltságot is szem előtt tartottam. A felelősségek elkülönítéséért a részfeladatokat egy külön osztályban (WMSUserInterface) valósítottam meg, így szét lettek választva az alapvető, griddel kapcsolatot tartó metódusok, és az őket felhasználó komplexebb függvények. A plugin osztálydiagramja a 7. ábrán látható. A következőkben bemutatom, milyen részfeladatokat valósítottam meg a külön osztályban, majd az eredeti interfészt megvalósító két függvény működését is ismertetem.
27
7. ábra A gLite plugin osztálydiagramja Az első alapvető részfeladat az átmeneti tanúsítvány érvényességének ellenőrzése. Erre nagyon gyakran szükség van, hiszen mindig, amikor a gridhez fordulunk, érvényes proxy tanúsítvánnyal kell rendelkeznünk. Itt nem csak azt ellenőrzi a program, hogy az adott pillanatban érvényes-e, hanem azt is, hogy egy előre beállított időintervallumon belül nem fog-e lejárni, hiszen minden művelet végrehajtásához valamennyi időre van szükség. Ezt a proxyValid függvényben valósítottam meg. Ehhez szorosan kapcsolódik a következő részfeladat: új proxy tanúsítvány generálása, amelyet a createProxy metódus végez. Értelemszerűen erre akkor van szükség, ha az előző függvény hamis értéket ad vissza, azaz ha nem rendelkezünk átmeneti tanúsítvánnyal, ha rendelkezünk vele, de már lejárt, vagy pedig ha nagyon rövid időn belül le fog járni. A generáláshoz szükség van az eredeti, végleges tanúsítványra, amely alapján az átmenetit létre tudjuk hozni. Ennek egy előre meghatározott könyvtárban kell lennie, és nem szabad, hogy jelszóval legyen védve, ugyanis a Saleve program jelenleg nem képes a jelszó bekérésére, kezelésére. Jelenleg a pluginba bele van kódolva, hogy mely virtuális szervezethez tartozó átmeneti tanúsítványt fog generálni, de a későbbiekben ezt egy beállításokat tartalmazó fájlból tervezzük beolvasni. A harmadik részfeladat egy feladat beküldése a gridbe, melyet a submitJob metódus végez. Szüksége van a feladat JDL nyelvű leírására, amelyet paraméterként kap meg. Visszatérési 28
értéke pedig a feladathoz tartozó azonosító, aminek segítségével a későbbiekben le lehet kérdezni a job állapotát, illetve le lehet tölteni a hozzá kapcsolódó kimeneti fájlokat. A következő részfeladat egy beküldött job állapotának a lekérdezése. Az ezt megvalósító getJobStatus metódus paraméterként átveszi a kérdéses feladat azonosítóját, visszatérési értéke pedig az aktuális állapot. Amikor lefutott egy feladat, a getOutput függvény tölti le a hozzá tartozó kimeneti fájlokat. Ehhez szintén szükség van az adott job azonosítójára. A letöltött fájlok tárolására a Saleve szerver a /tmp könyvtárban létrehoz egy saját mappát. Bizonyos esetekben szükség van egy beküldött feladat törlésére is. Leginkább akkor, amikor egy feladat „beragad” valamilyen, például futó állapotba, és jóval több időt tölt ott, mint amennyi a lefuttatásához szükséges lehet. Ilyen esetekben célszerű ezt a példányt törölni, és újra beküldeni a feladatot. A törlés a cancelJob függvényben történik, és értelemszerűen szükség van hozzá a törlendő job azonosítójára. Ezen, a gLite függvénykönyvtár metódusait közvetlenül meghívó függvények után ismertetem az ezekre épülő, komplexebb feladatokat megvalósító metódusokat is. Ezeket már nem a saját WMSUserInterface osztályom tartalmazza, hanem a pluginok számára előírt interfészt megvalósító ServiceAdapter_gLite osztály. A két kötelezően implementálandó függvényen kívül létrehoztam egy harmadikat is: a submitJob-ot. Ez feladatok beküldését végzi a másik osztály azonos nevű függvényének meghívásával. Létrehozását az indokolja, hogy előfordulhat, hogy a feladatbeküldés sikertelen, mert valami hiba történt, vagy esetleg nem áll elegendő számú a feladat követelményeinek megfelelő erőforrás rendelkezésre. Ilyen esetekben a Saleve többször megpróbálja újra a beküldést, exponenciálisan növekvő időközönként. Ezáltal ideiglenes szerverhibák esetén is végül sikeres lesz a beküldés, és így a végfelhasználó csak annyit érzékel mindebből, hogy egy kicsit tovább tartott a futtatás. A növekvő időközök alkalmazása azért célszerű, mert így a hiba fennállásával összemérhető ideig kell várni, vagyis nem kell egy nagyon rövid hiba esetén is sokáig várni az újrapróbálkozással, de egy hosszabb kimaradás esetén sem fogja feleslegesen leterhelni a hálózatot. Amennyiben a próbálkozások száma meghalad egy bizonyos értéket, a plugin feladja a próbálkozást, és hibát dob.
29
[ Type = "Job"; JobType = "Normal"; Requirements = true; Rank = -other.GlueCEStateEstimatedResponseTime; Executable = "integ_d"; Arguments = "\"integ_d.1.stdout\" \"integ_d.1.stderr\" 0.000000
0.100000";
InputSandbox = {"*"}; OutputSandbox = {"integ_d.1.stdout", "integ_d.1.stderr", "integ_d.2.stdout", "integ_d.2.stderr"}; ]
8. ábra Saleve szerver által generált JDL leírás A launch függvény a feladatok Saleve szerverre történő beérkezésekor hívódik meg. Egyrészt ellenőrzi, hogy rendelkezünk-e érvényes proxy tanúsítvánnyal, és ha nem, akkor generál egyet. Másik fontos feladata a beérkező feladat tulajdonságai alapján az egyes példányokhoz (részfeladatokhoz) tartozó Job Description Language nyelvű leírások előállítása. Ennek felépítését a 2.2 fejezetben ismertettem részletesen; tartalmazza többek között a feladat típusát, és a be- illetve kimeneti fájlokat. Egy a Saleve program által előállított JDL leírást mutat a 8. ábra. Végül a submitJob meghívásával minden egyes részfeladatot külön-külön beküld. A getUnfinished függvény menedzseli a már beküldött részfeladatokat, és letölti az eredményeiket. A tanúsítvány érvényességének ellenőrzése – és szükség esetén az új tanúsítvány generálása – után lekérdezi minden olyan részfeladat állapotát, amely még nem készült el. A feladatok lehetséges állapotait a 2.2 fejezetben ismertettem. Ha a részfeladat még Waiting, Scheduled, vagy Running állapotban van, akkor a végrehajtása még nem fejeződött be, vagyis a további műveletekkel még várni kell e feladat esetében. Ha a job futása valami miatt félbeszakadt, vagyis Aborted állapotba jutott, akkor a Saleve szerver újból beküldi. Ha viszont sikeresen lefutott a feladat, vagyis a Done(Success) állapotban tartózkodik, akkor le kell tölteni a hozzá tartozó eredményeket. Manapság még a grid, illetve a hozzá tartozó gLite köztesréteg sem érte el végső állapotát, még előfordulnak bizonyos hibák. Egyelőre sajnos megtörténhet, hogy egyes beküldött feladatok „beragadnak”, azaz a végrehajtáshoz szükséges időnél sokkal tovább is futó állapotban maradnak. Ezen jobokat ki kell szűrni, a beragadt példányokat törölni kell, és újra be kell küldeni őket.
30
4
Megvalósítás és tesztelés
Mivel a Saleve csak Posix környezetben, pontosabban csak Linux alatt futtatható, ezért megismerkedtem a Linux rendszerrel, nemcsak a grafikus, hanem a parancssoros felületével is. Az Ubuntu disztribúciót használtam. A Saleve program fejlesztése során egy verziókezelő programot használunk, a Subversion-t. A használatához először létre kell hozni egy repository-t, amelyben magát a programot tároljuk. Innen mindig le lehet tölteni a legfrissebb működő verziót. Amikor elkészül egy új programrészlet, vagy kijavítunk egy hibát, az új változatot feltöltjük. Ha viszont azt tapasztaljuk, hogy elrontottunk valamit, akkor visszatérhetünk a még működő verzióhoz. A programmal nem csak a legutóbbi változatot tudjuk elérni, hanem az összes korábbit is, ezáltal ha a módosítás után csak később derül ki, hogy valami rosszul működik, akkor is vissza tudunk térni a még helyesen futó változathoz. A fejlesztés során a Saleve repository egy külön ágában dolgoztam, így bármikor feltölthettem a részeredményeimet anélkül, hogy ezzel felülírnám a működő verziót. Végül a már kész plugin bekerült a hivatalos Saleve repositoryba. Egyrészt a Saleve program működésének a megismerésére, másrészt az elkészült plugin tesztelésére írtam két Saleve-et használó egyszerű programot. Az egyik egy számhalmaz legkisebb és legnagyobb elemét tudja megkeresni, a másik pedig két mátrix összeszorzására képes. Ahogyan a 2.4 fejezetben leírtam, három részfeladatra kell szétbontani a feladatot. Ennek megfelelően a programozás során egy 3 metódusból álló interfészt kell megvalósítani. Az első függvény, a gcsaleve_span a paraméter-tartomány felbontására szolgál. Ez még a kliensen fut le. A második metódus, a gcsaleve_main számolja ki a részeredményeket. Ez gyakorlatilag a Saleve-et nem használó programok main függvényének felel meg. Lefuttatása a gLite plugin használata esetén a griden történik, de a 2.4 fejezetnek megfelelően máshol is lehetséges. A harmadik részfeladat a részeredmények összesítése, amelyet a gcsaleve_sum függvényben kell megvalósítani. Ez szintén a kliensen fut le, méghozzá akkor, amikor már az összes részfeladat eredménye rendelkezésre áll. A következőkben a szélsőérték-kereső programon keresztül bemutatom egy Saleve kliens írásának folyamatát. A paraméter-tartomány felbontása a gyakorlatban azt jelenti, hogy az eredeti számhalmazt megfelelő számú részhalmazra kell felbontani. Ezt célszerű úgy végezni, hogy minden részfeladat körülbelül azonos nehézségű legyen, vagyis a részhalmazok lehetőleg azonos
31
elemszámúak legyenek. Még ugyanebben az első metódusban lehet specifikálni minden egyes részfeladathoz be- és kimeneti állományokat. A részfeladatoknak át kell adni a paramétereiket, az adatokat, amelyeken dolgozniuk kell. Erre két megoldást kínál a Saleve: a részfeladatok megkaphatják őket függvényparaméterként, ahhoz hasonlóan, mint ahogyan a programok a parancssori paramétereiket megkapják; a másik lehetőség pedig az, hogy fájlba kiírjuk az adatokat, majd a részfeladatokban onnan olvassuk ki őket. A szélsőérték-kereső programban paraméterként adtam át az adatokat, a mátrix-szorzó programban pedig a másik megoldást választottam. A részeredményeket kiszámoló metódusomnak csak a paraméterei közül kell kiválasztania a legkisebbet és a legnagyobbat. A részeredmények továbbítására a bemeneti adatokéhoz hasonlóan két megoldás adódik: a fájlokon keresztüli átadás itt is működik, a másik lehetőség pedig az, hogy a standard outputra írjuk ki az eredményeket. Ugyanis a részfeladatok standard kimenetét, illetve a hibaüzeneteiket egy-egy fájlként tudjuk elérni az összesítést végző függvényből. A programomban a standard kimeneten keresztüli átadást használtam, mert az az egyszerűbb. A fájlokba való kiírást akkor érdemes például használni, ha több részeredmény-csoportot szeretnénk átadni; ekkor külön-külön fájlokba írhatjuk őket. Az összesítő függvényben megnyitom a részeredményeket tartalmazó fájlokat, és a bennük található értékek alapján kiszámolom a globális minimumot és maximumot. Mivel a Saleve szerver futtatásához szükség van a gLite programkönyvtár telepítésére az összes függőségével együtt, és ezek telepítése egy meglehetősen bonyolult feladat, így a szervert olyan gépeket fordítottam és futtattam, ahol mindezek már rendelkezésre állnak. Ezek úgynevezett User Interface gépek. Egyrészt a BME IIT tanszékén is található egy ilyen, mely az ui.hpc.iit.bme.hu címen elérhető, másrészt mivel beléptem a VOCE virtuális szervezetbe, lehetőségem nyílt annak egyik UI gépét is használni, mely az ui1.egee.cesnet.cz címen található. A tesztelés megkönnyítésére a plugin metódusai naplózzák a lényeges eseményeket, ugyanabba a fájlba, ahová a Saleve program többi része is végzi a naplózást. Ez alapján végigkövethetők az egyes részfeladatok életciklusai, például hogy a beküldése sikeres volt-e, mikor futottak le, illetve megtörtént-e a kimeneti fájlok letöltése.
32
5
Összegzés
A munka során először megismertem a grid használatához kapcsolódó alapfogalmakat. Saját tanúsítványt igényeltem, majd ennek birtokában több virtuális szervezethez, köztük a VOCEhoz is csatlakoztam. Mindezek lehetővé tették számomra az EGEE gridbe való feladatbeküldést. Ezzel párhuzamosan megismertem a Saleve keretrendszert, és az ismeretek elmélyítése végett írtam hozzá saját klienst. Ezen felkészülés után már hozzáláthattam a gLite plugin megtervezéséhez, majd kivitelezéséhez. Megismertem Saleve és a gLite közötti kapcsolatteremtés lehetséges alternatíváit, majd az érvek és ellenérvek alapján kiválasztottam a legmegfelelőbbet, amely jelenleg a gLite programkönyvtár. Ezen API működésének részletes tanulmányozása után elkészítettem magát a plugint, majd következhetett a tesztelés. Itt ismét hasznát vehettem a megírt Saleve kliensnek, illetve jelentős segítséget nyújtott a Saleve szerverbe integrált naplózás is. A hibák kijavítása után a plugin végül bekerült a hivatalos Saleve repositoryba is, és már a nagyközönség rendelkezésére áll. A keretrendszer fejlesztésére számos további lehetőség mutatkozik. Az egyik javaslat szerint a gLite plugin egy konfigurációs fájlt használna, és innen olvasná be az olyan változó értékeket, mint például a használni kívánt virtuális szervezet neve. Ennél sokkal nagyobb horderejű változást jelentene, ha lehetővé válna az egyes felhasználók saját tanúsítványainak használata a gLite pluginnal. Ehhez a kliens és a szerver módosítására is szükség lenne: kliens oldalon kellene megvalósítani a proxy-generálást, és ezt továbbítani kellene a szerverhez. További fejlesztési lehetőség lenne, hogy a kliens fogadhasson parancssori paramétereket, amelyeket továbbítana a kliens implementálója által írt, még a kliensen lefutó gcsaleve_span függvény számára. Mivel a Saleve által nyújtott lehetőségek köre egyre bővül, használata egyre egyszerűbb, sokoldalúbb lesz, így joggal remélhetjük, hogy egyre inkább bekerül a kutatók és mérnökök látóterébe, egyre többük életét, munkáját könnyíti meg; és rajtuk keresztül e keretrendszer hozzájárulhat akár a világról való ismereteink bővítéséhez, a tudományok fejlődéséhez is.
33
6
Irodalom
[1] Ian Foster – Carl Kesselman The Grid 2: Blueprint for a New Computing Infrastructure Morgan Kaufmann Publishers Inc., 2003 [2] EGEE projekt honlapja http://www.eu-egee.org/ , http://www.eu-egee.hu/ [3] Grid Café honlapja http://gridcafe.eu-egee.hu/ [4] Zs. Molnár – I. Szeberényi Saleve: simple web-services based environment for parameter study applications. In Proceedings of the 6th IEEE/ACM International Workshop on Grid Computing, 292– 295. p., 2005. [5] P. Dóbé – R. Kápolnai – I. Szeberényi Simple grid access for parameter study applications In 6th International Conference on Large-Scale Scientific Computations, Sozopol, 2007. Nyomtatás alatt [6] P. Dóbé – R. Kápolnai – I. Szeberényi Saleve: Supporting the Deployment of Parameter Study Tasks in the Grid [7] P. Dóbé – R. Kápolnai – I. Szeberényi Saleve: párhuzamos Grid-alkalmazások fejlesztőeszköze [8] CERN honlapja http://public.web.cern.ch/public/en/LHC/Computing-en.html [9] HunGrid honlapja http://grid.kfki.hu/hungrid/ [10] GILDA tesztágy https://gilda.ct.infn.it/
34
[11] SOAP leírás http://www.w3.org/TR/soap12/ [12] gSoap http://gsoap2.sourceforge.net/ [13] Robert A. van Engelen – Kyle Gallivan The gSOAP Toolkit for Web Services and Peer-To-Peer Computing Networks In the proceedings of the 2nd IEEE International Symposium on Cluster Computing and the Grid (CCGrid2002), pages 128-135, May 21-24, 2002, Berlin, Germany. [14] Job Description Language Attributes Specification https://edms.cern.ch/file/590869/1/EGEE-JRA1-TEC-590869-JDL-Attributes-v0-9.pdf [15] WMProxy Service User’s Guide https://edms.cern.ch/file/674643/1/EGEE-JRA1-TEC-674643-WMPROXY-guide-v03.pdf [16] EGEE User’s Guide WMS Service https://edms.cern.ch/file/572489/1/EGEE-JRA1-TEC-572489-WMS-guide-v0-3.pdf [17] Kápolnai Richárd – Németh Dénes – Dr. Szeberényi Imre Grid az oktatásban [18] Németh Dénes Grid rendszerek kialakítása és alkalmazása Diplomamunka (BME). 2007. [19] Stephen Burke – Simone Campana – Patricia Méndez Lorenzo – Christopher Nater – Roberto Santinelli – Andrea Sciabá gLite 3.1 User Guide https://edms.cern.ch/file/722398//gLite-3-UserGuide.pdf [20] Condor projekt honlapja http://www.cs.wisc.edu/condor/ [21] X509 szabvány http://www.itu.int/rec/T-REC-X.509/en 35
[22] Ian Foster Globus Toolkit Version 4: Software for Service-Oriented Systems IFIP International Conference on Network and Parallel Computing, Springer-Verlag LNCS 3779, pp 2-13, 2005. [23] WSDL 2.0 szabvány http://www.w3.org/TR/2007/REC-wsdl20-primer-20070626 [24] EGEE Middleware Architecture https://edms.cern.ch/file/594698/1.0/architecture.pdf [25] Saleve honlapja http://cern.ch/saleve
36
