OpenStack Kilo 版本，OpenStack 這個開源項目的第11個版本，已經于2015年4月正式發布了。現在是個合適的時間來看看這個版本中Neutron到底發生了哪些變化了，以及引入了哪些新的關鍵功能。
1. 擴展 Neutron 開發社區 (Scaling the Neutron development community)
為了更好地擴展 Neutron 開發社區的規模，我們在Kilo開發周期中主要做了兩項工作：解耦核心插件以及分離高級服務。這些變化不會直接影響 OpenStack 用戶，但是我們期望這些工作會帶來代碼量的減少，以及新功能開發速度的提升，從而最終帶來創新的加速。下面我們來一項一項的來看。
1.1 解耦Neutorn核心插件 (Neutron core plugin decomposition)
從設計上看，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版本發布前完成所有工作，這主要是為了給各廠商留下足夠的時間。
關于該流程的更多信息，請閱讀該文檔，它是專門用來跟蹤所有插件的進度的。
1.2 分離高級服務 (Advanced services split)
上述的第一件事情只是著眼于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 客戶端。這也使得它們的開發團隊能專注于一個或者幾個高級服務從而有可能實現更大的變化。
2. ML2/Open vSwitch 端口安全 (ML2/Open vSwitch port-security)
安全組(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 的端口上禁用安全組了，同時在主機虛機的端口上使用安全組。這么做以后，就可以正常地做路由了。
更多的信息，以及配置示例，可以在 Red Hat 公司 Terry Wilson 的 blog 上找到。
3. IPv6 增強 (IPv6 enhancements)
隨著Juno版本中引入的一些新的功能，包括允許使用 SLAAC 和 DHCPv6 來向租戶網絡分配IP地址，以及支持由外部路由器產生的廣告給物理網絡的 RAs消息等，IPv6 已經成為 Neutron 一個新的焦點領域 。Kilo 版本中 IPv6 功能在進一步地成熟，因此也帶來了一些其它方面的增強，包括：
允許給一個網絡分配多個IPv6 前綴
IPv6 允許給一個網卡分配多個IP前綴。這其實是個常見的配置，通 常地，所有的網卡會被分配一個本地連接地址(link-local address， LLA)用于處理本地連接的網絡流量，其中一個或者多個網卡會被分配全局單播地址( global unicast addresses ，GUA)來處理端到端的網絡連接流量。從 Kilo 版本開始，用戶可以分配多個IPv6 子網給一個網絡。當子網的類型是 SLAAC 或者 無狀態的DHCPv6 的時候，一個Neutron 端口會被從每個子網中分配一個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)。
4. LBaaS v2 API
LBaaS 是 Neutron 高級服務之一。它允許租戶按需創建負載均衡器，后端使用一個基于不同負載均衡技術的開源或者閉源的服務插件。在Red Hat Enterprise Linux OpenStack Platform上的開源方案是基于HAProxy的。
LBaaS v1.0 API 包括基本的負載均衡能力，實現了一個簡單而直接的工作流來設置負載均衡服務：
創建一個池
為池創建一個或者多個成員
創建健康狀態監控器
創建一個和池關聯的虛機IP
這個實現在做初始實現和部署LBaaS時會有幫助，但是，它不足以提供企業級的高級負載均衡器。LBaaS 2.0 能夠提供更加強大的負載均衡方案，包括支持SSL/TLS 端點。要實現這個目標，需要重新設計LBaaS的架構，具體你可以參考 HAProxy reference plugin.
[page]5. 增加 DVR 對 VLAN 模式的支持 (Distributed Virtual Routing (DVR) VLAN support)
DVR，在 Juno 版本中被首次引入，允許跨計算節點部署 Neutron 虛擬路由器，這樣每個計算節點就能夠為它上面運行的虛機提供路由服務。這會提高虛擬路由器的性能和可擴展性，被視為實現更高效的L3網絡的一個重要里程碑。
提醒一下，默認的OpenStack Neutron架構中，使用了一個專用網絡節點集群來處理云中的大部分網絡服務，包括 DHCP，L3 路由和 NAT。這意味著從計算節點上發出的網絡流量需要經過網絡節點才能被正確地路由。通過使用 DVR，計算節點就能夠處理它本地虛機在網段之間(東西)的路由以及浮動IP 的NAT。DVR 任然依賴專用網絡節點來提供默認的 SNAT 服務，來允許虛機訪問外部網絡。
Kilo 之前，DVR 只支持使用隧道網絡包括 GRE 和 VXLAN 等來做租戶網絡隔離。這樣的話，它就阻礙了用戶就使用 VLAN 租戶網絡了。在Kilo 中，DVR 增加了VLAN 的支持，因此，現在 DVR 即可以支持隧道網絡也可以支持VLAN 了。
更多的關于DVR的信息，強烈建議你去讀 Red Hat 公司的 Assaf Muller 的三篇非常棒的blog：overview and east/west routing, SNAT, and Floating IPs：。
6. 查看HA虛擬路由器的狀態 (View the state of Highly Available routers)
Juno 版本中引入的一個重要功能是L3 HA 方案，它允許在多個網絡節點上設置 active/active HA 模式的 neutron-l3-agent。這個方案基于 keepalived，內部使用 VRRP 協議來組建高可靠的虛擬路由器組。根據設計，每個組只有一個活動的路由器負責網絡轉發，以及一個或者多個備用路由器，它們在等待活動路由器失效時接替它成為新的活動路由器。主/備路由器是被隨機地部署到不同的網絡節點上的，因此負載會在這些節點上被分攤。
基于 Juno 方案的一個限制是，Neutron 沒法報告 HA 路由器的狀態，這會給問題定位和維護帶來困難。Kilo 版本中，運維人員可以運行 neutron l3-agent-list-hosting-router 命令來查看活動的路由器在那個網絡節點上。
7. 允許選擇浮動IP (Ability to choose a specific floating IP)
浮動IP 是被動態地分配給虛機的IPv 4 地址，有了它以后，虛機可以被從外網中訪問，比如常見的因特網。一開始，當給虛機分配浮動IP的時候，IP 地址是隨機地從地址池中選取的，因此無法保證一個虛機在多次分配時會被分配到同樣的地址。從Kilo 版本開始，用戶通過使用新的 floating_ip_address API 參數，可以指定特定的浮動IP地址來分給某個虛機。
8. MTU 廣播功能 (MTU advertisement functionality)
這個新的功能允許配置一個網絡的(期望)MTU，并且發布到客戶機操作系統中。這個新功能能夠避免多個網絡中的MTU不一致，因為這種不一致會帶來一些不可預測的后果，比如網絡連接問題、丟包和網絡性能降低。
9. 提升性能和穩定性(Improved performance and stability)
OpenStack 網絡社區一直致力于提供一個更穩定的和代碼更成熟的 Neutron。在 Kilo 提供的眾多性能和穩定性優化改進中，我想著重強調兩個：直接使用 OVSDB 和 ML2/OVS 插件通信，而不是使用 OVS 的 ovs-vsctl 命令;廣泛地重構 l3-agent 的代碼。
盡管這兩個改進都沒有給用戶引入新的功能，但是它們確實是社區一直在為優化Neutorn代碼而努力的一個代表，特別是核心的L2 和 L3 組件，它們對所有的負載都非常關鍵。
10. 展望Liberty 版本 (Looking ahead to Liberty)
Liberty，下一個 OpenStack 版本，計劃于 2015年10月15日發布。我們正在緊張地為 Vancouver 設計峰會做準備，到時新功能和改進提議都會被討論到。你可以查看 Neutron specifications for Liberty 頁面來跟蹤哪些提議會被接受到 Neutron 中，哪些會在Liberty 版本中得以實現。
京公網安備 11010502049343號