如何控制 vmware HA 中的准入策略？

Question

简单的问题，我有 3 台主机运行 4.1 Essentials Plus 和 vmware HA。我尝试创建几个虚拟机，这些虚拟机占据了每台服务器 90% 的内存容量。我知道 vmware 在虚拟机中具有非常复杂的内存管理，但我不明白 vCenter 如何允许我在仍然可以处理主机故障转移的情况下打开超过临界内存级别的虚拟机。

是不是因为虚拟机不使用内存，所以它仍然被认为是空闲的，所以虚拟机可以开机？但是，如果所有 VM 在主机故障之前都真正使用 RAM 会发生什么情况——它们在故障后无法迁移到其他主机。

XenServer 中的默认行为是，它会自动计算群集内可以使用的最大内存级别，以便主机故障仍然受到保护。Vmware 做同样的事情吗？

准入策略已启用。启用 Vmware HA。

Answer 1

HA 的准入控制使用称为“插槽”的东西来计算在配置的主机数量发生故障时是否有空间容纳所有 VM。即使集群中的内存资源开始看起来很糟糕，插槽计算也允许您继续为虚拟机供电。

准入控制和插槽

“插槽”机制旨在采用通用方法将集群分解为 VM 大小的估计块，然后确保在丢失配置的主机数量后，每个运行的 VM 仍然有可用的插槽。

计算插槽大小

插槽大小计算中发生的第一件事。它正在寻找的是保留资源，或者更具体地说，就保留资源而言，集群中最大的虚拟机。这样做的原因是为了确保集群中的每个资源槽都能够提供足够的资源来满足最大 VM 上的资源预留，以便在发生以下情况时不会降级资源低于其预留的最小值HA 故障转移。

对于 CPU，找到 VM 上的最高预留并将其用作插槽大小。如果没有预留，则使用最小值，在集群的das.vmCpuMinMHz设置中配置；4.1 中的默认值为 256Mhz，但在 5.0 中降至 32Mhz。

对于内存，使用内存预留加上VM 的内存开销 - 因此，如果没有预留，您的插槽大小将是最高 VM 的内存开销数或集群das.vmMemoryMinMB设置（如果已配置）之间的较大数字（文档目前说默认值为 256MB；这不是真的，4.1+ 中的默认值为 0）。

这些数字结合起来为您提供集群的插槽大小。

假设您没有保留，您的插槽大小可能是最小值 - CPU 为 256Mhz，而内存插槽大小将是开销最大的 VM 的内存开销大小。

在频谱的另一端，如果您有一个具有大量内存预留但没有 CPU 预留的 VM，以及另一个具有大量内存预留的 VM，则您的插槽大小将根据每个预留的大数进行计算 - 每个两种资源中的插槽都非常大，这将非常有限 - 在您达到相关资源使用水平之前很久，您就会被准入控制阻止打开虚拟机。

为了解决该特定问题，您可以手动设置每个资源的插槽大小上限：

• das.slotCpuInMHz 设置插槽计算的 CPU 部分的最大大小
• das.slotMemInMB 设置内存的最大值

如果您使用这些，那么这些编号上的 VM 将被分配多个插槽，以便在故障转移后仍能保证它们具有预留的资源价值。

计算插槽和执行限制

确定插槽大小后，将计算群集中每台主机上的插槽数。

较低的资源决定了它们的限制 - 因此，如果主机在 CPU 资源方面可以容纳 100 倍的 CPU 插槽大小，但只能容纳 30 倍的内存限制，则主机有 30 个插槽。

该数字是为集群中的每台主机加起来的。这就是配置的准入控制限制生效的时候。如果您已将集群配置为容忍 1 个主机故障，那么它会从计算中删除具有最多插槽的主机；如果设置了 2 个主机故障，则丢弃前两个插槽计数的主机。它假设您将失去最大的主机。

一旦完成，集群中剩余主机上的插槽数就会相加 - 这就是在阻止您启动虚拟机之前允许您运行虚拟机的插槽数。

集群摘要选项卡中的“高级运行时信息”链接将告诉您您的插槽设置为什么。

