从多控阵列到全闪革命:RDMA+NVMe-oF重构高端存储新范式

主要部分目录

- 高端存储定义忆旧

- 技术发展：磁盘路径冗余 & 写缓存镜像技术

- RDMA + NVMe-oF：有利于扩展的Shared-Everying

- 通用硬件？Alletra Storage MP B10000、X10000和VAST

- 参考配置与存储系统架构选型

接前文：《可软件定义的双机热备(HA)存储方案》

高端存储定义忆旧

在《AI时代的高端文件存储系统：IBM、DDN、Weka 和 VAST》中我讨论了一些知名的文件存储，LLM大模型的热度，确实促进了非结构化数据容量和性能的需求。而今天我要跟大家聊的是块存储（SAN），特别是在云计算兴起之前，多数的交易型结构化数据，比如关键数据库等大都放在上面。

在我的记忆中，传统的高端存储系统（阵列）通常认为应包含以下几方面特性：

1、性能，对于SAN块存储协议，交易型应用更多看重IOPS。这个与支持的磁盘/SSD数量以及控制器配置等有关。

2、RAS（可靠性、可用性、可服务性），一般要求可用性达到6个9（99.9999%）。中低端存储，包括大多数x86架构的双控阵列达不到这一水平，所以传统高端存储通常不低于4控，老式的有些是Scale-up/新型多为Scale-out横向扩展形态。IBM DS8000系列虽为双控制器但基于Power小型机，算是个例外吧。

注：后来游戏规则被玩坏了，也有些双控阵列标称6个9可用性，把2套组成双活冗余也算进去了。

3、支持Mainframe大型机和FICON存储网络。以前应该只有IBM、EMC Symmetrix家族和HDS的高端如VSP能达标。但后来一方面大机越卖越少了，另外像HPE 3PAR、国内的菊厂等也推出多控架构的高端存储，不满组这点但性能指标上也够了。

在上一篇转载文章的结尾处，我透露了一些这篇想写的东西。关于今天举例的产品，我在网上看到《HPE Alletra Storage MP B10000：适用于现代工作负载的多协议存储》内容不错，给了我一些启发。

https://www.storagereview.com/zh-CN/review/hpe-alletra-storage-mp-b10000-multi-protocol-storage-for-modern-workloads（英文好的朋友，可以点切换看原文）

上图中的Internal Fabric使用的是RoCE（RDMA以太网），后端JBOF（Just Bundle of Flash）机箱其实也可以称为EBOF或者E-JBOF——通过NVMe-oF协议将其中的SSD连接到前端控制器节点。这样每块NVMe盘对每个控制器都可见，就属于新型的Shared-Everything共享架构。

图中出示的另一点，是可以添加/更换一部分前端的控制器为不同或者较新配置的型号，不像传统SAN块存储阵列那样严格要求对等。谈到这里，我想先回顾下双控/多控存储系统要解决的高可用基础硬件：

技术发展：磁盘路径冗余 & 写缓存镜像技术

1、数据（磁盘/SSD）路径冗余：

在传统集中式存储架构中，RAID/纠删码或者镜像/多副本只解决了基础的数据可靠性。为了达到整个数据链路高可用，SAN存储的前端服务器连接FC（光纤通道）、iSCSI这些存储网络，都支持多路径冗余。而为了应对阵列控制器单点故障，每一块硬盘/SSD至少需要同时连接到2个控制器，这样才能确保HA故障切换。

从我进入IT行业以来，先后经历过支持热插拔的80针SCSI硬盘、FC-AL（光纤通道仲裁环路）硬盘、SAS HDD/SSD，以及今天的双端口NVMe SSD。凡是可用在双控阵列中的，基本上都支持双端口访问。

下面为HPE 3PAR（即后来的Alletra 9000家族）高端存储——4控制器架构的读/写路径示意图：

注意：图中可以看到早期3PAR专有硬件ASIC在控制器互连和Cache管理中的作用，后来应该是用NTB一类的技术替代了。但是像NTB、PCIe Switch、通过背板实现2-Node对NVMe SSD共享访问这些，仍然不属于大型云计算服务商数据中心里的标准化硬件。

上图示意的中间2个控制器，同时通过SAS线缆连接到后端的一个JBOD磁盘扩展柜。只要这2个控制器不同时坏，磁盘/SSD中的数据就能保持访问。同理，另外2个控制器应该也是同时连接到一个或多个JBOD机箱。

读/写路径中的 “W2”，就是我接下来要说的另一个要点：

2、写缓存冗余保护

落盘的数据保证不丢了，但为了性能更高往往还要在DRAM中缓存一部分写Cache（包括压缩/重删也可以用这个）。这块除了要加BBU电池/电容应对断电之外，还要在不同控制器之间做镜像保护。如今双控阵列的成熟方案是通过基于PCIe的NTB（非透明桥接）来实现，上面HPE 3PAR的Full Mesh背板则是多控之间的PCIe全网状连接——理论上能把缓存镜像到多个控制器。这样在有控制器失效时，就可以换个控制器重建DRAM镜像以减少性能受影响的时间——提高服务质量。

