High-Availability mit Pacemaker/Corosync: Ressourcen‑Gruppen, STONITH und Split‑Brain‑Vermeidung

Wer produktive Services wirklich hochverfügbar betreiben will, setzt unter Linux oft auf High-Availability mit Pacemaker/Corosync. Pacemaker ist der Ressourcen-Manager, Corosync liefert Messaging, Mitgliedschaft und Quorum-Informationen. Dieser Leitfaden ergänzt die Grundlagen um tiefergehende Betriebsaspekte: konkrete STONITH‑Konfigurationen, SBD‑Einsatz, Corosync‑Tuning, Monitoring‑Integration, Prüfschritte für Fencing‑Tests sowie Rollback‑Strategien — alles mit Blick auf Betrieb, Datenintegrität und sichere Migrationen von prozessnahen Softwarelösungen.

Erweiterte Risiken: Wann Split‑Brain besonders wahrscheinlich ist

Split‑Brain entsteht, wenn zwei Partitionen des Clusters unabhängig Ressourcen aktivieren. Besonders gefährdet sind Setups mit Single‑Writer‑Storage (z. B. klassische LVM/LUNs ohne Cluster‑Dateisystem), instabilem Clusternetzwerk oder fehlendem/defektem Fencing. Netztrennungen bei gleichzeitigem Storage‑Timeout sind ein klassisches Szenario: Die eine Partition verliert Corosync‑Kommunikation, die andere sieht den LUN noch als zugänglich — beide können zum Primary werden.

SBD (STONITH Block Device): Wann es Sinn macht und wie man startet

SBD ist ein Fencing‑Mechanismus, der ein dediziertes Blockdevice als Token nutzt. Die Idee: Nur der Knoten, der das Token halten kann, darf Schreibzugriffe ausführen. SBD ist besonders praktisch, wenn ein externes SAN vorhanden ist oder ein kleines, rasch erreichbares Blockdevice (z. B. iSCSI LUN) für den Cluster bereitgestellt werden kann.

SBD‑Konfiguration: Beispiel /etc/sbd.conf

# Minimalbeispiel /etc/sbd.conf
SBD_DEVICE=/dev/sdb
SBD_WATCHDOG=yes
SBD_PACEMAKER=yes
SBD_TIMEOUT=120
SBD_STARTMODE=dual
SBD_OPTS="-p 30"

Erläuterung: SBD_DEVICE ist das gemeinsame Device; WATCHDOG nutzt einen Hardware‑Watchdog, PACEMAKER erlaubt Integration mit Pacemaker; TIMEOUT ist die Wartezeit bis zum Fencing. Startmode=dual erlaubt zwei Knoten, die SBD nutzen. Änderungen immer außerhalb der Geschäftszeiten testen.

SBD installieren und starten (Debian/Ubuntu, RHEL-Varianten ähnlich)

# Debian/Ubuntu
apt-get update && apt-get install -y sbd
# RHEL/CentOS
yum install -y sbd

# Starten und prüfen
systemctl enable --now sbd
journalctl -u sbd --no-pager --since "-5m"

Wichtig: SBD braucht ein zuverlässiges gemeinsames Device. Wenn das Device intermittierend wegfällt, erzeugt SBD Fehlfencing. Testen Sie Device‑Path‑Persistenz und Failover‑Pfad vor dem Produktivstart.

STONITH via BMC: IPMI / Redfish Beispiele und Stolperfallen

Power‑Fencing über BMC ist weit verbreitet, weil es einen echten Hardware‑Reset ermöglicht. Allerdings sind BMCs oft separat zu konfigurieren und stellen eigene Sicherheitsrisiken dar (Default‑Passwörter, unverschlüsselte Management‑Netze).

Beispiel: STONITH mit fence_ipmilan über pcs

# Beispiel: Gerät für „node1“ anlegen (Platzhalter verwenden!)
pcs stonith create fence-node1 fence_ipmilan 
  ipaddr=192.0.2.120 login=ADMIN passwd='SECRET' 
  pcmk_host_list=node1 op monitor interval=60s

# Prüfen
pcs stonith show

Hinweis: Verwenden Sie sichere Credentials, Zugangsbeschränkungen für das Managementnetz und rollenbasierte Zugriffe im BMC. Testen Sie das Power‑Cycle immer kontrolliert und dokumentiert.

Redfish: moderneres API

# Beispiel: fence_redfish mit Token (Platzhalter)
pcs stonith create fence-node1-redfish fence_redfish 
  ip=192.0.2.121 user=admin password='SECRET' 
  pcmk_host_list=node1 op monitor interval=60s

