OpenStack Kilo 版本，OpenStack 這個開源項目的第11個版本，已經于2015年4月正式釋出了。現在是個合适的時間來看看這個版本中Neutron到底發生了哪些變化了，以及引入了哪些新的關鍵功能。
為了更好地擴充 Neutron 開發社群的規模，我們在Kilo開發周期中主要做了兩項工作：解耦核心插件以及分離進階服務。這些變化不會直接影響 OpenStack 使用者，但是我們期望這些工作會帶來代碼量的減少，以及新功能開發速度的提升，進而最終帶來創新的加速。下面我們來一項一項的來看。
從設計上看，Neutron 采用可插拔式（pluggable）架構，這種架構允許實作 Neutron API 的可定制後端。Neutron 核心插件（core plugin）是整個Neutron項目開發的核心部分，它就像在邏輯API層和實際實作層之間的一個粘合層（glue）。随着Neutron項目的演進，越愛越多的插件被引入了，它們來自各個不同的開源項目和社群（比如 Open vSwitch 和 OpenDaylight），以及廣大供應商（vendor，比如 Cisco, Nuage, Midokura 等等）。在Kilo 開發周期的一開始，Neutron 有十幾個插件和驅動，包括核心插件（core plugins）、ML2 機制驅動（mechanism drivers）、L3 服務插件，以及 L4-L7 插件比如 FWaaS、LBaaS 和 VPNaaS 等，其中大部分插件的代碼都直接放在Neutron項目代碼庫中。 是以，需要檢視的Neutron代碼的數量，包括所有這些插件和驅動的代碼，已經增長到了導緻項目開發規模無法再增長的程度。讓不熟悉這些驅動或者插件的代碼檢視者，以及沒有合适的硬體或者軟體環境來驗證這些插件和驅動代碼的代碼檢視者來檢視這些插件和驅動的代碼是不現實的。同時，當供應商送出的代碼不能及時地被合并時，這些供應商難免會失望。
要改善這種境況要做的第一件事情是，将Neutron 核心插件和ML2驅動的代碼從 Neutron 代碼庫中解耦。具體的做法是，隻在Neutorn代碼樹中給上文提到的每個插件和驅動保留一個薄薄的代理（ shim/proxy）層，再把它們所有的後端實作邏輯移到不同的代碼庫中，新的代碼庫的一個比較自然的選擇是 StackForge。這麼做的好處是顯而易見的：Neutron 代碼檢視人員可以把主要精力放在檢視Neutron 核心代碼上，同時廠商和插件的維護者可以按照他們自己的疊代周期做疊代。社群已經鼓勵各代碼提供者去立即着手這項解耦工作，但是也不強制要求所有的插件在Kilo版本釋出前完成所有工作，這主要是為了給各廠商留下足夠的時間。
上述的第一件事情隻是着眼于Neutron 核心插件和 ML2 驅動，一個并行的工作是對L4-L7 進階服務(FWaaS, LBaaS, and VPNaaS)做同樣的事情。和核心插件類似，這些進階服務之前也是将代碼存放在Neutron主代碼庫中，一個相似的後果是導緻Neutron 核心代碼檢視人員失去專注性。從Kilo開始，這些服務的代碼将會被分離到它們各自的代碼樹中。是以，現在Neutron 有四個不同的代碼庫：一個用于基礎的L2/L3 網絡、分别有一個用于FWaaS, LBaaS, 和 VPNaaS。因為目前進階服務插件還比較少，目前各廠商和插件的代碼還會被保留在各個服務的代碼庫中。
值得一提的是，這麼做不會影響到OpenStack 使用者。這些服務即使現在被分離出去了，它們的 API 或者CLI 不會有任何變化，它們還會和之前一樣使用相同的 Neutron 用戶端。同時，我們确實能預計到，由于每個進階服務都有從Neutron分離出去成為獨立元件的潛力，目前所做的分離工作确實為它們将來更深層次的變化打下了基礎，将來它們可能會提供它們自己的 REST 端點、配置檔案和CLI/API 用戶端。這也使得它們的開發團隊能專注于一個或者幾個進階服務進而有可能實作更大的變化。
安全組（Security-groups）是Neutron 最常用的功能之一，它允許租戶去指定允許經過一個Neutron 端口的網絡流量的類型和方向（進/出），進而可以高效地為虛機建立防火牆。
從安全考慮，Neutron 安全組的實作，總是會自動建立阻止IP 位址欺騙攻擊的規則，來避免虛機收到或者發出與虛機的Neutron 端口的 MAC 或者 IP 位址不符的網絡包。當大多數使用者認為安全組和防IP欺騙規則非常有用而且必要時，一些人要求增加開關選項來使得他們可以在特定端口上不建立這種規則。有這種需求的主要用例是當在虛機上運作網絡服務的時候，一個常用的例子是 NFV。考慮一個在 OpenStack 虛機中部署路由應用的例子：它需要能夠接收不是發給它自己的包，還需要能夠發出不是從它任何端口産生的包。當使用了安全組時，這個虛機是沒法做這些事情的。
我們來看看這個例子的拓撲圖：
Host 1 是一個虛機，它的IPv4 位址是 192.168.0.1，現在它需要通路 Host 2，它的IP位址是 172.16.0.1。這兩個主機通過兩個運作路由應用的虛機（R1 和 R2）連接配接在一起，這兩個虛機分别被配置為主機1 和 2的預設路由。上圖顯示了端口的預設IP位址。我們來看看Host 1 是如何向 Host 2 發包的：
Host 1 産生一個 IPv4 網絡包，源IP是 192.168.0.1，目的 IP 是 172.16.0.1。因為兩個虛機在不同網段上，R1 使用它自己的MAC位址來響應Host 1 的 ARP 請求，是以，Host 1 産生的網絡幀的目的 MAC 位址為 3B-2D-B9-9B-34-40 。
R1 收到該包。注意這個包的目的IP 是 172.16.0.1，不是R1自己。在 R1 的端口上應用了Neutron安全組以後，防IP欺騙規則就預設被應用了，這個包就會被丢棄，是以 R1 無法完成進一步的路由。
Kilo 版本之前，你對整個雲要麼禁止安全組要麼使用安全組。從 Kilo 版本開始，可以使用新的屬性 port-security-enabled 來啟用或者禁用某個端口上的安全組了。這個新的屬性目前被 Open vSwitch agent 和 IptablesFirewallDriver 支援。
回到之前的拓撲，現在可以在 R1 和 R2 的端口上禁用安全組了，同時在主機虛機的端口上使用安全組。這麼做以後，就可以正常地做路由了。
随着Juno版本中引入的一些新的功能，包括允許使用 SLAAC 和 DHCPv6 來向租戶網絡配置設定IP位址，以及支援由外部路由器産生的廣告給實體網絡的 RAs消息等，IPv6 已經成為 Neutron 一個新的焦點領域 。Kilo 版本中 IPv6 功能在進一步地成熟，是以也帶來了一些其它方面的增強，包括：
允許給一個網絡配置設定多個IPv6 字首
更好的IPv6 路由支援
Kilo 版本中，OpenStack IPv6 沒有網絡位址轉換（NAT - network address translation ）或者 浮動IP。這是假設虛機會被配置設定全局可路由位址（globally routed addresses ）是以能夠和純L3路由通信的。Neutron中的 neutron-l3-agent 元件通過建立和維護虛機路由器來負責Neutorn 内的路由。要在虛機路由器中支援IPv6， 需要以下的兩個功能：
子網之間的路由：這是指網絡包在同一租戶的不同IPv6 子網之間的路由。因為這些網絡流量是在OpenStack雲内部被路由的，它們不會離開OpenStack雲去任何外部系統，這種路由往往被稱為“東西”路由。這個功能在Juno版本中就支援了，而在Kilo 中沒有大的變化。
外部路由：這是指在IPv6租戶子網和IPv6 外部子網之間的路由。因為這些流量需要離開Neutron網絡去外部網絡，它們往往被稱為“南北”流量。因為沒有 IPv6 NAT 支援，虛機路由器（virtual router）隻需要簡單地在内部子網和外部子網之間做路由。這個功能在Juno版本就支援了，但是在Kilo 中，針對運維人員（operator）建立外部網絡的方式做了主要的優化，現在他們不需要給外部網絡建立Neutron子網了。Meutron虛拟路由器可以自動地通過SLAAC 學習得到預設網關的資訊（如果RAs 在上行路由器上被啟用了的話），或者由運維人員使用 l3-agent 配置檔案中新的 ipv6-gateway 配置項來手動地指定預設網關。
增加若幹DHCP選項
使用 Neutron，使用者可以指定子網額外的 DHCP 選項。這主要用于給 Neutron 端口配置設定諸于 DNS 或者 MTU 這樣的附加資訊。一開始，這些配置隻能用在端口的 DHCPv4 或者 DHCPv6 位址上，它的問題是當給一個端口同時配置設定了IPv4 和 IPv6 兩個位址時無法使用。
從 Kilo 版本開始，可以為 DHCPv4 和 DHCPv6 設定額外的DHCP 選項。Neutron 建立和更新端口（port）的 API 增加了一個新的參數 “ip_version”，它會指定某個給定 DHCP 選項的IP版本（4 或者 6）。
LBaaS 是 Neutron 進階服務之一。它允許租戶按需建立負載均衡器，後端使用一個基于不同負載均衡技術的開源或者閉源的服務插件。在Red Hat Enterprise Linux OpenStack Platform上的開源方案是基于HAProxy的。
建立一個池
為池建立一個或者多個成員
建立健康狀态監控器
建立一個和池關聯的虛機IP
DVR，在 Juno 版本中被首次引入，允許跨計算節點部署 Neutron 虛拟路由器，這樣每個計算節點就能夠為它上面運作的虛機提供路由服務。這會提高虛拟路由器的性能和可擴充性，被視為實作更高效的L3網絡的一個重要裡程碑。
提醒一下，預設的OpenStack Neutron架構中，使用了一個專用網絡節點叢集來處理雲中的大部分網絡服務，包括 DHCP，L3 路由和 NAT。這意味着從計算節點上發出的網絡流量需要經過網絡節點才能被正确地路由。通過使用 DVR，計算節點就能夠處理它本地虛機在網段之間（東西）的路由以及浮動IP 的NAT。DVR 任然依賴專用網絡節點來提供預設的 SNAT 服務，來允許虛機通路外部網絡。
Kilo 之前，DVR 隻支援使用隧道網絡包括 GRE 和 VXLAN 等來做租戶網絡隔離。這樣的話，它就阻礙了使用者就使用 VLAN 租戶網絡了。在Kilo 中，DVR 增加了VLAN 的支援，是以，現在 DVR 即可以支援隧道網絡也可以支援VLAN 了。
基于 Juno 方案的一個限制是，Neutron 沒法報告 HA 路由器的狀态，這會給問題定位和維護帶來困難。Kilo 版本中，運維人員可以運作 neutron l3-agent-list-hosting-router <router_id> 指令來檢視活動的路由器在那個網絡節點上。
浮動IP 是被動态地配置設定給虛機的IPv 4 位址，有了它以後，虛機可以被從外網中通路，比如常見的網際網路。一開始，當給虛機配置設定浮動IP的時候，IP 位址是随機地從位址池中選取的，是以無法保證一個虛機在多次配置設定時會被配置設定到同樣的位址。從Kilo 版本開始，使用者通過使用新的 floating_ip_address API 參數，可以指定特定的浮動IP位址來分給某個虛機。
這個新的功能允許配置一個網絡的（期望）MTU，并且釋出到客戶機作業系統中。這個新功能能夠避免多個網絡中的MTU不一緻，因為這種不一緻會帶來一些不可預測的後果，比如網絡連接配接問題、丢包和網絡性能降低。
OpenStack 網絡社群一直緻力于提供一個更穩定的和代碼更成熟的 Neutron。在 Kilo 提供的衆多性能和穩定性優化改進中，我想着重強調兩個：直接使用 OVSDB 和 ML2/OVS 插件通信，而不是使用 OVS 的 ovs-vsctl 指令；廣泛地重構 l3-agent 的代碼。
盡管這兩個改進都沒有給使用者引入新的功能，但是它們确實是社群一直在為優化Neutorn代碼而努力的一個代表，特别是核心的L2 和 L3 元件，它們對所有的負載都非常關鍵。
本文轉自SammyLiu部落格園部落格，原文連結：http://www.cnblogs.com/sammyliu/p/5028647.html，如需轉載請自行聯系原作者