我已经在大量的虚拟化服务(Azure)和产品(vmware,kvm,hyperv)上看到了I / O和I / O工作量大的系统停顿的情况。
我的问题是:
- 在执行I / O繁重的工作负载时使用虚拟化解决方案是否明智?
- 围绕这些东西的最佳实践是什么?
- 是什么原因导致这些问题,存在众所周知的系统瓶颈,还是仅仅是争用过多的问题?
我已经在大量的虚拟化服务(Azure)和产品(vmware,kvm,hyperv)上看到了I / O和I / O工作量大的系统停顿的情况。
我的问题是:
Answers:
在执行I / O繁重的工作负载时使用虚拟化解决方案是否明智?
是的,确实非常理智,实际上,对于大多数组织而言,现在虚拟化是默认设置,而在物理设备上执行操作则是非常例外。我们拥有超过100k种各种形式的VM,其中许多IOPS> 40k完全没有问题。
围绕这些东西的最佳实践是什么?
这里的关键不是是否进行虚拟化,而是要了解您的IO需求并匹配虚拟存储资源。就是这么简单,如果您知道自己需要/想要的东西,并且有预算将其与存储系统匹配,那么虚拟化层实际上就几乎没有作用-除非您真的推动了某些事情(我说的是数十/亿个IOP)。
是什么原因导致这些问题,存在众所周知的系统瓶颈,还是仅仅是争用过多的问题?
缺乏理解或尝试使用太少的存储资源来做太多事情,这通常会导致人员问题。
在执行I / O繁重的工作负载时使用虚拟化解决方案是否明智?
数据库服务器是否定期提取1GB /秒的随机IO计数?这里有一个。
或一台虚拟文件服务器向HPC群集提供高达600mb / s的速度。那只在专用的Raid 10战斗机中击落了8个Velicoraptors。
围绕这些东西的最佳实践是什么?
提供大量的IO。我认为此SQL VM具有大约8或10个专用SSD。
导致这些问题的原因有哪些众所周知的系统瓶颈,
人们不做基础数学。如果IO子系统无法处理负载,则在虚拟化条件下也不会处理负载。需要大量IO-然后提供适当大小的专用存储子系统。
除了基本数学和概念(您仍然需要与非虚拟化相同的IO)外,还有QOS /优先级划分。大多数虚拟化平台至少为此提供基本支持,这将有助于防止行为不端的dev VM拖延您的prod DB。