Slurm集群保护模式

当集群在启用保护模式下运行时，会在启动计算节点启动时AWS ParallelCluster监控和跟踪这些故障，以检测故障是否持续发生。

如果检测到以下任一情况，集群将进入保护模式：

1. 连续的引导失败会持续发生，没有成功启动计算节点。

2. 队列的失败次数达到预定义的阈值。

集群进入保护模式后，AWS ParallelCluster禁用故障等于或高于预定义阈值的一个或多个队列。

Slurm在 3.0.0AWS ParallelCluster 版中添加了集群保护模式。

您可以使用保护模式来减少在计算节点引导故障循环上花费的时间和资源。

受保护节点参数

protected_failure_count

protected_failure_count指定激活群集保护节点的连续失败次数。

默认值protected_failure_count为 10，保护模式已启用。

如果小protected_failure_count于或等于零，则禁用保护模式。

您可以通过在中的clustermgtd配置文件中添加参数来更改该protected_failure_count值HeadNode。/etc/parallelcluster/slurm_plugin/parallelcluster_clustermgtd.conf

您可以随时更新此参数，无需停止计算队列即可进行更新。如果在失败计数达到之前在队列中成功启动protected_failure_count，则失败计数将重置为零。

在保护模式下检查集群状态

当集群处于保护模式时，您可以检查计算队列状态和节点状态。

计算舰队状态

计算队列的状态PROTECTED是在保护模式下运行的集群中。

$ pcluster describe-compute-fleet --cluster-name <cluster-name> --region <region-id>
{
   "status": "PROTECTED",
   "lastStatusUpdatedTime": "2022-04-22T00:31:24.000Z"
}

节点状态

要了解哪些队列（分区）的引导失败且已激活保护模式，请登录到集群并运行sinfo命令。引导失败等于或以上的分区protected_failure_count位于INACTIVE state。没有等于或更高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]

分区queue1INACTIVE是因为检测到连续 10 次的引导失败。

节点后面的实例queue1-dy-c5xlarge-[1-10]已启动，但由于状态不佳而未能加入集群。

集群处于保护模式。

分区queue2不受中的引导失败的影响queue1。它处于UP状态，还能开展工作。

如何停用保护模式

解决引导错误后，您可以运行以下命令使集群退出保护模式。

$ pcluster update-compute-fleet --cluster-name <cluster-name> \
  --region <region-id> \
  --status START_REQUESTED

激活保护模式的引导失败

激活保护模式的引导错误可细分为以下三种类型。要确定类型和问题，您可以检查是否AWS ParallelCluster生成了日志。如果日志已生成，则可以检查其中的错误详细信息。有关更多信息，请参阅检索和保留集群日志：

1. 引导错误导致实例自行终止。

   实例在引导过程的早期失败，例如由于 SlurmQueues\ CustomActions\ OnNodeStart| OnNodeConfigured脚本中的错误而自行终止的实例。

   对于动态节点，查找与下面类似。

   Node bootstrap error: Node ... is in power up state without valid backing instance

   对于静态节点，请在clustermgtd log (/var/log/parallelcluster/clustermgtd) 中查找与以下内容类似的错误。

   Node bootstrap error: Node ... is in power up state without valid backing instance

2. 节点resume_timeout或node_replacement_timeout过期。

   实例无法加入resume_timeout（对于动态节点）或node_replacement_timeout（对于静态节点）内的集群。它不会在超时之前自行终止。例如，群集的网络设置不正确，并且该节点在超时到期Slurm后设置为DOWN状态。

   对于动态节点，查找与下面类似。

   Node bootstrap error: Resume timeout expires for node

   对于静态节点，请在clustermgtd log (/var/log/parallelcluster/clustermgtd) 中查找与以下内容类似的错误。

   Node bootstrap error: Replacement timeout expires for node ... in replacement.

3. 节点未通过运行状况检查。

   节点后面的实例未通过 EC2 运行状况检查或预定事件运行状况检查，这些节点被视为引导失败节点。在这种情况下，实例由于无法AWS ParallelCluster控制的原因而终止。

   在clustermgtd log (/var/log/parallelcluster/clustermgtd) 中查找与以下内容类似的错误。

   Node bootstrap error: Node %s failed during bootstrap when performing health check.

如何调试保护模式

在得知集群处于受保护状态后，如果从和有问题的计算节点AWS ParallelCluster生成clustermgtd了cloud-init-output日志，则可以查看日志以了解错误详细信息。HeadNode有关如何检索日志的更多信息，请参阅检索和保留集群日志。

clustermgtd头节点上的 log (/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计算节点上的 log (/var/log/cloud-init-output.log)

在clustermgtd日志中获取引导失败节点私有 IP 地址后，您可以通过登录计算节点或按照中的检索和保留集群日志指南检索日志来找到相应的计算节点日志。在大多数情况下，来自有问题节点/var/log/cloud-init-output的日志显示了导致计算节点引导失败的步骤。