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

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

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

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

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

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

如圖所示，谷歌的網(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ò)，負(fù)責(zé)將用戶業(yè)務(wù)從全球各地的POP點(diǎn)引入到數(shù)據(jù)中心。而Jupiter，則是谷歌數(shù)據(jù)中心的內(nèi)部網(wǎng)絡(luò)。

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

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

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

█ 谷歌的第一代SDN

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

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

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

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

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

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

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

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

█ Orion的整體情況

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

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

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

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

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

中間的核心層主要實(shí)現(xiàn)了控制器的通用功能，包括一個(gè)集中的NIB數(shù)據(jù)庫(kù)（兼具消息隊(duì)列功能）和負(fù)責(zé)處理配置、拓?fù)浼傲鞅砩傻墓芾砥鳎约坝糜诤?a class="article-link" target="_blank" href="/tag/%E8%B7%AF%E7%94%B1%E5%99%A8/">路由器通信的OFE。

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

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

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

█ Orion的設(shè)計(jì)考慮

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

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

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

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

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

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

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

一般認(rèn)為帶外管理因?yàn)榫哂袉为?dú)的管理通道，會(huì)是更可靠的方式。但管理通道本身也可能損壞，且大量網(wǎng)元均通過帶外管理也會(huì)產(chǎn)生巨大的成本。

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

█ 結(jié)語(yǔ)

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

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

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

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

這些問題的答案并不是那么顯然，因?yàn)榘踩亩x其實(shí)是很復(fù)雜的。

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