Un roundrobin para archivos entrantes

Un grupo de archivos nuevos con nombres de archivo únicos "aparece" regularmente ¹ en un servidor. (Al igual que cientos de GB de datos nuevos al día, la solución debe ser escalable a terabytes. Cada archivo tiene varios megabytes de tamaño, hasta varias decenas de megabytes).

Hay varias máquinas que procesan esos archivos. (Decenas, la solución debería ser escalable a cientos). Debería ser posible agregar y eliminar fácilmente nuevas máquinas.

Hay servidores de almacenamiento de archivos de respaldo en los que cada archivo entrante debe copiarse para el almacenamiento de archivos. Los datos no deben perderse, todos los archivos entrantes deben terminar entregados en el servidor de almacenamiento de respaldo.

Cada archivo entrante debe enviarse a una sola máquina para su procesamiento, y debe copiarse en el servidor de almacenamiento de respaldo.

El servidor receptor no necesita almacenar archivos después de enviarlos en su camino.

Aconseje una solución sólida para distribuir los archivos de la manera descrita anteriormente. La solución no debe basarse en Java. Las soluciones unidireccionales son preferibles.

Los servidores están basados ​​en Ubuntu, se encuentran en el mismo centro de datos. Todas las demás cosas se pueden adaptar a los requisitos de la solución.

¹ Tenga en cuenta que omito intencionalmente información sobre la forma en que los archivos se transportan al sistema de archivos. La razón es que los archivos están siendo enviados por terceros por varios medios heredados diferentes hoy en día (curiosamente, a través de scp y ØMQ). Parece más fácil cortar la interfaz de clúster cruzado en el nivel del sistema de archivos, pero si una u otra solución realmente requerirá un transporte específico, los transportes heredados pueden actualizarse a ese.

Aquí hay una solución para lo que estás buscando. No hay Java involucrado en la fabricación de este sistema, solo bits de código abierto fácilmente disponibles. El modelo presentado aquí puede funcionar con otras tecnologías diferentes a las que estoy usando como ejemplo.

1. Los archivos se envían HTTP a una dirección DNS Round-Robin específica.
2. El sistema que PUBLICA los archivos luego coloca un trabajo en un sistema AMQP (Rabbit MQ aquí), por medio de otro par de equilibradores de carga, para iniciar el flujo de trabajo de procesamiento.
3. Los equilibradores de carga que reciben HTTP POST se encuentran frente a un grupo de servidores de almacenamiento de objetos OpenStack Swift.
   • Los equilibradores de carga tienen cada uno dos o más servidores de almacenamiento de objetos OpenStack Swift detrás de ellos.
   • 'Round Robin no es HA' puede ser si los objetivos son HA mismos. YMMV.
   • Para una mayor durabilidad, las IP en el RRDNS podrían ser clústeres individuales LB en espera.
4. El servidor de Object Store que realmente recibe la POST entrega el archivo a un sistema de archivos basado en Gluster.
   • El sistema Gluster debe ser distribuido (también conocido como fragmentado) y replicado. Esto le permite escalar a densidades tontas.
5. El sistema AMQP envía el primer trabajo, hacer la copia de seguridad, a un nodo de procesamiento disponible.
6. El nodo de procesamiento copia el archivo desde el almacenamiento principal al almacenamiento de respaldo e informa el éxito / fracaso según sea necesario.
   • El procesamiento del modo de falla no está diagramado aquí. Básicamente, sigue intentándolo hasta que funcione. Y si nunca funciona, ejecute un proceso de excepciones.
7. Una vez que se completa la copia de seguridad, AMQP envía el trabajo de procesamiento a un nodo de procesamiento disponible.
8. El nodo de procesamiento extrae el archivo a su sistema de archivos local o lo procesa directamente desde Gluster.
9. El nodo de procesamiento deposita el producto de procesamiento donde sea que vaya e informa el éxito a AMQP.

Esta configuración debería poder ingerir archivos a velocidades de velocidad extremas dados suficientes servidores. Obtener velocidades de ingesta agregadas de 10 GbE debería ser factible si lo aumenta demasiado. Por supuesto, procesar esa cantidad de datos tan rápido requerirá aún más servidores en su clase de máquina de procesamiento. Esta configuración debería escalar hasta mil nodos, y probablemente más allá (aunque hasta qué punto depende de qué, exactamente, estás haciendo con todo esto).

Los profundos desafíos de ingeniería estarán en el proceso de gestión del flujo de trabajo oculto dentro del proceso AMQP. Eso es todo software, y probablemente creado a medida para las demandas de su sistema. ¡Pero debería estar bien alimentado con datos!

Dado que ha aclarado que los archivos llegarán a través de scp, no veo ninguna razón para que exista el servidor front-end, ya que el mecanismo de transporte es algo que se puede redirigir en la capa 3.

Pondría un director LVS (par) al frente, con un grupo de servidores de procesamiento detrás y una política de redireccionamiento de turnos. Eso hace que sea muy fácil agregar y restar servidores al grupo, aumenta la confiabilidad porque no hay un servidor front-end que se caiga, y significa que no tenemos que abordar la pregunta pull / push sobre cómo obtener los archivos de el front-end a los servidores de procesamiento porque no hay front-end.

Cada servidor de grupo debe hacer dos cosas al recibir un archivo: en primer lugar, copiarlo en el almacenamiento de archivo, luego procesar el archivo y enviarlo en su camino.