Transferir muitos arquivos entre servidores de processamento de trabalhos

Question

Eu tenho o servidor A que funciona em uma parte de um trabalho e gera um arquivo como saída. O servidor B trabalha na segunda parte do trabalho, mas precisa do arquivo que o Serviço A gerou.

Qual é a melhor maneira de obter o arquivo do Servidor A para o Servidor B? Isso acontecerá muitas vezes e possivelmente haverá várias transferências ao mesmo tempo.

(Esses arquivos são quase sempre < 50KB, mas podem ter até 15MB)

Eu sei que eu poderia usar rsync ou scp, mas estou preocupado com a eficiência com essas transferências acontecendo com tanta frequência. Isso é uma preocupação válida?

Eu também olhei para a opção do NFS, mas eu preciso da capacidade de especificar facilmente diferentes servidores e não parece inteligente montar um novo nfs toda vez que eu preciso definir um novo servidor.

Não é bonito, mas por enquanto o que tenho feito é apenas colocar os arquivos em http em um script que os grava no sistema de arquivos. A idéia era reescrever isso como um simples cliente / servidor e cortar o servidor web dele. Mas eu pensei que deveria haver uma ferramenta existente que faz algo semelhante.

    

Answer 1

Há duas perguntas aqui. O primeiro é o óbvio, onde você quer compartilhar arquivos entre servidores. Você deve ser capaz de usar o NFS, ou algum tipo de sistema de arquivos em cluster como gluster para fazer isso. Sim, você terá que alterar as configurações conforme adiciona os servidores.

O tipo de segunda pergunta é como você enviaria essa alteração de configuração para todos os servidores em questão à medida que você adiciona servidores. Esse é mais o domínio dos sistemas de gerenciamento de configurações , como puppet ou chef . Com algo parecido, gerenciar a configuração do gluster entre os vários Server As e o Server Bs pode ser feito de forma centralizada, com mais controle de versão, etc.

Como alternativa, você também pode usar o armazenamento externo para os arquivos de rascunho, como o Servidor A os envia para o Amazon S3 e o Servidor B a partir desse local comum. É difícil dizer se essa é uma opção viável sem saber mais sobre sua situação.

    

Answer 2

O melhor caminho é totalmente subjetivo.

Para mim, a melhor maneira é, seja qual for de forma confiável e verificável, obter o arquivo do ServerA para o ServerB, usando as ferramentas com as quais estou mais familiarizado / posso dar suporte mais facilmente.

Como tal, eu enviaria o arquivo (no seu caso, provavelmente com rsync) e um arquivo hash associado (MD5, SHA1, etc) e, em seguida, o trabalho em sua tarefa ServerA para fazer isso automaticamente. Em seguida, eu iria trabalhá-lo em seu trabalho ServerB para verificar o arquivo de dados usando o arquivo de hash e continuar o processo.

Eu provavelmente também gostaria de garantir que o ServerB não comece a trabalhar em um arquivo parcialmente transferido, então eu provavelmente recorreria a copiar para um diretório 'staging' no ServerB, e então mover para um diretório 'ready' - escolhendo apenas para pesquisar ou inotificar o diretório "pronto".

Depois que isso acontecer, seu trabalho imediato estará concluído e você poderá continuar com os principais marcos de seu projeto e voltar a acelerar o transporte mais tarde.

O máximo que posso fazer nos estágios iniciais é estruturar os diretórios no ServerA, para que eu possa dizer o que está sendo gerado no ServerA e o que está sendo copiado para o ServerB; provavelmente com um diretório 'pendente' no qual o ServerA grava, um diretório 'copiando' para o qual o ServerA move o arquivo final e do qual os processos hashing / rsync pegam o arquivo, e um diretório 'archive' para o qual o ServerA move o arquivo é feito copiando para o ServerB. Dessa forma, posso ter uma idéia aproximada da latência / tamanho da fila, verificando o número de arquivos na pasta "copiar".

Se você achar que precisa melhorar os tempos de transferência, provavelmente descobrirá que otimizar sua pilha de rede será a melhor maneira de fazê-lo. Canais mais gordos entre os servidores estarão em ordem (por exemplo, atualizando 100Mb / s para 1Gb / s ou mesmo 10Gb / s). Você pode ser tentado a unir várias interfaces de rede, mas, se fizer isso, certifique-se de que seu algoritmo de ligação não esteja escolhendo a mesma interface sempre com base em endereços IP de origem e de destino (ou outros critérios que não mudem - mesmo A porta IP + para o destino IP + porta não oferecerá maior rendimento, a menos que você possa abrir várias conexões simultâneas a partir de diferentes portas de origem e paralelizar o processo de cópia).

Se você ainda achar o transporte um gargalo proibitivo, procure eliminá-lo no caminho de atualização. Tente refatorar para que os trabalhos no ServerA e no ServerB possam ser executados pelo ServerC mais novo e robusto. Se for que é importante para o gerenciamento que esses arquivos sejam processados rapidamente, será um tempo de revisão do projeto bastante fácil de vender.