Erőforrás-felhasználás nyilvántartó és elszámoló rendszer Condor Grid ütemező környezetben

Somogyi Csongor, Dr. László Zoltán, Szeberényi Imre

BME Irányítástechnika és Informatika Tanszék

{csongor, laszlo, szebi}@iit.bme.hu

Az IKTA-4 MGRID projekt célja, hogy létrehozza a magyar, professzionális szuperszámítógép Grid prototípusát. A Gridnek a felhasználók számára üzleti célokra is alkalmas teljes körű szolgáltatásokat szükséges nyújtania, beleértve a felhasználóbarát kezelői felületet és a pontos, ellenőrizhető, a ténylegesen felhasznált erőforrások költségeinek kalkulálását és számlázását. A professzionális szolgáltatások egyik legfőbb eleme az erőforrás-felhasználás (EFH) nyilvántartása és elszámolása. A cikk szerzői tervezték meg és implementálták a fontosabb funkcionális egységek prototípusát. Jelen cikk célja az említett területen végzett kutató-fejlesztő munka eddigi eredményeinek összefoglalása, a tapasztalatok értékelése és a további munka fő irányainak bemutatása.

A Stiller, Gerke, Reichl és Flury [1,2] által megalkotott EFH nyilvántartó és elszámoló modell képezi az általunk tervezett rendszer alapját. A hivatkozott cikkek jelzés szinten rámutatnak arra, hogy a modell alkalmazható Grid rendszerekre is [3]. Jelen cikk szerzői ezt a modellt kiegészítve, módosítva készítették el a rendszertervet, így az adatfolyam-modelleket, az adatszerkezetek entitás-relációs modelljét és a dinamikus viselkedés leírását. A tervezési fázis lezárult, és a projekt a megvalósítási szakaszba lépett. Elkészült a Condor Grid ütemezővel együttműködni képes adatgyűjtő modul, és az EFH nyilvántartó egységgel együtt a rendszer telepítve lett a BME Irányítástechnika és Informatika Tanszékének Condor klaszterére, ahol az adatgyűjtés próbaüzeme zajlik.

1          Bevezető

1.1         A Grid szolgáltatások fejlődése

Az elmúlt évtizedekben az Internet gyökeresen átalakította az életünket. Lehetővé tette, hogy hatalmas mennyiségű információt osszunk egymással, és olcsó kom­mu­ni­kációs, ill. dokumentumcserélő felületet biztosít számunkra. A globális hálózat segít­ségével nem csak információ, multimédia, hanem más típusú erőforrások, így pl. számítási kapacitás, is könnyen elérhetővé vált. Megszületett annak igénye, hogy a bonyolult algoritmusú, hosszú futási idejű problémákat több, kisebb - de elsősorban a számosság nagyságát hangsúlyozva - számítási erőforrással elosztott, párhuzamosított környezetben oldhassunk meg.

Először két fajta elképzelés kezdett el fejlődni. Az első volt a lokális hálózatokon vagy multiprocesszoros rendszereken működő számítógép farmok vagy klaszterek kialakulása. Ezek a rendszerek elsősorban lehetőséget teremtettek arra, hogy a rendszer csomópontjain (számítógépein vagy processzorain - végrehajtási egységein) futó feladatok egy közös virtuális gépként működjenek, vagyis a párhuzamos szálak programozói könyvtárhívások segítségével képesek legyenek üzeneteket továbbítani egymásnak. Mivel lokális rendszerekről volt szó, a többfelhasználósság és a biztonsági kérdések nem jelentek meg elsődleges szempontként.

A másik elképzelés az olyan kihívás jellegű problémák kezelését részesítette előnyben, mint a kódtörés (distributed.net), az idegen intelligencia keresése (Seti@home) vagy rákkutatás (United Devices™). Ezek a megoldások lehetővé tették önkéntes felhasználók számára, hogy egy kliensoldali alkalmazást letöltve a processzor szabadidejét "bérbe adhassák" egy az adott problémára megoldást kereső közösségnek, és persze így ők is ennek a közösségnek a részévé válhattak. Az ilyen ügyfél-kiszolgáló rendszerek sokfelhasználóssá váltak, de maradt az egyszerű kétrétegű architektúra, általában csak a fent példaként említett specifikus problémák megoldására voltak képesek, és a biztonsági kérdések itt sem tulajdonítottak kitűntetett szerepet.

