Live-Migration mit Shared-Storage: Latenz messen, Ursachenanalyse und Tuning

Live-Migration mit Shared-Storage gilt als „der einfache Weg“: Die virtuelle Maschine (VM) behält ihre virtuellen Platten auf einem gemeinsamen Storage, während nur CPU- und RAM-Zustand auf einen anderen Host verschoben werden. In der Praxis scheitert es aber erstaunlich oft nicht an der Funktion der Virtualisierung, sondern an Latenz – und zwar an Stellen, die im Alltag gern übersehen werden: Storage-Response-Zeiten, Netzwerk-Jitter, überlaufende Queues, falsch gesetzte Timeouts oder ein Multipath-Pfad, der im Hintergrund „schwimmt“.

Dieser Leitfaden fokussiert deshalb die Betriebsrealität: Wie Sie bei Live-Migration mit Shared-Storage Latenz belastbar messen, Ursachen systematisch eingrenzen und anschließend so tunen, dass Migrationen reproduzierbar funktionieren – inklusive Voraussetzungen, typischer Stolperfallen, Prüfschritten und einer sauberen Rückfallstrategie.

Was bei Live-Migration mit Shared-Storage wirklich passiert (und wo Latenz wirkt)

Auch mit Shared-Storage wird während einer Live-Migration mehr bewegt als „nur ein bisschen RAM“. Typisch ist ein iterativer Ablauf: Speicherseiten werden vorab kopiert (Pre-Copy), während die VM weiterläuft. Je nach Plattform werden zuletzt noch „dirty pages“ (neu beschriebene Seiten) nachgeschoben. Für einen kurzen Moment wird die VM angehalten (Stun/Pause), der Restzustand übertragen und die VM auf dem Zielhost fortgesetzt.

Shared-Storage reduziert die Menge an zu kopierenden Blockdaten, verschärft aber die Anforderungen an konsistente, niedrige Storage-Latenz. Ab dem Moment, in dem die VM auf dem Zielhost läuft, müssen ihre I/O-Requests (Lesen/Schreiben) über neue Host-HBAs/NICs, neue Queue-Strukturen und ggf. andere Pfade zum Storage laufen. Jede Unsauberkeit in Pfadwahl, MPIO (Multipathing), LUN-Ownership, NFS-Mount-Optionen oder Switch-Buffering zeigt sich dann als Latenzspike. Genau diese Spikes erhöhen Stun-Zeiten, verlängern die Migrationsdauer oder führen zu Timeouts.

Symptome richtig lesen: Latenz ist nicht gleich Latenz

Im Troubleshooting ist entscheidend, welche Art von „Langsamkeit“ Sie sehen. Drei Muster sind besonders häufig:

• Konstant hohe Latenz: z. B. 8–15 ms statt 1–3 ms. Ursache oft Überlastung, falsche Queue-Depth, falsche Storage-Tier, zu langsame Links.
• Spikes: z. B. alle 30–120 Sekunden 50–200 ms. Ursache häufig Retransmits, Microbursts, Path-Flaps, Hintergrundjobs (Snapshots, Rebuilds), Cache-Evictions.
• Asymmetrische Latenz: nur auf einem Host oder nur auf einem Pfad. Typisch für Multipath-Fehlkonfiguration, unterschiedliche Firmware/Driver, VLAN/MTU-Mix, falsche LACP/MLAG-Parameter.

Wichtig: Eine Live-Migration ist ein „Stress-Test“ für mehrere Ebenen gleichzeitig. Wenn Sie nur den Hypervisor betrachten, sehen Sie oft nur das Symptom (Migration dauert, VM stottert), nicht die Ursache (Queue läuft voll, NFS hat Retransmits, iSCSI hat Path-Recovery).

Voraussetzungen und typische Stolperfallen (vor dem Messen)

Technische Mindestbedingungen

