DRBD und Pacemaker: Zwei-Knoten-HA mit Rocky Linux 9 und STONITH

EdwardMoon

DRBD repliziert die Blockgeräte zweier Server; Pacemaker und Corosync bestimmen, welcher Knoten Primary ist und Dateisystem, virtuelle IP sowie Dienst betreibt. Beide Knoten manuell zum Primary zu machen oder XFS gleichzeitig zu mounten, kann Daten beschädigen. Deshalb Active-Passive-Betrieb und einen zuverlässig erzwungenen einzelnen Schreibknoten vorsehen.

Das frühere CentOS-7.9-Beispiel darf wegen des Supportendes, veralteter Master/Slave-Begriffe und fehlendem Fencing nicht unverändert für neue Produktionssysteme verwendet werden. Dieser Leitfaden erklärt Architektur und Prüfablauf anhand von Rocky Linux 9, DRBD 9 und dem heutigen Promoted/Unpromoted-Modell von Pacemaker. Paketversionen und unterstützte Kombinationen in den Distributions- und LINBIT-Vertragsunterlagen erneut prüfen.

DRBD-Pacemaker-HA mit zwei Knoten: einzelner Primary, Blockreplikation, Quorum-Zeuge und STONITH — Active-Passive-Struktur mit nur einem gemounteten Dateisystem sowie getrennten Replikations-, Quorum- und STONITH-Pfaden gegen Split Brain

Architektur und Ausfallgrenzen

Schicht	Aufgabe	Schutz bei Ausfällen
DRBD 9	Synchrone Blockreplikation	Protocol C, einzelner Primary und Prüfung des Replikationszustands
Corosync	Knotenmitgliedschaft, Nachrichtenübertragung und Quorum	Eigenes oder redundantes Netzwerk; qdevice prüfen
Pacemaker	Ressourcenplatzierung, Reihenfolge und Wiederherstellung	Promoted-Rolle sowie Colocation- und Order-Bedingungen
STONITH	Stromversorgung oder Zugriff eines nicht isolierbaren Knotens sperren	Unabhängiges Verwaltungsnetz und tatsächlicher Fencing-Test
Filesystem	XFS mit einem Schreibknoten auf DRBD	Nur auf dem Promoted-Knoten mounten
VIP und Dienst	Clientzugang und Anwendung	Nach dem Dateisystem starten und in umgekehrter Reihenfolge stoppen
Backup	Wiederherstellung nach Löschung, Beschädigung oder Ransomware	Von DRBD unabhängige versionierte Sicherungen und Wiederherstellungstests

STONITH in einer produktiven Pacemaker-Konfiguration zu deaktivieren, ist unsicher. Lässt sich der Stillstand eines nicht erreichbaren Knotens nicht nachweisen, können beide Knoten denselben Datenbestand für sich beanspruchen. Fencing deshalb vor dem Start der Ressourcen konfigurieren und testen.

Voraussetzungen für den Aufbau

Kompatible Versionen von Betriebssystem, DRBD-Kernelmodul und -Werkzeugen, Pacemaker, Corosync, pcs und Ressourcen-Agenten auf beiden Knoten festlegen.
Vorwärts- und Rückwärtsauflösung der Hostnamen sowie NTP-Synchronisierung prüfen.
Ausfalldomänen von Replikations-, Corosync-, Dienst- und BMC-/Fencing-Verwaltungsnetz möglichst trennen.
Größe und Sektorinformationen beider zugrunde liegenden Geräte prüfen und vorhandene Dateisystem- oder LVM-Signaturen auf den Partitionen ausschließen.
Passenden Fence-Agent, BMC-Konto und qdevice beziehungsweise eine dritte Entscheidungsstelle vorbereiten.
RPO, RTO und manuelle Wiederherstellung bei Datenbeschädigung, Split Brain oder Standortausfall dokumentieren.

Knoten und Speicher vorab prüfen

hostnamectl --static
timedatectl status
chronyc tracking
getent hosts ha1.example.com ha2.example.com

