O Google usa tecnologia de IA na tradução de conteúdos para seu idioma de preferência. As traduções com IA podem ter erros.

Adicionar ou remover nós em um cluster do vSphere

Neste documento, descrevemos como adicionar um ou mais nós bare metal do Compute Engine a um cluster do vSphere (expansão de cluster) e remover um ou mais nós de um cluster (compactação de cluster) no VMware Cloud Foundation (VCF) 9.1 na solução VMware no Google Cloud. Expanda ou compacte um cluster quando precisar aumentar ou reduzir a capacidade de computação e armazenamento do vSAN de um cluster atual no domínio de gerenciamento ou em um domínio de carga de trabalho de VI. O mesmo procedimento se aplica se você adicionar ou remover um ou vários nós: liste um ou mais nós na variável de ambiente ADD_HOSTS ou REMOVE_HOSTS.

Resumo da arquitetura

Quando você adiciona ou remove nós em um cluster do vSphere, o fluxo de trabalho usa a seguinte arquitetura:

Adicionar nós: cada novo nó é uma instância bare metal z3-highmem-192-highlssd-metal que você implanta na mesma zona, política de posicionamento e tipo de máquina que os nós atuais do cluster. Cada nó tem uma interface de rede principal (nic0) na sub-rede de gerenciamento do ESXi da sua rede de nuvem privada virtual (VPC) e Interfaces de rede dinâmicas com inclusão de tag VLAN para vMotion, vSAN e NSX Tunnel Endpoint (TEP). O nó se junta aos grupos de endpoints de rede (NEGs) zonais atuais. Em seguida, comissione o nó no SDDC Manager com o pool de rede do cluster e adicione-o ao cluster.
Remover nós: primeiro, remova o nó do cluster no VCF, o que migra as VMs de carga de trabalho e evacua os dados da vSAN do host. Em seguida, desative o host do SDDC Manager e remova-o dos NEGs zonais antes de excluir a instância bare metal do Compute Engine.
Alinhamento de endereços IP: assim como na criação de clusters, o VCF aloca endereços IP do vMotion e do vSAN do pool de rede do cluster, e o NSX aloca endereços IP do TEP (vmk10) do pool de endereços IP do NSX. Alinhe as NICs dinâmicas do Compute Engine dos novos nós com os endereços IP alocados pelo VCF, mantendo todas as validações do VCF ativadas.
Sem mudanças no appliance: adicionar ou remover nós de cluster não exige novos registros DNS do Cloud DNS, serviços de back-end, políticas de alta disponibilidade (HA) ou regras de encaminhamento para appliances de gerenciamento.

Antes de começar

Antes de adicionar ou remover nós, verifique os requisitos nas seções a seguir e configure as variáveis de ambiente.

Verificar os requisitos do ambiente

Verifique se o ambiente atende aos seguintes requisitos:

