sql-server - 虚拟化SQL Server:为什么不呢？

Question

我工作的IT部门正在尝试将其所有数据存储在SAN上的100％虚拟服务器。他们还没有这样做，但是该计划最终要求将现有的物理SQL Server计算机也移至虚拟服务器。

几个月前，我参加了Heroes Happen Here启动 Activity ，在一次SQL Server session 中，演讲者顺便提到了这对生产系统不是一个好主意。

所以我在寻找一些东西:

为什么这是个好主意，具体原因是什么？我需要引用，或者不打扰。我可以通过Google自己提出一个模糊的“I / O绑定(bind)”响应。

仅凭HHH发言人的回忆可能不会说服我们的IT部门改变主意。谁能直接指出我更权威的东西？ “直接”是指比模糊的Books OnLine评论更具体的内容。请缩小一点。

Answer 1

我可以根据个人经验来这么说，因为我在讲话时正在处理这个问题。我目前作为承包商的地方为其SQL Server开发系统提供了这种类型的环境。我正在尝试开发一个相对适中的B.I.系统在这种环境下并确实在性能问题上挣扎。

在幼稚的虚拟机上，TLB丢失和模拟I / O的速度非常慢。如果您的操作系统具有半虚拟化支持(在Windows上仍不是成熟的技术)，则可以使用半虚拟化的I / O(本质上是连接到VM中的API的设备驱动程序)。 Opteron的最新版本支持嵌套页表，这消除了在软件中模拟MMU的需求(这确实很慢)。

因此，运行在大型数据集上并执行大量I / O(例如ETL流程)的应用程序会跳到虚拟化的致命弱点。如果您的数据仓库系统之类的东西可能难以存储在内存或磁盘I / O上，则应考虑其他因素。对于简单的事务性应用程序，可能还可以。

透视一下我正在使用的系统正在具有4x 2gbit F / C链接的SAN的 Blade 服务器(IBM服务器)上运行。这是一个中型SAN。 VM具有4GB的RAM IIRC和现在的两个虚拟CPU。处于最佳状态(SAN处于安静状态)，这仅是XW9300速度的一半，它是1 U320总线上有5个SCSI磁盘(系统，tempdb，日志，数据，数据)和4GB RAM。

您的工作量可能会有所不同，但我建议使用工作站系统(如我所描述的那样)，该系统优先于SAN上的虚拟服务器开发任何繁重的I / O。
除非您的资源使用要求超出了这种工具包的范围(在这种情况下，无论如何它们都远远超出了虚拟服务器的范围)，否则这是一个更好的解决方案。硬件并不那么昂贵-肯定比SAN， Blade 服务器机箱和VMWare许可便宜得多。 SQL Server开发人员版随附V.S.专业及以上。

这还具有一个好处，即您的开发团队从一开始就被迫处理部署-您必须提出一种易于“一键式”部署的架构。这并不像听起来那么难。 Redgate SQL Compare Pro是您的 friend 在这里。您的开发人员还将获得数据库管理的基本知识。

快速浏览HP's website后，我获得了带有四核xeon芯片，4GB RAM，1x146和4x73GB 15k SAS硬盘的XW8600(当前基于至强处理器的型号)的标价约为4,600美元。街价可能会更低。将此与SAN， Blade 服务器机箱和VMware许可的价格以及该设置的备份成本进行比较。对于备份，您可以为网络共享提供备份，人们可以根据需要删除压缩的数据库备份文件。

编辑:This whitepaper on AMD's web-site讨论了VM上的一些基准测试。从后面的基准测试来看，繁重的I / O和MMU工作负载确实破坏了VM的性能。他们的基准(因为这是供应商提供的统计数据，所以要花些盐)表明OLTP基准的速度损失为3.5倍。由供应商提供时，应牢记:

它对朴素的虚拟化进行了基准测试
并将其与
半虚拟化解决方案，不是
裸机性能。

OLTP基准测试将有更多
随机访问I / O工作负载，并将
花更多时间等待磁盘
寻求。顺序磁盘
访问模式(的特征
数据仓库查询)将有一个
更高的罚款和更多的记忆
操作(例如，SSAS是
圣经的记忆 pig )
大量TLB失误也将
产生额外的罚款。这个
意味着在此放慢脚步
处理类型可能是
比OLTP更明显
白皮书中引用了基准罚款。

我们在这里看到的是，TLB丢失和I / O在VM上非常昂贵。 MMU中具有半虚拟化驱动程序和硬件支持的良好体系结构将缓解部分或全部这些问题。但是，我相信Windows Server 2003完全不支持半虚拟化，并且我不确定Windows 2008 Server中提供了什么级别的支持。根据我的经验，与相对适中的裸机硬件相比，VM在进行ETL流程和SSAS多维数据集构建时会从根本上降低服务器速度。