现在我正在使用 DRBD 在两个不同的 XEN VPS 上复制两个目录（/var/www 和 /var/spool/mail），它们相距 7000 英里！最重要的是，我正在使用透明 IPSec 隧道 VPN 在私有级别连接两个节点，我知道这似乎不公平，现在我将（www 和 mail）文件夹放在 DRBD 目录中，我只是将它们软链接到每台机器，它正在工作和复制，但由于我在网络级别（距离和安全性）上有太多负载，我的磁盘读/写速度很糟糕，我在 6 分钟甚至更长时间里打开一个网页，我的邮件延迟，在一天结束时，我面临（双裂脑）并且两个节点都重新启动，那时 DRBD 将两个节点都作为辅助节点，挂载过程永远不会发生，这导致没有活动的根文档供 apache 启动，而此时冗余会破坏可用性！
我正在尝试释放 DRBD 分区上的负载以加快速度，因此我将两个目录复制回其原始位置，并在 DRBD 分区上为每个目录创建了一个软链接，但这从未奏效，现在我需要好的建议！（顺便说一下，我正在为 DRBD 分区使用 OCFS2）
答案1
那“首先不要复制超过 7000 英里的慢速和高延迟链路”又如何呢？
DRDB 级别的复制有其用武之地，但您基本上滥用了它：它仅针对低延迟高带宽场景而设计。您还可以在灾难恢复场景中“异步”使用它，在这种情况下，由于复制落后并赶上进度，丢失一些数据是可以接受的。
如果您不属于上述两种情况之一，那么就不要再使用 drdb 之类的东西了。在数据中心组织本地数据，并使用复制和备份来合理地提取数据。
例如，复制邮件池就没什么意义。Web 内容（网站等）——也没什么意义，因为您可以使用其他工具来分发这些数据。
如果您采用特殊用途技术，忽略其局限性并将其置于不适合的情形中，那么您将面临此处描述的灾难。
DRDB 是本地机器的高可用性功能。它允许在机器发生故障时复制文件系统。它不适用于处理 WAN 场景，除非您使用异步，即“写出”（即复制到异地位置）。即使这样，您仍然必须拥有处理它的带宽 - 这可能会很费力（例如：1gbit+）。
答案2
正如 TomTom 和 ThatGrameGuy 指出的那样，您的设计假设（即您可以使用 DRBD 实现您想要的功能）是有缺陷的。DRBD 对于同步块设备很有用（名称为：分布式复制块设备）。 你可以理论上在您当前场景中使用它，正如 TomTom 所描述的（异步模式，适用于可以丢失一些数据的情况），但您没有描述这种情况存在的任何情况。
而且你似乎把这件事搞得比它需要的复杂得多：听起来你只需要一个简单的“主/次”环境。
对于网络内容
网站会定期更改。备份网站内容并将其恢复到远程服务器（或将所有内容存储在版本控制系统中，或使用配置管理系统将网站“推送”到多个服务器）非常简单。
对于数据库
如今，网站通常由数据库支持（这通常是唯一“持续”变化的部分），但每个值得使用的数据库引擎都具有某种复制功能（您说您已经在使用它）。
正确配置数据库复制是方式比 DRBD 更适合复制数据库，因为远程数据库引擎保证与主服务器具有相同的 ACID 级别。
对于电子邮件
就像 TomTom 在他的回答中所说的那样，复制您的外发邮件队列是没有意义的。
如果您的主服务器丢失了，而队列中有一封或两封电子邮件，您的用户可以重新发送它们，而且这只是一个极端情况，因为除非收件人的服务器宕机，否则电子邮件会在几秒钟内从您的系统中消失。不值得担心。
人们的邮箱是另一回事：在这里，您将需要备份（或支持复制的邮件系统）。这可能意味着当您故障转移到辅助服务器时（同时恢复旧邮件），人们有一小时或一天无法访问他们的旧电子邮件，但这通常是可以接受的，因为他们正在获取他们的当前的电子邮件。如果恢复时间不可接受，您可以连续将备份恢复到辅助服务器（或使用类似 rsync 的工具每隔几个小时保持邮箱同步）。
我上面描述了几个边缘情况，您应该注意。
第一，如果您的服务器“非常繁忙”，您可能需要正确进行负载平衡（使用类似 HAProxy 的工具在“前端”服务器之间分配 Web 请求，并将邮件和数据库移动到它们自己的服务器上）。这就是您正确扩展的方式。
技术计算机科学解释：DRBD 黑客对 DRBD 的带宽要求接近 O（N^2），其中 N = 节点数，我概述的解决方案大致为 O（N），其中 N = DR 站点数 - 并且 DR 站点数不太可能超过 2）。
二，如果您的 Web 服务器将数据写入本地文件系统，您将需要重新设计该解决方案（将文件存储在数据库中，或存储在 MongoDB 等 NoSQL 数据库中，或存储在中央存储服务器中（通过 NFS 或类似方式，并可能使用 Async DRBD 将其复制到您的异地位置，以实现近乎实时的灾难恢复） - 基本上是某种解决方案，以确保本地文件写入可供所有其他“前端”服务器使用。