Überprüfen Sie Ihre NSX-V-Umgebung, bevor Sie eine End-to-End-Migration starten.

Systemstatus

Überprüfen Sie die folgenden Systemzustände:

  • Falls es sich bei Ihrer Umgebung um eine Umgebung mit vSphere 7.0 oder höher handelt, führen Sie ein Upgrade des VDS auf 7.0 oder höher durch.
  • 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.
  • Wenn die NSX-V-Umgebung VDS 7.0 oder höher aufweist, kann vSphere-Hochverfügbarkeit (HA) aktiviert werden.

    Hinweis: HA wird für frühere VDS-Versionen nicht unterstützt. Dies hat folgenden Grund: Wenn die NSX-V-Umgebung VDS 6.5 oder 6.7 aufweist und die VMkernel-Ports (VMKs) an VDSe angehängt sind, verlieren die Hosts und VMs während einer Direktmigration die Netzwerkkonnektivität für einen Zeitraum, der ausreichend lang ist, damit HA ausgelöst wird. Der HA-Mechanismus wird versuchen, VMs auszuschalten, zu migrieren und neu zu starten. Dies kann fehlschlagen, weil die NSX-V-Umgebung zu NSX migriert wird. Dies führt dazu, dass VMs nach der Migration möglicherweise ausgeschaltet bleiben oder, sofern sie eingeschaltet sind, über keine Netzwerkkonnektivität verfügen. Um diese Situation zu vermeiden, deaktivieren Sie HA oder hängen Sie die Verwaltungs-VMK an ein VSS an, bevor Sie die Migration starten.

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

  • NSX-V Transportzonen mit Multicast- oder Hybrid-Replizierungsmodus werden für die Migration nicht unterstützt. 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. In diesem Modus werden Hosts während der Migration nicht in den Wartungsmodus versetzt und bei VMs kommt es während der Migration zu einem Ausfall des Netzwerks und des Netzwerkspeichers. Dieser Modus ist nur in einer Umgebung mit vSphere 6.x verfügbar (VDS wird zu N-VDS migriert).
      • Der Migrationsmodus Manuelle Wartung wird verwendet. Wenn Sie für die Migration von VMs vMotion verwenden möchten, können Sie vSphere DRS deaktivieren oder für die vSphere DRS-Automatisierungsstufe „Manuell“, „Teilautomatisiert“ oder „Vollautomatisiert“ festlegen.
      • Der Migrationsmodus Automatisierte Wartung wird verwendet und die VDS-Version lautet 6.5 oder 6.7.

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

      • Der Migrationsmodus Automatisierte Wartung wird verwendet und die VDS-Version lautet 7.0.

      Beachten Sie, dass der Migrationskoordinator im Modus Automatisierte Wartung die ausgeschalteten VMs nicht neu konfiguriert. Nach der Migration müssen Sie diese VMs vor dem Einschalten manuell konfigurieren.

  • 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 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 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

  • Sie müssen möglicherweise Änderungen an der NSX-V Route Redistribution-Konfiguration vornehmen, bevor die Migration gestartet wird.
    • Redistribution-Filter werden nicht migriert. Für BGP können Filter auf die BGP-Nachbarebene verschoben werden.
    • Nach der Migration werden dynamisch erlernte Routen zwischen dem Distributed Logical Router und dem Edge Services Gateway in statische Routen konvertiert und alle statischen Routen werden in BGP oder OSPF neu verteilt. Wenn Sie eine dieser Routen filtern müssen, können Sie sie auf der BGP-Nachbarebene konfigurieren oder die Neuverteilungsregeln auf NSX manuell konfigurieren, nachdem die Konfigurationsmigration abgeschlossen ist und bevor die Umschaltung erfolgt. Beachten Sie, dass bei einem Rollback die manuelle Konfiguration der Neuverteilungsregeln ebenfalls entfernt wird.
    • Die MTU-Standardeinstellung ist 1500 auf NSX. Wenn Sie nicht standardmäßige MTU-Einstellungsanforderungen haben, können Sie die Einstellung ändern. Siehe Ändern der globalen MTU-Einstellung.
  • 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 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-V 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 der Migration 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. Im Schritt Konfiguration auflösen des Migrationsvorgangs werden Sie aufgefordert, alternative Sicherheitsgruppen anzugeben.

Synchronisierung von Service Composer

Stellen Sie sicher, dass der Service Composer mit der verteilten Firewall synchronisiert wurde, bevor Sie die Migration 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 der Migration 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 zurücksetzen, den Service Composer mit der verteilten Firewall synchronisieren und die Migration neu starten.