PCS AWS のコンピューティングノードのブートストラップと登録に関する問題のトラブルシューティング - AWS PCS
AWS PCS での Slurm の仕組みインスタンスログを取得するインスタンス ID から VPC/Subnet/Securityグループを取得するノード登録の問題Slurm クラスター結合の問題

翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。

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

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

  • ジョブが開始されない

  • のインスタンスに接続できません AWS Systems Manager

  • インスタンスが予期せずシャットダウンする

  • インスタンスは継続的に置き換えられます

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

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

AWS PCS での Slurm の仕組み

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

標準 Slurm ジョブ処理

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

  1. ジョブを送信すると、 はジョブslurmctldを検証してキューに入れます。

  2. リソースが利用可能になると、 は既存のノードをslurmctld割り当てます。

  3. slurmd デーモンは、割り当てられたノードでジョブを実行します。

PCS での Slurm AWS ジョブ処理

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

  1. ジョブを送信すると、 はジョブslurmctldを検証してキューに入れます。

  2. 追加の容量が必要な場合、 AWS PCS はコンピューティングノードグループの起動テンプレートを使用して新しい EC2 インスタンスを起動します。

  3. 新しいインスタンスはクラスターにブートストラップします。

    1. インスタンスは PCS AWS に登録されます。

    2. インスタンスは Slurm クラスターに参加します。

  4. リソースの準備ができたら、 はノード (新しくブートストラップされたノードを含む) をslurmctld割り当てます。

  5. slurmd デーモンは、割り当てられたノードでジョブを実行します。

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

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

AWS CLI

次のコマンドを使用して、コンピューティングノードからコンソール出力を取得します。

aws ec2 get-console-output --region us-east-1 --instance-id i-1234567890abcdef0 --output text

us-east-1 を AWS リージョンに、i-1234567890abcdef0 をインスタンス ID に置き換えます。

AWS Systems Manager

Systems Manager を使用してインスタンスに接続できる場合は、ブートストラップログファイルを直接表示できます。

  1. Systems Manager を使用してインスタンスに接続します。詳細については、「Systems Manager ユーザーガイド」の「セッションの開始」を参照してください。

  2. ブートストラップログファイルを表示します。

    sudo cat /var/log/amazon/pcs/bootstrap.log
注記

初期化フェーズ中に問題が発生した場合は、インスタンスに接続できるようになるまでに約 20 分待つ必要がある場合があります。Systems Manager および SSH サービスは、初期化が完了した後、または障害発生時にブートストラップ実行がタイムアウトに達した場合にのみ開始されます。

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

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

AWS マネジメントコンソール
VPC、サブネット、セキュリティグループを取得するには

  1. Amazon EC2 コンソールを開きます。

  2. [Instances] を選択します。

  3. インスタンス テーブルで、インスタンス ID を選択します。

  4. 表示されたインスタンスの概要で、VPC ID とサブネット ID を見つけます。

  5. インスタンスの概要で、セキュリティタブを選択します。

  6. セキュリティタブでセキュリティグループを見つけます。

AWS CLI

インスタンスの VPC、サブネット、およびセキュリティグループ情報を取得するには、次のコマンドを使用します。

aws ec2 describe-instances --instance-ids i-1234567890abcdef0 --query 'Reservations[*].Instances[*].{InstanceId:InstanceId,VpcId:VpcId,SubnetId:SubnetId,SecurityGroups:SecurityGroups[*].GroupId}' --output table

ノード登録の問題

ノード登録は、ブートストラップ中にコンピューティングノードによって実行される最初のアクションです。ノードは 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 ゲートウェイへのルートがあることを確認してください。詳細については次を参照してください:

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 に追加することもできます。

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 AWS に登録されていない場合 (EC2 インスタンスのRegisterComputeNodeGroupInstance呼び出しなし）、インスタンスログに次のようなエラーメッセージがないか確認してください。

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

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

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

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

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

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