Migration à chaud KVM sans stockage partagé : réplication de blocs, cohérence et minimisation des temps d'arrêt

La migration KVM en direct sans stockage partagé est un défi récurrent dans les centres de données hétérogènes, sur des sites Edge et lors de changements matériels planifiés, lorsque aucun SAN central ou backend de stockage distribué comme Ceph n’est disponible. Le mot-clé principal KVM-Live-Migration ohne Shared-Storage figure donc dès le début : dans cet article j’explique de manière pragmatique quels modèles techniques de réplication de blocs existent, comment assurer la cohérence au niveau du système de fichiers et des applications et comment réduire le temps d’indisponibilité à quelques secondes. Le public visé est constitué d’administrateurs, d’ingénieurs système et d’exploitants qui planifient, testent et exploitent des migrations.

Concepts clés : que signifie « sans stockage partagé » et quelles options existe-t‑il ?

« Sans stockage partagé » signifie : l’hôte source et l’hôte cible ne se partagent pas de périphériques blocs persistants via un backend de stockage commun. Par stockage partagé on entend des systèmes centraux comme SAN, NFS ou des backends distribués qui exposent au deux hôtes le même LUN ou le même device RBD. En l’absence de cela, les blocs disque doivent être synchronisés activement entre les hôtes.

Les modèles usuels sont :

• Réplication de blocs au niveau bloc (DRBD ou basé sur NBD).
• Migration de stockage assistée par Libvirt/QEMU (copy-storage-all, block-copy, postcopy).
• Méthodes orientées système de fichiers (snapshots LVM + rsync pour les fichiers d’image des guests).

Chaque modèle implique des exigences différentes en termes d’exploitation, de réseau, de supervision et de stratégie de retour en arrière.

Migration KVM en direct sans stockage partagé : variantes d’architecture

DRBD : réplication au niveau bloc

DRBD (Distributed Replicated Block Device) réplique des périphériques blocs entre hôtes en amont du système de fichiers. Il peut fonctionner en mode synchrone (protocole C, garantit chaque écriture), semi-synchrone (protocole B) ou asynchrone (protocole A). Avantage : pour la VM, le périphérique reste visible localement et le basculement peut être très court. Inconvénient : charge opérationnelle liée au fencing (exclusion automatique d’un hôte défaillant), à la prévention du split‑brain et aux contrôles réguliers de resynchronisation.

# 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

Important pour l’exploitation : le fencing (séparation externe d’un hôte défaillant) et une supervision des resynchronisations sont impératifs. Sans fencing, une partition réseau peut provoquer un split‑brain — les deux côtés se considèrent Primary et des états d’écriture divergents devront être fusionnés manuellement.

Exemple de configuration DRBD (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;
  }
}

Pourquoi cette configuration : le protocole C garantit qu’une écriture n’est considérée comme réussie que lorsqu’elle a été enregistrée des deux côtés — crucial pour des exigences Zero-RPO. En cas de latences élevées, le protocole C affecte toutefois la latence perçue par l’application.

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

Libvirt peut copier le stockage de machines virtuelles en cours d’exécution. Le mode par défaut est une approche Pre-copy : copie initiale du volume, copies incrémentielles ultérieures des blocs modifiés et basculement final. Postcopy est un mode dans lequel la VM est démarrée sur la cible et les blocs manquants sont chargés à la demande via le réseau. Postcopy réduit la fenêtre de basculement, mais est plus sensible à la perte de paquets ou à la défaillance de l’hôte source.

# 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

Conseil pratique : n’utiliser le Postcopy que sur un réseau contrôlé et après des tests de charge. Testez des scénarios de basculement (p. ex. perte d’un paquet ou interruption brève) avant de le déployer en production.

Snapshot LVM + rsync (basé sur image)

Si les disques VM sont des fichiers (qcow2/raw) sur l’hôte, un instantané LVM est une méthode pragmatique pour produire une image cohérente. Ensuite, synchronisez via rsync vers l’hôte de destination. Les inconvénients sont des temps d’arrêt prolongés lors de la synchronisation finale et d’éventuelles incohérences en l’absence de 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

Exigences de cohérence : qui doit forcer l’écriture de quoi et pourquoi ?

La cohérence signifie que l’image cible représente un état que les systèmes de fichiers et les applications peuvent interpréter correctement. On distingue la cohérence au niveau des blocs (tous les blocs sont dans un état cohérent), la cohérence du système de fichiers (métadonnées et journal corrects) et la cohérence applicative (p. ex. transactions complètes de base de données).

Mécanismes essentiels pour y parvenir :

• QEMU Guest Agent : guest-fsfreeze pour geler temporairement les systèmes de fichiers dans la VM invitée.
• Hooks spécifiques aux applications : WAL-Switch pour PostgreSQL, commandes de flush pour d’autres SGBD.
• Instantanés du système de fichiers (LVM/XFS/Btrfs) pour des images atomiques.

