Slurm Burst Buffer 指南

概述

本指南解释了如何使用 Slurm burst buffer 插件。在适当的情况下，它解释了这些插件的工作原理，以便为如何最好地使用这些插件提供指导。

Slurm burst buffer 插件在作业生命周期的不同阶段调用脚本：

  1. 在作业提交时
  2. 在作业在估计开始时间后待处理时。这称为“阶段输入”。
  3. 一旦作业已被调度但尚未开始运行。这称为“预运行”。
  4. 一旦作业完成或被取消，但 Slurm 尚未释放作业的资源。这称为“阶段输出”。
  5. 一旦作业完成，Slurm 已释放作业的资源。这称为“拆除”。

该脚本在 slurmctld 节点上运行。支持的插件有：

  • datawarp
  • lua

Datawarp

该插件提供了对 Cray 的 Datawarp API 的钩子。Datawarp 实现了 burst buffer，它是一个共享的高速存储资源。Slurm 提供了分配这些资源的支持，文件的阶段输入、调度使用这些资源的计算节点，以及文件的阶段输出。Burst buffer 也可以在作业生命周期内用作临时存储，而无需文件阶段输入。另一个典型用例是用于与任何特定作业无关的持久存储。

Lua

该插件提供了对由 Lua 脚本定义的 API 的钩子。该插件的开发旨在为系统管理员提供在作业生命周期的不同阶段执行任何任务（不仅仅是文件阶段输入）的方法。这些任务可能包括文件阶段输入、节点维护或在上述五个作业状态中的一个或多个状态下希望运行的任何其他任务。

只有明确请求使用 burst buffer API 的作业才会调用这些 API。作业提交命令部分解释了作业如何请求使用 burst buffer API。

配置（针对系统管理员）

常见配置

  • 要启用 burst buffer 插件，请在 slurm.conf 中设置 BurstBufferType。如果未设置，则不会加载任何 burst buffer 插件。只能指定一个 burst buffer 插件。
  • 在 slurm.conf 中，您可以设置 DebugFlags=BurstBuffer 以获取来自 burst buffer 插件的详细日志。这将导致非常详细的日志记录，并不适合在生产系统中长期使用，但这可能对调试有用。
  • TRES 限制可以通过关联或 QOS 配置 burst buffer，就像可以为节点、CPU 或任何 GRES 配置 TRES 限制一样。要使 Slurm 跟踪 burst buffer 资源，请在 slurm.conf 中将 bb/datawarp（对于 datawarp 插件）或 bb/lua（对于 lua 插件）添加到 AccountingStorageTres。
  • 作业的 burst buffer 需求大小可用作设置作业优先级的因素，如多因素优先级文档中所述。Burst Buffer 资源部分解释了这些资源是如何定义的。
  • 特定于 burst buffer 的配置可以在 burst_buffer.conf 中设置。配置设置包括可以使用 burst buffer 的用户、超时、burst buffer 脚本的路径等。有关更多信息，请参见burst_buffer.conf手册。
  • 必须安装 JSON-C 库才能构建 Slurm 的 burst_buffer/datawarp 和 burst_buffer/lua 插件，这些插件必须解析 JSON 格式数据。有关详细信息，请参见 Slurm 的JSON 安装信息。

Datawarp

slurm.conf:

BurstBufferType=burst_buffer/datawarp

datawarp 插件调用两个脚本：

  • dw_wlm_cli - Slurm burst_buffer/datawarp 插件调用此脚本以执行 burst buffer 功能。它应该由 Cray 提供。此脚本的位置由 burst_buffer.conf 中的 GetSysState 定义。此脚本的模板与 Slurm 一起提供：
    • src/plugins/burst_buffer/datawarp/dw_wlm_cli
  • dwstat - Slurm burst_buffer/datawarp 插件调用此脚本以获取状态信息。它应该由 Cray 提供。此脚本的位置由 burst_buffer.conf 中的 GetSysStatus 定义。此脚本的模板与 Slurm 一起提供：
    • src/plugins/burst_buffer/datawarp/dwstat

Lua

slurm.conf:

BurstBufferType=burst_buffer/lua

