王煜煒 劉 敏 馬 誠 李鵬飛

1(中國科學(xué)院計算技術(shù)研究所 北京 100190) 2 (中國科學(xué)院大學(xué) 北京 100049) (wangyuwei@ict.ac.cn)

在傳統(tǒng)的電信業(yè)務(wù)系統(tǒng)中，豐富多彩的業(yè)務(wù)由各類專有硬件設(shè)備承載.伴隨著新技術(shù)和新服務(wù)的蓬勃發(fā)展，設(shè)備的生命周期越來越短且運營成本大幅增加，使得傳統(tǒng)電信業(yè)務(wù)應(yīng)對來自互聯(lián)網(wǎng)企業(yè)OTT(over the top)的服務(wù)競爭中逐漸處于不利地位.

針對上述問題，由全球各大運營商牽頭，歐洲電信標(biāo)準(zhǔn)化協(xié)會(ETSI)在2012年首次提出了網(wǎng)絡(luò)功能虛擬化(network function vitalization, NFV)的概念，其核心思想在于將網(wǎng)絡(luò)功能與專用硬件設(shè)備解耦，進(jìn)而將其以軟件形式部署于數(shù)據(jù)中心通用硬件平臺，從而為運營商提供強大的業(yè)務(wù)整合與創(chuàng)新能力[1-2].基于NFV技術(shù)框架，通過特定的管理與編排策略，使得虛擬網(wǎng)絡(luò)功能(network function, NF)以中間件的形式串接形成業(yè)務(wù)服務(wù)鏈(service function chain, SFC)(簡稱業(yè)務(wù)鏈)來提供服務(wù)，NF類型和順序決定了業(yè)務(wù)鏈的功能內(nèi)容[3].然而，部署電信業(yè)務(wù)所帶來的龐大用戶請求和數(shù)據(jù)流量給NFV業(yè)務(wù)系統(tǒng)帶來了巨大壓力，從而引發(fā)時延增大和吞吐量下降等嚴(yán)重的性能問題[4]，此時單一NF功能處理單元往往不能滿足數(shù)據(jù)高效處理要求，為了保障業(yè)務(wù)網(wǎng)絡(luò)性能，需要將數(shù)據(jù)在不同NF間進(jìn)行均勻分發(fā)以達(dá)到高效處理的目的.因此，在NFV系統(tǒng)中部署負(fù)載均衡服務(wù)至關(guān)重要.

ETSI官方發(fā)布的標(biāo)準(zhǔn)文稿中定義了4種負(fù)載均衡系統(tǒng)模型[5]，根據(jù)負(fù)載均衡服務(wù)與網(wǎng)絡(luò)功能耦合的情況可分為2類：內(nèi)部負(fù)載均衡和外部負(fù)載均衡服務(wù)系統(tǒng).前者內(nèi)嵌于NF產(chǎn)品中，大多由專門廠家定制研發(fā)，但部署受限于具體產(chǎn)品架構(gòu)，缺乏通用性和良好的可移植性；相應(yīng)地，在外部負(fù)載均衡服務(wù)系統(tǒng)架構(gòu)中，負(fù)載均衡器可以作為單獨的網(wǎng)絡(luò)功能NF進(jìn)行部署，由NFV管理系統(tǒng)進(jìn)行統(tǒng)一業(yè)務(wù)編排，部署和擴展靈活.因此，本文所提出的負(fù)載均衡機制基于外部負(fù)載均衡服務(wù)系統(tǒng)模型實現(xiàn).

傳統(tǒng)的網(wǎng)絡(luò)負(fù)載均衡系統(tǒng)通常以專用硬件設(shè)備的形式部署于網(wǎng)絡(luò)中，這種方式存在明顯的缺陷[6-7]：1)其擴展性受到單點設(shè)備容量限制，很難滿足用戶業(yè)務(wù)流量快速增長需求.2)不能滿足實時業(yè)務(wù)的高可達(dá)性需求.盡管通常采用成對部署的方式來避免單點故障的影響，只能提供簡單的1+1冗余備份.3)缺乏業(yè)務(wù)快速迭代所需要的靈活性和可編程性，硬件系統(tǒng)通常很難升級和修改.4)成本較高，通常只有靠增加新的設(shè)備進(jìn)行部署.相比較而言，面向NFV的負(fù)載均衡系統(tǒng)以軟件形式部署于商用服務(wù)平臺之上，因此成本得以大大降低.同時，可以利用橫向擴展方式來解決可擴展性問題，此時處理容量可通過靈活增加部署虛擬機的方式來實現(xiàn)，從而提供N+1的冗余備份.同時，服務(wù)可達(dá)性和可靠性也得到增強，系統(tǒng)部署和升級改造也得以簡化.

盡管具有上述優(yōu)點，設(shè)計和部署一個面向NFV的負(fù)載均衡軟件系統(tǒng)仍然具有非常大的挑戰(zhàn)：1)由于NFV承載大量電信業(yè)務(wù)流量和訪問請求，相關(guān)負(fù)載均衡機制必須能夠在虛擬化環(huán)境中提供高吞吐量、低延遲的處理性能；2)必須保證業(yè)務(wù)服務(wù)鏈連接的準(zhǔn)確一致，即屬于同一個業(yè)務(wù)連接的數(shù)據(jù)報文能夠轉(zhuǎn)發(fā)至后序相同的NF實例，并能夠應(yīng)對后端資源池發(fā)生動態(tài)變化狀況和其他故障；3)業(yè)務(wù)服務(wù)鏈所處的虛擬化網(wǎng)絡(luò)環(huán)境復(fù)雜多變，其網(wǎng)絡(luò)性能受到多種因素影響而波動情況明顯.因此，必須根據(jù)網(wǎng)絡(luò)鏈路狀況以及NF工作負(fù)荷情況提供實時、準(zhǔn)確的負(fù)載均衡調(diào)度策略.

基于數(shù)據(jù)平面開發(fā)套件(data plane develop-ment kit, DPDK)等相關(guān)技術(shù)[8]，本文設(shè)計實現(xiàn)面向NFV的4層高性能網(wǎng)絡(luò)負(fù)載均衡機制及系統(tǒng)HVLB(high performance virtual load balance system)，能夠靈活部署并運行于主流虛擬化平臺環(huán)境，主要貢獻(xiàn)包括4點：

1) 設(shè)計實現(xiàn)基于控制與轉(zhuǎn)發(fā)處理分離的負(fù)載均衡處理架構(gòu)，實現(xiàn)調(diào)度策略制訂和數(shù)據(jù)轉(zhuǎn)發(fā)的有效分離.同時，提出基于綜合能力反饋的NF選擇與調(diào)度策略，將網(wǎng)絡(luò)鏈路和NF計算資源使用狀況作為調(diào)度依據(jù)，有效減小業(yè)務(wù)數(shù)據(jù)分發(fā)處理過程中的開銷.

2) 針對虛擬化網(wǎng)絡(luò)環(huán)境下數(shù)據(jù)包傳輸與處理特點，基于網(wǎng)卡分流功能實現(xiàn)隊列處理功能硬件卸載，采用多核多隊列并發(fā)高效處理數(shù)據(jù)報文，并保證各處理隊列間的任務(wù)流量均衡，保障數(shù)據(jù)包的高效處理.

3) 設(shè)計基于虛擬NUMA節(jié)點資源分配策略，實現(xiàn)從虛擬機到用戶空間處理線程之間的數(shù)據(jù)零拷貝，并保證各處理隊列之間數(shù)據(jù)訪問隔離，有效地減少內(nèi)存申請和釋放及線程同步開銷.

4) 基于KVM的虛擬化平臺部署并實現(xiàn)HVLB原型系統(tǒng).在虛擬化環(huán)境下，HVLB單隊列和多隊列處理性能均遠(yuǎn)遠(yuǎn)優(yōu)于主流開源軟件系統(tǒng)LVS(Linux virtual server)[9].針對UDP小尺寸數(shù)據(jù)包，在給定計算資源情況下，HVLB在萬兆網(wǎng)卡上達(dá)到了線速的處理與轉(zhuǎn)發(fā)性能.

1 相關(guān)工作

