Google utilise la technologie IA pour traduire le contenu dans votre langue préférée. Les traductions générées par IA peuvent contenir des erreurs.

Ajouter ou supprimer des nœuds dans un cluster vSphere

Ce document explique comment ajouter un ou plusieurs nœuds Bare Metal Compute Engine à un cluster vSphere existant (extension de cluster) et comment supprimer un ou plusieurs nœuds d'un cluster (compaction de cluster) dans VMware Cloud Foundation (VCF) 9.1 dans la solution VMware sur Google Cloud. Développez ou compactez un cluster lorsque vous devez augmenter ou réduire la capacité de calcul et de stockage vSAN d'un cluster existant dans le domaine de gestion ou un domaine de charge de travail VI. La même procédure s'applique, que vous ajoutiez ou supprimiez un ou plusieurs nœuds : listez un ou plusieurs nœuds dans la variable d'environnement ADD_HOSTS ou REMOVE_HOSTS.

Résumé de l'architecture

Lorsque vous ajoutez ou supprimez des nœuds dans un cluster vSphere existant, le workflow utilise l'architecture suivante :

Ajout de nœuds : chaque nouveau nœud est une instance Bare Metal z3-highmem-192-highlssd-metal que vous déployez dans la même zone, avec la même stratégie d'emplacement et le même type de machine que les nœuds existants du cluster. Chaque nœud possède une interface réseau principale (nic0) sur le sous-réseau de gestion ESXi de votre réseau cloud privé virtuel (VPC) et des interfaces réseau dynamiques avec marquage VLAN pour vMotion, vSAN et le point de terminaison de tunnel NSX (TEP). Le nœud rejoint les groupes de points de terminaison du réseau (NEG) zonaux existants. Vous mettez ensuite en service le nœud dans SDDC Manager avec le pool de réseau du cluster et l'ajoutez au cluster.
Suppression de nœuds : vous supprimez d'abord le nœud du cluster dans VCF, ce qui migre les VM de charge de travail et évacue les données vSAN de l'hôte. Vous devez ensuite mettre l'hôte hors service depuis SDDC Manager et le supprimer des NEG zonaux avant de supprimer l'instance Bare Metal Compute Engine sous-jacente.
Alignement des adresses IP : comme pour la création de clusters, VCF alloue des adresses IP vMotion et vSAN à partir du pool réseau du cluster, et NSX alloue des adresses IP TEP (vmk10) à partir du pool d'adresses IP NSX. Vous alignez les cartes d'interface réseau dynamiques Compute Engine des nouveaux nœuds sur les adresses IP allouées par VCF, tout en gardant toutes les validations VCF activées.
Aucune modification de l'appareil : l'ajout ou la suppression de nœuds de cluster ne nécessite pas de nouveaux enregistrements Cloud DNS, services de backend, règles de haute disponibilité (HA) ni règles de transfert pour les appareils de gestion.

Avant de commencer

Avant d'ajouter ou de supprimer des nœuds, vérifiez les exigences décrites dans les sections suivantes et configurez vos variables d'environnement.

Vérifier les exigences de l'environnement

Vérifiez que votre environnement répond aux exigences suivantes :

