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

도메인에 vSphere 클러스터 추가

이 문서에서는 Compute Engine 베어메탈 인스턴스를 사용하여 Google Cloud 의 VMware 솔루션에서 기존 VMware Cloud Foundation (VCF) 9.1 도메인에 vSphere 클러스터를 추가하는 방법을 설명합니다. 단일 클러스터를 넘어 컴퓨팅 및 vSAN 스토리지 용량을 확장하거나, 워크로드를 격리하거나, 기존 도메인 내에서 별도의 vSphere Lifecycle Manager (vLCM) 이미지 또는 vSAN 스토리지 정책을 적용해야 하는 경우 클러스터를 추가합니다. 동일한 프로젝트, 가상 프라이빗 클라우드 (VPC) 네트워크, 영역에서 다음 도메인 중 하나에 클러스터를 추가할 수 있습니다.

관리 도메인: 관리 vCenter Server 및 NSX Manager에서 관리하는 클러스터를 추가합니다.
VI 워크로드 도메인: 워크로드 도메인 vCenter Server 및 NSX Manager 인스턴스에서 관리하는 클러스터를 추가합니다.

아키텍처 요약

기존 VCF 도메인에 vSphere 클러스터를 추가하면 배포에서 다음 아키텍처를 사용합니다.

베어메탈 ESXi 호스트: 각 새 ESXi 호스트는 VPC 네트워크의 기존 레이어 2 서브넷 (ESXi 관리, vMotion, vSAN, NSX 터널 엔드포인트 (TEP))에 연결된 z3-highmem-192-highlssd-metal 베어메탈 인스턴스입니다. 각 호스트는 기본 네트워크 인터페이스 (nic0)와 VLAN 태그가 지정된 Dynamic Network Interface를 통해 연결됩니다.
추가 관리 어플라이언스 없음: 이미 대상 도메인을 관리하는 vCenter Server 및 NSX Manager에 클러스터를 추가하므로 새 관리 어플라이언스를 배포하지 않습니다. 또한 새 어플라이언스 Cloud DNS 레코드, 백엔드 서비스, 고가용성 (HA) 정책 또는 전달 규칙을 만들지 않습니다. 대신 기존 영역 네트워크 엔드포인트 그룹 (NEG)에 새 호스트를 추가합니다.
IP 주소 할당 및 정렬: VCF는 네트워크 풀에서 vMotion 및 vSAN IP 주소를 할당하고 NSX는 NSX IP 주소 풀에서 TEP (vmk10) IP 주소를 할당합니다. VCF 9.1에서는 두 풀 모두 호스트별 정적 할당을 지원하지 않으므로 배포 중에 Compute Engine Dynamic NIC를 VCF 할당 IP 주소와 일치시키고 모든 VCF 검증을 사용 설정된 상태로 유지합니다.

시작하기 전에

클러스터를 만들기 전에 다음 섹션의 요구사항을 확인하고 환경 변수를 구성합니다.

환경 요구사항 확인

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

권한: 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)이고 실패한 태스크가 없습니다.
vSphere Lifecycle Manager (vLCM) 이미지: VCF 이미지 라이브러리에서 vLCM 이미지를 사용할 수 있거나 호스트에서 이미지를 추출할 계획입니다. 모든 호스트가 정렬된 상태를 유지하도록 기존 클러스터에서 사용하는 것과 동일한 이미지를 사용합니다.
저장 장치: 각 새 호스트에는 vSAN에 필요한 대로 기존 파티션이 없는 NVMe 로컬 SSD 기기가 있습니다.
최소 노드 수: 클러스터에는 최소 3개의 베어메탈 노드가 필요합니다. 이는 허용할 장애가 하나인 vSAN에 필요한 최소 개수입니다(FTT=1).
머신 유형: 클러스터의 모든 노드는 동일한 머신 유형(vSAN Express Storage Architecture(ESA)의 경우 z3-highmem-192-highlssd-metal)을 사용합니다.
영역: 새 클러스터는 기존 관리 및 NSX TEP 영역 NEG와 동일한 영역에 있습니다.
점프박스 VM: gcloud CLI, curl, jq가 설치되어 있고 VPC 네트워크에 대한 네트워크 연결이 있는 점프박스 VM에 액세스할 수 있습니다(예: bm-gcp-demo 서브넷).
신뢰할 수 있는 이미지 정책 및 VPC 서비스 제어: 조직에서 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 학습을 참조하세요.

예시 환경 파라미터 검토

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

