Knoten in einem vSphere-Cluster hinzufügen oder entfernen

In diesem Dokument wird beschrieben, wie Sie einen oder mehrere Compute Engine-Bare-Metal-Knoten zu einem vorhandenen vSphere-Cluster hinzufügen (Clustererweiterung) und einen oder mehrere Knoten aus einem Cluster entfernen (Clusterkomprimierung) in VMware Cloud Foundation (VCF) 9.1 in der VMware-Lösung in Google Cloud. Erweitern oder komprimieren Sie einen Cluster, wenn Sie die Rechen- und vSAN-Speicherkapazität eines vorhandenen Clusters in der Verwaltungsdomain oder einer VI-Arbeitslastdomain erhöhen oder verringern müssen. Das Verfahren ist dasselbe, unabhängig davon, ob Sie einen einzelnen Knoten oder mehrere Knoten hinzufügen oder entfernen: Listen Sie einen oder mehrere Knoten in der Umgebungsvariablen ADD_HOSTS oder REMOVE_HOSTS auf.

Zusammenfassung der Architektur

Wenn Sie Knoten in einem vorhandenen vSphere-Cluster hinzufügen oder entfernen, verwendet der Workflow die folgende Architektur:

  • Knoten hinzufügen: Jeder neue Knoten ist eine z3-highmem-192-highlssd-metal-Bare-Metal-Instanz, die Sie in derselben Zone, mit derselben Platzierungsrichtlinie und demselben Maschinentyp wie die vorhandenen Knoten des Clusters bereitstellen. Jeder Knoten hat eine primäre Netzwerkschnittstelle (nic0) im ESXi-Verwaltungssubnetz Ihres VPC-Netzwerks (Virtual Private Cloud) und mit VLAN-Tags versehene Dynamic Network Interfaces für vMotion, vSAN und NSX-Tunnelendpunkt (TEP). Der Knoten wird den vorhandenen zonalen Netzwerk-Endpunktgruppen (NEGs) hinzugefügt. Anschließend nehmen Sie den Knoten im SDDC Manager mit dem Netzwerkpool des Clusters in Betrieb und fügen ihn dem Cluster hinzu.
  • Knoten entfernen: Sie entfernen zuerst den Knoten aus dem Cluster in VCF. Dadurch werden die Arbeitslast-VMs migriert und die vSAN-Daten des Hosts entfernt. Anschließend nehmen Sie den Host aus SDDC Manager außer Betrieb und entfernen ihn aus den zonalen NEGs, bevor Sie die zugrunde liegende Compute Engine-Bare-Metal-Instanz löschen.
  • IP-Adressausrichtung: Wie bei der Clustererstellung weist VCF vMotion- und vSAN-IP-Adressen aus dem Netzwerkpool des Clusters zu und NSX weist TEP-IP-Adressen (vmk10) aus dem NSX-IP-Adresspool zu. Sie richten die Compute Engine Dynamic NICs der neuen Knoten an den von VCF zugewiesenen IP-Adressen aus, während alle VCF-Validierungen aktiviert bleiben.
  • Keine Änderungen an der Appliance: Wenn Sie Clusterknoten hinzufügen oder entfernen, sind keine neuen Cloud DNS-Einträge, Backend-Dienste, Hochverfügbarkeitsrichtlinien oder Weiterleitungsregeln für Verwaltungs-Appliances erforderlich.

Hinweis

Bevor Sie Knoten hinzufügen oder entfernen, prüfen Sie die Anforderungen in den folgenden Abschnitten und konfigurieren Sie Ihre Umgebungsvariablen.

Umgebungsanforderungen prüfen

Prüfen Sie, ob Ihre Umgebung die folgenden Anforderungen erfüllt:

  • Berechtigungen: Sie haben die erforderlichen IAM-Rollen (Identity and Access Management) für das Zielprojekt, einschließlich Compute-Administrator (roles/compute.admin), DNS-Administrator (roles/dns.admin) und Secret Manager Secret Accessor (roles/secretmanager.secretAccessor).
  • Anmeldedaten in Secret Manager: Wenn Sie Ihre Passwörter für ESXi root, SDDC Manager, vCenter Server oder NSX Manager in VCF nach der ersten Bereitstellung geändert oder rotiert haben, wird Secret Manager nicht automatisch aktualisiert. Bevor Sie die Befehle in diesem Dokument ausführen, aktualisieren Sie die entsprechenden Secrets in Secret Manager oder geben Sie die aktualisierten Passwörter direkt an, damit sie mit Ihren aktiven VCF-Anmeldedaten übereinstimmen.
  • Cluster- und Domainzustand: Der Zielcluster und seine Domain sind fehlerfrei (vCenter Server, vSAN, NSX Manager, SDDC Manager und VCF Operations) und es gibt keine fehlgeschlagenen Aufgaben.

  • Knoten hinzufügen:

    • Ihr Projekt hat ein ausreichendes z3-Bare-Metal-Kontingent in der Zielregion und -zone.
    • Die neuen Knoten verwenden denselben Maschinentyp wie die vorhandenen Knoten im Cluster (z3-highmem-192-highlssd-metal für vSAN Express Storage Architecture (ESA)) und werden der vorhandenen Platzierungsrichtlinie des Clusters zugewiesen (jede Platzierungsrichtlinie gehört nur zu einem Cluster).
    • Jeder neue Knoten hat lokale NVMe-SSD-Geräte ohne vorhandene Partitionen.
    • Wenn Ihre Organisation die Organisationsrichtlinie constraints/compute.trustedImageProjects erzwingt oder einen VPC Service Controls-Dienstperimeter verwendet, muss Ihr Projekt Image-Zugriff auf das Projekt smve-prod-public-images (projects/999037279871) zulassen. Weitere Informationen finden Sie unter Knotenkapazität verwalten.

    • VLAN-basiertes Netzwerk: Für die VMware-Lösung muss die Eigenschaft Subnetzmaske auflösen der Subnetze Ihres VPC-Netzwerks auf Primären Bereich nur mit Lernen übertragen festgelegt sein, um VLAN-basierte Netzwerke zu unterstützen. Öffnen Sie im Google Cloud Console-Supportcenter ein Support-Ticket mit den folgenden Informationen:

      • Produkt: Google Cloud VMware Engine
      • Priorität: P2
      • Kategorie: Network Connectivity
      • Auswirkungen auf das Geschäft: Allgemeine technische Frage
      • Geben Sie weitere Details an: Allowlist L2 network connectivity for my project, zusammen mit Ihrer Projekt-ID, Projektnummer und der Zielregion und -zone für Ihre Bereitstellung.

      Weitere Informationen zur Unterstützung von VLAN-basierten Netzwerken finden Sie unter Layer-2-Emulation: ARP-Broadcasting und benutzerdefiniertes MAC-Learning.

  • So entfernen Sie Knoten:

    • Die verbleibenden Knoten haben genügend Rechen- und vSAN-Speicherkapazität für Ihre aktiven Arbeitslasten.
    • Nach dem Entfernen des Knotens enthält der Cluster mindestens drei Knoten (die Mindestanzahl für vSAN mit einer Fehlertoleranz (FTT=1)) oder die Mindestanzahl von Hosts, die Ihre aktiven Speicherrichtlinien erfordern (siehe vSAN-Fehlertoleranz und Hostanzahl).

  • Jumpbox-VM: Sie haben Zugriff auf eine Jumpbox-VM, auf der die gcloud-Befehlszeile, curl und jq installiert sind und die eine Netzwerkverbindung zum VPC-Netzwerk hat (z. B. im Subnetz bm-gcp-demo).

Beispielumgebungsparameter prüfen

In den Befehlen in diesem Dokument werden die folgenden Beispielparameter verwendet:

Eingabeparameter Beispielwert Beschreibung
Projekt-ID, Region und Zone PROJECT_ID / us-east4 / us-east4-b Dasselbe Projekt, dieselbe Region und dieselbe Zone wie der Zielcluster
Kunden-ID demo In vorhandenen Ressourcennamen verwendete Kennung
Zielcluster cl02 (esxi-h7, esxi-h8, esxi-h9) Vorhandener Cluster in der Verwaltungsdomain oder einer VI-Arbeitslastdomain
Platzierungsrichtlinie bm-cl02 Vorhandene Platzierungsrichtlinie für Gruppen des Clusters
Netzwerkpool und VDS cl02-np01/cl02-vds-01 Vorhandener Netzwerkpool und vSphere Distributed Switch (VDS) des Clusters
NSX-TEP-IP-Pool cl02-tep-pool Vorhandener NSX-IP-Adresspool des Clusters
NSX Manager nsx01.vmware.gve NSX Manager der Clusterdomain (oder nsx05.vmware.gve für die Arbeitslastdomain wld01 mit einer dedizierten NSX-Instanz)
Maschinentyp z3-highmem-192-highlssd-metal Gleicher Maschinentyp wie die vorhandenen Knoten im Cluster
VPC-Netzwerk und Subnetze (VLAN-ID) bm-demo; bm-mgmt-demo (ohne Tag), bm-vmotion-demo (2), bm-vsan-demo (3), bm-nsx-demo (4) Vorhandenes VPC-Netzwerk und Layer-2-Subnetze
Zonale NEGs bm-mgmt-demo, bm-nsx-tep-demo Vorhandene Verwaltungs- und NSX-TEP-NEGs
SDDC Manager sddcm.vmware.gve (192.168.0.3) Vorhandene SDDC Manager-Appliance
ESXi-root-Passwort esxi-root-password Vorhandenes Secret Manager-Secret, das das ESXi-root-Passwort enthält

IP-Adressen und Hostnamen planen

Im folgenden Beispiel werden dem Cluster cl02 zwei Knoten (esxi-h10 und esxi-h11) hinzugefügt und dann einer davon (esxi-h11) entfernt. Wenn Sie einen einzelnen Knoten hinzufügen oder entfernen möchten, fügen Sie nur diesen Knoten in das Array der Umgebungsvariablen ein:

ESXi-Host Verwaltungs-IP (nic0) vMotion (VLAN 2) vSAN (VLAN 3) NSX TEP (VLAN 4) Verfügbarkeitsdomain Aktion
esxi-h10 192.168.0.164 192.168.2.24 192.168.3.24 192.168.4.24 4 Hinzufügen
esxi-h11 192.168.0.165 192.168.2.25 192.168.3.25 192.168.4.25 5 Hinzufügen, dann entfernen

Verteilen Sie die Knoten des Clusters auf Verfügbarkeitsdomains innerhalb der Platzierungsrichtlinie des Clusters: Da die vorhandenen Knoten (esxi-h7 bis esxi-h9) die Verfügbarkeitsdomains 1 bis 3 verwenden, verwenden die neuen Knoten die Verfügbarkeitsdomains 4 und 5.

Regionales Kontingent prüfen

Bevor Sie Bare-Metal-Knoten bereitstellen oder einen Cluster erstellen, prüfen Sie, ob Ihr Projekt über ein ausreichendes regionales und globales Compute Engine-Kontingent verfügt. Fügen Sie die Ressourcen aller vorhandenen Cluster in der Region den folgenden inkrementellen Werten hinzu, bevor Sie sie mit Ihrem Projektkontingent vergleichen:

Kontingent Erforderliche Ressourcen pro Bare-Metal-Knoten Erforderliche Ressourcen für einen Cluster mit 3 Knoten
compute.googleapis.com/cpus_per_vm_family für Z3 192 vCPUs 3 × 192 = 576 vCPUs
compute.googleapis.com/local_ssd_total_storage_per_vm_family für Z3 72 TB 3 × 72 TB = 216 TB
compute.googleapis.com/hyperdisk_balanced_total_storage 128 GB 3 × 128 GB = 384 GB
compute.googleapis.com/resource_policies 0, wenn Knoten zu einem vorhandenen Cluster hinzugefügt werden 1 Richtlinie für verteilte Platzierung pro Cluster
compute.googleapis.com/regional_backend_services_protocol_forwarding_fast_ha 0, wenn Knoten oder Cluster ohne neue Appliances hinzugefügt werden 1 pro neuer VCF-Verwaltungs-Appliance-VIP oder NSX Edge-Endpunkt

Eine vollständige Liste der erforderlichen Kontingente und eine Anleitung zum Aufrufen oder Anfordern von Kontingenterhöhungen finden Sie unter Kontingente und Limits.

Umgebungsvariablen festlegen

Legen Sie die folgenden Umgebungsvariablen in Ihrer Jumpbox-Shell fest. Listen Sie die Knoten, die hinzugefügt werden sollen, in der Umgebungsvariablen ADD_HOSTS und die Knoten, die entfernt werden sollen, in der Umgebungsvariablen REMOVE_HOSTS auf (jeweils ein oder mehrere Einträge):

export PROJECT_ID="PROJECT_ID"
export REGION="us-east4"
export ZONE="us-east4-b"
export CUSTOMER_ID="demo"
export VPC_NETWORK="bm-${CUSTOMER_ID}"
export DOMAIN="vmware.gve"
export DNS_ZONE="dns-zone-${CUSTOMER_ID}"
export REV_DNS_ZONE="rev-dns-zone-${CUSTOMER_ID}"
export MGMT_SUBNET="bm-mgmt-${CUSTOMER_ID}"
export VMOTION_SUBNET="bm-vmotion-${CUSTOMER_ID}"
export VSAN_SUBNET="bm-vsan-${CUSTOMER_ID}"
export TEP_SUBNET="bm-nsx-${CUSTOMER_ID}"
export MGMT_NEG="bm-mgmt-${CUSTOMER_ID}"
export TEP_NEG="bm-nsx-tep-${CUSTOMER_ID}"
export CLUSTER_NAME="cl02"
export PLACEMENT_POLICY="bm-${CLUSTER_NAME}"          # Existing placement policy of the cluster
export NETWORK_POOL_NAME="${CLUSTER_NAME}-np01"        # Existing network pool of the cluster
export VDS_NAME="${CLUSTER_NAME}-vds-01"               # Existing VDS of the cluster
export MACHINE_TYPE="z3-highmem-192-highlssd-metal"    # Same machine type as existing nodes
export ESXI_IMAGE_FAMILY="astra-vcf-9-1-x"
export ESXI_IMAGE_PROJECT="smve-prod-offline-depot"
export SDDC_MANAGER="sddcm.vmware.gve"                 # 192.168.0.3
export VCF_USER="admin@local"
export VCF_PASSWORD="VCF_ADMIN_PASSWORD"
export ESXI_PASSWORD_SECRET="esxi-root-password"
export NSX_MANAGER="nsx01.vmware.gve"                  # NSX Manager of the cluster's domain
export MTU=8896

# Nodes to add: name mgmt_ip vmotion_ip vsan_ip tep_ip availability_domain
ADD_HOSTS=(
  "esxi-h10 192.168.0.164 192.168.2.24 192.168.3.24 192.168.4.24 4"
  "esxi-h11 192.168.0.165 192.168.2.25 192.168.3.25 192.168.4.25 5"
)

# Nodes to remove (short hostnames)
REMOVE_HOSTS=(esxi-h11)

# Retrieve an SDDC Manager API token (re-run when the token expires)
TOKEN=$(curl -s -X POST "https://${SDDC_MANAGER}/v1/tokens" \
    -H "Content-Type: application/json" \
    -d "{\"username\":\"${VCF_USER}\",\"password\":\"${VCF_PASSWORD}\"}" | jq -r '.accessToken')

