RHEL 9 EC2環境でSlurm Job Schedulerを検証してみた。
こんにちは、クラスメソッドのキム・ジェウク（Kim Jaewook）です。
今回は、RHEL 9 EC2環境でSlurm Job Schedulerを検証してみました。
元々は、LSF（Load Sharing Facility） Job Schedulerの検証を行う予定でしたが、LSFはIBMが提供する商用ソフトウェアであるため、検証用のテスト環境を構築するにはいくつかの制約がありました。
そのため、LSFと同様の機能を持つオープンソースのJob SchedulerであるSlurmを利用し、Job Schedulingの動作を検証してみました。
Job Schedulerは、CADシミュレーションのように大量の計算リソースを必要とする処理を複数のユーザーが同時に実行する環境において、サーバーリソースを効率的に管理・割り当てる役割を担います。
例えば、複数のユーザーが同時にシミュレーションの実行を要求した場合、Job Schedulerは、サーバーのCPUやメモリなどのリソース使用状況を確認し、ジョブの実行順序や各ジョブに割り当てるリソース量を決定します。
ユーザーA：シミュレーション実行
ユーザーB：シミュレーション実行 → Slurm / LSF → サーバーリソースの使用状況を確認
ユーザーC：シミュレーション実行 → 実行待ちキューへ登録 → リソースを割り当て後に実行
LSF vs Slurm
| 項目 | LSF | Slurm |
|---|---|---|
| コスト | 有料（IBM） | 無料（オープンソース） |
| 主要コマンド | bsub, bjobs | sbatch, srun, squeue |
| ジョブ管理の概念 | 同一 | 同一 |
| 主な使用分野 | HPC、EDA、研究環境 | HPC、研究環境、クラスタ環境 |
LSFとSlurmでは、利用するコマンドや細かい機能に違いがありますが、ユーザーがジョブを実行し、スケジューラーがリソースを管理した上でジョブを実行するという基本的な動作は同じです。
やりたいこと
今回のブログでは、次を実装します。
- マスターから
srun --nodes=1 --ntasks=1 hostnameを実行 slurmctldがワーカーノードの状態（Idle）を確認slurmctldがワーカーノード上のslurmdに「hostnameを実行」と指示slurmdがhostnameコマンドを実行- 実行結果（ip-xx-x-xxx-xxx...）をマスターノードへ返却
各サーバーの役割は以下の通りです。
- slurmctld（マスターノード）
- クラスタ全体の管理
- ジョブキューの管理（ジョブの実行順序や実行ノードを決定）
- ワーカーノードの状態監視
- 実際のジョブ実行は行わない
- slurmd（ワーカーノード）
- マスターノードからの指示を受け、実際のジョブを実行するデーモン
- 常にバックグラウンドで待機し、マスターノードからジョブ実行指示を受けると処理を開始する
セキュリティグループ設定
まず、マスターノードのセキュリティグループのインバウンドルールを設定します。
マスターSGインバウンドルール
| ポート | プロトコル | ソース | 用途 |
|---|---|---|---|
| 6817 | TCP | ワーカーSG | Slurm Controller |
| 6818 | TCP | ワーカーSG | Slurm Daemon |
| 6819 | TCP | ワーカーSG | Slurm DBD |
| 1024-65535 | TCP | ワーカーSG | IO通信（Ephemeral Port） |
※ 1024-65535の範囲は、SlurmがIO通信に一時的なポート（Ephemeral Port）を利用するため必要になります。このルールが設定されていない場合、ジョブ実行時にタイムアウトが発生します。
続いて、ワーカーノードのセキュリティグループのインバウンドルールを設定します。
ワーカーSGインバウンドルール
| ポート | プロトコル | ソース | 用途 |
|---|---|---|---|
| 6817 | TCP | マスターSG | Slurm Controller |
| 6818 | TCP | マスターSG | Slurm Daemon |
Step 1. マスターノードの設定
SSM Session Managerでマスターノードに接続した後、設定を進めます。
EPELリポジトリ追加及びSlurmインストール
sudo dnf install -y https://dl.fedoraproject.org/pub/epel/epel-release-latest-9.noarch.rpm
sudo dnf install -y slurm slurm-slurmctld slurm-slurmd munge
Mungeキー作成及び起動
Mungeは、マスターノードとワーカーノード間の通信認証に使用するツールです。
sudo /usr/sbin/create-munge-key
sudo systemctl enable munge
sudo systemctl start munge
sudo systemctl status munge
slurmユーザー作成
Slurmデーモンを実行するため、システムユーザーを作成します。
sudo useradd -r -s /sbin/nologin slurm
Slurm設定ファイル作成
slurm.confは、ジョブを実行するノードや使用するリソースなど、Slurmクラスタの基本設定を定義するファイルです。
- マスターノードの指定
- ワーカーノードの指定
- 使用可能なCPU数
- 通信ポート番号
sudo tee /etc/slurm/slurm.conf << 'EOF'
ClusterName=test-cluster
SlurmctldHost=ip-10-0-xxx-xxx.ap-northeast-1.compute.internal
SlurmUser=slurm
SlurmctldPort=6817
SlurmdPort=6818
AuthType=auth/munge
StateSaveLocation=/var/spool/slurmctld
SlurmdSpoolDir=/var/spool/slurmd
SchedulerType=sched/backfill
SelectType=select/cons_tres
SlurmctldLogFile=/var/log/slurmctld.log
SlurmdLogFile=/var/log/slurm.log
NodeName=ip-10-0-yyy-yyy.ap-northeast-1.compute.internal CPUs=2 State=UNKNOWN
PartitionName=debug Nodes=ip-10-0-yyy-yyy.ap-northeast-1.compute.internal Default=YES MaxTime=INFINITE State=UP
EOF
ディレクトリ作成及びslurmctld起動
sudo mkdir -p /var/spool/slurmctld
sudo chown slurm:slurm /var/spool/slurmctld
sudo touch /var/log/slurmctld.log
sudo chown slurm:slurm /var/log/slurmctld.log
sudo systemctl enable slurmctld
sudo systemctl start slurmctld
sudo systemctl status slurmctld
実行結果
● slurmctld.service - Slurm controller daemon
Active: active (running)
Main PID: 17575 (slurmctld)
Step 2. Mungeをワーカーノードにコピー
マスターノードとワーカーノードが同じMungeキーを共有することで、通信認証が可能になります。
マスターでキーを確認
sudo cat /etc/munge/munge.key | base64
ワーカーにキーをコピー
ワーカーノードにSSMで接続した後、以下のコマンドを実行します。
sudo bash -c 'echo "マスターからコピーした_base64値" | base64 -d > /etc/munge/munge.key'
sudo chmod 400 /etc/munge/munge.key
sudo chown munge:munge /etc/munge/munge.key
Step 3. ワーカーノードの設定
EPELリポジトリ追加及びSlurmインストール
sudo dnf install -y https://dl.fedoraproject.org/pub/epel/epel-release-latest-9.noarch.rpm
sudo dnf install -y slurm slurm-slurmd munge
slurmユーザー作成
sudo useradd -r -s /sbin/nologin slurm
Munge起動
sudo systemctl enable munge
sudo systemctl start munge
sudo systemctl status munge
Slurm設定ファイル作成（マスターノードと同じ設定）
sudo tee /etc/slurm/slurm.conf << 'EOF'
ClusterName=test-cluster
SlurmctldHost=ip-10-0-xxx-xxx.ap-northeast-1.compute.internal
SlurmUser=slurm
SlurmctldPort=6817
SlurmdPort=6818
AuthType=auth/munge
StateSaveLocation=/var/spool/slurmctld
SlurmdSpoolDir=/var/spool/slurmd
SchedulerType=sched/backfill
SelectType=select/cons_tres
SlurmctldLogFile=/var/log/slurmctld.log
SlurmdLogFile=/var/log/slurmd.log
NodeName=ip-10-0-yyy-yyy.ap-northeast-1.compute.internal CPUs=2 State=UNKNOWN
PartitionName=debug Nodes=ip-10-0-yyy-yyy.ap-northeast-1.compute.internal Default=YES MaxTime=INFINITE State=UP
EOF
ディレクトリ作成及びslurmd起動
sudo mkdir -p /var/spool/slurmd
sudo chown slurm:slurm /var/spool/slurmd
sudo touch /var/log/slurmd.log
sudo chown slurm:slurm /var/log/slurmd.log
sudo systemctl enable slurmd
sudo systemctl start slurmd
sudo systemctl status slurmd
実行結果
● slurmd.service - Slurm node daemon
Active: active (running)
Main PID: 17584 (slurmd)
slurmd: slurmd version 22.05.9 started
slurmd: CPUs=2 Boards=1 Sockets=2 Cores=1 Threads=1 Memory=1713
Step 4. 動作確認
マスターノードから動作確認を行います。
ノード状態確認
sinfo
実行結果
PARTITION AVAIL TIMELIMIT NODES STATE NODELIST
debug* up infinite 1 idle ip-10-0-yyy-yyy.ap-northeast-1.compute.internal
ワーカーノードがidle状態で、正常に接続されていることを確認できます。
ジョブ実行テスト
srun --nodes=1 --ntasks=1 hostname
実行結果
ip-10-0-yyy-yyy.ap-northeast-1.compute.internal
マスターノードからジョブを実行すると、ワーカーノード上で処理が実行され、結果が返却されることを確認できます。
最後に
今回の検証では、RHEL 9ベースのEC2環境でSlurmクラスタを構築し、マスターノードから投入したジョブがワーカーノード上で実行される一連の流れを確認しました。
今回は単純なhostnameコマンドの実行でテストしましたが、実際のHPCやEDA環境では、この部分にCADシミュレーション実行スクリプトや大規模計算処理を配置することで、同じ仕組みで処理を実行できます。
全体の動作フローは以下の通りです。
ユーザー
↓
ジョブ投入（srun / sbatch）
↓
slurmctld（マスターノード）
↓
リソース状態確認及び実行ノード決定
↓
slurmd（ワーカーノード）
↓
ジョブ実行
↓
結果返却
今回のテストを通じて、LSFのような商用ジョブスケジューラが提供する基本的な動作構造を、Slurm環境でも確認することができました。
もちろん、実際の運用環境では、複数のワーカーノード構成、GPUリソース管理、ユーザーごとのキュー設定、ジョブ優先度管理など、追加の設定が必要になります。
しかし、基本的な「ジョブ投入 → リソース割り当て → ジョブ実行 → 結果返却」という処理フローは、今回構築した検証環境と同じ仕組みで動作します。
