1. Keepalived健康检查机制深度解析
在构建高可用集群时，Keepalived作为业界主用的负载均衡解决方案，其健康检查机制直接决定了整个系统的可靠性。今天我想和大家深入探讨两种最核心的健康检查方式：VRRP Script脚本检查和HTTP_GET应用层检查。这两种机制看似相似，实则定位完全不同，很多工程师在实际部署时容易混淆它们的适用场景。
我在过去五年里部署过数十套Keepalived集群，从电商大促到金融交易系统，深刻体会到这两种检查机制配合使用的重要性。记得有一次线上事故，由于错误配置了检查方式，导致整个支付系统雪崩——这正是我们今天要避免的。
2. VRRP Script与HTTP_GET的本质区别
2.1 检测对象：节点与服务的不同维度
VRRP Script就像系统的全科医生，它关注的是整个Keepalived节点的"生命体征"。当我在配置文件中定义一个vrrp_script时，实际上是在为这个节点设置一套健康评估标准。常见的检查包括：
- 关键进程存活状态（如Nginx/HAProxy）
- 系统资源水位（CPU/内存/磁盘）
- 网络连通性（网关可达性测试）
- 自定义业务指标（如日志错误率）
而HTTP_GET更像是专科医生，它只专注于单个后端服务的"专科检查"。每个real_server可以配置独立的HTTP健康检查，比如：
- HTTP状态码验证
- 响应内容匹配（正则表达式）
- 连接超时控制
- TLS证书检查（SSL_GET）
关键经验：VRRP Script失败会导致VIP漂移，而HTTP_GET失败只会影响单个后端服务的流量分配。这就好比医院急诊科（VRRP Script）和专科门诊（HTTP_GET）的区别。
2.2 工作机制：优先级调整与负载剔除
当VRRP Script检测失败时，它会通过weight参数动态调整节点优先级。这里有个计算公式需要特别注意：
code复制最终优先级 = 初始优先级 + ∑(健康脚本的weight值)
假设主节点配置priority=100，weight=-30，那么当脚本检测失败时：
- 主节点优先级变为70（100-30）
- 如果备节点priority=90，此时备节点优先级更高（90>70）
- 触发主备切换，VIP转移到备节点
而HTTP_GET的工作机制完全不同，它通过TCP三次握手+HTTP请求验证后端健康状态。当检测失败时：
- 该real_server被标记为"不健康"
- 从LVS转发规则中临时移除
- 其他健康后端继续提供服务
- 不会触发VIP切换
2.3 配置架构：全局与局部的设计哲学
VRRP Script的配置具有全局性，通常放在keepalived.conf的顶层：
bash复制vrrp_script chk_nginx {
script "/usr/local/bin/check_nginx.sh"
interval 2
weight -20
fall 2
rise 1
}
vrrp_instance VI_1 {
track_script {
chk_nginx
}
}
而HTTP_GET则是服务级别的配置，嵌套在virtual_server块内：
bash复制virtual_server 10.0.0.100 80 {
real_server 10.0.0.14 80 {
HTTP_GET {
url {
path /health
status_code 200
}
}
}
}
3. 配置实战与高级技巧
3.1 VRRP Script最佳实践
3.1.1 智能脚本编写技巧
一个健壮的检测脚本应该包含以下要素：
bash复制#!/bin/bash
# 检查Nginx进程
if ! pgrep -x "nginx" >/dev/null; then
# 尝试优雅重启
systemctl try-restart nginx
sleep 2
# 二次确认
if ! pgrep -x "nginx" >/dev/null; then
# 记录故障日志
logger -t keepalived "Nginx recovery failed, triggering failover"
exit 1
fi
fi
# 额外检查：磁盘空间
DISK_USAGE=$(df -h / | awk 'NR==2 {print $5}' | tr -d '%')
if [ $DISK_USAGE -gt 90 ]; then
logger -t keepalived "Disk space critical: ${DISK_USAGE}%"
exit 1
fi
exit 0
3.1.2 参数调优经验
- interval：生产环境建议2-5秒，太频繁会增加系统负载
- weight：建议设置为
-(主备优先级差+10)，例如主100备90，则weight=-20 - fall/rise：防止抖动，通常fall>rise（如3次失败2次恢复）
3.2 HTTP_GET高级配置
3.2.1 复杂健康检查配置
bash复制HTTP_GET {
url {
path /api/health
digest e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855 # 响应体SHA256校验
status_code 200-399 # 接受2xx和3xx状态码
}
connect_port 8080 # 指定非标准端口
connect_timeout 5
warmup 5 # 服务启动后等待5秒开始检查
}
3.2.2 动态权重调整
通过HTTP检查结果动态调整后端权重：
bash复制real_server 10.0.0.15 80 {
weight 10
HTTP_GET {
url {
path /load
status_code 200
}
on_success {
weight +=5 # 健康时增加权重
}
on_failure {
weight -=10 # 失败时大幅降低权重
}
}
}
4. 典型应用场景剖析
4.1 电商大促架构案例
在去年双十一的某电商架构中，我们采用了三级健康检查：
-
节点级：VRRP Script检查
- Nginx进程存活
- 系统负载（load average < CPU核心数*2）
- 网络延迟（网关ping < 50ms）
-
服务级：HTTP_GET检查
- 商品API的/health端点
- 响应时间 < 300ms
- 错误率 < 0.5%
-
业务级：自定义脚本
- 订单创建成功率
- 库存一致性校验
这种分层检查机制在峰值10万QPS下保持了99.995%的可用性。
4.2 微服务架构下的特殊考量
对于Spring Cloud微服务，需要注意：
- 健康端点通常为/actuator/health
- 需要处理HTTP 503（服务未就绪）
- 建议添加自定义健康指标：
java复制@Component
public class CustomHealthIndicator implements HealthIndicator {
@Override
public Health health() {
// 添加业务健康检查逻辑
return Health.up().withDetail("queue_size", queue.size()).build();
}
}
5. 避坑指南与疑难排查
5.1 常见配置陷阱
-
权限问题：
- VRRP Script需要root权限
- 脚本必须设置可执行位（chmod +x）
- SELinux可能阻止脚本执行
-
时间参数误区：
- 总超时时间 = connect_timeout + (nb_get_retry * delay_before_retry)
- 示例：connect_timeout=3, retry=3, delay=1 → 最大可能耗时6秒
-
日志调试技巧：
bash复制tail -f /var/log/messages | grep keepalived # 增加调试日志 vrrp_instance VI_1 { debug 1 # 1-4级，数字越大日志越详细 }
5.2 性能优化建议
-
对于大规模集群：
- 将HTTP_GET检查分散到不同时间点
- 使用keepalived的misc_check替代重量级脚本
- 考虑采用轻量级协议（如gRPC健康检查）
-
容器化环境：
bash复制vrrp_script chk_docker { script "docker inspect --format='{{.State.Status}}' nginx | grep -q running" interval 5 weight -10 }
6. 架构演进与新型方案
随着云原生发展，健康检查也出现了新范式：
-
混合云场景：
- 通过API检查云服务健康状态
- 集成云厂商的LB健康检查
- 多活架构下的健康检查策略
-
服务网格集成：
bash复制vrrp_script chk_istio { script "kubectl get pod -l app=nginx -o jsonpath='{.items[0].status.phase}' | grep -q Running" timeout 10 } -
eBPF加速方案：
使用eBPF实现内核层面的健康检查，将检测耗时从毫秒级降到微秒级。