VMware 采用的成组调度是一个严重的缺点吗？

Question

我正在阅读一些技术网文章以及这篇关于 VMware 和 hyper v 执行 CPU 调度方式之间的差异的文章。

我想知道我是否能得到一些关于这个的客观信息。看起来VMware使用的帮派调度是一个巨大的劣势，但我不想只是喝coolaid。它会严重影响性能还是 VMware 的虚拟机管理程序的最新迭代解决了这个问题？

编辑：当我说劣势时，我的意思是相对于 Hyper V 的“免费处理器调度”或 KVM 所做的。我正在阅读的材料没有说“自由处理器调度”存在任何问题，而帮派调度可以避免这些问题。

Answer 1

就像对着昏暗的浴室镜子吟唱血腥玛丽一样，让我们看看能否让杰克·奥辛斯出现……

群调度也称为协同调度。我认为 VMware 更喜欢协同调度这个词，而不是群调度。

在版本 3.x 之前的 ESX 版本中，VMware 使用“严格”协同调度，这具有同步缺陷。在 ESX 3.x 及更高版本中，VMware 切换到“宽松”协同调度。

宽松的协同调度取代了 ESX 3.x 中的严格协同调度，并在后续版本中进行了改进，以实现更好的 CPU 利用率并支持广泛的多处理器虚拟机。与严格的协同调度算法相比，宽松的协同调度具有一些独特的特性。最重要的是，虽然在严格的协同调度算法中，滞后 vCPU 的存在会导致整个虚拟机被协同停止。在宽松的协同调度算法中，领先的 vCPU 会根据与最慢的同级 vCPU 的偏差来决定它是否应该协同停止自己。如果偏斜大于阈值，则领先的 vCPU 将自身共同停止。请注意，滞后 vCPU 的进度明显低于最快的同级 vCPU，而领先的 vCPU 则比最慢的同级 vCPU 取得更多进步。通过跟踪最慢的同级 vCPU，现在每个 vCPU 都可以独立做出自己的协同调度决策。与 co-stop 一样，co-start 决定也是单独做出的。一旦最慢的同级 vCPU 开始运行，共同停止的 vCPU 就有资格共同启动，并且可以根据 pCPU 可用性进行调度。这通过不要求将一组 vCPU 一起调度来解决严格协同调度算法中的 CPU 碎片问题。在前面的 4-vCPU 虚拟机示例中，即使只有一个空闲 pCPU 可用，虚拟机也可以向前推进。这显着提高了 CPU 利用率。通过跟踪最慢的同级 vCPU，现在每个 vCPU 都可以独立做出自己的协同调度决策。与 co-stop 一样，co-start 决定也是单独做出的。一旦最慢的同级 vCPU 开始运行，共同停止的 vCPU 就有资格共同启动，并且可以根据 pCPU 可用性进行调度。这通过不要求将一组 vCPU 一起调度来解决严格协同调度算法中的 CPU 碎片问题。在前面的 4-vCPU 虚拟机示例中，即使只有一个空闲 pCPU 可用，虚拟机也可以向前推进。这显着提高了 CPU 利用率。通过跟踪最慢的同级 vCPU，现在每个 vCPU 都可以独立做出自己的协同调度决策。与 co-stop 一样，co-start 决定也是单独做出的。一旦最慢的同级 vCPU 开始运行，共同停止的 vCPU 就有资格共同启动，并且可以根据 pCPU 可用性进行调度。这通过不要求将一组 vCPU 一起调度来解决严格协同调度算法中的 CPU 碎片问题。在前面的 4-vCPU 虚拟机示例中，即使只有一个空闲 pCPU 可用，虚拟机也可以向前推进。这显着提高了 CPU 利用率。一旦最慢的同级 vCPU 开始运行，共同停止的 vCPU 就有资格共同启动，并且可以根据 pCPU 可用性进行调度。这通过不要求将一组 vCPU 一起调度来解决严格协同调度算法中的 CPU 碎片问题。在前面的 4-vCPU 虚拟机示例中，即使只有一个空闲 pCPU 可用，虚拟机也可以向前推进。这显着提高了 CPU 利用率。一旦最慢的同级 vCPU 开始运行，共同停止的 vCPU 就有资格共同启动，并且可以根据 pCPU 可用性进行调度。这通过不要求将一组 vCPU 一起调度来解决严格协同调度算法中的 CPU 碎片问题。在前面的 4-vCPU 虚拟机示例中，即使只有一个空闲 pCPU 可用，虚拟机也可以向前推进。这显着提高了 CPU 利用率。即使只有一个空闲的 pCPU 可用，虚拟机也可以向前推进。这显着提高了 CPU 利用率。即使只有一个空闲的 pCPU 可用，虚拟机也可以向前推进。这显着提高了 CPU 利用率。

上面的片段来自 VMware 自己的文档。

因此，VMware 不再使用严格的帮派调度。我会将直接来自供应商的文档视为更具权威性。

唯一可以为您提供硬性数字的是基准测试，它完全取决于 CPU 运行的代码类型。但是我可以告诉你，如果VMware处于这样的劣势，那么他们就不会在虚拟化市场上占据最大的份额。

Answer 2

好吧，瑞安，你让我开心。我不像以前那样经常阅读这个论坛，但我碰巧签到了。

Red888，你应该事先知道我是一名在 Microsoft 从事 Hyper-V 工作的软件架构师。我认为大多数阅读本文的人完全有能力点击下面我的姓名链接并发现它，甚至谷歌搜索我，但对于这个答案，完全确定阅读本文的人对我的观点没有怀疑是很有用的。

一般而言，如果管理程序无法影响 VM 中运行的操作系统的行为，则群调度很有用。当然，这就是 VMware 以这种方式起步的原因。他们不拥有任何操作系统，因此他们的目标是使现有的操作系​​统运行良好。如果我是他们，这就是我开始的地方。

群调度，VMware 可能会说我在这方面是对的，这对如何使用机器内的物理处理器留下了很多限制。管理程序通常无法找到适合当前的正确资源。所以他们多年来一直在修改他们的算法，寻找更好的调度方法。

微软（可能还有其他几家公司）从不同的观点开始。我们拥有 Windows。我们将使 Windows 在虚拟化时表现良好。因此，帮派调度将是不必要的。我们甚至不会费心构建一个帮派调度程序。

有趣的是，我们微软更关心 Windows 与其他操作系统相比运行良好，而不是我们关心 Hyper-V 看起来比 VMware、KVM、Xen、Oracle 或 Unisys 等更好。 所以我们发布了 Windows 的接口用于与管理程序合作。如果你好奇，这里有一个链接，虽然我不推荐它作为睡前阅读：

http://www.bing.com/search?q=Hypervisor+Top-Level+Functional+Specification+3.0a%3A+Windows+Server+2012&src=IE-SearchBox&FORM=IESR02

因此，任何管理程序供应商都可以公开将触发 Windows 协作行为的内容。他们中有几个人有。老实说，我不知道 VMware 是否已经、已经或将要公开这一点。你得问他们，或者问那些非常关注他们的人。如果他们这样做了，如果他们没有修改他们的调度程序以更加放松，我会感到非常惊讶。当然，最后一句话纯属猜测。

所以我的底线答案是，我怀疑您是否应该根据管理程序调度程序的工作方式在 2014 年做出购买决定。我怀疑他们现在都很好。几年前，这可能不是真的。

您应该在各种系统上尝试您的工作负载，看看它们是如何工作的。我敢打赌，您的最终性能取决于您的存储和网络是否满足您的需求。