LVS 集群中的IP 負(fù)載均衡技術(shù)本文在分析服務(wù)器集群實(shí)現(xiàn)虛擬網(wǎng)絡(luò)服務(wù)的相關(guān)技術(shù)上，詳細(xì)描述了LVS 集群中實(shí)現(xiàn)的三種IP 負(fù)載均衡技術(shù)（VS/NAT、VS/TUN和VS/DR）的工作原理，以及它們的

LVS 集群中的IP 負(fù)載均衡技術(shù)

本文在分析服務(wù)器集群實(shí)現(xiàn)虛擬網(wǎng)絡(luò)服務(wù)的相關(guān)技術(shù)上，詳細(xì)描述了LVS 集群中實(shí)現(xiàn)的三種IP 負(fù)載均衡技術(shù)（VS/NAT、VS/TUN和VS/DR）的工作原理，以及它們的優(yōu)缺點(diǎn)。

1. 前言

在前面文章中，講述了可伸縮網(wǎng)絡(luò)服務(wù)的幾種結(jié)構(gòu)，它們都需要一個(gè)前端的負(fù)載調(diào)度器（或者多個(gè)進(jìn)行主從備份）。我們先分析實(shí)現(xiàn)虛擬網(wǎng)絡(luò)服務(wù)的主要技術(shù)，指出IP 負(fù)載均衡技術(shù)是在負(fù)載調(diào)度器的實(shí)現(xiàn)技術(shù)中效率最高的。在已有的IP 負(fù)載均衡技術(shù)中，主要有通過網(wǎng)絡(luò)地址轉(zhuǎn)換（Network Address Translation）將一組服務(wù)器構(gòu)成一個(gè)高性能的、高可用的虛擬服務(wù)器，我們稱之為VS/NAT技術(shù)（Virtual Server via Network Address Translation）。在分析VS/NAT的缺點(diǎn)和網(wǎng)絡(luò)服務(wù)的非對(duì)稱性的基礎(chǔ)上，我們提出了通過IP 隧道實(shí)現(xiàn)虛擬服務(wù)器的方法VS/TUN（Virtual Server via IP Tunneling），和通過直接路由實(shí)現(xiàn)虛擬服務(wù)器的方法VS/DR（Virtual Server via Direct Routing），它們可以極大地提高系統(tǒng)的伸縮性。VS/NAT、VS/TUN和VS/DR技術(shù)是LVS 集群中實(shí)現(xiàn)的三種IP 負(fù)載均衡技術(shù)，我們將在文章中詳細(xì)描述它們的工作原理和各自的優(yōu)缺點(diǎn)。

在以下描述中，我們稱客戶的socket 和服務(wù)器的socket 之間的數(shù)據(jù)通訊為連接，無論它們是使用TCP 還是UDP 協(xié)議。下面簡(jiǎn)述當(dāng)前用服務(wù)器集群實(shí)現(xiàn)高可伸縮、高可用網(wǎng)絡(luò)服務(wù)的幾種負(fù)載調(diào)度方法，并列舉幾個(gè)在這方面有代表性的研究項(xiàng)目。

2. 實(shí)現(xiàn)虛擬服務(wù)的相關(guān)方法

在網(wǎng)絡(luò)服務(wù)中，一端是客戶程序，另一端是服務(wù)程序，在中間可能有代理程序。由此看來，可以在不同的層次上實(shí)現(xiàn)多臺(tái)服務(wù)器的負(fù)載均衡。用集群解決網(wǎng)絡(luò)服務(wù)性能問題的現(xiàn)有方法主要分為以下四類。

2.1. 基于RR-DNS 的解決方法

NCSA 的可伸縮的WEB 服務(wù)器系統(tǒng)就是最早基于RR-DNS （Round-Robin Domain Name System）的原型系統(tǒng)[1,2]。它的結(jié)構(gòu)和工作流程如下圖所示：

圖1：基于RR-DNS 的可伸縮WEB 服務(wù)器 (注：本圖來自文獻(xiàn)【9】)

有一組WEB 服務(wù)器，他們通過分布式文件系統(tǒng)AFS(Andrew File System)來共享所有的HTML 文檔。這組服務(wù)器擁有相同的域名（如www.ncsa.uiuc.edu ），當(dāng)用戶按照這個(gè)域名訪問時(shí), RR-DNS 服務(wù)器會(huì)把域名輪流解析到這組服務(wù)器的不同IP 地址，從而將訪問負(fù)載分到各臺(tái)服務(wù)器上。

