Gyakran feltett kérdések
Hibakeresés NetWare szerveren – Abend-ek kezelése
Mi az a szerver abend?
A szerverkonzolon megjelenő abend-üzenetek arra utalnak, hogy vagy a NetWare, vagy a szerver CPU-ja kritikus állapotot (hibát) azonosított, és elindította a NetWare hibakezelőjét. Ez a kezelőprogram leállítja a NetWare-t és megjeleníti az abend-üzenetet a szerverkonzolon és azonnali reakciót vár a szerver rendszergazdájától.
A CPU által felderített hibás állapotokat vagy hibákat processzorkivételnek (processor exception), a NetWare által felderítetteket szoftverkivételnek (software exception) nevezzük.
A NetWare hibakezelő funkciója nyílt, abban az értelemben, hogy bármely operációsrendszer-modul vagy Novell NLM használhatja (Abend Recovery Techniques for NetWare Servers. 1995. június, Application Notes, 79.o.)
A NetWare operációs rendszerek folyamatosan figyelik a különböző szervertevékenységeket a helyes működés érdekében. Ha a NetWare olyan állapotot észlel, amely veszélyezteti a belső adatok integritását (ilyen lehet például egy érvénytelen paraméter egy funkcióhívásnál, vagy bizonyos hardverhibák), akkor megszakítja az aktív folyamatot és egy ún. abend-üzenetet ír ki a képernyőre. (Az „abend” egy szokásos rövidítés programok abnormális leállására – abnormal end.)
A NetWare abendjeinek elsődleges szerepe, hogy biztosítsák az operációs rendszer stabilitását és a belső adatok integritását. Ha például az operációs rendszer érvénytelen értékeket talált a cache-pufferek mutatói között, és nem áll le, akkor az adatok rövidesen használhatatlanná válnak vagy megsérülnek. Így az abend a NetWare egyfajta védekezési mechanizmusa, amellyel magát és a felhasználókat óvja az adatsérülés nemkívánatos hatásaitól. (Resolving Critical Server Issues. 1995. február, Application Notes, 37.o.)
Jelen anyagban az abend kifejezést a lehető legszélesebb értelemben használjuk, beleértve mindenféle típusú kivételt, azokat is, amelyek lefagyasztják a szervert.
Abendek hibakeresése - Első lépések
Szerverabend (illetve gyakorlatilag bármely más probléma) esetén tekintsük át az alábbi karbantartási lépéseket, mielőtt bármi máshoz fognánk. A tapasztalat azt mutatja, hogy az abendek nagy százaléka kijavítható az operációs rendszer szervizcsomagjainak üzembehelyezésével, illetve a hálózatikártya- és lemezmeghajtó-programok frissítésével. A minimális frissítési lista a http://support.novell.com/misc/patlst.htm címen olvasható. A Novell határozottan ajánlja, hogy legyen szó bármilyen problémáról is, tegyük fel a legfrissebb szervizcsomagokat és meghajtóprogramokat. Utána fontoljuk meg az alább felsorolt lépések megtételét.
MEGJEGYZÉS: Az NMI Parity hiba (abend: Non-Maskable Interrupt) hardverhiba.
Töltsük be az ÖSSZES ismert szoftverjavítást. Ezek célja az ismert problémák megoldása. 4.11 előtti NetWare-verzió esetében a letöltendő fájl neve <OS-verzió>PT<fájlrevíziószám vagy -betű>.EXE a „PT”-javítások és <OS-verzió>IT<fájlrevíziószám>.EXE az „IT”-javítások esetén (pl.: 410PT3.EXE és 410IT6.EXE). Mindkét típusú javítást töltsük be. (A javítások magyarázata a minimális frissítési lista oldalon látható.) NetWare 4.11 vagy NetWare 4.2 esetében az összes javítás egy csomagban található, NW4SP<fájlrevíziószám>.EXE néven. NetWare 5 esetében pedig NW5SP<fájlrevíziószám>.EXE a fájl neve.
Frissítsük a meghajtóprogramokat. Minden LAN- és lemezvezérlő kártya gyártója maga fejleszti meghajtóprogramjait. A legfrissebb változathoz csak úgy juthatunk hozzá, ha közvetlenül a gyártótól töltjük azokat le. Előfordul, hogy új hardvereszközök mellé régebbi meghajtóprogramot kapunk, ezért gondosan ellenőrizzük, hogy a lehető legfrissebbeket használjuk!!!
Keressünk elavult NLM-eket. A javítások pontosan azért készülnek, hogy stabilabbá/hasznosabbá tegyék a termékeket. A gyakran frissített NetWare NLM-ek általában önkicsomagoló letölthető fájlok formájában férhetők hozzá. Az aktuális javasolt minimális frissítési lista a weben, a Minimum Patch List (http://support.novell.com/misc/patlst.htm) oldalon olvasható. Ne felejtsük el a külső fejlesztésű NLM-ek frissítéseit sem ellenőrizni.
Ellenőrizzük a szerver DOS-partícióját, hogy nincs-e rajta vírus.
Tisztítsuk és igazítsuk meg a kártyákat és vezetékeket (MINDIG ügyeljük a statikus feltöltődés levezetésére.)
Ellenőrizzük a lezárásokat, az SCSI-azonosítókat stb.
Ellenőrizzük a ventilátorok helyes működését.
Antisztatikus sűrítettlevegős spray-vel fújjuk le az alaplapot, a kártyákat és az alkatrészeket.
Abendek hibakeresése - Adatgyűjtés
Helyesen elvégezve ez a lépés a legértékesebb a probléma azonosítása szempontjából. A leggyakoribb hiba az adatgyűjtés során a rövidlátás: csak az észlelt tünetekre koncentrálás. Az alábbi – részleges – lista hasznos kérdéseket tartalmaz; de ne szégyelljünk feltenni olyan kérdéseket sem feltenni, amelyeknek első látásra semmi köze sincs a problémához. Lehet, hogy tényleg nincs, de segíthet magasabb szintről vizsgálni a problémát. Akad, hogy az adatgyűjtés során egynél több potenciális problémára derül fény, és csak korlátozott erőforrások állnak rendelkezésre. Mégis, a teljes kép felmérése nélkül lehet, hogy teljesen értelmetlen irányban tapogatóznánk.
Jegyezzük fel az abend-üzeneteket és próbáljunk trendeket keresni. A következetesen megjelenő abend-üzenetek utalhatnak szoftverhibára, míg a nem következetesen megjelenők hardverhibára. Ez NEM ökölszabály, de esetleg segíthet elindulni.
Nézzük meg a rendszer hibanaplóját (SYS:SYSTEM\SYS$LOG.ERR). Akadhatnak nyomok, amelyek csak itt láthatók (hiba egy bizonyos csomóponton épp az abend előtt, egy adott fájl vagy nyomtatási sor hibája, kötetlekapcsolások stb.).
Mely erőforrásokat használta a rendszer az abend idején? (pl. nyomtatás, fájl, szalag, COM-port stb.)
A nap mely részében fordul elő az abend? Mindig ugyanakkor?
Légkondicionált-e a szoba? A túlhevülés is okozhat problémát.
Milyen a környezet? A száraz, poros és forró környezetek hozzájárulnak a túlhevüléshez és a sztatikus feltöltődéshez.
Vannak-e tápellátási problémák akár a szolgáltatónál, akár a becsatlakozásnál?
Fut-e egy bizonyos adatbázis-funkció (pl. újraindexelés)?
Nagy-e a LAN-forgalom? Magas-e a lemezírások vagy -olvasások száma?
Ha még az abend látszik a képernyőn, menjünk bele a debuggerbe, és olvassunk ki bizonyos alapadatokat, mint az EIP (utasításszámláló), a futó NLM, a futó folyamat.
A CONLOG.NLM-mel fogjuk el azokat a konzolüzeneteket, amelyek egyébként kiszaladnának a képernyőről. (Megjegyzés: ehhez persze be kell tölteni a CONLOG-ot.)
Van-e egy bizonyos felhasználó, szegmens, alkalmazás, szerverfolyamat (pl. a biztonsági mentés), vagy bármi más, amelynél tipikusan jelentkezik az abend?
Friss-e a kliensszoftver?
Tegyük fel a kérdést: „Mi változott a szerverkörnyezetben?”.
Alkérdések:Megnőtt-e a felhasználók száma?
Tettünk-e fel új szoftvert vagy szoftverfrissítéseket?
Másképpen használja-e valaki a szoftvert (pl. adatbázis-indexelés).
Van-e új vagy más hardvereszköz a hálózaton?
Változott-e a LAN, az útválasztók vagy a kábelezés?
Kerültek-e át munkaállomások vagy a fájlszerver más helyre?
Vannak-e új nyomtatók a LAN-on?
Volt-e áramkimaradás?
Változtak-e a SET-paraméterek?
Van-e valami új vagy erős elektromágneses kisugárzás a szerver vagy a vezetékek közelében? (Nagy motorok, fénycsövek, porszívó stb.)
Nyúltak-e a hardverhez megfelelő statikus védelem nélkül?
Kapcsoljuk be a SET DSTRACE = ON paramétert, majd nézzük a DSTRACE képernyőt (hibák vagy "All processed = Nő üzenet jelenik meg). Adjunk némi időt a DS-hibáknak, hogy eltűnjenek (15-60 perc általában elég idő kell, hogy legyen.)
Szakadnak-e le felhasználók a szerverről?
Sérültek-e fájlok?
Lekapcsolódtak-e meghajtók? Tükrözött partíciók esetében az egyik meghajtó lekapcsolódhat anélkül, hogy a szerver leállnak. Ellenőrizzük a hibanaplót.
Vannak-e nyomtatási problémák?
Szűrt-e a tápellátás? Ha igen, vizsgáltuk-e mostanában a szűrőhardvert? (Működik-e még?)
A MONITOR.NLM és az INSTALL.NLM igen hasznos NetWare-segédprogramok a szerverek állapotának diagnosztizálására. A legfontosabb paraméterek:
Növekvő csomagfogadási pufferek.
Növekvő „Packet discarded, no available puffers”-statisztika.
Alacsony szervermemória. A cache-pufferek kihasználtsága legalább 60% kell, hogy legyen.
Alacsony „LRU sitting time” érték (15 perc alatt).
Magas „Dirty cache buffers”-érték.
Sok LAN-hiba (több mint 10 százaléka az összes küldött vagy fogadott csomagnak).
Magas kihasználtság (ha sokáig, 10-20 percig magasan marad).
A „Service Processes” elérte a maximális értéket.
Partíció-, kötet- és tükrözési adatok.
NCF-fájlok tartalma.
CONFIG.NLM: &Eeacute;rtékes eszköz, amely adatokat gyűjt a szerver konfigurációjáról. E helyütt észrevehetünk olyan dolgokat, amelyek korábban nem tűntek fel. Mielőtt változtatnánk a beállításokon, dokumentáljunk. Szükség lesz erre akkor is, ha fel kell hívnunk a Novell műszaki tanácsadási szolgálatát.
FONTOS MEGJEGYZÉS: Előfordul, hogy a begyűjtött adatokat más forrásokkal kell összevetni annak megállapításához, hogy a látott értékek normálisak-e. Például teljesen normális működés, hogy a szerver kihasználtsága pár percre – esetleg tovább – felugrik 100 százalékra. Hasonlan, a csomagfogadási pufferek száma dinamikusan növekszik, a beállított maximumig. Sokszor a tapasztalat mondja meg, hogy mi normális, mi utal hibára. Figyelje folyamatosan a SAJÁT szervért, hogy megismerje, mi normális a SAJÁT környezetében. Szintén előfordul, hogy a DSTRACE hibákat jelez normális működés közben (ha pl. a címtár éppen egy kérést dolgoz fel, és egy másik még folyamatban van, akkor hiba jelentkezik, amíg az első nem végez). Fontos, hogy ismerjük, mi számít normális állapotnak az adott környezetben, hogy pontosan felismerjük, mi a valódi probléma és mi származik a hardver- vagy szoftver korlátaiból.
Abendek hibakeresése - Szűkítés (izoláció) és megismétlés
Az előző két szakasz gondos elvégzése után a hibakeresés lényegében a hiba izolálása, illetve a hiba megismétlése közötti oda-vissza lépkedésből áll. Más szavakkal, megkíséreljük behatárolni a problémát, ugyanakkor megkíséreljük reprodukálni azokat az eseményeket, amelyek a hibát okozzák. Nagyon egyszerűen fogalmazva, egy abendet vagy hardverhiba, vagy egy helytelenül működő NLM okozza. Mindkét esetben az eredmény általában sérült memória.
A probléma izolációja és megismétlése majdnem ugyanaz. A lényegi különbség, hogy az utóbbi esetben kifejezetten megismételni próbáljuk a hibát. Találhatunk egy NLM-et, amely minden egyes betöltésnél abendeli a szervert. Előfordulhat, hogy másolás közbeni bejelentkezés okoz hibát. Ha sikerült reprodukálni a problémát, akkor szűkíthetjük a változókat, egyesével, majd vizsgáljuk, hogy elmúlik-e a probléma. A probléma izolációja esetén az adatokból esetleg már sejtjük, hogy hol keressük a hibát, így ebben az irányba keresgélve megpróbáljuk egy adott komponensre leszűkíteni a problémát. Például biztos, hogy a lemezvezérlővel van a gond, mert mindig lemezhozzáférésnél történik a baj. Vagy mondjuk egy adott NLM-nél. Izolációnál próbáljuk az alábbi alrendszereket vizsgálni:
lemezvezérlő,
hálózati kártya,
alaplap
COM-port,
a NetWare OS
külső fejlesztésű NLM,
a vezetékek,
egy bizonyos típusú munkaállomás (WinNT/Win95/Win 3.1/DOS),
egy bizonyos típusú shell (VLM, Client32, külső fejlesztésű kliens).
Ne feledjük, hogy a cél azon események reprodukálása, amelyek a hibát okozzák, vagy legalább a probléma egy adott alrendszerre szűkítése. Az alábbi ötletek remélhetőleg segítenek a keresés során. A lista nincs sorbaszedve, csak nagyjából LAN, lemez és általános tanácsokra bontva.
A SERVER -NS vagy SERVER -NA parancsokkal indítsuk el a szervert a STARTUP.NCF illetve az AUTOEXEC.NCF nélkül. A SERVER -NS parancs a kötetek automatikus felkapcsolása nélkül indítja a szervert. (SFT III esetében is működnek ezek a paraméterek az ACTIVATE SERVER paranccsal.)
Mond-e valamit az abend-üzenet? LAN-csatorna, lemezcsatorna, memóriasérülés, alaplap-probléma, egy bizonyos NLM, nyomtatás, valamely hardvereszköz, egy bizonyos LAN-szegmens, munkaállomás, útválasztó, környezeti feltétel stb. A NetWare 4.11, a NetWare 4.2, és a NetWare 5 létrehoz egy ABEND.LOG nevű fájlt a SYS:SYSTEM könyvtárban, amely tartalmazza az aktuális és megelőző abend üzeneteket, valamint az abend idején betöltött modulok listáját.
Indítsuk el a szervert a SERVER -NA paranccsal (az AUTOEXEC.NCF végrehajtása nélkül). Ezután töltsük be az NLM-eket egyesével.
Indítsuk el a szervert a SERVER -NDB paranccsal, megakadályozva a DS-adatbázis betöltését (azaz kikapcsolva a címtárszolgáltatást). Ilyenkor nem lehet bejelentkezni a szerverre.
Mennyi idős a hardver? Ha semmi más nem történt, akkor lehet, hogy egyszerűen csak a hardver hibásodott meg. Ne tételezzük fel, hogy az új hardver mindig jó.
&Eeacute;rhette-e statikus kisülés a hardvert? A statikus kisülések nem mindig azonnal pusztítóak, sokszor csak olyan sérülést okoznak, amelytől a hardver még egy darabig működik.
Beszéljünk a külső fejlesztésű termékek gyártóival, hogy tapasztaltak-e hasonló problémát.
Ideiglenesen állítsunk le minden külső fejlesztésű NLM-et.
Állítsuk le a vírusellenőrzést, illetve a szerver- és LAN-figyelő NLM-eket.
Származhatnak-e tápellátási problémák a szolgáltatótól vagy a becsatlakozástól?
Ellenőrizzük a tápegység, a gép és a CPU ventilátorát. A túlhevülés hardverhibához vezet.
A száraz, forró vagy poros környezet okozhat hardverhibát az elektromos kisülések miatt. Növeli az NMI-hibák esélyét is.
Kerüljük a 15-ös, 2-es és 9-es megszakításokat (ebben a sorrendben).
Próbáljuk meg a hibát leszűkíteni egyetlen hardver-alrendszerre. Próbáljuk meg kicserélni a hardvert, vagy próbáljunk ki más kártyahelyet/megszakítást/stb.
Bár az abend-üzenet nagyon általános, néha segíthet irányt mutatni. A legtöbb abend memóriasérülést jelez. Mások a lemezműveletekre, ismét mások a LAN-műveletekre utalnak. Gyakran olvasható egy függvény neve az abend-üzenetben – például „abend: DeallocateMappedPage was supplied an invalid memory pointer.” A nagybetűs, szóköz nélküli szavak a NetWare-kód egy függvényére utalnak (esetünkben rossz memóriamutatót kapott a DeallocateMappedPage függvény). Ha az abend tartalmazza az „....interrupted....” szavakat, érdemes lehet megnézni a LAN-csatornát, ugyanis messze a LAN generálja a legtöbb megszakítást a szerverben.
Tisztítsuk és igazítsuk meg a kártyákat és vezetékeket. Ne feledkezzünk meg a statikus feltöltődés elleni védekezésről.
Mikor lett telepítve a szerver? Ha friss telepítés (kevesebb, mint egy hónapos), akkor még mindig lehetnek konfigurációs és beállítási problémák – vagy lehet, hogy hibás a hardver, még akkor is, ha új.
Ellenőrizzük, hogy a legfrissebb BIOS-t használja a hardver.
Ha van, futtassunk hardverdiagnosztikai programot a gépen.
Ha a LAN-csatornával van baj, próbáljuk meg egy másik gyártó kártyájára kicserélni a LAN-kártyát.
A SERVER.EXE, csakúgy, mint minden más fájl, sérülhet, és ezt nagyon nehéz megállapítani. Ha leszűkítettük a környezetet a szerverre, a lemezeszközökre és a LAN-ra, érdemes megpróbálni a SERVER.EXE (és mellesleg minden más NLM) egy friss másolatát. Ügyeljünk, hogy a megfelelő SERVER.EXE fájlt másoljuk át.
Futtassuk le a DSREPAIR-t és/vagy a VREPAIR-t.
Nézzük meg az INSTALL.NLM-mel a partíciók és a tükrözés adatait. (Az INSTALL ezt az információt dinamikusan kérdezi le.) Sérülhettek például a partíciós táblák. Ebben az esetben egy speciális hibát kapunk, ha nem tudja az INSTALL elolvasni a partíció adatait.
Mindig kétszer-háromszor ellenőrizzük a lezárásokat, a megszakítások beállításait, az SCSI ID-ket, a meghajtók transzlációs beállításait (ki kell, hogy legyen kapcsolva) stb.
Futtassuk le a VREPAIR-t. Ha nem jelez hibát, és mégis lemezsérülésre gyanakszunk, változtassuk meg a VREPAIR beállításait (főmenü, 2. menüpont). Állítsuk be a „Write changes immediately...”, „Write all changes....” és a „Purge deleted files” opciókat (nem feltétlenül szó szerint). Ne lepődjünk meg, ha RENGETEG hibát látunk e változtatások után.
Megjegyzés: a VREPAIR természetéből kifolyólag a Novell javasolja, hogy legyen kéznél egy ellenőrzött mentés a VREPAIR futtatása előtt.Próbáljunk ki más munkaállomásokat.
Próbáljunk ki más szegmenseken lévő munkaállomásokat.
Sikerül-e teljesen izolálni a LAN-t úgy, hogy egy munkaállomást közvetlenül a szerverhez csatlakoztatunk?
A gyors LAN-kártyákhoz jellemzően Category 5 kábelezésre van szükség. A nem megfelelő vezetékek gyakran okoznak problémákat.
A nagy I/O-terhelés néha hibázásra készteti a szervert. Próbáljunk meg kiadni egy folyamatos COPY *.* vagy XCOPY parancsot. Próbáljuk meg egyszerre több munkaállomásról.
Az NCOPY-val másoljunk át egy fájlt úgy, hogy a forrás és a cél ugyanazon a szerveren legyen. Ebben az esetben az NCOPY nem küld át csomagokat a LAN-on. Ha megmaradt a probléma, akkor az nem a LAN-ban van. Minden más másoló parancs (COPY, XCOPY) átmozgatja a fájlokat a „dróton”, akkor is, ha ugyanaz a szerver a forrás és a cél. Ha a COPY hibát eredményez, de az NCOPY nem, akkor a hiba jó eséllyel a LAN-ban van.