集群式網站負載均衡解決方案探析

摘要：Internet的飛速發展，導致一些網站的服務能力正面臨著單點脆弱性的危機， Web服務器集群已經成為解決此問題的一個選擇。本文討論了服務器組的組成模式及其組成結構，就目前服務器集群的結構進行比較，針對各種負載均衡方法的優缺點進行了探討，對負載均衡技術的發展進行了思考與展望。

關鍵詞：Web集群；集群體系結構；負載均衡；資源調度

中圖分類號：TP309文獻標識碼：A文章編號：1009-3044(2008)09-11608-03

Analysis of Cluster Website Load Balancing Solution

ZHANG Jun-hui， ZHANG Hong-yan

(College of Educational Science of Anhui Normal University，Wuhu 241000，China)

Abstract: With the rapid development of Internet，the website's service ability is faceing the crisis of a single point of vulnerability. the WEB server cluster already becoming a choice resolving this problem. This paper discusses the composition and structure of the server group，and their composition structure， server cluster structure carries out comparison right away at present， think deeply that and look into the merit and shortcoming of various load balanced method. Finally，the load balancing technology's development in the future also consider.

Key words: Web Cluster; Cluster Architecture; Load Balancing; Resource Schedulin

隨著網絡用戶的增加，Web服務器的系統容量面臨著巨大的挑戰，對一些大型的電子商務網站影響巨大，任何的服務中斷或是關鍵性數據的丟失均會造成直接的經濟損失。如何在高訪問量的情況下保證高的服務質量成為亟待解決的課題。Web服務器集群是將若干Web服務器通過一定的技術組織在一起構成的一個邏輯整體。從外部應用看來，系統仿佛是一臺功能更加強大的邏輯Web服務器。[1]這種系統具有較高的性能價格比和良好的系統可靠性，并且能夠通過添加服務器的方式來不斷擴充系統的容量，其已經成為構建大型Web網站系統的關鍵技術之一。對于快速膨脹的網絡來說，引進負載平衡機制是一個明智的選擇。

1 當前Web集群方式及體系結構解析

1.1 Web集群體的集群方式

Web集群體集群方式有兩種，一種方式是鏡像，另一種方式是采用URL重定向方式。

1.1.1 鏡像方式（mirroring）

鏡像方式通過將網站的全部內容復制到若干臺位于相同或不同的地理位置服務器上，并且分別擁有各自的IP地址和服務器名字。用戶訪問站點時，自選Web服務器集群相關技術其中的一臺服務器提供服務，用戶的請求被分布到不同的服務器上，實現了系統負載的分配。特別是當服務器分布在不同的地理位置時，如果用戶選擇最近的服務器，就可能節省網絡傳輸帶寬，并獲得較快的響應速度。有的站點將客戶端的瀏覽器軟件中嵌入服務器選擇功能，這樣用戶就不必自己進行服務器選擇，而是由客戶端軟件系統根據一定的算法來選擇服務器。在 Netscape 的 Navigator 瀏覽器中就采用了這種技術。[2]但是，鏡像方式由客戶端來選擇服務器，而服務器本身無法控制用戶的選擇，容易造成負載失衡。比如，人們習慣會選擇編號靠前的服務器，這樣就容易造成編號靠前的服務器過載，而編號靠后的服務器空閑的情況。

1.1.2 URL重定向方式

URL 重定向方式的實現是當用戶首先訪問一臺主 Web 服務器，通過鏈接將請求指向其它服務器，從而讓負載分散到各臺服務器上。以上兩種方式均存在一些不足。雖然，URL重定向方式似乎解決了這一問題，但是由于所有的訪問都以主服務器為入口，因此主服務器可能成為系統的瓶頸。一旦系統中某臺服務器失效，系統將無法提供該部分的服務。特別是主 Web 服務器失效時，由于無法得到指向其它服務器的連接，即使其它服務器正常工作，也會造成整個 Web 系統癱瘓。

1.2 集中式服務器組的結構

