如何通过Keepalived管理多网卡多VIP的复合集群引流实战-Nginx-PHP中文网

Keepalived 管理多网卡多 VIP 的核心是按网络平面和业务边界逻辑隔离：每网卡配独立 vrrp_instance，确保状态无干扰；需正确配置接口、路由与健康检查，实现跨网段引流与双主分发。

如何通过keepalived管理多网卡多vip的复合集群引流实战

Keepalived 管理多网卡多 VIP 的复合集群，核心不是“堆配置”，而是按网络平面和业务边界做逻辑隔离：每个网卡承载独立网段的 VIP，每组 VIP 对应独立 vrrp_instance，彼此状态不干扰、漂移不耦合。只要接口、路由、健康检查三者分得清，再多网卡多 VIP 也能稳如磐石。

不同网卡对应不同业务网络（如管理网段、业务网段、数据库网段），Keepalived 必须为每张网卡单独定义 vrrp_instance，并显式指定 interface 和 virtual_ipaddress 所属设备。

不能把 192.168.10.100/24（业务口）和 10.0.20.200/24（DB 口）写在同一个 instance 下——它们属于不同广播域，强行共用会导致 ARP 响应混乱或通告失败
正确做法是：ens33 绑定 VI_WEB（virtual_router_id 51），ens34 绑定 VI_DB（virtual_router_id 52），两组实例完全独立，互不感知
确保每张网卡已启用并能收发组播报文（检查 ip link show ens33 状态，确认无 NO-CARRIER；关闭该接口的 NetworkManager 干预，避免 IP 冲突）

VIP 漂移到备机后，流量能否正确抵达，取决于三层可达性。多网段场景下，仅靠 Keepalived 自动绑定 secondary IP 不够，还需配合路由与内核参数。

启用 /proc/sys/net/ipv4/conf/all/arp_ignore = 1 和 arp_announce = 2，防止非本接口 IP 响应 ARP 请求，避免跨网段 VIP 被错误解析
若 VIP 所在网段无直连路由（如 VIP 是 172.16.30.300/24，但主机只有一条默认路由），需手动添加 host 路由：ip route add 172.16.30.300/32 dev ens35 src 172.16.30.254
对跨子网访问 VIP 的客户端，建议在核心交换机或网关上配置静态 ARP 或辅助路由，而非依赖主机响应

真正高可用的复合集群，是让不同网卡上的 VIP 各自走双主路径：节点 A 主管 Web VIP（ens33）、备份 DB VIP（ens34）；节点 B 正好相反。这样既分流又互备。

node-01 配置示例：
vrrp_instance VI_WEB { state MASTER; interface ens33; virtual_router_id 51; priority 100; ... }
vrrp_instance VI_DB { state BACKUP; interface ens34; virtual_router_id 52; priority 90; ... }
node-02 配置反向：
VI_WEB 设为 BACKUP（priority 90），VI_DB 设为 MASTER（priority 100）
两个 virtual_router_id 在双机间必须严格一致，否则 VRRP 组播无法协商
关键细节：两节点的 advert_int 建议统一为 1 秒，避免因心跳间隔差异引发状态抖动；认证密码可不同（auth_pass 独立），但 auth_type 必须一致

一个脚本监控多个 VIP 或多个网卡上的服务，极易造成“误杀”——比如 DB 服务异常导致 Web VIP 也被降级。必须做到一对一绑定。

为每个 vrrp_instance 编写专用检测脚本：check_web_on_ens33.sh 仅探测 192.168.10.100:80，check_db_on_ens34.sh 仅探测 10.0.20.200:3306
脚本中使用绝对路径调用 curl / nc / ss，设置超时（timeout 3），明确返回码（成功 exit 0，失败 exit 1）
track_script 块必须与对应 instance 关联，不要全局复用；若某 VIP 依赖另一 VIP 存在（如 API VIP 仅在 Web VIP 可达时才激活），需在脚本中嵌入逻辑判断，而非靠 track_interface 间接联动