End-to-end I/O Monitoring on a Leading Supercomputer

摘要

本文旨在克服生产系统I / O性能监控的复杂性。我们为40960节点的Sunway TaihuLight超级计算机设计了Beacon，一种端到端的I / O资源监控和诊断系统，目前排名世界第三。 Beacon同时收集和关联来自所有计算节点，转发节点，存储节点和元数据服务器的I / O跟踪/分析数据。借助积极的在线+离线跟踪压缩和分布式缓存/存储等机制，它可在生产环境中提供可扩展，低开销和可持续的I / O诊断。从系统级监控数据重建更高级别的每应用程序I / O性能行为，以揭示系统性能瓶颈，利用率问题和应用程序行为之间的相关性。 Beacon进一步为用户和管理员提供查询，统计和可视化实用程序，无需任何代码/脚本修改即可进行全面深入的分析。

通过在TaihuLight上部署大约18个月，我们展示了Beacon在I / O性能问题识别和诊断方面的实际用例的有效性。 它成功地帮助中心管理员识别出设计或配置缺陷，系统异常发生，I / O性能干扰以及资源不足或过度配置问题。 已经修复了一些暴露的问题，其他问题目前正在解决。此外，我们通过最近监控互连网络的扩展来证明Beacon的普遍性，这是超级计算机的另一个争论点。 Beacon代码和部分收集的监测数据均已发布

介绍

现代超级计算机是具有越来越深的存储层次结构的网络系统，为不断扩展的规模和复杂性的应用程序提供服务。 从存储介质到应用程序的长I / O路径，结合复杂的软件堆栈和硬件配置，使得I / O优化对于应用程序开发人员和超级计算机管理员来说都越来越具有挑战性。 此外，由于I / O使用了大量共享的系统组件（与计算或内存访问不同），因此通常会受到大量的工作负载间干扰，从而导致高性能差异。

非常需要能够捕获/分析I / O活动和指导优化的在线工具。 他们还需要提供I / O使用信息和性能记录，以指导未来系统的设计，配置和部署。 为此，已经开发了几种分析/跟踪工具和框架，包括应用程序端（例如，Darshan和ScalableIOTrace），后端端（例如，LustreDU，IOSI和LIOProf），以及多层工具（例如， 模块化Darshan和GUIDE）。

然而，这些提出的工具受到以下一个或多个限制。 面向应用程序的工具通常要求开发人员检测其源代码或链接额外的库。 它们也没有提供直观的方法来分析应用程序间的I / O性能行为，例如干扰问题。 面向后端的工具可以收集系统级性能数据并监控跨应用程序交互，但难以识别特定应用程序的性能问题以及查找其根本原因。最后，发出效率低下的I / O请求的有问题的应用程序依赖于高带宽应用程序的后端分析方法[50,52]的雷达。

-本文报告了我们为TaihuLight设计的轻量端端I / O资源监控和诊断系统Beacon的设计，实施和部署，目前是世界第三的超级计算机[75]。 它适用于TaihuLight的40,960个计算节点（总数超过一千万个核心），288个转发节点，288个存储节点和2个元数据节点。 Beacon将前端跟踪和后端分析集成到一个无缝框架中，支持诸如自动每应用程序I / O行为分析，I / O瓶颈/干扰分析和系统异常检测等任务。

据我们所知，这是第一个采用超大规模超级计算机的系统级多层监控和实时诊断框架。 Beacon同时从不同类型的节点（包括计算，I / O转发，存储和元数据节点）收集性能数据，并协同分析它们，而无需应用程序开发人员的任何参与。 其精心设计的收集方案和积极的压缩可最大限度地降低系统成本：仅有85个兼职服务器可监控整个40960节点系统，用户应用程序的性能开销<1％。

自2017年4月起，我们已将Beacon用于生产用途。它帮助TaihuLight系统管理和I /

