vSphere 教育 - 使用 *太多* 内存配置虚拟机有哪些缺点?

eww*_*ite 57 virtualization memory capacity-planning vmware-esxi vmware-vsphere

VMware 内存管理似乎是一个棘手的平衡行为。对于集群 RAM、资源池、VMware 的管理技术(TPS、膨胀、主机交换)、来宾内 RAM 利用率、交换、预留、共享和限制,存在很多变数。

我处于客户端使用专用 vSphere 集群资源的情况。但是,他们正在配置虚拟机,就好像它们在物理硬件上一样。反过来,这意味着标准 VM 构建可能具有 4 个 vCPU 和 16GB 或更多 RAM。我来自从小开始(1 个 vCPU,最小 RAM)的学校,检查实际使用情况并根据需要进行调整。不幸的是,许多供应商的要求和不熟悉虚拟化的人要求更多的资源而不是必要的……我对量化这个决定的影响很感兴趣。


来自“问题”集群的一些示例。

资源池摘要 - 看起来几乎 4:1 过度使用。请注意大量膨胀的 RAM。 在此处输入图片说明

资源分配 - 最坏情况分配列显示这些 VM 在受限条件下只能访问其配置 RAM 的 50% 以下。 在此处输入图片说明

上面列表中顶部 VM 的实时内存利用率图。分配了 4 个 vCPU 和 64GB RAM。它的平均使用量低于 9GB。 在此处输入图片说明

同一个VM的总结 在此处输入图片说明


  • 在 vSphere 环境中过度使用和过度配置资源(特别是 RAM)的缺点是什么?

  • 假设 VM 可以在更少的 RAM 中运行,是否可以说配置虚拟机具有比实际需要更多的 RAM 的开销?

  • 什么是反驳:“如果 VM 分配了 16GB 的 RAM,但只使用了 4GB,有什么问题?? ”?例如,是否需要教育客户VM 与物理硬件不同?

  • 应使用哪些特定指标来计量 RAM 使用量。跟踪“活动”随时间的峰值?看“消费”?


更新:我使用vCenter Operations Manager来分析此环境并获取有关上面列出的群集统计信息的一些详细信息。虽然事情肯定是过载时,虚拟机实际上是这样不必要的RAM配置过高,真正的(微小)内存占用显示在集群/主机级别没有内存争...

我的结论是,虚拟机的大小真的应该合适,并为操作系统级缓存留出一点缓冲区。由于无知或供应商“要求”而过度使用会导致此处出现的情况。内存膨胀似乎在任何情况下都是糟糕的,因为它会影响性能,因此调整大小可以帮助防止这种情况。

更新 2: 其中一些虚拟机开始崩溃:

kernel:BUG: soft lockup - CPU#1 stuck for 71s! 
Run Code Online (Sandbox Code Playgroud)

VMware 将此描述为大量内存过量使用的症状。所以我想这回答了这个问题。

在此处输入图片说明


vCops“超大虚拟机”报告... 在此处输入图片说明

vCops“可回收废物”图...

在此处输入图片说明

Cra*_*son 45

vSphere 的内存管理相当不错,尽管使用的术语经常引起很多混淆。

一般来说,应该避免内存过度使用,因为它会产生这种类型的问题。然而,也有无法避免的时候,所以有备无患!

在 vSphere 环境中过度使用和过度配置资源(特别是 RAM)的缺点是什么?

过度使用资源的主要缺点是,如果您有争用,您的主机将被迫在幕后膨胀、交换或智能调度/重复数据删除,以便为每个 VM 提供所需的 RAM。

对于膨胀,vSphere 将膨胀选定虚拟机内的 RAM“膨胀”,然后将膨胀的 RAM 提供给需要它的来宾。这并不是真正的“坏事”——VM 正在窃取彼此的 RAM,因此不会进行磁盘交换——但如果这些依赖于分析 VM 的 RAM 使用情况,则可能会导致错误触发警报和偏差指标,因为 RAM 获胜不会被标记为“气球”,只是它被操作系统“使用”。

vSphere 可以使用的另一个功能是透明页面共享 (TPS) - 它本质上是 RAM 重复数据删除。vSphere 将定期扫描所有分配的 RAM,查找重复的页面。找到后,它将消除重复并释放重复的页面。

如果您需要更深入的解释,请查看vSphere 的内存管理白皮书 (PDF) - 特别是“ESXi 中的内存回收”(第 8 页)。

假设 VM 可以在更少的 RAM 中运行,是否可以说配置虚拟机的 RAM 多于它们需要的开销?

没有可见的开销 - 您可以在具有 16 GB 的主机上分配 100 GB 的 RAM(但是,由于上述原因,这并不意味着您应该这样做)。

所有 VM 使用的总内存是图表中显示的“活动”曲线。当然,在计算要过量使用的数量时,永远不应仅依赖该数字,但是如果您有历史指标,则可以根据实际使用情况进行分析和计算。

VMWare 社区线程中讨论了“活动”和“消耗”RAM 之间的区别。

什么是反驳:“如果 VM 分配了 16GB 的 RAM,但只使用了 4GB,有什么问题??” ? 例如,客户需要接受教育吗?

对此的简短回答是肯定的——无论使用何种工具,客户都应该始终接受最佳实践的教育。

应该教育客户根据他们使用的内容而不是他们想要的内容来调整他们的虚拟机的大小。很多时候,人们会过度指定他们的虚拟机,因为他们可能需要 16 GB 的 RAM,即使他们在历史上日复一日地在 2 GB 上笨手笨脚。作为 vSphere 管理员,您拥有挑战他们并询问他们是否真的需要他们分配的 RAM 的知识、指标和权力。

也就是说,如果您将 vSphere 的内存管理与仔细控制的过量使用限制相结合,您在实践中应该很少遇到问题,长时间用完 RAM 的可能性相对较小。

除此之外,自动化 vMotion(VMware称为分布式资源调度)本质上是 VM 的负载平衡器 - 如果单个 VM 成为资源占用者,DRS 应该迁移 VM 以充分利用集群的资源。

应该使用什么特定指标来计量 RAM 使用量。跟踪“活动”随时间的峰值?

上面主要介绍了 - 您主要关注的应该是“活动”RAM 使用情况,但您应该仔细定义过量使用阈值,以便在达到一定比例时(这是一个不错的例子,尽管它可能有点过时)。通常,我肯定会保持在总集群 RAM 的 120% 以内,但您可以自行决定合适的比例。

一些关于内存过度使用的好文章/讨论:

  • @James - 在 vMotion 期间仅迁移活动(即正在使用)内存,因此分配给 VM 的 RAM 量并不重要。参考:http://www.vmware.com/files/pdf/VMware-VMotion-DS-EN.pdf (2认同)

pau*_*ska 22

除了 Craig Watson 的出色回答之外,我还想补充以下几点:

在 VMware 中过度使用内存不是你应该故意做的。它通常表明您或您的客户超额订阅了硬件。

如果过度提交是唯一的选择,那么我强烈建议您执行优先级规则。如果有人一心想要在只需要 4GB 的情况下为非关键 VM 提供 16GB 的 vRam - 至少将该 VM 放在低资源池中或给它一个低优先级。您真的不希望虚拟机管理程序换出关键的生产数据库。不仅性能会下降,还会占用后端存储的 I/O 队列。

如果您在极快的存储(FusionIO、Violin、本地 SSD 等)上运行,那么交换可能不是一个大问题,但对于传统的 SAN 存储,您最终会影响连接到同一阵列/控制器的每个 VM 和主机。

  • 很好地观察了交换的存储影响。这解释了我见过的一些 VNX 性能问题...... (5认同)