張穎楠，顧乃杰，彭建章，王國澎，魏振偉

一種內(nèi)核級多進(jìn)程負(fù)載均衡會話保持方法

張穎楠1a,1b,1c，顧乃杰1a,1b,1c，彭建章1a,1b,1c，王國澎2，魏振偉1a,1b,1c

(1. 中國科學(xué)技術(shù)大學(xué) a. 計算機(jī)科學(xué)與技術(shù)學(xué)院；b. 安徽省計算與通訊軟件重點(diǎn)實(shí)驗(yàn)室； c. 中國科學(xué)技術(shù)大學(xué)中科院沈陽計算所網(wǎng)絡(luò)與通信聯(lián)合實(shí)驗(yàn)室，合肥 230027；2. 國家高性能集成電路設(shè)計中心，上海 201204)

針對多進(jìn)程負(fù)載均衡無法保持會話的問題，提出一個基于epoll機(jī)制的內(nèi)核級高效解決方法。對于每個新建立的連接，在epoll的通知機(jī)制中使用源地址哈希算法，由epoll通知哈希選出的進(jìn)程接收此連接，期望通過為同一個IP地址的請求選擇同一個負(fù)載均衡服務(wù)進(jìn)程，保證該進(jìn)程依據(jù)自身記錄的會話信息將同一個客戶的請求轉(zhuǎn)發(fā)給同一個后端服務(wù)器。此外，通過分析多隊列網(wǎng)卡的特性，給出維持收包發(fā)包中斷、軟中斷、協(xié)議棧處理、用戶態(tài)處理都在同一個核上的優(yōu)化方法，以提高cache性能。實(shí)驗(yàn)結(jié)果表明，該方法能解決基于epoll的多進(jìn)程負(fù)載均衡服務(wù)器的會話保持問題，并且在多核處理器多隊列網(wǎng)卡環(huán)境下通過優(yōu)化使cps提高12%，數(shù)據(jù)吞吐量提高4.6%。

多隊列網(wǎng)卡；多核；epoll機(jī)制；源地址哈希；會話保持

1 概述

網(wǎng)絡(luò)負(fù)載均衡[1]作為一種滿足大規(guī)模并發(fā)訪問服務(wù)的有效解決方案被廣泛使用。會話保持是網(wǎng)絡(luò)負(fù)載均衡服務(wù)器需要提供的重要功能，要求負(fù)載均衡服務(wù)器將攜帶相同會話信息的請求交給同一服務(wù)器處理。

為了充分利用多核處理器，現(xiàn)今的網(wǎng)絡(luò)負(fù)載均衡服務(wù)器一般采用多進(jìn)程并發(fā)模式。對于基于socket的負(fù)載均衡服務(wù)器，在多進(jìn)程服務(wù)模式下，多個進(jìn)程共享同一個socket，與該socket建立的連接被哪個進(jìn)程接收具有不確定性，客戶攜帶相同會話信息的多次請求被交由不同的進(jìn)程處理，由于每個負(fù)載均衡服務(wù)進(jìn)程分別保存各自的會話保持信息表，不能保證為同一客戶的請求選擇同一個后端服務(wù)器，因此無法做到會話保持。

由于攜帶同樣會話信息的請求來自同一客戶，本文提出了一種內(nèi)核級的解決方案，旨在通過為同一客戶請求選擇同一用戶態(tài)服務(wù)進(jìn)程處理來實(shí)現(xiàn)會話保持，在epoll[2]機(jī)制中基于源地址哈希選擇性地喚醒一個進(jìn)程服務(wù)，以實(shí)現(xiàn)同一IP的請求交給同一進(jìn)程處理，同時充分利用中斷親和性和進(jìn)程親和性對內(nèi)核協(xié)議棧及網(wǎng)卡的發(fā)包收包過程進(jìn)行優(yōu)化。

2 相關(guān)工作