입력 매개변수	예시 값	설명
프로젝트 ID	`PROJECT_ID`	대상 도메인과 동일한 Google Cloud 프로젝트
리전 및 영역	`us-east4`/`us-east4-b`	기존 영역 NEG와 동일한 영역
고객 ID	`demo`	기존 리소스 이름에 사용되는 식별자
대상 도메인	`mgmt-domain`(또는 `wld01`)	기존 관리 도메인 또는 VI 워크로드 도메인
클러스터 이름	`cl02`	새 vSphere 클러스터의 이름
머신 유형	`z3-highmem-192-highlssd-metal`	클러스터의 모든 노드에 대한 동종 머신 유형
노드 수	`3`	vSAN `FTT=1`의 최소 노드 수
VPC 네트워크	`bm-demo`	기존 VPC 네트워크
서브넷 (VLAN ID)	`bm-mgmt-demo` (태그 없음), `bm-vmotion-demo` (`2`), `bm-vsan-demo` (`3`), `bm-nsx-demo` (`4`)	기존 Layer 2 서브넷
영역별 NEG	`bm-mgmt-demo`, `bm-nsx-tep-demo`	기존 관리 및 NSX TEP NEG
ESXi 이미지	계열 `astra-vcf-9-1-x`, 프로젝트 `smve-prod-offline-depot`	기존 클러스터와 동일한 ESXi 이미지 빌드
DNS 도메인 및 영역	`vmware.gve` / `dns-zone-demo`, `rev-dns-zone-demo`	기존 Cloud DNS 정방향 및 역방향 관리형 영역
SDDC Manager	`sddcm.vmware.gve`(`192.168.0.3`)	기존 SDDC Manager 어플라이언스
ESXi `root` 비밀번호	`esxi-root-password`	ESXi `root` 비밀번호가 포함된 기존 Secret Manager 보안 비밀

IP 주소 및 호스트 이름 계획

다음 표에서는 새로운 ESXi 호스트 3개에 대한 IP 주소 계획 예시를 보여줍니다.

ESXi 호스트	관리 IP (`nic0`)	vMotion (VLAN 2)	vSAN (VLAN 3)	NSX TEP (VLAN 4)
`esxi-h7`	`192.168.0.161`	`192.168.2.21`	`192.168.3.21`	`192.168.4.21`
`esxi-h8`	`192.168.0.162`	`192.168.2.22`	`192.168.3.22`	`192.168.4.22`
`esxi-h9`	`192.168.0.163`	`192.168.2.23`	`192.168.3.23`	`192.168.4.23`

대상 도메인 선택

선택한 대상 도메인에 따라 새 클러스터를 관리하는 vCenter Server, NSX Manager, 오버레이 전송 영역이 결정됩니다.

파라미터 또는 리소스	관리 도메인의 클러스터	VI 워크로드 도메인의 클러스터
`TARGET_DOMAIN` 변수	`mgmt-domain`	`wld01`
vCenter Server 관리	`vc01.vmware.gve`	`vc02.vmware.gve`
`NSX_MANAGER` 변수	`nsx01.vmware.gve` (관리 NSX)	`nsx05.vmware.gve` (전용 NSX) 또는 `nsx01.vmware.gve` (공유 관리 NSX)
`TRANSPORT_ZONE` 변수	`overlay-tz-mgmt-nsxt`	워크로드 도메인 NSX 인스턴스의 오버레이 전송 영역

리전 할당량 확인

베어메탈 노드를 프로비저닝하거나 클러스터를 만들기 전에 프로젝트에 리전 및 전역 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개

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

환경 변수 설정하기

이 가이드 전체의 명령어에서 사용할 수 있도록 점프박스 셸에서 다음 환경 변수를 설정합니다.

