Dans ce mode de migration, vous migrez la configuration du pare-feu distribué (DFW) de NSX-V vers NSX. Si vous avez configuré le pare-feu d'identité (IDFW), il sera également migré.

Pour plus d'informations sur la migration IDFW, reportez-vous à la section Migration du pare-feu d'identité (de bout en bout et « Lift-and-Shift »).

Les configurations d'objets logiques suivantes sont migrées :
  • Règles de pare-feu distribué (DFW) définies par l'utilisateur
  • Regroupement des objets
    • Ensembles d'adresses IP
    • Ensembles d'adresses MAC
    • Groupes de sécurité
    • Services et groupes de services
    • Balises de sécurité
  • Stratégies de sécurité créées à l'aide de Service Composer (seules les configurations de règles DFW sont migrées)

    La configuration du service Guest Introspection et les configurations de règle d'introspection réseau dans Service Composer ne sont pas migrées.

Selon la configuration de DFW, il existe deux façons de migrer les VM de charge de travail après la migration de la configuration DFW. Si l'option « Appliqué à » n'est configurée dans aucune des règles DFW (cela signifie que cette option est définie sur « DFW »), vous pouvez utiliser vSphere Client pour migrer les VM de charge de travail (suivez la procédure Migrer les VM de charge de travail (cas simple)). Sinon, vous devez utiliser un script pour migrer les VM (suivez la procédure Migrer les VM de charge de travail (cas complexe)).

La migration d'un déploiement de site unique NSX-V qui contient un NSX Manager en mode principal, aucune instance secondaire de NSX Manager et des objets universels sur le site principal, est prise en charge. Un tel déploiement de site unique NSX-V est migré vers un environnement de site unique NSX (non fédéré) avec des objets locaux uniquement.

Pour voir une liste détaillée de toutes les configurations prises en charge pour la migration de la configuration de pare-feu distribué, reportez-vous à la section Prise en charge détaillée des fonctionnalités pour la migration.

Vous disposez des objectifs de migration suivants :
  • Migrez uniquement la configuration existante du pare-feu distribué de NSX-V vers NSX.
  • Utilisez un pont Edge de couche 2 et vSphere vMotion pour migrer des machines virtuelles de charge de travail de NSX-V vers NSX.

Pour étendre des réseaux de couche 2, vous pouvez utiliser le pont Edge natif NSX.

Important : Lorsque vous utilisez l'approche « lift-and-shift » pour migrer la configuration DFW de NSX-V vers NSX, vous devez exécuter le mode de migration « DFW uniquement » une seule fois. Une fois que la configuration DFW est migrée vers NSX, vous ne devez pas mettre à jour la configuration DFW dans votre environnement NSX-V et réexécuter le mode de migration « DFW uniquement ». Il n'est pas recommandé d'exécuter plusieurs fois le mode de migration « DFW uniquement ».

Conditions préalables pour la migration de DFW uniquement

  • Un nouvel environnement NSX est préparé pour cette migration.
  • Aucune règle DFW définie par l'utilisateur n'existe dans l'instance de NSX avant cette migration.
  • Tous les états du volet Présentation du système du tableau de bord NSX-V sont verts.
  • Il n'y a aucune modification non publiée pour les stratégies de pare-feu distribué et de Service Composer dans l'environnement NSX-V.
  • Tous les hôtes du cluster géré par NSX (NSX-v et NSX) doivent être connectés à la même version de VDS. Chaque hôte du cluster géré par NSX doit alors être membre d'une version unique de VDS.
Note :
  • La migration « lift and shift » de la configuration de DFW uniquement n'implique pas la migration d'hôtes NSX-V vers NSX. Par conséquent, elle n'est pas obligatoire pour la version d'ESXi utilisée dans votre environnement NSX-V pour être prise en charge par NSX.
  • En mode de migration DFW uniquement, l’état du pare-feu (DVFilter) pour les sessions de connexion existantes est conservé tout au long de la migration, y compris vMotion. L'état du pare-feu est conservé, que les machines virtuelles soient migrées dans un VMware vCenter unique ou entre des serveurs vCenter Server. En outre, l'appartenance dynamique dans les règles de pare-feu est conservée lorsque les balises de sécurité sont migrées vers les machines virtuelles de charge de travail.
  • Les objets qui sont créés pendant la migration ne doivent pas être mis à jour ou supprimés avant la fin de la migration. Cependant, vous pouvez créer des objets supplémentaires dans NSX, si nécessaire.
  • Dans NSX, DFW est activé d'origine. Tous les flux disposant de sources et de destinations sous la forme « any » dans les règles DFW sont autorisés par défaut. Si le pare-feu distribué est activé dans l'environnement NSX, vous ne pouvez pas migrer de nouveau les machines virtuelles de charge de travail de NSX vers NSX-V. La restauration des machines virtuelles de charge de travail migrées n'est pas prise en charge. La solution consiste à ajouter les machines virtuelles de charge de travail à la liste d'exclusion de pare-feu NSX, puis à migrer de nouveau les machines virtuelles de charge de travail vers NSX-V à l'aide de vSphere vMotion.
  • La migration automatisée des configurations DFW prend en charge les machines virtuelles de charge de travail attachées à des commutateurs logiques NSX-v. Ces machines virtuelles seront migrées vers des segments de superposition NSX. Les machines virtuelles de charge de travail dans NSX-v qui sont attachées à des groupe de ports virtuels distribués vSphere ne sont pas automatiquement migrées vers des groupes de ports virtuels distribués NSX. Pour résoudre ce problème, vous devez créer manuellement les groupes de ports virtuels distribués NSX et leur associer les machines virtuelles de charge de travail.
  • Les listes d'exclusion DFW ne sont pas migrées. Vous devez les recréer sur NSX après la migration.
  • 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 segments par défaut dans NSX ne prennent pas en charge les serveurs DHCP et entraînent l'arrêt des serveurs après la migration.