lua 插件调用一个名为 burst_buffer.lua 的脚本。此脚本需要存在于与 slurm.conf 相同的目录中。以下函数必须存在，尽管它们可能只返回成功：

  • slurm_bb_job_process
  • slurm_bb_pools
  • slurm_bb_job_teardown
  • slurm_bb_setup
  • slurm_bb_data_in
  • slurm_bb_test_data_in
  • slurm_bb_real_size
  • slurm_bb_paths
  • slurm_bb_pre_run
  • slurm_bb_post_run
  • slurm_bb_data_out
  • slurm_bb_test_data_out
  • slurm_bb_get_status

burst_buffer.lua 的模板与 Slurm 一起提供： etc/burst_buffer.lua.example

此模板记录了有关函数的更多详细信息，例如所需参数、每个函数调用的时间、每个函数的返回值以及一些简单示例。

Lua 实现

本节的目的是提供有关 Lua 插件的附加信息，以帮助希望实现 Lua API 的系统管理员。本节中最重要的要点是：

  • burst_buffer.lua 中的某些函数必须快速运行，无法被终止；其余函数可以运行所需的时间并可以被终止。
  • 为了避免超过系统限制，最多允许同时运行 512 个 burst_buffer.lua 的副本。

burst_buffer.lua 是如何运行的？

Lua 脚本可以通过 fork() 和 exec() 系统调用在单独的进程中运行，或者可以通过现有进程中的 Lua C API 被调用。lua 插件的目标之一是避免从 slurmctld 中调用 fork()，因为这会严重影响 slurmctld 的性能。datawarp 插件在每次 burst buffer API 调用时从 slurmctld 调用 fork() 和 exec()，这已被证明会严重损害 slurmctld 的性能。因此，slurmctld 使用 Lua 的 C API 调用 burst_buffer.lua，而不是使用 fork()。

burst_buffer.lua 中的某些函数可以运行较长时间，但如果作业被取消、slurmctld 被重新启动，或者如果它们运行超过 burst_buffer.conf 中配置的超时，则可能需要终止它们。然而，通过 Lua 的 C API 调用 Lua 脚本无法从同一进程中终止；只有终止调用 Lua 脚本的整个进程才能终止 Lua 脚本。

为了解决这种情况，burst_buffer.lua 以两种不同的方式调用：

  • slurm_bb_job_process、slurm_bb_pools 和 slurm_bb_paths 函数从 slurmctld 调用。由于上述解释，运行这些函数的脚本无法被终止。由于这些函数在 slurmctld 持有某些互斥锁时被调用，如果它们运行缓慢，将对 slurmctld 的性能和响应能力造成极大的损害。直接调用这些函数比调用 fork() 创建新进程更快，因此这被认为是一个可接受的权衡。因此，这些函数无法被终止。
  • burst_buffer.lua 中的其余函数可以运行更长时间而不会产生不良影响。这些函数需要能够被终止。这些函数由一个轻量级的 Slurm 守护进程 slurmscriptd 调用。每当需要运行这些函数之一时，slurmctld 会告诉 slurmscriptd 运行该函数；slurmscriptd 然后调用 fork() 创建一个新进程，然后调用适当的函数。这避免了从 slurmctld 调用 fork()，同时仍然提供了一种在需要时终止正在运行的 burst_buffer.lua 副本的方法。因此，这些函数可以被终止，如果它们运行超过在 burst_buffer.conf 中配置的适当超时值，它们将被终止。

每个函数的调用方式也在 burst_buffer.lua.example 文件中记录。

警告

请勿在 burst_buffer.lua 中安装信号处理程序，因为它是直接从 slurmctld 调用的。如果 slurmctld 收到信号，它可能会尝试在 burst_buffer.lua 完成调用后运行 burst_buffer.lua 中的信号处理程序，这会导致崩溃。

Burst Buffer 资源

bust buffer API 可以定义 burst buffer 资源“池”，作业可以请求一定量的池空间。如果池没有足够的空间来满足作业的请求，该作业将保持待处理状态，直到池有足够的空间。一旦池有足够的空间，Slurm 可以开始进行作业的阶段输入。当阶段输入开始时，Slurm 从池的可用空间中减去作业请求的空间。当拆除完成时，Slurm 将作业请求的空间重新添加到池的可用空间中。作业提交命令部分解释了作业如何请求池中的空间。池空间是一个标量量。

