涂俊亮，陳 偉

（中國電子科技集團(tuán)公司第三十研究所，四川 成都 610041）

0 引言

當(dāng)前，云服務(wù)商大多采用虛擬交換機(jī)來管理、隔離不同租戶間的通信[1]，應(yīng)用最廣泛的是Nicira公司的開源虛擬交換機(jī)（Open vSwitch，OVS）項(xiàng)目[2]。OVS 具備基礎(chǔ)的網(wǎng)絡(luò)隔離和報(bào)文轉(zhuǎn)發(fā)功能，但在大網(wǎng)絡(luò)流量下存在性能瓶頸。OVS 對報(bào)文的接收、處理主要在內(nèi)核態(tài)進(jìn)行，操作過程中內(nèi)存會多次移動或拷貝報(bào)文，浪費(fèi)內(nèi)核資源，導(dǎo)致轉(zhuǎn)發(fā)效率低下。此外，OVS 組網(wǎng)時(shí)，多容器（docker）的網(wǎng)絡(luò)并發(fā)性能不佳，帶寬分配不均勻。因此原生OVS 難以滿足大規(guī)模云平臺對網(wǎng)絡(luò)邊緣設(shè)備的性能需求。

英特爾公司推出的數(shù)據(jù)平面開發(fā)包（Intel Data Plane Development Kit，DPDK）[3]為用戶態(tài)快速處理數(shù)據(jù)包提供了豐富的庫函數(shù)和靈活的驅(qū)動支撐。DPDK 結(jié)合OVS 后，性能變得高效且方便開發(fā)，但直接部署還存在一些困難，如環(huán)境相關(guān)性高，運(yùn)維困難，且對傳輸控制協(xié)議（Transmission Control Protocol，TCP）分片卸載的支持度不高。TCP 大包需要先分片變小后才能被送至網(wǎng)卡，導(dǎo)致虛擬機(jī)負(fù)載加劇，網(wǎng)絡(luò)傳輸性能降低[4]。有研究表明，將OVS-DPDK 部署在docker[5]環(huán)境中會明顯改善性能，因?yàn)樵谌萜髦?，OVS 共享宿主機(jī)文件系統(tǒng)，宿主機(jī)和虛擬機(jī)間的連接采用OVS-DPDK 的橋接端口，從而無須通過物理網(wǎng)卡，TCP 分片卸載問題也不復(fù)存在。因此，本文選擇在docker 環(huán)境下研究OVSDPDK 提升網(wǎng)絡(luò)性能的效果。

本文首先介紹OVS 和DPDK 的原理及核心技術(shù)；其次針對實(shí)驗(yàn)瓶頸，利用二者聯(lián)合部署解決；最后，從3 層轉(zhuǎn)發(fā)、應(yīng)用層傳輸兩方面進(jìn)行測試，研究OVS+DPDK 在生產(chǎn)環(huán)境中的優(yōu)缺點(diǎn)及優(yōu)化方向。

1 OVS 簡介

1.1 OVS 結(jié)構(gòu)

OVS 由核心組件ovs-vswitchd、數(shù)據(jù)庫組件ovsdb-server、內(nèi)核模塊openvswitch.ko 3大要素構(gòu)成，結(jié)構(gòu)如圖1 所示。

圖1 OVS 內(nèi)部組成

ovs-vswitchd 是OVS 的核心模塊，在用戶空間運(yùn)行，負(fù)責(zé)地址學(xué)習(xí)、物理端口綁定、邏輯轉(zhuǎn)發(fā)等基本功能。可利用OVS 自帶的工具ovs-ofctl，基于openflow 協(xié)議進(jìn)行交換機(jī)配置管理。

ovsdb-server 是存儲OVS 配置、狀態(tài)和日志等信息的輕量級數(shù)據(jù)庫服務(wù)，ovsdb 是一個(gè)可持久化的數(shù)據(jù)庫，交換機(jī)的配置信息均保存在其中，即使設(shè)備掉電也不會丟失。ovsdb-server 與ovs-vswitchd間采用OVS 數(shù)據(jù)庫（OVS Data Base，OVSDB）管理協(xié)議通信，其內(nèi)容包含但不限于配置信息加載、運(yùn)行過程中變化的OVS 相關(guān)信息。

