Sie müssen den Status der NSX Data Center for vSphere-Umgebung überprüfen und alle gefundenen Probleme beheben. Darüber hinaus müssen Sie je nach Umgebung gegebenenfalls Ihre NSX Data Center for vSphere-Konfiguration ändern, bevor Sie auf NSX-T Data Center migrieren können.

Systemstatus

Überprüfen Sie die folgenden Systemzustände:

  • Stellen Sie sicher, dass der Status der NSX-v-Komponenten im NSX-Dashboard auf „Grün“ gesetzt ist.
  • Stellen Sie sicher, dass alle ESXi-Hosts betriebsbereit sind. Beheben Sie alle Probleme mit Hosts, einschließlich getrennter Zustände. Für den Eintritt in den Wartungsmodus dürfen weder ausstehende Neustarts noch ausstehende Aufgaben vorhanden sein.
  • Stellen Sie sicher, dass keine NSX-v-Upgrades ausgeführt werden.
  • Überprüfen Sie den Veröffentlichungsstatus der verteilten Firewall und des Service Composers, um sicherzustellen, dass keine unveröffentlichten Änderungen vorliegen.

Allgemeine Konfiguration

  • Sichern Sie die NSX-v- und die vSphere-Umgebung. Weitere Informationen finden Sie unter „Sichern und Wiederherstellen von NSX“ im Administratorhandbuch für NSX.
  • Der VXLAN-Port muss auf 4789 festgelegt sein. Wenn in der NSX-v-Umgebung ein anderer Port verwendet wird, muss dieser vor der Migration geändert werden. Weitere Informationen finden Sie unter „Ändern des VXLAN-Ports“ im NSX-v Administratorhandbuch für NSX.

Controller-Konfiguration

  • Der Migrations-Koordinator bietet keine Unterstützung für NSX-v-Transportzonen, die den Multicast- oder Hybrid-Replikationsmodus verwenden. Ein NSX Controller-Cluster ist erforderlich, wenn VXLAN verwendet wird. VLAN-gestützte Mikrosegmentierungs-Topologien verwenden kein VXLAN und benötigen daher keinen NSX Controller-Cluster.

Hostkonfiguration

  • Überprüfen Sie diese Einstellungen auf allen Hostclustern in der NSX-v-Umgebung und aktualisieren Sie sie gegebenenfalls:
    • Legen Sie vSphere DRS entsprechend fest.

      Deaktivieren Sie vSphere DRS, wenn eine der folgenden Bedingungen zutrifft:

      • Der Migrationsmodus Direkt wird verwendet.
      • Der Migrationsmodus Manuelle Wartung wird verwendet. Sehen Sie hierzu den unten stehenden Hinweis.
      • Wenn der Migrationsmodus Automatisierte Wartung für die Migration verwendet wird und die vCenter Server-Version 6.5 oder 6.7 lautet.
      • Hinweis: Wenn Sie für die Migration von VMs im Migrationsmodus Manuelle Wartung vMotion verwenden möchten, können Sie entweder vSphere DRS deaktivieren oder eine der folgenden vSphere DRS-Automatisierungsstufen nutzen: „Manuell“, „Teilautomatisiert“ oder „Vollständig automatisiert“.

      Legen Sie den vSphere DRS-Modus auf „Vollständig automatisiert“ fest, wenn Folgendes zutrifft:

      • Der Migrationsmodus Automatisierte Wartung wird für die Migration verwendet und die vCenter Server-Version lautet 7.0.
    • Deaktivieren Sie die vSphere-Hochverfügbarkeit.
    • Die Exportversion des Filters für die verteilte Firewall auf 1.000 setzen. Siehe Konfigurieren der Exportversion des Filters „Verteilte Firewall“ auf Hosts.
  • Verwenden Sie zum Migrieren von Regeln des Netzwerk-Introspektionsdienstes den Host-Migrationsmodus Wartung. Der Migrationsmodus Direkt wird nicht unterstützt.
  • Hosts, auf denen NSX-v installiert ist, die aber keinem vSphere Distributed Switch hinzugefügt wurden, müssen zu Distributed Switches hinzugefügt werden, wenn sie auf NSX-T migriert werden sollen. Weitere Informationen hierzu finden Sie unter Konfigurieren von nicht an vSphere Distributed Switches angehängten Hosts.
  • Überprüfen Sie auf jedem Cluster, auf dem NSX-v installiert ist, ob die verteilte Firewall aktiviert ist. Sie können den aktivierten Status unter Installation und Upgrade > Hostvorbereitung anzeigen.

    Wenn die verteilte Firewall vor der Migration auf NSX-v-Clustern aktiviert ist, wird sie auf allen Clustern aktiviert, wenn diese auf NSX-T migriert werden. Überprüfen Sie die Auswirkungen der Aktivierung der verteilten Firewall auf allen Clustern und ändern Sie gegebenenfalls die Konfiguration der verteilten Firewall.

