阿里云-云小站(无限量代金券发放中)
【腾讯云】云服务器、云数据库、COS、CDN、短信等热卖云产品特惠抢购

Keepalived无法绑定VIP故障排查经历

682次阅读
没有评论

共计 16949 个字符,预计需要花费 43 分钟才能阅读完成。

一 故障描述
我在台湾合作方给定的两台虚拟机上部署 HAProxy+Keepalived 负载均衡高可用方案。在配置完 Keepalived 后,重新启动 Keepalived,Keepalived 没有绑定 VIP。

Keepalived 执行程序路径为 /data/app_platform/keepalived/sbin/keepalived
配置文件路径为 /data/app_platform/keepalived/conf/keepalived.conf 
Keepalived 的启动脚本为 /etc/init.d/keepalived

keepalived.conf 的内容
LB1 Master
! Configuration File for keepalived
 
global_defs {
  notification_email {
    admin@example.com
  }
  notification_email_from lb1@example.com
  smtp_server 127.0.0.1
  smtp_connect_timeout 30
  router_id LB1_MASTER
}
 
 vrrp_script chk_haproxy {
        script “killall -0 haproxy”
        interval 2
    weight 2
    }
 
 
 
 
vrrp_instance VI_1 {
    state MASTER
    interface eth1
    virtual_router_id 51
    priority 100
    advert_int 1
    authentication {
        auth_type PASS
        auth_pass 1111
    }
    virtual_ipaddress {
 
    10.1.1.200/24      brd 10.1.1.255      dev eth1 label eth1:vip
 
    }
 
    track_script {
        chk_haproxy
                }
}

重新启动 Keepalived 查看日志
Mar  3 18:09:00 cv00300005248-1 Keepalived[20138]: Stopping Keepalived v1.2.15 (02/28,2015)
Mar  3 18:09:00 cv00300005248-1 Keepalived[20259]: Starting Keepalived v1.2.15 (02/28,2015)
Mar  3 18:09:00 cv00300005248-1 Keepalived[20260]: Starting Healthcheck child process, pid=20261
Mar  3 18:09:00 cv00300005248-1 Keepalived[20260]: Starting VRRP child process, pid=20262
Mar  3 18:09:00 cv00300005248-1 Keepalived_vrrp[20262]: Registering Kernel netlink reflector
Mar  3 18:09:00 cv00300005248-1 Keepalived_vrrp[20262]: Registering Kernel netlink command channel
Mar  3 18:09:00 cv00300005248-1 Keepalived_vrrp[20262]: Registering gratuitous ARP shared channel
Mar  3 18:09:00 cv00300005248-1 Keepalived_healthcheckers[20261]: Registering Kernel netlink reflector
Mar  3 18:09:00 cv00300005248-1 Keepalived_healthcheckers[20261]: Registering Kernel netlink command channel
Mar  3 18:09:00 cv00300005248-1 Keepalived_healthcheckers[20261]: Configuration is using : 3924 Bytes
Mar  3 18:09:00 cv00300005248-1 Keepalived_healthcheckers[20261]: Using LinkWatch kernel netlink reflector…
Mar  3 18:09:00 cv00300005248-1 Keepalived_vrrp[20262]: Configuration is using : 55712 Bytes
Mar  3 18:09:00 cv00300005248-1 Keepalived_vrrp[20262]: Using LinkWatch kernel netlink reflector…
Mar  3 18:09:18 cv00300005248-1 kernel: __ratelimit: 1964 callbacks suppressed
Mar  3 18:09:18 cv00300005248-1 kernel: Neighbour table overflow.
Mar  3 18:09:18 cv00300005248-1 kernel: Neighbour table overflow.
Mar  3 18:09:18 cv00300005248-1 kernel: Neighbour table overflow.
Mar  3 18:09:18 cv00300005248-1 kernel: Neighbour table overflow.
Mar  3 18:09:18 cv00300005248-1 kernel: Neighbour table overflow.
Mar  3 18:09:18 cv00300005248-1 kernel: Neighbour table overflow.
Mar  3 18:09:18 cv00300005248-1 kernel: Neighbour table overflow.
Mar  3 18:09:18 cv00300005248-1 kernel: Neighbour table overflow.
Mar  3 18:09:18 cv00300005248-1 kernel: Neighbour table overflow.
Mar  3 18:09:18 cv00300005248-1 kernel: Neighbour table overflow.

查看 VIP 绑定情况
$ ifconfig eth1:vip
eth1:vip  Link encap:Ethernet  HWaddr 00:16:3E:F2:37:6B 
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          Interrupt:13

