面向網絡功能虛擬化的高性能負載均衡機制

王煜煒 劉 敏 馬 誠 李鵬飛

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

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

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

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

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

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

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

1) 設計實現基于控制與轉發處理分離的負載均衡處理架構，實現調度策略制訂和數據轉發的有效分離.同時，提出基于綜合能力反饋的NF選擇與調度策略，將網絡鏈路和NF計算資源使用狀況作為調度依據，有效減小業務數據分發處理過程中的開銷.

2) 針對虛擬化網絡環境下數據包傳輸與處理特點，基于網卡分流功能實現隊列處理功能硬件卸載，采用多核多隊列并發高效處理數據報文，并保證各處理隊列間的任務流量均衡，保障數據包的高效處理.

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

4) 基于KVM的虛擬化平臺部署并實現HVLB原型系統.在虛擬化環境下，HVLB單隊列和多隊列處理性能均遠遠優于主流開源軟件系統LVS(Linux virtual server)[9].針對UDP小尺寸數據包，在給定計算資源情況下，HVLB在萬兆網卡上達到了線速的處理與轉發性能.

1 相關工作

目前，負載均衡技術廣泛受到產業界和學術界的關注，現有工作主要分為3類:

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

Fig. 1 The architecture and working flow of HVLB圖1 HVLB架構及處理流程

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

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

綜上所述，現有研究工作無法直接應用于NFV虛擬化應用場景，且未充分考慮虛擬化環境下的網絡鏈路和業務鏈負載變化狀況對業務處理性能的影響，進而無法為業務系統提供高性能負載均衡服務.

2 概 述

2.1 架構與處理流程

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

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

2.2 虛擬服務配置與管理

HVLB旨在為NFV業務提供業務負載分擔，盡可能減少網絡傳輸和處理瓶頸.作為特殊的網絡功能中間件，HVLB可為多個NF或多條業務鏈同時提供服務.因此，首先需要對其提供的服務進行標識和管理.

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

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

3 轉發器

3.1 概 述

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

Table 1 The Structure of the Connection Table表1 業務連接表結構

HVLB同時支持TCP和UDP傳輸協議，對于無連接的UDP協議，FR對相同五元組的數據分發視同一次“連接”，通過維護其超時狀態來進行管理，超時時間默認為300 s，若超時之后仍然沒有后續相同五元組的數據包到來，則將相關表項刪除.

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

3.2 高速數據包處理

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

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

Fig. 3 The processing architecture of the FR圖3 轉發器處理架構

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

3.2.1 數據高效直通和零拷貝

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

3.2.2 隊列處理功能硬件卸載

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

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

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

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

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

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

2) 基于元數據的數據信息預處理

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

3.2.3 虛擬NUMA節點資源分配優化策略

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

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

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

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

3.2.4 基于隊列負載狀況感知的QoS保障

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

Table 2 Key Notations in the FR表2 轉發器器處理過程主要符號釋義

(1)

(2)

(3)

(4)

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

算法1. 基于負載感知的隊列任務調整策略.

① fori=1→N

② forj=1→Nsamdo

④ end for

⑧ else

⑩flow_sort(Lo,Lno)；

4 控制器

控制器是HVLB系統的管理核心，負責虛擬服務配置、NF選擇與調度策略制訂等.此外，控制器還負責各類信息監測與分析.

4.1 信息監測與統計分析

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

2) 網絡鏈路狀況監測.業務鏈中的各NF通過虛擬化網絡建立數據傳輸連接，虛擬化環境的傳輸特性決定了相關鏈路狀況變化的不確定性，通過與NFV管理系統的接口，CR對各FR至不同NF間的網絡鏈路狀況進行監測，以制訂準確的調度策略.

3) NF計算資源使用狀況監測.目標NF可能為多條業務鏈所共用，因此其計算資源的使用情況也在不斷變化中，而計算資源使用狀況對NF網絡性能有著重要影響，需要實時監測NF計算資源狀況.

4) 業務連接信息維護.CR統一管理和維護所有FR數據處理信息.并將同一虛擬服務的業務連接表進行聚合，然后重新分發至各FR上.因此每個FR可以實時維護其他FR上同一虛擬服務的業務連接信息.當FR發生故障時，可以將業務流實時調整至其他FR進行處理，保障業務數據的傳輸.

4.2 基于綜合能力反饋的NF選擇與調度

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

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

4.2.1 網絡傳輸能力計算與篩選

(5)

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

(6)

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

4.2.3 調度及分發策略制訂

(7)

對計算出的偏移率φi和ηi進行加權處理，即：

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

(8)

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

其中，γ為常數，默認值γ=0.5.按照不同nfi對應ai值的大小，進一步分別為各nfi計算業務轉發比例λi，用以指導數據轉發，即有

(9)

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

(10)

上述調度策略參見算法2.

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

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

5.1 HVLB單機處理性能

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

5.1.1 單處理隊列性能

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

Fig. 7 The network performance under single queue圖7 單處理隊列網絡性能

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

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

Fig. 8 The network performance under multi-queues圖8 多處理隊列網絡性能

5.1.2 多處理隊列性能

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

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

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

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

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

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

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

5.3 基于負載狀況感知的隊列QoS性能

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

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

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

5.4 NF選擇及調度策略性能分析

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

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

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

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

6 結 論

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

[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.