Opções para sincronizar eficientemente 1 milhão de arquivos com servidores remotos?

Question

Na empresa em que trabalho, temos uma coisa chamada "listas de reprodução", que são arquivos pequenos de 100 a 300 bytes cada. Há cerca de um milhão deles. Cerca de 100.000 deles são trocados a cada hora. Essas listas de reprodução precisam ser enviadas para 10 outros servidores remotos em diferentes continentes a cada hora, e isso precisa acontecer rapidamente em menos de dois minutos, de maneira ideal. É muito importante que os arquivos excluídos no master também sejam excluídos em todas as réplicas. Atualmente, usamos o Linux para nossa infraestrutura.

Eu estava pensando em experimentar o rsync com a opção -W para copiar arquivos inteiros sem comparar o conteúdo. Eu não tentei ainda, mas talvez as pessoas que têm mais experiência com o rsync possam me dizer se é uma opção viável?

Quais outras opções valem a pena considerar?

Atualização: Escolhi a opção lsyncd como a resposta, mas apenas porque era a mais popular. Outras alternativas sugeridas também são válidas à sua maneira.

    

Answer 1

Como as atualizações instantâneas também são aceitáveis, você pode usar lsyncd .
Ele observa diretórios (inotify) e rsync muda para escravos.
Na inicialização, ele fará um rsync completo, o que levará algum tempo, mas depois disso somente as alterações serão transmitidas.
A observação recursiva de diretórios é possível, se um servidor escravo estiver inativo, a sincronização será repetida até que ele retorne.

Se tudo isso estiver em um único diretório (ou em uma lista estática de diretórios), você também pode usar incron .
A desvantagem é que ele não permite a observação recursiva de pastas e você mesmo precisa implementar a funcionalidade de sincronização.

    

Answer 2

Considere o uso de um sistema de arquivos distribuído, como GlusterFS . Sendo projetado com replicação e paralelismo em mente, o GlusterFS pode escalar até 10 servidores com muito mais facilidade do que as soluções ad-hoc envolvendo inotify e rsync .

Para este caso de uso específico, pode-se construir um volume GlusterFS de 10 servidores de 10 réplicas (ou seja, 1 réplica / tijolo por servidor), para que cada réplica seja um espelho exato de todas as outras réplicas no volume. O GlusterFS propagaria automaticamente as atualizações do sistema de arquivos para todas as réplicas.

Os clientes em cada localidade entrariam em contato com o servidor local, portanto, o acesso de leitura aos arquivos seria rápido. A questão chave é se a latência de gravação pode ser mantida aceitavelmente baixa. A única maneira de responder isso é tentar.

    

Answer 3

Eu duvido que rsync funcione para isso da maneira normal, porque a varredura de um milhão de arquivos e a comparação com o sistema remoto 10 vezes levaria muito tempo. Eu tentaria implementar um sistema com algo como inotify que mantém uma lista de arquivos modificados e os envia para os servidores remotos (se essas alterações não forem feitas de outra maneira). Você pode então usar essa lista para identificar rapidamente os arquivos necessários a serem transferidos - talvez até mesmo com o rsync (ou melhor, 10 instâncias paralelas).

Editar: Com um pouco de trabalho, você pode até usar essa abordagem inotify / log watch para copiar os arquivos assim que a modificação acontecer.

    

Answer 4

Mais algumas alternativas:

• Insira um trabalho no RabbitMQ ou Gearman para assíncrona apagar e excluir (ou adicionar) o mesmo arquivo em todos os servidores remotos sempre que você excluir ou adicionar um arquivo no servidor primário.
• Armazene os arquivos em um banco de dados e use a replicação para manter os servidores remotos em sincronia.
• Se você tiver o ZFS, poderá usar Replicação ZFS .
• Algumas SANs têm replicação de arquivos. Não tenho ideia se isso pode ser usado na Internet.

Answer 5

Este parece ser um caso de uso de livro de histórias ideal para o MongoDB e talvez GridFS . Como os arquivos são relativamente pequenos, o MongoDB sozinho deve ser suficiente, embora possa ser conveniente usar a API GridFS.

O MongoDB é um banco de dados nosql e o GridFS é uma construção de armazenamento de arquivos sobre ele. O MongoDB tem muitas opções embutidas para replicação e sharding , por isso deve ser muito bem dimensionado no seu caso de uso.

No seu caso, você provavelmente começará com um conjunto de réplicas que consiste no mestre localizado em seu datacenter primário (talvez um segundo, no caso de você querer fazer um failover no mesmo local) e seus dez "escravos" distribuídos ao redor do mundo. Em seguida, carregue os testes para verificar se o desempenho de gravação é suficiente e verifique os tempos de replicação para seus nós. Se você precisar de mais desempenho, poderá transformar a configuração em um sharpy (principalmente para distribuir a carga de gravação para mais servidores). O MongoDB foi projetado com o aumento de configurações enormes com hardware "barato", para que você possa adicionar vários servidores de baixo custo para melhorar o desempenho.

    

Answer 6

Eu usaria um back-end do S3 e montaria isso em todos os servidores de que preciso. Dessa forma, todos ficarão em sincronia instantaneamente

    

Answer 7

Uma opção que parece não ter sido mencionada ainda é arquivar todos os arquivos em um arquivo compactado. Isso deve reduzir significativamente o tamanho total e remover toda a sobrecarga que você recebe ao lidar com milhões de arquivos individuais. Ao substituir todo o conjunto de arquivos em uma grande atualização, você também pode ter certeza de que os arquivos removidos são removidos nas réplicas.

A desvantagem é claro que você está transferindo muitos arquivos desnecessariamente. Isso pode ou não ser compensado pelo tamanho reduzido graças à compressão. Também não tenho ideia de quanto tempo levaria para compactar muitos arquivos.