LVS負載均衡

負載均衡集群是Load Balance 集群的縮寫，翻譯成中文就是負載均衡集群。常用的負載均衡開源軟體有Nginx、LVS、Haproxy，商業的硬體負載均衡設備有F5、Netscale等。

負載均衡LVS基本介紹

LB集群的架構和原理很簡單，就是當用戶的請求過來時，會直接分發到Director Server上，然後它把用戶的請求根據設置好的調度演算法，智能均衡的分發後端真正伺服器（real server）上。為了避免不同機器上用戶請求的數據不一樣，需要用到了共用存儲，這樣保證所有用戶請求的數據是一樣的。

LVS是Linux Virtual Server 的簡稱，也就是linux虛擬伺服器。這是由章文嵩博士發起的一個開源項目，官網：http://www.linuxvirtualserver.org 現在LVS已經是 Linux 內核標準的一部分。使用 LVS 可以達到的技術目標是：通過 LVS 達到的負載均衡技術和 Linux 操作系統實現一個高性能高可用的 Linux 服務集群，它具有良好的可靠性、可擴展性和可操作性。從而以廉價的成本實現最優的性能。 LVS 是一個實現負載均衡集群的開源軟體項目，LVS架構從邏輯上可分為調度層、Server集群層和共用存儲。

LVS的體系架構

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

如圖：

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 Arrary層：

  由一組實際運行應用服務的機器組成，Real Server可以是WEB 伺服器、MALL伺服器、FTP伺服器、DNS伺服器、等等，每個Real Server 之間通過高速的LAN或分佈在各地的WAN相連接，在實際的應用中，Director Server也可以同時兼任Real Server的角色。

• Shared Storage層：

  是為所有Real Server提供共用存儲空間和內容一致性的存儲區域，在物理上，一般有磁碟陣列設備組成，為了提供內容的一致性，一般可以通過NFS網路文件系統共用數據，但是NFS在繁忙的業務系統中，性能並不是很好，此時可以採用集群文件系統，列如Red hat的GFS文件系統等等。

LVS的基本工作原理

（1）當用戶負載均衡調度器（Director Server）發起請求，調度器將請求發往至內核空間

（2）PREROUTING 鏈首先會接受到用戶請求，判斷目標IP確實是本地IP，將數據包發往 INPUT 鏈

（3）IPVS 是工作在 INPUT 鏈上的，當用戶請求到達INPUT時，IPVS 會將用戶請求和自己定義好的集群服務進行比對，如果用戶請求的就是集群服務，那麼此時 IPVS 會強行修改數據包里的目標IP地址和埠，並將新的數據包發往 POSTROUTING 鏈

（4）POSTROUTING 鏈將收到數據包後發現目標IP地址剛好是自己的後端伺服器，那麼此時通過選路，將數據包最終發送給後端的伺服器

LVS相關術語

（1）DS：Director Server　　指的是前端負載均衡器節點。

（2）RS：Real Server　　後端真實的工作伺服器。

（3）VIP：向外部直接面向用戶請求，作為用戶請求的目標的ip地址。

（4）DIP：Director Server IP　　主要用於和內部伺服器通訊的ip地址。

（5）RIP：Real Server IP　　後端伺服器的ip地址。

（6）CIP：Client IP　　　　訪問客戶端的IP地址。

LVS工作模式和原理

NAT 模式

NAT 模式工作原理：

（1）當用戶請求到達Director Server，此時的請求數據報文會先到內核空間的PREROUTING鏈。此時報文的源IP為 CIP，目標IP為 VIP。

（2）PREROUTING檢查發現數據包的目標IP 是本機，將數據包發送至INPUT鏈。

（3）IPVS比對數據包請求的服務是否為集群服務，若是，修改數據包的目標IP地址為後端伺服器IP，然後將數據包發送至POSTROUTING鏈。此時報文的源IP為 CIP，目標IP為 RIP。

（4）POSTROUTING鏈通過選路，將數據包發送給Real Server。

（5）Real Server對比發現目標為自己的IP，開始構建響應報文發回給Director Server。此時報文的源IP為 RIP，目標IP為 CIP。

（6）Director Server在響應客戶端前，此時會將源IP地址修改為自己的VIP地址，然後響應給客戶端。此時報文的源IP為 VIP，目標IP為CIP。

DR 模式

DR 模式工作原理：

（1）首先用戶用CIP請求VIP。

