OpenStack中SDN泛談1 (Neutron&ODL&ONOS)

專欄的初衷就是介紹OpenStack中SDN的種種，這個主題可以說是最對題的。類似的題目很多前輩都說過，我也在這用一個系列來發表一下自己粗淺的觀點吧。這個主題會在4月19日北京國家會議中心全球開源年會做一個簡短的報告，先在知乎上分享一下吧。

網路的管控能力直接決定了計算集群的規模和性能，這不僅適用於傳統的數據中心，也適用於虛擬化的雲數據中心。OpenStack作為私有雲IaaS的事實標準，其網路模塊也一直是各個廠商和使用者關注的重點。

OpenStack Neutron

OpenStack自己官方的網路項目是Neutron，Neutron有著自己的一套網路實現方案：基於linux namespace，構建一個個相對獨立的虛擬網路功能單元。通過這些網路功能單元提供OpenStack所需要的網路服務。前幾年有爭論說Neutron到底是不是SDN，不知道現在還有沒有這樣的爭論？在我看來，Neutron就是SDN，因為它實現了網路資源的可編程式控制制，並且實現了網路控制層和數據轉發層的分離，這個我在SDN閑聊裡面曾經說過。基於OpenFlow的SDN方案只是狹義的SDN概念。

nnnnnnnnnnnnnnnNeutron在自己的實現之外，也考慮了第三方功能的兼容，例如2層的功能被抽象到了ML2的mechanism driver，各個網路功能被抽象到了對應的service plugin。第三方SDN只需要實現相應的mechanism driver和service plugins，就能接入到OpenStack Neutron。進而在整個OpenStack環境下使用。Neutron的架構如下圖所示：

拋開第三方SDN接入實現不說，單看Neutron的實現。Neutron大體上可以分成兩個部分，Neutronnserver和agents。

Neutron server

Neutron的北向（northbound）介面，DB介面。Neutron server實現了網路數據模型的抽象，和基於這些抽象模型的業務邏輯。Neutron server有整個OpenStack的虛擬網路信息，有關網路的可達信息和統計數據的計算都將在Neutron server進行。Neutronnserver可以部署多個，以達到HA的效果，並達到水平擴展的目的。從劃分Controller nodes，Network nodes和Compute nodes的角度來說，Neutronnserver屬於Controllernnodes。

Agents

Neutron的南向（southbound）介面。這裡的agents指的是各種agents，例如DHCP agent，L3 agent，ovs-agent，metadata-agent，l2gw-agent等等。可以看出來，Neutron的具體網路功能是由一個個agent完成。Agents可以是Networknnodes的一部分，也可以是Computennodes的一部分，具體要看是什麼agent，並且網路是集中式的還是分散式的。

RPC（Remote Procedure Call）

Neutron server與agents之間通過雙向的RPC進行數據交互。也就是上面圖中的message queue。

DB（Database）

nnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnNeutron通常與OpenStack其他項目共用一種SQL資料庫。Neutron server是Neutron中唯一與DB有交互的進程或者服務。

總結

OpenStack Neutron是OpenStack社區最活躍的項目之一，集中了大量優秀的工程師參與開發，也是各大公司重點投資的項目。在OpenStack場景下，Neutron的代碼質量和一定用例下的穩定性，是其他SDN方案不能比的。不過它並不是完美的。

單看OpenStacknNeutron，它不能提供一套完善的網路解決方案，早在Kilo版本，曾經在Neutron代碼庫中的LBaaS，VPNaaS，FWaaS的功能代碼就被分離出Neutron。從那時起，OpenStack Neutron項目自身就致力於只提供2-3層網路服務，4-7層服務由Neutron的子項目提供。開源項目一個大問題就是開發碎片化，因為沒有統一的管理。Neutron這樣的拆分，能降低核心代碼的管理難度，但無疑也加劇了碎片化的程度。分離出去的子項目發展不均衡，很多項目活躍度大大降低。

另一方面，基於SQL和RPC的網路計算實現，以及一些其他的實現細節，使得Neutron在大規模部署時表現不盡如人意。雖然最近有一些文章和測試為Neutron的實現正名，但是具體的轉變還是需要等待時間的驗證。

總的來說，不像Ceph之於存儲，OpenStack中不存在（包括Neutron自身的實現）一個壓倒一切的SDN實現。這就導致各個廠商更熱衷於在OpenStack中推廣自家的SDN方案，而不是在一起開發一個默認的廠商中立的SDN方案（例如Neutron的默認實現）。這進而分散了Neutron的開發力量，使得Neutron的默認實現進步變得緩慢。

從現在的趨勢來看，我認為OpenvSwitch已經是OpenStack的默認網路底層實現，根據之前的一項調查，有48%的OpenStack用戶使用OpenvSwitch。OpenvSwitch社區自身也熱衷於為OpenStack提供網路底層。上層網路方案上，各個廠商希望自己能夠引領OpenStack的SDN實現，像Cisco，Midokura，Juniper，Huawei分別推出自己的SDN，甚至OVS也在推自己的SDN方案。這些SDN的共同特點是各自實現了4-7層的網路服務支持，有些也提供了更優化的2-3層實現。

nnnnnnnnnnnnnnnnnnnnnnnnnnnnn接下來看看這些SDN吧。

OpenDayLight

ODL項目成立於2013年4月，是由Linux基金會管理管理的開源SDN項目。項目的目的是提供一個開放的，全功能的，廠商中立的SDN解決方案。目前ODL有超過40個公司作為成員，例如Cisco，IBM，Huawei等。樂觀人士認為：ODL對networking的意義就像Linux對computing的意義一樣。