Felmerült egy olyan infrastruktúra kiépítésének igénye, ami lehetővé teszi a különféle erőforrás-megosztó rendszerek összekapcsolását anélkül, hogy erőteljesen beavatkozna a már meglévő rendszerek működésébe, és a felhasználókat sem kényszeríti az erőforrások elérésének módjában (tehát a régi, megszokott eszközöket alkalmazni vagy könnyedén átültetni lehetséges). Az új elképzelés tömegekben gondolkodik és a biztonság, a különböző platformok együttműködése (interoperációs-képesség), a többfelhasználósság alapvető elemei.

A Globus rendszer fejlesztői találkoztak először azokkal az alapelvekkel, amelyeket egy ilyen rendszer tervezésénél figyelembe kell venni. Öt követelményt határoztak meg, amelyek a következők [5]:

ˇ        erőforrás-megosztó telephely autonómiája - nem avatkozhatunk bele az ottani fel­hasz­nálói vezérelvek kialakításába;

ˇ        heterogén szubsztrátum - azt jelképezi, hogy a globális rendszernek illeszkednie kell a helyi, eltérő sajátosságokhoz, a különféle architektúrákhoz;

ˇ        erőforrás-megosztási irányelvek kiterjesztése - az eltérő elven elérhető, és más paraméterezettséggel rendelkező erőforrás-telepek felé egy egységes erőforrás-kezelő felületet kell képezni;

ˇ        együttes-igénylés (koallokáció) kérdését meg kell tudni oldani;

ˇ        közvetlen (on-line) vezérlés, felügyelet - lehetővé kell tegye az erőforrás-felhasz­ná­lási (EFH) folyamat folyamatos felügyelhetőségét és irányíthatóságát.

Ezen elvek segítségével építették meg a négyrétegű ún. "homokóra" modell-alapú Grid architektúrát [6]. Az architektúra négy szintje, négy szolgáltatási felületet foglal magába. Az első szint az erőforrások szintje, ide kerülnek a már meglévő erőforrás-kezelő rendszerek. A következő szint egy egységes kommunikációs és biztonsági réteget húz fel. A harmadik szinten található az erőforrások közös reprezentációs és kezelői (menedzselő) rétege. Végül a legfelső szinten az ún. EFH kollektíva létrejötte látható, az olyan szükséges feladatok, mint az erőforrások együttes kezelése és felhasználása, valamint a kiegészítő szolgáltatások ezen a szinten valósulnak meg.

A Grid fejlődésének végleges célja egy szabványos rendszer specifikációja. Ez a folyamat is elindult, a Grid architektúrára építve, az ún. Open Grid Services Architecture (OGSA) [7] kialakítása megkezdődött, a Grid elemek és szolgáltatások Web szol­gál­tatásokon keresztüli (SOAP protokollt alkalmazva [8]) elérése fog hamarosan lehetővé válni.

1.2         Professzionális Grid szolgáltatások

Nem csak a Grid architektúrájának kialakítása a feladatunk. Szükség lehet egy kifinomult felhasználói környezet kialakítására is. Ezzel szemben a következő követelményeket szükséges támasztani:

ˇ        fejlesztői környezet kialakítása - az ilyen rendszereknek a szoftverfejlesztés teljes életciklusát kényelmes eszközökkel támogatnia kell a tervezésen, fejlesztésen át egészen a tesztelésig és/vagy a szimulációig;

ˇ        felhasználói kezelő felület létrehozása az erőforrások és az EFH adminisztrációjára és kezelésére (allokáció, de-allokáció, monitorozás, beavatkozás, felügyelet, stb.);

ˇ        erőforrás-felhasználás nyilvántartási és elszámolási feladataihoz a szükséges infrastruktúra kialakítása;

ˇ        felhasználó-támogatás (dokumentáció, súgó, letöltések, ügyfélszolgálat, stb.).

1.3         A Magyar Szuperszámítógép Grid projekt

A 2002-ben indult IKTA-4 Magyar Szuperszámítógép Grid (MGRID) projekt célja, hogy létrehozza Magyarország első professzionális szuperszámítógép Grid prototípusát. A készülő rendszernek teljesítenie kell olyan követelményeket [9], mint

