# High Availability Deep Dive: Clustering mit Corosync & Pacemaker

TL;DR / Management Summary Hochverfügbarkeit (HA) ist kein Luxus, sondern eine Notwendigkeit für Business-Critical Services. In der Linux-Welt ist die Kombination aus Corosync (Kommunikation) und Pacemaker (Cluster Resource Manager) der Goldstandard. Sie sorgt dafür, dass Dienste (IPs, Datenbanken, Webserver) automatisch auf einen gesunden Node schwenken, wenn der primäre Node ausfällt. Wichtigster Punkt: Ein HA-Cluster ohne STONITH (Fencing) ist kein Cluster, sondern eine Gefahr für die Datenintegrität (Split-Brain).

# 1. Einführung & Architektur

Die Rollenverteilung im Cluster.

• Corosync: Der Funkspruch. Er stellt sicher, dass alle Nodes wissen, wer online ist (Membership & Quorum).
• Pacemaker: Der Dirigent. Er entscheidet, welcher Dienst auf welchem Node läuft.
• Resource Agents (RA): Die Skripte, die Pacemaker nutzt, um Dienste zu starten/stoppen (z.B. OCF Skripte).

graph TD
    subgraph "Node 1 (Primary)"
        A[Pacemaker CRM] --- B[Corosync]
        A --> C[VIP: 10.0.0.100]
        A --> D[Service: Nginx]
    end
    subgraph "Node 2 (Standby)"
        E[Pacemaker CRM] --- F[Corosync]
    end
    B <-->|Heartbeat / UDP 5405| F
    G[External Storage / Fencing] --- Node1
    G --- Node2

# 2. Grundkonfiguration

Ein 2-Node Cluster aufbauen.

# Pakete installieren

sudo apt update
sudo apt install pacemaker corosync pcs

# Passwort für den Cluster-User setzen

sudo passwd hacluster

# Cluster initialisieren (via pcs)

# Auf einem Node ausführen
sudo pcs cluster auth node1 node2 -u hacluster -p password
sudo pcs cluster setup --name my_cluster node1 node2
sudo pcs cluster start --all
sudo pcs cluster enable --all

# 3. Ressourcen-Management

Dienste hochverfügbar machen.

# Beispiel: Eine Virtual IP (VIP) erstellen

Dies ist die Adresse, über die Clients den Dienst erreichen.

sudo pcs resource create virtual_ip ocf:heartbeat:IPaddr2 \
    ip=192.168.1.100 cidr_netmask=24 op monitor interval=30s

# Ressourcen bündeln (Colocation)

Stellen Sie sicher, dass die IP und der Webserver immer auf dem gleichen Node laufen.

sudo pcs constraint colocation add nginx_service with virtual_ip score=INFINITY

# 4. STONITH (Fencing): Überlebenswichtig

Shoot The Other Node In The Head.

Wenn Node 1 nicht mehr antwortet, muss Node 2 sicherstellen, dass Node 1 wirklich “tot” ist, bevor er dessen IP übernimmt. Sonst schreiben beide gleichzeitig auf den Storage (Split-Brain -> Datenverlust!).

# Fencing-Methoden

• Proxmox: fence_pve (schaltet die VM via API aus).
• Bare Metal: IPMI, iLO, DRAC oder steuerbare PDU-Steckdosen.

# STONITH aktivieren (Beispiel IPMI)
sudo pcs stonith create my_fence fence_ipmilan ipaddr="10.0.0.50" login="admin" passwd="password"

# 5. Troubleshooting & “War Stories”

Wenn der Cluster Amok läuft.

# Story 1: “Der hängende Dienst”

Symptom: Pacemaker meldet “FAILED” für eine Ressource und versucht sie ständig neu zu starten, was die CPU-Last in die Höhe treibt. Ursache: Der Resource Agent kann den Dienst nicht stoppen (Timeout). Lösung: Bereinigen Sie den Status manuell: pcs resource cleanup <resource_name>. Prüfen Sie, warum der Dienst hängt (Logs!).

# Story 2: “Quorum-Verlust in 2-Node Clustern”

Symptom: Ein Node fällt aus, der zweite Node stoppt alle Dienste, obwohl er gesund ist. Ursache: Ein Cluster braucht die Mehrheit (>50%), um Entscheidungen zu treffen. Bei 2 Nodes führt der Ausfall von einem Node zu 50% -> Quorum weg. Lösung: Setzen Sie no-quorum-policy=ignore für 2-Node Cluster oder nutzen Sie einen QDevice (einen dritten Beobachter ohne Dienste).

# 6. Fazit & Empfehlung

• Design: Halten Sie den Cluster einfach. Zu viele Abhängigkeiten machen das System unvorhersehbar.
• Tests: Führen Sie regelmäßige Failover-Tests durch (pcs node standby <name>).
• Monitoring: Überwachen Sie den Cluster-Status mit dem pcs status Befehl und Prometheus Exportern.

# Anhang: Cheatsheet