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

1.1. Mayastor簡介

OpenEBS是一個廣受歡迎的開源云原生存儲解決方案，托管于CNCF（云原生計(jì)算基金會）之下，旨在通過擴(kuò)展Kubernetes的能力，為有狀態(tài)應(yīng)用提供靈活的持久性存儲。Mayastor是OpenEBS項(xiàng)目中的關(guān)鍵存儲引擎，它以其高性能、耐久性和易于管理的特點(diǎn)，為云原生應(yīng)用提供了理想的存儲解決方案。Mayastor的特點(diǎn)包括：

基于NVMe-oF：Mayastor利用NVMe-oF協(xié)議，這是一種基于網(wǎng)絡(luò)的NVMe訪問方法，允許NVMe設(shè)備通過以太網(wǎng)或其他網(wǎng)絡(luò)結(jié)構(gòu)進(jìn)行遠(yuǎn)程訪問，這有助于提高存儲系統(tǒng)的性能和可擴(kuò)展性。

支持多種設(shè)備類型：雖然Mayastor優(yōu)化了NVMe-oF的使用，但它并不要求必須使用NVMe設(shè)備或云卷，也可以與其他類型的存儲設(shè)備配合使用。

與Kubernetes集成：Mayastor作為OpenEBS的一部分，與Kubernetes緊密集成，允許開發(fā)人員和運(yùn)維人員使用Kubernetes的原生工具（如kubectl）來管理和監(jiān)控存儲資源。

Mayastor適用于需要高性能和耐久性存儲解決方案的云原生應(yīng)用場景，特別是在邊緣計(jì)算、大數(shù)據(jù)分析、流媒體處理等領(lǐng)域。它可以幫助開發(fā)人員構(gòu)建高可用性和可擴(kuò)展性的有狀態(tài)應(yīng)用，同時降低存儲系統(tǒng)的復(fù)雜性和成本。通過利用NVMe-oF協(xié)議和最新一代固態(tài)存儲設(shè)備的性能能力，Mayastor能夠提供低開銷的存儲抽象，滿足有狀態(tài)應(yīng)用對持久性存儲的需求。

1.2. 問題與挑戰(zhàn)

當(dāng)前Mayastor只提供了NVMe over TCP技術(shù)實(shí)現(xiàn)數(shù)據(jù)存儲服務(wù)，不支持NVMe over RDMA技術(shù)，這就不能充分挖掘NVMe SSD盤的性能優(yōu)勢，主要問題和挑戰(zhàn)包括：

1、性能瓶頸：

Mayastor依賴于TCP來實(shí)現(xiàn)NVMe SSD的數(shù)據(jù)傳輸，這意味著它不可避免地繼承了TCP的性能瓶頸。TCP的頭部開銷和擁塞控制機(jī)制限制了數(shù)據(jù)傳輸?shù)挠行俾剩绕涫窃谔幚泶罅啃?shù)據(jù)包時更為明顯。對于需要高速訪問和處理的NVMe SSD來說，這種限制可能顯著影響Mayastor的整體性能。

2、延遲敏感應(yīng)用的挑戰(zhàn)：

對于那些對延遲要求極高的應(yīng)用（如高頻交易、實(shí)時數(shù)據(jù)分析等），Mayastor當(dāng)前的TCP實(shí)現(xiàn)可能無法提供足夠的低延遲保證。TCP的延遲增加和抖動問題可能導(dǎo)致這些應(yīng)用的性能下降，從而影響業(yè)務(wù)決策的時效性和準(zhǔn)確性。

3、資源消耗：

在高并發(fā)場景下，Mayastor處理TCP數(shù)據(jù)包時涉及的頻繁中斷和上下文切換會顯著增加CPU的負(fù)載。這不僅會降低系統(tǒng)整體的計(jì)算效率，還可能影響Mayastor處理其他存儲請求的能力，導(dǎo)致整體性能下降。

2. 方案介紹

2.1. 整體架構(gòu)

本方案是基于馭云ycloud-csi架構(gòu)，將Mayastor整合進(jìn)來，通過Gateway提供數(shù)據(jù)通路的RDMA加速，提高IO性能。在Host側(cè)通過DPU卸載，可以進(jìn)一步解放工作節(jié)點(diǎn)上的CPU負(fù)載，獲取更好的應(yīng)用性能。整體架構(gòu)如下所示（標(biāo)綠和標(biāo)藍(lán)部分是自研組件）：

