叢集

叢集的概念

　　計算機叢集通過一組鬆散整合的計算機軟體和/或硬體連線起來高度緊密地協作完成計算工作。在某種意義上，他們可以被看作是一臺計算機。集群系統中的單個計算機通常稱為節點，通常通過區域網連線，但也有其它的可能連線方式。叢集計算機通常用來改進單個計算機的計算速度和/或可靠性。一般情況下叢集計算機比單個計算機，比如工作站或超級計算機效能價格比要高得多。 　　比如單個重負載的運算分擔到多臺節點裝置上做並行處理，每個節點裝置處理結束後，將結果彙總，返回給使用者，系統處理能力得到大幅度提高。一般分為幾種：

• 高可用性叢集：一般是指當叢集中有某個節點失效的情況下，其上的任務會自動轉移到其他正常的節點上。還指可以將叢集中的某節點進行離線維護再上線，該過程並不影響整個叢集的執行。
• 負載均衡叢集：負載均衡叢集執行時，一般通過一個或者多個前端負載均衡器，將工作負載分發到後端的一組伺服器上，從而達到整個系統的高效能和高可用性。
• 高效能運算叢集：高效能運算叢集採用將計算任務分配到叢集的不同計算節點而提高計算能力，因而主要應用在科學計算領域。

分散式

　　叢集：同一個業務，部署在多個伺服器上。分散式：一個業務分拆成多個子業務，或者本身就是不同的業務，部署在不同的伺服器上。 　　簡單說，分散式是以縮短單個任務的執行時間來提升效率的，而叢集則是通過提高單位時間內執行的任務數來提升效率。舉例：就比如新浪網，訪問的人多了，他可以做一個群集，前面放一個均衡伺服器，後面幾臺伺服器完成同一業務，如果有業務訪問的時候，響應伺服器看哪臺伺服器的負載不是很重，就將給哪一臺去完成，並且一臺伺服器垮了，其它的伺服器可以頂上來。分散式的每一個節點，都完成不同的業務，一個節點垮了，那這個業務可能就失敗了。

負載均衡

概念

　　隨著業務量的提高，現有網路的各個核心部分訪問量和資料流量的快速增長，其處理能力和計算強度也相應地增大，使得單一的伺服器裝置根本無法承擔。在此情況下，如果扔掉現有裝置去做大量的硬體升級，這樣將造成現有資源的浪費，而且如果再面臨下一次業務量的提升時，這又將導致再一次硬體升級的高額成本投入，甚至效能再卓越的裝置也不能滿足當前業務量增長的需求。 　　負載均衡技術通過設定虛擬伺服器IP（VIP），將後端多臺真實伺服器的應用資源虛擬成一臺高效能的應用伺服器，通過負載均衡演算法，將使用者的請求轉發給後臺內網伺服器，內網伺服器將請求的響應返回給負載平衡器，負載平衡器再將響應傳送到使用者，這樣就向網際網路使用者隱藏了內網結構，阻止了使用者直接訪問後臺（內網）伺服器，使得伺服器更加安全，可以阻止對核心網路棧和執行在其它埠服務的攻擊。並且負載均衡裝置（軟體或硬體）會持續的對伺服器上的應用狀態進行檢查，並自動對無效的應用伺服器進行隔離，實現了一個簡單、擴充套件性強、可靠性高的應用解決方案，解決了單臺伺服器處理效能不足，擴充套件性不夠，可靠性較低的問題。 　　系統的擴充套件可分為縱向（垂直）擴充套件和橫向（水平）擴充套件。縱向擴充套件，是從單機的角度通過增加硬體處理能力，比如CPU處理能力，記憶體容量，磁碟等方面，實現伺服器處理能力的提升，不能滿足大型分散式系統（網站），大流量，高併發，海量資料的問題。因此需要採用橫向擴充套件的方式，通過新增機器來滿足大型網站服務的處理能力。比如：一臺機器不能滿足，則增加兩臺或者多臺機器，共同承擔訪問壓力。

