六大Web負載平衡原理與實現，六大web負載平衡

六大Web負載平衡原理與實現，六大web負載平衡

開頭先理解一下所謂的“均衡”

不能狹義地理解為分配給所有實際伺服器一樣多的工作量，因為多台伺服器的承載能力各不相同，這可能體現在硬體設定、網路頻寬的差異，也可能因為某台伺服器身兼多職，我們所說的“均衡”，也就是希望所有伺服器都不要過載，並且能夠最大程式地發揮作用。

 

一、http重新導向

當http代理（比如瀏覽器）向web伺服器請求某個URL後，web伺服器可以通過http回應標頭資訊中的Location標記來返回一個新的URL。這意味著HTTP代理需要繼續請求這個新的URL，完成自動跳轉。

 

效能缺陷：

1、吞吐率限制

主要站台伺服器的吞吐率平均分配到了被轉移的伺服器。現假設使用RR（Round Robin）調度策略，子伺服器的最大吞吐率為1000reqs/s，那麼主伺服器的吞吐率要達到3000reqs/s才能完全發揮三檯子伺服器的作用，那麼如果有100檯子伺服器，那麼主伺服器的吞吐率可想而知得有大？相反，如果主服務的最大吞吐率為6000reqs/s，那麼平均分配到子伺服器的吞吐率為2000reqs/s，而現子伺服器的最大吞吐率為1000reqs/s，因此就得增加子伺服器的數量，增加到6個才能滿足。

 

2、重新導向訪問深度不同

有的重新導向一個靜態頁面，有的重新導向相比複雜的動態網頁面，那麼實際伺服器的負載差異是不可預料的，而主站伺服器卻一無所知。因此整站使用重新導向方法做負載平衡不太好。

 

我們需要權衡轉移請求的開銷和處理實際請求的開銷，前者相對於後者越小，那麼重新導向的意義就越大，例如下載。你可以去很多鏡像下載網站試下，會發現基本下載都使用了Location做了重新導向。

 

二、DNS負載平衡

DNS負責提供網域名稱解析服務，當訪問某個網站時，實際上首先需要通過該網站網域名稱的DNS伺服器來擷取網域名稱指向的IP地址，在這一過程中，DNS伺服器完成了網域名稱到IP地址的映射，同樣，這樣映射也可以是一對多的，這時候，DNS伺服器便充當了負載平衡調度器，它就像http重新導向轉換策略一樣，將使用者的請求分散到多台伺服器上，但是它的實現機制完全不同。

 

使用dig命令來看下"baidu"的DNS設定

可見baidu擁有三個A記錄

 

相比http重新導向，基於DNS的負載平衡完全節省了所謂的主要站台，或者說DNS伺服器已經充當了主要站台的職能。但不同的是，作為調度器，DNS伺服器本身的效能幾乎不用擔心。因為DNS記錄可以被使用者瀏覽器或者互連網接入服務商的各級DNS伺服器緩衝，只有當緩衝到期後才會重新向網域名稱的DNS伺服器請求解析。也說是DNS不存在http的吞吐率限制，理論上可以無限增加實際伺服器的數量。

 

特性:

1、可以根據使用者IP來進行智能解析。DNS伺服器可以在所有可用的A記錄中尋找離用記最近的一台伺服器。

2、動態DNS：在每次IP地址變更時，及時更新DNS伺服器。當然，因為緩衝，一定的延遲不可避免。

 

不足：

1、沒有使用者能直接看到DNS解析到了哪一台實際伺服器，加伺服器營運人員的調試帶來了不便。

2、策略的局限性。例如你無法將HTTP請求的上下文引入到調度策略中，而在前面介紹的基於HTTP重新導向的負載平衡系統中，調度器工作在HTTP層面，它可以充分理解HTTP請求後根據網站的應用邏輯來設計調度策略，比如根據請求不同的URL來進行合理的過濾和轉移。

3、如果要根據實際伺服器的即時負載差異來調整調度策略，這需要DNS伺服器在每次解析操作時分析各伺服器的健康狀態，對於DNS伺服器來說，這種自訂開發存在較高的門檻，更何況大多數網站只是使用第三方DNS服務。

4、DNS記錄緩衝，各級節點的DNS伺服器不同程式的緩衝會讓你暈頭轉向。

5、基於以上幾點，DNS伺服器並不能很好地完成工作量均衡分配，最後，是否選擇基於DNS的負載平衡方式完全取決於你的需要。

 

三、反向 Proxy負載平衡

