Nagy feldolgozási képességű számítási környezet a BME-n


Szeberényi Imre <szebi@iit.bme.hu>

BME IIT



Összefoglaló: A számítógép-hálózatok kapacitásának hatalmas ütemű növekedése új lehetőségeket nyitott az elosztott számítási rendszerekben. Az utóbbi években számos olyan fejlesztő környezetet és tervezési technikát fejlesztettek ki, amely az elosztott számítási modellen alapul. A nagy feldolgozó képességű számítási rendszerek az osztott rendszereknek egy fontos részterülete. Ezek a rendszerek viszonylag hosszú ideig futó alkalmazásokat tudnak kiszolgálni az elosztott rendszer erőforrásainak kihasználásával. A cikk összefoglalja a nagy kapacitású elosztott számítási környezetek alapkoncepcióit, és bemutatja a Condor rendszert, amely az egyik legfontosabb ilyen környezet.

Bevezetés

A számítógépek alkalmazása terén gyakran beszélünk teljesítményekről, végrehajtási sebességekről, ezek mérőszámairól, megaflops-okról és megahertz-ekről. Valóságos elvárásaink azonban ettől jóval bonyolultabbak, így azok nehezen sűríthetők egy-egy mérőszámba. Felhasználói szempontból leggyakrabban az adott program válaszideje, tehát a gép teljesítménye a fontos, de a rendszer üzemeltetője szempontjából sokszor fontosabb kérdés a feldolgozási vagy áteresztési képesség és a kihasználtság. Természetesen a teljesítmény és a feldolgozási képesség bizonyos szinten összefüggő fogalmak, de nem azonosak.


Abban az esetben, ha egy alkalmazást több száz vagy több ezer adattal kell újra és újra futtatni, a rendszer teljesítménye mellett igen fontos kérdés a rendszer feldolgozási képessége is. Azaz a fő kérdés nem az alkalmazás egyszeri lefutásának ideje, hanem hogy hány futtatási ciklust tud az adott rendszeren a kutató vagy a mérnök egy adott idő alatt végrehajtani. Ezért meg kell különböztetnünk a nagy teljesítményű (High-Performance Computing) és a nagy feldolgozási képességű (High-Throughput Computing) számítási környezetet. Míg a nagy teljesítményű környezetben rendszerint rövid idejű feladatok futnak, addig a nagy feldolgozási képességű környezetben nem ritkák a hetekig vagy hónapokig futó feladatok. A nagy feldolgozási képességű rendszerekben igen fontos, hogy a rendelkezésre álló erőforrások a lehető legjobban ki legyenek használva, hiszen így tudja a rendszer a legtöbb feladatot végrehajtani.


Mind a számítási teljesítmény, mind a feldolgozási képesség növelésének egyik lehetséges módja a párhuzamosítás, bár a két cél alapvetően más megoldást igényel:


A hálózati technológiák fejlődésével az elosztott, párhuzamos hálózati rendszerek kutatásának egyik fontos részterületévé váltak a nagy feldolgozási képességű rendszerek. E kutatás egyik eredményeként jött létre a Condor [1] rendszer, melyet alapvetően a hálózatba kapcsolt munkaállomások szabad erőforrásainak összegyűjtésére és ezzel egy rugalmas, nagy feldolgozási képességű rendszer kialakítására terveztek.


A Condor rendszer különösen fontos szerepet tölthet be az elosztott, párhuzamos rendszerek fejlődésében, mivel a rendszerben alkalmazott alapelvek, modulok alapját képezik a nagy várakozásokat kiváltó hazai és nemzetközi Grid [2] kutatásoknak is. Tanszékünk a múlt év végén alakított ki egy kísérleti Condor pool-t, mellyel kapcsolatos tapasztalatainkat foglalja össze ez a cikk.

A párhuzamosítás múltja és jelene

