LVS (Linux Virtual Server) 结合 Keepalived 是实现高可用、高性能网络服务（如 Web、数据库、邮件等）的经典解决方案。它利用 LVS 提供强大的四层（传输层，TCP/UDP）负载均衡能力，并通过 Keepalived 实现负载均衡器本身的高可用性（HA），避免单点故障。
核心组件与工作原理
LVS (IPVS):
角色：核心负载均衡器。工作在内核空间 (
ip_vs模块)，效率极高。功能：接收客户端请求，根据配置的调度算法 (如轮询
rr、加权轮询wrr、最少连接lc、加权最少连接wlc、源地址哈希sh等)，将请求转发给后端真实服务器集群 (Real Servers, RS)。工作模式 (关键选择)：
NAT (Network Address Translation):
LVS 修改请求和响应的 IP 地址/端口。
进出流量都经过 LVS，易成为瓶颈。RS 网关需指向 LVS。
DR (Direct Routing):
最常用、高性能模式。
LVS 只修改请求帧的 MAC 地址，将其直接路由给选中的 RS。
RS 处理请求并直接将响应发送回客户端 (不经过 LVS)。
要求 LVS 和所有 RS 在同一物理网络/VLAN (不能跨路由器)。RS 需要配置 VIP (Virtual IP) 在 loopback 接口上并抑制 ARP 响应 (
arp_ignore=1,arp_announce=2)。
TUN (IP Tunneling):
在 LVS 和 RS 之间建立 IP 隧道。
LVS 将请求封装在 IP 隧道包中发送给 RS。
RS 解封装后处理请求，并将响应直接发送回客户端。
允许 LVS 和 RS 在不同网络，但配置复杂，性能开销略高于 DR。
Keepalived:
角色：实现 LVS 负载均衡器本身的高可用性 + 管理 LVS 配置 + 监控后端 RS 健康状态。
核心机制：VRRP (Virtual Router Redundancy Protocol)。
多个 LVS 节点（通常是两个：
Master和Backup）组成一个 VRRP 组。组内所有节点都配置一个相同的虚拟路由器 ID (VRID)。
组内选举出一个
Master节点。Master节点持有虚拟 IP 地址 (VIP)，这个 VIP 就是客户端访问服务的地址。Master节点定期发送 VRRP 通告 (advert) 给组内其他节点，宣告自己存活。Backup节点监听通告。如果Backup在指定时间内 (advert_int+n * priority delay) 没有收到Master的通告，它会发起选举，成为新的Master并接管 VIP。优先级 (
priority) 决定选举结果（值高的优先）。
功能：
LVS 高可用 (VRRP)：自动进行故障转移（Failover），确保 VIP 始终可用。
管理 LVS 规则：Keepalived 根据其配置文件 (
keepalived.conf) 自动在活动节点 (Master) 上配置 LVS 的虚拟服务器 (virtual_server) 和后端 RS (real_server)。健康检查 (Health Checking)：
对后端 RS：Keepalived (
Master) 定期检查配置的每个real_server的健康状态（如 TCP 连接检查、HTTP GET 检查、自定义脚本检查等）。如果检测到 RS 故障，它会将其从 LVS 转发池中移除。当 RS 恢复后，再将其重新加入。对 LVS 节点自身服务：可配置脚本检查本机上的关键服务（如
ipvsadm服务本身、或依赖的进程），如果检查失败，Keepalived 可以主动降低自身优先级 (priority)，触发主备切换，让更健康的节点接管。这有助于处理“僵死”节点（网络通但服务挂的情况）。
典型架构 (以 DR 模式为例)
+-----------------------+
| Client |
+----------+------------+
| (请求目标: VIP)
|
+----------v------------+ +-----------------------+
| | VRRP | |
| LVS/Keepalived <--------> LVS/Keepalived |
| (Master) | | (Backup) |
| [VIP:eth0] | | [VIP:未激活] |
+----------+------------+ +-----------------------+
| (DR 模式: 转发请求到 RS, 目标 MAC 是选中的 RS)
|
+----------v---------------------------+
| Switch / VLAN |
+-----+--------------+-----------------+
| |
+-------v----+ +------v-------+
| Real Server| | Real Server |
| (RS1) | | (RS2) |
| [VIP:lo:0] | | [VIP:lo:0] | <-- VIP 配置在 loopback 接口，抑制 ARP
+------------+ +--------------+
| |
| (响应直接发送给客户端，源IP是VIP)
|
+-----v----------------------+
| Client |
+----------------------------+
关键配置文件 (keepalived.conf) 主要部分
global_defs {
notification_email { ... } # 报警邮件设置 (可选)
router_id LVS_DEVEL # 标识本节点
}
# VRRP 实例配置 - 实现 LVS 节点 HA
vrrp_instance VI_1 {
state MASTER # 初始状态 MASTER 或 BACKUP
interface eth0 # 绑定 VRRP 的物理接口
virtual_router_id 51 # VRRP 组 ID (必须相同)
priority 100 # 选举优先级 (MASTER 通常更高)
advert_int 1 # VRRP 通告间隔 (秒)
authentication { # VRRP 认证 (可选，简单密码)
auth_type PASS
auth_pass 1111
}
virtual_ipaddress { # 要管理的 VIP (可以有多个)
192.168.1.100/24 dev eth0 label eth0:0 # VIP 配置在 eth0:0
}
# 可选的脚本跟踪接口/脚本检查
track_script {
chk_haproxy # 引用下面定义的脚本检查 (可选)
}
}
# 定义一个 LVS 虚拟服务器 (Virtual Server)
virtual_server 192.168.1.100 80 { # VIP 和端口
delay_loop 6 # 健康检查间隔 (秒)
lb_algo wrr # 调度算法 (加权轮询)
lb_kind DR # 工作模式 (DR)
persistence_timeout 50 # 会话保持时间 (秒，可选)
protocol TCP # 协议
# 真实服务器 1 (Real Server)
real_server 192.168.1.11 80 {
weight 1 # 权重 (用于 wrr, wlc 等算法)
# TCP 健康检查
TCP_CHECK {
connect_timeout 3 # 连接超时
nb_get_retry 3 # 重试次数
delay_before_retry 3 # 重试间隔
connect_port 80 # 检查端口
}
# 或者 HTTP_GET 健康检查
# HTTP_GET {
# url { path /healthz }
# connect_timeout 3
# nb_get_retry 3
# delay_before_retry 3
# }
}
# 真实服务器 2 (Real Server)
real_server 192.168.1.12 80 {
weight 2
TCP_CHECK { ... } # 同上
}
}
# 可选的额外脚本检查 (用于 track_script)
vrrp_script chk_haproxy {
script "/usr/bin/killall -0 haproxy" # 检查 haproxy 进程是否存在 (示例)
interval 2 # 检查间隔
weight 2 # 检查失败时优先级变化值 (可负)
}
优点
高性能：LVS 内核转发，效率极高，尤其 DR/TUN 模式避免响应瓶颈。
高可用：Keepalived 实现 LVS 节点故障自动转移，服务不中断。
可扩展性：后端 RS 可以水平扩展以应对增长流量。
透明性：客户端只感知 VIP，后端服务器变化对客户端透明。
灵活性：支持多种负载均衡算法和健康检查方式。
成熟稳定：技术成熟，在大型互联网公司广泛使用多年。
缺点/注意事项
配置复杂性：尤其 DR 模式下的 ARP 抑制和网络拓扑要求。
单点配置：Keepalived 主节点负责 LVS 配置管理，需确保配置同步（通常靠同步配置文件解决，Keepalived 自身不负责配置同步）。
脑裂 (Split-Brain) 风险：如果 VRRP 通告因网络分区无法传递，可能导致两个节点都认为自己是 Master 并持有 VIP。需要合理设置优先级、通告间隔，并在网络设计上尽量避免分区。有时需依赖额外的监控和仲裁机制。
模式限制：
DR/TUN：要求后端应用不能依赖源 IP（因为客户端 IP 直达 RS，RS 看到的源 IP 是真实客户端 IP，但 LVS 可能修改了 TCP 选项如时间戳，某些应用需注意）。
NAT：LVS 可能成为带宽和连接数瓶颈，且需要 RS 网关指向 LVS。
功能层级：LVS 是四层负载均衡，不感知应用层内容（如 HTTP URL、Cookie）。如需七层负载均衡（更智能的路由），需要在 RS 上部署 Nginx/Haproxy 或使用专门的七层负载均衡器。
部署步骤概要
规划：确定 VIP、真实服务器 IP、网络拓扑（推荐同一 VLAN DR 模式）、调度算法、健康检查方式。
配置后端 RS：
安装并配置应用服务 (Nginx, Apache, Tomcat 等)。
配置 VIP 在 loopback 接口 (仅 DR/TUN 模式需要)。
配置 ARP 抑制 (
arp_ignore=1,arp_announce=2)。确保 RS 防火墙允许 VIP 和健康检查流量。
配置 LVS/Keepalived 节点 (所有节点)：
安装
ipvsadm(管理工具) 和keepalived。编辑
/etc/keepalived/keepalived.conf(如上示例)。确保配置文件在节点间一致（主备的
state和priority不同）。开启内核转发 (
net.ipv4.ip_forward=1for NAT)。确保 VRRP 通告端口 (通常是 112) 和健康检查端口在防火墙允许。
启动服务：
在所有 LVS 节点启动
keepalived服务：systemctl start keepalived && systemctl enable keepalived检查日志 (
journalctl -u keepalived -f)，确认 Master 选举成功，VIP 绑定正确。在 Master 节点使用
ipvsadm -Ln检查 LVS 规则和后端 RS 状态。
测试：
访问 VIP 测试服务是否正常。
模拟故障测试：
关闭 Master 的 keepalived：观察 Backup 是否接管 VIP 和 LVS 规则。
关闭一个后端 RS：观察 LVS Master 是否将其从池中移除 (
ipvsadm -Ln查看状态)。恢复 RS：观察是否重新加入池。
(可选) 模拟网络分区测试脑裂处理。
总结
LVS + Keepalived 是一个强大、高效且成熟的四层高可用负载均衡解决方案。它特别适合处理高流量、对性能要求苛刻且需要高可用性的场景（如 Web 前端、API 网关、缓存层等）。虽然配置（尤其是 DR 模式）相对复杂并需要注意网络拓扑和 ARP 问题，但其卓越的性能和稳定性使其在基础设施领域占据重要地位。理解其工作原理和不同模式的特点对于成功部署和维护至关重要。