Redfish bietet klare APIs und bessere Audit‑Möglichkeiten. Trotzdem bleibt die Grundregel: BMC‑Zugriff nur über ein dediziertes Managementnetz, Credentials wechseln und Zugangslimits setzen.

Corosync‑Tuning: Parameter, die Stabilität bringen

Corosync kommuniziert über einen Ring; Verzögerungen oder Paketverluste führen zu wiederholten Membership‑Änderungen. Drei sinnvolle Stellschrauben:

• token: Zeit, die ein Knoten maximal auf seinen Turn wartet. Höheres Token reduziert Split‑Brain‑Empfindlichkeit bei Latenz, erhöht aber Failover‑Latenz.
• consensus: Anzahl an Nachrichten, die für Membership‑Änderungen erforderlich sind; erhöht die Sicherheit gegen flüchtige Paketverluste.
• join‑timeout / rrp_mode (bei mehreren Ringen): wie schnell Neuverbindungen erwartet werden.

Änderungen erfordern Tests im Testnetz. Kleine Token‑Erhöhungen sind oft besser als aggressive Ressourcen‑Timeouts.

Pacemaker Resource‑Meta und Failure‑Handling

Pacemaker bietet Meta‑Attribute wie migration‑threshold, failure‑timeout oder resource‑stickiness. Diese bestimmen, wie oft und wie schnell eine Ressource nach Fehlern migriert oder wieder versucht wird.

# Beispiel: Metaparameter setzen
pcs resource meta grp_app migration-threshold=3 failure-timeout=10m 
  resource-stickiness=100

Empfehlung: resource‑stickiness verhindert unnötige Back‑and‑Forth‑Moves. migration‑threshold limitiert die Anzahl automatischer Migrationsversuche, failure‑timeout definiert das Zeitfenster für Zählungen.

Monitoring und Alerting: End‑to‑End statt nur Clusterstatus

Cluster‑Metriken allein reichen nicht. Ergänzen Sie Prometheus‑Exporter (z. B. crm_exporter oder native pacemaker exporter) durch End‑to‑End‑Probes, die Service‑Funktionalität prüfen (HTTP‑Healthchecks, DB‑Write/Read). Alerts sollten klare Indikationen liefern: Fencing‑Fehler, wiederholte Failovers, long‑running recovery.

Fencing‑Tests: Sicher, reproduzierbar und auditorisch

Ein Fencing‑Test muss folgende Kriterien erfüllen: er ist kontrollierbar, reproduzierbar und dokumentiert. Vorgehen:

1. Maintenance‑Mode setzen (während Testumgebungen auch ohne aber mit klarer Freigabe)
2. Sicherung: pcs config export und Logs sichern
3. Simulierter Node‑Ausfall (z. B. Netzwerk disconnect) und Beobachtung, ob Fencing einsetzt
4. Überprüfung: Ist LUN/FS wirklich offline? Wurden Power‑Off/Reset Befehle am BMC ausgeführt?
5. Dokumentation aller Schritte und Zeitstempel

# Beispiel: Logs prüfen (Pacemaker, Corosync, SBD)
journalctl -u pacemaker -u corosync -u sbd --since "-30m" --no-pager
# Corosync Quorum Status
corosync-quorumtool -s

Vermeiden Sie Tests zur Hauptarbeitszeit. Wenn Fencing fehlschlägt, kann ein Power‑Off eine produktive VM hart beenden oder ein Storage‑Pfad unzugänglich machen.

Upgrade- und Migrationsstrategie für bestehende Cluster

Cluster‑Upgrades sind riskant, weil Änderungen am Messaging-Stack oder Resource‑Agents Verhalten verändern können. Empfehlenswerte Schritte:

• Rollback‑Plan und Konfigurationsbackup vor jedem Schritt
• Rolling Upgrade, sofern vom Distributor unterstützt: Knoten nacheinander upgraden, Clusterfunktion prüfen
• Testumgebung spiegeln: gleiche Storage‑Konfiguration und vergleichbare Netzwerkbedingungen
• Nach Upgrade: längere Beobachtungszeit, erhöhte Monitoring‑Sensitivität

Betriebscheckliste: Vor einem produktiven Go‑Live

• Dokumentation: Architekturdiagramm mit Failure Domains, Fencing‑Methoden und Wartungsfenstern
• End‑to‑End‑Checks: VIPs, NS/ARPs, Service‑Bind, DB‑Writes
• Fencing‑Test: mindestens einmal erfolgreich reproduziert und dokumentiert
• Monitoring: Alerts für Fencing, repeated failures, high failcounts
• Backups: Konfigurations‑Snapshot und Recovery‑Runbook verfügbar

