之后1年的時間，其實也就是業(yè)界各類開源SDN解決方案陸續(xù)出現(xiàn)的階段允华，OpenContrail圈浇、Calico、OpenDayLight靴寂、ONOS磷蜀、Midonet、OVN百炬、Neutron DVR褐隆、Dragonflow等。之后我的更多的精力就放在了真正能處理生產(chǎn)環(huán)境問題的SDN解決方案上剖踊。

1.OpenContrail

當(dāng)時庶弃，OpenContrail的橫空出世，確實是SDN業(yè)界的一顆重磅炸彈德澈。記得該項目剛開源歇攻，就開始評估和測試。OpenContrail確實是一個非常專業(yè)的SDN解決方案梆造，其架構(gòu)并無SPOF缴守，用MPLS VPN實現(xiàn)了隔離，包括在那個時候率先設(shè)計并實現(xiàn)了基于Policy的服務(wù)鏈定義澳窑，非常值得學(xué)習(xí)斧散。不過最終還是放棄跟進(jìn)供常，原因如下：

（1）其軟件框架純粹是Juniper設(shè)計并實現(xiàn)了摊聋，沒有任何指導(dǎo)開發(fā)的文檔（門檻確實較高）。

（2）其轉(zhuǎn)發(fā)面模塊vRouter是Juniper設(shè)計并實現(xiàn)的Linux內(nèi)核模塊栈暇，雖然只是簡單的查詢和轉(zhuǎn)發(fā)數(shù)據(jù)包麻裁，但當(dāng)時在Mailing List上也有公司測試出有crash的現(xiàn)象。當(dāng)時我特地發(fā)消息給社區(qū)，建議社區(qū)盡量把內(nèi)核態(tài)模塊提交給Linux Upstream煎源，保證代碼質(zhì)量色迂。畢竟datapath crash的后果可想而知，沒有穩(wěn)定性手销，談何性能歇僧。

（3）開源社區(qū)并不開放，這個是大多廠商主導(dǎo)的開源社區(qū)的通病锋拖。

（4）畢竟在創(chuàng)業(yè)公司诈悍，很難依靠個人之力去維護(hù)一套龐大的沒有文檔的開源系統(tǒng)。

（5）聽說當(dāng)時國內(nèi)Juniper并無對應(yīng)的技術(shù)支持團(tuán)隊兽埃，就算企業(yè)愿意購買商業(yè)版本侥钳，也需國外遠(yuǎn)程支持，說明Juniper并沒有很好去建設(shè)針對企業(yè)的服務(wù)體系柄错，連企業(yè)級支持都沒舷夺，風(fēng)險挺大。

這些都是很早之前的評估了售貌，之后OpenContrail這個產(chǎn)品發(fā)展越來越好给猾，包括也看到其和Mirantis合作落地了一些項目，不過還都是以Contrail商業(yè)版本為主趁矾。

2.Calico

這個開源項目是比較有趣的針對Neutron SDN的方案耙册，當(dāng)時投入了一些精力在其開源代碼上，受到了很大的啟發(fā)毫捣。Calico設(shè)計的思路其實非常簡單直白详拙，它在每臺計算節(jié)點(diǎn)上安裝了一個BGP Speaker，通過軟件實現(xiàn)了Virtualized L3 Fabric蔓同。然后在架構(gòu)上又引入了BGP Reflector解決full mesh的問題饶辙。雖然API是用的Neutron，但是大多Neutron extension都沒有實現(xiàn)斑粱，也不好實現(xiàn)弃揽，它是Flat Network的解決方案，當(dāng)前還不支持Overlapping-IP则北，最多實現(xiàn)個安全組矿微、但是完美支持了IPv6，其架構(gòu)和Nova-network multihost模式更為接近尚揣，而且由于其控制平面基于BGP涌矢，計算開銷小并且運(yùn)行可靠，運(yùn)維成本低快骗，所以在我眼里娜庇，他是Neutron版本的L3-based multihost模式塔次。這個項目設(shè)計更多是考慮數(shù)據(jù)中心網(wǎng)絡(luò)架構(gòu)，把Neutron的虛擬網(wǎng)絡(luò)與現(xiàn)實世界的DCN實現(xiàn)了整合名秀，是大規(guī)模企業(yè)級私有云的一個可靠的解決方案励负。

