Geo-Redundante Virtualisierung mit Proxmox VE, Ceph und RBD-Mirror

oder wie man den Ausfall eines Datacenter überstehen kann

Carsten Feuls

2026-10-15

About me

• Carsten Feuls
• Jahrgang 89
• Linux User seit 2004
• Hobbys: Linux/OpenSource, Elektronik, Amateurfunk
• Seit (2015) 2016 bei der credativ GmbH

Was ist Ceph & RBD?

• Ceph: Ein hochskalierbares, verteiltes Storage-System (Object, Block, File).
• Kein Single Point of Failure: Daten werden über den CRUSH-Algorithmus intelligent und ohne zentralen Metadaten-Server verteilt.
• RBD (RADOS Block Device):
  • Stellt virtualisierte, verteilte Blockdevices (Festplatten) bereit.
  • Zerlegt große virtuelle Laufwerke nativ in kleinere 4 MB Datenobjekte.
  • Ideal für virtuelle Maschinen (VMs) und Container unter Proxmox VE.
• RBD-Mirror: Ein Dienst welcher virtuelle Blockdevices zwischen Clustern syncronisiert

• Ceph läuft direkt integriert in Proxmox (HCI).
• Wichtig zu verstehen: RBD schneidet virtuelle Platten in 4MB Slices. Diese Slices liegen verstreut im Cluster.
• Für DR müssen wir also diese 4MB Objekte (oder deren Änderungen) auf die andere Seite bekommen.

Warum überhaupt RBD-Mirror und kein großes Cluster?

• Latenz
• Proxmox: 1-2ms
• Ceph: < 0,5ms

Entfernung / Ziel	Normale Internetverbindung	Dark Fiber, direkter Weg
In Deutschland	5–20 ms	0,1–2 ms
Nachbarländer	5–40 ms	0,2–3 ms
Südeuropa (IT, ES)	20–60 ms	1–5 ms
USA	80–180 ms	60–130 ms

Replikationsmodi im Deep Dive

Ceph bietet zwei fundamental unterschiedliche Ansätze zur asynchronen Spiegelung:

A) Journal-basiertes Mirroring (journaling)

• Jedes Schreibereignis wird zuerst in ein sequenzielles Log (Journal) geschrieben, bevor es in das eigentliche Image wandert.
• Der Remote-Cluster liest das Journal kontinuierlich aus und spielt es lokal ein (“Replay”).
• Vorteil: Point-in-Time-Konsistenz (Crash-Consistent) nahezu in Echtzeit.
• Nachteil: Doppelte Schreiblast (Write Amplification) – Performance-Impact.

B) Snapshot-basiertes Mirroring (snapshot-based)

• Arbeitet zeitgesteuert (z.B. alle 10 Minuten) oder manuell.
• Berechnet Deltas zwischen zwei Snapshots über das fast-diff-Feature.
• Vorteil: Keine Write Amplification, ideal für WAN-Strecken mit höherer Latenz.
• Nachteil: Höheres RPO (Recovery Point Objective) abhängig vom Intervall.

• Journaling verdoppelt die IOPS-Last auf dem Quell-Storage! Das muss das System verkraften.
• Snapshot-basiert ist neuer (seit Ceph Octopus) und oft die Rettung bei schmalen Leitungen.
• Wichtig: LXC-Container-Disks in Proxmox unterstützen das Journal-Feature oft nicht gut; hier ist Snapshot-basiert meist Pflicht.

Vergleich: Journal vs. Snapshot

Kriterium	Journal-basiert (journaling)	Snapshot-basiert (snapshot-based)
RPO (Recovery Point Objective)	Extrem niedrig (Sekundenbereich)	Intervallabhängig (z.B. 5–15 Min.)
Performance-Impact	Hoch (doppeltes Schreiben)	Minimal (nur während Snapshot-Diff)
Netzwerkanforderung	Dauerhafter Stream	Höhere Bandbreite für periodische Bursts
Anwendungsfall	Kritische Datenbanken, VMs	Standard-VMs, LXC-Container

• Nutze diese Tabelle, um dem Kunden/Chef zu erklären, warum man nicht pauschal “Journaling” wählen sollte.
• Snapshot-basiert puffert Netzwerkausfälle besser ab als volllaufende Journale.

Mode wechseln via CLI

Bevor gespiegelt werden kann, muss der Pool-Modus definiert und das Feature aktiviert werden.

Aktivierung für Journal-basiertes Spiegeln:

# 1. Pool auf Image-Spiegelung vorbereiten
rbd mirror pool enable vm-storage-a pool [--site-name]

# 2. Journaling-Feature für das spezifische Image aktivieren
rbd feature enable vm-storage-a/vm-100-disk-0 journaling

Aktivierung für Snapshot-basiertes Spiegeln:

