DRBD代理/ WAN体验

我想考虑使用DRBD在主要位置和次要位置之间进行数据复制。最初的计划是在两者之间建立VPN隧道。初级端使用双T1链路的一部分，而次级位置设置在电缆/ DSL线上。

辅助服务器仅用于灾难恢复-它将“永不”复制回主服务器。

有没有人做/累/使用过类似的东西，您对此有何经验？

Linbit还具有（付费）DRBD代理产品，该产品应设计用于跨WAN类型链接（压缩，多个对等点）运行。有人尝试过吗？

我不能说DRBD代理，但是普通的DRBD不会那么喜欢。

即使活动有限，您也可以轻松使双T1饱和（2x 1.5Mbps；对于整数，为300KB / s）。仅应用程序日志记录可能占用300KB / s的速度，更不用说在服务器上做任何有趣的事情了。这排除了同步复制（协议C），更不用说将vpn上的延迟添加到公式中了。

异步复制（协议A）在技术上可能可行，但我希望辅助复制已过时，以至于在发生故障的情况下无法使用（复制可能会在一天之后延迟数小时）

内存同步（协议B）将无济于事，因为它仍然受到带宽问题的限制。

我希望DRBD代理仍然会遇到类似的问题，主要是由于带宽有限而导致复制延迟。

我建议您重新评估您的灾难恢复策略，以解决您要缓解的问题；硬件故障或站点故障。

在防止站点故障的情况下，在一个（或两个）带宽受限的站点的情况下，您可以从较低的带宽/较高的密度传输中获得更好的里程。这种技术的一些示例是rsync（在线传输仅限于两次运行之间文件的更改-而不是每次更改每次更改-加上一些协议开销；可以在SSH上运行以进一步加密和压缩流量）数据库日志传送（将压缩的数据库日志传送到DR盒上进行重放可能比传送完整的数据库转储使用的带宽少）。

如果您要防止硬件故障，则与GigE交叉连接的本地DRBD副本可以正常工作，允许完全同步更新，并允许在线验证以证明两个节点上的数据均一致。您仍然可以将此选项与有限的文件复制到DR站点结合使用，以防止发生主站点故障。

如果您没有一直使T1链接饱和，则DRBD代理将可以正常工作。我们通过DRBD代理连接（已授予100兆位链接）发送了许多2TB文件，没有任何问题。如果您有足够的RAM用于代理并且写入量不是很高，则T1无法应付，这应该可以正常工作。您可能希望使用异步模式进行复制。