怎么計(jì)算Web服務(wù)器的最大負(fù)載量

1、怎么計(jì)算WEB服務(wù)器的最大負(fù)載量？【編者按】web應(yīng)用服務(wù)器集群系統(tǒng)，是由一群同時(shí)運(yùn)行同一個(gè)web應(yīng)用的服務(wù)器組成的集群系統(tǒng)，在外界看來，就像是一個(gè)服務(wù)器一樣。為了均衡集群服務(wù)器的負(fù)載，達(dá)到優(yōu)化系統(tǒng)性能的目的，集群服務(wù)器將眾多的訪問請求，分散到系統(tǒng)中的不同節(jié)點(diǎn)進(jìn)行處理。從而實(shí)現(xiàn)了更高的有效性和穩(wěn)定性，而這也正是基于Web的企業(yè)應(yīng)用所必須具備的特性。【正文】web應(yīng)用服務(wù)器集群系統(tǒng)，是由一群同時(shí)運(yùn)行同一個(gè)web應(yīng)用的服務(wù)器組成的集群系統(tǒng)，在外界看來，就像是一個(gè)服務(wù)器一樣。為了均衡集群服務(wù)器的負(fù)載，達(dá)到優(yōu)化系統(tǒng)性能的目的，集群服務(wù)器將眾多的訪問請求，分散到系統(tǒng)中的不同節(jié)點(diǎn)進(jìn)行處理。從而實(shí)現(xiàn)了更高的

2、有效性和穩(wěn)定性，而這也正是基于Web的企業(yè)應(yīng)用所必須具備的特性。 高可靠性可以看作為系統(tǒng)的一種冗余設(shè)定。對于一個(gè)特定的請求，如果所申請的服務(wù)器不能進(jìn)行處理的話，那么其他的服務(wù)器能不能對之進(jìn)行有效的處理呢？對于一個(gè)高效的系統(tǒng)，如果一個(gè)Web服務(wù)器失敗的話，其他的服務(wù)器可以馬上取代它的位置，對所申請的請求進(jìn)行處理，而且這一過程對用戶來說，要盡可能的透明，使用戶察覺不到！ 穩(wěn)定性決定了應(yīng)用程序能否支持不斷增長的用戶請求數(shù)量，它是應(yīng)用程序自身的一種能力。穩(wěn)定性是影響系統(tǒng)性能的眾多因素的一種有效的測量手段，包括機(jī)群系統(tǒng)所能支持的同時(shí)訪問系統(tǒng)的最大用戶數(shù)目以及處理一個(gè)請求所需要的時(shí)間。 在現(xiàn)有眾多的均衡服

3、務(wù)器負(fù)載的方法中，廣泛研究并使用的是以下兩個(gè)方法： DNS負(fù)載平衡的方法RR-DNS(Round-Robin Domain Name System) 負(fù)載均衡器 以下，我們將就這兩種方法進(jìn)行討論。 DNS輪流排程 RR-DNS(Round-Robin Domain Name System) 在本例中，DNS服務(wù)器中包含下面的映射表： 利用上述的DNS Round Robin技術(shù)，對于某一個(gè)站點(diǎn)的所有請求將被平均的分配到及群中的機(jī)器上。因此，在這種技術(shù)中，集群中的所有的節(jié)點(diǎn)對于網(wǎng)絡(luò)來說都是可見的。 DNS 輪流排程的優(yōu)勢 DNS Round Robin的最大的優(yōu)點(diǎn)就是易于實(shí)現(xiàn)和代價(jià)低廉： 代價(jià)低

4、，易于建立。 為了支持輪流排程，系統(tǒng)管理員只需要在DNS服務(wù)器上作一些改動，而且在許多比較新的版本的DNS服務(wù)器上已經(jīng)增加了這種功能。對于Web應(yīng)用來說，不需要對代碼作任何的修改；事實(shí)上，Web應(yīng)用本身并不會意識到負(fù)載均衡配置，即使在它面前。 簡單. 不需要網(wǎng)絡(luò)專家來對之進(jìn)行設(shè)定，或在出現(xiàn)問題時(shí)對之進(jìn)行維護(hù)。 DNS 輪流排程的缺點(diǎn) 這種基于軟件的負(fù)載均衡方法主要存在兩處不足，一是不實(shí)時(shí)支持服務(wù)期間的關(guān)聯(lián)，一是不具有高可靠性。 不支持服務(wù)器間的一致性。服務(wù)器一致性是負(fù)載均衡系統(tǒng)所應(yīng)具備的一種能力，通過它，系統(tǒng)可以根據(jù)會話信息是屬于服務(wù)器端的，還是底層數(shù)據(jù)庫級別的，繼而將用戶的請求導(dǎo)向相應(yīng)的服務(wù)