ˇ        a lokális számítási kapacitások kiterjesztése globális, vagyis Grid szinten - a Grid architektúra kialakítása;

ˇ        biztonsági megoldások alkalmazása a Grid egyes részegységén és kommunikációs csatornáin;

ˇ        a SZTAKI Párhuzamos és Elosztott Rendszerek Laboratóriuma által fejlesztett P-GRADE fejlesztői környezet a teljes szoftverfejlesztési ciklust lefedi [10], a projekt célja ennek a környezetnek az illesztése a tervezett Grid architektúrához;

ˇ        ún. Grid portál létrehozása, amelynek a Grid teljes felhasználói kezelői felületét adja;

ˇ        és végül az EFH elszámoló és nyilvántartó rendszer kifejlesztése és integrálása, ami a jelen cikk szerzőinek feladata.

1.4         EFH nyilvántartó és elszámoló rendszerek Grid környezetben

Az ún. Global Grid Forum [11] kezdeményezés fogja össze a Griddel kapcsolatos kutatási-fejlesztési tevékenységeket. Elsődleges célja a Grid architektúra felépülésének elősegítése. A fórumon belül különböző munkacsoportok jöttek létre, így pl. az Accounting Models Research Group (AM-RG) [12], ami az elosztott környezetben alkalmazott EFH nyilvántartási és elszámolási rendszerek kifejlesztésével foglalkozik.

A témában Rajkumar Buyya és társai értek el áttörést az ún. GridBank létrehozásával [13], ami az ún. GRACE - GRid Architecture for Computational Economy - keretrendszer egy implementációja. A GRACE egy gazdasági elven kialakított koncepció. Buyya felismerte, hogy a felhasználóknak különböző minőségi igényei lehetségesek (QoS igények) - pl. költségminimalizálás vagy futási idő-korlátok -, ezért az egyes felhasználók és szolgáltatók között egyeztetni kell a felmerülő igényeket, és a lehető legoptimálisabb megoldást kell választani. Ez a folyamat az ún. Nimrod-G erőforrás-bróker segítségével megy végbe. A GridBank többi része gondoskodik a szükséges információs szolgáltatásokról, a kereskedelmi adatbankok infrastrukturális hátteréről, valamint konkrét kereskedelmi protokollokat definiál a tranzakciók lebonyolítására. Az ún. GridSim szimulációs környezet segítségével igazolhatók a rendszer megalkotásával elért eredmények.

Amíg ez egy általános gazdasági alapú koncepció, a jelen cikk szerzőinek munkája inkább egy rendszer-szemléletű megközelítést alkalmaz. Célunk a rendszer felépítése moduláris elven alapkövekből, lépésről lépésre. Az így létrejött rendszer egy nyílt, flexibilis eszközkészletté (toolkit) válhat, ami a már meglévő rendszerekhez ill. a változó igényekhez rugalmasan képes alkalmazkodni.

Az elkövetkezendő fejezetekben ennek a rendszernek az elemeiről és az eddig elért eredményekről lesz szó. Először a rendszerspecifikáció kerül részletes ismertetésre, majd a megvalósítás kérdéseire tér ki a cikk röviden. Végül az eredmények és értékelésük következik.

2          Rendszerspecifikáció

2.1         A specifikáció felépítése

A cikk szerzői elkészítették a rendszer teljes specifikációját, ami két fő részre, a logikai és a fizikai specifikációra bontható. A logikai specifikáció részletes ismertetése következik ebben a fejezetben.

A specifikáció kidolgozásához strukturális tervezési metodikát alkalmaztunk. A terv legfőbb részei a következők:

ˇ        adatfolyam-modell,

ˇ        entitás-relációs séma,

ˇ        a dinamikus viselkedés leírása.

A kezelendő feladat adat- ill. adatfolyam-orientált jellege, a modell csővezeték-szerű (pipeline) felépítése teszi a strukturális tervezési módszertant alkalmassá a probléma leírására.

Először a kiinduló modellt mutatjuk be, majd a specifikáció egyes részeit.

2.2         A kiinduló modell

