Hálózat diagnosztizálás multi-ágens rendszer segítségével

EÖTVÖS LORÁND TUDOMÁNYEGYETEM INFORMATIKAI KAR

Hálózat diagnosztizálás multi-ágens rendszer segítségével Készítette: Terray Tamás Témavezető: Gulyás László

Budapest, 2004

Hálózat diagnosztizálás multi-ágens rendszer segítségével

Irodalomjegyzék

Tartalomjegyzék 0.1Ágensek.......................................................................................................................................8 0.1.1Az ágens alapú programozás története................................................................................................8 0.1.2Ágens definíció...................................................................................................................................9 0.1.3Ágensek belső struktúrája.................................................................................................................11 0.1.4Ágens típusok....................................................................................................................................12 0.1.5Ágens környezetek jellemző tulajdonságai.......................................................................................16

0.2Multi-ágens rendszerek.............................................................................................................17 0.2.1Multi-ágens rendszerek története......................................................................................................18 0.2.2Multi-ágens rendszer definíciója.......................................................................................................19 0.2.3MAS felhasználási területek..............................................................................................................20 0.2.4Multi-ágens rendszerek típusai.........................................................................................................20 0.2.5Multi-ágens alkalmazások tervezése.................................................................................................20

0.3Hagyományos hálózatdiagnosztikai eszköz .............................................................................26 0.3.1Ismertető............................................................................................................................................26 0.3.2Elérhetetlenné vált vagy nem működő hosztok figyelése ................................................................27 0.3.3Hálózati kimaradások diagnosztizálása.............................................................................................29 0.3.4Figyelmeztetések...............................................................................................................................30 0.3.5Szolgáltatásellenőrzési szenzorok.....................................................................................................30 0.3.6Szolgáltatás-ellenőrzés időzítése.......................................................................................................31 0.3.7Állapotok és állapot-jellemzők.................................................... ..................................................... 31 0.3.8Eseménykezelők ...............................................................................................................................32 0.3.9Passzív szolgáltatás-ellenőrzés..........................................................................................................33 0.3.10Hoszt vagy szolgáltatás lebegő állapotban......................................................................................34 0.3.11Teljesítménymérések ......................................................................................................................35 0.3.12Időzített leállások............................................................................................................................35 0.3.13Összefoglalás..................................................................................................................................36

0.4Osztott rendszerű hálózatdiagnosztizálás.................................................................................36 0.4.1Indirekt hoszt és szolgáltatás ellenőrzés...........................................................................................37 0.4.2Szolgáltatás ellenőrzés párhuzamosítása...........................................................................................37 0.4.3Osztott monitorozás..........................................................................................................................38 0.4.4Redundáns, hibatűrő monitorozás.....................................................................................................39 0.4.5Összefoglalás....................................................................................................................................41

0.5Bevezetés...................................................................................................................................42 0.6Célok.........................................................................................................................................42 0.7Környezet .................................................................................................................................43 0.8Az ágens ...................................................................................................................................44 0.8.1Felépítés............................................................................................................................................45 0.8.2Tanulás..............................................................................................................................................48 0.8.3Az ágens tudása.................................................................................................................................49 0.8.4Kommunikáció..................................................................................................................................50

0.9A multi-ágens rendszer.............................................................................................................51 0.9.1Feladatok kiosztása...........................................................................................................................51 0.9.2Hierarchia..........................................................................................................................................53

0.10Kommunikáció........................................................................................................................ 56 0.10.1Információ szűk körben, párbeszéd ...............................................................................................57 0.10.2Információ széles körnek, magas prioritású információk...............................................................57 0.10.3Információ mindenkinek ................................................................................................................58

0.11Hálózat-diagnosztizálás...........................................................................................................59 0.11.1Hosztok, szolgáltatások figyelése...................................................................................................59 0.11.2Hálózati kimaradások diagnosztizálása...........................................................................................61 0.11.3Ágens leállása.................................................................................................................................62

2


Irodalomjegyzék

0.11.4Új ágens indítása.............................................................................................................................62

0.12Összefoglalás...........................................................................................................................63 0.13Sérülékenység ........................................................................................................................65 0.14Egyenetlen terhelés ................................................................................................................66 0.15Konfigurálhatóság...................................................................................................................67 0.16Összetett megfigyelések..........................................................................................................67

3


Irodalomjegyzék

Témabejelentő

EÖTVÖS LORÁND TUDOMÁNYEGYETEM INFORMATIKAI KAR

Név: Terray Tamás tagozat: nappali szak: programtervező matematikus Témavezető neve: Gulyás László munkahelyének neve és címe: MTA SZTAKI, Budapest 1111, Kende u. 11-13. beosztása és iskolai végzettsége: tudományos munkatárs, programtervező matematikus A dolgozat címe: Hálózat diagnosztizálás multi-ágens rendszer segítségével A dolgozat témája: A hálózatok számának, és jelentőségük növekedésével párhuzamosan növekszik azoknak a programoknak a száma, melyek a hálózatok működéséről szolgáltatnak folyamatosan információkat. Ezek a rendszerek általában a hagyományos programírás eszközeivel és szemléletével készülnek, ennek megfelelően központosított vezérlésűek. A modern rendszerekben már megosztják a feladatokat a hálózat több gépe között, de jellemzően egy központi program végzi az összetett feladatokat, a rendszer többi része csak megfigyeléseket végez és továbbítja azokat. A központosított tervezésből adódó sérülékenységet még kevés rendszer védi ki hatékonyan. Ezt a problémát lehet hatékonyan kezelni olyan Multi-ágens Rendszerekkel, melyekben a feladatot önálló egységek végzik, melyek a hálózat különböző pontjain helyezkednek el, és egymással kommunikálva gyűjtik össze a hálózat aktuális állapotát leíró információkat. Egy ilyen felépítésű rendszerben a hibatűrés magasabb fokon valósítható meg, hiszen nincs olyan rész, melynek kiesésével az egész rendszer összeomlana. Természetesen ez a rendszer is veszít információt, ha részei sérülnek, de a rendszer mindig a körülményekhez viszonyított maximumot nyújthatja. Ez a struktúra lehetőséget ad az ágenseknek, hogy a megszerzett információk segítségével fejlődjenek, és hogy önmagukat rekonfigurálják a többi ágens információi alapján. A diplomamunka célja megvizsgálni, hogy egy egyszerű következtetések meghozatalára is alkalmas ágensekből álló csoport hatékonyabban tud-e megfigyelni egy teszt hálózatot egy központosított rendszerhez képest, és ki tudja-e használni a feladatmegosztásból származó előnyöket. Fontos kérdés, hogy elkerülhető-e az, hogy a feladatok megosztása miatt megnövekvő kommunikáció leterhelje a hálózatot.

4


Irodalomjegyzék

Előszó A kereskedelmi hálózat-diagnosztikai rendszerek rendelkeznek olyan tulajdonságokkal, melyek skálázhatóságukat, konfigurálhatóságukat és hatékonyságukat korlátozzák. A problémák jó része arra vezethető vissza, hogy a rendszerek monolitikus felépítésűek, a feladatok nagy részét egy központi entitás végzi. A dolgozatban megtervezem a MAHD rendszert, mely multi-ágens alapú, és képes kiküszöbölni a központosított rendszerek problémáinak nagy részét. Ez az önálló egységekből álló rendszer rendelkezik azzal a rugalmassággal melyet központosított rendszerrel nem lehet elérni. Emellett több nézőpontból képes megfigyeléseket végezni, mely magasabb szintre emeli az összegyűjtött információk minőségét. A dolgozatban először részletesen bemutatom a rendszer és a feladat ismertetéséhez szükséges fogalmakat. Az ismeretekre építkezve ezek után készítek egy tervet, mely specifikálja az együttműködő egységeket - az ágenseket - majd felépítem belőlük a komplex multi-ágens rendszert, a MAHD-ot. A specifikációban kitérek az ágensek közti kommunikációra, a köztük lévő hierarchiára és a feladatok elosztásának módszerére is. A tervezett rendszer ismertetése után annak, és a hagyományos rendszereknek példákon keresztül való összehasonlítása következik.

5


Irodalomjegyzék

Bevezetés A dolgozat a számítógépes hálózatok szolgáltatásainak újszerű diagnosztizálásáról szól. A bejelentőben foglaltaknak megfelelően megkísérlem értékelni, hogy a multi-ágens rendszerek használata egy ilyen feladat megoldása során milyen előnyökkel és hátrányokkal járhat. A hálózatok jelentőségének robbanásszerű növekedésével párhuzamosan átalakultak a számítógép-felhasználási szokások, a kliens-szerver modell használata általánossá vált, és még hangsúlyosabbá vált a csoportos munkavégzés. A hálózatok hibátlan működése már nem csak a csoportos munkához nélkülözhetetlen, hanem az egyén munkavégzéséhez is, például már nem csak az internetezéshez van szükségünk hálózatra, de legtöbbször a nyomtatáshoz is. Természetes követelmény, hogy a hálózatok folyamatosan és megbízhatóan működjenek. A nagy méretű hálózatoknál ez komoly emberi munkát igényel. A munka nagyobb részének automatizálása nem csak csökkenti a munkaórák számát, de gyorsíthatja is a hibák felfedezésének, és javításának folyamatát. A hálózatok diagnosztizálására használt szoftverrendszerek fejlesztése jelenleg a párhuzamosításra és a hibák automatikus felderítésére koncentrál. A hagyományos rendszerek központosított felépítésén a fejlesztők változtatnak, a feladatokat szétosztják több erőforrásra. A párhuzamosítás szükségessége a rendszerek robusztus és rugalmas tulajdonságait igyekszik növelni, melyek egy központosított szoftverben a rendszer felépítéséből adódóan korlátozottak. A feladatok elosztásával csökkenthető a központi megfigyelő terheltsége, hiszen tőle a feladatok egy része átadható párhuzamos feldolgozásra. A párhuzamosítás nem vonatkozik a rendszerek minden folyamatára, az irányítás a továbbiakban is a központi megfigyelő rendszer feladata, mely kiosztja a speciális feladatokat segítőire, majd értékeli az eredményeket. A dolgozat célja, hogy bemutasson egy rendszert, melyben a feladatok párhuzamosítása alapvető tulajdonság, nem a központosított rendszer kiegészítése. A tervezett rendszer multi-ágens felépítésű. Az ilyen rendszerek olyan önállóan működő szoftverekből állnak, melyek közösen oldják meg feladataikat. A rendszer önállósága, tanulási képessége és rugalmassága nem csak a különálló szoftverágensek tulajdonságainak, hanem azok kapcsolatainak és együttes működésének köszönhetőek. A dolgozat alapvető ötlete, hogy egy ilyen önálló entitásokból álló együttműködő csoport hatékonyabban képes ellátni diagnosztikai feladatokat egy hálózaton, mint egy alapvetően központosított rendszer. Ennek oka, hogy az önállóbb ágensek képesek a feladatok rugalmasabb szétosztására, ami a rendszer normális működése esetén ’csak’ a központ szűk keresztmetszet tulajdonságát szünteti meg, esetleges hibák vagy támadások esetén viszont a rendszer működőképességét is garantálhatja. Az osztott rendszer további előnye, hogy több megfigyelő esetén összetett megfigyelések készíthetőek, melyek több ágens közös munkájának az eredményei. A dolgozat először ismereti a szükséges alapfogalmakat, és a jelenlegi rendszerek tulajdonságait, majd bemutat egy multi-ágens architektúrát a hálózat-diagnosztikai feladatok ellátására. A dolgozat négy alapvető részből áll, melyek témái: • •

Az ágensekkel és multi-ágens rendszerekkel kapcsolatos alapvető ismeretek. A jelenleg elterjedt hálózatdiagnosztikai módszerek. A módszereket egy elterjedt szoftverrendszer ismertetésén keresztül mutatjuk be. 6


• •

Irodalomjegyzék

A multi-ágens rendszerű hálózatdiagnosztizáló rendszer ismertetése. Az ismertetett rendszerek összehasonlítása, értékelés.

A dolgozatot lezáró összefoglalás bemutatja a tervezés eredményeit, és a továbbfejlesztés lehetséges irányait.

7


Irodalomjegyzék

Ágensek és Multi-ágens rendszerek Ebben a pontban az ágensekkel kapcsolatos alapvető fogalmak találhatóak. A fejezet elején az ágensek informális és formális definíciója, az ágensek jellemzői kerülnek bevezetésre. A fejezet további részei ismertetik az ágensek jellemző felépítéseit, és a környezetek alapvető tulajdonságait, melyek befolyásolják tervezésüket.

0.1 Ágensek Mi is az ágens köznyelven megfogalmazva? Általános elvárásunk egy ágenssel kapcsolatban, hogy valamiféle intelligenciát mutasson fel. A szoftver ágensek egy informális definíciója: „Az ágens egy olyan szoftver-alkalmazás, ami meg tud csinálni valamit, amire valószínűleg mi is képesek lennénk, ha lenne rá elég időnk” 0.16. Az ágens alapú megközelítés számtalan helyen konkrét gazdasági és felépítésbeli előnyökkel jár a hagyományos megközelítéshez képest. Ha egy űrrepülő útját kell figyelemmel kísérni, akkor a hagyományos eljárás szerint sok ember folytonos munkájával kell a műszereket ellenőrizni, hogy minden rendben zajlik-e. Egy ilyen automatizálható folyamatot érdemes szoftver ágensekre bízni, melyek alacsonyabb költséggel és jobb reflexekkel végzik a monoton munkát. Az internet megjelenésével a hatalmas információmennyiség feldolgozásánál kaptak kiemelt szerepet a szoftver ágensek. A kézenfekvő felhasználási területek mellett mára az ipar és szórakozás számtalan területén találkozhatunk ágensekkel. Néhány példa az ágensek felhasználására: • Sakk programok • Csillagászati esemény megfigyelés és válogatás. A megfigyelendő objektumok nagy száma miatt előszeretettel alkalmaznak ágenseket, melyek jelentik a különleges eseményeket. • Járművek számítógépes irányítása. A kísérleti autók vezetését szoftverágensekre bízzák, melyek az autó szenzorai, műholdas rendszer és kamerák segítségével tájékozódnak. • Elektronikus játék botok. A számítógépes játékok jelenlegi generációjában egyre emberibben viselkedő szoftverekkel vetélkedhetünk. • A Gyűrűk ura c. film csatajeleneteiben ’statisztáló’ szoftver ágensek. A sok statiszta alkalmazása helyett gyakran alkalmaznak szoftver rendszereket. A csatajelent ágensei képesek harcolni egymással, a csata kimenetelét a gondos konfigurálás határozza meg. • Internetes kereső robotok. Ezek a szoftverek folyamatosan frissítik a kereső alkalmazások adatbázisát, több milliárd oldalt elemezve. Ebben a fejezetben az ágensekkel kapcsolatos alapvető ismeretek találhatóak. A leírtak elsősorban az alábbi szakirodalomra alapulnak: H. Van Dyke Parunak,0.16; Stuart J. Russel-Peter Norvig,0.16; Futó Iván,0.16 0.1.1 Az ágens alapú programozás története Az ágens alapú programozás alapötlete a programozási technikák fejlődési trendjében vizsgálva logikus továbblépésnek tűnik. A strukturált programozástól az objektum alapú 8


Irodalomjegyzék

programozáshoz az egységbe zárás magasabb fokú megvalósításával jutunk. Az objektumok egységként működve elfedik előlünk belső működésüket. A következő lépés, hogy a programok kezdeményezőkészségét is beágyazzuk az objektumokba, melyeket így önállósággal látunk el. Ha a programozói – jó értelemben vett – lustaság folyományaként tekintünk erre a fejlődésre, akkor a következőt látjuk: elsőként a mérnök csak el akarta végeztetni algoritmizált feladatait automatikusan, így monolitikus programokat készített. Később ráébredt, hogy érdemes lenne saját programjainak legalább egy részét újra felhasználni, ha máshol nem, legalább egyazon projekten belül és létrehozta a strukturált programokat. Ezután logikusnak tűnt más programozók fejlesztéseihez is kényelmesen hozzáférni, és megszületett az objektum-orientált programozás. Ennél már csak egy dolog tűnt kényelmesebbnek: ha a jól definiált, külön fejleszthető egységek maguktól is képesek cselekvés kezdeményezésére, és az önállóság beágyazásával megszületett az ágens alapú programozás. H. Van Dyke Parunak nyomán:

Monolitikus program

Strukturált program Lokális

Objektumorientált program Lokális

Ágensorientált program Lokális

Mit csinál? (kód)

Külső

Mivel? (állapot)

Külső

Külső

Lokális

Lokális

Mikor fut?

Külső

Külső (meg Külső (üzenet) Lokális (célok, kell hívni) szabályok)

1. táblázat A programozási technikák és az ágens alapú programozás összehasonítása 0.1.2 Ágens definíció Nincsen általánosan elfogadott ágensdefiníció, de megközelítésképpen vannak tulajdonságok, melyeket elvárunk egy entitástól ahhoz, hogy ágensnek nevezzük. Az ágens érzékelői segítségével érzékeli a környezetét, és beavatkozó szerveivel megváltoztatja (0.1.2) azt. Az ember, mint ágens érzékeli környezetét, és ha úgy alakul, akkor testrészei segítségével változtat azokon. A közlekedési lámpa ágens érzékeli nyomásmérőivel vagy kameráival a forgalmat, mint környezetet, majd fényeivel változtat rajta. Az ágensek gyenge definíciója 0.16: Az ágens egy olyan rendszer (informatikai esetben hardver- vagy szoftver alapú), amely a következő tulajdonságokkal rendelkezik: • Beágyazott

9


Irodalomjegyzék

Az ágensek a környezetükbe ágyazottak, abból kiemelve nem tudnak funkcionálni. • Reaktivitás Az ágensek érzékelik a környezetüket, valamint valós időben reagálnak arra. • Autonómia Az ágensek önállóan, direkt beavatkozás nélkül működnek. • Helyzetfüggőség Az ágensek helyzethez és szerephez kötötten ágensek csupán.

1. ábraÁgens és környezete Egy ágensre vonatkozhatnak további kiegészítő tulajdonságok: • Kezdeményezőkészség (proaktivitás) Amikor egy ágens nem csak reagál az eseményekre, hanem szükség esetén kezdeményez is. • Célvezérelt viselkedés Amikor az ágensnek céljai vannak, melyeket igyekszik teljesíteni. • Temporális kontinuitás Az ágens huzamosabb ideig létezik, működik. Megoszlanak a vélemények egyelőre a következő kérdésekben: • Milyen mértékűnek kell lennie a különböző tulajdonságoknak? • Kell-e rendelkeznie az ágensnek explicit célreprezentációval? • Kell-e egyéb tulajdonságokkal rendelkeznie az ágensnek? A dolgozatban ágensnek nevezem azokat az entitásokat, melyek megfelelnek az ágensek gyenge definíciójának. A racionális ágens

