Google은 AI 기술을 사용하여 콘텐츠를 사용자의 기본 언어로 번역합니다. AI 번역에는 오류가 있을 수 있습니다.

vSphere 클러스터에서 노드 추가 또는 삭제

이 문서에서는 Google Cloud의 VMware 솔루션에 있는 VMware Cloud Foundation(VCF) 9.1에서 기존 vSphere 클러스터에 Compute Engine 베어메탈 노드를 하나 이상 추가 (클러스터 확장)하고 클러스터에서 노드를 하나 이상 삭제(클러스터 압축)하는 방법을 설명합니다. 관리 도메인 또는 VI 워크로드 도메인에서 기존 클러스터의 컴퓨팅 및 vSAN 스토리지 용량을 늘리거나 줄여야 하는 경우 클러스터를 확장하거나 축소합니다. 단일 노드 또는 여러 노드를 추가하거나 삭제하는 경우에도 동일한 절차가 적용됩니다. ADD_HOSTS 또는 REMOVE_HOSTS 환경 변수에 하나 이상의 노드를 나열합니다.

아키텍처 요약

기존 vSphere 클러스터에서 노드를 추가하거나 삭제할 때 워크플로는 다음 아키텍처를 사용합니다.

노드 추가: 각 새 노드는 클러스터의 기존 노드와 동일한 영역, 배치 정책, 머신 유형으로 배포하는 z3-highmem-192-highlssd-metal 베어메탈 인스턴스입니다. 각 노드에는 Virtual Private Cloud (VPC) 네트워크의 ESXi 관리 서브넷에 기본 네트워크 인터페이스 (nic0)가 있고 vMotion, vSAN, NSX 터널 엔드포인트 (TEP)에 VLAN 태깅된 Dynamic Network Interfaces가 있습니다. 노드가 기존 영역 네트워크 엔드포인트 그룹 (NEG)에 조인합니다. 그런 다음 SDDC Manager에서 클러스터의 네트워크 풀을 사용하여 노드를 커미셔닝하고 클러스터에 추가합니다.
노드 삭제: 먼저 VCF의 클러스터에서 노드를 삭제합니다. 그러면 워크로드 VM이 마이그레이션되고 호스트의 vSAN 데이터가 비워집니다. 그런 다음 SDDC Manager에서 호스트를 사용 중단하고 영역 NEG에서 삭제한 후 기본 Compute Engine 베어메탈 인스턴스를 삭제합니다.
IP 주소 정렬: 클러스터 생성과 마찬가지로 VCF는 클러스터의 네트워크 풀에서 vMotion 및 vSAN IP 주소를 할당하고 NSX는 NSX IP 주소 풀에서 TEP(vmk10) IP 주소를 할당합니다. 모든 VCF 검증을 사용 설정한 상태로 유지하면서 새 노드의 Compute Engine Dynamic NIC를 VCF 할당 IP 주소와 일치시킵니다.
어플라이언스 변경 없음: 클러스터 노드를 추가하거나 삭제할 때 관리 어플라이언스에 대한 새 Cloud DNS 레코드, 백엔드 서비스, 고가용성 (HA) 정책 또는 전달 규칙이 필요하지 않습니다.

시작하기 전에

노드를 추가하거나 삭제하기 전에 다음 섹션의 요구사항을 확인하고 환경 변수를 구성하세요.

환경 요구사항 확인

환경이 다음 요구사항을 충족하는지 확인합니다.

