LVS集羣中的IP負載均衡技術

LVS集羣中的IP負載均衡技術

章文嵩 (wensong@linux-vs.org)
2002 年 4 月

本文在分析服務器集羣實現虛擬網絡服務的相關技術上，詳細描述了LVS集羣中實現的三種IP負載均衡技術（VS/NAT、VS/TUN和VS/DR）的工做原理，以及它們的優缺點。

1.前言
在 前面文章中，講述了可伸縮網絡服務的幾種結構，它們都須要一個前端的負載調度器（或者多個進行主從備份）。咱們先分析實現虛擬網絡服務的主要技術，指出 IP負載均衡技術是在負載調度器的實現技術中效率最高的。在已有的IP負載均衡技術中，主要有經過網絡地址轉換（Network Address Translation）將一組服務器構成一個高性能的、高可用的虛擬服務器，咱們稱之爲VS/NAT技術（Virtual Server via Network Address Translation）。在分析VS/NAT的缺點和網絡服務的非對稱性的基礎上，咱們提出了經過IP隧道實現虛擬服務器的方法VS/TUN （Virtual Server via IP Tunneling），和經過直接路由實現虛擬服務器的方法VS/DR（Virtual Server via Direct Routing），它們能夠極大地提升系統的伸縮性。VS/NAT、VS/TUN和VS/DR技術是LVS集羣中實現的三種IP負載均衡技術，咱們將在文 章中詳細描述它們的工做原理和各自的優缺點。

在如下描述中，咱們稱客戶的socket和服務器的socket之間的數據通信爲鏈接，不管它們是使用TCP仍是UDP協議。下面簡述當前用服務器集羣實現高可伸縮、高可用網絡服務的幾種負載調度方法，並列舉幾個在這方面有表明性的研究項目。

2. 實現虛擬服務的相關方法
在網絡服務中，一端是客戶程序，另外一端是服務程序，在中間可能有代理程序。由此看來，能夠在不一樣的層次上實現多臺服務器的負載均衡。用集羣解決網絡服務性能問題的現有方法主要分爲如下四類。

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

NCSA的可伸縮的WEB服務器系統就是最先基於RR-DNS（Round-Robin Domain Name System）的原型系統[1,2]。它的結構和工做流程以下圖所示：

圖1：基於RR-DNS的可伸縮WEB服務器 (注：本圖來自文獻【9】)

有 一組WEB服務器，他們經過分佈式文件系統AFS(Andrew File System)來共享全部的HTML文檔。這組服務器擁有相同的域名（如www.ncsa.uiuc.edu），當用戶按照這個域名訪問時, RR-DNS服務器會把域名輪流解析到這組服務器的不一樣IP地址，從而將訪問負載分到各臺服務器上。

這種方法帶來幾個問題。第一，域名服務 器是一個分佈式系統，是按照必定的層次結構組織的。當用戶就域名解析請求提交給本地的域名服務器，它會因不能直接解析而向上一級域名服務器提交，上一級域 名服務器再依次向上提交，直到RR-DNS域名服器把這個域名解析到其中一臺服務器的IP地址。可見，從用戶到RR-DNS間存在多臺域名服器，而它們都 會緩衝已解析的名字到IP地址的映射,這會致使該域名服器組下全部用戶都會訪問同一WEB服務器，出現不一樣WEB服務器間嚴重的負載不平衡。爲了保證在域 名服務器中域名到IP地址的映射不被長久緩衝，RR-DNS在域名到IP地址的映射上設置一個TTL(Time To Live)值，過了這一段時間，域名服務器將這個映射從緩衝中淘汰。當用戶請求，它會再向上一級域名服器提交請求並進行從新影射。這就涉及到如何設置這個 TTL值，若這個值太大，在這個TTL期間，不少請求會被映射到同一臺WEB服務器上，一樣會致使嚴重的負載不平衡。若這個值過小，例如是０，會致使本地 域名服務器頻繁地向RR-DNS提交請求，增長了域名解析的網絡流量，一樣會使RR-DNS服務器成爲系統中一個新的瓶頸。

