Cluster mit Open AIS und Corosync

Oleksii Glushenkov, 123RF

Im Gleichtakt

Das Setup hochverfügbarer Cluster-Ressourcen gehört heute zum Standardrepertoire eines Admin. Viele Hersteller bieten dafür eigene, oftmals proprietäre Produkte. Dieser Artikel beschreibt die Grundlagen eines Clusters mit der freien Open-AIS-/Corosync-basierten Cluster Suite.
Thematischer Schwerpunkt dieser Ausgabe ist die kontinuierliche Überwachung von Servern, Clients und anderen Geräten im Netzwerk: mit dem IPMI-Plugin, dem ... (mehr)

Bei Clustern ist grundsätzlich zwischen verschiedenen Varianten zu unterscheiden. So existieren zum einen die so genannten Speichercluster, deren Aufgabe es ist, den Zugriff auf ein einzelnes Dateisystem von mehreren Systemen aus zu ermöglichen. Die lästige Synchronisierung der Daten zwischen den einzelnen Rechnern entfällt dabei, da der Zugriff auf einen gemeinsamen Datenspeicher stattfindet.

Hochverfügbarkeits-Cluster (HA) bündeln einzelne Ressourcen, etwa Dateisysteme und IP-Adressen, zu einem Clusterservice. Beim Ausfall einer Ressource versucht der Cluster diese erneut zu aktivieren. Sollte der Rechner, auf dem der Clusterservice läuft, komplett ausfallen, wird dieser auf einem anderen Rechner neu gestartet. So ist sichergestellt, dass der Service, zum Beispiel ein Webserver, zu jeder Zeit verfügbar ist.

Lastverteilungs-Cluster verstecken mehrere Systeme hinter einer einzelnen IP-Adresse und verteilen nach einem bestimmten Algorithmus alle eingehenden Anfragen auf diese Backend-Systeme. Fällt eins dieser Systeme aus, erhält es auch keine Anfragen mehr. Gerade bei gut besuchten Webservern kommen solche Cluster zum Einsatz, da ein einzelner Rechner die Vielzahl von Anfragen oft nicht alleine bewältigen kann.

Schließlich gibt es noch die so genannten Hochleistungs-Cluster, bei denen komplizierte Berechnungen auf die einzelnen Clusterknoten verteilt werden, um so eine höhere Rechenkapazität zu erreichen. Sie kommen oft in der Forschung oder der Industrie zum Einsatz, beispielsweise in der Automobilbranche, um Crashtest-Simulationen durchzuführen. In diesem Artikel geht es primär um HA- und Speicher-Cluster.

Cluster-Komponenten

Ein Clusterknoten setzt sich immer aus mehreren Komponenten zusammen. Das Herzstück bildet dabei der Clustermanager, der sozusagen das Kommunikationssystem des Clusters darstellt und entscheidet, welche Systeme zu einem Clusterverbund gehören und welche aus dem Cluster zu entfernen sind. Als Entscheidungsgrundlage kommen so genannte Quorum-Regeln zum Einsatz. Arbeitet ein System fehlerhaft oder gar nicht mehr, greift der Clustermanager auf ein weiteres Subsystem, das Fencing-System, zurück, um den fehlerhaften Knoten zu entfernen.

Der Fencing-Daemon kommuniziert dabei mit Hilfe bestimmter Agenten mit so genannten Fencing-Geräten. Dabei kann es sich um Management-Boards, Power-Switches, aber auch SAN-Switches handeln. Wichtig ist, dass nach dem Fencing der Zugriff von einem fehlerhaft arbeitenden Knoten auf eine bestimmte Cluster-Ressource nicht mehr möglich ist.

Um den Zugriff auf einen gemeinsamen Datenspeicher zu ermöglichen, ist ein Locking-Subsystem nötig. Bei einem Cluster-Dateisystem wie GFS2 [1] ist eine Kommunikation zwischen den einzelnen Knoten wichtig, die sicherstellt, dass zu einem Zeitpunkt immer nur ein System eine Änderung an einem Dateisystem-Block durchführt, erst dann kommt ein anderer Knoten dran. Auch beim Volume-Management selbst ist eine Synchronisation der Knoten untereinander notwendig. Beide Funktionen übernimmt der Lock-Manager.