export PROJECT_ID="PROJECT_ID"
export REGION="us-east4"
export ZONE="us-east4-b"
export CUSTOMER_ID="demo"
export VPC_NETWORK="bm-${CUSTOMER_ID}"
export DOMAIN="vmware.gve"
export DNS_ZONE="dns-zone-${CUSTOMER_ID}"
export REV_DNS_ZONE="rev-dns-zone-${CUSTOMER_ID}"
export MGMT_SUBNET="bm-mgmt-${CUSTOMER_ID}"
export VMOTION_SUBNET="bm-vmotion-${CUSTOMER_ID}"
export VSAN_SUBNET="bm-vsan-${CUSTOMER_ID}"
export TEP_SUBNET="bm-nsx-${CUSTOMER_ID}"
export MGMT_NEG="bm-mgmt-${CUSTOMER_ID}"
export TEP_NEG="bm-nsx-tep-${CUSTOMER_ID}"
export CLUSTER_NAME="cl02"
export PLACEMENT_POLICY="bm-${CLUSTER_NAME}"
export NETWORK_POOL_NAME="${CLUSTER_NAME}-np01"
export TEP_POOL_NAME="${CLUSTER_NAME}-tep-pool"
export VDS_NAME="${CLUSTER_NAME}-vds-01"
export MACHINE_TYPE="z3-highmem-192-highlssd-metal"
export ESXI_IMAGE_FAMILY="astra-vcf-9-1-x"
export ESXI_IMAGE_PROJECT="smve-prod-offline-depot"
export SDDC_MANAGER="sddcm.vmware.gve"            # 192.168.0.3
export VCF_USER="admin@local"
export VCF_PASSWORD="VCF_ADMIN_PASSWORD"
export ESXI_PASSWORD_SECRET="esxi-root-password"  # Secret Manager secret holding the ESXi root password
export MTU=8896                                   # VPC MTU

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

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

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

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

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

DNS 레코드 만들기

관리 도메인을 배포할 때 레이어 2 서브넷, Cloud DNS 인바운드 전달 정책, 정방향 및 역방향 관리형 영역을 만들었습니다. 클러스터를 추가해도 새 어플라이언스가 배포되지 않으므로 새 ESXi 호스트에 대한 정방향 (A) 및 역방향 (PTR) 레코드만 만들면 됩니다.

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

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

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

베어메탈 인스턴스 만들기

새 클러스터에 전용 배치 정책을 만듭니다. 그런 다음 기본 관리 인터페이스 (nic0)와 vMotion (VLAN 2), vSAN (VLAN 3), NSX TEP (VLAN 4)용 VLAN 태그가 지정된 Dynamic NIC를 사용하여 각 베어메탈 ESXi 호스트를 만듭니다.

배치 정책 만들기

그룹 배치 정책을 만듭니다.

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

부팅 디스크 및 베어메탈 ESXi 인스턴스 만들기

클러스터의 각 호스트에 대해 Google Cloud Hyperdisk Balanced 부팅 디스크와 베어메탈 ESXi 인스턴스를 만듭니다.

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

  # Create boot disk
  gcloud compute disks create "${HOST}" \
      --image-project="${ESXI_IMAGE_PROJECT}" \
      --image-family="${ESXI_IMAGE_FAMILY}" \
      --type=hyperdisk-balanced --interface=NVME --size=128GB \
      --guest-os-features=IDPF \
      --zone="${ZONE}" --project="${PROJECT_ID}"

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

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

NEG 멤버십 업데이트

VCF 네트워크 어플라이언스가 클러스터 노드 간에 트래픽을 라우팅할 수 있도록 영역의 모든 노드가 서브넷의 동일한 영역 NEG에 속해야 합니다. 기존 관리 NEG 및 NSX TEP NEG에 새 호스트를 추가합니다.

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

ALL_NEGS=("${MGMT_NEG}" "${TEP_NEG}")
for entry in "${CLUSTER_HOSTS[@]}"; do
  read -r HOST _ <<< "${entry}"
  for NEG in "${ALL_NEGS[@]}"; do
    gcloud compute network-endpoint-groups update "${NEG}" \
        --zone="${ZONE}" \
        --add-endpoint="instance=${HOST}" \
        --project="${PROJECT_ID}"
  done
done

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

ESXi 루트 비밀번호 재설정

보안 및 호스트 커미셔닝을 위해 각 새 호스트의 root 비밀번호를 Secret Manager에 저장된 ESXi root 비밀번호로 재설정합니다. 이후 단계에서 동일한 보안 비밀을 사용하여 호스트를 커미셔닝합니다. 비밀번호가 VCF 복잡성 요구사항 (대문자, 소문자, 숫자, 특수문자를 포함하여 15자 이상)을 충족하는지 확인합니다. 초기 배포 후 ESXi root 또는 VCF 비밀번호를 변경하거나 순환한 경우 이 명령어를 실행하기 전에 Secret Manager에서 해당 보안 비밀을 업데이트하세요.

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

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

# 2. Reset the root password on each new host
for entry in "${CLUSTER_HOSTS[@]}"; do
  read -r HOST _ <<< "${entry}"
  ssh -o StrictHostKeyChecking=no "root@${HOST}.${DOMAIN}" \
      "esxcli system account set -i root -p '${ESXI_ROOT_PASSWORD}' -c '${ESXI_ROOT_PASSWORD}'"
done

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