A fenti definícióból látható, hogy ágensnek nevezhetünk igen sok mindent, melyek közül bizonyos típusúak érdekesebbek számunkra a többieknél. Az ágensek nagy osztályából kiemelten foglalkozunk a racionális ágensekkel. Racionálisnak nevezünk egy ágenst, ha a lehetőségekhez képest sikeresen cselekszik, ezt a tulajdonságot pontosítjuk a továbbiakban. A sikeres cselekvés méréséhez szükségünk van valamilyen mérhető tulajdonságra, melyet általában teljesítménymértéknek nevezünk. Természetesen nincs általánosan használható

10


Irodalomjegyzék

teljesítménymérték, az függ az ágens környezetétől, és attól a feladattól, melyet az ágens – aktuálisan – végez. Az emberi ágensek esetében teljesítménymérték lehet sakkozóként az élő-pontok száma, brókerként a megszerzett pénz mennyisége, vagy eminensként a megszerzett diplomák száma és azok minősége. Egy egyszerű takarítógép esetében könnyen kitűzhető mérték a feltakarított kosz mennyisége. Sok esetben könnyen félrevezetővé válhat a választott mérték által mért teljesítmény. A rosszul megválasztott mérték meggyőző példája lehet a takarítógép esetén az említett koszmennyiség mérése, hiszen a szemetest felborító majd a benne lévő koszt feltakarító ágenst sikeresebbé teszi a ’normálisan’ működőnél. A racionális ágensekkel kapcsolatban felmerülő igény, hogy helyes működésük minél nagyobb körre, esetleg az esetek teljes körére kiterjedjen. Ehhez természetesen a környezet minden, az ágens döntéseihez fontos információját ismerni kell. Ezt a követelményt, melyre gyakran mindentudásként hivatkozunk, a gyakorlatban igen nehéz, sőt sokszor lehetetlen kielégíteni. Ennek oka az, hogy az ágens által, érzékszervei segítségével gyűjtött információ a megszerezhető mennyiségnek csupán töredéke. Így a racionális ágenstől ’csak’ annyit várunk el, hogy az általa ismert környezet tényeinek ismeretében megközelítse az elvárt sikerességet. Összegezve tehát egy ágens racionális viselkedése az alábbiaktól függ: 1. A sikerességet mérő teljesítménymérték. 2. Megfigyelései (melyeket észlelési sorozatnak nevezünk). 3. Környezetéről való tudása. 4. Az általa végrehajtható cselekvések. Az ideális racionális ágens

Az ideális racionális ágens minden egyes észlelési sorozathoz megtesz mindent a teljesítmény mérték maximalizálásáért. Ezt beépített tudása és az észlelési sorozatban lévő információk alapján teszi. Az, hogy az ágens megtesz mindent, nem csak cselekedeteire vonatkozik, hanem arra is, hogy igyekszik minden hasznos információ észlelésére. Az ideális ágenssel kapcsolatos elvárások a gyakorlatban ritkán valósíthatóak meg, hiszen nincs mindig lehetőség (idő, erőforrás) arra, hogy az összes szükséges megfigyelést végrehajtsuk, és azokból a legjobb cselekvést meghatározzuk. Az autonóm ágens

Egy ágenst olyan mértékben nevezünk autonómnak, amennyire cselekvései az általa szerzett tapasztalatokra épülnek. Ez a definíció kissé eltér a köznyelv által használttól, nem az entitás önállóságára, hanem a környezethez való alkalmazkodás képességére koncentrál. Az autonómia ilyen definiálása arra mutat rá, hogy egy tapasztalataira jobban építő ágens életképesebb egy pusztán belső tudására építő ágensnél, hiszen könnyebben alkalmazkodik a változó körülményekhez. A beépített tudásra és a tapasztalatokra épülő cselekvés közti különbség az állatvilágban is jól nyomon követhető, ahol az állatoknál megfigyelhetőek örökölt viselkedési minták, és tanulással elsajátítottak. 0.1.3 Ágensek belső struktúrája Az ágensek viselkedésének vizsgálata után vizsgáljuk meg azok belső felépítését! A szoftver ágensről elmondhatjuk, hogy egy hardver architektúrán futó program. A program feladata, hogy az észlelési sorozatokhoz cselekvési sorozatot rendelő függvényt valósítson 11


Irodalomjegyzék

meg. Egy szoftver-ágens életciklusa

A fentiek ismeretében felvázolhatjuk, hogy egy szoftver ágens működése milyen lépésekből áll. Az ágens az alábbi lépéseket ismétli futása közben: • érzékelés, érzékelési adatok frissítése • cselekvés kiválasztása, cselekvés végrehajtása • cselekvés hatásainak észlelése, rögzítése A későbbiekben megismert ágensek mindegyike ehhez hasonló alapon működik, függetlenül a felépítésük összetettségétől. 0.1.4 Ágens típusok Egy egyszerű ágens: a leképezési tábla

Az ágens definíció ismeretében adódik az ötlet az ágensek megvalósítására, hogy az észlelési sorozathoz rendeljünk rögzített cselekvéseket. Ezzel akár ideális ágenst is létrehozhatunk, hiszen minden egyes észlelési sorozathoz előre kiszámíthatjuk az ideális cselekvést. Látható viszont, hogy egy ilyen ágens csak nagyon kisszámú észlelési sorozatot tud kezelni, így nem alkalmas összetett feladatok ellátására. A gyakorlati feladatok legtöbbjében - mint például a fent már említett sakkozás esetében – ez a fix táblázatra épülő statikus modell nem képes működésre, vagy működése nem hatékony. Reflex-szerű ágens

A leképezési táblával működő ágensek egyszerű továbbgondolásával juthatunk ehhez a típushoz. Ebben a struktúrában a leképezési tábla hasonló tulajdonságokkal bíró elemeit csoportosítjuk. Nem az egész aktuálisan megfigyelt észlelési sorozatra koncentrál az ágens, csak feltételek létezését vizsgálja. Ha egy általa ismert feltétel teljesül, amihez tartozik cselekvési szabálya, akkor az illető szabályt egyszerűen végrehajtja. Ez az ágenstípus is rendkívül egyszerűen implementálható, de általában nem képes rugalmas alkalmazkodásra.

12


Irodalomjegyzék

2. ábraReflexszerű ágens felépítése 0.16 A leképezési-táblával működő ágenssel összehasonlítva a különbség az, hogy abban az állapottér minden elemére szabályokat kell meghatároznunk, itt viszont az állapottér elemeiből képezett halmazokhoz – a feltételeket kielégítő csoportokhoz – alkotunk szabályokat. Az ágens az alábbi lépéseket hajtja végre (0.1.4) • Észlelés, észlelési adatok frissítése. • Szabályillesztés. • Cselekvés végrehajtása a megtalált szabályokkal. Belső állapottal rendelkező ágens

Az eddigiekben ismertetett ágensek közvetlenül az észleléssel kapott adatok alapján hozták meg döntéseiket cselekvéseikről. Ennek hátránya, hogy sok olyan információ van a környezetekben, ami az ágensek észlelési sorozatába nem kerül be, viszont lényeges a cselekvések kiválasztása szempontjából. Ezeknek az információknak egy része kezelhetővé válik, ha az ágens a környezet egy belső leírását kezeli magában, és azt képes frissíteni olyan szabályok alapján melyek a nem észlelt események kikövetkeztetésére alkalmasak. Ilyen információ lehet az ágens saját cselekedeteinek következménye, vagy egy előző észlelés alapján hozott következtetés. Például egy forgalomirányító ágens esetén kikövetkeztetett információ lehet az, amit egy autó előzetes helyzetéből és sebességéből számol a rendszer, akkor is, ha az autó kikerül a szenzorok látóköréből.

13


Irodalomjegyzék

3. ábraBelső állapottal rendelkező ágens felépítése 0.16 Az ágens lépései (0.1.4) • Belső állapot frissítése az észlelések alapján. • Szabály illesztés a belső állapot alapján. • Cselekvés a szabály illesztés alapján. • Belső állapot frissítése a cselekvés alapján. Célorientált ágens

A reflex-szerű ágensek már egy kissé jobban elvonatkoztattak az aktuális állapottól a leképezés-tábla alapúakhoz képest. Ennek az absztrahálásnak egy radikálisabb formája valósul meg a célorientált ágensekben, ahol a következtetési szabályok felett létrejövő magasabb szinten van definiálva az ágens célja. Ennek az ágens típusnak is van belső reprezentációja a környezetről. Ha az ágens a cselekedeteinek a végcélja alapján dönt az aktuális cselekvés kiválasztásáról, akkor saját cselekedeteinek következményeivel is számolnia kell, nem csak az eddigi lépéseivel kapcsolatban, hanem a meghozandókkal is (0.1.4). Egy ilyen ágensnek már tervkészítési képességekkel kell rendelkeznie, a belső állapot itt már többlépéses következtetések végrehajtására szolgál.

14


Irodalomjegyzék

4. ábraCélorientált ágens felépítése 0.16 Hasznosságorientált ágens

A célorientált ágensek képesek több lépésben egy előre elkészített tervnek megfelelően végrehajtani cselekvéseiket. Sajnos az elérendő célok nem mindig egységesek, egy ágensnek általában több célt kell figyelembe vennie, melyek néha ellentmondanak egymásnak. A célok ellentmondása esetén a célorientált ágens nem tudja eldönteni, hogy melyik cél megvalósítását tűzze ki maga elé. Ezért szükséges a cél alapú megközelítés finomítása, a sikeresség – mint kétértékű állapot – helyett egy árnyaltabb érték, a sikeresség mértékének a használata (0.1.4). Ebben a megközelítésben az ágens céljaihoz hasznosság van rendelve, mely nem kétértékű fogalom, hanem egy intervallum valamely értéke. Az ilyen módon következtető ágens két cél ütközése esetén a számára hasznosabb cél megvalósítását preferálja.

15


Irodalomjegyzék

5. ábraHasznosság alapú ágens felépítése 0.16 0.1.5 Ágens környezetek jellemző tulajdonságai Az alábbiakban az ágensek környezeteinek fontos tulajdonságait vizsgáljuk meg. Ezek azok a tulajdonságok, melyek befolyásolják az ágens tervezését. Hozzáférhető Egy környezet hozzáférhető, ha az ágens képes minden, a döntéseihez fontos cél észlelésére. Determinisztikus Ha a környezet következő állapotát jelenlegi állapota és az ágens cselekvése egyértelműen meghatározza, akkor determinisztikus környezetről beszélünk. Epizódszerű Ha a környezet állapota időbeli egységekre bontható úgy, hogy az egységek állapotai és az azokban végzett ágens cselekedetek nem hatnak a többi egységre, akkor epizódszerű környezetről beszélünk. Dinamikus Ha a környezet változhat, amíg az ágens a következtetési folyamatát végzi, akkor a környezet dinamikus, egyébként statikus. Diszkrét vagy folytonos Ha a környezet figyelembe veendő állapotainak a száma megszámlálható, akkor diszkrét,

16


Irodalomjegyzék

egyébként folytonos környezetről beszélünk.

0.2 Multi-ágens rendszerek Ebben a fejezetben az ágensekből felépíthető multi-ágens rendszerek ismertetése található. A fejezetben a multi-ágens rendszerek definiálása és alaptulajdonságainak ismertetése után a tervezéssel kapcsolatos tudnivalók találhatóak. A fejezet támaszkodik az alábbi forrásokra: Wooldridge, 0.16; H. Van Dyke Parunak, 0.16; Katya P. Sycara, 0.16; Tatai Gábor-Gulyás László, 0.16; Egy ágens tudása, elérhető számítási kapacitása, és az egyetlen perspektíva, amiből megfigyeléseket végezhet a környezetéről, sokszor kevésnek bizonyul egy feladat megoldásához. Ez a korlátozott nézőpont az oka, hogy a kutatók érdeklődése a több ágensből álló rendszerek felé fordult. Az ágens alapú megközelítés multi-ágens rendszereknek hívja ezeket az együttműködő ágenseket. Egy ilyen, több ágensből álló rendszer felépítése jobban igazodik a nyílt rendszerekhez. Nyílt tulajdonságúnak nevezünk egy olyan rendszert, melynek felépítése képes dinamikusan változni, és heterogén elemekből épül fel. Az ágensek fejlesztésének számtalan ötlete a modellül szolgáló természetből és az emberi társadalmakból származik. Az ott megfigyelteknek megfelelően a problémák igen széles körében az ágensek nem önállóan léteznek környezetükben, hanem nagyobb számban, és egymással együttműködve, vagy versengve tevékenykednek. Számtalan multi-ágens rendszert ismerhetünk, néhány példa: • Hangyatársadalom. Sok kutatás irányult annak multi-ágens alapú modellezésére, hogy hogyan oldanak meg a hangyák feladatokat. Ilyen érdekes feladat annak a modellezése, hogy hogyan hangolják össze a hangyák mozgásukat élelemszerzés közben (0.2). • Csordában vadászó állatok. A ragadozók egy része csordában vadászik, ahol a csorda tagjai folyamatosan figyelik egymás helyzetét, és az alapján cselekednek. • Kötelékben repülő költözőmadarak. • Számítógépes játékok együttműködő ágensei. A játékokban található ágensek néha túllépnek azon, hogy csak hatnak egymásra, és közösen is cselekszenek.

17


Irodalomjegyzék

6. ábraA hangyatársadalomban az egyedek közti kommunikáció a feromon segítségével segíti a tájékozódást0.16. A hangyák útvonalukat képesek feromonnal megjelölni, illetve az így megjelölt útvonalat követni. Mivel a többször használt útvonalakon a feromon jel mennyisége megnő, egyre nagyobb eséllyel választják azt az útvonalat. Ilyen módon képesek megtalálni a legrövidebb utat is két pont között (0.2). 0.2.1 Multi-ágens rendszerek története A multi-ágens rendszerek (Multi-agent system, MAS) története a kilencvenes évek végén indult több tudományterület találkozásánál. Eredete kapcsolódik az osztott mesterséges intelligencia kutatáshoz, a robotikához és a szakértői rendszerekhez. Az említettek közül az osztott MI kutatás kapcsolódik a legszorosabban a multi-ágens rendszerekhez, mely azt vizsgálja, hogyan lehet egy feladatot több önálló egység segítségével megoldani. A multi-ágens rendszerek fejlesztése már ott tart, hogy összetett problémák megoldására is használható. Funkcionális szempontból két jellemző feladattípust látnak el ilyen rendszerekkel: az egyik csoportban azok az alkalmazások szerepelnek, ahol fizikai szinten adott a probléma osztottsága. Ilyen a számítógép vezérelte gyártás a különböző folyamatokkal, vagy az ellátási láncok kezelése. A feladatok másik csoportjába azok a fejlesztések tartoznak, melyek bár természetük okán alapvetően központosítottak, de komoly előnnyel jár feladataik többfelé osztása. Ezek olyan komplex számítástechnikai feladatok, melyeket a növekvő elvárások szültek, és nem szolgálhatóak ki hatékonyan központosított rendszerrel. Jó példa erre a fürtözött számítási architektúrán futó terhelésmegosztásos rendszer, például a google keresőmotor. Mindkét esetben az a feladat, hogy a rendszert jól definiált, kompakt, és jól párhuzamosítható részekre osszuk. Az ágens alapú programozás előnyei, hogy jól alakítható egy változó környezetben, rugalmas és jól skálázható. Mára MAS-okkal találkozhatunk rendkívül sok területen: technikai- és orvosi diagnosztizálás, termelés-irányítás és felügyelet, légiirányítás, e-business, szórakoztatás, stb. Az MA rendszerek elterjedtsége ellenére sok nehézséggel találkozhatunk fejlesztésükkor. A 18


Irodalomjegyzék

rendszerek tervezésére, a kész MAS-ok validálására és verifikálására még nincsenek a hagyományos programozási feladatoknál megszokott módszerekhez hasonlóak. 0.2.2 Multi-ágens rendszer definíciója Több kölcsönható ágensből álló rendszereket multi-ágens rendszereknek nevezzük. Kicsit pontosítva az előző definíción elvárjuk egy MAS-tól, hogy autonóm - problémamegoldó – ágensek olyan hálózata legyen, mely hálózat problémamegoldó képessége meghaladja a benne szereplő ágensek képességét. Formálisan: MAS={a1, a2, …, an, K, H}, ahol ai ágens, K a kölcsönhatás módját írja le (például a kommunikáció nyelvét), és H az ágensrendszer struktúrája (például hierarchikus viszonyok). A multi-ágens rendszerben szereplő ágensek kommunikálhatnak és megoszthatják egymással a közös környezet azon részeiről szóló információkat, melyek észlelési körükbe tartoznak. Az egyes ágensek észlelési körei nem feltétlenül fedik egymást (0.2.2). Az egy környezetben lévő ágenseket csoportosíthatjuk az alapján, hogy folytatnak-e egymással kommunikációt.

7. ábraMulti-ágens rendszer: kommunikációs csoportok, észlelési hatáskörök 0.16 Egy multi-ágens rendszer jellemzői: • Minden ágensnek csak korlátozott tudása, érzékelési hatásköre és problémamegoldó képessége van. • Az információk eloszlanak az ágensek között. • Az ágensek aszinkron módon működnek.

19


Irodalomjegyzék

A multi-ágens rendszerek alapvető tulajdonságai után következzenek jellemtűző felhasználási területeik. 0.2.3 MAS felhasználási területek Az alábbiakban ismertetünk néhány olyan jellemzőt, mely ha igaznak bizonyul egy problémára, ott hasznos lehet MAS használata. • • • • • •

Olyan problémák esetén, melyek mérete túl nagy ahhoz, hogy központosítva megoldhatóak legyenek, vagy a központosítás miatt üvegnyak effektus léphet fel, mely veszélyezteti a rendszer működését. Olyan rendszereknél, ahol fontos az elemek közötti kommunikáció és a közös cselekvés. Olyan esetekben, melyek felépítése megfeleltethető önálló részekből álló és egymással együttműködő közösség felépítésének. Például alkusz ágensek esetében. Olyan rendszereknél, ahol hatékonyan kell kezelni osztott információkat, mint például egy érzékelő hálózat. Amikor a tudás megoszlik egy rendszerben, például ipari alkalmazások esetén. Olyan esetekben, amikor a teljesítmény mértéke vagy minősége növelhető a megosztás által. Ilyen előny lehet: számítási hatékonyság, a megbízhatóság, a kiterjeszthetőség, a robusztusság, vagy a rugalmasság növekedése.

