楊杭，張昕，趙建平

（長春理工大學 計算機科學技術學院，長春 130022）

近年來，基于互聯(lián)網(wǎng)的各類應用服務已逐步深入到人類生產生活的各個方面，在開展服務過程中，大量的服務請求在單位時間內到達服務端，并要求后者以盡可能短的延遲完成對服務請求的應對處理。因此，服務端的吞吐能力直接影響了應用服務質量，其直接體現(xiàn)為支撐服務能力的服務器（集群）所具備的并發(fā)處理能力，較高的并發(fā)處理能力意味著同時單位數(shù)量的服務請求能夠在相對更短的時間內被應對處理［1］。作為一種提高并發(fā)處理能力的措施，負載均衡技術采用多點分發(fā)的方式實現(xiàn)對大量服務請求的均衡分組，使服務器集群中的多個工作服務器（按其在集群中發(fā)揮的作用可分別稱為“總控節(jié)點”和“工作節(jié)點”）各自獨立地對近似等量的服務請求實施接入，達成并行化的應對處理，從而降低服務請求的響應延遲，提高服務請求的接入效率。

本文提出基于動態(tài)反饋的負載均衡方法，通過動態(tài)反饋機制，實時收集各工作節(jié)點的運行情況，從而在服務請求接入過程中根據(jù)運行條件動態(tài)調整工作負載的分配方案，使各工作節(jié)點在可行的范圍內承擔相近的工作負載，避免負載分配不均衡。該方法能夠有效適應并發(fā)處理過程中的動態(tài)運行條件，具有較好的實時性和靈活性。

1 相關工作

最早的均衡機制是通過循環(huán)DNS（Domain Name System）實現(xiàn)的［2］，該機制通過DNS配置使一臺擁有域名的主機（稱為工作主機）具備多個映射地址，到達的用戶服務請求在與工作主機進行交互后，由后者采用輪詢方式將請求分配至特定的映射地址，即另外實際開展處理響應的服務單元，從而實現(xiàn)由不同服務單元對多個服務請求進行應對處理，在一定程度上達到了負載均衡的效果，但此種方式下的負載分配效率相對較低，且受限于網(wǎng)絡拓撲結構，因此其負載均衡效果并不太理想。

Nikolaou等人［3］通過研究認為，工作節(jié)點的資源實際利用率是達成更好負載均衡效果的核心因素，負載均衡方案的主要工作目標之一即是合理規(guī)劃工作負載的分配，使各工作節(jié)點的資源均等充分地發(fā)揮效能。Cardellini和 Bryhni［4］等人對多種負載均衡方法進行了對比研究，主要分析了基于客戶端、服務器、DNS以及中心分配器等負載均衡策略的優(yōu)缺點，比較了各種實現(xiàn)算法的性能，為負載均衡方法體系提供了有力支持。關于負載均衡的產品，目前國內外已經有不少公司在從事基于軟件和硬件的負載均衡產品研發(fā)。其中，基于軟件負載均衡的產品有LVS、Lander Balance和Check Point等［5］。

2 基于動態(tài)反饋的負載均衡方法

在面對用戶的大量并發(fā)服務請求時，實施負載均衡的核心任務是通過合理的任務調度安排策略，使得服務器集群在執(zhí)行服務任務過程中滿足來自總體完成時間、任務吞吐量、資源利用效率以及可擴展性等多方面的約束。本文提出的基于動態(tài)反饋的負載均衡方法，重點考慮工作節(jié)點自身負載狀況和接入任務情況的動態(tài)性，形成并發(fā)請求工作條件下的任務分配及執(zhí)行近優(yōu)解決方案。

本文主要圍繞以下四個方面構建負載均衡方法：

（1）節(jié)點參數(shù)：即各個工作節(jié)點即時的負載情況，包括運行隊列中的任務數(shù)目、系統(tǒng)調用的速率、空閑存儲器的大小等。

（2）評估決策：根據(jù)當前工作節(jié)點的負載情況評估是否需要將后續(xù)到達的任務分配轉移至其他工作節(jié)點并處理。本文中采用閾值限定的方式對待任務轉移進行判定。

