10-16 周一 Scientific Software Management in Real Life: Deployment of EasyBuild on a Large Scale Syste

10-16 周一 Scientific Software Management in Real Life: Deployment of EasyBuild on a Large Scale System 论文阅读

时间	版本	修改人	描述
2023年10月16日10:46:53	V0.1	宋全恒	新建文档
2023年10月20日15:01:52	V1.0	宋全恒	了解2016 EasyBuild在JURECA系统上的实践

引言

摘要

问题

• 管理科学软件栈手动任务，需要大规模团队，并且还需要特定领域细节知识。
• 扁平的flat module view手动创建module file的问题
• OS 镜像需要包含辅助包来支持软件栈的组成，潜在的使得计算节点膨胀，并限制了软件的安装

解决

EasyBuild: in a structured way 管理大量的科学软件包

简介

问题

 第一段说的是HPC软件管理现状，系统管理员很累。

 第二段写的手动任务，软件包数量越多，团队规模越大，但是人力资源有限，有许多的辅助软件包：

• 通用编程需要
  • Subversion
  • git
  • CMake
• 为了支持科学软件站的组成
  • 可视化库
  • 额外的Python模块

这种方式不仅使集群节点的OS镜像臃肿，而且将缺失软件的安装限制在指定的维护窗口内。

This approach not only bloats the OS images of the cluster nodes, but also restricts the installation of missing software to a designated maintenance window.

 第三段已安装软件被暴露给用户的方式。传统的"flat"的模型试图导致无结构和混淆的module视图。层级方式

无论如何，手工创建一致的模块文件并进行维护是繁琐且容易出错的。

In any case, creating consistent module files and maintaining them manually is tedious and error-prone.

工具

第四段

 出现了许多的工具来帮助系统管理员管理科学软件栈。

• 软件栈的安装
• 自动创建关联的module文件。

但是，这些软件还缺少一些特征，因此必须金华适应新的环境和约束。

第五段

 我们提出来一种方式即 EasyBuild + LMod。

• 几个关键的特征。
• 如何管理安装、更新、遗弃
• 这个方法如何在其他的内部系统中进行重用，并且会遇到那些阻碍。
• 如何进一步的发展来满足更佳的用户和管理员体验。

第六段

论文组织结构。

 第二部分，概览被JURECA系统以及我们的用户社区的施加的要求。

 第三部分，如何向用户呈现软件，为什么选择LMod

 第四部分，为什么选择Easybuild，如何实现需要的功能的。

 第五部分，详细介绍了JURECA上的当前状态、用户视图以及与上游的分歧。生命周期策略。

 第六部分，如何重用软件管理方法在其他的内部集群系统。

 第七部分，展示计划的未来改进。

 第八部分，结论

系统细节和要求

第一段-细节

 第一段描述JURECA集群的细节。描述了计算节点的配置，内存层级，GPU设备，和网络结构(fat-tree).

第二段-异构

 第二段描述系统的异构性也需要复杂的软件环境。

 X86 CPU设备需要Intel和GCC编译器。

 GPU加速器需要CUDA和PGI编译器。

 编译器-Compilers

• Intel
• GCC
• PGI编译器

第三段-MPI

 平台支持多种MPI。

• ParaStationMPI
• MVAPICH@-GDR
• Intel MPI

第四段-工具链

To ensure a consistent software stack and to avoid subtle, hard-to-diagnose errors, one can define toolchains consisting of a particular compiler coupled with a specific MPI implementation, and require that each software package is available within each toolchain.

为了保证软件栈的一致性，避免细微的、难以诊断的错误，可以定义由特定编译器和特定MPI实现组成的工具链，并要求每个软件包在每个工具链中可用。

第五段-杂乱无章

One can easily see how this quickly leads to a very large number of environment modules which gets increasingly cluttered as new versions of software packages become available

人们可以很容易地看到，随着新版本的软件包的出现，这会导致大量的环境模块变得越来越杂乱无章。

