LVS 原理详解

发布于：2025-07-21 ⋅ 阅读:(18) ⋅ 点赞:(0)

一、LVS 原理

1.1.什么是 LVS

LVS（Linux Virtual Server，Linux 虚拟服务器）是集成于 Linux 内核的高性能负载均衡技术，由我国科学家章文嵩博士于 1998 年主导开发，其核心模块（IPVS）直接内置于 Linux 内核中，属于内核级别的负载均衡解决方案。

与 Nginx、HAProxy 等运行在用户态的负载均衡工具不同，LVS 工作在操作系统最底层的内核空间，通过直接操纵网络数据包转发逻辑，实现对大规模并发请求的高效分发。它并非独立的软件，而是 Linux 系统原生支持的功能模块，只需通过 ipvsadm 工具配置即可启用，因此具有极高的稳定性和兼容性。

1.2.LVS 的核心作用

  • 负载均衡：避免单点过载

LVS 的核心功能是作为 “前端调度器（Director）”，接收来自客户端的所有请求，再根据预设的调度算法（如轮询、加权轮询、最小连接等），将请求 “均匀” 分发到后端的多台服务器（Real Server，真实服务器）。

  • 高可用：保障服务不中断

结合外部健康检测工具（如 Keepalived），LVS 可实现服务的高可用。当后端某台服务器（如 Real Server 3）因故障（宕机、网络中断、服务崩溃）无法响应时，健康检测工具会立即将其从 “可用服务器池” 中剔除，LVS 调度器会自动将后续请求转发给其他正常服务器。待故障服务器修复后，又会被重新加入服务器池，整个过程无需人工干预，确保服务持续可用。

  • 注意：LVS 本身没有高可用功能。

1.3.LVS 三大核心组件

  • 负载均衡器（Director）：

整个集群的 “入口网关”，负责接收所有客户端请求（通过虚拟 IP 暴露服务），并根据调度算法将请求转发到后端服务器。 Director 是 LVS 的核心控制节点，需配置两块网卡（或单网卡绑定多 IP）：一块用于接收客户端请求（绑定 VIP），另一块用于与后端服务器通信（绑定 DIP，即 Director IP）。

  • 服务器池（Real Server，RS）：

实际提供服务的后端服务器集群（如 Web 服务器、数据库服务器），接收 Director 转发的请求并处理。所有 RS 需配置 RIP（Real IP），且能与 Director 通信（通常处于同一局域网）。RS 对客户端透明，客户端仅感知 VIP 的存在，不知道具体 RS 的 IP。

  • 虚拟 IP（VIP，Virtual IP）：

对外暴露的 “服务 IP”，是客户端访问集群的唯一入口（如 10.0.0.100）。 VIP 绑定在 Director 上，所有 RS 需通过一定配置（如 ARP 抑制）确保客户端请求只会被 Director 接收，避免 IP 冲突。

  • LVS 相关术语

VIP（Virtual IP）：客户端访问 LVS 集群的入口 IP，对外暴露服务。
RIP（Real Server IP）：后端真实服务器的 IP，用于处理 LVS 转发的请求。
DIP（Director IP）：负载均衡器（Director）与后端服务器通信的 IP。
CIP（Client IP）：发起请求的客户端设备的 IP 地址。
Director（负载均衡器）：LVS 集群的核心调度节点，接收请求并转发给后端。
Real Server（RS）：后端实际提供服务的服务器集群。
IPVS：Linux 内核中的模块，LVS 的核心转发引擎。
ipvsadm：管理 IPVS 的用户态工具，用于配置 LVS 规则。

1.4.LVS 的优势

1.高性能

LVS 工作在 TCP/IP 协议栈的四层（传输层），直接在内核中完成请求转发，无需经过用户态与内核态之间的数据拷贝（这是用户态工具的性能瓶颈）。因此，其转发效率接近硬件负载均衡器，能以极低的资源消耗处理海量请求。

2.高并发

由于内核级优化，LVS 可支持百万级并发连接（如每秒处理 100 万以上的新连接），远超 Nginx（十万级）、HAProxy（数十万级）等工具，是高流量场景的核心支撑技术。

3.开源免费

作为 Linux 内核的一部分，LVS 完全开源，无需支付任何 licensing 费用，且可自由定制修改。相比昂贵的硬件负载均衡器（如 F5），LVS 能以极低的成本构建企业级负载均衡集群，大幅降低架构成本。

4.灵活的网络模式

