developersIO
AWS Parallel Computing Service が Slurm のインプレースメジャーバージョンアップグレードに対応したので試してみた

AWS Parallel Computing Service が Slurm のインプレースメジャーバージョンアップグレードに対応したので試してみた

AWS PCS が Slurm メジャーバージョンのインプレースアップグレードに対応しました。
HPCAWS Parallel Computing ServiceAWS
2026.07.18

はじめに

AWS Parallel Computing Service（PCS）は、Slurm ベースの HPC クラスターをマネージドで運用できるサービスです。このたび PCS が、稼働中クラスターの Slurm メジャーバージョンをインプレースでアップグレードできるようになりました。これまではメジャーバージョンを上げる手段がなく、新バージョンでクラスターを新規作成してワークロードを移行するしかありませんでした。今回は Slurm 25.05 のクラスターを構築し、ジョブを実行したまま v25.11 へのローリングアップデートを試しました。

https://aws.amazon.com/about-aws/whats-new/2026/06/aws-parallel-computing-service-upgrade/

pcs-slurm-inplace-upgrade.png

これまでメジャーバージョンを上げる手段がなかったツラミ

AWS PCS の UpdateCluster は、これまでコントローラーの一部設定は更新できても、Slurm メジャーバージョンのアップグレードはできませんでした。 つまり、メジャーバージョンを上げたければ、新バージョンで作成したクラスターへ移行するしかありませんでした。

Slurm のバージョンは YY.MM 形式で、v25.05 や v25.11 という単位がメジャーバージョンにあたります。3 桁目（例: v25.05.7）はパッチバージョンで、コントローラーへは PCS が自動適用します。今回のアップデートで新しくなったのはメジャーバージョンを上げられる点です。

さらに PCS には EOL（サポート終了）ポリシーがあります。執筆時点で v24.11 以前はすべて EOL 済みで、新規作成できるのは v25.05 と v25.11 のみです。既存クラスターが EOL 後も最長 12 か月動作を継続できるとはいえサポートの保証はありません。メジャーバージョンを上げる手段がないため、早かれ遅かれクラスターの作り直しを迫られる状況でした。

何が嬉しいか

今回のアップデートで、コントローラーの Slurm メジャーバージョンをアップグレードできるようになりました。 マネジメントコンソール、AWS CLI、UpdateCluster API のいずれからも実行でき、最大 3 つ先のメジャーバージョンまで指定できます。それを超える場合は複数回に分けてアップグレードが必要です。

コンソールの場合は「クラスターを編集」画面のスケジューラー欄で新しいバージョンを選択します。アップグレードが失敗した場合は自動的にロールバックし、クラスターはアクティブなままになるという説明もこちらの画面で確認できます。

パラレルコンピューティングサービス___ap-northeast-1-6.png

ローリングアップデートであれば実行中のジョブを止めずにアップグレードできます。 Slurm アカウンティングデータもアップグレードをまたいで保持されます。クラスターを作り直してワークロードを移行する手間が、コントローラーの更新だけで済むようになりました。

確認結果早見

Slurm 25.05 のクラスターを v25.11 へアップグレードし、以下を確認しました。

  • update-cluster を 1 回実行するだけで、コントローラーを v25.05 から v25.11 へインプレースでアップグレードできました（所要約 4 分 18 秒。公式ドキュメントの目安は 5〜15 分）
  • 実行中のジョブ（sleep 1800）はアップグレードをまたいで RUNNING を継続し、無停止でした
  • アップグレード直後はコントローラーが SLURM_VERSION=25.11.6、既存ノードの slurmd は Version=25.05.7 のままの混在状態になりました
  • 旧ノードの置き換えは手動 DRAIN だけでは発生せず、コンピュートノードグループの更新操作がトリガーになりました（今回は約 7 分で置き換え完了）
  • 置き換え後は同一 AMI から v25.11 の slurmd が自動選択されました

2 つのアップグレード方式を紹介