第二，用戶機器 會緩衝從名字到IP地址的映射，而不受TTL值的影響，用戶的訪問請求會被送到同一臺WEB服務器上。因爲用戶訪問請求的突發性和訪問方式不一樣，例若有的 人訪問一下就離開了，而有的人訪問可長達幾個小時，因此各臺服務器間的負載仍存在傾斜（Skew）而不能控制。假設用戶在每一個會話中平均請求數爲20，負 載最大的服務器得到的請求數額高於各服務器平均請求數的平均比率超過百分之三十。也就是說，當TTL值爲0時，由於用戶訪問的突發性也會存在着較嚴重的負 載不平衡。

第三，系統的可靠性和可維護性差。若一臺服務器失效，會致使將域名解析到該服務器的用戶看到服務中斷，即便用戶按 「Reload」按鈕，也無濟於事。系統管理員也不能隨時地將一臺服務器切出服務進行系統維護，如進行操做系統和應用軟件升級，這須要修改RR-DNS服 務器中的IP地址列表，把該服務器的IP地址從中劃掉，而後等上幾天或者更長的時間，等全部域名服器將該域名到這臺服務器的映射淘汰，和全部映射到這臺服 務器的客戶機再也不使用該站點爲止。

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

基 於客戶端的解決方法須要每一個客戶程序都有必定的服務器集羣的知識，進而把以負載均衡的方式將請求發到不一樣的服務器。例如，Netscape Navigator瀏覽器訪問Netscape的主頁時，它會隨機地從一百多臺服務器中挑選第N臺，最後將請求送往wwwN.netscape.com。 然而，這不是很好的解決方法，Netscape只是利用它的Navigator避免了RR-DNS解析的麻煩，當使用IE等其餘瀏覽器不可避免的要進行 RR-DNS解析。

Smart Client[3]是Berkeley作的另外一種基於客戶端的解決方法。服務提供一個Java Applet在客戶方瀏覽器中運行，Applet向各個服務器發請求來收集服務器的負載等信息，再根據這些信息將客戶的請求發到相應的服務器。高可用性也 在Applet中實現，當服務器沒有響應時，Applet向另外一個服務器轉發請求。這種方法的透明性很差，Applet向各服務器查詢來收集信息會增長額 外的網絡流量，不具備廣泛的適用性。

2.3. 基於應用層負載均衡調度的解決方法

多 臺服務器經過高速的互聯網絡鏈接成一個集羣系統，在前端有一個基於應用層的負載調度器。當用戶訪問請求到達調度器時，請求會提交給做負載均衡調度的應用程 序，分析請求，根據各個服務器的負載狀況，選出一臺服務器，重寫請求並向選出的服務器訪問，取得結果後，再返回給用戶。

應用層負載均衡調度 的典型表明有Zeus負載調度器[4]、pWeb[5]、Reverse-Proxy[6]和SWEB[7]等。Zeus負載調度器是Zeus公司的商業 產品，它是在Zeus Web服務器程序改寫而成的，採用單進程事件驅動的服務器結構。pWeb就是一個基於Apache 1.1服務器程序改寫而成的並行WEB調度程序，當一個HTTP請求到達時，pWeb會選出一個服務器，重寫請求並向這個服務器發出改寫後的請求，等結果 返回後，再將結果轉發給客戶。Reverse-Proxy利用Apache 1.3.1中的Proxy模塊和Rewrite模塊實現一個可伸縮WEB服務器，它與pWeb的不一樣之處在於它要先從Proxy的cache中查找後，若 沒有這個副本，再選一臺服務器，向服務器發送請求，再將服務器返回的結果轉發給客戶。SWEB是利用HTTP中的redirect錯誤代碼，將客戶請求到 達一臺WEB服務器後，這個WEB服務器根據本身的負載狀況，本身處理請求，或者經過redirect錯誤代碼將客戶引到另外一臺WEB服務器，以實現一個 可伸縮的WEB服務器。

基於應用層負載均衡調度的多服務器解決方法也存在一些問題。第一，系統處理開銷特別大，導致系統的伸縮性有限。當請 求到達負載均衡調度器至處理結束時，調度器須要進行四次從核心到用戶空間或從用戶空間到核心空間的上下文切換和內存複製；須要進行二次TCP鏈接，一次是 從用戶到調度器，另外一次是從調度器到真實服務器；須要對請求進行分析和重寫。這些處理都須要不小的ＣＰＵ、內存和網絡等資源開銷，且處理時間長。所構成系 統的性能不能接近線性增長的，通常服務器組增至3或4臺時，調度器自己可能會成爲新的瓶頸。因此，這種基於應用層負載均衡調度的方法的伸縮性極其有限。第 二，基於應用層的負載均衡調度器對於不一樣的應用，須要寫不一樣的調度器。以上幾個系統都是基於HTTP協議，若對於FTP、Mail、POP3等應用，都需 要重寫調度器。

