Temos dois servidores do Drupal que read/write para sua própria cópia da mesma pasta (a pasta sites/default/files para aqueles que conhecem um pouco sobre Drupal ). Essas duas pastas devem estar em sincronia. Eu estive procurando algumas opções e aqui está o que eu descobri:
OPÇÃO 1: Rsync nos dois sentidos: não é uma opção
Você precisaria executar rsync nos dois sentidos, porque as duas pastas são modificadas. Contanto que os arquivos sejam modificados, tudo funciona bem, porque você pode usar o -u flag que verifica o tempo de atualização e modifica apenas se a origem for mais recente que o destino. No entanto, porque rsync não mantém um histórico dos arquivos que estão sendo removidos e quando, rsync não saberia o que fazer com os arquivos excluídos em um lado para saber se eles devem ser mantidos do outro lado porque atualizados mais recentemente ou jogado fora também.
OPÇÃO 2: Compartilhamento de rede: OK, mas a E / S aguarda problema de desempenho
Uma opção seria configurar um compartilhamento de rede, removendo as necessidades de sincronização. A desvantagem é a espera de E / S, pois ambos os servidores devem read/write no mesmo disco.
OPÇÃO 3: terceiro servidor com cópia mestre: OK, mas problemas potenciais de condição de desempenho / corrida
Outra opção seria ter um terceiro servidor mantendo uma cópia mestre da pasta. Sempre que uma alteração for feita em um servidor Drupal, a pasta do servidor Drupal será rsync para a cópia principal, contornando o problema levantado na opção 1. Para que isso funcione, você precisaria que as alterações fossem sincronizadas com a cópia principal em ordem de ocorrência nos servidores Drupal, levantando os seguintes problemas:
- P1 : se você sincronizar com o mestre para todas as alterações feitas e as alterações forem freqüentes, os servidores poderão ficar quietos ocupados com o processo de sincronização.
- P2 : mesmo se você iniciar os trabalhos de sincronização em ordem, devido a vários elementos (velocidade de execução do processo, atrasos da rede ...) você não tem garantia de que os arquivos serão sincronizados em ordem a cópia principal.
Q1: Como você resolve os problemas P1 e P2?
Q2: Existem outras abordagens para manter duas pastas remotas em sincronia?
Informações adicionais:
server OS: Ubuntu server 10.04 LTS
Drupal v: Drupal 6.X
Size of sites/default/files: 4.5G
Testei Unison e não funciona como esperado em relação a arquivos excluídos:
[1] Configurando os diretórios
FOLDER1 FOLDER2
file1 (new) (empty)
[2] Em execução do Unison ( unison FOLDER1 FOLDER2 )
FOLDER1 FOLDER2
file ----> file1
= > file1 é copiado de FOLDER1 para FOLDER2
[3] Atualizando os diretórios
FOLDER1 FOLDER2
file1 (removed) file1 (modified)
[4] Execução do Unison novamente ( unison FOLDER1 FOLDER2 )
FOLDER1 FOLDER2
deleted <-?-> changed file1 []
No default command [type '?' for help]
Neste ponto, Unison não sabe se deve excluir file1 de FOLDER2 ou copiá-lo para FOLDER1 . Espero que Unison faça o último como:
-at [2] sabemos os últimos tempos de modificação / acesso de file1 em ambas as pastas e estes são copiados em Unison archives.
-at [4] vemos que file1 está faltando em FOLDER1 , então o tempo levado em conta para a remoção deve ser o último tempo disponível no arquivo (ou seja, o tempo obtido em [2]).
-at [4] também vemos que o último tempo de modificação / acesso de file1 em FOLDER2 é maior que [2] para FOLDER1 , portanto, file1 deve ser copiado de FOLDER2 para FOLDER1 .
Estou tentando comutadores diferentes, como -auto (aceitar automaticamente as ações padrão) e -batch (modo em lote: não faço perguntas), mas ainda assim, Unison não pode tomar essa decisão por si só .
P: Existe uma maneira de executar Unison ou outra ferramenta de acordo com o comportamento que descrevo?
É necessário que você use 2 cópias do Drupal? O Drupal faz muitas consultas por solicitação de página, tendo vários front-ends do Drupal compartilhando um back-end de banco de dados remoto que pode ser uma grande penalidade de desempenho.
Você já pensou em usar vários frontends de cache e um único backend de banco de dados + drupal? O Pressflow é uma versão aprimorada do Drupal que possui integração integrada com o memcached e o Varish (frontend de armazenamento em cache).
Eu acho que você está complicando demais o problema. Tudo o que você precisa é ter algo como o NFS. Assim, um servidor acessará a pasta localmente e outro acessará remotamente via NFS. Eu não acho que o NFS é tão lento, especialmente se os dois servidores são adjacentes uns aos outros dentro da mesma sub-rede.
Outra opção é usar uma replicação no nível do disco, como DRBD .
Usando essas soluções, você pode eliminar a necessidade de sincronizar manualmente as alterações nos dois sentidos.
Para resolver os dois problemas, use o uníssono. É baseado em rsync e está resolvendo o problema com arquivos excluídos.
Estamos usando Gluster em um cenário semelhante (aplicativos Ruby, não Drupal). No seu caso, ambas as máquinas seriam tanto servidores gluster quanto clientes. A instalação do Drupal apontaria para compartilhamento conforme visto pela configuração do cliente. As operações de arquivo no compartilhamento são propagadas por todo o cluster e você deve ser resiliente a um nó que falhe.
Sim, o desempenho de i / o não será tão bom quanto algo mais físico, mas não tenho certeza de como você poderá contorná-lo de acordo com sua configuração.
Como @Khaled mencionou brevemente, você poderia usar o DRBD para isso.
Cada nó tem sua própria cópia local dos dados (assim, as leituras são tão rápidas quanto seu disco local); você pode configurá-lo para que o bloco de gravações seja gravado até que os dados sejam gravados no disco nos outros nós (portanto, há latência que depende da velocidade da sua rede, mas todos os clientes verão uma visualização consistente dos arquivos).