在虚拟机内部运行数据库有哪些弊端?我该如何克服它们?[关闭]


66

在虚拟机中运行任何内容都会对性能造成一定程度的影响,但是它实际上对数据库系统的性能有多大影响?

我发现此学术参考论文带有一些有趣的基准,但这仅是使用Xen和PostgreSQL的有限测试。结论是使用VM不会“付出高昂的性能代价”(尽管您可能认为实际数据并非如此)。

在虚拟机中运行数据库有哪些技术,管理和其他缺点?

请发布可以得到客观事实支持的答案,我对投机或任何其他半宗教论据不感兴趣(极客热情在许多方面都很好,但这在这里无济于事)。

话虽如此,

  • 在虚拟机中运行数据库时出现什么问题?(请发表参考)
  • 这些问题重要吗?
    • 它们仅在某些情况下有意义吗?
  • 有哪些解决方法?

+1我主要想听听有关SQL Server和Windows 2008 R2方案的反馈
goodguys_activate 2011年

4
@Shane Madden-您能解释一下关闭吗?我希望动机是由一个非特定的答案(然后在评论中偏离)而不是问题本身驱动的。关于该问题,在封闭前存在的大约一天之内,有44票和12个最爱对我意味着这是一个很好的问题,提供了有用的答案/信息(尤其是与ServerFault问题流量的典型情况相比)。这就是各个SE网站所针对的。您是否宁愿选择一个更具体的问题措词,而不是宽松的“问题有多严重?”。
拉斯(Russ)

1
@ ErikA,Shane,Womble,mikeyb,Ben-我进行了社区编辑,可能使这个问题更具建设性。请考虑重新打开该问题,或在新问题/干净问题上发布类似问题。
goodguys_activate 2011年

Answers:


41

尽管许多数据库供应商执行此操作的速度很慢,但现在几乎所有供应商都正式支持其在虚拟化环境中运行的软件。

我们在ESXi之上的linux中运行许多Oracle 11g实例,当然有可能获得非常好的性能。与所有硬件扩展一样,您只需要确保虚拟化主机具有足够的资源(RAM,CPU),并且磁盘层就可以完成提供所需的任何IO性能的任务。


7
+1如前所述,至关重要的是资源必须由任务来决定。磁盘一直是我们的最大瓶颈,需要仔细计划。
戴夫M

2
+1您需要提前完成数据库使用情况的作业。如果您的物理盒子的利用率超过了40%,那么您进行虚拟化的优势就会消失。话虽这么说,但我们在虚拟机上运行着无数小规模的特定于应用程序的独立sql没问题。但是由于缺乏优势,我们的大型重型机器具有专用硬件。
Nate

5
毫无疑问,磁盘IO是最大的罪魁祸首,而虚拟化环境往往容易出错。
lynxman 2011年

1
@lynxman-同意。我们在15k SAS的Tier 1 SAN磁盘上运行所有Oracle实例。据我所知,我们非常接近原生性能。
EEAA 2011年

10
“一盎司的测试值得一磅的猜测。”
克里斯·贝伦斯

21

正如ErikA所说,这变得越来越普遍。我现在在SQL Server阵营中,个人没有在VM上运行任何生产系统,但是我会毫不犹豫地(在对该主题进行了一些研究之后)。不过,在走那条路之前,肯定要考虑一些事情(至少对于SQL Server)。磁盘IO(如其他人所提到的)和内存分配只是两个示例。不同的管理程序之间的情况也将有所不同。

Brent Ozar是虚拟化SQL Server(尤其是VMWare)方面公认的专家。我强烈建议您阅读他的材料。

http://www.brentozar.com/community/virtualization-best-practices/


11

可以然后有应该。一辆轻型巡洋舰可以时速150英里/小时,但是您应该在公共高速公路上吗?您可以不必要地伤害自己。

数据库是客户机操作系统。通过设计,当他们启动时,他们会抢占资源块并出于性能原因直接对其进行管理。在虚拟化托管环境中,一旦将数据库服务器的核心操作系统作为来宾,就需要在磁盘和RAM的块分配元素与数据库服务器之间放置一个带有虚拟机管理程序的仲裁层。它会变慢。您的查询效率越低,速度越慢。今天,在专用硬件上可能掩盖了这些低效率的问题,但是,一旦您将仲裁引入相关资源,您就会很快发现真正的问题。

许多要求虚拟化的bean计数器没有意识到,作为访客操作系统的数据库服务器提供了自己的整合层。没有理由不能将合并的多个逻辑数据库实例移动到一台物理服务器上,甚至不能移动IP地址,设置其他主机名等,以免发生这种自然的服务合并。而且,使用此模型,您不仅可以保留管理层为减少物理主机数量而推动的成本节省,而且可以保留对物理资源的块访问,而不会影响任意虚拟机管理程序,这有时可以做出有益的决定,而不能做出任何决定。其他。

其他来宾操作系统(例如Java)也是如此。虚拟化解决方案通常在繁忙的环境中,管理程序必须对谁在资源上“获得令牌”做出很多决定。只要您可以消除该层,您的状况就会更好。

