浅析 vSAN 磁盘组架构和缓存盘的“消亡”

Posted 2023-04-06 志凌海纳SmartX

一、vSAN 中的 DiskGroup 架构的问题与应对思路回顾

如何将分散在多个服务器中的本地盘资源整合成集群范围可用的“共享存储资源池”，是超融合架构中的一项关键技术。在 vSAN 中，这项技术是通过“盘组（DiskGroup）”来实现的。

1.vSAN DiskGroup 架构简介

盘组内部采用两级存储架构：一层用于数据的临时缓存 / 缓冲，被称为“缓存层（Cache Tier）”，每个盘组内的缓存必须有且仅有 1 个采用闪存的高速存储设备，通常为固态硬盘 SSD；另一层用于最终存储数据，被称为“容量层（Capacity Tier）”，由 1~7 个固态硬盘或普通磁介质硬盘 HDD 组成。vSAN 允许每个主机使用 1~5 个这样的磁盘组。如图 1 所示的例子中，vSAN 超融合集群的每个主机节点内仅有 1 个盘组，该盘组由 1 块 SSD 缓存盘和 3 块 HDD 容量盘组成。

图 1 vSAN 超融合集群及主机内的盘组结构

由两级不同的存储设备构成的盘组结构，最主要的目的是将经常使用的“热数据”存放在高速 SSD 中，减少对低速 HDD 的直接访问，从而提升整个盘组的平均读 / 写速度。在 10 年之前，SSD 价格还很高的时代，通过使用相对小容量的缓存盘作为”杠杆“，在设定的盘组范围内达到存储性能提升的效果，是一种很好的技术思路。这种思路也在被 VMware 以外的其他超融合厂商使用，如深信服。

2.vSAN 盘组技术在实现中的限制

vSAN 的两级存储架构在产品化过程中存在一些要求和限制：

① 高速缓存盘的容量至少为盘组中所有低速盘总容量的 10%。

• 如图 1 所示，每个盘组的容量层总和为 12TB，那么理论上，缓存层至少为 1.2TB；
• 如果低于这个比例，可能达不到理想的缓存提速效果——通俗说，就是“缓存盘太小，带不动容量盘”；
• 而 vSAN 还有一个技术限制：全闪配置下每个缓存盘上，只有 600GB 空间可以被真正用于对写数据进行缓冲。

② 每个盘组中只能有 1 块缓存盘，无法突破每盘组 600GB 可用缓冲空间的限制。

③ 盘组中唯一的缓存盘存在单点故障的可能，如果它损坏了：

• 该盘组将从集群资源池中退出。
• 该盘组内所有容量盘上的数据无法读取。
• 损失的数据（数 TB ~ 数十 TB）有可能通过保存在其他节点上的数据进行恢复，但后台的数据恢复过程中（几小时 ~ 几十小时），集群存储性能不可避免地会出现一定程度的下降。

3.vSAN 部署方案中应对盘组技术限制的思路

以上技术实现中的限制在 vSAN 7 及以前的版本中一直存在。为了降低这些限制对 vSAN 集群部署的影响，VMware 的 vSAN 部署方案设计中给出的应对思路是：增加集群中每台主机上的盘组数量（如图 2 所示）。

图 2 vSAN 集群实施方案设计

vSAN 集群的单台主机上，最多可以允许设置 5 个盘组。因此，可以通过增加主机内部的盘组数量方法，一定程度上减轻单个缓存盘故障的影响范围，也就是“把鸡蛋放到多个篮子里”。VMware 经过测试，给出的最佳盘组设计方案是：每台主机内设置 2~3 个盘组，每个盘组内设置 3~5 个容量盘。这种设计与 vSAN 存储策略中的条带化数量设置相结合，可以把原本由单块存储盘承担的读 / 写工作，尽可能地分散到多个主机、多个盘组的多个 SSD 上来完成，实现了集群级别存储性能的最优化。

4.“最优设计方案”面临的困境

VMware 提供的最优设计解决方案却很难落实到实际项目中，主要因为这个设计思路会导致：

