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