Pacemaker und Corosync: Hochverfügbarkeits-Cluster Grundlagen

1. Rollenverteilung: Corosync und Pacemaker

Pacemaker und Corosync bilden zusammen den etablierten Cluster-Stack für Hochverfügbarkeit unter Linux, wobei beide Komponenten unterschiedliche, klar getrennte Aufgaben übernehmen. Corosync ist die Kommunikationsschicht, die Cluster-Mitgliedschaft verwaltet, Herzschlag-Nachrichten zwischen den Knoten austauscht und feststellt, welche Knoten gerade erreichbar sind. Ohne diese zuverlässige Kommunikationsebene könnte kein Cluster-Manager überhaupt wissen, ob ein Knoten ausgefallen oder nur langsam ist.

Pacemaker setzt auf dieser Kommunikationsschicht auf und übernimmt die eigentliche Ressourcen-Orchestrierung: Es startet, stoppt und überwacht beliebige Ressourcen wie IP-Adressen, Dateisysteme, Datenbank-Dienste oder Applikationsserver, verschiebt sie bei einem Knotenausfall auf einen gesunden Knoten und respektiert dabei komplexe Abhängigkeiten zwischen mehreren Ressourcen. Diese Kombination macht Pacemaker deutlich mächtiger als keepalived, aber auch entsprechend komplexer in Konfiguration und Betrieb.

Der typische Anwendungsfall für Pacemaker und Corosync ist ein Cluster, in dem mehrere zusammengehörige Ressourcen gemeinsam verwaltet werden müssen, etwa ein freigegebenes Dateisystem, das nur auf einem Knoten gleichzeitig gemountet sein darf, ein Datenbank-Dienst, der darauf zugreift, und eine virtuelle IP, die auf denselben Knoten zeigen muss. Genau für diese Art koordinierter Abhängigkeiten ist keepalived nicht ausgelegt, während Pacemaker dafür entworfen wurde.

2. Installation und Cluster-Grundgerüst

Auf den meisten modernen Distributionen wird der Cluster über das Kommandozeilenwerkzeug pcs verwaltet, das Corosync- und Pacemaker-Konfiguration hinter einer einheitlichen Schnittstelle vereinfacht. Nach der Installation muss auf jedem Knoten der Systembenutzer hacluster mit einem gemeinsamen Passwort authentifiziert werden, bevor die Knoten sich gegenseitig als Cluster-Mitglieder registrieren.

# Install the cluster stack on RHEL/AlmaLinux (both nodes)
sudo dnf install -y pacemaker pcs pcs-cli resource-agents

# Set a shared password for the hacluster system user (both nodes)
sudo passwd hacluster

# Start and enable the pcs daemon (both nodes)
sudo systemctl enable --now pcsd

# Authenticate node1 against node2 (run once, from node1)
sudo pcs host auth node1 node2 -u hacluster

# Create the cluster with both nodes as members
sudo pcs cluster setup my_cluster node1 node2

# Start the cluster on all nodes and enable it on boot
sudo pcs cluster start --all
sudo pcs cluster enable --all

Nach diesen Schritten zeigt pcs status den aktuellen Cluster-Zustand, inklusive aller Knoten und ihrer Erreichbarkeit. An dieser Stelle ist der Cluster technisch aktiv, verwaltet aber noch keine einzige Ressource. Die eigentliche Konfiguration der zu schützenden Dienste erfolgt im nächsten Schritt.

3. Cluster-Ressourcen definieren

Eine Cluster-Ressource ist alles, was Pacemaker starten, stoppen und überwachen soll, angesprochen über sogenannte Resource Agents. Diese Agents sind standardisierte Skripte, die eine einheitliche Schnittstelle für Start-, Stop- und Monitor-Operationen implementieren, egal ob es sich um eine IP-Adresse, ein Dateisystem oder einen Datenbank-Dienst handelt. Die bekannteste Agent-Klasse ist ocf:heartbeat, die eine breite Palette gängiger Dienste abdeckt.

Jede Ressource wird mit einem eindeutigen Namen sowie ressourcenspezifischen Parametern registriert. Für eine virtuelle IP-Adresse ist das etwa die IP selbst und die Netzmaske, für ein Dateisystem der Gerätepfad und der Mount-Punkt. Pacemaker überwacht anschließend jede Ressource in einem konfigurierbaren Intervall und reagiert auf Fehler automatisch, indem es die Ressource neu startet oder auf einen anderen Knoten verschiebt.

# Define a virtual IP resource
sudo pcs resource create cluster_vip ocf:heartbeat:IPaddr2 \
  ip=192.168.10.100 cidr_netmask=24 \
  op monitor interval=10s

# Define a filesystem resource (shared storage, e.g. iSCSI or DRBD device)
sudo pcs resource create shared_fs Filesystem \
  device="/dev/sdb1" directory="/mnt/shared" fstype="xfs" \
  op monitor interval=20s

# Define a database service resource
sudo pcs resource create mysql_db systemd:mariadb \
  op monitor interval=15s

