基于網(wǎng)卡虛擬化的高性能容器網(wǎng)絡(luò)設(shè)計(jì)

臧迪，楊志剛，王晶，姚治成，張偉功

（1.首都師范大學(xué)信息工程學(xué)院，北京 100048；2.中國(guó)科學(xué)院計(jì)算技術(shù)研究所先進(jìn)計(jì)算機(jī)系統(tǒng)研究中心，北京 100080；3.首都師范大學(xué)高可靠嵌入式系統(tǒng)技術(shù)北京市工程中心，北京 100048）

0 概述

云計(jì)算具有資源利用率高、靈活和部署便利等特點(diǎn)，因此，越來(lái)越多的企業(yè)逐漸從傳統(tǒng)模式過(guò)渡到云計(jì)算模式。然而，云計(jì)算需要數(shù)據(jù)中心做支撐，當(dāng)數(shù)據(jù)包通過(guò)互聯(lián)網(wǎng)到達(dá)數(shù)據(jù)中心時(shí)，數(shù)據(jù)中心會(huì)采用防火墻、深度報(bào)文檢測(cè)、入侵檢測(cè)、網(wǎng)絡(luò)地址轉(zhuǎn)換等［1］技術(shù)對(duì)數(shù)據(jù)包進(jìn)行處理。網(wǎng)絡(luò)中間件與Web 業(yè)務(wù)緊密耦合，能夠滿(mǎn)足運(yùn)營(yíng)商電信級(jí)的業(yè)務(wù)要求。隨著云平臺(tái)規(guī)模的不斷擴(kuò)大，專(zhuān)用中間件的部署需求不斷增加，導(dǎo)致傳統(tǒng)軟硬一體化的封閉式結(jié)構(gòu)功能單一、不靈活、價(jià)格昂貴的缺點(diǎn)逐漸顯現(xiàn)。然而，軟件定義網(wǎng)絡(luò)（Software Define Network，SDN）結(jié)合軟硬解耦原理對(duì)網(wǎng)絡(luò)功能進(jìn)行虛擬化。這種網(wǎng)絡(luò)功能虛擬化（Network Function Virtualization，NFV）使得網(wǎng)絡(luò)架構(gòu)更靈活、功能更豐富、價(jià)格更低廉，推動(dòng)云計(jì)算平臺(tái)的發(fā)展，加快了容器技術(shù)、虛擬交換機(jī)技術(shù)和網(wǎng)卡虛擬化技術(shù)的成熟和推廣。

NFV 技術(shù)實(shí)現(xiàn)了軟硬件解耦，并且具有靈活的網(wǎng)絡(luò)部署和動(dòng)態(tài)擴(kuò)展的特點(diǎn)。傳統(tǒng)的NFV 平臺(tái)主要依靠虛擬機(jī)技術(shù)，基于虛擬機(jī)的NFV 架構(gòu)能夠?qū)⒖臻g資源隔離，具有較優(yōu)的靈活性和按需分配性，但是虛擬機(jī)帶來(lái)的資源消耗較大［2］。例如，在NFV 開(kāi)放平臺(tái)（OPNFV）［3］框架下，使用OpenStack 虛擬機(jī)技術(shù)與OpenDaylight 構(gòu)建虛擬化基礎(chǔ)設(shè)施管理器，產(chǎn)生的資源消耗較大。

