1. 方案背景和挑戰(zhàn)

Ceph是一個(gè)高度可擴(kuò)展、高性能的開(kāi)源分布式存儲(chǔ)系統(tǒng)，設(shè)計(jì)用于提供優(yōu)秀的對(duì)象存儲(chǔ)、塊存儲(chǔ)和文件存儲(chǔ)服務(wù)。它的幾個(gè)核心特點(diǎn)是：

彈性擴(kuò)展：Ceph能夠無(wú)縫地水平擴(kuò)展存儲(chǔ)容量和性能，只需添加新的存儲(chǔ)節(jié)點(diǎn)即可，無(wú)需重新配置現(xiàn)有系統(tǒng)，非常適合云環(huán)境的動(dòng)態(tài)需求；

自我修復(fù)：通過(guò)副本或糾刪碼技術(shù)，Ceph能夠自動(dòng)檢測(cè)并修復(fù)數(shù)據(jù)損壞或丟失，保證數(shù)據(jù)的高可用性和持久性；

統(tǒng)一接口：Ceph提供RADOS GW（對(duì)象存儲(chǔ)網(wǎng)關(guān)）、RBD（塊設(shè)備映射）和CephFS（文件系統(tǒng)）三種接口，滿足不同存儲(chǔ)需求，且這些接口可以同時(shí)在一個(gè)集群中使用。

在Kubernetes（K8s）架構(gòu)下，Ceph可以作為一個(gè)強(qiáng)大的存儲(chǔ)后端，為容器化的應(yīng)用提供持久化存儲(chǔ)解決方案。Kubernetes通過(guò)存儲(chǔ)卷插件與外部存儲(chǔ)系統(tǒng)集成，Ceph正是通過(guò)這樣的插件（如RBD插件）與K8s集成，實(shí)現(xiàn)存儲(chǔ)資源的動(dòng)態(tài)分配和管理。
架構(gòu)如下圖所示：

在傳統(tǒng)方式下使用Ceph作為存儲(chǔ)解決方案，會(huì)遇到一些局限性和挑戰(zhàn)，尤其是在與現(xiàn)代云原生環(huán)境如Kubernetes集成時(shí)，這些問(wèn)題可能會(huì)更加突出，具體表現(xiàn)為以下幾個(gè)方面：

RBD客戶端運(yùn)行于Host，消耗計(jì)算資源：傳統(tǒng)部署模式下，Ceph的RBD（RADOS Block Device）客戶端運(yùn)行在宿主機(jī)（Host）層面，而非直接在容器內(nèi)部。這意味著所有與Ceph交互的計(jì)算任務(wù)，包括I/O請(qǐng)求處理、錯(cuò)誤恢復(fù)等，都需要宿主機(jī)的CPU資源來(lái)完成。在高負(fù)載情況下，這些額外的計(jì)算需求可能會(huì)對(duì)宿主機(jī)的資源分配產(chǎn)生壓力，影響到運(yùn)行在相同宿主機(jī)上的其他容器應(yīng)用的性能。

使用RBD協(xié)議連接后端存儲(chǔ)，性能受限：RBD協(xié)議雖然成熟且穩(wěn)定，但在某些場(chǎng)景下，其性能表現(xiàn)可能不盡人意，尤其是在需要大量小I/O操作或高帶寬傳輸?shù)那闆r下。這是因?yàn)镽BD協(xié)議在設(shè)計(jì)上更多考慮了數(shù)據(jù)的可靠性和一致性，而非極致的性能。這導(dǎo)致數(shù)據(jù)傳輸延遲較高，影響到依賴快速存儲(chǔ)響應(yīng)的應(yīng)用性能，如數(shù)據(jù)庫(kù)服務(wù)或大數(shù)據(jù)處理系統(tǒng)。

在Kubernetes架構(gòu)下，無(wú)法直接利用DPU實(shí)現(xiàn)卸載和加速：隨著DPU（Data Processing Unit）等硬件加速技術(shù)的興起，其在數(shù)據(jù)處理、網(wǎng)絡(luò)和存儲(chǔ)任務(wù)中的加速能力備受矚目。然而，在傳統(tǒng)的Ceph與Kubernetes集成方案中，缺乏直接利用DPU卸載存儲(chǔ)相關(guān)處理的能力，導(dǎo)致無(wú)法充分利用DPU提供的硬件加速優(yōu)勢(shì)，限制了存儲(chǔ)性能的進(jìn)一步提升和資源的高效利用。

