Agenten, Agenten!

Ist der Stand-alone-KVM-Host oder gleich ein ganzer Cluster auf Basis der oben beschriebenen Komponenten in Betrieb genommen, kann die Überwachung der einzelnen Ressourcen beginnen. Jetzt muss sich der Admin zunächst Gedanken über die richtigen Werkzeuge und die zu überwachenden Ressourcen machen. Weil im Falle von Software- oder Hardware-Versagen der oder die Hosts nicht wissen können, welche Anwendungen innerhalb der abgeschotteten virtuellen Umgebungen laufen, muss der Planer sein Hauptaugenmerk auf die Dienste, Prozesse und Anwendungen innerhalb der Gäste legen.

Zusätzlich muss er sicherstellen, dass die entsprechende KVM-Instanz auch aktiv ist. Im Cluster stößt er darüber hinaus auf das Problem, dass die Monitoring-Anwendung nicht wissen kann, auf welchem Knoten die virtuelle Maschine aktiv ist – sie prüft meist nur die Dienste in Form einer IP-Adresse in Verbindung mit einzelnen Ports.

Da ist es sinnvoll, das Überwachen von KVM-Instanzen Pacemaker zu überlassen, da dieser über alle im Cluster vorhandenen Ressourcen Bescheid weiß. Das Monitoringtool der Wahl sollte sich daher – zumindest im Cluster – auf das Monitoring des Schrittmachers konzentrieren. Das vorliegende Beispiel realisiert diese Anforderung mit dem Nagios-Plugin »check_crm« , wobei »crm« für den Cluster Resource Manager steht.

Im Stand-alone-Betrieb ist es ratsam, den Host direkt mit den Standardchecks zu überprüfen. In Frage kommen dafür die Erreichbarkeit übers lokale Netzwerk, die Systemauslastung und der SSH-Zugang – schließlich möchte der Admin stets wissen, ob der Fernzugriff auf den Host möglich ist. Für den KVM-Host muss er daher mindestens folgende Ressourcen im Blick behalten:

• Connectivity (LAN)
• Unix-Load
• RAM/Swap-Auslastung
• Storage Utilisation
• SSH-Verfügbarkeit (meist auf Port 22)
• Optionale Erweiterungen: Bei Verwendung von Libvirt lässt sich beispielsweise prüfen, ob der Daemon Libvirtd läuft (Abbildung 2).

Abbildung 2: Die richtigen Checks sind die halbe Miete: Hier prüft ein Monitoringsystem, ob der Libvirtd läuft.

Diese Checks genügen in den meisten Fällen, um zuverlässig Auskunft über den Zustand des Hosts geben zu können. Wer das KVM-System dann, wie oben beschrieben, zum Cluster ausbaut, sollte mindestens noch die Dienste CRM und DRBD ins Monitoring integrieren.

Keine Ahnung vom Gast

Weil der Cluster selbst keine Kenntnis über die Vorgänge in der virtuellen Maschine besitzt, muss das Monitoring-System auch diese überwachen. Für jeden Linux-Gast ergeben sich daher fast identische Anforderungen wie für das Host-System (siehe oben).

Zu den Basischecks kommen aber pro Gast noch (meist mehrere) individuelle Erweiterungen, weil je nach Anwendungsszenario auch die Dienste zu überwachen sind, die die virtuellen Gäste anbieten. Für einen Webserver wären dies etwa die Erreichbarkeit des Apache via HTTP, FTP und einer Datenbank, falls vorhanden.

Windows-Gäste lassen sich anhand der Verfügbarkeit folgender Systemressourcen überwachen:

• Connectivity (LAN)
• CPU-Auslastung
• Arbeitsspeicher
• Auslagerungsdatei
• Freie Kapazitäten auf den Laufwerken
• Verfügbarkeit des RDP-Zugangs für die Fernverwaltung
• Überwachung der Windows-Event-Logs »Application« , »Security« und »System«

Zusätzlich kommt auch hier niemand um das Monitoring der Applikationen herum, zu deren Zweck der Windows-Gast aufgesetzt wurde. Bei dem Einsatz von Branchensoftware ist es möglich, kontinuierlich nach bestimmten laufenden Diensten und Prozessen zu suchen. Segnet der zuständige Dienst zu einer Anwendung das Zeitliche, kann so der Admin zumindest informiert werden.

Bei der Frage nach dem richtigen Monitoringtool liegt der Griff zu Altbewährtem nahe, Nagios [10] scheint die erste Wahl. Dank der Anzahl der frei verfügbaren Check-Plugins und Erweiterungen ist es in vielen Fällen das Tool der Wahl, um einen Stand-alone-Server oder auch den Cluster im Auge zu behalten. Dagegen spricht, dass die Datei-basierte Konfiguration von Nagios so manchem Neuling Probleme bereitet. Für Quereinsteiger oder Freunde von simplen Konfigurationen in komplexen Umgebungen bietet sich ein modifizierten Nagios an, zum Beispiel Opsview [11]. Das Tool setzt auf Nagios auf, erweitert es um zahlreiche Features und bietet ein komfortables und modernes Webinterface. Anders als in manch anderen Weboberflächen kann der Admin hier zusätzlich die gesamte Nagios-Konfiguration vornehmen, neue Hosts anlegen oder einzelne Service-Checks feintunen (Abbildung 3).

Abbildung 3: Nagios für Einsteiger: Opsview wartet mit einem schlanken und übersichtlichen Webinterface auf, erlaubt es aber auch, neue Hosts und Services via GUI hinzuzufügen.

Opsview speichert alle Einstellungen in MySQL-Datenbanken und generiert daraus die Konfigurationsdateien für Nagios. Auch zusätzliche Service-Checks, zum Beispiel für das Überwachen der Unix-Load, sind möglich. Für alle Hosts, die denselben Check zur Überwachung zugeteilt bekommen, greifen dann die allgemeinen Parameter des Service-Checks. Da die überwachten Systeme jedoch meist auch verschiedenen Zwecken dienen, lassen sich die Service-Checks auch über Attribute detaillierter spezifizieren und für jeden einzelnen Host individuell festlegen.

Ein weiteres Schmankerl von Opsview stellen die Benachrichtigungsprofile dar, die sogar für kleinere KVM-Installationen schon sinnvoll sind. Sie ermöglichen es beispielsweise, jeweils nur den Inhaber der virtuellen Instanz über Ausfälle zu benachrichtigen, was dritte Personen vor für sie uninteressanten Benachrichtigungen bewahrt.