KVM‑Live‑Migration ohne Shared‑Storage: Block‑Replikation, Konsistenz und Downtime‑Minimierung

KVM-Live-Migration ohne Shared-Storage ist eine wiederkehrende Herausforderung in heterogenen Rechenzentren, bei Edge-Standorten und bei geplanten Hardwarewechseln, wenn kein zentrales SAN- oder verteiltes Storage-Backend wie Ceph verfügbar ist. Das Fokus-Keyword KVM-Live-Migration ohne Shared-Storage steht deshalb gleich zu Beginn: In diesem Beitrag erkläre ich praxisnah, welche technischen Muster zur Block-Replikation existieren, wie Sie Dateisystem- und Anwendungs-Konsistenz sicherstellen und wie Sie Downtime auf Sekunden reduzieren. Zielgruppe sind Administratoren, System Engineers und Betreiber, die Migrationen planen, testen und betreiben.

Kernkonzepte: Was bedeutet „ohne Shared-Storage“ und welche Optionen gibt es?

„Ohne Shared-Storage“ heißt: Quell- und Zielhost teilen keine persistenten Blockgeräte über ein gemeinsames Storage-Backend. Shared-Storage bezeichnet zentrale Systeme wie SAN, NFS oder verteilte Backends, die beiden Hosts denselben LUN oder RBD-Device bereitstellen. Fehlt dies, müssen Diskblocks aktiv zwischen Hosts synchronisiert werden.

Die gebräuchlichsten Muster sind:

• Block-Replikation auf Blockebene (DRBD oder NBD-basiert).
• Libvirt/QEMU-gestützte Storage-Migration (copy-storage-all, block-copy, postcopy).
• Dateisystem-orientierte Methoden (LVM-Snapshots + rsync für guest-Image-Dateien).

Jedes Muster bringt unterschiedliche Anforderungen an Betrieb, Netzwerk, Monitoring und Rückfallstrategie mit.

KVM-Live-Migration ohne Shared-Storage: Architekturvarianten

DRBD: Replikation auf Blockebene

DRBD (Distributed Replicated Block Device) repliziert Blockgeräte zwischen Hosts auf der Ebene vor dem Dateisystem. Es kann synchron (Protokoll C, sichert jeden Schreibvorgang), semi-synchron (Protokoll B) oder asynchron (Protokoll A) betrieben werden. Vorteil: Für die VM bleibt das Device lokal sichtbar und der Cutover kann sehr kurz sein. Nachteil: Betriebsaufwand für Fencing (automatisches Ausschließen eines fehlverhaltenen Hosts), Split‑Brain‑Vermeidung und regelmäßige Resync-Checks.

# Grundlegende DRBD-Schritte (Beispiel)
drbdadm create-md r0
drbdadm up r0
# Initiale Promotion und Datenübernahme (Achtung: überschreibt Daten auf Ziel!)
drbdadm -- --overwrite-data-of-peer primary r0
cat /proc/drbd

Wichtig für den Betrieb: Fencing (externe Trennung eines fehlerhaften Hosts) und ein Monitoring für Resyncs sind zwingend. Ohne Fencing kann bei Netzwerkpartition Split-Brain entstehen — beide Seiten denken, sie seien Primary, und divergente Schreibstände müssen manuell zusammengeführt werden.

DRBD-Config-Beispiel (minimal)

resource r0 {
  protocol C; # synchrone Replikation
  on hostA {
    device /dev/drbd0;
    disk /dev/sdb1;
    address 10.0.0.1:7789;
    meta-disk internal;
  }
  on hostB {
    device /dev/drbd0;
    disk /dev/sdb1;
    address 10.0.0.2:7789;
    meta-disk internal;
  }
}

Warum das konfiguriert wird: Protocol C stellt sicher, dass ein Schreibvorgang erst als erfolgreich gilt, wenn er auf beiden Seiten abgelegt wurde — wichtig für Zero-RPO-Anforderungen. Bei hohen Latenzen beeinflusst C jedoch die Anwendungslatenz.