　　負載平衡最重要的一個應用是利用多臺伺服器提供單一服務，這種方案有時也稱之為伺服器農場。通常，負載平衡主要應用於Web網站，大型的Internet Relay Chat網路，高流量的檔案下載網站，NNTP（Network News Transfer Protocol）服務和DNS服務。現在負載平衡器也開始支援資料庫服務，稱之為資料庫負載平衡器。 　　伺服器負載均衡有三大基本Feature：負載均衡演算法，健康檢查和會話保持，這三個Feature是保證負載均衡正常工作的基本要素。其他一些功能都是在這三個功能之上的一些深化。下面我們具體介紹一下各個功能的作用和原理。 　　在沒有部署負載均衡裝置之前，使用者直接訪問伺服器地址（中間或許有在防火牆上將伺服器地址對映成別的地址，但本質上還是一對一的訪問）。當單臺伺服器由於效能不足無法處理眾多使用者的訪問時，就要考慮用多臺伺服器來提供服務，實現的方式就是負載均衡。負載均衡裝置的實現原理是把多臺伺服器的地址對映成一個對外的服務IP（我們通常稱之為VIP，關於伺服器的對映可以直接將伺服器IP對映成VIP地址，也可以將伺服器IP:Port對映成VIP:Port，不同的對映方式會採取相應的健康檢查，在埠對映時，伺服器埠與VIP埠可以不相同）,這個過程對使用者端是不可見的，使用者實際上不知道伺服器是做了負載均衡的，因為他們訪問的還是一個目的IP，那麼使用者的訪問到達負載均衡裝置後，如何把使用者的訪問分發到合適的伺服器就是負載均衡裝置要做的工作了，具體來說用到的就是上述的三大Feature。 我們來做一個詳細的訪問流程分析:

　　使用者(IP:207.17.117.20)訪問域名www.a10networks.com，首先會通過DNS查詢解析出這個域名的公網地址：199.237.202.124，接下來使用者207.17.117.20會訪問199.237.202.124這個地址，因此資料包會到達負載均衡裝置，接下來負載均衡裝置會把資料包分發到合適的伺服器，看下圖：

　　負載均衡裝置在將資料包發給伺服器時，資料包是做了一些變化的，如上圖所示，資料包到達負載均衡裝置之前，源地址是：207.17.117.20，目的地址是：199.237.202.124，當負載均衡裝置將資料包轉發給選中的伺服器時，源地址還是：207.17.117.20，目的地址變為172.16.20.1，我們稱這種方式為目的地址NAT(DNAT，目的地址轉換)。一般來說，在伺服器負載均衡中DNAT是一定要做的（還有另一種模式叫做伺服器直接返回-DSR，是不做DNAT的，我們將另行討論），而源地址根據部署模式的不同，有時候也需要轉換成別的地址，我們稱之為：源地址NAT(SNAT)，一般來說，旁路模式需要做SNAT，而串接模式不需要，本示意圖為串接模式，所以源地址沒做NAT。 　　我們再看伺服器的返回包，如下圖所示，也經過了IP地址的轉換過程，不過應答包中源/目的地址與請求包正好對調，從伺服器回來的包源地址為172.16.20.1，目的地址為207.17.117.20，到達負載均衡裝置後，負載均衡裝置將源地址改為199.237.202.124，然後轉發給使用者，保證了訪問的一致性。

負載均衡演算法

　　一般來說負載均衡裝置都會預設支援多種負載均衡分發策略，例如：

• 輪詢（RoundRobin）將請求順序迴圈地發到每個伺服器。當其中某個伺服器發生故障，AX就把其從順序迴圈佇列中拿出，不參加下一次的輪詢，直到其恢復正常。
• 比率（Ratio）：給每個伺服器分配一個加權值為比例，根椐這個比例，把使用者的請求分配到每個伺服器。當其中某個伺服器發生故障，AX就把其從伺服器佇列中拿出，不參加下一次的使用者請求的分配，直到其恢復正常。
• 優先權（Priority）：給所有伺服器分組，給每個組定義優先權，將使用者的請求分配給優先順序最高的伺服器組（在同一組內，採用預先設定的輪詢或比率演算法，分配使用者的請求）；當最高優先順序中所有伺服器或者指定數量的伺服器出現故障，AX將把請求送給次優先順序的伺服器組。這種方式，實際為使用者提供一種熱備份的方式。
• 最少連線數（LeastConnection）：AX會記錄當前每臺伺服器或者服務埠上的連線數，新的連線將傳遞給連線數最少的伺服器。當其中某個伺服器發生故障，AX就把其從伺服器佇列中拿出，不參加下一次的使用者請求的分配，直到其恢復正常。
• 最快響應時間（Fast Reponse time）：新的連線傳遞給那些響應最快的伺服器。當其中某個伺服器發生故障，AX就把其從伺服器佇列中拿出，不參加下一次的使用者請求的分配，直到其恢復正常。
• 雜湊演算法( hash): 將客戶端的源地址，埠進行雜湊運算，根據運算的結果轉發給一臺伺服器進行處理，當其中某個伺服器發生故障，就把其從伺服器佇列中拿出，不參加下一次的使用者請求的分配，直到其恢復正常。
• 基於資料包的內容分發：例如判斷HTTP的URL，如果URL中帶有.jpg的副檔名，就把資料包轉發到指定的伺服器。