• Synchronisierte Zeit (NTP/Chrony): Ohne konsistente Zeitstempel sind Korrelationen zwischen Host, Switch und Storage kaum möglich.
• Stabile Pfade zum Shared-Storage: Redundanz ist gut, aber nur, wenn sie sauber konfiguriert ist (Multipath/MPIO, Failover-Policy, ALUA/Asymmetric Logical Unit Access).
• Separates Migrationsnetz (wenn möglich): Migration konkurriert sonst mit Storage- oder Client-Traffic.
• Kompatible CPU-Features/Cluster-Policy: Sonst kommt es zu „hidden downtimes“ oder harten Abbrüchen, die fälschlich als Performanceproblem interpretiert werden.

Stolperfallen aus dem Betrieb

• MTU-Mischbetrieb: Jumbo Frames (MTU 9000) nur auf Teilen der Strecke erzeugen Fragmentierung oder Drops; beides wirkt wie Latenz.
• Bufferbloat auf Switchports/Uplinks: Hoher Durchsatz bei gleichzeitig steigender Latenz; Migrationen reagieren empfindlich auf Jitter.
• Snapshots/Backups während Migration: Storage-seitig entstehen Copy-on-Write-Kosten oder zusätzliche Reads.
• Übersehene Queue-Limits: HBA/NIC-Queues, dm-multipath, iSCSI-Sessions oder NFS-RPC-Slots können sich bei Migrationen anders verhalten als im Normalbetrieb.
• Unklare Erfolgskriterien: „Migration war langsam“ ist kein Messwert. Definieren Sie Zielwerte (Max-Stun, Max-Dauer, Max-Latenzspike).

Latenz messen: Welche Metriken Sie wirklich brauchen

Für eine belastbare Ursachenanalyse reichen ein Ping und ein Storage-Dashboard selten aus. Sie brauchen Messwerte auf drei Ebenen, idealerweise parallel im selben Zeitfenster:

• Gast/VM-Wirkung: Stun-Zeit, Applikationslatenz, Timeouts, erhöhte IO-Wartezeit.
• Hypervisor/Host: Block-Device-Latenz (read/write await), Queue-Auslastung, CPU-Steal/Ready, Netzwerk-Retransmits.
• Storage/Netz: Port-Errors, Drops, Retransmits, Path-Failover-Ereignisse, Array-Latenz (Frontend/Backend), Cache-Hit-Rate.

Als Faustregel: Wenn Host-Block-Latenz hoch ist, aber Array „grün“ meldet, liegt oft ein Pfad- oder Netzwerkproblem vor. Wenn Array-Latenz hoch ist, ist das Storage selbst unter Druck (Tier, Cache, Backend-Disks, Rebuild, Snapshotting).

Linux-Host: Block-Latenz und Queue-Verhalten messen

Auf Linux-Hypervisoren (z. B. KVM-Hosts) sind iostat und sar robuste Startpunkte. Sie liefern „await“ (mittlere I/O-Wartezeit) und „svctm“ je nach Kernel/Tool-Version eingeschränkt; wichtiger ist die Kombination aus Latenz und Auslastung.

# Paket: sysstat
# 1) I/O-Latenz und Auslastung je Device, 1s Intervall, 60 Samples
iostat -x -d 1 60

# 2) Block-Device-Throughput und Queue in sar (falls aktiviert)
sar -d 1 60

# 3) VM-Statistiken (CPU-Wartezeiten, Runqueue) als Kontext
sar -q 1 60

Interpretation im Migrationskontext:

• await steigt deutlich während Migration: Storage-Pfad oder Array wird zusätzlich belastet.
• %util nahe 100% bei einzelnen Devices: Engpass auf diesem Device/Pfad (z. B. ein Multipath-Pfad wird bevorzugt).
• Hohe avgqu-sz: Requests stauen sich (Queueing), oft Vorbote von Timeouts.

Multipath/MPIO: Pfadzustand und Flapping sichtbar machen

