9 运维机制

9.1 工单流转

用户服务工单管理系统是一种专门设计来协助用户服务团队高效管理客户咨询和问题的软件工具，旨在通过提高效率、优化客户体验和加强数据驱动的决策来支持用户服务团队。

用户在使用”交我算”计算平台的过程中，可能会遇到一系列的技术问题。这些问题可能包括但不限于：无法登录、作业运行报错、软件安装及编译需求等。为了处理这些问题，并提供及时有效的技术支持，“交我算”团队建设了工单系统（tickets.computing.sjtu.edu.cn)。

9.1.1 工单系统的主要特点和功能

工单生成与追踪：客户的问题或请求通过电子邮件（hpc.sjtu.edu.cn）自动转换成工单。这些工单可以被追踪和管理，确保每个问题都得到及时回应和解决。
分类和优先级设置：工单可以根据其紧急程度、类型或客户重要性进行分类和排序，帮助用户服务团队优先处理最重要或最紧急的问题。
自动化流程：一些常见问题可以通过预设的模板进行处理和回复，提高效率。
协作与分配：工单管理系统支持团队协作，允许多个团队成员查看和处理同一工单，也可以根据需求将工单分配给指定成员。
用户沟通历史记录：系统会记录与用户的所有互动历史，包括邮件往来等，也可以记录服务团队处理工单时增加的备注信息或图片，便于回顾和分析。
报告与分析：提供统计报告和分析功能，帮助管理员掌握用户服务质量和工作量，包括处理时效、数量统计、常见问题等关键指标。

图9.1是工单系统的一个示例图。

图9.1: 工单系统示意图

9.1.2 工单处理流程

用户遇到问题时，可以发送邮件至交我算团队的官方邮箱hpc@sjtu.edu.cn。在电子邮件中，用户需要详细描述他们遇到的问题，包括任何错误消息、作业ID、使用的软件版本以及他们尝试过的解决步骤。

接到用户的邮件后，工单系统会自动记录并归类该邮件。计算服务团队会在工单系统上对用户的问题进行初步评估，并分配给合适的技术支持人员。每一位技术人员都有丰富的经验和专业知识，可以对各种问题提供专门的解决方案。

表9.1所示为交我算计算服务团队的成员组成和相应职责。

表9.1: 交我算计算服务团队成员组成和职责
团队成员	主要职责
用户服务前台	整理故障现象，回复初级问题
初级应用支持专员	重现故障现象解决初级问题，归档处理结果分析软件安装需求，协助Conda安装，更新文档
中级应用支持专员	解答特定软件使用问题使用Spack安装全局软件、更新Spackenv仓库
高级应用支持专员	解答特定软件性能问题编写Singularity Definition File, 编译软件
系统管理员	添加公钥、确认节点状态使用yum安装依赖少的全局软件

9.1.3 工单处理分类

按照工单问题的种类不同，可以细分为基础问题、作业异常、软件安装等几种处理流程。

9.1.3.1 基础问题

基础问题包括如账号密码重置、账号无法登录、费率咨询、充值缴费、作业延长或其他平台相关的咨询均由用户服务前台回复。

9.1.3.2 作业异常处理流程

作业异常处理的基本流程为，在工单系统中收到用户咨询邮件后，用户服务前台检查知识库有无解决方案，如果有则根据知识库的信息处理完毕，通知用户；如果没有，则请用户补充故障信息，并撰写软件故障简报流转至初级支持专员。

初级支持专员先判断作业是否内存不足，如果是则请用户修改核心数后重新提交作业；如果否则用自己的账号尝试重现故障。如果无法用自己账号重现故障，则询问用户是否可以用其账号重现故障。故障重现后进行故障分类处理：

修正作业脚本编写，复位.bashrc等基础错误；
如果是HPC studio作业，检查Studio后台日志；
向OnDemand社区反馈故障。

完成后回复用户，并将处理结果添加至知识库和更新docs用户文档。

图9.2是作业异常处理的流程图。

图9.2: 作业异常处理流程示意图

9.1.3.3 软件安装需求处理流程

软件安装需求处理流程为，收到用户提出需求的邮件后，用户服务前台在工单中撰写《软件安装需求》，然后检查平台的docs文档，确定是否已有安装指南或相关说明，如果有，则将链接发送给用户查看并关闭工单。如果没有，则先判断是否设计商业软件版权，商业软件问题建议用户自行联系厂商。对于开源软件，如果docs中没有相关文档，或用户需要安装的软件版本不在文档中列出，则需要回复用户提供更多信息，用户应详细描述他们的需求，包括所需软件的名称、版本号以及任何特别的配置要求。

对于开源软件，初级应用支持专员将根据用户提供信息来分析软件支持方法，撰写软件支持计划并分配软件安装任务。通常有四种安装策略：

协助用户使用Anaconda在家目录安装软件
使用Spack全局安装软件
编写Singularity Definition File，提交到hpc-container仓库
使用yum安装软件，提交到puppet-environment 仓库

完成后相关负责人员更新docs文档页面，并回复用户。

对于可视化软件，应用支持专员需要评估是否在Studio可视化部署，如果需要则增加Studio部署文件，提交到ood-app仓库。

图9.3是软件安装需求处理的流程图。

图9.3: 软件安装处理流程示意图

平台的知识库会不断更新软件安装指南，确保用户可以访问最新的信息和解决方案。

9.2 自动化运维

9.2.1 案例1：高性能计算集群故障诊断与处理软件

9.2.1.1 背景

高性能计算集群的自动化运维主要包含”自动感知”和”自动修复”两个环节。在自动感知方面，使用开源软件slurm进行作业调度的高性能计算集群通常依靠LBNL Node Health Check检查计算节点健康状态。但是NHC仅负责检查计算节点是否健康，并没有提供对故障节点的自动修复能力。

在生产环境中大部分软件层面的节点故障具有相似性和共通性，通过对故障的分类总结，可以提炼出几种常用的故障处理流程。自动化运维程序基于常见软件故障的经验总结，在开源调度平台airflow上实现了一套可拓展的故障节点自动修复流程，以填补slurm集群在自动修复环节的空白。高性能计算平台的管理员可以在此框架的基础上，结合平台实际的运维情况，进一步补充允许自动处理的故障类型和处理逻辑。

9.2.1.2 软件特色

软件以DAG工作流的形式运行于airflow调度平台上，定期读取slurm汇总的故障节点信息，根据工作流中预定义的可处理故障类型和对应的处理逻辑，自动修复发生故障的计算节点（见图9.4）。

图9.4: 计算节点自动修复流程

工作流程中各个执行环节的作用概述如下：

collect_data：通过pyslurm库调用slurm API获取全部节点的状态和故障原因信息。
classify_nodes：对collect_data环节获取的drain、down状态节点进行筛选、分类，得到可自动处理的故障节点和所属故障分类。
filter_cg_nodes：对collect_data环节获取的completing状态节点信息进行筛选，得到尚未清空作业但可以提前处理的故障节点。
handle_XXX：每个task对应一类故障的自动处理，各分类的处理并行执行，依次修复属于该分类的故障计算节点。
generate_report: 汇总上一环节各分类处理任务的修复结果，生成HTML格式的修复报告供集群管理员查看。根据修复情况判断是否需要人工介入，据此转向对应的后续task。
email_report: 仅在上一环节故障节点存在修复失败的情况下执行，将修复报告以邮件的形式发送到集群管理员指定的邮箱。
dummy_all_node_green: 仅在上一环节未发现故障节点的情况下执行，无实际操作，用于在airflow历史执行记录图上形成易于分辨的结果标记。
dummy_all_repair_ok: 仅在上一环节故障节点全部修复成功的情况下执行，无实际操作，用于在airflow历史执行记录图上形成易于分辨的结果标记。

应当自动处理的故障类别和对应的处理方式主要依据集群运维过程中的经验总结，针对可以自动修复的故障，常用的处理方式有：

重启slurmd服务
清理/tmp临时存储文件
调用reboot软重启节点
通过bmc断电硬重启节点
调用slurm指令清除不重要的报错

9.2.1.3 软件使用方式

如图9.5，安装后在airflow管理页面的DAGs标签页中可以看到名为slurm_repair的DAG，启用此工作流。

图9.5: airflow管理界面启用工作流

airflow会根据代码中设置的调度时间间隔，定期触发自动修复工作流，无需手动干涉。管理员可以在Tree View中查看历史执行记录（图9.6），在Graph View中查看指定执行记录中各task的执行细节（图9.7）。如果某一task涉及的故障节点在最终报告中显示修复失败，管理员可以点击该task进入log页面查看具体的修复日志，以辅助判断后续人工介入需要采取的修复措施。

