LVS负载均衡下session共享的实现方式-持久化连接

 

之前简单介绍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