針對多進(jìn)程并發(fā)負(fù)載均衡服務(wù)器的會話保持問題，一種很普遍的解決方案是多個進(jìn)程之間共享會話信息表，這種方式并發(fā)訪問的鎖操作會帶來較大的性能開銷，并且從單進(jìn)程向多進(jìn)程升級時需要修改程序框架。文獻(xiàn)[3]提出了一種方式，通過修改從內(nèi)核空間到用戶空間傳遞請求部分的邏輯，從偵聽狀態(tài)的socket請求接收等待隊列上選擇一個進(jìn)程，將連接請求傳遞到用戶空間，并保證同一個客戶的請求發(fā)給同一個用戶態(tài)服務(wù)進(jìn)程。這種方法可以實(shí)現(xiàn)會話保持，也不存在鎖操作，但現(xiàn)在大多數(shù)基于Linux的負(fù)載均衡服務(wù)器都是利用epoll機(jī)制高效地管理網(wǎng)絡(luò)I/O事件的，這種基于Linux epoll機(jī)制的服務(wù)器程序在多進(jìn)程模式下多會遇到驚群現(xiàn)象[4]，當(dāng)注冊事件發(fā)生時喚醒所有進(jìn)程競爭，最終結(jié)果也只有一個進(jìn)程成功，造成資源浪費(fèi)。而文獻(xiàn)[3]并沒有解決這種驚群問題。

針對Linux操作系統(tǒng)內(nèi)核中數(shù)據(jù)包接收和發(fā)送過程，有以下優(yōu)化手段：

針對單隊列網(wǎng)卡，谷歌公司提出了Linux內(nèi)核補(bǔ)丁RPS(Receive Packet Steering)[5]，用軟件模擬的方式實(shí)現(xiàn)了多隊列網(wǎng)卡所提供的功能。對數(shù)據(jù)流通過hash進(jìn)行歸類，將多核系統(tǒng)中數(shù)據(jù)接收時的負(fù)載分布在不同的核上，充分利用多核，提高網(wǎng)絡(luò)性能。

但RPS僅僅是把同一流的數(shù)據(jù)包分發(fā)給同一個核處理，這就有可能出現(xiàn)給該數(shù)據(jù)流分配執(zhí)行軟中斷的核與操作該數(shù)據(jù)流的用戶態(tài)程序所在的處理器核不一致，仍會對cache性能造成影響，因此在RPS的基礎(chǔ)上谷歌公司又提出了RFS(Receive Flow Steering)[6]配合RPS使用，確保操作該數(shù)據(jù)流的應(yīng)用程序與處理軟中斷在同一個核上，更加充分地利用cache。但RPS和RFS最適合在單隊列網(wǎng)卡環(huán)境下 使用。

除了對數(shù)據(jù)包接收過程性能的優(yōu)化，谷歌又提出了針對多隊列網(wǎng)卡數(shù)據(jù)包發(fā)送過程的優(yōu)化XPS(Transmit Packet Steering)[7]。

在發(fā)送數(shù)據(jù)包時，XPS會根據(jù)當(dāng)前發(fā)送過程所在的核來選擇對應(yīng)的硬件發(fā)送隊列，使得處理過程在同一個核上的數(shù)據(jù)包選擇相同的發(fā)送隊列，提高了cache的效率。但這種方法仍然會引起其他方面的cache行震蕩，也就是說，網(wǎng)卡發(fā)送完數(shù)據(jù)包向其中一個核發(fā)出中斷，這個核并不一定是處理數(shù)據(jù)包發(fā)送流程所在的核。

3 基于epoll的多進(jìn)程負(fù)載均衡器會話保持

3.1 Linux內(nèi)核的epoll機(jī)制

epoll[2]是一個異步事件的通知機(jī)制，可通知某個就緒的文件描述符事件，常用于網(wǎng)絡(luò)I/O事件管理。

用戶態(tài)程序通過epoll_create()創(chuàng)建epoll的句柄，即一個epoll監(jiān)控容器，維護(hù)需要監(jiān)控的socket事件；使用epoll_ctl()系統(tǒng)調(diào)用可以向容器中注冊某個sock上的監(jiān)控事件并設(shè)置回調(diào)函數(shù)；系統(tǒng)調(diào)用epoll_wait()將當(dāng)前進(jìn)程掛載在當(dāng)前容器的等待隊列上并進(jìn)入可中斷掛起狀態(tài)，等待已注冊事件發(fā)生后被喚醒。

在基于epoll機(jī)制的多進(jìn)程服務(wù)器模型中，多個進(jìn)程間共享偵聽狀態(tài)的socket，這些進(jìn)程都把該socket加入到epoll關(guān)注事件中，并阻塞在epoll_wait上等待監(jiān)控事件發(fā)生。