图9.6: Task视图界面总览试行历史记录

图9.7: Graph视图界面查看执行细节

如果被修复的节点中有部分修复失败，工作流会生成修复情况报告邮件（图9.8），发送到指定的邮箱，集群管理员可以根据报告采取进一步的人工干涉措施。

图9.8: 修复结果报告邮件示例

9.2.2 案例2：模型驱动的高性能计算集群配置管理

9.2.2.1 背景

高性能计算集群是为求解大型计算问题、由多个节点通过高速网络连接而组成的集群，其能否有效工作很大程度上取决于集群中各节点是否处于协调一致的配置状态。集群节点从上架通电到下线退役发生的软件配置调整，都可归入配置管理的范畴，包括为节点初始化做的离线配置和不中断节点服务的在线配置。传统配置方法关注配置的具体操作，譬如”使用useradd 命令添加用户”“用户已存在该如何处理”等。受限于命令式配置的建模能力，传统配置方法很难快速正确地将复杂系统配置到预期状态，而由此导致作业运行效率低甚至集群下线，将严重影响高性能计算集群的正常使用。

9.2.2.2 配置管理工具选型

“基础设施即代码”( Infrastructure as Code，IaC) 是为解决复杂系统配置问题而提出的方法，其核心理念是专注表达配置的需求———即构建配置建模，具体烦琐的配置操作则由程序在模型驱动下完成。以图9.9所示的添加用户为例，配置建模使用”声明式”描述，相比配置过程使用的”命令式”描述，能更加简洁准确地表达配置意图。尽管由模型驱动的配置管理在云计算领域已获得广泛应用，但这项技术是否适合于物理机占比高、异构硬件数量多的高性能计算集群，仍需要进一步探索。

图9.9: “声明式”与“命令式”配置对比

在”基础设施即代码”实践中，配置管理与编程解题有很多共同点。如图9.10 所示。程序员使用高级语言编写程序代码，经编译器编译后得到可执行程序，执行后输出计算结果。类似地，管理员使用建模语言描述配置模型，经配置管理工具翻译后得到可执行脚本，执行后将目标节点配置到预期状态。程序员在选择编程工具链时会考察编程语言的表达能力、执行效率、第3 方库丰富程度以及对版本回溯等软件工程特性的支持。同样地，管理员选择配置管理工具时，也会重点考察建模能力、配置速度、模块数量、对版本回溯的支持和部署难度。

图9.10: 配置管理执行流程

现有主流开源配置管理工具特性对比见图9.11。表中，Puppet 使用了语法类似Ruby 的定制语言，具有很强的建模能力，又因为使用了独立的客户端所以配置速度快，庞大的社区提供了超过6 000 个模块，且可与git 版本控制系统整合提供变更回溯功能。尽管Puppet 部署难度要比其他配置管理工具高，但其提供的层次化建模、逻辑与数据分离特性对管理复杂集群配置提供了极大的便利。

图9.11: 主流开源配置管理系统对比

9.2.2.3 Puppet 配置管理工具

Puppet配置管理工具的3 个主要组件如图9.12 所示，包括建模组件、主控节点和客户端。管理员使用建模组件构建的配置模型由主控节点编译后变成可执行脚本，客户端执行脚本把目标节点配置到预期状态。

图9.12: Puppet配置管理系统组件

Puppet的配置模型包含”逻辑”与”数据”两个要素，分别描述”配置什么”和”配置参数”。

模型的逻辑使用名为Puppet DSL的特定领域描述语言( Domain SpecificLanguage，DSL)描述。这个语言专为配置管理设计，不仅提供了完成基础配置所需的函数，如安装特定RPM包、启动特定服务等，还包含了用于构建复杂功能的语言特性，如变量、数据结构、条件分支等。Puppet推荐使用名为”角色-剖绘”(Roles-Profiles)编码规范把模型代码分散到多个文件中。这个编码规范使用角色和剖绘两层抽象，分别描述节点的功能(如compute、nameserver 等) 以及实现这些功能所需的软件栈( 如slurm、bind等) 。部分具有共性功能的模型代码( 如配置MySQL、SLURM) 可发布在PuppetForge 社区或GitHub供其他用户使用。Puppet社区提供的模块数量和质量一直在不断提高，已经积累了超过6000个模块，涵盖了高性能计算集群所需绝大部分软件栈。

Puppet使用名为Hiera的程序组织模型中的数据。Hiera提供了从最细粒度的”节点”到最粗粒度”全局默认”之间多粒度层次化的参数匹配方法。Hiera 可从节点角色、操作系统或其他特征搜索参数，并按照用户指定的优先级替换或合并参数，若搜索失败将使用默认的全局参数。Hiera 很好地处理了配置数据中”一般”与”特殊”的关系，通过多粒度参数汇聚避免重复配置在多处出现。Hiera 使用”逻辑”与”数据”分离的编程理念，使得敏感配置信息得以从配置逻辑中分离出来得到保护。

Puppet提供了”文件”和”模型”两个级别的配置变更跟踪机制。在文件一级，Puppet主控节点会备份file 函数每一次对配置文件所做的修改，管理员可以查看、对比和恢复配置文件的历史记录。在模型一级，Puppet与git 集成，跟踪整个配置模型，即”逻辑+数据”的代码变更历史。管理员可使用”git签出”抽取任意时刻的模型应用到目标节点，或使用”git 分支”创造多个独立于生产环境的配置模型。Puppet配置变更跟踪机制是实现配置回溯和独立测试环境的基础。

9.2.2.4 使用Puppet配置高性能集群

使用Puppet建模组件构建了上海交大高性能计算集群的配置模型，并借助Puppet配置变更跟踪特性搭建了可回溯可测试的在线配置流程，结合Cobbler操作系统部署工具，搭建了无须人工干预的节点离线配置流程。

9.2.2.4.1 使用Puppet构建高性能计算集群的配置模型

按照Roles-Profiles编码规范，集群节点的角色和所需软件栈见图9.13。

图9.13: 节点角色分配表

具体地，lib/facter/role.rb配置文件通过正则表达式为其指定角色变量puppet_role和计算节点子类型变量puppet_subtype，接着在角色文件中引入所需软件栈剖绘。从PuppetForge和GitHub站点选取软件栈对应的模块加剖绘文件，并针对高性能计算领域特有的软硬件系统，如OmniPath网络、SLURM调度系统编写了Puppet扩展模块。Hiera使用”角色(role)-子类(subtype)-节点(node)“的优先级顺序合并参数。git代码仓库的多个分支分别对应不同的测试环境，每个环境都可独立地分配”角色-剖绘”配置、使用其他外部模块、指派配置数据。

9.2.2.4.2 使用Puppet进行可回溯的在线配置

在线配置用于完成那些无须重启节点的维护操作，包括SLURM队列设置、增加软件包、调整告警检查阈值等。

如图9.14所示，基于生产环境的模型新建git测试环境分支，在这个分支上修改模型选择个别节点应用新模型，确认新配置模型工作正常后再将git分支的修改合并到生产环境分支。在所有节点上应用更新后的配置模型。在新的git分支调试新模型时，可以使用gitrevert撤回某一个错误修改，或者用gitcheckout回滚到某个历史状态，还可以使用puppet agent -t --environment production把测试分支的集群配置复位到生产环境状态，然后开启新的git分支继续”开发-测试-合并”的流程。

图9.14: 在分支环境测试配置变更

9.2.2.4.3 使用Puppet进行无人值守离线配置

Cobbler节点部署工具和Puppet 配置工具用于无人值守离线配置，可以一键完成节点上线的流程。离线配置适合重大更新，如操作系统大版本升级、更换节点角色等。

如图9.15所示，首先，管理员通过IPMI设置目标节点通过PXE 网络启动并重启节点，节点从Cobbler服务器获得启动镜像和Kickstart 文件，重新部署操作系统。然后，安装程序调用puppet 客户端在这个新部署的操作系统上配置其他服务组件。最后，安装程序退出，节点自动上线提供服务。经测试，这个流程可并发部署超过1 000个物理机或虚拟机。通过调整Cobbler和Kickstart的设置，还可以定制每个节点使用的操作系统和分区方案。

图9.15: 无人值守部署流程图

9.2.2.5 性能测试

9.2.2.5.1 配置时间对比

