开放科学(资源服务)标志码(OSID)：

0 概述

高性能计算在国民经济建设和社会发展中发挥着不可替代的作用。2021年底，基于传统高性能计算的量子模拟技术打破Google量子垄断^[1-2]，意味着在未来一段时间内，传统超级计算机仍将是高性能计算的主要形式。目前，传统高性能计算已进入E级时代，更强的算力意味着更大的规模、更多的部件与更为复杂的子系统。E级高性能计算系统由数百万个部件组成，系统平均无故障时间从小时级降到分钟级^[3-4]，系统的实时监控与故障诊断变得越来越重要。

维护故障诊断系统是高性能计算机维护系统的核心，负责全机硬件系统的异常检测(包括故障检测，下文同)、故障诊断及故障预测。本文聚焦异常检测、故障诊断、故障预测3个方向的关键技术，结合实际工程需要设计一种支撑数E级规模的高性能计算机维护故障诊断系统，并部署在神威E级原型机系统上对关键设计进行实验验证，同时将实验结果与神威·太湖之光的故障诊断系统进行对比分析。

1 维护故障诊断关键技术研究

高性能计算系统维护故障诊断技术主要包括异常检测、故障诊断及故障预测3个方向。本节对3个方向的关键技术进行研究，以高性能计算系统对维护故障诊断系统的需求为目标，对相应算法进行适用性分析，最后确定在工程实践中能够取得实效的研发设计方法。

1.1 异常检测技术

异常检测的基本原理是定义数据所代表的物理意义在当前场景下所应该表现出来的特征，用算法分析当前数据是否有不满足正常特征之处，若有即为异常。

在对信息进行分析时容易发现多次采集的待分析数据信息汇集到一起具有时间序列特征，对时间序列数据的异常检测是数据挖掘领域的一个重要分支，其相关算法的思想可用于故障检测的设计。

目前，国内外学者对时间序列的异常检测方法的研究成果非常丰富，主要有基于统计^[5]、基于聚类^[6]、基于偏差^[7-8]、基于距离^[9]、基于密度^[10]、基于神经网络^[11-13]等算法。除深度学习靠样本训练外，其他算法均利用统计学知识计算特征值，只是针对不同的应用场景精度不同。各类算法判断异常的原理及适用性如表 1所示。

在实际工程化应用中，使用最多的是基于统计学的算法。腾讯织云metis在数据异常检测时就大量运用各种统计学算法，如3sigma算法、移动平均算法、带权重的移动平均算法、1/2/3次指数移动平均算法、奇异值分解算法、自回归算法等。百度运维针对不同数据业务场景设计数据检测算法时，也从数据的统计特征出发寻求解决之道，如将原始数据转换到相邻窗口均值变化比例空间，在该比例空间上设置阈值进而检测数据是否有突升突降。

在智能检测领域，腾讯织云采用取代传统阈值检测方式的无阈值智能监控学件，基于统计判断机制，用无监督和有监督学习联合检测时间序列，经海量样本训练出通用模型。

本文讨论的故障诊断系统运行环境是嵌入式系统，无论从资源占用角度还是效率角度，设计算法不宜过于复杂。基于统计的算法简单有效、执行迅速，对近似满足正态分布的一些指标是最好的选择；对系统内具有相似场景的指标数据，可以采用基于相似度的算法，但其计算量较大并且效率不高，应考虑利用统计学特征做差分，结合阈值进行检测；对于样本足够且可以用来训练模型的数据，在外部用神经网络训练好模型，放至嵌入式系统以提高效率。

1.2 故障诊断技术

故障诊断的核心功能是根因分析，需要在异常检测的基础上进一步明确故障类型、故障部位、故障原因，并把故障定位到实施修理时的可更换单元。

根因分析也是故障诊断的难点，国内外在该领域已经取得了许多有价值的研究成果，有基于图论的符号有向图(Signed Directed Graph，SDG)^[14-16]和故障树分析(Fault Tree Analysis，FTA)^[17-19]、基于专家系统^[20]、基于机器学习^[21]、基于模糊理论^[22]等。在此基础上，一些研究工作通过联合多种方式取得了更好的诊断效果，如文献[23]用专家系统和神经网络联合诊断，文献[24-25]用模糊petri网模型和故障树联合诊断等。表 2列出近年来使用最多、研究热度较高的3类方法的优缺点。

从实际应用情况看，基于故障树及专家系统的根因分析普遍取得很好的效果。利用机器学习获取异常事件之间关联关系进行故障诊断的方法，大都仍停留在实验研究层面。文献[27]介绍了某E级系统中使用机器学习方式支持故障诊断，但并未给出具体应用情况及实质性成果。智慧运维领域的云智慧研究院算法团队通过实验研究认为，在针对根因分析的各种机器学习模型中，由于各层信息的物理意义不明确，盲目运用到运维领域造成了诊断结果不可解释，认为脱离系统知识的机器学习方法学到的是事件的相关性而非因果性。文献[28-29]介绍了当前的机器学习学到的是事件相关性而非因果性，而相关性和因果性之间尚存在一定的鸿沟^[30-32]，主要原因在于当前的机器学习尚不具备逻辑性^[33-34]。云智慧研究院算法团队主张切忌以“智能”算法为基础进行根因分析方法的设计，对根因分析算法产品的设计思路要用运维的逻辑做支撑，抽象运维经验，将运维的排除故障经验自动化。

