Centos使用LVS+keepalive 搭建集羣原理詳解

負載均衡集羣是 load balance 集羣的簡寫，翻譯成中文就是負載均衡集羣。經常使用的負載均衡開源軟件有nginx、lvs、haproxy，商業的硬件負載均衡設備F五、Netscale。這裏主要是學習Linux下 LVS 並對其進行了詳細的總結記錄。

1、負載均衡LVS基本介紹
LB集羣的架構和原理很簡單，就是當用戶的請求過來時，會直接分發到Director Server上，而後它把用戶的請求根據設置好的調度算法，智能均衡地分發到後端真正服務器(real server)上。爲了不不一樣機器上用戶請求獲得的數據不同，須要用到了共享存儲，這樣保證全部用戶請求的數據是同樣的。

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


2、LVS的基本工做原理

1. 當用戶向負載均衡調度器（Director Server）發起請求，調度器將請求發往至內核空間
2. PREROUTING鏈首先會接收到用戶請求，判斷目標IP肯定是本機IP，將數據包發往INPUT鏈
3. IPVS是工做在INPUT鏈上的，當用戶請求到達INPUT時，IPVS會將用戶請求和本身已定義好的集羣服務進行比對，若是用戶請求的就是定義的集羣服務，那麼此時IPVS會強行修改數據包裏的目標IP地址及端口，並將新的數據包發往POSTROUTING鏈
4. POSTROUTING連接收數據包後發現目標IP地址恰好是本身的後端服務器，那麼此時經過選路，將數據包最終發送給後端的服務器


3、LVS的組成
LVS 由2部分程序組成，包括 ipvs 和 ipvsadm。

1. ipvs(ip virtual server)：一段代碼工做在內核空間，叫ipvs，是真正生效實現調度的代碼。
2. ipvsadm：另一段是工做在用戶空間，叫ipvsadm，負責爲ipvs內核框架編寫規則，定義誰是集羣服務，而誰是後端真實的服務器(Real Server)


4、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地址。

下邊是三種工做模式的原理和特色總結。


5、LVS/NAT原理和特色
1. 重點理解NAT方式的實現原理和數據包的改變。

(a). 當用戶請求到達Director Server，此時請求的數據報文會先到內核空間的PREROUTING鏈。 此時報文的源IP爲CIP，目標IP爲VIP 
(b). PREROUTING檢查發現數據包的目標IP是本機，將數據包送至INPUT鏈
(c). IPVS比對數據包請求的服務是否爲集羣服務，如果，修改數據包的目標IP地址爲後端服務器IP，而後將數據包發至POSTROUTING鏈。 此時報文的源IP爲CIP，目標IP爲RIP 
(d). POSTROUTING鏈經過選路，將數據包發送給Real Server
(e). Real Server比對發現目標爲本身的IP，開始構建響應報文發回給Director Server。 此時報文的源IP爲RIP，目標IP爲CIP 
(f). Director Server在響應客戶端前，此時會將源IP地址修改成本身的VIP地址，而後響應給客戶端。 此時報文的源IP爲VIP，目標IP爲CIP

2. LVS-NAT模型的特性

RS應該使用私有地址，RS的網關必須指向DIP

DIP和RIP必須在同一個網段內

請求和響應報文都須要通過Director Server，高負載場景中，Director Server易成爲性能瓶頸

支持端口映射

RS可使用任意操做系統

缺陷：對Director Server壓力會比較大，請求和響應都需通過director server


6、LVS/DR原理和特色
1. 重將請求報文的目標MAC地址設定爲挑選出的RS的MAC地址

(a) 當用戶請求到達Director Server，此時請求的數據報文會先到內核空間的PREROUTING鏈。 此時報文的源IP爲CIP，目標IP爲VIP
(b) PREROUTING檢查發現數據包的目標IP是本機，將數據包送至INPUT鏈
(c) IPVS比對數據包請求的服務是否爲集羣服務，如果，將請求報文中的源MAC地址修改成DIP的MAC地址，將目標MAC地址修改RIP的MAC地址，而後將數據包發至POSTROUTING鏈。 此時的源IP和目的IP均未修改，僅修改了源MAC地址爲DIP的MAC地址，目標MAC地址爲RIP的MAC地址 
(d) 因爲DS和RS在同一個網絡中，因此是經過二層來傳輸。POSTROUTING鏈檢查目標MAC地址爲RIP的MAC地址，那麼此時數據包將會發至Real Server。
(e) RS發現請求報文的MAC地址是本身的MAC地址，就接收此報文。處理完成以後，將響應報文經過lo接口傳送給eth0網卡而後向外發出。 此時的源IP地址爲VIP，目標IP爲CIP 
(f) 響應報文最終送達至客戶端

2. LVS-DR模型的特性