（3）轉移位置：對于適合轉移到其他工作節(jié)點的任務，要明確任務轉移的目標工作節(jié)點。

（4）維持手段：確定可進行轉移的任務列表，進而通過任務傳輸實現(xiàn)負載調度，保持負載均衡。

圖1 負載均衡方法執(zhí)行流程

通過對上述四個方面進行綜合分析，首先對運行場景中的相關可用資源情況進行收集和識別，具體包括：可用的工作節(jié)點、節(jié)點的處理能力、可用的存儲空間和內存；然后分析和判斷當前接入任務的執(zhí)行情況，如果所有任務均已完成，則轉至等待新任務的接入；如果存有尚待完成的任務，則對任務需求進行分析，具體需求包括：任務的到達率、任務數(shù)量以及各項任務對內存的預計占用情況，并根據(jù)任務需求相應調整任務處理策略及參數(shù)；接下來采集各工作節(jié)點中任務運行隊列參數(shù)，以實現(xiàn)對當前處理性能的判斷，從而確定執(zhí)行負載均衡措施的邏輯起始節(jié)點及可行時間點；在此之后配置和執(zhí)行負載遷移方法，即選定需要遷出的任務條目及任務所在的工作節(jié)點，并將其遷入另外的工作節(jié)點；接下來識別是否有新的任務等待接入，如果有新任務，則轉至之前對運行場景中可用資源情況的收集和識別，并執(zhí)行后續(xù)的相應流程；如果沒有新任務，則完成當前負載均衡方法的執(zhí)行，如圖1所示。

2.1 動態(tài)反饋策略

針對并發(fā)處理過程的實際情況，本文提出了面向全局均衡質量的工作情況動態(tài)反饋策略，綜合考慮負載均衡場景的關鍵要素及其相互作用。在開展請求接入和服務響應的過程中，持續(xù)采集和分析各工作節(jié)點負載情況，重點圍繞全局的負載均衡質量執(zhí)行相應任務處理，結合動態(tài)反饋方式，保持均衡措施的合用和有效。

本文參考了控制論中的反饋原理動態(tài)地分析工作節(jié)點當前的運行狀況，評估負載指標，進而調整和規(guī)劃任務負載均衡的方案，保障工作性能的持續(xù)有效，如圖2所示。

圖2 基于動態(tài)反饋的評估機制

本文以各節(jié)點的工作狀態(tài)作為出發(fā)點對其資源占用情況進行持續(xù)評估，并分析任務執(zhí)行過程中的各種特征數(shù)據(jù)，持續(xù)評估實施負載均衡方案后的服務器集群系統(tǒng)性能，相應調整任務分配方案。其具體的評估任務包括兩項：

（1）對工作節(jié)點的負載情況評估；

（2）根據(jù)負載情況評估，制定負載閾值設定策略，并根據(jù)評估結果對閾值進行動態(tài)調整。

節(jié)點負載情況評估主要包括對工作節(jié)點自身情況的評估和對各節(jié)點間交互情況的評估，其對應的工況指標參數(shù)分別是：

其中，idle表示在對應時間點CPU的空閑時間，cpu表示相應的CPU總運行時間。

其中，用MemTotal表示RAM總共的物理空間，用MemFree表示未使用的內存。

綜上，在完成對工作節(jié)點內各部件工作情況評估的基礎上，節(jié)點工況指標表達為：

其中，σ代表對應部件在評估中所占的衡量權重，稱為部件性能權重，上述各部件工況指標均采用使用率表達，其取值范圍為0%至100%，0%代表該部件未被使用，100%代表該部件已達到滿負載工作狀態(tài)。

相應的節(jié)點交互工況指標表達為：

其中，m為當前工作節(jié)點保持與其他節(jié)點連接的總數(shù)表示當前工作節(jié)點與標識編號為k的其他節(jié)點的連通交互情況，如果存在交互連通（即connected），其取值為1，否則（即disconnected）為0。

通過上述指標，對每個工作節(jié)點的負載指標評估表達為：