目前，負(fù)載均衡技術(shù)廣泛受到產(chǎn)業(yè)界和學(xué)術(shù)界的關(guān)注，現(xiàn)有工作主要分為3類:

1) 傳統(tǒng)依靠專有硬件設(shè)備實現(xiàn)的負(fù)載均衡方案[10-14].如引言中所述，這些方案著眼于利用硬件來提升網(wǎng)絡(luò)數(shù)據(jù)處理性能；但是成本較高，且可擴展性、靈活性較差，不適合NFV場景中業(yè)務(wù)動態(tài)部署的需求.

Fig. 1 The architecture and working flow of HVLB圖1 HVLB架構(gòu)及處理流程

2) 基于軟件的網(wǎng)絡(luò)負(fù)載均衡方案.部分方案以通用軟件包的形式，按照扁平的結(jié)構(gòu)進(jìn)行部署，目前已經(jīng)在Web搜索或其他并行計算系統(tǒng)中得到廣泛應(yīng)用，如LVS，Nginx[15]，HAProxy[16]等.這部分方案可在虛擬化環(huán)境下進(jìn)行靈活、快速地部署.但數(shù)據(jù)傳輸與處理基于內(nèi)核，存在網(wǎng)卡中斷、數(shù)據(jù)包拷貝等固有開銷，網(wǎng)絡(luò)性能較差；且需依靠多層次部署才能實現(xiàn)容量擴展,無法滿足NFV業(yè)務(wù)的需求.

3) 隨著用戶業(yè)務(wù)需求進(jìn)一步擴大，出現(xiàn)了第3類層次化負(fù)載均衡解決方案，其實質(zhì)是一個可擴展的負(fù)載均衡集群系統(tǒng).相關(guān)機制依托ECMP協(xié)議進(jìn)行業(yè)務(wù)分流.將數(shù)據(jù)平面功能劃分為若干層次，在路由器、負(fù)載均衡器和終端服務(wù)器之間建立多層負(fù)載處理，具有良好的可擴展性和處理能力.比較典型的有微軟公司的Ananta[7],Duet[17]，普林斯頓大學(xué)的Niagara[18]和谷歌公司的Maglev[6]等.Ananta是一個分布式的軟件負(fù)載均衡器，它采用ECMP協(xié)議進(jìn)行系統(tǒng)擴展和管理控制，并使用業(yè)務(wù)流表保持連接的一致性.盡管提供了快速路徑轉(zhuǎn)發(fā)機制，其單機數(shù)據(jù)包的處理性能受限于操作系統(tǒng)內(nèi)核，在虛擬化環(huán)境中存在處理瓶頸.Duet和Niagara是基于硬件和軟件混合設(shè)計的負(fù)載均衡器，旨在解決Ananta機制存在的單機轉(zhuǎn)發(fā)性能問題，其使用數(shù)據(jù)中心現(xiàn)有的交換機來構(gòu)造高性能負(fù)載均衡系統(tǒng)，處理與轉(zhuǎn)發(fā)需要大量依靠硬件交換機，使得無法在NFV虛擬化環(huán)境中進(jìn)行靈活部署和擴展.Maglev是谷歌公司為其云平臺研發(fā)的網(wǎng)絡(luò)負(fù)載均衡系統(tǒng)，統(tǒng)一部署并運行于商用物理服務(wù)器中，處理容量可以通過添加移除服務(wù)器的形式進(jìn)行調(diào)整.在性能優(yōu)化方面，Maglev采用網(wǎng)卡和進(jìn)程共享內(nèi)存資源的方式實現(xiàn)內(nèi)核跨越，轉(zhuǎn)發(fā)性能可以達(dá)到線速.同時引入特有的一致性Hash與連接追溯算法,提供均勻、準(zhǔn)確的后端服務(wù)器選擇和調(diào)整機制.Maglev系統(tǒng)適用于較大規(guī)模云平臺且性能優(yōu)異，但無法直接部署并應(yīng)用于NFV虛擬化環(huán)境中；同時，其采用的服務(wù)集群選擇策略未考慮鏈路狀況及計算負(fù)載變化對其處理能力的影響，因而不能提供最佳的目標(biāo)NF選擇策略.

綜上所述，現(xiàn)有研究工作無法直接應(yīng)用于NFV虛擬化應(yīng)用場景，且未充分考慮虛擬化環(huán)境下的網(wǎng)絡(luò)鏈路和業(yè)務(wù)鏈負(fù)載變化狀況對業(yè)務(wù)處理性能的影響，進(jìn)而無法為業(yè)務(wù)系統(tǒng)提供高性能負(fù)載均衡服務(wù).

2 概 述

2.1 架構(gòu)與處理流程

HVLB采用控制與轉(zhuǎn)發(fā)分離的架構(gòu)設(shè)計，如圖1所示，主要包括控制器(controller, CR)和轉(zhuǎn)發(fā)器(forwarder, FR)兩部分.其中CR主要完成虛擬服務(wù)配置、調(diào)度策略制訂以及對轉(zhuǎn)發(fā)器工作狀況、NF計算資源占用以及網(wǎng)絡(luò)鏈路狀況監(jiān)測.此外，CR還提供與NFV管理系統(tǒng)的接口，以實施資源動態(tài)配置與調(diào)整.在實際部署中，CR既可作為NFV管理系統(tǒng)的一部分，也可以單獨部署.相應(yīng)地，F(xiàn)R則專注于數(shù)據(jù)包的接收、調(diào)度策略執(zhí)行及轉(zhuǎn)發(fā)處理.在實際的數(shù)據(jù)中心環(huán)境部署中，可根據(jù)虛擬網(wǎng)絡(luò)配置情況部署多個CR，每個CR負(fù)責(zé)管控不同的FR，從而提升管理效率，保障性能.

HVLB主要工作流程包括：由NFV管理系統(tǒng)根據(jù)業(yè)務(wù)處理和傳輸狀況向HVLB發(fā)起負(fù)載均衡請求(步驟①)，同時將需要進(jìn)行負(fù)載均衡的NF及業(yè)務(wù)鏈的信息發(fā)送給CR，其中包含虛擬服務(wù)、待服務(wù)的前序NF信息等；收到請求后，CR給出確認(rèn)回復(fù)(步驟②)，同時挑選工作能力較強的FR進(jìn)行處理，并向該FR下發(fā)虛擬服務(wù)配置指令(步驟③)；如果未能找到合適的FR則通知NFV管理系統(tǒng)建立新的FR實例.FR接收到CR配置指令后，進(jìn)行確認(rèn)回復(fù)，并及時更新其虛擬服務(wù)列表(virtual service list, VSL)(步驟④).NFV管理系統(tǒng)下發(fā)路由更新策略(步驟⑤)，引導(dǎo)待服務(wù)NF業(yè)務(wù)流轉(zhuǎn)發(fā)至步驟③中選定或新生成的FR(步驟⑥)，由該FR完成業(yè)務(wù)數(shù)據(jù)轉(zhuǎn)發(fā)和響應(yīng)接收(步驟⑦)，并更新其業(yè)務(wù)連接表(connection table, CFT).CR開始根據(jù)備選目標(biāo)NF計算資源占用及網(wǎng)絡(luò)鏈路狀況為FR制訂業(yè)務(wù)調(diào)度轉(zhuǎn)發(fā)策略，并更新下發(fā)至FR(步驟⑧).FR根據(jù)CR策略將數(shù)據(jù)包轉(zhuǎn)發(fā)至備選NF集群中的多個NF處理，然后根據(jù)NFV管理系統(tǒng)路由信息將數(shù)據(jù)包轉(zhuǎn)發(fā)至該業(yè)務(wù)鏈中的后續(xù)NF.

2.2 虛擬服務(wù)配置與管理

HVLB旨在為NFV業(yè)務(wù)提供業(yè)務(wù)負(fù)載分擔(dān)，盡可能減少網(wǎng)絡(luò)傳輸和處理瓶頸.作為特殊的網(wǎng)絡(luò)功能中間件，HVLB可為多個NF或多條業(yè)務(wù)鏈同時提供服務(wù).因此，首先需要對其提供的服務(wù)進(jìn)行標(biāo)識和管理.