A párhuzamos feldolgozás, párhuzamos programok készítésének igénye hosszabb ideje foglalkoztatja a számítástechnikai fejlesztőket. A korai technológiai korlátokból már több mint 30 évvel ezelőtt is arra a következtetésre jutottak a fejlesztők, hogy a számítási teljesítmény növelésének egyetlen reális módja a párhuzamosítás. Ennek hatására több irányban indult kutatás és fejlesztés. Ezek elsősorban a szorosan csatolt rendszerek kifejlesztésére irányultak. Igen nagy teljesítményű, több száz, esetenként több ezer processzort is tartalmazó szuperszámítógépek jöttek létre, igen magas tervezési és előállítási költségek mellett. A 80-as évek végére úgy tűnt, hogy a processzorok összekapcsolása, kommunikációja körüli technológiai nehézségek megszűntek [4], és egyre több gyártó jelent meg párhuzamos architektúrájú számítógéppel a piacon.


Alapvetően kétfajta fejlesztési és megvalósítási irányzat alakult ki:


A párhuzamos architektúrájú gépek fejlesztésével egyidőben a processzoron belüli feldolgozás párhuzamosítása (RISC technológia) terén is jelentős előrelépés történt. Ez utóbbi és a gyártási technológiák fejlődéséből adódó hihetetlen ütemű fejlődés miatt sokan megkérdőjelezték a drága és igen bonyolultan programozható párhuzamos gépek jövőjét. Némileg igazuk lett, mert a várt áttörés a speciális párhuzamos architektúrák terén nem következett be, de számos gyártó gyárt egyszerűbb, busz jellegű kapcsolatokat vagy kapcsolt hálózatot tartalmazó szuperszámítógépeket.


Ugyanakkor az elosztott számítási rendszerek jelentősége és ezzel a párhuzamos feldolgozás jelentősége megnőtt. Ennek fő oka az, hogy az utóbbi években a számítógépek teljesítménye és kapacitása hatalmas ütemben nőtt, az általános célú gépek tömeges gyártása miatt áruk folyamatosan csökkent. A hálózati eszközök és technológiák fejlődésével az általános célú munkaállomásokból, személyi számítógépekből nagy méretű, akár több országot is magába foglaló, igen teljesítőképes elosztott rendszerek hozhatók létre, melyek segítségével egyes alkalmazások a szuperszámítógépek teljesítményének megfelelő vagy azt meghaladó teljesítménnyel futtathatók. Ezen rendszerek létrehozási költsége viszont csak töredéke a szuperszámítógépek költségének.


Az ilyen rendszerek különösen jól alkalmazhatók azokban az esetekben, amikor ugyanazt az alkalmazást kell többször, más-más adathalmazzal futtatni, és az egyes futtatások között nincs adatkapcsolat. Így az egyes futtatások párhuzamosan indíthatók annyi példányban, ahány szabad gépünk van. Természetesen alkalmazási szinten ez nem jelent párhuzamos alkalmazást. Párhuzamos alkalmazásnak csak azokat nevezhetjük, amikor az alkalmazások egy közös cél érdekében dolgoznak párhuzamosan együtt.


Valódi párhuzamos programokhoz is hatékonyan alkalmazhatók a lazán csatolt elosztott rendszerek az ún. master-worker [3] számítási modell felhasználásával. Az ilyen alkalmazások programjai egy közös feladat megoldásán dolgoznak együtt, tehát nem függetlenek, de egymással nem kommunikálnak, csak az ún. master programmal, amely kiosztja a feladatokat, és begyűjti az eredményeket. Természetesen nem minden feladat osztható ilyen módon részfeladatokra, de számos területen (pl. képfeldolgozás, egyes szimulációk, stb.) hatékonyan alkalmazható ez a módszer.

Opportunista környezet (szegény ember vízzel főz)

Láttuk, hogy általános célú munkaállomások hálózaton történő összekapcsolásával viszonylag kis költséggel elosztott rendszert hozhatunk létre, mellyel akár nagy teljesítményű, akár nagy feldolgozási képességű rendszer is kialakítható. Természetesen figyelembe kell vennünk a rendszerek hálózati kapcsolatából adódó korlátokat, de a hálózati technológiák fejlődése miatt ezek jelentősége várhatóan jelentősen csökken.


