Keepalived 支持单机多组 VIP，需为每组独立配置 vrrp_instance，指定唯一 virtual_router_id、合理 priority 与 nopreempt，并隔离健康检查脚本及网络参数。
Keepalived 支持在同一台主机上管理多组 VIP（Virtual IP），但需避免状态冲突、优先级错配和网络干扰。关键在于为每组 VIP 独立定义 vrrp_instance，并确保它们互不抢占、路由可达、健康检查隔离。
每组 VIP 必须使用独立的 vrrp_instance 块
不能将多个 VIP 写在同一个 vrrp_instance 下试图“批量绑定”——Keepalived 会把它们当作同一虚拟路由器实例处理，导致主备切换时全部 VIP 同步漂移，失去灵活控制能力。
正确做法是：为每组业务或网段分配单独的 vrrp_instance，例如：
-
vrrp_instance VI_100绑定 192.168.10.100/24，用于 Web 服务 -
vrrp_instance VI_200绑定 10.0.20.200/24，用于数据库访问 -
vrrp_instance VI_300绑定 172.16.30.300/24，用于内部 API
每个实例需指定唯一 virtual_router_id（1–255 范围内），且主备节点对应实例的 ID 必须一致，否则无法建立 VRRP 对等关系。
合理设置 priority 和 nopreempt 避免脑裂与抖动
多实例共存时，若所有实例都启用抢占（默认行为），可能因某实例检测失败触发局部切换，进而影响其他实例的稳定状态。
建议策略：
- 核心业务实例（如数据库 VIP）设较高 priority（如 110），并开启
preempt_delay（如 5 秒），防止瞬时故障引发误切 - 非关键实例（如监控入口 VIP）设较低 priority（如 90），或在备用节点上配置
nopreempt，使其始终处于 backup 状态，不主动抢主 - 同一物理节点上多个实例的 priority 不宜过于接近（如 100/101），避免因微小差异频繁重选 Master
健康检查需按实例隔离，避免单点失效传导
默认情况下，一个实例的 track_script 失败会导致该实例状态降级，但不会影响其他实例——前提是脚本本身不共享全局资源或依赖同一进程。
实操注意点：
- 为每组 VIP 编写专用检查脚本（如
check_web.sh、check_db.sh），不要复用同一脚本判断多个服务 - 脚本中使用绝对路径、超时控制（
timeout 3）、明确退出码（0=成功，非0=失败） - 若需关联检查（如 DB VIP 仅在 Web 可用时才激活），应通过
track_interface或自定义逻辑实现，而非直接共用track_script
确认内核参数与网络接口支持多 VIP 绑定
Linux 默认允许在单个接口上配置多个 secondary IP，但需确保：
-
/proc/sys/net/ipv4/conf/all/arp_ignore和arp_announce已按 Keepalived 推荐值设置（通常为 1 和 2），避免 ARP 响应混乱 - 防火墙（如 firewalld 或 iptables）未拦截 VRRP 协议（协议号 112，目的地址 224.0.0.18）
- 交换机端口启用 IGMP snooping 或禁用对组播包的过滤，保障 VRRP 报文正常收发
可通过 ip addr show 验证 VIP 是否实际绑定，用 tcpdump -i eth0 vrrp 观察报文交互是否正常。
多组 VIP 的本质是多个轻量级 VRRP 实例并行运行，只要实例间配置解耦、资源隔离、状态自治，就能在一套 Keepalived 进程中稳定承载数十个 VIP。不复杂但容易忽略细节。
