Migration à chaud avec stockage partagé : mesurer la latence, analyse des causes et optimisation

La migration à chaud (Live-Migration) avec stockage partagé est considérée comme « la voie facile » : la machine virtuelle (VM) conserve ses disques virtuels sur un stockage commun, tandis que seul l’état CPU et mémoire est déplacé vers un autre hôte. En pratique, l’échec survient étonnamment souvent non pas à cause de la fonctionnalité de virtualisation, mais à cause de la latence — et précisément à des endroits souvent négligés au quotidien : temps de réponse du stockage, jitter réseau, files d’attente qui débordent, timeouts mal configurés ou un chemin multipath qui « flotte » en arrière-plan.

Ce guide se concentre donc sur la réalité opérationnelle : comment mesurer de manière fiable la latence lors de Live-Migration avec stockage partagé, circonscrire systématiquement les causes et ensuite régler les paramètres pour que les migrations fonctionnent de façon reproductible — y compris les prérequis, les pièges typiques, les étapes de vérification et une stratégie de repli propre.

Ce qui se passe réellement lors d’une Live-Migration avec stockage partagé (et où la latence intervient)

Même avec un stockage partagé, une Live-Migration déplace plus que « juste un peu de RAM ». Le processus est typiquement itératif : des pages mémoire sont copiées en amont (Pre-Copy) pendant que la VM continue de fonctionner. Selon la plateforme, les « dirty pages » (pages récemment écrites) sont ensuite transférées. Pendant un court instant, la VM est arrêtée (stun/pause), l’état RESTant est transféré et la VM est reprise sur l’hôte cible.

Le stockage partagé réduit la quantité de données bloc à copier, mais renforce les exigences en matière de latence de stockage faible et cohérente. À partir du moment où la VM s’exécute sur l’hôte cible, ses requêtes I/O (lecture/écriture) doivent transiter via de nouveaux HBA/NICs d’hôte, de nouvelles structures de files d’attente et éventuellement via d’autres chemins vers le stockage. Toute imprécision dans le choix des chemins, la configuration MPIO (multipathing), la propriété des LUN (LUN-Ownership), les options de montage NFS ou le buffering des commutateurs se manifeste alors par des pics de latence. Ce sont précisément ces pics qui allongent les temps de stun, prolongent la durée de migration ou provoquent des timeouts.

Lire correctement les symptômes : la latence n’est pas uniforme

En dépannage, il est essentiel de déterminer quel type de « lenteur » vous observez. Trois phénomènes sont particulièrement courants :

• Latence constamment élevée : p. ex. 8–15 ms au lieu de 1–3 ms. Causes fréquentes : surcharge, profondeur de file (queue depth) incorrecte, mauvais niveau de stockage (storage tier), liens trop lents.
• Pics (spikes) : p. ex. toutes les 30–120 secondes 50–200 ms. Causes fréquentes : retransmissions, micro-bursts, path-flaps, tâches en arrière-plan (snapshots, rebuilds), évictions de cache.
• Latence asymétrique : uniquement sur un hôte ou sur un seul chemin. Typique d’une mauvaise configuration multipath, de firmwares/drivers différents, d’un mélange VLAN/MTU, ou de paramètres LACP/MLAG incorrects.

Important : une Live-Migration est un « test de charge » pour plusieurs couches simultanément. Si vous ne regardez que l’hyperviseur, vous ne verrez souvent que le symptôme (la migration prend du temps, la VM saccade), pas la cause (file d’attente qui se remplit, NFS avec retransmissions, iSCSI en récupération de chemin).

Prérequis et pièges typiques (avant la mesure)

Conditions techniques minimales

• Horloges synchronisées (NTP/Chrony) : sans horodatages cohérents, il est quasiment impossible de corréler les événements entre hôte, switch et stockage.
• Chemins stables vers le stockage partagé : la redondance est utile, mais uniquement si elle est correctement configurée (Multipath/MPIO, politique de basculement, ALUA/Asymmetric Logical Unit Access).
• Réseau de migration séparé (si possible) : sinon la migration entre en concurrence avec le trafic de stockage ou des clients.

Pièges en exploitation

• Configuration MTU mixte : Des Jumbo Frames (MTU 9000) présents seulement sur une portion du trajet provoquent fragmentation ou pertes ; les deux se traduisent par de la latence.
• Bufferbloat sur les ports de commutateur/uplinks : débit élevé avec une latence croissante ; les migrations réagissent fortement au jitter.
• Snapshots/Sauvegardes pendant la migration : côté stockage apparaissent des coûts Copy-on-Write ou des lectures supplémentaires.
• Limites de files d’attente négligées : HBA/NIC-Queues, dm-multipath, sessions iSCSI ou slots NFS-RPC peuvent se comporter différemment lors de migrations que pendant le fonctionnement normal.
• Critères de succès flous : « La migration a été lente » n’est pas une métrique. Définissez des objectifs (Max-Stun, Max-Dauer, Max-Latenzspike).