0.2.4 Multi-ágens rendszerek típusai A MAS-okat az alábbi jellemzők mentén csoportosíthatjuk: Homogénnek nevezünk egy MAS-t ha egyforma ágensekből épül fel, ellenkező esetben heterogénnek. Nyílt rendszerű egy MAS, ha képes más rendszerekkel együttműködni. Ez természetesen feltételezi valamilyen közös nyelv használatát. Ilyen közös nyelv lehet valamelyik szabványos ACL (Agent Communication Language, ágens kommunikációs nyelv), például a FIPA ACL vagy a KQML. Bár egyéb rendszerek esetében erős tendencia a nyíltság terjedése, de autonóm ágensek esetén ez csak jól összehangolt fejlesztés esetén valósul meg. 0.2.5 Multi-ágens alkalmazások tervezése Egy MAS tervezésekor az alábbi, főbb kérdésekre kell válaszolni. • Hogyan specifikáljuk és osztjuk meg a feladatot úgy, hogy ágenscsoporttal megoldható legyen? • Hogyan fognak az ágensek kommunikálni, milyen rétegen keresztül, és milyen protokoll segítségével? • Hogyan biztosítjuk, hogy a sokelemű ágens rendszer koherensen viselkedjen, ne adódjanak problémák az összetett működés során? • Hogyan oldjuk meg, hogy az egyes ágensek tudása megfelelő minőségű legyen a többiről a működéshez? 20


• •

Irodalomjegyzék

Hogyan oldjuk fel az ágensek különböző információiból és esetleg eltérő felépítéséből származó konfliktusokat úgy, hogy a teljes rendszer hatékonyan működjön? Milyen fejlesztési metódusokat és környezeteket választunk a rendszer létrehozásához?

Lássuk, hogy a tervezés során figyelembe veendő kérdésekre milyen felépítések és folyamatok adhatnak választ. MAS felépítések

A multi-ágens rendszerek tervezésekor olyan felépítést választhatunk, mely összehangolja az ágensek működését, és ilyen módon a struktúrán keresztül megoldja a konfliktusok kezelését. A rendszerek felépítése is a mindennapi életből vett példákra támaszkodik. • Hierarchikus: a rendszerben kitüntetett szerepe van egy vagy több ágensnek, melyek meghatározzák a többi működését. • Piaci: a vezérlés megoszlik az ágensek között, melyek valamilyen piaci módszerrel hozzák meg döntéseiket. A módszer lehet az árverés valamilyen formája. • Szakértői közösség: az egyes ágensek speciális tudással rendelkeznek, a feladatokat ezek alapján osztják meg. • Tudományos közösség: a problémák megoldása lokálisan születik meg, majd publikálásra kerül a közösségben, mely tesztelheti és finomíthatja azt. Akármilyen MAS felépítést is válasszunk, abban fel kell oldanunk a konfliktusokat, ehhez pedig valamilyen egyezség kialakítására alkalmas eljárást kell a rendszerbe építenünk. Egyezség kialakítása

Egy MAS-ban részt vevő ágensek alapvetően két szemlélettel bírhatnak. Az ’egoista’ ágensek a saját hasznosságukat maximalizálják, míg egy ’csoportközpontú’ ágens az egész rendszer összes hasznosságát vizsgálja. A tervezés egyik fontos feladata tehát eldönteni, hogy az ágensek milyen logika alapján maximalizálják a hasznosságot. Amennyiben létrejön egy olyan állapot, melyben egyeztetni kell a cselekvési tervet, mert nem minden ágens számára ugyanaz a cselekvés a leghasznosabb, akkor különböző technikák szolgálnak az egyezség kialakítására. Az egyezség kialakítását az ágensekbe épített mechanizmusok, protokollok és az általuk használható stratégiák segítik. Az ágensek együttműködési mechanizmusainak kialakításánál az alábbi szempontokat kell figyelembe venni: • Konvergencia egy megoldáshoz, legyen garantálva annak véges idejű létrejötte. • Hatékonyság. • Az egyes ágensek számára legyen racionális. • Stabilitás, egyszerűség (robosztusság). • Együttműködésre épüljön. Az egyezség kialakításának egy lehetséges módja az aukció. Az aukció célja, hogy egy bizonyos, az ágensek számára hasznos dologról döntsön, a döntési folyamatban a licitáló ágensek árat kínálnak a licit tárgyáért. A folyamat során a licit-vezető maximalizálni

21


Irodalomjegyzék

próbálja az árat, a licitálók pedig minimalizálni. A licitálási módszerek MAS-ok esetében sokfélék lehetnek. A licitálási folyamat eltérhet az ár publicitásában (nyílt, zárt), a nyertes kiválasztásában (első ár, második ár), a licitált dolog jellegében, és a licit folyamat lezajlásában (egyszeres, csökkenő, emelkedő). Ezen jellemzők alapján megkülönböztetjük az angol, holland, első áras, vickrey, és egyéb típusú aukciókat. Az egyezség kialakításának másik módja az egyeztetés (0.2.5). Az egyezkedés részei: az ágensek számára választható cselekvések, a protokoll, az ágensek saját stratégiája, a szabály, amely eldönti, hogy vége van-e a folyamatnak. Az egyezkedés jellemzően több körben zajlik, a döntés finomításával. Az egyeztetés tárgyaként vizsgált választható cselekvéseket az ágensek számára a csoportszintű és a saját hasznosság jellemzi.

8. ábraAz egyezkedés lehetséges hasznossága 0.16 Kommunikáció

Az ágensek kommunikációja - mint minden más tulajdonságuk - erősen köthető a példaként szolgáló emberi kommunikációhoz. A szoftver ágensek kommunikációjában is megtalálhatjuk a különböző típusú információcseréket: • Reprezentáció: például esik az eső, vagy nő a processzor terheltsége. • Utasítás: például kérlek értesítsd a rendszergazdát. • Ígéret: például ígérem, hogy értesítem a rendszergazdát, hogy megnőtt a processzor terheltség.

22


• •

Irodalomjegyzék

Érzelemleírás: például köszönöm, hogy megtetted. Deklaráció: például a2+b2=c2.

Általában elmondható, hogy egy beszéd esemény kétféle típusú lehet: informatív – például „esik az eső” – és cselekvésre utaló – például „hozd légy szíves az ernyőt”, vagy „hozom az ernyőt”. Természetesen ezek összeállhatnak összetett beszéddé. Természetesen sok kísérlet történt már arra, hogy a beszéd-értelmezésnek olyan formális leírását adják, mely gépi kommunikáció alapját is adhatja. Ilyen formalizmust készített Cohen és Perrault, akik modellüknek az előfeltétel-törlésbővítés (precondition-delete-add) nevet adták. Például egy kérés formális leírása lehet az alábbi: Request (s, h, φ) Pre s hiszi, hogy h képes φ-re s hiszi, hogy h hiszi, hogy képes φ-re s hiszi, hogy s akarja φ-t

Post h hiszi, hogy s hiszi, hogy s akarja φ-t

Szabványos ágens kommunikációs nyelvek

Az ágensek közti kommunikáció szabványosítására létrehoztak szabványos nyelveket, ezeket az angol rövidítés alapján ACL-nek (Agent Communication Language, Ágens Kommunikációs Nyelv) nevezik. A legismertebb ACL a KQML, melyet az ARPA fejlesztett ki 0.16. Két részből áll, a tudás lekérdező és változtató nyelvből (KQML) és a tudás reprezentációs formátumból (KIF). A KQML beszédesemények egy készletét határozza meg, melyeket az ágensek rögzített szemantikai tartalommal használhatnak. Például: • Ask-if : kérdés, igaz, hogy .... • Perform : készülj fel arra, hogy .... • Tell : kijelentés, igaz, hogy .... • Reply : a válasz az, hogy .... A KIF ezzel szemben a tartalom kifejezésére szolgál, például: • Inform: tudatom veled, hogy KQML/KIF dialógust mutat az alábbi táblázat (0.2.5). Feladó -> Címzett A -> B B -> A B -> A B -> A

Üzenet Jelentés (ask-if (> (prioritás x) (prioritás y))) Igaz-e hogy: x prioritása nagyobb y-énál ? (reply true) A válasz: igaz (inform (= (prioritás x) 40)) Tudatom: x prioritása = 40 (inform (= (prioritás y) 20)) Tudatom: y prioritása = 20 2. táblázat KQML/KIF dialógus A és B ágens között

23


Irodalomjegyzék

A másik legismertebb kezdeményezés ACL létrehozására a FIPA-tól származik, és sok mindenben hasonlít a KQML-re. Egy FIPA üzenet felépítése az alábbi: • Üzenet típus (mint a KQML-ben, 20 féle van definiálva) • Üzenet információk (például küldő) • Tartalom (az üzenet információ tartalma) Szabványos FIPA üzenet például az alábbi (0.2.5): (inform :sender agent_A :receiver agent_B :content (= (prioritás x) 40) :language példa_nyelv :ontology prioritások

Küldő: A Fogadó: B Tartalom: x prioritása 40 Üzenet nyelve: példa_nyelv Ontológia: prioritások

)

3. táblázat Fipa üzenet A FIPA üzenetek öt jellemzővel bírhatnak, ezeket, és néhány jellemző FIPA üzenetet mutat be a 0.2.5. Üzenet típus Accept-proposal (együttműködési kérelem elfogadása) Agree (egyetértés) Cancel (mégse) Cfp (Együttműködés kérése) Confirm (egyetértés) Disconfirm (egyet nem értés) Failure (hiba) Inform (információküldés) Inform-if (feltételes informálás)

Üzenet küldés

Információ kérés

Egyezkedés

Cselekvés Kérés

Hibakezelés

X X X

X X

X X X X X 4. táblázat Néhány FIPA üzenet típus 24


Irodalomjegyzék

Az üzenetek jelentésének leírása két részből áll: az előfeltételekből és az elvárt racionális viselkedésből, melyre az üzenetet küldő fél számít. Együttműködés

A fent ismertetett egyeztetési módszerekkel és nyelvekkel az ágensek már alkalmasak arra, hogy együttműködjenek. Most az együttműködés formáit vizsgáljuk meg. Az együttműködés módja alapvetően függ attól, hogy ’csoportközpontú’ vagy ’egoista’ ágensekből épül-e fel a MAS. Természetesen a csoportközpontú viselkedést csak akkor tudjuk garantálni a rendszer minden ágensére, ha azok mind saját fejlesztésűek. Ebben az esetben az együttműködő ágensek osztott problémamegoldóként működhetnek, akár nagyságrendekkel hatékonyabban, mint ’egoista’ társaik. Emellett az egész rendszer tervezése is nagyban leegyszerűsödik együttműködő ágensek használata esetén, hiszen egyáltalán nem, vagy kevesebbet kell foglalkozni a konfliktusok kezelésével. Az együttműködés két alapvető formáját különböztetjük meg: a feladatmegosztást és az eredmény (információ) megosztását. Egy feladatmegosztó protokoll példa: a Vállalkozási Háló. A protokollnak megfelelő MAS a következő lépésekben osztja ki a feladatokat: • Feladat felismerése specifikálása. A feladat részekre is osztható. • Az ágens észleli, hogy nem képes hatékonyan végrehajtani egyedül a feladatot, vagy részfeladatot. • Feladat kihirdetése. Az ágens kihirdeti a specifikált feladatot, határidőt. • Ajánlattételek. A kihirdető ágens fogadja az ajánlatokat, azon ágensektől, akik képesnek hiszik magukat a végrehajtásra. • Feladat elnyerése. A legjobb ajánlat nyer. • Végrehajtás, vagy a feladat további részekre osztása és továbbadása. Egy eredménymegosztó protokoll: a hirdetőtábla. Ha az ágensek együttműködése nem feltétlenül terjed ki a feladatok közös megosztására, sokszor ’csak’ az információk megosztásával hatnak egymásra. Az ilyen rendszerek egyik típusa a hirdetőtábla, melyben az ágensek egy mindenki számára elérhető helyre – például egy elérhető állományba, vagy adatbázisba - teszik ki az információkat, majd azokat a többi ágens megvizsgálhatja, és a számára érdekeseket felhasználhatja.

25


Irodalomjegyzék

Hálózat-diagnosztizálás A hálózat-diagnosztizálás feladata, hogy folyamatosan figyelje a hálózat működéséhez szükséges eszközök állapotát, és segítsen az esetleges hibák javításában. A hálózatdiagnosztikai rendszereket szokás az alapján osztályozni, hogy megfigyeléseik mire vonatkoznak. Ez alapján hoszt- és hálózat-központú rendszereket különböztetünk meg. A hoszt-központú rendszerek a hosztok és szolgáltatások, míg a hálózat-központúak a hálózati forgalom viselkedése alapján figyelik meg a hálózatot. Az alábbiakban bemutatott rendszer reprezentálja a hálózatdiagnosztikai rendszerek jelenlegi helyzetét. Ezzel a rendszerrel összehasonlítva lehet értékelni, hogy érdemes-e multi-ágens rendszert bevetni ezekre a feladatokra. Ezen rendszerek bemutatásán keresztül ismerhetőek meg legjobban a hálózatok figyelésével kapcsolatos feladatok, így ezek bemutatására nem térek ki külön.

0.3 Hagyományos hálózatdiagnosztikai eszköz A hagyományos diagnosztikai eszközök bemutatásához a Nagios-t 0.16 választottam. A választást elterjedtsége, széles funkcionalitása, bővíthetősége és szabad felhasználhatósága indokolta. A Nagios megbízhatóságát bizonyítja, hogy ezt az eszközt választotta az ELTE hálózat felügyelete is. A választott rendszerben lehetőség van több megfigyelőből álló rendszer megvalósítására is, így összehasonlíthatóvá válik segítségével a központosított és az osztott felépítés. A Nagios hoszt központú, tehát megfigyeléseit hosztokra és a hosztokon futó szolgáltatásokra vonatkoznak. A Nagios bemutatásához a hozzá adott dokumentációt vettem alapul 0.16. 0.3.1 Ismertető A Nagios az adminisztrátor által beállított hosztokat és szolgáltatásokat figyeli, és figyelmeztetéseket küld a szolgáltatásokkal kapcsolatos fennakadásokról, majd azok elhárulásáról. A rendszer Linux operációs rendszer alá készült, de megbízhatóan működik a legtöbb Unix rendszer alatt is. A rendszer által nyújtott szolgáltatások: • Hálózati szolgáltatások figyelésére (SMTP, POP3, HTTP, NNTP, PING, stb.). • Fizikai erőforrások figyelése (processzor-terheltség, lemezhasználat, stb.). • Bővíthetőség: a felhasználó saját maga is fejleszthet szolgáltatás-figyelő modulokat. • Párhuzamosítható benne a szolgáltatások ellenőrzése. • Hálózati hosztok között hierarchikus felépítés adható meg, így meg lehet különböztetni az esetlegesen nem működő hosztokat az elérhetetlenektől. • Figyelmeztetések küldése a rendszergazdáknak (email, sms, stb.). • Eseménykezelők definiálhatóak hosztokkal és hálózattal kapcsolatos eseményekhez. • Automatikus logfile rotáció. A rendszer által gyűjtött adatokat tartalmazó állományok automatikus kezelése.

26


• • •

Irodalomjegyzék

Redundáns monitorozó hosztok alakíthatóak ki. Az ilyen rendszerben a meghibásodott megfigyelő helyére másik léphet. Opcionálisan kialakítható webes felület az összegyűlt adatok megtekintésére. Többféle adattároló módszer használata. Alapértelmezésben file-okban kerülnek tárolásra az adatok, de lehetőség van adatbázisok használatára is. Jelenleg a Mysql és Postgres adatbázis-kezelők használhatóak.

0.3.2 Elérhetetlenné vált vagy nem működő hosztok figyelése A Nagios fő célkitűzése, hogy a hálózaton lévő hosztokon vagy egyéb eszközökön futó szolgáltatásokat figyelhessük. Nyilvánvaló, hogy ha egy Hoszt leáll, akkor a rajta lévő összes szolgáltatás elérhetetlenné válik. Ha a Hoszt elérhetetlenné válik, akkor a Nagios nem képes megállapítani, hogy mely szolgáltatások működnek rajta. A Nagios minden esetben, amikor észleli, hogy egy szolgáltatás elérhetetlenné vált, ellenőrzi, hogy az őt szolgáltató szerver elérhető-e (jellemzően a szerver pingelésével). Ha a szerver elérése sikertelen, akkor a rendszer feljegyzi, hogy gond van az adott hoszttal. Ebben az esetben a rendszer nem küld riasztást az összes azon hoszton futó rendszer leállásáról, csak annak a személynek, aki a leállással kapcsolatban riasztandó. Amikor a hoszt működése helyreáll a Nagios erről is üzenetet küld. Helyi hoszt figyelése

Helyi vagy lokális hosztnak nevezzük a rendszer szóhasználata szerint azon szervereket, melyek a hálózat azonos részében helyezkednek el. Egy lokális hoszt ellenőrzése meglehetősen egyszerű. Nincs útválasztó vagy külső hálózat a monitorozó rendszert futtató hoszt és helyi hoszt között, így az adott hoszt elérhetetlenné válása egyszerűen ellenőrizhető.

27


Irodalomjegyzék

9. ábraEgy mintahálózat A mintahálózatban a C hoszt szempontjából helyi Hoszt D, E, C és a II-es útválasztó (0.3.2). Távoli hoszt

Távolinak nevezi a Nagios szóhasználat a nem helyi hosztokat. Természetesen nem minden hoszt van ugyanolyan távol szomszédsági szempontból egy adottól, hisz van melyeket csak egy lépés választ el az adott hoszttól és van melyeket több. Ha a mintahálózatban az A hosztot jelöljük ki a monitorozó rendszer futtatására, akkor a tőle való távolságot az A és a kijelölt hoszt közötti routerek számával jellemezhetjük. Mivel A és egy kijelölt hoszt között az útválasztókon keresztül zajlik az adatáramlás, így a hosztoknak fontos jellemzője, hogy mely routereken keresztül juthatunk el tőle A-ba. A Nagios szóhasználat emiatt bevezeti a szülő fogalmat a hosztokra, amelynek jelentése egy hosztra az a hoszt, melyen keresztül küldendő az információ a monitorozó hoszt felé (következő ábra). Ennek a definíciónak megfelelően a C, D, E szülője router II, míg B-nek nincs szülője, mert helyi tulajdonságú A szempontjából. A szülő tulajdonság (0.3.2) bevezetése a nem lokális hosztok figyelését segíti. Amikor a Nagios észleli, hogy egy távoli hoszt elérhetetlenné vált, akkor sorban megvizsgálja annak szüleit, hogy kiderítse, hogy hálózati hibáról van-e szó.

28


Irodalomjegyzék

10. ábraA mintahálózat felépítése szülő – gyermek szempontból 0.3.3 Hálózati kimaradások diagnosztizálása A Nagios rendelkezik olyan képességgel, mellyel hálózati kimaradások okát lehet kutatni. Ez a képesség elsősorban nagyméretű hálózatokban hasznos, ott növeli jelentősen a kimaradások okának felderítési hatékonyságát. A Nagios a szülő gyermek kapcsolat felhasználásával diagnosztizálja a hálózati kimaradások valószínű okozóit. Ha hosztok egy csoportja elérhetetlenné válik (a megfigyelő rendszer szempontjából), akkor a rendszer az alábbi logika alapján keresi a kimaradás okozóját: egy problémás hoszt okozója lehet a kimaradásnak, ha elérhetetlen, vagy kikapcsolt állapotban van, és legalább egy szülője elérhető állapotban van. Az ilyen lehetséges problémaforrásokra a rendszer megvizsgálja, hogy minden olyan közvetlen leszármazottjuk elérhetetlen-e, melyeknek nincsen más közvetlen szülőjük. Ha ez a vizsgálat is igaznak bizonyul, akkor a rendszer a kimaradás okozójának tünteti fel a hosztot. A Nagios a hálózati kimaradások okozóit a kimaradás súlyossága alapján rangsorolva listázzák. Ehhez a diagnosztikai rendszer megvizsgálja, hogy hány hoszt és hány szolgáltatás kimaradását eredményezte a hoszt kiesése, és a kapott adatok alapján súlyozza a lista elemeit.