虛擬服務(wù)(virtual service,vs)是HVLB對外進(jìn)行服務(wù)宣稱的虛擬實例，用五元組信息(關(guān)鍵字，協(xié)議，地址，端口，真實服務(wù))標(biāo)識，即vsi=〈keyi,protocoli,vipi,vporti,rsi〉.其中，protocol為傳輸協(xié)議，vip為虛擬服務(wù)IP地址，vport為對應(yīng)端口號，關(guān)鍵字key為此虛擬服務(wù)的唯一標(biāo)識，由協(xié)議、地址和端口所對應(yīng)的值進(jìn)行Hash計算得到.真實服務(wù)(real service,rs)實質(zhì)是為該虛擬服務(wù)提供處理的目標(biāo)NF集合，用rsi=〈keyk,protocolk,dipk,dportk,healthk,reservedk〉標(biāo)識，其中前4項含義與關(guān)鍵字計算方法和虛擬服務(wù)一致，不同之處在于虛擬服務(wù)中的IP地址并不需要配置在具體網(wǎng)絡(luò)接口上，而真實服務(wù)中的IP地址和端口信息為各NF所在虛擬機中的真實配置信息.health為每個NF的工作狀態(tài)，初始化設(shè)置為1.在系統(tǒng)處理過程中，若CR通過NFV管理系統(tǒng)獲悉某個NF故障或網(wǎng)絡(luò)不可達(dá)，即將該NF健康狀態(tài)置為0.此時暫時將該rs從對應(yīng)vs中真實服務(wù)列表中剔除.reserved為調(diào)度轉(zhuǎn)發(fā)策略保留信息字段，主要用來存放對應(yīng)某vs中的各目標(biāo)NF的轉(zhuǎn)發(fā)比例.當(dāng)需要進(jìn)行虛擬服務(wù)添加時，首先完成2.1節(jié)中的虛擬服務(wù)信息配置，由CR統(tǒng)一管理并維護(hù)虛擬服務(wù)集合VS={vsi}(i=1,2,…,N)，同時下發(fā)至各個FR，由FR維護(hù)各自虛擬服務(wù)列表.相關(guān)虛擬服務(wù)配置結(jié)構(gòu)如圖2所示：

Fig. 2 The configuration of virtual service and management in HVLB圖2 HVLB虛擬服務(wù)配置與管理

3 轉(zhuǎn)發(fā)器

3.1 概 述

HVLB設(shè)計實現(xiàn)了高性能負(fù)載均衡轉(zhuǎn)發(fā)器數(shù)據(jù)處理框架，作為獨立的應(yīng)用程序，轉(zhuǎn)發(fā)器FR部署并運行于虛擬機的用戶空間，實現(xiàn)對Linux操作系統(tǒng)內(nèi)核協(xié)議棧的完全跨越.整體處理流程如下：轉(zhuǎn)發(fā)器基于輪詢模式批量接收來自網(wǎng)卡的數(shù)據(jù)請求和響應(yīng)，接收到的數(shù)據(jù)包將會按照其五元組信息被分發(fā)至不同的隊列進(jìn)行并行處理.首先進(jìn)行業(yè)務(wù)分類操作，該過程通過查找和匹配虛擬服務(wù)關(guān)鍵字進(jìn)行，只有匹配命中的數(shù)據(jù)包才會進(jìn)入后續(xù)處理流程.完成業(yè)務(wù)分類后，仍然以數(shù)據(jù)包五元組Hash值為關(guān)鍵字，在業(yè)務(wù)連接表中進(jìn)行連接狀態(tài)查詢.若命中，則證明該業(yè)務(wù)連接已存在，此時重用表中已選擇的NF作為目標(biāo)NF；若未命中，則證明該業(yè)務(wù)連接為新連接，需要從控制器CR更新的調(diào)度和轉(zhuǎn)發(fā)策略中選擇目標(biāo)NF.由于CR已經(jīng)為各NF確定了數(shù)據(jù)轉(zhuǎn)發(fā)比例，F(xiàn)R只需運行一個簡單的0～1的隨機數(shù)計算程序，然后將計算結(jié)果和4.2.3節(jié)中各NF轉(zhuǎn)發(fā)比例范圍進(jìn)行比對即可完成調(diào)度操作.同時，在業(yè)務(wù)連接轉(zhuǎn)發(fā)表中插入新的表項并維護(hù)業(yè)務(wù)連接狀態(tài).業(yè)務(wù)連接表格式如表1所示：

Table 1 The Structure of the Connection Table表1 業(yè)務(wù)連接表結(jié)構(gòu)

HVLB同時支持TCP和UDP傳輸協(xié)議，對于無連接的UDP協(xié)議，F(xiàn)R對相同五元組的數(shù)據(jù)分發(fā)視同一次“連接”，通過維護(hù)其超時狀態(tài)來進(jìn)行管理，超時時間默認(rèn)為300 s，若超時之后仍然沒有后續(xù)相同五元組的數(shù)據(jù)包到來，則將相關(guān)表項刪除.

完成調(diào)度策略選擇后，轉(zhuǎn)發(fā)器對數(shù)據(jù)包的路由和MAC信息進(jìn)行修改，根據(jù)NF目的地址查找路由表匹配出下一跳IP地址和端口，查找ARP表匹配出下一跳MAC地址，路由表和ARP表內(nèi)容通過控制器配置虛擬服務(wù)時進(jìn)行統(tǒng)一添加，并在處理過程中進(jìn)行定期更新維護(hù).最后將數(shù)據(jù)包地址和信息寫入發(fā)送隊列緩沖區(qū)描述符，請求網(wǎng)卡完成數(shù)據(jù)包轉(zhuǎn)發(fā).完成上述處理的同時，轉(zhuǎn)發(fā)器FR還需實時對各隊列數(shù)據(jù)處理情況進(jìn)行監(jiān)測；另一方面，實時接收并處理來自控制器CR的虛擬服務(wù)配置和調(diào)度策略更新消息.

3.2 高速數(shù)據(jù)包處理

為了滿足NFV承載的業(yè)務(wù)服務(wù)質(zhì)量需求，我們希望HVLB的處理和轉(zhuǎn)發(fā)速度能夠達(dá)到線速，因此需要盡可能減少處理與轉(zhuǎn)發(fā)過程中的各種開銷.分析負(fù)載均衡的處理過程，主要的開銷包括IO傳輸和數(shù)據(jù)處理2部分.前者主要指的是操作系統(tǒng)及網(wǎng)絡(luò)協(xié)議棧處理過程中引入的中斷、系統(tǒng)調(diào)用以及數(shù)據(jù)包拷貝等開銷；后者主要來源于計算資源調(diào)度競爭、線程上下文切換、數(shù)據(jù)訪問競爭等[19-20].

HVLB轉(zhuǎn)發(fā)器實質(zhì)上是一個位于虛擬機用戶態(tài)的高性能網(wǎng)絡(luò)處理協(xié)議棧.整體架構(gòu)如圖3所示，核心操作由處理與轉(zhuǎn)發(fā)線程(processing and for-warding thread, PFT)和統(tǒng)計與交互線程(statistics and interaction thread, SIT)兩類完成.從網(wǎng)卡接收到的請求和響應(yīng)被分發(fā)至多個隊列進(jìn)行處理，每個隊列對應(yīng)一個PFT線程，單獨完成負(fù)載均衡處理與轉(zhuǎn)發(fā)操作；相應(yīng)地，由SIT線程完成虛擬服務(wù)配置、各PFT對應(yīng)隊列的工作狀態(tài)信息監(jiān)測，并負(fù)責(zé)完成與控制器CR的消息交互操作.

Fig. 3 The processing architecture of the FR圖3 轉(zhuǎn)發(fā)器處理架構(gòu)

