??? 摘 要: 在Linux內核中實現的負載均衡" title="負載均衡">負載均衡調度算法都是靜態的，沒有動態調節機制。介紹了LVS集群原理，分析了LVS調度算法的不足，提出了一種通過實時獲取真實服務器" title="真實服務器">真實服務器的性能數據、計算和評估真實服務器負載，并根據結果調節服務器權值" title="權值">權值的方法。經測試，利用該方法能夠有效防止服務器負載傾斜，達到良好高負載均衡的效果。
??? 關鍵詞: 負載均衡 LVS 集群 負反饋
?
??? 近年來，Internet的迅速發展使得人們已經習慣從網絡上獲取任何想要的資源，在這種情況下需要網絡服務器具備提供大量并發訪問所需服務的能力。然而，單一服務器的處理能力" title="處理能力">處理能力很難滿足服務要求，已成為網絡系統的瓶頸。簡單地提高單個服務器硬件性能或者更換性能更高的服務器，都不能真正地提供大量并發訪問的能力。因為單臺服務器的性能總是有限的，而且網絡請求具有突發性，即當有重大事件發生時，網絡訪問量會急劇上升，從而造成網絡阻塞。
??? 利用集群技術在服務器應用系統中實現負載均衡可以有效地解決上述問題。Linux的虛擬服務器LVS（Linux Virtual Server）可以完成基于IP層和基于內容請求分發的負載平衡調度，并在Linux內核中實現這些方法，將一組服務器構成一個能實現可伸縮的、高可用網絡服務的服務器集群。本文在分析現有LVS負載均衡調度算法的基礎上，針對其不足，提出一種可動態調整服務器權值的負載均衡調度算法。
1 LVS集群介紹
1.1? LVS集群的結構[1]
??? LVS是由基于Linux操作系統的負載均衡服務器（LB）和基于任意支持TCP/IP平臺的支撐服務器RS(Real Server)群組成的高擴展性和高穩定性的虛擬服務器。在LVS集群中，服務器集群的結構對用戶是透明的，用戶訪問集群提供的網絡服務就像訪問一臺高性能、高可用的服務器一樣。LVS集群的通用體系結構如圖1所示，主要由以下三部分組成：
?
?
??? (1) 負載調度器" title="調度器">調度器（load balancer）：它是整個集群對外的前端機，負責將用戶的請求發送到一組服務器上執行，但從用戶角度來看,服務來自一個IP地址。它可以是基于IP負載均衡技術的負載調度器，也可以是基于內容請求分發的負載調度器，還可以是兩者的結合。
??? (2） 服務器池（server pool）：是一組真正執行用戶請求的服務器，執行的服務有Web、MAIL、FTP和DNS等。
??? (3） 后端存儲（backend storage）：它為服務器池提供一個共享的存儲區，這樣可使服務器池很容易擁有相同的內容，提供相同的服務。
??? 在調度器的實現技術中，IP負載均衡技術是效率最高的，LVS實現的基于IP負載均衡技術的三種虛擬服務器方法如下：
??? (1) 通過網絡地址轉換VS/NAT技術（Virtual Server via Network Address Translation）。大多數商品化的IP負載均衡調度器產品都是使用此方法。
??? (2) IP隧道VS/TUN（Virtual Server via IP Tunneling）。
??? (3) 直接路由實現虛擬服務器的方法VS/DR（Virtual Server via Direct Routing）。
??? 三種IP負載均衡技術的優缺點如表1所示。
?
?
1.2 LVS負載均衡調度算法[2]
??? LVS支持的負載均衡調度算法有如下八種：
??? (1)輪詢(rr)：以順序循環方式進行調度，相比R-R DNS，這種調度是基于TCP或UDP網絡套接字連接的，而不是基于網絡主機的，它不受客戶端Cache或DNS分級結構的影響。
?? ?(2)加權輪詢(wrr)：循環方式調度，但在循環中給每個內容服務器分配指定權重的連接，從而充分考慮各內容服務器處理能力之間的差異。
?? ?(3)最小連接(lc)：將新到的連接請求動態地分配給現有活躍連接數最少的內容服務器。
?? ?(4)加權最小連接(wlc)：將新到的連接請求按各內容服務器當前處理連接數量的比例進行動態分配。wlc是LVS系統的缺省調度算法，在一般應用中都可采用此法均衡。
?? ?(5)基于位置的最小連接(lblc)：專門為高緩集群(cache cluster)設計的算法，屬基于內容的均衡，盡量將對同一目的地址的連接請求分配給固定的一臺高緩集群節點。
??? (6)帶復制的基于位置的最小連接(lblcr)：在集群節點中維護若干針對特定目的地址的高緩服務器集合，以后每當有對匹配地址的連接請求時，盡量分配給該集合中活躍連接數最少的那臺高緩服務器，并定期將該集合中負載最大的節點剔除。
?? ?(7)目標哈希(dh)：根據目標地址查找事先設定的靜態哈希表來分配連接。
?? ?(8)源哈希(sh)：按客戶地址查找設定的靜態哈希表來分配連接，可實現服務就近提供，保證服務質量(QoS)。
2? 動態負載均衡模型
??? 服務器的負載主要由客戶端的請求服務引起。當客戶端的請求到來時，調度器如何選擇服務器來為此請求服務的過程成為服務器負載大小的關鍵。在LVS中，調度器通過使用上述各種調度算法來完成這個工作。但上述調度算法是一些靜態算法。
??? 靜態調度算法是利用事先設定好的服務器的信息調度的，決策過程的依據都是事先設定好的，如權值等，因而不能動態反映服務器的負載情況。當客戶通過TCP/UDP連接訪問服務器時，由于網絡服務的服務時間不同、訪問分布的不均勻性及服務所需資源千差萬別，靜態調度算法不能實時地反映后端服務器的負載情況，無法保證系統內服務器真正地實現均衡。動態算法的主要思想是根據負反饋理論，獲得服務器的真實負載情況并作出評估，將評估的結果作為系統的反饋來修正負載均衡算法的參數。系統模型如圖2所示。
?
???? 圖2只是表示了一個服務器的反饋情況，在實際情況中，每個服務器都會向調度器反饋負載情況l（l較大表示負載較大，反之則負載較小）。圖中,F(w,l)表示權值和負載關系的權值調節模塊，根據服務器當前負載情況l和當前權值w計算得出新權值w′，調度器（LB）則根據服務器新的權值信息w′分配用戶的請求。服務器池(RS)由多臺服務器組成，負責對客戶請求做出響應并向權值調節模塊反饋負載信息。
??? 權值代表服務器的處理，通過反饋調整過的新權值w′，反映了服務器的實時處理能力。而在LVS的各種調度算法中，權值是事先設定好的。根據加權輪詢調度算法(wrr)或加權最小連接調度算法（wlc），權值大的服務器會分配到相對較多的請求。這就可能出現負載相對不均衡的情況：當權值較大的服務器得到較多請求時的處理能力反而比權值小的服務器的處理能力小。這時，可采用如圖2所示的負反饋模型解決負載相對的不均衡問題，即當某個服務器的l較大時，可降低w；l較小時可增大w，從而能充分發揮服務器的處理能力，較好地達到均衡負載的作用。
3 動態負載均衡的實現
??? LVS系統中實現的調度算法都是靜態調度算法，為此，本文根據圖2模型引入動態負載均衡機制，對真實服務器的權值進行動態調整。由于動態負載均衡模塊需要定時收集后端真實服務器的實時負載信息，因此，要在LB中加上負載查詢與接收模塊、負載信息處理與評估模塊和內核通信模塊[3]。加入動態負載均衡模塊后，基于linux內核的動態負載均衡流程如圖3所示。
?
?
3.1 負載采集模塊
??? 動態調度算法需要獲得各節點的系統性能和負載信息, 包括CPU占用率、CPU利用率、磁盤可用空間、內存以及I/O利用率等。在Linux系統中，這些信息的獲取可通過簡單網絡管理協議SNMP來實現。支持SNMP管理的網路設備，其性能數據都有一個標準MIB變量并有惟一的OID與之對應，如1.3.6.1.4.1.2021.10.1.3.2表示CPU最近5分鐘的平均占用率等。在所有RS的用戶空間運行SNMP代理進程，SNMP將負責接收和處理LB發出的SNMP請求。由于影響服務器自身性能的因素很多，負載采集不可能收集所有的信息，在此，只選取了一般應用中影響服務器性能的五個關鍵指標：CPU占用率L(Ci)、請求響應時間L(Ti)、內存占用率L(Mi)、磁盤I/O占用率L(Di)、網絡帶寬占有率L(Bi)。
3.2 定時器模塊和負載查詢與接收模塊
??? 負載查詢與接收模塊運行在LB的用戶空間。對于查詢對象即RS的地址的獲取，負載查詢進程會按一定的時間間隔遍歷內核LVS模塊的RS鏈表，并返回Real Server的地址等信息，建立用戶空間的RS鏈表。查詢進程根據RS鏈表，針對每一個RS，發出相應SNMP請求查詢并存儲其負載信息。
??? 動態反饋機制本身也是需要系統開銷的，因此不可能對用戶的所有請求都對服務器端的負載情況進行查詢?？刹捎妹扛粢欢ǖ臅r間間隔T（如2秒鐘），由負載查詢進程再查詢各個服務器的情況，并相應調整服務器的權值。這樣周期性地進行，通過一個負反饋機制，使得服務器保持較好的利用率。
3.3 負載處理與評估模塊
??? 該模塊負責處理與評估負載接收模塊存儲對應于每個RS的負載信息，將每個RS當前的權值和其負載信息計算出一個新的權值。當負載值表示服務器比較忙時，新計算出的權值會比當前權值??；反之會比當前權值大（新權值的具體算法如后所述）。算出新權值后，通過內核通信模塊用新的權值更新內核中相應服務器的信息。
??? 因為服務器的各種性能信息對服務器的處理能力影響不一樣，根據其不同的影響力，對每個因素設定一個影響因子，不同的服務器影響因子將不相同。例如，在Web服務器集群中，對服務器RSi的主要負載因素[L(Ci)、L(Ti)、L(Mi)、L(Di)、L(Bi)]引入影響因子Qi進行計算。Qi=[qi1,qi2,qi3,qi4,qi5]=[0.4,0.3,0.1,0.1,0.1]時，認為服務器的CPU負載和請求響應時間較其他參數重要一些。若當前的系數Qi不能很好地反映應用的負載，系統管理員可以對系數不斷地進行修正，直到找到貼近當前應用的一組系數。通過下式可得出服務器RSi的負載綜合Li=Qi×[L(Ci),L(Ti),L(Mi),L(Di),L(Bi)]T。
??? 結合節點的初始權值和采集的綜合負載情況計算新的權值結果，即可引入如下權值計算公式:
??? 
式中，0.65是本文想要達到的系統利用率，A是一個可調整的系數（缺省值為5）。當綜合負載值為0.65時，服務器權值不變；而大于0.65時，權值變??；小于0.65時，權值變大。為了避免權值變成一個很大的值,對權值的范圍作一個限制
其中k是可以調整的,其缺省值為10。若新權值
可將新權值設為k×wi。若新權值與當前權值的差值
沒有超過設定的閥值，則將新權值設置到內核中的IPVS調度參數中；否則避免打斷IPVS調度的開銷。這樣將使權值調整到一個穩定點。當系統達到理想的利用率時，權值是不變的。
3.4 內核通信模塊
??? 由于IPVS模塊工作在內核中，因此，內核通信模塊負責負載處理模塊及負載接收模塊與內核的交互。主要有兩個任務：(1)完成負載查詢與接收模塊取得內核RS鏈表，并返回。(2)通過調用setsockopt()函數把負載處理模塊生成的新的權值信息傳入內核IPVS模塊。
4 測 試
4.1 硬件環境
??? 測試平臺連接拓撲圖如圖4所示。圖中設備的硬件配置如表2所示。
?
?
?
4.2 軟件環境[5-6]
??? 各個設備使用的操作系統如表2所示。真實服務器RS1、RS2都運行Apache2.2服務器，提供Web服務；安裝了簡單網絡管理協議SNMP，負責監控服務器的性能信息。測試儀利用工具 WAS（Web Application Stress）在客戶端向虛擬服務發起持續請求，觀察服務器的服務性能。WAS是Microsoft公司推出的Web服務器性能測試工具。WAS設置時將Stress Level大小設置為100，StressMultiplier 大小設置為 20，測試時間為 4 分鐘，測試期間WAS請求真實服務器上的HTTP動態頁面。
4.3 測試內容和結果分析
??? 在上述環境下，采用DR(Direct Route)方式實現服務器的負載均衡，其連接拓撲圖見圖1。
??? 為了測試是否會出現負載傾斜現象，將RS1和RS2的初始權值分別設為4和10，內核LVS調度算法采用加權輪詢調度（wrr）算法。
??? (1)不使用動態調度算法的情況
??? 靜態算法下的負載情況如圖5所示。由圖可知，RS1的配置比RS2的配置低很多，卻擁有較大的權值，所以基本一直工作在滿負荷狀態，而RS2雖然配置很高但權值很低，一直處于較低的負載，其性能得不到充分發揮。這是因為服務器的權值無法動態更改，在運行過程中無法根據服務器的實時負載來確定服務器的權值以確定新鏈接的分配去向，造成服務器的負載傾斜。
?
??? (2）在LB上啟動動態負載模塊并在RS1、RS2上啟動SNMPD進程后，得到如圖6所示的結果。
?
?
??? 由圖6可知，雖然兩臺服務器的配置及初始權值不一樣，但由于動態權值的引入，使得LB能夠按照各真實服務器的實時負載情況來分配任務，使兩臺服務器的負載情況都在期望值(0.65)附近，較好地實現了負載的均衡,達到了預期效果。
??? 網絡中各種服務對服務器性能的需求差別很大，Linux 內核中LVS實現的靜態負載均衡調度算法容易使服務器發生傾斜，達不很理想的均衡效果。而本文在介紹LVS集群系統及其負載均衡調度算法的基礎上，提出并實現了一種根據真實服務器實時性能數據動態調整服務器權值的方案，經測試，采用該方案后，能夠更加充分地發揮各服務器的性能，減少任務分配的傾斜的可能性，能更好地達到均衡負載的效果。
參考文獻
[1] ?ZHANG Weng Song. Linux virtual server Web site.[EB/OL] http://www.linuxvirtualserver.org, 2002.
[2] ?Turbolinux cluster server white paper[EB/OL] http ://www.turbolinux.com,2002.
[3] ?王晉鵬,潘龍法,李降龍.LVS集群中的動態反饋調度算法[J]. 計算機工程，2005,31(19).
[4] ?吳曉葵.利用SNMP獲取網絡資源信息[J].現代電子技術，2006，(16).
[5] ?軟件測試工具——WAS服務器負載測試軟件導讀.http://51cmm.csai.cn/casepanel/ST/No024.htm?ID=1267,2004.
[6] ?葉言苓,崔彥軍.軟件測試管理的研究與應用[J].計算機應用與軟件, 2003，(9).