什么是RDMA？

RDMA（Remote Direct Memory Access），通俗的說就是遠程的DMA技術(shù)，是為了解決網(wǎng)絡(luò)傳輸中服務(wù)器端數(shù)據(jù)處理的延遲而產(chǎn)生的。

▲ 傳統(tǒng)模式與RDMA模式工作機制對比

如上圖，在傳統(tǒng)模式下，兩臺服務(wù)器上的應(yīng)用之間傳輸數(shù)據(jù)，過程是這樣的：

●  首先要把數(shù)據(jù)從應(yīng)用緩存拷貝到Kernel中的TCP協(xié)議棧緩存；

●  然后再拷貝到驅(qū)動層；

●  最后拷貝到網(wǎng)卡緩存。

多次內(nèi)存拷貝需要CPU多次介入，導(dǎo)致處理延時大，達到數(shù)十微秒。同時整個過程中CPU過多參與，大量消耗CPU性能，影響正常的數(shù)據(jù)計算。

在RDMA 模式下，應(yīng)用數(shù)據(jù)可以繞過Kernel協(xié)議棧直接向網(wǎng)卡寫數(shù)據(jù)，帶來的顯著好處有：

●  處理延時由數(shù)十微秒降低到1微秒內(nèi)；

●  整個過程幾乎不需要CPU參與，節(jié)省性能；

●  傳輸帶寬更高。

RDMA對于網(wǎng)絡(luò)的訴求

RDMA在高性能計算、大數(shù)據(jù)分析、IO高并發(fā)等場景中應(yīng)用越來越廣泛。諸如iSICI, SAN, Ceph, MPI, Hadoop, Spark, Tensorflow等應(yīng)用軟件都開始部署RDMA技術(shù)。而對于支撐端到端傳輸?shù)幕A(chǔ)網(wǎng)絡(luò)而言，低延時（微秒級）、無損（lossless）則是最重要的指標。

低延時

網(wǎng)絡(luò)轉(zhuǎn)發(fā)延時主要產(chǎn)生在設(shè)備節(jié)點（這里忽略了光電傳輸延時和數(shù)據(jù)串行延時），設(shè)備轉(zhuǎn)發(fā)延時包括以下三部分：

●  存儲轉(zhuǎn)發(fā)延時：芯片轉(zhuǎn)發(fā)流水線處理延遲，每個hop會產(chǎn)生1微秒左右的芯片處理延時（業(yè)界也有嘗試使用cut-through模式，單跳延遲可以降低到0.3微秒左右）；

●  Buffer緩存延時：當網(wǎng)絡(luò)擁塞時，報文會被緩存起來等待轉(zhuǎn)發(fā)。這時Buffer越大，緩存報文的時間就越長，產(chǎn)生的時延也會更高。對于RDMA網(wǎng)絡(luò)，Buffer并不是越大越好，需要合理選擇；

●  重傳延時：在RDMA網(wǎng)絡(luò)里會有其他技術(shù)保證不丟包，這部分不做分析。

無損

RDMA在無損狀態(tài)下可以滿速率傳輸，而一旦發(fā)生丟包重傳，性能會急劇下降。在傳統(tǒng)網(wǎng)絡(luò)模式下，要想實現(xiàn)不丟包最主要的手段就是依賴大緩存，但如前文所說，這又與低延時矛盾了。因此，在RDMA網(wǎng)絡(luò)環(huán)境中，需要實現(xiàn)的是較小Buffer下的不丟包。

在這個限制條件下，RDMA實現(xiàn)無損主要是依賴基于PFC和ECN的網(wǎng)絡(luò)流控技術(shù)。

PFC

PFC（Priority-based Flow Control），基于優(yōu)先級的流量控制。是一種基于隊列的反壓機制，通過發(fā)送Pause幀通知上游設(shè)備暫停發(fā)包來防止緩存溢出丟包。

▲ PFC工作機制示意圖

PFC允許單獨暫停和重啟其中任意一條虛擬通道，同時不影響其它虛擬通道的流量。如上圖所示，當隊列7的Buffer消耗達到設(shè)置的PFC流控水線，會觸發(fā)PFC的反壓：

●  本端交換機觸發(fā)發(fā)出PFC Pause幀，并反向發(fā)送給上游設(shè)備；

●  收到Pause幀的上游設(shè)備會暫停該隊列報文的發(fā)送，同時將報文緩存在Buffer中；

●  如果上游設(shè)備的Buffer也達到閾值，會繼續(xù)觸發(fā)Pause幀向上游反壓；

