P-GRADE fejlesztőkörnyezet és Jini alapú GRID integrálása PVM programok végrehajtásához. Rendszerterv. Sipos Gergely

P-GRADE fejlesztőkörnyezet és Jini alapú GRID integrálása PVM programok végrehajtásához

Rendszerterv

Sipos Gergely [email protected] Lovas Róbert [email protected]

MTA SZTAKI, 2003

P-GRADE fejleszt környezet és Jini alapú GRID integrálása PVM programok végrehajtásához

Tartalomjegyzék 1. Bevezetés ................................................................................................ 3 2. Jini alapú Grid rendszer ........................................................................... 4 2.1 2.2 2.3 2.4 2.5

A Grid célja és felépítése.....................................................................................................4 A Jini-szemlélet ...................................................................................................................5 Egy dzsinn m ködése ..........................................................................................................7 A Sun Jini-implementációja ................................................................................................9 A Jini, mint a Grid alap-infrastruktúrája ...........................................................................12

3. Párhuzamos PVM programok végrehajtása ............................................14 3.1 3.2 3.3 3.4 3.5

A végrehajtás párhuzamosítása .........................................................................................14 Programok futtatása a helyi PVM-démon felhasználásával ..............................................15 PVM programok futtatása Condorral ................................................................................16 A Condor, mint er forrásmenedzser .................................................................................17 A PVM és a Condor szerepe a Gridben.............................................................................18

4. PVM alkalmazások végrehajtása Jini alapon ..........................................20 4.1 4.2 4.3 4.4 4.5

A Jini használata................................................................................................................20 A rendszer követelményei Jini alapon...............................................................................21 Egy PVM-program futtatásának forgatókönyve................................................................22 A szolgáltatás használata...................................................................................................24 A szolgáltató program megtervezése.................................................................................27

5. A P-GRADE és a Jini-Grid integrálása...................................................31 6. Párhuzamos PVM programok monitorozása...........................................36 6.1 A monitorozás célja...........................................................................................................36 6.2 Helyi hálózatban futó PVM-program monitorozása .........................................................36 6.3 PVM-programok monitorozása Jini alapú Gridben...........................................................38

Glosszárium..................................................................................................41 Hivatkozások jegyzéke .................................................................................43


1. Bevezetés A közös projekt egyik célja, hogy a szuperszámítógépeken és klasztereken rendkívül hatékonyan futó párhuzamos kódot egységbe zárva létrehozzunk egy új lehet ségeket nyújtó szolgáltatatást; egy interfész modult az MTA SZTAKI által kifejlesztett P-GRADE programozási környezet és a Veszprémi Egyetem által fejlesztett Jini alapú Grid közé. Az újonnan létrejöv interfész modul segítségével a felhasználó egyszer en készíthet egy csomagot a meglév párhuzamos alkalmazásából, megadva a futtatáshoz szükséges rendszerkövetelményeket, illetve a kimeneti/bemeneti adatokhoz és az ellen rz ponthoz tartozó állományokat. Ezek után a felhasználó az interfészen keresztül a Jini alapú Grid segítségével kereshet a Grid-ben a megadott rendszerkövetelményeknek eleget tév és a P-GRADE rendszerben fejlesztett PVM (MPI) programok futtatását felkínáló szolgáltatást. A következ lépcs ben az interfész egy speciális szolgáltatása eljuttatja a kiválasztott szolgáltatóhoz a párhuzamos alkalmazást tartalmazó csomagot a bemeneti adatokkal együtt, majd eredeti állapotába visszaállítja az alkalmazást, és lefuttatja a klaszteren vagy szuperszámítógépen, végül a megadott eredményfájlokat (megszakított futás esetén az ellen rz pont fájlt) visszajuttatja a felhasználóhoz, esetleg elvégzi az esetleges utómunkálatokat. A fenti mechanizmus segítségével kiaknázhatjuk a szuperszámítógépen vagy klaszteren a natív kód és a rendkívül hatékony (gyártók által támogatott) üzenetközvetít könyvtárak el nyeit, de a Jini alapú Grid tenné lehet vé, hogy az alkalmazásunk futtatásához megfelel (kihasználatlan) er forrásokat fedezzünk fel és használhassuk távolról a Grid-ben. Az interfész modul még felel s lenne a fejleszt környezet többi eszközének (pl. monitorozó) távoli moduljainak elindításáért, valamint a távoli modulok és a felhasználó oldalán lokálisan futó fejleszt környezet közötti kapcsolattartásért mind on-line monitorozás során, mind az elosztott hibakeresés fázisában.

A rendszerterv els két fejezetében az illesztend infrastruktúrák; a Jini alapú Grid rendszer, valamint a klasztereken használatos PVM és Condor által támasztott követelményeket vizsgáljuk meg, melyek az interfész modul tervezésében a legfontosabb szerepet kapták. A követelmények ismeretében a következ két fejezetben két egymásra épül tervezési fázisban megoldást adunk a PVM alkalmazások végrehajtása a Jini által adott szolgáltatások kihasználása mellett, majd egy szinttel feljebb lépve a P-GRADE és a Jini alapú Grid illesztésére. Végül külön fejezet foglalkozik a Jini alapú Gridben történ PGRADE/PVM alkalmazások megfigyelésének témakörével.


2. Jini alapú Grid rendszer 2.1 A Grid célja és felépítése A számítógépklaszter helyi hálózattal összekötött munkaállomásból áll, és els sorban párhuzamos programok futtatására használják [7]. Ha mások rendelkezésére is bocsátják a számítógépes kapacitásokat, akkor létrejön a Grid, a számítógép-kapacitások világhálózata, melyet önálló PC-k, szuperszámítógépek, és számítógépklaszterek alkotnak [4]. A Gridben tehát – a jelenlegi Internettel szemben – nem az információ-megosztás, hanem a hardverkapacitás-megosztás az els dleges cél. A Grid tényleges használatához szükség van valamilyen infrastruktúrára, melynek segítségével mindenki értesülhet a többiek által felkínált er forrásokról, és ami lehet vé teszi a felhasználók számára a nekik szükséges kapacitások igénybevételét. Az infrastruktúra f feladata hogy összekösse a Gridet alkotó er forrásokat, és a Gridben programot futtatni kívánó kliensek gépeit. Szerepe az 1. ábrán látható módon képzelhet el.

Er forrás

Kliens gép

Er forrás

. Er forrás

Gridinfrastruktúra

. .

Kliens gép

Er forrás

Kliens gép

1. ábra: Az infrastruktúra szerepe a Gridben Ez az infrastruktúra a Grid alapszolgáltatásaként fogható fel, melynek minimálisan az alábbi funkciókat kell biztosítania: Csatlakozási lehet séget a Gridhez, keresési lehet séget az er források között.

Az els szolgáltatás igénybevételével a hálózat bármely er forrása csatlakozhat a felajánlókhoz. A szolgáltatást úgy kell implementálni, hogy ha egy csatlakozni kívánó er forrás végrehajtja a csatlakozási protokoll szerint rá háruló feladatokat, akkor biztos lehessen benne, hogy része lett a Gridnek, és el bb-utóbb valaki majd igénybe veszi a


kapacitását, legyen egy önálló Linux-os PC, egy MS Windows 2000-es munkaállomásokat tartalmazó klaszter, vagy akár egy Cray szuperszámítógép. A másik feladat: megoldani hogy azok, akik igénybe kívánnak venni valamilyen grides er forrást, megtalálják az igényeiket kielégít rendszereket. A keresés eredményeként kapott adathalmaznak tartalmaznia kell az igényeknek megfelel er forrásokkal való kapcsolatfelvételhez szükséges információkat. Az információk alapján az er forrás bérbeadójával a kapcsolat felvehet , a bérbeadás feltételei megtárgyalhatók, majd az er forrás használatba vehet . Mindkét szolgáltatást úgy kell megvalósítani, hogy az igényl eszközök akár emberi közrem ködés nélkül is használatba vehessék azokat. A szolgáltatás igénybevételi folyamata mindkét esetben jól algoritmizálható, pontosan definiált lépésekb l kell hogy álljon. Ha az Interneten ez a két szolgáltatás ilyen formában megvalósul, akkor tényleg létrejön a Grid. De az említett két szolgáltatás nem teljesen független egymástól. A köztük fennálló kapcsolatot az a nyilvántartás adja, amelybe be vannak jegyezve a Gridet alkotó er források. A Gridbe kapcsolódáskor ebbe kerül bejegyzésre az er forrás, és ez képezi az er forrás-keresés alapját. A Grid-infrastruktúra létrehozása során ennek a nyilvántartásnak a kialakítása a legnehezebb feladat. A nyilvántartásban szerepelnie kell annak, hogy milyen er források vesznek részt a Gridben, és hogy azokkal milyen módon vehet fel a kapcsolat. A nyilvántartást elosztott módon kell megvalósítani, hiszen könnyen belátható, hogy egy központosított nyilvántartó-rendszer adná a Grid sz k keresztmetszetét – rendkívül lerontva annak használhatóságát – egy esetleges leállással pedig ellehetetlenítené a teljes Gridet. Használhatóságát nagyban befolyásolja a naprakészsége, vagyis hogy milyen frissek a bejegyzett információk. A valóságnak teljes egészében megfelel nyilvántartás az információk terjedésének véges sebessége, és az el re nem látható hardver- és szoftverhibák miatt elméletileg sem lehetséges, de törekedni kell a valóságnak leginkább megfelel nyilvántartás létrehozására. Ezt a nyilvántartó szolgáltatást azért érdemes megkülönböztetni az el bb felsorolt kett t l, mert míg azok a hálózatot alkotó minden gép számára látható, általuk közvetlenül igénybe vehet szolgáltatások, addig a nyilvántartás a többség el l rejtve marad, ahhoz csak az említett két szolgáltatást megvalósító komponensek férhetnek hozzá. Összegezve az eddig leírtakat elmondható, hogy a Grid infrastruktúráját olyan szolgáltatók, és a velük való kommunikációt lehet vé tev protokollok alkotják, melyek a hálózat gépei által ismertek, és melyek használatára algoritmus adható.

2.2 A Jini-szemlélet Egy hálózatban a grid-alapszolgáltatásokat megvalósítani képes egyik infrastruktúra a Sun Microsystems által kifejlesztett Jini. A cél, amiért a Jini-t létrehozták: lehet vé tenni egy dinamikusan változó hálózati környezetben – mint amilyen a Grid – a hálózatot alkotó komponensek egymásnak történ szolgáltatásnyújtását [13]. Az eddigiekhez képest a legfontosabb szemlélet-beli különbség, hogy a Jini a hálózatot alkotó komponenseket nem mint er forrás-felajánlókat és er forrás-igényl ket, hanem mint szolgáltatókat és szolgáltatás-igényl ket tekinti. Ez a megközelítési mód azonban sokkal általánosabb az eddiginél. Egyrészt azért, mert amir l eddig szó volt, hogy egy számítástechnikai eszköz – egy PC, egy klaszter, vagy egy szuperszámítógép – felkínálja másoknak a számítási kapacitását, azzal tulajdonképpen azt a szolgáltatását teszi bárki számára elérhet vé, melyet az adott fizikai eszköz legáltalánosabb értelemben nyújtani képes: programok

!

"

#

$


futtatása. De ha az eszköz tulajdonosa nem szeretné, hogy mások programokat futtassanak nála, a hardver-kapacitást még mindig felkínálhatja a többiek számára. Nyújthat például fájl tárolási lehet séget, SMS-küld szolgáltatást, vagy számológép funkciót. Ezek a szolgáltatások ugyanúgy kihasználják majd az eszköz képességeit, viszont kizárólag a tulajdonos programjai, és nem idegen programok futnak majd a gépen. A lényeg tehát, hogy a bérl knek a számítástechnikai eszköz sokkal speciálisabb szolgáltatást nyújthat, mint a programfuttatás. Az ilyen többletfunkciók eléréséhez azonban a tulajdonosának megfelel szoftvereket kell a rendszerre telepítenie, miel tt azt a Gridbe csatlakoztatná. Eddig a Grid, mint számítástechnikai eszközök, számítógépek hálózata volt. A Jini olyen irányban is kib víti a Gridet, hogy a segítségével létrehozott hálózatba – amit dzsinnek hívnak – olyan eszközök is bekapcsolódjanak, melyeknek a hagyományos értelemben vett informatikai eszközökt l távol állnak. Egy dzsinnek része lehet például egy kávéf z , egy mobiltelefon vagy akár egy gépkocsi is. Az egyedüli kikötés minden eszközzel szemben, hogy a Jini specifikációban definiált protokollokat képes legyen a gyakorlatban megvalósítani. Ez leegyszer sítve annyit jelent, hogy minden eszköznek rendelkeznie kell egy olyan számítógépegységgel, amely programok futtatására képes, és ezek a programok vezérelni tudják az eszköz fizikai m ködését [14]. A Jini tehát a hálózatot szolgáltatás-nyújtó, és szolgáltatás-felhasználó eszközök halmazának tekinti. A két csoport tagjai ilyen egyszer en azonban nem különíthet k el egymástól: egy szolgáltató maga is lehet egy másik szolgáltatás felhasználója. A Jini-szemlélettel kapcsolatban a legfontosabb kérdés, hogy hogyan biztosítja a hálózat számára a grid-alapszolgáltatásokat? A két alapszolgáltatás az új szemlélet szerint: szolgáltatás-bejegyzés és szolgáltatás-keresés. A m ködésükhöz itt is nélkülözhetetlen egy harmadik, a szolgáltatások nyilvántartása. A Jini-ben ezt a három szolgáltatást együttesen lookup szolgáltatásnak hívják. A lookup szolgáltatás a Jini infrastruktúra metaszolgáltatása: egyrészt ugyanúgy szolgáltatásként kezelhet , másrészt viszont a feladata nem egy valóságos, a dzsinn létezése nélkül is fennálló szükséglet kielégítése, hanem magának a dzsinnek az „üzemeltetése”. Ha egy hálózatban lookup szolgáltatást nyújtó eszköz nem létezik, akkor az a hálózat nem dzsinn. A lookup szolgáltatást nyújtó eszköz feladatai a következ k:

Nyilvántartani a mindenkori dzsinnben résztvev szolgáltatásokat, és a hozzájuk kapcsolódó információkat. Lehet vé tenni további szolgáltatások csatlakozását a dzsinnhez. Keresési lehet séget biztosítani a nyilvántartásban azon eszközök számára, amelyek nem szolgáltatni akarnak, hanem valamilyen szolgáltatást igényelnek.