Schließlich gibt es bei HA-Clustern noch den Ressourcen-Manager. Dieser kümmert sich um die Überwachung und das Management der konfigurierten Cluster-Ressourcen und Services. Im Fehlerfall eines Knotens kann der Ressourcen-Manager die Clusterservices auf einem anderen Knoten neu starten. Für den Benutzer ist dieser Service-Neustart nahezu transparent, er merkt von dem Ausfall eines Systems nichts ( Abbildung 1 ).

Abbildung 1: Beim Failover startet der Ressource-Manager eine Cluster-Ressource-Gruppe auf einem anderen Host.

Clustermanager

Red Hat Enterprise Linux (RHEL) und Fedora enthalten beide die Red Hat Cluster Suite (RHCS). Als Clustermanager kommt CMAN zum Einsatz. Je nach eingesetzter Version sieht dessen Implementierung jedoch komplett anders aus. So war in der initialen Variante (Version 1.0), die beispielsweise in RHEL 4 oder sehr alten Fedora-Versionen enthalten war, CMAN komplett im Kernelspace implementiert.

Ein Zugriff von Applikationen aus dem Userspace fand über das Libcman-API statt. Im Netzwerkbereich kam UDP-Broadcast/Unicast zum Einsatz. Der alte CMAN-Code wurde ausschließlich von Red Hat entwickelt und betreut.

In neueren Versionen (2.0), beispielsweise in RHEL 5 und ab Fedora Core 6, wurde die überholte CMAN-Implementierung durch eine offene Implementierung auf Basis der Application Interface Specification (AIS) abgelöst. Das Open-AIS-Framework [3] ist modular aufgebaut und bietet mit »aisexec« einen Daemon im Userspace, der über verschiedene Module auf weitere Subsysteme zurückgreifen kann. So existiert beispielsweise ein Subsystem »totem« , welches das Messaging-System für den Clustermanager bildet.

Der CMAN-Code von Red Hat wurde nun so abgeändert, dass CMAN lediglich ein weiteres Modul für das Open-AIS-System darstellt. Aufgabe dieses CMAN-Moduls ist es eigentlich nur noch, ein einheitliches API für bestehende Applikationen bereitzustellen, sollten diese Informationen vom eigentlichen Clustermanager benötigen.

Daneben ist das Modul noch für die Kommunikation mit dem Quorum-Daemon zuständig. Dieser kommt optional zum Einsatz, wenn es um die Berechnung des Quorums für einen Cluster geht. Dazu dient ein bestimmter Algorithmus, wobei der Quorum-Daemon ein optionaler Teil davon sein kann.

Netzwerk-seitig kommt bei Open-AIS UDP-Multicast/Unicast zum Einsatz. Sollte in der Konfiguration für den Clustermanager keine Multicast-Adresse angegeben sein, wird diese dynamisch generiert. Sie beginnt dann mit 239.192, wobei die letzten beiden Oktetts auf Basis der Cluster-ID erzeugt werden.

In der Cluster-Suite-Version 3.0 von RHEL 6 und Fedora 10 wurde nun Open AIS durch Corosync [2] ausgetauscht. Von außen betrachtet hat sich zwischen den beiden Clustermanagern nicht viel verändert, der Code unterscheidet sich zum Teil aber wesentlich. Die alten Open-AIS-Module stehen teilweise immer noch zur Verfügung, es sind jedoch auch neue Module hinzugekommen. Diese werden nun nicht mehr durch »aisexec« , sondern durch Corosync aufgerufen.

Kommen Open AIS oder Corosync zusammen mit dem CMAN-Modul in der Red Hat Cluster Suite zum Einsatz, findet die Konfiguration des Clustermanagers nicht wie üblich über die Konfigurationsdateien »/etc/ais/openais.conf« beziehungsweise »/etc/corosync/corosync.conf« statt, sondern über die XML-Datei »/etc/cluster/cluster.conf« .

Ab der Cluster-Suite-Version 3.0 lässt sich als Konfigurations-Repository auch ein LDAP-Server einsetzen. Die Datei »/etc/sysconfig/cman« enthält dabei einen Konfiguratiosparameter »CONFIG_LOADER« , der als Wert entweder »xmlconfig« oder »ldapconfig« enthalten kann. Beim Starten von CMAN mittels »/etc/init.d/cman start« lädt das entsprechende CMAN-Modul dann entweder die Konfigurationsoptionen aus der XML-Datei oder vom LDAP-Server in die Corosync-Objektdatenbank. Eine minimale XML-Konfigurationsdatei zeigt Listing 1 .

Listing 1

XML-Config für den Clustermanager

 

comments powered by Disqus
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

Ausgabe /2023