AWS ParallelCluster のトラブルシューティング - AWS ParallelCluster
ログの取得と保存スタックデプロイ時のトラブルシューティングマルチキューモードクラスターでの問題のトラブルシューティングシングルキューモードのクラスターにおける問題のトラブルシューティングプレイスメントグループとインスタンスの起動に関する問題置き換えられないディレクトリAmazon DCV の問題のトラブルシューティングAWS Batch 統合されたクラスターにおける問題のトラブルシューティングリソースの作成に失敗したときのトラブルシューティングIAM ポリシーのサイズに関する問題のトラブルシューティング追加のサポート

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

AWS ParallelCluster のトラブルシューティング

AWS ParallelCluster コミュニティは、AWS ParallelCluster GitHub Wiki で多くのトラブルシューティングのヒントを提供する Wiki ページを管理しています。既知の問題のリストは、「Known issues」(既知の問題) を参照してください。

ログの取得と保存

ログは問題を解決するための有用なリソースです。ログを使用して AWS ParallelCluster リソースの問題をトラブルシューティングする前に、まずクラスターログのアーカイブを作成する必要があります。AWS ParallelCluster GitHub Wiki のクラスターのログのアーカイブを作成する トピックで説明されている手順に従って、このプロセスを開始します。

稼働中のクラスターの 1 つに問題が発生した場合、トラブルシューティングを開始する前に pcluster stop <cluster_name> コマンドを実行してクラスターを STOPPED 状態にしてください。これにより、予想外のコストが発生することを防ぐことができます。

pcluster が機能しなくなったクラスターを削除したい場合は、pcluster delete —keep-logs <cluster_name> コマンドを実行します。このコマンドを実行すると、クラスターは削除されますが、Amazon CloudWatch に保存されているロググループは保持されます。このコマンドの詳細については、「pcluster delete」を参照してください。

スタックデプロイ時のトラブルシューティング

クラスターの作成に失敗し、スタックの作成がロールバックされる場合は、以下のログファイルを参照して問題を診断します。これらのログの中から 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 を使用してクラスターを再度作成します。次に、クラスターに SSH 接続します。

$ pcluster create mycluster --norollback
...
$ pcluster ssh mycluster

ヘッドノードにログインすると、エラーの原因を突き止めるための 3 つの主要なログファイルが見つかります。

  • /var/log/cfn-init.log は cfn-init のスクリプトのログです。最初に、このログを確認してください。このログには Command chef failed のようなエラーが表示される可能性があります。エラーメッセージの詳細については、この行の直前の行を参照してください。詳細については、「cfn-init」を参照してください。

  • /var/log/cloud-init.log は cloud-init のログです。cfn-init.log に何も表示されない場合は、次にこのログを確認してください。

  • /var/log/cloud-init-output.log は cloud-init で実行されたコマンドの出力です。これには cfn-init からの出力も含まれます。通常、この種の問題のトラブルシューティングには、このログを見る必要はありません。

マルチキューモードクラスターでの問題のトラブルシューティング

このセクションは、Slurm ジョブスケジューラで AWS ParallelCluster バージョン 2.9.0 以降を使用してインストールしたクラスターに関連しています。マルチキューモードの詳細については、「マルチキューモード」を参照してください。

キーログ

次の表は、ヘッドノードのキーログの概要を示したものです。

/var/log/cfn-init.log

これは AWS CloudFormation の init ログです。インスタンスのセットアップ時に実行されたすべてのコマンドが含まれています。初期化時の問題のトラブルシューティングに役立ちます。

/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 コントロールデーモンのログです。AWS ParallelCluster はスケーリングの決定をしません。むしろ、Slurm の要求を満たすためにリソースの送信を試みます。スケーリングや割り当ての問題、ジョブ関連の問題、スケジューラ関連の起動や終了の問題などに有効です。

コンピュートノードのキーノートは次のとおりです。

/var/log/cloud-init-output.log

これは cloud-init のログです。インスタンスのセットアップ時に実行されたすべてのコマンドが含まれています。初期化時の問題のトラブルシューティングに役立ちます。

/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) を確認することで、Slurm がノードを使って ResumeProgram を呼び出そうとしたことがあるかどうかを調べることができます)

  • なお、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 によって予期された終了であるかどうか、より具体的には一時的な終了であるかどうかを確認します。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 に失敗した動的ノードの場合、SuspendProgram ログで SuspendProgram が slurmctld から特定のノードを引数として呼び出されたかどうかを確認します。なお、SuspendProgram は実際には何のアクションもしません。呼び出されたときだけログに記録されます。インスタンスの終了や NodeAddr のリセットは全て clustermgtd が行います。Slurm は SuspendTimeout の後、自動的にノードを POWER_SAVING 状態に戻します。

その他の既知のノードやジョブの問題のトラブルシューティング

もうひとつの既知の問題は、AWS ParallelCluster がジョブの割り当てやスケーリングの決定に失敗することです。このタイプの発行では、Slurm の指示に従って、リソースの起動、AWS ParallelCluster の終了、または維持のみが行われます。これらの問題については、slurmctld ログを確認してトラブルシューティングを行ってください。

シングルキューモードのクラスターにおける問題のトラブルシューティング

注記

バージョン 2.11.5 以降、AWS ParallelCluster は SGE または Torque スケジューラの使用をサポートしていません。

ここでは、次の 2 つの構成のうち、マルチキューモードを持たないクラスターに適用します。

  • AWS ParallelCluster のバージョンが 2.9.0 より前で、SGE、Torque、Slurm のジョブスケジューラを使用して起動

  • AWS ParallelCluster のバージョンが 2.9.0 以降で、SGE または Torque のジョブスケジューラを使用して起動

