回報出錯的主機

如果您發現 A4X Max、A4X、A4、A3 Ultra、A3 Mega 和 A3 High (8 個 GPU) 執行個體發生問題，且無法自行解決，可以將主機回報為故障。舉例來說，叢集效能變慢，或是 GPU 溫度持續偏高，都可能是這類問題。

回報主機故障時，Compute Engine 會執行主機維護作業，自動修復運算執行個體。

  • 如果是 A4 和 A3 Ultra 執行個體，當維護作業開始時，Compute Engine 會嘗試將執行個體遷移至其他主機 (如有未使用的預留容量，或執行個體所在區域有可用容量)。將主機回報為有故障，有助於盡量減少工作負載的停機時間。
  • 如果是 A3 Mega 和 A3 High 執行個體，Compute Engine 會停止執行個體、執行必要的主機修復作業，然後在同一部主機上重新啟動執行個體。

本文說明如何回報及修復 Slurm 叢集或其他以運算執行個體為基礎的叢集中的故障主機執行個體。如要在 Google Kubernetes Engine (GKE) 叢集中回報故障主機，請參閱「透過 GKE 回報故障主機」。

限制

回報出錯的主機時，請注意下列限制：

  • 只有在主機上執行的運算執行個體符合下列所有條件時，您才能回報主機故障：

    • 運算執行個體正在執行。

    • 運算執行個體使用 A4X Max、A4X、A4、A3 Ultra、A3 Mega 和 A3 High (8 個 GPU) 機型。

    • 運算執行個體使用取決於預留項目的佈建模式。

  • 如果在 reportHostAsFaulty 作業進行期間刪除運算執行個體，reportHostAsFaulty 作業就會失敗。

  • Google Cloud 會盡力滿足所有回報主機故障的要求。不過，由於容量限制或速率限制，要求不一定都能完成。

事前準備

Select the tab for how you plan to use the samples on this page:

Console

When you use the Google Cloud console to access Google Cloud services and APIs, you don't need to set up authentication.

gcloud

In the Google Cloud console, activate Cloud Shell.

Activate Cloud Shell

At the bottom of the Google Cloud console, a Cloud Shell session starts and displays a command-line prompt. Cloud Shell is a shell environment with the Google Cloud CLI already installed and with values already set for your current project. It can take a few seconds for the session to initialize.

REST

如要在本機開發環境中使用本頁的 REST API 範例，請使用您提供給 gcloud CLI 的憑證。

    Install the Google Cloud CLI. After installation, initialize the Google Cloud CLI by running the following command: 

    gcloud init

    If you're using an external identity provider (IdP), you must first sign in to the gcloud CLI with your federated identity.

詳情請參閱 Google Cloud 驗證說明文件中的「使用 REST 進行驗證」。

必要的角色

如要取得回報主機故障所需的權限，請要求管理員授予您下列 IAM 角色：

如要進一步瞭解如何授予角色，請參閱「管理專案、資料夾和組織的存取權」。

這些預先定義的角色具備回報主機故障所需的權限。如要查看確切的必要權限，請展開「Required permissions」(必要權限) 部分：

所需權限

如要檢舉主機故障，必須具備下列權限：

  • 如要建立出錯的主機報告，請按照下列步驟操作： compute.instances.update 在 Compute 執行個體上
  • 如要使用 Logging 查看作業清單，請按照下列步驟操作： logging.operations.list 在專案中
  • 如要使用 Logging 查看作業詳細資料，請按照下列步驟操作： logging.operations.get 在專案中
  • 如要查看 Compute Engine 中的作業清單： compute.zoneOperations.list 在專案中
  • 如要查看 Compute Engine 中作業的詳細資料： compute.zoneOperations.describe 在專案中

您或許還可透過自訂角色或其他預先定義的角色取得這些權限。

瞭解出錯主機回報程序