29


Irodalomjegyzék

0.3.4 Figyelmeztetések A Nagios képes figyelmeztetések küldésére a hosztok és szolgáltatások karbantartói számára. Figyelmeztetés küldése akkor történik, ha a szolgáltatás vagy hoszt állapota jelentősen megváltozik – akár javul, akár romlik – illetve akkor, ha az elromlott szolgáltatás a bekonfigurált időhatár után sem kelt életre. A figyelmeztetések a szolgáltatásokhoz rendelt értesítési listák résztvevőinek kerülnek kikézbesítésre. A figyelmeztetések kiküldése előtt azok szűréseken esnek keresztül, melyek megakadályozhatják kiküldésüket. A szűrések lehetnek rendszer szintűek – minden figyelmeztetés tiltása – vagy szolgáltatás alapúak – például előre bejelentett kimaradás esetén. A figyelmeztetések több módon is kiküldhetőek: emailben, sms-ben, Üzenetküldő szolgáltatásokon keresztül, Hangjelzésekkel, stb. 0.3.5 Szolgáltatásellenőrzési szenzorok A Nagios sok más rendszerrel ellentétben nem tartalmaz beépített szenzorokat a szolgáltatások ellenőrzésére. Ehelyett a piszkos munkát külső programokra - pluginokra – bízza (0.3.5). Ezeket a programokat a Nagios elindítja, majd futásuk után visszakapott eredmények alapján esetleg cselekvéseket végez. Ilyen cselekvés lehet egy eseménykezelő indítása vagy egy figyelmeztetés kiküldése. A lényeg, hogy a szenzorok fekete dobozok a rendszer magjának szempontjából. Ezzel a felépítéssel a rendszer természetes tulajdonsága, hogy nyitott az új szenzorok létrehozására és integrálására.

11. ábraSzenzorok és a Nagios magja Természetesen annak ellenére, hogy a Nagios magja nem tartalmaz szenzorokat, már nagy számban készültek hozzá különböző feladatok elvégzésére. Így az alapvető diagnosztikai feladatok már le vannak fedve Nagios szenzorokkal, ilyenek például: processzor terheltség ellenőrzése, lemez telítettség, processzor hőmérséklet, vagy a hálózati válaszidő mérése. Az, hogy a rendszernek fogalma sincsen arról, hogy a szenzorok mit mérnek, jár némi kényelmetlenséggel. Mivel nem ismert a mag számára, hogy a szenzor által mért értékek mit jelentenek, nem képes eldönteni azt, hogy hogyan viszonyulnak azok az optimális értékekhez. Így a rendszer csak státuszokkal képes operálni, melyek azt jelzik, hogy az adott szolgáltatáshoz kapcsolódó mérési eredmény alapján a szolgáltatás megfelelően

30


Irodalomjegyzék

működik-e. A szenzorok és a szolgáltatások kapcsolata egyszerű. Amikor a Nagios egy szolgáltatást ellenőriz, egyszerűen végrehajtja a szolgáltatáshoz a konfigurációs állományban rendelt szolgáltatásellenőrzési szenzort. 0.3.6 Szolgáltatás-ellenőrzés időzítése A Nagios egy időzítési rendszert tartalmaz, mely meghatározza, hogy melyik szolgáltatást mikor kell következőnek ellenőrizni. A hosztok vizsgálata más logika alapján történik: azok csak akkor kerülnek ellenőrzésre, ha egy rajtuk futó szolgáltatás elérhetetlenné válik. A szolgáltatások ellenőrzéseinek időzítése két okból is fontos: az egyik, hogy a monitorozó rendszert futtató hosztnak rendkívül sok feladata lehet, és így azon a terhelést minél egyenletesebben kell elosztani. A másik, hogy a megfigyelt szolgáltatásokat nyújtó hosztokon sem illendő egyenetlen terhelést okozni, főleg, hogy azt egy esetleges elárasztásos (sok lekérdezéssel operáló) támadásként is értékelhetik. Ezen okok miatt igen fontos, hogy a rendszer megfelelően ossza szét a megfigyelési feladatokat. Az időzítő egy másik konfigurálható paramétere azt írja le, hogy hány szenzort lehet működésbe hozni egy időben. Ennek kiértékelése azzal a haszonnal jár, hogy a rendszer nem foglal le túl sok erőforrást – elsősorban processzor időt – a monitorozó hoszton. Ha túl sok feladat kerül egy időben időzítésre, akkor a rendszer elhalasztja az utoljára érkezőket. A Nagios normál állapotúnak hív egy szolgáltatást, ha az rendben fut, vagyis a hozzá kapcsolt szenzorok szerint megfelelő az állapota. Ebben az esetben csak a szolgáltatáshoz rendelt ellenőrzési periódusonként vizsgálja meg a működést. Amennyiben a szolgáltatás nem megfelelő állapotba kerül a mag a félig-problémás állapotjellemzőt rendeli hozzá. Ezek után az időzítő többször is újraellenőrzi a szolgáltatást, hogy ne rendeljen hozzá feleslegesen problémás állapot-jellemzőt. Amennyiben az újfenti ellenőrzések is sikertelenek és a szolgáltatás nem megfelelő (non-ok) állapotban marad, úgy a Nagios mag a problémás állapotot rendeli hozzá. Ezek után a rendszer megteszi a megfelelő lépéseket: figyelmeztetéseket küld, elindítja az eseménykezelőket. A probléma megszűntéig a szolgáltatás problémás állapotban marad, ami azzal jár, hogy a rendszer gyakrabban ellenőrzi állapotát. 0.3.7 Állapotok és állapot-jellemzők A Nagios működése szempontjából rendkívül fontosak az állapotok és az állapot-jellemzők. Egy szolgáltatás állapota pillanatnyi státuszát jelenti. Ennek megfelelően az állapot diszkrét értékeket vehet fel, például: • Megfelelő (OK) • Nem-megfelelő (Non-OK, vagy Warning) • Kritikus (Critical) • Elérhetővé vált (Up) • Elérhetetlenné vált (Down) A fenti állapotok viszont csak a pillanatnyi állapotról adnak leírást. Emiatt a Nagios bevezet egy állapot-jellemzőt, mely tulajdonság az utolsó valahány állapot alapján jellemzi a

31


Irodalomjegyzék

szolgáltatást. A jellemzők a félig-problémás (soft) és a problémás (hard) értéket vehetik fel. A félig problémás állapotból az előző pontban leírtaknak megfelelően, többszöri ellenőrzés után kerül a szolgáltatás a problémás állapotba. Az állapot-jellemzők feladata, hogy a problémák súlyosságának minősítésével lehetőséget adjanak a felesleges riasztások elkerülésére. A félig-problémás állapotban a rendszer nem küld ki figyelmeztetéseket, végrehajtja viszont a szolgáltatáshoz kapcsolt megfelelő eseménykezelőket, ha vannak. Ilyen módon a rendszerek fenntartói kísérletet tehetnek megfelelő eseménykezelők készítésével a problémák automatikus megoldására. Ilyen megoldás lehet lemezterület kritikus mértékű fogyása esetén átmeneti állományok törlése. A problémás esetekben, ha a rendszer nem kerül elérhető állapotba, akkor végrehajtódnak a megfelelő eseménykezelők, és a rendszer kiküldi a figyelmeztetéseket. 0.3.8 Eseménykezelők Az előző pontokban már szóba kerületek az eseménykezelők, melyek arra hivatottak, hogy egy szolgáltatás állapotának változásakor automatikusan végrehajtsanak parancsokat. A felhasználás leggyakoribb formája az, amikor egy elhaló szolgáltatást próbál a hozzá rendelt eseménykezelő feltámasztani. Tipikus példa erre a lemezterület felszabadítása, melyet az alábbi módszerrel kell beállítani. Elsőként definiálni kell a szolgáltatást: Nagios kód Jelentés define service{ Szolgáltatás definiálása host_name somehost Futtató hoszt megadása service_description DISK Szolgáltatás-típus megadása max_check_attempts 4 Többszöri ellenőrzések száma event_handler clear-tmp Eseménykezelő hiba esetére } 5. táblázat Nagios szolgáltatás-definíció Ezután definiálni kell a hozzá kapcsolt eseménykezelőt. Paraméterben át lehet adni a Nagios által kezelt változók értékeit: Nagios kód Jelentés define command{ Parancs definiálása command_name clear-tmp Parancs neve command_line /usr/nagios/clear_tmp Parancssori meghívása $SERVICESTATE$ paraméterekkel, melyek helyére a $STATETYPE$ Nagios aktuális értékeket $SERVICEATTEMPT$ helyettesít futtatáskor. } 6. táblázat Nagios eseménykezelő Majd el kell készíteni az eseménykezelő programot, jelen esetben egy nagyon egyszerű shell szkriptet. A szkriptben ki lehet használni az átadott paraméterek értékeit.

32


Irodalomjegyzék

#/bin/bash # # Ez a szkript gondoskodik lemezterület felszabadításáról # A monitorozó rendszer hívja meg, ha kritikus szintre csökken a szabad # lemezterület # a lemezterület fogyásának mértéke alapján case “$1” in OK) # nem csinálunk semmit, mert minden rendben van ;; WARNING) # egyenlőre nem esünk igazan kétségbe ;; CRITICAL # most mar muszáj csinálni valamit # meg kell vizsgálni, hogy nem csak átmeneti állapotról van-e szó case “$2” in SOFT) # lehet, hogy csak átmeneti problémáról van szó, töröljünk kíméletesen rm /tmp/*tgz ;; HARD) # állandósult a helyhiány, toroljunk mindent, amit lehet rm –rf /tmp/* ;; esac ;; esac exit 0; 7. táblázat Eseménykezelő program A fenti szkriptben (0.3.8) is megfigyelhető, hogy ki lehet használni a rendszer állapotainak és állapot-jellemzőinek ismeretét. 0.3.9 Passzív szolgáltatás-ellenőrzés Az eddig ismertetett szolgáltatás-monitorozást a Nagios elnevezési konvenciója aktív címkével látja el. Az aktív monitorozás azt jelenti, hogy a rendszer maga hívja meg az időzítő által kijelölt időpontokban a megfelelő szenzort. Ezzel szemben lehetőség van arra, hogy külső programok, az időzítőtől függetlenül monitorozási feladatokat lássanak el. Ezek a programok a rendszer magjától függetlenül, önállóan indulnak el, és egy állományba írják futásuk végeredményét. A mag menetrend-szerint elolvassa az állományt, és ha talál benne külső futási eredményt, akkor azt is felveszi a megfigyelések közé. Ezt a módszert nevezi a Nagios szóhasználat passzív ellenőrzésnek. A passzív ellenőrzés az alábbi esetekben hasznos:

33


• •

Irodalomjegyzék

Amikor a szolgáltatás egy tűzfal mögött helyezkedik el, és nem lehet aktívan monitorozni. Amikor aszinkron természetű eseményekhez kapcsolódik a megfigyelés, például biztonsági riasztás esetén.

12. ábraKülső programok, a passzív ellenőrzés szenzorai Amennyiben a passzív monitorozást végző program a Nagios maggal megegyező hoszton fut, külső programok adatai számára fenntartott állomány írása nem okozhat gondot. Ha a külső program távoli hoszton van, úgy igénybe veheti az NSCA kiegészítést, mely kliens szerver felépítésű, és az adatok központi szerverre való eljuttatásáért felel (0.3.9). 0.3.10 Hoszt vagy szolgáltatás lebegő állapotban A monitorozás során előfordul, hogy a rendszer egy olyan hosztra vagy szolgáltatásra figyel fel a rendszer, mely gyakran változtatja állapotát (0.3.10). Ez a jelenség a lebegés, és érdemes megkülönböztetett módon foglalkozni vele, mert a jelenség mögött gyakran valamilyen összetett ok áll. Ilyen ok lehet például, ha a meghibásodáshoz kapcsolódó eseménykezelő csak átmenetileg javítja meg a szolgáltatást. Eseménykezelőknél látott példa esetén felmerülhet a jelenség, ha egy folyamat folytonosan kritikus méretű állományokat ír a temporális könyvtárba, melyeket az eseménykezelő rendszeresen letöröl.

34


Irodalomjegyzék

13. ábraLebegő állapotba került szolgáltatás monitorozása 0.16 A rendszer a gyakran állapotot változtató szolgáltatások – vagy hosztok – esetében kiszámít egy értéket, mely a lebegési állapot beálltát valószínűsíti. A lebegési valószínűségi értéket az állapot változások teljes megfigyelések számával való összevetésével kapjuk, melyet a rendszer időrenddel súlyoz a frissebb megfigyelések fontossága miatt. Amennyiben a kiszámolt érték az előre konfigurált határérték felett van, akkor a szolgáltatást a rendszer lebegőnek címkézi. Ezek után a rendszer: naplózza az eseményt, csökkenti a kiküldött üzenetek számát. 0.3.11 Teljesítménymérések A Nagios rendszer kétféle mérési adattal dolgozik: a saját működését jellemző futási adatokkal és a szenzorok által szolgáltatott adatokkal. A szenzorokról szóló fejezetben kifejtetteknek megfelelően, a Nagios magnak nem részei a szenzorok azok eredményeiről csak egy absztrakt szinten – a visszakapott státuszok alapján – vesz tudomást a rendszer. Ennek megfelelően a szenzoroktól kapott adatok részletes értékelésére olyan külső programokat kell bevetni, melyeknek van információjuk a mérési adatok pontos szemantikájáról. Ennek a logikának megfelelően a szenzorok visszatérési értékeik között is szét vannak választva a magnak szóló információk, és a finom mérési eredmények. Például egy hálózati kapcsolat sebességének mérésére szolgáló szenzor visszatérési értéke lehet az alábbi: PING ok - Packet loss = 0%, RTA = 0.80 ms | percent_packet_loss=0, rta=0.80 Ahol a pipe („|”) karakter előtti eredmények szólnak mindig a magnak, az utána következők pedig a finom mérési eredmények. A finom mérési eredmények tárolása is külön történik, és az eltárolt adatokra szenzor specifikus programok készíthetőek melyek kiértékelik az adatokat, és statisztikákat készítenek belőlük. 0.3.12 Időzített leállások Minden rendszer életciklusában vannak olyan intervallumok, amikor valamilyen ok miatt előre eltervezett módon leállításra kerülnek. Ilyen esetekre a rendszerben lehetőség van időzített leállás beállítására, mely intervallum alatt nem kerülnek figyelmeztetések kiküldésre.

35


Irodalomjegyzék

0.3.13 Összefoglalás Megismertünk egy hagyományos felépítésű hálózat diagnosztizáló rendszert. Alapvető logikája, hogy egy központi megfigyelő a hálózat egy bizonyos pontjáról szenzorok segítségével adatokat gyűjt hosztokról és az azokon futó szolgáltatásokról. Természetesen a hálózatot karbantartó szakértőknek komoly segítség egy ilyen rendszer használata, hiszen automatizálhatóak általa azok a rutinfeladatok, melyek idejük nagy részét lefoglalhatják, és töredékére csökkenhet a hibák felderítésének és elhárításának ideje. Mondhatjuk-e, hogy a Nagios rendszer magja egy szoftver ágens? Igen, hiszen megfelel annak az informális definíciónak mely szerint: „Az ágens egy olyan szoftver-alkalmazás, ami meg tud csinálni valamit, amire valószínűleg mi is képesek lennénk, ha lenne rá elég időnk”. De a Nagios megfelel az ágensek formális definíciójának is, hiszen rendelkezik a megkövetelt tulajdonságokkal: • Beágyazottság A Nagios beágyazott, hiszen csak a hálózatos környezetben képes működésre. • Reaktivitás A Nagios reaktív, hiszen a szenzorai által gyűjtött értékek alapján valós idejű eseménykezelők indítását végzi. • Autonómia Az rendszer autonóm, hiszen önállóan, direkt beavatkozás nélkül működik. • Helyzetfüggőség A Nagios helyzethez és szerephez kötötten ágensek csupán, hiszen csak aktív monitorozó rendszerként viselkedik ágensként. Az informális definíciónak való megfelelése megmutatja, hogy a rendszer képes időt takarítani meg használóinak. De mi az, amit nem képes egy ilyen centralizált ágens elvégezni? • Egy példányú, így nem figyelhet akármennyi szolgáltatást • Egy hoszton fut, így nem látja több szemszögből a hálózatot. Ennek nyoma visszaköszön a rendszer szóhasználatában, mely például a nem elérhető szolgáltatást a megfigyelő által nem elérhető szolgáltatásként definiálja. • Nem robusztus, hiszen a központi ágens elérhetetlenné válása teljes leállást is jelent. A fenti okok a Nagios fejlesztését is a párhuzamosítás irányába mozdították. Megjelennek a rendszerben olyan funkciók, melyek a központosított rendszer gyengeségeit igyekeznek orvosolni.

0.4 Osztott rendszerű hálózatdiagnosztizálás A Nagios fejlesztésekor is világossá vált, hogy egy központi hoszton futó monitorozó rendszer nem képes ellátni minden feladatot. Ezért több olyan lehetőséget építettek a rendszerbe mely robusztusabbá tette, vagy lehetőséget adott arra, hogy több megfigyelőtől gyűjtsön adatokat. Ezekről a módszerekről lesz szó az alábbiakban. A kérdés az, hogy ezek a kiegészítések feljavítják-e annyira a rendszer tulajdonságait, hogy versenyezhessen egy alapvetően osztott rendszerű alkalmazással.

36


Irodalomjegyzék

0.4.1 Indirekt hoszt és szolgáltatás ellenőrzés Sok olyan szolgáltatás van, melyek ellenőrizhetőek közvetlenül a Nagios magot futtató hoszton lévő szenzorok segítségével. Ezek többnyire publikus szolgáltatások, mint a web, dns, vagy ftp szolgáltatás. De vannak olyan privát szolgáltatások, vagy hoszt jellemzők, melyek nem véletlenül nem publikusak. Ilyen lehet a processzor hőmérséklete, a diszk telítettsége egy távoli gépen, vagy egy tűzfallal védett hálózat valamely belső szolgáltatása. Hasonló problémát jelent egy védett zóna két hosztja közötti hálózati kapcsolat sebességének tesztelése, mely szintén nem oldható meg a zónán kívülről. Olyan esetekben, amikor ezeknek a szolgáltatásoknak a monitorozására nem ad kielégítő megoldást egy passzív megfigyelő használata, a Nagios az indirekt monitorozást ajánlja.

