我曾见过许多虚拟化服务（Azure）和产品（vmware、kvm、hyperv）在繁重的 I/O 工作负载下出现 I/O 和系统停顿的情况。
我的问题是：
- 在执行 I/O 繁重工作负载时使用虚拟化解决方案是否明智？
- 针对这类事情的最佳做法是什么？
- 是什么导致了这些问题，是否存在众所周知的系统瓶颈，还是仅仅是争用过度的问题？
答案1
在执行 I/O 繁重工作负载时使用虚拟化解决方案是否明智？
是的，确实非常明智，事实上，对于大多数组织来说，虚拟是默认设置，在物理机上执行操作是非常例外的情况。我们有超过 10 万台各种形式的虚拟机，其中许多虚拟机的 IOPS 都超过 4 万台，完全没有问题。
针对这类事情的最佳做法是什么？
这里的关键不在于它是否虚拟化 - 而是很好地理解您的 IO 需求并匹配虚拟存储资源。就这么简单，如果您知道自己需要/想要什么，并且有足够的预算将其与您的存储系统相匹配，那么虚拟化层实际上就起不了多大作用 - 除非您真的在推动事情的发展（我指的是数千万/数亿 IOP）。
是什么导致了这些问题，是否存在众所周知的系统瓶颈，还是仅仅是争用过度的问题？
缺乏理解或试图用太少的存储资源做太多事情，这通常会导致人们遇到问题。
答案2
在执行 I/O 繁重工作负载时使用虚拟化解决方案是否明智？
数据库服务器定期拉取 1gb/秒的随机 IO 计数吗？这里有一个。
或者一个虚拟文件服务器，每秒向 HPC 集群提供高达 600mb 的速度。该服务器在 Raid 10 中运行 8 个 Velicoraptor，是专用的。
针对这类事情的最佳做法是什么？
提供充足的 IO。我认为这个 SQL VM 大约有 8 或 10 个专用 SSD。
导致这些问题的原因是什么？是否存在众所周知的系统瓶颈？
人们不做基本的数学运算。如果 IO 子系统无法处理负载，那么在虚拟化下它也无法处理负载。需要大量 IO - 然后提供适当大小的专用存储子系统。
答案3
除了基本数学和概念（您仍然需要与非虚拟化相同的 IO）之外，还有 QOS/优先级。大多数虚拟化平台至少提供对此的基本支持，这将大大有助于防止行为不当的开发 VM 拖延您的生产数据库。