看過(guò)前面幾期的技術(shù)文章，相信大家對(duì)RDMA(Remote Direct Memory Access，遠(yuǎn)程直接數(shù)據(jù)存取)和無(wú)損網(wǎng)絡(luò)有了一定的認(rèn)識(shí)，也許大家會(huì)問(wèn)為什么我們需要RDMA？為什么我們需要無(wú)損網(wǎng)絡(luò)？這些先進(jìn)的技術(shù)究竟能給我們帶來(lái)什么好處？

只從網(wǎng)絡(luò)層面來(lái)看可能無(wú)法得出令人滿意的答案，下面分別從前端業(yè)務(wù)和后端應(yīng)用，簡(jiǎn)單列舉幾個(gè)例子，相信大家可以從中解開(kāi)疑惑。

首先想說(shuō)的是互聯(lián)網(wǎng)中大量的在線業(yè)務(wù)，例如在線搜索、購(gòu)物、直播等，它需要以非常快的速度對(duì)高頻率的用戶請(qǐng)求做出應(yīng)答，數(shù)據(jù)中心內(nèi)任何一個(gè)環(huán)節(jié)導(dǎo)致延遲，都會(huì)對(duì)終端用戶的訪問(wèn)體驗(yàn)造成極大的影響，從而影響其流量、口碑、活躍用戶等。

還有在機(jī)器學(xué)習(xí)和AI的技術(shù)趨勢(shì)下，對(duì)計(jì)算能力的需求是呈幾何級(jí)數(shù)上升的，為了滿足日益復(fù)雜的神經(jīng)網(wǎng)絡(luò)和深度學(xué)習(xí)模型，數(shù)據(jù)中心會(huì)存在大量的分布式計(jì)算集群，但大量并行程序的通訊延遲，則會(huì)極大影響整個(gè)計(jì)算過(guò)程的效率。

另外為了解決數(shù)據(jù)中心內(nèi)爆炸式增長(zhǎng)的數(shù)據(jù)存儲(chǔ)和讀取效率問(wèn)題，利用以太網(wǎng)融合組網(wǎng)的分布式存儲(chǔ)越來(lái)越受到歡迎。但因?yàn)榇鎯?chǔ)網(wǎng)絡(luò)中數(shù)據(jù)流以大象流為主，所以一旦因擁塞造成丟包，將會(huì)引發(fā)大象流重傳，不僅降低效率，還會(huì)加重?fù)砣?/p>

所以從前端用戶的體驗(yàn)和后端應(yīng)用的效率來(lái)看，眼下對(duì)于數(shù)據(jù)中心網(wǎng)絡(luò)的要求是：延遲越低越好，效率越高越好。

為了降低數(shù)據(jù)中心內(nèi)部網(wǎng)絡(luò)延遲，提高處理效率，RDMA技術(shù)應(yīng)運(yùn)而生，通過(guò)允許用戶態(tài)的應(yīng)用程序直接讀取和寫入遠(yuǎn)程內(nèi)存，而無(wú)需CPU介入多次拷貝內(nèi)存，并可繞過(guò)內(nèi)核直接向網(wǎng)卡寫數(shù)據(jù)，實(shí)現(xiàn)了高吞吐量、超低時(shí)延和低CPU開(kāi)銷的效果。

當(dāng)前RDMA在以太網(wǎng)上的傳輸協(xié)議是RoCEv2，RoCEv2是基于無(wú)連接協(xié)議的UDP協(xié)議，相比面向連接的TCP協(xié)議，UDP協(xié)議更加快速、占用CPU資源更少，但其不像TCP協(xié)議那樣有滑動(dòng)窗口、確認(rèn)應(yīng)答等機(jī)制來(lái)實(shí)現(xiàn)可靠傳輸，一旦出現(xiàn)丟包，依靠上層應(yīng)用檢查到了再做重傳，會(huì)大大降低RDMA的傳輸效率。

