配置Keepalived实现双机热备，一个常见的误解是认为软件装上就能自动实现高可用。实际上，真正的稳定运行，关键在于VRRP配置、健康检查绑定以及网络层对齐这三者必须严丝合缝。任何一个环节出错，比如virtual_router_id不一致，或者健康检查脚本失效，都可能导致虚拟IP（VIP）无法正常漂移，服务依然中断。
确认网卡名和VIP网段是否真实可达
很多部署后的问题，根源在于“以为网络是通的，但实际上不通”。这需要从最底层开始确认：首先，VIP必须与两台服务器的物理IP处于同一个子网。其次，配置文件中指定的网卡名称，必须与系统内实际名称完全匹配（例如是ens33还是eth0，不同CentOS版本差异可能很大）。
- 第一步，在两台服务器上执行
ip -br a命令，确认目标网卡状态为UP，并且已经分配了同网段的IP地址（例如192.168.100.11/24）。 - 规划的VIP地址（如
192.168.100.107）不能与现有物理IP、网关地址或广播地址冲突。 - 防火墙必须放行VRRP协议通信。VRRP默认使用组播地址
224.0.0.18和协议号112。以firewalld为例，可以执行命令：firewall-cmd --add-rich-rule='rule protocol value="vrrp" accept' --permanent，然后重载配置。 - 如果系统启用了SELinux，需要确保Keepalived进程有权限读取自定义脚本，可以执行
setsebool -P keepalived_read_etc 1来设置。
state、priority和virtual_router_id必须成对校验
在vrrp_instance配置块中，state、priority和virtual_router_id这三个参数是主备节点相互识别的核心，任何一项不匹配都可能导致脑裂或状态异常。
state参数：主节点配置应设为MASTER，备节点必须设为BACKUP。如果写反了，配置本身不会报错，但VIP将无法按预期漂移。priority参数：主节点的优先级应高于备节点。通常主节点设为100，备节点设为90，保持至少10的差值可以在网络轻微抖动时避免误切换。virtual_router_id参数：同一个VRRP实例在两台机器上的这个ID必须完全相同（取值范围1-255），并且在同一局域网内，不同的VRRP组必须使用不同的ID，否则会相互干扰。
健康检查脚本必须返回正确的exit code并可执行
依靠自定义脚本（如killall -0 nginx或curl -s https://127.0.0.1/health）来检测应用状态是标准做法，但脚本本身常常成为故障点。
- 脚本路径必须与
vrrp_script中定义的完全一致（例如/etc/keepalived/check_nginx.sh），并且确保其具有可执行权限（chmod 755），属主为root。 - 脚本的退出码必须明确：健康时返回
exit 0，异常时返回exit 1（或其他非零值）。返回其他特定值（如exit 2）可能会被Keepalived忽略。 - 在脚本中，避免使用依赖完整系统环境的命令，例如
systemctl is-active nginx。因为Keepalived的子进程可能无法加载全部systemd环境变量。改用pgrep -x nginx这类命令会更可靠。 - 检查间隔
interval建议设置为2秒左右。间隔太短会增加系统负载，间隔太长（如超过5秒）则会延长故障发现时间，影响服务可用性。
切记：Keepalived不同步数据，只管VIP漂移
这是一个至关重要的认知：Keepalived只负责IP地址的高可用，它不负责数据同步。有人配置好后以为高枕无忧，结果主服务器宕机后，VIP虽然漂移到了备机，但备机上的数据库却是空的——因为Keepalived从不复制磁盘数据、不同步文件、也不处理数据库日志。
- 它的核心工作非常单一：当通过健康检查判断本地服务异常时，自动降低自身优先级，触发备节点升为主节点并接管VIP。
- 对于Nginx静态资源，需要通过
rsync或分布式存储等方式保证文件一致。对于MySQL、PostgreSQL等数据库，必须单独配置主从复制或流复制。 - 如果使用
corosync + pacemaker这类集群栈来同时管理数据库服务和VIP，必须正确配置colocation约束，否则可能出现VIP和数据库服务分别运行在不同节点上的情况，服务依然不可用。
说到底，要让双机热备真正稳定运行，最常遇到的障碍往往不是配置文件的语法错误，而是网络层组播通信是否畅通、健康检查脚本是否存在静默失败，以及是否清晰理解了“VIP切换”并不等同于“服务全自动恢复”这个根本逻辑。
