Orion：谷歌的新一代SDN控制器

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

在今年的NSDI會議上，谷歌發(fā)表論文，詳細闡述了其第二代SDN控制器Orion的設(shè)計原則、整體架構(gòu)和在生產(chǎn)網(wǎng)絡(luò)中的應(yīng)用情況。

盡管是最近才發(fā)表的論文，但Orion已經(jīng)在現(xiàn)網(wǎng)中運行了四年，可謂是“久經(jīng)考驗”。

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

█ 谷歌網(wǎng)絡(luò)情況簡介

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

其中B4是谷歌的數(shù)據(jù)中心互聯(lián)網(wǎng)絡(luò)，連接了谷歌全球的數(shù)據(jù)中心。B2是谷歌面向互聯(lián)網(wǎng)的網(wǎng)絡(luò)，負責(zé)將用戶業(yè)務(wù)從全球各地的POP點引入到數(shù)據(jù)中心。而Jupiter，則是谷歌數(shù)據(jù)中心的內(nèi)部網(wǎng)絡(luò)。

這里再補充談一下谷歌網(wǎng)絡(luò)承載的業(yè)務(wù)流量屬性。

直到現(xiàn)在，很多運營商專家都表示谷歌的流量基本是自有業(yè)務(wù)，因此可控性好，更適合SDN。而運營商網(wǎng)絡(luò)的流量情況，則過于復(fù)雜。

事實上，隨著谷歌產(chǎn)品線的擴展，尤其是云服務(wù)業(yè)務(wù)的增長，谷歌網(wǎng)絡(luò)內(nèi)的流量不可預(yù)測性也在不斷提升。很大一部分流量，已經(jīng)不再是自有業(yè)務(wù)。

█ 谷歌的第一代SDN

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

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

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

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

第一階段是2010年開始引入openflow交換機，但新交換機對外的表現(xiàn)和傳統(tǒng)交換機一樣，只是網(wǎng)絡(luò)協(xié)議運算在controller而不是設(shè)備本身完成。第二階段是一個漫長的流量切換過程。直到2012年開始，流量才完全切換到openflow網(wǎng)絡(luò)。

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

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

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

█ Orion的整體情況

Orion本身的工作模式，一個詞總結(jié)，就是調(diào)和（reconciliation）。

一方面，Orion接收網(wǎng)絡(luò)管理方（人或者上層應(yīng)用）的意圖并層層翻譯。另一方面，不斷地感知當前網(wǎng)絡(luò)的實際運行狀態(tài)，然后將網(wǎng)絡(luò)的運行狀態(tài)逐漸調(diào)整向管理方意圖靠攏。

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

而從架構(gòu)上看，Orion則是一個典型的微服務(wù)應(yīng)用。

最上層是各種具體的網(wǎng)絡(luò)應(yīng)用，如負責(zé)域內(nèi)算路的Routing Engine以及負責(zé)BGP廣播的Raven等。

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

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

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

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

█ Orion的設(shè)計考慮

作為面向超大規(guī)模生產(chǎn)網(wǎng)絡(luò)的控制器，意圖驅(qū)動（intent-based）是必然選擇。

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

Orion處理故障的原則也非常值得學(xué)習(xí)：對于小問題積極處理，對于大問題則直接躺平（不干涉數(shù)據(jù)面狀態(tài)）。

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

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

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

最后一點是關(guān)于管理通道的問題。

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

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

█ 結(jié)語

網(wǎng)絡(luò)運營，追求的無非是安全和高效。

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

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

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

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

這幾年來，在網(wǎng)絡(luò)智能化上，筆者也做了一些微小的工作?？偟膩碚f，遇到的困難不少，取得的成果也不算大。但我仍然堅信，SDN就是未來。畢竟，夢想還是要有的。