以”配置SLURM作业调度系统”和”配置一个新的节点”这两个任务为例，传统配置方法和模型驱动的Puppet 方法的工作效率对比见图9.16。模型驱动方法在准备阶段时间、执行阶段时间和需要撰写代码行数均优于传统配置方法。传统配置方法在”配置SLURM调度系统”时，需要单独为slurmctld、slurmdbd、slurmd这几个服务维护内容相似的配置文件，并配置相应的MUNGE、SSSD等服务;Puppet配置方法则可以共享SLURM 主要配置信息，并直接使用现成的SLURM、MUGNE、SSSD配置模块。传统配置方法在”配置一个新的节点”时，需要额外编写配置流程，或在操作系统部署后人工运行配置程序;Puppet 配置方法则可完全复用已有的配置流程，只需在Kickstart文件末尾加入一行调用puppet客户端的代码。除此以外，模型驱动的配置方法引入了模块化设计、变更追溯等软件工程方法，使管理员能够像发布软件一样，保障质量地进行配置变更，这是传统配置方法做不到的。

图9.16: 模型驱动配置和传统配置方法对比

9.2.2.5.2 使用Puppet 部署一个高性能计算集群

图9.17展示了使用模型驱动的配置方法部署一个高性能计算集群的主要过程和耗时。

图9.17: 集群配置主要流程图

在管理节点物理机上安装Cobbler部署服务和Puppet主控节点服务; 在管理节点安装Ovirt虚拟机管理器服务，另选一台服务器安装Ovirt宿主机服务;新建Ovirt虚拟机承载集群内的Bind域名解析、Squid代理、MariaDB数据库、SLURM主控节点服务; 批量为计算节点部署和配置系统，与此同时使用Spack软件包管理器为集群安装编译器、MPI库、数学库等工具。传统部署方法最耗时的操作系统安装和系统配置部分，被Puppet+Cobbler无人值守部署流程替代，使得部署一个包含几十甚至上千计算节点集群的时间，从1周缩短到了一天。

9.2.2.6 总结

传统”命令式”配置方法建模能力受限，不能胜任日益复杂的高性能计算集群配置任务。借鉴”基础设施即代码”的思想，将配置问题转换为建模问题。在以模型为核心的配置管理中，管理员专注编写配置模型，具体的配置操作交由模型驱动的程序执行。这套方法在开源Puppet配置管理工具基础上实现，并加入了模块划分、逻辑-数据分离、变更追溯等特性提高配置的执行效率、通用性和正确性。这套方法支撑了上海交大校级高性能计算平台超过1000个节点的配置，极大缩短在线配置、离线部署的时间，为开发新的服务内容提供了便利的测试流程。后续将整合”连续集成”技术用于自动验证和应用配置，进一步将管理员从烦琐重复的运维工作中解放出来。

9.2.3 案例3：高性能计算集群登录节点资源限制

9.2.3.1 背景

近年来，高性能计算集群和用户规模的不断扩大增加了集群登录节点的负载以及管理上的难度。集群登录节点属于共享资源，允许用户进行一些简单不耗资源的操作。但是，不同用户对集群的使用操作以及相关规章制度的了解存在着一定的差异。有些用户由于刚刚接触高性能计算，对集群认知比较有限，经常会直接在登录节点运行耗费资源的任务，导致登录节点长时间负载过高。随着高性能计算集群的用户数量逐渐增加，对集群自动化需求越来越高。因此我们急需一种自动、实时的监测技术来调节登录节点资源使用。

国外几个HPC 中心曾尝试使用cgroup 对共享资源进行限制。由印第安纳大学编写的“cgroup_py”脚本，可以起到限制用户资源的作用，但该脚本与CentOS 7系统或基于Systemd的系统不兼容; 由美国普渡大学Maves和John编写的“cgroups_py”脚本，可以对给定用户的Systemd user-$ UID.slice资源进行限制，该方法基于简单的阈值法，只能起到静态的限制作用，可扩展性不强。犹他大学Dylan、Robben等在基于Cgroups和Systemd理论基础上，提出了一种可以对共享资源进行监测的方法Arbiter2，该方法不仅可以监视用户CPU和内存使用率，还可以强制执行默认资源限制、惩罚消耗共享资源过多的用户。

我们结合上海交通大学高性能计算集群的实际运行情况，在基于Arbiter2的实现原理上，从资源和时间两个维度限制超出阈值的用户，并设计了多层惩罚机制，动态调整用户可用资源。实际应用结果表明，登录节点上用户违规次数大幅降低，资源利用率始终处于正常水平。

9.2.3.2 关键技术Cgroups和Systemd

Cgroups全称是Control Groups，早在2006年由Google工程师(主要是Paul Menage和Rohit Seth) 发起，并于2007年嵌入在linux内核中，成为一种可以限制、记录任务组所使用的物理资源的机制，如限制CPU、内存、I/O等资源的使用。Cgroups将系统中的进程(任务)进行分组化管理，每组进程为一个控制族群(control group)。控制族群以层级(hierarchy)的形式组织成一颗控制族群树，子族群继承父族群的特性。对CPU、内存等资源进行控制的子系统称之为资源控制器，必须要附加到某个层级上才能起作用，从而对层级上的控制族群进行管理。

Systemd通过提供内在机制、默认设置和相关的操作命令，降低了Cgroups的使用难度，提供了一种便捷的方式。在系统的初始化阶段，Systemd会把资源控制器即子系挂载到默认的/sys/fs/cgroup/目录下面，并自动创建进程组(slice) 、外部进程(scope)和系统服务(service unit)来为Cgroups树提供统一的层级结构。在层级顶端Systemd会自动创建4个slice(-.slice，system.slice，user.slice，machine.slice)来监测并限制用户行为，在用户登录时自动创建，在会话结束后自动销毁。默认情况下，内存和CPU的控制器都未启用，可以通过systemctl set-property user-#UID.slice 来启用，并设置: slice CPU Accounting = true，MemoryAccounting = true。

9.2.3.3 高性能计算集群上的实践过程

系统总体工作流程如图9.18所示。用户登录集群后，系统首先判断用户的cpu． usage_percpu和memory.usage_in_bytes是否超过阈值，如果超过阈值，则根据用户违规严重程度采取惩罚措施，一段时间未违规，则相应降低惩罚，逐步回归正常状态。接下来将详细介绍用户身份和状态分类、CPU和内存相关设置、惩罚级别分类。

图9.18: 系统总体工作流程示意图

首先，设置用户身份和状态。将用户设置为管理员用户和普通用户两种身份，管理员用户加入白名单，可以任意使用登录节点资源，不受限制。管理员名单目前只设置两位，更多的账号是普通用户。将用户状态设置为正常状态和惩罚状态，正常状态即默认状态，用户在登录节点上可以使用的资源是默认值的百分百，并且允许短时间内高负载运行; 当用户有违规行为时，则进入惩罚状态。

其次，分类设置系统资源。将正常用户可使用的资源设置为1核CPU，4GB内存，CPU阈值设置为cpu_badness_threshold = 80%，内存阈值mem_badness_threshild = 50%， time_to_max_bad = 5 min， time_to_min_bad = 30 min，即当用户使用CPU 超过80% 或者内存使用量超过50%，且持续时间超过5min，则不良评分开始增加，当用户的CPU 和内存使用率持续30min均在阈值以下，不良评分则会逐步减少。以内存使用率为例，随机统计了某位用户一段时间内资源使用率与不良评分的变化，如图9.19所示。

图9.19: 登录节点上用户资源使用率与不良评分变化

最后，设置惩罚措施。对于违规用户，采取3层惩罚机制动态限制用户可用资源。不同级别的惩罚措施对应的资源可用率和资源限制时间不同，如图9.20所示。

图9.20: 登录节点上用户资源使用率与不良评分变化

9.2.3.4 结果分析

我们使用3台登录节点进行了测试。实验用节点的操作系统带有cgroups v1的Systemd版本，依赖的软件主要有Python3、toml和matplotlib。研究人员在T2、T3两台登录节点主机上进行了软件部署和相关参数设置，T1主机上保持原有状态。

经过6个月的试运行，登录节点的T2、T3主机资源平均使用率显著下降，因用户不合理行为导致节点挂机的情况减少至零。随机统计了一段时间内3台登录节点资源使用率，如图9.21所示，T2、T3主机上的内存和CPU资源使用率始终在50% 以下，T1主机上的内存和CPU资源使用率较高，平均在80%左右。

图9.21: 登录节点上用户可用资源限制前后使用率对比

9.2.3.5 总结

我们针对登录节点负载过高的情况，在研究了其他HPC机构的管理方式后，提出了一种基于Cgroups控制组策略的可以动态限制资源的方法。实际应用结果表明，CPU和内存使用率始终处于正常水平，登录节点的稳定性和可靠性得到了提高。同时，我们提出的方法对其他机构高性能计算集群的登录节点管理也有一定的参考价值。