nnODL controller是一個純軟體的實現，基於Java+OSGI，運行在自己的JVM中，理論上，任何支持Java的設備都能運行ODL。採用OSGI作為框架，基於這點可以看出ODL內部是一個個相對獨立的模塊。ODL項目最開始的定位是SDN controller，在它的第三個版本（Lithium版本），ODL將自己的定位變成了SDN Platform。也就是說ODL的定位開始轉變成以SDN為核心構建生態系統。

ODL的架構大致如下，可以分為三層。

• Application Layer：邏輯業務層，不關心底部網路設備，網路協議的實現。通過RESTful介面和OSGI接入到Control Layer。

• Coordination，Control Layer：對應SDN控制器，實現網路功能，並將抽象網路模型轉換成實際的網路底層數據，並下發到網路設備。Control Layer連接了ApplicationnLayer和NetworknDevice Layer。使得ApplicationnLayer不必關心NetworknDevice的變化性，而只需要關心業務邏輯，另一方面，同一個application通過ControlnLayer可以適配多種NetworknDevice。

• Network Device Layer：網路設備層，各種各樣的網路設備和網路協議，以及接入到ODL的plugin。

OpenStack Neutron通過networking-odl項目接入到OpenDayLight，目前networking-odl的架構如下圖所示：

nnnnnnnnnnnnnnn前面說過Neutron server可以部署多個，以達到HA和水平擴展的目的。ODL接入OpenStack Neutron也考慮了多個Neutron server的情況。Networking-odl包括了同步DB和通過RESTful API訪問OpenDayLight。在OpenDayLight也加入了適配Neutron的module。OpenDayLight的詳細架構如下圖所示：

簡單看一下ODL的架構組成部分：

ODL southbound protocol

ODL用來支持多種網路協議和網路設備的多個plugin的集合，通過OSGI框架與Service Abstraction Layer連接。為了支持OpenStack Neutron的接入，在ODL southbound protocol中加入了OVSDB的支持。ODL南向協議不僅支持OpenFlow，還支持很多其他協議，因此ODL可以認為是廣義上的SDN。

Service Abstraction Layer

nnnnnnnnnnnnnnnnnnnnnnnnnODL中，SAL是最重要的組成部分。SAL接收從Controller Platform來的service request，通過自身的plugin manager找到最合適的plugin，也就是southbound protocol，進而通過這個plugin操作特定的網路設備。另一方面，SAL接收network devices的消息，通過plugin manager抽象消息，再轉發給northbound模塊。SAL是做northbound和southbound的實際轉換工作。

Controller Platform

包含了BasicnNetwork Service Function和PlatformnService Function。前者是基本網路功能，後者是廠商平台對應的模塊。為了適配OpenStack Neutron，在Platform Service Function中有一個OVSDB Neutron模塊。

Northbound APIs

nnnnnn為Cloud Orchestrator和application提供介面。介面包括了RESTful和OSGI。

總結

論知名度，ODL可以說是最負盛名的SDN，Linux基金會管理，各大廠商支持，使得它從誕生開始就是正規軍。OpenDayLight和OpenStack的結合也是Neutron 前PTL KylenMestery極力推動下的結果。從其定位可以看出，它的功能也比較完善，現在也有基於OpenDayLight的解決方案（Cisco等廠商）在售或者部署在數據中心。

另一方面，ODL項目較為龐大，代碼行數多，子項目多，ODL在Boron版本的子項目依賴如下圖所示，可以看出還是比較複雜的。

並且，Cisco是背後的主要推動者，因此項目一定程度是由Cisco控制。作為開源項目，ODL文檔也飽受詬病。綜上所述，ODL的門檻要高一些，如果要落地，還是需要一個專業的團隊支撐。

ONOS

ONOS（Open Network Operating System），是2014年由ON.Lab（OpennNetworking Lab）發起的一個開源項目（注，ON.Labn去年底宣布與ONF合併，所以ONOS以後可能會看到是ONF支持的項目）。ONOS專門針對servicenprovider場景，目的是提供一個SDN系統。這是一個與ODL有很多類似地方的項目。

• 它們都支持都是Linux基金會管理的項目

• 它們都基於OSGI實現

• 它們都支持多種南向協議，屬於廣義上的SDN

• 都是HA，模塊化，可擴展的SDN

ONOS通過networking-onos項目與OpenStack集成。不過這個項目的參與度似乎很低。可見其與OpenStack的集成並不好。ONOS也是提供一個分層的結構，北向提供REST API，南向兼容多種網路協議和控制協議，簡單看一下這個項目的架構吧。

可以分成三層：

• Provider：支持多種網路協議和控制協議，連接網路設備，並且讀取網路設備的信息，向上發送的Manager。

• Manager：承上啟下，連接Application和Provider。Store也位於這一層，store負責同步多個ONOS實例之間的數據。

• Application：ONOS的最上層，業務邏輯層。

Services/Subsystems

ONOS由多個Service或者Subsystem組成，每個Subsystem由多個OSGI模塊組成，這些模塊分布在ONOS的三層中。ONOS的Service／Subsystem如下圖所示：

總結

基於networking-onos的狀態，討論ONOS在OpenStack中的應用似乎意義不大。前面講過ODL和ONOS的共同點，實際中有什麼區別？ONOS的定位就是給SP用的SDN，例如電信運營商，因此AT&T將ONOS部署成local SDNncontroller，將ODL部署成global SDN controller。因為通常在電信應用場景下，環境是是多層的，可能不只一種SDN存在於大環境下。

推薦閱讀：