升级指南

Slurm 支持在某些版本之间进行就地升级。此页面提供了执行升级所需步骤的重要细节以及需要准备的潜在复杂性。

另请参见 快速入门管理员指南

目录

• 发行周期
  • 兼容窗口
  • EPEL 仓库
  • 预发行版本
• 恢复升级
• 小版本升级
• 升级程序
  • 准备
  • 创建备份
  • slurmdbd（会计）
    • 数据库服务器
  • slurmctld（控制器）
  • slurmd（计算节点）
  • 其他 Slurm 命令
  • 自定义 Slurm 插件
• 无缝升级

发行周期

Slurm 版本号包含三个用句点分隔的数字，表示主要的 Slurm 版本和维护版本级别。例如，Slurm 23.11.4：

• 23.11 = 主要版本
  • 这与初始发行的年份和月份相匹配（2023年11月）
  • 主要版本可能包含对 RPC（远程过程调用）、状态文件、配置选项和核心功能的更改
• .4 = 维护版本
  • 维护版本可能包含错误修复和性能改进

在 24.05 版本发布之前，Slurm 在主要版本上采用 9 个月的发布周期。Slurm 24.05 代表在新的 6 个月周期上的第一次发布。

兼容窗口

来自前两个主要版本的升级是兼容的。例如，slurmdbd 23.11.x 能够接受来自版本为 23.11.x、23.02.x 或 22.05.x 的 slurmctld 守护进程和命令的消息。它还能够更新由运行这些版本的 slurmdbd 实例记录的数据库中的记录。

Slurm 24.11 版本引入了与三个以前主要版本的兼容性，以提供与更频繁的 6 个月发布周期相似的支持持续时间：

Slurm 版本	修订后的支持结束日期 (总长度)	兼容的先前版本
23.11	2025年5月（18个月）	23.02, 22.05
24.05	2025年11月（18个月）	23.11, 23.02
24.11	2026年5月（18个月）	24.05, 23.11, 23.02
25.05	2026年11月（18个月）	24.11, 24.05, 23.11
25.11	2027年5月（18个月）	25.05, 24.11, 24.05
26.05	2028年11月（18个月）	25.11, 25.05, 24.11

来自不兼容版本的升级将在启动时立即失败。必须分步骤执行来自不兼容先前版本的升级，逐步升级到与当前运行版本兼容的新版本。可能需要几个步骤才能升级到当前的 Slurm 版本。例如，不要直接从 Slurm 20.11 升级到 23.11，而是先将所有系统升级到 Slurm 22.05 并验证功能，然后再升级到 23.11。这确保每次执行的升级都经过测试，并且可以得到 SchedMD 的支持。兼容性要求适用于正在运行的作业，升级超出其兼容窗口将导致作业被终止，作业会计数据丢失。

EPEL 仓库

在 2021 年初，Slurm 的一个版本被添加到 EPEL 仓库中。此版本不由 SchedMD 提供或支持，且目前不支持客户使用。不幸的是，这一包含可能导致 Slurm 在计划的维护期之外被更新到较新版本，或导致软件包冲突。为了防止 Slurm 被意外更改和破坏，我们建议您修改 EPEL 仓库配置，以排除所有 Slurm 软件包的自动更新。

在 /etc/yum.repos.d/epel.repo 的 [epel] 部分下添加以下内容：

exclude=slurm*

预发行版本

安装预发行版本（例如，24.05.0rc1 或 主分支）时，您应该准备好应对意外崩溃、错误和状态信息丢失。SchedMD 旨在使用 NEWS 文件指示在预发行版本中将丢失状态信息的情况。然而，这些预发行版本仅经过有限测试，并不适用于生产集群。鼓励站点在每个主要版本发布之前在测试机器上积极运行预发行版本。

恢复升级

一旦任何 Slurm 守护进程已启动，恢复升级（或降级）是不支持的。在升级后启动时，Slurm 守护进程（slurmctld、slurmdbd 和 slurmd）将更新其相关的状态文件和数据库，以使用新版本中使用的结构。如果您恢复到旧版本，相关的 Slurm 守护进程将无法识别新的状态文件或数据库，导致状态信息或作业会计数据的丢失或损坏。Slurm 守护进程可能会拒绝启动，除非配置为在可能的数据丢失风险下启动。

