使用 MonALISA 监控和控制大型系统 -

2009年7月30日
第7卷，第6期

Download PDF version of this article 下载本文的 PDF 版本 PDF

使用 MonALISA 监控和控制大型系统

MonALISA 开发人员描述了它的工作原理、背后的关键设计原则以及构建它时最大的技术挑战。

Iosif Legrand, Ramiro Voicu, Catalin Cirstoiu, Costin Grigoras, Latchezar Betev, Alexandru Costan

加州理工学院的 HEP（高能物理）小组于 2002 年开始开发 MonALISA（使用大型集成服务架构的监控代理）框架，旨在提供一个分布式服务系统，能够控制和优化大规模、数据密集型应用。¹⁰ 其最初的目标应用领域是网格系统以及支持 HEP 协作的数据处理和分析的网络。我们为满足数据密集型应用的需求而采取的策略是转向应用、计算和存储设施与网络基础设施之间更协同的关系。

管理大规模分布式数据处理设施的一个重要部分是监控系统，用于近乎实时地监控计算设施、存储、网络以及在这些系统上运行的大量应用程序。为所有子系统收集的监控信息对于开发所需的高级服务（提供决策支持和一定程度的自动化决策的组件）以及维护和优化大规模分布式系统中的工作流程至关重要。这些管理和全局优化功能由更高级别的基于代理的服务执行。MonALISA 高级服务目前的应用程序包括优化的动态路由、控制和优化专用电路上的大规模数据传输、数据传输调度、分布式作业调度以及大量网格设施之间的远程服务的自动化管理。

系统设计

MonALISA 系统的初始设计灵感来自 Jini 架构。⁹ MonALISA 被设计为自主自描述的基于代理的子系统集合，这些子系统注册为动态服务。这些服务能够协作和配合，执行各种分布式信息收集和处理任务。

MonALISA 架构，如图 1 所示，基于四个层次的全局服务。整个系统基于 Java 技术。

第一层是 LUS（查找服务）网络，它为所有其他服务和代理提供动态注册和发现。MonALISA 服务能够在分布式环境中相互发现，并被感兴趣的客户端发现。注册使用租约机制。如果服务未能续订其租约，则会将其从 LUS 中删除，并向所有订阅此类事件的服务或其他应用程序发送通知。

MonALISA 框架的第二层代表 MonALISA 服务网络。它们提供多线程执行引擎，可容纳许多监控模块和各种松散耦合的代理，这些代理实时分析收集到的信息。该框架还集成了一组现有的监控工具和程序，用于收集描述计算节点、应用程序和网络性能的参数。收集到的信息可以本地存储在数据库中。动态加载的代理和过滤器能够本地处理信息，并与其他服务或代理通信，以执行全局优化任务。MonALISA 框架中的服务是一个组件，它通过动态代理或使用自描述协议的代理与其他服务自主交互。通过使用查找服务网络、分布式服务注册表以及发现和通知机制，服务能够无缝地访问彼此。动态远程事件订阅的使用允许服务注册对一组选定的事件类型感兴趣，即使在注册时没有通知提供程序。

代理服务构成了 MonALISA 框架的第三层。它们为客户端或其他服务请求的信息提供智能多路复用，并用于代理之间可靠的通信。此层还可以用于访问控制实施，以提供对收集到的信息和远程服务管理的安全访问。

更高级别的服务和客户端使用代理层访问收集到的信息。位置感知、负载均衡机制用于将这些服务动态地分配给最佳代理服务。客户端、其他服务或代理可以通过使用谓词机制来请求或订阅选定的测量值，从而获得实时或历史数据。这些谓词基于正则表达式来匹配客户端感兴趣的测量值的属性描述。它们也可以用于对选择值施加额外的条件或约束。订阅请求为消息创建专用优先级队列。与客户端的通信由线程池提供服务。分配的线程对客户端提交的所有谓词执行匹配测试，并使用数据流中的监控值。同一个线程负责将选定的结果作为压缩的序列化对象发送回客户端。

为客户端设置独立的线程可以快速可靠地发送他们需要的信息，避免了与其他客户端可能发生的通信错误造成的干扰。如果出现通信问题，这些线程将尝试重新建立连接或清理不再活动的客户端或服务的订阅。

通信经验

开发 MonALISA 系统中最困难的部分之一是广域网中所有这些服务的通信机制。该系统尝试建立和维护服务之间可靠的通信，使用自动重新连接或在网络或硬件问题的情况下查找替代服务的能力。尽管当时的流行趋势是在 XML 上实现远程调用协议并使用 Web 服务，但我们决定使用二进制协议，以避免将所有内容包装在基于文本的协议中的开销，并且因为缺少远程通知，除了基于拉取的方法（Oasis Web Services Notification¹³ 稍后出现，但在最初的实现中仍然使用基于拉取的方法）。尽管 XML 或 Web 服务对于某些应用程序仍然很有意义，但它们不适合大型动态数据。