2.4. 基於IP層負載均衡調度的解決方法

用 戶經過虛擬IP地址（Virtual IP Address）訪問服務時，訪問請求的報文會到達負載調度器，由它進行負載均衡調度，從一組真實服務器選出一個，將報文的目標地址Virtual IP Address改寫成選定服務器的地址，報文的目標端口改寫成選定服務器的相應端口，最後將報文發送給選定的服務器。真實服務器的迴應報文通過負載調度器 時，將報文的源地址和源端口改成Virtual IP Address和相應的端口，再把報文發給用戶。Berkeley的MagicRouter[8]、Cisco的LocalDirector、 Alteon的ACEDirector和F5的Big/IP等都是使用網絡地址轉換方法。MagicRouter是在Linux 1.3版本上應用快速報文插入技術，使得進行負載均衡調度的用戶進程訪問網絡設備接近核心空間的速度，下降了上下文切換的處理開銷，但並不完全，它只是研 究的原型系統，沒有成爲有用的系統存活下來。Cisco的LocalDirector、Alteon的ACEDirector和F5的Big/IP是很是 昂貴的商品化系統，它們支持部分TCP/UDP協議，有些在ICMP處理上存在問題。

IBM的TCP Router[9]使用修改過的網絡地址轉換方法在SP/2系統實現可伸縮的WEB服務器。TCP Router修改請求報文的目標地址並把它轉發給選出的服務器，服務器能把響應報文的源地址置爲TCP Router地址而非本身的地址。這種方法的好處是響應報文能夠直接返回給客戶，壞處是每臺服務器的操做系統內核都須要修改。IBM的 NetDispatcher[10]是TCP Router的後繼者，它將報文轉發給服務器，而服務器在non-ARP的設備配置路由器的地址。這種方法與LVS集羣中的VS/DR相似，它具備很高的 可伸縮性，但一套在IBM SP/2和NetDispatcher須要上百萬美金。總的來講，IBM的技術還挺不錯的。

在貝爾實驗室的 ONE-IP[11]中，每臺服務器都獨立的IP地址，但都用IP Alias配置上同一VIP地址，採用路由和廣播兩種方法分發請求，服務器收到請求後按VIP地址處理請求，並以VIP爲源地址返回結果。這種方法也是爲 了避免迴應報文的重寫，可是每臺服務器用IP Alias配置上同一VIP地址，會致使地址衝突，有些操做系統會出現網絡失效。經過廣播分發請求，一樣須要修改服務器操做系統的源碼來過濾報文，使得只 有一臺服務器處理廣播來的請求。

微軟的Windows NT負載均衡服務（Windows NT Load Balancing Service，WLBS）[12]是1998年末收購Valence Research公司得到的，它與ONE-IP中的基於本地過濾方法同樣。WLBS做爲過濾器運行在網卡驅動程序和TCP/IP協議棧之間，得到目標地址 爲VIP的報文，它的過濾算法檢查報文的源IP地址和端口號，保證只有一臺服務器將報文交給上一層處理。可是，當有新結點加入和有結點失效時，全部服務器 須要協商一個新的過濾算法，這會致使全部有Session的鏈接中斷。同時，WLBS須要全部的服務器有相同的配置，如網卡速度和處理能力。

3. 經過NAT實現虛擬服務器（VS/NAT）

由 於IPv4中IP地址空間的日益緊張和安全方面的緣由，不少網絡使用保留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上使用，而是專門爲內部網絡預留的。當內部網絡中的主機要訪問Internet或被Internet訪問時，就須要 採用網絡地址轉換（Network Address Translation, 如下簡稱NAT），將內部地址轉化爲Internets上可用的外部地址。NAT的工做原理是報文頭（目標地址、源地址和端口等）被正確改寫後，客戶相信 它們鏈接一個IP地址，而不一樣IP地址的服務器組也認爲它們是與客戶直接相連的。由此，能夠用NAT方法將不一樣IP地址的並行網絡服務變成在一個IP地址 上的一個虛擬服務。