本方案將不同的組件分別部署在不同的node，主要包含：

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

Worker Node上，部署csi-node-host，配合csi-node-dpu，通過volumeattachment發(fā)現(xiàn)DPU掛載的NVMe盤，然后執(zhí)行綁定或者格式化。

DPU上，部署csi-node-dpu和opi-bridge。opi-bridge是卡對opi-api存儲的實(shí)現(xiàn)；csi-node-dpu 負(fù)責(zé)給host側(cè)掛盤。

Storage Node上，部署Mayastor和GATEWAY，GATEWAY是對SPDK封裝的一個服務(wù)，用于后端Mayastor存儲，對外提供NVMe target訪問。

2.2. 方案描述

本方案主要由ycloud-csi、RDMA Gateway和Mayastor后端存儲三個部分組成，下面將對這三個部分進(jìn)行介紹。

2.2.1.ycloud-csi

通過ycloud-csi架構(gòu)可以接入第三方的存儲，讓第三方存儲很方便的使用DPU的能力。其包括ycloud-csi-controller、ycloud-csi-node-host和ycloud-csi-node-dpu，主要職責(zé)是為K8s的負(fù)載提供不同的存儲能力。

2.2.1.1.Ycloud-csi-controller

Ycloud-csi-controller主要實(shí)現(xiàn)以下兩類功能：

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

針對pod，提供存儲的兩種連接模式：AIO和NVMe-oF（因?yàn)閛pi目前只支持這兩種）。如果是NVMe-oF，則調(diào)用不同的plugin在GATEWAY上創(chuàng)建NVMe-oF target。

2.2.1.2.Ycloud-csi-node

Ycloud-csi-node使用插件系統(tǒng)，對接不同的第三方存儲。 ycloud-csi-node按node角色分為ycloud-csi-node-dpu、ycloud-csi-node-host和ycloud-csi-node-default，不同角色的csi-node功能不同，下面分別加以說明：

Ycoud-csi-node-dpu需要處理host和DPU側(cè)的掛盤請求，根據(jù)不同的連接模式(AIO或者NVMe-oF)，連接遠(yuǎn)程存儲。

Ycloud-csi-node-host把DPU側(cè)導(dǎo)出的volume掛載到pod中。

Ycloud-csi-node-default 也就是默認(rèn)的工作模式，工作于smartNic場景。完成掛載volume，導(dǎo)入pod中。

2.2.2.RDMA Gateway

RDMA Gateway是基于SPDK開發(fā)的存儲服務(wù)，可以部署在io-engine相同的節(jié)點(diǎn)上，負(fù)責(zé)連接本地Mayastor的target，對外提供NVMe oF存儲服務(wù)。

2.2.3. Mayastor storage

后端存儲采用Mayastor，管理不同節(jié)點(diǎn)上的硬盤存儲。

2.3. 工作流程

2.3.1.存儲卷創(chuàng)建流程

用戶的App運(yùn)行在POD中。為了能存放持久的數(shù)據(jù)，需要給POD掛載存儲卷。在啟動POD之前，可以先創(chuàng)建好PVC，以供后面使用。創(chuàng)建PVC的過程如下：

圖中除了包含上一章節(jié)介紹的組件外，還有兩個k8s系統(tǒng)提供的用于方便對接csi的組件：

external-provisioner：用戶創(chuàng)建pvc時，該sidecar 會調(diào)用csi-controller的CreateVolume創(chuàng)建存儲并創(chuàng)建pv與之前的pvc綁定。

Pv-controller：當(dāng)?shù)讓哟鎯?zhǔn)備好存儲空間后，該sidecar會更新PVC的狀態(tài)為bound。

2.3.2.存儲卷掛載流程

在POD的描述yaml文件里，會指定使用的存儲卷PVC。創(chuàng)建POD后，K8s的調(diào)度器會選擇一個合適的節(jié)點(diǎn)來啟動POD，然后attacher會把PVC連接到指定節(jié)點(diǎn)上，csi-node會把存儲卷掛載到POD中。

圖中包含兩個k8s系統(tǒng)提供的用于對接csi的組件：

external-attacher：會 watch VolumeAttachment 對象。根據(jù) .spec.attacher 判斷是不是需要自己處理，如果是則調(diào)用ControllerPublishVolume 方法，將.spec.persistentVolumeName 這個 Volume attach 到 .spec.nodeName 這個節(jié)點(diǎn)上。

