Linux服務(wù)器集群系統(tǒng)(三)

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ù) 章文嵩 (), 簡介： 簡介： 本文在分析服務(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ù)的非對(duì)稱性的基礎(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)多臺(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圖 1：基于 RR-DNS 的可伸縮 WEB 服務(wù)器 (注：本圖來自文獻(xiàn)【9】) 有一組 WEB 服務(wù)器，他們通過分布式文件系統(tǒng) AFS(Andrew File System)來共享所有的 HTML 文檔。這組服務(wù)器擁有相同的域名（如 ），當(dāng)用戶按照這個(gè)域名訪問時(shí), RR-DNS 服務(wù)器會(huì)把域名輪流解析到這組服務(wù)器的不同 IP 地址， 從而將訪問負(fù)載分到各臺(tái)服務(wù) 器上。 這種方法帶來幾個(gè)問題。 第一， 域名服務(wù)器是一個(gè)分布式系統(tǒng)， 是按照一定的層次結(jié)構(gòu)組織的。 當(dāng)用戶就域名解析請(qǐ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)用戶請(qǐng)求， 它會(huì)再向上一級(jí)域名服器提交請(qǐng)求并進(jìn)行重 新影射。這就涉及到如何設(shè)置這個(gè) TTL 值，若這個(gè)值太大，在這個(gè) TTL 期間，很多請(qǐng)求會(huì)被映 射到同一臺(tái) WEB 服務(wù)器上，同樣會(huì)導(dǎo)致嚴(yán)重的負(fù)載不平衡。若這個(gè)值太小，例如是，會(huì)導(dǎo)致 本地域名服務(wù)器頻繁地向 RR-DNS 提交請(qǐng)求，增加了域名解析的網(wǎng)絡(luò)流量，同樣會(huì)使 RR-DNS 服務(wù)器成為系統(tǒng)中一個(gè)新的瓶頸。 第二，用戶機(jī)器會(huì)緩沖從名字到 IP 地址的映射，而不受 TTL 值的影響，用戶的訪問請(qǐng)求會(huì)被 送到同一臺(tái) WEB 服務(wù)器上。 由于用戶訪問請(qǐng)求的突發(fā)性和訪問方式不同， 例如有的人訪問一下 就離開了，而有的人訪問可長達(dá)幾個(gè)小時(shí)，所以各臺(tái)服務(wù)器間的負(fù)載仍存在傾斜（Skew）而不 能控制。假設(shè)用戶在每個(gè)會(huì)話中平均請(qǐng)求數(shù)為 20，負(fù)載最大的服務(wù)器獲得的請(qǐng)求數(shù)額高于各 服務(wù)器平均請(qǐng)求數(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ù)載均衡的 方式將請(qǐng)求發(fā)到不同的服務(wù)器。例如，Netscape Navigator 瀏覽器訪問 Netscape 的主頁時(shí)， 它會(huì)隨機(jī)地從一百多臺(tái)服務(wù)器中挑選第 N 臺(tái)，最后將請(qǐng)求送往 wwwN.。然而，這 不是很好的解決方法，Netscape 只是利用它的 Navigator 避免了 RR-DNS 解析的麻煩，當(dāng)使用 IE 等其他瀏覽器不可避免的要進(jìn)行 RR-DNS 解析。 Smart Client3是 Berkeley 做的另一種基于客戶端的解決方法。服務(wù)提供一個(gè) Java Applet 在客戶方瀏覽器中運(yùn)行，Applet 向各個(gè)服務(wù)器發(fā)請(qǐng)求來收集服務(wù)器的負(fù)載等信息，再根據(jù)這 些信息將客戶的請(qǐng)求發(fā)到相應(yīng)的服務(wù)器。 高可用性也在 Applet 中實(shí)現(xiàn)， 當(dāng)服務(wù)器沒有響應(yīng)時(shí)， Applet 向另一個(gè)服務(wù)器轉(zhuǎn)發(fā)請(qǐng)求。這種方法的透明性不好，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)用戶訪問請(qǐng)求到達(dá)調(diào)度器時(shí)，請(qǐng)求會(huì)提交給作負(fù)載均衡調(diào)度的應(yīng)用程序，分析請(qǐng)求，根 據(jù)各個(gè)服務(wù)器的負(fù)載情況，選出一臺(tái)服務(wù)器，重寫請(qǐng)求并向選出的服務(wù)器訪問，取得結(jié)果后， 再返回給用戶。 應(yīng)用層負(fù)載均衡調(diào)度的典型代表有 Zeus 負(fù)載調(diào)度器4、 pWeb5、 Reverse-Proxy6和 SWEB7 等。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 請(qǐng)求到達(dá)時(shí)，pWeb 會(huì)選出一個(gè)服務(wù)器，重寫請(qǐng)求并向這個(gè)服務(wù)器 發(fā)出改寫后的請(qǐng)求，等結(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ā)送請(qǐng)求，再將 服務(wù)器返回的結(jié)果轉(zhuǎn)發(fā)給客戶。SWEB 是利用 HTTP 中的 redirect 錯(cuò)誤代碼，將客戶請(qǐng)求到達(dá) 一臺(tái) WEB 服務(wù)器后， 這個(gè) WEB 服務(wù)器根據(jù)自己的負(fù)載情況， 自己處理請(qǐng)求， 或者通過 redirect 錯(cuò)誤代碼將客戶引到另一臺(tái) WEB 服務(wù)器，以實(shí)現(xiàn)一個(gè)可伸縮的 WEB 服務(wù)器。 基于應(yīng)用層負(fù)載均衡調(diào)度的多服務(wù)器解決方法也存在一些問題。第一，系統(tǒng)處理開銷特別大， 致使系統(tǒng)的伸縮性有限。 當(dāng)請(qǐng)求到達(dá)負(fù)載均衡調(diào)度器至處理結(jié)束時(shí)， 調(diào)度器需要進(jìn)行四次從核 心到用戶空間或從用戶空間到核心空間的上下文切換和內(nèi)存復(fù)制； 需要進(jìn)行二次 TCP 連接， 一 次是從用戶到調(diào)度器，另一次是從調(diào)度器到真實(shí)服務(wù)器；需要對(duì)請(qǐng)求進(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)度器對(duì)于不 同的應(yīng)用，需要寫不同的調(diào)度器。以上幾個(gè)系統(tǒng)都是基于 HTTP 協(xié)議，若對(duì)于 FTP、Mail、POP3 等應(yīng)用，都需要重寫調(diào)度器。 2.4. 基于 IP 層負(fù)載均衡調(diào)度的解決方法 用戶通過虛擬 IP 地址（Virtual IP Address）訪問服務(wù)時(shí)，訪問請(qǐng)求的報(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 的 MagicRouter8、 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 Router9使用修改過的網(wǎng)絡(luò)地址轉(zhuǎn)換方法在 SP/2 系統(tǒng)實(shí)現(xiàn)可伸縮的 WEB 服務(wù)器。 TCP Router 修改請(qǐng)求報(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 的 NetDispatcher10是 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-IP11中，每臺(tái)服務(wù)器都獨(dú)立的 IP 地址，但都用 IP Alias 配置上同一 VIP 地址，采用路由和廣播兩種方法分發(fā)請(qǐng)求，服務(wù)器收到請(qǐng)求后按 VIP 地址處理請(qǐng)求，并以 VIP 為源地址返回結(jié)果。這種方法也是為了避免回應(yīng)報(bào)文的重寫，但是每臺(tái)服務(wù)器用 IP Alias 配置上同一 VIP 地址，會(huì)導(dǎo)致地址沖突，有些操作系統(tǒng)會(huì)出現(xiàn)網(wǎng)絡(luò)失效。通過廣播分發(fā)請(qǐng)求， 同樣需要修改服務(wù)器操作系統(tǒng)的源碼來過濾報(bào)文，使得只有一臺(tái)服務(wù)器處理廣播來的請(qǐng)求。 微軟的 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)卡速度和處理能力。 通過 NAT 實(shí)現(xiàn)虛擬服務(wù)器（VS/NAT） 由于 IPv4 中 IP 地址空間的日益緊張和安全方面的原因，很多網(wǎng)絡(luò)使用保留 IP 地址 （/、/ 和 /）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)容，即不管請(qǐng)求被發(fā)送到哪一臺(tái)服務(wù)器，執(zhí) 行結(jié)果是一樣的。 服務(wù)的內(nèi)容可以復(fù)制到每臺(tái)服務(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í)，請(qǐng)求報(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)遷移，這里我們不一一敘述，請(qǐng)參見 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)對(duì)用戶 是透明的。對(duì)改寫后的報(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ù)中傳送，若我們只對(duì)報(bào)文頭的 IP 地址和端口號(hào)作轉(zhuǎn)換，這樣就會(huì)出現(xiàn)不一致性，服務(wù)會(huì)中斷。所以，針對(duì)這些服務(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、 AudioLink、 SoftwareVision、 NTT NTT Yamaha MIDPlug、 iChat Pager、Quake 和 Diablo。 下面，舉個(gè)例子來進(jìn)一步說明 VS/NAT，如圖 3 所示： 圖 3：VS/NAT 的例子 VS/NAT 的配置如下表所示，所有到 IP 地址為 和端口為 80 的流量都被負(fù)載均 衡地調(diào)度的真實(shí)服務(wù)器 :80 和 :8000 上。 目標(biāo)地址為 :21 的報(bào)文被轉(zhuǎn)移到 :21 上。而到其他端口的報(bào)文將被拒絕。 Protocol TCP TCP Virtual IP Address Port 80 21 Real IP Address Port 80 8000 21 Weight 1 2 1 從以下的例子中，我們可以更詳細(xì)地了解報(bào)文改寫的流程。 訪問 Web 服務(wù)的報(bào)文可能有以下的源地址和目標(biāo)地址： SOURCE :3456 DEST :80 調(diào)度器從調(diào)度列表中選出一臺(tái)服務(wù)器， 例如是 :8000。 該報(bào)文會(huì)被改寫為如下地址， 并將它發(fā)送給選出的服務(wù)器。 SOURCE :3456 DEST :8000 從服務(wù)器返回到調(diào)度器的響應(yīng)報(bào)文如下： SOURCE :8000 DEST :3456 響應(yīng)報(bào)文的源地址會(huì)被改寫為虛擬服務(wù)的地址，再將報(bào)文發(fā)送給客戶： SOURCE :80 DEST :3456 這樣，客戶認(rèn)為是從 :80 服務(wù)得到正確的響應(yīng)，而不會(huì)知道該請(qǐng)求是服務(wù)器 還是服務(wù)器 處理的。 通過 IP 隧道實(shí)現(xiàn)虛擬服務(wù)器（VS/TUN） 在 VS/NAT 的集群系統(tǒng)中，請(qǐ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)： 請(qǐng)求報(bào)文較短而響應(yīng)報(bào)文往往包含大量的數(shù)據(jù)。 如果能將請(qǐng)求和響應(yīng)分開處 理， 即在負(fù)載調(diào)度器中只負(fù)責(zé)調(diào)度請(qǐng)求而響應(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ù)將請(qǐng)求報(bào)文封裝轉(zhuǎn)發(fā)給后端服務(wù)器，響應(yīng)報(bào)文能從后端服務(wù)器直接返回 給客戶。 但在這里， 后端服務(wù)器有一組而非一個(gè)， 所以我們不可能靜態(tài)地建立一一對(duì)應(yīng)的隧道， 而是動(dòng)態(tài)地選擇一臺(tái)服務(wù)器，將請(qǐng)求報(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)地選擇一臺(tái)服務(wù)器，將請(qǐng)求報(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è)請(qǐng)求，然后根據(jù)路由表將響應(yīng)報(bào)文直接返回給客戶。 VS/TUN 圖 5：VS/TUN 的工作流程 在這里需要指出，根據(jù)缺省的 TCP/IP 協(xié)議棧處理，請(qǐng)求報(bào)文的目標(biāo)地址為 VIP，響應(yīng)報(bào)文的 源地址肯定也為 VIP，所以響應(yīng)報(bào)文不需要作任何修改，可以直接返回給客戶，客戶認(rèn)為得到 正常的服務(wù)，而不會(huì)知道究竟是哪一臺(tái)服務(wù)器處理的。 圖 6：半連接的 TCP 有限狀態(tài)機(jī) 通過直接路由實(shí)現(xiàn)虛擬服務(wù)器（VS/DR） 跟 VS/TUN 方法相同，VS/DR 利用大多數(shù) Internet 服務(wù)的非對(duì)稱特點(diǎn)，負(fù)載調(diào)度器中只負(fù)責(zé)調(diào) 度請(qǐng)求，而服務(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 地址是對(duì)外可見的， 用于接收虛擬服務(wù)的請(qǐng)求報(bào)文； 所有的服務(wù)器把 VIP 地址配置在 各自的 Non-ARP 網(wǎng)絡(luò)設(shè)備上， 它對(duì)外面是不可見的， 只是用于處理目標(biāo)地址為 VIP 的網(wǎng)絡(luò)請(qǐng)求。 圖 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)地選擇一臺(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é)議棧處理，請(qǐng)求報(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)遷移。 三種方法的優(yōu)缺點(diǎn)比較 三種 IP 負(fù)載均衡技術(shù)的優(yōu)缺點(diǎn)歸納在下表中： _ Server server network server number server gateway VS/NAT any private low (1020) 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ù)器的硬件配置相同，而且是對(duì)一般 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)樵?VS/NAT 中請(qǐng)求和響應(yīng)報(bào)文都需要通過 負(fù)載調(diào)度器。 我們?cè)?Pentium 166 處理器的主機(jī)上測得重寫報(bào)文的平均延時(shí)為 60us，性能更 高的處理器上延時(shí)會(huì)短一些。假設(shè) TCP 報(bào)文的平均長度為 536 Bytes，則調(diào)度器的最大吞吐量 為 8.93 MBytes/s. 我們?cè)偌僭O(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)吞吐量的更好方法。 對(duì)于那些將 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)度器只將請(qǐng)求調(diào)度到不同的后端服務(wù)器，后端服務(wù)器將應(yīng)答 的數(shù)據(jù)直接返回給用戶。這樣，負(fù)載調(diào)度器就可以處理大量的請(qǐng)求，它甚至可以調(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ù)對(duì)服務(wù)器有要求，即所有的服務(wù)器必須支持“IP Tunneling”或者“IP Encapsulation”協(xié)議。目前，VS/TUN 的后端服務(wù)器主要運(yùn)行 Linux 操作系統(tǒng)，我們沒對(duì)其他 操作系統(tǒng)進(jìn)行測試。因?yàn)椤癐P 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 端口上。 小結(jié) 本文主要講述了 LVS 集群中的三種 IP 負(fù)載均衡技術(shù)。在分析網(wǎng)絡(luò)地址轉(zhuǎn)換方法（VS/NAT）的缺點(diǎn)和網(wǎng)絡(luò)服務(wù)的非對(duì)稱性的基 礎(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,