Slurmの導入から運用まで：Linux HPCクラスターのリソース管理とジョブスケジューリング

EdwardMoon

Slurmの構築はパッケージのインストールだけでは終わりません。全ノードの時刻とUID・GIDをそろえ、MUNGEの信頼領域を作成してから、コントローラーのslurmctld、計算ノードのslurmd、必要に応じてジョブ履歴・リソース使用量を保存するslurmdbdを順に構成します。

このガイドは役割分担、パッケージ化、slurm.conf、cgroupによるリソース分離、ジョブ履歴・リソース使用量の記録、ジョブ投入と検証、drain、バックアップまでを扱います。例のノード名とリソース値は、必ず実際のslurmd -Cの出力に合わせて変更してください。

用語：SlurmのAccountingは、ジョブごとの実行履歴と、割り当て・使用したリソースの情報を収集、保存、照会する機能です。この記事ではジョブ履歴・リソース使用量の記録と表記します。

役割と障害の影響範囲

コントローラーは計算データ自体を保管しませんが、スケジューラーの状態を保持します。StateSaveLocationを削除したり、2つのコントローラーを同時にアクティブ化したりして障害へ対処しないでください。

ノード、時刻、UID・GIDの前提条件

正引き・逆引きの名前解決、統一されたユーザーの数値ID、NTP同期を先に整えることで、MUNGEとジョブ所有権の整合性が保たれます。LDAPなどの中央ディレクトリを使わない場合は、アカウント作成手順で数値IDを固定します。

hostnamectl --static
getent hosts ctrl01
getent hosts node01
id slurm
id hpcuser
timedatectl status
chronyc tracking
chronyc sources -v

サービスアカウントとディレクトリ

sudo groupadd --system slurm
sudo useradd --system --gid slurm   --home-dir /var/lib/slurm --shell /sbin/nologin slurm
sudo install -d -o slurm -g slurm -m 0750 /var/lib/slurm/controller
sudo install -d -o root -g root -m 0755 /var/lib/slurm
sudo install -d -o root -g root -m 0755 /var/lib/slurm/slurmd
sudo install -d -o slurm -g slurm -m 0750 /var/log/slurm

複数ノードで個別にアカウントを作ると、UID・GIDが異なる場合があります。組織の標準値に固定するか、中央ディレクトリから提供してください。

SlurmdSpoolDirは計算ノードのrootが管理する領域ですが、ジョブユーザーがパスを通過してスクリプトを実行できる必要があります。そのためroot:root、0755で作成し、コントローラーの状態ディレクトリのslurm:slurm、0750と混同しないでください。親の/var/lib/slurmも0755であることを確認します。

再現可能なSlurmパッケージを用意する

本番ではソースディレクトリでmake installを繰り返すよりも、公式リリースのtarballからRPMまたはDEBを作成し、署名した内部リポジトリで固定管理します。コントローラー、ログインノード、計算ノードのSlurmのメジャー・マイナーバージョンと、プラグインのビルドオプションを統一してください。

sha256sum "${SLURM_TARBALL}"
rpmbuild -ta "${SLURM_TARBALL}"
rpm -qp --queryformat '%{NAME} %{VERSION}-%{RELEASE}
'   ~/rpmbuild/RPMS/*/slurm-*.rpm

ディストリビューション、データベース、PMIx、hwloc、cgroupに必要なビルド依存関係は、公式資料と内部のサポートマトリックスで確定します。インターネット上の任意のリポジトリから、コントローラー1台だけにパッケージを導入しないでください。

ビルドしたパッケージを役割ごとにインストールする

rpmbuildはインストールまでは行いません。MUNGEの開発ライブラリ、cgroup v2用のhwloc・libbpf・D-Bus、ジョブ履歴・使用量の保存に使うMySQL/MariaDBの開発ライブラリなど、必要なプラグイン依存関係をビルド前に準備します。同じバージョンのRPMを内部リポジトリへ公開した後、各役割に応じて以下を導入してください。リポジトリには検証済みのビルドを置き、インストール予定のバージョンを先に確認します。

# 内部リポジトリの候補バージョンと提供元を確認
dnf info slurm slurm-perlapi slurm-slurmctld slurm-slurmd slurm-slurmdbd
# ctrl01
sudo dnf install slurm slurm-perlapi slurm-slurmctld
# node01～node04の各計算ノード
sudo dnf install slurm slurm-perlapi slurm-slurmd
# ログインノード
sudo dnf install slurm slurm-perlapi
# acct01：ジョブ履歴・リソース使用量の保存機能を使用する場合
sudo dnf install slurm slurm-slurmdbd

MUNGEの信頼領域を構成する

1つのクラスターに参加する全ノードへ、同じMUNGE鍵を配布します。安全な構成管理経路を使い、mungeユーザーだけが読めるようにしてください。MUNGEはSlurmより先に起動します。

