Google utilizza la tecnologia AI per tradurre i contenuti nella tua lingua preferita. Le traduzioni generate dall'AI potrebbero contenere errori.

Aggiungi o rimuovi nodi in un cluster vSphere

Questo documento descrive come aggiungere uno o più nodi bare metal di Compute Engine a un cluster vSphere esistente (espansione del cluster) e rimuovere uno o più nodi da un cluster (compattazione del cluster) in VMware Cloud Foundation (VCF) 9.1 nella soluzione VMware su Google Cloud. Espandi o comprimi un cluster quando devi aumentare o ridurre la capacità di calcolo e di archiviazione vSAN di un cluster esistente nel dominio di gestione o in un dominio workload VI. La stessa procedura si applica sia che tu aggiunga o rimuova un singolo nodo o più nodi: elenca uno o più nodi nella variabile di ambiente ADD_HOSTS o REMOVE_HOSTS.

Riepilogo dell'architettura

Quando aggiungi o rimuovi nodi in un cluster vSphere esistente, il workflow utilizza la seguente architettura:

Aggiunta di nodi: ogni nuovo nodo è un'istanza bare metal z3-highmem-192-highlssd-metal di cui esegui il deployment nella stessa zona, nella stessa policy di posizionamento e con lo stesso tipo di macchina dei nodi esistenti del cluster. Ogni nodo ha un'interfaccia di rete principale (nic0) nella subnet di gestione ESXi della tua rete Virtual Private Cloud (VPC) e interfacce di rete dinamiche con tag VLAN per vMotion, vSAN e NSX Tunnel Endpoint (TEP). Il nodo si unisce ai gruppi di endpoint di rete (NEG) a livello di zona esistenti. Poi, esegui il provisioning del nodo in SDDC Manager con il pool di rete del cluster e lo aggiungi al cluster.
Rimozione dei nodi: per prima cosa, rimuovi il nodo dal cluster in VCF, che esegue la migrazione delle VM del workload e svuota i dati vSAN dell'host. Poi, esegui il decommissionamento dell'host da SDDC Manager e lo rimuovi dai NEG di zona prima di eliminare l'istanza bare metal di Compute Engine sottostante.
Allineamento degli indirizzi IP: come per la creazione del cluster, VCF alloca gli indirizzi IP vMotion e vSAN dal pool di rete del cluster, mentre NSX alloca gli indirizzi IP TEP (vmk10) dal pool di indirizzi IP NSX. Allinea le NIC dinamiche di Compute Engine dei nuovi nodi agli indirizzi IP allocati da VCF, mantenendo attive tutte le convalide VCF.
Nessuna modifica alle appliance: l'aggiunta o la rimozione di nodi del cluster non richiede nuovi record Cloud DNS, servizi di backend, policy di alta affidabilità (HA) o regole di forwarding per le appliance di gestione.

Prima di iniziare

Prima di aggiungere o rimuovere nodi, verifica i requisiti nelle sezioni seguenti e configura le variabili di ambiente.

Verifica i requisiti dell'ambiente

Verifica che il tuo ambiente soddisfi i seguenti requisiti:

Autorizzazioni: disponi dei ruoli Identity and Access Management (IAM) richiesti nel progetto di destinazione, tra cui Amministratore Compute (roles/compute.admin), Amministratore DNS (roles/dns.admin) e Secret Manager Secret Accessor (roles/secretmanager.secretAccessor).
Credenziali in Secret Manager: se hai modificato o ruotato le password di ESXi root, SDDC Manager, vCenter Server o NSX Manager in VCF dopo il deployment iniziale, Secret Manager non viene aggiornato automaticamente. Prima di eseguire i comandi in questo documento, aggiorna i secret corrispondenti in Secret Manager o fornisci direttamente le password aggiornate in modo che corrispondano alle tue credenziali VCF attive.
Integrità del cluster e del dominio: il cluster di destinazione e il relativo dominio sono integri (vCenter Server, vSAN, NSX Manager, SDDC Manager e VCF Operations) e non presentano attività non riuscite.
Per aggiungere nodi:
- Il tuo progetto dispone di una quota bare metal z3 sufficiente nella regione e nella zona di destinazione.
- I nuovi nodi utilizzano lo stesso tipo di macchina dei nodi esistenti nel cluster (z3-highmem-192-highlssd-metal per vSAN Express Storage Architecture (ESA)) e vengono assegnati alla policy di posizionamento esistente del cluster (ogni policy di posizionamento appartiene a un solo cluster).
- Ogni nuovo nodo dispone di dispositivi SSD locali NVMe senza partizioni preesistenti.
- Se la tua organizzazione applica la policy dell'organizzazione constraints/compute.trustedImageProjects o utilizza un perimetro di servizio dei Controlli di servizio VPC, assicurati che il tuo progetto consenta l'accesso alle immagini al progetto smve-prod-public-images (projects/999037279871). Per ulteriori informazioni, consulta Gestisci la capacità dei nodi.
- Networking basato su VLAN: la soluzione VMware richiede che le subnet della tua rete VPC abbiano la proprietà Risolvi subnet mask impostata su Trasmetti solo l'intervallo principale con apprendimento per supportare il networking basato su VLAN. Apri un ticket di assistenza nel Centro assistenza della consoleGoogle Cloud con le seguenti informazioni:
  - Prodotto: Google Cloud VMware Engine
  - Priorità: P2
  - Categoria: connettività di rete
  - Impatto aziendale: domanda tecnica generale
  - Fornisci maggiori dettagli: Allowlist L2 network connectivity for my project, insieme all'ID progetto, al numero di progetto e alla regione e alla zona di destinazione del deployment
  Per ulteriori informazioni sul supporto del networking basato su VLAN, consulta Emulazione di livello 2: trasmissione ARP e apprendimento MAC personalizzato.
Per rimuovere i nodi:
- I nodi rimanenti hanno una capacità di computing e di archiviazione vSAN sufficiente per i tuoi workload attivi.
- Dopo la rimozione dei nodi, il cluster conserva almeno tre nodi (il minimo per vSAN con un errore da tollerare (FTT=1)) o il numero minimo di host richiesto dalle policy di archiviazione attive (vedi Errori da tollerare e numero di host vSAN).
VM jumpbox: hai accesso a una VM jumpbox con l'interfaccia a riga di comando gcloud, curl e jq installate e con connettività di rete alla rete VPC (ad esempio, nella subnet bm-gcp-demo).

Esamina i parametri dell'ambiente di esempio

I comandi in questo documento utilizzano i seguenti parametri di esempio:

Parametro di input	Valore di esempio	Descrizione
ID progetto, regione e zona	`PROJECT_ID` / `us-east4` / `us-east4-b`	Stesso progetto, stessa regione e stessa zona del cluster di destinazione
ID cliente	`demo`	Identificatore utilizzato nei nomi delle risorse esistenti
Cluster di destinazione	`cl02` (`esxi-h7`, `esxi-h8`, `esxi-h9`)	Cluster esistente nel dominio di gestione o in un dominio del workload VI
Policy di posizionamento	`bm-cl02`	Policy di posizionamento del gruppo esistente del cluster
Pool di rete e VDS	`cl02-np01`/`cl02-vds-01`	Pool di rete esistente e vSphere Distributed Switch (VDS) del cluster
Pool di IP NSX TEP	`cl02-tep-pool`	Pool di indirizzi IP NSX esistente del cluster
NSX Manager	`nsx01.vmware.gve`	NSX Manager del dominio del cluster (o `nsx05.vmware.gve` per il dominio del workload `wld01` con un'istanza NSX dedicata)
Tipo di macchina	`z3-highmem-192-highlssd-metal`	Stesso tipo di macchina dei nodi esistenti nel cluster
Rete VPC e subnet (ID VLAN)	`bm-demo`; `bm-mgmt-demo` (senza tag), `bm-vmotion-demo` (`2`), `bm-vsan-demo` (`3`), `bm-nsx-demo` (`4`)	Rete VPC e subnet di livello 2 esistenti
NEG a livello di zona	`bm-mgmt-demo`, `bm-nsx-tep-demo`	NEG di gestione e NSX TEP esistenti
SDDC Manager	`sddcm.vmware.gve` (`192.168.0.3`)	Appliance SDDC Manager esistente
Password root ESXi `root`	`esxi-root-password`	Secret di Secret Manager esistente che contiene la password ESXi `root`

Pianifica gli indirizzi IP e i nomi host

L'esempio seguente aggiunge due nodi (esxi-h10 e esxi-h11) al cluster cl02, quindi ne rimuove uno (esxi-h11). Per aggiungere o rimuovere un singolo nodo, includi solo quel nodo nell'array di variabile di ambiente:

Host ESXi	IP di gestione (`nic0`)	vMotion (VLAN 2)	vSAN (VLAN 3)	NSX TEP (VLAN 4)	Dominio di affidabilità	Azione
`esxi-h10`	`192.168.0.164`	`192.168.2.24`	`192.168.3.24`	`192.168.4.24`	`4`	Aggiungi
`esxi-h11`	`192.168.0.165`	`192.168.2.25`	`192.168.3.25`	`192.168.4.25`	`5`	Aggiungi, poi rimuovi

Distribuisci i nodi del cluster tra i domini di disponibilità all'interno della policy di posizionamento del cluster: poiché i nodi esistenti (da esxi-h7 a esxi-h9) utilizzano i domini di disponibilità da 1 a 3, i nuovi nodi utilizzano i domini di disponibilità 4 e 5.

Verifica la quota a livello di regione

Prima di eseguire il provisioning dei nodi bare metal o di creare un cluster, verifica che il tuo progetto disponga di una quota Compute Engine regionale e globale sufficiente. Aggiungi le risorse di tutti i cluster esistenti nella regione ai seguenti valori incrementali prima di confrontarli con la quota del progetto:

Metrica di quota	Risorse richieste per nodo bare metal	Risorse richieste per un cluster a 3 nodi
`compute.googleapis.com/cpus_per_vm_family` per `Z3`	192 vCPU	3 x 192 = 576 vCPU
`compute.googleapis.com/local_ssd_total_storage_per_vm_family` per `Z3`	72 TB	3 x 72 TB = 216 TB
`compute.googleapis.com/hyperdisk_balanced_total_storage`	128 GB	3 × 128 GB = 384 GB
`compute.googleapis.com/resource_policies`	0 quando aggiungi nodi a un cluster esistente	1 policy di posizionamento distribuito per cluster
`compute.googleapis.com/regional_backend_services_protocol_forwarding_fast_ha`	0 quando aggiungi nodi o cluster senza nuove appliance	1 per ogni nuovo VIP dell'appliance di gestione VCF o endpoint NSX Edge

Per l'elenco completo delle quote richieste e le istruzioni su come visualizzare o richiedere aumenti delle quote, consulta Quote e limiti.

Imposta le variabili di ambiente

Imposta le seguenti variabili di ambiente nella shell del jumpbox. Elenca i nodi da aggiungere nella variabile di ambiente ADD_HOSTS e i nodi da rimuovere nella variabile di ambiente REMOVE_HOSTS (una o più voci ciascuna):

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')

Prima di eseguire i comandi, sostituisci quanto segue:

PROJECT_ID: l'ID del progetto Google Cloud di destinazione.
VCF_ADMIN_PASSWORD: la password dell'amministratore di SDDC Manager.

Verifica che nessuno degli indirizzi IP pianificati sia già utilizzato da regole di forwarding o istanze esistenti:

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())"

Aggiungi nodi a un cluster

Per espandere un cluster vSphere esistente aggiungendo nodi bare metal, completa i passaggi descritti nelle sezioni seguenti.

Crea record DNS

Poiché le zone Cloud DNS gestite di inoltro e inversione esistono già, crea record di inoltro (A) e inversione (PTR) solo per i nuovi nodi:

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]'"

Crea istanze bare metal

Crea ogni nuovo nodo nella policy di posizionamento esistente del cluster con la NIC di gestione ESXi principale (nic0) e le NIC dinamiche con tag VLAN per vMotion (VLAN 2), vSAN (VLAN 3) e 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())"

Aggiorna l'appartenenza al NEG

