Virtuális számítógép architektúra hálózati PC-kre

Juhász Sándor <sanyo@sch.bme.hu>

BME, Automatizálási és Alk. Informatikai Tanszék

Charaf Hassan Phd. <hassan@aut.bme.hu>

BME, Automatizálási és Alk. Informatikai Tanszék

Kivonat

Ahogy egyre jobban megközelítjük a jelen integrált áramköri technológiával történő sebességnövelés határait, egyre komolyabb szerephez jut a teljesítmény növelés másik útja, a több szinten is megjelenő párhuzamosság. Az Internet a számítógépek fizikai összekapcsolásával a különféle adattárolási és feldolgozási műveletek elosztásának minden eddiginél nagyobb mértéke válik lehetővé. Az ilyen irányú kutatások fő célja a GRID, az egész bolygóra kiterjedő igényvezérelt számítógépes feldolgozó architektúra megalkotása. Angolul a grid elvevezés szó szerint az elektromos hálózatot takarja.

A heterogén eszközök számítási kapacitását egyesítő metaszámítási rendszerek a legkülönfélébb programozói megoldásokon alapulnak. Az ilyen rendszereknél azonban számtalan hasonló alapkövetelmény fordul elő (egységes rendszerkép, teljesítmény, hibatűrés stb.), és így az ezekre adott megoldások is közös vonásokat mutatnak. Egyes alapvető rendszerkomponensek (azonosítás, kommunikáció, szinkronizáció, biztonsági rendszer, információs szolgáltatás) minden megoldásban megtalálhatók, csupán az implementáció technikai részleti különböznek. Cikkünkben a tanszék a hasonló témában folyó fejlesztését mutatjuk be, melynek célja egy elosztott, párhuzamos keretrendszer elkészítése. A rendszer az Internet segítségével összekapcsolt PC-k egyesített sokprocesszoros gépként való felhasználását és programozását segíti.

Abstract

As we are approaching more and more to the limit, where the present integrated circuit technology it is not capable to improve the speed of computation any more, the other way of increasing performance, the application of parallelism is becoming more and more dominant. It is present on multiple level, reaching from parts of circuits to even multiplying whole computers. Its most impressive form, the Internet physically connects the computers of the world, allowing the distribution of data storing and data processing on a scale never seen before. The goal of the researches in this field is to create the computational GRID, a demand driven processing architecture extending to the whole planet.

The metacomputing systems based on various programming solutions aim to unite the computational forces of their heterogen components. Such systems also share a number of base requirements like performance, single system image, fault tolerance etc., so solutions addressing these issues also have some common characteristics. Some base components (identification, communication, synchronisation, security system, information service) are common parts of every system, only the implementations differ. Our department also pursuits the development of a parallel, distributed framework, which we would like to present in this article. This system allows to use and to program PC-s connected by the Internet as a single multiprocessor system.

1. A párhuzamosság szintjei a mai informatikában

Ahogy egyre jobban megközelítjük a jelen integrált áramköri technológiával történő sebességnövelés határait, egyre komolyabb szerephez jut a teljesítmény növelés másik útja, a több szinten is megjelenő párhuzamosság. Áramköri szinten már saját asztali számítógépünk processzora is számos párhuzamosítást alkalmaz, így változatos módszerekkel (pipeline, többszörözött feldolgozó egységek) akár egyszerre több utasítás végrehajtására is képes. Nem megy ritkaságszáma a több processzoros számítógépek alkalmazása sem. Innen már csak egy lépés a különféle, akár számos processzort tartalmazó számítógépek összekapcsolása és a világot átfogó számítási hálózat megvalósítása.

Az Internet a számítógépek fizikai összekapcsolásával számos, addig sohasem látott alkalmazás előtt nyitotta meg az utat. Kiváló példa erre az emberek közötti kommunikációt forradalmasító elektronikus levelezés, valamint az elosztott adattárolás és adatprezentáció számos problémáját megoldó World Wide Web. Vannak azonban még lefedetlen területek is, egyelőre nem alakult ki például mindenki által általánosan elfogadott megoldás az elosztott adatbázis-kezelésre vagy az elosztott feldolgozásra sem, bár e területeken számos erőfeszítés történt és történik jelenleg is. Cikkemben én is egy ilyen területet, az elosztott számítások elvégzésének lehetséges eszközeit vizsgálom meg közelebbről.

1. Metaszámítási rendszerek és virtuális számítógépek

Ha már egyszer adott a hálózatba kapcsolt számítógépek sokasága, jó lenne, ha erejüket egyesíteni lehetne a nagy számítási kapacitást igénylő feladatok gyors megoldására. Ez annál inkább kívánatos lenne, mivel a low-end számítógépek fajlagos számítási költsége jóval alacsonyabb. Komoly gondot jelent azonban az ilyen rendszert üzemeltető és használó szoftverek kifejlesztése. A szekvenciális futásra tervezett algoritmusok általában alkalmatlanok a párhuzamos környezetben történő működésre, sőt a kimondottan párhuzamos algoritmusok futtatása is számtalan kommunikációs és szinkronizációs alapfeltételt támaszt.

A kezdeti számos megoldás közül kettő, a heterogén rendszerek összekapcsolását segítő PMV (Parallel Virtual Mashine) [12] és az eredetileg szuper-számítóközpontok összekapcsolására tervezett MPI (Message Passing Interface) [w1] bizonyult a legéletképesebbnek, és később a földrajzilag elosztott számítógépek közötti kommunikáció de facto szabványaival nőtték ki magukat. A két rendszer összehasonlításával számos irodalom foglalkozik [9][13], a mi szempontunkból csupán annyit érdemes róluk megjegyezni, hogy csupán a processzek közötti kommunikáció és szinkronizáció feladatának megoldását tűzik ki maguk elé, a számítás szervezés, adatelosztás, hibakezelés és a biztonsági kérdések kezelése a programozóra hárul.

