Experiências DRBD Proxy / WAN

Eu 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 primária 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 - "nunca" será replicado novamente para o primário.

Alguém já fez / cansou / usou 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 pares). Alguém tentou isso?

Não posso falar pelo DRBD Proxy, mas o DRBD comum não vai gostar tanto.

Com atividades limitadas, você pode saturar facilmente um T1 duplo (2x 1,5 Mbps; para números redondos, 300 KB / s). 300 KB / s podem ser ocupados apenas pelo log do aplicativo, sem falar em fazer algo interessante no seu servidor. Isso exclui a replicação síncrona ( Protocolo C ), muito menos a adição da latência over-the-vpn na equação.

A replicação assíncrona ( Protocolo A ) pode tecnicamente funcionar, mas eu esperaria que o secundário estivesse tão desatualizado que não fosse utilizável no caso de uma falha (a réplica pode demorar horas durante o dia)

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

Espero que o DRBD Proxy ainda sofra problemas semelhantes, causando principalmente atraso na replicação devido à largura de banda limitada.

Eu recomendo que você reavalie sua estratégia de recuperação de desastres para descobrir o que está mitigando; falha de hardware ou site.

No caso de proteção contra falhas no site, você pode obter melhores milhas com transferências de menor largura de banda / densidade no caso de um (ou ambos) sites com restrição de largura de banda. Alguns exemplos dessa técnica são o rsync (transferências por fio são limitadas a alterações nos arquivos entre as execuções - em vez de por alteração a cada alteração - mais algumas sobrecargas de protocolo; podem ser executadas no SSH para criptografar e compactar ainda mais o tráfego) e envio de log do banco de dados (a transferência de logs compactados do banco de dados para reprodução na caixa DR pode usar menos largura de banda do que a transferência de um dump completo do banco de dados).

Se você estiver protegendo contra falhas de hardware, uma réplica local de DRBD conectada a um cruzamento GigE funcionará perfeitamente, permitirá atualizações totalmente síncronas e permitirá a verificação on-line para provar que os dados são consistentes nos dois nós. Você ainda pode combinar esta opção com replicação limitada de arquivos em um site de recuperação de desastres para proteger contra uma falha no site principal.

O DRBD-Proxy funcionará bem, desde que você não esteja saturando os links T1 o tempo todo. Enviamos muitos arquivos de 2 TB através de uma conexão Proxy DRBD (concedida com um 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 que seu T1 não possa lidar, isso deve funcionar bem. Você gostaria de usar o modo assíncrono para replicação.