LVS深度解析：从原理到实战的负载均衡完全指南

原创

已于 2025-10-05 22:01:22 修改 · 1.1k 阅读

25 ·

CC 4.0 BY-SA版权

文章标签：

#lvs #负载均衡

于 2025-10-05 22:00:30 首次发布

1.LVS基础：核心概念与工作机制

LVS 的全称是 Linux Virtual Server，即 Linux 虚拟服务器。它是一个由章文嵩博士发起和领导的优秀开源项目，现在已经是 Linux 内核标准的一部分。

核心目标：使用负载均衡技术将多台真实的服务器（Real Server）构成一个高性能、高可用的虚拟服务器。客户端访问这个虚拟的 IP 地址（VIP），由 LVS 将请求透明地转发到后端的真实服务器上，从而扩展网络设备和服务的吞吐量、提高应用的处理能力，并保护后端服务器不被直接暴露在公网上。

如果把互联网服务比作一家热门餐厅，客户端就是上门的顾客，后端服务器就是厨房里的厨师，而 LVS（Linux 虚拟服务器）就是那个站在门口的 “智能调度员”。它的核心活儿很简单：不让顾客都挤在一个厨师面前，而是把订单均匀分到各个厨师手里，既能让上菜速度变快，也能避免某个厨师累垮；更重要的是，顾客从头到尾只认 “餐厅大门”（也就是 VIP，虚拟 IP），根本不知道后厨有多少个厨师，这就给后端服务器加了层保护。在这个 “餐厅” 里，除了 LVS 这个调度员，还有几个关键角色：顾客的地址（CIP）、调度员自己的工位（DIP）、厨师们的工位（RIP），少了哪个都没法顺畅运转。

1.1 必知术语：LVS 网络架构中的关键角色与地址标识

VS：Virtual Server ，虚拟服务
Director： Balancer ，也叫DS(Director Server)负载均衡器、分发器
RS：Real Server ，后端请求处理服务器，真实服务器
CIP: Client IP ，客户端IP
VIP：Director Virtual IP ，负载均衡器虚拟IP
DIP：Director IP ，负载均衡器IP
RIP：Real Server IP ，后端请求处理的服务器IP

1.2 底层运行原理：Netfilter 框架与 IPVS 模块的协同工作

LVS 的核心工作依赖于 Netfilter 框架（Linux 内核的数据包过滤框架，iptables 也基于此）和 IPVS 模块。

IPVS 模块：这是 LVS 的核心。它工作在内核态，实现了高效的负载均衡功能。当内核编译了 IPVS 模块后，它会在 Netfilter 的 INPUT 链上挂载一个钩子函数。
Netfilter工作机制：

Netfilter中有五个内置链（chain）对应内核中的五个勾子函数。

（1）当一个数据包进入网卡时，数据包首先进入PREROUTING链，内核根据数据包目的IP判断是否需要传送出去；

（2）如果数据包是进入本机的，则会进入INPUT链，然后交由本机的应用程序处理；

（3）如果数据包是要转发的，且内核允许转发，则数据包在PREROUTING链之后到达FORWARD链，再经由POSTROUTING链输出；

（4）本机的应用程序往外发送数据包，会先进入OUTPUT链，然后到达POSTROUTING链输出。

数据流入：PREROUTING --> INPUT

数据流出：OUTPUT --> POSTROUTING

数据转发：PREROUTING --> FORWARD --> POSTROUTING

LVS 是基于Netfilter框架，主要工作于 INPUT 链上，在 INPUT 上注册 ip_vs_in HOOK 函数，进行 IPVS 主流程，大概原理如图所示:

1.2.1 数据包流转全流程：从客户端请求到后端响应

请求到达：客户端请求 [CIP -> VIP] 到达负载均衡器。
路由判断：内核发现目标是本机VIP，准备送交INPUT链。
IPVS拦截：IPVS模块在INPUT链拦截此包，根据算法选中一台真实服务器(RS)。
**LVS转发请求，RS返回响应。**如下四种模式，四种转发模式的核心差异（DR/NAT/TUN/FULL NAT）

