Slurm が PCS AWS で機能する方法インスタンスログを取得するインスタンス ID から VPC/Subnet/Securityグループを取得するノード登録の問題 Slurm クラスター結合の問題

PCS AWS のコンピューティングノードのブートストラップと登録に関する問題のトラブルシューティング

コンピューティングノードのブートストラップまたは PCS AWS クラスターへの適切な登録に失敗すると、次の症状が発生する可能性があります。

ジョブが開始されない
のインスタンスに接続できません AWS Systems Manager
インスタンスが予期せずシャットダウンする
インスタンスは継続的に置き換えられます

これらの障害は、EC2 インスタンスの起動中または PCS AWS コンピューティングノードのブートストラッププロセス中に発生する可能性があります。このトピックでは、PCS AWS ノードのブートストラッププロセス中の問題のトラブルシューティングに役立つ手順について説明します。EC2 インスタンスの起動のトラブルシューティングの詳細については、Amazon EC2 インスタンスの起動に関する問題のトラブルシューティング」を参照してください。

ブートストラップの失敗は、EC2 インスタンスが正常に起動したが、PCS AWS クラスターの結合プロセス中に失敗した場合に発生します。ブートストラッププロセスには、主に 2 つのフェーズがあります。

ノード登録 – EC2 インスタンスは RegisterComputeNodeGroupInstance AWS PCS API アクションを呼び出して PCS AWS サービスに登録します。以下の問題が原因で障害が発生する可能性があります。
- アクセス許可
  - インスタンスプロファイルが正しくありません
- ネットワーク
- クラスターシークレット
  - クラスターシークレットが削除されたか、削除対象としてマークされている
Slurm 統合 – インスタンスは Slurm クラスターを実行してslurmd結合します。以下の問題が原因で障害が発生する可能性があります。
- アクセス許可
  - セキュリティグループの構成
  - Slurmctld がコンピューティングノードに ping できない
- カスタム AMI セットアップ
  - NVIDIA ドライバーが見つからない
  - ResumeTimeout に到達しました

Slurm が PCS AWS で機能する方法

これは、Slurm の標準的な動作と Slurm が AWS PCS で動作する方法を比較するのに役立ちます。

標準 Slurm ジョブ処理

次の手順は、標準の Slurm ジョブ処理で発生します。

ジョブを送信すると、はジョブslurmctldを検証してキューに入れます。
リソースが利用可能になると、は既存のノードをslurmctld割り当てます。
slurmd デーモンは、割り当てられたノードでジョブを実行します。

PCS での Slurm AWS ジョブ処理

PCS AWS ジョブ処理では、次の手順を実行します。

ジョブを送信すると、はジョブslurmctldを検証してキューに入れます。
追加の容量が必要な場合、 AWS PCS はコンピューティングノードグループの起動テンプレートを使用して新しい EC2 インスタンスを起動します。
新しいインスタンスはクラスターにブートストラップします。
1. インスタンスは PCS AWS に登録されます。
2. インスタンスは Slurm クラスターに参加します。
リソースの準備ができると、はノード (新しくブートストラップされたノードを含む) をslurmctld割り当てます。
slurmd デーモンは、割り当てられたノードでジョブを実行します。

インスタンスログを取得する

コンピューティングノードのブートストラップ問題のトラブルシューティングの最初のステップは、インスタンスログの取得です。次のいずれかの方法を使用します。

インスタンス ID から VPC/Subnet/Securityグループを取得する

コンピューティングノードの問題をトラブルシューティングするには、インスタンスに関連付けられた VPC、サブネット、およびセキュリティグループに関する情報を取得する必要がある場合があります。インスタンス IDs「」を参照してくださいPCS AWS でのコンピューティングノードグループインスタンスの検索。

ノード登録の問題

ノード登録は、ブートストラップ中にコンピューティングノードによって実行される最初のアクションです。ノードは PCS API AWS エンドポイントを呼び出して、自身を PCS AWS に登録します。登録の失敗は通常、次のようなエラーメッセージを表示します。