A Stiller, Gerke, Reichl és Flury által kialakított általános elosztott EFH nyilvántartási és elszámolási modell (1. ábra) [1,2] az ún. CATI (Charging and Accounting Technologies for the Internet) projekt [4] keretein belül az Internetes kommunikációs protokollok esetében felmerülő forgalom-felhasználás kereskedelmi vonatkozású technológiai hátterét vizsgálva jött létre.  A szerzők rámutattak azonban arra is, hogy az általuk felvázolt koncepció alkalmazható Grides környezetben is [3].

Jelen cikk szerzői ezt a modell fejlesztették tovább - kiegészítették, és Grides környezetbe ültették.

1. ábra - Alapmodell

A CATI kutatók dekomponálták és tisztázták az EFH nyilvántartással és felhasználással kapcsolatos fogalmakat, amelyek a következők:

ˇ        metering vagy mérés, adatgyűjtés az erőforrás-fogyasztásra vonatkozó in­for­má­ci­ók­ról;

ˇ        mediation vagy mediálás, a mérési adathalmazból a szignifikáns információ kigyűjtése;

ˇ        accounting vagy nyilvántartásba-vétel, a mért adatok rögzítése a felhasználás szempontjából (tehát a felhasználóra, ill. a felhasználási folyamatra nézve);

ˇ        charging vagy elszámolás, amikor rögzítésre kerül, hogy az adott erőforrás-fogyasztásnak milyen költségei voltak a felhasználóra nézve;

ˇ        billing vagy számlázás.

A jól körülhatárolt fogalmak segítségével a rendszer feladatai könnyedén egységekbe (modulokba) formálhatóak. Megjegyzendő, hogy ez a fogalomrendszer nem tartalmaz fizetéssel, ill. számlakiegyenlítéssel kapcsolatos elemeket, de ezekre a kérdésekre jelenleg is léteznek internetes megoldások, így ezek tárgyalására nem kívánunk kitérni. Ha a rendszer tervezésekor a nyíltságot kiemelt szempontként kezeljük, akkor egy már meglévő pénzügyi rendszerhez (payment) a tervezett rendszer könnyen illeszthetővé válik.

2.3         Adatfolyam-modell

A fenti modell kiegészítésének és továbbfejlesztésének eredménye a specifikáció adatfolyam-modellje. A modell bizonyos részei nem a nyilvántartó és elszámoló rendszerhez, hanem inkább az erőforrás-kezelő infrastruktúrához tartoznak. Fontos azonban a folyamat idetartozó részeit is elemezni ahhoz, hogy az általunk vizsgált rendszer és az erőforrás-kezelő közötti kapcsolatot pontosan definiálni lehessen.

Az ERH nyilvántartó és elszámoló rendszernek három fő része van (3. ábra): EFH nyilvántartó (accounting), elszámoló (charging) és számlázó (billing) alrendszerek.

2. ábra - Adatfolyam kontextus

A 3. ábrán látható a teljes adatfolyam-modell. A felhasználó (fogyasztó - resource consumer) igénye (job creation request) eljut az erőforrás-kezelőhöz, ami létrehozza az erőforrás-felhasználó munkafolyamatot (job creation). A folyamat a számítógépen futni kezd (process). Ez adatfolyam szinten úgy ábrázolható, mint egy tároló, amelyből fogyasztásra vonatkozó információt lehet kiolvasni (resource consumption). Az így kapott adatok a mérési (metering) modulon keresztül kerülnek a nyilvántartást végző folyamathoz (accounting), ami rögzíti az adatokat a nyilvántartóban (accounting register). A nyilvántartásba vételhez szükségesek az erőforrás-kezelőből érkező erőforrás-azonosító (resource information), és a fogyasztási kérelmet azonosító (usage request) információkra.

Az elszámoló alrendszer rendelkezik egy nyilvántartó lekérdező modullal (accounting query). A lekért nyilvántartási rekordok segítségével áll össze egy adott időszakra vonatkozó fogyasztás mértéke, ami a beárazással (pricing) jut el az elszámolóba (charging), ami rögzíti az adatokat az elszámolási nyilvántartóban (charging register). Ez a folyamat az elszámoló modulon keresztül kezdeményezett folyamat elindításával megy végbe, az elszámolni kívánt fogyasztási munkafolyamat (job information) vagy éppen egy időszak paramétereit megadva. Az elszámoláskor minden egyes rekord saját azonosítót kap, amit egy belső számláló (charging no. counter) lekérdezéséből nyerünk.

