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

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

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

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

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

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

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

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

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

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

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

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

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

我們來看看這個(gè)例子的拓?fù)鋱D：

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

1. Host 1 產(chǎn)生一個(gè) IPv4 網(wǎng)絡(luò)包，源IP是 192.168.0.1，目的 IP 是 172.16.0.1。因?yàn)閮蓚€(gè)虛機(jī)在不同網(wǎng)段上，R1 使用它自己的MAC地址來響應(yīng)Host 1 的 ARP 請求，因此，Host 1 產(chǎn)生的網(wǎng)絡(luò)幀的目的 MAC 地址為 3B-2D-B9-9B-34-40 。
2. R1 收到該包。注意這個(gè)包的目的IP 是 172.16.0.1，不是R1自己。在 R1 的端口上應(yīng)用了Neutron安全組以后，防IP欺騙規(guī)則就默認(rèn)被應(yīng)用了，這個(gè)包就會(huì)被丟棄，因此 R1 無法完成進(jìn)一步的路由。

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

回到之前的拓?fù)洌F(xiàn)在可以在 R1 和 R2 的端口上禁用安全組了，同時(shí)在主機(jī)虛機(jī)的端口上使用安全組。這么做以后，就可以正常地做路由了。

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

3. IPv6 增強(qiáng) (IPv6 enhancements)

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

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

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

更好的IPv6 路由支持

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

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

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

增加若干DHCP選項(xiàng)

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

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

4. LBaaS v2 API

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

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

1. 創(chuàng)建一個(gè)池
2. 為池創(chuàng)建一個(gè)或者多個(gè)成員
3. 創(chuàng)建健康狀態(tài)監(jiān)控器
4. 創(chuàng)建一個(gè)和池關(guān)聯(lián)的虛機(jī)IP

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

#p#

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

DVR，在 Juno 版本中被首次引入，允許跨計(jì)算節(jié)點(diǎn)部署 Neutron 虛擬路由器，這樣每個(gè)計(jì)算節(jié)點(diǎn)就能夠?yàn)樗厦孢\(yùn)行的虛機(jī)提供路由服務(wù)。這會(huì)提高虛擬路由器的性能和可擴(kuò)展性，被視為實(shí)現(xiàn)更高效的L3網(wǎng)絡(luò)的一個(gè)重要里程碑。

提醒一下，默認(rèn)的OpenStack Neutron架構(gòu)中，使用了一個(gè)專用網(wǎng)絡(luò)節(jié)點(diǎn)集群來處理云中的大部分網(wǎng)絡(luò)服務(wù)，包括 DHCP，L3 路由和 NAT。這意味著從計(jì)算節(jié)點(diǎn)上發(fā)出的網(wǎng)絡(luò)流量需要經(jīng)過網(wǎng)絡(luò)節(jié)點(diǎn)才能被正確地路由。通過使用 DVR，計(jì)算節(jié)點(diǎn)就能夠處理它本地虛機(jī)在網(wǎng)段之間(東西)的路由以及浮動(dòng)IP 的NAT。DVR 任然依賴專用網(wǎng)絡(luò)節(jié)點(diǎn)來提供默認(rèn)的 SNAT 服務(wù)，來允許虛機(jī)訪問外部網(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的信息，強(qiáng)烈建議你去讀 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 版本中引入的一個(gè)重要功能是L3 HA 方案，它允許在多個(gè)網(wǎng)絡(luò)節(jié)點(diǎn)上設(shè)置 active/active HA 模式的 neutron-l3-agent。這個(gè)方案基于 keepalived，內(nèi)部使用 VRRP 協(xié)議來組建高可靠的虛擬路由器組。根據(jù)設(shè)計(jì)，每個(gè)組只有一個(gè)活動(dòng)的路由器負(fù)責(zé)網(wǎng)絡(luò)轉(zhuǎn)發(fā)，以及一個(gè)或者多個(gè)備用路由器，它們在等待活動(dòng)路由器失效時(shí)接替它成為新的活動(dòng)路由器。主/備路由器是被隨機(jī)地部署到不同的網(wǎng)絡(luò)節(jié)點(diǎn)上的，因此負(fù)載會(huì)在這些節(jié)點(diǎn)上被分?jǐn)偂?/p>

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

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

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

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

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

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

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

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

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

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

原文鏈接：http://www.cnblogs.com/sammyliu/p/5028647.html?utm_source=tuicool&utm_medium=referral