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 un cluster vSphere à un domaine

Ce document explique comment ajouter un cluster vSphere à un domaine VMware Cloud Foundation (VCF) 9.1 existant dans la solution VMware sur Google Cloud à l'aide d'instances Bare Metal Compute Engine. Ajoutez un cluster lorsque vous devez faire évoluer la capacité de calcul et de stockage vSAN au-delà d'un seul cluster, isoler des charges de travail ou appliquer des images vSphere Lifecycle Manager (vLCM) ou des règles de stockage vSAN distinctes dans un domaine existant. Vous pouvez ajouter le cluster à l'un des domaines suivants dans le même projet, le même réseau cloud privé virtuel (VPC) et la même zone :

Domaine de gestion : ajoute un cluster géré par le serveur vCenter et NSX Manager de gestion.
Domaine de charge de travail VI : ajoute un cluster géré par le serveur vCenter du domaine de charge de travail et son instance NSX Manager.

Résumé de l'architecture

Lorsque vous ajoutez un cluster vSphere à un domaine VCF existant, le déploiement utilise l'architecture suivante :

Hôtes ESXi bare metal : chaque nouvel hôte ESXi est une instance bare metal z3-highmem-192-highlssd-metal associée aux sous-réseaux de couche 2 existants de votre réseau VPC (gestion ESXi, vMotion, vSAN et point de terminaison de tunnel NSX (TEP)). Chaque hôte se connecte via une interface réseau principale (nic0) et des interfaces réseau dynamiques avec marquage VLAN.
Aucun dispositif de gestion supplémentaire : comme vous ajoutez le cluster au serveur vCenter et à NSX Manager qui gèrent déjà le domaine cible, vous ne déployez pas de nouveaux dispositifs de gestion. Vous ne créez pas non plus d'enregistrements Cloud DNS, de services de backend, de règles de haute disponibilité ni de règles de transfert pour la nouvelle appliance. À la place, vous ajoutez les nouveaux hôtes aux groupes de points de terminaison du réseau (NEG) zonaux existants.
Allocation et alignement des adresses IP : VCF alloue les adresses IP vMotion et vSAN à partir d'un pool de réseaux, et NSX alloue les adresses IP TEP (vmk10) à partir d'un pool d'adresses IP NSX. Comme aucun des pools n'est compatible avec l'attribution statique par hôte dans VCF 9.1, vous alignez les cartes d'interface réseau dynamiques Compute Engine sur les adresses IP allouées par VCF lors du déploiement, tout en gardant toutes les validations VCF activées.

Avant de commencer

Avant de créer le cluster, 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 domaine : le domaine cible est opérationnel (vCenter Server, vSAN, NSX Manager, SDDC Manager et VCF Operations) et ne comporte aucune tâche ayant échoué.
Image vSphere Lifecycle Manager (vLCM) : une image vLCM est disponible dans la bibliothèque d'images VCF, ou vous prévoyez d'extraire une image d'un hôte. Utilisez la même image que celle de vos clusters existants afin que tous les hôtes restent alignés.
Périphériques de stockage : chaque nouvel hôte dispose de périphériques SSD NVMe locaux sans partitions préexistantes, comme requis pour vSAN.
Nombre minimal de nœuds : un cluster nécessite au moins trois nœuds Bare Metal, ce qui correspond au minimum requis pour vSAN avec une tolérance aux pannes (FTT=1).
Type de machine : tous les nœuds du cluster utilisent le même type de machine (z3-highmem-192-highlssd-metal pour vSAN Express Storage Architecture (ESA)).
Zone : le nouveau cluster se trouve dans la même zone que les NEG zonaux de gestion et NSX TEP existants.
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).
Règlement relatif aux images de confiance et VPC Service Controls : 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 les sous-réseaux de votre réseau VPC aient la propriété Résoudre le masque de sous-réseau 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é.

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	`PROJECT_ID`	Même projet Google Cloud que le domaine cible
Région et zone	`us-east4`/`us-east4-b`	Même zone que les NEG zonaux existants
ID client	`demo`	Identifiant utilisé dans les noms de ressources existants
Domaine cible	`mgmt-domain` (ou `wld01`)	Domaine de gestion ou domaine de charge de travail VI existant
Nom du cluster	`cl02`	Nom du nouveau cluster vSphere
Type de machine	`z3-highmem-192-highlssd-metal`	Type de machine homogène pour tous les nœuds du cluster
Nombre de nœuds	`3`	Nombre minimal de nœuds pour vSAN `FTT=1`
Réseau VPC	`bm-demo`	Réseau VPC existant
Sous-réseaux (ID de VLAN)	`bm-mgmt-demo` (sans tag), `bm-vmotion-demo` (`2`), `bm-vsan-demo` (`3`), `bm-nsx-demo` (`4`)	Sous-réseaux de couche 2 existants
NEG zonaux	`bm-mgmt-demo`, `bm-nsx-tep-demo`	NEG de gestion et NSX TEP existants
Image ESXi	Famille `astra-vcf-9-1-x`, projet `smve-prod-offline-depot`	Même build d'image ESXi que les clusters existants
Domaine et zones DNS	`vmware.gve` / `dns-zone-demo`, `rev-dns-zone-demo`	Zones gérées Cloud DNS directes et inversées existantes
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