3.OpenDayLight

OpenDayLight是一直在跟蹤的項目，它是基于動態(tài)模塊系統(tǒng)構(gòu)建的插件式網(wǎng)絡(luò)操作系統(tǒng)（SDN-OS）匕得，是我見過的功能最為強(qiáng)大的SDN平臺（沒有之一）继榆。從架構(gòu)角度，它是純粹地利用了JavaOSGI框架實現(xiàn)了一個動態(tài)模塊系統(tǒng)汁掠，各個網(wǎng)絡(luò)服務(wù)模塊（無論是南向plugin還是北向plugin）都可以進(jìn)行熱部署裕照，這對于生產(chǎn)環(huán)境運(yùn)維是極大的幫助，因為整個OSGI框架不變的基礎(chǔ)上调塌，每個網(wǎng)絡(luò)服務(wù)都能做到獨(dú)立升級和修改晋南，并且動態(tài)生效，不影響平臺穩(wěn)定性羔砾。而且它設(shè)計并實現(xiàn)了南北向交互的服務(wù)抽象層（AD-SAL和MD-SAL）负间，大大方便了定制開發(fā)。唯一的問題在于AD-SAL和MD-SAL本身姜凄，OpenDayLight項目最早是實現(xiàn)了AD-SAL政溃，其很多成熟的模塊都是基于AD-SAL開發(fā)的，但是之后态秧，發(fā)現(xiàn)設(shè)計的AD-SAL存在擴(kuò)展性和代碼重用的問題董虱，就重新借助Yang模型設(shè)計了MD-SAL，然后希望逐步把AD-SAL實現(xiàn)的模塊重寫變成MD-SAL的申鱼，費(fèi)時費(fèi)力愤诱，當(dāng)前應(yīng)該還是存在兩個不同的SAL框架，建議新的插件都以MD-SAL為主開發(fā)捐友。OpenDayLight還初步實現(xiàn)了集群功能淫半，基于Akka框架實現(xiàn)集群，并且也設(shè)計了支持分布式內(nèi)存數(shù)據(jù)庫匣砖，但是其擴(kuò)展性我沒有評估過科吭，不妄下判斷。從社區(qū)發(fā)展角度講猴鲫，其代碼核心是Cisco實現(xiàn)的对人，之前確實擔(dān)心Cisco獨(dú)裁，但是目前整個項目全部由獨(dú)立的基金會操控拂共，包括代碼貢獻(xiàn)上牺弄，Ericsson、Intel匣缘、Brocade猖闪、Huawei、ETRI等公司和組織都在持續(xù)貢獻(xiàn)肌厨，而且該開源項目已經(jīng)納入了Linux基金會的合作項目培慌。從功能實現(xiàn)的角度講，OpenDayLight是我用過的第一個純粹的網(wǎng)絡(luò)操作系統(tǒng)柑爸，兼容并包各類網(wǎng)絡(luò)技術(shù)吵护，包括OpenFlow1.0和1.3、OVSDB表鳍、BGP馅而、LISP、Netconf譬圣、PCEP瓮恭、SNMP、OpenDove等厘熟，可以做到統(tǒng)管整個DCN（數(shù)據(jù)中心網(wǎng)絡(luò)基礎(chǔ)架構(gòu)）屯蹦，從上層服務(wù)上，提供了包括虛擬多租戶绳姨、服務(wù)鏈登澜、有線電纜通信服務(wù)（DOCSIS）、OpenStackNeutron服務(wù)接口等模塊飘庄。與OpenStack的對接僅僅是其眾多應(yīng)用中的一個脑蠕，相信其在數(shù)據(jù)中心網(wǎng)絡(luò)領(lǐng)域、NFV領(lǐng)域跪削，乃至三網(wǎng)融合領(lǐng)域谴仙，都會取得良好的發(fā)展。

