伺服器負載均衡的基本功能和實作原理

負載均衡裝置作為縱跨網絡2-7層協定的裝置，往往放置在網絡裝置和應用裝置的連接配接處，對工程師在網絡和應用基本知識方面的要求遠高于其他裝置，是以我們要在基本功能的了解上下更多的功夫。負載均衡裝置還有另外一個稱呼：4/7層交換機，但它首先是個2-3層交換機，這要求我們首先掌握2-3層的基本知識，然後才是本文介紹的内容。

伺服器負載均衡有三大基本Feature：負載均衡算法，健康檢查和會話保持，這三個Feature是保證負載均衡正常工作的基本要素。其他一些功能都是在這三個功能之上的一些深化。下面我們具體介紹一下各個功能的作用和原理。

在沒有部署負載均衡裝置之前，使用者直接通路伺服器位址（中間或許有在防火牆上将伺服器位址映射成别的位址，但本質上還是一對一的通路）。當單台伺服器由于性能不足無法處理衆多使用者的通路時，就要考慮用多台伺服器來提供服務，實作的方式就是負載均衡。負載均衡裝置的實作原理是把多台伺服器的位址映射成一個對外的服務IP（我們通常稱之為VIP，關于伺服器的映射可以直接将伺服器IP映射成VIP位址，也可以将伺服器IP:Port映射成VIP:Port，不同的映射方式會采取相應的健康檢查,在端口映射時，伺服器端口與VIP端口可以不相同）,這個過程對使用者端是透明的，使用者實際上不知道伺服器是做了負載均衡的，因為他們通路的還是一個目的IP,那麼使用者的通路到達負載均衡裝置後，如何把使用者的通路分發到合适的伺服器就是負載均衡裝置要做的工作了，具體來說用到的就是上述的三大Feature。

我們來做一個詳細的通路流程分析:

<a target="_blank" href="http://blog.51cto.com/attachment/201107/181416330.png"></a>

<a target="_blank" href="http://blog.51cto.com/attachment/201107/181501837.png"></a>

負載均衡裝置在将資料包發給伺服器時，資料包是做了一些變化的，如上圖所示，資料包到達負載均衡裝置之前，源位址是：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，然後轉發給使用者，保證了通路的一緻性。

<a target="_blank" href="http://blog.51cto.com/attachment/201107/181543509.png"></a>

以上是單個資料包的處理流程。那麼負載均衡裝置是怎麼選擇伺服器的呢？ 這就是我們要介紹的第一個Feature:

<b>負載均衡算法</b>

<b></b>

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

Ø  輪詢（RoundRobin）将請求順序循環地發到每個伺服器。當其中某個伺服器發生故障，AX就把其從順序循環隊列中拿出，不參加下一次的輪詢，直到其恢複正常。

Ø  比率（Ratio）：給每個伺服器配置設定一個權重值為比例，根椐這個比例，把使用者的請求配置設定到每個伺服器。當其中某個伺服器發生故障，AX就把其從伺服器隊列中拿出，不參加下一次的使用者請求的配置設定，直到其恢複正常。

Ø  優先權（Priority）：給所有伺服器分組，給每個組定義優先權，将使用者的請求配置設定給優先級最高的伺服器組（在同一組内，采用預先設定的輪詢或比率算法，配置設定使用者的請求）；當最高優先級中所有伺服器或者指定數量的伺服器出現故障，AX将把請求送給次優先級的伺服器組。這種方式，實際為使用者提供一種熱備份的方式。

Ø  最少連接配接數（LeastConnection）：AX會記錄目前每台伺服器或者服務端口上的連接配接數，新的連接配接将傳遞給連接配接數最少的伺服器。當其中某個伺服器發生故障，AX就把其從伺服器隊列中拿出，不參加下一次的使用者請求的配置設定，直到其恢複正常。

Ø  最快響應時間（Fast Reponse time）：新的連接配接傳遞給那些響應最快的伺服器。當其中某個伺服器發生故障，AX就把其從伺服器隊列中拿出，不參加下一次的使用者請求的配置設定，直到其恢複正常。

以上為通用的負載均衡算法，還有一些算法根據不同的需求也可能會用到，例如：

Ø  雜湊演算法( hash):  将用戶端的源位址，端口進行哈希運算，根據運算的結果轉發給一台伺服器進行處理，當其中某個伺服器發生故障，就把其從伺服器隊列中拿出，不參加下一次的使用者請求的配置設定，直到其恢複正常。

Ø  基于政策的負載均衡：針對不同的資料流設定導向規則，使用者可自行編輯流量配置設定政策，利用這些政策對通過的資料流實施導向控制。

Ø  基于資料包的内容分發：例如判斷HTTP的URL，如果URL中帶有.jpg的擴充名，就把資料包轉發到指定的伺服器。

<a target="_blank" href="http://blog.51cto.com/attachment/201107/181700753.png"></a>

<a target="_blank" href="http://blog.51cto.com/attachment/201107/182329890.png"></a>

假設在工作過程中，突然有一台伺服器出現問題怎麼辦？ 這就涉及到我們要介紹的第二個Feature:

<b>健康檢查</b>

健康檢查用于檢查伺服器開放的各種服務的可用狀态。負載均衡裝置一般會配置各種健康檢查方法，例如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。健康檢查的間隔時間和嘗試次數要根據綜合情況來設定，原則是既不會對業務産生影響，又不會對負載均衡裝置造成較大負擔。

<a target="_blank" href="http://blog.51cto.com/attachment/201107/181758934.png"></a>

<a target="_blank" href="http://blog.51cto.com/attachment/201107/181958387.png"></a>

假設是同一個使用者繼續通路，後續的連接配接會怎麼處理呢？ 看下圖：

<a target="_blank" href="http://blog.51cto.com/attachment/201107/093104353.png"></a>

<a target="_blank" href="http://blog.51cto.com/attachment/201107/093143173.png"></a>

使用者207.17.117.25之前發起的第一個連接配接是207.17.117.25：4003-〉199.237.202.127:80，負載均衡裝置将該連接配接轉發到了172.16.20.4，接着發起第二個連接配接207.17.117.25：4004-〉199.237.202.127:80，我們看到該連接配接還是轉發到了伺服器172.16.20.4，為什麼呢？因為負載均衡裝置配置了會話保持。

<b>會話保持</b>

會話保持用于保持會話的連續性和一緻性，由于伺服器之間很難做到實時同步使用者通路資訊，這就要求把使用者的前後通路會話保持到一台伺服器上來處理。舉個例子，使用者通路一個電子商務網站，如果使用者登入時是由第一台伺服器來處理的，但使用者購買商品的動作卻由第二台伺服器來處理，第二台伺服器由于不知道使用者資訊，是以本次購買就不會成功。這種情況就需要會話保持，把使用者的操作都通過第一台伺服器來處理才能成功。當然并不是所有的通路都需要會話保持，例如伺服器提供的是靜态頁面比如網站的新聞頻道，各台伺服器都有相同的内容，這種通路就不需要會話保持。

本文介紹了負載均衡的基本功能和實作原理，看起來并不難，但負載均衡涉及的知識其實非常的廣泛，根據各個使用者系統的不同，我們要熟悉不同的協定和應用流程，甚至涉及到某些開發語言和軟體平台，否則在出現故障的時候，我們可能沒有能力做出有效的判斷，從這個意義上來說，一個負載均衡裝置的工程師要掌握網絡，應用和系統等各方面的知識，這些都要當作基礎來積累。

（wyl）.

本文轉自 virtualadc 51CTO部落格，原文連結:http://blog.51cto.com/virtualadc/615836