Datawarp

  • 池由 dw_wlm_cli 定义，表示字节。此脚本打印一个 JSON 格式的字符串，定义池并输出到标准输出。
  • 如果作业不请求池，则将使用 burst_buffer.conf 中定义的 DefaultPool 池。如果作业不请求池且未定义 DefaultPool，则作业将被拒绝。

Lua

  • 在此插件中，池是可选的，可以表示任何内容。
  • DefaultPool 在 burst_buffer.conf 中未在此插件中使用。
  • 池由 burst_buffer.lua 中的 slurm_bb_pools 函数定义。如果不需要池，则此函数应仅返回 slurm.SUCCESS。如果需要池，则此函数应返回两个值：（1）slurm.SUCCESS，以及（2）定义池的 JSON 格式字符串。burst_buffer.lua.example 中提供了一个示例。当前 JSON 字符串中的有效字段包括：
    • id - 定义池名称的字符串
    • quantity - 定义池中空间量的数字
    • granularity - 定义可以从此池中分配的空间的最低分辨率的数字。如果作业请求的数字不是 granularity 的倍数，则作业的请求将向上舍入到最接近的 granularity 的倍数。例如，如果 granularity 等于 1000，则单个作业从此池中分配的最小空间量为 1000。如果作业请求的单位少于 1000，则作业的请求将向上舍入到 1000。

作业提交命令

正常操作模式是批处理作业在批处理脚本中指定 burst buffer 需求。包含特定指令的注释批处理脚本行（取决于使用的插件）将通知 Slurm 应该为该作业运行 burst buffer 阶段。这些行还将描述作业的 burst buffer 需求。

salloc 和 srun 命令可以使用 --bb 和 --bbf 选项指定 burst buffer 需求。这在命令行作业选项部分中进行了描述。

所有 burst buffer 指令应在批处理脚本的顶部以注释形式指定。它们可以放置在任何 #SBATCH 指令之前、之后或交错。所有 burst buffer 阶段在作业生命周期的特定时刻发生，如概述部分所述；它们不会在作业执行期间发生。例如，所有持久性 burst buffer（仅由 datawarp 插件使用）创建和删除发生在作业的计算部分之前。以类似的方式，您不能在脚本执行的各个点运行阶段输入；burst buffer 阶段输入在作业开始之前执行，阶段输出在作业完成后执行。

对于两个插件，作业可以从 burst buffer 资源 池 请求一定量的空间（大小或容量）。

  • 池规范只是一个与池名称匹配的字符串。例如：pool=pool1
  • 容量规范是一个数字，表示从池中所需的空间量。容量规范可以包含后缀“N”（节点）、“K|KiB”、“M|MiB”、“G|GiB”、“T|TiB”、“P|PiB”（以 1024 为底的幂）和“KB”、“MB”、“GB”、“TB”、“PB”（以 1000 为底的幂）。注意：通常，Slurm 将 KB、MB、GB、TB、PB 单位解释为以 1024 为底的幂，但对于 Burst Buffers 大小规范，Slurm 支持 IEC/SI 格式。这是因为 CRAY API 支持这两种格式。

在作业提交时，Slurm 执行基本指令验证，并在 burst buffer 脚本中运行一个函数。该函数可以对作业脚本中使用的指令进行验证。如果 Slurm 确定选项无效，或者如果 burst buffer 脚本返回错误，则作业将被拒绝，并且错误消息将直接返回给用户。

请注意，为了支持向后兼容性，可能会忽略未识别的选项（即在某些版本的 Slurm 中识别的选项，但在其他版本中未识别的选项不会导致作业提交失败）。如果作业被接受，但后期失败（例如，某些文件阶段输入问题），作业将被挂起，其“原因”字段将设置为基础设施提供的错误消息。

用户还可以请求在 burst buffer 阶段输出完成时通过电子邮件通知，使用 --mail-type=stage_out 或 --mail-type=all 选项。电子邮件的主题行将是以下形式：

SLURM Job_id=12 Name=my_app Staged Out, StageOut time 00:05:07

