蘇命峰

（1.湖南商務(wù)職業(yè)技術(shù)學院 2.湖南大學信息科學與工程學院）

1 前言

隨著Internet飛速發(fā)展，Web、Mail、Media等網(wǎng)絡(luò)應(yīng)用已成為生活中的重要組成部分。Web等網(wǎng)絡(luò)服務(wù)器面對越來越多的用戶訪問請求，僅靠單個服務(wù)器已遠遠不能滿足需求。為了滿足不斷增長的服務(wù)器性能需求，實現(xiàn)系統(tǒng)的高可靠性，常采用DNS、反向代理服務(wù)器、NAT地址轉(zhuǎn)換和集群等負載均衡技術(shù)。其中，章文嵩提出基于Linux集群的可伸縮網(wǎng)絡(luò)服務(wù)體系結(jié)構(gòu)（Linux Virutal Server，LVS[1]）能提供負載均衡、可伸縮性和高可用性等性能，是目前廣泛應(yīng)用且成熟的集群技術(shù)。本文分析網(wǎng)絡(luò)地址轉(zhuǎn)換、IP隧道和直接路由等三種實現(xiàn)LVS的方式，針對三種LVS模式分別設(shè)計實現(xiàn)一個 Web服務(wù)器集群，并采用WAS測試軟件仿真大量網(wǎng)絡(luò)用戶，進行并發(fā)訪問測試，最終得出三種 LVS負載均衡模式的系統(tǒng)性能分析結(jié)果。

2 LVS體系結(jié)構(gòu)

LVS集群系統(tǒng)在兩個層次上實現(xiàn)負載均衡，分別是基于IP層的IPVS和基于應(yīng)用層的KTCPVS內(nèi)容請求分發(fā)方式。它們均在Linux內(nèi)核中實現(xiàn)，可將一組服務(wù)器構(gòu)成一個可伸縮的、高可用的網(wǎng)絡(luò)虛擬服務(wù)器，對外提供一個虛擬IP地址，響應(yīng)用戶訪問請求。LVS體系結(jié)構(gòu)由三部分組成，如圖1所示。

2.1 負載均衡器(Load balancer)

負載均衡器是整個集群系統(tǒng)對外提供服務(wù)的前端，它將用戶訪問請求（目的地址為虛擬IP地址），根據(jù)工作模式、調(diào)度策略和內(nèi)容分發(fā)到集群內(nèi)部各臺真實服務(wù)器上；服務(wù)器則通過負載均衡器響應(yīng)請求或?qū)⒔Y(jié)果直接返回給客戶。服務(wù)器集群的結(jié)構(gòu)對客戶是透明的，客戶訪問集群系統(tǒng)提供的網(wǎng)絡(luò)服務(wù)就像訪問一臺高性能、高可用的服務(wù)器（地址為虛擬IP地址）一樣。負載均衡器可以采用 IP負載均衡技術(shù)、基于內(nèi)容請求分發(fā)技術(shù)或兩者相結(jié)合的技術(shù)。由于負載均衡器運行在Linux操作系統(tǒng)的內(nèi)核中，無需在用戶態(tài)和內(nèi)核態(tài)之間切換，故調(diào)度開銷小，占用資源少，效率較高。

圖1 LVS體系結(jié)構(gòu)

為避免負載均衡器單點故障導致整個 LVS集群系統(tǒng)不可用，可設(shè)置Master、Slaver兩臺負載均衡器，它們分別處于活躍、備用工作狀態(tài)，兩者之間通過Heartbeat[2]機制實時監(jiān)測對方的健康狀態(tài)。如果負載均衡器Master宕機，則Slaver立即由備用跳轉(zhuǎn)為活躍狀態(tài)，以確保系統(tǒng)的高可用性。

2.2 服務(wù)器池(Server pool)