openvswitch.ko 組件作為快速轉(zhuǎn)發(fā)平面運(yùn)行在內(nèi)核空間，實(shí)現(xiàn)修改報(bào)文、匹配流表、封裝隧道、維護(hù)轉(zhuǎn)發(fā)表等功能。在OVS 中，報(bào)文先經(jīng)該組件封裝或解析，然后進(jìn)行轉(zhuǎn)發(fā)規(guī)則匹配，匹配成功則直接轉(zhuǎn)發(fā)，否則轉(zhuǎn)交給用戶空間的ovs-vswitchd 組件處理。它與ovs-vswitchd 采用NetLink 協(xié)議規(guī)范進(jìn)行內(nèi)核態(tài)和用戶態(tài)進(jìn)程間的通信。

1.2 OVS 網(wǎng)絡(luò)應(yīng)用

OVS 以軟件形態(tài)存在于虛擬網(wǎng)絡(luò)中，角色類似于物理交換機(jī)，具有局域網(wǎng)劃分、隧道搭建、路由模擬3 大功能，其典型網(wǎng)絡(luò)應(yīng)用如圖2 所示。圖中虛擬交換機(jī)OVS0 是中心交換機(jī)，作為網(wǎng)絡(luò)中心連接OVS1、OVS2、OVS3、OVS4 這4 個(gè)邊緣交換機(jī)。邊緣交換機(jī)與虛擬機(jī)直連，負(fù)責(zé)同網(wǎng)絡(luò)的虛擬機(jī)間通信和跨網(wǎng)絡(luò)的虛擬機(jī)間包轉(zhuǎn)發(fā)。

1.2.1 局域網(wǎng)劃分

通過劃分虛擬局域網(wǎng)（Virtual Local Area Network，VLAN），可以實(shí)現(xiàn)同網(wǎng)絡(luò)的虛擬機(jī)間局域網(wǎng)隔離。通過給中心交換機(jī)端口配置不同的VLAN 號，使邊緣OVS 屬于不同VLAN，隔斷邊緣OVS 間二層通信，實(shí)現(xiàn)跨網(wǎng)絡(luò)的虛擬機(jī)間局域網(wǎng)隔離。本文便是利用該功能實(shí)現(xiàn)docker 間網(wǎng)絡(luò)隔離。

1.2.2 隧道搭建

邊緣OVS 可搭建隧道。在虛擬擴(kuò)展局域網(wǎng)（Virtual Extensible Local Area Network，VXLAN）隧道應(yīng)用中，OVS 能實(shí)現(xiàn)其中的由虛擬網(wǎng)段隧道終結(jié)點(diǎn)（VXLAN Tunnel End Point，VTEP）負(fù)責(zé)的VXLAN 報(bào)文解析封裝、轉(zhuǎn)發(fā)、地址學(xué)習(xí)等功能[6]。

1.2.3 路由模擬

OVS 結(jié)合控制器可模擬路由轉(zhuǎn)發(fā)功能，實(shí)現(xiàn)在不同局域網(wǎng)中主機(jī)的數(shù)據(jù)轉(zhuǎn)發(fā)。圖2 中虛擬機(jī)B和F 所直連的邊緣OVS（OVS1 和OVS3）屬于兩個(gè)局域網(wǎng)，不能進(jìn)行二層轉(zhuǎn)發(fā)。配合控制器，首先，將局域網(wǎng)中的地址解析協(xié)議（Adress Resolution Protocol，ARP）報(bào)文上報(bào)到控制端；其次，控制端感知OpenFlow中網(wǎng)絡(luò)節(jié)點(diǎn)，獲得所有設(shè)備網(wǎng)絡(luò)信息；最后，將對應(yīng)ARP 流表下發(fā)到OVS 上，有了流表信息，不同局域網(wǎng)的主機(jī)B 和F 便可通信。

圖2 OVS 在網(wǎng)絡(luò)中的應(yīng)用

1.3 OVS 與網(wǎng)橋?qū)Ρ?/h3>