전용 네트워크 풀 만들기

VCF는 호스트를 커미셔닝할 때 선택한 네트워크 풀에서 vMotion 및 vSAN IP 주소를 할당합니다. 기존 클러스터의 네트워크 풀에는 자체 호스트 IP 주소만 포함되므로 새 호스트의 Compute Engine Dynamic NIC에 사전 할당한 정확한 vMotion 및 vSAN IP 주소가 IP 범위에 포함된 전용 네트워크 풀을 만듭니다. 전용 네트워크 풀을 사용하면 VCF IP 할당이 사전 할당된 Compute Engine IP 주소 집합 내에 유지되므로 불일치가 발생하는 경우 나중에 호스트-IP 순서만 조정하면 됩니다.

VCF Operations 또는 SDDC Manager API를 사용하여 네트워크 풀을 만들 수 있습니다.

VCF 작업

VCF 작업에서 네트워크 풀 관리로 이동하고 네트워크 풀 만들기를 클릭한 후 vMotion(VLAN 2, 192.168.2.21~192.168.2.23) 및 vSAN (VLAN 3, 192.168.3.21~192.168.3.23) 네트워크 설정과 MTU 8896바이트를 사용하여 cl02-np01 네트워크 풀을 만듭니다.

SDDC Manager API

다음 명령어를 실행하여 네트워크 풀을 만들고 ID를 가져옵니다.

TOKEN=$(curl -s -X POST "https://${SDDC_MANAGER}/v1/tokens" \
    -H "Content-Type: application/json" \
    -d "{\"username\":\"${VCF_USER}\",\"password\":\"${VCF_PASSWORD}\"}" | jq -r '.accessToken')

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

# Retrieve the network pool ID for host commissioning
POOL_ID=$(curl -s "https://${SDDC_MANAGER}/v1/network-pools" -H "Authorization: Bearer ${TOKEN}" \
    | jq -r --arg n "${NETWORK_POOL_NAME}" '.elements[] | select(.name==$n) | .id')
echo "${POOL_ID}"

호스트 위임

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

VCF 작업

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

SDDC Manager API

다음 명령어를 실행하여 호스트를 검증하고 커미셔닝한 후 Successful가 반환될 때까지 태스크 ID를 폴링합니다.

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

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

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

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

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

# 3. Poll task status until Successful
curl -s "https://${SDDC_MANAGER}/v1/tasks/${TASK_ID}" -H "Authorization: Bearer ${TOKEN}" | jq -r '.status'

호스트 SSL 지문에 내부 (비FQDN) 인증서 이름이 표시되면 호스트에 DNS 검색 도메인이 구성되지 않은 것입니다. 영향을 받는 ESXi 호스트에서 esxcli network ip dns search add -d vmware.gve 명령어를 실행하고 /var/lib/vmware/osdata/init.sh 스크립트를 다시 실행한 후 /sbin/generate-certificates 명령어를 실행하고 rhttpproxy 및 hostd 서비스 (/etc/init.d/rhttpproxy restart && /etc/init.d/hostd restart)를 다시 시작합니다.

배포 전 IP 정렬 확인

SDDC Manager에서 모든 vSAN, vMotion, 네트워크 연결 유효성 검사를 사용 설정된 상태로 유지합니다. 이러한 검증은 VCF가 각 호스트에 할당하는 vmk1 (vMotion) 및 vmk2(vSAN) IP 주소가 해당 호스트의 Compute Engine Dynamic NIC IP 주소와 일치하는 경우에만 통과합니다. SDDC Manager가 다른 호스트 순서로 풀 IP 주소를 할당하여 불일치가 발생하면 연결 확인에서 클러스터 생성 태스크가 일시중지됩니다. 그런 다음 작업을 다시 시도하기 전에 후속 단계에서 Dynamic NIC를 정렬합니다.

네트워크 풀 범위가 Compute Engine vMotion 및 vSAN NIC IP 주소와 일치하는지 확인: 네트워크 풀에 새 호스트의 Dynamic NIC에 사전 할당한 IP 주소만 포함되어 있는지 확인합니다 (이 예시에서는 192.168.2.21~192.168.2.23 및 192.168.3.21~192.168.3.23).

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

# Inspect Compute Engine dynamic NIC IPs per new host (VLAN 2 = vMotion, 3 = vSAN, 4 = TEP)
for entry in "${CLUSTER_HOSTS[@]}"; do
  read -r HOST _ <<< "${entry}"
  echo "== ${HOST}"
  gcloud compute instances describe "${HOST}" --zone="${ZONE}" --project="${PROJECT_ID}" \
      --format="table(networkInterfaces[].name,networkInterfaces[].vlan,networkInterfaces[].networkIP)"