本文讨论的故障诊断系统处于维护系统内部，待分析的数据均为硬件信息及硬件配置参数，和系统软件应用相关的只有节点所处的作业队列信息，故障诊断关注的核心是关键芯片及器件的硬件问题。芯片器件大多历经几代研发改进，一些故障发生的根因已经经过芯片设计者、系统管理者及应用开发者联合诊断确认，所以根因分析最有效的手段首选基于专家经验，研发主体基于专家知识，以系统知识和运维知识为基础，充分学习领域专家在问题求解过程中所用到的结构知识、因果知识、行为知识，建立包含这些知识规则的较为完备的知识图谱。在某些特定问题上，通过对大量故障实例的机器学习，协助专家提取知识。针对诊断结论由反馈机制进行确认，而后通过特征提取生成样本，在样本累积到一定程度后用BP神经网络对该知识进行学习。

1.3 故障预测技术

故障预测是根据系统内发生故障时的大量历史数据特征，结合当前数据状态对未来一段时间出现故障的可能性进行预测。

故障预测的方法目前主要有基于模型、基于知识和基于数据驱动3种类型。基于模型的故障预测方法原理是将系统实际执行行为与模型描述的预期行为进行比较，通过发现明显行为差异来预测系统故障^[34]。基于知识的故障预测方法原理主要依据专家经验和知识进行定性推理，比如系统中某个异常故障的发生就预示不久的将来大概率会发生另一个更为严重的故障。基于数据驱动的预测方法利用系统大量离线数据对当前采样的在线数据进行分析处理，对未来一段时间的数据趋势进行预测或识别潜在故障。

模型、知识和数据驱动可以结合起来进行预测。文献[35-36]介绍了通过挖掘事件之间的关联，将故障预测过程转换为查找故障间是否存在关联规则的过程，用事件关联图来表示事件规则并预测故障事件。

基于以上3种方法的故障预测算法有灰色模型预测、隐马尔科夫模型预测、神经网络预测和支持向量机预测，这些算法可以混合使用，也可以为每种算法赋予不同权重后组合使用^[35]。在故障检测中用到的一些算法也可以用于故障预测，如对时间序列的分析算法结合滑动窗口进行预测。

在对故障预测的研究中发现，国内外研究文献对超级计算机系统倾向于使用各种日志进行预测，比如对基于日志记录中故障事件的时间与故障事件之间的关联性^[35]进行故障预测，或是根据日志记录中各类事件(包括故障事件和非故障事件)的分布特点进行故障预测^[37]。本文讨论的故障预测模块位于高性能计算维护系统内，本就处于底层，系统内有关硬件的日志信息来自维护本身，故障检测模块已经能够提供几乎所有信息，无须对日志进行重复挖掘。

文献[38]介绍了一种用于高性能计算机系统的故障预测方法。利用双数据源(环境状态数据和系统运行状态数据)通过计算互信息和距离来度量属性和类别之间的相关性，用SVM分类器确定最佳属性子集，用基于SVM集成数据流挖掘方法建立故障预测模型，最后基于实时状态样本预测结果，结合移动窗口判定预测节点运行状态。该方法用于本文讨论的环境中会有3个问题：1)属性和类别之间的相关性如果缺乏专家知识做指引会带来大量不必要的计算；2)故障预测模型的建立需要足够多的故障节点数据；3)预测模块运行在插件级平台上，数量达数万之多，如果预测模型准确率不够高，难免会报出大量无效信息，使得后续维护处理陷入无意义的消耗，甚至影响系统正常维护运行。

综上所述，为使故障预测在工程化应用中取得实效，本文联合运用基于模型、知识以及数据驱动的方式，采用以下两种实现方法：一是充分利用领域专家已知的预测知识建立模型或规则；二是以场景为导向，针对不同应用场景，对系统或部件大量信息数据表现出来的确定性行为规律进行知识提取，建立适用不同特定场景的多种模型。预测时间域的设置也要合理，过小过大都无意义，太小来不及后续处理，太大则期间可能发生其他因素的变化，会对预测结果产生偏离影响，要根据系统自身特征表现适当设置。

2 高性能计算机维护故障边缘诊断系统设计

针对高性能计算机的维护故障诊断系统，要具备较好的可扩展性，能够高效采集大规模系统中各种关键器件的运行状态、环境参数状态，全面检测并准确识别系统中的异常现象和故障，给出相对精准的诊断结论，辅助人工高效排查并解决问题，对系统中潜在故障能够及时准确预报。本文提出一种维护故障边缘诊断系统来满足数E级高性能计算机系统的以上需求。