Multipathing (Linux dm-multipath oder Windows MPIO) bündelt mehrere physische Wege zum Storage. Es schützt vor Ausfällen, kann aber Latenz massiv verschlechtern, wenn Pfade instabil sind oder die Policy ungünstig ist (z. B. unpassendes Load-Balancing, falsche ALUA-Prioritäten).

# Überblick über Multipath-Devices, Policies, Prioritäten und Pfade
multipath -ll

# Kernel-Log nach Storage-Resets, Path-Down/Up, Timeout/Abort prüfen
journalctl -k --since "-2h" | egrep -i "multipath|scsi|iscsi|nvme|path down|path up|abort|reset|timeout"

Wenn Sie während der Migration „Path down/up“-Ereignisse sehen oder häufige SCSI-Resets, sind das keine „kosmetischen“ Meldungen. Jede Recovery kann Latenzspikes im Sekundenbereich verursachen. Genau solche Spikes sind es, die Live-Migrationen destabilisieren.

Netzwerk: Verlust, Retransmits und Jitter erfassen

Für Shared-Storage ist das Netzwerk oft doppelt relevant: einmal für die Migration selbst (Memory-Transfer) und einmal für Storage-Protokolle wie NFS oder iSCSI. Drops und Retransmits wirken wie Latenz, weil TCP neu senden muss und Anwendungen warten.

# Interface-Statistiken: Drops, Errors, Retransmits-Hinweise
ip -s link

# TCP-Statistiken: Retransmits, RTO, Out-of-order
ss -s
netstat -s | egrep -i "retrans|timeout|failed|listen|segments"

# Paketmitschnitt zur Korrelation (nur gezielt, kurzzeitig!)
# Beispiel: iSCSI (3260) oder NFS (2049) an einem Storage-Interface
tcpdump -i ethX -nn -s 128 -w /tmp/storage-trace.pcap '(port 3260 or port 2049)'

Ein häufiger Fehler ist, „Latenz“ ausschließlich als Ping-Zeit zu messen. Ping misst ICMP und oft nur eine geringe Paketgröße. Storage-Protokolle und Migrationen reagieren aber auf Queueing, Drops unter Last, MTU-Fehler und Microbursts. Deshalb sind Interface-Counter und TCP-Statistiken so wichtig.

Windows/Hyper-V-Umfeld: Basismessung ohne Spezialtools

In Windows-Umgebungen können Sie mit Bordmitteln zumindest die Richtung bestimmen: Storage-Latenz per Performance Counter und Netzwerk-Fehler per Adapterstatistik. (Je nach Umgebung liefern Hyper-V- und SMB-Direct/RDMA-Setups zusätzliche Counter.)

# Netzadapter-Statistiken (Errors, Discards)
Get-NetAdapterStatistics | Sort-Object -Property Name | Format-Table -Auto

# Performance Counter für Datenträger-Latenz (Beispiel: alle Instanzen)
Get-Counter -Counter "LogicalDisk(*)Avg. Disk sec/Read","LogicalDisk(*)Avg. Disk sec/Write" -SampleInterval 1 -MaxSamples 30

Als grobe Einordnung: Einzelne Millisekunden sind in vielen SAN/NVMe-oF/FC-Umgebungen normal; zweistellige Millisekunden unter Last sind ein Warnsignal, insbesondere wenn sie spiken.

Ursachenanalyse: Vorgehen in klaren Schritten

Die Kunst ist, Migrationen nicht „auf Verdacht“ zu tunen, sondern Hypothesen zu prüfen. Bewährt hat sich diese Reihenfolge:

1. Reproduzierbarkeit herstellen: Migration einer Test-VM oder einer unkritischen VM, immer gleicher Zeitraum, ähnliche Last.
2. Trennen von Migrations- vs. Storage-Traffic: Wenn möglich separate NICs/VLANs; sonst zumindest Messung je Interface.
3. Host-seitige Latenz lokalisieren: Welches Device/Multipath-Device zeigt hohe await/Queue?
4. Pfad-Ereignisse suchen: Path-Flaps, Link-Errors, CRC-Errors, iSCSI-Reconnects, NFS-Retrans.
5. Storage-seitige Events korrelieren: Snapshot, Rebuild, Cache-Flush, Controller-Failover, Tiering.
6. Migrationseinstellungen prüfen: Concurrency, Bandbreitenlimit, Stun-Threshold, Pre-Copy-Parameter.

Check: Ist die VM selbst der Treiber (Dirty-Page-Rate)?

Manche VMs sind „schlecht migrierbar“, obwohl Storage und Netzwerk in Ordnung sind: Datenbanken mit sehr hohem Schreibaufkommen oder Memory-Intensive Anwendungen erzeugen eine hohe Dirty-Page-Rate (Speicherseiten ändern sich schneller, als Sie kopiert werden können). Dann pendelt die Migration in immer neuen Iterationen oder endet mit hohem Stun.

Praktischer Test: Migrieren Sie eine eher „ruhige“ VM und eine „heiße“ VM im selben Zeitfenster. Wenn nur die „heiße“ VM auffällig ist, liegt der Schwerpunkt eher bei Workload/Migrationsparametern als bei Shared-Storage-Latenz.

Check: Pfad-Asymmetrie und ALUA/Ownership

Bei SANs mit ALUA gibt es oft „optimierte“ und „nicht optimierte“ Pfade. Wenn ein Host nach der Migration überwiegend nicht-optimierte Pfade nutzt, steigt die Latenz ohne offensichtliche Fehler. Das sehen Sie in dm-multipath (Prioritäten) oder im Array-Frontend. Abhilfe ist selten „mehr Bandbreite“, sondern saubere ALUA-Erkennung, korrekte Prioritäten und konsistente Treiber/Firmware-Stände auf allen Hosts.

Check: NFS-Retransmits und RPC-Slots

Bei NFS ist Latenz oft eine Mischung aus Server-Response, Netz und Client-Queue. Retransmits treten auf, wenn Pakete verloren gehen oder Antworten zu spät kommen. Ein nicht seltener Stolperstein: zu aggressive Mount-Optionen, die unter Last Timeouts provozieren, oder zu konservative Einstellungen, die Recovery verlängern. Hier ist Fingerspitzengefühl gefragt, weil „Tuning“ sonst nur Symptome verschiebt.

# NFS-Client-Statistiken (Linux)
nfsstat -c

# Mount-Optionen und NFS-Version prüfen
mount | egrep -i " nfs "
cat /proc/mounts | egrep -i " nfs "

Tuning-Ansätze, die in der Praxis wirklich helfen

Die folgenden Maßnahmen sind bewusst so formuliert, dass Sie sie in Change-Prozessen sauber begründen und testen können. Nicht jede Maßnahme passt zu jeder Umgebung; entscheidend ist, dass Sie jeweils ein konkretes Symptom adressieren.

1) Migrationen entkoppeln und begrenzen (Concurrency und Bandbreite)

Ein Klassiker: Mehrere gleichzeitige Live-Migrationen erzeugen Traffic-Spitzen, die Switch-Queues und Storage-Frontends kurzzeitig überfahren. Das sieht dann wie „plötzliche Latenz“ aus. Die oft wirksamste Maßnahme ist organisatorisch/technisch simpel: weniger parallele Migrationen und Bandbreitenlimit für Migrationsverkehr, damit Storage-Traffic nicht verhungert.

Warum das funktioniert: Sie reduzieren Microbursts und stabilisieren die Queue-Latenz. In vielen Umgebungen ist eine etwas längere, aber gleichmäßige Migration deutlich besser als eine kurze Migration mit harten Spikes und Stun.

2) Netzwerk-Grundlagen härten: MTU, LACP, ECN, Puffer

