Google utiliza tecnología de IA para traducir contenido a tu idioma preferido. Las traducciones realizadas con IA pueden contener errores.

Agrega o quita nodos en un clúster de vSphere

En este documento, se describe cómo agregar uno o más nodos de Compute Engine sin sistema operativo a un clúster de vSphere existente (expansión del clúster) y quitar uno o más nodos de un clúster (compactación del clúster) en VMware Cloud Foundation (VCF) 9.1 en VMware Solution en Google Cloud. Expande o compacta un clúster cuando necesites aumentar o reducir la capacidad de procesamiento y almacenamiento de vSAN de un clúster existente en el dominio de administración o en un dominio de carga de trabajo de VI. Se aplica el mismo procedimiento ya sea que agregues o quites un solo nodo o varios: enumera uno o más nodos en la variable de entorno ADD_HOSTS o REMOVE_HOSTS.

Resumen de la arquitectura

Cuando agregas o quitas nodos en un clúster de vSphere existente, el flujo de trabajo usa la siguiente arquitectura:

Agrega nodos: Cada nodo nuevo es una instancia de Bare Metal de z3-highmem-192-highlssd-metal que implementas en la misma zona, política de posición y tipo de máquina que los nodos existentes del clúster. Cada nodo tiene una interfaz de red principal (nic0) en la subred de administración de ESXi de tu red de nube privada virtual (VPC) y las interfaces de red dinámicas con etiqueta de VLAN para vMotion, vSAN y el extremo de túnel de NSX (TEP). El nodo se une a los grupos de extremos de red (NEG) zonales existentes. Luego, encargas el nodo en SDDC Manager con el grupo de redes del clúster y lo agregas al clúster.
Quita nodos: Primero, quita el nodo del clúster en VCF, lo que migra las VMs de carga de trabajo y evacua los datos de vSAN del host. Luego, retiras el host de SDDC Manager y lo quitas de los NEG zonales antes de borrar la instancia de Bare Metal de Compute Engine subyacente.
Alineación de direcciones IP: Al igual que con la creación del clúster, VCF asigna direcciones IP de vMotion y vSAN del grupo de redes del clúster, y NSX asigna direcciones IP de TEP (vmk10) del grupo de direcciones IP de NSX. Alineas las NIC dinámicas de Compute Engine de los nodos nuevos con las direcciones IP asignadas por VCF, mientras mantienes habilitadas todas las validaciones de VCF.
No hay cambios en el dispositivo: Agregar o quitar nodos de clúster no requiere nuevos registros de Cloud DNS, servicios de backend, políticas de alta disponibilidad (HA) ni reglas de reenvío para los dispositivos de administración.

Antes de comenzar

Antes de agregar o quitar nodos, verifica los requisitos en las siguientes secciones y configura tus variables de entorno.

Verifica los requisitos del entorno

Verifica que tu entorno cumpla con los siguientes requisitos:

Permisos: Tienes los roles de Identity and Access Management (IAM) necesarios en el proyecto de destino, incluidos Administrador de Compute (roles/compute.admin), Administrador de DNS (roles/dns.admin) y Descriptor de acceso a secretos de Secret Manager (roles/secretmanager.secretAccessor).
Credenciales en Secret Manager: Si cambiaste o rotaste tus contraseñas de ESXi root, SDDC Manager, vCenter Server o NSX Manager en VCF después de la implementación inicial, Secret Manager no se actualiza automáticamente. Antes de ejecutar los comandos de este documento, actualiza los secretos correspondientes en Secret Manager o proporciona las contraseñas actualizadas directamente para que coincidan con tus credenciales de VCF activas.
Estado del clúster y del dominio: El clúster de destino y su dominio están en buen estado (vCenter Server, vSAN, NSX Manager, SDDC Manager y VCF Operations) y no tienen tareas con errores.
Para agregar nodos, haz lo siguiente:
- Tu proyecto tiene suficiente cuota de equipos físicos z3 en la región y la zona de destino.
- Los nodos nuevos usan el mismo tipo de máquina que los nodos existentes en el clúster (z3-highmem-192-highlssd-metal para vSAN Express Storage Architecture [ESA]) y se asignan a la política de ubicación existente del clúster (cada política de ubicación pertenece a un solo clúster).
- Cada nodo nuevo tiene dispositivos SSD locales NVMe sin particiones preexistentes.
- Si tu organización aplica la política de la organización constraints/compute.trustedImageProjects o usa un perímetro de servicio de Controles del servicio de VPC, asegúrate de que tu proyecto permita el acceso de imágenes al proyecto smve-prod-public-images (projects/999037279871). Para obtener más información, consulta Administra la capacidad de los nodos.
- Herramientas de redes basadas en VLAN: La solución de VMware requiere que las subredes de tu red de VPC tengan la propiedad Resolver máscara de subred configurada como Transmitir solo el rango principal con aprendizaje para admitir las herramientas de redes basadas en VLAN. Abre un ticket de asistencia en el Centro de asistencia de la consola deGoogle Cloud con la siguiente información:
  - Producto: Google Cloud VMware Engine
  - Prioridad: P2
  - Categoría: Conectividad de red
  - Impacto comercial: Pregunta técnica general
  - Proporciona más detalles: Allowlist L2 network connectivity for my project, junto con el ID del proyecto, el número del proyecto, y la región y la zona de destino para la implementación.
  Para obtener más información sobre la compatibilidad con las redes basadas en VLAN, consulta Emulación de capa 2: transmisión de ARP y aprendizaje de MAC personalizado.
Para quitar nodos, haz lo siguiente:
- Los nodos restantes tienen suficiente capacidad de procesamiento y almacenamiento de vSAN para tus cargas de trabajo activas.
- Después de quitar el nodo, el clúster conserva al menos tres nodos (el mínimo para vSAN con una falla que tolerar [FTT=1]) o el recuento mínimo de hosts que requieren tus políticas de almacenamiento activas (consulta Fallas de vSAN que tolerar y recuento de hosts).
VM de jumpbox: Tienes acceso a una VM de jumpbox con la CLI de gcloud, curl y jq instaladas, y con conectividad de red a la red de VPC (por ejemplo, en la subred bm-gcp-demo).

Revisa los parámetros de entorno de ejemplo

Los comandos de este documento usan los siguientes parámetros de ejemplo:

Parámetro de datos	Valor de ejemplo	Descripción
ID del proyecto, región y zona	`PROJECT_ID` / `us-east4` / `us-east4-b`	Mismo proyecto, región y zona que el clúster de destino
ID de cliente	`demo`	Identificador que se usa en los nombres de recursos existentes
Clúster de destino	`cl02` (`esxi-h7`, `esxi-h8`, `esxi-h9`)	Clúster existente en el dominio de administración o en un dominio de carga de trabajo de VI
Política de posición	`bm-cl02`	Política de posición de grupo existente del clúster
Grupo de redes y VDS	`cl02-np01`/`cl02-vds-01`	Grupo de redes existente y vSphere Distributed Switch (VDS) del clúster
Grupo de IP de TEP de NSX	`cl02-tep-pool`	Grupo de direcciones IP de NSX existente del clúster
NSX Manager	`nsx01.vmware.gve`	NSX Manager del dominio del clúster (o `nsx05.vmware.gve` para el dominio de carga de trabajo `wld01` con una instancia de NSX dedicada)
Tipo de máquina	`z3-highmem-192-highlssd-metal`	El mismo tipo de máquina que los nodos existentes en el clúster
Red de VPC y subredes (ID de VLAN)	`bm-demo`; `bm-mgmt-demo` (sin etiquetar), `bm-vmotion-demo` (`2`), `bm-vsan-demo` (`3`), `bm-nsx-demo` (`4`)	Red de VPC y subredes de capa 2 existentes
NEG zonales	`bm-mgmt-demo`, `bm-nsx-tep-demo`	NEG de administración y TEP de NSX existentes
SDDC Manager	`sddcm.vmware.gve` (`192.168.0.3`)	Dispositivo de SDDC Manager existente
Contraseña de ESXi de `root`	`esxi-root-password`	Secreto de Secret Manager existente que contiene la contraseña de ESXi `root`

