VMware 与 SmartX 分布式存储缓存机制浅析与性能对比

network

VMware 与 SmartX 分布式存储缓存机制浅析与性能对比

志凌海纳SmartX

于 2022-09-16 14:18:07 发布

532
收藏 3
分类专栏： 产品解析 文章标签： SmartX 超融合
版权

产品解析
专栏收录该内容
31 篇文章2 订阅
订阅专栏
作者：深入细节的 SmartX 一线技术团队

近日，VMware 发布了 vSAN 8，对存储架构进行了重大更新。其中最主要的变化，即引入了新的 Express Storage Architecture（ESA）架构：用“存储池”替代了原存储架构（OSA）中的“磁盘组”，并不再需要专用 SSD 承担缓存加速功能，一定程度上避免了 8.0 之前版本中的专用缓存盘利用率低、易发生缓存击穿等问题。

而值得一提的是，在 vSAN 大版本更新之前，SmartX 即通过统一缓存空间和智能冷热数据管理优化了分布式存储缓存机制，有效规避了上述问题。本文将通过重点解读 vSAN（以 vSAN 7 为例）和 SmartX 分布式块存储组件 ZBS* 缓存机制的原理，并测试对比两种缓存机制下虚拟机性能表现，让读者更好地了解两种技术实现机制的区别对业务可能带来的实际影响。

* ZBS 内置于 SmartX 超融合软件 SMTX OS，可与 SmartX 原生虚拟化 ELF 搭配提供服务。

本文重点
vSAN 7 采用划分读写缓存空间的机制，将缓存磁盘按照容量占比划分为写缓冲区（30%）和读缓存区（70%）。这种方式可能出现缓存利用率低、在访问数据量过大时导致缓存击穿，进而引起性能下降等问题。
ZBS 采用统一缓存空间的机制，并通过 2 级 LRU 算法对冷热数据进行管理，在充分利用缓存容量的同时避免了因访问量激增导致虚拟机性能下降的情况。
本文基于相同的硬件配置和 I/O 读写场景，分别测试 VMware 超融合（vSphere 虚拟化 + vSAN 分布式存储）写入 300 GB 数据、SMTX OS（ELF + ZBS）写入 500 GB 数据时虚拟机的性能表现。结果显示，vSAN 7 难以充分利用缓存介质，发生缓存击穿，导致存储性能下降；而 SMTX OS 即便在写入更多数据的情况下也未发生缓存击穿，虚拟机性能保持稳定。
场景问题
混闪配置是超融合或分布式存储现阶段的主流落地模式。混闪配置是指机器中的磁盘使用 SSD + HDD 混合组成，其中 SSD 磁盘作为数据缓存层，而 HDD 磁盘作为数据容量层。以该模式构建的分布式存储池通过软件算法进行冷热数据自动判断，在提供高性能的同时，还可获得较大的存储容量，进而提升资源利用率，获得相对全闪存储更高的性价比。

在将 SSD 磁盘用作数据缓存层时，部分超融合产品会将缓存容量（Cache）划分为读和写各自独立的两部分。例如，vSAN 7 及更早版本会将每个磁盘组（Disk Group）中的缓存磁盘，按照容量占比划分为写缓冲区（30%）和读缓存区（70%），当读取数据未命中缓存或者写缓存已满，将会直接从容量层进行读写。

注：对于全闪配置的磁盘组，可以将全部缓存盘容量（100%）用于写缓存，不再设置读缓存区。

这种划分读写的方式，虽然可以保障读写 I/O 的缓存击穿空间隔离，但经常导致无法充分利用高速存储介质的缓存空间。例如，在业务虚拟机写数据较多、读数据较少的场景，可能作为写入数据的缓存容量已经被占满，但是读缓存空间还有很多容量没有被使用，反之亦然。

以医疗客户的集成平台建设为例，集成平台通过将各个系统产生的数据集中存储并重新组织，形成医院的数据仓库，帮助医院挖掘数据价值、形成智能化决策，进而加快数字化转型。集成平台通过 ETL 工具，从现有医疗业务系统（如 HIS、EMR 和 LIS 等）的数据库直接抽取数据并进行转换、加载。该过程都发生在中间数据库中，最大程度降低对生产数据库的影响。此时中间数据库会有大量的数据进行写入，使得缓存空间容易被填满，而如果读写缓存采用固定容量分配，就可能会发生写入数据量 > 写缓存空间容量，进而导致缓存击穿、业务访问性能下降。大型三甲医院集成平台平均每天需要处理 900 万条消息，要求峰值处理能力需达到 1000 TPS，存储性能不足易导致整个业务系统卡顿，严重情况下甚至会宕机，因此非常考验基础架构 I/O 吞吐能力。

