由工業和資訊化部指導，中國資訊通訊研究院主辦，業界知名組織雲端計算開源產業聯盟（OSCAR）承辦的2017全球雲端計算開源大會於4月19日-20日在北京國家會議中心順利召開。本文為本屆大會嘉賓分享的大會演講速記內容，敬請瀏覽。

嘉賓介紹:肖巨集輝

公司職務：華為軟體工程師

大會演講速記

大家好，很高興能跟大家分享這個主題，我先自我介紹一下，我叫肖巨集輝，來自華為。

OpenStack是非常出名的開源雲平臺，在雲端計算裡面主要資源是計算、儲存和網路，今天我們這個主題是講SDN，也就是OpenStack網路。

OpenStack不用介紹了，我們先來看看SDN。SDN總結起來可以說有兩個特點，一個是網路資源可程式設計規制，具體來說是把網路裝置做成軟體可控，因為在傳統機房裡，如果我們要改動一個網路裝置，需要到機房裡面插拔一個裝置，但是通過SDN我們可以通過軟體控制實現這個功能。第二是控制層面和轉發層面的分離，通過這樣的分離，能夠提升網路整體的管控能力。

說到SDN，不得不說OpenFlow，它是OpenStack裡面最具代表性的協議，是斯坦福大學提出的協議，有些時候可能會說OpenFlow和SDN是等同的，我個人認為基於OpenFlow的SDN是狹義的SDN。廣義的SDN包括更多的協議，例如OVSDB，NETCONF等。

我們首先看一下OpenStack  Neutron，Neutron大體上可以分為兩部分：Neutron server 和Neutron agent。Neutron server包含了API和DB，也就是說，整個OpenStack環境裡所有網路資訊，都是存在Neutron server中，包括網路可達資訊還有統計資料的運算都是在Neutron server進行的。Neutron agents可以看作是網路實現。需要說一下的是，Neutron除了自身提供一套網路實現之外，還考慮到第三方相容。

Neutron專案是OpenStack社群最活躍的專案之一，它集中了大量工程師參與開發，在OpenStack場景下它的穩定性和一定規模下的可靠性也是別的SDN所不能比擬的。

另一方面，再看看Neutron的定位，Neutron致力於提供2—3層網路服務，4—7層服務由Neutron子專案提供。

開源社群開發有一個大的特點，開發有一定的碎片性，Neutron的這樣的定位首先能夠提高核心程式碼的質量，降低核心程式碼的管控難度，但是同時增加碎片的程度，很多分離出去的子專案大家如果參與的話，會發現它的活躍度會大大降低。

總體來說，在OpenStack中，不像Ceph對於儲存來說有壓倒一切的網路實現方案，包括Neutron的實現方案也不能勝過其他SDN方案。所以在目前Neutron社群裡面可以發現主要活躍的工程師都是來自於HP和Mirrantis，不是傳統的網路廠商，HP因為最近的策略，工程師都分流到了別的公司。而傳統網路廠商，包括做SDN的廠商，他們熱衷於是推自己的SDN，這樣反過來又分散Neutron開發的力量。

接下來說一下OpenDayLight，這是基於Java + OSGI的平臺，總的來說OpenDayLight專案功能是完善的，而且現在有基於ODL的商業版在售，也有資料中心基於ODL提供服務。不過思科對ODL貢獻較多，一定程度掌握了ODL專案。另外OpenDayLight專案比較龐大，子專案也很多，如果說一個公司想要採用這個專案的話，建議由一個專業團隊維護這個專案。

第二是ONOS，這是2014年由ON.Lab發起的，這個組織去年跟ONF合併了，所以以後看ONOS會看到是ONF支援的專案。ONOS定位是SDN system。但是ONOS專案在OpenStack裡應用不是特別好，它與ODL有很多相似的地方，ONOS更偏向於資料中心的底層SDN控制器。

第三是OpenContrail，它的前身是2012年成立的創業公司Contrail，同年就被Juniper收購，並作為Juniper的SDN方案出售。OpenContrail比較有意思的是開源版本和商業版本同時存在，並且程式碼是一致的，區別是商業版本支援更好一些。

OpenContrail定義是支援Cloud  networking和NFV場景，經過這幾年發展已經比較成熟了，而且本身架構是參考MPLS VPN，架構上比較可靠。

