

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

# 问题排查 AWS PCS 集群版本更新
<a name="working-with_clusters_version_update_troubleshooting"></a>

本主题可帮助您识别和解决在更新集群上的调度程序版本时可能出现的常见问题。
+ [更新后计算节点无法连接](#update-troubleshooting-nodes-fail)
+ [更新请求被拒绝 ValidationException](#update-troubleshooting-validation-error)
+ [集群仍处于更新状态](#update-troubleshooting-stuck-updating)
+ [更新后，集群进入 UPDATE\_FAILED 状态](#update-troubleshooting-update-failed)
+ [由于配置解析错误，计算节点无法启动](#update-troubleshooting-config-parse)
+ [由于 QoS 配置无效，群集在更新后不可用](#update-troubleshooting-qos-bootloop)

## 更新后计算节点无法连接
<a name="update-troubleshooting-nodes-fail"></a>

### 常见原因
<a name="update-troubleshooting-nodes-fail-cause"></a>

更新集群后，新启动的计算节点无法向控制器注册。节点启动但从未出现在`sinfo`输出中，并且计算节点组可能会在实例之间反复循环。当计算节点组的 AMI 包含的调度程序版本超出新控制器版本的兼容窗口时，就会发生这种情况。

例如，如果您将集群从 24.11 更新到 25.11，但计算节点组仍使用带有 Slurm 23.11 的 AMI，则新实例将无法连接，因为 23.11 在 25.11 的兼容窗口之外。

### 如何诊断
<a name="update-troubleshooting-nodes-fail-diagnosis"></a>

您可以通过在两个地方查看日志来确认此问题：

**日程安排日志**

如果您启用了调度程序日志记录，请在 “日志” 中查看调度程序 CloudWatch 日志中是否存在类似以下内容的错误：

```
error: unpack_header: protocol_version 10240 not supported
error: slurm_unpack_received_msg: [{{ip-10-0-1-23}}] Incompatible versions of client and server code
```

这些错误表明具有不兼容调度器版本的计算节点正在尝试连接到控制器。有关设置调度程序日志记录的信息，请参见[计划程序在 PCS 中 AWS 登录](monitoring_scheduler-logs.md)。

**计算节点实例日志**

检索实例控制台输出或通过 Systems Manager 进行连接，并检查引导日志中是否存在类似于以下内容的错误：

```
error: _fetch_child: failed to fetch remote configs: Incompatible versions of client and server
error: _establish_configuration: failed to load configs
error: slurmd initialization failed
```

有关检索实例日志的更多信息，请参阅[检索实例日志](troubleshooting-compute-node-bootstrap.md#troubleshooting-compute-node-bootstrap-retrieve-logs)。

### 解决方案
<a name="update-troubleshooting-nodes-fail-resolution"></a>

更新计算节点组以使用包含新集群版本兼容窗口内的调度程序版本的 AMI：

```
aws pcs update-compute-node-group \
--cluster-identifier {{my-cluster}} \
--compute-node-group-identifier {{my-cng}} \
--ami-id {{ami-0123456789abcdef0}}
```

要确定哪些调度程序版本与您的集群兼容，请参阅[版本兼容性](working-with_clusters_version_update.md#version_update-cluster-compatibility)。

有关使用正确的计划程序版本构建自定义 AMI 的信息，请参阅。[的亚马逊机器映像 (AMI) AWS 个](working-with_ami.md)

## 更新请求被拒绝 ValidationException
<a name="update-troubleshooting-validation-error"></a>

### 常见原因
<a name="update-troubleshooting-validation-error-cause"></a>

该`UpdateCluster`请求会立即返回，并显示`ValidationException`错误消息，表示不支持更新。在以下情况下会发生这种情况：
+ 目标版本在当前版本的[兼容性窗口](https://slurm.schedmd.com/upgrades.html#compatibility_window)之外。
+ 目标版本被指定为生命周期结束 (EOL)，不再是有效的更新目标。
+ 目标版本早于或等于当前版本（不支持降级）。

### 解决方案
<a name="update-troubleshooting-validation-error-resolution"></a>

如果目标版本不在兼容性窗口内，请分多个步骤执行更新。每个步骤都必须针对兼容性窗口中支持的版本。例如，要从 23.11 升级到 25.11，首先更新到 25.05，请等待集群返回`ACTIVE`，然后更新到 25.11。

如果目标版本为 EOL，请改为选择更新的支持版本。有关支持的版本的信息，请参阅[在 Slurm 版本中 AWS 个](slurm-versions.md)。

## 集群仍处于更新状态
<a name="update-troubleshooting-stuck-updating"></a>

### 常见原因
<a name="update-troubleshooting-stuck-updating-cause"></a>

集群保持`UPDATING`状态的时间比预期的长（超过 20 分钟）。这可能是由于更新过程中出现的暂时性内部问题所致。

### 解决方案
<a name="update-troubleshooting-stuck-updating-resolution"></a>

AWS PCS 会自动恢复处于`UPDATING`状态的集群。如果集群在 30 分钟`UPDATE_FAILED`内未返回`ACTIVE`或未恢复，请联系 Supp AWS ort 寻求帮助。

## 更新后，集群进入 UPDATE\_FAILED 状态
<a name="update-troubleshooting-update-failed"></a>

### 常见原因
<a name="update-troubleshooting-update-failed-cause"></a>

更新期间，集群会转换到`UPDATE_FAILED`状态。当临时服务错误使更新无法成功完成时，就会发生这种情况。

### 解决方案
<a name="update-troubleshooting-update-failed-resolution"></a>

再次提交相同的`UpdateCluster`请求，重试更新。处于`UPDATE_FAILED`状态的集群接受新的更新请求。如果更新仍然失败，请联系 Supp AWS ort。

## 由于配置解析错误，计算节点无法启动
<a name="update-troubleshooting-config-parse"></a>

### 常见原因
<a name="update-troubleshooting-config-parse-cause"></a>

更新集群后，计算节点无法启动，也不会出现在`sinfo`输出中。计算节点实例日志显示的错误与以下内容类似：

```
error: _parse_next_key: Parsing error at unrecognized key: {{HashPlugin}}
error: Invalid DebugFlag: {{AuditRPCs}}
fatal: Unable to process configuration file
```

当运行调度器版本 23.11 的计算节点收到来自较新集群版本的配置时，就会发生这种情况。23.11 之后的调度器版本引入了 23.11 无法解析的新配置指令。与[兼容性窗口](https://slurm.schedmd.com/upgrades.html#compatibility_window)中的其他版本不同，23.11 计算节点无法连接到较新的集群，因为它们在无法识别的配置密钥上出现致命错误。

如果您的自定义 AMI 使用低于 v1.4.0 的 AWS PCS 代理版本，也会出现此问题。较旧的代理版本不支持计算节点守护程序的自动版本回退。

### 解决方案
<a name="update-troubleshooting-config-parse-resolution"></a>

按照以下要求重新构建您的自定义 AMI：
+ 调度程序版本 24.05 或更高版本
+ AWS PCS 代理版本 1.4.0 或更高版本

然后更新计算节点组以使用新的 AMI：

```
aws pcs update-compute-node-group \
--cluster-identifier {{my-cluster}} \
--compute-node-group-identifier {{my-cng}} \
--ami-id {{ami-0123456789abcdef0}}
```

有关构建自定义 AMI 的信息，请参阅[的亚马逊机器映像 (AMI) AWS 个](working-with_ami.md)。有关 AWS PCS 代理版本的信息，请参见[AWS PCS 代理版本](pcs-agent-versions.md)。

## 由于 QoS 配置无效，群集在更新后不可用
<a name="update-troubleshooting-qos-bootloop"></a>

### 常见原因
<a name="update-troubleshooting-qos-bootloop-cause"></a>

更新到版本 25.11 后，集群进入`UPDATE_FAILED`状态或调度程序变为不可用。您无法提交作业或运行调度器命令。调度程序日志显示的错误类似于以下内容：

```
error: Invalid Allow/DenyQOS value: {{low}}
fatal: Partition {{my-queue}} has an invalid DenyQOS ({{low}}), please check your configuration
```

当队列（分区）通过`AllowQOS`、`DenyQOS`或 Slurm 记账数据库中不存在的`QOS`设置引用 QoS 名称时，就会发生这种情况。Slurm 25.11 在调度器启动时引入了对 QoS 参考的更严格的验证。早期版本允许引用不存在的 QoS 名称而不会出现错误。

### 解决方案
<a name="update-troubleshooting-qos-bootloop-resolution"></a>

在更新到版本 25.11 之前，请确认队列配置中引用的所有 QoS 名称都存在于会计数据库中。连接到登录节点并运行以下命令以检查 QoS 是否存在：

```
sacctmgr show qos where name={{low}} format=name
```

如果 QoS 不存在，请在尝试更新之前创建它：

```
sacctmgr add qos {{low}}
```

或者，在更新集群之前，通过更新队列的 Slurm 自定义设置来删除`AllowQOS``DenyQOS`、或`QOS`参数，从队列配置中删除 QoS 引用。