Sie können Ihre VMware Integrated OpenStack (VIO)-Bereitstellung von NSX-V auf NSX-T migrieren. Während der Migration muss sich die VIO-Steuerungsebene im schreibgeschützten Modus befinden.

Die Datenpfadkonnektivität für VMs ist während der Migration nicht betroffen, mit Ausnahme von kurzen Unterbrechungen während der Nord-Süd-Umstellung und der Hostmigration. Diese Migration muss während eines einzelnen Wartungsfensters durchgeführt werden.

Übersicht über den Migrationsprozess

  1. Installieren Sie NSX-T.
  2. Bereiten Sie NSX-T für VIO vor. Dies erfordert die Einrichtung von Tier-0-Gateways oder VRF-lites für externe Netzwerke sowie die Konfiguration von Edge-Clustern, DHCP-Serverprofilen und Metadaten-Proxys. Weitere Informationen finden Sie unter https://docs.vmware.com/de/VMware-Integrated-OpenStack/index.html.
  3. Rufen Sie das Neutron-Migrator-Paket ab, das Teil des VIO-Lieferumfangs ist.
  4. Konfigurieren Sie den Neutron-Migrator.
  5. Stellen Sie den Neutron-Migrations-Pod bereit.
  6. Über die NSX Manager-Benutzeroberfläche:
    • Starten Sie die Edge-Übernahmemigration.
    • Bearbeiten Sie Feedback und schließen Sie die Migration ab.
    • Starten Sie die Host-Migration.
    • Bearbeiten Sie Feedback und schließen Sie die Migration ab.
  7. Warten Sie, bis der Neutron-Migrations-Pod abgeschlossen ist.
  8. Löschen Sie die Neutron-Migrationsbereitstellung.
  9. Entfernen Sie die VIO-Installation in NSX-V.

Voraussetzungen

  • VIO 7.2.0 oder höher
  • NSX-V 6.4.11 oder höher
  • vSphere 6.7 oder höher (Es wird empfohlen, vor der Migration ein Upgrade von ESXi-Hosts auf 7.0 oder höher durchzuführen.)
Der Neutron-Migrations-Pod führt die folgenden Validierungsprüfungen durch. Prüfungen, die eine Warnung ausgeben, können über die Neutron-Migrator-Konfiguration umgangen werden.
  • Anzahl der in Neutron zulässigen Adresspaare (Anzahl der manuellen Adressbindungen darf 128 nicht überschreiten)
  • Anzahl mehrerer Subnetze mit DHCP pro logischem Switch (nur eines in NSX-T zulässig)
  • Anzahl der Router-Uplinks pro Netzwerk (nur einer in NSX-T)
  • Hostgruppen: Wenn HA für NSX Edge-Knoten aktiviert ist und Hostgruppen für die zu platzierenden Edge-Knoten angegeben sind. Dadurch wird eine Warnung generiert.
  • Edge-HA wird in NSX-T ignoriert, da sie nicht zutrifft. Dadurch wird eine Warnung generiert.
  • Anbieternetzwerke oder externe Netzwerke, die auf einer DVS-Portgruppe basieren, werden vom NSX-T-Plug-In nicht unterstützt.
  • Multi-Provider-VLAN-Netzwerke werden nicht unterstützt.
  • Load Balancing-Topologien werden vom NSX-T-Plug-In nicht unterstützt (z. B. ein Load Balancer mit Mitgliedern aus verschiedenen Subnetzen, die nicht mit demselben Edge-Router verbunden sind, oder ein Load Balancer in einem Netzwerk, das nicht mit einem Neutron-Router verbunden ist).
  • Verwendung von ungültigen Adressen für NSX-T (z. B. Überschneidung mit Transitnetzwerk).
  • In externen Netzwerken bereitgestellte VMs. Sie funktionieren nicht auf NSX-T.
  • Erreichbarkeit von Subnetzen für Load Balancing-Mitglieder. NSX-T erfordert, dass alle Subnetze des Load Balancers mit demselben Subnetz verbunden sind.

Auf NSX-T dürfen keine OpenStack-eigenen Ressourcen vorhanden sein (z. B. Ressourcen aus früheren VIO-Bereitstellungen auf der NSX-T-Instanz).

Unter Direkte Migration bestimmter Teile von NSX-V finden Sie Informationen zu allen Vorbereitungen für die Edge-Übernahmemigration und die Hostmigration.

Vorbereiten der Migration – Dimensionierung des NSX-T Edge-Clusters

Der NSX-T Edge-Cluster muss über genügend Steckplätze für OpenStack Load Balancer verfügen. Wenn Sie die Liste der Tier-1-Gateways ermitteln, die einen LB-Dienst hosten, gehen Sie wie folgt vor:
  • Suchen Sie für jede OpenStack-VIP das entsprechende Subnetz und rufen Sie den Router ab, mit dem sie verbunden ist, es sei denn, das Subnetz befindet sich in einem externen Netzwerk.
  • Listen Sie für jeden OpenStack LB-Pool die Mitglieder auf. Suchen Sie das zugehörige Subnetz und ermitteln Sie den Router, mit dem das Subnetz verbunden ist.

