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

Átírás

1 P-GRADE fejlesztőkörnyezet és Jini alapú GRID integrálása PVM programok végrehajtásához Rendszerterv Sipos Gergely Lovas Róbert MTA SZTAKI, 2003

2 Tartalomjegyzék 1. Bevezetés Jini alapú Grid rendszer A Grid célja és felépítése A Jini-szemlélet Egy dzsinn m ködése A Sun Jini-implementációja A Jini, mint a Grid alap-infrastruktúrája Párhuzamos PVM programok végrehajtása A végrehajtás párhuzamosítása Programok futtatása a helyi PVM-démon felhasználásával PVM programok futtatása Condorral A Condor, mint er forrásmenedzser A PVM és a Condor szerepe a Gridben PVM alkalmazások végrehajtása Jini alapon A Jini használata A rendszer követelményei Jini alapon Egy PVM-program futtatásának forgatókönyve A szolgáltatás használata A szolgáltató program megtervezése A P-GRADE és a Jini-Grid integrálása Párhuzamos PVM programok monitorozása A monitorozás célja Helyi hálózatban futó PVM-program monitorozása PVM-programok monitorozása Jini alapú Gridben...38 Glosszárium...41 Hivatkozások jegyzéke...43

3 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 P- GRADE/PVM alkalmazások megfigyelésének témakörével.

4 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 Er forrás Kliens gép Er forrás Gridinfrastruktúra... Kliens gép Kliens gép Er forrás 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

5 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

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

7 Felhasználó Szolgáltató 1 Szolgáltató 2 Szolgáltató 3 Felhasználó A hálózat fizikai megvalósítása LOOKUP SZOLGÁLTATÓ 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ó 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 2. ábra: Egy dzsinn felépíté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

8 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 Memória Szolgáltató eszköz Memória Igényl program 1 5 Szolgáltatás proxy 2 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

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

10 Unicast TCP és multicast UDP csomagok Java program JVM Java program Java program JVM Fizikai eszköz JVM 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

11 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 Proxy 3 1 Szolgáltató Proxy Attribútumok Attribútumok Azonosító A szolgáltatást jellemz objektum 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

12 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

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

14 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 MPP PC klaszter 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.

15 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

16 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

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

18 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. 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. 2. 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.

19 Grid-infrastruktúra Grid szolgáltató program Condor Grid szolgáltató program Condor Gép 1 Gép 2... Gép M... Gép 1 Gép 2... Gép N Lokális hálózat 1 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.

20 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á:

21 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. 2. 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.