以下插件子部分提供了特定于每个插件的附加信息，并提供示例作业脚本。命令行示例在命令行作业选项部分中给出。

Datawarp

指令 #DW（表示“DataWarp”）用于使用 burst_buffer/datawarp 插件时的 burst buffer 指令。有关 DataWarp 选项的详细信息，请参考 Cray 文档。对于 DataWarp 系统，可以使用指令 #BB 创建或删除持久性 burst buffer 存储。
注意：使用 #BB 指令，因为该命令由 Slurm 解释，而不是由 Cray Datawarp 软件解释。这在持久性 Burst Buffer部分中有更多讨论。

对于特定作业的 burst buffer，必须指定 burst buffer 容量。如果作业未指定 容量，则作业将被拒绝。作业还可以指定希望从中获取资源的池；如果作业未指定池，则将使用 burst_buffer.conf 中指定的 DefaultPool 池（如果已配置）。

以下作业脚本请求从默认池中获取 burst buffer 资源，并请求文件进行阶段输入和阶段输出：

#!/bin/bash
#DW jobdw type=scratch capacity=1GB access_mode=striped,private pfs=/scratch
#DW stage_in type=file source=/tmp/a destination=/ss/file1
#DW stage_out type=file destination=/tmp/b source=/ss/file1
srun application.sh

Lua

此插件的默认指令是 #BB_LUA。此插件使用的指令可以通过在 burst_buffer.conf 中设置 Directive 选项进行更改。由于指令必须始终以 # 符号开头（这在 shell 脚本中开始注释），因此此选项应仅指定 # 符号后面的字符串。例如，如果 burst_buffer.conf 包含以下内容：

Directive=BB_EXAMPLE

则 burst buffer 指令将是 #BB_EXAMPLE。

如果在 burst_buffer.conf 中未指定 Directive 选项，则将使用此插件的默认指令（#BB_LUA）。

由于此插件旨在通用和灵活，因此此插件只要求提供指令。如果提供了指令，Slurm 将为作业运行所有 burst buffer 阶段。

以下是运行所有 burst buffer 阶段所需的最少信息示例：

#!/bin/bash
#BB_LUA
srun application.sh

由于此插件的 burst buffer 池是可选的（请参见Burst Buffer 资源部分），作业不需要指定池或容量。如果 burst buffer API 提供了池，则作业可以请求池和容量：

#!/bin/bash
#BB_LUA pool=pool1 capacity=1K
srun application.sh

作业可以选择是否指定池。如果作业未指定池，则作业仍然可以运行，并且 burst buffer 阶段仍将为该作业运行（只要提供了 burst buffer 指令）。如果作业指定了池但未找到该池，则作业将被拒绝。

系统管理员可以在 burst_buffer.lua 中的 slurm_bb_job_process 函数中验证 burst buffer 选项。这可能包括要求作业指定池或验证系统管理员决定实施的任何其他选项。

持久性 Burst Buffer 创建和删除指令

本节仅适用于 datawarp 插件，因为其他 burst buffer 插件不使用持久性 burst buffer。

这些选项用于创建和删除持久性 burst buffer：

  • #BB create_persistent name=<name> capacity=<number> [access=<access>] [pool=<pool> [type=<type>]
  • #BB destroy_persistent name=<name> [hurry]

创建和删除持久性 burst buffer 的选项：

  • name - 持久性 burst buffer 名称不得以数字值开头（数字名称保留给特定作业的 burst buffer）。
  • capacity - 在作业提交命令部分中描述。
  • pool - 在作业提交命令部分中描述。
  • access - 访问参数标识缓冲区访问模式。datawarp 插件支持的访问模式包括：
    • striped
    • private
    • ldbalance
  • type - 类型参数标识缓冲区类型。datawarp 插件支持的类型模式包括：
    • cache
    • scratch

可以在单个作业中创建或删除多个持久性 burst buffer。

示例 - 创建两个持久性 burst buffer：

#!/bin/bash
#BB create_persistent name=alpha capacity=32GB access=striped type=scratch
#BB create_persistent name=beta capacity=16GB access=striped type=scratch
srun application.sh

示例 - 销毁两个持久性 burst buffer：