所以要想發(fā)揮出RDMA真正的性能，突破數(shù)據(jù)中心大規(guī)模分布式系統(tǒng)的網(wǎng)絡(luò)性能瓶頸，勢(shì)必要為RDMA搭建一套不丟包的無(wú)損網(wǎng)絡(luò)環(huán)境，而實(shí)現(xiàn)不丟包的關(guān)鍵就是解決網(wǎng)絡(luò)擁塞。

一、為什么會(huì)產(chǎn)生擁塞

產(chǎn)生擁塞的原因有很多，下面列舉了在數(shù)據(jù)中心場(chǎng)景里比較關(guān)鍵也是比較常見(jiàn)的三點(diǎn)原因：

1．收斂比

進(jìn)行數(shù)據(jù)中心網(wǎng)絡(luò)架構(gòu)設(shè)計(jì)時(shí)，從成本和收益兩方面來(lái)考慮，多數(shù)會(huì)采取非對(duì)稱帶寬設(shè)計(jì)，即上下行鏈路帶寬不一致，交換機(jī)的收斂比簡(jiǎn)單說(shuō)就是總的輸入帶寬除以總的輸出帶寬。以銳捷萬(wàn)兆交換機(jī)RG-S6220-48XS6QXS-H為例，下行可供服務(wù)器輸入的帶寬是48*10G=480G，上行輸出的帶寬是6*40G=240G，整機(jī)收斂比為2:1。而25G交換機(jī)RG-S6510-48VS8CQ，下行可供服務(wù)器輸入的帶寬是48*25G=1200G，上行輸出的帶寬是8*100G=800G，整機(jī)收斂比是1.5:1。

也就是說(shuō)，當(dāng)下聯(lián)的服務(wù)器上行發(fā)包總速率超過(guò)上行鏈路總帶寬時(shí)，就會(huì)在上行口出現(xiàn)擁塞。

2．ECMP

當(dāng)前數(shù)據(jù)中心網(wǎng)絡(luò)多采用Fabric架構(gòu)，并采用ECMP來(lái)構(gòu)建多條等價(jià)負(fù)載均衡的鏈路，通過(guò)設(shè)置擾動(dòng)因子并HASH選擇一條鏈路來(lái)轉(zhuǎn)發(fā)是簡(jiǎn)單的，但這個(gè)過(guò)程中卻沒(méi)有考慮到所選鏈路本身是否有擁塞。ECMP并沒(méi)有擁塞感知的機(jī)制，只是將流分散到不同的鏈路上轉(zhuǎn)發(fā)，對(duì)于已經(jīng)產(chǎn)生擁塞的鏈路來(lái)說(shuō)，很可能加劇鏈路的擁塞。

3．TCP Incast

TCP Incast是Many-to-One的通信模式，在數(shù)據(jù)中心云化的大趨勢(shì)下這種通信模式常常發(fā)生，尤其是那些以Scale-Out方式實(shí)現(xiàn)的分布式存儲(chǔ)和計(jì)算應(yīng)用，包括Hadoop、MapReduce、HDFS等。

例如，當(dāng)一個(gè)Parent Server向一組節(jié)點(diǎn)（服務(wù)器集群或存儲(chǔ)集群）發(fā)起一個(gè)請(qǐng)求時(shí)，集群中的節(jié)點(diǎn)都會(huì)同時(shí)收到該請(qǐng)求，并且?guī)缀跬瑫r(shí)做出響應(yīng)，很多節(jié)點(diǎn)同時(shí)向一臺(tái)機(jī)器（Parent Server）發(fā)送TCP數(shù)據(jù)流，從而產(chǎn)生了一個(gè)“微突發(fā)流”，使得交換機(jī)上連接Parent Server的出端口緩存不足，造成擁塞。

▲TCP Incast流量模型

正如前面所說(shuō)，RDMA和TCP不同，它需要一個(gè)無(wú)損網(wǎng)絡(luò)。對(duì)于普通的微突發(fā)流量，交換機(jī)的Buffer緩沖區(qū)可以起到一定作用，在緩沖區(qū)將突發(fā)的報(bào)文進(jìn)行列隊(duì)等待，但由于增加交換機(jī)Buffer容量的成本非常高，所以它所能起到的作用是有限的，一旦緩沖區(qū)列隊(duì)的報(bào)文過(guò)多，仍舊會(huì)產(chǎn)生丟包。