Mesurer la latence : quelles métriques vous sont réellement nécessaires

Pour une analyse des causes fiable, un ping et un tableau de bord de stockage suffisent rarement. Vous avez besoin de mesures à trois niveaux, idéalement en parallèle sur la même fenêtre temporelle :

• Effet sur l’invité/VM : durée de stun, latence applicative, timeouts, augmentation du temps d’attente I/O.
• Hyperviseur/Hôte : latence des block devices (read/write await), charge des files d’attente, CPU-Steal/Ready, retransmissions réseau.
• Storage/Réseau : erreurs de port, drops, retransmissions, événements de path-failover, latence de l’array (frontend/backend), cache-hit-rate.

Règle générale : si la latence block côté hôte est élevée alors que l’array signale « grün », il s’agit souvent d’un problème de chemin ou de réseau. Si la latence de l’array est élevée, le stockage lui-même est sous pression (Tier, Cache, disques backend, rebuild, snapshotting).

Linux-hôte : mesurer la latence bloc et le comportement des files d’attente

Sur Linux-hyperviseurs (p. ex. KVM-Hosts), iostat et sar sont des points de départ robustes. Ils fournissent « await » (temps d’attente I/O moyen) et « svctm » selon la version du noyau/outils, de façon limitée ; plus importante est la combinaison latence/charge.

# 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

Interprétation dans le contexte des migrations :

• await augmente nettement durant la migration : le chemin de stockage ou l’array est sollicité en plus.
• %util proche de 100% sur certains devices : goulot d’étranglement sur ce device/chemin (p. ex. un chemin Multipath est privilégié).
• avgqu-sz élevé : les requêtes s’accumulent (queueing), souvent annonciateur de timeouts.

Multipath/MPIO : rendre visibles l’état des chemins et le flapping

Multipathing (Linux dm-multipath oder Windows MPIO) regroupe plusieurs chemins physiques vers le stockage. Il protège contre les pannes, mais peut fortement dégrader la latence si les chemins sont instables ou si la politique est défavorable (p. ex. équilibrage de charge inadapté, priorités ALUA incorrectes).

# Aperçu des périphériques multipath, des politiques, priorités et chemins
multipath -ll

# Vérifier le journal du noyau pour resets de stockage, événements Path-Down/Up, timeout/abort
journalctl -k --since "-2h" | egrep -i "multipath|scsi|iscsi|nvme|path down|path up|abort|reset|timeout"

Si vous observez pendant la migration des événements « Path down/up » ou des resets SCSI fréquents, ce ne sont pas des messages « cosmétiques ». Chaque récupération peut provoquer des pics de latence de l’ordre de secondes. Ce sont précisément ces pics qui déstabilisent les migrations à chaud.

Réseau : détection des pertes, retransmissions et jitter

Pour le stockage partagé, le réseau est souvent doublement pertinent : d’une part pour la migration elle‑même (transfert de mémoire) et d’autre part pour les protocoles de stockage comme NFS ou iSCSI. Les pertes (drops) et retransmissions se manifestent comme de la latence, car TCP doit renvoyer et les applications attendent.

# Statistiques des interfaces : pertes, erreurs, indications de retransmissions
ip -s link

# Statistiques TCP : retransmissions, RTO, paquets hors d'ordre
ss -s
netstat -s | egrep -i "retrans|timeout|failed|listen|segments"

# Capture de paquets pour corrélation (uniquement ciblée, de courte durée !)
# Exemple : iSCSI (3260) ou NFS (2049) sur une interface vers le stockage
tcpdump -i ethX -nn -s 128 -w /tmp/storage-trace.pcap '(port 3260 or port 2049)'

Une erreur fréquente est de mesurer la « latence » uniquement par le temps de ping. Ping mesure l’ICMP et souvent une taille de paquet faible. Les protocoles de stockage et les migrations réagissent en revanche à la mise en file d’attente, aux pertes sous charge, aux erreurs MTU et aux micro‑bursts. C’est pourquoi les compteurs d’interface et les statistiques TCP sont si importants.

Windows/Hyper-V : mesures de base sans outils spécialisés

Dans les environnements Windows, vous pouvez, avec les outils intégrés, au moins déterminer la tendance : latence de stockage via compteurs de performance et erreurs réseau via statistiques des adaptateurs. (Selon l’environnement, les configurations Hyper‑V et SMB‑Direct/RDMA fournissent des compteurs supplémentaires.)