2.1 可扩展的边缘诊断架构设计

维护故障诊断系统以软件开发为主，智能化只能在一定程度上促进局部高效性，硬件系统部件众多、结构复杂，诊断系统要实现异常故障的实时检测、诊断及预测，需要从总体架构开始进行系统级优化，结合全机维护系统硬件结构进行合理设计。

设计实现高效、高可扩展性的诊断系统总体框架，将其各功能模块的各个部分合理分布在维护系统内，分级管理是高性能计算系统中最为简洁有效的通用管理思想。

基于组装结构的维护系统整体硬件架构如图 1所示。左半部分为神威E级原型机系统的组装结构。众多节点位于不同的物理层次上，若干节点组成插件，若干插件组成超节点，若干超节点最后组成了系统。右半部分分级的维护系统依据组装结构分别在插件级、超节点级以及系统级实现硬件分级管理，发挥“超级管家”的功能。一级维护是插件级维护，向下直接面向多种底层关键芯片及器件，通过各种硬件协议获取底层硬件信息；二级维护为超节点级维护，是数据的汇集地及分散地，向下与若干插件之间进行高效数据交换，向上与三级维护进行数据交换；三级维护为系统级维护，是系统管理员及用户获取系统信息的接口，向下与二级维护之间进行数据交换。耦合硬件系统的这种分级架构实现层次化的维护架构，有利于支撑软件实现信息数据的高效传输，包括向上汇集以及向下分发。

基于以上三级维护硬件架构的特点，本文提出边缘诊断架构设计，将检测、诊断及预测的行为本地化，部署在获取相应硬件信息最近的地方。各功能模块按照执行效率及执行范围分布到各级维护的嵌入式系统上。对硬件数据的采集、插件级异常检测、插件级故障诊断及预测放在离节点最近的一级维护嵌入式系统上运行，超节点级异常检测、故障诊断及预测运行在二级维护嵌入式系统上，系统级跨超节点的检测、诊断、预测、系统级数据的应用以及用户接口均运行在三级维护嵌入式系统上，每一级维护嵌入式系统上都有各自的数据库，前两级维护中的数据同时汇入上一级数据库。维护故障诊断系统框架如图 2所示。

维护故障诊断系统框架的运行情况总体来看是一级维护层并行采集系统硬件信息，经过计算分析处理后，将各自结果并行发往各自的二级维护，二级维护层在完成本级分析汇总后将结果并行发往三级维护，三级维护层完成系统级分析后，综合一二级维护层的结果信息入库，最上层的管理员及用户可以随时从该数据库中获取整个系统的故障检测诊断及预测情况。理论上，用户获取整个系统信息的时间基本等同于直接访问第三级数据库的时间，系统运行效率与规模无关，具有较高的可扩展性。

2.2 系统总体流程设计

维护故障诊断系统总体结构及流程如图 3所示。

一级维护以10 s为周期进行采集操作，数据信息进入异常检测模块后，将可明确反映出异常及故障的数据交由异常检测规则库进行处理，规则库结合历史信息及系统配置信息输出明确的异常及故障信息；需要经过数据挖掘处理的关键异常信息，则由异常检测算法库调用相应算法进行异常及故障信息的检测，算法输出的异常及故障均为疑似异常和疑似故障。

确定性异常和疑似异常均需要经过异常过滤接口才能进入待诊断状态。异常过滤接口的作用是过滤掉不需要被诊断的异常，包含两种情况：一种是通过外部打标接口确认不需要关注的异常；另一种是已经被诊断过但因未被处理仍然在报的异常。

过滤后的待诊断信息进入故障诊断模块，故障诊断模块由故障诊断规则库、故障诊断推导树及专用神经网络故障诊断模型组成。

规则库和推导树均基于领域内专家知识图谱建立，规则库里故障及根因有比较明确的对应关系或经简单推理即可，推导树的逻辑比规则库复杂，要结合多种数据信息多次联合推导，诊断模块中会有若干故障推导树。

用于神经网络训练诊断模型的样本，部分来源于系统在模拟验证阶段的故障信息，其他则基于专家知识模拟，该模型在三级维护系统上训练，在一级维护系统上运行，系统内可以有多个诊断模型。

待诊断信息在经过规则库后，或者直接获取故障根因，或者根据规则库中的标记进入推导树或调用诊断模型。获取到故障根因后进入故障定位，故障定位的功能有3个：明确故障发生部件；根据对系统及应用的影响程度确定故障等级；结合根因结果定位可替换故障单元。

异常检测及故障诊断算法除了分布在一级维护上，还分布在二级和三级维护上。二级和三级维护系统上驻留的算法是利用各级结构知识和系统配置信息，分别进行中板级和系统级数据的对比检测、诊断。

故障预测算法驻留在一级维护系统中，针对几种场景设计，每隔1 min对库中当前时刻前3 min内相关数据进行计算。

