Slurm：处理云调度系统中POWER_UP失败的节点

Question

问题

当前行为和问题描述

当节点未能

POWER_UP

时，它会被标记为

DOWN

。虽然这总体上是一个好主意，但在使用

CLOUD

节点时这没有用，因为所述

CLOUD

节点可能在不同的机器上启动，因此到

POWER_UP

没有问题。但由于该节点被标记为关闭，该云资源将不再使用，并且在手动释放之前不会再次启动。

想要的行为

理想情况下，slurm 不会将节点标记为

DOWN

，而只是尝试启动另一个节点。如果这不可能，自动恢复

DOWN

节点也是一种选择。

问题

如何防止slurm将无法

POWER_UP

的节点标记为

DOWN

或让slurm自动恢复

DOWN

节点以防止slurm忘记云资源？

尝试与想法

返回服务

我尝试使用

ReturnToService

解决这个问题，但这似乎并没有解决我的问题，因为，如果我理解正确的话，那只会接受自行启动的 slurm 节点，或者在调度作业时手动不考虑它们直到他们开始。

恢复失败的程序

我考虑过使用

ResumeFailedProgram

，但这听起来很奇怪，你必须自己编写一个脚本来让节点恢复服务。

SlurmctldParameters=idle_on_node_suspend

虽然这很棒并且绝对有帮助，但它并不能解决当前的问题，因为在通电期间发生故障的节点不会被挂起。

附加信息

在

POWER_UP

脚本中，如果安装因任何原因失败并返回不等于 0 的退出代码，我将终止服务器。

在我们的云调度中，实例在需要时创建，一旦不再删除则删除。这意味着 slurm 存储节点是

DOWN

，而其背后的真实实例不再存在。如果该节点没有被标记为

DOWN

并且稍后会为其安排作业，那么它只会启动一个实例并在该新实例上运行。我只是说这是最明确的。

Answer 1

ResumeFailProgram

正是解决这个问题的方法。您遇到了 slurm 的“节点”视图与云环境中实际提供这些节点的内容之间的不匹配问题。在这种情况下，ResumeFailProgram 可能应该使用云 API 来检查它是否实际上可能是暂时的配置失败（例如，超出配额、丢失网络等一些错误可能需要干预而不是重试，并且保持 DOWN 状态可能是正确的做法），那么如果是这样，只需运行

scontrol update nodename=whatever state=resume

以使该“节点”（实际上，这里只是一个节点名称）符合节电条件，然后尝试再次“恢复”它。