Ezekre a kommunikációs alrendszerekre, illetve ezek továbbfejlesztett változataira támaszkodva számos alkalmazás született, többféle irányból megközelítve az elosztott feldolgozás problémakörét. Egyesek a számítógépek holt idejének összegyűjtésével igyekeznek kihasználatlan számítási kapacitásokat találni (pl. Condor [11]), mások a részegységekből monolitikus rendszert alakítanak ki, a felhasználók felé egységes nagy teljesítményű rendszer képét mutatva (Harness Parallel Virtual Machine Project. [w3], Local Area Multicomputer/MPI [w11]). Ez utóbbiak közül az egyforma számítógépekből felépülők a klaszterek vagy számítógép farmok, míg a heterogén, különféle teljesítményű és fajtájú gépekből álló, változatokat a metaszámítási rendszereknek nevezzük.

A több elemből felépülő, egységes rendszerképet mutató összetett számítási rendszerek virtuális számítógépnek nevezzük. Az elemek számának növekedésével a rendszerintegritás megőrzése egybe bonyolultabbá válik, előtérbe kerül a hibakezelés (a sok komponens között nagyobb valószínűséggel lesz meghibásodás) megoldása, és megoldást kell találni a decentralizált szervezési és erőforrás kezelési problémákra is. A decentralizált, dinamikusan változó rendszert minden időpillanatban, teljes mértékben már elvileg sem ismerheti egyik komponense sem, így a jóval egyszerűbb központosított megoldások itt nem használhatók. Az ilyen rendszerekre történő szoftverfejlesztés eszközei szintén külön kutatások tárgyát képezik. A fenti nehézségek legyőzése érdekében napjainkban is tevékeny kutatómunka folyik, és vannak már működő tesztrendszerek is (Globus[9][w7], Legion [w2]). A végső célnak az ún. GRID [9][w6] hálózat megalkotását tekintik, melynek lényege, hogy bolygónk számítógépit egyetlen az elektromos hálózathoz hasonlón, igényvezérelt metaszámítási rendszerben egyesítsék, ahol a tetszőleges pontokon beadott feladatokon a rendszer egésze dolgozik, a feladatot adónak csupán az eredményt kell megvárnia, anélkül hogy a megoldás módjával és helyével foglalkozna.

Hasonló célt fogalmaznak meg a komponens alapú programozást támogató rendszerek is, bár ezek az egységes rendszerképet egy kicsit más értelemben használják, mivel nem a maguk a processzek, hanem különféle komponensek egy névtérbe kerüléséről kell gondoskodni. Itt kétféle, bár alapvetően nem eltérő, de természetesen inkompatibilis megoldás látott napvilágot (Microsoft DCOM, és OMG CORBA [10][w9]).

Az elosztott számítási rendszerekben külön irányzatot képviselnek a Java alkalmazások, melyek hordozható bytecode-ban leírt osztályokban kerülnek implementálásra, ami lehetővé teszi a különféle platformok közötti tárgykód szintű kompatibilitást. Így bár a Java kiválóan alkalmas CORBA objektumok megvalósítására [10] is, kínálja magát a lehetőség a hordozható kódú komponensek és ún. mobil agent típusú szoftverek elkészítésére. A Sun JavaSpaces[8] fejlesztése külön támogatást kínál az elosztott algoritmus fejlesztéshez és az elosztott objektumok perzisztencia kezeléséhez is.

1. A Piramis rendszer áttekintése

   1. Elvárások az elosztott rendszerekkel szemben

Ebben a cikkben elsődleges célunk, hogy bemutassunk a metaszámítási rendszerek alapját alkotó különféle megoldások programozói hátterét. Bár, mint az előző pontban láthattuk, sokféle megoldás csoport létezik, de alapvető céljaik és követelményeik megegyeznek: a sok heterogén összetevőből kialakított egységes rendszernek minél nagyobb teljesítménnyel kell rendelkeznie, a dinamikus változásokat és a komponensek hibáit megfelelően kell kezelnie (skálázhatóság, konfigurálhatóság, hibatűrés) és természetesen lehetőséget kell biztosítania a minél egyszerűbb fejlesztésre és a működésének nyomon követésére is. Helyi megoldásoknál is gyakran, de a földrajzi értelemben kiterjedt rendszerekben szinte minden esetben foglalkozni kell a biztonság kérdéskörével is.

A különféle rendszerek természetesen eltérő módon, más prioritással kezelik az egyes követelményeket, abban azonban valamennyi megegyezik, hogy egy meglévő operációs rendszerrel ráépülve, azt egy újabb szolgáltatás réteggel bővíti ki, melyet az elosztott alkalmazások majd alapszolgáltatásokként használnak. A következőkben egy konkrét rendszer megoldásain keresztül mutatjuk meg, hogy hogyan képzelhető el egy ilyen rendszer, és az alapvető működéshez milyen szolgáltatásokra van szüksége. A bemutatandó rendszer a BME Villamosmérnöki és Informatikai Karának Automatizálási és Alkalmazott Informatikai Tanszékén fejlesztett Piramis rendszer lesz. Az elosztott párhuzamos rendszerekben gyakori az “oszd meg és uralkodj” elvének használata, melynek lényege, hogy egy csomópont a neki kiadott feladatot részekre osztva továbbadja, és a kapott eredményeket egyesítve adja vissza a feladatot kezdeményezőnek. A fenti megoldási módszerrel egy egymásra épülő, lefelé egyre bővülő számú elemet tartalmazó kliens-szerver architektúra alakul ki, innen kapta nevét a rendszer.

1. ábra. Adat és feladatáramlás a Piramis rendszerben

