Absztrakt A Grid rendszerek egyre nagyobb érdeklődést váltanak ki a tudományos,
ipari és hétköznapi életben. Számos nagyra törő projekt fut, melyek célja
egyre nagyobb, óriási teljesítményű számítási szolgáltatások létrehozása.
Cikkünkben bemutatjuk hogy miért van szükség újszerű,
szolgáltatás-orientált megközelítésre az elkövetkező Grid rendszerekben,
és hogy ezeket miért érdemes a Java és a Jini nyújtotta eszközök segítségével
megépíteni. A cikkben leírjuk e modell melletti érveinket, valamit az ilyen
rendszerrel kapcsolatban felmerülő követelményeket. Emellett megvitatjuk a
rendszer tervezése közben felmerülő kérdéseket abban a reményben, hogy segítségükkel jobb minőségű
Grid rendszereket tervezhessünk.
1. Bevezetés
Az elmúlt néhány év nagyszerűen telt a Grid rendszerek kutatói számára. A média tele van a Grid fontosságát bemutató cikkekkel, valamint újabb és újabb Grid alkalmazásokról és rendszerekről szóló hírekkel. Ipari óriások, mint a Microsoft, az IBM, a Sun és a HP, felsorakoztak a Grid, a számítás törtétének újabb "nagy durranása" mögött. Napilapok mutatják be az új világot, ahol a számítási szolgáltatás bárki számára egyszerűen hozzáférhető, mint a mindennapi életben a csapvíz vagy az elektromos áram.
Mindazonáltal nem ennyire egyszerű ezeknek az igényeknek megfelelni. Megtanulhattuk, hogy a nagy felhajtás nem feltétlenül segíti a kutatást. A mesterséges intelligencia története figyelmeztetés lehet, hogy ha az elvárások túl nagyok, és a bíztató eredmények nem követik az elvárásokat, akkor az kiábránduláshoz, a támogatások megcsappanásához és a szakmai elismerés elveszítéséhez vezethet.
A Grid fejlesztés kezdeti évei (a 90-es évek közepe-vége) főként a különféle Grid fejlesztési próbálkozások versenyéről szóltak. Számos komolyabb rendszer született - melyeket akkor még nem hívtak Gridnek - főként az USA-beli kutatóintézetekben. A legfontosabb ilyen rendszerek a Legion [1], a Globus [2], a Javelin [3] és a NetSolve [4]. Az évszázad végére ezek közül a Globus vált de facto szabvánnyá - nem szükségszerűen a szakmai értékei alapján. A kiemelkedés oka elsősorban annak köszönhető, hogy ez a rendszer már létező eszközök és komponensek felhasználásával készült, ezért ennél építeni lehetett a már meglévő felhasználói tudásra, valamint fel lehetett használni a meglévő nagy teljesítményű rendszereket.
Az elmúlt öt évben az IT szektorban más irányú fejlődés is végbement. Az elektronikus kereskedelem mindennapossá vált, a világ számos országában működnek e-boltok és e-bankok. Hatalmas mennyiségű B2B üzleti tranzakció folyik nap mint nap. A mobil technológia és vezeték nélküli hálózatok fejlődésével egyre több számítógép-szintű mobiltelefonon és PDA-n válnak elérhetővé az Internet által nyújtott szolgáltatások.
Ezen fejlesztések következtében az Internet-világot úgy írhatjuk le, ahol az egyik oldalon hagyományos felhasználók százmilliói állnak, Web-szerverektől függve, korlátozott böngésző-alapú erőforrás-hozzáféréssel, míg a másik oldalon viszonylag kis számú kutató áll, akik korlátlan mennyiségű erőforrást szeretnének felhasználni számításaikhoz. A két felhasználói csoport és a felhasznált technológiák közötti rés szűkítése érdekében tervezték az Open Grid Services Architecture (OGSA) rendszert [5], amelyet a Globus követőjének szánnak. Erre a paradigmaváltásra szükség volt, de a cikk szerzői szerint tovább is lehetett volna lépni.
Cikkünkben összehasonlítjuk a jelenlegi Grid fejlesztési irányokat az általunk javasolt jövőbeli irányokkal, és rámutatunk, hogy a lehető legnagyobb felhasználói réteg elérése érdekében radikálisabb megközelítésre van szükség, azaz a felhasználói érdekeket kell figyelembe venni, és tanulni kell a többi nagyméretű elosztott rendszer fejlesztési tapasztalatából. Véleményünk szerint nagyméretű Grid rendszerek fejlesztésére megfelelőbb egy Java és Jini alapokon nyugvó Grid infrastruktúra.
A cikk következő fejezetében áttekintjük a Grid rendszerekkel szembeni jelenlegi követelményeket, és megmutatjuk, hogy miért nem alkalmazhatóak teljes mértékben széles körben használható Grid rendszerekkel szemben. Bemutatjuk a "Grid" szó mi értelmezésünk szerinti jelentését, és megmutatjuk hogy milyen eszközöket nyújt a Jini a felhasználói interakciók és a rendszer működtetésének megkönnyítésére. A 3. fejezetben bemutatjuk a Grid általunk javasolt szolgáltatás-orientált megközelítését valamit vázoljuk az ilyen rendszerekkel szembeni követelményeket és a tervezésekor felmerülő kérdéseket. A 4. fejezetben körvonalazzuk a sikeres Grid rendszerekhez vezető fő tervezési megközelítéseket, és megvitatjuk hogy a Jini valamint a különféle szoftvertechnológiai eszközök hogyan segíti ezen rendszerek gyakorlati tervezését és implementálását.
2. A Griddel szembeni követelmények
A Globus rendszer fejlesztése során a tudományos életben szereplő felhasználók szemszögéből vizsgálták a követelményeket. A rendszer célja távoli számítási, adattároló és megjelenítő eszközök valamint speciális műszerek egy nagy virtuális szuperszámítógéppé való összekapcsolása volt. Ennek segítségével számításigényes feladatok oldhatók meg, valamint nagy mennyiségű tudományos adat tárolása és feldolgozása válik lehetővé. Kezdetben a résztvevő szervezetek elsősorban szuperszámítógép-központok voltak, később nagy teljesítményű Unix munkaállomásokból álló klaszterek is csatlakoztak hozzájuk. Mindezek eredményeként a Globus rendszer a következő fő komponensekből épül fel [2][6]:
ˇ Erőforrás-kezelés (GRAM): Ez a modul teszi lehetővé az erőforrások lefoglalását és a folyamatok menedzselését
ˇ Kommunikáció (Nexus/MPI): Kommunikációs alrendszer, kezdetben a Nexus használatával, később az MPI szabványra építve
ˇ Biztonság (GSI): Hitelesítést és ehhez kapcsolódó biztonsági szolgáltatásokat nyújtó modul
ˇ Információ (MDS): Globális erőforrás-információs modul, mely elosztott hozzáférést nyújt a rendszer állapotával és felépítésével kapcsolatos információkhoz
ˇ Egészség és állapot (HBM): A rendszerkomponensek állapotát felügyelő modul
ˇ Távoli adatelérés (GASS): Távoli fájlelérést és elosztott fájlrendszerek kezelését lehetővé tevő modul
ˇ Végrehajtható programok kezelése (GEM): Végrehajtható kódok létrehozásához, gyorsítótárazásához és elhelyezéséhez támogatást nyújtó modul
A teljes rendszer körülbelül 12 MB forráskódból és 23 MB konfigurációs szkriptből áll. A Globus egyik legnagyobb problémája , hogy C nyelvre épül, ami (i) nem támogatja az elosztott rendszerek fejlesztését, és (ii) a könyvtárak segítségével csak korlátozott lehetőségeket nyújt a már megírt kódok újrafelhasználására. Ebből következik, hogy a Globus fejlesztőinek sok rendszerszintű problémára minden lehetséges platformra külön el kell készíteniük a problémát megoldó eljárást (távoli processz létrehozás, szálkezelés, fájl hozzáférés, kommunikáció, biztonság, stb.) A platformok nagy száma és az propléma mérete komoly szoftvertechnológiai kérdéseket vet fel. A figyelembe veendő platformok számának növekedésével (gondoljunk a mobil eszközökre!) a verziókövetés és a karbantartás jelentős problémává válhat.
A Grid rendszerek szabványosításának elősegítésére létrejött független nemzetközi fórum, a Global Grid Forum (GGF) célja, hogy a világ minden tájáról összekösse a Grid rendszerekkel foglalkozó kutatókat. A GGF munkacsoportokból áll, és a Grid minden egyes részterületével - biztonság, ütemezés, stb. - külön munkacsoport foglalkozik.
A Grid protokoll architektúra munkacsoport a Grid rendszerek feladatainak definiálásával foglalkozik. Egy aktuális ajánlásban a következőképpen definiálták a Grid rendszerek alapvető moduljait [7]:
ˇ perzisztens állapot, nyilvántartás és erőforrás-felfedezés
ˇ erőforrás-felhasználás ütemezése
ˇ egységes számítási felület
- futtató / kiszolgáló környezet Unix-típusú folyamat-együttműködéshez
- futtató / kiszolgáló környezet OGSI-típusú folyamat-együttműködéshez
- alkalmazás futtató környezetek kialakítására alkalmas eszközök
ˇ egységes adathozzáférés
ˇ aszinkron információforrások (események és monitorozás)
ˇ hitelesítés, delegálás és biztonságos kommunikáció
ˇ jogosultságok ellenőrzése
ˇ azonosító tanúsítványok kezelése
ˇ rendszerkezelés és -hozzáférés
Ezen a listán is látható, hogy a Grid rendszerek elsődleges célja az erőforrások elérése és kezelése, azaz C/Fortran/stb. programok távoli gépeken való futtatása a távoli számítógépek egyenlő kihasználtságának biztosítása mellett. A fő részek az erőforrás-felfedezés, az ütemezés, az egységes számítási- és adathozzáférés és a biztonság.
Szerintünk elsősorban a rendszer adminisztrátora az, aki az erőforrások elérése és kihasználtsága miatt aggódik. A tudományos és egyéb végfelhasználók csak egy feladatot akarnak elvégezni a lehető legegyszerűbben és leggyorsabban. Ezt összekapcsolva azzal, hogy az Internet- (és potenciális Grid-) felhasználók nem akarnak nagyteljesítményű számításokat elvégezni, arra a következtetésre juthatunk, hogy egy újabb, magasabb szintű Grid modellre van szükség. Ez a szolgáltatás-orientáltság, ami a Jini technológia alapgondolata is, és az OGSA kezdeményezésben is feltűnik.
A szolgáltatás-orientáció a hangsúlyt az eszközökről (erőforrásokról) a szolgáltatásokra (alkalmazások) helyezi át, és arra koncentrál, hogy a rendszer egy eleme mit nyújt a rendszer többi komponense számára. A végfelhasználók pedig a funkcionalitásra figyelhetnek (nyomtatás, vásárolt áru kifizetése), nem pedig a megvalósítás részleteire (melyik nyomtató elérhető és hogyan lehet kinyomtatni vele a levelet). Ha a Grid szolgáltatások, és nem erőforrások gyűjteménye (de a szolgáltatások természetesen erőforrásokat is takarhatnak) akkor rögtön felhasználók millióihoz kerül közelebb, és a Web-böngészőkkel való szövegalapú elérés helyett közvetlenebb kapcsolatba léphetnek a szolgáltatásokkal. Ekkor a Grid nem csak a számításról és adattárolásról szól, hanem egy olyan szoftver-infrastruktúráról, amely szolgáltatásokhoz való általános hozzáférést biztosít bárhol, bármikor, bárkinek. Ez azonban új követelményeket vet fel, amelyeket a következő fejezetben fogunk megvizsgálni.
3. A szolgáltatás-griddel szembeni követelmények
A követelmények megállapításához tételezzük fel, hogy a jövőbeli Grid rendszerek szolgáltatások dinamikus gyűjteményei lesznek. A Grid nem "csak" egy számítási felület, hanem szolgáltatásokat nyújtó rendszer. Egy ilyen rendszerben bármi szolgáltatás lehet: lakossági számlákat kezelő bankok, igény szerinti videóműsor-szolgáltatók, szuperszámítógépek, találkozóhelyek, vagy a kedvenc sarki boltunk.
Képzeljük el a következő Grid-felhasználási szituációt (a hagyományos távoli shell/szkript központúsággal szemben):
Aliz reggel
munkába menet kedvenc Bach cselló szvitjét szeretné meghallgatni. A CD-t otthon
felejtette, ezért a PDA-ja segítségével az autóból utasítja a Grid brókerét, hogy
keressen egy olyan zenei szolgáltatást, amely lejátssza neki az 1. szvitet.
Másodpercek alatt felcsendül a zene, és Aliz el is feledkezik a reggeli
csúcsforgalomról. A munkahelyén Aliz egy meteorológiai kutatási projektet
vezet, ahol távoli érzékelőket használnak fel, és az adatok feldolgozása
érdekében számításokra van szükségük. A számítógépéről utasítja a Grid
brókert hogy gyűjtse össze az adatokat, és az általa megadott
beállításoknak megfelelően a világ különböző tájain fellelhető
számítási szolgáltatások felhasználásával feldolgozva küldje át a megjelenítő
terembe. Délután egy megbeszélést tart, ahol a Gridről a bróker
segítségével letöltött adatokat megjeleníti a legközelebbi aktív táblán. Az
egész napos munka után úgy dönt, hogy elmegy vacsorázni a férjével és
barátaikkal. A Grid bróker Aliz beállításainak megfelelően gyorsan talál
egy új francia éttermet, majd Aliz ismét a PDA-ja segítségével foglal egy
asztalt négy személyre.
Felmerül a kérdés, hogy ebben az esetben Grid-ről beszélhetünk-e, vagy sem. Úgy gondoljuk, hogy a szolgáltatás-alapú rendszereket is Grid-nek tekinthetjük, hiszen az adatforrás ŕ feldolgozás ŕ megjelenítés számítási Grid-beli folyamat hasonló a multimédia adatbázis ŕ feldolgozás ŕ videókijelző folyamathoz. Emellett bármely szolgáltatás-alapú rendszer képes adatokat feldolgozni, tárolni és megjeleníteni, képes különféle alkalmazásfüggő hardvereszközöket használni, valamint erőforrásokat megosztani és összehangolni a feladatok végrehajtása érdekében.
Tervezéskor a felhasználó-központúságra helyezve a hangsúlyt, először nézzük a használhatósággal kapcsolatos követelményeket. A példaként említett szituáció alapján a következő követelményeket láthatjuk:
ˇ általános hozzáférés: a felhasználóknak képesnek kell lenniük arra, hogy a szolgáltatásokat bármilyen típusú eszközről elérjék, akár szuperszámítógépről, akár mobiltelefonról van szó. Emellett képesnek kell lenniük előzőleg ismeretlen szolgáltatások felfedezésére.
ˇ adminisztrációmentesség: a felhasználóknak ne kelljen különféle szoftvereket telepíteniük ahhoz, hogy a szolgáltatásokat használni tudják. Az összes Grid-beli szolgáltatásnak képesnek kell lennie a felhasználói interfész igény szerinti szolgáltatására, az eszköz paramétereinek (képernyőméret, multimédiás képességek) és a felhasználó igényeinek (személyes kívánságok, esetleges korlátok) figyelembe vételével. Az interfész a szolgáltatástól tölthető le.
ˇ segédszolgáltatások: a felhasználóknak szükségük lehet speciális segéd- (bróker-) szolgáltatásokra, amelyek kérésükre elvégzik helyettük az alapvető feladatokat (pl. zenei szolgáltatás keresése, kapcsolat felépítése érzékelők és a számítógép között, stb.)
ˇ biztonság: a felhasználó adatai, programjai és a végrehajtások adatainak védettnek kell lenniük a lopástól, illetéktelen módosítástól és hozzáféréstől, valamint védekezni kell a tisztességtelen szolgáltatásokkal szemben is
ˇ teljesítmény: a felhasználók állandó rendelkezésre állást kívánnak a szolgáltatásoktól (feltéve ha létezik megfelelő vagy helyettesítő szolgáltatás), időponttól és helytől függetlenül
A szolgáltatást nyújtók szemszögéből ezek a követelmények a következőket jelentik:
ˇ általános hozzáférés: a szolgáltatásoknak használhatóknak kell lenniük használt eszköztől és felhasználói korlátoktól függetlenül. A szolgáltatás működése nem változhat egyes eszközök és interfészek használata miatt.
ˇ adminisztrációmentesség: a szolgáltatások módosíthassák a megvalósítás módját anélkül, hogy ez megzavarná a felhasználókat. Emellett a szolgáltatások tetszés szerint csatlakozhatnak a Gridre és leválhatnak a róla anélkül, hogy a Grid rendszer többi részének működését ezzel megzavarnák
ˇ segédszolgáltatások: a szolgáltatásoknak képesnek kell lenniük együttműködni más szolgáltatásokkal és segédszolgáltatásokkal, és a feladatokat "csapatmunkában" megoldani. A szolgáltatóknak különféle fizetési módokat kell felajánlaniuk a felhasználók részére, és képesnek kell lenniük harmadik fél által nyújtott fizetési szolgáltatásokkal együttműködni.
ˇ biztonság: a szolgáltatásoknak (adatok, programok és a végrehajtási információk) védettnek kell lenniük a lopástól, illetéktelen módosítástól és hozzáféréstől, illetve védekezni kell a tisztességtelen felhasználókkal szemben is
ˇ teljesítmény: a szolgáltatásoknak maximális mértékben a felhasználók rendelkezésére kell állniuk, időtől és helytől függetlenül.
Mik az előzőekben bemutatott modell legfőbb különbségei az erőforrás-központú megközelítéssel szemben? Eddig a rendszer által megadott erőforrások közül a felhasználónak kellett kiválasztania a neki megfelelőt, ezzel szemben itt a szolgáltatásokat másik programok fogják felfedezni és felhasználni. A szolgáltatások igény szerint használhatóak, dinamikusan letöltött felhasználói interfészeken keresztül. A szolgáltatások természetesen nem ingyenesek, ezért online fizetési módszerekre van szükség. A hardver és a szolgáltatások implementációja is változni fog idővel, ezekre a változásokra fel kell készülnie a rendszernek, akárcsak a felmerülő hibák megfelelő kezelésére.
Úgy gondoljuk, hogy a Grid rendszerek funkcionalitását és specifikációját a használhatósággal szemben támasztott követelményeknek megfelelően kell megtervezni. Véleményünk szerint a Java programozási nyelv megfelelő alapot nyújt Grid rendszerek tervezéséhez és megvalósításához, egyrészt platformfüggetlensége miatt, másrészt mivel lehetővé teszi a mobil kód használatát. A további szükséges, elosztottságot támogató eszközöket a Jini technológia nyújtja számunkra.
4. A Jini Service Grid
Mint láttuk, szolgáltatás-orientált környezetben a felhasználók és a szolgáltatások elvárják a folyamatosan üzemelő és hibatűrő működést, a fejlett biztonsági eszközöket, a hatékony globális szolgáltatás-felfedezést, a minél kisebb adminisztrációt és a szoftverek telepítésének szükségtelenségét, az eszközhöz és a felhasználókhoz alkalmazkodó interfészeket valamint a testreszabhatóságot. Mindezek biztosítása elsősorban a Grid infrastruktúra (middleware) feladata.
A cikk szerzői kifejlesztettek egy Jini alapú számítási Grid prototípust ezen elgondolások tesztelésére [9]. A minimális rendszer felépítése az 1. ábrán látható. A rendszer számítási (Compute), lookup és bróker szolgáltatásokból áll. A lookup szolgáltatás minden Jini közösség kulcsfontosságú eleme, amely a szolgáltatások proxy objektumait tárolja és a kliensek rendelkezésére bocsátja. A bróker szolgáltatások a felhasználói kéréseket a számítási szolgáltatásokhoz továbbítják, miközben az erőforrás-kiválasztást és a feladat futtatásával kapcsolatos teendőket elvégzi a kliens helyett. Ebben a rendszerben a szolgáltatás-felfedezés a lookup szolgáltatás segítségével történik. Nagyobb rendszereknél, ahol túl sok szolgáltatás van jelen, egy lookup szolgáltatással való regisztrálás rontja a rendszer teljesítményét. Ebben az esetben a brókereket hierarchiába lehet szervezni, ezzel lehetővé téve a szolgáltatások hatékony keresését [10]. Ebben az alap rendszerben a kliensek Java programokat hoznak létre és futtatnak a számítási szolgáltatásokon a brókerek segítségével.
1. ábra: Az alap Jini Grid rendszer
Ez a minimális, kutatási célokra készült prototípus csak számítási szolgáltatásokat tartalmaz, és számos, Grid rendszerekben nélkülözhetetlen funkciót mellőz. Ennek ellenére sikeresen megmutatta, hogy a hatékony szolgáltatás-felfedezés, hibakezelés, valamint a karbantartás és a használat egyszerűsége mind az alkalmazhatóság mellett szól. Az alábbi alrendszereket (funkciókat) kell még a jövőben rendszerünkhöz adni:
ˇ rugalmas, dinamikus és konfigurálható biztonsági rendszer, amely kezeli a felhasználók hitelesítését és jogosultságaik ellenőrzését, biztosítja a programok integritását, valamint a bizalmasság (trust) kezelését és továbbítását.
ˇ számlázó alrendszer, amely naplózza a szükséges rendszer- és felhasználói aktivitásokat, a szolgáltatások és erőforrások felhasználását, valamint eltárolja ezeket az adatokat a későbbi számlázás és elemzés érdekében
ˇ biztonságos fizetési rendszer, amely többféle fizetési módra ad lehetőséget (ingyenes, használat alapján, előre fizetett, kedvezményes, csomag, stb.)
ˇ felhasználó-kezelő rendszer, a személyre szabhatóság támogatására,
ˇ együttműködési alrendszer, amelynek lehetőséget nyújt egyéb Java és nem Java alapú programokkal és Grid rendszerekkel való együttműködésre
ˇ lehetőség intelligens ágens alapú szolgáltatások használatára, amelyek képesek saját viselkedésük optimalizálására, és képesek különféle működési sablonokat megtanulni a teljesítmény és a profit növelése érdekében.
Ezek a követelmények a rendszer minden szolgáltatásának a működését meghatározzák. Az általunk követett objektum-orientált tervezési megközelítésből adódóan ezeket a funkciókat egy Grid szolgáltatás ősosztályban kell megvalósítani. Ennek köszönhetően az egyes szolgáltatások fejlesztői az adott szolgáltatás felépítésére és funkcióira koncentrálhatnak.
4.1. Általános szolgáltatás architektúra
Az általunk tervezett rendszerben működő szolgáltatás moduljait a 2. ábrán láthatjuk. Az ábrán az érthetőség kedvéért elhagytuk az egyes modulok közötti összefüggéseket és kapcsolatokat. Természetesen ezen modulok többségét akkor használjuk, amikor egy kliens ebből az ősosztályból leszármaztatott szolgáltatásnak valamilyen funkcióját igénybe veszi.
A fő kérdések a rendszer és a nyelvi szintű szoftvertechnológiai megoldásokkal kapcsolatban merülnek fel. Milyen programozási nyelvet használjunk az általános architektúra megvalósítására? Tartalmazza a nyelv az összes szükséges szolgáltatást? Életciklusa során minden nagy rendszer szükségszerűen változásokon megy át. Hogyan tudunk tervezéskor felkészülni a változásokra? Melyek a hibatűrést, az öngyógyítást és a dinamikus viselkedést támogató szoftvermodellek? Léteznek sikeres minták és/vagy rendszerek, melyeket tervezésünk kiindulópontjaként felhasználhatunk?
2. ábra. Az általános Grid szolgáltatás moduljai
4.1.1 Programozási nyelv kiválasztása
A prototípus elkészítéséhez használt Java programozási nyelv jó választásnak bizonyult. Először is, a Java a szoftveripar által széles körben elfogadott, kiforrott objektum-orientált nyelv. Erősségei Web szerver rendszerekben mutatkoznak meg, ami egyúttal igazolja a Grid szolgáltatásokra való alkalmazhatóságát is. Másodszor, az 1.4-es verzió megjelenésével minden olyan eszköz rendelkezésünkre áll, amelyre nagyméretű párhuzamos és elosztott rendszerek építése esetén szükség van. Támogatja a szálakat, a hálózatkezelést (unicast, multicast, HTTP, biztonságos adatátvitel), a naplózást, flexibilis és hatékony biztonsági architektúrával rendelkezik, erősen típusos és lehetővé teszi interfészek használatát, léteznek különféle eszközfüggő implementációi (J2ME/SE/EE), támogatja az együttműködést más rendszerekkel (Java Native Interface, XML, Web Service és SOAP támogatás, adatbázis-elérés), és nagy számú alkalmazásfüggő csomag áll rendelkezésre multimédia, grafikus felhasználói felületek, hang, beszéd és kisegítő lehetőségek változatos alkalmazásához. Mindezekkel együtt a Java nyelv szilárd alapot nyújthat az implementációhoz.
4.1.2 Változásra tervezés
A legnagyobb kihívás a tervezés során a rendszer változásokra való felkészítése. Bármely függetlenül elkészített komponensekből álló elosztott rendszer esetén a rendszer elemeinek funkcionalitása és megvalósítása idővel szükségszerűen változik. Ezzel egyidőben az elemek meghibásodása, illetve újabb elemek beillesztése révén a rendszer viselkedése dinamikusan változik. A következőkben felsorolt módszerek megoldást nyújtanak ezekre a problémákra.
A legfontosabb szabály a specifikáció és az implementáció különválasztása, más néven a felelősségi körök szétválasztása (separation of concerns). A rendszer elemeit külön kell választani az implementációtól, hogy az egyes komponensek változtatása esetén ne legyen szükség az egész rendszer újrafordítására. A legismertebb nyelvek közül a Javaban található meg legtisztábban az interfész fogalma, amely leírja hogy miért felelős egy komponens, anélkül hogy a hogyan-nal foglalkozna. Ha a rendszerben interfészek segítségével specifikáljuk a komponenseket/szolgáltatásokat, akkor lehetőség nyílik az implementáció futás közbeni megváltoztatására is.
A kialakuló rendszerek hardver-és szoftverfüggetlensége ugyancsak fontos. A Java nyelv egy egyszerű "hardvare image"-en keresztüli hozzáféréssel elszigeteli a hardvert a felhasználótól. Habár a rendszerünkben a kliensek és a szolgáltatások közötti kapcsolatok felépítéséhez a Java nyelvre támaszkodunk, a Jini proxy programozási paradigmája garanciát nyújt a kommunikációtól és a szolgáltatás megvalósításától való függetlenségre (azaz bármely nyelv használható az implementációhoz).
A Jini távoli eseménykezelése segítségével lehetővé válik a dinamikus állapotkezelés és az eseményekről való értesítés. Ezt a bérletkezelési (lease) mechanizmussal együtt használva megoldható a hibás erőforrások automatikus eltávolítása. Erről az állapotváltozásról a rendszer abban érdekelt elemei értesítést kapnak, aminek köszönhetően megnő a rendszer hibatűrése.
Végül, a szolgáltatások felfedezésekor azok típusa (interfésze) és egyéb megadott attribútumok (pl. hely) számítanak, ami a legjobb módszer a szolgáltatások leírásának és jelentés-integritásának biztosítására. Az interfészek szabványosíthatóak, és lehetőség szerint nem változnak. Ha mégis elkerülhetetlen a változtatás, az újabb verziójú interfészt a régiből való származtatással készíthetjük el. Ebben az esetben a régebbi kliensek a régebbi interfészt használhatják, de ezzel egyidőben az új kliensek felhasználhatják az újabb interfész nyújtotta előnyöket.
4.1.3 Szoftvertechnológia
A Grid rendszerek fejlesztése nagy kihívást jelent. A globális méretű Grid rendszerek jó eséllyel a valaha készített legnagyobb és legösszetettebb szoftverrendszerekké válhatnak. Ezekhez tehát alapos szoftvertechnológiai eljárásokra és megbízható építőelemekre van szükség.
A Java nyelv már bizonyította megbízhatóságát és robosztusságát mind programozási nyelvként, mind számítási környezetként. Erre az alapra építve a Jini elegáns megoldásokat nyújt dinamikus elosztott rendszerek fejlesztéséhez. A szoftverfejlesztők a tervezési sablonok (design patterns) használatával elkerülhetik a "kerék újrafeltalálását", valamint már kipróbált és alaposan letesztelt szoftverarchitektúrákra építhetnek. Néhány ilyen, a Grid rendszerek esetén hasznos tervezési sablon:
ˇ Proxy pattern: implementációtól és protokolltól függő proxy-k használatával a klienseket és a szolgáltatásokat implementációtól és protokolltól függetlenül kapcsolhatjuk össze
ˇ Adapter pattern: használatával automatikus "tolmácsot" használhatunk az egymás interfészeit nem ismerő kliensek és szolgáltatások között. Ez a szolgáltatások igény szerint nyújtott felhasználói interfészén keresztül érhető el
ˇ Composite pattern: segítségével a komponenseket és a komponensek halmazait egységesen kezelhetjük
ˇ Factory pattern: használatával a konkrét osztály ismerete nélkül hozhatunk létre objektumokat, és a leszármazottakra bízhatjuk a konkrét objektumok létrehozását
ˇ Facade pattern: interfészek összetételével hozhatunk létre új szolgáltatásokat
ˇ Mediator pattern: a Grid komponensei közötti kapcsolatokba bevonhatunk harmadik feleket is, pl. a kliens és a szolgáltatás között használhatunk brókereket
ˇ Observer pattern: segítségével figyelhetünk a szolgáltatásoknál bekövetkező, számunkra érdekes állapotváltozásokra
A tervezési sablonok használata nem csak könnyebbé teszi a Grid megtervezését, hanem elérhetőbbé és érthetőbbé teszi a tervet a külső programozók számára is, akik így könnyebben fejleszthetnek szolgáltatásokat a Grid rendszerbe, illetve vehetnek részt azok karbantartásában.
A sablonok mellett az elosztott rendszerek világában számos nagyméretű rendszert vehetünk példának, amikből tanulhatunk. Az üzleti életben használt világméretű fizetési és tranzakciós architektúrák, az ATM pénzkiadó automaták globális hálózata, a vezetékes és vezeték nélküli telekommunikációs hálózatok - mind olyan rendszerek, melyeket érdemes alaposan megvizsgálni és esetleg részleteiben újrafelhasználni a Grid rendszerek építésében. Ha sikeres Gridet akarunk, akkor nem csak a számítási teljesítményre kell összpontosítani. A robosztusság, megbízhatóság, magas rendelkezésre állás, biztonság és karbantarthatóság mind ugyanolyan fontos célok.
Végül az utolsó megvizsgálandó terület a biztonsági kérdésekkel, illetve a dinamikus konfigurálhatósággal foglalkozik. Hely szűke miatt ezek egy másik cikk témái lesznek, röviden azonban elmondható, hogy a Jini mostanában megjelent legújabb verziója olyan bővíthető eszköztárral rendelkezik, mely a legszigorúbb biztonsági és konfigurációs igényeknek is megfelelő rendszerek építésére ad lehetőséget.
5. Következtetések
Cikkünkben
nagyméretű Grid rendszerek tervezési kérdéseivel foglalkoztunk. Röviden
áttekintettük a Grid számítás történetét és bemutattuk a Grid rendszerekkel
szembeni általánosan elfogadott követelményeket. Érveket soroltunk fel, melyek
alapján a szolgáltatás-orientált megközelítést alkalmasabbnak találhatjuk nagy Grid
rendszerek esetére, és definiáltuk az ilyen rendszerek főbb
követelményeit. Felvetettük, hogy ilyen rendszerek építésére a Java/Jini alap a
legmegfelelőbb, az általa nyújtott szoftvertechnológiai és nyelvi
támogatásoknak köszönhetően. Az "ingyen kapott" platformfüggetlenség
mellett ez a legalkalmasabb környezet sablonok alapján történő
tervezéshez. Ugyan cikkük csak felszínesen érintette a tervezési
problémaköröket, reményeink szerint ez jó kezdet egy jól használható, globális
szolgáltatás-orientált Grid rendszer építéséhez.
6. Hivatkozások
[1] Grimshaw, W. Wulf et al. The Legion Vision of a Worldwide Virtual Computer. Communications of the ACM, vol. (40)1, January 1997.
[2] Foster and C. Kesselman, The Globus project: a status report, Future Generation Computer Systems 15 (1999) pp 607-621.
[3] M.O. Neary, B.O.Christiansen, P. Capello and K.E.Schauser, Javelin: Parallel Computing on the Internet, Future Generation Computer Systems 15 (1999) pp 659-674.
[4] Henri Casanova and Jack Dongarra, "NetSolve: A Network Server for Solving Computational Science Problems", The International Journal of Supercomputer Applications and High Performance Computing, Volume 11, Number 3, pp 212-223, Fall 1997.
[5] I. Foster, C. Kesselman, J. Nick, S. Tuecke, "The Physiology of the Grid: An Open Grid Services Architecture for Distributed Systems Integration", Open Grid Service Infrastructure WG, Global Grid Forum, June 22, 2002., http://www.gridforum.org.
[6] The Globus Toolkit: Basics. http://www.globus.org/training/toolkit-internals/
[7] W. Johnston and J. Brooke, "Core Grid Functions: A Minimal Architecture for Grids", Working Draft, Version 3.1, Global Grid Forum, Grid Protocol Architecture Working Group, http://www-itg.lbl.gov/GPA/
[8] Sun Microsystems, "The Jini Specification", http://www.sun.com/jini
[9] Zoltan Juhasz, Arpad Andics, and Szabolcs Pota, "JM: A Jini Framework for Global Computing", in Proc 2nd International Workshop on Global and Peer-to-Peer Computing on Large Scale Distributed Systems at IEEE International Symposium on Cluster Computing and the Grid (CCGrid'2002) May 21 - 24, 2002 Berlin, Germany. pp. 395-400.
[10] Zoltan Juhasz, Arpad Andics, and Szabolcs Pota, "Towards A Robust And Fault-Tolerant Multicast Discovery Architecture For Global Computing Grids", in P. Kacsuk, D. Kranzlmüller, Zs. Nemeth, J. Volkert (Eds.): Distributed and Parallel Systems - Cluster and Grid Computing Proc. 4th Austrian-Hungarian Workshop on Distributed and Parallel Systems, Kluwer Academic Publishers, The Kluwer International Series in Engineering and Computer Science, Vol. 706, Linz, Austria, September 29-October 2, 2002, pp. 74-81.