Párhuzamos programok monitorozása klaszteren és griden



Podhorszki Norbert


MTA SZTAKI Párhuzamos és Elosztott Rendszerek Laboratórium

1518 Budapest, Pf. 63.

pnorbert@sztaki.hu


Bevezetés

A GRM monitorozó és a PROVE teljesítmény vizualizációs eszközök párhuzamos alkalmazások megfigyelését teszik lehetõvé egy klaszteren. Jelenleg ezek az eszközök a P GRADE grafikus párhuzamos fejlesztõrendszer [1] integrált elemei. Ezeket az eszközöket az EU DataGrid Framework V projekt [2] keretében grid alkalmazások megfigyelésére is alkalmas, önálló eszközökké tesszük.

Ebben a cikkben röviden bemutatjuk ezeket az eszközöket a P-GRADE rendszer keretében klaszteren futó párhuzamos alkalmazások megfigyelésére, majd megvizsgáljuk a grides használathoz szükséges új követelményeket. A továbbfejlesztés két eltérõ útját mutatjuk be. Az egyik esetben a GRM monitort önálló grides eszközzé alakítjuk, a másikban a DataGrid projekt relációs monitorozó és információs rendszeréhez kapcsoljuk.

Az elsõ irány legnagyobb kihívása a monitorozó rendszer, a GRM elindítása és az alkalmazáshoz való kapcsolódása. A második megoldásban a GRM-et a relációs modellt támogató, Java alapú R-GMA komponenseivel kell összekötni és ennek megfelelõen átalakítani mind az alkalmazásról szerzett információkat továbbító instrumentálási könyvtárat, mind a monitor információkat összegyûjtõ komponenst.

Párhuzamos programok monitorozása klaszteren

A P-GRADE egy grafikus párhuzamos programozási környezet, amely az üzenetváltásos paradigmán alapul. A programozó grafikusan tervezheti meg az alkalmazás topológiáját és a kommunikációs eseményeket. A felhasználónak nem kell ismernie egy adott kommunikációs programkönyvtár függvénykészletét és szintaktikáját, a kommunikáció teljes egészében grafikus elemekkel definiálható. A fejlesztõ eszköz hatékonysága és skálázhatósága érdekében a párhuzamos programban lévõ szekvenciális kódrészletek a hagyományos C nyelven írhatók meg. A legtöbb szokásos párhuzamos alkalmazás így létrehozható a P-GRADE-en belül.

A P-GRADE PVM vagy MPI alkalmazást készít a grafikusan megtervezett programból. A környezet nem csak a tervezést, hanem a fordítást, futtatást, hibakeresést és teljesítményelemzést is támogatja egy egységes keretrendszeren belül. A kész program bármilyen rendszeren futhat, ahol PVM vagy MPI alkalmazás képes futni: szuperszámítógépeken és klasztereken. A teljes programozási életciklus (a tervezéstõl a párhuzamos program teljesítményének elemzéséig) támogatása egy fejlesztõrendszeren belül egyedülállóvá teszi a P-GRADE-t. Az 1. Ábra bal felsõ és jobb alsó ablakaiban a P-GRADE-ben fejlesztett Flsim program látható. Az alkalmazás topológiája jól megfigyelhetõ a bal felsõ ablakban, míg a központi processz szerkezetét mutatja a bal alsó ablak. A folyamatábra jellegû gráf minden doboza C forrásnyelvi kódot rejt, így az alkalmazás jóval nagyobb, mint amekkorának elsõ pillantásra tûnik.

A teljesítmény elemzéséhez a PROVE vizualizációs eszköz nyújt támogatást, amely a P GRADE integrált eleme. A végrehajtott program mûködésérõl részletes képet kaphatunk a PROVE fõ ablakában megjelenõ diagramról (time-space diagram) ld. 1. Ábra bal alsó ablaka. Az alkalmazás minden processzének idõbeli állapotát egy sorban színes blokkok jelzik. A fekete szín a számításvégzést, a világosabbak a kommunikációt jelzik. A processzek közötti nyilak a konkrét üzenetküldést reprezentálják. Ha kiválasztunk egy ilyen blokkot vagy kommunikációt, a P-GRADE kijelöli az alkalmazás grafikus kódjában az eseményhez tartozó kódrészletet, így nagyon könnyû azonosítani az eseményeket.

