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