# 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"}'

Runbook de migration concret (étape par étape)

Un runbook clair et concis réduit les erreurs pendant les phases de basculement. Voici une procédure pragmatique pour une migration en Pre-copy avec quiesce via Guest‑Agent :

1. Préparation : vérification des versions de QEMU/libvirt, contrôles d’espace disque, test réseau (iperf), monitoring activé.
2. Lancer la copie initiale du volume (Pre-copy).
3. Lancer plusieurs copies incrémentielles ; surveiller jusqu’à ce que le taux de modifications (dirty rate) soit faible.
4. Quiesce du guest : guest-fsfreeze + flush applicatif.
5. Dernière synchronisation incrémentielle et cutover (arrêter la VM sur la source et démarrer sur la cible ou basculement à chaud via libvirt).
6. Vérifications post-basculement : contrôles du système de fichiers, état des applications, comparaison des métriques de monitoring.
7. Lorsque tout est stable : supprimer l’instantané / la sauvegarde sur la cible et marquer la cible comme productive.

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

Documentez les responsabilités pour chaque étape (qui exécute guest-fsfreeze, qui déclenche le DB-Flush, qui surveille les logs).

Stratégie de rollback et de récupération

Un rollback doit être possible rapidement et en toute sécurité. Principes importants :

• Conserver un point de restauration (Snapshot ou Backup) avant le Cutover final.
• Définir des timeouts : si le Cutover dure plus de X minutes, interrompre et revenir sur la source.
• Changement de rôle avec DRBD : commandes claires et listes de contrôle pour la promotion/démotion.

# 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

Si vous devez annuler une migration libvirt, documentez si la cible a déjà modifié des parties du disque. Un schéma fréquent : arrêter la VM sur la cible, conserver le Snapshot sur la cible, laisser la VM tourner sur la source et effectuer une analyse des causes.

Tests de postcopy avec simulation de panne réseau

Avant l’utilisation en production de postcopy, vous devriez simuler des erreurs réseau. Utilisez tc (Traffic Control) pour introduire latence, perte de paquets ou interruptions de connexion :

# 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

Déroulement du test : lancez une migration postcopy sur le réseau de test, injectez des erreurs réseau et observez si la VM sur la cible reste stable ou si des blocs manquants provoquent des erreurs. Consignez les temps de réaction et les étapes de récupération.

Monitoring, métriques et alertes

Métriques pratiques à surveiller :

• Taux de dirty (taux de modification des disques de la VM) — influence le nombre de cycles de Pre-copy.
• Octets incrémentiels par job et octets restants (über virsh domjobinfo).
• Débit réseau et latence sur le réseau de migration (iperf, SNMP).
• Statut de Resync DRBD et éventuels Backlogs.
• État du Guest-Agent, état des processus et des services dans le guest (via monitoring agent).

Alertes concrètes : si le Pre-copy dure plus que prévu, si dirty-rate > X MB/s über Y Minuten bleibt, si DRBD Resync fällt oder Split-Brain erkannt wird.

Tuning de performance: paramètres qui aident réellement

Quelques approches de tuning pratiques :

• Choix du protocole DRBD : Protocol C pour la consistance, A/B pour une latence plus faible — choisir en fonction des exigences RPO.
• Options I/O QEMU : cache=none, io=native réduisent les effets de cache côté hôte pendant la copie.
• Pour qcow2 : vérifier si une conversion temporaire en raw réduit le temps de copie — tenir compte du besoin supplémentaire d’espace disque.
• Réseau : VLAN de migration dédié, QoS ou liaison physique séparée pour de grands volumes de données.

Pièges typiques et comment les éviter

• Guest Agent absent ou obsolète : testez guest-fsfreeze / thaw avant la migration.
• Taux de modification sous-estimé : mesurez le dirty-rate en amont, prévoyez plusieurs cycles de Pre-copy.
• Chemin réseau surchargé : définir un réseau de migration séparé ou une politique QoS.
• DRBD sans fencing : testez la récupération en cas de split‑brain et déployez SBD/STONITH.
• Incompatibilités de versions qemu/libvirt : comparer les versions au préalable et effectuer des tests de migration.

Liste de contrôle avant la migration en production

1. Sauvegarde : présence d’une sauvegarde récente et validation effectuée.
2. Contrôle de compatibilité : modèles CPU, versions QEMU/libvirt, formats d’image.
3. Vérification réseau : latence, bande passante, QoS configurée.
4. Agent invité et hooks applicatifs vérifiés.
5. Monitoring et alerting pour les métriques de migration activés.
6. Runbook de rollback connu et validé par les membres de l’équipe.
7. Dry-run effectué en staging.

Conclusion : critères de sélection et maturité opérationnelle

