首页
学习
活动
专区
圈层
工具
发布
社区首页 >专栏 >VMware:内存分层如何破解虚拟化环境下的容量困局?

VMware:内存分层如何破解虚拟化环境下的容量困局?

作者头像
数据存储前沿技术
发布2026-04-15 15:42:54
发布2026-04-15 15:42:54
150
举报

阅读收获

  • 掌握分层内存的核心价值链:理解为何内存扩展能直接转化为软件许可证成本削减,以及如何在 TCO 模型中量化这种收益,这对云厂商的架构决策和产品规划具有直接指导意义
  • 掌握冷热数据分级的主流方案:Linux AutoNUMA/TPP、商用 SDM 方案(MemVerge)、硬件 Flat Memory Mode、DAMON 等多条技术路线的工作原理与适用场景,为技术选型提供全景视图
  • 评估 CXL 对存储体系的重塑潜力:对比 NVMe 与 CXL 在延迟、带宽、一致性等维度的本质差异,预判下一代异构内存架构的演进方向,为研发规划提供技术参考
  • 量化分层方案的实际落地效果:通过 VDI(性能损失 1%、容量翻倍)和数据库(Oracle <5%、SQL Server <10% 损耗)的真实基准测试,消除对性能风险的顾虑,加速采购决策

全文概览

在云计算和虚拟化部署中,一个看似矛盾的现象普遍存在:CPU 利用率长期徘徊在 50% 左右,而内存却捉襟见肘。这背后的本质是什么?当 DRAM 容量成为单节点可承载虚拟机数量的硬限制时,企业的选择往往被迫转向增加物理节点——这在成本结构上意味着额外的服务器投资、数据中心空间占用,以及最致命的:按 CPU 插槽计费的软件许可证成本激增。

在国内服务器价格高企、利旧改造需求旺盛的当下,一些云厂商开始探索一条新路径:通过分层内存技术(Memory Tiering),将冷数据卸载至低成本存储介质,在不改变应用代码的前提下,用 NVMe 或 CXL 等技术延伸内存容量。

这不仅是一个工程优化问题,更是一个架构理念的转变——从"用廉价存储代替 DRAM"的简单思路,升级为"通过智能分类释放 CPU 潜力"的系统方案。本文将通过 VMware 官方的真实场景数据,揭示分层内存技术如何在 VDI、数据库等生产环境中实现 2 倍密度提升,以及这背后的技术权衡与未来方向。

👉 划线高亮 观点批注


PPT 旨在对比两种通过引入 二级内存层(Tier-2 Memory) 来优化虚拟化环境(以 VMware ESXi 为例)总拥有成本(TCO)的不同策略

  • 从“容量替代”转向“性能解锁”: 引入二级内存不仅仅是为了用廉价存储代替 DRAM(如客户 A 关注的硬件单价),更重要的价值在于通过消除内存容量瓶颈,释放 CPU 的计算潜力(如客户 B 关注的整体效率)。
  • 内存扩展对软件许可成本的杠杆作用: 在虚拟化环境中(如 ESXi),限制单台服务器承载虚拟机数量的往往是内存容量而非 CPU。通过扩展内存层,可以显著提高单节点的工作负载密度,从而在相同计算需求下减少物理节点数和按 CPU 插槽计费的软件许可证支出。
  • 分层内存策略的灵活性: 二级内存(可能涉及 CXL 扩展或持久内存技术)可以根据业务生命周期灵活介入。对于“绿地”项目可作为降本方案,对于“棕地”老旧系统则是通过内存扩容延长硬件生命周期、推迟大规模更替的有效手段。

这让我想起当下国内服务器价格高涨,不少云厂商都在做利旧相关的工作。很多应用场景如虚拟化和云桌面等,实际CPU的利用率并不高,但是通过多租户方式对外提供的资源消耗了大量内存容量。因此当下有不少厂商在基于老旧的服务器DRAM来扩展应用系统的内存容量


图片通过直观的进度条和色块矩阵,展示了 CPU 负载与内存页面状态之间的关系:

  • 精细化数据感知是分层存储的前提: 要实现上一张图中提到的“二级内存层”优化,系统必须能够准确区分哪些是“热页面”,哪些是“极冷页面”。这种分类技术是决定数据放置(Data Placement)策略成败的关键。
  • 优化资源分配的依据: 通过将页面分为四级(Hot, Warm, Cold, Very Cold),系统可以将热页面保留在昂贵的、低延迟的 DRAM 中,而将极冷页面迁移至成本更低、容量更大的二级内存(如 CXL 扩展内存或持久内存)中。
  • 解决“内存壁垒”问题的切入点: 图片中 CPU 负载仅为一半,而内存页面显得非常拥挤且状态复杂。这暗示了在现代数据中心,通过智能的页面分类和迁移,可以“解锁”被冷数据占用的昂贵 DRAM 空间,从而提升整体 CPU 的有效利用率。

内存页面数据的冷热程度是根据访问频次以及语义来做区分的。业界有哪些方案是可以用来实现冷热数据分级?

Cite