1.2.1 集中式

在集中式的服務器組中，有一個服務器是作為交換機或分派器存在的，其它服務器分別與其相連。用戶的訪問請求首先到達交換機，由交換機根據每個服務器的當前狀態將鏈接分派給合適的服務器。

Luis Aversa等專家對這種模式及其業務流進行了較詳細的描述。其中，MagicRouter的角色就是一個分派器，它將來自所有客戶機的訪問請求按一定的策略進行轉發。MagicRouter中保存有其它服務器的狀態信息，其它服務器需要定時向MagicRouter報告自己的狀態。當客戶機的請求到達了MagicRouter時，Magi-cRouter檢查“服務器狀態表”，發現服務器1相對較空閑，于是就將鏈接轉發到服務器1；服務器1響應后再經MagicRouter或直接將響應返回到該客戶機。如果是直接返回，可減輕轉發器的負擔，這對于大數據量的響應尤其重要，可避免轉發器成為新瓶頸。但此時，轉發器就必須要保存一個“鏈接分配表”。

1.2.2 分布式

在分布式模式中，所有服務器組成一個無主式的局域網，用戶的訪問請求可以是任意一個服務器，該服務器根據自己的負載情況決定響應或轉發。

圖１

與集中式服務器組方式不同，分布式模式中的所有的服務器都有可能參與鏈接的轉發。當某臺客戶機發出的請求到達一個服務器時，該服務器根據它所掌握的服務器組的狀態信息，按照某種策略將鏈接請求轉發至其它服務器。接收服務器將響應直接返回給請求客戶機。在這種方式中，服務器組內每個服務器均有兩個角色：響應請求和轉發請求。所轉發的內容中包含有源請求的IP地址。當一個服務器轉發一個客戶機的請求的同時，它也可以轉發其它客戶機的請求。轉發決策使用的信息來源于：(1)客戶機的同步包(SYN Packet，即第一個包)，同步包中包含有源/目的IP地址和源目的端口號；(2)服務器組內的狀態信息，在每個服務器上都有一個表來存放這些信息。在服務器組內，服務器狀態通過組播(Multicast)或廣播方式周期性（例如每隔1秒）地更新。概括地說，服務器的轉發決策是基于：源/目IP地址、源/目端口號和組內狀態信息。不管是哪種服務器結構，都至少需要一級轉發，和服務器直接響應相比，這不可避免地會增加一級時延，即轉發時延。但這種轉發時延和因服務器擁塞而引起的時延相比則要小得多。對于集中式服務器結構，轉發器往往會成為潛在的瓶頸，特別是當用戶訪問量很大時。而分布式服務器結構中，每個服務器均可以作為轉發器，從概率的角度講，用戶的訪問是平均分配在這些服務器上的，因此可避免轉發瓶頸。 另外，和集中式服務器結構相比，分布式服務器結構的可擴展性、容錯性要好得多。特別是當一臺服務器無效時，該服務器上的訪問會自動平均加載到組內其它服務器上，在軟、硬件上都不需要動作；如果失效的服務器恢復或新增一臺服務器，系統會自動將其它服務器上訪問加載到新服務器上。

2 當前比較成熟的負載均衡策略和調度方法

負載均衡策略是指為了使服務器組中各服務器上的負載基本一樣，當客戶機的請求到達轉發器時，轉發器必須采取一定的算法將當前請求分配到某一服務器上的算法。

2.1 網絡地址轉換(NAT)

其實原理是在前端分配器在收到的用戶請求后，將請求包中虛擬服務器的 IP 地址轉換為某個選定真實服務器的 IP 地址，然后將該請求轉發給真實服務器；真實服務器將應答包發給前端分配器，前端分配器再將應答包中真實服務器的 IP 地址轉換為虛擬服務器的 IP地址發送給用戶。其優點在于：真實服務器可運行在任何支持 TCP/IP 的 OS 上，能使用私有 IP 地址，僅需要一個合法的 IP 地址分配給前端分配器。缺點在于：可擴展性不夠好，當真實服務器的結點數增加時，前端服務器會成為整個系統的瓶頸，因為請求包和應答包都須經過前端分配器重寫。