Die Anzahl der gefundenen Router bestimmt zusammen mit der Größe des größten OpenStack-LB die Anzahl der LB-Steckplätze, die auf dem NSX-T Edge-Cluster erforderlich sind. Für jede LB werden zwei Steckplätze für den aktiven und den Standby-Dienstrouter benötigt. Unter https://configmax.vmware.com finden Sie die maximale Anzahl der Load Balancer, die auf jeder NSX-T Edge-Appliance ausgeführt werden können.

Vorbereiten der Migration – Konfigurieren des TEP-IP-Pools

Während der Hostmigration müssen sich NSX-V und NSX-T TEPs gegenseitig erreichen können, um die Konnektivität sicherzustellen. Sie müssen den NSX-T TEP-IP-Pool so konfigurieren, dass er Datenverkehr an NSX-V-TEPs weiterleiten kann.

NSX-V-Konfigurationsparameter werden in NSX-T nicht unterstützt

In der folgenden Tabelle werden die nicht unterstützten NSX-V-Parameter und die Gründe dafür aufgelistet.

Parameter Beschreibung Grund
cluster_moid Listet die IDs der von OpenStack verwendeten Cluster auf. Nicht anwendbar in NSX-T

datacenter_moid

Identifiziert das Datencenter für die Bereitstellung von NSX-V-Edge-Appliances. Nicht anwendbar in NSX-T

deployment_container_id

Identifiziert den Bereitstellungs-Container für NSX-V-Edges. Nicht anwendbar in NSX-T

resource_pool_id

Identifiziert den Ressourcenpool für NSX-V-Edges. Nicht anwendbar in NSX-T

datastore_id

Identifiziert den Datenspeicher für NSX-V-Edges. Nicht anwendbar in NSX-T

ha_datastore_id

Zusätzlicher Datenspeicher, wenn Edge-HA aktiviert ist. Nicht anwendbar in NSX-T

ha_placement_random

Aktive Edges auf primären und sekundären Datenspeicher aufteilen. Nicht anwendbar in NSX-T

edge_host_groups

Stellen Sie sicher, dass aktive/Sicherungs-Edges in den aufgelisteten Hostgruppen platziert werden. Nicht anwendbar in NSX-T

external_network

ID von DVPG, die für den physischen Netzwerk-Uplink verwendet werden soll. Nicht anwendbar in NSX-T

task_status_check_interval

Intervall für die Prüfung auf Abschluss der Aufgabe. Nicht anwendbar in NSX-T

vdn_scope_id

ID des Netzwerkbereichsobjekts für virtuelle VXLAN-Leitungen. VDN-Bereiche werden durch NSX-T-Overlay-Transportzonen ersetzt.

dvs_id

ID des mit dem Verwaltungs- und Edge-Cluster verbundenen DVS. Wird auch standardmäßig für VLAN-Netzwerke verwendet. DVS wird in NSX-T durch die VLAN-Transportzone ersetzt.

maximum_tunnel_per_vnic

Maximale Anzahl der Teilschnittstellen, die von einer vNIC auf einer Edge-Appliance unterstützt werden. Nicht anwendbar in NSX-T

backup_edge_pool

Definiert die Größe für den NSX-V-Edge-Pool, der von der OpenStack-Bereitstellung verwendet werden soll. Nicht anwendbar in NSX-T

mgm_net_moid

Portgruppen-ID für das Metadaten-Proxy-Verwaltungsnetzwerk. Nicht anwendbar in NSX-T

mgt_net_proxy_ips

Kommagetrennte Liste der IP-Adressen des Verwaltungsnetzwerks. Nicht anwendbar in NSX-T

mgt_net_proxy_netmask

Verwaltungsnetzwerkmaske für den Metadaten-Proxy. Nicht anwendbar in NSX-T

mgt_net_default_gateway

Standard-Gateway des Verwaltungsnetzwerks für den Metadaten-Proxy. Nicht anwendbar in NSX-T

nova_metadata_ips

Vom Nova-Metadatendienst verwendete IP-Adressen. Wird in der NSX-T-Metadaten-Proxy-Konfiguration bereitgestellt.

nova_metadat_port

Port, der vom Nova-Metadatendienst verwendet wird. Wird in der NSX-T-Metadaten-Proxy-Konfiguration bereitgestellt.

spoofguard_enabled

Standardmäßig ist Spoofguard in NSX-V aktiviert. Wenn Sie Spoofguard in NSX-V deaktivieren, wird Spoofguard nach der Migration in NSX-T aktiviert. Standardmäßig in NSX-T aktiviert (kann nicht global deaktiviert werden).

use_exclude_list

NSX-V-Ausschlusslistenkomponente verwenden, wenn die Portsicherheit deaktiviert und Spoofguard aktiviert ist. Standardmäßig in NSX-T aktiviert (kann nicht global deaktiviert werden).

tenant_router_types

Sortierte Liste der Routertypen, die als Mandantenrouter zugeteilt werden sollen. Nicht anwendbar in NSX-T

edge_appliance_user

Benutzername, der für die Anmeldung bei der Edge-Appliance konfiguriert werden soll. Nicht anwendbar in NSX-T

