【第三十四期】大型數(shù)據(jù)中心網(wǎng)絡路由協(xié)議選擇

【網(wǎng)絡路由協(xié)議選擇】如何為數(shù)據(jù)中心三層組網(wǎng)選擇合適的路由協(xié)議？本文聚焦于大型數(shù)據(jù)中心場景，力圖給出確切的答案。

#互聯(lián)網(wǎng)

發(fā)布時間：2019-06-12
點擊量：
點贊：

分享至

我想評論

數(shù)據(jù)中心網(wǎng)絡互聯(lián)技術

為了滿足數(shù)據(jù)中心虛擬機（Vm）、容器（Docker）之間大二層通信的需求，數(shù)據(jù)中心網(wǎng)絡發(fā)展歷程中出現(xiàn)了眾多依托網(wǎng)絡設備硬件實現(xiàn)的互聯(lián)組網(wǎng)技術——例如借鑒路由協(xié)議實現(xiàn)的大二層組網(wǎng)技術：多鏈接透明互聯(lián)（TRILL）、最短路徑橋接（SPB）；虛實結(jié)合的Overlay技術：可擴展虛擬局域網(wǎng)（VXLAN）、使用通用路由封裝的網(wǎng)絡虛擬化（NVGRE）等等。但由于技術的復雜性、設備能力的參差不齊，這些技術均沒有在網(wǎng)絡設備上得到大規(guī)模應用。

到今天，我們看到數(shù)據(jù)中心（IDC）網(wǎng)絡返璞歸真，與業(yè)務解耦，簡單、可靠成為核心訴求，數(shù)據(jù)中心只需要提供簡單、可靠的三層Underlay組網(wǎng)，二層Overlay網(wǎng)絡更多依賴主機側(cè)軟件或智能網(wǎng)卡實現(xiàn)。

那么問題來了，如何為數(shù)據(jù)中心三層組網(wǎng)選擇合適的路由協(xié)議？本文聚焦于大型數(shù)據(jù)中心場景，力圖給出確切的答案。

IDC網(wǎng)絡架構(gòu)演進

經(jīng)濟基礎決定上層建筑。同樣的，數(shù)據(jù)中心（物理）網(wǎng)絡架構(gòu)很大程度上決定了路由協(xié)議的規(guī)劃。關于架構(gòu)的設計，推薦閱讀《技術盛宴 | 互聯(lián)網(wǎng)數(shù)據(jù)中心網(wǎng)絡25G組網(wǎng)架構(gòu)設計》。本文對IDC網(wǎng)絡架構(gòu)僅做簡要介紹，目的在于理清基礎架構(gòu)與路由協(xié)議選擇的關系。

傳統(tǒng)數(shù)據(jù)中心網(wǎng)絡架構(gòu)

圖1：傳統(tǒng)數(shù)據(jù)中心網(wǎng)絡架構(gòu)（內(nèi)部，不含網(wǎng)關區(qū)）

圖1展示的是傳統(tǒng)數(shù)據(jù)中心的網(wǎng)絡架構(gòu)：

傳統(tǒng)IDC承載的大多是數(shù)據(jù)中心提供對外訪問的業(yè)務；

流量分布符合80/20模型，且以南北向為主，東西向流量小；

網(wǎng)絡架構(gòu)設計采用核心-匯聚-接入三級結(jié)構(gòu)，匯聚往下采用大二層組網(wǎng)，匯聚及核心橫向采用廠商私有虛擬化技術，保證可靠性；

流量瓶頸在出口，IDC內(nèi)部可以維持高收斂比（10:1甚至更大）。

近年來，隨著云計算、大數(shù)據(jù)等業(yè)務的興起，分布式計算、分布式存儲等技術開始在IDC內(nèi)部大規(guī)模部署。從網(wǎng)絡視角看，IDC內(nèi)部的東西向流量急劇上升，流量的80/20模型轉(zhuǎn)變成以東西向流量為主。