9.3 故障处理与应急预案

9.3.1 工作背景

随着高校信息化建设的快速发展，超算集群规模日益增大，随之而来的故障也不断增加。超算集群作为高校计算资源的核心，其稳定运行不仅关系到科研和学术项目的顺利推进，更关系到高校在科技创新和学术研究方面的竞争力。超算集群不仅仅是计算工具，更是高校在各个领域取得突破性成果的重要技术支撑。

总结我校历年的管理维护经验，我们发现，即使在设计、建设、运营、维护阶段重点关注冗余、安全等问题，极端情况下的故障还是无法规避，故障可能由硬件故障、软件问题或操作失误引发，若不能迅速应对，不仅会造成计算任务的中断，还可能导致数据丢失，从而对科研进展和项目成果带来难以弥补的损害。为应对这些故障，超算中心近年来开始探索构建并不断完善超算集群的故障处理机制与应急保障机制。

在这一背景下，我们建立了详实的集群维护日志、运维管理制度、简明实用的软硬件操作流程和高效的应急处理流程，强调快速发现、快速反应与快速处置，力求最大程度保障业务延续。在以上机制的建立过程中，不断从现实事件中汲取经验教训，逐步完善形成一套更为贴合自身业务、适应自身现状的成熟的故障处理机制与应急保障机制。通过全面而系统的故障处理机制与应急保障机制，高校超算中心能够在面对超算集群故障时，以最高效、最迅速的方式恢复系统正常运行。

9.3.2 运维管理制度

9.3.2.1 root授权管理规范

root授权管理

高性能计算集群root权限由高性能计算办公室审核批准。人员离开时，应及时取消上述人员的root授权。
非授权人员(包括且不限于未获得授权的员工、普通用户)提出需要使用root授权时，应向高性能计算办公室申请，审核通过后由具有root授权的人员操作。
root授权未经允许不可转给其他人。
持有root授权人员，未经允许，不得进行授权变更的操作，包括且不限于增加授权、取消授权等。

root授权使用范围

root授权类型分为：堡垒机(puppetserver)授权、登录节点授权、计算节点授权，三种root授权各分管一部分功能，不可混用。
堡垒机授权用于开启和关闭集群、远程重启计算节点、远程登录到计算节点进行故障诊断。
登录节点授权用于预约SLURM资源、创建普通用户、协助用户解决编译问题和处理与用户数据相关的问题。
严禁使用root授权在未获得允许的情况下访问或修改用户数据。

root操作日志回溯

监控值班人员有责任保障日志收集系统正常工作，及时发现异常，发现故障后应于当日内向高性能计算办公室报告。日志监控系统应保证堡垒机、登录节点和计算节点的root操作可回溯至少30天。

9.3.2.2 机房管理制度

组织结构

部门负责人

职责：负责运维管理体系制定、整体协调事宜，指导运维主管开展工作。
职位描述：

1）整体负责高性能计算部运维管理体系的制定，领导运维主管并安排运维工作，指导运维主管完成具体维护工作，每周听取运维主管的工作汇报，负责考核运维主管工作完成情况。

2）协助建设单位完成新增项目的调研、方案设计并指导项目经理进行具体实施。

运维主管

职责：规划、执行、完善运维工作，指导运维工程师开展工作。
职位描述：

1）根据公司战略目标，指导下属工程师开展客户服务工作，确保运维工作能够满足客户的实际需要；建立和持续完善运维管理体系，优化运维流程流程，解决运维服务中出现的特殊问题；

2）规划并提升运维工程师专业服务能力，在整体上提高客户满意度；

3）制定和持续完善绩效考核体系；

4）制定整理运维项目的应急预案系统，并指导运维工程师实施；

5）提高自身专业技能，在业务方面给予运维工程师指导。

运维工程师

职责：执行日常巡检制度，解决集群运行中出现的各种问题。
职位描述：

1）工作日上午下午各一次机房巡检，及时发现机房环境、集群设备的异常情况，并做好相应的巡检记录。

2）巡检发现空调、UPS、微模块、环控、消防系统的故障，立即联系动环保障工程师，协助动环保障工程师处理故障，保障集群正常运行。

3）巡检发现计算节点、网络设备、存储设备故障。立即定位故障，如果有备件，立即更换。如果无备件，联系厂商，要求厂商工程师在24小时内到达现场，完成故障处理。

4）时刻注意机房空调运行状态，保持机房及设备恒温、湿度状态，出现故障要及时通知动环保障工程师配合解决；

5）协助动环保障工程师完成计划内的集群维护工作（如大楼电力维护，空调加防冻液等）；

6）当出现机房高温报警、空调的电力故障、UPS主机故障，一次性超过8个节点下线，lustre故障等严重影响到用户使用的故障时。运维工程师需要立即启动应急响应预案，具体处理流程参照《高性能计算集群应急响应预案》。

7）工作认真、细致，积极主动有条理性，具有良好的沟通能力及团队合作精神。

动环保障工程师

职责：保障计算平台机房供电、制冷、UPS正常运行。
职位描述：

1）日常巡检机房配电柜、列间空调、室外冷水机组、UPS机组及电池组；

2）接到运维工程师报修或者巡检发现供电、空调故障，立即定位故障，如果无法立即修复，联系厂商，预约上门服务时间，要求厂商工程师在24小时内到达现场，完成故障处理。如需申请备件，也要求在3天内到货；

3）密切联系校动力科，时刻掌握停电通知，负责协调集群停电维护事宜；

4）定期联系空调、UPS厂家，严格执行月度、季度、年度巡检保养制度；

5）当出现供电报警、温度报警等紧急情况时，第一时间定位故障原因，确定停电时长并告知运维工程师，以便运维工程师进行下一步操作。

6）工作认真、细致，积极主动有条理性，具有良好的沟通能力及团队合作精神。

维护内容

计算平台机房的维护内容按重要程度可以分成三级：核心级、重要级、一般级。

核心级包括：机房动力及环境监控的维护；机房制冷系统维护管理；配电设备维护管理。核心级的维护内容一旦出现故障，需要在30分钟内响应，3小时内解决故障。
重要级包括：UPS及电池维护管理；机房消防设备维护管理；机房主机设备维护管理。重要级的维护内容一旦出现故障，需要在2小时内响应，6小时内解决故障。
一般级包括：机房照明的维护管理；机房基础维护管理；机房运维管理体系建设。一般级的维护内容一旦出现故障，只需要在工作日时间内解决即可。

维护要求

机房动力及环境监控的维护

1）每季度清理一次监控设备上显露的尘土，调整摄像头清晰度，同时检查监控主机的通风、散热、供电情况。确保各传感器各项功能良好，能够正常运行。

2）对容易老化的监控设备部件每季度进行一次全面检查，一旦发现老化现象应及时更换、维修，如视频探头、采集模块等。

3）对长时间工作的监控设备每月定期维护一次，如硬盘录像机长时间工作会产生较多的热量。一旦风扇有故障需要立即修复，否则会影响设备散热，导致设备无法正常运行。

4）对监控系统及设备的运行情况进行监控，分析运行情况，及时发现并排除故障。

5）每月进行一次机房动环监控日志上报。每月第一个工作日，将上月维修、维护、保养记录汇总形成报表，以邮件形式发送给主管领导。

机房制冷系统维护管理

1）列间空调日常巡检。观察主机控制面板，确认所有LED指示灯状态，观察设备有无声光报警和故障指示，观察空调运行有无异常噪声，观察温湿度状态显示有无异常。如有报警信息和异常情况，立即联系厂商上门维修。

2）季度维护。每一季度检查一次过滤网，如果污垢堆积严重，联系厂商上门清洗。每一季度检查一次加湿器，如果结垢严重，联系厂商上门清洗。

3）冷却塔日常巡检。观察冷却塔周围是否有阻碍通风的障碍物，观察塔体和配管是否有异常的振动和噪音。观察塔内补水是否正常，以及循环水的水质、水量是否正常。

4）定期安排厂商上门对冷却塔、冷水机组等室外设备进行维护以及保养。在冬季或者极度低温情况下，添加防冻液，防止室外循环水冻结。

配电设备维护管理

1）每日上午、下午对ATS配电柜1、ATS配电柜2、UPS输入配电柜、UPS输出配电柜、动力配电柜1、动力配电柜2进行巡检，发现数据异常立即联系动环保障工程师进行处理。

2）动环保障工程师遇到配电设备故障应先定位故障点，若无法及时修复，应和运维工程师、运维主管联系，制定维修方案。若有必要，联系校动力科，安排停电维修时间。

UPS及电池维护管理

