基于預(yù)測模型及獨(dú)立訓(xùn)練節(jié)點(diǎn)的負(fù)載均衡策略①

陳大才,呂 立,高 岑,孫 詠

1(中國科學(xué)院大學(xué),北京 100049)

2(中國科學(xué)院 沈陽計(jì)算技術(shù)研究所,沈陽 110168)

1 引言

互聯(lián)網(wǎng)的高速發(fā)展使得上網(wǎng)用戶劇增,很多互聯(lián)網(wǎng)服務(wù)的日活躍量成指數(shù)增長.這就給服務(wù)器帶來了巨大的壓力.服務(wù)器必須升級以服務(wù)更多的用戶.同時(shí),近幾年互聯(lián)網(wǎng)越來越多的新“玩法”給服務(wù)器的并發(fā)訪問能力帶來了嚴(yán)峻的挑戰(zhàn).比如微信搶紅包、淘寶雙十一、春運(yùn)搶票等.2016年除夕夜發(fā)的紅包數(shù)量就達(dá)到了幾十億個(gè).對承載這些秒級數(shù)據(jù)和高并發(fā)響應(yīng)的的服務(wù)器的性能的需求可想而知[1].

如何提高服務(wù)器的并發(fā)訪問能力還是一個(gè)值得深入研究的課題.本文通過提出一種新型的負(fù)載均衡策略來提高服務(wù)器集群的整體處理效率,從而提高Web服務(wù)器的并發(fā)訪問能力.

2 研究現(xiàn)狀

多年來,負(fù)載均衡一直是服務(wù)端一個(gè)熱門的話題,新的策略和解決方案不斷的被提出,已經(jīng)從最初的只能通過靜態(tài)設(shè)置,到后來的可以根據(jù)集群運(yùn)行情況作出動(dòng)態(tài)分配,再到最后的自適應(yīng)策略等.已經(jīng)有很多的相關(guān)技術(shù)人員作出了不可磨滅的貢獻(xiàn)[1].其中,國外的許多企業(yè)和研發(fā)團(tuán)隊(duì)推出了很多較好的解決方案.Microsoft公司針對于集群的負(fù)載情況,提出了具有較高可伸縮性和可用性的網(wǎng)絡(luò)負(fù)載均衡技術(shù)(NLB)以及基于作用在多層集群網(wǎng)絡(luò)的中間件與網(wǎng)絡(luò)負(fù)載均衡的組件負(fù)載均衡技術(shù)(CLB)[2].IBM公司推出的Web Sphere[3]相關(guān)的一套強(qiáng)大的Web 應(yīng)用服務(wù)器,其提供了優(yōu)秀的集群解決方案以及卓越的負(fù)載均衡功能.Intel公司網(wǎng)擎系列中的負(fù)載均衡器采用的快速響應(yīng)算法[4].在國內(nèi),諸多高校也在致力于研究負(fù)載均衡策略,例如清華大學(xué)、國防科學(xué)技術(shù)大學(xué)、浙江大學(xué)等,其中具有代表性的有清華大學(xué)研發(fā)的可擴(kuò)展的Web服務(wù)器集群系統(tǒng),國防科技大學(xué)章文嵩博士主持開發(fā)的Linux虛擬服務(wù)器項(xiàng)目等[5].

3 最少響應(yīng)時(shí)間負(fù)載均衡策略

本文提出的算法根據(jù)當(dāng)前請求的請求類型計(jì)算出當(dāng)前每個(gè)服務(wù)器節(jié)點(diǎn)預(yù)計(jì)的響應(yīng)時(shí)間,并從中選擇一個(gè)擁有最少響應(yīng)時(shí)間的節(jié)點(diǎn),用該節(jié)點(diǎn)處理請求.

本算法適用于具有負(fù)載調(diào)度器、業(yè)務(wù)服務(wù)器池和共享存儲(chǔ)三層結(jié)構(gòu)的負(fù)載均衡集群結(jié)構(gòu)[6].

為了簡化模型,本文假設(shè)集群中的所有服務(wù)器節(jié)點(diǎn)都具有相同的硬件和軟件配置.

3.1 相關(guān)概念

負(fù)載調(diào)度器:負(fù)載均衡集群結(jié)構(gòu)中用來接收用戶請求并向后端服務(wù)器節(jié)點(diǎn)分發(fā)請求的節(jié)點(diǎn).

業(yè)務(wù)服務(wù)器:用于實(shí)際業(yè)務(wù)操作的服務(wù)器.

請求:用戶發(fā)送的 HTTP Request,如登錄請求、注冊請求等.