针对这一问题，ZBS 使用统一的缓存空间，不划分读写，所有缓存层容量均被使用，不易出现缓存空间不足从而影响存储性能的情况。同时，通过冷热数据分层技术，依据数据的访问频率，将频繁读写的热数据放置在 SSD 中、长时间无读写的冷数据放置在 HDD 中，有效提升数据缓存层利用率，保证业务高性能稳定运行。

为了让读者更直观地感受到不同的缓存机制对性能的影响，本文将分别介绍 VMware 和 SmartX 分布式存储缓存机制的原理，并测试对比数据写入场景中两种缓存机制下虚拟机性能表现。

技术实现
1.vSAN

vSAN 7 使用磁盘组（Disk Group）将高性能存储介质（如 NVMe / SATA SSD）与低性能存储介质（如 SATA / SAS HDD）组成逻辑存储空间，并通过网络 RAID 功能保障数据可靠性。

每台 ESXi 主机可创建 5 个磁盘组，每个磁盘组中至多仅支持 1 块高性能存储介质与 1 ~ 7 块低性能存储介质组合构成。其中高性能存储介质作为缓存层，并以 7 : 3 容量比例划分为读和写的空间使用，虚拟机在进行数据 I/O 访问时，可使用到其中单个磁盘组的缓存空间。低性能存储介质作为容量层，保存因访问频率较低从缓存层回写（Write Back）的冷数据。

当数据写入写缓存空间后，会基于电梯算法（Elevator Algorithm），周期性地将数据回写到容量层，从而保障缓存层有充足的容量支持后续 I/O 的数据请求。当写缓存空间不足时，会直接写入到容量层。冷数据被读取访问时，会将其加载进入读缓存空间中，缓存空间不足时将直接访问持久化缓存层。

另外，vSAN 7 的缓存数据仅能用于本磁盘组，且缓存数据没有冗余。





2.ZBS

ZBS 在以混闪模式部署的时候会要求选择至少 2 块 SSD 作为缓存容量（Cache），并通过 2 级 LRU（Least Recently Used）算法进行判定、管理数据冷热程度。

在 Cache 中，数据会被划分为 4 种状态，分别是 Active、Inactive、Clean 和 Free。





Active：用来记录访问最频繁和“冷转热”的数据，是 Cache 中“最热”的数据。
Inactive：用来记录首次写入和短时间未访问的数据，是 Cache 中“次热级”的数据。
Clean：用来记录长时间未访问的数据，是 Cache 中的“冷”数据，且数据已经完成了 HDD 落盘。
Free：用来记录未使用或被回收的数据，是 Cache 中闲置的数据空间。
（1）通过 2 级 LRU 链表来管理数据冷热程度

首次进行数据写入时，由于 Cache 中没有数据，会从 Free 中请求未使用的数据空间，数据写入完成后将被记录为 Inactive。





Active 中记录了被访问过多次的数据块，当 Active 的数据超过 Inactive 后，将 Active 数据按照被访问的先后顺序进行排序，不经常被访问的数据会转移记录到 Inactive 中，直到两者的容量相同。





同时当 Active 和 Inactive 的数据容量超过 Cache 空间的 20% 之后， Inactive 数据将开始触发落盘操作，按照时间先后顺序进行排序，排名靠前的早期数据会被写入到 HDD 并在缓存层中被标记为 Clean（此时 Clean 数据在 HDD 和 Cache 中各有一份），后续当 Clean 数据有访问请求时会被重新标记为 Active，否则将被回收为可用空间供写入新数据使用。





（2）不同数据读写场景的处理机制

数据写入场景

Cache 命中写入 Cache 空间并根据当前数据状态发生“冷热”变化。
Cache 未命中Cache 未满，写入 Cache 中的闲置空间。 Cache 已满，写入容量层中。
数据读取场景