Le tableau suivant présente l'exemple de plan d'adresses IP pour les trois nouveaux hôtes ESXi :

Hôte ESXi	Adresse IP de gestion (`nic0`)	vMotion (VLAN 2)	vSAN (VLAN 3)	TEP NSX (VLAN 4)
`esxi-h7`	`192.168.0.161`	`192.168.2.21`	`192.168.3.21`	`192.168.4.21`
`esxi-h8`	`192.168.0.162`	`192.168.2.22`	`192.168.3.22`	`192.168.4.22`
`esxi-h9`	`192.168.0.163`	`192.168.2.23`	`192.168.3.23`	`192.168.4.23`

Choisir le domaine cible

Le domaine cible que vous sélectionnez détermine quel serveur vCenter, NSX Manager et zone de transport de superposition gèrent le nouveau cluster :

Paramètre ou ressource	Cluster dans le domaine de gestion	Cluster dans un domaine de charge de travail VI
Variable `TARGET_DOMAIN`	`mgmt-domain`	`wld01`
Gérer vCenter Server	`vc01.vmware.gve`	`vc02.vmware.gve`
Variable `NSX_MANAGER`	`nsx01.vmware.gve` (gestion NSX)	`nsx05.vmware.gve` (NSX dédié) ou `nsx01.vmware.gve` (NSX de gestion partagé)
Variable `TRANSPORT_ZONE`	`overlay-tz-mgmt-nsxt`	Zone de transport de superposition de l'instance NSX du domaine de charge de travail

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 interface système Jumpbox pour les utiliser dans les commandes de ce guide :

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}"
export NETWORK_POOL_NAME="${CLUSTER_NAME}-np01"
export TEP_POOL_NAME="${CLUSTER_NAME}-tep-pool"
export VDS_NAME="${CLUSTER_NAME}-vds-01"
export MACHINE_TYPE="z3-highmem-192-highlssd-metal"
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"  # Secret Manager secret holding the ESXi root password
export MTU=8896                                   # VPC MTU

# Target domain parameters
export TARGET_DOMAIN="mgmt-domain"                # Or wld01
export NSX_MANAGER="nsx01.vmware.gve"             # Or nsx05.vmware.gve for wld01 with a dedicated NSX instance
export TRANSPORT_ZONE="overlay-tz-mgmt-nsxt"      # Overlay transport zone of the target NSX instance

# Ordered host list: name mgmt_ip vmotion_ip vsan_ip tep_ip
CLUSTER_HOSTS=(
  "esxi-h7 192.168.0.161 192.168.2.21 192.168.3.21 192.168.4.21"
  "esxi-h8 192.168.0.162 192.168.2.22 192.168.3.22 192.168.4.22"
  "esxi-h9 192.168.0.163 192.168.2.23 192.168.3.23 192.168.4.23"
)

# TEP pool range matching the new hosts' Compute Engine TEP NIC IPs
export TEP_CIDR="192.168.4.0/24"
export TEP_GATEWAY="192.168.4.1"
export TEP_START="192.168.4.21"
export TEP_END="192.168.4.23"

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

Créer des enregistrements DNS

Lorsque vous avez déployé le domaine de gestion, vous avez créé les sous-réseaux de couche 2, la règle de transfert entrant Cloud DNS, ainsi que les zones gérées de transfert et de recherche inversée. L'ajout d'un cluster ne déployant pas de nouvelles appliances, il vous suffit de créer des enregistrements directs (A) et inversés (PTR) pour les nouveaux hôtes ESXi :

add_dns() {
  local name=$1 ip=$2
  gcloud dns record-sets create "${name}.${DOMAIN}." \
      --rrdatas="${ip}" --type=A --ttl=300 \
      --zone="${DNS_ZONE}" --project="${PROJECT_ID}"
  local rev
  rev=$(echo "${ip}" | awk -F. '{print $4"."$3"."$2"."$1".in-addr.arpa."}')
  gcloud dns record-sets create "${rev}" \
      --rrdatas="${name}.${DOMAIN}." --type=PTR --ttl=300 \
      --zone="${REV_DNS_ZONE}" --project="${PROJECT_ID}"
}

for entry in "${CLUSTER_HOSTS[@]}"; do
  read -r HOST MGMT_IP _ <<< "${entry}"
  add_dns "${HOST}" "${MGMT_IP}"
