Checkmk
to checkmk.com

1. Einleitung

Bei der Bereitstellung wichtiger und geschäftskritischer Services wie Datenbanken oder Websites für den elektronischen Handel (E-commerce) werden Sie sich kaum darauf verlassen, dass der Host, auf dem diese Services laufen, ein langes, stabiles und absturzfreies Leben führen wird. Stattdessen werden Sie den Ausfall eines Hosts einkalkulieren und dafür sorgen, dass andere Hosts bereitstehen, um bei einem Ausfall die Services unmittelbar zu übernehmen (Failover), so dass sich der Ausfall nach außen gar nicht bemerkbar macht.

1.1. Cluster, Knoten und Cluster-Services

Eine Gruppe von vernetzten Hosts, die zusammenarbeiten, um die gleiche Aufgabe zu erledigen, wird als Rechnerverbund oder Computer-Cluster oder kürzer und im folgenden nur noch als Cluster bezeichnet. Ein Cluster agiert nach außen als ein System und organisiert nach innen die Zusammenarbeit der Hosts, um die gemeinsame Aufgabe zu erfüllen.

Ein Cluster kann verschiedene Aufgaben übernehmen, zum Beispiel ein HPC-Cluster das Hochleistungsrechnen (high-performance computing), das unter anderem dann eingesetzt wird, wenn Berechnungen viel mehr Speicher benötigen als auf einem Computer verfügbar ist oder ein Programm mehrfach ausgeführt werden muss (normalerweise mit unterschiedlichen Eingabedaten). Falls das Cluster die Aufgabe hat, die Verfügbarkeit auf Hochverfügbarkeit (high availability) zu erhöhen, wird es auch als HA-Cluster bezeichnet.

Ein Cluster bietet einen oder mehrere Services nach außen an: die sogenannten Cluster-Services. In einem Cluster werden die Hosts, aus denen es besteht, als Knoten (nodes) bezeichnet. Zu einem bestimmten Zeitpunkt wird jeder Service von genau einem der Knoten bereitgestellt. Fällt ein Knoten des Clusters aus, werden alle Services, die für die Aufgabe des Clusters essentiell sind, auf einen der verbleibenden Knoten verschoben.

Um ein Failover transparent zu machen, stellen einige Cluster eine eigene Cluster-IP-Adresse zur Verfügung, die manchmal auch als virtuelle IP-Adresse bezeichnet wird. Die Cluster-IP-Adresse verweist auf den derzeit aktiven Knoten und steht stellvertretend für das gesamte Cluster. Im Falle eines Failovers geht die IP-Adresse auf einen anderen, bisher passiven Knoten über, der dann zum aktiven Knoten wird. Der Client, der mit dem Cluster kommuniziert, braucht nicht umzuschalten. Er kann weiterhin die gleiche IP-Adresse verwenden.

Andere Cluster haben keine Cluster-IP-Adresse. In einem solchen Fall führt der Client eine Liste der IP-Adressen aller Knoten, die den Service bereitstellen könnten, und muss einen Failover im Cluster selbst erkennen. Ein prominentes Beispiel sind Oracle-Datenbank-Cluster in vielen ihrer Varianten.

1.2. Das Monitoring eines Clusters

Checkmk ist einer der Clients, der mit dem Cluster kommuniziert. In Checkmk können alle Knoten eines Clusters eingerichtet und überwacht werden — unabhängig davon, wie die Cluster-Software intern den Status der einzelnen Knoten überprüft und, falls notwendig, einen Failover durchführt.

Die meisten Checks, die Checkmk auf den einzelnen Knoten eines Clusters ausführt, befassen sich mit den physischen Eigenschaften der Knoten, die unabhängig davon sind, ob der Host zu einem Cluster gehört oder nicht. Beispiele dafür sind CPU- und Speichernutzung, lokale Festplatten, physische Netzwerkschnittstellen usw. Für die Abbildung der Cluster-Funktion der Knoten in Checkmk ist es aber notwendig, diejenigen Services zu identifizieren, die die Aufgabe des Clusters definieren und gegebenenfalls auf einen anderen Knoten übertragen werden: die Cluster-Services.

Checkmk hilft Ihnen dabei, die Cluster-Services zu überwachen. Was Sie tun müssen, ist:

  1. Cluster erstellen

  2. Cluster-Services auswählen

  3. Service-Erkennung für alle beteiligten Hosts durchführen