<13>Nov 13 16:23:50 user-data: [2025-11-13T16:23:50.510+00:00] - /opt/aws/pcs/bin/pcs_bootstrap_init.sh: INFO: Registering node to cluster <clusterId>
<13>Nov 13 16:24:18 user-data: [2025-11-13T16:24:18.192+00:00] - /opt/aws/pcs/bin/pcs_bootstrap_init.sh: INFO: Retriable exception detected.
<13>Nov 13 16:24:18 user-data: [2025-11-13T16:24:18.193+00:00] - /opt/aws/pcs/bin/pcs_bootstrap_init.sh: INFO: Response is [specific error message]
<13>Nov 13 16:24:18 user-data: [2025-11-13T16:24:18.194+00:00] - /opt/aws/pcs/bin/pcs_bootstrap_init.sh: INFO: Retrying in 31 seconds...
<13>Nov 13 16:24:18 user-data: [2025-11-13T16:24:18.192+00:00] - /opt/aws/pcs/bin/pcs_bootstrap_init.sh: INFO: Retriable exception detected.
...
<13>Nov 13 16:25:18 user-data: [2025-11-13T16:25:18.195+00:00] - /opt/aws/pcs/bin/pcs_bootstrap_init.sh: INFO: Registration timeout (600 seconds) reached. Exiting.
<13>Nov 13 16:25:18 user-data: [2025-11-13T16:25:18.200+00:00] - /opt/aws/pcs/bin/pcs_bootstrap_init.sh: ERROR: Error: (2) occurred on line 1 when running /opt/aws/pcs/bin/pcs_bootstrap_init.sh. Shutting down instance.

インスタンスプロファイルが正しくありません

インスタンスプロファイルが正しくないためにノードを登録できない場合は、次のエラーが表示されます。

<13>Nov 13 18:43:08 user-data: [2025-11-13T18:43:08.268+00:00] - /opt/aws/pcs/bin/pcs_bootstrap_init.sh: INFO: Response is {
<13>Nov 13 18:43:08 user-data:   "__type": "com.amazon.coral.service#AccessDeniedException",
<13>Nov 13 18:43:08 user-data:   "Message": "User: arn:aws:sts::<accountId>:assumed-role/<roleName>/<instanceId> is not authorized to perform: pcs:RegisterComputeNodeGroupInstance on resource: arn:aws:pcs:<regionCode>:<accountId>:cluster/<clusterId> as either the resource does not exist, some policy explicitly denies access, or no policy grants access",
<13>Nov 13 18:43:08 user-data:   "nodeID": null
<13>Nov 13 18:43:08 user-data: }

コンピューティングノードに関連付けられたインスタンスプロファイルにアクセスpcs:RegisterComputeNodeGroupInstance許可があることを確認します。有効なインスタンスプロファイルを作成する方法の詳細については、「」を参照してくださいPCS AWS のインスタンスプロファイルを作成する。

AWS PCS エンドポイントに接続できない

コンピューティングノードがプライベートサブネットにある場合は、PCS の VPC AWS エンドポイントが設定されているか、サブネットにインターネットアクセス用の NAT ゲートウェイへのルートがあることを確認してください。詳細については次を参照してください:

Amazon Virtual Private Cloud AWS PrivateLink ガイドのインターフェイス VPC エンドポイントを使用して AWS サービスにアクセスします。
AWS PCS のエンドポイントとサービスクォータ.
「Amazon Virtual Private Cloud ユーザーガイド」の「VPC を他のネットワークに接続するAmazon Virtual Private Cloud」
AWS PCS ネットワーク

PCS AWS エンドポイントの設定ミス

次のようなエラーメッセージが表示された場合は、PCS VPC AWS エンドポイントに関連付けられているポリシーを確認します。

com.amazon.coral.security.AccessDeniedException: User: arn:aws:sts::xxx:assumed-role/<roleName>/<instanceId> is not authorized to perform: pcs:RegisterComputeNodeGroupInstance on resource: arn:aws:pcs:<regionCode>:<accountId>:cluster/<clusterId> as either the resource does not exist, some policy explicitly denies access, or no policy grants access

