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

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

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

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

章文嵩 (wensong@linux-vs.org), 簡介： 簡介： 本文在分析服務(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)。 發(fā)布日期： 發(fā)布日期： 2002 年 4 月 10 日 前言 在前面文章中，講述了可伸縮網(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ù)的非對稱性的基礎(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)目。

實(shí)現(xiàn)虛擬服務(wù)的相關(guān)方法 在網(wǎng)絡(luò)服務(wù)中，一端是客戶程序，另一端是服務(wù)程序，在中間可能有代理程序。由此看來，可 以在不同的層次上實(shí)現(xiàn)多臺服務(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圖 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ù)器會把域名輪流解析到這組服務(wù)器的不同 IP 地址， 從而將訪問負(fù)載分到各臺服務(wù) 器上。 這種方法帶來幾個(gè)問題。 第一， 域名服務(wù)器是一個(gè)分布式系統(tǒng)， 是按照一定的層次結(jié)構(gòu)組織的。 當(dāng)用戶就域名解析請求提交給本地的域名服務(wù)器， 它會因不能直接解析而向上一級域名服務(wù)器 提交，上一級域名服務(wù)器再依次向上提交，直到 RR-DNS 域名服器把這個(gè)域名解析到其中一臺 服務(wù)器的 IP 地址?？梢?，從用戶到 RR-DNS 間存在多臺域名服器，而它們都會緩沖已解析的名 字到 IP 地址的映射, 這會導(dǎo)致該域名服器組下所有用戶都會訪問同一 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)用戶請求， 它會再向上一級域名服器提交請求并進(jìn)行重 新影射。這就涉及到如何設(shè)置這個(gè) TTL 值，若這個(gè)值太大，在這個(gè) TTL 期間，很多請求會被映 射到同一臺 WEB 服務(wù)器上，同樣會導(dǎo)致嚴(yán)重的負(fù)載不平衡。若這個(gè)值太小，例如是０，會導(dǎo)致 本地域名服務(wù)器頻繁地向 RR-DNS 提交請求，增加了域名解析的網(wǎng)絡(luò)流量，同樣會使 RR-DNS 服務(wù)器成為系統(tǒng)中一個(gè)新的瓶頸。

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