권한: Compute 관리자 (roles/compute.admin), DNS 관리자 (roles/dns.admin), Secret Manager 보안 비밀 접근자 (roles/secretmanager.secretAccessor)를 포함하여 대상 프로젝트에 필요한 Identity and Access Management(IAM) 역할이 있습니다.
Secret Manager의 사용자 인증 정보: 초기 배포 후 VCF에서 ESXi root, SDDC Manager, vCenter Server 또는 NSX Manager 비밀번호를 변경하거나 순환한 경우 Secret Manager가 자동으로 업데이트되지 않습니다. 이 문서의 명령어를 실행하기 전에 Secret Manager에서 해당 보안 비밀을 업데이트하거나 업데이트된 비밀번호를 직접 제공하여 활성 VCF 사용자 인증 정보와 일치하도록 합니다.
클러스터 및 도메인 상태: 대상 클러스터와 해당 도메인이 정상 상태이고(vCenter Server, vSAN, NSX Manager, SDDC Manager, VCF Operations) 실패한 태스크가 없습니다.
노드 추가:
- 프로젝트에 대상 리전 및 영역의 z3 베어메탈 할당량이 충분합니다.
- 새 노드는 클러스터의 기존 노드와 동일한 머신 유형 (vSAN Express Storage Architecture (ESA)의 경우 z3-highmem-192-highlssd-metal)을 사용하며 클러스터의 기존 배치 정책에 할당됩니다 (각 배치 정책은 하나의 클러스터에만 속함).
- 각 새 노드에는 기존 파티션이 없는 NVMe 로컬 SSD 기기가 있습니다.
- 조직에서 constraints/compute.trustedImageProjects 조직 정책을 시행하거나 VPC 서비스 제어 서비스 경계를 사용하는 경우 프로젝트에서 smve-prod-public-images 프로젝트(projects/999037279871)에 대한 이미지 액세스를 허용하는지 확인합니다. 자세한 내용은 노드 용량 관리를 참조하세요.
- VLAN 기반 네트워킹: VMware 솔루션에서는 VLAN 기반 네트워킹을 지원하기 위해 VPC 네트워크의 서브넷에 학습을 통해서만 기본 범위 브로드캐스트로 설정된 서브넷 마스크 확인 속성이 있어야 합니다. Google Cloud 콘솔 지원 센터에서 다음 정보를 입력하여 지원 티켓을 엽니다.
  - 제품: Google Cloud VMware Engine
  - 우선순위: P2
  - 카테고리: 네트워크 연결
  - 비즈니스 영향: 일반적인 기술 관련 질문
  - 자세한 정보 제공: Allowlist L2 network connectivity for my project, 프로젝트 ID, 프로젝트 번호, 배포의 대상 리전 및 영역
  VLAN 기반 네트워킹 지원에 대한 자세한 내용은 레이어 2 에뮬레이션: ARP 브로드캐스팅 및 커스텀 MAC 학습을 참조하세요.
노드를 삭제하려면 다음 안내를 따르세요.
- 남은 노드에는 활성 워크로드에 충분한 컴퓨팅 및 vSAN 스토리지 용량이 있습니다.
- 노드 삭제 후 클러스터는 최소 3개의 노드 (허용되는 실패가 1개인 vSAN의 최소값 (FTT=1)) 또는 활성 스토리지 정책 요구사항에 필요한 최소 호스트 수 (vSAN 허용되는 실패 및 호스트 수 참조)를 유지합니다.
점프박스 VM: gcloud CLI, curl, jq가 설치되어 있고 VPC 네트워크에 대한 네트워크 연결이 있는 점프박스 VM에 액세스할 수 있습니다(예: bm-gcp-demo 서브넷).

예시 환경 파라미터 검토

이 문서의 명령어는 다음 예시 매개변수를 사용합니다.

입력 매개변수	예시 값	설명
프로젝트 ID, 리전, 영역	`PROJECT_ID` / `us-east4` / `us-east4-b`	대상 클러스터와 동일한 프로젝트, 리전, 영역
고객 ID	`demo`	기존 리소스 이름에 사용되는 식별자
대상 클러스터	`cl02`(`esxi-h7`, `esxi-h8`, `esxi-h9`)	관리 도메인 또는 VI 워크로드 도메인의 기존 클러스터
배치 정책	`bm-cl02`	클러스터의 기존 그룹 배치 정책
네트워크 풀 및 VDS	`cl02-np01`/`cl02-vds-01`	클러스터의 기존 네트워크 풀 및 vSphere Distributed Switch (VDS)
NSX TEP IP 풀	`cl02-tep-pool`	클러스터의 기존 NSX IP 주소 풀
NSX Manager	`nsx01.vmware.gve`	클러스터 도메인의 NSX Manager (또는 전용 NSX 인스턴스가 있는 `wld01` 워크로드 도메인의 경우 `nsx05.vmware.gve`)
머신 유형	`z3-highmem-192-highlssd-metal`	클러스터의 기존 노드와 동일한 머신 유형
VPC 네트워크 및 서브넷 (VLAN ID)	`bm-demo`; `bm-mgmt-demo` (태그 없음), `bm-vmotion-demo` (`2`), `bm-vsan-demo` (`3`), `bm-nsx-demo` (`4`)	기존 VPC 네트워크 및 레이어 2 서브넷
영역별 NEG	`bm-mgmt-demo`, `bm-nsx-tep-demo`	기존 관리 및 NSX TEP NEG
SDDC Manager	`sddcm.vmware.gve`(`192.168.0.3`)	기존 SDDC Manager 어플라이언스
ESXi `root` 비밀번호	`esxi-root-password`	ESXi `root` 비밀번호가 포함된 기존 Secret Manager 보안 비밀