キーログ

次のログファイルは、ヘッドノードのキーログです。

AWS ParallelCluster バージョン 2.9.0 以降:

/var/log/chef-client.log

これは CINC (chef) のクライアントログです。CINC で実行されたすべてのコマンドが含まれています。初期化時の問題のトラブルシューティングに役立ちます。

AWS ParallelCluster の全バージョンが対象:

/var/log/cfn-init.log

これが cfn-init のログです。インスタンスのセットアップ時に実行されたすべてのコマンドが含まれているため、初期化に関する問題のトラブルシューティングに役立ちます。詳細については、「cfn-init」を参照してください。

/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 を実行することで可能になります。

ラージスケールのクラスターでは、システムに追加のチューニングが必要な場合があります。詳細については、「サポート」にお問い合わせください。

プレイスメントグループとインスタンスの起動に関する問題

ノード間のレイテンシーを最小にするには、プレースメントグループを使用します。プレイスメントグループにより、確実にインスタンスが同じネットワーキングバックボーンに配置されます。リクエスト時に十分な数のインスタンスが用意されていない場合は、InsufficientInstanceCapacity エラーが返ります。クラスタープレイスメントグループを使用する際にこのエラーが発生する可能性を減らすために、placement_group パラメータを DYNAMIC に、placement パラメータを compute に設定します。

高性能な共有ファイルシステムが必要な場合は、FSx for Lustre の使用をご検討ください。

ヘッドノードがプレースメントグループに含まれている必要がある場合は、ヘッドノードとすべてのコンピュートノードに同じインスタンスタイプとサブネットを使用します。これにより、compute_instance_type パラメータは master_instance_type パラメータと同じ値になり、placement パラメータは cluster に設定され、compute_subnet_id パラメータは指定されません。この設定では、master_subnet_id パラメータの値がコンピュートノードに使用されます。

詳細については、「Amazon EC2 ユーザーガイド」の「インスタンスの起動に関する問題のトラブルシューティング」と「プレイスメントグループの役割と制限」を参照してください。

置き換えられないディレクトリ

以下のディレクトリはノード間で共有され、置き換えることはできません。

/home

これには、デフォルトユーザーのホームフォルダ (Amazon Linux では /home/ec2_user、CentOS では /home/centos、Ubuntu では /home/ubuntu）が含まれます。

/opt/intel

これには、Intel MPI、Intel Parallel Studio、および関連ファイルが含まれます。

/opt/sge
注記

バージョン 2.11.5 以降は、SGE または Torque スケジューラの使用は AWS ParallelCluster ではサポートされていません。

これには、Son of Grid Engine および関連ファイルが含まれます。(条件付き、scheduler = sge の場合のみ)

/opt/slurm

これには、Slurm Workload Manager および関連ファイルが含まれます。(条件付き、scheduler = slurm の場合のみ)

/opt/torque
注記

バージョン 2.11.5 以降は、SGE または Torque スケジューラの使用は AWS ParallelCluster ではサポートされていません。

これには、Torque Resource Manager および関連ファイルが含まれます。(条件付き、scheduler = torque の場合のみ)

Amazon DCV の問題のトラブルシューティング

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 ターミナルで [編集] メニューを選択します。

    2. [設定]、[プロファイル] の順に選択します。

    3. [コマンド] を選択し、[ログインシェルとしてコマンドを実行] を選択します。

    4. [新しいターミナル] を開きます。

  • コマンドラインを使用して、使用可能なプロファイルを取得します。

    $ source /etc/profile && source $HOME/.bashrc

AWS Batch 統合されたクラスターにおける問題のトラブルシューティング

このセクションは、AWS Batch スケジューラが統合されたクラスターに関連しています。

ヘッドノードの問題

ヘッドノードに関連するセットアップの問題は、シングルキューのクラスターと同様にトラブルシューティングが可能です。これらの問題を解決する方法の詳細については、「シングルキューモードのクラスターにおける問題のトラブルシューティング」を参照してください。

AWS Batch マルチノード並列ジョブ送信の問題

ジョブスケジューラとして AWS Batch を使用するときにマルチノード並列ジョブの送信に問題がある場合は、AWS ParallelCluster バージョン 2.5.0 にアップグレードする必要があります。それが不可能な場合は、トピック「Self patch a cluster used for submitting multi-node parallel jobs through AWS Batch」で紹介されている回避策を使用できます。

コンピューティングの問題

AWS Batch は、お客様のサービスのスケーリングとコンピューティング面を管理します。コンピューティング関連の問題が発生した場合は、AWS Batch のトラブルシューティングのドキュメントを参照してください。

ジョブの失敗

ジョブが失敗した場合は、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 Management Console にログインし、https://console.aws.amazon.com/cloudformation に移動します。

  2. スタック名は parallelcluster-cluster_name を選択します。

  3. [イベント] タブを選択します。

  4. [論理 ID] でリソースイベントのリストをスクロールして、作成に失敗したリソースの [ステータス] を確認します。サブタスクの作成に失敗した場合は、失敗したリソースイベントを見つけるために逆算します。

  5. 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 クォータ、名前の要件、および文字の制限」を参照してください。管理ポリシーのサイズがクォータを超える場合は、ポリシーを 2 つ以上のポリシーに分割してください。IAM ロールにアタッチされたポリシー数のクォータを超えた場合は、追加のロールを作成し、そのロール間でポリシーを配布してクォータを満たすようにします。

追加のサポート

既知の問題点の一覧は、GitHub Wiki のメインページまたは「問題」ページを参照してください。より緊急性の高い問題については、サポート に問い合わせるか、new GitHub issue (新しい GitHub での問題) を登録してください。