1）严格按照正确的开机、关机顺序进行操作。避免因负载突然加载或突然减载时，UPS电源的电压输出波动大，而使UPS 电源无法正常工作。

2）每天定时巡检，记录主机运行参数，查清各参数是否正确或切合实际，及时发现事故隐患。

3）严禁频繁地关闭和开启UPS 电源。一般要求在关闭UPS 电源后，至少等待30 秒钟后才能开启UPS电源

4）禁止超负载使用。UPS 电源的最大启动负载最好控制在80%之内，如果超载使用，在逆变状态下，时常会击穿逆变管。将其负载控制在30～60%额定输出功率范围内是最佳工作方式。

5）对于长期无停电的UPS，应当每隔3～6个月对电池放电，然后重新充电。这样才能延长电池的使用寿命。对于长期存放的UPS，应当每隔3～6 个月对UPS 开机使用和充电。

6）定期对UPS 电源进行维护工作。清除机内的积尘，测量蓄电池组的电压，检查风扇运转情况及检测调节UPS 的系统参数等。

机房消防设备维护管理

1）检查火灾报警控制器的自检、消音、复位功能以及主备电源切换功能；

2）检查报警探测器、手动报警按钮、火灾警报装置外观；

3）检查储瓶间环境、气体瓶组或储罐、选择阀、驱动装置等组件外观；

4）检查应急灯和疏散指示标志工作状态。

5）检查火灾报警探测器、手动报警按钮、报警控制器、联动控制设备的试验报警功能。

机房主机设备维护管理

1）每日上午、下午对机房内各设备进行全面巡检，及时发现故障设备并进行登记处理；每日填写巡检日志；

2）定期对集群进行全盘漏洞扫描，及时发现高危漏洞并修复，提高系统安全等级，避免发生恶意攻击事件；

3）机房内计算机系统软硬件的配置及更改，须由上海交通大学管理人员进行或允许后方可操作。为防止计算机感染病毒，使用外来的软盘、光盘、U盘、移动硬盘等移动存储介质前，要先查毒后使用；

4）每季度对机柜及机柜内设备进行除尘清洁。

机房照明的维护管理

1）镇流器、灯管更换；灯盘校正，开关更换，

2）线头氧化处理，标签巡查更换，漏保实验。

机房基础维护管理

1）吊顶表面清洁；板材松动、翘起修复，变形、损坏更换；龙骨调平等；

2）墙面污迹清理，裂缝修补；

3）玻璃清洗，不锈钢清洗，玻璃胶修整，地弹簧校正，拉手螺丝加固；

4）静电地板清洗清洁，地面除尘；缝隙调整；平整度调整；损坏更换；

5）机柜除尘、清洁；机柜及网络设备整理，包括交换机、配线架和网线的重新整理、排序，并重新标上统一的编号；

机房运维管理体系建设

1）完善机房运维规范，优化机房运维体系；

应急响应预案

系统的故障等级共分三类：

重大故障：在系统运行期间，硬件故障（服务器、存储、交换机、空调、UPS、配电）、软件（slurm,lustre）故障造成所有超算业务中断超过24小时。
严重故障：在系统运行期间，硬件故障（服务器、存储、交换机、空调、UPS、配电）、软件（slurm,lustre）故障造成超算业务中断超过12小时但不超过24小时；
一般故障：除重大故障和严重故障外的其他故障。

机房停电预案

1）发生停电后第一时间电话联系基础业务部动环保障工程师询问停电原因及停电时长。确定停电时长是否在UPS负荷工作时间范围内，如果在UPS负荷工作范围内，密切观察UPS工作状态，所有设备正常工作；如果超出UPS工作范围内，向领导申请，存储信息，关闭机房设备，防止机房断电造成数据丢失。

2）电话通知相关领导汇报停电状况，并在用户群发布停电通知。随时和领导汇报现场情况，在电力恢复后形成事故报告。

机房防火预案

当发生火灾事故时，抢险工作应遵循如下原则：

1）坚持“统一领导、分级负责、严密组织、密切配合、快速反应、保障有力”的原则。

2）坚持快速恢复生产、减少经济损失的原则。

3）坚持原则性与灵活性相结合的原则，注意讲究策略和方法。

4）坚持“预防为主，防消结合”的原则。

5）坚持“谁主管、谁负责”的“两谁”原则。

9.3.2.3 驻场规章制度

总则：安全，诚恳，细致，自觉。

在服务过程中，驻场服务人员禁止一切行为损害客户的业务系统。驻场服务人员要做到耐心、细心、热心的服务。工作要做到事事有记录、事事有反馈、重大问题及时汇报。严格遵守工作作息时间，严格按照服务工作流程操作。
严格遵守公司规章制度。在公司规章制度下，开展具体工作。
凡违犯本章程的职员，依有关制度为准绳，按程序公正处理。

人员与地点

人员配置：安排1名驻场服务人员。
地点安排：上海市闵行区东川路800号上海交通大学网络信息中心。

日常行为

驻场运维的工作区域为：用户单位所在地办公区域。
驻场服务时间为法定工作日5*8小时驻场。
遵守用户单位的各项规章制度，严格按照规章制度办事。
遵守保密原则。对被支持单位的网络、主机、系统软件、应用软件等的密码、核心参数、业务数据等负有保密责任，不得随意复制和传播。
出现疑难技术、业务问题和重大紧急情况时，及时向用户单位报告。
与用户运维体系其他部门和环节协同工作，密切配合，共同开展技术支持工作。
现场技术支持时要精神饱满，穿着得体，谈吐文明，举止庄重。接听电话时要文明礼貌，语言清晰明了，语气和善。

考勤制度

严格遵守上海交通大学网络信息中心的办公时间,不得迟到早退。
准时上下班，对所担负的工作争取时效，不拖延、不积压。
中午就餐时间12：00-13：00。除就餐外，其他时间不得无故离岗。
事假需提前一天向上海交通大学管理人员申请，得到上海交通大学管理人员同意后按照公司人事要求提交请假说明。如未向客户申请，导致的损失，按照矿工处理。
如假期未得到上海交通大学管理人员同意或未提出申请，按旷工处理。
驻场人员因病必须治疗及休养时，按照公司人事管理办法处理。

驻场服务职责

留存好与厂商交接资料（产品合格证、使用说明书、信息统计表等等），并明确各部分的相应接口人。若发生变更，则及时更新相应资料。
服务范围内的设备/系统日常运行维护，确保系统的可靠性和可用性。
对于空调、UPS、微模块、环控、消防系统的故障，立即定位故障，如果无法立即修复，联系厂商，预约上门服务时间，要求厂商工程师在24小时内到达现场，完成故障处理。如需申请备件，也要求在3天内到货。
对于计算节点、网络设备、存储设备故障。立即定位故障，如果有备件，立即更换。如果无备件，联系厂商，要求厂商工程师在24小时内到达现场，完成故障处理。
工作日上午下午各一次巡检，对出现的问题按照校方的要求做好记录，巡检内容具体如下： 1）巡检机房内服务器、存储、交换机工作状态（是否有报警灯）； 2）巡视机房、微模块门禁的关闭情况； 3）巡视机房、微模块的卫生状况； 4）巡视机房、微模块的灯光状况； 5）巡视空调（室内、室外）的工作状况（是否有报警信息）； 6）巡视UPS、电池的工作状况（是否有报警信息）； 7）巡视机房环控系统的工作状况（是否有报警信息）； 8）巡视消防报警系统（是否有报警信息）。
每周参加校方的集群管理团队例会，汇报一周的工作情况并参加其他与运维相关的会议。
负责校方对外接口邮箱（hpc@sjtu.edu.cn）的日常技术支持工作，解决用户在集群使用中遇到的各种问题。
协助校方完成计划内的集群维护工作（如大楼电力维护，空调加防冻液等）。
由校方决定是否给驻场工程师root权限或者一般用户权限账号，若给予root权限，驻场工程师需遵守《高性能计算集群root授权管理办法》。
完成校方指派的其他工作。

机房安全注意事项

驻场服务人员必须严格遵守上海交通大学机房的管理要求。

