深入解析LVS负载均衡核心原理

简介

LVS：Linux Virtual Server，负载调度器，集成在Linux内核中，由章文嵩博士开发

LVS官网：http://www.linuxvirtualserver.org/

工作原理：VS 根据请求报文的目标 IP 和目标协议及端口将请求调度转发到 RS ，调度到哪个 RS 由调度算法决定

LVS相关术语

CIP	客户端IP
VIP	虚拟服务器外网IP
DIP	LVS 负载均衡器（Director）的私网IP
VS	虚拟服务器（LVS），负责调度
RS	真实服务器（Web），提供服务
RIP	真实服务器IP

LVS集群的类型

模式	概述
NAT	修改请求报文的目标IP，多目标IP的DNAT
DR	操纵封装新的MAC地址
Tun	在原请求IP报文之外新加一个IP首部
FullNAT	修改请求报文的源和目标IP

LVS相关信息

程序包	ipvsadm
主程序	/usr/sbin/ipvsadm
规则保存工具	/usr/sbin/ipvsadm-save
规则重载工具	/usr/sbin/ipvsadm-restore
配置文件	/etc/sysconfig/ipvsadm-config
ipvs调度规则文件	/etc/sysconfig/ipvsadm

NAT

简介

本质上是多目标IP的DNAT（基于目标的网络地址转换），通过将请求报文中的目标地址和目标端口修改为某RS的RIP和PORT实现转发

• VS 必须是 Linux 系统，RS可以是任意OS系统
• 支持端口映射，可修改请求报文的目标PORT
• 缺点：请求报文和响应报文都必须经过 VS ，容易成为系统瓶颈（超过 20 台 RS 以上时）

原理

1. 客户端发送访问请求，包含CIP、VIP、访问目标端口80

CIP	VIP	80

2. VS接收到请求后，通过DNAT把请求数据包中的VS的VIP-->某RS的RIP和相应端口9000Port

CIP	VIP-->RIP	80-->9000

3. RS响应请求，发送响应数据包，包含源RIP、目CIP，端口9000

RIP	CIP	9000

4. VS接收到响应数据包后，改变包中的源RIP-->VIP、端口9000-->80

RIP-->VIP	CIP	9000-->80

5. VS将修改过后的数据包发送给客户端

综上，客户请求和服务响应均需要经过VS，所以VS容易阻塞、容易成为瓶颈

实现

主机名	IP	网关	网卡模式
Client	172.25.254.79（CIP）	无	NAT
LVS	172.25.254.100（VIP）	无	NAT
	192.168.0.100（DIP）	无	仅主机
RS1	192.168.0.87（RIP）	192.168.0.100（DIP）	仅主机
RS2	192.168.0.89（RIP）	192.168.0.100（DIP）	仅主机

要点：RIP 和 DIP 需要在同一个 IP 网络，且使用私网地址；RS 的网关指向 DIP；仔细检查网卡模式是否正确

Client

配置IP

LVS

双网卡，一个NAT模式（eth0），一个仅主机模式（eth1）

配置IP

内核路由

调度策略

RS1、RS2

RS1、RS2的网卡均使用仅主机模式

安装 httpd 服务

配置IP

# 关闭防火墙与SELinux
[root@rs1 ~]# systemctl disable --now firewalld
[root@rs1 ~]# sestatus
SELinux status:		enable
[root@rs1 ~]# setenforce 0
[root@rs1 ~]# sestatus
SELinux status:		disabled

测试

排错点

1.有个别主机的防火墙与SELinux未关闭

2.LVS的调度策略配置错误;未开启内核路由功能

3.网卡仅主机模式的主机IP网段配置错误;未将网卡切换到仅主机模式

4.RS的网卡未配置或配置错误

5.RS中未配置 /var/www/html/index.html 文件

DR

简介

DR：Direct Routing，直接路由，LVS默认模式，应用最广泛

原理

源MAC是DIP所在接口的MAC	目标MAC是被挑选出的RS的RIP所在接口的MAC
源IP/PORT不变	目标IP/PORT不变

1. 客户端发送请求到 Director，包括CIP、CIP-MAC 、VIP、VIP-MAC
2. Director 收到后，将CIP-MAC-->DIP-MAC、VIP-MAC-->RIP-MAC，发送给RS

CIP	CIP-MAC-->DIP-MAC	VIP	VIP-MAC-->RIP-MAC