支持 NAT（网络地址转换）、DR（直接路由，性能最优）、TUN（隧道）、FullNet 模式四种网络模式，可适应不同的网络拓扑（如局域网、跨机房部署），满足复杂场景需求。

1.5.适用场景

LVS 凭借其高性能、高并发特性，广泛应用于以下场景：

1.大型门户网站 / 电商平台：如淘宝、京东等，需应对海量用户访问，LVS 作为第一层负载均衡，将请求分发到下层的 Nginx 或应用服务器。

2.高流量 API 服务：如支付接口、短视频接口等，需处理每秒数万至数十万的 API 调用，LVS 可确保请求均匀分配，避免接口服务器过载。

3.云服务与 IDC 机房：作为云平台的负载均衡网关（如 OpenStack 中的 LVS 组件），为虚拟机、容器集群提供流量分发能力。

4.金融、电信等核心系统：对稳定性要求极高的场景，LVS 配合 Keepalived 实现主从热备，确保服务零中断。

 

二、LVS 负载均衡工作模式

2.1.NAT 模式

 

2.1.1.NAT 详细传输过程逻辑

  1. 客户端发送请求：

    客户端向 VIP（如 192.168.67.100:80）发起访问，请求数据包包含：

    • 源 IP（CIP）：客户端自身 IP（如 192.168.67.10）

    • 目的 IP（VIP）：LVS 负载均衡器对外暴露的虚拟 IP

    • 目的端口：服务端口（如 80 或 443）

  2. Director 接收请求并做 DNAT

    LVS 调度器（Director）接收请求后，执行 目的地址转换（DNAT）：

    • 将目的 IP 从 VIP 改为 RS 的 RIP（如 192.168.13.100）

    • 可能修改目的端口（如将客户端请求的 80 映射到 RS 的 8080）

    • 源 IP 保持为 CIP 不变

    • 转发修改后的数据包至 RS

  3. RS 处理请求并响应

    RS 接收数据包（源 IP 为 CIP，目的 IP 为 RIP），处理请求后生成响应数据包：

    • 源 IP：RS 自身的 RIP（如 192.168.13.10）

    • 目的 IP：客户端的 CIP

    • 源端口：服务端口（如 80）

    • 目的端口：客户端随机端口（如 8080）

  4. Director 接收响应并做 SNAT

    响应数据包返回至 Director，Director 执行源地址转换（SNAT）：

    • 将源 IP 从 RIP 改为 VIP

    • 可能修改源端口（与步骤 2 对应）

    • 转发修改后的数据包至客户端

  5. 客户端接收响应

    客户端收到的响应数据包中，源 IP 为 VIP，与请求时一致，感知不到后端 RS 的存在。

 

2.1.2.NAT 模式特点

1.优点：

  • 配置简单：RS 无需特殊配置，只需能访问 Director 的 DIP 即可。

  • 网络隔离：RS 可使用私有 IP，无需暴露在公网，安全性高。

  • 支持端口映射：可将客户端请求的端口（如 80）映射到 RS 的其他端口（如 8080）。

2.缺点：

  • 性能瓶颈：所有请求和响应都需经过 Director，Director 易成为流量瓶颈。

  • 依赖 Director：RS 必须通过 Director 与客户端通信，无法直接响应。

  • 扩展性有限：Director 的处理能力限制了集群规模，通常适用于中小规模部署。

 

2.1.3.NAT 适用场景

  1. 小规模集群：当后端 RS 数量较少（如 < 10 台），且流量不大时。

  2. RS 无公网 IP：RS 部署在私有网络，需通过 Director 进行地址转换。

  3. 测试 / 开发环境：配置简单，便于快速搭建负载均衡架构。

  4. 端口映射需求：需要将不同端口的请求分发到同一 RS 的不同服务时（如 80→8080，443→8443）。

2.2.DR 模式

 

2.2.1.DR 详细传输过程逻辑

1. 客户端发送访问请求

客户端向 VIP（如 10.0.0.100:80）发起请求，数据帧包含：

  • 源 IP（CIP）：客户端自身 IP（如 113.57.xxx.xxx）

  • 源 MAC：客户端网卡的 MAC 地址（如 aa:bb:cc:dd:ee:ff）

  • 目的 IP（VIP）：LVS 集群的虚拟服务 IP（绑定在 Director 的 dummy 虚拟网卡 lvstest 上）

  • 目的 MAC：Director 的 lvstest 网卡的 MAC 地址（如 ff:ee:dd:cc:bb:aa，由系统自动分配）

  • 目的端口：服务端口（如 80）

  • 关键点：Director 通过 nmcli 创建的 dummy 网卡 lvstest 作为 VIP 的载体，其 MAC 地址独立于物理网卡。客户端通过 ARP 解析 VIP 对应的 MAC 时，获取的是 lvstest 的 MAC。

