IaaS Control Plane – Wrong NSX Edge cluster for T1 placement
Ich hatte kürzlich eine IaaS Control Plane (ehem. vSphere with Tanzu) Umgebung auf vSphere 8.0.3 aktualisiert.
Ich hatte kürzlich eine IaaS Control Plane (ehem. vSphere with Tanzu) Umgebung auf vSphere 8.0.3 aktualisiert. Dabei lief alles einwandfrei und der Betrieb konnte nach dem Upgrade wie gewohnt fortgeführt werden. Als ich für ein paar neue Dashboards in VMware Aria Operations for Logs für die NSX T1 Gateways der vSphere Namespaces erstellen wollte, ist mir aufgefallen, dass die T1 SR Instanzen nicht auf dem vorgesehenen NSX Edge Cluster instanziiert wurden. Der NSX Edge Cluster Setup für den Supervisor Cluster sieht dabei wie folgt aus:
Dabei wird der T0 Gateway des Supervisor Clusters auf dem Edge Cluster 1 gehostet, während sämtliche T1 Gateways der vSphere Namespaces auf dem Edge Cluster 2 gehostet werden.
Das Problem
Die Tatsache, dass die T1 SR Instanzen der vSphere Namespaces nicht auf dem vorgesehen NSX Edge Cluster instanziiert wurden, liess auf ein Problem im Creation Workflow der vSphere Namespaces schliessen. Dabei habe ich zuerst versucht zu verstehen, ob das Verhalten dabei konsistent ist.
Ich habe dazu einen vSphere Namespace mit und einen ohne Network Overrides erstellt. Dabei wurde der vSphere Namespace ohne Network Overrides auf dem vorgesehen dedizierten T1 Edge Cluster bereitgestellt, während der vSphere Namespace mit Network Overrides auf dem Edge Cluster bereitgestellt wurde, auf welchem sich auch der T0 Gateway des Supervisor System Namespace befindet.
Nach dem ich in den Logs keine Indikatoren für ein Problem finden konnte, eröffnete ich eine VMware SR und nach kurzer Zeit war die Ursache auch schon klar. Mit dem Update auf vSphere 8.0.3 wurde auch das Verhalten der T1 Bereitstellung geändert.
Dabei gilt neu ab vSphere 8.0.3 folgendes Verhalten:
- Wenn ein vSphere Namespace mit Network Overrides erstellt wird, werden die T1 SRs auf dem Edge Cluster platziert, welcher die T0 SRs des neuen vSphere Namespace hostet.
- Wenn keine Network Overrides angegeben werden, werden die T1 SRs auf dem Standard Edge Cluster gem. Supervisor Network Configuration instanziiert.
Aber wie kann ich nun meine neuen vSphere Namespaces mit Network Overrides auf dem vorgesehenen Edge Cluster instanziieren?
Die Lösung
Falls nach dem vSphere 8.0.3 Update bereits neue vSphere Namespaces angelegt wurden oder neue geplant sind, dann muss vorerst auf folgenden Workaround zurückgegriffen werden:
# [STEP-1]
# Login to a NSX manager via root user
# Get the respective T1 gateway ID of the newly created vSphere Namespace
curl -k -u 'admin:PASSWORD' --request GET 'https://localhost/policy/api/v1/infra/tier-1s' | grep VSPHERE_NAMESPACE_T1_NAME-rtr -B 1
"id" : "t1_778759f1-e306-3322-8fe4-6ddkjh658b09_rtr",
"display_name" : "t1-domain-c5008:23e875a6-44gf-4814-94ff-e840ghm7bc03-VSPHERE_NAMESPACE_T1_NAME-rtr",
# [STEP-2]
# Get the locale-services ID of the respective T1 gateway
# locale-servces ID = t1_778759f1-e306-3322-8fe4-6ddkjh658b09_rtr-0
curl -k -u 'admin:PASSWORD' --request GET 'https://localhost/policy/api/v1/infra/tier-1s/t1_778759f1-e306-3322-8fe4-6ddkjh658b09_rtr/locale-servces'
{
"results" : [ {
"edge_cluster_path" : "/infra/sites/default/enforcement-points/default/edge-clusters/294ss994-8128-4217-aa42-a182b954ak8b",
"resource_type" : "LocaleServices",
"id" : "t1_778759f1-e306-3322-8fe4-6ddkjh658b09_rtr-0",
"display_name" : "t1_778759f1-e306-3322-8fe4-6ddkjh658b09_rtr-0",
"path" : "/infra/tier-1s/t1_778759f1-e306-3322-8fe4-6ddkjh658b09_rtr/locale-services/t1_778759f1-e306-3322-8fe4-6ddkjh658b09_rtr-0",
"relative_path" : "t1_778759f1-e306-3322-8fe4-6ddkjh658b09_rtr-0",
"parent_path" : "/infra/tier-1s/t1_778759f1-e306-3322-8fe4-6ddkjh658b09_rtr",
"remote_path" : "",
"unique_id" : "84ca333a-8619-d3f31-a108-13d222c4c349",
"realization_id" : "84ca333a-8619-d3f31-a108-13d222c4c349",
"owner_id" : "48cb77bb-9t43-4285-a245-b2117f8a8b87",
"marked_for_delete" : false,
"overridden" : false,
"_create_time" : 1730469777339,
"_create_user" : "wcp-cluster-user-380fdd7d-6f2c-4cdw-82df-fb7dfddd1b9b-dbd7f126-633c-4a13-badf-f5wwd8cfd11e",
"_last_modified_time" : 1732889723175,
"_last_modified_user" : "admin",
"_system_owned" : false,
"_protection" : "REQUIRE_OVERRIDE",
"_revision" : 1
} ],
"result_count" : 1,
"sort_by" : "display_name",
"sort_ascending" : true
# Verify the associated edge cluster in the 'edge_cluster_path' parameter
curl -k -u 'admin:PASSWORD' --request GET 'https://localhost/policy/api/v1/infra/sites/default/enforcement-points/default/edge-clusters' | grep '\"id\" : \"294ss994-8128-4217-aa42-a182b954ak8b\"' -A 1
"id" : "294ss994-8128-4217-aa42-a182b954ak8b",
"display_name" : "k8s-t0-ec",
# [STEP-3]
# Get the 'path' parameter of the desired T1 edge cluster
# Current edge cluster = 294ss994-8128-4217-aa42-a182b954ak8b
# Desired edge cluster = 486hc7c3-2d29-ad51-b6c3-ff52alo86f4b
curl -k -u 'admin:PASSWORD' --request GET 'https://localhost/policy/api/v1/infra/sites/default/enforcement-points/default/edge-clusters'
{
"results" : [ {
"nsx_id" : "294ss994-8128-4217-aa42-a182b954ak8b",
"inter_site_forwarding_enabled" : false,
"member_node_type" : "EDGE_NODE",
"resource_type" : "PolicyEdgeCluster",
"id" : "294ss994-8128-4217-aa42-a182b954ak8b",
"display_name" : "k8s-t0-ec",
"tags" : [ ],
"path" : "/infra/sites/default/enforcement-points/default/edge-clusters/294ss994-8128-4217-aa42-a182b954ak8b",
"relative_path" : "294ss994-8128-4217-aa42-a182b954ak8b",
"parent_path" : "/infra/sites/default/enforcement-points/default",
"remote_path" : "",
"unique_id" : "294ss994-8128-4217-aa42-a182b954ak8b",
"realization_id" : "294ss994-8128-4217-aa42-a182b954ak8b",
"owner_id" : "48cb77bb-9t43-4285-a245-b2117f8a8b87",
"marked_for_delete" : false,
"overridden" : false,
"_create_time" : 1702468345681,
"_create_user" : "admin",
"_last_modified_time" : 1702471331793,
"_last_modified_user" : "admin",
"_system_owned" : false,
"_protection" : "NOT_PROTECTED",
"_revision" : 1
}, {
"nsx_id" : "486hc7c3-2d29-ad51-b6c3-ff52alo86f4b",
"inter_site_forwarding_enabled" : false,
"member_node_type" : "EDGE_NODE",
"resource_type" : "PolicyEdgeCluster",
"id" : "486hc7c3-2d29-ad51-b6c3-ff52alo86f4b",
"display_name" : "k8s-t1-ec",
"tags" : [ ],
"path" : "/infra/sites/default/enforcement-points/default/edge-clusters/486hc7c3-2d29-ad51-b6c3-ff52alo86f4b",
"relative_path" : "486hc7c3-2d29-ad51-b6c3-ff52alo86f4b",
"parent_path" : "/infra/sites/default/enforcement-points/default",
"remote_path" : "",
"unique_id" : "486hc7c3-2d29-ad51-b6c3-ff52alo86f4b",
"realization_id" : "486hc7c3-2d29-ad51-b6c3-ff52alo86f4b",
"owner_id" : "48cb77bb-9t43-4285-a245-b2117f8a8b87",
"marked_for_delete" : false,
"overridden" : false,
"_create_time" : 1702468349973,
"_create_user" : "admin",
"_last_modified_time" : 1702471337162,
"_last_modified_user" : "admin",
"_system_owned" : false,
"_protection" : "NOT_PROTECTED",
"_revision" : 1
} ],
"result_count" : 2,
"sort_by" : "display_name",
"sort_ascending" : true
# [STEP-4]
# Update the 'edge_cluster_path' parameter in the T1 locale-services from step 2 to the desired T1 edge cluster path from step 3
curl -k -u 'admin:PASSWORD' \
--request PUT 'https://localhost/policy/api/v1/infra/tier-1s/t1_778759f1-e306-3322-8fe4-6ddkjh658b09_rtr/locale-servces/t1_778759f1-e306-3322-8fe4-6ddkjh658b09_rtr-0' \
--header 'X-Allow-Overwrite: True' \
--header 'Content-Type: application/json' \
--data-raw '{
"edge_cluster_path": "/infra/sites/default/enforcement-points/default/edge-clusters/486hc7c3-2d29-ad51-b6c3-ff52alo86f4b",
"_revision": 0
}'Achtung: Eine SR Relocation ist ein destruktiver Vorgang, bei der mit kurzen Verbindungsunterbrüchen zu den Workloads an dem betroffenen T1 Gateway gerechnet werden muss.
Der grundsätzliche Vorgang ist einfach und kurz erklärt:
- Die NSX Object ID des betroffenen T1 Gateway ermitteln
- Die locale-services ID des betroffenen T1 Gateways ermitteln
- Sämtliche Edge Cluster der NSX Domain abfragen
- deren Path Parameter mit jenem aus dem edge_cluster_path Parameter des betroffenen T1 Gateways vergleichen
- den Path Parameter des korrekten Edge Clusters ermitteln
- Den edge_cluster_path Parameter des betroffenen T1 Gateways mit dem Path Parameter des korrekten Edge Clusters ersetzen
Nach dem der PUT Request übermittelt wurde, beginnt NSX damit, die T1 SR Instanzen auf den gewünschten Edge Cluster zu platzieren.