容器技術(shù)是一種基于內(nèi)核命名空間的資源隔離技術(shù)，近年來(lái)，作為下一代虛擬化技術(shù)進(jìn)入快速普及階段。由于容器技術(shù)沒(méi)有硬件損失，因此具有接近裸機(jī)的性能。此外，容器技術(shù)的啟動(dòng)速度可以達(dá)到毫秒級(jí)，因此在資源利用率和靈活部署方面有很大優(yōu)勢(shì)。采用容器技術(shù)構(gòu)建虛擬網(wǎng)絡(luò)功能能夠有效解決資源開(kāi)銷(xiāo)大的問(wèn)題［4-5］?；谌萜骷夹g(shù)構(gòu)建虛擬網(wǎng)絡(luò)功能通常采用Linux 自帶的橋接模式、overlay網(wǎng)絡(luò)或者虛擬交換機(jī)部署［6-7］。這種模式雖然可以實(shí)現(xiàn)流量轉(zhuǎn)發(fā)，但是在跨主機(jī)情況下，流量經(jīng)過(guò)網(wǎng)卡需要兩次轉(zhuǎn)發(fā)，導(dǎo)致延遲敏感型應(yīng)用產(chǎn)生較大的性能損失，并且CPU 的負(fù)載較大，導(dǎo)致帶寬下降。

本文提出目標(biāo)感知的容器網(wǎng)絡(luò)用于NFV 長(zhǎng)鏈場(chǎng)景。結(jié)合硬件虛擬化技術(shù)和軟件模擬技術(shù)判斷流量的目的地址，尋找最優(yōu)的流量轉(zhuǎn)發(fā)路徑，優(yōu)化NFV場(chǎng)景下經(jīng)過(guò)每個(gè)業(yè)務(wù)節(jié)點(diǎn)的網(wǎng)絡(luò)延遲和吞吐量，同時(shí)利用基于腳本程序的自動(dòng)化部署模塊對(duì)每個(gè)節(jié)點(diǎn)業(yè)務(wù)進(jìn)行配置，便于用戶(hù)對(duì)網(wǎng)絡(luò)進(jìn)行管理和修改。

1 相關(guān)工作

在NFV 部署中，NFV 服務(wù)鏈的優(yōu)化技術(shù)和網(wǎng)絡(luò)I/O 虛擬化技術(shù)是影響網(wǎng)絡(luò)性能最直接的因素。

在NFV 服務(wù)鏈的優(yōu)化技術(shù)方面，文獻(xiàn)［8］將整條服務(wù)鏈的網(wǎng)絡(luò)功能拆分成若干個(gè)子模塊，消除原有服務(wù)鏈中的冗余模塊，加快服務(wù)鏈的處理速度。文獻(xiàn)［9］通過(guò)拷貝、合并等方式對(duì)原有的串行處理且無(wú)依賴(lài)關(guān)系的網(wǎng)絡(luò)功能進(jìn)行并行化包處理，優(yōu)化整條服務(wù)鏈的延遲和吞吐量性能。文獻(xiàn)［10］提出IETF（Internet Engineering Task Force），在云數(shù)據(jù)中心通過(guò)優(yōu)化虛擬網(wǎng)絡(luò)功能的調(diào)度完成時(shí)間來(lái)減少延遲。

現(xiàn)有的網(wǎng)絡(luò)I/O 虛擬化技術(shù)分為單根I/O 虛擬化（Single Root I/O Virtualization，SR-IOV）技術(shù)、軟件模擬虛擬化技術(shù)和網(wǎng)卡直通技術(shù)。SR-IOV 技術(shù)是由PCI-SIG 制定的輸入輸出虛擬化標(biāo)準(zhǔn)［11］，通過(guò)直接I/O 技術(shù)減少額外包復(fù)制帶來(lái)的性能損失，達(dá)到接近主機(jī)的性能。文獻(xiàn)［12］提出在標(biāo)準(zhǔn)X86 服務(wù)器上使用SR-IOV 技術(shù)部署虛擬化網(wǎng)絡(luò)功能，以達(dá)到提高吞吐量的目的。基于軟件模擬的網(wǎng)絡(luò)I/O 虛擬化技術(shù)又稱(chēng)虛擬交換機(jī)技術(shù)。虛擬交換機(jī)技術(shù)的工作原理與物理交換機(jī)類(lèi)似，其兩端分別連接著物理網(wǎng)卡和多塊虛擬網(wǎng)卡，同時(shí)虛擬交換機(jī)內(nèi)部會(huì)維護(hù)一張映射表，根據(jù)MAC 地址尋找對(duì)應(yīng)的虛擬機(jī)鏈路進(jìn)而完成數(shù)據(jù)轉(zhuǎn)發(fā)。文獻(xiàn)［13］提出一種虛擬交換機(jī)開(kāi)源軟件OpenVSwitch。文獻(xiàn)［14］對(duì)NFV 場(chǎng)景下虛擬交換機(jī)的性能進(jìn)行評(píng)估與分析。網(wǎng)卡直通技術(shù)使用硬件輔助虛擬化技術(shù)，將宿主機(jī)中的物理PCI 設(shè)備直接分配給客戶(hù)機(jī)使用，客戶(hù)機(jī)以獨(dú)占方式訪(fǎng)問(wèn)該宿主機(jī)的PCI/PCI-E 設(shè)備［15］。文獻(xiàn)［16］對(duì)X86 的網(wǎng)卡直通技術(shù)進(jìn)行分析，指出物理網(wǎng)卡直通更容易受到“拒絕攻擊”，從而影響每個(gè)服務(wù)器的性能。由于網(wǎng)卡直通技術(shù)只能被一個(gè)虛擬機(jī)獨(dú)享，安全性也存在隱患，因此逐漸被單根虛擬化技術(shù)和軟件模擬虛擬化技術(shù)所取代。