sudo /usr/sbin/mungekey --create
sudo chown munge:munge /etc/munge/munge.key
sudo chmod 0400 /etc/munge/munge.key
sudo systemctl enable --now munge
munge -n | unmunge

コントローラーで作成した鍵を各ノードへ安全に配布し、所有権とハッシュを照合します。鍵の内容をコマンドラインや通常のログへ出力しないでください。

sudo stat -c '%U:%G %a %n' /etc/munge/munge.key
sudo sha256sum /etc/munge/munge.key
remunge

実際のハードウェア情報からslurm.confを作成する

CPU、ソケット、コア、メモリーを推測で設定しないでください。各計算ノードでslurmd -Cを実行し、同じモデルのグループごとにNodeNameを定義します。

slurmd -C
lscpu
free -m
lsblk -o NAME,SIZE,TYPE,MOUNTPOINTS

ClusterName=hpc-prod
SlurmctldHost=ctrl01
SlurmUser=slurm
StateSaveLocation=/var/lib/slurm/controller
SlurmdSpoolDir=/var/lib/slurm/slurmd
SlurmctldLogFile=/var/log/slurm/slurmctld.log
SlurmdLogFile=/var/log/slurm/slurmd.log

AuthType=auth/munge
SelectType=select/cons_tres
SelectTypeParameters=CR_Core_Memory
SchedulerType=sched/backfill
ProctrackType=proctrack/cgroup
TaskPlugin=task/cgroup

AccountingStorageType=accounting_storage/slurmdbd
AccountingStorageHost=acct01
JobAcctGatherType=jobacct_gather/cgroup

NodeName=node[01-04] CPUs=32 RealMemory=125000 State=UNKNOWN
PartitionName=compute Nodes=node[01-04] Default=YES MaxTime=2-00:00:00 State=UP

NodeNameのCPUsとRealMemoryは例です。メモリーは実際のslurmd -Cの値より少し低くしてOS用の余裕を残し、GPUがある場合はGRESとデバイスcgroupの構成を別途検証します。

cgroup v2によるリソース分離

次の内容をslurm.confと同じ設定ディレクトリのcgroup.confに保存します。slurm.confは全参加ノードへ一貫して配布してください。ジョブ履歴・リソース使用量を保存する機能が未準備の場合は、AccountingStorageTypeとAccountingStorageHostの両行を省略するかコメントアウトします。現行Slurmでは、削除されたaccounting_storage/noneを指定するのではなく、AccountingStorageTypeを未設定にすることで永続保存を無効にします。この場合、sacct・sacctmgrの手順はslurmdbdとデータベースを構成した後に行います。

CgroupPlugin=autodetect
ConstrainCores=yes
ConstrainRAMSpace=yes
ConstrainDevices=yes

stat -fc %T /sys/fs/cgroup
scontrol show config | grep -E 'ProctrackType|TaskPlugin|SelectType'
systemd-cgls --no-pager

slurmdbdによるジョブ履歴・リソース使用量の保存

ジョブ履歴、Slurmアカウント別の使用量、QoSを長期管理するには、slurmdbdとサポートされるSQLデータベースを構成します。規模に応じてSQLサーバーを別ホストに分離してください。

次はacct01にslurmdbdと対応するMariaDB/MySQLサーバーを同居させる例です。DBの導入、InnoDB対応、バックアップ方針を先に準備します。DB管理者セッションでslurm_acct_dbとslurmアカウントを作成し、このデータベースだけに権限を与えます。本物のパスワードをシェルの引数や記録ファイルに含めず、管理手順に従って入力してください。大規模環境でSQLを分離する場合は、StorageHostとDBアカウントの接続元ホストを併せて変更します。

-- DB管理者セッションで実行するSQLの例
CREATE DATABASE slurm_acct_db;
CREATE USER 'slurm'@'localhost' IDENTIFIED BY 'REPLACE_WITH_UNIQUE_SECRET';
GRANT ALL ON slurm_acct_db.* TO 'slurm'@'localhost';
SHOW ENGINES;

次の項目を/etc/slurm/slurmdbd.confへ保存し、StoragePassをDBアカウントの実際のパスワードへ変更します。SQLユーザーとOSのslurmユーザーは別のアカウントです。設定が空、または例示用パスワードのままの状態でサービスを起動しないでください。

AuthType=auth/munge
DbdHost=acct01
DbdPort=6819
SlurmUser=slurm
StorageType=accounting_storage/mysql
StorageHost=localhost
StorageUser=slurm
StoragePass=REPLACE_WITH_UNIQUE_SECRET
StorageLoc=slurm_acct_db
LogFile=/var/log/slurm/slurmdbd.log
PidFile=/var/run/slurmdbd.pid

DB資格情報は権限0600のslurmdbd.confまたは秘密情報管理システムで保管し、記事本文やGitに記録しないでください。

