作者：馬紹文 丨首發於SDNLAB
Google 網絡架構
隨著雲計算的發展，Internet 從最早承載海量文本/圖片/視頻，演變到高清直播佔據Internet 主要流量（Netfliex/AWS, Youtube/Google, Facebook Live/Facebook）。
隨著AR 相機 和社交VR（SocialVR）的等新應用的到來，互聯網的流量還會持續高速增長。大部分的流量增長沒有體現在運營商SP 的網絡中，而是主要集中在OTT 網絡中。
Google/Facebook/AWS/Microsoft/Apple 為代表五大OTT 都構建了全球規模的骨幹網，很多人也稱之為『Private Internet』。
OTT 的數據中心/WAN/PoP流量快速增長，帶來OTT 網絡架構的快速迭代和升級。傳統的設備形態和網管工具無法適應流量和業務的快速發展。OTT 紛紛採用自研設備，引入SDN 來管理全球骨幹網。
Google 的SDN 網絡大概可以分為四個主要部分：
①雲平臺Andromeda（仙女座）
②數據中心 Jupiter（木星）
③Peering Espresso SDN（意式咖啡）
④DCI 互聯WAN SDN（B4）
Google 的廣域網實際上分為B4（DCI）數據中心互聯和B2 骨幹網。如下圖所示。
B4 作為Google全球數據中心互聯採用自研交換機設備，運行純IP 網絡。B2 連接數據中心和POP 點，採用廠家路由器設備，並且運行MPLS RSVP-TE 進行流量工程調節，還沒有進行SDN 改造。
簡單的說B2負責數據中心到用戶的流量轉發（Machine to User），B4 負責數據中心到數據中心的流量轉發（Machine to Machine）。
B4 的流量增長率遠遠高於B2，容量每9 個月就要翻倍（Double），5 年時間，流量增長了100倍。沒有商用單機路由器可以支持這麼大容量的業務增長。所以Google 決定利用交換機芯片來自定義自己的『超級核心路由器』
Google 在2012 年部署全球SDN 廣域網絡B4，基於自研設備 Saturn（土星），2013 年8 月在香港SIGCOMM 發表B4 SDN 控制器白皮書。《B4: Experience with a Globally-Deployed Software Defined WAN》，2018 年發表《B4 and After: Managing Hierarchy, Partitioning, and Asymmetry for Availability and Scale in Google Software-Defined WAN》。描述B4 的演進，更新了自研設備Stargate（星關）和層次化的TE 控制器。2012 年B4 部署在全球12 個站點，到2018 年1 月B4 站點增加到33 個。
如下圖所示，紅色圖標中的數字，說明在位置附近有多少個站點（sites）
業界對於B4 的理解僅僅停留在兩篇晦澀的白皮書上。本文從一個架構師的視角試圖解析B4 的自研設備，網絡架構，SDN 控制和部署中碰到的難題。對於Google 如何構建雲計算平臺GCP 請參考作者的另一篇關於混合雲/多雲網絡的文章：深度解讀：雲網融合的多雲網絡。對於 OTT 網絡架構的深入理解，基本上來源於 SIGCOM 的白皮書和一些公開視頻和討論。
B4詳解
▌B4 硬件發展
第一代 B4 Saturn（土星）交換機:
為了應對數據中心流量的快速增長，Google 2009 年在數據中心部署了第四代機框式 Saturn（土 星）交換機，可以在半高機箱中支持 288x10GE 接口，單槽 240Gbps， 一個機架支持 5.76T。相比 同期廠商路由器設備，大部分僅僅支持單槽 40G。(CRS-3 2010/2011 年全高機箱支持 140G/Slot x 16 = 2.24T)。Saturn 圖片上面的 Pizzabox 是同樣 24x10GE 的 TOR 交換機，接 10GE 的服務器。
多機互聯 vs CLOS
運營商網絡一般採用多機框的方式來 Scale out. 但是多機框需要設計專門的 Fabric 機框。最早的多 機系統通過非常複雜的交換矩陣互聯把多臺 LCC(line card chassis)連接起來。比如 4+2 系統需要 960 根 VCSEL(Vertical Cavity Surface-Emitting Lasers， 一個 3x12 bundle 裡面有 36 根 fiber )線纜互 聯。連接效率非常低，同時非常容易出現光纖故障難於 debug。
在 2014 年推出的 200G/400G 每槽 的單機之後，連接的光纖採用 CXP 100GE 標準光纖帶(每條 12 根光纖)，也是個龐大的複雜系統。 而且非常難於升級，多機互聯採用的芯片基本上比單機系統晚一代（2-3 年）。
全球 SP 客戶基本上都摒棄了 Multi-Chassis 的設計，OTT 網絡從設計之初就拋棄了多機互聯。很 多 OTT 客戶採用 CLOS Fabric 來構建大型路由器系統。
2010 年在設計 B4 之初， Google 採用的是 CLOS 架構，用 6-8 臺 Saturn 來構造一個 CLOS Fabric,並大規模部署在全球 12 個 DC site。
根據不同 site 流量要求，每個 Saturn Fabric 可以提供，5.12Tbps 連接數據中心，5.12/6.4T 到廣域網連接。
CLOS Fabric as a Router
隨著業務流量的增長，Saturn 大機箱 CLOS 設計也無法滿足業務發展。2013 年，Google 重新設計了 B4 site,取消了原來的大盒子設計，採用小盒子 Pizzabox 來構建新型的 CLOS Fabric，兩種設計 JPOP 和 Stargate（星際之門），JPOP 主要部署在 POP 點，Stargate 用來升級傳統的 Saturn（土 星）站點。
Stargate 利用 1.28T 的 Trident2 芯片，採用盒式交換機（見上圖右上角）。利用 16 Spine + 32 leaf， 總計 48 個盒式交換機構建了一個 Stargate(星際之門)Super Node 路由器。在一個 Stargate 站點內，一般有四個 Fabric，提供 81.2Tbps 的容量來連接 Cluster/Sidelinks 和 WAN。
從 Google B4 路由器硬件的演進可以看出，最早採用大機箱 Fabric，後來把大機箱拆開分為 Spine(Fabric Card)/Leaf(Line Card) IP CLOS 系統，多個系統組成一個站點。最近由小盒子組成的 IP Fabric Core 路由器在很多 OTT 網絡中出現，比如 AWS 的 Brick 設計就是類似架構，採用不同芯片架構和 BGP 設計，更兼顧長距傳輸的 QOS 要求和低成本要求。
國內 OTT 紛紛參考 OCP，Sonic/Stratum 架構，開始自研數據中心交換機。但是國內 OTT 廣域網（WAN）設計還沒有采用專用的自研設備，也基本上沒有區分 B2（DC-POP/Peering）和 B4 （DCI 互聯）不同的網絡設計目標，並引入廣域網 SDN 控制器。Google/AWS/Facebook 的 WAN 設計值得國內 OTT 學習。限於篇幅本文僅介紹 Google 的 WAN network，後續會介紹 Facebook 和 AWS 的網絡架構。
▌B4 網絡架構
Google B4 SDN Picture from netmanis.com
B4 的流量調度，首先通過 Center TE server 蒐集全球 DC Cluster 的流量發送請求。通過 SDN Gateway 調節全球 12+ DC site 之間的流量。Google 是第一家公司採用 SDN 技術，在跨洲光纜鏈 路做到鏈路利用率 98%以上。
有了新的 CLOS 路由器，Google 的 WAN 是如何構建的？首先你需要設計：
怎樣做流量工程？
● 從 DC Cluster 蒐集流量發送請求，發多少流量，到哪個目的地址。
● 通過全球的流量管理控制器（BwE controller），進行層次化控制。從 DC Andromeda（仙女座）SDN 控制的主機 Host 開始流量控制，匯聚成每個 Job/Cluster 的流量需求，提供給 Global Enforce 統一調度併發送給 Central TE 來驅動 SDN 控制器來建立端到端的 Tunnel。
● BwE 的設計原則是，路由器/交換機不是一個對 IP 報文 per packet 做策略、帶寬預留控制的理想節點，尤其 B4 採用小 buffer 交換芯片，很難做到海量數據流量 QoS 控制。所以 BwE 設計流量控制在 Host 層次，並且在 B4 提供層次化 TE 管道控制。
● BwE 修改了 Linux 網絡協議棧，任何 Container 發出的流量，都可以被識別，每 5 秒鐘間 隔，Host 彙報流量情況。並且匯聚 Task/Job/User/Cluster 的流量要求，最後匯聚成 SiteSite 的流量請求。並且能夠根據歷史流量數據，進行帶寬預留的預測。如下圖所示：
可能需要個路由協議？
在 Google 數據中心裡，有大量自研設備，包括 Leaf/Spine 交換機，還有前面提到的 CLOS Fabric，如何感知網絡拓撲，構建 SPF 最短路徑樹？
2009 年左右，ISIS 用在數據中心裡，帶來了很多 Flooding 的問題，BGP Fabric 設計還沒有流行。
Google 的一個工程師基於 ISIS 協議，創造一個新的 IGP 協議 Firepath 路由協議來計算路徑。
首先，把路由控制平面集中到 Firepath Master 服務器上，並且在服務器之間跑專門的 FMRP 做備 份。對於每個 Leaf/Spine 交換機，他們不需要互相建立 IGP 鄰居去發現拓撲。而是僅僅跟 Master 建立鄰居關係，上報拓撲信息，拿到 master 下發的路由表。
Firepath 僅僅是 IGP 協議，需要引入 Quagga 做 BGP peering。
Firepath 在 2009 年左右部署在 Jupiter 和 B4，過了幾年，Google 覺得 Firpath 保留了太多 ISIS 的機制，對 Google 的 DC 和 B4 意義不大。在 2014 年左右，Google 用新的 SDN 協議來取代了 Firepath。
新的 SDN 控制器能拿到網絡的 topo 信息，就可以計算出最優路徑。不需要任何 OSPF/ISIS 或者 BGP 協議。關於新的 SDN 路由協議，我們後續再做詳細分析。
選擇 Tunnel 技術做流量調度
● 注意，這裡的 TE 流量工程，完全沒有采用傳統的 MPLS RSVP-TE Tunnel。在每個 site 中，Google 採用 IPinIP 報文來實現非 ECMP 路徑的 tunnel 負載分擔。Google 把需要做 TE 優化的 Tunnel, Tunnel Group 和 Flow Group。用 KV 數據庫構建 TED。每個 OFC 利用 TED 來下發沿路的 tunnel 轉發表，OFC 等待沿路的每個路由器給出迴應（成功/失敗）。
● 為了避免丟包，在 OFC 更新 tunnel 和 flow group 的時候，一定要遵循一定的順序，比如首 先設置好 tunnel，然後才能配置 flow group 映射流量到 Tunnel 上。並且在拆掉 Tunnel 之前，也要等所有 flow Entry 沒有用到這個 Tunnel。
● 比如對於目的地址是 9.0.0.1 報文，在 Encap 交換機會封裝在兩個不同的 IP Tunnel 裡面， source 地址都是 2.0.0.1，目的地址分別是 3.0.0.1 和 4.0.0.1.
● 在 Transit 交換機，到 4.0.0.1 的報文直接按照最短路徑樹（LPM）來轉發，沿著綠色 tunnel。到 3.0.0.1 的報文，在 Transit switch1 按照 Openflow ACL table 來轉發（有別於 IGP，也不是 ECMP）
● 在 Decap 交換機，根據目的地址是 3.0.0.1/4.0.0.1 直接按照 Openflow 彈出下一跳繼續按照 LPM 查表。
Openflow 表比 LPM 表項更優先，如果 Openflow 表項失敗，自動按照 IGP/LPM 表項轉 發。如下圖所示：在 Encap Switch 上，有 IGP 算出來的 9.0.0.0/24 地址，因為配置了 FlowGroup SDN/ACL entry, 所以轉發按照 ACL 找到 Multipath index=0，然後根據 Hash 結果發送到兩個 tunnel。
隨著 B4 流量極速增長，自研設備演變成更大的 Stargate ,同時在網絡架構上，每個 Site 中引入了多 個 Stargate Fabric。為了在 site level 進行流量規劃，Google 引入了另一個高層次化 TE， SuperNode TE（TSG）。如下圖所示：
● SSG（Switch Split Group） level：每個 Stargate 是一個 Fabric，最多有 16 Spine + 32 leaf，需要指導流量在多個 Pizzabox 裡面轉發給下一個 site，或者利用 side link 轉發給同一個 site 裡面的另一個 Stargate Fabric。跟舊有的 Saturn 多個大機框的調度一樣。
● TSG（Tunnel Split Group） level： 四個 Stargate fabric 組成一個 Super Node。Stargate Fabric 之間的鏈路叫做 Side Link。用來保護 Site 之間鏈路中斷。一般 site 的 16%容量用來 Fabric 互聯。新加入的流量調度層次。
● TG(Tunnel Group) Level：在 B4 Site 之間 Tunnel 的流量調度，採用 IPinIP 封裝。Tunnel 的 起終點是 Statrgate 的 Edge Switch，E1/E2 etc.
在 TSG 上的層次化 TE 調度採用 Greedy Exhaustive Waterfill 算法，白皮書裡用了很多篇幅講解，實際上對於網工來講就是利用 Stargate 之間的 Side Link 做一個 LFA（Loop Free Alternative）。
如下 圖 site A 有 4 個 Super Nodes，Site B 有兩個 Super Nodes，如果藍色鏈路 A4 到 B1/B2 故障，A4 會 把流量調度去 A1/A2/A3，A1/A2/A3 都有直連鏈路到 B1/B4，都是 LFA。故障節點 A4 會用 Greedy 算法來預留 Side Link 的帶寬。
這個流量調度層次上，沒有必要，技術上也不可行引入另一層 IP-in-（IPinIP）封裝。引入另一層 Tunnel 會帶來 load Balance，性能和芯片支持問題。所以在 Super Node 裡面調度，沒有采用另加的 tunnel 頭。
▌B4 SDN 控制器
Google 全球 TE 服務器，蒐集從 BwE（帶寬控制）匯聚來的各個 DC Cluster 主機流量請求，並接 受允許 host 發送流量。TE 服務器跟 SDN GW 網關來通訊，指導 B4 採用 Hybrid SDN 模式，拓撲 發現採用 IGP，對於 Tunnel 和 flow 的管理採用 OpenFlow，最早採用 ACL 來映射相應 prefix 到不 同的 tunnel，後來改為 VFP/LPM 表。
B4 控制器在每個 Site 有多個 SDN 控制器，一般一個控制器管理一個 building 裡面的幾十臺交換機 （SuperNode 超級核心）。
全球化SDN部署經驗教訓
▌SDN 控制器和 Openflow Agent
一個好的 SDN 系統，首先要保證控制器的冗餘（採用類似 Paxos/Zookeeper 機制實現），並且能 夠保證到被控制設備的通道暢通。
每個 Stargate site OFC 需要控制大概(16 Spine+32 Leaf)*4= 192 switches。而且需要動態調整 TE，下發交換機轉發表項。
最早的 Google B4 控制器，控制報文和數據報文混跑。通常Server的CPU很快，Switch 的 CPU 稍慢，Switch 的轉發表更新就更慢了。而且最早 Openflow 控制器和OFA之間僅僅支持單一 Connection。導致 server 發出來的消息經常會排隊，每次網絡流量鏈路變化，所有涉及到的 tunnel 都要重新 program，產生很多 Flow Rules 變更（F）。Flow 變更需要等待交換機硬件完全下發。導致了協議報文（P）可能會丟失，導致拓撲變化和連鎖反應。
Google 的解決方案是在 controller 裡把協議報文，和 Flow Rules 的放到不同優先級的隊列，採用 Token based Queue，只有協議報文發送完畢才進行 Flow Rule 的調度。並且在 OFA 側採用異步調度。極大的提高了控制器的穩定性。
『點評』：很基礎的架構設計，所有路由器廠商都有主控（SDN）和接口（Agent）板卡，這個問題已經在廠家設備解決了20+多年。
▌Flow Group 映射
現有商用芯片有各種各樣 Scale 的限制，如何在有限的表項中，儘可能的支持更大規模的網絡，我們需要十分小心設計轉發。Google B4 的最新設計規避了兩個最大的限制。
Openflow 最早採用 ACL 轉發。但是商業芯片僅支持大概 3K ACL。
sizeACL ≥ numSites × numPrefixes/Site × numServiceClasses
最初 B4 僅能支持 32 site x 16 prefix/site x 6 forwarding classes ~ 3K。隨著 B4 site 增加（2018 年 1 月，33 個站點），不可能繼續利用 ACL 來映射 traffic。
最新的 B4 流量映射採用層次化 FG mapping 採用 DSCP 映射到 6 個不同的 VRF，6 個 VRF 和 Global 轉發表共享芯片的最長匹配表（LPM）高達 128K。從一級 ACL 到兩級 VFP/LPM 轉發，流量映射架構可以支持最多 32 sites 擴展到 1920 site。足夠支持 Google 網絡的長期演進。如果在 VRF 表項裡面找不到精確匹配，兩級轉發架構可以很容易的從 TE 轉發表，fall back 回傳統的 BGP/ISIS 全局轉發表。
『點評』：在 B4 定製化的場景，SuperNode 僅僅承載內部架構的 Prefix，類似 BGP free Core 的設 計理念，仙女座（Andromeda）主機 overlay 管理的客戶的真正路由。把流量分類從 ACL 錶轉移到 FIB 表 LPM 是個很自然的選擇。
▌Hash 功能
層次化 TE 也要求多級 Hash，如果採用一級 Hash，交換機上需要大概 192k ECMP 下一跳 Entry。而一般的交換機僅僅能支持 14K ECMP entry，16K-2K LPM（BGP/ISIS）。
在一個 CLOS 集群上，Edge switch 決定採用哪個 Tunnel。並且採用特殊的 Source MAC 來代表本 地/下一跳 site（TSG）hash 結果。在 Backend Edge 交換機上把不同 MAC 地址報文 hash 到不同的 SuperNode 上。從 Edge switch 處理所有的 Hash 結果，到分佈在 Super Node CLOS 架構中的兩臺 Edge/Backend 交換機，Google 聲稱得到 6%的 Hash 結果優化。
『點評』：這個創新非常類似 2013 年某廠家交換機設計，利用 B 家商用芯片，單芯片僅僅支持很小的 128K FIB，架構師把每個 fabric 芯片做成一個獨立的轉發表。6 塊 Fabric 可以支持 1M 以上的 FIB。路由查表時，首先在板卡做一級查找，然後在 Fabric 卡做二級查表。達到了採用商用小 FIB 表芯片來實現支持 1M Internet 轉發表的功能。太陽底下沒有新鮮事，技術發展是螺旋上升的。
總結
本文詳細講解了 Google B4 的硬件，軟件協議和 SDN 控制器。對國內 OTT 的網絡建設有一定的借鑑意義，本人認為：
①分開 DCI 和 WAN：小型 OTT 還可以繼續採用 DCI 和 WAN 共用混跑同一個網絡。對於中大型的 OTT，需要考慮根據 M2M（Machine to Machine）和 M2U（Machine to User）的流量分開建設 DCI 和 WAN 兩張網絡。
②粗粒度管理：Google 對於網絡從 DC Host 端到端的控制是基於 linux 協議棧的更改和管控，引入了 QUIC 和 TCP BBR 來加強端到端質量管理，計費和控制，管理的顆粒度太細，不太適合國內 OTT，尤其是沒有主機協議棧掌控能力的 OTT。對於 TE 管理，本人更傾向於類似 Facebook Express Backbone 和 Edge Fabric 的做法，針對特定 Prefix 和 Netflow 進行粗粒度管理。網絡診斷可以通過 ePBF 來檢測端到端的每一條 flow。
③大 Buffer 設備：B4 採用自研 Shallow buffer（小 buffer）設備在 WAN，是因為流控在主機 側做了。但是擁塞時丟包很嚴重（10%+），雖然 QUIC/BBR 可以重傳，但是效率不高。 國內 OTT 可以學習採用 Big Buffer 設備部署在 WAN，減少網絡重傳。
④採用 Pizzabox：國內 OTT DC Spine 和 WAN 網絡習慣於採用大機箱設備。從 Google 的做法看，最早數據中心交換機做了大機 Saturn（土星），2012 年演變到 Junpiter（木星）之 後，就完全採用 Pizzabox 構建 DC 和 WAN，9 級 CLOS 部署在數據中心，Stargate{星門 48 （16+32）CLOS 超級節點（super Node）}部署在 WAN。國內 OTT 需要儘快考慮採用類似『Brick』的做法來實現 WAN router 和 DC spine。
⑤採用白盒？OTT 期望軟硬件解耦，隨著 Snoic/Stratum 逐漸成熟，可以逐漸部署在 DC 裡面。但在 WAN 採用白盒還需要考慮路由協議（比如 Opne/R）和 TE Tunnel 管理，鏈路保護等，短時間內採用灰盒或者黑盒更合適，尤其對於大 buffer 的交換機需要等 Sonic/Stratum 方案更成熟。
通過詳細解析 Google B4 和它 5 年的演進歷史，可以看到 B4 的設計理念在 2012/2013 年時非常的先進。但是也受限於歷史包袱和最初系統架構設計，某些地方可以更好的優化，本人覺得 B4 可以在以下方面改進：
①在 B4 引入 Buffer，採用大 buffer Leaf CLOS Brick。可以在增加少量硬件成本的前提下， 極大的減少網絡重傳。
②引入 Segment Routing 構建拓撲和調度分離。Openflow 把拓撲構建和流量調度混在一起。 完全是靜態配置，每更改一個 flow，需要在 7/8 個設備裡面去下發 Flow Rules。SDN 控制 器需要跟 7/8 個設備通訊。引入 SR 之後，僅僅在入口設備上下發策略。需要考慮 SR 在 CLOS Fabric 和 Site 之間的部署。
③P4/ OpenConfig /gRPC/Telemetry 來代替 Openflow/SNMP/，Openflow 僅僅能下發流表， 最新的 P4 可以定義最新報文頭解析，下發流表實現更復雜的功能。並且通過基於 gRPC 的gNMI/gNOI 來實現設備的配置和管理。Google 在業界積極推動 P4/ Openconfig/ Telemetry，相信在下一個 B4 版本會實現更好的 SDN 接口。
2011/2012 年 Google 提出和部署了業界第一個 Global Hybrid SDN 流量工程調度，徹底顛覆了傳統 基於大機和多機（MC）的運營商骨幹網建設思路。Google 更改了 Linux 協議棧，路由協議，轉發 機制（Mapping/ECMP/Tunnel），採用 Scale Out CLOS 路由器的方式支持了 Google 流量 5 年增長 100 倍。
雖然 Google 的方法不太適合中國 OTT（Facebook 的粗顆粒 SDN 方式更適合中國 OTT）。Google 解決實際架構問題中的思考和持續架構演進非常值得國內 OTT 學習。
接下來我沒拿會繼續詳解 Google/Facebook/AWS 等 OTT 網絡架構，下一討論 Google Espresso （意式咖啡）BGP based SDN Peering。然後介紹 Facebook DC, Fabric Aggregator, Express backbone 和 Edge Fabric 等，接下來也會詳解 AWS 架構。敬請期待。
最後非常感謝 Google B4 團隊的開放/開源精神，在 Youtube/SIGCOM 公開了很多詳細的技術細節，使得我們能夠管中窺豹。如果希望跟作者討論『Cloud/OTT SDN 網絡架構』，請掃碼入群。
作者：馬紹文丨郵箱：[email protected]