健康檢查

　　健康檢查用於檢查伺服器開放的各種服務的可用狀態。負載均衡裝置一般會配置各種健康檢查方法，例如Ping，TCP，UDP，HTTP，FTP，DNS等。Ping屬於第三層的健康檢查，用於檢查伺服器IP的連通性，而TCP/UDP屬於第四層的健康檢查，用於檢查服務埠的UP/DOWN，如果要檢查的更準確，就要用到基於7層的健康檢查，例如建立一個HTTP健康檢查，Get一個頁面回來，並且檢查頁面內容是否包含一個指定的字串，如果包含，則服務是UP的，如果不包含或者取不回頁面，就認為該伺服器的Web服務是不可用（DOWN）的。比如，負載均衡裝置檢查到172.16.20.3這臺伺服器的80埠是DOWN的，負載均衡裝置將不把後面的連線轉發到這臺伺服器，而是根據演算法將資料包轉發到別的伺服器。建立健康檢查時可以設定檢查的間隔時間和嘗試次數，例如設定間隔時間為5秒，嘗試次數為3，那麼負載均衡裝置每隔5秒發起一次健康檢查，如果檢查失敗，則嘗試3次，如果3次都檢查失敗，則把該服務標記為DOWN，然後伺服器仍然會每隔5秒對DOWN的伺服器進行檢查，當某個時刻發現該伺服器健康檢查又成功了，則把該伺服器重新標記為UP。健康檢查的間隔時間和嘗試次數要根據綜合情況來設定，原則是既不會對業務產生影響，又不會對負載均衡裝置造成較大負擔。

會話保持

　　如何保證一個使用者的兩次http請求轉發到同一個伺服器，這就要求負載均衡裝置配置會話保持。 　　會話保持用於保持會話的連續性和一致性，由於伺服器之間很難做到實時同步使用者訪問資訊，這就要求把使用者的前後訪問會話保持到一臺伺服器上來處理。舉個例子，使用者訪問一個電子商務網站，如果使用者登入時是由第一臺伺服器來處理的，但使用者購買商品的動作卻由第二臺伺服器來處理，第二臺伺服器由於不知道使用者資訊，所以本次購買就不會成功。這種情況就需要會話保持，把使用者的操作都通過第一臺伺服器來處理才能成功。當然並不是所有的訪問都需要會話保持，例如伺服器提供的是靜態頁面比如網站的新聞頻道，各臺伺服器都有相同的內容，這種訪問就不需要會話保持。 　　絕大多數的負載均衡產品都支援兩類基本的會話保持方式：源/目的地址會話保持和cookie會話保持，另外像hash，URL Persist等也是比較常用的方式，但不是所有裝置都支援。基於不同的應用要配置不同的會話保持，否則會引起負載的不均衡甚至訪問異常。我們主要分析B/S結構的會話保持。

基於B/S結構的應用：