求會被 送到同一臺 WEB 服務(wù)器上。 由于用戶訪問請求的突發(fā)性和訪問方式不同， 例如有的人訪問一下 就離開了，而有的人訪問可長達(dá)幾個(gè)小時(shí)，所以各臺服務(wù)器間的負(fù)載仍存在傾斜（Skew ）而不 能控制。假設(shè)用戶在每個(gè)會話中平均請求數(shù)為 20，負(fù)載最大的服務(wù)器獲得的請求數(shù)額高于各 服務(wù)器平均請求數(shù)的平均比率超過百分之三十。也就是說，當(dāng) TTL 值為 0 時(shí)，因?yàn)橛脩粼L問的 突發(fā)性也會存在著較嚴(yán)重的負(fù)載不平衡。 第三，系統(tǒng)的可靠性和可維護(hù)性差。若一臺服務(wù)器失效，會導(dǎo)致將域名解析到該服務(wù)器的用戶 看到服務(wù)中斷，即使用戶按“Reload ”按鈕，也無濟(jì)于事。系統(tǒng)管理員也不能隨時(shí)地將一臺服 務(wù)器切出服務(wù)進(jìn)行系統(tǒng)維護(hù)，如進(jìn)行操作系統(tǒng)和應(yīng)用軟件升級，這需要修改 RR-DNS 服務(wù)器中 的 IP 地址列表，把該服務(wù)器的 IP 地址從中劃掉，然后等上幾天或者更長的時(shí)間，等所有域名 服器將該域名到這臺服務(wù)器的映射淘汰， 和所有映射到這臺服務(wù)器的客戶機(jī)不再使用該站點(diǎn)為 止。 2.2. 基于客戶端的解決方法 基于客戶端的解決方法需要每個(gè)客戶程序都有一定的服務(wù)器集群的知識， 進(jìn)而把以負(fù)載均衡的 方式將請求發(fā)到不同的服務(wù)器。例如，Netscape Navigator 瀏覽器訪問 Netscape 的主頁時(shí)， 它會隨機(jī)地從一百多臺服務(wù)器中挑選第 N 臺，最后將請求送往 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ù)器查詢來收集信 息會增加額外的網(wǎng)絡(luò)流量，不具有普遍的適用性。 2.3. 基于應(yīng)用層負(fù)載均衡調(diào)度的解決方法 多臺服務(wù)器通過高速的互聯(lián)網(wǎng)絡(luò)連接成一個(gè)集群系統(tǒng)，在前端有一個(gè)基于應(yīng)用層的負(fù)載調(diào)度 器。當(dāng)用戶訪問請求到達(dá)調(diào)度器時(shí)，請求會提交給作負(fù)載均衡調(diào)度的應(yīng)用程序，分析請求，根 據(jù)各個(gè)服務(wù)器的負(fù)載情況，選出一臺服務(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 會選出一個(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è)副本，再選一臺服務(wù)器，向服務(wù)器發(fā)送請求，再將 服務(wù)器返回的結(jié)果轉(zhuǎn)發(fā)給客戶。SWEB 是利用 HTTP 中的 redirect 錯(cuò)誤代碼，將客戶請求到達(dá) 一臺 WEB 服務(wù)器后， 這個(gè) WEB 服務(wù)器根據(jù)自己的負(fù)載情況， 自己處理請求， 或者通過 redirect 錯(cuò)誤代碼將客戶引到另一臺 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 臺時(shí)，調(diào)度器本身可能會成為新的瓶頸。所以，這種基 于應(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)文會到達(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)文可以直接返回給客戶， 壞處是每臺服務(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 需 要上百萬美金?？偟膩碚f，IBM 的技術(shù)還挺不錯(cuò)的。 在貝爾實(shí)驗(yàn)室的 ONE-IP[11]中，每臺服務(wù)器都獨(dú)立的 IP 地址，但都用 IP Alias 配置上同一 VIP 地址，采用路由和廣播兩種方法分發(fā)請求，服務(wù)器收到請求后按 VIP 地址處理請求，并以 VIP 為源地址返回結(jié)果。這種方法也是為了避免回應(yīng)報(bào)文的重寫，但是每臺服務(wù)器用 IP Alias 配置上同一 VIP 地址，會導(dǎo)致地址沖突，有些操作系統(tǒng)會出現(xiàn)網(wǎng)絡(luò)失效。通過廣播分發(fā)請求， 同樣需要修改服務(wù)器操作系統(tǒng)的源碼來過濾報(bào)文，使得只有一臺服務(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 地址和端口號，保證只有一臺服務(wù)器將報(bào)文交給上一層處理。但是，當(dāng) 有新結(jié)點(diǎn)加入和有結(jié)點(diǎn)失效時(shí)，所有服務(wù)器需要協(xié)商一個(gè)新的過濾算法，這會導(dǎo)致所有有 Session 的連接中斷。同時(shí)，WLBS 需要所有的服務(wù)器有相同的配置，如網(wǎng)卡速度和處理能力。

通過 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ā)送到哪一臺服務(wù)器，執(zhí) 行結(jié)果是一樣的。 服務(wù)的內(nèi)容可以復(fù)制到每臺服務(wù)器的本地硬盤上， 可以通過網(wǎng)絡(luò)文件系統(tǒng) （如 NFS）共享，也可以通過一個(gè)分布式文件系統(tǒng)來提供。

圖 2：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ù)器中選出一臺服務(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)文會使得連接處于不同的狀態(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è)置的， 在缺省情況下， 狀態(tài)的超時(shí)為 1 分鐘， SYN 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 地址或者端口號在報(bào)文的數(shù)據(jù)中傳送，若我們只對報(bào)文頭的 IP 地址和端口號作轉(zhuǎn)換，這樣就會出現(xiàn)不一致性，服務(wù)會中斷。所以，針對這些服務(wù)，需要編寫 相應(yīng)的應(yīng)用模塊來轉(zhuǎn)換報(bào)文數(shù)據(jù)中的 IP 地址或者端口號。我們所知道有這個(gè)問題的網(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。 下面，舉個(gè)例子來進(jìn)一步說明 VS/NAT，如圖 3 所示：

圖 3：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)文將被拒絕。 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

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

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

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

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

通過 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 臺和 20 臺之間時(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 地址。 隧道技術(shù)亦稱為 IP 封裝技術(shù) IP （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)地選擇一臺服務(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è)備上。 圖 4：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)地選擇一臺服務(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 圖 5：VS/TUN 的工作流程

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

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

通過直接路由實(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 地址配置方法是相似的），

但 IBM 的 NetDispatcher 是非常昂貴的商品化產(chǎn)品， 我們也不知道它內(nèi)部所使用的機(jī)制， 其中 有些是 IBM 的專利。 VS/DR 的體系結(jié)構(gòu)如圖 7 所示： 調(diào)度器和服務(wù)器組都必須在物理上有一個(gè)網(wǎng)卡通過不分?jǐn)嗟木?域網(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ò)請求。

圖 7：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)地選擇一臺服務(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)文直接返回給客戶。

