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

# クラスターの更新を試行する
<a name="troubleshooting-fc-v3-update-cluster"></a>

次のセクションでは、クラスターを更新しようとして問題が発生した場合に役立つトラブルシューティングソリューションを示します。

## `pcluster update-cluster` コマンドのローカル実行に失敗する
<a name="update-cluster-failure-cli-v3"></a>

失敗の詳細について、ローカルファイルシステムの `~/.parallelcluster/pcluster-cli.log` を確認します。

## クラスターの更新がタイムアウトになる
<a name="update-cluster-failure-timeout-v3"></a>

これは `cfn-hup` が実行されていないことに関連する問題の可能性があります。`cfn-hup` デーモンが外部の原因により終了させられる場合、自動的に再開されることはありません。`cfn-hup` が実行されていない場合、クラスターの更新中に CloudFormation スタックは期待どおりに更新プロセスを開始しますが、更新手順はヘッドノードでアクティブ化されず、最終的にスタックのデプロイはタイムアウトになります。詳細については、「[`cfn-hup` が実行していない場合のクラスター更新タイムアウトのトラブルシューティング](troubleshooting-v3-cluster-update-timeout.md)」を参照してトラブルシューティングと問題からの復旧を行ってください。

## `clusterStatus` は `UPDATE_FAILED`
<a name="update-cluster-failure-v3"></a>

### ルートの原因
<a name="update-cluster-failure-v3-root-causing"></a>

失敗の根本原因を特定するには、まずヘッドノード`/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

### の防止
<a name="update-cluster-failure-v3-preventing"></a>

クラスター内の少なくとも 1 つのノードが更新を正常に適用しなかった場合、クラスターの更新が失敗する可能性があります。クラスターの更新に失敗するリスクを軽減するために、更新を開始する前に壊れたノードを終了することをお勧めします。ノードが壊れる可能性がある例として、予想されるエピックログ期間よりも長い間、コンピューティングノードが `COMPLETING`状態のままになることがあります。これらのノードを検出するには、次のコマンドを実行し、`threshold`値をニーズに合わせて調整します (値は、エピックログに予想される最大期間より大きくなければなりません）。

```
$ scontrol show nodes --json | jq -r --argjson threshold 60 '
  .nodes[] | select(.state | index("COMPLETING")) |
  select((now - .last_busy.number) > $threshold) |
  .name
'
```

### 復旧
<a name="update-cluster-failure-v3-recovering"></a>

更新が失敗した場合、ロールバックはクラスターの状態を回復することが予想されるメカニズムです。

 ロールバックが失敗した場合、クラスターの状態は決定的ではありません。この場合、障害の増幅を防ぐために停止`clustermgtd`された可能性があります。ヘッドノードで次のコマンドを実行して開始することをお勧めします。Python バージョンを、お使いのバージョンに同梱されている AWS ParallelCluster バージョンに適応させます。

```
$ /opt/parallelcluster/pyenv/versions/{{3.12.11}}/envs/cookbook_virtualenv/bin/supervisorctl start clustermgtd
```

### `clusterStatus` は `UPDATE_FAILED`で、 `cloudFormationStackStatus` は です。 `UPDATE_ROLLBACK_FAILED`
<a name="update-cluster-failure-rollback-failed-v3"></a>

 `pcluster describe-cluster` `clusterStatus` が `UPDATE_FAILED`で、 `cloudFormationStackStatus`が の場合`UPDATE_ROLLBACK_FAILED`、クラスターの更新とその後のロールバックの両方が失敗しました。この状態では、クラスタースタックはそれ以上の更新を受け入れることができないため、手動による介入をブロック解除する必要があります。

クラスタースタックのブロックを解除するには、次の手順を実行します。

1. 失敗の根本原因を修正します。

1. ロールバックを強制的に続行します。

   ```
   $ aws cloudformation continue-update-rollback --region {{REGION}} --stack-name {{CLUSTER_STACK_NAME}}
   ```

1. スタックが `UPDATE_ROLLBACK_COMPLETE`ステータスになるまで待ちます。

1. `pcluster update-cluster` コマンドを使用して元の更新を再試行します。

## クラスタースタックが `UPDATE_IN_PROGRESS`または にスタックしているように見える `UPDATE_ROLLBACK_IN_PROGRESS`
<a name="update-cluster-stuck-in-progress-v3"></a>

 ログインノードのブートストラップ障害により、ログインノード Auto Scaling Group が安定しない場合、クラスタースタックは最大 `UPDATE_ROLLBACK_IN_PROGRESS`1 時間、`UPDATE_IN_PROGRESS`または 1 時間停止する可能性があります。

 ログインノード Auto Scaling グループが原因でこの状況にあるかどうかを確認するには、次のチェックを行う必要があります。メインスタックで、 にある唯一のリソースは、ネストされたログインノードスタック`UPDATE_IN_PROGRESS`です。ネストされたログインノードスタックでは、 にスタックされる唯一のリソースは、ログインノードの Auto Scaling Group `UPDATE_IN_PROGRESS`です。

 このシナリオでは、更新をキャンセルして、更新が完了するまで 1 時間待つ必要がないようにできます。

```
$ aws cloudformation cancel-update-stack --region {{REGION}} --stack-name {{CLUSTER_STACK_NAME}}
```

 更新をキャンセルすると、ロールバックがトリガーされます。ロールバックの 1 時間のタイムアウトを短縮することはできないため、最悪のシナリオでは、ロールバックが最終状態になるまで待つ必要があります。

 ロールバックが成功した場合、障害の根本原因を修正したら、すぐに元のクラスターの更新を再試行できます。それ以外の場合は[`clusterStatus` は `UPDATE_FAILED`で、 `cloudFormationStackStatus` は です。 `UPDATE_ROLLBACK_FAILED`](#update-cluster-failure-rollback-failed-v3)を参照してください。