• 硬件成本提高：缓存层 SSD 和容量层 HDD 单盘容量减小，但数量都要增加，有可能还要增加 RAID 卡的数量——以图 2 的配置举例，由 1 块 SSD + 3 块 HDD，增加为 3 块 SSD + 6 块 HDD，1 块 8 口 RAID 卡也不够用了，需要再加 1 块或换成 16 口的。
• 内存消耗增加：每增加 1 个盘组要增加 ~8GB 内存消耗，每增加 1 个容量盘要增加 240~300MB 内存消耗（具体算法参见文末参考文章 1 ）。
• 维护复杂度增加：运维人员面对更复杂的结构，更多的 SSD + HDD 数量必然引入更多的故障点。
• 主机机箱内的硬盘槽位消耗增加：压缩了今后扩容的空间。
• 更难保持 vSAN 集群的“一致性”：VMware 建议一个 vSAN 集群中所有主机上的盘组数量和盘组内部组成结构都应保持一致（尽管允许存在个别主机、个别盘组的配置不同，但差异越大，造成的整体性能下降幅度就越大），初始设计采用的盘组结构越复杂，今后在同一集群内部扩容时，就越难以保证结构的一致性。

由于存在以上困难，大多数用户的部署中难以满足理想的 vSAN 盘组设计要求，仅仅选择以“单盘组”方式运行 vSAN。这也是为什么很多用户抱怨他们使用的 vSAN 集群的性能达不到 VMware 官方发布的标准。

5.用户对 vSAN 盘组结构的期望

对于以上技术限制，vSAN 用户一直以来希望 VMware 能够对盘组的实现方式进行改善，最主要的诉求包括但不限于：

1. 支持缓存盘冗余，消除盘组内部的单点故障。
2. 解除缓存盘上 600GB 可用空间的限制，在同主机内部使用大容量的 SSD 作为共享缓存盘，简化主机内部的盘组结构。
3. 在集群内各主机、各盘组上，支持缓存盘和容量盘的“异构”，在扩容时可以在更大范围内灵活地选用新型号的存储设备。

这些改进诉求的最终目的，是降低 vSAN 集群硬件选配的复杂度以及硬件采购和维护上的成本。

二、vSAN 8 带来了什么？

1.vSAN 8 ESA 简介

2022 年 8 月底，VMware 正式发布了 vSAN 8 这个里程碑性质的版本。在 vSAN 8 中，引入了“快速存储架构（Express Storage Architecture）”，这为 vSAN 用户提供了一种可选替代架构，目标是以全新级别的效率、可扩展性和性能来处理和存储数据。ESA 不再使用“DiskGroup 盘组”的概念，而是使用“Storage Pool 存储池”，主机中所有符合要求的存储设备不再被分为不同的“组”，不再被分为“缓存层”和“容量层”。

同时，vSAN 原有的基于盘组的架构仍然保留，作为可选的 vSAN 方案之一，它现在被称为 OSA（Original Storage Architecture）。

为了简化，本文以下部分，就用 ESA 和 OSA 来指代两种技术架构。

2.ESA 实现了用户对 OSA 改进的期望吗？

先公布答案：没有。

先来看看启用 ESA 需要什么样的条件：

数据来源：Comparing the Original Storage Architecture to the vSAN 8 Express Storage Architecture

• 启用 ESA 的集群每台主机上，必须使用至少 4 块高性能、耐用的 TLC NVMe 存储盘。VMware 表示，“之所以选择它们，是因为它们能够提供一致的性能、低延迟和减少存储处理所需的 CPU”3。由于闪存技术进步了，对应的商用化产品降价了，VMware 认为，磁介质盘不再是性能提升的瓶颈，真正需要高性能的场景，一定会用基于闪存的存储设备。因此通过高速缓存盘对低速磁盘进行加速，不是 ESA 需要解决的主要问题，ESA 不考虑对于混合盘配置的支持。
• 不是任何主机配备了 TLC NVMe 存储盘都可以启用 ESA，这个主机必须是 “vSAN 就绪节点”（vSAN ReadyNodesTM：经过 VMware 验证的、符合 vSAN 部署要求的服务器整机产品，组件配置相对固定，用户不可自行更改，提供多种服务器品牌和配置组合供选择。）。
• “各节点配置一致”是“vSAN ReadyNodesTM”的强制要求，也就是说，没有提供“组件异构”或“节点异构”的选项。
• 25Gbps 将是对主机网络的最低要求。
• 需要 vSAN Advanced 或 vSAN Enterprise 许可，才能使用 ESA；vSAN Standard 许可只能使用 OSA。

在创建新的 vSAN ESA 集群时，预检查流程将确保客户使用经过批准的硬件，检查内容包括：是否与 vLCM 配置兼容、最低物理网卡速度、主机的物理内存和磁盘类型。