當(dāng)設(shè)備就緒即socket注冊事件發(fā)生時，調(diào)用設(shè)備等待節(jié)點(diǎn)上注冊的喚醒回調(diào)函數(shù)，把就緒事件加入到就緒隊列，并喚醒所有等待進(jìn)程，這些進(jìn)程在用戶態(tài)競爭后續(xù)accept操作，但最終只有一個進(jìn)程成功，這樣便會發(fā)生驚群現(xiàn)象[4]，造成資源浪費(fèi)。而且所有共享此偵聽狀態(tài)socket的進(jìn)程都被喚醒競爭此連接，最終成功建立連接的進(jìn)程并不確定，無法做到同一個客戶的請求交由同一個進(jìn)程處理?；谝陨戏治龊涂紤]，本文設(shè)計了在epoll喚醒回調(diào)機(jī)制中基于源地址哈希算法選擇性地喚醒一個服務(wù)進(jìn)程的方案。

3.2 基于源地址哈希的會話保持方案

本文期望可以按某種規(guī)則有選擇地喚醒其中一個進(jìn)程，而非全部，這樣既可以避免驚群現(xiàn)象，也可以在規(guī)則設(shè)計合適的情況下實(shí)現(xiàn)來自同一個客戶的請求交給同一個進(jìn)程處理的會話保持需求。

如圖1所示，本文采取對數(shù)據(jù)包源地址哈希來選擇進(jìn)程，在喚醒回調(diào)函數(shù)中進(jìn)行規(guī)則判斷，源地址哈希值落在某個等待進(jìn)程上，就會將就緒事件插入到該進(jìn)程的epoll就緒隊列中，并喚醒該進(jìn)程進(jìn)行后續(xù)的操作。采用數(shù)據(jù)包源地址哈希的方法選擇處理進(jìn)程使得來自同一個客戶的請求都交由同一個進(jìn)程處理，從而滿足會話保持的要求。

圖1 epoll機(jī)制中源地址哈希選擇喚醒進(jìn)程

對于存在某個進(jìn)程退出或者加入新的進(jìn)程共享同一個socket的情況，本文加入一致性哈希算法[8]來減弱這種情況發(fā)生時對會話保持的影響。

因此，根據(jù)一致性哈希算法，整個會話保持方案如下：

(1)構(gòu)造一致性哈希桶：對于同一個共享的socket，當(dāng)每個進(jìn)程向epoll容器中注冊該socket的關(guān)注事件時，由于每個進(jìn)程都擁有各自不同的epoll容器對象，因此將容器對象的地址值通過哈希映射到一個32位的鍵值上，也就是0~232-1次方的數(shù)值，可以把這個數(shù)值空間映射到一個首(0)尾(232-1)相接的圓環(huán)，如圖2所示。

圖2 一致性哈希算法在選擇進(jìn)程時的應(yīng)用場景

(2)源地址哈希映射數(shù)據(jù)包：當(dāng)有數(shù)據(jù)包到達(dá)時，根據(jù)數(shù)據(jù)包的源IP地址作哈希映射到同一個哈希數(shù)值空間中，即圖2圓環(huán)。

(3)選擇處理進(jìn)程：在為數(shù)據(jù)包選擇處理進(jìn)程時，從數(shù)據(jù)包計算所得哈希值出發(fā)，在環(huán)形空間中按順時針方向遇到的第一個進(jìn)程哈希節(jié)點(diǎn)所對應(yīng)的進(jìn)程即處理該數(shù)據(jù)包的進(jìn)程，如圖2虛線箭頭所指。

當(dāng)有新進(jìn)程加入或進(jìn)程退出時，影響范圍僅是很少部分，而非整個范圍的震蕩。

該方案包括2個哈希函數(shù)，分別為對進(jìn)程節(jié)點(diǎn)的哈希和對數(shù)據(jù)包源地址哈希，為了盡可能將進(jìn)程節(jié)點(diǎn)及數(shù)據(jù)包的哈希值分散到232即32位數(shù)值空間中，本文選擇如下RSS哈希[9]算法：

ComputeHash(input[], N);