3. RS 响应请求，发送响应数据包，内容为

VIP	RIP（VIP）-MAC	CIP	CIP-MAC

实现

主机名	IP	网关	VIP	网卡模式
Client	172.25.254.79（CIP）	172.25.254.100		NAT
Router	172.25.254.100（eth0）			NAT
	192.168.0.100（eth1）			仅主机
DR-LVS	192.168.0.88（DIP）	192.168.0.100	192.168.0.254/32（lo）	仅主机
RS1	192.168.0.87（RIP）	192.168.0.100	192.168.0.254/32（lo）	仅主机
RS2	192.168.0.89（RIP）	192.168.0.100	192.168.0.254/32（lo）	仅主机

• Director 和 RS 都配置有相同的VIP
• RS 的 RIP 公私网地址都行，但要确保 RIP 与 DIP 在同一IP网络、同一物理网络
• RIP 的网关不能指向 DIP，以确保响应报文不会经由 Director
• 请求报文经过 Director ，但响应报文不经过 Director ，而是由 RS 发到客户端，Director 仅处理入站请求
• 不支持端口映射

解决 VIP 响应问题

DR模式中各主机上均需要配置VIP，解决地址冲突的方式有三种：

1. 在前端网关做静态绑定
2. 在各RS使用arptables
3. 在各RS修改内核参数，来限制 arp 响应和通告的级别

arp_ignore

0：默认值，表示可使用本地任意接口上配置的任意地址进行响应

1：仅当 ARP 请求的目标 IP 地址配置在接收该请求的网络接口上时，才会响应 ARP 请求

arp_announce

0：默认值，把本机所有接口的所有信息向每个接口的网络进行通告

1：尽量避免将接口信息向非直连网络进行通告

2：避免将接口信息向非本网络进行通告

Client

配置IP

Router

双网卡，其中一个是NAT模式（eth0），另一个是仅主机模式（eth1）

配置IP、路由内核

DR-LVS

配置IP

ipvsadm、调度策略

RS1、RS2

配置IP

http、默认发布页

arp_ignore、arp_announce

测试

TUN

简介

不修改请求报文的IP首部，而在原IP报文之外再封装一个IP首部，将报文发往挑选出的目标RS；RS直接响应给客户端

• DIP、VIP、RIP都是公网地址
• RS 的网关 一般不能指向 DIP
• 请求报文要经由Director，但响应不能经由Director
• 不支持端口映射
• RS 的 OS 必须支持隧道功能

原理

1. 客户端发送请求数据包，包括CIP、VIP、Port

CIP	VIP	80

2. 到达调度器后，重新封装添加IP报文头部，包括TUN SRC IP、TUN DST IP、CIP、VIP、Port，并发送到RS

TUN SRC IP（DIP）	TUN DST IP（RIP）	CIP	VIP	80

3. RS收到来自调度器的数据包后做出响应，包括VIP、CIP、Port，通过网络直接回传给Client

Fullnet

简介

通过同时修改请求报文的源IP地址和目标IP地址进行转发

• VIP是公网地址、DIP和RIP是私网地址，且通常不在同一IP网络，因此RIP的网关一般不指向DIP
• RS收到的请求报文源是DIP，只需要响应给DIP，但Director还要将其发往Client
• 请求和响应报文都经由Director
• 支持端口映射

原理

1. 客户端发送请求数据包，包括CIP、VIP
2. 调度器收到后，替换成DIP、RIP
3. RS进行响应，包括RIP、DIP
4. 调度器收到后，替换成VIP、CIP

核心功能：

• 集群服务管理：增、删、改
• 集群服务的RS管理：增、删、改
• 查看

ipvsadm 命令

管理集群服务中的增删改

ipvsadm -A|E -t|u|f service-address:port [-s 调度算法] [-p [timeout]]

选项	功能
-A	添加service-address
-E	修改
-t	TCP服务
-u	UDP服务
-f	Firewall Mask 防火墙标记，是一个数字
-s	指定调度算法，默认是WLC
-p	设置持久连接超时，持久连接

ipvsadm -D -t|u|f service-address	# 删除
ipvsadm -C		# 清空
ipvsadm -R		# 重载
ipvsadm -S [-n]		# 保存
ipvsadm -Ln		# 查看策略

管理集群中的RealServer的增删改