通过使用恢复工具，如全面的文件备份、磁盘映像和快照，可能可以将组件恢复到升级前的状态。特别是，如果您希望恢复升级，则需要恢复 StateSaveLocation（在 slurm.conf 中定义）和（如果配置）会计数据库的内容。恢复升级将清除备份创建后发生的任何内容。

小版本升级

当升级到较新的小维护版本时（如上述定义），我们建议遵循与主要版本相同的升级程序。您会发现这个过程所需的时间更少，并且更能适应混合版本和就地降级。然而，您始终应该拥有当前的备份，以巩固您的恢复选项。

升级程序

升级程序可以总结如下。请注意守护进程应升级的特定顺序：

1. 为升级准备集群
2. 创建备份
3. 升级 slurmdbd
4. 升级 slurmctld
5. 升级 slurmd（最好与 slurmctld 一起）
6. 升级 登录节点和客户端命令
7. 重新编译/升级 自定义 Slurm 插件
8. 测试关键功能
9. 归档备份数据

在考虑升级完成之前，请等待所有已运行的作业完成。在slurmd 系统升级之前启动的任何作业将使用旧版本的slurmstepd 运行，因此启动另一个升级或尝试使用新版本中的新功能可能会导致问题。

注意：如果使用 RPM/DEB 软件包，则每个系统上存在的所有软件包必须一起升级，而不是逐个升级。这是因为包含 Slurm 守护进程和客户端命令的软件包依赖于通用的slurm 软件包。避免使用低级包管理器，如 rpm 或 dpkg，因为它们可能无法正确强制执行这些依赖关系。升级后，守护进程应按上述顺序启动。

在同一系统上运行多个守护进程不是推荐的生产设置，部分原因是逐个升级的限制。强烈建议站点为每个系统分配一个 Slurm 守护进程（slurmd、slurmctld 或 slurmdbd）。

准备

RELEASE_NOTES 和 CHANGELOG

查看目标版本及您当前运行的版本与目标版本之间的任何主要版本的RELEASE_NOTES.md 文件中的相关发行说明。特别注意任何条目中删除或更改的项目。这些项目在升级过程中特别可能需要特定的关注或更改。还要查看您正在使用的可选 slurm 组件的更改。您可能还会注意到在升级后希望开始使用的 Slurm 中添加的新项目。

最新主要版本的发行说明可在此处或在 GitHub 上（RELEASE_NOTES.md）获得。其他版本的发行说明可以在源代码中找到，可以通过选择与所需版本相对应的分支或标签在 GitHub 上查看。（请参阅RELEASE_NOTES 以获取 Slurm 24.11 及更早版本。）更详细的更改，包括小版本更改，可以在CHANGELOG 目录中找到（以前是 NEWS 文件），但通常不需要为升级做准备。

配置更改

在生产环境中升级之前，始终在测试环境中准备和测试配置更改。发行说明中概述的更改需要在手册页中查找（例如slurm.conf）以获取详细信息和新语法。您的配置文件中的某些选项可能需要更改，因为每个主要 Slurm 版本中的功能和功能都有所改进。通常，新命名和语法约定在旧约定被删除之前的几个版本中引入，因此您可能能够在开始升级过程之前进行必要的更改。

计划停机时间

请参考以下各个相关 Slurm 守护进程的预期停机时间指导，特别是slurmdbd。通知受影响的用户相关服务的预计停机时间及其作业可能受到的影响。尽可能在 SchedMD 的支持时间内计划升级。如果您在这些时间之外遇到问题，提供帮助将会有延迟。

OpenAPI 更改

使用 --json 或 --yaml 参数的任何 CLI 命令或运行 slurmrestd 的站点需要在升级之前检查格式兼容性和数据解析器插件的删除。解析和转储为 JSON 和 YAML 的值的格式由数据解析器和 openapi 插件处理。格式的更改在OpenAPI 发行说明中跟踪。

发行说明	添加的 OpenAPI 插件	添加的数据解析器插件	在发行中删除
24.05		v0.0.41	26.05
24.11		v0.0.42	26.11
25.05		v0.0.43	27.05
25.05		v0.0.44	27.11

注意：未版本化的 openapi/slurmctld 和 openapi/slurmdbd 插件没有计划删除的版本。

