服务器虚拟化已经出现好多年了，技术已趋于成熟。几年前，DBA还很抵触把SQL Server迁移到虚拟机，但是现在已经是再平常不过的了。然而，在决定虚拟化之前有一些重要的事情需要考虑。
SQL Server虚拟化***的解决方案是VMware和微软公司的Hyper-V。首先你应该决定采用哪一种方案。VMware仍然是虚拟化领域的王者，有更成熟的产品和更多的功能。而Hyper-V追赶的速度也很快，它比VMware成本要低一些。这两种产品都提供了免费试用版，如果你正好刚开始使用SQL Server虚拟化，我推荐你两种产品都试试。
当确定了哪些功能适合自己的企业，并研究清楚它们如何运作之后，你就可以比较成本和性能，然后做决定。SQL Server开发团队与Windows和Hyper-V团队都出自微软，这是他们***的优势。如果你只是寻求针对SQL Server的虚拟化方案，那么Hyper-V在大部分情况下都是不错的选择。但是如果你的公司还要虚拟化其它服务器，比如Web服务器或者域控制器，而且其他IT人员更熟悉VMware的话，可能坚持用统一方案是你***的选择。
接下来要考虑的是什么服务器***做迁移。***对象是非生产用的SQL Server。许多公司对于这些环境有不同的称谓，但是通常他们会叫做“开发环境”，“QA环境”，“阶段环境”，“测试环境”，“基准测试环境”以及“压力测试环境”。更常见的是，超高性能并不是***的优先级，这就使得对它们做虚拟化更容易了些。此外，在这些环境中的服务器可能比较老旧，经常是淘汰下来的生产环境服务器，有很多使用寿命问题和配置不一致的问题。另外，它们缺乏足够空间来还原生产数据库。另一个很糟糕但又常见的现象是，DBA们通常需要过于关注生产环境，而忽略非生产环境。这就可能导致在开发周期内由于硬件老化故障或其它问题丢失数据库，耗费更多开发时间。如果你是在给这些环境做虚拟化，你会在新硬件上运行，而且你可以使他们配置一致，使DBA们工作更容易。
那么生产服务器怎么样呢?答案很简单：视情况而定。根据我的个人经验和与其它SQL Server DBA们的讨论，目前的共识是转向虚拟化对于较小的或者中等负载的服务器不成问题。这一技术已经足够先进，虚拟机可以与SQL Server共享内存和磁盘IO。你可以考虑给重负荷的服务器使用VMware或者Hyper-V，但是在这种情况下，我会考虑先做一些基准测试或者压力测试，确保运行于虚拟层的负载不会使性能下降到不可接受的程度。你还可以使用虚拟化作为运行数据库应用的初始设置，但是这种方式是否可以成功并不十分确定。这些年来，我经历过几种情况，我们做了最坏的打算，构建了超级强大的服务器并运行应用程序，事情并没有像我们想象的那样发生。
还有一个问题需要提醒，那就是BI服务器。这些服务器通常托管非常巨大的数据库，这些数据库需要非常快速的处理能力。当OLAP多维数据集构建起来的时候，SQL Server可能需要扫描TB级的数据量。在这种情况下，需要那种“猛踩油门”类型的性能，所以虚拟化的总开销可能难以被接受。例如，在我的公司里，我们没有看到在虚拟化数据仓库上的良好性能表现，需要转换到原来的物理服务器上去。
高可用性在当今时代非常重要，这个领域虚拟化可以提供很大帮助。例如，VMware有一种称为“vMotion”的技术，支持虚拟机在物理服务器之间移动。这就使得你可以保持一套虚拟机处于运行状态，同时你只需要把虚拟机转换到另一台物理服务器就可以执行硬件升级。或者，如果数据库应用比较繁忙的话，当前物理服务器不再够用，你可以在秒级时间内把虚拟机迁移到另一台物理服务器上去。最终，如果底层物理硬件出故障了，vMotion将自动把对虚拟机的控制转移到另一台物理服务器上去。所以，如果你用vMotion在虚拟机上设置了SQL Server，这会极大地提升可用性;如果底层物理硬件出故障了，vMotion将迅速把虚拟机转移到另一台物理节点上， SQL Server仍然处于运行状态。
随着更多的新特性增加到了虚拟化软件中，在SQL Server环境下考虑虚拟化实现的可能性也大大增加，而转向虚拟化的总开销也变得更低了。
