Actualmente estoy buscando un buen middleware para crear una solución para un sistema de monitoreo y mantenimiento. Tenemos la tarea del desafío de monitorear, recopilar datos y mantener un sistema distribuido que consta de hasta 10,000 nodos individuales.

El sistema está agrupado en grupos de 5-20 nodos. Cada grupo produce datos (como un equipo) al procesar los datos del sensor entrante. Cada grupo tiene un nodo dedicado (cajas azules) que actúa como una fachada / proxy para el grupo, exponiendo los datos y el estado del grupo al mundo exterior. Estos grupos están separados geográficamente y pueden conectarse al mundo exterior a través de diferentes redes (uno puede funcionar a través de fibra, otro a través de 3G / satélite). Es probable que experimentemos apagones más cortos (segundos / minutos) y más largos (horas). Los datos son persistidos por cada grupo localmente.

Estos datos deben ser recopilados (de manera continua y confiable) por servidores externos y centralizados (casillas verdes) para su posterior procesamiento, análisis y visualización por parte de varios clientes (casillas naranjas). Además, debemos monitorear el estado de todos los nodos a través de cada nodo proxy de grupo. No es necesario monitorear cada nodo directamente, aunque sería bueno si el middleware pudiera admitir eso (maneja los mensajes de latido / estado desde ~ 10,000 nodos). En caso de falla del proxy, hay otros métodos disponibles para identificar nodos individuales.

Además, debemos ser capaces de interactuar con cada nodo para modificar las configuraciones, etc., pero parece que esto se resuelve más fácilmente, ya que en su mayoría se maneja manualmente por nodo cuando es necesario. Es posible que se necesiten algunos ajustes por lotes, pero en conjunto parece una situación RPC estándar (servicio web o similar). Por supuesto, si el middleware puede manejar esto también, a través de algún mecanismo de Solicitud / Respuesta sería una ventaja.

Requisitos:

1000+ nodos publicando / ofreciendo datos continuosLos datos deben ser confiables (de alguna manera) y continuamente reunidos en uno o más servidores. Es probable que esto se construya sobre el middleware utilizando algún tipo de solicitud / respuesta explícita para pedir datos perdidos. Si esto puede ser manejado automáticamente por el middleware, esto es, por supuesto, una ventaja.Más de un servidor / suscriptor necesita poder conectarse al mismo productor / editor de datos y recibir los mismos datosLa tasa de datos es máxima en el rango de 10-20 por segundo por grupoEl tamaño de los mensajes varía de unos 100 bytes a 4-5 kbytesLos nodos van desde sistemas restringidos incorporados a cajas COTS Linux / Windows normalesLos nodos generalmente usan C / C ++, los servidores y los clientes generalmente C ++ / C #Los nodos no deberían (preferiblemente) necesitar instalar SW o servidores adicionales, es decir, un agente dedicado o servicio extra por nodo es costosoLa seguridad se basará en mensajes, es decir, no se necesita seguridad de transporte

Estamos buscando una solución que pueda manejar la comunicación entre principalmente nodos proxy (azul) y servidores (verde) para la publicación / consulta / descarga de datos y de clientes (naranja) a nodos individuales (estilo RPC) para ajustes de configuración.

Parece que hay muchas discusiones y recomendaciones para la situación revertida; distribuir datos desde el servidor (s) a muchos clientes, pero ha sido más difícil encontrar información relacionada con la situación descrita. La solución general parece ser usar SNMP, Nagios, Ganglia, etc. para monitorear y modificar un gran número de nodos, pero la parte difícil para nosotros es la recopilación de datos.

Hemos analizado brevemente soluciones como DDS, ZeroMQ, RabbitMQ (¿se necesita un intermediario en todos los nodos?), SNMP, diversas herramientas de monitoreo, servicios web (JSON-RPC, REST / Protocol Buffers), etc.

Asi que, ¿tiene alguna recomendación para una solución de middleware (u otro) fácil de usar, robusta, estable, liviana, multiplataforma, multiplataforma que se ajuste a la cuenta? Tan simple como sea posible pero no más simple.