Autorisations : vous disposez des rôles Identity and Access Management (IAM) requis sur le projet cible, y compris Administrateur Compute (roles/compute.admin), Administrateur DNS (roles/dns.admin) et Accesseur de secrets Secret Manager (roles/secretmanager.secretAccessor).
Identifiants dans Secret Manager : si vous avez modifié ou effectué une rotation de vos mots de passe ESXi root, SDDC Manager, vCenter Server ou NSX Manager dans VCF après le déploiement initial, Secret Manager n'est pas mis à jour automatiquement. Avant d'exécuter les commandes de ce document, mettez à jour les secrets correspondants dans Secret Manager ou fournissez directement les mots de passe mis à jour afin qu'ils correspondent à vos identifiants VCF actifs.
État du cluster et du domaine : le cluster cible et son domaine sont opérationnels (vCenter Server, vSAN, NSX Manager, SDDC Manager et VCF Operations) et ne comportent aucune tâche ayant échoué.
Pour ajouter des nœuds :
- Votre projet dispose d'un quota bare metal z3 suffisant dans la région et la zone cibles.
- Les nouveaux nœuds utilisent le même type de machine que les nœuds existants du cluster (z3-highmem-192-highlssd-metal pour vSAN Express Storage Architecture (ESA)) et sont attribués à la stratégie d'emplacement existante du cluster (chaque stratégie d'emplacement n'appartient qu'à un seul cluster).
- Chaque nouveau nœud dispose de disques SSD locaux NVMe sans partitions préexistantes.
- Si votre organisation applique la règle d'administration constraints/compute.trustedImageProjects ou utilise un périmètre de service VPC Service Controls, assurez-vous que votre projet autorise l'accès aux images du projet smve-prod-public-images (projects/999037279871). Pour en savoir plus, consultez Gérer la capacité des nœuds.
- Mise en réseau basée sur les VLAN : la solution VMware nécessite que la propriété Résoudre le masque de sous-réseau des sous-réseaux de votre réseau VPC soit définie sur Diffuser la plage principale uniquement avec l'apprentissage pour prendre en charge la mise en réseau basée sur les VLAN. Ouvrez une demande d'assistance dans le Centre d'assistance de la consoleGoogle Cloud en fournissant les informations suivantes :
  - Produit : Google Cloud VMware Engine
  - Priority : P2
  - Catégorie : Connectivité réseau
  - Impact sur l'entreprise : question technique d'ordre général
  - Fournissez plus de détails : Allowlist L2 network connectivity for my project, ainsi que l'ID de votre projet, le numéro de projet, et la région et la zone cibles de votre déploiement.
  Pour en savoir plus sur la compatibilité avec la mise en réseau basée sur les VLAN, consultez Émulation de couche 2 : diffusion ARP et apprentissage MAC personnalisé.
Pour supprimer des nœuds :
- Les nœuds restants disposent d'une capacité de calcul et de stockage vSAN suffisante pour vos charges de travail actives.
- Après la suppression du nœud, le cluster conserve au moins trois nœuds (le minimum pour vSAN avec un échec à tolérer (FTT=1)) ou le nombre minimal d'hôtes requis par vos règles de stockage actives (voir Échecs à tolérer et nombre d'hôtes vSAN).
VM Jumpbox : vous avez accès à une VM Jumpbox sur laquelle la CLI gcloud, curl et jq sont installés, et qui dispose d'une connectivité réseau au réseau VPC (par exemple, dans le sous-réseau bm-gcp-demo).

Examiner les exemples de paramètres d'environnement

Les commandes de ce document utilisent les exemples de paramètres suivants :

Paramètre d'entrée	Exemple de valeur	Description
ID du projet, région et zone	`PROJECT_ID` / `us-east4` / `us-east4-b`	Même projet, même région et même zone que le cluster cible
ID client	`demo`	Identifiant utilisé dans les noms de ressources existants
Cluster cible	`cl02` (`esxi-h7`, `esxi-h8`, `esxi-h9`)	Cluster existant dans le domaine de gestion ou un domaine de charge de travail VI
Stratégie d'emplacement	`bm-cl02`	Règle d'emplacement de groupe existante du cluster
Pool de réseaux et VDS	`cl02-np01`/`cl02-vds-01`	Pool de réseaux et vSphere Distributed Switch (VDS) existants du cluster
Pool d'adresses IP NSX TEP	`cl02-tep-pool`	Pool d'adresses IP NSX existant du cluster
NSX Manager	`nsx01.vmware.gve`	NSX Manager du domaine du cluster (ou `nsx05.vmware.gve` pour le domaine de charge de travail `wld01` avec une instance NSX dédiée)
Type de machine	`z3-highmem-192-highlssd-metal`	Même type de machine que les nœuds existants dans le cluster
Réseau et sous-réseaux VPC (ID de VLAN)	`bm-demo` ; `bm-mgmt-demo` (sans tag), `bm-vmotion-demo` (`2`), `bm-vsan-demo` (`3`), `bm-nsx-demo` (`4`)	Réseau VPC et sous-réseaux de couche 2 existants
NEG zonaux	`bm-mgmt-demo`, `bm-nsx-tep-demo`	NEG de gestion et NSX TEP existants
Gestionnaire SDDC	`sddcm.vmware.gve` (`192.168.0.3`)	Dispositif SDDC Manager existant
Mot de passe `root` ESXi	`esxi-root-password`	Secret Secret Manager existant contenant le mot de passe ESXi `root`

Planifier les adresses IP et les noms d'hôte