# 1. Pool auf Snapshot-Modus umstellen
rbd mirror pool enable vm-storage-a image [--site-name]

# 2. Image im Snapshot Modus versetzen
rbd mirror image enable vm-storage-a/$i snapshot;

# 3. Schedule hinzufügen (z.B. alle 10 Minuten ein Sync-Point)
rbd mirror snapshot schedule add 10m --pool vm-storage-a

• Zeige hier, dass Journaling tief im Image (rbd feature) verankert ist.
• Bei Snapshots hingegen steuert Ceph den Rhythmus global über den integrierten Manager (snapshot schedule).

Netzwerkarchitektur für rbd-mirror

Für eine stabile Spiegelung ist die Trennung der Datenströme entscheidend:

• Ceph Public: VM-Lese-/Schreibzugriffe innerhalb des Standorts.
• Ceph Cluster: OSD-Replikation und Heartbeats (Latenzkritisch!).
• RBD-Mirror Netz: Dedizierte Verbindung über Standorte hinweg.
• Routing über anderes Interface durch spezielle Route

• Niemals den RBD-Mirror-Traffic über das Ceph Cluster Netz jagen, wenn das WAN ein Nadelöhr ist.
• Wenn das WAN wegbricht, darf das nicht das lokale OSD-Heartbeat-Verhalten stören, sonst stürzt der lokale Cluster ab!

Cluster verbinden: Zwei-Wege-Sync (Bidirektional)

Das klassische Verfahren (Manuell via Keyrings)

# ceph.conf von Quell auf Zielcluster kopieren
scp /etc/ceph/ceph.conf <node>:/etc/pve/ceph/cluster-a.conf
ln -s /etc/pve/ceph/cluster-a.conf /etc/ceph/cluster-a.conf

# Auf Cluster A: Client anlegen und Key kopieren
ceph auth get-or-create client.rbd-mirror.cluster-b mon 'profile rbd' osd 'profile rbd'
# Auf Cluster B: Peer mühsam via Monitor-IPs hinzufügen
rbd mirror pool peer add vm-storage-a client.rbd-mirror.cluster-b@cluster-a

Cluster-Kopplung via Bootstrap-Token (Zwei-Wege)

Schritt 1: Token auf Cluster A erzeugen & auf Cluster B importieren

# Auf Cluster A (Site-A) ausführen:
rbd mirror pool peer bootstrap create --site-name cluster-a vm-storage-a > token-a

# Datei übertragen, dann auf Cluster B (Site-B) mit Richtung rx-tx importieren:
rbd mirror pool peer bootstrap import --site-name cluster-b --direction rx-tx vm-storage-a token-a

Schritt 2: Gegen-Token auf Cluster B erzeugen & auf Cluster A importieren

# Auf Cluster B (Site-B) ausführen:
rbd mirror pool peer bootstrap create --site-name cluster-b vm-storage-a > token-b

# Datei übertragen, dann auf Cluster A (Site-A) mit Richtung rx-tx importieren:
rbd mirror pool peer bootstrap import --site-name cluster-a --direction rx-tx vm-storage-a token-b

• rx-tx beschreiben, tx-only beschreiben

Das Proxmox VE “Dilemma”

• Wie Ceph RBD-Mirror agiert: Es spiegelt die “nackten” Festplatten-Inhalte (Block-Ebene) asynchron auf den zweiten Cluster.
• Wie Ceph NICHT agiert: Es weiß nichts von Proxmox-VM-Konfigurationen.

Das Problem:

• Die Konfiguration unter /etc/pve/nodes/<node>/qemu-server/<VMID>.conf fehlt.
• Firewall der VM sichern! /etc/pve/firewall/<VMID>.fw

Die Lösung: rsync / scp Automatisierung z.B. mit cronjob

Die Konfigurationsdateien müssen zusätzlich dateibasiert abgeglichen werden.

• Das ist der wichtigste Lerneffekt für Proxmox-Admins!
• Proxmox nutzt ein internes Cluster-Dateisystem (pmxcfs). Das spiegelt sich nur innerhalb eines Clusters, nicht standortübergreifend.
• Ohne die .conf Datei ist die gespiegelte virtuelle Festplatte wertlos, weil Proxmox nicht weiß, wie viel RAM/CPU die VM hatte.

Promote und Demote

Falls Cluster A noch kontrolliert heruntergefahren werden kann:

rbd mirror image demote vm-storage-a/vm-100-disk-0
# oder
rbd mirror pool demote vm-storage-a

Image auf Cluster B zum Primärimage befördern (Promote)

Jetzt aktivieren wir die Schreibrechte auf der DR-Seite:

rbd mirror image promote vm-storage-a/vm-100-disk-0
# oder
rbd mirror pool promote vm-storage-a

Falls Cluster A nicht mehr heruntergefahren werden kann:

rbd mirror image promote vm-storage-a/vm-100-disk-o --force
# oder
rbd mirror pool promote vm-storage-a --force

• Zeige in der Live-Demo genau diese Reihenfolge.
• Erkläre, dass ein Image immer nur auf einer Seite “primary” sein kann, um Datenkorruption (Split-Brain) zu verhindern.
• Wenn Cluster A komplett tot ist (kein Demote möglich), erzwingt man das Promote auf Cluster B mit dem Flag --force.

Mögliche Probleme:

• Anderer Pool-name in der VM-Konfiguration
• Netzwerk muss evtl. angepasst werden.
• Autostart von VMs/CT (VMs auf beiden Seiten aktiv)
• HA in Proxmox
• HA Rebalance

• Sobald die Datei in /etc/pve/node/<nodes>/qemu-server/ landet, triggert Proxmox den GUI-Inhalt per Inotify.
• Das sed-Kommando ist ein echter Lebensretter in heterogenen Umgebungen.
• Zusammenfassung: Daten spiegeln (Ceph) + Config spiegeln (rsync) + Promote = Erfolgreiches Disaster Recovery!

Monitoring & Überprüfung (Health Checks)

1. Globalen Pool-Spiegelstatus prüfen

rbd mirror pool status vm-storage-a --verbose

Sollte: health: OK sein und die Peers unter peers: korrekt gelistet sind.

2. Detaillierten Image-Sync-Status ausgeben

rbd mirror image status vm-storage-a/vm-100-disk-0

Soll-Zustand beim Journaling: status: Up+Replaying (Der Ziel-Cluster spielt Änderungen live ein).

• Zeige diese Befehle auf der Konsole, um den Zustand “VOR” und “NACH” dem Failover zu demonstrieren.
• Wenn dort Up+Stopped steht, bedeutet das meist, dass beide Seiten glauben, sie seien Primary (Split-Brain) oder der Keyring ist abgelaufen.

Überprüfung von Snapshot-basiertem Mirroring

1. Prüfen, ob automatische Snapshots generiert werden

rbd mirror snapshot schedule status --pool vm-storage-a

2. Lokale und Remote-Snapshots auf Block-Ebene auflisten

rbd snap ls vm-storage-a/vm-100-disk-0

• Erkläre, dass Ceph bei der Snapshot-Methode eigene interne “Hidden Snapshots” anlegt, um das fast-diff zu berechnen.
• Die Latenz (RPO) lässt sich hier einfach mathematisch prüfen: Letzter Sync-Zeitstempel minus Aktuelle Uhrzeit.

Häufige Fehler & Troubleshooting

• Fehler: Status: Down+Detached
  • Ursache: Der lokale rbd-mirror Daemon kann den entfernten Cluster nicht erreichen (Netzwerk- oder Firewall-Problem auf Port 6789/3300).
• Fehler: Status: Up+Error (split-brain detected)
  • Ursache: Beide Cluster beanspruchen die Rolle primary für sich.
  • Lösung: Das Image auf der Backup-Seite degradieren (demote) und das korrekte Image mittels resync neu erzwingen:

  rbd mirror image resync vm-storage-a/vm-100-disk-0

• Split-Brain ist das Horrorszenario. Passiert meist, wenn die WAN-Strecke wackelt und ein Admin voreilig auf der DR-Seite “Promote” drückt, während die VM auf Seite A noch lief.
• Der resync Befehl wirft alle Änderungen auf der sekundären Seite weg und baut die Replikation basierend auf der primären Seite komplett neu auf.

Monitoring:

• ceph mgr prometheus exporter
• Prometheus
• Alertmanager
• Grafana

Live-Demo: Aufzeichnung der Pool-Kopplung

• Ceph ist auf beiden Cluster bereits vorhanden und wird als Storage genutzt.
• Kopplung der Cluster & Aktivierung der Snapshot-Spiegelung für alle Images im Pool.

Figure 1

8. Ausblick: Active-Active Cross-Over Pool-Design

Um die Hardware an beiden Standorten produktiv auszulasten, trennt man die Pfade logisch in zwei Pools auf:

• Vorteil: VMs laufen aktiv an beiden Standorten. Replikation arbeitet kreuzweise.
• Proxmox Integration: Beide Pools werden auf allen Nodes in der /etc/pve/storage.cfg eingebunden. Der passive Pool verhält sich im Normalbetrieb Read-Only.

• Dieses Design ist das Ziel für Enterprise-Umgebungen. Keine Brachliegende Hardware an der DR-Site.
• Man koppelt die Paare gezielt mit dem Token-Flag --direction rx-only beim jeweiligen Empfänger-Pool, um unidirektionale Streams pro Pool-Paar abzusichern.

ENDE

Vielen Dank für die Aufmerksamkeit! Fragen?