●  最終通過降低該優(yōu)先級隊列的發(fā)送速率來避免數(shù)據(jù)丟包；

●  當Buffer占用降低到恢復(fù)水線時，會發(fā)送PFC解除報文。

RDMA無損網(wǎng)絡(luò)的關(guān)鍵技術(shù)：ECN

ECN（Explicit Congestion Notification）：顯示擁塞通知。ECN是一個非常古老的技術(shù)，只是之前使用的并不普遍，該協(xié)議機制作用于主機與主機之間。

ECN是報文在網(wǎng)絡(luò)設(shè)備出口（Egress port）發(fā)生擁塞并觸發(fā)ECN水線時，使用IP報文頭的ECN字段標記數(shù)據(jù)包，表明該報文遇到網(wǎng)絡(luò)擁塞。一旦接收服務(wù)器發(fā)現(xiàn)報文的ECN被標記，立刻產(chǎn)生CNP（擁塞通知報文），并將它發(fā)送給源端服務(wù)器，CNP消息里包含了導(dǎo)致?lián)砣腇low信息。源端服務(wù)器收到后，通過降低相應(yīng)流發(fā)送速率，緩解網(wǎng)絡(luò)設(shè)備擁塞，從而避免發(fā)生丟包。

通過之前的描述可以了解到，PFC和ECN之所以可以實現(xiàn)網(wǎng)絡(luò)端到端的零丟包，是通過設(shè)置不同的水線來實現(xiàn)的。對這些水線的合理設(shè)置，就是針對交換機MMU的精細化管理，通俗講就是對交換機Buffer的管理。接下來我們具體分析下PFC的水線設(shè)置。

PFC水線設(shè)置

交換芯片都有固定的Pipeline（轉(zhuǎn)發(fā)流水線）， Buffer管理處于入芯片流程和出芯片流程的中間位置。報文處于在這個位置上時，已經(jīng)知道了該報文的入口和出口信息，因此邏輯上就可以分成入方向和出方向分別對緩存進行管理。

PFC水線是基于入方向緩存管理進行觸發(fā)的。芯片在入口方向提供了8個隊列，我們可以將不同優(yōu)先級的業(yè)務(wù)報文映射到不同的隊列上，從而實現(xiàn)對不同優(yōu)先級的報文提供不同的Buffer分配方案。

▲ 隊列Buffer的組成部分

具體到每個隊列，其Buffer分配根據(jù)使用場景設(shè)計為3部分：保證緩存，共享緩存，Headroom。

●  保證緩存：每個隊列的專用緩存，確保每個隊列均有一定緩存以保證基本轉(zhuǎn)發(fā)；

●  共享緩存：流量突發(fā)時可以申請使用的緩存，所有隊列共享；

●  Headroom：在觸發(fā)PFC水線后，到服務(wù)器響應(yīng)降速前，還可以繼續(xù)使用的緩存。

保證緩存設(shè)置

保證緩存是一個靜態(tài)水線（固定的、獨享的）。靜態(tài)水線的利用率非常低，資源消耗卻非常大。我們在實際部署時建議不分配保證緩存，以減少這部分的緩存消耗。這樣，入方向報文直接使用共享緩存空間，可提高Buffer的利用率。

共享緩存設(shè)置

對于共享緩存的設(shè)置，需要采用更為靈活的動態(tài)水線。動態(tài)水線能根據(jù)當前空閑的Buffer資源，以及當前隊列已使用的Buffer資源數(shù)量來決定能否繼續(xù)申請到資源。由于系統(tǒng)中空閑共享Buffer資源與已使用的Buffer資源都是時刻變化的，因此閾值也處于不斷變動中。相對于靜態(tài)水線，動態(tài)水線能更靈活、有效的利用Buffer及避免造成不必要的浪費。

銳捷網(wǎng)絡(luò)交換機支持基于動態(tài)的方式進行Buffer資源的分配，對共享緩存的設(shè)置分為11檔，動態(tài)水線alpha值=隊列可申請緩存量/剩余共享緩存量。隊列的α值越大，其在共享緩存中可使用的百分數(shù)占比也就越高。

▲共享水線α值與可使用率對應(yīng)關(guān)系

我們不妨分析一下：

隊列的α值設(shè)置越小，其最大可申請的共享緩存占比就越小。當端口擁塞時就會越早觸發(fā)PFC流控，PFC流控生效后隊列降速，可以很好地保證網(wǎng)絡(luò)不丟包。

但從性能的角度看，過早觸發(fā)PFC流控，會導(dǎo)致RDMA網(wǎng)絡(luò)吞吐下降。因此我們在MMU水線設(shè)置時需要選取一個平衡值。