A PROVE természetesen számos egyéb, statisztikai diagramokkal is segíti a felhasználót, hogy megtalálja az alkalmazás teljesítményét lerontó programozási és konfigurációs hibákat. Ilyen statisztikák például a processzek közötti kommunikációról, vagy az egyes programkódrészletekben töltött idõrõl adott összesítõ adatok. Így gyorsan megtalálhatók azok a részek a programban, amelyek a legtöbb erõforrást vagy idõt igénylik és amelyek optimalizálása vezethet az alkalmazás teljesítményének javításához.


5. Ábra A P-GRADE és PROVE az Flsim program futtatása közben.

A PROVE csak egy megfelelõ monitorozó rendszer segítségével mûködhet, amely az alkalmazás futtatása közben összegyûjti és a vizualizációs eszköznek szállítja az adatokat. Ez az eszköz a P-GRADE rendszerben a GRM monitor [3]. A GRM egy semi-on-line monitor, amely azt jelenti, hogy bármikor a futtatás során, kérésre, képes összegyûjteni az alkalmazás eseményadatait és azokat a kérõ eszköz számára elérhetõvé tenni. Azonban nem teszi ezt folyamatosan és kérés nélkül és a kérõ eszköz a kérés után csak néhány másodperccel kapja meg az adatokat. Ezért nem nevezzük a GRM-et on-line monitornak. Ezt a funkciót a következõ megoldások teszik lehetõvé:


A GRM egy fõ monitor processzbõl és annyi lokális monitor processzbõl áll, ahány számítógépet használunk az alkalmazás futtatására (ld. 2. Ábra). A fõ monitor feladata az, hogy koordinálja a lokális monitorok munkáját, kommunikáljon a P-GRADE futtató rendszerével és a PROVE-val. Továbbá ez végzi el az óraszinkronizációt is az eseményadatokon, hiszen azok egymástól független órával (és ennek megfelelõen, eltérõ járással) rendelkezõ számítógépekrõl erednek, míg egy elemzõ eszköznek a valódi (valamilyen globális) idõpont szükséges minden egyes eseményhez. A koordinációba tartozik az lokális monitorok indítása és leállítása, az adatgyûjtések sorrendjének vezérlése és az összefûzött, egységes esemény adatfájl írása.

A lokális monitorok egy-egy számítógépen futnak és az ott futó alkalmazás processzek monitorozását végzik. Egy lokális monitor létrehoz egy esemény puffert közös memória szegmensként és amikor egy processz valamilyen eseményrõl egy eseményadatot generál, akkor ezt az adatot a közös pufferbe írja. Így az adat a monitor számára bármikor hozzáférhetõ. Ha a processz a saját memóriaterületére helyezné az adatot, akkor nem lehetne azt kívûlrõl (a monitor által) kiolvasni és az on-line monitorozás nem lenne lehetséges. A közös memória használat azt is lehetõvé teszi, hogy ha az alkalmazás abortál, akkor az utolsó generált eseményt is össze lehet gyûjteni és a PROVE-ban megjeleníteni, ami nagyban segíti a hiba behatárolását. A másik módszer esetén a privát memóriaterületen tartott eseményadatok elvesznének.


5. Ábra A GRM hierarchikus felépítése

Mint a fentiekbõl is kiderül, az alkalmazás processzek maguk generálják az eseményadatokat és nem egy külsõ program vagy hardver készít adatokat az alkalmazásról. Ez a fajta monitorozás a software tracing-be tartozik. Az alkalmazás kódját instrumentálni kell, azaz speciális függvényhívásokat kell beszúrni a kódba, amelyek az eseményadatokat generálják (kódrészlet kezdete illetve vége, üzenetküldés, -fogadás stb.) Ezt az instrumentálást a P-GRADE rendszerben a fordító automatikusan elvégzi, a felhasználónak nem kell törõdnie vele.

Az adatok összegyûjtése a következõ algoritmus szerint történik. Amikor egy kérés érkezik a PROVE-tól (de ilyen kérést tehet a P-GRADE futtató rendszere a futtatás végén, sõt a debugger is, ha egyszerre óhajtjuk a P-GRADE hibakeresési eszközét és a vizualizációs eszközt használni) a fõ monitor utasítja a lokális monitorokat, hogy állítsák meg az alkalmazás processzeket. Ezután a fõ monitor végrehajt egy óraszinkronizációs lépést a lokális monitorokkal való ping-pong üzenetváltások segítségével. Ezután a fõ monitor minden egyes lokális monitort utasít az ottani közös puffer átküldésére. Az abban található eseményadatok (helyi) idõpontjait módosítja a globális idõértékre és kiírja az eseményfájlba. Ha minden lokális monitortól összegyûjtötte az adatokat, a fõ monitor utasítást ad az alkalmazás továbbfuttatására.

