OpenStack 網(wǎng)絡項目（Neutron）的歷史、現(xiàn)狀與未來
歷史
OpenStack 作為最熱門的云計算開源項目，自 2010 年 10 月發(fā)布第一個版本 Austin 以來，到 2014 年 10 月 發(fā)布 Juno 版本，已經經歷了 10 個主要版本?；痉€(wěn)定為每年 4 月和 10 月各發(fā)布一次大的版本更新。
網(wǎng)絡功能實現(xiàn)是自第二個版本，即 Bexar 版本引入，最初作為 Nova 項目的一個功能 Nova-Network，僅支持所有用戶共享一個底層網(wǎng)絡（即所謂的 Flat 網(wǎng)絡），后面自 2012 年 9 月發(fā)布的 Folsom 版本開始，將網(wǎng)絡功能剝離出來，作為一個新的 Quantum 項目。2013 年 10 月發(fā)布的 Havana 版本中，項目改名為 Neutron。最新的 2014 年 10 月發(fā)布的 Juno 版本中，更引入了分布式路由（DVR）機制，并停止對于 Nova-Network 的支持。
各個關鍵版本的更新情況如下：
- Bexar 版本：
引入 Nova-Network
- Cactus 版本：
IPv6 支持
- Diablo 版本：
FlatDHCP 網(wǎng)絡下的 HA
- Essex 版本：
網(wǎng)絡功能數(shù)據(jù)模型開始從 Nova 中剝離，為獨立項目做準備
- Folsom 版本：
正式從 Nova 中剝離，成為新的獨立項目 Quantum
多租戶隔離的支持
插件式結構支持多種網(wǎng)絡后端技術，包括 Open vSwitch、Cisco、Linux Bridge、Nicira NVP、Ryu、NEC
支持 IP 地址的 Overlapping
支持 provider networks
支持基本的 L3 轉發(fā)、SNAT、Floating IP
- Grizzly 版本：
多網(wǎng)絡節(jié)點支持，提高可靠性
安全組
支持 LBaaS
- Havana 版本：
項目名稱從 Quantum 改名為 Neutron
多種物理網(wǎng)絡（Linux Bridge，Hyper-V，OVS）類型同時支持
引入 Fwaas、VPNaas
引入 ML2 支持多種類型二層網(wǎng)絡實現(xiàn)
- IceHouse 版本：
一些新的插件
新的 LBaaS 驅動
- Juno 版本：
初步支持分布式路由（DVR）機制
完整的 IPv6 支持
L3 agent 的 HA 支持
一些新的廠商的功能插件
從上面的過程可以可以看出，網(wǎng)絡功能從 Folsom 版本開始引進，經歷了 Folsom、Grizzly、Havana、IceHouse 四個版本才形成了比較穩(wěn)定的集中式網(wǎng)絡模型。自最新的 Juno 版本開始，才開始采用分布式路由模型。
現(xiàn)狀
作為云計算平臺的基礎之一，網(wǎng)絡服務的實現(xiàn)無疑是最能體現(xiàn)技術實力之處。無論是功能全面與否、性能高低、穩(wěn)定性，每一項想做到滿足生產環(huán)境的眾多要求，都不是那么容易的。這也是現(xiàn)在很多圍繞 OpenStack 的創(chuàng)業(yè)公司立足之根本。
OpenStack 在宣傳上，一直明確表明自身的網(wǎng)絡是完全按照軟件定義網(wǎng)絡（SDN）的理念來設計的。實際上，即使是從網(wǎng)絡已經正式成為獨立項目的 Folsom 版本開始看，這種說法也是不準確的。這個不明確的設計理念也是目前 OpenStack 在網(wǎng)絡項目上收到大量抱怨的重要原因之一。
我們知道，SDN 有幾個特點，最基礎的一點是以松耦合的方式來處理好控制平面與數(shù)據(jù)平面的關系。
OpenStack 在設計上的確做到了控制平面與數(shù)據(jù)平面的分離，所有的數(shù)據(jù)都存放在數(shù)據(jù)庫，所有的 agent 監(jiān)聽來自 Neutron-Server 的消息，根據(jù)這些消息來執(zhí)行本地的操作。從這個簡單的模型上看，Neutron 確實采用了 SDN 的模型。
但是將控制平面與數(shù)據(jù)平面分離，這僅僅是漫漫長途的第一步。后面的如何設計數(shù)據(jù)平面，以及如何設計和實現(xiàn)控制平面，才是最為核心的地方。
目前，OpenStack 在這兩點上是怎么實現(xiàn)的呢？
2009 年誕生的 OpenvSwitch 項目，提供了足夠支持生產環(huán)境應用的虛擬交換機實現(xiàn)，可以無縫替換掉 Linux 自身的 bridge，并且還支持一系列額外的功能?？雌饋?，這是個不錯的項目。于是，在最初幾個版本中，網(wǎng)絡就同時支持了 Linux Bridge 和 OpenvSwitch。但是很可惜的是，從一開始，大家在使用 OpenvSwitch 的時候，僅僅是當作一個 Linux Bridge 替代品，在設計新的功能的時候，也局限于 Linux Bridge 所支持的功能。這導致理論上可以充當任意轉發(fā)組件的 OpenvSwitch，在今天的 Neutron 項目中，大部分時候只是作為一個二層交換機在使用。
那么， 更為重要的控制平面呢？很遺憾，在這點 OpenStack 上的表現(xiàn)差強人意。雖不至于說存在技術漏洞，但至少控制平面缺乏統(tǒng)一的規(guī)劃，以現(xiàn)代眾多控制平面的實現(xiàn)角度去看，只能說是一堆功能放在了一起。為了解決一個部分功能，先用已有技術解決掉，而不管其它功能的實現(xiàn)。這也導致經常出現(xiàn)不同功能模塊的沖突。分布式路由機制在 SDN 中是個很自然的事情，但現(xiàn)有的實現(xiàn)先后用了固定的地址映射、ARP 代理、多級的轉發(fā)表、隧道、L2 Population……并不是說不能用這些技術，但是實現(xiàn)的復雜與緊耦合將給未來的擴展帶來更多的困難。并且同時啟用路由跟高可靠性、多類型服務鏈等等功能，現(xiàn)有的設計很難在不提高復雜度的前提下實現(xiàn)。
可能做網(wǎng)絡研發(fā)出身的人比較難理解為何要這樣設計。實際上，換個角度，從 Linux 系統(tǒng)自身管理的來看，這樣的設計是有其合理之處的。在沒有 SDN 的年代，用 Linux 自身做路由器或防火墻是很常見的事情，通過 IPtables、Linux Bridge 進行各種配置，總能滿足局域網(wǎng)內的各種需求。然而，到了云時代，一臺物理機動不動就上數(shù)十臺虛擬機，甚至現(xiàn)在幾百成千個的容器，同時是多租戶的、有計費需求的、對安全可靠性需求很高的……這里面很多的場景，是之前簡單應用 Linux 做服務器或網(wǎng)關時候所難以想象的。即使通過各種技術手段勉強解決了基本的需求，也只能造成今天這樣復雜的局面。也可以想象，為何將網(wǎng)絡接口接到交換機上這樣的操作，在 OpenStack 里面是由 Nova 計算服務來負責的。
在這里也稍微感嘆下，如果 OpenStack 當年沒有 NASA 項目的代碼基礎、如果沒有選擇“生命苦短，我選 Python” 的 Python 語言開發(fā)，可能到今天的情況會更加不能讓人滿意。
當然，使用 OpenStack 除了上面的模式，還有另外一種用法：僅把 Neutron 作為一個框架，讓后端的各種插件自己來實現(xiàn)各種網(wǎng)絡的服務。這種情況下無疑對于現(xiàn)有代碼的依賴最小，也無疑最為廣大有自己成熟網(wǎng)絡解決方案的廠商所推崇。但是這樣的模式，肯定也不是社區(qū)能接受的情況。畢竟，僅作為一個殼子轉發(fā)下各種調用，這失去了作為一個成熟云平臺開源項目的意義。
未來
雖然指出了網(wǎng)絡項目在設計上的諸多問題，筆者對于 OpenStack 仍然是推崇的。并非出于盲目喜愛開源項目的原因，更多的，自 Linux 項目后，這些年很難見到這么多業(yè)界巨頭和開源屆的緊密合作，一起進行一項解決實際需求的項目。
實際上，思考 Linux 項目之所以能成功的原因，很重要的一點，是 Linus 本人。并非只是因為他在操作系統(tǒng)內核方面的技術境界，不可缺少的一點是 Linus 本人是比較“偏執(zhí)”的，他認定的事情就輕易不會改變。同時，在很長一段時間里 Linux 系統(tǒng)內核的維護只是由 Linus 說了算。這或許能給今天的 OpenStack 社區(qū)一些啟發(fā)。OpenStack 已經成功了，再宣傳贊助基金之巨、參與人數(shù)之多其實意義沒那么大了。一個真正透徹理解云計算需求和技術的小團隊，往往勝過大量自覺或不自覺站在各種立場上的參與者。
從目前的情況推測，在很長一段時間內，網(wǎng)絡項目還將沿著現(xiàn)在的路子走下去，一方面是在分布式模型下的新的網(wǎng)絡功能實現(xiàn)，以及解決與已有功能的沖突；另一方面仍然是各個廠商以插件的形式支持自己的網(wǎng)絡方案。這兩種方式發(fā)生沖突是遲早的事情，只是希望那個時候 OpenStack 中的網(wǎng)絡已經選擇了更為高效和可擴展的框架，可以真正地實現(xiàn)“任意替換”的軟件定義網(wǎng)絡。
附：OpenStack 發(fā)布歷史（摘自官方 wiki）
- Series Status Releases Date
- KiloUnder development Due Apr 30, 2015
- Juno Current stable release, security-supported 2014.2 Oct 16, 2014
- Icehouse Security-supported 2014.1 Apr 17, 2014
- Havana EOL 2013.2 Oct 17, 2013
- Grizzly EOL 2013.1 Apr 4, 2013
- Folsom EOL 2012.2 Sep 27, 2012
- Essex EOL 2012.1 Apr 5, 2012
- Diablo EOL 2011.3 Sep 22, 2011
- Cactus Deprecated 2011.2 Apr 15, 2011
- Bexar Deprecated 2011.1 Feb 3, 2011
- Austin Deprecated 2010.1 Oct 21, 2010
