SNMP-Traps und LDAP

Für Unternehmen hingegen bietet Opsview die Möglichkeit, SNMP-Traps auszuwerten, eine LDAP-Anbindung vorzunehmen oder die im vorgestellten Setup nützliche Option, das Monitoringtool auf mehrere Server zu verteilen. Weitere Unterschiede zwischen Nagios und der frei erhältlichen Erweiterung Opsview zeigt [14]. Von Opsview gibt es auch eine Enterprise-Variante, die je nach Ausstattung zwischen knapp 10 000 und 50 000 Dollar kostet. Für die meisten Setups reicht jedoch die Community-Edition vollkommen aus.

Sowohl für DRBD als auch den Cluster Resource Manager Pacemaker liefert Opsview je ein Plugin, das deren aktuellen Zustand zuverlässig abfragt. Die Plugins sind auf den KVM-Hosts meist unter »/usr/lib/nagios/plugins« zu finden. Das für die Überwachung von DRBD zuständige Perl-Skript heißt »check_drbd« und lässt sich auch in der Shell ausführen. Es wertet die Ausgabe von »/proc/drbd« aus und gibt bei Unregelmäßigkeiten die Zustände »OK« , »WARNING« , »CRITICAL« und »UNKNOWN« zurück.

In Opsview selbst lässt sich zum Auswerten dieser Übergabe ein gewöhnlicher »check_by_SSH« -Check anlegen:

check_by_ssh -H Adresse_des_Hosts -l Benutzername-C "/usr/lib/nagios/plugins/check_drdb -d All"

Der Parameter »-d ALL« weist den Agenten an, den Check auf allen DRBD-Devices auszuführen (Abbildung 6). Auch den Status der CRM-Ressourcen ermittelt er auf ähnliche Weise. Auf jedem KVM-Host findet sich das Perl-Skript »check_crm« , das »/usr/sbin/crm_mon« aufruft und die Ausgabe auf Fehler prüft. Wie bei der Überprüfung von DRBD wird der Service-Check selbst ebenfalls mit »check_by_SSH« angelegt:

Abbildung 6: Wer DRBD einsetzt, sollte seine Nagios-Checks anweisen jedes DRBD-Device in jedem Volume zu prüfen.

check_by_ssh -H Adresse_des_Hosts -l Benutzername -C "/usr/lib/nagios/plugins/check_crm"

Nagios verbindet sich daraufhin in regelmäßigen Abständen via SSH mit dem zu überwachenden Server und führt das angegebene Kommando aus.

Automatische Aktionen

Neben der gewöhnlichen Überwachung von Ressourcen und dem Alerting im Notfall kann das Monitoring auch als Grundlage für weiterführende Aktionen dienen. Denkbar wäre, dass bestimmte Service-Checks bei der Rückgabe des »WARNING« -Status automatisiert Aktionen auslösen, um einem Ausfall vorzubeugen. Deutet sich beispielsweise die Überlastung eines Cluster-Node an, so könnte der Hypervisor zuvor definierte virtuelle Gäste automatisch auf den zweiten Knoten migrieren. Der unter Volllast stehende Knoten hätte auf diese Weise die Gelegenheit, sich regelrecht zu erholen, und läuft gar nicht erst Gefahr, den Cluster durch einen kompletten Ausfall zu belasten.

Tatsächlich sind solche automatisierten Umschaltungen zwischen aktiven Hosts nur dann möglich, wenn der Ausfall der betroffenen virtuellen Maschinen für zumindest wenige Minuten verkraftbar ist. Geht das nicht, könnte eine Live-Migration der Gäste helfen. Die aber gestaltet mit Konzepten wie Multi-Primary und Fencing das Cluster-Setup sowie die Administration deutlich komplexer.

Für die Administration eines Pacemaker-Clusters gibt es mehrere GUI-Tools, die das Management von Ressourcen vereinfachen. Die wahrscheinlich umfangreichste Implementation ist die so genannte DRBD Management Console [15] des in Wien ansässigen Unternehmens Linbit. Der Name ist dabei etwas irreführend, da es weit über das Management von DRBD hinausgeht und sämtliche Komponenten eines Linux-Clusters verwaltet, auch Pacemaker, Corosync, Heartbeat, DRBD, KVM, Xen und LVM.