# Proxmox Multi-Site HA: Geo-Clustering & Standortübergreifende Resilienz

TL;DR / Management Summary Ein lokaler HA-Cluster (Artikel 691) schützt vor dem Ausfall eines Servers, aber nicht vor dem Verlust eines ganzen Gebäudes. Multi-Site HA spannt den Proxmox-Cluster über geografisch getrennte Standorte. Ein Senior Admin meistert dabei die physikalischen Grenzen: Die Netzwerklatenz für Corosync (Heartbeat) muss unter 5ms bleiben, und die Daten müssen via ZFS Replication oder Stretch-Ceph an beiden Standorten synchron vorliegen.

# 1. Architektur-Modelle

Vom Campus zum Kontinent.

  1. Campus Cluster (Stretching): Zwei Gebäude auf dem gleichen Gelände, verbunden via Glasfaser.
    • Technik: Synchrone Replikation möglich (Ceph).
  2. Geo-Cluster: Zwei Standorte in verschiedenen Städten.
    • Technik: Asynchrone Replikation (ZFS Replication alle 1-15 Min).
  3. Separate Cluster (Federation): Keine HA-Automatik, manuelle Wiederherstellung via Backup (Artikel 694).

# 2. Die Latenz-Hürde (Corosync)

Die Lichtgeschwindigkeit bändigen.

Das größte Problem bei Multi-Site ist die Zeit, die ein Paket zwischen den Standorten braucht.

# 3. Deep Dive: Quorum am dritten Standort

Der Schiedsrichter.

In einem 2-Standort-Cluster (Host A in RZ1, Host B in RZ2) führt ein Kabelbruch dazu, dass beide Seiten denken, sie seien allein (Split-Brain).

# 4. Day-2 Operations: Schwenk-Szenarien (DR)

Den Ernstfall trainieren.

Wie sieht ein Schwenk von RZ1 nach RZ2 aus?

  1. Szenario: RZ1 ist komplett offline.
  2. Automatik: HA-Manager erkennt Ausfall. Da RZ2 das Quorum (via QDevice) hat, werden die VMs dort gestartet.
  3. Datenstand: Letzter erfolgreicher ZFS-Replication Stand (z.B. vor 5 Minuten).

# 5. Troubleshooting & “War Stories”

Wenn der Standort flappt.

# Top 3 Fehlerbilder

  1. Symptom: Ständiges Fencing aller Knoten bei schlechtem Wetter.

    • Ursache: Richtfunkstrecke zwischen Standorten hat Jitter bei Regen. Corosync-Pakete kommen zu spät an.
    • Lösung: Erhöhen Sie die token Timeouts in der corosync.conf.

  2. Symptom: Split-Brain bei manuellem Schwenk.

    • Lösung: Nutzen Sie immer das offizielle Tool pvecm, um die Quorum-Erwartung anzupassen, wenn ein Standort dauerhaft offline geht.

  3. Symptom: VMs booten am Standort B nicht.

    • Ursache: IP-Adress-Mismatch (VLANs am zweiten Standort nicht identisch).

# “War Story”: Der “Zombie” Cluster

Ein Unternehmen betrieb einen 2-Standort-Cluster ohne QDevice. Ein Bagger durchtrennte das Glasfaserkabel zwischen den Standorten. Das Ergebnis: Beide Standorte verloren das Quorum und froren sofort alle VMs ein (Fencing). Da keine Seite eine Mehrheit hatte, startete keine VM neu. Das Unternehmen war für 6 Stunden komplett offline, obwohl beide RZs technisch gesund waren. Lehre: Ein Multi-Site Cluster ohne dritten Vote-Knoten (QDevice) ist kein Hochverfügbarkeits-System, sondern eine Zeitbombe.

# 6. Monitoring & Reporting

Latenz-Statistiken.

# Corosync Monitor (Shell)

# Überwachung der Latenz zwischen den Knoten
corosync-cfgtool -s

# 7. Fazit & Empfehlung

Multi-Site HA ist die Königsklasse der Virtualisierung.

# Anhang: Cheatsheet (QDevice Setup)

Aufgabe Befehl
QDevice installieren apt install corosync-qnetd (am 3. Standort)
QDevice beitreten pvecm qdevice setup <IP-Adresse> (vom PVE Host)
Quorum Status pvecm status

# Referenzen