單根I/O 虛擬化技術(shù)和軟件模擬虛擬化技術(shù)已成為主流技術(shù)，為容器提供網(wǎng)橋的功能。但是單根I/O虛擬化技術(shù)在主機(jī)內(nèi)部傳輸方面比軟件模擬虛擬化技術(shù)性能差，而單根虛擬化技術(shù)在跨主機(jī)的性能要優(yōu)于軟件模擬虛擬化技術(shù)。在NFV 長(zhǎng)鏈的場(chǎng)景下，需要同時(shí)采用主機(jī)內(nèi)部的傳輸和主機(jī)外部的傳輸，使用單一某種技術(shù)難以滿(mǎn)足NFV 長(zhǎng)鏈場(chǎng)景的需求。針對(duì)上述問(wèn)題，本文提出一種目標(biāo)感知的容器網(wǎng)絡(luò)，通過(guò)優(yōu)化SR-IOV 技術(shù)在NFV 場(chǎng)景下的性能，降低NFV 場(chǎng)景下網(wǎng)絡(luò)的延遲并且提高網(wǎng)絡(luò)吞吐量。

2 目標(biāo)感知的容器網(wǎng)絡(luò)

目標(biāo)感知的容器網(wǎng)絡(luò)設(shè)計(jì)方案主要是對(duì)硬件虛擬化進(jìn)行改進(jìn)。傳統(tǒng)的SR-IOV［17］技術(shù)是通過(guò)驅(qū)動(dòng)把單一的物理網(wǎng)卡虛擬出獨(dú)立的虛擬網(wǎng)卡，并通過(guò)驅(qū)動(dòng)將網(wǎng)卡劃分為多個(gè)地址段。SR-IOV 技術(shù)主要有虛擬功能（Virtualization Function，VF）和物理功能（Physical Function，PF）。SR-IOV 技術(shù)原理示意圖如圖1 所示。

圖1 SR-IOV 技術(shù)原理示意圖Fig.1 Schematic diagram of SR-IOV technology principle

SR-IOV 技術(shù)主要分為3 層，最底層是支持SR-IOV 技術(shù)的硬件網(wǎng)卡，中間層是操作系統(tǒng)內(nèi)核，最上層是提供某種服務(wù)的容器。SR-IOV 技術(shù)的原理是網(wǎng)卡通過(guò)SR-IOV 技術(shù)虛擬出多個(gè)虛擬功能，虛擬出的VF 可以跨過(guò)操作系統(tǒng)內(nèi)核直接分配給提供某種服務(wù)的容器，但是在NFV 級(jí)聯(lián)的場(chǎng)景下，單獨(dú)使用SR-IOV 技術(shù)會(huì)導(dǎo)致其性能下降，因此針對(duì)NFV場(chǎng)景，本文設(shè)計(jì)目標(biāo)感知的容器網(wǎng)絡(luò)。

