Google は AI 技術を使用して、コンテンツをご希望の言語に翻訳しています。AI 翻訳には誤りが含まれる場合があります。

vSphere クラスタにノードを追加または削除する

このドキュメントでは、VMware solution on Google Cloudの VMware Cloud Foundation（VCF）9.1 で、1 つ以上の Compute Engine ベアメタルノードを既存の vSphere クラスタに追加する（クラスタ拡張）方法と、クラスタから 1 つ以上のノードを削除する（クラスタ圧縮）方法について説明します。管理ドメインまたは VI ワークロードドメイン内の既存のクラスタのコンピューティング容量と vSAN ストレージ容量を増減する必要がある場合は、クラスタを拡張または圧縮します。単一のノードまたは複数のノードを追加または削除する場合も、同じ手順が適用されます。ADD_HOSTS または REMOVE_HOSTS 環境変数に 1 つ以上のノードをリストします。

アーキテクチャの概要

既存の vSphere クラスタにノードを追加または削除する場合、ワークフローは次のアーキテクチャを使用します。

ノードの追加: 新しいノードは、クラスタの既存のノードと同じゾーン、プレースメントポリシー、マシンタイプにデプロイする z3-highmem-192-highlssd-metal ベアメタルインスタンスです。各ノードには、Virtual Private Cloud（VPC）ネットワークの ESXi 管理サブネットにプライマリネットワークインターフェース（nic0）があり、vMotion、vSAN、NSX トンネルエンドポイント（TEP）に VLAN のタグ付けされた Dynamic Network Interface があります。ノードは、既存のゾーンネットワークエンドポイントグループ（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）ポリシー、管理アプライアンスの転送ルールは必要ありません。

始める前に

ノードを追加または削除する前に、次のセクションの要件を確認し、環境変数を構成します。

環境要件を確認する

環境が次の要件を満たしていることを確認します。

権限: ターゲットプロジェクトに必要な Identity and Access Management（IAM）ロール（Compute 管理者（roles/compute.admin）、DNS 管理者（roles/dns.admin）、Secret Manager のシークレットアクセサー（roles/secretmanager.secretAccessor）など）が付与されている。
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）を使用し、クラスタの既存のプレースメントポリシーに割り当てられます（各プレースメントポリシーは 1 つのクラスタにのみ属します）。
- 各新しいノードには、既存のパーティションのない NVMe ローカル SSD デバイスがあります。
- 組織で constraints/compute.trustedImageProjects 組織ポリシーが適用されている場合、または VPC Service Controls サービス境界を使用している場合は、プロジェクトで 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 つの許容障害数（FTT=1）を持つ vSAN の最小値）またはアクティブなストレージポリシー要件に必要な最小ホスト数が保持されます（vSAN の許容障害数とホスト数をご覧ください）。
ジャンプボックス VM: gcloud CLI、curl、jq がインストールされ、VPC ネットワーク（bm-gcp-demo サブネットなど）へのネットワーク接続があるジャンプボックス VM にアクセスできます。

環境パラメータの例を確認する

このドキュメントのコマンドでは、次のサンプルパラメータを使用します。

入力パラメータ	値の例	説明
プロジェクト 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`	既存の管理 NEG と NSX TEP NEG
SDDC Manager	`sddcm.vmware.gve`（`192.168.0.3`）	既存の SDDC Manager アプライアンス
ESXi `root` パスワード	`esxi-root-password`	ESXi `root` パスワードを保持する既存の Secret Manager シークレット

IP アドレスとホスト名を計画する

次の例では、2 つのノード（esxi-h10 と esxi-h11）を cl02 クラスタに追加し、そのうちの 1 つ（esxi-h11）を削除します。1 つのノードを追加または削除するには、環境変数配列にそのノードのみを含めます。

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 ノードクラスタに必要なリソース
`compute.googleapis.com/cpus_per_vm_family`（`Z3`）	192 vCPU	3 × 192 = 576 vCPU
`compute.googleapis.com/local_ssd_total_storage_per_vm_family`（`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	クラスタごとに 1 つのスプレッドプレースメントポリシー
`compute.googleapis.com/regional_backend_services_protocol_forwarding_fast_ha`	新しいアプライアンスなしでノードまたはクラスタを追加する場合は 0	新しい VCF 管理アプライアンス VIP または NSX Edge エンドポイントごとに 1 つ