AD controller： 會 watch Pod 對象，利用Pod 的 Volume 列表計(jì)算出 該 Node 上的 PV 列表，然后和 node.Status.VolumesAttached 值進(jìn)行對比，沒有attach 的話就執(zhí)行 attach 操作。

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

3.1. Pod掛盤

通過相應(yīng)的 yaml 描述文件，可以完成創(chuàng)建PVC，刪除PVC，創(chuàng)建/刪除snapshot，在POD中掛載PVC，并驗(yàn)證操作成功。經(jīng)驗(yàn)證可知，Mayastor原生支持的操作，在添加Gateway之后，仍可以支持。

操作截圖如下：

運(yùn)行kubectl describe pod snap-mayagate-1命令查看pod，結(jié)果如下：

可以連進(jìn)pod進(jìn)行簡單的寫操作測試：

3.2. 性能對比

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

io-engine threads：設(shè)置io-engine的線程個數(shù)為2，4，6，8，分別測試；

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

IO方式：隨機(jī)讀，隨機(jī)寫，順序讀，順序?qū)懀?0%寫的混合讀寫；

不同的測試采樣位置：

在Gateway/io-engine本地，目標(biāo)是使用本地連接提供測試基準(zhǔn)數(shù)據(jù)

在host通過nvme-cli的connect創(chuàng)建盤符來訪問，這是host側(cè)采用smartNic的場景

在host通過DPU直通來訪問存儲，是我們主要關(guān)注的測試case

考慮多個性能指標(biāo)：測試的性能指標(biāo)包括iops，吞吐，延遲和host cpu消耗。

(1) 隨機(jī)寫延遲分析

隨機(jī)寫延遲的測試結(jié)果，如下圖所示：

對比TCP和RDMA在不同地方的采樣，可知，io-engine所在節(jié)點(diǎn)本地訪問延遲較小，在另外一個節(jié)點(diǎn)訪問，TCP延遲增加了一個數(shù)量級，而RDMA延遲增加較小。

（2）順序?qū)憥挿治?/p>

順序?qū)憥挼臏y試結(jié)果，如下圖所示：

通過在本地直接對于NVMe SSD硬盤測試，發(fā)現(xiàn)SSD可支持帶寬大約2680MiB/s左右。從表中可以看到，使用nvme cli連接，無論是TCP還是RDMA，都可以接近后端存儲支持的最大帶寬。單獨(dú)看DPU直通的數(shù)據(jù)，RDMA的性能遠(yuǎn)遠(yuǎn)超過TCP的性能。這是因?yàn)門CP由軟件棧處理，需要消耗大量CPU資源，DPU內(nèi)僅有4core，CPU資源不足造成的。

(3) 隨機(jī)寫IOPS分析

隨機(jī)寫IOPS的測試結(jié)果，如下圖所示：

可以看到：

1.RDMA的io-engine本地和host nvme-cli兩個測試位置曲線接近，說明RDMA是完全卸載到硬件處理，性能好；

2. TCP的兩種方式性能有差別，特別是TCP DPU直通方式的上限是200kiops，說明瓶頸是在DPU的CPU上。

另外把Host cli訪問的數(shù)據(jù)單獨(dú)拿出來，用這兩行單獨(dú)作圖，如下：

可以看到，當(dāng)io-engine thread個數(shù)為4時，RDMA Gateway已經(jīng)基本可以壓滿后端存儲；再增加threads個數(shù)影響不大。但TCP直連時，性能還是會隨著threads增加而增大。這說明RDMA在相對較低的資源條件下就可以達(dá)到較高的性能，其加速效果較好。

（4）隨機(jī)讀IOPS分析

隨機(jī)讀IOPS的測試結(jié)果，如下圖所示：

可以看到TCP DPU直通方式隨機(jī)讀的上限是150kiops，說明瓶頸是在DPU的CPU上。

另外把Host cli訪問的數(shù)據(jù)單獨(dú)拿出來，用這兩行單獨(dú)作圖，如下：

可以看到，當(dāng)io-engine thread個數(shù)為2時，Mayastor TCP方式與RDMA Gateway相差不大，說明瓶頸在于存儲后端；當(dāng)io-engine thread個數(shù)大于等于4時，RDMA Gateway的性能要比TCP方式大約提高20%左右。