2. Director 调度器转发请求

Director 接收请求后，执行以下操作：

  • 修改目的 MAC：将目的 MAC 从 lvstest 的 MAC（ff:ee:dd:cc:bb:aa）改为目标 RS 的 dummy 网卡 rs-vip 的 MAC 地址（如 11:22:33:44:55:66）

  • 修改源 MAC：将源 MAC 从客户端的 MAC（aa:bb:cc:dd:ee:ff）改为DIP 所在物理网卡的 MAC（如 22:33:44:55:66:77，即 Director 连 RS 的 eth1 网卡 MAC）

  • IP 层保持不变：源 IP（CIP）、目的 IP（VIP）、端口均不修改

  • 关键点：Director 通过物理网卡 eth1（绑定 DIP）转发数据包，根据链路层规则，源 MAC 必须是发送接口（eth1）的 MAC，与 dummy 网卡 lvstest 无关。

3. RS 处理请求并直接响应客户端

RS 接收数据包（因 RS 的 dummy 网卡 rs-vip 绑定了 VIP，能识别目的 IP 为 VIP 的请求），处理后生成响应：

  • 源 IP：保持为 VIP（确保客户端感知不到 RS 存在）

  • 源 MAC：RS 的 rs-vip 网卡的 MAC 地址（11:22:33:44:55:66）

  • 目的 IP：客户端 IP（CIP）

  • 目的 MAC：客户端的 MAC 地址（aa:bb:cc:dd:ee:ff）

  • 响应数据包直接通过 RS 的物理网卡（如 eth0）发送给客户端，不经过 Director

  • 关键点：RS 的 rs-vip 虚拟网卡仅用于接收 VIP 流量，响应时通过物理网卡（如 eth0）发送，其源 MAC 为 rs-vip 的 MAC，确保客户端能通过 ARP 解析到正确的 MAC。

4. 客户端接收响应

客户端收到响应，源 IP 为 VIP（与请求时一致），源 MAC 为 RS 的 rs-vip 网卡的 MAC（但客户端仅关注 IP 层，不感知 MAC 变化），认为是从 “虚拟服务” 直接返回的结果，完成一次通信。

为什么使用 dummy 网卡？

dummy 网卡相比 lo 回环网卡，在ARP 冲突控制、路由适配、独立性三个核心维度更适合作为 VIP 的载体，能简化配置并降低冲突风险。而 lo 接口的设计初衷是本地通信，其特性与 DR 模式中 VIP 需要跨网络通信、严格控制 ARP 的需求天然冲突，因此实际场景中几乎都选择 dummy 网卡（或其他专用虚拟网卡，如 tun/tap）承载 VIP。

 

2.2.2.DR 模式特点

  1. 数据转发基于二层 MAC 地址修改

    Director（负载均衡器）仅修改请求数据包的目的 MAC 地址（从自身与后端通信的网卡 MAC 改为目标后端服务器的 MAC），不修改源 IP、目的 IP（VIP）和端口。这种转发方式几乎不消耗 Director 的计算资源，效率极高。

  2. 响应不经过 Director，降低瓶颈

    后端服务器（RS）处理请求后，直接向客户端返回响应（源 IP 为 VIP，目的 IP 为客户端 IP），响应数据包不经过 Director。因此，Director 仅承担 “请求转发” 角色，不会成为流量瓶颈，支持更高并发。

  3. 网络层限制：需同一广播域

    Director 与后端服务器（RS）必须处于同一局域网（同一广播域），因为 MAC 地址转发依赖二层网络通信（无法跨网段路由）。

  4. 后端服务器需特殊配置

    所有 RS 必须在本地绑定 VIP（通常通过虚拟 dummy 网卡，而非物理网卡或 lo 回环），否则无法接收目标为 VIP 的数据包。

    需配置 ARP 抑制（如关闭 VIP 的 ARP 响应、抑制 ARP 广播），避免 RS 因绑定 VIP 而对外宣告 ARP，导致客户端直接向 RS 发送请求（绕过 Director）。

  5. 不支持端口映射

    由于 Director 不修改 IP 和端口，后端服务器的服务端口必须与 VIP 暴露的端口一致（如 VIP:80 对应 RS:80），无法像 NAT 模式那样做端口转换。

  6. 扩展性强

    因 Director 负载极低，可轻松扩展后端服务器数量（理论上支持数百甚至上千节点），适合大规模集群。

 

