大型網站架構系列：負載均衡詳解（4）

本文是負載均衡詳解的第四篇，主要介紹了LVS的三種請求轉發模式和八種負載均衡算法，以及Haproxy的特色和負載均衡算法。具體參考文章，詳見最後的連接。

 

3、LVS負載均衡

LVS是一個開源的軟件，由畢業於國防科技大學的章文嵩博士於1998年5月創立，用來實現Linux平臺下的簡單負載均衡。LVS是Linux Virtual Server的縮寫，意思是Linux虛擬服務器。

基於IP層的負載均衡調度技術，它在操做系統核心層上，未來自IP層的TCP/UDP請求均衡地轉移到不一樣的 服務器，從而將一組服務器構成一個高性能、高可用的虛擬服務器。

 

操做系統：Liunx

開發語言：C

併發性能：默認4096，能夠修改但須要從新編譯。

3.1.功能

LVS的主要功能是實現IP層（網絡層）負載均衡，有NAT,TUN,DR三種請求轉發模式。

3.1.1LVS/NAT方式的負載均衡集羣

NAT是指Network Address Translation，它的轉發流程是：Director機器收到外界請求，改寫數據包的目標地址，按相應的調度算法將其發送到相應Real Server上，Real Server處理完該請求後，將結果數據包返回到其默認網關，即Director機器上，Director機器再改寫數據包的源地址，最後將其返回給外界。這樣就完成一次負載調度。

 

構架一個最簡單的LVS/NAT方式的負載均衡集羣Real Server能夠是任何的操做系統，並且無需作任何特殊的設定，唯一要作的就是將其默認網關指向Director機器。Real Server可使用局域網的內部IP(192.168.0.0/24)。Director要有兩塊網卡，一塊網卡綁定一個外部IP地址 (10.0.0.1)，另外一塊網卡綁定局域網的內部IP(192.168.0.254)，做爲Real Server的默認網關。

LVS/NAT方式實現起來最爲簡單，並且Real Server使用的是內部IP，能夠節省Real IP的開銷。但由於執行NAT須要重寫流經Director的數據包，在速度上有必定延遲；

當用戶的請求很是短，而服務器的迴應很是大的狀況下，會對Director造成很大壓力，成爲新的瓶頸，從而使整個系統的性能受到限制。

3.1.2LVS/TUN方式的負載均衡集羣

TUN是指IP Tunneling，它的轉發流程是：Director機器收到外界請求，按相應的調度算法,經過IP隧道發送到相應Real Server，Real Server處理完該請求後，將結果數據包直接返回給客戶。至此完成一次負載調度。

 

最簡單的LVS/TUN方式的負載均衡集羣架構使用IP Tunneling技術，在Director機器和Real Server機器之間架設一個IP Tunnel，經過IP Tunnel將負載分配到Real Server機器上。Director和Real Server之間的關係比較鬆散，能夠是在同一個網絡中，也能夠是在不一樣的網絡中，只要二者可以經過IP Tunnel相連就行。收到負載分配的Real Server機器處理完後會直接將反饋數據送回給客戶，而沒必要經過Director機器。實際應用中，服務器必須擁有正式的IP地址用於與客戶機直接通訊，而且全部服務器必須支持IP隧道協議。

 

該方式中Director將客戶請求分配到不一樣的Real Server，Real Server處理請求後直接回應給用戶，這樣Director就只處理客戶機與服務器的一半鏈接，極大地提升了Director的調度處理能力，使集羣系統能容納更多的節點數。另外TUN方式中的Real Server能夠在任何LAN或WAN上運行，這樣能夠構築跨地域的集羣，其應對災難的能力也更強，可是服務器須要爲IP封裝付出必定的資源開銷，並且後端的Real Server必須是支持IP Tunneling的操做系統。

3.3.3LVS/TUN方式的負載均衡集羣

DR是指Direct Routing，它的轉發流程是：Director機器收到外界請求，按相應的調度算法將其直接發送到相應Real Server，Real Server處理完該請求後，將結果數據包直接返回給客戶，完成一次負載調度。

 