明确上海交通大学高性能计算机房负责人或者驻场服务接口人，获取机房、UPS电池间、备件库的门禁出入权限。
严格注意防火、防盗，机房内严禁吸烟和使用明火，不得存放各种易燃、易爆、放射性及强磁场物品。驻场服务人员外出及下班时要锁好门窗。
驻场服务人员应时刻注意机房空调运行状态，保持机房及设备恒温、湿度状态，出现故障要及时通知有关人员配合解决。
驻场服务人员未经批准不得擅自关闭服务器。因机房设备检测、维修或其他原因关闭服务器，应事先征得相关负责人批准。
驻场服务人员要定期维护机房设备，保持正常运行。发现异常情况应及时处理并好记录，如不能解决须报告相关负责人研究处理方案。
机房内计算机系统软硬件的配置及更改，须由上海交通大学管理人员进行或允许后方可操作。为防止计算机感染病毒，使用外来的软盘、光盘、U盘、移动硬盘等移动存储介质前，要先查毒后使用。
机房内的设备、资料、物品是校方财产，未经校方允许，不允许动用。开展运维工作需要的时候，需要向校方申请，取得同意后方可使用。
保持机房清洁卫生。严禁在机房堆放杂物，禁止将食品或与工作无关的物品带入机房。
未经允许，驻场服务人员不允许带第三方人员进入机房。
注意静电危险，禁止徒手接触主机系统主板。

9.3.2.4 UPS机房管理规范

UPS机房现场管理

UPS设备及蓄电池巡检人员应了解主机PLC面板的基本操作。明确巡查、检查的频次及要求等，主要巡查以下内容： 1） UPS机房内应保持清洁，主机设备及电池表面无灰尘，环境温度、湿度应符合厂家产品说明书相关要求。 2）通风换气设施、空气调节设施运行正常。 3）火灾报警、灭火设施处于适应工作状态，灭火器材完好、有效。 4） UPS风扇工作正常，输出处无明显高温，过滤网或通风栅格及进出风口无堵塞、无杂音。 5） UPS控制操作显示面板工作状态指示应正常，图形显示单元处于正常运行状态，各项运行参数都处于正常值范围，显示记录内无故障和报警信息。
禁止携带易燃、易爆、强磁物品及其它与机房工作无关的物品进入机房，禁止违章使用电器。机房内禁止吸烟、饮食，在机房内不做与工作无关的事。
UPS设备及蓄电池巡检人员应对UPS系统的运行情况作好记录，包括UPS电源的充、放电时间，故障发生及排除的情况等，以便维护和维修。
UPS设备及蓄电池的日常巡检人员必须与UPS电源设备供应商的专业维护人员保持联系，若出现故障能及时联系排除，或者尽快安排上门检修。
UPS机房若有施工的情况、在施工期间需做好对设备的保护，施工完毕之后，施工人员必须将施工现场清理干净。

UPS机房权限及人员出入管理

UPS机房运维巡检人员的门禁卡需在网络信息中心的门禁系统注册并获得授权，无门禁卡权限的网络信息中心人员及外单位人员如因工作需要进入的，应统一由计算业务部进行授权，并由相应拥有权限的人员陪同进入机房。
拥有机房出入权限的人员不得私自带领无权限人员进入机房，获得授权后进入也需做好登记。拥有机房出入权限的人员也不得私自将门禁卡交由其他同事。
对即将离职或职位调动人员的UPS机房门禁权限，计算业务部统一进行回收。

9.3.3 软硬件操作流程

9.3.3.1 软件安装流程

在回复用户安装软件前，先让用户通过工单系统填写如下基本内容（可根据咨询内容适度删改）：

学院：
课题组负责人名称：
账号：
软件名称：
是否是商业软件：
软件官方网站：
软件下载地址：
软件安装的目录：
数据测试目录：
是否同意我们进入您的目录操作：
您目录下软件安装包的位置：
您具体的问题是什么？
重现该问题需要做什么操作？
您尝试解决该问题的方法？

通过用户的回答，总结软件安装需求，相关内容包括：

用户名
是否是VIP用户
软件名
软件网址
是否是商业软件
在docs上的入口
在Anaconda的入口
是否是GUI软件
是否是广泛使用的HPC软件

如图9.22所示，在超算文档规范登记软件，评估软件重要性和安装难度。

图9.22: 软件登记示意图

登记完成后，撰写软件支持计划，内容包括：

采用何种方式为用户安装软件
用户目录编译:
是否需要在Studio上可视化部署：
预估完成时间：
建议操作人：

软件安装完以后，需要在docs文档添加入口，增加软件页面，并在超算文档规范表里登记，添加相应的工单链接。

9.3.3.2 存储坏盘更换流程

操作前准备

准备好待更换的新硬盘。
请使用通过原厂公司认证且与产品型号相匹配的硬盘模块（该备件为服务工程师通过故障硬盘备件编码获取的对应备件）。
已经定位待更换硬盘模块的位置（现场盘阵指示灯亮红色）。

注意事项

为防止硬盘模块损坏，拉出或推入框体时，请缓慢操作。如遇到螺丝固定的框体，可在218备件库右手边拿十字螺丝刀。
拔插硬盘模块时用力要均匀，避免用力过大或强行拔插等操作，以免损坏部件的物理外观或导致接插件故障。
插拔硬盘应当间隔至少30秒，即在拔出硬盘模块30s后再插入硬盘模块（期间可对坏盘做拍照、权鉴工作）。
只允许更换硬盘告警/定位指示灯亮红色的硬盘模块。
需在硬盘拔出后的5分钟内完成硬盘模块的更换，否则系统散热性会受到影响（一般在替换后指示灯会在60-90s内恢复绿色，即可推回硬盘框）。

操作步骤

拉出框体。
按下硬盘模块拉手上的卡扣，拔出硬盘模块。
将取出的硬盘模块放入防静电包装袋。
将待安装的硬盘模块从防静电包装袋中取出。
将待安装硬盘模块的拉手完全打开，将硬盘模块插入空槽，合上拉手。
等待大约2分钟后，根据硬盘模块状态指示灯的状态，判断安装是否成功。
安装成功后，缓慢推入框体（动手操作部分完成）。
第二天再进后台web系统检查硬盘情况（数据恢复大约需要10-12小时）。

9.3.3.3 平台巡检流程

常规机房巡检操作流程包括：

通过电子门禁，刷卡进入机房；
检查空调面板是否有告警；
检查UPS主机面板是否有告警；
检查服务器交换机是否有告警或警示灯亮红灯；
观察空调室外机是否有漏液、异响的情况；
如有异常，联系相关工程师进行处理；
巡检过程中发现相关基础设施面板有告警或警示灯亮红灯先拍照统一发给相关工作人员；
告警相关记录记录在seatable相关维护日志上。

9.3.3.4 空调室外机切换流程

背景：某计算平台制冷方式为水冷制冷，室外机包括冷水机组+冷却塔，冷水机组与冷却塔均为1用1备，在临时维护或常规轮换时需手动切换使用。超算平台外机示意图如图9.23所示。

图9.23: 超算平台室外机示意图

冷水机组切换流程

切换前确认事项：注意关闭机组一侧的两个手动阀门处于全部开启状态，两个电动阀门处于全部开启（open）状态。
点击电源键，关闭在运行的机组，机器应在10秒内关闭。
点击电源键，开启另外一台机组，机器应在10秒内开启，现场观察运行5分钟没有异常可判定切换成功。

冷却塔切换流程

切换前确保即将使用的冷却塔内部基本干净；
1人开启2#冷却塔两个回水阀门，并立即彻底关闭1#冷却塔两个回水阀门；
另外1人在手动阀门切换接近完成时操作冷却塔控制柜进行切换；1#冷却塔由“远方控制”旋转至“手动操作”,2#冷却塔由“手动操作”旋转至“远程控制”。并立即观察操作后两个冷却塔上水电动阀门是否有动作反应，正常应是1#冷却塔电动上水阀关闭，2#冷却塔电动上水阀开启。完成控制系统与四个手动阀门（2开2关）操作后需要在90s内观察与判定阀门状态及冷却塔风机、水流是否都正常，否则需要回退原来冷却塔或临时关闭室外机系统进行维修。

9.3.3.5 故障排查

日常巡检内容包括：检查空调系统是否有告警、检查计算节点是否有告警、检查存储节点是否有告警、检查是否有新增故障节点、检查是否有闲置的作业节点，检查是否有用户在运行作业；
slurm控制下的节点重启：计算节点长时间运行后，会因为软件问题导致计算速度下降，可以通过重启操作系统来解决。SLURM 提供了一种相对友好的重启机制，用来在节点闲置时自动重启计算节点，从而影响当前作业。建议每两周对节点重启一次；
排查故障时内容包括：排查硬件故障、节点软件故障、用户作业故障；
故障节点恢复后，经运行测试成功后正式上线使用。

9.3.3.6 集群重启

关闭计算集群需遵循下面的操作顺序：

关闭所有登录节点；
通过作业调度系统停止向计算节点加载新作业；
关闭所有计算节点；
关闭物理机；
关闭交换机；
关闭puppet节点；
关闭空调及机柜电源；
关闭制冷系统室外机部分。

