基于云計算的彈性負載均衡服務研究

□ 文/梅　榮

作者單位：深圳市泛海三江電子股份有限公司

引言

云計算是隨著虛擬化技術、分布式技術及自動化管理技術等的發展而產生的一種基于網絡的計算模式。云計算能夠提供可以擴展的大規模計算能力。云計算的大規模計算能力通常是由分布式的服務器集群提供 。云計算的一個重要特征是具有彈性。借助虛擬化技術和自動化管理技術，云計算可以實現集群的彈性伸縮，從而提供動態的服務能力。

在大規模、超大規模的云計算部署環境中，當后端應用虛擬機達到一定規模后，由單節點構成的負載均衡器將成為整個系統性能的瓶頸。在單節點的負載均衡器達到轉發能力上限后，即使應用虛擬機集群規模持續擴大，系統提供的服務能力卻不能夠繼續提升。同時，由于大規模的集群中，節點失效的問題會凸顯出來。

現有基于云計算的彈性負載均衡研究，大多都針對于一種特定的應用，主要研究負載均衡系統中的應用服務器集群隨請求數量的不同，進行動態的伸縮［1～6］。文獻［2］提出了一種基于彈性云的負載均衡方法，通過任務調度算法和彈性伸縮算法實現任務的分發和虛擬機集群的彈性。設計了具有彈性的ElasTraS系統。該系統可以根據算法和給定的閾值，對于應用節點進行彈性伸縮，以提升系統的容錯和自治性能。現有研究對于實際出現的單點性能瓶頸問題，沒有有效的解決方案。

為適應大規模的部署環境，本文提出了基于云計算的彈性負載均衡服務（ELBaaS，Elastic Load Balancing as a Service），將彈性負載均衡作為一種公共服務提供出來。建立了集群管理模型和交叉調度模型，并引入了失效節點替換策略，設計了基于規則匹配的彈性伸縮算法和基于交叉調度模型的負載調度算法，實現了負載均衡層和應用層的彈性伸縮，有效提升了系統的吞吐量和可用性，并進行了實驗驗證。

彈性負載均衡服務模型

彈性負載均衡服務框架

彈性負載均衡服務主要面向的是分布式的任務，如海量數據的處理，分布式的web服務。分布式任務主要由若干可以相互獨立的任務構成，可以由負載均衡系統調度給不同應用節點分別執行。

彈性負載均衡服務的框架，采用數據流和控制流分離的設計，主要包括負載均衡層，應用層以及集群管理模塊，負載均衡框架如圖1所示。數據流從用戶發起，經負載均衡層到達應用層。控制流由集群管理模塊發起，對于負載均衡層和應用層進行控制。

▲ 圖1：彈性負載均衡服務框架

負載均衡層主要提供負載均衡服務，包括若干個負載均衡節點，負責將任務接收并轉發到相應的后端應用虛擬機進行處理。應用層主要提供應用服務，包括有若干個應用虛擬機，部署有若干個應用，負責處理用戶的任務請求。

在大規模、超大規模的云環境中，負載均衡層和應用層中大量的節點，使用人力無法進行有效、及時的管理，因此引入了集群管理模塊。集群管理模塊主要用于提供負載均衡節點和應用虛擬機集群的自動化管理服務，以保證負載均衡層和應用層的穩定性和可靠性。

集群管理模型

負載均衡層和應用層中的節點，分別提供了負載均衡和應用服務。為將節點進行統一的管理，對于節點進行統一的抽象。

定義1 節點，指用于提供服務的虛擬機，用node表示。節點有服務類型type，資源res，所屬物理機host三個基本屬性。節點i用元組（typei，resi，hosti）進行表示。負載均衡層的節點集合為LB，應用層的節點集合為APP。

集群管理模塊主要負責對于所有節點的管理控制，由監控模塊、自動伸縮模塊、心跳模塊、調度模塊以及池化管理模塊五個子模塊構成。

（1） 監控模塊：主要負責收集節點的資源監控數據，將數據匯總并交付自動伸縮模塊。

（2） 自動伸縮模塊：接收監控模塊的數據，根據彈性伸縮算法，作出集群擴展或收縮的決策，并通知調度模塊執行。

