Solución Java de código abierto para distribuir trabajos e iniciar múltiples trabajadores JVM

Meta

Estoy buscando una solución Java de código abierto que se pueda usar en un grupo pequeño (2-4) de máquinas Linux. Puede pensar en esto como una granja de servidores de trabajo de procesamiento que solo escuchan un mensaje de un punto final JMS para comenzar a procesar.

Requisitos

Esta biblioteca/solución/lo que sea debe poder desencadenar entre 10 y 20 procesos en cada máquina del clúster (cada uno es una JVM). Cada proceso consumirá un mensaje de una instancia de JMS centralizada y guardará los resultados del trabajo en una instancia de DBMS centralizada. Cada proceso tarda varios minutos (de 5 a 50 minutos) en completarse y ocupa poco espacio en términos de uso de red, E/S de disco, CPU y memoria. Cada trabajo es independiente. La biblioteca solo debe ayudar a administrar esta asignación/desasignación de procesos JVM y proporcionar algunas estadísticas y control mínimos. No es necesario pausar/reanudar/cancelar trabajos. Solo necesito saber cuándo se están ejecutando o no, y si se completó con éxito o no. Mantener los servidores de trabajadores inactivos no es un problema.

Importante : no estoy buscando PaaS ni ninguna solución basada en la nube.

Que sé yo

Inicialmente, consideré la idea de simplemente iniciar un montón de instancias de tomcat, pero parece excesivo y tendría que proporcionar a cada uno de ellos puertos diferentes. No es un problema de divide y vencerás, por lo que no estoy buscando soluciones de reducción de mapas. Tampoco es algo que se resuelva usando hadoop (supongo). Pero confieso que sé poco sobre este tipo de soluciones. He leído un poco sobre JavaSpaces y RMI, pero parece que estos son componentes básicos para soluciones distribuidas. También he oído hablar de los microservicios, pero parecen algo más útil para la orquestación de diferentes partes de un proceso completo. También revisé memcache, hazelcast, terracota, pero están destinados a resolver una clase diferente de problema.

Mi sensación

es que este es un tipo de problema bien conocido con varias soluciones interesantes, pero no sé exactamente cómo se llama (y luego no puedo buscarlo en Google correctamente).

¿No están Apache YARN, Mesos, etc. tratando de hacer exactamente esto (y un poco más: administrar la asignación de recursos)?
@Anony-Mousse le echará un vistazo, ¡gracias por avisarnos!

Respuestas (2)

No conozco una solución preparada para este problema (y no tiene un nombre elegante), pero preferiría configurarlo yo mismo (en Java). Además, mis habilidades de JMS están "en desarrollo", por lo que podría haber mejores soluciones, que combinen las partes 1 y 2. Y no estoy muy seguro de haber entendido bien tu problema.

Supongo que los trabajadores manejan sus conexiones de base de datos por sí mismos, así que no lo daré cuenta.

Primera parte: El distribuidor: un bean controlado por mensajes que consume sus mensajes JMS y los maneja. Como no desea un servidor de aplicaciones en todas las máquinas, ahora solo necesita uno.

Segunda parte: El frontworker: un programa Java que se ejecuta en cada máquina y mantiene abierto un puerto para la comunicación con el distribuidor. Necesitan algún formato de intercambio, RMI es la solución más directa en mi experiencia para esto.

Tercera parte: El trabajador - Comienza con el trabajador frontal. Están en la misma máquina así que, meh. Toda la información que necesita el trabajador la proporciona el trabajador frontal de alguna manera (base de datos, consola, archivo, lo que sea). Los trabajadores se insertan en la base de datos cuando se inician, se detienen y fallan.

Última parte: El monitor - lee la base de datos. Los datos se muestran con una tabla simple. Fancy Reports tal vez a través de JasperReports.

Dataflow sería así: el proveedor de datos JMS envía sus mensajes que son consumidos por el distribuidor. El distribuidor verifica opcionalmente qué servidor tiene la menor cantidad de trabajadores en ejecución actualmente o simplemente hace un round-robin. Luego abre la conexión RMI al frontworker en este servidor específico y entrega la información JMS. El frontworker inicia un proceso de trabajo con la información. Cada trabajador ingresa sus datos a la base de datos independientemente uno del otro.

El monitor se usaría independientemente de esto y solo leería la base de datos del trabajo que realizan los trabajadores.

Hola Angelo, tiene mucho sentido. Después de investigar un poco, creo que voy a usar una estrategia como esa, pero fusionando el distribuidor y el frontworker, porque el frontworker puede leer directamente desde el JMS. La parte que me interesa especialmente en su idea es cómo el frontworker iniciaría al trabajador. ¿Generador de procesos? Gracias por tu ayuda.

Usaría el planificador de cuarzo para esto.

Lo he usado con éxito en el pasado y aparentemente tiene un modo de clúster (que no he probado). Realiza balanceo de carga y puede usar cualquier base de datos JDBC para la coordinación.

Es de código abierto, escrito en Java.