效能注意事項

本頁提供相關指引，說明如何設定 Google Cloud Managed Lustre 環境，以獲得最佳效能。

如要查看各個效能等級的具體成效數據，請參閱「效能等級」。

增加容量後的效能

增加現有執行個體的儲存空間容量，可提高其總處理量和 IOPS 上限，也可能提升中繼資料效能。

隨著新資料寫入並重新分配到額外儲存空間，讀取輸送量效能會逐步提升。寫入處理量效能立即提升。

容量使用率偏高

執行個體的儲存空間用量達到 90% 時，執行個體的效能可能會降低。建議您提高 Managed Lustre 執行個體的容量。擴充前，您可能需要申請更多配額。

如果看到 No space left on device 錯誤，但執行個體顯示剩餘容量，請參閱「No space left on device 錯誤」。

VPC 網路最大傳輸單位 (MTU)

建立 VPC 網路時，將 mtu 值 (最大傳輸單位，或可在這個網路上傳輸的最大 IP 封包大小) 設為允許的最大值 8896，與預設值 1460 個位元組相比，效能最多可提升 10%。

您可以使用下列指令查看網路目前的 MTU 值：

gcloud compute networks describe NETWORK_NAME --format="value(mtu)"

網路建立後，可以更新 MTU 值，但請務必注意以下事項。詳情請參閱「變更網路的 MTU」。

Compute Engine 機器類型

網路處理量可能會受到所選機型影響。一般來說，如要獲得最佳處理量，請採取下列做法：

  • 增加 vCPU 數量。每個執行個體的輸出頻寬上限通常為每個 vCPU 2 Gbps，最高可達機型上限。
  • 選取支援較高輸入和輸出限制的機器系列。舉例來說，採用 Tier_1 網路的 C2 執行個體支援最高 100 Gbps 的輸出頻寬。搭配 Tier_1 網路的 C3 執行個體最高支援 200 Gbps。
  • 使用較大的機型，啟用各個 VM 的 Tier_1 網路效能。
  • 使用 Google Virtual NIC (gVNIC)。 gVNIC 是第 3 代和更新機型的唯一選項。使用 Tier_1 網路時，必須使用 gVNIC。

詳情請參閱「網路頻寬」。

多重 NIC 設定

透過 Lustre 內建的多重通道功能，用戶端可以跨多個網路介面卡 (多 NIC) 條紋化網路流量。這會匯總頻寬，以充分運用高容量 Managed Lustre 執行個體。

如要設定多重 NIC，請務必完成下列步驟：

  • 選取具有多個實體 NIC 的機型。
  • 為每個 NIC 建立子網路，並將每個 NIC 指派給其子網路。
  • 從 Compute Engine 或 GKE 連線時，請按照多重 NIC 的步驟操作。

驗證流量平衡

設定多重 NIC 後，請確認資料是否正確平衡。

Compute Engine

直接在 VM 上監控已設定的網路介面 (例如 eth0 和 eth1)，並使用 nload 產生前往 Managed Lustre 後端的流量，藉此驗證資料平衡：

nload -m eth0 eth1

如果多重 NIC 設定成功，所有設定介面的傳出位元率應大致相同。

GKE

部署暫時的網路偵錯 Pod 到排定工作負載的節點，確認工作負載的網路流量已在多個 NIC 之間平衡分配：

  1. 找出排定工作負載的節點：

    kubectl get pod POD_NAME -o wide

    將 POD_NAME 替換為 Pod 的名稱。在指令輸出中，記下 NODE 欄中的名稱。

  2. 在該節點上啟動網路偵錯工具：

    kubectl run multi-nic-debug --rm -i --tty --image=nicolaka/netshoot \
  --overrides='{"spec": {"hostNetwork": true, "nodeSelector": {"kubernetes.io/hostname": "NODE_NAME"}, "tolerations": [{"key": "nvidia.com/gpu", "operator": "Exists", "effect": "NoSchedule"}]}}' \
  -- /bin/bash -c "apk update && apk add nload && nload -m eth0 eth1"

    將 NODE_NAME 替換為上一步的節點名稱。

  3. 在輸出結果中，分析 eth0 和 eth1 的「Outgoing」(傳出)欄位位元率。如果設定成功，位元率大致會相同。輸出結果會與下列內容相似：

    Device eth0 [10.1.0.50] (1/2):
