Ersetzen eines NSX Edge-Transportknotens mithilfe der NSX Manager-Benutzeroberfläche

Das folgende Verfahren beschreibt, wie Sie über die NSX Manager-Benutzeroberfläche einen NSX Edge-Transportknoten in einem NSX Edge-Cluster ersetzen, der sowohl VM-NSX Edge- auch Bare Metal-NSX Edge-Transportknoten aufweist. Sie können einen VM-NSX Edge durch einen Bare Metal-NSX Edge und umgekehrt ersetzen. Sie können den Edge-Transportknoten unabhängig davon ersetzen, ob er ausgeführt wird oder nicht.

Voraussetzungen

Machen Sie sich mit der Vorgehensweise zum Installieren eines NSX Edge-Knotens vertraut, verbinden Sie den Edge-Knoten mit der Management Plane und erstellen Sie einen NSX Edge-Transportknoten. Weitere Informationen finden Sie im Dokument Installationshandbuch für NSX.
Sowohl VM-NSX Edge- als auch Bare Metal-NSX Edge-Transportknoten müssen über dieselbe VLAN-Konnektivität mit den physischen TOR-Switches verfügen.

Prozedur

Wenn Sie möchten, dass der neue NSX Edge-Transportknoten dieselben Konfigurationen wie der zu ersetzende NSX Edge-Transportknoten besitzt, führen Sie den folgenden API-Aufruf aus, um die Konfigurationen zu finden:

GET https://<nsx-manager-IP>/api/v1/transport-nodes/<tn-id>

An example output of a Bare Metal NSX Edge transport node.
{
  "node_id": "cd15d368-569b-11ed-8143-b07b25e93f64",
  "host_switch_spec": {
  "host_switches": [
   {
   "host_switch_name": "nsxHostSwitch",
   "host_switch_id": "809299a2-c090-4543-8747-d200e12cd2ea",
   "host_switch_type": "NVDS",
   "host_switch_mode": "STANDARD",
   "host_switch_profile_ids": [
   {
   "key": "UplinkHostSwitchProfile",
   "value": "57da58fa-bce6-448b-8db3-874ceff59656"
   },
   {
   "key": "LldpHostSwitchProfile",
   "value": "9e0b4d2d-d155-4b4b-8947-fbfe5b79f7cb"
   }
   ],
  "pnics": [
   {
   "device_name": "fp-eth1",
   "uplink_name": "lag-0"
   },
   {
   "device_name": "fp-eth3",
   "uplink_name": "lag-1"
   },
   {
   "device_name": "fp-eth5",
   "uplink_name": "lag-2"
   },
   {
   "device_name": "fp-eth7",
   "uplink_name": "lag-3"
   },
   {
   "device_name": "fp-eth0",
   "uplink_name": "Uplink3"
   },
   {
   "device_name": "fp-eth2",
   "uplink_name": "Uplink4"
   },
   {
   "device_name": "fp-eth4",
   "uplink_name": "Uplink5"
   },
   {
   "device_name": "fp-eth6",
   "uplink_name": "Uplink6"
    }
    ],
    "is_migrate_pnics": false,
    "ip_assignment_spec": {
    "ip_pool_id": "82f8ae96-992b-45c6-8376-777b82bfeb1d",
    "resource_type": "StaticIpPoolSpec"
    },
    "cpu_config": [],
    "transport_zone_endpoints": [
     {
    "transport_zone_id": "15897bda-802f-4481-b9fd-4e5cc1ef084b",
     "transport_zone_profile_ids": [
    {
    "resource_type": "BfdHealthMonitoringProfile",
    "profile_id": "52035bb3-ab02-4a08-9884-18631312e50a"
     }
     ]
     },
     {
     "transport_zone_id": "4a237a28-050e-4499-a241-0eb0c9dad97f",
     "transport_zone_profile_ids": [
     {
     "resource_type": "BfdHealthMonitoringProfile",
    "profile_id": "52035bb3-ab02-4a08-9884-18631312e50a"
     }
      ]
      }
    ],
    "pnics_uninstall_migration": [],
    "vmk_uninstall_migration": [],
    "not_ready": false
    }
    ],
    "resource_type": "StandardHostSwitchSpec"
    },
    "maintenance_mode": "DISABLED",
    "node_deployment_info": {
    "deployment_type": "PHYSICAL_MACHINE",
    "node_settings": {
    "hostname": "w1-hs2-m2716.eng.vmware.com",
    "enable_ssh": true,
    "allow_ssh_root_login": false,
    "enable_upt_mode": false
        },
        "resource_type": "EdgeNode",
        "external_id": "cd15d368-569b-11ed-8143-b07b25e93f64",
        "ip_addresses": [
            "10.196.145.177"
        ],
        "id": "cd15d368-569b-11ed-8143-b07b25e93f64",
        "display_name": "w1-hs2-m2716.eng.vmware.com",
        "tags": [],
        "_revision": 1
    },
    "is_overridden": false,
    "failure_domain_id": "4fc1e3b0-1cd4-4339-86c8-f76baddbaafb",
    "resource_type": "TransportNode",
    "id": "cd15d368-569b-11ed-8143-b07b25e93f64",
    "display_name": "w1-hs2-m2716.eng.vmware.com",
    "tags": [],
    "_create_time": 1666946274614,
    "_create_user": "admin",
    "_last_modified_time": 1666946708328,
    "_last_modified_user": "admin",
    "_system_owned": false,
    "_protection": "NOT_PROTECTED",
    "_revision": 1
}