IP 주소 및 호스트 이름 계획

다음 예시에서는 cl02 클러스터에 노드 2개 (esxi-h10 및 esxi-h11)를 추가한 후 그중 하나 (esxi-h11)를 삭제합니다. 단일 노드를 추가하거나 삭제하려면 환경 변수 배열에 해당 노드만 포함합니다.

ESXi 호스트	관리 IP (`nic0`)	vMotion (VLAN 2)	vSAN (VLAN 3)	NSX TEP (VLAN 4)	가용성 도메인	작업
`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`	추가 후 삭제

클러스터의 배치 정책 내에서 가용성 도메인에 클러스터 노드를 분산합니다. 기존 노드 (esxi-h7~esxi-h9)는 가용성 도메인 1~3를 사용하므로 새 노드는 가용성 도메인 4 및 5를 사용합니다.

리전 할당량 확인

베어메탈 노드를 프로비저닝하거나 클러스터를 만들기 전에 프로젝트에 리전 및 전역 Compute Engine 할당량이 충분한지 확인합니다. 리전의 모든 기존 클러스터 리소스를 프로젝트 할당량과 비교하기 전에 다음 증분 값에 추가합니다.

할당량 측정항목	베어메탈 노드당 필요한 리소스	노드 3개 클러스터에 필요한 리소스
`Z3`의 `compute.googleapis.com/cpus_per_vm_family`	vCPU 192개	3 × 192 = 576 vCPU
`Z3`의 `compute.googleapis.com/local_ssd_total_storage_per_vm_family`	72 TB	3 × 72 TB = 216 TB
`compute.googleapis.com/hyperdisk_balanced_total_storage`	128GB	3 × 128 GB = 384 GB
`compute.googleapis.com/resource_policies`	기존 클러스터에 노드를 추가할 때 0	클러스터당 분산 배치 정책 1개
`compute.googleapis.com/regional_backend_services_protocol_forwarding_fast_ha`	새 어플라이언스 없이 노드 또는 클러스터를 추가하는 경우 0	새 VCF 관리 어플라이언스 VIP 또는 NSX Edge 엔드포인트당 1개

필수 할당량의 전체 목록과 할당량 상향을 보거나 요청하는 방법에 대한 안내는 할당량 및 한도를 참조하세요.

환경 변수 설정하기

점프박스 셸에서 다음 환경 변수를 설정합니다. ADD_HOSTS 환경 변수에 추가할 노드와 REMOVE_HOSTS 환경 변수에서 삭제할 노드를 나열합니다 (각각 하나 이상의 항목).

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

명령어를 실행하기 전에 다음을 바꿉니다.

PROJECT_ID: 대상 Google Cloud프로젝트의 ID입니다.
VCF_ADMIN_PASSWORD: SDDC Manager 관리자 비밀번호입니다.

계획된 IP 주소가 기존 전달 규칙 또는 인스턴스에서 이미 사용 중이 아닌지 확인합니다.

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

클러스터에 노드 추가

베어메탈 노드를 추가하여 기존 vSphere 클러스터를 확장하려면 다음 섹션의 단계를 완료하세요.

DNS 레코드 만들기

정방향 및 역방향 Cloud DNS 관리형 영역이 이미 있으므로 새 노드에 대해서만 정방향 (A) 및 역방향 (PTR) 레코드를 만듭니다.

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

베어메탈 인스턴스 만들기

기본 ESXi 관리 NIC (nic0)와 vMotion (VLAN 2), vSAN (VLAN 3), NSX TEP (VLAN 4)용 VLAN 태그가 지정된 Dynamic NIC를 사용하여 클러스터의 기존 배치 정책에 각 새 노드를 만듭니다.

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

NEG 멤버십 업데이트

