這一篇講一下基于OpenvSwitch的SDN平挑。
OVN（Open Virtual Network）是OVS社區(qū)在2015年1月發(fā)起的OVS子項目厌衙，其代碼與OVS在一個庫里面。OVN提供了一個可在大規(guī)模環(huán)境下部署的润梯、產(chǎn)品級別的輕量級SDN。
在之前（2014年）的一個調(diào)查中，OpenvSwitch已經(jīng)成為了OpenStack中最受歡迎的virtual switch斧账，OVS為hypervisor提供了虛擬的網(wǎng)絡(luò)設(shè)備，共同參與構(gòu)建虛擬環(huán)境煞肾。鑒于OVS的廣泛接受程度咧织，并為了讓OVS能勝任更多的場景，OVS社區(qū)提出提供一個輕量級的控制平面籍救，借助這個控制平面拯爽，可以在虛擬網(wǎng)絡(luò)設(shè)備之上實現(xiàn)OVS對虛擬網(wǎng)絡(luò)的支持。
基于這個出發(fā)點钧忽，OVN在創(chuàng)立之初只關(guān)注2-3層的虛擬網(wǎng)絡(luò)毯炮，這是區(qū)別于其他全功能的SDN控制器或者平臺。OVN可以看成是OVS的補充耸黑，因此OVN可以運行在任何OVS兼容的環(huán)境下桃煎。雖然兩者在一個項目下，OVN與OVS的連接采用的是OVS的通用接口大刊，因此ovs-vswitchd和ovsdb-server不會因為OVN而受到影響（說Midonet呢）为迈。另一方面三椿，就算不使用OVN，對OVS本身也沒有什么影響葫辐。
隨著OVS 2.6的發(fā)布搜锰，OVN的第一個版本也隨著發(fā)布（包含在OVS中），OVN從創(chuàng)立之初就考慮了與OpenStack的集成耿战。OVN通過networking-ovn項目與OpenStack集成蛋叼。Networking-ovn項目也是Neutron前PTL Kyle Mestery發(fā)起的項目。他后來跳槽到IBM剂陡，我曾經(jīng)有幸在他的lead下參與過OVN的開發(fā)工作狈涮。
下面看看OVN的架構(gòu)：
在OVS的基礎(chǔ)上，OVN新增了兩個進程：ovn-northd和ovn-controller鸭栖，兩個數(shù)據(jù)庫：Northbound DB和Southbound DB歌馍。下面來分別看看：
存儲virtual networking data model，例如 Switch晕鹊，Router松却，Port等。Northbound DB是由CMS（OpenStack）寫入溅话，也就是說與之前說過的SDN不太一樣晓锻，OVN北向不提供RESTful接口，而是直接由CMS寫入數(shù)據(jù)庫內(nèi)容公荧。舉個例子带射，在OpenStack Neutron的場景下，對應(yīng)的在Neutron中創(chuàng)建一個Network循狰，需要通過networking-ovn在Northbound DB中創(chuàng)建一個LogicalSwitch窟社。
監(jiān)聽Northbound DB的變化，將Northbound DB的內(nèi)容翻譯成LogicalFlow绪钥，存儲在Southbound DB灿里。Ovn-northd是一個集中的進程，在OVN環(huán)境下一般運行在獨立的Database node上程腹，在下面會再提到Database node匣吊。
存儲LogicalFlow，Chassis和其他的一些信息寸潦。Southbound DB存儲ovn-controller的數(shù)據(jù)色鸳。傳統(tǒng)的集中式SDN控制器會根據(jù)已有的配置和數(shù)據(jù)計算OpenFlow規(guī)則，并下發(fā)到各個節(jié)點见转。而OVN將這個過程分解成了兩部分：
先通過ovn-northd將配置和數(shù)據(jù)計算成LogicalFlow命雀。一個LogicalSwitch下的LogicalFlow是一樣的。
將LogicalFlow分發(fā)到各個ovn-controller斩箫，再由ovn-controller將計算出相應(yīng)的OpenFlow規(guī)則下發(fā)吏砂。這樣做的好處是一些全局的運算只需要做一次撵儿。
分布在各個計算節(jié)點（OVN中叫做chassis）的SDN controller。Ovn-controller向上讀取Southbound DB的數(shù)據(jù)狐血，應(yīng)用在本地淀歇；并且讀取本地的VIF和Chassis信息，向上更新匈织。
OVN對于網(wǎng)絡(luò)功能的實現(xiàn)浪默，秉承的是分布式思想。因此網(wǎng)絡(luò)功能都分布在計算節(jié)點报亩，并且沒有一個專門的網(wǎng)絡(luò)節(jié)點浴鸿。但是OVN需要獨立的Database node井氢。這是因為OVN目前采用ovsdb-server作為其DB弦追，一方面，這對于OVN的部署很方便花竞，因為OVN本身就基于OVS劲件，采用ovsdb-server可以避免新增依賴。但是另一方面约急，ovsdb-server之前的主要應(yīng)用場景是給OVS存儲hypervisor本地的虛擬網(wǎng)絡(luò)設(shè)備信息零远，而OVN是一個集群內(nèi)運行的軟件，ovsdb-server明顯不能勝任這種大規(guī)模的數(shù)據(jù)讀寫厌蔽。同時牵辣，前面說過ovn-northd是一個集中式進程，因此用一個獨立的Database node來運行ovn-northd并存儲Northbound DB和Southbound DB奴饮，可以一定程度的緩解瓶頸問題纬向。
OVN與OpenStack集成之后的運行框架如下圖所示 ：
OVN是一個廠商中立的開源項目，背后并沒有一個大的廠商在操縱戴卜，項目的發(fā)起是VMware的工程師逾条，項目的推進有Redhat和IBM等其他公司的參與。相比ODL投剥，ONOS其架構(gòu)也較為簡單师脂。OVN在創(chuàng)立之初就考慮了與OpenStack的集成，因此OVN在OpenStack環(huán)境下工作的較好江锨，一些OpenStack Neutron已知的問題吃警，在OVN中都有較好的解決，例如DVR啄育，Security Group的性能問題酌心。對于已有的OpenStack + OVS環(huán)境，升級到OVN也是一個不錯的選擇灸撰。據(jù)說OVN已經(jīng)在數(shù)百個物理節(jié)點上進行了部署測試谒府，并且用ovn-scale-test項目進行了數(shù)千個節(jié)點的模擬測試拼坎。
其現(xiàn)在的主要問題就在于Database node的瓶頸問題，相信后繼的改進能夠解決這個問題完疫。其他問題在于項目的定位不是一個全功能的SDN泰鸡，因此只有2-3層的virtual networking。不過這個倒是契合OpenStack Neutron的定位壳鹤。其他的advanced 功能可以通過OpenStack Neutron的各個子項目彌補盛龄。
如果說其他的SDN項目是在OpenStack之外生長的，再嫁接到OpenStack芳誓，那Dragonflow就是土生土長的OpenStack SDN項目余舶，Dragonflow是OpenStack的big tent項目，屬于Neutron下面的子項目锹淌，是一個基于Python的完全開源的項目匿值。
Dragonflow是華為公司以色列團隊發(fā)起并推動的項目，最早在OpenStack Kilo版本提出赂摆，是為了解決Neutron DVR的問題挟憔。有關(guān)Neutron DVR的問題，這里就不展開了烟号，以后有機會細說绊谭。在OpenStack Liberty版本開始，可能是受OVN項目的影響汪拥，Dragonflow轉(zhuǎn)向全面的SDN項目达传，與OVN不同的是，Dragonflow目的是提供全功能的SDN解決方案迫筑。一直到剛剛結(jié)束的Ocata版本宪赶，Dragonflow社區(qū)一直處于活躍的開發(fā)和正向的演進中。本人目前也是Dragonflow項目的活躍開發(fā)者之一铣焊。
Dragonflow的定位是大規(guī)模環(huán)境下高性能SDN解決方案逊朽。來看看它的架構(gòu)吧：
其組成部分主要有Neutron plugin，Message Driver曲伊，DB driver叽讳，Dragonflow controller。分別來看看這些組成部分：
由于Dragonflow就是OpenStack Neutron下面的的子項目坟募，因此Dragonflow自己完成了與Neutron的集成岛蚤，Neutron plugin就是Dragonflow中與Neutron的集成部分，這個與其他的SDN一樣懈糯，實現(xiàn)了ML2 mech driver和各種Service plugins涤妒。與OVN類似的是，目前Dragonflow本身不提供獨立的RESTful接口赚哗，Neutron plugin直接寫Dragonflow Database她紫，并觸發(fā)相應(yīng)的Message硅堆。
Dragonflow組件間通訊的方式，其他的SDN一般是定義好了組件間通訊的方式贿讹，要么是RPC渐逃，要么是其他協(xié)議，而Dragonflow將這部分做了一個抽象民褂，可以支持多種Message機制茄菊，目前支持的有ZeroMQ和ReidsMQ。這樣用戶可以根據(jù)不同的使用場景赊堪，選用不同的Message機制面殖。Message Driver用來連接Dragonflow Controller和Neutron server，并在之間傳遞數(shù)據(jù)哭廉。
與Message driver類似脊僚，其他的SDN一般只支持一種DB，但是Dragonflow將這部分也做了抽象群叶，可以支持多種NoSQL數(shù)據(jù)庫吃挑，目前支持的有etcd钝荡，RAMCoud街立，Reids，Cassandra等埠通。這樣實現(xiàn)的目的也是為了用戶可以根據(jù)不同的使用場景赎离，選用不同的DB，以達到最好的性能效果端辱。
這個是Dragonflow的核心部分梁剔。
所有的Dragonflow controller都監(jiān)聽Message driver，當(dāng)Neutron plugin發(fā)布相應(yīng)的Message舞蔽，Dragonflow Controller能收到這個消息荣病，并進行相應(yīng)的計算，更新相應(yīng)的OpenFlow規(guī)則和本地的配置渗柿，同時Dragonflow會通過Message driver上報本地的信息个盆，例如端口上線事件。
剛剛結(jié)束的Dragonflow Northbound DB重構(gòu)朵栖，將Dragonflow Controller中的數(shù)據(jù)和消息機制颊亮，按照Model來管理，這有點類似于ODL中的MD-SAL陨溅。
為了提高網(wǎng)絡(luò)計算的速度终惑，Dragonflow本地有一個數(shù)據(jù)的緩存，這樣在進行網(wǎng)絡(luò)計算的時候门扇，直接可以從內(nèi)存中讀取數(shù)據(jù)進行運算雹有，而不需要再讀取遠端DB數(shù)據(jù)偿渡。這樣能減少網(wǎng)絡(luò)計算的時間，降低網(wǎng)絡(luò)延時霸奕。
為了適應(yīng)大規(guī)模部署卸察，Dragonflow中還有一個selective topology的概念，這個有點類似我在上一篇中介紹的OpenContrail里的的vRouter中的routing instance概念铅祸。
只有當(dāng)前計算節(jié)點關(guān)注的Topology才會在當(dāng)前Dragonflow Controller中存在緩存坑质，并且相應(yīng)消息才會被當(dāng)前Dragonflow Controller接收。當(dāng)前計算節(jié)點關(guān)注的Topology是指當(dāng)前計算節(jié)點上相應(yīng)租戶（tenant）的虛擬機临梗。這樣的設(shè)計涡扼，使得在大規(guī)模部署環(huán)境下，每個Dragonflow Controller的只需要監(jiān)聽有限的信息盟庞，緩存有限的數(shù)據(jù)吃沪，不會因為規(guī)模的變大而導(dǎo)致單個Dragonflow Controller負荷變大。
這里是具體網(wǎng)絡(luò)功能的實現(xiàn)什猖，因為Dragonflow Controller是運行在各個計算節(jié)點的票彪，因此，Dragonflow對于網(wǎng)絡(luò)的運算不狮，也是放到各個計算節(jié)點降铸，這是一個真正的分布式可插拔的SDN方案。之前介紹的SDN要么是集中式的SDN摇零，要么是部分運算在集中式節(jié)點推掸，部分計算在分布式節(jié)點。
在NAL驻仅，每個網(wǎng)絡(luò)功能都是一個獨立的application谅畅。為了實現(xiàn)相應(yīng)的網(wǎng)絡(luò)功能，每個計算節(jié)點上都必須運行一套applications噪服。目前實現(xiàn)的網(wǎng)絡(luò)功能有DHCP毡泻，L3 routing，L2粘优，Security Group仇味，等等。
與ovn-controller類似的是敬飒，Dragonflow Controller底層連接的也是ovs-vswitchd和ovsdb-server邪铲。
與OVN類似的是，Dragonflow也有一個專門的Database node无拗，但是與OVN不一樣的是Dragonflow的Database Node可以是任何DB backend带到，例如實際環(huán)境下可以部署一個RedisDB的HA集群，這在大規(guī)模環(huán)境下優(yōu)勢要明顯強于OVN的ovsdb-server。另一方面不一樣的是揽惹，Dragonflow的Database node不關(guān)心任何網(wǎng)絡(luò)運算被饿，所有的網(wǎng)絡(luò)運算都交由分布在計算節(jié)點的Dragonflow controller完成。
Dragonflow是一個真正的分布式SDN解決方案搪搏，其底層依賴OVS狭握。因此對于現(xiàn)有的Neutron + OVS架構(gòu)，遷移到Dragonflow也較為自然疯溺，實際上论颅，Dragonflow目前也有相應(yīng)的努力，提供Neutron + OVS agent遷移到Dragonflow的方案（開發(fā)中）囱嫩。
從社區(qū)開發(fā)來看恃疯，華為是目前的主要貢獻者，不過從其目前的開源策略看墨闲，Dragonflow并沒有想做成一個廠商控制的開源項目今妄。
另一方面，Dragonflow現(xiàn)在還處于一個相對早期的階段鸳碧。并且分布式的SDN方案盾鳞，雖然將網(wǎng)絡(luò)運算分布到了各個計算節(jié)點，能夠從理論上去除瓶頸瞻离，擴大集群規(guī)模腾仅，但是也增加了開發(fā)的難度和浪費了集群內(nèi)整體的計算資源，因為同一個網(wǎng)絡(luò)運算琐脏，需要在多個計算節(jié)點分別完成攒砖，從整體上看是有一定的浪費。
不過鑒于目前計算資源成本較低日裙，這些副作用利大于弊，總體來說惰蜜，Dragonflow還是一個很有前途的SDN項目昂拂。
本文轉(zhuǎn)載自：https://zhuanlan.zhihu.com/p/25996102
