Dei a tarefa de criar dois servidores CentOS 7 onde não apenas os bancos de dados serão replicados, mas também os arquivos. Agora, meu problema é que provavelmente haverá centenas de milhares de arquivos, senão um milhão de arquivos com uma ampla variedade de tamanhos, de alguns Kbytes a aproximadamente 1 Gbyte.
Eu li sobre
- inscrição
- lysncd
- anexo git
- QuíronFS
Agora, gostaria de perguntar sobre suas experiências sobre qualquer um deles, se você o usa ou usa atualmente. Como está o desempenho com as alterações de arquivos em relação a cópias e exclusões? Tenho muito medo de usar qualquer rsync porque minha experiência é que ele não é muito rápido com muitos arquivos pequenos, portanto não posso usá-lo para replicação de arquivos em tempo real. Ou eu estou errado? Por favor, prove que estou errado. :)
Ou talvez eu precise de um terceiro e um quarto servidores como servidores de arquivos? Se sim, então permanece a questão: Como replicar os arquivos entre os dois servidores em tempo real?
Saúde!
Responder1
Se seus servidores estiverem na mesma LAN, então um sistema de arquivos em cluster (ou seja: GlusterFS) ou uma solução de armazenamento compartilhado (ou seja: via NFS) deve ser a melhor escolha.
Se seus servidores estiverem em locais diferentes, tendo apenas conectividade WAN, a solução acima não funcionará bem. Neste caso, ese você precisar apenas de replicação unidirecional(ou seja: do servidor ativo para o servidor de backup), lsyncdé uma boa solução. Outra solução é csync2. Por fim, outra possibilidade é usar DRBD + DRBD Proxy(observe que seu componente proxy é um plugin comercial).
Finalmente, se seus servidores tiverem apenas conectividade WAN evocê precisa de replicação bidirecional(ou seja: ambos os servidores estão ativos ao mesmo tempo), basicamente não existe solução mágica. Vou listar algumas possibilidades, mas estou longe de recomendar uma configuração semelhante:
unisoncom seu plugin em tempo realpsync, que escrevi exatamente para resolver um problema semelhante (mas observe que ele tem sua própria cota de idiossincrasias, e forneçosem suportepor isso)syncthingcom seu plugin em tempo real (mas tem limitações significativas, ou seja, não preserva ACLs nem o proprietário/grupo do arquivo)
Responder2
Eu uso o sistema de arquivos ZFS e aproveito sua replicação em nível de bloco usando a estrutura de envio/recebimento zfs.
Eu uso um script útil chamadosinóidepara realizar sincronização regular de sistemas de arquivos em intervalos de 15 segundos a cada hora ou diariamente, dependendo do requisito.
A replicação em nível de bloco será mais limpa e precisa do que o rsync para o conjunto de dados de que você fala.
Responder3
Pela minha experiência, os sistemas de arquivos distribuídos fornecem mecanismos fáceis de replicação para aplicativos. No entanto, eles sofrem de mau desempenho, especialmente quando os diretórios ficam muito grandes com muitos arquivos pequenos. Isso é esperado, pois eles precisam lidar com bloqueio/acesso compartilhado de vários locais/máquinas.
Métodos semelhantes ao Rsync fornecem, em alguns casos, replicação aceitável com algum atraso. Eles não afetam o desempenho do aplicativo durante a leitura/gravação de pastas replicadas.
Acho que uma solução melhor é fornecer armazenamento compartilhado (quando acessível) acessível a partir de um servidor. Outro servidor em espera está pronto para montar a pasta compartilhada quando o primeiro cair. Não há necessidade de replicar quaisquer dados entre servidores.
Responder4
Parabéns pelas ideias. Eu verifiquei e testei todos eles e estou aderindo ao lsyncd.
Razões:
- Instalação extremamente fácil
- Configuração extremamente fácil
- Suporta replicação unidirecional e bidirecional