动态修改LVS real server配置的影响验证

LVS是一种非常高效的负载均衡软件实现，尤其是DR模式。但实际部署需要考虑real server的健康状况，并应该根据real server的健康状况或扩容缩容需求及时更新LVS的配置。但是动态修改LVS配置，对正在运行的客户端会有什么影响呢？考虑到这些问题对LVS做了个全组合测试。

参考网上的流行配置。如下

LVS服务器：

点击(此处)折叠或打开

echo 1 > /proc/sys/net/ipv4/ip_forward

ifconfig eth0:0 ${vip} broadcast ${vip} netmask 255.255.255.255 up

ipvsadm -A -t ${vip}:${port} -s rr

ipvsadm -a -t ${vip}:${port} -r ${realserver}

...

后端real server:

echo 1 > /proc/sys/net/ipv4/conf/lo/arp_ignore

echo 2 > /proc/sys/net/ipv4/conf/lo/arp_announce

echo 1 > /proc/sys/net/ipv4/conf/all/arp_ignore

echo 2 > /proc/sys/net/ipv4/conf/all/arp_announce

ifconfig lo:0 ${vip} broadcast ${vip} netmask 255.255.255.255 up

用LVS做MySQL的负载均衡，测试结果如下:

是否存在lvs realserver配置项

mysql服务

客户端操作

结果

结果判断

存在

启动

新建连接

成功

OK

执行sql

停止

ERROR 2003 (HY000): Can't connect to MySQL server on '10.27.113.51' (111)

mysql> select 1;

ERROR 2006 (HY000): MySQL server has gone away

No connection. Trying to reconnect...

Connection id:    9911

Current database: *** NONE ***

mysql进程死掉的时候会给直接客户端发个F包，这样客户端可以检出连接切断。

已执行sql等待服务端返回

mysql> select sleep(20);

ERROR 2013 (HY000): Lost connection to MySQL server during query

mysql进程死掉的时候会给直接客户端发个F包，这样客户端可以检出连接切断，停止等待。

不存在

成功(有其它real server可选)或失败（无其它real server可选）

[root@srdsdevapp69 ~]# mysql -h 10.27.113.51 -e "select @@server_id";

客户端一直等待ack包。处于这个状态时，再加上lvs的realserver可以恢复。

+---+

| 1 |

1 row in set (5 min 25.57 sec)

注意tcpdump包

17:20:22.310061 IP srdsdevapp69.40776 > 10.27.113.51.mysql: Flags [P.], seq 126:139, ack 295, win 123, length 13

17:20:22.510941 IP srdsdevapp69.40776 > 10.27.113.51.mysql: Flags [P.], seq 126:139, ack 295, win 123, length 13

17:20:22.912934 IP srdsdevapp69.40776 > 10.27.113.51.mysql: Flags [P.], seq 126:139, ack 295, win 123, length 13

17:20:23.716944 IP srdsdevapp69.40776 > 10.27.113.51.mysql: Flags [P.], seq 126:139, ack 295, win 123, length 13

17:20:25.324920 IP srdsdevapp69.40776 > 10.27.113.51.mysql: Flags [P.], seq 126:139, ack 295, win 123, length 13

17:20:28.540935 IP srdsdevapp69.40776 > 10.27.113.51.mysql: Flags [P.], seq 126:139, ack 295, win 123, length 13

17:20:34.972918 IP srdsdevapp69.40776 > 10.27.113.51.mysql: Flags [P.], seq 126:139, ack 295, win 123, length 13

17:20:47.836934 IP srdsdevapp69.40776 > 10.27.113.51.mysql: Flags [P.], seq 126:139, ack 295, win 123, length 13

17:21:13.564932 IP srdsdevapp69.40776 > 10.27.113.51.mysql: Flags [P.], seq 126:139, ack 295, win 123, length 13

17:22:05.021017 IP srdsdevapp69.40776 > 10.27.113.51.mysql: Flags [P.], seq 126:139, ack 295, win 123, length 13

17:23:47.932941 IP srdsdevapp69.40776 > 10.27.113.51.mysql: Flags [P.], seq 126:139, ack 295, win 123, length 13

17:25:47.932934 IP srdsdevapp69.40776 > 10.27.113.51.mysql: Flags [P.], seq 126:139, ack 295, win 123, length 13

17:25:47.934196 IP 10.27.113.51.mysql > srdsdevapp69.40776: Flags [P.], seq 295:351, ack 139, win 29, length 56

17:25:47.934287 IP srdsdevapp69.40776 > 10.27.113.51.mysql: Flags [.], ack 351, win 123, length 0

NG

正常执行，因为mysql的反馈不经过lvs，只要客户端的包发出去了，lvs的配置修改了也不会影响这个包的响应。

mysql> select sleep(10);

+-----------+

| sleep(10) |

|         0 |

1 row in set (10.00 sec)

上面倒数第二个测试结果我认为是有问题的。试想，如果我要集群收缩删除一个后台服务器，如果直接从LVS的realserver列表里删，就会导致那些还连在上面的客户端下次发SQL时会一直等待。

4. 改进后的配置

后经调查，通过在LVS服务器上设置下面的内核参数可解决问题。上面的场景下，客户端发SQL时会立刻错误返回。

echo 1 > /proc/sys/net/ipv4/vs/expire_nodest_conn

5. 最后

LVS默认行为的初衷好像是期待后台服务器发生故障后从列表中剔除，然后等后台服务器恢复之后再加进来。这段时间让客户端等待，可以使故障对客户端透明。实际上这基本是做不到的，后台服务器故障再恢复后，提供服务的进程已经不是原来的进程了，无法继续使用之前的连接。所以LVS还不如把立刻错误返回作为默认行为。