开启计算集群需遵循下面的操作顺序：

开启制冷系统室外机部分；
开启机柜电源，空调电源；
开启交换机；
开启物理机；
开启文件系统服务器；
开启计算节点；
恢复作业调度系统；
开启登录节点。

注：【集群状态监控】、【账户管理】、故障排查、集群重启、【设备监控】、【系统升级】内容待完善，【】部分内容过多且过于具体，如何简化待讨论

9.3.4 应急处理流程

9.3.4.1 机房火灾应急预案

处置原则

火灾应急预案所遵循的原则是：首先保人员安全；其次保关键设备、关键数据安全；三是保一般设备安全。

火灾预防

机房全体人员应有高度的防火意识，禁止在机房内存放易燃易爆物品，禁止在机房内吸烟或使用明火，禁止在机房内乱拉电线。如发现以上情况，应立即上报机房管理员，由机房管理员协调处理相关问题。
消防器材由专人负责保管,并定期检查消防器材。未经许可,禁止擅自移动。 1）二氧化碳灭火器由保安部主管提供相关人员负责保管、检查； 2）机房专用气体消防灭火系统由环境与布线工程师通知厂商做定期检查。
机房巡检人员发现异味、烟雾、明火等不安全因素，必须及时上报保安，并做好记录备案。其他人员发现上述情况可参照机房管理须知，通知机房管理员、保安。
走廊、楼梯等公共部位严禁堆放物品，保持通道畅通。若发现通道堵塞，机房管理员应协调人员清理堆放物品。

预案流程

预案流程如图9.24所示。

图9.24: 火灾应急相应流程示意图

应急措施

接警：任何人员发现火情时，应参照机房管理须知立即上报保安部,保安部主管收到电话告警或消防系统警报后，应立即派人赶往现场查看火情。
警情判断： 1）误报：当保安部主管发现是误报后，复原消防告警系统，并通知机房管理员。 2）I级火灾：保安部主管发现只是局部或轻微着火，并判断不会危及其他设备，可利用二氧化碳灭火器扑灭的火灾。 3）Ⅱ级火灾：保安部主管发现单个机柜着火，并判断会危及其他设备，且利用二氧化碳灭火器无法扑灭火源，需要利用机房专用气体消防灭火系统扑灭的火灾。 4）Ⅲ级火灾：保安部主管发现多个机柜着火，判断火势较大难以控制，机房专用气体消防灭火系统也无法扑灭的火灾。
应急启动： 1）遇到I级火灾时，保安部主管应立即指挥保安人员利用二氧化碳灭火器实施灭火，判断火势能否被控制，并依次电话通知中心负责人、计算业务部主管领导、计算业务部负责人、机房负责人、环境与布线工程师、机房管理员。 2）遇到Ⅱ级火灾时，保安部主管应立即向环境与布线工程师申请中断机房供电。环境与布线工程师在得到机房管理员确认后，中断机房供电。保安部主管向中心负责人申请使用机房专用气体消防系统灭火，并依次电话通知中心负责人、计算业务部主管领导、计算业务部负责人、机房负责人、环境与布线工程师、机房管理员。 3）遇到Ⅲ级火灾时，保安部主管应迅速通知公安消防队，根据保安部内部的《火灾应急预案》，组织相关人员实施灭火救援。保安部主管依次电话通知中心负责人、计算业务部主管领导、计算业务部负责人、机房负责人、环境与布线工程师、机房管理员。

应急恢复

保护现场：火灾扑灭后，保安部主管指挥保安人员在火灾区域设立警戒区，禁止无关人员进入，配合公安消防部门调查火灾起因。现场清理：保安人员在现场清理时，要在专家和领导的指导下进行。消除烧毁物资，杜绝火势复燃。
物资清点：火灾消除后，由设备管理员清点物资，并登记造册，计算火灾损失。
恢复业务：由环境与布线工程师评估机房基础设施受损情况，由机房负责人、机房管理员统计IT设备、数据损失情况，根据领导意见开始机房重建及业务恢复工作。

总结评审

中心负责人召开会议回顾火灾事件。分析火灾原因，加强火灾防范，明确事故责任，做好灾后部署。
应急恢复结束后，部门负责人应对整个应急响应过程进行分析、回顾，并按对预案的响应程序进行修订。

9.3.4.2 集群故障应急响应

职责分工

超算系统管理员：主要负责高性能计算集群的故障诊断及修复，编写故障报告，更新维护日志等工作。
超算系统用户专员：主要负责高性能计算集群的故障信息通知、机时返还等工作。
空调电力系统专员：主要负责高性能计算集群的空调、电力故障处理等工作。
超算系统值班专员：主要负责非工作日期间，收到节点下线邮件后，第一时间在π用户群里面发布故障信息。

工作流程概述

应急流程如图9.25所示。

图9.25: 集群故障应急流程示意图

故障初诊 当超算系统管理员收到用户微信群的异常作业终止反馈、空调电力系统专员的短信告警、邮件告警等故障通知后，在半小时内完成故障初诊，整理出故障简报，并将故障简报发送至超算机房运维群和员工群中。

用户通知 超算系统用户专员根据故障简报，拟定通知。通过users邮件列表和微信群通知用户相关故障信息，告知故障详情和最新进展，解决用户提出的问题。

故障处理

电力、空调系统故障

空调电力系统专员负责立即定位故障，如果无法立即修复，联系厂商，预约上门服务时间，要求工程师在24小时内到达现场，完成故障处理。如需申请备件，也要求在3天内到货。

计算节点、网络设备、存储设备故障

超算系统管理员负责立即定位故障，如果有备件，立即更换。如果无备件，联系厂商，预约上门服务时间。核心设备（存储设备、核心交换机）要求厂商3天内上门维修。

软件故障

超算系统管理员负责按照单节点故障处理流程或Pi集群重启流程重新上线集群服务和计算节点。

故障总结

编写故障报告

故障按严重程度分为严重故障和一般故障。严重故障是指：机房的高温报警、空调的电力故障、UPS主机故障，一次性超过8个节点下线，lustre故障等严重影响到用户使用的故障。这类故障需要马上启动应急响应预案。一般故障是指：小于8个节点下线，内存故障、风扇故障等那些短期不处理，不会严重影响到用户使用的故障。这类故障在工作日处理即可。由超算系统管理员编写故障报告，内容包括故障发生描述、故障原因、故障临时处理、后续维修、追责问责（含故障未及时发现的责任、故障未及时处理的责任）这五部分。

机时返还

在故障处理完毕后，超算系统用户专员通过users邮件列表和微信群及时告知用户故障已回复，并且在一周内返还收到故障影响的作业机时。

9.3.4.3 网络信息安全应急响应

职责分工

计算业务部主任

负责审核网络信息安全应急预案，指导督促应急预案的修订和完善，检查预案执行情况；
负责加强对本部门员工的信息安全教育和引导，提高安全防范意识；
负责落实各业务负责人，建立和完善信息安全责任制。

安全小组组长

通过漏洞扫描工具或者国内外安全网络信息组织获取安全预警信息，并及时告知用户；对异常流量来源进行监控，并妥善处理各种异常情况；
协助业务负责人找出网站、应用的高危漏洞，并评估漏洞风险；待漏洞修复后，负责漏洞的修复验证工作；
负责组建信息网络安全应急救援队伍并组织培训和演练。

业务负责人

负责网站、应用、集群的日常维护工作，每天定期巡检，及时发现系统异常情况；
负责编制、修订网络信息安全应急预案；
负责调查和处置突发的网络信息安全事件，及时上报并做好善后工作；
负责组织厂商的开发人员对突发的网络信息安全事件进行应急处置；
协助安全小组完成漏洞的修复和验证工作。

事件分类

根据网络与信息安全事件的性质、机理和发生过程，网络与信息安全事件主要分为以下两类：

安全漏洞。指网站、集群、应用系统被发现存在安全漏洞，还未被他人利用，还未造成具体损失和影响的事件。
安全事件。指网站、集群、应用系统被恶意篡改，非法登录，具体原因还有待分析，已造成具体损失和不良影响的事件。

处理流程

对于安全漏洞：

漏洞发现。漏洞获知通常有以下方式：

来自软、硬件厂商和国际、国内知名安全组织的安全通告。
单位信息安全部门工作人员的渗透测试结果及安全评审意见。
来自单位合作的安全厂商或友好的外部安全组织给出的漏洞通知。