相較于網(wǎng)橋（Linux-Bridge），OVS 圖形化工具更方便管理員對云環(huán)境中的網(wǎng)絡(luò)狀態(tài)、數(shù)據(jù)流量等信息進(jìn)行監(jiān)管。相比網(wǎng)橋單純基于媒體訪問控制（Media Access Control，MAC）地址學(xué)習(xí)的轉(zhuǎn)發(fā)規(guī)則，OVS 引入流緩存機(jī)制，可提高數(shù)據(jù)包轉(zhuǎn)發(fā)效率。網(wǎng)橋僅支持通用路由封裝隧道，OVS 則支持更多的隧道協(xié)議，如VXLAN、互聯(lián)網(wǎng)安全協(xié)議（Internet Protocol Security，IPsec）。此外，OVS 作為軟件定義網(wǎng)絡(luò)（Software Defined Network，SDN）生態(tài)的一部分，其擴(kuò)展性更高和應(yīng)用范圍更廣。

OVS 也存在局限，其穩(wěn)定性和可靠性不及網(wǎng)橋，其復(fù)雜的內(nèi)部結(jié)構(gòu)導(dǎo)致OVS 安裝復(fù)雜、運(yùn)維困難，并且OVS 與操作系統(tǒng)的集成友好度也不如網(wǎng)橋。

2 Intel DPDK 簡介

2.1 DPDK 特點(diǎn)

DPDK 的設(shè)計(jì)理念是基于通用服務(wù)器，采用軟件方式優(yōu)化，以代替原用于網(wǎng)絡(luò)設(shè)備的專用網(wǎng)絡(luò)處理器。經(jīng)過多次適配迭代，DPDK 目前已支持x86、精簡指令集機(jī)器（Advanced RISC Machine，ARM）、無內(nèi)部互鎖流水級的微處理器（Microprocessor without Interlocked Piped Stages，MIPS）等架構(gòu)，應(yīng)用廣泛[7]。DPDK 的主要技術(shù)特點(diǎn)有：

（1）用戶態(tài)輸入/ 輸出（Userspace Input/Output，UIO），直接在用戶態(tài)實(shí)現(xiàn)網(wǎng)卡I/O，實(shí)現(xiàn)零拷貝數(shù)據(jù)。

（2）CPU 預(yù)分配、并行處理，內(nèi)存無須多次申請和釋放，緩存高效工作，包時(shí)延銳減。

（3）CPU 和程序親和性關(guān)聯(lián)。把不同CPU 核與控制面及數(shù)據(jù)面線程綁定，減少核間切換，并調(diào)度熱點(diǎn)代碼段一直處于高速緩存中。

（4）無鎖（LOCKLESS）環(huán)形緩存管理，去掉鎖開銷。

（5）內(nèi)存大頁方案，增大程序基礎(chǔ)內(nèi)存塊容量，提高緩存命中和訪問內(nèi)存效率。

（6）輪詢驅(qū)動（Poll Mode Driver，PMD）。用戶態(tài)輪詢，減少中斷沉睡喚醒、上下文切換開銷。

2.2 DPDK 架構(gòu)

DPDK 是由在用戶空間運(yùn)行的數(shù)據(jù)處理、訪問底層硬件資源與內(nèi)核通信等接口庫組成的集合，其內(nèi)部結(jié)構(gòu)如圖3 所示。

圖3 DPDK 庫結(jié)構(gòu)

樣例App、用戶App和獨(dú)立軟件開發(fā)商（Independent Software Vendors，ISV）系統(tǒng)App 作為應(yīng)用運(yùn)行在頂層。中層是各種庫函數(shù)，其中核心庫提供內(nèi)存池、無鎖環(huán)和大頁內(nèi)存等基礎(chǔ)功能；擴(kuò)展庫函數(shù)提供擴(kuò)展功能，如定時(shí)器；PMD 庫匹配原生和虛擬網(wǎng)卡，通過輪詢、線程綁定等技術(shù)獲得網(wǎng)卡高速轉(zhuǎn)發(fā)性能；Classify 支持如前綴最長匹配、通配符匹配的查表操作；QoS 庫提供網(wǎng)口限速、流控和調(diào)度等功能。底層的內(nèi)核網(wǎng)卡接口（Kernel NIC Interface，KNI）、虛擬功能輸入輸出（Virtual Function I/O，VFIO）等技術(shù)將I/O、直接存儲器訪問（Direct Memory Access，DMA）、中斷等內(nèi)核功能安全有效地向上提供給用戶空間調(diào)用，并支持將報(bào)文向下注入內(nèi)核協(xié)議棧。