Befolgen Sie das Verfahren im Thema Erstellen eines NSX Edge-Transportknotens im Installationshandbuch für NSX.

Wenn Sie möchten, dass dieser NSX Edge-Transportknoten dieselben Konfigurationen wie der zu ersetzende NSX Edge-Transportknoten aufweist, verwenden Sie die Konfigurationen, die Sie in Schritt 1 erhalten haben. In der API-Ausgabe aus Schritt 1 können Sie sich beispielsweise die Host-Switch-Spezifikationen und die Knotenbereitstellungsdetails notieren und den neuen NSX Edge-Transportknoten mit derselben Konfiguration konfigurieren.
Wählen Sie in NSX Manager System > Fabric > Knoten > Edge-Cluster aus.
Wählen Sie einen NSX Edge-Cluster aus, indem Sie auf das Kontrollkästchen in der ersten Spalte klicken.
Melden Sie sich per SSH bei den NSX Edge-Knoten an, auf denen Tier-0 gehostet wird.
Führen Sie get logical router aus. Überprüfen Sie auf allen NSX Edge-Knoten im NSX Edge-Cluster die VRF-ID für den Tier-0-Dienstrouter (SR).
Wenn die VRF-ID des Tier-0-SR „1“ lautet, führen Sie vrf 1 aus.
Überprüfen Sie die Ausgabe des Dienstrouters mit dem Befehl get high-availability status.
Aktivieren Sie den Wartungsmodus auf einem NSX Edge-Knoten, auf dem der Tier-0-SR im Standby-Modus ist. Führen Sie in der Edge-CLI-Konsole set maintenance-mode enabled aus.
Auf diesem NSX Edge-Knoten können Tier-1-SRs im Zustand „Aktiv“ sein. Beim Versetzen des NSX Edge-Knotens in den Wartungsmodus wird ein HA-Failover ausgelöst, bei dem alle Tier-1- oder Tier-0-SRs auf diesem NSX Edge-Knoten auf diesem NSX Edge-Knoten in den Standby-Zustand wechseln. Wegen des Failovers von Tier-1- oder Tier-0-SRs kann dies zu einer Unterbrechung des Datenverkehrs der aktiven SRs auf diesem NSX Edge-Knoten führen.
Stellen Sie sicher, dass der Bare Metal-NSX Edge-Transportknoten nicht Teil eines anderen Clusters ist.
Klicken Sie auf Aktionen > Edge-Clustermitglied ersetzen.
Es wird empfohlen, den zu ersetzenden Transportknoten in den Wartungsmodus zu versetzen. Wenn der Transportknoten nicht ausgeführt wird, können Sie diese Empfehlung ignorieren.
Wählen Sie den zu ersetzenden VM-NSX Edge-Transportknoten in der Dropdown-Liste aus.
Wählen Sie den Ersatzknoten für den Bare Metal-NSX Edge-Transportknoten in der Dropdown-Liste aus.
Klicken Sie auf Speichern.
Stellen Sie sicher, dass der Bare Metal-NSX Edge-Transportknoten in den vorhandenen Edge-VM-Cluster verschoben wurde.
Führen Sie get logical router aus, um sicherzustellen, dass Tier-0- und Tier-1-Gateways von der NSX Edge-VM (im Wartungsmodus) in den Bare Metal-NSX Edge-Transportknoten verschoben wurden.
Wiederholen Sie die vorherigen Schritte, um einen weiteren VM-NSX Edge mit Bare Metal-NSX Edge-Transportknoten zu verschieben.
Überprüfen Sie die vertikale und horizontale Konnektivität der Arbeitslasten, die mit Tier-1- oder Tier-0-LRs verbunden sind.

Ergebnisse

Wenn Sie eine NSX-Version vor 3.1.3 ausführen, wird nach dem Ersetzen des NSX Edge-Transportknotens möglicherweise der Alarm Alle BGP/BFD-Sitzungen sind inaktiv angezeigt. Um das Problem zu beheben, befolgen Sie die Anweisungen zur Problemumgehung im KB-Artikel https://kb.vmware.com/s/article/83983.

Nächste Maßnahme

Durch das Ersetzen einer VM-NSX Edge-VM durch einen Bare Metal-NSX Edge-Knoten werden die Tier-1-Gateways nicht automatisch neu auf NSX Edge-Knoten verteilt. Sie müssen jedes Tier-1-Gateway manuell neu konfigurieren.