В настоящее время я ищу хорошее промежуточное программное обеспечение для построения решения для системы мониторинга и обслуживания. Перед нами стоит задача контролировать, собирать данные и обслуживать распределенную систему, состоящую из 10 000 отдельных узлов.

Система разбита на группы по 5-20 узлов. Каждая группа производит данные (как команда), обрабатывая входящие данные датчика. У каждой группы есть выделенный узел (синие прямоугольники), выступающий в качестве фасада / прокси для группы, представляющий данные и состояние из группы внешнему миру. Эти кластеры географически разделены и могут подключаться к внешнему миру по разным сетям (один может работать через оптоволокно, другой через 3G / спутник). Скорее всего, у нас будут как короткие (секунды / минуты), так и более длительные (часы) простои. Данные сохраняются каждым кластером локально.

Эти данные должны собираться (постоянно и надежно) внешними централизованный сервер (ы) (зеленые ящики) для дальнейшей обработки, анализа и просмотра различными клиентами (оранжевые ящики). Также нам нужно следить за состоянием всех узлов через каждый прокси-узел группы. Нет необходимости контролировать каждый узел напрямую, хотя было бы хорошо, если бы промежуточное ПО могло это поддерживать (обрабатывать сообщения пульса / состояния от ~ 10000 узлов). В случае сбоя прокси-сервера доступны другие методы для точного определения отдельных узлов.

Кроме того, нам необходимо иметь возможность взаимодействовать с каждым узлом для настройки параметров и т. Д., Но это, кажется, легче решить, поскольку в большинстве случаев это обрабатывается вручную для каждого узла при необходимости. Может потребоваться некоторая пакетная настройка, но в целом это выглядит как стандартная ситуация RPC (веб-служба или аналогичная). Конечно, если промежуточное ПО может справиться и с этим, через какой-то механизм запроса / ответа, это было бы плюсом.

Требования:

Более 1000 узлов публикуют / предлагают непрерывные данныеДанные должны быть надежно (каким-то образом) и постоянно собираться на один или несколько серверов. Вероятно, он будет построен поверх промежуточного программного обеспечения с использованием какого-то явного запроса / ответа для запроса потерянных данных. Если это может быть выполнено автоматически промежуточным программным обеспечением, это, конечно, плюс.Более одного сервера / подписчика должны иметь возможность подключаться к одному и тому же производителю / издателю данных и получать одни и те же данные.Максимальная скорость передачи данных в диапазоне 10-20 в секунду на группуРазмер сообщений варьируется от ~ 100 до 4-5 КбайтДиапазон узлов от встроенных ограниченных систем до обычных COTS Linux / WindowsУзлы обычно используют C / C ++, серверы и клиенты обычно C ++ / C #.Узлы не должны (предпочтительно) устанавливать дополнительные ПО или серверы, т. Е. Один выделенный брокер или дополнительная служба на узел стоит дорогоБезопасность будет основываться на сообщениях, т. Е. Безопасность транспорта не требуется

Мы ищем решение, которое может обрабатывать связь между главным образом прокси-узлами (синий) и серверами (зеленый) для публикации / опроса / загрузки данных и от клиентов (оранжевый) к отдельным узлам (стиль RPC) для настройки параметров.

Там, кажется, много дискуссий и рекомендаций для обратной ситуации; распространение данных с сервера (серверов) среди многих клиентов, но было сложнее найти информацию, относящуюся к описанной ситуации. Общее решение, по-видимому, заключается в использовании SNMP, Nagios, Ganglia и т. Д. Для мониторинга и изменения большого количества узлов, но сложная часть для нас - это сбор данных.

Мы кратко рассмотрели такие решения, как DDS, ZeroMQ, RabbitMQ (нужен ли брокер на всех узлах?), SNMP, различные инструменты мониторинга, веб-службы (JSON-RPC, REST / Protocol Buffers) и т. Д.

ТакЕсть ли у вас какие-либо рекомендации относительно простого в использовании, надежного, стабильного, легкого, кросс-платформенного, межязыкового промежуточного программного обеспечения (или другого), которое бы отвечало всем требованиям? Как можно проще, но не проще.