Maga a Piramis rendszer azonban nem csupán ennek az architektúrának a megvalósítására képes, hanem tulajdonképpen egy általános célú elosztott kommunikációs és erőforrás kezelő rendszer. A rendszer elkészítésének elsődleges célja az volt, bizonyos elosztott modellezési technikákhoz teszt környezetül szolgáljon, melyben a különféle kommunikációs megoldásokkal és elosztott számítási algoritmusokkal mérések és demonstrációk végezhetők. Ezek a célkitűzések egyben az egyes követelmények súlyozását is meghatározzák: elsődleges itt is a teljesítmény, de emellett a mérésekhez szintén fontos a minél kevesebb adminisztrációs overhead, az áttekinthető, egyszerű kialakítás és jól nyomon követhető egyszerű fejlesztés. Mivel rendszerünket egyetemi környezetben, hagyományos személyi számítógépek felhasználásával szeretnénk kialakítani, melyeket esetleg időnként más célokra is használnak, valamilyen szinten megoldást kell adnunk a rendszerkonfigurálás és a hibatűrés megvalósítására is. Az itt bemutatott rendszer elméletileg jól skálázható, de ennek valódi kipróbálására még nem nyílt igazán lehetőségünk. A rendszer monolitikus, a felhasználó felé egységes képet mutat, de egyszerűsége magában rejti az általunk használt (32 bites Intel processzor alapú) PC-k bizonyos jellemzőinek kihasználását (pl. adatábrázolás, tárgykód kompatibilitás), és így a hetoregenitás eltakarásával sem kell hangsúlyosan foglalkozni. Az egyforma rendszerösszetevők általában a klaszter rendszerekre jellemzők, a Piramis rendszer azonban nem tekinthető homogénnek sem, mivel a rendszerkomponensek processzor típusa, diszk és memória kapacitása igen eltérő lehet, sőt könnyen elképzelhető, hogy a rendszer alatti operációs rendszer réteg is különbözik (32 bites Windows és Linux változatok).

1. Alapszolgáltatások

A fent bemutatott követelmények teljesítéséhez az elosztott rendszereknek, így a Piramis rendszernek is, a számos részfeladatokat kell megoldania, és ezeket alapszolgáltatásként a felette lévő szinteknek biztosítania. A rendszer egészének célja, hogy a komponensei összehangolt működésükkel biztosítsák a kapott feladatok minél hatékonyabb megoldását.

A monolitikus rendszerkép kialakításához elengedhetetlen, hogy a rendszer elemeit (taszkok, fájlok, adatszerkezetek) egyedileg és egyforma módon azonosítani lehessen. Az azonosítás szerepe, hogy az együttműködni kívánó elemek megtalálhassák és megkülönböztethessék egymást kommunikáció vagy információnyerés céljából.

Az együttműködés másik fontos feltétele a kommunikáció és szinkronizálás. A rendszer és a komponensek egymást közötti adatcseréje üzenetkezelésen alapul, melynek lehetőséget kell biztosítani a szükséges szinkronizálási formák megvalósítására is.

A fenti két alapfeladat mellett a rendszerek egy része különféle felsőbb szintű operációs rendszer jellegű funkciókat is megvalósíthat. Ezek közül legfontosabbak az erőforrás kezelés és a biztonsági funkciók. A memória-, fájl- és taszkkezelést (taszkok létrehozása, megszüntetése, ütemezése) általában a helyi operációs rendszer végzi, azonban teljes rendszer szintjén fellépő erőforrás foglalási és kölcsönös kizárási problémák megoldása külön erőfeszítéseket igényel, különösen, ha nem csupán egy helyes megoldás adására, hanem valamilyen optimum elérésére is törekszünk.

A biztonsági rendszer feladata az illetéktelen hozzáférés elleni védelem, a virtuális gépet alkotó gazdagépek normál működésének zavartalan fenntartása és jól működő, hasznos programok megóvása a rossz szándékkal vagy esetleg hibásan megírt társaiktól. Szintén ebben a témakörbe tartozik az adatvédelem, hibakezelés is.

Az elosztott rendszerben nem csupán a hardver erőforrások konfigurálhatóságával kell foglalkozni, hanem fontos szerepet játszik a szoftver komponensek változtathatósága, bővíthetősége is. A szolgáltatás kezelés funkció egy interfész olyan rendszerelemek megvalósításához, melyek futási időben kapcsolódnak be a rendszer működésébe. Ezek képezik majd a különféle feladatok megvalósításához szükséges alkotóelemeket, és így különösen a komponens alapú rendszerekben jutnak jelentős szerephez, de a különféle rendszerek működés közbeni átkonfigurálására is régóta széles körben használják (pl. Novell: network loadable module, Windows: dynamic link library, Unix device kezelés és mount funciók).

A szolgáltatás kezelés megvalósításával magától adódik a lehetőség egyes alap rendszerszolgáltatások hasonló megvalósítására, ilyen lehet a távoli erőforrás kezelés, katalógus és információs szolgáltatások (terheltségi adatok, rendszer komponensek listája), replikációs vagy disztribúciós szolgáltatás stb., melyek a rendszer felállásakor automatikusan épülnek be a szolgáltatások közé.

1. Architektúra elosztott számításokhoz

Ebben a részben a Piramis rendszer bemutatásán keresztül betekintést nyújtunk a fenti feladatok egyfajta gyakorlati megvalósítására. A Piramis rendszer alapja egy multiszámítógép architektúra, melynek végrehajtó egységeit hierarchikus elvű soros buszra (Internet) kapcsolt önálló számítógépek képezik. Mivel a rendszer felépítésében egyik fő alapelvünk a minél nagyobb teljesítmény elérése, a vezérlésben ahol lehet alkalmazzuk a lokalitás elvét, feltételezve, hogy helyben gyorsabban és hatékonyabban tudunk intézkedni, mint egy távoli, szűk keresztmetszetet a rendszerbe iktató központból.

A rendszer felépítésében tetszőleges multitasking operációs rendszert futtató számítógépek részt vehetnek, ha képesek a TCP/IP portok kezelésére, de szükség lehet az Intel PC-s világban megszokott szám és karakterábrázolások konverziójának implementálására. Mivel a helyi erőforrások (processzorok, taszkok, fájlok) kezelését továbbra is a helyi operációs rendszerre bízzuk, nem jelent akadályt a résztvevő számítógépek felépítése, mely lehet egy egyszerű asztali számítógép, vagy akár egy mainframe is.

A Piramis alapvetően rétegszerkezetű virtuális gép, mely a nem helyettesíti az őt felépítő számítógépek operációs rendszerét, hanem annak szolgáltatásait felhasználva felépít egy magasabb szintű, új szoftver réteget, mely az elosztott virtuális gépbe való integrációt szolgálja. Az elosztást vezérlő új réteget nevezzük Piramis Managernek (PM). Bár a vezérlő új réteget képez az operációs rendszer fölött, de a többi alkalmazás számára használata ennek használata nem kötelező, így a helyi alkalmazásoknak továbbra is lehetősége nyílik az operációs rendszerrel való közvetlen kapcsolattartásra. A virtuális gép alkalmazásai természetesen a Piramis Manageren keresztül tartják a kapcsolatot a többi komponenssel, de a helyi alkalmazásokhoz hasonlóan ezek is használhatják az operációs rendszer szolgáltatásait.

