本文属于机器翻译版本。若本译文内容与英语原文存在差异，则一律以英文原文为准。
# 更新调度器版本的 AWS PCS 集群
使用以下步骤更新集群上的调度程序版本。根据您是否可以容忍作业中断，有两种选择。有关在选项之间进行选择的更多信息，请参阅[在中更新集群的调度程序版本 AWS 个](working-with_clusters_version_update.md)。
**注意**
我们建议您在对生产环境应用更改之前，在非生产集群上测试新的 AMI 和更新程序。
## 选项 1：滚动更新
在舰队继续运行的同时，控制器会更新。现有节点继续使用先前的 Slurm 版本，直到它们被耗尽和更换。更新后启动的新节点使用目标版本。正在运行的作业不会中断。
**何时使用**：
+ 集群控制器使用的是 Slurm 版本 24.05 或更高版本。
### 步骤 0 — 检查起始状态
您的集群正在运行控制器版本 “A”（例如 24.11），并且您想迁移到版本 “B”（例如 25.11）。使用集群节点上的以下命令，确认队列中的所有计算节点都运行相同的主要版本：
```
scontrol show nodes | grep "Version="
# Example output:
# NodeAddr=compute-1 NodeHostName=compute-1 Version=24.11.7
# NodeAddr=compute-2 NodeHostName=compute-2 Version=24.11.7
```
确认计算节点上的 AWS PCS 代理版本。使用 Systems Manager 连接到该节点并检查引导日志：
```
grep "PCS Agent version" /var/log/amazon/pcs/bootstrap.log | tail -1
# Example output:
# /opt/aws/pcs/bin/pcs_bootstrap_init.sh: INFO: Bootstrap starting with PCS Agent version: 1.3.2-1
```
滚动更新要求所有计算节点 AMI 上的 AWS PCS 代理版本 1.4.0 或更高版本。有关更多信息，请参阅 [AWS PCS 代理版本](pcs-agent-versions.md)。
### 步骤 1 — 准备目标 AMI
构建或识别包含 ** Slurm 版本 B 和最新 AWS PCS 代理的 AMI。**
+ 你可以使用最新的 ** PCS-ready DLAMI **。此类 AMI 附带了最新的三个支持的 Slurm 版本。有关更多信息，请参阅 [将 PCS-ready DLAMI 与 AWS PCS](working-with_ami_pcs-ready-dlami.md)。
+ 您可以按照 Slurm 软件包和 AWS PCS 代理的安装步骤构建自**定义 AMI **。有关更多信息，请参阅 [适用于 AWS PCS 的自定义 Amazon 机器映像 (AMIs)](working-with_ami_custom.md)。
+ 我们不建议将 **AWS PCS 示例 AMI ** 用于生产用途。这些 AMI 仅用于测试。
**注意**
同一 AMI 可以包含多个 Slurm 版本。 AWS PCS 会自动选择与控制器匹配的版本。安装其他版本不会导致问题。
### 第 2 步 — 更新群集控制器
在`scheduler.version`设置`UpdateCluster`为版本 B 的情况下进行调用
------
#### [ AWS 管理控制台 ]
1. 在以下位置打开 AWS PCS 控制台[https://console.aws.amazon.com/pcs/](https://console.aws.amazon.com/pcs/)。
1. 在导航窗格中，选择**集群**。
1. 选择要更新的集群，然后选择**编辑**。
1. 在 “**集群详细信息” 下**，从 “调度程序” 下拉列表中选择目标**调度器**版本。
1. 选择 “**更新” ** 以提交版本更新。
1. 监控集群状态。集群显示为更新`UPDATING`期间的状态，`ACTIVE`完成后返回到。更新通常在 5—15 分钟内完成。
------
#### [ AWS CLI ]
```
aws pcs update-cluster \
--cluster-identifier {{cluster-id}} \
--scheduler version={{25.11}}
```
等待集群返回`ACTIVE`。更新通常在 5—15 分钟内完成。
------
在此操作期间，控制器短暂不可用：
+ 在计算节点上运行的作业**继续执行**。
+ 在更新完成之前，新的任务提交和调度程序命令不可用。
+ 自动扩展将暂停，直到集群返回到。`ACTIVE`
**注意**
当舰队仍包含版本 A 上的节点时，请勿添加特定于 B 版本的 Slurm 设置。配置分发给所有节点；旧版本`slurmd`可能无法识别新参数。
如果集群未恢复到`ACTIVE`或`UPDATE_FAILED`在 30 分钟内未恢复，请联系 AWS 支持部门寻求帮助。
### 第 3 步 — 更新计算节点组
对于每个计算节点组，使用目标 Slurm 版本设置新 AMI：
```
aws pcs update-compute-node-group \
--cluster-identifier {{cluster-id}} \
--compute-node-group-identifier {{cng-id}} \
--ami-id {{new-ami-id}}
```
AWS PCS 将运行先前版本的节点设置为`DRAIN`状态。排干的节点完成当前任务后， AWS PCS 终止节点并用运行 Slurm 版本 B 的新节点取而代之。
### 第 4 步 — 在 Slurm 版本 B 上验证一致的队列
监控舰队过渡。在群集节点上，查看所有节点的版本摘要：
```
scontrol show nodes | grep "Version=" | awk -F'=' '{print $NF}' | sort | uniq -c
```
检查处于`DRAIN`状态的节点及其版本：
```
scontrol show nodes | awk '/NodeName=/{name=$1; ver=""} /Version=/{ver=$NF} /State=.*DRAIN/{print name, ver}'
```
检查所有活动节点的版本：
```
scontrol show nodes | awk '/NodeName=/{name=$1; ver=""} /Version=/{ver=$NF} /State=/{if (ver) print name, ver}'
```
当版本摘要仅显示目标版本且没有节点处于`DRAIN`或`DRAINING`状态时，更新即告完成。处于该`POWERED_DOWN`状态的节点在 AWS PCS 启动之前不会报告版本。
## 选项 2：停止 Full-fleet 维护
在更新控制器之前，您需要终止整个队列，然后将其从带有目标 Slurm 版本的新 AMI 向上扩展。此过程更简单，但它会终止所有节点和正在运行的作业。
**何时使用**：
+ 群集控制器的版本为 23.11（选项 1 不适用于 23.11 群集）。
**注意**
一次终止整个机队会增加扩容时出现容量不足错误的可能性。考虑使用预留容量或在非高峰时段进行调度。
### 步骤 0 — 检查起始状态
您的集群正在运行控制器版本 “A”（例如 24.11），并且您想迁移到版本 “B”（例如 25.11）。使用集群节点上的以下命令，确认队列中的所有计算节点都运行相同的主要版本：
```
scontrol show nodes | grep "Version="
# Example output:
# NodeAddr=compute-1 NodeHostName=compute-1 Version=24.11.7
# NodeAddr=compute-2 NodeHostName=compute-2 Version=24.11.7
```
确认计算节点上的 AWS PCS 代理版本。使用 Systems Manager 连接到该节点并检查引导日志：
```
grep "PCS Agent version" /var/log/amazon/pcs/bootstrap.log | tail -1
# Example output:
# /opt/aws/pcs/bin/pcs_bootstrap_init.sh: INFO: Bootstrap starting with PCS Agent version: 1.3.2-1
```
在目标 AMI 上使用最新的 AWS PCS 代理。有关更多信息，请参阅 [AWS PCS 代理版本](pcs-agent-versions.md)。
### 步骤 1 — 准备目标 AMI
构建或识别包含 ** Slurm 版本 B 和最新 AWS PCS 代理的 AMI。**
+ 你可以使用最新的 ** PCS-ready DLAMI **。此类 AMI 附带了最新的三个支持的 Slurm 版本。有关更多信息，请参阅 [将 PCS-ready DLAMI 与 AWS PCS](working-with_ami_pcs-ready-dlami.md)。
+ 您可以按照 Slurm 软件包和 AWS PCS 代理的安装步骤构建自**定义 AMI **。有关更多信息，请参阅 [适用于 AWS PCS 的自定义 Amazon 机器映像 (AMIs)](working-with_ami_custom.md)。
+ 我们不建议将 **AWS PCS 示例 AMI ** 用于生产用途。这些 AMI 仅用于测试。
### 第 2 步 — 缩小整个机队的规模
记录当前`minNodeCount`和每个计算节点组`maxNodeCount`的值，您将在步骤 4 中恢复这些值。
```
for cng in $(aws pcs list-compute-node-groups --cluster-identifier {{cluster-id}} --query "computeNodeGroups[].id" --output text); do
aws pcs get-compute-node-group \
--cluster-identifier {{cluster-id}} \
--compute-node-group-identifier "$cng" \
--query "computeNodeGroup.{Id:id,AmiId:amiId,Min:scalingConfiguration.minInstanceCount,Max:scalingConfiguration.maxInstanceCount}" \
--output table
done
```
**警告**
以下操作将终止所有正在运行的节点及其上的作业。
`0`在每个计算节点组上设置`minNodeCount`和`maxNodeCount`为：
```
aws pcs update-compute-node-group \
--cluster-identifier {{cluster-id}} \
--compute-node-group-identifier {{cng-id}} \
--scaling-configuration '{"minNodeCount": 0, "maxNodeCount": 0}'
```
继续操作之前，请确认没有`aws:pcs:cluster-id`与您的集群匹配的标记的实例正在运行：
```
aws ec2 describe-instances \
--filters "Name=tag:aws:pcs:cluster-id,Values={{cluster-id}}" \
--query "Reservations[].Instances[].[InstanceId,ImageId,State.Name]" \
--output table
```
### 第 3 步 — 更新群集控制器
------
#### [ AWS 管理控制台 ]
1. 在以下位置打开 AWS PCS 控制台[https://console.aws.amazon.com/pcs/](https://console.aws.amazon.com/pcs/)。
1. 在导航窗格中，选择**集群**。
1. 选择要更新的集群，然后选择**编辑**。
1. 在 “**集群详细信息” 下**，从 “调度程序” 下拉列表中选择目标**调度器**版本。
1. 选择 “**更新” ** 以提交版本更新。
1. 监控集群状态。集群显示为更新`UPDATING`期间的状态，`ACTIVE`完成后返回到。更新通常在 5—15 分钟内完成。
------
#### [ AWS CLI ]
```
aws pcs update-cluster \
--cluster-identifier {{cluster-id}} \
--scheduler version={{25.11}}
```
等待集群返回`ACTIVE`。更新通常在 5—15 分钟内完成。
如果集群未恢复到`ACTIVE`或`UPDATE_FAILED`在 30 分钟内未恢复，请联系 AWS 支持部门寻求帮助。
------
### 第 4 步 — 更新计算节点组并恢复容量
对于每个计算节点组，设置新的 AMI 并恢复原始的最小和最大容量限制：
```
aws pcs update-compute-node-group \
--cluster-identifier {{cluster-id}} \
--compute-node-group-identifier {{cng-id}} \
--ami-id {{new-ami-id}} \
--scaling-configuration '{"minNodeCount": {{previous-min}}, "maxNodeCount": {{previous-max}}}'
```
集群向上扩展。所有新节点都使用最新的 AWS PCS 代理运行 Slurm B 版。
## 示例：跨多个版本更新
如果目标版本不在当前版本的兼容性窗口内，则必须将控制器移至一个或多个中间版本，一次更新一跳。在当前控制器版本的兼容性窗口中，每跳都必须以支持的版本为目标。
因为在更新控制器之前会将队列[选项 2：停止 Full-fleet 维护](#version_update-procedure-option2)扩展到零，所以当控制器在版本之间移动时，没有计算节点在运行。因此，您的 AMI 可以直接使用**最终**目标版本——每跳只能重复控制器更新（步骤 3）。
以下示例**使用选项 2 过程将集群从 ** 23.11 更新到 25.11。23.11 不在 25.11 的兼容窗口内，因此控制器分两跳（23.11 更新到 25.05，然后是 25.05 到 25.11）。按照选项 2 的步骤操作，步骤 3 分为每跳一次更新：
1. **步骤 1-准备目标 AMI。**使用**最终**版本 (25.11) 和最新的 AWS PCS 代理构建或识别 AMI。请参阅[步骤 1 — 准备目标 AMI](#version_update-procedure-option2-step1)。
1. **第 2 步 — 缩小整个机队的规模。**记录当前容量（参见[第 2 步 — 缩小整个机队的规模](#version_update-procedure-option2-step2)），然后将每个计算节点组设置为零。
```
aws pcs update-compute-node-group \
--cluster-identifier {{my-cluster}} \
--compute-node-group-identifier {{my-cng}} \
--scaling-configuration '{"minNodeCount": 0, "maxNodeCount": 0}'
```
1. **步骤 3a — 将控制器从 23.11 更新到 25.05。**等待集群返回`ACTIVE`。
```
aws pcs update-cluster --cluster-identifier {{my-cluster}} \
--scheduler version=25.05
```
1. **步骤 3b — 将控制器从 25.05 更新到 25.11。**等待集群返回`ACTIVE`。
```
aws pcs update-cluster --cluster-identifier {{my-cluster}} \
--scheduler version=25.11
```
1. **第 4 步 — 更新计算节点组并恢复容量。**在每个计算节点组上设置 25.11 AMI 并恢复原始容量限制（参见[第 4 步 — 更新计算节点组并恢复容量](#version_update-procedure-option2-step4)）。
```
aws pcs update-compute-node-group \
--cluster-identifier {{my-cluster}} \
--compute-node-group-identifier {{my-cng}} \
--ami-id {{ami-0123456789abcdef0}} \
--scaling-configuration '{"minNodeCount": {{previous-min}}, "maxNodeCount": {{previous-max}}}'
```
**注意**
每个控制器跳跃都必须在前一个版本的兼容窗口内登陆一个版本。要查找有效的中间版本，请参阅[版本兼容性](working-with_clusters_version_update.md#version_update-cluster-compatibility)。通过步骤 3a 和 3b，队列保持为零，因此无需进行中间 AMI 更新。