回報運算執行個體的主機故障後，運算執行個體重新啟動的時間會因運算執行個體使用的預訂項目中指定的預訂項目運作模式而異。如要驗證預留項目的運作模式，請查看預留項目中的 reservationOperationalMode 欄位。下表大致列出兩種可用的預訂作業模式 (所有容量模式和管理模式) 的主機程序錯誤。
所有容量模式 (ALL_CAPACITY) 受管理模式 (HIGHLY_AVAILABLE_CAPACITY)
支援的機型 A4X Max 和 A4X A4、A3 Ultra、A3 Mega 和 A3 High
Faulty host report API 頻率限制 沒有匯率限制。 對 API 的呼叫可能會受到速率限制。
主機故障回報程序

如果執行個體是以所有容量模式執行，回報主機故障時會發生下列情況：

  1. 回報出錯的主機：在回報出錯的主機作業期間，執行個體會維持 RUNNING 狀態，通常需要 10 到 12 分鐘才能完成。如要查看作業狀態，請參閱本文中的「查看報告中發生錯誤的主機作業」。

  2. 修復主機：回報主機故障作業完成後，主機修復作業會在 1 分鐘內啟動。

    維修主機作業開始後，執行個體會停止運作，且狀態會根據為執行個體指定的自動重新啟動 (automaticRestart) 設定而變更：

    • 如果執行個體已啟用自動重新啟動功能，執行個體狀態會變更為 REPAIRING。除非您事先停止執行個體，否則當主機恢復正常時，執行個體會自動重新啟動。
    • 如果停用執行個體的自動重新啟動功能，執行個體狀態會變更為 TERMINATED。主機恢復正常後，您必須手動重新啟動執行個體。

    維修故障主機可能需要 3 到 14 天，有時甚至更久。

  3. 重新啟動執行個體：主機維修作業完成後 (通常需要 3 到 14 天)，會發生下列其中一種情況：

    • 如果執行個體處於 REPAIRING 狀態，且資源在修復完成時可用，Compute Engine 會自動在修復後的主機上重新啟動執行個體。
    • 否則，如果執行個體處於 TERMINATED 狀態，或資源在修復完成時無法使用，執行個體狀態會維持或變更為 TERMINATED。如要執行執行個體，請手動重新啟動執行個體。不過，如果重新啟動執行個體時沒有可用資源，執行個體可能會無法重新啟動；舉例來說，如果其他執行個體已使用修復的主機，就會發生這種情況。

如果代管模式下執行的運算執行個體發生主機故障，回報後會發生下列情況：

  1. 回報出錯的主機：在回報出錯的主機作業期間，執行個體會維持 RUNNING 狀態，通常需要 10 到 12 分鐘才能完成。如要查看作業狀態，請參閱本文中的「查看回報主機故障作業」。

  2. 開始修復主機：回報主機故障作業完成後，主機修復作業會在 1 分鐘內啟動。

    維修主機作業開始後，執行個體會停止運作，且狀態會根據為執行個體指定的自動重新啟動 (automaticRestart) 設定而變更：

    • 如果執行個體已啟用自動重新啟動功能，執行個體狀態會變更為 REPAIRING。除非您事先停止執行個體，否則當主機恢復正常時，執行個體會自動重新啟動。
    • 如果停用執行個體的自動重新啟動功能，執行個體狀態會變更為 TERMINATED。主機恢復正常後，您必須手動重新啟動執行個體。

    維修故障主機可能需要 3 到 14 天，有時甚至更久。

  3. 遷移並重新啟動執行個體：主機修復作業開始後 (通常需要 10 到 12 分鐘)，Compute Engine 會嘗試預留一個主機，以取代預留容量中回報有問題的主機。如果 Compute Engine 找到正常運作的主機 (成功更換故障主機，或在預留容量中找到相符的正常主機)，就會將執行個體遷移至該主機。接著，透過下列其中一種方式重新啟動執行個體：

    • 如果執行個體處於 REPAIRING 狀態，且在修復完成前或完成時有可用資源，Compute Engine 會自動在正常運作的主機上重新啟動執行個體。
    • 否則，如果執行個體處於 TERMINATED 狀態，或在修復完成前或完成時沒有可用資源，執行個體狀態會維持或變更為 TERMINATED。如要執行執行個體，必須手動重新啟動執行個體。不過，如果重新啟動執行個體時沒有可用資源，執行個體可能會無法重新啟動；舉例來說，如果其他執行個體已使用修復的主機，就會發生這種情況。