2. ábra. A Piramis rendszer egy csomópontja

A fenti szerkezet lehetővé teszi, hogy a Piramis rendszert felépítő egyes számítógépek eredeti funkciójukat megőrizve váljanak a virtuális számítógép részévé. A prioritások megfelelő beállításával megoldató az is, hogy a Piramis rendszer az eredeti működés lelassítása és megzavarása nélkül, a holtidőket kihasználva működjön, hasznosítva így az egyes számítógépekben rejlő működési tartalékokat.

A Piramis rendszer a fenti csomópontok kommunikációs hálózattal összekapcsolt halmazából áll. A PM kettős szerepet tölt be, egyik feladata az adott gépen futó elosztott alkalmazások taszkjainak ütemezése, másik pedig a helyi és a távoli taszkok közötti kommunikációs lehetőség megteremtése. Mivel a helyi taszkok elérése is a PM-en keresztül történik, a taszkok egyformán kommunikálhatnak akár helyi, akár távoli alkalmazásokkal (helyfüggetlenségi átlátszóság), az egyforma módon, a PM-en keresztülmenő hívások a rendszer monitorozását is segítik. A PM a kommunikáció megvalósításához használja az operációs rendszer szolgáltatásait is (hálózat kezelés).

3. ábra. Kommunikáció a Piramis rendszer taszkjai között

1. A komponensek feladatai

Az ábrán látható, hogy a rendszer minden csomópontja a következő fő elemekből épül fel: helyi operációs rendszer, Piramis Manager, és különféle taszkok. A taszkok között találunk különleges rendszerfunkciókat megvalósító szolgáltatásokat is. A rendelkezésre álló komponensek között a feladatok a következőképpen oszlanak meg:

A helyi operációs rendszer látja el az összes alapvető operációs rendszer feladatot (fájl-, eszköz-, taszk-, memória- és egyéb erőforrás kezelés, időzítés, hálózati komunikáció), és annak biztonsági rendszerét felhasználva alakítjuk ki a biztonsági rendszert.

Az elosztás kezelő (Piramis Manager), az operációs rendszer szolgáltatásait kiegészítve kezeli az elosztott alkalmazások üzeneteit és taszkjait (azonosítás, létrehozás, kommunikáció).

A taszkokban valósítjuk meg a magasabb szintű rendszerfeladatokat (távoli fájl kezelés, könyvtár szolgáltatás), valamint a taszkok végzik a szó szoros értelmében vett tényleges felhasználói feladatok elvégzését is.

A fent említett komponensek közül itt csupán a két legfontosabbat, az elosztás kezelőt és a könyvtár szolgáltatást szeretnénk részletesebben bemutatni, de ezeken keresztül jó átfogó képet kaphatunk a rendszer működéséről.

1. Piramis Manager

A Piramis Manager rendszer lényegi részét alkotja. Úgy kell kialakítani, hogy a rendszert alkotó összes számítógépre feltelepítve biztosítsa a részegységek egységes rendszerként való viselkedését. A PM elindításával az adott számítógép önműködően a rendszer részévé válik, és ettől kezdve már minden további feladatot távolról is elvégezhető. A PM indításakor létrehozza a távoli kommunikációs felületét, mely egy TCP porton keresztül kommunikál a külvilággal. Mivel a PM maga is egy az operációs rendszer taszkjai közül, így a helyi taszkok egy megfelelő leírón közvetlenül az operációs rendszer helyi kommunikációs rendszerén keresztül is elérhetik. Az elindításához csupán néhány paraméter szükséges: a PM saját címe és portja, a rendszer munkakönyvtára a helyi fájlrendszerben és az (elsődleges, másodlagos) könyvtár szolgáltatást futtató távoli PM-ek címe (ezek szerepéről a könyvtár szolgáltatás ismertetésénél részletesen beszélünk).

1. Üzenetek kezelés

Mivel a rendszer alapjául az üzenetkezelés szolgál, a PM első és legfontosabb feladata az üzenetek kezelése és továbbítása. A Piramis üzenetek általános célúak, így meglehetősen egyszerű szerkezetűek, csupán egy üzenet típus azonosítóból, és egy szabad felhasználású, kötetlen hosszúságú pufferből állnak. A puffer tartalmának értelmezéséről a típus alapján a céltaszk dönt. Egy üzenet elküldéséhez a taszknak ismernie kell a saját PM-jének egyfajta leíróját, és üzenetküldéskor ennek felhasználásával a saját PM-jének kell továbbítania a más taszkoknak szánt üzenetet, mégpedig a címzett megnevezésével, hiszen maga az üzenet ezt nem tartalmazza (ha a feladó megnevezése fontos a céltaszk számára, akkor az üzenet pufferbe ez is beletehető, de az üzenettovábbításhoz ez nem szükséges). A PM a beérkezett üzenetek címzettje alapján eldönti, hogy a címzett is a hatáskörébe tartozik-e, ha igen akkor az üzenetet beteszi annak üzenetsorába, ha nem, akkor elküldi a céltaszk PM-jének, ami a kézbesítésről majd helyben gondoskodik. A PM-ek egymás közötti kommunikációja TCP/IP socket kezelésen alapul, melyhez felhasználjuk az operációs rendszer által nyújtott támogatást.

Az üzenetkezelés fontos teljesítmény javító tulajdonsága, hogy törekszik az üzenetek felesleges másolgatásának elkerülésére. Az üzenet létrehozása (megfelelő memória terület lefoglalása és kitöltése az üzenet és a puffer számára) a küldő taszk feladata, és üzenetküldéskor ennek csak a címét adja át, a továbbítás és a memória foglalás megszüntetése már a céltaszk feladata. Ha az üzenet távoli, fizikailag más címtérben elhelyezkedő taszknak megy, akkor a küldő PM-je elküldés után a küldő oldalon felszabadítja a tárterületeket, a céltaszk PM-je pedig fogadó oldalon ismét létrehozza az üzenetet a címzett címterében, és így ismét csak a céltasznak kell használat után véglegesen felszabadítani a lefoglalt tárat.

