OpenStack云平臺中的網絡數據性能研究與優(yōu)化

徐啟后

（武漢郵電科學研究院湖北武漢430074）

進入新世紀以來，全球數據量的爆炸式增長，人們進入了一個信息爆炸的時代。每秒數以億萬計的數據在互聯網上不斷產生，如何獲取、存儲、管理、處理如此龐大的數據量成為了如今急需解決的問題[1-2]。為了解決這一問題，云計算被提出并寄予厚望。OpenStack作為當前解決云計算方案中最佳的開源項目，是全球各大公有云、私有云以及混合云提供商的首選云平臺[3]。但是由于x86服務器架構是一種通用服務器平臺，并非是專門針對OpenStack網絡服務，x86服務器提供的數據平面性能在面臨大量并發(fā)業(yè)務時捉襟見肘。同時現階段所使用的技術限制了OpenStack的網絡穩(wěn)定性、靈活性和虛擬網絡的吞吐量，制約了OpenStack云環(huán)境數據平面的傳輸能力，從而影響了OpenStack的進一步發(fā)展。因此需要引入更加先進和靈活的方法來解決上面提到的這些問題。

1 OpenStack及網絡組件Neutron簡介

OpenStack是由美國國家航空航天局（NASA）發(fā)起的開源軟件項目，它是以Apache授權的自由軟件和開源代碼的軟件開發(fā)項目[4]。OpenStack的社區(qū)現已發(fā)展成為由1 000多家公司和數以萬計的開發(fā)者協(xié)作提供代碼開發(fā)，版本升級的平臺。作為公有云和私有云的開源云計算平臺，OpenStack的主要任務是簡化云計算平臺的搭建過程和改善云數據中心的管理方式。

典型的OpenStack平臺組網圖如圖1所示。將OpenStack的組件——包含了計算服務Nova、網絡服務Neutron、鏡像服務Glance、身份認證服務Keystone、對象存儲服務Swift、用戶Web頁面服務Horizon等等組件分別部署在對應的節(jié)點上就組成一個簡單的云平臺。

圖1 典型的OpenStack平臺組網圖

Neutron作為OpenStack中的核心組件之一，是OpenStack社區(qū)的核心項目之一，提供云計算環(huán)境下的虛擬網絡功能[4-5]。在OpenStack云環(huán)境中的虛擬網絡也如同物理網絡一樣，將網絡、子網、端口、路由器等概念引入，組建一個虛擬網絡就是將這幾個基本概念有機的結合到一起。

圖2所示為在OpenStack云環(huán)境內部組成虛擬網絡的虛擬網絡設備的組網結構。從圖中可以看到虛擬網絡設備分為以下幾種：

1）內部端口：這是Linux中提供的虛擬接口設備，其中vnet設備是虛擬機的虛擬網卡設備，tap設備作為連接dhcp和Openvswitch虛擬交換機的接口設備，而qr/qg設備則連接Openvswitch虛擬交換機和qrouter命名空間[6-7]。

2）Openvswitch虛擬交換機：由Openvswitch軟件創(chuàng)建的虛擬交換機，其中虛擬交換機br-int用于實現租戶內的虛擬網絡，而網絡節(jié)點的br-ex用于實現外部網絡，br-eth用于實現租戶訪問外網和租戶之間相互訪問的數據通道，同時也是節(jié)點出口。

3）veth pair：qvbqvo和 int-br-ethphy-br-eth設備對都是連接兩個虛擬網橋的veth pair，相當于物理網絡中的一根網線[8]。

4）Linux bridge：這是一種功能相對簡單的虛擬網橋設備，通過訪問內核協(xié)議棧實現數據交換[9]。如圖2所示，qbr設備就是Linux bridge設備。

圖2 OpenStack云平臺虛擬網絡設備結構圖

針對虛擬機訪問不同的訪問對象，可以把虛擬機的數據包流向分為以下幾種：

1）虛擬機訪問同一計算節(jié)點同一租戶的虛擬機。虛擬機VM1發(fā)出的數據包是通過vnet1接口到qbrXXX這個linux bridge上的，而qbrXXX與br-int之間用qvbqvo這種veth pair來連接。在同一租戶中的數據包在br-int上會打上同一的vlan tag，而不同的租戶的數據包打上不同的vlan tag，這樣就實現了不同租戶的隔離。

