一、知识整理
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.178linux.com/56385
