C114通信網(wǎng)  |  通信人家園

技術(shù)
2018/7/2 11:55

技術(shù)盛宴 | 淺析RDMA網(wǎng)絡(luò)下MMU水線設(shè)置

C114中國通信網(wǎng)  

RDMA(遠(yuǎn)程直接數(shù)據(jù)存取),以其對業(yè)務(wù)帶來的高性能、低延時優(yōu)勢,在數(shù)據(jù)中心尤其是AI、HPC、大數(shù)據(jù)等場景得到了廣泛應(yīng)用。為保障RDMA的穩(wěn)定運行,基礎(chǔ)網(wǎng)絡(luò)需要提供端到端無損零丟包及超低延時的能力,這也催生了PFC、ECN等網(wǎng)絡(luò)流控技術(shù)在RDMA網(wǎng)絡(luò)中的部署。在RDMA網(wǎng)絡(luò)中,如何合理設(shè)置MMU(緩存管理單元)水線是保證RDMA網(wǎng)絡(luò)無損和低延時的關(guān)鍵。本文將以RDMA網(wǎng)絡(luò)作為切入點,結(jié)合實際部署經(jīng)驗,分析MMU水線設(shè)置的一些思路。

什么是RDMA?

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

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

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

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

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

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

多次內(nèi)存拷貝需要CPU多次介入,導(dǎo)致處理延時大,達(dá)到數(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)則是最重要的指標(biāo)。

低延時

網(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緩存延時:當(dāng)網(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)先級的流量控制。是一種基于隊列的反壓機(jī)制,通過發(fā)送Pause幀通知上游設(shè)備暫停發(fā)包來防止緩存溢出丟包。

▲ PFC工作機(jī)制示意圖

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

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

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

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

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

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

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

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

ECN是報文在網(wǎng)絡(luò)設(shè)備出口(Egress port)發(fā)生擁塞并觸發(fā)ECN水線時,使用IP報文頭的ECN字段標(biāo)記數(shù)據(jù)包,表明該報文遇到網(wǎng)絡(luò)擁塞。一旦接收服務(wù)器發(fā)現(xiàn)報文的ECN被標(biāo)記,立刻產(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è)置,就是針對交換機(jī)MMU的精細(xì)化管理,通俗講就是對交換機(jī)Buffer的管理。接下來我們具體分析下PFC的水線設(shè)置。

PFC水線設(shè)置

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

PFC水線是基于入方向緩存管理進(jìn)行觸發(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ù)當(dāng)前空閑的Buffer資源,以及當(dāng)前隊列已使用的Buffer資源數(shù)量來決定能否繼續(xù)申請到資源。由于系統(tǒng)中空閑共享Buffer資源與已使用的Buffer資源都是時刻變化的,因此閾值也處于不斷變動中。相對于靜態(tài)水線,動態(tài)水線能更靈活、有效的利用Buffer及避免造成不必要的浪費。

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

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

我們不妨分析一下:

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

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

PFC水線到底設(shè)置多少,是一個非常復(fù)雜的問題,理論上不存在一個固定的值。實際部署時,需要我們具體分析業(yè)務(wù)模型,并搭建測試環(huán)境進(jì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ù)也吻合。當(dāng)然,考慮一定的冗余性,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并進(jìn)行PG映射),同時支持擁塞ECN標(biāo)記;

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

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

●  Leaf和Spine設(shè)備支持PFC流控幀統(tǒng)計、ECN標(biāo)記統(tǒng)計、擁塞丟包統(tǒng)計、基于隊列的擁塞統(tǒng)計等,并支持將統(tǒng)計信息通過gRPC同步到遠(yuǎn)端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ù)模型,并進(jìn)行了長時間浸泡測試后,我們對于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ù)精進(jìn)。

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

http://survey.ruijie.com.cn/m/25569404.aspx#

給作者點贊
0 VS 0
寫得不太好

免責(zé)聲明:本文僅代表作者個人觀點,與C114通信網(wǎng)無關(guān)。其原創(chuàng)性以及文中陳述文字和內(nèi)容未經(jīng)本站證實,對本文以及其中全部或者部分內(nèi)容、文字的真實性、完整性、及時性本站不作任何保證或承諾,請讀者僅作參考,并請自行核實相關(guān)內(nèi)容。

熱門文章
    最新視頻
    為您推薦

      C114簡介 | 聯(lián)系我們 | 網(wǎng)站地圖 | 手機(jī)版

      Copyright©1999-2024 c114 All Rights Reserved | 滬ICP備12002291號

      C114 通信網(wǎng) 版權(quán)所有 舉報電話:021-54451141