Keepalived脑裂两台机器同时绑VIP，conntrack满导致VRRP通告被丢该怎么提前防？

目录

一、导语：一次"两台都是主"的故障复盘

故障现象通常是这样被描述的：业务侧出现间歇性连接重置，抓包发现同一个 VIP 在两个不同 MAC 地址上应答 ARP，两台 Keepalived 节点都处于 MASTER 状态，ip addr 显示 VIP 同时存在于两台机器。运维第一反应是"VRRP 配置有问题"，但配置文件往往数月未动。真正的变量在别处——故障前一段时间，业务侧连接数陡增，conntrack -C 接近 nf_conntrack_max，dmesg 里出现 nf_conntrack: table full, dropping packet。

这条线索把两个看似无关的子系统连了起来：VRRP 通告走的是组播报文，同样要经过 netfilter 的报文处理路径；当 conntrack 表满，内核在 nf_conntrack_in 阶段对新建流直接丢包，VRRP 通告若被判定为需要跟踪的流（或与 conntrack 共享同一软中断/队列资源），就会在高峰期被系统性丢弃。对端收不到通告，advert_int 计时器超时，状态机从 BACKUP 迁移到 MASTER，VIP 被二次绑定，脑裂成立。

本文的核心判断：脑裂不是"Keepalived 的 bug"，而是通告面与连接面共享内核资源、缺乏隔离的系统性设计缺陷。预防的重点不在于把 advert_int 调小，而在于让 VRRP 通告在 conntrack 饱和时仍能被可靠投递。

需要强调的是，本文讨论的是"可预防的脑裂"，即由资源耗尽、路径拥塞、配置缺陷导致的失效，而非物理链路双断、交换机 STP 异常等外部故障。前者有明确的工程抓手，后者更多依赖仲裁与告警。区分这两类，是设计预防方案的前提。

二、背景与问题定义：脑裂、VIP 与 conntrack 的三方关系

2.1 概念界定

脑裂（split-brain）：在双机热备中，两台节点同时认为自己是主节点并对外提供服务（此处表现为同时持有 VIP），导致上游流量被分流到两个不一致的状态副本上。其本质是分布式系统中成员对"谁是主"的认知不一致，而非单点故障。

VRRP（Virtual Router Redundancy Protocol）：RFC 5798 定义的冗余网关协议，通过周期性的 Advertisement 报文维持主备选举。默认 advert_int 为 1 秒，BACKUP 在 3 × advert_int + skew_time 内未收到通告即判定 MASTER 失效并接管。

conntrack：Linux netfilter 的连接跟踪子系统，为每条流维护一个 struct nf_conn 条目，用于 NAT、状态防火墙等。表容量由 nf_conntrack_max 控制，条目回收依赖超时与 GC 线程。

三者的耦合点在于：VRRP 通告是 IP 报文，进入协议栈后要经过 netfilter 的 PREROUTING 钩子；conntrack 在该钩子上为"新流"分配条目。当表满，nf_conntrack_in 返回 -ENOMEM 类错误，报文被丢弃。VRRP 通告虽为组播、通常被建议用 NOTRACK 规则豁免，但默认配置下并未豁免，这是大量现网事故的根因之一。

2.2 问题边界：哪些场景会触发

并非所有 conntrack 满都会导致脑裂。触发需要同时满足三个条件：其一，VRRP 通告未被 NOTRACK 豁免，或虽豁免但共享同一 CPU 软中断队列；其二，conntrack 饱和持续时间超过 3 × advert_int；其三，两端节点在饱和窗口内均未通过其他通道（如 unicast peer、独立心跳网）确认对端存活。三者缺一，故障链即断开。

本文评述：很多团队把"conntrack 满"当作性能问题处理，扩容 nf_conntrack_max 了事。但从故障链看，扩容只是推迟了饱和时刻，并未切断"饱和→丢通告→脑裂"的因果。真正的工程解法是让 VRRP 通告不进入 conntrack 跟踪，从路径上解耦，而非在容量上博弈。

三、原理剖析：从 conntrack 插入失败到 VRRP 通告丢弃

3.1 报文路径与钩子位置

一个进入网卡的报文，在 netfilter 中的处理顺序为：PREROUTING（含 conntrack 的 nf_conntrack_in）→ 路由决策 → INPUT/FORWARD。VRRP 通告的目的地址为 224.0.0.18，协议号 112，属于本地输入报文，必然经过 PREROUTING 的 conntrack 钩子。若该钩子因表满返回丢包，报文在到达 VRRP 协议处理函数之前就已消失，Keepalived 进程对此一无所知。

# 查看 conntrack 当前条目与上限
conntrack -C
sysctl net.netfilter.nf_conntrack_max
sysctl net.netfilter.nf_conntrack_count

# 观察是否出现表满丢包
dmesg | grep -i "nf_conntrack"
# 典型输出：nf_conntrack: table full, dropping packet

