本文属于机器翻译版本。若本译文内容与英语原文存在差异，则一律以英文原文为准。
# 支持的调度器 AWS ParallelCluster
AWS ParallelCluster 支持Slurm和 AWS Batch 调度程序，它们使用设置进行[`Scheduler`](Scheduling-v3.md#yaml-Scheduling-Scheduler)设置。以下主题将介绍每种调度器及其使用方法。
**Topics**
+ [Slurm Workload Manager (`slurm`)](slurm-workload-manager-v3.md)
+ [将 AWS Batch (`awsbatch`) 调度器与 AWS ParallelCluster](awsbatchcli-v3.md)
# Slurm Workload Manager (`slurm`)
## 集群容量大小和更新
集群的容量由集群可以扩展的计算节点数量来定义。计算节点由 AWS ParallelCluster 配置中的计算资源中定义的 Amazon EC2 实例提供支持`(Scheduling/SlurmQueues/`ComputeResources`)`，并按照 1:1 映射到Slurm分区的队列`(Scheduling/SlurmQueues)`进行组织。
在计算资源中，可以配置集群中必须始终保持运行的最小计算节点（实例）数（`MinCount`），以及计算资源可以扩展到的最大实例数（[`MaxCount`3](Scheduling-v3.md#yaml-Scheduling-SlurmQueues-ComputeResources-MaxCount)）。
在创建集群时或更新集群时，为集群中定义的每个计算资源 (`Scheduling/SlurmQueues/ ComputeResources`) AWS ParallelCluster 启动中配置`MinCount`的任意数量的 Amazon EC2 实例。为覆盖集群中计算资源的最小节点数量而启动的实例称为***静态节点***。静态节点一旦启动，就会在集群中持续存在，除非发生特定事件或情况，否则系统不会终止它们。例如，此类事件包括 Slurm 或 Amazon EC2 运行状况检查失败，以及 Slurm 节点状态变为 DRAIN 或 DOWN。
为应对集群负载增加而按需启动的 Amazon EC2 实例（范围在 `1` 到 `‘MaxCount - MinCount’`（`MaxCount ` *减去*` MinCount)`）之间）称为“动态节点”******。这些节点的性质是短暂的，启动它们是为了处理待处理的作业，一旦它们闲置了一段时间（由集群配置中的 `Scheduling/SlurmSettings/ScaledownIdletime` 定义）（默认值：10 分钟），就会被终止。
静态节点和动态节点符合以下命名方案：
+ 静态节点 `-st--`，其中 ` = 1..ComputeResource/MinCount`
+ 动态节点 `-dy--`，其中 ` = 1..(ComputeResource/MaxCount - ComputeResource/MinCount)`
例如，给定以下 AWS ParallelCluster 配置：
```
Scheduling:
Scheduler: Slurm
SlurmQueues:
- Name: queue1
ComputeResources:
- Name: c5xlarge
Instances:
- InstanceType: c5.xlarge
MinCount: 100
MaxCount: 150
```
将在 Slurm 中定义以下节点
```
$ sinfo
PARTITION AVAIL TIMELIMIT NODES STATE NODELIST
queue1* up infinite 50 idle~ queue1-dy-c5xlarge-[1-50]
queue1* up infinite 100 idle queue1-st-c5xlarge-[1-100]
```
当计算资源拥有时`MinCount == MaxCount`，所有相应的计算节点都将是静态的，并且所有实例都将在集群 creation/update 时启动并保持正常运行。例如：
```
Scheduling:
Scheduler: slurm
SlurmQueues:
- Name: queue1
ComputeResources:
- Name: c5xlarge
Instances:
- InstanceType: c5.xlarge
MinCount: 100
MaxCount: 100
```
```
$ sinfo
PARTITION AVAIL TIMELIMIT NODES STATE NODELIST
queue1* up infinite 100 idle queue1-st-c5xlarge-[1-100]
```
## 集群容量更新
集群容量的更新包括添加或删除队列、计算资源或更改计算资源的 `MinCount/MaxCount`。从 AWS ParallelCluster 版本 3.9.0 开始，缩小队列大小需要在集群更新之前停止计算队列或将其[QueueUpdateStrategy](Scheduling-v3.md#yaml-Scheduling-SlurmSettings-QueueUpdateStrategy)设置为 TERMINATION for。在以下情况下，无需停止计算队列或将其设置[QueueUpdateStrategy](Scheduling-v3.md#yaml-Scheduling-SlurmSettings-QueueUpdateStrategy)为 “终止”：
+ 将新队列添加到 Scheduling/[`SlurmQueues`](Scheduling-v3.md#Scheduling-v3-SlurmQueues)
+ 向队列中添加新的计算资源 `Scheduling/SlurmQueues/ComputeResources`
+ 增加计算资源的 `MaxCount`
+ 计算资源的增加 MaxCount 和相同计算资源的增加量至少相等 MinCount
## 注意事项和限制
本节旨在概述在调整集群容量大小时应考虑的任何重要因素、约束或限制。
+ 从 `Scheduling/SlurmQueues` 中删除队列时，所有名称为 `-*` 的计算节点（包括静态和动态节点）都将从 Slurm 配置中删除，相应的 Amazon EC2 实例也将终止。
+ 从队列中删除计算资源 `Scheduling/SlurmQueues/ComputeResources` 时，所有名称为 `-*--*` 的计算节点（包括静态和动态节点）都将从 Slurm 配置中删除，相应的 Amazon EC2 实例也将终止。
在更改计算资源的 `MinCount` 参数时，我们可以区分两种不同的情况，一种是 `MaxCount` 与 `MinCount` 相等（仅静态容量），另一种是 `MaxCount` 大于 `MinCount`（静态和动态混合容量）。
### 只有静态节点的容量变化
+ 如果 `MinCount == MaxCount`，当增加 `MinCount`（和 `MaxCount`）时，通过将静态节点数扩展到 `MinCount` `-st--` 的新值来配置集群，并且系统将不断尝试启动 Amazon EC2 实例来满足新的静态容量需求。
+ 如果 `MinCount == MaxCount`，当 `MinCount`（和 `MaxCount`）的数量减少 N 时，通过移除最后 N 个静态节点 `-st--...]` 来配置集群，系统将终止相应的 Amazon EC2 实例。
+ 初始状态 `MinCount = MaxCount = 100`
+
```
$ sinfo
PARTITION AVAIL TIMELIMIT NODES STATE NODELIST
queue1* up infinite 100 idle queue1-st-c5xlarge-[1-100]
```
+ 更新 `MinCount` 和 `MaxCount: MinCount = MaxCount = 70` 上的 `-30`
+
```
$ sinfo
PARTITION AVAIL TIMELIMIT NODES STATE NODELIST
queue1* up infinite 70 idle queue1-st-c5xlarge-[1-70]
```
### 混合节点的容量变化
如果 `MinCount < MaxCount`，当 `MinCount` 的数量增加 N 时（假设 `MaxCount` 保持不变），通过将静态节点数扩展到 `MinCount` 的新值（`old_MinCount + N`）来配置集群（`-st--`），并且系统将不断尝试启动 Amazon EC2 实例来满足新的静态容量需求。此外，为了满足计算资源的 `MaxCount` 容量，通过*删除最后 N 个动态节点*来更新集群配置（`-dy--[...]`），系统将终止相应的 Amazon EC2 实例。
+ 初始状态：`MinCount = 100; MaxCount = 150`
+
```
$ sinfo
PARTITION AVAIL TIMELIMIT NODES STATE NODELIST
queue1* up infinite 50 idle~ queue1-dy-c5xlarge-[1-50]
queue1* up infinite 100 idle queue1-st-c5xlarge-[1-100]
```
+ 将 \$130 更新为 `MinCount : MinCount = 130 (MaxCount = 150)`
+
```
$ sinfo
PARTITION AVAIL TIMELIMIT NODES STATE NODELIST
queue1* up infinite 20 idle~ queue1-dy-c5xlarge-[1-20]
queue1* up infinite 130 idle queue1-st-c5xlarge-[1-130]
```
如果 `MinCount < MaxCount`，当 `MinCount` 和 `MaxCount` 的数量都增加 N 时，通过将静态节点数扩展到 `MinCount` 的新值（`old_MinCount + N`）来配置集群（`-st--`），并且系统将不断尝试启动 Amazon EC2 实例来满足新的静态容量需求。此外，动态节点的数量不会因新的
`MaxCount` 值。
+ 初始状态：`MinCount = 100; MaxCount = 150`
+
```
$ sinfo
PARTITION AVAIL TIMELIMIT NODES STATE NODELIST
queue1* up infinite 50 idle~ queue1-dy-c5xlarge-[1-50]
queue1* up infinite 100 idle queue1-st-c5xlarge-[1-100]
```
+ 将 \$130 更新为 `MinCount : MinCount = 130 (MaxCount = 180)`
+
```
$ sinfo
PARTITION AVAIL TIMELIMIT NODES STATE NODELIST
queue1* up infinite 20 idle~ queue1-dy-c5xlarge-[1-50]
queue1* up infinite 130 idle queue1-st-c5xlarge-[1-130]
```
如果 `MinCount < MaxCount`，当 `MinCount` 的数量减少 N 时（假设 `MaxCount` 保持不变），通过移除最后 N 个静态节点 `-st--[...` 来配置集群，系统将终止相应的 Amazon EC2 实例。此外，为了满足计算资源的 `MaxCount` 容量，通过扩展动态节点数来更新集群配置（`MaxCount - new_MinCount: -dy--[1..]`）。在这种情况下，由于这些是动态节点，因此除非调度器在新节点上有待处理的作业，否则不会启动新的 Amazon EC2 实例。
+ 初始状态：`MinCount = 100; MaxCount = 150`
+
```
$ sinfo
PARTITION AVAIL TIMELIMIT NODES STATE NODELIST
queue1* up infinite 50 idle~ queue1-dy-c5xlarge-[1-50]
queue1* up infinite 100 idle queue1-st-c5xlarge-[1-100]
```
+ 更新 `MinCount : MinCount = 70 (MaxCount = 120)` 上的 -30
+
```
$ sinfo
PARTITION AVAIL TIMELIMIT NODES STATE NODELIST
queue1* up infinite 80 idle~ queue1-dy-c5xlarge-[1-80]
queue1* up infinite 70 idle queue1-st-c5xlarge-[1-70]
```
如果 `MinCount < MaxCount`，当 `MinCount` 和 `MaxCount` 的数量都减少 N 时，通过移除最后 N 个静态节点来配置集群（`-st--...]`），系统将终止相应的 Amazon EC2 实例。
此外，动态节点的数量不会因新的 `MaxCount` 值而发生变化。
+ 初始状态：`MinCount = 100; MaxCount = 150`
+
```
$ sinfo
PARTITION AVAIL TIMELIMIT NODES STATE NODELIST
queue1* up infinite 50 idle~ queue1-dy-c5xlarge-[1-50]
queue1* up infinite 100 idle queue1-st-c5xlarge-[1-100]
```
+ 更新 `MinCount : MinCount = 70 (MaxCount = 120)` 上的 -30
+
```
$ sinfo
PARTITION AVAIL TIMELIMIT NODES STATE NODELIST
queue1* up infinite 80 idle~ queue1-dy-c5xlarge-[1-50]
queue1* up infinite 70 idle queue1-st-c5xlarge-[1-70]
```
如果 `MinCount < MaxCount`，当 `MaxCount` 的数量减少 N 时（假设 `MinCount` 保持不变），通过移除最后 N 个动态节点来配置集群（`-dy--]`），系统将终止正在运行的相应 Amazon EC2 实例。预计不会对静态节点产生影响。
+ 初始状态：`MinCount = 100; MaxCount = 150`
+
```
$ sinfo
PARTITION AVAIL TIMELIMIT NODES STATE NODELIST
queue1* up infinite 50 idle~ queue1-dy-c5xlarge-[1-50]
queue1* up infinite 100 idle queue1-st-c5xlarge-[1-100]
```
+ 更新 `MaxCount : MinCount = 100 (MaxCount = 120)` 上的 -30
+
```
$ sinfo
PARTITION AVAIL TIMELIMIT NODES STATE NODELIST
queue1* up infinite 20 idle~ queue1-dy-c5xlarge-[1-20]
queue1* up infinite 100 idle queue1-st-c5xlarge-[1-100]
```
## 对作业的影响
在移除节点和终止 Amazon EC2 实例的所有情况下，在已移除节点上运行的批处理作业将重新排队，除非没有其它节点满足作业要求。在最后一种情况下，任务失败，状态为 NODE\$1FAIL，并从队列中消失，必须手动重新提交。
如果您计划执行集群大小调整更新，可以防止作业在计划更新期间将被移除的节点上运行。这可以通过将要移除的节点设置为维护状态来实现。请注意，将节点设置为维护状态不会影响最终已在该节点上运行的作业。
假设在计划的集群大小调整更新中，您将移除节点 `qeueu-st-computeresource-[9-10`]。您可以使用以下命令创建 Slurm 预留
```
sudo -i scontrol create reservation ReservationName=maint_for_update user=root starttime=now duration=infinite flags=maint,ignore_jobs nodes=qeueu-st-computeresource-[9-10]
```
这将在节点 `qeueu-st-computeresource-[9-10]` 上创建一个名为 `maint_for_update` 的 Slurm 预留。从创建预留开始，`qeueu-st-computeresource-[9-10]` 节点上就不能再运行任何作业。请注意，预留不会阻止作业最终在 `qeueu-st-computeresource-[9-10]` 节点上分配。
集群大小调整更新后，如果 Slurm 预留只设置在调整大小更新期间被移除的节点上，维护预留将自动删除。如果您在集群大小调整更新后仍然存在的节点上创建了 Slurm 预留，我们可能希望在执行大小调整更新后删除节点上的维护预留，方法是使用以下命令
```
sudo -i scontrol delete ReservationName=maint_for_update
```
有关 Slurm 预留的更多详情，请在[此处](https://slurm.schedmd.com/reservations.html)查看 SchedMD 官方文档。
## 容量变更时的集群更新过程
调度器配置更改后，将在集群更新过程中执行以下步骤：
+ 停下来 AWS ParallelCluster `clustermgtd (supervisorctl stop clustermgtd)`
+ 根据 AWS ParallelCluster 配置生成更新的 Slurm 分区配置
+ 重启 `slurmctld`（通过 Chef 服务配方完成）
+ 检查 `slurmctld` 状态 `(systemctl is-active --quiet slurmctld.service)`
+ 重新加载 Slurm 配置 `(scontrol reconfigure)`
+ 启动 `clustermgtd (supervisorctl start clustermgtd)`
有关 Slurm 的信息，请参阅 [https://slurm.schedmd.com](https://slurm.schedmd.com)。有关下载，请参阅 [https://github.com/SchedMD/slur](https://github.com/SchedMD/slurm/tags) m/tags。有关源代码，请参阅 [https://github.com/SchedMD/slurm](https://github.com/SchedMD/slurm)。
## 支持的集群版本和 SLURM 版本
下表列出了 AWS 支持的 AWS ParallelCluster 和Slurm版本。
| AWS ParallelCluster 版本 | 支持的 Slurm 版本 |
| --- | --- |
| 3.13.0 | 24.05.07 |
| 3.12.0 | 23.11.10 |
| 3.11.0 | 23.11.10 |
| 3.9.2、3.9.3、3.10.0 | 23.11.7 |
| 3.9.0、3.9.1 | 23.11.4 |
| 3.8.0 | 23.02.7 |
| 3.7.2 | 23.02.6 |
| 3.7.1 | 23.02.5 |
| 3.7.0 | 23.02.4 |
| 3.6.0、3.6.1 | 23.02.2 |
| 3.5.0、3.5.1 | 22.05.8 |
| 3.4.0、3.4.1 | 22.05.7 |
| 3.3.0、3.3.1 | 22.05.5 |
| 3.1.4、3.1.5、3.2.0、3.2.1 | 21.08.8-2 |
| 3.1.2、3.1.3 | 21.08.6 |
| 3.1.1 | 21.08.5 |
| 3.0.0 | 20.11.8 |
**Topics**
+ [集群容量大小和更新](#cluster-capacity-size-and-update)
+ [集群容量更新](#cluster-capacity-update)
+ [注意事项和限制](#considerations-limitations)
+ [对作业的影响](#impacts-on-jobs)
+ [容量变更时的集群更新过程](#cluster-update-process)
+ [支持的集群版本和 SLURM 版本](#cluster-slurm-version-table)
+ [多个队列的配置](configuration-of-multiple-queues-v3.md)
+ [Slurm 多队列模式指南](multiple-queue-mode-slurm-user-guide-v3.md)
+ [Slurm 集群保护模式](slurm-protected-mode-v3.md)
+ [Slurm 集群快速容量不足故障转移](slurm-short-capacity-fail-mode-v3.md)
+ [Slurm 基于内存的调度](slurm-mem-based-scheduling-v3.md)
+ [Slurm 的多实例类型分配](slurm-multiple-instance-allocation-v3.md)
+ [动态节点的集群扩展](scheduler-node-allocation-v3.md)
+ [Slurm会计 AWS ParallelCluster](slurm-accounting-v3.md)
+ [Slurm 配置自定义](slurm-configuration-settings-v3.md)
+ [Slurm 和 `prolog``epilog`](slurm-prolog-epilog-v3.md)
+ [集群容量大小和更新](slurm-cluster-capacity-size-and-update.md)
# 多个队列的配置
在 AWS ParallelCluster 版本 3 中，您可以通过将设置为`slurm`并在配置文件[`SlurmQueues`](Scheduling-v3.md#Scheduling-v3-SlurmQueues)中为指定多个队列来配置多个队列。[`Scheduler`](Scheduling-v3.md#yaml-Scheduling-Scheduler)在此模式下，不同的实例类型共存于配置文件的 [`ComputeResources`](Scheduling-v3.md#Scheduling-v3-SlurmQueues-ComputeResources) 部分中指定的计算节点中。具有不同实例类型的 [`ComputeResources`](Scheduling-v3.md#Scheduling-v3-SlurmQueues-ComputeResources) 会根据 [`SlurmQueues`](Scheduling-v3.md#Scheduling-v3-SlurmQueues) 的需要纵向扩展或缩减。
当工作负载共享相同的底层基础架构和资源（例如共享存储、网络或登录节点）时，单个集群中的多个*队列*通常优先于多个集群。如果工作负载具有相似的计算、存储和网络需求，则在单个集群中使用多个队列会更高效，因为它允许资源共享并避免不必要的重复。这种方法简化了管理，减少了开销，同时还能实现高效的作业调度和资源分配。另一方面，当工作负载之间存在很强的安全、数据或操作隔离要求时，应使用多个*集群*。例如，如果您需要使用不同的计划、更新周期或访问策略独立管理和操作工作负载，则多个集群更合适。
**集群队列和计算资源配额**
| 资源 | 限额 |
| --- | --- |
| [`Slurm queues`](Scheduling-v3.md#Scheduling-v3-SlurmQueues) | 每个集群 50 个队列 |
| [`Compute resources`](Scheduling-v3.md#Scheduling-v3-SlurmQueues-ComputeResources) | 每个队列 50 个计算资源 每个集群 50 个计算资源 |
**节点数**
队列的 [`ComputeResources`](Scheduling-v3.md#Scheduling-v3-SlurmQueues-ComputeResources) 中的每个计算资源都必须具有唯一的 [`Name`](Scheduling-v3.md#yaml-Scheduling-SlurmQueues-ComputeResources-Name)、[`InstanceType`](Scheduling-v3.md#yaml-Scheduling-SlurmQueues-ComputeResources-InstanceType)、[`MinCount`](Scheduling-v3.md#yaml-Scheduling-SlurmQueues-ComputeResources-MinCount) 和 [`MaxCount`](Scheduling-v3.md#yaml-Scheduling-SlurmQueues-ComputeResources-MaxCount)。[`MinCount`](Scheduling-v3.md#yaml-Scheduling-SlurmQueues-ComputeResources-MinCount) 和 [`MaxCount`](Scheduling-v3.md#yaml-Scheduling-SlurmQueues-ComputeResources-MaxCount) 具有默认值，用于定义队列的 [`ComputeResources`](Scheduling-v3.md#Scheduling-v3-SlurmQueues-ComputeResources) 中的计算资源的实例范围。您也可以为 [`MinCount`](Scheduling-v3.md#yaml-Scheduling-SlurmQueues-ComputeResources-MinCount) 和 [`MaxCount`](Scheduling-v3.md#yaml-Scheduling-SlurmQueues-ComputeResources-MaxCount) 指定自己的值。[`ComputeResources`](Scheduling-v3.md#Scheduling-v3-SlurmQueues-ComputeResources) 中的每个计算资源均由编号为 1 到 [`MinCount`](Scheduling-v3.md#yaml-Scheduling-SlurmQueues-ComputeResources-MinCount) 值的静态节点和编号为 [`MinCount`](Scheduling-v3.md#yaml-Scheduling-SlurmQueues-ComputeResources-MinCount) 值到 [`MaxCount`](Scheduling-v3.md#yaml-Scheduling-SlurmQueues-ComputeResources-MaxCount) 值的动态节点组成。
**示例配置**
下面是集群配置文件的 [Scheduling](Scheduling-v3.md) 部分的示例。在此配置中，有两个名为 `queue1` 和 `queue2` 的队列，每个队列的 [`ComputeResources`](Scheduling-v3.md#Scheduling-v3-SlurmQueues-ComputeResources) 都指定了 [`MaxCount`](Scheduling-v3.md#yaml-Scheduling-SlurmQueues-ComputeResources-MaxCount)。
```
Scheduling:
Scheduler: slurm
SlurmQueues:
- Name: queue1
ComputeResources:
- InstanceType: c5.xlarge
MaxCount: 5
Name: c5xlarge
- InstanceType: c4.xlarge
MaxCount: 5
Name: c4xlarge
- Name: queue2
ComputeResources:
- InstanceType: c5.xlarge
MaxCount: 5
Name: c5xlarge
```
**主机名**
启动到计算实例集中的实例是动态分配的。将为每个节点生成主机名。默认情况下， AWS ParallelCluster 将使用以下格式的主机名：
`$HOSTNAME=$QUEUE-$STATDYN-$COMPUTE_RESOURCE-$NODENUM`
+ `$QUEUE` 是队列的名称。例如，如果 [`SlurmQueues`](Scheduling-v3.md#Scheduling-v3-SlurmQueues) 部分中的条目将 [`Name`](Scheduling-v3.md#yaml-Scheduling-SlurmQueues-Name) 设置为“`queue-name`”，则“`$QUEUE`”为“`queue-name`”。
+ 对于静态节点，`$STATDYN` 为 `st`，对于动态节点则为 `dy`。
+ `$COMPUTE_RESOURCE` 是与此节点对应的 [`ComputeResources`](Scheduling-v3.md#Scheduling-v3-SlurmQueues-ComputeResources) 计算资源的 [`Name`](Scheduling-v3.md#yaml-Scheduling-SlurmQueues-ComputeResources-Name)。
+ `$NODENUM` 是节点的编号。对于静态节点，`$NODENUM` 介于一 (1) 和 [`MinCount`](Scheduling-v3.md#yaml-Scheduling-SlurmQueues-ComputeResources-MinCount) 的值之间，对于动态节点，则介于一 (1) 和 [`MaxCount`](Scheduling-v3.md#yaml-Scheduling-SlurmQueues-ComputeResources-MaxCount)-[`MinCount`](Scheduling-v3.md#yaml-Scheduling-SlurmQueues-ComputeResources-MinCount) 之间。
根据上面的示例配置文件，`queue1` 和计算资源 `c5xlarge` 的给定节点的主机名为：`queue1-dy-c5xlarge-1`。
主机名和完全限定域名 (FQDN) 都是使用 Amazon Route 53 托管区创建的。FQDN 是 `$HOSTNAME.$CLUSTERNAME.pcluster`，其中 `$CLUSTERNAME` 是集群的名称。
请注意，Slurm 节点名称也将使用相同的格式。
用户可以选择使用为计算节点提供支持的实例的默认 Amazon EC2 主机名，而不是使用的默认主机名格式 AWS ParallelCluster。这可通过将 [`UseEc2Hostnames`](Scheduling-v3.md#yaml-Scheduling-SlurmSettings-Dns-UseEc2Hostnames) 参数设置为 true 来完成。但是，Slurm节点名称将继续使用默认 AWS ParallelCluster 格式。
# Slurm 多队列模式指南
在这里，您可以了解如何 AWS ParallelCluster Slurm和管理队列（分区）节点，以及如何监控队列和节点状态。
## 概述
扩展架构基于 Slurm 的[云调度指南](https://slurm.schedmd.com/elastic_computing.html)和节能插件。有关节能插件的更多信息，请参阅 [Slurm Power Saving Guide](https://slurm.schedmd.com/power_save.html)。在该架构中，可能可供集群使用的资源通常在 Slurm 配置中预定义为云节点。
## 云节点生命周期
在整个生命周期中，云节点会进入以下几种（如果不是全部）状态：`POWER_SAVING`、`POWER_UP` (`pow_up`)、`ALLOCATED` (`alloc`) 和 `POWER_DOWN` (`pow_dn`)。在某些情况下，云节点可能会进入 `OFFLINE` 状态。下面的列表详细介绍了云节点生命周期中这些状态的几个方面。
+ **处于 `POWER_SAVING` 状态的节点**在 `sinfo` 中显示 `~` 后缀（例如 `idle~`） 在这种状态下，没有支持该节点的 EC2 实例。但 Slurm 仍然可以向该节点分配作业。
+ **正在过渡到 `POWER_UP` 状态的节点**将在 `sinfo` 中显示 `#` 后缀（例如 `idle#`）。当 Slurm 向处于 `POWER_SAVING` 状态的节点分配作业时，该节点会自动转变为 `POWER_UP` 状态。
或者，您可以以 `su` 根用户身份使用以下命令将节点手动转变为 `POWER_UP` 状态：
```
$ scontrol update nodename=nodename state=power_up
```
在此阶段，将调用 `ResumeProgram`，启动并配置 EC2 实例，并且节点会过渡到 `POWER_UP` 状态。
+ **当前可供使用的节点**在 `sinfo` 中不显示后缀（例如 `idle`）。节点设置完毕并加入集群后，即可用于运行作业。在此阶段，节点已正确配置并可供使用。
一般而言，我们建议 Amazon EC2 实例的数量与可用节点的数量相同。在大多数情况下，在创建集群后，静态节点即可用。
+ **正在过渡到 `POWER_DOWN` 状态的节点**在 `sinfo` 中显示 `%` 后缀（例如 `idle%`）。经过 [`ScaledownIdletime`](Scheduling-v3.md#yaml-Scheduling-SlurmSettings-ScaledownIdletime) 之后，动态节点会自动进入 `POWER_DOWN` 状态。相比之下，静态节点在大多数情况下不会关闭。但您可以以 `su` 根用户身份使用以下命令将节点手动置于 `POWER_DOWN` 状态：
```
$ scontrol update nodename=nodename state=down reason="manual draining"
```
在此状态下，与节点关联的实例将会终止，节点将设置回 `POWER_SAVING` 状态并在经过 [`ScaledownIdletime`](Scheduling-v3.md#yaml-Scheduling-SlurmSettings-ScaledownIdletime) 之后可供使用。
[`ScaledownIdletime`](Scheduling-v3.md#yaml-Scheduling-SlurmSettings-ScaledownIdletime) 设置保存到 Slurm 配置中的 `SuspendTimeout` 设置。
+ **离线的节点**将在 `sinfo` 中显示 `*` 后缀（例如 `down*`）。如果 Slurm 控制器无法联系某个节点，或者静态节点被禁用并且支持实例被终止，则该节点将会离线。
请考虑以下 `sinfo` 示例中所示的节点状态。
```
$ sinfo
PARTITION AVAIL TIMELIMIT NODES STATE NODELIST
efa up infinite 4 idle~ efa-dy-efacompute1-[1-4]
efa up infinite 1 idle efa-st-efacompute1-1
gpu up infinite 1 idle% gpu-dy-gpucompute1-1
gpu up infinite 9 idle~ gpu-dy-gpucompute1-[2-10]
ondemand up infinite 2 mix# ondemand-dy-ondemandcompute1-[1-2]
ondemand up infinite 18 idle~ ondemand-dy-ondemandcompute1-[3-10],ondemand-dy-ondemandcompute2-[1-10]
spot* up infinite 13 idle~ spot-dy-spotcompute1-[1-10],spot-dy-spotcompute2-[1-3]
spot* up infinite 2 idle spot-st-spotcompute2-[1-2]
```
`spot-st-spotcompute2-[1-2]` 和 `efa-st-efacompute1-1` 节点已经设置了支持实例，并且可供使用。`ondemand-dy-ondemandcompute1-[1-2]` 节点处于 `POWER_UP` 状态，应会在几分钟内可用。`gpu-dy-gpucompute1-1` 节点处于 `POWER_DOWN` 状态，它将在 [`ScaledownIdletime`](Scheduling-v3.md#yaml-Scheduling-SlurmSettings-ScaledownIdletime)（默认为 10 分钟）之后过渡到 `POWER_SAVING` 状态。
所有其他节点都处于 `POWER_SAVING` 状态，没有支持它们的 EC2 实例。
## 使用可用节点
可用节点由 Amazon EC2 实例提供支持。默认情况下，可以使用节点名称直接通过 SSH 加入到实例中（例如 `ssh efa-st-efacompute1-1`）。可以使用以下命令来检索实例的私有 IP 地址：
```
$ scontrol show nodes nodename
```
在返回的 `NodeAddr` 字段中检查 IP 地址。
对于不可用的节点，`NodeAddr` 字段不应指向正在运行的 Amazon EC2 实例，而是应与节点名称相同。
## 作业状态和提交
在大多数情况下，提交的作业会立即分配给系统中的节点，或者如果所有节点都已分配，则将其置于待处理状态。
如果为作业分配的节点包括任何处于 `POWER_SAVING` 状态的节点，则该作业将以 `CF` 或 `CONFIGURING` 状态开始。此时，该作业将会等待处于 `POWER_SAVING` 状态的节点过渡到 `POWER_UP` 状态并变为可用。
为作业分配的所有节点都可用后，该作业将进入 `RUNNING` (`R`) 状态。
默认情况下，所有作业都提交到默认队列（在 Slurm 中称为分区）。此队列由队列名称后面的后缀 `*` 表示。您可以使用 `-p` 作业提交选项选择队列。
所有节点都配置了以下特征，这些特征可以在作业提交命令中使用：
+ 实例类型（例如 `c5.xlarge`）。
+ 节点类型（`dynamic` 或 `static`。）
您可以使用以下命令查看特定节点的特征：
```
$ scontrol show nodes nodename
```
在返回的结果中，查看 `AvailableFeatures` 列表。
考虑集群的初始状态，可以通过运行 `sinfo` 命令来查看该状态。
```
$ sinfo
PARTITION AVAIL TIMELIMIT NODES STATE NODELIST
efa up infinite 4 idle~ efa-dy-efacompute1-[1-4]
efa up infinite 1 idle efa-st-efacompute1-1
gpu up infinite 10 idle~ gpu-dy-gpucompute1-[1-10]
ondemand up infinite 20 idle~ ondemand-dy-ondemandcompute1-[1-10],ondemand-dy-ondemandcompute2-[1-10]
spot* up infinite 13 idle~ spot-dy-spotcompute1-[1-10],spot-dy-spotcompute2-[1-3]
spot* up infinite 2 idle spot-st-spotcompute2-[1-2]
```
请注意，`spot` 是默认队列。它由 `*` 后缀表示。
向默认队列 (`spot`) 中的一个静态节点提交作业。
```
$ sbatch --wrap "sleep 300" -N 1 -C static
```
向 `EFA` 队列中的一个动态节点提交作业。
```
$ sbatch --wrap "sleep 300" -p efa -C dynamic
```
向 `ondemand` 队列中的八 (8) 个 `c5.2xlarge` 节点和两 (2) 个 `t2.xlarge` 节点提交作业。
```
$ sbatch --wrap "sleep 300" -p ondemand -N 10 -C "[c5.2xlarge*8&t2.xlarge*2]"
```
向 `gpu` 队列中的一个 GPU 节点提交作业。
```
$ sbatch --wrap "sleep 300" -p gpu -G 1
```
考虑使用 `squeue` 命令的作业状态。
```
$ squeue
JOBID PARTITION NAME USER ST TIME NODES NODELIST(REASON)
12 ondemand wrap ubuntu CF 0:36 10 ondemand-dy-ondemandcompute1-[1-8],ondemand-dy-ondemandcompute2-[1-2]
13 gpu wrap ubuntu CF 0:05 1 gpu-dy-gpucompute1-1
7 spot wrap ubuntu R 2:48 1 spot-st-spotcompute2-1
8 efa wrap ubuntu R 0:39 1 efa-dy-efacompute1-1
```
作业 7 和 8（在 `spot` 和 `efa` 队列中）已经在运行 (`R`)。作业 12 和 13 仍在配置 (`CF`)，可能正在等待实例变为可用。
```
# Nodes states corresponds to state of running jobs
$ sinfo
PARTITION AVAIL TIMELIMIT NODES STATE NODELIST
efa up infinite 3 idle~ efa-dy-efacompute1-[2-4]
efa up infinite 1 mix efa-dy-efacompute1-1
efa up infinite 1 idle efa-st-efacompute1-1
gpu up infinite 1 mix~ gpu-dy-gpucompute1-1
gpu up infinite 9 idle~ gpu-dy-gpucompute1-[2-10]
ondemand up infinite 10 mix# ondemand-dy-ondemandcompute1-[1-8],ondemand-dy-ondemandcompute2-[1-2]
ondemand up infinite 10 idle~ ondemand-dy-ondemandcompute1-[9-10],ondemand-dy-ondemandcompute2-[3-10]
spot* up infinite 13 idle~ spot-dy-spotcompute1-[1-10],spot-dy-spotcompute2-[1-3]
spot* up infinite 1 mix spot-st-spotcompute2-1
spot* up infinite 1 idle spot-st-spotcompute2-2
```
## 节点状态和特征
在大多数情况下，节点状态完全由 AWS ParallelCluster 根据本主题前面所述的云节点生命周期中的特定流程进行管理。
但是， AWS ParallelCluster 还会替换或终止处于不健康`DRAINED`状态的节点`DOWN`和具有不健康后备实例的节点。有关更多信息，请参阅 [`clustermgtd`](processes-v3.md#clustermgtd-v3)。
## 分区状态
AWS ParallelCluster 支持以下分区状态。Slurm 分区就是 AWS ParallelCluster中的队列。
+ `UP`：表示该分区处于活动状态。这是分区的默认状态。在此状态下，该分区中的所有节点都处于活动状态并且可供使用。
+ `INACTIVE`：表示该分区处于非活动状态。在此状态下，将会终止支持非活动分区的节点的所有实例。不会为非活动分区中的节点启动新实例。
## 集群 update-compute-fleet
+ **停止计算队列**-执行以下命令时，所有分区都将`INACTIVE`转换为状态， AWS ParallelCluster 进程将分区保持`INACTIVE`状态。
```
$ pcluster update-compute-fleet --cluster-name testSlurm \
--region eu-west-1 --status STOP_REQUESTED
```
+ **启动计算实例集** - 执行以下命令时，所有分区最初都将转变为 `UP` 状态。但是， AWS ParallelCluster 进程不会使分区保持`UP`状态。您需要手动更改分区状态。所有静态节点将在几分钟后变为可用。请注意，将分区设置为 `UP` 不会增加任何动态容量。
```
$ pcluster update-compute-fleet --cluster-name testSlurm \
--region eu-west-1 --status START_REQUESTED
```
当运行 `update-compute-fleet` 时，您可以通过运行 `pcluster describe-compute-fleet` 命令并检查 `Status` 来查看集群的状态。下面列出了可能的状态：
+ `STOP_REQUESTED`：停止计算实例集请求已发送到集群。
+ `STOPPING`：`pcluster` 进程当前正在停止计算实例集。
+ `STOPPED`：`pcluster` 进程已完成停止进程，所有分区都处于 `INACTIVE` 状态，并且所有计算实例都已终止。
+ `START_REQUESTED`：启动计算实例集请求已发送到集群。
+ `STARTING`：`pcluster` 进程当前正在启动集群。
+ `RUNNING`：`pcluster` 进程已完成启动过程，所有分区都处于 `UP` 状态，静态节点将在几分钟后可用。
+ `PROTECTED`：此状态表示某些分区持续出现引导故障。受影响的分区处于非活动状态。请调查问题，然后运行 `update-compute-fleet` 以重新启用该实例集。
## 队列的手动控制
在某些情况下，您可能需要对集群中的节点或队列（在 Slurm 中称为分区）进行一些手动控制。您可以使用 `scontrol` 命令通过以下常用过程管理集群中的节点。
+ **启动处于 `POWER_SAVING` 状态的动态节点**
`su`以根用户身份运行以下命令：
```
$ scontrol update nodename=nodename state=power_up
```
您也可以提交占位符 `sleep 1` 作业，请求一定数量的节点，然后依赖于 Slurm 来启动所需数量的节点。
+ **在 [`ScaledownIdletime`](Scheduling-v3.md#yaml-Scheduling-SlurmSettings-ScaledownIdletime) 之前关闭动态节点**
我们建议您以 `su` 根用户身份使用以下命令将动态节点设置为 `DOWN`：
```
$ scontrol update nodename=nodename state=down reason="manually draining"
```
AWS ParallelCluster 自动终止并重置已关闭的动态节点。
通常，我们不建议直接使用 `scontrol update nodename=nodename state=power_down` 命令将节点设置为 `POWER_DOWN`。这是因为 AWS ParallelCluster 会自动处理关闭过程，
+ **禁用队列（分区）或停止特定分区中的所有静态节点**
以 `su` 根用户身份使用以下命令将特定队列设置为 `INACTIVE`：
```
$ scontrol update partition=queuename state=inactive
```
此操作会终止支持该分区中节点的所有实例。
+ **启用队列（分区）**
以 `su` 根用户身份使用以下命令将特定队列设置为 `UP`：
```
$ scontrol update partition=queuename state=up
```
## 扩展行为和调整
**下面是正常扩展工作流程的示例：**
+ 调度器收到需要两个节点的作业。
+ 调度器将两个节点转换为 `POWER_UP` 状态，并使用节点名称（例如 `queue1-dy-spotcompute1-[1-2]`）调用 `ResumeProgram`。
+ `ResumeProgram` 启动两个 Amazon EC2 实例并分配 `queue1-dy-spotcompute1-[1-2]` 的私有 IP 地址和主机名，等待 `ResumeTimeout`（默认时段为 30 分钟），然后重置节点。
+ 实例配置完成并加入集群。作业开始在实例上运行。
+ 作业完成并停止运行。
+ 经过配置的 `SuspendTime`（设置为 [`ScaledownIdletime`](Scheduling-v3.md#yaml-Scheduling-SlurmSettings-ScaledownIdletime)）后，调度器将实例设置为 `POWER_SAVING` 状态。然后，调度器将 `queue1-dy-spotcompute1-[1-2]` 设置为 `POWER_DOWN` 状态并使用节点名称调用 `SuspendProgram`。
+ 为两个节点调用 `SuspendProgram`。节点保持在 `POWER_DOWN` 状态，例如通过保持 `idle%` 状态持续 `SuspendTimeout`（默认时段为 120 秒（2 分钟））。在 `clustermgtd` 检测到节点正在关闭后，它会终止支持实例。然后，它将 `queue1-dy-spotcompute1-[1-2]` 转变到空闲状态并重置私有 IP 地址和主机名，使其能够启动以供将来的作业使用。
**如果出现问题，特定节点的某个实例由于某种原因无法启动，则会发生以下情况：**
+ 调度器收到需要两个节点的作业。
+ 调度器将两个云爆发节点转变为 `POWER_UP` 状态，并使用节点名称（例如 `queue1-dy-spotcompute1-[1-2]`）调用 `ResumeProgram`。
+ `ResumeProgram` 仅启动一（1）个 Amazon EC2 实例并配置 `queue1-dy-spotcompute1-1`，另一（1）个实例 `queue1-dy-spotcompute1-2` 未能启动。
+ `queue1-dy-spotcompute1-1` 未受影响，并在进入 `POWER_UP` 状态后上线。
+ `queue1-dy-spotcompute1-2` 转变为 `POWER_DOWN` 状态，并且由于 Slurm 检测到节点故障，自动将作业重新排队。
+ 经过 `SuspendTimeout`（默认为 120 秒（2 分钟））之后 `queue1-dy-spotcompute1-2` 变为可用。在此期间，作业将重新排队，并可以开始在另一个节点上运行。
+ 上述过程将会重复，直到作业可以在可用节点上运行而不发生故障。
**有两个定时参数可以根据需要进行调整：**
+ **`ResumeTimeout`（默认为 30 分钟）：**`ResumeTimeout` 控制 Slurm 将节点转变为关闭状态之前等待的时间。
+ `ResumeTimeout`如果您的 pre/post 安装过程花费了将近那么长的时间，那么扩展可能会很有用。
+ `ResumeTimeout` 也是在出现问题的情况下 AWS ParallelCluster 在替换或重置节点之前等待的最长时间。如果在启动或设置过程中发生任何错误，则计算节点会自行终止。 AWS ParallelCluster 检测到已终止的实例后，进程会替换节点。
+ **`SuspendTimeout`（默认为 120 秒（2 分钟））**：`SuspendTimeout` 控制将节点放回系统并准备好再次使用的速率。
+ `SuspendTimeout` 越短，节点重置就会越快，并且 Slurm 能够更频繁地尝试启动实例。
+ `SuspendTimeout` 越长，故障节点的重置就会越慢。在此期间，Slurm 会尝试使用其他节点。如果 `SuspendTimeout` 超过几分钟，则 Slurm 将会循环尝试系统中的所有节点。对于大型系统（超过 1000 个节点），较长的 `SuspendTimeout` 可能有利于减轻 Slurm 上因频繁尝试对失败作业重新排队而产生的压力。
+ 请注意，`SuspendTimeout`这并不是指 AWS ParallelCluster 等待终止节点的后备实例的时间。`POWER_DOWN` 节点的支持实例将会立即终止。终止过程通常在几分钟内完成。但在此期间，节点仍处于 `POWER_DOWN` 状态，无法供调度器使用。
## 架构的日志
以下列表包含关键日志。与 Amazon Logs 一起使用的 CloudWatch 日志流名称的格式*logIdentifier*为`{hostname}.{instance_id}.{logIdentifier}`，后面是日志名称。
+ `ResumeProgram`: `/var/log/parallelcluster/slurm_resume.log` (`slurm_resume`)
+ `SuspendProgram`: `/var/log/parallelcluster/slurm_suspend.log` (`slurm_suspend`)
+ `clustermgtd`: `/var/log/parallelcluster/clustermgtd.log` (`clustermgtd`)
+ `computemgtd`: `/var/log/parallelcluster/computemgtd.log` (`computemgtd`)
+ `slurmctld`: `/var/log/slurmctld.log` (`slurmctld`)
+ `slurmd`: `/var/log/slurmd.log` (`slurmd`)
## 常见问题以及调试方法：
**无法启动、加电或加入集群的节点**
+ 动态节点：
+ 检查 `ResumeProgram` 日志，查看是否对该节点调用过 `ResumeProgram`。如果没有，请检查 `slurmctld` 日志以确定 Slurm 是否尝试过对该节点调用 `ResumeProgram`。请注意，`ResumeProgram` 上不正确的权限可能会导致它静默失败。
+ 如果调用了 `ResumeProgram`，请查看是否为该节点启动了实例。如果未启动实例，则应有明确的错误消息，说明实例启动失败的原因。
+ 如果启动了实例，则可能在引导过程中出现了问题。从`ResumeProgram`日志中找到相应的私有 IP 地址和实例 ID，然后在 Logs 中查看特定实例的相应引导 CloudWatch 日志。
+ 静态节点：
+ 检查 `clustermgtd` 日志，查看是否为该节点启动了实例。如果实例未启动，则应有明确的错误说明实例启动失败的原因。
+ 如果启动了实例，则引导过程出现了问题。从`clustermgtd`日志中找到相应的私有 IP 和实例 ID，然后在 Logs 中查看特定实例的相应引导 CloudWatch 日志。
**节点意外替换或终止和节点故障**
+ 节点 replaced/terminated 出乎意料：
+ 在大多数情况下，`clustermgtd` 会处理所有节点维护操作。要检查 `clustermgtd` 是否替换或终止了节点，请查看 `clustermgtd` 日志。
+ 如果 `clustermgtd` 替换或终止了节点，则应显示一条消息，说明该操作的原因。如果原因与调度器有关（例如，节点处于 `DOWN` 状态），请查看 `slurmctld` 日志以获取更多详细信息。如果原因与亚马逊 EC2 有关，请使用诸如亚马逊 CloudWatch 或亚马逊 EC2 控制台、CLI 或软件开发工具包之类的工具来检查该实例的状态或日志。例如，您可以检查该实例是否有已安排的事件或失败的 Amazon EC2 运行状况检查。
+ 如果 `clustermgtd` 没有终止该节点，请检查 `computemgtd` 是否终止了该节点，或者 EC2 是否终止了该实例以回收竞价型实例。
+ 节点故障：
+ 在大多数情况下，如果节点出现故障，作业会自动重新排队。在 `slurmctld` 日志中查看作业或节点失败的原因，并在其中评测具体情况。
**替换或终止实例时出现故障、关闭节点时出现故障**
+ 通常，`clustermgtd` 会处理所有预期的实例终止操作。在 `clustermgtd` 日志中查看其无法替换或终止节点的原因。
+ 对于 [`ScaledownIdletime`](Scheduling-v3.md#yaml-Scheduling-SlurmSettings-ScaledownIdletime) 失败的动态节点，请在 `SuspendProgram` 日志中查看 `slurmctld` 进程是否以特定节点作为参数进行了调用。请注意，`SuspendProgram` 实际上并不执行任何特定的操作，它只是记录被调用时的时间。所有实例终止和 `NodeAddr` 重置均由 `clustermgtd` 完成。Slurm 会在 `SuspendTimeout` 后将节点转变为 `IDLE` 状态。
**其它问题：**
+ AWS ParallelCluster 不会做出工作分配或扩大规模的决策。它只是尝试按照 Slurm 的指示启动、终止和维护资源。
对于与作业分配、节点分配和扩展决策有关的问题，请查看 `slurmctld` 日志中是否存在错误。
# Slurm 集群保护模式
当集群在启用保护模式的情况下运行时，会在启动计算节点时 AWS ParallelCluster 监控和跟踪计算节点引导失败。这样做是为了检测这些失败是否持续发生。
如果在队列（分区）中检测到以下情况，集群将进入受保护状态：
1. 持续发生连续的计算节点引导失败，没有成功的计算节点启动。
1. 失败计数达到预定义的阈值。
集群进入保护状态后， AWS ParallelCluster 禁用故障等于或高于预定义阈值的队列。
Slurm 集群保护模式已在 3.0.0 AWS ParallelCluster 版中添加。
您可以使用受保护模式来减少在计算节点引导失败循环上花费的时间和资源。
## 受保护模式参数
**`protected_failure_count`**
`protected_failure_count` 指定队列（分区）中激活集群受保护状态的连续失败次数。
默认的 `protected_failure_count` 为 10 并启用受保护模式。
如果 `protected_failure_count` 大于零，则启用受保护模式。
如果 `protected_failure_count` 小于或等于零，则禁用受保护模式。
通过在 `HeadNode` 中 `/etc/parallelcluster/slurm_plugin/parallelcluster_clustermgtd.conf` 处的 `clustermgtd` 配置文件中添加该参数，可以更改 `protected_failure_count` 值。
您可以随时更新此参数，并且无需停止计算实例集即可执行此操作。如果在失败计数达到 `protected_failure_count` 之前在队列中启动成功，则失败计数将重置为零。
## 在受保护状态下检查集群状态
当集群处于受保护状态时，您可以检查计算实例集状态和节点状态。
### 计算实例集状态
在受保护状态下运行的集群的计算实例集状态为 `PROTECTED`。
```
$ pcluster describe-compute-fleet --cluster-name --region
{
"status": "PROTECTED",
"lastStatusUpdatedTime": "2022-04-22T00:31:24.000Z"
}
```
### 节点状态
要了解哪些队列（分区）的引导失败已激活受保护状态，请登录集群并运行 `sinfo` 命令。引导失败次数达到或超过 `protected_failure_count` 的分区处于 `INACTIVE` 状态。引导失败次数未达到或超过 `protected_failure_count` 的分区处于 `UP` 状态并正常工作。
`PROTECTED` 状态不影响正在运行的作业。如果作业正在引导失败次数达到或超过 `protected_failure_count` 的分区上运行，则正在运行的作业完成后会将该分区设置为 `INACTIVE`。
请考虑以下示例中所示的节点状态。
```
$ sinfo
PARTITION AVAIL TIMELIMIT NODES STATE NODELIST
queue1* inact infinite 10 down% queue1-dy-c5xlarge-[1-10]
queue1* inact infinite 3490 idle~ queue1-dy-c5xlarge-[11-3500]
queue2 up infinite 10 idle~ queue2-dy-c5xlarge-[1-10]
```
分区 `queue1` 为 `INACTIVE`，因为检测到连续 10 次计算节点引导失败。
节点 `queue1-dy-c5xlarge-[1-10]` 后面的实例已启动，但由于运行状况不佳，未能加入集群。
集群处于受保护状态。
分区 `queue2` 不受 `queue1` 中的引导失败的影响。它处于 `UP` 状态并且仍然可以运行作业。
## 如何停用受保护状态
解决引导错误后，您可以运行以下命令使集群退出受保护状态。
```
$ pcluster update-compute-fleet --cluster-name \
--region \
--status START_REQUESTED
```
## 激活受保护状态的引导失败
激活受保护状态的引导错误细分为以下三种类型。要确定类型和问题，您可以检查是否 AWS ParallelCluster 生成的日志。如果生成了日志，则可以检查这些日志以查看错误详细信息。有关更多信息，请参阅 [检索和保留日志](troubleshooting-v3-get-logs.md)。
1. **导致实例自行终止的引导错误。**
实例在引导过程的早期失败，例如由于 [`SlurmQueues`](Scheduling-v3.md#Scheduling-v3-SlurmQueues)\$1[`CustomActions`](Scheduling-v3.md#Scheduling-v3-SlurmQueues-CustomActions)\$1[`OnNodeStart`](Scheduling-v3.md#yaml-Scheduling-SlurmQueues-CustomActions-OnNodeStart)\$1[`OnNodeConfigured`](Scheduling-v3.md#yaml-Scheduling-SlurmQueues-CustomActions-OnNodeConfigured) 脚本中的错误而自行终止的实例。
对于动态节点，请查找类似于下面的错误：
```
Node bootstrap error: Node ... is in power up state without valid backing instance
```
对于静态节点，请在 `clustermgtd` 日志 (`/var/log/parallelcluster/clustermgtd`) 中查找类似于下面的错误：
```
Node bootstrap error: Node ... is in power up state without valid backing instance
```
1. **节点 `resume_timeout` 或 `node_replacement_timeout` 过期**。
实例无法在 `resume_timeout` 内（对于动态节点）或 `node_replacement_timeout` 内（对于静态节点）加入集群。它不会在超时之前自行终止。例如，群集的网络设置不正确，节点的`DOWN`状态设置为 Slurm 超时到期后。
对于动态节点，请查找类似于下面的错误：
```
Node bootstrap error: Resume timeout expires for node
```
对于静态节点，请在 `clustermgtd` 日志 (`/var/log/parallelcluster/clustermgtd`) 中查找类似于下面的错误：
```
Node bootstrap error: Replacement timeout expires for node ... in replacement.
```
1. **节点未通过运行状况检查**。
节点后面的实例未通过 Amazon EC2 运行状况检查或计划的事件运行状况检查，并且这些节点被视为引导失败节点。在这种情况下，实例因超出控制范围的原因而终止。 AWS ParallelCluster
请在 `clustermgtd` 日志 (`/var/log/parallelcluster/clustermgtd`) 中查找类似于下面的错误：
```
Node bootstrap error: Node %s failed during bootstrap when performing health check.
```
1. **计算节点出现故障 Slurm 注册**。
将`slurmd`守护程序注册到 Slurm control daemon (`slurmctld`) 失败并导致计算节点状态更改为`INVALID_REG`状态。配置不正确 Slurm 计算节点可能导致此错误，例如配置了计算节点规格错误的[`CustomSlurmSettings`](Scheduling-v3.md#yaml-Scheduling-SlurmQueues-ComputeResources-CustomSlurmSettings)计算节点。
在头节点上的 `slurmctld` 日志文件 (`/var/log/slurmctld.log`) 或失败的计算节点上的 `slurmd` 日志文件 (`/var/log/slurmd.log`) 中查找类似于下面的错误：
```
Setting node %s to INVAL with reason: ...
```
## 如何调试受保护模式
如果您的集群处于受保护状态，并且 AWS ParallelCluster 生成了来自的`clustermgtd`日志`HeadNode`以及来自有问题的计算节点的`cloud-init-output`日志，则可以查看日志以了解错误详情。有关如何检索日志的更多信息，请参阅[检索和保留日志](troubleshooting-v3-get-logs.md)。
**头节点上的 `clustermgtd` 日志 (`/var/log/parallelcluster/clustermgtd`)**
日志消息会显示哪些分区发生了引导失败以及相应的引导失败计数。
```
[slurm_plugin.clustermgtd:_handle_protected_mode_process] - INFO - Partitions
bootstrap failure count: {'queue1': 2}, cluster will be set into protected mode if protected failure count reach threshold.
```
在 `clustermgtd` 日志中，搜索 `Found the following bootstrap failure nodes` 以查找哪个节点引导失败。
```
[slurm_plugin.clustermgtd:_handle_protected_mode_process] - WARNING -
Found the following bootstrap failure nodes: (x2) ['queue1-st-c5large-1(192.168.110.155)', 'broken-st-c5large-2(192.168.65.215)']
```
在 `clustermgtd` 日志中，搜索 `Node bootstrap error` 以查找失败的原因。
```
[slurm_plugin.clustermgtd:_is_node_bootstrap_failure] - WARNING - Node bootstrap error:
Node broken-st-c5large-2(192.168.65.215) is currently in replacement and no backing instance
```
**计算节点上的 `cloud-init-output` 日志 (`/var/log/cloud-init-output.log`)**
在 `clustermgtd` 日志中获取引导失败节点的私有 IP 地址后，您可以登录计算节点或按照[检索和保留日志](troubleshooting-v3-get-logs.md)中的指导检索日志，找到相应的计算节点日志。在大多数情况下，有问题的节点的 `/var/log/cloud-init-output` 日志会显示导致计算节点引导失败的步骤。
# Slurm 集群快速容量不足故障转移
从 AWS ParallelCluster 版本 3.2.0 开始，集群在默认情况下会启用快速容量不足故障转移模式。这会最大限度地减少检测到 Amazon EC2 容量不足错误时对作业重试排队所花费的时间。当您将队列配置为使用不同实例类型的多个计算资源时，这尤其有效。
**Amazon EC2 检测到容量不足故障：**
+ `InsufficientInstanceCapacity`
+ `InsufficientHostCapacity`
+ `InsufficientReservedInstanceCapacity`
+ `MaxSpotInstanceCountExceeded`
+ `SpotMaxPriceTooLow`：竞价型请求价格低于要求的最低竞价型请求履行价格时激活。
+ `Unsupported`：使用特定实例类型不支持的实例类型激活 AWS 区域。
在快速容量不足故障切换模式下，如果在将任务分配给 [`SlurmQueues`](Scheduling-v3.md#Scheduling-v3-SlurmQueues)/时检测到容量不足错误 [`compute resource`](Scheduling-v3.md#Scheduling-v3-SlurmQueues-ComputeResources)，则 AWS ParallelCluster 执行以下操作：
1. 将计算资源设置为禁用 (`DOWN`) 状态，持续预定义的时间段。
1. 使用 `POWER_DOWN_FORCE` 取消计算资源失败的节点作业并暂停失败的节点。将失败的节点设置为 `IDLE` 和 `POWER_DOWN (!)` 状态，然后设置为 `POWERING_DOWN (%)`。
1. 将作业重新排队到另一个计算资源。
已禁用计算资源的静态和已启动的节点不受影响。作业可以在这些节点上完成。
此循环将会重复，直到将作业成功分配给一个或多个计算资源节点。有关节点状态的信息，请参阅 [Slurm 多队列模式指南](multiple-queue-mode-slurm-user-guide-v3.md)。
如果找不到运行该作业的计算资源，则将作业设置为 `PENDING` 状态，直到经过预定义的时间段。在这种情况下，您可以按照下一节所述修改预定义时间段。
## 容量不足超时参数
**`insufficient_capacity_timeout`**
`insufficient_capacity_timeout` 指定检测到容量不足错误时，计算资源保持在禁用 (`down`) 状态的时间段（以秒为单位）。
默认情况下，`insufficient_capacity_timeout` 处于启用状态。
默认的 `insufficient_capacity_timeout` 为 600 秒（10 分钟）。
如果 `insufficient_capacity_timeout` 值小于或等于零，则表示已禁用快速容量不足故障转移模式。
通过在 `HeadNode` 中 `/etc/parallelcluster/slurm_plugin/parallelcluster_clustermgtd.conf` 处的 `clustermgtd` 配置文件中添加该参数，可以更改 `insufficient_capacity_timeout` 值。
可以在不停止计算实例集的情况下随时更新该参数。
例如：
+ `insufficient_capacity_timeout=600`:
如果检测到容量不足错误，则会将计算资源设置为禁用 (`DOWN`)。10 分钟后，其失败节点将设置为 `idle~` (`POWER_SAVING`) 状态。
+ `insufficient_capacity_timeout=60`:
如果检测到容量不足错误，则计算资源将处于禁用状态 (`DOWN`)。1 分钟后，其失败节点将设置为 `idle~` 状态。
+ `insufficient_capacity_timeout=0`:
禁用了快速容量不足故障转移模式。未禁用计算资源。
**注意**
从节点因容量不足错误而失败到集群管理进程守护程序检测到节点失败之间可能有长达一分钟的延迟。这是因为集群管理守护程序会检查节点容量不足故障，并每隔一分钟将计算资源设置为`down`状态。
## 快速容量不足故障转移模式状态
当集群处于快速容量不足故障转移模式时，您可以检查其状态和节点状态。
### 节点状态
当作业提交到计算资源动态节点并检测到容量不足错误时，该节点将被置于 `down#` 状态并显示原因：
```
(Code:InsufficientInstanceCapacity)Failure when resuming nodes.
```
然后，关闭的节点（处于 `idle~` 状态的节点）将被设置为 `down~` 并显示原因：
```
(Code:InsufficientInstanceCapacity)Temporarily disabling node due to insufficient capacity.
```
作业重新排队到队列中的其他计算资源。
计算资源静态节点和处于 `UP` 状态的节点不受快速容量不足故障转移模式影响。
请考虑以下示例中所示的节点状态。
```
$ sinfo
PARTITION AVAIL TIMELIMIT NODES STATE NODELIST
queue1* up infinite 30 idle~ queue1-dy-c-1-[1-15],queue1-dy-c-2-[1-15]
queue2 up infinite 30 idle~ queue2-dy-c-1-[1-15],queue2-dy-c-2-[1-15]
```
我们向 queue1 提交了需要一个节点的作业。
```
$ sinfo
PARTITION AVAIL TIMELIMIT NODES STATE NODELIST
queue1* up infinite 1 down# queue1-dy-c-1-1
queue1* up infinite 15 idle~ queue1-dy-c-2-[1-15]
queue1* up infinite 14 down~ queue1-dy-c-1-[2-15]
queue2 up infinite 30 idle~ queue2-dy-c-1-[1-15],queue2-dy-c-2-[1-15]
```
节点 `queue1-dy-c-1-1` 将会启动以运行该作业。但由于容量不足错误，该实例启动失败。节点 `queue1-dy-c-1-1` 被设置为 `down`。该计算资源中已关闭的动态节点 (`queue2-dy-c-1`) 将被设置为 `down`。
您可以使用 `scontrol show nodes` 检查节点原因。
```
$ scontrol show nodes queue1-dy-c-1-1
NodeName=broken-dy-c-2-1 Arch=x86_64 CoresPerSocket=1
CPUAlloc=0 CPUTot=96 CPULoad=0.00
...
ExtSensorsJoules=n/s ExtSensorsWatts=0 ExtSensorsTemp=n/s
Reason=(Code:InsufficientInstanceCapacity)Failure when resuming nodes [root@2022-03-10T22:17:50]
$ scontrol show nodes queue1-dy-c-1-2
NodeName=broken-dy-c-2-1 Arch=x86_64 CoresPerSocket=1
CPUAlloc=0 CPUTot=96 CPULoad=0.00
...
ExtSensorsJoules=n/s ExtSensorsWatts=0 ExtSensorsTemp=n/s
Reason=(Code:InsufficientInstanceCapacity)Temporarily disabling node due to insufficient capacity [root@2022-03-10T22:17:50]
```
作业排队到队列计算资源中的另一种实例类型。
经过 `insufficient_capacity_timeout` 之后，计算资源中的节点将重置为 `idle~` 状态。
```
$ sinfo
PARTITION AVAIL TIMELIMIT NODES STATE NODELIST
queue1* up infinite 30 idle~ queue1-dy-c-1-[1-15],queue1-dy-c-2-[1-15]
queue2 up infinite 30 idle~ queue2-dy-c-1-[1-15],queue2-dy-c-2-[1-15]
```
经过 `insufficient_capacity_timeout` 并且计算资源中的节点重置为 `idle~` 状态后，Slurm 调度器会为这些节点分配较低的优先级。除非发生以下情况之一，否则调度器会继续从其他队列计算资源中选择权重较高的节点：
+ 作业的提交要求与已恢复的计算资源相匹配。
+ 没有其他计算资源可用，因为它们的容量已满。
+ `slurmctld` 已重新启动。
+ AWS ParallelCluster 计算队列已停止并开始关闭所有节点的电源并开启电源。
### 相关日志
可以在头节点的 Slurm `resume` 日志和 `clustermgtd` 日志中找到与容量不足错误和快速容量不足故障转移模式相关的日志。
**Slurm `resume` (`/var/log/parallelcluster/slurm_resume.log`)**
节点由于容量不足而无法启动时的错误消息。
```
[slurm_plugin.instance_manager:_launch_ec2_instances] - ERROR - Failed RunInstances request: dcd0c252-90d4-44a7-9c79-ef740f7ecd87
[slurm_plugin.instance_manager:add_instances_for_nodes] - ERROR - Encountered exception when launching instances for nodes (x1) ['queue1-dy-c-1-1']: An error occurred
(InsufficientInstanceCapacity) when calling the RunInstances operation (reached max retries: 1): We currently do not have sufficient p4d.24xlarge capacity in the
Availability Zone you requested (us-west-2b). Our system will be working on provisioning additional capacity. You can currently get p4d.24xlarge capacity by not
specifying an Availability Zone in your request or choosing us-west-2a, us-west-2c.
```
**Slurm `clustermgtd` (`/var/log/parallelcluster/clustermgtd`)**
queue1 中的计算资源 c-1 因容量不足而被禁用。
```
[slurm_plugin.clustermgtd:_reset_timeout_expired_compute_resources] - INFO - The following compute resources are in down state
due to insufficient capacity: {'queue1': {'c-1': ComputeResourceFailureEvent(timestamp=datetime.datetime(2022, 4, 14, 23, 0, 4, 769380, tzinfo=datetime.timezone.utc),
error_code='InsufficientInstanceCapacity')}}, compute resources are reset after insufficient capacity timeout (600 seconds) expired
```
容量不足超时到期后，将会重置该计算资源，并将计算资源中的节点设置为 `idle~`。
```
[root:_reset_insufficient_capacity_timeout_expired_nodes] - INFO - Reset the following compute resources because insufficient capacity
timeout expired: {'queue1': ['c-1']}
```
# Slurm 基于内存的调度
从 3.2.0 版开始，支持 AWS ParallelCluster Slurm 使用 [`SlurmSettings`](Scheduling-v3.md#Scheduling-v3-SlurmSettings)/[`EnableMemoryBasedScheduling`](Scheduling-v3.md#yaml-Scheduling-SlurmSettings-EnableMemoryBasedScheduling)集群配置参数进行基于内存的调度。
**注意**
[从 3.7.0 AWS ParallelCluster 版开始，如果您在实例中配置了多个实例类型，则`EnableMemoryBasedScheduling`可以启用。](Scheduling-v3.md#yaml-Scheduling-SlurmQueues-ComputeResources-Instances)
适用于 3.2.0 到 3.6 AWS ParallelCluster 版本。 *x*[，如果您在实例中配置了多个实例类型，则`EnableMemoryBasedScheduling`无法启用。](Scheduling-v3.md#yaml-Scheduling-SlurmQueues-ComputeResources-Instances)
**警告**
当您在中指定多个实例类型时 Slurm 队列计算资源`EnableMemoryBasedScheduling`启用后，该`RealMemory`值为所有实例类型可用的最小内存量。如果您指定的实例类型具有截然不同的内存容量，则可能会导致大量未使用的内存。
随`EnableMemoryBasedScheduling: true`着，Slurm 调度器跟踪每个任务在每个节点上所需的内存量。然后，Slurm 调度器使用此信息在同一个计算节点上调度多个作业。作业在节点上所需的内存总量不能大于可用的节点内存。调度器可防止作业使用的内存超过提交作业时请求的内存。
使用 `EnableMemoryBasedScheduling: false`，作业可能会争夺共享节点上的内存并导致作业失败和 `out-of-memory` 事件。
**警告**
Slurm 对其标签使用 2 的乘方表示法，例如 MB 或 GB。将这些标签分别读作 MiB 和 GiB。
## Slurm 基于配置和内存的调度
随着`EnableMemoryBasedScheduling: true`，Slurm 设置以下内容 Slurm 配置参数：
+ `slurm.conf` 中的 [https://slurm.schedmd.com/slurm.conf.html#OPT_CR_CPU_Memory](https://slurm.schedmd.com/slurm.conf.html#OPT_CR_CPU_Memory)。此选项将节点内存配置为中的可消耗资源 Slurm.
+ [https://slurm.schedmd.com/cgroup.conf.html#OPT_ConstrainRAMSpace](https://slurm.schedmd.com/cgroup.conf.html#OPT_ConstrainRAMSpace)在 Slurm `cgroup.conf`。 使用此选项，作业对内存的访问权限仅限于提交作业时请求的内存量。
**注意**
其他几个 Slurm 配置参数可能会影响的行为 Slurm 调度程序和资源管理器（如果设置了这两个选项）。有关更多信息，请参阅 [。Slurm 文档](https://slurm.schedmd.com/documentation.html)。
## Slurm 调度程序和基于内存的调度
**`EnableMemoryBasedScheduling: false`（默认值）**
默认情况下，`EnableMemoryBasedScheduling` 设置为 false。如果为假，Slurm 在其调度算法中不包括内存作为资源，也不跟踪作业使用的内存。用户可以指定 `--mem MEM_PER_NODE` 选项来设置作业所需的每个节点的最小内存量。这会强制调度器在调度作业时选择 `RealMemory` 值至少为 `MEM_PER_NODE` 的节点。
例如，假设用户提交了两个使用 `--mem=5GB` 的作业。如果请求的资源（如 CPUs 或）可用，则 GPUs 这些作业可以在内存为 8 GiB 的节点上同时运行。不会调度这两个作业在 `RealMemory` 小于 5 GiB 的计算节点上运行。
**警告**
禁用基于内存的调度时，Slurm 不跟踪作业使用的内存量。在同一节点上运行的作业可能会争夺内存资源并导致其他作业失败。
在禁用基于内存的调度时，我们建议用户不要指定 [https://slurm.schedmd.com/srun.html#OPT_mem-per-cpu](https://slurm.schedmd.com/srun.html#OPT_mem-per-cpu) 或 [https://slurm.schedmd.com/srun.html#OPT_mem-per-gpu](https://slurm.schedmd.com/srun.html#OPT_mem-per-gpu) 选项。这些选项可能导致的行为与中描述的有所不同 [Slurm 文档](https://slurm.schedmd.com/documentation.html)。
**`EnableMemoryBasedScheduling: true`**
当设置`EnableMemoryBasedScheduling`为 true 时，Slurm 使用`--mem`提交选项跟踪每个作业的内存使用情况，并防止作业使用的内存超过请求的内存量。
在上面的示例中，用户提交了两个使用 `--mem=5GB` 的作业。这些作业无法在内存为 8 GiB 的节点上同时运行。这是因为所需的总内存量大于节点上可用的内存量。
启用基于内存的调度后，其`--mem-per-gpu`行为`--mem-per-cpu`与中描述的内容保持一致 Slurm 文档中）。例如，使用 `--ntasks-per-node=2 -c 1 --mem-per-cpu=2GB` 提交作业。在这种情况下，Slurm 为每个节点分配总计 4 GiB 的任务。
**警告**
启用基于内存的调度后，我们建议用户在提交作业时包含 `--mem` 规范。使用默认值 Slurm 包含的配置 AWS ParallelCluster，如果不包含内存选项（`--mem``--mem-per-cpu`、或`--mem-per-gpu`），Slurm 将分配的节点的全部内存分配给该作业，即使它只请求一部分其他资源，例如 CPUs 或 GPUs。这可在作业完成之前有效地防止节点共享，因为没有内存可用于其他作业。发生这种情况是因为 Slurm 将作业的每个节点的内存设置为在提交作业[https://slurm.schedmd.com/slurm.conf.html#OPT_DefMemPerNode](https://slurm.schedmd.com/slurm.conf.html#OPT_DefMemPerNode)时未提供任何内存规格时。此参数的默认值为 0，指定的是对节点内存进行无限制访问。
如果同一个队列中存在多种具有不同内存量的计算资源，则在不同的节点上可能会为不带内存选项的已提交作业分配不同的内存量。这取决于调度器为作业提供了哪些节点。用户可以在集群或分区级别为选项（例如`DefMemPerNode`或 [https://slurm.schedmd.com/slurm.conf.html#OPT_DefMemPerCPU](https://slurm.schedmd.com/slurm.conf.html#OPT_DefMemPerCPU)）定义自定义值 Slurm 配置文件以防止这种行为。
## Slurm RealMemory 和 AWS ParallelCluster SchedulableMemory
使用 Slurm 随附的配置 AWS ParallelCluster，Slurm 解释[RealMemory](https://slurm.schedmd.com/slurm.conf.html#OPT_RealMemory)为每个节点可用于作业的内存量。从版本 3.2.0 开始，默认 AWS ParallelCluster 设置`RealMemory`为[亚马逊 EC2 实例类型中列出并由亚马逊](https://aws.amazon.com/ec2/instance-types) EC2 API [DescribeInstanceTypes](https://docs.aws.amazon.com/AWSEC2/latest/APIReference/API_DescribeInstanceTypes.html)返回的内存的 95%。
禁用基于内存的调度时，Slurm 当用户提交`--mem`指定任务时`RealMemory`，调度器用于筛选节点。
启用基于内存的调度后，Slurm 调度器解释`RealMemory`为计算节点上运行的作业可用的最大内存量。
默认设置可能不是所有实例类型的最佳设置：
+ 此设置可能高于节点实际可以访问的内存量。当计算节点是小型实例类型时，可能会发生这种情况。
+ 此设置可能低于节点实际可以访问的内存量。当计算节点是大型实例类型时，可能会发生这种情况，并可能导致大量未使用的内存。
您可以使用 [`SlurmQueues`](Scheduling-v3.md#Scheduling-v3-SlurmQueues)/[`ComputeResources`](Scheduling-v3.md#Scheduling-v3-SlurmQueues-ComputeResources)/[`SchedulableMemory`](Scheduling-v3.md#yaml-Scheduling-SlurmQueues-ComputeResources-SchedulableMemory)微调计算节点 AWS ParallelCluster 的`RealMemory`配置值。要覆盖默认值，请针对您的集群配置专门为 `SchedulableMemory` 定义一个自定义值。
要检查计算节点的实际可用内存，请在该节点上运行 `/opt/slurm/sbin/slurmd -C` 命令。此命令可返回节点的硬件配置，包括 [https://slurm.schedmd.com/slurm.conf.html#OPT_RealMemory](https://slurm.schedmd.com/slurm.conf.html#OPT_RealMemory) 值。有关更多信息，请参阅 [https://slurm.schedmd.com/slurmd.html#OPT_-C](https://slurm.schedmd.com/slurmd.html#OPT_-C)。
确保计算节点的操作系统进程有足够的内存。为此，请将 `SchedulableMemory` 值设置为低于 `slurmd -C` 命令返回的 `RealMemory` 值，从而限制作业可用的内存。
# Slurm 的多实例类型分配
从 3.3.0 AWS ParallelCluster 版开始，您可以将集群配置为从计算资源的一组已定义的实例类型中进行分配。可以基于 Amazon EC2 机队的低成本或最佳容量策略进行分配。
这组已定义的实例类型必须全部具有相同数量的 v，CPUs 或者如果禁用了多线程，则必须具有相同数量的内核。此外，这组实例类型必须具有相同制造商的相同数量的加速器。如果 [`Efa`](Scheduling-v3.md#yaml-Scheduling-SlurmQueues-ComputeResources-Efa)/[`Enabled`](Scheduling-v3.md#yaml-Scheduling-SlurmQueues-ComputeResources-Efa-Enabled) 设置为 `true`，则实例必须支持 EFA。有关更多信息和要求，请参阅 [`Scheduling`](Scheduling-v3.md)/[`SlurmQueues`](Scheduling-v3.md#Scheduling-v3-SlurmQueues)/[`AllocationStrategy`](Scheduling-v3.md#yaml-Scheduling-SlurmQueues-AllocationStrategy) 和 [`ComputeResources`](Scheduling-v3.md#Scheduling-v3-SlurmQueues-ComputeResources)/[`Instances`](Scheduling-v3.md#yaml-Scheduling-SlurmQueues-ComputeResources-Instances)。
`capacity-optimized`根据您的[CapacityType](Scheduling-v3.md#yaml-Scheduling-SlurmQueues-CapacityType)配置 [`AllocationStrategy`](Scheduling-v3.md#yaml-Scheduling-SlurmQueues-AllocationStrategy)，可以设置为`lowest-price`或。
在 [`Instances`](Scheduling-v3.md#yaml-Scheduling-SlurmQueues-ComputeResources-Instances) 中，您可以配置一组实例类型。
**注意**
[从 3.7.0 AWS ParallelCluster 版开始，如果您在实例中配置了多个实例类型，则`EnableMemoryBasedScheduling`可以启用。](Scheduling-v3.md#yaml-Scheduling-SlurmQueues-ComputeResources-Instances)
适用于 3.2.0 到 3.6 AWS ParallelCluster 版本。 *x*[，如果您在实例中配置了多个实例类型，则`EnableMemoryBasedScheduling`无法启用。](Scheduling-v3.md#yaml-Scheduling-SlurmQueues-ComputeResources-Instances)
以下示例显示了如何查询 v CPUs、EFA 支持和架构的实例类型。
Query InstanceTypes 采用 96 v CPUs 和 x86\$164 架构。
```
$ aws ec2 describe-instance-types --region region-id \
--filters "Name=vcpu-info.default-vcpus,Values=96" "Name=processor-info.supported-architecture,Values=x86_64" \
--query "sort_by(InstanceTypes[*].{InstanceType:InstanceType,MemoryMiB:MemoryInfo.SizeInMiB,CurrentGeneration:CurrentGeneration,VCpus:VCpuInfo.DefaultVCpus,Cores:VCpuInfo.DefaultCores,Architecture:ProcessorInfo.SupportedArchitectures[0],MaxNetworkCards:NetworkInfo.MaximumNetworkCards,EfaSupported:NetworkInfo.EfaSupported,GpuCount:GpuInfo.Gpus[0].Count,GpuManufacturer:GpuInfo.Gpus[0].Manufacturer}, &InstanceType)" \
--output table
```
Query InstanceTypes 拥有 64 个内核、支持 EFA 和 arm64 架构。
```
$ aws ec2 describe-instance-types --region region-id \
--filters "Name=vcpu-info.default-cores,Values=64" "Name=processor-info.supported-architecture,Values=arm64" "Name=network-info.efa-supported,Values=true" --query "sort_by(InstanceTypes[*].{InstanceType:InstanceType,MemoryMiB:MemoryInfo.SizeInMiB,CurrentGeneration:CurrentGeneration,VCpus:VCpuInfo.DefaultVCpus,Cores:VCpuInfo.DefaultCores,Architecture:ProcessorInfo.SupportedArchitectures[0],MaxNetworkCards:NetworkInfo.MaximumNetworkCards,EfaSupported:NetworkInfo.EfaSupported,GpuCount:GpuInfo.Gpus[0].Count,GpuManufacturer:GpuInfo.Gpus[0].Manufacturer}, &InstanceType)" \
--output table
```
下一个集群配置示例片段显示了如何使用这些配置 InstanceType 以及 AllocationStrategy 属性。
```
...
Scheduling:
Scheduler: slurm
SlurmQueues:
- Name: queue-1
CapacityType: ONDEMAND
AllocationStrategy: lowest-price
...
ComputeResources:
- Name: computeresource1
Instances:
- InstanceType: r6g.2xlarge
- InstanceType: m6g.2xlarge
- InstanceType: c6g.2xlarge
MinCount: 0
MaxCount: 500
- Name: computeresource2
Instances:
- InstanceType: m6g.12xlarge
- InstanceType: x2gd.12xlarge
MinCount: 0
MaxCount: 500
...
```
# 动态节点的集群扩展
ParallelCluster 支持使用SlurmSlurm的 power saver 插件动态扩展集群的方法。有关更多信息，请参阅 Slurm 文档中的 [Cloud Scheduling Guide](https://slurm.schedmd.com/elastic_computing.html) 和 [Slurm Power Saving Guide](https://slurm.schedmd.com/power_save.html)。以下主题说明每个版本的 Slurm 策略。
**Topics**
+ [版本 3.8.0 中的 Slurm 动态节点分配策略](scheduler-node-allocation-v3-3.8.0.md)
+ [版本 3.7.x 中的 Slurm 动态节点分配策略](scheduler-dynamic-node-allocation-v3-3.7.x.md)
+ [版本 3.6.x 及以前版本中的 Slurm 动态节点分配策略](scheduler-dynamic-node-allocation-v3-3.6.x.md)
# 版本 3.8.0 中的 Slurm 动态节点分配策略
从 ParallelCluster 版本 3.8.0 开始， ParallelCluster 使用**作业级恢复**或**作业级扩展**作为默认的动态节点分配策略来扩展集群： ParallelCluster 根据每个作业的要求、分配给任务的节点数量以及需要恢复的节点数量来扩展集群。 ParallelCluster 从 SLURM\$1RESUME\$1FILE 环境变量中获取此信息。
动态节点的扩展分为两个步骤，包括启动 EC2 实例和将启动的 Amazon EC2 实例分配到 Slurm 节点。这两个步骤中的每一个都可以使用**all-or-nothing**或**尽力**而为的逻辑来完成。
启动 Amazon EC2 实例：
+ **all-or-nothing**调用启动的 Amazon EC2 API，其最小目标等于总目标容量
+ **最大努力**调用启动 Amazon EC2 API，最小目标值等于 1，总目标容量等于请求的容量
将 Amazon EC2 实例分配到 Slurm 节点：
+ **all-or-nothing**只有在可以为每个请求的Slurm节点分配一个 Amazon EC2 实例的情况下，才会将 Amazon EC2 实例分配给节点
+ 即使 Amazon EC2 实例容量无法覆盖所有请求节点，**最大努力**也会将 Amazon EC2 实例分配给 Slurm 节点
上述策略的可能组合转化为 ParallelCluster发射策略。
**Example** [ ScalingStrategy](Scheduling-v3.md#yaml-Scheduling-ScalingStrategy)
**all-or-nothing**缩放：
此策略包括 AWS ParallelCluster 为每个任务启动 Amazon EC2 启动实例 API 调用，这要求成功启动所请求的计算节点所需的所有实例。这可确保集群只在每个作业所需的容量可用时才进行扩展，避免在扩展过程结束时留下闲置实例。
该策略使用一种**all-or-nothing**逻辑来启动每项任务的 Amazon EC2 实例，以及将 Amazon EC2 实例分配给Slurm节点的**all-or-nothing**逻辑。
该策略将启动请求分为若干批次，每个请求的计算资源一个批次，每个批次最多 500 个节点。对于跨越多个计算资源或超过 500 个节点的请求， ParallelCluster 按顺序处理多个批次。
任何单一资源的批处理失败都会导致所有相关未使用容量的终止，从而确保在扩展过程结束时不会留下任何闲置实例。
限制
+ 扩展所需的时间与每次执行 Slurm 恢复程序时提交的作业数量成正比。
+ 扩展操作受 RunInstances 资源账户限制的限制，默认情况下设置为 1000 个实例。此限制符合 AWS EC2 API 限制政策，有关更多详细信息，请参阅 [Amazon EC2 API](https://docs.aws.amazon.com/AWSEC2/latest/APIReference/throttling.html) 限制文档
+ 当您在具有单一实例类型的计算资源中提交任务时，在跨越多个可用区的队列中，只有在单个可用区中可以提供所有容量时，**all-or-nothing**EC2 启动 API 调用才会成功。
+ 当您在具有多种实例类型的计算资源中提交任务时，在具有单个可用区的队列中，只有当所有容量均可由单个实例类型提供时，**all-or-nothing**Amazon EC2 启动 API 调用才会成功。
+ 当您在具有多种实例类型的计算资源中提交任务时，在跨越多个可用区的队列中，不支持 **all-or-nothing**Amazon EC2 启动 API 调用，而是 ParallelCluster 执行**尽力**扩展。
**greedy-all-or-nothing**缩放：
该 all-or-nothing策略的这种变体仍然可以确保集群仅在每个任务所需的容量可用时才进行扩展，从而避免在扩展过程结束时出现空闲实例，但它涉及 ParallelCluster 启动一个目标最小容量为 1 的 Amazon EC2 启动实例 API 调用，尝试将启动的节点数量最大化到请求的容量。该策略使用尽力为所有任务启动 EC2 实例的逻**all-or-nothing**辑，以及将 Amazon EC2 实例分配给每个任务的Slurm节点的逻辑。
该策略将启动请求分为若干批次，每个请求的计算资源一个批次，每个批次最多 500 个节点。对于跨越多个计算资源或超过 500 个节点的请求， ParellelCluster 按顺序处理多个批次。
该策略以在扩展过程中暂时过度扩展为代价，最大限度地提高吞吐量，从而确保在扩展过程结束时不会留下闲置实例。
限制
+ 可能会出现临时的过度扩展，导致在扩展完成前过渡到运行状态的实例产生额外费用。
+ 与 all-or-nothing策略中相同的实例限制适用，具体取决于 AWS的 RunInstances 资源账户限制。
**最大努力**扩展：
该策略调用 Amazon EC2 启动实例 API 调用，将最小容量设为 1，并以达到总请求容量为目标，但如果不是所有要求的容量都可用，则在扩展过程执行后会留下闲置实例。该策略采用“最大努力”逻辑为所有作业启动 Amazon EC2 实例，并为每个作业采用**最大努力**逻辑来将 Amazon EC2 实例分配给 Slurm 节点。
该策略将启动请求分为若干批次，每个请求的计算资源一个批次，每个批次最多 500 个节点。对于跨越多个计算资源或超过 500 个节点的请求， ParallelCluster 按顺序处理多个批次。
这种策略允许在多次扩展过程执行中，扩展的实例数量远远超过默认的 1000 个实例限制，但代价是在不同扩展进程中出现闲置实例。
限制
+ 在扩展过程结束时可能出现的闲置运行实例，用于无法分配作业要求的所有节点的情况。
以下示例显示了使用不同的**ParallelCluster 启动策略**扩展动态节点的行为。假设您提交了两个作业，每个作业需要 20 个节点，总共需要 40 个相同类型的节点，但只有 30 个 Amazon EC2 实例可用，无法满足 EC2 上的请求容量。
**all-or-nothing**缩放：
+ 对于第一项任务，调用了 A ** all-or-nothing**mazon EC2 启动实例 API，请求了 20 个实例。一次成功的调用启动了 20 个实例
+ **all-or-nothing **成功将 20 个已启动的实例分配给第一个任务的Slurm节点
+ 调用了另一个 **all-or-nothing**Amazon EC2 启动实例 API，为第二个任务请求 20 个实例。调用不成功，因为只有另外 10 个实例的容量。目前未启动任何实例
**greedy-all-or-nothing**缩放：
+ 采用**最大努力**调用 Amazon EC2 启动实例 API，请求 40 个实例，这是所有作业请求的总容量。这会导致启动 30 个实例
+ 成功将 20 个已启动的实例**all-or-nothing**分配给第一个任务的Slurm节点
+ 尝试将剩余已启动的实例再次**all-or-nothing**分配给第二个任务的Slurm节点，但是由于任务请求的总共 20 个实例中只有 10 个可用实例，因此分配不成功
+ 10 个未分配的已启动实例被终止
**最大努力**扩展：
+ 采用**最大努力**调用 Amazon EC2 启动实例 API，请求 40 个实例，这是所有作业请求的总容量。这会导致启动 30 个实例。
+ 在第一个作业中，采用**最大努力**将 20 个已启动的实例分配给 Slurm 节点是成功的。
+ 在第二个作业中，再次采用**最大努力**将剩余 10 个已启动的实例分配给 Slurm 节点是成功的，即使请求的总容量为 20 也是如此。但是，由于该作业请求 20 个节点，而 Amazon EC2 实例只能分配给其中的 10 个节点，因此该作业无法启动，实例处于闲置状态，直到在以后的扩展过程调用中找到足够的容量来启动缺少的 10 个实例，或者调度器将该作业调度到其它已经运行的计算节点上。
# 版本 3.7.x 中的 Slurm 动态节点分配策略
ParallelCluster 使用 2 种类型的动态节点分配策略来扩展集群：
+
**根据可用的请求节点信息进行分配：**
+ **所有节点恢复**或**节点列表**扩展：
ParallelCluster `ResumeProgram`运行时仅根据请求Slurm的节点列表名称Slurm来扩展集群。它仅按节点名称向节点分配计算资源。节点名称列表可以跨越多个作业。
+ **作业级别恢复**或**作业级别**扩展：
ParallelCluster 根据每个作业的要求、当前分配给该任务的节点数以及需要恢复的节点来扩展集群。 ParallelCluster 从`SLURM_RESUME_FILE`环境变量中获取此信息。
+
**使用 Amazon EC2 启动策略进行分配：**
+ **最大努力**扩展：
ParallelCluster 使用最小目标容量等于 1 的 Amazon EC2 启动实例 API 调用来扩展集群，启动支持请求的节点所需的部分但不一定是全部实例。
+ ll-or-nothing缩@@ **放**比例：
ParallelCluster 使用 Amazon EC2 启动实例 API 调用扩展集群，只有在支持请求的节点所需的所有实例都启动后，该调用才会成功。在这种情况下，它调用 Amazon EC2 启动实例 API 时的最小目标容量等于请求的总容量。
默认情况下， ParallelCluster 使用**节点列表**扩展和尽力而为 Amazon **EC** 2 启动策略来启动支持请求的节点所需的部分实例，但不一定是全部实例。它会尝试预置尽可能多的容量来处理所提交的工作负载。
**从 3.7.0 ParallelCluster 版开始， ParallelCluster 使用**作业级**扩展和 **all-or-nothing**EC2 启动策略来处理以独占模式提交的任务。**当您在独占模式下提交作业时，该作业对其分配的节点拥有独占访问权限。有关更多信息，请参阅 Slurm 文档中的 [EXCLUSIVE](https://slurm.schedmd.com/slurm.conf.html#OPT_EXCLUSIVE)。
要以独占模式提交作业，请执行以下操作：
+ 向集群提交 Slurm 作业时传递独占标志。例如 `sbatch ... --exclusive`。
或
+ 向 [`JobExclusiveAllocation`](Scheduling-v3.md#yaml-Scheduling-SlurmQueues-JobExclusiveAllocation) 设置为 `true` 的已配置集群队列提交作业。
以独占模式提交作业时：
+ ParallelCluster 目前批量启动请求最多包含 500 个节点。如果任务请求的节点超过 500 个， ParallelCluster 则为每组 500 个节点发出启动请求，为其余节点发出额外的启动请求。**all-or-nothing**
+ 如果节点分配在单个计算资源中， ParallelCluster 则为每组 500 个节点发出启动请求，为其余节点发出额外的启动请求。**all-or-nothing**如果启动请求失败， ParallelCluster 将终止所有启动请求创建的未使用容量。
+ 如果节点分配跨越多个计算资源，则 ParallelCluster 需要为每个计算资源发出**all-or-nothing**启动请求。这些请求也会进行批处理。如果其中一个计算资源的启动请求失败，则 ParallelCluster 会终止所有计算资源启动请求所创建的未使用容量。
使用**all-or-nothing**启动策略进行@@ **作业级**扩展已知局限性：
+ 当您在具有单一实例类型的计算资源中提交任务时，在跨越多个可用区的队列中，只有在单个可用区中可以提供所有容量时，**all-or-nothing**EC2 启动 API 调用才会成功。
+ 当您在具有多种实例类型的计算资源中提交任务时，在具有单个可用区的队列中，只有当所有容量均可由单个实例类型提供时，**all-or-nothing**Amazon EC2 启动 API 调用才会成功。
+ 当您在具有多种实例类型的计算资源中提交任务时，在跨越多个可用区的队列中，不支持 **all-or-nothing**Amazon EC2 启动 API 调用，而是 ParallelCluster执行**尽力**扩展。
# 版本 3.6.x 及以前版本中的 Slurm 动态节点分配策略
AWS ParallelCluster 仅使用一种类型的动态节点分配策略来扩展集群：
+ 根据可用的请求节点信息进行分配：
+ **所有节点恢复**或**节点列表**扩 ParallelCluster 展：仅根据运行时Slurm请求Slurm的节点列表名称来扩展集群。`ResumeProgram`它仅按节点名称向节点分配计算资源。节点名称列表可以跨越多个作业。
+ 使用 Amazon EC2 启动策略进行分配：
+ **尽力扩 ParallelCluster 展：使用最**小目标容量等于 1 的 Amazon EC2 启动实例 API 调用来扩展集群，启动支持请求的节点所需的部分但不一定是全部实例。
ParallelCluster 使用**节点列表**扩展和尽力而为 Amazon **EC** 2 启动策略来启动支持请求的节点所需的部分实例，但不一定是全部实例。它会尝试预置尽可能多的容量来处理所提交的工作负载。
限制
+ 在扩展过程结束时可能出现的闲置运行实例，用于无法分配作业要求的所有节点的情况。
# Slurm会计 AWS ParallelCluster
从 3.3.0 版开始， AWS ParallelCluster 支持使用集群配置参数 [SlurmSettings](Scheduling-v3.md#Scheduling-v3-SlurmSettings)/[数据库](Scheduling-v3.md#Scheduling-v3-SlurmSettings-Database)进行Slurm记账。
从 3.10.0 版开始， AWS ParallelCluster 支持使用带有集群配置参数/的外部 Slurmdbd 进行Slurm记账。[SlurmSettings[ExternalSlurmdbd](Scheduling-v3.md#Scheduling-v3-SlurmSettings-ExternalSlurmdbd)](Scheduling-v3.md#Scheduling-v3-SlurmSettings)如果多个集群共享同一个数据库，建议使用外部 Slurmdbd。
通过 Slurm 会计，您可以集成外部会计数据库来执行以下操作：
+ 管理集群用户或用户组和其他实体。借助此功能，您可以使用更高级Slurm的功能，例如资源限制强制执行、公平共享和。 QOSs
+ 收集并保存作业数据，例如运行作业的用户、作业的持续时间及其使用的资源。您可以使用 `sacct` 实用工具查看保存的数据。
**注意**
AWS ParallelCluster 支持对[Slurm支持的 MySQL 数据库服务器](https://slurm.schedmd.com/accounting.html#mysql-configuration)进行Slurm记账。
## Slurmdbd在 AWS ParallelCluster v3.10.0 及更高版本中使用外部使用Slurm记账
在配置 Slurm 会计之前，必须有一个现有的外部 Slurmdbd 数据库服务器，该服务器可连接到现有的外部数据库服务器。
要对此进行配置，请定义以下内容：
+ [ExternalSlurmdbd](Scheduling-v3.md#Scheduling-v3-SlurmSettings-ExternalSlurmdbd)/[Host](Scheduling-v3.md#yaml-Scheduling-SlurmSettings-ExternalSlurmdbd-Host) 中外部Slurmdbd服务器的地址。服务器必须存在并且可以从头节点访问。
+ 用于与外部Slurmdbd服务器通信的 munge 密钥。[MungeKeySecretArn](Scheduling-v3.md#yaml-Scheduling-SlurmSettings-MungeKeySecretArn)
要查看分步教程，请参阅[使用外部集群创建集群 Slurmdbd 会计](external-slurmdb-accounting.md)。
**注意**
您负责管理 Slurm 数据库会计实体。
AWS ParallelCluster 外部SlurmDB支持功能的架构使多个集群可以共享相同SlurmDB和相同的数据库。
![\[\]](http://docs.aws.amazon.com/zh_cn/parallelcluster/latest/ug/images/External_Slurmdbd_Architecture_ASG.png)
**警告**
与外部 AWS ParallelCluster 之间的流量SlurmDB未加密。建议在可信网络中运行集群和外部 SlurmDB。
## Slurmdbd在 AWS ParallelCluster v3.3.0 及更高版本中使用头节点处理Slurm记账
在配置 Slurm 会计之前，必须具有现有的外部数据库服务器和使用 `mysql` 协议的数据库。
要使用配置Slurm记账 AWS ParallelCluster，必须定义以下内容：
+ 在 [Database](Scheduling-v3.md#Scheduling-v3-SlurmSettings-Database)/[Uri](Scheduling-v3.md#yaml-Scheduling-SlurmSettings-Database-Uri) 中定义的外部数据库服务器的 URI。服务器必须存在并且可以从头节点访问。
+ [访问数据库/ [PasswordSecretArn](Scheduling-v3.md#yaml-Scheduling-SlurmSettings-Database-PasswordSecretArn)和数据库/中定义的外部[数据库](Scheduling-v3.md#Scheduling-v3-SlurmSettings-Database)的凭据[UserName](Scheduling-v3.md#yaml-Scheduling-SlurmSettings-Database-UserName)。](Scheduling-v3.md#Scheduling-v3-SlurmSettings-Database) AWS ParallelCluster 使用此信息在Slurm级别上配置记账并在头节点上配置`slurmdbd`服务。 `slurmdbd`是管理群集和数据库服务器之间通信的守护程序。
要查看分步教程，请参阅[使用创建集群 Slurm 会计](tutorials_07_slurm-accounting-v3.md)。
**注意**
AWS ParallelCluster 通过将默认集群用户设置为数据库管理员来执行Slurm会计数据库的基本引导。Slurm AWS ParallelCluster 不会向会计数据库添加任何其他用户。客户负责管理 Slurm 数据库中的会计实体。
AWS ParallelCluster 配置[https://slurm.schedmd.com/slurmdbd.html](https://slurm.schedmd.com/slurmdbd.html)为确保群集在Slurm数据库服务器上拥有自己的数据库。同一台数据库服务器可以跨多个群集使用，但每个群集都有自己的独立数据库。 AWS ParallelCluster 使用集群名称在`slurmdbd`配置文件[https://slurm.schedmd.com/slurmdbd.conf.html#OPT_StorageLoc](https://slurm.schedmd.com/slurmdbd.conf.html#OPT_StorageLoc)参数中定义数据库的名称。请考虑以下情况：数据库服务器上存在的数据库包括的集群名称未映射到有效的集群名称。在这种情况下，您可以使用该集群名称创建一个新集群以映射到该数据库。Slurm 会对新集群重复使用该数据库。
**警告**
我们不建议设置多个集群同时使用同一个数据库。这样做可能会导致性能问题，甚至导致数据库死锁情况。
如果在集群的头节点上启用了 Slurm 会计，我们建议使用具有强大 CPU、更大内存和更高网络带宽的实例类型。Slurm 会计可能会增加集群头节点的负荷。
在当前的 AWS ParallelCluster Slurm记账功能架构中，每个集群都有自己的`slurmdbd`守护程序实例，如下图示例配置所示。
![\[\]](http://docs.aws.amazon.com/zh_cn/parallelcluster/latest/ug/images/slurm-acct-arch.png)
如果您要向集群环境中添加自定义 Slurm 多集群或联合身份验证功能，则所有集群都必须引用同一个 `slurmdbd` 实例。对于这种替代方案，我们建议您在一个集群上启用 AWS ParallelCluster Slurm记账，然后手动配置其他集群以连接到第一个集群上托管的集群。`slurmdbd`
如果您使用的是 3.3.0 之前的 AWS ParallelCluster 版本，请参阅此 [HPC 博客文章](https://aws.amazon.com/blogs/compute/enabling-job-accounting-for-hpc-with-aws-parallelcluster-and-amazon-rds/)中描述的实现Slurm记账的替代方法。
## Slurm 会计注意事项
### 数据库和集群在不同的地方 VPCs
要启用 Slurm 会计，需要将数据库服务器作为 `slurmdbd` 进程守护程序执行读取和写入操作的后端。在创建或更新集群以启用 Slurm 会计之前，头节点必须能够访问该数据库服务器。
如果您需要在集群使用的 VPC 之外的不同 VPC 上部署数据库服务器，请考虑以下事项：
+ 要启用群集端和数据库服务器之间的通信，必须设置两者之间的连接 VPCs。`slurmdbd`有关更多信息，请参阅 *Amazon Virtual Private Cloud 用户指南* 中的 [VPC 对等连接](https://docs.aws.amazon.com/vpc/latest/peering/what-is-vpc-peering.html)。
+ 您必须在集群的 VPC 上创建要连接到头节点的安全组。两者建立 VPCs 对等关系后，即可在数据库端和集群端安全组之间进行交叉链接。有关更多信息，请参阅 *Amazon Virtual Private Cloud 用户指南* 中的[安全组规则](https://docs.aws.amazon.com/vpc/latest/userguide/VPC_SecurityGroups.html#SecurityGroupRules)。
### 配置 `slurmdbd` 和数据库服务器之间的 TLS 加密
如果服务器支持 TLS 加密，则使用 AWS ParallelCluster 提供的默认Slurm记账配置与数据库服务器`slurmdbd`建立 TLS 加密连接。 AWS 默认情况下，诸如 Amazon RDS 之类的数据库服务 Amazon Aurora 支持 TLS 加密。
通过在数据库服务器上设置 `require_secure_transport` 参数，可以在服务器端要求安全连接。这是在提供的 CloudFormation 模板中配置的。
根据安全性方面的最佳实践，我们建议您同时在 `slurmdbd` 客户端上启用服务器身份验证。为此，请在[StorageParameters](https://slurm.schedmd.com/slurmdbd.conf.html#OPT_StorageParameters)中配置`slurmdbd.conf`。将服务器 CA 证书上传到集群的头节点。接下来，将 `slurmdbd.conf` 中 `StorageParameters` 的 [SSL\$1CA](https://slurm.schedmd.com/slurmdbd.conf.html#OPT_SSL_CA) 选项设置为头节点上服务器 CA 证书的路径。这样做会在 `slurmdbd` 侧启用服务器身份验证。进行这些更改后，重启 `slurmdbd` 服务以便在启用身份验证的情况下重新建立与数据库服务器的连接。
### 更新数据库凭证
要更新[数据库](Scheduling-v3.md#Scheduling-v3-SlurmSettings-Database)/[UserName](Scheduling-v3.md#yaml-Scheduling-SlurmSettings-Database-UserName)或的值 [PasswordSecretArn](Scheduling-v3.md#yaml-Scheduling-SlurmSettings-Database-PasswordSecretArn)，必须先停止计算队列。假设存储在密钥中的 AWS Secrets Manager 密钥值已更改，且其 ARN 未更改。在这种情况下，集群不会自动将数据库密码更新为新值。要针对新密钥值更新集群，请从头节点运行以下命令。
```
$ sudo /opt/parallelcluster/scripts/slurm/update_slurm_database_password.sh
```
**警告**
为避免会计数据丢失，我们建议仅在已停止计算实例集的情况下更改数据库密码。
### 数据库监控
我们建议您启用 AWS 数据库服务的监控功能。有关更多信息，请参阅 [Amazon RDS 监控](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/CHAP_Monitoring.html)或 [Amazon Aurora 监控](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/MonitoringAurora.html)文档。
# Slurm 配置自定义
从 3.6.0 AWS ParallelCluster 版开始，您可以自定义 `slurm.conf` Slurm AWS ParallelCluster 集群配置中的配置。
在集群配置中，您可以自定义 Slurm 使用以下集群配置设置配置参数：
+ 自定义 Slurm 使用 [`SlurmSettings`](Scheduling-v3.md#Scheduling-v3-SlurmSettings)/[`CustomSlurmSettings`](Scheduling-v3.md#yaml-Scheduling-SlurmSettings-CustomSlurmSettings)或参数为整个集群[`CustomSlurmSettingsIncludeFile`](Scheduling-v3.md#yaml-Scheduling-SlurmSettings-CustomSlurmSettingsIncludeFile)设置参数。 AWS ParallelCluster 如果同时指定两者，则失败。
+ 自定义 Slurm 使用 [`SlurmQueues`](Scheduling-v3.md#Scheduling-v3-SlurmQueues)/为队列设置参数 [`CustomSlurmSettings`](Scheduling-v3.md#yaml-Scheduling-SlurmQueues-CustomSlurmSettings)（映射到 Slurm 分区）。
+ 自定义 Slurm 使用 [`SlurmQueues`](Scheduling-v3.md#Scheduling-v3-SlurmQueues)/[`ComputeResources`](Scheduling-v3.md#Scheduling-v3-SlurmQueues-ComputeResources)/为计算资源设置参数 [`CustomSlurmSettings`](Scheduling-v3.md#yaml-Scheduling-SlurmQueues-ComputeResources-CustomSlurmSettings)（映射到 Slurm 节点）。
## Slurm 配置自定义限制和使用时的注意事项 AWS ParallelCluster
+ 对于`CustomSlurmSettings`和`CustomSlurmSettingsIncludeFile`设置，您只能指定和更新包含在中的`slurm.conf`参数 [Slurm 您用于配置集群的 AWS ParallelCluster 版本所支持的版本。](slurm-workload-manager-v3.md)
+ 如果您指定自定义 Slurm 在任何`CustomSlurmSettings`参数中进行配置， AWS ParallelCluster 执行验证检查并阻止设置或更新 Slurm 与 AWS ParallelCluster 逻辑冲突的配置参数。这些区域有：Slurm 已知与 AWS ParallelCluster 之冲突的配置参数在拒绝列表中标识。如果有其他情况，拒绝列表可能会在 future AWS ParallelCluster 版本中发生变化 Slurm 功能已添加。有关更多信息，请参阅 [被拒登名单 Slurm 的配置参数 `CustomSlurmSettings`](#slurm-configuration-denylists-v3)。
+ AWS ParallelCluster 仅检查参数是否在拒绝列表中。 AWS ParallelCluster 无法验证您的自定义 Slurm 配置参数语法或语义。您有责任验证您的自定义 Slurm 配置参数。无效的自定义 Slurm 配置参数可能导致 Slurm 守护程序失败可能导致集群创建和更新失败。
+ 如果您指定自定义 Slurm 中的配置`CustomSlurmSettingsIncludeFile`， AWS ParallelCluster 不执行任何验证。
+ 您可以更新 `CustomSlurmSettings` 和 `CustomSlurmSettingsIncludeFile` 而不停止然后启动计算实例集。在这种情况下， AWS ParallelCluster 重新启动`slurmctld`守护程序并运行命令。`scontrol reconfigure`
一段时间 Slurm 在整个集群中注册更改之前，可能需要对配置参数进行不同的操作。例如，它们可能需要重启集群中的所有进程守护程序。您有责任验证 AWS ParallelCluster 操作是否足以传播您的自定义内容 Slurm 更新期间的配置参数设置。如果您发现 AWS ParallelCluster 操作还不够，则您有责任按照中的建议提供传播更新后的设置所需的额外操作 [Slurm 文档](https://slurm.schedmd.com/documentation.html)。
## 被拒登名单 Slurm 的配置参数 `CustomSlurmSettings`
下表列出了拒绝使用参数的 AWS ParallelCluster 版本（从 3.6.0 版本开始）。 `CustomSlurmSettings`3.6.0 之前的 AWS ParallelCluster 版本不支持。
**集群级别列入拒绝列表的参数：**
| Slurm 参数 | 已在版本中列出拒绝 AWS ParallelCluster |
| --- | --- |
| CommunicationParameters | 3.6.0 |
| Epilog | 3.6.0 |
| GresTypes | 3.6.0 |
| LaunchParameters | 3.6.0 |
| Prolog | 3.6.0 |
| ReconfigFlags | 3.6.0 |
| ResumeFailProgram | 3.6.0 |
| ResumeProgram | 3.6.0 |
| ResumeTimeout | 3.6.0 |
| SlurmctldHost | 3.6.0 |
| SlurmctldLogFile | 3.6.0 |
| SlurmctldParameters | 3.6.0 |
| SlurmdLogfile | 3.6.0 |
| SlurmUser | 3.6.0 |
| SuspendExcNodes | 3.6.0 |
| SuspendProgram | 3.6.0 |
| SuspendTime | 3.6.0 |
| TaskPlugin | 3.6.0 |
| TreeWidth | 3.6.0 |
**本机时在集群级别被拒绝列出的参数 [Slurm 记账集成](slurm-accounting-v3.md)是在群集配置中配置的：**
| Slurm 参数 | 已在版本中列出拒绝 AWS ParallelCluster |
| --- | --- |
| AccountingStorageType | 3.6.0 |
| AccountingStorageHost | 3.6.0 |
| AccountingStoragePort | 3.6.0 |
| AccountingStorageUser | 3.6.0 |
| JobAcctGatherType | 3.6.0 |
**队列管理的队列的队列（分区）级别的拒绝列表参数： AWS ParallelCluster**
| Slurm 参数 | 已在版本中列出拒绝 AWS ParallelCluster |
| --- | --- |
| Nodes | 3.6.0 |
| PartitionName | 3.6.0 |
| ResumeTimeout | 3.6.0 |
| State | 3.6.0 |
| SuspendTime | 3.6.0 |
**由以下机构管理的计算资源（节点）级别的拒绝列出的计算资源的参数： AWS ParallelCluster**
| Slurm 参数 | 已在版本和更高 AWS ParallelCluster 版本中列出 “拒绝” |
| --- | --- |
| CPUs | 3.6.0 |
| Features | 3.6.0 |
| Gres | 3.6.0 |
| NodeAddr | 3.6.0 |
| NodeHostname | 3.6.0 |
| NodeName | 3.6.0 |
| 权重 | 3.7.0 |
# Slurm 和 `prolog``epilog`
从 AWS ParallelCluster 版本 3.6.0 开始，使用部署的Slurm配置 AWS ParallelCluster 包括`Prolog`和`Epilog`配置参数：
```
# PROLOG AND EPILOG
Prolog=/opt/slurm/etc/scripts/prolog.d/*
Epilog=/opt/slurm/etc/scripts/epilog.d/*
SchedulerParameters=nohold_on_prolog_fail
BatchStartTimeout=180
```
有关更多信息，请参阅 Slurm 文档中的 [Prolog 和 Epilog 指南](https://slurm.schedmd.com/prolog_epilog.html)。
AWS ParallelCluster 包括以下序言和结尾脚本：
+ `90_plcuster_health_check_manager`（位于 `Prolog` 文件夹）
+ `90_pcluster_noop`（位于 `Epilog` 文件夹）
**注意**
`Prolog` 和 `Epilog` 文件夹都必须至少包含一个文件。
您可以将自定义 `prolog` 或 `epilog` 脚本添加到相应的 `Prolog` 和 `Epilog` 文件夹中，从而使用自己的自定义脚本。
**警告**
Slurm 按字母倒序运行这些文件夹中的每个脚本。
`prolog` 和 `epilog` 脚本的运行持续时间会影响运行作业所需的时间。当运行的 `prolog` 脚本数量较多或运行时间较长时，请更新 `BatchStartTimeout` 配置设置。默认值为 3 分钟。
如果您要使用自定义 `prolog` 和 `epilog` 脚本，请将这些脚本放置在相应的 `Prolog` 和 `Epilog` 文件夹中。我们建议您保留在每个自定义脚本之前运行的 `90_plcuster_health_check_manager` 脚本。有关更多信息，请参阅 [Slurm 配置自定义](slurm-configuration-settings-v3.md)。
# 集群容量大小和更新
集群的容量由集群可以扩展的计算节点数量来定义。计算节点由 AWS ParallelCluster 配置中的计算资源中定义的 Amazon EC2 实例提供支持`(Scheduling/SlurmQueues/ ComputeResources)`，并按照 1:1 映射到`(Scheduling/SlurmQueues)`的队列进行组织 Slurm 分区。
在计算资源中，可以配置集群中必须始终保持运行的计算节点（实例）的最小数量（`MinCount`），以及计算资源可扩展到的实例最大数量（[`MaxCount`3 ](Scheduling-v3.md#yaml-Scheduling-SlurmQueues-ComputeResources-MaxCount)）。
在创建集群时或群集更新时，为集群中定义的每个计算资源 (`Scheduling/SlurmQueues/ ComputeResources`) AWS ParallelCluster 启动中配置`MinCount`的任意数量的 Amazon EC2 实例。为覆盖集群中计算资源的最小节点数量而启动的实例称为***静态节点***。静态节点一旦启动，就会在集群中持续存在，除非发生特定事件或情况，否则系统不会终止它们。例如，此类事件包括失败 Slurm 或者 Amazon EC2 健康检查和变更 Slurm 节点状态变为 “耗尽” 或 “关闭”。
为应对集群`MaxCount `*负载增加而`1`按需启动的 Amazon EC2 实例被称为***动态节点***，范围为`‘MaxCount - MinCount’`（减去*` MinCount)`）。 它们的性质是短暂的，启动它们是为了处理待处理的任务，如果它们`Scheduling/SlurmSettings/ScaledownIdletime`在集群配置中定义的一段时间内保持闲置状态（默认值：10 分钟），它们就会被终止。
静态节点和动态节点符合以下命名方案：
+ 静态节点 `-st--`，其中 ` = 1..ComputeResource/MinCount`
+ 动态节点 `-dy--`，其中 ` = 1..(ComputeResource/MaxCount - ComputeResource/MinCount)`
例如，给定以下 AWS ParallelCluster 配置：
```
Scheduling:
Scheduler: Slurm
SlurmQueues:
- Name: queue1
ComputeResources:
- Name: c5xlarge
Instances:
- InstanceType: c5.xlarge
MinCount: 100
MaxCount: 150
```
将在中定义以下节点 Slurm
```
$ sinfo
PARTITION AVAIL TIMELIMIT NODES STATE NODELIST
queue1* up infinite 50 idle~ queue1-dy-c5xlarge-[1-50]
queue1* up infinite 100 idle queue1-st-c5xlarge-[1-100]
```
当计算资源的 `MinCount == MaxCount` 时，所有相应的计算节点都将是静态的，所有实例都将在集群创建/更新时启动并保持运行。例如：
```
Scheduling:
Scheduler: slurm
SlurmQueues:
- Name: queue1
ComputeResources:
- Name: c5xlarge
Instances:
- InstanceType: c5.xlarge
MinCount: 100
MaxCount: 100
```
```
$ sinfo
PARTITION AVAIL TIMELIMIT NODES STATE NODELIST
queue1* up infinite 100 idle queue1-st-c5xlarge-[1-100]
```
## 集群容量更新
集群容量的更新包括添加或删除队列、计算资源或更改计算资源的 `MinCount/MaxCount`。从 AWS ParallelCluster 版本 3.9.0 开始，缩小队列大小需要在集群更新之前停止计算队列或将其[QueueUpdateStrategy](Scheduling-v3.md#yaml-Scheduling-SlurmSettings-QueueUpdateStrategy)设置为 TERMINATION for。在以下情况下，无需停止计算队列或将其设置[QueueUpdateStrategy](Scheduling-v3.md#yaml-Scheduling-SlurmSettings-QueueUpdateStrategy)为 “终止”：
+ 将新队列添加到 Scheduling/[`SlurmQueues`](Scheduling-v3.md#Scheduling-v3-SlurmQueues)
+ 向队列中添加新的计算资源 `Scheduling/SlurmQueues/ComputeResources`
+ 增加计算资源的 `MaxCount`
+ 计算资源的增加 MaxCount 和相同计算资源的增加量至少相等 MinCount
## 注意事项和限制
本节旨在概述在调整集群容量大小时应考虑的任何重要因素、约束或限制。
+ 从`Scheduling/SlurmQueues`所有具有静态和动态名称`-*`的计算节点中移除队列时，将从 Slurm 配置和相应的 Amazon EC2 实例将被终止。
+ `Scheduling/SlurmQueues/ComputeResources`从队列中移除计算资源时，所有名`-*--*`为静态和动态的计算节点都将从队列中移除 Slurm 配置和相应的 Amazon EC2 实例将被终止。
在更改计算资源的 `MinCount` 参数时，我们可以区分两种不同的情况，一种是 `MaxCount` 与 `MinCount` 相等（仅静态容量），另一种是 `MaxCount` 大于 `MinCount`（静态和动态混合容量）。
### 只有静态节点的容量变化
+ 如果在增加`MinCount`（和`MaxCount`）时`MinCount == MaxCount`，将通过将静态节点的数量扩展到新的值来配置集群，`MinCount``-st--`并且系统将继续尝试启动 Amazon EC2 实例以满足新的所需静态容量。
+ 如果在减少`MinCount`（和`MaxCount`）数量 N 时`MinCount == MaxCount`，将通过移除最后 N 个静态节点来配置集群，`-st--...]`并且系统将终止相应的 Amazon EC2 实例。
+ 初始状态 `MinCount = MaxCount = 100`
+
```
$ sinfo
PARTITION AVAIL TIMELIMIT NODES STATE NODELIST
queue1* up infinite 100 idle queue1-st-c5xlarge-[1-100]
```
+ 更新 `MinCount` 和 `MaxCount: MinCount = MaxCount = 70` 上的 `-30`
+
```
$ sinfo
PARTITION AVAIL TIMELIMIT NODES STATE NODELIST
queue1* up infinite 70 idle queue1-st-c5xlarge-[1-70]
```
### 混合节点的容量变化
如果在增加`MinCount`数量 N（假设保持不变）时`MinCount < MaxCount`，`MaxCount`将通过将静态节点的数量扩展到新的值 `MinCount` (`old_MinCount + N`): 来配置集群，`-st--`并且系统将继续尝试启动 Amazon EC2 实例以满足新的所需静态容量。此外，为了满足计算资源的`MaxCount`容量，通过*删除最后 N 个动态节点*来更新集群配置：`-dy--[...]`系统将终止相应的 Amazon EC2 实例。
+ 初始状态：`MinCount = 100; MaxCount = 150`
+
```
$ sinfo
PARTITION AVAIL TIMELIMIT NODES STATE NODELIST
queue1* up infinite 50 idle~ queue1-dy-c5xlarge-[1-50]
queue1* up infinite 100 idle queue1-st-c5xlarge-[1-100]
```
+ 将 \$130 更新为 `MinCount : MinCount = 130 (MaxCount = 150)`
+
```
$ sinfo
PARTITION AVAIL TIMELIMIT NODES STATE NODELIST
queue1* up infinite 20 idle~ queue1-dy-c5xlarge-[1-20]
queue1* up infinite 130 idle queue1-st-c5xlarge-[1-130]
```
如果在增加`MinCount`且`MaxCount`数量相同 N 时`MinCount < MaxCount`，将通过将静态节点数扩展到新值 `MinCount` (`old_MinCount + N`): 来配置集群，`-st--`并且系统将继续尝试启动 Amazon EC2 实例以满足新的所需静态容量。此外，动态节点的数量不会因新的
`MaxCount` 值。
+ 初始状态：`MinCount = 100; MaxCount = 150`
+
```
$ sinfo
PARTITION AVAIL TIMELIMIT NODES STATE NODELIST
queue1* up infinite 50 idle~ queue1-dy-c5xlarge-[1-50]
queue1* up infinite 100 idle queue1-st-c5xlarge-[1-100]
```
+ 将 \$130 更新为 `MinCount : MinCount = 130 (MaxCount = 180)`
+
```
$ sinfo
PARTITION AVAIL TIMELIMIT NODES STATE NODELIST
queue1* up infinite 20 idle~ queue1-dy-c5xlarge-[1-50]
queue1* up infinite 130 idle queue1-st-c5xlarge-[1-130]
```
如果`MinCount < MaxCount`在减少`MinCount`数量 N（假设保持不变）时，`MaxCount`将通过移除最后 N 个静态节点的静态节点来配置集群，系统将终止相应的 Amazon EC2 实例。`-st--[...`此外，为了满足计算资源的`MaxCount`容量，通过扩展动态节点的数量来更新集群配置以填补空白。`MaxCount - new_MinCount: -dy--[1..]`在这种情况下，由于这些是动态节点，因此除非调度程序在新节点上有待处理的任务，否则不会启动新的 Amazon EC2 实例。
+ 初始状态：`MinCount = 100; MaxCount = 150`
+
```
$ sinfo
PARTITION AVAIL TIMELIMIT NODES STATE NODELIST
queue1* up infinite 50 idle~ queue1-dy-c5xlarge-[1-50]
queue1* up infinite 100 idle queue1-st-c5xlarge-[1-100]
```
+ 更新 `MinCount : MinCount = 70 (MaxCount = 120)` 上的 -30
+
```
$ sinfo
PARTITION AVAIL TIMELIMIT NODES STATE NODELIST
queue1* up infinite 80 idle~ queue1-dy-c5xlarge-[1-80]
queue1* up infinite 70 idle queue1-st-c5xlarge-[1-70]
```
如果在减少`MinCount`且`MaxCount`数量相同的 N 时`MinCount < MaxCount`，将通过移除最后 N 个静态节点`-st--...]`来配置集群，系统将终止相应的 Amazon EC2 实例。
此外，动态节点的数量不会因新的 `MaxCount` 值而发生变化。
+ 初始状态：`MinCount = 100; MaxCount = 150`
+
```
$ sinfo
PARTITION AVAIL TIMELIMIT NODES STATE NODELIST
queue1* up infinite 50 idle~ queue1-dy-c5xlarge-[1-50]
queue1* up infinite 100 idle queue1-st-c5xlarge-[1-100]
```
+ 更新 `MinCount : MinCount = 70 (MaxCount = 120)` 上的 -30
+
```
$ sinfo
PARTITION AVAIL TIMELIMIT NODES STATE NODELIST
queue1* up infinite 80 idle~ queue1-dy-c5xlarge-[1-50]
queue1* up infinite 70 idle queue1-st-c5xlarge-[1-70]
```
如果在减少`MaxCount`数量 N（假设保持不变）时`MinCount < MaxCount`，`MinCount`将通过移除最后 N 个动态节点来配置集群，`-dy--]`并且系统将终止相应的 Amazon EC2 实例（如果它们正在运行）。预计不会对静态节点产生任何影响。
+ 初始状态：`MinCount = 100; MaxCount = 150`
+
```
$ sinfo
PARTITION AVAIL TIMELIMIT NODES STATE NODELIST
queue1* up infinite 50 idle~ queue1-dy-c5xlarge-[1-50]
queue1* up infinite 100 idle queue1-st-c5xlarge-[1-100]
```
+ 更新 `MaxCount : MinCount = 100 (MaxCount = 120)` 上的 -30
+
```
$ sinfo
PARTITION AVAIL TIMELIMIT NODES STATE NODELIST
queue1* up infinite 20 idle~ queue1-dy-c5xlarge-[1-20]
queue1* up infinite 100 idle queue1-st-c5xlarge-[1-100]
```
## 对作业的影响
在移除节点和 Amazon EC2 实例终止的所有情况下，除非没有其他节点满足任务要求，否则在已移除的节点上运行的 sbatch 作业都将重新排队。在最后一种情况下，任务失败，状态为 NODE\$1FAIL，并从队列中消失，必须手动重新提交。
如果您计划执行集群大小调整更新，可以防止作业在计划更新期间将被移除的节点上运行。这可以通过将要移除的节点设置为维护状态来实现。请注意，将节点设置为维护状态不会影响最终已在该节点上运行的作业。
假设在计划的集群大小调整更新中，您将移除节点 `qeueu-st-computeresource-[9-10`]。你可以创建一个 Slurm 使用以下命令进行预订
```
sudo -i scontrol create reservation ReservationName=maint_for_update user=root starttime=now duration=infinite flags=maint,ignore_jobs nodes=qeueu-st-computeresource-[9-10]
```
这将创建一个 Slurm 在节点`maint_for_update`上命名的预留`qeueu-st-computeresource-[9-10]`。从创建预留开始，`qeueu-st-computeresource-[9-10]` 节点上就不能再运行任何作业。请注意，预留不会阻止作业最终在 `qeueu-st-computeresource-[9-10]` 节点上分配。
集群大小更新后，如果 Slurm 仅在调整大小更新期间移除的节点上设置了预留，维护预留将自动删除。相反，如果你创建了一个 Slurm 在集群调整大小更新后仍然存在的节点上进行预留，我们可能需要在执行调整大小更新后使用以下命令删除节点上的维护预留
```
sudo -i scontrol delete ReservationName=maint_for_update
```
欲了解更多详情，请访问 Slurm 预订，请[在此](https://slurm.schedmd.com/reservations.html)处查看 schedMD 官方文档。
## 容量变更时的集群更新过程
调度器配置更改后，将在集群更新过程中执行以下步骤：
+ 停下来 AWS ParallelCluster `clustermgtd (supervisorctl stop clustermgtd)`
+ 生成已更新 Slurm 配置中的分区 AWS ParallelCluster 配置
+ 重启 `slurmctld`（通过 Chef 服务配方完成）
+ 检查 `slurmctld` 状态 `(systemctl is-active --quiet slurmctld.service)`
+ Reload Slurm 配置 `(scontrol reconfigure)`
+ 启动 `clustermgtd (supervisorctl start clustermgtd)`
# 将 AWS Batch (`awsbatch`) 调度器与 AWS ParallelCluster
**警告**
AWS CodeBuild 亚太地区（马来西亚）(`ap-southeast-5`) 和亚太地区（泰国）`ap-southeast-7`() 区域不支持。因此，这些地区不支持 ParallelCluster AWS Batch 集成。
AWS ParallelCluster 还支持 AWS Batch 调度程序。以下主题介绍如何使用 AWS Batch。有关的信息 AWS Batch，请参见[AWS Batch](https://aws.amazon.com/batch/)。有关文档，请参阅 [AWS Batch User Guide](https://docs.aws.amazon.com/batch/latest/userguide/)。
**AWS ParallelCluster 的 CLI 命令适用于 AWS Batch**
使用`awsbatch`调度程序时，的 AWS ParallelCluster CLI 命令 AWS Batch 会自动安装在 AWS ParallelCluster 头节点中。CLI 使用 AWS Batch API 操作并允许执行以下操作：
+ 提交和管理作业。
+ 监控作业、队列和主机。
+ 镜像传统调度器命令。
**重要**
AWS ParallelCluster 不支持 GPU 作业 AWS Batch。有关更多信息，请参阅 [GPU 作业](https://docs.aws.amazon.com/batch/latest/userguide/gpu-jobs.html)。
此 CLI 作为单独的软件包进行分发。有关更多信息，请参阅 [调度器支持](moving-from-v2-to-v3.md#scheduler_support)。
**Topics**
+ [`awsbsub`](awsbatchcli.awsbsub-v3.md)
+ [`awsbstat`](awsbatchcli.awsbstat-v3.md)
+ [`awsbout`](awsbatchcli.awsbout-v3.md)
+ [`awsbkill`](awsbatchcli.awsbkill-v3.md)
+ [`awsbqueues`](awsbatchcli.awsbqueues-v3.md)
+ [`awsbhosts`](awsbatchcli.awsbhosts-v3.md)
# `awsbsub`
向集群的作业队列提交作业。
```
awsbsub [-h] [-jn JOB_NAME] [-c CLUSTER] [-cf] [-w WORKING_DIR]
[-pw PARENT_WORKING_DIR] [-if INPUT_FILE] [-p VCPUS] [-m MEMORY]
[-e ENV] [-eb ENV_DENYLIST] [-r RETRY_ATTEMPTS] [-t TIMEOUT]
[-n NODES] [-a ARRAY_SIZE] [-d DEPENDS_ON]
[command] [arguments [arguments ...]]
```
**重要**
AWS ParallelCluster 不支持 GPU 作业 AWS Batch。有关更多信息，请参阅 [GPU 作业](https://docs.aws.amazon.com/batch/latest/userguide/gpu-jobs.html)。
## 定位参数
***command***
提交作业（指定的命令必须在计算实例上可用），或指定要传输的文件名。另请参阅`--command-file`。
**arguments**
（可选）指定命令或命令文件的参数。
## 命名的参数
**-jn *JOB\$1NAME*, --job-name *JOB\$1NAME***
为作业命名。第一个字符必须是字母或数字。作业名称可以包含字母（大写和小写）、数字、连字符和下划线，长度不超过 128 个字符。
**-c *CLUSTER*, --cluster *CLUSTER***
指定要使用的集群。
**-cf, --command-file**
指示命令是要传输到计算实例的文件。
默认值：False
**-w *WORKING\$1DIR*, --working-dir *WORKING\$1DIR***
指定要用作作业的工作目录的文件夹。如果未指定工作目录，则在用户的主目录的 `job-` 子文件夹中运行作业。您可以使用此参数或 `--parent-working-dir` 参数。
**-pw *PARENT\$1WORKING\$1DIR*, --parent-working-dir *PARENT\$1WORKING\$1DIR***
指定作业的工作目录的父文件夹。如果未指定父工作目录，则默认为用户的主目录。在父工作目录中创建名为 `job-` 的子文件夹。您可以使用此参数或 `--working-dir` 参数。
**-if *INPUT\$1FILE*, --input-file *INPUT\$1FILE***
指定要传输到计算实例的文件（在作业的工作目录中）。您可以指定多个输入文件参数。
**-p *VCPUS*, --vcpus *VCPUS***
指定要为容器保留的 v CPUs 数。与一起使用时`–nodes`，它会标识每个节点CPUs 的 v 数。
默认值：1
**-m *MEMORY*, --memory *MEMORY***
指定要为作业提供的内存的硬限制（以 MiB 为单位）。如果您的作业尝试超出此处指定的内存限制，则该作业将被结束。
默认值：128
**-e *ENV*, --env *ENV***
指定要导出到作业环境的环境变量名称的逗号分隔的列表。要导出所有环境变量，请指定“all”。请注意，“all”环境变量列表不包含 `–env-blacklist` 参数中列出的环境变量，或以 `PCLUSTER_*` 或 `AWS_*` 前缀开头的环境变量。
**-eb *ENV\$1DENYLIST*, --env-blacklist *ENV\$1DENYLIST***
指定**不**会导出到作业环境的环境变量名称的逗号分隔的列表。默认情况下，不会导出 `HOME`、`PWD`、`USER`、`PATH`、`LD_LIBRARY_PATH`、`TERM` 和 `TERMCAP`。
**-r *RETRY\$1ATTEMPTS*, --retry-attempts *RETRY\$1ATTEMPTS***
指定要让作业进入 `RUNNABLE` 状态的次数。可以指定 1 到 10 之间的尝试次数。如果尝试次数大于 1，则作业在失败后将重试，直到它进入 `RUNNABLE` 状态的次数达到指定值。
默认值：1
**-t *TIMEOUT*, --timeout *TIMEOUT***
指定持续时间（以秒为单位）（根据任务尝试`startedAt`的时间戳衡量），如果任务尚未完成，则该持续时间后 AWS Batch 将终止作业。超时值必须至少为 60 秒。
**-n *NODES*, --nodes *NODES***
指定要为作业预留的节点数量。为此参数指定一个值，以启用多节点并行提交。
当 [`Scheduler`](Scheduling-v3.md#yaml-Scheduling-Scheduler)/[`AwsBatchQueues`](Scheduling-v3.md#Scheduling-v3-AwsBatchQueues)/[`CapacityType`](Scheduling-v3.md#yaml-Scheduling-AwsBatchQueues-CapacityType) 参数设置为 `SPOT` 时，*不* 支持多节点并行作业。此外，您的账户中必须有 `AWSServiceRoleForEC2Spot` 服务相关角色。您可以使用以下 AWS CLI 命令创建此角色：
```
$ aws iam create-service-linked-role --aws-service-name spot.amazonaws.com
```
有关更多信息，请参阅《适用于 Linux 实例的 Amazon Elastic Compute Cloud 用户指南》**中的[竞价型实例请求的服务相关角色](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/spot-requests.html#service-linked-roles-spot-instance-requests)。
**-a *ARRAY\$1SIZE*, --array-size *ARRAY\$1SIZE***
指示数组的大小。您可以指定 2 到 10000 之间的值。如果您为一个作业指定数组属性，该作业将变为数组作业。
**-d *DEPENDS\$1ON*, --depends-on *DEPENDS\$1ON***
指定作业的依赖项的分号分隔的列表。一个作业可依赖于最多 20 个作业。您可以指定 `SEQUENTIAL` 类型依赖项，而不指定数组作业的作业 ID。顺序依赖项允许每个子数组作业按顺序完成，从索引 0 开始。您也可以使用数组作业的作业 ID 指定 N\$1TO\$1N 类型依赖项。N\$1TO\$1N 依赖项意味着此作业的每个子索引必须等待每个依赖项的相应子索引完成后才能开始。此参数的语法是 “jobid=**，type=**;...”。
# `awsbstat`
显示集群的作业队列中提交的作业。
```
awsbstat [-h] [-c CLUSTER] [-s STATUS] [-e] [-d] [job_ids [job_ids ...]]
```
## 定位参数
***job\$1ids***
指定要在输出中显示的 IDs 以空格分隔的作业列表。如果作业是作业数组，则显示所有子作业。如果请求单个作业，则将以详细版本显示该作业。
## 命名的参数
**-c *CLUSTER*, --cluster *CLUSTER***
指示要使用的集群。
**-s *STATUS*, --status *STATUS***
指定要包含的作业状态的逗号分隔的列表。默认作业状态为“活动”。接受的值为：`SUBMITTED`、`PENDING`、`RUNNABLE`、`STARTING`、`RUNNING`、`SUCCEEDED`、`FAILED` 和 `ALL`。
默认值：“`SUBMITTED`,`PENDING`,`RUNNABLE`,`STARTING`,`RUNNING`”
**-e, --expand-children**
展开具有子作业（数组和多节点并行）的作业。
默认值：False
**-d, --details**
显示作业详细信息。
默认值：False
# `awsbout`
显示给定作业的输出。
```
awsbout [-h] [-c CLUSTER] [-hd HEAD] [-t TAIL] [-s] [-sp STREAM_PERIOD] job_id
```
## 定位参数
***job\$1id***
指定作业 ID。
## 命名的参数
**-c *CLUSTER*, --cluster *CLUSTER***
指示要使用的集群。
**-hd *HEAD*, --head *HEAD***
获取任务输出的第一*HEAD*行。
**-t *TAIL*, --tail *TAIL***
获取作业输出的最后几个 行。
**-s, --stream**
获取作业输出，然后等待生成其他输出。此参数可与 –tail 一起使用，以从作业输出的最新 行开始。
默认值：False
**-sp *STREAM\$1PERIOD*, --stream-period *STREAM\$1PERIOD***
设置流式传输时段。
默认：5
# `awsbkill`
取消或终止集群中提交的作业。
```
awsbkill [-h] [-c CLUSTER] [-r REASON] job_ids [job_ids ... ]
```
## 定位参数
***job\$1ids***
指定要取消或终止的 IDs 以空格分隔的作业列表。
## 命名的参数
**-c *CLUSTER*, --cluster *CLUSTER***
指示要使用的集群的名称。
**-r *REASON*, --reason *REASON***
指示要附加到作业的消息，并说明取消作业的原因。
默认：”Terminated by the user”
# `awsbqueues`
显示与集群关联的作业队列。
```
awsbqueues [-h] [-c CLUSTER] [-d] [job_queues [job_queues ... ]]
```
## 定位参数
***job\$1queues***
指定要显示的队列的空格分隔的列表。如果请求单个队列，则将以详细版本显示该队列。
## 命名的参数
**-c *CLUSTER*, --cluster *CLUSTER***
指定要使用的集群的名称。
**-d, --details**
指明是否显示队列的详细信息。
默认值：False
# `awsbhosts`
显示属于集群的计算环境的主机。
```
awsbhosts [-h] [-c CLUSTER] [-d] [instance_ids [instance_ids ... ]]
```
## 定位参数
***instance\$1ids***
指定以空格分隔的实例 IDs列表。如果请求单个实例，则将以详细版本显示该实例。
## 命名的参数
**-c *CLUSTER*, --cluster *CLUSTER***
指定要使用的集群的名称。
**-d, --details**
指示是否显示主机的详细信息。
默认值：False