このガイドでは、Slurm のアカウンティング機能と Quality of Service (QOS) 機能を使用して、優先度とリソース要件が異なる複数のチームで共有される単一のトレーニング クラスタを効果的に管理する方法について説明します。
目標
このチュートリアルを修了すると、クラスタ リソースを管理するためのフレームワークが完成します。このフレームワークでは、次のことが可能です。
- チームごとにリソース上限を適用する。
- 緊急度に基づいてジョブの優先順位を付けてプリエンプトする。
- リソース消費量を明確にアカウンティングする。
- 公平性を維持しながらクラスタの使用率を最大化する。
前提条件
アカウントの管理、ジョブのスケジュール設定と優先順位付けを行うようにアカウンティング、プリエンプション、優先度が構成されたトレーニング クラスタが実行されていること。
管理者コマンドを実行するためのクラスタのログインノードに対する
sudoアクセス権。
コアコンセプト: Slurm アカウンティングの構成要素
Slurm は、明確で柔軟な階層を使用してリソースを管理します。これら 4 つの構成要素を理解することが重要です。
| コンポーネント | 例 | 目的 |
|---|---|---|
| アカウント | チームまたはプロジェクト | ユーザーをグループ化し、全体的なリソース上限を設定するための基本単位（たとえば、team_ace は最大 10 個のノードを使用できます）。 |
| ユーザー | 個々の研究者 | ジョブを送信する担当者。すべてのユーザーはデフォルト アカウントに属している必要があります。 |
| パーティション | ハードウェア キュー | ノードの論理グループ。最大限の柔軟性を実現するには、すべてのノードを含む単一のパーティションをおすすめします。 |
| QOS | rulebook | ジョブの上限（たとえば、「この QOS のジョブは 2 つのノードのみを使用できる」）とスケジューリングの優先度を定義する名前付きのルールセット。 |
このモデルでは、アカウント全体に高レベルの割り当てを設定し、QOS を使用してより詳細なジョブ単位の上限を適用できます。
ペルソナ: 管理者と研究者
このシステムには、クラスタ管理者と研究者という 2 つの異なるロールがあります。
クラスタ管理者
- 主なツール:
sacctmgr（Slurm アカウント マネージャー） - ジョブ: アカウント、ユーザー、QOS ルールの「スキャフォールディング」を構築します。 通常、これは「一度構成したら、必要に応じて更新する」タスクです。
- 主なタスク: アカウントの作成、アカウントへのユーザーの割り当て、QOS rulebook の定義、それらのリンク。
研究者
- 主なツール:
sbatch、squeue、sinfo - ジョブ: 研究ジョブの送信とモニタリング。
- 仕組み: 研究者がジョブを送信すると、Slurm はアカウントと QOS に関連付けられたルールを自動的にチェックします。ジョブが上限に違反している場合、Slurm は明確なエラー メッセージとともにジョブを拒否します。
チュートリアル: 段階的なチュートリアル
次のチュートリアルでは、一連の段階的なシナリオを通じて、これらのコンセプトを実践します。このチュートリアルでは、クラスタ管理者のロールを想定しています。タスクは、1 つのアカウント team_ace と 1 人のユーザー user_alice を設定することです。シナリオは上限なしで始まり、段階的に制御レイヤを追加していきます。
パート 1: 初期設定（上限なし）
アカウントを作成し、ユーザーを関連付けます。
- 目標:
team_aceとuser_aliceの基本的な階層を作成します。 - 方法:
sacctmgrを使用してアカウントを追加し、そのアカウントに関連付けられたユーザーを追加します。
# --- (Run as Admin) ---
# 1. Create the 'team_ace' account
sudo sacctmgr add account team_ace Description="The Ace Team"
# 2. Create the 'user_alice' user and map them to their default account
# (Note: 'user_alice' must already exist as a Linux user on the node)
sudo sacctmgr add user user_alice Account=team_ace
# 3. Show the hierarchy we just built to confirm
sacctmgr show associations where account=team_ace
結果: ユーザー user_alice として、大規模なジョブを送信できるようになりました。上限がないため、7 ノードのジョブが受け入れられ、すぐに実行されます（7 つのノードがアイドル状態であると仮定します）。
パート 2: アカウントにグループレベルの上限を追加する
次に、team_ace アカウントにリソース上限を適用し、チーム全体を最大 6 ノードと合計 4 つのジョブに制限します。
目標: チーム全体に合計リソース上限を設定します。
方法: この上限は、
team_aceアカウントにGrpJobs（グループ ジョブ）とGrpTRES（グループ トラッキング可能なリソース。この場合はnode=6）を使用して適用します。
# --- (Run as Admin) ---
# 1. Add group-level job and node limits to the 'team_ace' account
sudo sacctmgr modify account where name=team_ace set GrpJobs=4 GrpTRES=node=6
# 2. View the limits to confirm the change
sacctmgr show association where account=team_ace
結果: 新しい上限が機能していることを確認するには、user_alice として次のテストを行います。
- ノードの上限: 7 ノードのジョブを送信すると失敗します。ジョブは保留（
PD）状態になり、理由（AssocGrpNodeLimit）が表示されます。 - ジョブの上限: 5 つの単一ノード ジョブを送信すると、4 つのジョブが実行され（
R）、5 つ目のジョブが保留（PD）状態になり、理由（AssocGrpJobsLimit）が表示されます。
アカウント レベルの上限は正常に機能しています。
パート 3: QOS でジョブ単位の上限を追加する
アカウント レベルのグループ上限は、チームの合計リソース使用量を制限するのに有効です。ただし、ユーザーがチームの割り当て全体を消費する単一のジョブを送信することを防ぐことはできません。個々のジョブのサイズを制御するには、次のステップで Quality of Service（QOS）を使用します。
- 目標: チームが送信する個々のジョブの最大サイズを制限します。
- 方法:
MaxTRESPerJob=node=2ルールを使用して、qos1という名前の Quality of Service（QOS）を作成します。次に、これをteam_aceアカウント全体のデフォルトの QOS にします。
# --- (Run as Admin) ---
# 1. Create a QOS with a per-job limit of 2 nodes
sudo sacctmgr add qos qos1 MaxTRESPerJob=node=2
# 2. Allow the 'team_ace' account to use this QOS
sudo sacctmgr modify account where account=team_ace set QOS=qos1
# 3. Set 'qos1' as the DEFAULT QOS for all users in this account
sudo sacctmgr modify account where account=team_ace set DefaultQOS=qos1
結果: user_alice が 3 ノードのジョブを送信すると、ジョブは
保留状態になり、理由（QOSMaxNodePerJobLimit）が表示されます。ユーザーは合計
アカウント割り当て（6 ノード）内ですが、
ジョブ単位のQOSルールに違反しています。
パート 4: ユーザー固有のオーバーライドを追加する
user_alice がインターンで、チームの他のメンバーに影響を与えることなく、さらに小さなジョブに制限する必要がある場合はどうすればよいでしょうか？
- 目標: 単一のユーザーに、より厳しい制限を適用します。
- 方法: 新しい、より厳しい QOS（
qos_intern）を作成し、user_aliceのデフォルトとして適用します。これにより、アカウントのデフォルトの QOS がオーバーライドされます。
# --- (Run as Admin) ---
# 1. Create a more restrictive QOS with a 1-node limit
sudo sacctmgr add qos qos_intern MaxTRESPerJob=node=1
# 2. Allow the account to use this new QOS
sudo sacctmgr modify account where account=team_ace set QOS+=qos_intern
# 3. Apply 'qos_intern' as the default QOS for the specific user association
sudo sacctmgr modify user where name=user_alice account=team_ace set DefaultQOS=qos_intern
結果: user_alice が qos1 で以前に許可されていた 2 ノードのジョブを送信しようとすると、QOSMaxNodePerJobLimit で失敗します。より具体的なユーザーレベルのルールが、一般的なアカウント レベルのルールを正常にオーバーライドしました。
パート 5: 優先度とプリエンプションを構成する
最後に、ジョブ の優先度とプリエンプション を構成して、クラスタが満杯の場合でも重要なジョブをすぐに実行できるようにします。
- 目標: 優先度の低いジョブを一時停止またはキャンセルしてリソースを解放できる、優先度の高い「緊急」QOS を作成します。
方法:
- 高い
Priority値で新しいqos_urgentを作成します。 qos_urgentに、qos1で実行中のジョブをPreemptできることを伝えます。- ジョブがプリエンプトされたときに
qos1がジョブをREQUEUEするように構成します。
- 高い
# --- (Run as Admin) ---
# 1. Create a new 'qos_urgent' with a high priority that can preempt 'qos1'
sudo sacctmgr add qos qos_urgent Priority=1000 Preempt=qos1
# 2. Configure 'qos1' to requeue preempted jobs after a 10-second grace period
sudo sacctmgr modify qos where name=qos1 set PreemptMode=REQUEUE GraceTime=10
# 3. Allow the 'team_ace' account and 'user_alice' to use this new QOS
sudo sacctmgr modify account where account=team_ace set QOS+=qos_urgent
sudo sacctmgr modify user where name=user_alice account=team_ace set QOS+=qos_urgent
# 4. For this scenario, remove the group limits so preemption is easier to trigger
sudo sacctmgr modify account where name=team_ace set GrpJobs=-1 GrpTRES=node=-1
結果:
- 1 つのターミナルで、
user_aliceはデフォルトのqos1で長時間実行されるジョブを送信します。実行が開始されます（R）。 - 2 つ目のターミナルで、
user_aliceは緊急 QOS（sbatch --qos=qos_urgent ...）を使用して大規模なジョブを送信します。 - 数秒以内に、最初のジョブの状態が実行中（R）から保留（
PD）に変わり、理由がPreemptedになります。その後、緊急ジョブの実行が開始されます。
完了しました。優先度の高い作業が優先度の低い作業を自動的に置き換えるシステムを構成しました。
まとめと次のステップ
このチュートリアルでは、Slurm の階層型アカウンティング機能を使用して、共有クラスタをきめ細かく制御する方法を学びました。 次の操作が可能になりました。
- グローバル上限を設定する: アカウントを使用して、チーム全体のリソース割り当ての合計を設定します。
- ジョブ単位のルールを適用する: QOS を使用して、個々のジョブのサイズと優先度を制御します。
- 特定のオーバーライドを作成する: きめ細かい制御を行うために、ユーザーに別の QOS を適用します。
- 優先度を保証する: プリエンプションを構成して、重要なワークロードを常に実行できるようにします。
この階層化されたモデルは、クラスタ リソースを公平かつ効率的に管理するための柔軟で強力な方法を提供します。さらに高度な構成については、 公式の Slurm ドキュメントをご覧ください。