NVIDIA DSX OSは、GPUクラスターの構成基準を再現し、実際のワークロードで準備状態を検証し、運用中の障害を監視するツール群だ。クラスター運用チームは既存のデプロイツールを維持しながら、追加容量や修理済みノードを検査し、設定に応じて隔離と復旧を自動化できる。

1. 構成基準をファイルに固定し、既存のデプロイツールにつなぐ

構成基準を担うNVIDIA AI Cluster Runtime(AICR)は、ネットワーク・ストレージ・ドライバーなどのコンポーネントのバージョンを固定したレシピを作る。レシピは、クラスターにどのソフトウェアをどの順序でインストールするかを記した構成設計図だ。

AICRはこの設計図を、既存のデプロイツールが適用できる成果物、つまりツールが生成するデプロイ用ファイルに変換する。実際のデプロイと状態の調整は既存ツールが担うため、運用チームは現在のパイプライン、つまり作業工程を順に実行する流れを活用できる。

レシピには、コンポーネント間の依存関係、つまり事前に必要なコンポーネントとの関係や、インストール後の状態を確認する検査も含まれる。これにより基準のバージョン管理やコードレビューが可能になり、手動変更による基準からの逸脱も検出できる。Kubernetesは異常なコンテナを含むPodを実行中と表示する場合があるため、Podの状態だけを確認する検査よりも、コンポーネントごとの状態確認が重要だ。

以下のコマンドは稼働中のクラスターをレシピの基準と照合し、基準から逸脱した場合に0以外の終了コード、つまりコマンドの実行結果を表す数値を返す。

# Check a live cluster against the recipe's constraints
aicr validate --recipe recipe.yaml

# Compare a golden baseline against the live cluster, non-zero exit on drift
aicr diff --baseline ./golden.yaml --target cm://default/aicr-snapshot --fail-on-drift

2. 実際のワークロードを動かして遅いノードと失敗原因を確認

基本的な状態チェックがサービスの動作有無を確認するのに対し、NVIDIA Cluster Readiness Engine(NVCRE)は複数ノードが連携して実際のワークロードを処理できるかを試す。学習ジョブやGPU間通信テストを実行し、結果と失敗原因を記録する。

認証仕様、つまり検査対象と合格基準を記した文書では、検査ノード、テストの種類、合否を分ける基準値である合格しきい値を定める。設定例では通信・学習テストを選び、バス帯域幅、つまりデータ転送経路の処理容量の合格基準を毎秒300GB以上とする。これは測定結果ではなく、運用チームが定める合格ラインの例だ。

検査項目には、GPU管理ツールであるDCGMのレベル4診断や、NVIDIA NeMo Frameworkによる事前学習、つまり本格的な作業の前にモデルをあらかじめ訓練する処理も含まれる。独自のコンテナテストを認証検査に追加することもできる。

64ノードの通信試験で帯域幅が低い場合、NVCREは失敗したグループを繰り返し分割し、最小グループサイズまで試験して疑わしいノードと理由を報告する。1ノードの性能低下が、複数GPUで分担する分散学習全体を遅らせる可能性があるため、単純な状態指標には表れないボトルネック、つまり全体の処理速度を落とす箇所の発見に意味がある。

3. 障害監視を隔離と復旧後の再検証につなぐ

NVSentinelはGPU診断とエラー信号、ネットワーク接続を担う装置であるネットワークインターフェースの状態、クラウドのメンテナンスイベントを監視する。NVIDIAによると、監視にはGPU時間を使わず、進行中のジョブに使うリソースを残す。

デフォルトは障害をノードの状態として報告する監視モードだ。運用チームは報告を評価した後、自動隔離、ノード上の実行ジョブを退避させるドレイン処理、復旧を有効化できる。一定時間内に隔離するノード数を制限する安全策も提供する。

新しいノードが加わるときや、復旧したノードが戻るときに、再検証を要求するよう設定できる。検証中は新しいジョブの割り当てをブロックし、検査に合格して他の検査によるブロック理由もなくなれば解除する。再試行後も失敗したノードはブロック状態を維持する。

NVCREはどのノードがなぜ失敗したかを判定し、NVSentinelは隔離と復旧を担う。この役割分担により、両システムが同じノードを重複してブロックし、解除処理の状態に不整合が生じる事態を減らす。プラットフォームチームは認証結果を、ノードの作成から廃棄までを管理する独自のノードライフサイクルツールに渡して運用を任せることもできる。

4. 監視から導入しつつ、合格ラインと復旧ルールはチームが決める

3つのツールはApache 2.0ライセンスのオープンソースで、外部からの貢献を受け付けている。導入には各ツールとテスト実行環境のインストール・構成が必要だ。稼働中のクラスターでは監視報告を確認することから始め、信頼できる信号に隔離・復旧ルールを結び付けられる。

自動復旧と再検証を設定すると、ノードを修理・検査して利用可能なリソースに戻すまでの手作業による引き継ぎを減らせる。一方で運用チームは、クラスターに適したテストとしきい値、隔離ルール、復旧の上限、担当者の対応手順を設計し、維持する必要がある。

性能しきい値はデフォルトでは設定されておらず、指定しなければ目標より遅いノードも合格する可能性がある。ドライバーや管理コンポーネントのアップグレード、接続ネットワークの変更後の検証は自動で始まらないため、運用チームが要求する必要がある。

DSX OSの価値はGPUクラスターの基準・検証・復旧をつなぐことにあり、自動化の範囲は運用チームが定めた検査とルールに左右される。