必要な割り当ての完全なリストと、割り当ての増加を表示またはリクエストする方法については、割り当てと上限をご覧ください。

環境変数を設定する

ジャンプボックスシェルで次の環境変数を設定します。ADD_HOSTS 環境変数に追加するノードと、REMOVE_HOSTS 環境変数で削除するノードを一覧表示します（それぞれ 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}"          # 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 タグ付き動的 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 root パスワードをリセットする

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

新しい IP アドレスをネットワークプールと TEP プールに追加する

クラスタのネットワークプール（cl02-np01）と NSX TEP プール（cl02-tep-pool）には、最初は既存のクラスタノードの IP アドレスのみが含まれています。新しいノードの正確な Compute Engine Dynamic NIC IP アドレスを両方のプールに追加して、VCF と NSX が Compute Engine NIC にすでに構成されているセットから IP アドレスを割り当てるようにします。

ネットワークプール（vMotion と vSAN）を更新する: VCF Operations または SDDC Manager API を使用して、新しいノードの vMotion と vSAN の IP アドレスを cl02-np01 ネットワークプールに追加します。

VCF Operations

[VCF Operations] で [Network pool management] に移動し、cl02-np01 ネットワークプールを選択して、vMotion ネットワークと vSAN ネットワークを編集し、新しいノードの IP アドレス範囲を追加します。

SDDC Manager API

次のコマンドを実行して、新しいノードごとに 1 つの単一 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 ホスト）で、[Networking] > [IP Address Pools] に移動し、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 Operations

VCF Operations で、[Inventory] > [Hosts] > [Commission Hosts] に移動します。
cl02-np01 ネットワークプールを選択し、vSAN ESA ストレージタイプを選択します。
新しいホストの FQDN と root 認証情報を入力します。
SSL サムプリントを承認し、ホストを検証して、[Commission] をクリックします。

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 Operations

VCF Operations（または 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 の動的 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 の 2 つのコマンドを実行します。新しいノードのみが対象となります。

一致しない 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 Operations で、[フリート管理] に移動します。

タスク] で拡張タスクを再試行するか、次の 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 クラスタの場合は、[Monitor] > [vSAN] > [Skyline Health] に移動し、すべてのヘルスチェックに合格していること、データストアの容量に新しいノードが含まれていることを確認します。
NSX Manager: [System] > [Fabric] > [Hosts] に移動し、新しい各ノードに [Success] と [Up] が表示され、オーバーレイトンネルが稼働していることを確認します。
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 クラスタに対して、削除する各ノード（[Full data migration] オプションを使用）の [Monitor] > [vSAN] > [Data Migration Pre-check] に移動し、残りのノードに十分な 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 Operations

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 Operations

VCF Operations で、[Inventory] > [Hosts] に移動し、未割り当てのノードを選択して、[Decommission] をクリックします（詳細については、VMware Cloud Foundation のドキュメントの「Decommission hosts」をご覧ください）。

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 アドレスを割り当てる）、プールから削除して、Compute Engine NIC が異なる IP アドレスを使用する将来のノードに VCF と NSX が割り当てないようにすることができます。

ノードの削除を確認する

ノード削除ワークフローを完了したら、次の点を確認します。