如今AMD Instinct MI300等GPU的OAM UBB互连，看上去与当初3PAR存储架构图里面的控制器互连示意图蛮像的（都是点对点/全网状）。当然Infinity Fabric/xGMI的带宽要大多了。

除了3PAR高端系列的Full Mesh背板之外，中端4控的7000系列存储，曾经是通过点对点PCIe Cable来实现“全网状互连”。如下图：

下图则是当年更有代表性的高端存储系统——EMC Symmetrix VMAX，它的多控制器（引擎）间互连使用的InfiniBand网络，软件架构上类似于NUMA的全局缓存管理技术。

扩展阅读：《从VMAX到PowerMax：Dell EMC新一代NVMe高端阵列解析》

上图中并没有完全画出VMAX的后端磁盘连接。实际上每个SAS JBOD也是同时连接到一对控制器，比如我用红圈标出的“双控”。到后来使用NVMe SSD的全闪高端存储PowerMax，是通过带有PCIe Switch的JBOF连接到控制器，保证性能但同时也不容易拓扑到太大规模。（好在控制器对够多，而且NVMe单盘性能够高）

对于普通双控阵列，除了NTB缓存镜像之外，还有下面这种写Cache保护方法：

上图我在《Dell EMC PowerStore详解：NVMe+SAS全闪存阵列，还是一体机？》中列出过。PowerStore的控制器机箱中除了20个SSD数据盘之外，还会有2-4个使用DRAM的NVMe接口“内存盘”，写缓存数据写入到成对的NVRAM中进行Mirror保护。

对于今天更流行的分布式存储而言，许多时候做不到每节点都有NVDIMM或者NVRAM，一方面有跨节点的数据冗余，另外就是像Ceph那样加上Journal或者WAL日志一类的技术来实现Crash恢复的一致性，以保证数据完整性。这类技术在写I/O路径上的开销比传统存储要高，好在全闪存流行了，加上软件层面一些新技术的应用&调优，有些Server SAN的性能也可以跑得挺高。

RDMA + NVMe-oF：有利于扩展的Shared-Everying

前面写了许多铺垫，终于到了本文要谈的代表产品。

上图来自《HPE Alletra Storage MP B10000 architecture》文档，B10000的定位应该是接替以前的9000系列高端块存储系统，但我却找不到像“Full Mesh Backplane”那样复杂的设计结构了。原因是，前后端要解决的那2个问题，都通过RDMA以太网来实现了。

比如NVMe SSD，在示意图的CPU右侧，有一种方式是本地直连24个x2 Lane PCIe Gen4固态盘（每块盘另外2个Lane连接到另一控制器）；还有一种扩展方式就是通过2个100GbE以太网口连接NVMe-oF的JBOF（EBOF）扩展柜。

控制器之间的网络互连，也在之前PCIe的基础上加入了RDMA网络，至少4控跨机箱时用的这个。上图中CPU上方绿色部分，虽然没写具体速率，下文中有资料证明是100Gb，而且与NVMe-oF后端SSD扩展使用不同的网卡。

如果B10000是延续3PAR的架构，那么橙色的Cache（写缓存）部分，也可以靠RDMA网络来在控制器间镜像保护吧？后面我还会列出点关于写缓存不同的描述。

左边是HPE Alletra Storage MP系列双控机型的基础硬件，对应块存储机型就是无需交换机的B101x0系列。在2U双控节点机箱之外，还可以选配最多2个JBOF SSD扩展柜——最多72个NVMe SSD。

注意：JBOF里面也有2个连接节点（HA），其中包含CPU但应该用于管理处理器，SSD的数据路径走SmartNIC/DPU网卡效率更高一些。

前面一张图右侧的是2-4控的高端型号B102x0，当前最多支持2个2U双控节点机箱，通过2台100Gb交换机互连，并最多扩展16个以太网JBOF扩展柜，可支持到384个NVMe SSD。

关于控制器的PCIe扩展卡/接口部分，HPE Quickspec中的描述如下。

Notes:

- 1Slot 3 and Slot 4 can be used for host connectivity (at least one is required), and RCIP is optional; Slot 1 and Slot 2 are used for expansion

请注意这里：对于4控型号需要配2块100GbE双口OCP网卡，其中一块像双控机型那样用于NVMe SSD扩展柜，另一块则是4个控制器节点之间的通信。

不知是否有读者会问，384块SSD盘，4个控制器节点性能够吗？就像我在《一次无需调优的测试：SMT多线程对存储服务器IOPS的贡献》中列出的数字，1颗普通的64核CPU，如果只处理16块Gen4 SSD的IOPS能跑到1700多万；最新一代双路CPU机型可以跑更高（参见：《服务器NVMe调优指南：4900万IOPS、340GB/s带宽 (24x SSD)》）。不过在真实应用环境中很少有这么高的需求；另外在企业级存储系统中，还有RAID保护等更多数据服务开销、网络等各种瓶颈，远不像服务器本地I/O那样简单。