Praxisbeispiele: Typische Stolperfallen und Gegenmaßnahmen

Stolperfalle: BMCs befinden sich im gleichen Management‑VLAN wie produktive Clients

Problem: Wenn das Produktionsnetz ausfällt, ist auch der BMC nicht erreichbar und Fencing schlägt fehl. Gegenmaßnahme: BMCs in ein separates Management‑Netz auslagern oder redundante Out‑of‑Band‑Zugänge vorsehen.

Stolperfalle: Falsche Monitor‑Intervalle

Problem: Zu aggressive Monitore in Zeiten hoher IO‑Latenz führen zu Flapping. Gegenmaßnahme: Monitor‑Intervalle an reale IO‑Bedingungen anpassen, resource‑stickiness erhöhen.

Fazit: Disziplinierte Infrastruktur statt Konfigurationsmagie

High‑Availability mit Pacemaker/Corosync funktioniert zuverlässig, wenn Architektur, Fencing und Quorum als integriertes System gestaltet werden. STONITH ist kein „Nice to have“, sondern bei Single‑Writer‑Setups und DRBD unverzichtbar. SBD bietet eine robuste Alternative, wenn ein gemeinsames Blockdevice zur Verfügung steht, während BMC‑Fencing echte Power‑Isolation liefert. Entscheidend ist: testen, dokumentieren, Monitoring integrieren und Rollback‑Pläne bereithalten. So wird Split‑Brain vermeidbar und der Betrieb planbar.

Erweiterte Ressourcen: Nützliche Prüfbefehle

# Quick‑Checks im Betrieb
pcs status --full
pcs stonith show
corosync-cfgtool -s
corosync-quorumtool -s
# Logs zusammenführen
journalctl -u pacemaker -u corosync -u sbd --since "-2h" --no-pager

FAQs

• Ist STONITH immer erforderlich? Bei Shared‑Storage‑Setups ohne Multi‑Writer‑Cluster‑FS und bei DRBD ist STONITH zwingend. Bei komplett verteilten Speichern mit eingebauter Konsistenz kann es in einigen Architekturen entfallen, aber die Entscheidung erfordert genaues Verständnis der Speicher‑Semantik.
• Wie teste ich SBD ohne Produktionsdaten zu riskieren? Nutzen Sie eine Test‑LUN mit identischer Pfadstruktur, simulieren Sie Node‑Ausfälle und prüfen Sie, ob Token‑Transfer und Fencing erwartbar funktionieren. Dokumentieren Sie Unterschiede zur Produktivumgebung.
• Was, wenn Fencing fehlschlägt? Sofort Maintenance‑Mode, Analyse der BMC/Storage‑Erreichbarkeit und Recovery‑Plan ausführen. In kritischen Situationen ist kontrollierter Single‑Node‑Betrieb oft sicherer als unsichere automatische Aktionen.

High-Availability mit Pacemaker/Corosync: qdevice, Ressourcen‑Constraints und Recovery‑Runbook

In Ergänzung zu STONITH und SBD lohnt sich ein Blick auf drei operative Bereiche, die oft übersehen werden aber massiv die Stabilität beeinflussen: der Einsatz eines externen Quorum‑Witness (qdevice/qnetd), saubere Ressourcen‑Constraints (Order/Colocation) und ein pragmatisches Recovery‑Runbook für echte Split‑Brain‑Fälle. Diese Aspekte betreffen Architektur, Automatisierung und die sichere Rückführung in den Normalbetrieb – relevant für den Betrieb prozessnaher Softwarelösungen mit geteiltem Storage oder VIP‑Failover.

qdevice (Quorum Witness) vs. SBD: Wann welches Pattern?

qdevice (auch qnetd genannt) bietet einen kleinen, externen Witness‑Dienst, der bei knappen Quorum‑Situationen Stimmen liefert. Vorteil: keine geteilten Blockdevices erforderlich, geringer Overhead, einfacher in Cloud‑/VM‑Setups. Nachteil: der Witness muss erreichbar und performant sein; bei Netzwerkpartitionen bringt er nur Vorteil, wenn er klar erreichbar bleibt.

SBD ist hardware‑ bzw. storagebasiert und schützt auf Block‑Device‑Ebene. Wählen Sie qdevice wenn Sie keine gemeinsamen LUNs bereitstellen können oder in virtualisierten Umgebungen mit externem kleinen Witness‑VM. Wählen Sie SBD für physische Umgebungen mit zuverlässigem SAN‑Path und wenn Sie Token‑basierte Fencing‑Garantie brauchen.

Praktische Hinweise zum qdevice‑Betrieb

