翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。
# AWS ParallelCluster トラブルシューティング
AWS ParallelCluster コミュニティは、[AWS ParallelCluster GitHub Wiki で多くのトラブルシューティングのヒントを提供する Wiki](https://github.com/aws/aws-parallelcluster/wiki/) ページを保持しています。既知の問題のリストは、[「Known issues」](https://github.com/aws/aws-parallelcluster/wiki#known-issues-)(既知の問題) を参照してください。
**Topics**
+ [
## ログの取得と保存
](#retrieving-and-preserve-logs)
+ [
## スタックデプロイ時のトラブルシューティング
](#troubleshooting-stack-creation-failures)
+ [
## マルチキューモードクラスターでの問題のトラブルシューティング
](#multiple-queue-mode)
+ [
## シングルキューモードのクラスターにおける問題のトラブルシューティング
](#troubleshooting-issues-in-single-queue-clusters)
+ [
## プレイスメントグループとインスタンスの起動に関する問題
](#placement-groups-and-instance-launch-issues)
+ [
## 置き換えられないディレクトリ
](#directories-cannot-be-replaced)
+ [
## Amazon DCV の問題のトラブルシューティング
](#nice-dcv-troubleshooting)
+ [
## AWS Batch 統合によるクラスターの問題のトラブルシューティング
](#clusters-with-aws-batch-integration)
+ [
## リソースの作成に失敗したときのトラブルシューティング
](#troubleshooting-resource-fails-to-create)
+ [
## IAM ポリシーのサイズに関する問題のトラブルシューティング
](#troubleshooting-policy-size-issues)
+ [
## 追加のサポート
](#getting-support)
## ログの取得と保存
ログは問題を解決するための有用なリソースです。ログを使用して AWS ParallelCluster リソースの問題をトラブルシューティングする前に、まずクラスターログのアーカイブを作成する必要があります。[AWS ParallelCluster GitHub Wiki](https://github.com/aws/aws-parallelcluster/wiki/) の[クラスターのログのアーカイブを作成する](https://github.com/aws/aws-parallelcluster/wiki/Creating-an-Archive-of-a-Cluster's-Logs) トピックで説明されている手順に従って、このプロセスを開始します。
稼働中のクラスターの 1 つに問題が発生した場合、トラブルシューティングを開始する前に ``pcluster stop` ` コマンドを実行してクラスターを `STOPPED` 状態にしてください。これにより、予想外のコストが発生することを防ぐことができます。
`pcluster` が機能しなくなったクラスターを削除したい場合は、``pcluster delete` —keep-logs ` コマンドを実行します。このコマンドを実行すると、クラスターは削除されますが、Amazon CloudWatch に保存されているロググループは保持されます。このコマンドの詳細については、「[`pcluster delete`](pcluster.delete.md)」を参照してください。
## スタックデプロイ時のトラブルシューティング
クラスターの作成に失敗し、スタックの作成がロールバックされる場合は、以下のログファイルを参照して問題を診断します。これらのログの中から `ROLLBACK_IN_PROGRESS` の出力を探します。失敗した場合のは次のように表示されます。
```
$ pcluster create mycluster
Creating stack named: parallelcluster-mycluster
Status: parallelcluster-mycluster - ROLLBACK_IN_PROGRESS
Cluster creation failed. Failed events:
- AWS::EC2::Instance MasterServer Received FAILURE signal with UniqueId i-07af1cb218dd6a081
```
この問題を診断するには、`--norollback` フラグを含む [`pcluster create`](pluster.create.md) を使用してクラスターを再度作成します。次に、クラスターに SSH 接続します。
```
$ pcluster create mycluster --norollback
...
$ pcluster ssh 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` からの出力も含まれます。通常、この種の問題のトラブルシューティングには、このログを見る必要はありません。
## マルチキューモードクラスターでの問題のトラブルシューティング
このセクションは、Slurmジョブスケジューラで AWS ParallelCluster バージョン 2.9.0 以降を使用してインストールされたクラスターに関連しています。マルチキューモードの詳細については、「[マルチキューモード](queue-mode.md)」を参照してください。
**Topics**
+ [
### キーログ
](#key-logs)
+ [
### **ノードの初期化に関する問題のトラブルシューティング**
](#troubleshooting-node-initialization-issues)
+ [
### **予期しないノードの置換や終了のトラブルシューティング**
](#troubleshooting-unexpected-node-replacements-and-terminations)
+ [
### **問題のあるインスタンスやノードの置換、終了、電源オフ**
](#replacing-terminating-or-powering-down-problematic-instances-and-nodes)
+ [
### **その他の既知のノードやジョブの問題のトラブルシューティング**
](#troubleshooting-other-known-node-and-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/cloud-init-output.log`
これは [cloud-init](https://cloudinit.readthedocs.io/) のログです。インスタンスのセットアップ時に実行されたすべてのコマンドが含まれています。初期化時の問題のトラブルシューティングに役立ちます。
`/var/log/parallelcluster/computemgtd`
これが `computemgtd` のログです。各コンピュートノード上で動作し、ヘッドノード上の `clustermgtd` デーモンがオフラインになるレアなケースでノードをモニタリングします。予期せぬ終了の問題のトラブルシューティングに役立ちます。
`/var/log/slurmd.log`
これは Slurm コンピュートデーモンのログです。初期化やコンピュートの不具合に関するトラブルシューティングに役立ちます。
### **ノードの初期化に関する問題のトラブルシューティング**
このセクションでは、ノードの初期化に関するトラブルを解決する方法について説明します。これには、ノードが起動しない、電源が入らない、またはクラスターが参加できない、などの問題が含まれます。
**ヘッドノード:**
該当するログ:
+ `/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` ログにエラーメッセージが表示されます。クラスターの構成でプリインストールまたはポストインストールのスクリプトが指定されている場合、スクリプトが正常に実行されていることをログメッセージで再確認します。
クラスターが作成されると、ヘッドノードはコンピュートノードがクラスターに参加するのを待ってからクラスターに参加する必要があります。そのため、コンピュートノードがクラスターに参加できないと、ヘッドノードも失敗してしまいます。このような問題を解決するためには、使用しているコンピュートノートの種類に応じて、次の手順のいずれかを実行します。
**動的コンピュートノード:**
+ `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 が表示されます。さらに、特定のインスタンスに対応するセットアップログを確認することができます。
+ **コンピュートノード**
+ **該当するログ:**
+ `/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` のログを確認してください。
### **予期しないノードの置換や終了のトラブルシューティング**
このセクションでは、ノードに関連する問題、特にノードが予期せず置換されたり終了したりした場合のトラブルシューティング方法について引き続き説明します。
+ **該当するログ:**
+ `/var/log/parallelcluster/clustermgtd` (ヘッドノード)
+ `/var/log/slurmctld.log` (ヘッドノード)
+ `/var/log/parallelcluster/computemgtd` (コンピューティングノード)
+ **予期せず置換または終了したノード**
+ `clustermgtd` のログ (`/var/log/parallelcluster/clustermgtd`) で、`clustermgtd` がノードの交換や終了のアクションをとったかどうかを確認します。なお、`clustermgtd` は通常のノードメンテナンスのアクションをすべて行います。
+ `clustermgtd` がノードを置換または終了させた場合、なぜそのアクションがノードに対して行われたのかを詳細に説明するメッセージが必要です。スケジューラ関連の理由 (例えば、ノードが `DOWN` にあるため) の場合は、`slurmctld` ログで確認してください。理由が Amazon EC2 に関連するものであれば、置換を必要とする Amazon EC2 に関連する問題の詳細を示す情報メッセージが表示されるはずです。
+ `clustermgtd` がノードを終了しなかった場合は、まず、これが Amazon EC2 による予期された終了であるかどうか、具体的にはスポット終了かどうかを確認します。Compute ノードで`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-xyz --disable-api-termination
```
+ このコマンドで、ノードのコンソール出力を取得します。
```
aws ec2 get-console-output --instance-id i-xyz --output text
```
### **問題のあるインスタンスやノードの置換、終了、電源オフ**
+ **該当するログ:**
+ `/var/log/parallelcluster/clustermgtd` (ヘッドノード)
+ `/var/log/parallelcluster/slurm_suspend.log` (ヘッドノード)
+ 通常、`clustermgtd` は期待されるすべてのインスタンス終了アクションを処理します。`clustermgtd` ログを見て、ノードの置換または終了に失敗した理由を確認します。
+ [`scaledown_idletime`](scaling-section.md#scaledown-idletime) に失敗した動的ノードの場合、`SuspendProgram` ログで `SuspendProgram` が `slurmctld` から特定のノードを引数として呼び出されたかどうかを確認します。なお、`SuspendProgram` は実際には何のアクションもしません。呼び出されたときだけログに記録されます。インスタンスの終了や `NodeAddr` のリセットは全て `clustermgtd` が行います。Slurm は `SuspendTimeout` の後、自動的にノードを `POWER_SAVING` 状態に戻します。
### **その他の既知のノードやジョブの問題のトラブルシューティング**
もう 1 つの既知の問題は、ジョブの割り当てやスケーリングの決定に失敗 AWS ParallelCluster する可能性があることです。このタイプの問題では、 はSlurm指示に従ってリソース AWS ParallelCluster を起動、終了、または維持します。これらの問題については、`slurmctld` ログを確認してトラブルシューティングを行ってください。
## シングルキューモードのクラスターにおける問題のトラブルシューティング
**注記**
バージョン 2.11.5 AWS ParallelCluster 以降、 は SGEまたは スTorqueケジューラの使用をサポートしていません。
ここでは、次の 2 つの構成のうち、マルチキューモードを持たないクラスターに適用します。
+ 2.9.0 より前の AWS ParallelCluster バージョンと、SGE、Torque、または Slurmジョブスケジューラを使用して起動されました。
+ AWS ParallelCluster バージョン 2.9.0 以降および SGEまたは Torque ジョブスケジューラを使用して起動しました。
**Topics**
+ [
### キーログ
](#key-logs-1)
+ [
### **起動および参加オペレーションの失敗のトラブルシューティング**
](#troubleshooting-failed-launch-and-join-operations)
+ [
### スケーリング問題のトラブルシューティング
](#troubleshooting-scaling-issues)
+ [
### 他のクラスター関連の問題のトラブルシューティング
](#troubleshooting-other-cluster-related-issues)
### キーログ
次のログファイルは、ヘッドノードのキーログです。
AWS ParallelCluster バージョン 2.9.0 以降の場合:
`/var/log/chef-client.log`
これは CINC (chef) のクライアントログです。CINC で実行されたすべてのコマンドが含まれています。初期化時の問題のトラブルシューティングに役立ちます。
すべての AWS ParallelCluster バージョン:
`/var/log/cfn-init.log`
これが `cfn-init` のログです。インスタンスのセットアップ時に実行されたすべてのコマンドが含まれているため、初期化に関する問題のトラブルシューティングに役立ちます。詳細については、[「cfn-init」](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/cfn-init.html)を参照してください。
`/var/log/clustermgtd.log`
これは Slurm スケジューラの `clustermgtd` のログです。`clustermgtd` はほとんどのクラスターオペレーションのアクションを管理する集中型デーモンとして動作します。起動、終了、クラスターの動作の問題のトラブルシューティングに役立ちます。
`/var/log/jobwatcher`
これは、SGE およびTorque スケジューラの `jobwatcher` のログです。`jobwatcher` はスケジューラキューをモニターし、Auto Scaling グループを更新します。ノードのスケールアップに関する問題のトラブルシューティングに役立ちます。
`/var/log/sqswatcher`
これは SGE および Torque スケジューラの `sqswatcher` のログです。`sqswatcher` は、初期化に成功したコンピューティングインスタンスから送られてくるインスタンス準備イベントを処理します。また、スケジューラの構成にコンピュートノードを追加します。このログは、ノードがクラスターへの参加に失敗した場合のトラブルシューティングに役立ちます。
以下は、コンピュートノードのキーログです。
AWS ParallelCluster バージョン 2.9.0 以降
`/var/log/cloud-init-output.log`
これは Cloud init のログです。インスタンスのセットアップ時に実行されたすべてのコマンドが含まれています。初期化時の問題のトラブルシューティングに役立ちます。
AWS ParallelCluster 2.9.0 より前のバージョン
`/var/log/cfn-init.log`
これは CloudFormation のログです。インスタンスのセットアップ時に実行されたすべてのコマンドが含まれています。初期化に関する問題のトラブルシューティングに役立ちます。
すべてのバージョン
`/var/log/nodewatcher`
これは `nodewatcher` のログです。SGE および Torque スケジューラを使用している場合に各コンピューティングノード上で動作する `nodewatcher` デーモンです。アイドル状態のノードはスケールダウンします。このログは、リソースのスケールダウンに関する問題に役立ちます。
### **起動および参加オペレーションの失敗のトラブルシューティング**
+ **該当するログ:**
+ `/var/log/cfn-init-cmd.log` (ヘッドノードとコンピュートノード)
+ `/var/log/sqswatcher` (ヘッドノード)
+ ノードの起動に失敗した場合は、`/var/log/cfn-init-cmd.log` ログで特定のエラーメッセージを確認します。通常、ノードの起動の失敗はセットアップの失敗が原因です。
+ スケジューラの設定に成功したにもかかわらず、コンピュートノードがスケジューラの設定に参加できなかった場合、`/var/log/sqswatcher` ログを確認し、`sqswatcher` がイベントを処理したかどうかを確認します。通常、これらの問題は、`sqswatcher` がイベントを処理していないことが原因です。
### スケーリング問題のトラブルシューティング
+ **該当するログ:**
+ `/var/log/jobwatcher` (ヘッドノード)
+ `/var/log/nodewatcher` (コンピュートノード)
+ **スケールアップの問題:**ヘッドノードの場合、`/var/log/jobwatcher` ログを確認し、`jobwatcher` デーモンが必要なノード数を適切に計算し、Auto Scaling グループを更新したかどうかを確認します。なお、`jobwatcher` はスケジューラのキューをモニターし、Auto Scaling グループを更新します。
+ **スケールダウンの問題:**コンピュートノードの場合、問題のノードの `/var/log/nodewatcher` ログを確認し、ノードがスケールダウンした理由を確認します。`nodewatcher` デーモンは、コンピュートノードがアイドル状態になるとスケールダウンします。
### 他のクラスター関連の問題のトラブルシューティング
ラージスケールのクラスター、特に 500 台以上のコンピュートノードを持つクラスターでは、コンピュートノートがランダムに故障するという問題があります。この問題は、シングルキュークラスターのスケーリングアーキテクチャの制限に関連しています。大規模なクラスターを使用し、 AWS ParallelCluster バージョン v2.9.0 以降を使用していて、 を使用していてSlurm、この問題を回避するには、複数のキューモードがサポートされているクラスターにアップグレードして切り替える必要があります。[`pcluster-config convert`](pcluster-config.md#pcluster-config-convert) を実行することで可能になります。
ultra-large-scaleクラスターの場合、システムに追加のチューニングが必要になる場合があります。詳細については、 にお問い合わせください サポート。
## プレイスメントグループとインスタンスの起動に関する問題
ノード間のレイテンシーを最小にするには、*プレースメントグループ*を使用します。プレイスメントグループにより、確実にインスタンスが同じネットワーキングバックボーンに配置されます。リクエスト時に十分な数のインスタンスが用意されていない場合は、`InsufficientInstanceCapacity` エラーが返ります。クラスタープレイスメントグループを使用する際にこのエラーが発生する可能性を減らすために、[`placement_group`](cluster-definition.md#placement-group) パラメータを `DYNAMIC` に、[`placement`](cluster-definition.md#placement) パラメータを `compute` に設定します。
高性能な共有ファイルシステムが必要な場合は、[FSx for Lustre](https://aws.amazon.com/fsx/lustre/) の使用をご検討ください。
ヘッドノードがプレースメントグループに含まれている必要がある場合は、ヘッドノードとすべてのコンピュートノードに同じインスタンスタイプとサブネットを使用します。これにより、[`compute_instance_type`](cluster-definition.md#compute-instance-type) パラメータは [`master_instance_type`](cluster-definition.md#master-instance-type) パラメータと同じ値になり、[`placement`](cluster-definition.md#placement) パラメータは `cluster` に設定され、[`compute_subnet_id`](vpc-section.md#compute-subnet-id) パラメータは指定されません。この設定では、[`master_subnet_id`](vpc-section.md#master-subnet-id) パラメータの値がコンピュートノードに使用されます。
詳細については、「*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)」を参照してください。
## 置き換えられないディレクトリ
以下のディレクトリはノード間で共有され、置き換えることはできません。
`/home`
これには、デフォルトユーザーのホームフォルダ (Amazon Linux では `/home/ec2_user`、CentOS では `/home/centos`、Ubuntu では `/home/ubuntu`）が含まれます。
`/opt/intel`
これには、Intel MPI、Intel Parallel Studio、および関連ファイルが含まれます。
`/opt/sge`
バージョン 2.11.5 AWS ParallelCluster 以降、 は SGEまたは スTorqueケジューラの使用をサポートしていません。
これには、Son of Grid Engine および関連ファイルが含まれます。(条件付き、[`scheduler`](cluster-definition.md#scheduler)` = sge` の場合のみ)
`/opt/slurm`
これには、Slurm Workload Manager および関連ファイルが含まれます。(条件付き、[`scheduler`](cluster-definition.md#scheduler)` = slurm` の場合のみ)
`/opt/torque`
バージョン 2.11.5 AWS ParallelCluster 以降、 は SGEまたは スTorqueケジューラの使用をサポートしていません。
これには、Torque Resource Manager および関連ファイルが含まれます。(条件付き、[`scheduler`](cluster-definition.md#scheduler)` = torque` の場合のみ)
## Amazon DCV の問題のトラブルシューティング
**Topics**
+ [
### Amazon DCV のログ
](#nice-dcv-troubleshooting-logs)
+ [
### Amazon DCV インスタンスタイプメモリ
](#nice-dcv-troubleshooting-memory)
+ [
### Ubuntu の Amazon DCV の問題
](#nice-dcv-troubleshooting-modules)
### Amazon DCV のログ
Amazon DCV のログは `/var/log/dcv/` ディレクトリのファイルに書き込まれます。これらのログを確認することは、問題の解決に役立ちます。
### Amazon DCV インスタンスタイプメモリ
インスタンスタイプには、Amazon DCV を実行するために、少なくとも 1.7 ギビバイト (GiB) の RAM が必要です。Nano および micro のインスタンスタイプには、Amazon DCV を実行するのに十分なメモリがありません。
### Ubuntu の Amazon DCV の問題
Ubuntu の 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 ケジューラ統合のクラスターに関連しています。
### ヘッドノードの問題
ヘッドノードに関連するセットアップの問題は、シングルキューのクラスターと同様にトラブルシューティングが可能です。これらの問題を解決する方法の詳細については、「[シングルキューモードのクラスターにおける問題のトラブルシューティング](#troubleshooting-issues-in-single-queue-clusters)」を参照してください。
### AWS Batch マルチノード並列ジョブの送信に関する問題
をジョブスケジューラ AWS Batch として使用するときにマルチノード並列ジョブの送信に問題がある場合は、 AWS ParallelCluster バージョン 2.5.0 にアップグレードする必要があります。それが不可能な場合は、トピック「[Self patch a cluster used for submitting multi-node parallel jobs through AWS Batch](https://github.com/aws/aws-parallelcluster/wiki/Self-patch-a-Cluster-Used-for-Submitting-Multi-node-Parallel-Jobs-through-AWS-Batch)」で紹介されている回避策を使用できます。
### コンピューティングの問題
AWS Batch は、サービスのスケーリングとコンピューティングの側面を管理します。コンピューティング関連の問題が発生した場合は、 AWS Batch [トラブルシューティング](https://docs.aws.amazon.com/batch/latest/userguide/troubleshooting.html)ドキュメントを参照してください。
### ジョブの失敗
ジョブが失敗した場合は、``awsbout`` コマンドを実行してジョブの出力を取得することができます。また、``awsbstat` -d` コマンドを実行して、Amazon CloudWatch が保存しているジョブログへのリンクを取得することもできます。
## リソースの作成に失敗したときのトラブルシューティング
このセクションは、クラスターリソースが作成に失敗した場合に関連しています。
リソースの作成に失敗すると、ParallelCluster は次のようなエラーメッセージを返します。
```
pcluster create -c config my-cluster
Beginning cluster creation for cluster: my-cluster
WARNING: The instance type 'p4d.24xlarge' cannot take public IPs. Please make sure that the subnet with
id 'subnet-1234567890abcdef0' has the proper routing configuration to allow private IPs reaching the
Internet (e.g. a NAT Gateway and a valid route table).
WARNING: The instance type 'p4d.24xlarge' cannot take public IPs. Please make sure that the subnet with
id 'subnet-1234567890abcdef0' has the proper routing configuration to allow private IPs reaching the Internet
(e.g. a NAT Gateway and a valid route table).
Info: There is a newer version 3.0.3 of AWS ParallelCluster available.
Creating stack named: parallelcluster-my-cluster
Status: parallelcluster-my-cluster - ROLLBACK_IN_PROGRESS
Cluster creation failed. Failed events:
- AWS::CloudFormation::Stack MasterServerSubstack Embedded stack
arn:aws:cloudformation:region-id:123456789012:stack/parallelcluster-my-cluster-MasterServerSubstack-ABCDEFGHIJKL/a1234567-b321-c765-d432-dcba98766789
was not successfully created:
The following resource(s) failed to create: [MasterServer].
- AWS::CloudFormation::Stack parallelcluster-my-cluster-MasterServerSubstack-ABCDEFGHIJKL The following resource(s) failed to create: [MasterServer].
- AWS::EC2::Instance MasterServer 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)
}
```
たとえば、前のコマンドレスポンスにステータスメッセージが表示される場合は、現在の vCPU 制限を超えないインスタンスタイプを使用するか、vCPU 容量の追加をリクエストする必要があります。
CloudFormation コンソールを使用して `"Cluster creation failed"` ステータスに関する情報を確認することもできます。
コンソールから CloudFormation のエラーメッセージを表示します。
1. にログイン AWS マネジメントコンソール し、[https://console.aws.amazon.com/cloudformation](https://console.aws.amazon.com/cloudformation/) に移動します。
1. スタック名は parallelcluster-*cluster\$1name* を選択します。
1. **[イベント]** タブを選択します。
1. **[論理 ID]** でリソースイベントのリストをスクロールして、作成に失敗したリソースの **[ステータス]** を確認します。サブタスクの作成に失敗した場合は、失敗したリソースイベントを見つけるために逆算します。
1. AWS CloudFormation エラーメッセージの例:
```
2022-02-07 11:59:14 UTC-0800 MasterServerSubstack CREATE_FAILED Embedded stack
arn:aws:cloudformation:region-id:123456789012:stack/parallelcluster-my-cluster-MasterServerSubstack-ABCDEFGHIJKL/a1234567-b321-c765-d432-dcba98766789
was not successfully created: The following resource(s) failed to create: [MasterServer].
```
## IAM ポリシーのサイズに関する問題のトラブルシューティング
ロールにアタッチされた管理ポリシーのクォ[ータを確認するには、「IAM と AWS STS クォータ」、「名前の要件」、および「文字制限](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_iam-quotas.html)」を参照してください。管理ポリシーのサイズがクォータを超える場合は、ポリシーを 2 つ以上のポリシーに分割してください。IAM ロールにアタッチされたポリシー数のクォータを超えた場合は、追加のロールを作成し、そのロール間でポリシーを配布してクォータを満たすようにします。
## 追加のサポート
既知の問題点の一覧は、[GitHub Wiki](https://github.com/aws/aws-parallelcluster/wiki) のメインページまたは[「問題」](https://github.com/aws/aws-parallelcluster/issues)ページを参照してください。緊急の問題については、 に問い合わせる サポート か、[新しい GitHub の問題](https://github.com/aws/aws-parallelcluster/issues)を開きます。