2.3 DPDK 關(guān)鍵技術(shù)

本文的性能提升主要涉及UIO、內(nèi)核網(wǎng)卡接口（Kernel NIC Interface，KNI）、PMD 技術(shù)，具體如下文所述。

2.3.1 UIO 技術(shù)

UIO 用戶空間I/O 技術(shù)是指把內(nèi)核中的大部分I/O 功能遷移至用戶態(tài)完成，即繞過內(nèi)核協(xié)議棧，直接從網(wǎng)卡收發(fā)數(shù)據(jù)包，減少內(nèi)核資源消耗，其工作原理如圖4 所示。

圖4 UIO 技術(shù)工作原理

設(shè)備驅(qū)動由內(nèi)核空間驅(qū)動和用戶空間驅(qū)動組成，內(nèi)核空間只負(fù)責(zé)UIO 設(shè)備注冊、資源分配及少部分中斷，其余大部分驅(qū)動工作在用戶空間中完成。利用接口將UIO 驅(qū)動注冊到內(nèi)核后，會生成一個(gè)含有設(shè)備物理地址信息的地圖文件，用戶進(jìn)程讀取此文件，將內(nèi)核空間地址映射到用戶空間。操作用戶空間便等同于直接映射操作其內(nèi)存空間，以此避免數(shù)據(jù)在內(nèi)核緩沖區(qū)和應(yīng)用程序緩沖區(qū)的多次拷貝。

2.3.2 KNI 組件

KNI 組件能將數(shù)據(jù)重入內(nèi)核協(xié)議棧，高效利用傳統(tǒng)內(nèi)核協(xié)議棧已有的成熟功能。DPDK 對包的處理旁路了內(nèi)核，若在用戶空間構(gòu)建一套新的完整獨(dú)立的協(xié)議棧是很復(fù)雜的；因此，可以在用戶空間實(shí)現(xiàn)某些特殊的協(xié)議功能，再利用KNI 重載進(jìn)入內(nèi)核，而常用的普通協(xié)議無須重復(fù)造輪。KNI 通信機(jī)制如圖5 所示。

圖5 KNI 通信機(jī)制

虛擬網(wǎng)卡上的KNI 虛擬接口是用戶空間和內(nèi)核協(xié)議棧間通信的橋梁。網(wǎng)卡收到的數(shù)據(jù)包通過應(yīng)用程序轉(zhuǎn)發(fā)到用戶空間，再通過KNI 虛擬接口到達(dá)內(nèi)核協(xié)議棧進(jìn)行處理，處理后若有響應(yīng)報(bào)文，則再交由KNI 虛擬接口返回給應(yīng)用程序。通信中的發(fā)送線程及接收線程，由兩個(gè)邏輯核（如圖5 所示CoreA0和CoreB0）獨(dú)立處理，從而達(dá)到互不阻塞、提高效率的目的。

2.3.3 PMD 輪詢

PMD 提供了一系列高優(yōu)先級的配置設(shè)備、隊(duì)列的接口，還能以屏蔽中斷的形式訪問、發(fā)送和接收描述符，因此用戶態(tài)應(yīng)用可以實(shí)時(shí)地收發(fā)包，甚至以最高優(yōu)先級處理包。通過PMD 的輪詢機(jī)制從網(wǎng)卡收包，屏蔽了中斷，提高了大流量下的實(shí)時(shí)效率。顯然這也導(dǎo)致CPU 核的占用率一直很高，不夠節(jié)能，且不能直觀看到CPU 負(fù)載狀況。

3 實(shí)驗(yàn)環(huán)境和改進(jìn)方案

3.1 實(shí)驗(yàn)環(huán)境介紹