Ersetzen Sie vor dem Ausführen der Befehle Folgendes:

  • PROJECT_ID: die ID Ihres Google Cloud-Zielprojekts.
  • VCF_ADMIN_PASSWORD: Ihr SDDC Manager-Administratorpasswort.

Prüfen Sie, ob eine Ihrer geplanten IP-Adressen bereits von vorhandenen Weiterleitungsregeln oder Instanzen verwendet wird:

gcloud compute forwarding-rules list --project="${PROJECT_ID}" --regions="${REGION}" \
    --format="table(name,IPAddress,subnetwork.basename())"
gcloud compute instances list --project="${PROJECT_ID}" --zones="${ZONE}" \
    --format="table(name,networkInterfaces[].networkIP.list())"

Knoten zu einem Cluster hinzufügen

Führen Sie die Schritte in den folgenden Abschnitten aus, um einen vorhandenen vSphere-Cluster durch Hinzufügen von Bare-Metal-Knoten zu erweitern.

DNS-Einträge erstellen

Da die verwalteten Cloud DNS-Zonen für die Weiterleitung und die umgekehrte Weiterleitung bereits vorhanden sind, erstellen Sie nur für die neuen Knoten Weiterleitungseinträge (A) und Einträge für die umgekehrte Weiterleitung (PTR):

for entry in "${ADD_HOSTS[@]}"; do
  read -r HOST MGMT_IP _ <<< "${entry}"
  gcloud dns record-sets create "${HOST}.${DOMAIN}." \
      --rrdatas="${MGMT_IP}" --type=A --ttl=300 \
      --zone="${DNS_ZONE}" --project="${PROJECT_ID}"
  REV=$(echo "${MGMT_IP}" | awk -F. '{print $4"."$3"."$2"."$1".in-addr.arpa."}')
  gcloud dns record-sets create "${REV}" \
      --rrdatas="${HOST}.${DOMAIN}." --type=PTR --ttl=300 \
      --zone="${REV_DNS_ZONE}" --project="${PROJECT_ID}"
done

# Verify DNS records
gcloud dns record-sets list --zone="${DNS_ZONE}" --project="${PROJECT_ID}" \
    --filter="name~'esxi-h1[01]'"

Bare-Metal-Instanzen erstellen

Erstellen Sie jeden neuen Knoten in der vorhandenen Platzierungsrichtlinie des Clusters mit der primären ESXi-Verwaltungs-NIC (nic0) und mit VLAN-Tags versehenen dynamischen NICs für vMotion (VLAN 2), vSAN (VLAN 3) und NSX TEP (VLAN 4).

for entry in "${ADD_HOSTS[@]}"; do
  read -r HOST MGMT_IP VMOTION_IP VSAN_IP TEP_IP AD <<< "${entry}"
  # Create boot disk
  gcloud compute disks create "${HOST}" \
      --image-project="${ESXI_IMAGE_PROJECT}" \
      --image-family="${ESXI_IMAGE_FAMILY}" \
      --type=hyperdisk-balanced --interface=NVME --size=128GB \
      --guest-os-features=IDPF \
      --zone="${ZONE}" --project="${PROJECT_ID}"

  # Create bare-metal ESXi host
  gcloud compute instances create "${HOST}" \
      --zone="${ZONE}" \
      --machine-type="${MACHINE_TYPE}" \
      --can-ip-forward \
      --resource-policies="${PLACEMENT_POLICY}" \
      --availability-domain="${AD}" \
      --hostname="${HOST}.${DOMAIN}" \
      --disk="name=${HOST},boot=yes,auto-delete=yes" \
      --labels=gcve-node=true \
      --tags=mm-gcve-node \
      --deletion-protection \
      --maintenance-policy=TERMINATE \
      --restart-on-failure \
      --network-performance-configs=total-egress-bandwidth-tier=TIER_1 \
      --project="${PROJECT_ID}" \
      --network-interface="network-tier=PREMIUM,stack-type=IPV4_ONLY,subnet=${MGMT_SUBNET},no-address,private-network-ip=${MGMT_IP}" \
      --network-interface="network-tier=PREMIUM,stack-type=IPV4_ONLY,subnet=${VMOTION_SUBNET},no-address,private-network-ip=${VMOTION_IP},vlan=2" \
      --network-interface="network-tier=PREMIUM,stack-type=IPV4_ONLY,subnet=${VSAN_SUBNET},no-address,private-network-ip=${VSAN_IP},vlan=3" \
      --network-interface="network-tier=PREMIUM,stack-type=IPV4_ONLY,subnet=${TEP_SUBNET},no-address,private-network-ip=${TEP_IP},vlan=4"
done

# Verify instance creation and network interfaces
gcloud compute instances list --project="${PROJECT_ID}" --zones="${ZONE}" \
    --filter="resourcePolicies~${PLACEMENT_POLICY}" \
    --format="table(name,status,networkInterfaces[].vlan.list(),networkInterfaces[].networkIP.list())"

NEG-Mitgliedschaft aktualisieren

Alle Knoten eines Clusters in einer Zone müssen zur selben zonalen NEG des Subnetzes gehören. Fügen Sie die neuen Knoten der Verwaltungs-NEG und der NSX-TEP-NEG hinzu. Sie müssen keine HA-Richtlinien oder Weiterleitungsregeln ändern:

for entry in "${ADD_HOSTS[@]}"; do
  read -r HOST _ <<< "${entry}"
  for NEG in "${MGMT_NEG}" "${TEP_NEG}"; do
    gcloud compute network-endpoint-groups update "${NEG}" \
        --zone="${ZONE}" --add-endpoint="instance=${HOST}" --project="${PROJECT_ID}"
  done
done

# Verify NEG endpoints
for NEG in "${MGMT_NEG}" "${TEP_NEG}"; do
  gcloud compute network-endpoint-groups list-network-endpoints "${NEG}" \
      --zone="${ZONE}" --project="${PROJECT_ID}" \
      --format="table(networkEndpoint.instance,networkEndpoint.ipAddress)"
done

ESXi-Root-Passwort zurücksetzen

Setzen Sie das root-Passwort jedes neuen Knotens zurück, sodass es mit dem in Secret Manager gespeicherten ESXi-root-Passwort übereinstimmt. Sie verwenden dasselbe Secret, um die Knoten in einem späteren Schritt in Betrieb zu nehmen. Wenn Sie Ihre ESXi-root- oder VCF-Passwörter nach der ersten Bereitstellung geändert oder rotiert haben, aktualisieren Sie das entsprechende Secret in Secret Manager, bevor Sie diese Befehle ausführen.

Führen Sie die folgenden Befehle auf der Jumpbox-VM aus, um das root-Passwort auf jedem neuen Knoten zurückzusetzen, und geben Sie das ursprüngliche ESXi-root-Passwort ein, wenn Sie dazu aufgefordert werden:

ESXI_ROOT_PASSWORD=$(gcloud secrets versions access latest \
    --secret="${ESXI_PASSWORD_SECRET}" --project="${PROJECT_ID}")

for entry in "${ADD_HOSTS[@]}"; do
  read -r HOST _ <<< "${entry}"
  ssh -o StrictHostKeyChecking=no "root@${HOST}.${DOMAIN}" \
      "esxcli system account set -i root -p '${ESXI_ROOT_PASSWORD}' -c '${ESXI_ROOT_PASSWORD}'"
done

Fügen Sie die neuen IP-Adressen dem Netzwerkpool und dem TEP-Pool hinzu.

