VMware 内存管理似乎是一项棘手的平衡工作。集群 RAM、资源池、VMware 的管理技术(TPS、膨胀、主机交换)、客户机内 RAM 利用率、交换、预留、共享和限制等变量非常多。
我处于客户端使用专用 vSphere 集群资源的情况。然而,他们将虚拟机配置得就像在物理硬件上一样。反过来,这意味着标准 VM 构建可能具有 4 个 vCPU 和 16GB 或更多 RAM。我来自从小处着手(1 个 vCPU,最小 RAM)的学校,检查实际使用情况并根据需要进行调整。不幸的是,许多供应商要求和不熟悉虚拟化的人要求的资源比必要的要多……我对量化这一决定的影响很感兴趣。
来自“问题”集群的一些示例。
资源池摘要 - 看起来几乎是 4:1 的超额使用。请注意膨胀的 RAM 数量很高。
资源分配 - 最坏情况分配列显示,在受限条件下,这些虚拟机只能访问其配置的 RAM 的不到 50%。
上面列表中顶级虚拟机的实时内存利用率图表。分配了 4 个 vCPU 和 64GB RAM。平均使用量低于 9GB。
同一虚拟机的摘要
在 vSphere 环境中过度承诺和过度配置资源(特别是 RAM)有哪些缺点?
假设虚拟机可以在较少的 RAM 中运行,那么是否可以说为虚拟机配置比其本身更多的 RAM 会产生开销?实际上需要?
反驳的论点是什么:“如果虚拟机分配了 16GB 的 RAM,但只使用了 4GB,会有什么问题呢?“?例如,是否需要教育客户虚拟机与物理硬件不一样吗?
应使用哪些特定指标来衡量 RAM 使用情况。跟踪“活动”峰值与时间的关系?观察“已消耗”?
更新:我用了vCenter Operations Manager来分析此环境并获取上面列出的集群统计信息的一些详细信息。虽然情况肯定是过度承诺的,但虚拟机实际上所以过度配置了不必要的 RAM,以至于实际(微小)内存占用在集群/主机级别没有显示内存争用......
我的看法是,虚拟机应该有合适的大小,并留出一点缓冲区用于操作系统级缓存。由于无知或供应商“要求”而过度使用会导致此处出现的情况。内存膨胀似乎在任何情况下都是不好的,因为它会影响性能,因此适当的大小调整可以帮助防止这种情况。
更新 2: 其中一些虚拟机开始崩溃:
kernel:BUG: soft lockup - CPU#1 stuck for 71s!
VMware 将其描述为内存过度使用症状. 所以我想这回答了这个问题。
vCops“可回收废物”图表……
答案1
vSphere 的内存管理相当不错,尽管其使用的术语经常引起很多混淆。
一般情况下,应避免内存过度使用,因为它会产生此类问题。但是,有时无法避免,所以预先警告就是预先准备!
在 vSphere 环境中过度承诺和过度配置资源(特别是 RAM)有哪些缺点?
过度承诺资源的主要缺点是,如果您有争用,您的主机将被迫在后台膨胀、交换或智能地调度/重复数据删除,以便为每个虚拟机提供所需的内存。
对于膨胀,vSphere 将在所选 VM 中膨胀 RAM“膨胀”,然后将膨胀的 RAM 提供给需要它的客户机。这实际上并不是“坏事”——VM 正在窃取彼此的 RAM,因此不会进行磁盘交换——但如果这些依赖于分析 VM 的 RAM 使用情况,则可能导致警报错误和指标偏差,因为 RAM 不会被标记为“膨胀”,只是被操作系统“使用中”。
vSphere 可以使用的另一个功能是透明页面共享 (TPS) - 本质上是 RAM 重复数据删除。vSphere 将定期扫描所有分配的 RAM,查找重复的页面。找到后,它将删除重复数据并释放重复的页面。
看一眼vSphere 的内存管理白皮书 (PDF)- 特别是“ESXi 中的内存回收”(第 8 页)- 如果您需要更深入的解释。
假设虚拟机可以在更少的 RAM 下运行,那么是否可以说为虚拟机配置比其所需更多的 RAM 会产生开销?
没有可见的开销 - 你可以在具有 16 GB 的主机上分配 100GB 的 RAM(但这并不意味着你应该,原因如上所述)。
所有虚拟机使用的总内存是图表中显示的“活动”曲线。当然,在计算您想要超额使用多少内存时,您不应该只依赖这个数字,但如果您有历史指标,您可以根据实际使用情况进行分析和计算。
本文讨论了“活动”RAM 和“已消耗”RAM 之间的区别VMWare 社区主题。
反驳的论点是什么:“如果虚拟机分配了 16GB 的 RAM,但只使用了 4GB,会有什么问题?”? 例如,是否需要对顾客进行教育?
简短的回答是是的- 顾客应该总是接受最佳实践的教育,无论他们使用什么工具。
应该教育客户根据自己的需求调整虚拟机的大小使用,而不是他们想很多时候,人们会过度指定他们的虚拟机,只是因为他们可能需要 16 GB 的 RAM,即使他们过去每天都只能用 2 GB 内存。作为 vSphere 管理员,您拥有知识、指标和权力来挑战他们,并询问他们是否真的需要他们分配的 RAM。
也就是说,如果将 vSphere 的内存管理与精心控制的过度提交限制相结合,那么在实践中很少会遇到问题,长时间耗尽 RAM 的可能性相对较小。
此外,自动化 vMotion(称为分布式资源调度由 VMware 开发)本质上是虚拟机的负载均衡器 - 如果单个虚拟机占用过多的资源,DRS 应该会迁移虚拟机以充分利用集群的资源。
应该使用什么具体指标来衡量 RAM 使用情况。跟踪“活动”峰值随时间的变化?
上面主要介绍了 - 你主要关注的应该是“活动”RAM 使用情况,但你应该仔细定义你的过度使用阈值,以便如果达到一定比例(这是一个很好的例子,尽管它可能有点过时)。通常,我肯定会将总集群 RAM 保持在 120% 以内,但您可以自行决定自己喜欢的比例。
关于内存过量提交的一些好文章/讨论:
答案2
除了 Craig Watson 的出色回答之外,我还想补充以下内容:
在 VMware 中过度使用内存并不是你故意为之。这通常表明你或你的客户对硬件的使用过度。
如果过度承诺是唯一的选择,那么我强烈建议您执行优先级规则。如果有人执意要为非关键 VM 提供 16GB 的 vRam,而它只需要 4GB - 至少将该 VM 放在低资源池中或为其提供低优先级。您真的不希望关键生产数据库被虚拟机管理程序交换出去。这不仅会降低性能,还会占用后端存储的 I/O 队列。
如果您使用的是超快存储(FusionIO、Violin、本地 SSD 等),那么交换可能不是什么大问题,但使用传统的 SAN 存储,您最终会影响连接到同一阵列/控制器的每个 VM 和主机。