Linux服務(wù)器集群系統(tǒng)中如何實(shí)現(xiàn)虛擬服務(wù)器

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

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

在網(wǎng)絡(luò)服務(wù)中，一端是客戶程序，另一端是服務(wù)程序，在中間可能有代理程序。由此看來(lái)，可以在不同的層次上實(shí)現(xiàn)多臺(tái)服務(wù)器的負(fù)載均衡。用集群解決網(wǎng)絡(luò)服務(wù)性能問(wèn)題的現(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ù)器，他們通過(guò)分布式文件系統(tǒng)AFS(Andrew File System)來(lái)共享所有的HTML文檔。這組服務(wù)器擁有相同的域名(如www.ncsa.uiuc.edu)，當(dāng)用戶按照這個(gè)域名訪問(wèn)時(shí), RR-DNS服務(wù)器會(huì)把域名輪流解析到這組服務(wù)器的不同IP地址，從而將訪問(wèn)負(fù)載分到各臺(tái)服務(wù)器上。

這種方法帶來(lái)幾個(gè)問(wèn)題。***，域名服務(wù)器是一個(gè)分布式系統(tǒng)，是按照一定的層次結(jié)構(gòu)組織的。當(dāng)用戶就域名解析請(qǐng)求提交給本地的域名服務(wù)器，它會(huì)因不能直接解析而向上一級(jí)域名服務(wù)器提交，上一級(jí)域名服務(wù)器再依次向上提交，直到RR-DNS域名服器把這個(gè)域名解析到其中一臺(tái)服務(wù)器的IP地址?？梢?jiàn)，從用戶到RR-DNS間存在多臺(tái)域名服器，而它們都會(huì)緩沖已解析的名字到IP地址的映射,這會(huì)導(dǎo)致該域名服器組下所有用戶都會(huì)訪問(wèn)同一WEB服務(wù)器，出現(xiàn)不同WEB服務(wù)器間嚴(yán)重的負(fù)載不平衡。為了保證在域名服務(wù)器中域名到IP地址的映射不被長(zhǎng)久緩沖，RR-DNS在域名到IP地址的映射上設(shè)置一個(gè)TTL(Time To Live)值，過(guò)了這一段時(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值的影響，用戶的訪問(wèn)請(qǐng)求會(huì)被送到同一臺(tái)WEB服務(wù)器上。由于用戶訪問(wèn)請(qǐng)求的突發(fā)性和訪問(wèn)方式不同，例如有的人訪問(wèn)一下就離開(kāi)了，而有的人訪問(wèn)可長(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ù)的平均比率超過(guò)百分之三十。也就是說(shuō)，當(dāng)TTL值為0時(shí)，因?yàn)橛脩粼L問(wèn)的突發(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瀏覽器訪問(wèn)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)求來(lái)收集服務(wù)器的負(fù)載等信息，再根據(jù)這些信息將客戶的請(qǐng)求發(fā)到相應(yīng)的服務(wù)器。高可用性也在Applet中實(shí)現(xiàn)，當(dāng)服務(wù)器沒(méi)有響應(yīng)時(shí)，Applet向另一個(gè)服務(wù)器轉(zhuǎn)發(fā)請(qǐng)求。這種方法的透明性不好，Applet向各服務(wù)器查詢來(lái)收集信息會(huì)增加額外的網(wǎng)絡(luò)流量，不具有普遍的適用性。

3. 基于應(yīng)用層負(fù)載均衡調(diào)度的解決方法

多臺(tái)服務(wù)器通過(guò)高速的互聯(lián)網(wǎng)絡(luò)連接成一個(gè)集群系統(tǒng)，在前端有一個(gè)基于應(yīng)用層的負(fù)載調(diào)度器。當(dāng)用戶訪問(wèn)請(qǐng)求到達(dá)調(diào)度器時(shí)，請(qǐng)求會(huì)提交給作負(fù)載均衡調(diào)度的應(yīng)用程序，分析請(qǐng)求，根據(jù)各個(gè)服務(wù)器的負(fù)載情況，選出一臺(tái)服務(wù)器，重寫(xiě)請(qǐng)求并向選出的服務(wù)器訪問(wèn)，取得結(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ù)器程序改寫(xiě)而成的，采用單進(jìn)程事件驅(qū)動(dòng)的服務(wù)器結(jié)構(gòu)。pWeb就是一個(gè)基于Apache 1.1服務(wù)器程序改寫(xiě)而成的并行WEB調(diào)度程序，當(dāng)一個(gè)HTTP請(qǐng)求到達(dá)時(shí)，pWeb會(huì)選出一個(gè)服務(wù)器，重寫(xiě)請(qǐng)求并向這個(gè)服務(wù)器發(fā)出改寫(xiě)后的請(qǐng)求，等結(jié)果返回后，再將結(jié)果轉(zhuǎn)發(fā)給客戶。Reverse-Proxy利用Apache 1.3.1中的Proxy模塊和Rewrite模塊實(shí)現(xiàn)一個(gè)可伸縮WEB服務(wù)器，它與pWeb的不同之處在于它要先從Proxy的cache中查找后，若沒(méi)有這個(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)求，或者通過(guò)redirect錯(cuò)誤代碼將客戶引到另一臺(tái)WEB服務(wù)器，以實(shí)現(xiàn)一個(gè)可伸縮的WEB服務(wù)器。