结构信息、配置信息、采集信息、检测信息、诊断信息、预测信息均记入相应层级的数据库中，一级数据库中的信息会同时记入二级数据库，一级数据库保留两周内插件级的信息，二级数据库会同时记入三级数据库，二级数据库保留两周内中板级信息，三级数据库保留整个系统至少三个月内的信息。

1.2节中研究表明，通过机器学习进行故障诊断的方法目前大都仍处于实验研究阶段，本次维护故障诊断系统的设计目标要求设计内容在工程中取得较好实际效果，所以，通过机器学习建立模型的方式不是本次设计的主要选用技术，但因其具有较大的应用前景，本文系统中也做了一些设计为后续该技术的使用做准备，具体包括：1)以存储颗粒故障诊断为切入点，用神经网络进行模型训练；2)在系统级的三级维护数据库中，为探索神经网络方式进行异常检测及故障诊断保存积累样本，设计打标接口对样本故障根因进行反馈标注。

2.3 异常检测设计

异常检测模块对高性能计算机维护系统管理的所有芯片、部件的各种运行状态、环境参数进行周期性采集，运用规则算法对数据进行全面的异常及故障检测，过滤噪点及误报信息，提取比较确定的异常及故障信息。

在故障检测模块中设计若干异常检测算法，在调用算法前根据数据指标特征设计算法选择器，最后将得到的疑似异常进行过滤后提供给故障诊断子系统。过滤的方式初期主要依赖三级管理上的相应接口，该接口接受专业人员对异常进行确认标记，然后将标记发往一级维护，中后期对积累的带标数据建立规则或进行神经网络模型的学习，定期将过滤规则及模型更新至一级维护。

具体到异常检测算法设计，虽然异常数据检测有各种理论支撑的多种技术手段，但在高性能计算硬件系统异常检测领域，执行效率尤为重要，需考虑庞大的处理信息，以及对维护系统计算资源的消耗，算法的设计不宜复杂。所以，本文设计中仍围绕被实践证明落地有效、执行效率最高的专家知识设计，以及用各种理论支撑的算法辅助实现专家知识算法化、智能化。

异常检测的首要工作是确定被采集的指标向量。例如环境参数指标向量应包括各级温度、电压、电流、板级漏水等，针对关键芯片器件的指标向量应包含各种反映其运行情况的寄存器信息，针对系统内一些嵌入式系统的指标向量应包含其关键服务的运行状态、服务响应时间、CPU使用率、内存占用率、日志增长速度、磁盘占用率等。由于硬件信号质量问题及错误状态瞬时性特点，异常很难被采集到，软件手段的检测只能不断接近，永远无法做到真正意义的全面检测，这是异常检测的难点。

为提升检测的全面性及准确性，与上一代故障诊断系统相比，主要增加的设计方法有以下5点：

1) 通过硬件设计实现密集数据采集。增加信息采集次数能够获取更多的信息，是提升检测全面性及准确性最直接的手段。目前系统内采集周期为10 s，不宜再通过软件的手段直接缩短采集周期，原因主要有：采集程序所在嵌入式平台上运行的服务较多，采集程序频繁采集数据会影响关键服务的服务能力；后续的检测诊断等信息要在采集周期内完成，需要留足够的时间。本文设计提出由底层硬件进行适当的缓冲设计，硬件每隔1~2 s将自身关键信息进行自动保存，在软件采集时，一次性将软件采集周期内缓存的若干数据送出。

2) 滤除毛刺，提升检测准确率。为追求简单和效率，高性能计算系统内通常用恒定阈值的方式检测异常，硬件信号噪点或毛刺也会引起单点阈值异常。为解决上一代检测系统出现的误报问题，设计以下2种方式：

(1) 多指标联合判断。认为系统中一个真正的异常及故障必然会引发或伴随其他与之相关的异常，对检测出的某异常指标，结合必然受其影响的指标或与其有较强相关性的指标校验结果，如果该指标异常是唯一异常，即认为本次数据为误报。

(2) 推迟判断。在前面周期内检测到异常时先打标记，若后续若干周期内检测到异常的次数超过n，则记为异常，否则忽略掉。

上述两种方式按照指标误报的特点可单独使用，在某些情况下，必须结合起来使用才更准确全面。比如，在检测出某芯片电压数据单点超阈值后，用第1种方式等待芯片其他指标的异常检测算法调用完毕后联合判断，如果其他指标均正常，那么判断该单点电压异常就被忽略掉，因为该电压并没有引发任何芯片异常，芯片依然在正常运行中，随后的周期内第1种方式均做出忽略该异常的判断。但同时第2种方式也在随后周期内检测到电压数据异常次数超过n，那么这个频频误报的电压异常现象就不应该被忽略，因为很可能意味着电源芯片中存在问题，其流程如图 4所示。

