負載均衡研究 基礎

1.概念：

　　負載均衡是由多臺服務器以對稱的方式組成一個服務器集合，每臺服務器都具備等價的地位，均可以單獨對外提供服務而無須其餘服務器的輔助。經過某種負載分擔技術，將外部發送來的請求均勻分配到對稱結構中的某一臺服務器上，而接收到請求的服務器獨立地迴應客戶的請求。均衡負載可以平均分配客戶請求到服務器列陣，籍此提供快速獲取重要數據，解決大量併發訪問服務問題。

　　負載平衡主要應用於Web網站，高流量的文件下載網站，NNTP（Network News Transfer Protocol）服務和DNS服務。負載平衡器一般是一個軟體程序，這個程序偵聽一個外部端口，互聯網用戶能夠經過這個端口來訪問服務，而做爲負載平衡器的軟體會將用戶的請求轉發給後臺內網服務器，內網服務器將請求的響應返回給負載平衡器，負載平衡器再將響應發送到用戶，這樣就向互聯網用戶隱藏了內網結構，阻止了用戶直接訪問後臺（內網）服務器，使得服務器更加安全，能夠阻止對核心網絡棧和運行在其它端口服務的攻擊。

2.網絡負載均衡的優勢
第一，網絡負載均衡能將傳入的請求傳播到多達32臺服務器上，便可以使用最多32臺服務器共同分擔對外的網絡請求服務。網絡負載均衡技術保證即便是在負載很重的狀況下，服務器也能作出快速響應;
第二，網絡負載均衡對外只需提供一個IP地址(或域名);
第三，當網絡負載均衡中的一臺或幾臺服務器不可用時，服務不會中斷。網絡負載均衡自動檢測到服務器不可用時，可以迅速在剩餘的服務器中從新指派客戶機通信。這項保護措施可以幫助你爲關鍵的業務程序提供不中斷的服務，並能夠根據網絡訪問量的增長來相應地增長網絡負載均衡服務器的數量;
第四，網絡負載均衡可在普通的計算機上實現。

3.算法

　　負載均衡器有各類各樣的工做排程算法（用於決定將前端用戶請求發送到哪個後臺服務器），最簡單的是隨機選擇和輪詢。更爲高級的負載均衡器會考慮其它更多的相關因素，如後臺服務器的負載，響應時間，運行狀態，活動鏈接數，地理位置，處理能力，或最近分配的流量。

4.構架

　　高性能系統一般會使用多層負載均衡。另外專用的硬件負載均衡器以及純軟件負載均衡器，包括開源的，例如Apache Web服務器的mod proxy balancer擴展，nginx，Varnish和Pound反向代理和負載均衡器。使用Gearman將合適的計算任務分發給多臺計算機，如此大量的任務就能夠更快的完成了。

5.持續性