2.2.3.DR 适用场景

  1. 高并发、大流量的 TCP/UDP 服务

    如 Web 服务器（HTTP/HTTPS）、静态资源服务、视频点播 / 直播的前端负载均衡等。这类服务请求量巨大，DR 模式的低延迟、高吞吐量特性可显著提升整体性能。

  2. 同一局域网内的服务部署

    由于依赖二层 MAC 通信，Director 与 RS 必须在同一网段（如机房内部集群），适合数据中心内部的负载均衡场景。

  3. 追求极致性能，降低 Director 负载

    相比 NAT 模式（响应需经 Director）或 TUN 模式（封装 IP 隧道，开销较高），DR 模式性能最优，适合对延迟敏感的服务（如金融交易、实时通信）。

  4. 后端服务器可水平扩展的场景

    当业务需要通过增加后端节点提升容量时，DR 模式对 Director 的低依赖使其能轻松支持大规模扩展，无需频繁升级 Director 硬件。

2.3.TUN 模式

 

2.3.1.TUN 详细传输过程逻辑

  1. 客户端发送请求：发送数据包，包内有源 IP+vip+dport

  2. VS 调度器转发流量：到达 VS 调度器后对客户端发送过来的数据包重新封装添加 IP 报文头，新添加的 IP 报文头中包含TUNSRCIP（DIP）+TUNDESTIP（RSIP1) 并发送到 RS1

  3. RS 回应：RS 收到 VS 调度器发送过来的数据包做出响应，生成的响应报文中包含 SRCIP（VIP）+DSTIP（CIP）+port，响应数据包通过网络直接回传给 client

 

2.3.2.TUN 模式特点

  1. 核心转发逻辑：

    • 仅请求数据包经过 VS 时被隧道封装（添加外层 IP 头），响应数据包由 RS 直接回传客户端，VS 不参与响应转发，避免成为瓶颈。

    • 依赖 IP 隧道协议（如 GRE）实现跨网段通信，原 IP 层（CIP→VIP）始终不变，确保 RS 能识别请求。

  2. 优势：

    • 突破局域网限制：VS 与 RS 可不在同一网段（支持跨机房、跨地域部署），解决 DR 模式 “必须同一广播域” 的痛点。

    • 性能较高：响应不经过 VS，仅请求有封装开销，性能优于 NAT 模式（接近 DR 模式的 70%-80%），支持中大规模集群（数十至数百台 RS）。

    • 灵活性强：可通过隧道隔离 RS 网络，适合多租户场景（如不同 RS 集群分属不同部门，通过隧道与 VS 通信）。

  3. 劣势：

    • 封装开销：隧道封装 / 解封装会消耗一定 CPU 资源（尤其高并发场景），性能略低于 DR 模式。

    • 配置复杂：需在 VS 和 RS 上额外配置隧道协议（如 GRE），并确保隧道两端路由互通；RS 需绑定 VIP 并配置 ARP 抑制（避免 VIP 冲突）。

    • 依赖隧道协议支持：部分老旧设备或系统可能不支持 GRE 等隧道协议，限制部署场景。

 

2.3.3.TUN 适用场景

  1. 跨网段 / 跨机房部署：

    如总部与分部的服务器集群（跨城市局域网），需通过公网或专线通信，TUN 模式可通过隧道将请求从 VS 转发到异地 RS。

  2. 分布式集群 / 云服务：

    云平台中，虚拟机或容器分布在不同私有网络（如 AWS 的 VPC、阿里云的专有网络），TUN 模式可跨网络边界分发请求。

  3. 大规模地理分布式服务：

    如跨地域的 CDN 节点、短视频的边缘计算节点，需将用户请求就近转发到不同地区的 RS，TUN 模式支持跨广域网的负载均衡。

  4. 需隔离 RS 网络的场景：

    当 RS 部署在安全隔离区（如金融系统的核心数据库集群），仅允许通过隧道与外界通信时，TUN 模式可在保证隔离的同时实现负载均衡。

 

2.4.FullNet 模式

 