其中，input[]為epoll容器對象的地址值或數(shù)據(jù)包的源IP地址；N為輸入數(shù)據(jù)的字節(jié)數(shù)。算法描述如下：

(1)當(dāng)系統(tǒng)啟動時，隨機(jī)生成一個320比特位的K，存 儲在數(shù)組中，數(shù)組每一個成員為一個字節(jié)，即K[0]K[1] K[2]…K[39]。

(2)初始化哈希結(jié)果值為0。

(3)對輸入的每一比特位循環(huán)，如果該位為1，則將結(jié)果值異或K最左邊的32位。

(4)左移一位K，進(jìn)入步驟(3)的下一輪循環(huán)。

4 性能優(yōu)化

本節(jié)針對多隊列網(wǎng)卡和多核環(huán)境對會話保持方案從收包發(fā)包流程方面做了優(yōu)化。

4.1 從網(wǎng)卡到用戶態(tài)程序接收數(shù)據(jù)包流程的優(yōu)化

多隊列網(wǎng)卡有多個硬件接收隊列，網(wǎng)卡在硬件層次直接對數(shù)據(jù)包使用哈希部件分流，放在不同的隊列中，多隊列網(wǎng)卡的哈希函數(shù)可以配置。既可以選擇對源目的IP地址和源目的端口作哈希，也可以配置為僅依據(jù)源目的IP地址計算哈希值的方式，比如intel82580網(wǎng)卡[9]。

在接收數(shù)據(jù)包的過程中，為了充分利用局部性原理，降低cache刷新頻率，提高其命中率，需要盡可能滿足如下條件：

(1)將特征相似的數(shù)據(jù)包分配給同一個CPU處理。

(2)同一個數(shù)據(jù)包的硬件中斷處理過程、軟中斷處理過程以及用戶態(tài)應(yīng)用程序接收處理數(shù)據(jù)包的過程在同一個核上。

基于上述條件，期望在多隊列網(wǎng)卡多核環(huán)境下，網(wǎng)卡硬件哈希為數(shù)據(jù)包選擇的接收隊列綁定的核與epoll的喚醒回調(diào)函數(shù)中源地址哈希選擇的處理進(jìn)程綁定的核是同 一個。

配置網(wǎng)卡使用僅對數(shù)據(jù)包源目的地址哈希的函數(shù)選擇隊列時，由于數(shù)據(jù)包目的地址不變，相當(dāng)于在網(wǎng)卡硬件層對數(shù)據(jù)包做源地址哈希，交給不同的硬件隊列。在這種配置下，將用戶態(tài)進(jìn)程綁定于固定的處理器核，利用中斷親和性為每個硬件隊列綁定唯一的處理器核，只需記錄下數(shù)據(jù)包硬中斷處理過程所在的核，向上傳遞，在epoll層次選擇同樣處理器核上的進(jìn)程喚醒，如圖3所示，這個進(jìn)程已然是源地址哈希選擇的結(jié)果，滿足會話保持的要求。

圖3 數(shù)據(jù)包接收過程中期望的接收隊列、CPU、進(jìn)程間狀態(tài)

本文結(jié)合第3節(jié)中的會話保持方案將數(shù)據(jù)包接收流程修改如下：

(1)網(wǎng)卡接收數(shù)據(jù)包經(jīng)過哈希落在某個硬件隊列上。

(2)網(wǎng)卡發(fā)出硬中斷給該隊列所綁定的CPU核，將數(shù)據(jù)包掛在該CPU的處理隊列上。

(3)記錄下處理硬中斷的CPU核存儲于skbuff(數(shù)據(jù)包在內(nèi)核態(tài)的存儲形式)，并觸發(fā)軟中斷過程執(zhí)行內(nèi)核協(xié)議棧的解析與處理。

(4)當(dāng)該數(shù)據(jù)包為SYN包并且sock處于LISTEN狀態(tài)時，拷貝數(shù)據(jù)包的CPU核到sock中，向上層傳遞此記錄，并觸發(fā)sock上掛載的設(shè)備等待隊列調(diào)用喚醒回調(diào)函數(shù)。

(5)在使用epoll機(jī)制的情況下，喚醒回調(diào)函數(shù)的主要工作是掛載就緒事件到就緒隊列并喚醒等待進(jìn)程。在選擇用戶態(tài)進(jìn)程喚醒時，根據(jù)下層記錄的處理器核，選擇性地只喚醒綁定在該核上的用戶態(tài)進(jìn)程。