2）在虛機訪問不同計算節(jié)點同一租戶的虛擬機時，虛擬機發(fā)出的數據包由于需要訪問的虛擬機不在同一個計算節(jié)點，數據包需要經過網絡節(jié)點之后來訪問另一個計算節(jié)點。因此，數據包從虛擬機發(fā)出，經過 br-int打上 vlan tag，在 br-eth上換上mod_vlan_id，然后從計算節(jié)點發(fā)送到網絡節(jié)點的breth上，然后從網絡節(jié)點發(fā)送到另外一個計算節(jié)點上，最終發(fā)到需要訪問的虛擬機上。

可以發(fā)現無論是訪問同一節(jié)點的還是不同節(jié)點的虛擬機，都需要虛擬機發(fā)出的數據包都需要經過依次經過Linux Bridge、Openvswitch、物理網卡等設備，提升這些設備的性能成為了優(yōu)化OpenStack網絡的關鍵。

2 OpenStack網絡性能瓶頸

從云平臺的整體來看，通過分析OpenStack云環(huán)境的網絡組成，可以將其分為兩個部分，一是由物理網絡設備組成的網絡，另一種是由軟件模擬的網絡設備組成的虛擬網絡。物理網絡的性能由物理設備——交換機、路由器等網絡設備的性能決定，是虛擬網絡的承載。物理網絡的性能可以通過選用更好性能的物理網絡設備，增加物理網絡設備的數量來提高。而OpenStack云平臺中網絡性能主要受制于虛擬網絡的性能瓶頸[10]。虛擬網絡設備的性能由虛擬軟件的性能和x86平臺的性能決定。OpenStack虛擬網絡主要由Openvswitch和Linux Bridge這兩個軟件生成的虛擬網絡設備組成。由Linux Bridge生成的網絡設備是用于安全組功能的qbr設備，每一個qbr設備連接一臺虛擬機，通過測試原生的Linux Bridge設備性能滿足一臺虛擬機的性能要求。而由Openvswitch生成的設備有用于實現租戶網絡的brint，有節(jié)點出口br-eth，還有外網出口br-ex。但是經過測試發(fā)現原生Openvswtich的包轉發(fā)率僅有0.75Mbps，由于在云平臺中有眾多虛擬機通過Openvswitch相連，Openvswitch的數據包轉發(fā)性能會直接影響整個云環(huán)境的網絡性能[11]。

從數據包在云平臺中的傳輸過程來看，云平臺的網絡性能由以下兩方面影響：一是數據包有從物理交換機到達物理網卡的過程；二是從物理網卡到虛擬機的過程。交換機到網卡的部分已經由物理網絡硬件解決，在此本文討論數據包從網卡到虛擬機的過程。一個數據包從網卡到達虛擬機的過程可以分為兩部分。第一，從網卡到虛擬交換機；第二，從虛擬交換機到虛擬機。

1）數據包從網卡到虛擬交換機。其實可以認為是從網卡到一個應用程序的過程。數據包到達網卡，網卡接收到電信號并將其轉化為數字信號存儲到網卡寄存器進入網卡收包隊列后，網卡會產生硬件中斷，發(fā)送中斷請求給CPU觸發(fā)CPU的中斷，進入中斷服務程序。然后需要由Openvswitch的內核態(tài)快速通路openvswitch.ko進行內核態(tài)的包處理，然后從內核態(tài)進入用戶態(tài)與抽象的網絡設備的交互，到達Openvswitch主進程ovs-vswitchd。數據包從網卡到達CPU寄存器是基于異步中斷信號模式的收包，是不斷的在做中斷處理，上下文切換，每次處理這種開銷是固定的，累加起來的負荷是非常明顯的。數據包從內核態(tài)openvswitch.ko到ovs-vswitchd需要從內核態(tài)切換到用戶態(tài)，這種切換伴隨這內存拷貝和上下文的切換[10，12]。

2）數據包從虛擬交換機到虛擬機。從性能和安全兩方面綜合考慮，虛擬機的I/O一般使用半虛擬化方案——virtio/virtio-net[10]。當虛擬機發(fā)送報文時，它會利用消息通知機制通知KVM（Kernel-based Virtual Machine），并退出到用戶空間Qemu進程，然后由Qemu開始對Tap設備進行讀寫。這個過程中，在數據通道從Tap設備到Qemu的報文拷貝和Qemu到虛擬機的報文拷貝，兩次報文拷貝導致報文發(fā)送上的性能瓶頸；在消息通知路徑上，當報文到達Tap設備時內核發(fā)送到Qemu通知消息，然后Qemu利用ioctl向KVM請求中斷，KVM發(fā)送中斷到虛擬機，這樣也會帶來不必要的性能開銷[11]。

當然數據包從虛擬機到達網卡的過程與以上過程是一個相反的類似過程，在此不在贅述。

3 OpenStack網絡優(yōu)化設計

