Linux 服務器集群系統(tǒng)(三).txt 人生重要的不是所站的位置，而是所朝的方向。不要用自己的需求去衡量別人的給予，否則永遠是抱怨。 本文由3398winsonrong 貢獻doc文檔可能在W

Linux 服務器集群系統(tǒng)(三).txt 人生重要的不是所站的位置，而是所朝的方向。不要用自己的需求去衡量別人的給予，否則永遠是抱怨。 本文由3398winsonrong 貢獻

doc文檔可能在WAP 端瀏覽體驗不佳。建議您優(yōu)先選擇TXT ，或下載源文件到本機查看。 服務器集群系統(tǒng)( Linux 服務器集群系統(tǒng)(三)

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

章文嵩 (wensong@linux-vs.org), 簡介： 簡介： 本文在分析服務器集群實現(xiàn)虛擬網(wǎng)絡服務的相關技術上，詳細描述了 LVS 集群中實現(xiàn) 的三種 IP 負載均衡技術（VS/NAT、VS/TUN 和 VS/DR）的工作原理，以及它們的優(yōu)缺點。 發(fā)布日期： 發(fā)布日期： 2002 年 4 月 10 日 前言 在前面文章中，講述了可伸縮網(wǎng)絡服務的幾種結構，它們都需要一個前端的負載調度器（或者 多個進行主從備份）。我們先分析實現(xiàn)虛擬網(wǎng)絡服務的主要技術，指出 IP 負載均衡技術是在 負載調度器的實現(xiàn)技術中效率最高的。在已有的 IP 負載均衡技術中，主要有通過網(wǎng)絡地址轉 換（Network Address Translation）將一組服務器構成一個高性能的、高可用的虛擬服務器， 我們稱之為 VS/NAT 技術 （Virtual Server via Network Address Translation ） 在分析 VS/NAT 。 的缺點和網(wǎng)絡服務的非對稱性的基礎上，我們提出了通過 IP 隧道實現(xiàn)虛擬服務器的方法 VS/TUN（Virtual Server via IP Tunneling），和通過直接路由實現(xiàn)虛擬服務器的方法 VS/DR （Virtual Server via Direct Routing ） 它們可以極大地提高系統(tǒng)的伸縮性。 ， VS/NAT、 VS/TUN 和 VS/DR 技術是 LVS 集群中實現(xiàn)的三種 IP 負載均衡技術，我們將在文章中詳細描述它們的工 作原理和各自的優(yōu)缺點。 在以下描述中， 我們稱客戶的 socket 和服務器的 socket 之間的數(shù)據(jù)通訊為連接， 無論它們是 使用 TCP 還是 UDP 協(xié)議。 下面簡述當前用服務器集群實現(xiàn)高可伸縮、 高可用網(wǎng)絡服務的幾種負 載調度方法，并列舉幾個在這方面有代表性的研究項目。

實現(xiàn)虛擬服務的相關方法 在網(wǎng)絡服務中，一端是客戶程序，另一端是服務程序，在中間可能有代理程序。由此看來，可 以在不同的層次上實現(xiàn)多臺服務器的負載均衡。 用集群解決網(wǎng)絡服務性能問題的現(xiàn)有方法主要 分為以下四類。 2.1. 基于 RR-DNS 的解決方法 NCSA 的可伸縮的 WEB 服務器系統(tǒng)就是最早基于 RR-DNS（Round-Robin Domain Name System ） 的原型系統(tǒng)[1,2]。它的結構和工作流程如下圖所示：

RR圖 1：基于 RR-DNS 的可伸縮 WEB 服務器

(注：本圖來自文獻【9】) 有一組 WEB 服務器，他們通過分布式文件系統(tǒng) AFS(Andrew File System) 來共享所有的 HTML 文檔。這組服務器擁有相同的域名（如 www.ncsa.uiuc.edu ），當用戶按照這個域名訪問時, RR-DNS 服務器會把域名輪流解析到這組服務器的不同 IP 地址， 從而將訪問負載分到各臺服務 器上。 這種方法帶來幾個問題。 第一， 域名服務器是一個分布式系統(tǒng)， 是按照一定的層次結構組織的。 當用戶就域名解析請求提交給本地的域名服務器， 它會因不能直接解析而向上一級域名服務器 提交，上一級域名服務器再依次向上提交，直到 RR-DNS 域名服器把這個域名解析到其中一臺 服務器的 IP 地址?？梢姡瑥挠脩舻?RR-DNS 間存在多臺域名服器，而它們都會緩沖已解析的名 字到 IP 地址的映射, 這會導致該域名服器組下所有用戶都會訪問同一 WEB 服務器，出現(xiàn)不同 WEB 服務器間嚴重的負載不平衡。為了保證在域名服務器中域名到 IP 地址的映射不被長久緩 沖，RR-DNS 在域名到 IP 地址的映射上設置一個 TTL(Time To Live) 值，過了這一段時間，域 名服務器將這個映射從緩沖中淘汰。 當用戶請求， 它會再向上一級域名服器提交請求并進行重 新影射。這就涉及到如何設置這個 TTL 值，若這個值太大，在這個 TTL 期間，很多請求會被映 射到同一臺 WEB 服務器上，同樣會導致嚴重的負載不平衡。若這個值太小，例如是０，會導致 本地域名服務器頻繁地向 RR-DNS 提交請求，增加了域名解析的網(wǎng)絡流量，同樣會使 RR-DNS 服務器成為系統(tǒng)中一個新的瓶頸。

第二，用戶機器會緩沖從名字到 IP 地址的映射，而不受 TTL 值的影響，用戶的訪問請

求會被 送到同一臺 WEB 服務器上。 由于用戶訪問請求的突發(fā)性和訪問方式不同， 例如有的人訪問一下 就離開了，而有的人訪問可長達幾個小時，所以各臺服務器間的負載仍存在傾斜（Skew ）而不 能控制。假設用戶在每個會話中平均請求數(shù)為 20，負載最大的服務器獲得的請求數(shù)額高于各 服務器平均請求數(shù)的平均比率超過百分之三十。也就是說，當 TTL 值為 0 時，因為用戶訪問的 突發(fā)性也會存在著較嚴重的負載不平衡。 第三，系統(tǒng)的可靠性和可維護性差。若一臺服務器失效，會導致將域名解析到該服務器的用戶 看到服務中斷，即使用戶按“Reload ”按鈕，也無濟于事。系統(tǒng)管理員也不能隨時地將一臺服 務器切出服務進行系統(tǒng)維護，如進行操作系統(tǒng)和應用軟件升級，這需要修改 RR-DNS 服務器中 的 IP 地址列表，把該服務器的 IP 地址從中劃掉，然后等上幾天或者更長的時間，等所有域名 服器將該域名到這臺服務器的映射淘汰， 和所有映射到這臺服務器的客戶機不再使用該站點為 止。 2.2. 基于客戶端的解決方法 基于客戶端的解決方法需要每個客戶程序都有一定的服務器集群的知識， 進而把以負載均衡的 方式將請求發(fā)到不同的服務器。例如，Netscape Navigator 瀏覽器訪問 Netscape 的主頁時， 它會隨機地從一百多臺服務器中挑選第 N 臺，最后將請求送往 wwwN.netscape.com。然而，這 不是很好的解決方法，Netscape 只是利用它的 Navigator 避免了 RR-DNS 解析的麻煩，當使用 IE 等其他瀏覽器不可避免的要進行 RR-DNS 解析。 Smart Client[3]是 Berkeley 做的另一種基于客戶端的解決方法。服務提供一個 Java Applet 在客戶方瀏覽器中運行，Applet 向各個服務器發(fā)請求來收集服務器的負載等信息，再根據(jù)這 些信息將客戶的請求發(fā)到相應的服務器。 高可用性也在 Applet 中實現(xiàn)， 當服務器沒有響應時， Applet 向另一個服務器轉發(fā)請求。這種方法的透明性不好，Applet 向各服務器查詢來收集信 息會增加額外的網(wǎng)絡流量，不具有普遍的適用性。 2.3. 基于應用層負載均衡調度的解決方法 多臺服務器通過高速的互聯(lián)網(wǎng)絡連接成一個集群系統(tǒng)，在前端有一個基于應用層的負載調度 器。當用戶訪問請求到達調度器時，請求會提交給作負載均衡調度的應用程序，分析請求，根 據(jù)各個服務器的負載情況，選出一臺服務器，重寫請求并向選出的服務器訪問，取得結果后， 再返回給用戶。 應用層負載均衡調度的典型代表有 Zeus 負載調度器[4]、 pWeb[5]、 Reverse-Proxy[6]和 SWEB[7] 等。Zeus 負載調度器是 Zeus 公司的商業(yè)產品，它是在 Zeus Web 服務器程序改寫而成的，采 用單進程事件驅動的服務器結構。pWeb 就是一個基于 Apache 1.1 服務器程序改寫而成的并行 WEB 調度程序，當一個 HTTP 請求到達時，pWeb 會選出一個服務器，重寫請求并向這個服務器 發(fā)出改寫后的請求，等結果返回后，再將結果轉發(fā)給客戶。Reverse-Proxy 利用 Apache 1.3.1 中的 Proxy 模塊和 Rewrite 模塊實現(xiàn)一個可伸縮 WEB 服務器，它與 pWeb 的不同之處在于它要 先從 Proxy 的 cache 中查找后，若沒有這個副本，再選一臺服務器，向服務器發(fā)送請求，再將 服務器返回的結果轉發(fā)給客戶。SWEB 是利用 HTTP 中的 redirect 錯誤代碼，將客戶請求到達 一臺 WEB 服務器后， 這個 WEB 服務器根據(jù)自己的負載情況， 自己處理請求， 或者通過 redirect 錯誤代碼將客戶引到另一臺 WEB 服務器，以實現(xiàn)一個可伸縮的 WEB 服務器。 基于應用層負載均衡調度的多服務器解決方法也存在一些問題。第一，系統(tǒng)處理開銷特別大， 致使系統(tǒng)的伸縮性有限。 當請求到達負載均衡調度器至處理結束時， 調度器需要進行四次從核 心到用戶空間或從用戶空間到核心空間的上下文切換和內存復制； 需要進行二次 TCP 連接， 一 次是從用戶到調度器，另一次是從調度器到真實服務器；需要對請求進行分析和重寫。這些處 理都需要不小的ＣＰＵ、內存和網(wǎng)絡等資源開銷，且處理時間長。所構成系統(tǒng)的性能不能接近 線性增加的，一般服務器組增至 3 或 4 臺時，調度器本身可能會成為新的瓶頸。所以，這種基 于應用層負載均衡調度的方法的伸縮性極其有限。 第二， 基于應用層的負載均衡調度器對于不 同的應用，需要寫不同的調度器。以上幾個系統(tǒng)都是基于 HTTP 協(xié)議，若對于 FTP、Mail 、POP3 等應用，都需要重寫調度器。 2.4. 基于 IP 層負載均衡調度的解決方法 用戶通過虛擬 IP 地址（Virtual IP Address ）訪問服務時，訪問請求的報文會到達負載

調度 器，由它進行負載均衡調度，從一組真實服務器選出一個，將報文的目標地址 Virtual IP Address 改寫成選定服務器的地址，報文的目標端口改寫成選定服務器的相應端口，最后將報 文發(fā)送給選定的服務器。 真實服務器的回應報文經過負載調度器時， 將報文的源地址和源端口 改為 Virtual IP Address 和相應的端口，再把報文發(fā)給用戶。Berkeley 的 MagicRouter[8]、 Cisco 的 LocalDirector、 Alteon 的 ACEDirector 和 F5 的 Big/IP 等都是使用網(wǎng)絡地址轉換方 法。MagicRouter 是在 Linux 1.3 版本上應用快速報文插入技術，使得進行負載均衡調度的用 戶進程訪問網(wǎng)絡設備接近核心空間的速度，降低了上下文切換的處理開銷，但并不徹底，它只 是研究的原型系統(tǒng)，沒有成為有用的系統(tǒng)存活下來。Cisco 的 LocalDirector 、Alteon 的 ACEDirector 和 F5 的 Big/IP 是非常昂貴的商品化系統(tǒng)，它們支持部分 TCP/UDP 協(xié)議，有些在 ICMP 處理上存在問題。 IBM 的 TCP Router[9]使用修改過的網(wǎng)絡地址轉換方法在 SP/2 系統(tǒng)實現(xiàn)可伸縮的 WEB 服務器。 TCP Router 修改請求報文的目標地址并把它轉發(fā)給選出的服務器，服務器能把響應報文的源 地址置為 TCP Router 地址而非自己的地址。 這種方法的好處是響應報文可以直接返回給客戶， 壞處是每臺服務器的操作系統(tǒng)內核都需要修改。 IBM 的 NetDispatcher[10]是 TCP Router 的后 繼者，它將報文轉發(fā)給服務器，而服務器在 non-ARP 的設備配置路由器的地址。這種方法與 LVS 集群中的 VS/DR 類似，它具有很高的可伸縮性，但一套在 IBM SP/2 和 NetDispatcher 需 要上百萬美金?？偟膩碚f，IBM 的技術還挺不錯的。 在貝爾實驗室的 ONE-IP[11]中，每臺服務器都獨立的 IP 地址，但都用 IP Alias 配置上同一 VIP 地址，采用路由和廣播兩種方法分發(fā)請求，服務器收到請求后按 VIP 地址處理請求，并以 VIP 為源地址返回結果。這種方法也是為了避免回應報文的重寫，但是每臺服務器用 IP Alias 配置上同一 VIP 地址，會導致地址沖突，有些操作系統(tǒng)會出現(xiàn)網(wǎng)絡失效。通過廣播分發(fā)請求， 同樣需要修改服務器操作系統(tǒng)的源碼來過濾報文，使得只有一臺服務器處理廣播來的請求。 微軟的 Windows NT 負載均衡服務（Windows NT Load Balancing Service，WLBS ）[12]是 1998 年底收購 Valence Research 公司獲得的，它與 ONE-IP 中的基于本地過濾方法一樣。WLBS 作 為過濾器運行在網(wǎng)卡驅動程序和 TCP/IP 協(xié)議棧之間，獲得目標地址為 VIP 的報文，它的過濾 算法檢查報文的源 IP 地址和端口號，保證只有一臺服務器將報文交給上一層處理。但是，當 有新結點加入和有結點失效時，所有服務器需要協(xié)商一個新的過濾算法，這會導致所有有 Session 的連接中斷。同時，WLBS 需要所有的服務器有相同的配置，如網(wǎng)卡速度和處理能力。

通過 NAT 實現(xiàn)虛擬服務器（VS/NAT） 由于 IPv4 中 IP 地址空間的日益緊張和安全方面的原因，很多網(wǎng)絡使用保留 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 上使用，而是專門為內部網(wǎng)絡預留的。當內部網(wǎng)絡中的主機要訪 問 Internet 或被 Internet 訪問時， 就需要采用網(wǎng)絡地址轉換 （Network Address Translation, 以下簡稱 NAT），將內部地址轉化為 Internets 上可用的外部地址。NAT 的工作原理是報文頭

（目標地址、源地址和端口等）被正確改寫后，客戶相信它們連接一個 IP 地址，而不同 IP 地址的服務器組也認為它們是與客戶直接相連的。由此，可以用 NAT 方法將不同 IP 地址的并 行網(wǎng)絡服務變成在一個 IP 地址上的一個虛擬服務。 VS/NAT 的體系結構如圖 2 所示。在一組服務器前有一個調度器，它們是通過 Switch/HUB 相連 接的。這些服務器提供相同的網(wǎng)絡服務、相同的內容，即不管請求被發(fā)送到哪一臺服務器，執(zhí) 行結果是一樣的。 服務的內容可以復制到每臺服務器的本地硬盤上， 可以通過網(wǎng)絡文件系統(tǒng) （如 NFS）共享，也可以通過一個分布式文件系統(tǒng)來提供。

圖 2：VS/NAT 的體系結構

客戶通過 Virtual IP Address （虛擬服務的 IP 地址）訪問網(wǎng)絡服務時，請求報文到達調度器， 調度器根據(jù)連接調度算法從一組真實服務器中選出一臺服務器， 將報文的目標地

址 Virtual IP Address 改寫成選定服務器的地址，報文的目標端口改寫成選定服務器的相應端口，最后將修 改后的報文發(fā)送給選出的服務器。同時，調度器在連接 Hash 表中記錄這個連接，當這個連接 的下一個報文到達時，從連接 Hash 表中可以得到原選定服務器的地址和端口，進行同樣的改 寫操作，并將報文傳給原選定的服務器。當來自真實服務器的響應報文經過調度器時，調度器 將報文的源地址和源端口改為 Virtual IP Address 和相應的端口，再把報文發(fā)給用戶。我們 在連接上引入一個狀態(tài)機， 不同的報文會使得連接處于不同的狀態(tài)， 不同的狀態(tài)有不同的超時 值。在 TCP 連接中，根據(jù)標準的 TCP 有限狀態(tài)機進行狀態(tài)遷移，這里我們不一一敘述，請參見 W. Richard Stevens 的《TCP/IP Illustrated Volume I 》；在 UDP 中，我們只設置一個 UDP 狀態(tài)。 不同狀態(tài)的超時值是可以設置的， 在缺省情況下， 狀態(tài)的超時為 1 分鐘， SYN ESTABLISHED

狀態(tài)的超時為 15 分鐘，F(xiàn)IN 狀態(tài)的超時為 1 分鐘；UDP 狀態(tài)的超時為 5 分鐘。當連接終止或超 時，調度器將這個連接從連接 Hash 表中刪除。 這樣，客戶所看到的只是在 Virtual IP Address 上提供的服務，而服務器集群的結構對用戶 是透明的。對改寫后的報文，應用增量調整 Checksum 的算法調整 TCP Checksum 的值，避免了 掃描整個報文來計算 Checksum 的開銷。 在一些網(wǎng)絡服務中，它們將 IP 地址或者端口號在報文的數(shù)據(jù)中傳送，若我們只對報文頭的 IP 地址和端口號作轉換，這樣就會出現(xiàn)不一致性，服務會中斷。所以，針對這些服務，需要編寫 相應的應用模塊來轉換報文數(shù)據(jù)中的 IP 地址或者端口號。我們所知道有這個問題的網(wǎng)絡服務 有 FTP、 IRC、 H.323、 CUSeeMe、 Real Audio 、 Real Video 、 Vxtreme / Vosiac 、 VDOLive、 VIVOActive、 True Speech 、 RSTP、 PPTP、 StreamWorks、 AudioLink 、 SoftwareVision、 NTT NTT 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 TCP TCP Virtual IP Address 202.103.106.5 202.103.106.5 Port 80 21 Real IP Address 172.16.0.2 172.16.0.3 172.16.0.3 Port 80 8000 21 Weight 1 2 1

從以下的例子中，我們可以更詳細地了解報文改寫的流程。 訪問 Web 服務的報文可能有以下的源地址和目標地址： SOURCE 202.100.1.2:3456 DEST 202.103.106.5:80

調度器從調度列表中選出一臺服務器， 例如是 172.16.0.3:8000。 該報文會被改寫為如下地址， 并將它發(fā)送給選出的服務器。 SOURCE 202.100.1.2:3456 DEST 172.16.0.3:8000 從服務器返回到調度器的響應報文如下： SOURCE 172.16.0.3:8000 DEST 202.100.1.2:3456

響應報文的源地址會被改寫為虛擬服務的地址，再將報文發(fā)送給客戶： 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 處理的。

通過 IP 隧道實現(xiàn)虛擬服務器（VS/TUN） 在 VS/NAT 的集群系統(tǒng)中，請求和響應的數(shù)據(jù)報文都需要通過負載調度器，當真實服務器的數(shù) 目在 10 臺和 20 臺之間時，負載調度器將成為整個集群系統(tǒng)的新瓶頸。大多數(shù) Internet 服務 都有這樣的特點： 請求報文較短而響應報文往往包含大量的數(shù)據(jù)。 如果能將請求和響應分開處 理， 即在負載調度器中只負責調度請求而響應直接返回給客戶， 將極大地提高整個集群系統(tǒng)的 吞吐量。 IP 隧道（IP tunneling ）是將一個 IP 報文封裝在另一個 IP 報文的技術，這可以使得目標為 一個 IP 地址的數(shù)據(jù)報文能被封裝和轉發(fā)到另一個 IP 地址。 隧道技術亦稱為 IP 封裝技術 IP （IP

encapsulation ）。IP 隧道主要用于移動主機和虛擬私有網(wǎng)絡（Virtual Private Network）， 在其中隧道都是靜態(tài)建立的，隧道一端有一個 IP 地址，另一端也有唯一的 IP 地址。 我們利用 IP 隧道技術將請求報文封裝轉發(fā)給后端服務器，響應報文能從后端服務器直接返回 給客戶。 但在這里， 后端服務器有一組而非一個， 所以我們不可能靜態(tài)地建立一一對應的隧道， 而是動態(tài)地選擇一臺服務器，將請求報文封裝和轉發(fā)給選出的服務器。這樣，我們可以利用 IP 隧道的原理將一組服務器上的網(wǎng)絡服務組成在一個 IP 地址上的虛擬網(wǎng)絡服務。 VS/TUN 的體 系結構如圖 4 所示，各個服務器將 VIP 地址配置在自己的 IP 隧道設備上。 圖 4：VS/TUN 的體系結構

VS/TUN 的工作流程如圖 5 所示：它的連接調度和管理與 VS/NAT 中的一樣，只是它的報文轉發(fā) 方法不同。調度器根據(jù)各個服務器的負載情況，動態(tài)地選擇一臺服務器，將請求報文封裝在另 一個 IP 報文中，再將封裝后的 IP 報文轉發(fā)給選出的服務器；服務器收到報文后，先將報文解 封獲得原來目標地址為 VIP 的報文，服務器發(fā)現(xiàn) VIP 地址被配置在本地的 IP 隧道設備上，所 以就處理這個請求，然后根據(jù)路由表將響應報文直接返回給客戶。 VS/TUN 圖 5：VS/TUN 的工作流程

在這里需要指出，根據(jù)缺省的 TCP/IP 協(xié)議棧處理，請求報文的目標地址為 VIP，響應報文的 源地址肯定也為 VIP，所以響應報文不需要作任何修改，可以直接返回給客戶，客戶認為得到 正常的服務，而不會知道究竟是哪一臺服務器處理的。

圖 6：半連接的 TCP 有限狀態(tài)機

通過直接路由實現(xiàn)虛擬服務器（VS/DR） 跟 VS/TUN 方法相同，VS/DR 利用大多數(shù) Internet 服務的非對稱特點，負載調度器中只負責調 度請求，而服務器直接將響應返回給客戶，可以極大地提高整個集群系統(tǒng)的吞吐量。該方法與 IBM 的 NetDispatcher 產品中使用的方法類似（其中服務器上的 IP 地址配置方法是相似的），

但 IBM 的 NetDispatcher 是非常昂貴的商品化產品， 我們也不知道它內部所使用的機制， 其中 有些是 IBM 的專利。 VS/DR 的體系結構如圖 7 所示： 調度器和服務器組都必須在物理上有一個網(wǎng)卡通過不分斷的局 域網(wǎng)相連，如通過高速的交換機或者 HUB 相連。VIP 地址為調度器和服務器組共享，調度器配 置的 VIP 地址是對外可見的， 用于接收虛擬服務的請求報文； 所有的服務器把 VIP 地址配置在 各自的 Non-ARP 網(wǎng)絡設備上， 它對外面是不可見的， 只是用于處理目標地址為 VIP 的網(wǎng)絡請求。

圖 7：VS/DR 的體系結構

VS/DR 的工作流程如圖 8 所示：它的連接調度和管理與 VS/NAT 和 VS/TUN 中的一樣，它的報文 轉發(fā)方法又有不同，將報文直接路由給目標服務器。在 VS/DR 中，調度器根據(jù)各個服務器的負 載情況，動態(tài)地選擇一臺服務器，不修改也不封裝 IP 報文，而是將數(shù)據(jù)幀的 MAC 地址改為選 出服務器的 MAC 地址，再將修改后的數(shù)據(jù)幀在與服務器組的局域網(wǎng)上發(fā)送。因為數(shù)據(jù)幀的 MAC 地址是選出的服務器，所以服務器肯定可以收到這個數(shù)據(jù)幀，從中可以獲得該 IP 報文。當服 務器發(fā)現(xiàn)報文的目標地址 VIP 是在本地的網(wǎng)絡設備上， 服務器處理這個報文， 然后根據(jù)路由表 將響應報文直接返回給客戶。

圖 8：VS/DR 的工作流程

在 VS/DR 中，根據(jù)缺省的 TCP/IP 協(xié)議棧處理，請求報文的目標地址為 VIP，響應報文的源地 址肯定也為 VIP，所以響應報文不需要作任何修改，可以直接返回給客戶，客戶認為得到正常 的服務，而不會知道是哪一臺服務器處理的。 VS/DR 負載調度器跟 VS/TUN 一樣只處于從客戶到服務器的半連接中，按照半連接的 TCP 有限 狀態(tài)機進行狀態(tài)遷移。

三種方法的優(yōu)缺點比較 三種 IP 負載均衡技術的優(yōu)缺點歸納在下表中： _ Server server network server number server gateway VS/NAT any private low (10~20) load balancer VS/TUN Tunneling LAN/WAN High (100) own router VS/DR Non-arp device LAN High

(100) Own router

注：以上三種方法所能支持最大服務器數(shù)目的估計是假設調度器使用 100M 網(wǎng)卡，調度器的硬 件配置與后端服務器的硬件配置相同，而且是對一般 Web 服務。使用更高的硬件配置（如千兆 網(wǎng)卡和更快的處理器） 作為調度器， 調度器所能調度的服務器數(shù)量會相應增加。 當應用不同時， 服務器的數(shù)目也會相應地改變。 所以， 以上數(shù)據(jù)估計主要是為三種方法的伸縮性進行量化比較。 6.1. Virtual Server via NAT VS/NAT 的優(yōu)點是服務器可以運行任何支持 TCP/IP 的操作系統(tǒng)，它只需要一個 IP 地址配置在 調度器上，服務器組可以用私有的 IP 地址。缺點是它的伸縮能力有限，當服務器結點數(shù)目升 到 20 時， 調度器本身有可能成為系統(tǒng)的新瓶頸， 因為在 VS/NAT 中請求和響應報文都需要通過 負載調度器。 我們在 Pentium 166 處理器的主機上測得重寫報文的平均延時為 60us，性能更

高的處理器上延時會短一些。假設 TCP 報文的平均長度為 536 Bytes ，則調度器的最大吞吐量 為 8.93 MBytes/s. 我們再假設每臺服務器的吞吐量為 800KBytes/s，這樣一個調度器可以帶 動 10 臺服務器。（注：這是很早以前測得的數(shù)據(jù)） 基于 VS/NAT 的的集群系統(tǒng)可以適合許多服務器的性能要求。如果負載調度器成為系統(tǒng)新的瓶 頸，可以有三種方法解決這個問題：混合方法、VS/TUN 和 VS/DR。在 DNS 混合集群系統(tǒng)中，有 若干個 VS/NAT 負載調度器，每個負載調度器帶自己的服務器集群，同時這些負載調度器又通 過 RR-DNS 組成簡單的域名。但 VS/TUN 和 VS/DR 是提高系統(tǒng)吞吐量的更好方法。 對于那些將 IP 地址或者端口號在報文數(shù)據(jù)中傳送的網(wǎng)絡服務，需要編寫相應的應用模塊來轉 換報文數(shù)據(jù)中的 IP 地址或者端口號。這會帶來實現(xiàn)的工作量，同時應用模塊檢查報文的開銷 會降低系統(tǒng)的吞吐率。

6.2. Virtual Server via IP Tunneling 在 VS/TUN 的集群系統(tǒng)中，負載調度器只將請求調度到不同的后端服務器，后端服務器將應答 的數(shù)據(jù)直接返回給用戶。這樣，負載調度器就可以處理大量的請求，它甚至可以調度百臺以上 的服務器（同等規(guī)模的服務器），而它不會成為系統(tǒng)的瓶頸。即使負載調度器只有 100Mbps 的全雙工網(wǎng)卡，整個系統(tǒng)的最大吞吐量可超過 1Gbps 。所以，VS/TUN 可以極大地增加負載調度 器調度的服務器數(shù)量。VS/TUN 調度器可以調度上百臺服務器，而它本身不會成為系統(tǒng)的瓶頸， 可以用來構建高性能的超級服務器。 VS/TUN 技術對服務器有要求，即所有的服務器必須支持“IP Tunneling ”或者“IP Encapsulation ”協(xié)議。目前，VS/TUN 的后端服務器主要運行 Linux 操作系統(tǒng)，我們沒對其他 操作系統(tǒng)進行測試。因為“IP Tunneling ”正成為各個操作系統(tǒng)的標準協(xié)議，所以 VS/TUN 應 該會適用運行其他操作系統(tǒng)的后端服務器。 6.3. Virtual Server via Direct Routing 跟 VS/TUN 方法一樣，VS/DR 調度器只處理客戶到服務器端的連接，響應數(shù)據(jù)可以直接從獨立 的網(wǎng)絡路由返回給客戶。這可以極大地提高 LVS 集群系統(tǒng)的伸縮性。 跟 VS/TUN 相比， 這種方法沒有 IP 隧道的開銷， 但是要求負載調度器與實際服務器都有一塊網(wǎng) 卡連在同一物理網(wǎng)段上，服務器網(wǎng)絡設備（或者設備別名）不作 ARP 響應，或者能將報文重定 向（Redirect ）到本地的 Socket 端口上。

小結 本文主要講述了 LVS 集群中的三種 IP 負載均衡技術。在分析網(wǎng)絡地址轉換方法（VS/NAT）的缺點和網(wǎng)絡服務的非對稱性的基 礎上，我們給出了通過 IP 隧道實現(xiàn)虛擬服務器的方法 VS/TUN，和通過直接路由實現(xiàn)虛擬服務器的方法 VS/DR，極大地提高了 系統(tǒng)的伸縮性。

參考資料

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. 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. 6. Eric Anderson, Dave Patterson, and Eric Brewer, "The Magicrouter: an Application of Fast Packet Interposing", http://www.cs.berkeley.edu/~eanders-/magicrouter/, May, 1996. 7. 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. 8. 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. 9. Microsoft Corporation. Microsoft Windows NT Load Balancing Service. http://www.micorsoft.com/ntserver/NTServerEnterprise/exec/feature/WLBS/.