首先使用自然来宾操作系统层合并多个实例。奇怪的是,您将能够轻松实现平台整合和性能目标。


4
“来宾操作系统”的有趣定义。尽管您的观点是关于纯净,纯净的性能,但您的数据库多久真正遇到CPU瓶颈呢?I / O的可能性更大,对于性能更高的应用程序,您已经在SAN上共享I / O时间。我希望当一个应用程序的安全问题危及所有统一数据库的密码哈希时,或者当JVM中运行的一个进程消耗可用字节空间的每个字节时,您会重新考虑您的虚拟化原理。
Shane Madden

5
明确地说,我完全同意,经过微调,非常繁忙的高性能数据库服务器应具有自己的物理硬件。但这不是常态,虚拟化的其他好处往往会超过性能损失,这在大多数工作负载中是无法区分的。
Shane Madden

3
我不同意您总是先进入现有合并层的观点。有时候这很有意义。但是,例如,请考虑在重新平衡资源之间的成本权衡,这些资源是在单个OS上合并多个数据库与在虚拟机管理程序之上合并多个数据库/ OS组合之间的。第一个是更有效的。第二个更容易重新平衡。与将数据库迁移到新的操作系统相比,将OS /数据库迁移到新的主机所造成的破坏要小得多。
杰克·奥辛斯

我的评论来自对作为性能工程师在过去十年中向虚拟化解决方案成功迁移和失败迁移的直接现场观察。那里有大量不良的数据库应用程序,它们的滥用硬件掩盖了性能问题。添加虚拟化后,这些问题就暴露出来了。如果您的应用程序需要精确的时钟来进行计时或审核,那么由于时钟悬浮在软件虚拟化中,您将一发不可收拾。
James Pulley

1
哇,詹姆斯,哇。我没有时间也没有耐心去浪费您在答案和后续评论中提出的所有观点,但我只是觉得我需要在这里为可能会回答此问题的任何人发表评论。詹姆斯的观点很好,是他自己的观点,并没有反映真正的可能性。如果您订阅过多,那么您的性能当然会很差。因此,不要超额认购。拥有非常高性能的虚拟化环境是完全可能的。对此提出全面建议是愚蠢的,因为它“表现不佳”。
EEAA 2011年

6

这里有两件事要实现:

  • 对于虚拟化数据库,每单位硬件的数据库性能单位要低一些。这意味着您需要购买更多的硬件才能获得相同的性能水平。
  • 这并不意味着无法获得相同的水平或所需的性能水平。您从改进的管理和其他收益(例如更轻松的HA)中获得的收益通常可以抵消略微增加的硬件成本。

就是说,在我工作的地方,我们的Sql Server安装是我不打算很快进行虚拟化的仅有的两台服务器之一(另一台是主DC)。


4

只要您可以为VM提供足够的资源来运行您的应用程序,运行SQL Server的VM就可以了。如果在物理环境中需要24个内核和256 Gig的RAM,则在虚拟环境中需要提供24个vCPU和256 Gig的RAM。

我刚刚在上个月的SQL Server杂志上写了一篇文章,内容涉及在VMware vSphere上运行SQL Server。


2

我在dom0高度可用的虚拟环境(Xen)中运行两个数据库,一个是PostgreSQL,另一个是MySQL。domU文件系统全部位于iSCSI SAN LUN上,并由LVM2逻辑卷组成。MySQL数据库仅用于Cacti,因此根本看不到太多使用情况,它也位于iSCSI LUN上。

PostgreSQL数据库是用于我们的暂存环境的数据库,因此比MySQL数据库具有更高的利用率。因此,数据库位于本地RAID10集上,并且DRBD复制到了第二个群集节点。但是,就实际负载而言,此登台数据库根本看不到很高的负载。在我看来,这使其成为虚拟化的好/好候选人。

对我们组织的好处是降低了功耗,节省了机架空间并减少了硬件管理开销。

另一方面,我们的主要生产数据库无法想象要虚拟化。


2

我在许多服务器上使用MSSQL和MySQL服务器。几年前,我很犹豫开始在VM上设置SQL Server,因为我听说过在VM上运行SQL Server的性能问题。但是,在设置了第一批SQL服务器之后,我没有看到性能上的变化,这让我感到惊讶。我使用的越来越多的服务器都在VM上,并且我工作的几乎所有大型企业客户端都采用了虚拟化的SQL服务器。

是的,VM确实增加了一些开销成本,并且如果您要在一个盒子上托管多个VM,则将需要一台功能强大的服务器。要寻找的常见资源问题是添加其他VM并减少可用资源。计划增长是一种常见的做法,但是如果您购买服务器来托管2或3个VM,而现在运行10个VM,您的性能可能会受到打击。

如果我说我从未见过在VM上运行SQL Server的性能问题,那我会撒谎。但是,我了解到,如果您看到性能不佳,则环境可能存在问题。

By using our site, you acknowledge that you have read and understand our Cookie Policy and Privacy Policy.
Licensed under cc by-sa 3.0 with attribution required.