OpenStack Neutron結合SDN的架構分析

責任編輯:editor005

作者:北京小武

2015-09-17 14:26:52

摘自:SDNLab

等服務。Neutron as Controller:將Neutron作為SDN控制器的一部分,VM上部署的用戶業(yè)務直接或間接調用Neutron的接口,來申請和使用底層網絡資源。

OpenStack 開源社區(qū)為云計算提供了最大平臺,有多個組件分別實現(xiàn)計算(Nova)、存儲(Cinder/Swift)、監(jiān)控(Ceilometer)和網絡(Neutron)等服務。隨著Neutron逐漸成熟,越來越多的云計算廠家開始選用Neutron組件,并且有大量網絡設備商和云計算方案廠商為 Neutron提供硬件設備和網絡方案,使得Neutron的發(fā)展倍受關注。

OpenStack Neutron結合SDN的架構分析

  Neutron的華麗

云計算改變了用戶的業(yè)務部署方式,從而幫助用戶節(jié)省設備和運營成本。例如,類似12306 的火車票業(yè)務,它具有非常明顯的時節(jié)性,平常的業(yè)務流量并不是特別大,但到了節(jié)假日業(yè)務量會猛增。如果采用傳統(tǒng)的方式部署硬件設備,勢必會在業(yè)務流量少時造成硬件設備資源的浪費,而在業(yè)務流量猛增時又不能及時擴展硬件資源。但如果在云上運營,則可以在業(yè)務流量少時減少云主機和網絡帶寬等資源,在業(yè)務流量猛增時快速部署大量虛擬機,為新業(yè)務量提供服務。理想的方式是通過SDS(Software Defined Storatge)和 SDN(Software Defined Network)等方式,讓業(yè)務(相當于SDN中的App,即Software)在激增時,自動調用相關接口,申請并使用滿足其需求的計算資源、存儲資源和網絡資源。其中SDN是目前網絡和云計算領域中非?;馃岬木W絡架構,它結合 NFV(Network Function Virtualization)等相關技術,掀起了一場顛覆傳統(tǒng)網絡的革命。圖1是Neutron的拓撲示意圖。

OpenStack Neutron結合SDN的架構分析

  圖1 Neutron拓撲示意圖

Neutron自身無法克服的難題

Neutron中提供了使用虛擬路由器實現(xiàn)租戶網絡的互通和隔離、安全組(Security Group)、防火墻(FWaas)、負載均衡(LBaas)和虛擬專用網(VPNaas)等服務。在Neutron網絡中還可以采用VMaas(VM as a Service)的方式提供一些極易創(chuàng)新的網絡服務,包括Neutron中不支持的接入VPN等功能。雖然Neutron 的功能已經相對比較完備,但還存在一些不足之處,這也是為何Neutron需要SDN架構的部分原因。

有很多的網絡功能無法滿足部署需求,例如基于VM網卡或IP的限速、基于路由的限速以及基于租戶的限速等網絡需求,至今仍沒有完善的解決方案,而這些在實際物理網絡中部署都是極其常見的功能。曾經有人提出用Libvirt對虛擬機網卡的inbound average和outbound average做出入方向的限速,但我認為這個方案非常不妥。部署該方案時是通過設置flavor的quota:vif_inbound_average和 quota:vif_outbound_average來實現(xiàn)的,會導致對VM的所有網卡都做限制。而且該方案不僅限制了南北流量,還限制了東西流量,是不可用的方案。Qos功能不只是限速,還有很多諸如隊列調度、流控等方面的Qos需求,當有業(yè)務需要時,Neutron卻無從提供滿足需求的支持。

網絡節(jié)點存在的單點故障問題至今依然沒有完善的解決方案,DVR(Distributed Virtual Routing,分布式路由)對虛擬路由器的 HA方案也存在很大的缺陷。而與傳統(tǒng)交換機(甚至與路由器)相比,網絡節(jié)點的帶寬能力還存在一定差距,尤其是對單路由帶寬沒有分流方案,一旦帶寬超過虛擬路由器的帶寬能力則無能為力。