• Witness‑Standort: möglichst in einem dritten Standort oder getrenntem Netzwerksegment, damit er bei einem Zwei‑Knoten‑Split die Entscheidung nicht verfälscht.
• Resilienz: Betreiben Sie qdevice in HA (zwei fertige Witness‑Instanzen mit Floating‑IP sind möglich) oder nutzen Sie einen Cloud‑Hosted witness, wenn Netzwerkverbindungen stabil sind.
• Monitoring: erfassen Sie liveness und RTT zum Witness; schwankende Latenzen können Membership‑Flapping verursachen.

Ressourcen‑Constraints: Reihenfolge und Kollokation richtig modellieren

Viele Failover‑Probleme entstehen, weil Dienste in der falschen Reihenfolge gestartet oder auf verschiedenen Knoten platziert werden. Nutzen Sie Order‑ und Colocation‑Constraints bewusst, um Abhängigkeiten zu erzwingen:

# Beispiel: sicherstellen, dass das Filesystem zuerst startet, dann die Applikation
pcs constraint order start fs_resource then app_resource
# Beispiel: Applikation muss auf dem selben Knoten wie das gemountete Filesystem laufen
pcs constraint colocation add app_resource with fs_resource INFINITY

Erklärung: Die Order‑Constraint verhindert Timing‑Probleme (z. B. App startet bevor das FS bereit ist). Die Colocation‑Constraint verhindert, dass die Applikation auf einem Knoten läuft, der keinen Zugriff aufs Storage hat.

Multipath und Device‑Persistenz

Abhängigkeiten von gemeinsamen Blockdevices erfordern stabile Device‑Namen. Verwenden Sie persistente WWIDs, setzen Sie multipathd sinnvoll ein und sichern Sie udev‑Regeln. Wenn Pfadwechsel oder Timeout‑Ereignisse den LUN kurzzeitig invisible machen, interpretiert der Cluster das schnell als Node‑Failure – mit potentiell falschem Fencing.

Recovery‑Runbook: sichere Schritte bei vermutetem Split‑Brain

Ein klares, getestetes Runbook verhindert übereilte Aktionen. Beispiel‑Ablauf, bevor Sie handeln:

1. Informieren Sie Stakeholder und setzen Sie ein Wartungsfenster. Aktivieren Sie gegebenenfalls ein globales Alarmlevel, damit automatische Skripte nicht zusätzlich handeln.
2. Sichern Sie Konfiguration und Logs: pcs config export > /root/pcs-config-$(date +%F).xml und sammeln Sie journalctl‑Ausgaben.
3. Isolieren Sie Knoten: stoppen Sie Pacemaker auf wenigstens einem Knoten, wenn Sie die Integrität eines Datenträgers prüfen wollen (systemctl stop pacemaker).
4. Ermitteln Sie den Datensatz mit der höchsten Autorität (z. B. welches Replica hatte zuletzt Schreibrechte, bei DRBD: Primary). Dokumentieren Sie Zeitstempel und IO‑Metriken.
5. Wenn ein autoritativer Knoten klar ist: replizieren Sie Daten (je nach Storage‑Technik), stellen Sie den anderen Knoten in einen sauberen Zustand und rejoinden Sie kontrolliert.
6. Nach Wiederherstellung: verlängerte Monitoring‑Phase, erhöhte Alarme und manuelle Abnahme der End‑to‑End‑Checks (VIP, DB‑Writes, Anwendungslogs).

Wichtig: Vermeiden Sie automatisches „force‑join“ ohne Datenkonsistenz‑Prüfung. Dokumentieren Sie jeden Schritt, damit eventuelle forensische Analysen möglich sind.

Automatisierung, Konfigurations‑Control und Teststrategie

Halten Sie Clusterkonfigurationen versioniert (Git) und automatisiert über geprüfte Playbooks. Testen Sie Fencing‑ und Quorum‑Szenarien automatisiert in CI/CD‑artigen Laboren (z. B. Vagrant/VM‑basierte Staging). Nur geprüfte, repeatable Playbooks dürfen in Produktion Änderungen an Pacemaker/Corosync ausführen.

Diese Ergänzungen helfen, Architektur‑ und Betriebsrisiken zu reduzieren: Ein passender Witness, klare Constraints und ein getestetes Recovery‑Runbook machen den Unterschied zwischen gelegentlichen Failovers und planbarem, auditfähigem Betrieb.

Für dieses Thema sind auch Pacemaker Cluster und Stonith Fencing wichtig. Der Beitrag ordnet diese Aspekte verständlich ein und zeigt, worauf es im Alltag ankommt.