14. ábraIndirekt monitorozás. A tűzfal átengedi az nrpe adatait. Az indirekt monitorozás lényege, hogy a megfigyelt szolgáltatás mellé telepített ágens végzi a szenzorok adatainak begyűjtését, és az továbbítja az adatokat a Nagios magnak. A távoli szenzorokat irányító ágens a Nagios által fejlesztett nrpe démont futtatja (0.4.1), mely továbbítja a központi mag (ágens) kéréseit a szenzoroknak, majd visszaadja az eredményeket a központnak. Természetesen az indirekt monitorozás alapfeltétele, hogy a zónákat védő tűzfalak átengedjék a Nagioshoz tartozó nrpe forgalmat, amit paranoiára hajlamos – más szóval alapos - rendszergazdák könnyen biztonsági résnek tarthatnak. Fontos kiegészítés, hogy az nrpe ágensek képesek akár láncként is funkcionálni. Így lehetővé válik, hogy több hálózaton utazzon keresztül segítségükkel az információ. 0.4.2 Szolgáltatás ellenőrzés párhuzamosítása A Nagios magja a szenzorok futtatását párhuzamos folyamatokban kezeli. A gyakorlatban ez azt jelenti, hogy amikor az időzítő egy szolgáltatás ellenőrzést kezdeményez, elindít egy önálló processzt, amely elindítja a szenzort, majd fogadja a tőle származó adatokat. Ez a módszer garantálja, hogy a fő processz ne várakozzon egy szenzorhívásnál, ami a szenzor megfigyelési idejének esetleges elnyúlása, vagy annak nem megbízható működése miatt is fontos. A párhuzamosításnak ez a minimális formája természetesen csak az adott hosztra korlátozódik, de a processzek függetlensége miatt mégis rugalmasabb rendszert eredményez. A szenzor processzek párhuzamos végrehajtása természetesen gondokat is okozhat, ha azok

37


Irodalomjegyzék

egyazon erőforráshoz szeretnének egy időben hozzáférni. Az ilyen korlátozott erőforrásokkal – például modem – kapcsolatos gondok megoldására a rendszer az alábbi lehetőségeket ajánlja: • növelhető a megfigyelések indításai közt eltelt idő • maximálható az egy időben futtatható megfigyelések száma • a szenzorok készítésénél mindig figyelembe veendő a párhuzamosítás esete • a megfigyelési kísérletek száma konfigurációs lehetőséggel elérhető, hogy a rendszer többször próbáljon megfigyelést végezni egy szolgáltatásról. Így esetleges ütközés után nem küld a rendszer azonnal figyelmeztetést, hanem újraindítja a szenzort. Fontos megjegyezni, hogy a rendszer kizárólag a megfigyelések kezelését párhuzamosítja. Az eseménykezelés, az időzítés, vagy a figyelmeztetések kiküldése nincs párhuzamosítva. 0.4.3 Osztott monitorozás A monitorozási feladatok megosztásának oka a Nagios rendszerben a terhelés megosztásának elérése. Amikor a rendszerrel több száz vagy esetenként több ezer hosztot – és azokon a szolgáltatások többszörösét - akar monitorozni egy hálózati adminisztrátor, akkor az olyan mértékű terheléshez vezethet a központi szerveren, mely megoldhatatlan lehet kisebb hardverbővítéssel.

15. ábraOsztott monitorozó rendszer Az osztott monitorozó rendszerben egy központi Nagios mag mellett több együttműködő mag dolgozik (0.4.3). Az együttműködő magok az adatokat a passzív monitorozásnál már megismert állományba küldik. Az adatok mozgatásáért a központi mag felé az ún. NSCA

38


Irodalomjegyzék

szolgáltatás felelős. Az együttműködő magok telepítésénél figyelembe kell venni, hogy azoknak csak minimális funkcionalitásra van szükségük, hiszen a munka nagy részét továbbra is a központi mag végzi. Ennek megfelelően egy tipikus együttműködő maghoz nem tartozik webes felület, riasztó rendszer, de még eseménykezelő keretrendszer sem. Az együttműködő mag egyetlen feladata, hogy szolgáltatás ellenőrzéseket hajtson végre, és azok eredményét továbbítsa a központi rendszernek. Ezzel szemben a központi mag ellátja a rendszer többi feladatát, de tipikus esetben maga nem is kapcsolódik szenzorokhoz. A központi mag feladata tehát, hogy a beérkező információkat elemezze, és elindítsa az esetlegesen szükséges cselekvéseket. Az információk aszinkron küldése a központi mag felé biztosítja, hogy ne kelljen az együttműködő magokra várni. Az osztott monitorozásnak egy komoly problémája lehet: amennyiben az együttműködő mag leáll, a hozzá tartozó szolgáltatások ellenőrzése is leáll, hiszen a központi mag nem végez monitorozást. Erre az esetre a Nagios frissesség ellenőrzési lehetőséget, és az ahhoz kapcsolódó automatizmust ajánlja. A központi mag rendszeresen ellenőrzi a bekerült adatok frissességét, és amennyiben elavultnak találja azokat – tehát az együttműködő rendszerrel valami baj van – saját hatáskörén belül aktív megfigyelésbe kezd. Egyszerűbb esetben megengedhető, hogy az aktív monitorozás megkezdése helyett a központi mag csak egy figyelmeztetést küldjön ki, mely után az együttműködő rendszer adminisztrátora újraindíthatja a szolgáltatást. 0.4.4 Redundáns, hibatűrő monitorozás A Nagios lehetőséget ad arra, hogy a központi monitorozó rendszer hibája esetén is tovább működhessen a rendszer. Ezt helyettesítő központ beállításával érhetjük el. A helyettesítő rendszer akkor lép működésbe, ha: • A központi magot futtató hoszt elérhetetlenné válik • A központi mag folyamat valamilyen okból leáll.

39


Irodalomjegyzék

16. ábraTöbbszörös monitorozás: A az elsődleges, C a másodlagos mag hosztja Redundáns monitorozás

Redundánsan felépített rendszer esetén a magokat futtatni képes folyamatok között egyértelmű sorrend van, mely meghatározza, hogy több működőképes mag esetén melyik lássa el a feladatokat (0.4.4). A redundáns rendszerekben az elsődleges mag nem is tud arról, hogy másodlagos mag futtatására is lehetőség van. A másodlagos mag az elsődlegessel megegyező monitorozási feladatok ellátása mellett figyeli a központi mag működését is. Amennyiben azt észleli, hogy az elsődleges mag leállt, átveszi annak feladatait, tehát a továbbiakban már nem csak monitorozást végez, hanem aktív feladatokat (figyelmeztetés, eseménykezelés) is. A másodlagos központ a feladatok átvétele után is folytatja az elsődleges központ megfigyelését, és amennyiben észleli annak visszatérését, leállítja aktív cselekedeteit. Ezzel a rendszer visszatér kezdeti állapotába. Hibatűrő monitorozás

A hibatűrő monitorozás alapvetően ugyanazt a logikát követi, mint a redundáns, egy különbséggel: amíg az elsődleges központ működik, a másodlagos megfigyeléseket sem végez. Ezen módszer használatát az indokolja, hogy a redundáns monitorozás esetén mindkét – de akár több – megfigyelő egy időben végez monitorozást ugyanazokon a szolgáltatásokon. Ez természetesen növeli a megfigyelt szolgáltatásokat futtató hosztok terheltségét, ami a mérések pontosságát is befolyásolhatja. A pontatlanságok abból adódnak, hogy a több, egyszerre végzett megfigyelés lefoglalhat annyi erőforrást a megfigyelt szolgáltatást futtató hoszton, hogy az erősen befolyásolja a mérést. Hibatűrő monitorozás esetén a másodlagos központ normális működés esetén csak az

40


Irodalomjegyzék

elsődleges központ ellenőrzését végzi, ezzel elkerülve a megfigyelt szolgáltatásokat futtató környezetek terhelését. 0.4.5 Összefoglalás A feladatok megosztása több megfigyelő között a Nagios rendszerben a terhelés megosztására, a robusztusság és a skálázhatóság növelésére szolgál. Ezeket a tulajdonságokat a rendszerben megvalósított kiegészítések javítják ugyan, de nem érik el egy alapvetően osztott szemléletű rendszer rugalmasságát. A kitűzött feladatmegosztás csak félig sikeres, hiszen a rendszer központosítottsága nem változik. Adott időpillanatban mindig van egy központ, amely a teljes rendszer ellenőrzéséért felel. Ez a központ a feladatok egy részének kihelyezése után is a rendszer szűk keresztmetszete lehet. Ha a központ számára dedikált folyamatok mennyisége, vagy a központ és a többi rész közötti kommunikáció mérete túllép az ellátható mennyiségen, a rendszer óhatatlanul lelassul. Az osztott rendszer emellett nem használja ki hatékonyan a több megfigyelő alkalmazásából adódó előnyöket. A multi-ágens rendszereknél fontos tulajdonság, a több nézőpontból végezhető megfigyelések lehetősége nincs a rendszerben kiemelve. Ha a rendszer fejlesztői nem ragaszkodnának a központ megfigyelő nézőpontjához, akkor a több nézőpontból gyűjtött adatok összessége jóval pontosabb képet festene a szolgáltatások állapotáról.

41


Irodalomjegyzék

MAHD: egy multi-ágens alapú hálózat-diagnosztikai rendszer

0.5 Bevezetés A fejezet célja egy hálózat-diagnosztikai képességekkel ellátott multi-ágens rendszer tervének bemutatása. A fejezetben elsőként ismertetem a célokat és a környezetet, amiben a rendszernek működnie kell. Ezek után a rendszer egységei, az ágensek kerülnek kidolgozásra, majd a multi-ágens rendszer, melyet együttesen alkotnak. A rendszerre a MAHD rövidítéssel hivatkozom mely a multi-ágens és hálózat-diagnosztika kifejezések szavainak kezdőbetűire utal. Az ágensek és a multi-ágens rendszer tervezésekor a cél az, hogy a rendszer csak annyira legyen hálózat-diagnosztizálásra optimalizálva, amennyiben az befolyásolja a tulajdonságokat. A fejezet végén kerül ismertetésre, hogy a megismert architektúra hogyan tudja megoldani a feladatot. A fejezetben található specifikáció, nem tér ki az implementáció pontos részleteire. A specifikáció nem tér ki olyan gyakorlati részletekre, mint például a programnyelv választása. A megvalósított ágensek készülhetnek tetszőleges eszközökkel, ha megfelelnek ennek a specifikációnak. Így egy vegyes hálózat hosztjain az egyes hosztokon a legtesthezállóbb eszközöket lehet használni. A specifikáció célkitűzése, hogy az alapján olyan ágenseket lehessen létrehozni, melyek képesek a tervnek megfelelő együttműködésre. A fejezetben található információk elegendő megszorítást adnak az implementációhoz, hogy az eredményül kapott rendszer az ismertetett módon viselkedjen. A leírásban az első fejezetekben megismert ágensekkel, multi-ágensekkel és hálózatdiagnosztikával kapcsolatos fogalmakat használom. A fejezetben elsődleges az ágensekkel kapcsolatos szóhasználat, tehát ha egy ott megismert fogalmat használnak a hálózatdiagnosztikában is, akkor az ágenseknél megismert jelentéstartalom dominál. Az ettől való eltéréseket feltüntetem.

0.6 Célok A MAHD architektúra célja, hogy egy multi-ágens alapon szerveződő rendszer segítségével hatékony hálózat-diagnosztizálást valósítson meg. A rendszernek képesnek kell lennie arra, hogy benne megvalósíthatóak legyenek a központosított és osztott rendszereknél megismert képességek. Emellett elvárás, hogy több nézőpontból is lehetővé váljanak a megfigyelések, robusztusabb rendszer jöjjön létre, és a feladatok megosztásával kevésbé legyen terhelt a megfigyelt hálózat. A rendszerrel kapcsolatban az alábbi részletesebb elvárásokat gyűjtöttem össze: Robusztusság. A rendszer folyamatos működése legyen garantálva kisebb hibák vagy támadások esetén is, méghozzá minimális emberi beavatkozás mellett.

42


Skálázhatóság, Rugalmasság.

Irodalomjegyzék

Nagyobb számú feladat kezelése esetén is működőképes maradjon a rendszer. Ne kelljen struktúrát változtatni új feladatok kiosztásakor, vagy feladat változásakor.

A rendszer részeinek és egészének képesnek kell egy esetleges leállás Hibatűrés, vagy információ-vesztés után is működni. Egy vagy esetleg több Kegyelmes halál ágens tudatos leállítása vagy megtámadása a lehető legkisebb tulajdonság. veszteséget okozza. Megfigyelések több szemszögből Dinamikus feladatelosztás, a megfigyelés tárgyának minimális terhelése. Kommunikációs költségek minimalizálása.

A monitorozást végző szenzorok használják ki, hogy több megfigyelő van a rendszerben, és ezzel pontosabb képet kaphatnak a működésről. A rendszer számára kiosztott vagy a működés során keletkezett feladatokat az ágensek osszák szét maguk között minél egyenletesebben. Ezzel elősegítik azt, hogy az ágenseket futtató hosztokon, illetve a hálózaton minél kisebb és minél egyenletesebb terhelést okozzanak. Így hatékonyabban csökkenthető az effektus, amikor a mérőműszer a mérés tárgyát befolyásolja. A hálózat megfigyelése közben természetes követelmény, hogy a rendszer minél kevésbé terhelje a hálózatot. Emellett a MAS-ok jellemző hibája, hogy a feladatokat magas kommunikációs költséggel oldják meg, így ennek kikerülésére érdemes fokozottan figyelni.

0.7 Környezet A tervezés egyik fontos lépése annak megvizsgálása, hogy milyen környezetben kell működnie a rendszernek (0.7).

17. ábraÁgensek és környezetük A fejezetben a környezet kifejezés az ágens teljes környezetére vonatkozik. Ebbe 43


Irodalomjegyzék

beletartoznak a megfigyelt szolgáltatások, hosztok, de a környezet fennmaradó része, tehát a többi ágens, illetve a hálózat egésze is. A megfigyelt hálózatokkal és a futtató környezettel kapcsolatban az alábbi tulajdonságok befolyásolják a tervezést: Nem-hozzáférhető A környezet nem hozzáférhető, mert az ágens nem képes minden, a döntéseihez fontos információ észlelésére. Bizonyos információkkal csak a többi ágens rendelkezik, vagy rejtve maradnak a környezetben. Az sem várható el, hogy minden ágens minden információt megosszon a többivel a kommunikáció magas költsége miatt. Nem-determinisztikus A környezet nem determinisztikus, hiszen következő állapotát jelenlegi állapotán és az ágens cselekvésein kívül sok tényező befolyásolja. Ilyen lehet egy másik ágens cselekvése, vagy egy, az ágens által nem érzékelt entitás. Nem epizódszerű A hálózatos környezet nem epizódszerű, hiszen a benne zajló folyamatok időintervallumok határain keresztül is hatnak egymásra. Léteznek viszont részfolyamatok a hálózatban, melyek epizódszerűen viselkednek. Ezt a tulajdonságot a következtetésekkor ki lehet használni. Dinamikus A környezet változhat, amíg az ágens a következtetési folyamatát végzi, tehát a környezet dinamikus. Változást például másik ágens is előidézhet. Diszkrét Az ágens által megfigyelt objektumok száma (szolgáltatások, hosztok, ágensek, hálózat részei) és azok figyelembe veendő (az ágens számára információval bíró) állapotainak a száma is megszámlálható, tehát a környezet diszkrét tulajdonságú. Bár a környezet diszkrét, a célok között kitűzött bővíthetőség azt eredményezheti, hogy a megfigyelt környezet akár nagyságrendekkel is megnőhet, így a terv nem alapozhat a környezet méretének – vagy annak nagyságrendjének – állandóságára.

0.8 Az ágens Az ágensek tervezésekor arra kell koncentrálni, hogy multi-ágens rendszer részeként fognak működni. Az együttműködésre alkalmas ágensnek csoportközpontúnak kell lennie. A csoportközpontúság természetes tulajdonsága a MAHD rendszernek, hiszen a megfigyeléseket és az egyéb feladatokat is közösen végzik az ágensek. A közös munka miatt az ágens tervezésekor a nyitott és együttműködő tulajdonságokat is szem előtt kell tartani. A rendszer célkitűzései között szereplő rugalmasság és skálázhatóság azt követeli meg, hogy a környezet változásakor a rendszer – és alkotói az ágensek – képesek legyenek alkalmazkodni az új helyzethez. Az autonómia növelése olyan rugalmas felépítést sugall, melyben a beépített tudás nem gátolja az alkalmazkodást, és így a megfigyelésekkel létrejövő tudásbázis kihasználható. Az ágenseknél megismert definíció szerint egy ágenst olyan mértékben nevezünk autonómnak, amennyire cselekvései az általa szerzett

44


Irodalomjegyzék

tapasztalatokra épülnek. Ez az autonómia-fogalom a környezethez való alkalmazkodás fokát jellemzi, és azt sugallja, hogy az ágensek a beléjük épített tudás mellett nagy hangsúlyt fektessenek megszerzett információikra, és az abból következő tudásra. Az alapvető tulajdonságok mellett most részletesebben áttekintem az ágensek felépítését és képességeit. 0.8.1 Felépítés Teljes Modularitás

Az ágensek rugalmas felépítése megköveteli a moduláris felépítést. Ennek okai: • Bővíthető legyen új tulajdonságokkal, modulokkal, lehetőleg zökkenőmentesen. • Az egyforma ágens-maggal rendelkező ágenseket lehessen használni különböző célokra. • Ne kelljen minden ágensnek minden képességet tartalmaznia. Ez nem is lenne reális célkitűzés a hosztokon lévő eltérő környezetek miatt. • Az ágens részeit akár részenként is lehessen frissíteni.

18. ábraMAHD ágens A moduláris felépítés konzekvens használata nagyfokú rugalmassággal ruházza fel a rendszert. A modularitás nem csak a szenzorok és más külső programok beágyazhatóságára, hanem az ágens alapvető részeire is vonatkozik. Ezek az alapvető modulok az alábbiak (0.8.1): • Ágensmag Ez a modul minden ágensben megtalálható. Az ágensmag tartalmazza az időzítési képességekhez szükséges osztályokat. Nélkülözhetetlen, hiszen az időzítő nélkül az 45


Irodalomjegyzék

ágens nem lenne képes feladatai ütemezésére. • Kommunikációs modul A kommunikációs képességek nélkül az ágens nem képes kapcsolattartásra, így ez a modul is helyet kap minden ágensben. • Szenzorkezelő Ez a modul felel a környezetet figyelő szenzorok kezeléséért. • Eseménykezelő Ez a modul felel a hálózat-diagnosztikai események kezeléséért. • Figyelmeztetés-kezelő rendszer Ez a modul képes üzeneteket küldeni a szolgáltatások kapcsolattartóinak. Emellett az ágens külső modulokkal is el lehet látva, ezek közül a legfontosabbak: • Felhasználói felület, statisztikai modul Lehetőséget adnak a rendszer beállításaira, illetve a gyűjtött adatok megtekintésére. • Szenzorok A Nagiosnál megismert hálózatdiagnosztikai szenzorok. Külső programként való kezelésük itt is a bővíthetőséget célozza. Prioritás

