OpenStack Kilo 版本，OpenStack 這個開源項目的第11個版本，已經(jīng)于2015年4月正式發(fā)布了?，F(xiàn)在是個合適的時間來看看這個版本中Neutron到底發(fā)生了哪些變化了，以及引入了哪些新的關(guān)鍵功能。

1. 擴展 Neutron 開發(fā)社區(qū) (Scaling the Neutron development community)

為了更好地擴展 Neutron 開發(fā)社區(qū)的規(guī)模，我們在Kilo開發(fā)周期中主要做了兩項工作：解耦核心插件以及分離高級服務(wù)。這些變化不會直接影響 OpenStack 用戶，但是我們期望這些工作會帶來代碼量的減少，以及新功能開發(fā)速度的提升，從而最終帶來創(chuàng)新的加速。下面我們來一項一項的來看。

1.1 解耦Neutorn核心插件 (Neutron core plugin decomposition)

從設(shè)計上看，Neutron 采用可插拔式(pluggable)架構(gòu)，這種架構(gòu)允許實現(xiàn) Neutron API 的可定制后端。Neutron 核心插件(core plugin)是整個Neutron項目開發(fā)的核心部分，它就像在邏輯API層和實際實現(xiàn)層之間的一個粘合層(glue)。隨著Neutron項目的演進，越愛越多的插件被引入了，它們來自各個不同的開源項目和社區(qū)(比如 Open vSwitch 和 OpenDaylight)，以及廣大供應(yīng)商(vendor，比如 Cisco, Nuage, Midokura 等等)。在Kilo 開發(fā)周期的一開始，Neutron 有十幾個插件和驅(qū)動，包括核心插件(core plugins)、ML2 機制驅(qū)動(mechanism drivers)、L3 服務(wù)插件，以及 L4-L7 插件比如 FWaaS、LBaaS 和 VPNaaS 等，其中大部分插件的代碼都直接放在Neutron項目代碼庫中。 因此，需要檢視的Neutron代碼的數(shù)量，包括所有這些插件和驅(qū)動的代碼，已經(jīng)增長到了導(dǎo)致項目開發(fā)規(guī)模無法再增長的程度。讓不熟悉這些驅(qū)動或者插件的代碼檢視者，以及沒有合適的硬件或者軟件環(huán)境來驗證這些插件和驅(qū)動代碼的代碼檢視者來檢視這些插件和驅(qū)動的代碼是不現(xiàn)實的。同時，當(dāng)供應(yīng)商提交的代碼不能及時地被合并時，這些供應(yīng)商難免會失望。

要改善這種境況要做的第一件事情是，將Neutron 核心插件和ML2驅(qū)動的代碼從 Neutron 代碼庫中解耦。具體的做法是，只在Neutorn代碼樹中給上文提到的每個插件和驅(qū)動保留一個薄薄的代理( shim/proxy)層，再把它們所有的后端實現(xiàn)邏輯移到不同的代碼庫中，新的代碼庫的一個比較自然的選擇是 StackForge。這么做的好處是顯而易見的：Neutron 代碼檢視人員可以把主要精力放在檢視Neutron 核心代碼上，同時廠商和插件的維護者可以按照他們自己的迭代周期做迭代。社區(qū)已經(jīng)鼓勵各代碼提供者去立即著手這項解耦工作，但是也不強制要求所有的插件在 Kilo版本發(fā)布前完成所有工作，這主要是為了給各廠商留下足夠的時間。

關(guān)于該流程的更多信息，請閱讀該文檔，它是專門用來跟蹤所有插件的進度的。

1.2 分離高級服務(wù) (Advanced services split)

上述的第一件事情只是著眼于Neutron 核心插件和 ML2 驅(qū)動，一個并行的工作是對L4-L7 高級服務(wù)(FWaaS, LBaaS, and VPNaaS)做同樣的事情。和核心插件類似，這些高級服務(wù)之前也是將代碼存放在Neutron主代碼庫中，一個相似的后果是導(dǎo)致Neutron 核心代碼檢視人員失去專注性。從Kilo開始，這些服務(wù)的代碼將會被分離到它們各自的代碼樹中。因此，現(xiàn)在Neutron 有四個不同的代碼庫：一個用于基礎(chǔ)的L2/L3 網(wǎng)絡(luò)、分別有一個用于FWaaS, LBaaS, 和 VPNaaS。因為目前高級服務(wù)插件還比較少，目前各廠商和插件的代碼還會被保留在各個服務(wù)的代碼庫中。