首先，針對Openvswitch的數據包轉發(fā)性能問題，根據上一節(jié)中對Openvswitch的數據包轉發(fā)流程的分析，跟數據包轉發(fā)性能相關的主要有兩個組件：ovs-vswitch（用戶態(tài)慢速通道）和openvswitch.ko（內核態(tài)快速通道）。為了減少網卡在接收和發(fā)送數據包過程中的CPU的中斷次數，文中在云環(huán)境中使用高性能的向量化PMD（Poll-mode driver）代替異步中斷模式[13]。這樣在有大量的數據包需要發(fā)送或者接收的時候，會觸發(fā)一個收包或者發(fā)包中斷，喚醒應用程序的收發(fā)包進程，應用程序進行輪詢收發(fā)包，這樣CPU在有大量數據包需要處理的時候不會收到中斷信號，同時也不會讓輪詢收發(fā)包進程一直占用CPU。為了減少Openvswitch轉發(fā)過程中內核態(tài)和用戶態(tài)之間切換，如圖3所示文中給出了一種數據包不經過內核態(tài)openvswitch.ko處理直接到達用戶態(tài)的方式。通過向量指令將使得vSwitch netdev可以在用戶態(tài)訪問數據包所存儲的內存地址，同時通過dpif和dpif-netdev實現用戶態(tài)的快速數據通路。

圖3 優(yōu)化后Openvswitch的數據通道

其次，針對虛擬交換機到虛擬機的兩次拷貝和一次用戶態(tài)和內核態(tài)的切換所帶來的性能損耗，文中采用vhost-user方式實現優(yōu)化。vhost的庫實現了以下特性：

1）實現了一種用戶態(tài)中的vhost-backend，使得數據包從虛擬機到后端驅動不需要切換CPU特權等級。

2）實現了對virtio網絡設備的管理，包括virtionet設備的創(chuàng)建和銷毀[14]；

3）通過IVSHMEM將宿主機內存和虛擬機共享，將虛擬機的物理地址映射到vhost-user的地址空間，實現了數據包從虛擬機到后端驅動的零內存拷貝[15]；

4）通過eventfd接收來自虛擬機的接收報文消息通知vhost接收來自虛擬機的報文，同時通過eventfd通知虛擬機接收報文；

圖4 使用vhost-user后虛擬機到網卡結構圖

如圖4所示是使用vhost-user后虛擬機到網卡的結構圖。圖中當虛擬機發(fā)送數據包時，數據包經由virtio driver的兩個虛擬隊列——tx發(fā)送。tx將數據包發(fā)送給用戶態(tài)中的vhost，同時virtio driver通過eventfd通知vhost接收數據包。由于虛擬機的物理地址映射到了vhost的地址空間，因此virtio只需要通過eventfd將數據包所在內存地址告訴vhost，這樣vhost就可以通過地址偏移計算出數據包所在虛擬機物理地址[13]。當虛擬機從Openvswitch接收數據包時，數據包會被存儲到vhost的地址空間，同時vhost通過eventfd發(fā)送通知消息給virtio driver讓其接收報文，并告知virtio driver數據包所在地址空間。由于虛擬機的地址空間和vhost地址空間是共享的，這樣virtio driver只需要找到對應的地址就可以使得虛擬機接收到數據包。

圖5 優(yōu)化后虛擬網絡結構圖

經過以上方法優(yōu)化后，一臺虛擬機在OpenStack云平臺中的虛擬網絡如圖5所示。虛擬機通過vhost-user接口連接到虛擬交換機上，由于沒有了linux bridge簡化了虛擬網絡的結構，但是也同時無法使用內核態(tài)的iptables實現安全組功能，因此需要使用安全組的另一種實現方式，Openflow流表實現。因此在OpenStack的配置文件需要加入以Open?vswitch為驅動的firewall_driver。

4 測試方案與結果分析