PFC水線到底設(shè)置多少，是一個非常復(fù)雜的問題，理論上不存在一個固定的值。實際部署時，需要我們具體分析業(yè)務(wù)模型，并搭建測試環(huán)境進行水線調(diào)優(yōu)，找到匹配業(yè)務(wù)的最佳水線。

Headroom設(shè)置

Headroom：顧名思義，就是頭部空間的意思，是在PFC觸發(fā)后，到PFC真正生效這一段時間，用來緩存隊列報文的。Headroom設(shè)置多大合適？這里與4個因素有關(guān)：

●  PG檢測到觸發(fā)XOFF水線，到構(gòu)造PFC幀發(fā)出的時間（這里主要跟配置的檢測精度以及平均隊列算法相關(guān)，固定配置是固定值）

●  上游收到PFC Pause幀，到停止隊列轉(zhuǎn)發(fā)的時間（主要跟芯片處理性能有關(guān)系，交換芯片實際上是固定值）

●  PFC Pause幀在鏈路上的傳輸時間（跟AOC線纜/光纖距離成正比）

●  隊列暫停發(fā)送后鏈路中報文的傳輸時間（跟AOC線纜/光纖距離成正比）

因此Headroom所需要的緩存大小，我們可以根據(jù)組網(wǎng)的架構(gòu)，以及流量模型測算得出。以100米光纖線 + 100G光模塊，緩存64字節(jié)小包，計算出所需的Headroom大小是408個cell（cell是緩存管理的最小單元，一個報文會占用1個或者多個cell），實際測試數(shù)據(jù)也吻合。當然，考慮一定的冗余性，Headroom設(shè)置建議比理論值稍大。

RDMA網(wǎng)絡(luò)實踐

銳捷網(wǎng)絡(luò)在研發(fā)中心搭建了模擬真實業(yè)務(wù)的RDMA網(wǎng)絡(luò)，架構(gòu)如下：

▲銳捷網(wǎng)絡(luò)RDMA組網(wǎng)架構(gòu)

●  組網(wǎng)模型：大核心三級組網(wǎng)架構(gòu)，核心采用高密100G線卡；

●  POD內(nèi)：Spine采用提供64個100G接口的 BOX設(shè)備，Leaf采用提供48個25G接口+8個100G接口的BOX設(shè)備；

●  Leaf作為服務(wù)器網(wǎng)關(guān)，支持和服務(wù)器間基于PFC流控（識別報文的DSCP并進行PG映射），同時支持擁塞ECN標記；

●  RDMA僅運行于POD內(nèi)部，不存在跨POD的RDMA流量，因此核心無需感知RDMA流量；

●  為了避免擁塞丟包，需要在Leaf與Spine之間部署PFC流控技術(shù)，同時Spine設(shè)備也需要支持基于擁塞的ECN標記；

●  Leaf和Spine設(shè)備支持PFC流控幀統(tǒng)計、ECN標記統(tǒng)計、擁塞丟包統(tǒng)計、基于隊列的擁塞統(tǒng)計等，并支持將統(tǒng)計信息通過gRPC同步到遠端gRPC服務(wù)器。

寫在最后

銳捷網(wǎng)絡(luò)在研發(fā)中心同樣搭建了模擬真實業(yè)務(wù)的浸泡組網(wǎng)環(huán)境（包括RG-S6510、RG-S6520、RG-N18000-X系列25G/100G網(wǎng)絡(luò)設(shè)備、大型測試儀、25G服務(wù)器）。在疊加了多種業(yè)務(wù)模型，并進行了長時間浸泡測試后，我們對于RDMA網(wǎng)絡(luò)的MMU水線設(shè)置已有一些推薦的經(jīng)驗值。此外，在RDMA網(wǎng)絡(luò)中，還存在一些部署難點，比如多級網(wǎng)絡(luò)中 PFC風(fēng)暴、死鎖問題、ECN水線設(shè)計復(fù)雜問題等。對于這些問題，銳捷網(wǎng)絡(luò)也有一些研究和積累，期待與大家共同探討。

本期作者：顏曉波

銳捷網(wǎng)絡(luò)互聯(lián)網(wǎng)系統(tǒng)部行業(yè)咨詢

感謝您關(guān)注銳捷網(wǎng)絡(luò)技術(shù)干貨文章！現(xiàn)誠邀您參與有獎?wù){(diào)研，您寶貴的意見和建議將幫助我們在技術(shù)探索與分享上持續(xù)精進。

點擊下方鏈接參與調(diào)研。

#