Az ELTENET felépítése, az üzemeltetési tapasztalatok és használt management rendszerek

Győri Gábor
Gabor.Gyori@elte.hu
Eötvös Lóránd Tudományegyetem, Információtechnológiai Központ

Bevezetés

Az ELTENET-ről végig királyi többesben fogok beszélni, de már az elején le kell szögeznem, hogy az ELTENET tervezése és kivitelzése sajnos azóta már távozott kollegáim, Daruházi László és Pintér Ödön érdeme.

Az ELTE területileg eléggé szétszórt, ezért a legváltozatosabb technológiákat kellett alkalmazzuk a különböző helyszínek bekötésére. A vonalak ill. campusok elhelyezkedését az alábbi vázlatos ábra mutatja:

Az ELTENET szerkezete

Az ELTENET tervezésekor igyekeztünk egy nagy kapacitású és nagy megbízhatóságú magot létrehozni, amely várhatóan a jövö kommunikációs igényeit is kielégíti. Így esett a választás az FDDI-ra, amely 100Mbit/sec sebességet kínál, az üvegszálas technika garantálja az elektromos zavaroktól való mentességet, a gyűrű topológia pedig azt, hogy egy vonal kiesése esetén a gyűrű még zavartalanul működik, egy router kiesése esetén csak az adott routerhez csatolt hálózati részek esnek ki, a többi router változatlan sebességgel éri el egymást. Az FDDI gyűrű az ELTE és a SOTE közös projektjének indult, mára két másik intézmény (Az OMIKK és a MedInfo) is csatlakozott. Módosult egy kicsit a technológia is, mára az FDDI egyes ágait ATM-be ágyazva visszük át, így spórolva üvegszálakat. (Az ATM-en az FDDI mellett E1 trunk-ök is vannak, amelyeket a belső telefonhálózat kiterjesztésére használunk). Az ATM switchek bridgel-ként működnek a három fizikai gyűrű között. Az FDDI mai állapotát az alábbi ábra tartalmazza.

A gyűrűhöz csatlakozó routerekben látjuk el a routerekhez fizikailag közel lévő ELTE részeket valamint a SOTE épületeket, optikai ethernet segítségével. Az üvegszálakkal anyagi és egyéb okok miatt el nem érhető helyszíneket analóg bérelt vonallal illetve mikrohullám segítségével kapcsoltuk be, így az alábbi struktúra alakult ki:

Az ELTENET-hez sok külső intézmény is kapcsolódik FDDI, optikai ethernet, vagy bérelt vonal segítségével. Az ELTENET elsődleges külső kapcsolódása a bme.iif.hu routeren keresztül valósul meg , közvetlen optikai etherneten illetve a BME-n keresztül FDDI-on és etherneten keresztül. Ezen kívül van még a Városház utcába, az mta.iif.hu-ba vezető 64K-s tartalék bérelt vonalunk.

A felhasználókat a tervezett leállásokról és hibákról news-ban is tükrözött levelelzési listákon tájékoztatjuk. A hálózati szábályzat, a hálózat felépítéséről és egyes szolgáltatásokról a felhasználó a http://www.elte.hu/eltenet/ címen szerezhet információkat.

Üzemeltetési költségek

A hálózat telepítésekor az alacsony üzemeltetési kötségek elérése volt a cél. Ennek az alábbi technológiákat alkalmaztuk:

Az üzemeltetési tapasztalatok

Külső kapcsolat

Az ELTENET külső kapcsolataiban a legnagyobb fennakadásokat a HBONE mag redundancia nélküli tervezése okozta, amikor a Városház utca - Victor Hugó utcai bérelt vonal szakadozása miatt a tartalék 64K-n kellett forgalmazzunk. Néhányszor, a BKE-n lévő repeatert érintő áramszünet miatt, elszakadt az ELTE - bme.iif.hu ethernet is, ekkor azonban az egyetemközi FDDI-on és a BME-n keresztüli tartalék út automatikusan belépett, így változatlan sebességű maradt a külső kapcsolat.

