Apache HA集群自动化故障恢复需通过结构化演练验证，包括模拟宕机、配置错误等故障，检查VIP漂移、进程自启、健康检查剔除等响应，并用脚本和日志实现可观测与一键状态确认。
在Apache高可用（HA）集群中，自动化故障恢复不是“配完就完事”，而是需要通过结构化演练验证真实有效性。关键在于模拟典型故障、触发预设响应逻辑、确认服务无缝接管，并留下可复盘的执行痕迹。
明确演练目标与故障场景
避免泛泛而谈“测试高可用”，应聚焦具体可验证的目标，例如：
- VIP（虚拟IP）是否在主节点宕机后 10 秒内漂移到备节点
- Apache 进程崩溃后是否自动拉起且不丢失当前连接状态（如启用 mod_proxy_balancer 的 sticky session）
- 后端健康检查失败时，负载均衡器是否在 3 次连续失败后剔除异常节点
常见需覆盖的故障类型包括：
• 主节点系统级宕机（kill -9 所有 httpd 进程 + systemctl stop keepalived）
• Apache 配置错误导致启动失败（如语法错误后 service httpd start 返回非零）
• 网络分区（iptables DROP 主节点到备节点的 vrrp 组播包）
• 后端应用服务不可达（关闭 Tomcat 或 mock 503 响应）
构建可重复、可观测的演练环境
使用容器或轻量级 VM 快速搭建双节点 Keepalived + Apache + 自定义健康检查脚本的最小闭环。重点加入以下可观测能力：
• 在 /var/log/keepalived.log 和 /var/log/httpd/error_log 中添加时间戳和唯一 trace_id
• 用 curl -I http://VIP/health 每 2 秒轮询，记录状态码与响应时间变化
• 使用 ss -tlnp | grep :80 确认监听进程归属节点
• 用 tcpdump 抓取 VRRP 包（host 224.0.0.18），验证 MASTER/BACKUP 状态切换过程
建议将上述检查封装为一个 check_status.sh 脚本，支持一键输出当前角色、VIP 绑定位置、后端节点健康状态。
执行标准化恢复动作并验证结果
演练不是“等它自己恢复”，而是主动触发、分步确认：
• 第一步：人工触发故障（如 systemctl stop keepalived on node-A）
• 第二步：等待 5 秒后运行 check_status.sh，确认 VIP 已迁移、httpd 正常运行、日志出现 “Transition to MASTER”
• 第三步：发起持续 HTTP 请求（ab -n 1000 -c 10 http://VIP/test.html），检查无 502/503、平均延迟波动
• 第四步：恢复原主节点（systemctl start keepalived），观察是否按 preemption 设置决定是否抢回 VIP
所有步骤必须记录起止时间、命令输出片段、关键日志行（如 “VRRP_Instance(VI_1) Entering MASTER STATE”），用于事后比对 SLA 是否达标。
固化恢复逻辑与更新演练文档
每次演练暴露的问题要直接反哺生产配置：
• 若发现 Apache 启动慢导致 VIP 漂移延迟，需优化 httpd.conf（减少 LoadModule、调整 StartServers）
• 若健康检查脚本超时过长（如默认 10s），应缩短至 3s 并增加重试次数
• 若日志中频繁出现 “Keepalived_vrrp: (VI_1): setting VIPs.” 但服务未就绪，需在 notify_master 脚本中加入 wait_for_httpd_ready 函数
最终形成一份带时间戳的《Apache HA 故障恢复演练报告》，包含：故障注入方式、实际恢复耗时、验证结果截图、配置优化项、下次演练建议（如加入磁盘满、OOM killer 触发等新场景）。
立即学习“Java免费学习笔记（深入）”；
