slurm - SLURM 高可用性头节点

根据https://slurm.schedmd.com/quickstart_admin.html#HA的说法，SLURM 的高可用性是通过部署第二个 BackupController 来实现的，该控制器在主服务器发生故障时接管并从共享文件系统（可能是 NFS）检索当前状态。

在我看来，这有很多缺点。例如，这将服务器的总数限制为两个，而第二个服务器可能几乎没有使用。

这是使用 SLURM 获得高可用性头节点的唯一方法吗？

我想做的是经典的 3 层设置：第一层的负载均衡器将所有请求均匀地分布在第二层的节点上。这要求头节点是无状态的。第三层是存储或读取所有信息的数据库层。我对 SLURM 的内部结构一无所知，我不确定这是否可能。

标签： slurm

StateSaveLocation在目前的设计中，控制器内部状态是 in-memory，Slurm 会定期将其保存到配置参数指向的目录下的一组文件中。一次只有一个实例slurmctld可以写入该目录。

将状态存储在数据库中的一个问题是资源分配的可怕延迟，需要大量同步，因为最佳资源分配只能通过完整信息完成。与当前仅对内存中的数组进行按位操作的解决方案相比，支持与 Slurm 现在可以处理内存状态相同级别的吞吐量所需的基础设施将非常昂贵。

这是使用 SLURM 获得高可用性头节点的唯一方法吗？

您还可以使用 Corosync 管理单个 MasterController。但实际上，Slurm 仅具有可用于 HA 的主动/被动选项。

在我看来，这有很多缺点。例如，这将服务器的总数限制为两个，而第二个服务器可能几乎没有使用。

相对于当前的处理能力，控制器上的负载通常是非常合理的，并且资源分配问题不能简单地并行化（或无状态）。通常，备份控制器位于运行另一个服务的机器上。例如，在小型部署中，一台机器运行 Slurm 主控制器和其他服务（NFS、LDAP 等）等，而另一台机器是用户登录节点，它也充当辅助 Slurm 控制器。