障害のあるホストを報告する

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 を介して障害のあるホストを報告するをご覧ください。

注意: 障害のあるホストを報告すると、VM が停止する破壊的なアクションが発生します。ホストを報告する前に、クラスタ ヘルス スキャナ（CHS）などのツールを使用して環境を徹底的に調査し、問題の根本原因を特定します。問題を解決する代替手段がない場合にのみ、ホストに障害があると報告してください。

制限事項

障害のあるホストを報告する場合、次の制限が適用されます。

• ホストで実行されているコンピューティング インスタンスが次の条件をすべて満たしている場合にのみ、障害のあるホストを報告できます。

  • コンピューティング インスタンスが実行されている。

  • コンピューティング インスタンスは、A4X Max、A4X、A4、A3 Ultra、A3 Mega、A3 High（8 GPU）マシンタイプを使用します。

  • コンピューティング インスタンスが予約にバインドされたプロビジョニング モデルを使用している。

    注: 実行中の 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 ロールを付与するよう管理者に依頼してください。

• コンピューティング インスタンスまたはプロジェクトに対する Compute インスタンス管理者（v1） （roles/compute.instanceAdmin.v1）
• Cloud Logging を使用して障害のあるホストの報告オペレーションの状態を表示するには: プロジェクトに対するログ閲覧者（roles/logging.viewer）

ロールの付与については、プロジェクト、フォルダ、組織へのアクセス権の管理をご覧ください。

これらの事前定義ロールには、障害のあるホストを報告するために必要な権限が含まれています。必要とされる正確な権限については、「必要な権限」セクションを開いてご確認ください。

必要な権限

障害のあるホストを報告するには、次の権限が必要です。

• 障害のあるホストの報告を作成する: コンピューティング インスタンスに対する compute.instances.update
• Logging を使用してオペレーションのリストを表示する: プロジェクトに対する logging.operations.list
• Logging を使用してオペレーションの詳細を表示する: プロジェクトに対する logging.operations.get
• Compute Engine のオペレーションの一覧を表示する: プロジェクトに対する compute.zoneOperations.list
• Compute Engine のオペレーションの詳細を表示する: プロジェクトに対する compute.zoneOperations.describe

カスタムロールや他の事前定義ロールを使用して、これらの権限を取得することもできます。

障害のあるホストの報告プロセスについて

コンピューティング インスタンスの障害のあるホストを報告した後、コンピューティング インスタンスが再起動するタイミングは、コンピューティング インスタンスが使用する予約で指定された予約オペレーション モードによって異なります。予約の運用モードを確認するには、予約の reservationOperationalMode フィールドを表示します。次の表に、利用可能な 2 つの予約運用モード（すべての容量モードとマネージド モード）の障害のあるホストプロセスをまとめます。

	All Capacity モード（ALL_CAPACITY）	マネージド モード（HIGHLY_AVAILABLE_CAPACITY）
サポートされているマシンタイプ	A4X Max と A4X	A4、A3 Ultra、A3 Mega、A3 High
Faulty host report API のレート制限	レート制限は適用されません。	API の呼び出しにはレート制限が適用される場合があります。
障害のあるホストの報告プロセス	全容量モードで実行されているコンピューティング インスタンスの障害のあるホストを報告すると、次のようになります。 障害のあるホストを報告する: インスタンスは、障害のあるホストの報告オペレーション全体で RUNNING 状態のままになります。通常、報告オペレーションの完了には 10 ～ 12 分かかります。オペレーションの状態を確認するには、このドキュメントの障害のあるホストの報告オペレーションを確認するをご覧ください。 ホストを修復する: 障害のあるホストの報告オペレーションが完了すると、1 分以内にホストの修復オペレーションが開始されます。 ホストの修復オペレーションが開始されると、インスタンスが停止し、インスタンスに指定された自動再起動（automaticRestart）設定に応じて状態が変化します。 インスタンスで自動再起動が有効になっている場合、インスタンスの状態は REPAIRING に変わります。ホストが正常な場合、インスタンスは自動的に再起動します。ただし、それまでにインスタンスを停止した場合を除きます。 インスタンスで自動再起動が無効になっている場合、インスタンスの状態は TERMINATED に変わります。ホストが正常になったら、インスタンスを手動で再起動する必要があります。 障害のあるホストの修復には 3 ～ 14 日、またはそれ以上かかることがあります。 インスタンスを再起動する: ホストの修復オペレーションが完了すると（通常は 3 ～ 14 日）、次のいずれかが発生します。 インスタンスが REPAIRING 状態にあり、修復が完了したときにリソースが使用可能な場合、Compute Engine は修復されたホストでインスタンスを自動的に再起動します。 それ以外の場合、インスタンスが TERMINATED 状態の場合、または修復が完了したときにリソースが使用できない場合には、インスタンスの状態は TERMINATED のままになるか、TERMINATED に変更されます。インスタンスを実行する場合は、インスタンスを手動で再起動する必要があります。ただし、インスタンスの再起動時にリソースが使用できない場合（修復されたホストを他のインスタンスがすでに使用している場合など）、インスタンスの再起動が失敗することがあります。	マネージド モードで実行されているコンピューティング インスタンスの障害のあるホストを報告すると、次のようになります。 障害のあるホストを報告する: インスタンスは、障害のあるホストの報告オペレーション全体で RUNNING 状態のままになります。通常、報告オペレーションの完了には 10 ～ 12 分かかります。オペレーションの状態を確認するには、このドキュメントの障害のあるホストの報告オペレーションを確認するをご覧ください。 ホストの修復を開始する: 障害のあるホストの報告オペレーションが完了すると、1 分以内にホストの修復オペレーションが開始されます。 ホストの修復オペレーションが開始されると、インスタンスが停止し、インスタンスに指定された自動再起動（automaticRestart）設定に応じて状態が変化します。 インスタンスで自動再起動が有効になっている場合、インスタンスの状態は REPAIRING に変わります。ホストが正常な場合、インスタンスは自動的に再起動します。ただし、それまでにインスタンスを停止した場合を除きます。 インスタンスで自動再起動が無効になっている場合、インスタンスの状態は TERMINATED に変わります。ホストが正常になったら、インスタンスを手動で再起動する必要があります。 障害のあるホストの修復には 3～14 日、またはそれ以上かかることがあります。 インスタンスを移行して再起動する: ホストの修復オペレーションが開始されると（通常は 10 ～ 12 分）、Compute Engine は、予約済み容量で報告された障害のあるホストを置き換えるために、別のホストを予約しようとします。Compute Engine が正常なホストを見つけた場合（障害のあるホストの置き換えに成功した場合や、予約済み容量で一致する正常なホストを見つけた場合など）、Compute Engine はインスタンスをそのホストに移行します。インスタンスの再起動は、次のいずれかで行われます。 インスタンスが REPAIRING 状態にあり、修復が完了する前または完了時にリソースが使用可能な場合、Compute Engine は正常なホストでインスタンスを自動的に再起動します。 それ以外の場合、インスタンスが TERMINATED 状態の場合、または修復が完了する前または完了時にリソースが使用できない場合には、インスタンスの状態は TERMINATED のままになるか、TERMINATED に変更されます。インスタンスを実行する場合は、インスタンスを手動で再起動する必要があります。ただし、インスタンスの再起動時にリソースが使用できない場合（修復されたホストを他のインスタンスがすでに使用している場合など）、インスタンスの再起動が失敗することがあります。

