随着 NVMe SSD 的性能和容量不断提高且价格不断下降，高性能无损网络 25Gb/100Gb 的通用化和 400Gb 的出现，新的闪存硬件技术红利已经到来。

在这波新的全闪硬件红利中，各种“全闪分布式块存储产品”眼花缭乱。

难道把存储产品中的介质改成 NVMe SSD，或者存储网络支持 RoCE 就是“真”全闪了吗？用户应该如何擦亮眼睛，识别李鬼？

接下来，我们一起探讨下如何甄别“真”全闪分布式块存储。

首先，我们先看下全闪存储的基本条件“全闪硬件技术”，然后再看下存储软件栈中最关键的核心技术。

 3个基本全闪硬件技术，缺一不可 

• 在实现“真”全闪存储中，所需要的 3 个全闪硬件技术，缺一不可。

• 通过使用 NVMe 协议的 SSD，消除了 SAS/SATA SSD 的性能瓶颈。

• 通过使用 RDMA 技术，网络通信可以绕过 OS 内核，消除 OS 瓶颈，降低 CPU 开销。

通过使用无损以太网，可以消除网络瓶颈。使用这 3 个技术，就可以实现跨网络访问存储只需要 μs 级别，分布式存储也可以像高端集中式存储一样采用 Shared Everything 架构。

全闪硬件技术图

那么把分布式存储中的存储介质改成 NVMe，存储网络支持 RoCE 就是“真”全闪了吗？事情往往没有那么简单。

 存储软件架构需要创新，才能把全闪硬件性能压榨出来 

对于“真”全闪来说，只采用“NVMe over RoCE”硬件技术和硬件是不够的，还需要使用新的存储软件架构，才能发挥出最大的硬件性能。

这是因为在整个读写操作的时延路径中，不仅包括网络时延、硬盘时延，还有“软件处理时延”（反映了存储软件栈消耗的 CPU 资源）。其中降低 “软件处理时延”是最难的。

硬盘时延，可以通过采用 NVMe 盘和用户态 NVMe 驱动来降低。网络时延可以可以通过适配 RDMA 去降低。

“软件处理时延”是由存储软件架构天生决定的，几乎无法优化，只能重写存储软件架构。

所以使用面向混闪的存储软件架构，虽然更换成 NVMe SSD 介质和适配 RDMA 网络能够带来一定的性能提升，但是提升较为有限，这是因为“大头”在软件处理时延上。

从上图，大家能够看到，面向混闪的存储软件架构的软件处理时延在 0.3ms～1.5ms 之间，即使把介质全部换成 NVMe  SSD，把网络换成 RoCE，总时延也是居高不下。所以“存储软件架构”才是关键矛盾，是读写操作时延性能的关键。

存储软件架构是存储产品的基石，决定了存储产品的高度，地基打得好，才能建更高的摩天大厦。

只有全闪硬件核心技术还不够，面向混闪的存储软件架构无法压榨出全闪硬件的性能，更无法面对未来 10 年的硬件高速发展。

新的问题又来了，“真”全闪的存储软件架构需要点亮哪些“科技树”？

综上所述，要将全闪硬件的性能发挥到极致，重写新的存储软件架构是必经之路。在这一过程中，我们必须精准激活点亮“科技树”上的关键节点，避免走入可能的技术误区。

“真”全闪存储的软件架构，要点亮哪些“科技树” 

点错“科技树”的代价巨大，可能导致硬件成本失控，性能提升受限，进而严重削弱存储产品的市场竞争力。

存储高性能的基本保证来自于网络模型、NVMe 驱动、代码架构。

特别是代码架构，通过采用 “RunToCompletion+多核 Polling+无锁”，实现去内核开销，实现免锁、免中断、免内核调度、零数据拷贝，降低软件处理时延。通过使用新的代码架构，我们可以精确的量化每个数据面组件的每个 CPU Core 处理 1 个读写操作请求需要多少 μs 时延。而且我们可以通过多核进行性能 Scale-Out，因为不同 CPU Core 之间是无锁的。

卷属主模型中，“多控制器属主”比“单控制器属主” 更具有性能 Scale-Out 优势，能够充分榨干所有存储节点上的网卡、CPU、NVMe 盘的性能。

在数据布局结构的方法中，使用 “Appendlog（Log-Structured）”比“数据原地更新”有更好的性能表现和可靠性表现，并且对于 SSD 寿命更加友好。只有使用了“Appendlog（Log-Structured）”，才能实现性能无损的 EC+压缩，才能真正的控制存储硬件成本投入，才能做到让分布式全闪存储所需要要的硬件投入比集中式全闪阵列低。