done

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

Créer des instances Bare Metal

Créez une stratégie d'emplacement dédiée pour le nouveau cluster. Vous créez ensuite chaque hôte ESXi bare metal avec une interface de gestion principale (nic0) et des cartes d'interface réseau dynamiques avec tag VLAN pour vMotion (VLAN 2), vSAN (VLAN 3) et NSX TEP (VLAN 4).

Créer une stratégie d'emplacement

Créez la stratégie d'emplacement de groupe :

gcloud compute resource-policies create group-placement "${PLACEMENT_POLICY}" \
    --region="${REGION}" \
    --availability-domain-count=6 \
    --collocation=COLLOCATED \
    --project="${PROJECT_ID}"

Créer des disques de démarrage et des instances ESXi Bare Metal

Créez le disque de démarrage Google Cloud Hyperdisk Balanced et l'instance ESXi bare metal pour chaque hôte du cluster :

i=0
for entry in "${CLUSTER_HOSTS[@]}"; do
  read -r HOST MGMT_IP VMOTION_IP VSAN_IP TEP_IP <<< "${entry}"
  AD=$(( (i % 6) + 1 )); i=$((i + 1))

  # 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="name~'esxi-h[7-9]'" \
    --format="table(name,status,networkInterfaces[].vlan.list(),networkInterfaces[].networkIP.list())"

Mettre à jour l'appartenance au NEG

Tous les nœuds d'une zone doivent appartenir au même NEG zonal du sous-réseau afin que les dispositifs réseau VCF puissent acheminer le trafic entre les nœuds du cluster. Ajoutez les nouveaux hôtes au NEG de gestion existant et au NEG NSX TEP :

# List the NEGs in the zone (management and NSX TEP)
gcloud compute network-endpoint-groups list --zones="${ZONE}" --project="${PROJECT_ID}" \
    --format="table(name,subnetwork.basename(),networkEndpointType,size)"

ALL_NEGS=("${MGMT_NEG}" "${TEP_NEG}")
for entry in "${CLUSTER_HOSTS[@]}"; do
  read -r HOST _ <<< "${entry}"
  for NEG in "${ALL_NEGS[@]}"; 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 "${ALL_NEGS[@]}"; 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

Pour des raisons de sécurité et de mise en service de l'hôte, réinitialisez le mot de passe root de chaque nouvel hôte sur le mot de passe ESXi root stocké dans Secret Manager. Vous utiliserez le même secret pour mettre en service les hôtes lors d'une étape ultérieure. Assurez-vous que le mot de passe répond aux exigences de complexité de VCF (au moins 15 caractères, y compris des lettres majuscules, des lettres minuscules, des chiffres et des caractères spéciaux). 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 nouvel hôte, exécutez les commandes suivantes à partir de la VM jumpbox et saisissez le mot de passe ESXi root initial lorsque vous y êtes invité :

# 1. Read the ESXi root password from Secret Manager
ESXI_ROOT_PASSWORD=$(gcloud secrets versions access latest \
    --secret="${ESXI_PASSWORD_SECRET}" --project="${PROJECT_ID}")

# 2. Reset the root password on each new host
for entry in "${CLUSTER_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

# 3. Optional: Verify that the FQDN is set and vmk0 is configured as STATIC
ssh "root@esxi-h7.${DOMAIN}" \
    'esxcli system hostname get; esxcli network ip interface ipv4 get -i vmk0'

Créer un pool de réseaux dédié

VCF alloue des adresses IP vMotion et vSAN à partir du pool de réseau que vous sélectionnez lors de la mise en service des hôtes. Étant donné que les pools de réseaux de vos clusters existants ne contiennent que leurs propres adresses IP d'hôte, créez un pool de réseaux dédié dont les plages d'adresses IP contiennent les adresses IP vMotion et vSAN exactes que vous avez pré-attribuées aux cartes d'interface réseau dynamiques Compute Engine des nouveaux hôtes. L'utilisation d'un pool de réseaux dédié permet de conserver l'allocation d'adresses IP VCF dans l'ensemble d'adresses IP Compute Engine préattribuées. Vous n'avez donc qu'à aligner l'ordre hôte-IP ultérieurement en cas de non-concordance.

Vous pouvez créer le pool de réseaux à 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), cliquez sur Create network pool (Créer un pool de réseaux), puis créez le pool de réseaux cl02-np01 avec les paramètres réseau vMotion (VLAN 2, 192.168.2.21–192.168.2.23) et vSAN (VLAN 3, 192.168.3.21–192.168.3.23) et une MTU de 8896 octets.

API SDDC Manager

Exécutez les commandes suivantes pour créer le pool de réseaux et récupérer son ID :

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