Ezt a lookup szolgáltatást a dzsinnben bármilyen eszköz elláthatja, amelyik teljesíti a specifikált protokolloknak megfelel m ködést. Bárki írhat olyan programot, melynek segítségével a számítógépe lookup szolgáltatóvá válik, vagy készíthet egy olyan hardvereszközt, amely fizikai felépítésével teljesíti a protokolloknak megfelel m ködést. Miután egy ilyen eszközt a hálózatba kapcsol annak tulajdonosa, akkor nincs más feladat, mint várni, hogy a különféle eszközök beregisztrálják nála a szolgáltatásaikat. Bizonyos id elteltével a dzsinn a 2. ábrán látható módon néz majd ki.


Felhasználó

Szolgáltató 2

Felhasználó Szolgáltató 3

Szolgáltató 1

LOOKUP SZOLGÁLTATÓ A hálózat fizikai megvalósítása

Szolgáltatás 1 Szolgáltatás 2 Szolgáltatás 3

Információ 1 Információ 2 Információ 3

A dzsinn aktuális határa

Felhasználó

2. ábra: Egy dzsinn felépítése A dzsinn aktuális határa folyamatosan változik az id ben. A határon belül lesznek azok az eszközök, amelyek az adott pillanatban valamilyen szolgáltatást nyújtanak, a határon kívül pedig azok, melyek nem. A dzsinn tagjainak szolgáltatásait viszont mind a határon kívül, mind a határon belül tartózkodók egyaránt igénybe vehetik. Egy globális méret Jini alapú Grid létrehozásakor egyetlen lookup szolgáltató nem lehet megoldás, a nyilvántartást elosztottá kell tenni, ahogy ezt a Veszprémi Egyetem által fejlesztett megoldásban is megtalálható.

2.3 Egy dzsinn működése Egy hálózatban attól kezdve létezik dzsinn, hogy a hálózat egy eszköze lookup szolgáltatást kezd nyújtani. A lookup szolgáltatást igénybe véve a hálózat eszközei egyrészt regisztrálhatják a szolgáltatásukat – ezzel növelve a dzsinn méretét – másrészt megszerezhetik a számukra fontos szolgáltatásokat nyújtó eszközök címeit. Ennek birtokában a szolgáltató eszközzel a kapcsolat felvehet , a szolgáltatás igénybevétele megkezdhet . A Jini-ben a lookup szolgáltató megtalálását discovery-nek hívják. Három különböz protokoll szerint történhet [16]:

unicast discovery multicast request multicast announcement Az els mód feltételezi, hogy az eszköz, amelyik a lookup szolgáltatást igénybe akarja venni, ismeri a lookup szolgáltatást nyújtó eszköz hálózati címét, és a szolgáltatás portszámát. Ilyenkor el re kell tudni, hogy az információt tartalmazó oldal milyen IP címmel rendelkez számítógépen található, és annak melyik portjára küldhet a kérés. A szolgáltató gépen folyamatosan fut egy program, amelyik a bejöv kérésekre figyel. A multicast request protokoll csak a helyi hálózatban található lookup szolgáltatók megtalálását teszi lehet vé. A lényege, hogy a keresést végz eszköz multicast üzenetet ad ki, melyben a küldés célja – lookup szolgáltató megtalálása – és a küld vel való kapcsolatfelvételhez szükséges cím szerepel. A lookup szolgáltatók az üzenet „kézhezvétele” után válaszolnak a velük való kapcsolatfelvételhez szükséges


információval, míg a többiek egyszer en eldobják a kapott csomagot. A keresést kezdeményez eszköz ezek után az unicast discovery forgatókönyve szerint felveheti a kapcsolatot a lookup szolgáltatókkal. A harmadik módszer lookup szolgáltatás megtalálására a multicast announcement protokoll. Ez az el z höz hasonlóan szintén csak a helyi hálózaton m köd lookup szolgáltatók elérésére használható. A m ködés, ugyanúgy mint az el bb, most is multicast üzenetek küldésén alapszik, de jelen esetben a szerepek fordítottak: nem a lookup szolgáltatást igényl , hanem a lookup szolgáltatást nyújtó a kezdeményez . Bizonyos meghatározott s r séggel a lookup szolgáltató eszköz multicast üzenetet küldhet, melyben „reklámozza” saját magát. (A Sun Microsystems ingyenesen elérhet lookup-programja ezt például 120 mp-enként teszi.) Az üzenetben jelzi, hogy milyen hálózati címen és milyen porton keresztül vehet igénybe a szolgáltatása. A szolgáltatást igényl eszköznek csak meg kell várnia hogy eljusson hozzá egy ilyen üzenet, azután unicast discovery segítségével a kapott információkat felhasználva megtalálhatja a szolgáltatót A Jini szemlélete szerint a grid-alapszolgáltatások is ugyanolyan szolgáltatásnak tekinthet k, mint a Gridben elérhet többi szolgáltatás, emiatt a lookup szolgáltatás igénybevétele is ugyanúgy zajlik, mint egy dzsinn bármilyen más szolgáltatásáé. A Jiniben minden szolgáltatás-igénybevétel a szolgáltató eszközön és az igénybevev eszközön futó programok között zajló kérés-akció-válasz formájában megy végbe. Az igényl eszközön futó program azonban nem közvetlenül a szolgáltató eszközön futó programhoz, hanem egy úgynevezett proxy-hoz intézi a kéréseit (1). A proxy továbbítja a kérést a szolgáltató eszközön futó programnak (2), amely a kérés hatására utasítja a fizikai eszközt valamilyen akció végrehajtására (3). Az akció befejeztével a szolgáltató eszköz programja a proxy közrem ködésével visszaküld egy választ a kliens eszköz programjának (4, 5). A folyamat a 4. ábrán látható:

Szolgáltatást igényl eszköz

Szolgáltató eszköz

Memória

Memória 2

1 Igényl program

5

Szolgáltatás proxy

4

Szolgáltató program

3

3. ábra: Egy szolgáltatás igénybevételének folyamata A proxy a szolgáltató által készített olyan program, amely tudja, hogy hol található a szolgáltatást végz eszköz, és hogy a szolgáltató programnak milyen kéréseket kell küldenie ahhoz, hogy a kért akció végrehajtódjon. Egy szolgáltatás proxy-ja a szolgáltatás dzsinnbe való bekapcsolódásakor a lookup szolgáltatónál kerül letárolásra, mint az egyik, a szolgáltatást jellemz információ. Amikor tehát egy eszköz a dzsinnben valamilyen szolgáltatást keres, akkor számára a szolgáltatáshoz tartozó proxy-nak a megszerzése a cél. Egy szolgáltatás igénybevételének teljes folyamata az alábbi módon zajlik: az igényl eszköz memóriájában futó program valamelyik discovery módszert követve megszerzi a lookup szolgáltató proxy-ját. A proxy-t eltárolja a memóriájában, majd a segítségével a lookup szolgáltató által nyújtott „szolgáltatáskeres szolgáltatás”


igénybevételét kéri. A proxy-hoz intézett kérés tartalmazza mindazokat a feltételeket, melyeknek az igényelt szolgáltatás meg kell hogy feleljen. A proxy továbbítja a kérést a lookup szolgáltatónak, ami ennek hatására megnézi, hogy van-e a nála bejegyzett szolgáltatások között a feltételeknek megfelel . Ha van, akkor eredményként visszaküldi az összes ilyen szolgáltatáshoz tartozó proxy-t, ha nincs, akkor értesíti az igényl t a keresés sikertelenségér l. Sikeres keresés esetén a szolgáltatást igényl eszköz a kapott proxy-k közül bármelyikhez intézheti a kéréseit, mivel a megkapott proxy-k ugyanolyan funkcionalitással rendelkez szolgáltatásokhoz tartoznak. A következ fontos kérdés, ami a Jini nyilvántartó-rendszerével kapcsolatban felmerülhet, a bejegyzések törlése. Ha a dzsinn egy tagja a továbbiakban már nem kíván a többieknek szolgáltatást nyújtani, akkor az általa eddig nyújtott funkcióhoz tartozó információkat a lookup szolgáltató nyilvántartásából törölni kell. Egyszer eset, ha az eszköz önként hagyja el a dzsinnt, mert ilyenkor a törlést maga kezdeményezheti. Ha azonban a szolgáltatásnyújtás megsz nése el re nem látható hardver-, vagy szoftverhiba miatt lép fel, az eszközre vonatkozó bejegyzés törlésére akkor is szükség van. Az ilyen, el re nem látható események nagyban megnehezítik egy valóságh nyilvántartás létrehozását. A Jini ezt a problémát a lízing fogalmának a bevezetésével oldja meg: általában minden szolgáltatást annak igénybevev je a szolgáltatás megkezdését l számítva csak egy adott ideig használhat. Az engedélyezett használati id – a lízing hossza – a használat megkezdésekor kerül megállapításra. A lízing lejártakor a lízingel kérheti a használati id meghosszabbítását, de ha ezt nem teszi, akkor a szolgáltató beszünteti a számára nyújtott tényleges szolgáltató tevékenységét. A lookup szolgáltatás igénybevétele is ilyen minta szerint m ködik. Amikor egy lookup szolgáltató egy szolgáltatás nyilvántartásba vételét vállalja, azt csak egy meghatározott id re teszi. Ha az id lejárta el tt a szolgáltatást nyújtó eszköz nem kéri a lízing meghosszabbítását, a lookup szolgáltató törli a nyilvántartásából. Mivel a meghibásodott eszközök nem képesek a lízing meghosszabbítására, bejegyzésük törl dni fog a dzsinnb l. Minél rövidebb id re lízingelhet tehát egy lookup szolgáltató nyilvántartásba-vételt megvalósító szolgáltatása, annál valóságh bb lesz a nyilvántartás.

2.4 A Sun Jini-implementációja A Sun Microsystems kínál egy Jini implementációt, amely az eddig leírtaknak megfelel en m ködik, és kizárólag Java technológiákat használ. Az implementáció használatával egy IP protokollra épül hálózaton Jini alapú grid-rendszer hozható létre. A követelmény a hálózatba kapcsolt eszközökkel szemben, hogy mindegyik rendelkezzen Java Virtuális Géppel (a továbbiakban JVM), egyedi IP címmel, továbbá képes legyen unicast TCP és multicast UDP üzenetek küldésére. Ezeken kívül – mivel az implementáció er sen épít a Java RMI technológiára – az eszközökkel szemben támasztott további követelmény, hogy képesek legyenek Java objektumok idegen JVM-be történ exportálására. Ennek a feltételnek legegyszer bben megfelel en konfigurált HTTP szerverprogram használatával felelhet meg egy eszköz. Az implementációval létrehozott dzsinnben Java programok kommunikálnak közvetlenül egymással, és közvetve az ket futtató eszközzel. A dzsinn egy részlete az 4. ábrán látható módon képzelhet el.

!

#

"


Unicast TCP és multicast UDP csomagok

Java program Java program JVM Java program

JVM

JVM

Fizikai eszköz

Fizikai eszköz

Fizikai eszköz

4. ábra: A Sun implementációja szerint m köd Dzsinn

Az implementáció részei: Az összes szükséges, továbbá néhány hasznos Jini szolgáltatást megvalósító Java program. (például Lookup szolgáltató program) Egy Jini API (Java osztály- és interfész-gy jtemény), melynek segítségével Jini szolgáltatásokat használni képes kliensprogramok illetve tetsz leges szolgáltatásokat megvalósító szerverprogramok készíthet k. Olyan programok, melyek használata nem kötelez , de az infrastruktúra igénybevételekor rájuk, vagy hasonló funkcionalitású programokra gyakran szükség lehet. (például HTTP szerverprogram)

Mint már említettem, az implementáció er sen épít a Java RMI-re. Ez azt jelenti, hogy az RMI technológiát használja minden olyan esetben, amikor JVM-ek között Java objektumok mozgatására van szükség. Ilyen el fordulhat például két eszköz kommunikációja során, de a leggyakoribb ilyen eset, amikor szolgáltatásokhoz tartozó információkat kell átvinni egyik eszközr l a másikra. Minden szolgáltatást egy rá egyedileg jellemz objektum azonosít. Az ilyen objektumok mind a szolgáltató eszközök és a lookup szolgáltatók, mind a lookup szolgáltatók és a szolgáltatást igényl k között RMI segítségével kerülnek átvitelre. Ez az objektum tartalmazza egyrészt a szolgáltatáshoz tartozó proxy-t, másrészt az úgynevezett attribútumokat, harmadrészt pedig egy egyedi szolgáltatás-azonosítót. A proxy-t és az attribútumokat a szolgáltatást nyújtó eszköz készíti el. Az el bbi feladata a szolgáltatás igénybevételének lehet vé tétele, míg utóbbi a szolgáltatáshoz logikailag vagy fizikailag rendelhet paraméterek halmaza, melyek célja a szolgáltatás funkcionális jellemzése. Ilyen paraméter lehet egy nyomtató szolgáltatásnál például a nyomtató helye, vagy a nyomtatáshoz használható lap mérete. A Jini-szolgatatásokhoz tartozó harmadik paramétert – az azonosítót – ellenben nem a szolgáltató eszköz, hanem az a lookup


szolgáltató generálja, amelyiknél a szolgáltatás el ször kérte regisztrációját. Ennek az azonosítónak a célja, hogy a szolgáltatását globálisan -nem csak az adott dzsinnen belülegyedivé tegye. Minden eszköz számára ajánlatos ezt az els regisztráció során kapott azonosítót eltárolnia, és minden kés bbi regisztráláshoz ugyanezt használnia. Egy szolgáltató dzsinnbe való bekapcsolódásakor tehát ezt a három információt magába záró objektum kerül a dzsinn lookup szolgáltatójánál letárolásra. Azok az eszközök, melyek egy szolgáltatást igénybe szeretnének venni, el ször el kell hogy küldjék a lookup szolgáltatóhoz mindazokat a feltételeket, melyeknek a keresett szolgáltatás meg kell hogy feleljen. Ezután a lookup szolgáltató elvégzi a kritériumok és a nála tárolt objektumok összevetését, és amelyik megfelel a kikötéseknek, azt visszaküldi az igényl nek. Az igényl a kapott objektumban található proxy segítségével ezután kéréseket intézhet a szolgáltatóhoz a korábban említett módon. A szolgáltatás-regisztrálás és szolgáltatás-keresés folyamatát a 5. ábra mutatja.

Lookup szolgáltató

2

Igényl

Szolgáltató

1

3 Proxy

Proxy

Attribútumok

Attribútumok A szolgáltatást jellemz objektum

Azonosító

Azonosító