metadata_initializer

Initialisieren der Infrastruktur für den Metadatenzugriff Nicht anwendbar in NSX-T

shared_router_appliance_size

Edge-Appliance-Größe, die zum Erstellen eines gemeinsam genutzten Router-Edge verwendet wird. Nicht anwendbar in NSX-T

use_dvs_features

Ermöglichen Sie die direkte Konfiguration des DVS-Backing-NSX-V. Nicht anwendbar in NSX-T

service_insertion_profile_id

Die Profil-ID der Firewall-Umleitungsregeln, die für die Diensteinfügung verwendet werden. Funktion ist in der NSX-T-Integration nicht vorhanden.

service_insertion_redirect_all

Erstellt eine Firewallregel, um den gesamten Datenverkehr an eine Drittanbieter-Firewall umzuleiten. Funktion ist in der NSX-T-Integration nicht vorhanden.

use_nsx_policies

Verwenden Sie NSX-Richtlinien für die Implementierung von Neutron-Sicherheitsgruppen. Funktion ist in der NSX-T-Integration nicht vorhanden.

default_policy_id

Wenn use_nsx_policies True ist, wird diese Richtlinie als Standardrichtlinie für neue Mandanten verwendet Funktion ist in der NSX-T-Integration nicht vorhanden.

bind_floatingip_to_all_interfaces

Binden Sie dynamische IPs an Downlink-Schnittstellen, wenn sie auf True festgelegt sind. In NSX-T wird NAT für dynamische IP-Adressen immer auch für Ost-West-Datenverkehr verarbeitet.

vdr_transit_network

Netzwerkbereich für die TLR / PLR-Konnektivität des verteilten Routers. In NSX-T kann der Bereich für die DR/SR-Konnektivität nicht über OpenStack konfiguriert werden.

exklusiv_dhcp_edge

Verwenden eines exklusiven DHCP-Edge pro Netzwerk Gilt nicht für NSX-T, da DHCP auf dem Edge-Cluster implementiert ist.

bgp_neighbour_halte_down_timer

Intervall für die Hold-Down-Zeit des BGP-Nachbarn. Funktion ist in der NSX-T-Integration nicht vorhanden. BGP-Peering wird in der Routing-Konfiguration des NSX-Tier-0-Gateways konfiguriert.

bgp_neighbour_keep_alive_timer

Intervall für die Keep-Alive-Zeit des Nachbarn. Funktion ist in der NSX-T-Integration nicht vorhanden. BGP-Peering wird in der Routing-Konfiguration des NSX-Tier-0-Gateways konfiguriert.

share_edges_between_tenants

Verwenden Sie denselben DHCP- oder Router-Edge für mehrere Mandanten. Nicht anwendbar in NSX-T

use_routers_as_lbaas_platform

Verwenden Sie den exklusiven Router des Subnetzes als Plattform für LBaaS. Nicht anwendbar in NSX-T, wo LB-Dienste immer an Router angehängt sind, die für die Weiterleitung verwendet werden.

nsx_sg_name_format

Format für den NSX-Namen einer OpenStack-Sicherheitsgruppe. Die Benennung der Backend-Ressource ist in NSX-T implizit.

loadbalancer_pool_transparence

Erstellen Sie LBaaS-Pools im transparenten Modus. Der transparente Modus wird in NSX-T nicht unterstützt.

default_edge_size

Definiert die Standard-Edge-Größe für Router-, DHCP- und LB-Edges. Nicht anwendbar in NSX-T

Konfigurieren des Neutron-Migrators.

Erstellen Sie vor dem Starten des Neutron-Migrators eine JSON-Datei mit dem Namen migrator.conf.json, um die NSX-T-Umgebung und die zu migrierenden Hosts anzugeben. Diese Datei wird im Migrator-Pod gemountet und durch den Migrationsvorgang validiert. Nachfolgend finden Sie ein Beispieldatei für migrator.conf.json
{
 "strict_validation": true,
 "edge_migration": true,
 "host_migration": true,
 "edge_migration_interfaces_down": true,
 "post_migration_cleanup": true,
 "rollback": false, 
 "nsxv_token_lifetime": 1440,
 "compute_clusters": [
   "domain-c17",
   "domain-c29",
   "domain-c71",
  ],
  "nsx_manager_ips": [
    "192.168.16.32",
    "192.168.16.64",
    "192.168.16.96",
  ],
  "nsx_manager_user": "admin",
  "nsx_manager_password": "<NSX password>",
  "metadata_proxy": "VIO_mdproxy",
  "dhcp_profile": "VIO_dhcp_profile",
  "default_overlay_tz": "0b3d2a91-2dfc-40a7-ac6b-fbd62b0e4c79",
  "default_vlan_tz": "b87c7a69-6d1a-4857-badd-0d0e4d4e924f",
  "default_tier0_router": "VIO_Tier0",
  "availability_zones": [
  {
    "name": "az1",
    "metadata_proxy": "VIOAZ1_mdproxy",
    "dhcp_profile": "VIOAZ1_dhcp_profile",
    "default_vlan_tz": "6320d1e3-45a1-4f37-87b4-6d35d19cafef",
    "default_tier0_router": "VIOAZ1_Tier0VRFLite"
   }
   ],
   "external_networks_map": {
    "61282e88-0abb-4036-9ea8-22418f85cdf3": "VIO_Tier0",
    "39db1d0f-4279-462b-a17e-1995a5c00ae8": "VIOAZ1_Tier0VRFLite"
  },
  "transit_network": "100.64.0.0/16"
}

