解耦重構 Internet BGP SDN
1 介紹/Why
高清視訊直播和雲端計算的蓬勃發展,帶來網際網路流量持續高速增長,主流雲公司的Internet出口頻寬都已經達到Tbps級別。 鑑於網路的擁堵大部分發生在出口互聯,Edge Peering Fabric的架構設計直接影響到終端客戶的使用者體驗, 2017年Google/Facebook對外發布了兩種不同的Edge 設計理念,本文試著以Google Espresso為主詳解下一代Cloud Edge的架構,並簡單介紹一下Facebook Edge Fabric。
藉助成功部署業界第一個SDN網 B4資料中心互聯的經驗,Google工程師重新設計了全新的Espresso Peering Fabric。在2017年Espresso已經部署了3年多,服務20%的Google使用者,也就是說你看5次Youtube,就有一次機會Espresso控制器幫你調優轉發路徑。Espresso採用SDN動態調整BGP出口頻寬,快速迭代最新特性,在全球TE控制器配合下,Espresso可以提供比傳統BGP路由多傳送13%的客戶流量。同時可以顯著提高每條鏈路利用率和端到端使用者體驗。有效減少了客戶流量的Rebuffers(減少35%-170%)。
首先簡單介紹一下Google的網路,截止2018年1月,Google全球有33個數據中心,100+多個POP站點,同時在不同運營商網路中有很多Offnet Cache站點。資訊從Google資料中心資訊大致經過DC-POP-Cache三級網路傳送到終端使用者。
Google的廣域網實際上分為B2全球骨幹網和B4(DCI)資料中心網際網路。如下圖所示。B4作為Google全球資料中心互聯採用自研交換機裝置,執行純IP網路。B2連線資料中心和POP點,採用廠家路由器裝置,並且執行MPLS RSVP-TE進行流量工程調節,正在進行SDN/SR改造。簡單的說,B4負責資料中心到資料中心的流量轉發(Machine to Machine),B2負責資料中心到使用者的流量轉發(Machine to User)。關於B4詳細資訊,請參考 ofollow,noindex">Google B4 廣域網SDN 的前世今生
Google在ONS Summit 2017上推出了他的第四個SDN控制器Espresso(濃縮咖啡),在Metro網路中新引入SDN控制器來調整出方向(Egress)流量。在Google B4 DCI網路中,所有裝置都是Google自己設計實現的。可以做到很好的端到端控制, Host/Switch/WAN全路徑流量可規劃和可程式設計(Walled Garden)。如何在開放的Internet BGP Peering上來提供Application Aware SDN?Google 嘗試用全新的Espresso來解決這個問題。
Espresso首要需求是: 動態調整每使用者/每應用流量,在PR出口避免擁塞 。現有的互聯Peering網路是依賴於BGP設計的。BGP設計之初是為了提供穩定的聯通性,完全沒有考慮網路的動態變化,網路的需求,容量和效能都在每時每刻變化(BGP doesnt consider Demand, Capacity and Performance)。舉個例子,對8.8.8.0/24的網段,可能有兩個ISP或者ASBR都發送相同的路由。ASBR會根據BGP策略選擇一個最優路徑,比如上圖中,選擇ASBR1。過了10分鐘,到ASBR1的鏈路擁塞了,BGP不會做任何動作。只有當這個8.8.8.0/24 prefix從路徑1不可達,BGP才會選擇次優化路徑。BGP號稱是動態路由協議,實際上是非常靜態的。但是BGP也不是無可救藥,BGP有很多靈活的策略,比如根據Local Preference /Community/ Add Path 去調整選路。 不過需要網路管理員手動調節。 雖然BGP有這麼多問題,但是大多數的傳統的SP/ISP還在採用BGP互聯,Google/Facebook還不能拋棄BGP,所以Google/Facebook引入SDN控制器來自動調節BGP出口流量。
Google Metro原有設計最重要的缺陷是沒有全域性觀Metro View, 沒有辦法進行全域性優化,引入新的特性 。通常Google在Metro實時監測百萬使用者的流量頻寬時延,不同應用不同優先順序流量在鏈路分佈。但是很難(受限)在路由器上進行細顆粒度的控制/改寫override BGP轉發行為。即便是可能去更改, 也需要廠商路由器裝置去配合。一般至少需要一年時間去通知廠商開發一個特性 ,才能成功部署在OTT網路中。無法滿足Google的應用快速迭代要求。
1.1 Egress/Ingress Peering Engineering
傳統的流量工程僅僅 關注在IGP域部分,致力於避免網路內部擁塞。對於Cloud/Video/CDN等業務,網路的瓶頸還存在於BGP Peering部分。傳統運營商能採用什麼思路來解決BGP流量工程問題呢。如何找到沒有擁塞的ASBR和BGP Peering鏈路進而提高網路傳送能力?
C/J的路由專家和OTT專家討論之後,提出了兩種不同的思路來解決。核心思想都是給Peering Link分配標籤,一種方式通過BGP-LU攜帶,另外一種通過BGP-LS攜帶。
● draft-gredler-idr-bgplu-epe-xx(RtBrick/Juniper)
● draft-ietf-idr-bgpls-segment-routing-epe-xx(Cisco/ Arrcus)
下面以BGP-LU方式為例解釋一下流程:
● 引入SDN控制器蒐集全網BGP prefix路徑資訊和Peering鏈路流量資訊(Netflow/Telemetry)
● SDN控制器跟ASBR建立BGP-LU(3107)鄰居,並且給每個Peer分配一個標籤。
● SDN控制器根據實時鏈路狀態,計算最優路徑,例如每隔30秒來根據(latency/bandwidth/optical SRLG etc)來選擇避免擁塞的ASBR或者某個鏈路。
● SDN控制器在Ingress頭結點(可以是vRouter/TOR,也可以在GW router)進行策略控制:
1.外層隧道採用Segment Routing壓上多個標籤,外層SR標籤找到ASBR,內層BGP-LU標籤找到Peering
2.外層隧道也可以採用GRE/LDP等,建立Ingress/ASBR的直連MPLSoGRE隧道。在ASBR上解掉GRE封裝,通過查詢MPLS標籤來指導Peering轉發。
在BGP EPE轉發路徑上有個比較特殊的屬性,從使用者網路AS內部到Peer ASBR的轉發,不需要查詢Internet路由表,僅僅需要MPLS轉發。
入方向(Ingress)流量根據Global LB(Google採用Meglev)或者BGP Addpath(運營商)來優化。這裡不再詳述。注意入方向進到ASBR流量可以是IP,ASBR只需要儲存Google/Facebook內部網路的Prefix轉發表(<<128K)。
利用給每個Peering分配標籤特性,把完全Internet轉發表的需求轉移到Ingress Router(或者Host),可以採用新型態的LSR /Lean Core裝置做Internet Peering,可以大幅減少網路投資。同時引入SDN控制器可以動態監控網路擁塞情況,動態調整BGP轉發策略,極大的減少了網路的人工干預。關於更多詳細的BGP EPE解決方案,請參考我們在2016年初在New Zealand Apricot上的演講。 http://t.cn/RnXyHhR
2 Espresso詳解
前面講到Espresso來改造Google Metro,通常來講Metro提供三個基本的功能
● 路由器:提供BGP路由與合作伙伴對等交換。
● 伺服器池:負載分擔和CDN靜態快取內容分發
● 伺服器池:提供反向TCP代理
全新的Cloud Edge架構設計需要支援超低時延應用,提供重要的Anti-DDoS功能,並且能有效利用CDN減少經過雲骨幹網的流量。
從上圖可以看到主流的OTT都部署了反向web代理。以Facebook為例,從首爾訪問俄勒岡的資料中心,在跨越太平洋光纜一般要引入75ms的單程延遲。如果沒有采用反向web代理(圖左),從客戶開始訪問到收到網頁,需要600ms。利用在東京的POP點裡面的反向Web代理之後,延遲可以降低到240ms。使用者體驗得到極大提高。
2.1 Espresso系統架構
為了更好的規劃Metro裡的流量排程,Espresso引入了全球TE控制器(B4中也採用了)和本地控制器(Location Controller)來指導主機發出流量選擇更好的外部Peering 路由器/鏈路,進行per flow Host到Peer的控制。
並且解耦了傳統Peering路由器,演進為Peering Fabric和伺服器叢集(提供反向Web代理)。
控制和轉發流程:
● 外部系統請求進入Google Metro,在Peering Fabric上被封裝成GRE,送到Meglev負載均衡和反向web代理主機處理。如果可以返回快取記憶體上的內容以供使用者訪問,則該資料包將直接從此處發回。如果CDN沒有快取,就傳送報文通過B2去訪問遠端資料中心。
● 主機把實時頻寬需求傳送給全域性控制器(GC)
● GC根據蒐集到的全球Internet Prefix情況,Service Class和頻寬需求來計算調整不同應用採用不同的Peering路由器和埠進行轉發,實現全域性出向負載均衡。
● GC通知本地控制器(LC)來對host進行轉發表更改。同時在PF交換機上也配置相應的MPLSoGRE 解封裝。
● 資料報文從主機出發,根據GC指定的策略,首先找到GRE的目的地址(PF),PF收到報文之後,解除GRE報文頭。根據預先分配給不同外部Peering的MPLS標籤進行轉發(注意,採用集中控制器,不需要引入BGP-LU來分配MPLS標籤)。如上圖所示,如果採用紅色MPLS標籤,就會轉發給紅色鏈路。
下面針對不同的子系統詳細講解。
2.2 全域性和本地控制器
全域性控制器是一個分散式系統,持續不斷的蒐集各類資訊,並且定期產生針對應用優化過的轉發規則。進行並且通過本地控制器(LC)在各個區域釋出。本地控制器提供本地決策,來快速應對本地鏈路和Prefix的變化。
為了實現應用感知,全域性控制器需要蒐集:
● BGP Peering/Prefix資訊,類似BMP全網路由和Peering關係。
● 使用者頻寬和效能需求,通過L7 Proxy蒐集每使用者頻寬,延遲需求,並彙總。一般針對/24目的路由產生相近的延遲資料。
● PF出介面每佇列鏈路利用率
全域性控制器的輸出是一個Egress Map規則,對特定{ POP | Prefix |Class },選擇出口{ ASBR | Port }。
本地伺服器收到GC的應用優化規則,結合從EBGP過來的實時peering路由資訊,來產生主機轉發表。為了Anti-DDoS攻擊,還需要LC來下發大規模ACL轉發表項到主機。一臺本地控制器可以控制大概1000臺伺服器,持續不斷的更新主機轉發表項和ACL。
上圖可以看到,LC 收到GC 轉發規則之後,對每個主機,需要產生不同的{ Prefix | Application
Class } 採用不同的出口{ PF | Port | %},並且迭代找到相應的GRE/MPLS 封裝。
2.3 解耦Peering Router 演進到Peering Fabric
Espresso 另一個主要的設計原則是解耦路由器,演變成Peering Fabric。
傳統的Peering 裝置,由廠家統一提供軟體和硬體。軟體新特性開發週期過長。把非必要的功能從
Peering 路由器拿掉,僅保留最簡單的MPLS(Label-Switch Fabric)資料轉發平面。SDN 軟體特性
開發工作由Google 工程師主導,可以極大提高 網路可程式設計性(Programmability) :
1. BGP Speaker 功能,從路由器移出來,採用Google 自研Raven BGP 協議棧,執行在專用伺服器上,可以支援更多的Peering,執行更復雜的優化演算法,更精細的路由器控制。僅僅實現必要的Feature。
● a. 支援多核和Scale Out 控制平面,支援BGP Graceful Restart
● b. 同一個Peering fabric可以執行多個Raven例項。多個session可以平均分配到Raven例項。當Raven出錯時,僅僅影響少量的BGP session
● c. 之前採用Quagga,面臨一些問題,Quagga只有單執行緒,C語言除錯工具太少等。
2. 伺服器叢集:出方向(Egress)報文Internet路由查表/封裝和ACL訪問控制列表等放到在Edge裡面的大規模伺服器叢集。
● a. 每個Host裡面都存放完整Internet路由表。IPv4 FIB採用Compressed Multibyte Tire 演算法,採用Binary Tire做IPv6 FIB查表。
● b. Espresso現網執行環境每個Host中,大概有190萬Prefix/Service Class Tuple表項,佔用 1.2GB記憶體。 峰值可以做到每Host傳送37Gbps報文,大概3Mpps。查FIB表CPU佔用率 2.1-2.3%左右。
● c. Host裡儲存大規模Internet Facing ACL(MPLS Switch硬體表項太小),配合支援Anti-DDoS等業務,一小部分常用ACL放到PF裡面進行業務線速轉發。
3. Peering Fabric(PF, MPLS Switch):進行MPLS轉發,僅支援小規模FIB表和ACL表項。減少路由器成本
● a. 採用Openflow來編輯MPLS轉發表,並且配置IP-GRE規則來匹配BGP協議報文傳送去相應伺服器,並生成MPLSoGRE轉發表。
● b. Switch裡面保留常用ACL(小規模)線速轉發。5% ACL可以匹配99%的流量。在軟體Host裡面儲存另外95%的ACL,從PF透過GRE tunnel把流量轉到Host做進一步處理。
4. Peering Fabric 控制器
● a. 對映BGP Peering到不同的Raven例項。
● b. 管理PF轉發表
2.4 配置管理紅色按鈕-Big Red Button
Espresso採用自動化Intent-Based配置管理工具。 收到人工可讀的意向(Intention)配置管理工具會翻譯詳細的可以被裝置理解的配置。
為了安全性和易用性考慮,Espresso提供了一個大紅按鈕(Big Red Button,BRB)配置管理功能。管理員可以很容易安全的關閉部分/全部系統功能:
● 可以告訴LC下發給所有主機採用本地最佳路由,不用接受全域性控制器指令。
● 可以移除一個或多個BGP鄰居。
● 點選BGP管理GUI可以移出流經這個Peer的流量。
3 Facebook Edge Fabric簡介
2017年Sigcomm大會,Google和Facebook同時釋出了兩種不同的Edge架構。下面簡單介紹一下Facebook Edge Fabric的架構。
● 首先,Edge Fabric也引入一個SDN/BGP控制器。
● SDN控制器採用多重方式蒐集網路資訊
● 控制器基於實時流量等相關資訊,來產生針對某個Prefix的最優下一跳。指導不同Prefix在多個ASBR之間負載均衡。
● 控制器和每個Peering Router建立另一個BGP 控制session,每隔30秒鐘用來改寫Prefix,通過調整Local Preference來改變下一跳地址。
● 因為BGP不能感知網路質量,Edge Server對特定流量做eBPF標記DSCP,並動態隨機選一小部分流量來測量主用和備用BGP路徑的端到端效能。排程仍然發生在PR上,出向擁塞的PR上做SR Tunnel重定向到非擁塞的PR上.如下圖所示:
從上圖可以看出Facebook採用的都是業界主流廠商支援的協議來實現Edge Fabric。同時有這樣一些限制:
● SDN控制器單點控制PR裝置。如果PR裝置已經Overload,需要通過PBR和ISIS SR Tunnel轉移到另一個沒有擁塞的PR,流量路徑不夠全域性優化。
● 控制器只能通過Prefix來控制流量,但是同一個prefix,可能承載視訊和Voice流量,頻寬和時延要求不同,Edge Fabric沒有Espresso那麼靈活。
Facebook介紹,最早他們的嘗試過集中不同的方案,從Host選路到PR,都不太成功。
● 從Host建立LSP到PR
● 從Host 標識DCSP,PR根據DSCP轉發到不同埠
● 從Host採用GRE tunnel到PR。
最後選擇了BGP Inject@PR方案,他們認為是現階段比較適合的方案。在最近的Network@Scale 2018大會上,Facebook工程師說,未來Edge Fabric架構可能考慮轉向BGP EPE和Segment Routing。
下表我們總結了兩種方案的比較,請參考。
4 總結和展望
本文介紹了三種不同的思路來解決BGP出口流量排程問題。
● BGP EPE:採用標準協議為主,SDN控制器通過BGP LU/BGP-LS/Netflow方式選路。
● Facebook Edge Fabric:SDN控制器計算最佳路徑,BGP Local Preference 方式來路由注入
● Google Espresso:主機存放完整Internet路由,SDN控制器找到相應ASBR/Port.
從端到端架構圖中,可以看出在一個POP或DC WAN, Core/Aggregation 裝置大多已經採用Lean /BGP Free Core解決方案不用儲存完整Internet路由。通過Espresso,Google改造/解耦了 Peering/ASBR 路由器,通過把大部分軟體控制功能移到伺服器。PF裝置可以採用更簡單的MPLS Switch(QoS能力強,大Buffer,小型FIB表,小型ACL表,類似B公司Jericho系列)。加上之前B4已經採用了CLOS架構的Stargate Switch裝置。
Google已經成為業界第一個在WAN網路中沒有采用傳統Router的OTT公司。全網已經改造為Switch/Server的架構。對於在POP和DC中有大規模伺服器的Google來講,在POP中的每個Server處理內容的基礎上加上1.2GB記憶體和2-3%的CPU來實現Internet路由查表和隧道封裝基本上是可以接受的。
相比Facebook Edge Fabric,Google Espresso完美的解決了Application Aware TE問題,但是開發工作量也是巨大, Google為Espresso開發了很多全新元件:
{ 全新層次化SDN控制器GC/LC,全新BGP協議Raven實現,全新主機IPv4/IPv6 轉發表, 全新路由器解耦PF MPLSoGRE隧道介面,實時L7 Proxy流量需求 }
Espresso 僅僅改造了Metro POP, 今後會不會在B2採用類似Espresso架構來打通Backbone和Peering Fabric進行跨越B2全網流量排程?期待Sigcomm 2019 Google能夠揭曉更多B2改造成果!
國內OTT Metro改造展望
雲端計算進入下半場,企業上雲(Cloud Onboarding),網路SDN動態調整的能力越發重要。從雲到網需要端到端聯動{ VPC/DCI | Metro | Cache | SDWAN },OTT SDN全網改造勢在必行。
Google的網路改造方案是否過於複雜(Over Engineering)?Facebook Edge Fabric過於簡化,能否找到一條更適合中國OTT的技術路線來改造POP點?本人認為:
1. 技術路線應該選擇類似BGP EPE方案,跟Google保持一致。
● a. 不要採用BGP Inject方式,防止PR裝置過載。並且可以做全域性排程
2. 有條件情況下儘量採用Segment Routing + EPE 方式
● a. Google採用MPLSoGRE,是因為Metro/PoP一般比較小,內部也不會太擁塞。如果從超大資料中心跨越骨幹網,最好是採用SR+EPE,避免魚形TE問題。
● b. 對於BGP協議在伺服器實現的方式,入方向BGP協議報文可以走GRE。
3. 跟雲平臺和OTT網路使用者確定流量需求介面,支援Application Aware SDN
● a. 不光基於Prefix進行流量排程,最好分不同業務Class來指導轉發。
4. 裝置形態
● a. 大雲公司可以嘗試BGP跑在伺服器,並且在Host支援IPv4/IPv6全internet轉發表。但是需要工程師不斷調優。最近Linux Native 支援VRF,FRR等開源軟體也支援EVPN on Host。
● b. 建議採用PTX/NCS/Jericho/Jericho2等類似裝置,尤其是10T盒子/Chassis內建HBM2,一般1M FIB起跳,減少轉發表沒有太多裝置成本節省。
隨後我們會繼續詳解Google/Facebook/AWS 等OTT網路架構,下篇想談談Facebook DC, Fabric Aggregator, Express backbone,Edge Fabric和Open/R等,接下來也會詳解AWS網路和雲架構。敬請期待。
原文釋出時間為:2018-10-16
本文作者:gated