本文在分析服務(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.前言
我們先分析實(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ù)的非對稱性的基礎(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é)議。下面簡述當(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)和工作流程如下圖所示：
基于RR-DNS的可伸縮WEB服務(wù)器
有一組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)用戶就域名解析請求提交給本地的域名服務(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地址的映射不被長久緩沖，RR-DNS在域名到IP地址的映射上設(shè)置一個(gè)TTL(Time To Live)值，過了這一段時(shí)間，域名服務(wù)器將這個(gè)映射從緩沖中淘汰。當(dāng)用戶請求，它會(huì)再向上一級(jí)域名服器提交請求并進(jìn)行重新影射。這就涉及到如何設(shè)置這個(gè) TTL值，若這個(gè)值太大，在這個(gè)TTL期間，很多請求會(huì)被映射到同一臺(tái)WEB服務(wù)器上，同樣會(huì)導(dǎo)致嚴(yán)重的負(fù)載不平衡。若這個(gè)值太小，例如是０，會(huì)導(dǎo)致本地域名服務(wù)器頻繁地向RR-DNS提交請求，增加了域名解析的網(wǎng)絡(luò)流量，同樣會(huì)使RR-DNS服務(wù)器成為系統(tǒng)中一個(gè)新的瓶頸。
第二，用戶機(jī)器會(huì)緩沖從名字到IP地址的映射，而不受TTL值的影響，用戶的訪問請求會(huì)被送到同一臺(tái)WEB服務(wù)器上。由于用戶訪問請求的突發(fā)性和訪問方式不同，例如有的人訪問一下就離開了，而有的人訪問可長達(dá)幾個(gè)小時(shí)，所以各臺(tái)服務(wù)器間的負(fù)載仍存在傾斜（Skew）而不能控制。假設(shè)用戶在每個(gè)會(huì)話中平均請求數(shù)為20，負(fù)載最大的服務(wù)器獲得的請求數(shù)額高于各服務(wù)器平均請求數(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地址從中劃掉，然后等上幾天或者更長的時(shí)間，等所有域名服器將該域名到這臺(tái)服務(wù)器的映射淘汰，和所有映射到這臺(tái)服務(wù)器的客戶機(jī)不再使用該站點(diǎn)為止。
2.2. 基于客戶端的解決方法
基于客戶端的解決方法需要每個(gè)客戶程序都有一定的服務(wù)器集群的知識(shí)，進(jìn)而把以負(fù)載均衡的方式將請求發(fā)到不同的服務(wù)器。例如，Netscape Navigator瀏覽器訪問Netscape的主頁時(shí)，它會(huì)隨機(jī)地從一百多臺(tái)服務(wù)器中挑選第N臺(tái)，最后將請求送往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ā)請求來收集服務(wù)器的負(fù)載等信息，再根據(jù)這些信息將客戶的請求發(fā)到相應(yīng)的服務(wù)器。高可用性也在Applet中實(shí)現(xiàn)，當(dāng)服務(wù)器沒有響應(yīng)時(shí)，Applet向另一個(gè)服務(wù)器轉(zhuǎn)發(fā)請求。這種方法的透明性不好，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)用戶訪問請求到達(dá)調(diào)度器時(shí)，請求會(huì)提交給作負(fù)載均衡調(diào)度的應(yīng)用程序，分析請求，根據(jù)各個(gè)服務(wù)器的負(fù)載情況，選出一臺(tái)服務(wù)器，重寫請求并向選出的服務(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請求到達(dá)時(shí)，pWeb會(huì)選出一個(gè)服務(wù)器，重寫請求并向這個(gè)服務(wù)器發(fā)出改寫后的請求，等結(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ā)送請求，再將服務(wù)器返回的結(jié)果轉(zhuǎn)發(fā)給客戶。SWEB是利用HTTP中的redirect錯(cuò)誤代碼，將客戶請求到達(dá)一臺(tái)WEB服務(wù)器后，這個(gè)WEB服務(wù)器根據(jù)自己的負(fù)載情況，自己處理請求，或者通過redirect錯(cuò)誤代碼將客戶引到另一臺(tái)WEB服務(wù)器，以實(shí)現(xiàn)一個(gè)可伸縮的WEB服務(wù)器。
基于應(yīng)用層負(fù)載均衡調(diào)度的多服務(wù)器解決方法也存在一些問題。第一，系統(tǒng)處理開銷特別大，致使系統(tǒng)的伸縮性有限。當(dāng)請求到達(dá)負(fù)載均衡調(diào)度器至處理結(jié)束時(shí)，調(diào)度器需要進(jìn)行四次從核心到用戶空間或從用戶空間到核心空間的上下文切換和內(nèi)存復(fù)制；需要進(jìn)行二次TCP連接，一次是從用戶到調(diào)度器，另一次是從調(diào)度器到真實(shí)服務(wù)器；需要對請求進(jìn)行分析和重寫。這些處理都需要不小的ＣＰＵ、內(nèi)存和網(wǎng)絡(luò)等資源開銷，且處理時(shí)間長。所構(gòu)成系統(tǒng)的性能不能接近線性增加的，一般服務(wù)器組增至3或4臺(tái)時(shí)，調(diào)度器本身可能會(huì)成為新的瓶頸。所以，這種基于應(yīng)用層負(fù)載均衡調(diào)度的方法的伸縮性極其有限。第二，基于應(yīng)用層的負(fù)載均衡調(diào)度器對于不同的應(yīng)用，需要寫不同的調(diào)度器。以上幾個(gè)系統(tǒng)都是基于HTTP協(xié)議，若對于FTP、Mail、POP3等應(yīng)用，都需要重寫調(diào)度器。
2.4. 基于IP層負(fù)載均衡調(diào)度的解決方法
用戶通過虛擬IP地址（Virtual IP Address）訪問服務(wù)時(shí)，訪問請求的報(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修改請求報(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ā)請求，服務(wù)器收到請求后按VIP地址處理請求，并以VIP為源地址返回結(jié)果。這種方法也是為了避免回應(yīng)報(bào)文的重寫，但是每臺(tái)服務(wù)器用IP Alias配置上同一VIP地址，會(huì)導(dǎo)致地址沖突，有些操作系統(tǒng)會(huì)出現(xiàn)網(wǎng)絡(luò)失效。通過廣播分發(fā)請求，同樣需要修改服務(wù)器操作系統(tǒng)的源碼來過濾報(bào)文，使得只有一臺(tái)服務(wù)器處理廣播來的請求。
微軟的windows NT負(fù)載均衡服務(wù)（Windows NT Load Balancing Service，WLBS）[12]是1998年底收購Valence Research公司獲得的，它與ONE-IP中的基于本地過濾方法一樣。WLBS作為過濾器運(yùn)行在網(wǎng)卡驅(qū)動(dòng)程序和TCP/IP協(xié)議棧之間，獲得目標(biāo)地址為VIP的報(bào)文，它的過濾算法檢查報(bào)文的源IP地址和端口號(hào)，保證只有一臺(tái)服務(wù)器將報(bào)文交給上一層處理。但是，當(dāng)有新結(jié)點(diǎn)加入和有結(jié)點(diǎn)失效時(shí)，所有服務(wù)器需要協(xié)商一個(gè)新的過濾算法，這會(huì)導(dǎo)致所有有Session的連接中斷。同時(shí)，WLBS需要所有的服務(wù)器有相同的配置，如網(wǎng)卡速度和處理能力。
3. 通過NAT實(shí)現(xiàn)虛擬服務(wù)器（VS/NAT）
由于IPv4中IP地址空間的日益緊張和安全方面的原因，很多網(wǎng)絡(luò)使用保留IP地址（10.0.0.0/255.0.0.0、 172.16.0.0/255.128.0.0和192.168.0.0/255.255.0.0）[64, 65, 66]。這些地址不在Internet上使用，而是專門為內(nèi)部網(wǎng)絡(luò)預(yù)留的。當(dāng)內(nèi)部網(wǎng)絡(luò)中的主機(jī)要訪問Internet或被Internet訪問時(shí)，就需要采用網(wǎng)絡(luò)地址轉(zhuǎn)換（Network Address Translation, 以下簡稱NAT），將內(nèi)部地址轉(zhuǎn)化為Internets上可用的外部地址。NAT的工作原理是報(bào)文頭（目標(biāo)地址、源地址和端口等）被正確改寫后，客戶相信它們連接一個(gè)IP地址，而不同IP地址的服務(wù)器組也認(rèn)為它們是與客戶直接相連的。由此，可以用NAT方法將不同IP地址的并行網(wǎng)絡(luò)服務(wù)變成在一個(gè)IP地址上的一個(gè)虛擬服務(wù)。
VS/NAT的體系結(jié)構(gòu)如圖2所示。在一組服務(wù)器前有一個(gè)調(diào)度器，它們是通過Switch/HUB相連接的。這些服務(wù)器提供相同的網(wǎng)絡(luò)服務(wù)、相同的內(nèi)容，即不管請求被發(fā)送到哪一臺(tái)服務(wù)器，執(zhí)行結(jié)果是一樣的。服務(wù)的內(nèi)容可以復(fù)制到每臺(tái)服務(wù)器的本地硬盤上，可以通過網(wǎng)絡(luò)文件系統(tǒng)（如NFS）共享，也可以通過一個(gè)分布式文件系統(tǒng)來提供。
VS/NAT的體系結(jié)構(gòu)
客戶通過Virtual IP Address（虛擬服務(wù)的IP地址）訪問網(wǎng)絡(luò)服務(wù)時(shí)，請求報(bào)文到達(dá)調(diào)度器，調(diào)度器根據(jù)連接調(diào)度算法從一組真實(shí)服務(wù)器中選出一臺(tái)服務(wù)器，將報(bào)文的目標(biāo)地址 Virtual IP Address改寫成選定服務(wù)器的地址，報(bào)文的目標(biāo)端口改寫成選定服務(wù)器的相應(yīng)端口，最后將修改后的報(bào)文發(fā)送給選出的服務(wù)器。同時(shí)，調(diào)度器在連接Hash 表中記錄這個(gè)連接，當(dāng)這個(gè)連接的下一個(gè)報(bào)文到達(dá)時(shí)，從連接Hash表中可以得到原選定服務(wù)器的地址和端口，進(jìn)行同樣的改寫操作，并將報(bào)文傳給原選定的服務(wù)器。當(dāng)來自真實(shí)服務(wù)器的響應(yīng)報(bào)文經(jīng)過調(diào)度器時(shí)，調(diào)度器將報(bào)文的源地址和源端口改為Virtual IP Address和相應(yīng)的端口，再把報(bào)文發(fā)給用戶。我們在連接上引入一個(gè)狀態(tài)機(jī)，不同的報(bào)文會(huì)使得連接處于不同的狀態(tài)，不同的狀態(tài)有不同的超時(shí)值。在TCP 連接中，根據(jù)標(biāo)準(zhǔn)的TCP有限狀態(tài)機(jī)進(jìn)行狀態(tài)遷移，這里我們不一一敘述，請參見W. Richard Stevens的《TCP/IP Illustrated Volume I》；在UDP中，我們只設(shè)置一個(gè)UDP狀態(tài)。不同狀態(tài)的超時(shí)值是可以設(shè)置的，在缺省情況下，SYN狀態(tài)的超時(shí)為1分鐘，ESTABLISHED狀態(tài)的超時(shí)為15分鐘，F(xiàn)IN狀態(tài)的超時(shí)為1分鐘；UDP狀態(tài)的超時(shí)為5分鐘。當(dāng)連接終止或超時(shí)，調(diào)度器將這個(gè)連接從連接Hash表中刪除。
這樣，客戶所看到的只是在Virtual IP Address上提供的服務(wù)，而服務(wù)器集群的結(jié)構(gòu)對用戶是透明的。對改寫后的報(bào)文，應(yīng)用增量調(diào)整Checksum的算法調(diào)整TCP Checksum的值，避免了掃描整個(gè)報(bào)文來計(jì)算Checksum的開銷。
在一些網(wǎng)絡(luò)服務(wù)中，它們將IP地址或者端口號(hào)在報(bào)文的數(shù)據(jù)中傳送，若我們只對報(bào)文頭的IP地址和端口號(hào)作轉(zhuǎn)換，這樣就會(huì)出現(xiàn)不一致性，服務(wù)會(huì)中斷。所以，針對這些服務(wù)，需要編寫相應(yīng)的應(yīng)用模塊來轉(zhuǎn)換報(bào)文數(shù)據(jù)中的IP地址或者端口號(hào)。我們所知道有這個(gè)問題的網(wǎng)絡(luò)服務(wù)有FTP、IRC、H.323、 CUSeeMe、Real Audio、Real Video、Vxtreme / Vosiac、VDOLive、VIVOActive、True Speech、RSTP、PPTP、StreamWorks、NTT AudioLink、NTT SoftwareVision、Yamaha MIDPlug、iChat Pager、Quake和Diablo。
下面，舉個(gè)例子來進(jìn)一步說明VS/NAT，如圖所示：
VS/NAT的例子
VS/NAT 的配置如下表所示，所有到IP地址為202.103.106.5和端口為80的流量都被負(fù)載均衡地調(diào)度的真實(shí)服務(wù)器172.16.0.2:80和 172.16.0.3:8000上。目標(biāo)地址為202.103.106.5:21的報(bào)文被轉(zhuǎn)移到172.16.0.3:21上。而到其他端口的報(bào)文將被拒絕。
從以下的例子中，我們可以更詳細(xì)地了解報(bào)文改寫的流程。
訪問Web服務(wù)的報(bào)文可能有以下的源地址和目標(biāo)地址：
SOURCE202.100.1.2:3456DEST202.103.106.5:80
調(diào)度器從調(diào)度列表中選出一臺(tái)服務(wù)器，例如是172.16.0.3:8000。該報(bào)文會(huì)被改寫為如下地址，并將它發(fā)送給選出的服務(wù)器。
SOURCE202.100.1.2:3456DEST172.16.0.3:8000
從服務(wù)器返回到調(diào)度器的響應(yīng)報(bào)文如下：
SOURCE172.16.0.3:8000DEST202.100.1.2:3456
響應(yīng)報(bào)文的源地址會(huì)被改寫為虛擬服務(wù)的地址，再將報(bào)文發(fā)送給客戶：
SOURCE202.103.106.5:80DEST202.100.1.2:3456
這樣，客戶認(rèn)為是從202.103.106.5:80服務(wù)得到正確的響應(yīng)，而不會(huì)知道該請求是服務(wù)器172.16.0.2還是服務(wù)器172.16.0.3處理的。
4. 通過IP隧道實(shí)現(xiàn)虛擬服務(wù)器（VS/TUN）
在VS/NAT 的集群系統(tǒng)中，請求和響應(yīng)的數(shù)據(jù)報(bào)文都需要通過負(fù)載調(diào)度器，當(dāng)真實(shí)服務(wù)器的數(shù)目在10臺(tái)和20臺(tái)之間時(shí)，負(fù)載調(diào)度器將成為整個(gè)集群系統(tǒng)的新瓶頸。大多數(shù) Internet服務(wù)都有這樣的特點(diǎn)：請求報(bào)文較短而響應(yīng)報(bào)文往往包含大量的數(shù)據(jù)。如果能將請求和響應(yīng)分開處理，即在負(fù)載調(diào)度器中只負(fù)責(zé)調(diào)度請求而響應(yīng)直接返回給客戶，將極大地提高整個(gè)集群系統(tǒng)的吞吐量。
IP隧道（IP tunneling）是將一個(gè)IP報(bào)文封裝在另一個(gè)IP報(bào)文的技術(shù)，這可以使得目標(biāo)為一個(gè)IP地址的數(shù)據(jù)報(bào)文能被封裝和轉(zhuǎn)發(fā)到另一個(gè)IP地址。IP隧道技術(shù)亦稱為IP封裝技術(shù)（IP encapsulation）。IP隧道主要用于移動(dòng)主機(jī)和虛擬私有網(wǎng)絡(luò)（Virtual Private Network），在其中隧道都是靜態(tài)建立的，隧道一端有一個(gè)IP地址，另一端也有唯一的IP地址。
我們利用IP隧道技術(shù)將請求報(bào)文封裝轉(zhuǎn)發(fā)給后端服務(wù)器，響應(yīng)報(bào)文能從后端服務(wù)器直接返回給客戶。但在這里，后端服務(wù)器有一組而非一個(gè)，所以我們不可能靜態(tài)地建立一一對應(yīng)的隧道，而是動(dòng)態(tài)地選擇一臺(tái)服務(wù)器，將請求報(bào)文封裝和轉(zhuǎn)發(fā)給選出的服務(wù)器。這樣，我們可以利用IP隧道的原理將一組服務(wù)器上的網(wǎng)絡(luò)服務(wù)組成在一個(gè)IP地址上的虛擬網(wǎng)絡(luò)服務(wù)。 VS/TUN的體系結(jié)構(gòu)如圖4所示，各個(gè)服務(wù)器將VIP地址配置在自己的IP隧道設(shè)備上。
VS/TUN的體系結(jié)構(gòu)
VS/TUN 的工作流程如圖5所示：它的連接調(diào)度和管理與VS/NAT中的一樣，只是它的報(bào)文轉(zhuǎn)發(fā)方法不同。調(diào)度器根據(jù)各個(gè)服務(wù)器的負(fù)載情況，動(dòng)態(tài)地選擇一臺(tái)服務(wù)器，將請求報(bào)文封裝在另一個(gè)IP報(bào)文中，再將封裝后的IP報(bào)文轉(zhuǎn)發(fā)給選出的服務(wù)器；服務(wù)器收到報(bào)文后，先將報(bào)文解封獲得原來目標(biāo)地址為VIP的報(bào)文，服務(wù)器發(fā)現(xiàn)VIP地址被配置在本地的IP隧道設(shè)備上，所以就處理這個(gè)請求，然后根據(jù)路由表將響應(yīng)報(bào)文直接返回給客戶。
VS/TUN的工作流程
在這里需要指出，根據(jù)缺省的TCP/IP協(xié)議棧處理，請求報(bào)文的目標(biāo)地址為VIP，響應(yīng)報(bào)文的源地址肯定也為VIP，所以響應(yīng)報(bào)文不需要作任何修改，可以直接返回給客戶，客戶認(rèn)為得到正常的服務(wù)，而不會(huì)知道究竟是哪一臺(tái)服務(wù)器處理的。
半連接的TCP有限狀態(tài)機(jī)
5. 通過直接路由實(shí)現(xiàn)虛擬服務(wù)器（VS/DR）
跟VS/TUN 方法相同，VS/DR利用大多數(shù)Internet服務(wù)的非對稱特點(diǎn)，負(fù)載調(diào)度器中只負(fù)責(zé)調(diào)度請求，而服務(wù)器直接將響應(yīng)返回給客戶，可以極大地提高整個(gè)集群系統(tǒng)的吞吐量。該方法與IBM的NetDispatcher產(chǎn)品中使用的方法類似（其中服務(wù)器上的IP地址配置方法是相似的），但I(xiàn)BM的 NetDispatcher是非常昂貴的商品化產(chǎn)品，我們也不知道它內(nèi)部所使用的機(jī)制，其中有些是IBM的專利。
VS/DR的體系結(jié)構(gòu)如圖 7所示：調(diào)度器和服務(wù)器組都必須在物理上有一個(gè)網(wǎng)卡通過不分?jǐn)嗟木钟蚓W(wǎng)相連，如通過高速的交換機(jī)或者HUB相連。VIP地址為調(diào)度器和服務(wù)器組共享，調(diào)度器配置的VIP地址是對外可見的，用于接收虛擬服務(wù)的請求報(bào)文；所有的服務(wù)器把VIP地址配置在各自的Non-ARP網(wǎng)絡(luò)設(shè)備上，它對外面是不可見的，只是用于處理目標(biāo)地址為VIP的網(wǎng)絡(luò)請求。
VS/DR的體系結(jié)構(gòu)
VS/DR 的工作流程如圖8所示：它的連接調(diào)度和管理與VS/NAT和VS/TUN中的一樣，它的報(bào)文轉(zhuǎn)發(fā)方法又有不同，將報(bào)文直接路由給目標(biāo)服務(wù)器。在VS/DR 中，調(diào)度器根據(jù)各個(gè)服務(wù)器的負(fù)載情況，動(dòng)態(tài)地選擇一臺(tái)服務(wù)器，不修改也不封裝IP報(bào)文，而是將數(shù)據(jù)幀的mac地址改為選出服務(wù)器的MAC地址，再將修改后的數(shù)據(jù)幀在與服務(wù)器組的局域網(wǎng)上發(fā)送。因?yàn)閿?shù)據(jù)幀的MAC地址是選出的服務(wù)器，所以服務(wù)器肯定可以收到這個(gè)數(shù)據(jù)幀，從中可以獲得該IP報(bào)文。當(dāng)服務(wù)器發(fā)現(xiàn)報(bào)文的目標(biāo)地址VIP是在本地的網(wǎng)絡(luò)設(shè)備上，服務(wù)器處理這個(gè)報(bào)文，然后根據(jù)路由表將響應(yīng)報(bào)文直接返回給客戶。
VS/DR的工作流程
在VS/DR中，根據(jù)缺省的TCP/IP協(xié)議棧處理，請求報(bào)文的目標(biāo)地址為VIP，響應(yīng)報(bào)文的源地址肯定也為VIP，所以響應(yīng)報(bào)文不需要作任何修改，可以直接返回給客戶，客戶認(rèn)為得到正常的服務(wù)，而不會(huì)知道是哪一臺(tái)服務(wù)器處理的。
VS/DR負(fù)載調(diào)度器跟VS/TUN一樣只處于從客戶到服務(wù)器的半連接中，按照半連接的TCP有限狀態(tài)機(jī)進(jìn)行狀態(tài)遷移。
6.三種方法的優(yōu)缺點(diǎn)比較
三種IP負(fù)載均衡技術(shù)的優(yōu)缺點(diǎn)歸納在下表中：
_VS/NATVS/TUNVS/DRServeranyTunnelingNon-arp deviceserver networkprivateLAN/WANLANserver numberlow (10~20)High (100)High (100)server gatewayload balancerown routerOwn router
注：以上三種方法所能支持最大服務(wù)器數(shù)目的估計(jì)是假設(shè)調(diào)度器使用100M網(wǎng)卡，調(diào)度器的硬件配置與后端服務(wù)器的硬件配置相同，而且是對一般Web服務(wù)。使用更高的硬件配置（如千兆網(wǎng)卡和更快的處理器）作為調(diào)度器，調(diào)度器所能調(diào)度的服務(wù)器數(shù)量會(huì)相應(yīng)增加。當(dāng)應(yīng)用不同時(shí)，服務(wù)器的數(shù)目也會(huì)相應(yīng)地改變。所以，以上數(shù)據(jù)估計(jì)主要是為三種方法的伸縮性進(jìn)行量化比較。
6.1. Virtual Server via NAT
VS/NAT 的優(yōu)點(diǎn)是服務(wù)器可以運(yùn)行任何支持TCP/IP的操作系統(tǒng)，它只需要一個(gè)IP地址配置在調(diào)度器上，服務(wù)器組可以用私有的IP地址。缺點(diǎn)是它的伸縮能力有限，當(dāng)服務(wù)器結(jié)點(diǎn)數(shù)目升到20時(shí)，調(diào)度器本身有可能成為系統(tǒng)的新瓶頸，因?yàn)樵赩S/NAT中請求和響應(yīng)報(bào)文都需要通過負(fù)載調(diào)度器。 我們在Pentium 166 處理器的主機(jī)上測得重寫報(bào)文的平均延時(shí)為60us，性能更高的處理器上延時(shí)會(huì)短一些。假設(shè)TCP報(bào)文的平均長度為536 Bytes，則調(diào)度器的最大吞吐量為8.93 MBytes/s. 我們再假設(shè)每臺(tái)服務(wù)器的吞吐量為800KBytes/s，這樣一個(gè)調(diào)度器可以帶動(dòng)10臺(tái)服務(wù)器。（注：這是很早以前測得的數(shù)據(jù)）
基于 VS/NAT的的集群系統(tǒng)可以適合許多服務(wù)器的性能要求。如果負(fù)載調(diào)度器成為系統(tǒng)新的瓶頸，可以有三種方法解決這個(gè)問題：混合方法、VS/TUN和 VS/DR。在DNS混合集群系統(tǒng)中，有若干個(gè)VS/NAT負(fù)載調(diào)度器，每個(gè)負(fù)載調(diào)度器帶自己的服務(wù)器集群，同時(shí)這些負(fù)載調(diào)度器又通過RR-DNS組成簡單的域名。但VS/TUN和VS/DR是提高系統(tǒng)吞吐量的更好方法。
對于那些將IP地址或者端口號(hào)在報(bào)文數(shù)據(jù)中傳送的網(wǎng)絡(luò)服務(wù)，需要編寫相應(yīng)的應(yīng)用模塊來轉(zhuǎn)換報(bào)文數(shù)據(jù)中的IP地址或者端口號(hào)。這會(huì)帶來實(shí)現(xiàn)的工作量，同時(shí)應(yīng)用模塊檢查報(bào)文的開銷會(huì)降低系統(tǒng)的吞吐率。
6.2. Virtual Server via IP Tunneling
在VS/TUN 的集群系統(tǒng)中，負(fù)載調(diào)度器只將請求調(diào)度到不同的后端服務(wù)器，后端服務(wù)器將應(yīng)答的數(shù)據(jù)直接返回給用戶。這樣，負(fù)載調(diào)度器就可以處理大量的請求，它甚至可以調(diào)度百臺(tái)以上的服務(wù)器（同等規(guī)模的服務(wù)器），而它不會(huì)成為系統(tǒng)的瓶頸。即使負(fù)載調(diào)度器只有100Mbps的全雙工網(wǎng)卡，整個(gè)系統(tǒng)的最大吞吐量可超過 1Gbps。所以，VS/TUN可以極大地增加負(fù)載調(diào)度器調(diào)度的服務(wù)器數(shù)量。VS/TUN調(diào)度器可以調(diào)度上百臺(tái)服務(wù)器，而它本身不會(huì)成為系統(tǒng)的瓶頸，可以用來構(gòu)建高性能的超級(jí)服務(wù)器。
VS/TUN技術(shù)對服務(wù)器有要求，即所有的服務(wù)器必須支持“IP Tunneling”或者“IP Encapsulation”協(xié)議。目前，VS/TUN的后端服務(wù)器主要運(yùn)行Linux操作系統(tǒng)，我們沒對其他操作系統(tǒng)進(jìn)行測試。因?yàn)?ldquo;IP Tunneling”正成為各個(gè)操作系統(tǒng)的標(biāo)準(zhǔn)協(xié)議，所以VS/TUN應(yīng)該會(huì)適用運(yùn)行其他操作系統(tǒng)的后端服務(wù)器。
6.3. Virtual Server via Direct Routing
跟VS/TUN方法一樣，VS/DR調(diào)度器只處理客戶到服務(wù)器端的連接，響應(yīng)數(shù)據(jù)可以直接從獨(dú)立的網(wǎng)絡(luò)路由返回給客戶。這可以極大地提高LVS集群系統(tǒng)的伸縮性。
跟VS/TUN相比，這種方法沒有IP隧道的開銷，但是要求負(fù)載調(diào)度器與實(shí)際服務(wù)器都有一塊網(wǎng)卡連在同一物理網(wǎng)段上，服務(wù)器網(wǎng)絡(luò)設(shè)備（或者設(shè)備別名）不作ARP響應(yīng)，或者能將報(bào)文重定向（Redirect）到本地的Socket端口上。
7.小結(jié)
本文主要講述了LVS集群中的三種IP負(fù)載均衡技術(shù)。在分析網(wǎng)絡(luò)地址轉(zhuǎn)換方法（VS/NAT）的缺點(diǎn)和網(wǎng)絡(luò)服務(wù)的非對稱性的基礎(chǔ)上，我們給出了通過IP隧道實(shí)現(xiàn)虛擬服務(wù)器的方法VS/TUN，和通過直接路由實(shí)現(xiàn)虛擬服務(wù)器的方法VS/DR，極大地提高了系統(tǒng)的伸縮性。