4. Fencing mit STONITH: Warum es Pflicht ist

Fencing, in Pacemaker als STONITH bezeichnet, kurz für Shoot The Other Node In The Head, ist der Mechanismus, mit dem ein Cluster einen als fehlerhaft eingestuften Knoten aktiv vom Netzwerk trennt oder neu startet, statt sich nur auf dessen Selbstauskunft zu verlassen. Ohne Fencing besteht immer das Risiko, dass ein vermeintlich ausgefallener Knoten in Wahrheit noch läuft, weiterhin auf ein geteiltes Dateisystem schreibt und damit Datenkorruption verursacht, während ein anderer Knoten dieselbe Ressource übernommen hat.

STONITH-Geräte reichen von IPMI-basiertem Fencing über die Server-Management-Schnittstelle bis zu API-basiertem Fencing bei Cloud-Providern, die eine VM per API-Aufruf hart abschalten können. Ein Cluster ohne konfiguriertes Fencing gilt in produktiven Umgebungen als nicht betriebssicher, selbst wenn er im Normalbetrieb einwandfrei funktioniert, weil genau der Ausfallfall, für den der Cluster überhaupt gebaut wurde, ohne Fencing zu Dateninkonsistenz führen kann.

# Configure IPMI-based fencing for node1 (adjust IP/credentials per environment)
sudo pcs stonith create fence_node1 fence_ipmilan \
  pcmk_host_list="node1" ipaddr="192.168.20.11" \
  login="admin" passwd="s3cr3tIpmiPass" lanplus=1

sudo pcs stonith create fence_node2 fence_ipmilan \
  pcmk_host_list="node2" ipaddr="192.168.20.12" \
  login="admin" passwd="s3cr3tIpmiPass" lanplus=1

# Verify STONITH is enabled and configured (never disable in production)
sudo pcs property show stonith-enabled

5. Constraints: Reihenfolge und Kolokation

Sobald mehrere Ressourcen gemeinsam verwaltet werden, muss Pacemaker wissen, in welcher Reihenfolge sie gestartet werden müssen und ob sie zwingend auf demselben Knoten laufen müssen. Diese Regeln heißen Constraints. Eine order-Constraint definiert, dass etwa das Dateisystem gemountet sein muss, bevor die Datenbank startet, während eine colocation-Constraint erzwingt, dass Dateisystem, Datenbank und virtuelle IP immer auf demselben Knoten laufen, da sie sonst nicht funktionsfähig wären.

Ohne Constraints könnte Pacemaker theoretisch die Datenbank auf Knoten A und das zugehörige Dateisystem auf Knoten B platzieren, was die Anwendung sofort unbrauchbar machen würde. Constraints sind deshalb keine Optimierung, sondern eine notwendige Korrektheitsbedingung für jeden Cluster mit mehr als einer Ressource.

# Filesystem must be mounted before the database starts
sudo pcs constraint order shared_fs then mysql_db

# Database must start before the virtual IP becomes active
# (clients should only see the IP once the DB is reachable)
sudo pcs constraint order mysql_db then cluster_vip

# All three resources must always run on the same node
sudo pcs constraint colocation add mysql_db with shared_fs INFINITY
sudo pcs constraint colocation add cluster_vip with mysql_db INFINITY

# Group them for simpler management (equivalent to the constraints above)
sudo pcs resource group add app_group shared_fs mysql_db cluster_vip

6. Ein vollständiges Zwei-Knoten-Beispiel

Ein realistisches Zwei-Knoten-Setup für einen ausfallsicheren Datenbank-Dienst kombiniert alle bisher gezeigten Bausteine: geteiltes Storage über ein DRBD- oder iSCSI-Gerät, ein Dateisystem darauf, den Datenbank-Dienst selbst und eine virtuelle IP, alle als Ressourcen-Gruppe zusammengefasst. Fällt der aktive Knoten aus, unmountet Pacemaker das Dateisystem nicht erst manuell, sondern erkennt über Fencing zuverlässig, dass der alte Knoten wirklich abgeschaltet ist, bevor die Ressourcen-Gruppe komplett auf dem verbleibenden Knoten gestartet wird.

Dieser Ablauf unterscheidet sich fundamental von keepalived, wo nur eine einzelne IP-Adresse wandert. Bei Pacemaker wird eine ganze Kette abhängiger Dienste kontrolliert heruntergefahren und in korrekter Reihenfolge auf dem neuen Knoten wieder hochgefahren, was für Datenbank-Failover mit gemeinsamem Storage der einzig sichere Weg ist, Datenkorruption durch gleichzeitigen Schreibzugriff zweier Knoten zu verhindern.

In der Praxis wird ein solches Setup vor dem produktiven Einsatz ausgiebig getestet, indem ein Knoten kontrolliert vom Netzwerk getrennt oder hart ausgeschaltet wird, während eine kontinuierliche Last auf die Datenbank läuft. Nur so lässt sich verifizieren, dass Fencing, Constraints und Ressourcen-Reihenfolge tatsächlich im erwarteten Zeitfenster greifen und keine Ressource in einem inkonsistenten Zwischenzustand hängen bleibt.

