keepalive切换时redis的长连接和短连接的影响-2018-1-3

一、redis的VIP结构

VIP地址：172.15.7.244（默认绑定在172.15.7.3机器）

1）172.15.7.3：安装haproxy、keepalive服务，master节点，正常提供服务，权重因子为90，间隔2秒检测一次haproxy进程，若失败，则权重因子减20

2）172.15.7.9：安装haproxy、keeplaive服务，backup节点，3正常时候不提供服务，权重因子为80，间隔2秒检测一次haproxy进程，若失败，则权重因子减20

3）haproxy、supervisord、keepalive 都是由systemd来单独管理的。

二、操作 172.15.7.3 机器

1、修改/lib/systemd/system/supervisord.service文件，增加如下参数：

    LimitCORE=infinity

    LimitNOFILE=655360

    LimitNPROC=131072

2、通过重启supervisord进程

    命令：sudo systemctl restart supervisord

3、产生的问题

    1）keepalived的vip切换

        172.15.7.3(主)：2017.12.25 22:45:42秒，VIP地址从网卡删除；2017.12.25 22:45:51秒，VIP地址绑定网卡；

        172.15.7.9(备)：2017.12.25 22:45:43秒，VIP地址绑定网卡；2017.12.25 22:45:48秒，VIP地址从网卡删除；

    2）由于VIP切换，导致应用连接redis的VIP地址产生如下错误：

File "/usr/lib/python2.7/site-packages/redis/client.py", line 578, in execute_command
connection.send_command(args)
File "/usr/lib/python2.7/site-packages/redis/connection.py", line 563, in send_command
self.send_packed_command(self.pack_command(args))
File "/usr/lib/python2.7/site-packages/redis/connection.py", line 538, in send_packed_command
self.connect()
File "/usr/lib/python2.7/site-packages/redis/connection.py", line 442, in connect
raise ConnectionError(self._error_message(e))
ConnectionError: Error connecting to 172.17.9.244:6379. timed out.

三、重启supervisord造成keepalive的VIP切换问题分析

在测试机器上搭建了supervisord的环境，并部署了hammal应用，重现了线上的问题。新写个脚本，利用tornado创建1400个进程，同样能复现问题；把keepalive的check脚本的间隔由2秒修改1秒，复现问题的几率非常大。从测试的效果可以得出一些结论：

1）supervisord管理的进程数较多时，通过systemctl stop supervisord，会造成ps的命令执行时间变长，测试中有时都超过1秒（也有可能造成系统其他命令执行时间变长）；

2）通过supervisordctl stop 任务，关闭任务大概要16-20秒，而通过systemd stop supervisord，大概在3秒就可以关闭。查看supervisord关闭进程源码，关闭进程时会double check进程的关闭结果，所以可能会慢，作者也增加了注释；

3）supervisord中没有任何进程，或者只有几十个进程，不会重现问题；

4）把keepalive的check时间间隔修改为1秒，无论是否修改/lib/systemd/system/supervisord.service的参数，都能重现问题；

5）supervisord.service中只能使用fork模式，而不能使用simple模式；使用simple模式，supervisord启动后进程会自动退出；

6）在执行systemctl stop supervisord时，通过strace -p $pid，没有发现执行特别慢的system call；

7）systemd管理supervisord时，若supervisord中的进程数较多时（如大于635个进程），通过systemd重启supervisord可能造成系统指令变慢，如ps；

疑问：为什么在supervisord管理进程较多时，systemctl stop supervisord命令会造成系统ps命令变慢，还没有找到根本原因，以后使用过程中需要注意。

四、VIP切换时，应用连接redis的vip报time out问题分析

1、VIP出现问题时，gb后端业务有binserver和executor两类服务连接VIP地址，结构如下：

1.jpg

