在大量的I / O工作负载下，我看到了大量虚拟化服务（Azure）和产品（vmware，kvm，hyperv）I / O和系统停滞。
我的问题是：
在执行I / O繁重的工作负载时使用虚拟化解决scheme是否合理？
是的，确实非常理智，实际上对于大多数组织来说现在虚拟是默认的，在物理盒子上做事情是非常的例外。 我们有超过10万的各种forms的虚拟机，其中许多都是> 40k IOPS，完全没有问题。
这种东西最好的做法是什么？
这里关键的不是它是否是虚拟化的 – 它是理解你的IO需求和匹配虚拟存储资源。 就是这么简单，如果你知道你需要什么，并且有足够的预算来和你的存储系统相匹配，那么虚拟层实际上只扮演着一个或者几乎没有任何作用 – 除非你真的在推动当然的事情（我正在说话几十/数以百万计的IOP）。
造成这些问题的原因是系统瓶颈，还是只是一个过度争用的问题？
由于存储资源太less，缺乏理解或尝试做太多，这通常会导致人们的问题。
在执行I / O繁重的工作负载时使用虚拟化解决scheme是否合理？
数据库服务器是否定期提取1Gb /秒的随机IO数量？ 有一个在这里。
或者一个虚拟文件服务器，可以提供高达600mb /秒的HPC群集。 那个人在一个Raid 10中跑了8个Velicoraptors，这是专用的。
这种东西最好的做法是什么？
提供大量的IO。 我认为这个SQL虚拟机有大约8或10个专用SSD。
是什么原因导致这些问题，有没有众所周知的系统瓶颈，
人们不做基本的math。 如果IO子系统不能处理负载，那么在虚拟化下也不会这样做。 需要大量的IO – 然后提供适当大小的专用存储子系统。
除了基本的math和概念，您仍然需要与非虚拟化相同的IO，还有QOS /优先级。 大多数虚拟化平台至less为此提供了一个基本的支持，将有助于防止开发不当的虚拟机拖延您的prod数据库。