ipvsadm -a|e -t|u|f service-address:port -r realserver-address:port [-g|i|m] [-w weight]

选项	功能
-a	添加RealServer
-e	修改RealServer
-t	TCP服务
-u	UDP服务
-f	防火墙标记
-r	RealServer的地址
-g	直连路由模式
-i	IPIP隧道模式
-m	NAT模式
-w	设定权重

ipvsadm -A -t 192.168.0.254:80 -s rr
ipvsadm -a -t 192.168.0.254:80 -r 192.168.0.87:80 -g
ipvsadm -a -t 192.168.0.254:80 -r 192.168.0.89:80 -g

选项	功能
-C	清空LVS策略
-L	查看LVS策略
-n	不做解析
-Z	清空计数器

# 保存调度策略到文件中 ipvsadm-save > /etc/sysconfig/ipvsadm,重启后内容消失
# IPVS 负载均衡规则配置:/porc/net/ip_vs
# IPVS 当前处理的所有连接:/proc/net/ip_vs_conn
# 发行版保存策略:ipvsadm-save > /etc/sysconfig/ipvsadm.rules	# 文件可能不存在

# 重新加载规则 
ipvsadm -R < /etc/sysconfig/ipvsadm
# 或
ipvsadm --restore < /etc/sysconfig/ipvsadm

LVS调度算法

调度算法类型

根据调度时是否考虑各RS当前负载状态被分为两种：静态调度算法、动态调度算法

静态调度算法：仅根据算法进行调度，而不考虑RS的负载状态

动态调度算法：根据RS的负载状态和调度算法进行调度

静态调度算法

算法将基于DR模式进行演示

RR

Round Robin，轮询

原理：按顺序依次将请求分配给后端服务器，不考虑服务器性能差异

# 假设有 3 台服务器（RS1、RS2、RS3）,请求序列为REQ1, REQ2, REQ3, REQ4, REQ5,调度结果：
REQ1 → RS1  
REQ2 → RS2  
REQ3 → RS3  
REQ4 → RS1  
REQ5 → RS2  

适用场景：服务器硬件配置相同的场景

WRR

Weighted Round Robin，加权轮询

原理：根据服务器性能分配权重，权重越高被调度的次数越多

适用场景：服务器硬件配置差异较大的场景（如老服务器和新服务器）

SH

Source Hashing，源 IP 哈希

原理：通过客户端 IP 计算哈希值，将同一 IP 的请求固定分配给同一服务器，实现会话绑定

示例：客户端 IP 为192.168.0.79的所有请求始终被发送到 RS2，即使 RS2 负载很高

缺点：可能导致负载不均衡（如大量客户端来自同一 IP 段）

适用场景：需要会话保持的场景（如购物车、登录状态）

DH

Destination Hashing，目标地址哈希

原理：根据请求的目标 IP 计算哈希值，将同一目标地址的请求固定分配给同一服务器

首次轮询调度至RS，后续将通向同一个目标地址的请求始终转发至首次挑中的 RS

适用场景：正向代理缓存（如 CDN 节点负载均衡），确保同一网站的内容始终由同一节点缓存

动态调度算法

LC

Least Connections，最少连接

原理：优先将请求分配给当前连接数最少的服务器

负载值公式：Overhead = active_conns × 256 + inactive_conns

当前连接数：RS1(active=5, inactive=2), RS2(active=10, inactive=0)，新请求将被分配给 RS1

适用场景：长连接应用（如数据库连接、SSH）

WLC

Weighted LC，加权最少连接

原理：默认调度算法，在 LC 基础上引入权重，负载值除以权重，使高性能服务器承担更多连接

负载值公式 ：Overhead = (active_conns × 256 + inactive_conns) / weight

服务器配置及权重：RS1(weight=2), RS2(weight=1)

当前连接数：RS1(active=10), RS2(active=5)

计算负载值：

RS1 = (10×256)/2 = 1280

RS2 = (5×256)/1 = 1280

两者负载值相同，新请求将按轮询分配

适用场景：默认首选算法，适用于大多数场景

SED

Shortest Expected Delay，最短预期延迟

原理：初始连接时高权重服务器优先，避免低权重服务器长时间空闲

负载值公式：Overhead = (active_conns + 1) × 256 / weight（相比 WLC，加 1 模拟新连接的预期负载）