其中，θ表示對應指標在評估中所占的衡量權重，稱為節(jié)點性能權重。

通過上述計算過程，可根據(jù)上述工作節(jié)點的負載指標評估結果構建調度策略。其中，設定兩個閾值作為調度決策參數(shù)，分別為δ1和δ2，并且δ1＜δ2。

綜合分析公式（3）、（4）、（5）可以得知，由變量標識S表征的指標參數(shù)直接反映了相關部件以及交互活動在負載均衡過程中的負載情況，部件性能權重σ和節(jié)點性能權重θ反映了各項負載情況在負載均衡方案中的關鍵程度。因此，上述公式中權重參數(shù)的設定能夠將負載均衡任務場景引入到調度方案中，其取值主要來源于數(shù)據(jù)中心管理人員的經驗設定，并通過長時間的運行積累逐步形成穩(wěn)定配置。另外，通過實際工作中積累的經驗和對服務器系統(tǒng)性能表現(xiàn)的分析，推薦的調度決策初始參數(shù)（即δ1和δ2）取值分別設定為0.5和0.8。

在負載均衡運行過程中，需要通過連續(xù)且持續(xù)的負載參數(shù)采集，形成周期性的負載指標評估，根據(jù)負載均衡方案運行的具體場景，可對采集周期進行調整，以減小由頻繁評估參數(shù)采集造成的系統(tǒng)性能降低和能量損耗。根據(jù)實際工作經驗表明，評估參數(shù)的采集周期可根據(jù)服務請求頻度相應設定在10秒至90秒之間。

在基于動態(tài)反饋策略執(zhí)行負載均衡措施過程中，經分析發(fā)現(xiàn)，引發(fā)集群中任務動態(tài)調整進而帶動反饋動作的情況主要發(fā)生在新加入任務的實時載入、網(wǎng)絡帶寬情況的實時動態(tài)變動以及各工作節(jié)點即時的負載能力調整等三個場景中。

在新任務載入階段，如果有新的工作節(jié)點被納入到負載均衡系統(tǒng)方案中，此類工作節(jié)點的加入基本不會對整體任務規(guī)劃和集群性能表現(xiàn)產生消極影響。新加入的工作節(jié)點會被優(yōu)先配置執(zhí)行完成時間相對較短的任務，并按照上述策略執(zhí)行相應反饋措施。

2.2 負載均衡任務調度

在執(zhí)行負載均衡解決方案的服務器集群中，其總控節(jié)點部署的負載均衡算法綜合考慮所有工作節(jié)點的實時負載情況和處理性能，不斷調整任務分布的比例，避免任務分配不平衡造成的各種問題。由于負載均衡處理的任務量隨時間動態(tài)變化，通過對閾值的動態(tài)調整，使各工作節(jié)點工作情況大致等于負載閾值，實現(xiàn)任務均衡分配并充分發(fā)揮各工作節(jié)點的處理效能。

圖3 負載均衡工作過程

負載均衡的具體工作過程為（參見圖3）：

（1）在總控節(jié)點開展負載均衡管理，根據(jù)現(xiàn)有的節(jié)點工作情況和負載均衡閾值，分析系統(tǒng)負載情況；

（2）通過節(jié)點之間的連接，總控節(jié)點將工作任務分配至各個工作節(jié)點；

（3）各工作節(jié)點對接收到的任務進行處理；

（4）收集各個工作節(jié)點的實時負載狀態(tài)信息；

（5）根據(jù)收集的負載狀態(tài)信息，計算和評估各節(jié)點工作情況；

（6）對比節(jié)點的工作情況和負載均衡閾值，根據(jù)預設的均衡策略，在后續(xù)的負載均衡管理中相應調整負載均衡閾值。

在負載均衡工作過程的信息收集階段，總控節(jié)點對其他工作節(jié)點的實時運行情況信息進行收集，收集的信息主要包括所在節(jié)點的負載情況、任務分配情況、響應速度等信息。收集過程根據(jù)策略以及實際情況，一般情況下都是周期性的機制。比較常用的機制是工作節(jié)點周期性地向總控節(jié)點發(fā)送信息，工作節(jié)點利用心跳機制周期性的向總控節(jié)點發(fā)送狀態(tài)信息，保證總控節(jié)點掌握較新的工作節(jié)點狀態(tài)，并使前者以此判斷工作節(jié)點是否存在。

