DRBD vs. GlusterFS para replicação

Question

Eu preciso criar uma solução para hospedar repositórios git internos. Ele precisa suportar centenas de milhares (ou mais) repositórios.

Eu planejo usar vários servidores "burros" com um armazenamento compartilhado, então, basicamente, quando um cliente está tentando acessar um repositório - ele será redirecionado pelo balanceador de carga para qualquer um dos servidores disponíveis. Qualquer alteração no repositório - será replicada em todos os nós.

Meu primeiro pensamento foi usar o GlusterFS para isso, mas eu li que ele não funciona bem com arquivos pequenos. Eu também estou pensando em replicar tudo sozinho usando o DRBD, mas isso requer mais configuração e parece mais complicado quando comparado ao GlusterFS.

Qual dos dois oferece melhor desempenho? Basicamente, o problema que estou tentando resolver é que, quando qualquer um dos servidores fica inativo, quero que outros ainda possam servir os dados.

    

Answer 1

Este é um caso clássico de uso de scale-out, e o IMO GlusterFS deve se adequar ao projeto. Você pode tentar - basta trazer algumas VMs para cima, configurar alguns blocos para serem usados no armazenamento do repositório e executar um teste de estresse.

O DRBD não é uma opção aqui de qualquer maneira - não é escalável. Se qualquer coisa, eu olharia para outros projetos de armazenamento de objetos (Swift, por exemplo), se o Gluster não funciona bem o suficiente, mas nenhum deles é extremamente orientado para o desempenho

    

Answer 2

Eu tive uma configuração semelhante para os servidores de email cyrus, nos quais o gluster provou não ser capaz de lidar com a carga durante os testes de estresse. nós originalmente escolhemos gluster porque era simples mas tinha que voltar para drbd. no entanto, como dyasny destacado, drbd activs / active cfg não é aconselhável (para não mencionar a dor). Se você precisar de todos os servidores para montar o armazenamento compartilhado ao mesmo tempo, o drbd não é uma opção. Outra coisa que você pode querer olhar é clvmd com o gerenciador de bloqueio. O lvm2 agora tem suporte para o tipo raid lv e usa o código man para esse propósito. isso misturado com o sistema de arquivos apropriado (alguns com reconhecimento de cluster, se necessário) pode ser uma opção. no entanto, eu nunca testei sozinho na produção, apenas como PoC.

    

Answer 3

O problema que você terá com o Gluster é principalmente a latência entre os nós. Aconselho-o a experimentá-lo e veja se ele lida com a sua carga de trabalho. Se seus servidores forem poderosos o suficiente e tiverem uma interconexão rápida, você deverá obter um desempenho razoavelmente bom. Além disso, você pode querer experimentar o servidor NFS integrado, que, falando da minha experiência, lida com pequenos arquivos um pouco mais rápido.

Mas se você precisar da sua solução o mais rápido possível, o GlusterFS provavelmente não é para você. Outras opções seriam produtos comerciais como o Git Clustering (mas não testamos isso) ou você poderia criar sua própria solução com ferramentas gratuitas como gitmirror .

    

Answer 4

Se você está pensando em usar o Gluster (que, na minha experiência, pode ser usado com muitos arquivos pequenos, mas com o YMMV), talvez você queira dar uma olhada no Ceph, bem como no link

    

Answer 5

Eu também recomendo que o Glustet ad o mais fácil e mais rápido para configurar, configurar. Também se destaca muito bem. O problema é a velocidade, e meu 2c ia que você precisa escolher entre fácil configuração e fácil scaleout, e entre algumas dificuldades técnicas (alguns drbd / ocfs2 / Glances block storage) com o ganho de velocidade. Mas quanto velocidade você ganha? Yoi precisa fazer algum teste de estresse e escolha ..