PCS の VPC AWS インターフェイスエンドポイントを設定する方法の詳細については、「」を参照してくださいインターフェイスエンドポイント (AWS PrivateLink) AWS Parallel Computing Service を使用したへのアクセス。

パブリック IP のないパブリックサブネット内のインスタンス

サブネットでパブリック IP の自動割り当てが有効になっていず、ルート設定でインターネットゲートウェイを使用している場合、インスタンスは AWS PCS API と通信できません。

インターネットゲートウェイを持つサブネット内のインスタンスには、パブリック IP アドレスが必要です。この問題を解決するには、次のいずれかのオプションを選択します。

PCS AWS の VPC エンドポイントをクラスター VPC に追加します。これにより、パブリック IP アドレスがインターネットゲートウェイを通過することなく、インスタンスが AWS PCS と通信できるようになります。
NAT ゲートウェイでプライベートサブネットを使用するため、パブリック IP アドレスは必要ありません。
サブネットまたは起動テンプレートを介して自動パブリック IP アドレス割り当てを有効にして、インスタンスがインターネットゲートウェイを介して API に連絡できるようにします。このオプションは、マルチネットワークインターフェイスインスタンスでは有効ではないことに注意してください。

パブリックサブネットのマルチ NIC インスタンス

複数のネットワークインターフェイス (NICs) を持つインスタンスタイプを使用する場合は、プライベートサブネットを使用する必要があります。

AWS パブリック IP アドレスは、単一のネットワークインターフェイスで起動されたインスタンスにのみ割り当てることができます。IP アドレスの詳細については、「Linux インスタンス用 Amazon EC2 ユーザーガイド」の「インスタンスの起動時にパブリック IPv4 アドレスを割り当てる」を参照してください。 Amazon EC2

マルチ NIC インスタンスタイプでは、PCS エンドポイントにアクセスするために、サブネット内の NAT AWS ゲートウェイまたは内部プロキシが必要です。または、PCS AWS の VPC エンドポイントをクラスター VPC に追加することもできます。

クラスターシークレットが削除されたか、削除対象としてマークされている

AWS Secrets Manager の Slurm 共有シークレットが削除された場合、または削除対象としてマークされている場合、コンピューティングノードは登録に失敗し、クラスターに障害が発生します。

AWS PCS は、クラスターの作成時に AWS Secrets Manager (名前形式: pcs!slurm-secret-<cluster-id>) で Slurm 共有シークレットを自動的に作成します。このシークレットは、クラスター内の安全な通信に必要です。詳細については、「PCS AWS でのクラスターシークレットの使用」を参照してください。

このシークレットを削除または削除対象としてマークすると、新しいノードはクラスターに参加できず、再起動するとコントローラーやその他のクラスターデーモン ( slurmdやなどslurmdbd) はクラスターに再参加できない可能性があります。

この問題を解決するには、削除されたシークレットがまだ復旧ウィンドウ内にある場合に復元できます。詳細な手順については、「AWS Secrets Manager シークレットの復元」を参照してください。

復旧期間が終了すると、シークレットは復元できず、影響を受ける AWS PCS クラスターは復元できません。同じ設定で新しいクラスターを作成する必要があります。 AWS PCS は新しいスケジューラシークレットを自動的に作成します。

Slurm クラスター結合の問題

ノード登録が成功すると、コンピューティングノードは Slurm クラスターに参加しようとします。ノードのslurmdデーモンは Slurm コントローラーに連絡してクラスターに登録します。通常、Slurm 結合の失敗には次のようなエラーメッセージが表示されます。

<13>Nov  5 17:20:29 user-data: [2024-11-05T17:20:28+00:00] FATAL: Mixlib::ShellOut::ShellCommandFailed: service[slurmd] (aws-pcs-slurm::finalize_slurm line 18) had an error: Mixlib::ShellOut::ShellCommandFailed: Expected process to exit with [0], but received '1'  
<13>Nov  5 17:20:29 user-data: ---- Begin output of ["/usr/bin/systemctl", "--system", "start", "slurmd"] ----  
<13>Nov  5 17:20:29 user-data: STDOUT:   
<13>Nov  5 17:20:29 user-data: STDERR: Job for slurmd.service failed because the control process exited with error code. See "systemctl status slurmd.service" and "journalctl -xe" for details.  
<13>Nov  5 17:20:29 user-data: ---- End output of ["/usr/bin/systemctl", "--system", "start", "slurmd"] ----