此時，傳統(tǒng)網(wǎng)絡架構(gòu)開始力所不逮，顯現(xiàn)出諸多弊端：

擴展能力差：網(wǎng)絡規(guī)模受限于核心交換機端口數(shù)量，無法平滑Scale-out(橫向擴展)；

收斂比過高：為南北向流量設計的流量模型，收斂模型呈三角型，越往上性能越低，東西向帶寬嚴重不足；

單控制面運維復雜：匯聚及核心的可靠性依賴于廠商的橫向虛擬化技術，虛擬化技術的單控制面存在明顯弊端，很難做到不中斷業(yè)務升級版本（ISSU ，In-Service Software Upgrade）。

Fabric網(wǎng)絡架構(gòu)

為解決傳統(tǒng)IDC網(wǎng)絡面臨的問題，一種新的組網(wǎng)技術：Fabric網(wǎng)絡架構(gòu)，開始慢慢興起。

Fabric一詞，網(wǎng)工同學都不陌生：基于CLOS架構(gòu)的機框式交換機，就是依賴于Fabric（交換網(wǎng)板）作為Line card（線卡）在設備內(nèi)部的轉(zhuǎn)發(fā)橋梁（如圖2）。

圖2：IDC網(wǎng)絡架構(gòu)設計——Network as A Fabric

而時下數(shù)據(jù)中心火熱的Fabric組網(wǎng)架構(gòu)，與CLOS交換機有異曲同工之妙。

Line card：作為輸入輸出源，匯集所有服務器的流量，可以等同于IDC的柜頂交換機（TOR）；

Fabric card：在中間層構(gòu)建的高速轉(zhuǎn)發(fā)通道，跨TOR流量通過Fabric進行高速轉(zhuǎn)發(fā)。

把圖2對折看，就是當下數(shù)據(jù)中心最流行的葉脊（Leaf-Spine）網(wǎng)絡架構(gòu)。

圖3：Leaf-Spine葉脊網(wǎng)絡架構(gòu)

Leaf-Spine的兩層結(jié)構(gòu)，即可構(gòu)成一個簡單的葉脊網(wǎng)絡。在IDC建設時，我們也會以最小交付單元（POD，Point Of Delivery）為單位進行網(wǎng)絡建設。當然，為了提升這種網(wǎng)絡架構(gòu)的Scale-out能力，一般會在POD之上增加一層，用于橫向連接各個數(shù)據(jù)中心POD，擴大整個數(shù)據(jù)中心集群的規(guī)模。

Leaf-Spine架構(gòu)因其強大的Scale-out能力、極高的可靠性、出色的可運維能力而備受推崇。知名的全球互聯(lián)網(wǎng)巨頭，基本都使用了這種組網(wǎng)架構(gòu)。

Fabric網(wǎng)絡架構(gòu)用什么路由協(xié)議？

圖4：利用Fabric構(gòu)建的大型數(shù)據(jù)中心網(wǎng)絡

Facebook在2014年開放了其數(shù)據(jù)中心網(wǎng)絡設計（從F4演進到F16，但基本架構(gòu)同圖4）：采用典型的Fabric網(wǎng)絡。那么Fabric網(wǎng)絡架構(gòu)使用哪種路由協(xié)議更合適呢？

在RFC 7938《Use of BGP for Routing in Large-Scale Data Centers》中，作者提出了使用邊界網(wǎng)關協(xié)議（BGP）作為數(shù)據(jù)中心內(nèi)唯一路由協(xié)議的觀點，并做了詳細的分析，有興趣的同學可以閱讀RFC原文。

結(jié)合這篇RFC，以及當前國內(nèi)外互聯(lián)網(wǎng)公司的采用BGP組網(wǎng)的實踐，我們分析下為什么BGP會更受青睞？

大型IDC網(wǎng)絡路由設計原則