　　負載均衡器須要處理的一個重要問題是：如何保存用戶會話？若是會話信息保存在後臺服務器，用戶接下來的請求可能會被分配到不一樣的後臺服務器，此時用戶會話就沒法繼續。負載均衡器能夠緩存用戶會話，而後將用戶請求分發到不一樣的後臺服務器。可是這將帶來負載均衡器的負載問題。一個解決方案是將一個用戶會話中的全部請求都發送到同一個後臺服務器。即persistence或stickiness。這個方法的不足之處在於沒法容錯,若是後臺服務器故障，它提供的會話就會沒法取得，任何依賴於它的會話都會丟失。第二個方案是依據用戶名，客戶端IP來分配提供服務的服務器，也能夠隨機分配。由於客戶多是經過DHCP，NAT或者Web代理來鏈接 Internet的，其IP地址可能常常變換，這使得這個方案的服務質量沒法保障。隨機分配由負載均衡器將會話信息存儲保存。若是負載均衡器被替換或故 障，這些信息可會會丟失；另外（負載均衡器）負載較高的時候，爲保證分配表空間不會被耗盡，超時的分配信息必須被刪除。隨機分配方法也要求客戶會維持會話 狀態，若是客戶瀏覽器禁用了cookies的功能，就會引發問題。優秀的負載均衡器會使用多種持續（會話保持）技術，以免其中某些不能夠用時引發故障。另一個方案是將每一會話信息保存到一個數據庫中。因爲這個方案會增長數據庫的負載，因此這個方案對性能的提升並很差。數據庫最好是用來存儲會話時間比較長的會話數據。爲了不數據庫出現單點故障，而且提升其擴展性，數據庫一般會複製到多臺服務器上，經過負載均衡器來分發請求到數據庫服務器上。微軟ASP.net中的狀態服務器技術就是一個典型的會話數據庫的例子。集羣中的全部服務器都將它們的會話信息保存到狀態服務器上，同時它們能夠向狀態服務器查詢會話數據。幸運的是有一種更有效的方法，一般客戶瀏覽器能夠保存用戶的每一個會話信息。例如使用瀏覽器cookie，對數據加密並加上一個時間戳就能夠保證安全了；URL重寫。 將會話信息存儲在客戶端一般是首選方案，由於這樣負載均衡器就能夠靈活的選擇後臺服務器來處理用戶請求。然而這種方法不適應於一些較複雜的電子商務，由於電子商務中會話數據較大，並且須要服務器須要常常從新處理會話信息；與此同時URL重寫因爲用戶能夠改變會話流數據而存在安全問題；加密客戶端 cookies也一直存在着安全方面的爭議，除非全部的會話都經過HTTPS，可是HTTPS很容易遭到中間人攻擊。

6.負載均衡器的特性

• 不對稱負載調節。能夠對後臺服務器設置權重因子，權重因子用於控制服務器的請求處理量，進而控制服務器的負載。當後臺服務器的處理能力不是等同的時候，這是一種控制服務器負載的簡單方法。
• 優先啓動。當出現故障的服務器達到某個閥值，或者服務器負載太高時，備用服務器必需能夠及時上線提供服務。
• SSL截斷和加速。依賴服務器負載，處理加密數據或者經過SSL進行的受權請求會消耗Web服務器的大量CPU，隨着需求增長用戶會明顯感受到響應時間變長。爲了消除Web服務器上這部分（處理加密）負載，負載均衡器可能會將SSL通信截斷在負載均衡器上。有些硬件負載均衡器上包含 有專門用於處理SSL的硬件。當負載均衡器截斷SSL鏈接請求，再將用戶請求轉發給後臺前將HTTPS變爲HTTP。只有負載均衡器不超載，這個特性不會影響用戶體驗。這種方法的負面效應是，因爲全部SSL都由負載均衡器一臺設備來處理，它會致使負載均衡器成爲負載均衡體系的一個瓶頸。若是不使用這個特 性，SSL請求將會分發給各個Web服務器處理。是否採用這一特性，須要分析比較二者的資金投入狀況，含有處理SSL特殊硬件的負載均衡器一般價格高昂，而Web服務器通常比較廉價。增長少許的Web服務器的花費可能明顯比升級負載均衡器要少。另外，一些服務器廠商如Oracle/Sun也開始在它們的 CPU中加入加密加速模塊，例如T2000。在負載均衡器上截斷SSL的另外一個優勢是容許負載均衡器能夠對基於HTTPS請求數據進行負載均衡或內容交 換。
• DDOS攻擊防禦。負載均衡器能夠提供例如SYN cookies特性和延時綁定（在TCP握手完成以前，後臺服務器不會與用戶通信）來減緩SYN flook攻擊，and generally offload work from the servers to a more efficient platform.
• HTTP壓縮。使用gzip壓縮HTTP數據，以減小網絡上的數據傳輸量。對於響應時間較長，傳輸距離較遠的用戶，這一特性對於縮短響應時間效果明顯。這個特性會要求更多一些的負載均衡器CPU，這一功能也能夠由Web服務器來完成。
• TCP offload。不一樣的廠商叫法可能不同。其主要思想是同樣的，一般每一個用戶的每一個請求都會使用一個不一樣的TCP鏈接，這個特性利用HTTP/1.1未來自多個用戶的多個請求合併爲單個TCP socket再轉發給後臺服務器。
• TCP緩衝。負載均衡器能夠暫存後臺服務器對客戶的響應數據，再將它們轉發給那些響應時間較長網速較慢的客戶，如此後臺Web服務器就能夠釋放相應的線程去處理其它任務如直接整個響應數據直接發送給網速較快的用戶。
• 後臺服務器直接響應用戶（Direct Server Return）。這是不對稱負載分佈的一項功能，在不對稱負載分佈中請求和迴應經過不一樣的網絡路徑。
• （服務器）健康檢查。負載均衡器能夠檢查後臺服務器應用層的健康情況並從服務器池中移除那些出現故障的服務器。
• HTTP緩存。負載均衡器能夠存儲靜態內容，當用戶請求它們時能夠直接響應用戶而沒必要再向後臺服務器請求。
• 內容過濾。有些負載均衡器能夠按要求修改經過它的數據。
• HTTP安全。有些負載均衡器能夠隱藏HTTP出錯頁面，刪除HTTP響應頭中的服務器標示信息，加密cookies以防止用戶修改。
• 優先隊列。也可稱之爲流量控制。它能夠對不一樣的內容設定不一樣的優先級。
• ontent-aware switching（內容感知開關）。大多數負載均衡器能夠基於用戶請求的URL發送請求到不一樣的後臺服務器，不管內容是加密（HTTPS）仍是沒有加密（HTTP）。
• 用戶受權。對來自不一樣身份驗證源的用戶進行驗證，而後再容許他們訪問一個網站。
• 可編程的流量控制。不僅一種負載均衡器容許使用腳本編程來定製負載均衡方法，任意的流量控制以及其它功能。
• 防火牆功能。因爲安全的緣由，不容許用戶直接訪問後臺服務器。防火牆是由一系列規則構成，它們決定着哪些請求能夠經過一個接口而哪些不被容許。
• 入侵阻止功能。在防火牆保障網絡層/傳輸層安全的基礎上，提供應用層安全防範。