Planifica las direcciones IP y los nombres de host

En el siguiente ejemplo, se agregan dos nodos (esxi-h10 y esxi-h11) al clúster cl02 y, luego, se quita uno de ellos (esxi-h11). Para agregar o quitar un solo nodo, incluye solo ese nodo en el array de variable de entorno:

Host de ESXi	IP de administración (`nic0`)	vMotion (VLAN 2)	vSAN (VLAN 3)	NSX TEP (VLAN 4)	Dominio de disponibilidad	Acción
`esxi-h10`	`192.168.0.164`	`192.168.2.24`	`192.168.3.24`	`192.168.4.24`	`4`	Agregar
`esxi-h11`	`192.168.0.165`	`192.168.2.25`	`192.168.3.25`	`192.168.4.25`	`5`	Agrega y, luego, quita

Distribuye los nodos del clúster en los dominios de disponibilidad dentro de la política de posición del clúster: debido a que los nodos existentes (del esxi-h7 al esxi-h9) usan los dominios de disponibilidad del 1 al 3, los nodos nuevos usan los dominios de disponibilidad 4 y 5.

Verifica la cuota regional

Antes de aprovisionar nodos de equipos físicos o crear un clúster, verifica que tu proyecto tenga suficiente cuota regional y global de Compute Engine. Agrega los recursos de todos los clústeres existentes en la región a los siguientes valores incrementales antes de compararlos con la cuota de tu proyecto:

Métrica de cuota	Recursos necesarios por nodo de Bare Metal	Recursos necesarios para un clúster de 3 nodos
`compute.googleapis.com/cpus_per_vm_family` para `Z3`	192 CPUs virtuales	3 × 192 = 576 CPUs virtuales
`compute.googleapis.com/local_ssd_total_storage_per_vm_family` para `Z3`	72 TB	3 × 72 TB = 216 TB
`compute.googleapis.com/hyperdisk_balanced_total_storage`	128 GB	3 × 128 GB = 384 GB
`compute.googleapis.com/resource_policies`	0 cuando se agregan nodos a un clúster existente	1 política de posición distribuida por clúster
`compute.googleapis.com/regional_backend_services_protocol_forwarding_fast_ha`	0 cuando se agregan nodos o clústeres sin dispositivos nuevos	1 por cada nueva VIP del dispositivo de administración de VCF o extremo de NSX Edge

Para obtener la lista completa de las cuotas requeridas y las instrucciones para ver o solicitar aumentos de cuota, consulta Cuotas y límites.

Configura las variables de entorno

Establece las siguientes variables de entorno en la shell de tu jumpbox. Enumera los nodos que se agregarán en la variable de entorno ADD_HOSTS y los nodos que se quitarán en la variable de entorno REMOVE_HOSTS (una o más entradas cada una):

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

Antes de ejecutar los comandos, reemplaza lo siguiente:

PROJECT_ID: Es el ID de tu proyecto de Google Cloud de destino.
VCF_ADMIN_PASSWORD: Es la contraseña de administrador de SDDC Manager.

Confirma que ninguna de las direcciones IP que planeas usar ya esté en uso por reglas de reenvío o instancias existentes:

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

Agrega nodos a un clúster

Para expandir un clúster de vSphere existente agregando nodos de equipos físicos, completa los pasos que se indican en las siguientes secciones.

Crea registros DNS

Debido a que las zonas administradas de reenvío y reversa de Cloud DNS ya existen, crea registros de reenvío (A) y reversa (PTR) solo para los nodos nuevos:

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

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

Crea instancias de equipos físicos

Crea cada nodo nuevo en la política de ubicación existente del clúster con la NIC de administración de ESXi principal (nic0) y las NIC dinámicas con etiquetado de VLAN para vMotion (VLAN 2), vSAN (VLAN 3) y 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())"

