问题发现

在OpenStack环境中，我们使用Keepalived+Haproxy的模式来提供负债均衡和高可用。后方运维报过来一个VIP被不时remove的问题，从日志上来看是由于vrrp_script执行脚本超时，而后主keepalived让出了VIP。下图是日志

起初判断认为是由于vrrp_script的脚本执行时间过长，而导致执行失败，而触发了脚本，这个看法本身没错，但是我们当时认为解决办法应该是缩短脚本执行时间，这个思路看起来是对的，实际是只看到了表面。

#!/bin/bash
count=`netstat -nlp|grep -i haproxy|wc -l`
if [ $count -gt 1 ];then
exit 0
else
systemctl stop keepalived
exit 1
fi

在说脚本之前，需要说一一下vrrp_script的逻辑，当脚本返回0，则认为正常，当脚本结果返回非0，则任务脚本执行失败。
该脚本通过netstat命令获取目前haproxy的监听状态数量，该值不大于1的时候，而对keepalived进行stop，最终完成VIP的切换。
当时对优化脚本而提出的解决方案是用systemctl is-active haproxy的命令返回值而进行判断haproxy的状态，我们判断认为使用该命令受影响干扰少，且迅速。

验证两种脚本的执行时间

但是测试后，发现两种脚本的执行时间基本一致，所以该方案是行不通的。

问题出在哪里？

有一个浅显的道理摆在我们面前，我们一直视而不见。既然vrrp_script检测超时，那么keepalived的检测机制和逻辑究竟是什么，默认多久是超时，我们时候可以修改超时的时间。
查阅资料后，我们发现vrrp_script脚本本身是一个脚本检测的配置，会根据脚本执行的结果而影响priority。下面我逐一解释，这里每个字段的意思。

参数设置解释和建议：

Interval 1
#定期执行脚本间隔，单位是s

timeout 2
#脚本执行超时值，超过该值则认为本次脚本执行失败（并不是失败就降优先级，失败次数达到fall的值才认为会降级）
通过线下测试发现，我们的脚本的执行时间的平均值在1.3s左右，因此timeout值建议，大于等于2，也不需要过长

weight -2
#当脚本的失败次数达到了fall的次数的时候，priority就按照该值进行降级，当成功的次数达到了rise的值的时候，priority就开始按照该值升级。
这个值的绝对值建议大于等于MASTER中设置的priority与BACKUP中priority的值的差

fall 3
#脚本执行不成功（超时）多少次，才会触发priority下降,建议为2或者3都可以

rise 1
#脚本执行成功多少次，才会触发priority上升，建议为1

通过以上分析，可以知道，在我们写vrrp_script配置的时候，最好把以上的参数都写上，才会减少出问题的机率,如下：

vrrp_script chk_haproxy {
#    script "/etc/keepalived/haproxy_check.sh"
    script "/etc/keepalived/test.sh"
    interval 1
    timeout 2
    weight -2
    fall 3
    rise 1
}

验证一下猜想

1、测试超时

配置如下，其中timeout设置为2秒，fall为3次，rise为1次。
结果我们预期一致，那么当脚本超时3次，在2:41:04秒，主节点（192.168.0.105）的priority改变为98，并让出VIP。

当我们把脚本中的sleep注释掉，之后，我们发现主节点192.168.0.105的priority再次回到了100，与预期一致，时间为2:42:08

我们再看一下日志，在2:41:04秒，发生超时，进行VIP切换，2:42:08秒再切换回来，与我们抓包结果一致。