Párhuzamos programok checkpointolása és migrációja klasztereken¹

Kovács József

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

1518 Budapest, Pf. 63.

jozsef.kovacs@sztaki.hu

Bevezetés

Klasztereken futó nagy számításigényû párhuzamos alkalmazások checkpointolása a processzek állapotterének és a köztük zajló kommunikációnak egy konzisztens állapotban történõ lementését jelenti. Hosszan futó alkalmazások esetében elengedhetetlen az egyes processzek bizonyos idõközönkénti lementése annak érdekében, hogy a futtató egységek esetleges terhelési viszonyait kiegyenlítsük az egyes processzek klaszteren belüli áthelyezésével. Továbbá tudni kell az alkalmazás futtatását felfüggeszteni majd folytatni egy adott futási állapotból megõrizve ezáltal az addig elkészült számítási eredményeket. Ez utóbbi szükséges akkor is, ha a klaszter valamely gépének kiesése az alkalmazás elhalásához vezet. Jól felismerhetõ, hogy számos esetben nélkülözhetetlen egy checkpointoló rendszer alkalmazása.

A párhuzamos programok checkpointolása rendkívül összetett feladat, melynek egy lehetséges megoldása kerül bemutatásra a cikkben. Ez az elosztott checkpoint- és migrációs rendszer jelenleg a P-GRADE [1] grafikus alkalmazásfejlesztõi környezetbe kerül beágyazásra.

A legnagyobb nehézséget és egyben kihívást az jelenti, hogy a checkpointoló és migráló rendszert oly módon építsük meg, hogy a funkcionalitáshoz szükséges változások teljesen átlátszóak maradjanak a P-GRADE használója számára, a programokban semmilyen változtatást ne igényeljen és a P-GRADE által használt GRAPNEL[5] nyelvhez is tökéletesen illeszkedjen.

Párhuzamos programok checkpointolásának nehézségei

Az elosztott checkpointoló rendszernek három alapvetõ problémát kell megoldania. Képesnek kell lennie az alkalmazást alkotó processzek állapotterének, az üzenetközvetítõ alrendszerben keringõ üzeneteknek és a processzek közötti kapcsolatoknak a lementésére és visszaállítására. Továbbá mindezt oly módon kell tennie, hogy üzenetek ne duplikálódjanak, ne vesszenek el és célba érjenek egy esetleges processz másik futtató egységre történõ áthelyezését követõen is.

Kommunikáló processzek esetén az alkalmazás konzisztens állapotának lementését nagyban nehezítik a rendszerben bolyongó üzenetek. Az alkalmazás lementése oly módon történik, hogy a processzek végrehajtásának felfüggesztését követõen a teljes memóriatérképet és végrehajtási kontextust leolvassuk és fájlba mentjük. Az alkalmazás azonban nem függeszthetõ fel bármely idõpillanatban, hiszen egy megszakított üzenetküldés vagy üzenetátvétel programhibát okozhat akkor, ha adott paraméterekkel az eredeti környezetben megkezdett üzenetküldés már egy átrendezett, új környezetben kerül lefutásra a visszaállítást követõen. Ez esetben a környezet a processzt körülvevõ kommunikációs kapcsolatot és a partnereket jelenti.

Az üzenetközvetítésen alapuló alkalmazások checkpointolásának alapvetõ nehézsége, abban rejlik, hogy egy folyamatosan kommunikáló processz halmazban nem tudunk egyértelmûen olyan idõpontot meghatározni, amikor a processzek nem kommunikálnak és üzenetek sincsennek az üzenetközvetítõ alrendszerben. Az üzenetközvetítõ réteg változtatására nincs lehetõség, így arra sincs módunk, hogy egy adott idõpillanatban esetleg lementsük e réteg belsõ állapotterét. Tehát valamilyen módon szükség van annak biztosítására, hogy az állapottér lementésekor ne legyenek keringõ üzenetek a rendszerben, ellenkezõ esetben üzenetvesztés vagy duplikálódás történhet.