lsblk -o NAME,SIZE,TYPE,FSTYPE,MOUNTPOINTS,MODEL,SERIAL
sudo blkid /dev/vdb1
sudo wipefs --no-act /dev/vdb1

Das Beispiel verwendet /dev/vdb1. In der tatsächlichen Umgebung WWID, Multipath- und LVM-Schichten eindeutig identifizieren. Die Stabilität der Gerätezuordnung über Neustarts prüfen und bei vorhandenen Signaturen abbrechen. wipefs –no-act liest nur Informationen; tatsächliches Löschen wird hier nicht automatisiert.

Pakete und Ressourcen-Agent prüfen

sudo dnf repolist
sudo dnf --showduplicates list   drbd-utils kmod-drbd pacemaker corosync pcs resource-agents fence-agents-all

rpm -q drbd-utils pacemaker corosync pcs resource-agents
modinfo drbd | head
drbdadm --version
pcs --version

pcs resource standards
pcs resource providers ocf
pcs resource agents ocf:linbit

DRBD-Paketnamen und die Bereitstellung von kmod unterscheiden sich zwischen Repositories. RHEL-Kompatibilität, Secure-Boot-Signierung, Kernel-Update-Richtlinie und Supportzuständigkeit prüfen und ausschließlich geprüfte Paketquellen verwenden. Ressourcen erst erstellen, wenn ocf:linbit:drbd tatsächlich installiert ist.

DRBD-Replikationsressource konfigurieren

DRBD Protocol C bestätigt den Abschluss nach bestätigtem Schreiben auf den entfernten Datenträger und eignet sich für synchrone Replikation. Es garantiert aber nicht automatisch korrektes fsync-Verhalten der Anwendung oder geeignete Speichercache-Richtlinien. Datenpfade beider Knoten und Schreibpersistenz bei Stromausfall gesondert testen.

Gemeinsames DRBD-Geheimnis erzeugen

umask 077
openssl rand -base64 32

# Ausgabe in einem freigegebenen Secret Store aufbewahren
# Identisch in der DRBD-Konfiguration beider Knoten hinterlegen.

Beispiel für /etc/drbd.d/r0.res

resource r0 {
  protocol C;
  device /dev/drbd0;
  disk /dev/vdb1;
  meta-disk internal;

  net {
    cram-hmac-alg sha256;
    shared-secret "REPLACE_WITH_GENERATED_SECRET";
  }

  on ha1.example.com {
    node-id 0;
    address ipv4 10.10.10.11:7789;
  }

  on ha2.example.com {
    node-id 1;
    address ipv4 10.10.10.12:7789;
  }
}

Die Konfigurationsdatei mit Modus 0600 auf root beschränken und Geheimnisse in der Konfigurationsverwaltung nicht im Klartext protokollieren. Erst fortfahren, wenn REPLACE durch das tatsächliche Geheimnis ersetzt wurde. TCP 7789 nur von der Replikationsgegenstelle zulassen; SELinux und firewalld aktiv lassen.

Metadaten erstellen und Gerät starten

sudo chown root:root /etc/drbd.d/r0.res
sudo chmod 0600 /etc/drbd.d/r0.res
sudo drbdadm dump r0
sudo drbdadm create-md r0
sudo drbdadm up r0

sudo drbdadm status r0 --verbose
sudo cat /proc/drbd

create-md schreibt DRBD-Metadaten auf das zugrunde liegende Gerät. Geräteauswahl und Sicherung nochmals prüfen, dann auf beiden Knoten ausführen. Die Umwandlung eines Volumes mit vorhandenen Daten erfordert ein eigenes Migrationsverfahren.

Erste Synchronisierung und Dateisystemerstellung

# Nur für neue leere Volumes im freigegebenen Änderungsfenster ausschließlich auf ha1 ausführen
sudo drbdadm primary --force r0
watch -n 2 sudo drbdadm status r0