영역에 있는 클러스터의 모든 노드는 서브넷의 동일한 영역 NEG에 속해야 합니다. 관리 NEG 및 NSX TEP NEG에 새 노드를 추가합니다. HA 정책 또는 전달 규칙을 수정할 필요가 없습니다.

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

ESXi 루트 비밀번호 재설정

Secret Manager에 저장된 ESXi root 비밀번호와 일치하도록 각 새 노드의 root 비밀번호를 재설정합니다. 이후 단계에서 동일한 보안 비밀을 사용하여 노드를 커미셔닝합니다. 초기 배포 후 ESXi root 또는 VCF 비밀번호를 변경하거나 순환한 경우 이 명령어를 실행하기 전에 Secret Manager에서 해당 보안 비밀을 업데이트합니다.

각 새 노드에서 root 비밀번호를 재설정하려면 점프박스 VM에서 다음 명령어를 실행하고 메시지가 표시되면 초기 ESXi root 비밀번호를 입력합니다.

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

네트워크 풀 및 TEP 풀에 새 IP 주소 추가

클러스터의 네트워크 풀 (cl02-np01) 및 NSX TEP 풀 (cl02-tep-pool)에는 처음에는 기존 클러스터 노드의 IP 주소만 포함됩니다. VCF 및 NSX가 Compute Engine NIC에 이미 구성된 집합에서 IP 주소를 할당하도록 새 노드의 정확한 Compute Engine Dynamic NIC IP 주소를 두 풀에 모두 추가합니다.

네트워크 풀 업데이트 (vMotion 및 vSAN): VCF Operations 또는 SDDC Manager API를 사용하여 새 노드의 vMotion 및 vSAN IP 주소를 cl02-np01 네트워크 풀에 추가합니다.

VCF 작업

VCF 작업에서 네트워크 풀 관리로 이동하고 cl02-np01 네트워크 풀을 선택하고 vMotion 및 vSAN 네트워크를 수정한 후 새 노드의 IP 주소 범위를 추가합니다.

SDDC Manager API

다음 명령어를 실행하여 새 노드당 단일 IP 범위 하나를 네트워크 풀에 추가합니다.

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'

NSX TEP IP 풀 업데이트: NSX Manager (NSX_MANAGER 호스트)에서 네트워킹 > IP 주소 풀로 이동하고 cl02-tep-pool IP 주소 풀을 수정하고 새 노드의 TEP IP 주소를 서브넷의 IP 범위 (이 예시에서는 192.168.4.24~192.168.4.25)에 추가하고 게이트웨이를 192.168.4.1로 설정합니다. 업데이트된 풀 구성을 확인합니다.
```
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}'
```
명령어를 실행하기 전에 다음을 바꿉니다.
- NSX_ADMIN_PASSWORD: NSX Manager admin 비밀번호 (SDDC Manager /v1/credentials 엔드포인트 또는 VCF Operations에서 사용 가능)
- TEP_POOL_ID: cl02-tep-pool IP 주소 풀의 ID입니다.
참고: TEP 풀에 사용 가능한 IP 주소가 없으면 NSX에서 새 노드를 준비할 수 없습니다. 풀에 다른 무료 IP 주소 (예: 이전에 삭제된 노드에서 해제된 IP 주소)가 포함된 경우 VCF 또는 NSX는 새 노드의 Compute Engine NIC IP 주소 대신 해당 IP 주소를 할당할 수 있습니다. 이 경우 vMotion 및 vSAN Dynamic NIC 정렬 및 NSX TEP Dynamic NIC 정렬에서 NIC를 정렬합니다.

노드 커미셔닝

VCF Operations 또는 SDDC Manager API를 사용하여 새 노드를 SDDC Manager 인벤토리에 커미셔닝합니다.

VCF 작업

VCF 작업에서 인벤토리 > 호스트 > 커미션 호스트로 이동합니다.
cl02-np01 네트워크 풀을 선택하고 vSAN ESA 스토리지 유형을 선택합니다.
새 호스트 FQDN과 root 사용자 인증 정보를 입력합니다.
SSL 지문을 수락하고 호스트를 검증한 후 커미션을 클릭합니다.

SDDC Manager API

다음 명령어를 실행하여 호스트를 검증하고 커미셔닝한 후 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'