最初我们使用 Java RMI（远程方法调用）作为客户端和服务之间的通信协议。这是一个优雅的解决方案，在开始时帮助我们开发框架的其他组件，而无需过多关注底层通信协议。然而，当我们开始在越来越多的站点上部署监控服务时，我们不得不出于两个主要原因替换这种方法。第一个原因是 HEP 计算中心的安全问题以及在这些中心的防火墙中为传入 TCP 连接打开端口的难度。在某些情况下，甚至出站连接也必须限制为少数 IP 地址和端口。这实际上是开发代理服务层的主要原因，允许所有其他 MonALISA 服务即使在防火墙或本地 NAT（网络地址转换）环境之后运行时也能相互通信。

我们不得不替换 RMI 的第二个原因是它在 WAN 连接中的性能和稳定性相对较低（图 2）。HEP 社区中使用的主要操作系统过去和现在仍然是 Linux，但它的不同风格——内核和库——当然，还有异构管理。Java 提供了很大帮助，但由于当时使用的 2.4 内核中的 TCP 堆栈实现，我们遇到了套接字停滞和网络吞吐量低的问题。

我们试图在性能和开发自定义协议所花费的时间之间找到最佳平衡，因此我们仍然使用了原生 Java 序列化。由于最初的目标是几乎实时地做出反应，我们不得不在应用程序级别开发我们的保活机制；我们无法控制内核级别的保活机制，并且也遇到了问题。在标准 TCP 套接字上实现我们自己的通信协议帮助我们在发生网络 I/O 错误时进行更精细的控制，以便快速干净地恢复。尽管 TCP 实现⁵ 在最新的 2.6 内核中发生了变化——即使默认的拥塞协议在没有任何特殊设置的情况下也能相当好地工作——我们仍然认为，根据应用程序的时间限制，任何远程调用协议都将成为 WAN 环境中的一个问题，因为固有的开销与网络延迟相结合。

另一方面，对于数千个受监控实体与本地 MonALISA 服务之间的 LAN 通信，我们决定采用另一种方法：使用基于 UDP（用户数据报协议）的二进制但高度可移植的协议，该协议采用 XDR（外部数据表示）¹⁴ 进行数据编码。事实证明，这种选择是有效的，并且允许服务每秒收集超过 5,000 条消息而没有任何丢失——TCP 无法扩展到同时从大型计算场中的所有节点接收数据。我们为此目的开发的 ApMon 客户端库（提供 Java、C、Perl 和 Python 版本）成为跟踪远程作业和节点的首选方法，因为它不仅可以发送用户特定数据，还可以发送进程和机器监控信息。

大型数据密集型科学项目的挑战

使用 MonALISA 系统的最大社区之一是 ALICE（大型离子对撞机实验）¹，它是 CERN（欧洲核子研究组织）的四个 LHC（大型强子对撞机）实验之一。⁴ ALICE 合作组织由来自 29 个国家和 86 个研究所的 1000 多名成员组成，它强烈依赖分布式计算环境来执行其物理计划。ALICE 实验将于今年开始运行，并将以每年高达 4 PB 的速率收集数据。在其 20 年的设计寿命期间，ALICE 每年将产生超过 10⁹ 个数据文件，并需要数万个 CPU 来处理和分析这些文件。CPU 和存储容量分布在全球 80 多个计算中心。这些资源在各个方面都是异构的，从 CPU 型号和数量到操作系统和批处理队列软件。分配的资源应随着时间的推移而增加，以匹配实验参数变化导致的数据采集速率的增加，因此预计两年内翻一番，依此类推。

ALICE 计算模型要求每个计算中心都有一个专用节点，该节点运行本地资源的管理软件。同一个节点还运行一个 MonALISA 服务，该服务从所有计算节点、存储系统、数据传输应用程序和本地集群中运行的软件收集监控信息。这产生了超过 110 万个在 MonALISA 中发布的参数，每个参数的更新频率为一分钟。此外，特定于 ALICE 的过滤器聚合原始参数以实时生成系统概览参数。这些更高级别的值通常在 ALICE 中央 MonALISA 存储库¹¹（图 3）中收集、存储和显示，并且是采取自动操作的燃料。

线条表示站点关系（Tier0-Tier1-Tier2）

