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


21

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

Por bidirecional, quero dizer que alterações podem ocorrer em um servidor e precisam ser enviadas para o outro, para que o rsync não pareça apropriado.

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

Em tempo real, não há problema em haver uma pequena latência entre a sincronização, mas executar um cron a cada 1-2 minutos não parece certo, pois uma fração muito pequena dos arquivos pode mudar a qualquer hora, e muito menos.

EDIT : Isso está sendo executado nos VPS, então eu posso estar limitado nos tipos de coisas no nível do kernel que posso fazer. Além disso, os VPSs não são ricos em recursos; portanto, evito soluções que exijam muita memória RAM (como o Gluster?).

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

Encontrei o lsyncd para acionar uma sincronização no nível de alteração do sistema de arquivos. Isso parece inteligente, embora não seja super comum, e estou um pouco confuso com as várias abordagens lsyncd. Há apenas o uso de lsyncd com o rsync, mas parece que isso pode ser frágil para a bidirecionalidade, já que o rsync não tem 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). lipsync parece ser apenas uma implementação lsyncd + rsync, certo?

Depois, use lsyncd com csync2 , assim: https://icicimov.github.io/blog/devops/File-system-sync-with-Csync2-and-Lsyncd/ ... Estou inclinado a essa abordagem, mas O csync2 é um pouco peculiar, embora eu tenha feito um teste bem-sucedido. Estou principalmente preocupado por não ter conseguido encontrar muita confirmação da comunidade sobre esse método.

As pessoas aqui parecem gostar muito do Unison, mas parece que ele não está mais em desenvolvimento ativo e não está claro que ele tenha um gatilho automático como o lsyncd.

Eu vi Gluster mencionado, mas talvez exagero pelo 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 unidos de maneira muito vaga, para que cada servidor possa operar indefinidamente por conta própria, independentemente da qualidade do link entre eles.


Com que tipo de alterações você precisa lidar? Criação, exclusão, modificação de EG.
sciurus

Além disso, você espera conflitos? O mesmo arquivo pode ser modificado nos dois servidores?
sciurus 16/09

Todas as alterações: criação, exclusão, modificação. Existe um potencial para conflitos, mas eles devem ser raros. Eu não me importaria se eu simplesmente recebesse um alerta sobre um conflito que eu tenho que resolver manualmente.
dlo 17/09/11

Respostas:


5

DRBD no modo Dual-primário com um Proxy é uma opção.


O Proxy parece não ser de código aberto nem gratuito, certo? Não sei se entendi a conseqüência de não ter um Proxy no modo assíncrono: durante um tempo de inatividade prolongado, se não houver Proxy, o buffer de saída [pequeno?] Poderá ser preenchido e perderemos a sincronização? É difícil se recuperar disso?
dlo

Veja minha resposta acima. Eu não acho que o proxy é o que você precisa. Mesmo durante um pequeno tempo de inatividade, o drbd-meta-device marcará blocos "sujos" e os transferirá depois que a conexão for reiniciada. Eu acho que a principal diferença entre proxy e modo assíncrono é que o modo assíncrono usa um buffer máximo de alguns MBs. Depois disso, ele é sincronizado antes de preencher o buffer novamente. É provável que o proxy permita um buffer maior (necessário se você tiver grande latência ou puder gravar muito mais rápido localmente do que remoto).
Nils

2

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


2
NFS é horrível, apenas horrível. Qualquer coisa seria melhor do que NFS
AliGibbs

2
Um dos pontos principais da configuração de vários servidores é o failover / redundância. Portanto, um servidor deve poder continuar sem o outro.
dlo 14/09/11

Você deveria ter mencionado isso na sua pergunta então - não há necessidade de votar uma resposta perfeitamente razoável!
Bart B

Para sua informação, não diminuí o voto - alguém o fez. Mas sim, eu deveria ter mencionado isso para começar.
dlo 14/09/11

@ Bart: Bem - ele mencionou que há acesso simultâneo em dois sites distantes. Portanto, mesmo se você colocar o HA-NFS, isso seria uma solução ruim, pois um lado sofreria de latência durante o acesso ao NFS. E eu também não votei. Mas sou administrador do NFS há tempo suficiente para suportar o AliGibbs. : - /
Nils

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 poderá lidar melhor com um nó desativado.

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


Gluster requer 1 GB de RAM? gluster.com/community/documentation/index.php/… ... Também estou em um VPS, portanto, não tenho certeza sobre como fazer alterações no nível do kernel que o AFS possa exigir. Mas estou começando a ver que um fs distribuído adequado é o melhor caminho.
dlo

Sim, desculpe por não ter percebido anteriormente que você estava usando hosts VPS. As pegadas de memória do Gluster, tanto servidor quanto cliente, não são pequenas e podem crescer substancialmente. DRBD parece mais apropriado.

O AFS é o caminho a percorrer.
Anthony Giorgio

2

No seu caso, eu recomendaria uma combinação de DRBD no modo primário primário e gfs ou ocfs.

A desvantagem do DRBD no dual-primário é que ele estará sendo executado no modo síncrono. 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.


1
O modo síncrono seria ruim - não preciso dele e não quero prejudicar o desempenho, pois os servidores estão conectados por uma WAN em todos os continentes. Mas você não pode ter o primário primário no modo assíncrono?
dlo

Atualmente, estou usando o DRBD 8.3.5 - é preciso estar no modo de sincronização ("C") para entrar no modo primário duplo. Não tenho experiência pessoal com o proxy DRBD, mas parece ser semelhante ao Veritas Volume Replicator - mas isso não é adequado, pois você deseja acesso de gravação nos dois lados. O modo de sincronização no nível do bloco pode não ser tão ruim quanto você pensa - talvez gfs e / ou ocfs possam armazenar em buffer as gravações.
Nils

Acabei de verificar um artigo em alemão comparando o GFS2 e o OCFS2. Pelo menos, o OCFS2 parece oferecer suporte ao sistema de arquivos em buffer. O GFS2 é recomendado nesse artigo, pois é mais antigo. Consulte a documentação do RedHat no GFS2 para obter detalhes sobre o GFS2 - ele também usa buffer - mas você deve usar diretórios diferentes para gravações simultâneas para obter o melhor desempenho.
Nils

0

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

Eu acho que consideraria colocar a árvore inteira sob controle de versão ( Subversion , por exemplo) e fazer check-in / atualização periódica de ambos os servidores nos trabalhos cron.


0

Tendo acabado de terminar uma busca em relação à mesma coisa, vou com gluster. No entanto, eu não fiz ou encontrei nenhum teste de desempenho.

Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.