AWS ParallelCluster v3.15.0 で P6-B300 サポートなど主要な変更点を確認してみた
はじめに
AWS ParallelCluster v3.15.0 がリリースされました。EFA 用 ENI のプライベート IP アドレスの消費をゼロにする efa-only InterfaceType の導入や、Compute node の設定同期を刷新するなど、大規模な HPC クラスター運用向けの改善がなされました。クラスターを構築し、主要な変更点を確認してみました。
v3.15.0 の主要アップデート概要
GitHub のリリースノートから主な変更点を抜粋します。
主な新機能と改善
- P6-B300 インスタンスのサポートし、大規模な AI/ML ワークロードを実行可能
- EFA 有効時のネットワークインターフェイスが
interface+efa-onlyに分離され、プライベート IP アドレス消費を削減 - Compute node の設定同期が cfn-hup から systemd タイマーと NFS 共有ストレージベースの方式に変更
- Slurm 25.11.4、CUDA 13.0.2、Python 3.14.2 など主要なソフトウェアのバージョン更新
廃止予告
v3.15.0 では 2 つの廃止予告があります。
Amazon Linux 2 は v3.15.0 が最後のサポートリリースです。EOL は 2026 年 6 月 30 日のため、早めに Amazon Linux 2023 への移行を検討してください。
AWS Batch スケジューラも v3.15.0 が最後のサポートリリースです。v3.16.0 以降、ParallelCluster のスケジューラとして AWS Batch は利用できなくなります。AWS Batch を使用中の場合は Slurm への移行を計画してください。
検証環境
| 項目 | 設定値 |
|---|---|
| ParallelCluster | v3.15.0 |
| OS | Amazon Linux 2023 |
| Head node | t3a.small（パブリックサブネット） |
| Compute node | c5n.18xlarge（プライベートサブネット、EFA 有効、PlacementGroup 有効、オンデマンド） |
| 共有ストレージ | デフォルトの HeadNode NFS |
| インターネットアクセス | NAT Gateway 経由 |
| リージョン | ap-northeast-1 |
クラスター設定ファイル
検証で使用した設定ファイルです。環境依存の値（サブネット ID 等）はご自身の環境に合わせて置き換えてください。
クラスター設定ファイル全文
Region: ap-northeast-1
Image:
Os: alinux2023
Tags:
- Key: Name
Value: cluster-v3.15.0
HeadNode:
InstanceType: t3a.small
Networking:
ElasticIp: false
SubnetId: subnet-029f0fb0acc64043d
LocalStorage:
RootVolume:
Size: 45
Encrypted: true
VolumeType: gp3
Iops: 3000
Throughput: 125
Iam:
AdditionalIamPolicies:
- Policy: arn:aws:iam::aws:policy/AmazonSSMManagedInstanceCore
Scheduling:
Scheduler: slurm
SlurmSettings:
ScaledownIdletime: 5
SlurmQueues:
- Name: efa
ComputeResources:
- Name: c5n18xl
Instances:
- InstanceType: c5n.18xlarge
MinCount: 0
MaxCount: 2
Efa:
Enabled: true
ComputeSettings:
LocalStorage:
RootVolume:
Size: 45
Encrypted: true
VolumeType: gp3
Iops: 3000
Throughput: 125
CapacityType: ONDEMAND
Networking:
SubnetIds:
- subnet-0897827eb4d8cd2fe
PlacementGroup:
Enabled: true
Iam:
AdditionalIamPolicies:
- Policy: arn:aws:iam::aws:policy/AmazonSSMManagedInstanceCore
Monitoring:
Logs:
CloudWatch:
Enabled: true
RetentionInDays: 180
DeletionPolicy: "Delete"
Dashboards:
CloudWatch:
Enabled: false
pcluster create-cluster \
--cluster-name v3150-test \
--cluster-configuration cluster-config.yaml
P6-B300 インスタンスのサポート
v3.15.0 では NVIDIA Blackwell Ultra B300 GPU を搭載した P6-B300 インスタンスがサポートされました。8 基の B300 GPU、2.1 TB の高帯域 GPU メモリ、6.4 Tbps の EFA ネットワーキングを備えており、大規模な基盤モデルのトレーニングや推論に適しています。
P6-B300 インスタンスの詳細は以下の記事を参照してください。
P6-B300 はネットワークカードが 17 枚もあります。 次で取り上げる今回のアップデート efa-only InterfaceType の恩恵がとくに大きいインスタンスです。
EFA のプライベート IP 消費削減
背景
従来の ParallelCluster では、EFA を有効にすると ENI のタイプが efa となり、各ネットワークカードの ENI ごとにプライベート IP が割り当てられていました。たとえば P6-B300（ネットワークカード 17 枚）を 100 ノード起動すると、1,700 個の IP を消費します。大規模なクラスターでは VPC のネットワーク設計や、サブネットの IP 枯渇問題がありました。
v3.15.0 では efa-only InterfaceType が導入されました。EFA ファブリック専用の ENI には IP アドレスが割り当てられません。IP コネクティビティ用の interface ENI のみが IP を消費するため、P6-B300 の例では 1,700 IP が 100 IP に削減されます。
レガシー動作が必要な場合は、クラスター設定ファイルの DevSettings セクションで EfaInterfaceType: efa を指定することで従来動作に戻せます。
確認してみた
c5n.18xlarge(Compute node)を起動した状態で、ENI 構成と IP 消費を確認します。
ENI 構成の確認
aws ec2 describe-instances でインスタンスのネットワークインターフェイスを確認しました。
# Compute node のインスタンス ID は pcluster describe-cluster-instances で確認
aws ec2 describe-instances \
--instance-ids <compute-node-instance-id> \
--query 'Reservations[].Instances[].NetworkInterfaces[].{InterfaceType:InterfaceType,PrivateIpAddress:PrivateIpAddress,DeviceIndex:Attachment.DeviceIndex}' \
--output json
[
{
"InterfaceType": "efa-only",
"PrivateIpAddress": null,
"DeviceIndex": 1
},
{
"InterfaceType": "interface",
"PrivateIpAddress": "10.0.3.226",
"DeviceIndex": 0
}
]
DeviceIndex 0 の interface タイプ ENI にのみプライベート IP アドレスが割り当てられています。DeviceIndex 1 の efa-only タイプ ENI には IP アドレスがありません。
サブネット IP 消費の確認
Compute node 起動前後のサブネットの利用可能 IP アドレス数を比較しました。
aws ec2 describe-subnets \
--subnet-ids <private-subnet-id> \
--query 'Subnets[].AvailableIpAddressCount' \
--output text \
--region ap-northeast-1
| タイミング | AvailableIpAddressCount | 差分 |
|---|---|---|
| Compute node 起動前 | 250 | - |
| Compute node 起動後（c5n.18xlarge x1） | 249 | -1 |
describe-instances の結果で ENI が 2 つ（interface + efa-only）存在することを確認済みです。ENI が 2 つあるにもかかわらず、プライベート IP アドレスの消費は 1 つだけでした。efa-only ENI がプライベート IP を消費しないことを確認できました。
systemd タイマーによる cfn-hup 置き換え
cfn-hupとは何かから確認することになりました。
背景
従来の ParallelCluster では、Compute node が CloudFormation の cfn-hup デーモンで設定変更を検知していました。cfn-hup は定期的に CloudFormation API をポーリングします。CloudFormation API にはスロットリング制限があり、DescribeStackResource は 20 リクエスト/秒、DescribeStacks は 10 リクエスト/秒が上限です。この制限はアカウント・リージョン単位で適用され、引き上げできません。大規模クラスターでは Compute node 数に比例して API コールが増加するため、スロットリングが発生するリスクがありました。
v3.15.0 では Compute node の cfn-hup が pcluster-check-update.timer（systemd タイマー）に置き換わりました。Head node が共有ストレージ（NFS）にファイルを書き込み、Compute node が NFS 経由で検知する方式です。CloudFormation API コールが不要になりました。
確認してみた
Head node と Compute node それぞれで設定同期の仕組みを確認しました。
Head node の確認
Head node で systemd タイマーを確認しました。
systemctl list-timers --all の全出力（Head node）
NEXT LEFT LAST PASSED UNIT ACTIVATES
Tue 2026-03-24 01:20:51 UTC 34s left Tue 2026-03-24 01:19:49 UTC 27s ago refresh-policy-routes@ens5.timer refresh-policy-routes@ens5.service
Tue 2026-03-24 23:26:39 UTC 22h left Fri 2026-03-20 04:07:53 UTC 3 days ago update-motd.timer update-motd.service
Wed 2026-03-25 00:00:00 UTC 22h left Tue 2026-03-24 00:15:17 UTC 1h 4min ago logrotate.timer logrotate.service
Wed 2026-03-25 00:00:00 UTC 22h left Tue 2026-03-24 00:15:17 UTC 1h 4min ago mlocate-updatedb.timer mlocate-updatedb.service
Wed 2026-03-25 00:07:00 UTC 22h left - - sysstat-summary.timer sysstat-summary.service
Wed 2026-03-25 00:29:49 UTC 23h left Tue 2026-03-24 00:29:49 UTC 50min ago systemd-tmpfiles-clean.timer systemd-tmpfiles-clean.service
Sun 2026-03-29 01:00:00 UTC 4 days left - - raid-check.timer raid-check.service
Mon 2026-03-30 00:01:07 UTC 5 days left Tue 2026-03-24 01:05:49 UTC 14min ago fstrim.timer fstrim.service
- - Tue 2026-03-24 01:20:17 UTC 75ms ago sysstat-collect.timer sysstat-collect.service
9 timers listed.
Head node には pcluster-check-update.timer は存在しません。Head node は引き続き cfn-hup-runner.sh で設定変更を管理しています。
ps aux | grep cfn-hup | grep -v grep
root 3479 0.0 0.1 223028 3560 ? S 00:17 0:00 /bin/bash /opt/parallelcluster/scripts/cfn-hup-runner.sh
Compute node の確認
Compute node で systemd タイマーを確認しました。
systemctl list-timers --all の全出力（Compute node）
NEXT LEFT LAST PASSED UNIT ACTIVATES
Tue 2026-03-24 01:20:36 UTC 18s left Tue 2026-03-24 01:19:36 UTC 41s ago pcluster-check-update.timer pcluster-check-update.service
Tue 2026-03-24 01:20:37 UTC 19s left Tue 2026-03-24 01:19:36 UTC 41s ago refresh-policy-routes@ens5.timer refresh-policy-routes@ens5.service
Tue 2026-03-24 01:26:29 UTC 6min left - - systemd-tmpfiles-clean.timer systemd-tmpfiles-clean.service
Tue 2026-03-24 01:30:00 UTC 9min left Tue 2026-03-24 01:20:07 UTC 10s ago sysstat-collect.timer sysstat-collect.service
Tue 2026-03-24 01:30:53 UTC 10min left Fri 2026-03-20 04:07:53 UTC 3 days ago fstrim.timer fstrim.service
Wed 2026-03-25 00:00:00 UTC 22h left Tue 2026-03-24 01:12:10 UTC 8min ago logrotate.timer logrotate.service
Wed 2026-03-25 00:00:00 UTC 22h left Tue 2026-03-24 01:12:10 UTC 8min ago mlocate-updatedb.timer mlocate-updatedb.service
Wed 2026-03-25 00:07:00 UTC 22h left - - sysstat-summary.timer sysstat-summary.service
Wed 2026-03-25 00:22:28 UTC 23h left Fri 2026-03-20 04:07:53 UTC 3 days ago update-motd.timer update-motd.service
Sun 2026-03-29 01:00:00 UTC 4 days left - - raid-check.timer raid-check.service
10 timers listed.
Compute node では pcluster-check-update.timer が 1 分間隔で実行されています（出力の 1 行目）。
cfn-hup プロセスが動作していないことも確認しました。
ssh efa-dy-c5n18xl-1 systemctl status cfn-hup
○ cfn-hup.service - cfn-hup daemon
Loaded: loaded (/usr/lib/systemd/system/cfn-hup.service; disabled; preset: disabled)
Active: inactive (dead)
NFS 共有ストレージの確認
Compute node で NFS マウントを確認しました。
df -hT | grep nfs
10.0.0.207:/opt/parallelcluster/shared nfs4 45G 22G 24G 49% /opt/parallelcluster/shared
10.0.0.207:/home nfs4 45G 22G 24G 49% /home
10.0.0.207:/opt/intel nfs4 45G 22G 24G 49% /opt/intel
10.0.0.207:/opt/slurm nfs4 45G 22G 24G 49% /opt/slurm
/opt/parallelcluster/shared/ に設定同期用のファイルが格納されていることを確認しました。
ls -la /opt/parallelcluster/shared/
主な設定同期ファイルは以下のとおりです。ファイルの中身からの推測です。
| ファイル | 役割 |
|---|---|
cluster-config-version |
設定バージョンのハッシュ値 |
cluster-config.yaml |
クラスター設定本体 |
update_trigger |
更新トリガー（cluster-config-version と同じ値） |
change-set.json |
変更差分 |
computefleet-status.json |
コンピュートフリートのステータス |
v3.14.0 以前との比較
| 項目 | v3.14.0 以前 | v3.15.0 |
|---|---|---|
| Compute node の設定検知 | cfn-hup（CloudFormation API ポーリング） | systemd タイマー + NFS |
| CloudFormation API コール | Compute node 数 x ポーリング回数 | Head node のみ |
| スロットリングリスク | 大規模時に高い | 大幅軽減 |
| ネットワーク依存 | CloudFormation エンドポイント | NFS（ローカルネットワーク） |
| Head node | cfn-hup-runner.sh | cfn-hup-runner.sh（変更なし） |
ソフトウェアスタック更新
v3.15.0 では主要コンポーネントが大幅に更新されました。とくに Slurm のメジャーバージョンアップと CUDA 13.0 系への更新は、HPC・GPU ワークロードに直接影響しますのでご確認ください。
| コンポーネント | 前バージョン | v3.15.0 |
|---|---|---|
| Slurm | 24.11.7 | 25.11.4 |
| NVIDIA Driver | 570.172.08 | 580.105.08 |
| CUDA Toolkit | 12.8.1 | 13.0.2 |
| Python | 3.12.11 | 3.14.2 |
| EFA Installer | 1.44.0 | 1.47.0 |
| Pmix | 5.0.6 | 5.0.10 |
| GDRCopy | 2.4.4 | 2.5.2 |
| DCV | 2024.0-19030 | 2025.0-20103 |
| DCGM | 4.4.1 | 4.5.1 |
| Munge | 0.5.16 | 0.5.17 |
| Intel MPI | 2021.16.0 | 2021.17.2 |
Slurm が 24 系から 25 系へメジャーバージョンアップしています。CUDA も 13.0 系に更新されています。
検証中のトラブルシューティング
EFA 対応インスタンスはプライベートサブネット必須
検証中に遭遇したトラブルを共有します。
症状
c5n.18xlarge（EFA 有効）の Compute node が Slurm 上で CF（configuring）のまま進まず、ブートストラップが完了しない。
原因
EFA 対応インスタンスは複数の ENI を持つため、仕様によりパブリック IP を自動割り当てできません。パブリックサブネットに配置してもパブリック IP が付与されず、IGW 経由のインターネットアクセスができないため、ブートストラップに必要なパッケージのダウンロードが失敗します。
公式ドキュメントにも、複数のネットワークインターフェイスまたはネットワークインターフェイスカードを持つインスタンスにはパブリック IP を割り当てられないと記載されています。NAT Gateway の使用が推奨されています。
解決策
Compute node をプライベートサブネットに配置し、NAT Gateway 経由でインターネットアクセスを確保します。
教訓
EFA を有効にする場合はプライベートサブネットと NAT Gateway の構成にしましょう。ParallelCluster のドキュメントでも、Head node をパブリックサブネット、Compute node をプライベートサブネットに配置する構成が推奨されています。検証だったのですべてパブリックサブネットで起動させて失敗しました。
その他では ap-northeast-1 の単一 AZ + PlacementGroup の制約下で c5n.18xlarge のスポットキャパシティが確保できませんでした。古いから空いているかなと思ったのですが、結局オンデマンドへの切り替えることになりました。
まとめ
AWS ParallelCluster v3.15.0 の主要アップデートを検証しました。
今回のアップデートでインパクトが大きいのは efa-only InterfaceType の導入です。EFA 用 ENI がプライベート IP を消費しなくなり、P6-B300 のようなネットワークカードの多いインスタンスでは 1 ノードあたり 17 IP が 1 IP に削減されます。大規模クラスターでのサブネット IP 枯渇問題が大幅に緩和されます。
Compute node の設定同期が cfn-hup から systemd タイマー + NFS に変わった点も地味にポイントです。CloudFormation API のスロットリング制限を気にする必要がなくなりました。一方で NFS 共有ストレージへの依存度が高まりました。
ソフトウェアスタックでは Slurm が 24 系から 25 系へ、CUDA が 12 系から 13 系へメジャーバージョンアップしています。既存のジョブスクリプトや CUDA アプリケーションの互換性は事前に確認してください。
Amazon Linux 2 と AWS Batch スケジューラは v3.15.0 が最後のサポートです。該当する環境をお使いの場合は早めの移行をおすすめします。
おわりに
ParallelCluster 2.x 代のどこかで AWS Batch のジョブスケジューラが追加でサポートされて、いつ使うんだと思っていたまま使う機会がなかったです。あれから 4 年ほど経過したと思うのですけど、未だに HPC を携わっていることに感慨深いものがあります。