QEMU/libvirt Storage-Migration (copy-storage-all, block-job, postcopy)

Libvirt kann Storage von laufenden VMs kopieren. Standard ist ein Pre-copy-Ansatz: initiale Volumenkopie, anschließende inkrementelle Kopien der geänderten Blöcke und finaler Cutover. Postcopy ist ein Modus, in dem die VM am Ziel gestartet wird und fehlende Blöcke bei Bedarf über das Netzwerk geladen werden. Postcopy reduziert das Cutover-Fenster, ist aber anfälliger für Paketverlust oder Quellhost-Ausfall.

# Beispiel: virsh migrate mit copy-storage-all und optionalem postcopy
virsh migrate --live --verbose 
  --copy-storage-all 
  --persistent 
  --unsafe --postcopy 
  vmname qemu+ssh://targethost/system

# Job-Status überprüfen
virsh domjobinfo vmname

Praktischer Tipp: Postcopy nur in einem kontrollierten Netzwerk und nach Belastungstests verwenden. Testen Sie Failover-Szenarien (z. B. Verlust eines Pakets oder kurzzeitige Unterbrechung), bevor Sie es in Produktion einsetzen.

LVM-Snapshot + rsync (Image-basiert)

Wenn VM-Disks als Dateien (qcow2/raw) auf dem Host liegen, ist ein LVM-Snapshot ein pragmatischer Weg, ein konsistentes Abbild zu erzeugen. Anschließend synchronisieren Sie per rsync auf den Zielhost. Nachteile sind längere Downtimes beim finalen Sync und mögliche Inkonsistenzen ohne Quiesce.

# Beispielablauf: Snapshot, rsync und Cleanup
lvcreate -L 10G -s -n vmname-snap /dev/vg/vmname
rsync -av --progress /var/lib/libvirt/images/vmname-snap.img target:/var/lib/libvirt/images/
# Nach erfolgreichem Test Snapshot löschen
lvremove /dev/vg/vmname-snap

Konsistenzanforderungen: Wer muss was flushen und warum?

Konsistenz bedeutet, dass das Ziel-Image einen Zustand darstellt, den Dateisysteme und Anwendungen korrekt interpretieren können. Man unterscheidet Blockkonsistenz (alle Blöcke sind in kohärentem Zustand), Dateisystemkonsistenz (Metadaten und Journal sind korrekt) und Anwendungskonsistenz (z. B. vollständige DB-Transaktionen).

Wesentliche Mechanismen zur Erreichung:

• QEMU Guest Agent: guest-fsfreeze zum kurzzeitigen Einfrieren von Dateisystemen im Gast.
• Applikations-spezifische Hooks: WAL-Switch bei PostgreSQL, Flush-Befehle bei anderen DBMS.
• Dateisystem-Snapshots (LVM/XFS/Btrfs) für atomare Abbilder.

# guest-fsfreeze Beispiel mit virsh
virsh qemu-agent-command vmname '{"execute":"guest-fsfreeze-freeze"}'
# Applikation flush (Beispiel PostgreSQL)
psql -c "SELECT pg_switch_wal();"
# Nach Abschluss
virsh qemu-agent-command vmname '{"execute":"guest-fsfreeze-thaw"}'

Konkreter Migrations‑Runbook (Schritt‑für‑Schritt)

Ein klares, kurzes Runbook reduziert Fehler in Cutover-Phasen. Hier ein praxisorientierter Ablauf für eine Pre-copy-Migration mit Guest‑Agent‑Quiesce:

