摘要：Underlay網絡要如何演進，才能滿足5個9的指標？
這幾年公有雲業務急速上漲，network as a service理念越來越深入人心。雲廠商給租戶提供了越來越豐富的雲服務，VPC、LB等服務功能越來越完善。這需要網絡提供靈活編程的能力，可以針對租戶的業務訴求迅速改變策略。而這一理念其實與傳統的網絡是背道而馳的。在傳統網絡觀念中，信奉“穩定壓倒一切”的套路，為了保證網絡穩定，需要盡量減少對於網絡的配置變更。那么，在雲的環境下，網絡如何自處才能滿足既穩定又靈活的要求？
為滿足雲業務的需要，網絡逐漸分化為underlay和overlay。Underlay網絡就是傳統數據中心的路由交換設備，依然信奉穩定壓倒一切的理念，提供可靠的網絡數據傳輸能力；overlay則是在其上封裝的業務網絡，更加跟服務貼近，通過VXLAN 或者GRE等協議封裝，給租戶提供一個易用的網絡服務。Underlay網絡和overlay網絡即關聯又解耦，兩者相互關聯又能獨立演進。
今天主要是講一下underlay網絡的演進策略。Underlay網絡是整個公有雲的地基，承載網絡不穩，業務便無SLA可言。特別隨着雲上承載的業務越來越龐大，客戶越來越多，對於underlay網絡的穩定性要求越來越高。Underlay網絡要如何演進，才能滿足5個9的指標？
傳統的“胖樹”網絡，結構簡單，維護方便，但是隨着組網規模的擴大，卻存在很多問題。
1、 二層穩定性問題
傳統以POD為拓展交付單元的網絡，POD使用大規格交換機做匯聚，POD內多為二層組網。破解二層環路的常用方案有2種：STP+VRRP、堆疊
VRRP+STP是傳統數據中心最常用的組網方案，網關通過VRRP冗余，環路通過STP破環，真是傳統網絡的“黃金搭檔”。然而，隨着組網規模做大，當TOR的數量達到100台以上時，stp協議會面臨較大挑戰，計算偶然性錯誤，收斂時間慢等。100台TOR，按每台40個下行口計算，服務器雙歸接入，可以支持規模2K。規模也還算可觀，可一旦STP出現問題，2K服務器全都受影響，就不太能接受了。
堆疊，堆疊可以直接規避掉環路的問題，維護起來也簡單很多。可是堆疊終究也是一個大二層，大二層就存在風暴一起癱的風險。並且堆疊系統無法平滑升級，一直是運維工程師心中的痛，匯聚一堆疊，升級的風險就太大了。
2、 帶寬收斂問題
胖樹結構，通過增加上層設備的線路帶寬和線路數量的方式增加帶寬。但隨着規模的增加，下掛服務器越來越多，TOR越來越多，匯聚到核心的連線往往不足以實現無收斂組網。且再多的連線，都是從某台設備上出來的，此設備故障，帶寬損失太嚴重。
3、 拓展性問題
按照AWS提供的數據，一個雲數據中心的規模，在6W時的規模收益是最大的。而胖樹方案要支持6W台服務器接入，基本不太可能。哪怕真的接上了，任何一台骨干設備故障，引起的網絡問題是難以預計的。就跟電影《長城》中饕餮的陣型一樣，所有饕餮都圍繞獸王行動，獸王一死全軍覆沒。
那么在公有雲的業務訴求中，underlay網絡如何發展，才能滿足它即可靠又支持大規模無收斂的“人設”呢？那當然是clos，scale out，anycast等潮流玩法（也沒那么潮流，人家10年前就做出來了）
給大家分享一下google和Facebook的做法，這兩家公司的組網堪稱業績標桿。
Google：
Google還是保留了類似於POD的概念，但他們的POD有4台匯聚，而且上行所對接的核心數量，想要多少有多少，完全超出了傳統的范疇。N個核心之間與每一個POD匯聚之間都有互聯，任意兩個POD之間，有4*N條線路互通，任意一條掛掉，基本無影響。
POD四台匯聚，網關在哪里？這么多條線路，怎么做的管理和路由？
要做成這樣的組網，肯定不是改改連線方式就能搞定的。underlay的網關需要下沉到TOR上，TOR上行匯聚直接跑動態路由協議，匯聚和核心之間也跑動態路由協議，形成多條等價路徑。報文可以隨意轉發，條條大路通羅馬。
傳統的OSPF、BGP等動態路由協議，能支持的ECMP路徑畢竟是受限的。Google自己改造了傳統的動態路由協議，讓他可以支持更多地等價路徑，更快速地發現線路問題。
Facebook：
上圖是Facebook典型的樂高組網，分了多個層次多個平面。下層的每一個平面對應了一個POD，POD的匯聚有自己組成多個平面與核心之間組成一個上一級POD。
這樣看可能會有點暈，我們簡化一下如下：
- 每一個POD有48台TOR，每台服務器只出1根線接入到1台TOR
- 每一台TOR上行對接4個匯聚，每一個匯聚上行對接48個核心
- 任意2台服務器之間，有4*48=192條通路
- 任意1台TOR故障，軟件自己做冗余，業務不受影響
- 任意1台匯聚或核心故障，業務基本不感知
這樣的組網，業務跑在上面，是不是有一種很踏實的感覺。
總結一下這兩家公司網絡的特點：
1、去中心化，不再存在唯一的匯聚或者核心，而是拓展了多台
2、網關下沉到TOR，TOR以上為路由轉發，抑制二層廣播域擴散
3、多條等價路徑，核心匯聚之間線路冗余高，任何一台設備一條線路故障基本無影響
以上是我們可以直接從物理圖上看出來的，而在“看不到”的地方，還做了更多地優化：
1、 硬件設備控制器，所有設備統一管理，配置標准化
2、 設備監控信息上報通道，任何鏈路皆有完善監控
3、 流量調度能力，線路有擁塞，流量調度到其他鏈路
當然，還有好多優化，是筆者無法知道的，但這些優化肯定都有一個共同的目的：網絡更加穩定。
互聯網的設計理念，永遠不相信單點的可靠性。要通過冗余設計，達到任何一個節點故障，均無法影響整體業務的目的。基礎網絡也是如此，隨着雲上承載的業務越來越多，若底層網絡不穩定，受損的業務會越來越多，造成的損失不是扛可以扛過去的。所有底層網絡的設計理念，必然要圍繞“無論如何業務都不能down”的方向努力。Google、Facebook的組網算是我們的先驅，國內的各個雲廠商其實也在用類似的組網方案。
物理架構的fabric，帶來的是工程上的可靠性。而很多的故障模式，物理架構不一定能cover住。還必須要設計出與之匹配的軟件，才能更好的保證網絡的穩定運行。相比於物理架構來說，監控、調度等軟件能力的補齊更加重要。
現在越來越多的公司在推行“白牌”交換機，其實是把傳統交換機的系統打開了，給傳統封閉的交換機系統打上API接口，可以通過編程系統直接調度，獲取內部更多信息，以方便針對各種情況，做出調整。比如，交換機丟包分析，遠程抓包，指定流監控，指定流調度等能力。
傳統的交換機，雖然功能齊全，但是相對於公有雲來說，齊全的功能未必不是一種累贅。剛好齊全的功能，加上開放可編程的系統，才是雲的需要。你看，AWS都要自己出交換機了。