AWS ParallelCluster 3.16.0 がリリースされ、診断ツール pcluster-diag が追加されたので試してみた

AWS ParallelCluster 3.16.0 がリリースされ、診断ツール pcluster-diag が追加されたので試してみた

AWS ParallelCluster 3.16.0がリリースされ、新しい診断ツール `pcluster-diag` が追加されました。このツールを使ってクラスターノードの健全性を簡単に検査できるようになります。本記事では、`pcluster-diag` の使い方や実際の動作、そして3.16.0のその他の重要な変更点についてまとめています。
2026.08.22

はじめに

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

parallelcluster-3-16-0-pcluster-diag.png

https://github.com/aws/aws-parallelcluster/releases/tag/v3.16.0

アップデート内容早見

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 へ移行を検討してください。

https://dev.classmethod.jp/articles/aws-parallelcluster-v3150-p6-b300-update/

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 回で引くようになっています。

https://github.com/aws/aws-parallelcluster/commit/62f74578903bbd757124c3a37e231ed27c0bd6af

この API を呼ぶのは、クラスター設定にログインノードのプールがある場合だけでした。ログインノードありのクラスターを使っているなら、権限の追加が必要です。

https://github.com/aws/aws-parallelcluster/blob/v3.16.0/cli/src/pcluster/models/cluster.py#L286-L293

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 です。

https://github.com/aws/aws-parallelcluster-cookbook/tree/v3.16.0/cookbooks/aws-parallelcluster-platform/files/pcluster-diag

WARNING があっても run は成功扱いになる

run は全体の成否を終了コードで返します。0 が成功で、それ以外は失敗です。1 件でも FAILURECHECK_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-checksrun のどちらも、非 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-commandAWS-RunShellScript、root 実行)
リージョン ap-northeast-1

ヘッドノードが i-088be9e32dcc38be0、コンピュートノードが i-01848bba040e8ffce です。

インスタンス___EC2___ap-northeast-1_🔊-3.png

ここからはノード上での操作です。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-- で置かれていること、--version1.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 件保存されました。

実行結果(抜粋。run が出力した JSON は省略)
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."
    }
  ]
}

原因はインスタンスメタデータのインスタンスタグが無効だったことです。今回のノードはヘッドノード、コンピュートノードとも InstanceMetadataTagsdisabled でした。チェックが叩く /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_typeHeadNode から ComputeFleet に変わるのと、標準出力の内容の 2 か所でした。

ヘッドノードの結果。

実行結果(抜粋。cluster_config と dna_json は省略)
{
  "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"
}

こちらがコンピュートノードの結果です。

実行結果(抜粋。cluster_config と dna_json は省略)
{
  "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 の対象が clustermgtdclusterstatusmgtd から 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 のままです。

実行結果(抜粋。run が出力した JSON は省略)
 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.pyExitCode に 4 つ定義されており、今回確認できたのは 3 と 4 でした。

終了コード 定数 今回
1 INTERNAL_ERROR ソースで確認したのみ
2 CONTEXT_BUILD_ERROR ソースで確認したのみ
3 DIAGNOSTIC_CHECK_FAILURE munge.key を 0644 に緩めたときに
4 INSUFFICIENT_PRIVILEGES 一般ユーザーで診断コマンドを実行したとき

レポートの構造と保存先

レポートは contextresults の 2 つの項目があります。

  • context: 診断日時、pcluster-diag のバージョン、ParallelCluster のバージョン、インスタンス ID、インスタンスタイプ、ノードタイプ(主なキーのみ)
  • results: 各チェックの check_idcheck_descriptionstatus。失敗には 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_configdna_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 のアップデートを最速でお届けできたと思いたい、そんな土曜日でした。

参考

この記事をシェアする

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

関連記事