3) 建立关键部件的故障树。故障树是专家知识最集中的体现，主要由负责硬件设计专家及运维专家共同构建。系统为所有待检测部件按类构建各自的故障树。故障树的根是该硬件的总体状态，节点由该硬件配置参数、反映该硬件各级部件的记录故障情况和运行状态情况寄存器组成。故障树能实现对硬件器件的快速异常检测，从器件总状态到具体部件状态，再到部件内某类异常甚至某子类异常。与上一代仅对处理器芯片建立故障树相比，减少了其他器件大量冗余信息的采集，提高了处理效率，检测系统的逻辑结构也更为清晰。故障树异常检测算法在定义好树根之下各节点之间的关系后，则树形查找的算法本身非常简洁。

4) 利用系统结构信息和配置信息带来的数据关联性进行异常检测。这也是本文设计与上一代诊断系统相比新增加的设计。在高性能计算机系统中，每个部件都有大量同类，本文提出如下异常检测理论：如果数据来自生存环境类似或者使用场景类似的同类部件，那么反映这些部件相应特征向量的数据具有近似性。例如，位于同一冷板下并运行同一个作业的CPU芯片的温度值和功耗值理论上应该接近，如果某个芯片温度或功耗明显较高，就被检测认为疑似异常。

除了对相同系统结构以及相同配置下的数据进行类比检测外，系统中还对具有明确预期的场景，保存其正常状态数据建模，用于与实际相同场景下的数据进行类比，比如保存某特定类型课题跑题时的特征观测向量的数据，在系统中再次运行该类型课题时，采集到的相应数据应该与保存的数据具有近似性。

该类算法设计也非常简洁，只要计算待检测数据与同类该数据的期望之差，对差值调用阈值判定即可。

5) 维护嵌入式系统的异常检测。维护嵌入式系统是整个维护软件系统运行的主要平台，该平台主要有负责系统开工及实现各硬件维护接口的维护服务、故障检测、诊断、预测、各种驱动及固件、数据库、文件更新引擎以及各种守护进程，平台的异常和故障对系统影响重大，所以在这一代故障诊断系统中加入对维护嵌入式系统的异常检测设计。维护嵌入式系统的异常检测指标依据实际需求设定，包括关键服务程序及文件的版本检查、各程序的响应速率、各种日志增长速度、系统网络通信状况、CPU及内存使用率、磁盘占用率等。

维护嵌入式系统主要用到两类异常检测算法：

(1) 响应速率类指标的异常检测算法。先计算周期性采集信息中发出命令包和收到返回包之间的时间间隔，然后按平稳性数据异常检测算法即多次均值超阈值来上报异常，算法流程如图 5所示。对连续三次扫描的响应时间取均值，将响应时间从T空间转换到E空间，q为阈值，E空间值大于q，上报响应速率异常。

(2) 增长速度类指标的异常检测算法。将每次取得的数值与前一次求差值，将其转换到新的空间，然后在该空间用平稳性数据异常检测算法上报异常。

异常故障检测子系统报出的所有非确定性异常需要再次经专家打标过滤确认后，才能提供给故障诊断模块。

2.4 故障诊断设计

故障诊断模块对故障检测模块中输出的确定性异常及故障进行定位、根因分析、确定故障等级。故障定位明确出异常和故障发生的部件位置，根因分析挖掘异常和故障的根本原因，故障等级对异常故障在部件或系统中造成影响的轻重程度进行定性。本文讨论的故障诊断系统仍属于在线诊断范畴，对于一些需要借助万用表、示波器等仪器进行信号质量测量和需要交叉定位的故障，仅能根据数据现象给出中间性诊断结论。

故障定位的信息一般情况下已经包含在故障检测信息中，异常和故障是从哪里采集并检测到的，诊断系统仅需提取相应位置即可。

确定故障等级可以从多角度划分，高性能计算领域一般倾向于按照对作业的影响程度划分。上一代故障诊断系统分为三类故障：不影响作业运行为一级故障，影响部分作业运行为二级故障，所有作业均不能运行为三级故障。在实际使用中，专业人员希望从故障等级上更直观地获取信息，本文设计中将故障等级分为六级：一级故障，作业运行过程中发生的各种异常告警；二级故障，作业运行过程中发生的可纠错；三级故障，作业运行中的偶发错，作业再次运行后故障有可能不会再现；四级故障，影响个别作业，一般是芯片的某部件故障，只有用到该部件的作业会被影响，其他作业不受影响；五级故障，影响经过该故障单点的所有作业；六级故障，影响面较大，发生后，如果不立即处理，会影响其他点正常运行，甚至所有作业都无法进行，如漏水、掉电、堵网以及导致本级维护系统挂死等。这种划分方式专业度较高，需要对故障本身有深入的认识。

在上一代基础上，根因分析功能增加了故障推导树，主要有以下3类：

1) 以原因比较复杂的故障现象为根，如堵网故障推导树等。

2) 以部件为根，如某核心芯片故障推导树、某器件故障推导树、某板级故障推导树。

3) 以指定诊断角度为根，如性能异常推导树、物理环境异常推导树、系统级异常推导树等。

故障推导树可以自动诊断分支较多、原因复杂的故障，并接受外部打标的带目的性的诊断请求。

