Experiências DRBD Proxy / WAN

9

Gostaria de considerar o uso de DRBD para replicação de dados entre um local primário e secundário. O plano inicial é estabelecer um túnel VPN entre os dois; a extremidade principal usando uma fatia de um link T1 duplo e a configuração de localização secundária em uma linha de cabo / dsl.

O secundário existirá apenas para DR - ele "nunca" será replicado de volta ao primário.

Alguém já fez / cansado / usando algo assim e quais são suas experiências com ele?

O Linbit também possui um produto Proxy DRBD (Pago) que deve ser projetado para operar em links do tipo WAN (compactação, vários peers). Alguém tentou isso?

    
por Jeff Hengesbach 08.06.2009 / 18:51

2 respostas

6

Eu não posso falar pelo Proxy DRBD, mas o DRBD normal não vai gostar muito disso.

Mesmo com atividade limitada, você pode facilmente saturar um T1 duplo (2x1,5 Mbps; para números redondos, 300 KB / s). 300 KB / s podem ser usados apenas pelo log de aplicativos, sem falar de qualquer coisa interessante em seu servidor. Isso exclui a replicação síncrona ( Protocolo C ), sem falar da adição do latência vpn na equação.

A replicação assíncrona ( Protocolo A ) pode tecnicamente funcionar, mas eu esperaria que o secundário para estar tão desatualizado que não pode ser usado no caso de uma falha (a réplica pode ficar horas atrasada durante o dia)

A memória síncrona ( Protocolo B ) não ajudará, pois ainda é limitada por o problema de largura de banda.

Espero que o DRBD Proxy continue a sofrer com problemas semelhantes, causando principalmente atrasos na replicação devido à largura de banda limitada.

Eu recomendo que você reavalie sua estratégia de DR para descobrir o que você está mitigando; falha de hardware ou falha do site.

No caso de proteção contra falha do site, você pode obter melhor quilometragem de transferências de menor largura de banda / maior densidade no caso de um (ou ambos) site restrito de largura de banda. Alguns exemplos dessa técnica são o rsync (transferências over-the-wire são limitadas a alterações nos arquivos entre execuções - em vez de por alteração para cada alteração - mais alguma sobrecarga de protocolo; podem ser executadas via SSH para criptografar e compactar ainda mais o tráfego) envio de log de banco de dados (a transferência de logs de banco de dados compactados para reprodução na caixa de DR pode usar menos largura de banda do que a transferência de um despejo completo de banco de dados).

Se você estiver protegendo contra falhas de hardware, uma réplica DRBD local conectada com um crossover GigE funcionará muito bem, permitirá atualizações totalmente síncronas e permitirá a verificação online para provar que os dados são consistentes em ambos os nós. Você ainda pode combinar essa opção com a replicação de arquivos limitada a um site de DR para proteger contra uma falha do site principal.

    
por 11.06.2009 / 13:57
1

O DRBD-Proxy funcionará bem desde que você não esteja saturando os links T1 o tempo todo. Enviamos muitos arquivos de 2 TB em uma conexão DRBD-Proxy (com link de 100 megabits) sem problemas. Desde que você tenha RAM suficiente para o proxy e a quantidade de gravações não seja tão alta, seu T1 não pode lidar com isso, deve funcionar bem. Você desejaria usar o modo assíncrono para replicação.

    
por 14.12.2014 / 05:22

Tags