没有 VIP 绑定

二 排查过程

1)检查 VIP 的配置情况
向合作方确认提供的 VIP 的详细情况

IPADDR  10.1.1.200
NETMASK  255.255.255.0
GATEWAY  10.1.1.1
Brodcast  10.1.1.255
 
这里设置的是

10.1.1.200/24      brd 10.1.1.255      dev eth1 label eth1:vip

2)检查 iptables 和 selinux 的设置情况
$ sudo service iptables stop
$ sudo setenforce 0
setenforce: SELinux is disabled

如果非要开启 iptables 的话,需要作些设定

iptables -I INPUT -i eth1 -d 224.0.0.0/8 -j ACCEPT
service iptables save

keepalived 使用 224.0.0.18 作为 Master 和 Backup 健康检查的通信 IP

3)检查相关的内核参数
HAProxy+Keepalived 架构需要注意的内核参数有:

# Controls IP packet forwarding
net.ipv4.ip_forward = 1
开启 IP 转发功能

net.ipv4.ip_nonlocal_bind = 1
开启允许绑定非本机的 IP

如果使用 LVS 的 DR 或者 TUN 模式结合 Keepalived 需要在后端真实服务器上特别设置两个 arp 相关的参数。这里也设置好。
net.ipv4.conf.lo.arp_ignore = 1
net.ipv4.conf.lo.arp_announce = 2
net.ipv4.conf.all.arp_ignore = 1
net.ipv4.conf.all.arp_announce = 2

4)检查 VRRP 的设置情况
LB1 Master
state MASTER
    interface eth1
    virtual_router_id 51
    priority 100

LB2 Backup
state BACKUP
    interface eth1
    virtual_router_id 51
    priority 99

Master 和 Backup 的 virtual_router_id 需要一样,priority 需要不一样,数字越大,优先级越高

5)怀疑是编译安装 Keepalived 版本出现了问题
重新下载并编译 2.1.13 的版本,并重新启动 keepalived,VIP 仍然没有被绑定。

线上有个平台的 keepalived 是通过 yum 安装的,于是打算先用 yum 安装 keepalived 后将配置文件复制过去看看是否可以绑定 VIP

rpm -ivh http://ftp.linux.ncsu.edu/pub/epel/6/x86_64/epel-release-6-8.noarch.rpm
yum -y install keepalived

cp /data/app_platform/keepalived/conf/keepalived.conf  /etc/keepalived/keepalived.conf

重新启动 keepalived

然后查看日志
Mar  4 16:42:46 xxxxx Keepalived_healthcheckers[17332]: Registering Kernel netlink reflector
Mar  4 16:42:46 xxxxx Keepalived_healthcheckers[17332]: Registering Kernel netlink command channel
Mar  4 16:42:46 xxxxx Keepalived_vrrp[17333]: Opening file ‘/etc/keepalived/keepalived.conf’.
Mar  4 16:42:46 xxxxx Keepalived_vrrp[17333]: Configuration is using : 65250 Bytes
Mar  4 16:42:46 xxxxx Keepalived_vrrp[17333]: Using LinkWatch kernel netlink reflector…
Mar  4 16:42:46 xxxxx Keepalived_vrrp[17333]: VRRP sockpool: [ifindex(3), proto(112), unicast(0), fd(10,11)]
Mar  4 16:42:46 xxxxx Keepalived_healthcheckers[17332]: Opening file ‘/etc/keepalived/keepalived.conf’.
Mar  4 16:42:46 xxxxx Keepalived_healthcheckers[17332]: Configuration is using : 7557 Bytes
Mar  4 16:42:46 xxxxx Keepalived_healthcheckers[17332]: Using LinkWatch kernel netlink reflector…
Mar  4 16:42:46 xxxxx Keepalived_vrrp[17333]: VRRP_Script(chk_haproxy) succeeded
Mar  4 16:42:47 xxxxx Keepalived_vrrp[17333]: VRRP_Instance(VI_1) Transition to MASTER STATE
Mar  4 16:42:48 xxxxx Keepalived_vrrp[17333]: VRRP_Instance(VI_1) Entering MASTER STATE
Mar  4 16:42:48 xxxxx Keepalived_vrrp[17333]: VRRP_Instance(VI_1) setting protocol VIPs.
Mar  4 16:42:48 xxxxx Keepalived_vrrp[17333]: VRRP_Instance(VI_1) Sending gratuitous ARPs on eth1 for 10.1.1.200
Mar  4 16:42:48 xxxxx Keepalived_healthcheckers[17332]: Netlink reflector reports IP 10.1.1.200 added
Mar  4 16:42:53 xxxxx Keepalived_vrrp[17333]: VRRP_Instance(VI_1) Sending gratuitous ARPs on eth1 for 10.1.1.200

