【Linux从入门到精通】第48篇：Linux集群与负载均衡——LVS与Keepalived高可用

目录

一、引言：从单机到集群的必经之路

二、LVS：四层负载均衡的核心

2.1 LVS是什么？

2.2 LVS的三种工作模式

2.3 DR模式的核心原理

三、Keepalived：VRRP协议与高可用

3.1 单台LVS的问题

3.2 VRRP协议原理

3.3 Keepalived：VRRP的Linux实现

3.4 验证高可用

四、完整架构部署清单

五、常见问题排查

5.1 VRRP心跳不通导致脑裂（Split-Brain）

5.2 DR模式下后端收不到请求

六、本篇小结

动手练习（两台虚拟机模拟）

七、下篇预告

一、引言：从单机到集群的必经之路

在第32篇，我们搭建了单台Nginx服务器。随着业务增长，你会遇到两个瓶颈：

瓶颈一：一台Nginx处理不过来

Nginx本身性能极高，但终究受限于单机的CPU和网络带宽。当并发超过单机极限时，简单的做法是增加多台Nginx，由一台“分发器”统一接收请求，再转发给后端。

瓶颈二：分发器本身成了单点故障（SPOF）

如果这台分发器宕机了，后端再多的Nginx都没用——所有请求都进不来。这是典型的单点故障（Single Point of Failure）。解决方法是再加一台备用分发器，主分发器故障时备机自动接管。

text

用户请求 │ ▼ VIP（虚拟IP，永远在线） │ ▼ ┌──────────┐ ┌──────────┐ │ LVS 主 │ │ LVS 备 │ ← Keepalived 保证 VIP 在主备间漂移 └────┬─────┘ └─────┬────┘ │ │（备机空闲监控） ▼ ┌─────────────────────────────┐ │ Nginx1 Nginx2 Nginx3 │ ← 真实Web服务器 └─────────────────────────────┘

本文要搭建的就是这套架构：LVS做四层负载均衡和主备高可用，Nginx做七层Web处理。

二、LVS：四层负载均衡的核心

2.1 LVS是什么？

LVS（Linux Virtual Server，Linux虚拟服务器）是Linux内核自带的四层负载均衡框架。它工作在OSI模型的第四层（TCP/UDP层），不关心HTTP协议的内容，只根据IP和端口来分发请求。

与Nginx的七层反向代理相比：

实际生产中，LVS和Nginx经常组合使用：LVS在前端做第一层高性能分发，Nginx在后端做第二层七层处理和反向代理。

2.2 LVS的三种工作模式

LVS有三种转发模式，本文重点对比最常用的NAT和DR：

NAT模式（网络地址转换）：LVS作为“转发器”，用户请求经过LVS转发到后端，后端响应也原路经过LVS返回。这是最简单的模式，但出站流量也要经过LVS，在高并发时LVS可能成为出站瓶颈。

DR模式（直接路由）：LVS只处理进来的请求（入站路径），后端的响应直接返回给用户（出站路径绕过LVS）。这利用了“大部分请求的特点是请求小、响应大”这一事实——入站流量可能只有几十KB的HTTP头部，出站响应却有几十MB的文件下载。DR模式让LVS只扛入站，出站的带宽压力分散到各后端节点。这是生产环境最常用的模式，但要求LVS和后端在同一个物理网段上（因为它们需要共享同一个VIP来做MAC层的转发）。

2.3 DR模式的核心原理

DR模式的关键是MAC地址欺骗——LVS和所有后端Real Server共享同一个VIP，但只有LVS响应ARP请求，确保入站流量先到LVS。然后LVS修改数据包的目标MAC地址为后端Real Server的MAC，原IP头部不变，直接将数据包转给后端；后端处理完后，由于VIP就绑在自己本地，直接以VIP身份将响应发给用户。

配置LVS主要使用ipvsadm命令：

bash

