В настоящее время я ищу хорошее промежуточное программное обеспечение для создания решения для системы мониторинга и обслуживания. Перед нами стоит задача мониторинга, сбора данных и обслуживания распределенной системы, состоящей из 10 000 отдельных узлов.
Система кластеризуется в группы по 5-20 узлов. Каждая группа производит данные (как команда), обрабатывая поступающие данные датчиков. У каждой группы есть выделенный узел (синие прямоугольники), выступающий в качестве фасада/прокси для группы, предоставляющий данные и состояние группы внешнему миру. Эти кластеры географически разделены и могут подключаться к внешнему миру по разным сетям (один может работать по оптоволокну, другой по 3G/спутнику). Вероятно, мы будем сталкиваться как с более короткими (секунды/минуты), так и с более длительными (часами) отключениями. Данные сохраняются каждым кластером локально.
Эти данные должны собираться (непрерывно и надежно) внешними и централизованными серверами (зеленые прямоугольники) для дальнейшей обработки, анализа и просмотра различными клиентами (оранжевые прямоугольники). Кроме того, нам необходимо отслеживать состояние всех узлов через прокси-узел каждой группы. Не требуется отслеживать каждый узел напрямую, хотя было бы хорошо, если бы промежуточное ПО могло это поддерживать (обрабатывать сообщения пульса/состояния примерно с 10 000 узлов). В случае сбоя прокси доступны другие методы для точного определения отдельных узлов.
Кроме того, нам нужно иметь возможность взаимодействовать с каждым узлом для настройки параметров и т. д., но это, кажется, легче решить, поскольку при необходимости это в основном обрабатывается вручную для каждого узла. Может потребоваться некоторая пакетная настройка, но в целом это похоже на стандартную ситуацию 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) и т. д.
Итак, можете ли вы порекомендовать простое в использовании, надежное, стабильное, легкое, кросс-платформенное, межъязыковое промежуточное ПО (или другое) решение, которое отвечало бы всем требованиям? Максимально просто, но не проще.
