当我第一次设置 2 节点 Hyper-V 2012 集群时，故障转移几乎是即时的。我有一个分配了 8GB RAM 的 Sql Server 2012（在 Win2012 上）VM。我可以反弹它所在的节点，它会跳转到另一个节点而不会断开我的 Sql 连接。
然后我在集群中添加了第二个虚拟机（第一个虚拟机的克隆），也是 8GB。现在故障转移需要几秒钟，我的 Sql 连接会重置。它是必须移动的 RAM 量的一个因素吗？受网络影响吗？是仲裁磁盘的速度吗？
就我而言，两个节点都连接到同一个 DAS，并且 VM 文件位于 CSV 上。我希望磁盘不是一个因素，因为不需要移动任何东西。应该都是内存吧？那么随着 RAM 的增加，故障转移性能会降低吗？
回想起来，我想我应该知道的。答案分为两部分，因为在我看来，有计划的故障转移和“真正的”/计划外的故障转移——计划的故障转移不算在内。
计划的故障转移
计划中的故障转移实际上只是集群系统耗尽节点，然后为您重新启动它。因此，当您通过 RDP 或集群应用程序 GUI 中的“停止集群服务”直接重新启动节点时，首先会发生虚拟机实时迁移关闭。因为您实际上只是在实时迁移虚拟机，所以所需时间取决于需要传输的内容和网络连接。如果您有 1Gb 网卡，则需要一段时间（~118MB/秒）。您的 VM 拥有的 RAM 越多，更快的 NIC 将为您提供更好的服务。
真正的故障转移
计划外/“真正的”故障转移是在您拔下机器时。在这种情况下，集群系统会自动在另一个节点上启动 VM。对外界的行为与重新启动 VM 相同。对于虚拟机来说，这就像你“关闭它”然后重新启动它一样。因此，“真正的”故障转移始终与您的虚拟机启动所需的时间有关。
相切
从概念上讲，这对我来说是一个失望，因为我觉得网络上的所有集群讨论都表明集群系统隐藏了一个（“硬”）节点故障——它应该就像服务永远不会下楼。我记得读过的所有网页都在软件中测试了它们的集群故障转移（计划的故障转移），这很可能传播了这一事实。所以他们真正做的只是证明 Live Migration 像宣传的那样工作（从客户的角度来看没有停机时间）。
我的主要错误是误解了故障转移本身。除了在热服务器上发生自动故障转移的热/暖/冷备份服务器的概念之外，还有热/暖/冷故障转移。如此处所述，热故障转移是即时的，热故障转移以秒为单位，冷故障转移以分钟为单位。我天真地认为所有自动故障都是“热的”。我想我期待 RAM 有某种魔力，集群会在另一个节点上更新 VM 的 RAM 副本——就像使用 Sql Server 传送事务日志一样。但这需要机器之间的通信通道至少与 RAM 一样快，以保证它能够正常工作。