Actualiza la membresía del NEG

Todos los nodos de un clúster en una zona deben pertenecer al mismo NEG zonal de la subred. Agrega los nodos nuevos al NEG de administración y al NEG de TEP de NSX. No necesitas modificar las políticas de alta disponibilidad ni las reglas de reenvío:

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

Restablece la contraseña raíz de ESXi

Restablece la contraseña de root de cada nodo nuevo para que coincida con la contraseña de root de ESXi almacenada en Secret Manager. Usarás el mismo Secret para poner en servicio los nodos en un paso posterior. Si cambiaste o rotaste tus contraseñas de ESXi root o VCF después de la implementación inicial, actualiza el Secret correspondiente en Secret Manager antes de ejecutar estos comandos.

Para restablecer la contraseña de root en cada nodo nuevo, ejecuta los siguientes comandos desde la VM de jumpbox y, cuando se te solicite, ingresa la contraseña inicial de root de ESXi:

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

Agrega las direcciones IP nuevas al grupo de redes y al grupo de TEP

El grupo de red del clúster (cl02-np01) y el grupo de TEP de NSX (cl02-tep-pool) inicialmente solo contienen las direcciones IP de los nodos del clúster existentes. Agrega las direcciones IP exactas de la NIC dinámica de Compute Engine de los nodos nuevos a ambos grupos para que VCF y NSX asignen direcciones IP del conjunto que ya está configurado en las NIC de Compute Engine.

Actualiza el grupo de redes (vMotion y vSAN): Agrega las direcciones IP de vMotion y vSAN de los nodos nuevos al grupo de redes cl02-np01 con VCF Operations o la API de SDDC Manager:

VCF Operations

En Operaciones de VCF, ve a Administración de grupos de redes, selecciona el grupo de redes cl02-np01, edita las redes de vMotion y vSAN, y agrega los rangos de direcciones IP para los nodos nuevos.

API de SDDC Manager

Ejecuta los siguientes comandos para agregar un rango de IP única por nodo nuevo al grupo de redes:

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'

Actualiza el grupo de IP de TEP de NSX: En NSX Manager (el host NSX_MANAGER), ve a Herramientas de redes > Grupos de direcciones IP, edita el grupo de direcciones IP cl02-tep-pool y agrega las direcciones IP de TEP de los nodos nuevos a los rangos de IP de la subred (192.168.4.24–192.168.4.25 en este ejemplo) mientras mantienes la puerta de enlace configurada en 192.168.4.1. Verifica la configuración actualizada del grupo:
```
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}'
```
Antes de ejecutar los comandos, reemplaza lo siguiente:
- NSX_ADMIN_PASSWORD: Es la contraseña de admin de NSX Manager (disponible en el extremo /v1/credentials de SDDC Manager o en VCF Operations).
- TEP_POOL_ID: Es el ID del grupo de direcciones IP cl02-tep-pool.
Nota: Si el grupo de TEP no tiene direcciones IP libres, NSX no puede preparar los nodos nuevos. Si los grupos contienen otras direcciones IP libres (por ejemplo, direcciones IP que se liberaron por nodos quitados con anterioridad), VCF o NSX podrían asignar esas direcciones IP en lugar de las direcciones IP de NIC de Compute Engine de los nodos nuevos. Si eso sucede, alinea las NIC en Alinea las NIC dinámicas de vMotion y vSAN y Alinea las NIC dinámicas de NSX TEP.

Pon en marcha los nodos

Pon en servicio los nodos nuevos en el inventario de SDDC Manager con VCF Operations o la API de SDDC Manager:

VCF Operations

En VCF Operations, ve a Inventory > Hosts > Commission Hosts.
Selecciona el grupo de redes cl02-np01 y el tipo de almacenamiento vSAN ESA.
Ingresa los FQDN del host nuevo y las credenciales de root.
Acepta las huellas digitales SSL, valida los hosts y haz clic en Commission.

API de SDDC Manager