Megoldandó továbbá az üzenetek célba érkezésének biztosítása is. Tegyük fel, hogy egy processz üzenetet küld egy másiknak, és éppen az átvétel elõtt mentjük le az alkalmazás állapotterét. Lementést követõen a fogadó processzt áthelyezzük egy másik gépre, majd innen folytatjuk a végrehajtást. Nyilvánvaló, hogy az üzenet nem fog célba érni, hiszen a célállomáson már nem létezik a címzettként megjelölt processz. Az üzenetközvetítõ alrendszert pedig nincs lehetõség oly módon megváltoztatni, hogy az ilyen eseteket intelligensen lekezelje, az üzenet újrapostázásával.

Már csak azért sem, mert ha erre fel lenne készülve a kommunikációs alréteg, akkor sem lenne mûködõképes egy újabb akadály miatt. Ez pedig nem más, mint a processzek kommunikációs azonosítóinak megváltozása egy újbóli belépés esetén. Tehát az eredeti üzenet által tartalmazott címzett többé már nem létezik, attól a pillanattól, hogy kilépett a kommunikációs rétegbõl. Márpedig ez elkerülhetetlen, ha migrálni akarjuk, vagy esetleg teljesen újra szeretnénk indítani az alkalmazást.

A P-GRADE rendszer

A P-GRADE [1] egy grafikus párhuzamos programozási környezet, amely az általa generált elosztott alkalmazás processzei közötti kommunikációt üzenetváltással valósítja meg. A programozó az elkészítendõ alkalmazást magas szintû grafikai elemekkel tervezheti meg. Grafikai elemekkel, ikonokkal az alkalmazás teljes egészében “megrajzolható”, ezek legfontosabb szerepe mégis a program topológiájának és az üzenetek kezelésének megvalósításakor van. Mindezen grafika mögött a P-GRADE-hez kifejlesztett GRAPNEL nyelv rejtõzik, mely a magas színtû grafikai elemeket és ezzel magát az alkalmazást írja le. E nyelv oly módon lett megtervezve, hogy az alkalmazás topológiáján, a processzek belsõ felépítésén és a kommunikációs események megvalósításán kívül képes magába fogadni normál hagyományos C nyelven írt kódrészleteket is.

A P-GRADE egy GRAPNEL nyelvû programot generál, amely végsõ soron PVM vagy MPI alkalmazásként realizálódik, hiszen a GRAPNEL nyelv fordításakor az üzenetközvetítést jelzõ nyelvi elemek PVM vagy MPI rutinok segítségével kerülnek megvalósításra. Ily módon a P-GRADE-ben készített programok bármilyen rendszeren képesek futni, ahol a PVM vagy MPI kommunikációs szoftverek megtalálhatóak.

A P-GRADE alkalmazás

A P-GRADE rendszerben készített alkalmazások egy PVM vagy MPI programmá transzformálódnak. Ezek a programok oly módon épülnek fel, hogy az alkalmazásban elsõ lépésként egy GRAPNEL szerver processz jön létre, mely az alkalmazás teljes futási ideje alatt életben marad és az indítást követõen a következõ feladatokat végzi el:

• a felhasználói processzek indítása,

• a felhasználói processzek közötti kapcsolatok felépítése.

Felhasználói processznek nevezzük a P-GRADE-ben definiált összes processzt. A szerver processz az alkalmazás részeként mindössze a koordinációs feladatokat látja el. Miután minden felhasználói processz inicializálva lett a szerver várakozó állapotba kerül és a különbözõ kérelmek kiszolgálását végzi. Ilyen például a fájlmegnyitás vagy szövegkigépelés a konzol gépen.

Tehát a P-GRADE alkalmazás felépítését megvizsgálva kézenfekvõ, hogy az összes checkpoint szerver jellegû funkció egyszerûen beilleszthetõ a GRAPNEL szerverbe, hiszen minden szükséges információ és vezérlés rendelkezésre áll a felhasználói processzek felett.

Checkpointolás P-GRADE-ben

Egy checkpointoló rendszer megépítésekor és használatakor alapvetõ szempont a felhasználói kód, az üzenetközvetítõ alrendszer és az operációs rendszer változatlanul hagyása, azaz a checkpointoló rendszer használhatósága fordított arányban áll az általa megkövetelt felhasználói változtatások mennyiségével. Ennek teljesítése érdekében rétegzõdéses felépítés a legcélszerûbb, melynek során a már létezõ GRAPNEL nyelvi réteget használjuk fel erre a célra.

