是否有人有使用 DRBD（协议 C）同步 2 个 esxi 主机的部分数据存储以进行选定客户的灾难恢复的经验？
我有 2-3 位客人，他们应该能够在尽可能短的时间内从主机的硬件故障中恢复，但仍然需要手动干预并且不会丢失太多数据。
我想构建类似这样的东西：
2 个 esxi 主机上各有 1 个 DRBD VM 同步其本地 SAS 存储（主/辅助、主动/被动）。
此镜像存储应通过 ISCSI 或 NFS 一次仅连接到 1 个 esxi 主机，并用于让这些客户机将其 vmdks 同步到第二个“被动”esxi 主机。如果发生硬件故障，则第二个 esxi 主机应连接 DRBD 存储以启动这些虚拟机（当然是手动完成）。
我在网上找到了一些关于执行此操作的信息，但没有找到有关 vmdks 一致性的任何信息。
虽然这当然并不意味着要替代备份，但是虚拟机管理程序的备份工具通常会确保在拍摄快照或备份之前客户的文件系统和数据库处于静止状态。
但是，如果持续同步，这是不可能的。因此，我怀疑这是否值得做。
如果 vmdk 本身因为硬件故障发生的时间不对而损坏，该怎么办？我知道 DRBD 会丢弃不完整的写入，但这足以获得一致的（从 esxi 的角度来看意味着“正常工作”，除了客户文件系统一致性，当然这种方式无法保证）vmdk 吗？
我希望，如果发生崩溃，第二个 esxi 上启动的客户端可以表现得像虚拟机刚刚不正常关闭一样（在其他情况下，这通常会带来各种可能的缺点），但事实真的如此吗？整个 vmdk 难道不会损坏吗？
非常感谢您的阅读和想法。
最大限度
答案1
我对您描述的场景进行了广泛的测试。我尝试使用 DRBD 拥有具有故障转移功能的存储服务器，然后使用 iSCSI 将该存储连接到运行 Xen 的 Debian 机器。我很快就放弃了，因为我遇到了太多问题。不过，其中一部分可能是我的问题。其中一个是未创建 iSCSI 块设备。
然后我继续尝试制作两台 Debian Xen 机器，并使用 DRBD 复制虚拟机所在的 LVM 块设备。我确实有文件系统屏障错误克服。
然后我的性能就变得很差，我把原因归结于选项al-extents。我使用的 DRBD 版本 8.3 的默认值太低了。我把它调高到了 3833，因为我并不介意稍微长一点的重新同步时间。
我还做了大量有关关闭节点电源的实验。DRBD 在这方面表现得非常出色。VM 确实做出了如您所愿的响应：将其联机到另一个节点的过程很顺利，只是说它正在恢复其日志。重新启动节点也会简单地重新同步设备。当然，真正的节点故障通常很糟糕，磁盘半工作状态、网络流量等很难预测。您很聪明，只需手动提升从属节点即可。
我已经运行该设置大约 2 年了。节点还没有失败 :)，DRBD 也没有失败。
在我的测试中，我发现没有具有故障转移功能的中央存储服务器，而是在 DRBD 主服务器和辅助服务器上运行 Xen，这样方便得多。我想再次尝试 iSCSI 设置，但短期内不会发生。
另外，我不使用图像文件，而是使用 LVM 块设备。事实证明，这对我来说更加可靠。例如，在 LVM 上使用 Snapsnotting 是可能的。
有一件有趣的事情需要注意：DRBD 有一种模式，允许它在主节点上无盘运行。我曾经在主 Xen 节点上发生过一次磁盘故障，但没有引起注意（内核 MD 没有启动驱动器，但我不断出现 ATA 错误）。在我不知情的情况下，虚拟机在无盘模式下运行良好，使用另一台服务器作为存储 :)