yujin2010good
作者yujin2010good·2019-06-28 14:00
系统工程师·大型零售巨头

ipvsadm -L --timeout 之 tcp tcpfin udp 详解

字数 3943阅读 1800评论 0赞 2

LVS持久化

在实际应用场景中,轮询调度并不都是适用的。有些情况下,需要我们把同一个会话的请求都调度给一个RS节点。这时候就需要LVS提供持久化的能力,能够实现会话保持。

一、LVS的持久化主要包括以下两个方面。

  1. 把来自同一个客户端IP的请求转发到同一个RS的持久化时间:persistence_timeout。通过这个持久化时间,我们可以实现会话保持。
  2. 一个连接创建后处于空闲状态的超时时间。包括三种:

tcp连接的空闲超时时间

LVS收到客户端FIN消息的超时时间

udp的超时时间

二、持久化时间的机制

[root@node1 ~]# ipvsadm -lnc

IPVS connection entries

pro expire state source virtual destination

TCP 01:28 FIN_WAIT 192.31.56.1:52176 192.31.56.105:80 192.168.100.35:80

TCP 01:45 ESTABLISHED192.31.56.1:52226 192.31.56.105:80 192.168.100.35:80

TCP 05:34 NONE 192.31.56.1:0 192.31.56.105:80 192.168.100.35:80

如果用户配置了持久化时间persistence_timeout,当客户端的请求到达LB后,IPVS会在[记录表]里添加一条state为NONE的连接记录。该连接记录的源IP为客户端IP,端口为0,超时时间为上面所说的持久化时间persistence_timeout,会逐步减小。当NONE的超时时间减到0时,如果IPVS记录中还存在ESTABLISHED或FIN_WAIT状态的连接,则persistence_timeout值会刷新为初始值。

在该NONE状态的连接记录存在的期间,同一客户端IP的消息都会被调度到同一个RS节点。(NONE状态连接不是表示一条具体的连接,而是代表一个客户端IP过来的连接的模板,源端口用0表示。具体的连接会在IPVS上记录具体的连接状态,会显示具体的源端口)

ESTABLISHED前面的超时时间就是tcp|tcpfin|udp中的tcp的值。该值表示一条TCP连接记录的空闲释放时间。如果客户端和服务端建立了连接,则IPVS中会出现一条ESTABLISHED的记录。每当客户端和服务端的连接中有[信息交互]时,该超时时间都会刷新为初始值。如果连接处于空闲状态,即一直没有信息交互,则等到该值超时后,ESTABLISHED的记录会直接消失(这种情况下IPVS记录不会进入FIN_WAIT),实际上TCP连接还是存在的,并没有中断,但是由于持久化时间到了,后续同一客户端(IP+Port)过来的请求会重新调度。所以长连接业务场景需要注意根据业务需要设置好这个TCP空闲连接的超时时间。

FIN_WAIT前面的超时时间就是tcp|tcpfin|udp中的tcpfin的值。在IPVS记录的每一条连接中,如果客户端发起了FIN断连,则IPVS中记录的连接状态会从ESTABLISHED变为FIN_WAIT。该值超时后,FIN_WAIT状态的记录直接消失。

还有一个细节要注意,如果用户没有配置持久化时间persistence_timeout,那么在ipvsadm -lnc查询的记录里面是不会生成NONE记录模板的,因为此时不需要持久化。但是!!!ipvsadm -lnc记录中还是会生成ESTABLISHED记录的,后续同一客户端(IP+PORT)的请求都会调度给同一个[服务器],直到该连接达到了TCP空闲连接超时时间后,ESTABLISHED记录消失,ipvs才会重新调度该客户端的请求。这个机制是必须的,不能算作持久化(持久化针对的是同一客户端IP,可以是不同端口)。因为TCP在传输的过程中可能出出现报文分片,如果ipvs把来自同一客户端(IP+PORT)的不同分片调度给了不同的服务器,那么服务器收到报文分片后无法重新组合报文。

三、持久化时间的配置

示例:

配置持久化时长为360秒(不需要配置持久化就不带 -p参数即可)

ipvsadm -A -t 192.168.1.100:80 -s rr -p 360

ipvsadm -Ln查看配置

ipvsadm -Ln

IP Virtual Server version x.x.x (size=4096)

Prot LocalAddress:Port Scheduler Flags

-> RemoteAddress:Port Forward Weight ActiveConn InActConn

FWM 99 rr persistent 360

配置tcp/tcpfin/udp超时时间