Wie Sie dabei vorgehen, wird im nächsten Kapitel anhand der folgenden Beispielkonfiguration beschrieben: In Checkmk soll ein Windows Failover Cluster als HA-Cluster eingerichtet werden, das aus zwei Knoten mit installiertem Microsoft SQL (MS SQL) Server besteht. Es handelt sich dabei um ein sogenanntes Aktiv/Passiv-Cluster, das heißt, nur auf einem, dem aktiven Knoten läuft eine Datenbankinstanz. Der andere Knoten ist passiv und wird nur im Fall eines Failovers aktiv, fährt die Datenbankinstanz hoch und ersetzt den ausgefallenen Knoten. Die Daten der Datenbankinstanz werden nicht auf den Knoten selbst gespeichert, sondern auf einem gemeinsam genutzten Speichermedium, z.B. einem Storage Area Network (SAN), an das beide Knoten angeschlossen sind. Die Beispielkonfiguration besteht aus den folgenden Komponenten:

  • „mssql_node01“ ist der aktive Knoten mit laufender Datenbankinstanz.

  • „mssql_node02“ ist der passive Knoten.

  • „mssql_cluster01“ ist das Cluster, dem beide Knoten angehören.

Anders als in diesem Beispiel ist es auch möglich, das derselbe Knoten in mehreren Clustern enthalten ist. Im letzten Kapitel erfahren Sie, wie Sie solche überlappenden Cluster konfigurieren anhand einer abgeänderten Beispielkonfiguration.

2. Cluster und Cluster-Services einrichten

2.1. Cluster erstellen

In Checkmk werden die Knoten und das Cluster selbst als Hosts erstellt (Knoten-Hosts und Cluster-Hosts), wobei es für einen Cluster-Host einen speziellen Host-Typen gibt. Der Cluster-Host ist ein logischer Host, der mit Cluster-IP-Adresse konfiguriert werden soll, wenn diese existiert.

Vor der Einrichtung eines Cluster-Hosts gibt es folgendes zu beachten:

  • Cluster-Hosts können auf die gleiche Art und Weise konfiguriert werden wie „normale“ Hosts, zum Beispiel mit Host-Gruppen oder Host-Merkmalen.

  • Für alle beteiligten Hosts (damit sind stets der Cluster-Host und alle zugehörigen Knoten-Hosts gemeint), müssen die Datenquellen identisch konfiguriert werden, d.h. insbesondere dürfen nicht einige per Check_MK Agent und andere per SNMP konfiguriert sein. Ab Version 1.6.0p12 stellt Checkmk sicher, dass ein Cluster-Host nur dann erstellt werden kann, wenn diese Voraussetzung erfüllt ist.

  • In einem verteilten Monitoring müssen alle beteiligten Hosts derselben Checkmk-Instanz zugeordnet sein.

  • Nicht alle Checks funktionieren in einer Cluster-Konfiguration.

In unserem Beispiel sind die beiden Knoten-Hosts „mssql_node01” und „mssql_node02“ bereits als Hosts angelegt und eingerichtet. Wie es so weit kommen konnte, können Sie im Artikel zur Überwachung von Windows-Servern nachlesen — und dort im Abschnitt zur Erweiterung des Standard Windows-Agenten mit Plugins, für unser Beispiel den MS SQL Server-Plugins.

Tipp: Falls die Hosts in Ordner organisiert sind, vereinfacht es die Einrichtung (bei der Auswahl der Cluster-Services im nächsten Kapitel) wenn sich alle beteiligten Hosts im gleichen Ordner befinden.

Starten Sie die Erstellung des Clusters mit WATO > Hosts > New cluster > Create new cluster.

Sie erhalten die Seite Create new cluster:

Geben Sie als Hostname den Namen des Cluster-Hosts ein und tragen Sie unter Nodes die beiden Knoten-Hosts ein. Als IPv4 Address können Sie (falls verfügbar) die Cluster-IP-Adresse eintragen. Stellen Sie sicher, dass im Abschnitt Data Sources die gleichen Datenquellen ausgewählt sind wie bei den beiden Knoten-Hosts.

Schließen Sie die Erstellung mit Save & Finish ab und aktivieren Sie die Änderungen.

2.2. Cluster-Services auswählen