周期性的信息收集方式實現(xiàn)起來較為簡單，但是所存在的問題也相對較為明顯。首先，周期性的信息傳輸會加重總控節(jié)點的負載，并且所有工作節(jié)點均向總控節(jié)點發(fā)送消息，會造成較大的通信開銷；其次，消息傳送的周期長短不容易確定，太長會造成信息更新不及時，太短會造成通信負載的增加；最后，假如在一次任務分配周期內發(fā)送多次新任務，會導致后續(xù)任務不能得到高效的處理。反之，當兩次更新之間沒有新任務到達，就會造成系統(tǒng)資源的浪費。

鑒于上述情況，總控節(jié)點的周期性信息收集并不完全適合實際應用中出現(xiàn)的各種狀況。因此，本文對周期性信息收集方式進行擴展，使總控節(jié)點在進行周期性信息收集的同時還根據(jù)當前任務數(shù)據(jù)量的需要采集工作節(jié)點狀態(tài)信息。根據(jù)任務數(shù)據(jù)量進行信息收集的算法思想是：總控節(jié)點接收到新任務時，主動向工作節(jié)點發(fā)送狀態(tài)詢問請求，收集工作節(jié)點的負載情況；工作節(jié)點接收到總控節(jié)點的狀態(tài)詢問請求時，就會將當前的負載情況、資源占有情況、任務分配情況等信息發(fā)送給總控節(jié)點。

總控節(jié)點調度過程如下：

if新任務到達 ||開始新的時間周期

重置clock

總控節(jié)點發(fā)送詢問請求，接受從節(jié)點負載信息

if當前節(jié)點i綜合信息滿足

給當前節(jié)點i分配或者加入隊列

end if

end if

從當前節(jié)點i工作過程：

if當前節(jié)點i接收到總控節(jié)點的詢問請求

將負載信息反饋給總控節(jié)點

end if

在整個節(jié)點的通信過程中，可采用TCP協(xié)議進行消息傳輸來確?？煽啃裕鶕?jù)傳輸特點，工作節(jié)點接收總控節(jié)點分配任務并回復總控節(jié)點，為了確?？偪毓?jié)點監(jiān)測到的信息更準確，工作節(jié)點收到任務之后向總控節(jié)點回復消息，該消息中包含工作節(jié)點自身信息和在負載均衡調整過程中所用到的伙伴節(jié)點信息，并且每一個工作節(jié)點都在回復消息中添加其攜帶的時間戳，以保證總控節(jié)點收到的信息是最新的?？偪毓?jié)點依據(jù)攜帶信息對所存的相應工作節(jié)點信息進行更新，既能準確獲得工作節(jié)點的負載信息又能減少節(jié)點之間的通信量，又可保持調度算法的簡單可行。按需收集狀態(tài)信息的方式會出現(xiàn)空載運行的情況，為此，當系統(tǒng)空閑時，工作節(jié)點等待總控節(jié)點收集信息并做出決策；當系統(tǒng)運行時，工作節(jié)點并行處理實際任務和回復總控節(jié)點的詢問請求，并不持續(xù)等待分配任務，能夠充分利用系統(tǒng)資源。

總控節(jié)點只在提交任務的時候收集信息，當系統(tǒng)負載均衡處理壓力比較大且特定時間段內執(zhí)行任務數(shù)量過大時，總控節(jié)點在任務分配方面消耗的運算資源較多，時間消耗大。上述算法在進行設計的時候考慮到工作節(jié)點在接收到任務之后捎帶發(fā)送自己最新的負載信息給總控節(jié)點，在此過程中總控節(jié)點只會更新接收到任務的節(jié)點負載信息，而那些沒有接收任務的節(jié)點不會發(fā)送負載信息給總控節(jié)點。通過此種方式，能夠有效降低空閑節(jié)點接收到新任務的可能性。結合采用周期性的節(jié)點負載信息收集方式，使總控節(jié)點在保持按需收集方式的同時，周期性地收集所有節(jié)點的信息，可提高近期未被分配任務的節(jié)點接受新任務的可能性。綜上所述，周期性收集和按需收集相結合的工作模式，能夠保證負載信息的實時性和降低節(jié)點間交互的通信量，在提高系統(tǒng)整體性能的同時，較好地均衡各節(jié)點的負載。

