- 深入理解OpenStack Neutron
- 李宗標
- 2145字
- 2019-01-04 06:09:54
1.2 Neutron的特性與應用
從Nova-Network起步,經過Quantum,再跨入新時代以后,經過幾年的積累,Neutron在網絡的各個方面都取得了長足的發展。當前Neutron支持的特性,如表1-2所示:
表1-2 Neutron支持的特性

Neutron支持的這些特性,涵蓋了2~7層的各種服務。除了基本的、必須支持的二層、三層服務,Neutron在4~7層支持的服務有:LBaaS(負載均衡即服務)、FWaaS(防火墻即服務)、VPNaaS(VPN即服務)、Metering(網絡計量服務)、DNSaaS(DNS即服務)等。Neutron在大規模高性能層面,還支持L2pop、DVR、VRRP等特性。
Neutron的應用分為兩大類:基于OpenStack的應用、基于SDN的應用。前者是在云的場景下,與OpenStack其他部件一起配合,為用戶提供云服務。后者是在SDN場景下,與SDN Controller一起配合,為用戶提供網絡服務。
1.2.1 基于OpenStack的應用
基于OpenStack的應用,就是原生的云應用,Neutron作為OpenStack中的網絡部件,為用戶提供網絡服務。
早期的Nova-Network時代,Neutron所支持的網絡模型還比較簡單,僅僅是單一的網絡平面(或者是Flat,或者是VLAN),而且沒有租戶隔離,如圖1-3所示:

圖1-3 單平面租戶共享網絡
圖1-3中,共享網絡那個方框是Neutron的管理范圍,它所表達的意思是:租戶可以創建許多虛擬機,但是這些虛擬機只能連接到一個網絡上。不同的租戶共享一個網絡,而且這個網絡要么是VLAN網絡,要么是Flat網絡,只能是單一的網絡類型。雖然Neutron在當時能夠支持兩種網絡類型,但是在同一時刻,只能選擇一種(雖然也沒什么好選的)。另外,Neutron還不支持路由器,它必須借助外部路由器(圖1-3中的Physical Router)才能有三層路由功能,這也意味著,不同租戶的VM也必須在同一個網段,而且IP地址也不能重疊。
筆者當初第一眼看到這個圖的時候,內心是崩潰的。不是因為它簡單,而是因為它太簡單。如果我們以物理世界的交換機、路由器來組網的話,單一平面網絡就相當于圖1-4所示的組網圖:

圖1-4 單平面網絡在物理世界的映射
單一平面網絡,名字取得這么清新脫俗,不過是實現了一個低端交換機而已。人生若只如初見,何事秋風悲畫扇。說句心里話,如果網絡技術真的這么簡單倒挺好,大家也不用費那么大力氣去學習了。
世界是復雜的,網絡也是復雜的,Neutron也在慢慢成長,變成了今天的模樣——支持多平面租戶私有網絡,如圖1-5所示:
圖1-5所表達的網絡特征,總結如表1-3所示:

圖1-5 多平面租戶私有網絡
表1-3 多平面租戶私有網絡的特征

可以看到,Neutron從當初的低端交換機已經發展成為支持各種協議,融合交換機、路由器為一體的,支持多租戶隔離的綜合解決方案。
有一點需要澄清一下,圖1-5中的網絡(比如租戶A的私有網絡)具體指的是什么?圖1-4用了一個交換機做比方,雖然很痛快地說明了當初Nova-Network時代功能的不足,但是容易讓人產生誤解,以為Neutron當前的網絡也不過是一個交換機而已,只是高端一點罷了。其實不然,無論是當初的Nova-Network時代,還是當今的Neutron時代,網絡從具體實現來說,都不僅僅是一個交換機,而是一群交換機。
從模型角度來說,網絡指的是Neutron的資源模型,是一個邏輯概念。從實現來說,網絡指的是一群交換機,如圖1-6所示:

圖1-6 網絡的實現模型
圖1-6中,VM1、VM2、VM3分屬3個Host,組成一個網絡。從實現角度來說,這個網絡指的就是3個Host中的3個虛擬交換機。
說明
實際上,虛擬機交換機比圖1-6還要復雜,這里僅僅是一個簡單示意。具體請參見第3章的描述。
Neutron基于OpenStack的應用,網絡的實現一般都是Host內的虛擬交換機。在SDN場景下,網絡的實現很多選用廠商的硬件交換機(和路由器)。
1.2.2 基于SDN的應用
一千個人的心中,就有一千個SDN。本文所說的SDN,指的是傳統老牌設備廠商推出的SDN方案,如圖1-7所示:

圖1-7 基于SDN的應用場景
圖1-7所描述的應用場景,可以說是SDN浪潮大背景下的運營商與傳統老牌設備商心照不宣各取所需的“創新”方案。運營商一直以來都被各個設備廠商提供的形態各異、紛繁復雜的管理接口所深深“傷害”,一直期望能有一個統一的接口。隨著OpenStack的發展,Neutron接口成為不少運營商的一個選擇。當然,在SDN浪潮之下,僅僅選擇Neutron接口是不夠的,必須得沾上SDN的仙氣。于是圖1-7中的SDN控制器的存在就成為一種必然。這正好也中了設備商的下懷。1.2.1節提到,基于OpenStack的Neutron應用,其選擇的基本是Host內的虛擬交換機、路由器,這是傳統老牌設備商所不能接受的——如果都選擇了虛擬設備,那自家生產的交換機、路由器賣給誰去?于是設備商就與運營商一拍即合,推出了自家的“SDN控制器+硬件設備(交換機、路由器)”綜合解決方案,并將SDN控制器掛接在Neutron的下面,對外以Neutron的統一接口和SDN的面貌出現,其實醉翁之意不在酒,在乎銷售自己的硬件設備也。
客觀地說,設備商以這樣的方案推銷自己的硬件設備,除了在商言商無可指責以外,從技術角度而言,其實也是一個比較正確的選擇,畢竟當前的虛擬交換機、路由器,其性能還是不能跟硬件設備相比,在很多場景下還是有點力不從心。
下面我們就以開源組織OPEN-O的一個用例為例來直觀感受一下,如圖1-8所示:

圖1-8 OPEN-O Enterprise 2 DC場景解決方案
圖1-8描述的是一個Enterprise 2 DC的場景,圖左邊的組網及“其他SDN控制器”與本文主題無關,我們先忽略。圖右邊是一個DC(數據中心), OPEN-O向下看到的是Neutron接口,而DC SDN控制器掛接在Neutron之下,對DC中的硬件設備(GW、TOR)進行配置管理。
說明
OPEN-O已經與AT&T的openECOMP合并為一個新的開源組織ONAP。
業界基于SDN的Neutron的應用案例還有很多,限于篇幅原因,這里就不一一列舉。不過所有的案例、所有的解決方案,它們都有一個共同的特點:所有的SDN控制器都是掛接在Neutron之下的。這不僅因為業界期望Neutron能夠成為統一的北向接口,也是源于Neutron的可擴展能力。
- EJB 3.1從入門到精通
- RCNP實驗指南:構建高級的路由互聯網絡(BARI)
- React:Cross-Platform Application Development with React Native
- Windows Server 2012 Hyper-V虛擬化管理實踐
- 網管工具使用與技巧大全
- 計算機網絡技術及應用
- Android UI Design
- 物聯網工程概論
- Microsoft Power Platform Enterprise Architecture
- Dart Cookbook
- Professional Scala
- Corona SDK Application Design
- 網絡互聯技術(理論篇)
- 網絡基本通信約束下的系統性能極限分析與設計
- 互聯網心理學:新心理與行為研究的興起