鑒于以上挑戰(zhàn)，探索和實(shí)施針對(duì)Kubernetes環(huán)境優(yōu)化的Ceph部署方案，如通過(guò)專門的Ceph CSI（Container Storage Interface）插件支持DPU卸載，或是利用Ceph的其他高級(jí)功能與現(xiàn)代硬件加速技術(shù)緊密結(jié)合，成為了提升云原生應(yīng)用存儲(chǔ)性能和效率的關(guān)鍵方向。

2. 方案介紹

2.1. 整體架構(gòu)

本方案采用云原生架構(gòu)，引入DPU作為Kubernetes集群的Node，為集群之上的容器、虛機(jī)和裸金屬實(shí)例提供存儲(chǔ)服務(wù)的卸載和加速。整體架構(gòu)如下所示：

本方案將K8s node分為不同的角色（node-role），不同的組件分別部署在不同的node，主要包含：

Master Node上，部署csi的控制器csi-controller，用于創(chuàng)建volume和NVMe-oF target；

Host Node上，部署csi-node-host，配合csi-node-dpu，通過(guò)volumeattachment發(fā)現(xiàn)DPU掛載的NVMe盤，然后執(zhí)行綁定或者格式化；裸機(jī)場(chǎng)景沒(méi)有這個(gè)組件；

DPU上，部署csi-node-dpu，volume-attacher和opi-bridge。opi-bridge是卡對(duì)opi-api存儲(chǔ)的實(shí)現(xiàn)，volume-attacher是對(duì)DPU存儲(chǔ)相關(guān)方法的封裝；csi-node-dpu 調(diào)用volume-attacher給host掛盤；

Storage上，部署Ceph和GATEWAY，GATEWAY是對(duì)SPDK封裝的一個(gè)服務(wù)，用于本地連接rbd image，暴露成NVMe-oF target。

2.2. 方案描述

本方案主要由csi-framework、opi-framework和storage三個(gè)部分組成，下面將對(duì)這三個(gè)部分進(jìn)行介紹。

2.2.1. csi-framework

通過(guò)csi-framework我們能快速的接入第三方的存儲(chǔ)，讓第三方存儲(chǔ)很方便的使用DPU的能力。其包括csi-controller、csi-node-host和csi-node-dpu，主要職責(zé)是為K8s的負(fù)載提供不同的存儲(chǔ)能力。

2.2.1.1. csi-controller

Csi-controller以deployment的形式部署在master節(jié)點(diǎn)，其架構(gòu)如下圖所示：

在csi-controller pod中，包含對(duì)接存儲(chǔ)的csi-controller容器，主要用于在對(duì)接存儲(chǔ)上創(chuàng)建卷，除此之外，為了讓對(duì)接存儲(chǔ)也能用nvmeof的方式，本架構(gòu)也開(kāi)發(fā)了對(duì)應(yīng)的插件系統(tǒng)，由插件負(fù)責(zé)NVMe-oF target的管理。

結(jié)合K8s csi的external plugin，csi-controller主要實(shí)現(xiàn)以下兩類功能：

針對(duì)pvc，調(diào)用第三方的controller，創(chuàng)建卷，創(chuàng)建快照和擴(kuò)容等;

針對(duì)pod（本質(zhì)上volumeattachment，簡(jiǎn)稱va），兩種連接模式，AIO和NVMe-oF（因?yàn)閛pi目前只支持這兩種）。如果是NVMe-oF，則調(diào)用不同的plugin在GATEWAY上創(chuàng)建NVMe-oF target；相關(guān)的target參數(shù)會(huì)持久化到va的status，此時(shí)va的狀態(tài)變?yōu)閍ttached=true。

2.2.1.2. csi-node

Csi-node以daemonset的形式，部署在所有節(jié)點(diǎn)，其架構(gòu)如下圖所示：

在csi-node的架構(gòu)中，沒(méi)有整合第三方的csi-node，是因?yàn)榈谌絚si-node往往是針對(duì)非DPU的場(chǎng)景，所以在本框架中，也是使用插件系統(tǒng)，對(duì)接不同的第三方存儲(chǔ)。插件系統(tǒng)主要用于直連存儲(chǔ)，比如通過(guò)RBD或者ISCSI，會(huì)在本地生成一個(gè)塊設(shè)備，最后把這個(gè)塊設(shè)備再以AIO的方式掛載到PCIE上；如果是使用本框架的NVMe-oF的方式，由csi-node-dpu負(fù)責(zé)從va獲取對(duì)應(yīng)的連接信息，連接NVMe-oF target。

