作者 |?魏煌松

來源 |?鮮棗課堂

時至今日，谷歌在2015年公布的成果，“利用SDN將廣域網帶寬利用率提升至接近100%”，仍然是SDN的一個標桿案列，也是難以逾越的巔峰。但事實上，當時使用的SDN控制器Onix，早已退出了歷史舞臺。

在今年的NSDI會議上，谷歌發表論文，詳細闡述了其第二代SDN控制器Orion的設計原則、整體架構和在生產網絡中的應用情況。

盡管是最近才發表的論文，但Orion已經在現網中運行了四年，可謂是“久經考驗”。

今天這篇文章會分為幾個部分，包括介紹谷歌網絡的整體情況，回顧第一代SDN控制器Onix，簡要闡述谷歌新一代SDN控制器Orion的情況和幾個重要的設計考慮。

█ 谷歌網絡情況簡介

如圖所示，谷歌的網絡主要分成三大部分，B4、B2（也叫Espresso）以及Jupiter。

其中B4是谷歌的數據中心互聯網絡，連接了谷歌全球的數據中心。B2是谷歌面向互聯網的網絡，負責將用戶業務從全球各地的POP點引入到數據中心。而Jupiter，則是谷歌數據中心的內部網絡。

這里再補充談一下谷歌網絡承載的業務流量屬性。

直到現在，很多運營商專家都表示谷歌的流量基本是自有業務，因此可控性好，更適合SDN。而運營商網絡的流量情況，則過于復雜。

事實上，隨著谷歌產品線的擴展，尤其是云服務業務的增長，谷歌網絡內的流量不可預測性也在不斷提升。很大一部分流量，已經不再是自有業務。

█ 谷歌的第一代SDN

谷歌的第一代SDN控制器Onix，總的來說有這么幾點值得注意：

一是Onix本身是合作研發而非自研，二是Onix的引入是一個循序漸進的過程，三是Onix是一個單體（molonithic）程序。

Onix的研發是Nicara、NEC和谷歌合作進行的，甚至Nicara的專家還扮演了非常重要的角色。但到了Orion，從論文上看，作者已經是清一色的谷歌員工。可以說谷歌的網絡團隊在這幾年中是在飛速成長的。

Onix投產的過程，也是循序漸進的，大概花了三年完成切換。

第一階段是2010年開始引入openflow交換機，但新交換機對外的表現和傳統交換機一樣，只是網絡協議運算在controller而不是設備本身完成。第二階段是一個漫長的流量切換過程。直到2012年開始，流量才完全切換到openflow網絡。

Onix作為一個單體程序，其很多固有局限性基本無法解決，這也是Orion出現的理由。

單體程序在穩定性和開發速度上，都存在很大的劣勢。以谷歌的實力發布一個新版本都需要5個月，這個節奏和業務發展是明顯不相稱的。

微服務版本的Orion上線后，兩周就可以發布一個版本，并且還有望提升到一周。分布式程序穩定性大增，控制器完全崩潰的幾率變得更小。

█ Orion的整體情況

Orion本身的工作模式，一個詞總結，就是調和（reconciliation）。

一方面，Orion接收網絡管理方（人或者上層應用）的意圖并層層翻譯。另一方面，不斷地感知當前網絡的實際運行狀態，然后將網絡的運行狀態逐漸調整向管理方意圖靠攏。

從設計的根本原理上看，和Kubernetes的原理幾乎一致。

而從架構上看，Orion則是一個典型的微服務應用。

最上層是各種具體的網絡應用，如負責域內算路的Routing Engine以及負責BGP廣播的Raven等。

中間的核心層主要實現了控制器的通用功能，包括一個集中的NIB數據庫（兼具消息隊列功能）和負責處理配置、拓撲及流表生成的管理器，以及用于和路由器通信的OFE。

各個模塊之間都是微服務，主要通過NIB承載的消息進行交互，這也很好的保障了故障隔離性及開發的可協調性。

值得注意的是，Orion控制的所有路由器均只有openflow協議棧，沒有傳統協議棧，包括BGP信息的廣播和接收，都是在控制器上完成，可以說徹底實現了SDN化。

當然，出于安全性的考慮，Orion并不是一點集中的控制器，而是分域部署的。這在犧牲一些全局性帶來的優勢（如算路更優，流表更新更快等）的同時，也最大程度確保了網絡的健壯性。

█ Orion的設計考慮

作為面向超大規模生產網絡的控制器，意圖驅動（intent-based）是必然選擇。

谷歌表示宏觀的意圖遠比細鎖的過程更穩定，更不容易出錯。因此Orion本身就被設計為一個逐層翻譯和細化意圖的控制器，最終會將管理人員的意圖翻譯為交換機可識別的openflow原語（primitives）。

Orion處理故障的原則也非常值得學習：對于小問題積極處理，對于大問題則直接躺平（不干涉數據面狀態）。

如圖所示，一個數據流自頂向下的三層路由器網絡中，如果感知到2個路由器損壞，則Orion會牽引流量繞開損壞的路由器，這就是fail-closed。

而如果感知到四個路由器都損壞了，則Orion不會再做任何操作，保持數據面當前狀態，也就是fail-static。

這是因為一方面小問題Orion可以在不影響現網流量的情況下進行處理，但大問題的處理則會嚴重影響現有業務；另一方面數據面出現大問題的幾率其實很小，更大的可能是管理通道或者控制器本身出現問題，因此感知到大面積故障誤報的可能性很大。

最后一點是關于管理通道的問題。

一般認為帶外管理因為具有單獨的管理通道，會是更可靠的方式。但管理通道本身也可能損壞，且大量網元均通過帶外管理也會產生巨大的成本。

因此，Orion采用了帶內管理和帶外管理相結合的方式：一方面只對重要設備進行帶外管理，這樣節省了大量成本；另一方面帶內管理和帶外管理互為備份，避免管理通道的損壞導致網元徹底脫管。??????

█ 結語

網絡運營，追求的無非是安全和高效。

SDN本身就是為了高效而生的，經過業界多年的實踐，這一點已經沒有太大的爭議，其效率的提升是實實在在的。而現在爭議最大的，主要聚焦在安全和實施成本上。

考慮到網絡的自然迭代，成本其實不是問題，逐步轉型就好。谷歌也不是一夜之間把路由器都替換掉的。

而安全方面，我想谷歌的論文以及業界的其他實踐，已經解答了很多技術上的問題。剩下的問題，更多是意識層面的：是靠算法調度流量更安全，還是深夜的雙人割接更安全？是靠經驗反復分析、層層把關的割接報告更可靠，還是軟件自動計算的drain analysis更準確？

這些問題的答案并不是那么顯然，因為安全的定義其實是很復雜的。

總的來說，遇到的困難不少，取得的成果也不算大。但我仍然堅信，SDN就是未來。畢竟，夢想還是要有的。

往期推薦

虛幻引擎5上的《黑客帝國》全新體驗，愛了愛了

元宇宙真的是割韭菜嗎？

Log4j 第三次發布漏洞補丁，漏洞或將長存

低代碼發展專訪系列之六：低代碼平臺能解決業務重構的問題嗎？

點分享

點收藏

點點贊

點在看

總結

以上是生活随笔為你收集整理的Orion：谷歌的新一代SDN控制器的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。