应急处理。一旦发现漏洞，业务负责人立即缩小访问范围，封闭外部访问，与其他主机隔离。并通知校安全小组和领导。
漏洞评估。协同安全小组对漏洞进行风险评估，由安全小组给出风险评估报告和修复意见。
漏洞修复。业务负责人根据安全小组的风险评估报告和修复意见，安装厂家官方提供的漏洞修复补丁；正确配置系统登录口令；协调开发人员修正代码中存在的安全漏洞和功能缺陷。
修复验证。由安全小组对修复结果进行回归性测试和检查，确保漏洞成功修复。
安全总结。业务负责人整理本次安全漏洞的具体情况及补救措施，形成安全报告，将有关情况向领导和安全小组汇报。

对于安全事件：

事件发现。当业务负责人发现网站上出现非法信息；发现应用系统出现非授权用户登录；发现集群服务器出现病毒感染等安全事件。
应急处理。业务负责人应该立即把网站下线；关闭应用系统；将感染病毒的服务器机从网络上隔离出来。并通知校安全小组和领导。
事件分析。协同安全小组对本次安全事件进行全面分析，清点损失，找出安全漏洞，制定整改方案。
漏洞修复。业务负责人根据安全小组制定的整改方案，安装厂家官方提供的漏洞修复补丁；正确配置系统登录口令；协调开发人员修正代码中存在的安全漏洞和功能缺陷。
修复验证。由安全小组对修复结果进行回归性测试和检查，确保漏洞成功修复。
恢复上线。待安全小组检查通过后，业务负责人再将网站、应用、服务器恢复上线。
安全总结。业务负责人整理本次安全事件的具体情况及补救措施，形成安全事故报告，将有关情况向领导和安全小组汇报。

9.3.4.4 存储/计算/制冷系统应急处理流程与故障诊断

故障处理流程如图9.26所示。

图9.26: 存储/计算/制冷系统应急故障处理流程示意图

9.3.5 集群维护日志与平台巡检记录

对于各个计算平台节点的故障维护记录均在seatable平台上进行，每个集群单独列表记录，如图9.27所示，记录内容包括：

故障节点编号与设备类型；
故障发生时间与解决时间；
故障类别与故障描述；
故障影响范围；
解决方法与解决方法描述；
记录人与审核人。

图9.27: 故障维护记录示意图

此外，对HPC+AI平台的巡检记录也在seatable平台上进行，巡检每日两次，如图9.28所示，内容包括：

室外冷水机组与冷却塔运行情况；
确认交换机、计算节点、存储节点、空调系统是否正常。

巡检记录每年按季度分为4个工作表，按年归档。

图9.28: 日常巡检记录示意图

9.4 信息公开

9.4.1 实时利用率TOP

实时利用率TOP网站，基于SLURM及文件系统信息，可以实时显示思源一号、π2.0集群、AI平台、科学数据存储的利用率状态，方便用户直观了解交我算的使用情况。站点支持中英文切换，还提供了当日、当周、当月的使用情况。为用户支持，集群策略调整，使用分析提供了依据。

图9.29为TOP网站的示意图。

图9.29: TOP网站示意图

9.4.2 集群状态

9.4.2.1 网站简介

除了实时利用率 TOP 网站，校级计算平台还搭建了高性能计算集群的实时监控平台，向用户展示高度可视化的集群运行信息，以下是一些突出的功能和亮点：

实时功率和电源使用效率展示：

网站向用户展示集群的实时功率使用情况，让用户能够实时了解超算集群的电力消耗状况。
网站通过直观的图表呈现电源使用效率（Power Usage Effectiveness，PUE）数据，反映了集群的电源使用效率，帮助用户评估能源利用效率（见图9.30）。

图9.30: 超算集群PUE和实时功率

队列状态一目了然：

网站提供了各个队列的实时信息，包括队列中的空闲节点数量和排队作业数。这有助于用户迅速了解当前计算资源的使用状况，以便更好地规划和提交作业（见图9.31）。

图9.31: 超算集群队列信息

节点级别的性能监控：

针对每个计算节点，网站提供了更详细的性能监控信息，包括 CPU 利用率和内存利用率。通过更精细的节点级别监控，用户能够更全面地了解不同类型计算节点的工作状态，从而更好地进行任务调度和资源管理（见图9.32）。
针对GPU计算节点，除了 CPU 利用率和内存利用率外，还提供了 GPU 利用率、GPU 温度和 GPU 功率等更加全面的监控信息。GPU 利用率展示了 GPU 设备的实际使用程度，让用户可以了解 GPU 资源的充分利用情况。GPU 温度和功率监控有助于实时追踪 GPU 设备的热力状况，提供关于设备运行状况更全面的信息（见图9.33）。
除了计算节点，监控页面还整合了对其他节点的监控，如用户公用的登录节点（见图9.34）和传输节点（见图9.35）。网站提供了这些节点的 CPU 利用率、内存利用率和网络 I/O 数据等监控信息，用户可以实时查看这些节点的运行状态，确保登录和传输等功能的稳定性。

图9.32: 计算节点CPU和内存利用率

图9.33: GPU节点实时状态

图9.34: 登录节点实时状态

图9.35: 传输节点实时状态

用户友好的可视化界面

Grafana 提供了丰富的图表和面板选项，使用户能够根据自己的需求自定义仪表盘，将复杂的集群数据以直观的方式呈现。集群状态网站充分发挥了 Grafana 可视化工具的强大功能，为用户提供了直观、交互式的监控体验，使复杂的集群数据以简单而又美观的方式呈现。

实时更新和告警功能

网站会定期更新监控数据，确保用户能及时获取到最新的数据，了解超算集群的实时状态。
针对超算集群的关键性能指标，网站设置了告警规则，在相关指标到达阈值时通知系统管理员，及时做出相应变更。

9.4.2.2 网站建设

监控平台总体架构

监控平台的的总体架构考虑了集群异地分布的特点，涉及的组件包括前端展示界面、数据存储和查询、数据采集、数据探针（见图9.36）。

前端展示：使用 Grafana 作为前端可视化引擎提供直观的操作界面，利用 Grafana 可以自定义仪表盘、图表的特性，可以将用户关心的数据、集群运行的关键数据展示在 Web 界面。
数据存储和查询：使用 Mimir 作为数据库系统，负责存储监控数据。Mimir 通过高效的存储和检索机制，可以支持快速的数据查询，为 Grafana 提供实时数据支持。
数据采集和汇聚：Prometheus 是数据采集与汇聚的中心，负责从各个节点的探针收集监控数据。由于超算集群分布在闵行、张江两地，但数据又需要统一展示，选择在两地分别设置次级 Prometheus 节点，负责搜集当地集群的监控数据，并进行初步的汇总计算。Prometheus 主节点则从次级监控节点上抓取核心数据和汇总计算结果。
数据探针：数据探针是部署在需要监控的节点的轻量级服务，可以收集性能指标和监控数据，例如 CPU 使用率、内存消耗、磁盘活动等信息。探针可以将收集到的数据转化为特定格式，提供给 Prometheus 采集。

图9.36: 监控平台架构

数据探针选取

Prometheus 官方提供的 Node Exporter 是一个常用的探针，可以提供有关系统整体性能、硬件指标、网络监控、文件系统的监控信息，例如CPU使用率、内存状态、磁盘空间、网络活动、I/O 统计等，可以满足大部分场景使用，计算节点主要部署的也是 Node Exporter 探针。
DCGM Exporter 是一种用于监控 GPU 节点的探针。它可以收集 NVIDIA GPU 的性能和健康指标，例如 GPU 利用率、显存使用、温度、电源使用等信息。GPU 节点可以部署 DCGM Exporter 探针，获取更全面的统计信息。
GPFS Exporter 是一个用于监控 IBM Spectrum Scale 文件系统（以前称为GPFS，General Parallel File System）的探针。该探针可以收集和 GPFS 文件系统有关的性能指标，例如空间利用率、inode 使用情况、 GPFS 读写速率、GPFS IOPS、GPFS 各 client I/O 速率等信息，有助于及时发现问题。
Prometheus 也支持用户自定义 Exporter，将特定应用程序、服务集成到 Prometheus 监控中。如果找不到适合某些特定服务的 Exporter，也可以自行编写相关程序，定期收集数据并暴露给 Prometheus。例如 Node Exporter 不支持整机功率的指标，这时就需要使用其他的 Exporter，或者通过 IPMI 等管理接口收集相关数据。

告警功能结合校级通知 API

在 Prometheus 主节点上配置的告警服务，可以在系统相关数据到达设置的阈值时触发告警。超算集群上配置的告警服务和“交我办”应用的通知 API 打通，可以在触发告警时通过手机 APP 以及短信通知系统管理员，让管理员可以及时了解集群变化并采取相关措施。