再查看 IP 绑定情况
$ ifconfig eth1:vip
eth1:vip  Link encap:Ethernet  HWaddr 00:16:3E:F2:37:6B 
          inet addr:10.1.1.200  Bcast:10.1.1.255  Mask:255.255.255.0
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          Interrupt:13

再通过 yum 将 keepalived 卸载掉
yum remove keepalived
恢复到原来的启动脚本 /etc/init.d/keepalived
重新启动 keepalived 后还是无法绑定 VIP

怀疑是 keepalived 启动脚本 /etc/init.d/keepalived 的问题
检查 /etc/init.d/keepalived
# Source function library.
. /etc/rc.d/init.d/functions
 
exec=”/data/app_platform/keepalived/sbin/keepalived”
prog=”keepalived”
config=”/data/app_platform/keepalived/conf/keepalived.conf”
 
[-e /etc/sysconfig/$prog] && . /etc/sysconfig/$prog
 
lockfile=/var/lock/subsys/keepalived
 
start() {
    [-x $exec] || exit 5
    [-e $config] || exit 6
    echo -n $”Starting $prog: ”
    daemon $exec $KEEPALIVED_OPTIONS
    retval=$?
    echo
    [$retval -eq 0] && touch $lockfile
    return $retval
}

关键是这一行
daemon $exec $KEEPALIVED_OPTIONS

由于没有复制 /etc/sysconfig/keepalived, 所以将直接执行 damon /data/app_platform/keepalived/sbin/keepalived
由于 keepalived 默认使用的是 /etc/keepalived/keepalived.conf 作为配置文件,而这里指定了不同的配置文件,所以要修改成为
daemon $exec -D -f $config

重新启动 keepalived,查看日志和 VIP 绑定情况
$ ifconfig eth1:vip
eth1:vip  Link encap:Ethernet  HWaddr 00:16:3E:F2:37:6B 
          inet addr:10.1.1.200  Bcast:10.1.1.255  Mask:255.255.255.0
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          Interrupt:13

6)将 LB2 Backup 的 keepalived 启动脚本也修改一下,观察 VIP 接管情况
查看 LB1 Master

$ ifconfig eth1:vip
eth1:vip  Link encap:Ethernet  HWaddr 00:16:3E:F2:37:6B 
          inet addr:10.1.1.200  Bcast:10.1.1.255  Mask:255.255.255.0
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          Interrupt:13

查看 LB2 Backup
$ ifconfig eth1:vip
eth1:vip  Link encap:Ethernet  HWaddr 00:16:3E:F2:37:6B 
          inet addr:10.1.1.200  Bcast:10.1.1.255  Mask:255.255.255.0
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          Interrupt:13

问题出现了,LB1 Master 和 LB2 Backup 都绑定了 VIP 10.1.1.200,这是不正常的!!!!

在 LB1 和 LB2 上登录 10.1.1.200 看看

[lb1 ~]$ ssh 10.1.1.200 
Last login: Wed Mar  4 17:31:33 2015 from 10.1.1.200
[lb1 ~]$

[lb2 ~]$ ssh 10.1.1.200
Last login: Wed Mar  4 17:54:57 2015 from 101.95.153.246
[b2  ~]$

在 LB1 上停掉 keepalived,ping 下 10.1.1.200 这个 IP,发现无法 ping 通
在 LB2 上停掉 keepalived,ping 下 10.1.1.200 这个 IP,发现也无法 ping 通

然后开启 LB1 上的 keepalived,LB1 上可以 ping 通 10.1.1.200,LB2 上不行

开启 LB2 上的 keepalived,LB2 上可以 ping 通 10.1.1.200

由此得出,LB1 和 LB2 各自都将 VIP 10.1.1.200 绑定到本机的 eth1 网卡上。两台主机并没有 VRRP 通信,没有 VRRP 的优先级比较。