文中的測試是通過對比原生的OpenStack和優(yōu)化后OpenStack的二層/三層轉發(fā)性能得出測試結論。測試方案如圖6所示，在測試優(yōu)化后的轉發(fā)能力測試中，將一臺服務器1作為轉發(fā)服務器，一臺服務器2作為測試服務器。其中轉發(fā)服務器作為OpenStack中的計算節(jié)點，在上面創(chuàng)建一臺虛擬機，并在虛擬機上安裝L2/L3轉發(fā)程序：dpdk_l2_forwarding和dpdk_l3_forwarding。圖6中服務器2通過DPDK Pktgen程序從eth0網卡發(fā)送數據包，通過服務器2和服務器1之間的網線發(fā)送到Openvswitch+這個虛擬交換機上，并通過修改Openvswitch上的流表規(guī)則將發(fā)送到服務器1的eth0網卡上的數據包都發(fā)送給vhost-user1這個接口，數據包通過虛擬機的virtio接口將數據包交給虛擬機中的L2/L3 Forwarding程序處理，通過配置L2/L3 Forwarding程序將數據包由vhost-user2這個接口發(fā)送出虛擬機，最終發(fā)送回DPDK Pktgen程序，并由其進行測量[16]。在測試過程中，原生的OpenStack在二層/三層轉發(fā)測試的過程中發(fā)現在小包的處理上有明顯的丟包現象，而由于使用大頁內存技術和輪詢技術，極大的提高了虛擬交換機收包的能力，使得在優(yōu)化后的測試中沒有出現丟包現象。同時通過如圖7和8所示優(yōu)化后性能是原生OpenStack的6～7倍。

圖6 優(yōu)化后二層/三層轉發(fā)測試模型圖

圖7 二層轉發(fā)測試數據

圖8 三層轉發(fā)測試數據

5 結束語

文中首先對OpenStack云平臺及其網絡組件Neutron進行了研究，并通過研究影響Nuetron虛擬網絡的因素，發(fā)現通過減少中斷處理、內存拷貝、系統(tǒng)調用和協(xié)議處理的開銷可以優(yōu)化OpenStack的虛擬網絡的性能。通過優(yōu)化網卡數據包到達Open?vswitch的途徑和引入vhost-user接口提升了Open?Stack數據網絡中二層和三層的轉發(fā)性能。經過測試，OpenStack環(huán)境優(yōu)化后可以將二層和三層轉發(fā)性能提高6-7倍，大大改善了OpenStack的網絡性能。

參考文獻:

[1]劉輝邦，羅萱，黃保青，等.云計算中虛擬網絡服務的性能測量及運營實踐[C]//中國高等教育學會教育信息化分會第十二次學術年會論文集，2014.

[2]王喜文.試析中國云計算產業(yè)的發(fā)展路徑[J].物聯網技術，2014（3）:4-5.

[3]張麗梅.基于負載均衡的云資源調度策略研究[D].銀川：寧夏大學，2014.

[4]陳陶，顧雙雙，柳鈕滔，等.基于OpenStack Juno版的私有云平臺部署及實踐[J].物聯網技術，2015（6）:64-67.

[5]張華，向輝，劉艷凱.深入淺出Neutron:OpenStack網絡技術[M].北京：清華大學出版社，2015.

[6]李莉，李紀成，張超然，等.基于OpenStack云平臺Neutron關鍵技術研究[J].長春理工大學學報自然科學版，2015，38（6）:114-117.

[7]俞淑妍.基于OpenFlow的軟件定義網絡緩存加速系統(tǒng)的研究與實現[D].北京：北京郵電大學，2014.

[8]D Zhou，B Fan，H Lim，et al.Scalable，High Perfor?mance Ethernet Forwarding with CuckooSwitch[C].Proceedings of the 2013 ACM International Confer?ence on Emerging Networking Experiments and Technologies，USA，2013:97-108.

[9]Rizzo L，Carbone M，Catalli G.Transparent accel?eration of software packet forwarding using netmap[C]//INFOCOM，2012 Proceedings IEEE.IEEE，2012:2471-2479.

[10]Paolino M， Nikolaev N， Fanguede J， et al.SnabbSwitch user space virtual switch benchmark and performance optimization for NFV[C]//Net?work Function Virtualization and Software Defined Network.IEEE，2016:86-92.

[11]Koka P，Mccracken M O，Schwetman H D，et al.Combining a remote TLB lookup and a subsequent cache miss into a single coherence operation:US，US9003163[P].2015.

[12]Casoni M，Grazia C A，Patriciello N.On the perfor?mance of Linux Container with Netmap/VALE for networks virtualization[C]//2013 19th IEEE Inter?nationalConferenceonNetworks（ICON）.2013:1-6.

[13]朱河清.深入淺出DPDK[M].北京：機械工業(yè)出版社，2016.

[14]劉萌萌.基于SDN的全網路由虛擬化組件的研究與實現[D].北京：北京郵電大學，2015.

[15]Patni S，George J，Lahoti P，et al.A zero-copy fast channel for inter-guest and guest-host commu?nication using VirtIO-serial[C]//International Con?ference on Next Generation Computing Technolo?gies.IEEE，2015:6-9.

[16]劉志聰，李秦偉，王勝俊.OpenStack云平臺Neu?tron的研究與測試[J].自動化與儀器儀表，2015（6）:85-87.