LVS四種工作模式及排程演算法詳解
LVS即Linux虛擬伺服器
LVS實現了基於IP的資料請求負載均衡排程方案,它實現了四層交換，終端網際網路使用者從外部訪問公司的外部負載均衡伺服器，終端使用者的Web請求會發送給LVS排程器，LVS根據自身的排程演算法將客戶端請求傳送給後端主機叢集中的某一臺主機，LVS工作模式分為NAT模式、TUN模式、DR模式以及FULLNAT模式。
lvs的實現原理及協議支援:
ipvsadm/ipvs
ipvsadmin:使用者空間的命令列工具，用於管理叢集服務；
ipvs:工作核心中的netfilter INPUT鉤子上；
支援TCP,UDP,AH,EST,AH_EST,SCTP等諸多協議；
lvs arch:
排程器（負載均衡器）：director,dispatcher，balencer
RS:Real Server 後端真正提供服務的主機
防火牆資料流向：
PREROUTING -->INPUT
PREROUTING -->FORWARD-->POSTROUTING
OUTPUT-->POSTROUTING
LVS四種類型：
lvs-nat：基於NAT的負載均衡模式
lvs-dr(direct routing)：基於DR的負載均衡模式
lvs-tun(ip tunneling)：基於TUN的負載均衡模式
lvs-fullnat：基於FULLNAT的負載均衡模式
根據這張圖我們來詳細介紹一下LVS的四種工作模式
基本名詞解釋：
Client IP:CIP
Director Virutal IP:VIP
Director IP:DIP
Real Server IP:RIP
1.LVS-NAT
多目標的DNAT(iptables)轉換;它通過修改請求報文的目標IP地址（同時可能會修改目標埠)挑選出某Real Server的RIP地址實現轉發； 在LVS負載均衡排程器上請求先發送給PREROUTING-->INPUT，然後經由監聽在INPUT上的LVS程式強制將請求轉發給POSTROUTING
資料報文流向：
客戶端請求報文傳送給Director此時源IP為CIP，目標IP為VIP,然後經過nat轉換源IP不變仍然為CIP目標IP變為RIP，之後Real Server返回的報文源IP為RIP目標IP為CIP，然後經過Director源IP變為VIP目標IP變成CIP
注意事項：
（1）RS和DIP應該使用私網地址，且RD的閘道器要指向DIP；
（2）請求和響應報文都要經由director轉發；極高負載的場景中，director可能會成為系統瓶頸；
（3）支援埠對映；
（4）RS可以使用任意OS;
(5) RS的RIP和Director的DIP必須在同一IP網路；
2. LVS-DR:
當資料到達LVS負載均衡排程器時，不更改目標IP地址（VIP地址），而是更改目標mac地址，將目標mac換成挑選出的real server的mac地址，（mac是由direct通過ARP廣播獲取），然後將報文返還給交換機，減緩及根據目標mac地址將報文傳送給挑選出的Real Server。Real Server接受到報文後拆封裝，此時源IP為CIP目標IP為VIP，但是因為Real Server自身配置了兩個IP地址。一個RIP,一個VIP所以可以正常接受報文， 其中排程器通過DIP網絡卡發出的對RIP地址請求取得各Real Server的mac地址
問題：real server的RIP要跟排程器的DIP在同一網段，地址的閘道器要如何配置？此時資料報文在返回響應時由於Linux主機特性報文經由那個網絡卡發出源地址就是哪個網絡卡上配置的地址？那響應報文的源地址就不能是VIP這一特性了。
將VIP配置在Real Server的本地迴環地址上面，當資料報文傳送到Real Server後，先到達RIP地址，然後解封裝，發現是迴環地址，後發給迴環地址上配置VIP地址，然後發給程式程序，程式程序在處理完任務後原本是要講響應報文傳送給Real Server的RIP地址，但是現在強制將報文傳送給迴環地址上的VIP，然後由迴環地址傳送給DIP，此時就相當於資料響應報文從迴環地址的VIP地址
注意事項：
(1)保證前端路由器將目標IP為VIP的請求報文傳送給排程器;
解決方案：
靜態繫結，在ARP地址表中將VIP地址跟director網絡卡的mac繫結
修改RS（real server）主機核心的引數
（2）RS的RIP可以使用私有地址：但也可以使用公網地址；
（3）RS跟Director必須在同一物理網路中；
（4）請求報文經由排程器排程，但響應報文一定不能經由排程器;
(5) 不支援埠對映；
（6）RS可以是大多數OS;
(7) RS閘道器不能指向DIP；
3.LVS-TUN:
不修改請求報文的ip首部，而是通過在原有的ip首部(cip<-->vip)外，在封裝一個ip首部(dip<-->rip)；請求報文傳送給排程器此時源IP為CIP，目標IP為VIP,然後排程器將此報文在封裝一層，源IP為DIP,目標IP為RIP，經請求報文傳送給Real Server,然後拆封裝，之後發現目標IP為VIP，所以Real Server要配置兩個地址，同樣的要將VIP配置在迴環地址上面。
注意事項：
(1) RIP,DIP,VIP全得是公網地址；
（2）RS的閘道器不能指向DIP；
（3）請求報文必須經由director排程，但響應報文必須不能經由director；
（4）不支援埠對映
（5）RS的OS必須支援隧道功能；
4. LVS-FULLNAT:
排程器通過同時修改請求報文的目標地址和源地址進行轉發；
資料報文流向：
請求報文傳送給Director此時源IP為CIP，目標IP為VIP,然後經過nat轉換源IP變為DIP目標IP變為RIP，之後real server返回的請求源ip為RIP目標IP為DIP經過Director源ip變為VIP目標ip變成CIP
注意事項：
（1）VIP是公網地址；RIP和DIP是私網地址，二者無須在同一網路中；
（2）RS接收到請求報文的源地址為DIP，因此要響應給DIP；
（3）請求報文和響應報文都必須經由Director；
（4）支援埠對映機制；
（5）RS可以使用任意OS;
session資訊的儲存：
http是無狀態協議，而同一賬戶在訪問相同的伺服器的資源時要想獲取以前保留的資源，必須要建立並儲存session(伺服器端儲存的客戶端會話狀態)資訊。
session保持的幾種方法:
session繫結：來自於同一個使用者的請求始終定向至同一個Real Server
source ip hash會話表經發送請求的源IP跟Real Server對應儲存起來
cookie hash客戶端傳送請求在程序級別插入cookie用以表示
session叢集:
叢集中每一臺主機都有擁有全叢集中所有主機用的session資訊
session伺服器：
將session資訊用KV的方式存在快取伺服器中
LVS 負載均衡排程演算法:
靜態方法：僅根據演算法本身進行排程
RR:round robin,輪調
WRR：weighted rr,
SH:source hash,實現session保持的機制；將來自同一個IP的請求始終排程至同一RS;
DH:destination hash,將對同一個目標的請求始終發往同一個RS;
動態方法：根據演算法及各RS的當前負載狀態進行排程；
Overhead：伺服器權重
LC:Least Connection
Overhead=Active*256+Inactive；挑選出最小值的一臺主機為挑選出的主機
WLC：Wrighted LC
Overhead=(Active*256+Inactive)/weight
SED:Shortest Expection Delay
Overhead=(Active+1)*256/weight
NQ:Never Queue
SED演算法的改進；
LBLC：Locality-Based LC,即為動態的DH演算法；
正向代理情形下的cache server排程；
LBLCR：locality-Based Least-Connection withRelication,帶複製功能的LBLC演算法；