Nach der NSX-T-Migration von NSX Virtual Distributed Switch (N-VDS) zu konvergiertem VDS (C-VDS) müssen Sie betroffene vSphere-Netzwerkressourcen in vRealize Automation aktualisieren, um diese Ressourcen weiterhin in neuen und vorhandenen Cloud-Vorlagen und Bereitstellungen verwenden zu können.
Nach der Migration von N-VDS zu C-VDS scheinen die vSphere-Netzwerke in den vRealize Automation-Netzwerkprofilen zu fehlen, in denen sie Mitglied sind. Um zu vermeiden, dass diese vSphere-Netzwerke verloren gehen, und um mit deren Verteilung in vorhandenen und neuen Bereitstellungen fortzufahren, müssen Sie alle aufgelisteten C-VDS-Netzwerke in vRealize Automation Cloud Assembly manuell aktualisieren.
- Active Directory-Mitglieder, denen die Cloudadmin-Rolle in VMware Cloud on AWS vor der N-VDS-zu-C-VDS-Migration in NSX-T zugewiesen wurde, verfügen nach der N-VDS-zu-C-VDS-Migration weiterhin über die Cloudadmin-Rolle in VMware Cloud on AWS und somit über die erforderliche Zugriffsebene für die migrierten C-VDS-Ressourcen.
- Active Directory-Mitglieder, denen die Cloudadmin-Rolle in VMware Cloud on AWS vor der Migration von N-VDS zu C-VDS in NSX-T nicht zugewiesen wurde, müssen die Cloudadmin-Rolle nach der Migration erhalten.
- Weitere Informationen zu VMware Cloud on AWS- und vRealize Automation-Anmeldedaten finden Sie unter Zum Arbeiten mit Cloud-Konten in vRealize Automation sind Anmeldedaten erforderlich.
Dieses Verfahren ist spezifisch für in vRealize Automation erforderliche Aktionen zum Aktualisieren von vSphere-Netzwerken nach Durchführung der Migration von N-VDS zu C-VDS in NSX-T. Nach der Migration von N-VDS zu C-VDS muss in vRealize Automation keine Aktion für NSX-Netzwerke durchgeführt werden. NSX-Netzwerke benötigen keine manuelle Intervention nach der Migration von N-VDS zu C-VDS.
NSX-Netzwerke, die mit vCenter Cloud-Konten sowie mit VMware Cloud on AWS-Cloud-Konten verknüpft sind, werden unterstützt und erfordern nicht den in diesem Verfahren beschriebenen manuellen Eingriff. Allerdings erfordern NSX-Netzwerke, die mit VMware Cloud on Dell-Cloud-Konten verknüpft sind, möglicherweise den hier beschriebenen manuellen Eingriff. Weitere Informationen finden Sie unter VMware Cloud on AWS (VMConAWS) and VMware Cloud on Dell EMC Migration from N-VDS to VDS (82487).
Wenn ein NSX-T-Administrator NSX-T mit VDS-Netzwerktypen (N-VDS) auf konvergierte VDS-Netzwerktypen (C-VDS) in NSX migrieren kann, wirkt sich diese Aktion auf vorhandene vSphere-Netzwerkressourcen in vRealize Automation aus. Der vRealize Automation-Administrator kann Aktionen nach der Migration ausführen, um diese Ressourcen in vRealize Automation mit den zugehörigen Änderungen in NSX-T und vCenter Server abzustimmen. Beachten Sie, dass C-VDS (oder nur VDS) an anderer Stelle auch als vSphere 7 Virtual Distributed Switch (VDS) bezeichnet wird.
Weitere Informationen zu konvergiertem VDS (C-VDS) von NSX-T finden Sie im VMware-Knowledgebase-Artikel NSX-T on VDS (79872).
Beispiel: vRealize Automation-Ressourcen vor der Migration
In diesem Beispiel werden NSX-T-Beispielressourcen in einer vRealize Automation-Beispielumgebung vor der Migration von N-VDS zu C-VDS veranschaulicht.
- Dieses Beispiel enthält NSX-T- und vCenter-Cloud-Konten (siehe unten).
- Das Beispiel enthält mehrere vSphere-Netzwerke (siehe unten).
- Die Beispielnetzwerkkonfiguration enthält CIDR- und DNS-Einstellungen (siehe unten).
- Das Beispiel enthält auch vorhandene IP-Bereiche (siehe unten).
- Das Beispiel enthält ein Netzwerkprofil () mit mehreren N-VDS-Netzwerken, einschließlich (siehe unten).
- In diesem Beispiel wird die vorhandene Netzwerkkomponente seg5 in der folgenden Beispielsyntax der Cloud-Vorlage angezeigt. Das Netzwerk wird als N-VDS-Netzwerk gekennzeichnet. Die nach der Migration erforderlichen Updates desseg5-Netzwerks werden später in diesem Beispiel erläutert.
- Die Beispiel-Cloud-Vorlage erzeugt die Bereitstellung (siehe unten).
- Die IP-Adressen der Beispielmaschine werden in der Beispielbereitstellung angezeigt (siehe unten).
Beispiel: Schritt 1 nach der Migration – Ausführen der Datenerfassung und Enumeration nach der Migration von N-VDS zu C-VDS
Im obigen Abschnitt wurde mithilfe von Screenshots die Infrastruktur veranschaulicht, die in einer vRealize Automation-Beispielumgebung verwendet wird, die mit der Ausgabe-Cloud-Vorlage und der Bereitstellung kompatibel ist.
Warten Sie nach der Durchführung einer Migration von N-VDS zu C-VDS in NSX-T durch Sie oder einen anderen Administrator mindestens 10 Minuten, damit vRealize Automation regelmäßige Datenerfassungs- und Enumerationsvorgänge durchführen kann, um betroffene Ressourcen in vRealize Automation abzurufen und anzuzeigen.
Klicken Sie nach Abschluss der vRealize Automation-Datenerfassung auf , um verfügbare C-VDS-Netzwerke anzuzeigen und darauf zuzugreifen. Beachten Sie das Netzwerk seg5 (siehe unten).
Beispiel: Schritt 2 nach der Migration – Hinzufügen zuvor definierter CIDR- und DNS-Details zu migrierten C-VDS-Netzwerken
Bearbeiten Sie ein migriertes C-VDS-Netzwerk zum Hinzufügen von CIDR- und DNS-Details, die in der N-VDS-Definition vor der Migration angegeben wurden, und ändern Sie das Netzwerk-Tagging.
- Fügen Sie CIDR- und DNS-Details hinzu, die in der N-VDS-Definition vor der Migration festgelegt wurden
- Fügen Sie ein neues Tag für das Netzwerksegment seg-5 des Beispiel-C-VDS hinzu, z. B. seg5-cvds.
Beachten Sie, dass das ursprüngliche N-VDS-Netzwerk seg-5 als seg5-nvds gekennzeichnet wurde (siehe vorherige Bildschirme). Die Details des Ressourcen-Taggings müssen für die Neukonfiguration des Netzwerks geändert werden. vRealize Automation erfordert, dass Sie in der Cloud-Vorlage für das C-VDS-Netzwerk einen anderen Tag-Namen als den im ursprünglichen N-VDS-Netzwerk verwendeten Tag-Namen angeben. Mit dem geänderten Tagging wird in der Cloud-Vorlage eine Änderung angegeben, wenn eine gültige erneute Bereitstellung erzeugt wird.
Beispiel: Schritt 3 nach der Migration – Hinzufügen aktualisierter IP-Bereichsinformationen
Sie können IP-Bereiche des Netzwerks mit IP-Bereichsdetails bearbeiten, die in der N-VDS-Definition vor der Migration angegeben wurden, indem Sie eine Befehlszeilen-API oder eine Menüsequenz in vRealize Automation verwenden.
- Option 1: Verwenden der API zum Aktualisieren von IP-Bereichsdaten (siehe folgenden Beispielbildschirm).
- Option 2: Verwenden der Benutzeroberfläche zum Aktualisieren der IP-Bereichsdaten (siehe folgenden Beispielbildschirm).
Beispiel: Schritt 4 nach der Migration – Aktualisieren der Netzwerkprofile zum Beheben des Problems aufgrund fehlender Netzwerke
Im Anschluss an die Migration werden N-VDS-Netzwerke nach der Datenerfassung und Enumeration abgeglichen und aus vRealize Automation Cloud Assembly gelöscht. Betroffene Netzwerkprofile (z. B. ex-np) weisen fehlende Netzwerke auf. Zum Beheben des Problems aufgrund fehlender Netzwerke aktualisieren Sie jedes N-VDS-Netzwerk als C-VDS-Netzwerk (siehe unten).
Beispiel: Schritt 5 nach der Migration – Aktualisieren von Netzwerkeinschränkungen in Cloud-Vorlagen
Bei vorhandenen Bereitstellungen müssen Sie die Netzwerkeinschränkungen in der Cloud-Vorlage aktualisieren, damit sie mit den neuen C-VDS-Netzwerken in den aktualisierten Netzwerkprofilen übereinstimmen. Aktuelle Netzwerkeinschränkungen sind auch erforderlich, um iterative Bereitstellungen durchzuführen und die ursprüngliche vSphere-N-VDS-Darstellung von Netzwerken in eine vSphere-C-VDS-Darstellung umzukonfigurieren.
Für neue Bereitstellungen werden die angegebenen C-VDS-Ressourcen verwendet. Daher ist dieser Schritt nicht erforderlich. Iterative Bereitstellungen und die Netzwerkneukonfiguration funktionieren erwartungsgemäß.
- Ändern Sie in diesem Beispiel die Netzwerkeinschränkungen in der Cloud-Vorlage von seg5-nvds in seg5-cvds (siehe unten).
- Führen Sie eine iterative Bereitstellung durch, um das Netzwerk neu zu konfigurieren (siehe unten).
- Beachten Sie nach der erfolgreichen erneuten Bereitstellung, dass die aktualisierten Einschränkungen in den benutzerdefinierten Netzwerkeigenschaften angezeigt werden (siehe unten).
Da der IP-Bereich zuvor mit den neuen C-VDS-Daten aktualisiert wurde, wird die IP-Adresse der Maschine in der erneuten Bereitstellung nicht geändert (siehe unten).