1. Vorbereitung: Versions-Check von QEMU/libvirt, Platzprüfungen, Netzwerktest (iperf), Monitoring aktiv.
2. Initiale Volumenkopie (Pre-copy) starten.
3. Mehrere inkrementelle Kopien laufen lassen; überwachen, bis die Änderungsrate (dirty rate) klein ist.
4. Guest-Quiesce: guest-fsfreeze + Applikations-Flush.
5. Letzte inkrementelle Synchronisation und Cutover (VM stoppen auf Quelle und starten auf Ziel oder live switch über libvirt).
6. Post-Cutover-Checks: Dateisystem-Checks, Applikations‑Health, Monitor-Metriken vergleichen.
7. Wenn alles stabil: Snapshot/Backup am Ziel entfernen und das Ziel als produktiv markieren.

# Beispiel: Cutover mit virsh (vereinfachte Darstellung)
# 1) Initiate migration
virsh migrate --live --copy-storage-all --persistent vmname qemu+ssh://targethost/system
# 2) Monitor progress
watch -n 2 virsh domjobinfo vmname
# 3) Nach Erfolg: prüfen
ssh targethost virsh list --all | grep vmname
# 4) Falls Abbruch: Abbruchbefehl
virsh migrate --abort vmname || echo "Abort attempted"

Dokumentieren Sie Verantwortlichkeiten für jeden Schritt (wer führt guest-fsfreeze aus, wer startet DB-Flush, wer überwacht Logs).

Rollback‑ und Recovery‑Strategie

Ein Rollback muss schnell und sicher möglich sein. Wichtige Prinzipien:

• Vor dem finalen Cutover einen Wiederherstellungspunkt (Snapshot oder Backup) behalten.
• Timeouts definieren: Wenn Cutover länger als X Minuten dauert, Abbruch und Rückroll auf Quelle.
• Rollenwechsel bei DRBD: klare Befehle und Checklisten für Promoten/Demoten.

# DRBD: Promoten (auf Ziel) / Demoten (auf Quelle)
# Ziel promoten
drbdadm primary r0
# Quelle demoten (falls noch Primary)
drbdadm secondary r0
# Resync anstoßen
drbdadm connect r0
drbdadm status r0

Wenn Sie libvirt-Migration abbrechen müssen, halten Sie fest, ob Ziel bereits Teile der Disk geändert hat. Ein häufiges Muster ist: VM auf Ziel stoppen, Snapshot auf Ziel behalten, VM auf Quelle weiterlaufen lassen und Ursachenanalyse durchführen.

Testing Postcopy mit Netzwerkausfall‑Simulation

Vor der produktiven Nutzung von postcopy sollten Sie Netzwerkfehler simulieren. Nutzen Sie tc (Traffic Control) um Latenz, Paketverlust oder Verbindungsunterbrechungen zu erzeugen:

# Beispiel: 2% Paketverlust und 100ms Latenz auf der Ziel-schnittstelle
tc qdisc add dev eth1 root netem delay 100ms loss 2%
# entfernen
tc qdisc del dev eth1 root netem

Testablauf: Starten Sie eine postcopy-Migration im Testnetz, injizieren Netzwerkfehler und beobachten, ob die VM am Ziel stabil bleibt oder ob fehlende Blöcke zu Fehlern führen. Protokollieren Sie Reaktionszeiten und Recovery-Schritte.

Monitoring, Metriken und Alerts

Praktische Metriken, die Sie überwachen sollten:

• Dirty rate (Änderungsrate der VM-Disks) — beeinflusst Anzahl Pre-copy-Runden.
• Inkrementelle Bytes pro Job und verbleibende Bytes (über virsh domjobinfo).
• Netzwerkdurchsatz und Latenz auf Migrationsnetzwerk (iperf, SNMP).
• DRBD Resync-Status und eventuelle Backlogs.
• Guest-Agent Health, Prozess- und Services-Health im Gast (via monitoring agent).

Konkrete Alarme: wenn Pre-copy länger als erwartet läuft, wenn dirty-rate > X MB/s über Y Minuten bleibt, wenn DRBD Resync fällt oder Split-Brain erkannt wird.

Performance‑Tuning: Parameter, die wirklich helfen

Ein paar praktische Tuning-Ansätze:

• DRBD-Protokollwahl: Protocol C für Konsistenz, A/B für geringere Latenz — wählen nach RPO-Anforderung.
• QEMU-I/O-Optionen: cache=none, io=native reduzieren Host-Seiten-Caching-Effekte beim Kopieren.
• Bei qcow2: Prüfen, ob temporäre Konvertierung auf raw Kopierzeit reduziert — beachten Sie zusätzlichen Speicherbedarf.
• Netzwerk: Dediziertes Migrations-VLAN, QoS oder separate physische Verbindung für große Datenmengen.

Typische Stolperfallen und wie Sie sie vermeiden

• Guest Agent fehlt oder ist veraltet: Testen Sie guest-fsfreeze / thaw vor der Migration.
• Unterschätzte Änderungsrate: Messen Sie dirty-rate im Vorfeld, planen Sie mehrere Pre-copy-Zyklen ein.
• Network-Path überlastet: Separates Migrationsnetzwerk oder QoS-Policy definieren.
• DRBD ohne Fencing: Testen Sie Split‑Brain‑Recovery und setzen Sie SBD/STONITH ein.
• qemu/libvirt-Versioninkompatibilitäten: Versionen vorab vergleichen und Migrationstests durchführen.

Checkliste vor produktiver Migration

1. Sicherung: aktuelles Backup und Validierung vorhanden.
2. Kompatibilitätsprüfung: CPU-Modelle, QEMU/libvirt-Versionen, Image-Formate.
3. Netzwerkprüfung: Latenz, Bandbreite, QoS gesetzt.
4. Guest-Agent und Applikations‑Hooks verifiziert.
5. Monitoring und Alerting für Migrationsmetriken aktiv.
6. Rollback-Runbook bekannt und bestätigt durch Teammitglieder.
7. Dry-Run in Staging durchgeführt.

Fazit: Auswahlkriterien und Betriebsreife

Wählen Sie DRBD, wenn Sie kurze Cutover-Zeiten brauchen und bereit sind, Betriebsprozesse für Fencing und Split-Brain zu betreiben. Wählen Sie libvirt –copy-storage-all / block-copy für einmalige Migrationen ohne zusätzliche Storage-Infrastruktur, vorausgesetzt Netzwerk und Tests sind in Ordnung. LVM-Snapshots plus rsync eignen sich für Szenarien mit vorhersehbaren Wartungsfenstern und weniger strengen Downtime-Anforderungen.

Entscheidend ist die Betriebsreife: Testen Sie jede Methode in einer Staging-Umgebung mit vergleichbarem IO-Profil, dokumentieren Sie Runbooks, automatisieren Sie Pre-Checks und behalten Sie manuellen Eingriff für Cutover-Phasen. Nur so reduzieren Sie die Downtime für kritische Workloads auf ein Minimum und behalten gleichzeitig die Kontrolle über Konsistenz und Recovery.

Mit systematischem Testing, klaren Prüf- und Rückfallstrategien sowie Monitoring können Sie KVM-Live-Migrationen ohne Shared-Storage sicher und zuverlässig betreiben.

KVM-Live-Migration ohne Shared-Storage: Betrieb, Sicherheit und Orchestrierung

Neben der reinen Technik der Block-Replikation entscheiden Betrieb, Sicherheit und Orchestrierung über den Erfolg produktiver Migrationen. Die folgenden Punkte ergänzen die bisherigen technischen Muster um praktische Betriebsregeln, Integrationsaspekte und Automatisierungsansätze, die sich in Projekten mit individueller Unternehmenssoftware und kritischen Diensten bewährt haben.

Sicherheits- und Compliance-Aspekte