這種方法帶來幾個(gè)問題。第一，域名服務(wù)器是一個(gè)分布式系統(tǒng)，是按照一定的層次結(jié)構(gòu)組織的。當(dāng)用戶就域名解析請(qǐng)求提交給本地的域名服務(wù)器，它會(huì)因不能直接解析而向上一級(jí)域名服務(wù)器提交，上一級(jí)域名服務(wù)器再依次向上提交，直到RR-DNS 域名服器把這個(gè)域名解析到其中一臺(tái)服務(wù)器的IP 地址?？梢?，從用戶到RR-DNS 間存在多臺(tái)域名服器，而它們都會(huì)緩沖已解析的名字到IP 地址的映射, 這會(huì)導(dǎo)致該域名服器組下所有用戶都會(huì)訪問同一WEB 服務(wù)器，出現(xiàn)不同WEB 服務(wù)器間嚴(yán)重的負(fù)載不平衡。為了保證在域名服務(wù)器中域名到IP 地址的映射不被長(zhǎng)久緩沖，RR-DNS 在域名到IP 地址的映射上設(shè)置一個(gè)TTL(Time To Live) 值，過了這一段時(shí)間，域名服務(wù)器將這個(gè)映射從緩沖中淘汰。當(dāng)用戶請(qǐng)求，它會(huì)再向上一級(jí)域名服器提交請(qǐng)求并進(jìn)行重新影射。這就涉及到如何設(shè)置這個(gè)TTL 值，若這個(gè)值太大，在這個(gè)TTL 期間，很多請(qǐng)求會(huì)被映射到同一臺(tái)WEB 服務(wù)器上，同樣會(huì)導(dǎo)致嚴(yán)重的負(fù)載不平衡。若這個(gè)值太小，例如是０，會(huì)導(dǎo)致本地域名服務(wù)器頻繁地向RR-DNS 提交請(qǐng)求，

增加了域名解析的網(wǎng)絡(luò)流量，同樣會(huì)使RR-DNS 服務(wù)器成為系統(tǒng)中一個(gè)新的瓶頸。

第二，用戶機(jī)器會(huì)緩沖從名字到IP 地址的映射，而不受TTL 值的影響，用戶的訪問請(qǐng)求會(huì)被送到同一臺(tái)WEB 服務(wù)器上。由于用戶訪問請(qǐng)求的突發(fā)性和訪問方式不同，例如有的人訪問一下就離開了，而有的人訪問可長(zhǎng)達(dá)幾個(gè)小時(shí)，所以各臺(tái)服務(wù)器間的負(fù)載仍存在傾斜（Skew ）而不能控制。假設(shè)用戶在每個(gè)會(huì)話中平均請(qǐng)求數(shù)為20，負(fù)載最大的服務(wù)器獲得的請(qǐng)求數(shù)額高于各服務(wù)器平均請(qǐng)求數(shù)的平均比率超過百分之三十。也就是說，當(dāng)TTL 值為0時(shí)，因?yàn)橛脩粼L問的突發(fā)性也會(huì)存在著較嚴(yán)重的負(fù)載不平衡。

第三，系統(tǒng)的可靠性和可維護(hù)性差。若一臺(tái)服務(wù)器失效，會(huì)導(dǎo)致將域名解析到該服務(wù)器的用戶看到服務(wù)中斷，即使用戶按“Reload”按鈕，也無濟(jì)于事。系統(tǒng)管理員也不能隨時(shí)地將一臺(tái)服務(wù)器切出服務(wù)進(jìn)行系統(tǒng)維護(hù)，如進(jìn)行操作系統(tǒng)和應(yīng)用軟件升級(jí)，這需要修改RR-DNS 服務(wù)器中的IP 地址列表，把該服務(wù)器的IP 地址從中劃掉，然后等上幾天或者更長(zhǎng)的時(shí)間，等所有域名服器將該域名到這臺(tái)服務(wù)器的映射淘汰，和所有映射到這臺(tái)服務(wù)器的客戶機(jī)不再使用該站點(diǎn)為止。

2.2. 基于客戶端的解決方法

