1. 计划后台和挑衅
Ceph是一个高度可扩大、高性能的，设想用于供应优异的工具存储、块存储和文件存储办事。它的几个焦点特点是：
- 弹性扩大：Ceph可以或许无缝地程度扩大存储容量和功能，只要增添新的存储节点即可，无需从新设置现有体系，异常适宜云环境的静态需要；
- 自我修复：经由过程正本或擦除编码手艺，Ceph可以或许主动检测并修复数据毁坏或失落，保障数据的高可用性和持久性；
- 对立接口：Ceph供应RADOS GW（工具存储网关）、RBD（块设置装备摆设映照）和CephFS（文件体系）三种接口，餍足分歧存储需要，且这些接口能够同时在一个集群中应用。
在Kubernetes（K8s）架构下，Ceph能够作为一个壮大的存储后端，为容器化的使用供应速决化存储解决计划。Kubernetes经由过程存储卷插件与内部存储体系集成，Ceph恰是经由过程如许的插件（如RBD插件）与K8s集成，完成存储资本的静态调配和治理。
架构如下图所示：
在传统体式格局下应用Ceph作为存储解决计划，会遇到一些局限性和挑衅，尤其是在与当代云原生环境如Kubernetes集成时，这些题目可能会加倍凸起，具体表现为如下几个方面：
- RBD客户端运转于Host，损耗计较资本：传统安排模式下，Ceph的RBD（RADOS Block Device）客户端运行在宿主机（Host）层面，而非直接在容器外部。这意味着所有与Ceph交互的计较使命，包孕I/O要求处置、谬误复原等，都需求宿主机的资本来实现。在高负载情况下，这些额定的计较需要大概会对宿主机的资本调配发生压力，影响到运行在沟通宿主机上的其余容器使用的功能。
- 应用RBD和谈连贯后端存储，功能受限：RBD和谈尽管成熟且稳固，但在某些场景下，其功能体现大概不尽人意，尤其是在需求少量小I/O操纵或高带宽传输的情况下。这是由于RBD和谈在设想上更多思量了数据的可靠性和一致性，而非极致的功能。这致使耽误较高，影响到依附倏地存储呼应的使用功能，如办事或处置体系。
- 在Kubernetes架构下，无奈间接应用DPU完成卸载和加快：跟着DPU（Data Processing Unit）等加快手艺的鼓起，其在数据处置、网络和存储使命中的加快才能备受注视。然而，在传统的Ceph与Kubernetes集成计划中，不足间接应用DPU卸载存储相干处置的才能，致使无奈充沛应用DPU供应的硬件加快上风，限定了存储功能的进一步晋升和资本的高效应用。
鉴于以上挑衅，索求和实行针对Kubernetes环境优化的Ceph安排计划，如经由过程特地的Ceph CSI（Container Storage Interface）插件支撑DPU卸载，或是应用Ceph的其余高等功能与当代硬件加快手艺慎密连系，成为了晋升云原生使用存储功能和服从的关头偏向。
2. 计划先容
2.1. 团体架构
本方案接纳云原生架构，引入DPU作为Kubernetes集群的Node，为集群之上的容器、虚机和裸金属实例供应存储办事的卸载和加快。团体架构以下所示：
本方案将K8s node分为分歧的脚色（node-role），分歧的组件分手安排在分歧的node，首要包括：
- Master Node上，安排csi的csi-controller，用于建立volume和NVMe-oF target；
- Host Node上，安排csi-node-host，合营csi-node-dpu，经由过程volumeattachment发明DPU挂载的NVMe盘，而后施行绑定或许格式化；裸机场景没有这个组件；
- DPU上，安排csi-node-dpu，volume-attacher和opi-bridge。opi-bridge是卡对opi-api存储的完成，volume-attacher是对DPU存储相干要领的；csi-node-dpu 挪用volume-attacher给host挂盘；
- Storage上，安排Ceph和，GATEWAY是对SPDK封装的一个办事，用于当地连贯rbd image，裸露成NVMe-oF target。
2.2. 计划描绘
本方案主要由csi-framework、opi-framework和storage三个部份构成，上面将对这三个部份举行先容。
2.2.1. csi-framework
经由过程csi-framework咱们能倏地的接入第三方的存储，让第三方存储很便利的应用DPU的才能。其包孕csi-controller、csi-node-host和csi-node-dpu，首要职责是为K8s的负载供应分歧的存储才能。
2.2.1.1. csi-controller
Csi-controller以deployment的方式安排在master节点，其架构如下图所示：
在csi-controller pod中，包括对接存储的csi-controller容器，首要用于在对接存储上建立卷，除此以外，为了让对接存储也能用nvmeof的体式格局，本架构也开发了对应的插件体系，由插件担任NVMe-oF target的治理。
连系K8s csi的external plugin，csi-controller首要完成如下两类性能：
- 针对pvc，挪用第三方的controller，建立卷，建立快照和扩容等;
- 针对pod（本质上volumeattachment，简称va），两种连贯模式，O和NVMe-oF（由于opi今朝只支撑这两种）。如果是NVMe-oF，则挪用分歧的plugin在GATEWAY上建立NVMe-oF target；相干的target参数会速决化到va的status，此时va的状况变成attached=true。
2.2.1.2. csi-node
Csi-node以daemonset的方式，安排在所有节点，其架构如下图所示：
在csi-node的架构中，没有整合第三方的csi-node，是因为第三方csi-node往往是针对非DPU的场景，所以在本框架中，也是应用插件体系，对接分歧的第三方存储。插件体系首要用于直连存储比方经由过程RBD或许ISCSI，会在当地天生一个设置装备摆设最初把这个设置装备摆设再以AIO体式格局挂载到上；如果是应用本框架的NVMe-oF体式格局，由csi-node-dpu担任从va猎取对应连贯信息连贯NVMe-oF target。
Csi-node按node脚色分为csi-node-dpu、csi-node-host和csi-node-default分歧脚色的csi-node性能分歧上面分手加以解释：
- csi-node-dpu需求处置host和DPU要求，待csi-node-dpu依据分歧连贯模式(AIO或许NVMe-oF连贯长途存储；在pf或许vf上挂载磁盘后，会把挂盘的信息添加到va的annotation；
- csi-node-host就可以依据va的annotation找到挂载的disk举行下一步操纵；
- csi-node-default便是默许事情模式，同非DPU场景的csi-node事情体式格局。
2.2.2. opi-framework
Opi-framewark包孕volume-attacher、opi-yusur-bridge、opi-nvidia-bridge和SPDK供应存储卸载加快才能。
- volume-attacher是bridge之上的一层封装，其主要感化有三个：
- 参数计较比方挂载谁人vf应用谁人nsid等；同时保障沟通的盘，挂载到沟通的挂载点；
- 从上咱们晓得，opi框架供应才能无限比方backend支撑AIO和NVMe-oF；一旦应用其余的bdev比方lvol，此时无法经由过程opi-bridge操纵以是volume-attacher还封装了对底层SPDK操纵。
- opi-bridge是对opi规范完成分歧的卡会有分歧的bridge，存储方面首要包孕对接SPDK的三类接口（frontendmiddleendbackend）。
- SPDK办事，除了原生SPDK性能首要作用是在pf或许vf上挂载bdev。
2.2.3. storage
除了第三方或许开源的存储体系以外供应一个GATEWAY，GATEWAY才能就是在接近存储处所以是每每和存储体系安排在一起经由过程NVMe-oF target要领裸露进来；同时支撑NVMe-oF multipath完成高可用。
3.计划测试效果
3.1. Pod挂盘
##pvc-xxx.yaml关头参数storageClassName: class-ceph经由过程分歧的storageclass应用AIO或许nvmeof体式格局
- HOST应用nvme list和nvme list-subsys检察对应的disk和system，如下图所示：
- DPU应用rpc.py检察对应的bdev，nvme_ns, nvme_ctrl
- GATEWAY应用rpc.py检察nvme_subsystem，bdev
3.2.功能比照
本方案基于单节点ceph建立正本存储如下测试场景与传统ceph计划举行比照：
- AIO：DPU经由过程RBD和谈连贯存储而后把/dev/rbd0经由过程AIO给到Host；
- Host-RBD：测试节点上用RBD和谈连贯存储，也是传统ceph计划体式格局；
- LOCAL-RBD：存储节点上用RBD和谈连贯存储，用于比照Host-RBD；
- Host-NVMe-CLI/：测试节点经由过程NVMe-CLI以NVMe/TCP体式格局连贯存储上的GATEWAY，用来比照卸载模式功能；
- Host-NVMe-CLI/R：测试节点经由过程NVMe-CLI以NVMe/RDMA体式格局连贯存储上的GATEWAY，用来比照卸载模式功能；
- NVMe/TCP：DPU间接TCP和谈连贯GATEWAY，是本方案的一种连贯体式格局；
- NVMe/RDMA：DPU间接经由过程RDMA和谈连贯GATEWAY，是本方案的一种连贯体式格局。
测试分歧blocksize下的随机读写目标包孕iops，吞吐耽误和Host CPU损耗。
3.2.1. 存储IOPS
测试效果以下：
从上图咱们能够得出如下论断：
- AIO功能最差，是因为AIO经由过程DPU内里librbd连贯存储，受限于DPU资本；
- LOCAL-RBD功能较Host-RBD低，是因为当地测试时，内核RBD模块与osd存在资本合作致使ceph-osd的CPU上不去，在950摆布，但是在Host-RBD测试时ceph-osd的CPU在1050摆布；
- NVMe/TCP功能较Host-NVMe-CLI/TCP和Host-NVMe-CLI/RDMA稍高，是因为二者门路不一样多是DPU的SPDK办事带来加快结果；
- NVMe/RDMA与NVMe/TCP基础持平，是因为瓶颈在ceph，这个会基于裸盘给出论断
- NVMe/RDMA，NVMe/TCP，Host-NVMe-CLI/TCP和Host-NVMe-CLI/RDMA，高于Host-RBD，是因为GATEWAY加快感化，能把ceph-osd的CPU进一步提高到1150摆布。
随机读iops如下图所示：
如上图所示能够得出以下论断：
- NVMe/TCP的性能与Host-NVMe-CLI/TCP基础持平好过Host-RBD；
- NVMe/RDMA功能较NVMe/TCP的稍低多是在随机读场景下RDMA和谈消耗致使。
3.2.2. 存储耽误
测试效果以下：
如上图所示能够得出以下论断：
- RDMA耽误好过TCP；
- HOST-RBD好过其余当地场景，是因为团体io门路其余的短。
随机读场景耽误以下所示：
3.2.3. CPU损耗
测试效果以下：
如上图所示能够得出以下论断：
- 基于传统的Ceph解决计划损耗Host CPU在400%-600%之间资本损耗在内核模块RBD；
- 基于DPU的ceph解决计划，NVMe/TCP和NVMe/RDMA的Host CPU损耗很低。
随机读场景资本损耗以下所示：
4. 总结
4.1.计划上风
基于DPU（Data Processing Unit）的Ceph存储解决计划，为云原生存储畛域带来了显著资本优化，在性能上也有必定改良详细上风体现在如下几个方面：
1.资本服从大幅晋升：
2.功能坚持与优化：在对阐发中，基于DPU的Ceph解决计划不但坚持了与传统Ceph安排在性能上的竞争力并且还展示了显著晋升后劲经由过程比照应用Host-NVMe-CLI分手经由过程TCP和RDMA和谈）、NVMe/TCP和NVMe/RDMA的传统Ceph功能数据发明基于DPU计划并未下降原有的Ceph功能体现，反而在某些目标上有所加强。特别是间接比照基于Host的RBD造访、NVMe/TCP和NVMe/RDMA功能时，DPU计划揭示出了逾越这些传统造访体式格局功能晋升，这表明DPU不但无效卸载了存储处置使命经由过程其硬件加快特点提升了存储功能。
3.弥补Kubernetes生态空缺：在Kubernetes（K8s）生态体系中，虽然有多种存储解决计划和插件以前不足针对DPU优化的存储卸载加快办事。这一自研的基于DPU的Ceph解决计划，填补了这一手艺空缺，为Kubernetes环境使用供应了更高效耽误的存储支撑经由过程集成DPU加快才能不但增强了云原生使用的存储功能，还为用户供应了更多抉择和优化存储设置的灵活性，有助于晋升全部运转服从本钱效益。
综上所述，基于DPU的Ceph存储解决计划经由过程自研的Kubernetes组件、引入DPU深度优化存储处置流程，显著降低了宿主机资本损耗坚持以至提升了存储功能，同时为Kubernetes生态引入了立异的存储加快办事，是面向将来云原生架构首要手艺前进。
本方案来自于中科驭数研发团队，团队焦点由一群在、架构、高性能计较畛域深耕多年的业界资深架构师手艺专家构成不但领有厚实的实战教训，还对行业趋向具有灵敏的洞察力，该团队致力于索求设想开辟推行可落地的高性能计较解决计划赞助终究客户加快晋升营业效力，同时下降运营本钱。
##pvc-xxx.yaml关头参数storageClassName: class-ceph经由过程分歧的storageclass应用AIO或许nvmeof体式格局
- GATEWAY应用rpc.py检察nvme_subsystem，bdev
- AIO：DPU经由过程RBD和谈连贯存储而后把/dev/rbd0经由过程AIO给到Host；
- Host-RBD：测试节点上用RBD和谈连贯存储，也是传统ceph计划体式格局；
- LOCAL-RBD：存储节点上用RBD和谈连贯存储，用于比照Host-RBD；
- Host-NVMe-CLI/：测试节点经由过程NVMe-CLI以NVMe/TCP体式格局连贯存储上的GATEWAY，用来比照卸载模式功能；
- Host-NVMe-CLI/R：测试节点经由过程NVMe-CLI以NVMe/RDMA体式格局连贯存储上的GATEWAY，用来比照卸载模式功能；
- NVMe/TCP：DPU间接TCP和谈连贯GATEWAY，是本方案的一种连贯体式格局；
- NVMe/RDMA：DPU间接经由过程RDMA和谈连贯GATEWAY，是本方案的一种连贯体式格局。
- AIO功能最差，是因为AIO经由过程DPU内里librbd连贯存储，受限于DPU资本；
- LOCAL-RBD功能较Host-RBD低，是因为当地测试时，内核RBD模块与osd存在资本合作致使ceph-osd的CPU上不去，在950摆布，但是在Host-RBD测试时ceph-osd的CPU在1050摆布；
- NVMe/TCP功能较Host-NVMe-CLI/TCP和Host-NVMe-CLI/RDMA稍高，是因为二者门路不一样多是DPU的SPDK办事带来加快结果；
- NVMe/RDMA与NVMe/TCP基础持平，是因为瓶颈在ceph，这个会基于裸盘给出论断
- NVMe/RDMA，NVMe/TCP，Host-NVMe-CLI/TCP和Host-NVMe-CLI/RDMA，高于Host-RBD，是因为GATEWAY加快感化，能把ceph-osd的CPU进一步提高到1150摆布。
- NVMe/TCP的性能与Host-NVMe-CLI/TCP基础持平好过Host-RBD；
- NVMe/RDMA功能较NVMe/TCP的稍低多是在随机读场景下RDMA和谈消耗致使。
- RDMA耽误好过TCP；
- HOST-RBD好过其余当地场景，是因为团体io门路其余的短。
- 基于传统的Ceph解决计划损耗Host CPU在400%-600%之间资本损耗在内核模块RBD；
- 基于DPU的ceph解决计划，NVMe/TCP和NVMe/RDMA的Host CPU损耗很低。
3.2.功能比照
本方案基于单节点ceph建立正本存储如下测试场景与传统ceph计划举行比照：
测试分歧blocksize下的随机读写目标包孕iops，吞吐耽误和Host CPU损耗。
3.2.1. 存储IOPS
测试效果以下：
从上图咱们能够得出如下论断：
随机读iops如下图所示：
如上图所示能够得出以下论断：
3.2.2. 存储耽误
测试效果以下：
如上图所示能够得出以下论断：
随机读场景耽误以下所示：
3.2.3. CPU损耗
测试效果以下：
如上图所示能够得出以下论断：
随机读场景资本损耗以下所示：
4. 总结
4.1.计划上风
基于DPU（Data Processing Unit）的Ceph存储解决计划，为云原生存储畛域带来了显著资本优化，在性能上也有必定改良详细上风体现在如下几个方面：
1.资本服从大幅晋升：
2.功能坚持与优化：在对阐发中，基于DPU的Ceph解决计划不但坚持了与传统Ceph安排在性能上的竞争力并且还展示了显著晋升后劲经由过程比照应用Host-NVMe-CLI分手经由过程TCP和RDMA和谈）、NVMe/TCP和NVMe/RDMA的传统Ceph功能数据发明基于DPU计划并未下降原有的Ceph功能体现，反而在某些目标上有所加强。特别是间接比照基于Host的RBD造访、NVMe/TCP和NVMe/RDMA功能时，DPU计划揭示出了逾越这些传统造访体式格局功能晋升，这表明DPU不但无效卸载了存储处置使命经由过程其硬件加快特点提升了存储功能。
3.弥补Kubernetes生态空缺：在Kubernetes（K8s）生态体系中，虽然有多种存储解决计划和插件以前不足针对DPU优化的存储卸载加快办事。这一自研的基于DPU的Ceph解决计划，填补了这一手艺空缺，为Kubernetes环境使用供应了更高效耽误的存储支撑经由过程集成DPU加快才能不但增强了云原生使用的存储功能，还为用户供应了更多抉择和优化存储设置的灵活性，有助于晋升全部运转服从本钱效益。
综上所述，基于DPU的Ceph存储解决计划经由过程自研的Kubernetes组件、引入DPU深度优化存储处置流程，显著降低了宿主机资本损耗坚持以至提升了存储功能，同时为Kubernetes生态引入了立异的存储加快办事，是面向将来云原生架构首要手艺前进。
本方案来自于中科驭数研发团队，团队焦点由一群在、架构、高性能计较畛域深耕多年的业界资深架构师手艺专家构成不但领有厚实的实战教训，还对行业趋向具有灵敏的洞察力，该团队致力于索求设想开辟推行可落地的高性能计较解决计划赞助终究客户加快晋升营业效力，同时下降运营本钱。
