チュートリアル: クラスタでアカウントとジョブ スケジューリングを管理する

Vertex AI Training クラスタに関心をお持ちの場合は、営業担当者にお問い合わせください。

このガイドでは、Slurm のアカウンティング機能とサービス品質（QOS）機能を使用して、優先度とリソース要件が異なる複数のチームで共有される単一のトレーニング クラスタを効果的に管理する方法について説明します。

目標

このチュートリアルを終了すると、次のことができるクラスタ リソースを管理するためのフレームワークが完成します。

  • チームごとにリソース上限を適用します。
  • 緊急度に基づいてジョブの優先順位を付け、プリエンプトします。
  • リソース使用量の明確な会計処理を提供する。
  • 公平性を維持しながら、クラスタの使用率を最大化します。

前提条件

  • アカウントの管理、ジョブのスケジュール設定と優先順位付けを行うように構成されたアカウンティング、プリエンプション、優先度を備えた実行中のトレーニング クラスタ。

  • オーケストレート

  • Slurm の詳細設定

  • 管理者コマンドを実行するためのクラスタのログインノードに対する sudo アクセス。

コアコンセプト: Slurm アカウンティングの構成要素

Slurm は、明確で柔軟な階層を使用してリソースを管理します。この 4 つの構成要素を理解することが重要です。

コンポーネント 例 目的
アカウント チームまたはプロジェクト ユーザーをグループ化し、リソースの全体的な上限を設定するための基本単位（たとえば、team_ace は最大 10 個のノードを使用できます）。
ユーザー 個人の研究者 ジョブを送信するユーザー。すべてのユーザーはデフォルトのアカウントに属している必要があります。
パーティション ハードウェア キュー ノードの論理グループ。柔軟性を最大限に高めるには、すべてのノードを含む単一のパーティションをおすすめします。
QOS ルールブック ジョブの上限（「この QOS のジョブは 2 つのノードのみを使用できる」など）とスケジューリングの優先度を定義する名前付きのルールのセット。

このモデルでは、アカウント全体の高レベルの割り当てを設定し、QOS を使用してより詳細なジョブごとの上限を適用できます。

ペルソナ: 管理者と研究者

このシステムには、クラスタ管理者と研究者の 2 つの異なるロールが関与します。

クラスタ管理者

  • 主なツール: sacctmgr（Slurm アカウント マネージャー）
  • お客様の役割: アカウント、ユーザー、QOS ルールの「スキャフォールディング」を構築します。通常、これは「一度構成し、必要に応じて更新する」タスクです。
  • 主なタスク: アカウントの作成、アカウントへのユーザーの割り当て、QOS ルールブックの定義、それらのリンク。

調査担当者

  • 主なツール: 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 個のジョブに制限します。

  • 目標: チーム全体のリソース上限を設定する。

  • 方法: GrpJobs（グループ ジョブ）と GrpTRES（グループ トラッキング可能なリソース。この場合は node=6）を使用して、この上限を team_ace アカウントに適用します。

# --- (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 として次のテストを実行します。

  1. ノードの上限: 7 ノードのジョブを送信すると失敗するようになりました。ジョブは、理由（AssocGrpNodeLimit）とともに保留（PD）状態になります。
  2. ジョブの制限: 5 つの単一ノードジョブを送信すると、4 つのジョブが実行され（R）、5 つ目のジョブが保留（PD）になり、理由（AssocGrpJobsLimit）が返されます。

アカウント単位の上限は正常に機能しています。

パート 3: QOS を使用してジョブごとの上限を追加する

アカウント レベルのグループの上限は、チームのリソース使用量の合計を制限するのに有効です。ただし、チームの割り当て全体を消費する単一のジョブをユーザーが送信することを防ぐことはできません。個々のジョブのサイズを制御するには、次の手順でサービス品質（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 がインターンで、チームの他のメンバーに影響を与えずに、さらに小さなジョブに制限する必要がある場合はどうすればよいですか？

  • 目標: 1 人のユーザーに制限を厳しく適用する。
  • 方法: 新しい、より制限的な 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

結果: qos1 で以前に許可されていた 2 ノードジョブを user_alice が送信しようとすると、QOSMaxNodePerJobLimit で失敗します。より具体的なユーザーレベルのルールが、一般的なアカウント レベルのルールを正常にオーバーライドしました。

パート 5: 優先度とプリエンプションを構成する

最後に、クラスタが満杯の場合でも重要なジョブをすぐに実行できるように、ジョブの優先度とプリエンプションを構成します。

  • 目標: 優先度の低いジョブを一時停止またはキャンセルしてリソースを解放できる、優先度の高い「緊急」QOS を作成します。

  • メソッド:

    1. Priority 値の高い新しい qos_urgent を作成します。
    2. qos1 で実行されているジョブを Preempt する権限を qos_urgent に付与します。
    3. ジョブがプリエンプトされたときに 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. 1 つのターミナルで、user_alice はデフォルトの qos1 を使用して長時間実行ジョブを送信します。実行が開始されます（R）。
  2. 2 番目のターミナルで、user_alice は緊急 QOS（sbatch --qos=qos_urgent ...）を使用して大規模なジョブを送信します。
  3. 数秒以内に、最初のジョブの状態が実行中（R）から保留中（PD）に変わり、理由が（Preempted）になります。その後、緊急ジョブの実行が開始されます。

完了しました。優先度の高い作業が優先度の低い作業を自動的に置き換えるシステムを構成しました。

まとめと次のステップ

このチュートリアルでは、Slurm の階層型アカウンティング機能を使用して、共有クラスタをきめ細かく制御する方法を学習しました。次の操作が可能になりました。

  • グローバル上限を設定する: アカウントを使用して、チーム全体のリソース割り当ての合計を設定します。
  • ジョブごとのルールを適用する: QOS を使用して、個々のジョブのサイズと優先度を制御します。
  • 特定のオーバーライドを作成する: きめ細かい制御のために、ユーザーに別の QOS を適用します。
  • 優先度の保証: 重要なワークロードが常に実行されるようにプリエンプションを構成します。

この階層モデルは、クラスタ リソースを公平かつ効率的に管理するための柔軟で強力な方法を提供します。より高度な構成については、Slurm の公式ドキュメントをご覧ください。