Après la migration de NSX-T de NSX Virtual Distributed Switch (N-VDS) vers un VDS convergé (C-VDS), vous devez mettre à jour les ressources réseau vSphere concernées dans vRealize Automation Cloud pour continuer à utiliser ces ressources dans les modèles de cloud et les déploiements nouveaux et existants.

Après la migration de N-VDS vers C-VDS, vos réseaux vSphere peuvent sembler être absents dans les profils réseau vRealize Automation Cloud dont ils sont membres. Pour éviter de perdre ces réseaux de type vSphere et continuer à les allouer dans des déploiements nouveaux et existants, vous devez mettre à jour manuellement tous les réseaux C-VDS répertoriés dans vRealize Automation Cloud Cloud Assembly.

Note : Alors que les utilisateurs n'ont pas besoin du rôle Cloudadmin de VMware Cloud on AWS pour créer des comptes de cloud VMware Cloud on AWS dans vRealize Automation Cloud pour N-VDS, ils n'ont pas besoin de ce niveau d'autorisation pour accéder aux ressources C-VDS après la migration de N-VDS vers C-VDS. Les membres Active Directory disposant d'autorisations en conteneur nécessitent un accès au niveau du commutateur d'hôte (lecture seule) aux ressources C-VDS migrées dans vRealize Automation Cloud. Les utilisateurs du groupe d'administrateurs cloud (rôle Cloudamin) disposent d'autorisations au niveau du commutateur. Les utilisateurs vRealize Automation Cloud qui ne sont pas membres du groupe d'administrateurs cloud VMware Cloud on AWS ne peuvent pas accéder aux ressources C-VDS migrées.
  • Les membres Active Directory auxquels le rôle Cloudadmin est attribué dans VMware Cloud on AWS avant la migration de N-VDS vers C-VDS dans NSX-T ont le rôle Cloudadmin dans VMware Cloud on AWS après la migration de N-VDS vers C-VDS, et disposent donc du niveau d'accès requis aux ressources C-VDS migrées.
  • Les membres Active Directory auxquels le rôle Cloudadmin n'est pas attribué dans VMware Cloud on AWS avant la migration de N-VDS vers C-VDS dans NSX-T doivent se voir attribuer le rôle Cloudadmin après la migration.
  • Pour obtenir des informations associées sur des informations d'identification de VMware Cloud on AWS et de vRealize Automation Cloud, reportez-vous à la section Informations d'identification requises pour utiliser des comptes de cloud dans vRealize Automation Cloud.
Note :

Cette procédure est spécifique des actions nécessaires dans vRealize Automation Cloud pour mettre à jour les réseaux vSphere après la migration de N-VDS vers C-VDS dans NSX-T. Aucune action n'est nécessaire dans vRealize Automation Cloud sur les réseaux NSX après la migration de N-VDS vers C-VDS. Les réseaux NSX ne nécessitent aucune intervention manuelle après la migration de N-VDS vers C-VDS.

Les réseaux NSX qui sont attachés à des comptes de cloud vCenter, ainsi qu'à des comptes de cloud VMware Cloud on AWS sont pris en charge et ne nécessitent pas l'intervention manuelle décrite dans cette procédure. Toutefois, les réseaux NSX qui sont attachés à des comptes de cloud VMware Cloud on Dell peuvent nécessiter l'intervention manuelle décrite ici. Pour obtenir des informations complémentaires, reportez-vous à la section Migration de VMware Cloud on AWS (VMConAWS) et de VMware Cloud on Dell EMC de N-VDS vers VDS (82487).

Bien qu'un administrateur NSX-T puisse migrer NSX-T sur des types de réseaux VDS (N-VDS) vers des types de réseaux VDS convergés (C-VDS) dans NSX, cette action a un impact sur les ressources réseau vSphere existantes dans vRealize Automation Cloud. L'administrateur vRealize Automation Cloud peut effectuer des actions de post-migration pour rapprocher ces ressources dans vRealize Automation Cloud avec les modifications associées dans NSX-T et vCenter Server. Notez que C-VDS ou simplement VDS est également référencé ailleurs sous le nom de vSphere 7 Virtual Distributed Switch (VDS).

Pour obtenir des informations connexes sur les VDS NSX-T convergés (C-VDS), reportez-vous à l'article NSX-T sur VDS (79872) de la base de connaissances VMware.

Note : Cet exemple de scénario illustre les étapes nécessaires pour rapprocher les ressources dans un environnement vRealize Automation Cloud après la migration de N-VDS vers C-VDS. Vous pouvez utiliser cet exemple et cette procédure dans vRealize Automation Cloud pour rapprocher les modifications apportées dans vCenter Server après la migration de N-VDS vers C-VDS dans NSX-T.

Exemple : pré-migration des ressources vRealize Automation Cloud

Cet exemple illustre des ressources NSX-T dans un environnement vRealize Automation Cloud avant la migration de N-VDS vers C-VDS.

  • Cet exemple contient des comptes de cloud NSX-T et vCenter, comme indiqué ci-dessous.

    cvds1

  • L'exemple contient plusieurs réseaux vSphere, comme indiqué ci-dessous.

    cvds2

  • L'exemple de configuration réseau contient des paramètres CIDR et DNS, comme indiqué ci-dessous.

    cvds3

  • L'exemple inclut également les plages d'adresses IP existantes comme indiqué ci-dessous.

    cvds4

  • L'exemple contient un profil réseau (ex-np) qui contient plusieurs réseaux N-VDS (N-VDS), notamment seg-5, comme indiqué ci-dessous.cvds5
  • Dans cet exemple, le composant réseau seg5 existant figure dans la syntaxe de modèle de cloud suivant. Le réseau est balisé comme un réseau N-VDS. Nous allons illustrer les mises à jour post-migration nécessaires vers le réseau seg5 plus tard dans cet exemple.

    cvds6

  • L'exemple de modèle de cloud génère le déploiement, comme indiqué ci-dessous.

    cvds7

  • Les exemples d'adresses IP de machine figurent dans l'exemple de déploiement, comme indiqué ci-dessous.

    cvds8