#!/bin/bash
#BB destroy_persistent name=alpha
#BB destroy_persistent name=beta
srun application.sh

持久性 burst buffer 可以通过不需要计算资源的作业创建和删除。提交一个带有所需 burst buffer 指令的作业，并指定节点数为零（例如 sbatch -N0 setup_buffers.bash）。尝试提交没有 burst buffer 指令或具有作业特定 burst buffer 指令的零大小作业将生成错误。请注意，零大小作业不支持作业数组或异构作业分配。

注意：创建和销毁持久性 burst buffer 的能力可能会受到 burst_buffer.conf 文件中 Flags 选项的限制。有关更多信息，请参见burst_buffer.conf手册。默认情况下，只有特权用户（即 Slurm 操作员和管理员）可以创建或销毁持久性 burst buffer。

异构作业支持

异构作业可以请求 burst buffer。每个具有 burst buffer 指令的组件将运行一次 burst buffer 钩子。例如，如果一个异构作业有三个组件，其中两个具有 burst buffer 指令，则 burst buffer 钩子将为每个具有 burst buffer 指令的两个组件运行，但不会为没有 burst buffer 指令的第三个组件运行。有关更多信息和示例，请参见异构作业页面。

命令行作业选项

除了在批处理脚本中放置 burst buffer 指令外，命令行选项 --bb 和 --bbf 也可以包含 burst buffer 指令。这些命令行选项适用于 salloc、sbatch 和 srun。请注意，--bb 选项无法创建或销毁持久性 burst buffer。

--bbf 选项将文件名作为参数，该文件应包含与批处理作业中使用的 burst buffer 操作集合相同的内容。

或者，可以使用 --bb 选项将 burst buffer 指令指定为选项参数。此选项的行为取决于使用的 burst buffer 插件。当使用 --bb 选项时，Slurm 解析此选项并创建一个临时的 burst buffer 脚本文件，该文件在 burst buffer 插件内部使用。

Datawarp

使用 --bb 选项时，指令的格式可以与批处理脚本中使用的格式相同，或者可以使用一组非常有限的选项，这些选项被转换为后续处理的等效脚本。允许使用以下选项：

  • access=&ltaccess>
  • capacity=&ltnumber>
  • swap=&ltnumber>
  • type=&lttype>
  • pool=&ltname>

多个选项应以空格分隔。如果指定了 swap 选项，则作业还必须指定所需的节点数。

示例：

# 示例执行行：
srun --bb="capacity=1G access=striped type=scratch" a.out

# 由 Slurm 的 burst_buffer/datawarp 插件生成的等效脚本
#DW jobdw capacity=1GiB access_mode=striped type=scratch

Lua

此插件不会对通过 --bb 选项给出的 burst buffer 指令进行任何特殊解析或转换。当使用 --bb 选项时，格式与批处理脚本相同：Slurm 仅强制要求指定 burst buffer 指令。有关更多信息，请参见作业提交命令中的 Lua 子部分。

示例：

# 示例执行行：
srun --bb="#BB_LUA pool=pool1 capacity=1K"

# 由 Slurm 的 burst_buffer/lua 插件生成的等效脚本
#BB_LUA pool=pool1 capacity=1K

符号替换

Slurm 支持许多符号，可用于自动填充某些作业详细信息，例如使阶段输入或阶段输出目录路径在每次作业提交时变化。

支持的符号包括：

%%%
%A数组主作业 ID
%a数组任务 ID
%d工作目录
%j作业 ID
%u用户名
%x作业名称
\\停止进一步处理该行

状态命令

Slurm 跟踪的 burst buffer 信息可以通过使用 scontrol show burst 命令或使用 sview 命令的 Burst Buffer 选项卡获得。以下是示例。

datawarp 插件示例：

