Reboot-Monitoring – Effektive Endkontrolle
Die Aufgaben des IT-Administrators sind vielfältig. Eines der regelmäßig wiederkehrenden Themen auf seiner Agenda ist das Patchen und Warten von Systemen – zumeist gefolgt von einem Restart derselben. Auch hier spart das vollautomatisierte Monitoring einiges an Zeit.
Reboot – immer gut?
Vor allem Windows-Administratoren können davon ein Lied singen. Der monatliche »Patch-Tuesday« gehört mittlerweile zum festen Eintrag im Terminkalender. Damit nicht genug. Etwaige Fehlfunktionen einzelner Dienste und die folgende Bugbehebungen ziehen ebenfalls einen Neustart von Servern nach sich.
Größere Umstrukturierungen sowie Arbeiten im Serverraum erzwingen oft ein vollständiges Herunterfahren mehrerer Geräte und – nach Abschluss – das organisierte Wiederanfahren der gesamten Umgebung. Erst danach beginnt die Herausforderung: Up oder Down? Mehr als nur ein schneller Check ist gefragt.
Drei, zwei, eins – los!
Nach einem nach Abhängigkeiten ausgerichteten Neustart heißt es dann Prüfen. Alle Systeme fehlerlos gestartet? Alle Dienste nutzbar? Funktioniert der gesamte Datenfluss?
Bereits bei einigen Servern ist die eigentliche Überprüfung aller Anwendungen und Services von beträchtlichem Aufwand, weshalb etliche EDV-Mitarbeiter auch gerne den Anwender als Testkandidaten heranziehen. Keine gute Idee. Es könnte ja ein nicht so einfach zu behebender Fehler aufgetreten sein, der bei einer derartigen Vorgehensweise zu Produktionsausfällen führt.
Systematik versus Stichprobe
Ein gut aufgesetztes Monitoring arbeitet im Verhältnis zum IT-Admin nicht nur schneller, sondern vor allem genauer. Unternehmenskritische Dienste und Anwendungen werden im Rahmen der Überwachung ebenso auf vollständige Funktionalität geprüft wie alle serverbasierenden Standardapplikationen.
Komplexität der Abhängigkeiten
Die Funktionsprüfung eines einzelnen Serversystems ist keine Hexerei – wenngleich auch einigermaßen zeitaufwendig. Alle Dienste gestartet? Keine Fehler im Protokoll? Alle Services auch aus Client-Sicht verfügbar? Ok.
Beim Zusammenspiel mehrerer Anwendungsserver wird die Lage schnell komplex und sehr aufwendig zu prüfen. Einige einfache Beispiele: AD-Replizierung der Domain-Controller, Mailserver und Mailfluss (Eingang, Ausgang, Zustellung), Datenbanken gestartet und notwendige Zugriffe möglich, gesamte Hardware ohne Fehler. Wie gesagt: bereits die einfachen Dinge sind schier endlos – und zeitaufwendig zu testen.
Beispiel Mailfluss
Mailserver ok? Wann kann diese Aussage getroffen werden? Wenn der Exchange-Server sauber bootet? Wenn dessen Datenbanken alle gemountet sind? Wenn der Outlook-Client ohne Fehler sich verbindet? Wenn der Webzugang zum Server (OWA) und seinen Nachrichten funktioniert? Wenn die Ereignisanzeige keinen Fehler ausweist?
Die Liste ist schon einigermaßen lang – und dennoch völlig unausreichend. Funktionalität und Produktivität geht weit über ein fehlerloses Starten hinaus. Es gilt die gesamte Kette, also alle an der Funktionalität beteiligten Systeme und Dienste, zu prüfen. Spätestens jetzt sollte die Komplexität der Aufgabe klar sein.
Im angesprochenen Beispiel der Mailfunktion bedeutet dies: von der Internetverbindung, über SSL-Gateway, Firewall und Router, bis hin zur AntiVirus-/AntiSpam-Appliance und letztendlich dem Mailserver geht die Abnahme. Das Zusammenspiel mit Active-Directory, Datenspeichern und Switches gar nicht erst einbezogen.
Beispiel Einzelsystem
Noch einen Schwierigkeitsgrad zurück: Bereits das »Ok« für ein Einzelsystem wird nach erfolgtem Reboot meist über den Daumen gepeilt. Wurden zwar alle Dienste und Prozesse gestartet, so „hängt“ nicht selten ein solcher und bringt den Server auf Maximallast. Ein Blick auf die CPU-Auslastung und den Speicherverbrauch ist notwendig, um den „Normalzustand“ zu diagnostizieren.
Gleiches gilt für den Zustand der Hardware. Ein Festplattenausfall ist meist optisch zu erkennen – der Server läuft dank RAID ja problemlos. Lüfter- und Netzteilversagen sind da schon etwas problematischer. Letztlich macht aber die Summe der möglichen Fehler die letztliche Diagnose so schwierig.
Der Prozess als kleinste Einheit
Als praktisches Beispiel (siehe dazu auch den Screencast am Ende des Artikels) an dieser Stelle – die Überwachung eines Prozesses. Ein kleines Element im gesamten Monitoring-Prozess. Für die unterbrechungsfreie Arbeit im Unternehmen aber oft von entscheidender Bedeutung. Manchmal sind es die kleinen Dinge, die den Gesamtfluss zum Stillstand bringen.
In dem konkreten Fall handelt es sich um einen Serverprozess, der die Lizenzierung einer Unternehmenssoftware kontrolliert. Funktioniert dieser nicht, so bedeutet dies Stillstand für die Applikation – unternehmensweit. Firmenweiter Ausfall eines wichtigen Elements der gesamten Arbeitskette.
Mit Monitoring kein Problem. Der Ausfall des Lizenzierungsdienstes wird umgehend gemeldet und – so konfiguriert – automatisch neu gestartet. Kein großer Akt, die richtige EDV-Überwachung vorausgesetzt.
Die Ampel der Netzwerküberwachung
Zugegeben, ein gut konfiguriertes und effektiv arbeitendes Monitoring ist keine Sache von wenigen Stunden (auch wenn dies die Hersteller derartiger Software gerne so verkaufen). Überwachung ist kein Standardsetup, sondern immer ein auf das jeweilige Unternehmen zugeschnittener Analyseprozess.
Sowohl Aufwand als auch Kosten machen sich aber in kürzester Zeit bezahlt. Ein reduzierter Aufwand der Administratoren ist nur der eine Vorteil. Die Exaktheit, wie auch die immens erweiterten Möglichkeiten der Funktionsanalyse der gesamten IT, ist der entscheidende Punkt, warum Monitoring in keinem Unternehmen fehlen darf. Der Komfort beim nächsten Reboot ist nur ein kostenloses Add-On.
Das Praxis-Video
Monitoring und Netzwerküberwachung ist im Prinzip recht einfach. Erst die individuelle Anpassung auf unternehmensspezifische Anforderungen macht das Thema zum Feld für Experten. Unser Video-Screencast zeigt den Ansatz. Weitere Beiträge zu diesem Thema folgen.
Anzeige