共計(jì) 4188 個(gè)字符，預(yù)計(jì)需要花費(fèi) 11 分鐘才能閱讀完成。

這篇文章主要介紹 Linux 服務(wù)器集群系統(tǒng)中如何實(shí)現(xiàn)虛擬服務(wù)器，文中介紹的非常詳細(xì)，具有一定的參考價(jià)值，感興趣的小伙伴們一定要看完！

實(shí)現(xiàn)虛擬服務(wù)的相關(guān)方法：

在網(wǎng)絡(luò)服務(wù)中，一端是客戶程序，另一端是服務(wù)程序，在中間可能有代理程序。由此看來，可以在不同的層次上實(shí)現(xiàn)多臺(tái)服務(wù)器的負(fù)載均衡。用集群解決網(wǎng)絡(luò)服務(wù)性能問題的現(xiàn)有方法主要分為以下四類。

1. 基于 RR-DNS 的解決方法

NCSA 的可伸縮的 WEB 服務(wù)器系統(tǒng)就是最早基于 RR-DNS(Round-Robin Domain Name System)的原型系統(tǒng)[1,2]。它的結(jié)構(gòu)和工作流程如下圖所示：

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

有一組 WEB 服務(wù)器，他們通過分布式文件系統(tǒng) AFS(Andrew File System)來共享所有的 HTML 文檔。這組服務(wù)器擁有相同的域名(如 www.ncsa.uiuc.edu)，當(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 地址的映射不被長(zhǎng)久緩沖，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è)值太小，例如是 0，會(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ā)性和訪問方式不同，例如有的人訪問一下就離開了，而有的人訪問可長(zhǎng)達(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”按鈕，也無(wú)濟(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 地址從中劃掉，然后等上幾天或者更長(zhǎng)的時(shí)間，等所有域名服器將該域名到這臺(tái)服務(wù)器的映射淘汰，和所有映射到這臺(tái)服務(wù)器的客戶機(jī)不再使用該站點(diǎn)為止。

2. 基于客戶端的解決方法

基于客戶端的解決方法需要每個(gè)客戶程序都有一定的服務(wù)器集群的知識(shí)，進(jìn)而把以負(fù)載均衡的方式將請(qǐng)求發(fā)到不同的服務(wù)器。例如，Netscape Navigator 瀏覽器訪問 Netscape 的主頁(yè)時(shí)，它會(huì)隨機(jī)地從一百多臺(tái)服務(wù)器中挑選第 N 臺(tái)，*** 將請(qǐng)求送往 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ā)請(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ò)流量，不具有普遍的適用性。

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]、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 請(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)行分析和重寫。這些處理都需要不小的 CPU、內(nèi)存和網(wǎng)絡(luò)等資源開銷，且處理時(shí)間長(zhǎng)。所構(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)度器。

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 的 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 修改請(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 的 NetDispatcher[10]是 TCP Router 的后繼者，它將報(bào)文轉(zhuǎn)發(fā)給服務(wù)器，而服務(wù)器在 non-ARP 的設(shè)備配置路由器的地址。這種方法與 LVS 集群中的 VS/DR 類似，它具有很高的可伸縮性，但一套在 IBM SP/ 2 和 NetDispatcher 需要上百萬(wàn)美金。總的來說，IBM 的技術(shù)還挺不錯(cuò)的。

在貝爾實(shí)驗(yàn)室的 ONE-IP[11]中，每臺(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 年底收購(gòu) 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)卡速度和處理能力。

以上是“Linux 服務(wù)器集群系統(tǒng)中如何實(shí)現(xiàn)虛擬服務(wù)器”這篇文章的所有內(nèi)容，感謝各位的閱讀！希望分享的內(nèi)容對(duì)大家有幫助，更多相關(guān)知識(shí)，歡迎關(guān)注丸趣 TV 行業(yè)資訊頻道！