12.2.6 常见问题与兼容性注意事项

常见问题与兼容性注意事项#

0. 原理草图（切换与GARP）#

1. VIP不通或偶发漂移#

典型现象：ip a 有VIP但客户端访问失败，或切换后偶发断流。
原因与处理：
- ARP缓存未更新：主备切换后客户端仍指向旧MAC。
- 解决：启用/调整 vrrp_garp_interval、vrrp_garp_master_delay，切换后多次发送GARP。
- 防火墙阻断VRRP：VRRP使用IP协议号112。
- 解决：放行协议号112，检查安全组/iptables/nftables。
- 子网与网卡绑定错误：VIP需与业务网段匹配并绑定正确网卡。
- 解决：核对 interface 与 virtual_ipaddress。

配置示例（/etc/keepalived/keepalived.conf）：

vrrp_instance VI_1 {
    state MASTER
    interface eth0
    virtual_router_id 51
    priority 120
    advert_int 1
    virtual_ipaddress {
        192.168.10.100/24 dev eth0
    }
    vrrp_garp_master_delay 1
    vrrp_garp_interval 0.5
}

排错命令（含解释）：

# 1) 查看VIP是否绑定到网卡
ip -br a show dev eth0

# 2) 查看邻居/ARP表是否刷新（应指向MASTER的MAC）
ip neigh show dev eth0 | grep 192.168.10.100

# 3) 抓包确认是否发送GARP与VRRP通告
tcpdump -nn -i eth0 'vrrp or arp'

---

2. 主备同时成为MASTER（脑裂）#

典型现象：两端都持有VIP，日志显示均为MASTER。
原因与处理：
- 组播不可达或被交换设备抑制：收不到通告。
- 解决：确认组播转发，必要时切换为单播 unicast_peer。
- 多播/单播混用：两端配置不一致。
- 解决：主备统一使用组播或单播。
- 优先级与抢占策略冲突：nopreempt 与 priority 设置不合理。
- 解决：明确主备优先级，必要时禁用抢占避免抖动。

单播配置示例（主备一致，仅IP不同）：

vrrp_instance VI_1 {
    state MASTER
    interface eth0
    virtual_router_id 51
    priority 120
    advert_int 1

    unicast_src_ip 192.168.10.11
    unicast_peer {
        192.168.10.12
    }

    virtual_ipaddress {
        192.168.10.100/24 dev eth0
    }
}

确认通告接收：

# MASTER与BACKUP都应看到对方的VRRP报文
tcpdump -nn -i eth0 'ip proto 112'

---

3. 切换频繁或抖动#

典型现象：频繁切换MASTER/BACKUP，业务抖动。
原因与处理：
- 健康检查脚本不稳定：脚本耗时或偶发失败。
- 解决：优化脚本，设置 weight，增加超时/重试控制。
- 通告间隔过小：网络抖动导致误判。
- 解决：适度增大 advert_int，结合监控评估。

健康检查示例（/etc/keepalived/check_nginx.sh）：

#!/usr/bin/env bash
# 检测本机80端口是否可用
curl -sSf http://127.0.0.1:80/ >/dev/null

配合weight控制优先级：

vrrp_script chk_nginx {
    script "/etc/keepalived/check_nginx.sh"
    interval 2
    timeout 2
    rise 2
    fall 2
    weight -20
}
vrrp_instance VI_1 {
    ...
    track_script {
        chk_nginx
    }
}

---

4. 兼容性与版本差异#

风险点：配置项名称/默认值变化，内核ARP参数导致VIP响应异常。

内核ARP参数统一（主备一致）：

# 立即生效
sysctl -w net.ipv4.conf.all.arp_ignore=1
sysctl -w net.ipv4.conf.all.arp_announce=2
sysctl -w net.ipv4.conf.default.arp_ignore=1
sysctl -w net.ipv4.conf.default.arp_announce=2

# 永久生效
cat >/etc/sysctl.d/99-keepalived.conf <<'EOF'
net.ipv4.conf.all.arp_ignore=1
net.ipv4.conf.all.arp_announce=2
net.ipv4.conf.default.arp_ignore=1
net.ipv4.conf.default.arp_announce=2
EOF
sysctl -p /etc/sysctl.d/99-keepalived.conf

版本检查与配置对照：

keepalived -v
rpm -qi keepalived || dpkg -l | grep keepalived

---

5. 与云环境/虚拟化平台兼容#

问题：云厂商对组播限制、GARP被忽略。
建议：优先使用单播，或采用云厂商推荐HA方案（SLB/弹性IP）。

单播+安全组放行示例：

# 放行VRRP协议号112（nftables示例）
nft add rule inet filter input ip protocol 112 accept

---

6. 与LVS/其他中间件联动问题#

问题：切换后旧规则残留，导致流量异常。
解决：在 notify_* 脚本中清理/重建规则。

notify_master示例（/etc/keepalived/notify_master.sh）：

#!/usr/bin/env bash
# 切换为MASTER时重建LVS规则
ipvsadm -C
ipvsadm -A -t 192.168.10.100:80 -s rr
ipvsadm -a -t 192.168.10.100:80 -r 192.168.10.21:80 -m
ipvsadm -a -t 192.168.10.100:80 -r 192.168.10.22:80 -m

关联配置片段：

vrrp_instance VI_1 {
    ...
    notify_master "/etc/keepalived/notify_master.sh"
    notify_backup "/etc/keepalived/notify_backup.sh"
    notify_fault  "/etc/keepalived/notify_fault.sh"
}

---

7. 排查清单（快速定位）#

# 1) 是否有VIP
ip a | grep 192.168.10.100

# 2) ARP是否更新
ip neigh | grep 192.168.10.100

# 3) 是否收到VRRP通告
tcpdump -n -i eth0 'ip proto 112'

# 4) 查看Keepalived日志
journalctl -u keepalived --since "10 min ago"

# 5) 配置一致性检查
grep -E 'virtual_router_id|priority|unicast|auth' /etc/keepalived/keepalived.conf

---

8. 安装与基础验证（便于排错）#

# 安装（RHEL系）
yum -y install keepalived

# 安装（Debian/Ubuntu）
apt -y install keepalived

# 启动与自启
systemctl enable --now keepalived

# 服务状态
systemctl status keepalived

预期效果：MASTER上 ip a 可见VIP；BACKUP上无VIP。

---

9. 练习题（动手验证）#

1. 将VRRP从组播切换为单播，抓包验证双方收发通告。
2. 人为停止MASTER的业务端口（如关闭nginx），观察 weight 触发切换。
3. 调整 advert_int 从 1 到 2，观察切换判定时间变化。
4. 禁用GARP（注释相关参数），复现实验中客户端ARP不更新的问题。