Choisissez DRBD si vous avez besoin de courts temps de bascule (cutover) et si vous êtes prêts à opérer des processus d’exploitation pour le fencing et la gestion du split‑brain. Choisissez libvirt –copy-storage-all / block-copy pour des migrations ponctuelles sans infrastructure de stockage supplémentaire, à condition que le réseau et les tests soient satisfaisants. Les snapshots LVM combinés à rsync conviennent aux scénarios avec fenêtres de maintenance prévisibles et des exigences de downtime moins strictes.

La maturité opérationnelle est essentielle : testez chaque méthode dans un environnement de staging avec un profil IO comparable, documentez les runbooks, automatisez les pré-checks et conservez l’intervention manuelle pour les phases de cutover. Ce n’est qu’ainsi que vous réduirez la downtime des workloads critiques au minimum tout en conservant le contrôle sur la consistance et la récupération.

Avec des tests systématiques, des stratégies claires de vérification et de repli ainsi qu’un monitoring, vous pouvez opérer des migrations KVM en direct sans stockage partagé de manière sûre et fiable.

Migrations KVM en direct sans stockage partagé : exploitation, sécurité et orchestration

Au-delà de la seule technique de réplication de blocs, l’exploitation, la sécurité et l’orchestration déterminent le succès des migrations en production. Les points suivants complètent les schémas techniques précédents par des règles opérationnelles pratiques, des aspects d’intégration et des approches d’automatisation qui se sont avérées efficaces dans des projets de logiciel d’entreprise sur mesure et de services critiques.

Aspects sécurité et conformité

Le trafic de réplication et de migration transporte l’état complet des VM. Protégez ces données strictement : chiffrement en transit (IPsec, WireGuard ou tunnel TLS) et authentification des pairs sont obligatoires, en particulier pour la réplication asynchrone. Pour des VMs chiffrées (LUKS), définissez la gestion des clés : l’hôte cible doit disposer du matériel clé ou d’un mécanisme de déverrouillage à distance avant le cutover. Une erreur fréquente est de lancer la migration et de ne découvrir les problèmes de clé qu’au démarrage sur la cible.

• Recommandation : réseau de migration dédié avec ACLs et VPN ; activer le logging pour les pistes d’audit.
• Pour DRBD : ne laissez pas les ports de gestion exposés sur le réseau ; mettre en place un contrôle d’accès et une authentification pour le monitoring.

Migration cohérente de plusieurs VM ou de clusters

Les applications distribuées (p. ex. clusters de bases de données, caches distribués) nécessitent des migrations coordonnées. Procédure en bref :

1. L’orchestrateur/runbook déclenche des quiesce-hooks programmés sur toutes les VM concernées (flush applicatif, Guest-Agent).
2. Les incréments de pré-copy s’exécutent jusqu’à ce que le taux de pages modifiées (dirty rate) diminue.
3. Quiesce final et cutover synchrone de tous les nœuds avec timeouts définis.

Sans coordination, vous risquez un split-brain au niveau applicatif ou des transactions incohérentes. Un simple jeton mutex (p. ex. dans etcd) réduit le risque, car le basculement ne doit être effectué que si tous les nœuds ont confirmé.

Automatisation : petit exemple d’orchestration

Des hooks automatisés réduisent les erreurs manuelles. Ci‑dessous un task Ansible minimal qui orchestre guest-fsfreeze et un DB-Flush (modèle à adapter à votre environnement) :

- 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"}'

L’automatisation doit être idempotente et disposer de chemins clairs de gestion d’erreurs : en cas d’erreur, déclencheurs de rollback et notification à l’équipe d’astreinte.

Planification de capacité et calcul des SLA

Planifiez les migrations avec une formule simple : durée estimée ≈ (volume initial de données / bande passante nette disponible) + (données de modifications cumulées estimées / bande passante) + temps de basculement. Mesurez au préalable le Dirty‑Rate et utilisez ces valeurs pour définir des fenêtres réalistes. Définissez des seuils d’alerte : si la pré-copy dure plus longtemps que prévu ou si le Dirty‑Rate reste au‑dessus du seuil, annulation automatique ou escalade.

Validation après migration

Après le basculement, ne vérifiez pas seulement que la VM est opérationnelle, mais validez les transactions applicatives, les contrôles d’intégrité (checksums, DB-Health) et les métriques de latence/débit par rapport aux baselines. Automatisez des smoke-checks et comparez la télémétrie avant de désactiver définitivement la source.

Ces compléments aident à intégrer les KVM-Live-Migrationen sans stockage partagé dans le contexte opérationnel : sécurité, orchestration coordonnée et SLA mesurables rendent les migrations prévisibles et auditables.

Pour ce sujet, les Libvirt Copy-Storage-All sont également importants. L’article situe ces aspects de manière compréhensible et montre ce qui compte au quotidien.