
              Eine einfache Netware Serverberwachung (Teil 1)
              


Wie's so ist !


Ich komme wie blich zu nachtschlafender Zeit (so um 9:00 Uhr) in die
Firma und wundere mich schon im Vorbeigehen. Nicht, dass meine Kollegen
wie blich lustlos vor Ihren Rechner sitzen, heute sitzen sie offen-
sichtlich absolut nutzlos davor. Und da es so viele sind, schwant mir
schon ziemlich Schreckliches - unser Server ist bestimmt DOWN. Kaum habe
ich Zeit meinen Mantel auszuziehen, da kommt auch schon der erste:

"Kannst Du nicht endlich mal DEINEN DRECKS Server zum Laufen bringen.
Ich warte schon seit 7 Uhr darauf endlich was machen zu knnen !!!"

Arschloch - was kann ich dafr, dass er zu den Superverrckten gehrt,
die bereits um Mitternacht arbeiten wollen. Und wieso ist das MEIN
Server?

Mein Chef (leider auch schon da) ist noch besser drauf:

"Kannst DU mir mal sagen, wieso dieses DING NIE luft - wie soll man
denn hier mal zum Arbeiten kommen !!! - und vor allem was das wieder
kostet !!!"

"Den letzten Ausfall hatten wir vor ca. einem halben Jahr", wage ich
schchtern einzuwenden.

Das interessiert ihn aber nicht und wie blich kommt noch der Spruch:
"Wir werden das Netz jetzt endgltig abschalten und jeder bekommt wieder
seinen eigenen unabhngigen Rechner, damit die Scheie mit den ewigen
Serverausfllen endlich mal aufhrt !!"

Er wird sich wie blich auch diesmal nicht trauen es wirklich zu tun -
aber er nervt halt. Wrde er mich nicht solange aufhalten, dann wre die
Maschine wahrscheinlich schon lngst wieder on air.

Ich begebe mich also in den Serverraum und schliee vorsichtshalber von
innen ab, damit nicht noch mehr unfltige Beschimpfungen auf mich
darniederprasseln.

Dabei dachte ich - als ich vor 5 Jahren den Job bernommen habe - mach
was aus dir das die Ruhm und Ehre einbringt, werde Netzwerkbetreuer. Sei
wie der Brgermeister eines kleinen verschlafenen Dorfes, der als
einziger ein Telefon besitzt und um dessen Gunst sich alle wie wild
reissen. - Oh Mann (seufz!!).

Nach soviel "Vorfreude" habe ich nun endlich die erste Gelegenheit,
einen Blick auf die Serverkonsole zu werfen und sehe mit doch einiger
Erleichterung, da noch gewisses Leben in dem Server zu stecken scheint.

Die Fehlermeldung

   "Short Term Memory Allocator runs out of available memory"

verheit auf jeden Fall nichts schwieriges.

Eine kleine Parameternderung in der STARTUP.NCF und ich fahre den
Server wieder hoch. Und ich glaube es kaum, auf den ersten Blick sieht
alles ganz normal aus. Nur eine der Spiegelplatten scheint nicht zu
laufen. Aber immerhin der Server ist erstmal wieder oben - oh JESUS !!

Ein Blick in das Netware Error Log File sagt mir, da die Platte bereits
seit ber einem Monat nicht mehr funktioniert. Scheisse wieso hab ich
das nicht gemerkt?

Nicht das Netware nicht so nett wre, diesen Fehlerzustand zu
protokollieren, zusammen mit einem typischen Netware Beep. Aber wer hrt
den schon, wenn sich der Server in seinem eigenen verschlossenen Raum
befindet.

Dabei stelle ich fest, da ich noch Glck gehabt habe. Ein Kollege von
mir (leider auch so ein armes Betreuerschweinchen) hat den Ausfall einer
Spiegelplatte erst dann bemerkt, als die Intakte dann auch noch
dahingesiecht ist. Viel Zorn fiel damals mit ziemlich viel Wucht auf
ihn, weil sein Ausfall um einiges lnger dauerte als der eben beschriebene
(die arme Socke!).



              Eine einfache Netware Serverberwachung (Teil 2)
              


Nur was tun um Serverausflle zu minimieren ?