7.四層負載均衡和七層負載均衡的區別

　　四層負載均衡是經過報文中的目標地址和端口，再加上負載均衡設備設置的服務器選擇方式，決定最終選擇的內部服務器與請求客戶端創建TCP鏈接，而後發送Client請求的數據。具體過程以下：在四層負載設備中，把client發送的報文目標地址(原來是負載均衡設備的IP地址)，根據均衡設備設置的選擇web服務器的規則選擇對應的web服務器IP地址，這樣client就能夠直接跟此服務器創建TCP鏈接併發送數據。

　　七層負載均衡，也稱內容交換，也就是主要經過報文中的真正有意義的應用層內容，再加上負載均衡設備設置的服務器選擇方式，決定最終選擇的服務器。具體過程以下：七層負載均衡服務器起了一個代理服務器的做用，咱們知道創建一次TCP鏈接要三次握手；而client要訪問webserver以前，要先與七層負載設備進行三次握手後創建TCP鏈接，把要訪問的報文信息發送給七層負載均衡；而後七層負載均衡再根據設置的均衡規則選擇特定的webserver，而後經過三次握手與此臺webserver創建TCP鏈接，而後webserver把須要的數據發送給七層負載均衡設備，負載均衡設備再把數據發送給client；因此，七層負載均衡設備起到了代理服務器的做用。帶來的好處：使整個網絡更「智能化」，能把對圖片類的請求轉發到圖片服務器，對文字的請求轉發到文字服務器。能夠有效防止 SYN Flood攻擊，是網站更安全。帶來的缺點：帶來設備配置複雜，負載均衡壓力增高以及故障排查上的複雜性等問題。