设计用户视图

为我们提供的科学软件的最终用户提供一个直观的视角是我们的主要目标

 模块层级

Through the use of a module hierarchy one can restrict the user view to purely the consistent stack

通过使用模块层次结构，可以将用户视图限制为纯粹的一致堆栈，这是选择LMod的原因。

Module 层级

一个模块层次结构，用户必须首先选择一个编译器，然后选择一个MPI实现，以便使用此编译器/ MPI组合构建的所有软件在其可用的环境模块视图中可见

 相对于传统的module的扁平组织的好处如下：

• 方便选择兼容的软件module
• 用户可用modules的概览显著减少。
• 可以清楚的看到提供MPI功能的软件和相反软件的划分。

提供MPI功能的软件和不提供MPI功能的软件之间存在明显的分离；这些信息可以用来确定软件在什么情况下可以使用。

Lmod作为Modules工具

第一段-Tcl-based modules

缺少重要的特征

第二段-Lmod

 选择使用Lmod的原因

• Lmod提供了已有模块的缓存，极大提升系统的响应性。
• module spider
• 支持隐藏module文件: 仅仅作为依赖加载的modules。 (--show-hidden) to the module avail
• 支持定义module families.

这些特性为Lmod提供了对模块层次结构的良好支持；事实上，它是从基础上发展起来的，在头脑中具有模块层次结构。

These features give Lmod excellent support for module hierarchies; in fact, it was developed from the ground up with module hierarchies in mind.

EasyBuild来安装科学软件

 HPC系统上安装科学软件的工具出现。

These features give Lmod excellent support for module hierarchies; in fact, it was developed from the ground up with module hierarchies in mind.

这些目的是减轻系统管理员和支持团队的负担，维护一个符合用户需求和期望的科学软件栈。

 EasyBuild能够

• 安装软件栈
• 生成相应的层级module方案

动机

 各种各样的软件

• SWTools
• Smithy
• maali
• Spack
• EasyBuild

 选择EasyBuild的原因

• EasyBuild is intended exactly for our use case, i.e., efficiently maintaining a software stack for end users on a modern HPC system.EasyBuild正是针对我们的用例，即在现代HPC系统上为最终用户高效地维护一个软件栈。

  In contrast, Spack for example is more targeted towards developers of large scientific software applications, as illustrated by several of its main features including a very flexible and powerful way of dealing with dependencies.

  相比之下，Spack更多的是针对大型科学软件应用程序的开发人员，它的几个主要特点包括非常灵活和强大的处理依赖关系的方式。

• 从2012年就用于生产环境。

• EasyBuild可以根据站点策略进行灵活的配置，包括软件安装前缀，到module命名方案。

• EasyBuild包括对Lmod和模块层次结构的广泛支持，包括以Lua语法生成模块文件，而不是其他工具。

• EasyBuild得到了积极的维护，并得到了支持和欢迎的社区的支持。

• EasyBuild包含了超过1000个不同软件包的食谱( “易配置文件”)，明显多于其他任何一个工具。

 上述的方面组成了令人心腹的结论。

缺点

 JURECA复杂的用例和庞大的社区快速地要求数百个软件包安装上每一个所使用的工具链，许多问题变得显而易见：

• 9个工具链提供CMake
• 支持可视化软件（visualization software）需要在我们的EasyBuild安装中集成X11库，将默认模块视图中的科学应用程序与这些库及其依赖关系结合起来
• Some visualization libraries do not build with anything other than the GCC compiler, making the visualization libraries unavailable in toolchains that include other compilers.一些可视化库不与GCC编译器以外的任何其他编译器一起构建，使得可视化库在包含其他编译器的工具链中不可用。
• 暴露所使用的工具链的隐秘名称导致了混乱和支持问题。

 这些问题导致了许多的要求，为了维持一致的用户试图，这些试图被限制到相关的科学和开发包。

用户驱动的增强