Permissões: você tem os papéis necessários do Identity and Access Management (IAM) no projeto de destino, incluindo Administrador do Compute (roles/compute.admin), Administrador de DNS (roles/dns.admin) e Acessador de secrets do Secret Manager (roles/secretmanager.secretAccessor).
Credenciais no Secret Manager: se você alterou ou alternou as senhas do ESXi root, do SDDC Manager, do vCenter Server ou do NSX Manager no VCF após a implantação inicial, o Secret Manager não será atualizado automaticamente. Antes de executar os comandos neste documento, atualize os secrets correspondentes no Secret Manager ou forneça as senhas atualizadas diretamente para que correspondam às suas credenciais ativas do VCF.
Integridade do cluster e do domínio: o cluster de destino e o domínio dele estão íntegros (vCenter Server, vSAN, NSX Manager, SDDC Manager e VCF Operations) e não têm tarefas com falha.
Para adicionar nós:
- Seu projeto tem cota de bare metal z3 suficiente na região e na zona de destino.
- Os novos nós usam o mesmo tipo de máquina que os nós atuais no cluster (z3-highmem-192-highlssd-metal para a arquitetura de armazenamento expresso (ESA, na sigla em inglês) do vSAN) e são atribuídos à política de posicionamento atual do cluster (cada política de posicionamento pertence a apenas um cluster).
- Cada novo nó tem dispositivos SSD locais NVMe sem partições pré-existentes.
- Se a organização aplicar a política da organização constraints/compute.trustedImageProjects ou usar um perímetro de serviço do VPC Service Controls, verifique se o projeto permite o acesso de imagens ao projeto smve-prod-public-images (projects/999037279871). Para mais informações, consulte Gerenciar a capacidade do nó.
- Rede baseada em VLAN: a solução VMware exige que as sub-redes da sua rede VPC tenham a propriedade Resolver máscara de sub-rede definida como Transmitir intervalo principal apenas com aprendizado para oferecer suporte à rede baseada em VLAN. Abra um tíquete de suporte na Central de suporte do console doGoogle Cloud com as seguintes informações:
  - Produto: Google Cloud VMware Engine
  - Prioridade: P2
  - Categoria: conectividade de rede
  - Impacto nos negócios: pergunta técnica geral
  - Forneça mais detalhes: Allowlist L2 network connectivity for my project, além do ID do projeto, do número do projeto e da região e zona de destino da implantação.
  Para mais informações sobre o suporte a redes baseadas em VLAN, consulte Emulação de camada 2: transmissão ARP e aprendizado de MAC personalizado.
Para remover nós:
- Os nós restantes têm capacidade de computação e armazenamento vSAN suficiente para as cargas de trabalho ativas.
- Após a remoção do nó, o cluster mantém pelo menos três nós (o mínimo para vSAN com uma falha a tolerar (FTT=1)) ou o número mínimo de hosts exigido pelos requisitos da política de armazenamento ativa (consulte Falhas a tolerar e número de hosts do vSAN).
VM jumpbox: você tem acesso a uma VM jumpbox com a CLI gcloud, curl e jq instaladas e com conectividade de rede com a rede VPC (por exemplo, na sub-rede bm-gcp-demo).

Analisar exemplos de parâmetros de ambiente

Os comandos neste documento usam os seguintes parâmetros de exemplo:

Parâmetro de entrada	Valor de exemplo	Descrição
ID do projeto, região e zona	`PROJECT_ID` / `us-east4` / `us-east4-b`	Mesmo projeto, região e zona do cluster de destino
ID de cliente	`demo`	Identificador usado em nomes de recursos atuais
Cluster de destino	`cl02` (`esxi-h7`, `esxi-h8`, `esxi-h9`)	Cluster atual no domínio de gerenciamento ou em um domínio de carga de trabalho de VI
Política de posicionamento	`bm-cl02`	Política de posição em grupo atual do cluster
Pool de rede e VDS	`cl02-np01` / `cl02-vds-01`	Pool de rede e vSphere Distributed Switch (VDS) do cluster
Pool de IPs do TEP do NSX	`cl02-tep-pool`	Pool de endereços IP do NSX atual do cluster
NSX Manager	`nsx01.vmware.gve`	NSX Manager do domínio do cluster (ou `nsx05.vmware.gve` para o domínio de carga de trabalho `wld01` com uma instância dedicada do NSX)
Tipo de máquina	`z3-highmem-192-highlssd-metal`	O mesmo tipo de máquina dos nós atuais no cluster
Rede VPC e sub-redes (ID da VLAN)	`bm-demo`; `bm-mgmt-demo` (sem tag), `bm-vmotion-demo` (`2`), `bm-vsan-demo` (`3`), `bm-nsx-demo` (`4`)	Rede VPC e sub-redes de camada 2 atuais
NEGs por zona	`bm-mgmt-demo`, `bm-nsx-tep-demo`	NEGs de gerenciamento e TEP do NSX atuais
Gerenciador do SDDC	`sddcm.vmware.gve` (`192.168.0.3`)	Dispositivo do SDDC Manager atual
Senha de acesso root do ESXi `root`	`esxi-root-password`	Secret do Secret Manager que contém a senha do ESXi `root`

