OpenStack與SDN：UnitedStack在提升網絡穩定性與實現高級網絡功能融合方面的經驗分享
在2014年底的一次 SDN技術沙龍 上，UnitedStack資深網絡開發工程師馬嘯對OpenStack的SDN實現情況進行了介紹。在當天的 一次訪談 中，馬嘯提到了OpenStack社區當時的幾個主要的優化方向，一個是用L2Population優化廣播報文，另一個是改善DVR（分布式路由器）的成熟度，還有一個是進行Service Chaining等能夠提供更為靈活的NFV功能的技術。
兩個月前，OpenStack的大版本 更新到Kilo ，網絡方面對于LoadBalancer和NFV場景支持都做出了改進。具體到UnitedStack這樣的公有云運行環境，過去這幾個月又有怎樣的變化？生產環境中的OpenStack SDN部署已經進展到怎樣的程度，正在面臨哪些挑戰？InfoQ中文站帶著這些問題采訪了馬嘯，以下是他的最新分享。
嘉賓簡介
馬嘯（Zebra），UnitedStack資深網絡開發工程師，SDN網絡研發負責人。對SDN網絡架構有獨到深刻的理解，曾經參與NEC通用控制器PFC、Floodlight等項目的開發。2013年開始研究SDN控制器與OpenStack Neutron的集成，2014年開始深入研究Neutron的代碼，致力于解決Neutron的穩定性、服務多樣性、性能、融合性。
InfoQ：請Zebra先簡單介紹一下你們組過去幾個月做了什么，有哪些成果，以及面臨哪些挑戰？
Zebra：SDN組在今年到目前為止的主要工作包括：
- 穩定性問題的解決（典型代表為OVS流表沖刷問題）
- 高級網絡服務的開發（LoadBalancer、GRE隧道、OpenV*N、IPSec V*N、HA Router）
- OVS底層性能的優化
另外，最近我們這邊比較關注網絡的融入性這塊，就是利用ServiceVM的架構提供網絡高級服務的融入以及與廠商方案（Cisco ACI）的融入。
目前為止，UnitedStack網絡架構主要依然是社區的VxLAN+VLAN方案和底層的OVS、Linux協議棧，其他網絡服務也都是類似社區的純軟實現。對于用ServiceVM融入廠商提供的高級網絡服務這一塊研究更加成熟之后，我們未來會融入更多的廠商方案。
網絡的融入性是我們目前的主要工作，也是面臨的主要挑戰之一。此外，社區代碼整合、Service Chain也是我們當前的工作重點。
InfoQ：請描述一下你提到的OVS流表沖刷問題。這個問題表現為什么癥狀，在怎樣的場景下出現？
Zebra：Neutron中對于OVS的使用是通過Neutron OVS Agent來完成的。原始邏輯中OVS Agent重啟的時候，會進行如下兩步操作：
- 初始化OVS的流表，主要指VLan網絡用的OVS Bridge和OVS的Tunnel Bridge（這樣就產生了沖刷）
- 重新從Neutron Server側抓取Port的信息，并針對每個Port的Network分配Vlan ID，下發對應的流表（這樣就重新建立）
這個邏輯在Port數目較少的情況下，由于流表重建較快，不會被感知到；然而在大量Port存在的情況下，會導致業務的中斷。
我們是由于在每次重啟OVS Agent服務的時候，發現會出現用戶業務中斷而注意到的這個問題。
InfoQ：你們目前是用什么方式解決這個問題的？這種方式的好處是什么，還有哪些不足？
Zebra：根據VxLAN方案的特征和Neutron對VxLAN的實現，我們知道一個Network對應的節點的本地VLAN是不能重復的。
基本思路是，只要本地VLAN前后一致、Port也一致，則對應的OVS流表就不需要重新初始化再重新建立。
OVS Agent重啟前后，Port一般是一致的。同一個VxLAN ID（Network）對應的VLAN是OVS Agent本地進行的分配，因此在OVS Agent重啟的時候，我們只需要保持VLAN不變就可以了。
如何保持VLAN一致？我們在OVS Agent重啟的時候，根據之前的Port的VLAN ID（在OVS DB中），建立Network和VLAN ID的對應關系，對應的Network不再進行VLAN分配而使用重啟前的VLAN ID，即可不再需要重建流表。
其實VLAN本地分配，在各種V*N方案中是一種通用方式。在SDN的趨勢下，有些實現的思路是在SDN控制器側完成對應的節點的上 Network的VLAN分配，但是如果這樣改動，則與Neutron差別較大，顯然不是好的改動方式。我們采用的這種Agent本地分配、保持 Agent重啟前后VLAN不變的思路，則無需對Neutron進行太大的改動。
關于穩定性問題我想再補充兩個：
1、iptables安全組規則的泄漏。我們知道Neutron安全組是一個虛擬機的Port對應下發iptables規則實現的，OVS Agent存在一個BUG，即在某種時序下Port刪除了，安全組規則被殘留下來；殘留的規則過多的情況下，則會導致iptables規則下發變慢，而在 OVS Agent的邏輯中，iptables規則下發后，才會配置Port的Vlan tag。最終的表現是：有時候，如果用戶創建一個network并且立即創建一個屬于該network的虛擬機則這個虛擬機可能不能通過DHCP立即獲取到IP地址。這類問題隱藏的很深，只有長時間運行OVS Agent才會體現出來。
2、IPtables在L3 Agent重啟的時候，重刷iptables規則問題。我們知道，Neutrons社區的原始路由和NAT是通過網絡節點做的，由L3 Agent所管理。當L3 Agent重啟時，代碼在收到router add事件時，會做一次內存中存儲的iptables規則和實際網絡節點的iptables的規則的同步，而這個時間點，該Agent還沒有將該路由的 NAT規則寫入到內存中，如果進行同步，自然導致iptables規則的沖刷，引發業務中斷。這個問題和ovs流表問題屬于同種類型。也是極難發現的隱藏 BUG。
從上述這三個問題可以看到，社區代碼在穩定性的潛在風險集中在對時序問題的考慮不全，各個場景下的sequence圖沒畫好。穩定性問題實際體現的是對社區代碼的駕馭能力，沒有長時間的運維、不認真閱讀社區的代碼（比如上述OVS Agent的代碼）是不能查清楚的。
InfoQ：可否介紹一下你上面提到的ServiceVM架構？
Zebra：有關ServiceVM架構，可以查看這個 OpenStack Tacker項目的文檔 。簡單來說，Tacker是用來管理提供高級服務的虛擬機，進行虛擬機服務的動態操作的管理。
官方文檔的簡介如下：
Tacker是一個基于OpenStack的VNF管理服務，是一個用于在OpenStack搭建的NFV平臺上部署運維VNF的框架。它基于ETSI MANO架構，為VNF的端到端管理提供了一套完整的功能棧。
ETSI是歐洲電信標準協會，NFV相關標準制定工作主要由該協會推進。MANO是 網路功能虛擬化管理與協調流程(NFV Management and Orchestration, NFV MANO)的意思。 ETSI MANO架構中（Tacker項目鏈接中有架構圖），NFV被分為三個功能模塊：
- NFV協同器，用于上線新增網絡服務與VNF包，管理網絡服務的生命周期，進行全局資源管理，以及NFVI資源請求的權限認證工作
- VNF管理器，用于進行VNF實例的生命周期管理，以及在NFVI和E/NMS之間進行協調與事件報告
- 基礎設施管理器（VIM），用于對NFVI用到的計算、存儲與網絡資源進行控制管理
我們對于移植ServiceVM的代碼以進行虛擬機管理這方面的工作目前還處于概念驗證階段，主要仍然是參考社區的開發。
InfoQ：去年你介紹了OpenContrail以及Floodlight、RYU等控制器的情況。現在過了大半年，SDN控制器現在是個什么狀況，哪些發展的更成熟？
Zebra：OpenContrail已經具有較強的商用價值。Floodlight、Ryu只適合學習。
InfoQ：OpenStack用于NFV場景的部署現在被越來越多運營商關注，不少網絡廠商和軟件廠商現在都在這塊發力，這似乎對于Neutron/Nova帶來很多影響？你對此有何看法？
Zebra：運營商網絡畢竟和云網絡有所不同，我們也關注NFV的應用，但是用例的關注點會有較大差異。
InfoQ：現在我們跟進社區代碼的更新是怎樣的頻率？跟隨大版本，還是按照每日或其他的頻率更新？
Zebra：這個問題確實也是困擾我們的問題。我們現在是Juno版，之前跟社區會半年做一次同步。我們自己開發了一些適合中國市場的功能，打算這次做Kilo合并之前進行一次我們自身代碼的重構，因為我們知道Kilo版變化特別大，我們希望通過自身代碼的重構，最大程度的降低與社區代碼的藕合度，以方便后續的大版本升級。