호스트 SSL 지문에 내부 (비 FQDN) 인증서 이름이 표시되면 호스트에서 esxcli network ip dns search add -d vmware.gve 명령어를 실행하고 /var/lib/vmware/osdata/init.sh 스크립트를 다시 실행한 후 /sbin/generate-certificates 명령어를 실행하고 rhttpproxy 및 hostd 서비스를 다시 시작합니다.

사전 확장 전 IP 정렬 확인

SDDC Manager에서 모든 vSAN, vMotion, 네트워크 연결 유효성 검사를 사용 설정된 상태로 유지합니다. 이러한 검증 검사는 VCF가 각 새 노드에 할당하는 vmk1 및 vmk2 IP 주소가 Compute Engine Dynamic NIC IP 주소와 일치하는 경우에만 통과합니다.

사용되지 않는 풀 IP 주소가 새 Compute Engine NIC IP 주소와 일치하는지 확인: 네트워크 풀 범위를 기존 호스트에서 이미 사용하는 IP 주소 및 새 노드의 Compute Engine NIC와 비교합니다. 기존 호스트에서 사용하지 않는 유일한 풀 IP 주소는 새 노드의 IP 주소여야 합니다.

# 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

SDDC Manager가 검증을 우회하지 않는지 확인: SDDC Manager 어플라이언스 (root)에서 application.properties 파일에 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
```

클러스터 펼치기

VCF Operations 또는 SDDC Manager API를 사용하여 커미셔닝된 노드를 대상 클러스터에 추가합니다.

VCF 작업

VCF 작업 (또는 SDDC Manager UI)에서 클러스터의 도메인을 열고 cl02 클러스터를 선택하고 작업 > 호스트 추가를 선택하고 커미셔닝된 노드를 선택하고 vmnic0 인터페이스를 클러스터 VDS의 uplink1 업링크에 매핑하고 워크플로를 제출합니다. Fleet Management > Tasks로 이동하여 태스크를 모니터링하고 ID를 기록합니다 (다음 섹션에서 TASK_ID 변수를 이 값으로 설정).

SDDC Manager API

다음 명령어를 실행하여 확장 사양을 검증하고 클러스터를 확장합니다.

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'

클러스터를 확장하면 SDDC Manager는 호스트 순서를 유지하지 않고 네트워크 풀에서 vMotion 및 vSAN IP 주소를 할당합니다. SDDC Manager가 새 노드에 Compute Engine Dynamic NIC와 다른 IP 주소를 할당하면 vSAN 및 vMotion 연결의 확인 단계에서 태스크가 일시중지됩니다. 작업을 실패 상태로 두고 vMotion 및 vSAN Dynamic NIC 정렬의 단계를 완료한 후 동일한 작업을 다시 시도합니다. 이러한 노드에 대해 새 확장 요청을 시작하지 마세요. 확장이 실패하면 노드가 더 이상 할당되지 않은 상태가 아니며 SDDC Manager가 새 확장 요청을 거부합니다.

vMotion 및 vSAN Dynamic NIC 정렬

vSAN 및 vMotion 연결의 확인 단계에서 클러스터 확장 태스크가 일시중지되면 이 섹션의 단계를 완료합니다. 태스크가 이 단계를 통과하면 1단계만 실행하여 정렬을 확인한 후 NSX TEP Dynamic NIC 정렬로 진행합니다.

VCF 할당 IP 주소를 읽고 Compute Engine NIC와 비교: 확장 전 IP 정렬 확인의 1단계에서 두 명령어를 실행합니다. 새 노드만 범위에 포함됩니다.

일치하지 않는 모든 Dynamic NIC를 먼저 삭제한 후 다시 추가: 인터페이스를 다시 추가하기 전에 모든 새 노드에서 일치하지 않는 모든 Dynamic NIC (vMotion의 nic0.2 인터페이스 및 vSAN의 nic0.3 인터페이스)를 삭제합니다. 그렇지 않으면 교체된 IP 주소가 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}"

실패한 작업 다시 시도: VCF 작업에서 Fleet 관리로 이동합니다.

태스크를 클릭하여 확장 태스크를 다시 시도하거나 다음 SDDC Manager API 명령어를 실행합니다.
```
curl -s -X PATCH "https://${SDDC_MANAGER}/v1/tasks/${TASK_ID}" \
    -H "Authorization: Bearer ${TOKEN}" -H "Content-Type: application/json" \
    -d '{"status": "RETRY"}'