Az ágensek prioritással rendelkeznek. Ez a tulajdonságuk arra alkalmas, hogy együttműködés során a MAHD rendszer feloldja a vitás helyzeteket. A döntés a magasabb prioritású ágensnek kedvez, melyet a másik ágens automatikusan elfogad. A prioritás emellett az ágensek kommunikációs hálózatának kialakításakor is szervező tényező (0.9.2). Befolyásolhatja, hogy az információk milyen úton terjednek az ágens hálózatban (0.10). Csoportok

Az ágens tulajdonságainak ismeretében fogja a többi ágens eldönteni, hogy milyen információkra van szüksége, illetve, hogy milyen feladatokat oszthat rá. Például egy olyan ágens, amely nem rendelkezik figyelmeztetés-kezelő modullal, kioszthatja a feladatot egy ilyen képességgel (modullal) rendelkező ágensnek. Az ágensek tulajdonságaik alapján, illetve mesterségesen csoportokba sorolhatóak. A csoportok meghatározása az adminisztrátor számára teszi átláthatóbbá a rendszert, mert nem kell a képességek szintjén definiált részletes tulajdonságokkal dolgoznia. Például, ha a MAHD által gyűjtött adatokra kiváncsi, akkor egy speciális ágenssel megkeresheti az egyik aktív, felhasználói felülettel rendelkező ágenst. A mesterségesen kialakított csoportok segítségével az adminisztrátor osztályozhatja az ágenseket, mely nagyszámú ágens esetén könnyíti meg a feladatát. Ilyen csoport lehet például az idegen adminisztrátor által kezelt ágenseké, mely csoportnak a későbbiekben például lehet csökkenteni a prioritását, vagy a saját ágensek egyikével időszakosan ellenőriztetni lehet a tőlük kapott eredményeket. Az ágensmag felépítése

Az ágensmag felépítésének kiválasztásakor a robusztusság és a rugalmasság közti egyensúly kialakítása a cél. Talán kézenfekvő lenne a legösszetettebb és így legrugalmasabb szerkezetet választani ágensmagnak, de multi-ágens rendszer építésekor nem feltétlenül ez

46


Irodalomjegyzék

a legjobb választás. Egy MAS-ban az intelligens működést nem kizárólag az ágensek, hanem a teljes rendszer együttes működése garantálja. Emellett egy összetett alkotóelemekből álló rendszer könnyen ellenőrizhetetlenné, működése pedig érthetetlenné válhat. A rendszer tervezésekor a belső állapottal rendelkező ágens architektúrát választottam ágens-mag felépítésnek. Ez egyrészt alkalmas arra, hogy a korábbi észlelési sorozat alapján belső reprezentációt készítsen a környezetről, másrészt felépítése elég egyszerű ahhoz, hogy a teljes rendszer viselkedése átlátható maradjon. A környezet belső reprezentációja kiemelt fontosságú a feladatban, hiszen az ágensnek akkor is tudnia kell a megfigyelt szolgáltatásokról, vagy a többi ágensről, amikor éppen nem éri el azokat. A belső állapottal rendelkező ágens a környezet egy belső leírását kezeli magában, és azt képes frissíteni olyan szabályok alapján, melyek a nem észlelt események kikövetkeztetésére alkalmasak. Ilyen információ lehet az ágens saját cselekedeteinek következménye, vagy egy előző észlelés alapján hozott következtetés. A cselekvéseket az ágens ítéletlogikai következtetéssel választhatja ki (0.16:220). Az ágens által a környezetről tárolt információk természetesen nem csak a szolgáltatás és hoszt megfigyelésekre vonatkoznak, hanem önmagára, a hálózatra és a MAHD többi ágensére is. Az ágens a belső állapottal rendelkező ágens leírásánál (8. o) megismert lépéseket ismétli, természetesen elvégezve a hálózat-diagnosztikai és a többi ágenssel való kapcsolattartási feladatokat is (0.8.1): • belső állapot frissítése az észlelések alapján Az észlelések származhatnak saját forrásból, ha az ágens rendelkezik szenzorokkal, illetve a többi ágens megfigyeléseiből melyeket megosztottak vele. • szabály illesztés a belső állapot alapján A szabályok természetesen vonatkoznak a megfigyelt szolgáltatásokra, illetve a környezet többi részére is. • cselekvés a szabály illesztés alapján Az eseménykezelő modul aktiválása, hogyha rendelkezik ilyennel az ágens, illetve információcsere a többi ágenssel. • belső állapot frissítése a cselekvés alapján A végrehajtott események alapján, illetve a többi ágenstől visszakapott információk alapján történik a frissítés.

47


Irodalomjegyzék

19. ábraMAHD Ágens részletes felépítése 0.8.2 Tanulás Az ágensek két módon képesek a tanulásra: a többi ágenstől, illetve az adminisztrátortól fogadhatnak új tényeket, illetve megfigyeléseik alapján rögzíthetik azokat. Az ágensek belső tanulási képessége nem terjed ki szabályok létrehozására. Ennek oka, hogy a feladat megvalósításához nem az ágensek, hanem a teljes rendszer viselkedése kell, hogy megfelelően komplex és rugalmas legyen, továbbá az a törekvés, hogy a rendszer átlátható maradjon. A tanulás folyamán az ágens tényeket rögzít, melyeket más ágens számára elküldve, azok ellenőrzésre kerülnek. Ilyen tény lehet például, hogy új ágens kapcsolódott be a rendszerbe, vagy, hogy valamelyik szolgáltatás állapota kritikusra változott. Üzenetazonosító 1 2 3

Küldő Címzett Üzenet A A B

B uj_agens,név=C,prioritás=100,cím=192.168.1.111,port=222 B üzenet ellenőrzés kérése,1 A Üzenet válasz, 2, igaz 8. táblázat Tanulás új információ továbbadásával

A fenti példában (0.8.2) az A ágens tudatja a B ágenssel, hogy új ágens kapcsolódott a rendszerbe, és kéri, hogy ellenőrizze az új ágenssel kapcsolatos, általa átadott információkat. A rendszer adminisztrátorának lehetősége van arra, hogy új feltételes szabályokat illesszen a rendszerbe. Ezeket a szabályokat a felhasználói felület segítségével lehet a rendszerrel

48


Irodalomjegyzék

közölni. A felhasználói felülettel kapcsolatban álló ágens ezek után az új szabályt továbbküldi a többi ágensnek. 0.8.3 Az ágens tudása Az egységes működési elvű ágenseket az különbözteti meg egymástól, hogy milyen képességeik vannak, illetve, hogy milyen információkkal rendelkeznek a környezetről. Az ágens tudásához saját képességeinek ismerete is hozzátartozik. Az ágens által tárolt legfontosabb információk az alábbi csoportokba oszthatóak: • Saját jellemzők Tartalmazza az ágens moduljait, azok verziószámait. • Hálózat jellemzői A hálózat felépítése, hosztok, forgalomirányítók, kapcsolatok. • Ágenslista Önmaga és a többi ágens publikus információi. Minden ágensnek ismernie kell a többi elérhetőségeit és képességeit. • Feladatok listája Azon feladatok listája melyeket az ágenseknek el kell látnia. Ezek között lehetnek időszakosan ismétlődő feladatok és egyszeriek is. Ezeket a feladatokat fogja az ágensmagban lévő időzítő prioritásaik alapján sorbarendezni végrehajtásra. Fontos, hogy az ágens ismerheti több ágens, vagy akár minden ágens feladatait, hogy annak leállása után átvehesse őket. • Megfigyelések listája Tartalmazza az ágens információit a megfigyelt szolgáltatásokról. A megfigyelések között fontosabbak a hibákhoz kapcsolódó megfigyeléseknek, ezeket inkább kell ismernie a többi ágensnek. Az ágens által tárolt információkhoz olyan mérték van rendelve, amely leírja, hogy azt mennyire fontos bizonyos ágensekkel, vagy az adminisztrátorral megosztania. Ez a mérték az információ prioritása, mely minden információra és minden ágensre meg van adva. Az információ-prioritás természetes szám a 0-1000 intervallumból, tárolása minden ágensben egy tömbben kerül megvalósításra (0.8.3). A tömb az információ azonosítójával (amelyre vonatkozik), és az ágenssel (melynek az információ a prioritásnak megfelelően küldendő) címezhető. A prioritás kezelésekor lehetőség van ágensek csoportjaira és így akár az összes ágensre egységes prioritás kiosztására, de ’személyre szabott’ prioritás megadására is. Az információkhoz tartozó prioritási tömböt minden ágens önállóan kezeli. Ennek célja, hogy ágensek dönthessenek a megosztott információkról. Így például egy kisebb sávszélességgel rendelkező ágens csökkentheti bizonyos információk prioritását, és így csökkentheti továbbításuk sűrűségét.

Uj_agens(D) Meresi_feladat(meres_1,ping, hoszt(10.1.1.1)) 49

A ágens 1000 100

B ágens 1000 10

C ágens 1000 10


Irodalomjegyzék

A ágens Meresi_feladat(meres_2,processzorhőmérséklet) 0 Meresi_eredmeny(meres_1, datum_1, 111, 10 msec) Meresi_eredmeny(meres_2, datum_1, 45, 1 celsius) 9. táblázat Információ-prioritások

B ágens 100 1

C ágens 0 1

10

1

Vannak a rendszernek olyan adatai, amelyek rögzített prioritásúak (például az ágenslistával kapcsolatos információk). Ezek azok az adatok, melyek garantálják az elvárt működést, és csak az adminisztrátor változtathatja ezek körét. Van az adatoknak egy köre melyet nem minden ágenssel ugyanolyan hasznos megosztani. Ilyenek például a mérési feladatok, illetve a mérési feladatokhoz tartozó eredmények. A mérési feladatokat érdemes minimum egy ágensnek eljuttatni, hogy hiba esetén az az ágens átvehesse a feladatot (vagy kioszthassa azt másnak). A mérési eredményeket is érdemes megosztani azzal az ágenssel, aki hiba esetén átveszi a mérés ellátását, így az zavartalanul folytathatja a mérést tovább. Természetesen a prioritásokban ki kell fejeződnie annak, hogy mely információ mennyire fontos a rendszer működése szempontjából. Például a mérési eredmények jellemzően alacsonyabb prioritásúak a mérési feladatok specifikációjánál. 0.8.4 Kommunikáció Az ágensek közti kommunikáció szabványos ágens kommunikációs nyelven zajlik (például: 0.8.4), hogy a rendszer nyílt tulajdonságú legyen. A nyílt tulajdonság segíti, hogy több fejlesztő, akár különböző eszközökkel is fejleszthessen ágenseket. A rendszer nyelve a KQML, melynek elterjedtsége garantálja, hogy külső rendszerekkel való összekapcsolás esetén se okozzon gondot a nyelv ismerete, vagy annak dokumentálatlansága. Az ágensek közti kommunikáció titkosított csatornán zajlik, hiszen tartalmazhat bizalmas információkat. ÜzenetKüldő Címzett Üzenet azonosító 1 A B (inform ((uj_agens x) (=(nev x) C) (=(pri x) 100) (=(addr x) 192.168.1.111) (=(port x) 222))) 2 A B (ask-if (uzenet_helyes 1)) 3 B A (reply true) 10. táblázat Példa KQML üzenetváltásra A például választott üzenetváltás a tanulásnál megismert üzenet (0.8.2) KQML nyelű implementációja. A MAHD rendszer által lefoglalt kifejezések a fenti üzenetben: • uzenet_helyes: információ ellenőrzés kérése a üzenetazonosítóra. • uj_agens: új ágens érkezett a rendszerbe. • nev: objektum-azonosító

50

paraméterként

átadott


• • •

Irodalomjegyzék

pri: prioritás addr: hálózaton elérhető szolgáltatás IP címe port: hálózaton elérhető szolgáltatás portja

Természetesen az üzenetek értelmezéséhez a KQML szintaktikájának ismeretén kívül szükséges a rendszer által foglalt kifejezéseinek ismerete is. Mivel nem szükséges minden foglalt szó ismertetése a rendszer folyamatainak tervezéséhez, ezért csak a fenti példákat ismertetem.

0.9 A multi-ágens rendszer Ebben a részben arról lesz szó, hogy az ismertetett ágensek hogyan állnak össze az egységes MAHD multi-ágens rendszerré. Ehhez be kell mutatni, hogy milyen elv szerint szerveződnek, hogyan osztják szét feladataikat és hogyan kommunikálnak. Természetesen a rendszerrel kapcsolatos célkitűzések és az ágensek már megismert tulajdonságai meghatározzák a rendszer néhány tulajdonságát. Így már most lehet tudni, hogy heterogén multi-ágens rendszerről van szó, lévén, hogy az ágensek nem egyformák, és hogy az ágensek szabványos ACL üzenetekben kommunikálnak egymással. A MAS tervezésekor is igyekeztem szétválasztani az általános funkciókat és a feladattal kapcsolatos speciális funkciókat. Ennek megfelelően a hálózat-diagnosztizálással kapcsolatos leírás a fejezet végén található, és építkezik az előtte bemutatott általános felépítésre. 0.9.1 Feladatok kiosztása A MAHD tervezésének egyik fő célkitűzése volt, hogy a feladatokat az ágensek elosszák egymás között, minél egyenletesebben és automatikusan. Az egyenletes feladatelosztás azért fontos, hogy a rendszer ne terhelje az őt futtató erőforrások egyikét sem, legyen az hoszthoz kapcsolódó vagy hálózati erőforrás. Az automatikus feladatelosztás a feladatok és az ágensek nagy száma mellett azért is fontos, mert segít megőrizni az egyenletes feladatmegosztást. Az ágensek folyamatosan nyilvántartják, és figyelik saját erőforrásaikat, feladataikat, majd amennyiben túlterheltekké válnak, a feladatok egy részét megpróbálják más ágenseknek átadni. A feladatok könnyű átruházása például arra is lehetőséget ad, hogy egy tervezett ágens leállítás esetén annak feladatait a többi ágens átvegye. A feladatok kiosztása és az együttműködés a multi-ágens rendszerben a Vállalkozási Háló módszer alapján történik. A módszer előnye, hogy egyszerű, átlátható és emellett támogatja a feladatok részfeladatokra való felosztását. Alapvetően együttműködő stratégiájú ágensek használhatják sikeresen, amely tulajdonság a rendszerben biztosított. A protokoll lépései: • Feladat felismerése és specifikálása. Az ágens eldönti, hogy fel kell-e osztani a feladatot részfeladatokra, vagy pedig az egyben végrehajtható. A feladat esetleges felosztása után az ágens eldönti, hogy képes-e hatékonyan végrehajtani egyedül a feladatot, vagy részfeladatokat. • Feladat kihirdetése. Az ágens kihirdeti a specifikált feladatot (vagy részfeladatot), határidőt. A hirdetményt csak azoknak az ágenseknek küldi el, akik ismeretei szerint 51


•

• •

Irodalomjegyzék

képesek végrehajtani a feladatot. Ajánlattételek. A kihirdető ágens fogadja az ajánlatokat, azon ágensektől, akik képesnek hiszik magukat a végrehajtásra. Az ajánlatok természetes számok, melyek egy 0 és konfigurálható felső korlát közötti intervallumából kerülnek ki. Ha egy ágens mégsem képes ajánlatot tenni, azt egy extremális érték (-1) küldésével tudatja a kihirdetővel. Az ajánlat elkészítésekor az ágens azt vizsgálja meg, hogy a feladathoz szükséges erőforrásai mennyire vannak leterhelve, minél kevésbé, annál jobb ajánlatot tesz. Feladat elnyerése. A legjobb ajánlat nyer. Végrehajtás. A végrehajtás során a feladat további részekre bontható. A végrehajtás után jelentést kell küldeni a megbízónak.

20. ábraVállalkozási Háló módszer feladat elosztó módszere Példa Vállalkozási háló alapú feladatmegosztásra (0.9.1): • Feladat felismerése és specifikálása. Az A ágens felismeri, hogy az adminisztrátor új megfigyelési feladatot rótt rá, a feladat egy alhálózat sebességének mérése. A feladat specifikációjának ismeretében A ágens

52


Irodalomjegyzék

észleli, hogy a feladatot nem lehet több részre osztani. Mivel az A ágens nem a megfelelő alhálózatban van, a feladatot ki kell hirdetnie. • Feladat kihirdetése. A ágens kihirdeti a feladatot azoknak az ágenseknek, melyek ágenslistájának adatai alapján alkalmasak annak elvégzésére. Ezek a B, C, D ágensek, melyek a megfigyelendő hálózatban helyezkednek el. • Ajánlattételek. A B: 111 és C: 88 ajánlatok érkeznek be az A ágenshez, mivel ezen ágensek terhelése megengedi, hogy elvállalják a feladatot. Mivel a D ágens nem rendelkezik szabad erőforrással, ezért a -1 extremális értéket küld vissza A-nak. • Feladat elnyerése. A B ágens által adott érték a legmagasabb, így ő nyeri el a feladatot. • Végrehajtás. B ágens nekilát az alhálózat sebességének méréséhez. 0.9.2 Hierarchia A multi-ágens rendszerek tervezésének sarkalatos kérdése, hogy az ágensek milyen hierarchiába vannak szervezve. A hierarchia szerepet játszik abban, hogy milyen módon jutnak el információk az ágensekhez, és szerepe lehet döntéseik meghozatalakor is. A rendszer célkitűzései közül a hierarchiát, illetve annak kialakítását befolyásolja a rugalmasságra, a skálázhatóságra, a robusztusságra, a hibatűrésre és a kommunikációs költségek minimalizálására való törekvés is. Ennek oka, hogy a kommunikáció jó része ezen a hierarchián keresztül zajlik, így megléte, illetve a gyors újraszervezésére való lehetőség rendkívül fontos. A hierarchiát egy topológia határozza meg, mely egy gráf, melynek csúcspontjai az ágensek, élei pedig a hierarchikus kapcsolatok az ágensek között. A topológia

