web集群服務(wù)的負載均衡方案選擇與實現(xiàn)

責任編輯:Zane

2011-06-13 09:06:31

摘自:eNet硅谷動力

web應(yīng)用服務(wù)器集群系統(tǒng),是由一群同時運行同一個web應(yīng)用的服務(wù)器組成的集群系統(tǒng),在外界看來,就像是一個服務(wù)器一樣。通過故障恢復機制獲得高可靠性. 故障恢復發(fā)生在當集群中某個節(jié)點...

web應(yīng)用服務(wù)器集群系統(tǒng),是由一群同時運行同一個web應(yīng)用的服務(wù)器組成的集群系統(tǒng),在外界看來,就像是一個服務(wù)器一樣。為了均衡集群服務(wù)器的負載,達到優(yōu)化系統(tǒng)性能的目的,集群服務(wù)器將眾多的訪問請求,分散到系統(tǒng)中的不同節(jié)點進行處理。從而實現(xiàn)了更高的有效性和穩(wěn)定性,而這也正是基于Web的企業(yè)應(yīng)用所必須具備的特性。

高可靠性可以看作為系統(tǒng)的一種冗余設(shè)定。對于一個特定的請求,如果所申請的服務(wù)器不能進行處理的話,那么其他的服務(wù)器能不能對之進行有效的處理呢?對于一個高效的系統(tǒng),如果一個Web服務(wù)器失敗的話,其他的服務(wù)器可以馬上取代它的位置,對所申請的請求進行處理,而且這一過程對用戶來說,要盡可能的透明,使用戶察覺不到!

穩(wěn)定性決定了應(yīng)用程序能否支持不斷增長的用戶請求數(shù)量,它是應(yīng)用程序自身的一種能力。穩(wěn)定性是影響系統(tǒng)性能的眾多因素的一種有效的測量手段,包括機群系統(tǒng)所能支持的同時訪問系統(tǒng)的最大用戶數(shù)目以及處理一個請求所需要的時間。

在現(xiàn)有眾多的均衡服務(wù)器負載的方法中,廣泛研究并使用的是以下兩個方法:

DNS負載平衡的方法RR-DNS(Round-Robin Domain Name System)

負載均衡器

以下,我們將就這兩種方法進行討論。

DNS輪流排程 RR-DNS(Round-Robin Domain Name System)

域名服務(wù)器(Domain Name Server)中的數(shù)據(jù)文件將主機名字映射到其IP地址。當你在瀏覽器中鍵入一個URL時(例如:www.loadbalancedsite.com),瀏覽器則將請求發(fā)送到DNS,要求其返回相應(yīng)站點的IP地址,這被稱為DNS查詢。當瀏覽器獲得該站點的IP地址后,便通過該IP地址連接到所要訪問的站點,將頁面展現(xiàn)在用戶面前。

域名服務(wù)器(DNS)通常包含一個單一的IP地址與該IP地址所映射的站點的名稱的列表。在我們上面所假象的例子中,www.loadbalancedsite.com 這個站點的映射IP地址為203.24.23.3。

為了利用DNS均衡服務(wù)器的負載,對于同一個站點來講,在DNS服務(wù)器中同時擁有幾個不同的IP地址。這幾個IP地址代表集群中不同的機器,并在邏輯上映射到同一個站點名。通過我們的例子可以更好的理解這一點,www.loadbalancedsite.com將通過下面的三個IP地址發(fā)布到一個集群中的三臺機器上:

203.34.23.3

203.34.23.4

203.34.23.5

在本例中,DNS服務(wù)器中包含下面的映射表:

www.loadbalancedsite.com 203.34.23.3

www.loadbalancedsite.com 203.34.23.4

www.loadbalancedsite.com 203.34.23.5

當?shù)谝粋€請求到達DNS服務(wù)器時,返回的是第一臺機器的IP地址203.34.23.3;當?shù)诙€請求到達時,返回的是第二臺機器的IP地址203.34.23.4,以此類推。當?shù)谒膫€請求到達時,第一臺機器的IP地址將被再次返回,循環(huán)調(diào)用。