Konfiguration des Edge Services Gateway

  • Edge Services Gateways müssen BGP für Northbound-Routing verwenden. Bei Verwendung von OSPF müssen Sie die Konfiguration zur Verwendung von BGP abändern, bevor Sie die Migration starten.
  • Sie müssen möglicherweise Änderungen an der NSX-v Route Redistribution-Konfiguration vornehmen, bevor die Migration gestartet wird.
    • Auf der Neuverteilungsebene konfigurierte Präfixfilter werden nicht migriert. Fügen Sie alle benötigten Filter als BGP-Filter in der BGP-Nachbarkonfiguration des Edge Services Gateway hinzu.
    • Nach der Migration werden dynamisch erlernte Routen zwischen Distributed Logical Router und Edge Services Gateway in statische Routen konvertiert, und alle statischen Routen werden in BGP neu verteilt. Wenn Sie eine dieser Routen filtern müssen, bevor Sie die Migration starten, konfigurieren Sie die BGP-Nachbarfilter, um diese Präfixe zu verweigern, während sie andere zulassen.
  • NSX-v unterstützt richtlinienbasierte IPSec-VPN-Sitzungen, in denen lokale und Peer-Subnetze von zwei oder mehr Sitzungen miteinander überlappen. Dieses Verhalten wird in NSX-T nicht unterstützt. Sie müssen die Subnetze vor dem Start der Migration neu konfigurieren, damit sie sich nicht überlappen. Wenn dieses Konfigurationsproblem nicht behoben wird, schlägt der Schritt Migrieren der Konfiguration fehl.
  • Bei einem Edge Services Gateway, das als einarmiger Load Balancer fungiert, müssen Sie die folgenden Konfigurationen (falls vorhanden) vor dem Importieren der Konfiguration ändern.
    • Wenn für das Edge Services Gateway eine Verwaltungsschnittstelle konfiguriert wurde, müssen Sie diese vor der Migration löschen. Sie können nur über eine verbundene Schnittstelle auf einem Edge Services Gateway verfügen, das eine Load Balancer-Funktion mit einem Arm bereitstellt. Wenn mehrere Schnittstellen vorliegen, schlägt der Schritt Migrieren der Konfiguration fehl.
    • Wenn die Edge Services Gateway-Firewall deaktiviert und die Standardregel auf „Verweigern“ gesetzt ist, müssen Sie die Firewall aktivieren und die Standardregel in „Annehmen“ ändern. Nach der Migration wird die Firewall auf dem Tier-1-Gateway aktiviert und die Standardregel „Annehmen“ wird wirksam. Indem die Standardregel vor der Migration in „Annehmen“ geändert wird, verhindern Sie, dass eingehender Datenverkehr für den Load Balancer blockiert wird.
  • Stellen Sie sicher, dass alle Edge Services Gateways ordnungsgemäß mit der zu migrierenden Topologie verbunden sind. Wenn Edge Services Gateways als Teil der NSX-v-Umgebung nicht ordnungsgemäß an die restliche Umgebung angeschlossen sind, werden sie nicht migriert.
    Wenn ein Edge Services Gateway beispielsweise als einarmiger Load Balancer konfiguriert ist, aber eine der folgenden Konfigurationen aufweist, wird das Gateway nicht migriert:
    • Das Edge Services Gateway weist keine Uplink-Schnittstelle auf, die mit einem logischen Switch verbunden ist.
    • Das Edge Services Gateway weist eine mit einem logischen Switch verbundene Uplink-Schnittstelle auf. Die IP-Adresse des Uplinks stimmt jedoch nicht mit dem Subnetz überein, das mit dem Distributed Logical Router verknüpft ist, der eine Verbindung zum logischen Switch herstellt.