A számlázási alfolyamat szintén egy külső kérésre (ami általában automatizált, tehát jól körülhatárolhatóan pl. egy adott fogyasztó meghatározott időszakra vagy adott munkafolyamataira vonatkozólag) indul el, amelyben a szükséges elszámolási rekordok lehívása (charging query) után előáll a számla a fogyasztói információk (consumer information), a szolgáltató információi (provider information) alapján, valamint a számla sorszámát meghatározó számláló (billing no. counter) lekérdezésével. Az elkészült számla pl. e-mail-ben eljut a felhasználóhoz (fogyasztóhoz) és tárolásra kerül az archívumban (receipt file).

 

3. ábra - Adatfolyam-modell

2.4         Entitás-relációs modell

Az entitás-relációs modell nincs normalizált alakra hozva. Ez azért szükséges, mert az elosztott környezetben egy adott feldolgozó egységben rendelkezésre kell állnia minden szükséges információnak. A szürkén jelölt entitások, mint tárolt adatszerkezetek, a többi entitás pa­ra­mé­terként, ill. üzenet-mezőként jelenik meg a rendszerben.

Az accounting rekord tartalmazza az erőforrás-felhasználás rögzítésre kerülő adatait, így egy adott felhasználási munkafolyamathoz (request) tartozó, adott időpontban (date), egy adott paraméterű (parameter name), meghatározott mértékegységben (parameter unit) kifejezett mért fogyasztást (amount) egy megnevezett erőforráson (resource).

Egy erőforráson (resource information), amit egyedi azonosító (ID) jelöl, több, különböző paraméter (parameter) mérése lehetséges. Minden egyes felhasználási folyamat (usage request) szintén egyedi azonosítóval van ellátva. Az elszámoláshoz szükség van a felhasználási folyamat rögzítésére (utilization information), ami a felhasználási folyamat (request) az erőforrás (resource) foglalásának kezdeti (begin date) és végidőpontját (end date) tartalmazza. Ezt azonban az erőforrás-kezelő tartja nyilván, így az paraméterként jut az EFH nyilvántartó és elszámoló rendszerbe. Hasonló módon az ügyfél-információ (consumer information) is paraméter.

4. ábra - Entitás-relációs modell

Az árazási szabályokat írja le a pricing rule entitás. A szabály megadja, hogy egy adott erőforráson (resource) egy adott paraméterhez (parameter name, parameter unit) milyen egységár (unit price) tartozik egy megadott időszakban (begin time, end time). Ezeknek a szabályoknak a szuperpozíciója érvényes abban az esetben, ha fedik egymást. Az ilyen szituációt úgy kell tekinteni, mintha egy alapárhoz képest az átlapolt időszakban extra felárat kellene fizetni.

A charging rekordok rögzítik egy megadott felhasználó (consumer) fogyasztását (amount) és a hozzátartozó árat (price) megadott időszakban, adott erőforrásra, EFH folyamatra nézve. Az elszámolt rekordok számozva (no.) vannak, és időbélyeg (charge date) is tartozik hozzájuk.

A számla két részből áll. A fő-entitás (receipt) jelöli a tulajdonost (owner) és a számla sorszámát (no.). A számlához kapcsolódhat több számlabejegyzés (receipt entry), amelyek a tételest fogyasztást tartalmazzák.

2.5         Dinamikus modell

A három alrendszerhez három külön folyamat tartozik. Ebben a fejezetben is­mer­tet­jük algoritmikus szinten a folyamatok dinamikus viselkedését.

Az első folyamat a nyilvántartásba-vétel, és a következő lépésekből áll:

1.      Az EFH munkafolyamat (job) elindítása.

2.      A feldolgozási folyamat (process) elindítása.

3.      Az elszámolási folyamat egy példányának elindítása, a folyamat kapcsolódik a ko­ráb­ban létrehozott feldolgozási folyamathoz úgy, hogy megkapja a folyamat azonosítóját (process id) és az adott munkafolyamatra (job) vonatkozó információkat (job in­for­ma­tion).

4.      Az elszámolási folyamat elindítja a mérőrendszert a folyamat azonosítójának át­a­dá­sá­val.

5.      A mérőrendszer lekérdezi az operációs rendszert a vizsgált paraméter jelenlegi állásáról.

6.      A mérőrendszer visszaküldi az így kapott információt a nyilvántartónak, majd kilép.