5. ábra: Egy szolgáltatás-objektum megszerzésének folyamata A folyamat lépései: 1. A szolgáltatás regisztrálása. A szolgáltatást jellemz objektum RMI hívás paramétereként kerül át a lookup szolgáltatóhoz. 2. Szolgáltatás-keresés. A keresett szolgáltatással kapcsolatos kritériumok RMI hívás paramétereként kerülnek átadásra. 3. A megfelel szolgáltatás(ok)hoz tartozó objektum(ok) átküldése az el z RMI hívás visszatérési értékeként. Egy szolgáltatás megkeresésekor a lookup szolgáltatónak átadásra kerül kritériumok vonatkozhatnak az attribútumokra, a proxy-ra és az azonosítóra egyaránt. A kliens kereshet név-attribútuma szerint, vagy kérhet egy olyat, melynek a szolgáltatója a Veszprémi Egyetemen m ködik, mely esetben a hely-attribútum kell hogy megegyezzen az elküldött szöveggel. A proxy-ra vonatkozó kritériumok megadása olyan Java interfész vagy interfészek átadását jelenti, melyeket a proxy objektumnak implementálnia kell. Ilyen kikötésre minden szolgáltatáskeresés alkalmával szükség van, mert ez biztosítja a kliens számára, hogy a kapott proxy-t meg fogja érteni a kéréseit. A szolgáltatás azonosítója szerint történ keresés akkor lehetséges, ha az igényl eszköz korábban már használta a


keresend szolgáltatást. A korábbi használatkor meg volt elégedve vele, ezért eltárolta az azonosítóját, melyet most keresési kritériumként ad át a lookup szolgáltatónak. Éppen az ilyen keresések miatt ajánlatos a szolgáltató eszközöknek a regisztrációjuk során mindig ugyanazt az azonosítót használni. Bármilyen kritérium, vagy kritérium-rendszer alapján is keres egy kliens, eredményül a számára szükséges proxy-t kapja. A proxy-hoz az általa ismert módon kéréseket intéz, melyek hatására az vagy helyi szolgáltatás-nyújtást végez, vagy – ahogy az a 4. ábrán is látható volt – a kérést továbbítása után a távoli gépen történik meg a kiszolgálás. A proxy olyan protokollt kell, hogy használjon a szolgáltató-eszközzel való kommunikációhoz, melyet mind , mind a szolgáltató eszközön futó Java program megért. A teljesen különböz Jini szolgáltatások azonos módon történ igénybevételének ez az alapja. A kliensek szemszögéb l a dzsinn minden szolgáltatása azonos módon, ismert Java interfészen keresztül használható. A klienseknek nem kell tudni a szolgáltató-eszköz által ténylegesen ismert nyelvet, de még a szolgáltató eszköz helyét sem, a tolmács szerepét számukra a proxy tölti be. Ez a megoldás teszi lehet vé azt is, hogy egy dzsinnek bármilyen eszköz, és nem csak számítógép lehet az alkotó eleme.

2.5 A Jini, mint a Grid alap-infrastruktúrája A Jini-t az univerzális szolgáltatásszemlélete, és az egyértelm en definiált szolgáltatás-bejegyzési és szolgáltatás-keresési protokolljai alkalmassá teszik arra, hogy az alapinfrastruktúra szerepét töltse be bármilyen grid-rendszerben. Hogy egy dzsinnt tényleg Gridnek lehessen nevezni, a futtatást végz er forrásokon szükség van egy-egy – a Jini protokollokat alkalmazni képes – szolgáltató-programra, a kliens gépeken pedig a protokollokat szintén ismer kliens alkalmazásokra. Egy er forrásokon futó szolgáltató programnak képesnek kell lennie az adott gép által kínált futtató-szolgáltatás igénybevételéhez szükséges proxy regisztrálására, míg a kliens-programoknak egy megfelel er forráshoz tartozó proxy megtalálására, majd annak a saját JVM-jükbe történ importálására. A proxy letöltése után a grid-szolgáltatás igénybevételével a végrehajtásra szánt programjuk a távoli er forráson futtatható, annak eredménye pedig visszatölthet . A szolgáltatás igénybevételének folyamatát a 6. ábra mutatja.

Futtatandó program

Futási eredmény

Grid kliens program

Grid er forrás

Grid-szolgáltatás proxy-ja

Grid szolgáltató program

JVM

JVM

Tetsz leges protokoll

6. ábra: Egy Jini alapú Grid-szolgáltatás sémája


Mivel a Jini a Java nyelven alapszik, ezért mind a Grid szolgáltató programnak, mind a Grid kliens programnak Java program kell lennie, a köztük lév kommunikációs protokoll pedig csak olyan lehet, amelyet JVM-b l végre lehet hajtani. A kommunikáció során meg kell oldani a kliens programjának és a futtatáshoz szükséges minden egyéb információnak a szolgáltatóhoz való átvitelét, a futtatás befejezése után pedig az eredmények visszahozatalát. A kommunikáció alapulhat egyszer socket-eken, használhat Java RMI-t, CORBA alapú kommunikációt, vagy akár teljesen egyedi megoldást is. A Jini proxy-szemlélete miatt a kliensnek az alkalmazott módszerrel nem kell tör dnie, mert az csak a proxy-ra és a távoli er forráson futó szolgáltató programra tartozik. Amit viszont a kliens programnak mindenképpen tudnia kell, az a proxy használati módja, melynek ismerete nélkül nem képes a szolgáltatás igénybevételére. Az er forráson futó Java szolgáltató-programnak a proxy regisztrálása után késznek kell lennie a távoli proxy-któl jöv kérések fogadására, és a kéréseknek megfelel en programfuttatás irányítására.


3. Párhuzamos PVM programok végrehajtása 3.1 A végrehajtás párhuzamosítása Egy lehetséges módszer a párhuzamosításra a program dekomponálása, processzekre bontásra, melyek közül egyszerre több is futhat, de a processzek között valamilyen szinkronizálásra, kommunikációra van szükség. Az elkészült program futhat akár klaszteren, akár szuperszámítógépen. Egy párhuzamos program megírásakor a processzek között zajló kommunikációnak a kivitelezése jelenti az egyik legnagyobb nehézséget. Vagy el re tudnia kell a programozónak, hogy mikor melyik processz melyik gépen fut – ami nyilvánvalóan lehetetlen – vagy kell valamilyen megoldást találni arra, hogy az ilyen és ehhez hasonló részletekkel a programfejleszt knek ne kelljen foglalkozniuk. Erre a problémára ad megoldást a PVM (Parallel Virtual Machine) [5]. A PVM egy olyan szoftvercsomag, melynek használatával egy hálózat számítógépei a felhasználó számára egyetlen, párhuzamos m ködés virtuális gépnek látszanak. A gépeken futó processzek egymáshoz egységes interfésszel kapcsolódnak, melyen keresztül egymásnak PVM-függvényhívások segítségével üzeneteket küldhetnek. A virtuális gép része lehet bármilyen – els sorban Unix operációs rendszert használó – számítógép, számítógéprendszer. Egy PVM rendszer felépítése az alábbi ábrán látható:

PVM-program

Parallel Virtual Machine PC klaszter

…

MPP

Vektor szuper szg.

PVM-üzenetek

7. ábra: PVM-rendszer A PVM egy absztrakciós szint a párhuzamos program és a hálózat számítógépei között. A virtuális gép létrehozásában bármilyen típusú számítógép részt vehet, melyhez létezik PVM csomag. Egy PVM-program speciális függvényhívásokat használva kommunikálhat a virtuális géppel, mely kommunikáció a számítógépeken futó PVMdémonokkal való kommunikációt jelenti. A rendszer a kommunikáció során elrejti a processzek el l az olyan architektúra-függ információkat, mint például a gépek közötti számábrázolási különbség. Ezt a problémát úgy oldja meg, hogy az üzenetküldés el tt a paramétereket architektúra-független formátumra konvertálja, célba érkezéskor pedig vissza, de már az aktuális számábrázolásnak megfelel en.


3.2 Programok futtatása a helyi PVM-démon felhasználásával A PVM tehát egy olyan infrastruktúra, amely biztosítja a különböz gépeken futó processzek számára a kommunikációs csatornát, továbbá definiál egy hozzá való protokollt. Ahhoz, hogy ez az infrastruktúra egy program számára rendelkezésre álljon, a program tulajdonosának a futtatás el tt létre kell hoznia a virtuális gépet, melynek azon rendszerek lehetnek tagjai, amelyeken a felhasználónak joga van használni a helyi PVMdémont. Ezek után elindítható a program, amely a virtuális gépen belül létrehozza a kit zött feladatot megoldó PVM-processzeket. Fontos megjegyezni, közvetlenül a futtatás el tt az alábbi két dolgot kell tenni:

1. A programot minden olyan architektúrán lefordítani, amely a virtuális gépet alkotó számítógépek között megtalálható. 2. A lefordított állományokat abba a könyvtárba másolni, ahol a PVM a futás során a létrehozandó PVM-processzek forrását keresni fogja. Ennek a jegyzéknek a neve a PVM dokumentációjában megtalálható. (Általában $HOME/pvm3/$ARCH/bin.) A rendszeren belül a PVM-processzek tényleges futási helyét csak a PVM ismeri, a programozó nem. A processzek megszületésükkor a PVM-rendszert l egyedi azonosítót kapnak, melyek ismeretében egymásnak üzeneteket küldhetnek. A PVM gondoskodik arról, hogy egy üzenet eljusson a megadott azonosítóval rendelkez processzhez, vagyis egy üzenetet küld processznek csak a címzett processz azonosítóját kell ismernie, a futási helyét nem. A PVM ezen a szolgáltatásokon kívül semmi többletet nem ad a futtatás megkönnyitésére, és ez különösen a hosszú ideig (napokig vagy akár hetekig) futó programok esetén jelent nehézséget. Nem ritka az ilyen hosszú futású program, mivel a PVM-et gyakran használják olyan mérnöki, fizikai, biológiai számításokat igényl feladatokhoz, melyek során aránylag nem túl bonyolult m veleteket kell végrehajtani nagy mennyiség adaton. Az ilyen, és ehhez hasonló feladatok során elvégzend lebeg pontos számítások pedig rendkívül megnövelik a futási id t. A futtatás során a probléma jelentkezhet akkor, ha egyszerre több programot indítunk ugyanazon a virtuális gépen. Ilyenkor az ugyanabban a virtuális gépben futó, különböz alkalmazásokhoz tartozó PVM-processzek képesek egymásnak üzenetet küldeni, nincs semmi védelem, ami elkülönítené ket. Ez kiszámíthatatlan viselkedést okozhat a programokban, és ellehetetleníti az utólagos hibakeresést. További nehézséget okozhat – de még a futtatás el tt – a virtuális gép létrehozása, vagyis az er forrás-allokálás. Ez a folyamat azt jelenti, hogy a rendelkezésre álló er források közül ki kell választani azokat, amelyeket egy adott program futtatásához használni szeretnénk, vagyis amelyekb l a virtuális gépet létre kívánjuk hozni. PVMdémonon keresztül végzett futtatás esetén ez teljes mértékben a program tulajdonosára hárul, és közel sem egyszer feladat. Tudnia kell hogy pontosan milyen gépek érhet k el a hálózatban, és nem árt ismerni azok aktuális leterheltségét sem. A leterheltséget figyelembe véve elkerülhet , hogy egy túlterhelt gépen futó processz a kommunikációban fellép késleltetésekkel visszafogja a többi, kevésbé terhelt gépen futót. Ilyen nem egyenletes leterheltség különösen olyan ipari környezetben fordulhat el , ahol a helyi klaszter munkaállomásait els sorban a napi ügyek intézésére használják, párhuzamos programok futtatása csak másodlagos. Ilyen helyen csak olyan gépet ajánlatos a virtuális gép létrehozásakor felhasználni, amelyik éppen szabad, vagyis annak tulajdonosa nem


használ rajta semmilyen programot. Hogy egy egyszer felhasználó ezt hogyan tudja kideríteni, arra sok esetben egyáltalán nincs megoldás, de ha mégis valamilyen módon képes felmérni a helyi hálózat gépeit, abból akkor sem tud következteti a következ pár perc vagy óra történéseire.

3.3 PVM programok futtatása Condorral Az említett problémák megoldására szükség van egy olyan programra, amelyik egyrészt minden PVM-program számára új virtuális gépet hoz létre, másrészt az aktuális terheltségt l függ en változtatja a PVM-ek létrehozásában részt vev gépek halmazát. Ez a szoftver a felhasználóknak magasabb szint szolgáltatást nyújt, mint egy sima PVMdémon, elrejtve el lük a futtatás valódi menetét. Ezek a szoftverkomponensnek a jobmenedzserek. Használata esetén a felhasználók nem a virtuális géppel, hanem vele tartják a kapcsolatot, lényegében nem is kell tudniuk arról, hogy a PVM-programok futtatásához virtuális gépre is szükség van. Egy ilyen jobkezel program a Wisconsin-Madison Egyetem által kifejlesztett Condor. A cél, amiért a Condort létrehozták: lehet vé tenni az úgynevezett high throughput computing nagy számú, különböz tulajdonosokhoz tartozó számítógépek egyegységbe foglalásával [18]. Egy Condor-rendszer sémája az alábbi ábrán látható:

PVM-program

Java-program

MPI-program

Globus-program

...

Condor

Tényleges futtató környezetek, virtuális gépek Fizikai er forrás 1

Fizikai er forrás 2

Fizikai er forrás N

...

A hálózat fizikai megvalósítása

8. ábra: Condor futtató rendszer Mint látható, a Condor nem csak PVM-programokat, hanem más típusú, mind szekvenciális, mind párhuzamos programokat fogad. Elrejti a tényleges futtató környezeteket a felhasználók el l, akiknek egy program futtatásakor csupán annyit a feladatuk, hogy elkészítenek egy megfelel job-leíró fájlt, melyet azután átadnak a jobkezel nek.

Ebben a job-leíró fájlban szerepl alapvet adatok: A futtatandó program típusa A futtatható állomány neve Futási paraméterek Standard input-ot helyettesít fájl neve A program számára beállítandó környezeti változók Futás közbeni eseményekr l készítend naplófájl neve


A Condor a fájl tartalma alapján létrehoz egy új futási környezetet, elindítja a futtatható állományt a megadott környezeti változókkal, majd végig a futása során a fontosabb eseményekr l bejegyzéseket készít a megadott naplófájlba. A program tulajdonosa a napló fájlból értesülhet például arról is, hogy job-jának a futása – akár sikeresen, akár sikertelenül – befejez dött. Amit mindenképpen meg kell jegyezni, hogy a Condor ugyan sok tekintetben magasabb szint szolgáltatást nyújt, mint a PVM, viszont cserébe fel kell áldozni a programok interaktivitását. Condor-on keresztül ugyanis nem lehet interaktív alkalmazásokat futtatni. Mint az el bbi felsorolásból látszik, a felhasználónak már a program elindítása el tt tudnia kell, hogy mi lesz annak bemenete, ugyanis az adatokat a futtatás el tt egy állományba kell írnia, majd az állományt a leíró fájlban meghivatkoznia. A Condor garantálja, hogy a futó program a hivatkozott fájlt fogja standard bemenetének tekinteni, és nem a billenty zetet. Ez, a PVM-démonhoz képest jelent snek t n megszorítás PVM-programok esetén szerencsére nem jelent gondot, ugyanis a PVMalkalmazások által végzett számítások bemen adatai általában el re ismertek, vagy futás közben generálódnak.

