是否有人使用DRBD（协议C）同步部分2个esxi主机的数据存储以便选定的guest虚拟机进行灾难恢复？
我有2-3位客人可以在尽可能短的时间内从主机的硬件故障中恢复，但仍然需要人工干预，而且不会丢失太多的数据。
我想build立这样的事情：
1台同步SAS本地存储（主/从，主动/被动）的esxi主机上的每个DRBD VM。
这个镜像存储应该只通过ISCSI或者NFS连接到一个esxi主机上，并且用于这些guest虚拟机使他们的vmdks同步到第二个被动的esxi主机。 在发生硬件故障的情况下，第二台esxi主机应该连接DRBD存储，以启动这些虚拟机（当然手动完成）。
我已经find了关于在networking上做这个的一些信息，但是我没有find任何信息是vmdks的一致性。
虽然这当然不能代替备份，但是pipe理程序的备份工具通常会确保客户的文件系统和数据库在进行快照或备份之前处于停顿状态。
有了这个连续同步，这是不可能的。 这就是为什么我怀疑这是否值得去做的原因。
如果由于发生硬件故障而导致vmdks本身受损，该怎么办？ 我知道DRBD丢弃了不完整的写入，但这足以保证一致（esxi的观点，除了来宾文件系统的一致性，这当然不能保证这种方式的意义“工作”）vmdk？
我希望在发生崩溃的时候，第二个esxi上的一个客户可能会像虚拟机不正常closures一样（在其他情况下可能会有所有可能的缺陷），但是真的是这样案件？ 整个vmdks不能被破坏吗？
非常感谢您的阅读和您的想法。
马克斯
我用你描述的scenerio做了大量的testing。 我尝试过使用DRBD具有故障转移function的存储服务器，然后使用iSCSI将该存储附加到运行Xen的Debian机器上。 我很快就放弃了，因为我有太多的问题。 其中一部分可能是我的。 其中之一是iSCSI块设备没有创build 。
然后，我开始尝试制作两个Debian Xen机器，并使虚拟机所驻留的LVM块设备与DRBD一起复制。 我确实有文件系统屏障错误要克服。
然后，我的performance很糟糕，我追踪到了这些选项。 我使用的DRBD版本8.3的默认值太低。 我把它提高到了3833，因为我并不在乎稍长的再同步时间。
我也做了一大堆杀人节点的实验。 DRBD非常优雅。 虚拟机的确如你所希望的那样作出了反应：把它联机到另一个节点上就行了，只是说它正在恢复它的日志。 重新启动节点也明显重新激活设备。 当然，真正的节点故障往往是半工半读的磁盘，networkingstream量等难以预测的难题。 你很聪明只是手动推销一个奴隶。
我已经运行了大约2年的设置。 节点还没有失败:)，也没有DRBD。
在我的testing中，我发现没有故障转移的中央存储服务器更方便，但是在DRBD主服务器和辅助服务器上运行Xen。 iSCSI设置是我想再试一次，但不会很快发生。
另外，我不使用图像文件，而是使用LVM块设备。 这已经certificate对我来说更强大。 在LVM上进行快照是可能的。
一个有趣的事情要注意：DRBD有一个模式，允许它在主节点上无盘运行。 我曾经在我的主节点Xen上发现磁盘故障，但未被注意（内核MD没有启动磁盘驱动器，但是我有恒定的ATA错误）。 几个星期没有我知道，虚拟机在无盘模式下运行良好，使用其他服务器作为存储:)