Vérifiez votre environnement NSX-V avant de démarrer une migration de bout en bout.

État du système

Vérifier les états système suivants :

  • Si votre environnement est vSphere 7.0 ou version ultérieure, mettez à niveau VDS vers la version 7.0 ou ultérieure.
  • 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.
  • Vous pouvez activer vSphere High Availability (HA) si VDS 7.0 ou version ultérieure est installé dans l'environnement NSX-V.

    Remarque : HA n'est pas pris en charge pour les versions précédentes de VDS. Cela est dû au fait que si l'environnement NSX-V dispose de VDS 6.5 ou 6.7 et que les ports vmkernel (vmk) sont attachés à des 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-T. 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.

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

  • Les zones de transport NSX-V utilisant le mode de réplication multidiffusion ou hybride ne sont pas prises en charge pour la migration. 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é. Dans ce mode, les hôtes ne sont pas mis en mode de maintenance pendant la migration. Les VM subissent alors une panne réseau et une panne de stockage réseau pendant la migration. Ce mode n'est disponible que si l'environnement est vSphere 6.x (VDS est migré vers N-VDS).
      • Le mode de migration Maintenance manuelle sera utilisé. Si vous décidez d'utiliser vMotion pour la migration des VM, vous pouvez désactiver vSphere DRS ou définir le niveau d'automatisation de vSphere DRS sur Manuel, Partiellement automatisé ou Entièrement automatisé.
      • Le mode de migration Maintenance automatique sera utilisé et la version de VDS est 6.5 ou 6.7.

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

      • Le mode de migration Maintenance automatique sera utilisé et la version de VDS est 7.0.

      Notez que le coordinateur de migration ne reconfigure pas les VM hors tension en mode de maintenance Automatisé. Après la migration, vous devez configurer manuellement ces machines virtuelles avant de les mettre sous tension.

  • 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

  • Vous devrez éventuellement apporter des modifications à votre configuration de redistribution de routes NSX-V avant le début de la migration.
    • Les filtres de redistribution ne sont pas migrés. Pour BGP, les filtres peuvent être déplacés vers le niveau voisin BGP.
    • 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 ou OSPF. Si vous devez filtrer l'une de ces routes, vous pouvez les configurer au niveau du voisin BGP ou configurer manuellement les règles de redistribution sur NSX-T une fois la migration de la configuration terminée et avant le basculement. Notez que si vous restaurez, la configuration manuelle des règles de redistribution sera également supprimée.
    • Le paramètre MTU par défaut est 1 500 sur NSX-T. Si vous avez des exigences de paramètres MTU autres que ceux par défaut, vous pouvez modifier le paramètre. Reportez-vous à la section Modifier le paramètre MTU global.
  • 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-V 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 de démarrer la migration, mettez à jour les stratégies de sécurité existantes pour appliquer les nouveaux groupes de sécurité aux règles du 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. À l'étape Résoudre la configuration du processus de migration, vous serez invité à fournir d'autres groupes de sécurité.

Synchronisation avec Service Composer

Assurez-vous que Service Composer est synchronisé avec le pare-feu distribué avant de démarrer la 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 restaurer la migration, synchroniser Service Composer avec le pare-feu distribué et redémarrer la migration.