之前簡單介紹LVS負載均衡的高可用方案實施，下面詳細說明LVS的session解決方案：
LVS算法中，SH算法可以實現將同一客戶端的請求總是發送給第一次指定的RS，除非該RS出現故障不能再提供服務。其實在LVS集群中，持久連接功能也能在一定時間內，將來自同一個客戶端請求派發至此前選定的RS，而且是無關算法的。
持久連接是什么？
1）在LVS中，持久連接是為了用來保證當來自同一個用戶的請求時能夠定位到同一台服務器。
2）為什么會用到持久連接？
2.1）cookie/session機制的簡單說明： 在Web服務通信中，HTTP本身是無狀態協議，不能標識用戶來源，此時出現了一個問題，當用戶在一個網站瀏覽了A網頁並跳轉到B網頁，此時服務器就認為B網頁是一個新的用戶請求， 那么用戶之前的登陸的信息就都丟失了！為了記錄用戶的會話信息，開發者就在客戶端/服務器端軟件提供了cookie/session機制，當用戶訪問網站時，服務器端建立一個session會 話區，並建立一個cookie與這個session綁定，將信息發送給用戶的瀏覽器。這樣，只要用戶的cookie存在，服務器端的session存在，那么當用戶打開新頁面的時候，服務器依然會 認識用戶！
2.2）cookie/session由負載均衡導致的問題： 上面說服務器需要靠session/cookie來標記用戶的會話，這沒什么問題。不過，當用戶在做了負載均衡的時候，就出現了問題。 我們依然假設一個場景：某電商網站為了實現更多用戶的訪問，提供了A、B兩台服務器，並在前面做了LVS負載均衡。於是某用戶打開了某購物網站，選中了一件衣服，並加入了購物 車(此時背后的操作是：LVS負載均衡器接受了用戶請求，並將其分發到了選中的服務器，並將用戶添加了一件衣服記錄到這個會話的session中)。這時當用戶打開了第二個網頁，又 選中了一件帽子並加入購物車(此時背后的操作是：LVS負載均衡器接受了用戶請求，進行計算，將其發送到選中的服務器上，該服務器將用戶添加了一件帽子記錄到session中)。 到現在可能各位已經發現問題了，由於LVS是一個四層負載均衡器，僅能根據IP:Port對數據報文進行分發，不能確保將同一用戶根據session發往同一個服務器，也就是用戶第一次被 分配到了A服務器，而第二次可能分配到了B服務器，但是B服務器並沒有A服務器用戶的session記錄，直接導致這個例子里的用戶發現自己的購物車沒有了之前的衣服，而僅有帽子。這是不可接受的。 為了避免上面的問題，生產環境中一般有三種方案： 2.2.1）將來自於同一個用戶的請求發往同一個服務器 2.2.2）將session信息在服務器集群內共享，每個服務器都保存整個集群的session信息 2.2.3）建立一個session存儲池，所有session信息都保存到存儲池中 顯然，第一種方案是最簡單，也是最節約資源的，而持久連接和sh算法就是實現第一種方案的兩種方式。
3）LVS的sh算法和持久連接：
sh算法全稱為source hash（源地址hash），它和持久連接的作用都是"將來自同一個IP的請求都轉發到同一個Server"，從而保證了session會話定位的問題。兩者的不同是： 3.1）sh算法：使用SH算法，SH算法在內核中會自動維護一個哈希表，此哈希表中用每一個請求的源IP地址經過哈希計算得出的值作為鍵，把請求所到達的RS的地址作為值。 在后面的請求中，每一個請求會先經過此哈希表，如果請求在此哈希表中有鍵值，那么直接定向至特定RS，如沒有，則會新生成一個鍵值，以便后續請求的定向。但是此種 方法在時間的記錄上比較模糊（依據TCP的連接時長計算），而且其是算法本身，所以無法與算法分離，並不是特別理想的方法。 3.2）持久連接：此種方法實現了無論使用哪一種調度方法，持久連接功能都能保證在指定時間范圍之內，來自於同一個IP的請求將始終被定向至同一個RS，還可以把多種 服務綁定后統一進行調度。 詳細一點說：當用戶請求到達director時。無論使用什么調度方法，都可以實現對同一個服務的請求在指定時間范圍內始終定向為同一個RS。在director內有一個LVS持久 連接模板，模板中記錄了每一個請求的來源、調度至的RS、維護時長等等，所以，在新的請求進入時，首先在此模板中檢查是否有記錄（有內置的時間限制，比如限制是 300秒，當在到達300秒時依然有用戶訪問，那么持久連接模板就會將時間增加兩分鍾，再計數，依次類推，每次只延長2分鍾），如果該記錄未超時，則使用該記錄所指向 的RS，如果是超時記錄或者是新請求，則會根據調度算法先調度至特定RS，再將調度的記錄添加至此表中。這並不與SH算法沖突，lvs持久連接會在新請求達到時，檢查 后端RS的負載狀況，這就是比較精細的調度和會話保持方法。
4）LVS的三種持久連接方式：
在基於SSL的加密https協議中，特別需要用到持久連接，因為客戶端需要與服務器進行交換證書並協商加密算法等。 如果一個集群中提供了兩種服務，持久連接會將同一客戶端的所有請求都同步到同一RS。持久連接分三種： 4.1）PCC（持久端口連接）：每客戶端持久；將來自於同一個客戶端的所有請求統統定向至此前選定的RS；也就是只要IP相同，分配的服務器始終相同。
4.2）PPC（持久客戶端連接）：每端口持久；將來自於同一個客戶端對同一個服務(端口)的請求，始終定向至此前選定的RS。例如：來自同一個IP的用戶第一次訪問 集群的80端口分配到A服務器，25號端口分配到B服務器。當之后這個用戶繼續訪問80端口仍然分配到A服務器，25號端口仍然分配到B服務器。
4.3）PFMC：持久防火牆標記連接；將來自於同一客戶端對指定服務(端口)的請求，始終定向至此選定的RS；不過它可以將兩個毫不相干的端口定義為一個集群服務， 例如：合並http的80端口和https的443端口定義為同一個集群服務，當用戶第一次訪問80端口分配到A服務器，第二次訪問443端口時仍然分配到A服務器。
5）定義LVS持久連接：
LVS的持久連接功能需要定義在集群服務上面，使用-p timeout選項。
5.1）定義PPC： [root@localhost ~]# ipvsadm -At 192.168.10:80 -s rr -p 300 上面命令的意思是：添加一個集群服務為192.168.10:80，使用的調度算法為rr，持久連接的保持時間是300秒。當超過300秒都沒有請求時，則清空LVS的持久連接模板。 5.2）定義PCC： [root@localhost ~]# ipvsadm -A -t 192.168.10.200:0 -s rr -p 600 [root@localhost ~]# ipvsadm -a -t 192.168.10.200:0 -r 192.168.1.10 -g -w 2 [root@localhost ~]# ipvsadm -a -t 192.168.10.200:0 -r 192.168.1.20 -g -w 1 5.3）定義PFMC： ######PNMPP是通過路由前給數據包打標記來實現的 [root@localhost ~]# iptables -t mangle -A PREROUTING -d 192.168.10.200 -eth0 -p tcp --dport 80 -j MARK --set-mark 3 [root@localhost ~]# iptables -t mangle -A PREROUTING -d 192.168.10.200 -eth0 -p tcp --dport 443 -j MARK --set-mark 3 [root@localhost ~]# ipvsadm -A -f 3 -s rr -p 600 [root@localhost ~]# ipvsadm -a -f 3 -r 192.168.1.10 -g -w 2 [root@localhost ~]# ipvsadm -a -f 3 -r 192.168.1.20 -g -w 2
6）持久連接模板查看：
LVS的持久連接又集群的持久連接模板（一個內存緩沖區）提供；該持久連接模板保存着每一個客戶端及分配給它的RS的映射關系。使用如下命令可以查看該模板： [root@localhost ~]# ipvsadm -L -c IPVS connection entries pro expire state source virtual destination TCP 01:56 FIN_WAIT 192.168.10.200:51822 172.16.1.253:http 172.16.1.102:http TCP 01:57 FIN_WAIT 192.168.10.200:51825 172.16.1.253:http 172.16.1.101:http TCP 01:56 FIN_WAIT 192.168.10.200:51821 172.16.1.253:http 172.16.1.101:http 配置並啟用lvs集群的持久連接： 基本語法： # ipvsadm -A|E ... -p timeout timeout: 持久連接時長，默認300秒；單位是秒； 啟用持久連接： [root@localhost ~]# ipvsadm -L -n IP Virtual Server version 1.2.1 (size=4096) Prot LocalAddress:Port Scheduler Flags -> RemoteAddress:Port Forward Weight ActiveConn InActConn TCP 172.16.1.253:80 wlc -> 172.16.1.101:80 Route 5 0 1 -> 172.16.1.102:80 Route 5 0 2 [root@localhost ~]# ipvsadm -E -t 172.16.1.253:80 -p 600 [root@localhost ~]# ipvsadm -L -n IP Virtual Server version 1.2.1 (size=4096) Prot LocalAddress:Port Scheduler Flags -> RemoteAddress:Port Forward Weight ActiveConn InActConn TCP 172.16.1.253:80 wlc persistent 600 -> 172.16.1.101:80 Route 5 0 0 -> 172.16.1.102:80 Route 5 0 1 此時再次刷新客戶端，會發現已經不會再改變RS。 [root@localhost ~]# ipvsadm -L --persistent-conn IP Virtual Server version 1.2.1 (size=4096) Prot LocalAddress:Port Weight PersistConn ActiveConn InActConn -> RemoteAddress:Port TCP 172.16.1.253:http wlc persistent 600 -> 172.16.1.101:http 5 0 0 0 -> 172.16.1.102:http 5 1 0 14