目录
一、 Keepalived 双机热备核心技术
1.1 Keepalived 架构与 VRRP协议
Keepalived 的核心价值在于通过 VRRP（虚拟路由冗余协议） 实现服务高可用。其架构设计包含三层关键组件：
- VRRP Stack：管理虚拟路由器状态（MASTER/BACKUP），通过多播心跳包（advert_int参数控制频率）实现节点通信。
- Checkers：对后端服务（如 LVS节点、Nginx）进行健康检测，支持TCP/HTTP/SSL 等多种检测方式。
- SMTP Notifier：故障切换时发送邮件告警。
VRRP工作流程
1. 初始化：各节点广播优先级（priority）
2. 选举：最高优先级节点成为 MASTER，持有 VIP
3. 心跳：MASTER 周期性发送 Advertisement 包
4. 故障切换：当 BACKUP 节点超时未收到心跳，触发选举新 MASTER
1.2 双机热备配置深度优化
配置文件 /etc/keepalived/keepalived.conf 的精准控制：
关键参数说明：
vrrp_instance VI_1 {
state MASTER # 初始状态（MASTER/BACKUP）
interface ens33 # 绑定 VIP 的物理网卡
virtual_router_id 62 # 集群唯一ID (0-255)
priority 100 # 选举权重（MASTER > BACKUP）
advert_int 1 # 心跳间隔（秒）
authentication {
auth_type PASS # 认证方式
auth_pass 1111 # 密码（所有节点一致）
}
virtual_ipaddress {
192.168.10.100/24 # VIP（可配置多个）
}
}故障切换性能优化：
- 减少 advert_int 值（如0.5秒）加速故障检测
- 设置 nopreempt 防止优先级反转导致的频繁切换
- 日志追踪： tail -f /var/log/messages 监控状态迁移事件
二、 LVS+Keepalived 高可用负载均衡架构
2.1 系统架构设计
+---------------------+
| Client |
+----------+----------+
|
+----------+----------+
| VIP: 192.168.10.100|
+----------+----------+
|
+----------------+----------------+
| |
+---------+---------+ +---------+---------+
| Master LVS (lb01)| | Backup LVS (lb02)|
| IP: 192.168.10.101| | IP: 192.168.10.102|
+---------+---------+ +---------+---------+
| |
+---------+---------+ +---------+---------+
| Web01 (web01) | | Web02 (web02) |
| IP: 192.168.10.103| | IP: 192.168.10.104|
+-------------------+ +-------------------+
2.2 LVS集成配置详解
Keepalived 通过 virtual_server 断管理 LVS规则：
DR 模式核心配置：
virtual_server 192.168.10.100 80 {
delay_loop 3 # 健康检查间隔（秒）
lb_algo rr # 调度算法（rr/wlc/lc）
lb_kind DR # 工作模式（DR/NAT/TUN）
persistence_timeout 50 # 会话保持时间
# 真实服务器池配置
real_server 192.168.10.103 80 {
weight 1 # 权重值
TCP_CHECK {
connect_port 80 # 检测端口
connect_timeout 3 # 连接超时
retry 3 # 重试次数
delay_before_retry 2 # 重试间隔
}
}
# 其他节点类似配置...
}调度算法对比：
| 算法 | 名称 | 适用场景 |
| rr | 轮询 | 各服务器性能均等时 |
| wlc | 加权最小连接数 | 服务器性能差异较大时 |
| sh | 源地址哈希 | 需要会话保持的应用 |
三、 关键技术与疑难解析
3.1 DR模式 ARP 仰制机制
问题场景：多台服务器声明 VIP导致ARP冲突
解决方案（节点服务器配置）：
# 配置 ARP 参数
echo 1 > /proc/sys/net/ipv4/conf/lo/arp_ignore
echo 2 > /proc/sys/net/ipv4/conf/lo/arp_announce
echo 1 > /proc/sys/net/ipv4/conf/all/arp_ignore
echo 2 > /proc/sys/net/ipv4/conf/all/arp_announce
# 添加 VIP 到 lo 接口
ip addr add 192.168.10.100/32 dev lo label lo:0参数含义：
- arp_ignore=1:仅响应目标IP为本机接口的ARP请求
- arp_announce=2：始终使用最佳本地地址进行ARP宣告
3.2 健康检查策略优化
高阶检测方式示例：
real_server 192.168.10.103 80 {
HTTP_GET {
url {
path /healthz # 健康检查URL
status_code 200 # 预期状态码
}
connect_timeout 3
retry 3
}
}检查类型对比：
| 类型 | 特点 | 适用场景 |
| TCP_CHECK | 建立TCP连接即视为健康 | 快速检测端口存活 |
| HTTP_GET | 验证HTTP状态码和内容 | Web应用深度健康检查 |
| SSL_GET | 支持HTTPS证书验证 | 安全要求高的场景 |
四、 企业级运维实践
4.1 故障转移测试方案
sequenceDiagram
Client->>+MASTER: 请求(VIP)
MASTER->>Web01: 转发请求
Web01-->>Client: 返回数据
Note over MASTER: 模拟故障（停止Keepalived）
Client->>+BACKUP: 请求(VIP)
BACKUP->>Web02: 转发请求
Web02-->>Client: 返回数据关键指标验证：
- 切换时间：通过 ping -t VIP 观察丢包数（应≤2个）
- 服务一致性：检查 Web 内容是否同步（需配合 NFS/rsync）
- 日志追踪：监控 /var/log/messages 中状态迁移记录
4.2 性能调优建议
内核参数优化：
# 提高端口复用能力
sysctl -w net.ipv4.tcp_tw_reuse=1
sysctl -w net.ipv4.ip_local_port_range="1024 65000"
# 增大连接跟踪表
sysctl -w net.netfilter.nf_conntrack_max=1000000LVS 连接管理：
virtual_server 192.168.10.100 80 {
# 开启SYN Cookie防护
syn_proxy on
# 设置最大连接数
connection_timeout 300
}五、 架构演进与最佳实践
5.1 从双机热备到最多集群
+-----------+
| Global LB|
+-----+-----+
|
+--------------+--------------+
| |
+-------+-------+ +---------+-------+
| Region1 LVS | | Region2 LVS |
| VIP: 10.1.1.1| | VIP: 10.2.2.1 |
+-------+-------+ +---------+-------+
| |
+-------+-------+ +---------+-------+
| Web Cluster | | Web Cluster |
| (Keepalived) | | (Keepalived) |
+--------------+ +-----------------+
5.2 灾备设计原则
- RTO（恢复时间目标）：通过预配置脚本将切换时间控制在秒级
- RPO（数据恢复点）：采用DRBD+Keepalived 实现存储级高可用
- 异地多活：结合DNS智能解析实现跨地域流量调度
结语：构建坚不可摧的服务基座
LVS+Keepalived 的组合为关键业务系统提供了双重保障：
- 流量层：LVS 实现高性能负载分发，单集群可支撑 10Gbps+流量
- 容错层：Keepalived 确保调度器持续可用，切换过程用户无感知
成功部署的关键要素：
严格遵循 DR 模式的 ARP 抑制配置
健康检查策略需匹配业务特性
生产环境必须进行故障注入测试
日志监控系统集成（如 ELK 收集 /var/log/messages）
随着云原生技术的发展，该方案可与 Kubernetes Ingress Controller 集成，为传统架构向云原生演进提供平滑过渡路径，成为混合云场景下的核心流量治理方案。