負載均衡簡單介紹
用通俗的話來說負載均衡，就是通過不同的調度機制將用戶的請求分派到后端不同的服務器。緩解服務器的請求壓力，實現負載均衡的方案有多種，下面簡單說說了解的幾種方式：
- DNS 負載：利用DNS的解析可以實現區域的性用戶請求負載，這種負載方式是離用戶最近的負載方案，請求還沒有到達內部系統架構服務前就已經被分流了。
- LVS ：就是本篇文件要整理的解決方案，LVS性能特別強，它是工作在linux系統內核的一個程序，LVS負載的特點是超強的分流功能，但它只能負載調度流量的去向，沒有辦法實現在業務層分流負載。
- Haproxy：haproxy可以工作在ISO7層模型中的4層和7層，工作在4層時是基於IP的負載，這與LVS作用相同，工作在7層時是基於應用層的應用協議進行負載，可以根據分析報文內容並結合算法來選擇后端服務
- Nginx： nginx也是應用層負載均衡器，可以實現反向代理功能，nginx的特點是可以將請求按照業務類型進行向后端調度，對請求從業務功能上進行了負載調度。
lVS工作組成
LVS由兩部分組成，包括ipvs和ipvsadm：
-
ipvs：ipvs是工作在內核空間netfilter的input鏈上的框架，通過用戶空間工具進行管理，是真正生效實現調度的代碼。
-
ipvsadm：ipvsadm負責為ipvs內核框架編寫規則，管理配置內核中ipvs程序的用戶空間的管理工具
LVS工作原理
LVS是工作在linux內核空間的tcp/ip棧的應用程序，其程序名稱為ipvs，ipvs會監聽input鏈上的請求，一旦請求的是集群服務的話，ipvs鈎子函數會將請求拉出並進行報文修改，強制轉發到postrouting處理，關系圖如下圖所示：
在客戶端看來，負載層的LVS 就是一個真實的應用服務器，客戶端向LVS發送請求信息，LVS接收數據報文至內核空間，工作在input鏈上的ipvs模塊會判斷用戶請求是不是定義的后端服務器，如果用戶請求的就是定義的后端集群服務，數據報文傳送到input鏈上時，input鏈會強行將數據報文轉發給postrouting，postrouting將數據報文傳送給后端真實服務器
LVS的4種工作模式
LVS有多種工作模式，類型如下：
-
NAT：修改請求報文的目標IP，多目標IP的DNAT
-
DR：操縱封裝新的MAC地址
-
TUN：在原請求IP報文之外新加一個IP首部
-
FullNAT：修改請求報文的源和目標IP
生產環境中大多使用DR模型工作
LVS-NAT模式
在客戶端看來，負載層的Director server 就是一個真實的應用服務器，客戶端向LVS發送請求信息，Director server接收數據報文至內核空間，工作在input鏈上的ipvs模塊會判斷用戶請求是不是定義的后端服務器，如果用戶請求的就是定義的后端集群服務，數據報文傳送到input鏈上時，input鏈會強行將數據報文轉發給postrouting，postrouting將數據報文傳送給后端真實服務器。
LVS-NAT模型運行原理
NAT模式工作過程描述
-
1， Client向Director server發送帶有 [CIP-VIP] 的請求數據報文，PREROUTING 鏈接收數據報文發現目標ip是本機ip，隨后將報文轉發值INPUT鏈
-
2，工作在INPUT鏈上的IPVS比對數據包請求的服務是否為集群服務，如果是，修改數據包的目標IP地址為后端服務器IP，然后將數據包發至POSTROUTING鏈。 此時報文的源IP為CIP，目標IP為RIP
-
3， POSTROUTING根據選路發給后端realy server，realy server收到數據包發現目標ip是自己，然后向Director響應請求，此時響應報文中的源IP地址信息為 RIP,目標地址IP為CIP
-
4，Director server在響應Client之前再將報文中ip信息源IP地址改為 VIP，目標IP仍為CIP
NAT模式特點
本質是多目標IP的DNAT，通過將請求報文中的目標地址和目標端口修改為挑出的某個RS的RIP和PORT實現轉發
- 1，RIP和DIP應在同一個IP網絡，且應使用私網地址；RS的網關要指向DIP
- 2，請求報文和響應報文都必須經由Director轉發，Director易於成為系統瓶頸
- 3， 支持端口映射，可修改請求報文的目標PORT
- 4， LVS必須是Linux系統，RS可以是任意OS系統
LVS-DR模式
在DR工作模型中，Director收到請求通過修改數據數據報文中目的地址的MAC地址實現數據報文的轉發。在該模式下，Director和后端realy server都有一個相同VIP，且在同一物理網絡中，因此Client發送的請求報文到達INPUT鏈時，只要將報文中的[CIP-VIP]的MAC信息改成【DIP-MAC | RIP-MAC】,后端realy server接收報文並構建響應，此時，響應報文不再經過Director，realy server直接響應客戶端。
LVS-DR模型運行原理
DR模式工作流程
-
1，當用戶請求到達Director Server，此時請求的數據報文會先到內核空間的PREROUTING鏈。 此時報文的源IP為CIP，目標IP為VIP
-
2， PREROUTING檢查發現數據包的目標IP是本機，將數據包送至INPUT鏈
-
3， IPVS比對數據包請求的服務是否為集群服務，若是，將請求報文中的源MAC地址修改為DIP的MAC地址，將目標MAC地址修改RIP的MAC地址，然后將數據包發至POSTROUTING鏈。 此時的源IP和目的IP均未修改，僅修改了源MAC地址為DIP的MAC地址，目標MAC地址為RIP的MAC地址
-
4， 由於DS和RS在同一個網絡中，所以是通過二層來傳輸。POSTROUTING鏈檢查目標MAC地址為RIP的MAC地址，那么此時數據包將會發至Real Server。
-
5， RS發現請求報文的MAC地址是自己的MAC地址，就接收此報文。處理完成之后，將響應報文通過lo接口傳送給eth0網卡然后向外發出。 此時的源IP地址為VIP，目標IP為CIP
DR模式的特點
- 1，保證前端路由將目標地址為VIP的報文全部發送給DS，而不是RS
- 2，RS的RIP可以使用私有地址，但也可以使用公網地址
- 3，RS和director必須在同一物理網絡中
- 4，請求報文有director調度，但響應報文不一定經由director
- 5，不支持端口映射
- 6，RS可以支持大多數OS
- 7，RS的網關不能指向DIP
LVS-TUN模式
在TUN工作模式下，Client向Director server 發送請求報文，報文到達Director 內核空間不修改請求報文的ip首部，而是通過在原有ip首部[CIP-VIP]之外，再封裝一個ip首部[DIP-RIP]，RS收到報文后發現是自己的IP地址，就會將報文接受下來，拆除最外層的IP后，會發現里面還有一層IP首部，而且目標地址是自己的lo接口VIP，那么此時RS開始處理此請求，處理完成滯后，通過lo接口送給eth0網卡，然后向外傳遞。此時的源IP地址為VIP，目標IP為CIP
LVS-TUN模型運行原理
TUN模式工作流程
- 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
TUN模型特點
- 1，RIP、VIP、DIP全是公網地址
- 2，RS的網關不會也不可能指向DIP
- 3，所有的請求報文經由Director Server，但響應報文必須不能進過Director Server
- 4，不支持端口映射,
- 5，RS的系統必須支持隧道
LVS調度算法
- RR 輪詢
調度器將請求調度至后端服務器(這種方式最簡單，不考慮后端主機性能等因素，公平調度)
- WRR 加權輪詢
在輪詢的基礎上，調度器可以給后端主機指定權重，考慮到后端主機性能不均衡的問題，可以讓性能強的主機響應更多的請求
- LC 最少連接
調度器通過"最少連接"調度算法動態地將網絡請求調度到已建立的鏈接數最少的服務器上。如果集群系統的真實服務器具有相近的系統性能，采用"最小連接"調度算法可以較好地均衡負載。
- WLC 加權最少連接
調度器通過"加權輪叫"調度算法根據真實服務器的不同處理能力來調度訪問請求。這樣可以保證處理能力強的服務器處理更多的訪問流量。調度器可以自動問詢真實服務器的負載情況，並動態地調整其權值。
- LBLC 基於局部性最少連接
調度算法是針對目標IP地址的負載均衡，目前主要用於Cache集群系統。該算法根據請求的目標IP地址找出該目標IP地址最近使用的服務器，若該服務器 是可用的且沒有超載，將請求發送到該服務器；若服務器不存在，或者該服務器超載且有服務器處於一半的工作負載，則用"最少鏈接"的原則選出一個可用的服務 器，將請求發送到該服務器。
- LBLCR 帶復制的基於局部性最少連接
它與LBLC算法的不同之處是它要維護從一個 目標IP地址到一組服務器的映射，而LBLC算法維護從一個目標IP地址到一台服務器的映射。該算法根據請求的目標IP地址找出該目標IP地址對應的服務 器組，按"最小連接"原則從服務器組中選出一台服務器，
若服務器沒有超載，將請求發送到該服務器，若服務器超載；則按"最小連接"原則從這個集群中選出一 台服務器，將該服務器加入到服務器組中，將請求發送到該服務器。同時，當該服務器組有一段時間沒有被修改，將最忙的服務器從服務器組中刪除，以降低復制的程度。
- DH 目標地址哈希
目標地址哈希，將發往同一個目標地址的請求始終轉發至第一次挑中的RS，典型使用場景是正向代理緩存場景中的負載均衡，如：寬帶運營商
- SH 源地址哈希
實現session sticky，源IP地址hash；將來自於同一個IP地址的請求始終發往第一次挑中的RS，從而實現會話綁定