LVS均衡负载（四） LVS持久连接

逃离我推掉我的手 2022-09-25 14:17 198阅读 0赞

**LVS负载均衡（四） LVS持久连接**

> 上一篇我们分析及实现了LVS后端服务健康状态检查，下面我们还将利用前面配置好的DR工作方式集群来实现LVS持久连接。

## **1、什么是LVS持久连接** ##

> 在LVS中，持久连接是为了用来保证当来自同一个client的请求时，director能够将这些请求调度定位到同一台Real Server。

## **2、为什么会用到LVS持久连接** ##

>        例1： 一般来说，Real Server需要靠session来标记用户的会话，如果集群内没有共享存储session信息，而用户前后两次操作分别被调度到两台Real Server,就会导致后一次请求的无法继续前一次的操作状态；比如，前一次请求登录调度到Real Server1，Real Server1保存了该用户的已登录状态，而再一次请求获取个人数据的时候调度到Real Server2，Real Server2在自己的存储中没有找到用户已登录的状态信息，从而拒绝了该请求；当然这也可以通过使用Redis、Mencache实现各Real Server间的共享存储来实现；

>       例2： 对于电子商务网站来说，用户在挑选商品的时候使用的是http：80端口来浏览的，当付款的时候则是通过https：443端口加密的方式；我们不希望http：80挑选商品的信息在Real Server1，而https：443商品付款的时候跳转到另外一台Real Server2；并且https：443需要交换SSL密钥，当启用持久性连接时，只需要做一次验证即可。

>  ...等等。

## **3、LVS持久连接类型** ##

### **3-1、PPC（persistent port connections）** ###

>       持久的端口连接，将来自于同一个客户端对同一个服务(端口)的请求，始终定向至此前选定的RS。

>       例如：来自同一个IP的用户第一次访问集群的80端口分配到Real Server1，433号端口分配到Real Server2。当之后这个用户继续访问80端口仍然分配到Real Server1，433号端口仍然分配到Real Server2。

### **3-2、PCC（persistent client connections）** ###

>       将来自于同一个客户端的所有请求统统定向至此前选定的RS；也就是只要IP相同，分配的服务器始终相同。

>       例如，来自同一个IP的用户访问集群的80端口分配到Real Server1，然后用户访问433号端口仍然分配到Real Server1。**但如需要SSH：22连接管理Director时，也被分配到Real Server就不好了，下面的PNMPP可以解决这个问题。**

### **3-3、PNMPP（Persistent Netfilter Marked Packet Persistence）** ###

>       基于防火墙标记的持久性连接，这种防火墙标记仅在数据包在分发器上时有影响，数据包一旦离开Director，就不再被标记。

>       需要用到iptables的mangle表为数据包设置Mark标记，mangle表主要用于修改数据包的TOS（Type Of Service，服务类型）、TTL（Time To Live，生存周期）指以及为数据包设置Mark标记。

>            iptables -t mangle -A PREROUTING -d 192.168.1.100 -eth0 -p tcp --dport 80 -j MARK --set-mark 10

>       它可以将两个毫不相干的端口定义为一个集群服务，例如：合并http的80端口和https的443端口定义为同一个集群服务，而不会出现上面PCC据说的问题。

## **4、其他关注点** ##

### **4-1、为什么不使用SH算法** ###

>        SH调度算法和持久连接的作用都是"将来自同一个IP的请求都转发到同一个Server"，从而保证了session会话定位的问题。两者的不同是：
> 
>        **(1)sh算法**：使用SH算法，SH算法在内核中会自动维护一个哈希表，此哈希表中用每一个请求的源IP地址经过哈希计算得出的值作为键，把请求所到达的RS的地址作为值。在后面的请求中，每一个请求会先经过此哈希表，如果请求在此哈希表中有键值，那么直接定向至特定Real Server，如没有，则会新生成一个键值，以便后续请求的定向。但是此种方法在时间的记录上比较模糊（依据TCP的连接时长计算），而且其是算法本身，所以无法与算法分离，并不是特别理想的方法。
> 
>        **(2)持久连接**：此种方法实现了无论使用哪一种调度方法，持久连接功能都能保证在指定时间范围之内，来自于同一个IP的请求将始终被定向至同一个RS，还可以把多种服务绑定后统一进行调度。
> 
>        ipvs内有一个LVS持久连接模板，模板中记录了每一个请求的来源、调度至的Real Server、维护时长等等，在新的请求进入时，首先在此模板中检查是否有记录（有内置的时间限制，比如限制是300秒，当在到达300秒时依然有用户访问，那么持久连接模板就会将时间增加两分钟，再计数，依次类推，每次只延长2分钟），如果该记录未超时，则使用该记录所指向的Real Server，如果是超时记录或者是新请求，则会根据调度算法先调度至特定RS，再将调度的记录添加至此表中。这并不与SH算法冲突，LVS持久连接会在新请求达到时，检查后端Real Server的负载状况，这就是比较精细的调度和会话保持方法。