curl -s -X POST "https://${SDDC_MANAGER}/v1/network-pools" \
    -H "Authorization: Bearer ${TOKEN}" -H "Content-Type: application/json" \
    -d "{
      \"name\": \"${NETWORK_POOL_NAME}\",
      \"networks\": [
        { \"type\": \"VMOTION\", \"vlanId\": 2, \"mtu\": ${MTU},
          \"subnet\": \"192.168.2.0\", \"mask\": \"255.255.255.0\", \"gateway\": \"192.168.2.1\",
          \"ipPools\": [ { \"start\": \"192.168.2.21\", \"end\": \"192.168.2.23\" } ] },
        { \"type\": \"VSAN\", \"vlanId\": 3, \"mtu\": ${MTU},
          \"subnet\": \"192.168.3.0\", \"mask\": \"255.255.255.0\", \"gateway\": \"192.168.3.1\",
          \"ipPools\": [ { \"start\": \"192.168.3.21\", \"end\": \"192.168.3.23\" } ] }
      ]
    }"

# Retrieve the network pool ID for host commissioning
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')
echo "${POOL_ID}"

Mettre en service les hôtes

Mettez en service les nouveaux hôtes ESXi 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 noms de domaine complets de l'hôte (esxi-h7.vmware.gve, esxi-h8.vmware.gve et esxi-h9.vmware.gve) 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'ID de tâche jusqu'à ce qu'il renvoie Successful :

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

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

HOSTS_JSON=$(jq -n --argjson f "${HOST_FQDNS}" --arg p "${ESXI_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
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')

# 3. Poll task status until Successful
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), le domaine de recherche DNS n'est pas configuré sur l'hôte. Sur l'hôte ESXi concerné, 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 (/etc/init.d/rhttpproxy restart && /etc/init.d/hostd restart).

Vérifier l'alignement des adresses IP avant le déploiement

Laissez toutes les validations de connectivité réseau, vSAN et vMotion activées dans SDDC Manager. Ces vérifications ne réussissent que lorsque les adresses IP vmk1 (vMotion) et vmk2 (vSAN) que VCF attribue à chaque hôte correspondent aux adresses IP de la carte d'interface réseau dynamique Compute Engine de cet hôte. Si une incohérence se produit parce que SDDC Manager attribue des adresses IP de pool dans un ordre d'hôte différent, la tâche de création de cluster est suspendue lors de la vérification de la connectivité. Vous alignez ensuite les cartes d'interface réseau dynamiques lors d'une étape ultérieure avant de réessayer d'effectuer la tâche.

Vérifiez que la plage du pool de réseaux correspond aux adresses IP des cartes d'interface réseau vMotion et vSAN de Compute Engine : vérifiez que le pool de réseaux ne contient que les adresses IP que vous avez pré-attribuées aux cartes d'interface réseau dynamiques des nouveaux hôtes (192.168.2.21–192.168.2.23 et 192.168.3.21–192.168.3.23 dans cet exemple) :

# Inspect network pool definition
curl -s "https://${SDDC_MANAGER}/v1/network-pools/${POOL_ID}" \
    -H "Authorization: Bearer ${TOKEN}" | jq '.networks[] | {type, vlanId, mtu, ipPools}'

# Inspect Compute Engine dynamic NIC IPs per new host (VLAN 2 = vMotion, 3 = vSAN, 4 = TEP)
for entry in "${CLUSTER_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

