Промежуточное программное обеспечение для построения сбора данных и мониторинга для распределенной системы

Question

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

Система разбита на группы по 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) и т. Д.

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

Answer 1

Кажется, ZeroMQ легко справится с поставленной задачей, не имея центральной инфраструктуры для управления. Поскольку ваши серверы мониторинга исправлены, решить эту проблему довольно просто. Этот раздел в Руководстве 0MQ может помочь:

http://zguide.zeromq.org/page:all

Вы упомянули "надежность", но не могли бы вы указать фактический набор сбоев, которые вы хотите устранить? Если вы используете TCP, то сеть по определению уже "надежная".

Answer 2

Раскрытие информации: я давний специалист / энтузиаст DDS и работаю на одного из поставщиков DDS.

Хорошая реализация DDS предоставит вам то, что вы ищете. Сбор данных и мониторинг узлов является традиционным вариантом использования DDS и должен быть его приятным местом. Взаимодействие с узлами и их настройка также возможны, например, с помощью так называемых фильтров содержимого для отправки данных конкретному узлу. Это предполагает, что у вас есть средство для уникальной идентификации каждого узла в системе, например, с помощью строки или целочисленного идентификатора.

Из-за иерархической природы системы и ее огромного (потенциального) размера, вам, вероятно, придется ввести некоторые механизмы маршрутизации для пересылки данных между кластерами. Некоторые реализации DDS могут предоставить общие услуги для этого. Соединение с другими технологиями, такими как СУБД или веб-интерфейсы, также часто поддерживается.

Особенно, если в вашем распоряжении многоадресная рассылка, обнаружение всех участников системы может быть выполнено автоматически и потребует минимальной настройки. Это не обязательно, хотя.

На мой взгляд, ваша система достаточно сложна, чтобы ее можно было настроить. Я не верю, что какое-либо решение будет "легко соответствовать требованиям", особенно если ваша система должна быть отказоустойчивой и надежной. Прежде всего, вам нужно знать о ваших требованиях. Несколько слов о DDS в контексте тех, что вы упомянули:

Более 1000 узлов публикуют / предлагают непрерывные данные

Это большое число, но оно должно быть возможным, тем более что у вас есть возможность воспользоваться функциями разделения данных, поддерживаемыми DDS.

Данные должны быть надежно (каким-то образом) и постоянно собираться на один или несколько серверов. Скорее всего, он будет построен поверх промежуточного программного обеспечения с использованием какого-либо явного запроса / ответа для запроса потерянных данных. Если это может быть выполнено автоматически промежуточным программным обеспечением, это, конечно, плюс.

DDS поддерживает широкий набор так называемых настроек качества обслуживания (QoS), определяющих, как инфраструктура должна обрабатывать данные, которые она распространяет. Это пары имя-значение, установленные разработчиком. Область надежности и доступности данных среди поддерживаемых QoS. Это должно позаботиться о вашем требовании автоматически.

Более одного сервера / подписчика должны иметь возможность подключаться к одному и тому же производителю / издателю данных и получать одни и те же данные.

Распределение "один ко многим" или "многие ко многим" является распространенным вариантом использования.

Максимальная скорость передачи данных в диапазоне 10-20 в секунду на группу

Можно добавить до 20 000 сообщений в секунду, особенно если потоки данных разделены.

Размер сообщений варьируется от ~100 до 4-5 Кбайт

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

Диапазон узлов от встроенных ограниченных систем до обычных COTS Linux/Windows

Некоторые реализации DDS поддерживают широкий диапазон комбинаций ОС / платформы, которые можно смешивать в системе.

Узлы, как правило, используют C/C++, серверы и клиенты, как правило, C++/C#.

Они обычно поддерживаются и могут быть смешаны в системе.

Узлы не должны (предпочтительно) устанавливать дополнительные ПО или серверы, т. Е. Один выделенный брокер или дополнительная служба на узел стоит дорого

Такие параметры доступны, но необходимость в дополнительных услугах зависит от реализации DDS и функций, которые вы хотите использовать.

Безопасность будет основываться на сообщениях, т. Е. Безопасность транспорта не требуется

Это, безусловно, делает жизнь проще.