# Neues XFS erst erstellen, wenn beide Peers UpToDate melden
sudo mkfs.xfs -L ha_data /dev/drbd0
sudo mkdir -p /srv/ha-data
sudo mount /dev/drbd0 /srv/ha-data
sudo touch /srv/ha-data/cluster-marker
sudo umount /srv/ha-data
sudo drbdadm secondary r0

mkfs.xfs zerstört vorhandene Inhalte. Nicht auf wiederverwendeten Volumes oder bei erhaltenswerten Daten auf einer Seite ausführen. Werden bei der ersten Synchronisierung Quelle und Ziel vertauscht, können gültige Daten durch leere Blöcke überschrieben werden. Neue leere Geräte bestätigen und auf UpToDate/UpToDate warten.

Pacemaker-Cluster und STONITH

pcs-Authentifizierung und Corosync-Cluster erstellen

# hacluster-Passwort auf beiden Knoten interaktiv setzen
sudo passwd hacluster

# Auf einem Knoten ausführen und Passwort am Prompt eingeben
sudo pcs host auth ha1.example.com ha2.example.com -u hacluster
sudo pcs cluster setup ha-drbd ha1.example.com ha2.example.com --start
sudo pcs cluster enable --all

sudo pcs cluster status
sudo pcs quorum status
sudo corosync-cfgtool -s

Bei einer Kommunikationsunterbrechung können zwei Knoten nicht zuverlässig gegenseitig bestimmen, welche Seite noch aktiv ist. Corosync qdevice als dritte Stimme prüfen; auch qdevice ersetzt STONITH nicht. Bei DRBD-internem Quorum oder einem Diskless Tiebreaker Pacemaker-Fencing und DRBD-Fencing auf Ressourcenebene nicht ungeprüft kombinieren. Ein zusammenhängendes, durch die Supportdokumentation gedecktes Design wählen.

Fence-Agent auswählen und tatsächlich testen

sudo pcs stonith list
sudo pcs stonith describe fence_ipmilan
sudo pcs stonith config
sudo pcs property config --all

# Mit passendem BMC-, PDU- oder Cloud-Fence-Agent und Geräteparametern erstellen und prüfen
sudo pcs stonith config --full
sudo pcs stonith status

fence_ipmilan ist nur ein Beispiel. Einen zur Hardware oder Plattform passenden Fence-Agent, pcmk_host_map, unabhängige Verwaltungsadressen und ein Konto mit minimalen Rechten verwenden. Passwörter nicht im Befehlsverlauf hinterlassen, sondern über einen vom Agent unterstützten sicheren Mechanismus übergeben.

# Im Wartungsfenster erst nach doppelter Prüfung von Dienstauswirkungen und Zielknoten ausführen
sudo pcs stonith fence ha2.example.com

sudo pcs status --full
sudo journalctl -u pacemaker -u corosync --since '-10 min'

Bei einem Fencing-Test muss eine verantwortliche Person prüfen, dass der Zielknoten tatsächlich ausgeschaltet oder sein Speicherzugriff gesperrt wurde. Eine Erfolgsmeldung allein genügt nicht. Bei fehlgeschlagenem STONITH keine Datenressourcen starten.

Im neuen leeren Cluster verhindert der Wartungsmodus automatische Starts während der folgenden Ressourcen- und Bedingungserstellung. In einem bereits produktiven Cluster betrifft er den Verwaltungszustand sämtlicher Ressourcen; die Übungsbefehle dort nicht unverändert ausführen.

sudo pcs property set maintenance-mode=true
sudo pcs property config

Promotable-Ressource für DRBD

DRBD-Agent und Promoted-Rolle

sudo pcs resource create drbd_r0 ocf:linbit:drbd   drbd_resource=r0   op monitor interval=15s role=Promoted   op monitor interval=30s role=Unpromoted

sudo pcs resource promotable drbd_r0   promoted-max=1 promoted-node-max=1   clone-max=2 clone-node-max=1   notify=true

sudo pcs resource config drbd_r0
sudo pcs status --full

Aktuelle Pacemaker-Versionen verwenden Promoted und Unpromoted anstelle von Master und Slave. promoted-max=1 begrenzt die Zahl gleichzeitiger Primaries auf einen. Die von der verwendeten pcs-Version erzeugten Ressourcen- und Clone-Namen prüfen und in den folgenden Bedingungen exakt verwenden.

