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
- Installieren Sie NSX-T.
- 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.
- Rufen Sie das Neutron-Migrator-Paket ab, das Teil des VIO-Lieferumfangs ist.
- Konfigurieren Sie den Neutron-Migrator.
- Stellen Sie den Neutron-Migrations-Pod bereit.
- Ü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.
- Warten Sie, bis der Neutron-Migrations-Pod abgeschlossen ist.
- Löschen Sie die Neutron-Migrationsbereitstellung.
- 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.)
- 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
- 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.
{ "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
./build_yaml.sh -t 7.1.1.1899999
-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
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
- 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.
- 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. Mit dieser Prüfung wird sichergestellt, dass dies der Fall ist.
- Auf NSX-T sollte keine Neutron-Ressource konfiguriert werden. Wenn die Rollback-Option auf „True“ festgelegt ist, bereinigt der Migrationsvorgang alle (wahrscheinlich veralteten) Neutron-Ressourcen, die auf NSX-T gefunden werden.
Nach Abschluss der Prüfungen initialisiert der Migrationsvorgang 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 ist 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.
- 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
curl -v -s -X GET -k -u admin:<password> https://<nsx-mgr-ip>/api/v1/transport-nodes/ -H content-type:application/json
curl -v -s -X PUT -k -u admin:<password> https://<nsx-mgr-ip>/api/v1/transport-nodes/<edge-nodeid>/node/v2t-migration-config -H content-type:application/json -d '{"enabled": true}'
- 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.
- 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.
curl -v -s -X PUT -k -u admin:<password> https://<nsx-mgr-ip>/api/v1/transport-nodes/<edge-nodeid>/node/v2t-migration-config -H content-type:application/json -d '{"enabled":false}'
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.
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 Control Plane 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.:
|
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 | Die 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 ausgefü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 | Die 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-Übernahmemigration zu 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-Jobs oder die Datei /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:
|