之后1年的時(shí)間，其實(shí)也就是業(yè)界各類開源SDN解決方案陸續(xù)出現(xiàn)的階段，OpenContrail、Calico、OpenDayLight、ONOS、Midonet、OVN、Neutron DVR、Dragonflow等。之后我的更多的精力就放在了真正能處理生產(chǎn)環(huán)境問題的SDN解決方案上。
當(dāng)時(shí)，OpenContrail的橫空出世，確實(shí)是SDN業(yè)界的一顆重磅炸彈。記得該項(xiàng)目剛開源，就開始評(píng)估和測(cè)試。OpenContrail確實(shí)是一個(gè)非常專業(yè)的SDN解決方案，其架構(gòu)并無SPOF，用MPLS VPN實(shí)現(xiàn)了隔離，包括在那個(gè)時(shí)候率先設(shè)計(jì)并實(shí)現(xiàn)了基于Policy的服務(wù)鏈定義，非常值得學(xué)習(xí)。不過最終還是放棄跟進(jìn)，原因如下：
（1）其軟件框架純粹是Juniper設(shè)計(jì)并實(shí)現(xiàn)了，沒有任何指導(dǎo)開發(fā)的文檔（門檻確實(shí)較高）。
（2）其轉(zhuǎn)發(fā)面模塊vRouter是Juniper設(shè)計(jì)并實(shí)現(xiàn)的Linux內(nèi)核模塊，雖然只是簡(jiǎn)單的查詢和轉(zhuǎn)發(fā)數(shù)據(jù)包，但當(dāng)時(shí)在Mailing List上也有公司測(cè)試出有crash的現(xiàn)象。當(dāng)時(shí)我特地發(fā)消息給社區(qū)，建議社區(qū)盡量把內(nèi)核態(tài)模塊提交給Linux Upstream，保證代碼質(zhì)量。畢竟datapath crash的后果可想而知，沒有穩(wěn)定性，談何性能。
（3）開源社區(qū)并不開放，這個(gè)是大多廠商主導(dǎo)的開源社區(qū)的通病。
（4）畢竟在創(chuàng)業(yè)公司，很難依靠個(gè)人之力去維護(hù)一套龐大的沒有文檔的開源系統(tǒng)。
（5）聽說當(dāng)時(shí)國內(nèi)Juniper并無對(duì)應(yīng)的技術(shù)支持團(tuán)隊(duì)，就算企業(yè)愿意購買商業(yè)版本，也需國外遠(yuǎn)程支持，說明Juniper并沒有很好去建設(shè)針對(duì)企業(yè)的服務(wù)體系，連企業(yè)級(jí)支持都沒，風(fēng)險(xiǎn)挺大。
這些都是很早之前的評(píng)估了，之后OpenContrail這個(gè)產(chǎn)品發(fā)展越來越好，包括也看到其和Mirantis合作落地了一些項(xiàng)目，不過還都是以Contrail商業(yè)版本為主。
這個(gè)開源項(xiàng)目是比較有趣的針對(duì)Neutron SDN的方案，當(dāng)時(shí)投入了一些精力在其開源代碼上，受到了很大的啟發(fā)。Calico設(shè)計(jì)的思路其實(shí)非常簡(jiǎn)單直白，它在每臺(tái)計(jì)算節(jié)點(diǎn)上安裝了一個(gè)BGP Speaker，通過軟件實(shí)現(xiàn)了Virtualized L3 Fabric。然后在架構(gòu)上又引入了BGP Reflector解決full mesh的問題。雖然API是用的Neutron，但是大多Neutron extension都沒有實(shí)現(xiàn)，也不好實(shí)現(xiàn)，它是Flat Network的解決方案，當(dāng)前還不支持Overlapping-IP，最多實(shí)現(xiàn)個(gè)安全組、但是完美支持了IPv6，其架構(gòu)和Nova-network multihost模式更為接近，而且由于其控制平面基于BGP，計(jì)算開銷小并且運(yùn)行可靠，運(yùn)維成本低，所以在我眼里，他是Neutron版本的L3-based multihost模式。這個(gè)項(xiàng)目設(shè)計(jì)更多是考慮數(shù)據(jù)中心網(wǎng)絡(luò)架構(gòu)，把Neutron的虛擬網(wǎng)絡(luò)與現(xiàn)實(shí)世界的DCN實(shí)現(xiàn)了整合，是大規(guī)模企業(yè)級(jí)私有云的一個(gè)可靠的解決方案。
OpenDayLight是一直在跟蹤的項(xiàng)目，它是基于動(dòng)態(tài)模塊系統(tǒng)構(gòu)建的插件式網(wǎng)絡(luò)操作系統(tǒng)（SDN-OS），是我見過的功能最為強(qiáng)大的SDN平臺(tái)（沒有之一）。從架構(gòu)角度，它是純粹地利用了JavaOSGI框架實(shí)現(xiàn)了一個(gè)動(dòng)態(tài)模塊系統(tǒng)，各個(gè)網(wǎng)絡(luò)服務(wù)模塊（無論是南向plugin還是北向plugin）都可以進(jìn)行熱部署，這對(duì)于生產(chǎn)環(huán)境運(yùn)維是極大的幫助，因?yàn)檎麄€(gè)OSGI框架不變的基礎(chǔ)上，每個(gè)網(wǎng)絡(luò)服務(wù)都能做到獨(dú)立升級(jí)和修改，并且動(dòng)態(tài)生效，不影響平臺(tái)穩(wěn)定性。而且它設(shè)計(jì)并實(shí)現(xiàn)了南北向交互的服務(wù)抽象層（AD-SAL和MD-SAL），大大方便了定制開發(fā)。唯一的問題在于AD-SAL和MD-SAL本身，OpenDayLight項(xiàng)目最早是實(shí)現(xiàn)了AD-SAL，其很多成熟的模塊都是基于AD-SAL開發(fā)的，但是之后，發(fā)現(xiàn)設(shè)計(jì)的AD-SAL存在擴(kuò)展性和代碼重用的問題，就重新借助Yang模型設(shè)計(jì)了MD-SAL，然后希望逐步把AD-SAL實(shí)現(xiàn)的模塊重寫變成MD-SAL的，費(fèi)時(shí)費(fèi)力，當(dāng)前應(yīng)該還是存在兩個(gè)不同的SAL框架，建議新的插件都以MD-SAL為主開發(fā)。OpenDayLight還初步實(shí)現(xiàn)了集群功能，基于Akka框架實(shí)現(xiàn)集群，并且也設(shè)計(jì)了支持分布式內(nèi)存數(shù)據(jù)庫，但是其擴(kuò)展性我沒有評(píng)估過，不妄下判斷。從社區(qū)發(fā)展角度講，其代碼核心是Cisco實(shí)現(xiàn)的，之前確實(shí)擔(dān)心Cisco獨(dú)裁，但是目前整個(gè)項(xiàng)目全部由獨(dú)立的基金會(huì)操控，包括代碼貢獻(xiàn)上，Ericsson、Intel、Brocade、Huawei、ETRI等公司和組織都在持續(xù)貢獻(xiàn)，而且該開源項(xiàng)目已經(jīng)納入了Linux基金會(huì)的合作項(xiàng)目。從功能實(shí)現(xiàn)的角度講，OpenDayLight是我用過的第一個(gè)純粹的網(wǎng)絡(luò)操作系統(tǒng)，兼容并包各類網(wǎng)絡(luò)技術(shù)，包括OpenFlow1.0和1.3、OVSDB、BGP、LISP、Netconf、PCEP、SNMP、OpenDove等，可以做到統(tǒng)管整個(gè)DCN（數(shù)據(jù)中心網(wǎng)絡(luò)基礎(chǔ)架構(gòu)），從上層服務(wù)上，提供了包括虛擬多租戶、服務(wù)鏈、有線電纜通信服務(wù)（DOCSIS）、OpenStackNeutron服務(wù)接口等模塊。與OpenStack的對(duì)接僅僅是其眾多應(yīng)用中的一個(gè)，相信其在數(shù)據(jù)中心網(wǎng)絡(luò)領(lǐng)域、NFV領(lǐng)域，乃至三網(wǎng)融合領(lǐng)域，都會(huì)取得良好的發(fā)展。
最新版本是Lithium，在這個(gè)版本中，第一次看到了完整的使用文檔和開發(fā)文檔，這也是我評(píng)價(jià)一個(gè)開源項(xiàng)目是否值得跟進(jìn)的一個(gè)重要指標(biāo)（本人痛恨開源社區(qū)耍流氓）。目前其案例更多來自DCN領(lǐng)域，包括華為和Brocade都有基于OpenDayLight的數(shù)據(jù)中心解決方案產(chǎn)品對(duì)外在銷售，而騰訊的數(shù)據(jù)中心網(wǎng)絡(luò)優(yōu)化，也在使用OpenDayLight，說明其生產(chǎn)化已經(jīng)成為可能，但從我的角度講，確實(shí)需要一個(gè)專業(yè)的網(wǎng)絡(luò)技術(shù)團(tuán)隊(duì)作為服務(wù)支撐才行。OpenDayLight生產(chǎn)環(huán)境運(yùn)維，以及基于OSGI模型的二次研發(fā)，都是需要投入一定的成本的。 當(dāng)前OpenDayLight與OpenStack的整合，也在按部就班的進(jìn)行，并且完全跟隨著OpenStack社區(qū)的研發(fā)腳步，完整提供了ML2 Plugin和一部分Service Plugin。話說，Neutron 前PTL Kile就是OpenDayLight粉，并且在多個(gè)公共場(chǎng)合極力推廣整合解決方案。
ONOS是另一個(gè)龐大的開源網(wǎng)絡(luò)操作系統(tǒng)，它的設(shè)計(jì)的目標(biāo)和實(shí)現(xiàn)的功能幾乎和OpenDayLight完全相同，得到了ONF組織的大力支持（OpenFlow標(biāo)準(zhǔn)制定者），是OpenDayLight唯一的市場(chǎng)競(jìng)爭(zhēng)對(duì)手（目前兩個(gè)項(xiàng)目都在試探性地開展技術(shù)合作，競(jìng)合關(guān)系值得期待）。其發(fā)展滯后于OpenDayLight，代碼主要由Huawei、ETRI、 ON.Lab等公司和組織參與貢獻(xiàn)，公司數(shù)目和質(zhì)量還不及OpenDayLight（Huawei在開源道路上戰(zhàn)略很明確，使用人海戰(zhàn)術(shù)不放過任何一個(gè)可能的發(fā)展方向）。它的技術(shù)架構(gòu)都和OpenDayLight類似，也是通過Yang模型定義其抽象層對(duì)象，集群實(shí)現(xiàn)的發(fā)展從使用Zookeeper、 Hazelcast到最后聽說選擇了Raft，由于我沒有嘗試使用過和分析過該系統(tǒng)源碼，對(duì)其技術(shù)不妄下判斷，但是從其對(duì)OpenStack的支持力度上看，還只是Demo階段，似乎Plugin也沒有完善，希望能盡快看到整合方案，并且從其官網(wǎng)的宣傳上看，落地的生產(chǎn)項(xiàng)目也幾乎沒有。
Midonet是去年下半年開源的企業(yè)級(jí)OpenStack SDN解決方案，也是我介紹的主流方案中唯一一個(gè)全球范圍內(nèi)認(rèn)可的企業(yè)級(jí)解決方案，畢竟這個(gè)是人家Midokura公司賣了2年的產(chǎn)品，非常成熟，提供了完整的OpenStack網(wǎng)絡(luò)解決方案。從架構(gòu)上講，第一次將分布式SDN控制器的概念落地，使用了Zookeeper和Cassandra作為持久化存儲(chǔ)方案（網(wǎng)絡(luò)拓?fù)鋽?shù)據(jù)庫），其控制器分布在每一臺(tái)計(jì)算節(jié)點(diǎn)上，實(shí)現(xiàn)了一個(gè)純分布式的控制平面，管理接口通過Restful HTTP Server實(shí)現(xiàn)，數(shù)據(jù)平面利用了Openvswitch datapath，通過分布式路由實(shí)現(xiàn)東西向的流量調(diào)度，通過BGP發(fā)布外網(wǎng)網(wǎng)段，是一個(gè)沒有SPOF的解決方案，更加精妙的是，其流表的下發(fā)完全使用Proactive模型，其安全組和防火墻是基于Ingress Filtering的設(shè)計(jì)方案，大大降低了數(shù)據(jù)網(wǎng)絡(luò)的無效流量，其還存在一個(gè)簡(jiǎn)單的防DDoS模塊；另外它實(shí)現(xiàn)了Virtual Single Hop，虛擬網(wǎng)絡(luò)內(nèi)任意兩點(diǎn)間均只存在單跳。所以從架構(gòu)、性能、穩(wěn)定性上，Midonet都是最適合大規(guī)模生產(chǎn)環(huán)境使用的SDN解決方案，并且已經(jīng)得到了OpenStack業(yè)界權(quán)威RedHat和Mirantis的認(rèn)證支持。但是，它也不是完美的。第一，和OpenDayLight/ONOS不同，Midonet僅支持OpenStack和VMware，無法脫離OpenStack和vSphere單獨(dú)使用；第二，其雖然開源，但是從governance model看，完全是掌握在Midokura公司手里，并且沒有指導(dǎo)開發(fā)的技術(shù)文檔（其在Github上的開發(fā)文檔都是完全落后于其當(dāng)前代碼設(shè)計(jì)的，我在閱讀源碼過程中發(fā)現(xiàn)大量無效內(nèi)容，讓我莫名走了很多的彎路）；第三，它的技術(shù)堆棧主體是基于JVM的Scala語言，任務(wù)管理框架基于Akka，在云計(jì)算技術(shù)中比較冷門，一般需要較長(zhǎng)的學(xué)習(xí)周期才能適應(yīng)這門函數(shù)式編程語言及其框架。 當(dāng)然，我和Midonet的核心開發(fā)人員以及社區(qū)管理員都進(jìn)行過多次面談和電話交流，他們承諾會(huì)盡自己努力構(gòu)建一個(gè)完善的開源生態(tài)，希望他們能越走越開放。
OVN這個(gè)項(xiàng)目之所以會(huì)拋出，就是因?yàn)榘l(fā)現(xiàn)Neutron并不適合于作為完整的SDN控制器使用，僅適合作為整個(gè)虛擬網(wǎng)絡(luò)層的北向應(yīng)用（定義API接口）。 （就如我之前說的，專業(yè)的系統(tǒng)讓專業(yè)的人去開發(fā)，OpenStack社區(qū)做好應(yīng)用層和生態(tài)的管理就行了）。最終，因?yàn)镺VS在那個(gè)時(shí)候就已經(jīng)成為de facto，具有一定的話語權(quán)，所以這個(gè)社區(qū)也就承擔(dān)了為OpenStack設(shè)計(jì)并實(shí)現(xiàn)一套能大規(guī)模生產(chǎn)化使用的網(wǎng)絡(luò)系統(tǒng)的任務(wù)。從技術(shù)架構(gòu)講，這個(gè)項(xiàng)目最初的設(shè)計(jì)就是參考了Midonet（當(dāng)時(shí)Midonet已經(jīng)得到了大家的注意），但是由于OVS社區(qū)是基于C stack的，所以架構(gòu)雖然類似，但卻更多利用了已有的OVS代碼進(jìn)行改造，比如它的數(shù)據(jù)持久化方案，完全借助其已經(jīng)在使用的OVSDB-server作為全局的網(wǎng)絡(luò)拓?fù)鋽?shù)據(jù)庫和本地狀態(tài)存儲(chǔ)；部署架構(gòu)上，每臺(tái)計(jì)算節(jié)點(diǎn)上都部署了ovn-controller作為本地SDN控制進(jìn)程負(fù)責(zé)OpenFlow和OVSDB的通信。從產(chǎn)品成熟度來講，畢竟這個(gè)是一個(gè)全新剛起步的方案，當(dāng)前還僅僅實(shí)現(xiàn)了和Neutron ML2的對(duì)接，依照它的Roadmap，明年初就可以完善對(duì)接到Neutron ML2 Plugin+Service Plugins，并且實(shí)現(xiàn)分布式路由；另一個(gè)方面，OVSDB-server是一個(gè)不支持HA、Cluster的單點(diǎn)NoSQL數(shù)據(jù)存儲(chǔ)系統(tǒng)，所以除非OVN引入更可靠的分布式系統(tǒng)，比如Zookeeper、Cassandra、Raft，否則肯定無法生產(chǎn)環(huán)境使用。還是希望OpenStack東京峰會(huì)能有更多利好的消息，以及待到明年開始具體進(jìn)行測(cè)試評(píng)估工作。然后從社區(qū)角度講，畢竟和OVS同源，所以確實(shí)是一個(gè)值得期待和信任的方案，但是由于其設(shè)計(jì)初就綁定了OpenStack，所以和Midonet類似，無法擴(kuò)展到非CMS（云管理系統(tǒng)）的應(yīng)用場(chǎng)景。另外，這個(gè)項(xiàng)目的核心推動(dòng)者之一，還是Neutron 前PTL Kile，看來他對(duì)Neutron當(dāng)前實(shí)現(xiàn)怨念很深啊。
這兩個(gè)項(xiàng)目是當(dāng)前Neutron社區(qū)設(shè)計(jì)并實(shí)現(xiàn)的分布式路由解決方案，專門解決東西向流量的問題。
（1）DVR
這個(gè)是Neutron最初的分布式路由方案，由HP主導(dǎo)，將L3-agent管理的網(wǎng)絡(luò)拓?fù)浞植嫉剿械挠?jì)算節(jié)點(diǎn)上，看似很牛，實(shí)則純粹就是個(gè)玩具。為什么那么說？因?yàn)槭紫?，它的設(shè)計(jì)并沒有創(chuàng)新，而是將整個(gè)L3的控制和轉(zhuǎn)發(fā)面復(fù)制到了所有的計(jì)算節(jié)點(diǎn)，確實(shí)開發(fā)省心省力，并且設(shè)計(jì)之初就沒有考慮其他高級(jí)網(wǎng)絡(luò)服務(wù)對(duì)L3Router的依賴，導(dǎo)致兼容性問題；其次，運(yùn)維復(fù)雜度上升不止一個(gè)數(shù)量級(jí)， 針對(duì)虛擬路由器所定義的本地狀態(tài)（tap, veth peer, router namespace, flow table等等）原本僅分布在某幾臺(tái)網(wǎng)絡(luò)節(jié)點(diǎn)（L3-agent）上，現(xiàn)在卻分布在所有的計(jì)算節(jié)點(diǎn)上，看似沒有了SPOF，但運(yùn)維難度并沒有降低；然后也是最讓人郁悶的是，整個(gè)BP的推動(dòng)到代碼的編寫充斥著不確定性，一方面代碼的實(shí)現(xiàn)并不優(yōu)雅，實(shí)現(xiàn)過程中都是硬生生地嵌入Neutron已有的代碼中，之后再發(fā)現(xiàn)問題，提交大量的重構(gòu)去滿足DVR的落地；該功能的代碼寫完提交給社區(qū)進(jìn)行測(cè)試后，才發(fā)現(xiàn)原來和社區(qū)已經(jīng)存在的L3 HA、甚至與存在了1年多的L2pop均有兼容性問題；單元測(cè)試和功能測(cè)試用例極其不完善；每個(gè)Release都曝出各種High Level的Bugs，據(jù)統(tǒng)計(jì)大于30+，所以就如我之前說的，給HP和Review BP的人狠狠點(diǎn)贊，各種刷Commits和Reviews的機(jī)會(huì)啊。最后從SDN技術(shù)發(fā)展的角度上說，DVR的推動(dòng)是Neutron SDN的退步，它雖然解決了東西向流量集中路由的問題，但是在 packet tracing沒有可靠工具的前提下，不僅其增加了datapath的復(fù)雜度，間接導(dǎo)致增加了運(yùn)維的復(fù)雜度，提高了企業(yè)網(wǎng)絡(luò)運(yùn)維的隱形成本，與利用SDN技術(shù)降低OpEx的初衷相反。
（2）Dragonflow
這個(gè)是Neutron社區(qū)之后推動(dòng)的第二個(gè)分布式路由方案，完全由Huawei主導(dǎo)，OpenFlow Reactive的設(shè)計(jì)思路，利用純流表實(shí)現(xiàn)的分布式路由，設(shè)計(jì)比DVR優(yōu)雅太多，我也沒有時(shí)間去做測(cè)試評(píng)估，但是從設(shè)計(jì)文檔看，確實(shí)非常清晰，但由于一方面該項(xiàng)目參與的開發(fā)者并不多，另一方面項(xiàng)目起步也比較晚、到目前社區(qū)CI系統(tǒng)還沒能支持該項(xiàng)目的集成測(cè)試，所以當(dāng)前是否能直接上生產(chǎn)，我持保留意見，反正東京峰會(huì)快要舉行了，在峰會(huì)上應(yīng)該會(huì)有一些確定的結(jié)論。最后要說明Dragonflow只是替代L3-agent的方案，包括與FWaaS、VPNaaS的兼容性問題，更重要是首包上送的性能，還有待生產(chǎn)環(huán)境去考證。所以，和DVR一樣，它的應(yīng)用范圍實(shí)在有限，不是一個(gè)完整的SDN解決方案。
8. 本文純屬個(gè)人觀點(diǎn)，請(qǐng)自由拍磚，但本人僅關(guān)注在文章中技術(shù)層面存在嚴(yán)重失誤的拍磚。
本文轉(zhuǎn)載自：http://www.infoq.com/cn/articles/sdn-openstack-part02