Replikations- und Migrationsverkehr transportiert komplette VM-Zustände. Schützen Sie diese Daten strikt: Verschlüsselung in Transit (IPsec, WireGuard oder TLS-Tunnel) und Authentisierung der Peers sind Pflicht, besonders bei asynchroner Replikation. Bei verschlüsselten VMs (LUKS) klären Sie den Schlüsseltransport: Zielhost muss Schlüsselmaterial oder Remote-Unlock-Mechanismus vor Cutover haben. Ein typischer Fehler ist, Migration zu starten und erst beim Start am Ziel auf Schlüsselprobleme zu stoßen.

• Empfehlung: Dediziertes Migrationsnetzwerk mit ACLs und VPN; Logging für Audit-Trails aktivieren.
• Bei DRBD: Management-Ports nicht offen ins Netz stellen; Access-Control und Monitoring-Authentifizierung einsetzen.

Konsistente Multi-VM- oder Cluster-Migration

Verteilte Anwendungen (z. B. Datenbank-Cluster, verteilte Caches) erfordern koordinierte Migrationen. Vorgehen in Kurzform:

1. Orchestrator/Runbook startet zeitgesteuerte Quiesce-Hooks auf allen beteiligten VMs (Anwendungs-Flush, Guest-Agent).
2. Pre-copy-Inkremente laufen, bis Dirty‑Rate sinkt.
3. Finaler Quiesce und synchroner Cutover aller Knoten mit definierten Timeouts.

Ohne Koordination riskieren Sie split-brain auf Anwendungsebene oder inkonsistente Transaktionen. Ein einfaches Mutex-Token (z. B. in etcd) reduziert Risiko, da Cutover nur erfolgen darf, wenn alle Knoten bestätigt haben.

Automatisierung: kleines Orchestrierungsbeispiel

Automatisierte Hooks reduzieren Hands-on‑Fehler. Unten ein minimaler Ansible‑Task, der guest-fsfreeze und einen DB-Flush orchestriert (als Muster, an Ihre Umgebung anpassen):

- name: Quiesce VM and switch WAL
  hosts: controlhost
  tasks:
    - name: Freeze guest filesystem
      command: virsh qemu-agent-command vmname '{"execute":"guest-fsfreeze-freeze"}'
    - name: Trigger DB WAL switch on guest
      command: ssh dbuser@guest "psql -c 'SELECT pg_switch_wal();'"
    - name: Thaw guest filesystem
      command: virsh qemu-agent-command vmname '{"execute":"guest-fsfreeze-thaw"}'

Automatisierung muss idempotent sein und klare Error-Handling-Pfade haben: bei Fehlern Rollback-Trigger und Benachrichtigung an das On‑Call-Team.

Kapazitätsplanung und SLA‑Kalkulation

Planen Sie Migrationen mit einer einfachen Formel: geschätzte Dauer ≈ (Initiale Datenmenge / verfügbare Netto-Bandbreite) + (geschätzte kumulierte Änderungsdaten / Bandbreite) + Cutover-Zeit. Messen Sie vorher Dirty‑Rate und nutzen Sie diese Werte für realistische Fenster. Setzen Sie Alert-Schwellwerte: wenn Pre-copy länger als erwartet läuft oder Dirty‑Rate über Schwelle bleibt, automatisches Abbrechen oder Eskalation.

Validierung nach Migration

Nach dem Cutover prüfen Sie nicht nur, ob die VM läuft, sondern validieren Anwendungstransaktionen, Integritätschecks (Checksummen, DB-Health) und Latenz-/Durchsatz-Metriken gegen Baselines. Automatisieren Sie Smoke‑Checks und vergleichen Sie Telemetrie, bevor Sie die Quelle endgültig deaktivieren.

Diese Ergänzungen helfen, KVM-Live-Migrationen ohne Shared-Storage in den betrieblichen Kontext zu überführen: Sicherheit, koordinierte Orchestrierung und messbare SLAs machen Migrationen vorhersehbar und auditierbar.

Für dieses Thema sind auch Libvirt Copy-Storage-All wichtig. Der Beitrag ordnet diese Aspekte verständlich ein und zeigt, worauf es im Alltag ankommt.