Dans cette migration, le coordinateur de migration migre uniquement la configuration de pare-feu distribué de NSX Data Center for vSphere vers NSX-T Data Center.

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 les procédures Créer des groupes de machines virtuelles pour la migration de la charge de travail et Migrer les VM de charge de travail (cas complexe)).

À partir de NSX-T 3.1.1, la migration d'un déploiement de site unique NSX for vSphere 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 for vSphere est migré vers un environnement de site unique NSX-T (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 du coordinateur de migration.

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

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

Important : Lorsque vous utilisez l'approche « lift-and-shift » pour migrer la configuration DFW de NSX-v vers NSX-T, vous devez exécuter le mode de migration « DFW uniquement » du coordinateur de migration une seule fois. Une fois que la configuration DFW est migrée vers NSX-T, 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

  • Configuration pour la version logicielle :
    • Les versions 6.4.4, 6.4.5, 6.4.6, 6.4.8 et ultérieures de NSX-v sont prises en charge.
    • NSX-T Data Center version 3.1 ou version ultérieure.

      NSX-T 3.1 prend en charge cette migration uniquement avec des API. La migration avec l'interface utilisateur est disponible à partir de NSX-T 3.1.1.

  • Une nouvelle instance de NSX-T Data Center est préparée pour cette migration et un pont de couche 2 est préconfiguré pour étendre le commutateur logique VXLAN dans NSX-v au segment de superposition dans NSX-T Data Center.
    Pour des instructions détaillées, reportez-vous aux sections :
  • Aucune règle DFW définie par l'utilisateur n'existe déjà dans l'instance de NSX-T Data Center de destination 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.
  • La version d'exportation du pare-feu distribué doit être définie sur 1 000 sur les hôtes NSX-v. Vous devez vérifier la version d'exportation et la mise à jour si nécessaire. Pour plus d'informations, reportez-vous à la section Configurer la version d'exportation du filtre du pare-feu distribué sur des hôtes.
  • Tous les hôtes du cluster géré par NSX (NSX-v et NSX-T) 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-T. 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-T.
  • Ce guide explique le workflow de migration de DFW uniquement dans l'interface utilisateur du coordinateur de migration. Si vous utilisez NSX-T 3.1, cette migration est prise en charge uniquement avec des API NSX-T. Pour migrer à l'aide d'API, reportez-vous aux appels d'API qui sont expliqués dans la section Processus de migration « lift and shift » de l'article de la zone technique de NSX.
  • En mode de migration DFW uniquement du coordinateur de migration, 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 vCenter Server unique ou entre des serveurs vCenter Server. En outre, l'appartenance dynamique dans les règles de pare-feu est conservée lorsque le coordinateur de migration migre les balises de sécurité 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-T, si nécessaire.
  • Dans NSX-T, 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-T, vous ne pouvez pas migrer de nouveau les machines virtuelles de charge de travail de NSX-T 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-T, 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-T. 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-T 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.