Um roundrobin para arquivos recebidos

Question

Um monte de novos arquivos com nomes de arquivos únicos 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, até várias dezenas de megabytes.)

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

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

Cada arquivo recebido 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 pelo caminho.

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

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

¹ Note que estou omitindo intencionalmente informações sobre o modo como os arquivos são transportados para o sistema de arquivos. A razão é 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 cortar a interface entre clusters no nível do sistema de arquivos, mas se uma ou outra solução realmente exigir algum transporte específico, os transportes herdados podem ser atualizados para esse.

    

Answer 1

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

1. Os arquivos são HTTP POSTados para um endereço DNS específico da Round-Robin.
2. O sistema POSTing dos arquivos, em seguida, descarta uma tarefa 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 do OpenStack Swift.
   • Os balanceadores de carga possuem dois ou mais servidores de armazenamento de objeto do OpenStack Swift atrás deles.
   • 'Round Robin não é HA' pode ser se os alvos forem eles mesmos. YMMV.
   • Para maior durabilidade, os IPs nos RRDNS podem ser clusters de LB em espera a quente individuais.
4. O servidor de armazenamento de objetos que realmente obtém o POST entrega o arquivo a um sistema de arquivos baseado no Gluster.
   • O sistema Gluster deve ser distribuído (a.k.a. sharded) e Replicated. Isso permite escalar para densidades bobas.
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 o sucesso / falha conforme necessário.
   • O processamento do modo de falha não está diagramado aqui. Essencialmente, continue tentando até que funcione. E se nunca funcionar, passe por um processo de exceções.
7. Quando o backup estiver concluído, o AMQP enviará o trabalho de processamento para um nó de processamento disponível.
8. O nó de processamento envia 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.

Esta configuração deve ser capaz de ingerir arquivos a taxas extremas de velocidade, considerando servidores suficientes. Obter 10GbE velocidades agregadas de ingestão deve ser factível se você upsize o suficiente. Obviamente, processamento que muitos dados que são rápidos exigirão ainda mais servidores em sua classe Processing machine. Esta configuração deve escalar até mil nós, e provavelmente além (embora até que ponto depende do que, exatamente, você está fazendo com tudo isso).

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

    

Answer 2

Dado que você esclareceu que os arquivos chegarão via scp, não vejo nenhum motivo para que o servidor front-end exista, já que 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 para trás e uma política de redirecionamento round-robin. Isso torna muito fácil adicionar e subtrair servidores de / para o pool, aumenta a confiabilidade porque não há um servidor front-end para cair, e isso significa que não precisamos abordar a questão pull / push sobre como obter os arquivos de 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 de arquivamento, processe o arquivo e envie-o a caminho.