mx8*_*x82 5 disaster-recovery synchronization drbd hypervisor vmware-esxi
有没有人有使用 DRBD（协议 C）同步 2 台 esxi 主机的部分数据存储以对选定来宾进行灾难恢复的经验？
我有 2-3 个来宾，它们应该能够在尽可能短的时间内从主机的硬件故障中恢复，但仍然需要人工干预并且不会丢失太多数据。
我想构建这样的东西：
2 台 esxi 主机上的每台 1 DRBD VM 同步其本地 SAS 存储（主要/次要、主动/被动）。
此镜像存储应一次仅通过 ISCSI 或 NFS 连接到 1 个 esxi 主机，并用于这些来宾使其 vmdks 同步到第二个“被动”esxi 主机。如果发生硬件故障，第二台 esxi 主机应连接 DRBD 存储以启动这些虚拟机（当然是手动完成的）。
我在网上找到了一些关于这样做的信息，但我没有找到任何信息是 vmdks 的一致性。
虽然这当然不是备份的替代品，但虚拟机管理程序的备份工具通常会确保来宾的文件系统和数据库在拍摄快照或备份之前处于停顿状态。
但是，通过这种连续同步，这是不可能的。这就是为什么我想知道这是否值得做。
如果 vmdks 本身由于硬件故障发生在错误的时间而损坏怎么办。我知道 DRBD 会丢弃不完整的写入，但这是否足以让 vmdk 保持一致（从 esxi 的角度来看，意味着“工作”，除了来宾文件系统一致性，当然不能以这种方式保证）？
我希望，在发生崩溃的情况下，在第二个 esxi 上出现的来宾可以表现得好像 VM 只是不正常地关闭了（在其他情况下这通常可能具有所有可能的缺点），但这真的是案件？vmdks 不会整体损坏吗？
非常感谢您的阅读和您的想法。
最大限度
我对你所描述的场景进行了广泛的测试。我尝试使用 DRBD 建立具有故障转移功能的存储服务器，然后使用 iSCSI 将该存储连接到运行 Xen 的 Debian 计算机。我很快就放弃了，因为我遇到了太多问题。不过，其中一部分可能是我。其中之一是未创建 iSCSI 块设备。
然后我继续尝试制作两台 Debian Xen 机器，并使用 DRBD 复制虚拟机所在的 LVM 块设备。我确实需要克服文件系统障碍错误。
然后我的表现很糟糕，我将其归咎于选项al-extents。我使用的 DRBD 版本 8.3 的默认值太低。我将其提高到 3833，因为我并不真正关心稍微长一点的重新同步时间。
我还做了一大堆关于杀死节点能力的实验。DRBD 对此非常优雅。虚拟机确实做出了如您所愿的响应：将其在另一个节点上联机一切正常，只是说它正在恢复其日志。重新启动节点显然也重新同步了设备。当然，真正的节点故障通常是丑陋的，包括半工作的磁盘、网络流量等，这是很难预测的。你很聪明，只手动升级一个奴隶。
我已经运行该设置大约两年了。节点还没有失败:)，DRBD 也没有。
在我的测试中，我发现没有具有故障转移功能的中央存储服务器，而是在 DRBD 主数据库和辅助数据库上运行 Xen 会更加方便。我想再次尝试 iSCSI 设置，但这不会很快发生。
另外，我不使用图像文件，而是使用 LVM 块设备。事实证明这对我来说更加稳健。其一，LVM 上的快照是可能的。
需要注意的一件有趣的事情是：DRBD 有一种模式允许它在主节点上无盘运行。我的主 Xen 节点上曾经发生过一次未被注意到的磁盘故障（内核 MD 没有启动驱动器，但我经常遇到 ATA 错误）。在我不知情的情况下，虚拟机在无盘模式下运行良好，使用另一台服务器作为存储已有数周了:)
| 归档时间： |
|
| 查看次数： |
1942 次 |
| 最近记录： |