A belső hálózati vonalak

Itt a hibákat vonaltípusonként írom le

Hálózati eszközök hibái

A repeatereknél volt a legtöbb meghibásodás, főként a tápegységventillátor és emiatt a tápegység ment tönkre, de volt amikor csak egy AUI port illetve fiber modul hibásodott meg.

Egy MGS routerünkben az egyik 2E2S-es kártya ment tönkre, egy másikban az NVRAM felejtette el a tartalmát. Ebben merülnek ki az elmúlt másfél év hardware meghibásodásai.Így a routerek hardware-esen megbízhatónak mondhatók.

A PC-s bridgekkel rossz tapasztalataink vannak, gyakran elestek nagy terhelés illetve sok hibás frame esetén. A Unix, Novell, Win NT alatt üzemelő PC-s routerek megbízhatóan üzemeltek, a hardware bridge-ekkel sem volt probléma.

A használt felügyeleti rendszerek

Egy ekkora rendszert már nem célszerű a szokott módszerrel, a felhasználó panaszos telefonjára várva üzemeltetni, ezért az ELTE management rendszereket vásárolt. A rendszerek az eszközökbe épített Simple Network Management Protokoll (SNMP) lekérdezési lehetőséget és pollozást (az eszköz elérhetőségének periodikus vizsgálata) használják. Elsöként a Sunnet Manager keretrendszert és a beleágyazott CiscoWorks-öt vásároltuk meg, később a Cabletron cég Spectrum nevű rendszerét. Az ATM managelésére a NewBridge 46020 kódnevű management rendszerét használjuk. Ez utóbbiról itt nem beszélünk, mert csak a NewBridge eszközökkel működik együtt, nem a szabványos SNMP-t használja.

SunNet manager 2.0 /CiscoWorks 1.0

A SunNet Manager az alábbiakat tartalmazza:

Összességében nem igazán jól használható, a képességeit többnyire nem nyújtja kielégítő színvonalon, bosszantó hibákat tartalmaz. Ilyen például az, hogy az event-ek figyelése csak akkor történik, ha a grafikus felület fut, azaz megjelenik egy X terminálon, ami nálunk egy Linux X felülete. Emiatt a Linux X-et lock-ban kell tartani. Egy másik bosszantó dolog, hogy egy SNMP lekérdezés után az eredményablak bezárásával az egész program befejezi működését.

A CiscoWorks jobbra sikerült, ennek segítségével sikerült event-eket definiálni, rávenni arra, hogy hiba esetén levelet küldjön. Igaz, hogy a postaládánk elárasztásának elkerülése érdekében egy saját gyártmányú programot is fejleszteni kellett a vonallebegések (ismétlődő up/down státusztváltás) csillapítására. Lehetőségünk van a router állapotának lekérdezésére egyszerű MIB változók lekérdezése által, a telnet kapcsolatban megszokott show parancs formátumában illetve csinos grafikus oldalak formájában is. A SunNet Manager Grapher-jének segítségével on-line grafikonban is figyelhetjuk a router ill. egy vonal vagy protokol forgalmát. A Path-Toollal meghatározhatjuk egy adott adatúton a terheltséget, így a szúk keresztmetszet azonnal kiderül. A routerek konfigurációit is egységes környezetben tárolhatjuk, Tacacs servert is találunk benne. SyBase adatbázishoz kapcsolódva tárolatjuk a hálózati eszközeinkre jellemző adatokat. A software újabb verzióiban az eszköz grafikus képét is megjeneníthetjük, ahol a ledek állapotát is láthatjuk.

Spectrum

:A Spectum egy jóval bonyolultabb de jóval használhatóbb, objektumalapú rendszer. Ez azt jelenti, hogy a minden eszköznek, vonalnak megfelel egy objektum, amit a Spectrum modell-nek nevez. Ezen modelleket és egymáshoz való kapcsolódásaikat egy adatbázisban tároljuk. A modellekben megtaláljuk az adott eszközre jellemző legfontosabb adatokat, melyeket az adatbázishoz kapcsolódva le is kérdezhetünk.

