叢集復原能力

如要使用 Gemini Enterprise Agent Platform 訓練叢集，請與業務代表聯絡以取得存取權。

Gemini Enterprise Agent Platform 訓練叢集整合了完整的健康狀態檢查系統，可確保運算節點的可靠性，以及 Slurm 工作的穩定性。這個系統提供自動和手動救援選項。作業執行期間會執行自動化程序，監控 GPU 健康狀態和磁碟用量等重要元件，並自動更換故障的節點。如果需要使用者介入，訓練叢集會提供 reportFaultyNodes API，讓您手動刪除特定故障節點，或回報基礎主機上疑似發生的硬體故障。

執行測試工作負載，驗證 GPU 功能

步驟 1：使用 SSH 連線至叢集節點

從 Cloud Shell 或 Cloud de Confiance 控制台，使用 IAP 連線至登入節點。以下範例顯示 Cloud Shell 的指令：

gcloud compute ssh --zone $ZONE "Login Node Name" --tunnel-through-iap --project $PROJECT_ID

步驟 2：執行標準 Slurm 指令

連線至登入節點後，請執行幾個標準 Slurm 指令，確認叢集運作正常。

~$ sinfo
PARTITION   AVAIL  TIMELIMIT  NODES  STATE NODELIST
partition1*    up   infinite      2   idle hcsa3m1236-a3mnodeset-[0-1]

接著，提交批次工作。

~$ sbatch --qos normal --wrap "echo start! && sleep 10s && echo done!"

您應該會看到主目錄中建立了 slurm-job-id.out 檔案。

步驟 3：執行 GPU 工作負載

將下列內容儲存為名為 test.sh 的指令碼檔案，並放在主目錄中。

#!/bin/bash
#SBATCH --nodes=2
#SBATCH --ntasks-per-node=1
#SBATCH --cpus-per-task=4
#SBATCH --gres=gpu:8
#SBATCH --job-name=nvidia_smi

srun nvidia-smi -L

將指令碼的權限設為 755，使其可執行，然後提交 Slurm 工作：

~$ sbatch ./test.sh

Slurm 會將指令碼的輸出內容儲存至名為 slurm-job-id.out 的檔案。

預期輸出內容：

GPU 0: NVIDIA H100 80GB HBM3 (UUID: GPU-f75045e8-4d87-49d1-2eb9-39ec2baddf9b)
GPU 1: NVIDIA H100 80GB HBM3 (UUID: GPU-b91556d8-5215-d0ed-50b8-a88720e5b29c)
GPU 2: NVIDIA H100 80GB HBM3 (UUID: GPU-7600155a-0036-35f5-9489-a7b4ed0ce887)
GPU 3: NVIDIA H100 80GB HBM3 (UUID: GPU-a402e125-7841-033f-f08b-7921526c121f)
GPU 4: NVIDIA H100 80GB HBM3 (UUID: GPU-20eef8f8-b2c7-1716-5ce7-7f64475bd2c0)
GPU 5: NVIDIA H100 80GB HBM3 (UUID: GPU-65463286-e587-b52f-4d5b-8880eecbf0e7)
GPU 6: NVIDIA H100 80GB HBM3 (UUID: GPU-d5ff75e7-dd54-edf6-a684-33c26fc365e1)
GPU 7: NVIDIA H100 80GB HBM3 (UUID: GPU-26e81ae2-11fd-9d7e-95b6-c186e5173007)
GPU 0: NVIDIA H100 80GB HBM3 (UUID: GPU-e66a185a-b40c-81d9-d35d-19cab811df34)
GPU 1: NVIDIA H100 80GB HBM3 (UUID: GPU-d23e5cf7-afd8-bec2-1487-9e27eeb6aae0)
GPU 2: NVIDIA H100 80GB HBM3 (UUID: GPU-4dde1b05-ea5e-01e9-5c1e-e1c0d3b4b113)
GPU 3: NVIDIA H100 80GB HBM3 (UUID: GPU-3a0d734a-6fb8-d841-a97f-d6846553ea7f)
GPU 4: NVIDIA H100 80GB HBM3 (UUID: GPU-76fe0d37-08b2-a3a6-8ddf-55501426bc7c)
GPU 5: NVIDIA H100 80GB HBM3 (UUID: GPU-9e0a41e1-b399-8934-01af-6198b749c02a)
GPU 6: NVIDIA H100 80GB HBM3 (UUID: GPU-dddd09ee-c944-1098-9c4e-d96f8762ecb1)
GPU 7: NVIDIA H100 80GB HBM3 (UUID: GPU-df52c109-0ac1-30cc-226b-85b1a8a6bc16)

自動執行健康狀態檢查和復原

為確保節點可靠性，訓練叢集會使用下列自動檢查套件，持續監控節點健康狀態。訓練叢集會在 Slurm 前言 (工作開始前) 和後記 (工作完成後) 期間執行健康狀態檢查。

健康檢查套件

  • GPU 健康狀態：執行詳細的個別 GPU 診斷，包括 nvidia-smi、dcgmi 和 xid 程式碼監控。
  • 磁碟用量：檢查重要分割區的磁碟用量是否過高 (/、/mnt/localssd、/mnt/localdisk)，避免作業因空間不足而失敗。
  • 網路健康狀態：確認主要網路介面是否具有 IPv4 位址。 如果發現問題，系統會嘗試重設介面，藉此自我修復。
  • CPU 負載：監控系統的平均負載，如果超過預先定義的門檻，就會記錄警告。

故障復原程序

如果檢查偵測到嚴重且無法復原的錯誤，Gemini Enterprise Agent Platform 訓練叢集會自動啟動失敗復原程序。標準程序包括排空故障節點、重新排隊受影響的 Slurm 工作，然後刪除並重新建立排空的節點，將其還原為正常狀態。