　　對於普通B/S結構的應用內容，例如網站的靜態頁面，可以不用配置任何的會話保持，但是對於一個基於B/S結構尤其是中介軟體平臺的業務系統來說，必須配置會話保持，一般情況下，我們配置源地址會話保持可以滿足需求，但是考慮到客戶端可能有上述不利於源地址會話保持的環境，採用Cookie會話保持是一個更好的方式。Cookie會話保持會把負載均衡裝置選擇的Server資訊儲存在Cookie中傳送到客戶端，客戶端持續訪問時，會把該Cookie帶來，負載均衡器通過分析Cookie把會話保持到之前選定的伺服器。Cookie分為檔案Cookie和記憶體cookie，檔案cookie儲存在客戶端計算機硬碟上，只要該cookie檔案不過期，則無論是否重複關閉開放瀏覽器都能保持到同一臺伺服器。記憶體Cookie則是把Cookie資訊儲存在記憶體中，Cookie的生存時間從開啟瀏覽器訪問開始，關閉瀏覽器結束。由於現在的瀏覽器對Cookie都有一定預設的安全設定，有些客戶端可能規定不準使用檔案Cookie，所以現在的應用程式開發多使用記憶體Cookie。 　　然而，記憶體Cookie也不是萬能的，比如瀏覽器為了安全可能會完全禁用Cookie，這樣Cookie會話保持就失去了作用。我們可以通過Session-id來實現會話保持，即將session-id作為url引數或者放在隱藏欄位<input type="hidden">中，然後分析Session-id進行分發。 　　另一種方案是：將每一會話資訊儲存到一個數據庫中。由於這個方案會增加資料庫的負載，所以這個方案對效能的提高並不好。資料庫最好是用來儲存會話時間比較長的會話資料。為了避免資料庫出現單點故障，並且提高其擴充套件性，資料庫通常會複製到多臺伺服器上，通過負載均衡器來分發請求到資料庫伺服器上。 　　基於源/目的地址會話保持其實不太好用，因為客戶可能是通過DHCP，NAT或者Web代理來連線Internet的，其IP地址可能經常變換，這使得這個方案的服務質量無法保障。NAT(Network Address Translation，網路地址轉換):當在專用網內部的一些主機本來已經分配到了本地IP地址(即僅在本專用網內使用的專用地址)，但現在又想和因特網上的主機通訊(並不需要加密)時，可使用NAT方法。這種方法需要在專用網連線到因特網的路由器上安裝NAT軟體。裝有NAT軟體的路由器叫做NAT路由器，它至少有一個有效的外部全球IP地址。這樣，所有使用本地地址的主機在和外界通訊時，都要在NAT路由器上將其本地地址轉換成全球IP地址，才能和因特網連線。

負載均衡的其他好處

高擴充套件性

　　通過新增或減少伺服器數量，可以更好的應對高併發請求。

（伺服器）健康檢查

　　負載均衡器可以檢查後臺伺服器應用層的健康狀況並從伺服器池中移除那些出現故障的伺服器，提高可靠性。

TCP 連線複用（TCP Connection Reuse）

　　TCP連線複用技術通過將前端多個客戶的HTTP請求複用到後端與伺服器建立的一個TCP連線上。這種技術能夠大大減小伺服器的效能負載，減少與伺服器之間新建TCP連線所帶來的延時，並最大限度的降低客戶端對後端伺服器的併發連線數請求，減少伺服器的資源佔用。 　　一般情況下，客戶端在傳送HTTP請求之前需要先與伺服器進行TCP三次握手，建立TCP連線，然後傳送HTTP請求。伺服器收到HTTP請求後進行處理，並將處理的結果傳送回客戶端，然後客戶端和伺服器互相傳送FIN並在收到FIN的ACK確認後關閉連線。在這種方式下，一個簡單的HTTP請求需要十幾個TCP資料包才能處理完成。 　　採用TCP連線複用技術後，客戶端（如：ClientA）與負載均衡裝置之間進行三次握手併發送HTTP請求。負載均衡裝置收到請求後，會檢測伺服器是否存在空閒的長連線，如果不存在，伺服器將建立一個新連線。當HTTP請求響應完成後，客戶端則與負載均衡裝置協商關閉連線，而負載均衡則保持與伺服器之間的這個連線。當有其它客戶端（如：ClientB）需要傳送HTTP請求時，負載均衡裝置會直接向與伺服器之間保持的這個空閒連線傳送HTTP請求，避免了由於新建TCP連線造成的延時和伺服器資源耗費。

