LVS+Keepalived群集

|华|2026-04-15 19:56

LVS+Keepalived 是 Linux 生态下企业级标准的四层负载均衡 + 高可用集群解决方案，核心通过 LVS 实现业务流量的高效分发，通过 Keepalived 解决负载均衡节点的单点故障问题，同时内置健康检查能力，保障集群业务的连续性与高并发承载能力，广泛应用于互联网、金融、政企等生产环境的核心业务接入层。

一、核心组件深度解析

1.1 LVS（Linux Virtual Server）

LVS 是章文嵩博士于 1998 年开发的Linux 内核级四层负载均衡器，工作在 OSI 模型的传输层（TCP/UDP），基于 Linux 内核 Netfilter 框架实现，现已内置到 Linux 2.4 及以上版本内核中，无需额外编译安装，是目前性能最强的开源负载均衡方案之一。

核心术语

表格

术语 全称 核心说明
VS Virtual Server 虚拟服务器，即 LVS 调度器节点
RS Real Server 真实服务器，后端提供业务服务的节点池
VIP Virtual IP 虚拟 IP，集群对外提供服务的 IP 地址
DIP Director IP 调度器 IP，LVS 节点的物理网卡 IP
RIP Real Server IP 真实服务器 IP，后端 RS 节点的物理网卡 IP
CIP Client IP 客户端 IP，访问服务的用户终端 IP
三大核心工作模式

LVS 的核心差异在于数据包的转发方式，生产环境主流为DR 模式，NAT 模式适用于小规模场景，TUN 模式适用于跨机房部署。

表格

模式 核心原理 核心优缺点 网络要求
NAT 模式（网络地址转换） LVS 作为请求入口和响应出口，对请求包做 DNAT（将 VIP 转为 RIP），对响应包做 SNAT（将 RIP 转为 VIP），所有流量均经过 LVS 优点：配置简单，支持端口映射，RS 无需特殊配置；缺点：LVS 易成为性能瓶颈，入站出站流量都经过调度器 LVS 与 RS 必须在同一内网，RS 的网关必须指向 LVS 的 DIP
DR 模式（直接路由） LVS 仅修改请求包的目标 MAC 地址为选中 RS 的 MAC 地址（IP 头不变），二层转发给 RS；RS 处理完成后，直接将响应包发送给客户端，不经过 LVS 优点：性能最优（仅修改 MAC 地址，内核态无额外开销），可支撑 10Gbps 以上吞吐量，生产环境首选；缺点：需配置 ARP 抑制，不支持端口映射 LVS 与 RS 必须在同一二层网络（同一交换机 / VLAN），禁止二层隔离
TUN 模式（IP 隧道） LVS 将请求包封装在新的 IP 隧道包中，转发给跨网段的 RS；RS 解封装后处理请求，直接将响应包返回客户端 优点：支持跨机房、跨网段部署，响应包不经过 LVS；缺点：RS 需支持 IP 隧道协议，配置复杂，有隧道封装开销 LVS 与 RS 可跨网段，RS 必须配置 VIP，支持 IPIP 隧道
常用调度算法

LVS 调度算法分为静态调度 和动态调度两大类，可根据业务场景灵活选择：

  • 静态调度算法（不考虑 RS 实时负载）

    1. 轮询（RR）：依次将请求均匀分发给所有 RS，适用于 RS 性能一致的静态资源场景
    2. 加权轮询（WRR）：根据 RS 权重分配请求，权重越高，分配的请求越多，适配 RS 性能不均的场景
    3. 源地址哈希（SH）：对客户端 IP 做哈希计算，固定分配给同一台 RS，实现会话保持
    4. 目标地址哈希（DH）：对目标 IP 做哈希计算，多用于缓存集群、代理服务场景

  • 动态调度算法（结合 RS 实时负载状态）

    1. 加权最小连接数（WLC）：LVS 默认算法，结合权重与活跃连接数，优先分配给权重高、连接数少的 RS，适配 API、动态 Web 等场景
    2. 最小连接数（LC）：将请求分配给当前活跃连接数最少的 RS
    3. 最短预期延迟（SED）：基于 WLC 优化，计算请求预期延迟，优先分配给延迟最低的 RS
    4. 永不排队（NQ）：有空闲 RS 直接分配请求，无空闲再执行 SED 逻辑，避免请求排队

1.2 Keepalived

Keepalived 是专为 LVS 设计的高可用管理组件，基于 VRRP 协议实现，核心解决 LVS 调度器的单点故障问题，同时内置 LVS 规则管理、RS 节点健康检查能力，与 LVS 完美适配，是 LVS 集群的标配高可用方案。

VRRP 协议核心原理