7.      A nyilvántartó folyamat ellenőrzi, hogy a visszanyert adat érvényes-e - ez jelentheti azt, hogy a feldolgozási folyamat fut-e még.

8.      Ha a feldolgozási folyamat nem fut a nyilvántartó is terminál.

9.      Ellenkező esetben egy meghatározott ideig vár.

10.  A folyamat a 4. lépésre ugorva folytatódik.

Az elszámoló alrendszerben futó folyamatban egy kérés hatására előáll a kérésben fel­paraméterezett elszámolási rekord vagy rekordok listája, ami vagy amik az elszámolási nyil­vántartóban tárolódnak. Az alrendszer egyes moduljai folyamatosan, szolgáltatás jel­leg­gel rendelkezésre álnak, vagyis egy konkrét kérés esetén egy állapotmentes ki­szol­gáló pél­dány indul el.

1.      Az elszámoló kérésben megkapja, hogy mely időszakot, milyen felhasználó(ka)t, ill. mely munkafolyamatokat kell elszámolni.

2.      Az elszámoló a fenti kéréssel összhangban egy újabb paraméterezett kérést indít az árazási szabályok lekérdező-felületén.

3.      A lekérdező-felület lehívja a szükséges rekordokat az EFH nyilvántartóból.

4.      A lekért rekordok és a rendelkezésre álló árazási szabályok alapján meghatározza az adott kérésre érvényes árazási szabályokhoz tartozó fogyasztások mértékét, és az így létrehozott rekordokat küldi vissza az elszámolóba

5.      Az elszámoló kiszámolja a visszakapott rekordokhoz tartozó árakat, becímkézi őket (idő, sorszám) és az így kapott adatokat tárolja az elszámolási nyilvántartóban.

A számlázó alrendszer működése hasonló az elszámolóéhoz. Itt is folyamatosan rendelkezésre álló kiszolgálók futnak.

1.      A számlázási kérelem beadása a számlázó modulba.

2.      A számlázó modul lehívja a szükséges elszámolási rekordokat az elszámoló le­kér­de­ző-felületén keresztül.

3.      A számlázó összeállítja a számlát a rekordok és egyéb rendelkezésre álló információk alapján

4.      A számlá(ka)t a fogyasztónak kézbesíti, ill. letárolja az archívumban.

3          Megvalósítás

A specifikáció fizikai része is elkészült, amelynek készítésekor alkalmazott főbb elvek kerülnek ebben a fejezetben ismertetésre.

A rendszer elosztottságára vonatkozóan a megállapíthatjuk, hogy a mérő- és nyil­ván­tartó modulokon kívül, ami erőforráshoz kötött, a többi egység fizikailag bárhova telepíthető. A kommunikációs közeg standardizálása végett az egyes modulok HTTP-n keresztül GET ill. ún. "form" POST kérésekkel XML dokumentumok [14] küldésével cserélnek információt. Az adattárak, nyilvántartók eléréséhez SQL környezet (adatbázis eszközréteg) használtunk.

Az EFH nyilvántartó alrendszer és az árazó modul kifejlesztése befejeződött. A fejlesztés UNIX környezetben többnyire Perl nyelven folyt. Csak a mérőmodul elkészítéséhez volt szükség C kód írására, itt az ún. libgtop programozói könyvtárat alkalmaztuk, ami UNIX alapú rendszereken a futó folyamatok erőforrás-felhasználására vonatkozó adatokat képesek lekérni az operációs rendszertől. Az adatkapcsolati réteg a Perl DBI felületén keresztül valósul meg. Adattárolásra akár CSV (tagolt szöveges-állomány), ill. MySQL adatbázis is alkalmazható.

Példaparaméterként CPU időt mértünk ütemszámban (jiffy) kifejezve. Az adatok rögzítése a nyilvántartóba 10 másodpercenként történt.

Amikor az accounting alrendszer elindul, 10 másodperces ciklusokban indítja a mérőmodult, majd minden regisztrátumról rekordot készít az adatbázisban. Az árazó modul egy adott árazási szabály esetén lekérdezi a kezdeti és végidőpontokhoz tartozó időben korábbi, legközelebbi rögzített időpontokhoz tartozó EFH rekordokat. Az így kapott két mért érték különbségéhez hozzárendeli a szabályhoz tartozó egységárat.