done

호스트 이름 오름차순으로 IP 주소 할당: IP 주소 집합이 양쪽에서 동일하도록 호스트 이름 오름차순 (esxi-h7 → .21, esxi-h8 → .22, esxi-h9 → .23)으로 Compute Engine IP 주소를 미리 할당합니다.
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
```
SDDC Manager API를 사용하여 클러스터를 추가하는 경우 요청 본문에 "skipValidations": true 속성을 설정하지 마세요.
Compute Engine TEP NIC IP 주소와 일치하도록 NSX TEP 풀 크기 조정: 새 호스트의 VLAN 4 Dynamic NIC의 IP 주소와 일치하는 192.168.4.21~192.168.4.23 범위 (TEP_START 변수에서 TEP_END 변수까지)로 클러스터의 새 정적 NSX TEP IP 주소 풀을 구성하고 게이트웨이를 192.168.4.1로 설정합니다.

클러스터 추가

VCF Operations 또는 SDDC Manager API를 사용하여 대상 도메인에 클러스터를 추가할 수 있습니다.

VCF 작업

VCF Operations에 로그인하고 인벤토리로 이동하여 VCF 인스턴스를 펼치고 대상 도메인 (mgmt-domain 또는 wld01)을 선택한 후 클러스터 추가를 클릭합니다 (또는 SDDC Manager UI에서 워크로드 도메인 > 대상 도메인 > 작업 > 클러스터 추가로 이동). 다음 설정을 사용하여 마법사를 완료합니다.

마법사 페이지	필드	값
스토리지	유형	vSAN, vSAN ESA 사용 설정, vSAN HCI, 전송 중 데이터 암호화 사용 중지
클러스터	클러스터 이름	`cl02`
이미지	vLCM 이미지	기존 클러스터에서 사용하는 이미지를 선택하거나 이 VCF 인스턴스의 호스트에서 이미지 추출을 선택합니다 (`esxi-h7` 사용).
호스트	호스트	`esxi-h7`, `esxi-h8`, `esxi-h9` (`cl02-np01` 네트워크 풀을 사용하여 vSAN ESA로 커미셔닝됨)
vSphere Distributed Switch	프로필	기본값 (단일 VDS) 또는 커스텀: 업링크 1개 (`uplink1` → `vmnic0`), MTU `8896`, 트래픽 유형 ESX 관리, VM 관리, vMotion, vSAN, NSX
NSX 스위치 모드	가상 스위치 작동 모드	NSX Manager에 구성된 기본 가상 스위치 모드 적용을 선택 해제하고 작동 모드를 표준으로 설정합니다. VMware 솔루션 호스트는 기본 모드 (향상된 데이터 경로 표준)를 지원하지 않습니다.
NSX 호스트 오버레이	TEP VLAN 및 IP 할당	VLAN `4` (기존 NSX 구성과 일치), 고정 IP 풀 (DHCP 사용 안함): 새 풀 `cl02-tep-pool`, CIDR `192.168.4.0/24`, 범위 `192.168.4.21`~`192.168.4.23`, 게이트웨이 `192.168.4.1`
검토	제출	마침을 클릭합니다. Fleet Management > Tasks로 이동하여 태스크를 모니터링하고 태스크 ID (`TASK_ID`)를 기록합니다.

SDDC Manager API

대상 도메인 ID, vLCM 이미지 성격 ID, 커미셔닝된 호스트 ID를 가져온 후 클러스터를 만들기 위한 사양을 검증하고 제출합니다.

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

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

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

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

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

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

명령어를 실행하기 전에 PERSONALITY_ID를 클러스터 vLCM 이미지의 personalityId 값으로 바꿉니다.

VCF가 호스트에 Compute Engine Dynamic NIC와 다른 vMotion 또는 vSAN IP 주소를 할당하면 vSAN 및 vMotion 연결 확인 단계에서 태스크가 중지됩니다. 작업을 실패 상태로 두고 vMotion 및 vSAN Dynamic NIC 정렬의 단계를 완료한 후 작업을 다시 시도합니다. 작업을 취소하거나 검사 확인을 사용 중지하지 마세요.

vMotion 및 vSAN Dynamic NIC 정렬

클러스터 생성 태스크가 vSAN 및 vMotion 연결의 확인 단계에서 중지되는 경우 이 섹션의 단계를 적용합니다. 태스크가 이 단계를 통과하면 1단계와 2단계만 실행하여 IP 정렬을 확인한 후 NSX TEP Dynamic NIC 정렬로 진행합니다.

VCF 할당 IP 주소 읽기: SDDC Manager /v1/hosts 엔드포인트 (또는 SDDC Manager platform 데이터베이스)를 쿼리하여 VCF가 각 호스트에 할당한 vMotion(vmk1) 및 vSAN (vmk2) IP 주소를 검토합니다.

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

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

Compute Engine Dynamic NIC와 비교: 각 새 호스트의 현재 Dynamic NIC IP 주소를 나열합니다.

for entry in "${CLUSTER_HOSTS[@]}"; do
  read -r HOST _ <<< "${entry}"
  echo "== ${HOST}"
  gcloud compute instances describe "${HOST}" --zone="${ZONE}" --project="${PROJECT_ID}" \
      --format="table(networkInterfaces[].name,networkInterfaces[].vlan,networkInterfaces[].networkIP)"
done

일치하지 않는 모든 Dynamic NIC를 먼저 삭제한 후 다시 추가: 인터페이스를 다시 추가하기 전에 일치하지 않는 모든 호스트에서 일치하지 않는 모든 Dynamic NIC (vMotion의 nic0.2 인터페이스 및 vSAN의 nic0.3 인터페이스)를 삭제합니다. 그렇지 않으면 두 호스트 간에 교체된 IP 주소가 IP_IN_USE 오류와 함께 실패합니다.

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

# 3a. Delete mismatched NICs (run on all mismatched hosts before running 3b)
gcloud compute instances network-interfaces delete "${HOST}" \
    --network-interface=nic0.2 \
    --zone="${ZONE}" --project="${PROJECT_ID}" --quiet
gcloud compute instances network-interfaces delete "${HOST}" \
    --network-interface=nic0.3 \
    --zone="${ZONE}" --project="${PROJECT_ID}" --quiet

# 3b. Re-add the dynamic NICs with the VCF-allocated IP addresses
# vMotion (VLAN 2)
gcloud compute instances network-interfaces add "${HOST}" \
    --parent-nic-name=nic0 --vlan=2 \
    --network="${VPC_NETWORK}" --subnetwork="${VMOTION_SUBNET}" \
    --private-network-ip="${VCF_VMOTION_IP}" --no-address \
    --zone="${ZONE}" --project="${PROJECT_ID}"

# vSAN (VLAN 3)
gcloud compute instances network-interfaces add "${HOST}" \
    --parent-nic-name=nic0 --vlan=3 \
    --network="${VPC_NETWORK}" --subnetwork="${VSAN_SUBNET}" \
    --private-network-ip="${VCF_VSAN_IP}" --no-address \
    --zone="${ZONE}" --project="${PROJECT_ID}"

실패한 클러스터 태스크 재시도: 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"}'
```
재시도된 태스크는 vSAN 및 vMotion에 대한 연결 확인을 다시 실행하고 모든 Compute Engine Dynamic NIC가 VCF 할당 IP 주소와 일치하면 성공합니다.

