負載均衡原理的解析

01-30

負載均衡的重要性無需多說，今天帶來：負載均衡原理的解析。

開頭先理解一下所謂的「均衡」。

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

一、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的吞吐率限制，理論上可以無限增加實際伺服器的數量。

特性:

可以根據用戶IP來進行智能解析。DNS伺服器可以在所有可用的A記錄中尋找離用記最近的一台伺服器。
動態DNS：在每次IP地址變更時，及時更新DNS伺服器。當然，因為緩存，一定的延遲不可避免。

不足：

沒有用戶能直接看到DNS解析到了哪一台實際伺服器，加伺服器運維人員的調試帶來了不便。
策略的局限性。例如你無法將HTTP請求的上下文引入到調度策略中，而在前面介紹的基於HTTP重定向的負載均衡系統中，調度器工作在HTTP層面，它可以充分理解HTTP請求後根據站點的應用邏輯來設計調度策略，比如根據請求不同的URL來進行合理的過濾和轉移。
如果要根據實際伺服器的實時負載差異來調整調度策略，這需要DNS伺服器在每次解析操作時分析各伺服器的健康狀態，對於DNS伺服器來說，這種自定義開發存在較高的門檻，更何況大多數站點只是使用第三方DNS服務。
DNS記錄緩存，各級節點的DNS伺服器不同程序的緩存會讓你暈頭轉向。
基於以上幾點，DNS伺服器並不能很好地完成工作量均衡分配，最後，是否選擇基於DNS的負載均衡方式完全取決於你的需要。

三、反向代理負載均衡

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

相比前面的HTTP重定向和DNS解析，反向代理的調度器扮演的是用戶和實際伺服器中間人的角色：

任何對於實際伺服器的HTTP請求都必須經過調度器
調度器必須等待實際伺服器的HTTP響應，並將它反饋給用戶（前兩種方式不需要經過調度反饋，是實際伺服器直接發送給用戶）

特性：

調度策略豐富。例如可以為不同的實際伺服器設置不同的權重，以達到能者多勞的效果。
對反向代理伺服器的並發處理能力要求高，因為它工作在HTTP層面。
反向代理伺服器進行轉發操作本身是需要一定開銷的，比如創建線程、與後端伺服器建立TCP連接、接收後端伺服器返回的處理結果、分析HTTP頭部信息、用戶空間和內核空間的頻繁切換等，雖然這部分時間並不長，但是當後端伺服器處理請求的時間非常短時，轉發的開銷就顯得尤為突出。例如請求靜態文件，更適合使用前面介紹的基於DNS的負載均衡方式。
反向代理伺服器可以監控後端伺服器，比如系統負載、響應時間、是否可用、TCP連接數、流量等，從而根據這些數據調整負載均衡的策略。
反射代理伺服器可以讓用戶在一次會話周期內的所有請求始終轉發到一台特定的後端伺服器上（粘滯會話），這樣的好處一是保持session的本地訪問，二是防止後端伺服器的動態內存緩存的資源浪費。

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

因為反向代理伺服器工作在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_forwardn

2、檢查實際伺服器是否已經將NAT伺服器作為自己的默認網關，如果不是，如添加

route add default gw xx.xx.xx.xxn

3、使用ipvsadm配置

ipvsadm -A -t 111.11.11.11:80 -s rrn

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

ipvsadm -a -t 111.11.11.11:80 -r 10.10.120.210:8000 -mnnipvsadm -a -t 111.11.11.11:80 -r 10.10.120.211:8000 -mn

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

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

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

這麼強大的系統還是有它的瓶頸，那就是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_ignorennecho "2" > /proc/sys/net/ipv4/conf/lo/arp_announcennecho "1" > /proc/sys/net/ipv4/conf/all/arp_ignorennecho "1" > /proc/sys/net/ipv4/conf/all/arp_announcen

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

ipvsadm -A -t 10.10.120.193:80 -s rrnnipvsadm -a -t 10.10.120.193:80 -r 10.10.120.210:8000 -gnnipvsadm -a -t 10.10.120.193:80 -r 10.10.120.211:8000 -gn

-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。