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

最新推荐文章于 2025-03-22 19:13:02 发布

Yonself

最新推荐文章于 2025-03-22 19:13:02 发布

阅读量3.4k

点赞数 1

分类专栏： IP 文章标签： keepalived

原文链接：http://www.linuxidc.com/Linux/2015-03/114981.htm

版权

IP 专栏收录该内容

1 篇文章

订阅专栏

一、故障描述

我在台湾合作方给定的两台虚拟机上部署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

}

}