專欄的初衷就是介紹OpenStack中SDN的種種，這個主題可以說是最對題的。類似的題目很多前輩都說過，我也在這用一個系列來發表一下自己粗淺的觀點吧。這個主題會在4月19日北京國家會議中心全球開源年會做一個簡短的報告，先在知乎上分享一下吧。
網絡的管控能力直接決定了計算集群的規模和性能，這不僅適用于傳統的數據中心，也適用于虛擬化的云數據中心。OpenStack作為私有云IaaS的事實標準，其網絡模塊也一直是各個廠商和使用者關注的重點。
OpenStack自己官方的網絡項目是Neutron，Neutron有著自己的一套網絡實現方案：基于Linuxnamespace，構建一個個相對獨立的虛擬網絡功能單元。通過這些網絡功能單元提供OpenStack所需要的網絡服務。前幾年有爭論說Neutron到底是不是SDN，不知道現在還有沒有這樣的爭論？在我看來，Neutron就是SDN，因為它實現了網絡資源的可編程控制，并且實現了網絡控制層和數據轉發層的分離，這個我在SDN閑聊里面曾經說過。基于OpenFlow的SDN方案只是狹義的SDN概念。
Neutron在自己的實現之外，也考慮了第三方功能的兼容，例如2層的功能被抽象到了ML2的mechanism driver，各個網絡功能被抽象到了對應的service plugin。第三方SDN只需要實現相應的mechanism driver和service plugins，就能接入到OpenStack Neutron。進而在整個OpenStack環境下使用。Neutron的架構如下圖所示：
拋開第三方SDN接入實現不說，單看Neutron的實現。Neutron大體上可以分成兩個部分，Neutron server和agents。
Neutron的北向（northbound）接口，DB接口。Neutron server實現了網絡數據模型的抽象，和基于這些抽象模型的業務邏輯。Neutron server有整個OpenStack的虛擬網絡信息，有關網絡的可達信息和統計數據的計算都將在Neutron server進行。Neutron server可以部署多個，以達到HA的效果，并達到水平擴展的目的。從劃分Controller nodes，Network nodes和Compute nodes的角度來說，Neutron server屬于Controller nodes。
Neutron的南向（southbound）接口。這里的agents指的是各種agents，例如DHCP agent，L3 agent，ovs-agent，metadata-agent，l2gw-agent等等。可以看出來，Neutron的具體網絡功能是由一個個agent完成。Agents可以是Network nodes的一部分，也可以是Compute nodes的一部分，具體要看是什么agent，并且網絡是集中式的還是分布式的。
Neutron server與agents之間通過雙向的RPC進行數據交互。也就是上面圖中的message queue。
Neutron通常與OpenStack其他項目共用一種SQL數據庫。Neutron server是Neutron中唯一與DB有交互的進程或者服務。
OpenStack Neutron是OpenStack社區最活躍的項目之一，集中了大量優秀的工程師參與開發，也是各大公司重點投資的項目。在OpenStack場景下，Neutron的代碼質量和一定用例下的穩定性，是其他SDN方案不能比的。不過它并不是完美的。
單看OpenStack Neutron，它不能提供一套完善的網絡解決方案，早在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層實現。
接下來看看這些SDN吧。
ODL項目成立于2013年4月，是由Linux基金會管理管理的開源SDN項目。項目的目的是提供一個開放的，全功能的，廠商中立的SDN解決方案。目前ODL有超過40個公司作為成員，例如Cisco，IBM，Huawei等。樂觀人士認為：ODL對networking的意義就像Linux對computing的意義一樣。
ODL 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連接了Application Layer和Network Device Layer。使得Application Layer不必關心Network Device的變化性，而只需要關心業務邏輯，另一方面，同一個application通過Control Layer可以適配多種Network Device。
Network Device Layer：網絡設備層，各種各樣的網絡設備和網絡協議，以及接入到ODL的plugin。
OpenStack Neutron通過networking-odl項目接入到OpenDayLight，目前networking-odl的架構如下圖所示：
前面說過Neutron server可以部署多個，以達到HA和水平擴展的目的。ODL接入OpenStack Neutron也考慮了多個Neutron server的情況。Networking-odl包括了同步DB和通過RESTful API訪問OpenDayLight。在OpenDayLight也加入了適配Neutron的module。OpenDayLight的詳細架構如下圖所示：
簡單看一下ODL的架構組成部分：
ODL用來支持多種網絡協議和網絡設備的多個plugin的集合，通過OSGI框架與Service Abstraction Layer連接。為了支持OpenStack Neutron的接入，在ODL southbound protocol中加入了OVSDB的支持。ODL南向協議不僅支持OpenFlow，還支持很多其他協議，因此ODL可以認為是廣義上的SDN。
ODL中，SAL是最重要的組成部分。SAL接收從Controller Platform來的service request，通過自身的plugin manager找到最合適的plugin，也就是southbound protocol，進而通過這個plugin操作特定的網絡設備。另一方面，SAL接收network devices的消息，通過plugin manager抽象消息，再轉發給northbound模塊。SAL是做northbound和southbound的實際轉換工作。
包含了Basic Network Service Function和Platform Service Function。前者是基本網絡功能，后者是廠商平臺對應的模塊。為了適配OpenStack Neutron，在Platform Service Function中有一個OVSDB Neutron模塊。
為Cloud Orchestrator和application提供接口。接口包括了RESTful和OSGI。
論知名度，ODL可以說是最負盛名的SDN，Linux基金會管理，各大廠商支持，使得它從誕生開始就是正規軍。OpenDayLight和OpenStack的結合也是Neutron 前PTL Kyle Mestery極力推動下的結果。從其定位可以看出，它的功能也比較完善，現在也有基于OpenDayLight的解決方案（Cisco等廠商）在售或者部署在數據中心。
另一方面，ODL項目較為龐大，代碼行數多，子項目多，ODL在Boron版本的子項目依賴如下圖所示，可以看出還是比較復雜的。
并且，Cisco是背后的主要推動者，因此項目一定程度是由Cisco控制。作為開源項目，ODL文檔也飽受詬病。綜上所述，ODL的門檻要高一些，如果要落地，還是需要一個專業的團隊支撐。
ONOS（Open Network Operating System），是2014年由ON.Lab（Open Networking Lab）發起的一個開源項目（注，ON.Lab 去年底宣布與ONF合并，所以ONOS以后可能會看到是ONF支持的項目）。ONOS專門針對service provider場景，目的是提供一個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的最上層，業務邏輯層。
ONOS由多個Service或者Subsystem組成，每個Subsystem由多個OSGI模塊組成，這些模塊分布在ONOS的三層中。ONOS的Service／Subsystem如下圖所示：
基于networking-onos的狀態，討論ONOS在OpenStack中的應用似乎意義不大。前面講過ODL和ONOS的共同點，實際中有什么區別？ONOS的定位就是給SP用的SDN，例如電信運營商，因此AT&T將ONOS部署成local SDN controller，將ODL部署成global SDN controller。因為通常在電信應用場景下，環境是是多層的，可能不只一種SDN存在于大環境下。
本文轉載自：https://zhuanlan.zhihu.com/p/25992893
