鲁达 引言：从vSAN支持全闪存到现在已经有7年，终于还是把这个功能等来了。
随着VMware本次发布vSphere 8.0大版本，连续两天看到新闻。前一天是“将‘大’x86 Server的Hypervisor运行在‘小’arm Server上”，如下图：
图片点开后可放大，以下同
相关背景，我在今年2月的《VMware+SmartNIC：把vSAN和NSX卸载到Arm & 裸金属支持》一文中已经交代差不多了。VMware本次正式宣布的首家DPU硬件合作伙伴——NVIDIA Bluefield并不令人意外。
当ESXi运行在DPU上之后，上层既可以是VMware虚拟机，也可以是裸金属操作系统了。这样vSAN存储、NSX网络这些也就可以不只服务于虚拟化。
我对DPU和网络知识了解有限，下面正题还是要回到存储上。vSAN 8的重大变化就是引入新的Express Storage Architecture（ESA）架构，同时与原有的存储架构（OSA）并存，用户多了一种选择。
如上图，在左边的传统vSAN OSA架构中，即使是全闪存部署，在分布式Server SAN块存储的每个节点，具体到每个磁盘组（Disk groups）中都要求有一个Cache SSD（通常使用写密集型SSD以保证性能和寿命，Optane 傲腾SSD更好），以及多个Capacity容量SSD。
这个架构其实是继承自SSD+HDD混合存储，到全闪存之后Cache SSD不再承担读缓存加速，缓存盘上除了所有写入的数据都要过一道之外，应该还有一些vSAN相关的日志等元数据信息。所以这个Cache Tier不是当时立马就可以去掉的。而到了如今NVMe SSD全面普及的时代，传统vSAN架构就显得有些复杂且不够高效了。
到了上图右边的vSAN ESA Datastore，不再需要2种SSD搭配而变为单一分层了，每个节点上都是单一存储池，不再有（混合）磁盘组的概念。专为NVMe SSD优化并且所有盘同时贡献性能和容量。
性能方面，vSAN 8 ESA号称使用RAID-6达到RAID-1的性能；由于不再有Cache SSD被“写爆”的可能，所以说是一致和可扩展的性能；另外快照的性能影响最小化。
改进CPU效率，降低每I/O处理的CPU开销。关于Adaptive自适应RAID-5纠删码，我引用下图来具体讲：
上面引用自官网vSAN Frequently Asked Questions (FAQ)中的Express Storage Architecture (ESA)部分。当2节点集群时，vSAN ESA选择FTT=1即RAID-1双副本模式，仲裁盘只需要放在一个虚拟witness见证主机设备上，而不像传统vSAN OSA需要3节点了。
当集群为3-5台主机时，选择FTT=1使用RAID-5，对象数据（和校验块）可以跨越3台主机（RAID5最小2+1）。在4-5个主机时，相当于有一个备用的失效域主机，在某一个节点故障或者维护时还能恢复到规定的弹性。类似集中存储里面，宽条带化RAID 5 2+1+热备的效果，我理解这个弹性，要在数据存储容量不超过可用容量的75%或者80%的情况下才具备。
当集群为6台主机时，继续FTT=1，类似于宽条带化RAID 5 4+1+热备的效果，容量利用率提高。
当集群为7台主机或以上，选择FTT=2使用RAID-6以确保可靠性和可用性，对象数据（和校验块）跨越6台主机，相当于宽条带化RAID 6 4+2+热备的效果。
具体到vSAN ESA设计的变化，主要整个软件栈中加入的，偏下层的Log-Structured Object Manager（优化的日志结构对象管理器和数据结构），以及偏上层的Log-Structured File System（新的日志结构文件系统，即LFS）。
vSAN-8-ESA-data-structure（是否有点像当初Dell SC/Compellent存储阵列在每一块磁盘内部分层？）
上图是进一步展开看新的vSAN Object Manager的数据结构。以前经常有人问vSAN中为什么有“对象”的概念？这里就能看到在Block Engine块引擎的下面，除了管理到SSD设备带宽的I/O层之外，还有一个夹在中间的KV store（高性能元数据存储）。
在vSAN ESA使用的每个SSD设备上，都会分为3个区域——最小的Metadata元数据区；承担小块写入（包括随机I/O）的Perf. leg components性能区（暂存）；以及大数据块写入的Capacity leg components容量区。
表面上看，一部分数据还是要在SSD上写入2次，为什么要这样设计呢？下面我们来看将Log-Structured File System展开的详细示意图：
vSAN-8-ESA-LFS-performance-and-capacity-legs
在新的vSAN LFS文件系统中，小数据块的写入会合并&打包，先临时快速以镜像方式写入到位于Performance Leg区的持久化日志中，然后元数据经过Matadata log、B-Tree存放在底层vSAN的Capacity Leg区；Capacity Leg（纠删码冗余）除了可以直接写入大数据块之外，经过Performance Leg的数据也会以大块全条带的形式高效转移到这里。
这样设计的结果，既保证了延时敏感型工作负载（如数据库）的性能，又能否减少小块随机写带来的I/O放大，降低SSD设备磨损，并且在LFS上层已经经过压缩处理（默认打开，下面会讲什么情况下建议关闭）。
我认为：Performance Leg存在的最大意义，就是因为Server SAN不像集中存储阵列那样有带电池保护DRAM写缓存，只有数据先高效写入SSD才能保证持久化。
vSAN-8-ESA-performance-capacity-leg-write-details
如上图，Performance Leg除了元数据之外，有点像一个写日志分层，而它与Capacity leg容量分层之间在数据弹性上是对等的，不像传统vSAN OSA那样Cache SSD不计入存储容量。
vSAN ESA会不会因为LFS文件系统而影响性能呢？如果我没记错的话，VMware VMFS经过多个版本的进化，应该也有了类似日志文件系统的特点，特别是推荐SSD使用的Thin VMDK。而vSAN与VMFS之间有些技术应该是共用的。
再来看看压缩。由于vSAN ESA的4K块级压缩放在了vSAN的顶层，所以下面LFS文件系统层面产生的集群内网络开销，以及数据最终写入SSD的CPU I/O开销，都应该因为数据压缩过而减少了。有朋友可能会问：可是顶层压缩也消耗服务器CPU啊？
思考题：是不是因为担心ESXi on DPU 里面的arm核心不够强，才把压缩放到上面（x86 CPU）去处理呢？
vSAN ESA的压缩默认是打开的。根据这条Q&A，有少数工作负载如视频数据、PostgreSQL数据库等应用使用了自带的压缩功能（格式）。在这种情况下就不推荐再二次压缩了，可以节约下CPU。
最后看看vSAN 8.0 ESA和OSA的硬件要求。新架构要求每节点SSD不少于4个，并且是vSAN ESA认证的NVMe设备（不能是SAS、SATA SSD），不再需要Cache SSD了。服务器主机要求必须是经过认证的ReadyNodes，网络不能低于25Gbps。
VMware解释ESA并没增加网络的开销，要求25Gbps只是因为在服务器上已经普及了，并且保证性能。那么除了网卡之外，如果用户的交换机还只是万兆的话，就先别考虑ESA新架构了吧，传统的OSA也还是一种选择。
在vSAN 8版本ESA有哪些不支持的功能呢？如上图，我看到存储策略的最小粒度是VM虚拟机而不是每个VMDK了；另外还有vSAN文件服务、Deduplication（重复数据删除）。其实重删这个技术，在分布式存储上要想全局实现的性能代价太大——要有一个统一访问的Hash元数据池，所以Server SAN真正支持的不多。以传统vSAN OSA为例，重删和压缩也是在每节点的磁盘组内部进行的。
以上就是我的学习笔记，希望对大家有帮助：）
参考资料
2015-2019
《VMware vSAN下一目标：NVMe-oF存储扩展？》
《VMware vSAN 6.7发布：大量新特性》
《为什么ScaleIO和VSAN不要求三副本？》
《VSAN 6.5详解：传统存储特性附体，未来野心更大》
《全闪存专享：VSAN 6.2重复数据删除、纠删码浅析》
《vForum随笔：全闪存VSAN和Nimble CASL的创新》
注：本文只代表作者个人观点，与任何组织机构无关，如有错误和不足之处欢迎在留言中批评指正。如果您想在这个公众号上分享自己的技术干货，也欢迎联系我：）
尊重知识，转载时请保留全文。感谢您的阅读和支持！