5、器。而DNS輪流排程則不具備這種智能化的特性。它是通過cookie、隱藏域、重寫URL三種方法中的一種來進(jìn)行相似的判斷的。當(dāng)用戶通過上述基于文本標(biāo)志的方法與服務(wù)器建立連接之后，其所有的后續(xù)訪問均是連接到同一個(gè)服務(wù)器上。問題是，服務(wù)器的IP是被瀏覽器暫時(shí)存放在緩存中，一旦記錄過期，則需要重新建立連接，那么同一個(gè)用戶的請求很可能被不同的服務(wù)器進(jìn)行處理，則先前的所有會話信息便會丟失。 不支持高可靠性。設(shè)想一個(gè)具有N個(gè)節(jié)點(diǎn)的集群。如果其中的一個(gè)節(jié)點(diǎn)毀壞，那么所有的訪問該節(jié)點(diǎn)的請求將不會有所回應(yīng)，這是任何人都不愿意看到的。比較先進(jìn)的路由器可以通過每隔一定的時(shí)間間隔，對節(jié)點(diǎn)檢查，如果有毀壞的節(jié)點(diǎn)，則將之從

6、列表中去除的方法，解決這個(gè)問題。但是，由于在Internet上，ISPs將眾多的DNS存放在緩存中，以節(jié)省訪問時(shí)間，因此，DNS的更新就會變得非常緩慢，以至于有的用戶可能會訪問一些已經(jīng)不存在的站點(diǎn)，或者一些新的站點(diǎn)得不到訪問。所以，盡管DNS輪流排程在一定程度上解決了負(fù)載均衡問題，但這種狀況的改變并不是十分樂觀和有效的。 除了上面介紹的輪流排程方法外，還有三種DNS負(fù)載均衡處理分配方法，將這四種方法列出如下： Round robin (RRS)： 將工作平均的分配到服務(wù)器 (用于實(shí)際服務(wù)主機(jī)性能一致) Least-connections (LCS)： 向較少連接的服務(wù)器分配較多的工作(IPVS

7、 表存儲了所有的活動的連接。用于實(shí)際服務(wù)主機(jī)性能一致。) Weighted round robin (WRRS)： 向較大容量的服務(wù)器分配較多的工作。可以根據(jù)負(fù)載信息動態(tài)的向上或向下調(diào)整。 (用于實(shí)際服務(wù)主機(jī)性能不一致時(shí)) Weighted least-connections (WLC)： 考慮它們的容量向較少連接的服務(wù)器分配較多的工作。容量通過用戶指定的砝碼來說明，可以根據(jù)裝載信息動態(tài)的向上或向下調(diào)整。(用于實(shí)際服務(wù)主機(jī)性能不一致時(shí)) 【正文】負(fù)載均衡器 負(fù)載均衡器通過虛擬IP地址方法，解決了輪流排程所面臨的許多問題。使用了負(fù)載均衡器集群系統(tǒng)，在外部看來，像是具有一個(gè)IP地址的單一服務(wù)器一樣

8、，當(dāng)然，這個(gè)IP地址是虛擬的，它映射了集群中的每一臺機(jī)器的地址。所以，在某種程度上，負(fù)載均衡器是將整個(gè)集群的IP地址報(bào)漏給外部網(wǎng)絡(luò)。 當(dāng)請求到達(dá)負(fù)載均衡器時(shí)，它會重寫該請求的頭文件，并將之指定到集群中的機(jī)器上。如果某臺機(jī)器被從集群中移除了，請求不會別發(fā)往已經(jīng)不存在的服務(wù)器上，因?yàn)樗械臋C(jī)器表面上都具有同一個(gè)IP地址，即使集群中的某個(gè)節(jié)點(diǎn)被移除了，該地址也不會發(fā)生變化。而且，internet上緩存的DNS條目也不再是問題了。當(dāng)返回一個(gè)應(yīng)答時(shí)，客戶端看到的只是從負(fù)載均衡器上所返回的結(jié)果。也就是說，客戶端操作的對象是負(fù)載均衡器，對于其更后端的操作，對客戶端來講，是完全透明的。 負(fù)載均衡器的優(yōu)點(diǎn) 服務(wù)