請求類型:請求的動(dòng)作,如登錄、注冊、購買商品等.響應(yīng):服務(wù)器處理完用戶請求后,反饋的結(jié)果.

請求處理時(shí)間:服務(wù)器從請求隊(duì)列中抓取請求進(jìn)行處理,并處理完成的時(shí)間.

請求響應(yīng)時(shí)間:請求從負(fù)載調(diào)度器發(fā)出后,直至接收到響應(yīng)所需要時(shí)間.

3.2 影響響應(yīng)時(shí)間因素的分析

在集群結(jié)構(gòu)中,影響單節(jié)點(diǎn)中響應(yīng)時(shí)間的因素大致有以下幾種:

(1)當(dāng)前服務(wù)器節(jié)點(diǎn)的性能情況[1]

如 CPU 、內(nèi)存、磁盤 IO、網(wǎng)絡(luò)帶寬情況.

當(dāng)前節(jié)點(diǎn)的性能決定了請求的處理時(shí)長.

(2)請求類型

不同類型的請求所需要做的操作步驟不同(如有的請求查詢數(shù)據(jù)庫較多,有的數(shù)學(xué)計(jì)算較多),所需要的資源也不同(如 CPU 密集型任務(wù)需要更多的處理機(jī)資源,IO 密集型任務(wù)需要更多的 IO 資源),進(jìn)而所需要的處理時(shí)間也不同.

例如登錄請求所做的操作一般比獲取用戶資料多,也更耗費(fèi)時(shí)間.

(3)請求隊(duì)列的總響應(yīng)時(shí)間

即當(dāng)前請求隊(duì)列中的所有請求都被處理完所需要的時(shí)間.

當(dāng)前請求隊(duì)列的總響應(yīng)時(shí)間決定了新請求多長時(shí)間之后才能被處理.

經(jīng)過上面的分析,本文提出了一種算法,通過使用以往的實(shí)際請求響應(yīng)時(shí)間及節(jié)點(diǎn)的負(fù)載情況等歷史數(shù)據(jù)進(jìn)行建模,然后預(yù)測新請求的響應(yīng)時(shí)間,從而選擇具有最少響應(yīng)時(shí)間的服務(wù)器節(jié)點(diǎn)來處理請求,達(dá)到所有請求都近似擁有最少響應(yīng)時(shí)間的目標(biāo),最終集群的總響應(yīng)時(shí)間就減少了.

3.3 算法描述

給每個(gè)服務(wù)器節(jié)點(diǎn)設(shè)置以下變量:

(1)當(dāng)前性能情況P

(2)預(yù)估處理等待時(shí)間Tw

用于標(biāo)記新請求可能需要等待多長時(shí)間才能被處理.

(3)預(yù)估響應(yīng)時(shí)間Rp

給每個(gè)請求設(shè)置以下變量:

(1)請求類型 Action 參數(shù)A

(2)請求的開始響應(yīng)時(shí)間Rstart

(3)請求的實(shí)際響應(yīng)時(shí)間Rr

(1)提取請求中的請求類型[7]

負(fù)載調(diào)度器收到用戶發(fā)送的請求,提取出其中的請求類型參數(shù)A.

(2)預(yù)測各節(jié)點(diǎn)的響應(yīng)時(shí)間

將請求類型參數(shù)A、各節(jié)點(diǎn)的當(dāng)前性能情況信息P和各節(jié)點(diǎn)的預(yù)估處理等待時(shí)間Tw輸入響應(yīng)時(shí)間預(yù)測模型中得出每個(gè)服務(wù)器節(jié)點(diǎn)預(yù)估的響應(yīng)時(shí)間.

(3)選擇具有最少響應(yīng)時(shí)間的服務(wù)器節(jié)點(diǎn)

負(fù)載調(diào)度器從上一步計(jì)算出的各節(jié)點(diǎn)預(yù)估響應(yīng)時(shí)間中選擇一個(gè)具有最少響應(yīng)時(shí)間的服務(wù)器節(jié)點(diǎn),并更新該節(jié)點(diǎn)的Rp值,將請求發(fā)送給該服務(wù)器節(jié)點(diǎn),并記錄該請求的開始響應(yīng)時(shí)間Rstart.

(4)處理請求并記錄實(shí)際響應(yīng)時(shí)間

