翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。
# AWS ParallelCluster トラブルシューティング
以下のセクションでは、 AWS ParallelClusterの使用中に発生する可能性がある問題のトラブルシューティングのヒントを示します。 AWS ParallelCluster コミュニティは、[AWS ParallelCluster GitHub Wiki で多くのトラブルシューティングのヒントを提供する Wiki](https://github.com/aws/aws-parallelcluster/wiki/) ページを保持しています。既知の問題のリストは、「[既知の問題](https://github.com/aws/aws-parallelcluster/wiki#known-issues-)」を参照してください。
**Topics**
+ [クラスターの作成を試行する](troubleshooting-fc-v3-create-cluster.md)
+ [ジョブの実行を試行する](troubleshooting-fc-v3-run-job.md)
+ [クラスターの更新を試行する](troubleshooting-fc-v3-update-cluster.md)
+ [ストレージへのアクセスを試行する](troubleshooting-fc-v3-access-storage.md)
+ [クラスターの削除を試行する](troubleshooting-fc-v3-delete-cluster.md)
+ [AWS ParallelCluster API スタックのアップグレードの試行](troubleshooting-fc-v3-upgrade-stack-v3.md)
+ [コンピューティンティングノードの初期化のエラーが表示されている](troubleshooting-fc-v3-compute-node-initialization-v3.md)
+ [クラスターヘルスメトリクスのトラブルシューティング](troubleshooting-v3-cluster-health-metrics.md)
+ [クラスターデプロイの問題のトラブルシューティング](troubleshooting-v3-cluster-deployment.md)
+ [Terraform を使用したクラスターのデプロイのトラブルシューティング](troubleshooting-v3-terraform.md)
+ [スケーリング問題のトラブルシューティング](troubleshooting-v3-scaling-issues.md)
+ [プレイスメントグループとインスタンスの起動に関する問題](troubleshooting-v3-placemment-groups.md)
+ [ディレクトリの置換](troubleshooting-v3-dirs-must-keep.md)
+ [Amazon DCV の問題のトラブルシューティング](troubleshooting-v3-nice-dcv.md)
+ [AWS Batch 統合によるクラスターの問題のトラブルシューティング](troubleshooting-v3-batch.md)
+ [Active Directory を使用したマルチユーザー統合のトラブルシューティング](troubleshooting-v3-multi-user.md)
+ [カスタム AMI の問題のトラブルシューティング](troubleshooting-v3-custom-amis.md)
+ [`cfn-hup` が実行していない場合のクラスター更新タイムアウトのトラブルシューティング](troubleshooting-v3-cluster-update-timeout.md)
+ [ネットワークのトラブルシューティング](troubleshooting-v3-networking.md)
+ [クラスターの更新が `onNodeUpdated` カスタムアクションで失敗した](troubleshooting-v3-on-node-updated.md)
+ [カスタム Slurm 設定でエラーが表示されている](troubleshooting-v3-custom-slurm-config.md)
+ [クラスターのアラーム](troubleshooting-v3-cluster-alarms.md)
+ [エラーや障害の原因となる OS 設定変更の解決](resolving-os-configuration-changes.md)
# クラスターの作成を試行する
AWS ParallelCluster バージョン 3.5.0 以降を使用してクラスターを作成し、 を `--rollback-on-failure`に設定してクラスターの作成が失敗した場合`false`、 [`pcluster describe-cluster`](pcluster.describe-cluster-v3.md) CLI コマンドを使用してステータスと障害情報を取得します。この場合、`pcluster describe-cluster` の `clusterStatus` の正常な出力は `CREATE_FAILED` です。出力の `failures` セクションを確認して、`failureCode` と `failureReason` を見つけます。次のセクションで一致する `failureCode` を探して、その他のトラブルシューティングについてのヘルプを見つけます。詳細については、「[`pcluster describe-cluster`](pcluster.describe-cluster-v3.md)」を参照してください。
次のセクションでは、`/var/log/cfn-init.log` や `/var/log/chef-client.log` ファイルなど、ヘッドノードのログを確認することをお勧めします。 AWS ParallelCluster ログとその表示方法の詳細については、[デバッグ用のキーログ](troubleshooting-v3-scaling-issues.md#troubleshooting-v3-key-logs)「」および「」を参照してください[ログの取得と保存](troubleshooting-v3-get-logs.md)。
がない場合は`failureCode`、 CloudFormation コンソールに移動してクラスタースタックを表示します。`HeadNodeWaitCondition` の `Status Reason`、または他のリソースの障害を確認して、失敗に関するその他の詳細を確認します。詳細については、「[で CloudFormation イベントを表示する `CREATE_FAILED`](troubleshooting-v3-cluster-deployment.md#troubleshooting-v3-cluster-deployment-events)」を参照してください。ヘッドノードの `/var/log/cfn-init.log` および `/var/log/chef-client.log` ファイルを確認します。ヘッドノードの作成に失敗したためにクラスターの作成に失敗し、クラスターログがクラスターロググループで利用できない場合は、クラスターを失敗時に保持し、`--rollback-on-failure`= を指定`True`して、ヘッドノード自体内からログを取得する必要があります。
## `failureCode` が `OnNodeConfiguredExecutionFailure`
+ **失敗した原因**
クラスターを作成するために、設定のヘッドノードセクションの `OnNodeConfigured` にカスタムスクリプトを指定しました。しかし、カスタムスクリプトの実行に失敗しました。
+ **解決方法**
`/var/log/cfn-init.log` ファイルを確認して、障害の詳細とカスタムスクリプトの問題の修正方法を確認します。このログの最後の方で、`Running command runpostinstall` メッセージの後に `OnNodeConfigured` スクリプトに関連する実行情報が表示される場合があります。
## `failureCode` が `OnNodeConfiguredDownloadFailure`
+ **失敗した原因**
クラスターを作成するために、設定のヘッドノードセクションの `OnNodeConfigured` にカスタムスクリプトを指定しました。しかし、カスタムスクリプトのダウンロードに失敗しました。
+ **解決方法**
URL が有効で、アクセスが正しく設定されていることを確認します。カスタムブートストラップスクリプトの設定に関する詳細については、「[カスタムブートストラップアクション](custom-bootstrap-actions-v3.md)」を参照してください。
`/var/log/cfn-init.log` ファイルを確認してください。このログの最後の方で、`Running command runpostinstall` メッセージの後に、ダウンロードを含め `OnNodeConfigured` スクリプトの処理に関連する実行情報が表示される場合があります。
## `failureCode` が `OnNodeConfiguredFailure`
+ **失敗した原因**
クラスターを作成するために、設定のヘッドノードセクションの `OnNodeConfigured` にカスタムスクリプトを指定しました。ただし、クラスターのデプロイにおいてカスタムスクリプトの使用に失敗しました。即時に原因を判断できないため、追加の調査が必要です。
+ **解決方法**
`/var/log/cfn-init.log` ファイルを確認してください。このログの最後の方で、`Running command runpostinstall` メッセージの後に `OnNodeConfigured` スクリプトの処理に関連する実行情報が表示される場合があります。
## `failureCode` が `OnNodeStartExecutionFailure`
+ **失敗した原因**
クラスターを作成するために、設定のヘッドノードセクションの `OnNodeStart` にカスタムスクリプトを指定しました。しかし、カスタムスクリプトの実行に失敗しました。
+ **解決方法**
`/var/log/cfn-init.log` ファイルを確認して、障害の詳細とカスタムスクリプトの問題の修正方法を確認します。このログの最後の方で、`Running command runpreinstall` メッセージの後に `OnNodeStart` スクリプトに関連する実行情報が表示される場合があります。
## `failureCode` が `OnNodeStartDownloadFailure`
+ **失敗した原因**
クラスターを作成するために、設定のヘッドノードセクションの `OnNodeStart` にカスタムスクリプトを指定しました。しかし、カスタムスクリプトのダウンロードに失敗しました。
+ **解決方法**
URL が有効で、アクセスが正しく設定されていることを確認します。カスタムブートストラップスクリプトの設定に関する詳細については、「[カスタムブートストラップアクション](custom-bootstrap-actions-v3.md)」を参照してください。
`/var/log/cfn-init.log` ファイルを確認してください。このログの最後の方で、`Running command runpreinstall` メッセージの後に、ダウンロードを含め `OnNodeStart` スクリプトの処理に関連する実行情報が表示される場合があります。
## `failureCode` が `OnNodeStartFailure`
+ **失敗した原因**
クラスターを作成するために、設定のヘッドノードセクションの `OnNodeStart` にカスタムスクリプトを指定しました。ただし、クラスターのデプロイにおいてカスタムスクリプトの使用に失敗しました。即時に原因を判断できないため、追加の調査が必要です。
+ **解決方法**
`/var/log/cfn-init.log` ファイルを確認してください。このログの最後の方で、`Running command runpreinstall` メッセージの後に `OnNodeStart` スクリプトの処理に関連する実行情報が表示される場合があります。
## `failureCode` が `EbsMountFailure`
+ **失敗した原因**
クラスター設定で定義されている EBS ボリュームのマウントに失敗しました。
+ **解決方法**
失敗の詳細について、`/var/log/chef-client.log` ファイルを確認します。
## `failureCode` が `EfsMountFailure`
+ **失敗した原因**
クラスター設定で定義されている Amazon EFS ボリュームのマウントに失敗しました。
+ **解決方法**
既存の Amazon EFS ファイルシステムを定義した場合は、クラスターとファイルシステムの間のトラフィックが許可されていることを確認します。詳細については、「[`SharedStorage`](SharedStorage-v3.md)」/「[`EfsSettings`](SharedStorage-v3.md#SharedStorage-v3-EfsSettings)」/「[`FileSystemId`](SharedStorage-v3.md#yaml-SharedStorage-EfsSettings-FileSystemId)」を参照してください。
失敗の詳細について、`/var/log/chef-client.log` ファイルを確認します。
## `failureCode` が `FsxMountFailure`
+ **失敗した原因**
クラスター設定で定義されている Amazon FSx ファイルシステムのマウントに失敗しました。
+ **解決方法**
既存の Amazon FSx ファイルシステムを定義した場合は、クラスターとファイルシステムの間のトラフィックが許可されていることを確認します。詳細については、「[`SharedStorage`](SharedStorage-v3.md)」/「[`FsxLustreSettings`](SharedStorage-v3.md#SharedStorage-v3-FsxLustreSettings)」/「[`FileSystemId`](SharedStorage-v3.md#yaml-SharedStorage-FsxLustreSettings-FileSystemId)」を参照してください。
失敗の詳細について、`/var/log/chef-client.log` ファイルを確認します。
## `failureCode` が `RaidMountFailure`
+ **失敗した原因**
クラスター設定で定義されている RAID ボリュームのマウントに失敗しました。
+ **解決方法**
失敗の詳細について、`/var/log/chef-client.log` ファイルを確認します。
## `failureCode` が `AmiVersionMismatch`
+ **失敗した原因**
カスタム AMI の作成に使用される AWS ParallelCluster バージョンは、クラスターの設定に使用される AWS ParallelCluster バージョンとは異なります。CloudFormation コンソールで、クラスターの CloudFormation スタックの詳細を表示し、 `Status Reason`で AWS ParallelCluster バージョンと AMI `HeadNodeWaitCondition`の詳細を確認します。詳細については、「[で CloudFormation イベントを表示する `CREATE_FAILED`](troubleshooting-v3-cluster-deployment.md#troubleshooting-v3-cluster-deployment-events)」を参照してください。
+ **解決方法**
カスタム AMI の作成に使用した AWS ParallelCluster バージョンが、クラスターの設定に使用した AWS ParallelCluster バージョンと同じであることを確認します。カスタム AMI のバージョン、または `pcluster` CLI のバージョンのいずれかを変更して同じにすることができます。
## `failureCode` が `InvalidAmi`
+ **失敗した原因**
カスタム AMI は、 を使用して構築されていないため無効です AWS ParallelCluster。
+ **解決方法**
`pcluster build-image` コマンドを使用し、独自の AMI を親イメージにして AMI を作成します。詳細については、「[`pcluster build-image`](pcluster.build-image-v3.md)」を参照してください。
## `failureCode` が `HeadNodeBootstrapFailure` と `failureReason` で、ヘッドノードの設定に失敗した。
+ **失敗した原因**
即時に原因を判断できないため、追加の調査が必要です。例えば、クラスターが保護ステータスにある場合や、静的コンピューティングフリートのプロビジョニングの失敗により発生した可能性があります。
+ **解決方法**
失敗の詳細について、`/var/log/chef-client.log.` ファイルを確認します。
**注記**
`RuntimeError` 例外 `Cluster state has been set to PROTECTED mode due to failures detected in static node provisioning` が表示された場合、クラスターは保護ステータスにあります。詳細については、「[保護モードをデバッグする方法](slurm-protected-mode-v3.md#slurm-protected-mode-debug-v3)」を参照してください。
## `failureCode` は `HeadNodeBootstrapFailure` で、`failureReason` クラスター作成がタイムアウトした。
+ **失敗した原因**
デフォルトでは、クラスターの作成が完了するのに 30 分の時間制限があります。このタイムフレーム内でクラスターの作成が完了しない場合、クラスターの作成はタイムアウトエラーで失敗します。クラスターの作成は、さまざまな理由でタイムアウトになる可能性があります。例えば、タイムアウトによる失敗は、ヘッドノード作成の失敗、ネットワークの問題、ヘッドノードでの実行に時間がかかりすぎるカスタムスクリプト、コンピューティングノードで実行されるカスタムスクリプトのエラー、またはコンピューティングノードのプロビジョニングの待ち時間が長いことにより発生する可能性があります。即時に原因を判断できないため、追加の調査が必要です。
+ **解決方法**
失敗の詳細について、`/var/log/cfn-init.log` と `/var/log/chef-client.log` ファイルを確認します。 AWS ParallelCluster ログとその取得方法に関する詳細については、「[デバッグ用のキーログ](troubleshooting-v3-scaling-issues.md#troubleshooting-v3-key-logs)」と「[ログの取得と保存](troubleshooting-v3-get-logs.md)」を参照してください。
これらのログで、次のことが見つかることがあります。
+ **`chef-client.log` の最後の方にある `Waiting for static fleet capacity provisioning` が表示されている**
これは、静的ノードの電源が入るのを待機しているときにクラスターの作成がタイムアウトしたことを示しています。詳細については、「[コンピューティンティングノードの初期化のエラーが表示されている](troubleshooting-fc-v3-compute-node-initialization-v3.md)」を参照してください。
+ **`OnNodeConfigured` または `OnNodeStart` ヘッドノードスクリプトが `cfn-init.log` の最後で終了していないことが表示されている**
これは、`OnNodeConfigured` または `OnNodeStart` で、カスタムスクリプトの実行に時間がかかり、タイムアウトエラーが発生したことを示しています。カスタムスクリプトに、実行に長い時間がかかる問題がないか確認します。カスタムスクリプトの実行に長い時間が必要な場合は、次の例に示されているようにクラスター設定ファイルに `DevSettings` セクションを追加してタイムアウト制限を変更することを考慮してください。
```
DevSettings:
Timeouts:
HeadNodeBootstrapTimeout: 1800 # default setting: 1800 seconds
```
+ **ログが見つからない、またはヘッドノードが正常に作成されない**
ヘッドノードが正常に作成されず、ログが見つからない可能性があります。この場合、CloudFormation スタックイベントとヘッドノードコンソールログを確認することで、追加の障害の詳細を取得できます。ヘッドノードコンソールログを取得するには、Amazon EC2 コンソールを使用するか、次の Amazon EC2 CLI コマンドを実行します。
```
aws ec2 get-console-output --instance-id HEAD_NODE_INSTANCE_ID --output text
```
## `failureCode` は `HeadNodeBootstrapFailure` で、`failureReason` はヘッドノードのブートストラップに失敗した。
+ **失敗した原因**
即時に原因を判断できないため、追加の調査が必要です。
+ **解決方法**
`/var/log/cfn-init.log` と `/var/log/chef-client.log` のファイルを確認します。
## `failureCode` が `ResourceCreationFailure`
+ **失敗した原因**
クラスター作成プロセス中に、一部のリソースの作成に失敗しました。さまざまな理由で失敗が発生します。例えば、リソース作成の失敗は、容量の問題や IAM ポリシーが誤って設定されていることにより発生することがあります。
+ **解決方法**
CloudFormation コンソールでクラスタースタックを表示して、リソース作成の失敗に関するその他の詳細を確認します。
## `failureCode` が `ClusterCreationFailure`
+ **失敗した原因**
即時に原因を判断できないため、追加の調査が必要です。
+ **解決方法**
CloudFormation コンソールでクラスタースタックを表示し、`HeadNodeWaitCondition` の `Status Reason` を確認して、失敗に関するその他の詳細を見つけます。
`/var/log/cfn-init.log` と `/var/log/chef-client.log` のファイルを確認します。
## CloudFormation スタックの `WaitCondition timed out...` が表示されている
詳細については、「[`failureCode` は `HeadNodeBootstrapFailure` で、`failureReason` クラスター作成がタイムアウトした。](#create-cluster-head-node-bootstrap-timeout-failure-v3)」を参照してください。
## CloudFormation スタックの `Resource creation cancelled` が表示されている
詳細については、「[`failureCode` が `ResourceCreationFailure`](#create-cluster-resource-creation-failure-v3)」を参照してください。
## CloudFormation スタック内の表示`Failed to run cfn-init...`またはその他のエラー
失敗に関するその他の詳細について、`/var/log/cfn-init.log` と `/var/log/chef-client.log` を確認します。
## `INFO: Waiting for static fleet capacity provisioning` の最後に `chef-client.log` が表示されている
これは、静的ノードの電源が入るのを待機しているときにクラスターの作成がタイムアウトになることと関係しています。詳細については、「[コンピューティンティングノードの初期化のエラーが表示されている](troubleshooting-fc-v3-compute-node-initialization-v3.md)」を参照してください。
## `Failed to run preinstall or postinstall in cfn-init.log` が表示されている
クラスター設定 の `HeadNode` セクションに `OnNodeConfigured` または `OnNodeStart` スクリプトがあります。このスクリプトが正しく動作していません。カスタムスクリプトのエラーの詳細について、`/var/log/cfn-init.log` ファイルを確認します。
## CloudFormation スタックの `This AMI was created with xxx, but is trying to be used with xxx...` が表示されている
詳細については、「[`failureCode` が `AmiVersionMismatch`](#create-cluster-ami-version-mismatch-v3)」を参照してください。
## CloudFormation スタックの `This AMI was not baked by AWS ParallelCluster...` が表示されている
詳細については、「[`failureCode` が `InvalidAmi`](#create-cluster-invalid-ami-v3)」を参照してください。
## `pcluster create-cluster` コマンドがローカルで実行できないことが表示されている
失敗の詳細について、ローカルファイルシステムの `~/.parallelcluster/pcluster-cli.log` を確認します。
## 追加のサポート
[クラスターデプロイの問題のトラブルシューティング](troubleshooting-v3-cluster-deployment.md) のトラブルシューティングガイダンスに従ってください。
シナリオが [GitHub の にある GitHub の既知の問題](https://github.com/aws/aws-parallelcluster/wiki) AWS ParallelCluster でカバーされているかどうかを確認します。 GitHub
# ジョブの実行を試行する
次のセクションでは、ジョブを実行しようとして問題が発生した場合に役立つトラブルシューティングソリューションを示します。
## `srun` のインタラクティブなジョブがエラー `srun: error: fwd_tree_thread: can't find address for , check slurm.conf` で失敗する
+ **失敗した原因**
`srun` コマンドを実行してジョブを送信し、更新が完了した後、Slurm デーモンを再起動せずに `pcluster update-cluster` コマンドを使用してキューサイズを増やしました。
Slurm は、Slurm デーモンをツリー階層に整理して通信を最適化します。この階層は、デーモンが開始するときにのみ更新されます。
`srun` を使用してジョブを起動し、`pcluster update-cluster` コマンドを実行してキューサイズを増やすとします。新しいコンピューティングノードは、更新の一環として起動します。次に、Slurm は、新しいコンピューティングノードの 1 つに、ジョブをキューに入れます。この場合、Slurm デーモンと `srun` の両方は新しいコンピューティングノードを検出しません。`srun` は新しいノードを検出しないため、エラーを返します。
+ **解決方法**
すべてのコンピューティングノードで Slurm デーモンを再起動し、`srun` を使用してジョブを送信します。コンピューティングノードを再起動する `scontrol reboot` コマンドを実行することにより、Slurm デーモンの再起動をスケジュールできます。詳細については、「Slurm ドキュメント」の「[scontrol reboot](https://slurm.schedmd.com/scontrol.html#OPT_reboot)」を参照してください。また、対応する `systemd` サービスの再起動をリクエストすることにより、コンピューティングノードで Slurm デーモンを手動で再起動することもできます。
## ジョブが `squeue` コマンドで、`CF` 状態でスタックしている
これは、動的ノードの電源を入れる時の問題である可能性があります。詳細については、「[コンピューティンティングノードの初期化のエラーが表示されている](troubleshooting-fc-v3-compute-node-initialization-v3.md)」を参照してください。
## 大規模なジョブを実行し、`nfsd: too many open connections, consider increasing the number of threads in /var/log/messages` が表示されている
ネットワークに接続されたファイルシステムでは、ネットワークの制限に到達すると、I/O の待機時間も増加します。ネットワークと I/O メトリクスの両方のデータを書き込むのにネットワークが使用されるため、これによりソフトロックアップになることがあります。
第 5 世代のインスタンスでは、ENA ドライバーを使用してパケットカウンターを公開します。これらのカウンターは、ネットワークがインスタンス帯域幅制限に達した AWS ときに によって形成されたパケットをカウントします。これらのカウンターを確認して 0 より大きいかどうかを確認できます。その場合、帯域幅制限を超えていることになります。`ethtool -S eth0 | grep exceeded` を実行するとこれらのカウンターが表示されます。
サポートする NFS 接続が多すぎると、多くの場合、ネットワーク制限を超えます。これは、ネットワークの制限に到達したり、それを超えたりしたときに最初に確認することの 1 つです。
例えば、次の出力にドロップされたパッケージを示します。
```
$ ethtool -S eth0 | grep exceeded
bw_in_allowance_exceeded: 38750610
bw_out_allowance_exceeded: 1165693
pps_allowance_exceeded: 103
conntrack_allowance_exceeded: 0
linklocal_allowance_exceeded: 0
```
このメッセージの表示を回避するには、ヘッドノードのインスタンスタイプをよりパフォーマンスの高いインスタンスタイプに変更することを検討します。データストレージを、Amazon EFS や Amazon FSx などの NFS 共有としてエクスポートされていない共有ストレージファイルシステムに移行することを検討します。詳細については、[共有ストレージ](shared-storage-quotas-integration-v3.md)「」および GitHub の AWS ParallelCluster Wiki の[「ベストプラクティス](https://github.com/aws/aws-parallelcluster/wiki/Best-Practices)」を参照してください。
## MPI ジョブを実行する
### デバッグモードを有効にする
OpenMPI デバッグモードを有効にするには、「[What controls does Open MPI have that aid in debugging](https://www-lb.open-mpi.org/faq/?category=debugging#debug-ompi-controls)」を参照してください。
IntelMPI デバッグモードを有効にするには、「[Other Environment Variables](https://www.intel.com/content/www/us/en/develop/documentation/mpi-developer-reference-linux/top/environment-variable-reference/other-environment-variables.html)」を参照してください。
### ジョブ出力の `MPI_ERRORS_ARE_FATAL` と `OPAL ERROR` が表示されている
これらのエラーコードはアプリケーションの MPI レイヤーから発生します。アプリケーションから MPI デバッグログを取得する方法については、「[デバッグモードを有効にする](#run-job-mpi-enable-v3)」を参照してください。
このエラーの考えられる原因として、アプリケーションが OpenMPI などの特定の MPI 実装用にコンパイルされており、IntelMPI などの別の MPI 実装で実行しようとしていることがあります。アプリケーションのコンパイルと実行の両方で、同じ MPI 実装を使用していることを確認します。
### マネージド DNS を無効にして `mpirun` を使用する
[SlurmSettings](Scheduling-v3.md#Scheduling-v3-SlurmSettings)/[Dns](Scheduling-v3.md#Scheduling-v3-SlurmSettings-Dns)/[DisableManagedDns](Scheduling-v3.md#yaml-Scheduling-SlurmSettings-Dns-DisableManagedDns) および [UseEc2Hostnames](Scheduling-v3.md#yaml-Scheduling-SlurmSettings-Dns-UseEc2Hostnames) を `true` に設定して作成されたクラスターの場合、Slurm ノード名は DNS によって解決されません。Slurm は、MPI ジョブが Slurm コンテキストで実行されていて、`nodenames` が有効になっていないとき、MPI プロセスをブートストラップできます。「[Slurm MPI User's Guide](https://slurm.schedmd.com/mpi_guide.html)」のガイダンスに従い、Slurm を使用して MPI ジョブを実行することをお勧めします。
# クラスターの更新を試行する
次のセクションでは、クラスターを更新しようとして問題が発生した場合に役立つトラブルシューティングソリューションを示します。
## `pcluster update-cluster` コマンドのローカル実行に失敗する
失敗の詳細について、ローカルファイルシステムの `~/.parallelcluster/pcluster-cli.log` を確認します。
## `pcluster describe-cluster` コマンドで `clusterStatus` が `UPDATE_FAILED` であることが表示されている
### ルートの原因
失敗の根本原因を特定するには、まずヘッドノード`/var/log/chef-client.log`のクラスタースタックイベントと を確認します。
考えられる原因は、少なくとも 1 つのクラスターノードが更新を適用しなかったことです。ヘッドノード`/var/log/chef-client.log`で の更新に失敗したノードのリストを取得するには、 ログ`Check cluster readiness`で を探します。
問題が [GitHub の にある GitHub の既知の問題](https://github.com/aws/aws-parallelcluster/wiki) AWS ParallelCluster に記載されているかどうかを確認します。 GitHub
### の防止
クラスター内の少なくとも 1 つのノードが更新を正常に適用しなかった場合、クラスターの更新が失敗する可能性があります。クラスターの更新に失敗するリスクを軽減するために、更新を開始する前に壊れたノードを終了することをお勧めします。ノードが壊れる可能性がある例として、予想されるエピックログ期間よりも長い間、コンピューティングノードが `COMPLETING`状態のままになることがあります。これらのノードを検出するには、次のコマンドを実行し、`threshold`値をニーズに合わせて調整します (値は、エピックログに予想される最大期間より大きくなければなりません）。
```
$ scontrol show nodes --json | jq -r --argjson threshold 60 '
.nodes[] | select(.state | index("COMPLETING")) |
select((now - .last_busy.number) > $threshold) |
.name
'
```
### 復旧
更新が失敗した場合、ロールバックはクラスターの状態を回復することが予想されるメカニズムです。
ロールバックが失敗した場合、クラスターの状態は決定的ではありません。この場合、障害の増幅を防ぐために停止`clustermgtd`した可能性があります。ヘッドノードで次のコマンドを実行して開始することをお勧めします。Python バージョンを、お使いのバージョンに同梱されている AWS ParallelCluster バージョンに適応させます。
```
$ /opt/parallelcluster/pyenv/versions/3.12.11/envs/cookbook_virtualenv/bin/supervisorctl start clustermgtd
```
## クラスターの更新がタイムアウトになる
これは `cfn-hup` が実行されていないことに関連する問題の可能性があります。`cfn-hup` デーモンが外部の原因により終了させられる場合、自動的に再開されることはありません。`cfn-hup` が実行されていない場合、クラスターの更新中に CloudFormation スタックは期待どおりに更新プロセスを開始しますが、更新手順はヘッドノードでアクティブ化されず、最終的にスタックのデプロイはタイムアウトになります。詳細については、「[`cfn-hup` が実行していない場合のクラスター更新タイムアウトのトラブルシューティング](troubleshooting-v3-cluster-update-timeout.md)」を参照してトラブルシューティングと問題からの復旧を行ってください。
# ストレージへのアクセスを試行する
ストレージにアクセスする際のトラブルシューティングのヒントについて説明します。
## 外部の Amazon FSx for Lustre ファイルシステムを使用する
クラスターとファイルシステム間のトラフィックが許可されていることを確認します。ファイルシステムは、ポート 988、1021、1022、および 1023 経由のインバウンドおよびアウトバウンドの TCP トラフィックを許可するセキュリティグループに関連付けられている必要があります。セキュリティグループの設定方法の詳細については、「[FileSystemId](SharedStorage-v3.md#yaml-SharedStorage-FsxLustreSettings-FileSystemId)」を参照してください。
## 外部の Amazon Elastic File System ファイルシステムを使用する
クラスターとファイルシステム間のトラフィックが許可されていることを確認します。ファイルシステムは、ポート 988、1021、1022、および 1023 経由のインバウンドおよびアウトバウンドの TCP トラフィックを許可するセキュリティグループに関連付けられている必要があります。セキュリティグループの設定方法の詳細については、「[FileSystemId](SharedStorage-v3.md#yaml-SharedStorage-EfsSettings-FileSystemId)」を参照してください。
# クラスターの削除を試行する
以下のセクションでは、クラスターを削除しようとしてエラーが発生した場合の一般的なシナリオのトラブルシューティングのヒントを示します。
## `pcluster delete-cluster` コマンドのローカル実行に失敗する
ローカルファイルシステムの `~/.parallelcluster/pcluster-cli.log` ファイルを確認します。
## クラスタースタックが削除に失敗する
クラスタースタックが削除に失敗する場合、CloudFormation スタックイベントのメッセージを確認します。
問題が GitHub の AWS ParallelCluster の「[GitHub Known Issues](https://github.com/aws/aws-parallelcluster/wiki)」に記載されているか、確認します。
# AWS ParallelCluster API スタックのアップグレードの試行
AWS ParallelCluster API スタックをアップグレードしようとして `UPDATE_FAILED` などのエラーが発生した場合は、GitHub の [AWS ParallelCluster Wiki](https://github.com/aws/aws-parallelcluster/wiki) の「**Known Issues**」セクションで解決策を確認することをお勧めします。例えば、「[ParallelCluster API Stack Upgrade Fails for ECR resources](https://github.com/aws/aws-parallelcluster/wiki/(3.0.0-3.1.4)-ParallelCluster-API-Stack-Upgrade-Fails-for-ECR-resources)」を参照してください。これは、考えられる 1 つの問題を特定し、緩和オプションを提供します。
# コンピューティンティングノードの初期化のエラーが表示されている
以下のセクションでは、コンピューティングノードの初期化中にエラーが発生した場合のトラブルシューティングのヒントを提供します。これには、ブートストラップエラー、ログでのエラーの確認、特定の状況に当てはまるシナリオがない場合の問い合わせ先が含まれます。
**Topics**
+ [`clustermgtd.log` に `Node bootstrap error` が表示されている](compute-node-initialization-bootstrap-error-v3.md)
+ [オンデマンドキャパシティ予約 (ODCR) またはゾーンレベルのリザーブドインスタンスを設定しました。](compute-node-initialization-odcr-v3.md)
+ [ジョブの実行に失敗したとき `slurm_resume.log` で、またはクラスターの作成に失敗したとき `clustermgtd.log` で `An error occurred (VcpuLimitExceeded)` が表示されている](compute-node-initialization-vpc-limit-v3.md)
+ [ジョブの実行に失敗したとき `slurm_resume.log` で、またはクラスターの作成に失敗したとき `clustermgtd.log` で `An error occurred (InsufficientInstanceCapacity)` が表示されている](compute-node-initialization-ice-failure-v3.md)
+ [ノードが `Reason (Code:InsufficientInstanceCapacity)...` と共に `DOWN` ステータスで表示されている](compute-node-initialization-down-nodes-v3.md)
+ [`slurm_resume.log` に `cannot change locale (en_US.utf-8) because it has an invalid name` が表示されている](compute-node-initialization-locale-v3.md)
+ [前のシナリオはどれも私の状況には当てはまりません。](compute-node-initialization-not-found-v3.md)
# `clustermgtd.log` に `Node bootstrap error` が表示されている
この問題は、コンピューティンティングノードがブートストラップで失敗していることに関連しています。クラスター保護モードの問題をデバッグする方法の詳細については、「[保護モードをデバッグする方法](slurm-protected-mode-v3.md#slurm-protected-mode-debug-v3)」を参照してください。
# オンデマンドキャパシティ予約 (ODCR) またはゾーンレベルのリザーブドインスタンスを設定しました。
## P4d, P4deT AWS rainium (Trn) など、複数のネットワークインターフェイスを持つインスタンスを含む ODCRs
クラスター設定ファイルで、`HeadNode` がパブリックサブネットにあり、コンピューティングノードがプライベートサブネットにあることを確認します。
## ODCR が ターゲット ODCRS
### [オンデマンドキャパシティ予約 (ODCR) を使用してインスタンスを起動する](launch-instances-odcr-v3.md) の指示に従って既に `/opt/slurm/etc/pcluster/run_instances_overrides.json` を配置したのに `Unable to read file '/opt/slurm/etc/pcluster/run_instances_overrides.json'.` が表示されている
ターゲット ODCRs で AWS ParallelCluster バージョン 3.1.1 から 3.2.1 を使用していて、[実行インスタンスも JSON ファイルを上書き](launch-instances-odcr-v3.md)する場合、JSON ファイルが正しくフォーマットされていない可能性があります。`clustermgtd.log` で次のようなエラーが表示されることがあります。
```
Unable to read file '/opt/slurm/etc/pcluster/run_instances_overrides.json'.
Using default: {} in /var/log/parallelcluster/clustermgtd.
```
次を実行して、JSON ファイル形式が正しいことを確認します。
```
$ echo /opt/slurm/etc/pcluster/run_instances_overrides.json | jq
```
### クラスターの作成に失敗したときは `clustermgtd.log` で、またはジョブの実行に失敗したときは `slurm_resume.log` で `Found RunInstances parameters override.` が表示されている
[JSON ファイルをオーバーライドしてインスタンスを実行する](launch-instances-odcr-v3.md)を使用している場合は、`/opt/slurm/etc/pcluster/run_instances_overrides.json` ファイルでキュー名とコンピューティングリソース名を正しく設定していることを確認します。
### ジョブの実行に失敗したとき `slurm_resume.log` で、またはクラスターの作成に失敗したとき `clustermgtd.log` で `An error occurred (InsufficientInstanceCapacity)` が表示されている
#### PG-ODCR (プレイスメントグループ ODCR) を使用する
関連するプレイスメントグループを使用して ODCR を作成する場合、設定ファイルでは同じプレイスメントグループ名を使用する必要があります。クラスター設定で対応する[プレイスメントグループ名](Scheduling-v3.md#yaml-Scheduling-SlurmQueues-Networking-PlacementGroup)を設定します。
#### ゾーンレベルのリザーブドインスタンスを使用する
クラスター設定で `PlacementGroup`/`Enabled` を `true` としてゾーンレベルのリザーブドインスタンスを使用している場合、次のようなエラーが表示されることがあります。
```
We currently do not have sufficient trn1.32xlarge capacity in the Availability Zone you requested (us-east-1d). Our system will be working on provisioning additional capacity.
You can currently get trn1.32xlarge capacity by not specifying an Availability Zone in your request or choosing us-east-1a, us-east-1b, us-east-1c, us-east-1e, us-east-1f.
```
これは、ゾーンレベルのリザーブドインスタンスが同じ UC (またはスパイン) に配置されていないために発生することがあります。プレイスメントグループを使用しているときに、容量不足エラー (ICE) が発生することがあります。クラスター設定の `PlacementGroup` グループ設定を無効にして、クラスターがインスタンスを割り当てることができるかどうかを判断することにより、このケースについて確認できます。
# ジョブの実行に失敗したとき `slurm_resume.log` で、またはクラスターの作成に失敗したとき `clustermgtd.log` で `An error occurred (VcpuLimitExceeded)` が表示されている
使用している特定の EC2 インスタンスタイプについて、アカウントの vCPU 制限を確認します。vCPU の数がゼロまたはリクエストしている数より少ない場合は、制限の引き上げをリクエストします。現在の制限を確認する方法と新しい制限をリクエストする方法については、「*Amazon EC2 ユーザーガイド*」の「[Amazon EC2 のサービスクォータ](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-resource-limits.html)」を参照してください。
# ジョブの実行に失敗したとき `slurm_resume.log` で、またはクラスターの作成に失敗したとき `clustermgtd.log` で `An error occurred (InsufficientInstanceCapacity)` が表示されている
容量不足の問題が発生しています。[https://aws.amazon.com/premiumsupport/knowledge-center/ec2-insufficient-capacity-errors/](https://aws.amazon.com/premiumsupport/knowledge-center/ec2-insufficient-capacity-errors/) に従って問題をトラブルシューティングします。
# ノードが `Reason (Code:InsufficientInstanceCapacity)...` と共に `DOWN` ステータスで表示されている
容量不足の問題が発生しています。[https://aws.amazon.com/premiumsupport/knowledge-center/ec2-insufficient-capacity-errors/](https://aws.amazon.com/premiumsupport/knowledge-center/ec2-insufficient-capacity-errors/) に従って問題をトラブルシューティングします。容量不足 AWS ParallelClusterの高速フェイルオーバーモードの詳細については、「」を参照してください[Slurm クラスタ高速容量不足フェイルオーバー](slurm-short-capacity-fail-mode-v3.md)。
# `slurm_resume.log` に `cannot change locale (en_US.utf-8) because it has an invalid name` が表示されている
これは、`yum` のインストールプロセスで失敗してロケール設定に一貫性がない状態のままになっている場合に発生することがあります。例えば、これはユーザーがインストールプロセスを終了したときに発生することがあります。
**原因を確認するには、次のアクションを実行します。**
+ `su - pcluster-admin` を実行します。
シェルに、`cannot change locale...no such file or directory` などのエラーが表示されます。
+ `localedef --list` を実行します。
空のリストを返すか、デフォルトロケールを含んでいません。
+ 最後の `yum` コマンドおよび `yum history` と `yum history info #ID` を確認します。最後の ID に `Return-Code: Success` が含まれていますか。
最後の ID に `Return-Code: Success` が含まれていない場合、インストール後のスクリプトが正常に実行されていない可能性があります。
問題を解決するには、`yum reinstall glibc-all-langpacks` を使用してロケールを再構築してください。再構築後、問題が修正されているなら `su - pcluster-admin` でエラーや警告は表示されません。
# 前のシナリオはどれも私の状況には当てはまりません。
コンピューティングノードの初期化の問題のトラブルシューティングについては、「[ノードの初期化に関する問題のトラブルシューティング](troubleshooting-v3-scaling-issues.md#troubleshooting-v3-node-init)」を参照してください。
シナリオが [GitHub の にある GitHub の既知の問題](https://github.com/aws/aws-parallelcluster/wiki) AWS ParallelCluster でカバーされているかどうかを確認します。 GitHub
# クラスターヘルスメトリクスのトラブルシューティング
クラスターのヘルスメトリクスは、 AWS ParallelCluster バージョン 3.6.0 から AWS ParallelCluster Amazon CloudWatch ダッシュボードに追加されます。以降のセクションで、ダッシュボードヘルスメトリクスと、問題のトラブルシューティングと解決のために実行できるアクションについて説明します。
**Topics**
+ [**インスタンスプロビジョニングエラー**グラフが表示されている](#troubleshooting-v3-cluster-health-metrics-instance-provisioning)
+ [「**異常なインスタンスエラー**」グラフが表示されている](#troubleshooting-v3-cluster-health-metrics-unhealthy-instance)
+ [**コンピューティングフリートのアイドル時間**グラフが表示されている](#troubleshooting-v3-cluster-health-metrics-idle-time-errors)
## **インスタンスプロビジョニングエラー**グラフが表示されている
`Instance Provisioning Errors` グラフに 0 以外の値が表示される場合は、Slurm ノードをバッキングする Amazon EC2 インスタンスが `CreateFleet` または `RunInstance` API で起動できなかったことを示しています。
### `IAMPolicyErrors` が表示されている
+ **何が起きたのか。**
多数のインスタンスが起動できませんでした。これは、権限が不十分であることが原因であり、エラーコード `UnauthorizedOperation` が出ています。
+ **解決方法**
カスタム [`InstanceRole`](HeadNode-v3.md#yaml-HeadNode-Iam-InstanceRole) または [`InstanceProfile`](HeadNode-v3.md#yaml-HeadNode-Iam-InstanceProfile) を設定している場合は、IAM ポリシーを調べて、正しい認証情報を使用していることを確認してください。
`clustermgtd` ファイルにスタティックノードのエラーの詳細がないか確認してください。動的ノードエラーの詳細については `slurm_resume.log` ファイルを確認してください。詳細を参照して、追加する必要のある不足している権限について詳しく調べてください。
### `VcpuLimitErrors` が表示されている
+ **何が起きたのか。**
AWS ParallelCluster は、クラスターコンピューティングノード用に設定した AWS アカウント 特定の Amazon EC2 インスタンスタイプの の vCPU 制限に達したため、インスタンスを起動できませんでした。
+ **解決方法**
静的ノードの場合は `clustermgtd` ファイルに `VcpuLimitExceeded` エラーがないか確認し、動的ノードの場合は `slurm_resume.log` ファイルで詳細を確認してください。この問題を解決するため、vCPU 制限の引き上げをリクエストできます。現在の制限を確認する方法と新しい制限をリクエストする方法の詳細については、「*Linux インスタンス用 Amazon Amazon Elastic Compute Cloud ユーザーガイド*」の「[Amazon Elastic Compute Cloud のサービスクォータ](https://docs.aws.amazon.com//AWSEC2/latest/UserGuide/ec2-resource-limits.html)」を参照してください。
### `VolumeLimitErrors` が表示されている
+ **何が起きたのか。**
で Amazon EBS ボリュームの制限に達しており AWS アカウント、エラーコード AWS ParallelCluster `InsufficientVolumeCapacity`または でインスタンスを起動できません`VolumeLimitExceeded`。
+ **解決方法**
静的ノードの場合は `clustermgtd` ファイルを確認し、動的ノードの場合は `slurm_resume.log` ファイルでボリューム制限の詳細を確認してください。この問題を解決するには、別のボリュームを使用するか AWS リージョン、既存のボリュームを AWS クリーンアップするか、サポートセンターに連絡して Amazon EBS ボリューム制限の引き上げリクエストを送信してください。
### `InsufficientCapacityErrors` が表示されている
+ **何が起きたのか。**
AWS ParallelCluster には、Amazon EC2 インスタンスを起動してノードをバックアップするための十分な容量がありません。
+ **解決方法**
静的ノードについては `clustermgtd` ファイルを確認し、動的ノードについては `slurm_resume.log` ファイルで容量不足エラーの詳細を確認してください。この問題のトラブルシューティングを行うには、[https://aws.amazon.com/premiumsupport/knowledge-center/ec2-insufficient-capacity-errors/](https://aws.amazon.com/premiumsupport/knowledge-center/ec2-insufficient-capacity-errors/) のガイダンスに従ってください。
### `OtherInstanceLaunchFailures`
+ **何が起きたのか。**
コンピューティングノードをバッキングするための Amazon EC2 インスタンスを `CreateFleet` または `RunInstance` API で起動できませんでした。
+ **解決方法**
静的ノードについては `clustermgtd` ファイルを確認し、動的ノードについては `slurm_resume.log` ファイルでエラーの詳細を確認してください。
## 「**異常なインスタンスエラー**」グラフが表示されている
+ **何が起きたのか。**
多数のコンピューティングインスタンスが起動されたものの、後に異常として終了しました。
+ **解決方法**
異常なノードのトラブルシューティングの詳細については、「[**予期しないノードの置換や終了のトラブルシューティング**](troubleshooting-v3-scaling-issues.md#troubleshooting-v3-unexpected-node-replacements-and-terminations)」を参照してください。
### `InstanceBootstrapTimeoutError` が表示されている
+ **何が起きたのか。**
インスタンスは `resume_timeout` (動的ノードの場合) または `node_replacement_timeout` (静的ノードの場合) 内のクラスターに参加できません。これは、コンピューティングノード用にネットワークが正しく設定されていない場合や、コンピューティングノードで実行されているカスタムスクリプトが終了するまでに時間がかかりすぎる場合に発生する可能性があります。
+ **解決方法**
動的ノードの場合は、`clustermgtd` ログ (`/var/log/parallelcluster/clustermgtd`) でコンピューティングノードの IP アドレスと次のようなエラーを確認してください。
```
Node bootstrap error: Resume timeout expires for node
```
静的ノードの場合は、`clustermgtd` ログ (`/var/log/parallelcluster/clustermgtd`) でコンピューティングノードの IP アドレスと次のようなエラーを確認してください。
```
Node bootstrap error: Replacement timeout expires for node ... in replacement.
```
詳細については、`/var/log/cloud-init-output.log` ファイルでエラーを確認してください。問題のあるコンピューティングノードの IP アドレスは、`clustermgtd` および `slurm_resume` ログファイルから取得できます。
### `EC2HealthCheckErrors` が表示されている
+ **何が起きたのか。**
インスタンスが Amazon EC2 ヘルスチェックに失敗しました。
+ **解決方法**
この問題のトラブルシューティングについては、「[ステータスチェックに失敗したインスタンスのトラブルシューティング](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/TroubleshootingInstances.html)」を参照してください。
### `ScheduledEventHealthCheckErrors` が表示されている
+ **何が起きたのか。**
インスタンスが Amazon EC2 のスケジュールされたイベントのヘルスチェックに失敗し、正常ではありません。
+ **解決方法**
この問題のトラブルシューティングについては、「[インスタンスの予定されたイベント](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/monitoring-instances-status-check_sched.html)」を参照してください。
### `NoCorrespondingInstanceErrors` が表示されている
+ **何が起きたのか。**
AWS ParallelCluster はインスタンスバッキングノードを見つけることができません。ブートストラップ操作中にノードが自動的に終了した可能性があります。[`SlurmQueues`](Scheduling-v3.md#Scheduling-v3-SlurmQueues)/[`CustomActions`](Scheduling-v3.md#Scheduling-v3-SlurmQueues-CustomActions)/[`OnNodeStart`](Scheduling-v3.md#yaml-Scheduling-SlurmQueues-CustomActions-OnNodeStart) \$1 [`OnNodeConfigured`](Scheduling-v3.md#yaml-Scheduling-SlurmQueues-CustomActions-OnNodeConfigured) スクリプト、またはネットワークエラーが、`NoCorrespondingInstanceErrors` を発生させている可能性があります。
+ **解決方法**
詳細については、コンピューティングノードの `/var/log/cloud-init-output.log` を確認してください。
## **コンピューティングフリートのアイドル時間**グラフが表示されている
### **アイドル時間のスケールダウン**のしきい値よりも大幅に長い `MaxDynamicNodeIdleTime` が表示されている
+ **何が起きたのか。**
インスタンスが正しく終了していません。`MaxDynamicNodeIdleTime` は、Amazon EC2 インスタンスにバッキングされた動的ノードがアイドル状態になる最大時間 (秒) を示します。**アイドル時間スケールダウン**のしきい値は、クラスター設定の [`ScaledownIdletime`](Scheduling-v3.md#yaml-Scheduling-SlurmSettings-ScaledownIdletime) パラメータから算出されます。コンピューティングノードが**アイドル時間スケールダウン**の秒数を超えてアイドル状態になると、 はノードSlurmの電源を切り、バッキングインスタンスを AWS ParallelCluster 終了します。この場合、何かがインスタンスの終了を妨げています。
+ **解決方法**
この問題の詳細については、「[スケーリング問題のトラブルシューティング](troubleshooting-v3-scaling-issues.md)」の「[**問題のあるインスタンスやノードの置換、終了、電源オフ**](troubleshooting-v3-scaling-issues.md#replacing-terminating-or-powering-down-problematic-instances-and-nodes-v3)」を参照してください。
# クラスターデプロイの問題のトラブルシューティング
クラスターの作成に失敗し、スタックの作成がロールバックされる場合は、ログファイルを参照して問題を解決します。失敗した場合のメッセージは、次の出力のようになります。
```
$ pcluster create-cluster --cluster-name mycluster --region eu-west-1 \
--cluster-configuration cluster-config.yaml
{
"cluster": {
"clusterName": "mycluster",
"cloudformationStackStatus": "CREATE_IN_PROGRESS",
"cloudformationStackArn": "arn:aws:cloudformation:eu-west-1:xxx:stack/mycluster/1bf6e7c0-0f01-11ec-a3b9-024fcc6f3387",
"region": "eu-west-1",
"version": "3.15.0",
"clusterStatus": "CREATE_IN_PROGRESS"
}
}
$ pcluster describe-cluster --cluster-name mycluster --region eu-west-1
{
"creationTime": "2021-09-06T11:03:47.696Z",
...
"cloudFormationStackStatus": "ROLLBACK_IN_PROGRESS",
"clusterName": "mycluster",
"computeFleetStatus": "UNKNOWN",
"cloudformationStackArn": "arn:aws:cloudformation:eu-west-1:xxx:stack/mycluster/1bf6e7c0-0f01-11ec-a3b9-024fcc6f3387",
"lastUpdatedTime": "2021-09-06T11:03:47.696Z",
"region": "eu-west-1",
"clusterStatus": "CREATE_FAILED"
}
```
**Topics**
+ [で CloudFormation イベントを表示する `CREATE_FAILED`](#troubleshooting-v3-cluster-deployment-events)
+ [CLI を使用してログストリームを表示する](#troubleshooting-v3-cluster-deployment-cli-logstreams)
+ [`rollback-on-failure` を使用して失敗したクラスターを再作成する](#troubleshooting-v3-cluster-deployment-cli-fail-rollback)
## で CloudFormation イベントを表示する `CREATE_FAILED`
コンソールまたは CLI AWS ParallelCluster を使用して`CREATE_FAILED`、エラーに関する CloudFormation イベントを表示し、根本原因を見つけることができます。
**Topics**
+ [CloudWatch コンソールでイベントを表示する](#troubleshooting-v3-cluster-deployment-cloudformation)
+ [CLI を使用して、`CREATE_FAILED` で CloudFormation イベントを表示し、フィルタリングします。](#troubleshooting-v3-cluster-deployment-cli-events)
### CloudWatch コンソールでイベントを表示する
`"CREATE_FAILED"` ステータスの原因に関する情報を確認するのに、CloudFormation コンソールを使用できます。
**コンソールから CloudFormation のエラーメッセージを表示する。**
1. にログイン AWS マネジメントコンソール し、[https://console.aws.amazon.com/cloudformation](https://console.aws.amazon.com/cloudformation/) に移動します。
1. *cluster\$1name* という名前のスタックを選択します。
1. **[イベント]** タブを選択します。
1. **[論理 ID]** でリソースイベントのリストをスクロールして、作成に失敗したリソースの **[ステータス]** を確認します。サブタスクの作成に失敗した場合は、失敗したリソースイベントを見つけるために逆算します。
1. 例えば、次のステータスメッセージが表示される場合は、現在の vCPU 制限を超えないインスタンスタイプを使用するか、vCPU 容量の追加をリクエストする必要があります。
```
2022-02-04 16:09:44 UTC-0800 HeadNode CREATE_FAILED You have requested more vCPU capacity than your current vCPU limit of 0 allows
for the instance bucket that the specified instance type belongs to. Please visit http://aws.amazon.com/contact-us/ec2-request to request an adjustment to this limit.
(Service: AmazonEC2; Status Code: 400; Error Code: VcpuLimitExceeded; Request ID: a9876543-b321-c765-d432-dcba98766789; Proxy: null).
```
### CLI を使用して、`CREATE_FAILED` で CloudFormation イベントを表示し、フィルタリングします。
クラスター作成の問題を診断するには、[`pcluster get-cluster-stack-events`](pcluster.get-cluster-stack-events-v3.md) コマンドを使用して `CREATE_FAILED` ステータスのフィルタリングを行います。詳細については、「 *AWS Command Line Interface ユーザーガイド*[」の AWS CLI 「出力のフィルタリング](https://docs.aws.amazon.com/cli/latest/userguide/cli-usage-filter.html)」を参照してください。
```
$ pcluster get-cluster-stack-events --cluster-name mycluster --region eu-west-1 \
--query 'events[?resourceStatus==`CREATE_FAILED`]'
[
{
"eventId": "3ccdedd0-0f03-11ec-8c06-02c352fe2ef9",
"physicalResourceId": "arn:aws:cloudformation:eu-west-1:xxx:stack/mycluster/1bf6e7c0-0f02-11ec-a3b9-024fcc6f3387",
"resourceStatus": "CREATE_FAILED",
"resourceStatusReason": "The following resource(s) failed to create: [HeadNode]. ",
"stackId": "arn:aws:cloudformation:eu-west-1:xxx:stack/mycluster/1bf6e7c0-0f02-11ec-a3b9-024fcc6f3387",
"stackName": "mycluster",
"logicalResourceId": "mycluster",
"resourceType": "AWS::CloudFormation::Stack",
"timestamp": "2021-09-06T11:11:51.780Z"
},
{
"eventId": "HeadNode-CREATE_FAILED-2021-09-06T11:11:50.127Z",
"physicalResourceId": "i-04e91cc1f4ea796fe",
"resourceStatus": "CREATE_FAILED",
"resourceStatusReason": "Received FAILURE signal with UniqueId i-04e91cc1f4ea796fe",
"resourceProperties": "{\"LaunchTemplate\":{\"Version\":\"1\",\"LaunchTemplateId\":\"lt-057d2b1e687f05a62\"}}",
"stackId": "arn:aws:cloudformation:eu-west-1:xxx:stack/mycluster/1bf6e7c0-0f02-11ec-a3b9-024fcc6f3387",
"stackName": "mycluster",
"logicalResourceId": "HeadNode",
"resourceType": "AWS::EC2::Instance",
"timestamp": "2021-09-06T11:11:50.127Z"
}
]
```
前の例では、失敗はヘッドノードの設定にありました。
## CLI を使用してログストリームを表示する
この種の問題をデバッグするには、`node-type` でフィルタリングして [`pcluster list-cluster-log-streams`](pcluster.list-cluster-log-streams-v3.md) のヘッドノードから利用可能なログストリームをリストアップし、ログストリームのコンテンツを分析します。
```
$ pcluster list-cluster-log-streams --cluster-name mycluster --region eu-west-1 \
--filters 'Name=node-type,Values=HeadNode'
{
"logStreams": [
{
"logStreamArn": "arn:aws:logs:eu-west-1:xxx:log-group:/aws/parallelcluster/mycluster-202109061103:log-stream:ip-10-0-0-13.i-04e91cc1f4ea796fe.cfn-init",
"logStreamName": "ip-10-0-0-13.i-04e91cc1f4ea796fe.cfn-init",
...
},
{
"logStreamArn": "arn:aws:logs:eu-west-1:xxx:log-group:/aws/parallelcluster/mycluster-202109061103:log-stream:ip-10-0-0-13.i-04e91cc1f4ea796fe.chef-client",
"logStreamName": "ip-10-0-0-13.i-04e91cc1f4ea796fe.chef-client",
...
},
{
"logStreamArn": "arn:aws:logs:eu-west-1:xxx:log-group:/aws/parallelcluster/mycluster-202109061103:log-stream:ip-10-0-0-13.i-04e91cc1f4ea796fe.cloud-init",
"logStreamName": "ip-10-0-0-13.i-04e91cc1f4ea796fe.cloud-init",
...
},
...
]
}
```
初期化エラーを見つけるために使用できる 2 つの主要なログストリームは次のとおりです。
+ `cfn-init` は `cfn-init` のスクリプトのログです。まず、このログストリームを確認します。このログには `Command chef failed` エラーが表示される可能性があります。エラーメッセージの詳細については、この行の直前の行を参照してください。詳細については、[「cfn-init」](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/cfn-init.html)を参照してください。
+ `cloud-init` は [cloud-init](https://cloudinit.readthedocs.io/) のログです。`cfn-init` に何も表示されない場合は、次にこのログを確認してください。
ログストリームの内容を [`pcluster get-cluster-log-events`](pcluster.get-cluster-log-events-v3.md) で取得することができます (取得するイベント数を制限する `--limit 5` オプションに注意してください)。
```
$ pcluster get-cluster-log-events --cluster-name mycluster \
--region eu-west-1 --log-stream-name ip-10-0-0-13.i-04e91cc1f4ea796fe.cfn-init \
--limit 5
{
"nextToken": "f/36370880979637159565202782352491087067973952362220945409/s",
"prevToken": "b/36370880752972385367337528725601470541902663176996585497/s",
"events": [
{
"message": "2021-09-06 11:11:39,049 [ERROR] Unhandled exception during build: Command runpostinstall failed",
"timestamp": "2021-09-06T11:11:39.049Z"
},
{
"message": "Traceback (most recent call last):\n File \"/opt/aws/bin/cfn-init\", line 176, in \n worklog.build(metadata, configSets)\n File \"/usr/lib/python3.7/site-packages/cfnbootstrap/construction.py\", line 135, in build\n Contractor(metadata).build(configSets, self)\n File \"/usr/lib/python3.7/site-packages/cfnbootstrap/construction.py\", line 561, in build\n self.run_config(config, worklog)\n File \"/usr/lib/python3.7/site-packages/cfnbootstrap/construction.py\", line 573, in run_config\n CloudFormationCarpenter(config, self._auth_config).build(worklog)\n File \"/usr/lib/python3.7/site-packages/cfnbootstrap/construction.py\", line 273, in build\n self._config.commands)\n File \"/usr/lib/python3.7/site-packages/cfnbootstrap/command_tool.py\", line 127, in apply\n raise ToolError(u\"Command %s failed\" % name)",
"timestamp": "2021-09-06T11:11:39.049Z"
},
{
"message": "cfnbootstrap.construction_errors.ToolError: Command runpostinstall failed",
"timestamp": "2021-09-06T11:11:39.049Z"
},
{
"message": "2021-09-06 11:11:49,212 [DEBUG] CloudFormation client initialized with endpoint https://cloudformation.eu-west-1.amazonaws.com",
"timestamp": "2021-09-06T11:11:49.212Z"
},
{
"message": "2021-09-06 11:11:49,213 [DEBUG] Signaling resource HeadNode in stack mycluster with unique ID i-04e91cc1f4ea796fe and status FAILURE",
"timestamp": "2021-09-06T11:11:49.213Z"
}
]
}
```
前述の例では、失敗の原因は `runpostinstall` の失敗なので、[`CustomActions`](HeadNode-v3.md#HeadNode-v3-CustomActions) の `OnNodeConfigured` 設定パラメータで使われているカスタムブートストラップスクリプトの内容と厳密に関係しています。
## `rollback-on-failure` を使用して失敗したクラスターを再作成する
AWS ParallelCluster は、ロググループにクラスター CloudWatch ログストリームを作成します。これらのログは、CloudWatch コンソールの**カスタムダッシュボード**または**ロググループ**で表示できます。詳細については、「[Amazon CloudWatch Logs との統合](cloudwatch-logs-v3.md)」および「[Amazon CloudWatch ダッシュボード](cloudwatch-dashboard-v3.md)」を参照してください。利用可能なログストリームがない場合は、[`CustomActions`](HeadNode-v3.md#HeadNode-v3-CustomActions) カスタムブートストラップスクリプトや AMI 関連の問題が失敗の原因である可能性があります。この場合の作成問題を診断するには、`--rollback-on-failure` パラメータを `false` に設定した上で、[`pcluster create-cluster`](pcluster.create-cluster-v3.md) を使用してクラスターを再度作成します。次に、SSH を使用して、次に示すようにクラスターを表示します。
```
$ pcluster create-cluster --cluster-name mycluster --region eu-west-1 \
--cluster-configuration cluster-config.yaml --rollback-on-failure false
{
"cluster": {
"clusterName": "mycluster",
"cloudformationStackStatus": "CREATE_IN_PROGRESS",
"cloudformationStackArn": "arn:aws:cloudformation:eu-west-1:xxx:stack/mycluster/1bf6e7c0-0f01-11ec-a3b9-024fcc6f3387",
"region": "eu-west-1",
"version": "3.15.0",
"clusterStatus": "CREATE_IN_PROGRESS"
}
}
$ pcluster ssh --cluster-name mycluster
```
ヘッドノードにログインすると、エラーの原因を見つけるための 3 つの主要なログファイルが見つかります。
+ `/var/log/cfn-init.log` は `cfn-init` のスクリプトのログです。最初に、このログを確認してください。このログには `Command chef failed` などのエラーが表示される可能性があります。エラーメッセージの詳細については、この行の直前の行を参照してください。詳細については、[「cfn-init」](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/cfn-init.html)を参照してください。
+ `/var/log/cloud-init.log` は [cloud-init](https://cloudinit.readthedocs.io/) のログです。`cfn-init.log` に何も表示されない場合は、次にこのログを確認してください。
+ `/var/log/cloud-init-output.log` は [cloud-init](https://cloudinit.readthedocs.io/) で実行されたコマンドの出力です。これには `cfn-init` からの出力も含まれます。通常、この種の問題のトラブルシューティングには、このログを見る必要はありません。
# Terraform を使用したクラスターのデプロイのトラブルシューティング
このセクションは、Terraform を使用してデプロイしたクラスターに関連しています。
## ParallelCluster API が見つからない
ParallelCluster API が見つからないため、計画は失敗する可能性があります。この場合、次のようなエラーが返されます。
```
Planning failed. Terraform encountered an error while generating this plan.
╷
│ Error: Unable to retrieve ParallelCluster API cloudformation stack.
│
│ with provider["registry.terraform.io/aws-tf/aws-parallelcluster"],
│ on providers.tf line 6, in provider "aws-parallelcluster":
│ 6: provider "aws-parallelcluster" {
│
│ operation error CloudFormation: DescribeStacks, https response error StatusCode: 400, RequestID: REQUEST_ID, api error ValidationError: Stack with id PCAPI_STACK_NAME does not exist
```
このエラーを解決するには、クラスターを作成する先のアカウントに ParallelCluster API をデプロイします。「[Terraform を使用したクラスターの作成](tutorial-create-cluster-terraform.md)」を参照してください。
## ParallelCluster API を呼び出す権限がない
Terraform プロジェクトをデプロイするために引き受けた IAM ロール/ユーザーには ParallelCluster API を操作するアクセス許可がないため、計画が失敗する可能性があります。この場合、次のようなエラーが返されます。
```
Planning failed. Terraform encountered an error while generating this plan.
│ Error: 403 Forbidden
│
│ with module.parallelcluster_clusters.module.clusters[0].pcluster_cluster.managed_configs["DemoCluster01"],
│ on .terraform/modules/parallelcluster_clusters/modules/clusters/main.tf line 35, in resource "pcluster_cluster" "managed_configs":
│ 35: resource "pcluster_cluster" "managed_configs" {
│
│ {{"Message":"User: USER_ARN is not authorized to perform: execute-api:Invoke on resource: PC_API_REST_RESOURCE with an explicit deny"}
│ }
```
このエラーを解決するには、ParallelCluster API ロールを使用して API を操作するように ParallelCluster プロバイダーを設定します。
```
provider "aws-parallelcluster" {
region = var.region
profile = var.profile
api_stack_name = var.api_stack_name
**use_user_role** **= true**
}
```
# スケーリング問題のトラブルシューティング
このセクションは、Slurmジョブスケジューラで AWS ParallelCluster バージョン 3.0.0 以降を使用してインストールされたクラスターに関連しています。複数のキューの設定の詳細については、「[複数のキューの設定](configuration-of-multiple-queues-v3.md)」を参照してください。
稼働中のクラスターの 1 つに問題が発生した場合、トラブルシューティングを開始する前に次のコマンドを実行してクラスターを `STOPPED` 状態にします。これにより、予想外のコストが発生することを防ぐことができます。
```
$ pcluster update-compute-fleet --cluster-name mycluster \
--status STOP_REQUESTED
```
[`pcluster list-cluster-log-streams`](pcluster.list-cluster-log-streams-v3.md) コマンドを使用し、障害ノードまたはヘッドノードのいずれかの `private-dns-name` を使用してフィルタリングすることで、クラスターノードから利用可能なログストリームをリストアップすることができます。
```
$ pcluster list-cluster-log-streams --cluster-name mycluster --region eu-west-1 \
--filters 'Name=private-dns-name,Values=ip-10-0-0-101'
```
そして、[`pcluster get-cluster-log-events`](pcluster.get-cluster-log-events-v3.md) コマンドを使用して、次のセクションで述べたキーログの 1 つに対応する `--log-stream-name` を渡すことで、ログストリームの内容を取り出して分析することができます。
```
$ pcluster get-cluster-log-events --cluster-name mycluster \
--region eu-west-1 --log-stream-name ip-10-0-0-13.i-04e91cc1f4ea796fe.cfn-init
```
AWS ParallelCluster は、ロググループにクラスター CloudWatch ログストリームを作成します。これらのログは、CloudWatch コンソールの**カスタムダッシュボード**または**ロググループ**で表示できます。詳細については、「[Amazon CloudWatch Logs との統合](cloudwatch-logs-v3.md)」および「[Amazon CloudWatch ダッシュボード](cloudwatch-dashboard-v3.md)」を参照してください。
**Topics**
+ [デバッグ用のキーログ](#troubleshooting-v3-key-logs)
+ [ジョブの実行に失敗したとき `slurm_resume.log` で、またはクラスターの作成に失敗したとき `clustermgtd.log` で `InsufficientInstanceCapacity` エラーが表示されている](#compute-node-initialization-ice-failure-v3-c2)
+ [ノードの初期化に関する問題のトラブルシューティング](#troubleshooting-v3-node-init)
+ [**予期しないノードの置換や終了のトラブルシューティング**](#troubleshooting-v3-unexpected-node-replacements-and-terminations)
+ [**問題のあるインスタンスやノードの置換、終了、電源オフ**](#replacing-terminating-or-powering-down-problematic-instances-and-nodes-v3)
+ [キュー (パーティション) の `Inactive` ステータス](#troubleshooting-v3-queues)
+ [その他の既知のノードやジョブの問題のトラブルシューティング](#troubleshooting-v3-other-node-job-issues)
## デバッグ用のキーログ
次の表は、ヘッドノードのキーログの概要を示したものです。
+ `/var/log/cfn-init.log` - これは init CloudFormation ログです。インスタンスがセットアップされた時に実行されたすべてのコマンドが含まれています。初期化時の問題のトラブルシューティングに使用します。
+ `/var/log/chef-client.log` - これは Chef クライアントログです。Chef/CINC で実行されたすべてのコマンドが含まれています。初期化時の問題のトラブルシューティングに使用します。
+ `/var/log/parallelcluster/slurm_resume.log` - これは `ResumeProgram` ログです。動的ノードのインスタンスを起動します。ダイナミックノードの起動に関する問題のトラブルシューティングに使用します。
+ `/var/log/parallelcluster/slurm_suspend.log` - これが `SuspendProgram` のログです。動的ノードのインスタンスが終了する際に呼び出されます。ダイナミックノードの終了に関する問題のトラブルシューティングに使用します。このログを確認する際には、`clustermgtd` のログも確認する必要があります。
+ `/var/log/parallelcluster/clustermgtd` - これが `clustermgtd` のログです。ほとんどのクラスターオペレーションのアクションを管理する集中型デーモンとして動作します。起動、終了、またはクラスターの動作の問題のトラブルシューティングに使用します。
+ `/var/log/slurmctld.log` - これはSlurmコントロールデーモン log. AWS ParallelCluster does がスケーリングを決定しません。むしろ、Slurm の要求を満たすためにリソースの起動を試みます。スケーリングや割り当ての問題、ジョブ関連の問題、スケジューラ関連の起動や終了の問題などに有効です。
+ `/var/log/parallelcluster/compute_console_output` - このログには、予期せず終了した静的コンピューティングノードのサンプルサブセットからのコンソール出力が記録されます。静的コンピューティングノードが終了し、そのコンピューティングノードログが CloudWatch で利用できない場合は、このログを使用します。Amazon EC2 コンソールまたは を使用してインスタンスコンソールの出力 AWS CLI を取得する場合、受け取る`compute_console_output log`コンテンツは同じです。
以下は、コンピューティングノードの主要なログです。
+ `/var/log/cloud-init-output.log` - これは [cloud-init](https://cloudinit.readthedocs.io/) のログです。インスタンスがセットアップされた時に実行されたすべてのコマンドが含まれています。初期化時の問題のトラブルシューティングに使用します。
+ `/var/log/parallelcluster/computemgtd` - これが `computemgtd` のログです。各コンピューティングノードで実行し、ヘッドノードの `clustermgtd` デーモンがオフラインであるという一般的でなイベントのノードをモニタリングします。予期せぬ終了の問題のトラブルシューティングに使用します。
+ `/var/log/slurmd.log` - Slurm コンピューティングデーモンのログです。初期化およびコンピュートの不具合の問題に関するトラブルシューティングに使用します。
## ジョブの実行に失敗したとき `slurm_resume.log` で、またはクラスターの作成に失敗したとき `clustermgtd.log` で `InsufficientInstanceCapacity` エラーが表示されている
クラスターが Slurm スケジューラを使用している場合、容量不足の問題が発生しています。インスタンス起動のリクエスト時に十分な数のインスタンスが用意されていない場合は、`InsufficientInstanceCapacity` エラーが返されます。
静的インスタンス容量の場合、`/var/log/parallelcluster/clustermgtd` の `clustermgtd` ログでエラーを見つけることができます。
動的インスタンス容量の場合、`/var/log/parallelcluster/slurm_resume.log` の `ResumeProgram` ログでエラーを見つけることができます。
メッセージは、次の例のようになります。
```
An error occurred (InsufficientInstanceCapacity) when calling the RunInstances/CreateFleet operation...
```
ユースケースによっては、これらの種類のエラーメッセージが表示されないように、次のいずれかの方法を使用することを考慮します。
+ プレイスメントグループが有効になっている場合は、無効にします。詳細については、「[プレイスメントグループとインスタンスの起動に関する問題](troubleshooting-v3-placemment-groups.md)」を参照してください。
+ インスタンスのキャパシティを予約し、ODCR (オンデマンドキャパシティ予約) を使用して起動します。詳細については、「[オンデマンドキャパシティ予約 (ODCR) を使用してインスタンスを起動する](launch-instances-odcr-v3.md)」を参照してください。
+ 異なるインスタンスタイプを持つ複数のコンピューティングリソースを設定します。ワークロードに特定のインスタンスタイプが必要でない場合、複数のコンピューティングリソースによる容量不足の高速フェイルオーバーを活用できます。詳細については、「[Slurm クラスタ高速容量不足フェイルオーバー](slurm-short-capacity-fail-mode-v3.md)」を参照してください。
+ 同じコンピューティングリソースに複数のインスタンスタイプを設定し、複数のインスタンスタイプの割り当てを活用します。複数のインスタンスの設定に関する詳細については、[Slurm による複数のインスタンスタイプの割り当て](slurm-multiple-instance-allocation-v3.md) および [`Scheduling`](Scheduling-v3.md)/[`SlurmQueues`](Scheduling-v3.md#Scheduling-v3-SlurmQueues)/[`ComputeResources`](Scheduling-v3.md#Scheduling-v3-SlurmQueues-ComputeResources)/[`Instances`](Scheduling-v3.md#yaml-Scheduling-SlurmQueues-ComputeResources-Instances) を参照してください。
+ クラスター設定 [`Scheduling`](Scheduling-v3.md)/[`SlurmQueues`](Scheduling-v3.md#Scheduling-v3-SlurmQueues)/[`Networking`](Scheduling-v3.md#Scheduling-v3-SlurmQueues-Networking)/[`SubnetIds`](Scheduling-v3.md#yaml-Scheduling-SlurmQueues-Networking-SubnetIds) のサブネット ID を変更して、キューを異なるアベイラビリティーゾーンに移動します。
+ ワークロードが密接に結合されていない場合は、キューをさまざまなアベイラビリティーゾーンにまたがるようにしてください。複数のサブネットの設定に関する詳細については、「[`Scheduling`](Scheduling-v3.md)」/「[`SlurmQueues`](Scheduling-v3.md#Scheduling-v3-SlurmQueues)」/「[`Networking`](Scheduling-v3.md#Scheduling-v3-SlurmQueues-Networking)」/「[`SubnetIds`](Scheduling-v3.md#yaml-Scheduling-SlurmQueues-Networking-SubnetIds)」を参照してください。
## ノードの初期化に関する問題のトラブルシューティング
このセクションでは、ノードの初期化に関するトラブルを解決する方法について説明します。これには、ノードが起動しない、電源が入らない、またはクラスターが参加できない、などの問題が含まれます。
**Topics**
+ [ヘッドノード](#troubleshooting-v3-node-init.head-node)
+ [コンピューティングノード](#troubleshooting-v3-node-init.compute-node)
### ヘッドノード
該当するログ:
+ `/var/log/cfn-init.log`
+ `/var/log/chef-client.log`
+ `/var/log/parallelcluster/clustermgtd`
+ `/var/log/parallelcluster/slurm_resume.log`
+ `/var/log/slurmctld.log`
`/var/log/cfn-init.log` および `/var/log/chef-client.log` のログまたは対応するログストリームを確認してください。これらのログには、ヘッドノードのセットアップ時に実行されたすべてのアクションが含まれています。セットアップ中に発生するほとんどのエラーは、`/var/log/chef-client.log` ログにエラーメッセージが表示されます。クラスターの構成で `OnNodeStart` または `OnNodeConfigured` のスクリプトが指定されている場合、スクリプトが正常に実行されていることをログメッセージで再確認します。
クラスターが作成されると、ヘッドノードはコンピューティングノードがクラスターに参加するのを待ってからクラスターに参加する必要があります。このため、コンピューティングノードがクラスターに参加できないと、ヘッドノードも失敗してしまいます。このような問題を解決するためには、使用しているコンピュートノートの種類に応じて、次の手順のいずれかを実行します。
### コンピューティングノード
+ 該当するログ:
+ `/var/log/cloud-init-output.log`
+ `/var/log/slurmd.log`
+ コンピューティングノードが起動した場合、まず `/var/log/cloud-init-output.log` を確認します。ヘッドノードの `/var/log/chef-client.log` ログと同様のセットアップログが含まれているはずです。セットアップ中に発生するほとんどのエラーは、`/var/log/cloud-init-output.log` ログにエラーメッセージが表示されます。クラスター構成でプレインストールまたはポストインストールスクリプトが指定されている場合、それらが正常に実行されたかどうかを確認します。
+ Slurm の設定を変更したカスタム AMI を使用している場合は、Slurm 関連のエラーが発生し、コンピューティングノードがクラスターに参加できない可能性があります。スケジューラ関連のエラーについては、`/var/log/slurmd.log` のログを確認してください。
**動的コンピューティングノード:**
+ `ResumeProgram` ログ (`/var/log/parallelcluster/slurm_resume.log`) でコンピューティングノード名を検索し、そのノードで `ResumeProgram` が呼び出されたことがあるかどうかを調べます ( `ResumeProgram`が呼び出されたことがない場合は、 `slurmctld` ログ (`/var/log/slurmctld.log`) をチェックして、ノード`ResumeProgram`で を呼び出そうとしたSlurmかどうかを判断できます）。
+ なお、`ResumeProgram` のパーミッションが正しくないと、`ResumeProgram` がバックグラウンドで失敗する可能性があります。`ResumeProgram` の設定を変更したカスタム AMI を使用している場合は、`ResumeProgram` の所有者が `slurm` ユーザーであり、`744` (`rwxr--r--`) の許可を持っていることを確認してください。
+ `ResumeProgram` が呼ばれた場合、そのノードのインスタンスが起動しているかどうかを確認します。インスタンスが起動しなかった場合は、起動の失敗を示すエラーメッセージが表示されます。
+ インスタンスが起動する場合は、セットアップ時に問題が発生した可能性があります。`ResumeProgram` のログに対応するプライベート IP アドレスとインスタンス ID が表示されます。さらに、特定のインスタンスに対応するセットアップログを確認することができます。コンピューティングノードのセットアップエラーのトラブルシューティングについては、次のセクションを参照してください。
**静的コンピューティングノード:**
+ `clustermgtd` (`/var/log/parallelcluster/clustermgtd`) ログをチェックして、ノードに対してインスタンスが起動されたかどうかを確認します。起動されていない場合は、起動失敗の詳細を示す明確なエラーメッセージが表示されるはずです。
+ インスタンスが起動した場合、セットアップ中に何らかの問題が発生します。`ResumeProgram` のログに対応するプライベート IP アドレスとインスタンス ID が表示されます。さらに、特定のインスタンスに対応するセットアップログを確認することができます。
**スポットインスタンスにバックアップされたコンピューティングノード:**
+ スポットインスタンスを初めて使用し、ジョブが PD (保留中) のままである場合は、`/var/log/parallelcluster/slurm_resume.log` ファイルを再確認します。次のようなエラーが見つかる可能性があります。
```
2022-05-20 13:06:24,796 - [slurm_plugin.common:add_instances_for_nodes] - ERROR - Encountered exception when launching instances for nodes (x1) ['spot-dy-t2micro-2']: An error occurred (AuthFailure.ServiceLinkedRoleCreationNotPermitted) when calling the RunInstances operation: The provided credentials do not have permission to create the service-linked role for Amazon EC2 Spot Instances.
```
スポットインスタンスを使用する場合、お客様のアカウントに `AWSServiceRoleForEC2Spot` サービスにリンクしたロールが存在する必要があります。を使用してアカウントにこのロールを作成するには AWS CLI、次のコマンドを実行します。
```
$ aws iam create-service-linked-role --aws-service-name spot.amazonaws.com
```
詳細については、 AWS ParallelCluster 「 ユーザーガイド[スポットインスタンスの操作](spot-v3.md)」の「」および[「Amazon EC2 ユーザーガイド」の「スポットインスタンスリクエストのサービスにリンクされたロール](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/spot-requests.html#service-linked-roles-spot-instance-requests)」を参照してください。 *Amazon EC2 *
## **予期しないノードの置換や終了のトラブルシューティング**
このセクションでは、ノードに関連する問題、特にノードが予期せず置換されたり終了したりした場合のトラブルシューティング方法について引き続き説明します。
+ **該当するログ:**
+ `/var/log/parallelcluster/clustermgtd` (ヘッドノード)
+ `/var/log/slurmctld.log` (ヘッドノード)
+ `/var/log/parallelcluster/computemgtd` (コンピューティングノード)
**予期せず置換または終了したノード**
+ `clustermgtd` がノードを置換または終了させたかどうかを確認するには、`clustermgtd` のログ (`/var/log/parallelcluster/clustermgtd`) を確認します。なお、`clustermgtd` は通常のノードメンテナンスのアクションをすべて行います。
+ `clustermgtd` がノードを置換または終了させた場合、なぜそのアクションがノードに対して行われたのかを詳細に説明するメッセージが必要です。スケジューラ関連の理由 (例えば、ノードが `DOWN` にあるため) の場合は、`slurmctld` ログで確認してください。理由が Amazon EC2 に関連するものであれば、置換を必要とする Amazon EC2 に関連する問題の詳細を示す情報メッセージが表示されるはずです。
+ `clustermgtd` がノードを終了しなかった場合は、まずこれが Amazon EC2 による予期された終了、具体的にはスポット終了であるかどうかを確認します。コンピューティングノードで`computemgtd`実行されている は、 `clustermgtd`が異常であると判断された場合にノードを終了することもできます。`computemgtd` のログ (`/var/log/parallelcluster/computemgtd`) を確認し、`computemgtd` がノードを終了したかどうかを確認します。
**ノードが失敗しました**
+ `slurmctld` ログ (`/var/log/slurmctld.log`) で、ジョブやノードが失敗した理由を確認します。なお、ノードに障害が発生した場合、ジョブは自動的に再キューされます。
+ `slurm_resume` がノードの起動を報告し、`clustermgtd` が数分後にそのノードに対応するインスタンスが Amazon EC2 に存在しないと報告した場合、ノードはセットアップ中に失敗する可能性があります。コンピュート (`/var/log/cloud-init-output.log`) からログを取得するには、次の手順で行います。
+ Slurm が新しいノードを立ち上げるためのジョブを送信します。
+ コンピューティングノードが起動するまで待ちます。
+ インスタンスにより開始したシャットダウン動作を変更して、障害が発生したコンピューティングノードを終了するのではなく停止するようにします。
```
$ aws ec2 modify-instance-attribute \
--instance-id i-1234567890abcdef0 \
--instance-initiated-shutdown-behavior "{\"Value\": \"stop\"}"
```
+ 削除保護を有効にします。
```
$ aws ec2 modify-instance-attribute \
--instance-id i-1234567890abcdef0 \
--disable-api-termination
```
+ 簡単に識別できるようにノードにタグを付けます。
```
$ aws ec2 create-tags \
--resources i-1234567890abcdef0 \
--tags Key=Name,Value=QUARANTINED-Compute
```
+ `parallelcluster:cluster-name` タグを変更して、クラスターからノードをデタッチします。
```
$ aws ec2 create-tags \
--resources i-1234567890abcdef0 \
--tags Key=parallelcluster:clustername,Value=QUARANTINED-ClusterName
```
+ このコマンドで、ノードのコンソール出力を取得します。
```
$ aws ec2 get-console-output --instance-id i-1234567890abcdef0 --output text
```
## **問題のあるインスタンスやノードの置換、終了、電源オフ**
+ **該当するログ:**
+ `/var/log/parallelcluster/clustermgtd` (ヘッドノード)
+ `/var/log/parallelcluster/slurm_suspend.log` (ヘッドノード)
+ 通常、`clustermgtd` は期待されるすべてのインスタンス終了アクションを処理します。`clustermgtd` ログを見て、ノードの置換または終了に失敗した理由を確認します。
+ [`SlurmSettings` プロパティ](Scheduling-v3.md#Scheduling-v3-SlurmSettings.properties) に失敗した動的ノードの場合、`SuspendProgram` ログで `SuspendProgram` が `slurmctld` から特定のノードを引数として呼び出されたかどうかを確認します。なお、`SuspendProgram` は実際には何のアクションもしません。呼び出されたときだけログに記録されます。インスタンスの終了や `NodeAddr` のリセットは全て `clustermgtd` が行います。Slurm は `SuspendTimeout` の後、自動的にノードを `POWER_SAVING` 状態に戻します。
+ ブートストラップの失敗のためコンピューティングノードに継続的に障害が発生する場合は、[Slurm クラスター保護モード](slurm-protected-mode-v3.md) が有効な状態で起動されているかどうかを確認してください。保護モードが有効になっていない場合は、保護モードの設定を変更して保護モードを有効にします。ブートストラップスクリプトのトラブルシューティングをして修正してください。
## キュー (パーティション) の `Inactive` ステータス
`sinfo` を実行して出力に `inact` の `AVAIL` ステータスのキューが表示される場合は、クラスターで [Slurm クラスター保護モード](slurm-protected-mode-v3.md) が有効になっており、キューが事前に定義した期間に `INACTIVE` ステータスに設定されていた可能性があります。
## その他の既知のノードやジョブの問題のトラブルシューティング
もう 1 つの既知の問題は、ジョブの割り当てやスケーリングの決定に失敗 AWS ParallelCluster する可能性があることです。このタイプの発行では、Slurm の指示に従って、リソースの起動、 AWS ParallelCluster の終了、または維持のみが行われます。これらの問題については、`slurmctld` ログを確認してトラブルシューティングを行ってください。
# プレイスメントグループとインスタンスの起動に関する問題
ノード間のレイテンシーを最小にするには、*プレースメントグループ*を使用します。プレイスメントグループにより、インスタンスが同じネットワーキングバックボーンに配置されます。リクエスト時に十分な数のインスタンスが用意されていない場合は、`InsufficientInstanceCapacity` エラーが返ります。クラスタープレイスメントグループを使用する際にこのエラーが発生する可能性を減らすために、[`SlurmQueues`](Scheduling-v3.md#Scheduling-v3-SlurmQueues)/[`Networking`](Scheduling-v3.md#Scheduling-v3-SlurmQueues-Networking)/[`PlacementGroup`](Scheduling-v3.md#yaml-Scheduling-SlurmQueues-Networking-PlacementGroup)/[`Enabled`](Scheduling-v3.md#yaml-Scheduling-SlurmQueues-Networking-PlacementGroup-Enabled) パラメータを `false` に設定します。
キャパシティアクセスをさらに制御するには、「[Launching instances with ODCR (On-Demand Capacity Reservations)](launch-instances-odcr-v3.md)」を考慮します。
詳細については、「Linux インスタンス用 Amazon EC2 ユーザーガイド**」の「[インスタンスの起動に関する問題のトラブルシューティング](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/troubleshooting-launch.html)」および「[プレイスメントグループの役割と制限](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/placement-groups.html#concepts-placement-groups)」を参照してください。
# ディレクトリの置換
一部のディレクトリは置換できません。ディレクトリの置き換えに問題がある場合、置換不能が原因となっていることがあります。以下のディレクトリはノード間で共有され、置換できません。
+ `/opt/intel` - これには、インテル MPI、インテル Parallel Studio、および関連ファイルが含まれます。
+ `/opt/slurm` - これには、Slurm ワークロードマネージャーおよび関連ファイルが含まれます。(条件付き、`Scheduler: slurm` の場合のみ)
# Amazon DCV の問題のトラブルシューティング
**Topics**
+ [Amazon DCV のログ](#troubleshooting-v3-nice-dcv-logs)
+ [Ubuntu Amazon DCV の問題](#troubleshooting-v3-nice-dcv-modules)
## Amazon DCV のログ
Amazon DCV のログは `/var/log/dcv/` ディレクトリのファイルに書き込まれます。これらのログを確認することは、問題の解決に役立ちます。
インスタンスタイプは、Amazon DCV を実行するために、少なくとも1.7 ギビバイト (GiB) の RAM を必要とします。nano や micro のインスタンスタイプには、Amazon DCV を実行するのに十分なメモリがありません。
AWS ParallelCluster は、ロググループに Amazon DCV ログストリームを作成します。これらのログは、CloudWatch コンソールの**カスタムダッシュボード**または**ロググループ**で表示できます。詳細については、「[Amazon CloudWatch Logs との統合](cloudwatch-logs-v3.md)」および「[Amazon CloudWatch ダッシュボード](cloudwatch-dashboard-v3.md)」を参照してください。
## Ubuntu Amazon DCV の問題
Ubuntu の Amazon DCV セッションで Gnome ターミナルを実行すると、 AWS ParallelCluster でログインシェルから利用可能となるユーザー環境に自動的にアクセスできない場合があります。ユーザー環境には、openmpi や intelmpi などの環境モジュールやその他のユーザー設定が用意されています。
Gnome ターミナルのデフォルト設定では、シェルをログインシェルとして起動することはできません。つまり、シェルプロファイルは自動的にソース化されず、 AWS ParallelCluster ユーザー環境はロードされません。
シェルプロファイルを適切にソース化し、 AWS ParallelCluster ユーザー環境にアクセスするには、次のいずれかを実行します。
+
**デフォルトのターミナル設定を変更します。**
1. Gnome ターミナルで **[編集]** メニューを選択します。
1. **[設定]**、**[プロファイル]** の順に選択します。
1. **[コマンド]** を選択し、**[ログインシェルとしてコマンドを実行]** を選択します。
1. [新しいターミナル] を開きます。
+ **コマンドラインを使用して、使用可能なプロファイルを取得します。**
```
$ source /etc/profile && source $HOME/.bashrc
```
# AWS Batch 統合によるクラスターの問題のトラブルシューティング
このセクションでは、特にヘッドノードの問題、コンピューティングの問題、ジョブの失敗、タイムアウトエラーなど、ス AWS Batch ケジューラ統合を使用するクラスターで考えられるトラブルシューティングのヒントを提供します。
**Topics**
+ [ヘッドノードの問題](#troubleshooting-v3-batch-head-node)
+ [コンピュートの問題](#troubleshooting-v3-batch-compute-nodes)
+ [ジョブの失敗](#troubleshooting-v3-batch-job-fail)
+ [エンドポイント URL の接続タイムアウトエラー](#troubleshooting-v3-batch-connect-timeout)
## ヘッドノードの問題
ヘッドノードのセットアップに関連する問題は、Slurm クラスターと同様にトラブルシューティングを行うことができます (Slurm 固有のログは除く)。これらの問題を解決する方法の詳細については、「[ヘッドノード](troubleshooting-v3-scaling-issues.md#troubleshooting-v3-node-init.head-node)」を参照してください。
## コンピュートの問題
AWS Batch は、サービスのスケーリングとコンピューティングの側面を管理します。コンピューティング関連の問題が発生した場合は、 AWS Batch [トラブルシューティング](https://docs.aws.amazon.com/batch/latest/userguide/troubleshooting.html)ドキュメントを参照してください。
## ジョブの失敗
ジョブが失敗した場合は、[`awsbout`](awsbatchcli.awsbout-v3.md) コマンドを実行してジョブの出力を取得することができます。また、[`awsbstat`](awsbatchcli.awsbstat-v3.md) コマンドを実行して、Amazon CloudWatch が保存しているジョブログへのリンクを取得することもできます。
## エンドポイント URL の接続タイムアウトエラー
マルチノード並列ジョブが、エラー `Connect timeout on endpoint URL` で失敗する場合:
+ `awsbout` 出力ログで、出力からジョブがマルチノード並列であることを確認します。`Detected 3/3 compute nodes. Waiting for all compute nodes to start.`
+ コンピューティングノードのサブネットがパブリックかどうかを確認します。
マルチノード並列ジョブは、 AWS Batch で を使用する場合のパブリックサブネットの使用をサポートしていません AWS ParallelCluster。コンピューティングノードとジョブにはプライベートサブネットを使用します。詳細については、「AWS Batch ユーザーガイド**」の「[Compute environment considerations](https://docs.aws.amazon.com/batch/latest/userguide/multi-node-parallel-jobs.html#mnp-ce)」を参照してください。コンピューティングノードにプライベートサブネットを設定するには、「[AWS ParallelCluster ス AWS Batch ケジューラを使用する](network-configuration-v3-batch.md)」を参照してください。
# Active Directory を使用したマルチユーザー統合のトラブルシューティング
このセクションは、Active Directory と統合されたクラスターに関連するものです。
Active Directory 統合機能が期待どおりに動作していない場合、SSSD ログは役立つ診断情報を提供します。これらのログは、クラスターノードの `/var/log/sssd` に配置されています。デフォルトでは、クラスターの Amazon CloudWatch ロググループにも保存されます。
**Topics**
+ [Active Directory 固有のトラブルシューティング](#troubleshooting-v3-multi-ad-specific)
+ [デバッグモードを有効にする](#troubleshooting-v3-multi-user-debug)
+ [LDAPS から LDAP に移行する方法](#troubleshooting-v3-multi-user-ldaps-ldap)
+ [LDAPS サーバー証明書の検証を無効にする方法](#troubleshooting-v3-multi-user-ldaps-verify)
+ [パスワードではなく SSH キーを使用してログインする方法](#troubleshooting-v3-multi-user-ssh-login)
+ [ユーザーパスワードと失効しているパスワードをリセットする方法](#troubleshooting-v3-multi-user-reset-passwd)
+ [参加しているドメインを確認する方法](#troubleshooting-v3-multi-user-domain-verify)
+ [証明書に関する問題をトラブルシューティングする方法](#troubleshooting-v3-multi-user-certificates)
+ [Active Directory との統合が動作していることを確認する方法](#troubleshooting-v3-multi-user-ad-verify)
+ [コンピューティングノードへのログインのトラブルシューティング方法](#troubleshooting-v3-multi-user-ad-compute-node-login)
+ [マルチユーザー環境での SimCenter StarCCM\$1 ジョブに関する既知の問題](#troubleshooting-v3-multi-user-ad-starccm)
+ [ユーザー名解決に関する既知の問題](#troubleshooting-v3-multi-user-name-resolution)
+ [ホームディレクトリ作成の問題の解決方法](#troubleshooting-v3-multi-home-directory)
## Active Directory 固有のトラブルシューティング
このセクションは、Active Directory タイプ固有のトラブルシューティングに関連するものです。
### Simple AD
+ `DomainReadOnlyUser` 値は、ユーザーの Simple AD ディレクトリベース検索と一致している必要があります。
`cn=ReadOnlyUser,cn=Users,dc=corp,dc=example,dc=com`
`Users` の `cn` に注意してください。
+ デフォルトの管理者ユーザーは `Administrator` です。
+ `Ldapsearch` ユーザー名の前に NetBIOS 名が必要です。
`Ldapsearch` の構文は次のようである必要があります。
```
$ ldapsearch -x -D "corp\\Administrator" -w "Password" -H ldap://192.0.2.103 \
-b "cn=Users,dc=corp,dc=example,dc=com"
```
### AWS Managed Microsoft AD
+ `DomainReadOnlyUser` 値は、ユーザーの AWS Managed Microsoft AD ディレクトリベース検索と一致する必要があります。
`cn=ReadOnlyUser,ou=Users,ou=CORP,dc=corp,dc=example,dc=com`
+ デフォルトの管理者ユーザーは `Admin` です。
+ `Ldapsearch` の構文は次のようである必要があります。
```
$ ldapsearch -x -D "Admin" -w "Password" -H ldap://192.0.2.103 \
-b "ou=Users,ou=CORP,dc=corp,dc=example,dc=com"
```
## デバッグモードを有効にする
SSSD からのデバッグログは問題をトラブルシューティングするのに役立ちます。デバッグモードを有効にするには、クラスター設定に次の変更を加えてクラスターを更新する必要があります。
```
DirectoryService:
AdditionalSssdConfigs:
debug_level: "0x1ff"
```
## LDAPS から LDAP に移行する方法
LDAP だけでは暗号化を提供できないため、LDAPS (TLS/SSL を使用する LDAP) から LDAP への移行は推奨されていません。それでも、テスト目的やトラブルシューティングに役立ちます。
クラスターを以前の設定定義で更新することにより、クラスターを以前の設定に復元できます。
LDAPS から LDAP に移行するには、クラスター設定に次の変更を加えてクラスターを更新する必要があります。
```
DirectoryService:
LdapTlsReqCert: never
AdditionalSssdConfigs:
ldap_auth_disable_tls_never_use_in_production: True
```
## LDAPS サーバー証明書の検証を無効にする方法
テストまたはトラブルシューティングの目的でヘッドノードでの LDAPS サーバー証明書の検証を一時的に無効にすることは役立ちます。
クラスターを以前の設定定義で更新することにより、クラスターを以前の設定に復元できます。
LDAPS サーバー証明書の検証を無効にするには、クラスター設定に次の変更を加えてクラスターを更新する必要があります。
```
DirectoryService:
LdapTlsReqCert: never
```
## パスワードではなく SSH キーを使用してログインする方法
SSH キーは、パスワードを使用して初めてログインした後、`/home/$user/.ssh/id_rsa` に作成されます。SSH キーを使用してログインするには、パスワードを使用してログインし、SSH キーをローカルにコピーしてから、通常どおりパスワードなしで SSH キーを使用する必要があります。
```
$ ssh -i $LOCAL_PATH_TO_SSH_KEY $username@$head_node_ip
```
## ユーザーパスワードと失効しているパスワードをリセットする方法
ユーザーがクラスターにアクセスできなくなった場合、[AWS Managed Microsoft AD パスワードが失効している可能性があります](https://docs.aws.amazon.com/directoryservice/latest/admin-guide/ms_ad_password_policies.html)。
パスワードをリセットするには、ディレクトリの書き込みアクセス許可を持つユーザーとロールを使用し、次のコマンドを実行します。
```
$ aws ds reset-user-password \
--directory-id "d-abcdef01234567890" \
--user-name "USER_NAME" \
--new-password "NEW_PASSWORD" \
--region "region-id"
```
[`DirectoryService`](DirectoryService-v3.md)/[`DomainReadOnlyUser`](DirectoryService-v3.md#yaml-DirectoryService-DomainReadOnlyUser) のパスワードをリセットする場合。
1. 必ず新しいパスワードで [`DirectoryService`](DirectoryService-v3.md)/[`PasswordSecretArn`](DirectoryService-v3.md#yaml-DirectoryService-PasswordSecretArn) シークレットを更新します。
1. 新しいシークレット値にクラスターを更新します。
1. `pcluster update-compute-fleet` コマンドを使用してコンピューティングフリートを停止します。
1. クラスターヘッドノード内から、次のコマンドを実行します。
```
$ sudo /opt/parallelcluster/scripts/directory_service/update_directory_service_password.sh
```
パスワードのリセットとクラスターの更新の後、ユーザーのクラスターアクセスは復元されています。
詳細については、「Directory Service 管理ガイド**」の「[ユーザーパスワードをリセットする](https://docs.aws.amazon.com/directoryservice/latest/admin-guide/ms_ad_manage_users_groups_reset_password.html)」を参照してください。
## 参加しているドメインを確認する方法
次のコマンドは、ヘッドノードではなく、ドメインに参加しているインスタンスから実行する必要があります。
```
$ realm list corp.example.com \
type: kerberos \
realm-name: CORP.EXAMPLE.COM \
domain-name: corp.example.com \
configured: kerberos-member \
server-software: active-directory \
client-software: sssd \
required-package: oddjob \
required-package: oddjob-mkhomedir \
required-package: sssd \
required-package: adcli \
required-package: samba-common-tools \
login-formats: %U \
login-policy: allow-realm-logins
```
## 証明書に関する問題をトラブルシューティングする方法
LDAPS 通信が動作していない場合、TLS 通信のエラーが原因である可能性があり、それは証明書の問題である可能性があります。
**証明書に関する注意事項。**
+ クラスターの設定 `LdapTlsCaCert` で指定する証明書は、ドメインコントローラーの証明書を発行した認証局 (CA) チェーンの証明書全体を含む PEM 証明書のバンドルである必要があります。
+ PEM 証明書のバンドルとは PEM 証明書を連結したファイルのことです。
+ PEM 形式の証明書 (通常 Linux で使用) は base64 DER 形式の証明書 (通常 Windows でエクスポート) と同等です。
+ ドメインコントローラーの証明書が下位 CA によって発行された場合、証明書バンドルには下位およびルート CA の両方の証明書が含まれている必要があります。
**トラブルシューティングの検証手順:**
次の検証手順は、コマンドがクラスターヘッドノード内から実行されていて、ドメインコントローラーに `SERVER:PORT` でアクセスできることを前提としています。
証明書に関連する問題をトラブルシューティングするには、次の検証手順に従ってください。
**検証手順:**
1. **Active Directory ドメインコントローラーへの接続を確認します。**
ドメインコントローラーに接続できることを確認します。この手順が成功したら、ドメインコントローラーへの SSL 接続は成功し、証明書が検証されます。問題は証明書とは関係ありません。
この手順に失敗した場合は、次の検証に進みます。
```
$ openssl s_client -connect SERVER:PORT -CAfile PATH_TO_CA_BUNDLE_CERTIFICATE
```
1. **証明書の検証を確認します。**
ローカル CA 証明書バンドルがドメインコントローラから提供された証明書を検証できることを確認します。この手順が成功した場合、問題は証明書に関するものではなく、他のネットワークの問題に関係しています。
この手順に失敗した場合は、次の検証に進みます。
```
$ openssl verify -verbose -CAfile PATH_TO_CA_BUNDLE_CERTIFICATE PATH_TO_A_SERVER_CERTIFICATE
```
1. **Active Directory ドメインコントローラーから提供された証明書を確認します。**
ドメインコントローラーから提供された証明書の内容が期待どおりのものであることを確認します。この手順が成功した場合、コントローラーの検証に使用した CA 証明書に問題がある可能性があります。次のトラブルシューティングの手順に進んでください。
この手順に失敗した場合は、ドメインコントローラー用に発行された証明書を修正し、トラブルシューティングの手順を再実行する必要があります。
```
$ openssl s_client -connect SERVER:PORT -showcerts
```
1. **証明書の内容を確認します。**
ドメインコントローラーから提供された証明書の内容が期待どおりのものであることを確認します。この手順が成功した場合、コントローラーの検証に使用した CA 証明書に問題がある可能性があります。次のトラブルシューティングの手順に進んでください。
この手順に失敗した場合は、ドメインコントローラー用に発行された証明書を修正し、トラブルシューティングの手順を再実行する必要があります。
```
$ openssl s_client -connect SERVER:PORT -showcerts
```
1. **ローカル CA 証明書バンドルの内容を確認します。**
ドメインコントローラーの証明書の検証に使用されるローカル CA 証明書バンドルの内容が期待どおりのものであることを確認します。この手順が成功した場合、ドメインコントローラーから提供される証明書に問題がある可能性があります。
この手順に失敗した場合は、ドメインコントローラー用に発行された CA 証明書バンドルを修正し、トラブルシューティングの手順を再実行する必要があります。
```
$ openssl x509 -in PATH_TO_A_CERTIFICATE -text
```
## Active Directory との統合が動作していることを確認する方法
次の 2 つのチェックが成功すれば、Active Directory との統合は動作しています。
**チェック:**
1. **ディレクトリに定義されているユーザーを検出できる。**
クラスターヘッドノード内から、`ec2-user` として次のようにします。
```
$ getent passwd $ANY_AD_USER
```
1. **ユーザーパスワードを指定してヘッドノードに SSH 接続できる。**
```
$ ssh $ANY_AD_USER@$HEAD_NODE_IP
```
チェック 1 が失敗すると、チェック 2 も失敗することが予想されます。
その他のトラブルシューティングの確認。
+ ユーザーがディレクトリに存在することを確認します。
+ [デバッグログ](#troubleshooting-v3-multi-user-debug)を有効にします。
+ LDAPS の問題を除外するために、[LDAPS から LDAP に移行](#troubleshooting-v3-multi-user-ldaps-ldap)して暗号化を一時的に無効にすることを検討します。
## コンピューティングノードへのログインのトラブルシューティング方法
このセクションは、Active Directory と統合されたクラスターのコンピューティングノードへのログインに関連するものです。
では AWS ParallelCluster、クラスターコンピューティングノードへのパスワードログインは設計上無効になっています。
すべてのユーザーは、独自の SSH キーを使用してコンピューティングノードにログインする必要があります。
クラスター設定で [`GenerateSshKeysForUsers`](DirectoryService-v3.md#yaml-DirectoryService-GenerateSshKeysForUsers) が有効になっている場合、ユーザーは初回認証 (ログインなど) の後にヘッドノードで SSH キーを取得できます。
ユーザーはヘッドノードで初めて認証されるとき、ディレクトリユーザーとして自動的に生成された SSH キーを取得できます。ユーザーのホームディレクトリも作成されます。これは sudo ユーザーが初めてヘッドノードのユーザーに切り替えたときにも生じます。
ユーザーがヘッドノードにログインしたことがない場合、SSH キーは生成されず、ユーザーはコンピューティングノードにログインすることはできません。
## マルチユーザー環境での SimCenter StarCCM\$1 ジョブに関する既知の問題
このセクションは、Siemens の計算流体力学ソフトウェア Simcenter StarCCM\$1 がマルチユーザー環境で起動したジョブに関連するものです。
埋め込みの IntelMPI を使用するように設定された StarCCM\$1 v16 ジョブを実行すると、デフォルトで SSH を使用して MPI プロセスがブートストラップされます。
ユーザー名の解決エラーを起こす既知の [Slurm のバグ](https://bugs.schedmd.com/show_bug.cgi?id=13385)により、ジョブは `error setting up the bootstrap proxies` などのエラーで失敗することがあります。このバグは、 AWS ParallelCluster バージョン 3.1.1 と 3.1.2 にのみ影響します。
これを防ぐには、MPI ブートストラップ方式として Slurm を使用するよう IntelMPI を強制します。「[IntelMPI 公式ドキュメント](https://www.intel.com/content/www/us/en/develop/documentation/mpi-developer-reference-linux/top/environment-variable-reference/hydra-environment-variables.html)」で説明されているように、StarCCM\$1 を起動するジョブスクリプトに環境変数 `I_MPI_HYDRA_BOOTSTRAP=slurm` をエクスポートします。
## ユーザー名解決に関する既知の問題
このセクションは、ジョブ内でのユーザー名の取得に関連するものです。
既知の [Slurm のバグ](https://bugs.schedmd.com/show_bug.cgi?id=13385)により、`srun` なしでジョブを実行する場合、ジョブプロセス内で取得されるユーザー名は、`nobody` になることがあります。このバグは、 AWS ParallelCluster バージョン 3.1.1 と 3.1.2 にのみ影響します。
例えば、ディレクトリユーザーとして `sbatch --wrap 'srun id'` コマンドを実行すると、正しいユーザー名が返されます。ただし、`sbatch --wrap 'id'` をディレクトリユーザーとして実行すると、`nobody` がユーザー名として返されることがあります。
次の回避策を使用できます。
1. 可能であれば、`'sbatch'` の代わりに `'srun'` を使用してジョブを起動します。
1. クラスター設定で [AdditionalSssdConfigs](DirectoryService-v3.md#yaml-DirectoryService-AdditionalSssdConfigs) を次のように設定して、SSSD 列挙を有効にします。
```
AdditionalSssdConfigs:
enumerate: true
```
## ホームディレクトリ作成の問題の解決方法
このセクションは、ホームディレクトリ作成の問題に関連するものです。
次の例に示されるようなエラーが表示される場合は、ヘッドノードに初めてログインしたときにホームディレクトリが作成されていません。または、ヘッドノードで初めて sudoer から Active Directory ユーザーに切り替えたときに、ホームディレクトリが作成されませんでした。
```
$ ssh AD_USER@$HEAD_NODE_IP
/opt/parallelcluster/scripts/generate_ssh_key.sh failed: exit code 1
__| __|_ )
_| ( / Amazon Linux 2 AMI
___|\___|___|
https://aws.amazon.com/amazon-linux-2/
Could not chdir to home directory /home/PclusterUser85: No such file or directory
```
ホームディレクトリの作成の失敗は、クラスターヘッドノードにインストールされている `oddjob` および `oddjob-mkhomedir` パッケージにより発生することがあります。
ホームディレクトリと SSH キーがない場合、ユーザーはジョブや SSH をクラスターノードに送信できません。
システムに `oddjob` パッケージが必要な場合、`oddjobd` サービスが実行中であることを確認し、PAM 設定ファイルを更新してホームディレクトリが作成されていることを確認します。これを行うには、次の例に示されるようにヘッドノードでコマンドを実行します。
```
sudo systemctl start oddjobd
sudo authconfig --enablemkhomedir --updateall
```
システムに `oddjob` パッケージが必要でない場合、アンインストールし、PAM 設定ファイルを更新してホームディレクトリが作成されていることを確認します。これを行うには、次の例に示されるようにヘッドノードでコマンドを実行します。
```
sudo yum remove -y oddjob oddjob-mkhomedir
sudo authconfig --enablemkhomedir --updateall
```
# カスタム AMI の問題のトラブルシューティング
このセクションでは、カスタム AMI の問題のトラブルシューティングに役立つヒントを提供します。
カスタム AMI を使用すると、次の警告が表示されます。
```
"validationMessages": [
{
"level": "WARNING",
"type": "CustomAmiTagValidator",
"message": "The custom AMI may not have been created by pcluster. You can ignore this warning if the AMI is shared or copied from another pcluster AMI. If the AMI is indeed not created by pcluster, cluster creation will fail. If the cluster creation fails, please go to https://docs.aws.amazon.com/parallelcluster/latest/ug/troubleshooting.html#troubleshooting-stack-creation-failures for troubleshooting."
},
{
"level": "WARNING",
"type": "AmiOsCompatibleValidator",
"message": "Could not check node AMI ami-0000012345 OS and cluster OS alinux2 compatibility, please make sure they are compatible before cluster creation and update operations."
}
]
```
正しい AMI が使用されていることを確認できる場合、これらの警告は無視できます。
これらの警告を今後表示しない場合は、カスタム AMI に次のタグを付けます。 `my-os`は `alinux2`、、、`alinux2023``ubuntu2404``ubuntu2204`、`rhel8`、または `rhel9` *"3.15.0"* のいずれかで、 は使用中`pcluster`のバージョンです。
```
$ aws ec2 create-tags \
--resources ami-yourcustomAmi \
--tags Key="parallelcluster:version",Value="3.15.0" Key="parallelcluster:os",Value="my-os"
```
# `cfn-hup` が実行していない場合のクラスター更新タイムアウトのトラブルシューティング
`cfn-hup` ヘルパーは、リソースメタデータの変更を検出し、変更が検出された場合に、ユーザーが指定した操作を実行するデーモンです。これは、`UpdateStack` API アクションを介して、実行中の Amazon EC2 インスタンスで構成を更新する方法です。
現在、`cfn-hup` デーモンは `supervisord` によって起動されます。しかし、起動の後、`cfn-hup` プロセスは `supervisord` のコントロールからデタッチされます。`cfn-hup` デーモンが外部攻撃者により強制終了される場合、自動的に再開されることはありません。`cfn-hup` が実行されていない場合、クラスターの更新中に CloudFormation スタックは期待どおりに更新プロセスを開始しますが、更新手順はヘッドノードでアクティブ化されず、最終的にスタックはタイムアウトになります。クラスターログ `/var/log/chef-client` から、更新レシピが呼び出されていないことを確認できます。
**失敗した場合、`cfn-hup` を確認して再起動します**
1. ヘッドノードで、`cfn-hup` が実行されているかどうかを確認します。
```
$ ps aux | grep cfn-hup
```
1. ヘッドノードで `cfn-hup` ログ `/var/log/cfn-hup.log` と `/var/log/supervisord.log` を確認してください。
1. `cfn-hup` が実行されていない場合、次を実行して再起動してみます。
```
$ sudo /opt/parallelcluster/pyenv/versions/cookbook_virtualenv/bin/supervisorctl start cfn-hup
```
# ネットワークのトラブルシューティング
このセクションでは、ネットワークの問題、特に単一のパブリックサブネットの問題でクラスターを処理する場合のトラブルシューティングのヒントを提供します。
## 単一のパブリックサブネットのクラスターに関する問題
1 つのコンピューティングノードから `cloud-init-output.log` を確認します。ノードが Slurm の初期化においてスタックしていることを示す次のようなものが見つかった場合は、DynamoDB VPC エンドポイントが見つからないことが原因である可能性が高いです。DynamoDB エンドポイントを追加しください。詳細については、「[AWS ParallelCluster インターネットアクセスのない 1 つのサブネット内](aws-parallelcluster-in-a-single-public-subnet-no-internet-v3.md)」を参照してください。
```
ruby_block[retrieve compute node info] action run[2022-03-11T17:47:11+00:00] INFO: Processing ruby_block[retrieve compute node info] action run (aws-parallelcluster-slurm::init line 31)
```
# クラスターの更新が `onNodeUpdated` カスタムアクションで失敗した
[`HeadNode`](HeadNode-v3.md)/[`CustomActions`](HeadNode-v3.md#HeadNode-v3-CustomActions)/[`OnNodeUpdated`](HeadNode-v3.md#yaml-HeadNode-CustomActions-OnNodeUpdated) スクリプトが失敗するとき、更新は失敗し、ロールバック時間にスクリプトは実行されません。ロールバックが完了した後に必要なクリーンアップを手動で実行するのはユーザーの責任です。例えば、`OnNodeUpdated` スクリプトが設定ファイルのフィールドのステータスを変更 (`true` から `false` など) して失敗した場合、そのフィールド値を手動で更新前の状態 (`false` から `true` など) に復元する必要があります。詳細については、「[カスタムブートストラップアクション](custom-bootstrap-actions-v3.md)」を参照してください。
# カスタム Slurm 設定でエラーが表示されている
AWS ParallelCluster バージョン 3.6.0 以降、カスタムSlurm設定に含めることで、単一の `prolog`または`epilog`スクリプトをターゲットにすることはできなくなりました。 AWS ParallelCluster バージョン 3.6.0 以降のバージョンでは、カスタム `prolog` および `epilog`スクリプトをそれぞれの `Prolog`および `Epilog`フォルダに配置する必要があります。これらのフォルダは、デフォルトで次を指すように設定されています。
+ `Prolog` は、`/opt/slurm/etc/scripts/prolog.d/` を指します。
+ `Epilog` は、`/opt/slurm/etc/scripts/epilog.d/` を指します。
`90_plcuster_health_check_manager` Prolog スクリプトと `90_pcluster_noop` Epilog スクリプトは保持しておくことをお勧めします。
Slurm は、スクリプトをアルファベットの降順で実行します。`Prolog` および `Epilog` フォルダの両方に、少なくとも 1 つのファイルが含まれている必要があります。詳細については、「[Slurm および `prolog` `epilog`](slurm-prolog-epilog-v3.md)」および「[Slurm 設定のカスタマイズ](slurm-configuration-settings-v3.md)」を参照してください。
# クラスターのアラーム
クラスターのヘルスモニタリングは、最適なパフォーマンスを確保するために不可欠です。 AWS ParallelCluster では、クラスターのヘッドノードで複数の CloudWatch ベースのアラームをモニタリングできます。
このセクションでは、命名規則、アラームをトリガーする特定の条件、推奨されるトラブルシューティング手順など、ヘッドノードにおけるクラスターのアラームについてタイプ別に詳しく説明します。
クラスターのアラームの命名規則は `CLUSTER_NAME-COMPONENT-METRIC` です (例: `mycluster-HeadNode-Cpu`)。
+ `CLUSTER_NAME-HeadNode`: ヘッドノードの全体的なステータスを示します。以下のアラームのうち少なくとも 1 つが該当する場合は、赤色になります。
+ `CLUSTER_NAME-HeadNode-Health`: Amazon EC2 ヘルスチェックエラーが少なくとも 1 つあると、赤色になります。アラームが発生した場合は、「[ステータスチェックに失敗したインスタンスをトラブルシューティングする](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/TroubleshootingInstances.html)」を参照することをお勧めします。
+ `CLUSTER_NAME-HeadNode-Cpu`: CPU 使用率が 90% を超えると、赤色になります。アラームが発生した場合は、`ps -aux --sort=-%cpu | head -n 10` を使用して CPU を最も多く消費しているプロセスを確認します。
+ `CLUSTER_NAME-HeadNode-Mem`: メモリ使用率が 90% を超えると、赤色になります。アラームが発生した場合は、`ps -aux --sort=-%mem | head -n 10` を使用してメモリを最も多く消費しているプロセスを確認します。
+ `CLUSTER_NAME-HeadNode-Disk`: 占有ディスク容量がパス / で 90% を超えると、赤色になります。アラームが発生した場合は、`du -h --max-depth=2 / 2> /dev/null | sort -hr` を使用してスペースの大部分を消費しているフォルダを確認します。
# エラーや障害の原因となる OS 設定変更の解決
AWS ParallelCluster ノードに OS 設定を変更すると、クラスターの作成、更新、またはオペレーションの失敗の原因となるさまざまな問題が発生する可能性があります。このセクションでは、一般的な OS 設定関連の問題を特定して解決するためのガイダンスを提供します。
## OS 設定に関する一般的な問題
### ロケール設定の問題
最も一般的な OS 設定の問題の 1 つは、ロケール設定に関連しています。次のようなエラーが発生した場合:
```
cannot change locale (en_US.utf-8) because it has an invalid name
```
これは通常、次の場合に発生します。
+ `yum` インストールプロセスが失敗し、ロケール設定が不整合な状態のままになった
+ ユーザーがインストールプロセスを途中で終了しました
+ ロケールパッケージがないか、破損しています
#### 診断方法
1. pcluster-admin ユーザーに切り替えることができるかどうかを確認します。
```
$ su - pcluster-admin
```
のようなエラーが表示された場合は`cannot change locale...no such file or directory`、問題が確認されます。
1. 利用可能なロケールを確認します。
```
$ localedef --list
```
空のリストが返されるか、デフォルトのロケールが含まれていない場合、ロケール設定は壊れています。
1. 最後の`yum`コマンドを確認します。
```
$ yum history
$ yum history info #ID
```
最後の ID に `Return-Code: Success` が含まれていない場合、インストール後のスクリプトが正常に実行されていない可能性があります。
#### 解決方法
言語パックを再インストールしてロケールを再構築します。
```
$ sudo yum reinstall glibc-all-langpacks
```
再構築後、以下を実行して問題が修正されていることを確認します。
```
$ su - pcluster-admin
```
エラーや警告が表示されない場合、問題は解決されています。
### OS パッケージの競合
カスタムパッケージをインストールしたり、システムパッケージを変更したりすると、適切なクラスターオペレーションを妨げる競合が発生する可能性があります。
#### 診断方法
1. chef-client ログでパッケージ関連のエラーを確認します。
```
$ less /var/log/chef-client.log
```
1. cfn-init ログでパッケージの依存関係の競合を探します。
```
$ less /var/log/cfn-init.log
```
#### 解決方法
1. 特定のパッケージが原因で問題が発生した場合は、再インストールしてみてください。
```
$ sudo yum reinstall package-name
```
1. 依存関係の競合の場合、競合するパッケージを削除する必要がある場合があります。
```
$ sudo yum remove conflicting-package
```
1. 問題が解決しない場合は、 `pcluster build-image` コマンドを使用して必要なパッケージをプリインストールしたカスタム AMI を作成することを検討してください。詳細については、「[AWS ParallelCluster AMI のカスタマイズ](custom-ami-v3.md)」を参照してください。
### システム設定ファイルの変更
重要なシステム設定ファイルを変更すると、特にこれらのファイルが によって管理されている場合、クラスターの障害が発生する可能性があります AWS ParallelCluster。
#### 診断方法
1. 特定の設定ファイルに関する chef-client ログのエラーを確認します。
```
$ grep -i "config" /var/log/chef-client.log
```
1. 設定ファイルでアクセス許可または構文エラーを探します。
```
$ less /var/log/cfn-init.log
```
#### 解決方法
1. 変更された設定ファイルを元の状態に復元します。
```
$ sudo cp /etc/file.conf.bak /etc/file.conf
```
1. システム設定ファイルを永続的に変更する必要がある場合は、ファイルを直接変更するのではなく、カスタムブートストラップアクションを使用します。
```
HeadNode:
CustomActions:
OnNodeConfigured:
Script: s3://bucket-name/config-script.sh
```
詳細については、「[カスタムブートストラップアクション](custom-bootstrap-actions-v3.md)」を参照してください。
1. システムファイルに対して直接行う必要がある設定変更については、カスタム AMI の作成を検討してください。詳細については、「[AWS ParallelCluster AMI のカスタマイズ](custom-ami-v3.md)」を参照してください。
### カーネルの更新と互換性の問題
カーネルの更新により、特定の AWS サービス、特に Amazon FSx for Lustre との互換性の問題が発生する可能性があります。
#### 診断方法
1. カーネルの更新が適用されているかどうかを確認します。
```
$ uname -r
```
1. ログで Amazon FSx マウントの失敗を探します。
```
$ grep -i "fsx" /var/log/chef-client.log
```
#### 解決方法
1. Ubuntu 22.04 では、そのカーネルに Amazon FSx クライアントがないため、最新のカーネルに更新しないでください。詳細については、「[オペレーティングシステムに関する考慮事項](operating-systems-v3.md#OS-Consideration-v3)」を参照してください。
1. カーネルをすでに更新していて、問題が発生した場合は、互換性のあるカーネルバージョンにダウングレードすることを検討してください。
```
$ sudo apt install linux-image-previous-version
```
1. カーネルを永続的にカスタマイズするには、必要な特定のカーネルバージョンを使用してカスタム AMI を作成します。詳細については、「[AWS ParallelCluster AMI のカスタマイズ](custom-ami-v3.md)」を参照してください。
## OS 設定変更のベストプラクティス
OS 設定を変更する際の問題を最小限に抑えるには:
1. **カスタムブートストラップアクションを使用する**: システムファイルを直接変更する代わりに、 `OnNodeStart`または `OnNodeConfigured`スクリプトを使用して制御された方法で変更を行います。詳細については、「[カスタムブートストラップアクション](custom-bootstrap-actions-v3.md)」を参照してください。
1. **カスタム AMIs**: OS を大幅に変更するには、実行中のインスタンスを変更するの`pcluster build-image`ではなく、 を使用してカスタム AMI を作成します。詳細については、「[AWS ParallelCluster AMI のカスタマイズ](custom-ami-v3.md)」を参照してください。
1. **最初に変更**をテストする: 本番稼働用クラスターに変更を適用する前に、小さなテストクラスターでテストして互換性を確認します。
1. **ドキュメントの変更**: トラブルシューティングを容易にするために行われたすべての OS 設定の変更を追跡します。
1. **バックアップ設定ファイル**: システム設定ファイルを変更する前に、バックアップを作成します。
```
$ sudo cp /etc/file.conf /etc/file.conf.bak
```
1. **変更後のログの確認**: OS 設定を変更した後、エラーがないかログを確認します。
```
$ less /var/log/cfn-init.log
$ less /var/log/chef-client.log
```
これらのガイドラインに従うことで、クラスターの障害を引き起こす OS 設定変更のリスクを最小限に抑え、発生した問題をより効果的にトラブルシューティングできます。