每個PFT周期性進(jìn)行接收請求和響應(yīng)輪詢，輪詢操作通過一個高速環(huán)形隊列Rece_Ring進(jìn)行，該隊列存在2個指針，分別指向當(dāng)前環(huán)形隊列中的未處理數(shù)據(jù)請求和已處理請求，請求中包含了相關(guān)數(shù)據(jù)包的地址指針信息.PFT讀取對應(yīng)地址信息，并隨即進(jìn)入后續(xù)操作處理.PFT和SIT之間的通信通過DPDK提供的無鎖環(huán)形隊列實現(xiàn)，每個PFT和SIT之間維護(hù)一個環(huán)形通信結(jié)構(gòu)Control_Ring，以獨立的生產(chǎn)者和消費者方式與其他PFT和SIT之間實現(xiàn)訪問隔離，減少由線程競爭引發(fā)的開銷.為保障處理性能，轉(zhuǎn)發(fā)器采取了一系列高效數(shù)據(jù)處理策略，下面進(jìn)行詳細(xì)介紹.

3.2.1 數(shù)據(jù)高效直通和零拷貝

數(shù)據(jù)高效傳輸是負(fù)載均衡相關(guān)業(yè)務(wù)高性能處理的前提，在虛擬化傳輸環(huán)境中，傳輸開銷主要包括中斷開銷、內(nèi)核空間和用戶空間的上下文切換以及數(shù)據(jù)拷貝開銷等.基于單根IO虛擬化(single root IO virtualization, SR-IOV)技術(shù)[21]，HVLB為轉(zhuǎn)發(fā)器所在虛擬機分配了特定的HVLB-VF(virtual function)，在網(wǎng)卡和虛擬化管理單元Hypervisor之間建立數(shù)據(jù)直通通道，實現(xiàn)對Hypervisor以及操作系統(tǒng)操作的跨越；另一方面，由于HVLB轉(zhuǎn)發(fā)器部署于虛擬機用戶空間，通過輪詢的方式實現(xiàn)數(shù)據(jù)批量的接收與發(fā)送，實現(xiàn)對虛擬機操作系統(tǒng)的跨越.通過上述2次跨越操作，轉(zhuǎn)發(fā)器在虛擬機用戶空間和網(wǎng)卡之間建立了高效直通通道.同時，基于用戶空間IO技術(shù)，轉(zhuǎn)發(fā)器在網(wǎng)卡和接收處理隊列之間建立共享數(shù)據(jù)包存儲區(qū)域，從網(wǎng)卡接收的數(shù)據(jù)包被直接存入共享數(shù)據(jù)包存儲區(qū)域，接收隊列輪詢到數(shù)據(jù)請求的同時將數(shù)據(jù)地址指針信息通知PFT進(jìn)行處理，整個過程無需進(jìn)行數(shù)據(jù)拷貝操作，有效減少了數(shù)據(jù)傳輸開銷.

3.2.2 隊列處理功能硬件卸載

3.2節(jié)已述及，PFT線程要負(fù)責(zé)處理負(fù)載均衡過程中的多項操作，因而會產(chǎn)生較大的處理開銷.如圖4所示，利用主流智能網(wǎng)卡支持的RSS[22](receive side scaling)和FD[23](flow director)技術(shù)，在不改動網(wǎng)卡硬件的前提下，轉(zhuǎn)發(fā)器進(jìn)一步將硬件隊列分配以及部分Hash計算操作卸載至網(wǎng)卡進(jìn)行，從而有效減少處理開銷，同時降低計算資源消耗，相關(guān)FD和RSS規(guī)則設(shè)置代碼參見圖5.

Fig. 4 Hardware function offload of queue processing圖4 隊列處理功能硬件卸載

隊列處理功能硬件卸載過程主要包含2部分操作：

1) 硬件隊列分配及CPU綁定

系統(tǒng)初始化時給轉(zhuǎn)發(fā)器所在虛擬機分配N個vCPU，分別綁定N個物理CPU核，將其中N-1個vCPU與相同數(shù)量的PFT線程綁定，稱為處理與轉(zhuǎn)發(fā)核(process and forward core, PFC)；將剩余1個vCPU與統(tǒng)計與交互線程SIT綁定，稱為統(tǒng)計與交互核(statistics and interaction core, SIC).同時，計算每個數(shù)據(jù)包的五元組Hash值，根據(jù)接收與處理核的數(shù)量，依托網(wǎng)卡建立相同數(shù)目的硬件接收與轉(zhuǎn)發(fā)隊列.

在數(shù)據(jù)接收方向上，基于控制信令接收端口號，通過FD規(guī)則匹配將所有接收到的來自控制器的控制消息數(shù)據(jù)報文發(fā)送至SIT線程上進(jìn)行處理，從而將控制報文和數(shù)據(jù)報文區(qū)分.進(jìn)一步基于RSS將余下相同五元組數(shù)據(jù)通過接收隊列均勻且獨立分發(fā)至多個PFT處理，由于各個PFT預(yù)先綁定了獨立的CPU資源，因而可以避免由于CPU上下文切換產(chǎn)生的開銷.完成相關(guān)處理后，依靠3.2.1節(jié)中直通通道從發(fā)送隊列中進(jìn)行轉(zhuǎn)發(fā).相應(yīng)的vCPU和物理CPU數(shù)量可根據(jù)業(yè)務(wù)流量進(jìn)行預(yù)設(shè)和調(diào)整.

2) 基于元數(shù)據(jù)的數(shù)據(jù)信息預(yù)處理

由3.1節(jié)分析可知，為了完成業(yè)務(wù)連接查詢匹配，需要計算每個數(shù)據(jù)包的五元組Hash值.隨著數(shù)據(jù)傳輸速率增加，上述計算開銷也會隨之增大，進(jìn)而會給處理性能帶來影響.基于DPDK提供的RSS功能接口，我們直接將操作1中用于硬件隊列分配所計算的五元組Hash值存入相關(guān)數(shù)據(jù)包的元數(shù)據(jù)信息中，業(yè)務(wù)連接狀態(tài)查詢時直接通過DPDK提供的pktmbuf.hash.rss接口訪問，有效地避免重復(fù)Hash計算操作帶來的處理開銷.

3.2.3 虛擬NUMA節(jié)點資源分配優(yōu)化策略

目前主流多處理器系統(tǒng)大多基于非統(tǒng)一內(nèi)存架構(gòu)(non uniform memory access architecture, NUMA)設(shè)計，不同的NUMA節(jié)點的CPU插槽(socket)中對應(yīng)不同的物理CPU核和本地內(nèi)存資源.在HVLB的實際部署過程中要求為虛擬機分配多個vCPU，每一個vCPU綁定一個物理CPU核.若當(dāng)前虛擬機所需CPU數(shù)量Cvm大于Socket含有的CPU核總數(shù)Csocket時，則需要從不同的Socket中分配CPU資源.此時，存儲訪問開銷將取決于處理器和不同存儲區(qū)域之間的相對位置.原則上應(yīng)該盡量避免不同的Sockets中CPU核交叉訪問各自的本地內(nèi)存資源，因為這會導(dǎo)致大量的上下文切換及競爭開銷，使得數(shù)據(jù)包處理性能大幅下降[24-25].

Fig. 6 The resource assignment and management of the virtual NUMA圖6 虛擬NUMA的資源分配與管理

為了解決上述問題，F(xiàn)R初始化時即進(jìn)行基于NUMA節(jié)點的資源分配策略優(yōu)化操作，如圖6所示.首先根據(jù)業(yè)務(wù)處理需求對轉(zhuǎn)發(fā)器所需的Cvm的數(shù)量上限進(jìn)行預(yù)估，然后利用KVM的libvirt接口從已有NUMA節(jié)點的Socket中劃分出相同數(shù)量的CPU核.同時以大頁(hugepage)形式為上述CPU分配本地內(nèi)存，形成為轉(zhuǎn)發(fā)器服務(wù)的物理NUMA資源池，其中包含若干獨立的NUMA節(jié)點資源.完成上述操作后，便可以在虛擬機側(cè)感知底層基于NUMA的資源分配情況.進(jìn)而基于DPDK功能接口將轉(zhuǎn)發(fā)器所在虛擬機vCPU及虛擬內(nèi)存和底層物理NUMA資源池中的CPU和本地內(nèi)存進(jìn)行綁定映射，從而形成和物理NUMA資源池相對應(yīng)的虛擬NUMA資源池，包含相同數(shù)量的虛擬NUMA節(jié)點.