也就是说，虽然 ESA 表面上符合了前文总结的用户对 vSAN 的前两条期望——精简了主机内部的存储设备层次、消除了原有缓存盘的单点故障——但需要更高的硬件配置和软件许可才能实现。这意味着，ESA 并没有满足这些用户期望背后对于“降低成本”的诉求。对于第三条期望，ESA 则完全是背道而驰，进一步严格了对主机、存储和网络组件的选型要求，提高了用户使用 ESA 的门槛。

3.ESA 的主要提升体现在哪里？

看上去 ESA 给用户带来的收益并不美丽，那么 VMware 为什么要推出这个架构呢？我们可以从 VMware 已经发布的一系列关于 vSAN 8 的材料中，得到一些 ESA 技术思路的启示。

(1)“全闪”取代“混闪”

首先，采用高速闪存的存储设备越来越普及，能够负担全闪存储价格的用户也越来越多，在大量需要高速读 / 写的应用场景中，直接通过全闪配置就可以满足性能的要求。因此，VMware 认为使用 SSD 作为 HDD 加速杠杆的做法可以不再保留。

(2)减少数据的存储量

但是，基于 TLC NVMe 的存储设备价格确实比机械硬盘高，从混闪配置到 TLC NVMe 设备，用户需要花更多的钱。怎么能降低这部分成本？或者说，怎么让用户觉得可以省钱呢？ESA 给出的思路是：推广并普及基于纠删码（Erasure Coding）的数据高可用方法和数据压缩。这两种技术可以减少原始数据在存储设备上占用的空间，从而减少昂贵的闪存盘的数量。

注：由于篇幅所限，关于采用纠删码提供数据高可用（RAID-5/6）的原理，以及与镜像副本（RAID-1）方式在存储容量需求方面的对比，本文中就不再涉及了。

(3)进一步为 RAID-5/6 提速

用户对 RAID-5/6 的普遍担心是写性能的下降。RAID-5/6 对写性能的影响主要有两点：一是使用纠删码计算校验块（Parity），需要消耗更多的 CPU 计算周期，二是写入操作会引入额外的读 / 写操作（I/O 放大）。

对于第一点，VMware 认为现在 CPU 的计算能力大大提升了，不会成为瓶颈，可以放心使用。

vSAN 8 ESA 中，先接收来自客户机的写入数据，对这些数据以 4KB 块为单位进行压缩——“数据压缩”现在也作为 ESA 中默认开启的选项，新改进的压缩算法的速度和压缩效率更高——这减少了对存储容量的需求，也减少了使用纠删码计算校验块所需的 CPU 周期。但数据压缩过程对 CPU 的消耗呢？

ESA 对 RAID-5/6 写性能方面的主要改进，是针对以上第二点。

注：为了避免陷入性能泥沼，VMware 要求只能在全闪配置的 vSAN 集群上才能启用 RAID-5/6。这种配置下，读操作可以不经过缓存盘，直接从容量盘读取，除非被读取的数据正好就是缓存盘上的写缓冲内容。vSAN 7 及以前的版本中，就是以这种方式来避免校验块计算可能引入 I/O 的放大。

vSAN 8 ESA 中引入了新的日志结构化文件系统（LFS）和优化的日志结构化对象管理器。LFS 将压缩后的数据块与元数据打包，并使用镜像（Mirroring / RAID-1）方式将这些数据 / 副本和对应的日志写入到不同主机的闪存盘上。临时存储这些数据的区域被称为“性能分支（Performance Leg）”，它不独占某个特定的闪存盘，而是分布在每个闪存盘上。这个过程，由于不需要计算校验块，写入速度会很快，客户机可以在最短时间内获得写确认，表现出整体写性能的提升。

暂时存放在“性能分支”的数据，会被整合为更大的数据块，计算校验块之后，再写入“容量分支（Capacity Leg）”。这次写入发生在后台，发起写入请求的客户机（虚拟机）早已收到了写确认，不会感受到其中的延迟。

图 3 ESA 模式下 RAID-5 写入流程简图

通过以上原理简介，我们知道 ESA 所宣传的“不需要专门的缓存盘”，不意味着不使用缓存机制，它只是把“缓存盘”改成了“性能分支”。写缓冲数据不再独占某个闪盘，而是将临时数据作为“性能分支”分散到所有闪盘上的，因此也不再受到原有 600GB 可用缓冲空间的限制。问题是，每个集群上的“性能分支”总共需要占用多少空间？VMware 目前还没有公布这方面的细节，而是在博客中用了一种很模糊的说法：“它非常小 – 刚好足以将数据传输到持久存储区域”4。