Exemple : étape 1 de post-migration : exécution de la collecte de données après la migration de N-VDS vers C-VDS et l'énumération

Dans la section ci-dessus, des captures d'écran ont été utilisées pour illustrer l'infrastructure utilisée dans un exemple d'environnement vRealize Automation Cloud, en concluant avec le modèle de cloud de sortie et le déploiement.

Une fois que vous ou un autre administrateur avez effectué la migration de N-VDS vers C-VDS dans NSX-T, attendez au moins 10 minutes pour permettre à vRealize Automation Cloud d'effectuer son processus périodique de collecte et d'énumération des données afin d'extraire et d'afficher les ressources concernées dans vRealize Automation Cloud.

Après avoir autorisé l'exécution de la collecte de données par vRealize Automation Cloud, cliquez sur Infrastructure > Réseaux pour afficher les réseaux C-VDS disponibles et y accéder. Notez la présence du réseau seg5, comme indiqué ci-dessous.

énumération

Exemple : étape 2 de post-migration : ajouter CIDR et DNS précédemment définis aux réseaux C-VDS migrés.

Modifiez un réseau C-VDS migré pour ajouter des détails CIDR et DNS qui ont été spécifiés dans la définition de N-VDS de pré-migration et modifiez le balisage réseau.

  1. Ajouter des détails CIDR et DNS qui ont été définis dans sa définition N-VDS de pré-migration
  2. Ajoutez une nouvelle balise pour l'exemple de segment de réseau C-VDS seg-5. Par exemple seg5-cvds.

    ajouter des détails

    Notez que le réseau N-VDS seg-5 d'origine a été balisé en tant que seg5-nvds, comme dans les écrans précédents. La modification des détails de balisage des ressources est requise par la reconfiguration du réseau. vRealize Automation Cloud impose l'inclusion dans le modèle de cloud pour le réseau C-VDS d'un nom de balise différent de celui utilisé dans le réseau N-VDS d'origine. Le balisage modifié identifie une modification dans le modèle de cloud lors de la génération d'un redéploiement valide.

Exemple : étape 3 de post-migration : ajouter des informations de plage d'adresses IP mises à jour

Vous pouvez modifier les plages d'adresses IP du réseau dans les détails de la plage d'adresses IP qui ont été spécifiés dans la définition de N-VDS post-migration à l'aide d'une API de ligne de commande ou d'une séquence de menus dans vRealize Automation Cloud.

  • Option 1 : utilisez l'API pour mettre à jour les données de plage d'adresses IP, comme indiqué dans l'exemple d'écran suivant.

    API pour la mise à jour de la plage d'adresses IP

  • Option 2 : utilisez l'interface utilisateur pour mettre à jour les données de plage d'adresses IP, comme indiqué dans l'exemple d'écran suivant.

    UI pour la mise à jour de la plage d'adresses IP

Exemple : étape 4 de post-migration : mettre à jour les profils réseau pour corriger les réseaux manquants

Après la migration, les réseaux N-VDS sont rapprochés et supprimés de vRealize Automation Cloud Cloud Assembly après la collecte et l'énumération des données. Les profils réseau concernés (tels que l'exemple ex-np) ont des réseaux manquants. Pour corriger le problème des réseaux manquants, mettez à jour chaque réseau N-VDS en tant que réseau C-VDS, comme indiqué ci-dessous.

mise à jour de profils réseau

Exemple : étape 5 de post-migration : mettre à jour les contraintes réseau dans les modèles de cloud

Pour les déploiements existants vous devez mettre à jour les contraintes réseau dans le modèle de cloud pour qu'elles correspondent aux nouveaux réseaux C-VDS dans les profils réseau mis à jour. Les contraintes réseau mises à jour sont également nécessaires pour effectuer des déploiements itératifs et pour reconfigurer les réseaux de leur représentation N-VDS d'origine vSphere vers la représentation C-VDS vSphere.

Pour les nouveaux déploiements, les ressources C-VDS spécifiées sont utilisées, cette étape n'est donc pas requise. Les déploiements itératifs et la reconfiguration du réseau fonctionnent simplement comme prévu.

  1. Pour cet exemple, modifiez les contraintes réseau dans le modèle de cloud en remplaçant les contraintes seg5-nvds par seg5-cvds, comme indiqué ci-dessous.

    mise à jour des contraintes 1

  2. Effectuez un déploiement itératif pour reconfigurer le réseau, comme indiqué ci-dessous.

    mise à jour des contraintes 2

  3. Pour un redéploiement réussi, notez que les propriétés personnalisées du réseau affichent les contraintes mises à jour, comme indiqué ci-dessous.

    mise à jour des contraintes 3

    Cette plage d'adresses IP ayant été mise à jour précédemment avec les nouvelles données C-VDS, l'adresse IP de la machine ne change pas correctement dans le redéploiement, comme indiqué ci-dessous.

    mise à jour des contraintes 4