3 實驗驗證

本文采用CloudSim云計算仿真平臺驗證負載均衡方案（版本為4.0），CloudSim是基于離散事件模型使用Java語言設計開發(fā)的仿真模擬應用系統(tǒng)［6］，具備Java語言的跨平臺部署特性，可在Windows、Linux或MacOS操作系統(tǒng)中運行，用于在集群環(huán)境下對系統(tǒng)架構和部署方案進行建模和仿真。

本文選擇了CloudSim的部分核心類用于構建仿真模擬環(huán)境，具體包括：

（1）DataCenter class：該類用于模擬集群基礎設施中的數(shù)據(jù)中心解決方案，封裝了在其中配置相應工作節(jié)點的相關方法；

（2）DataCenterBroker class：該類封裝了管理內部工作節(jié)點的相關方法，支持對工作節(jié)點的加入、回收等操作；

（3）Host class：該類用于模擬集群環(huán)境下物理主機對虛擬機的映射關系，封裝了物理主機對部署虛擬機的管理策略，如對內存容量、數(shù)據(jù)存儲容量、處理器性能等性能參數(shù)的管理；同時，該類還提供對虛擬機協(xié)作交互的仿真模擬。

（4）VirtualMachine class：該類用于模擬集群中部署的虛擬機，其在Host class中作為成員模擬多個虛擬機之間的資源共享和內部調度等策略；

（5）VMScheduler class：該類用于模擬對多個虛擬機之間的調度和管理策略，允許實現(xiàn)虛擬機任務的掛載；

（6）VMProvsioner class：該類用于對DataCenter對象中Host對象與VirtualMachine對象的映射關系進行配置；

（7）Cloudlet class：該類用于對集群中的任務進行模擬，并支持對任務的資源配置。

本文使用3臺物理主機（分別標識為PH_LB_1601、PH_LB_1602和PH_LB_1603）配置部署負載均衡仿真實驗環(huán)境，各臺物理主機在安裝和配置JDK8.0基礎上，配置CloudSim4.0，并相應設置了環(huán)境變量。

負載均衡仿真實驗將上述3臺物理主機配置到1個DataCenter對象中（標識為CS_DC_LB）。物理主機PH_LB_1601在該DataCenter對象中配置2個VirtualMachine對象（分別標識為VM_CL_1601_01、VM_LB_CTL_1601_02）作為負載均衡控制器，用于執(zhí)行負載均衡的調度和管理；物理主機PH_LB_1602和物理主機PH_LB_1603各自分別構建了3個VirtualMachine對象（標識依次為VM_LB_1602_01、 VM_LB_1602_02、 VM_LB_1602_03、VM_LB_1603_01、VM_LB_1603_02和 VM_LB_1603_03）。上述物理主機內部的VirtualMachine對象形成了由7個節(jié)點組成的負載均衡方案。上述節(jié)點的網(wǎng)絡拓撲結構如圖4所示。

基于上述網(wǎng)絡拓撲結構，調用Host對象和VMScheduler對象將本文提出的基于動態(tài)反饋的負載均衡策略和調度算法部署至物理主機PH_LB_1601、物理主機PH_LB_1602和物理主機PH_LB_1603的虛擬節(jié)點中。

圖4 實驗方案的網(wǎng)絡拓撲結構