3.2 为什么 VRRP 通告会被"误伤"

关键细节在于：conntrack 对组播报文的处理并非总是"跳过"。在部分内核版本与配置下，组播 UDP/协议报文仍会尝试建立跟踪条目；即便被标记为 NOTRACK，其判定也发生在 raw 表之后，而 raw 表规则若未显式匹配 VRRP，报文仍会进入 conntrack。更隐蔽的是，conntrack 表满时内核的丢包行为是全局性的——它不区分业务流与心跳流，先到先丢。

笔者认为，这里存在一个普遍的认知偏差：运维人员倾向于认为"心跳报文很小、优先级高、不会被丢"。但在 Linux 的报文处理路径上，VRRP 通告与业务报文共享同一套 netfilter 钩子和软中断资源，没有任何优先级机制保护心跳。这是设计层面的盲区，而非实现缺陷。

3.3 状态机视角：从丢包到双主

以 BACKUP 节点为例，其状态迁移逻辑为：收到通告则重置 master_down_timer；计时器超时则迁移到 MASTER，绑定 VIP，并开始发送通告。若两端在饱和窗口内互相收不到通告，则两端各自超时、各自迁移，形成双主。此时若上游交换机未启用组播抑制，两个 MAC 都会响应 VIP 的 ARP，流量被哈希到两台机器，会话状态不一致，表现为连接重置与数据错乱。

四、关键数据与案例：容量、阈值与实测边界

4.1 conntrack 容量的数量级

Linux 内核中 nf_conntrack_max 的默认值随内存规模变化，常见发行版在 4GB 内存机器上约为 65536，在 16GB 机器上可达 262144。单条 nf_conn 在 64 位内核上约占 300 字节量级（含哈希桶与扩展结构，具体随内核版本与 NAT 扩展变化），因此 26 万条约占 80MB 量级。这意味着"扩容"在内存上代价不高，但扩容不解决路径耦合问题——这是本文反复强调的边界。

据公开的内核文档与社区实践（来源：Linux 内核文档 Documentation/networking/nf_conntrack-sysctl.rst，以及 Netfilter 项目官方 wiki），当 nf_conntrack_count 达到 nf_conntrack_max 的 100% 时，新流插入失败；部分发行版在 90% 时会触发 GC 加速。这些阈值是配置调优的参考点，但并非脑裂的触发点——触发点是"饱和持续时间"与"通告是否被豁免"。

4.2 一个可复现的模拟场景

为验证因果链，可在测试环境构造如下场景（模拟数据，非生产实测）：两台虚拟机运行 Keepalived，advert_int=1，未配置 NOTRACK；用 hping3 或 iperf3 制造大量短连接，使 conntrack -C 在 30 秒内逼近上限；同时用 tcpdump -i eth0 proto 112 观察通告。预期现象：饱和后通告抓包数量骤降，两端日志在 3–4 秒内先后出现 Entering MASTER STATE。

上述场景为模拟构造，用于验证机制，不代表任何特定厂商环境。真实环境的表现受内核版本、网卡多队列、RPS/RFS 配置影响，饱和到丢包的时延可能从毫秒级到秒级不等。

4.3 行业案例的共性

在公开的技术社区（如 Server Fault、Stack Overflow 的 keepalived 标签、以及国内多个运维博客）中，类似故障的描述高度一致：故障前有流量突增、dmesg 有 conntrack 告警、两端同时 MASTER。本文评述：这些案例的价值不在于"又一个脑裂故事"，而在于它们共同指向同一个可复现的因果结构。工程上应当把"conntrack 饱和"列为脑裂的一级预警指标，而非二级性能指标。

延伸阅读可参考：Keepalived 官方手册、conntrack-tools 官方文档、Netfilter 项目文档。

五、预防架构：通告面、连接面、仲裁面三层隔离

5.1 第一层：通告面隔离（切断因果）

目标：让 VRRP 通告不进入 conntrack 跟踪，从路径上消除"表满丢通告"的可能。手段是在 raw 表添加 NOTRACK 规则，匹配 VRRP 协议号 112。规则必须在 conntrack 之前生效，因此放在 raw PREROUTING。

# 对 VRRP（协议号 112）跳过连接跟踪
iptables -t raw -A PREROUTING -p vrrp -j NOTRACK
iptables -t raw -A OUTPUT -p vrrp -j NOTRACK

# 持久化（以 iptables-save 为例）
iptables-save > /etc/iptables/rules.v4

# 验证：应看到 NOTRACK 规则位于 raw 表
iptables -t raw -L -n -v

笔者认为，NOTRACK 是成本最低、收益最高的一步，但常被忽略，原因是它不在 Keepalived 的配置视野内——运维看 keepalived.conf 找不到问题，就不会想到 netfilter。这提示我们：高可用方案的知识边界必须覆盖到内核报文路径，否则配置再正确也挡不住系统性失效。

5.2 第二层：连接面容量治理（推迟饱和）

