Você realmente deve considerar o DRBD (RAID-1 sobre TCP / IP) com um sistema de arquivos de vários nós, como OCFS ou GFS.
Você também pode considerar obter uma SAN na qual poderá colocar qualquer um desses sistemas de arquivos também.
Eu tenho uma solução web de 3 camadas como esta:
Por isso, estou trabalhando em uma solução com alta disponibilidade para os servidores da Web no back-end. Minha idéia é replicar o conteúdo entre os servidores de backend e, se um falhar, o outro servirá todos os sites (isso pode ser manual ou usar o Heartbeat).
O problema é que os sites são grandes em termos de tamanho total e número de arquivos. Eu tento replicar o conteúdo entre servidores com rsync mas demora muito tempo. Também pensei em usar o NFS para compartilhar o conteúdo, mas isso não é uma opção para alta disponibilidade. Outra maneira é que o sistema de publicação envie conteúdo para ambos os servidores da web, mas o que acontecerá se eu colocar outro servidor da web no backend?
Existe uma maneira melhor de fazer isso? Eu não preciso dos dois servidores que servem o mesmo conteúdo ao mesmo tempo, mas ter o mesmo conteúdo sincronizado é uma obrigação.
Use uma SAN em vez de um servidor NFS, o RAID lidará com a alta disponibilidade.
Você pode usar o HAProxy + Keepalived para os balanceadores de carga. Para a replicação pense em link ótico, se a ethernet não for eficiente para as suas necessidades. O RSync é um IMAO muito eficiente (com as opções "-z" que comprimem os dados, ele é muito eficiente). Pelo menos, se você quiser um desempenho ALTO, você pode hospedar os dois Apache como VMs no mesmo servidor, e adicionar alguns discos legais (15K rpm) com um bom cartão RAID. Isso deve fornecer a disponibilidade que você está procurando
Eu uso o Heartbeat2 no Debian Lenny para failover e funciona muito bem. Eu tenho um aplicativo da web que está sendo atendido por um servidor da Web, que fará failover para outro se houver um problema (por exemplo, um cluster ativo-passivo de 2 nós). Os dados da aplicação web estão no sistema de arquivos e também em um banco de dados MySQL. Usamos o MySQL no modo de replicação Master-Master para manipular o espelhamento dos dados do aplicativo de banco de dados. O resto é tratado pelo rsync quando nós enviamos uma atualização ao vivo. Este set-up tem trabalhado na produção nos últimos 6 meses e funcionou bem em incidentes reais. Acho que adicionamos mais 9 ao nosso tempo de atividade geral devido a isso.
Estou surpreso que seu rsync esteja demorando muito, já que seus servidores da Web estão presumivelmente no mesmo datacenter ou no mesmo país, a menos que sejam arquivos grandes como ISOs. Pode valer a pena verificar quais opções de rsync você está usando para ver se isso pode ser otimizado.