時至今日，谷歌在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就是未來。畢竟，夢想還是要有的。