參考
http://www.ducea.com/2008/06/16/lvs-persistence/
http://zh.linuxvirtualserver.org/node/2487
http://shaguangzhaojiaren.blogspot.com/2017/12/lvs30.html
http://zh.linuxvirtualserver.org/node/2903
https://cloud.tencent.com/developer/article/1355733
一、lvs介紹
1.1 基礎概念
VIP：virtual IP，LVS伺服器上接收外網資料包的網卡IP位址
DIP：director IP，LVS伺服器上轉發資料包到realserver的網卡IP位址，用于和内部主機進行通訊
RIP：realserver(常簡稱為RS)上接收Director轉發資料包的IP，即提供服務的真實伺服器IP。
CIP：用戶端的IP
1.2 lvs 三種模式
DR模式
NAT模式
TUN模式
備注下：
masquerade(masquerade 看成是更新版本的nat,普通的nat在iptables裡面指定的位址是靜态的， masquerade可以動态的擷取本地的ip,然後做位址轉換 )
1.3 lvs 排程算法
可分為靜态算法和動态算法
靜态算法
rr：輪詢排程（Round-Robin Scheduling,rr）
wrr：權重輪詢排程（Weighted Round-Robin Scheduling,wrr），權重大的多分發請求，權重小的少分發請求
sh：源位址散列排程，對源位址哈希，在一定時間内，同一個用戶端的請求，被發送到同一個RS上
dh：目的位址散列排程，對目标位址哈希，在一定時間内，發往同一目标IP的請求，被發送到同一個RS上
動态算法
lc：最少連接配接排程（Least-Connection Scheduling,lc）
此算法會根據後端每台RS的連接配接數多少來分發請求，對于連接配接數少的伺服器，會多分發用戶端請求，以盡可能利用資源占用少的機器。當後端各個伺服器的處理能力不同時，該算法不理想。
wlc：權重最小連接配接排程（Weighted Least-Connection Scheduling,wlc）
動态的擷取後端不同伺服器的真實負載情況，并調整對應的權重值，進而保證将請求分發到性能優異且較空閑的機器，進而提高處理效率。
sed：Shortest Expect Delay
最短期望延遲；此算法是對WLC的一種改進
nq：Never Queue，永不排隊算法
此種算法，當用戶端請求到達時，會首先根據SED算法進行選擇一個RS，然後把請求配置設定給這個伺服器，同時從算法清單中将此台伺服器排除，下次請求到達時，隻會在剩下的伺服器清單中根據SED進行選擇，等到每一台主機都配置設定到連接配接後，排程器此後每次都會根據SED算法在所有的伺服器中進行計算選擇；
lblc：基于局部性的最連結（Locality-Based Least Connections）
“基于局部性的最少連結”排程算法是針對目标IP位址的負載均衡，目前主要用于Cache叢集系統。該算法根據請求的目标IP位址找出該目标IP位址最近使用的伺服器，若該伺服器是可用的且沒有超載，将請求發送到該伺服器；若伺服器不存在，或者該伺服器超載且有伺服器處于一半的工作負載，則用“最少連結” 的原則選出一個可用的伺服器，将請求發送到該伺服器。
lblcr ：帶複制的基于局部性最少連結（Locality-Based Least Connections with Replication）
“帶複制的基于局部性最少連結”排程算法也是針對目标IP位址的負載均衡，目前主要用于Cache叢集系統。它與LBLC算法的不同之處是它要維護從一個目标 IP位址到一組伺服器的映射，而LBLC算法維護從一個目标IP位址到一台伺服器的映射。該算法根據請求的目标IP位址找出該目标IP位址對應的伺服器組，按“最小連接配接”原則從伺服器組中選出一台伺服器，若伺服器沒有超載，将請求發送到該伺服器；若伺服器超載，則按“最小連接配接”原則從這個叢集中選出一台伺服器，将該伺服器加入到伺服器組中，将請求發送到該伺服器。同時，當該伺服器組有一段時間沒有被修改，将最忙的伺服器從伺服器組中删除，以降低複制的程度。
最近公司上線了緩存叢集伺服器，但是還依舊選擇了wrr算法，使得線上流量配置設定不均勻，現調研lblc負載均衡算法在做算法時的可行性。
LVS的負載均衡算法，不同的應用場景，應選擇合适的負載均衡算法，充分了解每一種算法背後的思想，才能更好的做出選擇。
二、 LVS持久化連接配接
2.1 持久化連接配接使用
使用方法： ipvsadm -p
功能：無論ipvs使用何種排程算法，都會将來自同一個client的所有連接配接請求始終定向至第一次排程時挑選出的後端RS。
如果不設定，則持久化連接配接的預設逾時時間為300秒
持久連接配接模闆：獨立于排程算法(而且優先于 排程算法)
預設情況下是 持久化 client ip來的連接配接，也可以設定netmask,将同一網段的client ip的連接配接重定向到同一個後端RS上
-M, —netmask netmask = Specify the granularity with which clients are grouped for persistent virtual services. The source address of the request is masked with this netmask to direct all clients from a network to the same real server. The default is 255.255.255.255, that is, the persistence granularity is per client host. Less specific netmasks may be used to resolve problems with non-persistent cache clusters on the client side.
example：
ipvsadm -A -t VIP:80 -p 3600 -s -wrr -M 255.255.255.0
ipvsadm -a -t VIP:80 -R RS1 -g -w 1
ipvsadm -a -t VIP:80 -R RS2 -g -w 1
2.2 持久化連接配接的分類
對于LVS的持久連接配接來說常見的分為三種PCC,PPC和基于防火牆标記的持久連接配接，下面我們就來分别讨論
PCC（persistent client connections 不常用）： 同一個client ip 到 同一個vip 的所有通路都會排程到同一台RS
|
開啟PCC政策，使用ipvsadm添加service和server時，指定端口為0即可，實際環境中并不常用
PPC（persistent port connections 常用）：就是 同一個 client ip 到同一個 vip+port 的所有通路會排程到同一台RS
|
80端口代表http服務，22端口代表ssh服務，是以PPC政策保證的是：
同一個使用者在逾時時間内對于某個服務的通路都會被重定向到同一台RS上
PFWMC政策（不常用）：基于防火牆标記的持久化連接配接
對于電子商務網站來說，使用者在挑選商品的時候使用的是80端口來浏覽的，當付款的時候則是通過443的ssl加密的方式，當然當使用者挑選完商品付款的時候我們當然不希望https的443跳轉到另外一台REALSERVER，很顯然應該是同一REALSERVER才對，這時候就要用到基于防火牆标記的持久連接配接，通過定義端口的姻親關系來實作
2.3 持久化連接配接查詢和顯示
ipvsadm -Ln --persistent-conn
PersistConn:持久化連接配接數量，到了逾時時間的連接配接會被删除
ActiveConn：活躍連接配接數，即處于ESTABLISHED狀态的tcp連接配接
InActConn：不活躍連接配接數，即除了ESTABLISHED狀态的tcp連接配接，剩餘的tcp連接配接都計算在不活躍連接配接數中
當時定位問題過程中，發現ActiveConn會比通過netstats看到的ESTABLISHED值高很多，而且數值一直增加，這是怎麼回事呢？
LVS自身對tcp和udp有預設逾時時間，一條tcp的連接配接經過lvs後,lvs會把這台記錄預設儲存15分鐘,而不管這條連接配接是不是已經失效!
是以如果你的伺服器在15分鐘以内有大量的并發請求連進來的時候,你就會看到這個數值直線上升.
2.4 持久化連接配接的實作原理
當一個client ip通路VIP時，ipvs會添加一條狀态為NONE的記錄到connection template哈希表中，記錄的key是clientip，記錄的儲存時間是persistent timeout值，
在逾時時間内，這條記錄都存在于connection template哈希表。
後續同一個client ip通路VIP時，會到connection template哈希表查找clientip是否存在，如果存在記錄則會将其轉發到後端的同一台RS。
三、LVS連接配接追蹤
在某些應用場景中，LVS需要基于“連接配接追蹤”實作将由同一個客戶機的請求始終發往其第一次被配置設定至的RS，以保證其請求的完整性等。lvs内部除了connection template持久連接配接表外，還維護了一個名為timeout_table的哈希表。
使用指令 ipvsadm -lcn顯示目前lvs中的連接配接資訊
FIN_WAIT狀态和NONE狀态解析
FIN_WAIT的值就是tcpfin的逾時時間，當NONE的expire值為0時，對應項的FIN_WAIT還存在，那麼NONE的expire值會重新變成60秒再繼續減少，一直到FIN_WAIT消失以後，NONE才會消失，隻要NONE存在，同一client的通路，都會配置設定到同一RS上。
ASSURED狀态
connection template持久化連接配接表的狀态分為兩種NONE和ASSURED，ASSURED是一個正常狀态。
Add support for state bits
and for the first "assured" bit which indicates that some
connection controlled by this template was established or assured
by the real server. In a followup patch we will use it to drop
templates under SYN attack. 看送出patch的說明，這個狀态的作用，是在遭受SYN攻擊時，通過ASSURED狀态，來棄用connection template持久化連接配接表
擷取tcp和udp的timeout值，可以用一下指令檢視
ipvsadm -L --timeout
為了保證其時效性，Hash table中“連接配接追蹤”資訊被定義了“生存時間”。
LVS為記錄“連接配接逾時”定義了三個計時器：
1、空閑TCP會話（建立連接配接後，無資料收發）
2、用戶端正常斷開連接配接後的TCP會話；
3、無連接配接的UDP資料包（記錄其兩次發送資料包的時間間隔）；
上面三個計時器的值可以用–set參數來修改，其後面的值依次對應于上述的三個計時器：
ipvsadm --set 28800 30 600
四、LVS高可用
一般來說，會在Director上運作service monitor，定期檢查後端server是否健康
如果在指定時間内，後端server對于通路請求或icmp ECHO_REQUEST 都無響應，service monitor會認為後端server deaded（不可用），會把它從Director的server清單中删除，新的請求将不會再轉發給它。
當service monitor檢測到後端server正常工作了，會将其重新加會可用server清單。
主備模式
primary backup
一定時間内沒收到primary的心跳資訊，backup将接管VIP，提供負載均衡服務。
當失敗的load balancer 恢複工作後，有兩種解決方法
1.自動成為backup load balancer
2.active load balance釋放VIP，新恢複的機器重新接管VIP，提供負載均衡服務。
現線上上使用的lvs + keepalived的模式來實作高可用服務。
五、其他方面
fwm:
firewall mark
在 prerouting chain 給連接配接打上标記， 後面lvs 更具規則排程打上特定标記的包 (man iptables extension)
example:
将2個服務 的連接配接打上 相同的标記:10
iptables -t mangle -A PREROUTING -p tcp -d $VIP --dport 80 -j MARK --set-mark 10 (10是标記)
iptables -t mangle -A PREROUTING -p tcp -d $VIP --dport 22 -j MARK --set-mark 10 (10是标記)
ipvs:
ipvsadm -A -f 10 -s rr //不需要指定 port
ipvsadm -a -f 10 -r $RIP1 -g
ipvsadm -a -f 10 -r $RIP2 -g
netfilter:
PREROUTING --> INPUT (lvs 在 INPUT chain 幹活) --> POSTROUTING
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.由于Director Server和RS在同一個網絡中，是以是通過二層來傳輸。