由于采用了“先镜像、后纠删码”的两级数据存储方式，VMware 发布 vSAN 8 ESA 强调的最主要亮点是：“以 RAID-1 的性能，获得 RAID-5/6 带来的存储空间节省”4。为了使用户觉得，ESA 不需要那么多硬件设备，甚至将 OSA 中 RAID-5 采用的“3 数据块 + 1 校验块”模式，“自适应”地降低为“2数据块 + 1 校验块”，从而减少了所需的最低主机数量。以下对比了 OSA 与 ESA 中，RAID-5/6 对主机数量的最低要求。

数据来源：Adaptive RAID-5 Erasure Coding with the Express Storage Architecture in vSAN 8

4.对 vSAN 8 ESA 和 OSA 的小结

至此已经可以看出：vSAN 8 ESA 并不能从根本上解决盘组结构（OSA）中被用户长期诟病的几个关键问题，而是鼓励用户使用更贵的闪盘来获取更高的性能。OSA 用户也无法直接迁移到 ESA，因为几乎所有有意向使用 ESA 的用户都要重新购买 vSAN ReadyNodesTM 服务器。

为了平衡全闪盘集群给用户带来的成本焦虑，ESA 通过：

• 鼓励用户使用 RAID-5/6 代替 RAID-1，以减少所需的闪盘容量和数量。
• 通过默认启用压缩功能以及对压缩算法的改进，减少了对存储空间的要求。
• 改进的 RAID-5 机制小幅降低了对主机数量的要求。

注：这些措施可能对减少存储空间需求有帮助，但毫无疑问地增加了对于 CPU 资源的消耗。

ESA 在获得一定程度改善的同时，部分原本在 OSA 上支持的功能，还不能在 ESA 上启用。关于新版本受到的功能限制和后续更新，请参见 VMware 官方消息。

在 OSA 方面：

① vSAN 8 保留了对 OSA 的支持，原有 vSAN 用户可以升级到 vSAN 8 后继续使用 OSA 模式，不必强制改用全闪盘结构的 ESA，同一个 vCenter 可以同时管理 OSA 集群和 ESA 集群。

② vSAN 8 的 OSA 模式下，缓存盘上的可用空间从 600GB 提高到 1.6TB，但要注意：

• 此空间仅可用于全闪盘组配置下的写缓冲。
• 将在每台主机上、为每个盘组增加 5GB 内存消耗。

无论如何，ESA 消除了“盘组”这一级结构，是一种自我突破。vSAN 发展过程中的技术亮点和缺陷都值得所有其他超融合存储产品不断学习和借鉴，才能提供最符合用户需求的产品。

三、其他解题思路：“共享缓存”与“智能冷热数据分层”技术相结合

除了 ESA，是否存在其他避免“盘组”结构复杂化的解决方案？

有的。如国内独立超融合厂商 SmartX，以自主研发的分布式块存储技术为核心，将“共享缓存”与“智能冷热数据分层”技术结合，对比“盘组结构”的限制和不足，具有以下优点：

• 主机内没有“盘组”这种结构：在集群内的每个主机上允许共享 2 个以上大容量缓存盘组成的缓存层（单台主机最大支持 16TB 缓存盘和 80TB 容量盘），避免了缓存层设备的单点故障。
• 通过 2 级 LRU（Least Recently Used）算法对冷热数据进行生命周期管理，提升数据缓存层利用率。
• 缓存盘上 System 和 Meta data 分区在节点内部作镜像，Journal 和 Cache 分区支持跨节点镜像，进一步提升缓存层的高可用特性。
• 不同规格型号的主机、缓存盘、容量盘可以组成异构集群，为用户提供更灵活的扩容选择。
• 对特定的存储要求，也支持将全部盘资源用于存储的“不分层”模式。
• 通过“本地优先”的读写路径，提升虚拟机对存储的访问性能。

SmartX 分布式存储可以与 vSphere 进行超融合部署，为困扰于 OSA 盘组结构限制但又无法使用 ESA 的用户，提供了一种选项。

更多 SmartX 超融合技术讲解和测试对比，请参见：

VMware 替代合集 | 技术路线、厂商评估、技术分析与对比

VMware 替代专题 | VMware 超融合国产替代之性能对比篇

VMware 替代专题 | VMware 与 SmartX 分布式存储缓存机制浅析与性能对比

VMware 替代专题 | VMware 与 SmartX 快照原理浅析与 I/O 性能对比

《不止弹性，更加灵活。一文了解 SmartX 超融合如何扩容》

参考文章：