一级、二级、三级管理中均增加了结合系统结构及系统配置信息的故障诊断设计，其流程如图 6所示。算法思想是：如果在对结构信息及配置信息数据进行聚类后的结果中，某配置信息聚类结果与某指标对故障点和正常点的分类一致，那么该配置项大概率就是该指标异常的根因。例如在全机范围内检测到多个点的某同一指标异常，通过算法结合配置信息后，发现这些异常属同一个器件的同一个生产批次，那么诊断意见就是该批次器件质量问题；再如，异常现象为系统中若干网络端口的某寄存器均发生溢出，算法结合系统结构信息，发现这些网络端口均与网络中某异常网络插件相连，那么这些网络端口异常的诊断意见就是由该网络插件的异常所导致等。

本次故障诊断设计中增加了神经网络的诊断方式，考虑到系统内存储颗粒因为其数量巨大，相对而言在系统中的故障率不算低，影响也比较大，设计使用神经网络的方式对存储颗粒故障进行诊断具有实践价值。系统内节点众多，每个节点均有数十存储颗粒，颗粒上的故障根因有可能是计算节点的问题，也有可能是颗粒本身的问题，或者是颗粒附近参考电压的问题，具体是哪路参考电压则和颗粒的位置相关。在该问题上维修反馈的信息显示，专家诊断结果的准确率约为75%，故设计使用神经网络的方式，理论上结合正确标签样本的训练模型能提高对存储颗粒故障诊断的准确率。设计中依据专家诊断存储颗粒根因的经验知识，选取相关寄存器及颗粒位置形成若干输入特征向量，结合几种可能的根因标签补充样本，再加入返修打标的实际故障样本(返修会按有效返修手段标注根因，该根因有可能和返修前的诊断意见并不一致)进行分类器模型训练，训练好的模型可以直接用于颗粒故障诊断。

2.5 故障预测设计

故障预测模块在系统正常运行的情况下，通过对来自检测模块的历史数据进行持续分析，对未来一段时间内系统发生故障的可能性和发生故障的类型进行预判。其现实意义是在系统发生故障前，通过提前调度等预防措施，避免故障的发生或者降低故障发生带来的系统资源损失。

故障预测是维护故障诊断系统中新加入的功能。根据第2节研究结果，设计了寻找指标数据周期性及趋势性的算法，利用周期性及趋势性对指标进行预测。提高预测准确率是该故障诊断系统的首要设计目标。预测子系统的主体部分是针对一些专家已知的预测知识建立规则，对常用的场景建立预测模型。例如系统在进行专业测试时，对不同规模资源的正常功耗曲线进行建模，利用获取的数据计算实时功耗，进行曲线拟合，发现异常即进行预测报警。

为使故障预测取得更多更好的实际效果，主要设计了2种预测算法：

1) 基于数据的趋势性进行预测。算法持续对时间间隔t内采集到的数据计算均值$ \overline{{x}_{1}} $、$ \overline{{x}_{2}} $、…，检测到均值的增长趋势后，开始计算增长速度，然后计算在该速度下超报警阈值的时间。

2) 基于已知的故障模型进行预测。如图 7所示，该算法针对某场景预测s时间后将发生某故障，算法首先要对该场景的故障现场进行建模，如果故障时间为f时刻，建模选取f-s时刻前的一段t时间内的数据，保存其变化曲线。在预测时，将实际运行中t时间内数据的变化曲线与保存的变化曲线进行相似度对比，在发现较高相似度的周期中，预报s时间后会发生故障。

3 实验验证

本文实验部分用到两个环境，分别为神威·太湖之光及神威E级原型机，其中神威E级原型机为主要实验环境。在该E级原型机上，对上一节给出的边缘诊断系统进行了实验和验证测试，并与神威·太湖之光维护故障诊断系统进行了比较。

神威·太湖之光(下文简称太湖之光)超级计算机是由国家并行计算机工程技术研究中心研制，安装在国家超级计算无锡中心的超级计算机。太湖之光超级计算机峰值性能达到125.436 PFLOPS，系统内有160个运算超节点，每个超节点有32块插件，每个插件上有8个运算节点，系统由40 960个运算节点构成。插件上BMC系统仅提供基础维护服务及数据采集，诊断系统驻留在维护管理服务器上，由维护管理服务器发起对指定目标的诊断流程。

神威E级原型机(下文简称E级原型机)部署在国家超级计算(神威)中心，是继神威蓝光、太湖之光之后神威家族的第三代计算机，该计算机作为一台E级计算机的原型机，峰值性能为3.13 PFLOPS。系统由512个运算节点构成，运算节点为双节点结构。E级原型机采用层次化的组装结构，维护故障诊断系统按照本文设计的架构部署。一级维护分布在256块插件上，每个插件负责2个运算节点，二级维护由4个超节点维护板组成，每个超节点维护板负责64个插件，三级维护是一台2.2 GHz、40核、256 GB内存、千兆以太网48T磁盘的维护管理服务器，与4个二级维护交互信息。

3.1 总体架构实验

在E级原型机系统及太湖之光上，设计如下两个实验：