Ejecuta los siguientes comandos para validar y poner en servicio los hosts y, luego, sondea el estado de la tarea hasta que devuelva 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 una huella digital SSL del host muestra un nombre de certificado interno (que no es FQDN), ejecuta el comando esxcli network ip dns search add -d vmware.gve en el host, vuelve a ejecutar la secuencia de comandos /var/lib/vmware/osdata/init.sh y, luego, ejecuta el comando /sbin/generate-certificates y reinicia los servicios rhttpproxy y hostd.

Verifica la alineación de IP previa a la expansión

Mantén habilitadas todas las validaciones de vSAN, vMotion y conectividad de red en SDDC Manager. Estas verificaciones de validación se aprueban solo cuando las direcciones IP vmk1 y vmk2 que VCF asigna a cada nodo nuevo coinciden con sus direcciones IP de NIC dinámica de Compute Engine.

Verifica que las direcciones IP del grupo sin usar coincidan con las nuevas direcciones IP de la NIC de Compute Engine: compara los rangos de grupos de red con las direcciones IP que ya usan los hosts existentes y las NIC de Compute Engine de los nodos nuevos. Las únicas direcciones IP del grupo que no usan los hosts existentes deben ser las direcciones IP de los nodos nuevos:

# 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

Confirma que SDDC Manager no omita las validaciones: En el dispositivo de SDDC Manager (como root), verifica que el archivo application.properties no contenga ninguna propiedad 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

Expande el clúster

Agrega los nodos encargados al clúster de destino con VCF Operations o la API de SDDC Manager:

VCF Operations

En Operaciones de VCF (o la IU de SDDC Manager), abre el dominio del clúster, selecciona el clúster cl02, elige Acciones > Agregar host, selecciona los nodos asignados, asigna la interfaz vmnic0 al vínculo superior uplink1 del VDS del clúster y envía el flujo de trabajo. Ve a Administración de flotas > Tareas para supervisar la tarea y registrar su ID (establece la variable TASK_ID en este valor para la siguiente sección).

API de SDDC Manager

Ejecuta los siguientes comandos para validar la especificación de expansión y expandir el clúster:

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'

Cuando expandes un clúster, SDDC Manager asigna direcciones IP de vMotion y vSAN desde el grupo de redes sin conservar el orden de los hosts. Si SDDC Manager asigna a un nodo nuevo una dirección IP que difiere de su NIC dinámica de Compute Engine, la tarea se detiene en el paso de verificación de la conectividad de vSAN y vMotion. Deja la tarea en el estado con errores, completa los pasos en Alinea las NIC dinámicas de vMotion y vSAN y, luego, vuelve a intentar la misma tarea. No inicies una nueva solicitud de expansión para estos nodos: después de una expansión con errores, los nodos ya no están en el estado sin asignar y SDDC Manager rechaza una nueva solicitud de expansión.

Alinea las NIC dinámicas de vMotion y vSAN

Completa los pasos de esta sección si la tarea de expansión del clúster se detiene en el paso de verificación de la conectividad de vSAN y vMotion. Si la tarea pasa ese paso, ejecuta solo el paso 1 para confirmar la alineación y, luego, continúa con Alinea las NIC dinámicas de NSX TEP.

Lee las direcciones IP asignadas por VCF y compáralas con las NIC de Compute Engine: Ejecuta los dos comandos del paso 1 de Verifica la alineación de IP previa a la expansión. Solo los nodos nuevos están dentro del alcance.

Primero, borra todas las NIC dinámicas que no coincidan y, luego, vuelve a agregarlas: Borra todas las NIC dinámicas que no coincidan (la interfaz nic0.2 para vMotion y la interfaz nic0.3 para vSAN) en cada nodo nuevo antes de volver a agregar cualquier interfaz; de lo contrario, las direcciones IP intercambiadas fallarán con un error 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}"

Reintenta la tarea con errores: En VCF Operations, ve a Administración de flotas.

