虚拟化SQL Server应该避免的8件事情

  在虚拟化和云计算已经越来越普及的时代，作为主流数据库之一的SQL Server也越来越多地需要跑在虚拟机上。一位具有10年虚拟化项目经验的IT经理分享了自己积累的SQL Server虚拟化最佳实践。

  1、自建主机

  在IT部门工作往往能提供给我们很多的机会回收零部件，适用于各种用途。可能是一个显示器，一个电源，或额外的 RAM，可以被重新部署。因此，我们养成让所购买的硬件获得最长的使用寿命的习惯。将有一个时期，你看着你的服务器机房想着“嘿!我有足够的零件在这里建立一个真正大的、健壮的服务器，可成为一个虚拟机的主机!”

  不要成为那个人。

  不要试图建立一个主机，尤其是主机产品的零件已接近生命的尽头。如果你的设备已经落后于时代，想象18个月之内它会落后更远。如果你喜欢便宜和使用剩余备件，请用在开发主机，并准备花费额外的时间来维护。

  如果你将要虚拟化，你要为你的主机购买新的硬件。新硬件应该比当前已部署为物理设备的服务器更强大。这里还有许可的考虑。购买新的硬件可能需要较少的许可，整体上便宜更加便宜。

  2、没有性能预期

  虚拟化不能不考虑可接受的性能水平。VMware表示，他们的虚拟化技术可以让你实现当前部署在物理服务器上的SQL Server的98%的性能。请注意，这并不意味着你迁移到 VMware就获得更好的性能。很多时候，你升级到较新的硬件会得到更好的性能。但是，如果你不知道当前的性能SLA，那么你将不会有任何概念。

  当你做性能基线，不要把查询的持续时间作为唯一的指标。你还需要测量查询的逻辑I/O和CPU成本。如果你要尝试尽可能多地挤出你的主机的性能，你会首先希望能够迅速确定那些最消耗CPU和内存的查询，并调整它们(参见图1)。

  3、磁盘配置

  这里有两个主要选项：原始设备映射(RDM)和虚拟机磁盘格式(VMDK)。哪一个是你想要使用的，何时使用？真正的区别在于功能，或者架构。

  VMware已经发布一个方案清单，列举了RDM何时是更好的解决方案。在开始部署无法满足一些关键的业务需求的解决方案之前，你需要知道这些差异。

  您还应该了解RAID级别之间的差异，哪些最适合SQL Server。最后，请记住，虚拟化是一个理想的工具的原因之一，是因为共享存储方面允许服务器根据需要在主机之间轻松移动。这也是很大的弱点，因为它允许“吵闹的邻居”消耗资源，可能导致使用相同磁盘的其他服务器“疼痛”。这是布置你的磁盘配置选项时候需要上心的。

  4 、自动精简配置

  自动精简配置是坏主意之一，听起来不错，往往会产生与自己动手做牙医相同的结果。它的初衷足够无辜：有人想节省空间，只在需要时分配存储空间。最终的结果是，没有人保持高效的跟踪虚拟机已自动精简配置什么，最终文件大小疯狂增长，直到填满所有可用的存储，使所有活动停止。

  对于存储磁盘变满问题的共同建议，是把客户机迁移到新的主机，在那里它们会适应。伟大的建议，但我猜想你没有足够的空间来实施，否则，你也不会使用自动精简配置了。

  我帮助DBA理解精简配置，通过将它与SQL Server的自动增长比较。如果你有相当的规模的数据文件(例如500GB)，它仍然在以10%的速度增长，那么下一次增长会消耗50GB磁盘空间不会发出警告。如果你有少于50GB的可用磁盘空间，那么驱动器将被完全填满。这与自动精简配置发生的事情相同。

  大多数优秀的高级数据库管理员采取措施，尽量减少会填满磁盘的自动增长事件，并引起最终用户头痛的机会。如果你发现自己使用自动精简配置以最大限度地提高你的空间利用率，那么你将需要采取额外的步骤来管理你的环境，以确保没有任何突发的增长事件。

  5、内存/CPU的超额分配

  超额分配你的内存和CPU资源的想法很自然。你不希望内存和 CPU引发性能问题。

  当我审查客户的配置，我告诉他们为默认CPU资源上限的1.5:1的比例(就是说，16个逻辑核心意味着你可以以分配24个CPU为基准，并根据根据工作负载需要和负载均衡的允许上下调整)。

  对于内存设置，我遵从VMware的性能最佳实践指南概括指出的“......避免过度分配内存。”换句话说，我对内存超额分配比CPU的超额分配更保守。

  超额分配资源很容易为你添加更多的客户机到主机时候带来惊喜。下一次当你将一个新的客户机添加到主机，在这上面花几分钟的时间，这几分钟可能会节省你以后几个小时的头痛时间。

  6 、信任O/S计数器

  虚拟化意味着你必须在你和磁盘上的数据之间抽象出新的一层(即hypervisor)。我通常只是说“你和你的数据之间有多层美味蛋糕。”麻烦的是，你需要知道是哪一层造成你的性能问题。是主机？还是客户机？因此，你需要依靠以虚拟机性能计数器来获得所发生的事情的全貌。

  数据库管理员通常知道他们的服务器被虚拟化，但抱怨说，他们没有洞察到VMware性能计数器。如果没有这种洞察力，数据库管理员不知道哪里是真正的瓶颈所在。一个常见的例子是关于CPU的压力。当SQL Server显示内部的CPU压力的症状，DBA可能会开始采取措施来纠正问题。然而，内部压力可能是一个客户机问题造成的，或者甚至是主机。

  不知道哪里是真正的瓶颈意味着DBA浪费时间试图解决没有问题的问题。所以说，如果你的虚拟服务器还在依赖于标准的O/S指标，那么你就错了。

  7、一次用完所有资源

  记住我说过要避免一次性过度提交你所有的资源，这是负载均衡和了解你的工作负载的关键。你不能开拓出十几个客户机用来作为运行生产数据库的服务器，并预期它们的性能将保持在VMware所说的98%。

  负载均衡的概念可能比科学更加艺术。一些意外事件引发的多米诺骨牌效应可能扰乱你的预期部署，需要一定的时间才能完全恢复。所以你必须权衡你的工作负载，否则你会发现，超额分配的资源是过度投放。只有均衡是不够的，你必须为增长和使用留下空间，使得如果一个事件发生，你能渡过难关，不会破坏许多其他的系统。

  8、容量规划

  我们有适当的容量规划的想法。从理论上讲，这是一个绝妙的主意。但在现实中，它往往是一个徒劳的努力。

  比如说“在过去六个月中，我们已经看到x%的增长，我们预计未来六个月内是在Y。”现实情况是，明天的业务可能决定需要能够下载1000个不下于1GB的文件。

  换句话说，业务需求会发生变化，而且往往没有预警。正如我们在谈负载均衡时提到的，你也需要为增长留出适当的容量规划。否则，你会在很短的时间内就遇到麻烦。