如何解決WEB服務器流量超負載問題？

2013-07-24 15:33 作者：ly 瀏覽量：

 

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

 

一、計算WEB服務器負載量的兩種方法

 

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

 

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

 

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

 

　　在現有眾多的均衡服務器負載的方法中，廣泛研究并使用的是以下兩個方法：

 

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

 

　　負載均衡器

 

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

 

二、DNS輪流排程的優勢及缺點

 

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

 

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

 

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

 

　　203.34.23.3

 

　　203.34.23.4

 

　　203.34.23.5

 

　　在本例中，DNS服務器中包含下面的映射表：

 

　　www.loadbalancedsite.com 203.34.23.3

 

　　www.loadbalancedsite.com 203.34.23.4

 

　　www.loadbalancedsite.com 203.34.23.5

 

　　當第一個請求到達DNS服務器時，返回的是第一臺機器的IP地址203.34.23.3；當第二個請求到達時，返回的是第二臺機器的IP地址203.34.23.4，以此類推。當第四個請求到達時，第一臺機器的IP地址將被再次返回，循環調用。

 

　　利用上述的DNS Round Robin技術，對于某一個站點的所有請求將被平均的分配到及群中的機器上。因此，在這種技術中，集群中的所有的節點對于網絡來說都是可見的。

 

　　DNS 輪流排程的優勢

 

　　DNS Round Robin的最大的優點就是易于實現和代價低廉：

 

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

 

　　簡單. 不需要網絡專家來對之進行設定，或在出現問題時對之進行維護。

 

　　DNS 輪流排程的缺點

 

　　這種基于軟件的負載均衡方法主要存在兩處不足，一是不實時支持服務期間的關聯，一是不具有高可靠性。

 

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

 

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

 

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

 

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

 

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

 

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

 

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

 

三：傳統負載均衡器的優勢及缺點

　　

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

 

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

　　傳統負載均衡器的優點

 

　　服務器一致性. 負載均衡器讀取客戶端發出的每一個請求中所包含的cookies或url解釋。基于所讀出的這些信息，負載均衡器就可以重寫報頭并將請求發往集群中合適的節點上，該節點維護著相應客戶端請求的會話信息。在HTTP通信中，負載均衡器可以提供服務器一致性，但并不是通過一個安全的途徑（例如：HTTPS）來提供這種服務。當消息被加密后（SSL），負載均衡器就不能讀出隱藏在其中的會話信息。

 

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

 

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

 

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

 

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

 

　　傳統負載均衡器的缺點

 

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

 

　　HTTPS請求的負載均衡

 

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

 

　　代理網絡服務器

 

　　硬件SSL解碼器

 

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

 

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

 

做為一家企業IT服務提供商，我們有責任也有義務為企業提供IT外包的相關信息，為企業的發展提升更高的效率，創造更大價值。

艾銻無限，成就夢想！