圖 8：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ù)，而不會知道是哪一臺服務(wù)器處理的。 VS/DR 負(fù)載調(diào)度器跟 VS/TUN 一樣只處于從客戶到服務(wù)器的半連接中，按照半連接的 TCP 有限 狀態(tài)機(jī)進(jìn)行狀態(tài)遷移。

三種方法的優(yōu)缺點(diǎn)比較 三種 IP 負(fù)載均衡技術(shù)的優(yōu)缺點(diǎn)歸納在下表中： _ 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ù)目的估計(jì)是假設(shè)調(diào)度器使用 100M 網(wǎng)卡，調(diào)度器的硬 件配置與后端服務(wù)器的硬件配置相同，而且是對一般 Web 服務(wù)。使用更高的硬件配置（如千兆 網(wǎng)卡和更快的處理器） 作為調(diào)度器， 調(diào)度器所能調(diào)度的服務(wù)器數(shù)量會相應(yīng)增加。 當(dāng)應(yīng)用不同時(shí)， 服務(wù)器的數(shù)目也會相應(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)樵?VS/NAT 中請求和響應(yīng)報(bào)文都需要通過 負(fù)載調(diào)度器。 我們在 Pentium 166 處理器的主機(jī)上測得重寫報(bào)文的平均延時(shí)為 60us，性能更

高的處理器上延時(shí)會短一些。假設(shè) TCP 報(bào)文的平均長度為 536 Bytes ，則調(diào)度器的最大吞吐量 為 8.93 MBytes/s. 我們再假設(shè)每臺服務(wù)器的吞吐量為 800KBytes/s，這樣一個(gè)調(diào)度器可以帶 動(dòng) 10 臺服務(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 地址或者端口號在報(bào)文數(shù)據(jù)中傳送的網(wǎng)絡(luò)服務(wù)，需要編寫相應(yīng)的應(yīng)用模塊來轉(zhuǎn) 換報(bào)文數(shù)據(jù)中的 IP 地址或者端口號。這會帶來實(shí)現(xiàn)的工作量，同時(shí)應(yīng)用模塊檢查報(bào)文的開銷 會降低系統(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)度百臺以上 的服務(wù)器（同等規(guī)模的服務(wù)器），而它不會成為系統(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)度上百臺服務(wù)器，而它本身不會成為系統(tǒng)的瓶頸， 可以用來構(gòu)建高性能的超級服務(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)椤癐P Tunneling ”正成為各個(gè)操作系統(tǒng)的標(biāo)準(zhǔn)協(xié)議，所以 VS/TUN 應(yīng) 該會適用運(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 端口上。

小結(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)的伸縮性。

參考資料

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/.