A Neptun rendszer erőforrás használatának elemzése Faragó Zsuzsa,
[email protected] Gál Zoltán,
[email protected] Debreceni Egyetem Informatikai Szolgáltató Központ (DISZK)
1. Bevezetés A Debreceni Egyetem 2002. szeptemberére tervezte minden karon a kredit rendszerű oktatás bevezetését. Ehhez elengedhetetlen a munkafolyamatok és az adatkezelés informatikai támogatása, egységes tanulmányi informatikai rendszer megteremtése közös adatbázis kialakításával. Korábban nem volt egységes tanulmányi rendszer, a karok/önálló intézetek eltérő módon oldották meg a nyilvántartási feladataikat A 14 kar illetve kar szintű intézményből álló Debreceni Egyetemen szükségessé vált egy korszerű hallgatói nyilvántartó és információs rendszer bevezetése. Az egyetem vezetése 2001. novemberben úgy döntött, hogy az Oktatási Minisztérium által támogatott Neptun2000 Egységes Tanulmányi Rendszer kerül bevezetésre az egyetem minden karán és önálló intézetében. Ez a rendszer eszköz a tanulmányi osztályokon folyó nyilvántartási feladatokhoz, a tanszékek oktatási feladatainak adminisztrálásához és a hallgatói ki- és befizetések kezeléséhez. Az oktatási egységek és a hivatalok a rendszer bevezetése nyomán egyetlen közös adatbázison, egységes informatikai rendszerrel végezhetik a munkájukat. Minden hallgató, oktató és dolgozó a jogosultságának, szerepkörének megfelelő információt érhet el a rendszerből. Az egyetemen működő informatikai rendszerek, meglévő nyilvántartások adatait át kellett konvertálni a Neptun adatbázisba, ennek következtében az adatok egy része (hallgatók személyi adata) nagyon hamar kezelhetővé vált, más részét (képzések, tárgyak, mintatantervek) be kellett kódolni, illetve át kellett dolgozni a Neptun rendszer igényeinek megfelelően. Feltétlenül meg kellett valósítani, hogy a bevezetésre kerülő rendszer adatkapcsolatban legyen az intézményben működő gazdasági informatikai rendszerrel. A Neptun projekt kiterjedt a hallgatói termináltermek kialakítására, amely a hallgatók rendszerelérését szolgálja. Ezen projekt keretében meg kellett teremteni az EFK (Egészségügyi Főiskolai Kar - Nyíregyháza) és a HPFK (Hajdúböszörményi Pedagógiai Főiskolai Kar) megfelelő kapacitású bérelt vonali csatlakozását. A cél az volt, hogy a bevezetés során eszközt biztosítsunk az oktatási munka adminisztrálásához, ami támogatja a kredit rendszerű oktatás és a megnövekedett hallgatói létszám következtében keletkező többletfeladatok ellátását. A bevezetésre került rendszer alkalmazásával az oktatók, a hallgatók és az adminisztrációs tevékenységet folytatók rendszerezetten, átlátható formában jutnak hozzá az őket érintő információkhoz. A bevezetés egyik fontos eleme volt a betanítás, oktatás. A munkaköröknek, feladatköröknek megfelelően több szinten történt az oktatás. Külön került bemutatásra a rendszer a karok/önálló intézetek kijelölt tartalmi és informatikai felelőseinek, akik később felügyelik és segítik a karokon folyó munkát. A tájékoztatón bemutatásra kerültek a paraméterezési lehetőségek, amelyekkel a karon az egyedi beállítások elvégezhetők. A tanulmányi osztályok és a tanszéki adminisztrátorok betanítása több héten keresztül heti 1-2 alkalommal 2-3 óra volt. Ez idő alatt megtanultak egy-egy munkafolyamatot, amit a közbeeső napokban begyakorolhattak, miközben végezték az adatfeltöltést. Lényegesnek véltük, hogy az adatok az előírt ütemben kerüljenek a rendszerbe, mert az oktatási tematika úgy épül fel, hogy a tanulmányi osztályok és a tanszékek felhasználhatják az egymás által felvitt adatokat. Külön betanítás volt szükséges a speciális feladatokra (órarendkészítés, pénzügyek kezelés). Az intézmény oktatói tájékoztató és konzultáció keretében ismerkedhettek meg a rendszerrel, a hallgatókhoz pedig hallgatói fórumon és egyéb írásos információs anyagban juttattuk el a rendszerrel kapcsolatos tudnivalókat. A rendszer kialakítása során fontos lépés volt a felelősök meghatározása, illetve a feladatok pontos definiálása. Az egyes karokon és kar szintű intézetekben a felelősök feladatai közé tartoztak az előkészítő feladatok irányítása, informatikai illetve szakmai kérdések megoldása, az
adatgyűjtési feladatok irányítása, a karhoz tartozó tanszékek támogatása az üzemeltetési feladatokban, az üzemeltetés során felmerülő problémák megoldása, és a kapcsolattartás. Tehát több más felsőfokú oktatási intézményhez hasonlóan egyetemünk is a Egységes Felsőoktatási Tanulmányi Rendszer bevezetése mellett foglalt állást. Az Szolgáltató Központra hárult az a feladat, hogy az alkalmazás működésének hardver rendszer szintű feltételeit biztosítsa, valamint kidolgozza az üzemeltetési környezet elemeit.
Neptun2000 Informatikai és operációs informatikai
2. A Neptun rendszer felépítése A Debreceni Egyetemen a Neptun tanulmányi rendszert úgy alakítottuk ki, hogy a felhasználói társadalom számára minél könnyebben és egyszerűbben elsajátítható legyen a megkövetelt filozófia. Ennek érdekében egyszerre két adatbázis fut párhuzamosan: NEPTUN és TEST. A redundanciát az egyetem oktatási rendszerének bonyolultsága, illetve a szoftver újdonsága tették szükségessé. Ezzel biztosítjuk, hogy az éles adatbázis mindig valós tartalommal bírjon, és lehetőség nyíljon az újonnan érkező dolgozók számára az egyes funkciók mielőbbi megismerése. Az egyetemen a Neptun rendszer kapcsolatai a felhasználókkal elég heterogén jogosultság és elérés szempontjából egyaránt. Az Egyetemi Hallgatói Információs Központ koordinál a felhasználók, a Neptun rendszer, a Gazdasági Főigazgatóság, az üzemeltetők, és a fejlesztők között. Ellátja az adminisztrációs feladatokat, követi és felügyeli az információ áramlását (pl. statisztikák elkészítése), illetve továbbítja a felmerülő igényeket, problémákat az illetékes felelősöknek. A Gazdasági Főigazgatóság és a Neptun rendszer közötti adatáramlás elektronikusan (a NeptunA szerveren kialakított tárterületen keresztül), illetve papír formában történik. A karonként és feladatonként megjelölt felelős személyek végzik a szükséges teendőket, illetve az egyetemi szintű feladatokat a központilag kijelölt személyek látják el. A Neptun rendszer tartalmi oldalának menedzselése a tanulmányi osztályok feladata. Itt történik mindenféle ügyintézés, és a hallgatók illetve oktatatók ide fordulnak tanulmányügyi problémáikkal. A Tanulmányi Osztályok dolgozói egyszerre több feladatot is ellátnak a Neptun rendszerben, ehhez viszont többféle jogosultságra van szükségük: kari adminisztrátor, tanulmányi ügyintéző (TO ügyintéző), tanszéki adminisztrátor, diákigazolvány nyilvántartó, teremkezelő, statisztikakészítő, banki felhasználó, órarendszerkesztő. Az oktatók és a hallgatók tanulmányi ügyeiket (tantárgyfelvétel, vizsgára jelentkezés) intézik a rendszeren keresztül. Az SDA Kft. folyamatosan fejleszti a szoftvert, és a hozzátartozó modulokat (beleértve az adatbázison és az adatbázis szerveren szükséges módosításokat), átadja az elkészült bővítéseket, illetve a felhasználók betanítását is elvégzi.
1. ábra. A Neptun rendszer kapcsolati struktúrája
A DISZK a Neptun rendszer informatikai üzemeltetéséért felelős. A szerverek, és a rajtuk lévő szoftverek folyamatos menedzselése a fő feladata, illetve biztosítania kell a rendszer folyamatos elérését, és működését. Rendszerszinten jelentkező feladatok megoldása (account management, printer driver telepítés, mentések, update-k), szerverekkel kapcsolatos igények kielégítése, és a hálózattal, operációs rendszerrel kapcsolatos problémák kiküszöbölése. A Debreceni Egyetem hallgatói, oktatói és dolgozói az intézmény hét nagy campusán, illetve telephelyén, az intézményi adatátviteli hálózatra kapcsolt számítógépekről férnek hozzá az informatikai rendszerekhez. Jelenleg az egyetemi hálózatra kapcsolt 5800 gép közül mindegyik Internet hozzáféréssel rendelkezik, ami lehetővé teszi, hogy a felhasználók az egyetem területéről bárhonnan elérjék a rendszert. A Neptun rendszer csak Internet Explorer 5 vagy magasabb verziójával érhető el Interneten keresztül, illetve az adminisztrációra fenntartott terminál szerverre Terminal Services Client programmal lehet belépni. Sok felhasználó otthonról vagy munkahelyéről kísérli meg a bejelentkezést. Biztonsági okokból a cégek általában egy tűzfalat állítanak be, mely védi hálózatát a kívülről érkező betolakodók ellen. Lehetőség szerint a vállalat tűzfalán engedélyeztetni kell a 3389-es portot, mert a kliensprogram ezen a porton keresztül kommunikál a Neptun rendszerrel. Kezdetben a Debreceni Egyetemen a Neptun2000 Egységes Tanulmányi Rendszer üzemeltetéséhez 5 db szerver állt rendelkezésre, melyek közül 4 db terminál szerver, és 1 db adatbázisszerver. A szerverek hardver konfigurációja a következő: Szerver Adatbázis Terminál
Konfiguráció 4GB RAM, 2x900 MHz CPU, 60 GB HDD 4 GB RAM, 900 MHz CPU, 36 GB HDD
Mennyiség [db] 1 6
Az adatbázis szerver 6 db, a terminál szerverek 2 db interfésszel rendelkeznek, vagyis használnak 1-1 olyan interfészt, melyek közvetlenül vannak összekötve. A Windows 2000 Server platformmal rendelkező négy darab terminál- és egy darab adatbázis szerver Oracle Kliens és MS Sql Server modulokat futtat, illetve az adminisztrátori feladatokat ellátó felhasználók igénye szerint a Microsoft Office programcsomag Word, Access és Excel programjainak installálása is megtörtént az általuk használt szerverekre, valamint további pénzügyi tranzakciók végrehajtásához szükséges kliens programok is felkerültek ezekre a platformokra. A banki utalásokat a Neptun rendszer kezdeményezi, és az utalási állomány általában szabványos GIRO formátumban készül el, filozófiánk szerint a Tanulmányi Osztályoknak a kari számfejtések eredményeként keletkező GIRO formátumú állományokat e-mail mellékleteként kell eljuttatniuk a Gazdasági Főigazgatóságra „Hallgatói GIRO feladás” program segítségével. Egyetemünk tanulmányi rendszerét egy linux-os tűzfal véd, melynek gondosan kialakított szigorú szabályai biztosítják a védelmet, illetve egy L2-es switch is tartozik Neptun szerverfarmunkhoz.
3. A Neptun rendszer erőforrás használatának tapasztalatai A rendszer felhasználásából adódó időben inhomogén, de trenddel rendelkező terhelés az üzemeltetésért felelős rendszergazdák számára egy, a folyamattal párhuzamos, intenzív odafigyelést feltételez. Mivel intézményünknél a Neptun-t 26.000 hallagató és 3.500 oktató nap, mint nap használja, a rendszer a telefonhoz hasonlóan nagyon nagy megbízhatósági színvonallal és rendelkezésre állási jellemzővel kell, hogy rendelkezzen. Emiatt a DISZK a többi kritikus alkalmazáshoz hasonlóan folyamatosan figyeli és elemzi a saját Neptun rendszerének erőforrás használatát. Ehhez tartozik nemcsak a szerverek CPU, RAM és hálózati interfészének folyamatos monitorozása, hanem a védelmi funkciót ellátó Neptun tűzfal elemei által érzékelt támadási típusok és azok gyakoriságának nyomon követése, valamint a gerinchálózati eszközök segítségével történő forgalommérések is. Az SNMP protokoll segítségével lekérdezett MIB változókat MRTG programmal rendszerezzük és ábrázoljuk. A begyűjtött állapotinformációk idősorait statisztikai eszközökkel dolgozzuk fel, amiből az erőforrások időszakos terhelésére vonatkozóan intelligens következtetéseket vonunk le.
Tapasztalataink és információink arra a következtetésekre jutattak, hogy a rendszerben több megoldandó problémát kell kielemeznünk. Egyik legszembetűnőbb a terminálszerverek egyenetlen terhelése. A szerverek jogosultság szerint vannak kiosztva a felhasználók között, vagyis az adminisztrátorok és a hallgatók különbözőképpen érhetik el a rendszert: míg a hallgatók IE böngésző segítségével bárhonnan bejelentkezhetnek, addig az adminisztrátorok csak egyetemi hálózatba kötött gépekről és saját azonosítóval kezelhetik adataikat. A hallgatók számára két, egymástól független terminálszerver áll rendelkezésre, így a hallgatók ízlés szerint választhatnak a NeptunC és NeptunD szerverek között. Az erőforrások optimális kihasználtsága érdekében, gondoskodtunk arról, hogy a hallgatói bejelentkezéskor egyenletes elosztás legyen a hallgatói szerverek között. Vagyis a Neptun rendszert védő tűzfal DNAT szabálya szerint egyik kérést az egyik, másik kérést a másik terminálszerver felé továbbítja. Sok esetben a hallgatók indokolatlanul hosszú ideig maradnak a rendszerben, vagy egyáltalán nem lépnek ki. Ez oktalan erőforrás használatot jelentett. Ennek kiküszöbölésére beállítottunk egy időlimitet, mely szerint a hallgatók félórás bejelentkezése megszakad. Mivel a hallgatók és oktatók ugyanazon felületen érik el a rendszert, így kezdetben ugyanazon terminálszerver állt rendelkezésükre. De a kialakított időkorlát következtében, a NeptunB szervert helyeztük üzembe az oktatók számára, és ezáltal lehetővé vált, hogy a NeptunC és NeptunD szerverekre csak hallgatók jelentkezzenek be. Ezeken a szervereken maximum fél óra időtartamig lehet bejelentkezve a felhasználó, továbbá figyeli azt is, hogy a hallgatók csak egy példányban lehetnek jelen a rendszerben. További foglaltságot jelent a szervereken, hogy a bejelentkezett adminisztrátorok helytelenül lépnek ki, és a háttérben futó, beragadt processzek továbbra is terhelik az erőforrásokat. Figyelmeztető üzenetekkel és az oktatáson nyomatékosan felhívtuk figyelmüket a szabályos kilépés fontosságára. A tanulmányi ügyek többrétű kezelése megkövetelte, hogy a dolgozók saját azonosítóval jelentkezhessenek be az általuk használt szerverre. A Neptun rendszer moduljai és egyéb programok használatán kívül, más szolgáltatásokat is biztosítanunk kellett. A felhasználók nyomtatási igényének is eleget kellett tennünk, így a használni kívánt nyomtatók driver-eit begyűjtöttük és feltelepítettük a szerverre. A nyomtatás mellett az adatfeldolgozás szükségessé tette az ftp hozzáférést is, melyhez természetesen hozzá tartozik a fizikai tárhely biztosítása. A felhasználóknak email-ben kell jelezniük ezen igényüket a Hallgatói Információs Központ felé, amely rendelkezik egy általános email címmel, melyet a hallgatók is használhatnak bármilyen információ és segítség kérésére. A begyűjtött adatok és a folyamatos monitorozás alapján, megállapítottuk, hogy a rendszer leterheltségének egyik kiküszöbölendő oka az ORACLE adatbázis beállítása. A 180 feletti felhasználó szám nem indokolna működési nehézségeket, tapasztalataink szerint mégis fennakadást okozott a 200 körüli létszám kiszolgálása. Különösen a tantárgyfelvétel és vizsgajelentkezés idején, amikor a hallgatók szinte rohamszerűen használják a rendszert.
2. ábra.
3. ábra.
Hosszú távú megoldást végül az jelentett, hogy sikerült egy nagyobb kapacitású adatbázisszervert beszerezni UNIX operációs rendszerrel, és a terminálszerverek számát is növelni tudtuk. Egyetértettünk abban, hogy ORACLE szakértőt is csak az új szerverek beállítása után kérjünk fel a rendszer hangolására.
4. A Neptun erőforrások fejlesztése és annak hatása A terminálszerver, mely egy IBM, x235 Xeon DP 2x2.4 GHz/400MHz CPU-val, 2 GB SDRAM-mal, és 2x36 GB HDD-vel rendelkezik. Az új terminálszerver az adminisztrátori feladatok ellátásához lett bekonfigurálva a NeptunA szerver mellé. Operációs rendszere Windows 2000 Server, tehát ugyanolyan környezet lett kialakítva, mint a többi terminálszerveren. Az új terminálszerver neve: Neptun-TO lett, és csak a Tanulmányi osztály dolgozói számára érhető el, saját azonosítóval. Az adatbázis szerver, mely egy IBM pSeries 615 –s szerver, 2.5 rPerf értékű processzorral, 2x36 GB HDD-vel és 2x2048 MB RAM-mal rendelkezik, illetve 2 Gbps-os Fiber Channel interfésszel kapcsolódik a tárolóhoz, mely 1 db storage szerver (FastT200 Storage Server) 0.7 TB HDD-vel. Az új adatbázis szerver operációs rendszere AIX 5.2, és Oracle 9.2 adatbázis kezelő került feltelepítésre és beparaméterezve. Egyik fontos szabályozási terület az AIX 5L (5.2) operációs rendszer, operációs rendszer szintű illesztése az Oracle 9i adatbázis kezelőhöz. Az IBM legújabb ajánlásai alapján JFS2 filesystem segítségével lett kialakítva minden partíció. Ennek használatával lehetőség van 2 GB-nál nagyobb állományok létrehozására és kezelésére. A diszk alrendszer partícióinak elérését többféleképpen lehet kialakítani. Lehet hagyományos elérés, az OP szintű állománypufferelés (file cache), vagy a közvetlen, nem pufferelt elérés (direct IO - DIO, concurrent IO - CIO). Az IBM CIO típusú filesystem opció használata esetén közel (5-10%) olyan sebességet tud produkálni, mint ha RAW típusú partíciót kezelne. A Neptun rendszer Oracle9i RDBMS verzión való működése új szemléletű paraméter beállításokat kíván meg a korábbi Oracle8i verziótól eltérően. Ezek a paraméter állítások a rendszer működésének sebességét és teljesítményét szabályozzák, a rendszer bénító hatású leállására nincs közvetlen szerepük. Mégis az elmúlt hetekben tapasztalható volt a rendszer enyhe bénulása, mely úgy jelent meg, hogy a rendelkezésre álló memória terület nullára csökkent. Több konzultáció és elemzés után nyilvánvalóvá vált, hogy sem az előbb említett paraméterek módisítása, sem az AIX hangolható KERNEL paraméterei nem okozhatták a rendszer lassulását. Az operációs rendszer szintjén történt KERNEL paraméterváltoztatások, tapasztalati úton szerzett, több helyen kipróbált, letesztelt és biztonságosan működő AIX környezetből származnak. Így az először alkalmazott CIO technika az egyetlen olyan elem, amely okozója lehetett a felmerült problémának. Ennek bizonyítéka, hogy visszaállítva a filesystem-eket alaphelyzetükbe (kikapcsolva a CIO) a rendszerre korábban jellemző túlzott memória felhasználás megszűnt. A Neptun felhasználók számának növekedése esetén sem jelentkezett a teljes virtuális memória felhasználása, és a szerver átlagos teljesítménye a korábbi állapothoz képest erősen feljavult. A vmstat statisztikát figyelve követhető volt a CPU kihasználtsága 2004. március 25-én, amikor a bejelentkezett felhasználók számának átlaga 85 volt: CPU processz User System Idle Waiting I/O
CPU terheltség 9% 2% 84% 5%
Az előbbiekben részletezett fennakadás kiküszöbölése megtörtént, melynek hatása erőteljesen érezhető a rendszer működésén. Az elmúlt hetekben szerzett tapasztalatok azt mutatják, hogy az új hardver konfiguráció beüzemelése szükséges volt, illetve az operációs rendszer és oracle paraméterek módosítása is javító hatással bírt. A rendszer működését mind operációs rendszer szinten, mind pedig oracle szinten folyamatosan nyomon követjük. Ehhez jelentős segítséget nyújt a Java alapon fejlesztett
StatsPack böngésző, mely egy grafikus megjelenítő. A programcsomag által létrehozott strukturált adathalmazból az adatbázis működését jellemző összes információ kinyerhető. A sokrétű és nagyon részletesen eltárolt adatokból többféle jelentést lehet készíteni. A jelentések lehetnek összegző típusúak és lehetnek elemi adat részletességet tartalmazóak is. Az Oracle SW csomag tartalmaz egy összesítő jellegű jelentést, amely az adatbázis működésének fontosabb területein mért adatokból készül. A jelentések többsége egy-egy specifikus terület egy-két értékét kérdezi le. A kapott adathalmazok kiválóan használhatóak különböző kimutatások, grafikonok elkészítéséhez. A jelentés akkor ad használható kimenetet, ha a kezdeti és vég mintavételi azonosító (snapshot ID) között nem volt adatbázis újraindítás. A hardver fejlesztés során a mentési stratégiát is átdolgoztuk, és új szabályokat állítottunk fel. A Neptun adatbázis mentése eleinte mágnes szalagra történt, de jelenleg a mentés az Oracle SW csomag részeként meglévő Recovery Manager (RMAN) segítségével zajlik. Az adatbázis működésének hatékonysága érdekében az RMAN által támogatott on-line mentési módszert alkalmaztuk, és ennek következtében az adatbázis 7x24 órában képes üzemelni. A mentés minden nap hajnal három órakor indul el, és szombatonként pedig teljes adatbázismentés történik, amikor is minden adatbázis blokk elmentésre kerül. A hét többi napján a mentés inkrementális, csak azok az adatblokkok mentődnek el, amelyek az előző mentéshez képes megváltoztak. Az adatbázis blokkon kívül elmentésre kerülnek a kontrol állományok, a paraméter állományok (spfile, pfile) és az archivált napló állományok is. A mentési folyamat az AIX operációs rendszer CRON eszközének segítségével került időzítésre. Az indítást egy script végzi root felhasználói jogokkal, amely meghív egy másik scriptet, és oracle felhasználói jogosultsággal futtatja az általa meghívott RMAN scripteket.
4. ábra. Memória használat a NetptunDB2 adatbázis szerveren A folyamat során keletkező úgynevezett backupset-ek egy könyvtárban tárolódnak el ideiglenesen. Az adatbázis mentés befejezését követően egy script megvizsgálja a mentésről készült napló állományt, és a vizsgálat eredményétől függően, üzenetet küld a megadott email címekre. Ezután visszaadja a vezérlést a vezérlő scriptnek, amely a mentés során keletkezett állományokat a gzip utility segítségével összetömöríti. Az összetömörített mentési állományok végleges alkönyvtárakban kerülnek eltárolásra. Ide kerülnek a mentések során keletkező eseményekről készülő napló állományok is, melyek heti gyakorisággal felülírásra kerülnek. A DE által megfogalmazott szabályok szerint az összetömörített mentési állományok heti gyakorisággal DVD-RAM médiára kerülnek kimásolásra. A másolás folyamatát nem lehet automatizálni, mivel a DVD-RAM lemezek
cseréje a meghajtóban csak manuálisan végezhető el. A másolás folyamata sok UNIX rendszer adminisztrátori tevékenységet foglal magába, és a fennálló szabályok szerint minden héten, pénteken kell a másolást elvégezni. A másoláshoz nyolc darab kétoldalas DVD-RAM lemez került kijelölésre, oldalankét 4,7 GB nyers tároló kapacitással. A mentési állományok jelenlegi mérete alapján egy heti teljes mentés ráfér egy-egy lemez oldalra, ennek következtében 16 hét hosszú mentési ciklust lehet kialakítani.
5. Konklúziók A felhasználók nyomtatási igényének eleget tettünk, vagyis a nyomtatók driver-ei felkerültek a terminál szerverekre, azonban a nyomtatási sorrend kezelése operációs rendszer szinten megoldásra vár. A felmerült probléma a Windows 2000 Szerver terminál szerver nyomtató session kezelésének sajátos tulajdonsága, mely nem nyomtató gyártó és nem driver specifikus. Az egyetem hallgatói létszáma újabb hardver fejlesztéseket igényel, mivel jelenleg két darab terminál szerver szolgálja ki a részükről érkező kéréseket. Terveink szerint, további két szerver segítené majd a szerverfarm hallgatói hozzáférését, tehát összesen 4 terminál szerver között oszlana meg a nap, mint nap bővülő terheltség. Az adatbázis szerveren alkalmazott CIO technika kikapcsolását átmeneti megoldásnak szántuk, véleményünk szerint szükséges a szerver memória bővítése minimum 2 GB RAM-mal. Nem csak hardveres bővítést tervezünk, hanem a terminál szerverek operációs rendszerének update-je is időszerű. A jelenlegi Windows 2000 Server helyett Windows 2003 Server telepítése a közeljövőben várható. Természetesen, ezzel egyidejűleg, a terminál szervereken levő Oracle 8.1.7 Client – ről Oracle 9.2 Client update-je is megtörténik. Az előadás a kiépített szerverfarm és a hálózati elemek erőforrásainak használatát részletezi, amely alapján a szükséges fejlesztési lépések és azok időszerűsége, valamint az üzemeletetési technikák bevezetése prognosztizálhatóvá válik. Az elemzés során felgyült gyakorlati tapasztalatot megosztjuk másokkal is, így a hasonló alkalmazást üzemeletető egyetemek, főiskolák számára a saját Neptun rendszerük napi üzemeltetési munkájának optimalizálása egyszerűbbé tehető. Irodalom [1] Cím1 [2] Cím2 [3] Cím3 [4] Cím4 [5] Cím5