DR模式
- 转发：如果DR模式下，只修改目标MAC为RS的MAC地址，然后将包从OUTPUT链送出。
- RS接收：RS看到MAC是自己，且VIP也在本地，于是处理请求。
- 直接响应：RS将响应包 [VIP -> CIP] 直接发回客户端，不经过负载均衡器。
NAT 模式
- 转发请求：LVS 直接修改请求包的目标IP，从 VIP 改为选中的 RS 的 IP。
- 返回响应：RS 将响应包发回给 LVS，LVS 再修改响应包的源IP，从 RS 的 IP 改回 VIP，然后发给客户端。
- 简记：LVS 是“中介”，请求和响应都要经过它，它要做两次地址转换。性能瓶颈。
TUN 模式
- 转发请求：LVS 将整个客户端请求包再套一层IP头（封装隧道），新包的目标IP是 RS 的 IP。RS 收到后拆掉外层IP头，看到原始的 [CIP -> VIP] 请求。
- 返回响应：RS 直接拿着原始请求包里的 VIP 和 CIP 信息，直接将响应发回给客户端。
- 简记：LVS 是“快递打包站”，RS 是“拆包点”。请求需要封装，响应直接返回。可以跨网络。
FULL NAT 模式
- 转发请求：LVS 同时修改请求包的源IP和目标IP。源IP从 CIP 改为 LVS 的内网IP，目标IP从 VIP 改为 RS 的 IP。
- 返回响应：RS 将响应包发回给 LVS，LVS 再同时修改响应包的源IP和目标IP。源IP从 RS 的 IP 改回 VIP，目标IP从 LVS 的内网IP 改回 CIP。
- 简记：NAT模式的升级版。进出都经过LVS并做两次地址转换，但解决了LVS和RS必须在同一网段的问题。RS看不到真实客户IP。

所以，如果不是 DR 模式，LVS 就不会只改MAC地址那么简单，它要么改IP地址（NAT），要么封装IP包（TUN）

1.3 四大工作模式深度解析：原理、流程与适用场景

以上简单提到了LVS的四种工作模式，接下来详细的介绍一下这四种模式

1.3.1 NAT 模式：基于地址转换的 “中介式” 转发

核心原理：通过网络地址转换，调度器重写请求和响应数据包的地址。
数据流：
1. 请求：客户端发送数据包 [CIP -> VIP] 到调度器。
2. 调度器：接收到包后，根据算法选择一台 Real Server（RS），将数据包的目标 IP 改为 RS 的 IP（RIP），端口也可能改变。数据包变为 [CIP -> RIP]。注意，源 IP 仍然是 CIP。
3. RS：收到数据包 [CIP -> RIP]，处理请求。
4. 响应：RS 将响应数据包发回，由于源 IP 是 CIP，所以 RS 会直接将响应包发回给调度器（因为 RS 的网关必须指向调度器）。响应包为 [RIP -> CIP]。
5. 调度器：收到 RS 的响应包后，将源 IP 地址从 RIP 改回 VIP，数据包变为 [VIP -> CIP]，然后发回给客户端。
NAT 模式特点：
- RIP和DIP 应在同一个IP网络，且应使用私网地址；
- RS 的网关要指向 DIP；
- 请求报文和响应报文都必须经由 LVS 转发，LVS 易成为系统瓶颈；
- 支持端口映射，可修改请求报文的目标PORT；
- VS 必须是 Linux 系统，RS 可以是任意 OS 系统；
- LVS 主机需要开启 ip_forward 转发。

1.3.2 DR 模式：通过 MAC 改写实现的高性能转发

核心原理：通过改写请求数据包的 MAC 地址，将请求直接转发给 RS，而 RS 处理后直接响应客户端，不再经过调度器。

数据流：

请求：客户端发送数据包 [CIP -> VIP] 到调度器。
调度器：选择一台 RS，不修改目标 IP（仍然是 VIP），而是修改目标 MAC 地址为 RS 的 MAC 地址。然后将数据包在局域网内发送出去。
RS：由于数据包的目标 MAC 是自己的 MAC，所以它会接收这个包。接着，它解开数据包，发现目标 IP（VIP）也配置在自己本机的某个网卡上（通常是 lo:0 接口）。于是，RS 处理这个请求。
响应：RS 处理完毕后，构建响应数据包 [VIP -> CIP]。由于它知道源 IP 是 VIP，目标 IP 是 CIP，并且 CIP 不在本地网络，所以它会通过默认网关直接将该响应包发回给客户端，完全不经过调度器。

DR模式特点：