NSX TEP Dynamic NIC 정렬

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

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

NSX_PW="NSX_ADMIN_PASSWORD"

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

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

명령어를 실행하기 전에 NSX_ADMIN_PASSWORD를 NSX Manager admin 비밀번호 (SDDC Manager /v1/credentials 엔드포인트 또는 VCF Operations 비밀번호 관리에서 사용 가능)로 바꿉니다.

Compute Engine TEP NIC (VLAN 4)와 비교: NSX에서 할당한 vmk10 IP 주소를 새 호스트 (esxi-h7, esxi-h8, esxi-h9)의 VLAN 4 Dynamic NIC IP 주소와 비교합니다. 새 호스트만 범위에 포함됩니다. 다른 클러스터에 있는 호스트의 TEP NIC는 수정하지 마세요.

일치하지 않는 TEP NIC 다시 만들기: 일치하지 않는 모든 새 호스트의 경우 먼저 TEP NEG에서 각 호스트를 분리하고 일치하지 않는 모든 호스트에서 nic0.4 인터페이스를 삭제합니다. 그런 다음 nic0.4 인터페이스를 다시 추가하고 호스트를 TEP NEG에 다시 연결합니다.

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

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

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

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

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

클러스터 배포 확인

클러스터 생성 태스크가 완료되고 모든 Dynamic NIC를 정렬한 후 다음을 확인합니다.

