vrrp协议在linux中通过keepalived实现高可用，核心是用户态进程管理vip漂移：master持有vip并发送组播通告（224.0.0.18，协议号112），backup监听超时后接管；关键配置包括一致的vrid、合理priority、认证机制、正确interface与state，结合vrrp_script健康检查动态调整优先级，确保服务级故障也触发切换。

VRRP 协议在 Linux 中实现高可用，核心是通过 Keepalived 软件来落地——它不是内核原生协议栈的直接启用，而是以用户态进程实现 VRRP 逻辑，管理虚拟 IP（VIP）在主备节点间的自动漂移。

VRRP 协议本身不传输数据，只传递“谁活着、谁该接管”的状态信号。Keepalived 借助它，在两个或多个节点间选举出一个 MASTER，由它持有 VIP 并响应流量；其余节点为 BACKUP，持续监听 MASTER 的 VRRP 通告包（组播地址 224.0.0.18，IP 协议号 112）。一旦 BACKUP 在 advert_int（默认 1 秒）× fail_count（通常为 3）时间内收不到通告，就触发状态切换。

---

VRRP 高可用的关键配置要素

• VRID（Virtual Router ID）
  同一广播域内必须唯一，取值范围 1–255。主备节点的 vrrp_instance 块中此项必须一致，否则无法组成同一虚拟路由器。

• 优先级（priority）
  取值 1–254，默认 100。MASTER 必须设为更高值（如 100），BACKUP 设为更低（如 90）。当 MASTER 故障恢复后，若配置了 nopreempt，则不会抢回 VIP；否则会重新抢占。

• 认证机制（authentication）
  推荐使用 auth_type PASS + auth_pass（8 字符以内明文密码），避免未授权节点加入 VRRP 组。不建议禁用认证，尤其在共享网络环境中。

• 网卡与状态声明
  interface 必须指定真实物理接口（如 ens33），不能写错；state 明确标识角色：MASTER 或 BACKUP（注意大小写）。同一实例中，仅允许一个 MASTER。

  

  Zynq Linux Hardware Debug

  Zynq‑7000 / Zynq UltraScale+ 硬件调试技能。适用于 Xilinx Zynq（Cortex‑A9/A53 + FPGA）Linux 环境，调试 I2C、I2S、UART、GPIO 等外设。包括设备树配置、内核驱动、用户空间调试工具、交叉编译和常见问题排查，支持 PetaLinux 开发。

  下载

---

健康检查如何影响 VRRP 状态

Keepalived 的高可用不只是“心跳断了就切”，而是把服务可用性纳入决策：

• 定义 vrrp_script 执行检测逻辑（如 curl 检查 Nginx 是否返回 200）
• 用 track_script 将脚本绑定到 vrrp_instance
• 检测失败时按 weight 调整当前节点优先级（例如 -30），使其低于 BACKUP，主动让出 MASTER 地位

这样就能实现“服务挂了，哪怕机器还活着，也自动交出 VIP”。

---

网络层必须满足的前提

• 时间同步：所有节点需运行 chronyd 或 ntpd，时间偏差超过 1 秒可能引发状态误判
• 组播可达：确保交换机允许 224.0.0.18 组播流量，且防火墙放行 VRRP 协议（非端口！要用 firewall-cmd --add-protocol=vrrp）
• ARP/Gratuitous ARP 正常：VIP 切换后，新 MASTER 会发免费 ARP 包刷新下游设备 MAC 表，否则客户端仍向旧 MAC 发包

---

实际效果表现

• VIP 漂移通常在 1–3 秒内完成（取决于 advert_int 和 fail_count）
• 客户端无感知：TCP 连接会中断（因 IP 归属变化），但 HTTP/短连接业务几乎无感；长连接需应用层重连机制配合
• 日志可查：journalctl -u keepalived -f 中能看到 Entering MASTER STATE 或 VRRP_Instance(VI_1) received advert from ... with higher priority 等关键事件

不复杂但容易忽略。