O性能团队确定了几个性能下降问题。凭借其丰富的I / O性能数据收集和实时系统监控，Bea- con成功地揭示了应用I / O模式与广泛采用的底层存储设计/配置之间的不匹配。为了帮助应用程序开发人员和用户，它可以实现详细的每个应用程序I / O行为研究，以及新颖的应用程序间干扰识别和分析Beacon还执行自动异常检测。最后，我们最近开始将Beacon的I / O扩展到网络交换机监控。

根据我们的设计和部署经验，我们认为拥有这种端到端的详细I / O监控框架是一种非常有益的做法。 Beacon的全系统级监控将其与语言，库或编译器约束分离，从而为所有应用程序和用户提供监控数据收集和分析。它的大部分基础设施都重用了现有的服务器/网络/存储资源，事实证明它可以带来可忽略不计的开销。作为交换，用户和管理员深入了解复杂的I / O系统组件的操作和交互，并节省人力资源和机器核心小时浪费在不必要的缓慢/抖动I / O或系统异常上。

背景

图一：TaihuLight及其Icefish存储系统架构概述。 Beacon使用底部显示的独立监控和管理以太网网络。

我们首先介绍了TaihuLight超级计算机（及其Icefish I / O子系统），我们在那里进行了实施和部署。虽然我们的其余讨论将基于这个特定的平台，但Beacon的设计和操作的许多方面可以应用于其他大型超级计算机或集群。

TaihuLight是目前世界第三的超级计算机，一个多核加速125千万亿次浮点运算系统[36]。图1说明了其架构，突出了Icefish存储子系统。40,960个260核计算节点组织在40个机柜中，每个机柜包含4个超级节点。通过双轨FDR

InfiniBand，一个超级节点中的所有256个计算节点都完全连接，然后通过Fat-tree网络连接到Icefish。此外，Icefish还提供具有Intel Xeon处理器的辅助计算集群（ACC），主要用于数据预处理和后处理。

Icefish后端采用Lustre并行文件系统[26]，在288个存储节点和144个Sugon DS800磁盘盒之上的总容量为10 PB。机箱包含60个1.2 TB SAS HDD驱动器，组成6个OST，每个OST为8 + 2 RAID6阵列。每个机箱内的控制器通过2个光纤通道连接到两个存储节点，以实现路径冗余。因此，每个存储节点管理3个OST，而共享控制器的两个相邻存储节点形成故障转移对

计算节点和Lustre后端之间是一层288个I / O转发节点。 每个都扮演双重角色，既作为基于Gluster [6]服务器的LWFS（轻量级文件系统）到计算节点，也作为Lustre后端的客户端。 这种I / O转发实践被多个其他平台采用，这些平台以这样的规模运行[15,28,54,78,90]。 转发节点提供2.5 GB / s的带宽，整个转发系统的带宽超过720 GB / s。 每个后端控制器提供大约1.8 GB / s，相当于大约260 GB / s的文件系统带宽。 整体Ice-fish分别为读取和写入提供240 GB / s和220 GB / s的聚合带宽。

TaihuLight于2016年6月在Top500排行榜上首次亮相。在本研究期间，Icefish同样被划分为两个名称空间：Online1（针对日常工作负载）和Online2（保留用于占据大多数计算节点的超大规模作业），具有不相交的转发节点集。批处理作业只能使用任一命名空间。来自计算节点的I / O请求由指定的转发节点使用静态映射策略提供服务，以便于维护（ACC的48个固定转发节点和Sunway计算节点的80个固定转发节点）。因此，两个名称空间以及静态分区的后端资源当前由例行作业和“VIP”作业单独使用。部署端到端监控系统的一个动机是分析整个超级计算机工作负载的I / O行为，并设计更灵活的I / O资源分配/调度机制。例如，在我们的监控系统的发现的推动下，已经开发了用于更好地转发资源利用的动态转发分配系统[43]并且进行了测试部署。

Beacon的设计与实现

Beacon 的架构概述