3.4 A Condor, mint erőforrásmenedzser A Condor az el bb leírtak értelmében tehát képes a felhasználó helyett a PVM létrehozására, és a futó programok folyamatos felügyeletére. Az ok azonban, amiért általában a felhasználók a Condor mellett döntenek, az az er forrásmenedzseri képessége. A Condor nem csak a futtatásra átadott programokat, hanem a hálózatban er forrásként üzemel gépeket is képes nyilvántartani. Az általa menedzselt hálózat minden gépén rendelkezik egy helyi démonnal, melyen keresztül folyamatosan figyelemmel kísérheti annak terheltségét. A terheltség függvényében bármelyik er forrást képes hozzácsatolni, illetve kivenni a programfuttatásra használható gépek halmazából. A leggyakoribb allokálási politika, amit Condor esetében alkalmaznak a következ : minden olyan gép, melyet x perce nem használt annak tulajdonosa, az kerüljön a központi Condor menedzser fennhatósága alá. Ha azonban megérkezik a tulajdonos, akkor t illeti az els bbség. Ha az x id intervallumnak a hosszát a rendszergazda alkalmasan választja meg, akkor egy ilyen – Condor esetén egyszer en konfigurálható – megoldással kisz rheti a korábban már említett kávészünetek miatt pihen er forrásokat a ténylegesen szabad gépek közül. A Condor egy program futtatásakor a politikája által szabadnak ítélt gépek halmazából választ a virtuális gép felépítéséhez. Az allokálási procedúra során azonban nem csak az er forrás-felajánlókra, de a job-ot futtatók igényeire is figyel. A Condorfelhasználók a job-leíró fájlokban megadhatnak a futtatáshoz használandó architektúrákra vonatkozó kikötéseket, prioritásokat. A Condor ezeket az információkat figyelembe véve próbálja a szabad gépek közül kiválasztani a legalkalmasabbakat a futtató környezet felépítéséhez. Ha éppen nincs olyan architektuájú gép, mint amit a kliens igényelt, akkor a Condor egyáltalán nem allokál er forrást, ennek okát pedig a naplófájlba írja. A Condor megoldja mindazokat a problémákat, melyek az egyszer PVM-démonon keresztüli program-futtatás során felmerültek. A korábban említett „interaktivitás hiányá”-n kívül azonban még egy problémája van: a Condor segítségével futtatott PVMprogramoknak más módon kell létrehozniuk a PVM-processzeket, mint PVM-démonnal való futtatás esetén. Emiatt a felhasználóknak már a programjuk fejlesztése során tudniuk kell, hogy az kés bb Condorral, vagy PVM-démonnal lesz-e futtatva.


3.5 A PVM és a Condor szerepe a Gridben Mint a fejezet els részb l kiderült, a PVM összefogja a lokális hálózat gépeit, és bel lük nagyobb egységeket képez. Egy ilyen nagyobb egység – egy párhuzamos virtuális gép – a processzek számára biztosított kommunikációs infrastruktúra miatt sokkal nagyobb számítási kapacitást képvisel, mint az t alkotó fizikai er források kapacitásának az összege. Mivel a Gridben a cél a nagy kapacitást igényl programok futtatása, ezért kézenfekv nek t nik egy olyan grid-rendszer létrehozása, melynek alapegységeit nem önálló gépek, hanem PVM-ek adják. Az ilyen számítási rendszer neve PVM-Grid, és jellemz tulajdonsága, hogy a benne található er források mind párhuzamos virtuális gépek. A PVM-Grid infrastruktúrát biztosít egyrészt a klienseknek a legmegfelel bb PVM kiválasztásához, másrészt a PVMprocesszeknek a kiválasztott virtuális gépen belüli hatékony kommunikációhoz. Mint az a második részben látható volt, a helyi hálózatban él PVM-démon nem biztosít elég magas szint szolgáltatást, vagyis a Condor-hoz kellett fordulni. A PVM-Grid esetén még ez a szint sem elegend , ugyanis a Condor-t általában csak a helyi hálózat er forrásmenedzsereként használják. Ilyen esetben csak a helyi hálózat gépeit használhatja programfuttatáshoz, de ami a legfontosabb, hogy ilyenkor csak a helyi hálózat felhasználói érhetik el. Ez utóbbi tulajdonság miatt egyetlen Condor-klaszter nem tekinthet gridrendszernek. A Condor lehet séget biztosít azonban arra, hogy több klaszter összekötésével úgynevezett barátságos pool-t hozzunk létre, melynek egyetlen Condor-példány az er forrás- és jobmenedzsere. Ilyen esetben el fordulhat, hogy a barátságos pool egyik felhasználója által submitált job olyan gépeken is futni fog, melyhez az illet nek nincs felhasználói fiókja. Ennek oka, hogy a Condor megengedi a barátságos pool-on belül a jobok tetsz leges gépen való futását. A felépítésnek azonban van két nagy hátránya, melyek miatt a gyakorlatban csak ritkán alkalmazzák:

1.

2.

A klaszterek között meg kell nyitni minden egyes portot. Ez akkora biztonsági rést jelenthet, hogy tényleg csak a legjobb „barátok” engedhetik meg maguknak a közös Condor használatát. Ha valamelyik barátságos klaszter ki akar lépni a szövetségb l, vagy egy új klaszter akar belépni a barátságos klaszterek közé, akkor a pool minden egyes résztvev jének módosítani kell néhány konfigurációs fájlt. Ez néhány tag esetén még elviselhet , de nagy méret Grid esetén nyilván kivitelezhetetlen.

Ha több száz, vagy ezer klaszterb l álló Gridet akarunk létrehozni, akkor a Condor önmagában nem nyújthat megoldást. Ennyi felhasználó nem bízik meg egymásban annyira, hogy barátságos pool-t hozzanak létre, és egyébként is túl bonyolult a rendszer menedzselése. A Condor tehát PVM-gridekben a klaszterek közötti infrastruktúraként nem használható, viszont klaszteren belül jól funkcionál. Emiatt érdemes a távoli kliensek számára futtató szolgáltatást nyújtó program, és a klasztert alkotó fizikai er források közötti rétegként alkalmazni. Ez a struktúra látható a 9. ábrán.


Grid-infrastruktúra

Gép 1



Condor

Condor

Gép 2

...

Lokális hálózat 1

Gép M

. . .

Gép 1

Gép 2

...

Gép N

Lokális hálózat P

9. ábra: A Condor szerepe a Gridben Ilyen esetben a Grid infrastruktúrája a klaszterek közötti, míg a Condor a klasztereken belüli er forrás-allokációt végzi. Mivel a Condor a PVM-programok számára nem transzparens – a programoknak máshogyan kell Condor esetén a PVM-processzeket létrehozniuk – ezért a Grid klienseinek tudnia kell a Condor létezésér l. Ha viszont tudnak a Condor-ról, akkor akár a klaszteren belüli gépallokációhoz is kritériumokat adhatnak. Ha ezeket a kritériumokat a klaszter szolgáltató programja továbbítja a Condor-nak, akkor annak a gépallokáció során mind a rendszergazda által beállított politikára, mind a kapott igényekre tekintettel kell lennie. Ha viszont a kikötéseket a szolgáltató program nem továbbítja, akkor a Grid kliensei csak klasztert, és nem konkrét er forrásokat választhatnak programjaiknak.


4. PVM alkalmazások végrehajtása Jini alapon A rendszernek lehet vé kell tennie, hogy egy Jini alapú hálózatban a hálózat egyik gépén megírt PVM-program a hálózat egy másik részén m köd PVM virtuális gépen fusson le akár PVM-démon, akár Condor támogatásával. Az elindított PVM-programok futás közben képesek a távoli monitoroknak állapotinformációkat küldeni, futásuk befejeztével pedig az eredmények automatikusan kerülnek vissza a kliensekhez. Egy alkalmasan megírt programmal egy dzsinnben, (dzsinnekben) bejegyezhet a „PVM-program futtató és monitorozó” szolgáltatás, melynek igénybevételével a kliensgépek távoli er forrásokat választhatnak a végrehajtandó programjaikhoz. A szolgáltatást nyújtó eszköz lehet bármilyen számítógép vagy számítógép-rendszer, az egyetlen kikötés vele szemben hogy rendelkezzen JVM-mel és PVM-mel, illetve opcionálisan Condor-ral. Ha a szolgáltató oldalon nincs Condor, akkor a kliensek job-jai egyszer PVM-démonon kereszül lesznek futtatva, ellenkez esetben viszont Condor-ral. A legcélszer bb és legegyszer bb, ha egy klaszter végzi ezt a szolgáltató tevékenységet, ezért a kés bbiekben a szolgáltató-eszközöket végig klasztereknek tekinthet .

4.1 A Jini használata A rendszerben a Jini-t, mint a PVM-Grid infrastruktúráját használom. A következ felsorolásban áttekintem mindazokat a Jini funkcionalitásokat, melyeket ki fog használni a rendszer:

Szolgáltatás-központú szemlélet: A Jini a hálózatot szolgáltatók, és szolgáltatás-igényl k hálózatának tekinti. Ez a szemlélet megfelel az aktuális helyzetnek. Szolgáltatónak tekinthet k mindazon PVMklaszterek, melyeket tulajdonosuk, mint futtató er forrást kínál mások számára. Szolgáltatás-igényl nek tekinthet k mindazon gépek, melyeken futtatásra és monitorozásra váró PVM-program található. Ezen igényl k és szolgáltatók egymásra találására a dzsinnek lookup szolgáltatásai adnak lehet séget. Dinamikusan változó hálózatban m ködik: A lookup szolgáltatás segítségével a hálózatban elérhet klaszterek dinamikusan változó halmaza könnyen nyilvántartható. A lízingelés miatt a nyilvántartás a valóságnak (majdnem tökéletesen) megfelel adatokat fog tartalmazni. Az igényl k emiatt biztosak lehetnek benne, hogy a kiválasztott klaszter jelen pillanatban „szabad”, vagyis az átküldött PVM-program a távoli virtuális gépen azonnal elindul. Nem okoz a klaszter tulajdonosának plusz kiadást: A program az ingyenesen elérhet Java, Jini, PVM és Condor programokat használja, ezért a szolgáltatót semmilyen kiadás nem terheli. A PVM-klaszterek tulajdonosai ezért mások számára a szolgáltatást akár ingyen is nyújthatják. TCP/IP alapú hálózatban alkalmazható: dzsinnek létrehozhatók az Internetre alapozva, vagyis a program a már meglév globális számítógép hálózatnak adna egy újabb funkcionalitást. Nem a szolgáltató-rendszert, hanem csak egy funkciót tesz a kliensek számára láthatóvá:


A teljes klaszter helyett a kliensek csak a lookup szolgáltatóknál közzétett proxy-t kapják meg. Kizárólag a proxy-n keresztül intézhet kérés a szolgáltatóhoz, tehát mind a szolgáltató program, mind az azt futtató eszköz a kliensek el l rejtve marad, a szolgáltatásnyújtás biztonsága javul. Ellen rzött módon végezhet idegen PVM-programok futtatása: A kliensekt l kapott PVM-programok futtatását a szolgáltató oldalon futó Java-program kezdeményezi. Ez a program egy el re megadott feltételrendszer alapján dönthet a kliensek megbízhatóságáról, a futtatás engedélyezésér l. Mind a kliens-, mind a szolgáltatói oldalon pontosan megadhatók azok a m veletek, melyeket az idegen forrásból származó kódoknak joguk van elvégezni, más dolgokat viszont nem. Automatikus szolgáltatás-igénylés és használat: A Jini koncepcióban a szolgáltatók és a szolgáltatás-igényl k nem emberek, hanem szoftverek, vagyis a szolgáltatás igénybevétele automatizálható. A PVM-programok futtatását a kliensek által írt Java-programok kezdeményezhetik, mely kéréseket a szolgáltató klaszteren futó Java-program emberi beavatkozás nélkül kiszolgál. A teljes folyamat emiatt jóval rövidebb id alatt lezajlik, mint bármely más módszerrel, vagyis a hálózat gépeinek állásideje csökken, kihasználtságuk hatásfoka növekszik.

4.2 A rendszer követelményei Jini alapon Írni kell egy olyan szolgáltató program - proxy párt, amely képes megvalósítani az alábbi szolgáltatást: A szolgáltatást igényl számítógépr l áttölti magához a kliens által megadott PVMprogramot. A helyi Condort vagy PVM-démont használva lefuttatja azt. Képes a PVM-programok monitorozásához támogatást adni. A futási eredményeket visszatölti a kliens gépére.

A feladat megoldása el tt az alábbi pontosításokat teszem:

1.

Lefordított PVM-program kerül áttöltésre: A kikötés a PVM-fejleszt k szempontjából teszi biztonságosabbá a szolgáltatás igénybevételét: nem kerülhet illetéktelen kezekbe a forráskód. A hátránya, hogy a futtatandó PVM-programhoz olyan szolgáltatót kell keresni, akinek a klasztere ugyanolyan architektúrájú gépekb l áll, mint amilyenen a PVM-program le lett fordítva. Ennek oka a korábban említett PVM tulajdonság, vagyis hogy egy PVM programot a futtatás el tt minden olyan architektúrán le kell fordítani, amely a virtuális gépben szerepel. A szolgáltató oldalon emiatt célszer szolgáltatóeszközként olyan klasztert használni, amely sok azonos felépítés , és széles körben használt architektúrájú gépb l áll. Az architektúrát jellemz tulajdonságokat azután a kliensek számára elérhet vé kell tenni, máskülönben csak a programjuk elindításakor derül ki, hogy nem megfelel architektúrájú klasztert választottak. A futtatandó PVM-program nem interaktív: Erre a kikötésre két ok miatt van szükség: 1. Condort használva nem lehet interaktív PVM-programokat futtatni. 2. PVM-et használva ugyan lehet, de ha a szolgáltatóhoz feltöltött programok id nként leállnának felhasználói inputra várakozva, azzal más programok el l foglalnák a számítási kapacitást, a klaszterek kihasználtsága jelent sen romlana.

2.


3.

A kliensnek el re meg kell adniuk, hogy a PVM-programjaik futtatása során milyen kimeneti fájlok fognak keletkezni: Mind a kliens, mind a szolgáltató szempontjából kényelmesebbé teszi a szolgáltatás használatát. A kliens számára könnyebb debuggolást, a szolgáltató számára egyszer bb implementálást biztosít. A rendszer a SZTAKI GRM/PROVE eszközével végzett monitorozáshoz ad támogatást: A monitorozás csak akkor m ködik, ha a kliens a SZTAKI Instrumentation API-jával instrumentált és P-GRADE-del lefordított párhuzamos programot submitál.

