已知問題

本頁列出在 Google Cloud的 VMware 解決方案中，部署及操作 VMware Cloud Foundation (VCF) 的已知問題和解決方法。

部署 VCF 期間的 ESX 主機 vSAN HCL 相容性

部署 VCF 管理網域時，如果將執行 VCF 安裝程式的節點納入管理網域，則執行 VCF 安裝程式的節點會無法通過 ESXi HCL 相容性檢查。這是 VCF 9.x 的已知問題。為確保檢查通過，請使用下列任一方法，在 VCF 安裝程式中啟用「Allow auto claim of HCL incompatible disks」(允許自動宣告與 HCL 不相容的磁碟)：

  • Terraform 和工具包：如果您使用 Terraform 和工具包部署節點和 VCF，系統會自動在部署設定 JSON 檔案中，將 skipHclAutoDiskClaim 選項設為 true。
  • VCF 安裝程式 UI：如果使用部署精靈，請在 「Deploy VMware Cloud Foundation」(部署 VMware Cloud Foundation) >「Plan」(方案) >「Storage」(儲存空間) 選項頁面的 「vSAN architecture」(vSAN 架構) 區段下方，選取 「Allow auto claim of HCL incompatible disks」(允許自動宣告與 HCL 不相容的磁碟)。

部署 VCF 時，主機 vMotion 和 vSAN IP 位址不符

部署 VCF 管理網域時，VCF 安裝程式會依數字遞增順序排序 vMotion 和 vSAN IP 位址集區，並按照 ESXi 主機在 hostSpecs 陣列中顯示的順序，依序指派 IP 位址。建立 VI 工作負載網域或擴充叢集時，SDDC Manager 會從設定的 IP 位址集區分配 vMotion 和 vSAN VMkernel IP 位址，不會保留 hostSpecs 主機順序。

由於 Google Cloud 虛擬私有雲網路會對每個裸機節點的 Dynamic NIC 執行嚴格的來源和目的地 IP 檢查，因此 VCF 指派給主機 vmk1 (vMotion) 或 vmk2 (vSAN) 轉接器的 IP 位址，必須與對應 Compute Engine Dynamic NIC (nic0.VLAN_ID) 上設定的 IP 位址相符。如果主機的 Dynamic NIC IP 位址與 VCF 指派的執行階段 IP 位址不符，Hypervisor 會接收或傳輸 IP 位址不符的流量，導致網路驗證或叢集部署失敗。

舉例來說，假設管理網域部署作業有四部主機，並採用下列 Compute Engine Dynamic NIC 分配方式：

主機 FQDN vMotion IP (vmk1) vSAN IP (vmk2) NSX-TEP IP (vmk10)
esxi-h0.40-vmware.gve 10.40.2.2 10.40.3.2 10.40.4.2
esxi-h1.40-vmware.gve 10.40.2.5 10.40.3.5 10.40.4.5
esxi-h2.40-vmware.gve 10.40.2.3 10.40.3.3 10.40.4.3
esxi-h3.40-vmware.gve 10.40.2.4 10.40.3.4 10.40.4.4

如果主機在輸入設定中的排序為 esxi-h0、esxi-h2、esxi-h1、esxi-h3，VCF 安裝程式會排序集區 (10.40.2.2、10.40.2.3、10.40.2.4、10.40.2.5)，並依序將位址對應至 esxi-h0、esxi-h2、esxi-h1 和 esxi-h3。主機 esxi-h1 會從安裝程式接收 10.40.2.4，即使其基礎 Compute Engine Dynamic NIC 預期為 10.40.2.5。

解決方法：視您要部署新的管理網域，還是擴充現有的工作負載網域或叢集，採用下列任一選項。

選項 1：預先排序管理網域部署作業的主機規格

使用 VMware 解決方案工具包 (self-managed-vmware-solution-toolkit) 時，工具包會自動查詢裸機節點的 Dynamic NIC IP 位址，並在 VCF 部署 JSON 檔案中排序 hostSpecs 和 includeIpAddressRanges 陣列。

如果您手動編寫或修改 VCF 部署 JSON 檔案，請調整 hostSpecs 陣列中的項目順序，使其與分配的 Dynamic NIC IP 位址遞增數字排列順序相符 (以上述範例來說：10.40.2.2 對應 esxi-h0.40-vmware.gve、10.40.2.3 對應 esxi-h2.40-vmware.gve、10.40.2.4 對應 esxi-h3.40-vmware.gve，以及 10.40.2.5 對應 esxi-h1.40-vmware.gve)：

  1. 設定 IP 位址集區：視 IP 分配是否連續而定，使用連續範圍或明確 IP 位址指定集區：

    • 連續 IP 範圍：

      "includeIpAddressRanges": [
  {
    "startIpAddress": "10.40.2.2",
    "endIpAddress": "10.40.2.5"
  }
]

    • 不連續的 IP 位址：

      "includeIpAddress": [
  "10.40.2.2",
  "10.40.2.3",
  "10.40.2.4",
  "10.40.2.5"
]

  2. 預先排序 hostSpecs 陣列，讓主機按照分配的 IP 位址遞增排序：

    "hostSpecs": [
  {
    "hostname": "esxi-h0.40-vmware.gve"
  },
  {
    "hostname": "esxi-h2.40-vmware.gve"
  },
  {
    "hostname": "esxi-h3.40-vmware.gve"
  },
  {
    "hostname": "esxi-h1.40-vmware.gve"
  }
]