L'exemple suivant ajoute deux nœuds (esxi-h10 et esxi-h11) au cluster cl02, puis en supprime un (esxi-h11). Pour ajouter ou supprimer un seul nœud, n'incluez que ce nœud dans votre tableau de variable d'environnement :

Hôte ESXi	Adresse IP de gestion (`nic0`)	vMotion (VLAN 2)	vSAN (VLAN 3)	TEP NSX (VLAN 4)	Domaine de disponibilité	Action
`esxi-h10`	`192.168.0.164`	`192.168.2.24`	`192.168.3.24`	`192.168.4.24`	`4`	Ajouter
`esxi-h11`	`192.168.0.165`	`192.168.2.25`	`192.168.3.25`	`192.168.4.25`	`5`	Ajouter, puis supprimer

Répartissez les nœuds du cluster sur les domaines de disponibilité de la stratégie d'emplacement du cluster : étant donné que les nœuds existants (esxi-h7 à esxi-h9) utilisent les domaines de disponibilité 1 à 3, les nouveaux nœuds utilisent les domaines de disponibilité 4 et 5.

Vérifier les quotas régionaux

Avant de provisionner des nœuds Bare Metal ou de créer un cluster, vérifiez que votre projet dispose d'un quota Compute Engine régional et mondial suffisant. Ajoutez les ressources de tous les clusters existants de la région aux valeurs incrémentielles suivantes avant de les comparer au quota de votre projet :

Métrique de quota	Ressources requises par nœud Bare Metal	Ressources requises pour un cluster à trois nœuds
`compute.googleapis.com/cpus_per_vm_family` pour `Z3`	192 vCPU	3 × 192 = 576 vCPU
`compute.googleapis.com/local_ssd_total_storage_per_vm_family` pour `Z3`	72 To	3 × 72 To = 216 To
`compute.googleapis.com/hyperdisk_balanced_total_storage`	128 Go	3 × 128 Go = 384 Go
`compute.googleapis.com/resource_policies`	0 lors de l'ajout de nœuds à un cluster existant	1 stratégie d'emplacement par répartition par cluster
`compute.googleapis.com/regional_backend_services_protocol_forwarding_fast_ha`	0 lors de l'ajout de nœuds ou de clusters sans nouvelles appliances	1 par nouvelle adresse IP virtuelle d'appareil de gestion VCF ou point de terminaison NSX Edge

Pour obtenir la liste complète des quotas requis et des instructions sur la façon d'afficher ou de demander des augmentations de quota, consultez Quotas et limites.

Définir des variables d'environnement

Définissez les variables d'environnement suivantes dans votre shell jumpbox. Répertoriez les nœuds à ajouter dans la variable d'environnement ADD_HOSTS et les nœuds à supprimer dans la variable d'environnement REMOVE_HOSTS (une ou plusieurs entrées chacune) :

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

Avant d'exécuter les commandes, remplacez les éléments suivants :

PROJECT_ID : ID de votre projet Google Cloudcible.
VCF_ADMIN_PASSWORD : mot de passe de l'administrateur de votre SDDC Manager.

Vérifiez qu'aucune des adresses IP que vous prévoyez d'utiliser n'est déjà utilisée par des règles de transfert ou des instances existantes :

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

Ajouter des nœuds à un cluster

Pour étendre un cluster vSphere existant en ajoutant des nœuds Bare Metal, suivez les étapes décrites dans les sections suivantes.

Créer des enregistrements DNS

Étant donné que les zones gérées Cloud DNS de transfert et inversées existent déjà, créez des enregistrements de transfert (A) et inversés (PTR) uniquement pour les nouveaux nœuds :

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

Créer des instances Bare Metal

Créez chaque nouveau nœud dans la stratégie d'emplacement existante du cluster avec la carte d'interface réseau de gestion ESXi principale (nic0) et les cartes d'interface réseau dynamiques avec marquage VLAN pour vMotion (VLAN 2), vSAN (VLAN 3) et 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())"

Mettre à jour l'appartenance au NEG

Tous les nœuds d'un cluster d'une zone doivent appartenir au même NEG zonal du sous-réseau. Ajoutez les nouveaux nœuds au NEG de gestion et au NEG NSX TEP. Vous n'avez pas besoin de modifier les règles de haute disponibilité ni les règles de transfert :

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

Réinitialiser le mot de passe racine ESXi