隔离之后，仍需治理 conntrack 容量，因为饱和本身会伤害业务。治理包括三方面：合理设置 nf_conntrack_max 与哈希桶 nf_conntrack_buckets（通常取 max/4 至 max/2）；缩短 nf_conntrack_tcp_timeout_established（默认 432000 秒，过长会导致僵尸条目堆积）；对短连接业务启用 nf_conntrack_tcp_timeout_time_wait 调优。

5.3 第三层：仲裁面加固（兜底）

即便前两层到位，仍需假设"通告可能丢"。仲裁面的作用是：当通告不可靠时，用独立通道确认对端存活。常见手段包括：Keepalived 的 unicast_peer 配合独立心跳网卡；vrrp_script 探测对端管理口；以及外部仲裁（如基于 etcd/Consul 的租约）。本文评述：仲裁面的价值在于把"单通道判定"升级为"多通道共识"，这与分布式系统中的 quorum 思想同源，但成本更低——双机场景下只需一条独立心跳链路即可显著降低误判率。

需要提醒的是，仲裁面不能替代通告面隔离。若心跳网与业务网共享物理路径，仲裁同样会被拥塞影响。因此三层是"纵深防御"关系，而非"任选其一"。

六、落地操作路径：参数、脚本与演练步骤

6.1 配置清单

第一步，在两端节点添加 NOTRACK 规则并持久化。第二步，调整 sysctl 参数，写入 /etc/sysctl.d/99-conntrack.conf。第三步，在 keepalived.conf 中启用 unicast_peer 与独立心跳接口。第四步，配置 vrrp_script 做对端管理口探测。

# /etc/sysctl.d/99-conntrack.conf
net.netfilter.nf_conntrack_max = 262144
net.netfilter.nf_conntrack_buckets = 65536
net.netfilter.nf_conntrack_tcp_timeout_established = 86400

# keepalived.conf 片段（示意）
vrrp_instance VI_1 {
    state BACKUP
    interface eth0
    virtual_router_id 51
    priority 100
    advert_int 1
    unicast_src_ip 10.0.0.11
    unicast_peer {
        10.0.0.12
    }
    virtual_ipaddress {
        10.0.0.100/24
    }
    track_script {
        chk_peer
    }
}

6.2 监控指标

建议采集四类指标：nf_conntrack_count / nf_conntrack_max 的比值（一级预警，阈值 80%）；dmesg 中 conntrack 丢包计数；VRRP 通告的收发计数（可通过 tcpdump 采样或 eBPF 统计）；Keepalived 状态迁移次数。四者联动，可在脑裂发生前 30 秒以上给出预警。

6.3 演练步骤

演练应在隔离环境进行，步骤为：记录基线 → 注入短连接压力使 conntrack 逼近上限 → 观察通告抓包与状态迁移 → 验证 NOTRACK 生效后通告不再丢失 → 恢复环境。演练的关键不是"复现故障"，而是验证隔离措施确实切断了因果链。建议每季度一次，并在变更（如内核升级、网卡驱动更新）后追加一次。

拓展材料可参考：VRRP 脑裂相关视频教程、Red Hat 高可用文档。

七、对比与局限：不同方案的适用边界

常见方案有三类：其一，纯 Keepalived + VRRP，成本低但依赖通告面；其二，Keepalived + 独立心跳 + 仲裁脚本，可靠性提升但复杂度增加；其三，引入外部协调服务（etcd/Consul）做租约仲裁，可靠性最高但引入新依赖。本文评述：选择的关键不是"哪个更先进"，而是业务对脑裂的容忍窗口。若业务可在秒级内通过上游负载均衡摘除异常节点，则第一类加监控即可；若业务对双写零容忍，则必须上第三类。

局限同样明显：NOTRACK 只解决 conntrack 路径，不解决网卡队列拥塞、交换机组播抑制等外部因素；仲裁面依赖心跳网的独立性，若心跳网与业务网同缆同交换机，则退化为单通道。因此任何方案都应配套"脑裂检测—自动隔离—人工确认"的闭环，而非假设方案能杜绝一切失效。

八、结论与展望

本文的主线可以概括为一句话：脑裂的预防，本质是把"通告面"从"连接面"的资源竞争中解耦出来。具体路径是三层：NOTRACK 切断因果、容量治理推迟饱和、仲裁加固兜底。三层之中，第一层成本最低、收益最高，应作为默认配置；第二层是常规运维；第三层是纵深防御。

展望未来，随着 eBPF 与 XDP 在报文路径上的普及，VRRP 通告有望在驱动层就被识别并赋予独立队列，从根本上避免与业务流共享资源。同时，基于可观测性的"预测性切换"（在 conntrack 饱和前主动降级或迁移）也值得关注。但无论技术如何演进，"心跳通道必须与业务通道隔离"这一原则不会过时——它是分布式系统可靠性的第一性原理。

九、主要参考文献