這個肯定大家都有所接觸，因為幾乎所有主流的Web伺服器都熱衷於支援基於反向 Proxy的負載平衡。它的核心工作就是轉寄HTTP請求。

相比前面的HTTP重新導向和DNS解析，反向 Proxy的調度器扮演的是使用者和實際伺服器中間人的角色：

1、任何對於實際伺服器的HTTP請求都必須經過調度器

2、調度器必須等待實際伺服器的HTTP響應，並將它反饋給使用者（前兩種方式不需要經過調度反饋，是實際伺服器直接發送給使用者）

 

特性：

1、調度策略豐富。例如可以為不同的實際伺服器設定不同的權重，以達到能者多勞的效果。

2、對反向 Proxy伺服器的並發處理能力要求高，因為它工作在HTTP層面。

3、反向 Proxy伺服器進行轉寄操作本身是需要一定開銷的，比如建立線程、與後端伺服器建立TCP串連、接收後端伺服器返回的處理結果、分析HTTP頭部資訊、使用者空間和核心空間的頻繁切換等，雖然這部分時間並不長，但是當後端伺服器處理請求的時間非常短時，轉寄的開銷就顯得尤為突出。例如請求靜態檔案，更適合使用前面介紹的基於DNS的負載平衡方式。

4、反向 Proxy伺服器可以監控後端伺服器，比如系統負載、回應時間、是否可用、TCP串連數、流量等，從而根據這些資料調整負載平衡的策略。

5、反射Proxy 伺服器可以讓使用者在一次會話周期內的所有請求始終轉寄到一台特定的後端伺服器上（粘滯會話），這樣的好處一是保持session的本地訪問，二是防止後端伺服器的動態記憶體緩衝的資源浪費。

 

 

四、IP負載平衡(LVS-NAT)

因為反向 Proxy伺服器工作在HTTP層，其本身的開銷就已經嚴重製約了可擴充性，從而也限制了它的效能極限。那能否在HTTP層面以下實現負載平衡呢？

 

NAT伺服器:它工作在傳輸層，它可以修改發送來的IP資料包，將資料包的目標地址修改為實際伺服器位址。

從Linux2.4核心開始，其內建的Neftilter模組在核心中維護著一些資料包過濾表，這些表包含了用於控制資料包過濾的規則。可喜的是，Linux提供了iptables來對過濾表進行插入、修改和刪除等操作。更加令人振奮的是，Linux2.6.x核心中內建了IPVS模組，它的工作性質類型於Netfilter模組，不過它更專註於實現IP負載平衡。

想知道你的伺服器核心是否已經安裝了IPVS模組，可以

有輸出意味著IPVS已經安裝了。IPVS的管理工具是ipvsadm，它為提供了基於命令列的配置介面，可以通過它快速實現負載平衡系統。這就是大名鼎鼎的LVS(Linux Virtual Server，Linux虛擬伺服器)。

 

1、開啟調度器的資料包轉寄選項

echo 1 > /proc/sys/net/ipv4/ip_forward

2、檢查實際伺服器是否已經將NAT伺服器作為自己的預設閘道，如果不是，如添加

route add default gw xx.xx.xx.xx

3、使用ipvsadm配置

ipvsadm -A -t 111.11.11.11:80 -s rr  

添加一台虛擬伺服器，-t 後面是伺服器的外網ip和連接埠，-s rr是指採用簡單輪詢的RR調度策略（這屬於靜態調度策略，除此之外，LVS還提供了系列的動態調度策略，比如最小串連（LC）、帶權重的最小串連（WLC），最短期望時間延遲（SED）等）

ipvsadm -a -t 111.11.11.11:80 -r 10.10.120.210:8000 -m  

ipvsadm -a -t 111.11.11.11:80 -r 10.10.120.211:8000 -m  

添加兩台實際伺服器（不需要有外網ip），-r後面是實際伺服器的內網ip和連接埠，-m表示採用NAT方式來轉寄資料包

運行ipvsadm -L -n可以查看實際伺服器的狀態。這樣就大功告成了。

 

實驗證明使用基於NAT的負載平衡系統。作為調度器的NAT伺服器可以將吞吐率提升到一個新的高度，幾乎是反向 Proxy伺服器的兩倍以上，這大多歸功於在核心中進行請求轉寄的較低開銷。但是一旦請求的內容過大時，不論是基於反向 Proxy還是NAT，負載平衡的整體輸送量都差距不大，這說明對於一睦開銷較大的內容，使用簡單的反向 Proxy來搭建負載平衡系統是值考慮的。

 