VS/NAT的體系結構如圖2所示。在一組服務器前有一個調度器，它們是經過Switch/HUB相鏈接的。這些服務器 提供相同的網絡服務、相同的內容，即無論請求被髮送到哪一臺服務器，執行結果是同樣的。服務的內容能夠複製到每臺服務器的本地硬盤上，能夠經過網絡文件系 統（如NFS）共享，也能夠經過一個分佈式文件系統來提供。

圖2：VS/NAT的體系結構

客 戶經過Virtual IP Address（虛擬服務的IP地址）訪問網絡服務時，請求報文到達調度器，調度器根據鏈接調度算法從一組真實服務器中選出一臺服務器，將報文的目標地址 Virtual IP Address改寫成選定服務器的地址，報文的目標端口改寫成選定服務器的相應端口，最後將修改後的報文發送給選出的服務器。同時，調度器在鏈接Hash 表中記錄這個鏈接，當這個鏈接的下一個報文到達時，從鏈接Hash表中能夠獲得原選定服務器的地址和端口，進行一樣的改寫操做，並將報文傳給原選定的服務 器。當來自真實服務器的響應報文通過調度器時，調度器將報文的源地址和源端口改成Virtual IP Address和相應的端口，再把報文發給用戶。咱們在鏈接上引入一個狀態機，不一樣的報文會使得鏈接處於不一樣的狀態，不一樣的狀態有不一樣的超時值。在TCP 鏈接中，根據標準的TCP有限狀態機進行狀態遷移，這裏咱們不一一敘述，請參見W. Richard Stevens的《TCP/IP Illustrated Volume I》；在UDP中，咱們只設置一個UDP狀態。不一樣狀態的超時值是能夠設置的，在缺省狀況下，SYN狀態的超時爲1分鐘，ESTABLISHED狀態的超 時爲15分鐘，FIN狀態的超時爲1分鐘；UDP狀態的超時爲5分鐘。當鏈接終止或超時，調度器將這個鏈接從鏈接Hash表中刪除。

這樣，客戶所看到的只是在Virtual IP Address上提供的服務，而服務器集羣的結構對用戶是透明的。對改寫後的報文，應用增量調整Checksum的算法調整TCP Checksum的值，避免了掃描整個報文來計算Checksum的開銷。

在 一些網絡服務中，它們將IP地址或者端口號在報文的數據中傳送，若咱們只對報文頭的IP地址和端口號做轉換，這樣就會出現不一致性，服務會中斷。因此，針 對這些服務，須要編寫相應的應用模塊來轉換報文數據中的IP地址或者端口號。咱們所知道有這個問題的網絡服務有FTP、IRC、H.32三、 CUSeeMe、Real Audio、Real Video、Vxtreme / Vosiac、VDOLive、VIVOActive、True Speech、RSTP、PPTP、StreamWorks、NTT AudioLink、NTT SoftwareVision、Yamaha MIDPlug、iChat Pager、Quake和Diablo。

下面，舉個例子來進一步說明VS/NAT，如圖3所示：

圖3：VS/NAT的例子

VS/NAT 的配置以下表所示，全部到IP地址爲202.103.106.5和端口爲80的流量都被負載均衡地調度的真實服務器172.16.0.2:80和 172.16.0.3:8000上。目標地址爲202.103.106.5:21的報文被轉移到172.16.0.3:21上。而到其餘端口的報文將被拒 絕。

Protocol	Virtual IP Address	Port	Real IP Address	Port	Weight
TCP	202.103.106.5	80	172.16.0.2	80	1
			172.16.0.3	8000	2
TCP	202.103.106.5	21	172.16.0.3	21	1

從如下的例子中，咱們能夠更詳細地瞭解報文改寫的流程。

訪問Web服務的報文可能有如下的源地址和目標地址：

SOURCE

202.100.1.2:3456

DEST

202.103.106.5:80

調度器從調度列表中選出一臺服務器，例如是172.16.0.3:8000。該報文會被改寫爲以下地址，並將它發送給選出的服務器。

SOURCE

202.100.1.2:3456