A célkitűzések kizárják azt, hogy az ágensek között egy fix hierarchikus rendszert alakítsunk ki, hiszen sérülékeny lenne a meghibásodásokra. Tehát dinamikus hierarchiát kell választanunk, mely könnyen újraszervezi önmagát. A kommunikációs költségek minimalizálására és a feladatmegosztás kiegyenlítésére, valamint a feladatmegosztás hatékonyságára való törekvésből több dolog is következik, melyek ellentmondanak egymásnak. Egyrészt szeretnénk, ha a nagyobb kommunikációs erőforrással (sávszélességgel) rendelkező ágensek több ágenssel lennének kapcsolatban, hogy jobban kihasználják erőforrásukat, másrészt szeretnénk egy jól szervezett topológiát kialakítani, amely körmentes, összefüggő (minden ágens részt vesz) és csomópontjainak nagyjából ugyanannyi kapcsolata van, hogy a feladatok egyenletesen oszoljanak el. A két szempont közti egyensúly megtalálása a cél. Az első szempontnak megfelelő topológiában a nagy sávszélességgel rendelkező ágensek sok kapcsolattal bírnak, a másik szempont szerint egy k-ad fokú fát alakítanánk ki. A szempontokat összefoglalva egy olyan dinamikusan létrehozható topológia lehet az optimális, mely fa szerkezetű, és benne a csúcsokhoz tartozó élek számát a csúcs sávszélessége határozza meg. A modellben a csúcsok természetesen az ágensek, az élek pedig a szomszédos ágensekhez való kapcsolódást reprezentálják. Ez a fa struktúra megfelelő arra is, hogy az információk terjedésének hálózata legyen. Az információk egy részét az ágensek nem közvetlenül eljuttatják egymáshoz, hanem átadják a

53


Irodalomjegyzék

fa gyökerében lévő ágensnek, aki azt továbbadja leszármazottjainak, és azok is továbbadják leszármazottjaiknak. Ennek az információterjedésnek az az előnye, hogy ha minden csúcsra igaz, hogy csak kisebb prioritású leszármazottjai vannak, akkor az adatok a prioritásnak nagyjából megfelelő sorrendben haladhatnak lefelé a fán. Ez nem jelenti azt, hogy minden kommunikáció ezen az úton terjed majd a rendszerben (ld.:0.10), de ez a mód megfelel azokban az esetekben, amikor minden ágens számára el szeretnénk juttatni egy információt. A prioritási sorrenddel összekapcsolt hierarchiában való kommunikációnak vannak olyan tulajdonságai, melyeket kihasználhatunk egy probléma megoldására: • Tudhatjuk, hogy kik kapják meg leggyorsabban az információkat. • Tudhatjuk, hogy kik kapják meg a legnagyobb eséllyel az információkat. • A fa aktuális csúcsán ellenőrizhetjük az információkat. Ha sok információt kell ellenőrizni, akkor az ellenőrzési feladatot meg lehet osztani több ágens között, hogy ne okozzon üvegnyak effektust. A fenti tulajdonságok ismeretében egy konkrét MAHD rendszer prioritásainak meghatározásakor előnyös tulajdonságokat programozhatunk a rendszerbe. A tervezett hierarchia teljesíti elvárásainkat, hiszen dinamikus, tehát skálázható és rugalmas. A fa minden csúcsán optimális a terheltség, illetve túlterheltség esetén részleteiben is újraszervezhető a struktúra. A fa gyökere kiemelt szerepet tölt be ugyan, de ez nem jár nagyobb terheltséggel, illetve meghibásodás esetén újraszervezhető a struktúra. Bár első látásra úgy tűnik, hogy a fa gyökere terheltebb a többi csúcsnál, de jobban megvizsgálva a fa minden csúcsán – a gyökéren is – csak egyszer haladnak át az információk, kivétel az információ küldőjét, ahol kétszer (ld.:0.10). Mivel az információ küldője normális esetben ugyanakkora eséllyel lehet minden ágens, így a terhelés átlagosan ugyanakkora minden csúcson. Topológia létrehozása

Hogyan lehet a fent vázolt topológiát hatékonyan létrehozni? Mivel dinamikus szerkezetre van szükség, ezért nem lehet abból kiindulni, hogy az ágensek egy időben alakítják ki a topológiát (hiszen a kész rendszerbe is csatlakozhat ágens, annak újraépítése nélkül), vagy abból, hogy az már nem fog változni (hiszen elérhetetlenné válhat valamelyik ágens). Emellett természetesen fontos hogy: a hierarchia létrehozása hatékony legyen, és minden időpillanatban egyértelmű legyen, hogy melyik ágensnek mi a feladata. Megoldásnak a rendszerben meglévő Vállalkozási Háló módszer felhasználása megfelelőnek tűnik. A struktúra létrehozását mindig az aktuálisan legmagasabb prioritású szabad (topológiában még nem szereplő) ágens kezdeményezi. Ehhez az ágensek rendelkeznek minden tudással, hiszen tárolják az ágenslistát, a prioritásokkal. Az algoritmus (0.9.2, 0.9.2) minden lépésében ez az ágens találja meg szülőjét. Mindezt a szülő-feladat kihirdetésével teszi. A szülő-feladat a Vállalkozási Háló módszer egy szabványos feladata, melynek célja eldönteni, hogy a topológiában ki kerüljön a meghirdető ágens fölé. A meghirdető ágens melyre természetesen csak az alkalmas ágenseket hívja meg, melyet az ágens-listájában tárolt szülő-gyermek kapcsolatok alapján keres ki.

54


Irodalomjegyzék

eljárás: Hierarchia-építése eljárás () Ha Legnagyobb szabad ágens() == önmaga.id Akkor szülőid = Szülő keresése(); Egyébként Semmi;

Ez az eljárás szülőt keres a legmagasabb prioritású ágensnek

függvény: Legnagyobb szabad ágens () maxid=null; maxpr=-1; Minden ágensre Ha ágens.szülő=null és ágens.pri>maxpr; Maxpr=ágens.pr; Maxid=ágens.id; Visszatérés(maxid);

A függvény kikeresi a szabad ágensek közül a legmagasabb prioritásút.

eljárás: Szülő keresése() szülőid=tömb()(); szülőszám=0; maxajánlat=-1; maxajánlatid=önmaga.id; Minden ágensre Ha ágens.szülő!=null és ágens.pr>önmaga.pri; szülőid[szülőszám][0]=ágens.id; szülőid[szülőszám][1]=ágens.gyerekszám; szülőszam=szülőszám+1; szülőid=Sorbarendez(szülőid, 1); i=0 tól k-ig ajánlat = ajánlatkérés(szülőid[i],szülő(önmaga)) ha maxajánlat < ajánlat maxajánlat = ajánlat; maxajánlatid = szülőid[i];

Az eljárás szülőt keres egy ágensnek. Megkeresi azokat, akik már szerepelnek a topológiában, majd azok közül meghívja a k legkevesebb gyerekkel rendelkezőket ajánlattételre. A legjobb ajánlat lesz a szülője az ágensnek. Fontos, hogy ha nincs még gyerekkel rendelkező ágens, akkor önmagát adja vissza az eljárás az ágensnek.

visszatérés(maxajánlatid);

11. táblázat Hierarchia építése eljárás Megjegyzések az algoritmussal kapcsolatban: • Az ágensek által tárolt ágenslista tartalmazza a szülőkre vonatkozó aktuális információkat, így az ágensek ismerik az aktuális topológiát. • Az algoritmus önszerveződő módon aktiválódik, tehát nem egy központ osztja ki a szerepeket, hanem a legmagasabb prioritású szabad ágensben aktiválódik az algoritmus. • A k érték azért szükséges, hogy az algoritmus ne terhelje az összes ágenst. Az algoritmus csak az első k legkevesebb gyermekkel rendelkező ágenstől kér ajánlatot. Az értékek az algoritmus hangolására szolgálnak. Minél nagyobb lesz a meghívottak köre, annál jobban közelíti a topológia az optimálisat. Ellenben minél kisebb, annál kisebb terhelést okoz és annál gyorsabb. • Az algoritmus kisebb átalakításokkal párhuzamosítható. Ezt a tulajdonságát nagyon gyorsan változó környezetekben érdemes kihasználni.

55


Irodalomjegyzék

21. ábraHierarchia épülése A fenti példán (0.9.2) látható, hogy hogyan épül fel a topológia a gyakorlatban. Minden egyes él felépítéséhez a rendszer a hierarchia építés eljárást használja, pontosabban azt aktiválja az időzítő modul a szabad ágensekben. A példán is látható, hogy a folyamat nem következik pusztán az ágensek prioritásából. A döntő kérdés az, hogy mely ágens mennyi szabad erőforrással rendelkezik szülő feladatok ellátásához. A folyamat így nem determinisztikus, az függ az ágensek aktuális terhelésétől.

0.10 Kommunikáció Ebben a pontban áttekintjük, hogy a megismert topológia felett hogyan kommunikálnak az ágensek. Mivel a rendszerben keletkező információk mindegyikét nem ismeri minden ágens, sőt nem is lehet általános szabályt adni arra, hogyha egy ágens rendelkezik valamilyen információval, akkor azt kiknek kell eljuttatnia, ezért többféle kommunikációs útvonalat mutatunk be. Ezek a kommunikáció egy-egy formáját valósítják meg. Amikor az ágens meg akar osztani egy információt, akkor az általa kezelt, információ-specifikus prioritási tömb alapján eldönti, hogy kik számára akarja azt eljuttatni. A következő lépésben az ágens a csoport ismeretében kiválasztja a megfelelő módszert.

56


Irodalomjegyzék

Amennyiben egy ágens nem érhető el közvetlenül és szüleinek láncolatán keresztül sem, az egy eseménykezelő aktiválását kezdeményezi, mely megpróbálja elérhetővé tenni az ágenst. Sikertelenség esetén a szabad ágensekben aktiválódik a hierarchia-építés eljárás. 0.10.1 Információ szűk körben, párbeszéd Abban az esetben, ha az ágens csak egy szűk körnek kíván információt eljuttatni, akkor a topológiától függetlenül, közvetlenül a keresett ágensekhez kapcsolódva küldi az információt. Annak eldöntésére, hogy mi számít szűk körnek küldendő információnak, a prioritás egy konfigurálható határértékkel való összehasonlítása szolgál. Ilyen információ lehet például egy mérési eredmény. Amennyiben a kiválasztott ágensek valamelyike nem érhető el közvetlenül, úgy az ágens a kiválasztott ágens szülőjének küldi el az információkat. Ilyen kommunikáció természetesen az is, amikor egy ágens párbeszédet folytat egy másikkal. Amennyiben lehetséges azt közvetlenül a kiválasztott ágenssel teszi.

22. ábraInformáció szűk körnek Az információ szűk körben való terjesztését mutatja a példa (0.10.1). Látható, hogy az ágens közvetlenül az általa címzett ágensek küldi az információt (folytonos vonal), és nem veszi figyelembe a hierarchiát. 0.10.2 Információ széles körnek, magas prioritású információk Amennyiben az ágensek száma, akiknek az információ elküldendő meghaladja azt az értéket, amely a közvetlen kiküldést lehetővé tenné, de nem közelíti meg az összes ágens számát, akkor a kommunikációt a többi feladathoz hasonlóan a Vállalkozási Háló módszer segítségével lehet kézbesíteni. A kézbesítés, a Vállalkozási Hálóknál használható kézbesítési feladat elvégzése lesz. Ugyanezt a módszert kell akkor is használni, ha olyan magas prioritású információról van szó, melynek mindenképpen el kell jutnia a célágenshez. Ebben az esetben az ágens szétosztja a kommunikációs feladatot, majd a nyertesek továbbítják azt vagy közvetlenül, vagy szintén a Vállalkozási Háló segítségével. A

57


Irodalomjegyzék

kommunikáció sikerességét a küldő ágens ellenőrzi a visszakapott jelentés alapján, és amennyiben szükséges újraküldi azt.

23. ábraInformáció küldése Vállalkozási háló módszerrel A példában (0.10.2) látható, hogy milyen lépésekben végzik el az ágensek a feladatot: • A küldő ágens a Vállalkozási háló módszerrel kiválaszt egy ágenst a kézbesítési feladat ellátására. • A megbízott ágens elküldi az információkat a címzetteknek • A megbízott ágens jelentést küld a feladat elvégzéséről. A kommunikációnak ez a fajtája sem használja fel az ágensek közti hierarchiát. 0.10.3 Információ mindenkinek Amikor az ágensnek olyan információja van, melyet minden – vagy majdnem minden - más ágens számára el kell juttatni, azt elküldi a fa gyökerében lévő ágensnek, aki továbbadja azt leszármazottjainak. Ezek után a leszármazottsági sorrend alapján adják tovább az információt az ágensek.

24. ábraInformáció küldése a hierearchia felhasználásával A példában (0.10.3) látható hogy az ágensek a hierarchikus struktúra segítségével (szaggatott vonalak) küldik az információkat. Az információ felkerül a gyökérbe, majd lefelé végighalad (folytonos vonalak) a leszármazotti struktúrán a levelekig. A folyamat végén, hibaellenőrzési eljárásként meg lehet vizsgálni, hogy a fa leveleiben lévő ágensek megkapták-e az információkat. Ezt az üzenet megkapását megerősítő kérdés elküldésével tehetik meg az ágensek, melynek paramétere az üzenet egyedi azonosítója.

58


Irodalomjegyzék

0.11 Hálózat-diagnosztizálás A fejezetnek ebben a részben kerül bemutatásra, hogy a rendszer milyen módon képes kihasználni felépítését a hálózat diagnosztikai feladatok ellátására. Mivel az alapfogalmak és a feladatok már ismertek a hálózat-diagnosztikával foglalkozó fejezetből, ezért ebben a részben az ott bemutatott módszerekkel való összehasonlítás található. Fontos megjegyezni, hogy a bemutatott multi-ágens rendszer felépíthető úgy, hogy megfeleljen az ismertetett hagyományos vagy osztott hálózatdiagnosztizáló eszközöknek. Hagyományos rendszerrel megegyező multi-ágens rendszer létrehozásához csupán egyetlen ágens aktiválása szükséges. Az egyetlen aktív ágens a központosított rendszerrel megegyező módon fog viselkedni, hiszen feladatait egyedül kell ellátnia. Osztott rendszerrel megegyező tulajdonságú MAS létrehozásához pedig csak egy ágenst kell az aktív cselekvéshez szükséges modulokkal ellátni. Mivel a többi telepített ágens csak megfigyelések végzésére alkalmas, az aktív feladatok elvégzésére kizárólag az arra alkalmas egyetlen ágenst fogják felkérni, aki így a központi megfigyelővel megegyező módon, egyedül fogja végezni a feladatok ezen körét. Az alábbiakban bemutatott példák kiválasztásának fő szempontja annak bemutatása volt, hogy mely funkciókat lehet jobban megvalósítani egy multi-ágens alapú rendszerben. 0.11.1 Hosztok, szolgáltatások figyelése A példában a Nagios-szal foglalkozó fejezet hosztok és szolgáltatások figyelését bemutató része kerül összehasonlításra hasonló funkciók multi-ágens alapú megvalósításával. Ugyanazon mintahálózat ebben az esetben több monitorozó ágenst is tartalmaz. Az ágensek az ábrán jelölt hosztokon futnak (0.11.1).

59


Irodalomjegyzék

25. ábraMAHD mintahálózat. A sötét háttérrel jelölt hosztokon fut monitorozó ágens

Mivel a multi-ágens rendszerű monitorozó rendszer nem egy hoszton fut, ezért a helyi – egy lokális hálózaton lévő – hosztok száma természetesen sokkal nagyobb. Bár a Nagios is adott rá lehetőséget, hogy távoli megfigyeléseket végezzünk, azt nem a megfigyelések több szemszögből való végzéséért, hanem a terhelés megosztásáért tette. A multi-ágens rendszerű monitorozás során akár minden alhálózatba telepíthetünk megfigyelőt. A megfigyelésekhez tartozó figyelmeztetési és eseménykezelési feladatokat megoszthatjuk az ágensek között. Ahhoz, hogy ez ne okozzon gondot, természetesen a rendszer minden ágensének folyamatosan karban kell tartania, hogy milyen feladatok kezelése tartozik hozzá, valamint azok között a figyelmeztetések és eseménykezelések nem fedhetik egymást. A helyi és távoli hoszt fogalma természetesen értelmes marad, azzal a kikötéssel, hogy az csak egy megfigyelő kijelölésével értelmezhető, annak az ágensnek a szemszögéből. Ugyanez igaz a Nagios szóhasználata szerinti szülő gyermek viszonyra is, mely adott megfigyelő és adott hoszt között lévő útválasztókon van értelmezve, jelentése megegyezik az ott ismertetettel. Feladatmegosztás

A központosított rendszer egy helyről végezte megfigyeléseit. Az osztott felépítésű rendszer képes volt több helyről végezni a megfigyeléseket, de azok eredményeit mindig továbbította a központi magnak.

60


Irodalomjegyzék

Ezzel szemben a MAHD rendszerben lehetőség van arra, hogy sok önálló megfigyelőt alkalmazzunk. Az önálló megfigyelők – ágensek – képesek a feladatok széles körét önállóan megoldani. A kliens-szerver modellben – például egy adatbázis szerver és kliense esetén - a kliens elküldi kéréseit a szervernek, és az a feldolgozandó adatok helyett a válaszokat küldi vissza. Ezzel jelentősen csökkent a kommunikáció a két pont között. A multi-ágens rendszerben az ágensek külön-külön kezelik méréseik eredményét. Az ágensek csak azokat az információkat osztják meg egymással, melyeket közösen kell kezelni. Ebből a szempontból a multi-ágens alapú felépítés a kliens-szerver szemlélet továbbgondolása, mely tovább csökkenti a hálózati forgalmat. Összetett monitorozás

Az ágensek végezhetnek olyan megfigyeléseket is, melyek több megfigyelés eredményét összesítik. Az összesített eredményt tovább is adhatják egymásnak. Az ebből összeállított eredmény globális megfigyelés eredménye lesz. A multi-ágens alapú megfigyelés előnyei: • Nem válik terheltté a központi mag (nincs is értelmezve ez a fogalom). • Nem terheljük feleslegesen a hálózatot, hiszen a megfigyeléseket helyben kiértékelhetjük. • Az aktív feladatok – figyelmeztetések, eseménykezelés - kezelését is rábízhatjuk az egyes ágensekre, a szenzorok értékeinek értelmezése mellett. Ez komoly előnnyel jár, ha a kommunikáció költsége magas. Ez előfordulhat azért, mert kis sávszélesség áll a rendelkezésünkre, vagy éppen egy elérhetetlen alhálózatban fut egy ágens. Így jobban alkalmazkodunk az alacsony sávszélességhez, hiba esetén sokkal pontosabb jelentéseket küldhetünk a helyi szolgáltatásról. • A rendszer felépítése sokkal jobban alkalmazkodik egy összetett hálózathoz, mely gyakran sok gyengén összekötött, de alhálózatokon belül erősen összekapcsolt hálózatból áll. • Lehetővé válik szolgáltatások összetett monitorozása. Az összetett monitorozásra jó példa, hogy az alhálózatokba helyezett ágensek mérhetik az alhálózatot jellemző hálózati sebességet, és az egymás között mérhető sebességeket. Az adatokat összefoglalva a teljes hálózatot jellemző térképet kapunk. 0.11.2 Hálózati kimaradások diagnosztizálása A Nagios központosított elven kereste a hálózati kimaradások okait. Megvizsgálta, hogy a központi megfigyelő szempontjából elérhetetlen hoszt lehet-e a hálózati kimaradás oka. Ezt azzal a módszerrel ellenőrizte, hogy megvizsgálta, az adott hoszt leszármazottjai elérhetetlenek-e, illetve, hogy van-e olyan szülője, amely elérhető. MAHD rendszerrel vizsgálva a hálózatot pontosabb képet kaphatunk a hálózati kimaradásokról: • Amíg a központosított rendszer csak annyit észlel, hogy lassan lehet elérni a C, D, E hosztokat, addig a C és E hoszt megfigyelői észlelhetik, hogy a II-es útválaztóval van gond, vagy a helyi hálózattal.