注：我上面讨论的更多从实用角度出发，对于传统厂商的FC/iSCSI/NVMe-oF存储系统而言，多控的意义更多在于提高可靠性/可用性而非性能。至于像SPC-1那样的BenchMark跑分则是另一回事，堆更多控制器上去数字确实会好看的。

所以在这里不要简单地想象把几百块SSD都跑满。个人理解，达到一定数量之后，根据需要的容量来规划配置就好了。

尽管规格表中还只写到4控，但上面的动画却列出了6个控制器，按以往3PAR的技术水平做到8控应该不太难吧。并且现在走RDMA网络互连理论上没有硬件的节点限制，也不需要特别研发背板啥的。

在后端的JBOF SSD机箱中，如果是按照跨JBOF配置的RAID保护，那么即使一台JBOF彻底离线也不影响数据访问。这让我想起以前VMAX还有个跨多引擎（控制器对）来放置RAID的数据条带的技术，如今在NVM-oF以太网Shared-Everything架构下，实现起来变得简单许多。

通用硬件？Alletra Storage MP B1000、X10000和VAST

上面列出的是VAST文件存储的架构图，大家是否觉得在硬件架构上与HPE Alletra Storage MP B10000很接近？其实我在《AI时代的高端文件存储系统：IBM、DDN、Weka 和 VAST》介绍过的HPE GreenLake for File Storage MP就OEM了VAST软件，还有下图中的HPE Alletra Storage MP X10000对象存储，好像也可以使用相同的硬件。

使用相对标准化的服务器（减少对PCIe Switch和NTB设计依赖）、业内通用RoCE交换机，以及E-JBOF NVMe SSD扩展柜这些硬件，还有一个好处，就是适合上云（包括公有云服务商的数据中心里，也不需要加专用设备）。

比如3年前的《NVMe-oF存储扩展：EBOF、FBOF、EBOD生态详解》，就是我与国内某头部互联网公司的朋友交流之后，进一步搜集资料撰写的。

像IBM GPFS文件系统在国内几大互联网/云服务商取得的成功，硬件支持上的灵活以及易维护性应该都是比较重要的（注：还有前北京研发中心资深经理——人称“GPFS老父亲”的贡献）。

单纯从硬件的角度，如今的高端闪存阵列更加接近大众化的x86服务器，这使我又想起了“软件定义的存储”一词。而硬件性能的强大，包括多核CPU、网卡带宽等方面发展也促成了今天的局面。

https://community.hpe.com/t5/around-the-storage-block/under-the-hood-hpe-alletra-storage-mp-x10000-architectural/ba-p/7232413?nobounce 在HPE网站上这段关于Write path写路径的描述，是我在本文中遗留的一个疑问：B10000的写缓存（或者说write buffer）究竟是放在控制器的DRAM，还是SSD盘上呢？

如果有知道的朋友，欢迎在下面留言或者私信告诉我。我还有另一种猜测：如果在每块企业级SSD上划分一个小区域模拟SLC用于写Cache，是不是也可以达到类似VAST另外添加一层SLC SSD的效果？毕竟块存储整体设计上不需要太大的Cache容量。

参考配置与存储系统架构选型

最后转载storagereview网站列出的HPE Alletra Storage MP B10000配置作为参考，存储控制器节点使用的CPU应该是AMD第3代EPYC。

既然是通用服务器架构，那存储控制器具体选择哪个平台更合适呢？在可靠性和成熟度的基础上，核心数/处理性能、I/O扩展能力，以及集成度都是要考虑的因素。比如像EPYC：

-前几代在核心数上有更高选择；

-单CPU即可支持128 Lane PCIe Gen4/Gen5通道。上文中提到HPE B10000每控制器用于前端和后端/扩展接口就要提供4个PCIe槽位，再考虑到2控与4控主板设计的通用性，连接控制器机箱内24块NVMe SSD也要48 Lane PCIe。如果CPU直接提供的信道不够，那就要加PCIe Swtich或者第2颗CPU，成本等跟着上升。

-EPYC还集成了传统意义上的南桥芯片组，有助于主板设计简化（Intel到最新的Xeon 6也开始整合了PCH）。

上图截自AMD文档《Seamlessly Scalable Processing Performance and I/O for Ultra-Efficient Storage from Enterprise to Cloud》

另外我查了下资料，EPYC Embedded（嵌入式）9004、7002和7003系列CPU也具备NTB的支持。

注：本文只代表作者个人观点，与任何组织机构无关，如有错误和不足之处欢迎在留言中批评指正。如果您想在这个公众号上分享自己的技术干货，也欢迎联系我：）

尊重知识，转载时请保留全文。感谢您的阅读和支持！