　　在HTTP 1.1中，客戶端可以在一個TCP連線中傳送多個HTTP請求，這種技術叫做HTTP複用（HTTP Multiplexing）。它與TCP連線複用最根本的區別在於，TCP連線複用是將多個客戶端的HTTP請求複用到一個伺服器端TCP連線上，而HTTP複用則是一個客戶端的多個HTTP請求通過一個TCP連線進行處理。前者是負載均衡裝置的獨特功能；而後者是HTTP 1.1協議所支援的新功能，目前被大多數瀏覽器所支援。

HTTP快取

　　負載均衡器可以儲存靜態內容，當用戶請求它們時可以直接響應使用者而不必再向後臺伺服器請求。

TCP緩衝

　　TCP緩衝是為了解決後端伺服器網速與客戶的前端網路速度不匹配而造成的伺服器資源浪費的問題。客戶端與負載均衡之間採用的鏈路具有較高的時延和較低的頻寬，而負載均衡與伺服器之間採用時延較低和高頻寬的區域網連線。由於負載均衡器可以暫存後臺伺服器對客戶的響應資料，再將它們轉發給那些響應時間較長網速較慢的客戶，如此後臺Web伺服器就可以釋放相應的執行緒去處理其它任務。

SSL加速

　　一般情況下，HTTP採用明文的方式在網路上傳輸，有可能被非法竊聽，尤其是用於認證的口令資訊等。為了避免出現這樣的安全問題，一般採用SSL協議（即：HTTPS）對HTTP協議進行加密，以保證整個傳輸過程的安全性。在SSL通訊中，首先採用非對稱金鑰技術交換認證資訊，並交換伺服器和瀏覽器之間用於加密資料的會話金鑰，然後利用該金鑰對通訊過程中的資訊進行加密和解密。 　　SSL是需要耗費大量CPU資源的一種安全技術。目前，大多數負載均衡裝置均採用SSL加速晶片（硬體負載均衡器）進行SSL資訊的處理。這種方式比傳統的採用伺服器的SSL加密方式提供更高的SSL處理效能，從而節省大量的伺服器資源，使伺服器能夠專注於業務請求的處理。另外，採用集中的SSL處理，還能夠簡化對證書的管理，減少日常管理的工作量。

內容過濾

　　有些負載均衡器可以按要求修改通過它的資料。

入侵阻止功能

　　在防火牆保障網路層/傳輸層安全的基礎上，提供應用層安全防範。

分類

　　下面從不同層次討論負載均衡的實現：

DNS 負載均衡

　　DNS負責提供域名解析服務，當訪問某個站點時，實際上首先需要通過該站點域名的DNS伺服器來獲取域名指向的IP地址，在這一過程中，DNS伺服器完成了域名到IP地址的對映，同樣，這樣對映也可以是一對多的，這時候，DNS伺服器便充當了負載均衡排程器，將使用者的請求分散到多臺伺服器上。使用dig命令來看下”baidu”的DNS設定：

　　可見baidu擁有三個A記錄。

　　這種技術的優點是，實現簡單、實施容易、成本低、適用於大多數TCP/IP應用，並且DNS伺服器可以在所有可用的A記錄中尋找離使用者最近的一臺伺服器。但是，其缺點也非常明顯，首先這種方案不是真正意義上的負載均衡，DNS伺服器將Http請求平均地分配到後臺的Web伺服器上（或者根據地理位置），而不考慮每個Web伺服器當前的負載情況；如果後臺的Web伺服器的配置和處理能力不同，最慢的Web伺服器將成為系統的瓶頸，處理能力強的伺服器不能充分發揮作用；其次未考慮容錯，如果後臺的某臺Web伺服器出現故障，DNS伺服器仍然會把DNS請求分配到這臺故障伺服器上，導致不能響應客戶端。最後一點是致命的，有可能造成相當一部分客戶不能享受Web服務，並且由於DNS快取的原因，所造成的後果要持續相當長一段時間(一般DNS的重新整理週期約為24小時)。所以在國外最新的建設中心Web站點方案中，已經很少採用這種方案了。

鏈路層（OSI 第二層）負載均衡