Réinitialisez le mot de passe root de chaque nouveau nœud pour qu'il corresponde au mot de passe ESXi root stocké dans Secret Manager. Vous utiliserez le même secret pour mettre en service les nœuds lors d'une étape ultérieure. Si vous avez modifié ou alterné vos mots de passe ESXi root ou VCF après le déploiement initial, mettez à jour le secret correspondant dans Secret Manager avant d'exécuter ces commandes.

Pour réinitialiser le mot de passe root sur chaque nouveau nœud, exécutez les commandes suivantes à partir de la VM jumpbox et saisissez le mot de passe ESXi root initial lorsque vous y êtes invité :

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

Ajouter les nouvelles adresses IP au pool de réseaux et au pool de TEP

Le pool réseau du cluster (cl02-np01) et le pool NSX TEP (cl02-tep-pool) ne contiennent initialement que les adresses IP des nœuds de cluster existants. Ajoutez les adresses IP exactes de la carte d'interface réseau dynamique Compute Engine des nouveaux nœuds aux deux pools afin que VCF et NSX allouent des adresses IP à partir de l'ensemble déjà configuré sur les cartes d'interface réseau Compute Engine.

Mettre à jour le pool de réseaux (vMotion et vSAN) : ajoutez les adresses IP vMotion et vSAN des nouveaux nœuds au pool de réseaux cl02-np01 à l'aide de VCF Operations ou de l'API SDDC Manager :

Opérations VCF

Dans VCF Operations, accédez à Network pool management (Gestion du pool de réseaux), sélectionnez le pool de réseaux cl02-np01, modifiez les réseaux vMotion et vSAN, puis ajoutez les plages d'adresses IP des nouveaux nœuds.

API SDDC Manager

Exécutez les commandes suivantes pour ajouter une plage d'adresses IP unique par nouveau nœud au pool de réseau :

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'

Mettre à jour le pool d'adresses IP TEP NSX : dans NSX Manager (l'hôte NSX_MANAGER), accédez à Mise en réseau > Pools d'adresses IP, modifiez le pool d'adresses IP cl02-tep-pool et ajoutez les adresses IP TEP des nouveaux nœuds aux plages d'adresses IP du sous-réseau (192.168.4.24–192.168.4.25 dans cet exemple) tout en conservant la passerelle définie sur 192.168.4.1. Vérifiez la configuration du pool mis à jour :
```
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}'
```
Avant d'exécuter les commandes, remplacez les éléments suivants :
- NSX_ADMIN_PASSWORD : mot de passe admin de votre NSX Manager (disponible à partir du point de terminaison SDDC Manager /v1/credentials ou de VCF Operations).
- TEP_POOL_ID : ID du pool d'adresses IP cl02-tep-pool.
Remarque : Si le pool TEP ne dispose d'aucune adresse IP libre, NSX ne peut pas préparer les nouveaux nœuds. Si les pools contiennent d'autres adresses IP libres (par exemple, des adresses IP libérées par des nœuds précédemment supprimés), VCF ou NSX peut allouer ces adresses IP au lieu des adresses IP de la carte d'interface réseau Compute Engine des nouveaux nœuds. Si cela se produit, vous alignez les cartes d'interface réseau dans Aligner les cartes d'interface réseau dynamiques vMotion et vSAN et Aligner les cartes d'interface réseau dynamiques NSX TEP.

Mettre en service les nœuds

Mettez en service les nouveaux nœuds dans l'inventaire SDDC Manager à l'aide de VCF Operations ou de l'API SDDC Manager :

Opérations VCF

Dans VCF Operations, accédez à Inventory > Hosts > Commission Hosts (Inventaire > Hôtes > Mettre en service des hôtes).
Sélectionnez le pool de réseaux cl02-np01 et le type de stockage vSAN ESA.
Saisissez les nouveaux noms de domaine complets de l'hôte et les identifiants root.
Acceptez les empreintes SSL, validez les hôtes, puis cliquez sur Commission (Mettre en service).

API SDDC Manager

Exécutez les commandes suivantes pour valider et mettre en service les hôtes, puis interrogez l'état de la tâche jusqu'à ce qu'elle renvoie 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'

Si l'empreinte SSL d'un hôte affiche un nom de certificat interne (non-FQDN), exécutez la commande esxcli network ip dns search add -d vmware.gve sur l'hôte, réexécutez le script /var/lib/vmware/osdata/init.sh, puis exécutez la commande /sbin/generate-certificates et redémarrez les services rhttpproxy et hostd.

