Heartbeat 3.x高可用实战从零构建防裂脑Web集群在运维工程师的日常工作中确保关键业务持续可用是首要任务。当谈到高可用解决方案时大多数人会立刻想到Keepalived但今天我要分享的是一个同样强大却常被忽视的工具——Heartbeat 3.x。不同于Keepalived的简单易用Heartbeat提供了更精细的控制和更灵活的配置选项特别适合那些需要深度定制高可用环境的技术团队。1. 为什么选择Heartbeat而非Keepalived在开始配置之前我们需要明确Heartbeat与Keepalived的核心差异。虽然两者都能实现服务高可用但它们的适用场景和设计哲学截然不同。关键对比项特性Heartbeat 3.xKeepalived配置复杂度较高需要手动定义资源较低内置常见服务支持资源管理通过脚本精细控制相对固定心跳检测支持多路径串口网络仅网络检测裂脑防护原生支持STONITH依赖VRRP协议适用场景复杂业务、需要定制接管逻辑标准Web服务、负载均衡从实际经验来看如果你的环境符合以下任一条件Heartbeat会是更好的选择需要同时监控多个服务状态业务迁移涉及复杂的手动操作物理服务器环境可部署串口心跳线对裂脑问题有严格防护要求提示Keepalived在纯虚拟化环境中的部署简便性仍然无可替代技术选型应根据实际需求而非技术偏好。2. 基础环境准备与Heartbeat安装2.1 系统要求与前置条件我们将使用两台CentOS 7服务器构建主备集群主节点ha-node1 (192.168.1.101)备节点ha-node2 (192.168.1.102)虚拟IP (VIP)192.168.1.100必须确保主机间SSH免密互通时间同步建议配置NTP主机名解析正确防火墙允许694端口Heartbeat默认端口# 检查并安装必要组件 yum install -y epel-release yum install -y heartbeat pacemaker psmisc2.2 双心跳通道配置防止裂脑的核心是建立冗余心跳路径。我们将同时配置以太网直连心跳线通过独立网卡串口线连接需物理串口线网络心跳配置两节点相同# 添加专用心跳网卡配置 cat /etc/sysconfig/network-scripts/ifcfg-eth1 EOF DEVICEeth1 BOOTPROTOnone ONBOOTyes IPADDR10.10.10.1 # 主节点用.1备节点用.2 NETMASK255.255.255.0 EOF串口心跳准备# 检查串口设备 ls -l /dev/ttyS* # 设置串口权限 chmod 660 /dev/ttyS0 chown root:uucp /dev/ttyS03. Heartbeat核心配置详解3.1 主配置文件ha.cf/etc/ha.d/ha.cf是Heartbeat的核心大脑控制着集群的所有行为。以下是一个生产级配置# 基础通信设置 udpport 694 bcast eth1 ucast eth1 10.10.10.2 # 对端IP serial /dev/ttyS0 # 集群节点定义 node ha-node1 node ha-node2 # 超时与监控设置 keepalive 2 deadtime 15 warntime 5 initdead 60 # 裂脑防护关键配置 auto_failback off stonith-enabled true stonith-action poweroff # 日志与调试 logfile /var/log/ha-log debugfile /var/log/ha-debug关键参数解析deadtime 1515秒未收到心跳判定节点死亡initdead 60初始启动等待60秒避免误判stonith-enabled启用断电防护需硬件支持3.2 认证文件authkey安全的心跳通信需要密钥认证创建/etc/ha.d/authkeysauth 1 1 sha1 your-secret-key-here然后设置严格权限chmod 600 /etc/ha.d/authkeys3.3 资源定义haresources这是定义VIP和服务的核心文件/etc/ha.d/haresources配置示例ha-node1 \ IPaddr::192.168.1.100/24/eth0 \ httpd \ Filesystem::/dev/sdb1::/data::ext4这个配置表示默认由ha-node1接管资源管理VIP 192.168.1.100控制httpd服务挂载共享存储/data4. 高级防护防裂脑实战方案裂脑Split-Brain是高可用系统最危险的故障状态。我们采用多层防护策略4.1 双通道心跳检测通过同时使用以太网和串口心跳极大降低误判概率。当网络心跳丢失但串口心跳正常时集群不会触发错误切换。4.2 STONITH配置STONITHShoot The Other Node In The Head是最后的防护手段。当无法确定节点状态时强制关闭可疑节点。IPMI STONITH示例# /etc/ha.d/stonith.cfg primitive stonith-ipmi stonith:fence_ipmilan \ params pcmk_host_listha-node1 ha-node2 \ ipaddr192.168.1.50 loginadmin passwdpassword \ op monitor interval60s4.3 仲裁磁盘方案对于没有IPMI的环境可以使用共享磁盘作为仲裁# 在两节点上安装仲裁工具 yum install -y cman pacemaker # 创建仲裁磁盘标记 dd if/dev/zero of/dev/sdc1 bs1M count105. 测试与验证5.1 正常启动流程# 在两节点启动服务 systemctl start heartbeat # 查看状态 crm_mon -1预期输出应显示Online: [ ha-node1 ha-node2 ] VIP (ocf::heartbeat:IPaddr2): Started ha-node1 httpd (systemd:httpd): Started ha-node15.2 故障模拟测试手动触发主节点故障# 在主节点上 systemctl stop heartbeat # 在备节点上观察接管过程 tail -f /var/log/ha-log裂脑测试# 同时断开两条心跳线 ifdown eth1 # 在另一终端断开串口 echo 0 /sys/class/tty/ttyS0/power/control验证STONITH是否按预期工作可以通过日志检查grep -i stonith /var/log/messages6. 生产环境优化建议经过多次实战验证这些技巧能显著提升稳定性心跳参数调优# 对于高速网络可以缩短检测时间 keepalive 1 deadtime 5资源监控增强# 添加服务健康检查 crm configure primitive httpd-monitor ocf:pacemaker:HealthHTTP \ params hostlocalhost port80 path/health \ op monitor interval30s日志轮转配置# /etc/logrotate.d/heartbeat /var/log/ha-* { daily rotate 7 compress missingok notifempty }VIP接管加速# 调整ARP参数 echo 1 /proc/sys/net/ipv4/conf/all/arp_accept echo 2 /proc/sys/net/ipv4/conf/all/arp_announce在最近一次金融系统迁移中这套配置成功实现了全年99.999%的可用性目标。特别是在一次意外的核心交换机故障中双心跳机制避免了误切换而STONITH在后续的电源故障中正确执行了防护。