前提として、PCS のクラスターは Slurm を動かすコントローラーと、ジョブを実行するコンピュートノード（EC2 インスタンス）で構成されます。コンピュートノードグループは、このコンピュートノードを束ねて管理する PCS のリソースで、使用する AMI、インスタンスタイプ、起動テンプレート、台数などの設定を保持します。PCS は コンピュートノードグループ の設定に従ってインスタンスを起動、置き換えます。

アップグレードには、実行中ジョブを許容できるかどうかで選ぶ 2 つの方式があります。

観点 ローリングアップデート フルフリートリサイクル
実行中ジョブ 停止不要 すべて終了
AMI 要件 現行バージョンとターゲットバージョンの両方を含む必要 ターゲットバージョンのみでよい
コントローラーの最小バージョン 24.05 制限なし
アップグレード後のコンピュートフリート 一時的に混在 全ノードがターゲットバージョンで起動

フルフリートリサイクルはフリート全体を一度に入れ替えるため、スケールアップ時のキャパシティ不足には注意が必要です。また現行バージョンが v23.11（EOL）のクラスターは、ローリングアップデートが使えないためフルフリートリサイクル一択になります。今回の検証ではローリングアップデートを試します。

バージョン互換表

一度のアップグレードで上げられる先は、現在のバージョンから最大 3 メジャーバージョン先までです。

現在のクラスターバージョン 更新可能なターゲットバージョン
v25.11 なし（最新）
v25.05 v25.11
v24.11（EOL） v25.05、v25.11
v24.05（EOL） v24.11、v25.05、v25.11
v23.11（EOL） v24.05、v24.11、v25.05（フルフリートリサイクルのみ）

3 メジャーバージョンを超える移行は、コントローラーを 1 ホップずつ経由させる必要があります。たとえば v23.11 から v25.11 へは、v23.11 → v25.05 → v25.11 の 2 段階のアップグレードになります。

PCS-ready DLAMI が dual-version AMI 要件を満たすのでオススメ

ローリングアップデートには、現行バージョンとターゲットバージョンの両方の Slurm を含む AMI（dual-version AMI）が必要です。 PCS-ready DLAMI は最新 3 つの Slurm バージョンをあらかじめ同梱しており、起動時にクラスターのコントローラーバージョンに応じて自動的に有効化されます。今回使用した AMI の Description は次のとおりでした。

実行結果
PCS-Ready DLAMI based on Deep Learning Base OSS Nvidia Driver GPU AMI (Ubuntu 24.04) 20260626. PCS Agent: 1.4.0-1. Slurm: 24.11.7-1, 25.05.7-1, 25.11.2-1. EFS Utils: 2.4.2

1 つの AMI に v24.11、v25.05、v25.11 の 3 バージョンが同梱されています。この AMI であればローリングアップデートの AMI 要件を満たせます。なお、最初期から提供されている PCS のサンプル AMI は単一バージョンのみのため、ローリングアップデートには使えません。フルフリートリサイクルでのみ使用可能です。

実際にノードへ接続して中身をみてみると、3 バージョンの Slurm がディレクトリ単位で分かれて用意されていることを確認できました。

