Kapitel 6

6 Alarmierung und Notfallkonzept

Um die von Tivoli entdeckten Fehler an die Administratoren melden zu können stehen bei BMW Regensburg mehrere Wege zur Verfügung: Jeder Administrator hat einen Piepser, die meisten ein D1 Handy. Das Rechenzentrum kann über die alte RZ-Technik telefonisch alarmiert werden. Außerdem steht noch eine Web-Page, eine Newsgroup sowie die direkte Alarmierung via e-Mail zur Verfügung.

Da jedes dieser Systeme selbst ausfallen kann, muß auch die Möglichkeit zur Alarmierung überwacht werden, da die beste Überwachung keinen Gewinn bringt, wenn die Ergebnisse der Überwachung nicht weitergemeldet werden können.

6.1 Aufgabendefinition

Sämtliche Alarmierungswege sollen nach Möglichkeit überwacht werden, bei einem Ausfall einzelner Systeme soll über die anderen Wege alarmiert werden. Kleinere Probleme sollen ohne Alarm behoben werden.

6.2 Implementierung

6.2.1 Lokaler Pager

Der Sender für den lokalen Pager ist über eine serielle Schnittstelle mit einem Rechner verbunden und erwartet einen einfach formatierten String. Zu Beginn traten hier häufig Ausfälle auf, da die serielle Schnittstelle des Windows NT-Servers jeweils nach einigen Tagen Betrieb nicht mehr sendete und erst durch einen Reboot des Rechners wieder aktiviert werden konnte. Ein Hardwaredefekt konnte ausgeschlossen werden, da es an verschiedenen Rechnern auftrat. Es muß also ein Fehler im Treiber vermutet werden. Ein Umzug der Hardware an einen AIX-Rechner hat das Problem beseitigt, auf eine weitere Überwachung kann seither verzichtet werden.

6.2.2 Cityruf/D1-/D2-SMS-Meldungen

Cityruf, D1- und D2-SMS-Meldungen werden über Remote-Printer-Queues angesteuert. Diese Queues bauen vom Werk München aus eine Verbindung zum Telekom BTX auf und senden so die Meldung weiter. Hier gibt es 4 Schwachpunkte: Die lokale Printer-Queue, die Netzwerkverbindung nach München, die Printer-Queue in München und den BTX-Server. Das Netzwerk wird an anderer Stelle bereits überwacht, der BTX-Server gehört der Telekom und damit außerhalb der Erreichbarkeit.

Die Printer-Queues stehen manchmal ohne erkennbaren Grund auf "DOWN". Dies wird von einem Skript sowohl lokal als auch remote überwacht und ggf. automatisch wieder "enabled". Sollte dies fehlschlagen, so wird alarmiert.

6.2.3 RZ-Technik

Die RZ-Technik steht als "letztes Notsystem" zur Verfügung und wartet lediglich auf eine Mitteilung von Tivoli, um eine vorgefertigte Meldung am Telefon im Rechenzentrum auszugeben. Dieses System wird lediglich durch die Ping-Überwachung, die weiter oben beschrieben wurde, mitüberwacht.

6.2.4 Web-Page

Die Webpage, in der alle aktuellen Alarme aufgelistet werden, ist ständig auf einem Monitor im Rechenzentrum sichtbar und aktuallisiert sich selbständig alle 30 Sekunden. Damit neue Einträge immer erstellt werden können wird der Füllgrad des betreffenden Filesystem überwacht und ggf. alte Meldungen gelöscht.

6.2.5 Newsgroup und E-Mail

Jeder Alarm führt zu einer Meldung in einer speziellen Newsgroup und zu einer Mail an den oder die zuständigen Administratoren. Das Mailsystem soll in Zukunft bzgl. Speicherplatz und Erreichbarkeit überwacht werden. Da die Mails aber lediglich als zusätzliche Information dienen (und dienen können) führt ein Ausfall dieses Teilsystems also nicht zum Ausfall des Alarmierungssystems.