Sicherheitskonfiguration

  • Wenn Sie vMotion zum Verschieben der VMs während der Migration verwenden möchten, deaktivieren Sie in NSX Data Center for vSphere alle SpoofGuard-Richtlinien, um einem Paketverlust vorzubeugen.
    • Der Modus „Automatisierte Wartung“ verwendet DRS und vMotion, um VMs während der Migration zu verschieben.
    • Im Modus „Manuelle Wartung“ können Sie optional vMotion nutzen, um VMs während der Migration zu verschieben.
    • Beim Migrationsmodus „Direkt“ wird vMotion nicht verwendet.

Konfiguration der Sicherheitsgruppe

Wenn vorhandene Sicherheitsrichtlinien Regeln für den Guest Introspection-Dienst enthalten, die auf Sicherheitsgruppen mit statischen VM-Mitgliedern oder dynamischen Mitgliedern, die keine VMs sind, angewendet werden, führen Sie folgende Schritte aus:
  1. Erstellen Sie neue Sicherheitsgruppen mit VMs, die ausschließlich den Kriterien für die dynamische Mitgliedschaft entsprechen. Stellen Sie sicher, dass die Kriterien für die dynamische Mitgliedschaft dieselben effektiven VM-Mitglieder erzeugen, wie ihre ursprünglichen Sicherheitsgruppen.
  2. Aktualisieren Sie vor dem Ausführen des Migrationskoordinators die vorhandenen Sicherheitsrichtlinien, um die neuen Sicherheitsgruppen auf die Regeln für den Guest Introspection-Dienst anzuwenden.

    Wenn Sie Ihre vorhandenen Sicherheitsrichtlinien vor der Migration nicht aktualisieren möchten, können Sie die neuen Sicherheitsgruppen weiterhin mit den richtigen dynamischen Mitgliedschaftskriterien in ihrer NSX-v-Umgebung beibehalten. Wenn der Migrationskoordinator während des Schritts Konfiguration auflösen des Migrationsvorgangs Warnmeldungen anzeigt und Sie aufgefordert werden, alternative Sicherheitsgruppen bereitzustellen, wählen Sie die neuen Sicherheitsgruppen aus und fahren Sie mit der Migration fort.

Synchronisierung von Service Composer

Stellen Sie sicher, dass der Service Composer mit der verteilten Firewall synchronisiert wurde, bevor Sie den Migrationskoordinator starten. Eine manuelle Synchronisierung stellt sicher, dass in letzter Minute durchgeführte Änderungen der Richtlinienkonfiguration vor dem Start der Migration auch auf die mit Service Composer erstellten Sicherheitsrichtlinien angewendet werden. Wenn Sie z. B. vor dem Starten der Migration den Namen der Sicherheitsgruppe bearbeiten, die in einer Firewallregel verwendet wird.

Führen Sie folgende Schritte aus, um zu prüfen, ob der Service Composer-Status „Synchronisiert“ lautet:
  1. Navigieren Sie im vSphere Client zu Netzwerke und Sicherheit > Sicherheit > Service Composer.
  2. Klicken Sie auf die Registerkarte Sicherheitsrichtlinien.
  3. Prüfen Sie, ob der Synchronisierungsstatus Synchronisiert lautet. Wenn nicht, klicken Sie auf Synchronisieren.

Es hat sich bewährt, vor dem Starten des Migrationskoordinators immer auf die Schaltfläche Synchronisieren zu klicken, auch wenn der Synchronisierungsstatus grün ist. Führen Sie diese manuelle Synchronisierung unabhängig davon durch, ob Sie in letzter Minute Änderungen der Richtlinienkonfiguration durchgeführt haben.

Wenn der Service Composer-Status nicht synchronisiert ist, wird während der Migration im Schritt „Konfiguration auflösen“ eine Warnung angezeigt. Sie können die Migration der mit Service Composer erstellten Sicherheitsrichtlinien überspringen, indem Sie die entsprechenden Abschnitte der verteilten Firewall überspringen. Alternativ können Sie die Migration abbrechen, Service Composer mit der verteilten Firewall synchronisieren und die Migration neu starten.