# 安装ipvsadm sudo apt install ipvsadm -y sudo dnf install ipvsadm -y # 添加虚拟服务（VIP和端口） sudo ipvsadm -A -t 192.168.1.100:80 -s rr # 添加后端Real Server（DR模式） sudo ipvsadm -a -t 192.168.1.100:80 -r 192.168.1.10:80 -g sudo ipvsadm -a -t 192.168.1.100:80 -r 192.168.1.11:80 -g # 查看LVS规则 sudo ipvsadm -L -n # 查看连接统计 sudo ipvsadm -L -n --stats

-s rr指定轮询调度算法，-g表示DR模式（-m为NAT模式，-i为TUN模式）。

此时你访问http://192.168.1.100，请求会被轮询分发到192.168.1.10和192.168.1.11。

三、Keepalived：VRRP协议与高可用

3.1 单台LVS的问题

上面搭建的LVS已经能分发请求了。但只有一个LVS——它自己宕机了怎么办？整个集群就全瘫痪了。

高可用的思想是：配置两台LVS，一台主（Master）一台备（Backup）。正常情况下VIP在主LVS上，主LVS处理所有请求，备机在一旁监控。主LVS宕机时，备机自动把VIP接管过来，继续分发请求——对用户来说，VIP始终可达。

这个“VIP在主备之间切换”的机制，依赖的就是VRRP协议（Virtual Router Redundancy Protocol，虚拟路由器冗余协议）。

3.2 VRRP协议原理

VRRP的原始设计是为路由器提供冗余，但其思想完全适用于任何需要VIP漂移的场景：

1. 多台设备组成一个VRRP组，对外共享一个虚拟IP（VIP）

2. 推举出一台Master拥有VIP，处理所有请求

3. Master持续发送组播心跳包（VRRP Advertisement，默认每1秒一次）

4. Backup在MASTER_DOWN_TIMER（通常配置为3秒）内没收不到心跳，自动升级为Master，接管VIP

5. 原来的Master恢复后，可以重新抢占回VIP（或保持Backup状态，取决于配置）

3.3 Keepalived：VRRP的Linux实现

Keepalived是Linux上最常见的VRRP实现，同时也内置了LVS管理功能——它能自动将配置的LVS规则添加到内核，不需要手动执行ipvsadm。

bash

sudo apt install keepalived -y sudo dnf install keepalived -y

主LVS配置（/etc/keepalived/keepalived.conf）：

nginx

# 全局定义 global_defs { router_id LVS_MASTER } # VRRP实例定义 vrrp_instance VI_1 { state MASTER # 初始状态：主 interface eth0 # VIP绑定在哪个网卡上 virtual_router_id 51 # VRRP组ID（主备必须相同） priority 100 # 优先级（主>备） advert_int 1 # 心跳间隔（秒） authentication { auth_type PASS auth_pass 123456 # 主备密码一致 } virtual_ipaddress { 192.168.1.100/24 # 虚拟IP（VIP） } } # 虚拟服务器定义（LVS规则） virtual_server 192.168.1.100 80 { delay_loop 6 # 健康检查间隔 lb_algo rr # 调度算法：轮询 lb_kind DR # 工作模式：直接路由 real_server 192.168.1.10 80 { weight 1 TCP_CHECK { connect_timeout 3 } } real_server 192.168.1.11 80 { weight 1 TCP_CHECK { connect_timeout 3 } } }

备LVS配置（只需修改三处）：

nginx