方法 2：在工作負載網域或叢集擴充期間，重新設定 Dynamic NIC

使用 SDDC Manager 部署 VI 工作負載網域或擴充叢集時，請將 vMotion 和 vSAN Dynamic NIC 與 VCF 指派的執行階段 IP 位址進行協調：

  1. 在 SDDC Manager 和 vCenter Server 中委託裸機 ESXi 主機，並啟動工作負載網域或叢集建立工作流程。允許工作流程在 vSAN 和 vMotion 連線能力驗證階段暫停或失敗。

  2. 使用 SDDC Manager 資料庫或 SDDC Manager REST API，擷取 VCF 分配的執行階段 IP 位址 (或在 vSphere Client 中檢查 VMkernel 轉接器)：

    • VCF 資料庫查詢 (在 SDDC Manager 設備上執行)：

      psql -h localhost -U postgres -d platform -c "select * from host;"

    • SDDC Manager REST API：

      curl -u ADMIN_USER:ADMIN_PASSWORD \
   -X GET https://SDDC_MANAGER_FQDN/v1/hosts

      執行 curl 指令前，請先替換下列項目：

      • ADMIN_USER：SDDC Manager 管理員使用者名稱。
      • ADMIN_PASSWORD：SDDC Manager 管理員密碼。
      • SDDC_MANAGER_FQDN：SDDC Manager 設備的完整網域名稱或 IP 位址。

  3. 請先刪除所有受影響 ESXi 主機上不相符的 Dynamic NIC (nic0.VLAN_ID)。您必須先在所有主機上完成所有 Dynamic NIC 刪除作業，才能重新新增任何介面；否則，如果其他主機仍保留目標 IP 位址，Compute Engine 會拒絕新增介面，並顯示 IP 位址衝突：

    gcloud compute instances network-interfaces delete HOST_INSTANCE_NAME \
   --zone=ZONE \
   --network-interface=nic0.VLAN_ID \
   --project=PROJECT_ID

  4. 從所有主機刪除不相符的 Dynamic NIC 後，請在每部主機上重新新增 Dynamic NIC (nic0.VLAN_ID)，並使用 VCF 指派的確切 IPv4 位址。

    gcloud compute instances network-interfaces add HOST_INSTANCE_NAME \
   --zone=ZONE \
   --parent-nic-name=nic0 \
   --vlan=VLAN_ID \
   --subnetwork=SUBNET_NAME \
   --no-address \
   --private-network-ip=VMWARE_ASSIGNED_IP \
   --project=PROJECT_ID

    執行上述指令前，請先替換下列項目：

    • HOST_INSTANCE_NAME：Compute Engine 中裸機 ESXi 執行個體的名稱。
    • ZONE：裸機執行個體所在的可用區。
    • VLAN_ID：對應至 Dynamic NIC 的 VLAN ID (例如 vSAN 的 2 或 vMotion 的 3)，會形成介面名稱 nic0.VLAN_ID。
    • SUBNET_NAME：vSAN 或 vMotion 子網路的名稱。
    • VMWARE_ASSIGNED_IP：IPv4 位址或現有的預留內部 IP 位址資源名稱，與 VCF 指派給主機 VMkernel 轉接器的 IP 位址相符。
    • PROJECT_ID： Google Cloud 專案的 ID。

  5. 在 SDDC Manager 中繼續並完成叢集部署工作。

主機上的 NSX-TEP IP 位址不相符

在 NSX 傳輸節點準備期間，NSX Manager 會從設定的 NSX IP 集區分配傳輸端點 (TEP) IP 位址 (vmk10 或 vmk3) ( Google Cloud VPC 子網路不支援 Dynamic NIC 的 DHCP)。由於 NSX Manager 會隨機從集區指派 IP 位址，因此在 ESXi 主機 vmk10 轉接器上設定的 TEP IP 位址，可能與最初在主機 NSX-TEP Dynamic NIC (nic0.TEP_VLAN_ID) 上預先分配的 IP 位址不符。