2、分析VIP出现问题时的日志

    1）长连接的binserver没有受到影响，只在2017.12.25 22:45:50秒出现一个timeout reading from socket的错误，没有其他错误；

    2）e1机器：只在2017.12.25 22:45:42秒，48秒和49秒，出现3个“ConnectionError: Error connecting to 172.17.9.244:6379\. timed out.”

错误，其他时间段没有错误。而修改host中的VIP地址映射的时间是在： 22:52:10秒时修改的（当时看到e2机器出现好多连接redis的time out错，第一解决办法是修改两台机器的hosts的VIP映射）。

    3）e2机器：从2017.12.25 22:45:42开始出现“ConnectionError: Error connecting to 172.17.9.244:6379\. timed out.”，持续到 2017.12.25 22:51:34秒，持续近6分钟，修改hosts的VIP映射时间为：2017.12.25 22:51:17秒；

3、在本地搭建VIP环境，与线上环境一致，测试VIP的长连接和短连接在VIP发生切换时可能会出现什么问题。

4、VIP切换时长连接会出现：

    1）先报"ConnectionError: Error 111 connecting to test_redis_vip:16379\. Connection refused”错，接着是报“ConnectionError: Error connecting to test_redis_vip:16379\. timed out.”错

    2）过几秒钟后，自动重新建立连接，访问VIP正常

5、VIP切换时短连接会出现：

    1）只会出现“ConnectionError: Error connecting to :16379\. timed out.”错      

6、测试产生“Connection refused” 和 “ConnectionError timed out“的错误

    1）Connection refused错：是访问的VIP地址存在，只是该机器没有开放所访问的port

    2）“ConnectionError: Error connecting to test_redis_vip:16379\. timed out.”错：是没有找到VIP的地址，连接redis时给的地址找不到时会报这个错

3、分析得出的一些结论

1）VIP切换时，无论redis是长连接还是短连接，都会出现”ConnectionError xxx timed out“的错误，VIP做不到完美的切换主备服务，需要服务能够容忍短暂的超时；

2）从上面的日志来看，VIP第一次从7.3切换到7.9后，接着VIP又从7.9切换到7.3，executor的e1机器连接正常，e2机器从第一次切换时就连接不上redis的VIP。e2机器与e1机器的不同处在于：e2机器比e1机器多一些python任务。（本地搭建环境没有重现该错误）

3）结合测试造成”timed out“的错误的实验，可以判断出当时e2机器是无法找到VIP的地址，VIP切换时会发送VIP的arp报文，看起来像是e1机器更新了arp cache，e2机器没有arp cache。现在e1和e2机器的arp cache中VIP地址是一样的，也可以连接上VIP。

4）结合12.27号下午17点18分，出现专网回调greenbay的gw地址时，返回的http状态码为404，后通过执行arp广播vip地址解决（此时VIP没有发生切换，在两台VIP机器上可以ping通VIP地址，在第三台机器上ping不通VIP地址）。两个案例结合来看，VIP在使用过程中，需要使用第三台机器来检测VIP地址。

五、一些想法

1、keepalived通过ps -ef haproxy|wc -l 来定时check，现在是间隔2秒检测一次，检测一次失败就切换VIP，这个策略不太合适，需要调整；

2、keepalive的check间隔需要调整的稍微大一些，比如4秒，2次check失败之后再执行VIP；

3、VIP切换到新的机器节点后，即使原来的机器haproxy服务已经恢复，也不执行切换，VIP直接在该机器上提供服务，除非人为手动执行切换或该节点出现问题；

4、keepalive没有记录日志的问题，没有找到具体的原因（很难重现，只有在第一次安装keepalive第一次启动时可能重现），在部署keepalive环境时，部署完成后，执行start-stop-start操作，同时通过log命令检测日志是否能正确记录；

5、keepalive需要提供第三台机器来检测VIP地址是否有效，无效时需要执行相关的arp操作；

6、keepalive切换会有短暂的无法提供服务时间，需要服务能够容忍这段时间；