7

我目前正在寻找一个好的中间件来构建监控和维护系统的解决方案。我们的任务是监控、收集和维护由多达 10,000 个独立节点组成的分布式系统。

该系统集群成 5-20 个节点的组。每个组通过处理传入的传感器数据来生成数据（作为一个团队）。每个组都有一个专用节点（蓝色框）作为组的外观/代理，将组中的数据和状态暴露给外界。这些集群在地理上是分开的，并且可以通过不同的网络连接到外部世界（一个可能通过光纤运行，另一个通过 3G/卫星）。我们很可能会经历更短（秒/分钟）和更长（小时）的中断。数据由每个集群在本地持久化。

这些数据需要由外部和集中式服务器（绿色框）收集（持续且可靠），以供各种客户端（橙色框）进一步处理、分析和查看。此外，我们需要通过每个组代理节点监控所有节点的状态。不需要直接监视每个节点，即使中间件可以支持它会很好（处理来自约 10,000 个节点的心跳/状态消息）。在代理失败的情况下，可以使用其他方法来查明单个节点。

此外，我们需要能够与每个节点交互以调整设置等，但这似乎更容易解决，因为这主要是在需要时手动处理每个节点。可能需要进行一些批量调整，但总而言之，它看起来像是标准的 RPC 情况（Web 服务或类似情况）。当然，如果中间件也可以通过一些请求/响应机制来处理这个问题，那将是一个加分项。

监控

要求：

  • 1000+ 节点发布/提供连续数据
  • 数据需要可靠（以某种方式）并持续收集到一台或多台服务器。这很可能建立在中间件之上，使用某种明确的请求/响应来请求丢失的数据。如果这可以由中间件自动处理，这当然是一个加号。
  • 多个服务器/订阅者需要能够连接到同一个数据生产者/发布者并接收相同的数据
  • 数据速率最大为每组每秒 10-20 次
  • 消息大小范围从大约 100 字节到 4-5 KB
  • 节点范围从嵌入式受限系统到普通 COTS Linux/Windows 机器
  • 节点一般使用C/C++，服务器和客户端一般使用C++/C#
  • 节点应该（最好）不需要安装额外的软件或服务器，即每个节点一个专用的代理或额外的服务是昂贵的
  • 安全性将基于消息，即不需要传输安全性

我们正在寻找一种解决方案，它可以处理主要代理节点（蓝色）和服务器（绿色）之间的通信，用于数据发布/轮询/下载，以及从客户端（橙色）到单个节点（RPC 样式）以调整设置。

对于相反的情况，似乎有很多讨论和建议；将数据从服务器分发到许多客户端，但很难找到与所描述情况相关的信息。一般的解决方案似乎是使用 SNMP、Nagios、Ganglia 等来监控和修改大量节点，但对我们来说棘手的部分是数据收集。

我们简要介绍了 DDS、ZeroMQ、RabbitMQ（所有节点都需要代理？）、SNMP、各种监控工具、Web 服务（JSON-RPC、REST/协议缓冲区）等解决方案。

那么，对于一个易于使用、健壮、稳定、轻量级、跨平台、跨语言的中间件（或其他）解决方案，您有什么建议吗？尽可能简单但不简单。

4

2 回答 2

6

披露：我是一名长期的 DDS 专家/爱好者，我为其中一家 DDS 供应商工作。

良好的 DDS 实施将为您提供所需的内容。数据收集和节点监控是 DDS 的传统用例，应该是它的最佳点。与节点交互并调整它们也是可能的，例如通过使用所谓的内容过滤器将数据发送到特定节点。这假定您有一种方法来唯一标识系统中的每个节点，例如通过字符串或整数 ID。

由于系统的分层特性及其绝对（潜在）大小，您可能必须引入一些路由机制来在集群之间转发数据。一些 DDS 实现可以为此提供通用服务。通常也支持与其他技术（如 DBMS 或 Web 界面）的桥接。

特别是如果您可以使用多播，系统中所有参与者的发现可以自动完成，并且需要最少的配置。但这不是必需的。

对我来说，您的系统看起来很复杂，需要定制。我不相信任何解决方案都能“轻松满足要求”，尤其是在您的系统需要容错和健壮的情况下。最重要的是，您需要了解您的要求。在您提到的上下文中，关于 DDS 的几句话：

1000+ 节点发布/提供连续数据

这是一个很大的数字，但应该是可能的，特别是因为您可以选择利用 DDS 支持的数据分区功能。

数据需要可靠（以某种方式）并持续收集到一台或多台服务器。这很可能建立在中间件之上，使用某种明确的请求/响应来请求丢失的数据。如果这可以由中间件自动处理，这当然是一个加号。

DDS 支持一组丰富的所谓服务质量 (QoS) 设置，指定基础设施应如何处理其分发的数据。这些是开发人员设置的名称-值对。支持的 QoS-es 中的可靠性和数据可用性区域。这应该会自动满足您的要求。

多个服务器/订阅者需要能够连接到同一个数据生产者/发布者并接收相同的数据

一对多或多对多分布是一个常见的用例。

数据速率最大为每组每秒 10-20 次

每秒最多添加 20,000 条消息是可行的，尤其是在对数据流进行分区的情况下。

消息大小范围从大约 100 字节到 4-5 KB

只要消息没有变得过大，消息的数量通常比通过线路传输的总千字节数量更受限制——除非大消息具有非常复杂的结构。

节点范围从嵌入式受限系统到普通 COTS Linux/Windows 机器

一些 DDS 实现支持大范围的操作系统/平台组合，它们可以混合在一个系统中。

节点一般使用C/C++，服务器和客户端一般使用C++/C#

这些通常是受支持的，并且可以在系统中混合使用。

节点应该（最好）不需要安装额外的软件或服务器，即每个节点一个专用的代理或额外的服务是昂贵的

此类选项可用，但是否需要额外服务取决于 DDS 实施和您要使用的功能。

安全性将基于消息，即不需要传输安全性

这肯定会让您的生活更轻松——但对于那些必须在消息级别实施该保护的人来说却不是那么容易。DDS 安全是 DDS 生态系统中较新的标准之一，它提供对应用程序透明的全面安全模型。

于 2012-11-26T04:13:55.713 回答
3

似乎 ZeroMQ 可以轻松满足要求，无需管理中央基础设施。由于您的监控服务器是固定的，因此解决问题确实非常简单。0MQ 指南中的这一部分可能会有所帮助：

http://zguide.zeromq.org/page:all#Distributed-Logging-and-Monitoring

您提到“可靠性”，但您能否指定您想要恢复的实际故障集？如果您使用的是 TCP，那么根据定义，网络已经是“可靠的”。

于 2012-11-21T06:20:10.023 回答