Thematischer Schwerpunkt dieser Ausgabe ist die kontinuierliche Überwachung von Servern, Clients und anderen Geräten im Netzwerk: mit dem IPMI-Plugin, dem ... (mehr)

Konfiguration aus LDAP

Damit jeder Clusterknoten auf die Konfiguration zugreifen kann, müssen Sie in der bereits angesprochenen Konfigurationsdatei »/etc/sysconfig/cman« noch den LDAP-Server und den »BaseDN« angeben:

# grep -i ldap /etc/sysconfig/cman
CONFIG_LOADER=ldapconfig
COROSYNC_LDAP_URL=ldap://ldap.tuxgeek.de

Nach einem Neustart von CMAN sollte dieser nun in der Lage sein, die Corosync-Objektdatenbank mit den Einträgen aus dem LDAP-Server zu füllen. Möchten Sie neue Objekte, beispielsweise Fencing-Devices oder Cluster-Ressourcen, zur LDAP-Datenbank hinzufügen, bietet es sich an, diese zuerst in einer Art Dummy-XML-Datei zu hinterlegen, um aus ihr dann wieder die passende LDIF-Datei zu generieren. Das Verwalten der Cluster-Konfiguration in einem LDAP-Baum ist derzeit noch experimentell und sollte in produktiven Umgebungen nicht eingesetzt werden.

Wie bereits angesprochen wurde, ist der Ressourcen-Manager in einem HA-Cluster dafür zuständig, Clusterservices – auch unter dem Namen Ressource-Gruppen bekannt – bereitzustellen und zu managen. Dazu gehören das manuelle und automatische Starten und Stoppen der Services sowie das Umschalten auf einen anderen Clusterknoten, sollte der gerade aktive Knoten ausfallen.

In den Versionen 1.0 und 2.0 war »rgmanager« der alleinige Herrscher in einem Red-Hat-Cluster, ab der Cluster-Suite-Version 3.0 ist nun auch »pacemaker« in RHEL 6 und ab Fedora 12 enthalten. Die Konfiguration findet bei »rgmanager« ebenfalls über die XML-Datei »cluster.conf« oder über LDAP statt, »pacemaker« hat seine eigene XML-basierte Konfigurationsdatei – auch als Cluster Information Base (CIB) bekannt. Manuelles Editieren dieser Datei ist allerdings nicht anzuraten, stattdessen greifen Sie besser auf das Tool »crm« zurück. Im folgenden Abschnitt geht es um den alteingesessenen »rgmanager« .

In der XML-Datei »cluster.conf« erfolgen alle Konfigurationsanweisungen für den »rgmanager« im Abschnitt »rm« . Als Erstes bietet es sich an, für die hochverfügbaren Clusterservices eine Failover-Domäne einzurichten. Hiermit beschränken Sie die Clusternodes, auf denen ein Service laufen kann. Das ist recht praktisch, wenn Sie beispielsweise schwergewichtige Oracle-Datenbanken nur auf entsprechend leistungsstarken Maschinen im Cluster betreiben wollen. Die Konfiguration für eine solche Fail-over-Domäne zeigt Listing 6.

Listing 6

Failover-Domänen

 

Mit den Anweisungen »ordered« , »restricted« und »nofailback« legen Sie fest, ob bestimmte Knoten innerhalb einer Domäne bevorzugt behandelt werden, ob der Service auch auf anderen Knoten außerhalb der Failover-Domäne laufen darf und ob ein Failover auf einem bevorzugten Knoten stattfinden soll, sollte dieser wieder innerhalb einer Failover-Domäne verfügbar werden, beispielsweise nach einem Fence-Event.

Eine Ressource-Gruppe setzt sich aus einzelnen Cluster-Ressourcen zusammen. Diese können Sie entweder getrennt in einem »resources« -Block aufführen oder unmittelbar bei der Definition eines Service angeben. Die erste Variante hat den Vorteil, dass Sie die Ressourcen mehrfach verwenden können, indem Sie darauf referenzieren. Die Ressource-Gruppe selbst definieren Sie innerhalb eines »service« -Blocks und verweisen dort auf die eben angesprochenen Ressourcen.