4.

4.3 Egy PVM-program futtatásának forgatókönyve (A szolgáltatás regisztrálása és a szolgáltatáshoz tartozó proxy-nak a letöltése a korábban leírt módon történik, arra itt külön nem térünk ki.) 1. A kliens átadja a proxy-nak a lefordított PVM programot, a futtatáshoz szükséges információkat, és az eredményként visszavárt fájlok neveit. 2. A proxy eljuttatja a kapott adatokat a szolgáltatónak. 3. A szolgáltató a helyi er forrásokat használva elvégzi a futtatást. 4. Futás közben a PVM-program trace-információkat küld a kliens oldali monitornak. 5. A futtatás eredményeképpen a szolgáltató gépen el áll a futási eredmény. 6. A kért eredményt a szolgáltató visszaküldi a proxy-nak. 7. A proxy menti az eredményt a kliens gépére. 8. Törl dnek a szolgáltató oldalon a feleslegessé vált állományok: a PVM-program és a futási eredmény.

A folyamat az alábbi ábrán látható: Igényl

4

Szolgáltató (PVM-klaszter)

Monitor PVM-program

2 1

3

8 Proxy

Futási eredmény

PVM-program

7

6

Futási eredmény

5

PVMdémon vagy Condor

10. ábra: A szolgáltatás igénybevételének folyamata

A szolgáltatóhoz átküldend állományok – melyeket mind a kliensnek kell elkészítenie a szolgáltatás igénybevétele el tt – az alábbiak: Az opcionálisan inkementált, majd lefordított PVM-program. A futtatáshoz szükséges információkat tartalmazó fájl, melynek tartalma: A futtatható állomány neve. Az indításkor átadandó paraméterek listája.


A PVM megfelel könyvtárába másolandó állományok listája. (Amelyek a pvm_spawn függvényhívások alkalmával a létrejöv processzek forrását adják.) A program standard inputját tartalmazó fájl neve. A program számára beállítandó környezeti változók nevei és értékei. Az eredményfájlokra vonatkozó információk.

A futtatáshoz szükséges információs fájlban ezek közül csak az els dolognak, a futtatható állomány nevének kell minden esetben szerepelnie. Ha a többi információ hiányzik, akkor a PVM-program nem igényel indítási paramétereket, nem külön fájlokból veszi a PVM-processzek forráskódját (mint például a P-GRADE-del lefordított PVMprogramok), nem olvas be a standard input stream-r l, nem használ környezeti változókat, és nem készít kimeneti fájlokat. Habár ilyen PVM-program is elképzelhet , nyilván nem ez az általános, emiatt kell a szolgáltató programnak támogatást adnia a felsorolt beállításokra. Ha a program nem készít kimeneti fájlokat, attól még lehet eredménye, csak éppen azt a képerny re, és nem fájlba írja. Emiatt a PVM-programok standard output-ját minden esetben fájlba kell menteni, és azt a kliensek számára eredményként visszaszállítani. Hálózaton történ továbbítás el tt célszer a továbbítandó állományokat összetömöríteni, mely két el nnyel is jár:

Csökken a továbbítandó adathalmaz mérete. Csak egyetlen fájl átvitelével kell foglalkozni. Hálózaton keresztüli fájltovábbítás a szolgáltatás használata során kétszer is el fordul: el ször a programfájlok mozognak a szolgáltató rendszerhez, másodszor pedig az eredményfájlok a klienshez. A szolgáltatói oldalon a szolgáltatást nyújtó Java programnak kell elvégeznie a ki-, illetve betömörítést. A kliens oldalon viszont erre több lehet ség is adott:

1. 2. 3. 4.

A proxy végzi mind a be-, mind a kitömörítést. A kliens programja végzi mind a be-, mind a kitömörítést. A kliens programja végzi a betömörítést, de a proxy a kitömörítést. A proxy végzi a betömörítést, de a kliens programja a kitömörítést.

A lehet ségek közül az utolsó két módszernek csak igen speciális esetekben lenne haszna, ezért az implementáláskor az els két variáció közül érdemes választani. Ha a proxy végzi el a be- és kitömörítést, az azzal az el nnyel jár, hogy a kliensnek nem kell tudnia arról, hogy az állományok tömörített formában mozognak a gépe és a futtatást végz klaszter között. A tömörítéshez használt eljárást ekkor a szolgáltató választhatja meg, és az alkalmazott módszeren bármikor változtathat. Változtatás esetén a lookup szolgáltatóknál elhelyezet proxy-t kell az újabbal lecserélni. Hátránya viszont, hogy a kliens oldalon a letöltött proxy számára fájl-hozzáférési jogokat kell adni, mely biztonsági kockázatot jelenthet a szolgáltatás használatakor. A második módszer el nye, hogy a kliens el re elkészítheti a tömörített állományt, a proxy-nak emiatt nem kell többlet-hozzáférési jogokat adni. Hátrány viszont, hogy a kliensnek olyan formátumra kell tömörítenie a fájlokat, melyet a szolgáltató vár. Emiatt a lookup szolgáltatónál történ szolgáltatás-kereséskor a kliensnek a tömörítési módszerre vonatkozó kritériumot is adnia kell. Én ezt a módszert választottam, amely ugyan többletmunkát okoz a kliensnek, viszont biztonságosabbá teszi a szolgáltatás használatát. A kliens maga csomagolja össze az átvitelre kerül állományokat, vagyis biztos lehet benne,


hogy csak az kerül ki a gépér l, amire engedélyt adott. Csomagoláshoz a JAR fájlformátumot használtam, melynek el nyei [3]:

Nem csak csomagolást, hanem tömörítést is lehet vé tesz. A Java API-szinten támogatja a JAR fájlok létrehozását, kicsomagolását. Digitális aláírás csatolható hozzá.

Az els tulajdonságból adódó el ny nyilvánvaló: csökken a hálózat igénybevétele. A második pontban felsorolt tulajdonság miatt Java programból metódushívásokkal végezhet a ki- és becsomagolás, nincs szükség rendszerhívásokra, vagyis tovább n a biztonság. Az utolsó tulajdonságból adódó el nyöket a jelenlegi implementációban nem használtam ki, de egy továbbfejlesztett változatban szükség lehet aláírt fájlokra a résztvev felek kölcsönös azonosításához. Ha digitálisan aláírt JAR fájlban kerül a szolgáltatóhoz egy PVM-program, akkor a szolgáltató dönthet arról, hogy a programot futtatja-e, és ha igen, akkor milyen jogokkal. A szolgáltatás használója pedig biztos lehet benne, hogy tényleg a szolgáltatótól származnak a futtatás után eredményül kapott fájlok.

4.4 A szolgáltatás használata A szolgáltatás megtalálása a korábban említett módon történik: az igényl a lookup szolgáltatóhoz elküldi mindazokat a kritériumokat, melyeknek a szolgáltatás meg kell hogy feleljen. A kritériumok között lehetnek a futtató klaszter architektúrájára, helyére, tulajdonosára vonatkozó kikötések, de a legfontosabb, hogy a kliens ismerjen egy interfészt, melyet a szolgáltatás proxy-ja implementál. A kliens számára az egész szolgáltatásból ez az egyetlen interfész látható, mivel ennek a metódusait fogja meghívni a szolgáltatás használatakor. A szolgáltatás megtervezését ennek az interfésznek a megírásával kell kezdeni. Az interfészen kívül a lookup szolgáltatónál bejegyzett attribútumok segíthetnek még a kliensnek abban, hogy a szolgáltatás min ségére el zetes becsléseket tehessen. Ha el re tudja például a klasztert felépít gépek teljesítményét, azzal becslést adhat a program várható futási idejére. A proxy interfészének azokat a metódusokat kell tartalmaznia, melyek meghívásának feladata mind a kliensre hárul a szolgáltatás használata során. Mivel célom volt minél könnyebbé tenni a Grid használatát, ezért ezt az interfészt olyan egyszer re terveztem, amennyire csak lehetett. A futtatás-procedúra egyetlen metódushívással kezdeményezhet , mely metódusnak csupán a korábban említett JAR fájlt kell átadni. A metódus visszatérési értéke egy egyedi azonosító, mellyel a felhasználó a submitált job-ra kés bb bármikor hivatkozhat. Ez az „azonosító-használat” a következ el nnyel jár: a kliens program nem blokkolódik a metódushíváson az elküldött párhuzamos program futása alatt. Ez az egyetlen tulajdonság számos el nyt okoz a szolgáltatás használatában:

Az azonosító kézhezvétele után a kliens program bármilyen más teend t végezhet, nem kell a submitált programmal tovább foglalkoznia. Nincs szükség további kommunikációra a szolgáltatóval a futtatás alatt, vagyis az igényl eszköz akár a hálózatról is lekapcsolódhat. Ez a lehet ség hatalmas el ny lehet, ha a PVM-programot mobil eszközr l submitálta a kliens. A Jini-t kifejezetten arra tervezték, hogy mobil és fix telepítés eszközöket azonos módon lehessen használni, ez az azonosító-használat pedig jól illeszkedik ebbe a képbe.


A kliensek esetleges meghibásodásától védve van a szolgáltató, hiszen a submitálást követ en tovább már nincs köztük kapcsolat. Az azonosítót a submitálás során a szolgáltató oldali Java program generálja, majd a proxy segítségével küldi vissza azt a kliensnek. Az azonosító az adott szolgáltató eszközön belül egyedi érték, vagyis egyértelm en azonosít egy PVM-programot. A PVM-program futásának befejez dése után a kliens az azonosító segítségével kérheti a proxy-t a futási eredmények visszatöltésére. Az eredményletöltéshez használt proxy természetesen ugyanahhoz a szolgáltató-eszközhöz kell hogy tartozzon, amelyhez a kliens el z leg elküldte a párhuzamos programját. A proxy lehet ugyanaz a példány, melyet a kliensprogram akkor használt – ekkor a submitálás után azt el kellett menteni valamilyen háttértárolóra – vagy lehet egy azóta letöltött példány is. Az azonosító visszaküldése után a szolgáltató kicsomagolja a proxy-tól a kapott fájlt, a helyi Condor vagy PVM-démon segítségével lefuttatja a benne található PVM-programot a mellékelt információk alapján, majd az eredményeket JAR fájllá tömöríti. A proxy a kliens kérésére ett l kezdve bármikor elvégezheti az eredményeket tartalmazó JAR fájl letöltését. Már csak az a kérdés, hogy ezek a JAR fájlok hogyan fognak mozogni az érintett felek között. A legegyszer bb megoldás, ha mind a kliens, mind a szolgáltató oldalán a fájlok elérhet k valamilyen fájl-szerveren (HTTP, FTP szerveren) keresztül. Ekkor a proxy és a szolgáltató program között csak a fájlok URL-jei, és nem maguk az adatok mozognak. A kliensnek submitáláskor nem a lefordított programot tartalmazó JAR fájlt, hanem csak annak URL-jét kell átadnia a proxy-nak, ami továbbítja a címet a szolgáltató oldali programnak, ami ezután letöltheti a kapott URL-r l a fájlt. Legkézenfekv bb a kliensnek a saját gépén indítania a fájlszervert – például a Jini implementációban található egyszer HTTP szervert – de ez nem kikötés. Mobil eszközr l végzett submitálás esetén el fordulhat, hogy a kliens nem a saját gépén, hanem egy idegen gépen lév PVMprogramot szeretne a Gridben futtatni. A 11. ábra ezt az esetet mutatja, vagyis nem kett , hanem három gép vesz részt a folyamatban.

PVM-programot tartalmazó host Program JAR fájl

HTTP/FTP/… szerver

Szolgáltatás-igényl host

JAR fájl

5 Futtató rendszer

(például mobiltelefon)

1 Kliens program

URL

4

2 URL Proxy

3 azonosító


6

azonosító

11. ábra: Egy PVM-program submitálásának folyamata

PVMprogram


A submitálás menete a következ : 1. A kliens meghívja a proxy interfészének megfelel metódusát, melynek paraméterként átadja a JAR fájl URL-jét. 2. A proxy a hálózaton keresztül továbbítja a címet a távoli er forrásnak. 3. A szolgáltató program visszaküld egy azonosítót a proxy-nak. 4. A proxy továbbítja az azonosítót a kliens programjának, ami elmenti azt a kés bbi hivatkozások miatt. 5. A szolgáltató program letölti a JAR fájlt. 6. A szolgáltató program kicsomagolja a letöltött fájlt.

A futtatás végeztével az eredményeket tartalmazó archív fájl az el z ekhez hasonlóan kerülhet vissza a kliens gépére: a proxy a szolgáltató programtól URL-t kap, ahonnan ezután letölti az eredményeket tartalmazó JAR fájlt. A proxy kérését kiszolgáló fájlszervernek a szolgáltató klaszter valamelyik gépén kell m ködnie, és el kell érnie minden, az adott klaszteren már lefutott PVM-program eredményét. Az eredmények áttöltésének menetét mutatja a 12. ábra.

Eredmény-igényl host

Futtató rendszer

Kliens program

1

2 Proxy

5 Eredmény JAR fájl

3


URL

4 JAR fájl

HTTP/FTP/… szerver

Eredmény JAR fájl

12. ábra: A futási eredmények visszahozatalának folyamata

A folyamat lépései: 1. A kliens meghívja a proxy interfészéb l az eredmények visszahozatalát kezdeményez metódust. 2. A proxy kérést intéz a szolgáltató programhoz, hogy megtudja vajon befejez dötte a PVM-program futása. Ha nem, akkor értesíti a kliens, különben továbblép a 3. pontra. 3. A szolgáltató programtól a proxy lekérdezi az eredményeket tartalmazó JAR fájl URL-jét. 4. Letölti a fájlt. 5. A kliens gépén a kért jegyzékbe menti a JAR állományt.


Fontos megjegyezni, hogy az eredmények visszahozatalát kezdeményez host nem szükségszer en ugyanaz, mint amelyik a PVM-programot submitálta! Az eredményeket bárki lekérdezheti, aki ismeri a submitáláskor kapott azonosítót.

4.5 A szolgáltató program megtervezése Az el z részben látható volt, hogy a szolgáltatás folyamata során több alkalommal is szükség van a proxy és a távoli klaszteren futó szolgáltató program közötti kommunikációra. A szolgáltatóprogram megtervezését ennek a kommunikációnak a tanulmányozásával kell elkezdeni. Az alábbi felsorolás összefoglalja, hogy mikor és pontosan milyen üzenetváltásokra van szükség a két fél között:

Proxy

Szolgáltató program: submitáláskor: URL eredmény letöltéskor: job azonosító letöltés befejez dését jelöl információ Szolgáltató program Proxy: submitáláskor: job azonosító eredmény letöltéskor: URL, vagy a program futását jelz adat