這麼強大的系統還是有它的瓶頸，那就是NAT伺服器的網路頻寬，包括內部網路和外部網路。當然如果你不差錢，可以去花錢去購買千兆交換器或萬兆交換器，甚至負載平衡硬體裝置，但如果你是個屌絲，咋辦？

一個簡單有效辦法就是將基於NAT的叢集和前面的DNS混合使用，比如５個100Mbps出口寬頻叢集，然後通過DNS來將使用者請求均衡地指向這些叢集，同時，你還可以利用DNS智能解析實現地區就近訪問。這樣的配置對於大多數業務是足夠了，但是對於提供下載或視頻等服務的大規模網站，NAT伺服器還是不夠出色。

 

五、直接路由(LVS-DR)

NAT是工作在網路分層模型的傳輸層（第四層），而直接路由是工作在資料連結層（第二層），貌似更屌些。它通過修改資料包的目標MAC地址（沒有修改目標IP），將資料包轉寄到實際伺服器上，不同的是，實際伺服器的響應資料包將直接發送給客戶羰，而不經過調度器。

1、網路設定

這裡假設一台負載平衡調度器，兩台實際伺服器，購買三個外網ip，一台機一個，三台機的預設閘道需要相同，最後再設定同樣的ip別名，這裡假設別名為10.10.120.193。這樣一來，將通過10.10.120.193這個IP別名來訪問調度器，你可以將網站的網域名稱指向這個IP別名。

2、將ip別名添加到迴環介面lo上

這是為了讓實際伺服器不要去尋找其他擁有這個IP別名的伺服器，在實際伺服器中運行：

另外還要防止實際伺服器響應來自網路中針對IP別名的ARP廣播，為此還要執行：

echo "1" > /proc/sys/net/ipv4/conf/lo/arp_ignore

echo "2" > /proc/sys/net/ipv4/conf/lo/arp_announce

echo "1" > /proc/sys/net/ipv4/conf/all/arp_ignore

echo "1" > /proc/sys/net/ipv4/conf/all/arp_announce

配置完了就可以使用ipvsadm配置LVS-DR叢集了

 

ipvsadm -A -t 10.10.120.193:80 -s rr  

ipvsadm -a -t 10.10.120.193:80 -r 10.10.120.210:8000 -g  

ipvsadm -a -t 10.10.120.193:80 -r 10.10.120.211:8000 -g  

-g 就意味著使用直接路由的方式轉寄資料包

LVS-DR 相較於LVS-NAT的最大優勢在於LVS-DR不受調度器寬頻限制，例如假設三台伺服器在WAN交換器出口寬頻都限制為10Mbps，只要對於串連調度器和兩台實際伺服器的LAN交換器沒有限速，那麼，使用LVS-DR理論上可以達到20Mbps的最大出口寬頻，因為它的實際伺服器的響應資料包可以不經過調度器而直接發往使用者端啊，所以它與調度器的出口寬頻沒有關係，只能自身的有關係。而如果使用LVS-NAT，叢集只能最大使用10Mbps的寬頻。所以，越是響應資料包遠遠超過請求資料包的服務，就越應該降低調度器轉移請求的開銷，也就越能提高整體的擴充能力，最終也就越依賴於WAN出口寬頻。

 

總的來說，LVS-DR適合搭建可擴充的負載平衡系統，不論是Web伺服器還是檔案伺服器，以及視頻伺服器，它都擁有出色的效能。前提是你必須為實際器購買一系列的合法IP地址。

 

六、IP隧道(LVS-TUN)

基於IP隧道的請求轉寄機制：將調度器收到的IP資料包封裝在一個新的IP資料包中，轉交給實際伺服器，然後實際伺服器的響應資料包可以直接到達使用者端。目前Linux大多支援，可以用LVS來實現，稱為LVS-TUN，與LVS-DR不同的是，實際伺服器可以和調度器不在同一個WANt網段，調度器通過IP隧道技術來轉寄請求到實際伺服器，所以實際伺服器也必須擁有合法的IP地址。

 

總體來說，LVS-DR和LVS-TUN都適合響應和請求不對稱的Web伺服器，如何從它們中做出選擇，取決於你的網路部署需要，因為LVS-TUN可以將實際伺服器根據需要部署在不同的地區，並且根據就近訪問的原則來轉移請求，所以有類似這種需求的，就應該選擇LVS-TUN。