9、器一致性. 負(fù)載均衡器讀取客戶端發(fā)出的每一個(gè)請求中所包含的cookies或url解釋?；谒x出的這些信息，負(fù)載均衡器就可以重寫報(bào)頭并將請求發(fā)往集群中合適的節(jié)點(diǎn)上，該節(jié)點(diǎn)維護(hù)著相應(yīng)客戶端請求的會話信息。在HTTP通信中，負(fù)載均衡器可以提供服務(wù)器一致性，但并不是通過一個(gè)安全的途徑（例如：HTTPS）來提供這種服務(wù)。當(dāng)消息被加密后（SSL），負(fù)載均衡器就不能讀出隱藏在其中的會話信息。 通過故障恢復(fù)機(jī)制獲得高可靠性. 故障恢復(fù)發(fā)生在當(dāng)集群中某個(gè)節(jié)點(diǎn)不能處理請求，需將請求重新導(dǎo)向到其他節(jié)點(diǎn)時(shí)。主要有兩種故障恢復(fù)： 請求級故障恢復(fù)。當(dāng)集群中的一個(gè)節(jié)點(diǎn)不能處理請求時(shí)（通常是由于down機(jī)），請求被發(fā)送到其

10、他節(jié)點(diǎn)。當(dāng)然，在導(dǎo)向到其他節(jié)點(diǎn)的同時(shí)，保存在原節(jié)點(diǎn)上的會話信息將會丟失。 透明會話故障恢復(fù)。當(dāng)一個(gè)引用失敗后，負(fù)載均衡器會將之發(fā)送到集群中其他的節(jié)點(diǎn)上，以完成操作，這一點(diǎn)對用戶來說是透明的。由于透明會話故障恢復(fù)需要節(jié)點(diǎn)具備相應(yīng)的操作信息，因此為了實(shí)現(xiàn)該功能，集群中的所有節(jié)點(diǎn)必須具有公共存儲區(qū)域或通用數(shù)據(jù)庫，存儲會話信息數(shù)據(jù)，以提供每個(gè)節(jié)點(diǎn)在進(jìn)行單獨(dú)進(jìn)程會話故障恢復(fù)時(shí)所需要的操作信息。 統(tǒng)計(jì)計(jì)量。既然所有的Web應(yīng)用請求都必須經(jīng)過負(fù)載均衡系統(tǒng)，那么系統(tǒng)就可以確定活動會話的數(shù)量，在任何實(shí)例訪問中的活動會話的數(shù)目，應(yīng)答的次數(shù)，高峰負(fù)載次數(shù)，以及在高峰期和低谷期的會話的數(shù)目，還有其他更多的。所有的這些統(tǒng)計(jì)信息都可以被很好的用來調(diào)整整個(gè)系統(tǒng)的性能。 負(fù)載均衡器的缺點(diǎn) 硬件路由的缺點(diǎn)在于費(fèi)用、復(fù)雜性以及單點(diǎn)失敗的。由于所有的請求均是通過一個(gè)單一的硬件負(fù)載均衡器來傳遞，因此，負(fù)載均衡器上的任何故障都將導(dǎo)致整個(gè)站點(diǎn)的崩潰。 HTTPS請求的負(fù)載均衡 正如上面所提到的，很難在那些來自HTTPS的請求上進(jìn)行負(fù)載均衡和會話信息維護(hù)處理。因?yàn)?，這些請求中的信息已經(jīng)被加密了。負(fù)載均衡器沒有能力處理這類請求。不過，這里有兩種方法可以解決這一問題： 代理網(wǎng)絡(luò)服務(wù)器 硬件S