任何使用 --json 或 --yaml 参数的脚本或客户端可能需要显式传递数据解析器版本，以避免在升级后出现问题。使用的默认数据解析器是最新版本，可能与先前版本不兼容。站点可以使用规范生成模式来比较格式差异。

$CLI_COMMAND --json=v0.0.41+spec_only > /tmp/v41.json;
$CLI_COMMAND --json=v0.0.40+spec_only > /tmp/v40.json;
json_diff /tmp/v40.json /tmp/v41.json;

如果发生格式不兼容，可以在插件删除之前的任何版本中显式请求首选数据解析器，从 v0.0.40 插件开始。

$CLI_COMMAND --json=v0.0.41 $OTHER_ARGS | $SITE_SCRIPT;
$CLI_COMMAND --json=v0.0.40 $OTHER_ARGS | $SITE_SCRIPT;
$CLI_COMMAND --yaml=v0.0.41 $OTHER_ARGS | $SITE_SCRIPT;
$CLI_COMMAND --yaml=v0.0.40 $OTHER_ARGS | $SITE_SCRIPT;

任何 slurmrestd 网络客户端可以通过查看被查询的 URL 来确定使用的相关插件。示例 URL：

http://$HOST/slurmdb/v0.0.40/jobs
http://$HOST/slurm/v0.0.40/jobs

示例 URL 中的相关数据解析器插件是 "v0.0.40"，与 data_parser/v0.0.40 插件匹配。插件命名遵循 vXX.XX.XX 的命名方案，其中 XX 是数字。命名方案与 Slurm 的打包二进制 RPC 层的内部命名方案相匹配，但并不直接相关。每个给定数据解析器插件的 URL 将保持有效的查询目标，直到插件被删除，作为 SchedMD 确保发布有限向后兼容性的承诺。虽然在插件仍受支持时继续使用先前版本的任何客户端应该是可能的，但站点在升级之前应始终重新编译任何生成的 OpenAPI 客户端并进行彻底测试。

创建备份

始终创建完整备份以恢复 Slurm 的所有部分，包括 Mysql 数据库，在升级之前，以防必须恢复升级。SchedMD 旨在使受支持的升级成为无缝过程，但可能会出现意外问题，并不可逆转地损坏 Slurm 保留的所有数据。如果发生这种情况，将无法恢复任何损坏的数据，您将依赖备份数据。

建议准备恢复选项（文件备份、磁盘映像、快照、数据库转储），以便将您恢复到已知的工作集群状态。备份的方式取决于系统集成商设计和设置集群的方式，此处不提供程序。

至少，备份以下内容：

• StateSaveLocation，如在slurm.conf 中定义，或可以通过调用

  scontrol show config | grep StateSaveLocation

  查询
• 整个 slurm 配置目录，如在编译期间通过configure --sysconfdir=DIR 定义。这通常位于 /etc/slurm/
• MySQL 数据库（如果配置了 slurmdbd）。通常通过调用

  mysqldump --databases slurm_acct_db > /path/to/offline/storage/backup.sql
  

  假设在转储运行时slurmdbd未运行。
  如果您希望在slurmdbd运行时备份，您可以使用--single-transaction 标志，但有以下限制：
  1. 在转储运行时，数据库操作可能会变慢
  2. 恢复此转储将恢复转储开始时的数据库，丢失转储期间或之后所做的任何更改
  3. 某些集群操作可能会导致转储不正确或失败：
     • 创建新数据库
     • 升级现有数据库
     • 在 slurmdbd 中添加或删除集群
     • 归档或清除 会计数据

slurmdbd（会计）

如果您的环境中使用slurmdbd，则其主要版本号必须与 slurmctld 守护进程相同或更高，并且版本必须足够接近以满足兼容性。因此，在执行升级时，应该首先升级它。当使用备份 slurmdbd 主机时，应与主机同时升级。

升级 slurmdbd 可能需要较长的停机时间。对于大型会计数据库，预防性数据库转储将需要一些时间，升级后的守护进程在将数据库更新到新架构时可能会无响应数十分钟。鼓励站点使用清除功能，如果不需要旧的会计数据进行正常操作。在尝试升级之前清除旧记录可以显著减少停机时间。

