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