Keepalive VIP 故障

Posted 2020-08-09 小怪兽的技术博客

前端环境如下：

              nginx + Keepalived ( MASTER ) --> node * 12
                    |
                    |
Cisco ASA --> VIP 1.18
                    |
                    |
              Nginx + Keepalived ( BACKUP )

问题描述：

客户端访问域名指向 Cisco ASA 外网端口，通过 NAT 地址转换到内网的 VIP 1.18，到达 Nginx 负载均衡器，之后将请求转向节点服务器。

故障时，客户端打开页面直接返回失败。

解决方法：

1、通过 Zabbix 监控发现 Cisco ASA 的外网接口流量正常。说明域名指向没有问题，请求已经到达防火墙。

2、登录防火墙查看地址映射表，发现地址映射正常。ping 1.18 也没有问题。

3、登录 Nginx 分发器，查看 VIP 处于绑定状态、Keepalived 处于 MASTER 状态、Nginx 服务处于运行状态。curl -I VIP 返回 200。

4、登录 Nginx BACKUP，发现处于 BACKUP 状态，也没有绑定 VIP。

5、实在没办法了，重启 Keepalived 之后发现服务正常。客户端访问无异常、故障恢复。

6、过了大概 5 小时左右，故障重现、一切如故。依然重启解决。( 03:20 )

7、又过了大概 5 小时左右，故障重现、一切如故。依然重启解决。( 08:20 )

8、经过各种查日志、设想、推理、google 后依然没有头绪，开始启用临时方案。

# 检测负载均衡器访问日志，如果前一分钟访问总数少于 500 条，则自动重启 Keepalived 记入 log、发邮件通知运维工程师。

#!/bin/bash
# Check Nginx access.log, Per minute is less than 500 restart Keepalived
# Wang 2016/09/09

dtime=`date -d ‘1 minute ago‘ +%Y:%H:%M`

num=`grep $dtime /data/logs/nginx/access.log | wc -l`

email=(‘[email protected]‘ ‘[email protected]‘ ‘[email protected]‘)

send_mail() {
  for addr in ${email[@]};do
    echo "$body" | /bin/mail -s "$subject" -r NGMA $addr
  done
}

if [ $num -lt 500 ];then
  body=‘Nginx access per minute is less than 500.‘
  echo `date +%F` $dtime $num >> re.log
  /etc/init.d/keepalived restart
  if [ $? -eq 0 ];then
    subject=‘S-Keepalived Restart‘
    send_mail $body $subject
  else
    subject=‘F-Keepalived Restart‘
    send_mail $body $subject
  fi
fi

# End

9、换换脑子继续排查故障。

shlle > ansible all-host -m shell -a ‘ip addr | grep 10.10.1.18‘，发现问题了，除了 Nginx MASTER 绑定了 VIP 后，还有三台机器也绑定了 VIP。

# 绑定 VIP 有三种情况：1、手动采用命令绑定 2、当作 LVS 节点服务器时，执行脚本绑定 3、当作 Keepalived MASTER 是程序绑定
# 目前这三台机器都不属于这三种情况，异常！

shell > ip -f inet addr delete 10.10.1.18/32 dev lo  # 从 lo 口删除 VIP 1.18

shell > ip -o -f inet addr show            # 再次查看，发现 VIP 已经删除

shell > /etc/init.d/keepalived restart     # 重启发现，其余机器没有再次绑定 VIP

10、进一步确认问题。

# 再次查看这三台服务器的流量图，发现其中有一台 1.10 的机器，在故障时间段的流量有一个小突发，应该是该机接管了 1.18，但又没有 WEB 服务，导致故障。

# 危机解除，故障之日至今14天，没有再次发生该故障。