A P-GRADE által használt GRAPNEL nyelv eredetileg is az alkalmazás és az üzenetközvetítõ alrendszer közé épül be a generált programban, tehát ennek módosításával érhetjük el azokat a szükséges checkpointoló funkciókat, melyek az alkalmazás szintû koordinációs feladatokat látják el.

Az elõzõekben már említésre került a párhuzamos checkpoint során fellépõ néhány olyan eset, amely megoldásra vár a rendszer megépítése során. A checkpointolás megkezdésekor a felhasználói processzeket megszakítjuk egy szignál segítségével, a lementés elvégzése érdekében. Azonban kommunikáció megkezdését követõen indított checkpoint után a processz azonosító (TID) megváltozhat. Ennek hatására a kommunikáció elvész, mert az azonosító nem írható át a kommunikáció megkezdését követõen. Tehát a kommunikációt atomi mûveletként kell kezelni, megszakítani nem lehet. Ebben az esetben viszont a checkpoint megkezdését jelzõ szignál nem érvényesül azokban a processzekben, amelyek a checkpointolás pillanatában kommunikáción várakoznak, így azok beragadhatnak.

A következõ technika alkalmazása megoldja ezt a problémát. A kommunikáción várakozó processzeket, csak egy üzenet érkezése volna képes kiléptetni a tiltott zónából. Eme üzenet biztosítása érdekében, tehát a szerver processznek kell minden ilyen esetben üzenetet küldeni a checkpointolandó processz számára. Ebben az esetben viszont a GRAPNEL kommunikációt szükséges felkészíteni a szerver processztõl érkezõ extra üzenet fogadására, illetve annak lekezelésére. A checkpoint üzenet a processzt kilépteti a kommunikációból, ezt valamilyen módon lekezeljük, megtörténik a checkpointolás, majd hogy a processz normál mûködését ne befolyásoljuk, megismételjük a kommunikációt mielõtt a felhasználó számítást végzõ kódjára tovább engednénk. Ez a technika biztosítja, hogy a checkpoint megkezdésekor minden processz kommunikáción kívül legyen megszakítva.

A checkpointolás megkezdésekor tehát minden processz kommunikáción kívüli programrészben áll, azonban a kommunikációs alrétegben továbbra is lehetnek üzenetek. Az üzenetek lementése pedig a kommunikációs réteg módosítása nélkül nem lehetséges. Ennek feloldására alkalmazható egy egyszerû technika, melyet már a CoCheck[3] nevû checkpoint rendszerben is alkalmaztak. Ez pedig nem más, mint az alréteg üzeneteinek kiürítése. Ennek részletes ismertetése a migrációs fázisok fejezetben található.

Az elõzõekben megismert technikák kivitelezéséhez természetesen szükség van a felhasználói szoftver réteg és a kommunikációs alréteg közötti extra rétegre, mely a P-GRADE által generált alkalmazásoknál a GRAPNEL réteg. Ennek segítségével érhetjük el, hogy az alkalmazás változtatása nélkül a fent leírt technikákat alkalmazzuk.

A checkpointoló rendszer építõkövei

A checkpointolás illetve migráció P-GRADE rendszerben történõ megvalósításához mindössze a GRAPNEL nyelv által megvalósított funkciókat, illetve a szervert kell módosítani. Természetesen ezen kívül szükség van egy olyan szoftverre is, mely a processz állapotterének lementését elvégzi. Ilyenek már készültek korábban, így ezek vizsgálata és a legalkalmasabb kiválasztása után annak integrálása következett. A P-GRADE-ben megvalósított checkpointoló és migráló rendszer komponensei a következõkben kerülnek bemutatásra.

Checkpoint és Migráció koordinálás: GRAPNEL szerver

Az alkalmazás kiszolgálójaként mûködõ grapnel szerver processz, magába foglalja a checkpointolás és migrálás koordinációs feladatait is. Ennek során biztosítja, hogy az egyes processzekhez eljusson a megszakítást jelzõ szignál és a checkpoint üzenet. Elvégzi a processzek kiléptetését, újraindítását és az áthelyezett processzek esetén a feléledést követõen újra beazonosítja a processzt, majd beilleszti azt az alkalmazásba. Ennek megfelelõen figyelemmel kíséri az egyes processzek migrációs állapotait és kezeli azokat. A grapnel szerver hatásköre a checkpoint fájlok menedzselése is, mely a jelenlegi fázisban egy egyszerûen megvalósítható sorszámozást jelent.