服务器配置及权重：RS1(weight=1), RS2(weight=10)，当前连接数：RS1(active=0), RS2(active=0)

计算负载值：

RS1 = (0+1)×256/1 = 256

RS2 = (0+1)×256/10 = 25.6

RS2 负载值更小，前几次请求会优先分配给 RS2，直到其连接数增加

适用场景：新连接建立成本较高的场景（如 HTTPS 握手）

NQ

Never Queue，永不排队

原理：第一轮均匀分配请求（避免所有请求集中到高权重服务器），后续采用 SED 算法

示例：初始时，3 台服务器各分配 1 个请求，之后按 SED 计算负载值调度

适用场景：与 SED 类似，但避免了初始连接集中问题

LBLC

Locality-Based LC，基于局部性的最少连接

原理：动态版的 DH 算法，结合 DH 的哈希固定性和 LC 的负载感知

若请求的目标地址已被缓存到某服务器，则优先分配到该服务器；否则分配给负载最轻的服务器

正向代理场景中，访问192.168.0.79的请求原本由 RS1 处理，若 RS1 负载过高，则新请求会被分配给 RS2

适用场景：缓存集群（如 Squid 代理服务器集群）

LBLCR

原理：在 LBLC 基础上，当某服务器负载过高时，将部分请求复制到负载较低的服务器，实现负载均衡

RS1 负载过高，系统会将部分请求（如访问192.168.0.79的请求）同时转发给 RS1 和 RS2，并标记 RS2 为备份；若 RS1 响应超时，则使用 RS2 的响应

适用场景：高可用性要求的缓存集群

内核 4.15 + 新增调度算法

FO

Weighted Fail Over，加权故障转移

原理：优先调度未过载（未标记IP_VS_DEST_F_OVERLOAD）且权重最高的服务器，适用于灰度发布

假设有 3 台服务器：RS1(weight=100)，RS2(weight=50),，RS3(weight=10)

初始时，所有请求由 RS1 处理

当 RS1 被标记为过载后，新请求转向 RS2

RS2 过载后，转向 RS3

灰度发布应用：将新版本部署到 RS3（低权重），观察运行情况，若无问题再逐步提高权重或取消 RS1、RS2 的过载标记

OVF

Overflow-connection，溢出连接

原理：将请求分配给权重最高且活动连接数 < 权重值的服务器，若所有服务器都超过限制，则按权重轮询

服务器配置及权重：RS1(weight=5), RS2(weight=10)

当 RS1 的活动连接数达到 5 时，新请求不再分配给 RS1，转而分配给 RS2

当 RS2 的活动连接数达到 10 时，系统会再次尝试 RS1（按权重轮询）

适用场景：需要严格控制单服务器连接数上限的场景

算法总结

算法	核心逻辑	适用场景
RR	轮流分配	服务器性能相近的短连接服务
WRR	按权重轮流分配	服务器性能差异较大的短连接服务
SH	源 IP 固定分配	需要会话保持的服务（如购物车）
DH	目标 IP 固定分配	正向代理缓存（如 CDN）
LC/WLC	最少连接优先	长连接服务（如数据库、SSH）
SED/NQ	高权重优先 + 避免排队	新连接建立成本高的服务（如 HTTPS）
LBLC/LBLCR	局部性 + 负载感知 + 复制	缓存集群（如 Squid 代理）
FO	权重 + 过载标记	灰度发布、故障转移
OVF	连接数严格限制	需要控制单服务器连接上限的场景

防火墙标签解决轮询错误

以HTTP和HTTPS为例，当在RS中同时开放80和443端口时，默认是分开轮询，这样就出现轮询错误的问题

即客户用HTTP访问轮询到RS1，而使用HTTPS访问时也轮询到RS1

问题复现

mod_ssl

两组不同端口的策略

按照轮询，后台服务器均访问一次

防火墙标记解决轮询调度问题

基于标记定义集群服务

LVS持久链接

进行调度时，不管用什么算法，只要相同源过来的数据包就把他的访问记录在内存中，也就是把源的主机调度到上次的RS中

即在默认时间（360s）内同源再来访问，仍然按照内存中记录的调度信息，把访问请求调度到同一台RS上

当超过默认时间时，同源再来访问，就调度到其他的RS上

# 秒
ipvsadm -E -f 80443 -s rr -p 1800
ipvsadm -LnC