DEST

172.16.0.3:8000

從服務器返回到調度器的響應報文以下：

SOURCE

172.16.0.3:8000

DEST

202.100.1.2:3456

響應報文的源地址會被改寫爲虛擬服務的地址，再將報文發送給客戶：

SOURCE

202.103.106.5:80

DEST

202.100.1.2:3456

這樣，客戶認爲是從202.103.106.5:80服務獲得正確的響應，而不會知道該請求是服務器172.16.0.2仍是服務器172.16.0.3處理的。

4. 經過IP隧道實現虛擬服務器（VS/TUN）

在VS/NAT 的集羣系統中，請求和響應的數據報文都須要經過負載調度器，當真實服務器的數目在10臺和20臺之間時，負載調度器將成爲整個集羣系統的新瓶頸。大多數 Internet服務都有這樣的特色：請求報文較短而響應報文每每包含大量的數據。若是能將請求和響應分開處理，即在負載調度器中只負責調度請求而響應直 接返回給客戶，將極大地提升整個集羣系統的吞吐量。

IP隧道（IP tunneling）是將一個IP報文封裝在另外一個IP報文的技術，這可使得目標爲一個IP地址的數據報文能被封裝和轉發到另外一個IP地址。IP隧道技 術亦稱爲IP封裝技術（IP encapsulation）。IP隧道主要用於移動主機和虛擬私有網絡（Virtual Private Network），在其中隧道都是靜態創建的，隧道一端有一個IP地址，另外一端也有惟一的IP地址。

咱們利用IP隧道技術將請求報文封裝轉 發給後端服務器，響應報文能從後端服務器直接返回給客戶。但在這裏，後端服務器有一組而非一個，因此咱們不可能靜態地創建一一對應的隧道，而是動態地選擇 一臺服務器，將請求報文封裝和轉發給選出的服務器。這樣，咱們能夠利用IP隧道的原理將一組服務器上的網絡服務組成在一個IP地址上的虛擬網絡服務。 VS/TUN的體系結構如圖4所示，各個服務器將VIP地址配置在本身的IP隧道設備上。

圖4：VS/TUN的體系結構

VS/TUN 的工做流程如圖5所示：它的鏈接調度和管理與VS/NAT中的同樣，只是它的報文轉發方法不一樣。調度器根據各個服務器的負載狀況，動態地選擇一臺服務器， 將請求報文封裝在另外一個IP報文中，再將封裝後的IP報文轉發給選出的服務器；服務器收到報文後，先將報文解封得到原來目標地址爲VIP的報文，服務器發 現VIP地址被配置在本地的IP隧道設備上，因此就處理這個請求，而後根據路由表將響應報文直接返回給客戶。

圖5：VS/TUN的工做流程

在這裏須要指出，根據缺省的TCP/IP協議棧處理，請求報文的目標地址爲VIP，響應報文的源地址確定也爲VIP，因此響應報文不須要做任何修改，能夠直接返回給客戶，客戶認爲獲得正常的服務，而不會知道到底是哪一臺服務器處理的。

圖6：半鏈接的TCP有限狀態機

5. 經過直接路由實現虛擬服務器（VS/DR）

跟VS/TUN 方法相同，VS/DR利用大多數Internet服務的非對稱特色，負載調度器中只負責調度請求，而服務器直接將響應返回給客戶，能夠極大地提升整個集羣 系統的吞吐量。該方法與IBM的NetDispatcher產品中使用的方法相似（其中服務器上的IP地址配置方法是類似的），但IBM的 NetDispatcher是很是昂貴的商品化產品，咱們也不知道它內部所使用的機制，其中有些是IBM的專利。

VS/DR的體系結構如圖 7所示：調度器和服務器組都必須在物理上有一個網卡經過不分斷的局域網相連，如經過高速的交換機或者HUB相連。VIP地址爲調度器和服務器組共享，調度 器配置的VIP地址是對外可見的，用於接收虛擬服務的請求報文；全部的服務器把VIP地址配置在各自的Non-ARP網絡設備上，它對外面是不可見的，只 是用於處理目標地址爲VIP的網絡請求。

圖7：VS/DR的體系結構