特色1：保證前端路由將目標地址爲VIP報文通通發給Director Server，而不是RS

RS可使用私有地址；也能夠是公網地址，若是使用公網地址，此時能夠經過互聯網對RIP進行直接訪問

RS跟Director Server必須在同一個物理網絡中

全部的請求報文經由Director Server，但響應報文必須不能進過Director Server

不支持地址轉換，也不支持端口映射

RS能夠是大多數常見的操做系統

RS的網關毫不容許指向DIP(由於咱們不容許他通過director)

RS上的lo接口配置VIP的IP地址

缺陷：RS和DS必須在同一機房中

3. 特色1的解決方案：

在前端路由器作靜態地址路由綁定，將對於VIP的地址僅路由到Director Server

存在問題：用戶未必有路由操做權限，由於有多是運營商提供的，因此這個方法未必實用

arptables：在arp的層次上實如今ARP解析時作防火牆規則，過濾RS響應ARP請求。這是由iptables提供的

修改RS上內核參數（arp_ignore和arp_announce）將RS上的VIP配置在lo接口的別名上，並限制其不能響應對VIP地址解析請求。


7、LVS/Tun原理和特色
在原有的IP報文外再次封裝多一層IP首部，內部IP首部(源地址爲CIP，目標IIP爲VIP)，外層IP首部(源地址爲DIP，目標IP爲RIP)

(a) 當用戶請求到達Director Server，此時請求的數據報文會先到內核空間的PREROUTING鏈。 此時報文的源IP爲CIP，目標IP爲VIP 。
(b) PREROUTING檢查發現數據包的目標IP是本機，將數據包送至INPUT鏈
(c) IPVS比對數據包請求的服務是否爲集羣服務，如果，在請求報文的首部再次封裝一層IP報文，封裝源IP爲爲DIP，目標IP爲RIP。而後發至POSTROUTING鏈。 此時源IP爲DIP，目標IP爲RIP 
(d) POSTROUTING鏈根據最新封裝的IP報文，將數據包發至RS（由於在外層封裝多了一層IP首部，因此能夠理解爲此時經過隧道傳輸）。 此時源IP爲DIP，目標IP爲RIP
(e) RS接收到報文後發現是本身的IP地址，就將報文接收下來，拆除掉最外層的IP後，會發現裏面還有一層IP首部，並且目標是本身的lo接口VIP，那麼此時RS開始處理此請求，處理完成以後，經過lo接口送給eth0網卡，而後向外傳遞。 此時的源IP地址爲VIP，目標IP爲CIP
(f) 響應報文最終送達至客戶端

LVS-Tun模型特性

RIP、VIP、DIP全是公網地址

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

全部的請求報文經由Director Server，但響應報文必須不能進過Director Server

不支持端口映射

RS的系統必須支持隧道

其實企業中最經常使用的是 DR 實現方式，而 NAT 配置上比較簡單和方便，後邊實踐中會總結 DR 和 NAT 具體使用配置過程。


8、LVS的八種調度算法
1. 輪叫調度 rr
這種算法是最簡單的，就是按依次循環的方式將請求調度到不一樣的服務器上，該算法最大的特色就是簡單。輪詢算法假設全部的服務器處理請求的能力都是同樣的，調度器會將全部的請求平均分配給每一個真實服務器，無論後端 RS 配置和處理能力，很是均衡地分發下去。

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

3. 最少連接 lc
這個算法會根據後端 RS 的鏈接數來決定把請求分發給誰，好比 RS1 鏈接數比 RS2 鏈接數少，那麼請求就優先發給 RS1 

4. 加權最少連接 wlc
這個算法比 lc 多了一個權重的概念。

5. 基於局部性的最少鏈接調度算法 lblc
這個算法是請求數據包的目標 IP 地址的一種調度算法，該算法先根據請求的目標 IP 地址尋找最近的該目標 IP 地址全部使用的服務器，若是這臺服務器依然可用，而且有能力處理該請求，調度器會盡可能選擇相同的服務器，不然會繼續選擇其它可行的服務器

6. 複雜的基於局部性最少的鏈接算法 lblcr
記錄的不是要給目標 IP 與一臺服務器之間的鏈接記錄，它會維護一個目標 IP 到一組服務器之間的映射關係，防止單點服務器負載太高。

7. 目標地址散列調度算法 dh
該算法是根據目標 IP 地址經過散列函數將目標 IP 與服務器創建映射關係，出現服務器不可用或負載太高的狀況下，發往該目標 IP 的請求會固定發給該服務器。

8. 源地址散列調度算法 sh
與目標地址散列調度算法相似，但它是根據源地址散列算法進行靜態分配固定的服務器資源。

 

轉載自：http://www.thinkphp.cn/topic/51067.html