ls -d /opt/aws/pcs/scheduler/*
実行結果
/opt/aws/pcs/scheduler/libjwt-1.17.0
/opt/aws/pcs/scheduler/pmix-5.0.6
/opt/aws/pcs/scheduler/slurm-24.11
/opt/aws/pcs/scheduler/slurm-25.05
/opt/aws/pcs/scheduler/slurm-25.11
/opt/aws/pcs/scheduler/src

/etc/profile.d に置かれた設定で、クラスターのバージョンに合う bin ディレクトリだけが PATH に通ります。ローリングアップデートにはもう 1 つの前提として、全コンピュートノードの AMI に PCS Agent 1.4.0 以降が必要です。PCS-ready DLAMI は最新版であればこの条件も満たします。

PCS-ready DLAMI がどのような AMI かは、登場時に検証した以下の記事で紹介しています。

https://dev.classmethod.jp/articles/aws-pcs-official-ami-no-custom-build/

やってみた

PCS-ready DLAMI の AMI ID と同梱バージョンを確認する

x86_64 向けの最新 PCS-ready DLAMI の AMI ID を SSM パラメータストアから取得します。

aws ssm get-parameter --region ap-northeast-1 \
  --name /aws/service/pcs/ami/dlami-base-ubuntu2404/x86_64/latest/ami-id \
  --query "Parameter.Value" --output text
実行結果
ami-06cc10e1a5834102a

取得した AMI の Description で、v25.05 と v25.11 の両方の Slurm と、PCS Agent 1.4.0 以降が同梱されていることを確認します。

aws ec2 describe-images --region ap-northeast-1 --image-ids ami-06cc10e1a5834102a \
  --query "Images[0].Description" --output text

25.05.7-1 と 25.11.2-1 の両方が同梱され、PCS Agent 1.4.0-1 がローリングアップデートの必須要件（1.4.0 以降）を満たしていることが確認できました。

実行結果
PCS-Ready DLAMI based on Deep Learning Base OSS Nvidia Driver GPU AMI (Ubuntu 24.04) 20260626. PCS Agent: 1.4.0-1. Slurm: 24.11.7-1, 25.05.7-1, 25.11.2-1. EFS Utils: 2.4.2

Slurm 25.05 のクラスターを構築する

構築手順自体は省略します。詳細は既存の PCS 入門記事を参照してください。

構築直後の あえて古いバージョンで作ったクラスター詳細画面です。 ステータスは「アクティブ」、スケジューラーは「Slurm バージョン 25.05」です。v25.05 はまだサポート中にもかかわらず、この時点から「現在のスケジューラーのバージョンは古くなっています」と EOL 日（2026 年 11 月 30 日）までのアップグレードを促す警告が表示されていました。

パラレルコンピューティングサービス___ap-northeast-1-5.png

今回の検証環境は次のとおりです。

項目 値
リージョン ap-northeast-1
PCS クラスター Slurm 25.05
コントローラーサイズ SMALL
コンピュートノードグループ t3.large、static 1 台
キュー（パーティション名） pcs-upg-queue
AMI PCS-ready DLAMI ami-06cc10e1a5834102a（Ubuntu 24.04、20260626 版）
AMI 同梱 Slurm 24.11.7-1、25.05.7-1、25.11.2-1
PCS Agent 1.4.0-1

PCS-ready DLAMI の公式サポートインスタンスは G4dn、G5、P 系などの GPU インスタンスですが、コスト最小化のため選んだ t3.large（CPU インスタンス）でも問題なく起動しました。

構築後、クラスターが ACTIVE、Slurm バージョンが v25.05 であることを確認します。

aws pcs get-cluster --region ap-northeast-1 --cluster-identifier pcs_s4vmcij4p8 \
  --query "cluster.{status:status,scheduler:scheduler}"
実行結果
{
    "status": "ACTIVE",
    "scheduler": {
        "type": "SLURM",
        "version": "25.05"
    }
}

コンピュートノードグループが ACTIVE、EC2 インスタンスが 1 台起動していることを確認します。

aws ec2 describe-instances --region ap-northeast-1 \
  --filters "Name=tag:aws:pcs:cluster-id,Values=pcs_s4vmcij4p8" "Name=instance-state-name,Values=running" \
  --query "Reservations[].Instances[].[InstanceId,InstanceType,ImageId,State.Name]" --output table
実行結果
i-0ada528b9671f1eb9  t3.large  ami-06cc10e1a5834102a  running

コンピュートノードの初期バージョンを確認する

SSM でノードに接続します。SSM 経由のシェルは /etc/profile.d を読み込まないため、Slurm コマンドを使う前に PATH へ追加しておきます。またジョブの出力ファイルはカレントディレクトリに作成されるため、以降の sbatch は書き込めるディレクトリ（ホームディレクトリ等）で実行します。

export PATH=$PATH:/opt/aws/pcs/scheduler/slurm-25.05/bin

bootstrap ログで PCS Agent バージョンと、コントローラーのバージョンに合わせて選択された Slurm バージョンを確認します。

grep "PCS Agent version" /var/log/amazon/pcs/bootstrap.log | tail -1
実行結果
Bootstrap starting with PCS Agent version: 1.4.0-1, Slurm cluster version: 25.05 (locally installed version: 25.05)

ノード上の Slurm バージョンとキューの状態も確認します。

scontrol show nodes | grep -E "NodeName=|Version=|State="
sinfo
実行結果
NodeName=pcs-upg-static-1 Arch=x86_64 CoresPerSocket=1
   NodeAddr=10.0.1.160 NodeHostName=ip-10-0-1-160 Version=25.05.7
   State=IDLE+CLOUD
PARTITION     AVAIL  TIMELIMIT  NODES  STATE NODELIST
pcs-upg-queue    up   infinite      1   idle pcs-upg-static-1

ノードバージョンが v25.05.7、PCS Agent が 1.4.0-1 で、ローリングアップデートの要件を満たしていることを確認できました。

長時間ジョブを投入する

アップグレード中にジョブが動き続けることを確認するため、sleep 1800 の長時間動くジョブを投入します。

sbatch -p pcs-upg-queue --wrap "sleep 1800" -J upgrade-survivor
squeue
実行結果
Submitted batch job 2
             JOBID PARTITION     NAME     USER ST       TIME  NODES NODELIST(REASON)
                 2 pcs-upg-q upgrade-   ubuntu  R       0:05      1 pcs-upg-static-1

JobId=2 が RUNNING になったことを確認しました。このジョブは 30 分後に完了する想定でしたが、アップグレードの開始作業が遅れたため、開始前に完了してしまいました。そのため、アップグレード中のジョブ継続はこの後に投入したジョブで確認しています。

コントローラーをインプレースアップグレードする

update-cluster でスケジューラーバージョンを v25.11 に指定します。

aws pcs update-cluster --region ap-northeast-1 \
  --cluster-identifier pcs_s4vmcij4p8 --scheduler version=25.11
実行結果
{
    "status": "UPDATING",
    "scheduler": {
        "type": "SLURM",
        "version": "25.11"
    }
}

update-cluster のレスポンス自体はターゲットバージョン（v25.11）を返します。しかし直後に get-cluster を実行すると、scheduler.version はまだ v25.05 のままでした。UPDATING 中の数分間は旧バージョンの表示が続き、その後 v25.11 に切り替わりました。

コンソールでも同様に、ステータスが「更新中」の間はスケジューラーが「Slurm バージョン 25.05」の表示のままでした。

パラレルコンピューティングサービス___ap-northeast-1-7.png

UPDATING 開始から約 1 分後、JobId=2 がすでに完了していたため、あらためてジョブを投入しました。公式ドキュメントではアップグレード完了までコマンドが使えなくなるとされていますが投入に成功しました。

sbatch -p pcs-upg-queue --wrap "sleep 1800" -J upgrade-survivor2
squeue
scontrol ping
実行結果
Submitted batch job 3
             JOBID PARTITION     NAME     USER ST       TIME  NODES NODELIST(REASON)
                 3 pcs-upg-q upgrade-   ubuntu PD       0:00      1 (None)
Slurmctld(primary) at slurmctld-primary is UP

公式ドキュメントでは、アップグレード中の挙動を次のように説明しています。

During this operation the controller is briefly unavailable:

Running jobs on compute nodes continue executing. New job submissions and scheduler commands are unavailable until the update completes. Automatic scaling is paused until the cluster returns to ACTIVE.

出典: Update the scheduler version of an AWS PCS cluster - AWS PCS User Guide

今回は 1 分間隔で scontrol ping を実行し続けましたが、完了まで一貫して UP のままでした。アップグレード自体は 4 分 18 秒（公式目安は 5〜15 分）で完了しました。コマンド不可の瞬間があったとしても、今回の観測粒度では検出できませんでした。

新旧混在状態を確認する

コントローラーの scheduler.version が v25.11 になっていることを確認します。

aws pcs get-cluster --region ap-northeast-1 --cluster-identifier pcs_s4vmcij4p8 \
  --query "cluster.{status:status,scheduler:scheduler}"
実行結果
{
    "status": "ACTIVE",
    "scheduler": {
        "type": "SLURM",
        "version": "25.11"
    }
}

コンソールでもステータスが「アクティブ」に戻り、スケジューラーが「Slurm バージョン 25.11」に変わっていました。構築時から出ていた古いバージョンへの警告バナーも消えています。

パラレルコンピューティングサービス___ap-northeast-1-8.png

一方、ノード上ではまだ v25.05 系のままであることを確認します。

scontrol show nodes | grep -E "NodeName=|Version="
scontrol show config | grep -i SLURM_VERSION
実行結果
NodeName=pcs-upg-static-1 Arch=x86_64 CoresPerSocket=1
   NodeAddr=10.0.1.160 NodeHostName=ip-10-0-1-160 Version=25.05.7
SLURM_VERSION           = 25.11.6

コントローラーは SLURM_VERSION=25.11.6、ノードの slurmd は Version=25.05.7 の混在状態です。なおパッチバージョンは、コントローラーが v25.11.6、後ほど確認するノード側の slurmd が v25.11.2 と、一致しないまま動作しました。

ジョブの継続も確認します。

squeue
ps aux | grep "sleep 1800"
実行結果
             JOBID PARTITION     NAME     USER ST       TIME  NODES NODELIST(REASON)
                 3 pcs-upg-q upgrade-   ubuntu  R       2:09      1 pcs-upg-static-1
ubuntu      2874  0.0  0.0   6120  2032 ?        S    04:39   0:00 sleep 1800

JobId=3 は RUNNING を継続し、sleep プロセスも同一 PID（2874）で生存していました。コントローラーのアップグレードをまたいでジョブが無停止だったことを確認できました。

旧ノードを DRAIN して置き換える

コントローラーのアップグレード後も、既存ノードは自動的に置き換わりません。 DRAIN はノードへの新規ジョブの割り当てを止め、実行中のジョブは完了まで走らせてノードを空にしていく操作です。置き換え自体は別の操作でトリガーする必要があります。

scontrol update NodeName=pcs-upg-static-1 State=DRAIN Reason="Slurm version update"
sinfo
squeue
実行結果
PARTITION     AVAIL  TIMELIMIT  NODES  STATE NODELIST
pcs-upg-queue    up   infinite      1   drng pcs-upg-static-1
             JOBID PARTITION     NAME     USER ST       TIME  NODES NODELIST(REASON)
                 3 pcs-upg-q upgrade-   ubuntu  R       3:22      1 pcs-upg-static-1

ノードは drng（draining）へ遷移し、実行中の JobId=3 は RUNNING を継続していました。公式ドキュメントには次の記載があります。

Once drained nodes finish their current jobs they terminate and are replaced by nodes on Slurm version B.

出典: Update the scheduler version of an AWS PCS cluster - AWS PCS User Guide

しかし、JobId=3 が完了した後も、ノードは IDLE+CLOUD+DRAIN のままインスタンスが terminate されず、3.5 時間経過しても変わりませんでした。置き換えのトリガーは DRAIN ではなくコンピュートノードグループの更新操作で、更新によって置き換えマークが付いたノードがアイドルになった時点で実際の置き換えが行われます。次のドキュメントに記載があります。

AWS PCS replaces existing instances in the node group after a node group update operation. If there are jobs running on a node, those jobs are allowed to complete before AWS PCS replaces the node. ... Node group status returns to Active when AWS PCS marks the instances for replacement, but the actual replacement occurs when the instances are idle.

出典: Updating an AWS PCS compute node group - AWS PCS User Guide

公式のローリングアップデート手順は、Step 1 で dual-version AMI への update-compute-node-group を実行し、そこで置き換えマークが付く前提になっています。今回のように最初から dual-version AMI（PCS-ready DLAMI）を使って Step 1 を省略すると置き換えマークが付かないため、DRAIN だけでは置き換えが進みませんでした。

パラメータを指定しない update-compute-node-group（公式ドキュメントの CLI 例そのまま）を試すと拒否されました。

aws pcs update-compute-node-group --region ap-northeast-1 \
  --cluster-identifier pcs_s4vmcij4p8 \
  --compute-node-group-identifier pcs_ss2pr7pzce
実行結果
An error occurred (ValidationException) when calling the UpdateComputeNodeGroup operation:
There are no editable fields in the request. At least 1 of the following fields is required:
[AmiId, SubnetIds, CustomLaunchTemplate, PurchaseOption, SpotOptions, ScalingConfig, IamInstanceProfileArn, SlurmConfiguration]

編集可能フィールドを 1 つ以上渡す必要があるため、現行と同じ AMI ID を明示指定してみましたが、これは変更なし扱いになり置き換えは発生しませんでした。

aws pcs update-compute-node-group --region ap-northeast-1 \
  --cluster-identifier pcs_s4vmcij4p8 \
  --compute-node-group-identifier pcs_ss2pr7pzce \
  --ami-id ami-06cc10e1a5834102a
実行結果
{
    "status": "ACTIVE",
    "amiId": "ami-06cc10e1a5834102a"
}

レスポンスは UPDATING を経ずに、そのまま ACTIVE でした。10 分監視しても置き換えは発生しませんでした。効果があったのは起動テンプレートを使う方法でした。コンピュートノードグループ は設定として「どの起動テンプレートのどのバージョンを使うか」を保持しています。そこで、中身を変えない起動テンプレートの新バージョン（バージョン 2）を作成し、コンピュートノードグループ が使用するバージョンの指定を 1 から 2 へ変更します。

aws ec2 create-launch-template-version --region ap-northeast-1 \
  --launch-template-id lt-00017910be5e54907 \
  --source-version 1 \
  --version-description "trigger node replacement for slurm 25.11" \
  --launch-template-data '{}'

aws pcs update-compute-node-group --region ap-northeast-1 \
  --cluster-identifier pcs_s4vmcij4p8 \
  --compute-node-group-identifier pcs_ss2pr7pzce \
  --custom-launch-template id=lt-00017910be5e54907,version=2
実行結果
{
    "status": "UPDATING",
    "customLaunchTemplate": {
        "id": "lt-00017910be5e54907",
        "version": "2"
    }
}

今回は コンピュートノードグループ が UPDATING に遷移し、実変更として受理されました。describe-instances でインスタンスの遷移を追うと、次のように進行しました。

実行結果（監視ログ）
17:58:12 cng=UPDATING instances: i-0ada528b9671f1eb9 running
18:00:32 cng=ACTIVE   instances: i-0ada528b9671f1eb9 running
18:01:19 cng=ACTIVE   instances: i-0ada528b9671f1eb9 shutting-down
18:02:06 cng=ACTIVE   instances: i-0ada528b9671f1eb9 terminated
18:05:12 cng=ACTIVE   instances: i-080136ae4266ce9b3 running

コンピュートノードグループ の更新実行から新インスタンスが running になるまで、約 7 分でした。コンピュートノードグループ のステータスが ACTIVE に戻るタイミングで置き換えマークが付与され、旧インスタンスがすでにアイドル状態だったため、すぐに terminate されたと考えられます。

新しいインスタンスの AMI が旧ノードと同一であることを確認します。

aws ec2 describe-instances --region ap-northeast-1 --instance-ids i-080136ae4266ce9b3 \
  --query "Reservations[].Instances[].[InstanceId,ImageId,InstanceType,State.Name]" --output table
実行結果
i-080136ae4266ce9b3  ami-06cc10e1a5834102a  t3.large  running

新ノードの bootstrap ログと Slurm バージョンを確認します。旧ノードの bootstrap ログと比較すると、次のように選択されたバージョンが切り替わっていることがわかります。

実行結果（bootstrap ログの新旧対比）
- Bootstrap starting with PCS Agent version: 1.4.0-1, Slurm cluster version: 25.05 (locally installed version: 25.05)
+ Bootstrap starting with PCS Agent version: 1.4.0-1, Slurm cluster version: 25.11 (locally installed version: 25.11)

同一 AMI（ami-06cc10e1a5834102a）から、コントローラーのバージョンに合わせて v25.11 の slurmd が自動選択されたことが確認できました。ノードの Slurm バージョンと状態も見ておきます。

scontrol show nodes | grep -E "NodeName=|Version="
実行結果
NodeName=pcs-upg-static-1 Arch=x86_64 CoresPerSocket=1
   NodeAddr=10.0.1.78 NodeHostName=ip-10-0-1-78 Version=25.11.2

NodeName は pcs-upg-static-1 のままでした。一方で NodeAddr（プライベート IP）は 10.0.1.160 から 10.0.1.78 に、InstanceId は i-0ada528b9671f1eb9 から i-080136ae4266ce9b3 に変わりました。DRAIN 状態も新ノードでは解除され、idle に戻りました。

全ノードが v25.11 になったことを確認する

新規ジョブが正常に実行できることを確認します。

sbatch -p pcs-upg-queue --wrap hostname -J final-check
squeue
scontrol show job 4 | grep -E "JobState|ExitCode"
実行結果
Submitted batch job 4
   JobState=COMPLETED Reason=None
   ExitCode=0:0

JobId=4 が COMPLETED、ExitCode 0:0 で正常に実行できました。ジョブ ID の連番（1〜4）は、コントローラーのアップグレードとノードの置き換えをまたいで維持されており、ジョブ履歴の引き継ぎも確認できました。

まとめ

AWS PCS は update-cluster を 1 回実行するだけで、Slurm メジャーバージョンをインプレースでアップグレードできるようになりました。今回の検証では、v25.05 から v25.11 へのアップグレードは約 4 分 18 秒で完了し、実行中のジョブは停止しませんでした。ただし旧ノードの置き換えは手動 DRAIN だけでは進まず、コンピュートノードグループの更新操作が必要でした。PCS-ready DLAMI を使えば、コントローラーのバージョンに合わせて Slurm が自動選択されるため、追加の AMI ビルドなしにローリングアップデートを進められます。

おわりに

大学や研究機関のように複数ユーザーが常時利用するクラスター環境では、AWS ParallelCluster はコントローラーの可用性が課題に感じられ、マネージドな PCS は良いソリューションだと考えていました。一方で、Slurm のバージョンアップのたびにクラスターの作り直しが発生する点は、大規模なクラスター環境では運用が厳しいとも感じていました。今回の改善でその懸念が解消され、大規模、複数ユーザーの環境にも勧められるサービスになってきたのではないでしょうか。PCS の基本的な仕組みについては、以下の記事もあわせてご覧ください。

https://dev.classmethod.jp/articles/announcing-aws-parallel-computing-service/

参考

この記事をシェアする

AWSのお困り事はクラスメソッドへ

関連記事

AWS ParallelCluster v3.15.0 で P6-B300 サポートなど主要な変更点を確認してみた
大村 保貴
2026.03.29
AWS ParallelCluster v3.8.0-v3.13.1でキャパシティ予約期限切れ時のクラスター更新失敗問題と対処方法
大村 保貴
2025.06.26
AWS ParallelCluster で Slurm パーティションの状態を inactive から up へ強制変更する方法
大村 保貴
2025.02.25
AWS ParallelCluster v3.15.1 の Copy Fail 対応を確認してみた
大村 保貴
2026.05.29