当我第一次安装双节点Hyper-V 2012群集时，故障转移非常迅速。 我有一个Sql Server 2012（在Win2012）VM分配8GB内存。 我可以反弹它所在的节点，它会跳到另一个节点，而不会丢失我的Sql连接。
然后我添加了第二个虚拟机到集群（第一个虚拟机的克隆），也是8GB。 现在故障转移需要几秒钟，我的Sql连接重置。 这是需要移动的RAM数量的一个因素吗？ 它受networking的影响吗？ 这是仲裁磁盘的速度吗？
在我的情况下，两个节点挂钩到相同的DAS和虚拟机文件居住在CSV。 我期望磁盘不是一个因素，因为什么都不需要移动。 它应该都是内存，对不对？ 随着RAM增加，故障转移性能下降？
回想起来，我想我应该知道。 答案分为两部分，因为在我看来，有计划的故障转移和“真正的”/无计划的故障转移 – 并且计划的故障转移不计算在内。
计划的故障切换实际上就是集群系统耗尽节点，然后为您重新启动它。 所以当你通过RDP或者Clustering应用程序GUI中的“Stop Cluster Service”直接重新启动节点时，第一件事就是closures虚拟机实时迁移。 由于实际上只是实时迁移虚拟机，所花费的时间取决于需要传输的内容以及networking连接。 如果您有1Gb网卡，则需要一段时间（〜118MB /秒）。 虚拟机的RAM越多，使用更快的网卡就能提供更好的服务 。
意外的/“真正的”故障切换是当你拔下机器。 在这种情况下，集群系统会在另一个节点上自动启动虚拟机。 对外界的行为与重启虚拟机的行为是一样的。 对于虚拟机来说，就好像你把它关掉了一样，然后重新启动它。 所以一个“真正的”故障转移总是会是你的虚拟机启动需要多长时间。
从概念上讲，这对我来说是一个失望，因为我觉得像“networking”上的所有聚类谈话都意味着集群系统隐藏了一个（“硬”）节点故障 – 它应该像服务从未下去了。 这可能是因为我记得所有的网页都是用软件（计划故障转移）testing了它们的集群故障转移。 所以他们真正做的就是certificateLive Migration能够像广告一样工作（从客户angular度来看不会停机）。
我的主要错误是误解故障转移本身。 除了具有热/冷/冷备份服务器的概念之外，在热服务器上发生自动故障转移的情况下，还存在热/冷/冷故障转移。 如此处所述，热故障转移是即时的，温故障转移以秒为单位进行度量，冷故障转移以分钟进行度量。 我很天真地认为所有的自动故障都是“热”。 我想我正期待着一些神奇的RAM，在那里集群会在另一个节点上更新虚拟机内存的副本—就像使用Sql Server的事务日志传送一样。 但是这将需要机器之间的沟通渠道，至less与RAM一样快，以保证它的工作。