Checkmk kann nicht wissen, welche der auf einem Knoten laufenden Services lokale und welche Cluster-Services sind: Einige Dateisysteme können lokal sein, andere sind möglicherweise nur auf dem aktiven Knoten gemountet. Ähnliches gilt für Prozesse: Während der NTP (Network Time Protocol) Daemon höchstwahrscheinlich auf allen Knoten läuft, wird eine bestimmte Datenbankinstanz nur auf dem aktiven Knoten verfügbar sein.

Statt Checkmk raten zu lassen, wählen Sie die Cluster-Services mit einer Regel aus. Für das Beispiel gehen wir davon aus, dass die Namen aller MS SQL Server Cluster-Services mit MSSQL beginnen und das Dateisystem des gemeinsam genutzten Speichermedium über das Laufwerk E:\ zugreifbar ist.

Starten Sie mit WATO > Hosts und klicken Sie den Cluster-Namen an. Auf der Seite Properties of host klicken Sie den Knopf Clustered Services.

Wählen Sie als Create rule in folder den Ordner aus, der die Knoten-Hosts enthält, da die Regel für die Hosts gilt, auf denen die Services laufen (d.h. nicht den Ordner mit dem Cluster-Host, falls die Hosts in unterschiedlichen Ordnern organisiert sind).

Sie erhalten die Seite New rule: Clustered services:

Unter Services machen Sie zwei Einträge: MSSQL für alle MS SQL-Services, deren Name mit „MSSQL“ beginnen und Filesystem E: für das Laufwerk. Die Eingaben werden als reguläre Ausdrücke interpretiert, zum Beispiel führt die Eingabe von MSSQL dazu, dass alle Services ausgewählt werden, deren Namen mit "MSSQL" beginnen.

Schließen Sie die Erstellung der Regel mit Save ab und aktivieren Sie die Änderungen.

Alle Services, die nicht als Cluster-Services definiert sind, werden von Checkmk als lokale Services behandelt.

2.3. Service-Erkennung für alle beteiligten Hosts durchführen

Für alle beteiligten Hosts (Cluster- und Knoten-Hosts) muss zum Abschluss eine neue Service-Erkennung (discovery) durchgeführt werden, damit alle neu definierten Cluster-Services zuerst bei den Knoten entfernt und dann beim Cluster hinzugefügt werden.

Unter WATO > Hosts markieren Sie zuerst alle beteiligten Hosts und klicken Sie dann den Knopf Bulk discovery. Auf der Seite Bulk discovery sollte die erste Option Add unmonitored services and new host labels zum gewünschten Ergebnis führen.

Klicken Sie Start um die Serviceerkennung für viele Hosts zu beginnen. Nach erfolgreichem Abschluss, erkennbar an der Meldung "Bulk discovery successful", aktivieren Sie die Änderungen.

Um herauszufinden, ob die Auswahl der Cluster-Services zum gewünschten Ergebnis geführt hat, können Sie sich alle Services auflisten, die dem Cluster zugewiesen sind: Unter WATO > Hosts klicken Sie in der Host-Liste beim Eintrag des Cluster-Hosts auf icon services. Auf der folgenden Seite Services of host werden unter Monitored services alle Cluster-Services aufgelistet.

Auf der anderen Seite, bei den Knoten-Hosts, fehlen nunmehr genau die zum Cluster verschobenen Services in der Liste der überwachten Services. Am Knoten-Host finden Sie diese am Ende der Services-Liste im Abschnitt Monitored clustered services (located on cluster host).

3. Überlappende Cluster

Es ist möglich, dass mehrere Cluster einen oder auch mehrere Knoten gemeinsam nutzen. Man spricht dann von überlappenden Clustern. Bei überlappenden Clustern benötigen Sie eine spezielle Regel, um Checkmk mitzuteilen, welche Cluster-Services eines gemeinsam genutzten Knoten-Hosts welchem Cluster zugeordnet werden sollen.

Das prinzipielle Vorgehen beim Einrichten eines überlappenden Clusters werden wir im folgenden vorstellen, indem wir das Beispiel des MS SQL Server Clusters von einem Aktiv/Passiv- zu einem Aktiv/Aktiv-Cluster abwandeln. In dieser Konfiguration ist nicht nur MS SQL Server auf beiden Knoten-Hosts installiert, sondern auf jedem der beiden Knoten läuft eine eigene Datenbankinstanz. Beide Knoten greifen auf das gemeinsam genutzte Speichermedium zu, aber auf unterschiedlichen Laufwerken. Dieses Beispiel realisiert ein zu 100% überlappendes Cluster, da die beiden Knoten beiden Clustern angehören.

