Eu tenho dois servidores web, com a chance de ter que adicionar mais servidores ao longo do caminho. Agora eu mantenho esses servidores em sincronia usando lsyncd + csync2. Ele funciona bem em termos de desempenho, porque todos os arquivos estão em ambos os servidores (não é necessário acesso à rede para abrir arquivos localmente), mas não tão bem em outros casos.
Um exemplo disso é se eu excluir um arquivo no servidor 1 e enviar imediatamente um novo arquivo para o servidor 1 que tenha o mesmo nome. O arquivo seria, então, excluído do servidor 2 enquanto isso, fazendo com que o arquivo recém-carregado no servidor 1 fosse excluído, pois o servidor 2 envia o evento de exclusão para o servidor 1 para concluir o "círculo de atualização".
Não consigo deixar de pensar que deve haver uma maneira melhor de manter os servidores sincronizados. Eu estive olhando para GlusterFS, e vejo que uma configuração onde todos os arquivos são replicados para todos os servidores são desencorajados. No entanto, estou executando sistemas CMS como o Drupal nesses servidores. Esses sistemas CMS geralmente abrem alguns arquivos, e estou preocupado que o excesso de tráfego de rede para obter esses arquivos atrase as solicitações.
Seria uma boa idéia substituir o lsyncd + csync2 pelo GlusterFS para replicar todos os arquivos em todos os nós, ou é uma má idéia?
O BitTorrent Sync pode fazer a ação por você. Eu estou usando para manter os arquivos em sincronia entre alguns servidores internos em minha casa e está fazendo o trabalho maravilhosamente. A outra coisa em que você precisará pensar é no banco de dados de back-end quando seu aplicativo usa um CMS. Certifique-se de que haja replicação do MySQL em andamento ou algo desse tipo.
O Gluster resolveria o problema que você tem, pois ele pode conter os bloqueios, propagar alterações - excluir o arquivo em todos os outros nós, mas pode adicionar latência adicional que pode ser um problema para um servidor da web. A próxima alternativa é DRBD + OCFS2 ou GFS, mas isso provavelmente é mais complexo, pois com gluster você está usando o sistema de arquivos subjacente - ele não opera no nível de bloco, então se os servidores estiverem fora de sincronia não é muito difícil de corrigir, arquivos podem não se corrompa tão facilmente por causa de cérebros divididos, etc ...
Estamos a usá-lo para um servidor de e-mail e é muito lento para diretórios com muitos arquivos. Você definitivamente deve testar tudo antes de implantar. No momento, estou testando a montagem do NFS porque funciona melhor para arquivos pequenos.
O GlusterFS é difícil de implantar. Para dados da web, o nível de sincronização de arquivos, como o Unison , é muito mais fácil de implantar e manter.
ODRBD é uma solução perfeita para manter a sincronização de dados em nível de bloco. Mas você tem que formatá-los para um formato especial como o OCFS2 ou algo semelhante.
Por que você não usa uma ferramenta como o boneco ? Escreva uma vez em uma fonte e, uma vez pronto, implante-o nos alvos usando "puppet kick" ou mcolletive. Está bem documentado. E você pode adicionar servidores mais tarde, se necessário.
Você também pode confiar em ferramentas usando o inotify, como o lsyncd, trabalhando no nível do kernel. Ele observa as alterações em uma pasta e aciona uma sincronização. Mas se uma ferramenta dedicada à sincronização de arquivos em um cluster como o csync2 não for suficiente, não sei o que será.
Só para ter certeza, as modificações também acontecem no servidor 2 ou apenas no servidor 1?