VRRP（Virtual Router Redundancy Protocol，虚拟路由冗余协议）是用于解决静态路由单点故障的容错协议，RFC2338 标准定义，是 Keepalived 实现高可用的核心基础Keepalived。

  1. 核心角色 ：同一 VRRP 备份组内分为MASTER（主节点）和BACKUP（备节点），同一时间只有一台 MASTER 对外提供服务，持有 VIP
  2. 选举机制：基于优先级（priority）选举，优先级范围 0-255，数值越高优先级越高；优先级相同时，IP 地址更大的节点当选
  3. 心跳机制 ：MASTER 默认每秒向组播地址224.0.0.18发送 VRRP 通告报文（协议号 112），宣告自身存活；BACKUP 节点持续监听该报文
  4. 故障切换：BACKUP 节点在 3 个通告周期内未收到 MASTER 的报文，即判定 MASTER 故障，优先级最高的 BACKUP 会立即升级为新的 MASTER，发送免费 ARP 报文更新网络 MAC 地址，完成 VIP 漂移，整个过程秒级完成，业务无感知
核心功能模块
  1. VRRP 协议栈：处理 VRRP 状态机、节点选举、心跳通告、VIP 漂移，实现调度器节点的故障自动切换
  2. 健康检查模块 ：独立多线程实现，支持多种检查方式，故障时自动调整集群拓扑Keepalived：
    • TCP_CHECK：四层 TCP 端口检查，非阻塞式 TCP 连接探测，适配绝大多数 TCP 业务
    • HTTP_GET/SSL_GET：七层 HTTP/HTTPS 请求检查，可校验响应状态码、内容哈希
    • MISC_CHECK：自定义脚本检查，支持复杂业务的健康检测逻辑
    • 检测结果处理：RS 故障时自动从 IPVS 转发规则中剔除，恢复后自动加回；LVS 主节点业务故障时，自动降低优先级触发主备切换
  3. LVS 集群管理：内置 IPVS 管理能力，可直接通过配置文件定义 LVS 转发规则，无需手动执行 ipvsadm 命令，自动同步主备节点的 LVS 配置
  4. 告警通知模块：支持 SMTP 邮件告警，节点状态变化、故障切换时可实时通知运维人员

二、LVS+Keepalived 集群整体架构与工作流程

2.1 典型集群架构（主备模式）

生产环境最常用的是双节点主备架构，架构组成如下：

plaintext

复制代码 
客户端 → 交换机 → [VIP: LVS-MASTER / LVS-BACKUP] → 交换机 → 后端RS节点池（Web/API/数据库等）
  • LVS-MASTER：主调度器节点，优先级更高，持有 VIP，负责客户端请求的接收与分发，发送 VRRP 心跳报文，管理 IPVS 转发规则
  • LVS-BACKUP：备调度器节点，优先级低于主节点，持续监听主节点心跳，主节点故障时立即接管 VIP，成为新的主节点
  • 后端 RS 节点池：多台提供实际业务服务的服务器，共同承载业务流量，节点可水平扩展
  • 共享存储（可选）：如 NFS、分布式存储，用于保障 RS 节点之间的业务数据一致性（如 Web 静态资源）

2.2 完整请求转发流程（DR 模式，生产环境首选）

以最常用的 DR 模式为例，完整的客户端请求 - 响应流程如下：

  1. 客户端发送请求到集群 VIP，源 IP 为 CIP，目标 IP 为 VIP
  2. 请求报文到达 LVS-MASTER 节点，LVS 核对请求的 VIP / 端口与 IPVS 规则匹配，根据调度算法选中一台健康的 RS 节点
  3. LVS 不修改 IP 报文头，仅将数据帧的目标 MAC 地址修改为选中 RS 的 MAC 地址，通过二层交换机转发给 RS 节点
  4. RS 节点收到数据帧，核对目标 MAC 是自身网卡 MAC，目标 IP 是 VIP（RS 已在 lo 接口绑定 VIP），正常接收并处理请求
  5. RS 节点处理完成后，将响应报文直接通过本机网关发送给客户端，源 IP 为 VIP，目标 IP 为 CIP，响应报文不经过 LVS 调度器

2.3 故障自动切换流程

场景 1：LVS 主节点故障
  1. LVS-MASTER 节点宕机 / 业务故障，停止发送 VRRP 通告报文
  2. LVS-BACKUP 节点在超时时间内未收到心跳报文，判定主节点故障
  3. 优先级最高的 BACKUP 节点立即升级为 MASTER，发送免费 ARP 报文，接管 VIP 和 IPVS 转发规则
  4. 客户端请求自动转发到新的 MASTER 节点，整个过程秒级完成，业务无感知
  5. 原主节点恢复后，根据抢占模式配置，可自动切回主角色，或保持备节点状态