在NFV 場(chǎng)景下需要將各容器相互級(jí)聯(lián)，但是對(duì)于圖1 的設(shè)計(jì)，單獨(dú)使用SR-IOV 技術(shù)的網(wǎng)絡(luò)性能會(huì)出現(xiàn)瓶頸。因此，為解決SR-IOV 技術(shù)在NFV 場(chǎng)景下的性能瓶頸問(wèn)題，本文提出目標(biāo)感知的容器網(wǎng)絡(luò)，其結(jié)構(gòu)如圖2 所示。

圖2 目標(biāo)感知的容器網(wǎng)絡(luò)結(jié)構(gòu)Fig.2 Structure of container network for target perception

該網(wǎng)絡(luò)結(jié)構(gòu)的最頂層是使用容器技術(shù)把每個(gè)NFV 獨(dú)立應(yīng)用分別放在不同的容器中，使得容器之間的應(yīng)用相互隔離，如果需要某種應(yīng)用，可以直接使用特定功能的容器鏡像，以便于維護(hù)，例如容器應(yīng)用支持防火墻、深度包檢測(cè)、網(wǎng)絡(luò)地址轉(zhuǎn)換和負(fù)載均衡等功能。本文網(wǎng)絡(luò)利用SR-IOV 技術(shù)跨過(guò)操作系統(tǒng)內(nèi)核，通過(guò)軟交換實(shí)現(xiàn)容器與容器之間的交互，因此在網(wǎng)卡流量發(fā)送到主機(jī)時(shí)需要判斷流量發(fā)送位置。當(dāng)網(wǎng)卡跨過(guò)操作系統(tǒng)內(nèi)核到容器的網(wǎng)絡(luò)中間件時(shí)，目標(biāo)感知的容器網(wǎng)絡(luò)通過(guò)轉(zhuǎn)發(fā)模塊判斷目標(biāo)的目的地址，通過(guò)目的地址判斷網(wǎng)絡(luò)流量的方向，之后提交給最頂層。

2.1 轉(zhuǎn)發(fā)模塊

目標(biāo)感知的容器網(wǎng)絡(luò)結(jié)合網(wǎng)絡(luò)地址轉(zhuǎn)換（NAT）和OpenFlow［18-19］對(duì)轉(zhuǎn)發(fā)模塊進(jìn)行設(shè)計(jì)，主要依據(jù)軟件虛擬技術(shù)實(shí)現(xiàn)流量轉(zhuǎn)發(fā)。OpenVSwitch 是目前主流的軟件模擬技術(shù)，它提供OpenFlow 協(xié)議并且OpenVSwitch 的轉(zhuǎn)發(fā)性能比Linux 下的網(wǎng)橋模式較優(yōu)。因此，轉(zhuǎn)發(fā)模塊使用基于NAT 和OpenVSwitch的網(wǎng)絡(luò)設(shè)計(jì)實(shí)現(xiàn)流量的轉(zhuǎn)發(fā)。當(dāng)前轉(zhuǎn)發(fā)分為單根虛擬化的虛擬網(wǎng)卡和OpenVSwitch 的虛擬網(wǎng)卡2 個(gè)方向。流量轉(zhuǎn)發(fā)會(huì)判斷發(fā)送的目的地址是否在NFV長(zhǎng)鏈中，如果在NFV 長(zhǎng)鏈中，轉(zhuǎn)發(fā)模塊將流量提交到上層并對(duì)數(shù)據(jù)包進(jìn)行處理，例如深度包檢測(cè)或者負(fù)載均衡等服務(wù)，如果不在NFV 長(zhǎng)鏈中，轉(zhuǎn)發(fā)模塊就會(huì)丟棄該流量。轉(zhuǎn)發(fā)模塊還可以根據(jù)用戶(hù)輸入的OpenFlow 語(yǔ)法更改路徑，使用戶(hù)調(diào)整轉(zhuǎn)發(fā)路徑，實(shí)現(xiàn)靈活轉(zhuǎn)發(fā)，即可以對(duì)容器的流量進(jìn)行靈活規(guī)劃。

