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

網(wǎng)絡(luò)的管控能力直接決定了計算集群的規(guī)模和性能，這不僅適用于傳統(tǒng)的數(shù)據(jù)中心，也適用于虛擬化的云數(shù)據(jù)中心。OpenStack作為私有云IaaS的事實(shí)標(biāo)準(zhǔn)，其網(wǎng)絡(luò)模塊也一直是各個廠商和使用者關(guān)注的重點(diǎn)。

OpenStack Neutron

OpenStack自己官方的網(wǎng)絡(luò)項(xiàng)目是Neutron，Neutron有著自己的一套網(wǎng)絡(luò)實(shí)現(xiàn)方案：基于Linuxnamespace，構(gòu)建一個個相對獨(dú)立的虛擬網(wǎng)絡(luò)功能單元。通過這些網(wǎng)絡(luò)功能單元提供OpenStack所需要的網(wǎng)絡(luò)服務(wù)。前幾年有爭論說Neutron到底是不是SDN，不知道現(xiàn)在還有沒有這樣的爭論？在我看來，Neutron就是SDN，因?yàn)樗鼘?shí)現(xiàn)了網(wǎng)絡(luò)資源的可編程控制，并且實(shí)現(xiàn)了網(wǎng)絡(luò)控制層和數(shù)據(jù)轉(zhuǎn)發(fā)層的分離，這個我在SDN閑聊里面曾經(jīng)說過?；贠penFlow的SDN方案只是狹義的SDN概念。

Neutron在自己的實(shí)現(xiàn)之外，也考慮了第三方功能的兼容，例如2層的功能被抽象到了ML2的mechanism driver，各個網(wǎng)絡(luò)功能被抽象到了對應(yīng)的service plugin。第三方SDN只需要實(shí)現(xiàn)相應(yīng)的mechanism driver和service plugins，就能接入到OpenStack Neutron。進(jìn)而在整個OpenStack環(huán)境下使用。Neutron的架構(gòu)如下圖所示：

拋開第三方SDN接入實(shí)現(xiàn)不說，單看Neutron的實(shí)現(xiàn)。Neutron大體上可以分成兩個部分，Neutron server和agents。

Neutron server

Neutron的北向（northbound）接口，DB接口。Neutron server實(shí)現(xiàn)了網(wǎng)絡(luò)數(shù)據(jù)模型的抽象，和基于這些抽象模型的業(yè)務(wù)邏輯。Neutron server有整個OpenStack的虛擬網(wǎng)絡(luò)信息，有關(guān)網(wǎng)絡(luò)的可達(dá)信息和統(tǒng)計數(shù)據(jù)的計算都將在Neutron server進(jìn)行。Neutron server可以部署多個，以達(dá)到HA的效果，并達(dá)到水平擴(kuò)展的目的。從劃分Controller nodes，Network nodes和Compute nodes的角度來說，Neutron server屬于Controller nodes。

Agents

Neutron的南向（southbound）接口。這里的agents指的是各種agents，例如DHCP agent，L3 agent，ovs-agent，metadata-agent，l2gw-agent等等?？梢钥闯鰜?，Neutron的具體網(wǎng)絡(luò)功能是由一個個agent完成。Agents可以是Network nodes的一部分，也可以是Compute nodes的一部分，具體要看是什么agent，并且網(wǎng)絡(luò)是集中式的還是分布式的。

RPC（Remote Procedure Call）

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

DB（Database）

Neutron通常與OpenStack其他項(xiàng)目共用一種SQL數(shù)據(jù)庫。Neutron server是Neutron中唯一與DB有交互的進(jìn)程或者服務(wù)。

總結(jié)

OpenStack Neutron是OpenStack社區(qū)最活躍的項(xiàng)目之一，集中了大量優(yōu)秀的工程師參與開發(fā)，也是各大公司重點(diǎn)投資的項(xiàng)目。在OpenStack場景下，Neutron的代碼質(zhì)量和一定用例下的穩(wěn)定性，是其他SDN方案不能比的。不過它并不是完美的。