Cache 命中系统收到读请求，通过元数据优先查找本地节点 Cache 是否命中请求数据，如果数据在 Cache（Active、Inactive、Clean）中，数据将直接从 Cache 中读取。
Cache 未命中Cache 未满系统会查询本地 Data（容量层）中是否有请求数据，如果有则转向本地容量层请求数据的副本。向本地容量层请求数据的副本，并不是直接读取容量层上的数据，而是首先查询本地 Cache 是否有富余空间，如果 Cache 空间充足，请求数据副本会先从本地容量层中载入到 Cache 中，然后通过 Cache 读取数据，并返回数据读取成功。Cache 已满系统收到读请求，当发现请求数据副本没有在本地 Cache，并且这个时候，本地 Cache 空间已经没有富余空间，请求数据副本会直接从容量层中读取。
测试验证对比
1.测试环境

（1）硬件环境

对比测试时采用相同的硬件环境，均使用 3 台 Dell PowerEdge C6420 服务器 ，每台硬件配置如下：





（2）软件版本





2.测试方法

通过 FIO 测试工具，分别在 vSAN 中写入 300 GB 数据、在 SMTX OS 中写入 500 GB 数据，观察虚拟机性能监控视图的数据表现和变化。

3.测试结果

（1）vSAN

SSD 单盘容量 894.25 GB，读缓存 620.61 GB，写缓存 268.28 GB，读写缓存容量比例为 7:3，符合《VMware vSAN Design Guide》中的描述。





在 256K 顺序写 300 GB 数据测试中，由于缓存空间不足，发生写缓存击穿，性能发生下降，从 280 MB 降低到 75 MB 左右。









在 4K 随机写 300 GB 测试中，同样由于缓存击穿导致了很大的性能下降，IOPS 从 37176 跌落至 16060。







通过上面的测试可以发现，vSAN 7 采用读写缓存空间各自独立，在容量较大的数据请求场景中存在缓存介质无法充分利用的情况，容易发生缓存击穿导致存储性能下降。

（2）ZBS

从缓存容量监控视图可以看出每个节点均有 1.5 TiB 的缓存容量可使用（不区分读写缓存），即 2 块 ~900GB SSD 的可用缓存容量。





首先使用 FIO 在测试虚拟机中 256K 顺序写入 500 GB 数据，观察虚拟机的性能变化。
通过虚拟机性能监控视图可以发现，FIO 测试虚拟机无性能波动，一直处于缓存 100% 命中状态。此时首次写入的 500 GB 数据保存在 Inactive。







再次测试 4K 随机写入 500 GB 数据，观察发现性能依然保持稳定，缓存未击穿。







从上述对比可以发现，在相同的数据容量和 I/O 读写场景中，SMTX OS 能够更好地利用缓存容量空间，即使发生大容量的数据突发请求也不易发生缓存空间击穿导致虚拟机性能下降，进而更好地保障业务稳定运行。

总结
与 vSAN 7 划分读写的缓存机制相比而言，ZBS 在处理数据请求时，通过统一缓存空间的方式，提升了缓存利用率，即使面对业务突发性数据写入和访问激增场景，也能很好地保障业务性能需求。同时，ZBS 采用 2 级 LRU 算法将数据划分为多种热度级别，可对冷热数据进行生命周期管理，缓存层也支持使用多种存储介质（SATA SSD、NVMe SSD 等），用户可根据不同业务的性能需求灵活选择，节省硬件投入成本，获得更高的性价比。

本文参考文档：

1.VMware vSAN Design Guidehttps://core.vmware.com/resource/vmware-vsan-design-guide

2.SMTX ZBS 块存储服务技术白皮书
https://www.smartx.com/resource/doc/general-zbs-white-paper

3.Virtual SAN Read IO – cache / buffer / spindleshttps://www.yellow-bricks.com/2014/01/15/virtual-san-read-io/

4.An overview of VMware Virtual SAN caching algorithmshttps://www.vmware.com/files/pdf ... hing-whitepaper.pdf

5.Announcing vSAN 8https://blogs.vmware.com/virtual ... orage-architecture/

6.医院集成平台 IT 基础架构需求分析与方案选型
https://www.smartx.com/blog/2021 ... tegration-platform/
————————————————
版权声明：本文为CSDN博主「志凌海纳SmartX」的原创文章，遵循CC 4.0 BY-SA版权协议，转载请附上原文出处链接及本声明。
原文链接：https://blog.csdn.net/weixin_43696211/article/details/126889412