（忽略 vCPU 数量；不再用于槽计算）

那样有用吗？

我知道你在想什么。

“等一下，我的虚拟机有几 GB 的 RAM 内存！它们到底应该如何运行在某个任意小尺寸（如 256MB）的“插槽”中？ ”

它们应该以资源预留指定的最低级别运行；如果他们没有保留，那么他们不一定运行得很好。

如果在资源使用量已经相当大的情况下发生 HA 故障，那么当额外的 VM 被添加到负载时，您可能会遇到严重的资源争用。

如果 CPU 资源处于争用状态，那仅意味着所有正在运行的 VM 的可用 CPU 时间都有效减少。在某些情况下，这可能会产生相当严重的影响 - 当 CPU 时间争用时，在具有多个 vCPU 的机器上使用的虚拟对称多处理可能会真正开始受到影响。

如果内存是争用的资源......好吧，那就是它变得有趣的时候。

ESX(i) 有许多处理内存争用的技术。有一个关于他们的深度文档在一个伟大的位置，但总结，管理程序需要这些方法：

• 透明页面共享
  • 在来宾 VM 中查找重复的内存页面。如果有多个运行相同的操作系统，则很可能存在重复项。多余的副本被丢弃，所有读取内存的尝试都指向一个副本。
  • 这一直运行，按照Mem.ShareScanTime设置确定的时间表- 每小时一次是默认值。
• 热气球
  • 作为来宾 VM 中 VMware Tools 的一部分运行的代理从虚拟机管理程序收到通知，表明它需要一些内存。在 VM 中运行的代理开始尝试通过向来宾操作系统询问内存来尝试从来宾取回内存，从而膨胀代理使用空内存的“气球”。这会强制客户操作系统采取措施释放内存，包括从内存中清除文件系统缓存或将内存页面交换到自己的交换空间。一旦内存页面被成功抓取到气球中，它会通知主机可以回收内存。
  • 这是主机在遇到内存争用时将采取的第一个操作。
• 内存压缩
  • VM 内存的页面被压缩，但仍存储在主内存中。这意味着访问该内存页面仍然会受到惩罚，但它仍然比从交换中提取要快。
  • 这用作交换前的最后一个“好”选项。
• 管理程序交换
  • 您可能已经注意到，当 VM 启动时，会在数据存储上创建一个与 VM 内存大小相等的交换文件。这种保留有效地使得，如果绝对必要，整个 VM 的主内存可能会驻留在磁盘上。如果发生这种情况，性能显然会很糟糕 - 但这个选项是最后的手段。但是，整个内存页被移动到数据存储中的交换文件；访问时，需要从磁盘中检索它们。

它们的最小插槽大小与 VM 的内存开销有关，这绝非偶然。那是因为开销数字确实是运行 VM 绝对必要的唯一内存 - 尽管“运行”这个词可能太强了，如果 VM 的整个内存最终都在交换中。

因此，准入控制并不是要确保所有 VM 在 HA 故障转移后都能正常运行，而是要确保所有 VM 都可以运行。

所以我该怎么做？

在发生 HA 故障转移时，准入控制会尝试强制执行最低级别的服务。但是，只有在您实际定义了最低服务级别时才会这样做；很多环境不需要或不需要预订。

如果您打算使用准入控制，我建议您调查您的插槽大小并将它们推向对您有意义的值；如果您不需要它们只是为了影响准入控制，请不要开始创建预订。

如果由于集群中没有任何预留空间而将您的插槽大小设置为或接近最小值，则将其推向更适合您的环境的“正常”VM 大小。在集群的高级设置中进行如下设置：

das.vmCpuMinMHz = 500
das.vmMemoryMinMB = 2048

如果由于少量高预留虚拟机而将插槽大小设置得太高，请适当向下推。

das.slotCpuInMHz = 1000
das.slotCpuInMHz = 4096

确保准入控制为插槽大小提供的值对您的环境有意义 - 您绝对不希望从交换空间运行一半的 VM，因为准入控制认为您不关心它们的服务水平！