路由設計作為數(shù)據(jù)中心網(wǎng)絡設計中非常重要的一環(huán)，其設計理念也需要和數(shù)據(jù)中心整體原則保持一致。有如下設計要點：

1、可擴展性

數(shù)據(jù)中心設計要點：大型互聯(lián)網(wǎng)公司單園區(qū)最大服務器規(guī)模已經(jīng)突破300K，很多大型園區(qū)服務器規(guī)模在20K到100K之間。數(shù)據(jù)中心網(wǎng)絡在設計之初就需要考慮平滑的Scale-out能力，能按POD進行數(shù)據(jù)中心網(wǎng)絡的交付（減少前期投入），并最終具備擴展到承載大規(guī)模、超大規(guī)模集群的能力。

路由協(xié)議設計要點：按照交換機和服務器數(shù)量1:20的比例（48口交換機，服務器雙歸網(wǎng)絡典型的比例），超大型數(shù)據(jù)中心運營的網(wǎng)絡設備數(shù)量是數(shù)以千計的。路由協(xié)議的設計需要考慮一致性，無論是初期的小規(guī)模，還是到上千萬元構(gòu)建的路由域，均能簡單好用，能快速傳播、收斂。

2、帶寬和流量模型

數(shù)據(jù)中心設計要點：數(shù)據(jù)中心東西向流量爆發(fā)式增長，傳統(tǒng)DC高收斂比模型已經(jīng)無法滿足東西向流量需求。新的網(wǎng)絡架構(gòu)中要盡可能地設計無收斂（Microsoft甚至部署了超速比網(wǎng)絡，即上行帶寬大于下行帶寬）。考慮到網(wǎng)絡建設的性價比，我們推薦部署每級收斂比1:1到3:1。

路由協(xié)議設計要點：對于Fabric網(wǎng)絡，低收斂主要是依賴上行多鏈路負載來實現(xiàn)（例如典型的25G TOR交換機RG-S6510-48VS8CQ，其下行帶寬48*25Gbps=1200Gbps，上行帶寬8*100Gbps=800Gbps，端口全利用的情況下，收斂比為1.5:1）。對于數(shù)據(jù)中心路由設計，非常重要的一點，是能簡單地在數(shù)據(jù)中心多鏈路之間實現(xiàn)等價多路徑路由（ECMP）。在正常情況下，ECMP多鏈路可以均勻分擔流量，鏈路新增或者剔除時，也能快速收斂而不影響現(xiàn)網(wǎng)業(yè)務。

3、CAPEX Minimization

數(shù)據(jù)中心設計要點：最大限度降低資本性支出。方法有：

盡量標準化網(wǎng)絡設備的軟硬件要求，基于統(tǒng)一架構(gòu)減少設備類型；

簡化網(wǎng)絡特性要求，降低研發(fā)成本和時間成本。

路由協(xié)議設計要點：采用成熟的，通用的路由協(xié)議，并且需要在主流型號上支持，覆蓋接入、核心、骨干設備。

4、OPEX Minimization

數(shù)據(jù)中心設計要點：最大限度降低運營成本。大型數(shù)據(jù)中心網(wǎng)絡的運營成本往往會比基礎設施的建設成本更高，減少運營成本也是架構(gòu)設計之初就必須考慮的問題。

路由協(xié)議設計要點：減少網(wǎng)絡中故障域的大小。

網(wǎng)絡故障時，路由收斂影響面小，收斂時間快；

整個數(shù)據(jù)中心只使用一種路由協(xié)議：更好地簡化運維，降低學習成本。運營知識庫也可以更容易積累，幫助快速定位問題，恢復故障。

大型IDC網(wǎng)絡路由協(xié)議選擇

1、路由協(xié)議需要具備的能力

圍繞前文分析的路由協(xié)議的設計要點，總結(jié)出大型IDC路由協(xié)議需要具備如下能力：