最新版本是Lithium碾盐，在這個版本中狞甚，第一次看到了完整的使用文檔和開發(fā)文檔，這也是我評價一個開源項目是否值得跟進(jìn)的一個重要指標(biāo)（本人痛恨開源社區(qū)耍流氓）廓旬。目前其案例更多來自DCN領(lǐng)域哼审，包括華為和Brocade都有基于OpenDayLight的數(shù)據(jù)中心解決方案產(chǎn)品對外在銷售，而騰訊的數(shù)據(jù)中心網(wǎng)絡(luò)優(yōu)化孕豹，也在使用OpenDayLight涩盾，說明其生產(chǎn)化已經(jīng)成為可能，但從我的角度講励背，確實需要一個專業(yè)的網(wǎng)絡(luò)技術(shù)團(tuán)隊作為服務(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粉喧伞，并且在多個公共場合極力推廣整合解決方案走芋。

4.ONOS

ONOS是另一個龐大的開源網(wǎng)絡(luò)操作系統(tǒng)，它的設(shè)計的目標(biāo)和實現(xiàn)的功能幾乎和OpenDayLight完全相同潘鲫，得到了ONF組織的大力支持（OpenFlow標(biāo)準(zhǔn)制定者）翁逞，是OpenDayLight唯一的市場競爭對手（目前兩個項目都在試探性地開展技術(shù)合作，競合關(guān)系值得期待）溉仑。其發(fā)展滯后于OpenDayLight挖函，代碼主要由Huawei、ETRI浊竟、 ON.Lab等公司和組織參與貢獻(xiàn)挪圾，公司數(shù)目和質(zhì)量還不及OpenDayLight（Huawei在開源道路上戰(zhàn)略很明確，使用人海戰(zhàn)術(shù)不放過任何一個可能的發(fā)展方向）逐沙。它的技術(shù)架構(gòu)都和OpenDayLight類似哲思，也是通過Yang模型定義其抽象層對象，集群實現(xiàn)的發(fā)展從使用Zookeeper吩案、 Hazelcast到最后聽說選擇了Raft棚赔，由于我沒有嘗試使用過和分析過該系統(tǒng)源碼，對其技術(shù)不妄下判斷徘郭，但是從其對OpenStack的支持力度上看靠益，還只是Demo階段，似乎Plugin也沒有完善残揉，希望能盡快看到整合方案胧后，并且從其官網(wǎng)的宣傳上看，落地的生產(chǎn)項目也幾乎沒有抱环。

5.Midonet

Midonet是去年下半年開源的企業(yè)級OpenStack SDN解決方案壳快，也是我介紹的主流方案中唯一一個全球范圍內(nèi)認(rèn)可的企業(yè)級解決方案，畢竟這個是人家Midokura公司賣了2年的產(chǎn)品镇草，非常成熟眶痰，提供了完整的OpenStack網(wǎng)絡(luò)解決方案。從架構(gòu)上講梯啤，第一次將分布式SDN控制器的概念落地竖伯，使用了Zookeeper和Cassandra作為持久化存儲方案（網(wǎng)絡(luò)拓?fù)鋽?shù)據(jù)庫），其控制器分布在每一臺計算節(jié)點(diǎn)上，實現(xiàn)了一個純分布式的控制平面七婴，管理接口通過Restful HTTP Server實現(xiàn)祟偷，數(shù)據(jù)平面利用了Openvswitch datapath，通過分布式路由實現(xiàn)東西向的流量調(diào)度打厘，通過BGP發(fā)布外網(wǎng)網(wǎng)段修肠，是一個沒有SPOF的解決方案，更加精妙的是婚惫，其流表的下發(fā)完全使用Proactive模型，其安全組和防火墻是基于Ingress Filtering的設(shè)計方案魂爪，大大降低了數(shù)據(jù)網(wǎng)絡(luò)的無效流量先舷，其還存在一個簡單的防DDoS模塊；另外它實現(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è)計的，我在閱讀源碼過程中發(fā)現(xiàn)大量無效內(nèi)容秧廉，讓我莫名走了很多的彎路）伞广；第三，它的技術(shù)堆棧主體是基于JVM的Scala語言疼电，任務(wù)管理框架基于Akka赔癌，在云計算技術(shù)中比較冷門，一般需要較長的學(xué)習(xí)周期才能適應(yīng)這門函數(shù)式編程語言及其框架澜沟。 當(dāng)然灾票，我和Midonet的核心開發(fā)人員以及社區(qū)管理員都進(jìn)行過多次面談和電話交流，他們承諾會盡自己努力構(gòu)建一個完善的開源生態(tài)茫虽，希望他們能越走越開放刊苍。