RS 必须在同一物理局域网内。
需要在所有 RS 上配置 ARP 抑制，让它们不会响应来自网络的对 VIP 的 ARP 请求，否则会导致混乱。通常通过修改内核参数实现。
不支持端口映射
LVS 服务器只处理请求报文，不处理响应报文，相对于 NAT 模式其负载性能会大幅提升，响应由RS 服务器自行完成

1.3.3 TUN 模式：跨网络的 IP 隧道转发方案

核心原理：通过 IP 隧道技术，将客户端的请求包封装在一个新的 IP 包中，发送给 RS，RS 解封装后直接响应客户端。
数据流：
1. 请求：客户端发送 [CIP -> VIP] 到调度器。
2. 调度器：对原始数据包进行 IP 封装，外面再加一个 IP 头，目标 IP 是 RIP，源 IP 是 DIP。数据包变为 [DIP -> RIP]，内部封装着 [CIP -> VIP]。
3. RS：收到这个封装包后，解封装，得到内部的 [CIP -> VIP] 数据包。它发现 VIP 就在自己本地，于是处理请求。
4. 响应：RS 直接构建响应包 [VIP -> CIP]，并通过自己的路由直接发回给客户端。
TUN模式特点：
- RS 可以分布在互联网的任何地方，可以跨越 VLAN。调度器只处理入站请求。
- RS 需要支持 IP 隧道协议，需要安装相应的隧道模块。封装和解封装数据包有额外的 CPU 开销。
- 不支持端口映射
- LVS 服务器只处理请求报文，不处理响应报文，相对于 NAT 模式其负载性能会大幅提升，响应由RS 服务器自行完成；

1.3.4 FULL NAT 模式：突破网段限制的 NAT 增强版

核心原理：NAT 模式的增强版。在 NAT 模式中，调度器只修改目标地址。在 FULL NAT 中，调度器同时修改源地址和目标地址。
数据流：
1. 请求：客户端发送 [CIP -> VIP] 到调度器。
2. 调度器：将源 IP 从 CIP 改为 DIP（调度器自己的内网 IP），将目标 IP 从 VIP 改为 RIP。数据包变为 [DIP -> RIP]。
3. RS：收到 [DIP -> RIP]，处理请求。
4. 响应：RS 发送响应 [RIP -> DIP] 给调度器。
5. 调度器：将响应包的源 IP 从 RIP 改回 VIP，目标 IP 从 DIP 改回 CIP，变为 [VIP -> CIP] 发回客户端。
FULL NAT模式特点：
- 解决了 NAT 模式下 RS 和调度器必须在同一 VLAN，且 RS 网关必须指向调度器的问题。在 FULL NAT 下，调度器和 RS 可以跨越 VLAN，RS 的网关也不需要指向调度器。极大提升了部署灵活性。
- RS 看不到真实的客户端 IP（CIP），因为源 IP 被改成了 DIP。需要通过 TOA 等内核模块从 TCP 选项中将真实 IP 带给 RS。
- 支持端口映射
- LVS 主机需要开启 ip_forward 转发。

1.3.5 四种模式核心特性对比表

特性	NAT	DR	TUN	FULL NAT
RS 操作系统	任意	任意	需支持隧道	任意
RS 网络	私有网络	同一局域网	可跨地域	可跨 VLAN
RS 网关	必须指向 DIP	不能指向 DIP	不能指向 DIP	可指向任意
性能	低（瓶颈在调度器）	非常高	高（有封装开销）	中
CIP 可见性	可见	可见	可见	不可见（需 TOA）
部署复杂度	简单	中等（需配置ARP抑制）	复杂（需隧道支持）	中等
端口映射	支持	不支持	不支持	支持
LVS主机是否开启ip_forward转发	是	否	是	否

NAT 与 FULL NAT：请求报文和响应报文都经由 LVS，NAT 模式下的 RIP 网关要指向 DIP，FULL NAT 模式下无此要求；

DR 与 TUN：请求报文经由 LVS，响应报文由 RS 自行转发；DR 模式通过修改 MAC 首部实现，通过 MAC 网络转发； TUN 模式通过在原 IP 报文之外封装新的 IP 首部实现转发，支持跨公网通信。

生产环境推荐：DR 模式 因其极高的性能而被广泛使用。当网络拓扑受限时，FULL NAT 是一个很好的备选