7. Quorum und das Zwei-Knoten-Problem

Quorum ist das Konzept, mit dem ein Cluster entscheidet, ob genügend Knoten erreichbar sind, um sicher weiterzuarbeiten. In einem klassischen Mehrheitsquorum benötigt ein Cluster mehr als die Hälfte aller konfigurierten Knoten, um Entscheidungen zu treffen. Bei genau zwei Knoten ist das strukturell problematisch: Fällt die Verbindung zwischen beiden aus, hat keiner der beiden eine Mehrheit, und ohne zusätzliche Maßnahme könnte keiner sicher entscheiden, ob er allein weiterarbeiten darf.

Für Zwei-Knoten-Cluster bietet Corosync die Option two_node: 1, die dieses Verhalten anpasst und in Kombination mit korrekt konfiguriertem Fencing trotzdem sicheren Betrieb ermöglicht, weil im Zweifel der jeweils andere Knoten per STONITH abgeschaltet wird, statt dass beide gleichzeitig aktiv bleiben. Für Cluster mit drei oder mehr Knoten ist ein echtes Mehrheitsquorum ohne solche Sonderregeln möglich und in der Regel die robustere Wahl, wenn die Infrastruktur dafür verfügbar ist.

8. Monitoring, Wartung und Troubleshooting

Der zentrale Befehl für den täglichen Umgang mit einem Pacemaker-Cluster ist pcs status, der eine vollständige Übersicht über Knoten, Ressourcen und deren aktuellen Zustand liefert. Bei Problemen zeigt pcs status --full zusätzlich fehlgeschlagene Operationen mit Zeitstempel, was meist der schnellste Weg ist, um die Ursache eines unerwarteten Failovers zu identifizieren.

Für geplante Wartungsarbeiten, etwa ein Kernel-Update, wird ein Knoten zunächst mit pcs node standby in den Standby-Modus versetzt, wodurch Pacemaker alle Ressourcen kontrolliert auf den verbleibenden Knoten verschiebt, bevor der Wartungsknoten neu gestartet wird. Dieser kontrollierte Übergang vermeidet einen ungeplanten Failover während der Wartung und lässt sich nach Abschluss mit pcs node unstandby rückgängig machen.

# Full cluster overview: nodes, resources, failed actions
sudo pcs status --full

# Put a node into maintenance before planned work (e.g. kernel update)
sudo pcs node standby node2

# Resume normal operation after maintenance
sudo pcs node unstandby node2

# Show detailed resource failure history
sudo pcs resource failcount show mysql_db

# Live-follow the Pacemaker/Corosync logs
sudo journalctl -u pacemaker -u corosync -f

9. Pacemaker im Vergleich zu einfacheren Lösungen

Für Teams, die bereits einen einfacheren HA-Mechanismus wie keepalived einsetzen, stellt sich früher oder später die Frage, wann der Umstieg auf Pacemaker sinnvoll wird. Die Entscheidung hängt fast ausschließlich davon ab, wie viele voneinander abhängige Ressourcen koordiniert werden müssen und wie kritisch korrekte Reihenfolge und Fencing für die Datenintegrität sind.

Wer nur eine IP-Adresse zwischen zwei Servern hochverfügbar machen will, fährt mit keepalived meist besser, weil es einfacher zu betreiben und zu debuggen ist. Sobald jedoch mehrere Ressourcen mit strikten Abhängigkeiten koordiniert werden müssen, etwa bei geteiltem Storage oder mehrstufigen Anwendungsdiensten, ist Pacemaker die einzig belastbare Lösung.

10. Zusammenfassung

Pacemaker und Corosync bilden gemeinsam den Standard-Cluster-Stack für Linux, wenn mehr als eine einzelne IP-Adresse hochverfügbar gemacht werden muss. Corosync übernimmt die zuverlässige Kommunikation zwischen Knoten, während Pacemaker beliebige Ressourcen wie Dateisysteme, Datenbank-Dienste und virtuelle IPs koordiniert startet, überwacht und im Fehlerfall verschiebt, gesteuert über Order- und Colocation-Constraints.

Fencing über STONITH ist keine optionale Erweiterung, sondern eine notwendige Voraussetzung für jeden produktiven Cluster, weil nur so verhindert wird, dass ein vermeintlich ausgefallener Knoten weiterhin auf geteiltes Storage schreibt. Bei genau zwei Knoten erfordert das Quorum-Verhalten besondere Aufmerksamkeit über die two_node-Option, während größere Cluster von echtem Mehrheitsquorum profitieren. Für einfache Ein-IP-Szenarien bleibt keepalived die pragmatischere Wahl, für koordinierte Multi-Ressourcen-Cluster ist Pacemaker jedoch das einzige belastbare Werkzeug.

11. FAQ: Pacemaker und Corosync Grundlagen