7)排查影响 VRRP 通信的原因
重新启动 LB1 Master 的 Keepalived 查看日志
Mar  5 15:45:36 gintama-taiwan-lb1 Keepalived_vrrp[32303]: Configuration is using : 65410 Bytes
Mar  5 15:45:36 gintama-taiwan-lb1 Keepalived_vrrp[32303]: Using LinkWatch kernel netlink reflector…
Mar  5 15:45:36 gintama-taiwan-lb1 Keepalived_vrrp[32303]: VRRP sockpool: [ifindex(3), proto(112), unicast(0), fd(10,11)]
Mar  5 15:45:36 gintama-taiwan-lb1 Keepalived_vrrp[32303]: VRRP_Script(chk_haproxy) succeeded
Mar  5 15:45:37 gintama-taiwan-lb1 Keepalived_vrrp[32303]: VRRP_Instance(VI_1) Transition to MASTER STATE
Mar  5 15:45:38 gintama-taiwan-lb1 Keepalived_vrrp[32303]: VRRP_Instance(VI_1) Entering MASTER STATE
Mar  5 15:45:38 gintama-taiwan-lb1 Keepalived_vrrp[32303]: VRRP_Instance(VI_1) setting protocol VIPs.
Mar  5 15:45:38 gintama-taiwan-lb1 Keepalived_vrrp[32303]: VRRP_Instance(VI_1) Sending gratuitous ARPs on eth1 for 10.1.1.200
Mar  5 15:45:38 gintama-taiwan-lb1 Keepalived_healthcheckers[32302]: Netlink reflector reports IP 10.1.1.200 added
Mar  5 15:45:43 gintama-taiwan-lb1 Keepalived_vrrp[32303]: VRRP_Instance(VI_1) Sending gratuitous ARPs on eth1 for 10.1.1.200

发现 LB1 Master 上的 Keepalived 直接进入 Master 状态,然后接管 VIP

再重新启动 LB2 Backup 上的 Keepalived,查看日志
Mar  5 15:47:42 gintama-taiwan-lb2 Keepalived_vrrp[30619]: Configuration is using : 65408 Bytes
Mar  5 15:47:42 gintama-taiwan-lb2 Keepalived_vrrp[30619]: Using LinkWatch kernel netlink reflector…
Mar  5 15:47:42 gintama-taiwan-lb2 Keepalived_vrrp[30619]: VRRP_Instance(VI_1) Entering BACKUP STATE
Mar  5 15:47:42 gintama-taiwan-lb2 Keepalived_vrrp[30619]: VRRP sockpool: [ifindex(3), proto(112), unicast(0), fd(10,11)]
Mar  5 15:47:46 gintama-taiwan-lb2 Keepalived_vrrp[30619]: VRRP_Instance(VI_1) Transition to MASTER STATE
Mar  5 15:47:47 gintama-taiwan-lb2 Keepalived_vrrp[30619]: VRRP_Instance(VI_1) Entering MASTER STATE
Mar  5 15:47:47 gintama-taiwan-lb2 Keepalived_vrrp[30619]: VRRP_Instance(VI_1) setting protocol VIPs.
Mar  5 15:47:47 gintama-taiwan-lb2 Keepalived_vrrp[30619]: VRRP_Instance(VI_1) Sending gratuitous ARPs on eth1 for 10.1.1.200
Mar  5 15:47:47 gintama-taiwan-lb2 Keepalived_healthcheckers[30618]: Netlink reflector reports IP 10.1.1.200 added
Mar  5 15:47:52 gintama-taiwan-lb2 Keepalived_vrrp[30619]: VRRP_Instance(VI_1) Sending gratuitous ARPs on eth1 for 10.1.1.200

可以看到 LB2 上的 Keepalived 先进入 BACKUP 状态,然后又转为 MASTER 状态,然后接管 VIP

这样就说明 VRRP 组播有问题。

既然 VRRP 组播有问题,就尝试使用单播发送 VRRP 报文。修改 LB1 和 LB2 的配置
LB1
添加以下配置
unicast_src_ip  10.1.1.12
    unicast_peer {
                  10.1.1.17
                }

LB2

添加以下配置
unicast_src_ip  10.1.1.17
 unicast_peer {
                  10.1.1.12
                }

unicast_src_ip 表示发送 VRRP 单播报文使用的源 IP 地址
unicast_peer 表示对端接收 VRRP 单播报文的 IP 地址

然后各自重新加载 keepalived,观察日志

