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

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

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

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

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

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

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

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

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

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

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

1.收斂比

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

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

2.ECMP

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

3.TCP Incast

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

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

▲TCP Incast流量模型

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

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

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

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

說PFC之前，我們可以先看一下IEEE 802.3X(Flow Control)流控的機制：當接收者沒有能力處理接收到的報文時，為了防止報文被丟棄，接收者需要通知報文的發(fā)送者暫時停止發(fā)送報文。

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

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

? 當F0/1在轉(zhuǎn)發(fā)報文出現(xiàn)擁塞時，交換機B會在端口緩沖區(qū)中排隊報文，當擁塞超過一定閾值時，端口G0/2向G0/1發(fā)PAUSE幀，通知G0/1暫時停止發(fā)送報文。

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

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

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

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

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

? RoCEv1：

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

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

? RoCEv2：

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

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

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

三、PFC死鎖

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

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

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

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

▲PFC死鎖示意圖

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

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

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

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

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

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

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

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

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

這個擁塞指示器被目的終端節(jié)點按照BTH(Base Transport Header，存在于IB數(shù)據(jù)段中)中的FECN擁塞指示標識來解釋意義。換句話說，當被ECN標記過的數(shù)據(jù)包到達它們原本要到達的目的地時，擁塞通知就會被反饋給源節(jié)點，源節(jié)點再通過對有問題的Queue Pairs(QP)進行網(wǎng)絡(luò)數(shù)據(jù)包的速率限制來回應(yīng)擁塞通知。

▲ECN交互過程示意圖

五、ECN交互過程

① 發(fā)送端發(fā)送的IP報文標記支持ECN(10);

② 交換機在隊列擁塞情況下收到該報文，將ECN字段修改為11并發(fā)出，網(wǎng)絡(luò)中其他交換機將透傳;

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

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

⑤ 交換機收到CNP報文后正常轉(zhuǎn)發(fā)該報文;

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

RoCEv2的CNP包格式如下：

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

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

總結(jié)

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

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

在數(shù)據(jù)中心網(wǎng)絡(luò)中應(yīng)用RDMA，不僅要解決轉(zhuǎn)發(fā)面的無損網(wǎng)絡(luò)需求，還要關(guān)注精細化運維，才能應(yīng)對延遲和丟包敏感的網(wǎng)絡(luò)環(huán)境。