障害のあるホストを報告する

障害のあるホストを報告する手順は次のとおりです。

1. コンピューティング インスタンスが実行されているホストを確認します。

   手順については、コンピューティング インスタンスのトポロジを表示するをご覧ください。

2. 省略可: ローカル SSD データをバックアップします。インスタンスが停止すると、Compute Engine はインスタンスにアタッチされているローカル SSD ディスクのデータを自動的に破棄します。Compute Engine がローカル SSD データを破棄した後は、復元できません。

   ローカル SSD データを保持する手順については、ローカル SSD データのバックアップをご覧ください。

3. 障害のあるホストを報告します。障害のあるホストを報告するには、次のいずれかのオプションを選択します。ホストの修復オペレーションは、障害のあるホストの報告オペレーションが完了してから 1 分以内に開始されます。障害のあるホストの報告オペレーションを開始した後にインスタンスが応答しなくなった場合は、少なくとも 15 分待ってからコンピューティング インスタンスを再起動することをおすすめします。

   重要: ホストに障害があると報告した後は、オペレーションが完了するまで、追加のリクエストを送信しないでください。オペレーションの進行中は、Compute Engine は追加のリクエストを拒否します。

   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 リクエストを送信します。

   障害のあるホストを報告するときに、複数の障害理由を一度に指定できます。たとえば、2 つの障害理由を指定するには、次のようにリクエストを送信します。

   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 コンソールで、[オペレーション] ページに移動します。

   [オペレーション] に移動

2. 表示されたテーブルで、報告したコンピューティング インスタンスを探します。

3. コンピューティング インスタンスを含む行の [ステータス] 列で、障害のあるホストの報告オペレーションのステータスを確認できます。オペレーションが完了すると、値は Done になります。

4. 省略可: Compute Engine がコンピューティング インスタンスを再起動したかどうかを確認するには、インスタンスの詳細を表示します。

コンソール（コンピューティング インスタンスのログ）

1. Google Cloud コンソールで、[ログ エクスプローラ] ページに移動します。

   [ログ エクスプローラ] に移動

2. [クエリを表示] 切り替えボタンがオンになっていることを確認します。

3. クエリエディタで以下のクエリを入力します。

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

4. [クエリを実行] をクリックします。[クエリ結果] ペインにクエリ結果が表示されます。

gcloud

1. プロジェクト内の障害のあるホストの報告オペレーションのステータスを表示するには、--filter フラグを operationType:reportHostAsFaulty に設定して gcloud compute operations list コマンドを使用します。

   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 リクエストを送信します。リクエスト URL に、items.operationType:reportHostAsFaulty に設定された filter クエリ パラメータを含めます。

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

次のように置き換えます。

• PROJECT_ID: オペレーションの名前。

• ZONE: オペレーションが存在するゾーン。

次のステップ

• 障害のあるホストを報告する際に問題が発生した場合は、faulty host API のトラブルシューティングをご覧ください。

フィードバックを送信