對Neutron網絡的監(jiān)控,雖然可以通過Ceilometer組件使用Neutron的neutron-meter-agent進行采集,但除了Ceilometer組件存儲采集數(shù)據(jù)持久化性能方面的問題,還存在很多監(jiān)控項無法采集到的問題。

在Neutron中經常使用Open vSwitch虛擬交換機,而其在計算節(jié)點和網絡節(jié)點的虛擬交換機都有穩(wěn)定性和性能方面的限制,尤其是使用VXLAN等隔離方式時,報文的封裝和解封裝很可能成為網絡瓶頸。

OpenStack Neutron結合SDN的架構分析

  SDN讓Neutron更強大

除了上述問題,Neutron還有很多實際部署難題需要處理。而如果采用SDN架構的話,這些問題將會有相當一部分得到解決。假設SDN控制器南向采用了OpenFlow協(xié)議,那么就能很容易控制流量轉發(fā)以實現(xiàn)不同虛擬路由器的流量分擔,通過goto tables(或者“goto entry”)來實現(xiàn)數(shù)據(jù)流按照OpenFlow規(guī)則進行的基于IP、虛擬路由器甚至租戶的限速功能。那么Neutron在SDN架構中是如何部署的呢?大概有三種方式部署(這里說的Neutron多指neutron-server)。

Neutron as App:將Neutron作為SDN中申請網絡資源的App,與使用網絡資源的VM上部署的用戶業(yè)務聯(lián)動,實現(xiàn)對網絡資源的控制。這種方式需要替換Neutron 的底層網絡架構,繼而Neutron通過SDN控制器控制網絡資源。如果該方案只用Neutron的API,那么Neutron之外的功能還是無法使用,只能再額外調用SDN控制器的API,這樣就需要維護兩套API在兼容條件下配合使用。這樣,讓網絡資源的申請者neutron-server與網絡資源的使用者VM里的App進行聯(lián)動。

Neutron as Controller:將Neutron作為SDN控制器的一部分,VM上部署的用戶業(yè)務直接或間接調用Neutron的接口,來申請和使用底層網絡資源。這種方案里用戶的業(yè)務只需要調用SDN控制器的API,沒有API兼容性問題,底層網絡可以替換也可以不替換,但部署時需要考慮Neutron和SDN控制器的對等關系。

Neutron as Underlay:將 Neutron作為底層承載網絡,為SDN控制器提供南向接口,VM上部署的用戶業(yè)務直接或間接使用SDN控制器來申請和使用網絡資源,然后SDN控制器再調用Neutron接口來做底層網絡資源的調度與分配。這種方案部署容易,但僅用Neutron原來的底層網絡結構和API,需要對Neutron做開發(fā)才能提供所需求的新功能。

三種方式各有優(yōu)缺點,需要結合自身的業(yè)務和廠家自身的技術積累進行選擇,因為SDN本身是一種新型的網絡架構,如果結合NFV的理念,使用白牌交換機等方式,那么就更能解除對設備商家的綁定。

結束語

云計算是將來數(shù)據(jù)中心提供服務的新模式,也是IT技術變革的趨勢之一。據(jù)估計網絡研發(fā)的工作量會占有云計算研發(fā)工作量的一半以上,這也是云計算技術難點的突破之處。目前比較有名的SDN控制器OpenDaylight(圖2)、OpenContrail和Ryu等,都支持Neutron與SDN架構結合。希望SDN技術能讓云計算的網絡技術更優(yōu)雅地提供難題的解決方案,在將來的云計算網絡之路上,大放光彩。

鏈接已復制,快去分享吧

企業(yè)網版權所有?2010-2024 京ICP備09108050號-6京公網安備 11010502049343號