标签: RDMA

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

前言 预测2022年服务器技术的趋势，IT 架构师可以在哪里进行设计，以及新的解决方案将如何应对最新的挑战。其实，当快速变化的世界带来的技术需求与系统设计人员目前可用的资源碰撞时，一幅关于2022年可能发生什么的清晰图景就会慢慢浮出水面。 一、预测 一个简单的预测是，未来将会继续强调提高架构交付数据能力的速度和性能。各种形式的数据规模都在增长：元数据、媒体文件、游戏和虚拟环境资产、交易数据，这些数据使用的越快，其价值就越大。虽然目前还没有新的、更快的存储介质，但新的、更有效传输数据的方法已经开始生根发芽了。 由于市场上新兴技术的出现，现在对于存储和网络连接来说是一个令人兴奋的时刻。NVMe、RDMA、PCIe 4.0和Gen7光纤通道（Fibre Channel）都为制造商和渠道合作伙伴之间的探索和机遇开辟了许多新的途径，我们会在2022年看到这些。 二、NVMe和PCIe 4.0 “2021年，NVMe在企业环境中的部署获得了动力，我完全可以预计这一趋势将在2022年继续下去。”制造商如何开发与NVMe的局限性合作（或绕过NVMe局限性）的方法，将是推动NVMe应用的动力源泉。 我们知道，企业采用NVMe的两个主要障碍是可扩展性和管理，我看到在新的一年出现的产品可以解决这两个问题。首先，新的解决方案将允许基础设施团队直接从服务器上扩展NVMe存储。其次，还有一些解决方案，使这些团队能够为本地和分布式存储网络建立高性能的NVMe存储阵列，其管理能力与SAS或光纤通道设备相同。PCIe 4.0也将在NVMe的应用中扮演着重要的角色，而且随着硬件可用性越来越高，NVMe的采用速度会迅速加快。假设产品可用性提高，成本下降，那么NVMe存储将进一步成为大多数企业应用程序的存储标准。 三、光纤通道 2022年，光纤通道的光芒将更加耀眼。2021年的一个鲜为人知的故事是，天平又开始倾向于这项强大的技术。这有多种原因，其中大部分是基于光纤通道在可靠性、稳定性和确定性能方面得来的声誉。 “然而，光纤通道也是相当灵活的，我希望在2022年看到 "FC "和 "NVMe "这两个首字母缩写词结合得更加频繁。” 事实上，由于系统构建者正在寻找从网络NVMe存储中获得最大收益的最佳方式，NVMeOFC（NVMe over Fibre Channel）已经悄然成为NVMeOF（NVMe over Fabrics）的一个强有力的替代品。戴尔最近在其大部分存储产品中增加了对NVMeOFC的支持，NetApp也已经有了。看到更多的供应商探索这种无可否认的强大联合也就不足为奇了。 四、以太网和RDMA 在以太网方面，我们将继续关注有助于提高性能的卸载技术，特别是基于远程直接内存访问（RDMA）的卸载技术。由于具有RDMA功能的以太网适配器（又称智能网卡）在市场上已经存在了一段时间，已经为扩大RDMA的使用奠定了基础。 虹科以太网智能网卡仅以适配器的成本增加了RDMA功能，内置硬件卸载引擎，积极响应市场需求。 “因此，我希望看到基于RDMA的协议，如RoCE（RDMA over Converged Ethernet）继续成为主流，而像NFSoRDMA（Network File System over RDMA）这样的解决方案可以从实验室中出来，激发更大的市场兴趣。Nvidia和VAST Data可能是该协议最值得关注的传播者，然而Linux社区已经用了好几年了。” 五、总结 当然，我们应该总是期待惊喜。你永远不知道会有什么新技术、驱动调整或迄今未公布的性能指标影响系统构建者的设计方向。 "这里没有什么内幕消息，只是委婉的提醒一下，在技术领域，12个月是很长的时间！" 持续更新网络和存储连接产品信息、解决方案、行业动态、技术干货等。我们连接的协议有光纤通道（FC）、以太网、SAS/SATA和Thunderbolt——每种协议都有不同的速度和不同的端口配置，保证极其稳定、平滑的数据流，满足您的企业级需求。 更多应用方案请关注公众号：虹科网络基础设施 更多产品信息可访问：https://hojichu.com