Um den Service an eine zuvor eingerichtete Failover-Domäne zu binden, geben Sie diese einfach mit dem Parameter »domain« an. Als Default-Service-Policy kommt »restart« zum Einsatz, das heißt, sollte der Service einmal ausfallen, versucht »rgmanager« ihn auf dem gleichen Knoten neu zu starten. Schlägt dies fehl, startet der Ressource-Manager den Service auf einem anderen Knoten der angegebenen Failover-Domäne. Listing 7 zeigt die Konfiguration eines hochverfügbaren Webservers.

Listing 7

Cluster-Services per rgmanager

 

Die einzelnen Cluster-Ressourcen überwacht »rgmanager« mit so genannten Ressource-Skripten. Es handelt sich um OCF- und LSB-kompatible ([4], [5]), Skripte im Verzeichnis »/usr/share/cluster/« . Die Startreihenfolge der Ressourcen ist in der Datei »service.sh« definiert, allerdings lässt sich eine Abhängigkeit zwischen einzelnen Ressourcen auch einfach durch Einrücken erreichen (Listing 7). Die Timeouts zum Starten und Stoppen und das Intervall zum Überprüfen der Ressourcen befinden sich in den jeweiligen Ressource-Skripten selbst.

Nach der Konfiguration des Cluster- und Ressourcen-Managers können Sie die eingerichteten Clusterservices starten. Hierfür bietet sich das Tool »clusvcadm« an:

clusvcadm -e service:www

Fazit

Im Laufe der Jahre hat sich hinter den Kulissen der Red Hat Cluster Suite einiges getan. Von einer selbst entwickelten Applikation mit einem Kernel-basierten Clustermanager hat sich das Framework zu einem komplett offenen Clustermanager auf Basis von Corosync entwickelt. Der alte CMAN spielt nur noch eine relativ geringe Rolle und bietet hauptsächlich Legacy-Funktionen. An der Konfiguration selbst hat sich relativ wenig geändert hat, sie findet nach wie vor über die XML-Datei »cluster.conf« statt.

Für die Cluster-Ressourcen selbst kommt weiterhin »rgmanager« zum Einsatz, mit Pacemaker gibt es aber eine Alternative aus dem bekannten Heartbeat-Projekt. Auch wenn die komplette Integration noch dauern wird, einen ersten Eindruck vermitteln das aktuelle Fedora 14 oder auch RHEL 6, wo Pacemaker bereits als Tech-Preview enthalten ist. Aktuelle Informationen zu Entwicklungen im Cluster-Umfeld finden sich auf den Cluster-Seiten von Red Hat [4].

Der Autor

Thorsten Scherf arbeitet als Senior Consultant für Red Hat EMEA. Er ist oft als Vortragender auf Konferenzen anzutreffen. Wenn ihm neben Arbeit und Familie noch Zeit bleibt, nimmt er gerne an Marathonläufen teil.

comments powered by Disqus
Mehr zum Thema

HA-Workshop, Teil 7: GFS mit DRBD und Pacemaker

Cluster-Dateisysteme wie GFS2 und OCFS2 ermöglichen vielen Clients den gleichzeitigen Zugriff auf ein Storage-Device. Dank DRBD und Pacemaker wird der Dienst so auf günstige Weise redundant – allerdings hat die Sache ein paar Haken.

Artikel der Woche

Eigene Registry für Docker-Images

Wer selber Docker-Images herstellt, braucht auch eine eigene Registry. Diese gibt es ebenfalls als Docker-Image, aber nur mit eingeschränkter Funktionalität. Mit einem Auth-Server wird daraus ein brauchbares Repository für Images. (mehr)
Einmal pro Woche aktuelle News, kostenlose Artikel und nützliche ADMIN-Tipps.
Ich habe die Datenschutzerklärung gelesen und bin einverstanden.

Konfigurationsmanagement

Ich konfiguriere meine Server

  • von Hand
  • mit eigenen Skripts
  • mit Puppet
  • mit Ansible
  • mit Saltstack
  • mit Chef
  • mit CFengine
  • mit dem Nix-System
  • mit Containern
  • mit anderer Konfigurationsmanagement-Software

Google+

Ausgabe /2019