Az alkalmazás leállításának az a célja, hogy a rendszert legerõsebben befolyásoló adatgyûjtési fázist kizárjuk az alkalmazás futtatásából. Így a monitorozás kevésbé intruzív, hiszen általában nem végez semmit, csak várakozik; amikor pedig az adatokat a hálózaton továbbítja, az az idõszakasz kívûl esik az alkalmazás futtatásának idején.

A PROVE feladata, hogy kapcsolódjon a GRM-hez és kérje az adatokat, amikor szüksége van rá. Így a GRM egy várakozó eszköz, amely önmagától nem végez munkát, csak kiszolgálja a felette lévõ eszközök kéréseit.

A GRM elindítása a P-GRADE rendszerben könnyû feladat. A felhasználó konfigurál egy számítógép hálózatot, tipikusan egy klasztert, amelyen a P-GRADE alkalmazásokat futtatni akarja. A rendszer a futtatás elõtt elõször a GRM-et indítja el a konfigurációban szereplõ gépeken és ezzel biztosítja, hogy amikor egy alkalmazás processz elindul valamelyik számítógépen, akkor egy lokális monitor már biztosan fut ott és a közös puffer készen áll az eseményadatok fogadására.

Monitorozás griden

A grid alapgondolata a koordinált erõforrás elosztás és problémamegoldás dinamikus, több intézményt összefogó virtuális szervezetben. Az eddig ismeretes elosztott architektúrákhoz képest a hangsúly a nagyméretû erõforrás elosztás felé tolódik el. Egy grid akár nemzetközileg elosztott, egymástól teljesen független szervezeti egységek hatáskörébe tartozó rendszereket köt össze azért, hogy az erõforrásokat megosszák a alkalmazások között.

A jelenleg folyó fejlesztések arra koncentrálnak, hogy összeállítsák azokat a használható szolgáltatásokat, amelyekkel egy grid mûködtethetõ. A monitor és információs rendszerek esetében hamar kiderült, hogy egyetlen létezõ rendszer sem használható minden további nélkül a griden, mert számos akadályba ütköznek. A skálázhatóság a leggyakoribb olyan alapkövetelmény, amelyet a monitorozó rendszerek nem tudnak teljesíteni. A hibatûrés, a biztonsági kérdések, a rendszer illetve alkalmazás monitorozás képessége további olyan kihívások, amelyekkel foglalkozni kell.

A mi célunk az, hogy a GRM-et és a PROVE-ot a P-GRADE rendszertõl független alkalmazás monitor és vizualizációs eszközzé tegyük, amelyet a grides környezetben is lehet használni. Kétféle megközelítésben is megpróbáljuk a szükséges módosításokat elvégezni. Egyrészt minden más eszköztõl független, grid rendszereken használható eszközt szeretnénk létrehozni [4][5], másrészt az európai DataGrid projektben létrehozandó grides rendszer információs rendszerét felhasználó eszközt is létrehozunk. Az alábbi alfejezetekben ezekrõl a fejlesztésekrõl írunk.

Önálló grides alkalmazás monitor

A legnagyobb nehézség, amellyel szembetaláljuk magunkat, amikor a griden szeretnénk monitorozni egy alkalmazást az, hogy nem tudható elõre, hogy az alkalmazás processzei mely számítógépen fognak elindulni. A monitorozó eszközt tehát nem lehet a futtatás elõtt elindítani a célgépeken és arra várni, hogy az alkalmazásprocesszek majd bejelentkezzenek.