VS/DR 的工做流程如圖8所示：它的鏈接調度和管理與VS/NAT和VS/TUN中的同樣，它的報文轉發方法又有不一樣，將報文直接路由給目標服務器。在VS/DR 中，調度器根據各個服務器的負載狀況，動態地選擇一臺服務器，不修改也不封裝IP報文，而是將數據幀的MAC地址改成選出服務器的MAC地址，再將修改後 的數據幀在與服務器組的局域網上發送。由於數據幀的MAC地址是選出的服務器，因此服務器確定能夠收到這個數據幀，從中能夠得到該IP報文。當服務器發現 報文的目標地址VIP是在本地的網絡設備上，服務器處理這個報文，而後根據路由表將響應報文直接返回給客戶。

圖8：VS/DR的工做流程

在VS/DR中，根據缺省的TCP/IP協議棧處理，請求報文的目標地址爲VIP，響應報文的源地址確定也爲VIP，因此響應報文不須要做任何修改，能夠直接返回給客戶，客戶認爲獲得正常的服務，而不會知道是哪一臺服務器處理的。

VS/DR負載調度器跟VS/TUN同樣只處於從客戶到服務器的半鏈接中，按照半鏈接的TCP有限狀態機進行狀態遷移。

6.三種方法的優缺點比較

三種IP負載均衡技術的優缺點概括在下表中：

_	VS/NAT	VS/TUN	VS/DR
Server	any	Tunneling	Non-arp device
server network	private	LAN/WAN	LAN
server number	low (10~20)	High (100)	High (100)
server gateway	load balancer	own router	Own router

注： 以上三種方法所能支持最大服務器數目的估計是假設調度器使用100M網卡，調度器的硬件配置與後端服務器的硬件配置相同，並且是對通常Web服務。使用更 高的硬件配置（如千兆網卡和更快的處理器）做爲調度器，調度器所能調度的服務器數量會相應增長。當應用不一樣時，服務器的數目也會相應地改變。因此，以上數 據估計主要是爲三種方法的伸縮性進行量化比較。

6.1. Virtual Server via NAT

VS/NAT 的優勢是服務器能夠運行任何支持TCP/IP的操做系統，它只須要一個IP地址配置在調度器上，服務器組能夠用私有的IP地址。缺點是它的伸縮能力有限， 當服務器結點數目升到20時，調度器自己有可能成爲系統的新瓶頸，由於在VS/NAT中請求和響應報文都須要經過負載調度器。 咱們在Pentium 166 處理器的主機上測得重寫報文的平均延時爲60us，性能更高的處理器上延時會短一些。假設TCP報文的平均長度爲536 Bytes，則調度器的最大吞吐量爲8.93 MBytes/s. 咱們再假設每臺服務器的吞吐量爲800KBytes/s，這樣一個調度器能夠帶動10臺服務器。（注：這是很早之前測得的數據）

基於 VS/NAT的的集羣系統能夠適合許多服務器的性能要求。若是負載調度器成爲系統新的瓶頸，能夠有三種方法解決這個問題：混合方法、VS/TUN和 VS/DR。在DNS混合集羣系統中，有若干個VS/NAT負載調度器，每一個負載調度器帶本身的服務器集羣，同時這些負載調度器又經過RR-DNS組成簡 單的域名。但VS/TUN和VS/DR是提升系統吞吐量的更好方法。

對於那些將IP地址或者端口號在報文數據中傳送的網絡服務，須要編寫相應的應用模塊來轉換報文數據中的IP地址或者端口號。這會帶來實現的工做量，同時應用模塊檢查報文的開銷會下降系統的吞吐率。

6.2. Virtual Server via IP Tunneling

在VS/TUN 的集羣系統中，負載調度器只將請求調度到不一樣的後端服務器，後端服務器將應答的數據直接返回給用戶。這樣，負載調度器就能夠處理大量的請求，它甚至能夠調 度百臺以上的服務器（同等規模的服務器），而它不會成爲系統的瓶頸。即便負載調度器只有100Mbps的全雙工網卡，整個系統的最大吞吐量可超過 1Gbps。因此，VS/TUN能夠極大地增長負載調度器調度的服務器數量。VS/TUN調度器能夠調度上百臺服務器，而它自己不會成爲系統的瓶頸，能夠 用來構建高性能的超級服務器。

