Sie möchten eine NSX Edge-VM erneut bereitstellen, wenn Sie nicht mehr in Kraft ist oder Ihre Platzierung im Datencenter geändert werden muss. Wenn beispielsweise NSX Edge in einen anderen Datenspeicher oder eine andere Computing-Ressource verschoben werden muss, stellen Sie den NSX Edge-Knoten erneut bereit. Sie können den Knoten auch in ein anderes Netzwerk verschieben. Je nach Netzwerkanforderungen kann es jedoch auch andere Gründe für die erneute Bereitstellung geben.

Sie können einen vorhandenen NSX Edge-Knoten (physischer Server oder NSX Edge-VM-Appliance) nur mit einer NSX Edge-VM-Appliance erneut bereitstellen.

Voraussetzungen

  • Sie können zwar einige Konfigurationen der NSX Edge-Transportknotennutzlast ändern, Sie ändern jedoch diese Konfigurationen nicht auf dem vorhandenen NSX Edge-Knoten, der von einem neuen Knoten erneut bereitgestellt werden soll:
    • Fehlerdomäne
    • Konnektivität des Transportknotens
    • Konfiguration der physischen Netzwerkkarte
    • Logische Router
    • Load Balancer-Zuweisungen

  • Stellen Sie sicher, dass die Verbindung zwischen NSX Edge-Knoten und NSX Manager inaktiv ist, wenn der vorhandene NSX Edge-Knoten ein physischer Server oder eine manuell über vSphere Client bereitgestellte VM ist. Wenn die Verbindung aktiv ist, lässt NSX nicht zu, dass der vorhandene NSX Edge-Knoten durch einen neuen ersetzt wird.

  • Ein vorhandener, automatisch bereitgestellter NSX Edge behält die Hardwareversion 13 bei. Wenn die NSX Edge-VM erneut bereitgestellt wird, wird ab NSX 4.0.1.1 die neue NSX Edge-VM automatisch mit einer aktualisierten Hardwareversion bereitgestellt, die mit der ESXi-Hostversion kompatibel ist. VM-Hardwareversionen, die mit ESXi-Hosts kompatibel sind, werden im KB-Artikel 2007240 aufgelistet.

