Chinaunix首页 | 论坛 | 博客
  • 博客访问: 2908619
  • 博文数量: 199
  • 博客积分: 1400
  • 博客等级: 上尉
  • 技术积分: 4126
  • 用 户 组: 普通用户
  • 注册时间: 2008-07-06 19:06
个人简介

半个PostgreSQL DBA,热衷于数据库相关的技术。我的ppt分享https://pan.baidu.com/s/1eRQsdAa https://github.com/chenhuajun https://chenhuajun.github.io

文章分类

全部博文(199)

文章存档

2020年(5)

2019年(1)

2018年(12)

2017年(23)

2016年(43)

2015年(51)

2014年(27)

2013年(21)

2011年(1)

2010年(4)

2009年(5)

2008年(6)

分类: LINUX

2016-01-18 16:41:15

1. 背景

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


2. 最初的配置

参考网上的流行配置。如下
LVS服务器:

点击(此处)折叠或打开

  1. echo 1 > /proc/sys/net/ipv4/ip_forward
  2. ifconfig eth0:0 ${vip} broadcast ${vip} netmask 255.255.255.255 up
  3. ipvsadm -A -t ${vip}:${port} -s rr
  4. ipvsadm -a -t ${vip}:${port} -r ${realserver}
  5. ...

后端real server:

点击(此处)折叠或打开

  1. echo 1 > /proc/sys/net/ipv4/conf/lo/arp_ignore
  2. echo 2 > /proc/sys/net/ipv4/conf/lo/arp_announce
  3. echo 1 > /proc/sys/net/ipv4/conf/all/arp_ignore
  4. echo 2 > /proc/sys/net/ipv4/conf/all/arp_announce
  5. ifconfig lo:0 ${vip} broadcast ${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时会立刻错误返回。

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

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

阅读(4138) | 评论(0) | 转发(0) |
给主人留下些什么吧!~~