在这种特殊情况下，我们通过聚合将数据量减少到仅约 35,000 个参数，例如，通过将本地集群中所有作业的整个 CPU 使用率汇总到一个参数中，通过汇总所有机器上的网络流量等等。这些概览通常足以识别问题并在系统中采取全局操作，并且可以将它们存储在中央数据库中以进行长期存档和分析。详细信息可根据需要在原始站点上获得，并且可以使用 GUI 客户端进行查阅。事实证明，这种方法对于调试目的非常有用——例如，跟踪特定应用程序或主机的行为。

ALICE 计算模型与 MonALISA 架构紧密匹配，因此各个部分自然地结合在一起，但也为我们提供了实现项目最初目标的绝佳机会：使用监控数据来改进观察到的系统。事实上，在 MonALISA 中实现的操作框架代表了基于监控信息可以做出的决策自动化的第一步。值得注意的是，可以在两个关键点采取操作：本地，靠近数据源（在 MonALISA 服务中），可以在此处采取简单操作；以及全局，在 MonALISA 客户端中，此处触发操作的逻辑可能更复杂，因为它可能取决于多个数据流。因此，中央客户端配备了多个决策代理，这些代理有助于操作这个复杂系统：在远程服务未通过功能测试时重新启动它们，当自动重启程序无法解决问题时发送电子邮件警报或即时消息，协调远程站点对之间的网络带宽测试，管理中央机器的基于 DNS 的负载均衡，以及在 CPU 资源空闲时自动执行标准应用程序。

操作框架已成为 ALICE 网格的关键组件。除了监控各种网格组件的状态并在操作期间发生任何问题时向相关人员发出警报外，此框架还用于自动化流程。其中一项自动化负责生成模拟实验行为或分析数据的 Monte Carlo 数据。在正常情况下，作业运行 10 到 12 个小时，并生成或分析每个文件约 10 GB 的文件。然而，ALICE 作业可能会因多种原因而失败：最常见的原因包括网络问题以及本地机器、存储或中央服务问题。通过持续监控生产作业的中央任务队列，当等待作业的数量低于预设阈值（目前为 4,000 个作业）时，MonALISA 存储库会采取行动。首先，它会查看是否有任何失败的作业可以重新安排运行；然后，如果队列长度仍然太短，它将安排新的 1,000 个作业批次。相同的框架用于自动将数据复制到远程站点并测试所有端点之间的网络连接。将网络的持续测试和存储与错误报告相结合，已被证明是调试系统的有效工具。

有如此多的参数需要存储并在合理的时间内按需显示是一个挑战——由于图表是根据用户的选项动态生成的，因此挑战更加艰巨。数据库响应时间取决于值的数量，因此按需生成图表的一个步骤是存储在不断增加的时间间隔内平均的值，从而节省空间但会损失分辨率。并行填充三个数据库结构：从一个具有高分辨率的数据库结构（仅保留最近几个月的数据）到一个具有非常低分辨率的数据库结构（永久保留数据）。数据控制器自动选择要从哪个结构中提取哪些部分的数据以满足用户请求，并且如果请求参数需要，它可以从多个结构中提取数据。

减少响应时间的第二个步骤是将查询分散到多个数据库后端。三个相同的数据库实例现在接收所有更新，而选择查询被拆分，以便从所有活动后端并行提取不同的参数。有了这两个选项，一台前端机器每天可以处理约 20,000 个动态页面，而数据库大小已达到 170 GB。

数据传输服务和优化通信

为了支持大规模数据驱动型应用程序，例如 HEP 社区特有的应用程序（尤其是在数据量增长的情况下），必须同时配置和调整大量子系统。手动执行这些操作不仅需要昂贵的人力专业知识，而且还限制了此类系统的最大实际规模。此外，处理动态变化的情况和错误以及协调不同应用程序的资源需求变得很困难。在 MonALISA 框架内，我们开发了大量模块和代理，能够监控不同的网络设备、网络拓扑和连接性，并且我们尝试近乎实时地使用这些信息来优化 WAN 中的通信和数据传输。过去三年，该框架一直用于监控和协调大型数据传输；我们在 2006⁸、2007² 和 2008³ 年的超级计算会议上展示了整个系统。

这种系统的一个例子是优化 EVO 协作网络的视频会议系统的全局连接。⁶ 优化基于持续的端到端监控，包括最终用户的计算机以及网络基础设施。通过这种方式，用户可以了解任何潜在或实际问题（例如，CPU 负载过高或数据包丢失），并且在可能的情况下，问题会在用户不知情的情况下自动透明地解决（例如，切换到网络中的另一个服务器节点，减少接收的视频流的数量等）。EVO 服务器通过一组通道（安全的 TCP 连接）相互通信，这些通道在实际网络拓扑之上形成一个覆盖网络。专用 MonALISA 服务用于从所有 EVO 服务器收集监控数据并维护连接反射器的连接树（最小生成树）。此树用于根据有关每对反射器之间替代可能连接质量的信息，动态计算视频会议数据流的最佳路由。如果一个或多个链路发生故障或严重降级，则会实时重建和重新优化树，使 EVO 能够抵抗故障（图 4）。