為了實(shí)現(xiàn)端到端的無(wú)損轉(zhuǎn)發(fā)，避免因?yàn)榻粨Q機(jī)中的Buffer緩沖區(qū)溢出而引發(fā)的數(shù)據(jù)包丟失，交換機(jī)必須引入其他機(jī)制，如流量控制，通過(guò)對(duì)鏈路上流量的控制，減少對(duì)交換機(jī)Buffer的壓力，來(lái)規(guī)避丟包的產(chǎn)生。

二、PFC如何實(shí)現(xiàn)流控

IEEE 802.1Qbb（Priority-based Flow Control，基于優(yōu)先級(jí)的流量控制）簡(jiǎn)稱PFC，是IEEE數(shù)據(jù)中心橋接（Data Center Bridge）協(xié)議族中的一個(gè)技術(shù)，是流量控制的增強(qiáng)版。

說(shuō)PFC之前，我們可以先看一下IEEE 802.3X（Flow Control）流控的機(jī)制：當(dāng)接收者沒(méi)有能力處理接收到的報(bào)文時(shí)，為了防止報(bào)文被丟棄，接收者需要通知報(bào)文的發(fā)送者暫時(shí)停止發(fā)送報(bào)文。

如下圖所示，端口G0/1和G0/2以1Gbps速率轉(zhuǎn)發(fā)報(bào)文時(shí)，端口F0/1將發(fā)生擁塞。為避免報(bào)文丟失，開(kāi)啟端口G0/1和G0/2的Flow Control功能。

▲端口產(chǎn)生擁塞的打流模型

• 當(dāng)F0/1在轉(zhuǎn)發(fā)報(bào)文出現(xiàn)擁塞時(shí)，交換機(jī)B會(huì)在端口緩沖區(qū)中排隊(duì)報(bào)文，當(dāng)擁塞超過(guò)一定閾值時(shí)，端口G0/2向G0/1發(fā)PAUSE幀，通知G0/1暫時(shí)停止發(fā)送報(bào)文。

• G0/1接收到PAUSE幀后暫時(shí)停止向G0/2發(fā)送報(bào)文。暫停時(shí)間長(zhǎng)短信息由PAUSE幀所攜帶。交換機(jī)A會(huì)在這個(gè)超時(shí)范圍內(nèi)等待，或者直到收到一個(gè)Timeout值為0的控制幀后再繼續(xù)發(fā)送。

IEEE 802.3X協(xié)議存在一個(gè)缺點(diǎn)：一旦鏈路被暫停，發(fā)送方就不能再發(fā)送任何數(shù)據(jù)包，如果是因?yàn)槟承﹥?yōu)先級(jí)較低的數(shù)據(jù)流引發(fā)的暫停，結(jié)果卻讓該鏈路上其他更高優(yōu)先級(jí)的數(shù)據(jù)流也一起被暫停了，其實(shí)是得不償失的。

如下圖中報(bào)文解析所示，PFC在基礎(chǔ)流控IEEE 802.3X基礎(chǔ)上進(jìn)行擴(kuò)展，允許在一條以太網(wǎng)鏈路上創(chuàng)建8個(gè)虛擬通道，并為每條虛擬通道指定相應(yīng)優(yōu)先級(jí)，允許單獨(dú)暫停和重啟其中任意一條虛擬通道，同時(shí)允許其它虛擬通道的流量無(wú)中斷通過(guò)。

▲PFC協(xié)議報(bào)文結(jié)構(gòu)解析

PFC將流控的粒度從物理端口細(xì)化到8個(gè)虛擬通道，分別對(duì)應(yīng)Smart NIC硬件上的8個(gè)硬件發(fā)送隊(duì)列（這些隊(duì)列命名為Traffic Class，分別為TC0,TC1,...,TC7），在RDMA不同的封裝協(xié)議下，也有不同的映射方式。

•  RoCEv1：

