Big Brother für den Serverpark
Artikel erschienen in Swiss IT Magazine 2006/17
Da hat man nun seinen Serverpark stehen, 99 Solaris-Maschinen, 128 Linux-Kisten, 17 Windows-Server, einige Exoten wie HP/UX oder IRIX und man freut sich, dass die Administration einigermassen konsistent und soweit wie möglich automatisiert ist. Doch da ruft plötzlich ein Kollege an, dass er keine Linux-Updates mehr vom internen Patch-Server herunterholen kann. Schon seit gestern Vormittag. Und ob es normal sei, dass er seit zwei Tagen keine Mail mehr bekommen habe?
Wer von solchen Anrufen genug hat, dem hilft nur eine automatisierte Überwachung der Systeme, beispielsweise mit Nagios, einem qualitativ hochwertigen und dazu noch freien Monitoring-Werkzeug.
Nagios hat mittlerweile schon fast sieben Jahre auf dem Buckel, rangierte aber bis 2002 unter anderem Namen und hiess Netsaint. Der Heilige der Netzwerke war ursprünglich als einfaches Tool konzipiert, um vor allem Netzwerkdienste wie HTTP, SMTP, POP3, oder NNTP zu überwachen und gegebenenfalls dem Administrator eine Meldung zu übermitteln. Mittlerweile hat sich das in der Version 2.5 erhältliche Tool in ein Framework von verschiedenen Plug-ins und Modulen verwandelt und kann sehr viel mehr als einfach nur auf ein «nicht erreichbar» eine Meldung absetzen. Grafische Kurven stellen die Verfügbarkeit eines Dienstes dar. Mit Zusatzsoftware kann die Infrastruktur der eigenen Netze dargestellt und für andere Zwecke verwendet werden. Abhängigkeiten werden aufgelöst, geplante Downtimes können eingepflegt werden und vermeiden unnötige Meldungen.
Selbst Performance-Aussagen über bestimmte Systeme lassen sich in einem begrenzten Umfang treffen. Mit den entsprechenden Modulen und Plug-ins können nahezu alle beliebigen Dienste und Prozesse überwacht werden: von der Plattenkapazität bis zur Speicherauslastung, von der Prozessanzahl bis zur Menge der Netzverbindungen, von der CPU-Auslastung bis zur Zahl der fehlerhaften Pakete im Netz, von der Verfügbarkeit einiger Prozesse bis zur Verfügbarkeit ganzer Netzwerke.
Eigenentwicklungen und Ideen sind ebenfalls wenig Grenzen gesetzt: Mit NRPE (Nagios Remote Plug-in Executor) existiert ein Tool, mit dem man eigene Scripts auf einem Client ausführen kann.
Der Nagios-Dienst selbst sollte auf jedem Unix-Derivat lauffähig sein. Man benötigt lediglich einen -Compiler und, wenn man die Weboberfläche verwenden möchte, einen Webserver wie Apache und die Grafikbibliothek GD für die Erstellung der verschiedenen Graphen. Alles weitere wird durch Plug-ins und Module realisiert.
Für viele Unix-, BSD-und Linux-Distributionen existieren fertige Nagios-Pakete. Aber auch die Self-Made-Installation von Nagios bringt man mit dem klassischen ./configure && make && make install schnell hinter sich. Beispieldateien werden mit make install-config installiert. Wie jeweils weiter zu verfahren ist, ersieht man an den Ausgaben der aufgerufenen Tasks. Plug-ins müssen je nach Bedarf extra installiert werden. Aber auch dies ist meist fix erledigt.
Möchte man das Web-Front-end benutzen, muss man zusätzlich den Webserver konfigurieren. Dies ist mit Unterstützung des Nagios-Manual recht einfach. Zudem kann man es auch so konfigurieren, dass bestimmte Checks oder sogar Dienste mit dem Front-end verwaltet werden können.
Eine grosse Menge von Plug-ins bringt bereits das Nagios-Plug-ins-Paket mit. Zwischen icmp, disk_smb für Abfragen von Windows Shares, snmp_storage zur Abfrage von Platten über SNMP, ntp, dns und den von Nagios mitgelieferten Grund-Checks wie ping und ssh sollten die meisten Bedürfnisse abgedeckt sein.
Ein mächtiges Werkzeug für eine ganze Reihe vordefinierter, aber auch selbstdefinierter Checks ist der NRPE. Der NRPE ist ein Dienst, welcher auf den Clients läuft. Der Nagios-Server kontaktiert den NRPE über einen bestimmten Port und lässt ihn dann ein Kommando ausführen. Die Rückgabewerte sind dann die Status, welche Nagios weiter auswerten kann.
Allerdings ist der NRPE durch seine mächtige Funktionalität ein nicht ganz unbedenklicher Mechanismus, den man unbedingt weiter absichern sollte. Schliesslich hat man die Möglichkeit, von einem Remote Host einen Befehl abzusetzen und diesen direkt auf dem Zielsystem auszuführen. Es empfiehlt sich hier, mit einem TCP Wrapper (sofern NRPE als inetd-Dienst eingerichtet ist) zu arbeiten oder in der NRPE-Konfiguration den Nagios-Server als einzig zugelassenen Host einzutragen. Noch besser verwendet man zusätzlich noch einen Paketfilter wie iptables oder pf und lässt nur den Nagios-Host auf den entsprechenden Port zu.
Die gesammelten Daten kann Nagios auch graphisch darstellen. So lässt sich recht einfach ein Trendverlauf – etwa die Anzahl der HTTP-Zugriffe oder die Load im Tagesverlauf eines Servers – darstellen und analysieren.
Um Administratoren mit Nagios-Meldungen zu versehen, existiert eine Vielzahl von Möglichkeiten. Die gebräuchlichsten sind wohl Mail, SMS oder SNMP-Traps. Die Meldungen lassen sich auch eskalieren. So ist es etwa möglich, bei einem Ausfall eines Systems den entsprechenden Administrator per Mail zu benachrichtigen. Erfolgte nach einem gewissen Zeitraum keine Aktion (Dienst ist immer noch nicht verfügbar), wird eine SMS an eine bestimmte Personengruppe geschickt. Reagiert immer noch niemand, kann beispielsweise auch der Abteilungsleiter oder IT-Verantwortliche informiert werden. Umgekehrt ist es natürlich auch sinnvoll, Entwarnung zu geben, wenn ein Dienst wieder verfügbar ist.
Ein Nachrichtendienst der etwas komplexeren Sorte ist am Rechenzentrum der Universität Erlangen-Nürnberg in Betrieb. Zum Einsatz kommen ein zentraler Nagios-Server und ein weiterer «Satellit» in einer durch eine Firewall abgeschotteten Umgebung. Der zentrale Nagios-Server hat keinen Zugriff auf die abgeschottete Umgebung. Statt dessen erhält er den Status der dort liegenden Hosts über den Satelliten. Die Kommunikation erfolgt nicht aktiv, sondern passiv. Das bedeutet, dass Nagios nicht die Abfrage startet, sondern umgekehrt der Nagios-Satellit regelmässig den Status der von ihm verwalteten Hosts an den Master-Server übermittelt. Das Nagios-System überwacht aktuell insgesamt 358 Hosts mit 1023 Diensten aktiv und 17 Hosts mit 86 Diensten passiv. Die Dienste und Hosts werden auf verschiedene Art und Weise gecheckt, teilweise nur auf Dienstverfügbarkeit (ping, ssh, http, ftp), teilweise über SNMP Traps und teilweise über den NRPE, der unter anderem Load und Plattenkapazität zurückgibt. Gekoppelt an die verschiedenen Rechnergruppen werden unterschiedliche Personen oder Personenkreise informiert. So gibt es beispielsweise einen «Administrator on Duty», der täglich wechselt. Hat einer der Server in dessen Zuständigkeitsbereich ein Problem, wird der diensthabende «Administrator on Duty» per SMS informiert. Ist das Problem behoben, wird eine Entwarnungs-SMS versandt.
Die Konfiguration von Nagios wird trotz der recht hohen Anzahl von Systemen noch teilweise mit der Hand gepflegt. In Aufbau ist eine zentrale Datenbank, in der alle Hosts und Dienste gepflegt werden. Aus dieser Datenbank heraus soll dann die Nagios-Konfiguration dynamisch erzeugt werden. Das Ziel dabei ist, dass bei der Neuanschaffung eines Rechners alle relevanten Daten wie Ausstattung, Inventarisierung, Dienste oder zuständiger Ansprechpartner zentral gespeichert werden und gleichzeitig, ohne Hand anlegen zu müssen, die Überwachung dieses Systems initiiert wird. In Erprobung befindet sich zudem eine Erweiterung von Nagios, die sich Nagvis nennt. Nagvis ist ein Front-end auf PHP-Basis, mit dem man die Nagios-Daten und -Werte grafisch übersichtlich darstellen kann. So ist es beispielsweise möglich, ein Serverrack in Form eines Fotos darzustellen und die Dienste, welche nicht laufen, auf dem Bild des jeweiligen Servers hervorzuheben. Ebenfalls grafisch darstellen lassen sich Abhängigkeiten und Workflows. So sind etwa alle Rechner gut ersichtlich, die an einem bestimmten Subnetz und Router hängen. Diese Bilder eignen sich als Dokumentation für Netzwerke, Präsentationen oder einfach nur zur Übersicht.
Überwachungssysteme wie Nagios sind in grösseren Rechenzentrum unbedingt erforderlich. Die Konfiguration von Nagios ist zwar nicht schwierig, aber doch relativ aufwendig und umfangreich, insbesondere bei vielen Rechnern. Trotzdem kann es sich auch für kleinere Installationen lohnen, Nagios für die Überwachung einzusetzen. Schliesslich sind auch Szenarien möglich, bei denen Nagios das eigene Domizil überwacht. Etwa könnte Nagios eine Meldung versenden, wenn im Briefkasten etwas liegt oder wenn beispielsweise die Eingangstür der eigenen Wohnung länger als eine bestimmte Zeit offen bleibt. Das ist alles nur eine Frage der Sensoren. Denn die Möglichkeiten mit Nagios sind nahezu unbegrenzt.
Gregor Longariva ist Solaris-Administrator am Rechenzentrum der Universität Erlangen-Nürnberg.