标签：yum 两种 主服务器 sts 失效 定义 配置文件说明 检测 mod
Keepalived高可用之间是通过VRRP通信的，因此，我从VRRP开始给您讲起：
介绍完了VRRP，接下来我再介绍一下Keepalived服务的工作原理：
| HOSTNAME | IP | 说明 |
|---|---|---|
| lb01 | 192.168.103.121 | Keepalived主服务器（Nginx主负载均衡器） |
| lb02 | 192.168.103.122 | Keepalived备服务器（Nginx备负载均衡器） |
| web01 | 192.168.103.123 | web01服务器 |
| web02 | 192.168.103.124 | web02服务器 |
说明:下面有关Keepalived安装，启动服务的操作都是同时处理lb01，lb02两台机器。
可通过官方地址获取Keepalived源码软件包编译安装，也可以使用yum的安装方式直接安装，这里选择更为简便额后者--yum安装方式，下面以lb01为例，介绍整个安装步骤，如下：
//lb01 [root@lb01 /]# yum install keepalived -y [root@lb01 /]# rpm -qa keepalived keepalived-1.3.5-8.el7_6.5.x86_64 //lb02 [root@lb02 /]# yum install keepalived -y [root@lb02 /]# rpm -qa keepalived keepalived-1.3.5-8.el7_6.5.x86_64
提示：
1）上述安装过程需要在lb01和lb02两台服务器上同时安装。
2）Keepalived版本为3.5版
启动服务命令：
service keepalived start
systemctl enable keepalived.service
建议查找资料将服务做成开机自动运行。
检查服务是否正常启动敲如下命令查看日志：
journalctl -xe
和其他使用yum安装的软件一样，Keepalived软件的配置文件默认路径及配置文件名为：
[root@lb01 /]# ls -l /etc/keepalived/keepalived.conf -rw-r--r--. 1 root root 3598 7月 30 01:19 /etc/keepalived/keepalived.conf
前面已经说过，Keepalived软件有3个主要功能，而这里仅讲解其高可用部分的功能。
这里的具备高可用功能的Keepalived.conf配置文件包含了两个重要区块，下面会分别说明
global_defs { notification_email { # 定义服务故障报警的Email地址。作用是当服务发生切换或RS节点等有故障时，发报警邮件。这几行是可选配置，notification_email指定在Keepalived发生事件时，需要发送的Email地址，可以有多个，每行一个。【可选的配置】 acassen@firewall.loc failover@firewall.loc sysadmin@firewall.loc } notification_email_from Alexandre.Cassen@firewall.loc # 指定发送邮件的发送人，即发件人地址。【可选的配置】 smtp_server 192.168.200.1 # 指定发送邮件的smtp服务器，如果本机开启了sendmail或postfix，就可以使用上面默认配置实现邮件发送。【可选配置】 smtp_connect_timeout 30 # 接smtp的超时时间。【可选配置】 router_id LVS_DEVEL # Keepalived服务器的路由标识（router_id）.在一个局域网内，这个标识（router_id）应该是唯一的。建议使用机器名【【必须】】 vrrp_skip_check_adv_addr # 检查vrrp报文中的所有地址比较耗时，设置此标志的意思是如果接收的到报文和上一个报文来至同一个路由器，则不执行检查。默认是跳过检查 vrrp_strict # 严格执行VRRP协议规范，此模式不支持节点单播，引起vip问题的就是这个参数 vrrp_garp_interval 0 vrrp_gna_interval 0 }
建议去掉红色标注部分
大括号“{}”。用来分隔区块，要成对出现。如果漏写了半个大括号，Keepalived运行时，不会报错，但也不会得到预期的结果。另外，由于区块间存在多层嵌套关系，因此很容易遗漏区块结尾处的大括号，要特别注意。
vrrp_instance VI_1 { # 表示定义一个vrrp_instance实例，名字是VI_1,每个vrrp_instance实例可以认为是Keepalived服务的一个实例或者作为一个业务服务，在Keepalived服务配置中，这样的vrrp_instance实例可以有多个。注意，【存在于主节点中的vrrp_instance实例在备节点中也要存在，这样才能实现故障切换接管】 state MASTER # 表示当前实例VI_1的【角色状态】，当前角色为MASTER，这个状态只能有【MASTER】和【BACKUP】两种状态，并且需要【大写】这些字符。其中MASTER为正式工作的状态，BACKUP为备用的状态。当MASTER所在的服务器故障或失效时，BACKUP所在的服务器会接管故障的MASTER继续提供服务。 interface eth0 # 网络通信接口。为对外提供服务的网络接口，如eth0,eth1。当前主流的服务器都有2~4个网络接口，在选择服务接口时，要搞清楚了。 virtual_router_id 51 # 虚拟路由ID标识，这个标识最好是一个【数字】，并且要在一个keepalived.conf配置中是【唯一的】。【但是MASTER和BACKUP配置中相同实例的virtual_router_id又必须是【一致的】，否则将出现脑裂问题。】 priority 100 # 数字越大，表示实例优先级越高。在同一个vrrp_instance实例里，MASTER的优先级配置要高于BACKUP的。若MASTER的priority值为150，那么BACKUP的priority必须小于150，一般建议【间隔50以上为佳】，例如：设置BACKUP的priority为100或更小的数值。 advert_int 1 # 同步通知间隔。MASTER与BACKUP之间通信检查的时间间隔，单位为秒，默认为1. authentication { # 权限认证配置。包含认证类型（auth_type）和认证密码（auth_pass）。 auth_type PASS # 认证类型有PASS（Simple Passwd（suggested）），AH（IPSEC（not recommended））两种，官方推荐使用的类型为PASS。 auth_pass 1111 # 验证密码为明文方式，最好长度不要超过8个字符，建议用4位数字，同一vrrp实例的MASTER与BACKUP使用相同的密码才能正常通信。 } virtual_ipaddress { # 虚拟IP地址。可以配置多个IP地址，每个地址占一行，配置时最好明确指定子网掩码以及虚拟IP绑定的网络接口。否则，子网掩码默认是32位，绑定的接口和前面的interface参数配置的一致。注意，这里的虚拟IP就是在工作中需要和域名绑定的IP，即和配置的高可用服务监听的IP要保持一致！ 192.168.200.16 192.168.200.17 192.168.200.18 } }
[root@lb01 /]# vim /etc/keepalived/keepalived.conf ! Configuration File for keepalived global_defs { notification_email { 786744873@qq.com # 邮箱随便写 } notification_email_from Alexandre.Cassen@firewall.loc smtp_server 127.0.0.1 # 邮件服务器IP smtp_connect_timeout 30 router_id lb01 # id为lb1，不能和其他Keepalived节点相同（全局唯一） } vrrp_instance VI_1 { # 实例名字为VI_1,相同实例的备节点名字要和这个相同 state MASTER # 状态为MASTER，备节点状态需要为BACKUP interface enp0s3 # 通信（心跳）接口enp0s3，此参数备节点设置和主节点相同，实际上是网卡名称 virtual_router_id 55 # 实例ID为55，要和备节点相同 priority 150 # 优先级为150，备节点的优先级必须比此数字低 advert_int 1 # 通信检查间隔时间1秒 authentication { auth_type PASS # PASS认证类型，此参数备节点设置和主节点相同 auth_pass 1111 # 密码1111，此参数备节点设置和主节点相同 } virtual_ipaddress { 192.168.103.120/24 dev enp0s3 label enp0s3:1 #虚拟IP，即VIP为192.168.103.120,子网掩码为24位，绑定接口为enp0s3，别名为enp0s3:1，此参数备节点设置和主节点相同 } }
[root@lb01 /]# service keepalived restart
[root@lb01 /]# ip a | grep 192.168.103.120 inet 192.168.103.120/24 scope global secondary enp0s3:1
[root@lb02 /]# vim /etc/keepalived/keepalived.conf ! Configuration File for keepalived global_defs { notification_email { 786744873@qq.com } notification_email_from Alexandre.Cassen@firewall.loc smtp_server 127.0.0.1 smtp_connect_timeout 30 router_id lb02 # id为lb2，不能和其他Keepalived节点相同（全局唯一） } vrrp_instance VI_1 { state BACKUP #此参数和lb01 MASTER不同 interface enp0s3 virtual_router_id 55 priority 100 # 此参数和lb01 MASTER不同 advert_int 1 authentication { auth_type PASS auth_pass 1111 } virtual_ipaddress { 192.168.103.120/24 dev enp0s3 label enp0s3:1 } }
[root@lb02 /]# service keepalived restart
Redirecting to /bin/systemctl restart keepalived.service
[root@lb02 /]# ip a | grep 192,168.103.120 [root@lb02 /]#
这里没有返回任何结果就对了，因为lb02为BACKUP，当主节点活着的时候，它不会接管 192.168.103.120
// lb01 [root@lb01 /]# ip a | grep 192.168.103.120 #虚拟VIP在lb01服务器上 inet 192.168.103.120/24 scope global secondary enp0s3:1 [root@lb01 /]# service keepalived stop #停掉服务 Redirecting to /bin/systemctl stop keepalived.service [root@lb01 /]# ip a | grep 192.168.103.120 #虚拟VIP消失了 [root@lb01 /]# // lb02 [root@lb02 /]# ip a | grep 192.168.103.120 #虚拟VIP出现在了lb02上 inet 192.168.103.120/24 scope global secondary enp0s3:1
[root@lb01 /]# ip a | grep 192.168.103.120 #虚拟VIP在lb01服务器上 inet 192.168.103.120/24 scope global secondary enp0s3:1
说明：
这里仅实现了VIP的自动漂移切换，因此，仅适合两台服务器提供的服务均保持开启的应用场景，这也是工作中常用的高可用解决方案。
| Keepalived配置参数 | MASTER节点特殊参数 | BACKUP节点特殊参数 |
|---|---|---|
| router_id(唯一标识) | router_id lb01 | router_id lb02 |
| state（角色状态） | state MASTER | state BACKUP |
| priority(竞选优先级) | priority 150 | priority 100 |
由于某些原因，导致两台高可用服务器对在指定时间内，无法检测到对方的心跳消息，各自取得资源及服务的所有权，而此时的两台高可用服务器对都还活着并在正常运行，这样就会导致同一个IP或服务在两端同时存在而发生冲突，最严重的是两台主机占用同一个VIP地址，当用户写入数据时可能会分别写入到两端，这可能会导致服务器两端的数据不一致或造成数据丢失，这种情况就被称为裂脑。
一般来说，裂脑的发生，有以下几种原因：
提示：
Keepalived配置里同一VRRP实例如果virtual_router_id两端参数配置不一致，也会导致裂脑问题发生。
在实际生产环境中，我们可以从以下几个方面来防止裂脑问题的发生：
作为互联网应用服务器的高可用，特别是前端Web负载均衡器的高可用，裂脑的问题对普通业务的影响是可以忍受的，如果是数据库或者存储的业务，一般出现裂脑问题就非常严重了。因此，可以通过增加冗余心跳线路来避免裂脑问题的发生，同时加强对系统的监控，以便裂脑发生时人为快速介入解决问题。
下面是生产场景检测裂脑故障的一些思路：
前面给出的是Keepalived单实例主备模式的高可用演示，Keepalived还支持多实例多业务双向主备模式，即A业务在lb01上是主模式，在lb02上是备模式，而B业务在lb01上是备模式，在lb02上是主模式，下面就以双实例为例讲解不同业务实现双主的配置。
下图为Keepalived双实例双主模式IP及VIP规划表
| HOSTNAME | IP | 说明 |
|---|---|---|
| lb01 | 192.168.103.121 | VIP:192.168.103.120(用于绑定A服务www.yunjisuan.com域名) |
| lb02 | 192.168.103.122 | VIP:192.168.103.130(用于绑定B服务bbs.yunjisuan.com域名) |
[root@lb01 /]# vim /etc/keepalived/keepalived.conf
! Configuration File for keepalived
global_defs {
notification_email {
786744873@qq.com # 邮箱随便写
}
notification_email_from Alexandre.Cassen@firewall.loc
smtp_server 127.0.0.1 # 邮件服务器IP
smtp_connect_timeout 30
router_id lb01 # id为lb1，不能和其他Keepalived节点相同（全局唯一）
}
vrrp_instance VI_1 { # 实例名字为VI_1,相同实例的备节点名字要和这个相同
state MASTER # 状态为MASTER，备节点状态需要为BACKUP
interface enp0s3 # 通信（心跳）接口enp0s3，此参数备节点设置和主节点相同，实际上是网卡名称
virtual_router_id 55 # 实例ID为55，要和备节点相同
priority 150 # 优先级为150，备节点的优先级必须比此数字低
advert_int 1 # 通信检查间隔时间1秒
authentication {
auth_type PASS # PASS认证类型，此参数备节点设置和主节点相同
auth_pass 1111 # 密码1111，此参数备节点设置和主节点相同
}
virtual_ipaddress {
192.168.103.120/24 dev enp0s3 label enp0s3:1 #虚拟IP，即VIP为192.168.103.120,子网掩码为24位，绑定接口为enp0s3，别名为enp0s3:1，此参数备节点设置和主节点相同
}
}
vrrp_instance VI_2 {
state BACKUP
interface enp0s3
virtual_router_id 56
priority 100
advert_int 1
authentication {
auth_type PASS
auth_pass 1111
}
virtual_ipaddress {
192.168.103.130/24 dev enp0s3 label enp0s3:2 #虚拟IP，即VIP为192.168.103.130,子网掩码为24位，绑定接口为enp0s3，别名为enp0s3:2，此参数备节点设置和主节点相同
}
}
#提示： 以vrrp_instance VI_1在lb01 192.168.103.121服务器上的角色为主，vrrp_instance VI_2在lb01 192.168.103.121服务器上的角色为备。
[root@lb02 /]# vim /etc/keepalived/keepalived.conf
! Configuration File for keepalived
global_defs {
notification_email {
786744873@qq.com
}
notification_email_from Alexandre.Cassen@firewall.loc
smtp_server 127.0.0.1
smtp_connect_timeout 30
router_id lb02 # id为lb2，不能和其他Keepalived节点相同（全局唯一）
}
vrrp_instance VI_1 {
state BACKUP #此参数和lb01 MASTER不同
interface enp0s3
virtual_router_id 55
priority 100 # 此参数和lb01 MASTER不同
advert_int 1
authentication {
auth_type PASS
auth_pass 1111
}
virtual_ipaddress {
192.168.103.120/24 dev enp0s3 label enp0s3:1
}
}
vrrp_instance VI_2 {
state MASTER
interface enp0s3
virtual_router_id 56
priority 150
advert_int 1
authentication {
auth_type PASS
auth_pass 1111
}
virtual_ipaddress {
192.168.103.130/24 dev enp0s3 label enp0s3:2 #虚拟IP，即VIP为192.168.103.130,子网掩码为24位，绑定接口为enp0s3，别名为enp0s3:2，此参数备节点设置和主节点相同
}
}
#提示： 以vrrp_instance VI_1在lb02 192.168.103.121服务器上的角色为备，vrrp_instance VI_2在lb02 192.168.103.122服务器上的角色为主。
#关闭服务 [root@lb01 /]# service keepalived stop Redirecting to /bin/systemctl stop keepalived.service [root@lb02 /]# service keepalived stop Redirecting to /bin/systemctl stop keepalived.service #在lb01上进行如下操作： [root@lb01 keepalived]# service keepalived restart [root@lb01 keepalived]# ip a | egrep "192.168.103.120|192.168.103.130" inet 192.168.103.120/24 scope global secondary eth0:1 #由于lb02还没开服务 inet 192.168.103.130/24 scope global secondary eth0:2 #主备VIP都显示在lb01上 #在lb02上进行如下操作： [root@lb02 keepalived]# service keepalived restart [root@lb02 keepalived]# ip a | egrep "192.168.103.120|192.168.103.130" inet 192.168.103.130/24 scope global secondary eth0:2 #lb01开启的情况下，lb02开启服务后，只显示了vrrp_instance VI_2实例lb02作为主模式的VIP 192.168.103.130 #再次在lb01上进行如下操作： [root@lb01 ~]# ip a | egrep "120|130" inet 192.168.103.120/24 scope global secondary eth0:1 #lb01上只有192.168.103.120了。
特别提示：
如果测试结果不符，请查看是否没有关闭iptables
到此为止，我们发现lb01，lb02主备节点已经实现了初始配置的VIP服务状态，当任意一端宕机，VIP可以实现互相切换接管。在实际工作中，可以把www.yunjisuan.com解析到192.168.103.120提供服务，把bbs.yunjisuan.com解析到192.168.103.130提供服务，当然了，lb01，lb02也要配置相应服务，例如：Nginx反向代理服务等。
结合上节介绍的Nginx负载均衡的环境，调整好主负载均衡器lb01，备用负载均衡器lb02服务器上Nginx负载均衡环境，两台服务器的安装基础环境一模一样。
这里使用的Nginx负载均衡的配置如下：
[root@lb01 /]# vim /usr/local/nginx/conf/nginx.conf [root@lb02 /]# vim /usr/local/nginx/conf/nginx.conf worker_processes 1; events { worker_connections 1024; } http { include mime.types; default_type application/octet-stream; sendfile on; keepalive_timeout 65; upstream www_server_pools { server 192.168.103.123:80 weight=1; server 192.168.103.124:80 weight=1; } server { listen 80; server_name www.yunjisuan.com; location / { proxy_pass http://www_server_pools; proxy_set_header host $host; proxy_set_header X-Forwarded-For $remote_addr; } } }
提示：此配置仅代理了www.yunjisuan.com域名
Keepalived的配置与本节之前的实验配置一致。
准备工作如下：
（1）在客户端hosts文件里把www.yunjisuan.com域名解析到VIP 192.168.103.120上，正式场景需通过DNS解析。
（2）两台服务器配好Nginx负载均衡服务，并且确保后面代理的Web节点可以测试访问。
因为咱们暂时没有域名，所以无法测试
默认情况下Keepalived软件仅仅在对方机器宕机或Keepalived停掉的时候才会接管业务。但在实际工作中，有业务服务停止而Keepalived服务还在工作的情况，这就会导致用户访问的VIP无法找到对应的服务，那么，如何解决业务服务宕机可以将IP漂移到备节点使之接管提供服务呢？
# 此脚本的基本思想是若没有80端口存在，就停掉Keepalived服务实现释放本地的VIP。在后台执行上述脚本并检查： [root@lb01 /]# vim /etc/keepalived/check_nginx.sh #!/bin/sh while true do if [ `netstat -antup | grep nginx | wc -l` -ne 1 ];then service keepalived stop fi sleep 5 done # 启动脚本 [root@lb01 /]# sh /etc/keepalived/check_nginx.sh & [1] 18446 [root@lb01 /]# ps -ef | grep check | grep -v grep root 18446 32623 0 13:17 pts/0 00:00:00 sh /etc/keepalived/check_nginx.sh #确认Nginx以及Keepalived服务是正常的 [root@lb01 /]# netstat -antup | grep nginx tcp 0 0 0.0.0.0:80 0.0.0.0:* LISTEN 21620/nginx: master [root@lb01 /]# service keepalived status Redirecting to /bin/systemctl status keepalived.service ● keepalived.service - LVS and VRRP High Availability Monitor Loaded: loaded (/usr/lib/systemd/system/keepalived.service; enabled; vendor preset: disabled) Active: active (running) since 六 2019-08-31 13:31:51 CST; 44s ago Process: 22193 ExecStart=/usr/sbin/keepalived $KEEPALIVED_OPTIONS (code=exited, status=0/SUCCESS) #然后模拟Nginx服务挂掉，看IP是否发生切换。 [root@lb01 /]# /usr/local/nginx/sbin/nginx -s stop [root@lb01 /]# service keepalived status Redirecting to /bin/systemctl status keepalived.service ● keepalived.service - LVS and VRRP High Availability Monitor Loaded: loaded (/usr/lib/systemd/system/keepalived.service; enabled; vendor preset: disabled) Active: inactive (dead) since 六 2019-08-31 13:34:03 CST; 3s ago Process: 22193 ExecStart=/usr/sbin/keepalived $KEEPALIVED_OPTIONS (code=exited, status=0/SUCCESS) Main PID: 22195 (code=exited, status=0/SUCCESS) [root@lb01 /]# netstat -antup | grep nginx #此时，备节点已接管： [root@lb02 /]# ip a | egrep "192.168.103.120|192.168.103.130" inet 192.168.103.130/24 scope global secondary enp0s3:2 inet 192.168.103.120/24 scope global secondary enp0s3:1
[root@lb01 /]# vim /etc/keepalived/chk_nginx_proxy.sh #!/bin/bash if [ `netstat -antup | grep nginx | wc -l` -ne 1 ];then service keepalived stop fi # 修改属性（可执行文件） [root@lb01 /]# chmod +x /etc/keepalived/chk_nginx_proxy.sh [root@lb01 /]# ls -l /etc/keepalived/chk_nginx_proxy.sh -rwxr-xr-x. 1 root root 100 8月 31 13:39 /etc/keepalived/chk_nginx_proxy.sh
此时，Keepalived服务的完整配置为：
[root@lb01 /]# vim /etc/keepalived/keepalived.conf ! Configuration File for keepalived global_defs { notification_email { 786744873@qq.com # 邮箱随便写 } notification_email_from Alexandre.Cassen@firewall.loc smtp_server 127.0.0.1 # 邮件服务器IP smtp_connect_timeout 30 router_id lb01 # id为lb1，不能和其他Keepalived节点相同（全局唯一） } vrrp_script chk_nginx_proxy { #定义vrrp脚本，检测HTTP端口 script "/etc/keepalived/chk_nginx_proxy.sh" #执行脚本，当Nginx服务有问题，就停掉Keepalived服务 interval 2 #间隔2秒 weight -60 } vrrp_instance VI_1 { # 实例名字为VI_1,相同实例的备节点名字要和这个相同 state MASTER # 状态为MASTER，备节点状态需要为BACKUP interface enp0s3 # 通信（心跳）接口enp0s3，此参数备节点设置和主节点相同，实际上是网卡名称 virtual_router_id 55 # 实例ID为55，要和备节点相同 priority 150 # 优先级为150，备节点的优先级必须比此数字低 advert_int 1 # 通信检查间隔时间1秒 authentication { auth_type PASS # PASS认证类型，此参数备节点设置和主节点相同 auth_pass 1111 # 密码1111，此参数备节点设置和主节点相同 } virtual_ipaddress { 192.168.103.120/24 dev enp0s3 label enp0s3:1 #虚拟IP，即VIP为192.168.103.120,子网掩码为24位，绑定接口为enp0s3，别名为enp0s3:1，此参数备节点设置和主节点相同 } track_script { chk_nginx_proxy # 触发检查 } } vrrp_instance VI_2 { state BACKUP interface enp0s3 virtual_router_id 56 priority 100 advert_int 1 authentication { auth_type PASS auth_pass 1111 } virtual_ipaddress { 192.168.103.130/24 dev enp0s3 label enp0s3:2 #虚拟IP，即VIP为192.168.103.130,子网掩码为24位，绑定接口为enp0s3，别名为enp0s3:2，此参数备节点设置和主节点相同 } }
下面测试接管结果
#先杀掉之前的后台进程脚本的运行，之后进行如下操作 [root@lb01 /]# /usr/local/nginx/sbin/nginx [root@lb01 /]# netstat -antup | grep nginx tcp 0 0 0.0.0.0:80 0.0.0.0:* LISTEN 3937/nginx [root@lb01 /]# service keepalived start Starting keepalived: [ OK ] [root@lb01 /]# service keepalived status keepalived (pid 3949) is running... [root@lb01 /]# ip a | grep 192.168.103.120 inet 192.168.103.120/24 scope global secondary eth0:1 [root@lb01 /]# /usr/local/nginx/sbin/nginx -s stop [root@lb01 /]# ip a | grep 192.168.103.120 [root@lb01 /]# service keepalived status keepalived is stopped #当停掉Nginx的时候，Keepalived 2秒钟内会被自动停掉，VIP被释放，由对端接管，这样就实现了即使服务宕机也会进行IP漂移，业务切换。
注意：本人测试后发现方法2不会停止keepalived，只会进行MASTER转移
当在同一个局域网内部署了多组Keepalived服务器对，而又未使用专门的心跳线通信时，可能会发生高可用接管的严重故障问题。之前已经讲解过Keepalived高可用功能是通过VRRP协议实现的，VRRP协议默认通过IP多播的形式实现高可用对之间的通信，如果同一个局域网内存在多组Keepalived服务器对，就会造成IP多播地址冲突问题，导致接管错乱，不同组的Keepalived都会使用默认的224.0.0.18作为多播地址。此时的解决办法是，在同组的Keepalived服务器所有的配置文件里指定独一无二的多播地址，配置如下：
global_defs router_id LVS_19 vrrp_mcast_group4 224.0.0.19 #这个就是指定多播地址的配置 } #提示： 1）不同实例的通信认证密码也最好不同，以确保接管正常。 2）另一款高可用软件Heartbeat，如果采用多播方式实现主备通信，同样会有多播地址冲突问题。
检测思路：在备节点上执行脚本，如果可以ping通主节点并且备节点有VIP就报警，让人员介入检查是否裂脑。
[root@lb02 /]# vim /etc/keepalived/check_split_brain.sh #!/bin/bash lb01_vip=192.168.103.120 lb01_ip=192.168.103.121 while true do ping -c 2 -W 3 $lb01_ip &>/dev/null if [ $? -eq 0 -a `ip a | grep "$lb01_vip" | wc -l` -eq 1 ];then echo "ha is split brain.warning." else echo "ha is OK" fi sleep 5 done [root@lb02 /]# sh /etc/keepalived/check_split_brain.sh ha is OK ha is OK ha is OK #正常情况下，主节点活着，VIP 192.168.103.121在主节点，因此不会报警，提示“ha is OK”
// lb01 [root@lb01 /]# service keepalived stop Redirecting to /bin/systemctl stop keepalived.service [root@lb01 /]# ip a | grep 192.168.103.120 [root@lb01 /]# // lb02 [root@lb02 /]# sh /etc/keepalived/check_split_brain.sh ha is split brain.warning. ha is split brain.warning. ha is split brain.warning.
// lb02 [root@lb02 /]# sh /etc/keepalived/check_split_brain.sh ha is split brain.warning. ha is split brain.warning. ha is split brain.warning. ha is split brain.warning. ha is split brain.warning. ha is split brain.warning. ha is split brain.warning. ha is OK ha is OK ha is OK #裂脑报警恢复了。
企业级Nginx负载均衡与keepalived高可用实战（二）keepalived篇
标签：yum 两种 主服务器 sts 失效 定义 配置文件说明 检测 mod
原文地址：https://www.cnblogs.com/wyt007/p/11439522.html