自動復原功能須符合下列條件：

  • 重新啟動次數上限：如果受影響的 Slurm 工作已重新啟動設定次數，系統會略過復原程序。

  • GPU 使用率：如果節點上執行的工作未使用所有可用的 GPU，系統也會略過節點刪除和重新建立作業。在這種情況下，節點只會排空，避免在節點上安排新工作。

每個復原動作都會記錄在專案記錄中，做為復原事件。如要根據節點的 Slurm 狀態繪製這些事件的圖表，請參閱「使用資訊主頁監控復原事件」。

手動管理故障的運算節點

訓練叢集提供 API，可手動回報及管理有問題的運算節點，如果自動健康狀態檢查無法解決問題，這項功能就特別實用。一次只能對一個節點執行這些作業。

動作 說明 適用情境
刪除節點 從叢集中移除指定的故障節點。這是預設動作。 一般錯誤，或節點沒有回應且需要回收時。
回報主機故障 回報基礎實體主機故障，觸發修復或遷移程序。 託管 GPU 節點的實體機器疑似發生硬體故障。

動作 1：刪除有問題的節點

這項操作會刪除指定的節點。這項作業的結果取決於節點是否由 Slurm 分類為「靜態」或「動態」：

  • 靜態節點：如果已刪除節點的索引小於節點集區的節點數量下限，系統會重新建立同名且規格相同的新運算節點。

  • 動態節點：如果已刪除節點的索引大於節點數量下限，只有在有待處理的工作負載排定要使用該節點時，系統才會重新建立節點。不然的話，則會遭到移除。

這些範例使用 gcurl 別名，這是與 API 端點互動的便利驗證捷徑。下列指令會為 curl 建立別名，其中包含必要的授權標頭。

alias gcurl='curl -H "Authorization: Bearer $(gcloud auth print-access-token)" -H "Content-Type: application/json"'

刪除節點的 API 要求

如要刪除故障節點，請執行下列 POST 要求。NODE_ID 的格式應為 CLUSTER_ID-NODEPOOL_ID-INDEX。

  gcurl -X POST https://REGION-aiplatform.googleapis.com/v1beta1/projects/PROJECT_ID/locations/REGION/modelDevelopmentClusters/CLUSTER_ID:reportFaultyNodes -d '{"nodeActions": [{"nodeId": "NODE_ID"}]}'

檢查作業狀態
您可以查看作業狀態，監控 reportFaultyNodes 動作的結果。

  gcurl https://REGION-aiplatform.googleapis.com/v1/projects/PROJECT_ID/locations/REGION/operations/OPERATION_ID

動作 2：回報主機錯誤

如果懷疑 GPU 節點的實體主機發生硬體故障，可以回報該主機有問題。

  • 支援的 VM：A3 Ultra 和 A4 High-GPU

  • 節點狀態：呼叫 API 前，目標節點必須處於 RUNNING 狀態。呼叫成功後，系統會轉換為 REPAIRING，並在主機修復或節點在新主機上重建後，返回 RUNNING。這項作業會盡可能完成。

必要條件：授予 IAM 角色

如要使用這項功能，請將 Compute 執行個體管理員 (v1) (roles/compute.instanceAdmin.v1) 角色授予 Agent Platform 服務代理程式。

  PROJECT_NUMBER=$(gcloud projects describe PROJECT_ID --format="value(projectNumber)")

  gcloud projects add-iam-policy-binding PROJECT_ID\
  --member="serviceAccount:service-PROJECT_NUMBER@gcp-sa-aiplatform.iam.s3ns-system.iam.gserviceaccount.com" \
  --role="roles/compute.instanceAdmin.v1"

透過 API 要求檢舉主機

執行下列 POST 要求，將基礎主機回報為有錯誤。這麼做時，您必須提供一或多項觀察到的行為和說明 faultReasons。
請在 behavior 欄位中使用下列其中一個值：

行為 說明
PERFORMANCE 與叢集中的其他 GPU 相比，附加至 VM 的 GPU 有效能問題，但您在記錄中看不到 XID 錯誤，且 Compute Engine 未偵測到其他常見的故障模式，例如無聲資料損毀。
SILENT_DATA_CORRUPTION 您發現 VM 中的資料已損毀，但 VM 仍持續執行。這可能是因為 vCPU 缺陷、軟體錯誤或核心問題等所致。
UNRECOVERABLE_GPU_ERROR 您已透過 XID 找出無法復原的 GPU 錯誤。
BEHAVIOR_UNSPECIFIED 您不確定 VM 發生什麼問題。

以下是 API 要求的範例。 

gcurl -X POST \
  https://REGION-aiplatform.googleapis.com/v1beta1/projects/PROJECT_ID/locations/REGION/modelDevelopmentClusters/CLUSTER_ID:reportFaultyNodes \
  -d '{"nodeActions": [{"nodeId": "NODE_ID", "reportFaultyHost": {"faultReasons": [{"behavior": "BEHAVIOR_1", "description": "DESCRIPTION_1"}, {"behavior": "BEHAVIOR_2", "description": "DESCRIPTION_2"}]}}]}'

全面整合使用

善用自動健康狀態檢查和本頁詳述的手動控制項，即可維持高彈性的訓練環境。主動管理叢集的健康狀態，刪除有問題的節點或回報硬體問題，確保訓練作業順利完成，並盡可能延長正常運作時間。如遇持續發生或複雜的問題，請務必諮詢 Cloud de Confiance by S3NS 支援團隊，取得深入診斷和協助。

後續步驟

設定訓練叢集的容錯能力，是建構完整且適用於正式環境的 MLOps 工作流程時，不可或缺的步驟。