(6)判斷當(dāng)前處理器核綁定的進(jìn)程：如果當(dāng)前處理器核上綁定了唯一的進(jìn)程，則喚醒該進(jìn)程；如果當(dāng)前處理器核綁定了不止一個進(jìn)程，則獲取數(shù)據(jù)包的源IP地址作哈希，根據(jù)哈希值從該處理器核綁定的所有進(jìn)程中選擇一個喚醒；如果當(dāng)前處理器核沒有綁定進(jìn)程，則將下一個處理器核作為當(dāng)前處理器核，重新執(zhí)行操作(6)。

4.2 從用戶態(tài)程序到網(wǎng)卡發(fā)送數(shù)據(jù)包流程的優(yōu)化

數(shù)據(jù)包發(fā)送過程包括：應(yīng)用程序?qū)㈨憫?yīng)數(shù)據(jù)包遞交給內(nèi)核；內(nèi)核網(wǎng)絡(luò)協(xié)議棧封裝數(shù)據(jù)包向下層遞送；選擇發(fā)送隊列；網(wǎng)卡發(fā)送隊列中斷處理。其中，網(wǎng)卡發(fā)送中斷處理的主要工作是刪除數(shù)據(jù)包或重發(fā)數(shù)據(jù)包，該中斷在網(wǎng)卡發(fā)送數(shù)據(jù)完數(shù)據(jù)包時觸發(fā)。

為了在發(fā)送數(shù)據(jù)包過程中充分利用多隊列網(wǎng)卡和多核環(huán)境，提高發(fā)送數(shù)據(jù)的局部性，最理想的情況是將上述一系列發(fā)送數(shù)據(jù)包的流程都放在同一個處理器核上，如圖4所示。關(guān)鍵就是要為數(shù)據(jù)包選擇合適的硬件發(fā)送隊列，使得硬件發(fā)送隊列中斷綁定的處理器核與數(shù)據(jù)包在內(nèi)核協(xié)議棧中處理過程所在的核為同一個。

圖4 數(shù)據(jù)包發(fā)送過程中期望的進(jìn)程、CPU、發(fā)送隊列間的狀態(tài)

使用中斷親和性綁定發(fā)送隊列到唯一的處理器核上，在此前提下，本節(jié)設(shè)計的發(fā)送隊列選擇方法如下：

(1)獲取當(dāng)前數(shù)據(jù)包內(nèi)核協(xié)議棧處理過程所在的 CPU核。

(2)判斷該CPU核上綁定的發(fā)送隊列個數(shù)。

(3)如果處理器核對應(yīng)唯一的發(fā)送隊列，則返回此隊列號——在這種情況下，硬件發(fā)送隊列發(fā)送成功或失敗后觸發(fā)中斷，中斷處理過程刪除數(shù)據(jù)包或重發(fā)數(shù)據(jù)包等操作都集中在之前發(fā)送過程的同一個核上完成。

(4)如果處理器核上綁定的隊列數(shù)大于1，則依據(jù)數(shù)據(jù)包的哈希值從綁定的隊列集合中選擇。

(5)如果處理器核上綁定的隊列數(shù)等于0，則依據(jù)數(shù)據(jù)包的哈希值從網(wǎng)卡所有可用隊列中選擇。

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

5.1 實(shí)驗(yàn)環(huán)境

為應(yīng)對壓力測試，需要提供高性能的服務(wù)器作為測試機(jī)，以使負(fù)載均衡處理不會成為瓶頸；選用多隊列網(wǎng)卡使數(shù)據(jù)包收發(fā)流程充分利用優(yōu)化特性。測試環(huán)境如表1所示。

表1 測試環(huán)境

5.2 會話保持測試

HAProxy為基于epoll的負(fù)載均衡軟件，存在多進(jìn)程會話不能保持的問題，本節(jié)選擇該軟件作為測試?yán)?。在不同的客戶端上使用curl工具向HAProxy監(jiān)聽的地址發(fā)送http請求，發(fā)現(xiàn)同一個客戶發(fā)送的請求交給了同一個進(jìn)程處理，表明實(shí)現(xiàn)了多進(jìn)程會話保持的目的。

