基于RDMA技术的Mayastor解决方案

1. 方案背景和挑战

1.1. Mayastor简介

OpenEBS是一个广受欢迎的开源云原生存储解决方案，托管于CNCF（云原生计算基金会）之下，旨在通过扩展Kubernetes的能力，为有状态应用提供灵活的持久性存储。Mayastor是OpenEBS项目中的关键存储引擎，它以其高性能、耐久性和易于管理的特点，为云原生应用提供了理想的存储解决方案。Mayastor的特点包括：

基于NVMe-oF：Mayastor利用NVMe-oF协议，这是一种基于网络的NVMe访问方法，允许NVMe设备通过以太网或其他网络结构进行远程访问，这有助于提高存储系统的性能和可扩展性。

支持多种设备类型：虽然Mayastor优化了NVMe-oF的使用，但它并不要求必须使用NVMe设备或云卷，也可以与其他类型的存储设备配合使用。

与Kubernetes集成：Mayastor作为OpenEBS的一部分，与Kubernetes紧密集成，允许开发人员和运维人员使用Kubernetes的原生工具（如kubectl）来管理和监控存储资源。

Mayastor适用于需要高性能和耐久性存储解决方案的云原生应用场景，特别是在边缘计算、大数据分析、流媒体处理等领域。它可以帮助开发人员构建高可用性和可扩展性的有状态应用，同时降低存储系统的复杂性和成本。通过利用NVMe-oF协议和最新一代固态存储设备的性能能力，Mayastor能够提供低开销的存储抽象，满足有状态应用对持久性存储的需求。

1.2. 问题与挑战

当前Mayastor只提供了NVMe over TCP技术实现数据存储服务，不支持NVMe over RDMA技术，这就不能充分挖掘NVMe SSD盘的性能优势，主要问题和挑战包括：

1、性能瓶颈：

Mayastor依赖于TCP来实现NVMe SSD的数据传输，这意味着它不可避免地继承了TCP的性能瓶颈。TCP的头部开销和拥塞控制机制限制了数据传输的有效速率，尤其是在处理大量小数据包时更为明显。对于需要高速访问和处理的NVMe SSD来说，这种限制可能显著影响Mayastor的整体性能。

2、延迟敏感应用的挑战：

对于那些对延迟要求极高的应用（如高频交易、实时数据分析等），Mayastor当前的TCP实现可能无法提供足够的低延迟保证。TCP的延迟增加和抖动问题可能导致这些应用的性能下降，从而影响业务决策的时效性和准确性。

3、资源消耗：

在高并发场景下，Mayastor处理TCP数据包时涉及的频繁中断和上下文切换会显著增加CPU的负载。这不仅会降低系统整体的计算效率，还可能影响Mayastor处理其他存储请求的能力，导致整体性能下降。

2. 方案介绍

2.1. 整体架构

本方案是基于驭云ycloud-csi架构，将Mayastor整合进来，通过Gateway提供数据通路的RDMA加速，提高IO性能。在Host侧通过DPU卸载，可以进一步解放工作节点上的CPU负载，获取更好的应用性能。整体架构如下所示（标绿和标蓝部分是自研组件）：

本方案将不同的组件分别部署在不同的node，主要包含：

Master Node上，部署 csi的控制器csi-controller，用于创建volume和NVMe-oF target。

Worker Node上，部署csi-node-host，配合csi-node-dpu，通过volumeattachment发现DPU挂载的NVMe盘，然后执行绑定或者格式化。

DPU上，部署csi-node-dpu和opi-bridge。opi-bridge是卡对opi-api存储的实现；csi-node-dpu 负责给host侧挂盘。

Storage Node上，部署Mayastor和GATEWAY，GATEWAY是对SPDK封装的一个服务，用于后端Mayastor存储，对外提供NVMe target访问。

2.2. 方案描述

本方案主要由ycloud-csi、RDMA Gateway和Mayastor后端存储三个部分组成，下面将对这三个部分进行介绍。

2.2.1.ycloud-csi

通过ycloud-csi架构可以接入第三方的存储，让第三方存储很方便的使用DPU的能力。其包括ycloud-csi-controller、ycloud-csi-node-host和ycloud-csi-node-dpu，主要职责是为K8s的负载提供不同的存储能力。

2.2.1.1.Ycloud-csi-controller

Ycloud-csi-controller主要实现以下两类功能：

针对pvc，调用第三方的controller，创建卷，创建快照和扩容等；

针对pod，提供存储的两种连接模式：AIO和NVMe-oF（因为opi目前只支持这两种）。如果是NVMe-oF，则调用不同的plugin在GATEWAY上创建NVMe-oF target。