2.2 IP 隧道(IP tunnel)

其實現原理是在前端分配器收到用戶請求包后，根據 IP 隧道協議封裝該包，然后傳給某個選定的真實服務器；真實服務器解包出請求信息，直接將應答數據包傳給用戶。此時要求真實服務器和前端分配器都要支持 IP 隧道協議。其優點是：在 IP 隧道實現技術中， 前端分配器只將請求送往不同的真實服務器，真實服務器直接應答用戶請求。因此前端分配器可以處理大量請求，管理大約 100 個真實服務器且不會成為系統瓶頸，最大流量可達 1Gbps。其缺點是：要求所有真實服務器支持 IP 隧道協議。但隨著 IP 隧道協議成為操作系統的標準，該技術將可以應用于所有的OS。

2.3 直接路由(Direct Routing)

其實現原理是在前端分配器收到請求包后，將請求包中目的 MAC 地址轉換為某個選定真實服務器的 MAC 地址后將請求包轉發出去，真實服務器收到請求包后，可直接將應答包傳給用戶。此時要求前端分配器和所有真實服務器都必須在一個物理段內，且前端分配器與真實服務器群共享一個虛擬 IP 地址。其優點是：不需要隧道設備，可處理大量請求，真實服務器可運行在任何 OS 上。其缺點是：前端分配器僅改變數據幀的 MAC 地址為選定的真實服務器的 MAC 地址，要求它們在同一個網段內。

2.4 基于DNS (Domain Name Server)的負載均衡

它又可分為兩種情況：一種是通過將一個域名解析成不同的IP，以此來分流服務請求的dlbDNS(dynamic load balance DNS)。另一種是根據服務內容等將整個網站劃分為幾個功能模塊，每個模塊用一個二級域名(此處視網站域名為一級域名)命名，域名服務器將用戶請求不同的二級域名解析為不同的服務器IP，以實現訪問請求的分流。

圖２

2.5 基于OSI/RM第七層的負載均衡

其基于OSI/RM第七層的負載均衡和基于內容的交換技術，根據數據包內數據的內容不同，再考慮各支撐服務器的處理能力和等待執行的任務隊列中的任務量，將任務分配到不同的服務器處理。這個方案中，由于均衡服務器要解出數據包內的內容，故對其性能要求比較高，且極易在此形成瓶頸。如Apache的ProxyPass，可以將不同的路徑，映射到不同的服務器上；又如ASP的redirection等，需要特定的應用程序支持。

2.6 基于IP層的負載均衡

其根據一定的調度算法，將數據包直接轉發到物理上不同的服務器。由于均衡在IP層進行，調度成本比上述兩者都要低，能調度更多的支撐服務器。這樣的產品有IBM的Interactive Network Dispatcher，Cisco的LocalDirector， Alteon的ACEDirector F5的Big/IP等。

2.7 反向代理負載均衡

其通過把來自網絡的服務請求以反向代理的方式動態轉發給內部服務器進行處理，從而實現負載均衡。此方法屬于OSI的第七層，所以就必須為每一種應用服務開發一個反向代理服務器，這樣就限制了其應用的范圍。同樣進出系統的報文都要由中心負載均衡設備處理，這樣它的工作負載就會很重，可能會成為系統的瓶頸。

3 集群式網站負載均衡系統實現的思考

3.1 基于分布式服務器結構的思考

通過集中式和分布式兩種結構的比較，我們可以發現：在分布式服務器結構（DCA）中，每個服務器都可以作為報文的轉發器，因此從概率上講，訪問是平均分配在這些服務器上的，一定程度可以避免轉發瓶頸；分布式服務器結構的可擴展性、容錯性也較集中式強，當一臺服務器無效時，該服務器上的訪問會自動平均加載到組內其它服務器上，如果失效的服務器恢復或新增一臺服務器，系統會自動將其它服務器上訪問加載到新服務器上。

