数据库虚拟化——这样做值吗？

在虚拟机镜像中部署服务器应用程序的做法风靡一时。当需求改变时，虚拟服务器可以快速地从一台机器移到另一台机器上的这种能力让 IT 部门受益无穷。但是，这种做法适用于像 SQL Server 这样的重量级系统吗？对于这个问题，Conor Cunningham 提出了否定的看法。

根据 Conor 的说法，SQL Server 对它的运行环境有一些假设，这包括：

1. 所有的 CPU 能力相同；
2. 所有 CPU 执行指令的频率大致相同；
3. 磁盘缓存的写入动作必须在一个确定的时间段内发生。

第一个问题会出现在支持并行查询的高端数据库版本中。当执行一个查询时，所有的工作会被平均地分配到不同的线程中，但在超线程（hypertheading）或是虚拟化的环境中，这些线程并不是按照一致的速度运行的。 > 在这种情况下，某些线程会比另外一些提前完成，因此较快的线程会被阻塞，直至最慢的线程执行完毕。更糟糕的是，除非是整个查询都完成了，否则这些线程都无法被分配给其他查询任务。现在，你应该了解到为什么说某些 SQL Server 不适合部署到超线程机器上的真正原因了。

Later Conor 接着讨论了内存和 I/O 方面的问题，

SQL Server 有假设条件，至少在被配置为主要服务模式的 SQL Server 中，它会假设自己是机器中唯一一个会使用大量内存的服务程序，因为这是一台“服务器”（SQL Express 的假设不同，不过它并不会放松对内存的需求），而现在，SQL Server 运行在一个内存受限的环境中，尽管你并不希望这样做，但这样做会让许多事情受到影响——缓存池、查询计划的缓存、以及用于查询的内存（例如进 行 hash join 的条件）等等。如果你不当心的话，这些问题都可能会变的愈发严重。

虚拟化中的 I/O 部分我的经验很少，这也是为什么我向其它人请教 SQL Server 产品相关问题的原因之一。他们通常使用会使用存储阵列（storage array），这的确是个有效的方法——它大大提高了 I/O 的带宽，并且把它和机器中的其他操作（如你的操作系统、你正在开发的 SQL Server 上层应用程序等）隔离开来。我打算花更多的时间去研究它，不过我认为这个想法的基础是有效的——因为当你开始让多个虚拟机共享 I/O 带宽时， 像 SQL Server 这样的 IO 带宽消耗大户会让你很快达到极限。所以，按照前面的逻辑，你应该将你的数据库通信隔离在独立的存储路径上，尤其是当你想构建一个扩展性良好的系统时更应该如此。在虚拟机环境中，这样做能让你避免因使用默认配置让所有人共享同一硬盘而造成的严重后果。

以上的说明并不是在说 SQL Server 无法在虚拟镜像中运行，只是为了说明当 SQL Server 的性能对你很重要时，使用虚拟机将会使你得不偿失。

查看英文原文： Database Virtualization - Is it worth it?