這個(gè)協(xié)議是將RDMA數(shù)據(jù)段封裝到以太網(wǎng)數(shù)據(jù)段內(nèi)，再加上以太網(wǎng)的頭部，因此屬于二層數(shù)據(jù)包。為了對(duì)它進(jìn)行分類，只能使用VLAN（IEEE 802.1q）頭部中的PCP(Priority Code Point)域3 Bits來(lái)設(shè)置優(yōu)先級(jí)值。

▲二層以太網(wǎng)幀VLAN頭部結(jié)構(gòu)

•  RoCEv2：

這個(gè)協(xié)議是將RDMA數(shù)據(jù)段先封裝到UDP數(shù)據(jù)段內(nèi)，加上UDP頭部，再加上IP頭部，最后再加上以太網(wǎng)頭部，屬于三層數(shù)據(jù)包。對(duì)它進(jìn)行分類，既可以使用以太網(wǎng)VLAN中的PCP域，也可以使用IP頭部的DSCP域。

▲三層IP報(bào)文頭部結(jié)構(gòu)

簡(jiǎn)單來(lái)說(shuō)，在二層網(wǎng)絡(luò)的情況下，PFC使用VLAN中的PCP位來(lái)對(duì)數(shù)據(jù)流進(jìn)行區(qū)分，在三層網(wǎng)絡(luò)的情況下，PFC既可以使用PCP、也可以使用DSCP，使得不同數(shù)據(jù)流可以享受到獨(dú)立的流控制。當(dāng)下數(shù)據(jù)中心因多采用三層網(wǎng)絡(luò)，因此使用DSCP比PCP更具有優(yōu)勢(shì)。

三、PFC死鎖

雖然PFC能夠通過(guò)給不同隊(duì)列映射不同優(yōu)先級(jí)來(lái)實(shí)現(xiàn)基于隊(duì)列的流控，但同時(shí)也引入了新的問(wèn)題，例如PFC死鎖的問(wèn)題。

PFC死鎖，是指當(dāng)多個(gè)交換機(jī)之間因微環(huán)路等原因同時(shí)出現(xiàn)擁塞,各自端口緩存消耗超過(guò)閾值，而又相互等待對(duì)方釋放資源，從而導(dǎo)致所有交換機(jī)上的數(shù)據(jù)流都永久阻塞的一種網(wǎng)絡(luò)狀態(tài)。

正常情況下，當(dāng)一臺(tái)交換機(jī)的端口出現(xiàn)擁塞并觸發(fā)XOFF水線時(shí)，數(shù)據(jù)進(jìn)入的方向（即下游設(shè)備）將發(fā)送PAUSE幀反壓，上游設(shè)備接收到PAUSE幀后停止發(fā)送數(shù)據(jù)，如果其本地端口緩存消耗超過(guò)閾值，則繼續(xù)向上游反壓。如此一級(jí)級(jí)反壓，直到網(wǎng)絡(luò)終端服務(wù)器在PAUSE幀中指定Pause Time內(nèi)暫停發(fā)送數(shù)據(jù)，從而消除網(wǎng)絡(luò)節(jié)點(diǎn)因擁塞造成的丟包。

但在特殊情況下，例如發(fā)生鏈路故障或設(shè)備故障時(shí)，BGP路由重新收斂期間可能會(huì)出現(xiàn)短暫環(huán)路，會(huì)導(dǎo)致出現(xiàn)一個(gè)循環(huán)的緩沖區(qū)依賴。如下圖所示，當(dāng)4臺(tái)交換機(jī)都達(dá)到XOFF水線，都同時(shí)向?qū)Χ税l(fā)送PAUSE幀，這個(gè)時(shí)候該拓?fù)渲兴薪粨Q機(jī)都處于停流狀態(tài)，由于PFC的反壓效應(yīng)，整個(gè)網(wǎng)絡(luò)或部分網(wǎng)絡(luò)的吞吐量將變?yōu)榱恪?/p>

▲PFC死鎖示意圖

即使在無(wú)環(huán)網(wǎng)絡(luò)中形成短暫環(huán)路時(shí)，也可能發(fā)生死鎖。雖然經(jīng)過(guò)修復(fù)短暫環(huán)路會(huì)很快消失，但它們?cè)斐傻乃梨i不是暫時(shí)的，即便重啟服務(wù)器中斷流量，死鎖也不能自動(dòng)恢復(fù)。