2.2.1.2.Ycloud-csi-node

Ycloud-csi-node使用插件系统，对接不同的第三方存储。 ycloud-csi-node按node角色分为ycloud-csi-node-dpu、ycloud-csi-node-host和ycloud-csi-node-default，不同角色的csi-node功能不同，下面分别加以说明：

Ycoud-csi-node-dpu需要处理host和DPU侧的挂盘请求，根据不同的连接模式(AIO或者NVMe-oF)，连接远程存储。

Ycloud-csi-node-host把DPU侧导出的volume挂载到pod中。

Ycloud-csi-node-default 也就是默认的工作模式，工作于smartNic场景。完成挂载volume，导入pod中。

2.2.2.RDMA Gateway

RDMA Gateway是基于SPDK开发的存储服务，可以部署在io-engine相同的节点上，负责连接本地Mayastor的target，对外提供NVMe oF存储服务。

2.2.3. Mayastor storage

后端存储采用Mayastor，管理不同节点上的硬盘存储。

2.3. 工作流程

2.3.1.存储卷创建流程

用户的App运行在POD中。为了能存放持久的数据，需要给POD挂载存储卷。在启动POD之前，可以先创建好PVC，以供后面使用。创建PVC的过程如下：

图中除了包含上一章节介绍的组件外，还有两个k8s系统提供的用于方便对接csi的组件：

external-provisioner：用户创建pvc时，该sidecar 会调用csi-controller的CreateVolume创建存储并创建pv与之前的pvc绑定。

Pv-controller：当底层存储准备好存储空间后，该sidecar会更新PVC的状态为bound。

2.3.2.存储卷挂载流程

在POD的描述yaml文件里，会指定使用的存储卷PVC。创建POD后，K8s的调度器会选择一个合适的节点来启动POD，然后attacher会把PVC连接到指定节点上，csi-node会把存储卷挂载到POD中。

图中包含两个k8s系统提供的用于对接csi的组件：

external-attacher：会 watch VolumeAttachment 对象。根据 .spec.attacher 判断是不是需要自己处理，如果是则调用ControllerPublishVolume 方法，将.spec.persistentVolumeName 这个 Volume attach 到 .spec.nodeName 这个节点上。

AD controller： 会 watch Pod 对象，利用Pod 的 Volume 列表计算出 该 Node 上的 PV 列表，然后和 node.Status.VolumesAttached 值进行对比，没有attach 的话就执行 attach 操作。

3. 方案测试结果

3.1. Pod挂盘

通过相应的 yaml 描述文件，可以完成创建PVC，删除PVC，创建/删除snapshot，在POD中挂载PVC，并验证操作成功。经验证可知，Mayastor原生支持的操作，在添加Gateway之后，仍可以支持。

操作截图如下：

运行kubectl describe pod snap-mayagate-1命令查看pod，结果如下：

可以连进pod进行简单的写操作测试：

3.2. 性能对比

本方案基于单节点Mayastor创建单副本存储池，在以下测试场景与传统Mayastor方案进行对比：

io-engine threads：设置io-engine的线程个数为2，4，6，8，分别测试；

Transport：Mayastor采用NVMe over TCP，Gateway采用NVMe over RDMA；

IO方式：随机读，随机写，顺序读，顺序写，30%写的混合读写；

不同的测试采样位置：

在Gateway/io-engine本地，目标是使用本地连接提供测试基准数据

在host通过nvme-cli的connect创建盘符来访问，这是host侧采用smartNic的场景

在host通过DPU直通来访问存储，是我们主要关注的测试case

考虑多个性能指标：测试的性能指标包括iops，吞吐，延迟和host cpu消耗。

(1) 随机写延迟分析

随机写延迟的测试结果，如下图所示：

对比TCP和RDMA在不同地方的采样，可知，io-engine所在节点本地访问延迟较小，在另外一个节点访问，TCP延迟增加了一个数量级，而RDMA延迟增加较小。

（2）顺序写带宽分析

顺序写带宽的测试结果，如下图所示：

通过在本地直接对于NVMe SSD硬盘测试，发现SSD可支持带宽大约2680MiB/s左右。从表中可以看到，使用nvme cli连接，无论是TCP还是RDMA，都可以接近后端存储支持的最大带宽。单独看DPU直通的数据，RDMA的性能远远超过TCP的性能。这是因为TCP由软件栈处理，需要消耗大量CPU资源，DPU内仅有4core，CPU资源不足造成的。

(3) 随机写IOPS分析

随机写IOPS的测试结果，如下图所示：

可以看到：

1.RDMA的io-engine本地和host nvme-cli两个测试位置曲线接近，说明RDMA是完全卸载到硬件处理，性能好；

