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

# スケーリング問題のトラブルシューティング
<a name="troubleshooting-v3-scaling-issues"></a>

このセクションは、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)

## デバッグ用のキーログ
<a name="troubleshooting-v3-key-logs"></a>

次の表は、ヘッドノードのキーログの概要を示したものです。
+  `/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` エラーが表示されている
<a name="compute-node-initialization-ice-failure-v3-c2"></a>

クラスターが 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)」を参照してください。

## ノードの初期化に関する問題のトラブルシューティング
<a name="troubleshooting-v3-node-init"></a>

このセクションでは、ノードの初期化に関するトラブルを解決する方法について説明します。これには、ノードが起動しない、電源が入らない、またはクラスターが参加できない、などの問題が含まれます。

**Topics**
+ [ヘッドノード](#troubleshooting-v3-node-init.head-node)
+ [コンピューティングノード](#troubleshooting-v3-node-init.compute-node)

### ヘッドノード
<a name="troubleshooting-v3-node-init.head-node"></a>

該当するログ:
+  `/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` のスクリプトが指定されている場合、スクリプトが正常に実行されていることをログメッセージで再確認します。

クラスターが作成されると、ヘッドノードはコンピューティングノードがクラスターに参加するのを待ってからクラスターに参加する必要があります。このため、コンピューティングノードがクラスターに参加できないと、ヘッドノードも失敗してしまいます。このような問題を解決するためには、使用しているコンピュートノートの種類に応じて、次の手順のいずれかを実行します。

### コンピューティングノード
<a name="troubleshooting-v3-node-init.compute-node"></a>
+ 該当するログ:
  + `/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 *

## **予期しないノードの置換や終了のトラブルシューティング**
<a name="troubleshooting-v3-unexpected-node-replacements-and-terminations"></a>

このセクションでは、ノードに関連する問題、特にノードが予期せず置換されたり終了したりした場合のトラブルシューティング方法について引き続き説明します。
+ **該当するログ:**
  + `/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
    ```

## **問題のあるインスタンスやノードの置換、終了、電源オフ**
<a name="replacing-terminating-or-powering-down-problematic-instances-and-nodes-v3"></a>
+ **該当するログ:**
  + `/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` ステータス
<a name="troubleshooting-v3-queues"></a>

`sinfo` を実行して出力に `inact` の `AVAIL` ステータスのキューが表示される場合は、クラスターで [Slurm クラスター保護モード](slurm-protected-mode-v3.md) が有効になっており、キューが事前に定義した期間に `INACTIVE` ステータスに設定されていた可能性があります。

## その他の既知のノードやジョブの問題のトラブルシューティング
<a name="troubleshooting-v3-other-node-job-issues"></a>

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