$ scontrol show burst
Name=datawarp DefaultPool=wlm_pool Granularity=200GiB TotalSpace=5800GiB FreeSpace=4600GiB UsedSpace=1600GiB
  Flags=EmulateCray
  StageInTimeout=86400 StageOutTimeout=86400 ValidateTimeout=5 OtherTimeout=300
  GetSysState=/home/marshall/slurm/master/install/c1/sbin/dw_wlm_cli
  GetSysStatus=/home/marshall/slurm/master/install/c1/sbin/dwstat
  Allocated Buffers:
    JobID=169509 CreateTime=2021-08-11T10:19:06 Pool=wlm_pool Size=1200GiB State=allocated UserID=marshall(1017)
    JobID=169508 CreateTime=2021-08-11T10:18:46 Pool=wlm_pool Size=400GiB State=staged-in UserID=marshall(1017)
  Per User Buffer Use:
    UserID=marshall(1017) Used=1600GiB

Lua 插件示例：

$ scontrol show burst
Name=lua DefaultPool=(null) Granularity=1 TotalSpace=0 FreeSpace=0 UsedSpace=0
  PoolName[0]=pool1 Granularity=1KiB TotalSpace=10000KiB FreeSpace=9750KiB UsedSpace=250KiB
  PoolName[1]=pool2 Granularity=2 TotalSpace=10 FreeSpace=10 UsedSpace=0
  PoolName[2]=pool3 Granularity=1 TotalSpace=4 FreeSpace=4 UsedSpace=0
  PoolName[3]=pool4 Granularity=1 TotalSpace=5GB FreeSpace=4GB UsedSpace=1GB
  Flags=DisablePersistent
  StageInTimeout=86400 StageOutTimeout=86400 ValidateTimeout=5 OtherTimeout=300
  GetSysState=(null)
  GetSysStatus=(null)
  Allocated Buffers:
    JobID=169504 CreateTime=2021-08-11T10:13:38 Pool=pool1 Size=250KiB State=allocated UserID=marshall(1017)
    JobID=169502 CreateTime=2021-08-11T10:12:06 Pool=pool4 Size=1GB State=allocated UserID=marshall(1017)
  Per User Buffer Use:
    UserID=marshall(1017) Used=1000256KB

通过 scontrol 使用 scontrol show bbstat ... 或 scontrol show dwstat ... 命令可以访问 burst buffer 状态 API。跟随 bbstat 或 dwstat 的选项直接传递给 bbstat 或 dwstat 命令，如下所示。在 datawarp 插件中，此命令调用 Cray 的 dwstat 脚本。有关 dwstat 选项和输出的详细信息，请参见 Cray Datawarp 文档。在 lua 插件中，此命令调用 burst_buffer.lua 中的 slurm_bb_get_status 函数。

datawarp 插件示例：

/opt/cray/dws/default/bin/dwstat
$ scontrol show dwstat
    pool units quantity    free gran'
wlm_pool bytes  7.28TiB 7.28TiB 1GiB'

$ scontrol show dwstat sessions
 sess state      token creator owner             created expiration nodes
  832 CA---  783000000  tester 12345 2015-09-08T16:20:36      never    20
  833 CA---  784100000  tester 12345 2015-09-08T16:21:36      never     1
  903 D---- 1875700000  tester 12345 2015-09-08T17:26:05      never     0

$ scontrol show dwstat configurations
 conf state inst    type access_type activs
  715 CA---  753 scratch      stripe      1
  716 CA---  754 scratch      stripe      1
  759 D--T-  807 scratch      stripe      0
  760 CA---  808 scratch      stripe      1

Lua 插件示例可以在提供的 etc/burst_buffer.lua.example 文件中的 slurm_bb_get_status 函数中找到。

高级预留

Burst buffer 资源可以使用 BurstBuffer 选项放置在高级预留中。参数由四个元素组成：
[plugin:][pool:]#[units]

  • plugin 是 burst buffer 插件名称，目前为“datawarp”或“lua”。
  • pool 指定 burst buffer 资源池。如果未指定“类型”，则数字是存储空间的度量。
  • #（表示数字）应替换为正整数。
  • units 的格式与作业提交命令部分中容量的后缀相同。

    • 使用此预留的作业不受这些 burst buffer 资源的限制，但可以使用这些保留的资源以及任何通常可用的资源。以下是一些示例。

    $ scontrol create reservation starttime=now duration=60 \
  users=alan flags=any_nodes \
  burstbuffer=datawarp:100G

$ scontrol create reservation StartTime=noon duration=60 \
  users=brenda NodeCnt=8 \
  BurstBuffer=datawarp:20G

