O rsync é um bom candidato para implementação de failover (conjunto de dados muito grande)?

Question

Eu tenho um grande conjunto de dados (+100 GB) que podem ser armazenados em arquivos. A maioria dos arquivos estaria no intervalo de 5k-50k (80%), depois 50k - 500k (15%) e > 500k (5%). O tamanho máximo esperado de um arquivo é de 50 MB. Se necessário, arquivos grandes podem ser divididos em partes menores. Os arquivos podem ser organizados em uma estrutura de diretórios também.

Se alguns dados precisarem ser modificados, meu aplicativo fará uma cópia, modificará e, se for bem-sucedida, sinalizará como a versão mais recente. Então, a versão antiga é removida. É seguro contra acidentes (por assim dizer).

Eu preciso implementar um sistema de failover para manter esses dados disponíveis. Uma solução é usar um sistema de banco de dados Master-Slave, mas eles são frágeis e forçam uma dependência da tecnologia de banco de dados.

Eu não sou sysadmin, mas li sobre a instrução rsync. Parece muito interessante. Eu estou querendo saber se configurar alguns nós de failover e usar o rsync do meu mestre é uma opção responsável. Alguém já tentou isso antes?

i) Se sim, devo dividir meus arquivos grandes? O rsync é inteligente / eficiente na detecção de quais arquivos copiar / excluir? Devo implementar uma estrutura de diretórios específica para tornar esse sistema eficiente?

ii) Se o mestre trava e um escravo assume por uma hora (por exemplo), está tornando o mestre atualizado novamente tão simples quanto rodando o rsync ao contrário (escravo para mestre)?

iii) Pergunta bônus: Existe alguma possibilidade de implementar sistemas multi-master com o rsync? Ou só é possível mestre escravo?

Estou procurando conselhos, dicas, experiência, etc ... Obrigado !!!

    

Answer 1

Is rsync smart/efficient at detecting which files to copy/delete?

O Rsync é extremamente eficiente na detecção e atualização de arquivos. Dependendo de como seus arquivos são alterados , você pode achar que um número menor de arquivos grandes é muito mais fácil de sincronizar, em seguida, muitos arquivos pequenos. Dependendo de quais opções você escolher, em cada execução, vai stat () cada arquivo em ambos os lados, e então transfere as mudanças se os arquivos forem diferentes. Se apenas um pequeno número de seus arquivos está mudando, essa etapa para procurar arquivos alterados pode ser muito cara. Muitos fatores entram em jogo sobre quanto tempo o rsync leva. Se você é sério em tentar isso, você deve fazer muitos testes em dados reais para ver como as coisas funcionam.

If the master crashes and a slave takes over for an hour (for example), is making the master up-to-date again as simple as running rsync the other way round (slave to master)?

Deve ser.

Is there any possibility of implementing multi-master systems with rsync?

O Unison, que usa as bibliotecas rsync, permite uma sincronização bidirecional. Deve permitir atualizações em ambos os lados. Com as opções corretas, ele pode identificar conflitos e salvar backups de todos os arquivos em que foi feita uma alteração nas duas extremidades.

Sem saber mais sobre os detalhes, não posso dizer com confiança que este é o caminho a percorrer. Talvez você precise examinar o DRBD ou alguma outra abordagem de dispositivo / sistema de arquivos em cluster que sincronize as coisas em um nível inferior.

    

Answer 2

Devo dividir meus arquivos grandes?
O rsync é inteligente, mas arquivos muito grandes podem ser muito menos eficientes para serem sincronizados. Aqui está o porquê:

Se apenas uma parte de um arquivo for alterada, o rsync é inteligente o suficiente para enviar apenas essa parte. Mas, para descobrir qual parte enviar, é necessário dividir o arquivo em partes lógicas de X bytes, criar somas de verificação para cada bloco (em ambos os lados), comparar os fragmentos, enviar as diferenças e, em seguida, reconstruir o arquivo no bloco. recebendo final.

Por outro lado, se você tiver vários arquivos pequenos que não mudam, as datas e os tamanhos corresponderão e o rsync pulará a etapa da soma de verificação e presumirá que o arquivo não foi alterado. Se estamos falando de muitos GB de dados, você está pulando MUITO IO e economizando muito tempo. Portanto, mesmo que haja uma sobrecarga extra envolvida na comparação de mais arquivos, ainda é menor do que a quantidade de tempo necessária para realmente ler os arquivos e comparar as somas de verificação.

Portanto, embora você deseje o mínimo de arquivos necessários, também deseja arquivos suficientes para não desperdiçar muito IO trabalhando com dados inalterados. Eu recomendo dividir os dados ao longo dos limites lógicos que seu aplicativo usa.

está tornando o mestre atualizado novamente tão simples quanto rodar o rsync ao contrário
De uma perspectiva de sistema de arquivos, sim. Mas seu aplicativo pode ter outros requisitos que complicam as coisas. E, claro, você estará revertendo para o seu mais recente ponto de verificação em que você rsync'ed ao seu escravo.

Existe alguma possibilidade de implementar sistemas multi-master com o rsync?
Tecnicamente sim, mas por esse caminho está a loucura. Assumindo que tudo funciona bem, então tudo ficará bem. Mas quando há soluços, você pode começar a ter problemas com mudanças ( e especificamente apaga ) sendo sincronizado na direção errada, sobrescrevendo seus arquivos bons com os ruins, ou apagando os arquivos inseridos, ou os fantasmas de arquivos excluídos reaparecendo. A maioria das pessoas recomenda contra isso, mas você pode tentar se quiser.

conselhos, dicas, experiência
Se você está procurando por uma configuração master / master com sincronização on-the-fly, recomendo o DRBD. É significativamente mais complicado de configurar e manter, mas muito mais capaz. Ele faz a sincronização em nível de bloco do próprio disco, em vez dos arquivos nele. Para fazer isso "on-line", você precisa de um sistema de arquivos que tolere esse tipo de sincronização, como o GFS.

O Rsync é mais como um sistema de instantâneos do que um sistema de sincronização contínua.