我们使用 MonALISA 的第二个例子是监控和控制光开关，并为最终用户应用程序提供全局服务以按需创建光路径/树。¹² 代理使用 MonALISA 的发现层来“发现”彼此，然后使用代理服务在它们之间自主通信。每个代理服务每秒可以处理超过 15,000 条消息，并且通常并行使用多个此类服务。这确保了即使在非常高的消息传递速率下，代理之间的通信也高度可靠。

代理集还用于创建全局路径或树，因为它知道每个本地和广域网链路的状态和性能，以及每个交换机中交叉连接的状态。路由算法通过考虑每个链路或交叉连接的“成本”来提供全局优化。这使得优化算法能够适应处理关于优先级和预留方案的各种策略。确定和构建端到端光路径（或多播树）的时间通常不到一秒，这与路径上的链路数量和路径的总长度无关。如果检测到网络错误，则会快速建立替代路径以避免 TCP 超时，从而使数据传输不间断地继续。

开发试图控制 WAN 中连接的此类全局服务最费力的部分是处理通信错误。我们的环境部分位于混合网络中——有些仅在研究或专用网络中，有些可以从学术网络和商业网络访问。大多数时候，一切都按预期工作，并且问题不会经常发生。但是，当问题确实发生时，重要的是先了解发生了什么，然后再采取行动。特别是，我们想讨论系统中可能出现的两种不对称情况。当这种情况仅发生在路由级别时，参与通信的双方都可以相互访问，但使用不同的路由——这会影响通信的吞吐量和可靠性，不易检测到，并且通常很容易从中恢复。

当参与决策的分布式框架的不同部分对系统有不同的看法时，会出现另一个更严重的问题。我们曾经遇到过一个案例，欧洲的一些服务无法访问美国的服务，但与此同时，其中一些服务可以看到所有其他服务。当您对系统有部分但一致的看法时，您可以在本地采取行动，但在这种情况下，我们得出的结论是，最好的方法是保持安全，不做出任何决定。此类问题在我们的环境中并不经常发生，但要检测它们并避免为我们描述的系统类型做出错误决策确实很困难。

结论

在过去的七年中，我们一直在开发一个监控平台，该平台提供在大型分布式环境中动态获取、处理、分析和创建信息层次结构的功能。该系统基于允许可伸缩性和可靠性的原则，并简化了分布式实体之间的通信。这种在如此灵活的分布式框架中收集任何类型的监控信息的方法可用于进一步开发，以帮助操作和有效利用分布式计算设施。

公平地说，在这个项目开始时，我们低估了在 WAN 中开发大型分布式系统的一些潜在问题，事实上，“分布式计算的八个谬论”是非常重要的教训。⁷

我们使用的分布式架构没有单点故障，事实证明它提供了一个可靠的分布式服务系统。在过去五年中 24 小时不停运转的过程中，我们从未发生过整个系统崩溃的情况。多个学术中心的复制的主要服务成功处理了重大网络故障和中断。

截至撰写本文时，全球有 350 多个 MonALISA 服务 24 小时不停运转。这些服务监控超过 20,000 台计算服务器、数百个 WAN 链路和数万个并发作业。近乎实时地监控超过 150 万个参数，总更新速率约为每秒 25,000 个参数。许多社区使用全局 MonALISA 存储库来聚合来自多个站点的信息，为用户正确组织这些信息，并保留长期历史记录。在过去一年中，存储库系统为用户提供了超过 800 万次请求的服务。
问

喜欢它，讨厌它？请告诉我们

[email protected]

参考文献

