编者按：本系列文章共有两篇，针对SQL Server虚拟化的应用场景进行了深度探讨。本文是第二篇，第一篇请参考：什么情况下我们应该放弃SQL Server虚拟化。

一些数据库必须是24小时运行的，这通常意味着要充分利用SQL Server高可用性的特性。最常见的部署方案之一就是故障转移集群，这种做法可以被虚拟化为独立运行的SQL Server实例。

是否要虚拟化你的数据库集群，可能是关于SQL Server的所有虚拟化讨论中最有争议的一个问题。许多DBA认为虚拟化集群是自寻死路，但同时也有其它很多人都证实虚拟化集群很有帮助，前提是如果性能问题得到充分解决的话。但是，即使在最好的情况下设置和管理集群也是个复杂的过程。虚拟化集群只是通过在资源管理层多增加一层而增加了复杂性。此外，在虚拟化环境中查找故障节点的问题也可能要花更长时间，甚至给虚拟机软件打补丁都可能带来重大影响。一些DBA建议如果你不能忍受30秒以上的停机时间，你就不应该采用虚拟化。

即便你可以满足这样的要求，虚拟化集群还有另外一项挑战。你要确保你的虚拟化集群节点没有设置成单点故障。每个VM都包含一个节点，虚拟机都应该托管在独立的服务器上，而不是共享存储。否则，在这个问题上，你就违背了集群（或者镜像，或者日志传送）的目的。如果你不能消除单点故障，你不应该做虚拟化集群。

SQL Server支持

对于一些DBA来说，虚拟化SQL Server的问题不在于它是否可以实施，而在于它是否能得到支持。许多DBA普遍都关注其他IT员工与他们之间的沟通障碍，尤其是与那些对虚拟化工作负责的人群做沟通时。就本质而言，虚拟化给你的实施增加了额外的复杂度。虚拟机资源必须做好规划、配置和管理。部署之前必须测试性能。专门针对SQL Server的需求，比如在刀片机箱交换期间，关闭CPU省电功能或者监视CPU使用率。事实上，在虚拟环境一般的监控变得更加复杂了，因为没有许可。

对于如何支持虚拟化SQL Server产品，微软公司设置了大量限制。例如，虚拟化环境必须满足Windows 2008或者Windows 2012故障转移集群的需求，否则微软公司将不支持该SQL Server部署。此外，如果应用的数据库被托管于虚拟环境，一些软件供应商也不会支持他们的应用。这些问题都必须在启动虚拟化之路之前加以考虑和检查。

这一切都指向一个问题，就是在参与者之间有效沟通的必要性，同时还需要协调管理策略和精心的配置，这样才能避免资源争用和服务器蔓延。在大多数情况下，实施虚拟机部署的人员都不是DBA，他们通常并不完全理解SQL Server部署的复杂性以及其性能调优的需求。反而，他们把SQL Server当作其它服务器一样，但SQL Server与其它服务器并不一样。诚然，通讯故障并不局限于虚拟化中才有，但是如果对于你的虚拟化系统是否可以得到完全支持仍然有诸多疑问的话，那就先不要做虚拟化。如果你除了虚拟化没有别的选择，那么要确保让涉众都知道其中的风险和挑战。

大而不倒

许多虚拟化数据库的挑战就是，我们很难预测你需要哪些资源，以及你什么时候需要。大型数据库资源可能很密集，但是在特定的情况下，较小的数据库也有同样的问题。尽管如此，虚拟化可能在较小规模的数据库场景中会表现的更完美，当然大型数据库场景也是有可能的。但是，对于大规模高功率的关键系统，你可能需要坚持使用物理服务器了。对于虚拟化的采纳，什么情况算是“太大”呢？这很难说。但是如果你不能保证虚拟机能提供你需要的性能和可用性，那就不要做虚拟化。如果你的授权成本大于你通过虚拟化节约的成本，那你可能也该放弃了。对支持方面也一样，没有支持的虚拟机不会自己运行的很稳定。

虚拟化是一项伟大的技术，有很成熟的优势，即便对SQL Server也是如此。只是如果你选择了这条路线，你要确保知道你在做什么。你可能决定只在你的开发和测试环境中做虚拟化，也可能把所有一切都做虚拟化。不管你做什么，要确保你的选择是经过多番考虑并基于现实的。在着手进行之前要仔细考虑，否则悔之晚矣。