A nyilvántartó modult illesztettük a Condor [15] Grid ütemező környezetéhez. A Condor, amikor kioszt egy munkafolyamatot egy adott erőforrásra, képes elindítani egy előkészítő modult (wrapper), ami a mi esetünkben módosításra került, hogy a folyamat indulásakor a dinamikus viselkedésben leírtak szerint az EFH nyilvántartó alfolyamat elindulhasson.

4          Eredmények és értékelés

Az elvégzett munka legfontosabb eredménye egy EFH nyilvántartó és elszámoló rendszer Grides környezetben alkalmazható architektúrájának és részletes terveinek kimunkálása. A tervek alapján elkészítettük a nyilvántartó alrendszer prototípusát, azt a Condorral integráltuk és telepítettük a tanszéki klaszterre, majd próbafuttatásokat végeztünk. Az alkalmazás jelenlegi állapotában eleget tesz az elosztottságra és az esz­köz­készletre (toolkit) vonatkozóan az 1.4. pontban megfogalmazott követelményeknek. A prototípus alkalmas a tesztelési fázis végrehajtására.

Az architektúrát a mérési és elszámolási pontosság szempontjából vizsgálva az alábbi megállapításokat tehetjük.

A fogyasztott CPU ütemszámot az operációs rendszer méri, így annak pontosságát adottnak kell tekintenünk. A mérés pontosságát alapvetően határozza meg az egy alkalommal elindított folyamat futási idejének és az ütemszámok összegzését végző mintavételek gyakoriságának viszonya. A mérési hiba két legfőbb forrása: a mintavétel során elvégzendő adminisztrációs többletfeladatok (overhead) és az utolsó mintavételi periódusban nem regisztrált fogyasztás. Ha a mintavételi periódust növeljük, akkor az utolsó periódusban elvesző fogyasztás okozta hiba növekszik. A periódusidő csökkentésével ez a hiba kisebb lesz, viszont az adminisztrációs többletfeladatokra fordított összes idő megnövekedik. Ez a növekedés nagy pontossággal megmérhető és kiszámolható, ellenben az utolsó periódusban elszenvedett veszteség (aminek várható értéke nem zérus) csak statisztikusan kezelhető. Ráadásul ez utóbbi veszteség minden esetben a szolgáltató kárára történik.

A mintavétel gyakorisága meghatározó a gyűjtött adatok mennyiségét (adatbázisok méretét) és a tarifálás pontosságát illetően is. A mediálás során a rögzített adatok mennyiségét redukáljuk. A mediálásra három módszer kínálkozik: a mintavételi időpontok szinkronizálása az árazás időhatárainak változásaihoz, az árazási időhatárok rögzítése definiált időintervallumokhoz és az arányosítás.

A megfelelő mintavételezési periódusidő és mediálási stratégia meghatározása, a nyilvántartó és elszámoló rendszer hibáinak, pontosságának és hitelességének megállapítása a megvalósult rendszer paramétereinek mérése és tesztelése alapján történhet.

A közeli jövőben a következő feladatok kidolgozására kell koncentrálnunk:

ˇ        az általunk felvázolt mérési modell helyességének igazolása kísérletekkel;

ˇ        hitelesítésre alkalmas környezet és mintafeladatok (benchmarkok) kidolgozása;

ˇ        a mediálási koncepció megvalósítása;

ˇ        a hátralevő részek implementálása;

ˇ        integrálás más helyi erőforrás-kezelővel (pl. Sun Grid Engine);

ˇ        a magyar szuperszámítógép Grid prototípushoz történő illesztés.

Az árazási szabályok kiegészítésével lehetőség nyílna egyedi szerződési jelleggel meghatározott árazási politikák alkalmazására is. Így pl. lehetne egyedi munkafolyamatra vagy fogyasztónként más-más árat megállapítani.

Nagyobb időtávlatban az alábbi feladatok megoldását tűztük ki:

ˇ        integrálás pénzügyi rendszerrel

ˇ        kiterjesztett árazási funkciók támogatása

ˇ        elszámolási limitek támogatása

ˇ        OGSA konform felület kialakítása

 

5          Összefoglaló