當(dāng)需要為轉(zhuǎn)發(fā)器分配計算資源時，首先根據(jù)實際Cvm值確定所需的vCPU(也即物理CPU核)數(shù)量，從虛擬NUMA資源池中選擇若干vCPU和各PFT進(jìn)行綁定，并進(jìn)一步為每個PFT均勻分配獨立的數(shù)據(jù)緩存區(qū)，用于單獨存儲業(yè)務(wù)隊列數(shù)據(jù)及業(yè)務(wù)連接轉(zhuǎn)發(fā)表等信息.在處理過程中數(shù)據(jù)包始終存儲在預(yù)設(shè)內(nèi)存緩沖區(qū)內(nèi)；相應(yīng)地，轉(zhuǎn)發(fā)器也為SIT設(shè)置了獨立緩存區(qū)，用于存儲控制器之間的交互信息.應(yīng)用上述資源分配和管理機制的好處在于：1)可以直接通過數(shù)據(jù)包地址指針高效訪問對應(yīng)數(shù)據(jù)包緩沖區(qū)，對數(shù)據(jù)包進(jìn)行修改的過程無需任何拷貝操作，有效提升了數(shù)據(jù)包處理效率；2)確保不同線程所屬的處理數(shù)據(jù)相互隔離，避免了線程訪問共享數(shù)據(jù)的競爭開銷.

3.2.4 基于隊列負(fù)載狀況感知的QoS保障

轉(zhuǎn)發(fā)器實現(xiàn)數(shù)據(jù)的多隊列并行高效處理，依托RSS等技術(shù)使得到達(dá)所有隊列的業(yè)務(wù)流分布均勻.然而，由于每條業(yè)務(wù)流的數(shù)據(jù)發(fā)送速率不同，造成各隊列間的數(shù)據(jù)處理負(fù)載有所差異.隨著業(yè)務(wù)量不斷增大，可能造成某個隊列處理首先過載，后續(xù)發(fā)送至該隊列中的數(shù)據(jù)將會由于處理不及時而發(fā)生丟包.針對上述情況，轉(zhuǎn)發(fā)器進(jìn)一步采取了基于隊列負(fù)載狀況感知的QoS保障策略RSS-A，表2為主要變量及符號釋義對照表.

Table 2 Key Notations in the FR表2 轉(zhuǎn)發(fā)器器處理過程主要符號釋義

(1)

(2)

(3)

(4)

為了防止遷移過程對目標(biāo)隊列的過載影響，采取逐條逐項遷移操作的方式，并實時比較遷移前后目標(biāo)隊列過載頻率值的變化情況，確保目標(biāo)隊列不出現(xiàn)過載情況.此外，由于目標(biāo)隊列上PFT的業(yè)務(wù)連接表中沒有遷移業(yè)務(wù)流的相關(guān)信息.因此，完成遷移操作的同時需要將業(yè)務(wù)表中的連接狀態(tài)信息更新至目標(biāo)隊列上PFT的業(yè)務(wù)連接表中，上述策略可有效避免隊列過載，保障轉(zhuǎn)發(fā)器的處理性能，相關(guān)策略如算法1所示.

算法1. 基于負(fù)載感知的隊列任務(wù)調(diào)整策略.

① fori=1→N

② forj=1→Nsamdo

④ end for

⑧ else

⑩flow_sort(Lo,Lno)；

4 控制器

控制器是HVLB系統(tǒng)的管理核心，負(fù)責(zé)虛擬服務(wù)配置、NF選擇與調(diào)度策略制訂等.此外，控制器還負(fù)責(zé)各類信息監(jiān)測與分析.

4.1 信息監(jiān)測與統(tǒng)計分析

1) 轉(zhuǎn)發(fā)器工作狀況監(jiān)測.HVLB系統(tǒng)需要并發(fā)處理大量業(yè)務(wù)數(shù)據(jù)，在實際處理過程中，CR需要實時掌握各FR的工作狀況，包括各處理隊列上的負(fù)載情況等.CR通過與FR的SIT之間的消息接口進(jìn)行信息交互并對相關(guān)信息進(jìn)行分析，進(jìn)而按照負(fù)載狀況及處理情況對各FR進(jìn)行排序.當(dāng)NFV管理系統(tǒng)發(fā)起負(fù)載均衡服務(wù)請求時，CR將參考上述列表內(nèi)容，從中選擇理處理能力相對較強的FR進(jìn)行服務(wù).當(dāng)某個FR處于嚴(yán)重過載或者網(wǎng)絡(luò)不可達(dá)時，CR會及時將流量轉(zhuǎn)移至其他FR或通知NFV管理系統(tǒng)啟動新的FR實例.限于篇幅，相關(guān)內(nèi)容本文不作詳述.

2) 網(wǎng)絡(luò)鏈路狀況監(jiān)測.業(yè)務(wù)鏈中的各NF通過虛擬化網(wǎng)絡(luò)建立數(shù)據(jù)傳輸連接，虛擬化環(huán)境的傳輸特性決定了相關(guān)鏈路狀況變化的不確定性，通過與NFV管理系統(tǒng)的接口，CR對各FR至不同NF間的網(wǎng)絡(luò)鏈路狀況進(jìn)行監(jiān)測，以制訂準(zhǔn)確的調(diào)度策略.

3) NF計算資源使用狀況監(jiān)測.目標(biāo)NF可能為多條業(yè)務(wù)鏈所共用，因此其計算資源的使用情況也在不斷變化中，而計算資源使用狀況對NF網(wǎng)絡(luò)性能有著重要影響，需要實時監(jiān)測NF計算資源狀況.

4) 業(yè)務(wù)連接信息維護(hù).CR統(tǒng)一管理和維護(hù)所有FR數(shù)據(jù)處理信息.并將同一虛擬服務(wù)的業(yè)務(wù)連接表進(jìn)行聚合，然后重新分發(fā)至各FR上.因此每個FR可以實時維護(hù)其他FR上同一虛擬服務(wù)的業(yè)務(wù)連接信息.當(dāng)FR發(fā)生故障時，可以將業(yè)務(wù)流實時調(diào)整至其他FR進(jìn)行處理，保障業(yè)務(wù)數(shù)據(jù)的傳輸.

4.2 基于綜合能力反饋的NF選擇與調(diào)度

完成虛擬服務(wù)配置后，CR為FR上每一個虛擬服務(wù)制訂調(diào)度和轉(zhuǎn)發(fā)策略，進(jìn)而將業(yè)務(wù)數(shù)據(jù)分發(fā)至不同的目標(biāo)NF處理.在NFV典型應(yīng)用場景中，NF選擇首先要保障不會引入新的性能處理瓶頸，主要考慮2方面的因素：1)虛擬化傳輸過程中引入的固有開銷以及數(shù)據(jù)中心網(wǎng)絡(luò)中的流量干擾，使得各NF與轉(zhuǎn)發(fā)器之間的網(wǎng)絡(luò)鏈路狀況變化明顯，直接影響數(shù)據(jù)的轉(zhuǎn)發(fā)性能[19-20]；2)各NF可能同時被不同業(yè)務(wù)鏈復(fù)用而導(dǎo)致計算資源的競爭，進(jìn)而影響其網(wǎng)絡(luò)性能[26-28].基于上述分析，控制器采用基于綜合能力反饋的NF選擇與調(diào)度策略，包括網(wǎng)絡(luò)傳輸能力和計算能力2部分.表3為相關(guān)變量及符號釋義對照表.

Table 3 Key Notations in the CR表3 控制器處理過程主要符號釋義

4.2.1 網(wǎng)絡(luò)傳輸能力計算與篩選

(5)

4.2.2 NF計算處理能力計算與篩選

(6)

i=1,2,…,N-k，

4.2.3 調(diào)度及分發(fā)策略制訂

(7)

對計算出的偏移率φi和ηi進(jìn)行加權(quán)處理，即：

ai=γ×φi+(1-γ)×ηi,

(8)

i=1,2,…,N-k-r，

其中，γ為常數(shù)，默認(rèn)值γ=0.5.按照不同nfi對應(yīng)ai值的大小，進(jìn)一步分別為各nfi計算業(yè)務(wù)轉(zhuǎn)發(fā)比例λi，用以指導(dǎo)數(shù)據(jù)轉(zhuǎn)發(fā)，即有

(9)