Gruppe aus Dateisystem, VIP und Dienst

sudo pcs resource create fs_data ocf:heartbeat:Filesystem   device=/dev/drbd0 directory=/srv/ha-data fstype=xfs   op monitor interval=20s timeout=40s

sudo pcs resource create vip_app ocf:heartbeat:IPaddr2   ip=192.0.2.50 cidr_netmask=24   op monitor interval=20s

sudo pcs resource create app_service systemd:myapp   op monitor interval=20s timeout=40s

sudo pcs resource group add app_group fs_data vip_app app_service

Auf beiden Knoten die systemd-Aktivierung von myapp so regeln, dass der Dienst außerhalb des Clusters nicht automatisch startet. IP-Adresse, Schnittstelle, Filesystem-Agent-Optionen und Dienst-Timeout anpassen. XFS wird als Dateisystem mit einem Schreibknoten nur auf einem Knoten gemountet; dieses Beispiel nicht auf Dual-Primary erweitern.

Order- und Colocation-Bedingungen

# Tatsächlich erzeugten Promotable-Clone-Namen mit pcs status/config prüfen und verwenden
sudo pcs constraint order   promote drbd_r0-clone then start app_group

sudo pcs constraint colocation add   app_group with promoted drbd_r0-clone INFINITY

sudo pcs constraint config --full
sudo pcs status --full

order startet die Gruppe erst nach der Promotion von DRBD. colocation platziert sie auf diesem Promoted-Knoten. Innerhalb der Gruppe gilt beim Start Dateisystem → VIP → Dienst, beim Stoppen die umgekehrte Reihenfolge. Bedingungsnamen und Rollensyntax anhand der Hilfe der installierten pcs-Version und der erzeugten CIB prüfen.

Zustand und Daten prüfen

Nach vollständiger Prüfung von Ressourcen, Reihenfolge, Colocation und Fencing den Wartungsmodus des neuen Übungsclusters beenden und den Beginn der Ressourcenverwaltung prüfen.

sudo pcs constraint config --full
sudo pcs stonith status
sudo pcs property set maintenance-mode=false
sudo pcs status --full

Normalzustand prüfen

sudo pcs status --full
sudo crm_mon -1Arf
sudo pcs resource config
sudo pcs constraint config --full
sudo drbdadm status r0 --verbose

findmnt /srv/ha-data
ip -brief address | grep '192.0.2.50'
curl --fail --silent --show-error http://192.0.2.50/healthz

Prüfung	Sollzustand	Bei Abweichung zuerst prüfen
DRBD role	Ein Knoten Promoted/Primary, der andere Unpromoted/Secondary	Spuren manueller Promotion, Bedingungen und Agent-Logs
disk state	Beide Seiten UpToDate	Replikationsnetz, zugrunde liegende Geräte und Resynchronisierungsfortschritt
Filesystem	Nur auf dem Promoted-Knoten gemountet	Colocation, Order und automatische systemd-Mounts
STONITH	Beide Knoten können den Peer tatsächlich isolieren	BMC-Stromversorgung, Rechte, Verwaltungsnetz und Agent-Timeout
quorum	Erwartete Stimmen und ordnungsgemäßer qdevice-Zustand	Corosync-Link, wait_for_all und dritte Stimme
Dienst	VIP und Health-Endpunkt antworten	Bereitschaft des Dateisystems, Anwendungslogs und Firewall

Failover testen

Zuerst über einen geordneten Standby-Wechsel Ressourcenbedingungen und Anwendung prüfen. Anschließend nach freigegebenem Testplan Ausfall des Dienstprozesses, Knotenabschaltung, Corosync-Linkunterbrechung, Replikationsnetzunterbrechung und BMC-Ausfall jeweils getrennt testen.

sudo pcs node standby ha1.example.com
watch -n 2 sudo pcs status --full

