如何為RDMA構建無損網(wǎng)絡

【RDMA】本文主要介紹為什么我們需要RDMA？為什么我們需要無損網(wǎng)絡？這些先進的技術究竟能給我們帶來什么好處？并詳細介紹如何為RDMA構建無損網(wǎng)絡。

發(fā)布時間：2018-09-12
點擊量：
點贊：

分享至

我想評論

我們?yōu)槭裁葱枰獰o損網(wǎng)絡

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

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

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

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

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

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

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

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

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

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

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

收斂比

進行數(shù)據(jù)中心網(wǎng)絡架構設計時，從成本和收益兩方面來考慮，多數(shù)會采取非對稱帶寬設計，即上下行鏈路帶寬不一致，交換機的收斂比簡單說就是總的輸入帶寬除以總的輸出帶寬。以銳捷萬兆交換機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。

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

ECMP

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

TCP Incast

TCP Incast是Many-to-One的通信模式，在數(shù)據(jù)中心云化的大趨勢下這種通信模式常常發(fā)生，尤其是那些以Scale-Out方式實現(xiàn)的分布式存儲和計算應用，包括Hadoop、MapReduce、HDFS等。
例如，當一個Parent Server向一組節(jié)點（服務器集群或存儲集群）發(fā)起一個請求時，集群中的節(jié)點都會同時收到該請求，并且?guī)缀跬瑫r做出響應，很多節(jié)點同時向一臺機器（Parent Server）發(fā)送TCP數(shù)據(jù)流，從而產(chǎn)生了一個“微突發(fā)流”，使得交換機上連接Parent Server的出端口緩存不足，造成擁塞。

▲TCP Incast流量模型

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

為了實現(xià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é)議族中的一個技術，是流量控制的增強版。

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

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

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

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

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

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

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

▲PFC協(xié)議報文結構解析

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

RoCEv1

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

▲二層以太網(wǎng)幀VLAN頭部結構

RoCEv2

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

▲三層IP報文頭部結構

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

PFC死鎖

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

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

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

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

▲PFC死鎖示意圖

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

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

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

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

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

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

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

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

▲IP報文頭ECN字段結構

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

ECN交互過程

▲ECN交互過程示意圖

• 發(fā)送端發(fā)送的IP報文標記支持ECN（10）；

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

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

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

• 交換機收到CNP報文后正常轉發(fā)該報文；

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

RoCEv2的CNP包格式如下：

▲CNP報文結構

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

總結

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

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

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

銳捷25G/100G數(shù)據(jù)中心解決方案

即將亮相2018杭州 · 云棲大會，等你來撩！