Sincronização bidirecional em tempo real da grande árvore de arquivos entre dois servidores linux distantes

22

Por árvore de arquivos grande eu quero dizer cerca de 200k arquivos, e crescendo o tempo todo. Um número relativamente pequeno de arquivos está sendo alterado em uma determinada hora.

Por bidirecional, quero dizer que as alterações podem ocorrer em qualquer servidor e precisam ser enviadas para o outro, portanto, o rsync não parece apropriado.

De longe, quero dizer que os servidores estão em data centers, mas geograficamente distantes um do outro. Atualmente existem apenas 2 servidores, mas isso pode se expandir com o tempo.

Em tempo real, não há problema em que haja um pouco de latência entre as sincronizações, mas executar um cron a cada 1-2 minutos não parece certo, já que uma fração muito pequena dos arquivos pode mudar em qualquer hora. só minuto.

EDIT : Isso está sendo executado em VPSs, então eu posso estar limitado nos tipos de coisas no nível do kernel que eu posso fazer. Além disso, os VPSs não são ricos em recursos, então eu fugiria de soluções que exigem muitos recursos (como o Gluster?).

Qual é a melhor / mais "aceita" abordagem para fazer isso? Isso parece ser uma necessidade comum, mas ainda não consegui encontrar uma abordagem geralmente aceita, o que foi surpreendente. (Estou procurando a segurança das massas.)

Encontrei lsyncd para acionar uma sincronização no nível de mudança do sistema de arquivos. Isso parece inteligente, embora não seja muito comum, e estou um pouco confuso com as várias abordagens do lsyncd. Há apenas usando lsyncd com rsync, mas parece que isso poderia ser frágil para bidirecionalidade desde rsync não tem uma noção de memória (por exemplo, para saber se um arquivo excluído em A deve ser excluído em B ou se é um novo arquivo em B que deve ser copiado para A). o lipsync parece ser apenas uma implementação do lsyncd + rsync, certo?

Depois, há usando o lsyncd com csync2 , assim: link ... Estou inclinado a essa abordagem, mas o csync2 é um pouco peculiar, embora eu tenha um teste bem sucedido. Eu estou mais preocupado que eu não tenha conseguido encontrar muita confirmação da comunidade sobre este método.

As pessoas daqui parecem gostar muito do Unison, mas parece que ele não está mais em atividade desenvolvimento e não está claro que ele tem um acionador automático como o lsyncd.

Eu vi Gluster mencionado, mas talvez exagero para o que eu preciso?

UPDATE: fyi- Acabei indo com a solução original que mencionei: lsyncd + csync2. Parece funcionar muito bem, e eu gosto da abordagem arquitetônica de ter os servidores muito unidos, de modo que cada servidor possa operar indefinidamente sozinho, independentemente da qualidade do link entre eles.

    
por dlo 14.09.2011 / 15:43

6 respostas

5

DRBD em Modo dual-primário com um Proxy é uma opção.

    
por 16.09.2011 / 18:48
2

Em vez de sincronizar, por que não compartilhar o mesmo sistema de arquivos pelo NFS?

    
por 14.09.2011 / 16:22
2

A implementação de um sistema de arquivos distribuído provavelmente é melhor do que hackear isso junto com ferramentas e scripts, especialmente se o cluster de servidores crescer. Você também será capaz de lidar melhor com um nó abatido.

Eu não acho que o Gluster (ou AFS) seja um exagero.

    
por 16.09.2011 / 17:34
2

No seu caso, eu recomendaria uma combinação de DRBD em dual-primary-mode e gfs ou ocfs.

A desvantagem do DRBD em dual-primary é que ele estará rodando em modo syncronous. Mas a velocidade de gravação não parece ser importante aqui, certo?

Uma alternativa ao DRBD pode ser um Soft-Raid1 usando muitos (2+) iSCSI-Targets - mas eu preferiria o DRBD com dois nós.

    
por 16.09.2011 / 23:11
0

Como demonstrado acima, muitas soluções estão disponíveis, cada uma com suas vantagens e desvantagens.

Acho que eu consideraria colocar a árvore inteira sob controle de versão ( Subversion , por exemplo) e verificar / atualizar periodicamente a partir de ambos servidores em tarefas agendadas.

    
por 19.09.2011 / 22:56
0

Tendo acabado de terminar um pouco de uma busca sobre a mesma coisa, eu vou com gluster. No entanto, não fiz ou encontrei nenhum teste de desempenho.

    
por 23.09.2011 / 15:24