# 既存ファイルがあれば先にバックアップする。空のファイルで上書きしない。
sudo install -d -m 0755 /etc/slurm
sudo touch /etc/slurm/slurmdbd.conf
sudo chown slurm:slurm /etc/slurm/slurmdbd.conf
sudo chmod 0600 /etc/slurm/slurmdbd.conf
sudoedit /etc/slurm/slurmdbd.conf
sudo systemctl enable --now slurmdbd
sudo journalctl -u slurmdbd -b --no-pager

クラスターの登録とSlurmアカウント・ユーザーの関連付け（association）は、変更管理手順に従って作成します。Slurmのaccountはプロジェクト・組織別のリソース使用を管理する単位で、OSのログインアカウントとは異なります。associationは、クラスター、Slurmアカウント、ユーザー、任意のパーティションを結ぶ関連付けです。sacctmgrの出力とDBバックアップを残し、削除は事前の照会で対象を確定してから実行します。

sudo sacctmgr add cluster hpc-prod
sudo sacctmgr add account research Description='Research'
sudo sacctmgr add user hpcuser Account=research
sacctmgr show cluster
sacctmgr show association tree

サービスの起動順序と状態確認

1. 全ノードの時刻、名前、UID・GIDを検証する。
2. MUNGEを起動し、ローカルと遠隔の資格情報を試験する。
3. ジョブ履歴・使用量を保存する場合は、先にslurmdbdとDB接続を確認する。
4. コントローラーでslurmctldを起動する。
5. 計算ノードでslurmdを起動する。
6. scontrol・sinfoで構成とノード状態を確認する。

# ctrl01コントローラーでのみ実行
sudo systemctl enable --now slurmctld
# 次のコマンドは各計算ノードで実行
sudo systemctl enable --now slurmd
systemctl --no-pager --full status slurmctld
systemctl --no-pager --full status slurmd
scontrol ping
sinfo --long
scontrol show nodes

対話型ジョブとバッチジョブで検証する

srun --partition=compute --nodes=1 --ntasks=1   hostname
srun --partition=compute --nodes=2 --ntasks-per-node=2   /bin/hostname

#!/usr/bin/env bash
#SBATCH --job-name=smoke-test
#SBATCH --partition=compute
#SBATCH --nodes=2
#SBATCH --ntasks-per-node=2
#SBATCH --time=00:05:00
#SBATCH --output=slurm-%j.out

set -euo pipefail
hostname
srun --label /bin/hostname

JOB_ID=$(sbatch --parsable smoke-test.sbatch)
squeue --job "$JOB_ID"
sacct --jobs "$JOB_ID"   --format=JobID,State,Elapsed,AllocCPUS,MaxRSS,ExitCode
scontrol show job "$JOB_ID"

ノードのdrain、復旧、安全な運用

sudo scontrol update NodeName=node03   State=DRAIN Reason='planned maintenance'
scontrol show node node03
squeue --nodelist=node03

sudo scontrol update NodeName=node03 State=RESUME
sinfo --nodes=node03 --long

DOWNやDRAINのノードを無条件にRESUMEせず、Reason、slurmdのログ、ハードウェアイベント、ファイルシステムの状態を先に確認します。ジョブ実行中のノードでは、方針に従って完了を待つか、再キュー投入するか、取り消すかを判断してください。

sudo journalctl -u slurmd --since '-30 minutes' --no-pager
sudo journalctl -u slurmctld --since '-30 minutes' --no-pager
scontrol show node node03
sdiag

バックアップと障害復旧

• slurm.conf、cgroup.conf、gres.conf、配布自動化の原本をバージョン管理する。
• StateSaveLocationはサービスの整合性を考慮してバックアップし、権限を保持する。
• slurmdbdのDBはトランザクション整合性を保ってバックアップし、復元試験を行う。
• MUNGE鍵を暗号化した秘密情報保管庫に別途保存し、アクセスを監査する。
• 待機コントローラーは公式HA方式で構成し、slurmctldデーモンを起動しておく。アクティブなスケジューラーは1つに保ち、待機デーモンの昇格と復帰はSlurmに調整させる。独立した主コントローラー2台が同じ状態へ書き込む構成にしない。

公式資料と関連ガイド

• SchedMD：SlurmdSpoolDirの権限とslurm.conf
• SchedMD：ジョブ履歴・リソース使用量のデータベース構成
• SchedMD：slurmdbd.confの必須設定

• SchedMD：Slurm管理者向けQuick Start
• SchedMD：slurm.conf構成ツール
• SchedMD：cgroup v2ガイド
• Rocky Linuxのインストールと初期セキュリティ設定
• SSH鍵認証と管理アカウントの保護

構築の完了基準は、デーモンがactiveであることではなく、MUNGE認証、リソース分離、複数ノードのジョブ、ジョブ履歴・リソース使用量の記録、drain・resume、バックアップと復元試験がすべて成功することです。自動確認として残し、ノード追加やバージョン更新時に繰り返してください。