在萬兆服務(wù)器上創(chuàng)建多個(gè)虛擬機(jī)（docker），提供租戶隔離的云服務(wù)，每個(gè)docker 上運(yùn)行業(yè)務(wù)服務(wù)端程序，期望在高并發(fā)下獲得高效的網(wǎng)卡性能。網(wǎng)橋部署下的實(shí)驗(yàn)場景如圖6 所示，實(shí)驗(yàn)環(huán)境相關(guān)信息如表1 所示。

圖6 網(wǎng)橋部署下的實(shí)驗(yàn)環(huán)境

表1 實(shí)驗(yàn)環(huán)境信息

測試端n個(gè)用戶t1～tn通過運(yùn)行業(yè)務(wù)客戶端程序，訪問對應(yīng)的虛擬機(jī)docker-0～docker-N。虛擬機(jī)配置雙網(wǎng)卡，分別橋接到服務(wù)器的bridge-0和bridge-1，兩個(gè)橋分別綁定在實(shí)際網(wǎng)卡Net-0 和Net-1 上，網(wǎng)絡(luò)包從一個(gè)網(wǎng)口進(jìn)入虛擬機(jī)，從另一個(gè)網(wǎng)口返回客戶端。為充分測試性能，客戶端上業(yè)務(wù)程序均是多線程滿負(fù)載并發(fā)執(zhí)行，統(tǒng)計(jì)此情況下隨著測試客戶端的增加，物理網(wǎng)卡Net 上的總帶寬和服務(wù)器的CPU 占用率。實(shí)驗(yàn)數(shù)據(jù)如圖7 所示。

圖7 不同docker 數(shù)時(shí)帶寬和CPU 占用率

由圖7可知，采用橋接模式時(shí)，隨著docker增加，CPU 占用率逐漸增大，總網(wǎng)卡帶寬在docker 為5 時(shí)達(dá)到峰值8.9，隨后呈現(xiàn)下降趨勢，無法達(dá)到萬兆標(biāo)稱值，且單個(gè)docker 的帶寬分配也不均勻，存在隨機(jī)性。此外隨著docker 增加，服務(wù)器上線程呈倍數(shù)級上漲，中斷過多，任務(wù)切換開銷大，內(nèi)核負(fù)載增加，然而實(shí)驗(yàn)中發(fā)現(xiàn)內(nèi)存使用并未顯著增加；因此，當(dāng)前瓶頸主要在CPU。基于DPDK 網(wǎng)絡(luò)性能優(yōu)勢，考慮采用OVS-DPDK 組網(wǎng)。

3.2 OVS-DPDK 改進(jìn)方案

本文設(shè)計(jì)的OVS-DPDK 架構(gòu)如圖8 所示。系統(tǒng)自下而上由OVS 內(nèi)核態(tài)進(jìn)程、DPDK 平臺管理層、用戶空間協(xié)議棧、OVS 用戶空間核心進(jìn)程共4 個(gè)模塊組成。OVS 內(nèi)核進(jìn)程負(fù)責(zé)內(nèi)核態(tài)報(bào)文轉(zhuǎn)發(fā)和流表匹配。OVS 用戶空間的核心進(jìn)程負(fù)責(zé)用戶態(tài)包傳遞，將報(bào)文傳入用戶空間協(xié)議棧，然后根據(jù)用戶態(tài)流表匹配返回的結(jié)果進(jìn)行相應(yīng)處置（轉(zhuǎn)發(fā)或丟棄）。用戶空間協(xié)議棧則按各層協(xié)議進(jìn)行封裝或解析。

改進(jìn)重點(diǎn)在于加入了DPDK 平臺管理層，承上啟下，對上層模塊屏蔽底層硬件資源，并通過對上層提供接口實(shí)現(xiàn)對底層資源如內(nèi)存、網(wǎng)卡、緩存等的管理。

如圖8 所示，圖中標(biāo)注“1”“2”“3”的位置代表主要模塊間的交互。

圖8 基于DPDK 平臺的OVS 架構(gòu)