Planejar endereços IP e nomes de host

O exemplo a seguir adiciona dois nós (esxi-h10 e esxi-h11) ao cluster cl02 e, em seguida, remove um deles (esxi-h11). Para adicionar ou remover um único nó, inclua apenas esse nó na matriz de variável de ambiente:

Host ESXi	IP de gerenciamento (`nic0`)	vMotion (VLAN 2)	vSAN (VLAN 3)	TEP do NSX (VLAN 4)	Domínio de disponibilidade	Ação
`esxi-h10`	`192.168.0.164`	`192.168.2.24`	`192.168.3.24`	`192.168.4.24`	`4`	Adicionar
`esxi-h11`	`192.168.0.165`	`192.168.2.25`	`192.168.3.25`	`192.168.4.25`	`5`	Adicionar e remover

Distribua os nós do cluster entre os domínios de disponibilidade na política de posicionamento do cluster: como os nós atuais (esxi-h7 a esxi-h9) usam os domínios de disponibilidade 1 a 3, os novos nós usam os domínios de disponibilidade 4 e 5.

Verificar cota regional

Antes de provisionar nós bare metal ou criar um cluster, verifique se o projeto tem cota regional e global suficiente do Compute Engine. Adicione os recursos de todos os clusters atuais na região aos seguintes valores incrementais antes de compará-los com a cota do projeto:

Métrica de cota	Recursos necessários por nó bare metal	Recursos necessários para um cluster de três nós
`compute.googleapis.com/cpus_per_vm_family` para `Z3`	192 vCPUs	3 × 192 = 576 vCPUs
`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 ao adicionar nós a um cluster atual	1 política de posicionamento distribuído por cluster
`compute.googleapis.com/regional_backend_services_protocol_forwarding_fast_ha`	0 ao adicionar nós ou clusters sem novos appliances	1 por novo VIP do dispositivo de gerenciamento do VCF ou endpoint do NSX Edge

Para ver a lista completa de cotas necessárias e instruções sobre como visualizar ou solicitar aumentos de cota, consulte Cotas e limites.

Defina as variáveis de ambiente

Defina as seguintes variáveis de ambiente no shell do jumpbox. Liste os nós a serem adicionados na variável de ambiente ADD_HOSTS e os nós a serem removidos na variável de ambiente REMOVE_HOSTS (uma ou mais entradas cada):

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 executar os comandos, substitua o seguinte:

PROJECT_ID: o ID do projeto de destino do Google Cloud.
VCF_ADMIN_PASSWORD: a senha de administrador do SDDC Manager.

Confirme se nenhum dos endereços IP planejados já está em uso por regras de encaminhamento ou instâncias:

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

Adicionar nós a um cluster

Para expandir um cluster do vSphere adicionando nós bare metal, siga as etapas nas seções a seguir.

Criar registros DNS

Como as zonas gerenciadas de encaminhamento e reversas do Cloud DNS já existem, crie registros de encaminhamento (A) e reversos (PTR) apenas para os novos nós:

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

Criar instâncias bare metal

Crie cada novo nó na política de posicionamento atual do cluster com a placa de rede de gerenciamento principal do ESXi (nic0) e as NICs dinâmicas com inclusão de tag VLAN para vMotion (VLAN 2), vSAN (VLAN 3) e NSX TEP (VLAN 4).

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

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

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

Atualizar associação do NEG

Todos os nós de um cluster em uma zona precisam pertencer ao mesmo NEG zonal da sub-rede. Adicione os novos nós ao NEG de gerenciamento e ao NEG do NSX TEP. Não é necessário modificar as políticas de alta disponibilidade ou as regras de encaminhamento:

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

Redefinir a senha raiz do ESXi

Redefina a senha root de cada novo nó para que corresponda à senha root do ESXi armazenada no Secret Manager. Use o mesmo secret para provisionar os nós em uma etapa posterior. Se você mudou ou alternou as senhas do ESXi root ou do VCF após a implantação inicial, atualize o secret correspondente no Secret Manager antes de executar esses comandos.

Para redefinir a senha de root em cada novo nó, execute os seguintes comandos na VM jumpbox e insira a senha inicial de root do ESXi quando solicitado:

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

Adicione os novos endereços IP ao pool de rede e ao pool de TEP.

O pool de rede do cluster (cl02-np01) e o pool de TEP do NSX (cl02-tep-pool) inicialmente contêm apenas os endereços IP dos nós do cluster. Adicione os endereços IP exatos da NIC dinâmica do Compute Engine dos novos nós aos dois pools para que o VCF e o NSX aloquem endereços IP do conjunto que já está configurado nas NICs do Compute Engine.

Atualize o pool de rede (vMotion e vSAN): adicione os endereços IP do vMotion e do vSAN dos novos nós ao pool de rede cl02-np01 usando as operações do VCF ou a API SDDC Manager:

Operações do VCF

Em Operações do VCF, acesse Gerenciamento de pool de rede, selecione o pool de rede cl02-np01, edite as redes vMotion e vSAN e adicione os intervalos de endereços IP para os novos nós.

API SDDC Manager

Execute os comandos a seguir para adicionar um intervalo de IP único por novo nó ao pool de rede:

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'

Atualize o pool de IPs do TEP do NSX: no NSX Manager (o host NSX_MANAGER), acesse Rede > Pools de endereços IP, edite o pool de endereços IP cl02-tep-pool e adicione os endereços IP do TEP dos novos nós aos intervalos de IP da sub-rede (192.168.4.24–192.168.4.25 neste exemplo), mantendo o gateway definido como 192.168.4.1. Verifique a configuração atualizada do pool:
```
NSX_PW="NSX_ADMIN_PASSWORD"
curl -s -u "admin:${NSX_PW}" "https://${NSX_MANAGER}/policy/api/v1/infra/ip-pools" \
    | jq -r '.results[] | [.id, .display_name] | @tsv'

TEP_POOL_ID="TEP_POOL_ID"   # ID of cl02-tep-pool from the preceding output
curl -s -u "admin:${NSX_PW}" \
    "https://${NSX_MANAGER}/policy/api/v1/infra/ip-pools/${TEP_POOL_ID}/ip-subnets" \
    | jq '.results[] | {cidr, gateway_ip, allocation_ranges}'