　　補充：所謂四層就是基於IP+端口的負載均衡；七層就是基於URL等應用層信息的負載均衡；同理，還有基於MAC地址的二層負載均衡和基於IP地址的三層負載均衡。 換句換說，二層負載均衡會經過一個虛擬MAC地址接收請求，而後再分配到真實的MAC地址；三層負載均衡會經過一個虛擬IP地址接收請求，而後再分配到真實的IP地址；四層經過虛擬IP+端口接收請求，而後再分配到真實的服務器；七層經過虛擬的URL或主機名接收請求，而後再分配到真實的服務器。所謂的四到七層的負載均衡，就是在對後臺的服務器進行負載均衡時，依據四層的信息或七層的信息來決定怎麼樣轉發流量。好比四層的負載均衡，就是經過發佈三層的IP地址（VIP），而後加四層的端口號，來決定哪些流量須要作負載均衡，對須要處理的流量進行NAT處理，轉發至後臺服務器，並記錄下這個TCP或者UDP的流量是由哪臺服務器處理的，後續這個鏈接的全部流量都一樣轉發到同一臺服務器處理。七層的負載均衡，就是在四層的基礎上（沒有四層是絕對不可能有七層的），再考慮應用層的特徵，好比同一個Web服務器的負載均衡，除了根據VIP加80端口辨別是否須要處理的流量，還可根據七層的URL、瀏覽器類別、語言來決定是否要進行負載均衡。舉個例子，若是你的Web服務器分紅兩組，一組是中文語言的，一組是英文語言的，那麼七層負載均衡就能夠當用戶來訪問你的域名時，自動辨別用戶語言，而後選擇對應的語言服務器組進行負載均衡處理。

8.應用

　　負載均衡對通信鏈路的冗餘是很是有用的。如一家公司可能有多條互聯網接入線路以保證某一條故障時仍能夠正常接入互聯網。故障轉移的架構意味着一條鏈接正常使用，另一條鏈接做爲備用，當第一條出現故障時纔會被啓用。使用負載均衡器，兩條鏈接能夠都投入使用。有一個設備或者程序實時監控着全部鏈接的連通性，而且對正在發送的包進行選路。同時使用多條鏈接能夠增長帶寬。許多電信公司在其內部網絡或鏈接到外部網絡都有多條線路可使用。爲避免某條鏈路出現網絡堵塞，最小化鏈接其它網絡的費用或者提升網絡的可靠性，它們使用負載均衡將流量從一條鏈路轉移到另外一條鏈路。負載均衡的另外一個用途是監控網絡活動。負載均衡器能用於將巨大的網絡流量分割爲幾個子流並使用網絡分析器，每一個都讀取原始數據的一部分。這對於監視10GbE高速網絡很是有用，在這些網絡上因爲數據量太大進行復雜的數據處理幾乎是不可能的。負載均衡常常被用於實現故障轉移，當一個或多個組件出現故障時能持續提供服務。這些組件都在持續監控中，當一個組件沒有響應，負載均衡器就會發現並再也不向其發送數據。一樣當一個組件從新上線，負載均衡器會從新開始向其發送數據。爲了可以如前所述正常工做，負載均衡體系中至少要有一個冗餘服務。採用一用一備方案（一個組件提供服務，一個備用，當主組件故障時備用組件將接管繼續提供服務）比故障轉移方案更加經濟，靈活。

9.健康檢查

　　負載均衡設備必須檢測後臺服務器是否在正常工做，若是發現某一臺服務器出現了故障，則須要把這臺服務器從負載均衡組裏面摘掉。當故障服務器恢復服務的時候，再把服務器從新加入到負載均衡組裏面進行處理。

10.待解決的問題

　　負載均衡策略的優劣及其實現的難易程度有兩個關鍵因素：1、負載均衡算法，2、對網絡系統情況的檢測方式和能力。 考慮到服務請求的不一樣類型、服務器的不一樣處理能力以及隨機選擇形成的負載分配不均勻等問題，爲了更加合理的把負載分配給內部的多個服務器，就須要應用相應的可以正確反映各個服務器處理能力及網絡狀態的負載均衡算法：