在业界,实现内存冷热数据分级(Memory Tiering)的核心挑战在于:如何在不修改应用程序(透明性)极低性能开销的前提下,精准识别哪些内存页(Pages)是活跃的(Hot),哪些是基本不访问的(Cold)。

目前,业界主流方案主要分为操作系统内核、商用虚拟化软件、硬件厂商方案以及超大规模互联网公司自研四类:

Linux内核通过NUMA机制演进实现分级存储:AutoNUMA周期性扫描热页面并迁移至本地DRAM;Meta贡献的TPP(v5.18起)优化内存回收,支持主动降级(冷数据挤至慢速层)与快速升级(热数据提升回DRAM),实测DRAM占20%时性能损失仅5%。

商用SDM方案作为中间层插件提供细粒度控制:MemVerge通过驱动虚拟化统一内存池,自动搬运数据并支持快照;VMware在Hypervisor层将CXL/NVMe识别为NUMA节点,透明调度冷热数据。

硬件方案如Intel Flat Memory Mode将DRAM作为CXL/PMem的硬件缓存(Cache Line级),延迟低但对软件透明、灵活性差。

超大规模厂商自研方案:蚂蚁集团结合用户态监控与内核迁移支撑交易系统降本;Google基于内核DAMON框架(区域采样)进行大规模内存监控与调度。

核心技术对比表

方案类别

典型代表

分辨率(粒度)

软件修改

性能损耗

Linux 内核

TPP / AutoNUMA

页面级 (4KB)

无需修改

中等(受扫描频率影响)

商用软件

MemVerge

灵活(页面或对象)

无需/极少修改

较低(算法精细)

硬件模式

Intel Flat Mode

缓存行级 (64B)

完全透明

极低

监控工具

DAMON

动态区域级

需配套策略脚本

可调(极低开销)


图展示了实施分层内存管理后的理想状态,将不同热度的页面分配到了最合适的物理介质中:

  • 实现真正的“降本增效”: 通过将冷页面(Cold/Very Cold Pages)从 DRAM 卸载(Offload)到 NVMe 设备,系统在不影响核心性能的前提下,极大地释放了昂贵的 DRAM 资源。这意味着可以在相同的物理服务器上运行更多的虚拟机或容器。
  • 内存容量的弹性扩展: 这种架构打破了传统主板插槽对内存容量的限制。利用 NVMe 存储作为内存的延伸,系统能够以远低于 DRAM 的每 GB 成本,获得近乎“无限”的逻辑内存容量。
  • 为 CPU “解锁”更多潜力: 图中 DRAM 的大量空闲空间意味着系统现在有能力处理更多的活动数据。这对应了第一张 PPT 中提到的“通过增加 CPU 利用率来节省 TCO”,因为现在有足够的 DRAM 空间去支撑更多的并发计算任务,而不是让 CPU 处于等待状态。

图通过对比 CPU 负载和内存填充情况的变化,揭示了分层内存技术对系统容量的“解锁”效应:

  • 实现“内存受限”向“算力受限”的转化: 在传统服务器中,CPU 往往因为内存溢出而无法满载。本图展示了通过 NVMe 扩展内存层,成功将系统的瓶颈从内存容量转移回了 CPU 算力。这正是第一张图中“Customer B”所追求的:通过“解锁”CPU,极大提高了单台服务器的产出比。
  • 显著提升硬件密度与投资回报率 (ROI): 同样的硬件底座,通过分层技术,现在能跑接近两倍的任务(CPU 从 50% 提升至近满载)。这意味着企业可以用更少的物理节点完成相同的业务需求,从而大幅削减了服务器采购成本、数据中心机柜租金以及能耗支出。

图展示了在 VDI(虚拟桌面基础架构) 场景下,使用 Login Enterprise Benchmark 进行压力测试的结果对比:

  • 打破内存容量对密度的桎梏: 在 VDI 环境中,每个虚拟桌面都需要占用固定的物理内存。传统方案中,1TB DRAM 限制了只能跑 128 个桌面;而分层内存通过将“温/冷”桌面数据存放在 NVMe 中,直接让单机承载能力翻倍,验证了前文提到的“解锁 CPU 利用率”的逻辑。
  • 近乎无损的性能平衡:1% 的性能损失是一个极其出色的技术指标。这表明其页面分类算法(Page Classification)和冷热数据迁移逻辑非常精准,确保了高频访问的数据始终驻留在高速 DRAM 中,而用户对二级内存带来的微小延迟几乎无感知。
  • 极高的 TCO 优化潜力: 虽然增加了 NVMe SSD 的成本,但相对于再采购一台配备 1TB DRAM 的服务器(包括 CPU、主板、许可证和机架空间)而言,增加 NVMe 的支出微乎其微。这为大规模云桌面部署提供了一个极具性价比的参考模型。