“1”表示數(shù)據(jù)收發(fā)管理線程和用戶空間協(xié)議棧交互，涉及包發(fā)送或接收，報(bào)文按協(xié)議封裝或解析。“2”中用戶空間協(xié)議棧處理報(bào)文時(shí)，向網(wǎng)絡(luò)緩存管理模塊申請報(bào)文緩存區(qū)，用完后立刻釋放，提高內(nèi)存使用率?！?”中數(shù)據(jù)收發(fā)管理線程和流表匹配模塊交互，依據(jù)報(bào)文頭匹配結(jié)果進(jìn)行相應(yīng)的返回操作，本文設(shè)計(jì)流表能加快包在用戶態(tài)轉(zhuǎn)發(fā)，且旁路內(nèi)核。

本文所提OVS-DPDK 架構(gòu)與原生OVS 的區(qū)別在于，OVS-DPDK 架構(gòu)指定CPU 核，通過OVS 配置的端口收到數(shù)據(jù)包，報(bào)文跳過內(nèi)核態(tài)openvswitch.ko 操作，經(jīng)DPDK 輪詢機(jī)制直接實(shí)時(shí)送達(dá)用戶態(tài)ovs-vswitchd 里處理。原生OVS 和OVS-DPDK 包交換對比如表2 所示。

表2 原生OVS 和OVS-DPDK 的比較

4 OVS-DPDK 配置

本文實(shí)驗(yàn)中使用到的關(guān)鍵軟件版本為OVS(v2.8.0)+DPDK(v16.11)，OVS-DPDK 環(huán)境安裝和配置過程簡述如下：

（1）相關(guān)編譯環(huán)境、依賴庫安裝，包括但不限于gcc、libpcap、libnet 等。

（2）確定網(wǎng)卡型號是否支持DPDK，腳本為：lspci -nn |grep Ethernet #得到網(wǎng)卡類型為“xxx”進(jìn)入dpdk目錄，grep --include=*.h -rn -e ‘xxx’

（3）編譯安裝OVS 和DPDK。

（4）操作系統(tǒng)配置：

①系統(tǒng)BIOS 需打開VT-d，并通過grub 配置iommu 和intel_iommu 參數(shù)來支持VFIO 驅(qū)動；

②配置大頁，系統(tǒng)每個(gè)page 默認(rèn)占2 MB，本文配置1 000 個(gè)大頁，大頁共占用2 GB 內(nèi)存。

（5）設(shè)置dpdk 驅(qū)動，腳本為：

modprobe vfio-pci #加載dpdk 驅(qū)動

網(wǎng)卡綁定到dpdk dpdk-devbind --bind=vfio-pci enp4s0f1（網(wǎng)卡名）

（6）啟動OVS 進(jìn)程。

（7）初始化DPDK，開啟DPDK 功能。從ovs-v2.7.0 開始，不能通過vswitchd 進(jìn)程啟動時(shí)指定DPDK 等參數(shù)開啟DPDK 功能，需通過設(shè)置ovsdb 來實(shí)現(xiàn)。主要配置3 個(gè)參數(shù)，具體如下：

ovs-vsctl --no-wait set Open_vSwitch .other_config:dpdk-init=true #設(shè)置dpdk 初始化啟動

ovs-vsctl --no-wait set Open_vSwitch .other_config:dpdk-socket-mem=”2056,0” #指定的sockets 從大頁預(yù)先分配的內(nèi)存，大小為2 GB

ovs-vsctl set Open_vSwitch .other_config:pmdcpu-mask=0x02 #指定在某些core 上運(yùn)行，該命令表示在02 號核上運(yùn)行

（8）配置OVS，主要有創(chuàng)建OVS 網(wǎng)橋、網(wǎng)橋上新增DPDK 端口、配置模式，連接控制器、新增流表等。本文使用vhostuser 方式配置，主要腳本摘錄如下：

創(chuàng)建兩個(gè)dpdk 的虛擬橋

ovs-vsctl add-br br0 --set bridge br0 datapath_type=netdev

通過mac 地址接管網(wǎng)卡，并加入到br0 中

ovs-vsctl add-port br0 dpdk0 --set Interface dpdk0 type=dpdk options:dpdk-devargs=0000:04:00.1

使用vhostuser 配置

