溫馨提示×
您好，登錄后才能下訂單哦！
點擊 登錄注冊 即表示同意《億速云用戶服務條款》
您好，登錄后才能下訂單哦！
本文轉載自UCloud技術公眾號，URL：https://mp.weixin.qq.com/s/GDxWXZAv0_SXv3PmTfnHpg
這篇文章給大家分享的是有關計高性能RoCE網絡的內容。小編覺得挺實用的，因此分享給大家做個參考。一起跟隨小編過來看看吧。
普通的內網進行數據包交互時，通常會使用系統級的TCP/IP協議棧或者是DPDK技術，這兩種方案都是依靠軟件進行協議棧解封裝的，對系統的CPU有不少消耗。而有一種方案：RDMA，可以直接使用網卡進行協議棧解封裝，無需消耗系統CPU，能有效降低數據處理的延時。
RDMA并沒有規定全部的協議棧，比如物理鏈路層、網絡層、傳輸層每個字段長什么樣，如何使用，但對無損網絡有相當高的要求：
– 不輕易丟包，重傳帶來的延時非常大。
– 吞吐量巨大，跑滿最好。
– 延時越低越好，100us都嫌長。
依據上述要求，主流的網絡方案有三種：
圖：主流的RDMA網絡方案
① InfiniBand： 該方案重新設計了物理鏈路層、網絡層、傳輸層，是RDMA最初的部署方案，所以要使用專用的InfiniBand交換機做物理隔離的專網，成本較大，但性能表現最優；
② iWARP： 該方案的目的是讓主流的以太網支持RDMA，將InfiniBand移植到TCP/IP協議棧，使用TCP協議保證無丟包，但缺點在于TCP開銷較大，且算法復雜，所以性能表現較差；
③ RoCEv2： 該方案的目的也是讓主流的以太網支持RDMA（RoCEv1版本已很少提及了）。網絡側使用PFC保證擁塞時不丟包，網卡側又使用DCQCN的擁塞控制算法進一步減緩擁塞（該擁塞算法需要網絡側支持ECN標記），傳統的以太網經過PFC和ECN的加持進化成為無損以太網，在無損以太網上運行RDMA性能大大增強。
RoCEv2（后文簡稱RoCE）方案的成熟案例較多，我們也選用了該方案進行研究。但RoCE方案仍存在一些問題，如PFC壓制的不公平性、PFC傳遞帶來的死鎖風險、過多的調參、ECN標記的滯后性（ECN概率標記是軟件輪詢機制）等，是需要我們解決完善的。
要把RoCE搬到經典的數據中心網絡上，這可不是一件容易的事兒。
當前數據中心是常見的CLOS架構，LCS是匯聚交換機，LAS是TOR交換機。如果RoCE直接運行在這上面，問題是顯而易見的：例如出現Incast事件時，轉發不了的報文會被存放在交換機緩存中，但緩存也不是無限大的，如果存滿了，這個數據包就丟掉了，很明顯這種丟包頻率肯定不能被RDMA所接受。
圖：CLOS架構示意
上面只是舉了一個簡單的例子，實際上出現的問題要更復雜一些。在設計之前，需要先明確好我們的目標是什么，做到有的放矢。
簡單來講我們的目標就是：
– 在各種流量模型下，網絡帶寬要能跑滿；
– 緩存使用要盡可能低；
– 極限情況下緩存使用滿了也不能丟包。
總結來說，為了讓RoCE跑在已有的網絡上，我們需要從三個方面下手：
① QOS設計：指隊列、調度、整形等一系列的轉發動作，相對獨立。
② 無損設計：是RDMA的要求之一，使用PFC技術實現。無損是一種基本保障，含義是在最擁塞的情況下也能保證其可用性，讓上層應用可以放心發送數據，不必擔心丟包的風險（所以說PFC并不是降速的手段）。
③ 擁塞控制設計：使用DCQCN技術實現。擁塞控制是滿足基本保障前提下的進一步優化，含義是在開始擁塞的時候，就告知服務器兩端，使其從源端開始降速，從根本上解決問題。
補充一點擁塞帶來的壞處：當出現擁塞后，必然要使用緩存，使用緩存后雖然不丟包了，但是帶來的后果是延遲上升，而且吞吐也不能再增加一絲一毫。網絡中擁塞點有很多，每一跳都可能成為擁塞點，在上圖的網絡中，最多會有3個擁塞點。
緩存的使用能帶來多少延時？
我們按25Gbps來算，緩存25Mb的數據，大約需要1ms的時間才能發送完畢，25Mb也僅僅是3.1MB，而常見的Broadcom Trident 3芯片有32MB的緩存。
有了這三個方面的認識，我們就可以化繁為簡，逐一破解。
QOS的設計，無非是入隊、調度、監管和整形。
入隊方式可以依據DSCP、TOS、COS等標記，然后信任某種標記入隊，也可以選擇使用策略抓取其它報文特征入隊。我們最終選擇的策略是：在IDC邊界處，使用報文特征抓取入隊，并重寫DSCP，IDC內部僅根據DSCP入隊（IDC內部減少策略使用，滿足高速轉發即可）。這樣，既能保證DSCP標記的可信任，又能減輕IDC內部的策略復雜度。根據這個思路，我們分別設置對應策略：
– 對ToR下行端口與Border上行端口： 抓取特定報文，進入特定隊列。
– 對其余設備和端口設置：信任DSCP，按映射入隊。
用圖表表達即：
■ IDC邊界入隊
次序
Match
Action
1
udp_dport==4791 &&
dscp==48
入隊列6
2
udp_dport==4791 &&
dscp==46
入隊列5
其他
其他
修改dscp為預定義
*這是已有的標記策略，我們IDC內部為業務進行分類，并標記特定的DSCP。
*其中次序1、2只在RoCE網絡的ToR部署。
■ IDC內部DSCP映射
DSCP
隊列
48
6
46
5
其他
2…
下面該聊聊調度設計了，調度的對象是緩存中的數據，也就是說，調度是僅在擁塞時才生效的，而且調度生效后，影響的將是各隊列的流量大小。
帶著以上的認識，我們開始調度設計。在一般的RoCE網絡中，使用的有如下隊列（或流量）：
① 協議信令類，目前來看只有CNP流量；（其它協議均不跨跳，所以不考慮）
② RoCE流量；
③ 業務/管理流量。
這三大類流量，還可以繼續分小類。按照ETC所推薦的調度模型，我們選擇了SP+WDRR的調度方式，即：1類流量絕對優先，在緩存積壓的時候優先調度，直到隊列為空。2類和3類流量次優，兩者之間按照WDRR調度，權重值可以靈活定義。這樣就能保證CNP報文在3us內轉發給流量源站（沒有擁塞的網絡單跳的延時在1us以內）。
以上調度設計中有個漏洞：如果隊列6的流量過大，可能會將低優先級的隊列餓死（即長時間得不到調度），雖然理論上隊列6的流量一般都在幾十~幾百Mbps，但仍要提防服務器惡意***行為。于是，我們將SP的隊列限制其隊列使用帶寬。這個便是所謂的監管和整形了。
RoCE的流量需要保證運行在無損隊列中，無損隊列使用了PFC技術，能針對某一隊列發送Pause幀，迫使上游停流。
在博通的XGS系列芯片中，有一塊緩存管理單元MMU（簡稱緩存），存放已收到但沒轉發走的報文，并給入口和出口都計數：“0/1的入口和0/2的出口，都用了1個cell”（cell是緩存資源的最小單位）。
緩存會給每個入口和出口設置一個上限，超過這個上限就不能再使用cell緩存報文了。上限以下還畫了很多其它的水線，同時對每一個出口和入口進行進一步細分，可以按照隊列進行統計限額其中入方向。入方向上，細分了PG-Guaranteed大小、PG-Share大小、Headroom大小；出方向上，細分了Queue-Guaranteed大小，Queue-Share大小（如下圖所示，這里我們不考慮端口，只考慮隊列）。
圖：隊列入方向與出方向示意
緩存使用的時候，總是從下往上依次申請使用，所以更喜歡把這些區塊大小稱之為“水線”，當“某區塊”都使用完畢，就稱之為“緩存水位”到達了“某水線”。例如：當PG-Share區塊使用完畢，就稱之為，入口緩存水位已經到達PG-Share水線。如果所有區塊用完就產生丟包了，稱為no buffer丟包。
每一塊大小都有其特殊用處，先簡單看下其作用，后面再探討下無損隊列中的這5個水線應該如何設置。
?PG-Guaranteed和Queue-Guaranteed是保證緩存，這部分是獨享的，即使不用，別的隊列也不能搶占使用。
?PG-Share和Queue-Share使用的是共享緩存，因為動態水線的緣故，它們的大小不固定，如果很多隊列都在用，那平分一下，每個隊列的水線就都很小。另外，PG-Share還有另一個重要的作用：PFC發送的臨界點，也稱為xoff水線，只要到達該水線，PFC就會從這個口發出去，回落一些后，才恢復正常。
?Headroom是一個特殊的水線，只有在無損隊列中才能發揮其作用。設想一下，PFC發出去以后，流量真的能瞬間停下來么？答案是不能的！因為線纜中還有一部分數據，而且七七八八的轉發處理時間也要算進去。所以Headroom空間就是用來做這個的。
**
講完了基本原理，回過頭來看網絡設計。先看PG-Guaranteed和Queue-Guaranteed水線，這倆水線與“無損隊列”關系不大，保證緩存的作用只是滿足交換機基本的存儲轉發功能，所以配置為一個數據包大小即可。那我們按照最差的情況來算，即MTU=9216的巨型幀。
但實際上我們不必為此發愁，因為動態水線的緣故，共享緩存中總會有剩余的緩存以供使用，所以保持原廠的默認配置即可。
2、Queue-Share
接下來是Queue-Share水線。在無損隊列中，我們希望在緩存丟包前，能觸發PFC進行反壓，所以在任何情況下，都應該入口PG-Share先到達水線，出口Queue-Share永遠不能到達水線（PG-Share到達會發PFC，Queue-Share到達會丟包）。
之前講過，MMU記賬是出口入口各記一筆，這樣來看，最差情況應該是多打一（出口的帳全記在一個隊列上，入口的帳會均攤到不同隊列中）。為了讓出口水線永遠不會到達，索性將出口水線配置為無限大好了，事實證明這樣做也沒有問題，因為入口的PG-Share是動態水線，總能在Buffer破產前觸發該水線。
這樣一來，Queue-Share好像已經搞定了，其實不然，如果TCP流量參與進來混跑呢？這問題可就嚴重了，TCP的Lossy隊列會吃掉大量緩存，所以Lossy隊列中，對應的Queue-Share水線也應當限制一下。
PG-Share水線只要配置為動態水線即可，大小可以隨意調節，都不會出太大問題的，但需要滿足一個不等式：(PG-Share + PG-Guarantee + Headroom) * [入口個數]≤ Queue-Share + Queue-Guarantee
該公式描述的是一個端口多打一的場景。入口個數根據實際情況選取一個較大值（拿ToR來看，最差情況是39打1，32個25G下行，8個100G上行）。
這里的PG-Share是動態水線，動態水線用一個簡潔的公式即可表達：PG-Share = [剩余Buffer] * α
這里的α是縮放因子，用戶可自由調節。可以看出，縮放因子決定了PG-Share水線的大小。依據上面等式，我們只要將Queue-Share水線設置為靜態最大、PG-Share設置為動態即可，入口的縮放因子α可隨意。當然入口α也不能設置太小，在端口少打多的情況下，由于入口的水位很低，導致均攤到每個出口時，出口的水位更低！出口的水位過低時，會發現已有的ECN配置不再生效（例如：可能出口的水位還到不了Kmax的一半）。在我們的經驗看來，無損隊列中PG-Share的α，配置1/8，1/4，1/2，1都可以，具體大小還要聯合擁塞設計中ECN參數來決定。
Headroom水線很重要，但可以通過實驗+推導的方式得出合理的配置，先來看一個等式：[Headroom大小] = [PFC構造到停流的時間] * [端口速率] / [64字節小包占用的比特數]
使用64字節小包計算，是因為小包對緩存的使用率最低，單個Cell有200多字節，但只能被一個報文獨享。其中，只有[PFC構造到停流的時間]是需要進一步分解的：T = Tm1 +Tr1 + Tm2 +Tr2* Tm1：下游PG檢測到xoff用完，到構造PFC幀發出的時間。
* Tr1：PFC幀從下游發往上游的時間。
* Tm2：對端收到PFC幀，到隊列停止的時間。
* Tr2：隊列停止后，線纜中報文傳輸的時間。
可以看出，這四個時間中，只有線纜長度是變量，繼續化簡后可以得出：[Headroom大小] = (Tm1 + Tm2 +2 * [線纜長度] / [信號傳播速度]) * [端口速率] / [64字節小包占用的比特數])
這里面Tm1 + Tm2 是常數，可以實驗測得，剩余的都是已知量了。最后根據公式就可以算得100G口，100M光纖下，H = 408 cell；25G口，15M AOC下，H = 98 cell。當然，真正使用的時候，還要再冗余一點，畢竟這是臨界值。
談到PFC就不得不提一下死鎖，死鎖危害極大，而且其傳遞性會迅速擴散到整個網絡，以至于整個網絡的無損隊列全部停流。死鎖的研究很多，其中較詳細的是微軟的一篇論文《Deadlocks in Datacenter Networks: Why Do They Form, and How to Avoid Them》。
死鎖產生的一個必要條件是CBD（環狀緩存依賴），在我們的組網環境中，是典型的CLOS組網，所以在穩定狀態下不會存在CBD，也沒有死鎖風險。而且整個POD內部路由不做過濾，明細互知，匯聚采用4臺~8臺冗余，即使出現兩點故障，收斂后的拓撲也不會存在CBD，即不會存在死鎖風險。
圖：CBD和死鎖
至此，我們已經解決穩定狀態下的死鎖了，但還要考慮一點：收斂過程中，是否存在CBD？其實仔細分析一下還是會存在的，我們考慮了很多收斂場景，確實會有部分場景下，存在微環路。有微環路就一定有CBD。事實證明，我們也真實地模擬出了微環路導致的死鎖。
死鎖問題總是要解決的。我們使用三種方法：
1、針對各種微環路場景，通過設計網絡協議，控制收斂的現先后關系，避免出現微環路出現。
2. 對于其它未知的死鎖風險，使用交換機的死鎖檢測功能，釋放緩存（釋放緩存會產生丟包，但收斂過程本身就有亂序/丟包情況）。
3. 將PG-Share的水線適當拉高，盡量使用DCQCN擁塞控制來壓制流量。
網絡擁塞控制是一個很復雜的課題，這里只講一些基本的設計思路。
RoCE使用的擁塞控制算法是DCQCN，_《Congestion Control for Large-Scale RDMA Deployments》_這篇論文很詳細地描述了該算法。
這里先簡單的描述下這個算法：維護這個算法的節點是服務器，也就是流量的兩端，中間的交換機作為傳輸節點，通告是否擁塞。發送方叫Reaction Point，簡稱RP；接收方叫Notification Point，簡稱NP；中間交換機叫 Congestion Point，簡稱CP。發送方（RP）以最高速開始發送，沿途過程中如果有擁塞，會被標記ECN顯示擁塞，當這個被標記的報文轉發到接收方（NP）的時候，接收方（NP）會回應一個CNP報文，通知發送方（RP）。收到CNP報文的發送方（RP），就會開始降速。當發送方沒有收到CNP報文時，就開始又提速了。
上述過程就是DCQCN的基本思路。雖然整個算法十分復雜，但都是圍繞這個基本思路，繼續完善算法細節（下圖分別是NP的狀態機和RP的算法）。可調參數也十分眾多，比如降速要降低多少？提速效率是否積極？網絡擁塞度如何維護？擁塞度更新周期多久？CNP報文的敏感度多大？這都是問題，需要對流量建模后找出合理參數。
圖：接收方
圖：發送方
DCQCN算法中，對RP、NP和CP都有很多參數可以調節。RP和NP節點在服務器上，準確來說應該是在網卡上，網卡初始化的參數已經為最優值，無需再進行調整，這樣就剩CP上的參數需要調整了。
CP上有三個參數其實就是WRED-ECN的那三個參數，分別是Kmin，Kmax，Pmax，這三者的關系，可以用下圖來表示。橫軸是出向隊列長度，縱軸是報文被標記的概率。從圖中可以看到，在隊列長度超過Kmax時，標記概率出現一個跳變，從Pmax直接到達100%。
根據上面的理論分析，我們可以通過實驗證實和試錯的方法一步步找到最優解。
現在設想一下：在一個擁塞場景中，當出口隊列長度小于Kmin時，不會被標記，出口隊列長度可能會穩步增長，當隊列長度超過Kmin時，DCQCN才開始降速。
所以Kmin的大小決定了RoCE網絡的基礎延時，這些緩存中的報文是發送者發出，但未被接收者確認的報文，我們稱之為inflight bytes，約等于延時帶寬積。所以，Kmin的配置規范為小于期望的延時帶寬積。有了這個理論基礎后，實踐測得理論符合實際，還可以根據測得的延時進一步調整該數值。
我們用同樣的思路來思考Kmax，承接剛剛的思路，那就是：Kmax的配置規范為小于或等于能容忍的延時帶寬積。但這次不再這么簡單了，因為Kmax還決定了圖中的斜率。同樣決定斜率的還有Pmax，在討論Kmax和Pmax前，我們不得不先介紹下整個ECN的理想與現實。
理想狀態下，標記概率在定義域Kmin~Kmax內的變化是連續的，而且，隊列的長度是準確的。但事與愿違，博通芯片SDK使用軟件輪詢的方式測得隊列長度，而且將此刻的隊列長度與歷史值做指數平均，并依此計算標記概率。軟件輪詢帶來的結果是，標記概率在定義域Kmin~Kmax內的變化是不連續的，其次，指數平均值會讓測得的隊列長度是滯后的（當然指數平均也帶來了好處，這里不展開）。
這件事帶給我們的影響就是，理論推導的Pmax，甚至Kmin、Kmax都被推翻，請繼續往下看：理想狀態下，一個25G端口、單QP會話下，最大的有效Pmax是多少？
根據DCQCN中NP的算法，50us內收到多個CE標記包，會被認為只有一個有效包，所以最高的CE標記速率應該為20000個包每秒（即1個包每50微秒），依此，我們算得最高有效Pmax，即是設置的Pmax值，如下表所示：我們假設一個25G端口、只有一個QP會話，此時最高有效Pmax是多少？可以根據表格中第4、5列計算出最后一列最高有效Pmax的值。
再回到現實，我們按照推導的數據對表格最后一行進行驗證。
對端口限速模擬擁塞，測得穩定時RoCE流量pps=2,227,007，然后選取一組ECN配置：Kmin=1cell，Kmax=1400cell，Pmax=1%，理論上來說Pmax已經超出最高有效的值了，理論上即使在擁塞時，出口水位也不可能達到1400cell，所以再設置一個監控項，監控出口水位有沒有超過1400cell（觸發式告警，并非輪詢，所以不會存在采集不到的情況）這是第一個實驗。
作為對比，第二個實驗使用另一組ECN配置，Kmin=800cell，Kmax=1400cell，Pmax=1%，按照之前分析，這一組配置下，出口水位也不會超過1400cell，因為在1400cell水位時，Pmax=1已經超過最高有效標記概率了。
可是實驗結果并不符合預期，第一個實驗沒有觸發告警，通過；第二個卻觸發告警了。這就意味著在某些時刻，緩存水位超過1400cell了！水位是波動的，并沒有穩定在某個值！我們大膽猜測其中原因：從緩存隊列積壓，到得到緩解，這其中有太多地方消耗了時間：隊列長度的輪詢、指數平均算法、CNP的生成與轉發，甚至于降速后線纜中的數據傳輸等等。
為解決這一難題，我們另辟蹊徑，選擇了另外一條路：首先制定了幾個小目標，然后通過大量的實驗來摸索出驗證一套安全可靠的配置。這個方法雖然更野蠻，但很有效。
? 小目標1：服務器端口吞吐量要在95%以上；
? 小目標2：所有流量場景下交換機99%的時間里PFC發送速率不得高于5pps；
? 小目標3：任意場景下服務器端到端延時不得高于80us（90%場景下低于40us）。
對于流量模型，我們設計篩選后，選用了50余種流量，最終我們得到了同時滿足這三個小目標的合理參數。
不得不說，DCQCN很難玩轉，參數眾多且互有聯系，這里也只是提供一些實踐規律，歡迎一同深入探討。
關于高性能RoCE網絡的設計方案就分享到這里了，希望以上內容可以對大家有一定的幫助，可以學到更多知識。如果覺得文章不錯，可以把它分享出去讓更多的人看到。
免責聲明：本站發布的內容（圖片、視頻和文字）以原創、轉載和分享為主，文章觀點不代表本網站立場，如果涉及侵權請聯系站長郵箱：is@yisu.com進行舉報，并提供相關證據，一經查實，將立刻刪除涉嫌侵權內容。