6.OVN

OVN這個項目之所以會拋出既们，就是因為發(fā)現(xiàn)Neutron并不適合于作為完整的SDN控制器使用，僅適合作為整個虛擬網(wǎng)絡(luò)層的北向應(yīng)用（定義API接口）正什。 （就如我之前說的啥纸，專業(yè)的系統(tǒng)讓專業(yè)的人去開發(fā)，OpenStack社區(qū)做好應(yīng)用層和生態(tài)的管理就行了）婴氮。最終斯棒，因為OVS在那個時候就已經(jīng)成為de facto，具有一定的話語權(quán)主经，所以這個社區(qū)也就承擔(dān)了為OpenStack設(shè)計并實現(xiàn)一套能大規(guī)模生產(chǎn)化使用的網(wǎng)絡(luò)系統(tǒng)的任務(wù)荣暮。從技術(shù)架構(gòu)講，這個項目最初的設(shè)計就是參考了Midonet（當(dāng)時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)存儲；部署架構(gòu)上节吮，每臺計算節(jié)點(diǎn)上都部署了ovn-controller作為本地SDN控制進(jìn)程負(fù)責(zé)OpenFlow和OVSDB的通信抽高。從產(chǎn)品成熟度來講，畢竟這個是一個全新剛起步的方案透绩，當(dāng)前還僅僅實現(xiàn)了和Neutron ML2的對接厨内，依照它的Roadmap，明年初就可以完善對接到Neutron ML2 Plugin+Service Plugins渺贤，并且實現(xiàn)分布式路由雏胃；另一個方面，OVSDB-server是一個不支持HA志鞍、Cluster的單點(diǎn)NoSQL數(shù)據(jù)存儲系統(tǒng)瞭亮，所以除非OVN引入更可靠的分布式系統(tǒng)，比如Zookeeper固棚、Cassandra统翩、Raft，否則肯定無法生產(chǎn)環(huán)境使用此洲。還是希望OpenStack東京峰會能有更多利好的消息厂汗，以及待到明年開始具體進(jìn)行測試評估工作。然后從社區(qū)角度講呜师，畢竟和OVS同源娶桦，所以確實是一個值得期待和信任的方案，但是由于其設(shè)計初就綁定了OpenStack，所以和Midonet類似衷畦，無法擴(kuò)展到非CMS（云管理系統(tǒng)）的應(yīng)用場景栗涂。另外，這個項目的核心推動者之一祈争，還是Neutron 前PTL Kile斤程，看來他對Neutron當(dāng)前實現(xiàn)怨念很深啊。

7.Neutron DVR和Dragonflow

這兩個項目是當(dāng)前Neutron社區(qū)設(shè)計并實現(xiàn)的分布式路由解決方案菩混，專門解決東西向流量的問題忿墅。

（1）DVR