Wenn Sie Jumbo Frames einsetzen: Prüfen Sie die MTU Ende-zu-Ende (Host-NIC, vSwitch/Bridge, Switchports, Uplinks, Storage-Ports). Eine einzelne 1500er-Strecke in einem 9000er-Pfad führt zu Fragmentierung oder Drops. Für Storage-Protokolle ist das Gift.

# MTU am Host prüfen
ip link show | egrep -i "mtu|state"

# Pfad-MTU testen (Beispiel 8972 Payload für MTU 9000; anpassen je nach Overhead)
ping -M do -s 8972 -c 5 <ziel-ip>

Wenn Retransmits/Out-of-order hoch sind, schauen Sie zusätzlich auf LACP/MLAG-Hashing und asymmetrische Pfade. Ein „funktionierendes“ Bonding kann trotzdem stark schwanken, wenn Hashing und Traffic-Muster ungünstig zusammenkommen.

3) Multipathing stabilisieren: Policies, Timeouts, Path-Health

Das Ziel ist nicht „maximal aggressives Failover“, sondern vorhersehbares Verhalten. Zu kurze Timeouts können bei kurzen Spikes unnötige Pfadwechsel triggern; zu lange Timeouts machen echte Ausfälle schmerzhaft. Prüfen Sie außerdem, ob ein Pfad permanent schlechter ist (CRC-Errors, Light-Level bei FC, schlechte Transceiver, fehlerhafte Kabel) und dadurch das Load-Balancing „verdirbt“.

Praxisregel: Bevor Sie Parameter drehen, stabilisieren Sie die Physik (Kabel/Optiken/Ports), dann erst Software-Policies.

4) Storage-seitige Nebenlasten terminieren: Snapshots, Rebuilds, Tiering

Live-Migrationen fallen oft in Wartungsfenster – und genau dort laufen auch Storage-Aufgaben: Rebuilds, Scrubs, Snapshot-Konsolidierung, Tiering-Moves. Das ist technisch legitim, aber betriebsseitig gefährlich, wenn alle Lastspitzen zusammenfallen. Planen Sie Migrationsfenster so, dass Storage-Hintergrundjobs entweder abgeschlossen sind oder gedrosselt laufen. Wenn das Array QoS (Quality of Service) oder Priorisierung unterstützt, nutzen Sie sie für kritische Datastores.

5) VM-seitige Vorbereitung: I/O glätten, große Writes entschärfen

Wenn einzelne VMs Migrationen „kaputt schreiben“, helfen manchmal einfache Maßnahmen: Batch-Jobs für die Migration pausieren, Datenbank-Checkpointing zeitlich verschieben, Log-Flush-Intervalle prüfen. Es geht nicht darum, Applikationen zu „verbiegen“, sondern darum, während der kritischen Phase Dirty-Page-Rate und I/O-Spitzen zu reduzieren.

Praxis-Runbook: Messung, Testmigration, Korrelation

Das folgende Vorgehen ist bewusst als wiederholbare Checkliste formuliert. Ziel ist ein Audit-Trail: Sie können später nachvollziehen, warum eine Änderung geholfen hat (oder nicht).

1) Vor dem Test: Zustand dokumentieren

• Hosts: Kernel/Hypervisor-Version, Treiberstände (NIC/HBA), Multipath-Policy
• Netz: MTU, VLANs, LACP/MLAG, dediziertes Migration-Netz ja/nein
• Storage: Protokoll (NFS/iSCSI/FC), Datastore/LUN, aktuelle Hintergrundjobs

2) Messfenster öffnen (Host + Netz)

# Terminal A: I/O Metriken
iostat -x -d 1 300

# Terminal B: Kernel-Events (Storage/Netz)
journalctl -k -f

# Terminal C: TCP/Interface-Zähler (alle 10s)
while true; do date; ip -s link; ss -s; sleep 10; done

3) Testmigration durchführen und Zeitpunkt notieren

