heartbeat双机热备通过心跳监测与资源接管实现高可用，核心是两节点间状态感知与自动故障切换；需统一主机名解析、时间同步、ssh互信，配置authkeys、ha.cf和haresources三文件，依赖专用心跳链路及udp 694端口通信。
构建基于 Heartbeat 的双机热备，核心在于让两台服务器能互相感知状态，并在主节点失效时，由备用节点自动接管服务。它不依赖共享存储，适合 Web、数据库代理、轻量级应用等场景，但需注意 Heartbeat v1 已停止维护，生产环境建议评估 Pacemaker+Corosync 等现代方案；若受限于旧系统或教学目的，v1 仍可稳定运行。
网络与基础环境准备
双机热备对底层一致性要求严格，必须提前统一：
-
主机名与解析一致：两台机器的
uname -n输出必须与/etc/hosts中定义的 FQDN 完全匹配（如node1.example.com），且彼此能通过主机名 ping 通； - 时间同步不可省略：使用 NTP 或 chrony 同步时间，误差建议控制在 1 秒内，否则心跳判定易误触发；
- SSH 密钥互信打通：Heartbeat 部分操作（如资源启动/停止脚本）可能调用远程命令，需 root 用户间免密 SSH；
- 独立心跳链路更可靠：推荐为每台机器配置第二块网卡（如 eth1），专用于心跳通信（如 192.168.100.0/24 网段），避免业务网络拥塞影响故障判断。
Heartbeat 配置三要素
三个配置文件必须完全一致地部署在 /etc/ha.d/ 下，权限和内容缺一不可：
-
authkeys：启用认证，防止非法节点加入。典型写法：auth 3<br>3 md5 HelloHA2026
保存后立即执行chmod 600 /etc/ha.d/authkeys，否则服务拒绝启动； -
ha.cf：定义集群行为。关键项包括：
•bcast eth1（广播心跳到专用网卡）或ucast eth1 192.168.100.2（单播，更安全）
•keepalive 2（每 2 秒发一次心跳）
•deadtime 30（30 秒收不到心跳即判故障）
•node node1.example.com node2.example.com（节点名须与 uname -n 一致）
•auto_failback off（避免主恢复后频繁抢回资源，推荐关闭）； -
haresources：声明要托管的服务及虚拟 IP。格式为：node1.example.com 192.168.1.100/24/eth0 apache2
表示默认由 node1 托管 VIP 192.168.1.100 和 Apache 服务；若仅需 VIP，则去掉apache2。
服务集成与验证要点
Heartbeat 本身不管理应用进程，而是通过标准 init 脚本或 LSB 兼容脚本控制服务启停：
-
Web 服务示例：确保
/etc/init.d/apache2（Ubuntu）或/etc/init.d/httpd（CentOS）存在且可执行；Heartbeat 启动时会调用start，故障切换时调用stop； -
自定义服务支持：若托管非标准服务（如 Python 后端），需编写符合 LSB 规范的启动脚本，放入
/etc/init.d/并设置好 chkconfig/service enable； -
手动模拟故障验证：在主节点执行
service heartbeat stop或直接断开心跳网卡，观察备用节点是否在deadtime内完成 VIP 绑定和服务拉起（可通过ip addr show eth0和curl http://VIP快速确认）； -
日志是排错第一依据：重点查看
/var/log/ha-log，搜索ResourceManager、takeover、release等关键词，判断资源切换是否完整。
常见陷阱与加固建议
很多部署失败源于细节疏忽，而非配置逻辑错误：
-
防火墙拦截心跳包：Heartbeat 默认使用 UDP 694 端口，需在两台机器上放行（
iptables -I INPUT -p udp --dport 694 -j ACCEPT）； -
SELinux 干扰资源接管：生产环境建议设为
permissive或针对性赋权，避免因上下文限制导致脚本执行失败； - 无共享存储的数据一致性风险：Heartbeat 只接管服务，不复制数据。若应用有写操作（如 MySQL），必须额外引入 DRBD、rsync 定时同步或应用层双写机制；
-
单点 ping 节点不可靠：若配置了
ping或ping_group，应选择网络核心设备（如网关）作为探测目标，避免因某个 ping 节点宕机引发误切换。