值得一提的是，這么做不會影響到OpenStack 用戶。這些服務(wù)即使現(xiàn)在被分離出去了，它們的 API 或者CLI 不會有任何變化，它們還會和之前一樣使用相同的 Neutron 客戶端。同時，我們確實能預(yù)計到，由于每個高級服務(wù)都有從Neutron分離出去成為獨立組件的潛力，目前所做的分離工作確實為它們將來更深層次的變化打下了基礎(chǔ)，將來它們可能會提供它們自己的 REST 端點、配置文件和CLI/API 客戶端。這也使得它們的開發(fā)團隊能專注于一個或者幾個高級服務(wù)從而有可能實現(xiàn)更大的變化。

2. ML2/Open vSwitch 端口安全 (ML2/Open vSwitch port-security)

安全組(Security-groups)是Neutron 最常用的功能之一，它允許租戶去指定允許經(jīng)過一個Neutron 端口的網(wǎng)絡(luò)流量的類型和方向(進/出)，從而可以高效地為虛機創(chuàng)建防火墻。

從安全考慮，Neutron 安全組的實現(xiàn)，總是會自動創(chuàng)建阻止IP 地址欺騙攻擊的規(guī)則，來避免虛機收到或者發(fā)出與虛機的Neutron 端口的 MAC 或者 IP 地址不符的網(wǎng)絡(luò)包。當(dāng)大多數(shù)用戶認為安全組和防IP欺騙規(guī)則非常有用而且必要時，一些人要求增加開關(guān)選項來使得他們可以在特定端口上不創(chuàng)建這種規(guī)則。有這種需求的主要用例是當(dāng)在虛機上運行網(wǎng)絡(luò)服務(wù)的時候，一個常用的例子是 NFV?？紤]一個在 OpenStack 虛機中部署路由應(yīng)用的例子：它需要能夠接收不是發(fā)給它自己的包，還需要能夠發(fā)出不是從它任何端口產(chǎn)生的包。當(dāng)使用了安全組時，這個虛機是沒法做這些事情的。

我們來看看這個例子的拓撲圖：

Host 1 是一個虛機，它的IPv4 地址是 192.168.0.1，現(xiàn)在它需要訪問 Host 2，它的IP地址是 172.16.0.1。這兩個主機通過兩個運行路由應(yīng)用的虛機(R1 和 R2)連接在一起，這兩個虛機分別被配置為主機1 和 2的缺省路由。上圖顯示了端口的默認IP地址。我們來看看Host 1 是如何向 Host 2 發(fā)包的：

Host 1 產(chǎn)生一個 IPv4 網(wǎng)絡(luò)包，源IP是 192.168.0.1，目的 IP 是 172.16.0.1。因為兩個虛機在不同網(wǎng)段上，R1 使用它自己的MAC地址來響應(yīng)Host 1 的 ARP 請求，因此，Host 1 產(chǎn)生的網(wǎng)絡(luò)幀的目的 MAC 地址為 3B-2D-B9-9B-34-40 。

R1 收到該包。注意這個包的目的IP 是 172.16.0.1，不是R1自己。在 R1 的端口上應(yīng)用了Neutron安全組以后，防IP欺騙規(guī)則就默認被應(yīng)用了，這個包就會被丟棄，因此 R1 無法完成進一步的路由。

Kilo 版本之前，你對整個云要么禁止安全組要么使用安全組。從 Kilo 版本開始，可以使用新的屬性 port-security-enabled 來啟用或者禁用某個端口上的安全組了。這個新的屬性目前被 Open vSwitch agent 和 IptablesFirewallDriver 支持。

回到之前的拓撲，現(xiàn)在可以在 R1 和 R2 的端口上禁用安全組了，同時在主機虛機的端口上使用安全組。這么做以后，就可以正常地做路由了。

更多的信息，以及配置示例，可以在 Red Hat 公司 Terry Wilson 的 blog 上找到。

3. IPv6 增強 (IPv6 enhancements)

隨著Juno版本中引入的一些新的功能，包括允許使用 SLAAC 和 DHCPv6 來向租戶網(wǎng)絡(luò)分配IP地址，以及支持由外部路由器產(chǎn)生的廣告給物理網(wǎng)絡(luò)的 RAs消息等，IPv6 已經(jīng)成為 Neutron 一個新的焦點領(lǐng)域 。Kilo 版本中 IPv6 功能在進一步地成熟，因此也帶來了一些其它方面的增強，包括：

允許給一個網(wǎng)絡(luò)分配多個IPv6 前綴

IPv6 允許給一個網(wǎng)卡分配多個IP前綴。這其實是個常見的配置，通 常地，所有的網(wǎng)卡會被分配一個本地連接地址(link-local address， LLA)用于處理本地連接的網(wǎng)絡(luò)流量，其中一個或者多個網(wǎng)卡會被分配全局單播地址( global unicast addresses ，GUA)來處理端到端的網(wǎng)絡(luò)連接流量。從 Kilo 版本開始，用戶可以分配多個IPv6 子網(wǎng)給一個網(wǎng)絡(luò)。當(dāng)子網(wǎng)的類型是 SLAAC 或者 無狀態(tài)的DHCPv6 的時候，一個Neutron 端口會被從每個子網(wǎng)中分配一個IPv6 地址。