同時利用測試儀環(huán)境測試請求處理轉(zhuǎn)發(fā)的正確性，圖5所示的測試結(jié)果表明，在壓力測試下，數(shù)據(jù)包處理的正確率為100%。

圖5 基于修改后內(nèi)核的數(shù)據(jù)包處理結(jié)果

5.3 性能測試

5.3.1 實(shí)驗(yàn)方法

為測試本文方法在大規(guī)模訪問壓力下并未限制整體性能相反有所提高，采用了如下實(shí)驗(yàn)方法：(1)關(guān)閉中斷負(fù)載均衡irqbalance服務(wù)；(2)內(nèi)核關(guān)閉RPS；(3)設(shè)置網(wǎng)卡中斷親和性：使網(wǎng)卡隊列與處理器核綁定；(4)設(shè)置進(jìn)程親和性：進(jìn)程分別綁定在不同的處理器核上；(5)測試儀配置：模擬100個客戶端，6個服務(wù)器端，1個負(fù)載均衡代理服務(wù)器HAProxy?？蛻舳送瑫r向HAProxy發(fā)送請求，測試HAProxy的響應(yīng)速度和吞吐量。

5.3.2 結(jié)果分析

每秒處理連接數(shù)(cps)反映測試程序HAProxy在當(dāng)前內(nèi)核及硬件平臺下處理請求的速度。圖6和圖7為cps的測試結(jié)果，縱軸表示每秒新增連接個數(shù)，橫軸為時間軸，基于本文修改后的內(nèi)核運(yùn)行HAProxy每秒處理請求數(shù)平均在93 000左右，而未修改2.6.35內(nèi)核下cps平均在83 000左右，表明修改后的內(nèi)核處理速度有12%的提升，更能充分利用多核和多隊列網(wǎng)卡硬件環(huán)境。吞吐量(throughout)表示每秒處理的數(shù)據(jù)總量。利用IxLoad測試儀模擬100個客戶端，向HAProxy請求大小為1 MB的數(shù)據(jù)。測試結(jié)果如 圖8和圖9所示，縱軸表示每秒處理的數(shù)據(jù)總量，橫軸為時間軸，在一段時間的試探期后數(shù)據(jù)會穩(wěn)定在一定范圍內(nèi)。修改前的內(nèi)核運(yùn)行HAProxy吞吐量基本都維持在2.2 Gb左右，修改后平均維持在2.3 Gb，提升在4.6%左右。

圖6 基于修改后內(nèi)核的每秒處理連接數(shù)

圖7 基于原2.6.35內(nèi)核的每秒處理連接數(shù)

圖8 基于修改后內(nèi)核的吞吐量

圖9 基于原2.6.35內(nèi)核的吞吐量

6 結(jié)束語

本文提出一種在epoll機(jī)制中根據(jù)數(shù)據(jù)包源地址哈希結(jié)果選擇性喚醒處理進(jìn)程的方法，有效地解決了基于epoll的多進(jìn)程負(fù)載均衡服務(wù)器的會話保持問題。與以往的研究工作相比，在滿足會話保持要求的同時解決了epoll機(jī)制在多進(jìn)程環(huán)境下多出現(xiàn)驚群現(xiàn)象的問題，而且基于修改后的內(nèi)核將單進(jìn)程的負(fù)載均衡服務(wù)向多進(jìn)程擴(kuò)展時也不需要大規(guī)模修改用戶態(tài)服務(wù)程序。此外，對多隊列網(wǎng)卡和多核處理器環(huán)境下的會話保持方案做了針對性優(yōu)化，實(shí)驗(yàn)結(jié)果顯示，優(yōu)化方案對于上述網(wǎng)絡(luò)環(huán)境有很好的性能提升。但本文的解決方法仍然基于共享的sock，在內(nèi)核態(tài)中共享的sock依舊會帶來互斥鎖的開銷，不利于網(wǎng)絡(luò)性能的進(jìn)一步提升。下一步工作的主要方向是期望解決多進(jìn)程偵聽在同一個地址上提供相同的服務(wù)時，如何能夠更有效地利用多核，減少內(nèi)核中鎖的開銷，提高并行性。

[1] 李 輝. 網(wǎng)絡(luò)服務(wù)器負(fù)載均衡的研究與實(shí)現(xiàn)[D]. 大連: 大連海事大學(xué), 2003.