回報出錯的主機

如要回報主機故障，請完成下列步驟：

  1. 查看運算執行個體執行的主機。

    如需操作說明，請參閱「查看運算執行個體的拓撲」。

  2. 選用：備份本機 SSD 資料。執行個體停止時，Compute Engine 會自動捨棄附加至執行個體的任何本機 SSD 磁碟資料。Compute Engine 捨棄本機 SSD 資料後，您就無法復原。

    如需如何保留本機 SSD 資料的操作說明，請參閱「本機 SSD 資料備份」一文。

  3. 回報出錯的主機。如要回報出錯的主機，請選取下列其中一個選項。回報故障主機作業完成後，主機修復作業會立即啟動，如果執行有問題的主機報表作業後，執行個體沒有回應，建議您等待至少 15 分鐘，然後重新啟動運算執行個體。

    gcloud

    如要回報出錯的主機，請使用下列 gcloud compute instances report-host-as-faulty 指令：

    gcloud compute instances report-host-as-faulty INSTANCE_NAME \
    --async \
    --disruption-schedule=IMMEDIATE \
    --fault-reasons=behavior=FAULT_REASON,description=DESCRIPTION \
    --zone=ZONE

    更改下列內容：

    • INSTANCE_NAME：運算執行個體的名稱。

    • FAULT_REASON：以半形逗號分隔的清單，列出運算執行個體遇到的主機問題，例如 ISSUE_1,ISSUE_2。您可以指定下列值：

      • PERFORMANCE：與叢集中的其他 GPU 相比，附加至運算執行個體的 GPU 有效能問題，但記錄中沒有 XID 錯誤，且 Compute Engine 未偵測到其他常見的失敗模式，例如無聲資料損毀。

      • SILENT_DATA_CORRUPTION：運算執行個體中出現資料損毀情形，但運算執行個體仍持續運作。無聲資料毀損可能是 vCPU 缺陷、軟體錯誤或核心問題所致。

      • UNRECOVERABLE_GPU_ERROR：您發現 XID 發生無法復原的 GPU 錯誤。

      • BEHAVIOR_UNSPECIFIED：您不確定運算執行個體的問題為何。

    • DESCRIPTION：影響運算執行個體的問題說明，例如 XID 資訊或疑似效能問題。

    • ZONE：運算執行個體所在的可用區。

    REST

    如要回報出錯的主機，請向 instances.reportHostAsFaulty 方法發出下列 POST 要求。

    回報主機故障時，你可以一次指定多個故障原因。舉例來說，如要指定兩個錯誤原因，請提出如下要求：

    POST https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/zones/ZONE/instances/INSTANCE_NAME/reportHostAsFaulty

{
  "disruptionSchedule": "IMMEDIATE",
  "faultReasons": [
    {
      "behavior": "FAULT_REASON_1",
      "description": "DESCRIPTION_1"
    },
    {
      "behavior": "FAULT_REASON_2",
      "description": "DESCRIPTION_2"
    }
  ]
}

    更改下列內容：

    • PROJECT_ID：運算執行個體所在的專案 ID。

    • ZONE：運算執行個體所在的可用區。

    • INSTANCE_NAME：運算執行個體的名稱。

    • FAULT_REASON_1 和 FAULT_REASON_2：運算執行個體遇到的每個主機問題。您可以指定下列值：

      • PERFORMANCE：與叢集中的其他 GPU 相比，附加至運算執行個體的 GPU 有效能問題，但記錄中沒有 XID 錯誤，且 Compute Engine 未偵測到其他常見的失敗模式，例如無聲資料損毀。

      • SILENT_DATA_CORRUPTION：運算執行個體中出現資料損毀情形，但運算執行個體仍持續運作。無聲資料毀損可能是 vCPU 缺陷、軟體錯誤或核心問題所致。

      • UNRECOVERABLE_GPU_ERROR：您發現 XID 發生無法復原的 GPU 錯誤。

      • BEHAVIOR_UNSPECIFIED：您不確定運算執行個體的問題為何。

    • DESCRIPTION_1 和 DESCRIPTION_2：您指定各主機問題的說明，例如 XID 資訊或疑似效能問題。

