編者按：Neutron是OpenStack提供網絡服務的專用組件，雖然目前其功能已相對比較完備，但還存在一些不足之處，需要結合SDN架構來解決部分網絡部署難題。本文分享了相應的實踐思路。
OpenStack開源社區爲雲計算提供了最大平臺，有多個組件分別實現計算（Nova）、存儲（Cinder/Swift）、監控（Ceilometer）和網絡（Neutron）等服務。隨着Neutron逐漸成熟，越來越多的雲計算廠家開始選用Neutron組件，並且有大量網絡設備商和雲計算方案廠商爲Neutron提供硬件設備和網絡方案，使得Neutron的發展倍受關注。
Neutron的華麗
雲計算改變了用戶的業務部署方式，從而幫助用戶節省設備和運營成本。例如，類似12306的火車票業務，它具有非常明顯的時節性，平常的業務流量並不是特別大，但到了節假日業務量會猛增。如果採用傳統的方式部署硬件設備，勢必會在業務流量少時造成硬件設備資源的浪費，而在業務流量猛增時又不能及時擴展硬件資源。但如果在雲上運營，則可以在業務流量少時減少雲主機和網絡帶寬等資源，在業務流量猛增時快速部署大量虛擬機，爲新業務量提供服務。理想的方式是通過SDS（Software Defined Storatge）和SDN（Software Defined Network）等方式，讓業務（相當於SDN中的App，即Software）在激增時，自動調用相關接口，申請並使用滿足其需求的計算資源、存儲資源和網絡資源。其中SDN是目前網絡和雲計算領域中非常火熱的網絡架構，它結合NFV（Network Function Virtualization）等相關技術，掀起了一場顛覆傳統網絡的革命。圖1是Neutron的拓撲示意圖。
圖1 Neutron拓撲示例圖
Neutron自身無法克服的難題
Neutron中提供了使用虛擬路由器實現租戶網絡的互通和隔離、安全組（Security Group）、防火牆（FWaas）、負載均衡（LBaas）和虛擬專用網（VPNaas）等服務。在Neutron網絡中還可以採用VMaas（VM as a Service）的方式提供一些極易創新的網絡服務，包括Neutron中不支持的接入VPN等功能。雖然Neutron的功能已經相對比較完備，但還存在一些不足之處，這也是爲何Neutron需要SDN架構的部分原因。
有很多的網絡功能無法滿足部署需求，例如基於VM網卡或IP的限速、基於路由的限速以及基於租戶的限速等網絡需求，至今仍沒有完善的解決方案，而這些在實際物理網絡中部署都是極其常見的功能。曾經有人提出用Libvirt對虛擬機網卡的inbound average和outbound average做出入方向的限速，但我認爲這個方案非常不妥。部署該方案時是通過設置flavor的quota:vif_inbound_average和quota:vif_outbound_average來實現的，會導致對VM的所有網卡都做限制。而且該方案不僅限制了南北流量，還限制了東西流量，是不可用的方案。Qos功能不只是限速，還有很多諸如隊列調度、流控等方面的Qos需求，當有業務需要時，Neutron卻無從提供滿足需求的支持。
網絡節點存在的單點故障問題至今依然沒有完善的解決方案，DVR（Distributed Virtual Routing，分佈式路由）對虛擬路由器的HA方案也存在很大的缺陷。而與傳統交換機（甚至與路由器）相比，網絡節點的帶寬能力還存在一定差距，尤其是對單路由帶寬沒有分流方案，一旦帶寬超過虛擬路由器的帶寬能力則無能爲力。
對Neutron網絡的監控，雖然可以通過Ceilometer組件使用Neutron的neutron-meter-agent進行採集，但除了Ceilometer組件存儲採集數據持久化性能方面的問題，還存在很多監控項無法採集到的問題。
在Neutron中經常使用Open vSwitch虛擬交換機，而其在計算節點和網絡節點的虛擬交換機都有穩定性和性能方面的限制，尤其是使用VXLAN等隔離方式時，報文的封裝和解封裝很可能成爲網絡瓶頸。
圖2 HELIUM版本OpenDaylight架構
SDN讓Neutron更強大
除了上述問題，Neutron還有很多實際部署難題需要處理。而如果採用SDN架構的話，這些問題將會有相當一部分得到解決。假設SDN控制器南向採用了OpenFlow協議，那麼就能很容易控制流量轉發以實現不同虛擬路由器的流量分擔，通過goto tables（或者“goto entry”）來實現數據流按照OpenFlow規則進行的基於IP、虛擬路由器甚至租戶的限速功能。那麼Neutron在SDN架構中是如何部署的呢？大概有三種方式部署（這裏說的Neutron多指neutron-server）。
Neutron as App：將Neutron作爲SDN中申請網絡資源的App，與使用網絡資源的VM上部署的用戶業務聯動，實現對網絡資源的控制。這種方式需要替換Neutron的底層網絡架構，繼而Neutron通過SDN控制器控制網絡資源。如果該方案只用Neutron的API，那麼Neutron之外的功能還是無法使用，只能再額外調用SDN控制器的API，這樣就需要維護兩套API在兼容條件下配合使用。這樣，讓網絡資源的申請者neutron-server與網絡資源的使用者VM裏的App進行聯動。
Neutron as Controller：將Neutron作爲SDN控制器的一部分，VM上部署的用戶業務直接或間接調用Neutron的接口，來申請和使用底層網絡資源。這種方案裏用戶的業務只需要調用SDN控制器的API，沒有API兼容性問題，底層網絡可以替換也可以不替換，但部署時需要考慮Neutron和SDN控制器的對等關係。
Neutron as Underlay：將Neutron作爲底層承載網絡，爲SDN控制器提供南向接口，VM上部署的用戶業務直接或間接使用SDN控制器來申請和使用網絡資源，然後SDN控制器再調用Neutron接口來做底層網絡資源的調度與分配。這種方案部署容易，但僅用Neutron原來的底層網絡結構和API，需要對Neutron做開發才能提供所需求的新功能。
三種方式各有優缺點，需要結合自身的業務和廠家自身的技術積累進行選擇，因爲SDN本身是一種新型的網絡架構，如果結合NFV的理念，使用白牌交換機等方式，那麼就更能解除對設備商家的綁定。
結束語
雲計算是將來數據中心提供服務的新模式，也是IT技術變革的趨勢之一。據估計網絡研發的工作量會佔有云計算研發工作量的一半以上，這也是雲計算技術難點的突破之處。目前比較有名的SDN控制器OpenDaylight（圖2）、OpenContrail和Ryu等，都支持Neutron與SDN架構結合。希望SDN技術能讓雲計算的網絡技術更優雅地提供難題的解決方案，在將來的雲計算網絡之路上，大放光彩。 （責編：劉亞瓊）
作者：北京-小武。從事於雲計算網絡的研發和架構設計工作，混跡於SDN和Openstack的網絡兩個圈子。 新浪微博：@北京-小武
本文爲CSDN原創文章，未經允許不得轉載，如需轉載請聯繫market#csdn.net(#換成@)