Elosztott rendszerünk létrehozásának költségei tovább csökkenthetők, ha a már meglevő gépekből hozzuk létre. Ez kézenfekvő megoldás, hiszen vállalati, intézményi szinten igen sok munkaállomással, személyi számítógéppel számolhatunk, melyek kihasználtsága a nap nagy részében igen alacsony. Ezek szabad erőforrásainak felhasználásával jelentős számítási kapacitást lehet összegyűjteni. Ekkor azonban számolnunk kell a következő problémákkal:


A fenti nehézségek ellenére sok berendezéssel meglepően nagy számítási kapacitás biztosítható akár hosszú időn keresztül folyamatosan is. Ezt a felismerést kihasználva kialakítható egy hatékony, alacsony költségű, opportunista, nagy feldolgozási képességű rendszer. Ehhez nem kell mást “tenni”, mint a hálózatba kötött munkaállomások szabad erőforrásait folyamatosan figyelni, és a lehető legoptimálisabban kihasználni azt.


Rendszerint külön gondot okoz az ilyen rendszerekben, hogy az egymáshoz kapcsolt számítógépek eltérő teljesítményűek és eltérő terheltségűek. Ilyen körülmények között kiemelt jelentőségű az egyes gépek közötti terheléselosztás. A feladatok ütemezéséhez, az erőforrások hatékony kihasználásához, a terhelés megfelelő elosztásához megfelelő ütemező algoritmussal ellátott feladatkezelőre van szükség.


A korábban említett master-worker modell alkalmazása a terhelés elosztását is egyszerűsítheti. Ha ugyanis a master a teljes feladatot több darabra vágja, mint ahány worker van a rendszerben, és minden worker képes a feladata befejeztével újabb feladatokat fogadni, akkor a terhelés automatikusan kiegyenlítődik. A gyorsabb gépeken futó worker programok ugyanis munkájuk befejeztével újabb feladatot kapnak, és ezalatt a lassabb vagy jobban terhelt gépek is befejezhetik feladatukat.

A Condor rendszer

A Condor rendszer lényegében egy elosztott, heterogén környezetben alkalmazható feladat-kezelő, amellyel nagy feldolgozási képességű rendszer alakítható ki. A programot eredetileg UNIX és NT munkaállomások szabad számítási kapacitásának összegyűjtésére és hasznosítására tervezték. A program bináris változata akadémiai intézmények számára szabadon letölthető és használható. A rendszer egyaránt alkalmazható heterogén, homogén és cluster környezetben is. Segítségével egyszerűen elérhető, hogy egy adott feladat a hálózatba kapcsolt számítógépek közül mindig azon, az egyébként szabad gépen fusson, amely a leginkább megfelel az alkalmazásnak. Igen fontos tulajdonsága a Condor-nak, hogy a megkezdett, de még be nem fejezett feladatot képes az egyik gépről a másikra átvinni, és ott folytatni. Erre akkor lehet szükség, ha az adott gép valamiért már nem használható tovább, pl. a tulajdonosa akarja azt használni.


A rendszer működésének egyik fontos eleme az ún. ClassAds mechanizmus. Ennek lényege, hogy a szabad erőforrásokkal rendelkező gépek “hirdetik” szabad erőforrásaikat, az erőforrást használni akaró programok pedig bejelentik igényeiket a rendszer megfelelő programjának. Ez a program a megfelelő rangsorolás mellett összeilleszti az igényeket és lehetőségeket. Az igények és lehetőségek találkozásakor az adott igénylő megkapja és használhatja az igényelt erőforrást. Más hasonló feladatú feladatkezelőktől eltérően a Condor az erőforrásokat egységes formában kezeli, így lehetővé válik azok rangsorolása még akkor is, ha fizikai értelemben nem összehasonlítható mennyiségek. Ezen rangsorra tetszőlegesen bonyolult szabály illeszthető, ami meglehetősen nagy rugalmasságot biztosít a konfigurálásban.