A proxy-tól a szolgáltató felé men URL-r l már korábban szó esett, és az eredmény letöltésekor átadandó job azonosító sem jelent újdonságot. Az els új dolgot a letöltés befejez dését jelöl információ jelenti. Erre azért van szükség, hogy a szolgáltató oldal tudja, hogy mikor válnak feleslegessé a PVM-programhoz tartozó állományok. Ha a proxy sikeresen letöltötte a párhuzamos program eredményeit magába foglaló JAR fájlt, valamilyen módon jeleznie kell azt a szolgáltató programnak, amelyik erre le kell hogy töröljön minden, az adott programhoz tartozó fájlt. A szolgáltató programtól a proxy felé men job azonosító szintén nem új dolog, és az URL-r l is szó esett már. Az URL helyett a proxy-nak visszaadandó információ – a program futását jelz adat – akkor kap szerepet, ha a kliens még a programjának a befejez dése el tt akarja az eredményeket visszahozatni. Ilyen esetben a szolgáltató program a proxy kérésére nem az URL-t, hanem a „még nem befejez dött futás”-t jelz üzenetet ad vissza. Az eddigiek alapján tehet rendkívül fontos megállapítás, hogy a proxy és a szolgáltató program közötti kommunikációt mindig a proxy kezdeményezi, a szolgáltató program csak a kérésekre válaszol! Mint arról korábban szó esett, a Jini-ben a proxy és a szolgáltatást nyújtó Java program közötti kommunikációs protokollra nincs megkötés. Esetünkben olyan megoldást kell választani, amely biztosítja a kétirányú, de csak a proxy irányából kezdeményezhet kommunikációt, és amellyel a fent említett adatok továbbíthatók. Én a Java RMI protokollt választottam az alábbi okokból:

Segítségével Java objektumok vihet k át egymástól távoli JVM-ek között. Kommunikáció csak az egyik irányból kezdeményezhet . A kommunikáció kétirányú, kérés-válasz típusú.

Az els tulajdonság biztosítja, hogy az URL-ek, a jobok azonosítói, valamint a programok állapotát reprezentáló objektumok továbbíthatók lesznek a szolgáltató program és a proxy-k között. A második tulajdonság miatt kommunikációt csak a kliensekhez


letöltött proxy-példányok kezdeményezhetnek, míg a harmadik dolog biztosítja, hogy mindkét fél megkapja a szolgáltatás során a szükséges információkat a másiktól. Az RMI egyetlen hátránya, hogy az átvitel nem titkosított. A kliens és a szolgáltató között továbbított URL-eket és egyéb adatokat emiatt akár mások is megtudhatják, viszont további el nye, hogy jól beleillik a Jini szemléletbe: ugyanezzel a módszerrel történik az alapinfrastruktúra igénybevétele. Összefoglalva az eddigieket: a Grid szolgáltatást nyújtó klasztereinek mindegyikén futnia kell egy RMI-szolgáltatóprogramnak, amely a világ különböz pontjaira letöltött proxy-któl érkez kéréseket teljesíti. A szolgáltatóprogram RMI interfészét csak a hozzá tartozó proxy ismerik, a kliensek nem. Emiatt biztosított, hogy kérések csak a proxy-któl fognak érkezni. A szolgáltatóprogram sémája a 13. ábrán látható.

RMI szolgáltatóprogram Távoli fájlszerver

JAR fájl letöltés

Válasz a proxynak

RMI interfész

RMI hívás a proxytól

JAR fájl kitömörítés

Helyi Condor vagy PVMdémon

PVM-program futtatása Eredmények betömörítése

Helyi fájl rendszer

Felesleges állományok törlése

13. ábra: A szolgáltatóprogram m ködése

A programnak az ábrán látható akciókat kell végrehajtania, melyekhez helyi er forrásokat használ, és távoli programokkal kommunikál. A programnak a fenti tevékenységek közül az els négyet a submitálás után automatikusan, egymás után kell végrehajtania, míg az utolsót csak a proxy újabb kérésére. A szolgáltató oldalon a PVMprogramokat a klienseknek visszaküldött azonosítók szerint el kell egymástól különíteni, célszer en eleve külön-külön könyvtárba letöltve ket. A JAR fájl kitömörítését a program a Java API-ban található osztályok segítségével végezheti. Az archív fájlban a szolgáltató által meghatározott helyen és néven mindenképpen szerepelnie kell a korábban tárgyalt, a kliens által készített információs fájlnak. Az, hogy ez a fájl létezik-e vagy sem, sajnos csak a JAR fájl letöltése és kicsomagolása után derül ki. A hibásan összeállított fájlok elég sok id t és energiát vehetnek el a „rendes” felhasználók programjai el l, ezért egy továbbfejlesztett verzióban érdemes lenne a kliens oldalon valamilyen erre vonatkozó ellen rzést végezni. Ezt az ellen rzést a proxy – megfelel fájl-hozzáférési jogok esetén – még a submitálás el tt elvégezhetné. A PVM-program elindítását az információs fájlból kinyert parancssor alapján lehet elvégezni. Mivel a futtatás kezdeményez je egy Java program, a futtatáshoz viszont egy JVM-en kívüli programra – Condorra vagy PVM-démonra – van szükség, az egyedüli lehet ség a PVM-programok elindítására a JVM-b l kiadott rendszerhívás. Condor esetén el ször össze kell állítani a klaszter valamelyik gépén futó szolgáltató programnak a Condor submit fájlt, majd rendszerhívással átadni azt a klaszter er forrásmenedzserének. Az általam készített implementációban a Condor submit fájl nem tartalmaz az er forrásokra vonatkozó kikötéseket, mivel a Condor használata a kliensek el l rejtve marad, a szolgáltató pedig nem állapít meg preferencia sorrendet az áttöltött programok


között. A virtuális gépek létrehozását emiatt a Condor a saját politikája szerint végzi. PVM-démonnal való futtatáskor nincs szükség a szolgáltató oldalon submit fájl összeállítására, azt az információs fájl alapján összeállított parancssor segítségével lehet elvégezni. Fontos megjegyezni a PVM-programok számára beállítható környezeti változók fontosságát, ugyanis ezen alapszik a monitorozáshoz adott támogatás. Ha a kliens a megfelel en elkészített PVM-programjának a submitálása el tt elindítja a GRM/PROVE önálló változatát, majd a konzolra kiprintelt DNS-név - portszám párost a job információs fájljába írja, akkor a párhuzamos program képes lesz futás közben visszakapcsolódni, és a kliens oldali monitornak trace-adatokat küldeni. Condor-ral való futtatás esetén a Condor megoldja a PVM-programok standard output és error kimentének a fájlba mentését, míg PVM-démonnal való futtatás esetén ez is a Java szolgáltatóprogram feladata. A futtatás folyamatának sémája az alábbi ábrán látható:

PVM-program

RMI szolgáltató program JVM

Condor vagy PVM-démon

PVM

1. Gép

2. Gép

N. Gép

. . .

14. ábra: PVM-program futtatása a szolgáltatónál A PVM-démon használatának hátránya, hogy ha valamelyik feltöltött program hibásan van megírva, akkor blokkolhat egy másik programhoz tartozó PVM-processzt, vagy akár magát a virtuális gépet is. Ilyen esetben minden PVM-program leáll, új PVM létrehozásáig pedig több program nem is futtatható. A baj az, hogy ezt a szolgáltató program nem veszi észre, továbbra is megpróbálja futtatni a feltöltött PVM-programokat, melyek azonnal „lefutnak”, és csak a kimenetükben látható, hogy valójában el sem kezdhették futásukat. Miután a szolgáltató elvégezte a futtatást, összetömöríti a kliens által az információs fájlban kért eredményfájlokat, valamint a standard output és error kimenetet. A tömörítésr l naplófájlt készít, legvégül ezt csatolja a JAR fájlhoz. A naplófájlnak a haszna, hogy a kliens láthatja, hogy az el zetesen kért eredményfájlok közül melyek léteztek és melyek nem a programjának a lefutása után. A csomagolás befejez dése után a proxy bármikor lekérheti a JAR fájl URL-jét, letöltheti a fájlt, végül meghívhatja a sikeres letöltést jelz függvényt, melynek hatására törölhet k a felesleges fájlok. Ennél a megoldásnál is lehetne jobbat elképzelni, de az igényeknek ez is megfelel. A struktúrával akkor van probléma, ha a kliens eszköz – miután a proxy segítségével letöltötte az


eredményeket – leáll. Ekkor az adott feltöltéshez tartozó állományok mind ott maradnak a szolgáltató számítógépen, és azokat a rendszergazdának a szolgáltatás leállítása után magának kell törölnie. Miután már minden komponensr l és azok m ködésér l is szó esett, lássuk a távoli PVM-program futtatását megvalósító rendszer teljes ábráját:

Kliens oldal



Condor vagy PVM-démon

RMI interfész

RMI

RMI skeleton

Proxy

RMI stub

Proxy interfész

Jini kliens program

Szolgáltató oldal


Fájlszerver

Fájlszerver

15. ábra: A rendszer komponensei

Az eddigiekhez képest csak az RMI kommunikációhoz szükséges stub és skeleton objektumok jelentenek újdonságot. A proxy – ami a két interfész közötti leképzést valósítja meg a korábban leírt módon – és az RMI stub a szolgáltatás megtalálása után tölt dik le a kliensekhez a Jini infrastruktúrájának segítségével. A kliensnek a szolgáltatás megkeresése el tt rendelkeznie kell a proxy interfésszel, továbbá meg kell írnia egy alkalmas kliens programot. Az általam írt kliens a Jini multicast discovery protokolljával képes megkeresni az elérhet lookup szolgáltatókat, letölteni, majd használni az els ként megtalált „PVM-program futtató és monitorozó” szolgáltatás proxy-ját.


5. A P-GRADE és a Jini-Grid integrálása A P-GRADE a SZTAKI által kifejlesztett PVM-program fejleszt környezet [10]. A program grafikus felületet biztosít a klienseknek helyi klaszteren vagy szuperszámítógépen végrehajtandó PVM-programok fejlesztéséhez és futtatásához. Segítségével a programok olyan grafikus modulokból építhet k fel, amelyek elrejtik a felhasználók el l a PVMkommunikációt ténylegesen megvalósító függvényhívásokat, így a programfejleszt k a processzeken belül végrehajtandó szekvenciális kódra koncentrálhatnak. A függvényhívások ilyen magas szint absztrakciója miatt a PVM-, illetve a monitorozáshoz szükséges Instrumentation API-kat a felhasználóknak nem kell ismerniük. A P-GRADE a végleges forráskód elkészítésénél a kommunikációt reprezentáló grafikus elemek elé és után automatikusan beilleszti a megfelel monitor-hívásokat, míg magukat a grafikus elemeket PVM-hívásokkal helyettesíti. Egy felhasználó a párhuzamos programjának a lefordítása után szintén grafikus felületen adhatja meg, hogy annak processzei a helyi klaszter mely gépein fussanak le. A P-GRADE ekkor a kiválasztott gépekb l létrehozza a párhuzamos virtuális gépet, majd ha szükséges mindegyik kiszemelt gépen elindítja a lokális monitort. Ezután indítja el a kliens által készített bináris kódot, amely létrehozza a processzeket, melyek végrehajtják a megfelel számításokat. Ha a felhasználó nem választja ki a futtatáshoz használandó gépeket, akkor a P-GRADE a helyi klaszter minden er forrását beveszi a PVM-be. Míg els esetben a felhasználó töltötte be az „er forrásmenedzser” szerepét, addig a másodikban ilyen egyáltalán nem is létezik. Fontos cél, hogy a P-GRADE kliensei nem csak helyi klasztert, hanem távoli er forrásokat is igénybe vehetnek a PVM-programjaik futtatásához. Ehhez a Jini-Grid kliens programját kell megfelel módon a P-GRADE-el helyettesíteni, amely ezek után grid-programok fejlesztésének teljes életciklusát képes lesz lefedni. Ha a jöv ben a felhasználók P-GRADE-et használva távoli er forrásokat vehetnek igénybe párhuzamos programjaik futtatásához, akkor a fejleszt i környezet kiléphet a klaszterek és szuperszámítógépek használóinak a köréb l, és az Internetre kötött bármelyik PC-n alkalmazható lesz. A P-GRADE C nyelven íródott. A Jini infrastruktúra, és emiatt az egész Jini-Grid igénybevételéhez viszont Java-programra van szükség. Csak Java-program képes megtalálni a Grid lookup szolgáltatóit – vagyis az er forrás brókereket – és csak egy Javaprogram alkalmas a futtató szolgáltatás igénybevételére. Ahhoz tehát, hogy a P-GRADE a Jini-Grid-del együttm ködhessen, egy C és egy Java-nyel alkalmazás integrálására van szükség. A Java-programnak képesnek kell lennie a Grid lookup szolgáltatóinak a megtalálására, a náluk bejegyzett er források adatainak a lekérdezésére, majd a kliens által kiválasztott klaszteren a P-GRADE-ben megírt PVM-program futtatására. Az, hogy ez a program közvetlenül, vagy inkább a P-GRADE-den keresztül tartja a kapcsolatot a felhasználóval, els közelítésben mellékes. Mindkét megközelítési módnak vannak el nyei és hátrányai. Az els esetben – amikor a P-GRADE-den keresztül folyik a kommunikáció – a P-GRADE biztosítja a grafikus felületet a kliens számára, vagyis az jobban illeszkedhet a már megszokott felhasználói környezetbe, viszont bonyolultabb a két program illesztése. Ennek a megközelítésnek a sémája látható a 16. ábrán.


Lookup discovery indítása Az elérhet lookup szolgáltatók listája

A kiválasztott lookup szolgáltatók P-GRADE (C-program)

A náluk bejegyzett er források

Grid kliens (Java-program)

Felhasználó

Jini-Grid

A kiválasztott er forrás PVM alkalmazás + leíró fájl

Futási eredmény

16. ábra: A P-GRADE – Jini-Grid kliens kommunikációja során történ üzenetváltások

