# SLURM: Simple Linux Utility for Resource Management Navigation: [[index]] | [[overview]] | [[SLURM]] | [[HPCジョブスケジューリング]] > [!note] 出典の位置づけ > 本 source が参照する原本(`.raw/papers/SLURM--Simple-Linux-Utility-for-Resource-Management.pdf`, UCRL-MA-147996 REV 3)は、Lawrence Livermore National Laboratory(LLNL)の技術レポートであり、著者は Morris Jette と Mark Grondona の2名のみが記載されている。同内容は Andy B. Yoo を筆頭著者に加えた形で Job Scheduling Strategies for Parallel Processing(JSSPP 2003, LNCS vol. 2862, Springer, pp. 44–60, DOI: 10.1007/10968987_3)として正式に学会発表・出版された(Crossref メタデータで確認済み)。`author` フィールドは本 raw 原本の記載に従い Jette と Grondona の2名とし、`aliases` に両方の版を残す。 > [!abstract] 概要(Abstract の完全日本語訳) > Simple Linux Utility for Resource Management(SLURM)は、数千ノード規模の Linux クラスタ向けの、オープンソースかつフォールトトレラントで高いスケーラビリティを持つクラスタ管理・ジョブスケジューリングシステムである。構成要素にはマシン状態管理、パーティション管理、ジョブ管理、スケジューリング、ストリームコピーの各モジュールが含まれる。本稿は SLURM のアーキテクチャと機能の概要を提示する。 ## 論文情報 - 著者(本 raw 原本記載): [[Morris Jette]]、[[Mark Grondona]](所属: [[Lawrence Livermore National Laboratory]]) - 学会発表版の著者: Andy B. Yoo、Morris A. Jette、Mark Grondona - 発表: Job Scheduling Strategies for Parallel Processing (JSSPP 2003), LNCS vol. 2862, Springer, pp. 44–60 - 原本種別: LLNL 技術レポート UCRL-MA-147996 REV 3(全31ページ) ## 概要 SLURM(Simple Linux Utility for Resource Management)は、既存の Linux 向けリソースマネージャを調査した結果、シンプルさ・高いスケーラビリティ・異なるクラスタアーキテクチャ/インターコネクトへの移植性を兼ね備えたものが見当たらなかったことを受け、LLNL が新規に設計したクラスタリソース管理システムである。設計方針として次を掲げる: - **シンプルさ**: 意欲あるエンドユーザーがソースコードを理解し機能追加できる程度に単純さを保つ。一般的な訴求力のある機能以外の追加は避ける。 - **オープンソース**: GNU General Public License で配布し、誰でも無償で利用できる。 - **移植性**: C 言語と GNU autoconf で実装。Linux 向けに書かれているが他の Unix 系 OS への移植も容易。プラグイン機構により多様なインフラを柔軟にサポートする。 - **相互接続**: UDP/IP ベースの通信と Quadrics Elan3 インターコネクトを当初サポート。プラグイン機構により他のインターコネクト追加も容易。 - **スケーラビリティ**: 数千ノード規模のクラスタ向けに設計。1000ノードクラスタのコントローラは約2MBのメモリで動作する。 - **フォールトトレランス**: コントローラのクラッシュを含む様々な障害モードでもワークロードを終了させない。ノード障害時もそのノードのスケジューリングのみに影響を限定する。 - **セキュリティ**: プラグイン機構を通じた暗号技術によるユーザー・サービス間の相互認証を行うが、ネットワークの物理的安全性は前提とせず、単一の管理ドメイン内であることのみを前提とする。 - **システム管理**: シンプルな設定ファイルを用い、分散状態を最小化する。設定はジョブ実行中でも変更可能。 ## 問題設定 - SLURM は包括的なクラスタ管理・監視パッケージではない。ノード状態は把握するが、一般的なイベントログ機構や履歴状態のバックエンド DB としての用途は持たない。他のツールとの併用を前提とする。 - SLURM は Globus や DPCS(Distributed Production Control System)のようなメタバッチシステムではなく、単一クラスタ内のリソース管理に限定される。 - SLURM は高度なバッチシステムではなく、あえてスケジューリング判断を外部エンティティに委ねる設計とし、デフォルトスケジューラは単純な FIFO のみを実装する。外部スケジューラはプラグイン経由でジョブの初期優先度を設定したり、API 経由でジョブの投入・シグナル送信・終了・待ち行列の並べ替えを行える。 ## 提案手法: SLURM のアーキテクチャ **Fig. 1: SLURM アーキテクチャ全体図** ![[_attachments/SLURM--Simple-Linux-Utility-for-Resource-Management/fig01-architecture.png]] (Fig. 1. ユーザーが利用する5つのコマンドラインユーティリティ(scontrol, sinfo, squeue, scancel, srun)から primary な slurmctld への要求、フェイルオーバー用の backup slurmctld との連携、slurmctld と各計算ノードの slurmd デーモン群との双方向通信、および slurmd から srun への直接接続を示す全体構成図。) SLURM は各計算ノードで動作する slurmd デーモン、管理ノードで動作する slurmctld デーモン(オプションでフェイルオーバー用の backup を持つ)、および任意の場所で実行可能な5つのコマンドラインユーティリティ(scancel, scontrol, sinfo, squeue, srun)から構成される。 SLURM が管理するエンティティは次の4種である: - **nodes**: SLURM における計算リソース - **partitions**: ノードを論理的に排他なグループへ分割したもの - **jobs**: 指定時間だけユーザーに割り当てられたリソースの割当 - **job steps**: ジョブ内のタスク集合(並列実行される場合を含む) 優先度順の待ち行列にある各ジョブは単一パーティション内のノードへ割り当てられる。一度あるパーティションでの割当要求が失敗すると、そのパーティションに対する低優先度ジョブは以降のリソース割当検討から除外される。 **Fig. 2: SLURM のエンティティ関係(ノード・パーティション・ジョブ・ジョブステップ)** ![[_attachments/SLURM--Simple-Linux-Utility-for-Resource-Management/fig02-entities.png]] (Fig. 2. 計算ノード群が Partition 1 と Partition 2 の2つに分割され、Partition 1 では1つのジョブが全割当ノードを使う1つのジョブステップを実行中、Partition 2 では1つのジョブが元の割当の半分のノードのみを使う1つのジョブステップを実行中である様子を示す図。) **Fig. 3: slurmctld と slurmd 内部のサブシステム構成** ![[_attachments/SLURM--Simple-Linux-Utility-for-Resource-Management/fig03-subsystems.png]] (Fig. 3. slurmctld 内の Node Manager・Partition Manager・Job Manager と、slurmd 内の Machine Status・Job Status・Job Control・Remote Execution・Stream Copy の各サブシステムの結線、オプションの Globus/メタスケジューラ連携、および User: srun からの経路を示す図。) ### slurmd slurmd はリモートシェルデーモンに類似した、各計算ノードで動作するマルチスレッドデーモンである。共通の SLURM 設定ファイルと保存済み状態情報を読み込み、コントローラへ activeを通知し、作業を待機・実行・状態返却するサイクルを繰り返す。他ユーザーのジョブを起動するため root 権限で実行される必要がある。5つの主要コンポーネントを持つ: - **Machine and Job Status Services**: コントローラからの状態問い合わせへの応答、非同期の状態変化報告 - **Remote Execution**: プロセス群の起動・管理・後始末(prolog 実行、プロセス制限設定、実効/実 uid 設定、環境変数設定、作業ディレクトリ設定、インターコネクトリソース割当、stdio 初期化、プロセスグループ管理を含む) - **Stream Copy Service**: リモートタスクの stderr/stdout/stdin のハンドリング - **Job Control**: シグナルやジョブ終了要求のリモート実行環境への非同期伝播 単一の設定ファイルが全 SLURM デーモン・コマンドに適用される(**Table 1. Sample SLURM config file**)。設定には `ControlMachine`/`ControlAddr` によるコントローラホスト指定、`AuthType`(認証プラグイン選択)、`PluginDir`(プラグイン検索ディレクトリ)、`NodeName=linux[001-512] CPUs=4 RealMemory=1024 ...` のような数値範囲構文によるノード群定義などが含まれる。ほとんどの情報はコントローラのみが参照し、他のコマンド群はホストとポート情報のみを参照する。 ### slurmctld slurmctld(controller)は、各種データ構造に独立した読み書きロックを持つマルチスレッドデーモンで、SLURM の状態情報の大半を保持する。起動時に設定ファイルと保存済み状態を読み込み、フェイルオーバー双子の状態に応じて master または standby モードで動作する。フルの状態情報は定期的にディスクへ書き出され、フォールトトレランスのため増分変更は即座に書き込まれる。root 権限は不要で、専用ユーザー(SlurmUser)での実行が推奨される。3つの主要コンポーネントを持つ: - **Node Manager**: 各ノードの状態(プロセッサ数、実メモリサイズ、一時ディスク容量、状態、Weight、Feature、IP アドレス)を監視する。実際にノードが登録する資源が設定より少なければ DOWN 状態にして記録する。Weight はノード割当の優先順位付けに、Feature は任意の記述文字列(ソフトウェアパッケージやファイルシステム種別など)として利用される。ノード情報はハッシュテーブル付き配列で管理され、連番付き命名規則により大規模クラスタでも高速な検索が可能。 - **Partition Manager**: ノード群を実際の資源スケジューリング単位として扱う。パーティションは name・RootOnly フラグ・ノードリスト・状態(UP/DOWN)・ジョブごとの最大時間制限・最小/最大ノード数・許可グループリスト・Shared アクセス設定(YES/NO/FORCE)・デフォルトパーティション指定を持つ。ノード・パーティションの UP/IDLE/設定ごとのビットマップを用いた AND 演算により、数万件規模の個別ノード設定比較を回避した高速なスケジューリング判断を実現する。Quadrics インターコネクトはハードウェアメッセージブロードキャストに連続ノード割当を要求するため、可能な限り連続ノードを優先的に割り当てる。 - **Job Manager**: ジョブ名・uid・job id・作業ディレクトリ・パーティション・優先度・ノード制約などを管理し、優先度順のジョブキューに対して周期的または状態変化トリガーでスケジューリングサイクルを実行する。デフォルトの FIFO スケジューリングに加え、外部スケジューラプラグインがジョブ投入前の初期優先度設定や各スケジューリングサイクル開始時の状態変更を行える。LLNL は外部スケジューラとして DPCS(柔軟なスケジューリングアルゴリズムを持つメタスケジューラ)を採用しており、Maui Scheduler も利用可能な外部スケジューラの一例である。 ## コマンドラインユーティリティ - **scancel**: 待機中/実行中のジョブまたはジョブステップを終了、または任意シグナルを送信する。デフォルトシグナルは SIGKILL。 - **scontrol**: root による SLURM 管理用ツール。コントローラの状態保存・終了、設定再読込、primary/backup の状態表示、ジョブ/ジョブステップ/ノード/パーティションの状態表示・更新を行う。 - **sinfo**: パーティションとノードの状態サマリを表示する。 - **squeue**: 実行中・待機中のジョブ/ジョブステップのキュー状態を表示する。 - **srun**: SLURM が管理するリソースへのユーザーインターフェースであり、リソース割当・バッチジョブ投入・インタラクティブジョブ実行・実行中ジョブへのアタッチ・並列タスク(ジョブステップ)起動を担う。interactive・batch・allocate・attach の4モードで動作する。srun のオプション全体は **Table 2. List of srun user options** にまとめられており、attach・allocate・batch・cddir・constraint・contiguous・cpus-per-task・distribution・error/input/output(stdio リダイレクト先)・exclude・immediate・job-name・label・mem・mincpus・no-kill・nodelist・nodes・ntasks・overcommit・partition・share・threads・time・tmp・verbose・version・wait など、ジョブ制約・入出力・時間制限を細かく指定できる約30個のオプションを持つ。 ## プラグイン機構 SLURM は動的リンクされたコードオブジェクトである「プラグイン」を実行時に明示的にロードする汎用機構を持つ。認証・インターコネクトファブリック・タスクスケジューリングなど、明確に定義された API のカスタム実装を提供する。設定ファイルで `AuthType=auth/authd` のように使用プラグインを指定する。認証プラグインは authd・Munge・none の3種が実装済みで、authd は安全なネットワークを前提とするのに対し Munge は前提としない。Kerberos ベースなど他の認証実装も同じ auth プラグイン API を用いて容易に開発できるとされる。 ## セキュリティ SLURM のセキュリティモデルはシンプルである。任意ユーザーは自分のジョブを投入・キャンセルでき、SLURM の設定・状態情報は誰でも閲覧できる。設定変更・任意ジョブのキャンセル・その他の制限操作は root と SlurmUser のような特権ユーザーのみが行える。 - **通信認証**: 従来型の予約ポート + set-uid プログラムに依存する方式ではなく、SLURM は全メッセージに認証クレデンシャルを付与し uid/gid を権威的に検証する認証方式を採用する。実装は auth プラグインに委譲される。 - **ジョブ認証**: コントローラがリソースをユーザーへ割り当てる際、uid・job id・step id・割当ノードリスト・クレデンシャル有効期限を組み合わせ slurmctld の秘密鍵で署名した「job step credential」を生成する。slurmd はコントローラの公開鍵で署名を検証し、有効な場合のみユーザー要求を実行する。 - **認可**: パーティションへのアクセスは RootOnly フラグや AllowGroups 指定により制限できる。 ## ジョブ起動の設計(3モード) **Fig. 4: ジョブ起動時の接続関係の概観** ![[_attachments/SLURM--Simple-Linux-Utility-for-Resource-Management/fig04-job-initiation-connections.png]] (Fig. 4. 1. srun が slurmctld へリソースを要求 → 2. slurmctld がノードリストとジョブステップクレデンシャルを含む応答を返す → 3. srun がジョブ IO 用の待受ポートを開き各 slurmd へ run job step 要求を送信 → 4. 各 slurmd がジョブステップを起動し stdout/err を srun へ接続、という4段階の接続シーケンスを図示。"ephemeral port" と "known port" の凡例付き。) **Fig. 5: インタラクティブジョブ起動のシーケンス** ![[_attachments/SLURM--Simple-Linux-Utility-for-Resource-Management/fig05-interactive-job-initiation.png]] (Fig. 5. srun がリソース割当とジョブステップを slurmctld へ同時要求し、応答後 slurmctld が全 slurmd へ run job step 要求を送信、slurmd 側で prolog・job_mgr・session_mgr・cmd が順に起動し stdout/err を srun へ接続、タスク終了後に release allocation → epilog 実行という流れを示すシーケンス図。破線は周期的な status req/reply。) **Fig. 6: バッチ(キュー投入)ジョブ起動のシーケンス** ![[_attachments/SLURM--Simple-Linux-Utility-for-Resource-Management/fig06-queued-job-initiation.png]] (Fig. 6. srun がバッチ要求を送信し即座に終了、slurmctld がジョブを優先度キューに投入(job queued)後、リソース確保できた時点で最初のノードの slurmd へ run req を送り job_mgr/session_mgr がジョブスクリプトを実行、スクリプト内の srun がさらに job step req を発行して並列タスクを起動、完了後 release step → epilog という流れを示すシーケンス図。) SLURM では3つのジョブ実行モードがある。 1. **インタラクティブモード**: stdout/stderr がユーザー端末にリアルタイム表示され、stdin とシグナルが透過的にリモートタスクへ転送される。srun は slurmctld へリソース割当とジョブステップ初期化を同時要求し、応答後に割当済み各ノードの slurmd へジョブステップ起動要求を送る。各 slurmd はジョブマネージャプロセスとセッションマネージャプロセスをフォークし、IO スレッドが全タスクの IO を srun の待受ポートへ接続する。全タスク終了後、srun は slurmctld へ割当解放要求を送り、slurmctld は各 slurmd へ epilog 実行要求を出してノードをパーティションへ復帰させる。 2. **バッチ(キュー投入)モード**: リソース要求が満たされるまでジョブは待ち行列で待機し、満たされた時点で投入ユーザーとして SLURM がジョブを実行する。srun はバッチ要求送信後すぐに終了する。ジョブスクリプト内から呼ばれる srun がジョブステップを初期化・実行する。 3. **allocate モード**: ジョブがユーザーへ割り当てられ、ユーザーはスクリプトまたはサブシェルから手動でジョブステップを実行できる。srun はリソース割当のみを要求し、割当済みリソースにアクセス可能なシェルを spawn する。サブシェルから引数無しで実行された srun は現在のジョブ内の全ノードでジョブステップを起動する。 **Fig. 7: allocate モードでのジョブ起動シーケンス** ![[_attachments/SLURM--Simple-Linux-Utility-for-Resource-Management/fig07-allocate-mode-initiation.png]] (Fig. 7. srun が allocate req を送信してリソース割当のみを受け取り、ユーザー端末上にシェル(sh)を spawn。そのサブシェルから起動された2つ目の srun が job step req を発行してジョブステップを開始し、prolog・job_mgr・session_mgr・cmd が順に走り stdout/err を接続、ユーザーがシェルを exit すると release allocation → epilog 実行という流れを示すシーケンス図。) いずれのモードでも、ジョブ終了後は slurmctld が割当済み全ノードの slurmd へ epilog 実行を要求し、epilog 成功報告を受けたノードから順にパーティションへ復帰させる。ノードクラッシュや srun の終了は SLURM にとってジョブのクリティカルイベントとして扱われず、ユーザーがジョブ単位でクラッシュ時の挙動(継続 or 終了)を指定できる。 ## フォールトトレランス SLURM は二次(backup)コントローラによるシステムレベルのフォールトトレランスをサポートする。backup コントローラは周期的に primary へ ping し、primary が無応答になると最後の保存状態をロードして制御を引き継ぐ。primary が復旧すると backup へ状態保存・終了を指示し、primary が状態をロードして制御を再開する。SLURM のユーティリティと API 利用者は設定ファイルを読み primary への接続を試み、失敗すれば backup への接続を試みる。 ノードは epilog 実行成功後速やかにパーティションへ復帰し、epilog 実行に失敗したノードや kill 不能なユーザープロセスを持つノードのみがパーティションから外れたまま保持される。 ## 実験設定 - 2002年11月に1000ノードクラスタ上で SLURM のテストを実施(開発途中でチューニング未実施の段階)。 - ベンチマーク内容: `/bin/hostname` を1ノードあたり2タスクで、ノード数を 1, 2, 4, 8, 16, 32, 64, 128, 256, 512, 950 と変化させて実行時間を計測。 - 比較対象: Quadrics Resource Management System(RMS)、IBM LoadLeveler。 ## 実験結果 **Fig. 8: /bin/hostname 実行時間のノード数依存性** ![[_attachments/SLURM--Simple-Linux-Utility-for-Resource-Management/fig08-hostname-scaling.png]] (Fig. 8. 横軸ノード数(1〜950、対数目盛)、縦軸実行時間(秒、対数目盛)で SLURM・RMS・LoadLeveler を比較した折れ線グラフ。SLURM と RMS はほぼ重なる曲線を描き、950ノードで約5秒。LoadLeveler は全ノード数域でおよそ10秒前後とほぼ一定で推移する。) SLURM の性能は全テストしたジョブサイズにおいて Quadrics RMS と同等であり、IBM LoadLeveler より約80倍高速であった。950ノードでの実行時間は SLURM・RMS がおよそ5秒であるのに対し、LoadLeveler は約10秒でほぼノード数に依存しない(定数に近い)挙動を示した。 ## 考察 - SLURM は2003年3月に LLNL の Linux クラスタで本番運用を開始した。 - 今後の拡張として、Quadrics インターコネクト以外(InfiniBand、IBM Blue Gene)のサポート追加、ジョブの preempt/resume 機能(外部スケジューラによる gang scheduling を可能にする)、チェックポイント/リスタート機能、実行中ジョブのノード数変更(MPI2 対応)、ジョブごとの資源使用量記録機能が挙げられている。 - 通信層について、ソケットとイーサネットで1000ノードを問題なく管理できているが、STORM(Quadrics Elan 専用の高速通信・ブロードキャスト機構)のような代替通信メカニズムも検討中とされる。 ## 強み / 弱点・課題 - **強み**: プラグイン機構によりスケジューリングポリシー・認証・インターコネクトを差し替え可能な疎結合設計。スケーラビリティ実証(1000ノードで LoadLeveler の約80倍)。ノード障害の影響をそのノードに閉じ込めるフォールトトレランス設計。 - **弱点・課題(論文内で明示)**: デフォルトスケジューラは単純な FIFO のみで、高度なスケジューリングポリシーは外部スケジューラ(Maui Scheduler, DPCS 等)への依存が前提。共有ノードアクセス(Shared=FORCE)時のリソース制限強制は当時未実装であり将来課題とされている。資源消費量(CPU時間・メモリ使用量)のジョブ単位での記録は将来リリースの計画にとどまっていた。 ## 関連 - [[SLURM]] — 本論文が提案するクラスタリソース管理システムそのもの - [[HPCジョブスケジューリング]] — 本論文が採るシンプルな FIFO + 外部スケジューラプラグインというスケジューリング設計の初期の代表例 - [[Lawrence Livermore National Laboratory]] — 開発元・著者所属機関 - [[@2023__PEARC__Jobstats - A Slurm-Compatible Job Monitoring Platform for CPU and GPU Clusters]] — 20年後に同じ SLURM を対象とした監視基盤の論文 ## 出典 - `.raw/papers/SLURM--Simple-Linux-Utility-for-Resource-Management.pdf` - `.raw/papers/SLURM--Simple-Linux-Utility-for-Resource-Management.txt` - Crossref メタデータ(DOI: 10.1007/10968987_3)で JSSPP 2003 発表・著者構成(Yoo, Jette, Grondona)を確認