1. 背景
LVS是一种非常高效的负载均衡软件实现，尤其是DR模式。但实际部署需要考虑real server的健康状况，并应该根据real server的健康状况或扩容缩容需求及时更新LVS的配置。但是动态修改LVS配置，对正在运行的客户端会有什么影响呢？考虑到这些问题对LVS做了个全组合测试。
2. 最初的配置
参考网上的流行配置。如下
LVS服务器：
点击(此处)折叠或打开
- echo 1 > /proc/sys/net/ipv4/ip_forward
- ifconfig eth0:0 vipbroadcast{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 vipbroadcast{vip} netmask 255.255.255.255 up
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时会立刻错误返回。
- echo 1 > /proc/sys/net/ipv4/vs/expire_nodest_conn
5. 最后
LVS默认行为的初衷好像是期待后台服务器发生故障后从列表中剔除，然后等后台服务器恢复之后再加进来。这段时间让客户端等待，可以使故障对客户端透明。实际上这基本是做不到的，后台服务器故障再恢复后，提供服务的进程已经不是原来的进程了，无法继续使用之前的连接。所以LVS还不如把立刻错误返回作为默认行为。