Ráadásul, ha a felhasználó a késõbbiekben tudomást szerez a végrehajtó számítógépek hollétérõl, akkor sem teszik a mai grid feladatelosztó rendszerek lehetõvé, hogy ugyanazokon a gépeken rövid idõn belül elindítsunk egy másik alkalmazást, amely történetesen a monitorozó eszköz lokális processzei lennének. Így tehát csak a következõ két lehetõségünk marad. Vagy lemondunk a lokális processzek használatáról vagy beépítjük azokat az alkalmazásprocesszekbe és azok indulásakor a processz azonnal megduplázódik (fork) és az egyikük lokális monitorként mûködik tovább. Az elsõ megoldás is mûködõképes, ekkor az instrumentált alkalmazásprocessznek saját magának kell a távoli gépen elhelyezkedõ monitornak elküldeni az eseményadatokat. Ez természetesen nagyon befolyásolja a végrehajtást, hiszen az interneten keresztül kommunikál az egyébként esetleg csak lokális hálózaton kommunikáló processz. Ez érdektelenné teheti a mérések kiértékelését, mert azok a befolyásolt futásról adnak képet és nem a nem-megfigyelt futásról, amely teljesen különbözõ lehet.

A második megoldás megvalósítható a GRM-ben és így annak kedvezõ tulajdonságai megõrizhetõk. A lokális monitor kódját átalakítottuk egy könyvtárrá és azt linkelni kell az alkalmazás processz kódjához. Az elsõ instrumentálási függvényhívás elvégzi a forkolást és a gyerek processz lokális monitorként kezd mûködni. Ezek után minden az eredeti módon történik: az alkalmazás processz üzenetben elküldi a lokális monitornak az adatait, amely visszaküldi az általa létrehozott közös memória címét és az alkamazás processz máris generálhatja az eseményeket és elhelyezheti a közös memóriaszegmensben.

Fennmarad még egy probléma: hogyan találják meg a lokális monitorok a kapcsolatot a fõ monitorral? Az eredeti GRM-ben a fõ monitor indítja el a lokális monitorokat és azoknak paraméterként átadja saját elérési címét, így azok képesek csatlakozni hozzá. Nyilvánvalóan ennek a kapcsolódási információnak az átadása a grides környezetben másként kell, hogy történjen. A következõ megoldással az információ eljuttatható a lokális monitoroknak. Ha tudjuk a fõ monitor kapcsolódási címét, amikor az alkalmazást a gridben elindítjuk (azaz a felhasználó elõször elindítja a monitort és aztán adja át az alkalmazást a grid elosztórendszernek), akkor ez a cím környezeti váltózóként definiálható az alkalmazás számára. Amikor az alkalmazás processzei elindulnak egy számítógépen, akkor az indító rendszer gondoskodik arról, hogy a definiált környezeti változók a processz számára is definiálva legyenek. A processz által elindított lokális monitor pedig automatikusan örökli ezeket a környezeti változókat és így a fõ monitor címe is ismert lesz számára. Ezután a lokális monitor ugyanazzal a protokollal kapcsolódhat a fõ monitorhoz és azonosíthatja magát, mint az eredeti GRM-ben. Az egyetlen kényelmetlenség ebben a megoldásban az, hogy a felhasználóra rá kell bízni a kapcsolódási információ átadását az alkalmazás indításakor. Legalábbis mindaddig, míg az egész alkalmazás indítási eljárást kézzel kell végezni és nem egy általánosan végrehajtó programba ültetjük az egészet (mint ahogy az eredeti GRM indítását a P-GRADE környezet végzi).

Az elsõ kísérletek sikerrel jártak. A Globus grid rendszer [6] segítségével a saját klaszterünkre kívûlrõl indított alkalmazás valóban elindította a számítógépeken a lokális monitorokat, amelyek visszakapcsolódtak a fõ monitorhoz és az alkalmazásról adatokat lehetett gyûjteni futtatás közben.

Az instrumentálási könyvtárat is általánosítottuk, hogy ne csak a P-GRADE fordító használhassa saját speciális grafikus blokk orientált instrumentáláshoz, hanem tetszõleges programkódokba a programozók beilleszthessenek eseménygeneráló utasításokat. A P GRADE-tõl elválasztott GRM és PROVE így alkalmassá vált nem csak P-GRADE, hanem általános alkalmazások grides futtatásának monitorozására és vizualizációjára. A 3. Ábra egy MPI példaprogram, a systest egy részletét mutatja, amikor az alkalmazás egyes processzei körbeküldenek egymásnak egy üzenetet (ring test).


5. Ábra Az MPI-os systest példaprogram ring test-je a PROVE-ban
(P0-P3 a processzek és n0-n3 a számítógépek nevei)

Az európai DataGrid projekt monitorozási rendszere