ovs-vsctl add-port br0 vnic0 --set Interface vnic0 type=dpdkvhostuserclient options:vhost-server-path=/tmp/dpdkvhostclient0

（9）創(chuàng)建docker，配置其網(wǎng)絡(luò)，進(jìn)行實(shí)驗(yàn)。

5 測試和分析

5.1 OVS-DPDK 的3 層轉(zhuǎn)發(fā)能力測試分析

本文主要使用OVS_DPDK 的3 層轉(zhuǎn)發(fā)能力，先使用DPDK 自帶的收發(fā)包測試工具進(jìn)行3 層轉(zhuǎn)發(fā)測試。OVS+DPDK 3層轉(zhuǎn)發(fā)測試平臺拓?fù)淙鐖D9所示。

如圖9 所示，服務(wù)器1 作轉(zhuǎn)發(fā)服務(wù)器，服務(wù)器2 作測試服務(wù)器。在服務(wù)器1 上安裝OVS+DPDK，創(chuàng)建并啟動虛擬機(jī)，配置vhost-user 接口模式，并與虛擬機(jī)網(wǎng)口對應(yīng)綁定連接到虛擬交換機(jī)上。虛擬機(jī)中安裝DPDK 自帶的3 層轉(zhuǎn)發(fā)應(yīng)用程序DPDK L3 Forwarding，它能實(shí)現(xiàn)3 層IP 間的包轉(zhuǎn)發(fā)。修改OVS 流表規(guī)則配置，將eth0 上的包轉(zhuǎn)到Vhostuser1 口，L3 Forwarding 可配置兩個(gè)虛擬網(wǎng)卡的IP分別為192.168.1.1 和192.168.1.2。服務(wù)器2 上安裝收發(fā)測試應(yīng)用程序Pktgen。測試過程中數(shù)據(jù)包的流向：服務(wù)器2 PDK Pktgen—eth0 —Vhost-user1—virtio—L3 Forwarding—virtio—Vhost-user2—eth1—服務(wù)器2 DPDK Pktgen。閉環(huán)返回到Pktgen 應(yīng)用程序中，并由其度量性能。

圖9 OVS+DPDK 的3 層轉(zhuǎn)發(fā)能力測試拓?fù)?/p>

測試轉(zhuǎn)發(fā)大小遞增的數(shù)據(jù)包，轉(zhuǎn)發(fā)性能統(tǒng)計(jì)數(shù)據(jù)如表3 所示。

表3 不同大小包下3 層轉(zhuǎn)發(fā)性能統(tǒng)計(jì)

測試結(jié)果表明，在3 層包的處理上，OVS+DPDK 比OVS+linux kernel 有明顯性能提升。原生OVS 在小包轉(zhuǎn)發(fā)時(shí)出現(xiàn)丟包現(xiàn)象，而OVS+DPDK在測試中未出現(xiàn)該現(xiàn)象，這得益于PMD 和大頁內(nèi)存的使用，提高了OVS 的收包能力。OVS 結(jié)合DPDK 后在3 層轉(zhuǎn)發(fā)性能上是原生OVS 的4～7倍，當(dāng)包大小為256 byte 時(shí)，性能提升最明顯，且OVS+DPDK 可避免小包丟包現(xiàn)象。

5.2 OVS-DPDK 的應(yīng)用層面能力測試分析

基于以上理想狀態(tài)下的測試結(jié)果，在實(shí)際業(yè)務(wù)應(yīng)用層面上進(jìn)行性能測試，實(shí)驗(yàn)網(wǎng)絡(luò)拓?fù)鋮⒖紙D7配置，將linux-bridge 模式換成OVS+DPDK 部署，使用單CPU 雙核心模式，進(jìn)行業(yè)務(wù)并發(fā)測試，結(jié)果如表4 所示。

表4 不同配置下的網(wǎng)絡(luò)性能測試統(tǒng)計(jì)