利用上述的DNS Round Robin技術(shù),對于某一個站點的所有請求將被平均的分配到及群中的機器上。因此,在這種技術(shù)中,集群中的所有的節(jié)點對于網(wǎng)絡(luò)來說都是可見的。

DNS 輪流排程的優(yōu)勢

DNS Round Robin的最大的優(yōu)點就是易于實現(xiàn)和代價低廉:

代價低,易于建立。 為了支持輪流排程,系統(tǒng)管理員只需要在DNS服務(wù)器上作一些改動,而且在許多比較新的版本的DNS服務(wù)器上已經(jīng)增加了這種功能。對于Web應(yīng)用來說,不需要對代碼作任何的修改;事實上,Web應(yīng)用本身并不會意識到負載均衡配置,即使在它面前。

簡單. 不需要網(wǎng)絡(luò)專家來對之進行設(shè)定,或在出現(xiàn)問題時對之進行維護。

DNS 輪流排程的缺點

這種基于軟件的負載均衡方法主要存在兩處不足,一是不實時支持服務(wù)期間的關(guān)聯(lián),一是不具有高可靠性。

不支持服務(wù)器間的一致性。服務(wù)器一致性是負載均衡系統(tǒng)所應(yīng)具備的一種能力,通過它,系統(tǒng)可以根據(jù)會話信息是屬于服務(wù)器端的,還是底層數(shù)據(jù)庫級別的,繼而將用戶的請求導向相應(yīng)的服務(wù)器。而DNS輪流排程則不具備這種智能化的特性。它是通過cookie、隱藏域、重寫URL三種方法中的一種來進行相似的判斷的。當用戶通過上述基于文本標志的方法與服務(wù)器建立連接之后,其所有的后續(xù)訪問均是連接到同一個服務(wù)器上。問題是,服務(wù)器的IP是被瀏覽器暫時存放在緩存中,一旦記錄過期,則需要重新建立連接,那么同一個用戶的請求很可能被不同的服務(wù)器進行處理,則先前的所有會話信息便會丟失。

不支持高可靠性。設(shè)想一個具有N個節(jié)點的集群。如果其中的一個節(jié)點毀壞,那么所有的訪問該節(jié)點的請求將不會有所回應(yīng),這是任何人都不愿意看到的。比較先進的路由器可以通過每隔一定的時間間隔,對節(jié)點檢查,如果有毀壞的節(jié)點,則將之從列表中去除的方法,解決這個問題。但是,由于在Internet上,ISPs將眾多的DNS存放在緩存中,以節(jié)省訪問時間,因此,DNS的更新就會變得非常緩慢,以至于有的用戶可能會訪問一些已經(jīng)不存在的站點,或者一些新的站點得不到訪問。所以,盡管DNS輪流排程在一定程度上解決了負載均衡問題,但這種狀況的改變并不是十分樂觀和有效的。

[page]

除了上面介紹的輪流排程方法外,還有三種DNS負載均衡處理分配方法,將這四種方法列出如下:

Round robin (RRS): 將工作平均的分配到服務(wù)器 (用于實際服務(wù)主機性能一致)

Least-connections (LCS): 向較少連接的服務(wù)器分配較多的工作(IPVS 表存儲了所有的活動的連接。用于實際服務(wù)主機性能一致。)

Weighted round robin (WRRS): 向較大容量的服務(wù)器分配較多的工作。可以根據(jù)負載信息動態(tài)的向上或向下調(diào)整。 (用于實際服務(wù)主機性能不一致時)

Weighted least-connections (WLC): 考慮它們的容量向較少連接的服務(wù)器分配較多的工作。容量通過用戶指定的砝碼來說明,可以根據(jù)裝載信息動態(tài)的向上或向下調(diào)整。(用于實際服務(wù)主機性能不一致時)

負載均衡器

負載均衡器通過虛擬IP地址方法,解決了輪流排程所面臨的許多問題。使用了負載均衡器集群系統(tǒng),在外部看來,像是具有一個IP地址的單一服務(wù)器一樣,當然,這個IP地址是虛擬的,它映射了集群中的每一臺機器的地址。所以,在某種程度上,負載均衡器是將整個集群的IP地址報漏給外部網(wǎng)絡(luò)。