Attribuer des adresses IP par ordre croissant de nom d'hôte : pré-attribuez les adresses IP Compute Engine par ordre croissant de nom d'hôte (esxi-h7 → .21, esxi-h8 → .22, esxi-h9 → .23) afin que l'ensemble d'adresses IP soit identique des deux côtés.
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
```
Si vous ajoutez le cluster à l'aide de l'API SDDC Manager, ne définissez pas la propriété "skipValidations": true dans le corps de la requête.
Dimensionnez le pool NSX TEP pour qu'il corresponde aux adresses IP des cartes d'interface réseau TEP Compute Engine : configurez un nouveau pool d'adresses IP NSX TEP statiques pour le cluster avec la plage 192.168.4.21–192.168.4.23 (de la variable TEP_START à la variable TEP_END), correspondant aux adresses IP des cartes d'interface réseau dynamiques du VLAN 4 des nouveaux hôtes, et définissez la passerelle sur 192.168.4.1.

Ajouter le cluster

Vous pouvez ajouter le cluster à votre domaine cible à l'aide de VCF Operations ou de l'API SDDC Manager :

Opérations VCF

Connectez-vous à VCF Operations, accédez à Inventaire, développez Instances VCF, sélectionnez le domaine cible (mgmt-domain ou wld01), puis cliquez sur Ajouter un cluster (ou, dans l'interface utilisateur de SDDC Manager, accédez à Domaines de charge de travail > domaine cible > Actions > Ajouter un cluster). Suivez les instructions de l'assistant en utilisant les paramètres suivants :

Page de l'assistant	Champ	Valeur
Stockage	Type	vSAN, Activer vSAN ESA, vSAN HCI, chiffrement des données en transit désactivé
Cluster	Nom du cluster	`cl02`
Image	Image vLCM	Sélectionnez l'image utilisée par vos clusters existants ou sélectionnez Extraire une image d'un hôte dans cette instance VCF (à l'aide de `esxi-h7`).
Hôtes	Hôtes	`esxi-h7`, `esxi-h8`, `esxi-h9` (mis en service en tant que vSAN ESA avec le pool de réseaux `cl02-np01`)
Commutateur distribué vSphere	Profil	Par défaut (VDS unique) ou personnalisé : 1 liaison montante (`uplink1` → `vmnic0`), MTU `8896`, types de trafic : gestion ESX, gestion des VM, vMotion, vSAN et NSX
Mode de commutateur NSX	Mode de fonctionnement du commutateur virtuel	Désélectionnez Appliquer le mode de commutateur virtuel par défaut configuré dans NSX Manager et définissez le Mode opérationnel sur Standard. Les hôtes de solution VMware ne sont pas compatibles avec le mode par défaut (Enhanced Datapath Standard).
Superposition d'hôte NSX	Attribution de VLAN et d'IP TEP	VLAN `4` (correspondant à la configuration NSX existante), pool d'adresses IP statiques (ne pas utiliser DHCP) : nouveau pool `cl02-tep-pool`, CIDR `192.168.4.0/24`, plage `192.168.4.21`–`192.168.4.23`, passerelle `192.168.4.1`
Récapitulatif	Envoyer	Cliquez sur Terminer. Accédez à Gestion du parc > Tâches pour surveiller la tâche et enregistrer l'ID de la tâche (`TASK_ID`).

API SDDC Manager

Récupérez l'ID du domaine cible, l'ID de la personnalité de l'image vLCM et les ID des hôtes mis en service, puis validez et envoyez la spécification pour créer le cluster :

# 1. Retrieve target domain ID, vLCM image personality ID, and host specs
DOMAIN_ID=$(curl -s "https://${SDDC_MANAGER}/v1/domains" -H "Authorization: Bearer ${TOKEN}" \
    | jq -r --arg d "${TARGET_DOMAIN}" '.elements[] | select(.name==$d) | .id')

curl -s "https://${SDDC_MANAGER}/v1/personalities" -H "Authorization: Bearer ${TOKEN}" \
    | jq -r '.elements[] | [.personalityId, .personalityName] | @tsv'
IMAGE_ID="PERSONALITY_ID"   # Select the personalityId of the existing clusters' image

HOST_SPECS=$(curl -s "https://${SDDC_MANAGER}/v1/hosts" -H "Authorization: Bearer ${TOKEN}" \
    | jq --argjson f "${HOST_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 3

# 2. Construct the cluster specification (without skipValidations)
CLUSTER_SPEC=$(jq -n \
    --arg domain "${DOMAIN_ID}" --arg name "${CLUSTER_NAME}" --arg img "${IMAGE_ID}" \
    --argjson hosts "${HOST_SPECS}" --arg vds "${VDS_NAME}" --argjson mtu "${MTU}" \
    --arg tz "${TRANSPORT_ZONE}" --arg pool "${TEP_POOL_NAME}" \
    --arg cidr "${TEP_CIDR}" --arg gw "${TEP_GATEWAY}" --arg s "${TEP_START}" --arg e "${TEP_END}" '
{
  domainId: $domain,
  computeSpec: { clusterSpecs: [{
    name: $name,
    clusterImageId: $img,
    hostSpecs: $hosts,
    datastoreSpec: { vsanDatastoreSpec: { datastoreName: ($name + "-vsan"), esaConfig: { enabled: true } } },
    networkSpec: {
      vdsSpecs: [{
        name: $vds, mtu: $mtu,
        portGroupSpecs: [
          { name: ($vds + "-pg-mgmt"),    transportType: "MANAGEMENT", activeUplinks: ["uplink1"], teamingPolicy: "loadbalance_loadbased" },
          { name: ($vds + "-pg-vmotion"), transportType: "VMOTION",    activeUplinks: ["uplink1"], teamingPolicy: "loadbalance_loadbased" },
          { name: ($vds + "-pg-vsan"),    transportType: "VSAN",       activeUplinks: ["uplink1"], teamingPolicy: "loadbalance_loadbased" }
        ],
        nsxtSwitchConfig: {
          transportZones: [ { name: $tz, transportType: "OVERLAY" } ],
          hostSwitchOperationalMode: "STANDARD"
        }
      }],
      nsxClusterSpec: { nsxTClusterSpec: {
        uplinkProfiles: [{ name: ($name + "-uplink-profile"),
          teamings: [ { policy: "LOADBALANCE_SRCID", activeUplinks: ["uplink-1"] } ],
          transportVlan: 4 }],
        ipAddressPoolsSpec: [{ name: $pool,
          subnets: [{ cidr: $cidr, gateway: $gw, ipAddressPoolRanges: [ { start: $s, end: $e } ] }] }]
      }},
      networkProfiles: [{
        name: ($name + "-network-profile"), isDefault: true,
        nsxtHostSwitchConfigs: [{
          vdsName: $vds, uplinkProfileName: ($name + "-uplink-profile"), ipAddressPoolName: $pool,
          vdsUplinkToNsxUplink: [ { vdsUplinkName: "uplink1", nsxUplinkName: "uplink-1" } ]
        }]
      }]
    }
  }]}
}')

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

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

Avant d'exécuter les commandes, remplacez PERSONALITY_ID par la valeur personalityId de l'image vLCM de votre cluster.

Si VCF attribue à un hôte une adresse IP vMotion ou vSAN différente de celle de sa carte d'interface réseau dynamique Compute Engine, la tâche s'arrête à l'étape de vérification de la connectivité vSAN et vMotion. Laissez la tâche à l'état d'échec, suivez les étapes de la section Aligner les cartes d'interface réseau dynamiques vMotion et vSAN, puis réessayez d'exécuter la tâche. N'annulez pas la tâche et ne désactivez pas la vérification de la validation.

Aligner les interfaces réseau dynamiques vMotion et vSAN

Suivez les étapes de cette section si la tâche de création de cluster s'arrête à l'étape de vérification de la connectivité vSAN et vMotion. Si la tâche réussit cette étape, n'exécutez que les étapes 1 et 2 pour confirmer l'alignement des adresses IP, puis passez à la section Aligner les cartes d'interface réseau dynamiques NSX TEP.

Lire les adresses IP allouées par VCF : interrogez le point de terminaison /v1/hosts de SDDC Manager (ou la base de données platform de SDDC Manager) pour examiner les adresses IP vMotion (vmk1) et vSAN (vmk2) que VCF a allouées à chaque hôte :

curl -s "https://${SDDC_MANAGER}/v1/hosts" -H "Authorization: Bearer ${TOKEN}" | jq -r '
  ["FQDN","STATUS","CLUSTER","MGMT_IP","VMOTION_IP","VSAN_IP"],
  (.elements | sort_by(.fqdn)[] | [
     .fqdn, (.status // "-"), (.cluster.name // .cluster.id // "-"),
     (([.ipAddresses[]? | select(.type=="MANAGEMENT") | .ipAddress] | first) // "-"),
     (([.ipAddresses[]? | select(.type=="VMOTION")    | .ipAddress] | first) // "-"),
     (([.ipAddresses[]? | select(.type=="VSAN")       | .ipAddress] | first) // "-")
  ]) | @tsv' | column -t

# Alternative (run on the SDDC Manager appliance shell):
# psql -h localhost -U postgres -d platform \
#   -c "select hostname, vmotion_ip_address, vsan_ip_address from host;"

Comparez avec les cartes d'interface réseau dynamiques Compute Engine : listez les adresses IP des cartes d'interface réseau dynamiques actuelles sur chaque nouvel hôte :

for entry in "${CLUSTER_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

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 tous les hôtes non concordants avant d'ajouter à nouveau une interface. Sinon, l'échange d'adresses IP entre deux hôtes échoue avec une erreur IP_IN_USE :

# Example: VCF assigned esxi-h7 vMotion 192.168.2.22 and vSAN 192.168.3.22
HOST="esxi-h7"
VCF_VMOTION_IP="192.168.2.22"
VCF_VSAN_IP="192.168.3.22"

# 3a. Delete mismatched NICs (run on all mismatched hosts before running 3b)
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

# 3b. Re-add the dynamic NICs with the VCF-allocated IP addresses
# vMotion (VLAN 2)
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}"

# vSAN (VLAN 3)
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éessayez la tâche de cluster ayant échoué : dans VCF Operations, accédez à Gestion de parc > Tâches pour réessayer la tâche, 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"}'
```
La tâche relancée exécute à nouveau le contrôle de connectivité pour vSAN et vMotion, et réussit une fois que toutes les cartes d'interface réseau dynamiques Compute Engine correspondent aux adresses IP attribuées par VCF.

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

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