LB1
Mar  5 16:13:35 gintama-taiwan-lb1 Keepalived_vrrp[2551]: VRRP_Instance(VI_1) setting protocol VIPs.
Mar  5 16:13:35 gintama-taiwan-lb1 Keepalived_vrrp[2551]: VRRP_Script(chk_haproxy) considered successful on reload
Mar  5 16:13:35 gintama-taiwan-lb1 Keepalived_vrrp[2551]: Configuration is using : 65579 Bytes
Mar  5 16:13:35 gintama-taiwan-lb1 Keepalived_vrrp[2551]: Using LinkWatch kernel netlink reflector…
Mar  5 16:13:35 gintama-taiwan-lb1 Keepalived_vrrp[2551]: VRRP sockpool: [ifindex(3), proto(112), unicast(1), fd(10,11)]
Mar  5 16:13:36 gintama-taiwan-lb1 Keepalived_vrrp[2551]: VRRP_Instance(VI_1) Transition to MASTER STATE
Mar  5 16:13:48 gintama-taiwan-lb1 Keepalived_vrrp[2551]: VRRP_Instance(VI_1) Received lower prio advert, forcing new election
Mar  5 16:13:48 gintama-taiwan-lb1 Keepalived_vrrp[2551]: VRRP_Instance(VI_1) Sending gratuitous ARPs on eth1 for 10.1.1.200
Mar  5 16:13:48 gintama-taiwan-lb1 Keepalived_vrrp[2551]: VRRP_Instance(VI_1) Received lower prio advert, forcing new election
Mar  5 16:13:48 gintama-taiwan-lb1 Keepalived_vrrp[2551]: VRRP_Instance(VI_1) Sending gratuitous ARPs on eth1 for 10.1.1.200

LB2
Mar  5 16:13:48 gintama-taiwan-lb2 Keepalived_vrrp[453]: VRRP_Instance(VI_1) Received higher prio advert
Mar  5 16:13:48 gintama-taiwan-lb2 Keepalived_vrrp[453]: VRRP_Instance(VI_1) Entering BACKUP STATE
Mar  5 16:13:48 gintama-taiwan-lb2 Keepalived_vrrp[453]: VRRP_Instance(VI_1) removing protocol VIPs.
Mar  5 16:13:48 gintama-taiwan-lb2 Keepalived_healthcheckers[452]: Netlink reflector reports IP 10.1.1.200 removed

查看 VIP 绑定情况,发现 LB2 上的 VIP 已经移除

在 LB1 上 LB2 上执行 ping 10.1.1.200 这个 VIP
[lb1 ~]$ ping -c 5 10.1.1.200
PING 10.1.1.200 (10.1.1.200) 56(84) bytes of data.
64 bytes from 10.1.1.200: icmp_seq=1 ttl=64 time=0.028 ms
64 bytes from 10.1.1.200: icmp_seq=2 ttl=64 time=0.020 ms
64 bytes from 10.1.1.200: icmp_seq=3 ttl=64 time=0.020 ms
64 bytes from 10.1.1.200: icmp_seq=4 ttl=64 time=0.021 ms
64 bytes from 10.1.1.200: icmp_seq=5 ttl=64 time=0.027 ms
 
— 10.1.1.200 ping statistics —
5 packets transmitted, 5 received, 0% packet loss, time 3999ms
rtt min/avg/max/mdev = 0.020/0.023/0.028/0.004 ms

[lb2 ~]$ ping -c 5 10.1.1.200 
PING 10.1.1.200 (10.1.1.200) 56(84) bytes of data.
 
— 10.1.1.200 ping statistics —
5 packets transmitted, 0 received, 100% packet loss, time 14000ms

当 LB1 接管 VIP 的时候 LB2 居然无法 ping 通 VIP,同样将 LB1 的 Keepalived 停掉,LB2 可以接管 VIP,但是在 LB1 上无法 ping 通这个 VIP

在 LB1 和 LB2 上进行抓包

lb1 ~]$ sudo tcpdump -vvv  -i eth1 host 10.1.1.17
tcpdump: listening on eth1, link-type EN10MB (Ethernet), capture size 65535 bytes
16:46:04.827357 IP (tos 0xc0, ttl 255, id 328, offset 0, flags [none], proto VRRP (112), length 40)
    10.1.1.12 > 10.1.1.17: VRRPv2, Advertisement, vrid 51, prio 102, authtype simple, intvl 1s, length 20, addrs: 10.1.1.200 auth “1111^@^@^@^@”
16:46:05.827459 IP (tos 0xc0, ttl 255, id 329, offset 0, flags [none], proto VRRP (112), length 40)
    10.1.1.12 > 10.1.1.17: VRRPv2, Advertisement, vrid 51, prio 102, authtype simple, intvl 1s, length 20, addrs: 10.1.1.200 auth “1111^@^@^@^@”
16:46:06.828234 IP (tos 0xc0, ttl 255, id 330, offset 0, flags [none], proto VRRP (112), length 40)
    10.1.1.12 > 10.1.1.17: VRRPv2, Advertisement, vrid 51, prio 102, authtype simple, intvl 1s, length 20, addrs: 10.1.1.200 auth “1111^@^@^@^@”
