Keepalived 心跳通信模式
Keepalived 它通过 VRRP (Virtual Router Redundancy Protocol) 协议来实现负载均衡器或 Web 服务器的高可用性。Keepalived 支持两种心跳通信模式：组播模式和单播模式。
组播模式 (Multicast Mode)
- 定义：在默认情况下，Keepalived 使用 VRRP 协议的组播地址 224.0.0.18 来发送心跳包，以便各个 Keepalived 节点之间可以互相感知对方的存在。
- 优点：
- 配置简单，不需要特别指定对端 IP 地址。
- 适用于传统的网络环境，特别是那些支持组播的局域网。
- 缺点：
- 在某些网络环境中，尤其是云环境（如 AWS、Azure、Google Cloud 等），由于网络策略限制，可能不支持组播，导致心跳包无法正常传递。
- 如果网络设备不正确处理组播流量，可能会导致 Keepalived 实例之间的通信失败。
单播模式 (Unicast Mode)
- 定义：在单播模式下，Keepalived 实例会直接向指定的对端 IP 地址发送心跳包，而不是使用组播地址。这种方式更加灵活，并且不受限于网络设备是否支持组播。
- 优点：
- 适用于不支持组播的网络环境，例如云环境。
- 更加安全，因为心跳包只在指定的节点之间传输。
- 可以更好地控制心跳包的传输路径，有助于故障排查。
- 缺点：
- 配置相对复杂，需要在每个节点上明确指定对端节点的 IP 地址。
主要区别
| 特性 |
组播模式 |
单播模式 |
| 通信方式 |
使用组播地址 224.0.0.18 |
直接向指定的对端 IP 地址发送 |
| 网络兼容性 |
需要网络支持组播 |
不依赖组播，适用于所有网络环境 |
| 配置复杂度 |
简单，无需指定对端 IP |
复杂，需明确指定对端节点 IP |
| 安全性 |
所有节点都能接收心跳信息 |
心跳信息仅在指定节点间传输 |
| 云环境适用性 |
在大多数云环境中不可用 |
适用于云环境 |
| 故障排查 |
可能受网络设备影响 |
通信路径明确，易于排查 |
选择建议
- 传统数据中心：如果网络环境支持组播并且没有特殊的安全要求，可以选择组播模式，因为它配置简单。
- 云环境：在云环境中，由于网络策略的限制，通常必须使用单播模式。
- 网络受限环境：如果网络环境不支持组播或存在其他限制，应选择单播模式。
- 安全性要求高：如果对通信的安全性有较高要求，推荐使用单播模式。
组播模式是Keepalived的默认模式，不需要额外的配置，默认支持。
单播模式配置实例
如上，两台nginx服务器已经配置了keepalived的基本配置（keepalived基本配置可以参照https://www.situgou.top/的《keeplivead 高可用集群–基本配置》），实现了可以通过虚拟IP进行故障转移，没有配置通信模式，所以默认是组播的，现在需要修改他们的配置修改为单播模式
Master配置
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
| [root@centos-manager local]
global_defs {
router_id haweb_1
}
vrrp_sync_group VGM {
group {
VI_HA
}
}
vrrp_instance VI_HA {
state MASTER 主服务为MASTER
interface eth0
virtual_router_id 51
priority 100
advert_int 5
authentication {
auth_type PASS
auth_pass test
}
unicast_src_ip 10.201.9.134
unicast_peer {
10.201.9.133
}
virtual_ipaddress {
10.201.9.177/24 dev eth0
}
}
|
在配置文件中添加unicast_peer和unicast_peer即可。
slave配置
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
| [root@node1 ~]
global_defs {
router_id haweb_1
}
vrrp_sync_group VGM {
group {
VI_HA
}
}
vrrp_instance VI_HA {
state BACKUP 主服务为MASTER
interface ens33
virtual_router_id 51
priority 90
advert_int 5
authentication {
auth_type PASS
auth_pass test
}
unicast_src_ip 10.201.9.133
unicast_peer {
10.201.9.134
}
virtual_ipaddress {
10.201.9.177/24 dev ens33
}
}
|
测试
根据以上配置修改完成之后，还没有重启keepalived服务，所以现在默认还是组播模式，可以使用tcpdump抓包看下。
命令：tcpdump -i ens33 -nn proto 112，ens33是我当前服务器的网卡名称，测试时根据实际情况修改。
备机：
主机：
通过在备机和主机上抓包，可以看到现在通信模式是使用 VRRP 协议的组播地址 224.0.0.18 来发送心跳包
重启keepalived服务
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
| [root@node1 ~]
[root@node1 ~]
[root@node1 ~]
● keepalived.service - LVS and VRRP High Availability Monitor
Loaded: loaded (/usr/lib/systemd/system/keepalived.service; enabled; vendor preset: disabled)
Active: active (running) since 二 2026-02-03 23:39:37 CST; 27s ago
Docs: man:keepalived(8)
man:keepalived.conf(5)
man:genhash(1)
https://keepalived.org
Process: 35222 ExecStart=/usr/local/sbin/keepalived $KEEPALIVED_OPTIONS (code=exited, status=0/SUCCESS)
Main PID: 35224 (keepalived)
Tasks: 2
Memory: 668.0K
CGroup: /system.slice/keepalived.service
├─35224 /usr/local/sbin/keepalived -D
└─35225 /usr/local/sbin/keepalived -D
2月 03 23:39:57 node1 Keepalived_vrrp[35225]: (VI_HA) Sending/queueing gratuitous ARPs on ens33 for 10.201.9.177
2月 03 23:39:57 node1 Keepalived_vrrp[35225]: Sending gratuitous ARP on ens33 for 10.201.9.177
2月 03 23:39:57 node1 Keepalived_vrrp[35225]: Sending gratuitous ARP on ens33 for 10.201.9.177
2月 03 23:39:57 node1 Keepalived_vrrp[35225]: Sending gratuitous ARP on ens33 for 10.201.9.177
2月 03 23:39:57 node1 Keepalived_vrrp[35225]: Sending gratuitous ARP on ens33 for 10.201.9.177
2月 03 23:39:58 node1 Keepalived_vrrp[35225]: Sending gratuitous ARP on ens33 for 10.201.9.177
2月 03 23:40:03 node1 Keepalived_vrrp[35225]: (VI_HA) Master received advert from 10.201.9.134 with higher priority 100, ours 90
2月 03 23:40:03 node1 Keepalived_vrrp[35225]: (VI_HA) Entering BACKUP STATE
2月 03 23:40:03 node1 Keepalived_vrrp[35225]: (VI_HA) removing VIPs.
2月 03 23:40:03 node1 Keepalived_vrrp[35225]: VRRP_Group(VGM) Syncing instances to BACKUP state
|
抓包验证
备机：
主机：
重启服务之后再通过抓包命令查看，可以看到他们当前的通信方式不再是组播，而是想对方发送心跳包了。说明配置成功。
Keepalived 脑裂+应用层监控
Keepalived脑裂是指在高可用（HA）集群环境中，当多个节点（通常是主备节点）都同时认为自己是唯一活跃的主节点时发生的状态异常
如上图，目前已经完成了keepalived的基本配置，但是还存在问题，就是如果是nginx应用挂了的话，keepalived不会进行切换。所以我们的就需要使用脚本对nginx的应用进行监控。当nginx功能异常的话，就停止keepalived或者是降低keepalived的priority。
1
2
3
4
5
6
7
8
9
10
11
12
| [root@centos-manager local]
counter=$(ps -C nginx --no-heading|wc -l)
if [ "${counter}" = "0" ]; then
/usr/bin/systemctl restart nginx.service
sleep 2
counter=$(ps -C nginx --no-heading|wc -l)
if [ "${counter}" = "0" ]; then
/usr/bin/systemctl stop keepalived.service
fi
fi
[root@centos-manager local]
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
| [root@centos-manager keepalived]
global_defs {
router_id LVS_001B
}
vrrp_instance VI_1 {
state MASTER
interface ens33
virtual_router_id 51
priority 100
unicast_src_ip 10.201.9.134
unicast_peer {
10.201.9.133
}
advert_int 1
authentication {
auth_type PASS
auth_pass test
}
virtual_ipaddress {
10.201.9.177/24 dev ens33 label ens33:0
}
}
virtual_server 10.201.9.177 80 {
delay_loop 2
lb_algo rr
lb_kind DR
persistence_timeout 60
protocol TCP
real_server 10.201.9.134 80 {
weight 1
notify_down /etc/keepalived/nginxstatus.sh
TCP_CHECK {
connect_port 80
connect_timeout 3
nb_get_retry 2
delay_before_retry 1
}
}
}
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
| [root@node1 keepalived]
global_defs {
router_id LVS_001B
}
vrrp_instance VI_1 {
state BACKUP
interface ens33
virtual_router_id 51
priority 90
unicast_src_ip 10.201.9.133
unicast_peer {
10.201.9.134
}
advert_int 1
authentication {
auth_type PASS
auth_pass test
}
virtual_ipaddress {
10.201.9.177/24 dev ens33 label ens33:0
}
}
virtual_server 10.201.9.177 80 {
delay_loop 2
lb_algo rr
lb_kind DR
persistence_timeout 60
protocol TCP
real_server 10.201.9.133 80 {
weight 1
notify_down /etc/keepalived/nginxstatus.sh
TCP_CHECK {
connect_port 80
connect_timeout 3
nb_get_retry 2
delay_before_retry 1
}
}
}
|
- 重启keepalived服务
分别重启master和backup的keepalived服务
- 测试
将主机的nginx停止，查看keepalived是否能够将nginx启动起来
从上面的两张图可以看出来，当我手动把nginx进程杀死之后，keepalived监测到80端口不在监听了之后，就会调用nginxstatus.sh脚本将nginx启动起来。
那如果是nginx无法正常启动呢
如上图，我将nginx的配置文件修改错误，并将nginx进程杀掉，随后keepalived会调用nginx的状态检查脚本拉起nginx，当使用脚本无法拉起nginx的时候，就会将本机的keepalived的服务停止，此时虚拟ip便会漂移到备机上。