（3） 心跳模塊：通過收發心跳數據包，以確認各個節點的可用性。在與節點失去心跳通訊次數達到上限閾值后，判定該節點失效，作出失效節點替換的決策，并通知調度模塊執行。

（4） 調度模塊：接收來自自動伸縮模塊和心跳模塊的決策，控制應用層和負載均衡層集群的伸縮。集群擴展時，從虛擬機池中取出虛擬機，加入到負載均衡集群或應用虛擬機集群；集群收縮時，將移除的節點回收至虛擬機池中。

（5） 池化管理模塊：考慮到虛擬機創建時的時間損耗，采用虛擬機池的方式，以提升虛擬機創建的效率。池化管理模塊主要對于虛擬機池進行管理，以保證充足的后備虛擬機供應的同時，減少虛擬機池的資源消耗。

負載調度模型

定義2 調度關系，負載均衡節點nodei接受來自用戶的任務，并將任務調度給應用虛擬機 nodej，則稱nodei和nodej之間存在調度關系，用元組（nodei，nodej）表示。在負載均衡層和應用層之間存在調度關系集R。

負載均衡集群有兩種基本調度模型，分片調度和交叉調度，其模型如圖2所示。分片調度是指各個負載均衡節點映射一臺或多臺應用節點，每個應用節點的任務只由一個負載均衡節點調度。負載均衡節點和應用節點之間是一對多的關系。分片調度模型中，負載均衡節點和應用節點之間的關系簡單，映射明確，易于管理，但是容易帶來單點失效的問題。當一個負載均衡節點發生故障后，其所屬的應用節點將無法接收到任何任務，直到節點故障排除或其他節點接管。

▲ 圖2：分片調度模型與交叉調度模型

交叉調度與分片調度不同，每個應用節點的任務可以由多個負載均衡節點調度。負載均衡節點和應用節點之間存在著多對多的關系。與分片調度相比較，交叉調度可以有效的解決單節點失效問題。當一個負載均衡節點失效后，由于其后端所屬的應用節點同時從屬于另外的負載均衡節點。因此應用節點可以持續提供應用服務而不中斷。

在交叉調度中，由于應用節點可以從屬于不同的負載均衡節點，因此對于交叉調度中調度關系集的生成和維護是核心。本文設計了負載調度算法，用以管理負載均衡層和應用層之間的調度關系。

彈性負載均衡服務策略

失效節點替換

心跳模塊每隔 時間，與節點進行依次心跳通訊。當與節點 進行心跳通訊，在規定時間內收到應答，則將該節點連續失效次數歸零；如果未收到，則將連續失效次數自加。當該節點連續失效次數達到閾值，則記該節點失效，作出失效節點替換的決策。

定義3 連續失效次數，指連續心跳通訊未收到應答的次數。節點nodei的連續失效次數記為losti。

失效節點替換的過程主要是當心跳模塊檢測到節點失效后，通知調度模塊，新增一個節點以替換失效節點，從而保證服務的可用性。同時，考慮到節點的失效一般是由于節點所在的物理機故障引起。因此對于節點所屬物理機中的其余虛擬機，追加一次心跳通訊，確認其余虛擬機的可用性。具體算法如下：

Step1：心跳模塊向節點nodei發出心跳通訊請求。

Step2：節點nodei在時間ttimeout內未返回應答，節點nodei失效次數自加，losti=losti+1，轉向Step3；否則，則將失效次數清零losti=0，轉向Step4。

Step3：losti與預設的失效閾值lostmax作比較，如果losti＜lostmax，轉向Step4；否則，判定該節點失效，轉向Step5。

Step4：等待Δt時間，返回Step1。

Step5：作出決策，增加類型為typei的新節點，并刪除nodei節點，提交調度模塊執行。同時，向nodei節點所屬物理機中的其余虛擬機，發送心跳通訊請求。

彈性伸縮算法

自動伸縮模塊根據彈性伸縮算法，對于集群的規模進行控制，滿足服務質量需求的同時，提高資源的利用率。彈性伸縮算法的主要思想是根據實時的監控數據，與預設的彈性伸縮規則進行匹配，從而作出增加或者減少節點的決定。