16:46:07.828338 IP (tos 0xc0, ttl 255, id 331, offset 0, flags [none], proto VRRP (112), length 40)
    10.1.1.12 > 10.1.1.17: VRRPv2, Advertisement, vrid 51, prio 102, authtype simple, intvl 1s, length 20, addrs: 10.1.1.200 auth “1111^@^@^@^@”

 

lb2 ~]$ sudo tcpdump -vvv -i eth1 host 10.1.1.12
tcpdump: listening on eth1, link-type EN10MB (Ethernet), capture size 65535 bytes
16:48:07.000029 IP (tos 0xc0, ttl 255, id 450, offset 0, flags [none], proto VRRP (112), length 40)
    10.1.1.12 > 10.1.1.17: VRRPv2, Advertisement, vrid 51, prio 102, authtype simple, intvl 1s, length 20, addrs: 10.1.1.200 auth “1111^@^@^@^@”
16:48:07.999539 IP (tos 0xc0, ttl 255, id 451, offset 0, flags [none], proto VRRP (112), length 40)
    10.1.1.12 > 10.1.1.17: VRRPv2, Advertisement, vrid 51, prio 102, authtype simple, intvl 1s, length 20, addrs: 10.1.1.200 auth “1111^@^@^@^@”
16:48:08.999252 IP (tos 0xc0, ttl 255, id 452, offset 0, flags [none], proto VRRP (112), length 40)
    10.1.1.12 > 10.1.1.17: VRRPv2, Advertisement, vrid 51, prio 102, authtype simple, intvl 1s, length 20, addrs: 10.1.1.200 auth “1111^@^@^@^@”
16:48:09.999560 IP (tos 0xc0, ttl 255, id 453, offset 0, flags [none], proto VRRP (112), length 40)
    10.1.1.12 > 10.1.1.17: VRRPv2, Advertisement, vrid 51, prio 102, authtype simple, intvl 1s, length 20, addrs: 10.1.1.200 auth “1111^@^@^@^@”

在 LB1 和 LB2 所在物理机上的其他虚拟机进行 VIP ping 测试,同样只能是 LB1 上绑定的 VIP 只能是 LB1 所在的物理机上的虚拟机可以 ping 通,LB2 所在的物理机上的虚拟机无法 ping 通,反之也是一样

有同行建议说 VRRP 和 DHCP 也有关系,经过查看对方提供的 VM 的 IP 地址居然是 DHCP 分配的,但是经过测试,VRRP 和 DHCP 没有关系。线上环境最好不要使用 DHCP 来获取 IP 地址。

8)请对方技术人员配合检查 VIP 无法 ping 通的问题
最终查明对方的内网居然使用的虚拟网络,网关是没有实际作用的。所以部分虚拟机无法通过 10.1.1.1 这个网关去访问 VIP。

让对方虚拟机提供方的技术人员到服务器调试 HAProxy+Keepalived,他们通过网络设置使得 10.1.1.200 这个 VIP 可以通过内网访问。但是当我测试时,发现当 HAProxy 挂掉后,Keepalived 无法作 VIP 的切换。

9)解决当 HAProxy 挂掉后,Keepalived 无法对 VIP 切换的问题。
经过反复测试,发现当 Keepalived 挂掉后,VIP 可以切换。但是当 HAProxy 挂掉后,VIP 无法切换。
仔细检查配置文件和查阅相关资料,最终确定是 Keepalived 的 weight 和 priority 两个参数的大小设置问题。

原来的配置文件中我设置 LB1 的 weight 为 2,priority 为 100。LB2 的 weight 为 2,priority 为 99

对方在调试的时候将 LB1 的 priority 更改为 160. 这样反复测试当 LB1 的 HAProxy 挂掉后,VIP 都无法迁移到 LB2 上。将 LB1 上的 priority 更改为 100 就可以了。

这里需要注意的是:
主 keepalived 的 priority 值与 vrrp_script 的 weight 值相减的数字小于备用 keepalived 的 priority 值即可!

vrrp_script 里的 script 返回值为 0 时认为检测成功,其它值都会当成检测失败

* weight 为正时,脚本检测成功时此 weight 会加到 priority 上,检测失败时不加。

主失败:
            主 priority < 从 priority + weight 时会切换。

主成功:
            主 priority + weight > 从 priority + weight 时,主依然为主

* weight 为负时,脚本检测成功时此 weight 不影响 priority,检测失败时 priority – abs(weight)