61


•

Irodalomjegyzék

Az elérhetetlenné vált alhálózatban elindulhatnak azok az eseménykezelők, melyeket kívülről nem lehet aktiválni. Ilyen lehet például a tűzfal szolgáltatást újraindító szkript.

0.11.3 Ágens leállása A hagyományos hálózatdiagnosztikai rendszerek központosítottságának egyik hátránya, hogy nem kezeli azokat a helyzeteket, amikor a központi megfigyelő nem érhető el. A megfigyelő leállása nem gyakori, de komoly fennakadásokat okozhat. Ilyen leállás bekövetkezhet az alábbi okokból: • Tervezett leállás, karbantartáshoz, ágens, vagy más szoftver frissítéséhez. • Leállás hiba, vagy támadás esetén. Az osztott diagnosztikai rendszer ad megoldást a leállások problémájára, ahogy a multiágens alapú rendszer is. A két megoldás közti különbség a szóba jöhető megfigyelők jellemző száma, és a feladatok átvételének módja közt van. Míg az osztott rendszernél az együttműködő magok jellemző száma alacsony, addig a multi-ágens rendszerben magas. Természetesen be lehet állítani az osztott rendszereket úgy, hogy a vezérlésre alkalmas megfigyelők száma elérje a hasonló multi-ágens rendszerbeli ágensek számát, de ez nem jellemző. A különbség abból adódik, hogy az osztott rendszernél a redundancia csak a terhelés megosztására, és a hibák következményének csökkentésére szolgál, addig a multi-ágens rendszerben a feladatok alapvetően több ágensre vannak kiosztva. A szóba jöhető megfigyelők száma több szempontból is fontos. • A véletlen hibák kevesebb feladat átütemezését okozzák • Az erőforráshiányból eredő hibák egy része fel sem lép, azok melyeket kivédett a feladatok egyenletesebb elosztása. • A támadások sokkal több ágens ellen kell, hogy irányuljanak. • A sikertelen támadások után megmaradt ágensek képesek átvenni a feladatok nagy részét, optimális esetben az összes feladatot. A multi-ágens rendszer másik előnye az ágens-leállásokkal kapcsolatban az a mód, ahogy egy ágens át tudja adni a feladatokat egy másik ágensnek. Az információk tárolása az ágensekben olyan prioritásokkal összerendelve történik, melyek meghatározzák a többi ágensre, hogy melyikkel mennyire kell megosztani azt az információt. Így kialakíthatóak az ágensek között olyan csoportok, amelyek a megfigyeléseik egy részét is megosztják egymással (példa: 0.8.3). Ha ezek a csoportok egy alhálózatban helyezkednek el, akkor nem nő kritikusan a kommunikáció költsége, viszont egy ágens leállása után a feladatot átvevő ágens gond nélkül folytathatja annak munkáját. A feladatok dinamikus elosztása pedig segít védekezni a hálózat, vagy megfigyelő rendszer támadásai ellen. Ennek oka, hogy a támadás által lelassult, vagy elérhetetlenné vált ágens feladatait átveheti a többi ágens. 0.11.4 Új ágens indítása A feladatok számának növekedésével elérkezhet az idő, amikor érdemes új megfigyelőt indítani. A multi-ágens rendszer rugalmas felépítése ezt a feladatot leegyszerűsíti, hiszen 62


Irodalomjegyzék

nem kell a rendszer többi részét leállítani, és újrakonfigurálni. Ha az ágensek magját akarja az adminisztrátor lecserélni, az is megoldható úgy, hogy a futtató hosztokon elindítja az új ágenst, az átveszi a régi feladatait, majd le lehet állítani a régit. Új ágens indítása az alábbi lépésekből áll: • Ágens telepítése: A frissen telepített ágensnek elegendő egy működő ágens ismernie. • Ágens kezdeti információinak begyűjtése: Az ágens Vállalkozási Háló módszerrel keres egyet az által ismert ágensek közül, akitől elkérheti a teljes rendszerre vonatkozó információkat. A nyertes ezek után elküldi a többi ágens listáját, a feladatokat, stb. • Az ágens begyűjti feladatait: Az új ágens vagy várakozik arra, hogy feladatokat kapjon, illetve ha kezdeti feladatai között szerepelt, átveszi bizonyos ágensek feladatainak egy részét. Ágenscsere esetén ez az összes feladat átvételét jelenti. Az architektúra két hasznos lehetőséget is ad arra, hogy új ágensek indításával csökkenthessük a többi terhelését. Egyrészt beállíthatunk minden alhálózatba olyan monitorozási feladatot, amely figyelmeztetést küld, ha az ágensek túlterheltté válnak. Másrészt telepíthetünk olyan ágenseket, amelyek kezdetben feleslegesek. Ezek át fogják aludni azt az időszakot, amely alatt nincs rájuk szükség, utána pedig átvállalják a feladatok egy részét.

0.12 Összefoglalás Ebben a fejezetben bemutattunk egy multi-ágens rendszert, a MAHD-ot, amely alkalmas hálózatok diagnosztizálására. Ahhoz, hogy kiderüljön sikerült-e a fejezet elején található célkitűzéseket teljesíteni, áttekintem az architektúra egyes célkitűzésekre adott válaszait: Robusztusság.

Az ágensek dinamikus feladatkiosztása és a hierarchia-szervezés dinamikussága garantálja a robusztusságot. A rendszer automatizmusai csökkentik az emberi beavatkozás szükségességét. Ez vonatkozik a feladatok kiosztására, és arra is, hogy az ágensek megtalálhatóak majd minden alhálózatban, és lokálisan könnyebben orvosolják a problémákat.

Skálázhatóság, Rugalmasság.

A feladatok számának növekedésére növelésével lehet válaszolni.

az

ágensek

számának

Az ágensek leállása nem okoz komoly gondot a rendszerben. Az Hibatűrés, elveszett információk mennyisége az ágesnek egymás közti Kegyelmes halál információ-megosztásának függvénye, mely idomul a tulajdonság. kommunikációs lehetőségekhez. Tehát a megoldás közel optimális lehet.

63


Megfigyelések több szemszögből Dinamikus feladatelosztás, a megfigyelés tárgyának minimális terhelése. Kommunikációs költségek minimalizálása.

Irodalomjegyzék

A rendszer természetesen képes összetett megfigyelések elvégzésére, melyekben több ágens is részt vesz. A Vállalkozási Háló módszer eljárást nyújt a feladatok elosztására. Az ágensek a terhelés növekedése esetén továbbadják feladataik egy részét. Az ágensek kihelyezése több helyre, önállóságuk növelése, és az információk priorizálása segít csökkenteni az erőforrások, többek között a hálózat terhelését.

64


Irodalomjegyzék

Összehasonlítás Ebben a pontban egy rövid összefoglaló található arról, hogy mely tulajdonságok azok, melyek hatékonyabbá tehetik a MAHD rendszert a hagyományos és osztott rendszereknél. Az összehasonlítás olyan pontokat tartalmaz, melyek a rendszerek egy-egy jellemző tulajdonságát hasonlítják össze, példával illusztrálva a különbségeket.

0.13 Sérülékenység A központosított rendszereknél az architektúrából adódik a sérülékenység. Ha a központi megfigyelő hibás lesz, sikeres támadás éri, vagy lelassul hálózati kapcsolata, akkor a rendszer védtelen lesz (0.13). Ugyanez igaz, bár kisebb mértékben, az olyan osztott rendszerekre, melyben van egy-két másodlagos megfigyelő, aki átveheti a központ feladatait.

26. ábraSérülékenység kiküszöbölése Az ábrán bemutatott példában a hagyományos rendszer központi megfigyelője, és a MAHD rendszer egyik ágense válik elérhetetlenné. Az 1-es és 3-as rész a rendszerek normális működését mutatják be, a 2-es és 4-es diagramok a hiba tartós megléte után kialakuló helyzetet szemléltetik. A hagyományos rendszerben a központi megfigyelő kiesésével az egész rendszer működésképtelenné vált. Nem csak a központi megfigyelő által végzett feladatok vesznek, el, hanem az együttműködő megfigyelő által összegyűjtött információk is. A rendszer javítható redundáns felépítés használatával, de rosszindulatú támadóval szemben mindenképpen sérülékenyebb a rendszer, hiszen annak csak a központi szerepre alkalmas

65


Irodalomjegyzék

megfigyelőket kell sikeresen támadnia. A MAHD rendszer képes az egyik megfigyelő elérhetetlenné válása után is folytatni a feladatát. Az elérhetetlenné váló ágens feladatai ugyan nincsenek kiszolgálva addig, amíg a többi ágens nem észleli leállását, de ezen időszak alatt sem kerül veszélybe a többi ágens feladatainak ellátása. A hiba észlelése után pedig a rendszer újraosztja az elérhetetlen ágens feladatait.

0.14 Egyenetlen terhelés A hagyományos rendszereknél a központosítás normális működés mellett is gondot okozhat. Egyrészt a rendszer skálázhatósága sérül, hiszen csak addig marad bővíthető a rendszer, ameddig a központra hárított feladatok – melyeket nem adhat át másnak – el nem érik azt a szintet, amelyet erőforrásai engednek. Másrészt a központot érő terhelés gátolhatja a normális működést, és mindenképpen erősebben lép fel benne az az effektus, amikor a mérőműszer működése zavarja a mérés eredményét. A multi-ágens rendszer képes a lehetőségekhez képest optimálisan szétosztani a feladatokat (0.14).

27. ábraTerhelés megosztása Az ábra bemutatja, hogy a szolgáltatások figyelésével kapcsolatos információk hogyan terjednek a rendszerekben. A szaggatott vonalak jelzik a megfigyelések információinak továbbítását. A hagyományos rendszerben minden megfigyelés eredménye a központi megfigyelőhöz kerül, hiszen csak az rendelkezik képességgel az információkkal kapcsolatos cselekvések elvégzéséhez. Így a központi megfigyelő sávszélességét a rendszer erősen terheli, előfordulhat, hogy pont a hálózat-diagnosztikai rendszer akadályozza a hálózat normális működését. A MAHD rendszerben is előfordul, hogy ágensek nem rendelkeznek minden képességgel, 66


Irodalomjegyzék

mely a megfigyelésekkel kapcsolatos információk kezeléséhez szükségesek. Ez abból adódik, hogy a rendszernek alkalmazkodnia kell a realitásokhoz, melyek nem teszik lehetővé, hogy minden hoszton minden eszköz az ágensek rendelkezésére álljon (például a figyelmeztetések kiküldéséhez). A különbség az, hogy míg a központosított rendszerekben egyáltalán nincs meg a lehetőség bizonyos feladatok szétosztására, addig a MAHD rendszerben ennek csak az informatikai környezet szab gátat. Így a MAHD felépítéssel megközelíthető az optimális feladatmegosztás, mely a lehető legkevesebb kommunikációval jár.

0.15 Konfigurálhatóság A hagyományos rendszereknél a megfigyelők frissítése fennakadásokkal járhat, hiszen a központi megfigyelő leállításakor a rendszer védtelen. Ezzel szemben a multi-ágens rendszerben folyamatosan cserélhetőek az ágensek, amíg a feladatokat a futó ágensek ellátják (0.15).

28. ábraRendszer konfigurálása A sérülékenység tárgyalásánál már bemutattuk, hogy egy hagyományos rendszer esetén a teljes diagnosztizálás leállásával jár a központi megfigyelő (vagy megfigyelők) elérhetetlenné válása. A rendszer megfigyelőinek leállással járó konfigurálásakor is ez történik. Amíg a központi megfigyelő átállítása zajlik (2. állapot), a teljes rendszer képtelen a működésre, mely csak a központi megfigyelő újbóli elérhetővé válásakor áll helyre (3. állapot). Ezzel szemben a MAHD rendszerben a feladatok ellátása nem szűnik meg, azokat másik ágens átveszi (5. állapot). A hibából, vagy támadásból eredő leállásokkal szemben a tervezett leállások esetén ráadásul lehetőség van arra, hogy a leállítandó ágenst feladatainak átadására utasítsuk. Így nincs olyan időpillanat, amikor a leállított ágens feladatai nem kerülnek ellátásra. Az ágens újraindítása után az újra feladatokat kap (6. állapot), a dinamikus feladatkiosztás miatt nem is feltétlenül régi feladatait.

0.16 Összetett megfigyelések A bemutatott központosított és osztott rendszerek nem használták ki, hogy a hálózatot több

67


Irodalomjegyzék

pontból is vizsgálhatják. A multi-ágens rendszerben erre lehetőség van, emellett az ágensek alkalmasak arra, hogy előfeldolgozás után adják tovább megfigyeléseiket összegzésre (0.16).

29. ábraÖsszetett megfigyelés Az ábra bemutatja, hogy hogyan végezhető el egy összetett megfigyelés osztott, illetve MAHD rendszerrel. Ilyen megfigyelés lehet a hálózat sebesség-térképnek az összeállítása, ahol a térkép csomópontjai a hosztok, a köztük lévő élek a kapcsolatok, megcímkézve a hálózati átvitel sebességével. Az ábráról is leolvasható, hogy a feladat nem oldható meg egy központosított rendszerrel, hiszen az alhálózatok hosztjai közötti sebesség mérése távolról külön eszköz nélkül megoldhatatlan. Osztott rendszert használva minden alhálózatba megfigyelőt – vagy minimum külső programot – kell telepíteni, mely képes a helyi sebességek megfigyelésére. Az osztott rendszer hátránya a MAHD-hoz képest az, hogy nem képes a megfigyeléseket helyi szinten összegezi, az összes mérés eredményét továbbadja a központnak. Ez a hálózat felesleges terhelésével jár. Amennyiben egy osztott megfigyelésben a hasznos információk összes megfigyelési információhoz viszonyított aránya alacsony, a módszer nagyon kevéssé hatékony. Például, ha a hálózat sebesség-térképének olyan változatára vagyunk kíváncsiak, melyben az éleket a ’rendben’, ’lassú’ és ’megszakadt’ címkékkel szeretnénk ellátni, az összes megfigyelés helyett a jól működő alhálózatokból elegendő egy minden kapcsolatra vonatkozó ’rendben’ jelzés küldése.

68


Irodalomjegyzék

Összefoglalás A rendszer tervezése megmutatta, hogy multi-ágens rendszer használatával hatékony hálózat-diagnosztizálást lehet végezni. Ahhoz, hogy megtudjuk a gyakorlatban mennyire működik hatékonyan egy ilyen rendszer el kell készíteni prototípusát és egy teszthálózatban vizsgálni kell működését. A szakon nagyprogramként fejlesztett multi-ágens alkalmazásom 0.16 készítésének tanulsága volt, hogy egy ilyen összetett rendszer nehezen tesztelhető és verifikálható. Az összetettség rugalmas és intelligens működést eredményezhet, de annak fejlesztése és ellenőrzése sokkal nehézkesebb, mint egy központosított fejlesztésnél. A tervezés nehézsége annak köszönhető, hogy el kell szakadni az egy entitásból kiinduló gondolkodásmódtól, amely az emberi nézőponthoz olyan közel áll. Az implementálás közben fellépő gondok oka, hogy nincsenek olyan elfogadott módszerek, melyekkel egy ilyen komplex rendszer esetén megkönnyítenék a fejlesztést, a verifikálást és a validálást. A hálózatok méretének és jelentőségének növekedése előreláthatólag kikényszeríti azoknak az eszközöknek az elkészítését, melyek hatékonyabban képesek hozzájárulni működésükhöz. A dolgozatban bemutatott rendszer fő jellemzői valószínűleg meg fognak jelenni a hálózat-diagnosztikai eszközöknek a következő generációjában., hogy miért? A feladatok sokasodó száma, a pontos diagnosztizálás szükségessége és az igény a felmerült problémák gyors és lehetőleg automatikus javítására jobban elláthatóak egy ehhez hasonló felépítésű rendszer tulajdonságaival. Ahogy az emberi munkavégzés során is nagy hangsúly került a csoportos munkavégzésre, úgy kerül az előtérbe a szoftverrendszerek terén is. Az ok ugyanaz: nem mondhatunk le arról, hogy a feladatokat több nézőpontból vizsgáljuk, és hogy a feladatokat elosszuk több problémamegoldó közt. Természetesen több szoftver működését is ugyanolyan nehéz összehangolni, mint több emberét, de ha a feladatok megkövetelik, akkor a szoftvereknél is megjelennek a szükséges módszerek. Egy ilyen módszert igyekezett bemutatni ez a dolgozat is. Hogy milyen sikerrel, az mérhető lesz azzal, hogy a benne foglalt módszerek mekkora része terjed majd el a kereskedelmi rendszerekben.

69


Irodalomjegyzék

Irodalomjegyzék 1

An Architecture for Intrusion Detection using Autonomous Agents COAST Technical Report 98,05

2

Jai Sundar Balasubramaniyan, Jose Omar Garcia-Fernandez, David Isacoff, Eugene Spafford, Diego Zamboni Gulyás László - Tatai Gábor

3

Gulyás László - Tatai Gábor (szerk.)

Agents everywhere Springer 1998 ISBN 963 6990 99 9

4

Gulyás László - Tatai Gábor

Multi-Ágens rendszerek jegyzet ELTE speciálkollégium 2001

5

Katya P. Sycara

6

Mérő László

Multiagent systems AI magazine 1998 nyár Észjárások: a racionális gondolkodás korlátai és a mesterséges intelligencia Tericum 1997 ISBN 963-8453-30-3

7

Stuart J. Russel-Peter Norvig

Mesterséges intelligencia modern megközelítésben Prentice Hall, 1995 ISBN 963 545 241 1

8

H. Van Dyke Parunak

„Go to the Ant” Engineering Principles from Natural Multi-Agent Systems Annals of Operations research, 1996

9

Terray Tamás

10 Aitia informatikai Rt.

MMAS, Mini Multi-Agent System ELTE nagyprogram 2003 http://tterray.imind.hu/egyetem/mmas/ Ágens portál http://agent.aitia.hu

11 Ethan Galstad

Nagios portál http://www.nagios.org

12 Michael Wooldridge

An Introduction to Multiagent systems http://www.csc.liv.ac.uk/~mjw/pubs/imas

70

Ágensek és multi-ágens rendszerek fejezet, Futó Iván (szerk.) Mesterséges Intelligencia Aula, 1999 ISBN 963 9078 99 9

Hálózat diagnosztizálás multi-ágens rendszer segítségével

Recommend Documents