Die Konfigurationsparameter lauten:

Parameter Standardwert Beschreibung
post_migration_cleanup Wahr Nachdem die Migration abgeschlossen ist, entfernen Sie zusätzliche NSX-T-Einheiten, die durch den Migrationsprozess erstellt wurden und nicht von VIO verwendet oder von anderen VIO-Ressourcen dupliziert werden.
Rollback Wahr Automatisches Zurücksetzen bei Ausfall (falls möglich).
nsxv_token_lifetime 1440 Dauer des Tokens für den NSX-V-Zugriff in Minuten. Token wird für NSX-T bereitgestellt. Die Dauer sollte entsprechend der Bereitstellungsgröße und der erwarteten Zeit zum Abschließen der Migration ausgewählt werden. Token sollte nicht ablaufen, bevor die Migration abgeschlossen ist.
compute_clusters Liste der zu migrierenden vSphere-Computing-Cluster. Dies sollte nur die Cluster umfassen, in denen VIO-VM-Instanzen bereitgestellt werden. Edge-Cluster und VIO-Verwaltungscluster sollten nicht enthalten sein.
nsx_manager_ips IP oder FQDN für NSX-T Manager. Wenn ein Manager-Cluster verwendet wird, kann dieser Parameter entweder eine VIP oder die Liste der NSX Manager-Instanzen angeben. Im letzteren Fall wird beim Zugriff auf NSX Manager das clientseitige Load Balancing verwendet.
nsx_manager_user admin Benutzer für den NSX Manager-Zugriff. Die Authentifizierung mit Prinzipalidentitäten wird von VIO nicht unterstützt.
nsx_manager_password Kennwort für den NSX Manager-Zugriff.
metadata_proxy Bezeichner des Metadaten-Proxys für den VIO-Standardverfügbarkeitsbereich. Der Bezeichner ist das letzte Segment des Richtlinienpfads der Ressource.
dhcp_profile Bezeichner des DHCP-Profils für die VIO-Standardverfügbarkeitszone.
default_tier0_router Bezeichner des Tier-0-Gateways für die VIO-Standardverfügbarkeitszone. Wird für den Nord-Süd-Datenverkehr von Neutron-Routern verwendet, deren Gateway das externe Standardnetzwerk ist.
default_overlay_tz Overlay-NSX-T-Transportzone für die VIO-Bereitstellung.
default_vlan_tz VLAN NSX-T-Transportzone für die Standardverfügbarkeitszone.
transit_network 100.64.0.0/16 CIDR für das NSX-T-Transitnetzwerk. Nur ändern, wenn sie vom NSX-T-Standardwert geändert wurde.
external_networks_map Leere Liste
availability_zones Leere Liste

Bereitstellen des Neutron-Migrators

Im Migrator-Paket befindet sich ein Skript mit dem Namen Skript build_yaml.sh . Wenn die Migrator-Konfiguration bereit ist, führen Sie das Skript aus, um die Bereitstellungsspezifikation zu erstellen und auf der VIO-Steuerungsebene bereitzustellen. Beispiel:
./build_yaml.sh -t 7.1.1.1899999
Das Skript akzeptiert die folgenden Parameter:
-k Optional Schließen Sie kein vCenter Server-Zertifikat in die Bereitstellung ein. Geben Sie dies nur an, wenn VIO eine unsichere vCenter-Verbindung verwendet.
/t <full VIO version> Erforderlich. Die VIO-Version muss die Build-Nummer und das Übereinstimmungs-Tag für vorhandene VIO-Images enthalten.

Das Skript build_yaml.sh erstellt <YAML-FILE-NAME> und enthält alle Informationen für die Bereitstellung der Neutron-Migrationssteuerungsebene.

Starten der Migration

Um die Migration zu starten, führen Sie den folgenden Befehl aus:
kubectl apply -f <YAML-FILE-NAME>

Dadurch wird die Neutron-Migrator-Bereitstellung im openstack-Namespace erstellt. Diese Bereitstellung verfügt über ein einzelnes Replikat. Der Migrations-Pod wird automatisch gestartet, wenn der Pod der Bereitstellung erstellt wird.

Migration Pod-Start

Während des Starts liest der Migrator-Pod die Konfigurationsdatei und den aktuellen Status der Migration. Basierend auf diesen Informationen entscheidet sie über den nächsten Schritt der Migration, der einer der folgenden sein kann:
  • API-Wiedergabe
  • Migration wird von NSX Manager gestartet
  • VIO-Neukonfiguration

Der Migrations-Pod wird beendet, wenn die Konfigurationsdatei nicht gefunden wird oder wenn ein erforderlicher Parameter nicht angegeben wurde.