超大規(guī)模：考慮可擴展性，從建設之初到集群最終滿配，都使用同樣的協(xié)議組網(wǎng)，協(xié)議需要具備支撐橫向擴展到“超大規(guī)模”數(shù)據(jù)中心的能力；

簡單：選擇足夠簡單、成熟、通用的路由協(xié)議，使用更少的軟件特性，從而引入更多可供選擇的設備廠商；

單一：數(shù)據(jù)中心盡量使用單一路由協(xié)議，降低復雜度，減少學習成本，也利于運營經(jīng)驗的積累；

減小故障域：當發(fā)生故障時，減少影響范圍，提升網(wǎng)絡的健壯性；

負載均衡：不依賴專用的負載均衡設備，在DC內(nèi)部形成等價多路徑；

靈活的策略控制：對于特定業(yè)務流需求，可提供豐富的路由策略控制手段；

快速收斂：在發(fā)生故障時，能減少影響面，快速收斂。

2、現(xiàn)有路由協(xié)議匹配度

我們看下現(xiàn)有路由協(xié)議的匹配度。

路由信息協(xié)議（RIP）：不適用大規(guī)模數(shù)據(jù)中心；

增強內(nèi)部網(wǎng)關路由協(xié)議（EIGRP）：私有協(xié)議，不符合需求2、3；

內(nèi)部BGP協(xié)議（IBGP）：一般需要配合內(nèi)部網(wǎng)關協(xié)議（IGP）一起使用，不滿足需求2、3；

開放式最短路徑優(yōu)先（OSPF）、中間系統(tǒng)到中間系統(tǒng)（ISIS）、BGP：初步看這三種路由協(xié)議基本能滿足1-7所有需求。其中ISIS和OSPF同屬于鏈路狀態(tài)IGP協(xié)議，相似度較高，選取應用更為廣泛的OSPF進行對比。以下著重分析OSPF和BGP兩種路由協(xié)議。

3、OSPF VS BGP

以下是維基百科對OSPF和BGP協(xié)議的定義。

OSPF：開放式最短路徑優(yōu)先（Open Shortest Path First），是對鏈路狀態(tài)路由協(xié)議的一種實現(xiàn)，隸屬內(nèi)部網(wǎng)關協(xié)議（IGP），運作于自治系統(tǒng)內(nèi)部。采用戴克斯特拉算法（Dijkstra's algorithm）被用來計算最短路徑樹。它使用“代價（Cost）”作為路由度量。鏈路狀態(tài)數(shù)據(jù)庫（LSDB）用來保存當前網(wǎng)絡拓撲結(jié)構(gòu)，路由器上屬于同一區(qū)域的鏈路狀態(tài)數(shù)據(jù)庫是相同的。

BGP：是互聯(lián)網(wǎng)上一個核心的去中心化自治路由協(xié)議。它通過維護IP路由表或‘前綴’（Prefix）表來實現(xiàn)自治系統(tǒng)（AS）之間的可達性，屬于矢量路由協(xié)議。BGP不使用傳統(tǒng)的內(nèi)部網(wǎng)關協(xié)議（IGP）的指標，而使用基于路徑、網(wǎng)絡策略或規(guī)則集來決定路由。因此，它更適合被稱為矢量性協(xié)議，而不是路由協(xié)議。

OSPF和BGP都是應用非常廣泛的路由協(xié)議，技術本身沒有優(yōu)劣之分。我們僅限于在大型/超大型的數(shù)據(jù)中心這個場景，來分析下兩種路由協(xié)議適用度。