通过EasyBuild维护模块层次结构的支持，使我们能够更好地组织模块堆栈，以一种完全自动化的方式

The support for maintaining a module hierarchy through EasyBuild allowed us to organize the module stack better than before, in a fully automated way

隐藏模块支持

A hidden module essentially can be created by prefixing the module file name with a dot (‘.’), just like any other hidden file in a Unix-based operating system.

隐藏模块本质上可以像基于Unix的操作系统中的任何其他隐藏文件一样，通过在模块文件名前加上点( ')来创建。

 指定隐藏模块的四种方式：

• 命令行选项 --hidden
• hidden easyconfig参数
• ‘EASYBUILD_HIDE_DEPS’环境变量
• ‘EASYBUILD_HIDE_TOOLCHAINS’

Toolchains通用基础编译器

第二个问题是，特别是可视化包需要有一个底层的GCC编译器，该编译器可以跨所有工具链构建和提供这些包。

GCCcore概念的发展。

This lead to the development of the GCCcore concept within EasyBuild, which essentially acts as a replacement for the system GCC compiler and also allows us to exercise control over which binutils installation is used for all software installations.

这导致了EasyBuild中GCCcore概念的发展，它本质上充当了系统GCC编译器的替代者，也允许我们对所有软件安装使用的binutils安装进行控制。

增强依赖解决

The dependency resolution mechanism implemented by EasyBuild was rather straightforward: usually, the toolchain that was employed to build and install a particular software package was simply inherited by the dependencies as well, even though they may not require some of the functionality that was provided by that toolchain (for example MPI support, BLAS/LAPACK libraries, etc.).

EasyBuild实现的依赖项解析机制非常简单：通常，用于构建和安装特定软件包的工具链也由依赖项简单继承，尽管它们可能不需要该工具链(例如MPI支持、BLAS / LAPACK库等。)提供的某些功能。

 为了缓解这种情况，增强了依赖项解析机制，以同时考虑所谓的子工具链的整个层次结构，其中，"完整"工具链(同时提供BLAS / LAPACK / FFTW功能)的仅编译器和仅编译器+ MPI的子集首先被认为是依赖项，而不是直接从"父"软件继承工具链。

 最小化toolchains概念

This concept of minimal toolchains opens the door to a much more intuitive module hierarchy: global tools and libraries can be moved to GCCcore, software that requires a specific compiler (typically for performance reasons, such as Python) can sit at the Compiler level of the hierarchy, with all other applications sitting at the MPI level of the hierarchy

这个最小工具链的概念打开了一个更直观的模块层次结构的大门：全局工具和库可以移动到GCCcore，需要特定编译器的软件(通常是出于性能的考虑,比如Python)可以位于层次结构的Compiler层，所有其他应用程序都位于层次结构的MPI层。

 --minimal-toolchains

自定义模块命名方案

 默认EasyBuild包含

• 扁平
• 分层命名方案

安装目录独立于模块命名方案

 --module-only: 允许对同一软件栈支持多个并行命名方案

With the introduction of the custom module naming scheme, there was also a realization that the installation directories of software should be unique and independent of the naming scheme employed

性能提升

 在某些情况下，当使用层次模块命名方案( HMNS )和具有复杂依赖树的软件包时，依赖解析所花费的时间为几分钟。造成这种放缓的原因有两方面：

1. Modules Tool是一个在多个实例之前为单例的类，需要多次实例化才能支持HMNS设置中来自多个工具链的安装包
2. 大量的模块显示和模块使用调用，在使用最小的工具链时特别昂贵。

解决了这两个问题，通过将ModulesTool实例的数量最小化为easyconfig文件的数量加1，并通过缓存模块显示和模块可用性的输出，获得了高达10倍的加速比

Refactoring of Support for MPICH-based MPI Libraries基于Mpich的MPI库支持的重构

 MPIC是最成功的MPI实现中的一个，有多个商业[Intel MPI, Cray MPI, IBM MPI]和免费开源(ParaStation MPI, MVAPICH)的派生物。

 通常，基于Configuration & & make的软件使用$CFLAGS, $LDFLAGS和相关的环境变量来确定编译过程中使用的编译器和链接器标志位

 “However, during the configuration step, MPICH takes these flags and transparently adds them to its MPI compiler wrappers [21]. Since EasyBuild sets these variables, this is not the desired behavior at installation time, and forces a change in the internal behavior of EasyBuild to unset these flags and export another set of variables to achieve the intended behavior.” (Alvarez 等, 2016, p. 35)

然而，在配置步骤中，MPICH采用这些标志并透明地将它们添加到其MPI编译器包装器中[ 21 ]。由于EasyBuild设置了这些变量，这在安装时间并不是想要的行为，并迫使EasyBuild内部行为的改变来取消设置这些标志，并导出另一组变量来实现预定的行为。

JURECA当前状态

 In this section we describe how our current setup looks like, as a result of these requirements, capabilities, and improvements.

 在这一部分中，我们描述了由于这些要求、能力和改进，我们目前的设置是如何看起来的。

Toolchains

 15个toolchain定义

• 编译器： GCC、Intel、PGI
• MPI运行时： ParaStationMPI， Intel MPI 和 MVAPICH2
• 数学库： MKL OLF

 为了与OS包解耦，有两个隔离层：

• dummy toolchain, 软件直接安装在OS上
• GCCCore

 不兼容，施加了一些限制在安装结构上：

• The installed versions of Intel, PGI and CUDA compilers do not support GCC 5 underneath. This forces us to have a GCCcore for version 4.9.3 and another one for version 5.3.0, if we want to provide the latest GCC to our users
• CUDA 7.5 does not support Intel 2016 compilers. That creates the need for another compiler-level toolchain, as Intel 2016.2 cannot be used together with CUDA

隐藏的Modules和用户视图

 可视模块主要有两类：( 1 )编译器；( 2 )安装在虚拟环境中的二进制工具

 With the selection of compiler and MPI a user has all the software available for that part of the tree

 通过编译器和MPI的选择，用户拥有该部分树的所有可用软件

 这些隐藏包绝大多数是安装在GCCcore级别的帮助者库和工具。

Bundling Extensions

 一些流行的脚本语言是高度模块化的。

• Python
• Perl
• R

它们都有共同的思想，都有中央仓库，持有大量的包，这些包易于访问和安装。

 有两个Python module在编译器级别，

• 2.7.11 有30个扩展
• 3.5.1 有24个扩展。

在HPC中，numpy和scipy是非常常用的Python包。它们与matplotlib、iPython等软件包一起构成了所谓的SciPy堆栈

In HPC, numpy and scipy are Python packages which are very commonly used. Together with matplotlib, iPython and other packages, they conform the so-called SciPy stack

发现软件

 The use of a hierarchical module naming scheme, hidden modules and bundles sometimes causes false negatives, when an unfamiliar user tries to find software in JURECA

 当一个不熟悉的用户试图在JURECA中查找软件时，使用分层的模块命名方案、隐藏模块和包有时会导致负面效应。

 module avail.

 --show-hidden 选项。

 module spider 寻找module tree， 并展示三种不同信息:

• 匹配查询的module描述
• 如果没有特定版本查询，显示安装了那些版本。
• 当查询特定版本，那些特定的module启用预期版本的加载。

 module key

更新和弃用软件安装

 JURECA的预期寿命大致为5年。在这段时间内，人们可以期望每隔几个月对编译器进行更新，并随着最新标准的集成对MPI实现进行更新。这将意味着整个软件栈将需要频繁的升级。在这样的升级过程中，人们很自然地期望安装任何特定软件包的最新版本。

 The project cycle for JURECA lasts 12 months with two cycles per year.

 JURECA的项目周期为12个月，每年两个周期。

确保一致性和质量

 为了确保一致性和质量标准，在生产阶段只允许极少数人(通常为12人)使用专用账户安装软件。

 修改权限，并且开发了一个定制的module正确设置必要的环境变量。分为两个阶段，development stage和production stage。

来自上游EasyBuild的分歧

 JURECA中使用的安装程序的部署并不简单，因为目前使用的大多数easyconfig文件都没有包括在上游。有两个原因：

• 我们在开发时候提供了最新可用版本。
• 由于我们默认使用最小工具链，我们将大量的包从顶层工具链切换到它们在层次结构中的正确位置。

 虽然这是一项繁琐的任务，需要大量的人工检查，但事实是安装在JURECA中的easyconfigs与上游的easyconfigs之间的差异通常很小。

 工具链的更改需要手动调整，因为确定最优包装位置( base、编译器、MPI或顶层)的启发式方法并不简单。

 上游指的是EasyBuild的仓库。EasyConifg变化，和EasyBlock的变化。

移植到其他集群

 本章描述当相同的设置移植到其他集群时出现的问题

• JUROPA3， 672个核心
• JUAMS 1960个核心

 处理器尽管都是x86_64,但是来自不同的代数。当使用AVX指令时，导致了二进制的不兼容性。操作系统在JURECA是Centos7.2， JUAMES和JUROPS3是Centos 6.7。

 部分节点具有特殊的( JUROPA3拥有额外的至强融核节点和NVIDIA K20X GPU ,而JURECA拥有配备NVIDIA K80 GPU的节点)特性。

These issues required the creation of extra easyconfigs to supply the missing software, to adapt dependencies and/or to fix existing easyconfigs

这些问题需要创建额外的easyconfig来提供缺失的软件、调整依赖关系和/或修复现有的easyconfig

未来的工作

 调整数百个easyconfig文件以更改某些依赖项的版本，或它们自己的版本，是一项容易出错且耗时的任务
 未来，我们旨在自动处理这些任务，通过实现两个额外的特征：

• 依赖版本的自动更新。这会使得EasyBuild能够已经安装的依赖，而不管在easyconfig中指定的特定版本，并且通过自动更新所有的easyconfigs来节省时间，这些easyconfigs依赖于一个更新的库。
• 软件版本的自动更新。这会使得EasyBuild能够自动爬取源URLS，发现新的软件版本，并尽力编译。

动态链接库

 使用动态连接库，$LD_LIBRARY_PATH会导致很长的字符串，并且可能回到意想不到的问题。

minimal toolchain

 使用最小的工具链已经是朝着复用软件安装、消除冗余包和在工具链层次结构中正确安装软件的方向迈出了非常重要的一步

fat easyconfig

 在第一步中，这将允许将多个工具链的easyconfig合并到单个easyconfig文件中。

结论

 仍然定制的努力需要来:

• 最小化toolchains的软件拷贝。
• 提供最新的和最高的软件版本，两者都来自toolchain组件和来自其他软件。
• 在满足其他要求时，提供一个有意义的用户视图

 迁移的工作也是非长达的。

致谢

 EasyBuild was created with support of Ghent University, the Flemish Supercomputer Centre (VSC), the Flemish Research Foundation (FWO) and the Department of Economy, Science and Innovation (EWI).

总结

 这个论文是2016年撰写的，是工程类的文章（笔者也想水一篇论文来着），HPC环境的管理是一个比较大的问题。这篇文章主要描述EasyBuild的实践，而且自己在工作中也实践了这个工具，在制药环境安装中，确实缓解了不少的问题。本文主题介绍了JURECA集群的要求，为设计用户视图而做出的实践和努力。作者写文章时写的很精彩，如果有机会能去国外待几年好了。

 挺遗憾的是，自己现在也只是会使用EasyBuild来部署基本的环境，还不能深入的理解EasyBuild的设计思想，诸如toolchain，minimal toolchain，dependency resolution， module-naming-schema。还需要做更多的努力吧。

 期待自己早日能写出第一篇水论文。

2023年10月20日15:01:31于之江实验室