ALICE Collaboration; http://aliceinfo.cern.ch/Collaboration.
Caltech High Energy Physics. High Energy Physicists Set New Record for Network Data Transfer. Supercomputing 2007 (Reno); http://media.caltech.edu/press_releases/13073.
Caltech High Energy Physics. High Energy Physics Team Sets New Data-Transfer World Records. Supercomputing 2008 (Austin); http://media.caltech.edu/press_releases/13216.
CERN; http://www.cern.ch.
Default TCP implementation in Linux 2.6 kernels; http://netsrv.csc.ncsu.edu/twiki/bin/view/Main/BIC.
EVO Collaboration Network; http://evo.caltech.edu.
Fallacies of distributed computing; http://en.wikipedia.org/wiki/Fallacies_of_Distributed_Computing.
HPC Wire. Physicists set record for network data transfer. Supercomputing 2006; http://www.hpcwire.com/topic/networks/17889729.html.
Jini: http://www.jini.org/.
MonALISA; http://monalisa.caltech.edu.
MonALISA Repository for ALICE; http://pcalimonitor.cern.ch.
Voicu, R., Legrand, I., Newman, H., Dobre, C., Tapus, N. 2007. A distributed agent system for dynamic optical path provisioning. Proceedings of Intelligent Systems and Agents (ISA), part of the IADIS Multi Conference on Computer Science and Information Systems (Lisbon).
WS Notification; http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=wsn.
XDR; http://en.wikipedia.org/wiki/External_Data_Representation.

Iosif Legrand is a Senior Research Engineer at Caltech and the technical lead of the MonALISA project. He has a M.Sc. in nuclear engineering and a Ph.D. in physics from the University of Bucharest. He worked for more than 16 years in high-performance computing, algorithms, modeling and simulation, and control and optimization for distributed systems.

Ramiro Voicu is a research engineer at Caltech working for USLHCNet at CERN. He received a M.Sc. degree in computer science from Politehnica University of Bucharest. He was a Marie Curie fellow at CERN and is also enrolled in a Ph.D. program at Politehnica University. His research interests include global optimization in distributed systems and high-performance data transfers.

Catalin Cirstoiu is a software engineer in the finance industry. He recently completed his Ph.D. in the computer science department of Politehnica University in Bucharest in collaboration with Caltech and CERN. He works on parallel and distributed systems, focusing on reliability, optimization, and high-performance issues.

Costin Grigoras is a software engineer in ALICE at CERN. He received a M.Sc. degree in computer science from Politehnica University of Bucharest. He is a fellow at CERN and is also enrolled in a Ph.D. program at Politehnica University. His research interests include distributed systems, monitoring, and automated decision taking.

Latchezar Betev is working in the offline team of the ALICE collaboration at CERN and is responsible for the operation of the grid infrastructure of the experiment. His main interests include large-scale distributed computing and monitoring and control of remote systems.

Alexandru Costan is a Ph.D. student and teaching assistant in the Computer Science department of the University Politehnica of Bucharest. His research interests include grid computing, data storage and modeling, and P2P systems.

Originally published in Queue vol. 7, no. 6—
在数字图书馆中评论本文

更多相关文章

Marc Brooker, Ankush Desai - AWS 的系统正确性实践
构建可靠且安全的软件需要一系列方法来推理系统正确性。除了行业标准测试方法（例如单元测试和集成测试）之外，AWS 还采用了模型检查、模糊测试、基于属性的测试、故障注入测试、确定性模拟、基于事件的模拟以及执行跟踪的运行时验证。形式化方法一直是开发过程的重要组成部分 - 也许最重要的是，形式化规范作为测试预言机，为 AWS 的许多测试实践提供正确的答案。正确性测试和形式化方法仍然是 AWS 的关键投资领域，这些领域已经看到的投资回报加速了这一投资。

Achilles Benetopoulos - 数据中心计算机的中间表示
我们已经到了分布式计算无处不在的地步。内存应用程序数据大小正在超过单台机器的容量，因此需要将其分区到集群中；在线服务具有高可用性要求，只有将系统部署为多个冗余组件的集合才能满足这些要求；高持久性要求只能通过数据复制来满足，有时甚至跨越广阔的地理距离。

David R. Morrison - 模拟：分布式系统中未充分利用的工具
模拟在 AI 系统的出现中发挥着巨大作用：我们需要一种高效、快速且经济高效的方式来训练 AI 代理在我们的基础设施中运行，而模拟绝对提供了这种能力。

Matt Fata, Philippe-Joseph Arida, Patrick Hahn, Betsy Beyer - 企业到云：Google 的虚拟桌面
超过四分之一的谷歌员工使用内部数据中心托管的虚拟桌面。这种本地部署方案位于企业网络中，允许用户开发代码、访问内部资源，并在世界各地远程使用图形用户界面 (GUI) 工具。其中最显著的功能包括：虚拟桌面实例可以根据当前的任务调整大小、具有持久的用户存储，并且可以在企业数据中心之间移动，以方便经常出差的谷歌员工。直到最近，我们的虚拟桌面曾经托管在谷歌企业网络中的商用硬件上，使用自研的名为 Ganeti 的开源虚拟集群管理系统。如今，这项规模庞大且对谷歌至关重要的工作负载在 GCP (Google Compute Platform) 上运行。