```
Antes de executar os comandos, substitua o seguinte:
- NSX_ADMIN_PASSWORD: a senha do admin do NSX Manager (disponível no endpoint /v1/credentials do SDDC Manager ou nas operações do VCF).
- TEP_POOL_ID: o ID do pool de endereços IP cl02-tep-pool.
Observação :se o pool de TEP não tiver endereços IP livres, o NSX não poderá preparar os novos nós. Se os pools tiverem outros endereços IP livres (por exemplo, endereços IP que foram liberados por nós removidos anteriormente), o VCF ou o NSX poderá alocar esses endereços IP em vez dos endereços IP da NIC do Compute Engine dos novos nós. Se isso acontecer, alinhe as NICs em Alinhar NICs dinâmicas do vMotion e do vSAN e Alinhar NICs dinâmicas do NSX TEP.

Comissionar os nós

Comissione os novos nós no inventário do SDDC Manager usando as operações do VCF ou a API SDDC Manager:

Operações do VCF

Em Operações do VCF, acesse Inventário > Hosts > Hosts de comissão.
Selecione o pool de rede cl02-np01 e o tipo de armazenamento vSAN ESA.
Insira os novos FQDNs do host e as credenciais do root.
Aceite as impressões digitais SSL, valide os hosts e clique em Commission.

API SDDC Manager

Execute os comandos a seguir para validar e comissionar os hosts e, em seguida, pesquise o status da tarefa até que ele retorne Successful:

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

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

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

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

Se uma impressão digital SSL do host exibir um nome de certificado interno (não FQDN), execute o comando esxcli network ip dns search add -d vmware.gve no host, execute novamente o script /var/lib/vmware/osdata/init.sh e, em seguida, execute o comando /sbin/generate-certificates e reinicie os serviços rhttpproxy e hostd.

Verificar o alinhamento de IP pré-expansão

Mantenha todas as validações de vSAN, vMotion e conectividade de rede ativadas no SDDC Manager. Essas verificações de validação são aprovadas apenas quando os endereços IP vmk1 e vmk2 que o VCF atribui a cada novo nó correspondem aos endereços IP da NIC dinâmica do Compute Engine.

Verifique se os endereços IP do pool não utilizados correspondem aos novos endereços IP da placa de rede do Compute Engine: compare os intervalos do pool de rede com os endereços IP que os hosts atuais já usam e as placas de rede do Compute Engine dos novos nós. Os únicos endereços IP do pool que os hosts atuais não usam devem ser os endereços IP dos novos nós:

# 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

Confirme se o SDDC Manager não ignora as validações: no dispositivo do SDDC Manager (como root), verifique se o arquivo application.properties não contém propriedades 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

Abrir o cluster

Adicione os nós comissionados ao cluster de destino usando as operações do VCF ou a API SDDC Manager:

Operações do VCF

Em Operações do VCF (ou na interface do SDDC Manager), abra o domínio do cluster, selecione o cluster cl02, escolha Ações > Adicionar host, selecione os nós comissionados, mapeie a interface vmnic0 para o uplink uplink1 do VDS do cluster e envie o fluxo de trabalho. Acesse Gerenciamento de frotas > Tarefas para monitorar a tarefa e registrar o ID dela (defina a variável TASK_ID como esse valor para a próxima seção).

API SDDC Manager

Execute os seguintes comandos para validar a especificação de expansão e expandir o cluster:

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

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

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

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

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

Quando você expande um cluster, o SDDC Manager aloca endereços IP do vMotion e do vSAN do pool de rede sem preservar a ordem do host. Se o SDDC Manager atribuir a um novo nó um endereço IP diferente da NIC dinâmica do Compute Engine, a tarefa será pausada na etapa de verificação da conectividade do vSAN e do vMotion. Deixe a tarefa no estado de falha, conclua as etapas em Alinhar NICs dinâmicas do vMotion e do vSAN e, em seguida, tente novamente a mesma tarefa. Não inicie uma nova solicitação de expansão para esses nós: após uma falha na expansão, os nós não estão mais no estado não atribuído, e o SDDC Manager rejeita uma nova solicitação de expansão.

Alinhar NICs dinâmicas do vMotion e do vSAN

Conclua as etapas desta seção se a tarefa de expansão do cluster for pausada na etapa de verificação da conectividade do vSAN e do vMotion. Se a tarefa passar por essa etapa, execute apenas a etapa 1 para confirmar o alinhamento e prossiga para Alinhar NICs dinâmicas do NSX TEP.

Leia os endereços IP alocados pelo VCF e compare-os com as NICs do Compute Engine: execute os dois comandos da etapa 1 de Verificar o alinhamento de IP pré-expansão. Somente os novos nós estão no escopo.

Exclua todas as NICs dinâmicas incompatíveis primeiro e, em seguida, adicione-as novamente: exclua todas as NICs dinâmicas incompatíveis (a interface nic0.2 para vMotion e a interface nic0.3 para vSAN) em cada novo nó antes de adicionar novamente qualquer interface. Caso contrário, os endereços IP trocados falharão com um erro 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}"

Repetir a tarefa com falha: em Operações do VCF, acesse Gerenciamento de frota.

Tarefas para tentar novamente a tarefa de expansão ou execute o seguinte comando da API SDDC Manager:
```
curl -s -X PATCH "https://${SDDC_MANAGER}/v1/tasks/${TASK_ID}" \
    -H "Authorization: Bearer ${TOKEN}" -H "Content-Type: application/json" \
    -d '{"status": "RETRY"}'