當請求到達負載均衡器時,它會重寫該請求的頭文件,并將之指定到集群中的機器上。如果某臺機器被從集群中移除了,請求不會別發(fā)往已經(jīng)不存在的服務(wù)器上,因為所有的機器表面上都具有同一個IP地址,即使集群中的某個節(jié)點被移除了,該地址也不會發(fā)生變化。而且,internet上緩存的DNS條目也不再是問題了。當返回一個應(yīng)答時,客戶端看到的只是從負載均衡器上所返回的結(jié)果。也就是說,客戶端操作的對象是負載均衡器,對于其更后端的操作,對客戶端來講,是完全透明的。

負載均衡器的優(yōu)點

服務(wù)器一致性. 負載均衡器讀取客戶端發(fā)出的每一個請求中所包含的cookies或url解釋?;谒x出的這些信息,負載均衡器就可以重寫報頭并將請求發(fā)往集群中合適的節(jié)點上,該節(jié)點維護著相應(yīng)客戶端請求的會話信息。在HTTP通信中,負載均衡器可以提供服務(wù)器一致性,但并不是通過一個安全的途徑(例如:HTTPS)來提供這種服務(wù)。當消息被加密后(SSL),負載均衡器就不能讀出隱藏在其中的會話信息。

通過故障恢復機制獲得高可靠性. 故障恢復發(fā)生在當集群中某個節(jié)點不能處理請求,需將請求重新導向到其他節(jié)點時。主要有兩種故障恢復:

請求級故障恢復。當集群中的一個節(jié)點不能處理請求時(通常是由于down機),請求被發(fā)送到其他節(jié)點。當然,在導向到其他節(jié)點的同時,保存在原節(jié)點上的會話信息將會丟失。

透明會話故障恢復。當一個引用失敗后,負載均衡器會將之發(fā)送到集群中其他的節(jié)點上,以完成操作,這一點對用戶來說是透明的。由于透明會話故障恢復需要節(jié)點具備相應(yīng)的操作信息,因此為了實現(xiàn)該功能,集群中的所有節(jié)點必須具有公共存儲區(qū)域或通用數(shù)據(jù)庫,存儲會話信息數(shù)據(jù),以提供每個節(jié)點在進行單獨進程會話故障恢復時所需要的操作信息。

統(tǒng)計計量。既然所有的Web應(yīng)用請求都必須經(jīng)過負載均衡系統(tǒng),那么系統(tǒng)就可以確定活動會話的數(shù)量,在任何實例訪問中的活動會話的數(shù)目,應(yīng)答的次數(shù),高峰負載次數(shù),以及在高峰期和低谷期的會話的數(shù)目,還有其他更多的。所有的這些統(tǒng)計信息都可以被很好的用來調(diào)整整個系統(tǒng)的性能。

負載均衡器的缺點

硬件路由的缺點在于費用、復雜性以及單點失敗的。由于所有的請求均是通過一個單一的硬件負載均衡器來傳遞,因此,負載均衡器上的任何故障都將導致整個站點的崩潰。

HTTPS請求的負載均衡

正如上面所提到的,很難在那些來自HTTPS的請求上進行負載均衡和會話信息維護處理。因為,這些請求中的信息已經(jīng)被加密了。負載均衡器沒有能力處理這類請求。不過,這里有兩種方法可以解決這一問題:

代理網(wǎng)絡(luò)服務(wù)器

硬件SSL解碼器

代理服務(wù)器位于服務(wù)器集群之前,首先由它接受所有的請求并對之進行解密,然后將這些處理后的請求根據(jù)頭信息重新發(fā)往相應(yīng)的節(jié)點上,這種方式不需要硬件上的支持,但會增加代理服務(wù)器的額外的負擔。

硬件SSL解碼器,則是在請求到達負載均衡器之前,先經(jīng)由它進行解密處理。這種方式比代理服務(wù)器的處理速度要快捷一些。但代價也高,而且實現(xiàn)比較復雜。

鏈接已復制,快去分享吧

企業(yè)網(wǎng)版權(quán)所有?2010-2024 京ICP備09108050號-6京公網(wǎng)安備 11010502049343號