ノードが抜けたとき読む順序

一言でいうと

Slurmの障害診断は、まずsinfoで範囲を絞り、slurmctld.logで理由を読むことでほぼ終わります。

なぜ必要なのか

「ジョブが動きません」という報告を受けると、確認する場所がいくつもあります。ジョブがキューで待機中なのか、ノードが外れたのか、認証が壊れたのか、設定が間違っているのか。ただし、確認には順序があります。

どう動くのか

1段階目: 全体の状態

sinfo
sinfo -R                        # DRAIN/DOWN 이유만
sinfo -N -l                     # 노드별 상세

sinfo -Rが特に便利です。外れたノードと、その理由の文字列だけを見せてくれます。

ノード状態の意味です。

状態	意味
idle	正常で、ジョブなし
alloc / mix	全体または一部のリソースが割り当て済み
drain	管理者またはシステムが外しました。自動では復帰しません
down	応答がないか、登録に失敗しました
inval	設定が実際と合っていません
fail / failg	ハードウェアの問題が報告されました

2段階目: 理由を読む

scontrol show node gpu-node01 | grep -i reason
tail -100 /var/log/slurm/slurmctld.log
tail -100 /var/log/slurm/slurmd.log     # 해당 노드에서

ログに出る代表的なメッセージと原因です。

メッセージ	原因
Low socket*core*thread count	CPUsがソケット×コア×スレッドと一致していません
Low RealMemory	設定したメモリがノードの実際の値より大きいです
gres/gpu count reported lower than configured	slurm.confとgres.confの個数が一致していません
Munge decode failed: Expired credential	時計の不一致
Munge decode failed: Invalid credential	キーの不一致
partition X has unknown node Y	定義されていないノードをパーティションが参照しています
Node unexpectedly rebooted	ノードが再起動したあとに登録されました

mungeエラーの2種類を区別することが重要です。Expired credentialは時計の問題なのでNTPを確認し、Invalid credentialはキーの問題なので/etc/munge/munge.keyを比較します。まったく異なる対応です。

3段階目: ジョブが動かない場合

ノードは問題ないのにジョブが待機するだけなら、squeueのREASON列を見ます。

REASON	対応
Resources	要求したリソースがまだ空いていません。正常な待機です
Priority	優先度の高いジョブが前にあります
Dependency	先行ジョブを待っています
PartitionTimeLimit	--timeがパーティションの最大値を超えています
PartitionNodeLimit	要求したノード数がパーティションの上限を超えています
ReqNodeNotAvail	指定したノードが使用不可です
QOSMax...	QOSの制限に達しています

PartitionTimeLimitのようなものは永遠に待機します。リソースが空いても決して始まらないので、ユーザーが要求を直して再投入する必要があります。

4段階目: 復旧

原因を直したら、ノードを明示的に復帰させます。

scontrol update NodeName=gpu-node01 State=RESUME
scontrol update NodeName=gpu-node[01-03] State=RESUME
scontrol reconfigure                     # 설정 변경 반영

設定ファイルを直したなら、すべてのノードに配布してからscontrol reconfigureを実行する必要があります。1台だけ違うと、そのノードがまた外れます。

ノードが外れるのを事前に見つける

Slurmの運用で最も多くの時間を取られるのは、ジョブの失敗ではなく、ノードが静かに外れることです。ユーザーは「遅くなった」としか感じませんが、原因はクラスターの半分が遊んでいることです。

外れた理由は必ず記録されます。

sinfo -R --format="%50E %12U %19H %N"     # 사유, 지운 사람, 시각, 노드
scontrol show node <노드> | grep -E 'State|Reason|CfgTRES|AllocTRES'

ノードがdrainになるよくある理由は3つです。

理由	実際の原因
Low RealMemory	設定のメモリ値が実際より大きいです。カーネルが少し使います
gres/gpu count too low	GPUが1枚消えました(nvidia-smiで確認します)
Kill task failed	ジョブのプロセスが終了せず、ノードが片付きませんでした

1つ目が特によく出ます。slurm.confに物理メモリの値をそのまま書くと、カーネルや予約領域のせいで実際に使える量が少しだけ小さくなり、ノードがすぐに外れます。slurmd -Cが出力する値を使い、そこからさらに少し下げます。

slurmd -C          # 이 노드가 보고하는 실제 값

設定を変えたら、反映を確認します。slurm.confはすべてのノードで同じでなければならず、変更後にはscontrol reconfigureが必要です。1台だけ違うとそのノードが外れ続けますが、症状はそのノード自体の問題のように見えます。

クリーンアップの失敗はたいてい、プロセスが終了しないことが原因です。epilogが終わらないと、ノードがcompletingのまま動かなくなります。UnkillableStepTimeoutを超えると、ノードがdrainになります。頻繁に起きるなら、ファイルシステム(特にNFS)の待機でプロセスがD状態になっているので、直すべき場所はSlurmではなくストレージです。

復帰させるときに理由を消します。状態だけを戻して理由を残すと、次のヘルスチェックでまた外れます。

scontrol update NodeName=<노드> State=RESUME

現場での姿

時計の問題は定期的に再発します。NTPが止まっていたり、ファイアウォールがポート123を塞いでいたりすると、数日かけて少しずつずれていき、ある日mungeが拒否し始めます。クラスターのモニタリングに、時計の同期状態を入れておくとよいです。

DRAINの理由の文字列を消さずに残しておく習慣。scontrol update ... State=RESUMEだけを実行すると、理由が消えます。調査の記録のために、理由をどこかに残してから復帰させるチームが多くあります。

次のラボですること

壊れた設定とログが入ったフィクスチャを受け取り、4つの原因をそれぞれ特定して、修正版を作り、復旧手順を書いて、RCAレポートを残します。