定義4 彈性伸縮規則，用以評判目前集群的資源使用狀況，用rule表示。rule規則主要由規則類型 ruletype，上限閾值rulemax，下限閾值rulemin組成。rule=｛ruletype，rulemax，rulemin｝

規則類型，是指用于評判集群的資源指標。常見的指標有C

enPU使用率rulecpu，內存使用率rulemem，網絡使用率rulenet，以及綜合負載ruleavg等。綜合負載一般由CPU、內存、網絡的使用率進行加權求和得到。

根據服務類型的不同，對于規則類型進行排序，得到規則組RULE。以負載均衡服務為例，負載均衡主要消耗網絡帶寬和CPU，因此負載均衡的規則組RULElb為

根據實時的監控數據，依據規則組RULElb進行依次匹配。在進行集群擴展時，從虛擬機池中取出一臺虛擬機，加入到集群中；在進行集群收縮時，考慮到負載較輕的節點可以提供更高的服務質量，將優先移除負載較重的節點。移除的節點將不再接收任務，在執行完現有的任務后，由調度模塊交付虛擬機池進行回收。負載均衡集群的彈性伸縮算法如下：

Step1：初始化n=0。從RULElb中取出規則rule， r ule =

Step2：獲得規則類型rule的監控值mt。

Step3：如果mt＞rulemax，則說明集群資源相對不足，轉向Step4；如果mt＜rulemin，則說明集群資源較為充足，轉向Step5；否則，轉向Step6。

Step4：作出集群擴展的決策，增加類型為 typei的新節點，提交調度模塊執行，轉向Step7。

Step5：作出集群收縮的決策，從集群中，選擇出負載最重的節點nodei，作出將nodej刪除的決策，提交調度模塊執行，轉向Step7。

Step6：規則編號自加n=n+1，取出規則rule， r ule = RULElb[n]，并轉向Step2；如果所有規則匹配完成，則轉向Step7。

Step7：結束整個彈性伸縮過程。

同樣，建立應用層的規則組，利用上述算法，則可以實現應用層的彈性伸縮。

負載調度算法

負載調度算法，是調度模塊管理負載均衡層和應用層之間調度關系的主要依據。

負載均衡節點部署有負載均衡軟件，負責將請求轉發給后端的應用節點。由于受到軟件和資源的限制，對于負載均衡節點nodei，其負責調度的應用節點數量存在上限limiti。

定義5 調度節點數，指負載均衡節點負責調度的應用節點數量。設負載均衡節點nodei的調度節點數為di，設調度節點數上限為dmax。

對于負載均衡節點nodei，在調度節點數達到上限后，即使為該節點分配更多的應用節點，其負載均衡能力已經到達瓶頸，因此無法將更多的請求調度給應用節點，導致應用節點資源的浪費。因此負載調度算法需要綜合考慮負載均衡節點的負載能力。

定義6 從屬節點數，指應用節點從屬于的負載均衡節點的數量。應用節點 的從屬節點數為p。

為避免出現單點失效，采用交叉調度，使得每個應用節點可以從屬于p個負載均衡節點。負載調度算法在管理調度關系時，需要為每個應用節點分配多個負載均衡節點。當所有的負載均衡節點均已經達到上限時，則自動增加負載均衡節點以。負載調度算法如下：

Step1：調度模塊新增應用節點nodej。

Step2：從LB中統計尚未達到調度節點上限的負載均衡節點個數n。如果n＜p，則轉向Step3；否則轉向Step4。

Step3：新增負載均衡節點nodenew，加入到集合LB中，并轉向Step2。

Step4：從未達到調度節點上限的負載均衡節點中選出P個節點，組成集合 LBj。LBj={nodei|di＜dmax}

Step5：建立負載調度關系子集Rj。

Step6：更新負載均衡層和應用層之間的調度關系集 R =R∪Rj。

實驗結果分析

為驗證彈性負載均衡服務的有效性，本文使用了CloudSim［7］進行了仿真實驗。仿真實驗模擬了對于web服務系統，從1000到10000用戶的并發訪問。訪問包括請求頁面文件以及用戶的交互行為。單用戶訪問間隔為5秒。用戶請求超時時間設為2秒，即系統未在2秒內作出響應，則認為該訪問失敗。