### **4-2、2个LVS的持续时间** ###

#### **    4-2-1.把同一个client发来请求到同一台Real Server的持久超时时间** ####

>       这个也就是上面所提到的LVS持久连接模板的超时时间，ipvsadm -A|E ... -p timeout；timeout: 持久连接时长，默认300秒；单位是秒。

####     **4-2-2.一个链接创建后空闲时的超时时间，这个超时时间分为3种** ####

ipvsadm --set tcp tcpfin udp设置，大的TCP会话超时值将会增加保留在director上的连接模板的时间。

>  1）tcp的空闲超时时间；
> 
>  2）lvs收到客户端tcp fin的超时时间；
> 
>  3）udp的超时时间。

## **5、配置** ##

> 这里还是使用前面配置好的DR方式群集。

### **5-1、配置PPC（persistent port connections）** ###

> 配置Director时加上-p timeout选项即可：

ipvsadm -A -t 192.168.1.100:80 -s wrr–p 300

### **5-2、配置PCC（persistent client connections）** ###

> 配置Director时使用0号端口，加上-p timeout选项，这样把所有端口统统定义为集群服务，全部向Real Server转发：

>             ipvsadm -A -t 192.168.1.100:0 -s wrr–p 300
> 
>             ipvsadm -a -t 192.168.1.100:0 -r 192.168.1.102 -g -w 1
> 
>             ipvsadm -a -t 192.168.1.100:0 -r 192.168.1.103 -g -w 3

### **5-3、配置PNMPP（Persistent Netfilter Marked Packet Persistence）** ###

配置Director时先配置iptables的mangle表为数据包设置Mark标记，下面设置80和22（SSH）端口的数据包都加上标记10，然后ipvs配置就可用-f mask选项，将两个毫不相干的端口定义为一个集群服务：

iptables -t mangle -A PREROUTING -d 192.168.1.100 -i eth0 -p tcp --dport 80 -j MARK --set-mark 10

iptables -t mangle -A PREROUTING -d 192.168.1.100 -i eth0 -p tcp --dport 22 -j MARK --set-mark 10

ipvsadm -A -f 10 -s wrr -p 600

ipvsadm -a -f 10 -r 192.168.1.102 -g -w 1

ipvsadm -a -f 10 -r 192.168.1.103 -g -w 3

## **6、测试PNMPP** ##

> 我们只测试PNMPP，就如上面配置的**PNMPP**来测试，配置如下：

![20160911175803241][]

> 配置好后，在另一测试机上执行：

>         ab –n 1000 –c 10[http://192.168.0.146/index.html][http_192.168.0.146_index.html]

可以看到虽然我们配置的调度算法为WRR，但测试机的请求连接都只调度到了192.168.1.103的Real Server2，情况如下：

![20160911175804233][]

>      然后再在xshell中SSH连接Director,可以看到连接同样调度到了192.168.1.103的Real Server2，说明实现了将80和22的两个端口定义为一个集群服务，情况如下：

![20160911175804967][]

经过写这几篇LVS的文章，较为全面的认识了LINUX集群的LVS均衡负载方式，但对于LINUX集群还有许多需要关注的问题，比如高可用、共享存储、数据同步…等等。后面还将继续关注…….

【参考资料】

1、SH算法与持久连接：http://minux.blog.51cto.com/8994862/1744761

[20160911175803241]: /images/20220717/0b613a89b9cf4d4eb363fd6934dbddc4.png
[http_192.168.0.146_index.html]: http://192.168.0.146/index.html
[20160911175804233]: /images/20220717/345e34b1ca2447d9b76131c8f8a85845.png
[20160911175804967]: /images/20220717/9a0aa84d45494886b1232bd8ca63192a.png