（2）根據上圖可以看到，不管是Director Server 還是Real Server 上都需要配置相同的VIP，那麼當用戶請求到達我們的集群網路的前端路由器的時候，請求數據包的源地址為CIP，目標地址為VIP；此時路由器還會發廣播問誰是VIP，那麼我們集群中所有的節點都配置有VIP，此時誰先響應路由器那麼路由器就會將用戶請求發給誰，這樣一來我們的集群系統是不是沒有意義了，那我們可以在網關路由器上配置靜態路由指定VIP就是Director Server，或者使用一種機制不讓Real Server 接受來自網路中的ARP 地址解析請求，這樣一來用戶的請求包都會經過Director Server。

（3）當用戶請求到達Director Server，此時請求的數據報文會先到內核空間的PREROUTING鏈，此時報文的源IP為CIP，目標IP為VIP。

（4）PREROUTING檢查發現數據包的目標IP為本機，將數據包發送至INPUT鏈。

（5）IPVS對比數據包請求的服務是否為集群服務，若是，將請求報文中的源MAC地址修改DIP的MAC地址，將目標MAC地址修改為RIP的MAC地址，然後將數據包發至POSTROUTING鏈，此時的源IP和目標IP均未修改，僅修改了源MAC地址為DIP的MAC地址，目標MAC地址為RIP的MAC地址。

（6）由於DS和RS在同一個網路中，所以是通過二層來傳輸，POSTROUTING鏈檢查目標MAC地址為RIP的MAC地址，那麼此時數據包將會發至Real Server。

（7）RS發現請求報文的MAC地址是自己的MAC地址，就接收報文。處理完成之後，將相應報文通過lo介面傳送給eth0網卡然後向外發出。此時的源IP地址為VIP，目標IP為CIP。

（8）響應報文最終送達至客戶端。

配置DR的三種方式：

• 第一種：在路由器上明顯說明vip對應的地址一定是Director上的MAC，只要綁定，以後再跟vip通信也不用再請求了，這個綁定是靜態的，所以它也不會失效，也不會再次發起請求，但是有個前提，我們的路由設備必須有操作許可權才能夠綁定MAC地址，萬一這個路由器是運營商操作的，我們沒法操作怎麼辦？第一種方式固然很簡單，但未必可行。
• 第二種：在個別主機上（列如：紅帽）它們引進的有一種程式arptables，它有點類似iptables，它肯定是基於arp或者MAC做訪問控制的，很顯然我們只需要在每一個Real Server上定義arptables規則，如果用戶arp廣播請求的目標地址是本機的vip則不予響應，或者說響應的報文不讓出去，很顯然（gateway）是接收不到的，也就是director響應的報文才能到達gateway，這個也行。第二種方式我們可以基於arptables。
• 第三種：在相對較新的版本中新增了兩個內核參數（kernelparameter），第一個是arp_ignore定義接受到ARP請求時的響應級別；第二個是arp_announce定義將自己地址向外通告時的通告級別。[提示：很顯然我們現在的系統一般在內核中都是支持這些參數的，我們用參數的方式進行調整更具有朴實性，它還不依賴額外的條件，像arptables，也不依賴外在路由配置的設置，反而通常我們使用的是第三種配置方式]

  arp_ignore:定義接收到ARP請求時的響應級別
  0：只要本地設置的有相應的地址，就給予響應。（預設）
  1：僅回應目標IP地址是本地的入網地址的arp請求。
  2：僅回應目標IP地址是本地的入網地址，而且源IP和目標IP在同一個子網的arp請求。
  3：不回應網路界面的arp請求，而只對設置的唯一和連接地址做出回應。
  4-7：保留未使用。
  8：不回應所有的arp請求。
  
  arp_announce：定義將自己地址向外通告的通告級別：
  0：將本地任何介面上的任何地址向外通告。
  1：視圖僅向目標網路通告與其網路匹配的地址。
  2：僅向與本地介面上地址匹配的網路進行通告。

  arp_ignore與arp_announce 

DR模式的特性

• 保證前端路由將目標地址為VIP報文統統發給Director Server，而不是RS。
• Director和RS的VIP為同一個VIP。
• RS可以使用私有地址，也可以是公網地址，如果使用公網地址，此時可以通過互聯網對RIP進行直接訪問。
• RS跟Director Server必須在同一個物理網路中。
• 所有的請求報文經由Director Server，但響應報文必須不能經過Director Server。
• 不支持地址轉換，也不支持埠轉換。
• RS 可以是大多數常見的操作系統。
• RS 的網關絕不允許指向DIP（因為我們不允許它經過Director）
• RS上的lo介面配置VIP的ip地址
• DR模式是市面上用得最廣的。
• 缺陷：RS和DS必須在同一機房。