Prozedur

  1. (Physischer Server oder von NSX Edge über vSphere Client bereitgestellt) Öffnen Sie eine SSH-Sitzung und stellen Sie eine Verbindung zur NSX Edge-Konsole her.
  2. Überprüfen Sie die logischen Routen, die auf dem NSX Edge-Knoten über die CLI-Konsole konfiguriert wurden, get logical-routers.
  3. Schalten Sie den NSX Edge-Knoten aus.
  4. Stellen Sie sicher, dass der NSX Edge-Knoten von NSX Manager getrennt wird, indem Sie den folgenden API-Befehl ausführen.
    GET api/v1/transport-nodes/<edgenode>/state 
     "node_deployment_state": 
        {"state": MPA_Disconnected"}

    Der Wert node_deployment_state lautet MPA getrennt. Dies deutet darauf hin, dass Sie mit der erneuten Bereitstellung des NSX Edge-Knotens fortfahren können.

    Hinweis: Wenn node_deployment_state Knoten bereit lautet, zeigt NSX Manager einen Fehler an 78006 – Manager-Konnektivität zum Edge-Knoten muss inaktiv sein. Andernfalls ist der Austausch/die erneute Bereitstellung von Hardware nicht zulässig .
  5. Alternativ können Sie den Status der Verbindung zwischen NSX Edge-Knoten und NSX Manager auf der Seite Edge-Transportknoten anzeigen. Ein getrennter NSX Edge-Knoten zeigt die folgende Systemmeldung an: Konfigurationsfehler, Edge VM-MPA-Konnektivität ist inaktiv.
  6. Wenn der NSX Edge-Knoten ein automatisch bereitgestellter Knoten ist, führen Sie GET /<NSX-Manager-IPaddress>/api/v1/transport-nodes/<edgenode> aus. Kopieren Sie die Ausgabenutzlast dieser API. 
    "resource_type": "EdgeNode",
	        "id": "9f34c0ea-4aac-4b7f-a02c-62f306f96649",
	        "display_name": "Edge_TN2",
	        "description": "EN",
	        "external_id": "9f34c0ea-4aac-4b7f-a02c-62f306f96649",
	        "ip_addresses": [
	            "10.170.94.240"
	        ],
	        "_create_user": "admin",
	        "_create_time": 1600106319056,
	        "_last_modified_user": "admin",
	        "_last_modified_time": 1600106907312,
	        "_system_owned": false,
	        "_protection": "NOT_PROTECTED",
	        "_revision": 2
	    },
	    "is_overridden": false,
	    "failure_domain_id": "4fc1e3b0-1cd4-4339-86c8-f76baddbaafb",
	    "resource_type": "TransportNode",
	    "id": "9f34c0ea-4aac-4b7f-a02c-62f306f96649",
	    "display_name": "Edge_TN2",
	    "_create_user": "admin",
	    "_create_time": 1600106319399,
	    "_last_modified_user": "admin",
	    "_last_modified_time": 1600106907401,
	    "_system_owned": false,
	    "_protection": "NOT_PROTECTED",
	    "_revision": 1
	}
  7. Sie können eines der folgenden Szenarien für die erneute Bereitstellung auswählen:
    Auswahl Aktionen

    Stellen Sie einen vorhandenen NSX Edge-Knoten (physischer Server oder manuell bereitgestellter Knoten) mit einem NSX Edge-VM-Knoten erneut bereit (bereitgestellt über die NSX Manager-API)

    		 Führen Sie im API-Befehl Folgendes aus: /api/v1/transport-nodes/<transport-node-id>?action=redeploy
    • Fügen Sie die Nutzlast in den Textkörper der API für die erneute Bereitstellung ein.

    • Stellen Sie sicher, dass der Abschnitt deployment_config auf die Compute Manager-, Datenspeicher- und Netzwerkdetails verweist, in dem Sie den Knoten erneut bereitstellen möchten. Stellen Sie sicher, dass diese Werte mit den im Abschnitt node_settings verwendeten Werten übereinstimmen.

    • Fügen Sie im Abschnitt deployment_config Anmeldekennwörter hinzu.

    NSX Manager stellt den NSX Edge-Knoten basierend auf den im Abschnitt „deployment_config“ angegebenen Details erneut bereit.

    Ändern der Platzierung des vorhandenen NSX Edge-Knotens

    		 Führen Sie im API-Befehl Folgendes aus: /api/v1/transport-nodes/<transport-node-id>?action=redeploy
    • Fügen Sie die Nutzlast in den Textkörper der API für die erneute Bereitstellung ein.
    • Verweisen Sie im Abschnitt deployment_config auf die neuen Compute Manager-, Datenspeicher-, Netzwerk-, CPU-, Arbeitsspeicher- oder Wartezeitenaktivitätsdetails.
    Beispiel für POST https://<manager-ip>/api/v1/transport-nodes/<transport-node-id>?action=redeploy 
    	{
	    "node_id": "9f34c0ea-4aac-4b7f-a02c-62f306f96649",
	    "host_switch_spec": {
	        "host_switches": [
	            {
	                "host_switch_name": "nsxvswitch_overlay",
	                "host_switch_id": "c0a4a83e-c8b8-4324-a4d7-dbbc07b30b53",
	                "host_switch_type": "NVDS",
	                "host_switch_mode": "STANDARD",
	                "host_switch_profile_ids": [
	                    {
	                        "key": "UplinkHostSwitchProfile",
	                        "value": "f9a2a2fa-b49d-498f-abaf-2fdc81917716"
	                    },
	                    {
	                        "key": "LldpHostSwitchProfile",
	                        "value": "9e0b4d2d-d155-4b4b-8947-fbfe5b79f7cb"
	                    }
	                ],
	                "pnics": [
	                    {
	                        "device_name": "fp-eth0",
	                        "uplink_name": "uplink1"
	                    }
	                ],
	                "is_migrate_pnics": false,
	                "ip_assignment_spec": {
	                    "ip_pool_id": "647d9b0d-0143-4903-91f5-930d9ab011e8",
	                    "resource_type": "StaticIpPoolSpec"
	                },
	                "cpu_config": [],
	                "transport_zone_endpoints": [
	                    {
	                        "transport_zone_id": "0b33b078-6438-4d9b-a1ec-33211fd36822",
	                        "transport_zone_profile_ids": [
	                            {
	                                "resource_type": "BfdHealthMonitoringProfile",
	                                "profile_id": "52035bb3-ab02-4a08-9884-18631312e50a"
	                            }
	                        ]
	                    },
	                    {
	                        "transport_zone_id": "a0133574-48de-4e3a-9407-7db1a68bae41",
	                        "transport_zone_profile_ids": [
	                            {
	                                "resource_type": "BfdHealthMonitoringProfile",
	                                "profile_id": "52035bb3-ab02-4a08-9884-18631312e50a"
	                            }
	                        ]
	                    }
	                ],
	                "vmk_install_migration": [],
	                "pnics_uninstall_migration": [],
	                "vmk_uninstall_migration": [],
	                "not_ready": false
	            }
	        ],
	        "resource_type": "StandardHostSwitchSpec"
	    },
	    "transport_zone_endpoints": [],
	    "maintenance_mode": "DISABLED",
	    "node_deployment_info": {
	        "deployment_type": "VIRTUAL_MACHINE",
	        "deployment_config": {
	            "vm_deployment_config": {
	                "vc_id": "cc82da39-b119-4869-a7fe-a54621cb4d3d",
	                "compute_id": "domain-c9",
	                "storage_id": "datastore-14",
	                "host_id": "host-12",
	                "compute_folder_id": "group-v5",
	                "management_network_id": "network-16",
	                "hostname": "EdgeSmallFactor",
	                "data_network_ids": [
	                    "5638c577-e142-4a50-aed3-a7079dc3b08c",
	                    "5638c577-e142-4a50-aed3-a7079dc3b08c",
	                    "5638c577-e142-4a50-aed3-a7079dc3b08c"
	                ],
	                "search_domains": [
	                    "eng.vmware.com",
	                    "vmware.com"
	                ],
	                "enable_ssh": true,
	                "allow_ssh_root_login": true,
	                "reservation_info": {
	                    "memory_reservation": {
	                        "reservation_percentage": 100
	                    },
	                    "cpu_reservation": {
	                        "reservation_in_shares": "HIGH_PRIORITY",
	                        "reservation_in_mhz": 0
	                    }
	                },
	                "resource_allocation": {
	                    "cpu_count": 4,
	                    "memory_allocation_in_mb": 8192
	                },
	                "placement_type": "VsphereDeploymentConfig"
	            },
	            "form_factor": "MEDIUM",
	            "node_user_settings": {
	                 "cli_username": "admin",
                        "root_password":"Admin!23Admin", 
                        "cli_password":"Admin!23Admin" 
	            }
	        },
	        "node_settings": {
	            "hostname": "EdgeSmallFactor",
	            "search_domains": [
	                "eng.vmware.com",
	                "vmware.com"
	            ],
	            "enable_ssh": true,
	            "allow_ssh_root_login": true
	        },
	        "resource_type": "EdgeNode",
	        "id": "9f34c0ea-4aac-4b7f-a02c-62f306f96649",
	        "display_name": "Edge_TN2",
	        "description": "EN",
	        "external_id": "9f34c0ea-4aac-4b7f-a02c-62f306f96649",
	        "ip_addresses": [
	            "10.170.94.240"
	        ],
	        "_create_user": "admin",
	        "_create_time": 1600106319056,
	        "_last_modified_user": "admin",
	        "_last_modified_time": 1600106907312,
	        "_system_owned": false,
	        "_protection": "NOT_PROTECTED",
	        "_revision": 2
	    },
	    "is_overridden": false,
	    "failure_domain_id": "4fc1e3b0-1cd4-4339-86c8-f76baddbaafb",
	    "resource_type": "TransportNode",
	    "id": "9f34c0ea-4aac-4b7f-a02c-62f306f96649",
	    "display_name": "Edge_TN2",
	    "_create_user": "admin",
	    "_create_time": 1600106319399,
	    "_last_modified_user": "admin",
	    "_last_modified_time": 1600106907401,
	    "_system_owned": false,
	    "_protection": "NOT_PROTECTED",
	    "_revision": 1
	}
    Hinweis: Wenn es sich bei dem alten Knoten um einen NSX Edge-VM-Knoten handelt, der über die NSX Manager-Benutzeroberfläche bereitgestellt wird, müssen Sie im node_user_settings-Abschnitt in der API-Nutzlast keine Anmeldedaten angeben.
    Weitere Informationen zu den Nutzlastdetails finden Sie im Handbuch zu NSX-API.
  8. Überprüfen Sie in NSX Manager den Konfigurationsstatus des neuen NSX Edge-Knotens.
  9. Überprüfen Sie alternativ den Status des neu vorbereiteten NSX Edge-Transportknotens, indem Sie den API-Befehl Get api/v1/transport-nodes/<node-id>/state ausführen.
  10. Überprüfen Sie, ob die Konfigurationen des logischen Routers zu dem neuen NSX Edge-Knoten migriert werden, indem Sie den CLI-Befehl get logical-routers ausführen.
  11. Stellen Sie sicher, dass die TEP-Adresse auf dem ersetzten NSX Edge-Knoten unverändert bleibt.
  12. Stellen Sie sicher, dass der NSX Edge-Clusterstatus „Aktiv“ lautet. API ist GET api/v1/edge-clusters/<cluster>. Wenn NSX für die Verwendung von NSX-Verbund konfiguriert ist, stellen Sie sicher, dass der siteübergreifende Status „Aktiv“ lautet.
  13. Überprüfen Sie den NSX Edge-Transportknoten und die Clusterstatus-API, um sicherzustellen, dass der Status „Aktiv“ lautet.
  14. Beheben Sie Fehlermeldungen:

    • (78006) NSX Manager-Konnektivität zum Edge-Knoten muss inaktiv sein. Andernfalls ist der Austausch der Hardware nicht zulässig: Stellen Sie sicher, dass der NSX Edge-Knoten nicht mit NSX Manager verbunden ist.

    • (16064) Bereitstellungskonfiguration fehlt: Geben Sie in der API für die erneute Bereitstellung Details für den Abschnitt deployment_config ein.

    • (16066) Anmeldekennwort fehlt: Geben Sie Anmeldedaten an.

    • (15019) Unzureichende Ressourcen auf dem Knoten, der dem Load Balancer-Pool zugeteilt werden soll: Die Formfaktorgröße des neuen NSX Edge-Knotens ist möglicherweise kleiner als der Formfaktor des alten NSX Edge-Knotens. Der neue Formfaktor verfügt möglicherweise nicht über genügend Ressourcen, um dem Load Balancer-Pool zugeteilt zu werden.