1. Azonosítás

Az üzenet kezelés fontos eleme a taszkok azonosítása. Mivel a taszkok a rendszer többi eleme felé a PM-en keresztül látszanak, az azonosításunk megoldását is itt kell elvégeznünk. A rendszer globálisan egyedi azonosítói (EPID, extended process identifier), két részből épülnek fel, az első rész a PM-et azonosítja (IP cím, és TCP port), a másik pedig a PM alatti egyedi taszkazonosító. Bár az ilyen formájú azonosítók meglehetősen hosszúak, azonban nagy előnyük, hogy a rendszer tetszőleges pontján felhasználhatók mindenféle központi taszkazonosító katalógus használata nélkül, mivel magukban hordozzák az útvonal keresési (routing) információt is. A PM könnyedén eldöntheti, hogy a kapott üzenetet saját taszkjának kell-e továbbítania (alatta fut a taszk, ha az azonosítójában található IP cím és port megegyezik a PM-ével), vagy ha ez egy távoli taszk, hova kell továbbküldenie (az azonosító tartalmazza a céltaszk PM-jének IP címét és portját). Azzal, hogy a PM-et nem kötjük fix porthoz, nem csak más a alkalmazásokkal való ütközések kerülhetők el, hanem lehetővé válik, egy számítógépen egyszerre több PM is futhasson.

1. Biztonsági rendszer

A rendszer alapvetően az operációs rendszer biztonsági szolgáltatásait használja ki. Úgy kell beállítani a PM-et, hogy egy saját usernév alatt fusson, így élhetünk az operációs rendszer által a felhasználók számára biztosított védelmi lehetőségekkel (fájlrendszer hozzáférés korlátozás, diszk, processzor kvóta). A virtuális számítógép taszkjainak egymással szembeni védelmétől alapvetően a taszkok programozói gondoskodnak, a hibás vagy rossz szándékkal megírt alkalmazások az egész rendszer működését negatívan befolyásolhatják. Alapesetben PM és alatta futó taszkok azonos címtérben futnak, de külön-külön szálként párhuzamosan működnek. Az azonos címtér megkönnyíti (és meggyorsítja) a kommunikációt, de a taszkok egymás hibás működésével szemben kevésbé védettek. Az egyes taszkok külön címtérbe helyezésével részben megoldható a probléma. Erre, mint láttuk a lehetőség adott, hiszen gépenként tetszőleges számú PM futtatható, ez azonban csökkenti a teljesítményt, és csak a memória területeket védelméről gondoskodik (pl. a fájlokat nem védi).

1. Szolgáltatások

A Piramis rendszer elosztott végrehajtása szolgáltatások (service) használatára épül. Szolgáltatások lehetnek a Piramis rendszer egyes összetevői (pl. távoli fájl elérés), bizonyos feladatokat megoldó önálló programok, és az egyes programok speciális kihelyezett komponensei is. A szolgáltatások elindítható taszk típusokat jelölnek, melyeket egy egyedi, 32 bites szolgáltatás azonosító (SID) jelöl (pl. SERV_DIRECTORY, SERV_FFT). A 32 bit bitcsoportokra osztható, és így akár hierarchikus elnevezési rendszer is megvalósítható. A szolgáltatások funkciói akkor érhetők el, ha elindítunk belőlük egy (vagy több) példányt, melyek saját taszkazonosítóval (EPID) rendelkeznek, így üzeneteket küldhetünk neki, és fogadhatjuk a válaszokat.

A már futó szolgáltatásokról interfész információt az MSG_INFO típusú üzenet elküldésével nyerhetünk. A futó vagy futtatható (regisztrált) szolgáltatások megtalálását a következő pontban bemutatott könyvtár szolgáltatás segíti.

A nem futó szolgáltatások elindítása egy alkalmas gépen az ottani PM segítségével történik, az alkalmasság eldöntésében szintén a könyvtár szolgáltatás adatai nyújtanak segítséget. A kiszemelt gazdagépre a távoli fájlkezelés szolgáltatás segítségével kell eljuttatni a szolgáltatás kódját valamilyen futásidőben betölthető modul formájában (pl. Window operációs rendszer alatt egy .dll). A PM egy MSG_LOADMODULE üzenet hatására betölti a paraméterben megadott modult, és a benne található inicializáló függvény segítségével regisztrálja a modul szolgáltatásait. A regisztráció lényege, hogy a PM szolgáltatás leíró táblájába bekerül az új szolgáltatás azonosítója és egy függvény címe, mely képes egy példányt legyártani az ilyen típusú szolgáltatásból. A szolgáltatás elindításához a PM-nek egy MSG_START_SERVICE üzenet kell küldeni, az elindítani kívánt szolgáltatás id-jét paraméterként átadva. A regisztráció után a PM felismeri a szolgáltatás azonosítóját, így képes tetszőleges számú ilyen típusú taszk elindítására.

A szolgáltatásoknak lehetőség szerint állapot nélkülinek kell lennie, hogy az egyes kieső komponensek könnyen helyettesíthetők legyenek egymással. Ha ez nem megvalósítható, akkor a szolgáltatásnak olyan perzisztencia kezelés kell megvalósítani, hogy a kieső szolgáltatás más gépen, akár más időpontban is folytatható legyen (állapotmentés egy mindig elérhető távoli fájlba vagy adatbázisba).

Van néhány speciális szolgáltatás, melyet a rendszernek automatikusan támogat, de a felhasználói szolgáltatásokhoz hasonlóan szolgáltatásként épülnek be a rendszerbe. Ilyen a távoli fájlelérés szolgáltatás (file service) és a könyvtár szolgáltatás (directory service) is.

1. Interfészek

A távoli szolgáltatásokat használó alkalmazások és maga a szolgáltatás közötti kommunikáció nemcsak közvetlenül, hanem egy interfész osztályon keresztül is lebonyolítható. Ennek szerepe a távoli eljáráshívások kliens oldali csonkjához (stub) hasonló, azonban nem csupán a függvényhívások elfedését célozza, hanem szerepet játszik a megfelelő azonosítójú távoli szolgáltatás megtalálásában, sőt telepítésében is segíthet. Hiba esetén hasznos lehet, hogyha az állapot a hívó oldali interfészben tárolódik, mert ilyenkor ez megkönnyíti egy másik ilyen típusú szolgáltatásra való automatikus átállást.