curl --fail --silent --show-error http://192.0.2.50/healthz
ssh ha2.example.com 'findmnt /srv/ha-data; sudo drbdadm status r0'

sudo pcs node unstandby ha1.example.com
sudo pcs status --full

Sobald Pacemaker die Ressourcen verwaltet, ihren Zustand nicht mehr manuell mit drbdadm primary, mount oder systemctl start verändern. Solche Eingriffe lassen CIB-Sollzustand und tatsächlichen Zustand auseinanderlaufen. Wartungen über Standby- oder Wartungsmodus-Verfahren durchführen und danach den Verwaltungszustand aller Ressourcen prüfen.

Auf Split Brain reagieren

Dienst und automatische Wiederherstellung stoppen und die Knoten so physisch isolieren, dass sie nicht gleichzeitig schreiben können.
DRBD-Rollen und Datenträgerzustände, Pacemaker-, Corosync- und Fencing-Logs sowie den Zeitpunkt der letzten gültigen Sicherung aufbewahren.
Gemeinsam mit den Anwendungsverantwortlichen anhand der Transaktionen den maßgeblichen Datenbestand bestimmen.
Im Vier-Augen-Prinzip prüfen, dass nach dem offiziellen LINBIT-Verfahren nur auf dem ausgewählten unterlegenen Knoten Daten verworfen werden.
Nach der Resynchronisierung Dateisystem, Datenkonsistenz, Dienstfunktionen und Sicherung prüfen.
Grundursache in Replikationsnetz, Quorum, STONITH oder Bedingungen beheben und denselben Ausfalltest wiederholen.

Der Befehl discard-my-data zur Split-Brain-Wiederherstellung kann den gesamten Datenbestand einer Seite verwerfen. Deshalb enthält dieser Artikel dafür kein kopierbares Ausführungsbeispiel. Ohne Bestimmung der maßgeblichen Kopie und Sicherung nicht fortfahren; die offizielle Dokumentation der eingesetzten DRBD-9-Version und das Supportverfahren befolgen.

Befehle zur Sicherung von Diagnosedaten

sudo drbdadm status r0 --verbose
sudo drbdsetup status --statistics
sudo pcs status --full
sudo crm_mon -1Arf
sudo corosync-cfgtool -s
sudo pcs quorum status

sudo journalctl -u drbd -u pacemaker -u corosync   --since '-30 min' --no-pager

Checkliste für den Betrieb

Das CentOS-7-Beispiel wurde durch eine festgelegte unterstützte Kombination aus Betriebssystem, DRBD und Pacemaker ersetzt.
Zugrunde liegende Geräte wurden anhand Seriennummer oder WWID geprüft und vor destruktiver Initialisierung doppelt kontrolliert.
Ausfalldomänen von Replikationsnetz, Corosync, Dienstnetz und BMC-Fencing-Netz sind getrennt.
STONITH wurde tatsächlich getestet; stonith-enabled bleibt aktiv.
DRBD verwendet promoted-max=1; XFS ist ausschließlich auf dem Promoted-Knoten gemountet.
Order- und Colocation-Bedingungen der Dateisystem-, VIP- und Dienstgruppe sind geprüft.
Erwartete Ergebnisse und RTO für Standby, Knotenabschaltung, Linkunterbrechung und Fencing-Ausfall sind dokumentiert.
Unabhängige versionierte Sicherungen wurden erstellt und in einer isolierten Umgebung wiederhergestellt.

Offizielle Dokumentation und weiterführende Artikel

Zusammenfassung

Zwei-Knoten-HA muss sicherstellen, dass nach zuverlässiger Isolation des bisherigen Eigentümers nur eine Stelle die korrekten Daten beschreibt. Protocol C, eine einzelne Promoted-Rolle, tatsächlich funktionierendes STONITH, Quorum-Entscheidungen und die Bedingungen für Dateisystem, VIP und Dienst gemeinsam prüfen. Replikation ersetzt keine Sicherung; erst Ausfalltests und unabhängige Wiederherstellungstests vervollständigen eine betreibbare HA-Konfiguration.