Der Migrations-Pod wird auch mit einem Fehler beendet, wenn der aktuelle Zustand der Migration inkonsistent ist, z. B. wenn die API-Wiedergabe nicht abgeschlossen wurde, aber bereits eine Migration durchgeführt wird.

Wenn der Migrationsauftrag gestartet wird, werden Konfigurationsdateien für Neutron NSX-Plug-Ins im Pod gemountet. Jede an der Neutron-Konfiguration vorgenommene Änderung wird durch den Migrator-Auftrag nicht verarbeitet. Sie dürfen keine Änderungen an der Neutron-Konfiguration vornehmen, während der Migrator ausgeführt wird. Wenn Sie Änderungen vornehmen müssen, muss der Migratorauftrag neu gestartet werden.

API-Wiedergabe

In diesem Zustand erstellt der Migrationsprozess alle erforderlichen Konfigurationen auf NSX-T und füllt die VIO Neutron-Datenbank für die Verwendung mit NSX-T auf.

Am Ende dieses Vorgangs werden alle für VIO erforderlichen logischen Netzwerkelemente in NSX-T konfiguriert, selbst wenn Arbeitslasten noch auf NSX-V ausgeführt werden.

Vor der Implementierung der VIO-Konfiguration auf NSX-T werden die folgenden Prüfungen durchgeführt:
  • Vorabvalidierungsprüfungen. Dies sind die im Abschnitt Voraussetzungen aufgeführten Prüfungen.
  • NSX-T-Versionsprüfung. Die NSX-T-Version muss 3.2 oder höher sein.
  • Stellen Sie sicher, dass Compute Manager konfiguriert ist. Für die Migration muss das vCenter von VIO als Compute Manager in NSX-T registriert sein. Diese Prüfung stellt sicher, dass dies geschehen ist.
  • Auf NSX-T darf keine Neutron-Ressource konfiguriert werden. Wenn die Rollback-Option auf „Wahr“ festgelegt ist, bereinigt der Migrationsvorgang alle auf NSX-T gefundenen (wahrscheinlich veralteten) Neutronressourcen.

Nach Abschluss der Prüfungen initialisiert der Migrationsprozess die Neutron NSX-T-Datenbank und bereitet deren Struktur vor. Anschließend wird ein temporärer Neutron-Server innerhalb des Migrator-Pods gestartet. Dieser temporäre Neutron-Server wurde für die Ausführung mit NSX-T konfiguriert. Nachdem der temporäre Neutron-Server aktiv ist, erfasst der Migrationsvorgang Informationen zu den Netzwerk-VNI-Zuordnungen und Port-/VIF-Zuordnungen.

Der API-Migrationsvorgang wird dann gestartet und migriert die folgenden Ressourcen:
  • Router (zu Tier-1-Gateways)
  • Netzwerke (zu Segmenten)
  • Subnetze (zum Segmentieren von Subnetzen und zur DHCP-Konfiguration von Segmenten)
  • Port (zum Segmentieren von Ports und statischen DHCP-Bindungen)
  • Sicherheitsgruppen (für Sicherheitsrichtlinien, Regeln, Gruppen und Dienste)
  • Dynamische IPs (zu NAT-Regeln)
  • QoS-Richtlinien und -Regeln
  • FWaaS-Gruppen, Richtlinien und Regeln
  • Octavia Load Balancer, Listener, Pools, Mitglieder und Integritätsüberwachungen

Nach Abschluss der API-Wiedergabe wird der temporäre Neutron-Server-Pod heruntergefahren.

Überwachen Sie die Migrator-Pod-Protokolle mit dem Befehl tail. Wenn in den Protokollen angezeigt wird, dass der Migrator-Pod darauf wartet, dass der NSX-T-Migrationsvorgang gestartet wird, führen Sie die nächste Aufgabe (Edge-Übernahme) aus.

Edge-Übernahme

Befolgen Sie das Verfahren in Migrieren des vertikalen Datenverkehrs auf NSX-T Edges mit Edge-Übernahme. Nach dieser Migration wird der Nord-Süd-Datenverkehr von NSX-T verarbeitet. Der Migrationsvorgang wird:
  • Deaktivieren Sie die Schnittstellen der NSX-V-Edge-Appliance.
  • Aktivieren Sie ARP auf NSX-T-Tier-1-Downlink, um während der Migration einen nahtlosen Übergang des Ost-West- und Nord-Süd-Datenverkehrs sicherzustellen.
  • Stellen Sie eine Verbindung mit vCenter her, um ein NSX-V-Authentifizierungstoken abzurufen.
  • Bereiten Sie eine Zuordnungsdatei für verteilte Router (NSX-V DLRs) vor.
  • Richten Sie die Edge-Migration auf NSX-T ein und warten Sie, bis sie abgeschlossen ist.

Während der Nord-Süd-Umstellung verlieren VMs möglicherweise kurzzeitig die Konnektivität, da die Konnektivität von NSX-V-ESGs oder DLRs zu NSX-T-Tier-1-Gateways gewechselt wird. Nach Abschluss der Nord-Süd-Übernahme werden die NSX-V- und Metadaten-Edges ausgeschaltet. Der nächste Schritt ist die Hostmigration.