Az állapot nélküli távoli szolgáltatásokhoz tetszőleges számú interfész kapcsolódhat a távoli gépekről, illetve az interfész tetszőlegesen megválaszthatja, hogy melyik ugyanolyan típusú (azonos SID) távoli szolgáltatáshoz kapcsolódjon, ezzel a hívó oldal szempontjából egyfajta szolgáltatás migrációval egyenértékű, hiszen menet közben is átlátszó módon át lehet térni egy jobb (gyorsabb, olcsóbb) szolgáltatás igénybevételére.

Az állapottal rendelkező szolgáltatások egy példányához egyetlen távoli interfész tartozhat csak (pl. maga az interfész hozza létre a hozzá tartozó service példányt).

1. Erőforrás kezelés

A PM nem foglalkozik közvetlen erőforrás kezeléssel, hiszen ez az operációs rendszer feladata. A memóriakezelést teljes mértékben az operációs rendszerre bízza, ehhez külön támogatást nem nyújt, de a pointerek közvetlen átadásával kihasználja, hogy az alatta futó taszkokkal közös címtérben van. A fálj- és a taszkkezelést szintén az operációs rendszer végzi, azonban ezeket a funkciókat jelentősen kiterjeszti. A taszkkezelésről a következő pontban részletesebben is említés történik.

A PM ellát bizonyos különleges funkciókat is, ilyen a helyi időzítő szolgáltatás vagy a helyi terheltség mérése. Az előbbi a beállított idő lejártával MSG_TIMEOUT üzenetet küld a taszkoknak, melyet azok különféle várakozások időzítéséhez használhatnak. A terhelésmérés eredménye rendszeresen bekerül a könyvtárszolgáltatás adatai közé is, ez a csomópontok közötti terhelés megosztás szabályozására használható.

A PM másik különleges feladata a monitorozás elősegítése. Mivel a csomópont miden üzenete keresztülmegy rajta, kiválóan alkalmas naplófájl adatok gyűjtésére. A PM biztosít egy konzol felületet is, ahol a felhasználó a belső folyamatokról nyerhet információt.

1. Taszkok

A különféle szolgáltatásokat megtestesítő taszkok egyedi azonosítóval rendelkeznek, és a szolgáltatok bináris kódjából kell őket a már leírt módon létrehozni. Az új típusú taszkok létrehozásához Piramis rendszer biztosít néhány C++ nyelvű header és forrás fájlt melyek a különféle konstansokat, és az alaposztályokat (üzenet, üzenetsor és taszk prototípus) tartalmazzák.

A Piramis rendszer alap építőelemeit a PTask osztályból leszármaztatott taszkok képezik. Minden taszk tartalmazza tagváltozóként a saját azonosítóját (ha választ vár valahonnan, akkor feladóként ezt az azonosítót teszi az üzenetbe), a hozzátartozó PM leíróját, és egy üzenetsort, melybe a neki szánt üzenetek kerülnek. A PTask osztály legfontosabb tagfüggvényei: SendMsg, Start, Run és a ProcessMsg. A PM a taszk elindítását a Start függvény meghívásával végzi. A Start függvény létrehoz egy szálat a PM címterében az operációs rendszer segítségével, úgy hogy annak belépési pontja a taszk Run függvénye legyen. A szál futása Run függvényben zajlik, mely tulajdonképpen egy üzenet feldolgozó ciklus, ha van feldolgozatlan üzenet, akkor azzal meghívja ProcessMsg függvényt, majd felszabadítja a feldolgozott üzenet számára lefoglalt memóriát. Ha nincs üzenet, akkor a szál elalszik és átadja a vezérlés más szálaknak. Ez a ciklus addig ismétlődik, amíg egy MSG_QUIT üzenet nem érkezik a szál üzenetsorába.

Az új taszkok készítése a PTask osztályból való örökléssel történik, elegendő csupán az üzenetkezelő függvényt felüldefiniálni. Ilyen formában csupán az egyes üzenetek típusokat feldolgozó függvényeket kell megírnunk, és a feldolgozás végeztével vissza kell adni a vezérlést. Ha az üzenet alapú vezérlés nem felel meg céljainknak, megtehetjük, hogy a MSG_START üzenet feldolgozásából nem térünk vissza, hanem a szál programját folyamatosan futtatjuk. Ez utóbbi esetben a taszk üzenetsorának feldolgozását szintén külön meg kell oldani. Példaként lássuk egy távoli számláló szolgáltatás megvalósítását (pl. globálisan egyedi azonosítók létrehozására használható):

class PCounterTask : public PTask { // deklaráció

void ProcessMsg(PMsg *msg);

int x;

}

.

:

void PCounterTask :: ProcessMsg( PMsg *msg ) { // implementáció

switch( msg->type ) {

case PMSG_QUIT:

Quit();

break;

case PMSG_START:

x=0; // számláló nullázása

break;

case PMSG_GETX:

x++; // számláló növelése

epid dest;

msg->Open();*msg>>dest; // a lekérdező taszkidjének kiolvasása

PMsg *m=new PMsg(PMSG_RESPONSE); // új üzenet létrehozása

m->Open(4);*m<<x; // x beírása az új üzenetbe

SendMsg(dest,m); // üzenet küldése a feladónak

break;

}

}

1. A könyvtár szolgáltatás

Az elosztott rendszerekben nagyon fontos szerepet játszik a rendszer információs szolgáltatásának kialakítása. A legnagyobb nehézséget az jelenti, hogy a rendszer különféle helyeken elhelyezkedő elemei a percről-percre változó rendszerkonfiguráció mellett is megtalálják egymást (meghibásodások, rendszerbe belépő és rendszert elhagyó számítógépek). Ha a rendszer információit egy folyamatosan frissített központi adatbázisban tároljuk, akkor a rendszerelemeknek elegendő a központi adattár elérését ismerni, és a többi információ már innen megszerezhető. Természetesen az adatfrissítés módjától függően az adott pillanatban a rendszerről az adattár csak közelítőleg pontos képet tárol.

