# Live Migration & HA: Resilienz im Hyper-V Cluster

TL;DR / Management Summary Live Migration ermöglicht das Verschieben einer laufenden VM zwischen physischen Hosts ohne Unterbrechung für den User. In Verbindung mit dem Windows Failover Cluster erreichen wir echte High Availability (HA): Wenn ein Host stirbt, startet die VM automatisch auf einem anderen Knoten neu. Ein Senior Admin optimiert das Migrations-Netzwerk (Compression vs. RDMA) und versteht die Abhängigkeit von Shared Storage (iSCSI, SMB3 oder S2D).

# 1. Einführung & Konzepte

Bewegung ohne Pause.

Es gibt zwei Arten der Migration:

  1. Live Migration (Shared Storage): Nur der RAM-Inhalt wird über das Netz geschickt. Die VHDX liegt auf einem gemeinsamen Speicher (SAN/S2D) und wird einfach vom anderen Host übernommen.
  2. Storage Live Migration: Die VHDX wird im laufenden Betrieb von einem Storage-System auf ein anderes verschoben (ohne Host-Wechsel).
  3. Shared Nothing Live Migration: Sowohl RAM als auch VHDX werden gleichzeitig über das Netz geschickt (kein Shared Storage nötig, aber sehr zeitintensiv).

# Architektur-Übersicht (Mermaid)

graph LR
    subgraph "Node A (Source)"
    VM_RAM[VM Memory]
    end

    subgraph "Node B (Destination)"
    VM_RAM_NEW[VM Memory Copy]
    end

    VM_RAM -->|TCP 6602 / Migration Net| VM_RAM_NEW
    STORAGE[(Shared Storage: CSV)] --- NodeA[Node A]
    STORAGE --- NodeB[Node B]

# 2. Einrichtung in der Praxis

Das Cluster-Fundament.

# Schritt 1: Cluster erstellen

Voraussetzung: Alle Knoten sind in der Domäne und haben identische Hardware/Patches.

# Validierung (Muss fehlerfrei sein!)
Test-Cluster -Node "HV01", "HV02"

# Cluster erstellen
New-Cluster -Name "HV-PROD-CLUSTER" -Node "HV01", "HV02" -StaticAddress 10.0.0.100

# Schritt 2: Live Migration optimieren

Konfigurieren Sie das Netzwerk für maximale Geschwindigkeit:

Set-VMHost -VirtualMachineMigrationPerformanceOption SMB # Oder 'Compression' bei wenig Bandbreite

# 3. Deep Dive: Quorum & Witness

Wer hat die Mehrheit?

Ein Cluster braucht eine Mehrheit (“Quorum”), um Entscheidungen zu treffen (z.B. Host-Isolation).

# 4. Day-2 Operations: Wartung & Failover

Den Ernstfall proben.

# Drain-Roles (Wartungsmodus)

Wenn Sie einen Knoten patchen müssen:

# Schiebt alle VMs automatisch via Live Migration auf andere Knoten
Suspend-ClusterNode -Name "HV01" -Drain

# Failover-Prioritäten

Nicht alle VMs sind gleich wichtig.

# 5. Troubleshooting & “War Stories”

Wenn der Schwenk hängen bleibt.

# Top 3 Fehlerbilder

  1. Symptom: Live Migration schlägt bei 90% fehl.

    • Ursache: CPU-Inkompatibilität. Der Ziel-Host hat eine neuere CPU-Generation als der Quell-Host.
    • Lösung: “Prozessor-Kompatibilitätsmodus” in den VM-Settings aktivieren (Geringer Performance-Verlust, aber stabilere Migration).

  2. Symptom: “Cluster Shared Volume (CSV)” steht auf Redirected Access.

    • Ursache: Ein Knoten hat den physischen Storage-Pfad verloren und schickt den I/O-Traffic über das LAN eines anderen Knotens.
    • Lösung: Storage-Verbindung (HBA/iSCSI) prüfen.

  3. Symptom: Quorum-Loss führt zum Shutdown des gesamten Clusters.

    • Ursache: Split-Brain Szenario bei Netzwerkausfall.

# “War Story”: Die “Stille” Migration

Ein Admin startete eine Live Migration einer 128 GB RAM Datenbank-VM über eine 1 Gbit Leitung. Das Ergebnis: Die Migration dauerte 20 Minuten. Während dieser Zeit war der Ping zur VM bei 500ms, da die Leitung komplett durch den RAM-Transfer gesättigt war. Die Applikation verlor die Verbindung zum Backend. Lehre: Nutzen Sie für Live Migration dedizierte 10 GbE (oder schneller) Interfaces und konfigurieren Sie QoS, damit der Migrationstresor nicht den Nutzverkehr erstickt.

# 6. Monitoring & Reporting

Cluster-Health.

# Wichtige Metriken

# 7. Fazit & Empfehlung

Live Migration ist die “Superkraft” von Hyper-V.

# Anhang: Cheatsheet

Aufgabe Befehl
Cluster Status Get-ClusterNode
VM verschieben Move-ClusterVirtualMachineRole -Name "VM01" -Node "HV02"
Quorum Info Get-ClusterQuorum
CSV Status Get-ClusterSharedVolume

# Referenzen