基于客戶端的解決方法需要每個(gè)客戶程序都有一定的服務(wù)器集群的知識(shí)，進(jìn)而把以負(fù)載均衡的方式將請(qǐng)求發(fā)到不同的服務(wù)器。例如，Netscape Navigator瀏覽器訪問Netscape 的主頁時(shí)，它會(huì)隨機(jī)地從一百多臺(tái)服務(wù)器中挑選第N 臺(tái)，最后將請(qǐng)求送往wwwN.netscape.com 。然而，這不是很好的解決方法，Netscape 只是利用它的Navigator 避免了RR-DNS 解析的麻煩，當(dāng)使用IE 等其他瀏覽器不可避免的要進(jìn)行RR-DNS 解析。

Smart Client[3]是Berkeley 做的另一種基于客戶端的解決方法。服務(wù)提供一個(gè)Java Applet 在客戶方瀏覽器中運(yùn)行，Applet 向各個(gè)服務(wù)器發(fā)請(qǐng)求來收集服務(wù)器的負(fù)載等信息，再根據(jù)這些信息將客戶的請(qǐng)求發(fā)到相應(yīng)的服務(wù)器。高可用性也在Applet 中實(shí)現(xiàn)，當(dāng)服務(wù)器沒有響應(yīng)時(shí)，Applet 向另一個(gè)服務(wù)器轉(zhuǎn)發(fā)請(qǐng)求。這種方法的透明性不好，Applet 向各服務(wù)器查詢來收集信息會(huì)增加額外的網(wǎng)絡(luò)流量，不具有普遍的適用性。

2.3. 基于應(yīng)用層負(fù)載均衡調(diào)度的解決方法

多臺(tái)服務(wù)器通過高速的互聯(lián)網(wǎng)絡(luò)連接成一個(gè)集群系統(tǒng)，在前端有一個(gè)基于應(yīng)用層的負(fù)載調(diào)度器。當(dāng)用戶訪問請(qǐng)求到達(dá)調(diào)度器時(shí)，請(qǐng)求會(huì)提交給作負(fù)載均衡調(diào)度的應(yīng)用程序，分析請(qǐng)求，根據(jù)各個(gè)服務(wù)器的負(fù)載情況，選出一臺(tái)服務(wù)器，重寫請(qǐng)求并向選出的服務(wù)器訪問，取得結(jié)果后，再返回給用戶。

應(yīng)用層負(fù)載均衡調(diào)度的典型代表有Zeus 負(fù)載調(diào)度器[4]、pWeb[5]、Reverse-Proxy[6]和SWEB[7]等。Zeus 負(fù)載調(diào)度器是Zeus 公司的商業(yè)產(chǎn)品，它是在Zeus Web服務(wù)器程序改寫而成的，采用單進(jìn)程事件驅(qū)動(dòng)的服務(wù)器結(jié)構(gòu)。pWeb 就是一個(gè)基于Apache 1.1服務(wù)器程序改寫而成的并行WEB 調(diào)度程序，當(dāng)一個(gè)HTTP 請(qǐng)求到達(dá)時(shí)，pWeb 會(huì)選出一個(gè)服務(wù)器，重寫請(qǐng)求并向這個(gè)服務(wù)器發(fā)出改寫后的請(qǐng)求，等結(jié)果返回后，再將結(jié)果轉(zhuǎn)發(fā)給客戶。Reverse-Proxy 利用Apache 1.3.1中的Proxy 模塊和Rewrite 模塊實(shí)現(xiàn)一個(gè)可伸縮WEB 服務(wù)器，它與pWeb 的不同之處在于它要先從Proxy 的cache 中查找后，若沒有這個(gè)副本，

再選一臺(tái)服務(wù)器，向服務(wù)器發(fā)送請(qǐng)求，再將服務(wù)器返回的結(jié)果轉(zhuǎn)發(fā)給客戶。SWEB 是利用HTTP 中的redirect 錯(cuò)誤代碼，將客戶請(qǐng)求到達(dá)一臺(tái)WEB 服務(wù)器后，這個(gè)WEB 服務(wù)器根據(jù)自己的負(fù)載情況，自己處理請(qǐng)求，或者通過redirect 錯(cuò)誤代碼將客戶引到另一臺(tái)WEB 服務(wù)器，以實(shí)現(xiàn)一個(gè)可伸縮的WEB 服務(wù)器。