2. TCP的两种方式性能有差别，特别是TCP DPU直通方式的上限是200kiops，说明瓶颈是在DPU的CPU上。

另外把Host cli访问的数据单独拿出来，用这两行单独作图，如下：

可以看到，当io-engine thread个数为4时，RDMA Gateway已经基本可以压满后端存储；再增加threads个数影响不大。但TCP直连时，性能还是会随着threads增加而增大。这说明RDMA在相对较低的资源条件下就可以达到较高的性能，其加速效果较好。

（4）随机读IOPS分析

随机读IOPS的测试结果，如下图所示：

可以看到TCP DPU直通方式随机读的上限是150kiops，说明瓶颈是在DPU的CPU上。

另外把Host cli访问的数据单独拿出来，用这两行单独作图，如下：

可以看到，当io-engine thread个数为2时，Mayastor TCP方式与RDMA Gateway相差不大，说明瓶颈在于存储后端；当io-engine thread个数大于等于4时，RDMA Gateway的性能要比TCP方式大约提高20%左右。

对于30%写的混合读写方式，由于读操作占主体，跟上面读操作的结果类似，在Host cli情形下，RDMA Gateway的性能要比TCP方式大约提高20%左右。

(5) Host侧CPU使用分析

在fio测试过程中，通过脚本记录Host上top命令的输出信息，获取CPU的使用信息。

下图是用Host cli连接时使用CPU的截图记录， TCP协议与RDMA协议的对比。（测试中Mayastor io-engine 采用8 core。）

测试命令是：

fio -direct=1 -iodepth=64 -rw=randwrite -ioengine=libaio -size=100G -bs=4k -numjobs=16 -runtime=300 -group_reporting -filename=/dev/filename -name=Rand_Write_Testing

依次对于三个不同的挂接设备进行测试：/dev/nvme2n1是Host侧TCP cli；/dev/nvme3n1是Host侧RDMA cli；/dev/nvme0n26是DPU侧RDMA直通。

在3个挂载盘上分别做fio测试的IOPS结果分别是：655k，684k，646k。可以看到测试出的性能结果相差不大。上图是测试过程中通过脚本记录的CPU使用情况。可以看到，相对于TCP，使用RDMA协议可以节省大量的CPU。

4. 方案优势总结

1、显著提升性能：

通过前面测试数据可以看到，在DPU直通连入的场景下，本方案比原生的Mayastor方案随机写IOPS性能提升40%左右，随机读IOPS性能提升20%左右。在DPU直通的场景下，TCP方式延约200毫秒，RDMA方式约80毫秒，本方案可以减少60%左右的时延。这是因为本方案充分利用了RDMA的超低延迟和高性能特性。RDMA的零拷贝和绕过CPU的传输方式极大地减少数据传输过程中的延迟和CPU消耗，使Mayastor能够更高效地处理NVMe SSD的读写请求。

2、优化资源利用：

通过前面测试数据可以看到，采用RDMA的方式连接后端存储，相对于TCP方式可以节省50%左右的Host cpu。本方案通过NVMe over RDMA减少Mayastor对CPU和内存的占用，使系统资源能够更多地用于其他计算任务，这有助于提升Mayastor的整体稳定性和可靠性，同时降低运营成本。

3、增强可扩展性和灵活性：

RDMA技术还提供了更好的可扩展性和灵活性。随着数据中心规模的扩大和存储需求的增长，Mayastor可以通过支持NVMe over RDMA来更轻松地应对这些挑战。RDMA的远程直接内存访问特性使得跨节点的数据传输更加高效和可靠，有助于构建更强大的分布式存储系统。

4、支持更多应用场景：

有了NVMe over RDMA的支持，Mayastor将能够更好地满足那些对性能有极高要求的应用场景。无论是高频交易、实时数据分析还是大规模数据库事务处理，Mayastor都将能够提供更加稳定和高效的数据存储服务。

综上所述，从Mayastor影响的角度来看，NVMe over RDMA技术相较于TCP在性能、延迟和资源消耗方面均展现出显著优势。对于追求极致性能的数据中心和应用场景来说，Mayastor未来能够支持NVMe over RDMA将是一个重要的里程碑，有助于进一步提升其市场竞争力和用户体验。

本方案来自于中科驭数软件研发团队，团队核心由一群在云计算、数据中心架构、高性能计算领域深耕多年的业界资深架构师和技术专家组成，不仅拥有丰富的实战经验，还对行业趋势具备敏锐的洞察力，该团队致力于探索、设计、开发、推广可落地的高性能云计算解决方案，帮助最终客户加速数字化转型，提升业务效能，同时降低运营成本。

审核编辑 黄宇