BUDAPESTI MŰSZAKI ÉS GAZDASÁGTUDOMÁNYI EGYETEM VILLAMOSMÉRNÖKI ÉS INFORMATIKAI KAR MÉRNÖK INFORMATIKUS SZAK. Diplomaterv

Átírás

1 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.

2 KIÍRÁS HELYE 2

3 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

4 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

5 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

6 Tartalomjegyzék 1 Bevezetés Alapfogalmak Elosztott számítás Grid... 8 A Grid története... 9 Virtuális szervezetek Tanúsítvány Webszolgáltatások Feladatok futtatása az EGEE griden Paraméterelemzés Saleve A Saleve célja A Saleve felépítése Alkalmazástervezés a griden Probléma Lehetőségek összehasonlítása Parancssoros felület glite API C++ nyelven Webszolgáltatások Döntés Saleve plugin tervezése Megvalósítás és tesztelés Összegzés Irodalom

7 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

8 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

9 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

10 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 CERN 1 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 felhasználója van, és naponta akár 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 állnak, akik egymással 1 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

11 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

12 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

13 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

14 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

15 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

16 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

17 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

18 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

19 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

20 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