Ismertettük az általunk javasolt erőforrás-felhasználást nyilvántartó és elszámoló rendszer kialakításánál alkalmazott koncepciót, és az ez alapján elkészített rendszertervet. A nyilvántartó alrendszer és a beárazó modul prototípusa elkészült. Az így részlegesen működő rendszert telepítettük a tanszéki klaszteren, és próbafuttatásokat végeztünk. További célunk a teljes rendszer implementálása, az alkalmazott mérési módszerek hitelességének vizsgálata, kiértékelése, és javítása, valamint rendszerintegráció más helyi erőforrás-kezelővel is.

Köszönetnyilvánítás

Jelen cikkben bemutatott munka az IKTA-00075/2001 projekt keretein belül készült, amit az Oktatási Minisztérium tett lehetővé az IKTA-4 tender kiírásával információs és kommunikációs technológiák és alkalmazások fejlesztésének támogatására.

Hivatkozások

1.        B. Stiller, J. Gerke, P. Reichl and P. Flury: The Cumulus Pricing Scheme and its Integration into a Generic and Modular Internet Charging System for Differentiated Services. ETH Zurich, TIK Report Nr. 96 (September 2000)

2.        B. Stiller, J. Gerke, P. Reichl, P. Flury and Hasan: Charging Distributed Services of a Computational Grid Architecture. IEEE International Symposium on Cluster Computing (CCGrid 2001), Workshop on Internet QoS for the Global Computing (IQ 2001), (May 2001) 596-601

3.        B. Stiller, J. Gerke, P. Reichl and P. Flury: A Generic and Modular Internet Charging System for the Cumulus Pricing Scheme. Journal of Network and Systems Management, 3(9) (September 2001) 293-325

4.        D. Billard, N. Foukia: Charging and Accounting Technologies over the Internet. 6th HP OpenView University Association WS (HPOVUA'99), Bologna, Italy (June 12-15, 1999)

5.        K. Czajkowski, I. Foster, N. Karonis, C. Kesselman, S. Martin, W. Smith, S. Tuecke.: A Resource Management Architecture for Metacomputing Systems. Proc. IPPS/SPDP '98 Workshop on Job Scheduling Strategies for Parallel Processing (1998)

6.        I. Foster, C. Kesselman and S. Tuecke.: The Anatomy of the Grid: Enabling Scalable Virtual Organizations. International J. Supercomputer Applications, 15(3) (2001)

7.        I. Foster, C. Kesselman, J. Nick and 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)

8.        D. Box, D. Ehnebuske, G. Kakivaya, A. Layman, N.Mendelsohn, H. Frystyk Nielsen, S. Thatte, D. Winer: Simple Object Access Protocol (SOAP) 1.1. W3C Note, http://www.w3.org/TR/SOAP/ (May 8, 2000)

9.        IKTA-00075/2001, Magyar Szuperszámítógép Grid. Pályázat információs és kommunikációs technológiák és alkalmazások fejlesztésének támogatására, Oktatási Minisztérium, Budapest (November 2002)

10.     P. Kacsuk: Parallel Program Development and Execution in the Grid. Proc. of PARELEC 2002, Warsaw (2002)

11.     Global Grid Forum, URL: http://www.gridforum.org/

12.     Accounting Models Research Group (AM-RG), Global Grid Forum, URL: http://people.nas.nasa.gov/~thigpen/accounts-wg/

13.     A. Barmouta and R. Buyya: GridBank: A Grid Accounting Services Architecture (GASA) for Distributed Systems Sharing and Integration. 17th Annual International Parallel & Distributed Processing Symposium (IPDPS 2003) Workshop on Internet Computing and E-Commerce, Nice, France (April 22-26, 2003)

14.     T. Bray, J. Paoli, C. M. Sperberg-McQueen, and E. Maler: Extensible Markup Language (XML) 1.0, (Second Edition). W3C Technical Report 20001006, http://www.w3.org/TR/2000/REC-xml-20001006 (2000)

15.     Douglas Thain and Miron Livny: Condor and the Grid. in Fran Berman, Anthony J.G. Hey, Geoffrey Fox, editors, Grid Computing: Making the Global Infrastructure a Reality, John Wiley (2003)

16.     Rajesh Raman and Miron Livny: High Throughput Resource Management. The Grid: Blueprint for a New Computing Infrastructure, Chapter 13, Morgan Kaufmann, San Francisco, California (1999)