# Statistiques des adaptateurs réseau (Errors, Discards)
Get-NetAdapterStatistics | Sort-Object -Property Name | Format-Table -Auto

# Compteurs de performance pour la latence des disques (exemple : toutes les instances)
Get-Counter -Counter "LogicalDisk(*)Avg. Disk sec/Read","LogicalDisk(*)Avg. Disk sec/Write" -SampleInterval 1 -MaxSamples 30

À titre indicatif : une à quelques millisecondes sont normales dans de nombreux environnements SAN/NVMe‑oF/FC ; des valeurs à deux chiffres de millisecondes sous charge constituent un signal d’alerte, surtout si elles se manifestent par des pics.

Analyse des causes : démarche en étapes claires

L’art consiste à ne pas tuner les migrations « sans fondement », mais à vérifier des hypothèses. L’ordre suivant a fait ses preuves :

1. Rétablir la reproductibilité : migration d’une VM de test ou d’une VM non critique, toujours la même fenêtre temporelle, charge similaire.
2. Séparer le trafic de migration et le trafic stockage : si possible NICs/VLANs séparés ; sinon au minimum mesurer par interface.
3. Localiser la latence côté hôte : quel device/multipath-device affiche un await/Queue élevé ?
4. Rechercher des événements de chemin : Path-Flaps, Link-Errors, CRC-Errors, reconnexions iSCSI, retransmissions NFS.
5. Corréler les événements côté stockage : snapshot, rebuild, vidage de cache, failover de contrôleur, tiering.
6. Vérifier les paramètres de migration : concurrency, limite de bande passante, stun-threshold, paramètres de pre-copy.

Contrôle : la VM est-elle elle-même le facteur déterminant (taux de pages modifiées) ?

Certaines VMs sont « difficiles à migrer » alors même que le stockage et le réseau sont corrects : des bases de données avec un très fort volume d’écritures ou des applications consommant beaucoup de mémoire génèrent un taux élevé de pages modifiées (les pages mémoire changent plus vite qu’elles ne peuvent être copiées). La migration tourne alors en itérations successives ou se termine avec un fort stun.

Test pratique : migrez une VM plutôt « calme » et une VM « chaude » dans la même fenêtre temporelle. Si seule la VM « chaude » est problématique, l’origine est plutôt la charge/les paramètres de migration que la latence du stockage partagé.

Contrôle : asymétrie de chemin et ALUA/Ownership

Sur des SANs avec ALUA, il existe souvent des chemins „optimisés“ et des chemins „non optimisés“. Si un hôte utilise majoritairement des chemins non optimisés après la migration, la latence augmente sans erreurs évidentes. On le voit dans dm-multipath (priorités) ou dans le frontend de l’array. La solution n’est rarement „plus de bande passante“, mais une détection ALUA propre, des priorités correctes et des versions de pilotes/firmware cohérentes sur tous les hôtes.

Contrôle : retransmissions NFS et slots RPC

Avec NFS, la latence est souvent un mélange de temps de réponse serveur, réseau et file d’attente côté client. Des retransmissions se produisent lorsque des paquets sont perdus ou que les réponses arrivent trop tard. Un piège fréquent : des options de montage trop agressives qui provoquent des timeouts sous charge, ou des réglages trop conservateurs qui allongent la récupération. Il faut de la finesse : un « tuning » maladroit ne fait que déplacer les symptômes.

# Statistiques client NFS (Linux)
nfsstat -c

# Vérifier les options de montage et la version NFS
mount | egrep -i " nfs "
cat /proc/mounts | egrep -i " nfs "

Approches de tuning efficaces en pratique

Les mesures suivantes sont formulées de manière à pouvoir être justifiées et testées dans des processus de changement. Toutes ne conviennent pas à tous les environnements ; l’essentiel est d’adresser à chaque fois un symptôme concret.

1) Découpler et limiter les migrations (concurrency et bande passante)

Un classique : plusieurs migrations live simultanées génèrent des pics de trafic qui saturent temporairement les files d’attente des commutateurs et les frontends de stockage. Cela ressemble alors à une « plötzliche Latenz ». La mesure souvent la plus efficace est simple sur le plan organisationnel/technique : moins de migrations parallèles et une limitation de bande passante pour le trafic de migration, afin que le trafic de stockage ne soit pas affamé.

Pourquoi cela fonctionne : vous réduisez les microbursts et stabilisez la latence des files d’attente. Dans de nombreuses environnements, une migration un peu plus longue mais régulière est nettement préférable à une migration courte avec des pics violents et du Stun.

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