2.2 自動(dòng)化部署模塊

本文網(wǎng)絡(luò)在原有的基礎(chǔ)上增加了軟件交換技術(shù)和轉(zhuǎn)發(fā)模塊配置，因此提高了部署的復(fù)雜性。為便于部署，本文使用基于腳本程序的自動(dòng)化部署方案，無(wú)需手動(dòng)干預(yù)，并且對(duì)每個(gè)節(jié)點(diǎn)業(yè)務(wù)進(jìn)行配置。配置包括整體網(wǎng)絡(luò)框架配置、轉(zhuǎn)發(fā)模塊配置、網(wǎng)絡(luò)中間件設(shè)計(jì)以及服務(wù)節(jié)點(diǎn)設(shè)計(jì)。自動(dòng)化部署序列圖如圖3 所示。

圖3 自動(dòng)化部署序列圖Fig.3 Sequence diagram of automatic deployment

自動(dòng)化部署模塊主要分為3 個(gè)部分：1）部署選擇，主要是配置容器環(huán)境以及虛擬交換機(jī)和單根虛擬化；2）部署的環(huán)境配置，當(dāng)用戶(hù)啟動(dòng)自動(dòng)化部署模塊時(shí)，自動(dòng)化部署會(huì)讓用戶(hù)選擇自動(dòng)化部署模式，進(jìn)而選擇中間件，例如容器提供的服務(wù)（防火墻服務(wù)、深度包檢測(cè)服務(wù)、負(fù)載均衡服務(wù)、網(wǎng)頁(yè)服務(wù)以及無(wú)服務(wù)等）；3）對(duì)轉(zhuǎn)發(fā)模塊進(jìn)行配置，轉(zhuǎn)發(fā)模塊分為使用網(wǎng)絡(luò)地址轉(zhuǎn)換和使用OpenFlow 協(xié)議自定義轉(zhuǎn)換。轉(zhuǎn)發(fā)模塊配置完成之后，整體網(wǎng)絡(luò)實(shí)現(xiàn)自動(dòng)化部署。

自動(dòng)化部署模塊的整體架構(gòu)如圖4 所示。從圖4 可以看出，最底層使用SR-IOV 技術(shù)生成虛擬網(wǎng)卡，應(yīng)用層使用Docker 容器技術(shù)，系統(tǒng)內(nèi)核層中的軟交換使用OpenVSwitch。自動(dòng)化部署模塊能夠自動(dòng)配置轉(zhuǎn)發(fā)模塊規(guī)則以及整體的網(wǎng)絡(luò)拓?fù)洹?/p>

圖4 自動(dòng)化部署模塊的整體架構(gòu)Fig.4 Overall architecture of automatic deployment module

3 實(shí)驗(yàn)與結(jié)果分析

3.1 實(shí)驗(yàn)環(huán)境與配置

本文使用兩個(gè)測(cè)試工具，分別是對(duì)網(wǎng)絡(luò)性能進(jìn)行測(cè)試的Netperf［20］和對(duì)請(qǐng)求數(shù)進(jìn)行測(cè)試的Apache Benchmark，測(cè)試的內(nèi)容為長(zhǎng)鏈NFV 的網(wǎng)絡(luò)延遲帶寬和每秒請(qǐng)求數(shù)。

Web 服務(wù)器軟件Apache2 網(wǎng)頁(yè)應(yīng)用和Haproxy［21］負(fù)載均衡應(yīng)用主要是用于測(cè)試負(fù)載。Haproxy 具有較高的可用性和負(fù)載均衡能力，適用于負(fù)載大的Web 站點(diǎn)。

