Vous devez vérifier l'état de l'environnement de NSX Data Center for vSphere et corriger les problèmes rencontrés. En outre, selon votre environnement, vous devrez modifier votre configuration de NSX Data Center for vSphere avant que vous puissiez migrer vers NSX-T Data Center.

État du système

Vérifier les états système suivants :

  • Vérifiez que les composants de NSX-v sont dans un état vert sur le tableau de bord de NSX.
  • Vérifiez que tous les hôtes ESXi sont dans un état opérationnel. Résolvez les problèmes impliquant des hôtes, y compris les états déconnectés. Aucun redémarrage ni aucune tâche ne doit être en attente pour passer en mode de maintenance.
  • Vérifiez qu'aucune mise à niveau de NSX-v n'est en cours.
  • Vérifiez l'état de publication du Pare-feu distribué et Service Composer pour vous assurer qu'il n'y a pas de modifications non publiées.

Configuration générale

  • Sauvegardez les environnements NSX-v et vSphere. Reportez-vous à la section « Sauvegarde et restauration de NSX » du Guide d'administration de NSX.
  • Le port VXLAN doit être défini sur 4789. Si votre environnement NSX-v utilise un port différent, vous devez le modifier avant de pouvoir migrer. Reportez-vous à la section « Modifier le port VXLAN » du Guide d'administration de NSX NSX-v.

Configuration du contrôleur

  • Le coordinateur de migration ne prend pas en charge les zones de transport de NSX-v avec le mode de réplication multidiffusion ou hybride. Un cluster NSX Controller est obligatoire si VXLAN est en cours d'utilisation. Les topologies de micro-segmentation reposant sur VLAN n'utilisent pas VXLAN et n'ont donc pas besoin d'un cluster NSX Controller.

Configuration d'hôte

  • Sur tous les clusters d'hôtes de l'environnement NSX-v, vérifiez ces paramètres et mettez-les à jour si nécessaire :
    • Définissez un DRS de vSphere en conséquence.

      Désactivez un DRS de vSphere si l'un des éléments suivants s'applique :

      • Le mode de migration Sur place sera utilisé.
      • Le mode de migration Maintenance manuelle sera utilisé. Voir la note ci-dessous.
      • Si le mode de migration Maintenance automatique sera utilisé pour la migration et que la version de vCenter Server est 6.5 ou 6.7.
      • Note : Dans le mode de migration Maintenance manuelle , si vous décidez d'utiliser vMotion pour migrer des machines virtuelles, vous avez la possibilité de désactiver le DRS vSphere ou d'utiliser l'un des niveaux d'automatisation de DRS vSphere suivants : manuel, partiellement automatisé ou entièrement automatisé.

      Définissez le mode DRS de vSphere sur Entièrement automatisé si :

      • Le mode de migration Maintenance automatique sera utilisé pour la migration et que la version de vCenter Server est 7.0.
    • Désactivez la Haute disponibilité vSphere.
    • Définissez la version d'exportation du filtre du pare-feu distribué sur 1 000. Reportez-vous à la section Configurer la version d'exportation du filtre du pare-feu distribué sur des hôtes.
  • Pour migrer les règles de service d'introspection réseau, utilisez le mode de migration de l'hôte Maintenance. Le mode de migration Sur place n'est pas pris en charge.
  • Si vous avez des hôtes sur lesquels NSX-v est installé mais ne sont pas ajoutés à un vSphere Distributed Switch, vous devez les ajouter à des commutateurs distribués si vous souhaitez les migrer vers NSX-T. Pour plus d'informations, reportez-vous à la section Configurer les hôtes non attachés aux vSphere Distributed Switches.
  • Sur chaque cluster sur lequel NSX-v est installé, vérifiez si le Pare-feu distribué est activé. Vous pouvez afficher l'état activé dans Installation et mise à niveau > Préparation de l'hôte.

    Si le Pare-feu distribué est activé sur les clusters de NSX-v avant la migration, le Pare-feu distribué est activé sur tous les clusters lorsqu'ils migrent vers le dispositif NSX-T. Déterminez l'impact de l'activation du Pare-feu distribué sur tous les clusters et modifiez la configuration du Pare-feu distribué, si nécessaire.