场景 2：后端 RS 节点故障
  1. Keepalived 的健康检查模块持续探测 RS 节点的服务状态
  2. 当某台 RS 节点服务故障，健康检查连续失败达到阈值
  3. Keepalived 自动将该 RS 节点从 IPVS 转发规则中剔除，后续请求不会再分发到该节点
  4. 该 RS 节点服务恢复后，健康检查连续成功达到阈值，Keepalived 自动将其重新加入 IPVS 转发池，恢复流量分发

三、生产环境部署实战（DR 模式）

3.1 环境规划

表格

节点角色 主机名 物理 IP（DIP/RIP） VIP 操作系统
LVS-MASTER lvs-master 192.168.1.10 192.168.1.100 CentOS 7+/Rocky Linux 8+
LVS-BACKUP lvs-backup 192.168.1.11 192.168.1.100 CentOS 7+/Rocky Linux 8+
RS-01 rs-01 192.168.1.20 192.168.1.100 CentOS 7+/Rocky Linux 8+
RS-02 rs-02 192.168.1.21 192.168.1.100 CentOS 7+/Rocky Linux 8+

四、核心运维与常见问题排查

4.1 脑裂问题

脑裂是指主备节点之间的心跳链路故障，导致主节点仍正常运行，但备节点也接管了 VIP，集群中出现两台 MASTER 节点，同时持有 VIP，造成 IP 冲突、业务异常，是 LVS+Keepalived 集群最核心的风险点。

核心成因
  1. 主备节点之间的防火墙未放行 VRRP 组播报文，心跳报文被拦截
  2. 主备节点之间的二层网络故障，心跳报文无法传输
  3. 主节点服务器负载过高，无法正常发送 VRRP 通告报文
  4. 主备节点的 VRRP 配置不一致（virtual_router_id、auth_pass 等）
预防与解决方案
  1. 放行 VRRP 报文：防火墙配置规则放行源地址为节点物理 IP、目标组播地址224.0.0.18、协议号 112 的报文
  2. 增加多条心跳链路：配置双网卡心跳，避免单链路故障
  3. 配置脑裂检测脚本：备节点检测到自身成为 MASTER 时，主动 ping 主节点，若能 ping 通则判定为脑裂，自动关闭自身 Keepalived 服务
  4. 开启 BFD 双向转发检测：结合 BFD 实现毫秒级故障检测，避免误判
  5. 配置非抢占模式：主节点恢复后，不自动抢占主角色，减少切换次数

4.2 常见故障与解决方案

表格

故障现象 核心原因 解决方案
VIP 无法漂移，备节点不接管 主备 VRRP 配置不一致、心跳报文被拦截、优先级配置错误 核对 virtual_router_id、auth_pass 是否一致；放行 VRRP 组播报文；确保主节点优先级高于备节点
客户端能 ping 通 VIP，但无法访问业务 LVS 转发规则未生成、RS 节点 ARP 配置错误、RS 节点未绑定 VIP 执行 ipvsadm -Ln 查看转发规则；核对 RS 节点的 arp_ignore/arp_announce 参数；确认 RS 节点 lo 接口已绑定 VIP
DR 模式下，请求仅主节点能访问，其他网段无法访问 RS 节点未配置默认网关，或 ARP 参数未生效 确认 RS 节点配置了正确的默认网关；重新执行 sysctl -p 生效 ARP 参数，重启网络服务
RS 健康检查失效，故障节点未被剔除 健康检查端口配置错误、TCP 连接超时时间过短、SELinux 未关闭 核对健康检查的端口与 RS 服务端口一致；调整 connect_timeout 超时时间；确认 SELinux 已关闭
并发性能瓶颈，LVS 节点 CPU 占用过高 调度算法选择不当、内核参数未优化、NAT 模式下流量过大 更换适配业务的调度算法；优化 TCP 内核参数；更换为 DR 模式，避免 LVS 成为流量瓶颈

五、方案优劣势与适用场景

5.1 核心优势

  1. 极致性能：LVS 工作在内核态，仅做数据包转发，无用户态开销，单机可支撑百万级并发、十万级 QPS，转发性能远超 Nginx、HAProxy 等七层负载均衡
  2. 超高稳定性：内核级实现，经过数十年生产环境验证，故障率极低，可 7×24 小时不间断运行
  3. 高可用能力完善：Keepalived 实现秒级故障切换，业务无感知，内置四层 / 七层健康检查，无需额外开发适配
  4. 开源免费：无商业版权成本，社区活跃，可灵活定制，适配各类业务场景
  5. 通用性极强：支持所有基于 TCP/UDP 的应用协议，HTTP、HTTPS、MySQL、Redis、DNS、流媒体等业务均可完美适配
  6. 可扩展性强：后端 RS 节点可水平无限扩展，轻松应对业务流量增长