服務(wù)器節(jié)點(diǎn)收到請求后,將請求放入請求隊(duì)列中.服務(wù)器節(jié)點(diǎn)從請求隊(duì)列中選取一條請求進(jìn)行處理.處理完成后,在響應(yīng)頭中添加當(dāng)前服務(wù)器節(jié)點(diǎn)的性能情況信息P′作為響應(yīng)頭,并將響應(yīng)回傳給負(fù)載調(diào)度器.

(5)使用實(shí)際響應(yīng)時(shí)間矯正響應(yīng)時(shí)間預(yù)測模型

負(fù)載調(diào)度器用收到響應(yīng)時(shí)的當(dāng)前時(shí)間Tn減去第 2步記錄的開始響應(yīng)時(shí)間Rstart,得到該請求的實(shí)際響應(yīng)時(shí)間Rr.負(fù)載調(diào)度器將該實(shí)際響應(yīng)時(shí)間Rr和第 2 步記錄的A、P、Tw放入響應(yīng)時(shí)間預(yù)測模型中,對預(yù)測模型進(jìn)行校正.

(6)更新預(yù)估處理等待時(shí)間Tw

更新預(yù)估處理等待時(shí)間為Tw=Rp–Rr,其中Rp等于服務(wù)器節(jié)點(diǎn)中當(dāng)前請求隊(duì)列中最末尾的一條記錄的預(yù)估響應(yīng)時(shí)間;Rr等于最近收到響應(yīng)的請求的實(shí)際響應(yīng)時(shí)間,也就是請求隊(duì)列中剛處理完的請求的實(shí)際響應(yīng)時(shí)間.兩者之差就是當(dāng)前請求隊(duì)列的總響應(yīng)時(shí)間.

(7)記錄結(jié)點(diǎn)當(dāng)前負(fù)載情況

負(fù)載調(diào)度器從收到的響應(yīng)頭中提取結(jié)點(diǎn)的當(dāng)前負(fù)載情況P′,更新變量P.

(8)給用戶發(fā)送響應(yīng)

負(fù)載均衡器從響應(yīng)頭中刪去負(fù)載均衡算法使用的信息,并將響應(yīng)發(fā)送給用戶.

圖1 集群結(jié)構(gòu)

3.4 提取請求中的請求類型

當(dāng)負(fù)載調(diào)度器接收到由用戶發(fā)送過來的請求時(shí),負(fù)載調(diào)度器會(huì)從請求中提取請求類型.

例如,從請求 http://www.example.com/login?userID=123456&pwd=s2a51s&timestamp=1400&verify=s45 f83f 中可以提取其請求類型為 login;從請求 http://www.example.com?action=signup&userID=123456 中可以提示其請求類型為 signup.

3.5 響應(yīng)時(shí)間預(yù)測模型

本算法通過使用機(jī)器學(xué)習(xí)算法建立響應(yīng)時(shí)間預(yù)測模型來預(yù)測請求的響應(yīng)時(shí)間.

通過 3.2 節(jié)的分析,本算法使用請求類型A、服務(wù)器節(jié)點(diǎn)的性能情況P、請求隊(duì)列的總響應(yīng)時(shí)間Tw作為輸入?yún)?shù),用請求響應(yīng)時(shí)間Rp作為輸出參數(shù).即有如下模型:

為了方便實(shí)驗(yàn),本文只選用了 CPU 占用率、內(nèi)存剩余量、磁盤 IO 讀寫速度、網(wǎng)絡(luò)讀寫速度等簡單的性能參數(shù).為了方便機(jī)器學(xué)習(xí),以上參數(shù)都使用標(biāo)準(zhǔn)化算法將他們轉(zhuǎn)換到一個(gè)數(shù)值范圍內(nèi).

為了減少負(fù)載調(diào)度器的計(jì)算開銷,將模型的訓(xùn)練階段的計(jì)算任務(wù)放到一個(gè)單獨(dú)的計(jì)算機(jī)中進(jìn)行,稱之為模型訓(xùn)練節(jié)點(diǎn).模型訓(xùn)練節(jié)點(diǎn)將模型訓(xùn)練好之后通過網(wǎng)絡(luò)將結(jié)果發(fā)送給負(fù)載調(diào)度器,負(fù)載調(diào)度器用它來預(yù)測響應(yīng)時(shí)間.

3.6 減少負(fù)載調(diào)度器的計(jì)算開銷

本算法為了提高任務(wù)調(diào)度的均衡性,給負(fù)載調(diào)度器增加了不少的額外計(jì)算開銷,而如果系統(tǒng)的額外開銷大于系統(tǒng)的優(yōu)化,那么很容易進(jìn)一步增加集群的負(fù)載.本算法的細(xì)節(jié)設(shè)計(jì)部分采用了以下幾種方法進(jìn)行優(yōu)化,以更大程度的減少負(fù)載調(diào)度器的計(jì)算開銷:

(1)將模型建立過程的計(jì)算任務(wù)放到一個(gè)獨(dú)立于負(fù)載調(diào)度器之外的計(jì)算機(jī)中執(zhí)行,這樣降低了負(fù)載調(diào)度器的計(jì)算量.

(2)當(dāng)處理完成的請求數(shù)達(dá)到一定數(shù)量后才矯正一次模型,而不是每一次處理完請求后都要矯正響應(yīng)時(shí)間預(yù)測模型,減少了頻繁訓(xùn)練模型帶來的計(jì)算量[8].

(3)隨著系統(tǒng)運(yùn)行時(shí)間的增加逐漸增大矯正模型的請求量閾值.

當(dāng)系統(tǒng)運(yùn)行足夠長時(shí)間之后,模型就變得非常穩(wěn)定了,所以就不需要頻繁矯正模型了.

4 實(shí)驗(yàn)驗(yàn)證

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

本文所使用的實(shí)驗(yàn)環(huán)境如下:

(1)服務(wù)器節(jié)點(diǎn)

數(shù)量:16;硬件:6G 內(nèi)存/2 核 4 線程 3.2 GHz CPU;軟件:CentOS 7 + Tomcat 8 + Redis + MySQL + kafka +商品秒殺系統(tǒng)(業(yè)務(wù)系統(tǒng)).

(2)負(fù)載調(diào)度器

數(shù)量:1;硬件:8G 內(nèi)存/4 核 8 線程 3.3 GHz CPU;軟件:CentOS 7 + Nginx[8,9]1.12 + 本文所講述的負(fù)載平衡算法模塊.

(3)模型訓(xùn)練節(jié)點(diǎn)

數(shù)量:1;硬件:4G 內(nèi)存/2 核 4 線程 2.2 GHz CPU;軟件:CentOS 7 + Python3 + Scikit-learn.

(4)用戶端

數(shù)量:2;硬件:4G 內(nèi)存/2 核 4 線程 2.2 GHz CPU;軟件:CentOS 7 + Java8 + JMeter.

4.2 實(shí)驗(yàn)過程

本實(shí)驗(yàn)使用JMeter[3]模擬用戶的高并發(fā)訪問請求;用商品秒殺系統(tǒng)作為實(shí)驗(yàn)中的基準(zhǔn)測試程序,該系統(tǒng)擁有完整的用戶登錄、注冊、管理模塊和商品瀏覽、搶購模塊;使用Scikit-learn[3]運(yùn)行機(jī)器學(xué)習(xí)程序.

本實(shí)驗(yàn)通過設(shè)置不同的并發(fā)量、不同的機(jī)器學(xué)習(xí)算法(決策樹 CART、向量機(jī)、KNN等算法)[10]、不同的服務(wù)器節(jié)點(diǎn)(4節(jié)點(diǎn)集群、8節(jié)點(diǎn)集群和16節(jié)點(diǎn)集群)來進(jìn)行不同組的實(shí)驗(yàn),采用傳統(tǒng)的 URL散列算法作為對照組,得出實(shí)驗(yàn)結(jié)果如圖2.

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

從實(shí)驗(yàn)結(jié)果可以看出,本算法適用于小規(guī)模集群、高并發(fā)請求的場景.對于小集群、低并發(fā)請求和大集群高并發(fā)的情況,負(fù)載調(diào)度器的額外開銷超過了系統(tǒng)的優(yōu)化,增加了系統(tǒng)的平均響應(yīng)時(shí)間;而小集群、高并發(fā)請求的情況下,由于集群中服務(wù)器節(jié)點(diǎn)的性能是集群中的性能瓶頸,本算法優(yōu)化了任務(wù)調(diào)度來均衡各服務(wù)器節(jié)點(diǎn)的性能,提高了集群的效率,降低了系統(tǒng)的平均響應(yīng)時(shí)間.

5 總結(jié)

本文通過使用機(jī)器學(xué)習(xí)算法建立了響應(yīng)時(shí)間預(yù)測模型對請求的響應(yīng)時(shí)間進(jìn)行預(yù)估,并使用最少響應(yīng)時(shí)間策略進(jìn)行負(fù)載調(diào)度,提高了小集群高并發(fā)場景下系統(tǒng)的效率.通過實(shí)驗(yàn)驗(yàn)證了本算法對減少集群的平均響應(yīng)時(shí)間具有一定的效果.