AWS ParallelCluster 3.16.0 がリリースされ、診断ツール pcluster-diag が追加されたので試してみた
はじめに
AWS ParallelCluster 3.16.0 が 2026 年 8 月 21 日にリリースされました。アップデートの目玉は診断ツール pcluster-diag の追加です。pcluster-diag は、クラスターノード上でオンデマンドの診断チェックを実行できるコマンドラインツールです。大きな変更点としては Amazon Linux 2 と AWS Batch スケジューラのサポートが予告どおり終了しました。

アップデート内容早見
3.16.0 の変更のうち、運用に影響しそうなものをピックアップしました。
| 区分 | 内容 |
|---|---|
| 新機能 | 診断ツール pcluster-diag を ParallelCluster AMI に同梱 |
| 廃止 | Amazon Linux 2 のサポート終了 |
| 廃止 | AWS Batch をスケジューラとして使うサポートの終了 |
| 改善 | IMDS の一時的な接続失敗時に EBS ボリュームのアタッチをリトライ |
| 改善 | ログインノードの更新をコンピュートノードと同じヘッドノード主導の方式へ統一 |
| 改善 | ブートストラップファイルを /tmp から /opt/parallelcluster/tmp へ移動 |
| 改善 | fwupd-refresh.timer を無効化し、密結合ワークロードのスケール時の性能を改善 |
| 変更 | ParallelCluster 管理の NFS サーバーを NFSv4 のみに強制 |
| 変更 | NFS ロックマネージャーの既定ポートを 32768 から 4045 へ変更 |
| 変更 | CLI が tag:GetResources 権限を新たに要求 |
| 変更 | amazon-efs-utils を公式 EFS エンドポイントから取得 |
| 変更 | aws-parallelcluster-node を PyPI でなく全リージョンで S3 から取得 |
| 変更 | ExternalSlurmdbd 使用時のクラスター名を 40 文字までに制限 |
| 変更 | pcluster CLI が Python 3.13 をサポート |
| 変更 | FSx for Lustre の AutomaticBackupRetentionDays の上限を 35 から 90 へ引き上げ |
Amazon Linux 2 と AWS Batch スケジューラのサポートが終了しました
3.15.0 で予告されていたもので、予告どおり 3.16.0 でサポート終了となりました。Amazon Linux 2 のクラスターは Amazon Linux 2023 などへ、AWS Batch のクラスターは Slurm へ移行を検討してください。
NFS の lockd 既定ポートが 4045 へ変わりました
ParallelCluster が管理する NFS サーバー、つまりヘッドノードが NFSv4 のみに強制されました。NFSv3 のクライアントスタック(rpcbind、rpc-statd、lockd)は変更されていません。外部の NFSv3 サーバーは引き続きマウントできます。
あわせて NFS ロックマネージャー(lockd)の既定ポートが 32768 から 4045 へ変わりました。Linux のエフェメラルポート範囲は 32768〜60999 で、以前の既定値はこの範囲と重なっていました。散発的なマウント失敗の原因になっていたのではないでしょうか。3.16.0 ではエフェメラルポート範囲外の 4045 へ変更されています。
影響を受けるのは外部の NFSv3 サーバーをマウントするノードだけです。ParallelCluster が管理するストレージは NFSv4 でマウントされるため、こちらは影響を受けません。
CLI に tag:GetResources 権限が必要になりました
3.16.0 の pcluster CLI は tag:GetResources 権限を新たに要求します。ログインノードのロードバランサー ARN をタグから解決するために使われ、ログインノードを持つクラスターの更新がロードバランサーの検索の競合で失敗する不具合修正に伴って入った変更です。3.15.1 までは ELB のロードバランサーを一覧してから 1 つずつタグを引き、目的のものを探していました。3.16.0 ではタグ条件を指定して 1 回で引くようになっています。
この API を呼ぶのは、クラスター設定にログインノードのプールがある場合だけでした。ログインノードありのクラスターを使っているなら、権限の追加が必要です。
amazon-efs-utils の取得先が変わりました
amazon-efs-utils はソースからのビルドをやめ、公式の EFS エンドポイントから取得するようになりました。取得先は CloudFront ドメインの amazon-efs-utils.aws.com です。
影響を受けるのはインターネットアクセスのないサブネットで build-image を使う場合です。アウトバウンド通信を許可リストで制御しているなら、このドメインの追加が必要です。インターネットに出られる環境なら特に対応は不要です。
一方 aws-parallelcluster-node は PyPI ではなく S3 から取得するようになりました。PyPI からの取得はインターネット越しになりますが、S3 なら VPC エンドポイントからアクセスできます。インターネットに出られない環境や、プロキシ経由でしか出られない環境では扱いやすくなっています。
主なバージョンアップ
コンテナ実行まわりでは Enroot が 3 系から 4 系へメジャーバージョンアップしています。Pyxis も 0.20.0 から 0.24.0 へ上がりました。両方を使っているクラスターは移行時に動作確認してください。
| ソフトウェア | バージョン |
|---|---|
| Slurm | 25.11.6(25.11.4 から) |
| NVIDIA ドライバー、Fabric Manager、IMEX | 595.71.05(580.126.20 から) |
| CUDA Toolkit | 13.2.2(13.0.2 から) |
| DCGM | 4.6.0(4.5.1 から) |
| EFA インストーラー | 1.49.0(1.47.0 から) |
| Enroot | 4.2.1(3.4.1 から) |
| Pyxis | 0.24.0(0.20.0 から) |
注目の pcluster-diag とは
ノードの不調を切り分けるとき、定番の確認先を 1 つずつ当たることになります。Slurm デーモンの状態、munge の権限、IMDS の応答あたりです。pcluster-diag はその点検項目を 1 つのコマンドで検査してくれるツールです。ParallelCluster AMI にインストール済みのため、ノードにログインして sudo pcluster-diag と打つだけで使えます。
クラスターはジョブを受け付けるヘッドノードと、ジョブを実行するコンピュートノードで構成されます。ノードの死活監視はヘッドノードの clustermgtd が担い、コンピュートノード側では computemgtd が動きます。pcluster-diag はこのノードタイプの違いを見て、実行するチェック項目を変えます。
サブコマンドは describe-checks と run の 2 つだけ
サブコマンドは登録済みチェックを一覧する describe-checks と、チェックを実行してレポートを出す run の 2 つです。どちらも root で実行する必要があります。
執筆時点(2026 年 8 月 21 日)で公式ユーザーガイドに pcluster-diag のページが見当たりませんでした。一次情報は cookbook リポジトリのソースと README です。
WARNING があっても run は成功扱いになる
run は全体の成否を終了コードで返します。0 が成功で、それ以外は失敗です。1 件でも FAILURE か CHECK_ERROR があれば 0 になりません。WARNING は成功扱いで、何件あっても終了コードは 0 のままです。
| ステータス | 意味 | run 全体を失敗にするか |
|---|---|---|
PASSED |
条件を満たした | しない |
WARNING |
条件は満たしたが警告があった | しない |
CHECK_ERROR |
チェックが完了できなかった | する |
FAILURE |
チェックは完了し、条件を満たさなかった | する |
SKIPPED_BY_USER |
ユーザーが実行を承認しなかった | しない |
SKIPPED_NOT_APPLICABLE |
このノードには適用されない | しない |
登録されているチェックは 9 種類
3.16.0 タグのソースに登録されていたチェックは次のとおりです。説明は各チェックの check_description を日本語にしたものです。ノード上では次のコマンドで一覧できます。
sudo pcluster-diag describe-checks
| check_id | 説明 |
|---|---|
Imds |
IMDS が応答し、機能しているか |
CfnHup |
cfn-hup デーモンがヘッドノードでのみ動作し、正しく設定されているか |
ReservedUsersAndGroups |
ParallelCluster の予約ユーザーとグループが存在し、uid と gid を共有していないか |
CriticalPathsHaveExpectedPermissions |
ParallelCluster の重要ファイルが期待どおりのオーナー、グループ、パーミッションを持つか |
ClusterDaemonsAreRunning |
そのノードタイプに対応する管理デーモンが動いているか |
ClustermgtdHeartbeatIsHealthy |
clustermgtd のハートビートが新しいか |
DirectoryService |
ディレクトリサービス(NSS、SSSD、AD)の連携が健全か |
SlurmAccounting |
Slurm アカウンティング(slurmdbd、データベース、認証情報、設定)が健全か |
LustreFilesystem |
FSx for Lustre のファイルシステムがインストールされ、マウントされ、到達可能で、EFA 向けに設定されているか |
チェックは実行するノードのコンテキストを見て取捨選択されます。判断材料はノードタイプとクラスター設定です。適用外のチェックは SKIPPED_NOT_APPLICABLE としてレポートに記録されます。適用条件はチェックごとに違い、ソースでは次のように判定していました。
SlurmAccountingはヘッドノードで、クラスター設定にアカウンティングの宣言があるか、ノード上にセットアップ済みのときだけ実行されるClustermgtdHeartbeatIsHealthyはヘッドノードとコンピュートノードでのみ実行されるLustreFilesystemは FSx for Lustre が構成されているときだけ実行される
pcluster-diag を試してみた
確認結果
ノード上の操作には aws ssm send-command を使い、ParallelCluster 3.16.0 と ubuntu2404 のクラスターで確認しました。
- 9 種類のチェックが 4 秒で完了し、ステータス一覧はヘッドノードとコンピュートノードで一致した
- 作りたてのクラスターでは
ImdsだけがWARNINGになり、原因はインスタンスメタデータのインスタンスタグが無効だったこと WARNINGは成功扱いで、終了コードは 0 のままだったdescribe-checksとrunのどちらも、非 root では実行できずsudoが必要だったmunge.keyを 0644 に緩めるとFAILUREと終了コード 3 で検出された
検証環境
ジョブを投入しなくてもコンピュートノードを診断できるよう、MinCount を 1 にして 1 台を常時起動させています。
| 項目 | 値 |
|---|---|
| ParallelCluster | 3.16.0 |
| OS | ubuntu2404 |
| スケジューラ | Slurm 25.11.6 |
| クラスター名 | pcluster-diag-verify |
| ヘッドノード | t3a.small |
| コンピュートノード | t3a.small(MinCount 1、MaxCount 2) |
| ノード上の操作 | aws ssm send-command(AWS-RunShellScript、root 実行) |
| リージョン | ap-northeast-1 |
ヘッドノードが i-088be9e32dcc38be0、コンピュートノードが i-01848bba040e8ffce です。