Természetesen a migráció igénye nem magában az alkalmazásban merül fel, így szükség van a grapnel szerver és egy külsõ vezérlõ kapcsolatára is. Kézenfekvõ, hogy ezt jelenleg a P-GRADE rendszer jelenti, amelybõl migrációt lehet kezdeményezni. A P-GRADE rendszerben jelenleg fejlesztés alatt áll továbbá egy terhelés kiegyenlítõ egység is, mely a klaszterben található futtató egységek terhelési viszonyaitól függõen utasítja a GRAPNEL szervert a migráció elvégzésére.

Checkpoint végrehajtása: GRAPNEL könyvtár

A checkpoint illetve migráció levezetéséhez a felhasználói processz oldalon a GRAPNEL könyvtár módosítása szükséges, mely a felhasználó által készített alkalmazás számára teljes mértékben láthatatlan. Ennek a rétegnek a módosítása tartalmazza

• a checkpoint üzemmódú futáshoz szükséges inicializálási feladatokat,

• a checkpoint szignál és üzenet lekezeléséhez szükséges változtatásokat,

• a kommunikációs rétegben található üzenetek kiürítéséhez szükséges koordinációt,

• a kommunikációs rétegbõl történõ ki illetve belépést megvalósító modulokat,

• és a processz újraéledését követõ azonosítást.

Processz állapotának lementése: ESKY

Az ESKY[4] checkpointoló programot David Gibson készítette a CAP Research Program keretein belül a The Australian National University-n. Jelenlegi verziója Linux és Solaris operációs rendszer alatt képes checkpointolni egy processzt. Teljes mértékben felhasználói módban fut, tehát nincsen szükség a kernel megváltoztatására. Az eredeti programot sem kell módosítani a checkpointoláshoz, mindössze néhány speciális feltételt kell annak teljesítenie.

A checkpointolandó processzt az ESKY-n keresztül kell elindítani, mely gyermek processzként elindítja az általunk megadott programot, és annak befejezõdéséig a rendszerben marad. Ahhoz, hogy checkpoint készüljön saját processzünkrõl, USR2 szignált kell küldeni az ESKY-nek. A checkpoint fájl nevét szintén indításkor paraméterként kell megadni, a checkpoint fájl kiírását követõen a program tovább fut.

Ahhoz, hogy az ESKY felhasználható legyen a párhuzamos checkpointoló rendszer részeként, szükséges volt néhány módosítást elvégezni:

• ESKY kontrollálása átlátszó módon a checkpointolandó programból

Szükséges, hogy a gyermekként elindított checkpointolandó program valamilyen módon információt közöljön az õt checkpointoló ESKY-vel, illetve lekérdezzen tõle bizonyos beállításokat. Ennek megvalósítása a “stat” rendszerhívás felüldefiniálásával történik, oly módon, hogy az „/esky/<parancs>” formátumú fájlnévvel meghívott rutin esetén a

parancsot az ESKY értelmezi. Ez a megoldás az ESKY nélküli futtatás során sem okoz futási hibát.

• Checkpointolás megkezdése elõtt és befejezése után tetszõleges feldolgozó rutinok lefuttatása

A tényleges állapottér lementése elõtt illetve után szükséges bizonyos beállítások elvégzése, mint például a kommunikációs csatornák kezelése. Ez oly módon oldható meg, hogy az elõzõekben említett parancsok segítségével egy ún. callback rutint definiálunk az ESKY számára. Az ESKY számára két callback rutin definiálható: az elõfeldolgozó és utófeldolgozó függvények. Ezek automatikusan lefuttatásra kerülnek a checkpointolás elõtt illetve után.

A migráció fázisai

Ebben a fejezetben a migrációs folyamat kerül ismertetésre. A P-GRADE-ben a következõ fejezetekben ismertetett módszerek elsõsorban a PVM környezethez igazodnak.

Inicializálás

A checkpointolás elvégzéséhez szükséges inicializálás az alkalmazás indításakor történik meg. Az alkalmazást a megfelelõ paraméterekkel indítva, a GRAPNEL szerver checkpoint üzemmódban mûködik. Ilyen esetben induláskor felveszi a kapcsolatot a P-GRADE-el, majd megkezdi a felhasználói processzek indítását, az alkalmazás felépítését.