A rendszerben ellátott feladat szerint 4 fajta gépről beszélhetünk:

Minden pool-ban csak egy ilyen van, és ennek a feladata a központi adminisztráció. Ezen fut a hirdetéseket és igényeket begyűjtő, valamint azok párosítását végző taszk.

Ezek a gépek képesek feladatokat fogadni és futtatni.

Ezekről a gépekről lehet új feladatot indítani, azaz igényt benyújtani erőforrás iránt.

A már elkezdett, de még be nem fejezett feladatok ideiglenesen ezen tárolódnak, amikor a rendszer valamiért nem tudja kiszolgálni azokat. Nem feltétlenül dedikált gépen van. Ha erre a célra nincs dedikált gép kijelölve, akkor a feladatot indító (submit machine) gépen tárolódik az átmeneti állapot.


A fenti a feladatokat a valóságban nem feltétlenül önálló gépek valósítják meg. Elképzelhető ugyanis, hogy több feladatot is ugyanaz a gép lát el. Így pl. igen gyakori, hogy az a gép, amely feladatot futtat, az egyben új feladatot is tud indítani. Hasonlóan a központi gép lehet, hogy egyben submit machine is.


Az egyes feladatokat az ún. daemon programok látják el, melyek a háttérben futnak. Ezek kapcsolatát és a rendszer felépítését szemlélteti az 1.ábra, amely eredeti magyarázataival a Condor kézikönyvében [1] található meg.


1. ábra: A Condor rendszer felépítése



A Condor rendszerrel potenciálisan futtatható alkalmazásokat különböző csoportokba sorolhatjuk aszerint, hogy hogyan illeszthetők be a rendszerbe.


A fenti esetek kezelésére a Condor ún. univerzumokat vezet be. Az egyes univerzumok más-más szolgáltatásokkal és korlátozásokkal rendelkeznek. Jelenleg a következő univerzumok használhatók:

Ennek használata programok újrafordítását, de legalább az újraszerkesztését igényli. Ennek fejében a rendszer minden szolgáltatása, így a check-pointing is igénybe vehető. Ez azt jelenti, hogy a program futása bizonyos pontokról újra indítható anélkül, hogy azt elölről kellene indítani. Ez igen hosszú futási idejű programok esetén előnyös, valamint ez elengedhetetlen feltétele annak, hogy egy megkezdett feladat egy másik gépen fejeződjön be (migrálás).

Ebben a programok változtatás, újraszerkesztés nélkül futtathatók, de nem lehetséges a migrációjuk. Ez azt jelenti, hogy ha egy gépen elindul a feladat, akkor annak azon kell befejeződnie. A feladat futása természetesen felfüggeszthető, pl. azért, mert a gép tulajdonosa akarja azt használni, de ugyanazon a gépen kell később befejeződnie.

Ez a környezet a PVM (Parallel Virtual Machine) környezethez készített párhuzamos alkalmazások futtatását támogatja.

Ez a környezet az MPI (Message Passing Interface) szabvány szerint készített párhuzamos alkalmazások futtatását támogatja.

Globus fejlesztőkörnyezethez készített univerzum.


Az alkalmazás igényeinek és a lehetőségeknek megfelelő univerzum kiválasztása természetesen a felhasználó dolga. Látható, hogy lényegében az alkalmazások minden fajtájához találunk valamilyen támogatást a rendszerben. A batch vagy script nyelven írt alkalmazások pl. a Vanilla univerzumban futtathatók, de egy forrásnyelven rendelkezésünkre álló master-worker alkalmazás célszerűen a Standard univerzummal tudja kihasználni a rendszer lehetőségeit.


