Eu gostaria de ter dois servidores da Web idênticos: um mestre e um escravo. Arquivo recém-modificado / criado no mestre deve ser replicado de uma vez no escravo (no minuto).
Eu não quero usar o rsync porque ele verifica todos os arquivos para calcular o delta a ser enviado. Eu não quero usar um sistema de arquivos distribuídos como o GLUSTER porque eu tenho medo que ele possa aceitar um monte de pequenas gravações. No entanto, posso aceitar esperar um minuto para descarregar todas as modificações no escravo.
Você tem uma ideia de qual ferramenta devo usar?
Não consigo entender por que você não quer usar o rsync; isto é, afinal de contas, exatamente o que é para ...
Já que você diz que não quer usar um sistema de arquivos clusterizado, que tal usar a pasta www no ServerA (share / export) para montar isso no ServerB como o wwwRoot. Em vez de replicação, o ServerB está usando exatamente os mesmos arquivos.
Eu não tentei, mas isso pode fazer o que você está pedindo.
Se você mantiver os arquivos de seu aplicativo da web em controle de versão, (você faz ter seus arquivos no controle de versão, não?), você poderia escrever um script para extrair esses arquivos do seu VCS e reinicie o serviço do seu servidor web (Apache, NGINX, etc.). Você pode até ter essa execução no cron para que, toda vez que atualizar o repositório (eu recomendo verificar um Tag em vez de um Branch ou apenas Master), ele atualizará automaticamente o site.
drbd permitiria replicação de nível de bloco, no entanto, se você estiver fazendo alguma gravação no escravo, você quer usar OCFS2 ou GFS para suportar bloqueio de cluster. Se você puder montar o NFS do primário do escravo e puder direcionar gravações para a montagem NFS, poderá evitar o uso de um sistema de arquivos de bloqueio de cluster.
O GlusterFS seria mais simples, mas muitas gravações pequenas parecem ficar um pouco atrasadas às vezes. O OpenAFS é semelhante, mas quase todos os sistemas de arquivos distribuídos se encaixam na conta. Um HDFS de dois nós provavelmente também faria o que você precisa.
@gwaldo, Quanto a não usar o rsync, se você tiver centenas de milhares de arquivos, pode levar mais de um minuto apenas para percorrer a árvore e encontrar os arquivos modificados.
O rsync não deve varrer todos os arquivos para calcular seus deltas; por padrão, ele usa um algoritmo de verificação rápida que procura apenas por arquivos com tamanho alterado ou modificado. Se você não tem muitos milhões de arquivos, a execução do rsync deve ser bastante rápida.
Caso contrário, você provavelmente precisará de uma solução personalizada que precise monitorar os aplicativos que podem modificar os dados e enviá-los depois que o programa fechar o arquivo.
Esses requisitos não são completamente incomuns, mas parece um problema.
Para os aplicativos da web de negócios mais significativos, os proxies de balanceamento de carga de alta disponibilidade devem estar em praticamente todos os lugares. Isso significa usar o que for apropriado: dns round-robin, haproxy, ipvs, pfsense, f5's, netscalers, cisco ace, etc.
Servidores da Web que atendem ao conteúdo estático devem ser sem estado. Além de eliminar conexões, deve haver pouco ou nenhum impacto nos usuários se algum servidor da web desaparecer. Portanto, não é necessário ter replicação de disco entre máquinas. Use LB mencionado acima para realizar a mesma coisa com menos esforço. A replicação cria dependências frágeis e um pesadelo de suporte que poderia derrubar tudo. Empurrar com git ou rsync sobre ssh como mencionado anteriormente em um servidor de implementação interno é uma idéia melhor. Se for enviar conteúdo para milhares de nós, a gema de assassinato do Twitter é incrível.
Servidores de aplicativos, qualquer coisa que produza uma página da Web com base em dados que sejam alterados, também devem ser relativamente sem estado. Definitivamente, use algo como o Nginx para fazer implantações limpas, dinâmicas e exponenciais do aplicativo. Os dados devem ser mantidos em um banco de dados (sql / nosql) ou provedor de dados RESTful.
O failover testado exaustivamente deve ser reservado para proteger bancos de dados e outros componentes cruciais. Para desempenho, se o aplicativo for medido para ter um afunilamento de gravação concorrente no banco de dados além do que o hardware (scale-up) pode manipular, considere um nosql confiável que usa um mecanismo de armazenamento estruturado por log, como o bitcask do riak.
Se este não for um aplicativo da Web, mas processar uma grande quantidade de dados, avalie um framework MapReduce como o Hadoop, que usa seu HDFS.
DRDB + Heartbeat O cluster do Apache pode ser ativado ... pessoalmente, eu testei isso ... está funcionando bem
Você provavelmente deve usar incrond para procurar por arquivos alterados em vez de correndo regularmente (e cegamente).
Você usaria a variável $# , que significa o nome do arquivo associado ao evento, para sincronizar cada arquivo alterado individualmente. Pode ser o caminho a percorrer se você quiser evitar a verificação de todos os arquivos no caminho após cada alteração. Eu não tentei embora.
Talvez você também deva dar uma olhada em Unison :
Unison shares a number of features with tools such as configuration management packages (CVS, PRCS, Subversion, BitKeeper, etc.), distributed filesystems (Coda, etc.), uni-directional mirroring utilities (rsync, etc.), and other synchronizers (Intellisync, Reconcile, etc).
Aqui está um howto .
Tags replication