Configuration de la passerelle Edge Services Gateway

  • Les passerelles Edge Services Gateway doivent utiliser BGP pour le routage ascendant. Si OSPF est utilisé, vous devez le reconfigurer pour utiliser BGP avant de commencer la migration.
  • Vous devrez éventuellement apporter des modifications à votre configuration de redistribution de routes NSX-v avant le début de la migration.
    • Les filtres préfixes configurés au niveau de la redistribution n'ont pas migré. Ajoutez tous les filtres dont vous avez besoin en tant que filtres BGP dans la configuration du voisin BGP de la passerelle de service Edge.
    • Après la migration, les routes apprises dynamiquement entre le routeur logique distribué et la passerelle de services Edge sont converties en routes statiques et toutes les routes statiques sont redistribuées dans BGP. Si vous devez filtrer l'une de ces routes, avant de démarrer la migration, configurez les filtres voisins BGP pour refuser ces préfixes tout en en autorisant d'autres.
  • NSX-v prend en charge les sessions de VPN IPSec basé sur les stratégies dans lequel les sous-réseaux locaux et homologues de deux ou plusieurs sessions se chevauchent mutuellement. Ce comportement n'est pas pris en charge sur NSX-T. Vous devez reconfigurer les sous-réseaux afin qu'ils ne se chevauchent pas avant de commencer la migration. Si ce problème de configuration n'est pas résolu, l'étape Migrer la configuration échoue.
  • Si vous disposez d'une passerelle Edge Services effectuant la fonction d'équilibreur de charge à un bras, vous devez modifier les configurations suivantes si elle est présente avant d'importer la configuration :
    • Si la passerelle Edge Services dispose d'une interface configurée pour la gestion, vous devez la supprimer avant la migration. Vous ne pouvez avoir qu'une seule interface connectée à une passerelle Edge Services fournissant une fonction d'équilibreur de charge à un bras. Si elle contient plusieurs interfaces, l'étape Migrer la configuration échoue.
    • Si le pare-feu de passerelle Edge Services est désactivé et que la règle par défaut est définie sur Refuser, vous devez activer le pare-feu et modifier la règle par défaut sur accepter. Après la migration, le pare-feu est activé sur la passerelle de niveau 1, et la règle par défaut Accepter prend effet. Modifier la règle par défaut à accepter avant la migration empêche le trafic entrant vers l'équilibreur de charge d'être bloqué.
  • Vérifiez que les passerelles Edge Services Gateways sont toutes correctement connectées à la topologie en cours de migration. Si les passerelles Edge Services font partie de l'environnement de NSX-v, mais ne sont pas correctement attachées au reste de l'environnement, elles ne sont pas migrées.
    Par exemple, si une passerelle Edge Services est configurée comme un équilibreur de charge à un bras, mais a une des configurations suivantes, elle n'est pas migrée :
    • La passerelle Edge Services dispose d'une interface de liaison montante connectée à un commutateur logique.
    • La passerelle Edge Services dispose d'une interface de liaison montante connectée à un commutateur logique, mais l'adresse IP de liaison montante ne correspond pas au sous-réseau associé au routeur logique distribué qui se connecte au commutateur logique.

Configuration de la sécurité

  • Si vous prévoyez d'utiliser vMotion pour déplacer des machines virtuelles pendant la migration, désactivez toutes les stratégies SpoofGuard dans NSX Data Center for vSphere pour empêcher la perte de paquets.
    • Le mode de maintenance automatisé utilise DRS et vMotion pour déplacer des machines virtuelles pendant la migration.
    • En mode de maintenance manuelle, vous pouvez éventuellement utiliser vMotion pour déplacer des machines virtuelles pendant la migration.
    • Le mode de migration Sur place n'utilise pas vMotion.

Configuration du groupe de sécurité

Si des stratégies de sécurité existantes contiennent des règles de service Guest Introspection qui sont appliquées à des groupes de sécurité avec des membres de machine virtuelle statiques ou des membres dynamiques autres que des machines virtuelles, procédez comme suit :
  1. Créez des groupes de sécurité avec des machines virtuelles uniquement dans les critères d'appartenance dynamique. Assurez-vous que les critères d'appartenance dynamique produisent les mêmes membres de machine virtuelle effectifs que vos groupes de sécurité d'origine.
  2. Avant d'exécuter le coordinateur de migration, mettez à jour les stratégies de sécurité existantes pour appliquer les nouveaux groupes de sécurité aux règles de service Guest Introspection.

    Si vous préférez ne pas mettre à jour vos stratégies de sécurité existantes avant la migration, vous pouvez toujours conserver les nouveaux groupes de sécurité avec les bons critères d'appartenance dynamique dans votre environnement NSX-v. Lors de l'étape Résoudre la configuration du processus de migration, lorsque le coordinateur de migration affiche des messages d'avertissement et vous invite à fournir d'autres groupes de sécurité, sélectionnez les nouveaux groupes de sécurité et poursuivez la migration.

Synchronisation avec Service Composer

Assurez-vous que Service Composer est synchronisé avec le pare-feu distribué avant de démarrer le coordinateur de migration. Une synchronisation manuelle garantit que si vous apportez des modifications de dernière minute à la configuration de la stratégie avant de démarrer la migration, ces modifications sont appliquées aux stratégies de sécurité créées à l'aide de Security Composer. Par exemple, vous modifiez le nom du groupe de sécurité qui est utilisé dans une règle de pare-feu avant de démarrer la migration.

Pour vérifier si l'état de Service Composer est synchronisé, procédez comme suit :
  1. Dans vSphere Client, accédez à Mise en réseau et sécurité > Sécurité > Service Composer.
  2. Cliquez sur l'onglet Stratégies de sécurité.
  3. Vérifiez que l'état de synchronisation est Synchronisation. Si ce n'est pas le cas, cliquez sur Synchroniser.

Comme pratique préférée, cliquez toujours sur le bouton Synchroniser avant de démarrer le coordinateur de migration, même lorsque l'état de synchronisation est vert. Effectuez cette synchronisation manuelle, même si vous avez effectué des modifications de dernière minute dans la configuration de la stratégie.

Pendant la migration, si le statut de Service Composer n'est pas synchronisé, l'étape Résoudre la configuration affiche un avertissement. Vous pouvez ignorer la migration des stratégies de sécurité créées à l'aide de Service Composer en ignorant les sections de pare-feu distribué appropriées. Vous pouvez également annuler la migration, synchroniser Service Composer avec le pare-feu distribué et redémarrer la migration.