Checkpoint üzemmódban a processzeket az ESKY program gyermekeként kell indítani, melynek legegyszerûbb módja a kommunikációs rétegben a debugger üzemmód támogatást felhasználni. Miután az összes processz elindítása megtörtént, a szerver várakozó állásba kerül, checkpoint szempontjából további inicializálási teendõje nincs.

A felhasználói processzek az elindulásukat követõen azonosítják magukat, majd az alkalmazásban betöltött szerepüknek megfelelõ kommunikációs beállításokat letöltik. Ezt követi a checkpointolás inicializálása, mely során beállításra kerül a szignált lekezelõ függvény és a checkpointolás elõtt illetve után az ESKY által végrehajtandó rutinok. Ezzel az inicializálási fázis befejezettnek tekinthetõ.

Megszakítás

Az alkalmazás processzeinek megszakításával veszi kezdetét a migráció. A már elõzõekben ismertetett technikának megfelelõen a GRAPNEL szerver egymást követõen küld szignált illetve checkpoint üzenetet a migrálandó processzeknek.

Mivel a felhasználói processz kapja meg a GRAPNEL szerver által küldött szignált, azonban ezt a szülõként futó ESKY programnak kell megkapnia, így a lekezelõ függvény a szignál továbbítását végzi. Ez elegendõ hiszen az ESKY a késõbbiekben mindenképp felfüggeszti a processz futását és az elõfeldolgozó rutin révén a checkpointolás elõtt a vezérlést is visszaadja.

A szignál és checkpoint üzenet együttes alkalmazásával biztosítható, hogy a processzek futása kommunikáción kívüli kódrészletben függesztõdik fel, majd automatikusan megkezdõdik az ESKY általi processz állapottér lementése. Ennek elsõ lépéseként az ESKY lefuttatja az inicializáláskor beállított checkpoint elõfeldolgozó rutint, mely elvégzi az üzenetek szinkronizációját.

Üzenetek szinkronizációja

Az üzenetek szinkronizációjának célja a kommunikációs alrétegben keringõ üzenetek kiürítése. Ez oly módon történik, hogy minden egyes processz a többinek küld egy “üzenetküldés vége” típusú üzenetet, majd megkezdi átvenni sorban minden egyes processztõl az elküldött üzeneteket. Az üzenetátvételt egy processztõl addig ismétli, míg meg nem érkezik az “üzenetküldés vége” típusú üzenet, hiszen ez jelzi, hogy a feladótól biztosan nem fog több üzenet érkezni. Miután az összes processz elvégezte ezeket a lépéseket, könnyen belátható, hogy a kommunikációs alrétegben nem tartózkodik egyetlen üzenet sem.

Természetesen az átvett üzeneteket el kell pufferelni a memóriába, és a memóriában tárolt üzeneteket is figyelembe kell venni egy újabb üzenet fogadásának alkalmával. Ezt pedig a GRAPNEL kommunikációs függvényeinek módosításával lehet elérni.

Lementés/Kilépés

A szinkronizáció után következik a processz állapotterének lementése fájlba, mely az elõfeldolgozó rutin végrehajtásának végeztével automatikusan megtörténik. A checkpoint fájl neve, már az ESKY indításakor paraméterként lett meghatározva. Miután a processz lementése befejezõdött, a checkpoint utófeldolgozó rutin is végrehajtásra kerül. Ebben a processz tájékoztatja a szervert a sikeres lementésrõl, és parancsot vár vissza. A parancs kétféle lehet: futás folytatása vagy kilépés. Ez utóbbi érkezik válaszként migráció esetén, melyet a processz azonnali kilépése követ.

Miután a kilépésrõl a GRAPNEL szerver értesült, a külsõ modultól már korábban megérkezett migrációs kérelemben megjelölt gépen a szerver újra elindítja a felhasználói processzt az ESKY segítségével, melynek paraméterekkel jelzi, hogy visszaállítás szükséges és meghatározza a checkpoint fájlt is.

Újraéledés és kapcsolatfelvétel