Tutti i nodi di un cluster in una zona devono appartenere allo stesso NEG a livello di zona della subnet. Aggiungi i nuovi nodi al NEG di gestione e al NEG NSX TEP. Non è necessario modificare le policy di alta affidabilità o le regole di forwarding:

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

Reimposta la password root di ESXi

Reimposta la password root di ogni nuovo nodo in modo che corrisponda alla password ESXi root archiviata in Secret Manager. Utilizzerai lo stesso secret per eseguire il provisioning dei nodi in un passaggio successivo. Se hai modificato o ruotato le password di ESXi root o VCF dopo il deployment iniziale, aggiorna il secret corrispondente in Secret Manager prima di eseguire questi comandi.

Per reimpostare la password root su ogni nuovo nodo, esegui i seguenti comandi dalla VM jumpbox e inserisci la password ESXi root iniziale quando richiesto:

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

Aggiungi i nuovi indirizzi IP al pool di rete e al pool TEP

Il pool di rete del cluster (cl02-np01) e il pool NSX TEP (cl02-tep-pool) inizialmente contengono solo gli indirizzi IP dei nodi del cluster esistenti. Aggiungi gli indirizzi IP esatti delle NIC dinamiche di Compute Engine dei nuovi nodi a entrambi i pool in modo che VCF e NSX assegnino gli indirizzi IP dal set già configurato sulle NIC di Compute Engine.

Aggiorna il pool di rete (vMotion e vSAN): aggiungi gli indirizzi IP vMotion e vSAN dei nuovi nodi al pool di rete cl02-np01 utilizzando VCF Operations o l'API SDDC Manager:

Operazioni VCF

In VCF Operations, vai a Gestione pool di rete, seleziona il pool di rete cl02-np01, modifica le reti vMotion e vSAN e aggiungi gli intervalli di indirizzi IP per i nuovi nodi.

API SDDC Manager

Esegui i comandi seguenti per aggiungere un intervallo di IP singolo per ogni nuovo nodo al pool di rete:

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'