1. Understanding vSAN memory consumption in ESXi 6.x and 7.x (2113954) | VMware KB https://kb.vmware.com/s/article/2113954

2. Adaptive RAID-5 Erasure Coding with the Express Storage Architecture in vSAN 8 | VMware https://core.vmware.com/blog/adaptive-raid-5-erasure-coding-express-storage-architecture-vsan-8

3.Comparing the Original Storage Architecture to the vSAN 8 Express Storage Architecture | VMware https://core.vmware.com/blog/comparing-original-storage-architecture-vsan-8-express-storage-architecture

4.RAID-5/6 with the Performance of RAID-1 using the vSAN Express Storage Architecture | VMware https://core.vmware.com/blog/raid-56-performance-raid-1-using-vsan-express-storage-architecture

5. An Introduction to the vSAN Express Storage Architecture | VMware https://core.vmware.com/blog/introduction-vsan-express-storage-architecture

6. Increased Write Buffer Capacity for the vSAN 8 Original Storage Architecture https://core.vmware.com/blog/increased-write-buffer-capacity-vsan-8-original-storage-architecture

7. vSAN Frequently Asked Questions (FAQ) | VMware https://core.vmware.com/resource/vsan-frequently-asked-questions-faq

如何彻底删除vSAN Disk Group里的闪存盘或HDD盘

　　这是因为在bios里的相关选项里禁用了这个选项。解除禁用即可。
　　方法：
　　1、磁盘第1启动顺序一定要设置为：[Hard disk]硬盘启动：
　　2、进入bios选项，选择[HDD S.M.A.R.T. Capability]磁盘自动监控及回报功能！bios默认的设置禁用了此项：
　　3、将其开启。变为enabled。
　　4、再将光标移到[Hard disk boot priority]磁盘启动选项中：
　　5、用+或-键移动其光标选择要启动的磁盘，按F10保存退出即可。
　　按照以上步骤就可以完成U盘启动设置方法，解决了主板BIOS没有USB-HDD选项问题。 参考技术A 1、磁盘第1启动顺序一定要设置为：[Hard disk]硬盘启动：
2、进入bios选项，选择[HDD S.M.A.R.T. Capability]磁盘自动监控及回报功能！bios默认的设置禁用了此项：
3、将其开启。变为enabled。
4、再将光标移到[Hard disk boot priority]磁盘启动选项中：
5、用+或-键移动其光标选择要启动的磁盘，按F10保存退出即可。
按照以上步骤就可以完成U盘启动设置方法，解决了主板BIOS没有USB-HDD选项问题。 参考技术B 对于初学者来说，vSAN是个很好玩的东西，不过，对于初学者来说，vSAN的建设不太难，但是破坏还不一定那么简单。当我们构建了Virtual SAN环境测试之后，不想要了就可以删掉了，按照正常的工作流程，我们一定是删除掉Disk Group，然后关掉vSAN Cluster。但是，这样做有一个问题：闪存盘和SSD盘里的东西还在，而且没法被当作普通的磁盘设备添加为VMFS；
这种情况下，我们vSphere Client或vSphere Web Client登录系统后，在Datastore添加向导里无法添加新的Datastore，虽然此时那些SSD和HDD都没用了。而且，当我们尝试去在下图所示的，图形界面Detach这些设备时，系统也会报错：
然后，尝试进入命令行界面执行命令：
#partedUtil delete /vmfs/devices/disks/mpx.xxxxxxxx
执行上面的命令时，系统汇报磁盘出于Read Only状态；
执行如下命令查看文件系统时，可以看到文件系统格式为Virsto格式：;
#partedUtil get /vmfs/devices/disks/mpx.xxxxxx
这个问题是由于vSAN虽然关闭了，但是也锁定了磁盘为Read Only模式，要想使用，就需要从vSAN入手，步骤如下：
1、首先需要执行如下命令查看vSAN的Disk Group以及Disk Group里的各个对象的UUID信息，这个很重要，无论是破坏还是建设，它都很重要：
#esxcli vsan storage list
2、记录下上图中标识的UUID（也就是你想要彻底删除磁盘的UUID信息），然后执行如下命令，干掉它：
#esxcli vsan storage -u YYYYYYYYYYYYYYYY
如下图所示，如果成功，它不会有什么提示，但是再次运行esxcli vsan storage list命令时，将看不到东西
备注：上面的YYYYYY是前面记录下的UUID信息；
3、执行完成后，再次去到vSphere Client或者vSphere Web Client界面，就会发现，那个原本无法被删除的设备可以被Detach了，也可以被添加为Datastore了。