View a markdown version of this page

尝试更新集群 - Amazon ParallelCluster
pcluster update-cluster 命令无法在本地运行集群更新超时集群状态为 UPDATE_FAILED集群堆栈显示卡在 UPDATE_IN_PROGRESS 或 UPDATE_ROLLBACK_IN_ PROGRESS 中
Amazon Web Services 文档中描述的 Amazon Web Services 服务或功能可能因区域而异。要查看适用于中国区域的差异，请参阅 中国的 Amazon Web Services 服务入门 (PDF)。

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

尝试更新集群

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

pcluster update-cluster 命令无法在本地运行

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

集群更新超时

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

集群状态为 UPDATE_FAILED

根本原因

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

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

查看在 “GitHub 已知问题” 中是否提到了您的问题 GitHub。 Amazon ParallelCluster

预防

如果集群中至少有一个节点未成功应用更新，则集群更新可能会失败。为了降低集群更新失败的风险，我们建议在启动更新之前终止损坏的节点。可能被破坏的节点的一个例子是计算节点处于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
'

正在恢复

如果更新失败，则回滚是恢复集群状态的预期机制。

如果回滚失败，则集群状态不确定。在这种情况下，可能是为了防止故障放大clustermgtd而停止的。我们建议通过在头节点上运行以下命令来启动它。将 Python 版本与你的 Amazon ParallelCluster 版本一起提供的版本进行调整：

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

clusterSt atus 为 UPDATE_FAILED，clou d 为 UPDATE_ROLLBACK_ FormationStackStatus

当pcluster describe-cluster报告现状UPDATE_FAILED和clusterStatus现状cloudFormationStackStatus时UPDATE_ROLLBACK_FAILED，集群更新和随后的回滚都失败了。在这种状态下，集群堆栈无法接受任何进一步的更新，需要手动干预才能解除阻止。

要解除对群集堆栈的封锁，请完成以下步骤：

  1. 修复失败的根本原因。

  2. 强制继续回滚。

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

  3. 等待堆栈达到UPDATE_ROLLBACK_COMPLETE状态。

  4. 使用pcluster update-cluster命令重试原始更新。

集群堆栈显示卡在 UPDATE_IN_PROGRESS 或 UPDATE_ROLLBACK_IN_ PROGRESS 中

如果登录节点 Auto Scaling Group 由于登录节点中的引导失败而无法稳定下来，则集群堆栈可能会停滞UPDATE_IN_PROGRESS或UPDATE_ROLLBACK_IN_PROGRESS最多 1 小时。

要验证是否由于登录节点 Auto Scaling Group 而处于这种情况，您需要进行以下检查：在主堆栈中UPDATE_IN_PROGRESS，唯一存在的资源是登录节点的嵌套堆栈。在登录节点的嵌套堆栈中，唯一被卡住的资源是登录节点 Auto Scaling Group。UPDATE_IN_PROGRESS

如果您处于这种情况，则可以取消更新，这样就无需等待 1 小时即可完成更新。

$ aws cloudformation cancel-update-stack --region REGION --stack-name CLUSTER_STACK_NAME

取消更新会触发回滚。您无法缩短回滚时的 1 小时超时时间，因此在最坏的情况下，您需要等待回滚达到其最终状态。

如果回滚成功，则在修复了故障的根本原因后，您可以立即重试原始集群更新。否则，请参阅clusterSt atus 为 UPDATE_FAILED，clou d 为 UPDATE_ROLLBACK_ FormationStackStatus。