1. 背景

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

2. 最初的配置

参考网上的流行配置。如下 LVS服务器： 后端real server:

2. 测试结果

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

是否存在lvs realserver配置项	mysql服务	客户端操作	结果	结果判断
存在	启动	新建连接	成功	OK
存在	启动	执行sql	成功	OK
存在	停止	新建连接	ERROR 2003 (HY000): Can't connect to MySQL server on '10.27.113.51' (111)	OK
存在	停止	执行sql	mysql> select 1; ERROR 2006 (HY000): MySQL server has gone away No connection. Trying to reconnect... Connection id:    9911 Current database: *** NONE *** mysql进程死掉的时候会给直接客户端发个F包，这样客户端可以检出连接切断。	OK
存在	停止	已执行sql等待服务端返回	mysql> select sleep(20); ERROR 2013 (HY000): Lost connection to MySQL server during query mysql进程死掉的时候会给直接客户端发个F包，这样客户端可以检出连接切断，停止等待。	OK
不存在	启动	新建连接	成功(有其它real server可选)或失败（无其它real server可选） [root@srdsdevapp69 ~]# mysql -h 10.27.113.51 -e "select @@server_id"; ERROR 2003 (HY000): Can't connect to MySQL server on '10.27.113.51' (111)	OK
不存在	启动	执行sql	客户端一直等待ack包。处于这个状态时，再加上lvs的realserver可以恢复。 mysql> select 1; +---+ | 1 | +---+ | 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
不存在	启动	已执行sql等待服务端返回	正常执行，因为mysql的反馈不经过lvs，只要客户端的包发出去了，lvs的配置修改了也不会影响这个包的响应。 mysql> select sleep(10); +-----------+ | sleep(10) | +-----------+ |         0 | +-----------+ 1 row in set (10.00 sec)	OK

上面倒数第二个测试结果我认为是有问题的。试想，如果我要集群收缩删除一个后台服务器，如果直接从LVS的realserver列表里删，就会导致那些还连在上面的客户端下次发SQL时会一直等待。 4. 改进后的配置 后经调查，通过在LVS服务器上设置下面的内核参数可解决问题。上面的场景下，客户端发SQL时会立刻错误返回。 5. 最后 LVS默认行为的初衷好像是期待后台服务器发生故障后从列表中剔除，然后等后台服务器恢复之后再加进来。这段时间让客户端等待，可以使故障对客户端透明。实际上这基本是做不到的，后台服务器故障再恢复后，提供服务的进程已经不是原来的进程了，无法继续使用之前的连接。所以LVS还不如把立刻错误返回作为默认行为。