這個是Neutron最初的分布式路由方案，由HP主導(dǎo)沮峡，將L3-agent管理的網(wǎng)絡(luò)拓?fù)浞植嫉剿械挠嬎愎?jié)點(diǎn)上疚脐，看似很牛，實則純粹就是個玩具帖烘。為什么那么說亮曹？因為首先橄杨，它的設(shè)計并沒有創(chuàng)新秘症，而是將整個L3的控制和轉(zhuǎn)發(fā)面復(fù)制到了所有的計算節(jié)點(diǎn)，確實開發(fā)省心省力式矫，并且設(shè)計之初就沒有考慮其他高級網(wǎng)絡(luò)服務(wù)對L3Router的依賴乡摹，導(dǎo)致兼容性問題；其次采转，運(yùn)維復(fù)雜度上升不止一個數(shù)量級聪廉， 針對虛擬路由器所定義的本地狀態(tài)（tap, veth peer, router namespace, flow table等等）原本僅分布在某幾臺網(wǎng)絡(luò)節(jié)點(diǎn)（L3-agent）上，現(xiàn)在卻分布在所有的計算節(jié)點(diǎn)上故慈，看似沒有了SPOF板熊，但運(yùn)維難度并沒有降低；然后也是最讓人郁悶的是察绷，整個BP的推動到代碼的編寫充斥著不確定性干签，一方面代碼的實現(xiàn)并不優(yōu)雅，實現(xiàn)過程中都是硬生生地嵌入Neutron已有的代碼中拆撼，之后再發(fā)現(xiàn)問題容劳，提交大量的重構(gòu)去滿足DVR的落地；該功能的代碼寫完提交給社區(qū)進(jìn)行測試后闸度，才發(fā)現(xiàn)原來和社區(qū)已經(jīng)存在的L3 HA竭贩、甚至與存在了1年多的L2pop均有兼容性問題；單元測試和功能測試用例極其不完善莺禁；每個Release都曝出各種High Level的Bugs留量，據(jù)統(tǒng)計大于30+，所以就如我之前說的，給HP和Review BP的人狠狠點(diǎn)贊肪获，各種刷Commits和Reviews的機(jī)會啊寝凌。最后從SDN技術(shù)發(fā)展的角度上說，DVR的推動是Neutron SDN的退步孝赫，它雖然解決了東西向流量集中路由的問題较木，但是在 packet tracing沒有可靠工具的前提下，不僅其增加了datapath的復(fù)雜度青柄，間接導(dǎo)致增加了運(yùn)維的復(fù)雜度伐债，提高了企業(yè)網(wǎng)絡(luò)運(yùn)維的隱形成本，與利用SDN技術(shù)降低OpEx的初衷相反致开。

（2）Dragonflow

這個是Neutron社區(qū)之后推動的第二個分布式路由方案峰锁，完全由Huawei主導(dǎo)，OpenFlow Reactive的設(shè)計思路双戳，利用純流表實現(xiàn)的分布式路由虹蒋，設(shè)計比DVR優(yōu)雅太多，我也沒有時間去做測試評估飒货，但是從設(shè)計文檔看魄衅，確實非常清晰，但由于一方面該項目參與的開發(fā)者并不多塘辅，另一方面項目起步也比較晚晃虫、到目前社區(qū)CI系統(tǒng)還沒能支持該項目的集成測試，所以當(dāng)前是否能直接上生產(chǎn)扣墩，我持保留意見哲银，反正東京峰會快要舉行了，在峰會上應(yīng)該會有一些確定的結(jié)論呻惕。最后要說明Dragonflow只是替代L3-agent的方案荆责，包括與FWaaS、VPNaaS的兼容性問題亚脆，更重要是首包上送的性能做院，還有待生產(chǎn)環(huán)境去考證。所以型酥，和DVR一樣山憨，它的應(yīng)用范圍實在有限，不是一個完整的SDN解決方案弥喉。

8. 本文純屬個人觀點(diǎn)郁竟，請自由拍磚，但本人僅關(guān)注在文章中技術(shù)層面存在嚴(yán)重失誤的拍磚由境。

本文轉(zhuǎn)載自：http://www.infoq.com/cn/articles/sdn-openstack-part02