技術盛宴 | 數據中心網絡等價多路徑(ECMP)技術應用研究

　　目前數據中心網絡廣泛應用的Fabric架構中會應用大量的ECMP(Equal-Cost Multipath Routing，簡寫ECMP),其優點主要體現在可以提高網絡冗餘性和可靠性，同時也提高了網絡資源利用率;大量的ECMP鏈路在特定場景下運行過程中會引發其他問題。例如，當某條ECMP鏈路斷開後，ECMP組內所有鏈路流量都會被重新HASH，在有狀態的伺服器區域(如LVS)中將導致雪崩現象，又或者會出現多級ECMP的HASH極化導致鏈路擁塞等。本文將結合ECMP運行原理針對以上問題進行分析，並探討如何優化ECMP的運用。

　　等價多路徑路由

　　等價多路徑路由，即存在多條到達同一個目的地址的相等開銷的路徑。當設備支持等價路由時，發往該目的IP 或者目的網段的三層轉發流量就可以通過不同的路徑分擔，實現網絡鏈路的負載均衡，並在鏈路出現故障時，實現快速切換。

　　ECMP實現流程：

　　圖例1：ECMP流程圖

　　步驟一：HASH因子的選擇

　　首先數據報文轉發查詢路由表，確認存在多個等價路由，再根據當前用戶配置的流量均衡算法，提取參與 HASH 計算的關鍵欄位，即HASH因子。ECMP 流量均衡可選擇的 HASH 因子如下表：

　　圖表1：流量均衡模式對應HASH因子表

　　註：因ECMP為三層轉發，即使配置基於源MAC、目的MAC或者源目MAC作為HASH因子，系統也會默認選擇源IP作為HASH因子。另外,在選擇提取HASH因子為目的IP時ECMP會默認選擇源目IP作為HASH因子。

　　步驟二：HASH計算

　　基於步驟一提取的 HASH 因子，根據 HASH 算法進行計算，得出相應的 HASH lb-key(load-balance key)。 ECMP 流量均衡支持的 HASH 算法包括異或(XOR)、CRC、 CRC+擾碼等。

　　HASH算法有很多種，我們以XOR算法為例做出說明。XOR運算法則為兩個輸入比特位相同時為0，不同則為1。HASH因子不同，運算結果也不盡相同。

　　1、 HASH因子為IP address source(SIP)：

　　a) SIP XOR 0 ，得出一個32bit的數值a

　　b) 將數值a再進行高16bit和低16bit做XOR計算得出16bit數值b

　　c) 數值b的15~12bit與11~8bit再做XOR計算，得出4bit數值c

　　d) 數值c替換數值b的11~8bit，得出數值d

　　e) 數值d截取低位10bit即為lb key

　　2、 HASH因子為SIP+DIP/DIP：

　　a) DIP XOR SIP ,得出一個32bit的數值a

　　b) 剩餘運算步驟與SIP運算一致

　　3、 HASH因子為SIP+DIP+SP+DP：

　　a) SIP XOR DIP得到32bit的數值a

　　b) 數值a的低16bit XOR SP 得到32bit的數值b

　　c) 數值b的低 16bit XOR DP 得到 32bit 的數值c

　　d) 數值c的高16bit XOR 低16bit得到16bit的數值d

　　e) 數值d的15～12bit XOR 11～8bit，得到4bit的數值e

　　f) 數值e替換數值d的11～8bit，得出數值f

　　g) 數值f截取低10bit，即為lb-key

　　步驟三：確認轉發下一跳

　　數據報文經過路由查表後找到對應ECMP 基值(base-ptr),根據 HASH 因子通過 HASH 算法計算獲得 HASH lb-key 後，進行 ECMP 下一跳鏈路數(Member-count)求餘計算，再與ECMP基值進行加法運算得出轉發下一跳index，即確定了下一跳轉發路由。

　　計算公式：Next-hop =(lb-key % Member-count)+ base-ptr

　　上述流程為ECMP常規轉發流程，但在特定網絡環境下運行過程中就會出現問題，接下來繼續分析數據中心網絡中ECMP遇到的2個常見問題。

　　問題一 單鏈路故障導致ECMP組所有數據流被重新HASH計算

　　當Leaf交換機發送6條數據流到LVS伺服器，Leaf先進行HASH運算負載均衡到每一臺LVS伺服器上，正常流量轉發如圖例2所示：