Az alkalmazás erőforrásigénye, paraméterei, be és kimenti állományai, a kívánt univerzum egy igen egyszerű szerkezetű szöveges állományban kerül rögzítésre. Ez az ún. feladatleíró állomány, amely a feladat minden jellemzőjét leírja. Ezen állomány elkészítése után a feladat egyszerűen indítható. Ettől a pillanattól kezdve a Condor rendszer feladata a megfelelő erőforrások kiválasztása, lefoglalása és az alkalmazás futtatása. Egy ilyen feladatleíróban külön megadható, hogy az adott alkalmazás hányszor és milyen paraméterekkel fusson. A feladat befejeződéséről a rendszer elektronikus levelet küld a felhasználónak.

Biztonsági kérdések

A Condor és a hozzá hasonló rendszerek számos biztonsági kérdést felvetnek. Ezek közül a legizgalmasabb, hogy vajon rosszindulatú Condor felhasználó kárt tehet-e a gépek állományaiban, rendszerében. A probléma megoldására alapvetően két megoldást dolgoztak ki a Condor fejlesztői:


Ha feltételezzük, hogy a rendszer védelmi beállításai jók, és biztonsági lyukak nincsenek benne, akkor mindkét megoldás alkalmas az állományok megvédésére. Azonban gondolnunk kell arra is, hogy esetleg egy mindenki által írható katalógust (pl. tmp) tartalmazó diszk feltöltésével is lehetséges károkat vagy fennakadásokat okozni. Ezt megfelelően beállított kvóta rendszerrel lehet kiküszöbölni.


Fontos azonban megjegyezni, hogy a Condor rendszer jelenlegi változatába nem építettek külön védelmi funkciókat, csupán az operációs rendszer saját védelmi funkcióit használja. IP szinten azonban beállítható, hogy az adott pool mely gépektől fogad el feladatokat, és mely pool-okat tekint “barátságos” pool-oknak. Az ilyen “barátságos” pool-ok között a feladatok átadhatók az ún. flock mechanizmussal.

Összefoglalás, tapasztalatok

A bemutatott módszerrel és eszközökkel viszonylag egyszerűen, alacsony költségekkel nagy feldolgozási képességű elosztott rendszert lehet létrehozni, melyben bizonyos alkalmazások, nagy számítási igényű kutatási feladatok hatékonyan megoldhatók.


Az Irányítástechnika és Informatika Tanszéken, valamint az Informatikai Központban 2000-ben kialakítottunk egy-egy kísérleti Condor pool-t. Mindkét rendszer vegyes, NT és UNIX munkaállomásokat és eltérő hardver architektúrájú gépeket is tartalmaz. A rendszer installációja a meglehetősen jó minőségű dokumentáció felhasználásával viszonylag egyszerű, és kézben tartható volt.


Jelenleg a különböző elemi tesztek, konfigurációs lehetőségek vizsgálata folyik. Rövidesen összekapcsoljuk a BME pool-okat a SZTAKI által az IKTA projekt keretében felállított pool-lal. Tapasztalataink, eredményeink alapján a rendszerből jól használható prototípust kívánunk kialakítani, melyen a tanszék elosztott párhuzamos rendszerekhez kapcsolódó oktatási és tudományos feladatait fogjuk megoldani. Tapasztalatainkat fel kívánjuk használni a hazai Grid kutatásokban is.

Köszönetnyilvánítás

A kutatási munkánkat az IKTA 00008/2000 számú projekt támogatásával végeztük.


Irodalom

  1. Condor 6.1.15 Manual,

Condor Team, University of Wisconsin-Madison, 2000

http://www.cs.wisc.edu/condor

  1. I. Foster, C. Kesselman,

The Grid: Blueprint for a new computing infrastructure, Morgan Kaufmann, San Francisco, 1999

  1. I. Foster,

Designing and building parallel programs: Concepts and tool for parallel software engineering, Addison-Wesley, New York, 1995

  1. G.S. Almasi, A. Gottlieb,

Highly parallel computing, Benjamin/Cummings, Redwood City, 1994