本文選擇Docker容器［22-23］，在容器中運(yùn)行Netperf 網(wǎng)絡(luò)性能評(píng)測(cè)工具，主要針對(duì)TCP 或UDP 的傳輸，針對(duì)不同應(yīng)用進(jìn)行不同模式的網(wǎng)絡(luò)性能測(cè)試。軟件虛擬化使用開(kāi)源OpenVSwitch，硬件虛擬化使用SR-IOV 技術(shù)。本文實(shí)驗(yàn)的硬件環(huán)境采用型號(hào)Intel E5620 X2 和主頻2.4 GHz 的CPU，內(nèi)存16 GB，內(nèi)存頻率1 333 MHz，型號(hào)82599 和帶寬為10 Gb/s的網(wǎng)卡。

本文實(shí)驗(yàn)的基本環(huán)境是使用2 臺(tái)服務(wù)器。每臺(tái)服務(wù)器有2 個(gè)主頻2.4 GHz 的E 5620 處理器，使用Intel 82599 網(wǎng)卡，選擇Centos 系統(tǒng)。

3.2 實(shí)驗(yàn)設(shè)計(jì)

本文配置了SR-IOV 和OpenVSwitch 的實(shí)驗(yàn)環(huán)境，并在容器中運(yùn)行Netperf 應(yīng)用、防火墻、Apache2網(wǎng)頁(yè)和Haproxy 負(fù)載均衡應(yīng)用。目標(biāo)感知的容器網(wǎng)絡(luò)拓?fù)浣Y(jié)構(gòu)如圖5 所示。

圖5 目標(biāo)感知的容器網(wǎng)絡(luò)拓?fù)浣Y(jié)構(gòu)Fig.5 Topology structure of container network for target perception

在NFV 長(zhǎng)鏈下，如果外部請(qǐng)求需要訪(fǎng)問(wèn)Apache2 網(wǎng)頁(yè)，經(jīng)過(guò)NAT、Haproxy、防火墻等一系列長(zhǎng)鏈服務(wù)才能夠請(qǐng)求成功。在這種情景下，如果單獨(dú)使用SR-IOV 會(huì)存在一定的不足，但是目標(biāo)感知的容器網(wǎng)絡(luò)可以解決這個(gè)問(wèn)題。

當(dāng)外部只訪(fǎng)問(wèn)NFV 長(zhǎng)鏈中的某一個(gè)應(yīng)用時(shí)，本文網(wǎng)絡(luò)能夠解決OpenVSwitch 經(jīng)過(guò)操作系統(tǒng)內(nèi)核后性能降低的問(wèn)題。

本文網(wǎng)絡(luò)主要使用內(nèi)網(wǎng)轉(zhuǎn)發(fā)技術(shù)，在容器中增加兩個(gè)網(wǎng)卡，外部提供訪(fǎng)問(wèn)的網(wǎng)卡使用SR-IOV 網(wǎng)卡，內(nèi)部使用OpenVSwitch 網(wǎng)卡，通過(guò)內(nèi)網(wǎng)轉(zhuǎn)發(fā)將OpenVSwitch 網(wǎng)卡相連接。從圖5 可以看出，當(dāng)外部訪(fǎng)問(wèn)時(shí)，在整個(gè)長(zhǎng)鏈NFV 的請(qǐng)求中選擇一條最優(yōu)的路徑。當(dāng)外部請(qǐng)求NFV 長(zhǎng)鏈中的某一項(xiàng)服務(wù)時(shí)，可以抽象為圖5 的網(wǎng)絡(luò)拓?fù)浣Y(jié)構(gòu)，這種情況通常出現(xiàn)在排查網(wǎng)絡(luò)故障和內(nèi)部數(shù)據(jù)維護(hù)的時(shí)候。

3.3 實(shí)驗(yàn)結(jié)果

