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

用户请求
    │
    ▼
  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反向代理（七层）
工作层级	TCP/UDP	HTTP/HTTPS
性能	极高（内核态转发）	高（用户态处理）
功能	纯负载均衡	负载均衡+SSL卸载+缓存+重写
配置复杂度	中	低

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

2.2 LVS的三种工作模式

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

模式	请求流向	响应流向	性能	网络要求
NAT	客户端→LVS→Real Server	Real Server→LVS→客户端	中（进出都过LVS）	Real Server网关指向LVS
DR（直接路由）	客户端→LVS→Real Server	Real Server直接→客户端	高（响应不走LVS）	LVS和Real Server在同一物理网段
TUN（IP隧道）	客户端→LVS→Real Server	Real Server直接→客户端	高	Real Server需支持IP隧道

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漂移的场景：

多台设备组成一个VRRP组，对外共享一个虚拟IP（VIP）
推举出一台Master拥有VIP，处理所有请求
Master持续发送组播心跳包（VRRP Advertisement，默认每1秒一次）
Backup在MASTER_DOWN_TIMER（通常配置为3秒）内没收不到心跳，自动升级为Master，接管VIP
原来的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。

四、完整架构部署清单

主机	IP	角色	软件
LVS-1	192.168.1.5	主LVS + Keepalived Master	ipvsadm + keepalived
LVS-2	192.168.1.6	备LVS + Keepalived Backup	ipvsadm + keepalived
RS-1	192.168.1.10	后端Nginx	nginx
RS-2	192.168.1.11	后端Nginx	nginx
VIP	192.168.1.100	对外暴露的虚拟IP	-

用户访问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秒

完整命令速查：

操作	命令
添加VIP	`keepalived.conf` 的 `virtual_ipaddress`
查看VIP在哪台机器	`ip addr show eth0`
添加LVS服务	`keepalived.conf` 的 `virtual_server`
查看LVS规则	`sudo ipvsadm -L -n`
查看VRRP组播心跳	`sudo tcpdump -i eth0 vrrp -n`

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

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卸载。