1) 实验1目的是观察该维护诊断架构在E级原型机上的执行效率。

在E级原型机系统上，针对系统中256个一级维护，在每个一级维护所负责的4个运算节点上随机挑选两个节点，进行人为造错，在三级维护上观察并记录异常检测及故障诊断的耗时为0.83 s。

在太湖之光系统中选取同样结构的1 024个运算节点，用同样方法造错，结果显示耗时为21.4 s。

造成以上响应时间差异的根本原因在于：太湖之光的检测及诊断信息是从第三级管理服务器上逐级向下分发多线程，对每个节点执行检测及诊断流程。在诊断流程的执行过程中，底层的维护服务会因为硬件故障的存在导致响应时间过长，甚至只能等到超时返回，这些时间也都直接反映到了三级维护对故障诊断的响应时间上。除了流程耗时外，信息通过网络传输也需要耗时。而第3节的总体架构设计将最耗时的故障诊断功能分散在最接近底层的一级维护系统内，一级维护并发进行周期性及时诊断，将数据及时发往二级和三级维护数据库从而保证在任何时刻，三级维护数据库中均为系统最近一个周期内的信息。用户或管理员直接从第三级数据库中即可迅速获取系统最新信息。

2) 实验2目的是评估该维护诊断架构在十万节点系统上的执行效率。

根据E级原型机的结构组成，如果系统中有十万个节点，按照每个一级维护负责4个节点，每个二级维护对应64个一级维护来计算，系统中将会有大约25 000个一级维护，约400个二级维护。

十万节点系统与E级原型机系统关系如图 8所示。

从图 8可以看出，从一级维护开始执行检测及诊断行为到结果送至三级维护数据库，十万节点系统与E级原型机系统的主要差别在于t₃时段，t₁和t₂时段均为并发执行，几乎与规模扩展无关。

本文设计以下实验对比4个二级维护与400个二级维护t₃的时间差异。

因E级原型机与太湖之光均不具备400个二级维护的条件，选择模拟实验在太湖之光环境中选取400个插件，将二级维护服务程序下沉到一级维护的嵌入式系统内，由400个一级维护模拟二级维护，各自将256条二级维护信息发往三级维护，记录耗时为4.26 s。

同样实验环境，依次模拟4、64、128、256以及512个二级维护，耗时分别为1.93、2.19、2.57、3.11及5.07 s。

不同二级维护规模诊断信息汇入三级维护数据库的时间变化趋势如图 9所示，据此可推测该架构应用于数E量级的系统，检测诊断时间应小于10 s，说明该架构具有较好可扩展性。

实验数据显示，十万个节点(对应400个二级维护)系统中t₃值仅比1 024个节点(对应4个二级维护)的系统多耗时数秒。对十万个节点系统进行检测及诊断的执行效率做如下估计：因为t₁和t₂与规模扩展无关，借用实验1的数据0.83 s，得出t=t₁+t₂+t₃=0.83+4.26=5.09 s，说明在一个执行周期(10 s)内，十万个节点信息完全能够在三级维护数据库中更新完成。而用户通过访问三级维护数据库获取这些信息的时间远小于t。据此推论，该架构如果应用于十万个节点系统中，获取最新检测及诊断信息的时间在10 s内。

在太湖之光上对上万节点(大约50个二级维护)系统维护耗时达数分钟，新的架构将该性能提升了数百倍。

3.2 算法实验

本节算法实验环境均为E级原型机系统。

1) 过滤误报算法

实验选用一块电源芯片，固件更换为在调试验证阶段发现有bug的版本，对由其供电的节点进行开工跑题，分别使用无过滤误报算法及有过滤误报算法进行异常检测，观察24 h内的电压数据的变化。实验结果如下：无过滤误报算法异常数据为107，有过滤误报算法异常数据为0。实验结果表明，设计的分段均值异常检测算法对此类误报数据的特征具有很好的识别性。

在太湖之光环境中统计调试验证阶段半年内信息结果显示，在检测记录的异常信息中，电源类误报信息占3.3%。从实验结果可以推测，过滤误报算法几乎可以消除全部该类误报信息，认为该类误报率几乎为0。

2) 维护嵌入式系统异常检测算法

实验在E级原型机所有板级维护嵌入式系统上部署该算法，观察期为1个月。实验结果如表 3所示。

实验结果表明，维护嵌入式系统异常检测算法能够及时发现维护嵌入式系统的各类常见问题，并准确定位根因，问题的主动发现及解决成功避免了因维护系统自身的问题导致的维护信息损失。实验结果同时表明，应将该维护嵌入式系统的故障等级升至最高级别，促使运维人员及时对其进行处理。

该算法对硬件故障诊断覆盖率的贡献如下：对太湖之光半年内的诊断信息进行统计，由维护嵌入式系统引起的故障占硬件总故障的4.2%，该算法将硬件系统故障诊断覆盖率提升约4%，同时统计显示维护嵌入式系统的故障在全部硬件故障中占比为5.9%，该算法亦将硬件系统故障检测覆盖率提升约6%。