A Spectrum egy szerverből (SpectroServer) és több kliensből áll. A szerver itt állandóan fut és gyűjti az adatokat, végzi a riasztásokat, függetlenul attól, hogy fut-e megjenítő kliens. Kliensből is több futhat egyszerre, azaz több terminálon is lehet egyidejűleg figyelni a hálózat működését.

A szerver tartja karbanazt az adatbázist amely leírja a hálózatot, tartalmazza az egyes Modelleket, valamint az egyes eseményeket (event-ek) és a statisztikákat tartalmaznapló file-okat is. A Szerver végzi az egyes hálozati eszközök (routerek, managelhetô repeaterek, számítógépek stb.) rendszeres pollozását. Az eszközöket alapvetően SNMP, illetve nem SNMP managelhető eszközöknél ICMP (ping) segítséségével ellenôrzi.

Az adatbázishoz alapvetôen a SpectroGRAPH rendszer segítségével férünk hozzá, de a szerver lehetôséget biztosít arra is, hogy más (esetleg saját fejlesztésű) alkalmazással kapcsoldjunk hozzá (script-eket használunk most, de lehetőség van az adatbázis C programból való elérésére is.).
Az adatbázis felépítéséhez a Spectrum felkínál egy ún. AutoDiscovery lehetőséget. Ez azt jelenti, hogy megadott IP cím tartományban leelenőrzi, hogy az adott eszköz megfelel-e egy menüben megadott feltételnek (pl. ha csak a routereket keressük akkor csak azokat jeleniti meg). A saját adatbázisunk felépítéséhez is ezt a lehetôséget használtuk. A később csatlakoztatott eszközöket egyesével is hozzá lehet adni.

Az adatbázisban minden ún. modell-ként van tárolva. Ezek a modell-ek parent/children viszonyban állnak egymással, pl. egy router és annak egy portja. A modellek között többfajta kapcsolatot is meg lehet adni, így egyszerre lehet tárolni a hálózat logikai- (melyik router melyikkel van összekötve) és a fizikai topológiáját (melyik telephelyen, azon belül melyik épületben, szobában, rack szekrényben található az adott eszköz).
Az egyes modellekre külön-külön, illetve modelltípusokra egységesen beálíthatók watch-ok. (A minden, egy adott típusű modellre definált watch is letiltható az adott modelleken egyenként.) A watch-ok nem csak eseményfigyelést jelentenek, hanem logolást és új attribútum kiszámítását is. Az eseményfigyelés definiciójáben egy adott model vagy modeltípus egy vagy több atribútuma értékeinek figyelembe vételével definiáltunk egy riasztási feltételt. A feltétel bekövetkezte és/vagy elmúlása esetén meghívhatunk egy scriptet vagy programot, ami a pl. riaszthatja a megfelelő szakambereket. Mi most ezt a lehetetőséget figyelmeztető E-mail küldésére használjuk.

A leggyakrabban a SpectroGRAPH alrendszert használjuk, ezen megjeleníthetôek az egyes eszközök (modellek) és ezek kapcsolata, grafikus formában. A megjelenítés több szintű, a teljes felügyelt hálózatból kiindulva egy adott részhálózat képéhez, az ott aktív eszkökhöz sőt egészen az eszköz MIB-jeihez is eljuthatunk. Lekérdezhetjük természetesen az adott modellről az adatbázisban tárolt értékeket is.Ugyanígy lehetőségünk van erre a fizikai topológia szerinti nézetben is. Mindez megszokás után kényelmesen kezelhető. Lekérdezhetjük egy adott modell, pl. egy vonal történetét is, amit report formájában ki is nyomtathatunk, ami igen hasznos lehet pl. a szolgáltatónál való reklamációnál a leállások dokumentálására.

A SpecroWATCH alrendszer segítségével követhetjük nyomon, hogy milyen aktív watch-aink vannak, itt definiálhatjuk az újakat, módosíthatjuk a régieket.