單看OpenStack Neutron，它不能提供一套完善的網(wǎng)絡(luò)解決方案，早在Kilo版本，曾經(jīng)在Neutron代碼庫中的LBaaS，VPNaaS，F(xiàn)WaaS的功能代碼就被分離出Neutron。從那時起，OpenStack Neutron項(xiàng)目自身就致力于只提供2-3層網(wǎng)絡(luò)服務(wù)，4-7層服務(wù)由Neutron的子項(xiàng)目提供。開源項(xiàng)目一個大問題就是開發(fā)碎片化，因?yàn)闆]有統(tǒng)一的管理。Neutron這樣的拆分，能降低核心代碼的管理難度，但無疑也加劇了碎片化的程度。分離出去的子項(xiàng)目發(fā)展不均衡，很多項(xiàng)目活躍度大大降低。

另一方面，基于SQL和RPC的網(wǎng)絡(luò)計算實(shí)現(xiàn)，以及一些其他的實(shí)現(xiàn)細(xì)節(jié)，使得Neutron在大規(guī)模部署時表現(xiàn)不盡如人意。雖然最近有一些文章和測試為Neutron的實(shí)現(xiàn)正名，但是具體的轉(zhuǎn)變還是需要等待時間的驗(yàn)證。

總的來說，不像Ceph之于存儲，OpenStack中不存在（包括Neutron自身的實(shí)現(xiàn)）一個壓倒一切的SDN實(shí)現(xiàn)。這就導(dǎo)致各個廠商更熱衷于在OpenStack中推廣自家的SDN方案，而不是在一起開發(fā)一個默認(rèn)的廠商中立的SDN方案（例如Neutron的默認(rèn)實(shí)現(xiàn)）。這進(jìn)而分散了Neutron的開發(fā)力量，使得Neutron的默認(rèn)實(shí)現(xiàn)進(jìn)步變得緩慢。

從現(xiàn)在的趨勢來看，我認(rèn)為OpenvSwitch已經(jīng)是OpenStack的默認(rèn)網(wǎng)絡(luò)底層實(shí)現(xiàn)，根據(jù)之前的一項(xiàng)調(diào)查，有48%的OpenStack用戶使用OpenvSwitch。OpenvSwitch社區(qū)自身也熱衷于為OpenStack提供網(wǎng)絡(luò)底層。上層網(wǎng)絡(luò)方案上，各個廠商希望自己能夠引領(lǐng)OpenStack的SDN實(shí)現(xiàn)，像Cisco，Midokura，Juniper，Huawei分別推出自己的SDN，甚至OVS也在推自己的SDN方案。這些SDN的共同特點(diǎn)是各自實(shí)現(xiàn)了4-7層的網(wǎng)絡(luò)服務(wù)支持，有些也提供了更優(yōu)化的2-3層實(shí)現(xiàn)。

接下來看看這些SDN吧。

OpenDayLight

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

ODL controller是一個純軟件的實(shí)現(xiàn)，基于Java+OSGI，運(yùn)行在自己的JVM中，理論上，任何支持Java的設(shè)備都能運(yùn)行ODL。采用OSGI作為框架，基于這點(diǎn)可以看出ODL內(nèi)部是一個個相對獨(dú)立的模塊。ODL項(xiàng)目最開始的定位是SDN controller，在它的第三個版本（Lithium版本），ODL將自己的定位變成了SDN Platform。也就是說ODL的定位開始轉(zhuǎn)變成以SDN為核心構(gòu)建生態(tài)系統(tǒng)。

ODL的架構(gòu)大致如下，可以分為三層。

Application Layer：邏輯業(yè)務(wù)層，不關(guān)心底部網(wǎng)絡(luò)設(shè)備，網(wǎng)絡(luò)協(xié)議的實(shí)現(xiàn)。通過RESTful接口和OSGI接入到Control Layer。

Coordination，Control Layer：對應(yīng)SDN控制器，實(shí)現(xiàn)網(wǎng)絡(luò)功能，并將抽象網(wǎng)絡(luò)模型轉(zhuǎn)換成實(shí)際的網(wǎng)絡(luò)底層數(shù)據(jù)，并下發(fā)到網(wǎng)絡(luò)設(shè)備。Control Layer連接了Application Layer和Network Device Layer。使得Application Layer不必關(guān)心Network Device的變化性，而只需要關(guān)心業(yè)務(wù)邏輯，另一方面，同一個application通過Control Layer可以適配多種Network Device。