服務(wù)器池由真正響應(yīng)客戶請求的真實服務(wù)器（簡稱節(jié)點）組成，這些節(jié)點可提供 Web、Mail、Media或DNS等網(wǎng)絡(luò)服務(wù)。根據(jù)訪問需求的變化，服務(wù)器池可靈活增加或減少節(jié)點數(shù)目，集群系統(tǒng)的整體訪問性能隨著節(jié)點數(shù)量的增加呈線性增長。LVS通過負載均衡器實時監(jiān)控節(jié)點，將有故障的節(jié)點及時從服務(wù)器池中移除，確保系統(tǒng)的高可用性。

2.3 共享存儲(Shared storage)

共享存儲為服務(wù)器池提供統(tǒng)一的存儲空間，使服務(wù)器池的節(jié)點擁有相同的內(nèi)容，提供相同的服務(wù)，對于同步更新更方便，系統(tǒng)數(shù)據(jù)維護更簡單。一般共享存儲為數(shù)據(jù)庫、網(wǎng)絡(luò)文件系統(tǒng)或是分布式文件系統(tǒng)。對于大規(guī)模的集群系統(tǒng)，可使用分布式文件系統(tǒng)存儲，如 AFS[3]、GFS[4]、Lustre[5]和 TFS[6]等，有良好的伸縮性和可用性。

3 LVS的3種實現(xiàn)模式

在負載均衡調(diào)度實現(xiàn)的技術(shù)中，IP負載均衡技術(shù)的應(yīng)用比較廣泛并且效率很高。基于 LVS的核心軟件IPVS有三種IP負載均衡模式，分別是網(wǎng)絡(luò)地址轉(zhuǎn)換（Virtual Server via Network Address Translation ，VS/NAT）模式、IP隧道（Virtual Server via IP Tunneling ，VS/TUN）模式和直接路由（Virtual Server via Direct Routing ，VS/DR）模式。

3.1 VS/NAT模式

VS/NAT體系結(jié)構(gòu)如圖2所示。

圖2 VS/NAT體系結(jié)構(gòu)

負載均衡器將用戶發(fā)來的請求報文的目的 IP地址（即虛擬 IP地址）和目的端口號，如“請求數(shù)據(jù)包1”，根據(jù)預設(shè)的調(diào)度算法，改寫為某臺真實服務(wù)器的目的IP地址和目的端口號，如“請求數(shù)據(jù)包2”，轉(zhuǎn)發(fā)給真實服務(wù)器；同時在負載均衡器的Hash表中記錄這兩個 IP地址和端口的映射關(guān)系。真實服務(wù)器負責處理、應(yīng)答請求。負載均衡器將真實服務(wù)器響應(yīng)的“應(yīng)答數(shù)據(jù)包1”，根據(jù)Hash表中的記錄，將報文的源IP地址和源端口號改為的虛擬IP地址和對應(yīng)端口，如“應(yīng)答數(shù)據(jù)包2”，再返回給客戶，完成整個負載調(diào)度過程。當這個連接的下一個報文到達時，負載均衡器根據(jù)Hash表中記錄，將請求和應(yīng)答報文進行同樣的改寫，轉(zhuǎn)發(fā)給相同的真實服務(wù)器和用戶。

用NAT技術(shù)時，請求和響應(yīng)報文都必須經(jīng)過負載均衡器進行目的（和源）IP地址和端口的重寫，當用戶請求越來越多，真實服務(wù)器數(shù)量增加到一定程度時，負載均衡器的處理能力將成為瓶頸。

3.2 VS/TUN模式

為了解決VS/NAT模式的負載均衡器瓶頸問題，針對大多數(shù)Internet服務(wù)的請求報文時間較短而響應(yīng)報文時間較長的特點，VS/TUN模式的負載均衡器只負責調(diào)度請求，響應(yīng)由真實服務(wù)器直接發(fā)給用戶。VS/TUN體系結(jié)構(gòu)見圖3。

圖3 VS/TUN體系結(jié)構(gòu)