A központosított megoldás egyik hátránya, hogy a rendszer skálázhatósága korlátozott, hiszen a központi elem könnyen szűk keresztmetszetté válhat. A másik gond, hogy a központi elem meghibásodásra érzékeny pont (single point of failure), mivel meghibásodása egy alapvető rendszerfunkció elvesztésével jár.

A Piramis rendszer központi adattárát könyvtár szolgáltatásnak (Directory Service) nevezzük, megvalósítását egy, a többihez hasonló, de speciális SID-del megjelölt taszk végzi. A könyvtár szolgáltatást futtató számítógép természetesen egyenrangú tagja a rendszernek, ezért ezen más szolgáltatások is futtathatók.

A központosítással járó nehézségeket az internetes névszolgáltatásnál (DNS, Domain Name Service) már bevált megoldásokkal kerüljük el. A skálázhatóság eléréséhez a könyvtár szolgáltatást végző taszkokat fa struktúrába rendezzük, és egy taszk csupán a saját környezetének a kiszolgálásáért felelős, de ehhez más könyvtár szolgáltatást végző taszkokat is felhasznál. A hibatűrést a könyvtár szolgáltatás többszörözésével érjük el, az elsődleges és másodlagos szolgáltatások működését később részletesen bemutatjuk.

A könyvtár szolgáltatás működésének lényege, hogy a rendszerbe való belépéshez minden egyes Piramis gépnek ismernie kell a legközelebbi Directory Service címét (ez csak egy IP cím és port, hiszen a SID alapján a taszkazonosító lekérdezhető). Hogy az elsődleges szolgáltatás hibája ne akadályozza a belépést, a másodlagos szolgáltatás címét is rögzítjük, és a belépő az első hibája esetén ehhez fordul. A rendszer felépülésekor minden rendszerbe belépő számítógép feltölti az adatait (4. ábrán A-val jelölve), így a könyvtárba minden rendszerelem bekerül. A könyvtár szolgáltatás normál működése közben minden részvevő számítógép adatait időnként újra bekéri (4. ábrán B-vel jelölve), így állandóan frissen tartja az adatokat, és a meghibásodásokról is tudomást szerez (egy gép nem válaszol).

A teljes redundancia biztosítására a másodlagos könyvtárszolgáltatást végző taszk más gépen fut. Az elsődlegeshez hasonlóan viselkedik, de adatfrissítést nem kezdeményez. Az elsődleges könyvtárszolgáltatás saját tartalmát időnként átküldi neki (4. ábra. C-vel jelölve), és az a beérkező információ hatására egy adott időre továbbra is passzív marad. Ha a frissítés nem érkezik meg a megfelelő időn belül, akkor átveszi az elsődleges könyvtárszolgáltatás helyét, és megkezdi az adatgyűjtést az elsődleges szolgáltató felépüléséig.

4. ábra. Adminisztrációs kommunikáció a Piramis rendszerben

A taszkok a rendszerről információt az adatbázis lekérdezésével szerezhetnek (5. ábra). Már csak egyetlen fontos kérdést kell tisztázni, mégpedig azt, hogy mit is tároljunk az adatbázisban. A sok információ karbantartása többlet nehézséget jelenthet, viszont az információt igénylő taszkoknak könnyebben és pontosabban szolgáltathatunk információt. A taszkok szempontjából legfontosabb, hogy hol és milyen szolgáltatások futnak, illetve ha még nincs ilyen szolgáltatás, vagy nincs meg elegendő számú gépen, akkor mely rendszerkomponensek hajlandók új szolgáltatások befogadására. Ehhez elengedhetetlen a rendszert felépítő gépek címének tárolása (IP cím és port elegendő az adott gép Piramis Managerének azonosításához), és érdemes nyilvántartani azt is, hogy mely szolgáltatások kódja áll rendelkezésre a távoli gépen (futó vagy közvetlenül futtatható szolgáltatások). Az azonos, de különféle gépeken futó szolgáltatások közüli választáshoz és a terhelés megosztáshoz szükség lesz az egyes gépek terhelési információjára is. Ha heterogén rendszerekben gondolkodunk egyéb gépfüggő információkat (processzor típus, memória, diszk méret, hálózati kapcsolat) is fel kell jegyezni, hogy előre tudhassuk, hogy mely szolgáltatások telepítésével érdemes egyáltalán ott próbálkozni.

A Piramis rendszerben a feldolgozás elosztása a feladatot fogadó komponensre hárul. Ennek sikeres elvégzéséhez a könyvtár szolgáltatástól információt kell szereznie a rendszer többi részéről, meg kell tudnia, hogy mely csomópontok állnak készen a feladat fogadására. A 5. ábra első lépésében (A) az eredeti feladatot megkapó PC lekérdezi a könyvtár szolgáltatásból, hogy melyik másik gépek képesek a megadott SID-jű szolgáltatás futtatására (információ már futó szolgáltatásokról, vagy a fogadási készségről). Az információ lekérdezésnek paraméterként tartalmaznia kell, hogy milyen típusú szolgáltatást szeretnénk távolról elérni (SID), hány darab gépen szeretnénk ezt megtenni (egy gépen esetleg több azonos szolgáltatás is futhat), és milyen típusú gépeket szeretnénk a válasz listában látni (különféle szempontok: terhelés, elhelyezkedés a hálózatban, processzor típus, diszk, memória méret). A válaszban visszakapott adatok alapján a kezdeményező PC ettől kezdve már csak a válaszlistában található gépekkel kommunikál, tehermentesítve ezzel a könyvtár szolgáltatást futtató gépet. A visszakapott lehetőség listát érdemes eltárolni, és később, ha valamelyik szolgáltatás kiesne, akkor ebből a service pool-ból pótolhatjuk, nem kell új könyvtár lekérdezést kezdeményezni. Természetesen az alkalmas szolgáltatások listáját időnként érdemes karban tartani.

Az ábrán látható B típusú kommunikációt is az első PC kezdeményezi, ez tartalmazza a távoli szolgáltatás elindítását (szükség esetén telepítését is), és ettől kezdve a szolgáltatás használatát. Itt már nincs szükség a könyvtár szolgáltatás további használatára.