$ scontrol create reservation StartTime=16:00 duration=60 \
  users=joseph flags=any_nodes \
  BurstBuffer=datawarp:pool_test:4G

    作业依赖关系

    如果两个作业使用 burst buffer，并且一个作业依赖于另一个作业（例如 sbatch --dependency=afterok:123 ...），则第二个作业将在第一个作业完成及其 burst buffer 阶段输出完成之前不会开始。如果第二个作业不使用 burst buffer，但依赖于第一个作业的完成，则它将不会等待第一个作业的阶段输出操作完成。可以使用“afterburstbuffer”依赖选项使第二个作业等待第一个作业的阶段输出操作完成（例如 sbatch --dependency=afterburstbuffer:123 ...）。

    Burst Buffer 状态和作业状态

    这些是不同的可能的 burst buffer 状态：

    • pending
    • allocating
    • allocated
    • deleting
    • deleted
    • staging-in
    • staged-in
    • pre-run
    • alloc-revoke
    • running
    • suspended
    • post-run
    • staging-out
    • teardown
    • teardown-fail
    • complete

    这些状态出现在scontrol show job的输出中的“BurstBufferState”字段。该字段仅出现在请求了突发缓冲区的作业中。状态allocating、allocated、deleting和deleted仅用于持久性突发缓冲区（不适用于特定作业的突发缓冲区）。如果在Slurm为作业分配资源和实际启动作业之间发生Slurm的选择插件故障，则会发生状态alloc-revoke。这种情况不应该发生。

    当作业请求突发缓冲区时，作业和突发缓冲区状态转换如下：

    1. 作业被提交。作业状态和突发缓冲区状态均为pending。
    2. 突发缓冲区阶段开始。作业状态：pending，原因： BurstBufferStageIn。突发缓冲区状态：staging-in。
    3. 当阶段完成时，作业有资格被调度（不考虑其他限制）。作业状态：pending。突发缓冲区状态： staged-in。
    4. 当作业被调度并分配资源时，突发缓冲区的预运行阶段开始。作业状态：running+configuring。突发缓冲区状态： pre-run。
    5. 当预运行完成时，configuring标志从作业中清除，作业可以实际开始运行。作业状态和突发缓冲区状态均为running。
    6. 当作业完成（即使失败）时，突发缓冲区阶段开始。作业状态：stage-out。突发缓冲区状态： staging-out。
    7. 当阶段完成时，开始清理。作业状态：complete。突发缓冲区状态：teardown。

    有一些情况会改变状态转换。示例包括：

    • 突发缓冲区操作失败：
      • 如果清理失败，则突发缓冲区状态更改为teardown-fail。将重试清理。对于burst_buffer/lua插件，清理最多将运行3次，然后放弃并销毁突发缓冲区。
      • 如果阶段或阶段失败，并且在burst_buffer.conf中配置了Flags=teardownFailure，则将运行清理。否则，作业将被挂起，突发缓冲区保持在同一状态，以便可以检查并手动销毁，使用scancel --hurry。
      • 如果预运行失败，则作业将被挂起并运行清理。
    • 当作业被取消时，当前作业的突发缓冲区脚本（如果正在运行）将被终止。如果使用了scancel --hurry，或者如果作业从未运行，则跳过阶段，直接进入清理。否则，开始阶段。
    • 如果slurmctld停止，Slurm将终止所有作业的运行中的突发缓冲区脚本，并为每个作业保存突发缓冲区状态。当slurmctld重新启动时，对于每个作业，它读取突发缓冲区状态并执行以下操作之一：
      • Pending - 不执行任何操作，因为没有突发缓冲区脚本被终止。
      • Staging-in, staged-in - 运行清理，等待一段时间，然后重新启动阶段。
      • Pre-run - 重新启动预运行。
      • Running - 不执行任何操作，因为没有突发缓冲区脚本被终止。
      • Post-run, staging-out - 重新启动后运行。
      • Teardown, teardown-fail - 重新启动清理。

    注意：这里列出了许多其他影响作业状态的因素。本文档专注于突发缓冲区，并未尝试解决所有可能的作业状态转换。

    最后修改于2023年8月21日