Si vous utilisez des Jumbo Frames : vérifiez la MTU de bout en bout (Host-NIC, vSwitch/Bridge, switchports, uplinks, storage-ports). Un segment à 1500 dans un chemin à 9000 provoque de la fragmentation ou des drops. Pour les protocoles de stockage, c’est rédhibitoire.

# 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>

Si les retransmits / out-of-order sont élevés, examinez en plus le hashing LACP/MLAG et les chemins asymétriques. Un bonding « fonctionnel » peut néanmoins fortement fluctuer si le hashing et les profils de trafic se combinent de manière défavorable.

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

L’objectif n’est pas un « maximal aggressives Failover », mais un comportement prévisible. Des timeouts trop courts peuvent déclencher des changements de chemin inutiles lors de courts pics ; des timeouts trop longs rendent les vraies pannes pénibles. Vérifiez également si un chemin est durablement dégradé (erreurs CRC, niveau lumineux sur FC, transceivers défectueux, câbles endommagés) et compromet ainsi l’équilibrage de charge.

Règle pratique : avant de modifier des paramètres, stabilisez la physique (câbles/optique/ports), puis seulement les politiques logicielles.

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

Les live-migrations tombent souvent dans des fenêtres de maintenance – et c’est précisément là que s’exécutent aussi des tâches côté stockage : rebuilds, scrubs, consolidation de snapshots, mouvements de tiering. C’est techniquement légitime, mais risqué opérationnellement si tous les pics de charge coïncident. Planifiez les fenêtres de migration de sorte que les jobs d’arrière-plan du stockage soient soit terminés, soit limités. Si l’array supporte la QoS (Quality of Service) ou la priorisation, utilisez-les pour les datastores critiques.

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

Si certaines VMs « cassent » les migrations par leurs écritures, des mesures simples aident parfois : mettre en pause les jobs batch pendant la migration, décaler le checkpointing des bases de données, vérifier les intervalles de flush des logs. Il ne s’agit pas de « tordre » les applications, mais de réduire durant la phase critique le taux de pages modifiées et les pics I/O.

Praxis-Runbook: Messung, Testmigration, Korrelation

La procédure suivante est délibérément formulée comme une checklist réutilisable. L’objectif est une piste d’audit : vous pourrez ensuite retracer pourquoi un changement a aidé (ou non).

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
# Terminal A : métriques E/S
iostat -x -d 1 300

# Terminal B: Kernel-Events (Storage/Netz)
# Terminal B : événements noyau (Stockage/Réseau)
journalctl -k -f

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

3) Testmigration durchführen und Zeitpunkt notieren

Notez début/fin, nom de la VM, hôte source/destination, Datastore/LUN et les migrations parallèles en cours. Ces métadonnées simples vous feront gagner des heures ensuite.

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)

Ce n’est que lorsque vous pouvez répondre précisément à ces trois points que l’optimisation est ciblée. Tout le reste relève du „Trial and Error“.

Risiken und Nebenwirkungen beim Tuning

De nombreuses modifications de performance comportent des compromis. Trois risques typiques :

• Zu aggressive Timeouts : Des timeouts trop agressifs peuvent provoquer des basculements inutiles lors de pics brefs (plus d’instabilité au lieu d’en réduire).
• Übermäßiges Bandbreitenlimit : Une limitation excessive de la bande passante stabilise certes la latence, mais prolonge les migrations au point de faire échouer les fenêtres de maintenance.
• QoS falsch eingesetzt : Une mauvaise utilisation de la QoS peut affamer d’autres charges ou simplement déplacer la latence (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

Une bonne stratégie d’exploitation admet que tous les environnements ne permettent pas de migrer une VM à chaud à tout moment. Définissez à l’avance quand interrompre et comment procéder en toute sécurité :

• 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

En cas de Live-Migration avec stockage partagé, ce n’est que rarement « l’hyperviseur » qui décide seul du succès ou de l’échec. Ce qui importe, c’est que les chemins de stockage et de réseau fournissent, sous la charge de migration, une latence prévisible et faible et que vos opérations identifient et atténuent les causes typiques de pics (files d’attente, retransmissions, path-flaps, tâches en arrière-plan). Si vous corrélez systématiquement les métriques au niveau de l’hôte, du réseau et du stockage, le ressenti « la migration est parfois lente » devient un constat clair — et il en résulte un réglage qui restera efficace des mois plus tard.

Pour ce sujet, la mesure de la latence de stockage et la latence vMotion sont également importantes. L’article met ces aspects en perspective de manière compréhensible et montre ce qui compte au quotidien.