[2] Libenzi D. Improving (Network) I/O Performance[EB/OL]. (2002-10-30). http://www.xmailserver.org/Linux-patches/nio- improve.html.

[3] Liu Xi, Pan Lei, Wang Chongjun, et al. A Lock-free Solution for Load Balancing in Multi-core Environment[C]//Proc. of the 3rd International Workshop on Intelligent Systems and Applications. Wuhan, China: [s. n.], 2011: 1-4.

[4] Molloy S P, Lever C. Accept() Scalability on Linux[C]//Proc. of USENIX Annual Technical Conference. San Diego, USA: [s. n.], 2000: 121-128.

[5] Herbert T. RPS: Receive Packet Steering[EB/OL]. (2010-09- 01). http://1wn.net/Articles/361440.

[6] Herbert T. RFS: Receive Flow Steering[EB/OL]. (2010-09-01). http://1wn.net/Articles/381955.

[7] Herbert T. XPS: Transmit Packet Steering[EB/OL]. (2010-10- 26). http://1wn.net/Articles/412062.

[8] Karger D, Lehman E, Leighton T, et al. Consistent Hashing and Random Trees: Distributed Caching Protocols for Relieving Hot Spots on the World Wide Web[C]//Proc. of the 29th Annual ACM Symposium on Theory of Computing. New York, USA: ACM Press, 1997: 654-663.

[9] Intel Corporation. Intel 82580EB/82580DB Gigabit Ethernet Controller Datasheet[EB/OL]. (2012-09-07). http://www.intel. com/content/www/us/en/ethernet-controllers/82580-eb-db-gbe-controller-datasheet.html.

[10] Ixia Corporation. IxLoad[EB/OL]. (2011-07-07). http://www. ixiacom.cn/products/applications/ixload.

[11] Tarreau W. HAProxy: The Reliable, High Performance TCP/ HTTP Load Balancer[EB/OL]. (2011-09-10). http://haproxy. 1wt.eu.

[12] 周少濤. 基于HAProxy的TCP長連接復(fù)用的研究與實(shí) 現(xiàn)[D]. 廣州: 華南理工大學(xué), 2011.

編輯 任吉慧

A Kernel Level Session-persistence Method for Multi-process Load Balancing

ZHANG Ying-nan1a,1b,1c, GU Nai-jie1a,1b,1c, PENG Jian-zhang1a,1b,1c, WANG Guo-peng2, WEI Zhen-wei1a,1b,1c

(1a. School of Computer Science and Technology; 1b. Anhui Province Key Laboratory of Computing and Communication Software; 1c. USTC&SICT Network and Communication Joint Laboratory, University of Science and Technology of China, Hefei 230027, China; 2. National High Performance IC Design Center, Shanghai 201204, China)

This paper proposes an efficient method at the kernel level to solve the problem how to maintain the session in multi-process load balancing. In the wakeup-callback mechanism of epoll, this method wakes up a certain service process selectively to process the packet and accept this connection according to the source address hash algorithm. It hopes that the requests sharing the same IP address are responded by the same service process. So the requests from the same client are forwarding to the same backend server according to the session information kept in this load balancing process. This paper also devotes to optimize the performance of the procedure of receiving and sending packets. It is an intended way to keep this whole process on the same CPU core to reduce the refresh rate of the CPU cache. Experimental results reflect that the method in this paper achieves the objective to keep the session and also increases cps by 12% and throughput by 4.6% which is based on multi-queue NIC and multi-core processor.

multi-queue network card; multi-core; epoll mechanism; source address hash; session-persistence

1000-3428(2014)03-0076-06

A

TP393.03

“核高基”重大專項(2009ZX01028-002-003-005)；高等學(xué)校學(xué)科創(chuàng)新引智計劃基金資助項目(B07033)。

張穎楠(1988－)，女，碩士、CCF會員，主研方向：網(wǎng)絡(luò)負(fù)載均衡；顧乃杰，博士、博士生導(dǎo)師；彭建章，博士；王國澎、魏振偉，碩士。

2013-03-19

2013-04-23 E-mail：zyn@mail.ustc.edu.cn

10.3969/j.issn.1000-3428.2014.03.016