Vérifier l'alignement des adresses IP avant l'expansion

Laissez toutes les validations de connectivité réseau, vSAN et vMotion activées dans SDDC Manager. Ces vérifications de validation ne réussissent que lorsque les adresses IP vmk1 et vmk2 que VCF attribue à chaque nouveau nœud correspondent à ses adresses IP de carte d'interface réseau dynamique Compute Engine.

Vérifiez que les adresses IP du pool inutilisées correspondent aux nouvelles adresses IP de la carte d'interface réseau Compute Engine : comparez les plages du pool réseau avec les adresses IP que les hôtes existants utilisent déjà et les cartes d'interface réseau Compute Engine des nouveaux nœuds. Les seules adresses IP du pool que les hôtes existants n'utilisent pas doivent être les adresses IP des nouveaux nœuds :

# 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

Vérifiez que SDDC Manager ne contourne pas les validations : sur l'appareil SDDC Manager (en tant que root), vérifiez que le fichier application.properties ne contient aucune propriété 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
```

Développer le cluster

Ajoutez les nœuds mis en service au cluster cible à l'aide de VCF Operations ou de l'API SDDC Manager :

Opérations VCF

Dans VCF Operations (ou l'interface utilisateur de SDDC Manager), ouvrez le domaine du cluster, sélectionnez le cluster cl02, choisissez Actions > Ajouter un hôte, sélectionnez les nœuds mis en service, mappez l'interface vmnic0 à la liaison montante uplink1 du VDS du cluster, puis envoyez le workflow. Accédez à Gestion du parc > Tâches pour surveiller la tâche et enregistrer son ID (définissez la variable TASK_ID sur cette valeur pour la section suivante).

API SDDC Manager

Exécutez les commandes suivantes pour valider la spécification d'extension et étendre le 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'

Lorsque vous étendez un cluster, SDDC Manager alloue des adresses IP vMotion et vSAN à partir du pool de réseaux sans conserver l'ordre des hôtes. Si SDDC Manager attribue à un nouveau nœud une adresse IP différente de celle de sa carte d'interface réseau dynamique Compute Engine, la tâche s'interrompt à l'étape de validation de la connectivité vSAN et vMotion. Laissez la tâche à l'état d'échec, suivez la procédure décrite dans Aligner les cartes d'interface réseau dynamiques vMotion et vSAN, puis réessayez d'exécuter la même tâche. Ne lancez pas de nouvelle demande d'extension pour ces nœuds : après l'échec d'une extension, les nœuds ne sont plus à l'état non attribué et SDDC Manager rejette une nouvelle demande d'extension.

Aligner les interfaces réseau dynamiques vMotion et vSAN

Suivez les étapes de cette section si la tâche d'extension du cluster s'interrompt à l'étape de vérification de la connectivité vSAN et vMotion. Si la tâche réussit cette étape, n'exécutez que l'étape 1 pour confirmer l'alignement, puis passez à la section Aligner les cartes d'interface réseau dynamiques NSX TEP.

Lisez les adresses IP allouées par VCF et comparez-les aux cartes d'interface réseau Compute Engine : exécutez les deux commandes de l'étape 1 de la section Vérifier l'alignement des adresses IP avant l'expansion. Seuls les nouveaux nœuds sont concernés.

Supprimez d'abord toutes les cartes d'interface réseau dynamiques non concordantes, puis ajoutez-les à nouveau : supprimez toutes les cartes d'interface réseau dynamiques non concordantes (l'interface nic0.2 pour vMotion et l'interface nic0.3 pour vSAN) sur chaque nouveau nœud avant d'ajouter à nouveau une interface. Sinon, les adresses IP permutées échouent avec une erreur 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}"

Réessayer la tâche ayant échoué : dans Opérations VCF, accédez à Gestion du parc.

Tâches pour réessayer la tâche d'extension, ou exécutez la commande d'API SDDC Manager suivante :
```
curl -s -X PATCH "https://${SDDC_MANAGER}/v1/tasks/${TASK_ID}" \
    -H "Authorization: Bearer ${TOKEN}" -H "Content-Type: application/json" \
    -d '{"status": "RETRY"}'