ここからはノード上での操作です。Session Manager で対話接続しても同じ結果になります。
ヘッドノードにログインして、そのまま pcluster-diag と打つと弾かれます。sudo を付ければ実行できます。
ubuntu@ip-10-0-0-12:~$ pcluster-diag
-bash: /usr/local/bin/pcluster-diag: Permission denied
ubuntu@ip-10-0-0-12:~$ sudo pcluster-diag --version
pcluster-diag, version 1.0.0
以降のブロックはすべて root で実行しているため sudo を付けていません。
診断ツールの保存先は?
コマンドの場所とバージョンを確認します。
which pcluster-diag
ls -l /usr/local/bin/pcluster-diag
pcluster-diag --version
root 所有の -rwxr--r-- で置かれていること、--version が 1.0.0 を返すことを見ます。オーナー以外に実行ビットがありません。一般ユーザーで実行できないわけです。
/usr/local/bin/pcluster-diag
-rwxr--r-- 1 root root 183 Aug 18 19:31 /usr/local/bin/pcluster-diag
pcluster-diag, version 1.0.0
ヘッドノードで診断を実行する
ヘッドノードで run を実行します。
cd /root
pcluster-diag run
echo "exit code: $?"
ls -l /root/pcluster-diag-output/
終了コードは 0 で、レポートが 1 件保存されました。
exit code: 0
total 12
-rw-r--r-- 1 root root 10564 Aug 21 01:10 pcluster-diag-report-2026-08-21T01-10-12.json
所要時間は 4 秒でした。9 件のステータスは次のとおりでした。後半の 3 件はディレクトリサービス、Slurm アカウンティング、FSx for Lustre のいずれも構成していないためスキップされました。
| check_id | ステータス |
|---|---|
Imds |
WARNING |
CfnHup |
PASSED |
ReservedUsersAndGroups |
PASSED |
CriticalPathsHaveExpectedPermissions |
PASSED |
ClusterDaemonsAreRunning |
PASSED |
ClustermgtdHeartbeatIsHealthy |
PASSED |
DirectoryService |
SKIPPED_NOT_APPLICABLE |
SlurmAccounting |
SKIPPED_NOT_APPLICABLE |
LustreFilesystem |
SKIPPED_NOT_APPLICABLE |
Imds はインスタンスタグが読めず WARNING になった
実行された 6 件のうち、PASSED にならなかったのは Imds だけでした。レポートの該当エントリには、警告の code とメッセージが入っていました。
{
"check_id": "Imds",
"check_description": "Verify that IMDS is responsive and functional.",
"status": "WARNING",
"warnings": [
{
"code": "W1",
"message": "Instance tags metadata is not reachable via IMDS."
}
]
}
原因はインスタンスメタデータのインスタンスタグが無効だったことです。今回のノードはヘッドノード、コンピュートノードとも InstanceMetadataTags が disabled でした。チェックが叩く /latest/meta-data/tags/instance は 404 を返していました。ヘッドノードで有効化して違いがでるのか確かめます。
aws ec2 modify-instance-metadata-options \
--instance-id i-088be9e32dcc38be0 \
--instance-metadata-tags enabled
pcluster-diag run --output-file /tmp/tags-enabled.json
Imds だけが PASSED に変わります。
+Imds -> PASSED
CfnHup -> PASSED
ReservedUsersAndGroups -> PASSED
WARNING は成功扱いのため、有効化する前も終了コードは 0 のままでした。確認が終わったら既定の disabled に戻しておきます。
aws ec2 modify-instance-metadata-options \
--instance-id i-088be9e32dcc38be0 \
--instance-metadata-tags disabled
コンピュートノードでも同じコマンドを実行する
コンピュートノードでも同じ手順で run を実行しました。所要時間は 4 秒、終了コードは 0 でヘッドノードと同じ結果でした。
ノードタイプの違いはステータス一覧に出ませんでした
9 件のステータスはヘッドノードと同じでした。SlurmAccounting はソース上ヘッドノードでのみ実行されるチェックです。ただし今回はアカウンティングを構成しておらず、ヘッドノード側でもスキップされたため差が出ませんでした。
違いがあったのはnode_type が HeadNode から ComputeFleet に変わるのと、標準出力の内容の 2 か所でした。
ヘッドノードの結果。
{
"timestamp": "2026-08-21T01-10-12",
"pcluster_diag_version": "1.0.0",
"pcluster_version": "3.16.0",
"instance_id": "i-088be9e32dcc38be0",
"instance_type": "t3a.small",
"node_type": "HeadNode",
"cluster_config": "...",
"dna_json": "...",
"head_node_instance_id": "i-088be9e32dcc38be0"
}
こちらがコンピュートノードの結果です。
{
"timestamp": "2026-08-21T01-12-13",
"pcluster_diag_version": "1.0.0",
"pcluster_version": "3.16.0",
"instance_id": "i-01848bba040e8ffce",
"instance_type": "t3a.small",
"node_type": "ComputeFleet",
"cluster_config": "...",
"dna_json": "..."
}
2026-08-21 01:12:13,630 [ERROR] pcluster_diag.core.context_builder: Could not determine the head node instance id from CloudFormation: An error occurred (AccessDenied) when calling the DescribeStacks operation: User: arn:aws:sts::<アカウント ID>:assumed-role/pcluster-diag-verify-ComputeFl-... is not authorized to perform: cloudformation:DescribeStacks
コンピュートノードのインスタンスロールに cloudformation:DescribeStacks が無く、ヘッドノードのインスタンス ID を解決できませんでした。診断そのものは続行し、終了コードは 0 のままでした。
もう 1 か所の違いはチェックが内部で叩くコマンドです。ClusterDaemonsAreRunning の対象が clustermgtd と clusterstatusmgtd から computemgtd へ切り替わっていました。
2026-08-21 01:12:15,914 [INFO] pcluster_diag.util.shell: Executed command [... 'supervisorctl', 'status', 'cfn-hup']: exit code 4, stdout='cfn-hup: ERROR (no such process)\n'
2026-08-21 01:12:15,914 [INFO] pcluster_diag.core.runner: CfnHup: PASSED
2026-08-21 01:12:16,166 [INFO] pcluster_diag.util.shell: Executed command [... 'supervisorctl', 'status', 'computemgtd']: exit code 0, stdout='computemgtd RUNNING pid 3092, uptime 0:04:51\n'
2026-08-21 01:12:16,166 [INFO] pcluster_diag.core.runner: ClusterDaemonsAreRunning: PASSED
CfnHup はコンピュートノードでもスキップされませんでした。supervisorctl status cfn-hup が exit code 4、つまり no such process を返し、それをもって PASSED になりました。ヘッドノードでは動いていること、それ以外のノードでは動いていないことを 1 つのチェックで確認しているようです。
診断をわざと失敗させてみる
CriticalPathsHaveExpectedPermissions は /etc/munge/munge.key が条件になっています。オーナーの読み取りを求め、グループとその他への読み書きを禁じる条件となっています。わざと診断を失敗させたいので 0644 に権限を緩めてみます。
cd /root
stat -c '%a %U %G' /etc/munge/munge.key
chmod 0644 /etc/munge/munge.key
stat -c '%a %U %G' /etc/munge/munge.key
pcluster-diag run --output-file /tmp/broken-report.json
echo "exit code: $?"
chmod 0600 /etc/munge/munge.key
stat -c '%a %U %G' /etc/munge/munge.key
pcluster-diag run --output-file /tmp/restored-report.json
echo "exit code: $?"
systemctl is-active munge
/opt/slurm/bin/sinfo
権限を緩めたときの終了コードは 3、戻したあとは 0 です。munged は active のままです。
600 munge munge
+644 munge munge
+exit code: 3
600 munge munge
exit code: 0
active
PARTITION AVAIL TIMELIMIT NODES STATE NODELIST
queue1* up infinite 1 idle~ queue1-dy-compute1-1
queue1* up infinite 1 idle queue1-st-compute1-1
FAILURE になったエントリには、どのファイルがどのモードで何を許してはいけないのかが教えてくれました。これは親切。
{
"check_id": "CriticalPathsHaveExpectedPermissions",
"check_description": "Verify that ParallelCluster critical files have their expected owner, group, and permissions.",
"status": "FAILURE",
"errors": [
{
"code": "E4",
"message": "'/etc/munge/munge.key' has mode 0644, which must not grant group read, other read."
}
]
}
0600 に戻すと PASSED に戻り、終了コードも 0 になりました。munged は active のまま、sinfo も正常で、クラスターへの影響はありませんでした。
終了コードは失敗の種類ごとに分かれていました
失敗したときの終了コードは 1 種類ではありません。models/exceptions.py の ExitCode に 4 つ定義されており、今回確認できたのは 3 と 4 でした。
| 終了コード | 定数 | 今回 |
|---|---|---|
| 1 | INTERNAL_ERROR |
ソースで確認したのみ |
| 2 | CONTEXT_BUILD_ERROR |
ソースで確認したのみ |
| 3 | DIAGNOSTIC_CHECK_FAILURE |
munge.key を 0644 に緩めたときに |
| 4 | INSUFFICIENT_PRIVILEGES |
一般ユーザーで診断コマンドを実行したとき |
レポートの構造と保存先
レポートは context と results の 2 つの項目があります。
context: 診断日時、pcluster-diagのバージョン、ParallelCluster のバージョン、インスタンス ID、インスタンスタイプ、ノードタイプ(主なキーのみ)results: 各チェックのcheck_id、check_description、status。失敗にはerrors、警告にはwarningsが付く
全文折りたたみ
{
"context": {
"timestamp": "2026-08-22T03-52-04",
"pcluster_diag_version": "1.0.0",
"pcluster_version": "3.16.0",
"instance_id": "i-088be9e32dcc38be0",
"instance_type": "t3a.small",
"node_type": "HeadNode",
"cluster_config": {
"AdditionalPackages": null,
"AdditionalResources": null,
"CustomS3Bucket": null,
"DeploymentSettings": null,
"DevSettings": null,
"DirectoryService": null,
"HeadNode": {
"CustomActions": null,
"Dcv": null,
"DisableSimultaneousMultithreading": false,
"Iam": {
"AdditionalIamPolicies": [
{
"Policy": "arn:aws:iam::aws:policy/AmazonSSMManagedInstanceCore"
}
],
"InstanceProfile": null,
"InstanceRole": null,
"S3Access": null
},
"Image": null,
"Imds": {
"Secured": true
},
"InstanceType": "t3a.small",
"LocalStorage": {
"EphemeralVolume": null,
"RootVolume": {
"DeleteOnTermination": true,
"Encrypted": true,
"Iops": 3000,
"Size": 45,
"Throughput": 125,
"VolumeType": "gp3"
}
},
"Networking": {
"AdditionalSecurityGroups": null,
"ElasticIp": false,
"Proxy": null,
"SecurityGroups": null,
"SubnetId": "subnet-029f0fb0acc64043d"
},
"SharedStorageEfsSettings": null,
"SharedStorageType": "Ebs",
"Ssh": {
"AllowedIps": "0.0.0.0/0",
"KeyName": null
}
},
"Iam": null,
"Image": {
"CustomAmi": null,
"Os": "ubuntu2404"
},
"Imds": {
"ImdsSupport": "v2.0"
},
"LoginNodes": null,
"Monitoring": {
"Alarms": {
"Enabled": true
},
"Dashboards": {
"CloudWatch": {
"Enabled": false
}
},
"DetailedMonitoring": false,
"Logs": {
"CloudWatch": {
"DeletionPolicy": "Delete",
"Enabled": true,
"RetentionInDays": 180
},
"Rotation": {
"Enabled": true
}
}
},
"Region": "ap-northeast-1",
"Scheduling": {
"ScalingStrategy": "all-or-nothing",
"Scheduler": "slurm",
"SlurmQueues": [
{
"AllocationStrategy": "lowest-price",
"CapacityReservationTarget": null,
"CapacityType": "ONDEMAND",
"ComputeResources": [
{
"CapacityReservationTarget": null,
"CustomSlurmSettings": {},
"DisableSimultaneousMultithreading": false,
"DynamicNodePriority": 1000,
"Efa": {
"Enabled": false,
"GdrSupport": false
},
"HealthChecks": {
"Gpu": {
"Enabled": null
}
},
"Instances": [
{
"InstanceType": "t3a.small"
}
],
"LaunchTemplateOverrides": null,
"MaxCount": 2,
"MinCount": 1,
"Name": "compute1",
"Networking": {
"PlacementGroup": {
"Enabled": null,
"Id": null,
"Name": null
}
},
"SchedulableMemory": null,
"SpotPrice": null,
"StaticNodePriority": 1,
"Tags": null
}
],
"ComputeSettings": {
"LocalStorage": {
"EphemeralVolume": null,
"RootVolume": {
"Encrypted": true,
"Iops": 3000,
"Size": 45,
"Throughput": 125,
"VolumeType": "gp3"
}
}
},
"CustomActions": null,
"CustomSlurmSettings": {},
"HealthChecks": {
"Gpu": {
"Enabled": null
}
},
"Iam": {
"AdditionalIamPolicies": [
{
"Policy": "arn:aws:iam::aws:policy/AmazonSSMManagedInstanceCore"
}
],
"InstanceProfile": null,
"InstanceRole": null,
"S3Access": null
},
"Image": null,
"JobExclusiveAllocation": false,
"Name": "queue1",
"Networking": {
"AdditionalSecurityGroups": null,
"AssignPublicIp": null,
"PlacementGroup": {
"Enabled": null,
"Id": null,
"Name": null
},
"Proxy": null,
"SecurityGroups": null,
"SubnetIds": [
"subnet-0897827eb4d8cd2fe"
]
},
"Tags": null
}
],
"SlurmSettings": {
"CustomSlurmSettings": null,
"CustomSlurmSettingsIncludeFile": null,
"Database": null,
"Dns": {
"DisableManagedDns": false,
"HostedZoneId": null,
"UseEc2Hostnames": false
},
"EnableMemoryBasedScheduling": false,
"ExternalSlurmdbd": null,
"MungeKeySecretArn": null,
"QueueUpdateStrategy": "COMPUTE_FLEET_STOP",
"ScaledownIdletime": 5
}
},
"SharedStorage": null,
"Tags": [
{
"Key": "Name",
"Value": "cluster-v3.16.0-pcluster-diag"
},
{
"Key": "parallelcluster:cluster-name",
"Value": "pcluster-diag-verify"
},
{
"Key": "parallelcluster:version",
"Value": "3.16.0"
}
]
},
"dna_json": {
"cluster": {
"stack_name": "pcluster-diag-verify",
"stack_arn": "arn:aws:cloudformation:ap-northeast-1:123456789012:stack/pcluster-diag-verify/0ca26650-9cfb-11f1-b77a-0663628fe01d",
"raid_vol_ids": "",
"raid_shared_dir": "",
"raid_type": "",
"base_os": "ubuntu2404",
"region": "ap-northeast-1",
"shared_storage_type": "ebs",
"default_user_home": "shared",
"efs_fs_ids": "",
"efs_shared_dirs": "",
"efs_encryption_in_transits": "",
"efs_iam_authorizations": "",
"efs_access_point_ids": "",
"fsx_fs_ids": "",
"fsx_mount_names": "",
"fsx_dns_names": "",
"fsx_volume_junction_paths": "",
"fsx_fs_types": "",
"fsx_shared_dirs": "",
"volume": "",
"scheduler": "slurm",
"ephemeral_dir": "/scratch",
"ebs_shared_dirs": "",
"proxy": "NONE",
"node_type": "HeadNode",
"cluster_user": "ubuntu",
"ddb_table": "parallelcluster-pcluster-diag-verify",
"log_group_name": "/aws/parallelcluster/pcluster-diag-verify-202608210055",
"dcv_enabled": "false",
"dcv_port": "NONE",
"enable_intel_hpc_platform": "false",
"cw_logging_enabled": "true",
"log_rotation_enabled": "true",
"cluster_s3_bucket": "parallelcluster-50bb4ae12fec178e-v1-do-not-delete",
"cluster_config_s3_key": "parallelcluster/3.16.0/clusters/pcluster-diag-verify-2jt60003s7xtui8o/configs/cluster-config-with-implied-values.yaml",
"cluster_config_version": "umHZcAYU9ccWH1sCEk7qPuB_EOnAeNd_",
"instance_types_data_version": "fBJZrI7ePvQtycamnKGJ38VyAkEK7fzm",
"change_set_s3_key": "parallelcluster/3.16.0/clusters/pcluster-diag-verify-2jt60003s7xtui8o/configs/change-set.json",
"instance_types_data_s3_key": "parallelcluster/3.16.0/clusters/pcluster-diag-verify-2jt60003s7xtui8o/configs/instance-types-data.json",
"custom_node_package": "",
"head_node_imds_secured": "true",
"compute_node_bootstrap_timeout": 2100,
"disable_sudo_access_for_default_user": "false",
"launch_template_id": "HeadNodeLaunchTemplate",
"dns_domain": "pcluster-diag-verify.pcluster.",
"hosted_zone": "Z0247083T3YMGX1J5GQQ",
"slurm_ddb_table": "parallelcluster-slurm-pcluster-diag-verify",
"use_private_hostname": "false"
}
},
"head_node_instance_id": "i-088be9e32dcc38be0"
},
"results": [
{
"check_id": "Imds",
"check_description": "Verify that IMDS is responsive and functional.",
"status": "WARNING",
"warnings": [
{
"code": "W1",
"message": "Instance tags metadata is not reachable via IMDS."
}
]
},
{
"check_id": "CfnHup",
"check_description": "Verify that the cfn-hup daemon runs only on the head node and it is properly configured.",
"status": "PASSED"
},
{
"check_id": "ReservedUsersAndGroups",
"check_description": "Verify that reserved ParallelCluster users and groups exist and do not share their uid/gid.",
"status": "PASSED"
},
{
"check_id": "CriticalPathsHaveExpectedPermissions",
"check_description": "Verify that ParallelCluster critical files have their expected owner, group, and permissions.",
"status": "PASSED"
},
{
"check_id": "ClusterDaemonsAreRunning",
"check_description": "Verify that the ParallelCluster management daemons for this node type are running.",
"status": "PASSED"
},
{
"check_id": "ClustermgtdHeartbeatIsHealthy",
"check_description": "Verify that the clustermgtd heartbeat is fresh (clustermgtd is not stalled).",
"status": "PASSED"
},
{
"check_id": "DirectoryService",
"check_description": "Verify that the directory service (NSS/SSSD/AD) integration is healthy.",
"status": "SKIPPED_NOT_APPLICABLE"
},
{
"check_id": "SlurmAccounting",
"check_description": "Verify that Slurm accounting (slurmdbd, database, credentials, and configuration) is healthy.",
"status": "SKIPPED_NOT_APPLICABLE"
},
{
"check_id": "LustreFilesystem",
"check_description": "Verify that FsxLustre filesystems are installed, mounted, reachable, and configured for EFA.",
"status": "SKIPPED_NOT_APPLICABLE"
}
]
}
スキップされたチェックには理由が記録されていませんでした。SKIPPED_NOT_APPLICABLE のエントリはフィールド 3 つだけでした。
context には cluster_config と dna_json が丸ごと入るため、レポート 1 本は 10KB ほどになりました。出力先はカレントディレクトリ配下です。cd /root で実行したので /root/pcluster-diag-output/ 配下に JSON ファイルが保存されました。絶対パスに固定されていないので実行するディレクトリには気を付けてください。--output-file を付ければ保存先を指定できます。
まとめ
AWS ParallelCluster 3.16.0 では診断ツール pcluster-diag が追加されました。9 種類のチェックがノードの構成に応じて 1 つのコマンドでチェック可能です。
その他、大きなところでは Amazon Linux 2 と AWS Batch スケジューラのサポートが終了しました。外部の NFSv3 サーバーをマウントしているクラスターは、lockd の既定ポートが 4045 へ変わった点を確認してください。
おわりに
ParallelCluster のアップデートを最速でお届けできたと思いたい、そんな土曜日でした。








