Pacemaker & Corosync auf Debian: HA-Cluster ohne Voodoo, aber mit Zaun

Pacemaker ohne Fencing ist wie RAID ohne Backup: klingt beruhigend, bis es nachts um 03:17 Uhr sehr laut knallt. Wir haben uns einen kleinen Debian-Cluster gebaut und die üblichen Stolperdrähte gleich mit eingesammelt.

Setup: Zwei Nodes, ein Ziel

Unser Test besteht aus zwei Debian-Servern:

- node1 mit 10.0.0.11

- node2 mit 10.0.0.12

- virtuelle Cluster-IP: 10.0.0.100

Erstmal Pakete drauf. Auf beiden Nodes:

apt update
apt install -y pacemaker corosync pcs resource-agents fence-agents
systemctl enable --now pcsd

Der hacluster-User braucht ein Passwort, sonst spricht pcs nicht mit uns:

passwd hacluster

Hostnamen müssen sauber auflösbar sein. Kein DNS? Dann eben oldschool:

# /etc/hosts
10.0.0.11 node1
10.0.0.12 node2

Cluster initialisieren

Auf node1 authentifizieren wir beide Nodes:

pcs host auth node1 node2 -u hacluster

Dann Cluster anlegen und starten:

pcs cluster setup plutex-ha node1 node2
pcs cluster start --all
pcs cluster enable --all

Statuscheck:

pcs status

Wenn hier schon rote Zeilen stehen: nicht ignorieren. Pacemaker merkt sich schlechte Laune.

Corosync: Quorum im Zwei-Node-Cluster

Bei zwei Nodes ist Quorum immer speziell. Fällt einer weg, steht der andere mathematisch dumm da. Für genau diesen Fall gibt es two_node: 1.

Prüfe auf beiden Nodes die Corosync-Konfiguration:

# /etc/corosync/corosync.conf
totem {
    version: 2
    cluster_name: plutex-ha
    transport: knet
}

nodelist {
    node {
        name: node1
        nodeid: 1
        ring0_addr: node1
    }

    node {
        name: node2
        nodeid: 2
        ring0_addr: node2
    }
}

quorum {
    provider: corosync_votequorum
    two_node: 1
}

logging {
    to_syslog: yes
}

Nach Änderungen:

systemctl restart corosync pacemaker

Ressourcen definieren: Floating IP und Dienst

Als simples Beispiel nehmen wir eine virtuelle IP. Die wandert zwischen den Nodes.

pcs resource create vip ocf:heartbeat:IPaddr2 ip=10.0.0.100 cidr_netmask=24 op monitor interval=30s

Dazu ein Dienst, zum Beispiel nginx:

apt install -y nginx
pcs resource create web systemd:nginx op monitor interval=30s

Damit IP und Webserver zusammenbleiben:

pcs constraint colocation add web with vip INFINITY
pcs constraint order start vip then web

Jetzt kannst du den Spaß testen:

pcs status
pcs node standby node1
pcs status
pcs node unstandby node1

Wenn die IP sauber auf node2 wandert: gut. Wenn nicht: Logs lesen, nicht Kaffeesatz.

journalctl -u pacemaker -u corosync -f

Fencing: Der Zaun ist kein Deko-Feature

Fencing bedeutet: Ein kaputter Node wird hart aus dem Spiel genommen. Strom aus, VM resetten, IPMI treten. Warum? Weil zwei Nodes, die beide glauben, sie seien aktiv, deine Daten schneller grillen als ein Azubi rm -rf tippen kann.

Pacemaker erwartet Fencing standardmäßig:

pcs property set stonith-enabled=true

Ein Beispiel mit IPMI:

pcs stonith create fence-node1 fence_ipmilan \
    pcmk_host_list=node1 \
    ipaddr=10.0.1.11 \
    login=admin \
    passwd='supergeheim' \
    lanplus=1 \
    op monitor interval=60s

Für node2 entsprechend nochmal. In echten Setups: Zugangsdaten absichern, dediziertes Management-Netz nutzen, Fencing testen.

Kurzzeitig im Lab kannst du STONITH deaktivieren:

pcs property set stonith-enabled=false

Aber Produktion ohne Fencing? Nein. Einfach nein.

Typische Fallstricke

Hostname-Auflösung muss identisch sein. node1 darf nicht auf dem einen Host 127.0.1.1 sein und auf dem anderen irgendwas Kreatives.

Zeit muss stimmen. Installiere NTP oder Chrony:

apt install -y chrony
systemctl enable --now chrony

Firewall nicht vergessen. Corosync braucht Kommunikation zwischen den Nodes, pcsd nutzt Port 2224/tcp. Wenn UDP-Pakete gefiltert werden, sieht Pacemaker Geister.

Und zuletzt: Ressourcen nicht manuell starten. Wenn Pacemaker nginx verwaltet, dann finger weg von systemctl start nginx. Der Cluster ist der Chef. Du bist nur der Mensch mit Shell-Zugang.