2.4.1.FullNet 详细传输过程逻辑

  1. 客户端对 VIP 发起请求。

  2. Director 接过请求，发现是请求后端集群服务。

  3. Director 对请求报文做 FULL NAT，把源 IP 改为 DIP，把目标 IP 转换为任意以后后端 RS 的 RIP，然后法网后端。

  4. RS 接收到请求后，进行响应，相应报文源 IP 为 RIP，目标 IP 还是 DIP，又内部路由路由到 Director。

  5. Director 接收相应报文后，进行 FULL NAT，把源地址改为 VIP，目标地址改为 CIP。

 

2.4.2.FullNet 模式特点

  1. 双向 NAT 解耦网络：请求 / 响应均做 IP 转换，RS 无需配置网关指向 Director，部署更灵活。

  2. 跨网自由部署：RS 可分布在任意路由可达的网络（跨机房、跨云平台），无需同网段。

  3. 隐藏 RS 真实 IP：客户端 / 外部网络无法直接访问 RS 的 RIP，增强后端安全性。

  4. 性能适中：优于普通 NAT（无响应瓶颈），略低于 DR 模式，支持中大规模集群。

 

2.4.3.FullNet 适用场景

  1. 跨数据中心 / 混合云：多地域机房、公有云 + 私有云混合部署，统一通过 Director 接入。

  2. 高安全隔离：金融、政务等敏感业务，RS 部署在内网隔离区，仅暴露 VIP 对外服务。

  3. 替代普通 NAT：解决普通 NAT 的 “RS 网关必须指向 Director” 限制，支持更灵活的 RS 扩展。

2.5.模式总结

模式 核心逻辑 网络修改 响应路径 网络要求 性能 适用场景
NAT Director作网关，双向改IP 源IP（CIP→DIP）、目的IP（VIP→RIP） 经Director RS网关指向Director，同网段 低 小规模集群、低成本
DR 修改MAC，IP层不变 仅改目的MAC 直连客户端 同广播域（二层可达） 极高 高并发Web、局域网大规模集群
TUN 隧道封装，跨网段转发 外层IP（DIP→RIP），内层不变 直连客户端 跨网段，RS支持隧道协议 中高 跨地域集群、分布式系统
FULLNAT 双向NAT，解耦RS网络 源IP（CIP→DIP）、目的IP（VIP→RIP） 经Director RS路由可达即可，无需同网段 中 混合云、高安全隔离场景

 

三、LVS 负载均衡算法

3.1.静态算法（不感知 RS 负载）

  1. RR（轮询） 轮流调度 RS，不考虑性能差异，适合 RS 配置一致的小规模集群，缺点是性能差异大时易导致负载不均。

  2. WRR（加权轮询） 按 RS 权重比例分配请求（如权重 2:1 则高配置 RS 处理 2 倍流量），适合混合配置集群，需手动配置权重。

  3. SH（源 IP 哈希） 相同源 IP 请求固定发往同一 RS，实现会话保持（如购物车），但可能导致单 IP 流量过大时 RS 负载不均。

  4. DH（目标 IP 哈希） 相同目标 IP 请求固定发往同一 RS，适合正向代理缓存（如 CDN），可减少后端缓存失效。

 

3.2.动态算法（感知 RS 负载）

  1. LC（最少连接） 优先调度当前连接数最少的 RS，适合长连接服务（如数据库），但未考虑 RS 性能差异。

  2. WLC（加权最少连接，默认） 综合 RS 权重与连接数（公式：(活动连接数×256 + 非活动连接数) / 权重），调度更公平，适合大多数场景。

  3. SED（最短预期延迟） 高权重 RS 优先承接新连接（公式：(活动连接数+1) ×256 / 权重），适合需要快速调度高配置 RS 的场景。

  4. NQ（永不排队） 第一轮均匀分配请求，后续按 SED 调度，避免请求排队，提升高并发场景响应速度。

  5. LBLC（基于局部性的 LC） 结合 DH 与 LC，优先调度目标 IP 最近使用的 RS，适合 CDN 等缓存场景，减少缓存失效。

  6. LBLCR（带复制的 LBLC） 当 RS 负载不均时，从高负载 RS 复制请求到低负载 RS，适合大规模缓存集群动态均衡。

 

3.3.内核新增算法（4.15+）

  1. FO（加权失败转移） 优先调度未标记过载且权重最高的 RS，支持手动标记过载 RS，适合灰度发布或故障隔离。

  2. OVF（溢出连接） 按权重分配请求，当 RS 连接数超过权重值时自动调度至下一个 RS，防止单 RS 过载。

网站公告

今日签到

点亮在社区的每一天
去签到

热门文章

最新发布