本文属于机器翻译版本。若本译文内容与英语原文存在差异，则一律以英文原文为准。
# 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` 日志会显示导致计算节点引导失败的步骤。