在存储介质访问模型中，使用 “Shared Everything” 比“Shared Nothing”有更好的性能、可靠性、得盘率的表现。

接下来，我们分析一下厂商旗下不同产品的存储软件架构历史和“科技树”演进路径。

 各个产品的存储软件架构历史和“科技树”

我们按照时间线来看各个产品的存储软件架构历史，穿透迷雾，看清“真”相。

通过对各厂商存储产品的历史发展进行梳理，我们可以清晰地看到存储软件架构的演进路径以及不同技术选择对产品性能的影响。以时间线为脉络，从早期的产品如 2011 年 DELLEMC 的 PowerFlex（ScaleIO）开始，其存储网络模型主要基于 TCP 协议，存储介质为 SSD，采用特定的代码架构、卷属主模型、数据布局结构和存储访问模型，随着时间的推移，各厂商产品在技术选择上不断演变。例如，阿里云的 EBS 产品系列从早期到后期逐渐支持 RDMA 技术，数据布局结构从原地更新转变为 Appendlog，卷属主模型也发生了相应的变化。这些变化反映了厂商在追求更高性能和更好可靠性的道路上不断探索和创新的过程。

数据来源：各厂商官网公开数据

 不同存储软件架构的性能对比 

我们已经知道了各个存储产品使用的软件架构，那么我们通过性能差异对比来证明“存储软件架构”的价值。

举例1：vSAN OSA 对比  vSAN ESA 

在 VMware 的官方介绍中，在“性能、可靠性、得盘率”的权衡中，对于 vSAN OSA 和 vSAN ESA 的区别与选择如下：

• 使用 vSAN OSA，在决定使用 RAID-1、RAID-5 还是 RAID-6（*） 时需要进行仔细规划。需要最大化容量的工作负载会选择 RAID-5/6，而需要最大写入性能的工作负载会选择 RAID-1。vSAN ESA 使用新的日志结构化文件系统，允许集群在获得 RAID-6 最大化容量效率的同时获得 RAID-1 的数据存储性能。RAID-5 现在可以在 2+1 或 4+1 配置中运行。这为小至 3 个节点的集群带来了 RAID-5 支持，同时在更大的集群上能够实现的容量效率更高。结合使用 RAID-5/6 纠删码以及不再需要缓存设备的特性，可以显著降低 VMware vSAN 集群的每 GB 成本。

• ESA 重新设计的数据压缩算法也更改为对每个虚拟机的设置，每 4KB 块的写压缩比高达 8:1，这是 OSA 的 4 倍。数据在通过网络之前就获得压缩，从而提高吞吐量并降低网络开销。这些新技术的引入使得用户能够以更低的 TCO 获得更充足的容量和性能。

由上可知， vSAN ESA 通过采用了日志结构文件系统（也就是 Appendlog 数据布局结构）极大提升了在 RAID5/RAID6 场景下的 IOPS 性能和降低时延。

数据来源：XSKY 实验室专业测试

举例2：vSAN ESA TCP 对比  vSAN ESA RDMA

通过下表对比，我们能够知道采用“RDMA”能极大降低时延。

但是读者可能会疑问，ESA 架构下使用 RDMA 的 IOPS 性能为什么对比 TCP 没有提升呢？我们只能猜测应该是 ESA 的代码架构跟 OSA 代码架构没有重写，所以“软件处理时延”没有变化。下表中 ESA 的时延降低都是来自于网络时延的降低。

数据来源：VMware 官网数据

举例3：vSAN ESA RDMA 对比 XSKY 星飞全闪的单卷性能

通过下表对比，我们能够知道卷属主模型采用 AA 架构后，单卷可以使用所有存储节点的 CPU 资源，所以性能会非常好。

数据来源：XSKY 实验室专业测试

几种常见的“坑” 

根据经验，我们列举出一些场景下的存储选型误区，希望能为读者提供有益的参考：

误区一：仅关注硬件升级，忽视软件架构。

把介质换成 SSD，并且支持 RDMA，但是存储软件架构还是老的，这导致无法压榨硬件性能。

误区二：片面追求 IOPS 性能峰值，忽略时延要求。

导致在跑时延敏感性的数据库应用时，应用性能体验非常糟糕。所以可以参考集中式全闪阵列的时延要求，一般时延要求在 0.5ms 内。