首先搭建SR-IOV 與OpenVSwitch 的環(huán)境，分別在SR-IOV 和OpenVSwitch 環(huán)境下部署不同應(yīng)用，使用Netperf 和Apache Benchmark 壓力測(cè)試工具進(jìn)行精確測(cè)試并分析SR-IOV 的性能；然后部署SR-IOV與OpenVSwitch 混合策略，與未優(yōu)化前的數(shù)據(jù)進(jìn)行對(duì)比，在NFV 長(zhǎng)鏈下，對(duì)目標(biāo)感知容器網(wǎng)絡(luò)技術(shù)與單獨(dú)的SR-IOV 與OpenVSwitch 技術(shù)的性能進(jìn)行對(duì)比。

在對(duì)外提供服務(wù)的場(chǎng)景中，網(wǎng)絡(luò)需要訪(fǎng)問(wèn)NFV長(zhǎng)鏈中的所有節(jié)點(diǎn)，以保證服務(wù)的安全性和完整性。

3.3.1 延遲測(cè)試

本文使用Netperf 測(cè)試工具分別測(cè)試SR-IOV 網(wǎng)絡(luò)、OpenVSwitch 網(wǎng)絡(luò)和本文網(wǎng)絡(luò)的延遲。每個(gè)實(shí)驗(yàn)測(cè)試次數(shù)為10 次，最終結(jié)果為10 次的平均值，測(cè)試結(jié)果如圖6 所示。

圖6 NFV 長(zhǎng)鏈下不同網(wǎng)絡(luò)的Netperf 延遲測(cè)試結(jié)果對(duì)比Fig.6 Netperf delay test results comparison among different networks in NFV long chain

從圖6 可以看出，在NFV 長(zhǎng)鏈下，單獨(dú)使用SR-IOV 技術(shù)的網(wǎng)絡(luò)延遲為 9.745 ms，使 用OpenVSwitch 技術(shù)的網(wǎng)絡(luò)延遲為7.406 ms，使用本文技術(shù)得到的網(wǎng)絡(luò)延遲為7.637 ms。因此，本文網(wǎng)絡(luò)性能比單獨(dú)的SR-IOV 性能提高21.6%。在NFV 長(zhǎng)鏈的應(yīng)用場(chǎng)景中，OpenVSwitch 技術(shù)的延遲最優(yōu)，本文網(wǎng)絡(luò)與OpenVSwitch 持平。

3.3.2 NFV 長(zhǎng)鏈下每秒請(qǐng)求數(shù)測(cè)試

本文在NFV 長(zhǎng)鏈應(yīng)用場(chǎng)景下，使用Apache Benchmark 對(duì)SR-IOV、OpenVSwitch 和本文網(wǎng)絡(luò)進(jìn)行請(qǐng)求數(shù)測(cè)試，測(cè)試結(jié)果如圖7 所示。

圖7 不同網(wǎng)絡(luò)的每秒請(qǐng)求數(shù)測(cè)試結(jié)果Fig.7 Test results of requests per second for different networks

從圖7 可以看出，在Apache Benchmark 的負(fù)載下，當(dāng)本文訪(fǎng)問(wèn)NFV 長(zhǎng)鏈服務(wù)時(shí)，其請(qǐng)求數(shù)是每秒12 718 個(gè)，OpenVSwitch 網(wǎng)絡(luò)的每秒請(qǐng)求數(shù)12 812 個(gè)，SR-IOV 網(wǎng)絡(luò)的每秒請(qǐng)求數(shù)10 310 個(gè)。在NFV 長(zhǎng)鏈的應(yīng)用場(chǎng)景下，SR-IOV 的每秒請(qǐng)求數(shù)是最差的，本文網(wǎng)絡(luò)的每秒請(qǐng)求數(shù)與OpenVSwitch 持平，本文網(wǎng)絡(luò)比SR-IOV 性能提高了23.35%。

3.3.3 某一項(xiàng)服務(wù)延遲測(cè)試

在Netperf 負(fù)載下，不同網(wǎng)絡(luò)訪(fǎng)問(wèn)NFV 長(zhǎng)鏈中某一項(xiàng)服務(wù)的延遲對(duì)比如圖8 所示。