```
Se a tarefa falhar novamente, repita as etapas 1 e 2 antes de tentar de novo.

Alinhar as NICs dinâmicas do NSX TEP

Depois que o NSX configurar os novos nós como nós de transporte, verifique e alinhe as NICs dinâmicas do TEP do NSX da VLAN 4 (vmk10) nos novos nós.

Recupere os endereços IP do TEP alocados pelo NSX: consulte o NSX Manager (ou execute o comando esxcli network ip interface ipv4 get -i vmk10 em 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'

Recrie NICs de TEP incompatíveis: compare os endereços IP vmk10 alocados pelo NSX com a NIC de TEP do Compute Engine (VLAN 4) de cada novo nó. Somente os novos nós estão no escopo. Não modifique as NICs de TEP dos nós existentes. Para todos os novos nós incompatíveis, primeiro remova cada nó do NEG do TEP e exclua a interface nic0.4 em todos os nós incompatíveis. Em seguida, adicione novamente a interface nic0.4 e anexe os nós ao NEG do 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}"

Verificar a expansão do cluster

Depois que a tarefa de expansão do cluster for concluída, verifique o seguinte:

vCenter Server: os novos nós estão conectados e íntegros no cluster cl02 sem alarmes de rede.
vSAN: para o cluster cl02, acesse Monitor > vSAN > Skyline Health e confirme se todas as verificações de integridade foram aprovadas e se a capacidade do repositório de dados inclui os novos nós.
NSX Manager: acesse Sistema > Fabric > Hosts e confirme se cada novo nó mostra Sucesso e Ativo e se os túneis de sobreposição estão ativos.
Operações do VCF: os novos nós são atribuídos ao cluster cl02, e a lista de tarefas não tem tarefas com falha.

Em um shell de host ESXi (por exemplo, esxi-h10), verifique a conectividade do frame jumbo (MTU 8896 menos cabeçalho 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

Falhas de vSAN a tolerar e contagem de hosts

Use a tabela a seguir para determinar quantos nós o cluster precisa ter ao adicionar nós ou quantos precisam ser mantidos ao remover nós:

Falhas a tolerar	Esquema de posicionamento de dados	Mínimo de hosts
`FTT=1`	RAID-1 (espelhamento) ou RAID-5 (programação de eliminação)	3 (recomendamos 4 ou mais para recriar após uma falha do host ou durante a manutenção)
`FTT=2`	RAID-1 (espelhamento)	5
`FTT=2`	RAID-6 (programação de eliminação)	6

Remover nós de um cluster

Concluir as verificações antes da remoção

Antes de remover nós de um cluster, verifique o seguinte:

Contagem de hosts: após a remoção do nó, o cluster mantém pelo menos três nós e, no mínimo, a contagem de hosts listada em Falhas de vSAN a serem toleradas e contagem de hosts que suas políticas de armazenamento ativo exigem.
Capacidade: no vCenter Server, para o cluster cl02, acesse Monitorar > vSAN > Pré-verificação de migração de dados para cada nó que você planeja remover (com a opção Migração de dados completa) e confirme se os nós restantes têm capacidade de computação e vSAN suficientes.
Integridade: o vSAN Skyline Health é aprovado sem erros e não há tarefas com falha nas operações do VCF ou no SDDC Manager.

Líderes de política de alta disponibilidade: confirme se nenhum serviço de back-end usa um nó que você está removendo como líder de política de alta disponibilidade. Se um serviço de back-end usar um desses nós como líder, atualize o líder para um nó restante (o host que executa a VM do dispositivo após a migração):

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

Remover os nós do cluster

Remova os nós de destino do cluster no VCF. O VCF coloca cada nó no modo de manutenção, migra as VMs e evacua os dados do vSAN. É possível remover os nós usando as operações do VCF ou a API SDDC Manager:

Operações do VCF

Em Operações do VCF (ou na interface do SDDC Manager), abra o domínio do cluster, selecione o cluster cl02, escolha Ações > Remover host, selecione os nós que serão removidos e confirme.

API SDDC Manager

Execute os seguintes comandos para validar a especificação de compactação e remover os hosts do cluster:

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

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

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

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

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

Desativar os nós

Depois de remover os nós do cluster, desative-os do inventário do SDDC Manager usando as operações do VCF ou a API SDDC Manager:

Operações do VCF

Em Operações do VCF, acesse Inventário > Hosts, selecione os nós não atribuídos e clique em Desativar (para mais informações, consulte Desativar hosts na documentação do VMware Cloud Foundation).

API SDDC Manager

Execute os comandos a seguir para enviar uma solicitação de desativação e consultar a tarefa até que ela retorne 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'

Remover os nós dos NEGs

Remova os nós desativados do NEG de gerenciamento e do NEG do NSX TEP:

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

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

Se a CLI gcloud rejeitar a remoção do NEG do TEP sem um endereço IP explícito, inclua o endereço IP do endpoint (conforme mostrado pelo comando de verificação) na flag --remove-endpoint: --remove-endpoint="instance=HOST,ip=TEP_IP".

Excluir as instâncias bare metal

Remova a proteção contra exclusão em cada host desativado e exclua a instância bare metal do Compute Engine (o Compute Engine exclui automaticamente o disco de inicialização com a instância):

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

Limpar registros DNS e pools de IP

Exclua os registros DNS de encaminhamento (A) e reversos (PTR) do Cloud DNS dos nós removidos:

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

Os endereços IP do vMotion, do vSAN e do TEP dos nós removidos ficam livres novamente no pool de rede e no pool de TEP do NSX. É possível manter esses endereços IP para um nó futuro (atribuindo a esse nó futuro os mesmos endereços IP da NIC do Compute Engine) ou removê-los dos pools para que o VCF e o NSX não os aloquem a um nó futuro cujas NICs do Compute Engine usem endereços IP diferentes.

Verificar a remoção do nó

Depois de concluir o fluxo de trabalho de remoção de nós, verifique o seguinte:

vCenter Server: o cluster cl02 mostra apenas os nós restantes, todos conectados e íntegros, e o vSphere HA e o DRS não relatam erros.
vSAN: o Skyline Health é aprovado e todos os objetos virtuais estão em conformidade (para o cluster cl02, acesse Monitor > vSAN > Virtual Objects).
NSX Manager: os nós removidos não são mais listados como nós de transporte, e os nós restantes mostram Ativo.
Operações do VCF e SDDC Manager: os nós removidos não estão mais no inventário do host, e não há tarefas com falha.
Google Cloud: as instâncias bare metal, os discos de inicialização, os endpoints de NEG e os registros DNS dos nós removidos são excluídos.

Resolver problemas de expansão de cluster e remoção de nós

A tabela a seguir lista problemas, causas e soluções comuns ao adicionar ou remover nós em um cluster do vSphere:

Problema	Causa	Resolução
A expansão do cluster falha na verificação de conectividade do vSAN e do vMotion; novos nós informam que não estão íntegros	Quando você expande um cluster, o SDDC Manager aloca endereços IP `vmk1` e `vmk2` do pool de rede sem preservar a ordem do host.	Mantenha as validações ativadas. Adicione apenas os endereços IP dos novos nós ao pool de rede. Se a tarefa for pausada na verificação de conectividade, alinhe as NICs dinâmicas e tente novamente.
O status do host NSX é `Degraded` ou os túneis estão inativos nos novos nós	O NSX Manager atribui endereços IP de TEP (`vmk10`) do pool de IPs aleatoriamente, então eles podem não corresponder à NIC de TEP do Compute Engine.	Alinhe as NICs dinâmicas do NSX TEP conforme descrito em Alinhar NICs dinâmicas do NSX TEP.
O NSX não pode preparar os novos nós	O pool de IPs do NSX TEP do cluster não tem endereços IP livres.	Adicione os endereços IP de TEP dos novos nós ao pool de IPs de TEP e tente novamente.
O SDDC Manager rejeita uma nova solicitação de expansão para os mesmos nós.	Uma tarefa de expansão com falha deixa os nós fora do estado `UNASSIGNED_USEABLE`.	Tente novamente a tarefa que falhou (`PATCH /v1/tasks/TASK_ID` com `{"status": "RETRY"}`) em vez de enviar uma nova solicitação de expansão.
O comissionamento de um nó falha porque ele já foi comissionado	Não é possível comissionar um host duas vezes.	Prossiga com a expansão do cluster ou desative o nó primeiro se precisar ativá-lo novamente (por exemplo, com um pool de rede diferente).
Erro `IP_IN_USE` ao adicionar novamente uma NIC dinâmica	Dois nós trocaram de endereço IP ou um endereço IP planejado se sobrepõe a outro nó.	Exclua todas as NICs dinâmicas incompatíveis em todos os novos nós antes de adicionar qualquer interface novamente e verifique seu plano de endereço IP.
Falha na validação da remoção do nó	A remoção dos nós reduz o cluster para menos hosts do que o tamanho mínimo, ou os nós restantes não têm capacidade suficiente.	Remova menos nós ou adicione capacidade primeiro. Não use a propriedade `"force": true`.
A CLI `gcloud` se recusa a excluir a instância bare metal	A proteção contra exclusão está ativada na instância.	Execute o comando `gcloud compute instances update HOST --no-deletion-protection` antes de excluir a instância.
Domínios de falha do vSAN incorretos após a adição de nós	Você criou nós em uma política de posicionamento diferente ou dois clusters compartilham uma política de posicionamento.	Crie novos nós na política de posicionamento do cluster e distribua-os entre os domínios de disponibilidade.
Erros de vSAN, tempos limite de vMotion ou fragmentação de sobreposição de NSX	A MTU configurada é maior que a MTU da rede VPC (`8896` bytes).	Os novos nós herdam o VDS e os pools do cluster. Mantenha a MTU definida como `8896` bytes em todos os componentes.
A impressão digital ou o certificado SSL do host mostra um nome interno	O domínio de pesquisa de DNS não está definido no host.	Execute o comando `esxcli network ip dns search add -d vmware.gve`, execute novamente o script `/var/lib/vmware/osdata/init.sh`, execute o comando `/sbin/generate-certificates` e reinicie os serviços `rhttpproxy` e `hostd`.
Os hosts não podem dar um ping no gateway da sub-rede (`.1`)	OGoogle Cloud não responde a solicitações de eco ICMP em endereços IP de gateway de sub-rede.	Comportamento esperado. Ignore os avisos de ping do gateway.

A seguir

Adicione um novo cluster do vSphere a um domínio em Adicionar um cluster do vSphere a um domínio.
Gerencie a capacidade de nós bare metal no console do Google Cloud em Gerenciar capacidade de nós.
Escalone a capacidade do nó usando o Terraform em Gerenciar a capacidade do nó usando o Terraform.
Consulte as diretrizes da política de posicionamento em Políticas de posicionamento e domínios de disponibilidade.
Consulte as diretrizes de dimensionamento e arquitetura de cluster em Sobre clusters do vSphere.
Confira as soluções alternativas comuns de implantação e operacionais em Problemas conhecidos.