```
Si la tâche échoue à nouveau, répétez les étapes 1 et 2 avant de réessayer.

Aligner les cartes d'interface réseau dynamiques NSX TEP

Une fois que NSX a configuré les nouveaux nœuds en tant que nœuds de transport, vérifiez et alignez les cartes d'interface réseau dynamiques du TEP NSX VLAN 4 (vmk10) sur les nouveaux nœuds.

Récupérez les adresses IP TEP allouées par NSX : interrogez NSX Manager (ou exécutez la commande esxcli network ip interface ipv4 get -i vmk10 sur chaque hôte 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'

Recréez les cartes d'interface réseau TEP non concordantes : comparez les adresses IP vmk10 allouées par NSX avec la carte d'interface réseau TEP Compute Engine (VLAN 4) de chaque nouveau nœud. Seuls les nouveaux nœuds sont concernés. Ne modifiez pas les cartes d'interface réseau TEP des nœuds existants. Pour tous les nouveaux nœuds non concordants, commencez par dissocier chaque nœud du NEG TEP, puis supprimez l'interface nic0.4 sur tous les nœuds non concordants. Vous devez ensuite rajouter l'interface nic0.4 et rattacher les nœuds au 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}"

Vérifier l'expansion du cluster

Une fois la tâche d'extension du cluster terminée, vérifiez les points suivants :

Serveur vCenter : les nouveaux nœuds sont connectés et opérationnels dans le cluster cl02, sans alarme réseau.
vSAN : pour le cluster cl02, accédez à Surveiller > vSAN > Skyline Health et vérifiez que tous les contrôles d'état sont réussis et que la capacité du datastore inclut les nouveaux nœuds.
NSX Manager : accédez à System > Fabric > Hosts (Système > Structure > Hôtes) et vérifiez que chaque nouveau nœud affiche Success (Réussite) et Up (Actif), et que les tunnels d'overlay sont actifs.
Opérations VCF : les nouveaux nœuds sont attribués au cluster cl02 et la liste des tâches ne contient aucune tâche ayant échoué.

À partir d'un shell d'hôte ESXi (par exemple, esxi-h10), vérifiez la connectivité des trames géantes (MTU 8896 moins l'en-tête IP/ICMP de 28 octets = 8868 octets) :

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

Nombre d'hôtes et de pannes à tolérer vSAN

Utilisez le tableau suivant pour déterminer le nombre de nœuds dont votre cluster a besoin lorsque vous ajoutez des nœuds ou que vous devez conserver lorsque vous en supprimez :

Échecs à tolérer	Schéma de placement des données	Nombre minimal d'hôtes
`FTT=1`	RAID-1 (mise en miroir) ou RAID-5 (codage d'effacement)	3 (4 ou plus sont recommandés pour la reconstruction après une défaillance de l'hôte ou pendant la maintenance)
`FTT=2`	RAID-1 (mise en miroir)	5
`FTT=2`	RAID-6 (codage d'effacement)	6

Supprimer des nœuds d'un cluster

Effectuer les vérifications préalables au retrait

Avant de supprimer des nœuds d'un cluster, vérifiez les points suivants :

Nombre d'hôtes : après la suppression du nœud, le cluster conserve au moins trois nœuds et au moins le nombre minimal d'hôtes indiqué dans la section Nombre d'hôtes et défaillances vSAN à tolérer requises par vos règles de stockage actives.
Capacité : dans vCenter Server, pour le cluster cl02, accédez à Surveiller > vSAN > Vérification préalable de la migration des données pour chaque nœud que vous prévoyez de supprimer (avec l'option Migration complète des données) et vérifiez que les nœuds restants disposent d'une capacité de calcul et vSAN suffisante.
État : vSAN Skyline Health réussit sans erreur, et aucune tâche n'échoue dans VCF Operations ou SDDC Manager.

Leaders de la règle de haute disponibilité : vérifiez qu'aucun service de backend n'utilise un nœud que vous supprimez en tant que leader de la règle de haute disponibilité. Si un service de backend utilise l'un de ces nœuds comme leader, remplacez-le par un nœud restant (l'hôte qui exécute la VM de l'appareil après la migration) :

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

Supprimer les nœuds du cluster

Supprimez les nœuds cibles du cluster dans VCF. VCF place chaque nœud en mode maintenance, migre ses VM et évacue ses données vSAN. Vous pouvez supprimer les nœuds à l'aide de VCF Operations ou de l'API SDDC Manager :

Opérations VCF

Dans VCF Operations (ou l'interface utilisateur de SDDC Manager), ouvrez le domaine du cluster, sélectionnez le cluster cl02, choisissez Actions > Supprimer l'hôte, sélectionnez les nœuds à supprimer, puis confirmez.

API SDDC Manager

Exécutez les commandes suivantes pour valider la spécification de compactage et supprimer les hôtes du 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'

Mettre hors service les nœuds

Après avoir supprimé les nœuds du cluster, mettez-les hors service de l'inventaire SDDC Manager à l'aide de VCF Operations ou de l'API SDDC Manager :

Opérations VCF

Dans VCF Operations, accédez à Inventory > Hosts (Inventaire > Hôtes), sélectionnez les nœuds non attribués, puis cliquez sur Decommission (Mettre hors service). Pour en savoir plus, consultez Mettre hors service des hôtes dans la documentation VMware Cloud Foundation.

API SDDC Manager

Exécutez les commandes suivantes pour envoyer une requête de mise hors service et interroger la tâche jusqu'à ce qu'elle renvoie 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'

Supprimer les nœuds des NEG

Supprimez les nœuds mis hors service du NEG de gestion et du 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

Si la CLI gcloud refuse la suppression du NEG TEP sans adresse IP explicite, incluez l'adresse IP du point de terminaison (comme indiqué par la commande de vérification) dans l'option --remove-endpoint : --remove-endpoint="instance=HOST,ip=TEP_IP".

Supprimer les instances bare metal

Désactivez la protection contre la suppression sur chaque hôte mis hors service et supprimez l'instance Bare Metal Compute Engine (Compute Engine supprime automatiquement le disque de démarrage avec l'instance) :

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

Nettoyer les enregistrements DNS et les pools d'adresses IP

Supprimez les enregistrements Cloud DNS directs (A) et inversés (PTR) des nœuds supprimés :

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

Les adresses IP vMotion, vSAN et TEP des nœuds supprimés sont à nouveau disponibles dans le pool de réseau et le pool NSX TEP. Vous pouvez conserver ces adresses IP pour un futur nœud (en attribuant à ce futur nœud les mêmes adresses IP de carte d'interface réseau Compute Engine) ou les supprimer des pools afin que VCF et NSX ne les allouent pas à un futur nœud dont les cartes d'interface réseau Compute Engine utilisent des adresses IP différentes.

Vérifier la suppression du nœud

Une fois le workflow de suppression de nœud terminé, vérifiez les points suivants :

vCenter Server : le cluster cl02 n'affiche que les nœuds restants, tous connectés et opérationnels, et vSphere HA et DRS ne signalent aucune erreur.
vSAN : Skyline Health réussit et tous les objets virtuels sont conformes (pour le cluster cl02, accédez à Surveiller > vSAN > Objets virtuels).
NSX Manager : les nœuds supprimés ne sont plus listés en tant que nœuds de transport, et les nœuds restants affichent Up (Actif).
VCF Operations et SDDC Manager : les nœuds supprimés ne figurent plus dans l'inventaire des hôtes, et aucune tâche n'a échoué.
Google Cloud : les instances Bare Metal, les disques de démarrage, les points de terminaison NEG et les enregistrements DNS des nœuds supprimés sont supprimés.

Résoudre les problèmes d'expansion de cluster et de suppression de nœuds

Le tableau suivant répertorie les problèmes courants, leurs causes et leurs solutions lors de l'ajout ou de la suppression de nœuds dans un cluster vSphere :

Problème	Cause	Solution
L'expansion du cluster échoue lors de la vérification de la connectivité pour vSAN et vMotion ; les nouveaux nœuds sont signalés comme non opérationnels	Lorsque vous étendez un cluster, SDDC Manager alloue des adresses IP `vmk1` et `vmk2` à partir du pool de réseau sans conserver l'ordre des hôtes.	Laissez les validations activées. Ajoutez uniquement les adresses IP des nouveaux nœuds au pool réseau. Si la tâche s'interrompt lors de la vérification de la connectivité, alignez les cartes d'interface réseau dynamiques et relancez la même tâche.
L'état de l'hôte NSX est `Degraded` ou les tunnels sont indisponibles sur les nouveaux nœuds	NSX Manager attribue de manière aléatoire des adresses IP TEP (`vmk10`) à partir du pool d'adresses IP. Elles peuvent donc ne pas correspondre à la carte d'interface réseau TEP Compute Engine.	Alignez les cartes d'interface réseau dynamiques NSX TEP comme décrit dans Aligner les cartes d'interface réseau dynamiques NSX TEP.
NSX ne peut pas préparer les nouveaux nœuds	Le pool d'adresses IP NSX TEP du cluster ne contient aucune adresse IP libre.	Ajoutez les adresses IP TEP des nouveaux nœuds au pool d'adresses IP TEP, puis réessayez d'effectuer la tâche.
SDDC Manager rejette une nouvelle demande d'extension pour les mêmes nœuds	En cas d'échec d'une tâche d'extension, les nœuds ne sont pas à l'état `UNASSIGNED_USEABLE`.	Réessayez d'exécuter la tâche ayant échoué (`PATCH /v1/tasks/TASK_ID` avec `{"status": "RETRY"}`) au lieu d'envoyer une nouvelle demande d'extension.
La mise en service d'un nœud échoue, car le nœud est déjà mis en service	Vous ne pouvez pas mettre en service un hôte deux fois.	Procédez à l'extension du cluster ou désactivez d'abord le nœud si vous devez le remettre en service (par exemple, avec un autre pool de réseaux).
Erreur `IP_IN_USE` lors de l'ajout d'une carte d'interface réseau dynamique	Deux nœuds ont échangé leurs adresses IP, ou une adresse IP planifiée chevauche celle d'un autre nœud.	Supprimez d'abord toutes les cartes d'interface réseau dynamiques non concordantes sur tous les nouveaux nœuds avant d'ajouter une interface, puis vérifiez votre plan d'adresses IP.
Échec de la validation de la suppression du nœud	La suppression des nœuds réduit le cluster à un nombre d'hôtes inférieur à sa taille minimale, ou les nœuds restants ne disposent pas d'une capacité suffisante.	Supprimez moins de nœuds ou ajoutez d'abord de la capacité. N'utilisez pas la propriété `"force": true`.
`gcloud` CLI refuse de supprimer l'instance Bare Metal	La protection contre la suppression est activée sur l'instance.	Exécutez la commande `gcloud compute instances update HOST --no-deletion-protection` avant de supprimer l'instance.
Domaines d'erreur vSAN incorrects après l'ajout de nœuds	Vous avez créé des nœuds dans une autre stratégie d'emplacement, ou deux clusters partagent une stratégie d'emplacement.	Créez des nœuds dans la stratégie d'emplacement du cluster et répartissez-les entre les domaines de disponibilité.
Erreurs vSAN, délais d'expiration vMotion ou fragmentation de l'overlay NSX	La MTU configurée est supérieure à la MTU du réseau VPC (`8896` octets).	Les nouveaux nœuds héritent du VDS et des pools du cluster. Conservez la MTU définie sur `8896` octets pour tous les composants.
L'empreinte ou le certificat SSL de l'hôte affiche un nom interne	Le domaine de recherche DNS n'est pas défini sur l'hôte.	Exécutez la commande `esxcli network ip dns search add -d vmware.gve`, réexécutez le script `/var/lib/vmware/osdata/init.sh`, puis exécutez la commande `/sbin/generate-certificates` et redémarrez les services `rhttpproxy` et `hostd`.
Les hôtes ne peuvent pas envoyer de ping à la passerelle du sous-réseau (`.1`)	Google Cloud ne répond pas aux requêtes d'écho ICMP sur les adresses IP de la passerelle de sous-réseau.	Comportement attendu : ignorez les avertissements de ping de la passerelle.

Étapes suivantes

Ajoutez un cluster vSphere à un domaine existant dans Ajouter un cluster vSphere à un domaine.
Gérez la capacité des nœuds Bare Metal dans la console Google Cloud , dans Gérer la capacité des nœuds.
Procédez au scaling de la capacité des nœuds à l'aide de Terraform en consultant Gérer la capacité des nœuds à l'aide de Terraform.
Consultez les consignes concernant les stratégies d'emplacement dans Stratégies d'emplacement et domaines de disponibilité.
Consultez les consignes de dimensionnement et d'architecture des clusters dans À propos des clusters vSphere.
Consultez les solutions de contournement courantes pour les problèmes de déploiement et de fonctionnement dans Problèmes connus.