图2概述了Beacon在Icefish I / O架构之上的工作原理，该架构旨在以不同的分布级别运行，以实现可扩展性和易管理性。 Beacon在所有五个Icefish组件上执行I / O监控：LWFS客户端（在计算节点上），LWFS服务器和Lustre客户端（在转发节点上），Lustre服务器（在存储节点上）和Lustre 元数据服务器（在元数据节点上）。 在每个监控点，Beacon部署轻量级监控守护进程，从而在本地收集与I / O相关的事件，状态和性能数据，然后传输数据以进行聚合。 在所有计算节点上进行积极的首次通过压缩，以实现有效的每应用程序I / O跟踪收集/存储。

图2：Beacon的主要组件：监控点的守护进程，分布式I / O记录数据库，作业数据库以及专用的Beacon服务器。 箭头进出模块的宽度不同表示数据压缩。

Beacon将其主要的后端处理和存储工作流分配到其节点本地磁盘上的部分存储节点，利用硬件资源和并行性。 为此，Beacon将40,960个计算节点划分为80个组，并将288个存储节点中的80个与每个计算节点进行通信。 另外两个存储节点用于从转发节点收集数据，另一个用于存储节点，另一个用于MDS。 这些84个“兼职”服务器（图2中显示为“N1”到“N84”）一起称为日志服务器，它们托管Beacon的分布式I / O记录数据库。 考虑到Icefish的峰值监控数据处理工作量，这些服务器的数量是根据经验选择的。

这些日志服务器采用基于成熟的开源框架的分层软件架构。它们通过Logstash [9]收集与I / O相关的事件，状态和性能数据，Logstash是服务器端日志处理管道，用于同时从多个源中提取数据。然后将数据导入Redis [16]，这是一种广泛使用的内存数据存储，充当缓存以快速吸收监视输出。持久性数据存储和后续分析是通过Elasticsearch [5]完成的，这是一个支持NoSQL数据库的分布式轻量级搜索和分析引擎。它还支持高效的Beacon查询，用于实时和离线分析。

另外一个存储节点（图2中的N85）用于托管Beacon的作业数据库（使用MySQL [11]实现），该数据库与作业排队系统交互并跟踪Beacon获得的每个作业信息。

最后，Beacon使用专用的Beacon服务器处理并向用户（系统管理员或应用程序用户）呈现其监控结果。它定期执行两种离线数据分析：（1）第二次通过节点间压缩，通过比较和组合运行相同作业的计算节点的日志，进一步消除数据冗余，以及（2）提取和缓存MySQL使用SQL查看每个作业的统计摘要，同时在Redis中生成和缓存常见的性能可视化结果，以方便用户快速响应。在两次压缩之后，使用Elasticsearch在此专用Beacon服务器上永久存储日志和监视数据。考虑到典型的每日数据采集大小为10-100 GB，其120 TB RAID5容量远远超过了系统的终身存储空间需求。

图3：Beacon网络界面的示例显示：（a）一个用户作业的跨层读/写带宽，（b）三个OST的带宽，这些OST被识别为经历异常。

在其Elasticsearch-MySQL-Redis堆栈之上，Beacon的Web界面为用户提供了友好的GUI，用于I / O相关的作业/系统信息查询处理和可视化。 例如，应用程序用户可以在整个I / O路径上查询基于作业ID的程序I / O行为的总结，以帮助诊断I / O性能问题; 系统管理员可以监控所有转发，存储节点和元数据服务器上的实时负载级别，从而促进未来的作业调度优化和中心级资源分配策略。 图3显示了相应的屏幕截图。 第4节提供了具体案例研究的更多细节。

Beacon实体之间的所有通信都使用低成本，易于维护的以太网连接（图1中以绿色标记），与主计算和存储互连分开。

多层I / O监控

Compute nodes   在40,960个计算节点中的每一个上，Beacon收集LWFS客户端跟踪日志。每个日志条目都包含节点的IP，I / O操作类型，文件描述符，偏移量，请求大小和时间戳。

