在我正在考虑的部署中，我们有一个需要高度可用的生产型sQL服务器。 它将在Server 2008R2集群上进行设置。 Hyper-V将会被设置。 我担心在虚拟机中运行SQL不会提供足够的高可用性解决scheme与根分区上的SQL集群。 在虚拟机中运行SQL性能不是一个问题，我只是担心在硬故障转移的情况下，虚拟机将重新启动，导致比正常SQL群集的故障转移期间更长的停机时间。
我感兴趣的有几个方面。虚拟机的停机时间与SQL集群的停机时间是否会有所不同？ SQL群集中的平均故障转移的时间有多长？ 是否有一些SQL集群的隐藏优势，例如事务发送到的共享队列，所以如果一个节点closures了，事务将在数据库恢复联机后应用于数据库？ 或者它没有改变？
现在，Hyper-V看起来相当不错，因为计划的故障转移可以在不中断任何客户端访问的情况下运行。
SQL Server故障转移涉及运行拥有数据库的主服务器和准备好拥有数据库的备份服务器。 在故障转移的时刻，备份服务器取得存储的所有权，重放日志，然后使数据库联机。 随后是一段时间，数据库的热部分根据需要被带入内存。 故障转移时间的最大限制是重播日志，因为在数据库可以开始响应查询之前需要执行日志。
如果将虚拟机而不是SQL服务器集群，则可以添加虚拟机重启时间以及任何文件系统检查。 这些往往不占主要的恢复时间。