A folyamat során a P-GRADE-nek utasításokat kell adnia a Java-program számára, majd várni az akciók eredményét. Ennek a megközelítési módnak további el nye, hogy a P-GRADE leveheti a Java-program válláról a konfigurációs feladatok nagy részét, például indíthatja el a JAR fájl exportálásához szükséges HTTP szervert. A két különböz nyelven írt program összekapcsolása ez esetben történhet a Java Native Interface használatával. Ehhez a P-GRADE megfelel modulját úgy kell megírni, hogy az a kliens kérésére elindítsa a Java-programot, amelyhez ezután a Native Interface-en keresztül kapcsolódhat, és a fenti ábrán látható utasításokat, üzeneteket elküldheti. Az P-GRADE Jini-Griddel való integrálásának másik lehetséges módja, ha a Javaprogram a P-GRADE helyett közvetlenül a klienssel tartja a kapcsolatot. Ebben a szituációban a P-GRADE-nek csupán annyi a feladata, hogy egy script segítségével elindítsa a Java-klienst, melynek indításkor paraméterként átadja a lefordított PVMalkalmazást, és annak leíró fájlját. (A futtatandó alkalmazás felépítését egyedül a P-GRADE ismeri, ezért kell a leíró fájlt most is neki összeállítania.) A Java-programnak ebben az esetben grafikus alkalmazásnak kell lennie, de ez nem biztos hogy hátrány, ugyanis ilyen módon igénybe vehet a Jini egy újabb funkciója, a grafikus proxy. Ezt a tulajdonságot ugyan korábban nem hangsúlyoztam, de most érdemes kiemelni: a Jini-ben a szolgáltatások proxy-jai grafikus objektumok is lehetnek. Ha egy szolgáltatáshoz ilyen proxy tartozik, akkor a klienseknek a használatkor nincs más dolguk, mint egy új ablakot nyitni, és a proxy-t ráhelyezni. A felhasználó ekkor a szolgáltató által biztosított grafikus elemek, és nem metódushívások segítségével használhatja a távoli eszközt. Ez azt jelenti, hogy a kliens programjának még a proxy interfészét sem kell ismernie! Ha a Grid futtató és monitorozó szolgáltatásához grafikus proxy-t fejlesztünk, akkor a P-GRADE felhasználói a proxy, és nem a kliens program által kirajzolt felületen keresztül submitálhatják a programjaikat. Fontos megjegyezni, hogy ett l még a kliens programnak kell biztosítania a lookup szolgáltatók kiválasztásához, majd a kiszemelt klaszter kijelöléséhez szükséges grafikus elemeket. A fenti módszerek alapján a P-GRADE-et alkalmassá lehet tenni a Jini-Grid használatához, mert így szélesebb felhasználói kör ismerhetné meg a Grid-szer PVMprogram futtatás el nyeit.


Ehhez a szolgáltató programnak a következ tulajdonságokkal kell rendelkeznie:

1. A szolgáltatást nem használhatja mindenki nyilvánosan, és ugyanolyan jogokkal. Ehhez szükség van a kliensek és szolgáltatók azonosítására, valamint a köztük zajló kommunikáció titkosítására. Ezt a feladatot a szolgáltató program és a proxy közösen végezheti. Minden azonosítási módszer esetén igaz, hogy a szolgáltató oldalon futó programnak valamilyen adatbázisból kell megszereznie az egyes felhasználókhoz tartozó job-ok jogait. 2. A hibásan megírt kliensekhez tartozó PVM-programok a szolgáltatóknál feleslegesen er forrást nem használhatnak (ha valamilyen oknál fogva egy kliens nem kéri a proxy-t a korábban submitált PVM-program eredményeinek a letöltésére, akkor azok – a PVMalkalmazás bináris fájljaival együtt – mind a szolgáltató oldalán maradnak).Megoldás a szolgáltatás lízingelhet vé tétele. Submitáláskor a kliens nem csak egy job azonosítót, hanem egy lízing objektumot is kapna. Az azonosító ugyanazt a szerepet töltené be mint eddig, a lízing objektummal viszont id nként meg kellene hosszabbítani a klaszter bérlését. Amelyik kliens ezt id ben nem teszi meg, annak a szolgáltató azonnal leállítja a PVM-programját, és töröl minden hozzá tartozó állományt. Ezzel a módszerrel mind a hibás, mind a „feledékeny” kliensek programjai által használt er források a lehet legrövidebb id n belül felszabadíthatók. Van azonban egy fontos ok, ami a lízing bevezetése ellen szól: lízing alapú szolgáltatás igénybevételekor a kliens eszköz nem kapcsolódhat le hosszabb id re a hálózatról, hiszen a lízing meghosszabbítása során a szolgáltatóval való kommunikációra van szükség. Erre megoldást adhat a JSK-ban található Jini szolgáltató program implementáció, a Norm. A Norm képes a kliensek helyett azok lízingjeinek meghosszabbítására. Mivel a Norm használata nem lízinghez kötött, ezért a job futása során nincs szükség a Norm-szolgáltató és a grid-kliens közötti kommunikációra, vagyis a kliens ez esetben szintén lekapcsolódhat a hálózatról.

3. Ha a kliens nem használ monitorozást, akkor a futás során más adatszolgáltatás is kell a szolgáltató fel l a kliens oldalra (ha a kliensek nem tudják pontosan, hogy pl. mikor fejez dik be a programjuk futása, akkor id nként kéréseket kellene intézniük a proxy segítségével a szolgáltató programnak, mely kérések nagy számú kliens esetén leronthatják a klaszterek futtató-teljesítményét). Megoldás lehet a Jini Remote Events modell alkalmazása. A szolgáltatótól a fontosabb eseményekr l értesítés küldhet a kliens oldalnak, ha ott egy megfelel interfésszel rendelkez Java RMI szolgáltató program m ködik. Ezzel a módszerrel a kliens értesíthet arról is, hogy az eredményeket tartalmazó JAR fájl elkészült, vagyis felesleges a szolgáltatót kérésekkel terhelnie.

4. A kliensek kérhetik távoli gépre a futási eredményeket. Minden eszközr l lehetséges távoli gépen található PVM-program submitálása, tehát az eredmény letöltését nem csak a fájlok végleges tárolására kiszemelt gép kezdeményezheti. Megoldás, hogy programot submitáló mobil eszköz (tipikusan notebook, PDA vagy mobiltelefon) nem közvetlenül a futtató er forrás proxy-jánál, hanem az eredmények elhelyezésére kiszemelt gép proxy-jánál kezdeményezi a letöltést. A proxy-n keresztül elküldhet a korábban submitált program, és a futtatást végz klaszter azonosítója, majd „meghivatható” a letöltést indító metódus. A mobil eszköz akár a lookup


szolgáltatóktól, akár privát hálózaton keresztül szerezheti be a fájlok tárolására használandó gép proxy-ját. A lookup szolgáltatón keresztüli letöltés esetét mutatja a következ ábra:

Eredmény letölt gép


Futási eredmény

Klaszter proxy-ja

4

Letölt gép proxy-ja

Klaszter proxy-ja

3 Mobil eszköz

2

5

Futtató klaszter Futási eredmény

Letölt gép proxy-ja

1

17. ábra: Távoli gépre történ eredményletöltés egy lehetséges forgatókönyve

A folyamat menete: 1. A futtatást végz klaszteren létrejön a futási eredmény. 2. A mobil eszköz megszerzi a letöltésre használandó gép proxy-ját. 3. A proxy segítségével továbbítja a futtató klaszter és a submitált job azonosítóit. 4. A kapott adatok alapján letölt dik a klaszterhez tartozó proxy. 5. A proxy segítségével letölt dik a futási eredmény. Ha a Grid ilyen irányú továbbfejlesztése megvalósul, akkor létrejön a mobil-PVM-Grid. Ebben mobil eszközök futtathatnak majd távoli PVM-klaszterek és szuperszámítógépek segítségével párhuzamos programokat. További átalakítások szükségesek, mivel a Veszprémi Egyetem által fejlesztett Jini Grid [6] architektúrája az egyszer programfuttatásnál magasabb szint szolgáltatást is biztosít, ugyanis a kliensek nem közvetlenül a futtatókkal, hanem úgynevezett brókerekkel tartják a kapcsolatot. A brókerek feladata a lookup szolgáltatóknál elhelyezett futtatóproxy-k közül kiválasztani a legalkalmasabbat, majd a segítségével végrehajtatni a kliens Java programját.

A rendszer m ködése a 27. ábrán látható.


Bróker


Futtató proxy

2

Bróker proxy

3

Futtató proxy Bróker proxy

4

1

Bróker proxy 5

Java kód

Futtató proxy

Java kód

JM kliens

Futtató szolgáltató

27. ábra. A JM rendszer használatának folyamata

Legel ször a futtató szolgáltatók elhelyezik a proxy-jukat az elérhet lookup szolgáltatóknál (1). A brókerek ezután letöltik magukhoz a felajánlott er források proxyjait (2), majd k is regisztrálják magukat a lookup szolgáltatók adatbázisában (3). A kliensnek ezek után a lookup szolgáltatók segítségével nem a program-futtatókat, hanem a brókereket kell megtalálnia, és valamelyik pyroxy-ját a saját JVM-jébe letöltenie (4). A bróker képes a kliens bonyolult igényeinek megfelel er forrást találni, majd ahhoz a futtatandó Java kódot submitálni (5). Ha a PVM-program futtató szolgáltatást illeszteni szeretnénk ebbe a sémába, akkor azt a Java-futtatók helyébe (esetleg melléjük lehetne elhelyezni). Mivel a futtatókkal a kapcsolatot a brókerek, és nem a kliensek tartják, ezért a bróker szolgáltatást kell képessé tenni a PVM-futtatók kezelésére. Probléma, hogy a JM-ben a futtatandó kód és a futási eredmény egy-egy olyan Java objektum, amely RMI hívás paramétereként kerül átvitelre. Ezzel szemben a PVM-Gridben sem a futtatandó kód, sem az eredmény nem Java adat, ezért kellett ket JAR fájlokba csomagolva HTTP szervereken keresztül továbbítani. Az új struktúra szerint a submitálást a brókerek végezik, emiatt az integrálás után a kliensekt l nekik nem a futtatandó Java objektumot, hanem a PVM-programot tartalmazó JAR fájl URL-jét kellene megkapniuk. Emiatt meg kell változtatni, vagy ki b víteni a bróker szolgáltatás kliensek fel li interfészét. Ha az interfész kib vül, akkor a létrehozott Gridbe mind Java, mind PVM-programok, ellenkez esetben csak PVM-programok lesznek submitálhatók. Az interfész megváltozatása után pontosan definiálni kell azokat az attribútumokat, melyeket egy PVM-er forrásnak a lookup szolgáltatóknál a proxy-jával együtt minden esetben regisztrálnia kell. Mivel egy PVM-klasztert és egy Java-futtatót teljesen más tulajdonságok jellemeznek – vagyis tesznek a kliensek számára egyedivé – ezért az ket jellemz attribútumokban is jelent s különbség van. A brókereket emiatt a PVMklasztereket jellemz attribútumokkal végzett összehasonlításokra is fel kell készíteni.


6. Párhuzamos PVM programok monitorozása 6.1 A monitorozás célja A folyamat alapvet célja, hogy a futó alkalmazás processzeinek állapotát a felhasználó folyamatosan figyelemmel követheti, és ha a teljesítménnyel kapcsolatban nem megfelel viselkedést tapasztal, akkor leállítja az alkalmazást. A megfigyelt hibás viselkedés ezután a programkódban végrehajtott alkalmas változtatással kijavítható. Mivel a PVM az üzenetküldéses kommunikációs paradigmát használja, ezért egy PVM-processz az alábbi állapotok valamelyikében lehet:

Szekvenciális kódot hajt végre. Üzenetküldés miatt blokkolódott, vagy éppen üzenetet küld. Üzenetet vár, vagy éppen most kap. Szekvenciális programok esetén csak az els állapot létezik, mivel ott nincs direkt kommunikáció a processzek között. Ha hatékony párhuzamos programot akarunk írni, akkor arra kell törekedni, hogy a kommunikáció miatti id veszteség minimális legyen, vagyis minél több ideig legyenek a processzek az els állapotban. Ha valamelyik az id nagy részét csak a kommunikáció miatti várakozással tölti, akkor az t futtató processzor nem is vesz részt valódi számításban. Az ilyen viselkedést kell id ben észrevenni, majd a processzek közötti feladatelosztást újratervezni. Ahhoz, hogy a felhasználó meg tudja állapítani a futó processzek állapotát, a futás közben folyamatos adattovábbításra van szükség a processzek, és egy, az információkat fogadni képes monitor-program között. A futás közbeni adatküldés egyik lehetséges módja a forráskód-instrumentálás. Ilyen esetben az eredeti párhuzamos program kódjába be vannak szúrva az állapotváltozásokat generáló parancsok elé vagy mögé olyan függvényhívások, melyek hatására a processz üzenetet küld a monitornak. A monitor az ilyen üzenetek nyilvántartásával a felhasználó számára biztosítani tudja, hogy a processzek állapota bármely pillanatban lekérdezhet . A PVM-forráskódba a monitorozás miatt beszúrt minden egyes függvényhívás módosít valamennyit a párhuzamos program viselkedésén. Ez azt eredményezi, hogy nem az eredeti, hanem az instrumentált program futását látja a fejleszt . A torzítás miatt a forráskódban a kiegészítéseket úgy kell megvalósítani, hogy az lehet leg minél kevésbé befolyásolja a programot, az egyes processzállapotokban eltöltött id adatok a lehet legkevesebbet változzanak.

6.2 Helyi hálózatban futó PVM-program monitorozása A monitorozáshoz szükséges adattovábbítás könnyen megoldható, ha a monitor és a párhuzamos alkalmazás azonos gépen fut. Ilyen esetben az instrumentált program processzei egy lokális fájlba, vagy osztott memóriába írhatják a megfelel állapotinformációkat, melyet akár még a párhuzamos program futása közben, akár a futás után a monitor program feldolgozhat. Az osztott memória el nye, hogy abba a processzek sokkal gyorsabban írhatnak, ami a torzulásmentes futást biztosítja.


Valamivel nehezebb a helyzet, ha a program ugyan a helyi hálózatban, de nem a monitor programot tartalmazó gépen fut. Ilyen esetben osztott memória közvetlenül nem használható. A SZTAKI kifejlesztett egy monitor programot, és egy hozzá kapcsolható vizualizáló eszközt helyi szuperszámítógépen vagy helyi klaszteren futó PVM-programok monitorozásához [11]. Mindkét program – a GRM-monitor és a PROVE-vizulizációs eszköz – a SZTAKI saját fejlesztés program-fejleszt környezetének, a P-GRADE-nek szerves része. A GRM/PROVE rendszer az alábbi komponensekre támaszkodik:

Kliens függvénykönyvtár: függvények gy jteménye, melyekkel a PVM-program forráskódja instrumentálható. A függvények hatására a program képes a helyi klaszteren vagy szuperszámítógépen futó monitor programnak adatokat szolgáltatni. Lokális monitor: még a párhuzamos program elindítása el tt létre kell hozni minden olyan er forráson, melyen PVM-processz fog futni. A P-GRADE elvégzi ezt a feladatot. A lokális monitorok a f monitor számára biztosítják a PVM-processzek által szállított adatokat. F monitor: a vizualizációs eszköz kéréseire a lokális monitoroktól begy jti, majd id szinkronizációt követ en a PROVE-nak továbbítja a trace-adatokat.