セキュリティグループの構成

コンピューティングノードと Slurm コントローラー間の通信を許可するようにセキュリティグループが正しく設定されていることを確認します。セキュリティグループは、次のトラフィックを許可する必要があります。

と通信slurmdするためののポート 6817 slurmctld
から ping slurmctldへのポート 6818 slurmd

セキュリティグループの要件の詳細については、以下のトピックを参照してください。

重要

クラスターの作成時にクラスターに関連付けたクラスターセキュリティグループは、コンピューティングノードがコントローラーと通信できるように、コンピューティングノードグループセキュリティグループでも設定する必要があります。

NVIDIA ドライバーが見つからない

インスタンスが正しくブートストラップしてもジョブが起動せず、インスタンスログに次のようなエラーメッセージが表示される場合は、NVIDIA ドライバーがない可能性があります。

<13>Dec  2 13:52:00 user-data: [2024-12-02T13:52:00.094+00:00] - /opt/aws/pcs/bin/pcs_bootstrap_config_always.sh: INFO: nvidia-smi not found!  
...  
<13>Dec  2 13:54:10 user-data: Job for slurmd.service failed because the control process exited with error code. See "systemctl status slurmd.service" and "journalctl -xe" for details.  
<13>Dec  2 13:54:12 user-data: [2024-12-02T13:54:12.718+00:00] - /opt/aws/pcs/bin/pcs_bootstrap_finalize.sh: INFO: systemctl could not start slurmd!

インスタンスに接続してslurmdデーモンのステータスを確認すると、次のようなエラーが表示されることがあります。

$ systemctl status slurmd  
...  
fatal: can't stat gres.conf file /dev/nvidia0: No such file or directory

この問題を解決するには、カスタム AMI に NVIDIA ドライバーをインストールします。詳細については、「ステップ 4 – (オプション) 追加のドライバー、ライブラリ、アプリケーションソフトウェアをインストールする」を参照してください。

ResumeTimeout に到達しました

ノードが異常であるためにコンピューティングノードとその EC2 インスタンスが終了した場合、 AWS PCS は AMI をサポートしていないか、ネットワークに問題がある可能性があります。EC2 インスタンスは、Slurm の ResumeTimeout に達するまで約 30 分間実行され、ノードをとしてマークしますDOWN。

インスタンスが正しくブートストラップされず、PCS に登録されていない場合 (EC2 AWS インスタンスのRegisterComputeNodeGroupInstance呼び出しなし）、インスタンスログに次のようなエラーメッセージがないか確認してください。

/opt/aws/pcs/bin/pcs_bootstrap_init.sh: No such file or directory

このエラーは、PCS AWS ブートストラップソフトウェアが AMI の一部ではないことを示します。この問題を解決するには、カスタム AMI に PCS AWS ブートストラップソフトウェアが含まれていることを確認してください。詳細については、「PCS のカスタム Amazon AWS マシンイメージ (AMIs)」を参照してください。

Slurmctld がコンピューティングノードに ping できない

インスタンスがブートストラッププロシージャを正しく実行し、PCS AWS に登録されているが、それを表示してジョブを送信slurmctldできない場合、インスタンスはしばらくDOWNしてからに設定され、終了します。

これは、セキュリティグループの設定ミスが原因である可能性があります。たとえば、ポート 6817 でとのslurmd通信が許可されているがslurmctld、ポート 6818 で slurmctld ping が許可されていない場合ですslurmd。

「」で説明されているように、セキュリティグループにすべての必要なルールが含まれていることを確認しますセキュリティグループの要件と考慮事項。

ブラウザで JavaScript が無効になっているか、使用できません。

AWS ドキュメントを使用するには、JavaScript を有効にする必要があります。手順については、使用するブラウザのヘルプページを参照してください。

ドキュメントの表記規則

再起動後に EC2 インスタンスが終了して置き換えられる

ジョブ送信 MaxJobCount の制限