A svájci székhelyû CERN által vezetett DataGrid projekt célja az, hogy lehetõvé tegye Európában is a következõ generációs tudományos kutatást, amely rendkívûl számításigényes és nagyméretû tudományos adatbázisok elemzését igényli terabájtnyi, sõt petabájtnyi mennyiségû információ feldolgozásához és mindezt nem egyes kutatók, hanem széleskörû nemzetközi kutatóközösségek együttmûködésével. A fizika, biológia és földtudományok ilyen diszciplinák. A közösségek közötti információ megosztás nagyon bonyolult a felhasználható erõforrások és maguk a közösségek elosztott természete, valamint az adatmennyiséghez képest elégtelen sávszélességû hálózat miatt. A DataGrid projekt egy kutatói hálózatot hoz létre Európa fizikai kutatóközpontjai között, amely a grid technológiákat használja ahhoz, hogy az eddigieknél sokkal hatalmasabb adatfeldolgozási és számítási lehetõségeket biztosítson.

A projekt hátterében áll a CERN LHC (Large Hadron Collider) új gyorsítójának építése, amely nagyságrendekkel nagyobb teljesítményû szerkezet, mint bármely más részecskegyorsító. A hatalmas kísérleti berendezés olyan mennyíségû adatot produkál majd minden egyes másodpercben, amelyet semmilyen jelenlegi számítógépes és hálózati megoldás nem tud feldolgozni. Ezért kulcsfontosságú, hogy a grid technológia segítségével egy egész Európára kiterjedõ számítógéphálózatot (nagy számítóközpontok hálózatát) hozzunk létre, amely képes fogadni és tárolni az információáradatot és lehetõvé teszi a fizikai kutatóknak mindenhol Európában, hogy a tárolt adatokon számításokat végezzen.

A DataGrid projekt egyik munkacsoportja (WP3) a monitor és információ szolgáltatásokkal foglalkozik. Ennek keretén belül egy relációs adatmodellt támogató és arra támaszkodó információs rendszert fejleszt ki, amely egy általános keretrendszer többféle grid információ eljuttatására a felhasználókhoz illetve adminisztrátorokhoz és programokhoz. Ebben a munkában az MTA SZTAKI is részt vesz és legfõképpen a felhasználói alkalmazások monitorozására és vizualizációjára koncentrál. A munka alapja itt is a GRM és PROVE és a cél ugyancsak az, hogy az alkalmazásokat a griden a GRM segítségével monitorozhassuk és a PROVE segítségével figyelhessük meg. Mindezt a WP3 csoport által létrehozott egységes keretek között.

Az információs rendszer neve R-GMA, ahol az 'R' a relációs adatmodellre utal, míg a 'GMA' a Grid Monitoring Architecture mozaikszava. A GMA a Global Grid Forum [7] által megtervezett, nagyon általános szintû, monitorozási architektúra, amelynek három központi eleme van: az információt elõállító és szolgáltató Termelõ, az információkat keresõ, lekérdezõ és feldolgozó Fogyasztó és a keresést és kapcsolatteremtést elõsegítõ Címtár.


5. Ábra A Grid Monitorozási Architektúra


Címtár (Directory Service) Lehetõvé teszi az információ közzétételét és megtalálását, továbbá nyilvántartja a termelõket és a fogyasztókat és az elérhetõ adatok típusait (metainformációit). Így ehhez a szolgáltatáshoz fordulva a résztvevõk fel tudják sorolni illetve meg tudják keresni a létezõ adatforrásokat és azok karakterisztikáit. A címtár nem tárolja magukat az adatokat, hanem csak a megkeresésükhöz szükséges információkat.

Termelõ (Producer) Az adatokat a termelõ teszi közzé, regisztrálja magát a címtárnál, fogadja a lekérdezési és feliratkozási kéréseket és ezeket kiszolgálja.

Fogyasztó(Consumer) Az adatokat a fogyasztó dolgozza fel, regisztrálja magát a címtárban, passzívan vagy aktívan létrehozza az adatfolyamot a termelõ és a fogyasztó között.