圖3中，負載均衡器利用IP隧道技術(shù)將“請求數(shù)據(jù)包1”封裝一個新的IP數(shù)據(jù)包頭，新數(shù)據(jù)包頭的源IP地址和目的IP地址分別為負載均衡器IP地址和根據(jù)調(diào)度算法選定的真實服務(wù)器的物理接口IP地址。支持IP隧道協(xié)議的真實服務(wù)器接收“請求數(shù)據(jù)包2”，先解封新 IP數(shù)據(jù)包頭，獲得的源地址和目標地址分別為用戶地址和虛擬 IP地址的報文。此時服務(wù)器發(fā)現(xiàn)虛擬IP地址為本機預先配置的IP隧道設(shè)備地址，所以處理這個請求，并構(gòu)造一個響應(yīng)報文，“直接應(yīng)答數(shù)據(jù)包”的源IP地址和目的IP地址分別為IP隧道設(shè)備地址（即虛擬 IP地址）和用戶地址，不需經(jīng)過負載均衡器，而是直接發(fā)給用戶。

由于一般網(wǎng)絡(luò)服務(wù)應(yīng)答比請求報文大許多，采用VS/TUN技術(shù)后，集群系統(tǒng)的最大吞吐量可以提高10倍以上。

3.3 VS/DR模式

和VS/TUN模式修改請求報文第3層IP地址不同（還需修改第2層MAC地址），VS/DR模式僅通過改寫請求報文的第2層MAC地址實現(xiàn)負載均衡。但VS/DR要求負載均衡器和真實服務(wù)器處在同一廣播網(wǎng)段，除了給負載均衡器和真實服務(wù)器的物理網(wǎng)卡配置不同的 IP地址外，還需要新添加邏輯（或Loopback）網(wǎng)卡接口，接口都設(shè)置為虛擬 IP地址，并在真實服務(wù)器上限制針對邏輯網(wǎng)卡接口的ARP廣播。VS/DR體系結(jié)構(gòu)見圖4。

圖4 VS/DR體系結(jié)構(gòu)

圖4中，負載均衡器接收用戶請求，將“請求數(shù)據(jù)包1”的源MAC地址和目的MAC地址分別修改為自己物理網(wǎng)卡MAC地址和根據(jù)調(diào)試算法選定的真實服務(wù)器的物理網(wǎng)卡MAC地址（請求數(shù)據(jù)包2），真實服務(wù)器發(fā)現(xiàn)“請求數(shù)據(jù)包2”的目的MAC地址為自己物理網(wǎng)卡MAC地址、目的IP地址為自己邏輯網(wǎng)卡的虛擬 IP地址時，就接收、處理并響應(yīng)用戶請求。并將“直接響應(yīng)數(shù)據(jù)包”返回給用戶（源 MAC地址和目的MAC地址分別為真實服務(wù)器的物理網(wǎng)卡MAC地址和去用戶最近網(wǎng)關(guān)接口MAC地址），不需經(jīng)過負載均衡器。

這種模式只需處理第2層數(shù)據(jù)幀，沒有第3層IP包的處理開銷，對集群中的真實服務(wù)器也沒有VS/TUN模式必須支持IP隧道協(xié)議的要求，相對前兩種LVS模式來說，VS/DR的負載均衡性能更好、可擴展性更強，適應(yīng)更廣。不足的是要求負載均衡器與真實服務(wù)器的網(wǎng)卡位于同一廣播域，且節(jié)點全暴露在外網(wǎng)，安全性較差，實際應(yīng)用時需在 LVS系統(tǒng)和外網(wǎng)之間安裝防火墻等安全設(shè)備。

3.4 三種IP負載均衡模式的比較

三種LVS負載均衡模式的特點見表1。

表1 三種LVS負載均衡模式的比較

4 LVS性能測試

為了簡化測試的物理平臺，本文在一臺CPU為intel Core i3M370 2.40GHz、內(nèi)存為4GB的物理主機上運行VMware Workstation 7虛擬機軟件，同時虛擬四臺計算機（每臺虛擬機的內(nèi)存均為 512MB），分別是負載均衡器、兩臺真實服務(wù)器和測試客戶端。