解決方法：NSX 傳輸節點設定完成後，請更新主機上的 NSX-TEP Dynamic NIC，以符合 NSX 指派的 TEP IP 位址：

  1. 在 NSX Manager UI (在 VCF 9.1 中，依序前往「System」(系統) >「Fabric」(網狀架構) >「Hosts」(主機)) 或 vSphere Client 中，檢查指派給各 ESXi 主機的 TEP IP 位址。

  2. 修改 NSX-TEP 網路介面前，請先從 NSX 網路端點群組 (NEG) 移除所有裸機主機執行個體：

    gcloud compute network-endpoint-groups update NSX_NEG_NAME \
    --zone=ZONE \
    --project=PROJECT_ID \
    --remove-endpoint="instance=HOST_INSTANCE_NAME"

  3. 請先刪除所有受影響主機上的 NSX-TEP Dynamic NIC (nic0.TEP_VLAN_ID)，請先完成所有主機的 NSX-TEP Dynamic NIC 刪除作業，再重新新增任何介面，以免主機之間的 IP 位址發生衝突：

    gcloud compute instances network-interfaces delete HOST_INSTANCE_NAME \
    --zone=ZONE \
    --network-interface=nic0.TEP_VLAN_ID \
    --project=PROJECT_ID

  4. 刪除所有主機上的所有 NSX-TEP Dynamic NIC 後，請使用 NSX Manager 指派的 TEP IPv4 位址，在各主機上重新建立 nic0.TEP_VLAN_ID 介面。

    gcloud compute instances network-interfaces add HOST_INSTANCE_NAME \
    --zone=ZONE \
    --parent-nic-name=nic0 \
    --vlan=TEP_VLAN_ID \
    --subnetwork=TEP_SUBNET_NAME \
    --no-address \
    --private-network-ip=TEP_IP_ADDRESS \
    --project=PROJECT_ID

  5. 將所有裸機主機執行個體重新附加至 NSX NEG：

    gcloud compute network-endpoint-groups update NSX_NEG_NAME \
    --zone=ZONE \
    --project=PROJECT_ID \
    --add-endpoint="instance=HOST_INSTANCE_NAME"

執行上述指令前，請先替換下列項目：

  • NSX_NEG_NAME：NSX 區域性 NEG 的名稱。
  • HOST_INSTANCE_NAME：裸機 ESXi 執行個體的名稱。
  • ZONE：裸機執行個體所在的可用區。
  • TEP_VLAN_ID：指派給 NSX-TEP Dynamic NIC 的 VLAN ID (例如 4)，會形成介面名稱 nic0.TEP_VLAN_ID。
  • TEP_SUBNET_NAME：NSX-TEP 子網路的名稱。
  • TEP_IP_ADDRESS：TEP IPv4 位址或現有的預留內部 IP 位址資源名稱，與 NSX Manager 指派給 ESXi 主機 (vmk10) 的 IP 位址相符。
  • PROJECT_ID： Google Cloud 專案的 ID。

VDS MTU 與 Google Cloud 虛擬私有雲巨型框架不符

Google Cloud 虛擬私有雲網路支援的最大傳輸單位 (MTU) 為 8896 個位元組，適用於巨型框架。根據預設，VCF 會設定 vSphere Distributed Switch (VDS)、VMkernel 轉接器 (vSAN、vMotion 和 NSX-TEP) 和 NSX 傳輸節點設定檔，MTU 為 9000 位元組。如果主機透過虛擬私有雲 underlay 傳送大於 8896 位元組的封包，虛擬私有雲網路會捨棄過大的框架，導致 vSAN 複製錯誤、vMotion 逾時或 NSX overlay 分割問題。

解決方法：在啟動前，將 VCF 部署規格中的 MTU 設為 8896 位元組，或在部署後更新 vCenter Server 和 NSX Manager 中的 MTU 設定：

在 vSphere Client 中更新 VDS MTU

  1. 在 vSphere Client 中，前往「Networking」(網路)，然後選取叢集的 vSphere Distributed Switch。
  2. 在分散式交換器上按一下滑鼠右鍵，然後依序選取「Settings」 >「Edit Settings」。
  3. 按一下「Advanced」分頁標籤，將「MTU (Bytes)」設為 8896，然後按一下「OK」。

更新 VMkernel 轉接器和 NSX 設定檔

  1. 針對叢集中的每個 ESXi 主機，依序前往「Configure」(設定) >「Networking」(網路) >「VMkernel adapters」(VMkernel 轉接器)，編輯 vMotion (vmk1) 和 vSAN (vmk2) 轉接器，然後將「MTU」設為 8896。
  2. 在 NSX Manager UI 中，依序前往「System」(系統) >「Fabric」(網狀架構) >「Profiles」(設定檔) >「Uplink Profiles」(上行連結設定檔)，編輯有效的主機和邊緣上行連結設定檔，並將「MTU」設為 8896 (並依序前往「System」(系統) >「Fabric」(網狀架構) >「Settings」(設定) >「Global Fabric Settings」(全域網狀架構設定)，將全域實體網狀架構 MTU 設為 8896)。