基于應(yīng)用層負(fù)載均衡調(diào)度的多服務(wù)器解決方法也存在一些問(wèn)題。***，系統(tǒng)處理開(kāi)銷特別大，致使系統(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)行分析和重寫(xiě)。這些處理都需要不小的CPU、內(nèi)存和網(wǎng)絡(luò)等資源開(kāi)銷，且處理時(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)用，需要寫(xiě)不同的調(diào)度器。以上幾個(gè)系統(tǒng)都是基于HTTP協(xié)議，若對(duì)于FTP、Mail、POP3等應(yīng)用，都需要重寫(xiě)調(diào)度器。

4. 基于IP層負(fù)載均衡調(diào)度的解決方法

用戶通過(guò)虛擬IP地址(Virtual IP Address)訪問(wèn)服務(wù)時(shí)，訪問(wèn)請(qǐng)求的報(bào)文會(huì)到達(dá)負(fù)載調(diào)度器，由它進(jìn)行負(fù)載均衡調(diào)度，從一組真實(shí)服務(wù)器選出一個(gè)，將報(bào)文的目標(biāo)地址Virtual IP Address改寫(xiě)成選定服務(wù)器的地址，報(bào)文的目標(biāo)端口改寫(xiě)成選定服務(wù)器的相應(yīng)端口，***將報(bào)文發(fā)送給選定的服務(wù)器。真實(shí)服務(wù)器的回應(yīng)報(bào)文經(jīng)過(guò)負(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èn)網(wǎng)絡(luò)設(shè)備接近核心空間的速度，降低了上下文切換的處理開(kāi)銷，但并不徹底，它只是研究的原型系統(tǒng)，沒(méi)有成為有用的系統(tǒng)存活下來(lái)。Cisco的LocalDirector、Alteon的ACEDirector和F5的Big/IP是非常昂貴的商品化系統(tǒng)，它們支持部分TCP/UDP協(xié)議，有些在ICMP處理上存在問(wèn)題。

IBM的TCP Router[9]使用修改過(guò)的網(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)文的源地址置為T(mén)CP 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)美金?？偟膩?lái)說(shuō)，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)文的重寫(xiě)，但是每臺(tái)服務(wù)器用IP Alias配置上同一VIP地址，會(huì)導(dǎo)致地址沖突，有些操作系統(tǒng)會(huì)出現(xiàn)網(wǎng)絡(luò)失效。通過(guò)廣播分發(fā)請(qǐng)求，同樣需要修改服務(wù)器操作系統(tǒng)的源碼來(lái)過(guò)濾報(bào)文，使得只有一臺(tái)服務(wù)器處理廣播來(lái)的請(qǐng)求。

微軟的Windows NT負(fù)載均衡服務(wù)(Windows NT Load Balancing Service，WLBS)[12]是1998年底收購(gòu)Valence Research公司獲得的，它與ONE-IP中的基于本地過(guò)濾方法一樣。WLBS作為過(guò)濾器運(yùn)行在網(wǎng)卡驅(qū)動(dòng)程序和TCP/IP協(xié)議棧之間，獲得目標(biāo)地址為VIP的報(bào)文，它的過(guò)濾算法檢查報(bào)文的源IP地址和端口號(hào)，保證只有一臺(tái)服務(wù)器將報(bào)文交給上一層處理。但是，當(dāng)有新結(jié)點(diǎn)加入和有結(jié)點(diǎn)失效時(shí)，所有服務(wù)器需要協(xié)商一個(gè)新的過(guò)濾算法，這會(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)注億速云行業(yè)資訊頻道！