一、知識整理
1、Session:在計算機中，尤其是在網絡應用中，稱為“會話控制、時域”。Session 對象存儲特定用戶會話所需的屬性及配置信息。這樣，當用戶在應用程序的 Web 頁之間跳轉時，存儲在 Session 對象中的變量將不會丟失，而是在整個用戶會話中一直存在下去。當用戶請求來自應用程序的 Web 頁時，如果該用戶還沒有會話，則 Web 服務器將自動創建一個 Session 對象。當會話過期或被放棄后，服務器將終止該會話。注意會話狀態僅在支持 cookie 的瀏覽器中保留。
2、站點指標：
PV：page view：頁面的瀏覽次數，衡量網站用戶訪問的網頁數量，打開一個頁面記錄一次，刷新累計；
UV：unique vistor：一天內訪問某站點的人數，以cookie為依據；
IP：同一個IP的訪問算作一次；同一IP不管訪問了幾個頁面，獨立IP數都為1；
VV：記錄所有訪客1天內訪問了多少次網站；
3、LVS的類型：
NAT 地址轉換
集群節點與director必須在同一IP網絡中
RIP通常都是私有地址，僅用于集群節點之間通信
director位于client和real server之間，并負責處理進出的所有通信
realsever必須將網關指向dip。
支持端口映射，可修改請求報文的目標PORT；
realsever可以使用任何類型的操作系統，vs是linux系統；
較大規模應用場景中，一個單獨的director易成為系統瓶頸
DR 直接路由
VIP僅用于作為源地址
修改mac地址通信
集群節點與director必須在同一物理網絡中（mac地址通信）
RIP可以使用公網地址，實現便捷的遠程管理和監控
realsever不能將網關指向DIP，而應直接使用前端網關
不支持端口映射
realsever隱藏了vip，但在發送響應報文時還可以當源IP：lo別名配置VIP，修改內核參數，使IP屬于網卡，限制響應模型和通知模型 arp_announce arp_ignore。
RS的RIP可以使用私網地址，也可以是公網地址；RIP與DIP在同一個網絡；
RS更Director要在同一個物理網絡；
請求報文要經由Director，但響應不能經由Director，而是由RS直接發往client；
比NAT處理更多的realserver
TUN 隧道
轉發時不修改請求報文的IP首部(CIP VIP)，而在源IP報文之外再封裝ip一個首部，借助第一層封裝發送第二層ip報文，要求支持隧道機制(IP-IP)。
集群節點可以跨越互聯網
DIP,VIP,RIP都應該是公網地址
director僅負責處理入站請求，響應報文則由realsever直接發往客戶端
只有支持隧道功能的os才能用于realsever
不支持端口映射；
realsever網關不能指向director，以確保響應報文不會經由Director；，請求報文要經由Director；
FULLNAT
同時修改請求報文的源IP地址和目標IP地址進行轉發；
CIP–DIP
VIP–RIP
VIP是公網地址，RIP和DIP是私網地址，且通常不在同一IP網絡；因此RIP的網關一般不會指向DIP；
RS收到的請求報文源地址是DIP，因此只需要響應給DIP，但Director還要將其發往client；
請求和響應報文都經由Director；
支持端口映射；
此類型默認不支持；(淘寶專用內核補丁)
4、正常情況下，如果我們定義了兩個集群：
[root@localhost ~]# ipvsadm -ln IP Virtual Server version 1.2.1 (size=4096) Prot LocalAddress:Port Scheduler Flag -> RemoteAddress:Port Forward Weight ActiveConn InActConn TCP 10.1.49.49:80 w -> 10.1.49.10:80 Route 1 0 0 -> 10.1.252.28:80 Route 1 0 0 TCP 10.1.49.49:3306 r -> 10.1.49.10:3306 Route 1 0 0 -> 10.1.252.28:3306 Route 1 0 0
那么在測試時，我們會發現他們是相互獨立的，也就是說我們在訪問一臺服務器的web服務時，有可能連接到另一臺服務的mysql服務，此處是為了演示，實際中會將http和https合并同時調度。含有test數據庫的是RS1：
[root@localhost ~]# mysql -h10.1.49.49 -uroot -pmagedu -e "SHOW DATABASES;" +--------------------+ | Database | +--------------------+ | information_schema | | mysql | | test | | ultrax | +--------------------+ [root@localhost ~]# curl http://10.1.49.49/index.html RS1 [root@localhost ~]# mysql -h10.1.49.49 -uroot -pmagedu -e "SHOW DATABASES;" +--------------------+ | Database | +--------------------+ | information_schema | | mysql | | ultrax | +--------------------+
此時可以使用FWM(firewall mark)，借助于防火墻標記來分類報文，而后基于標記定義集群服務，可將多個不同的應用使用同一個集群服務進行調度；
方法：在director主機上操作：
[root@localhost ~]# iptables -t mangle -A PREROUTING -d 10.1.49.49 -p tcp -m multiport --dports 80,3306 -j MARK --set-mark 8 [root@localhost ~]# iptables -t mangle -vnL Chain PREROUTING (policy ACCEPT 138 packets, 11526 bytes) pkts bytes target prot opt in out source destination 0 0 MARK tcp -- * * 0.0.0.0/0 10.1.49.49 multiport dports 80,3306 MARK set 0 Chain INPUT (policy ACCEPT 138 packets, 11526 bytes) pkts bytes target prot opt in out source destination Chain FORWARD (policy ACCEPT 0 packets, 0 bytes) pkts bytes target prot opt in out source destination Chain OUTPUT (policy ACCEPT 43 packets, 4452 bytes) pkts bytes target prot opt in out source destination Chain POSTROUTING (policy ACCEPT 43 packets, 4452 bytes) pkts bytes target prot opt in out source destination [root@localhost ~]# ipvsadm -A -f 8 -s wrr [root@localhost ~]# ipvsadm -a -f 8 -r 10.1.252.28 -g -w 1 [root@localhost ~]# ipvsadm -a -f 8 -r 10.1.49.10 -g -w 1 [root@localhost ~]# ipvsadm -ln IP Virtual Server version 1.2.1 (size=4096) Prot LocalAddress:Port Scheduler Flags -> RemoteAddress:Port Forward Weight ActiveConn InActConn FWM 8 wrr -> 10.1.49.10:0 Route 1 0 0 -> 10.1.252.28:0 Route 1 0 0
測試，可以看出兩個端口是被綁定起來訪問了：
[root@localhost ~]# mysql -h10.1.49.49 -uroot -pmagedu -e "SHOW DATABASES;" ; curl http://10.1.4 9.49/index.html+--------------------+ | Database | +--------------------+ | information_schema | | mysql | | test | | ultrax | +--------------------+ RS2 [root@localhost ~]# curl http://10.1.49.49/index.html RS1 [root@localhost ~]# mysql -h10.1.49.49 -uroot -pmagedu -e "SHOW DATABASES;" +--------------------+ | Database | +--------------------+ | information_schema | | mysql | | ultrax | +--------------------+
5、基于LVS的持久連接，此方法與算法無關，是LVS的核心層面實現的：
[root@localhost ~]# ipvsadm -A -t 10.1.49.49:80 -s rr -p 20 [root@localhost ~]# ipvsadm -a -t 10.1.49.49:80 -r 10.1.49.10 -g [root@localhost ~]# ipvsadm -a -t 10.1.49.49:80 -r 10.1.252.28 -g [root@localhost ~]# ipvsadm -Ln IP Virtual Server version 1.2.1 (size=4096) Prot LocalAddress:Port Scheduler Flags -> RemoteAddress:Port Forward Weight ActiveConn InActConn TCP 10.1.49.49:80 rr persistent 20 -> 10.1.49.10:80 Route 1 0 5 -> 10.1.252.28:80 Route 1 0 5
測試如下：
[root@localhost ~]# for i in {1..10}; do curl http://10.1.49.49/index.html; done
RS2
RS2
RS2
RS2
RS2
RS2
RS2
RS2
RS2
RS2
然而我們可以加上端口綁定來實現多種方式：
單端口持久 PPC：每集群服務單獨定義，并定義其持久性。
每防火墻持久：基于防火墻標記定義持久的集群服務；可實現將多個端口上的應用統一調度，即所謂的port affinity(端口的姻親關系)。
每客戶端持久：基于0端口定義集群服務，即將客戶端所有應用的請求全部調度至后端主機，而且使用持久連接進行綁定。
第三種方式的方法如下：
[root@localhost ~]# ipvsadm -C [root@localhost ~]# ipvsadm -A -t 10.1.49.49:0 -s rr -p [root@localhost ~]# ipvsadm -a -t 10.1.49.49:0 -r 10.1.49.10 -g [root@localhost ~]# ipvsadm -a -t 10.1.49.49:0 -r 10.1.252.28 -g [root@localhost ~]# ipvsadm -ln IP Virtual Server version 1.2.1 (size=4096) Prot LocalAddress:Port Scheduler Flags -> RemoteAddress:Port Forward Weight ActiveConn InActConn TCP 10.1.49.49:0 rr persistent 360 -> 10.1.49.10:0 Route 1 0 0 -> 10.1.252.28:0 Route 1 0 0
6、保存及重載規則：
保存：建議保存至/etc/sysconfig/ipvsadm中
ipvsadm-save >
ipvsadm -S >
systemctl stop ipvsadm.service
重載：ipvsadm-restore <
ipvsadm -R <
systemctl restart ipvsadm.service
停止服務和啟動服務時候或者直接重啟服務的時候，會自動保存及加載此文件中的規則。
[root@localhost ~]# ipvsadm-save > /etc/sysconfig/ipvsadm [root@localhost ~]# ipvsadm -C [root@localhost ~]# ipvsadm-restore < /etc/sysconfig/ipvsadm [root@localhost ~]# ipvsadm -Ln IP Virtual Server version 1.2.1 (size=4096) Prot LocalAddress:Port Scheduler Flags -> RemoteAddress:Port Forward Weight ActiveConn InActConn TCP 10.1.49.49:0 rr persistent 360 -> 10.1.49.10:0 Route 1 0 0 -> 10.1.252.28:0 Route 1 0 0
二、命令詳解及事例
1、ipvsadm命令：
保存規則
-S ipvsadm -S > /path/file
ipvsadm-save
載入之前的規則
-R ipvsadm -R < /PATH/FILE
ipvsadm-restore
刪除所有集群服務
-C 清空ipvs規則
查看：
-L|l
-n 數字格式顯示主機地址和端口
–exact：expand numbers(display exact values)
–state 統計數據
–rate
每秒連接數：CPS
–timeout 顯示tcp tcpfin和udp的會話超時時長
–daemon
–sort 以realsever做排序，默認升序
-c 顯示當前的ipvs連接狀況
管理集群服務
添加 -A|E -t|u|f service-address [-s scehduler]
ipvsadm -A -t 172.16.100.1:80 -s rr
-t tcp協議的集群 vip:port
-u udp協議的集群
service-address： ip:port
-f fwm防火墻標記
service-address:mark number
將不同的端口的規則設置為同一個number，可以統一調度；
[-s scehduler] 調度算法
修改 -E
刪除 -D
-D -t|u|f service-address
管理集群服務中的RS realsever
添加
-a|e -t|u|f service-address -r server-address [-g|i|m] [-w weight]
service-address :事先定義好的某集群服務
-r server-address
某rs的地址，在nat模型中，可使用ip：port實現端口映射
[-g|i|m] LVS類型
g：gateway，dr類型，默認類型；
i：ipip，tun類型
m：masquerade，nat類型
[-w weight] 定義服務器權重
默認是1
修改 -e
刪除 -d
2、調度算法：
固定調度：靜態調度：不考慮服務器上活動鏈接和非活動鏈接
rr：輪詢，輪調，輪叫
wrr：weight，加權輪詢
sh：source hash：源地址hash
隨機分配，但是將相同IP地址的請求始終發送到同一個realserver。
session affinity：持續用一個session，“購物車中的商品不會丟失”
dh：destination hashing
把發往同一個目標地址的請求始終轉發至第一次挑中的R Server，以目標地址為標準進行挑選。與sh類似，但適合的場景不同。
動態調度：
LC：least connection 最少連接
計算當前后端活動鏈接數 overhead=active*256+inactive
給數目較小的發送鏈接
wlc（默認方法）：加權最少連接 weighted LC
（active*256+inactive）/weight
sed:shortest expection delay最短期望延遲
（activeconns+1）*256/weight
nq：never queue
每個服務器最少一個連接；
LBLC：基于本地的最少連接locality-based LC
DH的改進，考慮cache的連接數，動態的DH算法；
LBLCR：LBLC with Replication，基于本地的帶復制功能的最少連接
原創文章，作者：SilencePavilion，如若轉載，請注明出處：http://www.www58058.com/56385
