ACM

ACM通信

首页 / 杂志存档 / 2009年9月(第五十二卷第九期) / MonALISA对大型系统的监视和控制 /全文

实践

MonALISA对大型系统的监视和控制

作者Iosif Legrand, Ramiro Voicu, Catalin Cirstoiu, Costin Grigoras, Latchezar Betev, Alexandru Costan
ACM通信，2009年9月，第52卷第9期，49-55页
10.1145/1562164.1562182
评论

认为: 打印手机应用程序 ACM数字图书馆全文(PDF) 数码版分享: 通过电子邮件发送在reddit分享在StumbleUpon分享在黑客新闻上分享在推特上分享在Facebook上分享

加州理工学院的高能物理(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的第二个原因是它在广域网连接中相对较低的性能和稳定性(参见图2)．HEP社区使用的主要操作系统过去是，现在仍然是Linux，但它的内核和库的风格不同，当然，在异构管理下。Java帮助很大，但由于当时使用的2.4内核中的TCP堆栈实现，我们经历了套接字停滞和网络吞吐量较差的情况。

我们试图在性能和开发自定义协议的时间之间找到最佳的平衡，因此我们仍然使用本机Java序列化。由于最初的目标是几乎实时地做出反应，我们必须在应用级别开发我们的保持存活机制;我们无法控制，而且在内核级别也有问题。通过标准TCP套接字实现我们自己的通信协议，可以帮助我们更好地控制网络I/O错误，从而实现快速和干净的恢复。虽然TCP的实现⁵在最新的2.6内核中已经发生了变化，即使默认的拥塞协议在没有任何特殊设置的情况下工作得相当好，我们仍然相信，取决于应用程序的时间限制，任何远程调用协议在广域网环境中都将是一个问题，因为固有的开销和网络延迟。

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

回到顶部

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

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

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

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

ALICE计算模型与MonALISA的体系结构非常匹配，因此各个部分自然地结合在一起，但它也为我们实现项目的初始目标提供了很大的机会:使用监测数据来改进观察到的系统。实际上，在MonALISA中实现的行动框架代表了实现基于监视信息的决策自动化的第一步。值得注意的是，操作可以在两个关键点上使用:本地，靠近数据源(在MonALISA服务中)，在这里可以执行简单的操作;在MonALISA客户端中，触发动作的逻辑可能更加复杂，因为它可以依赖于多个数据流。因此，中心客户机配备了几个决策代理来帮助操作这个复杂的系统:当远程服务没有通过功能测试时重新启动，当自动重新启动过程不能解决问题时发送电子邮件警报或即时消息，协调远程站点对之间的网络带宽测试，管理中心计算机的基于dns的负载平衡，以及在CPU资源空闲时自动执行标准应用程序。

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

要在相当短的时间内按需存储和显示如此多的参数是一项挑战，因为图表是根据用户的选项动态生成的，因此难度更大。数据库响应时间取决于值的数量，因此按需生成图表的一个步骤是在不断增加的时间间隔中存储平均值，这样节省了空间，但丢失了分辨率。三个数据库结构是并行填充的:从一个高分辨率的数据库只保存最近几个月的数据，到一个非常低分辨率的数据库永远保存数据。数据控制器自动选择从哪个结构中提取数据的哪部分以满足用户请求，如果请求参数需要，它可以从多个结构中获取数据。

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

回到顶部

数据传输服务和优化通信

为了支持大规模数据驱动的应用程序，比如那些特定于HEP社区的应用程序，特别是当数据量变得越来越普遍时，必须同时配置和调优大量的子系统。手动执行这些操作不仅需要昂贵的人力专业知识，而且还限制了这种系统的最大实际大小。此外，处理动态变化的条件和错误以及协调不同应用程序的资源需求也变得困难。在MonALISA框架中，我们开发了大量的模块和代理，这些模块和代理能够监视不同的网络设备、网络拓扑和连接，并且我们尝试使用这些近乎实时的信息来优化广域网中的通信和数据传输。过去三年来，该框架一直用于监测和协调大型数据传输;我们在2006年的超级计算大会上演示了整个系统，⁸2007年,²和2008年。^3.

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

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

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

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

在开发这种试图控制广域网连接的全局服务时，最费力的部分是处理通信错误。我们的部分环境是混合网络，一些是研究或专用网络，一些可以从学术和商业网络访问。大多数情况下，一切都按照预期工作，问题不会经常发生。然而，当它们真的发生时，在采取行动之前了解发生了什么是很重要的。特别地，我们想讨论系统中两种可能的不对称情况。当这种情况只发生在路由级别时，涉及通信的双方可以彼此到达，但通过使用不同的路由，这影响了通信的吞吐量和可靠性，并不难检测，通常很容易恢复。

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

回到顶部

结论

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

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

我们使用的分布式体系结构，没有单点故障，证明提供了可靠的分布式服务系统。在过去5年的24小时运行中，我们从未出现过整个系统瘫痪的情况。在几个学术中心复制的主要服务成功地处理了主要的网络故障和中断。

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