本文属于机器翻译版本。若本译文内容与英语原文存在差异，则一律以英文原文为准。

# 尝试更新集群
<a name="troubleshooting-fc-v3-update-cluster"></a>

下一节提供在尝试更新集群时可能发生的问题的问题排查解决方案。

## `pcluster update-cluster` 命令无法在本地运行
<a name="update-cluster-failure-cli-v3"></a>

检查本地文件系统中的 `~/.parallelcluster/pcluster-cli.log` 以查看失败详细信息。

## 使用 `pcluster describe-cluster` 命令时看到 `clusterStatus` 为 `UPDATE_FAILED`
<a name="update-cluster-failure-v3"></a>

### 根本原因
<a name="update-cluster-failure-v3-root-causing"></a>

要确定故障的根本原因，首先要查看集群堆栈事件和`/var/log/chef-client.log`头节点。

可能的原因是至少有一个群集节点未应用更新。您可以通过在日志中查找来检索`/var/log/chef-client.log`在头节点中更新失败的`Check cluster readiness`节点列表。

查看在 “[GitHub 已知问题” 中是否提到了您的问题](https://github.com/aws/aws-parallelcluster/wiki) GitHub。 Amazon ParallelCluster 

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

如果集群中至少有一个节点未成功应用更新，则集群更新可能会失败。为了降低集群更新失败的风险，我们建议在启动更新之前终止损坏的节点。可能损坏的节点的一个例子是计算节点停滞`COMPLETING`状态的时间超过预期的 epilog 持续时间。要检测这些节点，您可以运行以下命令，根据需要调整该`threshold`值（该值必须大于 epilogs 预期的最大持续时间）。

```
$ 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 版本与你的 Amazon ParallelCluster 版本一起提供的版本进行调整：

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

## 集群更新超时
<a name="update-cluster-failure-timeout-v3"></a>

这可能是与 `cfn-hup` 未运行有关的问题。如果 `cfn-hup` 进程守护程序因外部原因终止，它不会自动重启。如果`cfn-hup`未运行，则在集群更新期间， CloudFormation 堆栈会按预期启动更新过程，但更新过程未在头节点上激活，堆栈部署最终会超时。有关更多信息，请参阅[排查 `cfn-hup` 未运行时的集群更新超时问题](troubleshooting-v3-cluster-update-timeout.md)以排除故障并从问题中恢复。