在升级过程中，集群的非 slurmdbd 功能将继续运行，只要活动不会填满 slurmctld 节点上的 slurmdbd Agent 队列。当 slurmdbd 离线时，您应该监控 slurmctld 的内存使用情况，以及由sdiag报告的DBD Agent 队列大小，以确保其不超过slurm.conf 中配置的MaxDBDMsgs。在 slurmdbd 离线时，CLI 命令sacct 和sacctmgr 将无法工作。包含 slurmdb 的 URL 路径的 slurmrestd 查询将在 slurmdbd 离线时失败。

建议在关闭slurmdbd 守护进程后创建数据库备份，此时 MySQL 数据库不再更改。如果您希望在 slurmdbd 仍在运行时使用mysqldump 进行备份，可以将 --single-transaction 添加到 mysqldump 命令中。请注意，slurmdbd 将继续执行不包含在转储中的操作，如果您需要将数据库恢复到此状态，可能会导致并发问题。

建议的升级程序如下：

1. 优雅地关闭 slurmdbd 守护进程：

   sacctmgr shutdown

   或通过 systemd：

   systemctl stop slurmdbd

   在继续之前，请等待 slurmdbd 完全关闭，否则可能会丢失未完全保存的数据。

   systemctl status slurmdbd

2. 备份 Slurm 数据库
3. 验证 my.cnf 中的 innodb_buffer_pool_size 大于默认值。请参阅会计页面中的建议。
4. 升级 slurmdbd 守护进程的二进制文件、库和其 systemd 单元文件（如果使用）。如果使用RPM/DEB 软件包，软件包管理器将处理这些，尽管 systemd 覆盖可能会阻止新单元生效。
   此时仅升级 slurmdbd 系统；其他 Slurm 系统应保持在旧版本。
5. 启动主 slurmdbd 守护进程。
   注意：如果您通常使用 systemd，建议最初以配置的 SlurmUser 直接启动守护进程：
   sudo -u slurm slurmdbd -D
   当守护进程在升级后首次启动时，将花费额外时间更新数据库中的现有记录。如果使用 systemd 启动并达到配置的超时值，可能会被提前终止，可能导致数据丢失。在启动完成后，您可以使用 Ctrl+C 退出，然后正常使用 systemd 启动。
6. 启动备份 slurmdbd 守护进程（如适用）。
7. 验证会计操作，例如通过 sacct 或 sacctmgr 检索数据。

数据库服务器

在升级 slurmdbd 使用的数据库服务器（例如 MySQL 或 MariaDB）时，通常不需要特殊程序。建议使用由发布者支持的数据库服务器（或在选择的 Slurm 版本首次发布时支持的数据库服务器）。数据库升级应在 slurmdbd 停止时进行，并根据所使用数据库的推荐程序进行。

从旧版本的 MariaDB 或任何版本的 MySQL 升级现有会计数据库到MariaDB 10.2.1 或更高版本时，请确保您运行的是slurmdbd 22.05.7 或更高版本。这些版本将优雅地处理可能导致 slurmdbd 问题的 MariaDB 默认值的更改。

slurmctld（控制器）

建议在计算节点上与 slurmd 同时升级 slurmctld 系统，以及在客户端机器和登录节点上升级其他 Slurm 命令。slurmctld 和 slurmd 守护进程的停机影响基本相同，因此同时升级它们可以最小化这些影响的总持续时间。如果首先升级 slurmctld，则也可以进行滚动升级。当使用多个 slurmctld 主机时，所有主机应同时升级。

升级 slurmctld 将涉及短暂的停机时间，在此期间不接受作业提交，排队作业不会被调度，完成作业的信息将被保留。升级后的控制器启动后，这些功能将恢复。

推荐的升级程序如下，包括同时升级 slurmd 系统的可选步骤：

1. 增加配置的 SlurmdTimeout 和 SlurmctldTimeout 值，并执行 scontrol reconfig 以使其生效。
   新超时应足够长，以便使用您首选的方法进行升级。如果达到超时，节点可能会被标记为 DOWN 并终止其作业。