數(shù)據(jù)繪制在雙坐標(biāo)軸中如圖10 所示。使用OVS-DPDK 在容器數(shù)量從1 增加到10 的過程中，總帶寬比較平穩(wěn)，在9 GB 左右，網(wǎng)卡基本滿載，CPU 的變化曲線相較網(wǎng)橋也更平穩(wěn)，在docker 數(shù)量較少時(shí)，能高效利用CPU 性能，帶寬利用也比普通橋接高8%～10%。docker 數(shù)量為10 時(shí)，OVSDPDK 帶寬是網(wǎng)橋的1.3 倍，可以看出在容器數(shù)量增多的情況下，OVS-DPDK 的網(wǎng)卡利用性能更充分。OVS-DPDK 的CPU 占用率一直比普通橋接高，也印證了上文2.3.3 節(jié)中，CPU 核心的占用率會一直很高、不夠節(jié)能的觀點(diǎn)。

圖10 OVS+DPDK 和linux_bridge 網(wǎng)絡(luò)性能對比

給OVS 分配2 個(gè)CPU、4 個(gè)處理器邏輯核心后，OVS-DPDK 帶寬測試結(jié)果可達(dá)到網(wǎng)橋的1.86 倍，但將核心繼續(xù)增加到8 個(gè)和16 個(gè)時(shí)，OVS-DPDK帶寬測試結(jié)果并沒有比4 個(gè)的情況更好，這與核心數(shù)過多，任務(wù)調(diào)度消耗資源增多有關(guān)。

測試可得：在OVS-DPDK 架構(gòu)下，使用virtio 驅(qū)動和vhost-user 接口配置虛擬機(jī)網(wǎng)卡，可有效提升網(wǎng)絡(luò)性能，服務(wù)器網(wǎng)卡的性能損耗也明顯降低，且在4 核時(shí)網(wǎng)絡(luò)性能提升最大，網(wǎng)卡總帶寬是原生橋接的1.86 倍。

DPDK 自帶的3 層測試工具顯示網(wǎng)卡吞吐率是網(wǎng)橋的4～7 倍，在實(shí)際應(yīng)用層面上帶寬只有1.3～1.86 倍，二者數(shù)值上有一定差距，吞吐率是瞬時(shí)收發(fā)性能的體現(xiàn)，帶寬則是實(shí)際傳輸能力的衡量。從傳輸層到應(yīng)用層之間還存在性能損耗，這與實(shí)驗(yàn)中流表配置是否合適、大頁分配是否合理、包分片大小、CPU 綁定情況以及業(yè)務(wù)程序代碼邏輯等均有很大關(guān)系。目前，1.86 倍的應(yīng)用層帶寬提升有一定效果，3 層測試工具吞吐率的4～7 倍提升是基于測試程序的底層極限性能提升，后續(xù)帶寬優(yōu)化到網(wǎng)橋的2 倍或接近萬兆總帶寬是可行的研究 目標(biāo)。

6 結(jié)語

本文首先介紹了現(xiàn)階段云網(wǎng)絡(luò)方案，分析了OVS 性能瓶頸；其次引入DPDK；最后根據(jù)實(shí)際業(yè)務(wù)場景進(jìn)行了OVS+DPDK 和網(wǎng)橋的3 層轉(zhuǎn)發(fā)能力實(shí)驗(yàn)對比。理論上OVS+DPDK 的吞吐率是網(wǎng)橋的4～7倍，實(shí)際業(yè)務(wù)場景下帶寬則是網(wǎng)橋的1.3～1.86倍。DPDK 在處理高速數(shù)據(jù)報(bào)文中有較大作用，但其配置復(fù)雜，且對CPU 的親和性有一定要求。此外，從理論上的傳輸層到實(shí)際中的應(yīng)用層間的性能兌現(xiàn)還需更多研究。

部分學(xué)者提出了OVS+DPDK 的優(yōu)化方向，主要有開發(fā)用戶態(tài)網(wǎng)絡(luò)協(xié)議棧、添加DPDK 中斷優(yōu)先級、支持動態(tài)配置大頁內(nèi)存[8]3 個(gè)方面。OVS+DPDK 模式為云的網(wǎng)絡(luò)性能優(yōu)化提供了有效方案，后續(xù)希望能從以上3 個(gè)方面進(jìn)行深入研究，結(jié)合實(shí)際業(yè)務(wù)需求，以期在應(yīng)用層面上獲得更大的網(wǎng)絡(luò)性能提升。