構架一個最簡單的LVS/DR方式的負載均衡集羣Real Server和Director都在同一個物理網段中，Director的網卡IP是192.168.0.253，再綁定另外一個IP： 192.168.0.254做爲對外界的virtual IP，外界客戶經過該IP來訪問整個集羣系統。Real Server在lo上綁定IP：192.168.0.254，同時加入相應的路由。

 

LVS/DR方式與前面的LVS/TUN方式有些相似，前臺的Director機器也是隻須要接收和調度外界的請求，而不須要負責返回這些請求的反饋結果，因此可以負載更多的Real Server，提升Director的調度處理能力，使集羣系統容納更多的Real Server。但LVS/DR須要改寫請求報文的MAC地址，因此全部服務器必須在同一物理網段內。

3.3架構

LVS架設的服務器集羣系統有三個部分組成：最前端的負載均衡層（Loader Balancer），中間的服務器羣組層，用Server Array表示，最底層的數據共享存儲層，用Shared Storage表示。在用戶看來全部的應用都是透明的，用戶只是在使用一個虛擬服務器提供的高性能服務。

LVS的體系架構如圖：

 

LVS的各個層次的詳細介紹：

Load Balancer層：位於整個集羣系統的最前端，有一臺或者多臺負載調度器（Director Server）組成，LVS模塊就安裝在Director Server上，而Director的主要做用相似於一個路由器，它含有完成LVS功能所設定的路由表，經過這些路由表把用戶的請求分發給Server Array層的應用服務器（Real Server）上。同時，在Director Server上還要安裝對Real Server服務的監控模塊Ldirectord，此模塊用於監測各個Real Server服務的健康情況。在Real Server不可用時把它從LVS路由表中剔除，恢復時從新加入。

Server Array層：由一組實際運行應用服務的機器組成，Real Server能夠是WEB服務器、MAIL服務器、FTP服務器、DNS服務器、視頻服務器中的一個或者多個，每一個Real Server之間經過高速的LAN或分佈在各地的WAN相鏈接。在實際的應用中，Director Server也能夠同時兼任Real Server的角色。

Shared Storage層：是爲全部Real Server提供共享存儲空間和內容一致性的存儲區域，在物理上，通常有磁盤陣列設備組成，爲了提供內容的一致性，通常能夠經過NFS網絡文件系統共享數 據，可是NFS在繁忙的業務系統中，性能並非很好，此時能夠採用集羣文件系統，例如Red hat的GFS文件系統，oracle提供的OCFS2文件系統等。

從整個LVS結構能夠看出，Director Server是整個LVS的核心，目前，用於Director Server的操做系統只能是Linux和FreeBSD，linux2.6內核不用任何設置就能夠支持LVS功能，而FreeBSD做爲 Director Server的應用還不是不少，性能也不是很好。對於Real Server，幾乎能夠是全部的系統平臺，Linux、windows、Solaris、AIX、BSD系列都能很好的支持。

3.4均衡策略

LVS默認支持八種負載均衡策略，簡述以下：

3.4.1.輪詢調度（Round Robin）

調度器經過「輪詢」調度算法將外部請求按順序輪流分配到集羣中的真實服務器上，它均等地對待每一臺服務器，而無論服務器上實際的鏈接數和系統負載。

3.4.2.加權輪詢（Weighted Round Robin）

調度器經過「加權輪詢」調度算法根據真實服務器的不一樣處理能力來調度訪問請求。這樣能夠保證處理能力強的服務器能處理更多的訪問流量。調度器能夠自動問詢真實服務器的負載狀況，並動態地調整其權值。

3.4.3.最少連接（Least Connections）

調度器經過「最少鏈接」調度算法動態地將網絡請求調度到已創建的連接數最少的服務器上。若是集羣系統的真實服務器具備相近的系統性能，採用「最小鏈接」調度算法能夠較好地均衡負載。

3.4.4.加權最少連接（Weighted Least Connections）

在集羣系統中的服務器性能差別較大的狀況下，調度器採用「加權最少連接」調度算法優化負載均衡性能，具備較高權值的服務器將承受較大比例的活動鏈接負載。調度器能夠自動問詢真實服務器的負載狀況，並動態地調整其權值。

3.4.5.基於局部性的最少連接（Locality-Based Least Connections）