3.2 基于IP數據包重組及跨傳機制的思考

(1)利用前端在接收數據時，根據 IP 頭中協議類型分離出 TCP 報文，并從TCP 頭中的目的端口號分離出 HTTP 報文，對 HTTP 報文進行特殊的處理，這樣就可以實現不影響其它協議數據單元以及采用 TCP 協議的其它應用層協議報文的正常處理。將承載該報文的 IP 包的目的 IP 地址替換為被選中的后端服務器（分配器）的 IP 地址，并重新計算 IP校驗和，填入 IP 頭的首部校驗和字段中。服務器的選擇可以采用基于源端口號的簡單取模 Hash算法。當該包被向上傳時，由于其目的地址不是本機，IP層協議調用 IP 包轉發過程，將該 HTTP 報文轉發給相應的服務器（分配器）。

(2)采用與前端交換機相同的方式分離分配器駐留的 HTTP 報文，然后進一步對 HTTP 報文的內容進行解析，來確定提供響應的Web 服務器，并將承載該報文的 IP 包的目的 IP 地址和目的端口號改成被選中的 Web 服務器的 IP 地址和 WWW 服務的端口號，并重新計算 TCP 頭和 IP 頭校驗和，填入相應的首部校驗和字段中。當該包傳遞給 IP 層協議時，如果 IP 地址正好是本機的 IP 地址，則 IP 層協議將其發送給 TCP 層，并最終被本機的 Web 服務器在該端口接收；否則，IP層協議調用 IP 包轉發過程，將該 HTTP 報文轉發給相應的 Web 服務器。

(3)在Web 服務器發送 HTTP 響應報文時，當報文封裝后傳遞至 IP層，修改后的 IP 協議首先根據 IP 頭中協議類型識別 TCP 報文，再從 TCP 頭中的源端口號識別出 HTTP 報文。修改承載 HTTP 報文的 IP 包源地址和 TCP 源端口號，改成集群系統的 IP地址和端口號，重新計算 TCP頭和 IP 頭校驗和。再通過調用接收函數，把剛接收到的數據從發送隊列轉到接收隊列。這樣就實現了 IP數據包跨傳功能，避免了通過分配器轉發結果報文的開銷和傳輸瓶頸。客戶端在檢查來自集群系統的 IP 包時，由于 IP 地址已經修改為集群系統的IP 地址，因此，屏蔽了后端服務器的存在，保證了集群系統對客戶端的透明性。

我們對服務器集群體系結構、動態負載均衡算法等關鍵技術進行的這些理論研究，為我們最終實現一個良好的系統原型提供了一定的指導，但對于不同環境下系統原型的實現及測試還是有待我們去思考和探討的。

參考文獻：

[1] 林海， 孫軍. Windows 2003 中網絡負載均衡群集技術在Web 網站中的應用[J]. 電腦知識與技術，2003，(6):49.

[2] 謝希仁. 計算機網絡[M]. 北京:電子工業出版社，1999:36-40.

[3] Luis Aversa， Azer Bestavros， Load balancing a cluster of web servers us-ing distributed packet rewriting[C].In:Proc. of IEEE IPCCC'2000，Phoenix， AZ，2，2000，24-29.

[4] 陳志剛， 劉安豐， 等. 一種有效負載均衡的網格Web服務體系結構模型[J]. 2005:458-466.

[5] 朱利， 張興軍. Web服務器組的負載均衡方法研究[J]. 西安交通大學學報，2003，(5):24.

[6] 孫海霞， 馬玉鳳. 負載均衡綜述[J]. 電腦知識與技術，2003，(4):162.

[7] 戴剛， 羅宇. 服務器集群關鍵技術的研究與實現[J]. 國防科技大學，2002，(4):121.

[8] 余松慶. 網絡教學平臺負載均衡解決方案[J]. 中國遠程教育，2004，3:23-46.