Récupérez les adresses IP TEP allouées par NSX : interrogez le gestionnaire NSX du domaine cible (NSX_MANAGER) ou exécutez la commande esxcli network ip interface ipv4 get -i vmk10 sur chaque hôte ESXi :

NSX_PW="NSX_ADMIN_PASSWORD"

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

Avant d'exécuter les commandes, remplacez NSX_ADMIN_PASSWORD par le mot de passe admin de NSX Manager (disponible à partir du point de terminaison /v1/credentials de SDDC Manager ou de la gestion des mots de passe de VCF Operations).

Comparez avec la carte d'interface réseau TEP Compute Engine (VLAN 4) : comparez les adresses IP vmk10 attribuées par NSX aux adresses IP de la carte d'interface réseau dynamique du VLAN 4 sur les nouveaux hôtes (esxi-h7, esxi-h8 et esxi-h9). Seuls les nouveaux hôtes sont concernés. Ne modifiez pas les cartes d'interface réseau TEP des hôtes d'autres clusters.

Recréez les cartes d'interface réseau TEP non concordantes : pour tous les nouveaux hôtes non concordants, commencez par dissocier chaque hôte du NEG TEP et supprimez l'interface nic0.4 sur tous les hôtes non concordants. Vous ajoutez ensuite à nouveau l'interface nic0.4 et rattachez les hôtes au NEG TEP :