Aggiorna il pool di IP TEP NSX: in NSX Manager (l'host NSX_MANAGER), vai a Networking > Pool di indirizzi IP, modifica il pool di indirizzi IP cl02-tep-pool e aggiungi gli indirizzi IP TEP dei nuovi nodi agli intervalli IP della subnet (192.168.4.24-192.168.4.25 in questo esempio) mantenendo il gateway impostato su 192.168.4.1. Verifica la configurazione aggiornata del pool:
```
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}'
```
Prima di eseguire i comandi, sostituisci quanto segue:
- NSX_ADMIN_PASSWORD: la password di NSX Manager admin (disponibile dall'endpoint SDDC Manager /v1/credentials o da VCF Operations).
- TEP_POOL_ID: l'ID del pool di indirizzi IP cl02-tep-pool.
Nota: se il pool TEP non ha indirizzi IP liberi, NSX non può preparare i nuovi nodi. Se i pool contengono altri indirizzi IP liberi (ad esempio, indirizzi IP rilasciati da nodi rimossi in precedenza), VCF o NSX potrebbero allocare questi indirizzi IP anziché gli indirizzi IP NIC di Compute Engine dei nuovi nodi. In questo caso, allinea le NIC in Allinea le NIC dinamiche vMotion e vSAN e Allinea le NIC dinamiche NSX TEP.

Commissiona i nodi

Esegui il provisioning dei nuovi nodi nell'inventario di SDDC Manager utilizzando VCF Operations o l'API SDDC Manager:

Operazioni VCF

In VCF Operations, vai a Inventario > Host > Commissiona host.
Seleziona il pool di rete cl02-np01 e il tipo di spazio di archiviazione vSAN ESA.
Inserisci i nuovi FQDN dell'host e le credenziali root.
Accetta le impronte SSL, convalida gli host e fai clic su Commissiona.

API SDDC Manager

Esegui i seguenti comandi per convalidare e commissionare gli host, quindi esegui il polling dello stato dell'attività finché non restituisce Successful:

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'

Se un'impronta SSL dell'host mostra un nome di certificato interno (non FQDN), esegui il comando esxcli network ip dns search add -d vmware.gve sull'host, esegui di nuovo lo script /var/lib/vmware/osdata/init.sh, quindi esegui il comando /sbin/generate-certificates e riavvia i servizi rhttpproxy e hostd.

Controlla l'allineamento degli IP prima dell'espansione

Mantieni attive tutte le convalide di connettività di rete, vSAN e vMotion in SDDC Manager. Questi controlli di convalida vengono superati solo quando gli indirizzi IP vmk1 e vmk2 assegnati da VCF a ogni nuovo nodo corrispondono agli indirizzi IP della NIC dinamica di Compute Engine.

Verifica che gli indirizzi IP del pool non utilizzati corrispondano ai nuovi indirizzi IP della NIC di Compute Engine: confronta gli intervalli del pool di rete con gli indirizzi IP già utilizzati dagli host esistenti e con le NIC di Compute Engine dei nuovi nodi. Gli unici indirizzi IP del pool non utilizzati dagli host esistenti devono essere gli indirizzi IP dei nuovi nodi:

# 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

Verifica che SDDC Manager non ignori le convalide: sull'appliance SDDC Manager (come root), verifica che il file application.properties non contenga proprietà validation.disable.*:

# 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

Espandi il cluster

Aggiungi i nodi commissionati al cluster di destinazione utilizzando VCF Operations o l'API SDDC Manager:

Operazioni VCF

In VCF Operations (o nell'interfaccia utente di SDDC Manager), apri il dominio del cluster, seleziona il cluster cl02, scegli Azioni > Aggiungi host, seleziona i nodi di cui è stato eseguito il provisioning, mappa l'interfaccia vmnic0 all'uplink uplink1 del VDS del cluster e invia il workflow. Vai a Gestione del parco risorse > Attività per monitorare l'attività e registrarne l'ID (imposta la variabile TASK_ID su questo valore per la sezione successiva).

API SDDC Manager

Esegui questi comandi per convalidare la specifica di espansione ed espandere il cluster:

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'

Quando espandi un cluster, SDDC Manager alloca gli indirizzi IP vMotion e vSAN dal pool di rete senza preservare l'ordine degli host. Se SDDC Manager assegna a un nuovo nodo un indirizzo IP diverso dalla NIC dinamica di Compute Engine, l'attività viene messa in pausa nella fase di verifica della connettività vSAN e vMotion. Lascia l'attività nello stato di errore, completa i passaggi descritti in Allinea le NIC dinamiche vMotion e vSAN, quindi riprova la stessa attività. Non avviare una nuova richiesta di espansione per questi nodi: dopo un'espansione non riuscita, i nodi non sono più nello stato non assegnato e SDDC Manager rifiuta una nuova richiesta di espansione.

Allinea le NIC dinamiche vMotion e vSAN

Completa i passaggi descritti in questa sezione se l'attività di espansione del cluster si interrompe durante la fase di verifica della connettività vSAN e vMotion. Se l'attività supera questo passaggio, esegui solo il passaggio 1 per confermare l'allineamento, quindi vai ad Allinea le NIC dinamiche NSX TEP.

Leggi gli indirizzi IP allocati da VCF e confrontali con le NIC di Compute Engine: esegui i due comandi del passaggio 1 di Controlla l'allineamento degli IP pre-espansione. Solo i nuovi nodi rientrano nell'ambito.

Elimina prima tutte le NIC dinamiche non corrispondenti, quindi aggiungile di nuovo: elimina ogni NIC dinamica non corrispondente (l'interfaccia nic0.2 per vMotion e l'interfaccia nic0.3 per vSAN) su ogni nuovo nodo prima di aggiungere nuovamente un'interfaccia; in caso contrario, gli indirizzi IP scambiati non vanno a buon fine con un errore IP_IN_USE:

# 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}"

Riprova l'attività non riuscita: in VCF Operations, vai a Gestione del parco risorse

Attività per riprovare l'attività di espansione o esegui il seguente comando API di SDDC Manager:
```
curl -s -X PATCH "https://${SDDC_MANAGER}/v1/tasks/${TASK_ID}" \
    -H "Authorization: Bearer ${TOKEN}" -H "Content-Type: application/json" \
    -d '{"status": "RETRY"}'
```
Se l'attività non riesce di nuovo, ripeti i passaggi 1 e 2 prima di riprovare.

Allinea le NIC dinamiche NSX TEP

Dopo che NSX ha configurato i nuovi nodi come nodi di trasporto, verifica e allinea le NIC dinamiche TEP NSX VLAN 4 (vmk10) sui nuovi nodi.

Recupera gli indirizzi IP TEP allocati da NSX: esegui una query su NSX Manager (o esegui il comando esxcli network ip interface ipv4 get -i vmk10 su ogni host ESXi):

# 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'

Ricrea le NIC TEP non corrispondenti: confronta gli indirizzi IP vmk10 allocati da NSX con la NIC TEP di Compute Engine (VLAN 4) di ogni nuovo nodo. Solo i nuovi nodi sono inclusi nell'ambito; non modificare le NIC TEP dei nodi esistenti. Per tutti i nuovi nodi non corrispondenti, scollega prima ogni nodo dal NEG TEP ed elimina l'interfaccia nic0.4 in tutti i nodi non corrispondenti. Poi, aggiungi di nuovo l'interfaccia nic0.4 e ricollega i nodi al NEG TEP:

# 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}"

Verifica l'espansione del cluster

Una volta completata l'attività di espansione del cluster, verifica quanto segue:

vCenter Server: i nuovi nodi sono connessi e integri nel cluster cl02 senza allarmi di rete.
vSAN: per il cluster cl02, vai a Monitora > vSAN > Skyline Health e verifica che tutti i controlli di integrità siano stati superati e che la capacità del datastore includa i nuovi nodi.
NSX Manager: vai a System > Fabric > Hosts e verifica che ogni nuovo nodo mostri Success e Up e che i tunnel di overlay siano attivi.
VCF Operations: i nuovi nodi vengono assegnati al cluster cl02 e l'elenco delle attività non contiene attività non riuscite.

Da una shell host ESXi (ad esempio esxi-h10), verifica la connettività dei jumbo frame (MTU 8896 meno l'intestazione IP/ICMP di 28 byte = 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

Errori vSAN da tollerare e numero di host

Utilizza la tabella seguente per determinare il numero di nodi richiesti dal cluster quando aggiungi nodi o che devi conservare quando li rimuovi:

Errori da tollerare	Schema di posizionamento dei dati	Numero minimo di host
`FTT=1`	RAID-1 (mirroring) o RAID-5 (codifica di cancellazione)	3 (consigliamo 4 o più per la ricostruzione dopo un errore dell'host o durante la manutenzione)
`FTT=2`	RAID-1 (mirroring)	5
`FTT=2`	RAID-6 (erasure coding)	6

Rimuovi i nodi da un cluster

Completa i controlli pre-rimozione

Prima di rimuovere i nodi da un cluster, verifica quanto segue:

Numero di host: dopo la rimozione dei nodi, il cluster conserva almeno tre nodi e almeno il numero minimo di host elencato in Numero di host e di errori vSAN da tollerare richiesto dalle policy di archiviazione attive.
Capacità: in vCenter Server, per il cluster cl02, vai a Monitora > vSAN > Controllo pre-migrazione dei dati per ogni nodo che prevedi di rimuovere (con l'opzione Migrazione completa dei dati) e verifica che i nodi rimanenti abbiano una capacità vSAN e di computing sufficiente.
Integrità: vSAN Skyline Health viene superato senza errori e non sono presenti attività non riuscite in VCF Operations o SDDC Manager.

Leader delle policy di alta affidabilità: verifica che nessun servizio di backend utilizzi un nodo che stai rimuovendo come leader delle policy di alta affidabilità. Se un servizio di backend utilizza uno di questi nodi come leader, aggiorna il leader a un nodo rimanente (l'host che esegue la VM dell'appliance dopo la migrazione):

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}"

Rimuovi i nodi dal cluster

Rimuovi i nodi di destinazione dal cluster in VCF. VCF mette ogni nodo in modalità di manutenzione, esegue la migrazione delle VM ed evacua i dati vSAN. Puoi rimuovere i nodi utilizzando VCF Operations o l'API SDDC Manager:

Operazioni VCF

In VCF Operations (o nell'interfaccia utente di SDDC Manager), apri il dominio del cluster, seleziona il cluster cl02, scegli Azioni > Rimuovi host, seleziona i nodi da rimuovere e conferma.

API SDDC Manager

Esegui i seguenti comandi per convalidare la specifica di compattazione e rimuovere gli host dal cluster:

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'

Dismettere i nodi

Dopo aver rimosso i nodi dal cluster, dismettili dall'inventario di SDDC Manager utilizzando VCF Operations o l'API SDDC Manager:

Operazioni VCF

In VCF Operations, vai a Inventario > Host, seleziona i nodi non assegnati e fai clic su Dismettere (per ulteriori informazioni, consulta Dismettere gli host nella documentazione di VMware Cloud Foundation).

API SDDC Manager

Esegui i seguenti comandi per inviare una richiesta di dismissione ed eseguire il polling dell'attività finché non restituisce Successful:

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'

Rimuovi i nodi dai NEG

Rimuovi i nodi dismessi dal NEG di gestione e dal NEG NSX TEP:

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

Se l'interfaccia a riga di comando gcloud rifiuta la rimozione dal NEG TEP senza un indirizzo IP esplicito, includi l'indirizzo IP dell'endpoint (come mostrato dal comando di verifica) nel flag --remove-endpoint: --remove-endpoint="instance=HOST,ip=TEP_IP".

Elimina le istanze bare metal

Disattiva la protezione da eliminazione su ogni host dismesso ed elimina l'istanza bare metal di Compute Engine (Compute Engine elimina automaticamente il disco di avvio con l'istanza):

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)"

Pulisci i record DNS e i pool di IP

Elimina i record Cloud DNS di inoltro (A) e inversi (PTR) dei nodi rimossi:

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

Gli indirizzi IP vMotion, vSAN e TEP dei nodi rimossi tornano disponibili nel pool di rete e nel pool NSX TEP. Puoi conservare questi indirizzi IP per un nodo futuro (assegnando allo stesso nodo futuro gli stessi indirizzi IP NIC di Compute Engine) o rimuoverli dai pool in modo che VCF e NSX non li assegnino a un nodo futuro le cui NIC di Compute Engine utilizzano indirizzi IP diversi.

Verifica la rimozione del nodo

Dopo aver completato il workflow di rimozione dei nodi, verifica quanto segue:

vCenter Server: il cluster cl02 mostra solo i nodi rimanenti, tutti connessi e integri, e vSphere HA e DRS non segnalano errori.
vSAN: Skyline Health passa e tutti gli oggetti virtuali sono conformi (per il cluster cl02, vai a Monitora > vSAN > Oggetti virtuali).
NSX Manager: i nodi rimossi non sono più elencati come nodi di trasporto e i nodi rimanenti mostrano Attivo.
VCF Operations e SDDC Manager: i nodi rimossi non sono più nell'inventario degli host e non sono presenti attività non riuscite.
Google Cloud: le istanze bare metal, i dischi di avvio, gli endpoint NEG e i record DNS dei nodi rimossi vengono eliminati.

Risolvi i problemi di espansione del cluster e rimozione dei nodi

La tabella seguente elenca i problemi, le cause e le soluzioni comuni per l'aggiunta o la rimozione di nodi in un cluster vSphere:

Problema	Causa	Risoluzione
L'espansione del cluster non riesce durante il controllo della connettività per vSAN e vMotion; i nuovi nodi segnalano uno stato non integro	Quando espandi un cluster, SDDC Manager alloca gli indirizzi IP `vmk1` e `vmk2` dal pool di rete senza preservare l'ordine degli host.	Mantieni attive le convalide. Aggiungi solo gli indirizzi IP dei nuovi nodi al pool di rete. Se l'attività viene messa in pausa durante il controllo della connettività, allinea le NIC dinamiche e riprova la stessa attività.
Lo stato dell'host NSX è `Degraded` o i tunnel sono inattivi sui nuovi nodi	NSX Manager assegna gli indirizzi IP TEP (`vmk10`) dal pool di IP in modo casuale, pertanto potrebbero non corrispondere alla NIC TEP di Compute Engine.	Allinea le NIC dinamiche NSX TEP come descritto in Allinea le NIC dinamiche NSX TEP.
NSX non può preparare i nuovi nodi	Il pool di IP NSX TEP del cluster non ha indirizzi IP liberi.	Aggiungi gli indirizzi IP TEP dei nuovi nodi al pool di IP TEP, quindi riprova l'attività.
SDDC Manager rifiuta una nuova richiesta di espansione per gli stessi nodi	Un'attività di espansione non riuscita lascia i nodi al di fuori dello stato `UNASSIGNED_USEABLE`.	Riprova l'attività non riuscita (`PATCH /v1/tasks/TASK_ID` con `{"status": "RETRY"}`) anziché inviare una nuova richiesta di espansione.
La messa in funzione di un nodo non riesce perché il nodo è già stato messo in funzione	Non puoi commissionare un host due volte.	Procedi con l'espansione del cluster o dismetti prima il nodo se devi eseguirne nuovamente il provisioning (ad esempio, con un pool di rete diverso).
Errore `IP_IN_USE` durante l'aggiunta di una NIC dinamica	Due nodi hanno scambiato gli indirizzi IP o un indirizzo IP pianificato si sovrappone a un altro nodo.	Elimina tutte le NIC dinamiche non corrispondenti in tutti i nuovi nodi prima di aggiungere nuovamente un'interfaccia e verifica il piano degli indirizzi IP.
Convalida della rimozione dei nodi non riuscita	La rimozione dei nodi riduce il cluster a un numero di host inferiore alla sua dimensione minima oppure i nodi rimanenti non hanno capacità sufficiente.	Rimuovi meno nodi o aggiungi prima capacità; non utilizzare la proprietà `"force": true`.
L'interfaccia a riga di comando `gcloud` rifiuta di eliminare l'istanza bare metal	La protezione da eliminazione è abilitata nell'istanza.	Esegui il comando `gcloud compute instances update HOST --no-deletion-protection` prima di eliminare l'istanza.
Domini di errore vSAN errati dopo l'aggiunta di nodi	Hai creato nuovi nodi in una policy di posizionamento diversa o due cluster condividono una policy di posizionamento.	Crea nuovi nodi nella policy di posizionamento del cluster e distribuiscili tra i domini di disponibilità.
Errori vSAN, timeout vMotion o frammentazione dell'overlay NSX	L'MTU configurata è maggiore dell'MTU della rete VPC (`8896` byte).	I nuovi nodi ereditano il VDS e i pool del cluster; mantieni l'MTU impostata su `8896` byte in tutti i componenti.
L'impronta o il certificato SSL dell'host mostra un nome interno	Il dominio di ricerca DNS non è impostato sull'host.	Esegui il comando `esxcli network ip dns search add -d vmware.gve`, esegui nuovamente lo script `/var/lib/vmware/osdata/init.sh`, quindi esegui il comando `/sbin/generate-certificates` e riavvia i servizi `rhttpproxy` e `hostd`.
Gli host non possono inviare un ping al gateway della subnet (`.1`)	Google Cloud non risponde alle richieste echo ICMP sugli indirizzi IP del gateway della subnet.	Comportamento previsto; ignora gli avvisi di ping del gateway.

Passaggi successivi

Aggiungi un nuovo cluster vSphere a un dominio esistente in Aggiungi un cluster vSphere a un dominio.
Gestisci la capacità dei nodi bare metal nella console Google Cloud in Gestisci la capacità dei nodi.
Scala la capacità dei nodi utilizzando Terraform in Gestisci la capacità dei nodi utilizzando Terraform.
Consulta le linee guida sulle norme di posizionamento in Policy di posizionamento e domini di disponibilità.
Consulta le linee guida per il dimensionamento e l'architettura dei cluster in Informazioni sui cluster vSphere.
Esamina le soluzioni alternative comuni per il deployment e le operazioni in Problemi noti.