主失败:
          主 priority – abs(weight) < 从 priority 时会切换主从

主成功:
          主 priority > 从 priority 主依然为主。

最终的配置文件为:
! Configuration File for keepalived
 
global_defs {
  notification_email {
    admin@example.com
  }
  notification_email_from lb1@example.com
  smtp_server 127.0.0.1
  smtp_connect_timeout 30
  router_id LB1_MASTER
}
 
 vrrp_script chk_haproxy {
    script “killall -0 haproxy”
    interval 2
    weight 2
    }
 
 
 
 
# 设置外网的 VIP
vrrp_instance eth0_VIP {
    state MASTER
    interface eth0
    virtual_router_id 51
    priority 100
    advert_int 1
    authentication {
        auth_type PASS
        auth_pass 1111
    }
    unicast_src_ip  8.8.8.6        #使用 VRRP 的单播
    unicast_peer {
                  8.8.8.7
                }
    virtual_ipaddress {
    8.8.8.8/25  brd 8.8.8.255  dev eth0 label eth0:vip
 
    }
 
    track_script {
        chk_haproxy
                }
}
 
 
# 设置内网的 VIP
vrrp_instance eth1_VIP {
    state MASTER
    interface eth1
    virtual_router_id 52
    priority 100
    advert_int 1
    authentication {
        auth_type PASS
        auth_pass 1111
    }
    unicast_src_ip  10.1.1.12
    unicast_peer {
                  10.1.1.17
                }
    virtual_ipaddress {
    10.1.1.200/24    brd 10.1.1.255      dev eth1 label eth1:vip
 
    }
 
    track_script {
        chk_haproxy
                }

三 排查总结
在配置 Keepalived 的时候,需要注意以下几点:

A. 内核开启 IP 转发和允许非本地 IP 绑定功能,如果是使用 LVS 的 DR 模式还需设置两个 arp 相关的参数。
B. 如果 Keepalived 所在网络不允许使用组播,可以使用 VRRP 单播
C. 需要注意主备的 weight 和 priority 的值,这两个值如果设置不合理可能会影响 VIP 的切换。
D. 如果使用的配置文件不是默认的配置文件,在启动 Keepalived 的时候需要使用 -f 参数指定配置文件。

CentOS 6.3 下 Haproxy+Keepalived+Apache 配置笔记 http://www.linuxidc.com/Linux/2013-06/85598.htm

Haproxy + KeepAlived 实现 WEB 群集 on CentOS 6 http://www.linuxidc.com/Linux/2012-03/55672.htm

Keepalived+Haproxy 配置高可用负载均衡 http://www.linuxidc.com/Linux/2012-03/56748.htm

Haproxy+Keepalived 构建高可用负载均衡 http://www.linuxidc.com/Linux/2012-03/55880.htm

CentOS 7 上配置 LVS + Keepalived + ipvsadm http://www.linuxidc.com/Linux/2014-11/109237.htm

Keepalived 高可用集群搭建 http://www.linuxidc.com/Linux/2014-09/106965.htm

Keepalived 的详细介绍:请点这里
Keepalived 的下载地址:请点这里

本文永久更新链接地址:http://www.linuxidc.com/Linux/2015-03/114981.htm

正文完
星哥玩云-微信公众号
post-qrcode
 0
星锅
版权声明:本站原创文章,由 星锅 于2022-01-20发表,共计16949字。
转载说明:除特殊说明外本站文章皆由CC-4.0协议发布,转载请注明出处。
【腾讯云】推广者专属福利,新客户无门槛领取总价值高达2860元代金券,每种代金券限量500张,先到先得。
阿里云-最新活动爆款每日限量供应
评论(没有评论)
验证码
【腾讯云】云服务器、云数据库、COS、CDN、短信等云产品特惠热卖中

星哥玩云

星哥玩云
星哥玩云
分享互联网知识
用户数
4
文章数
19351
评论数
4
阅读量
7980561
文章搜索
热门文章
星哥带你玩飞牛NAS-6:抖音视频同步工具,视频下载自动下载保存

星哥带你玩飞牛NAS-6:抖音视频同步工具,视频下载自动下载保存

星哥带你玩飞牛 NAS-6:抖音视频同步工具,视频下载自动下载保存 前言 各位玩 NAS 的朋友好,我是星哥!...
星哥带你玩飞牛NAS-3:安装飞牛NAS后的很有必要的操作

星哥带你玩飞牛NAS-3:安装飞牛NAS后的很有必要的操作

星哥带你玩飞牛 NAS-3:安装飞牛 NAS 后的很有必要的操作 前言 如果你已经有了飞牛 NAS 系统,之前...
我把用了20年的360安全卫士卸载了

我把用了20年的360安全卫士卸载了

我把用了 20 年的 360 安全卫士卸载了 是的,正如标题你看到的。 原因 偷摸安装自家的软件 莫名其妙安装...
再见zabbix!轻量级自建服务器监控神器在Linux 的完整部署指南

再见zabbix!轻量级自建服务器监控神器在Linux 的完整部署指南

再见 zabbix!轻量级自建服务器监控神器在 Linux 的完整部署指南 在日常运维中,服务器监控是绕不开的...
飞牛NAS中安装Navidrome音乐文件中文标签乱码问题解决、安装FntermX终端

飞牛NAS中安装Navidrome音乐文件中文标签乱码问题解决、安装FntermX终端

飞牛 NAS 中安装 Navidrome 音乐文件中文标签乱码问题解决、安装 FntermX 终端 问题背景 ...
阿里云CDN
阿里云CDN-提高用户访问的响应速度和成功率
随机文章
【开源神器】微信公众号内容单篇、批量下载软件

【开源神器】微信公众号内容单篇、批量下载软件

【开源神器】微信公众号内容单篇、批量下载软件 大家好,我是星哥,很多人都希望能高效地保存微信公众号的文章,用于...
免费领取huggingface的2核16G云服务器,超简单教程

免费领取huggingface的2核16G云服务器,超简单教程

免费领取 huggingface 的 2 核 16G 云服务器,超简单教程 前言 HuggingFace.co...
亚马逊云崩完,微软云崩!当全球第二大云“摔了一跤”:Azure 宕机背后的配置风险与警示

亚马逊云崩完,微软云崩!当全球第二大云“摔了一跤”:Azure 宕机背后的配置风险与警示

亚马逊云崩完,微软云崩!当全球第二大云“摔了一跤”:Azure 宕机背后的配置风险与警示 首先来回顾一下 10...
星哥带你玩飞牛NAS硬件02:某鱼6张左右就可拿下5盘位的飞牛圣体NAS

星哥带你玩飞牛NAS硬件02:某鱼6张左右就可拿下5盘位的飞牛圣体NAS

星哥带你玩飞牛 NAS 硬件 02:某鱼 6 张左右就可拿下 5 盘位的飞牛圣体 NAS 前言 大家好,我是星...
星哥带你玩飞牛NAS-16:飞牛云NAS换桌面,fndesk图标管理神器上线!

星哥带你玩飞牛NAS-16:飞牛云NAS换桌面,fndesk图标管理神器上线!

  星哥带你玩飞牛 NAS-16:飞牛云 NAS 换桌面,fndesk 图标管理神器上线! 引言 哈...

免费图片视频管理工具让灵感库告别混乱

一言一句话
-「
手气不错
仅2MB大小!开源硬件监控工具:Win11 无缝适配,CPU、GPU、网速全维度掌控

仅2MB大小!开源硬件监控工具:Win11 无缝适配,CPU、GPU、网速全维度掌控

还在忍受动辄数百兆的“全家桶”监控软件?后台偷占资源、界面杂乱冗余,想查个 CPU 温度都要层层点选? 今天给...
星哥带你玩飞牛NAS硬件02:某鱼6张左右就可拿下5盘位的飞牛圣体NAS

星哥带你玩飞牛NAS硬件02:某鱼6张左右就可拿下5盘位的飞牛圣体NAS

星哥带你玩飞牛 NAS 硬件 02:某鱼 6 张左右就可拿下 5 盘位的飞牛圣体 NAS 前言 大家好,我是星...
手把手教你,购买云服务器并且安装宝塔面板

手把手教你,购买云服务器并且安装宝塔面板

手把手教你,购买云服务器并且安装宝塔面板 前言 大家好,我是星哥。星哥发现很多新手刚接触服务器时,都会被“选购...
支付宝、淘宝、闲鱼又双叕崩了,Cloudflare也瘫了连监控都挂,根因藏在哪?

支付宝、淘宝、闲鱼又双叕崩了,Cloudflare也瘫了连监控都挂,根因藏在哪?

支付宝、淘宝、闲鱼又双叕崩了,Cloudflare 也瘫了连监控都挂,根因藏在哪? 最近两天的互联网堪称“故障...
自己手撸一个AI智能体—跟创业大佬对话

自己手撸一个AI智能体—跟创业大佬对话

自己手撸一个 AI 智能体 — 跟创业大佬对话 前言 智能体(Agent)已经成为创业者和技术人绕...