Az R-GMA ennek az általános architectúrának egy Java implementációja (ld. 5. Ábra), amely a relációs adatmodellt veszi alapul az információk tárolására és továbbítására. A fogyasztók az adatokat SQL nyelven megfogalmazott lekérdezésekkel kérhetik a termelõktõl. A relációs modell nem feltétlenül jelenti relációs adatbázisok használatát az R-GMA-ban. A legegyszerûbb termelõk egy memóriabufferben tárolhatják adataikat és az SQL lekérdezést interpretálva válaszolhatnak a fogyasztóknak. A relációs modell az adatok megszerzésének protokollját definiálja elsõsorban. Természetesen nagyobb mennyiségû adat esetén érdemes relációs adatbázist használni és az SQL használata miatt az R-GMA-ba az beilleszthetõ.

A Java implementációban Java servletek biztosítják a termelõ (Producer) és a fogyasztó (Consumer) általános funkcionalitását. A tényleges termelõ és fogyasztó alkalmazások a grid rendszerben egy-egy jól definiált interfészen keresztül tudnak kommunikálni egymással. Az interfész elrejti a servleteket a programozók szeme elõl, míg jelenlétük biztosítja, hogy a programokra (és az azokat végrehajtó számítógépekre) csak kicsiny terhet ró az interfészek használata.


5. Ábra Az R-GMA szerkezete Java servletekkel implementálva

A GRM és PROVE eszközök összeköttetése az R-GMA-val azért nagyon fontos a DataGrid keretein belül, mert így lesz egységes monitorozási rendszer, amelyet az alkalmazások készítõi használhatnak majd. Ebben a kontextusban a lokális monitorok szerepét átveszik az R-GMA termelõ szolgáltatásai. Az instrumentált processznek azonban "beszélnie" kell a közös nyelvet, azaz a GRM instrumentációs könyvtárat át kell alakítani a termelõ interfész használatára. A GRM fõ monitor egysége megmarad és mint fogyasztó mûködik (az alkalmazás szempontjából). Ez azért jó megoldás, mert így a PROVE-ot nem kell megváltoztatni az R-GMA használatához, hanem csak a GRM-et. A PROVE ugyanúgy a GRM-tõl veszi majd az adatokat, mint az eredeti klaszteres felállásban.

Összefoglalás

A GRM monitorozó és a PROVE teljesítmény vizualizációs eszközök párhuzamos alkalmazások megfigyelését teszik lehetõvé egy klaszteren a P GRADE grafikus párhuzamos fejlesztõrendszer integrált elemeiként. A jelenlegi erõfeszítéseink arra irányulnak, hogy továbbfejlesszük ezeket az eszközöket, hogy griden futtatott alkalmazásokat lehessen velük monitorozni és megfigyelni. Az önálló eszközzé alakítás folyamatában már sikeres lépéseket tettünk, míg az R-GMA információs rendszerhez való illesztés a közeljövõ feladata.

Köszönetnyilvánítás

A cikkben leírt tevékenységeket az OTKA T032226 számú, "Grafikus felügyelõ rendszer földrajzilag elosztott, heterogén /metacomputing/ számítási környezetben" címû projekt, az IKTA 00111/2000 "DemoGrid: Heterogén rendszerek összekapcsolása adat- és számításigényes feladatok megoldására" címû projekt és az EU Framework V keretprogramon belüli "DataGrid" címû IST-2000-25182 projekt keretében végeztük és végezzük.

Hivatkozások

  1. P-GRADE rendszer honlapja: http://www.lpds.sztaki.hu/projects/p_grade

  2. EU-DataGrid projekt honlap: http://www.datagrid.cnr.it

  3. Podhorszki N., Kacsuk P.: "Design and Implementation of a Distributed Monitor for Semi-on-line Monitoring of VisualMP Applications", Proceedings. DAPSYS'2000 Distributed and Parallel Systems, From Instruction Parallelism to Cluster Computing, Balatonfüred, Hungary, pp. 23-32, 2000.

  4. Balaton Z., Kacsuk P., Podhorszki N., Vajda F.: "From Cluster Monitoring to Grid Monitoring Based on GRM", Proceedings. 7th EuroPar'2001 Parallel Processing, Manchester, UK. pp. 874-881., 2001

  5. Balaton Z., Kacsuk P., Podhorszki N..: "Application Monitoring in the Grid with GRM and PROVE", Proc. of the International Conference on Computational Science - ICCS 2001, San Francisco, CA., USA. pp. 253-262, 2001.

  6. Globus software toolkit: http://www.globus.org

  7. Global Grid Forum: http://www.gridforum.org