VMs zwischen Nodes synchron halten – Grundlage für HA ohne Shared Storage
Was ist Replikation?
Basiert auf ZFS send/receive, automatisiert und geplant über den Dienst pvesr (Proxmox VE Storage Replication) – kein manuelles Hantieren mit zfs send/zfs receive nötig
Kopiert VM- und LXC-Container-Daten in festen Intervallen von einem Node auf einen zweiten
Nur Deltas werden übertragen, nicht jedes Mal die komplette VM – wurden seit dem letzten Lauf z. B. nur 800 MB geändert, wandern auch nur diese 800 MB, nicht die komplette 100-GB-Disk erneut
Voraussetzung: beide Nodes brauchen ZFS-Storage mit identischem Storage-Namen im Cluster – Replikation funktioniert ausschließlich auf ZFS, nicht auf LVM-thin, ext4 oder NFS
Jeder Lauf legt intern ein Snapshot-Paar an, aus dessen Differenz das Delta berechnet wird; ältere Snapshots räumt pvesr automatisch auf
Replikation ersetzt kein Backup: Sie hält nur die beteiligten Nodes synchron. Ein versehentlich gelöschtes File oder eine fehlerhafte Anwendungsänderung wird ebenso zuverlässig repliziert wie ein korrekter Datensatz.
🎧 Block 1: Was ist Replikation, Intervalle
Einrichtung in der Praxis
GUIDatacenter → Replication → Add: VM auswählen, Ziel-Node, Zeitplan und optional ein Bandbreitenlimit festlegen
CLIpvesr create-local-job – dieselbe Konfiguration per Kommandozeile, praktisch für Skripte und Automatisierung
Beispiel: pvesr create-local-job 100-0 pve2 --schedule '*/15' --rate 50 repliziert VM 100 alle 15 Minuten auf Node pve2, gedeckelt auf 50 MB/s
Status prüfen mit pvesr status – zeigt je Job letzten Lauf, nächsten Lauf, Dauer und Fehlerzähler
Konfiguration liegt clusterweit synchron in /etc/pve/replication.cfg – wie alle Dateien unter /etc/pve sofort auf allen Nodes sichtbar
Migration einer VM zwischen ihren beiden Replikationspartnern nutzt den bereits synchronen Stand: Es muss nur noch das letzte Delta übertragen werden – spürbar schneller als eine „kalte" Migration auf einen fremden Node ohne bestehende Replikationsbeziehung.
Intervalle
Minimal ein Minuten-Intervall möglich, Zeitplan über systemd-Calendar-Syntax (z. B. */5 für alle 5 Minuten, stündlich oder täglich)
Kürzeres Intervall bedeutet kleineres RPO – ein 1-Minuten-Takt begrenzt den maximalen Datenverlust im Ernstfall auf rund eine Minute
Aber: mehr Last – jeder Lauf legt Snapshots an und beansprucht kurzzeitig CPU und I/O auf Quelle wie Ziel; bei VMs mit hoher Schreibrate summiert sich das spürbar
Für ruhige VMs (wenig Schreiblast, z. B. interne Dokuserver) reichen oft 15- oder 30-Minuten-Intervalle, für kritische Systeme wie Datenbank oder ERP eher 1–5 Minuten
Faustregel: nicht „so kurz wie möglich", sondern „so kurz wie nötig" – das gewünschte RPO bestimmt das Intervall, nicht die technische Untergrenze.
RPO-Berechnung
Maximaler Datenverlust ≈ Zeit seit der letzten erfolgreichen Replikation
Delta ÷ Netzdurchsatz = Übertragungsdauer
Die Übertragungsdauer muss ins gewählte Intervall passen, sonst läuft die Replikation der VM hinterher und die Läufe stapeln sich
Beispiel: 5 GB Delta über ein 1-GBit-Netz (effektiv ca. 100 MB/s) ergeben rund 50 Sekunden Übertragungsdauer – passt bequem in ein 1-Minuten-Intervall. Bei 10 GB Delta wären es schon gut 100 Sekunden – das Intervall würde nicht mehr eingehalten
Bleibt die Übertragung regelmäßig zurück: Intervall ehrlich verlängern oder die Netzanbindung beschleunigen (z. B. von 1 GbE auf 10 GbE)
🎧 Block 2: RPO-Berechnung & Bandbreite
Bandbreite & Last
Ein großes Delta braucht ein entsprechend schnelles Netz
Rate-Limit (--rate bei pvesr) deckelt die Replikations-Bandbreite in MB/s und schützt das Produktivnetz vor Sättigung während eines großen Laufs
Ein separates Replikationsnetz (eigene NIC/VLAN, ausschließlich für Storage- und Replikationsverkehr) ist bei größeren Deltas oder vielen replizierten VMs sinnvoll, damit ein einzelner großer Lauf nicht den VM-Netzverkehr ausbremst
Zum Einordnen: 1 GbE liefert real ca. 100–110 MB/s, 10 GbE entsprechend rund 1–1,1 GB/s – bei mehreren TB replizierten VMs macht das den Unterschied zwischen Minuten und Sekunden pro Lauf
Für kleine Setups mit wenigen, kleinen VMs reicht das normale Cluster-Netz meist aus – ein eigenes Replikationsnetz lohnt sich erst ab spürbarer Zusatzlast
Zusammenspiel mit HA
Replikation macht lokalen Storage überhaupt erst HA-fähig – ohne sie hätte ein Ersatz-Node nach einem Ausfall schlicht keine Daten
Failover nutzt den zuletzt replizierten Stand – RPO und Replikations-Intervall hängen deshalb direkt zusammen (1-Minuten-Intervall = maximal 1 Minute Datenverlust im Failover-Fall)
Günstige Alternative zu Ceph – kleines, kalkulierbares RPO bereits auf 2 Nodes plus QDevice (siehe Modul 8), statt mindestens 3 Nodes und eigenem Storage-Netz für Ceph
Nach einem Failover ist der ausgefallene Node im Rückstand – kommt er zurück, sollte der Replikationsstand kontrolliert und die Richtung ggf. neu aufgesetzt werden, bevor die VM dorthin zurückwandert
Für den typischen KMU-Fall (2 Nodes, überschaubares Budget) ist lokales ZFS mit Replikation oft die pragmatischste Kombination aus Ausfallsicherheit und Aufwand – Ceph liefert Datenverlust nahe null, aber zu einem deutlich höheren Infrastruktur- und Betriebsaufwand.
🎧 Block 3: Zusammenspiel mit HA
ZFS-Replikation im 3-Node-Cluster
Replikation ist 1:1 gerichtet, nicht verteilt wie Ceph – es gibt kein automatisches Verteilen über den ganzen Cluster
Pro VM wird das bzw. werden die Ziele explizit festgelegt; Mehrfachziel ist möglich, z. B. repliziert eine VM auf Node A sowohl zu Node B als auch zu Node C
Best Practice: jede VM auf mindestens einen definierten Partner-Node replizieren – die Ziele dabei bewusst über die Nodes verteilen, nicht alle VMs auf denselben Partner-Node
Grenze: Ein Failover ist nur auf Nodes möglich, die tatsächlich eine aktuelle Replik der betroffenen VM besitzen – ein Node ohne Replik kann die VM im Ausfallfall nicht übernehmen
ZFS-ReplikationRPO im Minutenbereich, geringerer Aufwand bei Aufbau und Betrieb, gezielte 1:1-Verteilung planbar
CephRPO praktisch 0, mehr Aufwand bei Aufbau und Betrieb, automatische Verteilung über den ganzen Cluster
Entscheidungshilfe für den 3-Node-Cluster: Wer ein höheres, aber kalkulierbares RPO im Minutenbereich akzeptiert und Aufwand sparen will, plant die Replikationsziele gezielt und verteilt über ZFS-Replikation. Wer ein RPO nahe null und automatische Verteilung über den ganzen Cluster braucht, investiert den höheren Aufwand in Ceph.
