Dependendo da complexidade de sua configuração e da frequência com que o conteúdo muda, há várias opções que você pode seguir.
O rsync é uma boa opção para sincronizar nós, mas você tem um problema quando os nós podem estar ativos ou inativos. Uma configuração comum pode executar um cron job em cada nó para extrair os dados de um nó 'principal', mas se esse nó mestre cair, você precisará escolher um novo 'líder' e partir daí. Se você estiver atribuindo manualmente um nó mestre, com a suposição de que nenhuma alteração ocorrerá quando estiver inoperante, você poderá ter seu trabalho cron apenas nesse nó e sincronizar para cada um dos outros nós. O Cron sempre experimentará um pouco de atraso, já que você está executando a tarefa periodicamente.
Uma versão ligeiramente melhor do que foi dito acima - que ainda sofre com os problemas de lidar com falhas de nós, mas é mais 'instantâneo' é usar incron . Isso pode ser configurado para acionar seu script rsync quando o conteúdo de um diretório for alterado e, portanto, reduzirá bastante o tempo em que os nós estão fora de sincronia.
Se você está preocupado apenas com o fato de seu código estar em sincronia, seu software de controle de versão deve permitir que você configure um gancho de pós-consolidação. Para a subversão , o processo seria essencial:
- Crie um repositório no seu servidor
- Importe seus arquivos para o repositório
- Confira uma cópia de trabalho no nó principal
- Configure um gancho de pós-confirmação que atualizará os nós (por exemplo, via rsync)
- Confira uma cópia de trabalho em sua máquina local Faça as alterações e envie-as para o repositório (svn commit) - o hook executará automaticamente o script e atualizará os nós remotos.
A opção mais versátil, embora, talvez excessiva, se você estiver simplesmente tentando manter o código em sincronia, seria um sistema de arquivos distribuídos. Por exemplo, usando GlusterFS , você pode configurar a replicação entre vários nós - e a falha de qualquer nó será tratada de forma transparente. A desvantagem é um aumento nos tempos de gravação, porque uma gravação em qualquer nó deve ser sincronizada em todos os nós. É, no entanto, a opção mais resistente à falha de um único nó (daqueles acima) e permite uma escalabilidade considerável. Também permitiria que você configurasse seus nós para que os arquivos fossem distribuídos e replicados (ou seja, se você tivesse 10 nós, talvez não queira 10 cópias dos dados - talvez 5 cópias dos dados espalhados entre os 10 nós sejam suficientes - o que permite que apenas metade dos nós falhem, e seus dados ainda possam ser lidos.)