完成上述過程后，控制器將該虛擬服務(wù)對應(yīng)的各nfi業(yè)務(wù)轉(zhuǎn)發(fā)比例值進(jìn)行匯總，進(jìn)一步計算nfi在選擇比例范圍tri如下：隨即更新各轉(zhuǎn)發(fā)器的虛擬服務(wù)配置信息中的reserved字段數(shù)值.FR在進(jìn)行調(diào)度處理時，只需按照隨機數(shù)計算結(jié)果進(jìn)行匹配即可(參考2.2節(jié)).

(10)

上述調(diào)度策略參見算法2.

算法2. 基于綜合能力的目標(biāo)NF選擇策略.

①Pc=?,A=?,k=0,ηi=0,num=N；

② fori=1→N

③ forj=1→Mido

⑤ end for

⑥ end for

⑧ fori=1→N-k

⑩ end for

5 部署與性能分析

HVLB核心作用在于為NFV提供高效的負(fù)載均衡數(shù)據(jù)分發(fā)，其處理性能可能受到多種因素的影響，包括處理隊列及分配的CPU數(shù)量、NUMA節(jié)點資源分配情況以及處理的數(shù)據(jù)包類型等.本節(jié)對HVLB的處理性能進(jìn)行全面評估.為了便于比較，我們搭建了原型系統(tǒng)實驗平臺，包括8臺物理服務(wù)器S1～S6，C1和C2，在S1上建立4個虛擬機V1，V2，V3，V4，其中V1運行HVLB轉(zhuǎn)發(fā)器，V2運行性能對比系統(tǒng)，V3運行HVLB控制器，V4作為控制器備份.在S2～S6上建立多個虛擬機，用來模擬備選NF集群.在C1和C2上部署和安裝測試工具PktGen-DPDK[29]和Thrulay[30].實驗過程中由C1和C2單獨或同時發(fā)送請求至HVLB轉(zhuǎn)發(fā)器.令轉(zhuǎn)發(fā)器和NF處于同一虛擬子網(wǎng)，并設(shè)置FR為NF網(wǎng)關(guān)，實驗配置參數(shù)如表4所示：

Table 4 Configuration of the Experiment Platform表4 實驗平臺配置

5.1 HVLB單機處理性能

首先來看轉(zhuǎn)發(fā)器的單機處理性能，我們在V2上部署業(yè)界廣泛采用的LVS[9]進(jìn)行性能對比.LVS系統(tǒng)可以靈活地部署于虛擬化環(huán)境中，但其數(shù)據(jù)轉(zhuǎn)發(fā)處理依賴Linux內(nèi)核進(jìn)行.為公平起見，我們同時為V1和V2分別配置基于SR-IOV的虛擬功能VF1和VF2，保證實驗過程中2個系統(tǒng)的數(shù)據(jù)收發(fā)均能跨越Hypervisor而直接到達(dá)各自虛擬網(wǎng)卡，并同時保證CPU和內(nèi)存資源處于相同NUMA節(jié)點.進(jìn)而對比HVLB和LVS處理不同類型、不同大小的數(shù)據(jù)包時的網(wǎng)絡(luò)性能.

5.1.1 單處理隊列性能

首先來看單處理隊列的情況，此時HVLB轉(zhuǎn)發(fā)器工作在最低配置情況：一個PFT通過虛擬機vCPU綁定1個物理CPU核，SIT綁定1個CPU核，實驗中為LVS系統(tǒng)配置相同數(shù)量的CPU核.用PktGen均勻發(fā)送2種類型的UDP數(shù)據(jù)包并逐漸增大到線速，大小從64～1 518 B變化.第1種為Constant 5-tuple類型，簡稱UDP-C，此時發(fā)包工具均勻產(chǎn)生1條業(yè)務(wù)流，所有的數(shù)據(jù)包具有相同的五元組；第2種為Independent 5-tuple類型，簡稱UDP-I，發(fā)送數(shù)據(jù)包時不斷改變源IP地址和發(fā)送端口，因此各數(shù)據(jù)包對應(yīng)不同的五元組值.

Fig. 7 The network performance under single queue圖7 單處理隊列網(wǎng)絡(luò)性能

吞吐量性能實驗結(jié)果如圖7(a)所示，橫軸為數(shù)據(jù)包尺寸大小，左邊縱軸為吞吐量(單位Gbps)，右邊縱軸為平均處理延遲.對于UDP-C類型數(shù)據(jù)包，HVLB的吞吐量性能遠(yuǎn)超LVS，以64 B小包為例，HVLB的最大吞吐量約為1.7 Gbps，約為LVS的3.8倍，其單核處理1 024 B數(shù)據(jù)包吞吐量性能已達(dá)到網(wǎng)卡飽和處理值10 Gbps.相應(yīng)地，LVS處理各個尺寸大小的數(shù)據(jù)包均無法達(dá)到或者接近10 Gbps.對于UDP-I類型數(shù)據(jù)包，HVLB的處理64 B數(shù)據(jù)包吞吐量約為1.48 Gbps，為LVS的5.9倍，但是略低于處理UDP-C類型數(shù)據(jù)的性能，這是因為UDP-I類型每個數(shù)據(jù)包的五元組信息各不相同，每個數(shù)據(jù)包處理都要進(jìn)行業(yè)務(wù)連接表查詢以及新表項建立操作，引入額外的處理開銷.對于UDP-C類型數(shù)據(jù)而言，業(yè)務(wù)連接表中已存儲相關(guān)信息，只需進(jìn)行查詢操作.

平均延遲性能實驗結(jié)果如圖7(b)所示，對于UDP-C和UDP-I類型數(shù)據(jù)包，在單核大尺寸數(shù)據(jù)包(512～1 518 B)場景下，HVLB和LVS的延遲性能差距并不明顯，隨著數(shù)據(jù)包大小的減少，二者的差別越來越明顯，處理64 B小包時，對于UDP-C類型數(shù)據(jù)，LVS平均處理延遲約為HVLB的3倍；對于UDP-I類型的數(shù)據(jù)包，LVS平均處理延遲約為HVLB的2.4倍.從實驗結(jié)果分析可知，LVS基于Linux內(nèi)核處理數(shù)據(jù)，引入大量中斷、拷貝開銷，最終影響網(wǎng)絡(luò)性能.

Fig. 8 The network performance under multi-queues圖8 多處理隊列網(wǎng)絡(luò)性能

5.1.2 多處理隊列性能

分析多處理隊列下系統(tǒng)處理性能，實驗中為HVLB和LVS系統(tǒng)配置相同的計算資源和處理隊列，同時發(fā)送UDP-C和UDP-I兩種類型，大小為64 B的數(shù)據(jù)包，并保證為每個接收與處理隊列發(fā)送相同數(shù)量的業(yè)務(wù)流.結(jié)果如圖8(a)和圖8(b)所示，橫軸為處理與轉(zhuǎn)發(fā)核數(shù)量，左邊縱軸為數(shù)據(jù)轉(zhuǎn)發(fā)吞吐量(單位為Mpps)，右邊縱軸為平均處理延遲.對于UDP-C類型的數(shù)據(jù)包而言，隊列和相應(yīng)計算資源的增加增強了LVS系統(tǒng)的處理能力，在6和7個處理核時達(dá)到最大吞吐量性能約為3.4 Mpps，其隊列平均處理延遲約為574.5 μs；相應(yīng)地，HVLB系統(tǒng)在6個處理核(處理線程)時已達(dá)到線速14.88 Mpps；比LVS提升近4.4倍，隊列平均處理延遲為181.7 μs；對于UDP-I類型數(shù)據(jù)包而言，LVS和HVLB處理性能均低于前者.HVLB需要7個CPU才達(dá)到線速，平均延遲為386 μs；相比之下，LVS在7個處理核情況下達(dá)到的最大吞吐量性能僅為3 Mpps，平均延遲為1 187.5 μs，說明在大量業(yè)務(wù)數(shù)據(jù)并發(fā)的場景下，LVS的處理瓶頸仍然來源于內(nèi)核數(shù)據(jù)收發(fā)過程中的固有開銷.

5.2 NUMA分配策略對處理性能影響