```
작업이 다시 실패하면 1단계와 2단계를 반복한 후 다시 시도합니다.

NSX TEP Dynamic NIC 정렬

NSX가 새 노드를 전송 노드로 구성한 후 새 노드에서 VLAN 4 NSX TEP (vmk10) Dynamic NIC를 확인하고 정렬합니다.

NSX에서 할당한 TEP IP 주소 검색: NSX Manager를 쿼리하거나 각 ESXi 호스트에서 esxcli network ip interface ipv4 get -i vmk10 명령어를 실행합니다.

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

일치하지 않는 TEP NIC 다시 만들기: NSX에서 할당한 vmk10 IP 주소를 각 새 노드의 Compute Engine TEP NIC (VLAN 4)와 비교합니다. 새 노드만 범위에 포함됩니다. 기존 노드의 TEP NIC는 수정하지 마세요. 일치하지 않는 모든 새 노드의 경우 먼저 TEP NEG에서 각 노드를 분리하고 일치하지 않는 모든 노드에서 nic0.4 인터페이스를 삭제합니다. 그런 다음 nic0.4 인터페이스를 다시 추가하고 노드를 TEP NEG에 다시 연결합니다.

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

클러스터 확장 확인

클러스터 확장 태스크가 성공하면 다음을 확인합니다.

vCenter Server: 새 노드가 cl02 클러스터에서 네트워크 알람 없이 연결되고 정상 상태입니다.
vSAN: cl02 클러스터의 경우 모니터링 > vSAN > Skyline 상태로 이동하여 모든 상태 점검이 통과되고 데이터 스토리지 용량에 새 노드가 포함되어 있는지 확인합니다.
NSX Manager: 시스템 > 패브릭 > 호스트로 이동하여 각 새 노드에 성공 및 작동이 표시되고 오버레이 터널이 작동하는지 확인합니다.
VCF 작업: 새 노드가 cl02 클러스터에 할당되고 태스크 목록에 실패한 태스크가 없습니다.

ESXi 호스트 셸 (예: esxi-h10)에서 점보 프레임 연결 (8896 MTU에서 28바이트 IP/ICMP 헤더를 뺀 값 = 8868바이트)을 확인합니다.

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

vSAN 허용되는 장애 수 및 호스트 수

다음 표를 사용하여 노드를 추가할 때 클러스터에 필요한 노드 수 또는 노드를 삭제할 때 유지해야 하는 노드 수를 확인하세요.

허용할 장애	데이터 배치 스키마	최소 호스트
`FTT=1`	RAID-1 (미러링) 또는 RAID-5 (삭제 코딩)	3 (호스트 장애 후 또는 유지보수 중에 다시 빌드하려면 4개 이상 권장)
`FTT=2`	RAID-1 (미러링)	5
`FTT=2`	RAID-6 (삭제 코딩)	6

클러스터에서 노드 삭제

삭제 전 확인 완료하기

클러스터에서 노드를 삭제하기 전에 다음을 확인하세요.

호스트 수: 노드 삭제 후 클러스터는 최소 3개의 노드와 활성 스토리지 정책에 필요한 허용할 vSAN 장애 및 호스트 수에 나열된 최소 호스트 수를 유지합니다.
용량: vCenter Server에서 cl02 클러스터의 경우 삭제하려는 각 노드에 대해 모니터링 > vSAN > 데이터 마이그레이션 사전 검사로 이동하고 (전체 데이터 마이그레이션 옵션 사용) 나머지 노드에 vSAN 및 컴퓨팅 용량이 충분한지 확인합니다.
상태: vSAN Skyline Health가 오류 없이 통과되고 VCF Operations 또는 SDDC Manager에 실패한 태스크가 없습니다.

HA 정책 리더: 삭제하는 노드를 HA 정책 리더로 사용하는 백엔드 서비스가 없는지 확인합니다. 백엔드 서비스가 해당 노드 중 하나를 리더로 사용하는 경우 리더를 나머지 노드 (마이그레이션 후 어플라이언스 VM을 실행하는 호스트)로 업데이트합니다.

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

클러스터에서 노드 삭제

VCF의 클러스터에서 대상 노드를 삭제합니다. VCF는 각 노드를 유지보수 모드로 전환하고, VM을 마이그레이션하고, vSAN 데이터를 비웁니다. VCF Operations 또는 SDDC Manager API를 사용하여 노드를 삭제할 수 있습니다.

VCF 작업

VCF Operations (또는 SDDC Manager UI)에서 클러스터의 도메인을 열고 cl02 클러스터를 선택하고 작업 > 호스트 삭제를 선택하고 삭제할 노드를 선택한 후 확인합니다.

SDDC Manager API

다음 명령어를 실행하여 압축 사양을 검증하고 클러스터에서 호스트를 삭제합니다.

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'

노드 사용 중단

클러스터에서 노드를 삭제한 후 VCF Operations 또는 SDDC Manager API를 사용하여 SDDC Manager 인벤토리에서 노드를 사용 중단합니다.

VCF 작업

VCF 작업에서 인벤토리 > 호스트로 이동하고 할당되지 않은 노드를 선택한 후 사용 중단을 클릭합니다 (자세한 내용은 VMware Cloud Foundation 문서의 호스트 사용 중단 참조).

SDDC Manager API

다음 명령어를 실행하여 사용 중단 요청을 전송하고 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'

NEG에서 노드 삭제

관리 NEG 및 NSX TEP NEG에서 사용 중단된 노드를 삭제합니다.

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

gcloud CLI가 명시적인 IP 주소 없이 TEP NEG에서 삭제를 거부하는 경우 --remove-endpoint 플래그에 엔드포인트 IP 주소 (확인 명령어에 표시됨)를 포함합니다. --remove-endpoint="instance=HOST,ip=TEP_IP"

베어메탈 인스턴스 삭제

사용 중단된 각 호스트에서 삭제 방지를 지우고 Compute Engine 베어메탈 인스턴스를 삭제합니다 (Compute Engine은 인스턴스와 함께 부팅 디스크를 자동으로 삭제함).

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

DNS 레코드 및 IP 풀 정리

삭제된 노드의 정방향 (A) 및 역방향 (PTR) Cloud DNS 레코드를 삭제합니다.

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

삭제된 노드의 vMotion, vSAN, TEP IP 주소는 네트워크 풀 및 NSX TEP 풀에서 다시 사용 가능해집니다. 향후 노드에 대해 해당 IP 주소를 유지하거나 (향후 노드에 동일한 Compute Engine NIC IP 주소를 할당) 풀에서 삭제하여 VCF 및 NSX가 Compute Engine NIC에서 다른 IP 주소를 사용하는 향후 노드에 할당하지 않도록 할 수 있습니다.

노드 삭제 확인

노드 삭제 워크플로를 완료한 후 다음을 확인합니다.

vCenter Server: cl02 클러스터에는 연결되어 있고 정상 상태인 나머지 노드만 표시되며 vSphere HA 및 DRS에서 오류가 보고되지 않습니다.
vSAN: Skyline Health가 통과되고 모든 가상 객체가 규정을 준수합니다 (cl02 클러스터의 경우 모니터링 > vSAN > 가상 객체로 이동).
NSX Manager: 삭제된 노드가 더 이상 전송 노드로 표시되지 않고 나머지 노드가 Up으로 표시됩니다.
VCF 작업 및 SDDC Manager: 삭제된 노드가 더 이상 호스트 인벤토리에 없으며 실패한 태스크가 없습니다.
Google Cloud: 삭제된 노드의 베어메탈 인스턴스, 부팅 디스크, NEG 엔드포인트, DNS 레코드가 삭제됩니다.

클러스터 확장 및 노드 삭제 문제 해결

다음 표에는 vSphere 클러스터에서 노드를 추가하거나 삭제할 때 발생하는 일반적인 문제, 원인, 해결 방법이 나와 있습니다.

문제	원인	해결 방법
vSAN 및 vMotion의 연결 확인에서 클러스터 확장이 실패하고 새 노드가 비정상으로 보고됨	클러스터를 확장하면 SDDC Manager는 호스트 순서를 유지하지 않고 네트워크 풀에서 `vmk1` 및 `vmk2` IP 주소를 할당합니다.	검증을 사용 설정된 상태로 유지합니다. 새 노드의 IP 주소만 네트워크 풀에 추가합니다. 연결 확인에서 작업이 일시중지되면 Dynamic NIC를 정렬하고 동일한 작업을 다시 시도합니다.
NSX 호스트 상태가 `Degraded`이거나 새 노드에서 터널이 작동 중지됨	NSX Manager는 IP 풀에서 TEP (`vmk10`) IP 주소를 무작위로 할당하므로 Compute Engine TEP NIC와 일치하지 않을 수 있습니다.	NSX TEP Dynamic NIC 정렬에 설명된 대로 NSX TEP Dynamic NIC를 정렬합니다.
NSX에서 새 노드를 준비할 수 없음	클러스터의 NSX TEP IP 풀에 사용 가능한 IP 주소가 없습니다.	새 노드의 TEP IP 주소를 TEP IP 풀에 추가한 후 작업을 다시 시도하세요.
SDDC Manager가 동일한 노드에 대한 새 확장 요청을 거부함	확장 태스크가 실패하면 노드가 `UNASSIGNED_USEABLE` 상태를 벗어납니다.	새 확장 요청을 제출하는 대신 실패한 작업 (`{"status": "RETRY"}`를 사용하는 `PATCH /v1/tasks/TASK_ID`)을 다시 시도합니다.
노드가 이미 커미셔닝되었으므로 노드 커미셔닝 실패	호스트를 두 번 위탁할 수 없습니다.	클러스터 확장을 진행하거나, 노드를 다시 커미셔닝해야 하는 경우 (예: 다른 네트워크 풀 사용) 먼저 노드를 사용 중단합니다.
Dynamic NIC를 다시 추가할 때 `IP_IN_USE` 오류 발생	두 노드가 IP 주소를 교환했거나 계획된 IP 주소가 다른 노드와 겹칩니다.	인터페이스를 다시 추가하기 전에 먼저 모든 새 노드에서 일치하지 않는 Dynamic NIC를 모두 삭제하고 IP 주소 계획을 확인하세요.
노드 삭제 검증 실패	노드를 삭제하면 클러스터가 최소 크기보다 적은 호스트로 축소되거나 남은 노드의 용량이 부족합니다.	노드를 더 적게 삭제하거나 먼저 용량을 추가하세요. `"force": true` 속성을 사용하지 마세요.
`gcloud` CLI에서 베어메탈 인스턴스 삭제를 거부함	인스턴스에 삭제 방지가 사용 설정되어 있습니다.	인스턴스를 삭제하기 전에 `gcloud compute instances update HOST --no-deletion-protection` 명령어를 실행합니다.
노드를 추가한 후 잘못된 vSAN 장애 도메인	다른 배치 정책에 새 노드를 만들었거나 두 클러스터가 배치 정책을 공유합니다.	클러스터의 자체 배치 정책에 새 노드를 만들고 가용성 도메인에 분산합니다.
vSAN 오류, vMotion 시간 초과 또는 NSX 오버레이 단편화	구성된 MTU가 VPC 네트워크 MTU (`8896`바이트)보다 큽니다.	새 노드는 클러스터의 VDS 및 풀을 상속합니다. 모든 구성요소에서 MTU를 `8896`바이트로 설정합니다.
호스트 SSL 지문 또는 인증서에 내부 이름이 표시됨	DNS 검색 도메인이 호스트에 설정되어 있지 않습니다.	`esxcli network ip dns search add -d vmware.gve` 명령어를 실행하고 `/var/lib/vmware/osdata/init.sh` 스크립트를 다시 실행한 후 `/sbin/generate-certificates` 명령어를 실행하고 `rhttpproxy` 및 `hostd` 서비스를 다시 시작합니다.
호스트가 서브넷 게이트웨이 (`.1`)를 핑할 수 없음	Google Cloud 은 서브넷 게이트웨이 IP 주소의 ICMP 에코 요청에 응답하지 않습니다.	예상되는 동작입니다. 게이트웨이 핑 경고를 무시하세요.

다음 단계

도메인에 vSphere 클러스터 추가에서 기존 도메인에 새 vSphere 클러스터를 추가합니다.
노드 용량 관리의 Google Cloud 콘솔에서 베어메탈 노드 용량을 관리합니다.
Terraform을 사용하여 노드 용량 관리에서 Terraform을 사용하여 노드 용량 확장
배치 정책 및 가용성 도메인에서 배치 정책 가이드라인을 검토합니다.
vSphere 클러스터 정보에서 클러스터 크기 및 아키텍처 가이드라인을 검토합니다.
알려진 문제에서 일반적인 배포 및 운영 해결 방법을 검토합니다.