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

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

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

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

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

實現(xiàn)虛擬服務(wù)的相關(guān)方法 在網(wǎng)絡(luò)服務(wù)中，一端是客戶程序，另一端是服務(wù)程序，在中間可能有代理程序。由此看來，可 以在不同的層次上實現(xiàn)多臺服務(wù)器的負載均衡。 用集群解決網(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圖 1：基于 RR-DNS 的可伸縮 WEB 服務(wù)器

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

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

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

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

通過 NAT 實現(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ò)預留的。當內(nèi)部網(wǎng)絡(luò)中的主機要訪 問 Internet 或被 Internet 訪問時， 就需要采用網(wǎng)絡(luò)地址轉(zhuǎn)換 （Network Address Translation, 以下簡稱 NAT），將內(nèi)部地址轉(zhuǎn)化為 Internets 上可用的外部地址。NAT 的工作原理是報文頭

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

圖 2：VS/NAT 的體系結(jié)構(gòu)

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

址 Virtual IP Address 改寫成選定服務(wù)器的地址，報文的目標端口改寫成選定服務(wù)器的相應端口，最后將修 改后的報文發(fā)送給選出的服務(wù)器。同時，調(diào)度器在連接 Hash 表中記錄這個連接，當這個連接 的下一個報文到達時，從連接 Hash 表中可以得到原選定服務(wù)器的地址和端口，進行同樣的改 寫操作，并將報文傳給原選定的服務(wù)器。當來自真實服務(wù)器的響應報文經(jīng)過調(diào)度器時，調(diào)度器 將報文的源地址和源端口改為 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 中，我們只設(shè)置一個 UDP 狀態(tài)。 不同狀態(tài)的超時值是可以設(shè)置的， 在缺省情況下， 狀態(tài)的超時為 1 分鐘， SYN ESTABLISHED

狀態(tài)的超時為 15 分鐘，F(xiàn)IN 狀態(tài)的超時為 1 分鐘；UDP 狀態(tài)的超時為 5 分鐘。當連接終止或超 時，調(diào)度器將這個連接從連接 Hash 表中刪除。 這樣，客戶所看到的只是在 Virtual IP Address 上提供的服務(wù)，而服務(wù)器集群的結(jié)構(gòu)對用戶 是透明的。對改寫后的報文，應用增量調(diào)整 Checksum 的算法調(diào)整 TCP Checksum 的值，避免了 掃描整個報文來計算 Checksum 的開銷。 在一些網(wǎng)絡(luò)服務(wù)中，它們將 IP 地址或者端口號在報文的數(shù)據(jù)中傳送，若我們只對報文頭的 IP 地址和端口號作轉(zhuǎn)換，這樣就會出現(xiàn)不一致性，服務(wù)會中斷。所以，針對這些服務(wù)，需要編寫 相應的應用模塊來轉(zhuǎn)換報文數(shù)據(jù)中的 IP 地址或者端口號。我們所知道有這個問題的網(wǎng)絡(luò)服務(wù) 有 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 的流量都被負載均 衡地調(diào)度的真實服務(wù)器 172.16.0.2:80 和 172.16.0.3:8000 上。 目標地址為 202.103.106.5:21 的報文被轉(zhuǎn)移到 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 服務(wù)的報文可能有以下的源地址和目標地址： SOURCE 202.100.1.2:3456 DEST 202.103.106.5:80

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

響應報文的源地址會被改寫為虛擬服務(wù)的地址，再將報文發(fā)送給客戶： SOURCE 202.103.106.5:80 DEST 202.100.1.2:3456

這樣，客戶認為是從 202.103.106.5:80 服務(wù)得到正確的響應，而不會知道該請求是服務(wù)器 172.16.0.2 還是服務(wù)器 172.16.0.3 處理的。

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

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

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

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

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

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

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

圖 7：VS/DR 的體系結(jié)構(gòu)

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

圖 8：VS/DR 的工作流程

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

三種方法的優(yōu)缺點比較 三種 IP 負載均衡技術(shù)的優(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

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

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

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

小結(jié) 本文主要講述了 LVS 集群中的三種 IP 負載均衡技術(shù)。在分析網(wǎng)絡(luò)地址轉(zhuǎn)換方法（VS/NAT）的缺點和網(wǎng)絡(luò)服務(wù)的非對稱性的基 礎(chǔ)上，我們給出了通過 IP 隧道實現(xiàn)虛擬服務(wù)器的方法 VS/TUN，和通過直接路由實現(xiàn)虛擬服務(wù)器的方法 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/.