在測試負載均衡方案時，本文在VirtualMachine對象VM_CL_1601_01中配置由Httperf生成負載任務，用于測試服務請求接入能力。測試方案中重點關注兩項性能指標：（1）服務請求的平均響應時間與并發(fā)連接數(shù)的關聯(lián)關系，以反映方案的服務請求接入性能；（2）給定服務請求場景中的可用并發(fā)連接數(shù)，以反映方案能夠處理的最大并發(fā)接入能力。實驗環(huán)境中由多臺服務器構成的集群對多種并發(fā)連接數(shù)的平均響應時間表現(xiàn)比較穩(wěn)定，測試數(shù)據(jù)如表-1所示。從上述實驗結果可以看出，采用集群方式的負載均衡方案在處理并發(fā)請求方面具備較好的性能表現(xiàn)，在并發(fā)連接數(shù)持續(xù)上升的情況下，響應時間基本保持在7ms以內?？梢姴捎眉悍绞綐嫿ǖ呢撦d均衡方案能夠有效控制服務器處理請求接入的時間。

表1 負載均衡方案的響應時間

對負載均衡策略進行評價時，主要考察實際并發(fā)連接數(shù)來分析基于動態(tài)反饋的負載均衡算法的性能表現(xiàn)，并以Nginx自帶的IP Hash算法作為對比。其中，IP Hash算法的核心思想是根據(jù)服務請求來源的IP地址進行哈希映射，并將哈希運算結果作為選擇實際應答服務請求的服務器節(jié)點的依據(jù)，進而將服務請求分配至相應的服務器節(jié)點,如表2所示。

表2 實際并發(fā)連接數(shù)對比

由圖5分析能夠發(fā)現(xiàn)，當并發(fā)連接數(shù)較低時（800以內），實際并發(fā)連接數(shù)基本與并發(fā)請求連接數(shù)持平，偶有少量丟失情況（IP Hash算法的丟失率為0.2%，基于動態(tài)反饋的負載均衡算法的丟失率為0.6%），能夠保持基本正常的請求接入性能。當并發(fā)連接數(shù)持續(xù)增加并達到1000時，IP Hash算法出現(xiàn)了明顯的并發(fā)請求連接丟失情況，其丟失率達到31.8%，而此時基于動態(tài)反饋的負載均衡算法的丟失率僅為2%。相比之下可見，后者擁有更好的服務請求接入性能。

圖5 實際并發(fā)連接數(shù)測試對比結果

4 結語

本文通過對動態(tài)負載均衡方法的介紹，優(yōu)化了動態(tài)負載均衡過程中的動態(tài)反饋策略，并在實際過程中實現(xiàn)負載均衡的任務調度，對負載均衡工作過程中的任務隊列調度進行了詳細的分析。論文首先實現(xiàn)對節(jié)點負載情況的一個評估，之后通過對負載均衡的閾值設定，進而實現(xiàn)了在負載均衡優(yōu)化策略方面的優(yōu)化。并通過搭建實驗環(huán)境對實驗結果進行了仿真驗證，證明進行優(yōu)化了的基于動態(tài)反饋的負載均衡算法在解決數(shù)據(jù)高并發(fā)方面比IP Hash算法更加良好。隨著網(wǎng)絡數(shù)據(jù)量不斷增大這一現(xiàn)實問題，在數(shù)據(jù)高并發(fā)處理過程中，對于網(wǎng)絡負載均衡優(yōu)化的研究需要采用更加優(yōu)化的算法，在以后的工作中將會在該方面進行更加深入的研究。

［1］文軍，張思峰，李濤柱.移動互聯(lián)網(wǎng)技術發(fā)展現(xiàn)狀及趨勢綜述［J］.通信技術，2014（9）：977-984.

［2］Cybenko G.Dynamic load balancing for distributed memory multiprocessors［J］.JournalofParallel&Distributed Computing，1989，7（2）：279-301.

［3］Bond A.ODSI：Enterprise service coordination［C］.International Symposium on Distributed Objects and Applications，2001.

［4］Xinhua E，Han J，Wang Y，et al.Big data-as-a-service：definition and architecture［C］.IEEE International Conference on Communication Technology，IEEE，2013：738-742.

［5］Raghavendra S，Chitra S Reddy，Geeta C M，et al.Survey on data storage and retrievaltechniques over encrypted cloud data［J］.International Journal of Computer Science and Information Security（IJCSIS），2016，14（9）：718-745.