Der Netzwerkpool (cl02-np01) und der NSX-TEP-Pool (cl02-tep-pool) des Clusters enthalten anfangs nur die IP-Adressen der vorhandenen Clusterknoten. Fügen Sie beiden Pools die genauen dynamischen NIC-IP-Adressen der neuen Compute Engine-Knoten hinzu, damit VCF und NSX IP-Adressen aus dem Satz zuweisen, der bereits auf den Compute Engine-NICs konfiguriert ist.

  1. Netzwerkpool (vMotion und vSAN) aktualisieren: Fügen Sie die vMotion- und vSAN-IP-Adressen der neuen Knoten dem Netzwerkpool cl02-np01 hinzu. Verwenden Sie dazu VCF Operations oder die SDDC Manager API:

    VCF-Vorgänge

    Gehen Sie in VCF Operations zu Netzwerkpoolverwaltung, wählen Sie den Netzwerkpool cl02-np01 aus, bearbeiten Sie die vMotion- und vSAN-Netzwerke und fügen Sie die IP-Adressbereiche für die neuen Knoten hinzu.

    SDDC Manager API

    Führen Sie die folgenden Befehle aus, um dem Netzwerkpool einen einzelnen IP-Bereich pro neuem Knoten hinzuzufügen:

    POOL_ID=$(curl -s "https://${SDDC_MANAGER}/v1/network-pools" -H "Authorization: Bearer ${TOKEN}" \
    | jq -r --arg n "${NETWORK_POOL_NAME}" '.elements[] | select(.name==$n) | .id')
NETWORKS=$(curl -s "https://${SDDC_MANAGER}/v1/network-pools/${POOL_ID}/networks" \
    -H "Authorization: Bearer ${TOKEN}")
VMOTION_NET_ID=$(echo "${NETWORKS}" | jq -r '.elements[] | select(.type=="VMOTION") | .id')
VSAN_NET_ID=$(echo "${NETWORKS}" | jq -r '.elements[] | select(.type=="VSAN") | .id')

for entry in "${ADD_HOSTS[@]}"; do
  read -r HOST MGMT_IP VMOTION_IP VSAN_IP _ <<< "${entry}"
  curl -s -X POST "https://${SDDC_MANAGER}/v1/network-pools/${POOL_ID}/networks/${VMOTION_NET_ID}/ip-pools" \
      -H "Authorization: Bearer ${TOKEN}" -H "Content-Type: application/json" \
      -d "{\"start\":\"${VMOTION_IP}\",\"end\":\"${VMOTION_IP}\"}"
  curl -s -X POST "https://${SDDC_MANAGER}/v1/network-pools/${POOL_ID}/networks/${VSAN_NET_ID}/ip-pools" \
      -H "Authorization: Bearer ${TOKEN}" -H "Content-Type: application/json" \
      -d "{\"start\":\"${VSAN_IP}\",\"end\":\"${VSAN_IP}\"}"
done

# Verify the network pool IP ranges
curl -s "https://${SDDC_MANAGER}/v1/network-pools/${POOL_ID}/networks" -H "Authorization: Bearer ${TOKEN}" \
    | jq -r '.elements[] | [.type, (.ipPools | map(.start + "-" + .end) | join(","))] | @tsv'

  2. NSX-TEP-IP-Pool aktualisieren: Gehen Sie im NSX Manager (dem NSX_MANAGER-Host) zu Netzwerk > IP-Adresspools, bearbeiten Sie den cl02-tep-pool-IP-Adresspool und fügen Sie die TEP-IP-Adressen der neuen Knoten den IP-Bereichen des Subnetzes hinzu (192.168.4.24–192.168.4.25 in diesem Beispiel). Behalten Sie dabei das Gateway 192.168.4.1 bei. Prüfen Sie die aktualisierte Poolkonfiguration:

    NSX_PW="NSX_ADMIN_PASSWORD"
curl -s -u "admin:${NSX_PW}" "https://${NSX_MANAGER}/policy/api/v1/infra/ip-pools" \
    | jq -r '.results[] | [.id, .display_name] | @tsv'

TEP_POOL_ID="TEP_POOL_ID"   # ID of cl02-tep-pool from the preceding output
curl -s -u "admin:${NSX_PW}" \
    "https://${NSX_MANAGER}/policy/api/v1/infra/ip-pools/${TEP_POOL_ID}/ip-subnets" \
    | jq '.results[] | {cidr, gateway_ip, allocation_ranges}'

    Ersetzen Sie vor dem Ausführen der Befehle Folgendes:

    • NSX_ADMIN_PASSWORD: Ihr NSX Manager-admin-Passwort (verfügbar über den SDDC Manager-/v1/credentials-Endpunkt oder VCF Operations).
    • TEP_POOL_ID: die ID des cl02-tep-pool-IP-Adresspools.

Knoten in Betrieb nehmen

Nehmen Sie die neuen Knoten mithilfe von VCF Operations oder der SDDC Manager API in das SDDC Manager-Inventar auf:

VCF-Vorgänge

  1. Gehen Sie in VCF Operations zu Inventar > Hosts > Hosts in Betrieb nehmen.
  2. Wählen Sie den Netzwerkpool cl02-np01 und den Speichertyp vSAN ESA aus.
  3. Geben Sie die neuen Host-FQDNs und die root-Anmeldedaten ein.
  4. Akzeptieren Sie die SSL-Fingerabdrücke, validieren Sie die Hosts und klicken Sie auf In Betrieb nehmen.

SDDC Manager API

Führen Sie die folgenden Befehle aus, um die Hosts zu validieren und in Betrieb zu nehmen, und rufen Sie dann den Aufgabenstatus ab, bis Successful zurückgegeben wird:

ADD_FQDNS=$(for entry in "${ADD_HOSTS[@]}"; do
  read -r HOST _ <<< "${entry}"; echo "${HOST}.${DOMAIN}"
done | jq -R . | jq -s .)

HOSTS_JSON=$(jq -n --argjson f "${ADD_FQDNS}" --arg p "${ESXI_ROOT_PASSWORD}" \
    --arg np "${POOL_ID}" --arg npn "${NETWORK_POOL_NAME}" \
    '$f | map({fqdn: ., username: "root", password: $p, storageType: "VSAN_ESA",
               networkPoolId: $np, networkPoolName: $npn})')

# 1. Validate hosts
curl -s -X POST "https://${SDDC_MANAGER}/v1/hosts/validations" \
    -H "Authorization: Bearer ${TOKEN}" -H "Content-Type: application/json" -d "${HOSTS_JSON}"

# 2. Commission hosts and poll until Successful
TASK_ID=$(curl -s -X POST "https://${SDDC_MANAGER}/v1/hosts" \
    -H "Authorization: Bearer ${TOKEN}" -H "Content-Type: application/json" \
    -d "${HOSTS_JSON}" | jq -r '.id')
curl -s "https://${SDDC_MANAGER}/v1/tasks/${TASK_ID}" -H "Authorization: Bearer ${TOKEN}" | jq -r '.status'

Wenn ein Host-SSL-Fingerabdruck einen internen (Nicht-FQDN-)Zertifikatsnamen anzeigt, führen Sie den Befehl esxcli network ip dns search add -d vmware.gve auf dem Host aus, führen Sie das Script /var/lib/vmware/osdata/init.sh noch einmal aus, führen Sie dann den Befehl /sbin/generate-certificates aus und starten Sie die Dienste rhttpproxy und hostd neu.

IP-Ausrichtung vor der Erweiterung prüfen

