Open Source im professionellen Einsatz
Linux-Magazin 05/2012
© maridav, 123Rf

© maridav, 123Rf

Automatisiertes Monitoring mit Pacemaker Resource Agents

Dabeibleiben ist alles

Macht ein Clusterknoten schlapp, startet die HA-Software Pacemaker bekanntermaßen die dabei mitgerissenen Dienste auf einem anderen Knoten neu. Wenig bekannt ist des Schrittmachers Dienste-Monitoring, mit dessen Hilfe der Clustermanager hängenden Diensten einzeln auf die Beine hilft.

506

Pacemaker hat sich zur unangefochtenen Standard-HA-Lösung auf Linux-Systemen entwickelt. Fällt einer von zwei Knoten eines Clusters aus, startet Pacemaker die ausgefallenen Dienste auf dem anderen Clusterknoten neu. Wer Pacemaker allerdings nur zu solchen Failover-Zwecken einsetzt, bringt sich um den Nutzen der besten Features. Dass der Schrittmacher auch abgestürzten Applikationen automatisch wieder auf die Beine helfen kann, ist vielen Admins erstaunlicherweise bis heute unbekannt.

Mehr als nur Umschalten

Es gibt weitaus mehr Gründe dafür, dass ein Dienst nicht mehr läuft, als nur den Ausfall des Servers, der den Dienst bis dahin beheimatet hatte. Applikationen stürzen ab oder werden vom Kernel mangels Arbeitsspeicher (OOM, Out of Memory) in die Knie gezwungen.

Admins rücken solchen Problemen üblicherweise mit umfangreichem Monitoring zu Leibe. Ein nicht mehr laufender Service produziert eine Warnung in Nagios, Icinga & Co. und informiert so den Systembetreuer. Bis dieser allerdings in der Lage ist, das Problem zu lösen, vergeht in der Regel eine gewisse Zeit. Währenddessen ist der abgestürzte Dienst nicht verfügbar – obwohl die restlichen Dienste des Clusters wie gewohnt weiterlaufen, bleibt der Failover also aus.

Das war der Grund für die Entwickler, dem Pacemaker mehr als das bloße Umschalten zwischen zwei Clusterknoten beizubringen. Der Schrittmacher kennt einfaches Monitoring, das in vielen Fällen ausreicht, um ein Problem in den Griff zu kriegen, etwa indem es ein abgestürztes Programm neu startet.

Dabei kommuniziert Pacemaker nicht direkt mit den Diensten. Trägt der Admin beispielsweise seinem Clustermanager auf, dass der Webserver zu starten ist, dann wird Pacemaker Apache nicht direkt aufrufen. Diese Aufgabe erledigen die so genannten Resource Agents: Sie bilden die Schnittstelle zwischen Dienst und Cluster-Schrittmacher. Ein typischer Agent ist ein Shellskript, spezifisch für ein bestimmtes Programm.

Ressourcen-Agenten kennen drei Argumente, die ihnen der Clustermanager beim Aufruf mit auf den Weg geben kann: »start« , »stop« und »monitor« . Pacemaker ruft die Agents mit diesen Parametern auf und erwartet, dass sie entsprechend funktionieren: »start« sollte einen Dienst starten, »stop« sollte ihn beenden und »monitor« informiert Pacemaker darüber, ob ein Dienst noch läuft oder nicht.

Agenten-Klassen

Die Resource Agents für Pacemaker sind in drei Kategorien eingeteilt: LSB-Agenten, also normale Init-Skripte nach LSB-Standard. Daneben gibt es die Heartbeat-Agenten, die aber als veraltet gelten. Die Kategorie der OCF-Agenten bildet die Königsklasse: Diese Agents sind für den Einsatz mit Pacemaker konzipiert und erlauben es in vielen Fällen, Parameter für die Konfiguration eines Dienstes direkt aus der Clusterkonfiguration anzugeben. Allen genannten Klassen ist gemein, dass sie die drei Optionen zum Starten, Beenden und Überwachen von Diensten kennen müssen.

Bevor der Admin die eigene Pacemaker-Installation auf Monitoring trimmt, sollte er testen, ob jeder Resource Agent diese Parameter tatsächlich beherrscht. Denn während bei OCF-Agenten diese Parameter praktisch immer funktionieren, sieht es bei den Init-Skripten bisweilen düster aus: Insbesondere auf Debian-Systemen finden sich diverse, die den »monitor« -Parameter nicht verstehen und daher eine Fehlermeldung ausgeben.

Diesen Artikel als PDF kaufen

Express-Kauf als PDF

Umfang: 4 Heftseiten

Preis € 0,99
(inkl. 19% MwSt.)

Linux-Magazin kaufen

Einzelne Ausgabe
 
Abonnements
 
TABLET & SMARTPHONE APPS
Bald erhältlich
Get it on Google Play

Deutschland

Ähnliche Artikel

  • Galera

    MySQL-Clustervarianten gibt es einige, aber erst ein Team aus Coderships Galera und dem Schrittmacher Pacemaker macht die Datenbank zu einem sicheren Verbund mit den Leistungsreserven beliebig vieler Primary-Knoten. Dafür ist jedoch derzeit noch ein wenig Handarbeit notwendig.

  • Mailserver-HA

    Auch gut 40 Jahre nach der ersten E-Mail gibt es immer noch gute Gründe, einen eigenen IMAP- oder SMTP-Server zu betreiben, zumal diverse Linux-Projekte das so einfach wie nie zuvor machen. Aber Mailserver, die selbst moderne redundante Storage-Backends nutzen, sucht der Admin vergebens.

  • KVM-HA-Monitoring

    Gerade im Notfall will der Admin schnell informiert sein, wenn ein System in der privaten Wolke streikt. Weder Monitoring- noch Hochverfügbarkeits-Konfiguration müssen dabei kompliziert sein, auch ein einfaches Setup mit KVM, Pacemaker, DRBD und Opsview hilft in den meisten Fällen.

  • VM-Livemigration

    Ein großer Vorteil von Virtualisierungen ist die Möglichkeit, Systeme von einem Host auf einen anderen umzuziehen, ohne dass für den Anwender eine längere Downtime entsteht. Damit das reibungslos klappt, müssen sowohl der Hypervisor als auch der verwendete Storage mitspielen.

  • Schrittmacherdienste

    Zero Downtime ist angesichts globaler Zusammenarbeit über Kontinente und Zeitzonen hinweg keine ungewöhnliche Forderung mehr. Daran gebunden ist der Ruf nach Hochverfügbarkeit. Um ihm unter Linux nachzukommen, bietet sich der neue Cluster-Resource-Manager Pacemaker mit weiteren Komponenten an.

comments powered by Disqus

Ausgabe 10/2017

Digitale Ausgabe: Preis € 6,40
(inkl. 19% MwSt.)

Artikelserien und interessante Workshops aus dem Magazin können Sie hier als Bundle erwerben.