在Mirrantis新發布的OpenStack版本里，OpenContrail是作為預設的構成在裡面，使用者可以選擇。但是對於開源使用者來說，因為存在商用版本的客觀原因，落地有一定額困難。

再看Midonet，它是來自於日本創業公司Midokura。它跟OpenContrail類似，也是開源版本和商業版本存在，但是區別是Midonet開源版本和商業版本程式碼不一樣，它的控制和運維方面的工具，商業版更先進一些。

Midonet通過entworking+Midonet與OpenStack整合，並且Midonet定位不像ODL，作為大而全的SDN，它主要的定位是雲端計算網路，整個專案是比較可控的，適合大規模部署。而且在與OpenContrail競爭Mirrantis第三方SDN時失敗了，這對Mirrantis有一定的衝擊。另外，同樣的問題也存在，因為背後有商業版，開源版落地存在困難。總之，背後有開源商業版的話，本身不是完全開源的，因為這種開源是為了更好的售賣商業。

下一個是OVN，OVN是OVS社群2015年1月發起的OVS子專案。OVS社群想在網路裝置上多做一層虛擬網路管控，所以提出了OVN專案，他們想做虛擬網路可能，但是又不想做太靠上，所以OVN定義是輕量級的SDN。

現在OVN是做networking-ovn向OpenStack整合。OVN主要定義是大規模部署和neutron本身有的一些問題，它有一個專門的專案做上千級別節點的模擬測試，但是現在有一個問題，就是資料庫的高可用問題，因為OVN用的是OVS的DB，在實際產品當中不支援資料庫高可用的話，用起來還是比較讓人擔心的。

最後說一下Dragonflow，這是在2015年由華為以色列團隊提出的專案。如果其他SDN都是在各自社群發展再嫁接到OpenStack，那Dragonflow就是一個源於OpenStack的SDN專案。它的定位是提供全功能的SDN解決方案，專案較為可控，適合大規模部署。SDN現在定位就是大規模部署的輕量級SDN，一方面雖然它是全功能SDN，但是現在整個架構還比較輕的，程式碼在幾萬行這個量級。另一方面，它是一個真正的分散式SDN，Dragonflow在所有計算節點上都跑SDN 控制器，這樣把網路運算都分佈到計算節點，去除了網路運算的瓶頸。

然後說一下Dragonflow的開源政策，Dragonflow目前主要是華為在推，到目前剛剛結束的一個版本，活躍度還是非常高的，開源政策也是比較開放的。Dragonflow專案設計考慮到應用場景多樣性，設計了可插拔的模組，前面說的SDN，一般只支援一種資料庫，但是Dragonflow支援五到六種資料庫。這樣使用者可以根據自己實際的經驗和環境來選擇SDN資料庫。比如之前有ETCD的經驗，現在用Dragonflow的話，ETCD經驗可以繼續維持下去。

再簡單看一下SDN和OpenStack的關係，首先SDN是獨立的領域，在OpenStack之外SDN是獨立發展的。另一方面，OpenStack的發展與SDN發展又是相互促進的關係，本身這兩個領域發展時間上看是重合的，另外SDN主要應用場景是雲端計算和網路，OpenStack發展推動雲端計算的發展，進而能夠帶動SDN的發展，另一方面，SDN發展又能夠使得OpenStack叢集規模變得更大，進而能夠推動OpenStack發展。

前面介紹這麼多SDN，他們有一個共同特點，他們都可以通過OpenStack Neutron來提供北向介面，或者他們都做了與OpenStack Neutron的對接，所以光看SDN和OpenStack，OpenStack Neutron有趨勢成為各種SDN統一的北向介面。

在傳統SDN架構裡，只有控制層和資料層，最近提出的SDN架構還包括應用層，而OpenStack就存在於應用層。SDN控制器是整個SDN的核心。SDN的最底層是資料層，資料層實際上就是一個個網路裝置，網路裝置可以包括物理裝置和虛擬裝置，比較有意思的是，雖然說SDN是用軟體定義網路，但是目前SDN市場裡，份額最大的還是支援SDN的物理裝置，最賺錢的還是這塊。虛擬裝置是一個最有發展前景的，畢竟成本上能夠降低不少。

時間原因我就簡單介紹這些，本次介紹有更詳細的版本，我在知乎上的專欄https://zhuanlan.zhihu.com/software-defined-network發表過，大家有興趣的話可以看一下。謝謝大家！

文章來自微信公眾號：雲端計算開源產業聯盟