圖8 不同網(wǎng)絡(luò)訪(fǎng)問(wèn)NFV 長(zhǎng)鏈某一項(xiàng)服務(wù)的延遲對(duì)比Fig.8 Comparison of delay of accessing a service in NFV long chain by different networks

從圖8 可以看出，當(dāng)訪(fǎng)問(wèn)NFV 長(zhǎng)鏈某一項(xiàng)服務(wù)時(shí)，SR-IOV 的延遲為1 983 μs，OpenVSwitch 的延遲為2 312 μs，本文網(wǎng)絡(luò)的延遲為1 964 μs。因此，當(dāng)訪(fǎng)問(wèn)單獨(dú)服務(wù)時(shí)，OpenVSwitch 的性能最差，本文網(wǎng)絡(luò)的性能與SR-IOV 的性能持平。

3.3.4 某一項(xiàng)服務(wù)的請(qǐng)求數(shù)測(cè)試

本文實(shí)驗(yàn)對(duì)NFV 長(zhǎng)鏈中單獨(dú)Apache2 服務(wù)進(jìn)行請(qǐng)求數(shù)測(cè)試，測(cè)試結(jié)果如圖9 所示。

圖9 不同網(wǎng)絡(luò)的Apache2 服務(wù)請(qǐng)求數(shù)Fig.9 The number of Apache2 service requests of different networks

從圖9 可以看出，在Apache Benchmark 負(fù)載下，本文網(wǎng)絡(luò)訪(fǎng)問(wèn)單獨(dú)服務(wù)的請(qǐng)求數(shù)是每秒50 937 個(gè)，OpenVSwitch 的每秒請(qǐng)求數(shù)是45 068 個(gè)，SR-IOV 的每秒請(qǐng)求數(shù)是50 132 個(gè)。本文在訪(fǎng)問(wèn)單獨(dú)服務(wù)時(shí)與SR-IOV 的結(jié)果持平。

綜上可知，本文網(wǎng)絡(luò)在長(zhǎng)鏈NFV 下的性能優(yōu)于單獨(dú)使用SR-IOV 和OpenVSwitch 的性能，并且綜合OpenVSwitch 和SR-IOV 的優(yōu)點(diǎn)。在長(zhǎng)鏈NFV 中，本文網(wǎng)絡(luò)比SR-IOV 的性能提高約20%，在直通訪(fǎng)問(wèn)時(shí)，本文網(wǎng)絡(luò)比軟件模擬網(wǎng)絡(luò)性能提高15%。

4 結(jié)束語(yǔ)

針對(duì)網(wǎng)絡(luò)功能虛擬化場(chǎng)景下網(wǎng)絡(luò)I/O 性能瓶頸，本文設(shè)計(jì)一種目標(biāo)感知的高性能容器網(wǎng)絡(luò)，通過(guò)轉(zhuǎn)發(fā)模塊和基于腳本程序的自動(dòng)化部署模塊，尋找最優(yōu)的流量轉(zhuǎn)發(fā)路徑，并對(duì)每個(gè)節(jié)點(diǎn)進(jìn)行業(yè)務(wù)配置，實(shí)現(xiàn)容器網(wǎng)絡(luò)流量的靈活轉(zhuǎn)發(fā)，便于用戶(hù)對(duì)網(wǎng)絡(luò)進(jìn)行管理和修改。實(shí)驗(yàn)結(jié)果表明，本文設(shè)計(jì)的容器網(wǎng)絡(luò)能夠有效提高NFV 長(zhǎng)鏈場(chǎng)景下的網(wǎng)絡(luò)性能，為解決數(shù)據(jù)中心網(wǎng)絡(luò)I/O 虛擬化問(wèn)題提供新思路。下一步將在單根I/O 虛擬化技術(shù)的基礎(chǔ)上增加OpenFlow 流量轉(zhuǎn)發(fā)規(guī)則，以提高平臺(tái)流量轉(zhuǎn)發(fā)的效率。