Um roundrobin para arquivos recebidos

Um monte de novos arquivos com nomes de arquivos exclusivos regularmente "aparece" ¹ em um servidor. (Como centenas de GB de novos dados diariamente, a solução deve ser escalável para terabytes. Cada arquivo tem vários megabytes de tamanho, até várias dezenas de megabytes.)

Existem várias máquinas que processam esses arquivos. (Dezenas, a solução deve ser escalável para centenas.) Deve ser possível adicionar e remover facilmente novas máquinas.

Existem servidores de armazenamento de arquivos de backup nos quais cada arquivo recebido deve ser copiado para armazenamento de arquivo. Os dados não devem ser perdidos, todos os arquivos recebidos devem ser entregues no servidor de armazenamento de backup.

Cada arquivo recebido myst deve ser entregue em uma única máquina para processamento e deve ser copiado para o servidor de armazenamento de backup.

O servidor receptor não precisa armazenar arquivos depois de enviá-los a caminho.

Por favor, informe uma solução robusta para distribuir os arquivos da maneira descrita acima. A solução não deve ser baseada em Java. Soluções Unix-way são preferíveis.

Os servidores são baseados no Ubuntu, estão localizados no mesmo data center. Todas as outras coisas podem ser adaptadas para os requisitos da solução.

¹ Observe que omiti intencionalmente informações sobre como os arquivos são transportados para o sistema de arquivos. O motivo é que os arquivos estão sendo enviados por terceiros por diversos meios legados hoje em dia (estranhamente, via scp e via ØMQ). Parece mais fácil reduzir a interface de cluster cruzado no nível do sistema de arquivos, mas se uma ou outra solução exigir algum transporte específico - os transportes herdados podem ser atualizados para esse.

Aqui está uma solução para o que você está procurando. Nenhum java está envolvido na criação deste sistema, apenas bits de código aberto prontamente disponíveis. O modelo apresentado aqui pode funcionar com outras tecnologias além das que estou usando como exemplo.

1. Os arquivos são HTTP POSTed para um endereço DNS Round-Robin específico.
2. O sistema POSTANDO os arquivos solta um trabalho em um sistema AMQP (Rabbit MQ aqui), por meio de outro par de balanceadores de carga, para iniciar o fluxo de trabalho de processamento.
3. Os balanceadores de carga que recebem o HTTP POST estão cada um na frente de um grupo de servidores de armazenamento de objetos OpenStack Swift.
   • Cada um dos balanceadores de carga possui dois ou mais servidores de armazenamento de objetos OpenStack Swift atrás deles.
   • 'Round Robin não é HA' pode ser se os alvos forem HA. YMMV.
   • Para maior durabilidade, os IPs no RRDNS podem ser clusters LB individuais de espera a quente.
4. O servidor do Object Store que realmente obtém o POST entrega o arquivo em um sistema de arquivos baseado no Gluster.
   • O sistema Gluster deve ser distribuído (também conhecido como sharded) e replicado. Isso permite escalar para densidades tolas.
5. O sistema AMQP despacha o primeiro trabalho, faça o backup, para um nó de processamento disponível.
6. O nó de processamento copia o arquivo do armazenamento principal para o armazenamento de backup e relata êxito / falha, conforme necessário.
   • O processamento no modo de falha não é diagramado aqui. Essencialmente, continue tentando até que funcione. E se nunca funcionar, execute um processo de exceções.
7. Após a conclusão do backup, o AMQP despacha o trabalho de processamento para um nó de processamento disponível.
8. O nó de processamento puxa o arquivo para seu sistema de arquivos local ou o processa diretamente do Gluster.
9. O nó de processamento deposita o produto de processamento onde quer que vá e reporta o sucesso ao AMQP.

Essa configuração deve poder ingerir arquivos a taxas extremas de velocidade, considerando servidores suficientes. A obtenção de velocidades de ingestão agregada de 10 GbE deve ser possível se você aumentar o tamanho suficiente. Obviamente, processar tantos dados com tanta rapidez exigirá ainda mais servidores na sua classe de máquinas de processamento. Essa configuração deve escalar até mil nós e provavelmente além (embora até que ponto dependa exatamente do que você está fazendo com tudo isso).

Os profundos desafios de engenharia estarão no processo de gerenciamento de fluxo de trabalho oculto dentro do processo AMQP. Isso é tudo software, e provavelmente construído sob medida para as demandas do seu sistema. Mas deve ser bem alimentado com dados!

Dado que você esclareceu que os arquivos chegarão via scp, não vejo nenhum motivo para a existência do servidor front-end, pois o mecanismo de transporte é algo que pode ser redirecionado na camada 3.

Eu colocaria um diretor LVS (par) na frente, com um pool de servidores de processamento atrás e uma política de redirecionamento round-robin. Isso facilita muito adicionar e subtrair servidores de / para o pool, aumenta a confiabilidade porque não há servidor front-end para cair e significa que não precisamos resolver a questão de obter / enviar sobre como obter os arquivos o front-end para os servidores de processamento porque não há front-end.

Cada servidor de pool deve fazer duas coisas ao receber um arquivo - primeiro, copie-o para o armazenamento em arquivo, processe o arquivo e envie-o a caminho.