Nun in einer Hinsicht kann ich Netzwerkbetreiber verstehen. Ein Server
ist kostentechnisch gesehen eine Zeitbombe. Fllt er aus, dann sind mit
einem Schlage 5 - 250 Leute arbeitslos (je nach Anzahl der ber einen
Server versorgten Anwender). Jede Arbeitsstunde kosten in der Regel so
um die 100,- Mark. Womit jede Stunde Serverausfall zwischen 500 und
25000,- Mark kosten kann.

Daher versteht es sich eigentlich von selbst, dass die Systembetreuer
ihr Mglichstes tun sollten, um Serverausflle und Wartungsarbeiten -
wenn irgend mglich - nicht in die Arbeitszeit fallen zu lassen.

Gegen den Ausfall eines Motherboards oder Netzteil kann man sich kaum
schtzen (auer man baut komplette Spiegelserver. Diese Art der
Ausflle sind jedoch heutzutage sehr gering, wenn man sich die Mhe
macht, wenigstens ab und zu nach den Lftern zu sehen und den
einwandreien Sitz aller Stecker zu prfen. Sollte der Server nicht
gleich bei Lieferung mit Markenlftern versehen sein, so lohnt sich ein
Auswechseln noch vor der ersten Inbetriebnahme.

Der wirkliche Schwachpunkt eines Servers liegt allerdings immer noch bei
den Platten. Sie unterliegen (da es mechanische Teile sind) einem
stndigen Verschlei - und eines weiss man sicher - sie werden irgenwann
ausfallen. Die Frage ist nur wann?

Darum sollte jeder Serverbesitzer darauf bestehen, da 'sein' Server
zumindest mit gespiegelten Platten ausgerstet ist, um eine gewisse
Datenredundanz zu haben. Besser ist noch ein Duplexing der
Plattensysteme. Hierbei sind zustzlich die Interfaces zu den Platten
doppelt vorhanden. Nicht nur, dass dies wiederum die Systemsicherheit
erhht, diese Manahme erhht auch den Datendurchsatz (und wer mchte es
nicht noch ein bisschen schneller haben, wenn's einfach geht).

Durch die oben geschilderte Redudanz ist mit einem pltzlichen Ausfall
des Servers durch Plattenversagen kaum zu rechnen. Vor allem dann, wenn
man die Anzeichen eines bevorstehenden Platencrashes rechtzeitig
bemerkt.

Einer der wichtigen Parameter ist hierbei die Anzahl der redirected
Blocks einer Platte.

Zur Erklrung: Beim Erstellen einer Netware Partition reserviert Netware
sogenannte Hotfix Blcke. Dies ist ein Plattenbereich, der normalerweise
ungenutzt bleibt. Treten Lese - oder Schreibfehler auf, so wird der
Inhalt des fehlerhaften Datenblocks - soweit als mglich - auf einen der
Hotfix Blcke umgelegt, so da defekte Sektoren nicht zu Datenverlust
fhren.

Also immer wenn Netware gezwungen ist einen Platenblock auf einen
anderen Block zu legen, dann erhht es den "Redirected Block" Zhler.
Den Inhalt dieses Zhlers kann man sich innerhalb des Monitors unter
"Disk Information" ansehen. Bei einwandfreien Platten sollte der Zhler
auf 0 stehen. Jeder Wert grer 0 weist auf eine unsichere Platte hin.
Mein persnlicher Grenzwert liegt bei maximal 3 redirected Blocks / pro
Platte. Wird dieser erreicht, dann wechsele ich die Platte auf jeden
Fall, auch wenn sie ansonsten noch voll funktionstchtig ist. Man kann
versuchen, die Platte zu formatieren, um sie damit wieder zu vollem
Leben zu erwecken - aber besser ist es, sie zu erneuern.

Ein zweiter lebenserhaltender Parameter ist - falls man Platten-
spiegelung betreibt - die regelmige Prfung des "Mirror Status". Den
Befehl "Mirror Status" gibt es ab Netware 3.12, den man an der Server
Konsole eingeben kann. Wenn alles in Ordnung ist, dann erhlt man fr
jede gespiegelte Platte die Meldung:

        Logical Partition #  n is fully synchronized

Fr jede nicht mehr gespiegelte Partition die Meldung:

        Logical Partition #  n is out of synchronization

Wer also die Plattenspiegelung sowie die Anzahl der redirected Blocks
seiner Platten im Auge behlt, ist vor unerwarteten Serverausfllen
schon recht sicher. Nur, wie macht man das am besten?
Welcher Systemadmistrator hat schon Lust, regelmig in seine Error Log
Files zu sehen, um darin zu suchen, ob hierin nichts Wichtiges steht,
das er wissen sollte.

Es geht also darum, zu automatisieren, nach der Devise: Heh Server,
sag's mir, wenn's Dir schlecht geht !

Nicht, dass hierzu nicht schon einiges erfunden worden wre. In der
Regel sind kommerzielle Lsungen aber teuer und so overengeneered, da
man zur Installation schon keine Lust hat, selbst wenn man sie geschenkt
bekommt.

Eine leicht zu installierende fertige Lsung zum Testen der oben
genannten Serverbetriebsparameter ist das public domain Script WATCH.ABC
fr das Shareware Program ABC.NLM. Es testet den "Mirror Status" und die
Anzahl der redirected Blocks einmal pro Tag. Werden Fehler festgestellt,
dann bombadiert ABC.NLM alle Mitglieder der Gruppe "GR_SUPERVISORS" mit
Broadcast Messages, um auf den drohenden Serverausfall hinzuweisen.

Das Script ist fr Netware 3.12 und 4.11 geschrieben. Nach leichten
Anpassungen ist es aber auch auf anderen Netware Versionen lauffhig.

Bezugsquellen fr das Script sowie ABC sind:

     -    INTERNET:

          Address (url)            http://www.netproducts.de


     Deutsche Mailboxen:

     -    Pandora box              Fido Address:  2:2476/719
                                   Phone / ISDN:  49-7853-97997

     -    Zaphod's beeble box      Fido Address:  2:2453/30
                                   Phone:         49-228-262894
                                                  49-228-264147
                                   ISDN:          49-228-9111041


Das Script ist unter dem Namen ABCWATCH.ZIP abgelegt. ABC findet sich
berall unter dem File Namen ABC211.ZIP



              Eine einfache Netware Serverberwachung (Teil 3)
              

Wer denkt: die Installation ist kompliziert !!! - liegt falsch

Alles halb so schlimm. Die Installation geht folgendermaen:

-       Mit Syscon oder Netadmin die Gruppe "GR_SUPERVISORS" anlegen
        und alle die Anwender zu Mitgliedern der Gruppe machen die durch
        ABC gewarnt werden sollen. Auf Netware 4 mu zustzlich die
        Binderyemulation gestartet werden.

-       SETSTR: 6 = "UNLOCK" in der Script Prozedur INITWATCH so
        modifizieren, da innerhalb der Anfhrungszeichen das Passwort
        steht, mit dem die Serverkonsole entsperrt und gesperrt wird.
        Dies ist allerdings nur notwendig, falls die Server Konsole in
        der Nacht gesperrt ist.

-       ABC.NLM aus ABC212.ZIP nach SYS:SYSTEM kopieren.

-       Das Verzeichnis SYS:SYSTEM\ABC auf dem zu berwachenden Server
        erzeugen.

-       Das File WATCH.ABC in das Verzeichnis: SYS:SYSTEM\ABC kopieren.

-       ABC starten durch die folgende Eingabe auf der Server Konsole:
        LOAD ABC WATCH

-       Das ist schon alles !


Was macht WATCH.ABC ?


Einmal um ein Uhr nachts entriegelt WATCH.ABC (falls notwendig) die
Systemkonsole oder ldt das Program MONITOR.NLM. Mit dessen Hilfe schaut
es nach, wieviele redirected Blocks jede Platte hat. Sind dies 3 oder
mehr, dann gibt es am nchsten Morgen jeweils zu jeder vollen Stunde
Broadcast Messages an alle Mitglieder der Gruppe "GR_SUPERVISORS" aus.
Nach dem Test wird die Systemkonsole entweder wieder gesperrt (falls sie
vorher gesperrt war) oder MONITOR.NLM wird wieder entladen, falls es
vorher nicht geladen war. Whrend des Tests wird auch der "Mirror
Status" geprft, was bei einem Plattenspiegelproblem ebenfalls zu
Broadcast Messages fhrt.

Noch Fragen ?

Dann 'ne mail an:

Horst Jelonneck

Fido:          2:2453/30.30
Internet mail: jelonneck@netproducts.de

/Horst/