更好的IPv6 路由支持

Kilo 版本中，OpenStack IPv6 沒有網(wǎng)絡(luò)地址轉(zhuǎn)換(NAT - network address translation )或者 浮動IP。這是假設(shè)虛機會被分配全局可路由地址(globally routed addresses )因此能夠和純L3路由通信的。Neutron中的 neutron-l3-agent 組件通過創(chuàng)建和維護虛機路由器來負責(zé)Neutorn 內(nèi)的路由。要在虛機路由器中支持IPv6， 需要以下的兩個功能：

子網(wǎng)之間的路由：這是指網(wǎng)絡(luò)包在同一租戶的不同IPv6 子網(wǎng)之間的路由。因為這些網(wǎng)絡(luò)流量是在OpenStack云內(nèi)部被路由的，它們不會離開OpenStack云去任何外部系統(tǒng)，這種路由往往被稱為“東西” 路由。這個功能在Juno版本中就支持了，而在Kilo 中沒有大的變化。

外部路由：這是指在IPv6租戶子網(wǎng)和IPv6 外部子網(wǎng)之間的路由。因為這些流量需要離開Neutron網(wǎng)絡(luò)去外部網(wǎng)絡(luò)，它們往往被稱為“南北”流量。因為沒有 IPv6 NAT 支持，虛機路由器(virtual router)只需要簡單地在內(nèi)部子網(wǎng)和外部子網(wǎng)之間做路由。這個功能在Juno版本就支持了，但是在Kilo 中，針對運維人員(operator)創(chuàng)建外部網(wǎng)絡(luò)的方式做了主要的優(yōu)化，現(xiàn)在他們不需要給外部網(wǎng)絡(luò)創(chuàng)建Neutron子網(wǎng)了。Meutron虛擬路由器可以自動地通過SLAAC 學(xué)習(xí)得到默認網(wǎng)關(guān)的信息(如果RAs 在上行路由器上被啟用了的話)，或者由運維人員使用 l3-agent 配置文件中新的 ipv6-gateway 配置項來手動地指定默認網(wǎng)關(guān)。

增加若干DHCP選項

使用 Neutron，用戶可以指定子網(wǎng)額外的 DHCP 選項。這主要用于給 Neutron 端口分配諸于 DNS 或者 MTU 這樣的附加信息。一開始，這些配置只能用在端口的 DHCPv4 或者 DHCPv6 地址上，它的問題是當(dāng)給一個端口同時分配了IPv4 和 IPv6 兩個地址時無法使用。

從 Kilo 版本開始，可以為 DHCPv4 和 DHCPv6 設(shè)置額外的DHCP 選項。Neutron 創(chuàng)建和更新端口(port)的 API 增加了一個新的參數(shù) “ip_version”，它會指定某個給定 DHCP 選項的IP版本(4 或者 6)。

4. LBaaS v2 API

LBaaS 是 Neutron 高級服務(wù)之一。它允許租戶按需創(chuàng)建負載均衡器，后端使用一個基于不同負載均衡技術(shù)的開源或者閉源的服務(wù)插件。在Red Hat Enterprise Linux OpenStack Platform上的開源方案是基于HAProxy的。

LBaaS v1.0 API 包括基本的負載均衡能力，實現(xiàn)了一個簡單而直接的工作流來設(shè)置負載均衡服務(wù)：

創(chuàng)建一個池

為池創(chuàng)建一個或者多個成員

創(chuàng)建健康狀態(tài)監(jiān)控器

創(chuàng)建一個和池關(guān)聯(lián)的虛機IP

這個實現(xiàn)在做初始實現(xiàn)和部署LBaaS時會有幫助，但是，它不足以提供企業(yè)級的高級負載均衡器。LBaaS 2.0 能夠提供更加強大的負載均衡方案，包括支持SSL/TLS 端點。要實現(xiàn)這個目標(biāo)，需要重新設(shè)計LBaaS的架構(gòu)，具體你可以參考 HAProxy reference plugin.

5. 增加 DVR 對 VLAN 模式的支持 (Distributed Virtual Routing (DVR) VLAN support)

DVR，在 Juno 版本中被首次引入，允許跨計算節(jié)點部署 Neutron 虛擬路由器，這樣每個計算節(jié)點就能夠為它上面運行的虛機提供路由服務(wù)。這會提高虛擬路由器的性能和可擴展性，被視為實現(xiàn)更高效的L3網(wǎng)絡(luò)的一個重要里程碑。