# Example: Compute Engine has 192.168.4.21 on esxi-h7, but NSX assigned 192.168.4.23
HOST="esxi-h7"
CURRENT_TEP_IP="192.168.4.21"
NSX_TEP_IP="192.168.4.23"

# 3a. Detach the host 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}"

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

# 3c. 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}"

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

Vérifier le déploiement du cluster

Une fois la tâche de création de cluster terminée et toutes les cartes d'interface réseau dynamiques alignées, vérifiez les points suivants :

vCenter Server (vc01 ou vc02) : le cluster cl02 et les trois hôtes sont connectés et opérationnels, sans aucune alarme réseau.
vSAN : pour le cluster cl02, accédez à Monitor > vSAN > Skyline Health et vérifiez que tous les contrôles d'état sont réussis et que le datastore vSAN affiche la capacité combinée des trois hôtes.
NSX Manager : accédez à Système > Structure > Hôtes et vérifiez que chaque nouvel hôte affiche Réussite et Actif, et que tous les tunnels d'overlay sont actifs.
Opérations VCF : l'état du cluster est Actif dans le domaine cible et la liste des tâches n'affiche aucune tâche ayant échoué.
Clusters existants : tous les autres clusters du domaine restent opérationnels.
Facultatif : Migrez une VM de test à l'aide de vMotion entre un cluster existant et le cluster cl02, et entre les hôtes du cluster cl02.

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

esxcli network ip interface ipv4 get                        # Verify vmk0, vmk1, vmk2, and vmk10 IPs
vmkping -S vmotion -I vmk1 -d -s 8868 192.168.2.22          # vMotion
vmkping -I vmk2 -d -s 8868 192.168.3.22                     # vSAN
vmkping ++netstack=vxlan -I vmk10 -d -s 8868 192.168.4.22   # NSX TEP

Facultatif : Configurer les défaillances vSAN à tolérer

Pour vSAN ESA, VCF crée et attribue une règle de stockage de datastore par défaut en fonction du type de cluster et du nombre d'hôtes. Pour configurer explicitement le paramètre FTT, choisissez une règle compatible avec le nombre d'hôtes de votre cluster :

É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

Pour définir la règle de stockage par défaut dans le client vSphere du serveur vCenter du domaine cible (vc01 ou vc02), procédez comme suit :

