Migration des données de machines virtuelles VMware
Explorez la migration des données de machines virtuelles VMware vers KVM avec ou sans agent
Introduction à la technologie en ligne pour minimiser les interruptions lors des transferts
Dans le paysage numérique actuel, rapide et exigeant, remplacer une plateforme de virtualisation VMware ne se limite pas à une simple mise à niveau technologique. C’est un véritable enjeu stratégique : la moindre erreur peut provoquer des interruptions de service, des pertes de données, voire un chaos opérationnel.
Pourtant, lorsqu’elle est bien planifiée et exécutée, la migration devient une passerelle vers une infrastructure moderne et agile, prête à soutenir les innovations futures.
Dans ce guide, découvrez les technologies, méthodes, outils et meilleures pratiques pour réussir la migration en ligne des machines virtuelles VMware, en limitant les risques et en assurant la continuité de vos activités.
1. Contexte de la technologie de migration des données de machines virtuelles
La plupart des plateformes de virtualisation modernes reposent aujourd’hui sur la technologie KVM, qui utilise le format QCOW2 pour les disques virtuels. À l’inverse, VMware ESXi fonctionne avec le format VMDK, non compatible nativement avec KVM.
Ainsi, la migration implique une conversion complète des fichiers VMDK vers QCOW2, tout en garantissant :
L’intégrité des données,
La stabilité des systèmes migrés,
Une continuité d’exploitation sans interruption.
Scénarios de déploiement VMware courants :
vSphere avec stockage FC ou iSCSI (désagrégé)
vSphere avec stockage vSAN (intégré)
Dans les deux cas, la stratégie de migration reste la même : une plateforme de destination ne peut pas lire directement les fichiers VMDK, nécessitant un transfert de données réseau, accompagné d’un espace de stockage suffisant et d’une liaison stable.
VMware propose une option d’exportation et d’importation des machines virtuelles au format OVA. Cependant, cette méthode exige que la machine virtuelle soit arrêtée pendant toute la durée du processus, ce qui devient de moins en moins pratique avec l’augmentation des exigences de continuité des activités. En conséquence, cette méthode a été progressivement remplacée par des solutions de migration en ligne utilisant un transfert initial complet suivi de mises à jour incrémentielles continues.
La méthode de migration dominante aujourd’hui utilise un modèle de transfert initial complet + transmission incrémentielle continue, permettant une migration en ligne sans affecter l’état d’exécution de la machine virtuelle. En augmentant la fréquence des transferts, le volume de données différentiels est réduit, garantissant la cohérence des données en synchronisant les dernières données différentielles avant le basculement.
Méthodes et technologies de migration
Migration sans agent basée sur l’interface VDDK :
- Migration gérée via la plateforme cloud/virtualisation Sangfor
Utilise la plateforme de virtualisation Sangfor pour gérer vCenter et exécuter la migration des données. - Migration point à point sans agent avec SCMT
Utilise l’outil de migration Sangfor (SCMT) pour interagir avec vCenter lors de la migration des données.
Migration avec agent basée sur la copie du système de fichiers OS :
- Migration point à point avec agent SCMT
Utilise un outil de migration avec plugin agent pour la migration basée sur le système de fichiers. - Migration par sauvegarde à chaud avec agent SCMT
Utilise un outil de migration avec plugin agent, s’appuyant sur la technologie CDP (Continuous Data Protection).
2. Migration des données de machines virtuelles via l’interface VDDK (sans agent)
La technologie de migration sans agent exploite les plateformes de virtualisation ou outils de migration interfacés avec l’API VDDK de vCenter. Elle émet des commandes de snapshot et de transmission des données à ESXi. Pendant la migration complète, les snapshots capturent et transmettent toutes les données, tandis que la migration incrémentielle utilise les snapshots pour comparer et transférer uniquement les données modifiées.
Après la transmission vers la plateforme cible, la plateforme de virtualisation convertit le format VMDK en QCOW2, permettant la compatibilité avec le système de destination. Lors de la conversion, le système injecte des pilotes, installe VMtools et optimise les configurations système, garantissant que les données sources soient utilisables sans problème par la machine virtuelle.
Avantages :
- Opération simple — les utilisateurs n’ont pas besoin d’un environnement de migration complexe et peuvent se fier à l’intégration standard via API.
Inconvénients :
- Comme cette méthode repose sur les snapshots, chaque transmission nécessite la création et la suppression de snapshots, dégradant significativement les performances en lecture/écriture des fichiers VMDK, ce qui peut impacter les opérations en cours.
- L’interface VDDK est fournie par vCenter, non ESXi, nécessitant un déploiement vCenter dans la ressource VMware.
- Les différentes versions de vCenter ont des comportements API variables, il est donc crucial de vérifier la compatibilité entre versions vCenter et ESXi avant migration.
2.1 Migration des données de machines virtuelles gérée par Sangfor (sans agent)
La plateforme cloud/virtualisation Sangfor supporte nativement la gestion VMware, permettant la migration via vCenter sur les ports 443 et 902. Cela permet des migrations par lots avec les machines virtuelles allumées, qui sont arrêtées uniquement lors de la phase finale pour compléter la migration — similaire à vMotion, assurant un processus simple et efficace.
Cette approche est intégrée à la plateforme de gestion opérationnelle et de maintenance classique. Pendant la migration, il n’est pas nécessaire de déployer des outils spécifiques ni de configurer des environnements réseau complexes, ni d’installer de plugins agents. Cette méthode convient aux besoins de migration par lots d’applications indépendantes. Cependant, elle ne permet pas de modifications de configuration pendant la migration et nécessite un basculement manuel ou automatique avec la VM source arrêtée. Pour un contrôle plus fin (comme ajustements de configuration, déduplication ou limitation de bande passante), l’outil SCMT est recommandé.
2.2 Outil de migration sans agent Sangfor
Sangfor propose l’outil de migration SCMT, utilisant la même technologie sans agent basée sur VDDK pour interagir avec vCenter et exécuter les tâches de migration. Par rapport à la migration gérée, SCMT offre des capacités supplémentaires, incluant l’ajustement de la configuration, la programmation des basculements, et la vérification des machines virtuelles, rendant le processus adapté à un plus large éventail de scénarios.
L’outil SCMT supporte le déploiement sur la plateforme cloud/virtualisation Sangfor, permettant d’exécuter les tâches sans ressources matérielles physiques supplémentaires. Il offre une interface visible pour toute la procédure, avec des alertes de risque plus complètes. Lors de la création d’un nouveau plan, il optimise les ressources système, adresses IP/MAC, et configurations applicatives, éliminant le besoin de redémarrages multiples lors de changements.
Le basculement post-migration ne requiert pas d’arrêter le système source, rendant la migration plus sûre et les risques mieux maîtrisés. Il supporte les basculements manuels, programmés, et en lot, convenant aux scénarios de migration sans surveillance et hors clusters de bases de données.
3. Copie de données basée sur le système de fichiers OS (avec agent)
La migration avec agent installe un plugin dans l’OS source pour lire directement les blocs du système de fichiers. Pendant la migration complète, l’agent lit tous les blocs et surveille en continu les changements pour la migration incrémentielle. Les données transmises sont directement sauvegardées au format QCOW2, évitant la conversion de format disque.
Avantages :
- Lecture directe des blocs disque, évitant conversions complexes et problèmes de compatibilité, réduisant les risques d’échec.
- Ne dépend pas des snapshots, évitant la dégradation des performances.
- Fréquence élevée des transferts de données, minimisant les interruptions.
Inconvénients :
- Nécessite l’installation d’un agent sur chaque système, augmentant la charge opérationnelle.
- Consomme des ressources CPU et mémoire du système source pendant le transfert.
En utilisant la migration avec agent, il faut vérifier la compatibilité du système de fichiers de l’OS avec l’agent pour éviter des problèmes de lecture. Il est aussi important de réserver suffisamment de CPU et mémoire pour ne pas affecter les applications métier.
3.1 Migration des données de machines virtuelles point à point avec agent Sangfor
L’outil SCMT de Sangfor supporte la copie et migration des systèmes de fichiers via le plugin agent. Après installation de l’agent sur l’OS source, celui-ci se connecte au serveur SCMT pour recevoir les tâches et commandes de transfert via l’interface SCMT.
Il facilite le transfert complet et incrémentiel en lisant les blocs disque dans l’OS. L’agent minimise l’impact sur le système source et améliore l’efficacité.
Le plugin occupe moins de 3 % de CPU et moins de 260 Mo de mémoire pendant le transfert, rendant l’impact négligeable. L’agent permet un transfert incrémentiel à la minute, réduisant les interruptions à 5-10 minutes, adapté aux applications à haute continuité. Par rapport à la sauvegarde sans agent, cette méthode évite l’impact des snapshots, idéale pour les bases de données sensibles. En plus, elle peut migrer des données brutes de disque ou volumes pass-through, impossible avec la méthode sans agent.
3.2 Migration des données de machines virtuelles par sauvegarde à chaud avec agent Sangfor
L’outil SCMT propose une migration par sauvegarde à chaud basée sur la technologie CDP (Continuous Data Protection). Avec l’agent, il sauvegarde les données complètes et les changements par seconde vers le serveur SCMT. Ensuite, par le plan de sauvegarde à chaud, les données sont poussées vers la plateforme cible. Après réception, la cible génère une nouvelle machine virtuelle métier, complète l’injection de pilotes, ajuste la configuration et entre en état semi-démarré, synchronisant les changements par seconde avec la source. Lors du basculement, la VM semi-démarrée peut rapidement compléter la prise en charge du réseau (IP drift) et assurer la reprise métier, réduisant encore plus le temps d’interruption.
Le mode de migration à chaud utilise le CDP pour synchroniser en temps réel les données différentielles, réduisant le temps de transfert à quelques secondes. Le système cible passe de l’état semi-démarré à opérationnel et prend le relais en moins de 30 secondes. Le drift IP automatique évite les interruptions réseau et la reconfiguration, réalisant le basculement en environ 1 minute, idéal pour les scénarios à haute continuité.
Cependant, comparé à la migration point à point, le processus est plus complexe. Il nécessite l’installation des plugins sur l’OS source, la conception de stratégies de sauvegarde CDP, la planification de la migration à chaud, la réservation d’espace de sauvegarde pour le serveur SCMT, et l’installation manuelle de l’environnement PE sur la cible. Par conséquent, la migration point à point est généralement recommandée pour les scénarios courants, tandis que la migration à chaud s’adresse aux cas particuliers.
4. Comparaison des méthodes de migration
| Sans agent | Avec agent | |
|---|---|---|
| Différences techniques | Ne nécessite pas l’installation de plugins sur le système d’exploitation source | Nécessite l’installation de plugins sur le système d’exploitation source pour la migration |
| S’appuie sur les interfaces de vCenter, environnement simple | Repose sur des outils de migration spécialisés, matrice de communication plus complexe | |
| Basé sur des instantanés, affecte les performances de lecture/écriture de la source | Ne peut pas migrer les disques bruts / données en LUN pass-through | |
| Surcharge de ressources du plugin minimale, impact négligeable | Prend en charge la migration de tout espace pouvant être formaté par le système d’exploitation |
| Migration gérée | Migration avec outil SCMT | Migration point-à-point | Migration avec sauvegarde à chaud | |
|---|---|---|---|---|
| Environnement de migration | Ne nécessite pas le déploiement d’outils de migration, environnement simple | Nécessite le déploiement d’outils de migration, environnement plus complexe | Nécessite le déploiement d’outils de migration, le plugin doit être installé sur la source | Le plugin est installé sur la source, préparation du PE cible |
| Processus de migration | Entièrement automatisé, processus non contrôlable | Processus visible, globalement contrôlable | Processus visible, globalement contrôlable | Processus visible, globalement contrôlable, étapes de configuration relativement complexes |
| Impact sur les performances | Les performances de snapshot externe VMware diminuent de 40 % | Les performances de snapshot externe VMware diminuent de 40 % | État de fonctionnement du plugin : CPU < 3 %, RAM < 260 Mo | État de fonctionnement du plugin : CPU < 3 %, RAM < 260 Mo |
| Temps d’arrêt | 5 à 10 minutes | 5 à 10 minutes | 5 à 10 minutes | 1 à 2 minutes |
- 1. 1. Contexte de la technologie de migration des données de machines virtuelles
- 2. 2. Migration des données de machines virtuelles via l’interface VDDK (sans agent)
- 3. 2.1 Migration des données de machines virtuelles gérée par Sangfor (sans agent)
- 4. 2.2 Outil de migration sans agent Sangfor
- 5. 3. Copie de données basée sur le système de fichiers OS (avec agent)
- 6. 3.1 Migration des données de machines virtuelles point à point avec agent Sangfor
- 7. 3.2 Migration des données de machines virtuelles par sauvegarde à chaud avec agent Sangfor
- 8. 4. Comparaison des méthodes de migration
Réseaux Télécoms
Cloud Infrastructure
Cyber Sécurité
Ressources
©Tous droits réservés CDX Telecom 2021 | Mentions légales | Conditions générales | Blog