3) 类比故障诊断算法

实验在一级、二级和三级管理上部署类比故障诊断算法，在近六周的时间内，记录主要有3例，如表 4所示。

实验结果表明，类比故障算法有效解决了和系统结构及配置信息相关的问题，提升了系统诊断效率。

该算法对硬件系统故障诊断覆盖率的贡献如下：对太湖之光半年内的故障信息进行统计分析，太湖之光维护故障诊断系统硬件系统故障诊断覆盖率为71%。针对未能给出诊断结论的部分，通过同类对比可以得出诊断结论的占比超过65%。据此认为，类比故障诊断算法可以将硬件故障诊断覆盖率提升约19%。

4) 专用模型对比预测算法

实验中的预测算法专用场景介绍：针对在运行某特定课题时，系统中某一组指标F{f₁，f₂，f₃}出现特定变化趋势后，大约3 min后会发生节点故障，进而导致正在运行的应用课题被中断。

算法记录三项指标f₁、f₂、f₃在故障发生3 min前的18个扫描周期内的数据信息$ {M}_{1}\{{d}_{0}, {d}_{1}, \cdots , {d}_{17}\}，$ $ {M}_{2}\{{d}_{0}^{\mathrm{\text{'}}}，{d}_{1}^{\mathrm{\text{'}}}, \cdots , {d}_{17}^{\mathrm{\text{'}}}\}，{M}_{3}\{{d}_{0}^{″}, {d}_{1}^{″}, \cdots , {d}_{17}^{″}\} $。

在实验环境中选取64个节点运行该课题，如图 7所示，每经过18个扫描周期，用相应的数据与M₁、M₂、M₃计算差值，并在差值空间计算方差。3个指标方差均小于阈值就报在3 min后即将发生某故障，否则无信息入库。

以上实验运行5次，实验部分结果如表 5所示。

该预测算法具有很强的针对性，通过多次实验找到了能准确预报故障的阈值，证明了该算法的有效性。及时预测使得课题能够迁移相关作业，避免了课题运行中断。

5) 趋势判断算法

在实验环境中选取10个节点，运行专门编写的高功耗课题引起关键芯片温度持续升高，部署趋势判断算法对温度趋势进行计算，并调用预测知识规则，当判断芯片温度在30 s后超预警值时做出预警。

实际温度超阈值时间如图 10所示。

6) 机器学习有关实验

实验环境为E级原型机系统，实验根据E级原型机系统中的颗粒故障根因的分类设置7个根因标签，依据专家诊断存储颗粒根因的经验知识，选取相关寄存器及颗粒位置形成11个输入特征向量，创造大约二十万个样本，再加入返修打标的实际故障样本进行两层中间层的分类器模型训练。

实验结果显示，训练出的模型在测试样本上取得了99.2%的准确率，尤其是能被专家知识准确诊断的样本均完全正确。由于实际故障样本本身数量不大，利用专家知识创造样本的程序借用算法优势轻松地穷举出了专家知识能覆盖的样本集合，因此模型可能存在过拟合问题。同时，如果专家规则并不算太复杂，系统中该类故障也并不多，在该具体的点上很难证明利用机器学习比用专家规则高效多少。

7) 总体效果评价

从E级原型机上的验证结果可以看出，基于专家知识的检测、诊断、预测算法均取得预期效果。

本文设计的故障诊断系统与太湖之光系统相比提升情况如表 6所示。

在表 6中，太湖之光的故障检测误报率、硬件系统故障检测覆盖率及诊断覆盖率均为半年内历史数据的统计结果，本文设计的故障诊断系统中以上3项指标值均为估算值。

异常检测覆盖率及故障诊断覆盖率的提升得益于设计中加入的关联性分析及对维护嵌入式系统自身的检测及诊断。覆盖率的提高直接提升了系统的检测效率及诊断效率，故障诊断的过程也解放了人工分析，进一步提升了诊断效率，故障预测也能够比较准确地预报重点监测的指标及几种关注的场景。

4 结束语

维护故障诊断系统是高性能计算机系统的重要组成部分，高能性计算即将进入后E时代，维护故障诊断系统的作用越来越突出，传统机制的执行效率及准确率和覆盖率需要进一步提升以满足需求。本文面向E量级高性能计算系统需求，对可扩展的高效维护故障诊断系统进行研究及设计。实验结果表明，本文设计的维护故障诊断系统在运行性能上可满足十万节点规模系统，在功能实现上，设计的融合系统结构及专家知识的检测、诊断及预测算法均达到了预期效果，执行效率、准确率及覆盖率均取得较大提升。近年来，AIOps作为更高效的工具逐渐成为运维领域的首要选择^[39]，高性能计算机硬件的维护故障诊断也将趋向人工智能化。后续将研究智能手段与专家知识深度融合的技术，找到更好更多的融合切入点，进一步提升维护故障诊断系统的准确率及覆盖率，并在故障诊断的基础上实现部分故障自愈功能，提高维护故障诊断系统的智能化程度。