　　輪循均衡（Round Robin）：每一次來自網絡的請求輪流分配給內部中的服務器，從1至N而後從新開始。此種均衡算法適合於服務器組中的全部服務器都有相同的軟硬件配置而且平均服務請求相對均衡的狀況。

　　權重輪循均衡（Weighted Round Robin）：根據服務器的不一樣處理能力，給每一個服務器分配不一樣的權值，使其可以接受相應權值數的服務請求。例如：服務器A的權值被設計成1，B的權值是 3，C的權值是6，則服務器A、B、C將分別接受到10%、30％、60％的服務請求。此種均衡算法能確保高性能的服務器獲得更多的使用率，避免低性能的 服務器負載太重。

　　響應速度均衡（Response Time）：負載均衡設備對內部各服務器發出一個探測請求（例如Ping），而後根據內部中各服務器對探測請求的最快響應時間來決定哪一臺服務器來響應客戶端的服務請求。此種均衡算法能較好的反映服務器的當前運行狀態，但這最快響應時間僅僅指的是負載均衡設備與服務器間的最快響應時間，而不是客戶端與服務器間的最快響應時間。

　　最少鏈接數均衡（Least Connection）：客戶端的每一次請求服務在服務器停留的時間可能會有較大的差別，隨着工做時間加長，若是採用簡單的輪循或隨機均衡算法，每一臺服務器上的鏈接進程可能會產生極大的不一樣，並無達到真正的負載均衡。最少鏈接數均衡算法對內部中需負載的每一臺服務器都有一個數據記錄，記錄當前該服務器正在處理的鏈接數量，當有新的服務鏈接請求時，將把當前請求分配給鏈接數最少的服務器，使均衡更加符合實際狀況，負載更加均衡。此種均衡算法適合長時處理的請求服務，如FTP。 

　　處理能力均衡：此種均衡算法將把服務請求分配給內部中處理負荷（根據服務器CPU型號、CPU數量、內存大小及當前鏈接數等換算而成）最輕的服 務器，因爲考慮到了內部服務器的處理能力及當前網絡運行情況，因此此種均衡算法相對來講更加精確，尤爲適合運用到第七層（應用層）負載均衡的狀況下。

　　DNS響應均衡（Flash DNS）：在Internet上，不管是HTTP、FTP或是其它的服務請求，客戶端通常都是經過域名解析來找到服務器確切的IP地址的。在此均衡算法下，分處在不一樣地理位置的負載均衡設備收到同一個客戶端的域名解析請求，並在同一時間內把此域名解析成各自相對應服務器的IP地址（即與此負載均衡設備在同一位地理位置的服務器的IP地址）並返回給客戶端，則客戶端將以最早收到的域名解析IP地址來繼續請求服務，而忽略其它的IP地址響應。在種均衡策略適合應用在全局負載均衡的狀況下，對本地負載均衡是沒有意義的。

儘管有多種的負載均衡算法能夠較好的把數據流量分配給服務器去負載，但若是負載均衡策略沒有對網絡系統情況的檢測方式和能力，一旦在某臺服務器或某段負載均衡設備與服務器網絡間出現故障的狀況下，負載均衡設備依然把一部分數據流量引向那臺服務器，這勢必形成大量的服務請求被丟失，達不到不間斷可用性的要求。因此良好的負載均衡策略應有對網絡故障、服務器系統故障、應用服務故障的檢測方式和能力：

　　Ping偵測：經過ping的方式檢測服務器及網絡系統情況，此種方式簡單快速，但只能大體檢測出網絡及服務器上的操做系統是否正常，對服務器上的應用服務檢測就無能爲力了。

　　TCP Open偵測：每一個服務都會開放某個經過TCP鏈接，檢測服務器上某個TCP端口（如Telnet的23口，HTTP的80口等）是否開放來判斷服務是否正常。

　　HTTP URL偵測：好比向HTTP服務器發出一個對main.html文件的訪問請求，若是收到錯誤信息，則認爲服務器出現故障。