Tareas para reintentar la tarea de expansión o ejecuta el siguiente comando de la API de SDDC Manager:
```
curl -s -X PATCH "https://${SDDC_MANAGER}/v1/tasks/${TASK_ID}" \
    -H "Authorization: Bearer ${TOKEN}" -H "Content-Type: application/json" \
    -d '{"status": "RETRY"}'
```
Si la tarea vuelve a fallar, repite los pasos 1 y 2 antes de volver a intentarlo.

Alinea las NIC dinámicas de TEP de NSX

Después de que NSX configure los nodos nuevos como nodos de transporte, verifica y alinea las NIC dinámicas de la VLAN 4 NSX TEP (vmk10) en los nodos nuevos.

Recupera las direcciones IP de TEP asignadas por NSX: Consulta NSX Manager (o ejecuta el comando esxcli network ip interface ipv4 get -i vmk10 en cada host ESXi):

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

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

Vuelve a crear las NIC de TEP que no coinciden: Compara las direcciones IP de vmk10 asignadas por NSX con la NIC de TEP de Compute Engine (VLAN 4) de cada nodo nuevo. Solo los nodos nuevos están dentro del alcance; no modifiques las NIC de TEP de los nodos existentes. Para todos los nodos nuevos que no coincidan, primero desconecta cada nodo del NEG de TEP y borra la interfaz nic0.4 en todos los nodos que no coincidan. Luego, vuelve a agregar la interfaz nic0.4 y a conectar los nodos al NEG de TEP:

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

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

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

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

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

Verifica la expansión del clúster

Después de que la tarea de expansión del clúster se complete correctamente, verifica lo siguiente:

Servidor de vCenter: Los nodos nuevos están conectados y en buen estado en el clúster de cl02 sin alarmas de red.
vSAN: Para el clúster cl02, ve a Supervisar > vSAN > Skyline Health y confirma que se aprueben todas las verificaciones de estado y que la capacidad del almacén de datos incluya los nodos nuevos.
NSX Manager: Ve a Sistema > Tejido > Hosts y confirma que cada nodo nuevo muestre Correcto y Activo, y que los túneles de superposición estén activos.
Operaciones de VCF: Los nodos nuevos se asignan al clúster cl02 y la lista de tareas no tiene tareas con errores.

Desde una shell de host de ESXi (por ejemplo, esxi-h10), verifica la conectividad de marcos jumbo (MTU de 8896 menos el encabezado de IP/ICMP de 28 bytes = 8868 bytes):

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

Cantidad de hosts y fallas de vSAN que se toleran

Usa la siguiente tabla para determinar cuántos nodos requiere tu clúster cuando agregas nodos o cuántos debes conservar cuando quitas nodos:

Fallas que se toleran	Esquema de ubicación de datos	Cantidad mínima de hosts
`FTT=1`	RAID-1 (duplicación) o RAID-5 (programación de borrado)	3 (se recomiendan 4 o más para volver a compilar después de una falla del host o durante el mantenimiento)
`FTT=2`	RAID-1 (duplicación)	5
`FTT=2`	RAID-6 (codificación de borrado)	6

Quita nodos de un clúster

Completa las verificaciones previas a la eliminación

Antes de quitar cualquier nodo de un clúster, verifica lo siguiente:

Recuento de hosts: Después de quitar el nodo, el clúster conserva al menos tres nodos y, como mínimo, el recuento de hosts que se indica en Fallas de vSAN que se deben tolerar y recuento de hosts que requieren tus políticas de almacenamiento activas.
Capacidad: En vCenter Server, para el clúster cl02, ve a Supervisar > vSAN > Verificación previa de la migración de datos para cada nodo que planeas quitar (con la opción Migración de datos completa) y confirma que los nodos restantes tengan suficiente capacidad de procesamiento y vSAN.
Estado: vSAN Skyline Health se aprueba sin errores y no hay tareas con errores en VCF Operations ni en SDDC Manager.

Líderes de la política de HA: Confirma que ningún servicio de backend use un nodo que estés quitando como líder de la política de HA. Si un servicio de backend usa uno de esos nodos como líder, actualiza el líder a un nodo restante (el host que ejecuta la VM del dispositivo después de la migración):

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