Nächste Maßnahme

  • Wenn Sie einen ersetzten physischen Server oder eine manuell bereitgestellte NSX Edge-VM-Appliance als Teil Ihres Netzwerks einsetzen möchten, stellen Sie sicher, dass der Knoten vom Netzwerk getrennt ist. Führen Sie dann del nsx aus, um NSX-VIBs auf dem Knoten vollständig zu löschen. Weitere Informationen zu del nsx finden Sie im Installationshandbuch für NSX.

    Nachdem Sie den Befehl „del nsx“ auf dem Host ausgeführt haben, werden alte Einträge von logischen Routern, VTEP-IP-Adressen, IP-Adressen für Uplinks freigegeben. Sie können jetzt den ersetzten physischen Server als neuen NSX-Transportknoten vorbereiten.

  • Nach der erneuten Bereitstellung einer NSX Edge-VM-Appliance werden einige Sicherheitsparameter auf ihre Standardwerte festgelegt. Konfigurieren Sie diese Parameter für Ihre Umgebung erneut.
    • set auth-policy minimum-password-length <password-length-arg>

      Legen Sie die Mindestanzahl der Zeichen in Kennwörtern fest. Der kleinstmögliche Wert ist 8

      Beispiel: nsx> set auth-policy minimum-password-length 12

    • set user <node-username> password-expiration <password-expiration-arg>

      Legen Sie fest, wie viele Tagen das Kennwort des Benutzers nach einer Kennwortänderung gültig bleibt.

      Dabei sind <username> der Benutzername des Benutzers,

      <password-expiration> die Anzahl der Tage, die das Kennwort nach der Änderung gültig bleibt (1-9999)

      Beispiel: nsx> set user audit password-expiration 120

    • set auth-policy cli max-auth-failures <auth-failures-arg>

      Legen Sie die maximal zulässige Anzahl fehlgeschlagener Anmeldeversuche fest, nach denen das Konto gesperrt wird. Wenn Sie den Wert „0“ festlegen, wird die Kontosperrung deaktiviert.

      <auth-failures> gibt die Anzahl der Authentifizierungsfehler bis zum Auslösen der Sperrung an

      Beispiel: nsx> set auth-policy cli max-auth-failures 5

    • set banner

      Legen Sie das Sicherheitsbanner oder die Meldung des Tages fest.

      Beispiel: nsx> set banner

      TEXT-Nachricht eingeben. Mit „Strg-D“ beenden

    • reset dataplane hugepage

      Setzen Sie die Hugepage-Startzeitoption auf die Werkseinstellungen zurück.

      Zum Beispiel

      nsx-edge-1> reset dataplane hugepage

      0000:0b:00.0 already bound to driver vfio-pci, skipping
0000:1b:00.0 already bound to driver vfio-pci, skipping
0000:13:00.0 already bound to driver vfio-pci, skipping
INFO: Config was written to: /config/vmware/edge/config.json
Generating grub configuration file ...
Found linux image: /vmlinuz-3.14.17-nn4-server
Found initrd image: //initrd.img-3.14.17-nn4-server
File descriptor 4 (/tmp/ffinvYglp (deleted)) leaked on lvs invocation. Parent PID 32203: /bin/sh
done
INFO: Updated grub. Please reboot to take effect.