2. 关闭 slurmctld 守护进程。
3. (可选) 关闭计算节点上的 slurmd 守护进程。
4. 备份配置的 StateSaveLocation 的内容。
5. 升级 slurmctld（可选地升级 slurmd）守护进程及其 systemd 服务文件（如果使用）。
6. (可选) 重新启动计算节点上的 slurmd 守护进程。
7. 重新启动 slurmctld 守护进程。
8. 验证正常操作，例如与节点的通信以及作业成功启动和完成的能力。
9. 恢复首选的 SlurmdTimeout 和 SlurmctldTimeout 值，并执行 scontrol reconfig 以使其生效。

slurmd（计算节点）

建议在升级 slurmctld 的同时升级所有 slurmd 节点。也可以通过在任何数量的组中稍后升级 slurmd 节点来执行滚动升级。鼓励站点尽量减少集群中使用混合版本的时间。

只要在此过程中未达到SlurmdTimeout，升级将不会中断正在运行的作业。然而，在 slurmd 升级期间，新的作业将不会启动，完成的作业将在 slurmd 重新上线之前等待向控制器报告。

如果您与控制器分开升级 slurmd 节点，可以遵循以下程序：

1. 增加配置的 SlurmdTimeout 值，并执行 scontrol reconfig 以使其生效。
   新超时应足够长，以便使用您首选的方法进行升级。如果达到超时，节点可能会被标记为 DOWN 并终止其作业。
2. 关闭计算节点上的 slurmd 守护进程。
3. 备份配置的 StateSaveLocation 的内容。
4. 升级 slurmd 守护进程及其 systemd 单元文件（如果使用）。
5. 重新启动 slurmd 守护进程。
6. 验证正常操作，例如与控制器的通信以及作业成功启动和完成的能力。
7. 对需要升级的其他节点组重复上述步骤。
8. 恢复首选的 SlurmdTimeout 值，并执行 scontrol reconfig 以使其生效。

其他 Slurm 命令

其他 Slurm 命令（包括客户端命令）在升级时不需要特别关注，除非在发行说明中特别说明。您还应注意这些附加组件中引入的任何更改。在升级核心 Slurm 组件后，使用系统的正常方法升级附加组件及其 systemd 单元文件（如果使用），然后重新启动任何受影响的守护进程。

自定义 Slurm 插件

Slurm 的主要公共 API 库 (libslurm.so.X.0.0) 在每个主要版本发布时都会增加其版本号，因此任何链接到它的应用程序在升级后都应重新编译。这包括本地开发的 Slurm 插件。

如果您构建了自己的 Slurm 插件版本，除了必须重新编译它们外，它们可能还需要修改以支持新的 Slurm 版本。插件在主要更新期间通常会添加新功能和函数参数。有关这些更改的详细信息，请参阅 RELEASE_NOTES 文件。

Slurm 的 PMI-1 (libpmi.so.0.0.0) 和 PMI-2 (libpmi2.so.0.0.0) 公共 API 库在版本之间不会更改，旨在永久固定。这意味着链接到它们中的任何一个都不需要在 Slurm 升级后重新编译应用程序，除非发生不太可能的更改。因为这些库必须与任何其他 PMI-1 和 PMI-2 实现兼容。如果发生更改，将在 RELEASE_NOTES 中宣布，并且只会在主要版本发布时发生。

例如，像 OpenMPI 和 MVAPICH2 这样的 MPI 堆栈链接到 Slurm 的 PMI-1 和/或 PMI-2 API，但不链接到我们的主要公共 API。这意味着在撰写本文档时，您在 Slurm 升级后无需重新编译这些堆栈。已知的一个例外是 MPICH。当 MPICH 与 Slurm 支持和 Hydra 进程管理器一起编译时，它将使用 Slurm API 获取作业信息。这种链接意味着在升级后您需要重新编译 MPICH 堆栈。

确定应用程序是否需要重新编译的一个简单方法是使用 'ldd' 检查其所有 ELF 文件，并 grep 查找 'slurm'。如果您看到版本化的 'libslurm.so.x.y.z' 引用，则该应用程序可能需要重新编译。

无缝升级

在 Slurm 构建过程被自定义的环境中，可以将新版本的 Slurm 安装到唯一目录，并使用符号链接将您的 PATH 中的目录指向您希望使用的 Slurm 版本。这使您能够在维护期之前安装新版本，并在需要回滚时轻松切换版本。它还避免了由于将不同版本安装到同一目录而可能出现的库冲突问题。

最后修改于 2025年6月5日