在前面的實驗中，我們對轉(zhuǎn)發(fā)器的單機處理性能進(jìn)行了分析，本節(jié)將進(jìn)一步采用3.2.3節(jié)中的虛擬NUMA節(jié)點資源分配策略前后對系統(tǒng)性能的影響.實驗中令2～7個隊列上的PFT綁定不同NUMA節(jié)點資源.為簡單起見，當(dāng)隊列數(shù)量為偶數(shù)時，平均分配PFT至2個不同的NUMA節(jié)點的計算資源；當(dāng)隊列數(shù)量為奇數(shù)時，在平均分配基礎(chǔ)上隨機分配剩余PFT給某個NUMA節(jié)點，測試內(nèi)容和5.1.2節(jié)相同.

Fig. 9 The network throughput performance under different NUMA resource allocation strategies圖9 不同NUMA資源分配策略下吞吐量對比

實驗結(jié)果如圖9和圖10所示.在圖9的吞吐量性能對比中，對于UDP-C類型的數(shù)據(jù)包而言，對于沒有經(jīng)過優(yōu)化的跨NUMA節(jié)點(crossing NUMA nodes, CNN)情況下，吞吐量性能出現(xiàn)明顯下降，在6個處理隊列條件下，未經(jīng)過策略優(yōu)化和優(yōu)化后(crossing NUMA nodes optimization, CNNO)情況下分別為12.95 Mpps和14.47 Mpps，提升約11.7%，后者仍然略低于5.1.2節(jié)中單NUMA節(jié)點(single NUMA node, SNN)情況下的處理性能；對于UDP-I類型數(shù)據(jù)包而言，未經(jīng)過策略優(yōu)化和優(yōu)化后分別為10.55 Mpps和12.05 Mpps，提升約14.2%，同樣略低于單NUMA節(jié)點下的處理性能.

Fig. 10 The latency performance under different NUMA resource allocation strategies圖10 不同NUMA資源分配策略下延遲性能對比

從圖10中可以看出，相比吞吐量性能而言，跨NUMA節(jié)點分配(CNN)對延遲處理性能影響更為明顯，并且隨著處理隊列(處理與轉(zhuǎn)發(fā)核)的數(shù)量的增加而增大，在7個處理隊列時2種類型數(shù)據(jù)包的平均處理延遲分別達(dá)到了1 150 μs和2 149 μs.經(jīng)過NUMA策略優(yōu)化(CNNO)后，對應(yīng)2種數(shù)據(jù)包類型的平均處理延遲分別為239 μs和442 μs，略高于單NUMA節(jié)點情況(SNN)下的177 μs和391 μs.由上述結(jié)果可知，采用虛擬NUMA節(jié)點資源分配策略后，系統(tǒng)吞吐量和延遲性能均得到提升，但相對單NUMA節(jié)點情況仍有下降，原因是HVLB采用一個SIT，PFT和SIT間存在跨NUMA節(jié)點訪問開銷.

5.3 基于負(fù)載狀況感知的隊列QoS性能

在5.1～5.2節(jié)實驗中發(fā)送的測試數(shù)據(jù)在各隊列分布均勻，如果某些業(yè)務(wù)數(shù)據(jù)發(fā)送速率較高會造成部分隊列處理過載而引發(fā)性能下降.本文提出RSS-A策略來實現(xiàn)隊列間的處理均衡，本節(jié)將通過實驗驗證應(yīng)用該策略前后對系統(tǒng)性能的影響.我們使用C1和C2同時發(fā)送UDP-C類型64 B數(shù)據(jù)包至轉(zhuǎn)發(fā)器.轉(zhuǎn)發(fā)器配置為6個處理隊列(綁定6個處理與轉(zhuǎn)發(fā)核).通過改變源端口，在C1上構(gòu)造并為每個隊列生成10條業(yè)務(wù)流，并為每個隊列的業(yè)務(wù)流設(shè)置不同的增長速率，分別為0.02 Mpps，0.03 Mpps，0.04 Mpps，0.05 Mpps，0.06 Mpps和0.1 Mpps，顯然，隊列6負(fù)載最重；同時，由C2生成并均勻發(fā)送每個隊列10條業(yè)務(wù)流，增速為0.01 Mpps，令C1和C2逐漸增大發(fā)送速率.過載判決閾值因子ε=0.95，策略處理周期為1 s，測試周期為5 min，取樣次數(shù)為20，θh=0.5.

圖11(a)為各隊列達(dá)到穩(wěn)態(tài)時吞吐量性能情況，可以看出，在業(yè)務(wù)傳輸速率分布不均勻情況下(RSS without uniformity, RSS-WOU)，隊列6很快處于過載狀況，吞吐量性能受到較大影響，僅為10.89 Mpps；相應(yīng)地，應(yīng)用RSS-A策略情況后(RSS-A without uniformity, RSS-A)達(dá)到13.83 Mpps，且各隊列處理情況均勻，與圖8中分布均勻情況下(RSS with uniformity, RSS-U)的結(jié)果相比仍相差6.5%左右.其原因在于業(yè)務(wù)遷移過程中業(yè)務(wù)連接表更新等操作造成一定開銷.圖11(b)為各隊列吞吐量實時變化情況，可看出由于出現(xiàn)過載情況，隊列6接連出現(xiàn)2次業(yè)務(wù)遷移操作，使得隊列1和隊列2出現(xiàn)速率瞬時增加情況，最終達(dá)到處理飽和狀態(tài).

Fig. 11 The network throughput performance with or without the HVLB RSS-A mechanism圖11 應(yīng)用HVLB RSS-A策略前后吞吐量性能對比

5.4 NF選擇及調(diào)度策略性能分析

本節(jié)將對調(diào)度策略對網(wǎng)絡(luò)性能的影響進(jìn)行評估，實驗中選擇輪詢策略(RR)、Maglev-Hash策略[6]來和HVLB策略進(jìn)行對比，比較吞吐量及平均往返時延(RTT)變化情況.實驗采用Thrulay[30]工具產(chǎn)生60條TCP業(yè)務(wù)流，經(jīng)過HVLB處理后分發(fā)至S2～S6上的10個NF，轉(zhuǎn)發(fā)器和NFs間存在5條鏈路，鏈路固有RTT為2.2 ms,每條鏈路最大帶寬為600 Mbps，轉(zhuǎn)發(fā)器配置6個處理隊列，參考5.1.2節(jié)的結(jié)果，轉(zhuǎn)發(fā)器處理上述業(yè)務(wù)數(shù)據(jù)不會產(chǎn)生性能瓶頸，引入處理延遲約為0.2 ms.實驗在2種情況下進(jìn)行：1)穩(wěn)態(tài)情況，HVLB和NF之間鏈路無其他流量干擾，同時NFs上不運行其他程序；2)動態(tài)變化情況，用限流工具對S2,S4和HVLB間鏈路增加5 ms延遲，在S3,S5中NF所屬虛擬機上通過Sysbench[31]工具增加負(fù)載，使CPU占用率維持在75%～80%.

Fig. 12 Effect on network throughput under different scheduling strategies圖12 不同調(diào)度策略下吞吐量性能對比

實驗結(jié)果如圖12和13所示，圖12(a)和12(b)中，橫軸為時間，縱軸為測試業(yè)務(wù)流的總吞吐量；圖13(a)和13(b)中，橫軸為RTT值，縱軸為測試業(yè)務(wù)流RTT均值概率分布.可以看出，在穩(wěn)態(tài)情況下，3種調(diào)度策略下總吞吐量和RTT均值變化平穩(wěn)，總量維持在2 820 Mbps左右，RTT均值維持在2.5 ms左右；動態(tài)變化情況下，RR策略對應(yīng)總吞吐量值為1 901.9 Mbps，且抖動劇烈；平均RTT延遲為14.9 ms；Maglev-Hash策略對應(yīng)總吞吐量值為2 044.5 Mbps，抖動較之RR策略更為劇烈，RTT延遲約為11.9 ms.分析其原因在于RR策略固定地選擇鏈路狀況不佳或計算資源競爭嚴(yán)重的NF，其網(wǎng)絡(luò)性能受到影響較大；Maglev-Hash采取均勻選擇目標(biāo)NF方式，性能受到影響較小.采用HVLB策略后吞吐量為2 648.7 Mbps，相比RR和Maglev-Hash策略分別提升39.3%和29.6%，且波動平緩;RTT均值為6.8 ms，比另2種策略分別降低54.4%和42.9%.上述結(jié)果表明，HVLB的調(diào)度策略綜合考慮NF傳輸和計算能力，在保障網(wǎng)絡(luò)性能的前提下制訂準(zhǔn)確的NF選擇策略和分發(fā)比例.

