LVS之DR模型以及持久連接
LVS的簡單介紹
linux virtual server
簡單來講lvs是一段內核代碼 類似於netfilter本身是一框架但不提供任何功能，但是在這框架上提供了能夠根據用戶定義的轉發規則將用戶對於服務應用的請求轉發至後端主機的機制，類似於DNAT
但DNAT只是其提供的一種工作模式
LVS的工作模式
lvs是工作在內核中的第四層（TCP/UDP）層
能夠處理用戶請求的套接字，而後只判定用戶是否訪問了定義爲集羣服務的應用
在lvs中就好比DNAT，並非將每個請求都轉換至後端只是某個特定的條件
在內核2.4.22之後ipvs直接被收錄進內核源碼樹了，只要啓用了相關功能就可以直接拿來使用了
ipvs相當於工作在netfilter中的input鏈
當用戶的請求到達主機內部，如果沒有做DNAT經過路由之後就到達input了，再經過input就到達用戶空間中，而ipvs就工作在input鏈上，隨時監控着通過input隨時發往本機的應用請求，而後可以接受用戶所定義的集羣服務規則，所以一旦請求到達input鏈上的服務是請求的集羣服務的話，那麼本來應該送到本機內部（用戶空間）的報文，但是強行扭轉到postrouting直接到達後端realserver上
所以ipvs和iptables的機制不能同時使用，否則會出現問題。
LVS術語
調度器： Director、Load Balancer
後端主機： RealServer
RealServer 的IP： RIP
Director 的IP： DIP
客戶端：CIP
其工作流程的走向：CIP<-->CIP<-->DIP<-->RIP
LVS的工作模式
NAT模式
類似於DNAT，只不過比DNAT多了幾個後端節點
用戶的請求到達的前端的調度器，調度器本身不提供服務，只是提供某種方法從後端realserver中挑選出一個服務角色來響應用戶請求，這些服務器是隱藏在調度器背後的，因此他們是通過地址轉換，將用戶請求逐個分發到後端realserver，當用戶的請求被realserver處理了之後，這個請求需要將請求再次發給調度器，再由調度器封裝報文（源VIP 目標CIP）發送給client
無論是客戶的請求還是服務端的響應都必須經過調度器（director）
如果調度器的併發量非常大的話，（請求非常小，響應比較大）如果後端的relaserver非常的多，調度器可能會成爲性能瓶頸的，因爲調度器本身也需要大量的系統資源來響應用戶的請求（CPU+網絡吞吐）
其好處：只需要一個公網地址即可響應用戶的請求
NAT模式特性總結：
·.realserver應該使用私有ip地址
·一般realsever的網關應該指向DIP，不然的話無法保證響應報文經過director
·RIP要和DIP應該在同一網段內
·進出的報文，無論請求還是響應都要經過Directory
·支持端口映射
·realserver可以使用任意系統，只要端口對應即可
在高負載下，directory可能會成爲性能瓶頸，所以不使用於併發很高的應用場景
在nat模式下在集羣節點下經過哪些鏈：
當一個請求到達的時候，請求剛進入本地會到prerouting，而後目標地址就是本機vip地址，於是送往input鏈，但是在input鏈上工作的有ipvs，而且ipvs會有規則結果會分發到postrouting
NAT模型回覆的報文會經過prerouting ，目標地址是CIP所以通過preting到達fowward到postrouting並返回給用戶
其報文走向流程：
入站報文：prerouting--> input(強行改變流程) --> postrouting
出站報文：響應時候先進行prerouting--> forward --> postrouting
TUN（隧道）模式
隧道模式則類似於×××的方式,使用網絡分層的原理
TUN的工作流程：
用戶發來的數據包的基礎上,封裝一個新的IP頭標記(此IP頭只有目的IP部) 發給REALSERVER
REALSERVER收到後,先把Director發過來的數據包的頭給解開,還原其數據包原樣,處理後,直接返回給客戶端,而不需要再經過Director
需要注意的是：由於REALSERVER需要對DR發過來的數據包進行還原,也就是說必須支持IPTUNNEL協議所以,在 REALSERVER的內核中,必須編譯支持IPTUNNEL這個選項
DR模式工作流程：
·用戶通過訪問其域名解析到其IP地址（VIP）
·用戶向目標VIP發送請求，這是Director接收到請求，此時源IP是用戶的IP地址，其目標MAC是Director的MAC地址
·LVS會根據其相關算法選擇一臺active的服務器，將此RIP所在網卡的MAC地址作爲目標的MAC地址，此時源MAC地址是Director的MAC地址，目標MAC地址是realserver的MAC地址
·realserver收到了數據包，並且分析數據包，如果發現目標IP地址（VIP）與本地的lo（環回接口）匹配，於是就會處理這個報文，廣播到LAN中，此時源MAC地址是realserver的MAC地址，目標IP地址是用戶的IP
其特性：
·realserver可以使用私有地址，但建議使用公網地址，
·realserver的網關一定不能指向DIP，否則沒有意義了
·RIP和DIP要在同一物理網絡內，一定不能跨越路由設備的
·入站報文經過directory，出站則由realserver直接響應
·不能做端口映射
·realserver必須綁定lo地址，跨越支持大多數常見OS
DR模型限定了主機必須在同一物理網絡內
LVS的八種算法：（參考科卡在線教材）
（1）輪叫（Round Robin）
簡寫：RR。調度器通過「輪叫」調度算法將外部請求按順序輪流分配到集羣中
的真實服務器上，它均等地對待每一臺服務器，而不管服務器上實際的連接數和系
統負載。
（2）加權輪叫（Weighted Round Robin）
簡寫：WRR。調度器通過「加權輪叫」調度算法根據真實服務器的不同處理能
力來調度訪問請求。這樣可以保證處理能力強的服務器處理更多的訪問流量。調度
器可以自動問詢真實服務器的負載情況，並動態地調整其權值。
（3）最少鏈接（Least Connections）
簡寫：LC。調度器通過「最少連接」調度算法動態地將網絡請求調度到已建立
的鏈接數最少的服務器上。如果集羣系統的真實服務器具有相近的系統性能，採用"
最小連接"調度算法可以較好地均衡負載。
lc算法與rr相反，無論請求的發往哪個realserver，只考慮哪個realserver最空閒，將請求發往最空閒的realserver，所以對比起靜態算法不考慮realserver當前的連接數，但是動態需要計算realserver的連接數來判定選擇realserver
一般處於established狀態都爲活動連接而其他狀態一律被視爲非活動連接
如何評估連接數：
對於一個服務器來講，非活動連接數的資源的開銷比活動連接要小的多，比如nginx維持1W非活動連接數只需要3M足以，所以非活動鏈接數開銷非常小，由此做評估的時候不僅要考慮活動鏈接還要考慮非活動鏈接只不過活動鏈接佔得比重要大的多
計算活動連接數：
活動鏈接數 X 256 + 非活動連接數
（Active*256+Inactive)誰的值小誰則選擇誰
（4）加權最少鏈接（Weighted Least Connections）
簡寫：WLC。在集羣系統中的服務器性能差異較大的情況下，調度器採用「加
權最少鏈接」調度算法優化負載均衡性能，具有較高權值的服務器將承受較大比例
的活動連接負載。調度器可以自動問詢真實服務器的負載情況，並動態地調整其權值。
（活動鏈接數 X 256 + 非活動連接數)/權重
（Active*256+Inactive）/weiht
wlc是默認的調度算法，說明對於lvs集羣來講，wlc是負載均衡最好的調度算法，但是wlc存在問題，所有有了sed算法
（5）基於局部性的最少鏈接（Locality-Based Least Connections）
簡寫：LBLC。「基於局部性的最少鏈接」調度算法是針對目標IP 地址的負載均
衡，目前主要用於Cache 集羣系統。該算法根據請求的目標IP 地址找出該目標IP
地址最近使用的服務器，若該服務器是可用的且沒有超載，將請求發送到該服務器；
若服務器不存在，或者該服務器超載且有服務器處於一半的工作負載，則用「最少
鏈接」的原則選出一個可用的服務器，將請求發送到該服務器。
（6）帶複製的基於局部性最少鏈接（Locality-Based Least Connections with
Replication）
簡寫：LBLCR。「帶複製的基於局部性最少鏈接」調度算法也是針對目標IP 地
址的負載均衡，目前主要用於Cache 集羣系統。它與LBLC 算法的不同之處是它要
維護從一個目標IP地址到一組服務器的映射，而LBLC 算法維護從一個目標IP 地
址到一臺服務器的映射。該算法根據請求的目標IP 地址找出該目標IP 地址對應的
服務器組，按"最小連接"原則從服務器組中選出一臺服務器，若服務器沒有超載，
將請求發送到該服務器，若服務器超載；則按"最小連接"原則從這個集羣中選出一
臺服務器，將該服務器加入到服務器組中，將請求發送到該服務器。同時，當該服
務器組有一段時間沒有被修改，將最忙的服務器從服務器組中刪除，以降低複製的
程度。
（7）目標地址散列（Destination Hashing）
簡寫：DH。「目標地址散列」調度算法根據請求的目標IP 地址，作爲散列鍵（Hash
Key）從靜態分配的散列表找出對應的服務器，若該服務器是可用的且未超載，將
請求發送到該服務器，否則返回空。
（8）源地址散列（Source Hashing）
簡寫：SH。「源地址散列」調度算法根據請求的源IP 地址，作爲散列鍵（Hash
Key）從靜態分配的散列表找出對應的服務器，若該服務器是可用的且未超載，將
請求發送到該服務器，否則返回空。
lvs集羣DR模型詳解
DR模式工作原理：
（1）當用戶請求到達交換機時，其報文源ip是cip 目標ip是vip
而Director將請求轉發至realserver的時候報文中的源ip是CIP，目標地址是VIP（因爲修改目標MAC）
（2）當報文送到以後它只將目標MAC改爲了RIP所對應的MAC地址（將報文的幀重新交給交換機的時候，交換機會根據目標MAC重新發往realserver，當realserver收到請求之後目標地址由於是VIP，因此爲了讓realserver接收目標地址爲vip的報文，在每個realserver必須配置vip的地址，不然不匹配報文無法接收，也就意味着每個realserver都必須配置vip）
（3）事實上路由器將報文轉發至directory之前要先進行arp廣播請求，arp廣播的意義是將vip轉換爲mac地址，那麼按理來講我們的realserver都配置了vip，也就意味着所有配置vip的主機都能響應其報文，很顯然這麼就亂套了，所以我們就期望進來的請求只到達directory，不然負載均衡就沒有意義了
方案如下：
·前端路由不做解析，明確指定directory
·arp-tables限制響應
（4）當realserver處理完請求後將直接返回給CIP
那麼我們來總結一下：
通告級別
默認情況下，linux發佈通告相當毫無遮掩，將自己的ip及mac地址統統通告出去
響應級別
通告完之後通常對方知道我們的mac和ip，於是將mac和ip的地址緩存至本地，爲了保證其地址的有效性通常緩存都是有一定的週期時間，一般來講是360（官方文檔說明是300秒，但ipvs顯示的是360秒）秒，當360秒之後如果雙方沒有進行任何通信，那麼則將緩存清空，假設經過一定時間內要進行雙方通信，但在arp列表裏沒有緩存，則再次進行發送廣播，對方收到之後則對其響應，並將mac地址響應給對方，並且響應方式也是廣播的
通告/響應級別是可以通過linux內核級別來調整的
在kernel2.4.26之後所具備的兩個設備標誌，我們被稱爲設備網卡的識別標識
用於調整arp協議棧的工作模式的
arp_ignore 用於定義通告限制級別
arp_annouce 用於定義響應級別
arp_announce
共有3個值：
0：默認值，表示默認情況下只要主機接入至網絡中，它會把每個接口以及接口IP和mac對應關係向本地網絡通告
1：儘可能避免不將地址通告本地網絡
2：只通告直連接口到本地網絡
一般模式選擇2
arp_ignore
共有8個值，重點是1
0：只要本地網絡有此ip則直接通告
1：僅接收在本地接口的ip地址
因此，我們所需要的值就是
arp_ignore=1
arp_announce=2
禁止RS上的vip直接跟前端路由通信的三種方案
1.修改路由，使用靜態arp
2.在RS上使用arptables 禁止響應對vip的廣播請求
3.在RS上修改其內核參數，並將vip配置在與RIP不同的接口的別名上比如lo:0
通常代價比較低，用的比較廣泛的是第三種方案，直接綁定lo環回地址
linux還有一種特性，儘管配置了vip也禁止了vip的響應請求，當請求報文到達以後，realserver要對其封裝響應，響應直接發送至客戶端，這時我們需要考慮兩個問題：
1:響應報文從哪個接口出去，則將哪個接口的地址當做源地址，報文響應出去的時候其源地址是RIP，但CIP一定是期望VIP響應的
（過程中會通過一條特定的路由設定來實現），
2.如果rip vip dip都在同一網段內，那麼可以輕鬆實現，直接將網關指向路由即可
但如果rip、dip不跟vip在同一網絡內，無論如何各realserver的網關一定不能指向directory，必須要準備另一個路由設備，比如將網關指向與RIP在同一網段內
最終外網接口有可能通過其他路由到達互聯網也有可能到達出口路由器，前提是必須能與RIP進行通信纔可以
如果在生產環境內只有一個公網ip其餘的使用私有ip，所以只能用公網ip當做vip，既然只有一個公網ip，那麼rip和dip都是私有地址，與vip不在同一網段，所以這時候必須要配置一個本地網關，通過地址轉換（路由）到互聯網中去
安裝IPVS
查看linux編譯的時候是否支持ipvs
[[email protected] ~]#grep -i 'ipvs' /boot/config-3.2.0-4-amd64
CONFIG_NETFILTER_XT_MATCH_IPVS=m
# IPVS transport protocol load balancing support
# IPVS scheduler
# IPVS application helper
安裝ipvs
[[email protected] ~]# yuminstall -y ipvsadm
ipvs常用命令參數
#man ipvsadm
ipvsadm -A|E -t|u|f service-address [-s scheduler]
[-p [timeout]] [-M netmask]
-A: 添加、新建
-E：編輯
-t: 指定tcp協議
-u：指定UDP協議
-f:firewal mark
-s: 指定調度算法
ipvsadm -D -t|u|fservice-address
-D：刪除
ipvsadm -a|e -t|u|fservice-address -r server-address
[-g|i|m] [-w weight] [-x upper] [-y lower]
-a：添加realserver
-r：指定realserver地址，一般ip+端口，只在端口映射的時候才指端口
-g：指定lvs默認的模型，dr模型
-i：tun模型
-m：nat模型
-w：定義權重
添加集羣
ipvsadm -a -t ip:80-r getwaryip -m
刪除ip
ipvsadm -d -t ip:80-r server-address
ipvsadm -d -t ip:80-r dip
保存規則
server ipvsadm save
默認路徑在/etc/sysconfig/ipvsadm
保存指定路徑
ipvsadm -S >/path/to/xxx.txt
ipvsadm -R >/path/to/xxx.txt
開啓轉發
sysctl -wnet.ipv4.ip_forward=1
統計數據
ipvsadm -L -n--stats
配置DR模式
（這裏我們的ipvs爲單點，沒有做keepalived或其他健康檢查機制）
| IP地址 | 服務器角色 |
| 10.0.10.61 | directory |
| 10.0.10.84 | realserver |
| 10.0.10.83 | realserver |
| 10.0.10.100 | VIP |
確保三方可以通信，服務可以啓動
配置vip步驟：
1.將log環回接口配置其vip
2. 確保都在同一網段並設置本地路由（不是網絡路由）
3.在realserv配置2個內核參數
echo 1 >/proc/sys/net/ipv4/conf/lo/arp_ignore
echo 2 > /proc/sys/net/ipv4/conf/lo/arp_announce
echo 1 > /proc/sys/net/ipv4/conf/all/arp_ignore
echo 2 > /proc/sys/net/ipv4/conf/all/arp_announce
#特定配置lo環回接口
每個realserver都需要配置內核參數再去配置vip
指定廣播地址爲自己本機，不對外做任何廣播，說明不需要與任何主機通信，只將在響應客戶端的請求的時候將自己做爲源地址
[[email protected] ~]#ifconfig lo:0 10.0.10.100 broadcast 10.0.10.100 netmask 255.255.255.255 up
[[email protected] ~]#ifconfig lo:0
lo:0 Link encap:Local Loopback
inet addr:10.0.10.100 Mask:255.255.255.255
UP LOOPBACK RUNNING MTU:16436 Metric:1
#爲了使得源地址是VIP還必須加一條路由，如果主機目標地址是vip的，那麼一定要通過lo接口出去
[[email protected] ~]#/sbin/route add -host 10.0.10.100 dev lo:0
這樣以來源地址響應的ip一定是lo:0環回接口
配置directory
要添加路由只不過將vip配置在外網接口的別名上
[[email protected] ~]# /sbin/ifconfig eth0:110.0.10.100 broadcast 10.0.10.100netmask 255.255.255.255 up
[[email protected] ~]#route add -host 10.0.10.100 dev eth0:1
查看路由
[[email protected] ~]#route -n
Kernel IP routingtable
Destination Gateway Genmask Flags Metric Ref Use Iface
10.0.10.100 0.0.0.0 255.255.255.255 UH 0 0 0 eth0
切換至我們的客戶端去ping vip
C:\Users\Administrator>ping10.0.10.100
正在 Ping10.0.10.100 具有 32 字節的數據:
來自 10.0.10.100 的回覆: 字節=32 時間<1msTTL=64
來自 10.0.10.100 的回覆: 字節=32 時間<1msTTL=64
查看arp列表，如下所示vip與其eth0的ip地址是一致的
接口: 10.0.0.1 ---0xd
Internet 地址物理地址類型
10.0.0.255 ff-ff-ff-ff-ff-ff 靜態
10.0.10.61 00-0c-29-d6-6b-a3 動態
10.0.10.83 00-0c-29-46-4b-40 動態
10.0.10.84 00-0c-29-47-55-a4 動態
10.0.10.100 00-0c-29-d6-6b-a3 動態
添加ipvs分發
[[email protected]~]# ipvsadm -A -t 10.0.10.100:80 -s rr
[[email protected]~]# ipvsadm -a -t 10.0.10.100:80 -r10.0.10.83 -g -w 2
[[email protected]~]# ipvsadm -a -t 10.0.10.100:80 -r10.0.10.84 -g -w 2
[[email protected]~]# ipvsadm -l -n
IP Virtual Serverversion 1.2.1 (size=4096)
ProtLocalAddress:Port Scheduler Flags
-> RemoteAddress:Port Forward Weight ActiveConn InActConn
TCP 10.0.10.100:80 rr
-> 10.0.10.83:80 Route 2 0 0
-> 10.0.10.84:80 Route 2 0 0
訪問時，發現已經到達輪詢的結果了（沒刷新一次則變化一次頁面）
因爲這裏是rr算法所以看不出效果，所以需要更改動態算法，並對其進行壓力測試
[[email protected] ~]#ipvsadm -E -t 10.0.10.100:80 -s wlc
[[email protected] ~]# ab-n 1000 -c 30 http://10.0.10.100/index.html
使其RIP與VIP不在同一網段
但如果rip、dip不跟vip在同一網絡內，無論如何各realserver的網關一定不能指向directory，必須要準備另一個路由設備，比如將網關指向與RIP在同一網段內
最終外網接口有可能通過其他路由到達互聯網也有可能到達出口路由器，前提是必須能與RIP進行通信纔可以
如果在生產環境內只有一個公網ip其餘的使用私有ip，所以只能用公網ip當做vip，既然只有一個公網ip，那麼rip和dip都是私有地址，與vip不在同一網段，所以這時候必須要配置一個本地網關，通過地址轉換（路由）到互聯網中去
地址劃分
由於我這裏沒有多餘的虛機，所以只能犧牲一下其中以臺的realserver了
劃分如下：
| IP地址 | 服務器角色 |
| 10.0.10.61 | Directory |
| 10.0.10.84/10.0.0.84 | Router |
| 10.0.0.83 | Realserver |
| 10.0.10.100 | VIP |
配置路由
[[email protected] conf]#ifconfig | grep 'inet addr'
inet addr:10.0.10.84 Bcast:10.0.10.255 Mask:255.255.255.0
inet addr:10.0.0.84 Bcast:10.0.0.255 Mask:255.255.255.0
inet addr:127.0.0.1 Mask:255.0.0.0
開啓轉發
[[email protected] conf]#echo 1 > /proc/sys/net/ipv4/ip_forward
配置realserver
更改ip地址並測試鏈路是否暢通
[[email protected]_test]# ifcccc;"> inet addr:10.0.10.84 Bcast:10.0.10.255 Mask:255.255.255.0
inet addr:10.0.0.84 Bcast:10.0.0.255 Mask:255.255.255.0
inet addr:127.0.0.1 Mask:255.0.0.0
開啓轉發
[[email protected] conf]#echo 1 > /proc/sys/net/ipv4/ip_forward
配置realserver
更改ip地址並測試鏈路是否暢通
[[email protected]_test]# ifconfig eth1 10.0.0.83
[[email protected] ~]#ping -c 1 10.0.0.84
PING 10.0.0.84(10.0.0.84) 56(84) bytes of data.
64 bytes from10.0.0.84: icmp_seq=1 ttl=64 time=0.335 ms
配置靜態路由
[[email protected] ~]#route add default gw 10.0.0.84
[[email protected] ~]#route -n
Kernel IP routingtable
Destination Gateway Genmask Flags Metric Ref Use Iface
10.0.10.100 0.0.0.0 255.255.255.255 UH 0 0 0 lo
192.168.1.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0
10.0.0.0 0.0.0.0 255.0.0.0 U 0 0 0 eth1
0.0.0.0 10.0.0.84 0.0.0.0 UG 0 0 0 eth1
測試跨網段ip是否暢通
[[email protected] ~]# ping10.0.10.84
PING 10.0.10.84(10.0.10.84) 56(84) bytes of data.
64 bytes from10.0.10.84: icmp_seq=1 ttl=64 time=2.42 ms
[[email protected] ~]# ping10.0.10.100
PING 10.0.10.100 (10.0.10.100)56(84) bytes of data.
64 bytes from10.0.10.100: icmp_seq=1 ttl=64 time=0.015 ms
更改DIP
[[email protected] ~]#route add default gw 10.0.10.84
清理規則
[[email protected]~]# ipvsadm -C
重新添加集羣服務
[[email protected] ~]# ipvsadm -A -t10.0.10.100:80 -s wrr
[[email protected]~]# ipvsadm -a -t 10.0.10.100:80 -r10.0.0.83 -g -w 2
[[email protected] ~]#ipvsadm -ln
IP Virtual Serverversion 1.2.1 (size=4096)
ProtLocalAddress:Port Scheduler Flags
-> RemoteAddress:Port Forward Weight ActiveConn InActConn
TCP 10.0.10.100:80 wrr
-> 10.0.0.83:80 Route 2 0 0
確保雙方都能暢通並訪問
lvs持久鏈接
持久連接主要是將同一用戶的不同請求分發至一臺服務器
connectionaffinity連接關聯性
使用其關聯性無論使用什麼方法都可以在外圍捆綁機制上實現持久功能
如何去實現lvs持久鏈接
持久連接必須對其進行連接追蹤，所以要實現端口關聯性的持久性，lvs在內部引進了機制叫做lvs持久鏈接模板（lvs persistent template）
簡單來講就是一內存存儲空間，是一段保存在內存中的哈希表，保存內容無非就是鍵值對（鍵：CIP；值：realserver）
啓動這種功能的時候lvs調度的過程爲：
1.用戶請求80服務於是根據算法選擇了realserver1並且將這對應關係保存在哈希表裏
2.於是第二次同一個請求不管是否是同一客戶端的請求到達後，不是將通過算法調度，而是先去查找內存哈希表，查看是否曾經被分配至某個realserver 不管使用的哪個服務都需要查找內存空間的哈希表
2.如果此前曾經被分配過某個realserver那麼哪怕其訪問的其他服務，都統統被分發到此realserver
所以在實現lvs持久鏈接的時候，先去查內存空間哈希表，只要表中匹配則進行分配
那麼對於非常繁忙的lvs來說 持久鏈接就存在瓶頸，如果有N個客戶端那麼就意味着要建立N個條目
也就意味着內存空間需要充足能容納我們的記錄的條目纔可以，所以在必要的時候要去調整模板的空間大小
定義持久連接機制
持久多長時間超時需要自己按需定義
如果想讓lvs工作在持久連接的模型下�bytes from10.0.10.84: icmp_seq=1 ttl=64 time=2.42 ms
[[email protected] ~]# ping10.0.10.100
PING 10.0.10.100 (10.0.10.100)56(84) bytes of data.
64 bytes from10.0.10.100: icmp_seq=1 ttl=64 time=0.015 ms
更改DIP
[[email protected] ~]#route add default gw 10.0.10.84
清理規則
[[email protected]~]# ipvsadm -C
重新添加集羣服務
[[email protected] ~]# ipvsadm -A -t10.0.10.100:80 -s wrr
[[email protected]~]# ipvsadm -a -t 10.0.10.100:80 -r10.0.0.83 -g -w 2
[[email protected] ~]#ipvsadm -ln
IP Virtual Serverversion 1.2.1 (size=4096)
ProtLocalAddress:Port Scheduler Flags
-> RemoteAddress:Port Forward Weight ActiveConn InActConn
TCP 10.0.10.100:80 wrr
-> 10.0.0.83:80 Route 2 0 0
確保雙方都能暢通並訪問
lvs持久鏈接
持久連接主要是將同一用戶的不同請求分發至一臺服務器
connectionaffinity連接關聯性
使用其關聯性無論使用什麼方法都可以在外圍捆綁機制上實現持久功能
如何去實現lvs持久鏈接
持久連接必須對其進行連接追蹤，所以要實現端口關聯性的持久性，lvs在內部引進了機制叫做lvs持久鏈接模板（lvs persistent template）
簡單來講就是一內存存儲空間，是一段保存在內存中的哈希表，保存內容無非就是鍵值對（鍵：CIP；值：realserver）
啓動這種功能的時候lvs調度的過程爲：
1.用戶請求80服務於是根據算法選擇了realserver1並且將這對應關係保存在哈希表裏
2.於是第二次同一個請求不管是否是同一客戶端的請求到達後，不是將通過算法調度，而是先去查找內存哈希表，查看是否曾經被分配至某個realserver 不管使用的哪個服務都需要查找內存空間的哈希表
2.如果此前曾經被分配過某個realserver那麼哪怕其訪問的其他服務，都統統被分發到此realserver
所以在實現lvs持久鏈接的時候，先去查內存空間哈希表，只要表中匹配則進行分配
那麼對於非常繁忙的lvs來說 持久鏈接就存在瓶頸，如果有N個客戶端那麼就意味着要建立N個條目
也就意味着內存空間需要充足能容納我們的記錄的條目纔可以，所以在必要的時候要去調整模板的空間大小
定義持久連接機制
持久多長時間超時需要自己按需定義
如果想讓lvs工作在持久連接的模型下，方法也很簡單：
在添加ipvs規則的時候加入參數-p：
ipvsadm-A|E -t|u|f service-address [-s scheduler]
[-p[timeout]] [-M netmask]
如下所示：
如果不去設置其值那麼其默認值爲360秒
ipvsadm -ptimeout_number
持久性跟算法沒有關係，就是說無論使用哪種算法都可以實現持久連接
那麼疑問來了：使用持久鏈接是否就沒有意義了？
在客戶端發送第一次連接時進行調度)在實現持久功能之前的選擇，算法依舊有用的，因此需要挑選一個最合理的算法
持久鏈接的功能主要目的是實現將多個端口綁定的，在定義一個服務的時候加-p 只對當前服務有效，那如果對其定義2個不同的服務，那麼他們2個各自持久鏈接是有效果的，但是彼此之間仍然沒關係，那麼我們的目的是將2個服務綁定在一起
因此我們需要人爲的將2個集羣定製爲一個集羣服務：
1.PCC ：持久客戶端連接
2.PPC ：持久端口連接
3. PFMC : 只需要將某幾個服務的請求剛到達directory服務器的時候，在perouting鏈上做防火牆標記，並用ipvs調用其標記
配置持久連接
首先將配置還原如初，這裏就不演示了
配置PCC持久端口連接
無論哪個客戶端統統定義分發至某個realserver中
我們將22端口定製爲集羣服務
[[email protected] ~]#ipvsadm -ln
啓動這種功能的時候lvs調度的過程爲：
1.用戶請求80服務於是根據算法選擇了realserver1並且將這對應關係保存在哈希表裏
2.於是第二次同一個請求不管是否是同一客戶端的請求到達後，不是將通過算法調度，而是先去查找內存哈希表，查看是否曾經被分配至某個realserver 不管使用的哪個服務都需要查找內存空間的哈希表
2.如果此前曾經被分配過某個realserver那麼哪怕其訪問的其他服務，都統統被分發到此realserver
所以在實現lvs持久鏈接的時候，先去查內存空間哈希表，只要表中匹配則進行分配
那麼對於非常繁忙的lvs來說 持久鏈接就存在瓶頸，如果有N個客戶端那麼就意味着要建立N個條目
也就意味着內存空間需要充足能容納我們的記錄的條目纔可以，所以在必要的時候要去調整模板的空間大小
定義持久連接機制
持久多長時間超時需要自己按需定義
如果想讓lvs工作在持久連接的模型下，方法也很簡單：
在添加ipvs規則的時候加入參數-p：
ipvsadm-A|E -t|u|f service-address [-s scheduler]
[-p[timeout]] [-M netmask]
如下所示：
如果不去設置其值那麼其默認值爲360秒
ipvsadm -ptimeout_number
持久性跟算法沒有關係，就是說無論使用哪種算法都可以實現持久連接
那麼疑問來了：使用持久鏈接是否就沒有意義了？
在客戶端發送第一次連接時進行調度)在實現持久功能之前的選擇，算法依舊有用的，因此需要挑選一個最合理的算法
持久鏈接的功能主要目的是實現將多個端口綁定的，在定義一個服務的時候加-p 只對當前服務有效，那如果對其定義2個不同的服務，那麼他們2個各自持久鏈接是有效果的，但是彼此之間仍然沒關係，那麼我們的目的是將2個服務綁定在一起
因此我們需要人爲的將2個集羣定製爲一個集羣服務：
1.PCC ：持久客戶端連接
2.PPC ：持久端口連接
3. PFMC : 只需要將某幾個服務的請求剛到達directory服務器的時候，在perouting鏈上做防火牆標記，並用ipvs調用其標記
配置持久連接
首先將配置還原如初，這裏就不演示了
配置PCC持久端口連接
無論哪個客戶端統統定義分發至某個realserver中
我們將22端口定製爲集羣服務
[[email protected] ~]#ipvsadm -ln
#查看連接
[[email protected] ~]#ipvsadm -lc
添加集羣服務
[[email protected] ~]#ipvsadm -A -t 10.0.0.100:22 -s rr -p
#默認不加數字表示默認超時時間爲360秒
[[email protected] ~]#ipvsadm -a -t 10.0.10.100:22 -r 10.0.10.84
[[email protected] ~]#ipvsadm -a -t 10.0.10.100:22 -r 10.0.10.83
再爲80端口服務添加持久鏈接
[[email protected] ~]#ipvsadm -E -t 10.0.10.100:80 -s rr -p #-p爲持久連接參數，如果不設定其事件默認爲360秒
[[email protected] ~]# ipvsadm-ln
IP Virtual Serverversion 1.2.1 (size=4096)
Prot LocalAddress:Port Scheduler Flags
->RemoteAddress:Port Forward Weight ActiveConn InActConn
TCP 10.0.10.100:22 rr persistent 360
->10.0.10.83:22 Route 1 1 0
->10.0.10.84:22 Route 1 0 0
TCP 10.0.10.100:80 rr persistent 360
->10.0.10.83:80 Route 1 0 0
->10.0.10.84:80 Route 1 0 0
首先連接其web服務
可以發現，無論如何刷新其都是一個頁面，這就是所謂的持久鏈接
再次連接其22端口發現看到已經跳轉至另外一個realserv
ssh 10.0.10.100 ifconfigeth1 | grep inet\ addr
inetaddr:10.0.10.83 Bcast:10.0.10.255 Mask:255.255.255.0
這種持久性只能對一個服務（端口）持久，如果想實現多個只能定義多個集羣
配置PPC持久端口連接
[[email protected] ~]#ipvsadm -C
[[email protected] ~]#ipvsadm -A -t 10.0.10.100:0 -s rr -p
#0表示所有端口，這樣一來不當緊，無論什麼端口都會進行分發操作，我們只要請求的是這個地址，都會統統轉發至realserver中
[[email protected] ~]#ipvsadm -a -t 10.0.10.100:0 -r 10.0.10.83 -g
[[email protected] ~]# ipvsadm -a -t 10.0.10.100:0 -r 10.0.10.84 -g
[[email protected] ~]# ipvsadm -ln
IP Virtual Server version 1.2.1 (size=4096)
Prot LocalAddress:Port Scheduler Flags
->RemoteAddress:Port Forward Weight ActiveConn InActConn
TCP 10.0.10.100:0 rr persistent 360
->10.0.10.83:0 Route 1 0 0
->10.0.10.84:0 Route 1 0 0
很顯然這不符合我們的目的，我們的主要目的是將某些特定的服務綁在一起