在典型的一天，这样的原始跟踪数据单独超过100 GB，使得它们的收集/处理在Beacon的I / O记录数据库上成为非常重要的任务，这会从存储节点中夺走资源。但是，HPC工作负载的I / O操作中存在大量冗余。例如，由于每个计算节点通常一次专用于一个作业，因此许多跟踪条目中的作业ID是相同的。同样，由于许多并行应用程序的规则，紧密耦合特性，相邻的I / O操作可能具有常见组件，如目标文件，操作类型和请求大小。认识到这一点，Beacon在每个计算节点上执行积极的在线压缩，以显着减少I / O跟踪大小。这是通过一个简单的线性算法来完成的，该算法比较相邻的日志项并将它们与相同的操作类型，文件描述符和请求大小相结合，并访问连续的区域。这些日志项目将替换为单个项目和计数器。考虑到低计算开销，我们在计算节点上执行这种并行的首次通过压缩。

Beacon在专用服务器上执行脱机日志处理和第二次通过压缩。在这里，它从原始日志记录中提取特征向量<时间，操作，文件描述符，大小，偏移>，并通过比较来自所有节点的特征向量列表并合并相同的向量来执行节点间压缩，使用类似的方法在块跟踪建模[74]或ScalaTrace [61]中。

计算节点端的首次通过压缩在8个真实的大规模应用中将原始跟踪大小减少了5.4到34.6倍，其中增益依赖于应用程序I中的“立即”冗余量/ O操作。专用Beacon服务器上的第二次通过压缩进一步减少了2到4倍。详细结果见附录A.

转发节点在每个转发节点上，Beacon都会为LWFS服务器和Lustre客户端提供配置文件。它收集每个LWFS服务器请求的延迟和处理时间，以及每个LWFS服务器的请求队列长度（通过每1000个请求抽取一次队列状态）。 Beacon守护程序不是保存每个请求的跟踪，而是定期处理新的跟踪，只保存I / O请求统计信息，如延迟和队列长度分布。

对于Lustre客户端，Beacon通过每秒一次采样所有未完成的RPC请求的状态来收集请求统计信息。每个样本都包含Lustre服务器的转发ID和RPC请求大小。

Storage nodes and MDS  在存储节点上，Beacon守护程序定期对Lustre OST状态表进行采样，记录OST ID和OST总数据大小等数据项，并进一步发送高级统计信息，如RPC请求数和每个RPC平均数据大小。 过去的时间。 在Lustre MDS上，Beacon还定期以1秒的间隔收集和记录活动元数据操作（如打开和查找）的统计信息，同时在其数据库中存储周期性统计信息的摘要。

  多层I / O性能分析数据分析

所有上述监控数据都作为JSON对象在基于Elasticsearch的数据库上作为JSON对象进行传输，以便长期存储和处理，Beacon将在其上构建I / O监控/分析服务。 这些包括定期运行的自动异常检测，以及超级计算机用户和管理员可以交互使用的查询和可视化工具。 下面我们给出更详细的描述。

Automatic anomaly detection   

在大型系统中，直接故障相对容易检测，通常由心跳检测等工具处理[67,72]，超出了这项工作的范围。但是，活动但非常慢的组件（例如转发节点和性能下降的OST）可能会继续为请求提供服务，但速度要低得多，这会降低整个应用程序的性能并降低整体系统利用率。由于繁忙的存储系统服务于多个平台以及每个并发应用程序，因此很难识别这种分散器。在连续的端到端I / O监控的帮助下，Beacon实现了自动I / O系统异常检测，识别系统组件处理I / O工作负载的速度明显慢于同类产品。

这是通过处理来自同一应用程序的当前和历史执行的I / O监视数据来完成的，使用群集来检测转发节点和OST上的明显性能下降。运行这种检测处理的频率是可配置的，并且当前每小时设置一次。在识别出严重的系统异常后，将自动生成警报电子邮件并发送给TaihuLight管理员。我们在4.2节中给出了一个用例研究，另外还有附录B中的详细工作流程描述。

Per-job I/O performance analysis

