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

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

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

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

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

所以從前端用戶的體驗和后端應用的效率來看，眼下對于數據中心網絡的要求是：延遲越低越好，效率越高越好。

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

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

所以要想發揮出RDMA真正的性能，突破數據中心大規模分布式系統的網絡性能瓶頸，勢必要為RDMA搭建一套不丟包的無損網絡環境，而實現不丟包的關鍵就是解決網絡擁塞。

一、為什么會產生擁塞

產生擁塞的原因有很多，下面列舉了在數據中心場景里比較關鍵也是比較常見的三點原因：

1．收斂比

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

也就是說，當下聯的服務器上行發包總速率超過上行鏈路總帶寬時，就會在上行口出現擁塞。

2．ECMP

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

3．TCP Incast

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

例如，當一個Parent Server向一組節點（服務器集群或存儲集群）發起一個請求時，集群中的節點都會同時收到該請求，并且幾乎同時做出響應，很多節點同時向一臺機器（Parent Server）發送TCP數據流，從而產生了一個“微突發流”，使得交換機上連接Parent Server的出端口緩存不足，造成擁塞。

▲TCP Incast流量模型

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

為了實現端到端的無損轉發，避免因為交換機中的Buffer緩沖區溢出而引發的數據包丟失，交換機必須引入其他機制，如流量控制，通過對鏈路上流量的控制，減少對交換機Buffer的壓力，來規避丟包的產生。

二、PFC如何實現流控

IEEE 802.1Qbb（Priority-based Flow Control，基于優先級的流量控制）簡稱PFC，是IEEE數據中心橋接（Data Center Bridge）協議族中的一個技術，是流量控制的增強版。

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

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

▲端口產生擁塞的打流模型

• 當F0/1在轉發報文出現擁塞時，交換機B會在端口緩沖區中排隊報文，當擁塞超過一定閾值時，端口G0/2向G0/1發PAUSE幀，通知G0/1暫時停止發送報文。

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

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

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

▲PFC協議報文結構解析

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

•  RoCEv1：

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

▲二層以太網幀VLAN頭部結構

•  RoCEv2：

這個協議是將RDMA數據段先封裝到UDP數據段內，加上UDP頭部，再加上IP頭部，最后再加上以太網頭部，屬于三層數據包。對它進行分類，既可以使用以太網VLAN中的PCP域，也可以使用IP頭部的DSCP域。

▲三層IP報文頭部結構

簡單來說，在二層網絡的情況下，PFC使用VLAN中的PCP位來對數據流進行區分，在三層網絡的情況下，PFC既可以使用PCP、也可以使用DSCP，使得不同數據流可以享受到獨立的流控制。當下數據中心因多采用三層網絡，因此使用DSCP比PCP更具有優勢。

三、PFC死鎖

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

PFC死鎖，是指當多個交換機之間因微環路等原因同時出現擁塞,各自端口緩存消耗超過閾值，而又相互等待對方釋放資源，從而導致所有交換機上的數據流都永久阻塞的一種網絡狀態。

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

但在特殊情況下，例如發生鏈路故障或設備故障時，BGP路由重新收斂期間可能會出現短暫環路，會導致出現一個循環的緩沖區依賴。如下圖所示，當4臺交換機都達到XOFF水線，都同時向對端發送PAUSE幀，這個時候該拓撲中所有交換機都處于停流狀態，由于PFC的反壓效應，整個網絡或部分網絡的吞吐量將變為零。

▲PFC死鎖示意圖

即使在無環網絡中形成短暫環路時，也可能發生死鎖。雖然經過修復短暫環路會很快消失，但它們造成的死鎖不是暫時的，即便重啟服務器中斷流量，死鎖也不能自動恢復。

為了解除死鎖狀態，一方面是要杜絕數據中心里的環路產生，另一方面則可以通過網絡設備的死鎖檢測功能來實現。銳捷RG-S6510-48VS8CQ上的Deadlock檢測功能，可以檢測到出現Deadlock狀態后的一段時間內，忽略收到的PFC幀，同時對buffer中的報文執行轉發或丟棄的操作（默認是轉發）。

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

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

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

四、利用ECN實現端到端的擁塞控制

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

RoCEv2標準定義了RoCEv2擁塞管理(RCM)。啟用了ECN之后，網絡設備一旦檢測到RoCEv2流量出現了擁塞，會在數據包的IP頭部ECN域進行標記。

▲IP報文頭ECN字段結構

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

▲ECN交互過程示意圖

五、ECN交互過程

① 發送端發送的IP報文標記支持ECN（10）；

② 交換機在隊列擁塞情況下收到該報文，將ECN字段修改為11并發出，網絡中其他交換機將透傳；

③ 接收端收到ECN為11的報文發現擁塞，正常處理該報文；

④ 接收端產生擁塞通告，每ms級發送一個CNP（Congestion Notification Packets）報文，ECN字段為01，要求報文不能被網絡丟棄。接收端對多個被ECN標記為同一個QP的數據包發送一個單個CNP即可（格式規定見下圖）；

⑤ 交換機收到CNP報文后正常轉發該報文；

⑥ 發送端收到ECN標記為01的CNP報文解析后對相應的流（對應啟用ECN的QP）應用速率限制算法。

RoCEv2的CNP包格式如下：

▲CNP報文結構

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

總結

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

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

在數據中心網絡中應用RDMA，不僅要解決轉發面的無損網絡需求，還要關注精細化運維，才能應對延遲和丟包敏感的網絡環境。有關MMU的精細化管理技術以及基于INT的網絡可視化技術可參考往期文章。

本期作者：趙爽

銳捷網絡互聯網系統部行業咨詢

感謝您關注銳捷網絡技術干貨文章！現誠邀您參與調研，您寶貴的意見和建議將幫助我們在技術探索與分享上持續精進。點擊下方鏈接參與調研：

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