AWS ParallelCluster の Slurm を CVE 対応の 25.11.8 にアップグレードしてみた
はじめに
2026 年 9 月 3 日に AWS ParallelCluster の GitHub リポジトリで気になる Issue が公開されました。バージョン 3.16.0 以前のすべての ParallelCluster が Slurm の 8 件の CVE の影響を受けるという内容です。CVE を修正した Slurm 25.11.8 が入った ParallelCluster は、執筆時点（2026 年 9 月 5 日）でリリースされていません。
クラスターをすぐ作り直せない場合の選択肢としてインプレースアップグレードの手順が公開されていました。というわけで、稼働中のクラスターの Slurm を 25.11.6 から 25.11.8 へインプレースアップグレードを試してみました。
確認結果
- Slurm 25.11.8 のビルドは 物理コア 8 個のヘッドノードでおよそ 4 分
- 全体の作業時間は 8 分 30 秒 でした
- フリート再開後に起動したコンピュートノードは 25.11.8 で動いていた
なにが起きているのか
Slurm 25.11.8 は 2026 年 9 月 2 日にリリースされました。修正されたのは次の 8 件です。
CVE-2026-65107 CVE-2026-65108 CVE-2026-65109 CVE-2026-65138
CVE-2026-65139 CVE-2026-65140 CVE-2026-65165 CVE-2026-65168
それぞれの内容はリリースノートを参照してください。
ParallelCluster への影響
影響を受ける Slurm は 25.05.9、25.11.8、26.05.4 より前の全バージョンです。残念なことにすべての ParallelCluster の Slurm はいずれもこの範囲です。
Slurm のバージョンはピリオド区切りの 3 つの数字です。先頭 2 つの YY.MM がメジャーリリースで、3 つ目はメンテナンスリリースです。
| ParallelCluster | Slurm | リリース日 | 25.11.8 へのアップグレード |
|---|---|---|---|
| 3.13.0 | 24.05.7 | 2025/04/01 | メジャーアップグレード（追加手順あり） |
| 3.13.1、3.13.2 | 24.05.8 | 2025/06/04、2025/06/24 | メジャーアップグレード（追加手順あり） |
| 3.14.0 | 24.11.6 | 2025/09/30 | メジャーアップグレード（追加手順あり） |
| 3.14.1、3.14.2 | 24.11.7 | 2025/12/22、2026/02/16 | メジャーアップグレード（追加手順あり） |
| 3.15.0、3.15.1 | 25.11.4 | 2026/03/23、2026/05/28 | メンテナンスアップグレード |
| 3.16.0 | 25.11.6 | 2026/08/20 | メンテナンスアップグレード |
メジャーアップグレードの追加作業は、Slurm アカウンティングを使っていればデータベースのスキーマ変換、libslurm に対してビルドしたプラグインがあればその再ビルドも必要とのことです。今回検証するのはメンテナンスアップグレードです。
サポート期限
ParallelCluster はリリースごとに EOSL（End of Support Life）が決められています。EOSL を過ぎたリリースにはサポートは提供されません。期限を過ぎたバージョンを使っている場合は、サポート対象のバージョンでクラスターを作り直しを検討ください。今なら v3.16.0 で作り直しか、対策されるであろう v3.16.1 のリリースを待つかです。
- 3.12.x: 2026 年 6 月 30 日（終了）
- 3.13.x: 2026 年 9 月 30 日
- 3.14.x: 2027 年 3 月 29 日
- 3.15.x: 2027 年 9 月 23 日
- 3.16.x: 2028 年 2 月 20 日
クラスターを作り直さずに対応できる
新しい Slurm のバージョンを使う正攻法は、そのバージョンが入った ParallelCluster のバージョンでクラスターを作り直すことです。
とはいえ、大規模に展開しているクラスター環境や、今々ジョブが流れているクラスターの作り直し、ユーザーの移行は丸っと環境構築の手間が伴います。CVE の公表から数日で作り直すのが難しいことの方が多いでしょう。
今回の対策として稼働中のクラスターの Slurm を入れ替える手順が公開されています。サポート対象のすべての ParallelCluster に適用できると案内されているので試してみます。
Upgrade Slurm in an AWS ParallelCluster cluster · aws/aws-parallelcluster Wiki
検証環境
ヘッドノードを 8 vCPU にしたのは、後述のスクリプトが Slurm をソースからビルドするため、ある程度コア数が欲しかったので大きめにしました。クラスターの構築手順は省略します。
| 項目 | 値 |
|---|---|
| リージョン | ap-northeast-1 |
| ParallelCluster | 3.16.0 |
| OS | Ubuntu 24.04 |
| Slurm（アップグレード前） | 25.11.6 |
| ヘッドノード | m7a.2xlarge |
| コンピュートノード | t3a.small（MinCount 0 / MaxCount 2） |
| Slurm アカウンティング | なし |
| ログインノード | なし |
アップグレードの手順
今回はアカウンティングとログインノードを使わない構成です。これらを使っている場合は、外部の slurmdbd の扱いとログインノードの停止について公式 Wiki の該当する手順も確認してください。
Upgrade Slurm in an AWS ParallelCluster cluster · aws/aws-parallelcluster Wiki
ヘッドノードでビルドし直せば OK
ParallelCluster は Slurm を /opt/slurm にインストールします。このディレクトリはクラスター内で共有されます。既定ではヘッドノードの EBS ボリューム上に作られ、NFS エクスポートとしてコンピュートノード、ログインノードへ共有されます。
The following directories are shared between the head node, compute nodes, and login nodes:
/opt/slurm/opt/intel/opt/parallelcluster/shared (only with compute nodes)/opt/parallelcluster/shared_login_nodes (only with login nodes)/home (unless specified in SharedStorage)By default these directories are created on the head nodes EBS volume and shared as NFS exports to the compute and login nodes.
つまり ヘッドノードで Slurm をビルドし直せば、コンピュートノード、ログインノードが参照するバイナリも入れ替わります。ノードごとにがんばる必要はなし。
2026 年 2 月の MUNGE の CVE 対応では事情が違いました。MUNGE のバイナリは各ノードのルートボリューム上にあります。ヘッドノードでビルドしたものを共有ディレクトリに置き、カスタムアクションでノード起動時に配る必要がありました。
今回は、ただし共有されているのはファイルであって、起動済みの slurmd が新しいバイナリを読み直すわけではありません。今回の手順ではコンピュートフリートをいったん停止し、コンピュートインスタンスをすべて終了させてから再開します。再開後に起動したノードが 25.11.8 で動いているかを確かめます。
現行バージョンのソースツリーがあることを確認する
後述のスクリプトは、いま入っている Slurm のソースツリーにある Makefile を使って旧版をアンインストールします。ソースツリーは AMI のビルド時に作られたものが /etc/chef/local-mode-cache/cache 配下へ残っています。ここに現行バージョンのディレクトリが 1 つだけあることを確認します。
ls -d /etc/chef/local-mode-cache/cache/slurm-slurm-*
/etc/chef/local-mode-cache/cache/slurm-slurm-25-11-6-1
コンピュートフリートを停止する
pcluster をインストールした端末から実行します。
pcluster update-compute-fleet --cluster-name slurm-cve-verify --status STOP_REQUESTED
status が STOPPED になるまで待ちます。
pcluster describe-compute-fleet --cluster-name slurm-cve-verify
{
"status": "STOPPED",
"lastStatusUpdatedTime": "2026-09-04T01:39:27.278Z"
}
STOPPED は、全パーティションが INACTIVE になりコンピュートインスタンスがすべて終了した状態です。
ヘッドノードのデーモンを停止する
ヘッドノードにログインし、ParallelCluster のデーモンと Slurm のデーモンを止めます。clusterstatusmgtd と clustermgtd は supervisord の管理下にあるため、supervisorctl で止めます。
SUPERVISORCTL=$(ls /opt/parallelcluster/pyenv/versions/*/envs/cookbook_virtualenv/bin/supervisorctl)
sudo $SUPERVISORCTL stop clusterstatusmgtd
sudo $SUPERVISORCTL stop clustermgtd
sudo systemctl stop slurmctld
Slurm アカウンティングをヘッドノードで有効にしている場合は slurmdbd を、slurmrestd が動いている場合はそれも止めます。私の環境はシンプルな検証用のクラスターなのでないです。
Slurm の状態とインストールをバックアップする
デーモンが止まっている状態でバックアップを取ります。slurmctld の状態ファイルの場所は設定ファイルから確認できます。
grep -rih StateSaveLocation /opt/slurm/etc/
状態ファイルと /opt/slurm をそれぞれ tar で固めます。
STATE_BACKUP_PATH="/opt/slurm_state_backup_$(date -u +%Y%m%d-%H%M%S).tar.gz"
sudo tar -czf "${STATE_BACKUP_PATH}" -C /var/spool slurm.state
sudo tar -tzf "${STATE_BACKUP_PATH}" >/dev/null
INSTALLATION_BACKUP_PATH="/opt/slurm_backup_$(date -u +%Y%m%d-%H%M%S).tar.gz"
sudo tar -czf "${INSTALLATION_BACKUP_PATH}" -C /opt slurm
sudo tar -tzf "${INSTALLATION_BACKUP_PATH}" >/dev/null
ロールバックはこの 2 つのアーカイブからの復元です。復元手順は Wiki のロールバックの節にまとまっています。
Slurm 25.11.8 をビルドして入れ替える
入れ替えは Wiki が公開している rebuild_slurm.sh を実行するだけです。Wiki からコピーしてヘッドノードに置き、root で実行します。スクリプトの動きは次のとおりです。
- ParallelCluster がビルドしたときと同じ configure オプション（
--with-pmix、--with-jwt、--enable-slurmrestd）でビルドする - ビルドが通ってから旧版を
make uninstallするので、ビルドに失敗しても既存のインストールは残る /opt/slurm/etcには触らないため、ParallelCluster が生成したクラスター設定はそのまま残るslurmctldやslurmdbdが動いていると実行を拒否する
time sudo SLURM_VERSION_NEW=slurm-25-11-8-1 ./rebuild_slurm.sh
実行が終わると、アンインストールした旧版と入れ替わったあとのバージョンがログに出ます。ログに Installed Slurm version is now slurm 25.11.8 が出ていれば入れ替えは完了です。
2026-09-04T01:41:38Z Installed Slurm version: 25.11.6
2026-09-04T01:41:38Z Downloading and building Slurm slurm-25-11-8-1
2026-09-04T01:43:52Z Uninstalling Slurm 25.11.6 and installing slurm-25-11-8-1
2026-09-04T01:45:18Z Installed Slurm version is now slurm 25.11.8
real 3m39.902s
物理 8 コアのヘッドノードで約 3 分 40 秒でした。ダウンロードとビルドが約 2 分 14 秒、make uninstall と make install が約 1 分 26 秒です。想像よりも早かったです。
デーモンとコンピュートフリートを再開する
止めたときと逆の順序で起動します。
sudo systemctl start slurmctld
sudo $SUPERVISORCTL start clusterstatusmgtd
sudo $SUPERVISORCTL start clustermgtd
コンピュートフリートを再開します。
pcluster update-compute-fleet --cluster-name slurm-cve-verify --status START_REQUESTED
describe-compute-fleet が RUNNING を返すと全パーティションが UP へ戻ります。
動作確認
ヘッドノードで 25.11.8 が動いていることを確認したい
sinfo -V の返すバージョンが 25.11.6 から 25.11.8 へ変わっていることを確認します。
sinfo -V
slurm 25.11.8
コントローラーが応答するかは scontrol ping で確認します。入れ替えの前後は /var/log/slurmctld.log の slurmctld version の行で追えます。同じログファイルに旧バージョンと新バージョンの起動行が並びます。
sudo grep "slurmctld version" /var/log/slurmctld.log
[2026-09-04T01:31:13.877] slurmctld version 25.11.6 started on cluster slurm-cve-verify(0)
+[2026-09-04T01:46:12.470] slurmctld version 25.11.8 started on cluster slurm-cve-verify(2515)
メンテナンスアップグレードなので、設定パラメータの非互換は想定していません。それでもログに fatal や no longer supported が出ていないかは見ておきます。今回はどちらも出ていませんでした。
コンピュートノードも 25.11.8 で起動するのか確認したい
ジョブを投入してコンピュートノードを起動します。ノードが登録されている間にバージョンを確認したいので、すぐには終わらないジョブにします。
sbatch --wrap "sleep 600" -N 1
ジョブの実行中に scontrol show node の Version を見ます。25.11.8 になっていることを確認します。
scontrol show node queue1-dy-compute1-1
NodeName=queue1-dy-compute1-1 Arch=x86_64 CoresPerSocket=1
NodeHostName=queue1-dy-compute1-1 Version=25.11.8
State=MIXED+CLOUD ThreadsPerCore=1 TmpDisk=0 Weight=1000 Owner=N/A MCS_label=N/A
コンピュートノード側の /var/log/slurmd.log も見ます。slurmd 自身が 25.11.8 で起動していれば、ヘッドノードでのビルドだけでコンピュートノードにも適用されたことを確認できる算段です。
sudo grep "slurmd version" /var/log/slurmd.log | tail -n 1
[2026-09-04T01:51:12.798] slurmd version 25.11.8 started
OK でした。
インプレースアップグレードにかかった時間の目安
ジョブを実行できない時間帯はコンピュートフリートの停止要求から再開までです。今回の検証では以下のとおりでした。
| 区間 | 所要 |
|---|---|
フリート停止（STOP_REQUESTED → STOPPED） |
約 30 秒 |
| デーモン停止とバックアップ取得 | 約 1 分 |
rebuild_slurm.sh（ダウンロード + ビルド + 入れ替え） |
3 分 40 秒 |
デーモン再起動（slurmctld 起動まで） |
約 1 分 |
フリート再開（START_REQUESTED → RUNNING） |
約 45 秒 |
| 合計 | 約 8 分 30 秒 |
ビルドはヘッドノートのスペックに依存するので T 系の小さなインスタンスならもっと時間がかかるはずです。なので、こればかり試さないと時間読めないです。
まとめ
稼働中の AWS ParallelCluster クラスターの Slurm を、公式 Wiki の手順で 25.11.8 にアップグレードしました。コンピュートフリートを止め、ヘッドノードでビルドし直し、フリートを戻す流れです。/opt/slurm がヘッドノードから共有されているため、コンピュートノードへログインノードでなにかする手順はありませんでした。
おわりに
新しいバージョンのリリースを待ちたいのですが、移行の工数がかかる場合はインプレースアップグレードもありかなと思い、一度手順を通しておきたくて試してみました。