在作业完成后，Beacon会自动分析从所有层收集的I / O监控数据。它通过首先在日志条目收集时识别在给定计算节点上运行的作业数据库中的作业来执行层间关联。然后，使用系统范围的映射表查找，通过计算 - 转发节点映射定位涉及的转发节点，从而导致相关的转发监视数据。最后，使用Lustre命令lfs通过文件系统查找找到相关的OST和相应的存储节点监视数据条目。

根据以上数据，Beacon导出并存储粗粒度信息以便快速查询，包括平均和峰值I / O带宽，平均IOPS，运行时间，执行I / O的进程数（和计算节点），I / O模式，I / O阶段的元数据操作总数和每秒平均元数据操作数。其中，I / O模式表示进程间的并行文件共享模式，常用模式包括“NN”（每个计算进程访问一个单独的文件），“N-1”（所有进程共享一个文件），“ NM“（N个进程执行I / O聚合以访问M个文件，M

为了帮助用户理解/调试其应用程序的I / O性能，Beacon提供基于Web的I / O数据可视化。在经过适当的身份验证后，可以使用作业ID查询此诊断系统，并允许可视化作业的I / O统计信息，包括实时和事后检查。它报告测量的I / O度量（例如带宽和IOPS）和推断的特性（例如I / O进程数和I / O模式）。还向用户呈现用户可配置的可视化工具，显示I / O度量中的时间序列度量，统计信息（如请求类型/大小分布）和性能差异。我们强大的I / O监控数据库允许进一步的用户启动导航，例如每计算节点流量历史记录和缩放控制，以检查不同粒度的数据。为了安全/隐私，用户只能在其工作执行期间查看涉及的计算，转发和存储节点的I / O数据。

I/O subsystem monitoring for administrators