Lassen Sie alle vSAN-, vMotion- und Netzwerkverbindungsprüfungen im SDDC Manager aktiviert. Diese Validierungsprüfungen sind nur erfolgreich, wenn die IP-Adressen vmk1 und vmk2, die VCF jedem neuen Knoten zuweist, mit den dynamischen NIC-IP-Adressen der Compute Engine übereinstimmen.

  1. Prüfen, ob nicht verwendete Pool-IP-Adressen mit den neuen Compute Engine-NIC-IP-Adressen übereinstimmen: Vergleichen Sie die Netzwerkpoolbereiche mit den IP-Adressen, die vorhandene Hosts bereits verwenden, und den Compute Engine-NICs der neuen Knoten. Die einzigen Pool-IP-Adressen, die von vorhandenen Hosts nicht verwendet werden, sollten die IP-Adressen der neuen Knoten sein:

    # List vMotion and vSAN IP addresses already used by hosts
curl -s "https://${SDDC_MANAGER}/v1/hosts" -H "Authorization: Bearer ${TOKEN}" | jq -r '
  .elements | sort_by(.fqdn)[] | [.fqdn,
    (([.ipAddresses[]? | select(.type=="VMOTION") | .ipAddress] | first) // "-"),
    (([.ipAddresses[]? | select(.type=="VSAN")    | .ipAddress] | first) // "-")] | @tsv'

# List Compute Engine dynamic NIC IPs of the new nodes (VLAN 2 = vMotion, 3 = vSAN, 4 = TEP)
for entry in "${ADD_HOSTS[@]}"; do
  read -r HOST _ <<< "${entry}"
  echo "== ${HOST}"
  gcloud compute instances describe "${HOST}" --zone="${ZONE}" --project="${PROJECT_ID}" \
      --format="table(networkInterfaces[].name,networkInterfaces[].vlan,networkInterfaces[].networkIP)"
done

  2. Bestätigen Sie, dass SDDC Manager keine Validierungen umgeht: Prüfen Sie auf der SDDC Manager-Appliance (als root), ob die Datei application.properties keine validation.disable.*-Attribute enthält:

    # Must return no output. If any validation.disable.* line is present, remove it
# and run: systemctl restart domainmanager
grep -n 'validation.disable' /etc/vmware/vcf/domainmanager/application.properties

Cluster maximieren

Fügen Sie die in Betrieb genommenen Knoten dem Zielcluster mithilfe von VCF Operations oder der SDDC Manager API hinzu:

VCF-Vorgänge

Öffnen Sie in VCF Operations (oder der SDDC Manager-UI) die Domain des Clusters, wählen Sie den Cluster cl02 aus, wählen Sie Aktionen > Host hinzufügen aus, wählen Sie die bereitgestellten Knoten aus, ordnen Sie die Schnittstelle vmnic0 dem Uplink uplink1 des VDS des Clusters zu und senden Sie den Workflow. Rufen Sie Flottenverwaltung > Aufgaben auf, um die Aufgabe zu überwachen und ihre ID zu notieren. Setzen Sie die Variable TASK_ID für den nächsten Abschnitt auf diesen Wert.

SDDC Manager API

Führen Sie die folgenden Befehle aus, um die Erweiterungsspezifikation zu validieren und den Cluster zu erweitern:

CLUSTER_ID=$(curl -s "https://${SDDC_MANAGER}/v1/clusters" -H "Authorization: Bearer ${TOKEN}" \
    | jq -r --arg c "${CLUSTER_NAME}" '.elements[] | select(.name==$c) | .id')

HOST_SPECS=$(curl -s "https://${SDDC_MANAGER}/v1/hosts?status=UNASSIGNED_USEABLE" \
    -H "Authorization: Bearer ${TOKEN}" \
    | jq --argjson f "${ADD_FQDNS}" --arg vds "${VDS_NAME}" '
        [.elements[] | select(.fqdn as $x | $f | index($x))
         | {id, hostNetworkSpec: {vmNics: [{id: "vmnic0", uplink: "uplink1", vdsName: $vds}]}}]')
echo "${HOST_SPECS}" | jq 'length'   # Must equal the number of ADD_HOSTS

EXPANSION_SPEC=$(jq -n --argjson h "${HOST_SPECS}" \
    '{clusterExpansionSpec: {hostSpecs: $h, deployWithoutLicenseKeys: true}}')

# 1. Validate (resolve any reported error before continuing)
curl -s -X POST "https://${SDDC_MANAGER}/v1/clusters/${CLUSTER_ID}/validations" \
    -H "Authorization: Bearer ${TOKEN}" -H "Content-Type: application/json" \
    -d "${EXPANSION_SPEC}" | jq '{executionStatus, resultStatus}'

# 2. Expand the cluster and poll the task
TASK_ID=$(curl -s -X PATCH "https://${SDDC_MANAGER}/v1/clusters/${CLUSTER_ID}" \
    -H "Authorization: Bearer ${TOKEN}" -H "Content-Type: application/json" \
    -d "${EXPANSION_SPEC}" | jq -r '.id')
curl -s "https://${SDDC_MANAGER}/v1/tasks/${TASK_ID}" -H "Authorization: Bearer ${TOKEN}" | jq -r '.status'

Wenn Sie einen Cluster erweitern, weist SDDC Manager vMotion- und vSAN-IP-Adressen aus dem Netzwerkpool zu, ohne die Hostreihenfolge beizubehalten. Wenn SDDC Manager einem neuen Knoten eine IP-Adresse zuweist, die sich von der dynamischen NIC von Compute Engine unterscheidet, wird die Aufgabe beim Überprüfungsschritt für die vSAN- und vMotion-Konnektivität angehalten. Lassen Sie die Aufgabe im Status „Fehlgeschlagen“, führen Sie die Schritte unter Dynamische vMotion- und vSAN-NICs abgleichen aus und versuchen Sie dann, dieselbe Aufgabe noch einmal auszuführen. Starten Sie für diese Knoten keine neue Erweiterungsanfrage: Nach einer fehlgeschlagenen Erweiterung befinden sich die Knoten nicht mehr im Status „Nicht zugewiesen“ und der SDDC Manager lehnt eine neue Erweiterungsanfrage ab.

vMotion- und vSAN-Dynamic NICs abgleichen

Führen Sie die Schritte in diesem Abschnitt aus, wenn die Clustererweiterung beim Überprüfungsschritt für die vSAN- und vMotion-Konnektivität pausiert. Wenn die Aufgabe diesen Schritt besteht, führen Sie nur Schritt 1 aus, um die Ausrichtung zu bestätigen, und fahren Sie dann mit Dynamische NSX-TEP-NICs ausrichten fort.

  1. Lesen Sie die vom VCF zugewiesenen IP-Adressen und vergleichen Sie sie mit den Compute Engine-NICs: Führen Sie die beiden Befehle aus Schritt 1 von IP-Abgleich vor der Vorab-Erweiterung prüfen aus. Nur die neuen Knoten sind im Umfang enthalten.

  2. Löschen Sie zuerst alle nicht übereinstimmenden Dynamic NICs und fügen Sie sie dann wieder hinzu: Löschen Sie alle nicht übereinstimmenden Dynamic NICs (die nic0.2-Schnittstelle für vMotion und die nic0.3-Schnittstelle für vSAN) auf jedem neuen Knoten, bevor Sie eine Schnittstelle wieder hinzufügen. Andernfalls schlagen vertauschte IP-Adressen mit einem IP_IN_USE-Fehler fehl:

    # Example: VCF swapped the IP addresses of esxi-h10 and esxi-h11
HOST="esxi-h10"
VCF_VMOTION_IP="192.168.2.25"
VCF_VSAN_IP="192.168.3.25"

# 2a. Delete mismatched NICs (run on all mismatched nodes before running 2b)
gcloud compute instances network-interfaces delete "${HOST}" \
    --network-interface=nic0.2 --zone="${ZONE}" --project="${PROJECT_ID}" --quiet
gcloud compute instances network-interfaces delete "${HOST}" \
    --network-interface=nic0.3 --zone="${ZONE}" --project="${PROJECT_ID}" --quiet

# 2b. Add the dynamic NICs back with the VCF-allocated IP addresses
gcloud compute instances network-interfaces add "${HOST}" \
    --parent-nic-name=nic0 --vlan=2 \
    --network="${VPC_NETWORK}" --subnetwork="${VMOTION_SUBNET}" \
    --private-network-ip="${VCF_VMOTION_IP}" --no-address \
    --zone="${ZONE}" --project="${PROJECT_ID}"
gcloud compute instances network-interfaces add "${HOST}" \
    --parent-nic-name=nic0 --vlan=3 \
    --network="${VPC_NETWORK}" --subnetwork="${VSAN_SUBNET}" \
    --private-network-ip="${VCF_VSAN_IP}" --no-address \
    --zone="${ZONE}" --project="${PROJECT_ID}"

  3. Fehlgeschlagene Aufgabe wiederholen: Rufen Sie in VCF Operations die Option Flottenverwaltung auf.

    Aufgaben, um die Erweiterungsaufgabe noch einmal zu versuchen, oder führen Sie den folgenden SDDC Manager-API-Befehl aus:

    curl -s -X PATCH "https://${SDDC_MANAGER}/v1/tasks/${TASK_ID}" \
    -H "Authorization: Bearer ${TOKEN}" -H "Content-Type: application/json" \
    -d '{"status": "RETRY"}'

    Wenn die Aufgabe wieder fehlschlägt, wiederholen Sie die Schritte 1 und 2, bevor Sie es noch einmal versuchen.

Dynamische NSX-TEP-NICs anpassen

Nachdem NSX die neuen Knoten als Transportknoten konfiguriert hat, prüfen Sie die dynamischen NICs für VLAN 4 NSX TEP (vmk10) auf den neuen Knoten und richten Sie sie aus.

  1. Rufen Sie die von NSX zugewiesenen TEP-IP-Adressen ab: Fragen Sie NSX Manager ab oder führen Sie den Befehl esxcli network ip interface ipv4 get -i vmk10 auf jedem ESXi-Host aus:

    # Map transport node ID to hostname
curl -s -u "admin:${NSX_PW}" "https://${NSX_MANAGER}/api/v1/transport-nodes" \
    | jq -r '.results[] | [.id, .display_name] | @tsv'

# Map transport node ID to TEP device and IP address
curl -s -u "admin:${NSX_PW}" "https://${NSX_MANAGER}/api/v1/transport-nodes/state" \
    | jq -r '.results[] | [.transport_node_id, .state,
        ([.host_switch_states[]?.endpoints[]? | .device_name + "=" + .ip] | join(","))] | @tsv'

  2. Nicht übereinstimmende TEP-NICs neu erstellen: Vergleichen Sie die von NSX zugewiesenen vmk10-IP-Adressen mit der Compute Engine-TEP-NIC (VLAN 4) jedes neuen Knotens. Nur die neuen Knoten sind im Umfang enthalten. Ändern Sie nicht die TEP-NICs vorhandener Knoten. Trennen Sie bei allen nicht übereinstimmenden neuen Knoten zuerst jeden Knoten von der TEP-NEG und löschen Sie die nic0.4-Schnittstelle auf allen nicht übereinstimmenden Knoten. Anschließend fügen Sie die nic0.4-Schnittstelle wieder hinzu und hängen die Knoten wieder an die TEP-NEG an:

    # Example: Compute Engine has 192.168.4.24 on esxi-h10, but NSX assigned 192.168.4.25
HOST="esxi-h10"
CURRENT_TEP_IP="192.168.4.24"
NSX_TEP_IP="192.168.4.25"

# 2a. Detach the node from the TEP NEG
gcloud compute network-endpoint-groups update "${TEP_NEG}" \
    --zone="${ZONE}" --project="${PROJECT_ID}" \
    --remove-endpoint="instance=${HOST},ip=${CURRENT_TEP_IP}"

# 2b. Delete the mismatched TEP NIC on all mismatched nodes first
gcloud compute instances network-interfaces delete "${HOST}" \
    --network-interface=nic0.4 --zone="${ZONE}" --project="${PROJECT_ID}" --quiet

# 2c. Re-add nic0.4 with the NSX-allocated IP address
gcloud compute instances network-interfaces add "${HOST}" \
    --parent-nic-name=nic0 --vlan=4 \
    --network="${VPC_NETWORK}" --subnetwork="${TEP_SUBNET}" \
    --private-network-ip="${NSX_TEP_IP}" --no-address \
    --zone="${ZONE}" --project="${PROJECT_ID}"

# 2d. Re-attach the node to the TEP NEG
gcloud compute network-endpoint-groups update "${TEP_NEG}" \
    --zone="${ZONE}" --project="${PROJECT_ID}" \
    --add-endpoint="instance=${HOST}"

Clustererweiterung prüfen

Prüfen Sie nach erfolgreichem Abschluss der Clustererweiterung Folgendes:

  • vCenter Server: Die neuen Knoten sind verbunden und fehlerfrei im cl02-Cluster, ohne Netzwerkalarme.
  • vSAN: Rufen Sie für den Cluster cl02 die Option Überwachen > vSAN > Skyline Health auf und prüfen Sie, ob alle Systemdiagnosen erfolgreich sind und die Datenspeicherkapazität die neuen Knoten enthält.
  • NSX Manager: Gehen Sie zu System > Fabric > Hosts und prüfen Sie, ob für jeden neuen Knoten Erfolgreich und Aktiv angezeigt wird und ob Overlay-Tunnel aktiv sind.
  • VCF-Vorgänge: Die neuen Knoten werden dem Cluster cl02 zugewiesen und die Aufgabenliste enthält keine fehlgeschlagenen Aufgaben.

Prüfen Sie in einer ESXi-Host-Shell (z. B. esxi-h10) die Jumbo-Frame-Konnektivität (8896 MTU minus 28-Byte-IP/ICMP-Header = 8868 Byte):

esxcli network ip interface ipv4 get                        # Verify vmk0, vmk1, vmk2, and vmk10 IPs
vmkping -S vmotion -I vmk1 -d -s 8868 192.168.2.21          # vMotion (netstack might be default)
vmkping -I vmk2 -d -s 8868 192.168.3.21                     # vSAN
vmkping ++netstack=vxlan -I vmk10 -d -s 8868 192.168.4.21   # NSX TEP

vSAN-Fehlertoleranz und Hostanzahl

Anhand der folgenden Tabelle können Sie feststellen, wie viele Knoten Ihr Cluster benötigt, wenn Sie Knoten hinzufügen, oder wie viele Knoten beibehalten werden müssen, wenn Sie Knoten entfernen:

Fehler, die toleriert werden können Datenplatzierungsschema Mindestanzahl von Hosts
FTT=1 RAID-1 (Spiegelung) oder RAID-5 (Erasure Coding) 3 (4 oder mehr empfohlen, um nach einem Hostausfall oder während der Wartung neu zu erstellen)
FTT=2 RAID-1 (Spiegelung) 5
FTT=2 RAID-6 (Erasure Coding) 6

Knoten aus einem Cluster entfernen

Prüfungen vor dem Entfernen durchführen

Prüfen Sie Folgendes, bevor Sie Knoten aus einem Cluster entfernen:

  • Hostanzahl: Nach dem Entfernen des Knotens enthält der Cluster mindestens drei Knoten und mindestens die Hostanzahl, die in vSAN-Fehler, die toleriert werden können, und Hostanzahl aufgeführt ist, die für Ihre aktiven Speicherrichtlinien erforderlich ist.
  • Kapazität: Gehen Sie in vCenter Server für den Cluster cl02 zu Überwachen > vSAN > Vorabprüfung der Datenmigration für jeden Knoten, den Sie entfernen möchten (mit der Option Vollständige Datenmigration), und prüfen Sie, ob die verbleibenden Knoten über ausreichend vSAN- und Rechenkapazität verfügen.
  • Zustand: vSAN Skyline Health wird ohne Fehler ausgeführt und es gibt keine fehlgeschlagenen Aufgaben in VCF Operations oder SDDC Manager.

  • HA-Richtlinien-Leader: Prüfen Sie, ob kein Backend-Dienst einen Knoten verwendet, den Sie als HA-Richtlinien-Leader entfernen. Wenn ein Backend-Dienst einen dieser Knoten als Leader verwendet, aktualisieren Sie den Leader auf einen verbleibenden Knoten (den Host, auf dem die Appliance-VM nach der Migration ausgeführt wird):

    gcloud compute backend-services list --regions="${REGION}" --project="${PROJECT_ID}" \
    --format="table(name,haPolicy.leader.networkEndpoint.instance)"

# Run only if a node being removed is an HA policy leader (example: move rbs-vc02-demo to esxi-h0)
NEG_LINK=$(gcloud compute network-endpoint-groups describe "${MGMT_NEG}" \
    --zone="${ZONE}" --project="${PROJECT_ID}" --format="value(selfLink)")
gcloud compute backend-services update "rbs-vc02-${CUSTOMER_ID}" \
    --ha-policy-leader-backend-group="${NEG_LINK}" --ha-policy-leader-instance=esxi-h0 \
    --region="${REGION}" --project="${PROJECT_ID}"

Knoten aus dem Cluster entfernen

Entfernen Sie die Zielknoten aus dem Cluster in VCF. VCF versetzt jeden Knoten in den Wartungsmodus, migriert seine VMs und entfernt seine vSAN-Daten. Sie können die Knoten mit VCF Operations oder der SDDC Manager API entfernen:

VCF-Vorgänge

Öffnen Sie in VCF Operations (oder der SDDC Manager-UI) die Domain des Clusters, wählen Sie den Cluster cl02 aus, wählen Sie Aktionen > Host entfernen aus, wählen Sie die zu entfernenden Knoten aus und bestätigen Sie.

SDDC Manager API

Führen Sie die folgenden Befehle aus, um die Komprimierungsspezifikation zu validieren und die Hosts aus dem Cluster zu entfernen:

CLUSTER_ID=$(curl -s "https://${SDDC_MANAGER}/v1/clusters" -H "Authorization: Bearer ${TOKEN}" \
    | jq -r --arg c "${CLUSTER_NAME}" '.elements[] | select(.name==$c) | .id')

REMOVE_FQDNS=$(for HOST in "${REMOVE_HOSTS[@]}"; do echo "${HOST}.${DOMAIN}"; done | jq -R . | jq -s .)

COMPACTION_SPEC=$(curl -s "https://${SDDC_MANAGER}/v1/hosts" -H "Authorization: Bearer ${TOKEN}" \
    | jq --argjson f "${REMOVE_FQDNS}" '
        {clusterCompactionSpec: {hosts: [.elements[] | select(.fqdn as $x | $f | index($x)) | {id}]}}')
echo "${COMPACTION_SPEC}" | jq '.clusterCompactionSpec.hosts | length'   # Must equal the number of REMOVE_HOSTS

# 1. Validate the compaction specification
curl -s -X POST "https://${SDDC_MANAGER}/v1/clusters/${CLUSTER_ID}/validations" \
    -H "Authorization: Bearer ${TOKEN}" -H "Content-Type: application/json" \
    -d "${COMPACTION_SPEC}" | jq '{executionStatus, resultStatus}'

# 2. Remove the hosts and poll the task until Successful
TASK_ID=$(curl -s -X PATCH "https://${SDDC_MANAGER}/v1/clusters/${CLUSTER_ID}" \
    -H "Authorization: Bearer ${TOKEN}" -H "Content-Type: application/json" \
    -d "${COMPACTION_SPEC}" | jq -r '.id')
curl -s "https://${SDDC_MANAGER}/v1/tasks/${TASK_ID}" -H "Authorization: Bearer ${TOKEN}" | jq -r '.status'

Knoten außer Betrieb nehmen

Nachdem Sie die Knoten aus dem Cluster entfernt haben, nehmen Sie sie mithilfe von VCF Operations oder der SDDC Manager API aus dem SDDC Manager-Inventar:

VCF-Vorgänge

Gehen Sie in VCF Operations zu Inventar > Hosts, wählen Sie die nicht zugewiesenen Knoten aus und klicken Sie auf Außer Betrieb nehmen. Weitere Informationen finden Sie in der VMware Cloud Foundation-Dokumentation unter Hosts außer Betrieb nehmen.

SDDC Manager API

Führen Sie die folgenden Befehle aus, um eine Anfrage zur Außerbetriebnahme zu senden und die Aufgabe abzufragen, bis Successful zurückgegeben wird:

DECOMMISSION_SPEC=$(echo "${REMOVE_FQDNS}" | jq 'map({fqdn: .})')
TASK_ID=$(curl -s -X DELETE "https://${SDDC_MANAGER}/v1/hosts?skipFailedHosts=false" \
    -H "Authorization: Bearer ${TOKEN}" -H "Content-Type: application/json" \
    -d "${DECOMMISSION_SPEC}" | jq -r '.id')
curl -s "https://${SDDC_MANAGER}/v1/tasks/${TASK_ID}" -H "Authorization: Bearer ${TOKEN}" | jq -r '.status'

# Verify that the nodes are no longer listed in the inventory
curl -s "https://${SDDC_MANAGER}/v1/hosts" -H "Authorization: Bearer ${TOKEN}" \
    | jq -r '.elements[] | [.fqdn, .status] | @tsv'

Knoten aus den NEGs entfernen

Entfernen Sie die außer Betrieb genommenen Knoten aus der Verwaltungs-NEG und der NSX-TEP-NEG:

for HOST in "${REMOVE_HOSTS[@]}"; do
  for NEG in "${MGMT_NEG}" "${TEP_NEG}"; do
    gcloud compute network-endpoint-groups update "${NEG}" \
        --zone="${ZONE}" --remove-endpoint="instance=${HOST}" --project="${PROJECT_ID}"
  done
done

# Verify NEG endpoints
for NEG in "${MGMT_NEG}" "${TEP_NEG}"; do
  gcloud compute network-endpoint-groups list-network-endpoints "${NEG}" \
      --zone="${ZONE}" --project="${PROJECT_ID}" \
      --format="table(networkEndpoint.instance,networkEndpoint.ipAddress)"
done

Wenn die gcloud-CLI das Entfernen aus der TEP-NEG ohne explizite IP-Adresse ablehnt, fügen Sie die Endpunkt-IP-Adresse (wie im Bestätigungsbefehl angezeigt) im Flag --remove-endpoint ein: --remove-endpoint="instance=HOST,ip=TEP_IP".

Bare-Metal-Instanzen löschen

Deaktivieren Sie den Löschschutz auf jedem außer Betrieb genommenen Host und löschen Sie die Compute Engine-Bare-Metal-Instanz. Compute Engine löscht das Bootlaufwerk automatisch mit der Instanz:

for HOST in "${REMOVE_HOSTS[@]}"; do
  # Clear deletion protection, and then delete the instance and its boot disk
  gcloud compute instances update "${HOST}" --no-deletion-protection \
      --zone="${ZONE}" --project="${PROJECT_ID}"
  gcloud compute instances delete "${HOST}" \
      --zone="${ZONE}" --project="${PROJECT_ID}" --quiet
done

# Verify remaining instances in the placement policy
gcloud compute instances list --project="${PROJECT_ID}" --zones="${ZONE}" \
    --filter="resourcePolicies~${PLACEMENT_POLICY}" --format="table(name,status)"

DNS-Einträge und IP-Pools bereinigen

Löschen Sie die Forward- (A) und Reverse- (PTR) Cloud DNS-Einträge der entfernten Knoten:

for HOST in "${REMOVE_HOSTS[@]}"; do
  MGMT_IP=$(gcloud dns record-sets describe "${HOST}.${DOMAIN}." --type=A \
      --zone="${DNS_ZONE}" --project="${PROJECT_ID}" --format="value(rrdatas[0])")
  REV=$(echo "${MGMT_IP}" | awk -F. '{print $4"."$3"."$2"."$1".in-addr.arpa."}')
  gcloud dns record-sets delete "${REV}" --type=PTR --zone="${REV_DNS_ZONE}" --project="${PROJECT_ID}"
  gcloud dns record-sets delete "${HOST}.${DOMAIN}." --type=A --zone="${DNS_ZONE}" --project="${PROJECT_ID}"
done

Die vMotion-, vSAN- und TEP-IP-Adressen der entfernten Knoten werden im Netzwerkpool und im NSX-TEP-Pool wieder freigegeben. Sie können diese IP-Adressen entweder für einen zukünftigen Knoten beibehalten (indem Sie diesem zukünftigen Knoten dieselben Compute Engine-NIC-IP-Adressen zuweisen) oder sie aus den Pools entfernen, damit VCF und NSX sie nicht einem zukünftigen Knoten zuweisen, dessen Compute Engine-NICs andere IP-Adressen verwenden.

Entfernen des Knotens prüfen

Prüfen Sie nach Abschluss des Workflows zum Entfernen von Knoten Folgendes:

  • vCenter Server: Im cl02-Cluster werden nur die verbleibenden Knoten angezeigt, die alle verbunden und fehlerfrei sind. vSphere HA und DRS melden keine Fehler.
  • vSAN: Skyline Health-Prüfungen sind erfolgreich und alle virtuellen Objekte sind konform (für den Cluster cl02 rufen Sie Monitoring > vSAN > Virtuelle Objekte auf).
  • NSX Manager: Die entfernten Knoten werden nicht mehr als Transportknoten aufgeführt und die verbleibenden Knoten werden als Aktiv angezeigt.
  • VCF Operations und SDDC Manager: Die entfernten Knoten sind nicht mehr im Hostinventar enthalten und es gibt keine fehlgeschlagenen Aufgaben.
  • Google Cloud: Die Bare-Metal-Instanzen, Bootlaufwerke, NEG-Endpunkte und DNS-Einträge der entfernten Knoten werden gelöscht.

Fehlerbehebung bei der Clustererweiterung und beim Entfernen von Knoten

In der folgenden Tabelle sind häufige Probleme, Ursachen und Lösungen beim Hinzufügen oder Entfernen von Knoten in einem vSphere-Cluster aufgeführt:

Problem Ursache Lösung
Die Clustererweiterung schlägt bei der Verbindungsprüfung für vSAN und vMotion fehl. Neue Knoten werden als fehlerhaft gemeldet. Wenn Sie einen Cluster erweitern, weist SDDC Manager vmk1- und vmk2-IP-Adressen aus dem Netzwerkpool zu, ohne die Hostreihenfolge beizubehalten. Lassen Sie die Validierungen aktiviert. Fügen Sie dem Netzwerkpool nur die IP-Adressen der neuen Knoten hinzu. Wenn die Aufgabe bei der Verbindungsprüfung pausiert, richten Sie die dynamischen NICs aus und versuchen Sie es noch einmal.
NSX-Hoststatus ist Degraded oder Tunnel sind auf den neuen Knoten nicht erreichbar NSX Manager weist TEP-IP-Adressen (vmk10) nach dem Zufallsprinzip aus dem IP-Pool zu. Daher stimmen sie möglicherweise nicht mit der Compute Engine-TEP-NIC überein. Richten Sie die dynamischen NSX-TEP-NICs wie unter Dynamische NSX-TEP-NICs ausrichten beschrieben aus.
NSX kann die neuen Knoten nicht vorbereiten Der NSX-TEP-IP-Pool des Clusters hat keine verfügbaren IP-Adressen. Fügen Sie die TEP-IP-Adressen der neuen Knoten dem TEP-IP-Pool hinzu und wiederholen Sie dann die Aufgabe.
SDDC Manager lehnt eine neue Erweiterungsanfrage für dieselben Knoten ab. Wenn eine Erweiterungsaufgabe fehlschlägt, befinden sich die Knoten nicht im Status UNASSIGNED_USEABLE. Wiederholen Sie die fehlgeschlagene Aufgabe (PATCH /v1/tasks/TASK_ID mit {"status": "RETRY"}), anstatt eine neue Erweiterungsanfrage zu senden.
Die Inbetriebnahme eines Knotens schlägt fehl, weil der Knoten bereits in Betrieb genommen wurde. Sie können einen Host nicht zweimal in Betrieb nehmen. Fahren Sie mit der Clustererweiterung fort oder nehmen Sie den Knoten zuerst außer Betrieb, wenn Sie ihn wieder in Betrieb nehmen müssen (z. B. mit einem anderen Netzwerkpool).
IP_IN_USE-Fehler beim erneuten Hinzufügen einer dynamischen NIC Zwei Knoten haben die IP-Adressen getauscht oder eine geplante IP-Adresse überschneidet sich mit einem anderen Knoten. Löschen Sie zuerst alle nicht übereinstimmenden dynamischen NICs auf allen neuen Knoten, bevor Sie eine Schnittstelle wieder hinzufügen, und prüfen Sie Ihren IP-Adressplan.
Validierung des Entfernens von Knoten schlägt fehl Durch das Entfernen der Knoten wird der Cluster auf weniger Hosts als seine Mindestgröße reduziert oder die verbleibenden Knoten haben nicht genügend Kapazität. Entfernen Sie weniger Knoten oder fügen Sie zuerst Kapazität hinzu. Verwenden Sie nicht das Attribut "force": true.
gcloud-CLI weigert sich, die Bare-Metal-Instanz zu löschen Der Löschschutz ist für die Instanz aktiviert. Führen Sie den Befehl gcloud compute instances update HOST --no-deletion-protection aus, bevor Sie die Instanz löschen.
Falsche vSAN-Fehlerdomains nach dem Hinzufügen von Knoten Sie haben neue Knoten in einer anderen Platzierungsrichtlinie erstellt oder zwei Cluster verwenden dieselbe Platzierungsrichtlinie. Erstellen Sie neue Knoten in der eigenen Platzierungsrichtlinie des Clusters und verteilen Sie sie auf Verfügbarkeitsdomains.
vSAN-Fehler, vMotion-Zeitüberschreitungen oder NSX-Overlay-Fragmentierung Die konfigurierte MTU ist größer als die MTU des VPC-Netzwerk (8896 Byte). Neue Knoten übernehmen den VDS und die Pools des Clusters. Behalten Sie die MTU-Einstellung von 8896 Byte für alle Komponenten bei.
Host-SSL-Fingerabdruck oder -Zertifikat zeigt einen internen Namen an Die DNS-Suchdomain ist auf dem Host nicht festgelegt. Führen Sie den Befehl esxcli network ip dns search add -d vmware.gve aus, führen Sie das Script /var/lib/vmware/osdata/init.sh noch einmal aus, führen Sie dann den Befehl /sbin/generate-certificates aus und starten Sie die Dienste rhttpproxy und hostd neu.
Hosts können das Subnetz-Gateway (.1) nicht pingen. Google Cloud reagiert nicht auf ICMP-Echoanfragen an Subnetz-Gateway-IP-Adressen. Erwartetes Verhalten; Gateway-Ping-Warnungen ignorieren.

Nächste Schritte