==========================================================================
Incoming:                               Outgoing:
Curr: 1.63 MBit/s                       Curr: 1.46 GBit/s
Avg: 1.60 MBit/s                        Avg: 1.44 GBit/s
Min: 1.40 MBit/s                        Min: 1.25 GBit/s
Max: 1.64 MBit/s                        Max: 1.47 GBit/s
Ttl: 590.94 GByte                       Ttl: 405.19 GByte

Device eth1 [172.16.15.5] (2/2):
==========================================================================
Incoming:                               Outgoing:
Curr: 1.64 MBit/s                       Curr: 1.47 GBit/s
Avg: 1.62 MBit/s                        Avg: 1.44 GBit/s
Min: 1.42 MBit/s                        Min: 1.26 GBit/s
Max: 1.66 MBit/s                        Max: 1.47 GBit/s
Ttl: 587.68 GByte                       Ttl: 406.36 GByte

  4. 按下 Ctrl+C 鍵，結束偵錯工具。

排解常見瓶頸

如果工作負載效能遠低於 Managed Lustre 效能層級的預期值，請檢查下列常見問題：

  • 用戶端電腦數量不足：單一用戶端電腦會受到自身虛擬 CPU (vCPU) 和單一連結網路處理限制的影響，如要充分運用高處理量層級，必須分配負載。舉例來說，如要讓 100,000 MBps 的 Managed Lustre 檔案系統達到飽和，通常需要至少 60 部標準用戶端機器 (或 12 部設定為使用第 1 層高頻寬網路的用戶端機器) 同時寫入資料。如要達到任何效能層級的最大執行個體大小，您可能需要設定超過 2,500 部用戶端機器，才能使用第 1 層高頻寬網路。

  • 不理想的虛擬私有雲 (VPC) MTU： 根據預設，VPC 網路會使用 1460 的 MTU (標準乙太網路框架)。如果是 Managed Lustre 等高效能儲存空間，您必須設定巨型封包，MTU 為 8896。以標準 1460 MTU 執行時，CPU 必須處理的網路封包數量會超過一倍，增加 CPU 負荷並限制最大頻寬。

  • 缺少 Tier 1 網路頻寬設定： 許多高效能機型需要您明確選擇加入 Tier 1 網路頻寬。

    • 在 Compute Engine 和 GKE Standard 節點集區中，請在建立時使用 --network-performance-configs=total-egress-bandwidth-tier=TIER_1 旗標。如果沒有這個標記，VM 或節點的預設輸出上限可能會較低。
    • 在 GKE Autopilot 中，您不會直接指定這個標記。請改為在 Pod 規格中使用節點選取器，選取支援更高頻寬的機器系列 (例如 c3)。

    詳情請參閱 Compute Engine 機器類型。

  • Lustre 物件儲存目標 (OST) 使用量不平衡： Managed Lustre 會將檔案資料分割到多個物件儲存目標 (OST)。如果測試或工作負載寫入單一未經條紋處理的檔案，或是用戶端工作寫入的模式會導致單一 OST 過載，該 OST 就會成為瓶頸，而檔案系統的其餘部分則會閒置。為避免這種情況，請確保在所有可用的 OST 中平均分配寫入酬載 (例如，在基準測試中使用每個程序一個檔案的模式)。

  • 共用網路頻寬爭用： 用戶端機器 (Compute Engine VM 或 GKE 節點) 的輸出頻寬會由機器上的所有網路作業共用。如果用戶端機器或 Pod 同時下載大型套件、執行大量記錄掃描，或與其他叢集節點大量通訊，儲存空間效能就會受到剩餘網路頻寬限制。