SLURM资源与作业管理系统的能源核算与控制

### SLURM资源与作业管理系统的能源核算与控制 在高性能计算（HPC）领域，能源消耗一直是一个备受关注的问题。有效的能源管理不仅可以降低成本，还能提高系统的可持续性。本文将介绍如何使用SLURM资源与作业管理系统进行能源核算与控制，包括能源数据的收集、分析以及如何通过CPU频率缩放来控制能源消耗。 #### 现有能源监测与调度系统 在介绍SLURM之前，先了解一些早期的能源监测与调度系统。LoadLeveler是一款专有软件，它似乎是最早提供电源和能源监测以及基于系统根据预测模型自动设置CPU频率的能源感知调度的软件之一。在LRZ的SuperMUC超级计算机上就使用了具有这些能源感知功能的LoadLeveler。此外，Hennecke等人通过一个名为LLview的特定LoadLeveler工具，从IBM Blue Gene/P超级计算机中检索功耗数据。LLview能够以高精度（每秒约4个样本）提供每个作业的功耗数据，但该工具是闭源的，并且是专门为BlueGene/P平台开发的。 在较新的微处理器中，常见的机制是动态电压频率调整（DVFS），即动态调整频率和电压。降低CPU频率可能会导致能源消耗的减少。利用DVFS技术的各种策略已被广泛研究，以改善MPI应用程序的能源消耗。其他研究表明，自适应使用频率缩放可能会在性能损失较小的情况下带来显著的能源效益。通过CPU频率缩放来控制能源消耗作为一种用户功能，最初是在OAR（另一个用于HPC集群的灵活资源和作业管理系统）上进行研究和实现的。 #### SLURM中的能源消耗检索与控制集成 SLURM有一个特定的插件，用于在作业执行期间收集每个节点的各种资源使用信息。这个名为jobacct gather的插件会收集诸如每个节点上所有任务的CPU和内存利用率等信息，然后在所有节点内部进行汇总，并返回每个作业的单个最大值和平均值。 ##### SLURM监控框架架构 SLURM的监控机制架构涉及多个守护进程、进程和子线程，它们部署在集群的不同组件上。在SLURM架构中，一个作业可能由多个并行的子作业（称为步骤）组成。作业通常通过sbatch命令以bash脚本的形式提交，脚本中可能包含多次调用SLURM的srun命令来启动应用程序（子作业）。 当一个作业启动时，srun命令将在作业分配的第一个节点上被调用，而slurmd守护进程将在每个节点上启动一个slurmstepd进程，该进程将跟踪整个步骤的执行。如果激活了基本监控模式，jobacct gather插件将被调用，slurmstepd进程将在每个节点上启动一个线程，在执行期间监控各种资源（如CPU、内存等）。资源利用率的轮询是通过Linux伪文件系统/proc/完成的，该系统是一个内核数据结构接口，提供节点上各种资源的统计信息。采样频率由用户在作业提交时指定。各种统计信息在执行期间保存在数据结构中，作业完成后，所有节点上的汇总值（如平均值、最大值等）将存储在数据库中。数据通过内部远程过程调用（RPC）在线程和进程之间移动，以确保机制的可靠性和效率。用户可以在作业执行期间通过SLURM命令sstat检索这些信息，在作业终止后通过sacct检索。 新的监控模式将遵循相同的设计架构，为每个监控模式使用单独的插件，并启动新线程，使其轮询与基本监控模式异步。 ```mermaid graph TD classDef process fill:#E5F6FF,stroke:#73A6FF,stroke-width:2px; classDef database fill:#FFF6CC,stroke:#FFBC52,stroke-width:2px; classDef client fill:#FFEBEB,stroke:#E68994,stroke-width:2px; classDef hardware fill:#E5F6FF,stroke:#73A6FF,stroke-width:2px; A(slurmctld):::process --> B(slurmd):::process A --> C(slurmd):::process A --> D(slurmd):::process A --> ...(...):::process B --> E(slurmstepd):::process C --> F(slurmstepd):::process D --> G(slurmstepd):::process ... --> H(slurmstepd):::process I(srun):::process --> E J(salloc):::process --> E K(sbatch):::process --> E L(slurmdbd):::database --> A M(Client):::client --> A N(Cluster Hardware):::hardware --> B N --> C N --> D N --> ... E --> O(jobacct gather):::process F --> O G --> O H --> O O --> P(Acct_gather_Energy IPMI):::process O --> Q(Acct_gather_Energy RAPL):::process O --> R(Acct_gather_Profile HDF5):::process P --> S(sstat):::process P --> T(scontrol):::process P --> U(sacct):::process Q --> S Q --> T Q --> U R --> S R --> T R --> U ``` ##### 通过IPMI接口收集功率数据 有多种开源软件支持IPMI协议，并能从基板管理控制器（BMC）检索功率数据，如Ipmitool、OpenIPMI等。我们选择了freeipmi，原因在于它专门用于HPC，不需要内核模块，并且提供了易于集成的API。 IPMI和RAPL检索的一个重要区别在于调用的持续时间。IPMI调用通常需要4ms到80ms，但有时可能需要2到3秒以上。因此，需要将收集过程与其他资源跟踪和作业执行控制异步进行，所以需要一个单独的线程来处理IPMI调用。此外，我们不仅希望在作业执行期间从jobacct线程与该线程通信，还希望从slurmd获取节点的功耗信息，以便获取系统信息。 因此，选择从slurmd启动IPMI轮询线程。IPMI收集的是功率（瓦），而我们感兴趣的是计算作业的能源消耗。因此，需要使用特定的算法来计算每个节点的能源消耗，然后汇总所有分配节点的能源消耗，以获得作业的能源消耗。采样频率由管理员为每个节点定义的特定选项固定。线程内的睡眠函数允许根据这个频率dt来累加能源消耗。 假设tn是一个轮询时间，那么下一个轮询时间将是tn + 1 = tn + dt。时间使用C函数”time(NULL)”计算，单位为秒。因此，tn + 1 - tn的差值将在dt - 1、dt、dt + 1之间，且始终以秒为单位。假设上述时间对应的功率值分别为wn和wn + 1，则每个节点在tn和tn + 1之间的能源消耗dEn可以通过以下公式计算： \[dE_n = (t_{n + 1}