協(xié)議類型對比項	OSPF	BGP
路由算法	Dijkstra algorithm	Best path algorithm
算法類型	鏈路狀態(tài)	距離矢量
承載協(xié)議	IP	TCP，有重傳機制，保證了協(xié)議數(shù)據(jù)可靠性
需求一：大規(guī)模組網(wǎng)	適用度：★★★ 理論上無跳數(shù)限制，可以支持較大規(guī)模的路由組網(wǎng)；但OSPF需要定期整網(wǎng)同步鏈路狀態(tài)信息，對于超大規(guī)模數(shù)據(jù)中心，鏈路狀態(tài)信息庫過大，網(wǎng)絡設備計算時性能消耗大；同時網(wǎng)絡震蕩影響面大	適用度：★★★★★ 只傳遞計算好的最優(yōu)路由信息適用于大型/超大型數(shù)據(jù)中心，在超大規(guī)模園區(qū)已有成熟實踐
需求二：簡單	適用度：★★★ 部署簡單，運維中等	適用度：★★★★ 部署簡單、維護較簡單
需求三：IDC內(nèi)部署單一類型的路由協(xié)議	適用度：★★★★ 滿足 IDC內(nèi)部可以只部署OSPF單路由協(xié)議在Server上也有豐富的軟件支持	適用度：★★★★ 滿足 IDC內(nèi)部可以只部署B(yǎng)GP單路由協(xié)議在Server上也有軟件支持外部自治系統(tǒng)之間也是使用BGP互聯(lián)
需求四：減少故障域	適用度：★★ 域內(nèi)要同步鏈路狀態(tài)信息，所有的Failure需要同步更新	適用度：★★★★ BGP本地只傳播計算好的最佳路徑，當網(wǎng)絡發(fā)生變化時，只傳遞增量信息
需求五：負載均衡	適用度：★★★★ 規(guī)劃好COST值，多鏈路時形成ECMP，某一鏈路故障時需要同步域內(nèi)設備計算	適用度：★★★★★ 規(guī)劃好跳數(shù)、AS后，多鏈路時可形成ECMP，某一鏈路故障時將鏈路對應的下一跳從ECMP組內(nèi)移除
需求六：靈活控制	適用度：★★★ 利用Area、lSA類型進行路由傳播的控制，相對復雜	★★★★ 利用豐富的選路原則，對路由進行過濾、控制路由的收、發(fā)
需求七：收斂快	適用度：★★★ 路由數(shù)量少時，通過BFD聯(lián)動可實現(xiàn)毫秒級收斂通告的是鏈路狀態(tài)信息，路由域大時，計算消耗大導致收斂會變慢	適用度：★★★★ 路由數(shù)量少時，通過BFD聯(lián)動可實現(xiàn)毫秒級收斂通告的是本地計算好的路由，路由域大也不會明顯影響性能；同時BGP有基于AS的快速切換技術

表1 大型數(shù)據(jù)中心路由協(xié)議對比

通過上表分析，結(jié)合業(yè)界的一些實踐，我們認為在中小型數(shù)據(jù)中心，路由域內(nèi)網(wǎng)絡設備數(shù)量不多的情況下，使用OSPF協(xié)議是比較合適的；而對于大型/超大型的數(shù)據(jù)中心，BGP的適用度會更高一些，建議部署B(yǎng)GP路由協(xié)議。

寫在最后

限于篇幅原因，本文只介紹了大型IDC首選BGP路由協(xié)議組網(wǎng)的原因，并未涉及BGP協(xié)議具體規(guī)劃。銳捷網(wǎng)絡在國內(nèi)TOP3的互聯(lián)網(wǎng)公司，均承建了大型/超大型數(shù)據(jù)中心網(wǎng)絡，且使用BGP路由協(xié)議組網(wǎng)。關于BGP路由協(xié)議的具體規(guī)劃，這里先拋出幾個問題，期待后續(xù)與大家共同探討：

BGP私有AS號數(shù)量有限，對于大型數(shù)據(jù)中心,AS應該如何規(guī)劃？

BGP使用什么接口建立鄰居？ECMP/LACP場景下如何規(guī)劃？

BGP選路原則非常多，怎么合理利用？

BGP性能、可靠性、收斂速度有哪些優(yōu)化的方法？

本期作者：顏曉波
銳捷網(wǎng)絡互聯(lián)網(wǎng)系統(tǒng)部行業(yè)咨詢