　　在通訊協議的資料鏈路層修改mac地址，進行負載均衡。 　　資料分發時，不修改ip地址（因為還看不到ip地址），只修改目標mac地址，並且配置所有後端伺服器虛擬ip和負載均衡器ip地址一致，達到不修改資料包的源地址和目標地址，進行資料分發的目的。 　　實際處理伺服器ip和資料請求目的ip一致，不需要經過負載均衡伺服器進行地址轉換，可將響應資料包直接返回給使用者瀏覽器，避免負載均衡伺服器網絡卡頻寬成為瓶頸。也稱為直接路由模式（DR模式）。如下圖：

效能很好，但是配置複雜，目前應用比較廣泛。

傳輸層（OSI 第四層）負載均衡

　　傳輸層是 OSI 第四層，包括 TCP 和 UDP。流行的傳輸層負載均衡器有 HAProxy（這個也用於應用層負載均衡）和 IPVS。 　　主要通過報文中的目標地址和埠，再加上負載均衡裝置設定的伺服器選擇方式，決定最終選擇的內部伺服器。 　　以常見的TCP為例，負載均衡裝置在接收到第一個來自客戶端的SYN 請求時，即通過上述方式選擇一個最佳的伺服器，並對報文中目標IP地址進行修改(改為後端伺服器IP），直接轉發給該伺服器。TCP的連線建立，即三次握手是客戶端和伺服器直接建立的，負載均衡裝置只是起到一個類似路由器的轉發動作。在某些部署情況下，為保證伺服器回包可以正確返回給負載均衡裝置，在轉發報文的同時可能還會對報文原來的源地址進行修改。

應用層（OSI 第七層）負載均衡

　　應用層是 OSI 第七層。它包括 HTTP、HTTPS 和 WebSockets。一款非常流行又久經考驗的應用層負載均衡器就是 Nginx[恩靜埃克斯 = Engine X]。 　　所謂七層負載均衡，也稱為“內容交換”，也就是主要通過報文中的真正有意義的應用層內容，再加上負載均衡裝置設定的伺服器選擇方式，決定最終選擇的內部伺服器。注意此時可以看到具體的http請求的完整url，因此可以實現下圖所示的分發：

　　以常見的TCP為例，負載均衡裝置如果要根據真正的應用層內容再選擇伺服器，只能先代理最終的伺服器和客戶端建立連線(三次握手)後，才能看到客戶端傳送的真正應用層內容的報文，然後再根據該報文中的特定欄位，再加上負載均衡裝置設定的伺服器選擇方式，決定最終選擇的內部伺服器。負載均衡裝置在這種情況下，更類似於一個代理伺服器。負載均衡和前端的客戶端以及後端的伺服器會分別建立TCP連線。所以從這個技術原理上來看，七層負載均衡明顯的對負載均衡裝置的要求更高，處理七層的能力也必然會低於四層模式的部署方式。那麼，為什麼還需要七層負載均衡呢？

　　七層負載均衡的好處，是使得整個網路更"智慧化"，比如上面列舉的負載均衡的好處，大部分都基於七層負載均衡。例如訪問一個網站的使用者流量，可以通過七層的方式，將對圖片類的請求轉發到特定的圖片伺服器並可以使用快取技術；將對文字類的請求可以轉發到特定的文字伺服器並可以使用壓縮技術。當然這只是七層應用的一個小案例，從技術原理上，這種方式可以對客戶端的請求和伺服器的響應進行任意意義上的修改，極大的提升了應用系統在網路層的靈活性。 　　另外一個常常被提到功能就是安全性。網路中最常見的SYN Flood攻擊，即黑客控制眾多源客戶端，使用虛假IP地址對同一目標傳送SYN攻擊，通常這種攻擊會大量傳送SYN報文，耗盡伺服器上的相關資源，以達到Denial of Service(DoS)的目的。從技術原理上也可以看出，四層模式下這些SYN攻擊都會被轉發到後端的伺服器上；而七層模式下這些SYN攻擊自然在負載均衡裝置上就截止，不會影響後臺伺服器的正常運營。另外負載均衡裝置可以在七層層面設定多種策略，過濾特定報文，例如SQL Injection等應用層面的特定攻擊手段，從應用層面進一步提高系統整體安全。 　　現在的七層負載均衡，主要還是著重於應用廣泛的HTTP協議，所以其應用範圍主要是眾多的網站或者內部資訊平臺等基於B/S開發的系統。 四層負載均衡則對應其他TCP應用，例如基於C/S開發的ERP等系統。