PPT 展示了在两种主流企业级数据库(SQL Server 和 Oracle)下,使用基于 NVMe 的分层内存方案的性能对比:

  • 数据库场景下的“高可用内存扩展”: 数据库通常是“内存大户”,传统上为了保证性能必须全部驻留在 DRAM 中。此数据证明,通过智能分层,即便是 SQL Server 和 Oracle 这类重型应用,也可以利用 NVMe 扩展内存池,在不牺牲核心用户体验的前提下,处理双倍的业务流量。
  • 性能损耗的可控性: 值得注意的是 Oracle 的性能损耗(<5%)比 SQL Server(<10%)更低。这反映了不同数据库引擎的内存访问模式对分层技术的敏感度差异,但总体而言,这种量级的损耗在换取 2 倍密度提升时,在商业决策中极具吸引力。
  • 显著降低单次交易成本: 通过在同一台物理服务器上运行双倍的数据库实例,企业不仅节省了服务器硬件投资,更重要的是节省了极其昂贵的数据库软件许可证(License)费用。这标志着分层内存技术已从“实验室概念”成熟到了足以支撑企业核心任务(Mission-Critical)的水平。

图通过三个阶段的架构图,描绘了内存扩展与分层技术的演进过程,顶部的蓝色星形标注特别强调了 “VCF 9x 版本将支持 CXL 平台”(VCF 指 VMware Cloud Foundation):

  • CXL 是未来内存架构的核心: 图片清晰地表明,业界正在从利用 NVMe 盘做内存分层,转向利用 CXL 协议连接的专用内存模组。CXL 提供了比传统 NVMe 更低的延迟和更高的带宽,使二级内存的性能更接近原生 DRAM。
  • 从“存储模拟内存”转向“原生内存扩展”: 愿景的演进体现了从“软件驱动的 NVMe 换页(第一阶段)”到“软硬件协同的异构内存交织(第二阶段)”,再到“智能感知热度的 CXL 分层(终极阶段)”的转变。
  • 生态系统的深度集成: 顶部关于 VCF 9x 的标注具有重要的行业意义。这预示着企业级虚拟化平台将原生支持 CXL 硬件,使得这种复杂的异构内存管理对上层的虚拟机(VM)和容器(Container)透明化,降低了企业采纳新技术门槛。

如何理解 CXL 提供了比传统 NVMe 更低的延迟和更高的带宽?

虽然 CXL (Compute Express Link)NVMe (Non-Volatile Memory express) 底层都物理挂载在 PCIe 总线上,但它们在协议层、数据访问模式以及硬件处理逻辑上有着本质的区别。

特性

NVMe (基于 PCIe)

CXL (基于 PCIe 物理层)

访问单位

块 (4KB 或更大)

缓存行 (64 字节)

软件路径

内核 I/O 栈、驱动程序

Load/Store 指令 (硬件直接处理)

典型延迟

10μs ~ 100μs (基于 SSD)

~200ns (基于 DRAM)

一致性

不支持硬件缓存一致性

支持硬件级缓存一致性

应用目标

长期存储与数据持久化

内存池化、容量扩展、算力协同

尽管时下火热的模型推理和 Agentic 沙箱应用等这些场景,都将目光放在了Nvidia更极致的片上互联上,决心通过定制化的片上互联协议,如 NVLink、UAlink 来打破数据访问的内存墙。但笔者认为,在生态完全成熟之前,基于 CXL 的互联存储是相对更容易落地的可行方案,尽管其基于 PCIE 的底层协议注定了没有办法做到极致的传输带宽,但在绝大部分通用场景仍能满足存量应用的架构扩展


延伸思考

这次分享的内容就到这里了,或许以下几个问题,能够启发你更多的思考,欢迎留言,说说你的想法~

问题 1:内存分层的精准度瓶颈 文章提及页面分类是分层存储的前提。在实际部署中,如何在不同工作负载切换的场景下(如云桌面用户的日常办公到月末报表分析),保持对热/冷数据的动态识别准确率?这对系统开销和性能损耗会产生怎样的放大效应?

问题 2:CXL 生态的成熟度与替代路线 尽管 CXL 在延迟和一致性上相比 NVMe 有本质优势,但短期内物理硬件生态仍不完善。在等待 CXL 生态成熟的窗口期,国内云厂商是否应该投资基于 NVMe 的分层方案作为过渡?这会如何影响未来向 CXL 的平滑迁移?

问题 3:分层方案对应用架构的长期影响 当分层内存使得单节点容量"近乎无限"后,这是否会改变传统的分布式架构设计理念?换言之,在极端场景下,我们是否需要重新思考"纵向扩展"与"横向扩展"的成本-收益权衡?

原文标题:VMware by Broadcom Memory Vision for Real World Applications

Notice:Human's prompt, Datasets by Gemini-3-Pro

#FMS25 #CXL内存扩展

---【本文完】---

本文参与 腾讯云自媒体同步曝光计划,分享自微信公众号。
原始发表:2026-04-12,如有侵权请联系 cloudcommunity@tencent.com 删除

本文分享自 王知鱼 微信公众号,前往查看

如有侵权,请联系 cloudcommunity@tencent.com 删除。

本文参与 腾讯云自媒体同步曝光计划  ,欢迎热爱写作的你一起参与!

评论
登录后参与评论
0 条评论
热度
最新
推荐阅读
目录
  • 核心技术对比表
领券
问题归档专栏文章快讯文章归档关键词归档开发者手册归档开发者手册 Section 归档