仿真實驗根據本文提出的模型和策略，實現了基于云計算的彈性負載均衡服務（Elastic Load Balance，ELB），提供web系統負載均衡服務。作為對比，本文實現了由單一負載均衡節點構成的負載均衡服務（Single Load Balance，SLB）和基于分片調度的負載均衡服務（Slice Load Balance，SLLB）。ELB系統采用交叉調度模型，是對本文提出的彈性負載均衡策略的實現。ELB系統可以根據系統的負載任意擴展負載均衡節點的數量和應用節點的數量。SLB系統由一個負載均衡節點和若干應用節點組成。SLB系統只能依據系統的負載，擴展應用節點的數量，負載均衡節點無法擴展。SLLB系統同ELB系統相似，區別在于SLLB系統使用基于分片調度的模型，每個應用節點只從屬于一個負載均衡節點。

實驗中，負載均衡系統的節點資源配置如表1所示。單個用戶平均請求數據量為1MB。應用節點處理單個請求消耗CPU平均時間為0.2秒，平均消耗內存2.1MB。

表1 負載均衡系統資源配置

負載均衡系統的性能主要通過以下兩個指標進行評估：

系統的吞吐量（Throughput），指在單位時間內通過系統成功傳送的數據量。

系統的可用性（Service ability），指在實驗的時間區間內訪問服務成功的概率，用以表示系統提供服務的能力。通過統計服務訪問系統時的成功次數（Success Request，SR）和失敗的訪問次數（Failure Request，FR），計算得到系統的可用性。

本文實驗了在不同并發數下，對于系統進行持續訪問。得出從1000并發到10000不同并發數下，系統的狀態和性能。每組實驗的仿真時間均設置為24小時。三個系統均采用公式（4）的彈性規則，規則參數一致。仿真結果如圖3、圖4所示。

▲ 圖3：系統吞吐量隨并發數的變化

▲ 圖4：系統可用性隨并發數的變化

由實驗結果可以看出，單節點的負載均衡系統在并發量達到3000左右時，系統的吞吐量不再隨并發量增加而有顯著增長。單一的負載均衡節點吞吐量已經到達上限，無法支持更多的請求轉發，整個系統出現了性能瓶頸。同時由于并發數的增加，系統無法及時處理，系統的可用性在逐步降低。基于分片調度的負載均衡系統在并發量達到7000時，雖然隨著并發數的增加，系統的吞吐量仍然有上升，但是由于此時系統的節點規模較大，負載均衡節點失效后，導致其后端應用節點需要等候其所屬的負載均衡節點恢復后，才能繼續提供服務。因此隨著并發量的增加，可用性有一段較為明顯的下降。

與之對比，本文提出的面向云計算的彈性負載均衡系統的負載均衡節點和應用節點能夠隨著并發數的增加，自動擴展，從而使得系統的吞吐量與并發數能夠呈線性增長。同時，由于引入了交叉調度的模型，系統的可用性并沒有隨并發數的增加而降低，而是一直維持在95%左右。較之SLB和SLLB系統，本文提出的彈性負載均衡系統提供了穩定可靠的服務。

結束語

在大規模、超大規模的部署環境中，單節點構成的負載均衡層會成為整個系統性能瓶頸。針對此問題，本文提出了基于云計算的彈性負載均衡服務將彈性負載均衡作為一種公共服務提供出來。為對負載均衡層和應用層進行統一管理，本文建立了集群管理模型和交叉調度模型，以提升系統的自動化管理能力和系統的可靠性。引入了失效節點替換策略，設計了基于規則匹配的彈性伸縮算法和基于交叉調度模型的負載調度算法，以實現負載均衡層和應用層的彈性伸縮。最后，對于本文提出的彈性負載均衡服務進行了實驗驗證。實驗結果表明，彈性負載均衡服務隨著系統并發量的增加，可以有效提升系統的吞吐量并保持系統的高可用性，防止了負載均衡層的性能瓶頸問題。