VS/TUN技術對服務器有要求，即全部的服務器必須支持「IP Tunneling」或者「IP Encapsulation」協議。目前，VS/TUN的後端服務器主要運行Linux操做系統，咱們沒對其餘操做系統進行測試。由於「IP Tunneling」正成爲各個操做系統的標準協議，因此VS/TUN應該會適用運行其餘操做系統的後端服務器。

6.3. Virtual Server via Direct Routing

跟VS/TUN方法同樣，VS/DR調度器只處理客戶到服務器端的鏈接，響應數據能夠直接從獨立的網絡路由返回給客戶。這能夠極大地提升LVS集羣系統的伸縮性。

跟VS/TUN相比，這種方法沒有IP隧道的開銷，可是要求負載調度器與實際服務器都有一塊網卡連在同一物理網段上，服務器網絡設備（或者設備別名）不做ARP響應，或者能將報文重定向（Redirect）到本地的Socket端口上。

7.小結

本文主要講述了LVS集羣中的三種IP負載均衡技術。在分析網絡地址轉換方法（VS/NAT）的缺點和網絡服務的非對稱性的基礎上，咱們給出了經過IP隧道實現虛擬服務器的方法VS/TUN，和經過直接路由實現虛擬服務器的方法VS/DR，極大地提升了系統的伸縮性。

參考文獻

1. Eric Dean Katz, Michelle Butler, and Robert McGrath, "A Scalable HTTP Server: The NCSA Prototype", Computer Networks and ISDN Systems, pp155-163, 1994.

2. Thomas T. Kwan, Robert E. McGrath, and Daniel A. Reed, "NCSA's World Wide Web Server: Design and Performance", IEEE Computer, pp68-74, November 1995.

3. C. Yoshikawa, B. Chun, P. Eastham, A. Vahdat, T. Anderson, and D. Culler. Using Smart Clients to Build Scalable Services. In Proceedings of the 1997 USENIX Technical Conference, January 1997.

4. Zeus Technology, Inc. Zeus Load Balancer v1.1 User Guide. http://www.zeus.com/

5. Edward Walker, "pWEB - A Parallel Web Server Harness",http://www.ihpc.nus.edu.sg/STAFF/edward/pweb.html, April, 1997.

6. Ralf S.Engelschall. Load Balancing Your Web Site: Practical Approaches for Distributing HTTP Traffic. Web Techniques Magazine, Volume 3, Issue 5, http://www.webtechniques.com, May 1998.

7. Daniel Andresen, Tao Yang, Oscar H. Ibarra. Towards a Scalable Distributed WWW Server on Workstation Clusters. In Proceedings of 10th IEEE International Symposium Of Parallel Processing (IPPS'96), pp.850-856, http://www.cs.ucsb.edu-/Research/rapid_sweb/SWEB.html, April 1996.

8. Eric Anderson, Dave Patterson, and Eric Brewer, "The Magicrouter: an Application of Fast Packet Interposing", http://www.cs.berkeley.edu/~eanders-/magicrouter/, May, 1996.

9. D. Dias, W. Kish, R. Mukherjee, and R. Tewari. A Scalable and Highly Available Server. In Proceeding of COMPCON 1996, IEEE-CS Press, Santa Clara, CA, USA, Febuary 1996, pp. 85-92.

10. Guerney D.H. Hunt, German S. Goldszmidt, Richard P. King, and Rajat Mukherjee. Network Dispatcher: a connection router for scalable Internet services. In Proceedings of the 7th International WWW Conference, Brisbane, Australia, April 1998.

11. Om P. Damani, P. Emerald Chung, Yennun Huang, "ONE-IP: Techniques for Hosting a Service on a Cluster of Machines", http://www.cs.utexas.edu-/users/damani/, August 1997.

12. Microsoft Corporation. Microsoft Windows NT Load Balancing Service.http://www.micorsoft.com/ntserver/NTServerEnterprise/exec/feature/WLBS/.

關於做者

章文嵩博士，開放源碼及Linux內核的開發者，著名的Linux集羣項目－－LVS(Linux Virtual Server)的創始人和主要開發人員。他目前工做於國家並行與分佈式處理重點實驗室，主要從事集羣技術、操做系統、對象存儲與數據庫的研究。他一直在自 由軟件的開發上花費大量時間，並以此爲樂。