Der Vorteil des Aktiv/Aktiv-Clusters besteht darin, dass die verfügbaren Ressourcen der beiden Knoten besser genutzt werden. Im Fall eines Failovers wird die Aufgabe des ausgefallenen Knotens vom anderen Knoten übernommen, auf dem dann beide Datenbankinstanzen laufen.

Diese Beispielkonfiguration besteht somit aus den folgenden Komponenten:

  • „mssql_node01“ ist der erste aktive Knoten mit laufender Datenbankinstanz.

  • „mssql_node02“ ist der zweite aktive Knoten, ebenfalls mit einer laufenden Datenbankinstanz.

  • „mssql_cluster01“ und „mssql_cluster02“ sind die beiden Cluster, denen beide Knoten angehören.

Den 1. Schritt zur Einrichtung des Aktiv/Passiv-Clusters müssen Sie für ein Aktiv/Aktiv-Cluster nur leicht abwandeln: Sie erstellen, wie oben beschrieben, das erste Cluster „mssql_cluster01“. Anschließend erstellen Sie das zweite Cluster „mssql_cluster02“ mit denselben beiden Knoten-Hosts.

Im 2. Schritt nutzen Sie zur Auswahl der Cluster-Services statt der allgemeinen Regel Clustered services die speziell für überlappende Cluster geltende Regel Clustered services for overlapping clusters. Damit definieren Sie in einer Regel die Cluster-Services eines oder mehrerer Knoten-Hosts und ordnen sie dem richtigen Cluster zu.

Für unser Beispiel mit 100% Überlappung benötigen wir zwei dieser Regeln: Die erste Regel definiert die Cluster-Services des ersten Knoten-Hosts und ordnet sie dem ersten Cluster zu. Die zweite Regel tut dies analog für den zweiten Knoten-Host und das zweite Cluster.

Starten wir mit der ersten Regel: Unter WATO > Host & Service Parameters suchen Sie nach "overlapping clusters" und klicken die gefundene Regel Clustered services for overlapping clusters an. Wählen Sie als Create rule in folder wieder den Ordner aus, der die Knoten-Hosts enthält. Sie erhalten die Seite New rule: Clustered services for overlapping clusters:

Ordnen Sie den ersten Knoten-Host mit seinen Cluster-Services dem ersten Cluster zu: Als Assign services to the following cluster tragen Sie das erste Cluster „mssql_cluster01“ ein. Aktivieren Sie Explicit hosts und tragen Sie den ersten Knoten-Host „mssql_node01“ ein. Unter Services machen Sie zwei Einträge: MSSQL für alle MS SQL-Services und Filesystem E: für das Laufwerk.

Schließen Sie die Erstellung der ersten Regel mit Save ab und erstellen Sie anschließend gleich die zweite Regel, diesmal für den zweiten Knoten-Host „mssql_node02“ und das zweite Cluster „mssql_cluster02“. Unter Services tragen Sie wieder MSSQL ein, da auch der zweite Knoten-Host eine laufende Datenbankinstanz hat. Auch der zweite Knoten-Host greift auf das Speichermedium zu, aber unter einem anderen Laufwerk als der erste. Wenn dies zum Beispiel das Laufwerk F:\ ist, erstellen Sie einen neuen Eintrag Filesystem F:.

Sichern Sie die Regel und aktivieren Sie die Änderungen.

Führen Sie abschließend die Service-Erkennung für alle beteiligten Hosts als 3. und letzten Schritt genauso aus wie oben beschrieben: als Bulk discovery für alle beteiligten Hosts.

Hinweis: Falls mehrere Regeln einen Cluster-Service definieren, hat die spezifischere Regel Clustered services for overlapping clusters mit der expliziten Zuordnung zu einem bestimmten Cluster Vorrang vor der allgemeineren Regel Clustered Services. Für die beiden in diesem Artikel vorgestellten Beispiele bedeutet das: Durch die beiden zuletzt erstellten spezifischen Regeln würde die im ersten Beispiel erstellte allgemeine Regel nie zur Anwendung kommen.

Auf dieser Seite