15 Rendelkezésre állás növelését segítő eljárások. Az informatikai rendszerek a termelő tevékenység részeivé váltak, nélkülük a vállalatok tevékenysége jelentősen romlik, vagy teljesen leáll. A folyamatirányító rendszerek működésének hibája, a beépített alkatrészek nagy száma miatt a rendelkezésre állás értéke nem javítható egy határon túl. Ipari környezetben számolnunk kell a hálózat egy részének fizikai sérülésével is. A lehetséges számtalan hiba mellett kell az üzleti logikából, vagy a műszaki paraméterekből adódó megbízhatóságú rendszert létrehoznunk. Kézenfekvő, hogy először az elemek megbízhatóságát kell növelnünk. Ennek egy adott technológiai színvonal mellett erős korlátai vannak. (Nem valószínű, hogy sikerülne a forgó alkatrészek 30-50 000 órás élettartamát 500 000 órára növelni). A megoldás a redundáns rendszerek használata. A redundancia azt jelenti, hogy funkcionális elemekből többet építenek be a rendszerbe, mint a funkció teljesítéséhez minimálisan szükséges, és ezek az elemek át tudják venni a meghibásodott elem funkcióját. Az utóbbi kritérium teljesítése sokszor komoly nehézségekbe ütközik. Alkatrész szinten pl. egy kondenzátor meg is szakadhat, és zárlatossá is válhat. Két párhuzamosan kötött kondenzátor zárlat esetén ugyanannyit ér, mint az egyetlen. Szakadás esetén viszont van redundancia a megoldásban. A meghibásodás hatását nem szabad átvinni a jól működő rendszerbe.
15.1 Részegység szint A részegység szintű megbízhatóság jelentősen növelhető, ha a részegység várható hibáját előre tudjuk jelezni. Nagyon jó előrejelzés adható pl. a diszkek várható meghibásodásáról. A „Predictive Failure Analysis” (IBM) általában katasztrofális meghibásodás előtt 36 órával 98% valószínűséggel meg tudja „jósolni” a hibát. Hasonló feladatokat lát el, más márkanéven az „Intelli Safe” (Compaq, HP) rendszer is. A jóslás alapja: fordulatszám szabályozó áramingadozása író/olvasó fejek repülési magasságának ingadozása hőmérséklet emelkedése hibásan olvasott szektorok újraolvasásának gyakorisága felpörgési idő változása. Mindezek együttes figyelése a diszk életképességét jól jellemzi. Jóslásokat lehet tenni a memória állapotára is ( hibajavító memóriáknál), ha figyeljük a javított hibák számát. (A nem javított memóriahiba észlelése már nem előrejelzés, hanem működési hiba, amire az egység leállításával reagálhatunk). Létezik olyan megoldás is, hogy egy-egy memóriszegmenst az ellenőrző rendszer kiiktat, és azon részletes tesztet futtat. Ha hibátlan akkor visszakapcsolja. Ellenkező esetben hibajelzést hoz létre, és a szegmenst kitiltja a működésből. A hibajelzéseket a kezelőszemélyzetnek át kell adni. A szerverek általában rendelkeznek DMI (Desktop Management Interface) felülettel, ami lehetővé teszi a fontosabb jellemzők távfelügyeletét és riasztások küldését a kezelő személyzet és a szervisz számára.
A meghibásodások elhárítása legegyszerűbben a rendszer leállításával és a részegység cseréjével oldható meg. A leállás azonban rontja a rendelkezésre állási mutatót. A rendelkezésre állás jelentősen javítható, ha a cserék „menet közben” végrehajthatók. Ehhez az kell, hogy a meghibásodott részegység szerepét egy másik átvegye (redundáns legyen), továbbá az, hogy az egység mechanikus és villamos szempontból ki és beszerelhető legyen további egységek működésének leállítása nélkül. Az üzem közben cserélhető egységeket „hot-swap” (melegen cserélhető) egységeknek nevezik. Leggyakrabban a forgó, mozgó alkatrészt tartalmazó modulok hibásodnak meg. tápegység diszk ventilátorok A leggyakrabban meghibásodó egységek redundánssá tételével, a minőség javításával, a „hot-swap” egységek alkalmazásával elérhető a 99 % - 99,5 %-os rendelkezésre állás egy egyedülálló szerver esetén. Sok esetben azonban 99,5%-os rendelkezésre állási mutató nem elegendően jó. A 0,5 % kiesés éves szinten több mint 1,5 nap! A részegységek minőségének javítása nem járható út. Belátható, hogy egy soha meg nem hibásodó egység sem oldaná meg a karbantartás, teljesítmény hangolás miatt kieső idő problémáját. A rendszerkiesés idejébe a tervezett leállás, szoftverkarbantartás is bele tartozik. Olyan megoldások kellenek, ahol a karbantartás, skálázás, szoftver módosítás megoldható a szolgáltatás leállítása nélkül. Redundánsan felépített rendszerekre van szükség. A redundancia mértéke az alkalmazás igényeitől függ. Nem azonos szintet várunk egy erőmű turbináját irányító rendszertől, mint egy egyfős könyvelést kiszolgáló géptől.
15.2 Redundáns hálózatok A redundáns rendszereknél célszerű külön foglalkozni a média redundáns, eszköz redundáns rendszerekkel. 15.2.1 A média redundáns rendszerekben az adatátviteli útvonal egypontos sérülése nem okoz működési kiesést. Az aktív eszközök többszörösen össze vannak kötve, és egy az útvonalakat koordináló algoritmus dönti el, hogy melyik útvonal az aktív. Az ETHERNET hálózatokban a feszítőfás algoritmusok (IEEE802.1D, Spanning Tree) terjedtek el. Ipari hálózatoknál alkalmazott megoldás az „ETHERNET gyűrű”. Topológiailag valóban gyűrűs hálózatról van szó, de működés szempontjából egy nyitott, hurok mentes kapcsolat jön létre. A fizikai hurok megszakítása valamelyik port kimenetének tiltásával az RSTP (IEEE 802.1W) algoritmus feladata.
15.1 ábra. Ipari ETHERNET hibátlan állapotban Könnyen belátható, hogy a hálózat bármely pontján megszakítva az adatátviteli közeget, átkonfigurálható a rendszer úgy, hogy minden aktív eszköz működhessen tovább. Az átkonfigurálást az RSTP algoritmus vezérli. A konfigurációt nem kell feltétlenül csak a szabványos algoritmusra bízni. Általában megadhatunk előre definiált sémákat is. A prioritások beállításával is van mód az üzemállapotok befolyásolására.
15.3 ábra. Ipari ETHERNET egy szakadással Az ábrán hálózat átkonfigurálása után az eddig inaktív (piros) szegmensen keresztül van kapcsolat az aktív elemek között. Aktív eszköz meghibásodása esetén az arra csatlakozó készülékek nem érik el a hálózatot. Alternatív útvonalat kell létrehoznunk. 15.2.2 Az eszköz redundancia azt jelenti, hogy aktív eszközöket úgy rendezzük el, hogy meghibásodás esetén is minden végpont működőképes maradjon.
15.4 ábra. Eszköz-redundáns csatlakozás a hálózatra. A PLC két switch-re csatlakozik. Az aktív switch meghibásodása esetén a másik válik aktívvá. Ha a másodlagos készülék hibásodik meg, akkor csak hibajelzés keletkezik, a működés változatlan marad.
15.5 ábra. Működés egy redundáns aktív elem meghibásodása után. Vegyük észre, hogy az atív elem meghibásodása megszakította a hurkot is. A hálózat egy média hiba esetén már szétesik. Az aktív eszközök redundanciája mellett tehát célszerű biztosítanunk a média-redundanciát is. Irodai rendszereknél a szerver oldal redundanciájával legtöbb esetben megelégszenek. A hálózat, és az aktív elemek nem hibatűrőek. Ipari rendszerekben többnyire a média redundanciát valósítják meg. Az aktív elemek redundáns beépítése csak a nagy megbízhatóságot igénylő iparágakban (erőmű, olajipar, repülés) szokásos.
A média redundancia egyszerű esetben a kábelezés többszörösét jelenti, de jelentheti azt is, hogy más média típusra kapcsolunk át. Kábeles összeköttetés helyett pl. műholdas kommunikációra. Az ábrán egy ipari ETHERNET hálózat redundáns elemeit és kapcsolatait látjuk.
15.6 ábra. Eszköz és média redundáns hálózat
15.7 Eszköz és média redundáns hálózat média hibákkal Belátható, hogy a rendszer működőképes marad bármely aktív elem hibája esetén is, és többszörös kábelhiba sem okoz működés kiesést.
A két hurok egyidejű megszakítása is csak néhány speciális esetben ( a szakaszra csatlakozó aktív elem egyidejű meghibásodásakor) okoz kiesést. A nagy megbízhatóságú hálózatok tervezése a gyakorlatban rendkívüli gondosságot kíván. Sokszor nehéz eldönteni, hogy az alkalmazott megoldásban a redundánsnak hitt rendszer valóban redundáns-e. A valóságban bekövetkező esemény nem egyszerre teszi-e tönkre valamennyi eszközünket. Végig kell gondolnunk, hogy a villamos betáp hálózat állapotai hogyan hatnak a rendszerre. Hol okoz kiesést a rendszert érő villámcsapás, túlfeszültség? Mi történjen, ha életvédelmi okokból kapcsol le a hálózat? Mi történjen tűzjelzés esetén, stb…? Az elemek nem csak kétszerezhetők. Többszörös redundancia is építhető a rendszerekbe. A nagy utasszállító repülőgépeknél legalább 3 független BUSZ – rendszer köti össze a részegységeket. Működnek olyan banki rendszerek, ahol az információ egy időben, 2 helyszínen, összesen 12 diszkre íródik fel párhuzamosan. Ezek extrém megbízhatóságot követelő rendszerek, ahol az adatvesztés, vagy a szolgáltatás kiesés esélyét nagyon alacsony értéken kell tartani. A hardveres redundancia természetesen csak része a védelmi stratégiának. Önmagában nem oldja meg a feladatot.
15.3 Kiszolgálókban alkalmazott redundáns megoldások. A kiszolgálók működésében két alapvető követelményt kell teljesítenünk: szolgáltatások magas rendelkezésre állása az adatok integritásának védelme A szolgáltatások rendelkezésre állásán túl, a kiszolgálás folytonossága alapján két további alcsoportot kell megkülönböztetnünk: A kiszolgáló folyamatos működést biztosítson akkor is, ha egyes elemei meghibásodnak. A program futása nem szakad meg, a folyamatok nem indulnak újra. A felhasználó oldaláról nem érzékelhető a hiba. Hiba esetén a folyamatok újraindulnak. A félbemaradt tranzakciók visszabontásra kerülnek, és újraindulnak a jó hardver/szoftver környezetben. Az első csoportba sorolhatók pl. a folyamatirányító rendszerek, a real-time rendszerek . Erre a feladatra a hibatűrő rendszerek alkalmasak. A hibatűrő rendszerekkel el lehet érni 99,99 – 99,999 %-os rendelkezésre állást. Nagy előny, hogy a hibatűrő szerverek nem igényelnek semmiféle módosítást a felhasználói szoftverben. A cluster technológia ott hatékony, ahol magas rendelkezésre állás szükséges, a folyamatos kiszolgálás igénye nélkül. A kiszolgálók számának növelésével a rendelkezésre állás szinte tetszőlegesen javítható. Megoldható a szolgáltás leállítása nélküli karbantartás, kapacitás bővítés, szoftver módosítás. A folyamatos, megszakítás nélküli kiszolgálás ellenben nem biztosítható. Probléma mentesen alkalmazható a cluster technológia állapotmentes kiszolgálók esetében. Tipikusan állapot-mentes kiszolgáló pl. Web-szerver. Minden kérés független az előzőtől, nem igényli a korábbi állapot ismeretét. Azonos adatállománnyal rendelkező szerverek között tetszőlegesen szétosztható a kiszolgálás. A valós helyzet ugyan valamivel bonyolultabb, mert a kapcsolat hitelesítése után a kérés áthelyezése biztonsági prolémákat vet fel. Ezeket a problémákat belső azonosítók használatával lehet feloldani.
Az egyes technológiák pozicionálása rendelkezésre állás mértéke és teljesítmény szerint:
15.8 ábra. A technológiák pozicionálása a teljesítmény és rendelkezésre állás alapján. Láthatjuk, hogy a hibatűrő megoldásokkal lehet a legmagasabb rendelkezésre állást (gyakorlatban 99.999% is elérhető) biztosítani. A teljesítmény a vállalati rendzsrek alsó szegmense számára elég. Logikailag ellentmondásosnak látszik, hogy a clustrek „lemaradnak”. FT szerverekből is lehetne clustert építeni, és akkor még javítható lenne a rendelkezésre állás. Ez elvben igaz, de a gazdasági racionalitása kérdéses a megoldásnak. A „Data Center” kategória, párosúlva a nagy megbízhatósági igénnyel, általában egyedi tervezést igényel. Itt már számíthatunk arra, hogy a felhasználó rendelkezik kellő számú, jól képzett informatikussal. A hibatűrő szerverek egyszerűen installálhatók, üzemeltethetők. Nem igényelnek speciális ismereteket, így jól illeszkednek az ipari elvárásokhoz. A személyzet a folyamatirányítási kérdésekre koncentrál, nem az informatikai háttér üzemeltetésére. 15.3.2 Hibatűrő rendszerek. A hibatűrő rendszerek hardveres biztosítják a magas rendelkezésre állást. A szoftverek telepítése, a rendszer üzemeltetése nem tér el lényegesen egy hagyományos, egyedül álló szerver üzemeltetésétől. Az egyes modulok menet közben cserélhetők. A szerverek általában tartalmaznak saját kijelzőt, ahol a hibaüzenetek megjelennek. A CPU Lockstep a két rendszer szinkronját biztosítja. A két CPU modulban az utasítások azonos időben hajtódnak végre, a programok azonos állapotban vannak. Ez teszi lehetővé a „nulla idejű” helyreállítását a szolgáltatásonak. A „Lockstep” speciális chip-garnitúrát
(Pl.:GEMINI) igényel a CPU mellett. A rendszervázlatból látható, hogy a CPU és az I/O modul független, és a két ág kölcsönösen tudja használni egymás moduljait. A diszkek szinkronizálása is megmarad bármelyik I/O modul hibája esetén is. Fontos gyakorlati kérdés, hogy a szerverek áramellátását is redundánsan oldjuk meg. Mérsékelt a haszna egy redundáns tápnak, ha az egyébként független modulok ugyanarra a szünetmentes tápra csatlakoznak.
15.8 ábra. Két modul-csoportot tartalmazó (Dual Module) hibatűrő rendszer (NEC Express 5800/ft szerver)
15.9 ábra. Hibatűrő rendszer modul meghibásodásokkal. Látható, hogy a rendszer több modul meghibásodása esetén is működőképes marad. A hibás modulokat természetesen cserélni kell, mert az azonos funkcionális egységet érintő második hiba már végzetes lehet.
15.3.3 Replikák alkalmazása. Az egypontos hibák hatásának csökkentésére alkalmas eszközök a „replikák”, másolatok. Belátható, hogy a teljes számítógép többszörözése a hibák hatásának csökkentésére a legjobb megoldás. Az így többszörözött rendszer teljesítménye azonban valamival kevesebb, mint egyetlen egyedül álló számítógép teljesítménye. A több párhuzamos rendszer potenciálisan nagyobb teljesítménye elvész. Ha kompromisszumot kötünk az adatbiztonság és a rendelkezésre állás területén, akkor egyszerűbb, olcsóbb megoldásokat is választhatunk. Tudatában kell lennünk annak, hogy ezek a módszerek kompromisszumok. Nem érdemes azonban egy adat megőrzésére fordítani, mint amennyibe az újraelőállítása kerül. Pl.: egy könyvelési tétel bevitele megoldható akkor is, ha ha egy műszak adatati elvesznek, mert minden bizonylat papír hordozón is megtalálható. A többleköltség az utolsó mentés óta felvitt bizonylatok újrarögzítésének költsége. Más költséggel kell számolnunk akkor, ha a késedelem miatt pl.: elvesztünk egy tendert. Teljes fájl másolatok A teljes fájl másolatok készítését minden operációs rendszer lehetővé teszi. A folyamat általában időszakos. Egy időpontnak megfelelő állapotot fagyasztunk be. Vannak eszközök a szinkron automatikus biztosítására is, de ezek is csak időszakosan szinkronizálják a fájlokat. Ritkán változó állományok esetén hatékony csak a megoldás.
Hardver replika A legegyszerűbb esetben a diszk másolatát állítjuk elő. A másolat véd a diszk hibák ellen, és hot-swap diszkek esetén a csere menet közben is elvégezhető. Ha a másolat azonos helyen van a primer diszkekkel, akkor nem véd a lokálisan fellépő behahatások ellen (tűz, robbanás természeticsapás, stb..). Ha távolabbra helyezzük a tükrözött állományt, akkor speciális hardver költségeivel kell számolnunk. Kizárólag a diszk meghibásodások ellen véd. ADAT MÓDOSTÁS
ALKALMAZÁS
OPERÁCIÓS RENDSZER
Fá jl /di s
FÁJL RENDSZER
TÁROLÓ
TÁROLÓ szinkron írás/olvasás
15.10 ábra. Mágneslemezek tükrözése
Alkalmazás replikáció (Application replication) Az alkalmazás csak a saját adatait másolja, más alkalmazásokra nézve nincs redundancia. A megoldás szinte kizárólag az adatbázis-kezelő rendszerek sajátja. Az adatok küldésének gyakorisága (szinkronizálás) a teljesítmény és a konzisztencia közötti „egyensúlyozás.” A tranzakciós log („log shipping”) küldése periodikus (pl.: Misrosoft SQL), ami egy összeomlás utáni helyreállításkor kritikus lehet. A periodikus szinkronizálás nem biztosítja mindig a primer rendszer és a replica azonosságát.
ADAT MÓDOSTÁS
Fá jl /di s
ALKALMAZÁS
Ci kl i kus á tvi tel
ADAT MÓDOSTÁS
ALKALMAZÁS
OPERÁCIÓS RENDSZER
OPERÁCIÓS RENDSZER
FÁJL RENDSZER
FÁJL RENDSZER
TÁROLÓ
TÁROLÓ
15.11 ábra. Alkalmazás replica Az alkalmazás replikácó több másolatot is létrehozhat. A cél nem csak a biztonság növelése, hanem a kiszolgálás teljesítményének növelése is lehet. A kérést az a szerver fogja kiszolgálni, ahol várhatóan a legkevesebb lesz a várakozási idő.
Szoftver replika A szoftver replica alkalmazás független megoldás. Jelentős előny, hogy nem kell hozzá speciális hardver. A kiszolgálás „közel folytonos”. A helyreállási idő másodperces nagyságrendű.
ADAT MÓDOSTÁS
ere deti
ALKALMAZÁS
írá s kérés tükrözés e
ALKALMAZÁS
OPERÁCIÓS RENDSZER
OPERÁCIÓS RENDSZER
FÁJL RENDSZER
FÁJL RENDSZER
TÁROLÓ
TÁROLÓ
15.12 ábra. Szoftver replika. A program az operációs rendszer drivereit figyeli, és kiszűri az I/0 utasításokat. Az írási utasításokat adja át a tükörként működő rendszernek. Ez jelentősen csökkenti az adatforgalmat, és lehetővé teszi, hogy a „tükör” rendszert nagy távolságban telepítsük. A két rendszer diszk-méretének nem kell azonosnak lenni. A másolat-diszken elegendő a primer rendszer ténylegesen foglalt területének megfelelő hely.
15.13. ábra. Több produkciós szerver adatai egy háttérgépen
Egy háttér-gépre több primer szerver adatai is tükrözhetők. Jól használható a rendszer alkalmazások szétosztására is. A tükör-rendszerről másolhatók az adatok és alkalmazások a primer szerverekre. Járulékos előny, hogy a közös háttérgépről konzisztens mágnesszalagos mentés is létrehozható a primer rendszer lassítása nélkül.
Cluster technológia A cluster technológia lényege, hogy több szerver-nód (server node) van logikai kapcsolatban egymással. Az alkalmazások futtatásának aktuális helyét a koordinátor szerver határozza meg. Egy aktív nód, vagy a szerver hálózati kapcsolatának meghibásodása estén az aktuális vezérlő gondokodik a feladatok áthelyezéséről. Hiba esetén a meghibásodott szerveren futó alkalmazást egy működő nód-ra helyezi át a rendszer. Az egyes nód-ok közös tárolórendszerre kapcsolódnak. A közös tároló biztosítja az adatok konzisztenciáját, és a „tudathasadás” felismerését. (Tudathasadás az az eset, mikor több szerver hiszi magáról, hogy ő az egyetlen működő kiszolgáló a hálózatban). A cluster önmagában nem biztosítja a tárololt adatok adatvesztés elleni védelmét. A tárolórendszer redundanciáját a clustertől függetlenül kell megoldani. A cluster a szolgáltatás rendelkezésre állását biztosítja úgy, hogy a hibás nod-on futó taszkot újraindítja egy működő, és elérhető nod-on. Nem foglalkozik az adatvesztés kiküszöbölésének módjával.
Hálózati csatoló
ADAT MÓDOSTÁS
ALKALMAZÁS
ALKALMAZÁS
OPERÁCIÓS RENDSZER
OPERÁCIÓS RENDSZER
FÁJL RENDSZER
FÁJL RENDSZER
KÖZÖS TÁROLÓ
Háttér rendszer Kijelölt rendszer
15.14 ábra. Klasszikus Cluster elrendezés