NSX 虛擬交換器模式

在 VCF 9.x 中，NSX Manager 設定的預設虛擬交換器模式為「Enhanced Datapath Standard」(增強型資料路徑標準)，VMware 解決方案主機不支援此模式。

解決方法：在 VCF 安裝程式的「NSX」部分，清除「Apply the default virtual switch mode configured in NSX Manager」核取方塊，然後在「Operational Mode」部分選取「Standard」，如下方螢幕截圖所示 (點選可放大)：

NSX 設定，顯示已取消勾選預設虛擬交換器模式核取方塊，且作業模式設為「標準」。 NSX 設定，顯示已取消勾選預設虛擬交換器模式核取方塊，且作業模式設為「標準」。

在第 2 層廣播子網路上，Cloud DNS 傳入轉送的 DNS 解析失敗

在託管 VMware 解決方案節點的虛擬私有雲網路，啟用 Cloud DNS 傳入伺服器政策時，Cloud DNS 會自動在虛擬私有雲網路的各個區域子網路，保留一個內部 DNS_RESOLVER IP 位址。這包括未標記的 ESXi 管理 (MGMT) 子網路，以及使用第 2 層位址解析通訊協定 (ARP) 廣播和自訂 MAC 學習 (ARP_BROADCAST_PRIMARY_RANGE_WITH_LEARNING) 的 VLAN 標記動態 NIC 子網路 (vSAN、vMotion 和 NSX-TEP)。

如果您將 ESXi 主機或 VCF 管理設備，設為從相同子網路 (或已啟用 ARP 廣播和 MAC 學習功能的任何節點子網路) 查詢 DNS_RESOLVER IP 位址，主機會將轉送站 IP 位址視為本機第 2 層鄰近節點，並傳送 ARP 廣播要求來解析其 MAC 位址。Cloud DNS 傳入轉送站是Google Cloud Proxy 服務，而非子網路上的第 2 層端點，因此不會回應 ARP 要求，也不會參與自訂 MAC 學習。因此，鄰近項目仍不完整 (esxcli network ip neighbor list)，且 DNS 查詢 (nslookup) 逾時。

Private Service Connect (PSC) 端點 (GCE_ENDPOINT) 也適用相同行為，例如用於連線至區域離線存放區的端點。如果您在第 2 層 ARP 廣播或 VLAN 標記節點子網路中部署 Private Service Connect 端點，端點 IP 位址的 ARP 解析作業會失敗，且與離線存放區的連線會逾時。

解決方法：針對 Cloud DNS 傳入 DNS_RESOLVER IP 位址 (以及 Private Service Connect 離線存放區端點)，使用相同區域和虛擬私有雲網路中的現有標準 (非 VLAN、非第 2 層廣播) 子網路，或建立專屬標準子網路 (如果尚未建立)。如果該區域已有標準子網路，Cloud DNS 會在該子網路中分配 DNS_RESOLVER IP 位址供您使用：

  1. 如果相同區域和虛擬私有雲網路中沒有標準子網路，請建立專屬標準子網路，不要指定 --resolve-subnet-mask 旗標。請勿將這個子網路連結至節點主要介面或 VLAN 標記的 Dynamic NIC：

    gcloud compute networks subnets create DNS_SUBNET_NAME \
    --network=VPC_NAME \
    --region=REGION \
    --range=DNS_SUBNET_RANGE \
    --project=PROJECT_ID

  2. 擷取 Cloud DNS 在標準子網路中保留的 DNS_RESOLVER IP 位址：

    gcloud compute addresses list \
    --filter="purpose=DNS_RESOLVER AND subnetwork:DNS_SUBNET_NAME" \
    --project=PROJECT_ID

    執行上述指令前，請先替換下列項目：

    • DNS_SUBNET_NAME：Cloud DNS 傳入轉送作業的現有或專用標準子網路名稱。
    • VPC_NAME：虛擬私有雲網路的名稱。
    • REGION：裸機節點所在的 Google Cloud 區域。
    • DNS_SUBNET_RANGE：專用標準子網路的主要 IPv4 CIDR 範圍，不得重疊 (例如 10.0.100.0/28)。
    • PROJECT_ID： Google Cloud專案的 ID。

  3. 設定 ESXi 主機、VCF 管理設備和 VMware 解決方案工具包 (config.json 中的 dns_server)，使用 DNS_SUBNET_NAME 的 DNS_RESOLVER IP 位址，而非與 ESXi 管理 (MGMT)、vSAN、vMotion 或 NSX-TEP 子網路相關聯的 DNS_RESOLVER IP 位址。