Network Device Layer：網(wǎng)絡(luò)設(shè)備層，各種各樣的網(wǎng)絡(luò)設(shè)備和網(wǎng)絡(luò)協(xié)議，以及接入到ODL的plugin。

OpenStack Neutron通過networking-odl項(xiàng)目接入到OpenDayLight，目前networking-odl的架構(gòu)如下圖所示：

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

簡單看一下ODL的架構(gòu)組成部分：

ODL southbound protocol

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

Service Abstraction Layer

ODL中，SAL是最重要的組成部分。SAL接收從Controller Platform來的service request，通過自身的plugin manager找到最合適的plugin，也就是southbound protocol，進(jìn)而通過這個plugin操作特定的網(wǎng)絡(luò)設(shè)備。另一方面，SAL接收network devices的消息，通過plugin manager抽象消息，再轉(zhuǎn)發(fā)給northbound模塊。SAL是做northbound和southbound的實(shí)際轉(zhuǎn)換工作。

Controller Platform

包含了Basic Network Service Function和Platform Service Function。前者是基本網(wǎng)絡(luò)功能，后者是廠商平臺對應(yīng)的模塊。為了適配OpenStack Neutron，在Platform Service Function中有一個OVSDB Neutron模塊。

Northbound APIs

為Cloud Orchestrator和application提供接口。接口包括了RESTful和OSGI。

總結(jié)

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

另一方面，ODL項(xiàng)目較為龐大，代碼行數(shù)多，子項(xiàng)目多，ODL在Boron版本的子項(xiàng)目依賴如下圖所示，可以看出還是比較復(fù)雜的。

并且，Cisco是背后的主要推動者，因此項(xiàng)目一定程度是由Cisco控制。作為開源項(xiàng)目，ODL文檔也飽受詬病。綜上所述，ODL的門檻要高一些，如果要落地，還是需要一個專業(yè)的團(tuán)隊(duì)支撐。

ONOS

ONOS（Open Network Operating System），是2014年由ON.Lab（Open Networking Lab）發(fā)起的一個開源項(xiàng)目（注，ON.Lab 去年底宣布與ONF合并，所以O(shè)NOS以后可能會看到是ONF支持的項(xiàng)目）。ONOS專門針對service provider場景，目的是提供一個SDN系統(tǒng)。這是一個與ODL有很多類似地方的項(xiàng)目。

它們都支持都是Linux基金會管理的項(xiàng)目

它們都基于OSGI實(shí)現(xiàn)

它們都支持多種南向協(xié)議，屬于廣義上的SDN

都是HA，模塊化，可擴(kuò)展的SDN

ONOS通過networking-onos項(xiàng)目與OpenStack集成。不過這個項(xiàng)目的參與度似乎很低。可見其與OpenStack的集成并不好。ONOS也是提供一個分層的結(jié)構(gòu)，北向提供REST API，南向兼容多種網(wǎng)絡(luò)協(xié)議和控制協(xié)議，簡單看一下這個項(xiàng)目的架構(gòu)吧。

可以分成三層：

Provider：支持多種網(wǎng)絡(luò)協(xié)議和控制協(xié)議，連接網(wǎng)絡(luò)設(shè)備，并且讀取網(wǎng)絡(luò)設(shè)備的信息，向上發(fā)送的Manager。

Manager：承上啟下，連接Application和Provider。Store也位于這一層，store負(fù)責(zé)同步多個ONOS實(shí)例之間的數(shù)據(jù)。

Application：ONOS的最上層，業(yè)務(wù)邏輯層。

Services/Subsystems

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

總結(jié)

基于networking-onos的狀態(tài)，討論ONOS在OpenStack中的應(yīng)用似乎意義不大。前面講過ODL和ONOS的共同點(diǎn)，實(shí)際中有什么區(qū)別？ONOS的定位就是給SP用的SDN，例如電信運(yùn)營商，因此AT&T將ONOS部署成local SDN controller，將ODL部署成global SDN controller。因?yàn)橥ǔＴ陔娦艖?yīng)用場景下，環(huán)境是是多層的，可能不只一種SDN存在于大環(huán)境下。

本文轉(zhuǎn)載自：https://zhuanlan.zhihu.com/p/25992893