LVS：四层（传输层 TCP/UDP）负载均衡集群解决方案。
ce解决方案：使用火墙标记访问vip的80和443的所有数据包，设定标记为6666，然后对此标记进行负载 1.什么是集群
核心价值：高性能、高可用、高扩展性、负载分摊、故障自动转移
组成角色：客户端、调度器（Director/LVS）、后端真实服务器（RS）
2.集群分类
| 集群类型 | 英文全称 | 核心作用 | 代表技术 |
|---|---|---|---|
| 负载均衡集群 | LB（LoadBalancing） | 将用户流量分发至多台 RS，分摊访问压力 | LVS、Nginx、HAProxy |
| 高可用集群 | HA（High Availability） | 节点故障自动切换，保证服务不中断 | Keepalived、Heartbeat |
| 高性能计算集群 | HPC | 多服务器协同完成密集型计算任务 | 分布式算力、MPI |
LVS 最核心本职工作：充当整个集群的流量调度器，依靠内置调度算法，把客户端的访问流量分发到集群里多台真实业务服务器（RS）处理请求，分摊服务器的工作压力。
3、LVS 的作用
LVS（Linux Virtual Server，Linux 虚拟服务器），由章文嵩博士开发，内置在 Linux 内核IPVS模块，是基于 Linux 内核的四层传输层负载均衡技术，工作在 TCP/IP 四层（传输层），仅基于 IP + 端口做数据包转发。
- 流量分发：海量用户请求均匀分配到多台后端业务服务器，避免单台服务器过载崩溃
- 服务隐藏：对外只暴露虚拟 VIP 地址，后端真实服务器 IP 对内隔离，提升网络安全性
- 高并发支撑：内核态转发，性能极高，单机可承载数十万并发连接，远高于七层 Nginx 概念解释
标识 全称 中文名称 作用说明 VS Virtual Server 调度器（Director） LVS 核心转发节点，接收用户请求，依靠算法分发数据包至后端业务服务器 RS Real Server 真实业务主机 部署 Web、服务接口等实际业务程序，处理客户端真实业务请求 CIP Client IP 客户端 IP 访问服务的用户设备公网 / 局域网 IP，数据包的源地址 VIP Virtual Server IP 虚拟 IP 调度器对外暴露的访问入口 IP，用户只访问该地址，感知不到后端集群 DIP Director IP 调度器内网 IP 调度器面向后端服务器网段的内网网卡 IP，用于和 RS 内网通信转发数据 RIP Real Server IP 后端服务器真实 IP 业务主机在内网中的实际物理 IP，调度器通过 DIP 和 RIP 完成内网数据交互
4、lvs的四种模式及原理
4.1NAT模式
本质是多目标IP的DNAT，通过将请求报文中的目标地址和目标端口修改为某挑出的RS的RIP和 PORT实现转发。
要求：
RIP和DIP应在同一个IP网络，且应使用私网地址;RS的网关要指向DIP
请求报文和响应报文都必须经由Director转发，Director易于成为系统瓶颈
支持端口映射，可修改请求报文的目标PORT
VS必须是Linux系统，RS可以是任意OS系统
通俗来讲就是：调度器修改请求报文的目标 IP（VIP→RIP）、修改响应报文源 IP（RIP→VIP），请求、响应双向流量全部经过 LVS 调度器。
数据通道：客户端 → VIP (LVS) → 修改目的 IP→RS → 回包源 IP 改为 VIP → LVS → 客户端
4.2 DR模式
原理：LVS 仅修改请求报文目标 MAC 地址，IP 报文全程不变；RS 接收请求后，响应数据包直接跨过 LVS 返回客户端，只有入站流量经过调度器。
数据流：客户端→VIP (二层 MAC 改写)→RS→RS 直接回包给客户端，图为数据流传输过程。
4.3TUN模式
LVS 将原始 IP 报文封装在新 IP 报文中，通过 IP 隧道技术跨网段发送给 RS；RS 解封装处理请求后，直接回包给客户端，支持跨机房、跨公网部署后端服务器。
4.4FULLNAT模式
4.5总结：
| 模式 | 流量走向 | 网段要求 | 性能 | 适用场景 |
|---|---|---|---|---|
| NAT | 进出都经过 LVS | 同内网 | 低 | 测试环境、小规模业务 |
| DR | 入站过 LVS，出站直回 | 同二层局域网 | 最高 | 线上大规模 Web 服务（主流） |
| TUN | 入站封装转发，出站直回 | 可跨公网 / 机房 | 中高 | 异地多活集群部署 |
5、lvs的13种算法
5.1 静态算法：
按照预设规则分发流量，不会感知后端服务器实时连接、负载情况。
| 算法 | 全称 | 核心原理 | 使用场景 & 优缺点 |
|---|---|---|---|
| RR | Round Robin 轮询 | 请求依次轮流分配给所有 RS，每台服务器分到请求数量均等 | 优点：配置简单；缺点：服务器硬件配置不一致时会造成负载失衡，仅所有 RS 性能相同时使用 |
| WRR | Weighted RR 加权轮询 | 为每台 RS 设置权重，硬件性能越强权重数值越高，权重越高被调度的请求次数越多 | 最通用静态算法，适配服务器配置参差不齐的集群环境 |
| SH | Source Hashing 源地址哈希 | 对客户端 CIP 做哈希计算，同一个客户端 IP 的所有请求，永远调度到第一次分配的 RS | 原生四层会话保持，实现会话粘连 |
| DH | Destination Hashing 目标地址哈希 | 对用户访问的目标地址哈希计算，同一目标地址请求固定转发至同一 RS | 正向代理、缓存服务器集群（运营商宽带缓存业务） |
5.2 动态调度算法动态算法：
Overhead(负载值)，优先把新请求分配给负载值更小的后端节点，自动感知服务器实时连接压力。1. LC 最少链接调度
- 负载公式：
Overhead = activeconns × 256 + inactiveconns - 逻辑：对比所有 RS 计算出的负载数值，数值最小的节点接收新连接
- 适用：长连接类业务
2. WLC 加权最少链接（LVS 系统默认调度算法）
- 负载公式：
Overhead = (activeconns × 256 + inactiveconns) / weight - 逻辑：在 LC 的基础上除以服务器权重，兼顾实时连接数与服务器硬件性能，综合负载均衡效果最优
3. SED 最短预期延迟
- 负载公式：
Overhead = (activeconns + 1 + inactiveconns) × 256 / weight - 逻辑：新建连接直接计入运算，高权重服务器会优先承接请求；权重差距大时，高权值机器会优先吃掉大量初始流量
4. NQ 永不排队调度
- 逻辑：集群内存在空闲无连接的 RS，直接分配请求给空闲节点；全部服务器都存在连接时，再使用 SED 算法进行调度分配
5. LBLC 基于本地的最少连接（动态 DH）
- 逻辑：结合目标地址哈希 + 动态负载检测，正常情况目标 IP 固定访问一台 RS；当该 RS 负载过高时，自动分流到其他低负载节点
- 场景：正向代理服务集群
6. LBLCR 带复制的 LBLC
- 逻辑：在 LBLC 基础上增加热点数据复制机制，热点流量集中在某台机器时，自动将流量分摊至负载空闲的副本 RS，解决 LBLC 容易局部负载过高的缺陷
5.3 在4.15版本内核以后新增调度算法
1. FO（Weighted Fai Over）加权故障转移调度
- 调度规则：遍历所有 RS 列表，筛选未被标记过载的服务器，优先选择权重最高的节点分发流量
- 过载管控：服务器连接压力过大时，可手动打上
IP_VS_DEST_F_OVERLOAD过载标记，调度器会直接不再向该主机分发新连接 - 典型用途：业务灰度发布、服务故障隔离
2. OVF（Overflow-connection）溢出连接调度
分配规则：优先分发流量给权重最高的可用 RS，直到该服务器活跃连接数打满自身权重阈值，再顺延分配给下一台高权重可用机器 一台 RS 被判定为可用必须同时满足三点：
- 未配置过载标记（无
IP_VS_DEST_F_OVERLOAD） - 当前活跃连接数量 ＜ 自身配置权重值
- 权重数值不为 0
6. LVS 多端口轮询问题及解决方案
出现原因：RR 轮询只根据请求到达次序均分后端节点，没有 “绑定客户端 IP” 的能力； 不同端口创建独立 VS 规则 = 两套独立调度队列，同一用户的一组关联请求被拆到两台主机； 页面、会话、静态资源被物理隔离在两台 RS，网页运行必需的整套数据被拆分，业务必然异常。
举例：
Web 登录原理：用户提交账号密码 → 服务器生成 Session 会话 ID，写入本机内存 / 本地文件，下发给浏览器 Cookie。
我的pc登录提交接口走 443，请求发到 RS2，登录成功，Session 保存在RS2 内存中，登录完成后刷新页面，页面主体 80 流量又分到 RS1，RS1 本机没有本次用户的 Session 数据，识别为未登录状态，页面立刻退回登录页 用户明明输入账号密码登录成功，刷新立马掉线，就是多端口分散到两台 RS 导致会话隔离。
方法：防火墙打标记统一调度
实验环境部署
| 主机 | 网络模式 | 功能 | 是否设定网关 |
|---|---|---|---|
| lvs | nat-172.25.254.100，hostonly-192.168.0.200 | vs | ~ |
| rs1 | hostonly-192.168.0.10 | rs2 | 192.168.0.200 |
| rs2 | hostonly-192.168.0.20 | rs2 | 192.168.0.200 |
mod_ssl 是 Apache (httpd) 的 SSL/TLS 加密模块
- httpd 默认只开放 80 端口（明文 HTTP）
- 安装
mod_ssl之后，httpd 才能加载 ssl 功能，自动监听 443 端口（加密 HTTPS），实现网页加密访问
#在RS1和RS2中开启https
[root@RS1+RS2 ~]# dnf install mod_ssl -y
[root@RS1+RS2 ~]# systemctl restart httpd
[root@RS1+RS2 ~]# systemctl restart httpd
[root@lvs ~]# dnf install ipvsadm -y
6.2 在LVS调度器中添加https的轮询策略
[root@lvs ~]# ^C
[root@lvs ~]# ipvsadm -A -t 192.168.0.200:80 -s rr
[root@lvs ~]# ipvsadm -a -t 192.168.0.200:80 -r 192.168.0.20 -g
[root@lvs ~]# ipvsadm -a -t 192.168.0.200:80 -r 192.168.0.10 -g
[root@lvs ~]# ipvsadm -A -t 192.168.0.200:443 -s rr
[root@lvs ~]# ipvsadm -a -t 192.168.0.200:443 -r 192.168.0.10:443 -g
[root@lvs ~]# ipvsadm -a -t 192.168.0.200:443 -r 192.168.0.20:443 -g
[root@lvs ~]# ipvsadm -Ln
IP Virtual Server version 1.2.1 (size=4096)
Prot LocalAddress:Port Scheduler Flags
-> RemoteAddress:Port Forward Weight ActiveConn InActConn
TCP 192.168.0.20:80 rr
-> 192.168.0.10:80 Route 1 0 0
-> 192.168.0.20:80 Route 1 0 0
TCP 192.168.0.20:443 rr
TCP 192.168.0.200:80 rr
-> 192.168.0.10:80 Route 1 0 0
-> 192.168.0.20:80 Route 1 0 0
TCP 192.168.0.200:443 rr
-> 192.168.0.10:443 Route 1 0 0
-> 192.168.0.20:443 Route 1 0 0
[root@lvs ~]#
这里之前敲错了，删掉多余数据数据，保证纯净实验环境
[root@lvs ~]# ipvsadm -Ln
IP Virtual Server version 1.2.1 (size=4096)
Prot LocalAddress:Port Scheduler Flags
-> RemoteAddress:Port Forward Weight ActiveConn InActConn
TCP 192.168.0.200:80 rr
-> 192.168.0.10:80 Route 1 0 0
-> 192.168.0.20:80 Route 1 0 0
TCP 192.168.0.200:443 rr
-> 192.168.0.10:443 Route 1 0 0
-> 192.168.0.20:443
设立完成后轮询访问，复现问题
[root@LVS ~]# curl 192.168.0.200;curl -k https://192.168.0.200
RS2 - 192.168.0.20
RS2 - 192.168.0.20
解决方案：使用火墙标记访问vip的80和443的所有数据包，设定标记为6666，然后对此标记进行负载
[root@lvs ~]# iptables -t mangle -A PREROUTING -d 192.168.0.200 -p tcp -m multiport --dports 80,443 -j MARK --set-mark 6666
[root@lvs ~]# ipvsadm -A -f 6666 -s rr
[root@lvs ~]# ipvsadm -a -f 6666 -r 192.168.0.10 -g
[root@lvs ~]# ipvsadm -a -f 6666 -r 192.168.0.20 -g
完成后测试
客户端
[root@client ~]# curl 192.168.0.200;curl -k https://192.168.0.200
RS2 - 192.168.0.20
RS1 - 192.168.0.10
7.Ivs的会话粘滞解决方案
利用持久连接实现会话粘滞
1.设定ipvs调度策略
[root@LVS ~]# ipvsadm -A -f 6666 -s rr -p 1
[root@LVS ~]# ipvsadm -Ln
IP Virtual Server version 1.2.1 (size=4096)
Prot LocalAddress:Port Scheduler Flags
-> RemoteAddress:Port Forward Weight ActiveConn InActConn
FWM 6666 rr persistent 1
-> 192.168.0.10:0 Route 1 0 0
-> 192.168.0.20:0
测试
[root@client ~]# curl 192.168.0.200
RS1 - 192.168.0.10
[root@client ~]# curl 192.168.0.200
RS1 - 192.168.0.10
北京人形旗下天工造物具身智能开源社区，聚焦具身天工与慧思开物两大平台
更多推荐
19
0- 0
已为社区贡献2条内容
所有评论(0)