Csi-node按node角色分為csi-node-dpu、csi-node-host和csi-node-default，不同角色的csi-node功能不同，下面分別加以說(shuō)明：

csi-node-dpu需要處理host和DPU側(cè)的掛盤請(qǐng)求，待csi-node-dpu根據(jù)不同的連接模式(AIO或者NVMe-oF)，連接遠(yuǎn)程存儲(chǔ)；在pf或者vf上掛載磁盤后，會(huì)把掛盤的信息添加到va的annotation；

csi-node-host就能根據(jù)va的annotation找到掛載的disk，進(jìn)行下一步操作；

csi-node-default 也就是默認(rèn)的工作模式，同非DPU場(chǎng)景的csi-node工作方式。

2.2.2. opi-framework

主要用來(lái)兼容不同卡的功能，對(duì)上提供統(tǒng)一的接口；通過(guò)opi-framework，我們能將第三方存儲(chǔ)快速對(duì)接到其他DPU。不同DPU通過(guò)opi-bridge對(duì)接到opi框架，再由volume-attacher提供opi框架沒(méi)有的功能，其架構(gòu)如下圖所示：

Opi-framewark包括volume-attacher、opi-yusur-bridge、opi-nvidia-bridge和SPDK，提供存儲(chǔ)卸載和加速能力。

volume-attacher是bridge之上的一層封裝，其主要作用有三個(gè)：

參數(shù)計(jì)算，比如掛載那個(gè)vf，使用那個(gè)nsid等；同時(shí)保證相同的盤，掛載到相同的掛載點(diǎn)；

因?yàn)閛pi-bridge和SPDK都沒(méi)有數(shù)據(jù)持久化，所以一旦opi-bridge或者SPDK重啟之后，需要volume-attacher進(jìn)行數(shù)據(jù)恢復(fù)

從上我們知道，opi框架提供的能力有限，比如backend，只支持AIO和NVMe-oF；一旦要使用其他的bdev，比如lvol，此時(shí)就沒(méi)法通過(guò)opi-bridge操作，所以volume-attacher還封裝了對(duì)底層SPDK的操作。

opi-bridge是對(duì)opi標(biāo)準(zhǔn)的實(shí)現(xiàn)，不同的卡會(huì)有不同的bridge，存儲(chǔ)方面主要包括對(duì)接SPDK的三類接口（frontendmiddleendbackend）。

SPDK是卡上的服務(wù)，除了原生SPDK的功能外，主要作用是在pf或者vf上掛載bdev。

2.2.3. storage

除了第三方或者開(kāi)源的存儲(chǔ)系統(tǒng)之外，還提供一個(gè)GATEWAY，GATEWAY的能力就是在靠近存儲(chǔ)的地方（所以往往和存儲(chǔ)系統(tǒng)部署在一起），把卷通過(guò)NVMe-oF target的方法是暴露出去；同時(shí)支持NVMe-oF multipath實(shí)現(xiàn)高可用。

3. 方案測(cè)試結(jié)果

3.1. Pod掛盤

首先創(chuàng)建pvc，然后在pod的volumes中以Block或者Filesystem的方式使用pvc，關(guān)鍵參數(shù)如下所示：

##pvc-xxx.yaml 關(guān)鍵參數(shù) storageClassName: class-ceph ## 通過(guò)不同的storageclass，使用AIO或者nvmeof的方式

創(chuàng)建后，相關(guān)資源信息如下：

HOST側(cè)，使用nvme list和nvme list-subsys可查看對(duì)應(yīng)的disk和system，如下圖所示：

DPU側(cè)，使用rpc.py查看對(duì)應(yīng)的bdev，nvme_ns, nvme_ctrl

查看對(duì)應(yīng)的bdev，如下所示：

GATEWAY側(cè)，使用rpc.py查看nvme_subsystem，bdev

查看對(duì)應(yīng)的bdev，如下所示：

3.2. 性能對(duì)比

本方案基于單節(jié)點(diǎn)ceph創(chuàng)建單副本存儲(chǔ)池，在以下測(cè)試場(chǎng)景與傳統(tǒng)ceph方案進(jìn)行對(duì)比：

