大規模なGPUクラスタでは、ハードウェア障害は現実的な問題です。Xidエラー、ダブルビットECCエラー、GPUがPCIeバスから外れる、InfiniBandリンクのフラッピングなどが、分散トレーニングジョブを停止させたり、推論レプリカをダウンさせたりします。何か問題が起きたことに気づくのは簡単ですが、障害から健全なノードに戻すまでのプロセスが難しいのです。Togetherは今年初めに完全自動ノード修復機能を発表し、現在一般提供しています。本記事ではその設計と動作を詳しく説明します。
従来のノード自動修復は、ノードがNotReadyになったという単一のシグナルに依存することが多いですが、NotReadyはノードが本当に故障しているのか、一時的に到達不能なのかを区別できません。ストレージやネットワークのイベントが多数のノードに同時に影響すると、すべてのノードがNotReadyになり、大規模な誤交換を引き起こす可能性があります。そこでTogetherの自動修復は「失敗した健康チェックなしにノード修復は行わない」という原則に従い、すべての修復にサポート証拠を添付します。
パイプラインは4段階です。障害を検出し、いつ行動するかを決定し、ノードを修復し、マシンを再検証します。最初の3段階はユーザーのクラスタ内で実行され、4段階目はノードが退去した物理ホスト上でTogetherのインフラによって実行されます。検出はハイパーバイザーの両側から行われます。VM内部では、カーネルログのXidやPCIe脱落、DCGMのECCや熱スロットリング指標、Node Problem Detectorのファイルシステム読み取り専用などを監視します。ホスト側では、InfiniBandレールの状態とリンクフラッピング、ホストの到達可能性を監視します。すべてのアラートには安定したサマリー、平易な説明、機械可読な証拠ペイロードが付属し、コンソール、API、通知で一貫した情報が提供されます。
ポリシー面では、プラットフォームが「何をするか」を決定し、ユーザーが「実行するか」「いつ実行するか」を決定します。各シグナルはそれを修正する最も軽量なアクションにマッピングされます。修復タブでは、自動修復ポリシーのデフォルトは「修復前に承認」で、すべての推奨が人の承認を待ちます。デフォルトを「完全自動」に切り替えることもできますが、それは一律のスイッチではなく、修復アクションのチェックリストで信頼するものを選択します。Xidグループ内ではコードごとに同意を設定でき、例えばXid 119と95の再起動を自動承認し、移行は承認制にすることが一般的です。「アイドル待機」設定により、ノードが実際にアイドルになるまで修復を保留します（KubernetesではGPUを要求するPodがない、Slurmでは割り当てがない状態）。最大待機時間はデフォルト2時間、上限24時間で、「実行中のジョブを中断しない」を選択すると無制限になります。各修復には要求者、承認者、決定ルール、時刻が記録されます。
組み込み検出に加え、API、コンソール、ノードラベル（プレビュー）を介して独自の検出システムを統合できます。ノードラベル方式では、RBAC権限を持つ任意の検出器がアノテーションとラベルを追加して修復を開始でき、システムはそれを外部要求者として記録し、追跡可能性を確保し、ユーザーを偽装できないようにします。検出器名とリクエストIDが冪等キーとなり、同じ障害を繰り返し検出してもノードが二重に再起動されることはありません。外部要求は再起動、クイック再プロビジョニング、移行を要求できますが、「削除」は常に人手による操作のみです。これらの要求は承認キューをスキップしますが、証拠ゲート、容量チェック、予算制限を通過する必要があり、クラスタごとの上限によりバグのある検出器が災害を引き起こすのを防ぎます。
修復アクションは軽い順に4段階です。再起動（VMをその場で再起動、ローカルの/scratchと/tmpデータは保持）、クイック再プロビジョニング（健全なホスト上でクリーンイメージからVMを再構築、ローカルデータは失われる）、新しいホストへの移行（別のハードウェアでVMを再構築し、古いホストは再検証へ）、削除（RMAのためにノードを引き抜く、常に人手で開始）。同じ修正がループすることはありません。同じマシンで同じアクションが2回実行された後に障害が再発した場合、次の推奨は1段階上がります。ラダーはマシン、クラスタ、アラート、Xidコードごとに追跡され、1週間以上前の試行やキャンセル・自己解決した推奨はカウントされません。移行にはクリティカルアラートの証拠が必要で、条件を満たさない場合はクイック再プロビジョニングとして実行されます。Xid 79などGPUの電源断が必要な障害には、プレビュー版でホスト電源サイクルが提供され、BMC認証情報は不要で、ブートIDチェックにより既に復帰したホストを再循環させないようにします。
アラートストームに備えて、複数の独立したガードレールが組み込まれています。シグナルは一定時間持続しないと推奨になりません。各修復後、ノードには約30分のクールダウンがあります。同時実行予算はクラスタのノード数に基づいて設定され、ノードプールごとに同時に1つの修復のみが実行されます。単一クラスタで相関する自動修復が急増するとサーキットブレーカーが作動します。各修復は1つのターゲットのみを対象とします。アラートが解除されると推奨は自動的に消えます。コントロールプレーンは複製され、すべての書き込みは冪等で期待状態と照合されるため、2つのレプリカが同じノードで競合しても1つの修復のみが生成されます。
ノードが移行または削除されると、そのマシンはすぐにプールに戻されるのではなく、キューで診断を待つこともありません。古いVMが消えるとすぐに、マシンはTogetherインフラ上で再検証プロセスに入り、診断が実行され、健全なマシンのみがクラスタに再参加できます。現在、パッシブ健康チェック、修復推奨、自動修復ポリシー（障害ごとおよびノードごとの同意を含む）、アイドル待機制御、エスカレーションラダー、安全ガードレール、APIとコンソールによる修復が一般提供されています。ノードラベルベースの修復契約はプレビュー段階です。Togetherは検出シグナルと修復アクションを継続的に追加し、カバレッジの最大化と復旧時間の短縮を目指しています。