Fig. 13 CDF for latency under different scheduling strategies圖13 不同調(diào)度策略下延遲性能對比

6 結(jié) 論

NFV為電信運營商提供了低成本、靈活高效的業(yè)務(wù)實施方式.作為其重要功能組件，負(fù)載均衡系統(tǒng)可實現(xiàn)準(zhǔn)確的業(yè)務(wù)分發(fā)處理，從而提供有力的服務(wù)質(zhì)量保障.本文設(shè)計實現(xiàn)了面向NFV的高性能負(fù)載均衡機制及系統(tǒng)HVLB，實現(xiàn)調(diào)度策略制訂和數(shù)據(jù)轉(zhuǎn)發(fā)的有效分離，在轉(zhuǎn)發(fā)端基于用戶空間實現(xiàn)多核多隊列高效數(shù)據(jù)處理架構(gòu)，保證各處理隊列之間的數(shù)據(jù)訪問隔離和任務(wù)處理均衡；在控制端將網(wǎng)絡(luò)鏈路和計算相結(jié)合的綜合能力作為目標(biāo)NF選擇和調(diào)度策略制訂依據(jù)，在業(yè)務(wù)準(zhǔn)確分發(fā)的基礎(chǔ)上保障了網(wǎng)絡(luò)性能.下一步研究工作將著眼于系統(tǒng)的容量擴展管理、容錯處理方面的改進(jìn)，并進(jìn)一步在大規(guī)模數(shù)據(jù)中心環(huán)境下進(jìn)行部署與試商用.

[1]ETSI-GS-NFV-002. 2014. Network functions virtualization (NFV): Architectural framework[OL].[2017-10-28]. http:www.etsi.orgdeliveretsi_gsnfv001_09900201.01.01_60gs_nfv002v010101p.pdf

[2]ETSI-GS-NFV-003. 2014. Network functions virtualisation: Terminology for main concepts in NFV[OL].[2017-07-12]. https:www.etsi.orgdeliveretsi_gsNFV001_09900301.02.01_60gs_NFV003v010201p.pdf

[3]Quinn P, Nadeau T. Service function chaining problem statement[OL]. Internet-Draft: IETF Secretariat, 2014 [2017-08-20]. https:www.ietf.orgarchiveiddraft-ietf-sfc-problem-statement-10.txt

[4]Mijumbi R, Serrat J, Gorricho J, et al. Network function virtualization: State-of-the-art and research challenges[J]. IEEE Communications Surveys and Tutorials, 2016, 18(1): 236-262

[5]ETSI-GS-NFV-SWA-001. 2014. Network functions virtualisation(NFV):Virtual network functions architecture[OL].[2017-01-08]. https:www.etsi.orgdeliveretsi_gsNFV-SWA001_09900101.01.01_60gs_nfv-swa001v010101p.pdf

[6]Eisenbud D E, Yi C, Contavalli C, et al. Maglev: A fast and reliable software network load balancer[C]Proc of ACM NSDI. New York: ACM, 2016: 523-535

[7]Patel P, Bansal D, Yuan L, et al. Ananta: Cloud scale load balancing[C]Proc of ACM SIGCOMM 2013. New York: ACM, 2013: 207-218

[8]Intel. DPDK: Intel data plane development kit[OL].[2016-12-27]. http:www.dpdk.org

[9]LVS. Linux Virtual Server[OL]. [2016-12-27]. http:www.linuxvirtualserver.org

[10]A10 Network. AX Series[OL].[2017-02-11]. http:www.a10networks.com

[11]Array Networks. Array networks[OL].[2017-02-12]. http:www.arraynetworks.com

[12]F5. BIG-IP[OL].[2017-02-17]. http:www.f5.com

[13]Barracuda. Load balancer application delivery controller[OL].[2017-02-23]. http:www.barracuda.com

[14]Load balancer. org Virtual Applicance[OL].[2017-02-23]. http:www.loadbalancer.org

[15]Haproxy. Haproxy Load Balancer[OL].[2017-02-27]. http:www.haproxy.org

[16]Nginx. Nginx[OL].[2017-04-25]. http:www.nginx.org

[17]Gandhi R, Liu Hongqiang, Charlie H, et al. Duet: Cloud scale load balancing with hardware and software[C]Proc of ACM SIGCOMM 2014. New York: ACM, 2014: 27-38

[18]Kang N, Ghobadi M, Reumann J, et al. Efficient traffic splitting on commodity switches[C]Proc of ACM CoNEXT. New York: ACM, 2015: 58-70

[19]Xu Fei, Liu Fangming, Jin Hai, et al. Prolog to managing performance overhead of virtual machines in cloud computing: A survey state of the art, and future directions[J]. Proceedings of the IEEE, 2014, 102(1): 11-31

[20]Li J, Sharma N K, Ports D R, et al. Tales of the tail: Hardware, OS, and application-level sources of tail latency[C]Proc of ACM SoCC 2014. New York: ACM, 2014: 1-14

[21]Dong Yaozu, Yang Xiaowei, Li Xiaoyong, et al. High performance network virtualization with SR-IOV[C]Proc of the 16th Int Symp on High Performance Computer Architecture (HPCA). Piscataway, NJ: IEEE, 2010: 1471-1480

[22]Makineni S, Iyer R, Sarangam P, et al. Receive side coalescing for accelerating TCPIP processing[C]Proc of the 13th Int Conf on High Performance Computing. Berlin: Springer, 2006: 289-300

[23]Intel. Ethernet Flow Director[OL]. [2017-02-17]. https:www.intel.comcontentwwwusenethernet-productsethernet-flow-director-video.html

[24]Han Sangjin, Jang Keon, Park KyoungSoo, et al. Packetshader: A GPU-accelerated software router[C]Proc of the ACM SIGCOMM Conf. New York: ACM, 2010: 195-206

[25]Hwang J, Ramakrishnan K K, Wood T, et al. NetVM: High performance and flexible networking using virtualization on commodity platforms[C]Proc of Networked Systems Design and Implementation. New York: ACM, 2014: 445-458

[26]Wang G,Ng T. The impact of virtualization on network performanceof Amazon ec2 data center[C]Proc of the 29th IEEE Int Conf on Computer Communications. Piscataway, NJ: IEEE, 2010: 1-9

[27]Shea R, Wang Feng, Wang Haiyang, et al. A deep investigation into network performance in virtual machine based cloud environments[C]Proc of the 33rd IEEE Int Conf on Computer Communications. Piscataway, NJ: IEEE, 2014: 1285-1293

[28]Xu Yunjing, Musgrave Z, Noble B D, et al. Bobtail: Avoiding long tails in the cloud[C]Proc of Networked Systems Design and Implementation. New York: ACM, 2013: 329-341

[29]GitHub. Traffic generator powered by DPDK[OL]. [2017-09-20]. https:github.comPktgenPktgen-DPDK

[30]Sourceforge. Thrulay-ng[OL]. [2017-10-12]. http:thrulay-ng.sourceforge.net

[31]Sourceforge. Sysbench[OL]. [2017-10-22]. http:sysbench.sourceforge.net

WangYuwei, born in 1980. PhD candidate. Senior engineer in the Institute of Computing Technology, Chinese Academy of Sciences. His main research interests include future network, virtualization technology and cloud computing.

LiuMin, born in 1976. Professor in the Institute of Computing Technology, Chinese Academy of Sciences. Her main research interests include mobile management, network measurement and mobile computing.

MaCheng, born in 1989. Master candidate in the Institute of Computing Technology, Chinese Academy of Sciences. His main research interests include cloud computing, next generation network and mobile computing.

LiPengfei, born in 1992. Master candidate in the Institute of Computing Technology, Chinese Academy of Sciences. His main research interests include cloud computing, next generation network and mobile computing.