Cette section présente les modes de migration avancés que vous pouvez utiliser pour migrer des parties spécifiques de votre environnement NSX-V sans avoir besoin de déployer un matériel supplémentaire, tel que des clusters de calcul distincts, dans votre environnement NSX-T de destination.
Par exemple : votre organisation peut préférer créer une nouvelle topologie NSX-T et configurer manuellement les dispositifs Edge NSX-T et d'autres services de mise en réseau sans utiliser le coordinateur de migration. Par exemple, vous pouvez déployer des nœuds NSX-T Edge sur des hôtes NSX-V existants.
Votre objectif est d'utiliser le coordinateur de migration pour migrer uniquement la configuration de pare-feu distribué (DFW) existante et les hôtes de calcul NSX-V vers NSX-T. Vous voulez que les machines virtuelles de charge de travail continuent de fonctionner sur le matériel de calcul existant avec une interruption minimale de la protection de la sécurité du trafic est-ouest lors de la migration vers le nouvel environnement NSX-T.
Comme vous effectuez une migration sur place uniquement des hôtes de configuration DFW et de calcul, vous pouvez définir votre propre topologie NSX-T. En d'autres termes, les topologies fixes prises en charge mentionnées dans Topologies fixées prises en charge pour la migration de bout en bout ne sont pas pertinentes pour cette migration sur place.
Vous pouvez activer vSphere High Availability (HA) si VDS 7.0 ou version ultérieure est installé dans l'environnement NSX-V. Si l'environnement NSX-V dispose de VDS 6.5 ou 6.7, et si les ports vmkernel (vmks) sont attachés aux VDS, lors d'une migration sur place, les hôtes et les VM peuvent perdre la connectivité réseau pendant une période suffisamment longue pour déclencher HA. Le mécanisme HA tente de mettre hors tension, de migrer et de redémarrer les VM. Cela peut échouer, car l'environnement NSX-V est en cours de migration vers NSX-V. Par conséquent, après la migration, les VM peuvent rester dans un état hors tension ou n'avoir aucune connectivité réseau si elles sont sous tension. Pour éviter cette situation, désactivez HA ou attachez le port vmk de gestion à un VSS avant de démarrer la migration vers NSX-T.
Remarque : les ports et commutateurs logiques créés pendant la migration ne sont pas supprimés lors de la suppression des VM de charge de travail. Vous devez supprimer ces ports et ces commutateurs via l'interface utilisateur ou l'API de NSX Manager.
- Les dispositifs Edge NSX-V et NSX-T se trouvent sur des hôtes ESXi différents.
- Les machines virtuelles de charge de travail directement connectées à une passerelle ESG (Edge Services Gateway) se trouvent sur un hôte ESXi différent de celui de la passerelle ESG.
Pour cette migration, si vous prévoyez ou avez besoin de migrer manuellement des machines virtuelles de certains hôtes NSX-V vers des hôtes NSX-T, vous devez configurer la version d'exportation du Pare-feu distribué (reportez-vous à la section Configurer la version d'exportation du filtre de pare-feu distribué).
Si l'environnement NSX-V dispose de la version 7.0 de VDS ou d'une version ultérieure, vous devez activer et configurer DRS pour chaque cluster NSX-V à migrer. Sous Automatisation, définissez Niveau d'automatisation sur Entièrement automatisé. Pour empêcher DRS de migrer automatiquement une machine virtuelle à partir d'un hôte NSX-V vers un hôte NSX-T avant que le processus de migration ne commence à migrer l'hôte NSX-V, sous Automatisation, définissez Seuil de migration sur l'option la plus conservatrice. De plus, sous Options supplémentaires, n'activez pas Distribution de VM. Une fois la migration d'un cluster vers NSX-T terminée, vous pouvez modifier Seuil de migration pour le définir sur une option agressive et activer Distribution de VM sous Options supplémentaires afin que DRS équilibre les VM entre les hôtes.