基于應(yīng)用層負(fù)載均衡調(diào)度的多服務(wù)器解決方法也存在一些問題。第一，系統(tǒng)處理開銷特別大，致使系統(tǒng)的伸縮性有限。當(dāng)請(qǐng)求到達(dá)負(fù)載均衡調(diào)度器至處理結(jié)束時(shí)，調(diào)度器需要進(jìn)行四次從核心到用戶空間或從用戶空間到核心空間的上下文切換和內(nèi)存復(fù)制；需要進(jìn)行二次TCP 連接，一次是從用戶到調(diào)度器，另一次是從調(diào)度器到真實(shí)服務(wù)器；需要對(duì)請(qǐng)求進(jìn)行分析和重寫。這些處理都需要不小的ＣＰＵ、內(nèi)存和網(wǎng)絡(luò)等資源開銷，且處理時(shí)間長(zhǎng)。所構(gòu)成系統(tǒng)的性能不能接近線性增加的，一般服務(wù)器組增至3或4臺(tái)時(shí)，調(diào)度器本身可能會(huì)成為新的瓶頸。所以，這種基于應(yīng)用層負(fù)載均衡調(diào)度的方法的伸縮性極其有限。第二，基于應(yīng)用層的負(fù)載均衡調(diào)度器對(duì)于不同的應(yīng)用，需要寫不同的調(diào)度器。以上幾個(gè)系統(tǒng)都是基于HTTP 協(xié)議，若對(duì)于FTP 、Mail 、POP3等應(yīng)用，都需要重寫調(diào)度器。

2.4. 基于IP 層負(fù)載均衡調(diào)度的解決方法

用戶通過虛擬IP 地址（Virtual IP Address）訪問服務(wù)時(shí)，訪問請(qǐng)求的報(bào)文會(huì)到達(dá)負(fù)載調(diào)度器，由它進(jìn)行負(fù)載均衡調(diào)度，從一組真實(shí)服務(wù)器選出一個(gè)，將報(bào)文的目標(biāo)地址Virtual IP Address 改寫成選定服務(wù)器的地址，報(bào)文的目標(biāo)端口改寫成選定服務(wù)器的相應(yīng)端口，最后將報(bào)文發(fā)送給選定的服務(wù)器。真實(shí)服務(wù)器的回應(yīng)報(bào)文經(jīng)過負(fù)載調(diào)度器時(shí)，將報(bào)文的源地址和源端口改為Virtual IP Address 和相應(yīng)的端口，再把報(bào)文發(fā)給用戶。Berkeley 的MagicRouter[8]、Cisco 的LocalDirector 、Alteon 的ACEDirector 和F5的Big/IP等都是使用網(wǎng)絡(luò)地址轉(zhuǎn)換方法。MagicRouter 是在Linux 1.3版本上應(yīng)用快速報(bào)文插入技術(shù)，使得進(jìn)行負(fù)載均衡調(diào)度的用戶進(jìn)程訪問網(wǎng)絡(luò)設(shè)備接近核心空間的速度，降低了上下文切換的處理開銷，但并不徹底，它只是研究的原型系統(tǒng)，沒有成為有用的系統(tǒng)存活下來。Cisco 的LocalDirector 、Alteon 的ACEDirector 和F5的Big/IP是非常昂貴的商品化系統(tǒng)，它們支持部分TCP/UDP協(xié)議，有些在ICMP 處理上存在問題。

IBM 的TCP Router[9]使用修改過的網(wǎng)絡(luò)地址轉(zhuǎn)換方法在SP/2系統(tǒng)實(shí)現(xiàn)可伸縮的WEB 服務(wù)器。TCP Router修改請(qǐng)求報(bào)文的目標(biāo)地址并把它轉(zhuǎn)發(fā)給選出的服務(wù)器，服務(wù)器能把響應(yīng)報(bào)文的源地址置為TCP Router地址而非自己的地址。這種方法的好處是響應(yīng)報(bào)文可以直接返回給客戶，壞處是每臺(tái)服務(wù)器的操作系統(tǒng)內(nèi)核都需要修改。IBM 的NetDispatcher[10]是TCP Router 的后繼者，它將報(bào)文轉(zhuǎn)發(fā)給服務(wù)器，而服務(wù)器在non-ARP 的設(shè)備配置路由器的地址。這種方法與LVS 集群中的VS/DR類似，它具有很高的可伸縮性，但一套在IBM SP/2和NetDispatcher 需要上百萬美金。總的來說，IBM 的技術(shù)還挺不錯(cuò)的。

在貝爾實(shí)驗(yàn)室的ONE-IP[11]中，每臺(tái)服務(wù)器都獨(dú)立的IP 地址，但都用IP Alias配置上同一VIP 地址，采用路由和廣播兩種方法分發(fā)請(qǐng)求，服務(wù)器收到請(qǐng)求后按VIP 地址處理請(qǐng)求