AIO：DPU上通過(guò)RBD協(xié)議連接存儲(chǔ)，然后把/dev/rbd0通過(guò)AIO給到Host；

Host-RBD：測(cè)試節(jié)點(diǎn)上用RBD 協(xié)議連接存儲(chǔ)，也是傳統(tǒng)ceph方案的方式；

LOCAL-RBD：存儲(chǔ)節(jié)點(diǎn)上用RBD協(xié)議連接存儲(chǔ)，用于對(duì)比Host-RBD；

Host-NVMe-CLI/TCP：測(cè)試節(jié)點(diǎn)上通過(guò)NVMe-CLI以NVMe/TCP的方式連接存儲(chǔ)上的GATEWAY，用來(lái)對(duì)比卸載模式的性能；

Host-NVMe-CLI/RDMA：測(cè)試節(jié)點(diǎn)上通過(guò)NVMe-CLI以NVMe/RDMA方式連接存儲(chǔ)上的GATEWAY，用來(lái)對(duì)比卸載模式的性能；

NVMe/TCP：DPU上直接TCP協(xié)議連接GATEWAY，是本方案的一種連接方式；

NVMe/RDMA：DPU上直接通過(guò)RDMA協(xié)議連接GATEWAY，是本方案的一種連接方式。

測(cè)試不同blocksize下的隨機(jī)讀寫指標(biāo)包括iops，吞吐，延遲和Host CPU消耗。

3.2.1. 存儲(chǔ)IOPS

測(cè)試結(jié)果如下：

從上圖我們可以得出以下結(jié)論：

AIO性能最差，是因?yàn)锳IO是通過(guò)DPU里面librbd連接存儲(chǔ)，受限于DPU的資源；

LOCAL-RBD的性能較Host-RBD低，是因?yàn)楸镜販y(cè)試時(shí)，內(nèi)核RBD模塊與osd存在資源競(jìng)爭(zhēng)，導(dǎo)致ceph-osd的CPU上不去，在950%左右，但是在Host-RBD測(cè)試時(shí)ceph-osd的CPU在1050%左右；

NVMe/TCP的性能較Host-NVMe-CLI/TCP和Host-NVMe-CLI/RDMA稍高，是因?yàn)閮烧叩穆窂讲灰粯樱锌赡苁荄PU的SPDK服務(wù)帶來(lái)的加速效果；

NVMe/RDMA與NVMe/TCP基本持平，是因?yàn)槠款i在ceph，這個(gè)會(huì)基于裸盤給出結(jié)論

NVMe/RDMA，NVMe/TCP，Host-NVMe-CLI/TCP和Host-NVMe-CLI/RDMA，高于Host-RBD，是因?yàn)镚ATEWAY的加速作用，能把ceph-osd的CPU進(jìn)一步提高到1150%左右。

隨機(jī)讀iops如下圖所示：

如上圖所示，可以得出如下結(jié)論：

NVMe/TCP的性能與Host-NVMe-CLI/TCP基本持平，好于Host-RBD；

NVMe/RDMA的性能較NVMe/TCP的稍低，有可能是在隨機(jī)讀場(chǎng)景下RDMA協(xié)議的損耗導(dǎo)致。

3.2.2. 存儲(chǔ)延遲

測(cè)試結(jié)果如下：

如上圖所示，可以得出如下結(jié)論：

RDMA的延遲要好于TCP；

HOST-RBD好于其他非本地場(chǎng)景，是因?yàn)檎wio路徑較其他的短。

隨機(jī)讀場(chǎng)景下的延遲，如下所示：

3.2.3. CPU消耗

測(cè)試結(jié)果如下：

如上圖所示，可以得出如下結(jié)論：

基于傳統(tǒng)的Ceph解決方案，消耗Host CPU在400%-600%之間，其資源消耗在內(nèi)核模塊RBD；

使用Host-NVMe-CLI/TCP的方式，消耗Host CPU在70%-200%之間， 其資源消耗在內(nèi)核模塊NVMe/TCP；

使用Host-NVMe-CLI/RDMA的方式，其資源消耗和卸載模式相當(dāng)；

基于DPU的ceph解決方案，NVMe/TCP和NVMe/RDMA的Host CPU消耗很低。

隨機(jī)讀場(chǎng)景下的資源消耗，如下所示：