Désactivez la gestion automatique des règles pour le cluster vSAN ESA afin que vSAN n'écrase pas votre règle par défaut personnalisée.
Accédez à Policies and Profiles (Règles et profils) > VM Storage Policies (Règles de stockage des VM) > Create (Créer), activez les règles de stockage vSAN, puis dans la section Availability (Disponibilité), sélectionnez Failures to tolerate (Défaillances à tolérer) (par exemple, 1 failure - RAID-1 (Mirroring) (1 défaillance - RAID-1 (Mise en miroir)) pour 3 à 4 hôtes, ou 2 failures - RAID-6 (Erasure Coding) (2 défaillances - RAID-6 (Codage d'effacement)) pour 6 hôtes ou plus).
Définissez la nouvelle règle comme règle par défaut du datastore : sélectionnez le datastore vSAN cl02, accédez à Configurer > Général > Règle de stockage par défaut > Modifier, puis sélectionnez la nouvelle règle.
Appliquez la règle aux VM existantes (VM Policies > Edit VM Storage Policies). Accédez à Monitor > vSAN > Virtual Objects (Surveiller > vSAN > Objets virtuels) pour le cluster cl02 afin de vérifier la conformité.

Résoudre les problèmes de création de clusters

Le tableau suivant répertorie les problèmes courants, leurs causes et leurs solutions lors de l'ajout d'un cluster vSphere à un domaine :

Problème	Cause	Solution
Échec de la validation de la connectivité vSAN et vMotion ; les nouveaux hôtes sont signalés comme non opérationnels	Lorsque vous créez ou é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. Créez un pool de réseaux dédié correspondant aux adresses IP des cartes d'interface réseau Compute Engine, vérifiez l'alignement avant le déploiement et, 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 tâche.
L'état de l'hôte NSX est `Degraded` ou les tunnels sont indisponibles après l'ajout du cluster	NSX Manager attribue des adresses IP TEP (`vmk10`) à partir du pool d'adresses IP de manière aléatoire. Elles peuvent donc ne pas correspondre à la carte d'interface réseau TEP Compute Engine. Les sous-réseaux de cartes d'interface réseau dynamiques ne sont pas compatibles avec DHCP.	Utilisez un pool d'adresses IP TEP dédié correspondant aux adresses IP TEP Compute Engine et alignez les cartes d'interface réseau dynamiques TEP après la préparation de l'hôte NSX.
L'agent ou l'hôte `NSX_VDL2` signale `Degraded` alors que la BFD est active	L'adresse IP de la passerelle est manquante dans le pool d'adresses IP NSX TEP.	Configurez la passerelle de sous-réseau (`192.168.4.1`) dans le pool d'adresses IP TEP.
Erreur `IP_IN_USE` lors de l'ajout d'une carte d'interface réseau dynamique	Deux hôtes ont échangé leurs adresses IP, ou une adresse IP planifiée chevauche un autre cluster.	Supprimez d'abord toutes les cartes d'interface réseau dynamiques non concordantes sur tous les hôtes avant d'ajouter une interface, puis vérifiez que votre plan d'adresses IP ne chevauche pas les clusters existants.
Le mode de commutateur virtuel NSX n'est pas compatible	Dans VCF 9.x, le mode de commutateur virtuel NSX par défaut est Enhanced Datapath Standard, qui n'est pas compatible avec les hôtes de solution VMware.	Effacez Appliquer le mode de commutateur virtuel par défaut configuré dans NSX Manager et définissez le Mode opérationnel sur Standard (ou `"hostSwitchOperationalMode": "STANDARD"` dans la spécification de l'API). Pour en savoir plus, consultez Mode de commutateur virtuel NSX.
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.
Configuration de la synchronisation horaire (NTP)	Les hôtes Bare Metal utilisent le serveur de métadonnées Compute Engine pour la synchronisation temporelle.	Utilisez l'adresse IP du serveur de métadonnées (`169.254.169.254`) directement comme serveur NTP.
L'empreinte ou le certificat de l'hôte affiche un nom interne	Le domaine de recherche DNS n'est pas défini sur l'hôte ou le nom d'hôte se termine par un point.	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`.
Échec de la mise en service de l'hôte	L'adaptateur VMkernel `vmk0` utilise toujours DHCP, car le service de démarrage ne l'a pas converti.	Exécutez la commande `esxcli network ip interface ipv4 get -i vmk0`. Si le type est `DHCP`, définissez-le manuellement sur "static" (par exemple, sur `esxi-h7` : `esxcli network ip interface ipv4 set -i vmk0 -t static -I 192.168.0.161 -N 255.255.255.0 -g 192.168.0.1`).
Erreurs de réplication vSAN, délais d'expiration vMotion ou fragmentation de l'overlay NSX	VCF définit par défaut les adaptateurs VDS, VMkernel et les profils NSX sur une MTU de `9000` octets, et le réseau VPC supprime les trames de plus de `8896` octets.	Configurez une MTU de `8896` octets sur le VDS, le pool de réseaux (vMotion et vSAN) et le profil de liaison montante NSX. Pour en savoir plus, consultez Incohérence de MTU VDS.
L'assistant demande un ID de VLAN pour le groupe de ports d'overlay	Le profil VDS par défaut nécessite l'ID du VLAN d'overlay de l'hôte NSX.	Saisissez l'ID de VLAN TEP de votre configuration NSX existante (`4` dans ce guide).
Aucun groupe de ports n'existe pour les VM de charge de travail sur le nouveau cluster	Le profil VDS par défaut ne crée que des groupes de ports d'infrastructure.	Créez un groupe de ports distribués pour les VM de charge de travail après avoir créé le cluster, ou utilisez une configuration de commutateur personnalisée.
Impossible d'ajouter des hôtes avec l'image vLCM sélectionnée	L'image vLCM du cluster est différente de la version ESXi installée sur les hôtes.	Utilisez la même famille d'images ESXi que celle utilisée par vos clusters existants ou extrayez l'image de l'un des nouveaux hôtes.

Étapes suivantes

Étendre ou compacter un cluster existant dans Ajouter ou supprimer des nœuds dans un cluster vSphere.
Gérez la capacité des nœuds Bare Metal dans la console Google Cloud , dans Gérer la capacité des nœuds.
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.
En savoir plus sur les cartes d'interface réseau dynamiques et les instances Bare Metal