翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。
# PCS AWS のコンピューティングノードのブートストラップと登録に関する問題のトラブルシューティング
コンピューティングノードのブートストラップまたは PCS AWS クラスターへの適切な登録に失敗すると、次の症状が発生する可能性があります。
+ ジョブが開始されない
+ のインスタンスに接続できません AWS Systems Manager
+ インスタンスが予期せずシャットダウンする
+ インスタンスは継続的に置き換えられます
これらの障害は、EC2 インスタンスの起動中または PCS AWS コンピューティングノードのブートストラッププロセス中に発生する可能性があります。このトピックでは、PCS AWS ノードのブートストラッププロセス中の問題のトラブルシューティングに役立つ手順について説明します。EC2 インスタンスの起動のトラブルシューティングの詳細については、[Amazon EC2 インスタンスの起動に関する問題のトラブルシューティング](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/troubleshooting-launch.html)」を参照してください。 **
ブートストラップの失敗は、EC2 インスタンスが正常に起動したが、PCS AWS クラスターの結合プロセス中に失敗した場合に発生します。ブートストラッププロセスには、主に 2 つのフェーズがあります。
+ **ノード登録** – EC2 インスタンスは [RegisterComputeNodeGroupInstance](https://docs.aws.amazon.com/pcs/latest/APIReference/API_RegisterComputeNodeGroupInstance.html) AWS PCS API アクションを呼び出して PCS AWS サービスに登録します。以下の問題が原因で障害が発生する可能性があります。
+ アクセス許可
+ [インスタンスプロファイルが正しくありません](#troubleshooting-compute-node-bootstrap-wrong-instance-profile)
+ ネットワーク
+ [AWS PCS エンドポイントに接続できない](#troubleshooting-compute-node-bootstrap-connect-to-endpoints)
+ [PCS AWS エンドポイントの設定ミス](#troubleshooting-compute-node-bootstrap-misconfigured-pcs-endpoint)
+ [パブリック IP のないパブリックサブネット内のインスタンス](#troubleshooting-compute-node-bootstrap-public-subnet-no-public-ip)
+ [パブリックサブネットのマルチ NIC インスタンス](#troubleshooting-compute-node-bootstrap-multi-nic-public-subnet)
+ クラスターシークレット
+ [クラスターシークレットが削除されたか、削除対象としてマークされている](#troubleshooting-compute-node-bootstrap-cluster-secret-deleted)
+ **Slurm 統合** – インスタンスは Slurm クラスターを実行して`slurmd`結合します。以下の問題が原因で障害が発生する可能性があります。
+ アクセス許可
+ [セキュリティグループの構成](#troubleshooting-compute-node-bootstrap-security-groups)
+ [Slurmctld がコンピューティングノードに ping できない](#troubleshooting-compute-node-bootstrap-slurmctld-ping-issue)
+ カスタム AMI セットアップ
+ [NVIDIA ドライバーが見つからない](#troubleshooting-compute-node-bootstrap-missing-nvidia-drivers)
+ [ResumeTimeout に到達しました](#troubleshooting-compute-node-bootstrap-resume-timeout)
## Slurm が PCS AWS で機能する方法
これは、Slurm の標準的な動作と Slurm が AWS PCS で動作する方法を比較するのに役立ちます。
**標準 Slurm ジョブ処理**
次の手順は、標準の Slurm ジョブ処理で発生します。
1. ジョブを送信すると、 はジョブ`slurmctld`を検証してキューに入れます。
1. リソースが利用可能になると、 は既存のノードを`slurmctld`割り当てます。
1. `slurmd` デーモンは、割り当てられたノードでジョブを実行します。
**PCS での Slurm AWS ジョブ処理**
PCS AWS ジョブ処理では、次の手順を実行します。
1. ジョブを送信すると、 はジョブ`slurmctld`を検証してキューに入れます。
1. **追加の容量が必要な場合、 AWS PCS はコンピューティングノードグループの起動テンプレートを使用して新しい EC2 インスタンスを起動します。**
1. **新しいインスタンスはクラスターにブートストラップします。**
1. **インスタンスは PCS AWS に登録されます。**
1. **インスタンスは Slurm クラスターに参加します。**
1. リソースの準備ができると、 はノード (新しくブートストラップされたノードを含む) を`slurmctld`割り当てます。
1. `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 ユーザーガイド*[」の「セッション](https://docs.aws.amazon.com/systems-manager/latest/userguide/session-manager-working-with-sessions-start.html#start-ec2-console)の開始」を参照してください。
1. ブートストラップログファイルを表示します。
```
sudo cat /var/log/amazon/pcs/bootstrap.log
```
**注記**
初期化フェーズ中に問題が発生した場合は、インスタンスに接続できるようになるまでに約 20 分待つ必要がある場合があります。Systems Manager と SSH サービスは、初期化が完了した後、または障害発生時にブートストラップ実行がタイムアウトに達した後にのみ開始されます。
------
## インスタンス ID から VPC/Subnet/Securityグループを取得する
コンピューティングノードの問題をトラブルシューティングするには、インスタンスに関連付けられた VPC、サブネット、およびセキュリティグループに関する情報を取得する必要がある場合があります。インスタンス IDs「」を参照してください[PCS AWS でのコンピューティングノードグループインスタンスの検索](working-with_compute-instances.md)。
------
#### [ AWS マネジメントコンソール ]
**VPC、サブネット、セキュリティグループを取得するには**
1. [Amazon EC2 コンソール](https://console.aws.amazon.com/ec2)を開きます。
1. [**Instances**] を選択します。
1. **インスタンス** テーブルで、インスタンス ID を選択します。
1. 表示されたインスタンスの概要で**、VPC ID** と**サブネット ID** を見つけます。
1. インスタンスの概要で、**セキュリティ**タブを選択します。
1. セキュリティタブで**セキュリティ****グループ**を見つけます。
------
#### [ 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
<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:::assumed-role// is not authorized to perform: pcs:RegisterComputeNodeGroupInstance on resource: arn:aws:pcs:::cluster/ 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 のインスタンスプロファイルを作成する](getting-started_create-cng_instance-profile.md)。
### AWS PCS エンドポイントに接続できない
コンピューティングノードがプライベートサブネットにある場合は、PCS の VPC AWS エンドポイントが設定されているか、サブネットにインターネットアクセス用の NAT ゲートウェイへのルートがあることを確認してください。詳細については次を参照してください:
+ *Amazon Virtual Private Cloud AWS PrivateLink* ガイドの[インターフェイス VPC エンドポイントを使用して AWS サービスにアクセスします](https://docs.aws.amazon.com/vpc/latest/privatelink/create-interface-endpoint.html)。
+ [AWS PCS のエンドポイントとサービスクォータ](service-endpoints-quotas.md).
+ [「Amazon Virtual Private Cloud ユーザーガイド」の「VPC を他のネットワークに接続](https://docs.aws.amazon.com/vpc/latest/userguide/extend-intro.html)する*Amazon Virtual Private Cloud*」
+ [AWS PCS ネットワーク](working-with_networking.md)
### PCS AWS エンドポイントの設定ミス
次のようなエラーメッセージが表示された場合は、PCS VPC AWS エンドポイントに関連付けられているポリシーを確認します。
```
com.amazon.coral.security.AccessDeniedException: User: arn:aws:sts::xxx:assumed-role// is not authorized to perform: pcs:RegisterComputeNodeGroupInstance on resource: arn:aws:pcs:::cluster/ 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 を使用した へのアクセス](vpc-interface-endpoints.md)。
### パブリック 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 アドレス](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-instance-addressing.html#public-ip-addresses)を割り当てる」を参照してください。 *Amazon EC2 *
マルチ NIC インスタンスタイプでは、PCS エンドポイントにアクセスするために、サブネット内の NAT AWS ゲートウェイまたは内部プロキシが必要です。または、PCS AWS の VPC エンドポイントをクラスター VPC に追加することもできます。
### クラスターシークレットが削除されたか、削除対象としてマークされている
AWS Secrets Manager の Slurm 共有シークレットが削除された場合、または削除対象としてマークされている場合、コンピューティングノードは登録に失敗し、クラスターに障害が発生します。
AWS PCS は、クラスターの作成時に AWS Secrets Manager (名前形式: `pcs!slurm-secret-`) で Slurm 共有シークレットを自動的に作成します。このシークレットは、クラスター内の安全な通信に必要です。詳細については、「[PCS AWS でのクラスターシークレットの使用](working-with_clusters_secrets.md)」を参照してください。
このシークレットを削除または削除対象としてマークすると、新しいノードはクラスターに参加できず、再起動するとコントローラーやその他のクラスターデーモン ( `slurmd`や など`slurmdbd`) はクラスターに再参加できない可能性があります。
この問題を解決するには、削除されたシークレットがまだ復旧ウィンドウ内にある場合に復元できます。詳細な手順については、「[AWS Secrets Manager シークレットの復元](https://docs.aws.amazon.com/secretsmanager/latest/userguide/manage_restore-secret.html)」を参照してください。
復旧期間が終了すると、シークレットは復元できず、影響を受ける 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`
セキュリティグループの要件の詳細については、以下のトピックを参照してください。
+ [PCS AWS のセキュリティグループを作成する](getting-started_create-sg.md)
+ [PCS AWS の起動テンプレートを作成する](getting-started_create-cng_launch-templates.md)
+ [セキュリティグループの要件と考慮事項](working-with_networking_sg.md#working-with_networking_sg-requirements)
**重要**
クラスターの作成時にクラスターに関連付けたクラスターセキュリティグループは、コンピューティングノードがコントローラーと通信できるように、コンピューティングノードグループセキュリティグループでも設定する必要があります。
### 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 – (オプション) 追加のドライバー、ライブラリ、アプリケーションソフトウェアをインストールする](working-with_ami_custom_install-software.md)」を参照してください。
### 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)](working-with_ami_custom.md)」を参照してください。
### Slurmctld がコンピューティングノードに ping できない
インスタンスがブートストラッププロシージャを正しく実行し、PCS AWS に登録されているが、それを表示してジョブを送信`slurmctld`できない場合、インスタンスはしばらく`DOWN`してから に設定され、終了します。
これは、セキュリティグループの設定ミスが原因である可能性があります。たとえば、ポート 6817 で との`slurmd`通信が許可されているが`slurmctld`、ポート 6818 で `slurmctld` ping が許可されていない場合です`slurmd`。
「」で説明されているように、セキュリティグループにすべての必要なルールが含まれていることを確認します[セキュリティグループの要件と考慮事項](working-with_networking_sg.md#working-with_networking_sg-requirements)。