4. 總結(jié)

4.1. 方案優(yōu)勢(shì)

基于DPU（Data Processing Unit）的Ceph存儲(chǔ)解決方案，為云原生存儲(chǔ)領(lǐng)域帶來(lái)了顯著的資源優(yōu)化，在性能上也有一定改善，具體優(yōu)勢(shì)體現(xiàn)在以下幾個(gè)方面：

1. 資源效率大幅提升：通過(guò)將Ceph的控制面和數(shù)據(jù)面操作下沉至DPU處理，顯著減輕了宿主機(jī)（Host）的資源消耗。測(cè)試結(jié)果顯示，在并行度為8的場(chǎng)景下，blocksize為4KB時(shí)，宿主機(jī)CPU資源的使用率明顯下降，從502%的消耗，降低到了僅45%，這意味著在實(shí)際應(yīng)用場(chǎng)景中，將大大節(jié)省了寶貴的CPU資源，讓這些資源能夠被應(yīng)用服務(wù)更高效地利用。

2. 性能保持與優(yōu)化：在對(duì)比分析中，基于DPU的Ceph解決方案不僅保持了與傳統(tǒng)Ceph部署在性能上的競(jìng)爭(zhēng)力，而且還展示了顯著的提升潛力。通過(guò)對(duì)比使用Host-NVMe-CLI（分別通過(guò)TCP和RDMA協(xié)議）、NVMe/TCP和NVMe/RDMA的傳統(tǒng)Ceph性能數(shù)據(jù)，發(fā)現(xiàn)基于DPU的方案并未降低原有的Ceph性能表現(xiàn)，反而在某些指標(biāo)上有所增強(qiáng)。特別是當(dāng)直接對(duì)比基于Host的RBD訪問(wèn)、NVMe/TCP和NVMe/RDMA的性能時(shí)，DPU方案展現(xiàn)出了超越這些傳統(tǒng)訪問(wèn)方式的性能提升，這表明DPU不僅有效卸載了存儲(chǔ)處理任務(wù)，還通過(guò)其硬件加速特性提升了存儲(chǔ)I/O性能。

3. 填補(bǔ)Kubernetes生態(tài)空白：在Kubernetes（K8s）生態(tài)系統(tǒng)中，雖然有多種存儲(chǔ)解決方案和插件，但之前缺乏針對(duì)DPU優(yōu)化的存儲(chǔ)卸載和加速服務(wù)。這一自研的基于DPU的Ceph解決方案，填補(bǔ)了這一技術(shù)空白，為Kubernetes環(huán)境下的應(yīng)用提供了更高效、低延遲的存儲(chǔ)支持。通過(guò)集成DPU加速能力，不僅增強(qiáng)了云原生應(yīng)用的存儲(chǔ)性能，還為用戶提供了更多選擇和優(yōu)化存儲(chǔ)配置的靈活性，有助于提升整個(gè)云平臺(tái)的運(yùn)行效率和成本效益。

綜上所述，基于DPU的Ceph存儲(chǔ)解決方案通過(guò)自研的Kubernetes組件、引入DPU深度優(yōu)化存儲(chǔ)處理流程，顯著降低了宿主機(jī)資源消耗，保持甚至提升了存儲(chǔ)性能，同時(shí)為Kubernetes生態(tài)引入了創(chuàng)新的存儲(chǔ)加速服務(wù)，是面向未來(lái)云原生架構(gòu)的重要技術(shù)進(jìn)步。

本方案來(lái)自于中科馭數(shù)軟件研發(fā)團(tuán)隊(duì)，團(tuán)隊(duì)核心由一群在云計(jì)算、數(shù)據(jù)中心架構(gòu)、高性能計(jì)算領(lǐng)域深耕多年的業(yè)界資深架構(gòu)師和技術(shù)專家組成，不僅擁有豐富的實(shí)戰(zhàn)經(jīng)驗(yàn)，還對(duì)行業(yè)趨勢(shì)具備敏銳的洞察力，該團(tuán)隊(duì)致力于探索、設(shè)計(jì)、開(kāi)發(fā)、推廣可落地的高性能云計(jì)算解決方案，幫助最終客戶加速數(shù)字化轉(zhuǎn)型，提升業(yè)務(wù)效能，同時(shí)降低運(yùn)營(yíng)成本。

審核編輯 黃宇