查看回報出錯的主機作業

回報主機故障後，Compute Engine 會啟動一系列作業，將主機標示為故障，並準備維修。具體來說，在回報出錯的主機作業期間，會發生下列程序：

  1. 將主機標示為有故障。Compute Engine 會建立報告，指出主機故障作業。「回報主機故障」作業接著會建立一連串的子作業。這些子作業會將基礎主機標示為有故障。

  2. 準備主機送修。所有子作業完成後，系統會開始回報故障主機作業。Compute Engine 會停止運算執行個體，並啟動修復故障主機作業。根據運算執行個體所用預留資源中指定的預留資源運作模式，以及是否有可用的健康主機，Compute Engine 會讓運算執行個體保持停止狀態，或嘗試自動遷移並重新啟動運算執行個體。

  3. 回報完成並修復主機。Compute Engine 會完成回報出錯主機作業，並執行主機修復作業。

如要追蹤專案中回報主機故障 (compute.instances.reportHostAsFaulty) 作業的狀態，請選取下列其中一個選項。如要進一步瞭解可用於追蹤修復、遷移和自動重新啟動的其他作業，請參閱 Compute Engine 說明文件中的「維護和重新啟動行為」和「監控及規劃主機維護事件」。

控制台 (執行個體作業)

  1. 前往 Google Cloud 控制台的「Operations」頁面。

    前往「作業」

  2. 在隨即顯示的表格中，找出您回報的運算執行個體。

  3. 在包含運算執行個體的資料列中，您可以在「狀態」欄中查看回報主機故障作業的狀態。作業完成後，值會是「Done」。

  4. 選用：如要確認 Compute Engine 是否已重新啟動運算執行個體，請查看執行個體的詳細資料。

控制台 (Compute 執行個體記錄)

  1. 前往 Google Cloud 控制台的「Logs Explorer」頁面。

    前往 Logs Explorer

  2. 確認「顯示查詢」切換鈕已設為開啟。

  3. 在查詢編輯器中輸入下列查詢：

    resource.type="gce_instance" AND protoPayload.methodName=~"compute\.instances\.reportHostAsFaulty"

  4. 按一下「Run query」(執行查詢)。「Query results」(查詢結果) 窗格會顯示查詢結果。

gcloud

  1. 如要查看專案中回報主機故障作業的狀態，請使用 gcloud compute operations list 指令，並將 --filter 旗標設為 operationType:reportHostAsFaulty：

    gcloud compute operations list --filter="operationType:reportHostAsFaulty"

  2. 如要查看特定錯誤主機作業的詳細資料，請使用 gcloud compute operations describe 指令：

    gcloud compute operations describe OPERATION_NAME \
    --zone="ZONE"

    更改下列內容：

    • OPERATION_NAME：作業名稱。

    • ZONE：作業所在的區域。

REST

如要查看專案中回報出錯主機作業的狀態，請對 zoneOperations.list 方法發出 GET 要求。在要求網址中，加入設為 items.operationType:reportHostAsFaulty 的 filter 查詢參數。

GET https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/zones/ZONE/operations&filter=items.operationType:reportHostAsFaulty

更改下列內容：

  • PROJECT_ID：作業名稱。

  • ZONE：作業所在的區域。

後續步驟