Beacon还为管理员提供了在任何节点上监控任何时间段的I / O状态的功能。除了上面提到的所有用户可见信息和设施，管理员还可以进一步获取和可视化:( 1）每个计算节点，转发节点和存储节点的详细I / O带宽和IOPS，（2）转发节点，存储节点和MDS的资源利用状态，包括详细的请求队列长度统计，以及（3） 转发节点上的I / O请求延迟分发。 另外，Beacon授权管理员使用直接I / O记录数据库访问，以便进行深入分析。

结合这些设施，管理员可以执行强大而彻底的I / O流量和性能分析，例如，通过检查关于特定作业执行的多级流量，等待时间和吞吐量监视信息。

一般性和限制

Beacon可以被其他平台采用。 I / O转发架构被当前排名前20的机器中的9台（表1中列出）广泛使用。它也是DAOS Exascale存储设计[54]和TOKIO I / O监控框架[24]的目标。

Beacon的构建模块，例如操作日志收集和压缩，调度程序辅助的每个应用程序数据关联和分析，基于历史记录的异常识别，自动I / O模式检测和内置干扰分析，可以都可以在其他超级计算机上执行。它的数据管理组件，如Logstash，Redis和ElasticSearch，也是在这些机器上运行的开源软件。我们的转发层设计验证和负载分析也可以帮助最近的平台具有一层突发缓冲节点，例如NERSC的Cori [2]。

同时，当前的Beacon系统具有可在未来工作中应用或可应用于其他平台的限制。例如，它目前通过向系统管理员的注意力提供不寻常的模式来执行数据分析并检测异常。将症状和解决方案相关联的其他历史数据收集将使该过程更加智能化并减少人工需求[86]。同样，非并行I / O专家的应用程序用户可以从系统生成的直接建议中受益（例如I / O模式或请求大小更改，以及使用并行文件系统进行元数据繁重的交互式任务） ），超越性能数据可视化。

Beacon框架评估

我们现在评估Beacon的每个应用程序分析精度以及性能开销。

Accuracy Verification

Beacon从计算节点侧收集完整的跟踪，因此可以访问完整的应用程序级I / O操作信息。但是，由于LWFS客户端跟踪接口仅提供粗略的时间戳数据（以每秒粒度为单位），并且由于计算节点之间的时钟漂移，因此从Beacon日志恢复的I / O模式可能会偏离应用程序级别捕获的记录。

为了评估此类错误的程度，我们将MPI-IO测试[40]报告的I / O吞吐量统计信息与Beacon报告的I / O吞吐量统计信息进行比较。在实验中，我们使用MPI-IO测试来测试不同的并行I / O模式，包括N-N和N-1独立操作，以及MPI-IO库集体调用。在每个执行规模上重复10次实验。

精度评估结果如图12所示。我们绘制了Beacon中的平均误差，测量为记录的聚合计算节点端I / O吞吐量与MPI报告的应用程序级吞吐量的偏差百分比-IO库。

我们发现Beacon能够准确地捕获应用程序性能，即使对于具有非平凡的并行I / O活动的应用程序也是如此。更确切地说，Beacon的记录吞吐量偏离MPI-IO测试报告值，读取测试仅为0.78-3.39％（平均为1.84％），写入为0.81-3.31％（平均为2.03％）。结果类似于高IOPS应用，由于空间限制而省略。

图12：Beacon报告带宽的平均错误率（误差条显示95％置信区间。）

Beacon的准确性可归因于它记录了所有计算节点侧跟踪日志，这得益于其高效且几乎无损的压缩方法（如第3.2节所述）。 我们发现，即使单个跟踪项可能在时间戳中关闭，但超级计算机上的数据密集型应用程序很少执行隔离的快速I / O操作（这对于分析目的不感兴趣）; 相反，它们表现出具有持续高I / O强度的I / O阶段。 通过收集大量的每应用程序I / O跟踪条目，Beacon能够准确描绘应用程序的I / O行为和性能。

Monitoring and Query Overhead

我们现在评估Beacon在生产环境中的监控开销。 我们比较了重要的I / O密集型实际应用程序和前面讨论的MPI-IO测试基准测试的性能，无论是否打开Beacon（分别为Tw和Tw / o）。 我们报告每个程序的总运行时间，并通过打开Beacon来计算引入的减速。 表6显示了结果，列出了每个项目至少5次运行的平均减速情况（运行速度减慢的差异非常低：低于2％）。 请注意，对于最大的应用程序，此类测试是在稳定代码的实际生产运行中捎带的，并且在某些分配时间帧期间打开Beacon。 像AWP这样的应用程序经常会破坏它们的执行，以便一次运行一定数量的模拟时间步长。

表6：平均Beacon监控应用程序的开销

这些结果表明Beacon工具引入了非常低的开销：在所有测试用例中低于1％。 此外，开销不随应用程序执行规模而增长，实际上对于使用130K或更多进程的两个最大作业而言显得更小（低于0.25％）。 考虑到通过Beacon提供的信息的优化或问题诊断产生的显着I / O性能增强和运行时间节省，这种成本尤其可以忽略不计。 表7列出了Beacon数据收集守护进程的CPU和内存使用情况。 此外，Beacon自2017年4月起在TaihuLight部署的存储开销约为10 TB。 如此低的操作开销和可扩展的操作证明了Beacon的轻量级设计，背景跟踪收集和压缩产生的可忽略的额外资源消耗。 此外，具有单独的监控网络和存储可避免对应用程序执行的潜在干扰。

图13：Beacon查询处理时间的CDF

最后，我们评估Beacon的查询处理性能。 我们在2018年9月测量了2000 Bea-con查询的查询处理时间，包括访问作业性能分析的应用程序用户和检查转发/存储节点性能的系统管理员。 特别是，我们检查了Beacon在Web界面和Elasticsearch之间的内存缓存系统的影响，如图2所示。图13给出了处理时间查询的CDF，并演示了（1）大多数Beacon用户查询都可以 在1秒内处理，95.6％在10秒内处理（可视化查询需要更长时间），以及（2）Beacon的内存缓存显着改善了用户体验。 附加检查显示，大约95％的查询可以通过缓存的数据提供。

相关工作

已经为HPC系统提出了几种I / O跟踪和分析工具，它们可以分为两类：面向应用的工具和面向后端的工具。

面向应用程序的工具可以逐个函数地提供有关特定执行的详细信息。这方面的工作包括Darshan [31]，IPM [76]和RIOT [81]，所有这些都旨在通过捕获计算节点上主流I / O堆栈的关键特性来构建应用程序I / O行为的准确图像。 Carns等人。评估了Darshan的性能和运行时开销[30]。吴等人。提出了一种可扩展的MPI和I / O事件跟踪方法[58,82,83]。记录仪[56]专注于收集额外的HDF5跟踪数据。

像Darshan这样的工具通过自动环境配置提供用户透明的监控。基于工具的工具仍然限制编程语言或库/链接器。相比之下，Beacon设计为一个不间断的全系统I / O监控系统，可捕获系统级的I / O活动。

面向后端的工具跨应用程序收集系统级I / O性能数据，并提供摘要统计数据（例如LIOProf [85]，LustreDU [29,48,62]和LMT [38]）。但是，使用这些工具很难识别应用程序性能问题并找出应用程序性能下降的原因。虽然后端分析方法[50,52]仅在使用后端日志识别高吞吐量应用程序方面取得了进展，但它们缺乏应用程序端信息。另一方面，Beacon拥有完整的跨层监控数据以提供此类任务。

沿着这条线，存在收集多层数据的工具。静态检测用于跟踪从MPI到PVFS服务器的并行I / O调用[46]。 SIOX [80]和IOPin [45]描述了I / O堆栈中的HPC I / O工作负载。这些项目将Darshan [31]使用的应用级I / O工具方法扩展到其他系统层。但是，它们的开销阻碍了它在大规模生产环境中的部署[70]。

关于端到端框架，TOKIO [24]结合了前端工具（Darshan，Recorder）和后端工具（LMT）。例如，UMAMI监测信息[53]提供了跨层I / O性能分析和可视化。此外，OVIS [27]使用Cray特定工具LDMS [22]来提供可扩展的故障和异常检测。 GUIDE [91]进行了中心范围和多源日志收集，并推动了进一步的分析和优化。 Beacon的不同之处在于其积极的实时性能和利用率监控，自动异常检测以及连续的每个应用程序I / O模式分析。 I / O干扰被认为是HPC系统性能变化的重要原因[52,63]。 Kuo等人。 [47]侧重于来自不同文件访问模式的干扰以及同步的时间片剖面。 Yildiz等人。 [88]研究了跨软件和硬件配置的跨应用程序I / O干扰的根本原因。据我们所知，Beacon是第一个具有内置功能的监控框架，用于应用程序间干扰分析。我们的研究证实了大规模HPC应用采用差I / O设计选择的发现[57]。它进一步表明，除了依赖于工作负载的I / O感知调度[33,52]之外，还应该通过应用程序I / O模式来应对干扰优化和自适应I / O资源分配。

最后，在网络监控方面，有专用工具[51,59,68]用于监控交换机性能，异常检测和资源利用优化。还有专门为数据中心进行网络监控/调试的工具[14,73,89]。但是，这些工具/系统通常不针对超级计算机上常用的InfiniBand互连。为此，Bea con采用开源OFED堆栈[13,32]从IB网络中检索相关信息。更重要的是，它利用其最初为I / O设计的可扩展且高效的监控基础架构来解决网络问题。

结论

我们展示了Beacon，这是领先的超级计算机Tai-huLight的端到端I / O资源监控和诊断系统。 它有助于沿着长I / O路径进行全面的I / O行为分析，并识别出隐藏的性能和用户I / O行为问题以及系统异常。 Beacon在过去18个月内实现的增强功能显着提升了超大规模应用的I / O性能和整体TaihuLight I / O资源利用率。 更一般地说，我们的结果和经验表明，这种详细的多层I / O监控/分析在最先进的超级计算机中是可以承受的，提供有价值的见解，同时产生非常低的成本。