Tunnel 模式

Tunnel 模式工作原理：

（1）當用戶請求到達Director Server，此時請求的數據報文會先拿到內核空間的PREROUTING鏈，此時報文的源IP為CIP，目標IP為VIP。

（2）PREROUTING檢查發現數據包的目標IP是本機，將數據包發送至INPUT鏈。

（3）IPVS對比數據包請求的服務是否為集群服務，若是，在請求報文的首部再次封裝一層IP報文，封裝源IP為DIP，目標IP為RIP。然後發至POSTROUTING鏈，此時源IP為DIP，目標IP為RIP。

（4）POSTROUTING鏈根據最新封裝的IP報文，將數據包發送至RS（因為在外層多封裝了一層IP首部，所以可以理解為 此時通過隧道傳輸）。此時源IP為DIP，目標IP為RIP。

（5）RS接收到報文後發現是自己的IP地址，就將報文接收下來，拆除掉最外層的IP後，會發現裡面還有一層IP首部，而且目標是自己的lo介面VIP，那麼此時RS開始處理請求，處理完成之後，通過lo介面發送給eth0網卡，然後向外傳遞。此時源IP為VIP，目標IP為CIP。

（6）響應報文最終送達至客戶端。

Tunnel模式的特性

RIP、VIP、DIP全是公網地址。

RS的網關不會也不可能指向DIP。

所有的請求報文經由Director Server，但響應報文必須不能經過Director Server。

不支持埠映射。

RS的系統必須支持隧道。

LVS 的調度演算法

固定調度演算法：rr，wrr，dh，sh

動態調度演算法：wlc，lc，lblc，lblcr

固定調度演算法：即調度器不會去判斷後端伺服器的繁忙與否，一如既往得將請求派發下去。

動態調度演算法：調度器會去判斷後端伺服器的繁忙程度，然後依據調度演算法動態得派發請求。

rr：輪詢（round robin）

這種演算法是最簡單的，就是按依次迴圈的方式將請求調度到不同的伺服器上，該演算法最大的特點就是簡單。輪詢演算法假設所有的伺服器處理請求的能力都是一樣的，調度器會將所有的請求平均分配給每個真實伺服器，不管後端 RS 配置和處理能力，非常均衡地分發下去。這個調度的缺點是，不管後端伺服器的繁忙程度是怎樣的，調度器都會講請求依次發下去。如果A伺服器上的請求很快請求完了，而B伺服器的請求一直持續著，將會導致B伺服器一直很忙，而A很閑，這樣便沒起到均衡的左右。

wrr：加權輪詢（weight round robin）

這種演算法比 rr 的演算法多了一個權重的概念，可以給 RS 設置權重，權重越高，那麼分發的請求數越多，權重的取值範圍 0 – 100。主要是對rr演算法的一種優化和補充， LVS 會考慮每台伺服器的性能，並給每台伺服器添加要給權值，如果伺服器A的權值為1，伺服器B的權值為2，則調度到伺服器B的請求會是伺服器A的2倍。權值越高的伺服器，處理的請求越多。

dh：目標地址散列調度演算法 （destination hash）

簡單的說，即將同一類型的請求分配給同一個後端伺服器，例如將以 .jgp、.png等結尾的請求轉發到同一個節點。這種演算法其實不是為了真正意義的負載均衡，而是為了資源的分類管理。這種調度演算法主要應用在使用了緩存節點的系統中，提高緩存的命中率。

sh：源地址散列調度演算法（source hash）

即將來自同一個ip的請求發給後端的同一個伺服器，如果後端伺服器工作正常沒有超負荷的話。這可以解決session共用的問題，但是這裡有個問題，很多企業、社區、學校都是共用的一個IP，這將導致請求分配的不均衡。

lc：最少連接數（least-connection）

這個演算法會根據後端 RS 的連接數來決定把請求分發給誰，比如 RS1 連接數比 RS2 連接數少，那麼請求就優先發給 RS1。這裡問題是無法做到會話保持，即session共用。

wlc：加權最少連接數（weight least-connection）

這個比最少連接數多了一個加權的概念，即在最少連接數的基礎上加一個權重值，當連接數相近，權重值越大，越優先被分派請求。

lblc：基於局部性的最少連接調度演算法（locality-based least-connection）

將來自同一目的地址的請求分配給同一臺RS如果這台伺服器尚未滿負荷，否則分配給連接數最小的RS，並以它為下一次分配的首先考慮。

lblcr：基於地址的帶重覆最小連接數調度 (Locality-Based Least-Connection with Replication)

這個用得少，可以略過。