vCenter Server: cl02 クラスタには、残りのノードのみが表示されます。すべてのノードが接続され、正常な状態です。vSphere HA と DRS はエラーを報告しません。
vSAN: Skyline Health が合格し、すべての仮想オブジェクトが準拠している（cl02 クラスタの場合は、[Monitor] > [vSAN] > [Virtual Objects] に移動します）。
NSX Manager: 削除されたノードはトランスポートノードとして表示されなくなり、残りのノードは Up と表示されます。
VCF Operations と 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`）を再試行します。
ノードがすでにコミッショニングされているため、ノードのコミッショニングに失敗する	ホストを 2 回コミッショニングすることはできません。	クラスタの拡張を続行するか、ノードを再度コミッションする必要がある場合は、まずノードをデコミッションします（たとえば、別のネットワークプールを使用する場合）。
Dynamic NIC を再追加すると `IP_IN_USE` エラーが発生する	2 つのノードの IP アドレスが入れ替わっているか、計画された IP アドレスが別のノードと重複しています。	インターフェースを再度追加する前に、まずすべての新しいノードで不一致の Dynamic NIC をすべて削除し、IP アドレス計画を確認します。
ノード削除の検証が失敗する	ノードを削除すると、クラスタのホスト数が最小サイズを下回るか、残りのノードの容量が不足します。	削除するノード数を減らすか、最初に容量を追加します。`"force": true` プロパティは使用しないでください。
`gcloud` CLI がベアメタルインスタンスの削除を拒否する	インスタンスで削除からの保護が有効になっている。	インスタンスを削除する前に、`gcloud compute instances update HOST --no-deletion-protection` コマンドを実行します。
ノードの追加後に vSAN フォールトドメインが正しくない	別のプレースメントポリシーで新しいノードを作成したか、2 つのクラスタがプレースメントポリシーを共有しています。	クラスタ独自のプレースメントポリシーで新しいノードを作成し、アベイラビリティドメインに分散します。
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`）に ping を実行できない	Google Cloud は、サブネットゲートウェイ IP アドレスの ICMP エコーリクエストに応答しません。	想定される動作。ゲートウェイの ping 警告は無視してください。

次のステップ

ドメインに vSphere クラスタを追加するで、既存のドメインに新しい vSphere クラスタを追加する。
ノード容量を管理するの Google Cloud コンソールで、ベアメタルノードの容量を管理します。
Terraform を使用してノード容量を管理するで、Terraform を使用してノード容量をスケーリングする。
プレースメントポリシーとアベイラビリティドメインでプレースメントポリシーのガイドラインを確認します。
vSphere クラスタについてで、クラスタのサイズ設定とアーキテクチャのガイドラインを確認します。
既知の問題で、一般的なデプロイと運用の回避策を確認する。

vSphere クラスタにノードを追加または削除する

アーキテクチャの概要

始める前に

環境要件を確認する

環境パラメータの例を確認する

IP アドレスとホスト名を計画する

リージョンの割り当てを確認する

環境変数を設定する

クラスタにノードを追加する

DNS レコードを作成する

ベアメタル インスタンスを作成する

NEG メンバーシップを更新する

ESXi root パスワードをリセットする

新しい IP アドレスをネットワーク プールと TEP プールに追加する

VCF Operations

SDDC Manager API

ノードをコミッショニングする

VCF Operations

SDDC Manager API

前置拡張 IP の整合性を確認する

クラスタを拡張する

VCF Operations

SDDC Manager API

vMotion と vSAN の Dynamic NIC を調整する

NSX TEP Dynamic NIC を調整する

クラスタの拡張を確認する

vSAN の許容障害数とホスト数

クラスタからノードを削除する

削除前のチェックを完了する

クラスタからノードを削除する

VCF Operations

SDDC Manager API

ノードを廃止する

VCF Operations

SDDC Manager API

NEG からノードを削除する

ベアメタル インスタンスを削除する

DNS レコードと IP プールをクリーンアップする

ノードの削除を確認する

クラスタの拡張とノードの削除に関するトラブルシューティング

次のステップ

ベアメタルインスタンスを作成する

新しい IP アドレスをネットワークプールと TEP プールに追加する

ベアメタルインスタンスを削除する