臧迪,楊志剛,王晶,姚治成,張偉功
(1.首都師范大學(xué)信息工程學(xué)院,北京 100048;2.中國(guó)科學(xué)院計(jì)算技術(shù)研究所先進(jìn)計(jì)算機(jī)系統(tǒng)研究中心,北京 100080;3.首都師范大學(xué)高可靠嵌入式系統(tǒng)技術(shù)北京市工程中心,北京 100048)
云計(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)行管理和修改。
在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ò)吞吐量。
目標(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ò)流量的方向,之后提交給最頂層。
目標(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ī)劃。
本文網(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
本文使用兩個(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)。
本文配置了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í)候。
首先搭建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%。
針對(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ā)的效率。