Quita los nodos del clúster

Quita los nodos de destino del clúster en VCF. VCF coloca cada nodo en modo de mantenimiento, migra sus VMs y evacua sus datos de vSAN. Puedes quitar los nodos con VCF Operations o la API de SDDC Manager:

VCF Operations

En VCF Operations (o la IU de SDDC Manager), abre el dominio del clúster, selecciona el clúster cl02, elige Acciones > Quitar host, selecciona los nodos que deseas quitar y confirma.

API de SDDC Manager

Ejecuta los siguientes comandos para validar la especificación de compactación y quitar los hosts del clúster:

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'

Retira los nodos

Después de quitar los nodos del clúster, retíralos del inventario de SDDC Manager con VCF Operations o la API de SDDC Manager:

VCF Operations

En VCF Operations, ve a Inventario > Hosts, selecciona los nodos sin asignar y haz clic en Retirar (para obtener más información, consulta Retira hosts en la documentación de VMware Cloud Foundation).

API de SDDC Manager

Ejecuta los siguientes comandos para enviar una solicitud de baja y sondear la tarea hasta que devuelva 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'

Quita los nodos de los NEG

Quita los nodos retirados del NEG de administración y del NEG de TEP de NSX:

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 de gcloud rechaza la eliminación del NEG de TEP sin una dirección IP explícita, incluye la dirección IP del extremo (como se muestra en el comando de verificación) en la marca --remove-endpoint: --remove-endpoint="instance=HOST,ip=TEP_IP".

Borra las instancias de equipos físicos

Borra la protección contra eliminaciones en cada host retirado y borra la instancia de Compute Engine de equipos físicos (Compute Engine borra automáticamente el disco de arranque con la instancia):

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

Limpia los registros DNS y los grupos de IP

Borra los registros DNS de Cloud DNS de reenvío (A) y reversos (PTR) de los nodos quitados:

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

Las direcciones IP de vMotion, vSAN y TEP de los nodos quitados vuelven a estar disponibles en el grupo de redes y en el grupo de TEP de NSX. Puedes conservar esas direcciones IP para un nodo futuro (asignando a ese nodo futuro las mismas direcciones IP de NIC de Compute Engine) o quitarlas de los grupos para que VCF y NSX no las asignen a un nodo futuro cuyas NIC de Compute Engine usen direcciones IP diferentes.

Verifica la eliminación del nodo

Después de completar el flujo de trabajo de eliminación de nodos, verifica lo siguiente:

vCenter Server: El clúster de cl02 muestra solo los nodos restantes, todos conectados y en buen estado, y vSphere HA y DRS no informan errores.
vSAN: Las verificaciones de Skyline Health se aprueban y todos los objetos virtuales cumplen con los requisitos (para el clúster cl02, ve a Supervisar > vSAN > Objetos virtuales).
NSX Manager: Los nodos quitados ya no aparecen como nodos de transporte, y los nodos restantes muestran Activo.
VCF Operations y SDDC Manager: Los nodos quitados ya no están en el inventario de hosts y no hay tareas con errores.
Google Cloud: Se borran las instancias de equipos físicos, los discos de arranque, los extremos de NEG y los registros DNS de los nodos quitados.

Soluciona problemas de expansión de clústeres y eliminación de nodos

En la siguiente tabla, se enumeran los problemas, las causas y las soluciones comunes cuando se agregan o quitan nodos en un clúster de vSphere:

Problema	Causa	Solución
La expansión del clúster falla en la verificación de conectividad para vSAN y vMotion; los nodos nuevos informan un estado incorrecto	Cuando expandes un clúster, SDDC Manager asigna direcciones IP de `vmk1` y `vmk2` del grupo de red sin conservar el orden de los hosts.	Mantén habilitadas las validaciones. Agrega solo las direcciones IP de los nodos nuevos al grupo de red. Si la tarea se detiene en la verificación de conectividad, alinea las NIC dinámicas y vuelve a intentar la misma tarea.
El estado del host de NSX es `Degraded` o los túneles están inactivos en los nodos nuevos	NSX Manager asigna direcciones IP de TEP (`vmk10`) del grupo de IP de forma aleatoria, por lo que es posible que no coincidan con la NIC de TEP de Compute Engine.	Alinea las NIC dinámicas de NSX TEP como se describe en Alinea las NIC dinámicas de NSX TEP.
NSX no puede preparar los nodos nuevos	El grupo de IP de TEP de NSX del clúster no tiene direcciones IP libres.	Agrega las direcciones IP de TEP de los nodos nuevos al grupo de IP de TEP y, luego, vuelve a intentar la tarea.
SDDC Manager rechaza una nueva solicitud de expansión para los mismos nodos	Una tarea de expansión con errores deja los nodos fuera del estado `UNASSIGNED_USEABLE`.	Vuelve a intentar la tarea con errores (`PATCH /v1/tasks/TASK_ID` con `{"status": "RETRY"}`) en lugar de enviar una nueva solicitud de expansión.
La puesta en marcha de un nodo falla porque el nodo ya está en marcha	No puedes encargar un host dos veces.	Continúa con la expansión del clúster o, primero, retira el nodo si debes volver a ponerlo en servicio (por ejemplo, con un grupo de red diferente).
Error `IP_IN_USE` cuando se vuelve a agregar una NIC dinámica	Dos nodos intercambiaron direcciones IP o una dirección IP planificada se superpone con otro nodo.	Primero, borra todas las NIC dinámicas que no coincidan en todos los nodos nuevos antes de volver a agregar cualquier interfaz y verifica tu plan de direcciones IP.
No se puede validar la eliminación de nodos	La eliminación de los nodos reduce el clúster a menos hosts que su tamaño mínimo, o los nodos restantes no tienen capacidad suficiente.	Quita menos nodos o agrega capacidad primero; no uses la propiedad `"force": true`.
La CLI de `gcloud` se niega a borrar la instancia de equipos físicos	La protección contra eliminaciones está habilitada en la instancia.	Ejecuta el comando `gcloud compute instances update HOST --no-deletion-protection` antes de borrar la instancia.
Dominios de fallas de vSAN incorrectos después de agregar nodos	Creaste nodos nuevos en una política de posición diferente o dos clústeres comparten una política de posición.	Crea nodos nuevos en la política de posición del clúster y distribúyelos en los dominios de disponibilidad.
Errores de vSAN, tiempos de espera de vMotion o fragmentación de superposición de NSX	La MTU configurada es mayor que la MTU de la red de VPC (`8896` bytes).	Los nodos nuevos heredan el VDS y los grupos del clúster. Mantén la MTU configurada en `8896` bytes en todos los componentes.
La huella digital o el certificado SSL del host muestran un nombre interno	El dominio de búsqueda de DNS no está configurado en el host.	Ejecuta el comando `esxcli network ip dns search add -d vmware.gve`, vuelve a ejecutar la secuencia de comandos `/var/lib/vmware/osdata/init.sh` y, luego, ejecuta el comando `/sbin/generate-certificates` y reinicia los servicios `rhttpproxy` y `hostd`.
Los hosts no pueden hacer ping a la puerta de enlace de la subred (`.1`)	Google Cloud no responde a las solicitudes de eco de ICMP en las direcciones IP de la puerta de enlace de la subred.	Comportamiento esperado; ignora las advertencias de ping de la puerta de enlace.

¿Qué sigue?

Agrega un clúster de vSphere nuevo a un dominio existente en Agrega un clúster de vSphere a un dominio.
Administra la capacidad de los nodos de equipos físicos en la consola de Google Cloud en Administra la capacidad de los nodos.
Escala la capacidad de los nodos con Terraform en Administra la capacidad de los nodos con Terraform.
Revisa los lineamientos de las políticas de posición en Políticas de posición y dominios de disponibilidad.
Revisa los lineamientos de tamaño y arquitectura del clúster en Acerca de los clústeres de vSphere.
Revisa las soluciones alternativas operativas y de implementación comunes en Problemas conocidos.