Hardwareüberwachung mit BMC PATROL Teil I:

Hitzetod wegen Lüfterausfall

Die klassische Domäne von BMC PATROL liegt in der Überwachung von Betriebssystemen, Datenbanken und Applikationen. Mindestens genauso wichtig ist jedoch die Überwachung der darunter liegenden Hardware. In dieser zweiteiligen Serie stellen wir Ihnen die verschiedenen Möglichkeiten der Hardwareüberwachung mit PATROL vor.

Überblick

Viele kritische Komponenten einer komplexen IT-Serverlandschaft werden manchmal nur unzureichend im System Monitoring überwacht. Hierzu zählen unter anderem der Status gespiegelter Platten, die Einsatzbereitschaft von Geräten zur unterbrechungsfreien Stromversorgung und last but not least die Lüfter von Servern und Storage Systemen. So kann der Ausfall von Lüftern durchaus zum Totalausfall eines kritischen Systems führen.

Die Überwachung mit Hilfe von BMC PATROL geschieht wie immer mit Hilfe von speziellen Knowledge Modulen. Grundsätzlich besteht die Möglichkeit, ein Knowledge Module (KM) selbst zu entwickeln oder auf die Palette der auf dem Markt befindlichen KMs zurückzugreifen. Hierzu gehören z. B.:

• Sun Enterprise Server KM,
• ServerView KM (Fujitsu Siemens Primergy),
• PATROL for Dell OpenManage oder
• PATROL for Compaq Insight Manager.

In der ORDIX News 2/2001 stellten wir ein Entscheidungsverfahren vor, mit dessen Hilfe die Auswahl des Produktes mit dem besten Preis/Leistungsverhältnis einfach vorzunehmen ist. Für zahlreiche Storage Systeme, USVs und selbst für viele Servertypen stehen allerdings keine vorgefertigten KMs zur Verfügung. Es muss demnach eine Individualprogrammierung vorgenommen werden.

Technische Verfahren

Grundsätzlich stehen zwei technische Verfahren zur Überwachung von Hardwarekomponenten zur Verfügung – lässt man die Überwachung von Protokolldateien hier einmal außen vor: Die Analyse via SNMP und die Nutzung von speziellen Programmen, die der jeweilige Hardwarehersteller zur Verfügung stellt. Die oben genannten Knowledge Module basieren alle auf SNMP Abfragen. Im zweiten Teil dieser Serie werden wir uns diesem Themengebiet ausführlich widmen.

In diesem ersten Teil stellen wir die systematische Vorgehensweise bei der Individualprogrammierung einer Hardwareüberwachung mit Hilfe spezieller Programme vor. Als Beispiel dient ein Storage System, welches mit Hilfe des Skripts check.sh überwacht werden soll (siehe Abb. 1).

Abb. 1: Überwachung eines Storage Systems.

Vorgehen bei der Individualprogrammierung

Diese Vorgehensweise besteht aus den folgenden Schritten:

• Identifizierung der zu überwachenden Systeme
• Auswahl eines Programms, welches die benötigten Überwachungsdaten zur Verfügung stellt
• Interpretation der Ausgabe des Programms
• Auswahl der benötigten Teilkomponenten
• Implementierung eines KMs

Nach der Identifizierung des zu überwachenden Systems muss ein Programm ausgewählt werden, welches die benötigten Überwachungsdaten zur Verfügung stellt. Diese Auswahl gestaltet sich oft als der schwierigste Teil des gesamten Verfahrens, da diese Programme oft nur wenigen Administratoren bekannt sind. Ist das Programm ausgewählt, müssen die Aufrufparameter noch bestimmt werden.

Im nächsten Schritt muss die Rückgabe des Programms (siehe Abb. 2) interpretiert werden. Da eine exakte Spezifikation der Ausgabe fast immer fehlt, müssen hier bestimmte Annahmen getroffen werden. Enthält eine Zeile den Ausgabetext „All temperatures are NORMAL“, so sollte nach dem gesamten Text gesucht werden. Die Annahme, dass in der Zeile mit „temperatures“ das Wort „NORMAL“ einen normalen Zustand darstellt, kann unter Umständen falsch sein, wie die folgende mögliche Ausgabe zeigt: „All temperatures are not NORMAL“.

Ist die Rückgabe des Programms interpretiert, müssen die zu überwachenden Komponenten ausgewählt werden. So wurden im Beispiel die Temperatur, der Status der Lüfter (Fans) und die Netzwerkversorgung (Power Supply) ausgewählt. Alle anderen Komponenten haben lediglich informativen Charakter.

In einem letzten Schritt wird das Knowledge Module implementiert. Wurden die ersten Schritte sorgfältig abgearbeitet, so muss in diesem Schritt lediglich die Architektur entworfen und in PSL implementiert werden. Es bietet sich grundsätzlich an, das zu überprüfende Kommando von einem Collector ausführen zu lassen. Kommt es zu einem Fehler bei der Datenerhebung, kann so der Collector in den Zustand „Warnung“ gesetzt werden. Für jede zu überwachende Komponente sollte es einen Parameter geben. Zusätzlich kann beispielsweise ein Textparameter die Rückgabe des Programms anzeigen.

Abb. 3: Architektur des Hardware KMs.

Neben den bisher aufgeführten Schritten, sind einige grundsätzliche Dinge bei der Implementierung einer Hardwareüberwachung zu beachten. Häufig können bestimmte Programme nur unter dem Benutzer root ausgeführt werden. Dies lässt sich über die verschlüsselte Ablage des Passwortes in der Agentenkonfiguration, dem S-Bit auf Betriebssystemebene oder die Erstellung einer Protokolldatei über einen Cronjob umgehen. Unter NT besteht dieses Problem i. d. R. nicht, da der PATROL Default Account lokaler Administrator ist. Weiterhin können sich natürlich mit jedem Release und Patch der überwachten Hardware und der damit ausgelieferten Software Änderungen im Ausgabeformat ergeben. Diese müssen erkannt und entsprechend berücksichtigt werden.

Fazit

Ist die Entscheidung für eine Individualprogrammierung gefallen und ist das entsprechende Know-how vorhanden, so lässt sich mit einer strukturierten Vorgehensweise in relativ kurzer Zeit ein Knowledge Module zur Hardwareüberwachung implementieren. Vorausgesetzt, es steht ein Programm zur Analyse der entsprechenden Hardware zur Verfügung. Mit einer solchen Überwachung behält dann auch die Hardware einen „kühlen Kopf“.

Martin Hoermann (info@ordix.de).

Seitenanfang

Seite drucken

Seite weiterempfehlen