WICHTIG: Stellen Sie vor dem Starten der Nord-Süd-Übernahme nach einem Rollback sicher, dass die Edge-Zuordnungsdatei vorhanden ist. Die Datei wird nach einem Rollback automatisch gelöscht. Der Migratorauftrag wird ihn innerhalb von 10 Sekunden nach Abschluss des Rollbacks wiederherstellen. Dies gilt nicht, wenn in der NSX-V-VIO-Umgebung keine verteilten Router vorhanden sind.

Hinweis: Das NSX-V-Zugriffstoken wird bei jeder Pod-Ausführung erneuert. Die Dauer sollte lang genug sein, um sicherzustellen, dass die Migration innerhalb des Migrator-Pod-Lebenszyklus abgeschlossen wird. Wenn der Migrator-Pod aus irgendeinem Grund neu gestartet wird, wird ein neues Token abgerufen.

Hostmigration

Befolgen Sie das Verfahren inMigrieren von Hosts, Arbeitslasten und einer DFW-Konfiguration.

Das VIO-Migrationsdienstprogramm wird:
  • Schalten Sie alle NSX-V-Edge-Appliances aus.
  • Richten Sie die Hostmigration auf NSX-T ein.
  • Warten Sie, bis die Hostmigration erfolgreich abgeschlossen wurde.

Das Ausschalten der Edge-Appliances ist erforderlich, um sicherzustellen, dass die Hostmigration erfolgreich abgeschlossen wird. Schalten Sie die NSX-V-Edge-Appliances während der Hostmigration nicht ein.

Bereinigung nach der Migration

Der Migrator-Auftrag konfiguriert die Neutron-CR für die Verwendung von NSX-T neu, entfernt jedoch nicht die NSX-V-Konfigurationsparameter, sodass Sie sie als Referenz anzeigen können. Diese Parameter sind ungefährlich. Nach Abschluss der Migration können Sie sie mit dem Befehl viocli update neutron entfernen.

Protokollierung

Der Neutron-Migrator-Prozess erstellt eine detaillierte Protokollierung für jede Phase des Prozesses. Protokolle mit dem stdout des Pods befinden sich auf der INFO-Ebene. Debug-Level-Protokolle befinden sich unter /var/log/migration/vio-v2t.log auf dem VIO-Controller-Knoten, auf dem der Migrator-Pod ausgeführt wird.

Sie können mit dem folgenden Befehl ermitteln, auf welchem Knoten der neutron-migrator-Pod ausgeführt wird:
osctl get pods neutron-migrator -o wide

Sie können dann den Befehl viossh verwenden, um eine Shell auf dem Controller-Knoten zu öffnen.

Das Verzeichnis /var/log/migration enthält auch das temporäre Neutron-Serverprotokoll.

Rollback

Das Rollback kann während der Migration in verschiedenen Phasen erfolgen.

Wenn während der API-Wiedergabephase ein Fehler auftritt, ist kein explizites Rollback erforderlich. Das VIO-Neutron-Migrationsprogramm entfernt automatisch erstellte Ressourcen und versucht dann, die Migration erneut durchzuführen.

Wenn Sie die Migration durch Löschen des Neutron Migrator-Pods unterbrechen möchten, funktioniert die VIO-Steuerungsebene in NSX-V weiterhin. Möglicherweise wurden durch die API-Wiedergabe NSX-T-Ressourcen erstellt. Diese Ressourcen werden entfernt.

Beachten Sie, dass NSX-T kein Rollback der Hostmigration zulässt. Nach NSX-T migrierte Hosts können nicht mehr nach NSX-V verschoben werden.

Wenn während der Hostmigration ein Fehler auftritt, können Sie die Protokolle überprüfen und das Problem entsprechend beheben.

Alternativ können Sie, wenn ein Host durchgehend nicht zu NSX-T migriert werden kann, ihn aus dem vSphere-Cluster entfernen und die Migration erneut versuchen. Die auf dem betroffenen Host ausgeführten VMs werden auf andere Hosts im Cluster migriert. Installieren Sie nach der Migration NSX-T auf dem Host und fügen Sie es zum ursprünglichen vSphere-Cluster hinzu.

Fehlercodes

Code Beschreibung
0001, 0002, 0003, 0004 Ungültiger Systemzustand oder ungültige Konfiguration. Es gibt wichtige Probleme bei der Migration, wie z. B.:
  • Hostmigration bereits abgeschlossen, aber API-Wiedergabe wurde nicht durchgeführt.
  • VIO wird bereits mit NSX-T ausgeführt, aber die API-Wiedergabe oder -Migration wurde nicht durchgeführt.
  • Hosts auf NSX-T, VIO wird mit NSX-T ausgeführt. Die API-Wiedergabe wird aber nicht durchgeführt.