為了解除死鎖狀態(tài)，一方面是要杜絕數(shù)據(jù)中心里的環(huán)路產(chǎn)生，另一方面則可以通過(guò)網(wǎng)絡(luò)設(shè)備的死鎖檢測(cè)功能來(lái)實(shí)現(xiàn)。銳捷RG-S6510-48VS8CQ上的Deadlock檢測(cè)功能，可以檢測(cè)到出現(xiàn)Deadlock狀態(tài)后的一段時(shí)間內(nèi)，忽略收到的PFC幀，同時(shí)對(duì)buffer中的報(bào)文執(zhí)行轉(zhuǎn)發(fā)或丟棄的操作（默認(rèn)是轉(zhuǎn)發(fā)）。

例如，定時(shí)器的監(jiān)控次數(shù)可配置設(shè)置檢測(cè)10次，每次10ms內(nèi)檢測(cè)是否收到PFC Pause幀。若10次均收到則說(shuō)明產(chǎn)生Deadlock，對(duì)buffer中的報(bào)文執(zhí)行默認(rèn)操作，之后將設(shè)置100ms作為Recover時(shí)間后恢復(fù)再檢測(cè)。命令如下：

priority-flow-control deadlock cos-value 5 detect 10 recover 100  //10次檢測(cè)，100ms recover。

RDMA無(wú)損網(wǎng)絡(luò)中利用PFC流控機(jī)制，實(shí)現(xiàn)了交換機(jī)端口緩存溢出前暫停對(duì)端流量，阻止了丟包現(xiàn)象發(fā)生，但因?yàn)樾枰患?jí)一級(jí)反壓，效率較低，所以需要更高效的、端到端的流控能力。

四、利用ECN實(shí)現(xiàn)端到端的擁塞控制

當(dāng)前的RoCE擁塞控制依賴ECN(Explicit Congestion Notification，顯式擁塞通知)來(lái)運(yùn)行。ECN最初在RFC 3168中定義，網(wǎng)絡(luò)設(shè)備會(huì)在檢測(cè)到擁塞時(shí)，通過(guò)在IP頭部嵌入一個(gè)擁塞指示器和在TCP頭部嵌入一個(gè)擁塞確認(rèn)實(shí)現(xiàn)。

RoCEv2標(biāo)準(zhǔn)定義了RoCEv2擁塞管理(RCM)。啟用了ECN之后，網(wǎng)絡(luò)設(shè)備一旦檢測(cè)到RoCEv2流量出現(xiàn)了擁塞，會(huì)在數(shù)據(jù)包的IP頭部ECN域進(jìn)行標(biāo)記。

▲IP報(bào)文頭ECN字段結(jié)構(gòu)

這個(gè)擁塞指示器被目的終端節(jié)點(diǎn)按照BTH(Base Transport Header，存在于IB數(shù)據(jù)段中)中的FECN擁塞指示標(biāo)識(shí)來(lái)解釋意義。換句話說(shuō)，當(dāng)被ECN標(biāo)記過(guò)的數(shù)據(jù)包到達(dá)它們?cè)疽竭_(dá)的目的地時(shí)，擁塞通知就會(huì)被反饋給源節(jié)點(diǎn)，源節(jié)點(diǎn)再通過(guò)對(duì)有問(wèn)題的Queue Pairs（QP）進(jìn)行網(wǎng)絡(luò)數(shù)據(jù)包的速率限制來(lái)回應(yīng)擁塞通知。

▲ECN交互過(guò)程示意圖

五、ECN交互過(guò)程

① 發(fā)送端發(fā)送的IP報(bào)文標(biāo)記支持ECN（10）；

② 交換機(jī)在隊(duì)列擁塞情況下收到該報(bào)文，將ECN字段修改為11并發(fā)出，網(wǎng)絡(luò)中其他交換機(jī)將透?jìng)鳎?/p>

③ 接收端收到ECN為11的報(bào)文發(fā)現(xiàn)擁塞，正常處理該報(bào)文；