Notieren Sie Start/Ende, VM-Name, Quell-/Zielhost, Datastore/LUN und parallel laufende Migrationen. Diese einfachen Metadaten sparen später Stunden.

4) Nach dem Test: Drei Fragen beantworten

• Wurde die Latenz am Blockdevice sichtbar? (await/Queue steigt)
• Gab es Netz-Indikatoren? (Drops, Retransmits, Out-of-order)
• Gab es Pfad-/Reset-Events? (multipath/scsi/iscsi logs)

Erst wenn Sie diese drei Punkte sauber beantworten können, ist Tuning zielgerichtet. Alles andere ist „Trial and Error“.

Risiken und Nebenwirkungen beim Tuning

Viele Performance-Änderungen haben Trade-offs. Drei typische Risiken:

• Zu aggressive Timeouts können bei kurzen Spikes unnötige Failover auslösen (mehr Instabilität statt weniger).
• Übermäßiges Bandbreitenlimit stabilisiert zwar Latenz, verlängert aber Migrationen so stark, dass Wartungsfenster platzen.
• QoS falsch eingesetzt kann andere Workloads verhungern lassen oder Latenz nur verlagern (z. B. von VM-A nach VM-B).

Deshalb: Änderungen immer einzeln, messbar, mit Rückbauplan.

Rückfallstrategie: Wenn Live-Migration im Fenster nicht stabil wird

Eine gute Betriebsstrategie akzeptiert, dass nicht jede Umgebung jede VM jederzeit live migrieren kann. Definieren Sie vorab, wann Sie abbrechen und wie Sie sicher weiterkommen:

• Abbruchkriterien: Stun > X ms, Migration > Y Minuten, Storage-Latenz > Z ms über N Sekunden, wiederholte Pfad-Resets.
• Fallback 1: VM im definierten Zeitfenster geordnet herunterfahren, Cold-Migration durchführen, Services kontrolliert wieder starten.
• Fallback 2: Workload verschieben (z. B. Batch aussetzen), später erneut migrieren.
• Fallback 3: Wartungsfenster verlängern oder Split in mehrere kleinere Migrationen (weniger parallele Moves).

Wichtig: Ein Abbruch ist kein Scheitern, wenn er kontrolliert erfolgt. Unkontrollierte Timeouts und Recovery-Stürme sind das eigentliche Risiko.

Best Practices für dauerhaft stabile Migrationen

• Monitoring auf Latenzspikes: Nicht nur Durchschnittswerte, sondern Perzentile (p95/p99) und Maxima betrachten.
• Change-Disziplin: Netzwerk- und Storage-Änderungen (Firmware, Switch-Config, Pfad-Policy) versionieren und dokumentieren.
• Regelmäßige „Migrationsproben“: Nicht nur im Notfall migrieren. Kleine, geplante Tests halten Pfade, Policies und Runbooks ehrlich.
• Trennung von Traffic-Klassen: Storage, Migration, Management und VM-Client-Traffic soweit möglich separieren.
• Abhängigkeiten kennen: Backup-Fenster, Snapshotting, Rebuilds, ETL-Jobs – alles, was Latenzspikes erzeugt, muss in die Planung.

Fazit: Latenz messbar machen, dann erst tunen

Bei Live-Migration mit Shared-Storage entscheidet selten „der Hypervisor“ allein über Erfolg oder Misserfolg. Entscheidend ist, ob Storage- und Netzwerkpfade unter Migrationslast vorhersehbar niedrige Latenz liefern und ob Ihr Betrieb die typischen Spike-Ursachen (Queues, Retransmits, Path-Flaps, Hintergrundjobs) erkennt und entschärft. Wenn Sie Metriken konsequent auf Host-, Netz- und Storage-Ebene korrelieren, wird aus dem gefühlten „Migration ist manchmal zäh“ ein klarer Befund – und daraus ein Tuning, das auch Monate später noch trägt.

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