　　圖例2：ECMP轉發圖

　　當某臺LVS伺服器網卡出現故障或者鏈路出現故障，Leaf交換機會將ECMP組內數據流將重新HASH計算，再進行負載均衡到剩餘有效鏈路上，進而導致TCP會話斷開，發生雪崩現象，例如一些支付類業務，同一個用戶的一次支付過程會調用多個業務服務，業務側要求一次支付的過程都落在同一個處理伺服器上，當出現單條鏈路故障後不僅影響該鏈路所在LVS承載的用戶，同時還影響該ECMP組下其他LVS承載的用戶，如圖例3所示：

　　圖例3：故障後ECMP轉發圖

　　優化方案：

　　為避免單臺LVS伺服器故障或者單鏈路故障導致整個ECMP組內流量全部被重新HASH，ECMP可採用彈性HASH算法來優化。採用彈性HASH算法後，僅將故障鏈路的流量重新HASH到其他活躍鏈路上，而非故障鏈路上的數據流則無需改變下一跳。實現效果如圖例4所示：

　　圖例4：ECMP彈性HASH算法

　　彈性HASH具體實現原理：

　　圖例5：彈性HASH流程

　　在交換機上生成一張索引表(RH Flow Set Table)，用於存放相關索引值對應下一跳路由地址。數據報文經過路由查表後找到對應ECMP 基值，提取HASH因子進行HASH運算，在HASH Key與ECMP數量取餘數時無論是否出現故障鏈路，均以最初數量進行取餘運算，因此運算結果一致，非故障鏈路數據依然按照原有鏈路轉發。如下圖中，鏈路3故障後軟體CPU將及時更新RH flow table，將失效鏈路用正常鏈路均勻替換。

　　圖例6：彈性HASH索引表替換示意圖

　　問題二 HASH極化問題

　　如圖例7所示，在Leaf設備和Spine設備均採用上聯鏈路數為偶數且ECMP算法及HASH因子一致的情況下，數據流在Leaf設備上經過一次HASH計算，將數據流負載分擔到兩臺Spine上，均衡後效果為數據流1、2、3轉發至Spine-1，數據流4、5、6轉發至Spine-2，Spine再進行HASH計算負載分擔到兩臺DCI核心上，因在Spine層採用的HASH算法與Leaf的HASH算法一致，最終Spine-1的數據流1、2、3均轉發至DCI-1上，未負載分擔到DCI-2上任何數據流，而Spine-2的數據流4、5、6均轉發至DCI-2上，未負載分擔到DCI-1上任何數據流，同理Leaf-2發送的數據流也是如此，進而產生HASH極化問題，導致SPINE和DCI之間鏈路有一條空閒，極大的浪費了網絡資源，甚至會導致流量擁塞。

　　圖例7：HASH極化

　　優化方案：

　　l 同廠商Leaf設備和Spine設備均採用相同上聯鏈路數場景下，應避免在相鄰的兩臺設備上使用相同的負載均衡算法;

　　l 設備在運行HASH計算時，除傳統的五元組外，可以增添擾動因子，避免HASH計算結果相同。

　　HASH擾動的計算過程中HASH因子仍然正常提取，再增加用戶自定義隨機擾動因子，經過HASH算法運算時，不同交換機HASH計算結果就將不一致，以達到避免HASH極化現象的出現。

　　圖例8：HASH擾動計算過程

　　動態負載均衡技術實現

　　在數據中心網絡中，突發流量多，並且存在大象流和老鼠流並存現象，本文所描述的基於數據流五元組的HASH算法，並結合HASH擾動因子技術實現流量負載均衡，但無法實現大象流和老鼠流並存的網絡中多鏈路之間的流量負載均衡。

　　銳捷網絡新一代25G數據中心網絡解決方案中所採用的最新晶片，已能夠支持DLB(Dynamic load balance，動態鏈路負載)特性，可基於流量負載狀態實現動態的HASH負載均衡。具體實現方法是交換機為每條進行負載均衡的數據流創建一個流表，基於流表記錄流量統計信息，根據流量統計信息動態調整鏈路負載均衡。

　　感謝您關注銳捷網絡技術乾貨文章!現誠邀您參與有獎調研，您寶貴的意見和建議將幫助我們在技術探索與分享上持續精進。