5. ábra. Szolgáltatás használati kommunikáció a Piramis rendszerben

A könyvtár szolgáltatás alkalomszerű (nem folyamatos) használata biztosítja, hogy a rendszer viszonylag sebezhető központi adatárának kiesése se jelentse a rendszer összeomlását. Ha a Directory Service futtató számítógép meghibásodik, akkor a régebben felépített szolgáltatás kapcsolatok gond nélkül futnak tovább, az újak felépítése pedig a másodlagos könyvtár szolgáltatás felhasználásával épülnek fel.

1. Összefoglalás

A bevezetőben láthattuk, hogy sokan és sokféleképpen törekszenek az elosztásban rejlő lehetőségek kihasználására. A számítások elosztására irányuló folyamatos erőfeszítések sok érdekes eredményt hoztak, azonban a feladatok általános és hatékony elosztása máig megoldatlan. Komoly előrelépés történt azonban a különféle programozót és rendszerelemzőt támogató eszközök kifejlesztésében. Ha a feladatot emberi közreműködéssel már sikerült párhuzamos részekre bontani, a párhuzamos részek implementálása és együttműködésük megvalósítása kisebb, statikus rendszerekben nem okoz gondot. A nagyobb, földrajzilag távol eső több ezer, emellett állandóan változó elemből álló rendszer esetén újabb nehézségek vetődnek fel, melyek magát az elosztás tervezést is befolyásolják.

Ebben a cikkben egy lehetséges elosztott rendszer architektúrával foglalkoztunk. Az itt bemutatott Piramis rendszer párhuzamos algoritmusok végrehajtásának modellezésére készült, így maga a keretrendszer fejlesztése is felvetette az ilyen rendszerekben általában előforduló nehézségeket. A rendszer felépítésének bemutatásával a felmerülő problémák ismertetése mellett igyekeztünk a lehető legelegánsabb és leghatékonyabb megoldásokat bemutatni, meg kell azonban jegyezni, hogy a megoldások hatékonysága nagyban függ a követelményektől és ezek között fennálló prioritásoktól. Az itt bemutatott megoldások, az egyetemi környezet sajátossága miatt, az elosztott vezérlést és a központi elemek minél kisebb mértékű, hibatűrő használatát helyezte előtérbe, míg a heterogenitás kezelésével és a biztonsági kérdésekkel keveset foglalkozott.

A fenti tömör ismertető célja az volt, hogy átfogó képet nyújtson a hasonló rendszerek működési elveiről és bennük zajló belső folyamatokról, a rendszer számos, kevésbé fontosnak tartott részletére nem tértünk ki, míg más részek jelenleg is fejlesztés tárgyát képezik.

Irodalomjegyzék

[1] H. Bal. Programming Distributed Systems, Prentice-Hall, London, UK, 1990.

[2] P. Kacsuk, G. Dózsa, F. Fadgyas: Designing parallel Programs Based On Collective Breakpoints, Proc. Of Int Symp. on Software Engineering for Parallel and Distributed Systems, 1999, pp. 83-96

[3] Errol Simon. Distributed Information Systemes, McGraw-Hill, London, UK, 1997.

[4] W. Smith, I. Foster, V. Taylor. Predicting Application Run Times Using Historical Information.

Proc. IPPS/SPDP ’98 Workshop on Job Scheduling Strategies for Parallel Processing, 1998.

[5] A. S. Tanenbaum. Computer Networks 2^nd edition, Prentice-Hall, Englewood Cliffs, NJ, USA, 1988.

[6] A. S. Tanenbaum. Distributed Operating Systems, Prentice-Hall, Englewood Cliffs, NJ, USA, 1995.

[7] W. Gropp, E. Lusk, N. Doss, and A. Skjellum, A high-performance, portable implementation of the MPI message passing interface standard, Technical Report ANL/MCS-TM-213, Mathematics and Computer Science Division, Aragonne Nation Laboratory, Aragonne, Ill., 1996.

[8] JavaSpaces Specification, Sun Microsystems, Inc., 1998

[9] I. Foster, C. Kesselman (editors): The GRID Blueprint for a New Computing Infrastructure, Morgan Kaufmann, 1999,

pp. 259-278

[10] Enterprise JavaBeans to CORBA Mapping, Sun Microsystems, Inc., 1998

[11] M. Litzkov, M. Livny, M.W. Mutka: Condor, a Hunter of Idle Workstation, In. Proc. Eights Int. Conference of Distributed Computing Systems, pp. 104-111, 1998

[12] A. Geist, A. Beguelin, J. Dongarra,W. Jiang, R. Mancher, V.S. Sunderam: Parallel Virtual Mashine – A User’s Guide and Tutorial for Networked Parallel Computing. MTI Press, London, 1994

[13] A. Geist, J. A. Kohl, P.M. Papadopoulos: PVM and MPI: a Comparison of Features, 1996

[w1] I. Foster, Designing and Building Parallel Programs v1.3, Addison-Wesley Inc., Aragonne National Laboratory

http://www-unix.mcs.anl.gov/dbpp/

[w2] A. Grimshaw, W. Wulf, J. French, A. Weaver, and P. Reynolds, Jr., Legion: The next logical step toward a nationwide virtual computer, tech. rep. CS-94-21, Department of Computer Science, University of Virginia, 1994.

http://legion.virginia.edu/

[w3] Harness Parallel Virtual Machine Project.

http://www.csm.oml.gov/harness/

[w4] http://www.isima.fr/limos/netopt/coursBruno/OD/poly/ODPoly.htm

[w5] http://www.scit.wlv.ac.uk/disbook/

[w6] P. Kacsuk, F. Vajda: Network based distributed computing (Meatcomputing), MTA SZTAKI, ERCI, 1999

http://www.sztaki.hu

[w7] The Globus Project.

http://www.globus.org/

[w8] Metacomputing Links

http://www.sis.port.ac.uk/~mab/Metacomputing

[w9] Overview of CORBA

http://www.cs.wustl.edu/~schmidt/corba-overview.htm

[w10] Parallel Computing Projects

http://www.hlrs.de/structure/organisation/par/projects

[w11] Local Area Multicomputer / MPI Parallel Computing

http://www.mpi.nd.edu/lam