5.2 局限性

  1. 仅支持四层负载均衡：无法基于应用层内容（URL、域名、Cookie、请求头）做精细化转发和规则控制，七层能力需要配合 Nginx/HAProxy 实现
  2. 网络拓扑限制：DR 模式要求 LVS 与 RS 必须在同一二层网络，跨机房部署受限；TUN 模式可解决，但配置复杂，运维成本高
  3. 会话保持能力有限：仅能通过源地址哈希实现粗粒度会话保持，无法像七层负载一样基于 Cookie 做精细化会话保持，易导致负载不均
  4. UDP 协议支持较弱：对 UDP 协议的健康检查能力有限，复杂 UDP 业务需要自定义脚本实现检测
  5. 不支持 HTTPS 卸载：无法完成 SSL 证书卸载、加解密处理，需要后端 RS 节点或七层负载均衡处理

5.3 典型适用场景

  1. 高并发 Web/API 服务接入层：作为四层流量入口，分发到七层 Nginx/HAProxy 集群，再转发到后端业务服务，是互联网业务最常用的架构
  2. 数据库读写分离场景：对 MySQL、PostgreSQL 等数据库的读库做负载均衡，提升数据库读性能，支撑高并发查询请求
  3. 中间件集群负载：Redis、RocketMQ、Kafka、Dubbo 等中间件集群的接入层负载均衡，保障中间件服务的高可用
  4. UDP 协议业务场景：DNS、流媒体、游戏服、视频会议等 UDP 协议的高并发负载均衡
  5. 核心业务系统高可用：金融、政企、运营商等对稳定性、可靠性要求极高的核心业务系统，保障业务零中断

5.4 与其他负载均衡方案对比

表格

特性 LVS+Keepalived Nginx HAProxy F5 硬件负载均衡
工作层级 四层为主 七层为主，支持四层 四层 + 七层 四层 + 七层
转发性能 极高（内核态） 中（用户态） 高（用户态） 极高（专用硬件）
高可用能力 原生支持（Keepalived） 需配合 Keepalived 需配合 Keepalived 原生双机热备
七层能力 无 极强（URL / 域名 / 正则转发） 强 强
成本 免费开源 免费开源 免费开源 极高（数十万 - 百万级）
运维难度 中等 简单 中等 高（需厂商认证）
适用场景 高并发四层接入、大规模集群 七层转发、中小规模集群 四层 + 七层混合、中大规模集群 金融、政企核心业务，预算充足场景
相关推荐
ego.iblacat11 小时前
lvs 集群部署
开发语言·php·lvs
卤炖阑尾炎14 小时前
LVS+Keepalived 高可用集群实战精讲从原理到上线全流程
网络·lvs
炸炸鱼.14 小时前
LVS+Keepalived 高可用集群部署手册
lvs·keepalived·高可用
kiku181814 小时前
keepalived高可用与负载均衡
后端·github·lvs
白毛大侠15 小时前
LVS 完全入门：从零理解 Linux 虚拟服务器的三种模式
linux·服务器·lvs
洛菡夕15 小时前
LVS+Keepalived高可用群集
运维·服务器·lvs
卢傢蕊15 小时前
LVS+Keepalived 高可用群集
linux·运维·lvs·keepalived
我不听你讲话17 小时前
LVS+Keepalived 高可用集群核心内容总结
lvs
刘晨鑫117 小时前
LVS+Keepalived高可用集群
lvs
热门推荐
012026年4月技术前沿：AI大模型爆发、智能体革命与量子安全新纪元02GitHub 镜像站点03一周AI热点速览（2026.03.31-04.06）：GPT-6曝光、谷歌开源Gemma 4、资本狂飙与模型军备竞赛04GPT-6核心能力解析及与现有主流大模型对比05基于 Docker 部署 Hermes Agent 并接入飞书机器人的完整指南06零成本！Ollama本地部署国产大模型全指南（支持Kimi-K2.5/GLM-5/Qwen，新手秒上手）07免费！不限量！用opencode接入英伟达（NVIDIA）大模型，轻松打造你的 AI 编程助手08从限购到畅通：GLM-5.1 Coding Plan接入攻略09CodeBuddy与WorkBuddy深度对比：腾讯两款AI工具差异及实操指南10AI Weekly | 2026年4月第二周 · GitHub热门项目与AI发展趋势深度解析