對于30%寫的混合讀寫方式，由于讀操作占主體，跟上面讀操作的結(jié)果類似，在Host cli情形下，RDMA Gateway的性能要比TCP方式大約提高20%左右。

(5) Host側(cè)CPU使用分析

在fio測試過程中，通過腳本記錄Host上top命令的輸出信息，獲取CPU的使用信息。

下圖是用Host cli連接時使用CPU的截圖記錄， TCP協(xié)議與RDMA協(xié)議的對比。（測試中Mayastor io-engine 采用8 core。）

測試命令是：

依次對于三個不同的掛接設(shè)備進(jìn)行測試：/dev/nvme2n1是Host側(cè)TCP cli；/dev/nvme3n1是Host側(cè)RDMA cli；/dev/nvme0n26是DPU側(cè)RDMA直通。

在3個掛載盤上分別做fio測試的IOPS結(jié)果分別是：655k，684k，646k?？梢钥吹綔y試出的性能結(jié)果相差不大。上圖是測試過程中通過腳本記錄的CPU使用情況?？梢钥吹?，相對于TCP，使用RDMA協(xié)議可以節(jié)省大量的CPU。

4. 方案優(yōu)勢總結(jié)

1、顯著提升性能：

通過前面測試數(shù)據(jù)可以看到，在DPU直通連入的場景下，本方案比原生的Mayastor方案隨機(jī)寫IOPS性能提升40%左右，隨機(jī)讀IOPS性能提升20%左右。在DPU直通的場景下，TCP方式延約200毫秒，RDMA方式約80毫秒，本方案可以減少60%左右的時延。這是因?yàn)楸痉桨赋浞掷昧薘DMA的超低延遲和高性能特性。RDMA的零拷貝和繞過CPU的傳輸方式極大地減少數(shù)據(jù)傳輸過程中的延遲和CPU消耗，使Mayastor能夠更高效地處理NVMe SSD的讀寫請求。

2、優(yōu)化資源利用：

通過前面測試數(shù)據(jù)可以看到，采用RDMA的方式連接后端存儲，相對于TCP方式可以節(jié)省50%左右的Host cpu。本方案通過NVMe over RDMA減少M(fèi)ayastor對CPU和內(nèi)存的占用，使系統(tǒng)資源能夠更多地用于其他計(jì)算任務(wù)，這有助于提升Mayastor的整體穩(wěn)定性和可靠性，同時降低運(yùn)營成本。

3、增強(qiáng)可擴(kuò)展性和靈活性：

RDMA技術(shù)還提供了更好的可擴(kuò)展性和靈活性。隨著數(shù)據(jù)中心規(guī)模的擴(kuò)大和存儲需求的增長，Mayastor可以通過支持NVMe over RDMA來更輕松地應(yīng)對這些挑戰(zhàn)。RDMA的遠(yuǎn)程直接內(nèi)存訪問特性使得跨節(jié)點(diǎn)的數(shù)據(jù)傳輸更加高效和可靠，有助于構(gòu)建更強(qiáng)大的分布式存儲系統(tǒng)。

4、支持更多應(yīng)用場景：

有了NVMe over RDMA的支持，Mayastor將能夠更好地滿足那些對性能有極高要求的應(yīng)用場景。無論是高頻交易、實(shí)時數(shù)據(jù)分析還是大規(guī)模數(shù)據(jù)庫事務(wù)處理，Mayastor都將能夠提供更加穩(wěn)定和高效的數(shù)據(jù)存儲服務(wù)。

綜上所述，從Mayastor影響的角度來看，NVMe over RDMA技術(shù)相較于TCP在性能、延遲和資源消耗方面均展現(xiàn)出顯著優(yōu)勢。對于追求極致性能的數(shù)據(jù)中心和應(yīng)用場景來說，Mayastor未來能夠支持NVMe over RDMA將是一個重要的里程碑，有助于進(jìn)一步提升其市場競爭力和用戶體驗(yàn)。

本方案來自于中科馭數(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)，還對行業(yè)趨勢具備敏銳的洞察力，該團(tuán)隊(duì)致力于探索、設(shè)計(jì)、開發(fā)、推廣可落地的高性能云計(jì)算解決方案，幫助最終客戶加速數(shù)字化轉(zhuǎn)型，提升業(yè)務(wù)效能，同時降低運(yùn)營成本。

審核編輯 黃宇