0101 Es können keine Konfigurationsdateien für den temporären Neutron-Server erstellt werden, der für die API-Wiedergabe aktiv sein muss. Überprüfen Sie die Pod-Protokolle des Migratorauftrags oder /var/log/migration/vio-v2t.log auf Fehler. Dieser Fehler kann in der Regel behoben werden, indem die Hauptursache mit Änderungen an der Konfigurationsdatei behoben wird.
1001 NSX-Migrationskoordinator wird nicht ausgeführt. Um diesen Fehler zu beheben, starten Sie den Migrations-Koordinator-Dienst auf dem ersten Knoten, der in migrator.conf.json angegeben ist. Wenn Sie HA-VIP verwenden, stellen Sie sicher, dass die aktive Manager-Instanz diejenige ist, auf der der Migrationskoordinator ausgeführt wird. Für die Migration wird empfohlen, einen bestimmten NSX Manager oder das clientseitige Load Balancing zu verwenden. NSX-T Manager-FQDNs können nach Abschluss der Migration geändert werden.
1002 Ungültige NSX-T-Version. NSX 3.2.0 oder höher ist erforderlich.
1003 NSX-T-Version kann nicht abgerufen werden. Überprüfen Sie die Pod-Protokolle des Migrator-Jobs oder /var/log/migration/vio-v2t.log auf Fehler.
1004 Fehler bei der Validierung des Compute Managers. In NSX-T muss mindestens ein Compute Manager definiert sein. Überprüfen Sie die Pod-Protokolle des Migrator-Jobs oder /var/log/migration/vio-v2t.log auf Fehler.
1005 Auf NSX-T muss eine Bereinigung durchgeführt werden. Das NSX-T-Setup verfügt bereits über von VIO erstellte Ressourcen. Stellen Sie sicher, dass rollback in migrator.conf.json auf True festgelegt ist.
1006 NSX-T-Migration kann nicht gestartet werden. Dies ist wahrscheinlich das Ergebnis eines vorherigen Migrationsversuchs. Setzen Sie alle laufenden Migrationen zurück und versuchen Sie es erneut.
1007 NSX-T kann nicht für Nord-Süd-Umstellung vorbereitet werden. Beim Einrichten der Nord-Süd-Umstellung auf NSX ist ein Fehler aufgetreten. Dies kann entweder ein Fehler beim Generieren der Datei „Edge-Zuordnungen“ oder ein Fehler beim Vorbereiten des Migrationsplans sein. Überprüfen Sie die Pod-Protokolle des Migrator-Jobs oder /var/log/migration/vio-v2t.log auf Fehler.
1008 Der Migrator-Pod kann Schnittstellen auf NSX-T Edge-Appliances nicht herunterfahren. Dies ist ein erforderlicher Schritt für die Nord-Süd-Übernahme. Überprüfen Sie die Pod-Protokolle des Migrator-Jobs oder /var/log/migration/vio-v2t.log auf Fehler. Um dieses Problem zu umgehen, legen Sie edge_migration_interfaces_down auf False in migrator.conf.json fest und stellen Sie manuell sicher, dass die Edge-Schnittstellen inaktiv oder getrennt sind, bevor Sie die Nord-Süd-Umstellung starten.
1009 Router ohne Downlinks können nicht migriert werden. Es gibt Neutron-Router ohne Downlinks. Diese können nicht migriert werden. Wenn der Operator der Ansicht ist, dass dieser Fehler versehentlich zurückgegeben wurde, kann er übersprungen werden, indem advanced_router_validation auf False in migrator.conf.json festgelegt wird.
1100 Ungültiger Modus im Migrationsplan. Der NSX-T-Migrationskoordinator ist bereits mit einem anderen Plan konfiguriert. Dies ist wahrscheinlich das Ergebnis eines vorherigen Migrationsversuchs. Setzen Sie alle laufenden Migrationen zurück und versuchen Sie es erneut.
1101 NSX-T-Migration wurde in der Konfiguration nicht bestätigt. Stellen Sie sicher, dass edge_migration und/oder host_migration in migration.conf.json auf True festgelegt sind.
1105 Router können ohne Gateway nicht gepatcht werden. Der Prozess zur Sicherstellung, dass Neutron-Router ohne Gateway nahtlos zu NSX-T migriert werden können, ist fehlgeschlagen. Überprüfen Sie die Pod-Protokolle des Migrator-Jobs oder die Datei /var/log/migration/vio-v2t.log auf Fehler. Wenn Sie advanced_router_validation auf „Falsch“ festlegen, wird dieser Vorgang übersprungen. Es ist jedoch Aufgabe des Operators sicherzustellen, dass jedes Tier-1-Gateway mit einem Tier-0-Router verbunden ist, bevor die Nord-Süd-Umstellung auf NSX-T gestartet wird.
1106 Router ohne Gateway können nicht wiederhergestellt werden. Der Prozess zur Wiederherstellung von Neutron-Routern ohne Gateway nach der Nord-Süd-Übernahme ist fehlgeschlagen. Überprüfen Sie die Pod-Protokolle des Migrator-Jobs oder die Datei /var/log/migration/vio-v2t.log auf Fehler. Durch die Einstellung von advanced_router_validation auf False wird dieser Prozess übersprungen. Es ist jedoch Aufgabe des Operators sicherzustellen, dass die Tier-1-Gateways für Neutron-Router ohne Gateways von den Tier-0-Gateways getrennt werden.
1110 Die Nord-Süd-Umstellungsmigration auf NSX-T kann nicht gestartet werden. Beim Anwenden des Migrationsplans ist ein Fehler aufgetreten. Überprüfen Sie die Pod-Protokolle des Migrator-Jobs oder /var/log/migration/vio-v2t.log auf Fehler.
1114 Fehlende VM für Edge-Appliances. Einige Edge-Appliances verfügen nicht über eine zugeordnete VM-Appliance. Entfernen Sie den entsprechenden Neutron-Router, sodass der Edge entfernt wird.
1115 NSX-V-Edge-VMs können vor der Hostmigration nicht ausgeschaltet werden. Überprüfen Sie die Pod-Protokolle des Migrator-Jobs oder /var/log/migration/vio-v2t.log auf Fehler. Sie können VMs manuell ausschalten. Dies ist erforderlich, um Probleme während der Laufzeitphase der Hostmigration zu vermeiden. Sie müssen mindestens DHCP- und Metadaten-Proxy-Edge-Appliances ausschalten.
1120 Hostmigration kann nicht gestartet werden. Beim Anwenden des Migrationsplans ist ein Fehler aufgetreten. Überprüfen Sie die Pod-Protokolle des Migrator-Jobs oder /var/log/migration/vio-v2t.log auf Fehlerdetails.
1130, 1131 Migration kann nicht abgeschlossen werden. Fehler beim Festlegen der Migration als abgeschlossen. Überprüfen Sie die Pod-Protokolle des Migrator-Jobs oder /var/log/migration/vio-v2t.log auf Fehler.
1132 Zeitüberschreitung während der Migration. Die Zeitüberschreitung für die Nord-Süd-Übernahme beträgt 12 Stunden. Die Zeitüberschreitung für die Hostmigration beträgt 48 Stunden. Wenn der Auftrags-Pod des Migrators auf den Start einer Migration wartet, kommt es schließlich zu einer Zeitüberschreitung. Operator muss ihn nur neu starten.
2001 Neutron-CR kann nicht von der VIO-Steuerungsebene abgerufen werden. Dies kann entweder ein Autorisierungsproblem oder ein Problem beim Erreichen der Kubernetes-Steuerungsebene von VIO sein. Überprüfen Sie die Pod-Protokolle des Migrator-Jobs oder /var/log/migration/vio-v2t.log auf Fehler.
2002 Neutron-CR kann nicht geparst werden. Stellen Sie sicher, dass im Abschnitt „'spec'“ ein 'manifests'-Attribut vorhanden ist.
2003 Ungültiger Inhalt in Neutron-CR. Stellen Sie sicher , dass das NSX-V-Plug-In aktiviert ist und alle anderen Plug-Ins, einschließlich des NSX-T Policy-Plug-Ins, deaktiviert sind.
2004 Neutron-CR kann nicht aktualisiert werden. Beim Aktualisieren der Neutron-CR ist ein Fehler aufgetreten. Überprüfen Sie die Pod-Protokolle des Migrator-Jobs oder /var/log/migration/vio-v2t.log auf Fehler. Dies kann entweder ein Fehler beim Aktualisieren der Neutron-CR, beim Erstellen der VIOSecret-Instanz für das NSX-T-Kennwort oder beim Erstellen von Ressourcen für NSX Manager sein. Stellen Sie sicher, dass diese Ressourcen bei einem vorherigen fehlgeschlagenen Versuch nicht veraltet gelassen wurden.
2011 Fehler beim Erstellen einer Datenbank für NSX-T mit Richtlinie. Dies ist wahrscheinlich ein SQL-Fehler. Überprüfen Sie die Pod-Protokolle des Migrator-Jobs oder /var/log/migration/vio-v2t.log auf Fehler.
2012 Fehler beim Umbenennen der Datenbank „neutron_policy“ in „neutron“ Dies ist wahrscheinlich ein SQL-Fehler. Überprüfen Sie die Pod-Protokolle des Migrator-Jobs oder /var/log/migration/vio-v2t.log auf Fehler.
2111 Der für die API-Wiedergabe verwendete temporäre Neutron-Server konnte nicht gestartet werden. Dies ist wahrscheinlich ein Fehler bei der Konfiguration des temporären Neutron-Servers. Überprüfen Sie /var/log/neutron-server-tmp.log auf Fehler.
2112 API-Wiedergabe fehlgeschlagen. Dies weist auf einen Fehler beim Erstellen von Ressourcen in NSX-T hin. Überprüfen Sie die Pod-Protokolle des Migrator-Auftrags oder /var/log/migration/vio-v2t.log auf Fehler. Protokolle zeigen an, welche Ressource nicht erstellt werden konnte. Überprüfen Sie dann /var/log/neutron-server-tmp.log auf Fehlerdetails. Häufige Fehlerursachen:
  • Falsche Transportzonen in temporärer Neutron-Serverkonfiguration
  • Nicht-OpenStack-Netzwerke mit demselben VLAN wie einige OpenStack-Netzwerke
  • Edge-Cluster verfügt über keine Steckplätze mehr für Load Balancer