vCenter Server (vc01 또는 vc02): cl02 클러스터와 세 호스트 모두 연결되어 있고 네트워크 알람 없이 정상 상태입니다.
vSAN: cl02 클러스터의 경우 모니터링 > vSAN > Skyline Health로 이동하여 모든 상태 점검이 통과되고 vSAN 데이터 스토어에 세 호스트 모두의 결합된 용량이 표시되는지 확인합니다.
NSX Manager: 시스템 > 패브릭 > 호스트로 이동하여 각 새 호스트에 성공 및 작동이 표시되고 모든 오버레이 터널이 작동하는지 확인합니다.
VCF 작업: 대상 도메인에서 클러스터 상태가 활성이고 태스크 목록에 실패한 태스크가 표시되지 않습니다.
기존 클러스터: 도메인의 다른 모든 클러스터는 정상 상태로 유지됩니다.
선택사항: 기존 클러스터와 cl02 클러스터 간, 그리고 cl02 클러스터 내 호스트 간에 vMotion을 사용하여 테스트 VM을 마이그레이션합니다.

ESXi 호스트 셸 (예: esxi-h7)에서 vMotion, vSAN, NSX TEP 인터페이스 전반의 점보 프레임 연결 (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.22          # vMotion
vmkping -I vmk2 -d -s 8868 192.168.3.22                     # vSAN
vmkping ++netstack=vxlan -I vmk10 -d -s 8868 192.168.4.22   # NSX TEP

(선택사항) 허용할 vSAN 장애 구성

vSAN ESA의 경우 VCF는 클러스터 유형 및 호스트 수에 따라 기본 Datastore 스토리지 정책을 만들고 할당합니다. FTT 설정을 명시적으로 구성하려면 클러스터 호스트 수에서 지원하는 정책을 선택합니다.

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

대상 도메인의 vCenter Server (vc01 또는 vc02)의 vSphere 클라이언트에서 기본 스토리지 정책을 설정하려면 다음을 수행합니다.

vSAN이 커스텀 기본 정책을 덮어쓰지 않도록 vSAN ESA 클러스터의 자동 정책 관리를 비활성화합니다.
정책 및 프로필 > VM 스토리지 정책 > 만들기로 이동하여 vSAN 스토리지 규칙을 사용 설정하고 가용성 섹션에서 허용되는 실패를 선택합니다 (예: 호스트 3~4개의 경우 1 실패 - RAID-1 (미러링), 호스트 6개 이상의 경우 2 실패 - RAID-6 (삭제 코딩)).
새 정책을 데이터 스토어 기본값으로 설정합니다. cl02 vSAN 데이터 스토어를 선택하고 구성 > 일반 > 기본 스토리지 정책 > 수정으로 이동하여 새 정책을 선택합니다.
기존 VM에 정책을 적용합니다 (VM 정책 > VM 스토리지 정책 수정). 모니터링 > vSAN > cl02 클러스터의 가상 객체로 이동하여 규정 준수를 확인합니다.

클러스터 생성 문제 해결

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

문제	원인	해결 방법
vSAN 및 vMotion 연결 유효성 검사 실패, 새 호스트가 비정상으로 보고됨	클러스터를 만들거나 확장할 때 SDDC Manager는 호스트 순서를 유지하지 않고 네트워크 풀에서 `vmk1` 및 `vmk2` IP 주소를 할당합니다.	검증을 사용 설정된 상태로 유지합니다. Compute Engine NIC IP 주소와 일치하는 전용 네트워크 풀을 만들고, 배포 전 정렬을 확인하고, 연결 확인에서 태스크가 일시중지되면 Dynamic NIC를 정렬하고 태스크를 다시 시도합니다.
클러스터를 추가한 후 NSX 호스트 상태가 `Degraded`이거나 터널이 다운됨	NSX Manager는 IP 풀에서 TEP (`vmk10`) IP 주소를 무작위로 할당하므로 Compute Engine TEP NIC와 일치하지 않을 수 있습니다. Dynamic NIC 서브넷은 DHCP를 지원하지 않습니다.	Compute Engine TEP IP 주소와 일치하는 전용 TEP IP 풀을 사용하고 NSX 호스트 준비 후 TEP Dynamic NIC를 정렬합니다.
BFD가 작동하는 동안 `NSX_VDL2` 에이전트 또는 호스트가 `Degraded`를 보고함	NSX TEP IP 풀에 게이트웨이 IP 주소가 누락되었습니다.	TEP IP 풀에서 서브넷 게이트웨이 (`192.168.4.1`)를 구성합니다.
Dynamic NIC를 다시 추가할 때 `IP_IN_USE` 오류 발생	두 호스트가 IP 주소를 교환했거나 계획된 IP 주소가 다른 클러스터와 겹칩니다.	인터페이스를 다시 추가하기 전에 먼저 모든 호스트에서 일치하지 않는 Dynamic NIC를 모두 삭제하고 IP 계획이 기존 클러스터와 겹치지 않는지 확인하세요.
NSX 가상 스위치 모드는 지원되지 않음	VCF 9.x에서 기본 NSX 가상 스위치 모드는 Enhanced Datapath Standard이며, VMware 솔루션 호스트는 이를 지원하지 않습니다.	NSX Manager에서 구성된 기본 가상 스위치 모드 적용을 선택 해제하고 작동 모드를 표준 (또는 API 사양의 `"hostSwitchOperationalMode": "STANDARD"`)으로 설정합니다. 자세한 내용은 NSX 가상 스위치 모드를 참조하세요.
호스트가 서브넷 게이트웨이 (`.1`)를 핑할 수 없음	Google Cloud 은 서브넷 게이트웨이 IP 주소의 ICMP 에코 요청에 응답하지 않습니다.	예상되는 동작입니다. 게이트웨이 핑 경고를 무시하세요.
시간 동기화 (NTP) 구성	베어메탈 호스트는 시간 동기화를 위해 Compute Engine 메타데이터 서버를 사용합니다.	메타데이터 서버 IP 주소 (`169.254.169.254`)를 NTP 서버로 직접 사용합니다.
호스트 지문 또는 인증서에 내부 이름이 표시됨	DNS 검색 도메인이 호스트에 설정되어 있지 않거나 호스트 이름에 후행 점이 있습니다.	`esxcli network ip dns search add -d vmware.gve` 명령어를 실행하고 `/var/lib/vmware/osdata/init.sh` 스크립트를 다시 실행한 후 `/sbin/generate-certificates` 명령어를 실행하고 `rhttpproxy` 및 `hostd` 서비스를 다시 시작합니다.
호스트 커미셔닝 실패	시작 서비스에서 변환하지 않았으므로 `vmk0` VMkernel 어댑터는 여전히 DHCP를 사용합니다.	`esxcli network ip interface ipv4 get -i vmk0` 명령어를 실행합니다. 유형이 `DHCP`인 경우 수동으로 정적으로 설정합니다 (예: `esxi-h7`: `esxcli network ip interface ipv4 set -i vmk0 -t static -I 192.168.0.161 -N 255.255.255.0 -g 192.168.0.1`).
vSAN 복제 오류, vMotion 시간 초과 또는 NSX 오버레이 단편화	VCF는 VDS, VMkernel 어댑터, NSX 프로필을 MTU `9000`바이트로 기본 설정하고 VPC 네트워크는 `8896`바이트보다 큰 프레임을 삭제합니다.	VDS, 네트워크 풀 (vMotion 및 vSAN), NSX 업링크 프로필에서 MTU를 `8896`바이트로 구성합니다. 자세한 내용은 VDS MTU 불일치를 참조하세요.
마법사에서 오버레이 포트 그룹의 VLAN ID를 입력하라는 메시지가 표시됨	기본 VDS 프로필에는 NSX 호스트 오버레이 VLAN ID가 필요합니다.	기존 NSX 구성의 TEP VLAN ID를 입력합니다 (이 가이드에서는 `4`).
새 클러스터에 워크로드 VM의 포트 그룹이 없음	기본 VDS 프로필은 인프라 포트 그룹만 만듭니다.	클러스터를 만든 후 워크로드 VM의 분산 포트 그룹을 만들거나 커스텀 스위치 구성을 사용합니다.
선택한 vLCM 이미지로 호스트를 추가할 수 없음	클러스터의 vLCM 이미지가 호스트에 설치된 ESXi 빌드와 다릅니다.	기존 클러스터에서 사용하는 것과 동일한 ESXi 이미지 계열을 사용하거나 새 호스트 중 하나에서 이미지를 추출합니다.

다음 단계

vSphere 클러스터에서 노드 추가 또는 삭제에서 기존 클러스터 확장 또는 축소
노드 용량 관리의 Google Cloud 콘솔에서 베어메탈 노드 용량을 관리합니다.
vSphere 클러스터 정보에서 클러스터 크기 및 아키텍처 가이드라인을 검토합니다.
알려진 문제에서 일반적인 배포 및 운영 해결 방법을 검토합니다.
Dynamic NIC 및 베어메탈 인스턴스에 대해 자세히 알아보세요.