ipvsadm --set 300 60 100

表示tcp空闲等待超时时间为300秒;客户端

ipvsadm -Ln --timeout查看配置

Timeout (tcp tcpfin udp): 900 120 300

四、 LVS虚拟服务分类

常见的LVS虚拟服务有以下三种:

1.指定IP端口的虚拟服务:将客户端对于某个虚拟服务IP端口的请求调度给真实服务器。

配置方法:

ipvsadm -A -t 192.168.1.100:80 -s rr -p 3600(添加一个VS,轮询,持久化时长1小时)

ipvsadm -a -t 192.168.1.100:80 -r 192.168.23 -g -w 1(DR模式,添加一个RS)

ipvsadm -a -t 192.168.1.100:80 -r 192.168.24 -g -w 1(DR模式,添加一个RS)

2.指定IP不指定端口的虚拟服务:将客户端IP对于虚拟服务IP的请求调度给真实服务器。

配置方法:

ipvsadm -A -t 192.168.1.100:0 -s rr -p 3600

ipvsadm -a -t 192.168.1.100:0 -r 192.168.1.23 -g -w 1

ipvsadm -a -t 192.168.1.100:0 -r 192.168.1.24 -g -w 1

3.指定防火墙标记的虚拟服务:将带有指定防火墙标记的数据包调度给真实服务器(相当于按防火墙标记匹配进行调度,可用于实现跨虚拟服务的关联持久化)

比如LVS同时提供一个http端口80和https端口443的虚拟服务,需要将这两个虚拟服务实现关联持久化。(比如:一个用户在访问购物网站时同时使用http(80)和https(443)两种协议,http服务用于浏览页面,https服务用于加密传输密码等重要信息,这时我们需要将用户的请求调度到同一台Real Server上)

配置方法:(如要实现80端口和443端口的会话保持)

iptables -t mangle -A PREROUTING -d 192.168.1.100 -i eth0 -p tcp --dport 80 -j MARK --set-mark -10(给访问虚拟服务192.168.1.100:80的数据包都加上标记10)

iptables -t mangle -A PREROUTING -d 192.168.1.100 -i eth0 -p tcp --dport 443 -j MARK --set-mark -10(给访问虚拟服务192.168.1.100:443的数据包都加上标记10)

ipvsadm -A -f 10 -s rr -p 3600(增加一个标记为10的虚拟服务,轮询,时长1小时)

ivpsadm -a -f 10 -r 192.168.1.23 -g -w 1(增加标记为10的真实服务器,实际上真实服务器并不会识别标记,这里只是把真实服务器和虚拟服务关联起来)

ivpsadm -a -f 10 -r 192.168.1.24 -g -w 1(增加标记为10的真实服务器,这里的真实服务器不需要指定端口,四层NAT和DR真实服务器的端口都和虚拟服务端口一致,因为LVS转发不改变端口)

注意:这里的标记都是指LB节点上iptables在mangle表上添加的标记规则。PREROUTING指路由前的操作。所以当客户端的请求到达iptables后,匹配到mangle表规则里的目的IP和端口时,iptables会给数据包打上标记10,然后IPVS模块根据配置的虚拟服务规则中指定的防火墙标记进行匹配,匹配到了指定标记的数据包,就将消息调度给真实服务器。这种场景下,防火墙标记实际上就是起到了一个虚拟服务标识的作用,IPVS根据指定的防火墙标记进行转发,不区分IP端口。(标记是内核模块上的记录,不会跟随数据包出去,RS上收到的数据包和普通数据包没有差别,并不会有标记)。

LVS实现关联持久化的原理

首先客户端的请求(目的端口80)到达iptables,mangle表匹配到80端口后,会给数据包打上标记10,然后IPVS模块匹配到标记10,就把消息调度到一组标记为10的真实服务器;然后客户端的请求(目的端口443)到达iptables,mangle表匹配到443端口后,也会给数据包打上标记10,然后IPVS模块匹配到标记10,就把消息调度到同一组真实服务器。如果虚拟服务有-p指定持久化时长的话,那么同一个客户端的两个请求(目的端口分别为80和443)就会被调度到同一个RS节点上。

这时候访问80端口和443端口的请求都调度给了同一个RS节点,从而实现了从http服务到https服务的会话保持。

如果觉得我的文章对您有用,请点赞。您的支持将鼓励我继续创作!

2

添加新评论0 条评论

Ctrl+Enter 发表

作者其他文章

相关问题

X社区推广