為測試不同 LVS負載均衡模式的性能，根據(jù)三種體系結(jié)構(gòu)依次搭建LVS集群測試的軟件平臺，LVS集群系統(tǒng)提供 Web服務(wù)。負載均衡器和兩臺真實服務(wù)器均運行Redhat Enterprise Linux 5操作系統(tǒng)，都安裝Apache組件，且負載均衡器安裝LVS核心管理組件ipvsadm。三種LVS集群系統(tǒng)均采用加權(quán)最少連接(Weighted Least-Connection Scheduling)調(diào)試算法，兩臺真實服務(wù)器的權(quán)重都為 10。真實服務(wù)器的主頁index.html為20kB大小的靜態(tài)網(wǎng)頁。測試客戶端運行Windows Server 2003 Enterprise操作系統(tǒng)，安裝Microsoft的 Web應(yīng)用負載測試工具 WAS[7]（Web Applicationstress Tool），通過設(shè)置不同的并發(fā)連接數(shù)，在測試端模擬大量用戶同時訪問LVS集群的Web服務(wù)。每次測試運行時間為2分鐘，以產(chǎn)生足夠的請求，避免出現(xiàn)失真的測試結(jié)果。主要從平均響應(yīng)時間長短來測試不同 LVS負載均衡模式的性能，平均響應(yīng)時間參考TTFB（Time To First Byte）值（見表2）。WAS測試收到真實服務(wù)器響應(yīng)的第一個數(shù)據(jù)所用的時間，值越小性能越好。

表2 三種LVS負載均衡模式的TTFB值(ms)

由表2的分析結(jié)果可得到三種LVS負載均衡模式在不同并發(fā)數(shù)下TTFB的變化曲線，如圖5所示。

圖5 三種LVS模式在不同并發(fā)數(shù)下TFFB的變化

由圖5可知，隨著并發(fā)數(shù)的增加，三種LVS負載均衡模式的TTFB值均隨之增長，但在相同負載前提下，VS/DR模式的TTFB值最小，系統(tǒng)性能最優(yōu)，VS/TUN模式次之，VS/NAT模式最差。

5 結(jié)束語

本文詳細討論了三種 LVS負載均衡技術(shù)，只從集群的系統(tǒng)性能看，VS/DR模式最優(yōu)。除了 LVS、基于Linux的軟件負載均衡集群、還有H A Proxy[8]和適應(yīng)復雜網(wǎng)絡(luò)的 Nginx[9]等。如果需要更高系統(tǒng)性能，可選擇F5的BIG-IP[10]、Cisco的CSS[11]內(nèi)容交換機、Radware的 AppDirector[12]等硬件負載均衡產(chǎn)品。

[1] 章文嵩.可伸縮網(wǎng)絡(luò)服務(wù)的研究與實現(xiàn)[D].長沙：國防科學技術(shù)大學,2000：14-40.

[2] Alan Robertson,et al.Linux High AvailabilityProject [EB/OL].http：//www.linux-ha.org,2011-5.

[3] Daniel Lazenby.Book Review：Managing AFS：Andrew File System[M].Specialized System Consultants,Inc,1998.

[4] Steven R.Soltis,Thomas M.Ruwart,Matthew T.O’keefe.The Global File System[C].Fifth NASA Goddard Conference on Mass Storage Systems and Technologies,1996：319-342.

[5] Peter Braam.Lustre(file system)[EB/OL].http：//wiki.lustre.org,2010.

[6] Taobao.TFS(Taobao FileSystem)[EB/OL].http：//code.taobao.org/trac/tfs/wiki,2010-9.

[7] Aaron Ching,Pedro Silva,Allen Wagner.利用Web Application Stress Tool(WAS)做性能測試[EB/OL].http：//msdn.microsoft.com,2001-1.

[8] H A Proxy. The Reliable, High Performance TCP/HTTP Load Balancer[EB/OL].http：//haproxy.1wt.eu,2011-9.

[9] Igor Sysoev.Nginx[EB/OL].http：//nginx.org/en,2010-4.

[10] F5 Networks Inc.BIG-IP[EB/OL].http：//www.f5.com,2011-9.

[11] Cisco System Inc.Cisco Content Services Switches[EB/OL].http：//www.cisco.com/en/US/products/hw/contnetw/ps792/in dex.html,2011-9.

[12] Radware Ltd. AppDirector[EB/OL].http：//www.radware.com/Products/ApplicationDelivery/AppDirector/default.aspx,2011-9.