global_defs { router_id LVS_BACKUP } vrrp_instance VI_1 { state BACKUP # 改为BACKUP interface eth0 virtual_router_id 51 priority 50 # 降低优先级（< 主） advert_int 1 authentication { auth_type PASS auth_pass 123456 } virtual_ipaddress { 192.168.1.100/24 } } # virtual_server 部分与主LVS完全相同

3.4 验证高可用

bash

# 两台LVS都启动Keepalived sudo systemctl start keepalived sudo systemctl enable keepalived # 在主LVS上查看VIP ip addr show eth0 | grep 192.168.1.100 # 在主LVS上查看LVS规则 sudo ipvsadm -L -n # 测试：停止主LVS的Keepalived，在备机上查看VIP是否漂移过来 # 主LVS执行： sudo systemctl stop keepalived # 备LVS上： ip addr show eth0 | grep 192.168.1.100 # VIP应该已出现在备机 # 重新启动主LVS，VIP会自动回切（优先级高） sudo systemctl start keepalived

漂移时间通常2-3秒——备机发现心跳中断（3秒无心跳），立即接管VIP。

四、完整架构部署清单

用户访问http://192.168.1.100→ 请求到达当前持有VIP的LVS → LVS轮询将请求MAC地址改写 → 请求到达RS-1或RS-2 → Nginx处理 → 响应直接返回用户。

五、常见问题排查

5.1 VRRP心跳不通导致脑裂（Split-Brain）

表现：主备同时持有VIP，两台机器都在分发请求，互相不知道对方存活着。

原因：VRRP心跳包被防火墙拦截或两台LVS之间链路故障。VRRP的心跳是通过组播地址224.0.0.18发送的，防火墙必须放行这个组播地址或两台LVS之间的VRRP协议报文。

排查：

bash

# 抓取VRRP心跳包（检查是否被防火墙丢弃） sudo tcpdump -i eth0 vrrp -n # 如果一侧持续看不到另一侧的心跳包，防火墙很可能是原因

5.2 DR模式下后端收不到请求

DR模式要求LVS和后端Real Server在同一物理网段，后端需配置VIP的ARP抑制（不能让后端把自己的VIP暴露出去抢占流量，否则请求会绕过LVS直接到达某个后端）。

六、本篇小结

LVS核心模式：

• NAT：进出都过LVS，简单但出站有瓶颈

• DR：请求进LVS，响应直接回用户，高性能、最常用

Keepalived高可用：

• VRRP协议：主备共享VIP，心跳中断→备自动接管

• 主备优先级差 + 3秒心跳超时 = VIP漂移时间约2-3秒

完整命令速查：

动手练习（两台虚拟机模拟）

bash

# 1. 两台虚拟机都安装keepalived和ipvsadm sudo apt install keepalived ipvsadm -y # 2. 按第四节配置主备LVS的 /etc/keepalived/keepalived.conf # 主 LVS：state MASTER, priority 100 # 备 LVS：state BACKUP, priority 50 # 3. 启动并验证VIP在主LVS上 sudo systemctl start keepalived ip addr show | grep VIP # 4. 模拟主LVS故障 sudo systemctl stop keepalived # 5. 在备LVS上验证VIP已漂移 ip addr show | grep VIP # 6. 恢复主LVS，观察VIP自动回切 sudo systemctl start keepalived

七、下篇预告

LVS解决了负载均衡和高可用，但生产环境中问题依然会发生——CPU飙了、磁盘慢了、网络卡了、服务挂了。当监控告警响起时，你应该从哪里入手？先查什么、后查什么？

下一篇《服务器故障排查终极指南》将给你一套经得起实战检验的排查路线图——从快速确认问题范围到逐层排除CPU、内存、磁盘、网络、应用五大系统，从lsof恢复误删文件到perf火焰图定位内核耗时。这是运维能力从“会操作”到“会救火”的关键一步。

延伸思考：LVS在DR模式下，入站流量经过LVS但出站流量直接从Real Server回到用户，这就是非对称负载均衡。非对称设计能大幅降低LVS的压力（入站请求几百KB，出站响应几百MB），但也意味着LVS看不到完整的TCP流——它无法对七层内容（HTTP头、Cookie等）做任何判断。这也是为什么实际生产环境常用LVS（四层分发）+ Nginx（七层处理和SSL）的组合：LVS负责快速分发，Nginx负责应用层处理和SSL卸载。