Slurm 集群受保护模式 - AWS ParallelCluster

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

Slurm 集群受保护模式

当集群在启用保护模式的情况下运行时,会在启动计算节点时 AWS ParallelCluster 监控和跟踪计算节点引导失败。这样做是为了检测这些失败是否持续发生。

如果在队列(分区)中检测到以下情况,集群将进入受保护状态:

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

  2. 失败计数达到预定义的阈值。

集群进入保护状态后, AWS ParallelCluster 禁用故障等于或高于预定义阈值的队列。

Slurm3.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 <cluster-name> --region <region-id> { "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]

分区 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 日志 (/var/log/parallelcluster/clustermgtd) 中查找类似于下面的错误:

    Node bootstrap error: Node ... is in power up state without valid backing instance
  2. 节点 resume_timeoutnode_replacement_timeout 过期

    实例无法在 resume_timeout 内(对于动态节点)或 node_replacement_timeout 内(对于静态节点)加入集群。它不会在超时之前自行终止。例如,在未为集群正确设置网络的情况下,在超时过期后,Slurm 会将节点设置为 DOWN 状态。

    对于动态节点,请查找类似于下面的错误:

    Node bootstrap error: Resume timeout expires for node

    对于静态节点,请在 clustermgtd 日志 (/var/log/parallelcluster/clustermgtd) 中查找类似于下面的错误:

    Node bootstrap error: Replacement timeout expires for node ... in replacement.
  3. 节点未通过运行状况检查

    节点后面的实例未通过 Amazon EC2 运行状况检查或计划事件运行状况检查,并且这些节点被视为引导失败节点。在这种情况下,实例因超出控制范围的原因而终止。 AWS ParallelCluster

    请在 clustermgtd 日志 (/var/log/parallelcluster/clustermgtd) 中查找类似于下面的错误:

    Node bootstrap error: Node %s failed during bootstrap when performing health check.
  4. 计算节点 Slurm 注册失败

    slurmd 进程守护程序向 Slurm 控制进程守护程序 (slurmctld) 注册失败并导致计算节点状态变为 INVALID_REG 状态。配置不正确的 Slurm 计算节点可能会导致此错误,例如使用 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日志,则可以查看日志以了解错误详情。有关如何检索日志的更多信息,请参阅检索和保留日志

头节点上的 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 地址后,您可以登录计算节点或按照检索和保留日志中的指导检索日志,找到相应的计算节点日志。在大多数情况下,有问题的节点的 /var/log/cloud-init-output 日志会显示导致计算节点引导失败的步骤。