我想考虑使用DRBD在主要和次要位置之间进行数据复制。 最初的计划是在两者之间build立VPN隧道; 主要使用一个双T1链路的一个片段和一个电缆/ DSL线路上的次要位置设置。
辅助将只存在DR – 它将“永不”复制回主节点。
有没有人完成/累/使用这样的事情，你有什么经验。
Linbit还有一个（付费）DRBD代理产品，它应该被devise用于跨WANtypes的链路（压缩，多个对等体）进行操作。 任何人都试过这个？
我不能说DRBD代理，但经常DRBD不会喜欢这么多。
即使有限的活动，你也可以很容易地饱和一个双重T1（2x 1.5Mbps;整数，300KB / s）。 300KB / s可以被单独的应用程序日志占用，更不用说在你的服务器上做任何有趣的事情。 这就排除了同步复制（ 协议C ），更不用说在等式中增加over-the-vpn延迟。
asynchronous复制（ 协议A ）可能在技术上是可行的，但是我期望次要过期已经过时，以至于在失败的情况下不能使用（副本可能在白天的时间之后）
内存同步（ 协议B ）将不起作用，因为它仍然受到带宽问题的限制。
我预计DRBD代理仍然会遇到类似的问题，主要是由于有限的带宽导致复制延迟。
我build议你重新评估你的灾难恢复策略，找出你正在减轻的负担。 硬件故障或现场故障。
在防止站点故障的情况下，在一个（或两个）带宽受限站点的情况下，您可以在较低带宽/较高密度传输中获得更好的里程数。 这种技术的一些例子是rsync（线上传输仅限于运行间文件的更改 – 而不是每个更改的更改 – 加上一些协议开销;可以通过SSH运行以进一步encryption和压缩stream量）和数据库日志传送（传送压缩数据库日志以在DR盒上重播可能使用比传送完整数据库转储更less的带宽）。
如果您正在防范硬件故障，与GigE交叉连接的本地DRBD副本将工作得很好，允许完全同步更新，并允许在线validation以certificate两个节点上的数据是一致的。 您仍然可以将此选项与有限文件复制组合到DR站点，以防止主站点故障。
DRBD代理将工作正常，只要你不是一直饱和T1链接。 我们通过DRBD-Proxy连接发送大量的2TB文件（授予100兆比特链接），没有问题。 如果你有足够的内存用于代理和写入数量不是那么高你的T1不能应付这应该工作正常。 尽pipe如此，您仍然希望使用asynchronous模式进行复制。
DRBD不是为了跨距离复制而devise的。 DRBD代理是。 它将尽可能快地发送写入的连线将允许。 DRBD代理缓冲区写入内存，不妨碍本地写入性能。 DRBD代理的最快用户运行100GBe，最慢的是：ISDN。
如果您在北美或南美，并想在您的情况下进行testing，LINBIT将为您提供免费试用。 他们有一个技术指南，将引导您通过设置： http : //www.linbit.com/en/downloads/tech-guides#disaster-recovery-with-drbd-proxy
如果它不适合你，这不是什么大的损失，因为它不需要修改你现有的drbd资源