④ 接收端產(chǎn)生擁塞通告，每ms級(jí)發(fā)送一個(gè)CNP（Congestion Notification Packets）報(bào)文，ECN字段為01，要求報(bào)文不能被網(wǎng)絡(luò)丟棄。接收端對(duì)多個(gè)被ECN標(biāo)記為同一個(gè)QP的數(shù)據(jù)包發(fā)送一個(gè)單個(gè)CNP即可（格式規(guī)定見(jiàn)下圖）；

⑤ 交換機(jī)收到CNP報(bào)文后正常轉(zhuǎn)發(fā)該報(bào)文；

⑥ 發(fā)送端收到ECN標(biāo)記為01的CNP報(bào)文解析后對(duì)相應(yīng)的流（對(duì)應(yīng)啟用ECN的QP）應(yīng)用速率限制算法。

RoCEv2的CNP包格式如下：

▲CNP報(bào)文結(jié)構(gòu)

值得注意的是，CNP作為擁塞控制報(bào)文，也會(huì)存在延遲和丟包，從發(fā)送端到接收端經(jīng)過(guò)的每一跳設(shè)備、每一條鏈路都會(huì)有一定的延遲，會(huì)最終加大發(fā)送端接收到CNP的時(shí)間，而與此同時(shí)交換機(jī)端口下的擁塞也會(huì)逐步增多，若發(fā)送端不能及時(shí)降速，仍然可能造成丟包。建議擁塞通告域的規(guī)模不要過(guò)大，從而避免因?yàn)镋CN控制報(bào)文交互回路的跳數(shù)過(guò)多，而影響發(fā)送端無(wú)法及時(shí)降速，造成擁塞。

總結(jié)

RDMA網(wǎng)絡(luò)正是通過(guò)在網(wǎng)絡(luò)中部署PFC和ECN功能來(lái)實(shí)現(xiàn)無(wú)損保障。PFC技術(shù)讓我們可以對(duì)鏈路上RDMA專屬隊(duì)列的流量進(jìn)行控制，并在交換機(jī)入口（Ingress port）出現(xiàn)擁塞時(shí)對(duì)上游設(shè)備流量進(jìn)行反壓。利用ECN技術(shù)我們可以實(shí)現(xiàn)端到端的擁塞控制，在交換機(jī)出口（Egress port）擁塞時(shí)，對(duì)數(shù)據(jù)包做ECN標(biāo)記，并讓流量發(fā)送端降低發(fā)送速率。

從充分發(fā)揮網(wǎng)絡(luò)高性能轉(zhuǎn)發(fā)的角度，我們一般建議通過(guò)調(diào)整ECN和PFC的buffer水線，讓ECN快于PFC觸發(fā)，即網(wǎng)絡(luò)還是持續(xù)全速進(jìn)行數(shù)據(jù)轉(zhuǎn)發(fā)，讓服務(wù)器主動(dòng)降低發(fā)包速率。如果還不能解決問(wèn)題，再通過(guò)PFC讓上游交換機(jī)暫停報(bào)文發(fā)送，雖然整網(wǎng)吞吐性能降低，但是不會(huì)產(chǎn)生丟包。

在數(shù)據(jù)中心網(wǎng)絡(luò)中應(yīng)用RDMA，不僅要解決轉(zhuǎn)發(fā)面的無(wú)損網(wǎng)絡(luò)需求，還要關(guān)注精細(xì)化運(yùn)維，才能應(yīng)對(duì)延遲和丟包敏感的網(wǎng)絡(luò)環(huán)境。有關(guān)MMU的精細(xì)化管理技術(shù)以及基于INT的網(wǎng)絡(luò)可視化技術(shù)可參考往期文章。

本期作者：趙爽

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

感謝您關(guān)注銳捷網(wǎng)絡(luò)技術(shù)干貨文章！現(xiàn)誠(chéng)邀您參與調(diào)研，您寶貴的意見(jiàn)和建議將幫助我們?cè)诩夹g(shù)探索與分享上持續(xù)精進(jìn)。點(diǎn)擊下方鏈接參與調(diào)研：

http://survey.ruijie.com.cn/m/27674678.aspx