虚拟机和 I/O 繁重的工作负载，它是否曾经理智过？

Question

我在大量虚拟化服务 (Azure) 和产品 (vmware、kvm、hyperv) 上看到 I/O 和系统在繁重的 I/O 工作负载下停顿。

我的问题是：

• 在执行 I/O 繁重的工作负载时，使用虚拟化解决方案是否明智？
• 围绕这类东西的最佳实践是什么？
• 是什么导致了这些问题，是否存在众所周知的系统瓶颈，或者仅仅是过度争用的问题？

Answer 1

在执行 I/O 繁重的工作负载时，使用虚拟化解决方案是否明智？

是的，确实很理智，事实上对于大多数组织来说，现在虚拟是默认的，在物理机器上做事是非常例外的。我们拥有超过 10 万个各种形式的虚拟机，其中许多虚拟机的 IOPS 超过 40k，完全没有问题。

围绕这类东西的最佳实践是什么？

这里的关键不在于它是否虚拟化——而是很好地了解您的 IO 需求并匹配虚拟存储资源。就是这么简单，如果你知道你需要/想要什么并且有预算来匹配你的存储系统，那么虚拟化层实际上很少或根本没有作用 - 当然除非你真的在推动事情（我说的是几十/数亿 IOP）。

是什么导致了这些问题，是否存在众所周知的系统瓶颈，或者仅仅是过度争用的问题？

缺乏理解或试图用太少的存储资源做太多事情，这通常会导致人们出现问题。

Answer 2

在执行 I/O 繁重的工作负载时，使用虚拟化解决方案是否明智？

数据库服务器是否定期提取 1GB/秒的随机 IO 计数？这里有一个。

或者虚拟文件服务器向 HPC 集群提供高达 600 mb/秒的速度。那个在 Raid 10 中跑掉了 8 个 Velicoraptors，专用。

围绕这类东西的最佳实践是什么？

提供充足的IO。我认为这个 SQL VM 有大约 8 或 10 个专用 SSD。

是什么导致了这些问题，是否存在众所周知的系统瓶颈，

不做基础数学的人。如果 IO 子系统不能处理负载，它在虚拟化下也不会这样做。需要大量 IO - 然后提供适当大小的专用存储子系统。