「基於局部性的最少連接」調度算法是針對目標IP地址的負載均衡，目前主要用於Cache集羣系統。該算法根據請求的目標IP地址找出該目標IP地址最近使用的服務器，若該服務器是可用的且沒有超載，將請求發送到該服務器；若服務器不存在，或者該服務器超載且有服務器處於一半的工做負載，則用「最少連接」 的原則選出一個可用的服務器，將請求發送到該服務器。

3.4.6.帶複製的基於局部性最少連接（Locality-Based Least Connections with Replication）

「帶複製的基於局部性最少連接」調度算法也是針對目標IP地址的負載均衡，目前主要用於Cache集羣系統。它與LBLC算法的不一樣之處是它要維護從一個目標IP地址到一組服務器的映射，而LBLC算法維護從一個目標IP地址到一臺服務器的映射。該算法根據請求的目標IP地址找出該目標IP地址對應的服務器組，按「最小鏈接」原則從服務器組中選出一臺服務器，若服務器沒有超載，將請求發送到該服務器；若服務器超載，則按「最小鏈接」原則從這個集羣中選出一臺服務器，將該服務器加入到服務器組中，將請求發送到該服務器。同時，當該服務器組有一段時間沒有被修改，將最忙的服務器從服務器組中刪除，以下降複製的程度。

3.4.7.目標地址散列（Destination Hashing）

「目標地址散列」調度算法根據請求的目標IP地址，做爲散列鍵（Hash Key）從靜態分配的散列表找出對應的服務器，若該服務器是可用的且未超載，將請求發送到該服務器，不然返回空。

3.4.8.源地址散列（Source Hashing）

「源地址散列」調度算法根據請求的源IP地址，做爲散列鍵（Hash Key）從靜態分配的散列表找出對應的服務器，若該服務器是可用的且未超載，將請求發送到該服務器，不然返回空。

 

除具有以上負載均衡算法外，還能夠自定義均衡策略。

3.5場景

通常做爲入口負載均衡或內部負載均衡，結合反向代理服務器使用。相關架構可參考Ngnix場景架構。

四、HaProxy負載均衡

HAProxy也是使用較多的一款負載均衡軟件。HAProxy提供高可用性、負載均衡以及基於TCP和HTTP應用的代理，支持虛擬主機，是免費、快速而且可靠的一種解決方案。特別適用於那些負載特大的web站點。運行模式使得它能夠很簡單安全的整合到當前的架構中，同時能夠保護你的web服務器不被暴露到網絡上。

4.1.特色

• 支持兩種代理模式：TCP（四層）和HTTP（七層），支持虛擬主機；
• 配置簡單，支持url檢測後端服務器狀態；
• 作負載均衡軟件使用，在高併發狀況下，處理速度高於nginx；
• TCP層多用於Mysql從（讀）服務器負載均衡。 （對Mysql進行負載均衡，對後端的DB節點進行檢測和負載均衡）
• 可以補充Nginx的一些缺點好比Session的保持，Cookie引導等工做

4.2.均衡策略

支持四種經常使用算法：

1.roundrobin：輪詢，輪流分配到後端服務器；

2.static-rr：根據後端服務器性能分配；

3.leastconn：最小鏈接者優先處理；

4.source：根據請求源IP，與Nginx的IP_Hash相似。

5、本次分享總結

以上是本週的分享，從主要講解了軟件負載均衡的應用背景，Ngnix負載均衡，LVS負載均衡，Haproxy負載均衡。

由於時間關係，有些講解的不細緻，你們能夠問下度娘/Google，但願本次分享對你們有幫助。

 

參考資料：

Nginx負載均衡實現原理圖解 http://www.server110.com/nginx/201403/7225.html

Nginx架構及其web服務搭建優化配置詳解

http://linux.it.net.cn/e/server/nginx/2015/0102/11183.html

Ngnix雙主場景：http://network.51cto.com/art/201109/288597.htm

用LVS構架負載均衡Linux集羣系統 linux lvs

http://blog.chinaunix.net/uid-45094-id-3012037.html

LVS基本介紹

http://os.51cto.com/art/201202/317108.htm

 

下次分享時間：下下週12月9日 晚7點30~~8點30見。《大型網站架構系列：分佈式消息隊列技術》