Miután az ESKY-vel feléled egy processz, a megadott checkpoint fájl alapján automatikusan visszaállításra kerül a teljes memória tartalom, majd mielõtt a program tovább futna, végrehajtásra kerül az ún. utófeldolgozó függvény. Ez a függvény tartalmazza azokat a módosításokat, mely a processz kapcsolatait építi vissza, újra belép a kommunikációs rétegbe. Ez egyrészt a PVM démonhoz való újrakapcsolódást, másrészt az alkalmazáshoz való csatlakozást jelenti. A PVM démonhoz való csatlakozás némi problémát jelenthet elsõ pillantásra.

Mivel a processz állapotterében rögzítve van a PVM démonnal való kapcsolatát leíró összes paraméter, így egy migrációt követõen a belsõ állapotjelzõk továbbra is a kapcsolat meglétét sugallják (beállított TID és socket azonosító), holott a kapcsolat már nem él. Ahhoz, hogy újrakapcsolódjon a processz az új hoszton lévõ PVM démonhoz, be kell állítani ezen változókat. Ezekhez a hozzáférés azonban nem lehetséges közvetlenül, hiszen a PVM könyvtár belsõ adatszerkezeteiben vannak eltárolva.

Ennek a megoldására használjuk ki azt a lehetõséget, hogy a démonhoz való kapcsolódás elõtt meg lehet adni környezeti változóban a démon socket azonosítóját. Ezt az azonosítót minden esetben a /tmp könyvtárban található PVM fájl tartalmazza, így ennek a beállítása megoldott, azáltal hogy a fájlból kiolvasott érték bekerül a környezeti változóba. A TID érték kinullázása egyszerûen történhet egy elõzetes PVM-bõl való kiléptetéssel. Mindezen lépéseket végrehajtva a processz képes lesz újra felvenni a kapcsolatot a helyi PVM démonnal.

Miután az újraélesztett processz sikeresen felvette a kapcsolatot a PVM-mel, nincs más dolga, mint beilleszkedni az alkalmazásba, azaz a grapnel alkalmazásokra jellemzõ belsõ beállításokat elvégezni. Ezt természetesen az alkalmazás részeként futó grapnel szerver processz tölti fel a felhasználói processzbe. Mivel a szerver processz nem lépett ki a PVM-bõl a felhasználói processz migrációja során, az azonosítója sem változik, így a vele való kapcsolat megmaradt.

A grapnel szerverrel való kapcsolatfelvételt követõen a következõ lépéseket hajtja végre a felhasználói processz, mielõtt futását folytatná:

• azonosítja magát a szerver processz felé

• üríti a többi processz kommunikációs azonosítóját tartalmazó táblázatát

• elvégzi a csoportbeállításokat

• elvégzi a template beállításokat

Eme lépések végeztével a processz értesíti a szervert, hogy a beállítások sikeresen megtörténtek, majd várakozni kezd az indításengedélyezõ üzenetre.

Összefoglalás

A cikkben ismertetett checkpointoló és migráló rendszer a P-GRADE által készített párhuzamos, üzenetváltási paradigmán alapuló GRAPNEL alkalmazások futás közbeni migrációjára képes klaszteren belül. A rendszer egyik legnagyobb elõnye, hogy sem az alkalmazásban, sem az üzenetközvetítõ alrendszerben, sem pedig az operációs rendszerben nem igényel semmilyen változtatást, mely egy egyedülállónak mondható tulajdonság. Jelenlegi erõfeszítéseink a migrációs eszköz terheléskiegyenlítõvel és hibatûréssel való kiegészítését célozzák meg.

Hivatkozások

[1] P-GRADE rendszer honlapja: http://ultra10.lpds.sztaki.hu/projects/p_grade

[2] “Klaszter programozási technológia és alkalmazása a meterológiában” címû IKTA-3

projekt.

http://www.lpds.sztaki.hu/conv.php?page=./projects/current_projects/ikta3/index&pr=1

[3] CoCheck honlapja: chttp://wwwbode.cs.tum.edu/~cocheck

[4] ESKY honlapja: http://cap.anu.edu.au/~dgibson/esky.html

[5] Drótos, D. and Kacsuk, P.: Inner Secrets of GRAPNEL Code Generation, Proc. of the 3^rd

SEIHPC workshop, Madrid, 1998