提醒一下，默認的OpenStack Neutron架構(gòu)中，使用了一個專用網(wǎng)絡(luò)節(jié)點集群來處理云中的大部分網(wǎng)絡(luò)服務(wù)，包括 DHCP，L3 路由和 NAT。這意味著從計算節(jié)點上發(fā)出的網(wǎng)絡(luò)流量需要經(jīng)過網(wǎng)絡(luò)節(jié)點才能被正確地路由。通過使用 DVR，計算節(jié)點就能夠處理它本地虛機在網(wǎng)段之間(東西)的路由以及浮動IP 的NAT。DVR 任然依賴專用網(wǎng)絡(luò)節(jié)點來提供默認的 SNAT 服務(wù)，來允許虛機訪問外部網(wǎng)絡(luò)。

Kilo 之前，DVR 只支持使用隧道網(wǎng)絡(luò)包括 GRE 和 VXLAN 等來做租戶網(wǎng)絡(luò)隔離。這樣的話，它就阻礙了用戶就使用 VLAN 租戶網(wǎng)絡(luò)了。在Kilo 中，DVR 增加了VLAN 的支持，因此，現(xiàn)在 DVR 即可以支持隧道網(wǎng)絡(luò)也可以支持VLAN 了。

更多的關(guān)于DVR的信息，強烈建議你去讀 Red Hat 公司的 Assaf Muller 的三篇非常棒的blog：overview and east/west routing, SNAT, and Floating IPs：。

6. 查看HA虛擬路由器的狀態(tài) (View the state of Highly Available routers)

Juno 版本中引入的一個重要功能是L3 HA 方案，它允許在多個網(wǎng)絡(luò)節(jié)點上設(shè)置 active/active HA 模式的 neutron-l3-agent。這個方案基于 keepalived，內(nèi)部使用 VRRP 協(xié)議來組建高可靠的虛擬路由器組。根據(jù)設(shè)計，每個組只有一個活動的路由器負責(zé)網(wǎng)絡(luò)轉(zhuǎn)發(fā)，以及一個或者多個備用路由器，它們在等待活動路由器失效時接替它成為新的活動路由器。主/備路由器是被隨機地部署到不同的網(wǎng)絡(luò)節(jié)點上的，因此負載會在這些節(jié)點上被分攤。

基于 Juno 方案的一個限制是，Neutron 沒法報告 HA 路由器的狀態(tài)，這會給問題定位和維護帶來困難。Kilo 版本中，運維人員可以運行 neutron l3-agent-list-hosting-router 命令來查看活動的路由器在那個網(wǎng)絡(luò)節(jié)點上。

7. 允許選擇浮動IP (Ability to choose a specific floating IP)

浮動IP 是被動態(tài)地分配給虛機的IPv 4 地址，有了它以后，虛機可以被從外網(wǎng)中訪問，比如常見的因特網(wǎng)。一開始，當(dāng)給虛機分配浮動IP的時候，IP 地址是隨機地從地址池中選取的，因此無法保證一個虛機在多次分配時會被分配到同樣的地址。從Kilo 版本開始，用戶通過使用新的 floating_ip_address API 參數(shù)，可以指定特定的浮動IP地址來分給某個虛機。

8. MTU 廣播功能 (MTU advertisement functionality)

這個新的功能允許配置一個網(wǎng)絡(luò)的(期望)MTU，并且發(fā)布到客戶機操作系統(tǒng)中。這個新功能能夠避免多個網(wǎng)絡(luò)中的MTU不一致，因為這種不一致會帶來一些不可預(yù)測的后果，比如網(wǎng)絡(luò)連接問題、丟包和網(wǎng)絡(luò)性能降低。

9. 提升性能和穩(wěn)定性(Improved performance and stability)

OpenStack 網(wǎng)絡(luò)社區(qū)一直致力于提供一個更穩(wěn)定的和代碼更成熟的 Neutron。在 Kilo 提供的眾多性能和穩(wěn)定性優(yōu)化改進中，我想著重強調(diào)兩個：直接使用 OVSDB 和 ML2/OVS 插件通信，而不是使用 OVS 的 ovs-vsctl 命令;廣泛地重構(gòu) l3-agent 的代碼。

盡管這兩個改進都沒有給用戶引入新的功能，但是它們確實是社區(qū)一直在為優(yōu)化Neutorn代碼而努力的一個代表，特別是核心的L2 和 L3 組件，它們對所有的負載都非常關(guān)鍵。

10. 展望Liberty 版本 (Looking ahead to Liberty)

Liberty，下一個 OpenStack 版本，計劃于 2015年10月15日發(fā)布。我們正在緊張地為 Vancouver 設(shè)計峰會做準(zhǔn)備，到時新功能和改進提議都會被討論到。你可以查看 Neutron specifications for Liberty 頁面來跟蹤哪些提議會被接受到 Neutron 中，哪些會在Liberty 版本中得以實現(xiàn)。