Ha a PVM-fejleszt a P-GRADE környezetet használja a PVM-program megírásához, akkor a kliens függvénykönyvtárat nem kell ismernie: a P-GRADE grafikus editora a megfelel helyekre beszúrja a szükséges függvényhívásokat. Ha viszont a felhasználó saját maga írja a PVM-programot, akkor b vebb leírást találhat az instrumentálást megvalósító Instrumentation API-ról a [9]-ban. A monitorozás közben zajló adatáramlás az alábbi ábrán látható:

1. fizikai PVM- er forrás processz

PROVE

GRM

vizualizáló eszköz

f monitor

Osztott memória

…

Helyi monitor

hálózat

PVMprocessz

...

hálózat

N. fizikai PVM- er forrás processz

P-GRADE-et futtató gép

Osztott memória

…

Helyi monitor

PVMprocessz

Trace fájl

18. ábra: Trace adatok áramlása a SZTAKI GRM/PROVE rendszerével végzett PVM-program monitorozás közben

A lokális monitorok programfuttatás el tti elindítását a GRM végzi a P-GRADE-hez tartozó scrip-ek segítségével. A lokális monitorok közvetlenül elindításuk után létrehoznak egy-egy osztott-memória szegmenst, melyet innent l kezdve az adott gépen futó PVMprocesszek használhatnak. A processzek közvetlenül ebbe a memóriaszegmensbe írják a trace-információkat, melyek két félék lehetnek: vagy teljes eseményleíró rekordok, vagy


eseményszámlálók. Az els esetben minden trace-bejegyzés azonosítja az t létrehozó processzt – vagyis a felhasználó minden adatot megtud a processzekr l – míg az utóbbi megoldás csak statisztikai elemzéshez biztosít hátteret. Ennek a második módszernek is megvan azonban az el nye: kevésbé terheli az er forrásokat. Az osztott-memória használata két el nnyel is jár: egyrészt gyorsan elérhet , vagyis alig torzítja a viselkedést, másrészt ha egy processz valamilyen hiba miatt abortál a trace-bejegyzései a lokális monitor számára azután is hozzáférhet k maradnak. Ez a tulajdonság nagyban megkönnyíti az utólagos hibakeresést. A monitorozás folyamata az alábbi módon zajlik: A P-GRADE-indításakor ugyanazon a gépen automatikusan elindul a PROVE – mint a vizualizációt megvalósító eszköz – és a GRM, mint az adatok összegyüjtéséért felel s f monitor. A klaszter távoli gépein a GRM egyb l elindítja a helyi monitorokat, melyek az indítási paraméterként kapott információk alapján visszacsatlakoznak hozzá. Ha a felhasználó elindít egy PVMprogramot, akkor annak a processzei a klaszter különböz gépein indulnak el – az el re beállított allokálási politikának megfelel en – és futásuk közben az ottani osztott-memória szegmensekbe trace-információkat írnak. A PROVE-on keresztül a felhasználó bizonyos id közönként kérheti a f monitort a trace adatok összegy jtésére. Ekkor a f monitor utasítja a lokális monitorokat, hogy állítsák meg a PVM-processzeket, a lokális monitorok között óraszinkronizációt hajt végre, majd lekéri t lük a helyi bufferek tartalmát. Az abban található eseményleírók id adatait hozzáigazítja egy globális id értékhez, kiírja a helyi trace fájlba, majd utasítást ad a PVM-processzek elindítására. Az id adatok szinkronizálására azért van szükség, hogy a proceszállapotok egymással összehasonlíthatóak legyenek. Mivel a processzek különböz gépeken futnak, melyek id beállítása közötti különbség nagyobb lehet, mint két különböz gépen futó processz által generált esemény között eltelt id szak hossza, ezért mindenképpen szükség van a szinkronizációra. Szinkronizáció nélkül valószín leg hibás eseménysorrendet kapnánk. A trace fájlba már csak a globálisan szinkronizált adatok kerülnek be. A f monitor és a lokális monitorok közötti kommunikáció szuperszámítógépre alapozott PVM esetén a bels hálózaton, míg klaszter alkalmazásakor a lokális hálózaton, socket-eken keresztül történik. Egyik esetben sem olyan jelent s a késleltetés, hogy az az óraszinkronizáció során zavart okozna. Az ok, amiért a processzeket érdemes leállítani az adatbegy jtés el tt, az az, hogy ez a szakasz veszi igénybe leginkább az er forrásokat, vagyis a viselkedésükben ez okozná a legnagyobb torzulást. A leállítás és az osztott memória használata együttesen azt eredményezik, hogy a GRM/PROVE-val végzett monitorozás alig módosítja a PVMprogramok futását.

!

6.3 PVM-programok monitorozása Jini alapú Gridben Jelent sen bonyolódik a helyzet grid-rendszerben futó PVM-program monitorozása esetén. Ilyenkor ugyanis el re nem tudható, hogy a PVM-processzek melyik gépeken fognak futni, vagyis hogy a GRM-nek a lokális monitorokat hol kellene a futtatás el tt elindítania [2]. Míg lokális PVM-program esetén a P-GRADE határozta meg a PVMprocesszek futási helyét, addig a Gridben ez valamilyen, a P-GRADE-t l független er forrásmenedzsernek a dolga. Még ha meg is kaphatnánk ett l a menedzsert l a virtuális gépet alkotó fizikai gépek listáját, a GRM valószín leg akkor sem tudna velük kapcsolatba lépni. Márpedig a korábbi minta szerint mindenképpen szükség van a kapcsolatra, különben a lokális monitorok nem tudnak visszakapcsolódni a f monitorhoz. "

#

$

%

&

'

(

)

*


A SZTAKI megoldása a problémákra a lokális monitorok indítási módjában végzett változtatás. Grid-rendszer esetén azokat nem a GRM, hanem a monitorozandó PVMprocesszek indítják [1]. Amikor egy távoli er forráson – melyet a Grid er forrásmenedzsere választott – az els PVM-processz megpróbál az ottani osztott memóriába írni, észreveszi hogy a szegmens nem létezik (hiszen nincs lokális monitor ami létrehozta volna azt). Ekkor a processz a UNIX fork mechanizmusával létrehozza az adott gép lokális monitorát, amely ezután lefoglalja az azon a gépen futó PVM-processzek számára az osztott memóriát. Innent l kezdve a processzek szemszögéb l minden ugyanúgy zajlik mint eddig, a trace információk ugyanúgy az osztott memóriába írhatók mint korábban. Hogy a PVM-processzek képesek legyenek erre a fork-olásra, a fordításnál hozzá kell linkelni a futtatható állományhoz a lokális monitor kódját. Ezt a feladatot a P-GRADE megoldja, a felhasználónak nem kell vele külön foglalkoznia. Mivel a helyi monitoroknak a korábbihoz hasonló módon kapcsolódniuk kell a GRM-hez, ezért nekik a f monitor gépének IP címére, és monitor portszámára most is szükségük van. A lokális monitorok indítását most a PVM-program végzi, vagyis az információt legkönnyebben t le kaphatják meg. A SZTAKI implementációjában ezt az adatot a PVM-program egy adott nev környezeti változóból veszi, mely tartalmat azután továbbad a forkolódó lokális monitor-processzeknek. A feladat tehát: megoldani, hogy a Gridben elinduló alkalmazás számára egy adott nev környezeti változó helyes értékre legyen beállítva. Mivel a f monitort jellemz IP cím és port szám P-GRADE-et használva a felhasználó el l rejtve marad, az a Gridben való futtatáskor nem adható át a futtatást végz jobmenedzsernek. Ezen ok miatt létre kellett hozni a GRM/PROVE P-GRADE-t l független változatát. Ez a változat képes bármilyen, akár P-GRADE segítségével, akár „kézzel” készített, megfelel en instrumentált és lefordított, távoli er forrásokon futó PVMprogram processzeir l adatokat szolgáltatni, és azokat vizualizálni. Korábban szó esett arról, hogy a P-GRADE hozzálinkeli a lokális monitorok kódját a PVM-programhoz, amely nélkül a Gridben való monitorozás lehetetlen. Ahhoz, hogy ez tényleg így m ködjön, a felhasználónak a P-GRADE-et nem a hagyományos módon kell installálnia. A P-GRADE fordításánál egy megfelel kapcsoló beállításával biztosítható, hogy az a szükséges kódot minden elkészített alkalmazáshoz hozzálinkelje, így adva meg a lehet séget a monitorok kiforkolásához. Az így elkészített program azután a megfelel en beállított környezeti változóval futtatható, és a különálló GRM/PROVE-val monitorozható. Összefoglalva az eddigieket, grid-rendszerben való PVM-program monitorozáskor a következ ket kell tenni:

1. 2. 3. 4. 5.

Az instrumentált PVM forráskódot akár P-GRADE-del akár más eszközzel elkészíteni. A fordítást az el bb említett módon installált P-GRADE-del végrehajtani. Az önálló GRM/PROVE-ot elindítani. A GRM-t l kapott IP cím, port szám párost környezeti változóként a PVM-program számára beállítani. A PVM-alkalmazást elindítani (submitálni a Gridbe).

A program lefordításához tehát ilyenkor is szükség van P-GRADE-re, a monitor funkció viszont kiváltható az önálló GRM/PROVE-val. Nagy kiterjedés hálózatban való futtatáskor az eseményadatok id szinkronizációja szintén nehezebb, mint helyi klaszter vagy szuperszámítógép használatakor volt. Ha WAN hálózatban a szinkronizációt a korábbi módszerrel próbálnánk megoldani, akkor szinte biztos, hogy a kommunikációban fellép késleltetések nagyobb hibát eredményeznének,


mint két generált esemény között eltelt id . Ilyenkor a szinkronizáció hamis eseménysorrendet készítene. A megoldáshoz a korábbi – lokális hálózatokhoz megfelel – szinkronizációs algoritmusnál intelligensebbre van szükség. A GRM/PROVE nem biztosít ilyen megoldást, ehelyett feltételezi, hogy a futtatáshoz használt gépek órái már el z leg szinkronizálva lettek. Ez a szinkronizáció a monitorozástól függetlenül, számos más módszerrel elvégezhet (pl.: NTP - Null Message Protocol).


Glosszárium discovery Egy Jini technológiát használó hálózatban a lookup szolgáltatók megtalálásának folyamata. GRM/PROVE Gridben futó párhuzamos alkalmazások monitorozásához használható monitor és vizualizációs program. J2SDK Java 2 platformot használó programok fejlesztéséhez szükséges osztály-, interfész- és programgy jtemény.

JAR ZIP algoritmus szerint tömörített archív fájl, amely tartalmaz egy úgynevezett manifest információs fájlt is. JM A Veszprémi Egyetem által fejlesztett Jini alapú bróker és futtató szolgáltatás Java programok számára. JSK Jini technológiát használó programok fejlesztéséhez szükséges osztály-, interfész- és programgy jtemény.

JVM Java programok futtatásához használt virtuális gép. Lookup Browser A JSK részét képez program, melynek segítségével egy hálózat dzsinnjei, és a náluk regisztrált szolgáltatások felderíthet k.

multicast Olyan kommunikációs mód, melynek során az üzenetet tartalmazó csomagot a lokális hálózat minden számítógépe megkapja. Norm A JSK-ban található Jini szolgáltató program neve. Képes más eszközök helyett azok lízingjeinek a meghosszabbítására. Object Server A JSK-ban található HTTP szerver program neve. P-GRADE PVM-programok írását, futtatását, és monitorozását el segít környezet.

fejleszt i

PVM Párhuzamos programok futtatásához szükséges virtuális gép. Tartozik hozzá egy C nyelv programokban használható API is.


Reggie A JSK-ban található lookup szolgáltató program neve. RMI Különböz JVM-ekben él tev technológia.

Java objektumok közötti metódushívást lehet vé

RMID Aktiválható RMI szolgáltató programok számára szükséges démon program. unicast Olyan kommunikációs mód, melynek során az üzenetet tartalmazó csomagot csak a címzett számítógép kapja meg.


Hivatkozások jegyzéke 1. Z. Balaton, P. Kacsuk, N. Podhorszki: Application Monitoring in the Grid with GRM and PROVE. Proceedings of the International Conference on Computational Science – ICCS 2001, San Francisco, CA., USA, (2001) 253-262. 2.

Z. Balaton, P. Kacsuk, N. Podhorszki, F. Vajda: From Cluster Monitoring to Grid Monitoring Based on GRM. Conference paper, 7th EuroPar’2001 Parallel Processings, Manchester, UK, (2001) 874-881.

3. G. Cornell, C. S. Horstmann: Core Java. Sunsoft Press, Prentice Hall, (1997) 4. I. Foster, C. Kesselman (szerkeszt k): The Grid: Blueprint for a New Computing Infrastructure. Morgan Kaufman, (1999)

5. A. Geist, A. Beguelin, J. Dongarra, W. Jiang, R. Manchek, V. Sunderam: PVM: Parallel Virtual Machine. A Users' Guide and Tutorial for Networked Parallel Computing. MIT Press, London, (1994) 6. Z. Juhász, Á. Andics, Sz. Póta: Towards a Robust and Fault-Tolerant Multicast Discovery Architecture for Global Computing Grids, Proceedings of the 4th DAPSYS workshop, Linz, (2002) 74-81. 7. P. Kacsuk, F. Vajda: Network-based Distributed Computing (Metacomputing). ERCIM tanulmány, (1999) 8. W. Keith Edwards, T. Rodden: Jini Example by Example. Prentice Hall PTR, (2001) 9. MTA SZTAKI: GRM/PROVE Users’ Guide. http://www.lpds.sztaki.hu 10. MTA SZTAKI: P-GRADE Project. http://www.lpds.sztaki.hu/pgrade 11. N. Podhordszki: Semi-on-line Monitoring of P-Grade Applications. PDPC Journal, (megjelenés 2003-ban) 12. Sun Microsystems: Java 2 SDK, Standard Edition Documentation. http://www.java.sun.com, (2002) 13. Sun Microsystems: Jini Architecture Specification v1.2. http://java.sun.com/products/jini (2001) 14. Sun Microsystems: Jini Device Architecture Specification v1.2. http://java.sun.com/products/jini, (2001) 15. Sun Microsystems: Jini Technology 1.2.1 Documentation. http://www.sun.com/jini, (2001) 16. Sun Microsystems: Jini Technology Core Platform Specification v1.2. http://java.sun.com/products/jini, (2001) 17. Sun Microsystems: The Java Tutorial. www.java.sun.com/docs/books/tutorial, (2002) 18. University of Wisconsin-Madison: Condor Project. http://www.cs.wisc.edu/condor

P-GRADE fejlesztőkörnyezet és Jini alapú GRID integrálása PVM programok végrehajtásához. Rendszerterv. Sipos Gergely

Recommend Documents