目录一、LVS 原理1.1.什么是 LVS1.2.LVS 的核心作用1.3.LVS 三大核心组件1.4.LVS 的优势1.5.适用场景二、LVS 负载均衡工作模式2.1.NAT 模式2.1.1.NAT 详细传输过程逻辑2.1.2.NAT 模式特点2.1.3.NAT 适用场景2.2.DR 模式2.2.1.DR 详细传输过程逻辑2.2.2.DR 模式特点2.2.3.DR 适用场景2.3.TUN 模式2.3.1.TUN 详细传输过程逻辑2.3.2.TUN 模式特点2.3.3.TUN 适用场景2.4.FullNet 模式2.4.1.FullNet 详细传输过程逻辑2.4.2.FullNet 模式特点2.4.3.FullNet 适用场景2.5.模式总结三、LVS 负载均衡算法3.1.静态算法不感知 RS 负载3.2.动态算法感知 RS 负载3.3.内核新增算法4.15一、LVS 原理1.1.什么是 LVSLVSLinux Virtual ServerLinux 虚拟服务器是集成于 Linux 内核的高性能负载均衡技术由我国科学家章文嵩博士于 1998 年主导开发其核心模块IPVS直接内置于 Linux 内核中属于内核级别的负载均衡解决方案。与 Nginx、HAProxy 等运行在用户态的负载均衡工具不同LVS 工作在操作系统最底层的内核空间通过直接操纵网络数据包转发逻辑实现对大规模并发请求的高效分发。它并非独立的软件而是 Linux 系统原生支持的功能模块只需通过 ipvsadm 工具配置即可启用因此具有极高的稳定性和兼容性。1.2.LVS 的核心作用负载均衡避免单点过载LVS 的核心功能是作为 “前端调度器Director”接收来自客户端的所有请求再根据预设的调度算法如轮询、加权轮询、最小连接等将请求 “均匀” 分发到后端的多台服务器Real Server真实服务器。高可用保障服务不中断结合外部健康检测工具如 KeepalivedLVS 可实现服务的高可用。当后端某台服务器如 Real Server 3因故障宕机、网络中断、服务崩溃无法响应时健康检测工具会立即将其从 “可用服务器池” 中剔除LVS 调度器会自动将后续请求转发给其他正常服务器。待故障服务器修复后又会被重新加入服务器池整个过程无需人工干预确保服务持续可用。注意LVS 本身没有高可用功能。1.3.LVS 三大核心组件负载均衡器Director整个集群的 “入口网关”负责接收所有客户端请求通过虚拟 IP 暴露服务并根据调度算法将请求转发到后端服务器。 Director 是 LVS 的核心控制节点需配置两块网卡或单网卡绑定多 IP一块用于接收客户端请求绑定 VIP另一块用于与后端服务器通信绑定 DIP即 Director IP。服务器池Real ServerRS实际提供服务的后端服务器集群如 Web 服务器、数据库服务器接收 Director 转发的请求并处理。所有 RS 需配置 RIPReal IP且能与 Director 通信通常处于同一局域网。RS 对客户端透明客户端仅感知 VIP 的存在不知道具体 RS 的 IP。虚拟 IPVIPVirtual IP对外暴露的 “服务 IP”是客户端访问集群的唯一入口如 10.0.0.100。 VIP 绑定在 Director 上所有 RS 需通过一定配置如 ARP 抑制确保客户端请求只会被 Director 接收避免 IP 冲突。LVS 相关术语VIPVirtual IP客户端访问 LVS 集群的入口 IP对外暴露服务。 RIPReal Server IP后端真实服务器的 IP用于处理 LVS 转发的请求。 DIPDirector IP负载均衡器Director与后端服务器通信的 IP。 CIPClient IP发起请求的客户端设备的 IP 地址。 Director负载均衡器LVS 集群的核心调度节点接收请求并转发给后端。 Real ServerRS后端实际提供服务的服务器集群。 IPVSLinux 内核中的模块LVS 的核心转发引擎。 ipvsadm管理 IPVS 的用户态工具用于配置 LVS 规则。1.4.LVS 的优势1.高性能LVS 工作在 TCP/IP 协议栈的四层传输层直接在内核中完成请求转发无需经过用户态与内核态之间的数据拷贝这是用户态工具的性能瓶颈。因此其转发效率接近硬件负载均衡器能以极低的资源消耗处理海量请求。2.高并发由于内核级优化LVS 可支持百万级并发连接如每秒处理 100 万以上的新连接远超 Nginx十万级、HAProxy数十万级等工具是高流量场景的核心支撑技术。3.开源免费作为 Linux 内核的一部分LVS 完全开源无需支付任何 licensing 费用且可自由定制修改。相比昂贵的硬件负载均衡器如 F5LVS 能以极低的成本构建企业级负载均衡集群大幅降低架构成本。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 详细传输过程逻辑客户端发送请求客户端向 VIP如192.168.67.100:80发起访问请求数据包包含源 IPCIP客户端自身 IP如192.168.67.10目的 IPVIPLVS 负载均衡器对外暴露的虚拟 IP目的端口服务端口如80或443Director 接收请求并做 DNATLVS 调度器Director接收请求后执行 目的地址转换DNAT将目的 IP 从 VIP 改为 RS 的 RIP如192.168.13.100可能修改目的端口如将客户端请求的80映射到 RS 的8080源 IP 保持为 CIP 不变转发修改后的数据包至 RSRS 处理请求并响应RS 接收数据包源 IP 为 CIP目的 IP 为 RIP处理请求后生成响应数据包源 IPRS 自身的 RIP如192.168.13.10目的 IP客户端的 CIP源端口服务端口如80目的端口客户端随机端口如8080Director 接收响应并做 SNAT响应数据包返回至 DirectorDirector 执行源地址转换SNAT将源 IP 从 RIP 改为 VIP可能修改源端口与步骤 2 对应转发修改后的数据包至客户端客户端接收响应客户端收到的响应数据包中源 IP 为 VIP与请求时一致感知不到后端 RS 的存在。2.1.2.NAT 模式特点1.优点配置简单RS 无需特殊配置只需能访问 Director 的 DIP 即可。网络隔离RS 可使用私有 IP无需暴露在公网安全性高。支持端口映射可将客户端请求的端口如80映射到 RS 的其他端口如8080。2.缺点性能瓶颈所有请求和响应都需经过 DirectorDirector 易成为流量瓶颈。依赖 DirectorRS 必须通过 Director 与客户端通信无法直接响应。扩展性有限Director 的处理能力限制了集群规模通常适用于中小规模部署。2.1.3.NAT 适用场景小规模集群当后端 RS 数量较少如 10 台且流量不大时。RS 无公网 IPRS 部署在私有网络需通过 Director 进行地址转换。测试 / 开发环境配置简单便于快速搭建负载均衡架构。端口映射需求需要将不同端口的请求分发到同一 RS 的不同服务时如80→8080443→8443。2.2.DR 模式2.2.1.DR 详细传输过程逻辑1. 客户端发送访问请求客户端向 VIP如10.0.0.100:80发起请求数据帧包含源 IPCIP客户端自身 IP如113.57.xxx.xxx源 MAC客户端网卡的 MAC 地址如aa:bb:cc:dd:ee:ff目的 IPVIPLVS 集群的虚拟服务 IP绑定在 Director 的 dummy 虚拟网卡lvstest上目的 MACDirector 的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的 MACff:ee:dd:cc:bb:aa改为目标 RS 的 dummy 网卡rs-vip的 MAC 地址如11:22:33:44:55:66修改源 MAC将源 MAC 从客户端的 MACaa:bb:cc:dd:ee:ff改为DIP 所在物理网卡的 MAC如22:33:44:55:66:77即 Director 连 RS 的eth1网卡 MACIP 层保持不变源 IPCIP、目的 IPVIP、端口均不修改关键点Director 通过物理网卡eth1绑定 DIP转发数据包根据链路层规则源 MAC 必须是发送接口eth1的 MAC与 dummy 网卡lvstest无关。3. RS 处理请求并直接响应客户端RS 接收数据包因 RS 的 dummy 网卡rs-vip绑定了 VIP能识别目的 IP 为 VIP 的请求处理后生成响应源 IP保持为 VIP确保客户端感知不到 RS 存在源 MACRS 的rs-vip网卡的 MAC 地址11:22:33:44:55:66目的 IP客户端 IPCIP目的 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 模式特点数据转发基于二层 MAC 地址修改Director负载均衡器仅修改请求数据包的目的 MAC 地址从自身与后端通信的网卡 MAC 改为目标后端服务器的 MAC不修改源 IP、目的 IPVIP和端口。这种转发方式几乎不消耗 Director 的计算资源效率极高。响应不经过 Director降低瓶颈后端服务器RS处理请求后直接向客户端返回响应源 IP 为 VIP目的 IP 为客户端 IP响应数据包不经过 Director。因此Director 仅承担 “请求转发” 角色不会成为流量瓶颈支持更高并发。网络层限制需同一广播域Director 与后端服务器RS必须处于同一局域网同一广播域因为 MAC 地址转发依赖二层网络通信无法跨网段路由。后端服务器需特殊配置所有 RS 必须在本地绑定 VIP通常通过虚拟 dummy 网卡而非物理网卡或 lo 回环否则无法接收目标为 VIP 的数据包。需配置 ARP 抑制如关闭 VIP 的 ARP 响应、抑制 ARP 广播避免 RS 因绑定 VIP 而对外宣告 ARP导致客户端直接向 RS 发送请求绕过 Director。不支持端口映射由于 Director 不修改 IP 和端口后端服务器的服务端口必须与 VIP 暴露的端口一致如 VIP:80 对应 RS:80无法像 NAT 模式那样做端口转换。扩展性强因 Director 负载极低可轻松扩展后端服务器数量理论上支持数百甚至上千节点适合大规模集群。2.2.3.DR 适用场景高并发、大流量的 TCP/UDP 服务如 Web 服务器HTTP/HTTPS、静态资源服务、视频点播 / 直播的前端负载均衡等。这类服务请求量巨大DR 模式的低延迟、高吞吐量特性可显著提升整体性能。同一局域网内的服务部署由于依赖二层 MAC 通信Director 与 RS 必须在同一网段如机房内部集群适合数据中心内部的负载均衡场景。追求极致性能降低 Director 负载相比 NAT 模式响应需经 Director或 TUN 模式封装 IP 隧道开销较高DR 模式性能最优适合对延迟敏感的服务如金融交易、实时通信。后端服务器可水平扩展的场景当业务需要通过增加后端节点提升容量时DR 模式对 Director 的低依赖使其能轻松支持大规模扩展无需频繁升级 Director 硬件。2.3.TUN 模式2.3.1.TUN 详细传输过程逻辑客户端发送请求发送数据包包内有源 IPvipdportVS 调度器转发流量到达 VS 调度器后对客户端发送过来的数据包重新封装添加 IP 报文头新添加的 IP 报文头中包含TUNSRCIPDIPTUNDESTIPRSIP1) 并发送到 RS1RS 回应RS 收到 VS 调度器发送过来的数据包做出响应生成的响应报文中包含 SRCIPVIPDSTIPCIPport响应数据包通过网络直接回传给 client2.3.2.TUN 模式特点核心转发逻辑仅请求数据包经过 VS 时被隧道封装添加外层 IP 头响应数据包由 RS 直接回传客户端VS 不参与响应转发避免成为瓶颈。依赖 IP 隧道协议如 GRE实现跨网段通信原 IP 层CIP→VIP始终不变确保 RS 能识别请求。优势突破局域网限制VS 与 RS 可不在同一网段支持跨机房、跨地域部署解决 DR 模式 “必须同一广播域” 的痛点。性能较高响应不经过 VS仅请求有封装开销性能优于 NAT 模式接近 DR 模式的 70%-80%支持中大规模集群数十至数百台 RS。灵活性强可通过隧道隔离 RS 网络适合多租户场景如不同 RS 集群分属不同部门通过隧道与 VS 通信。劣势封装开销隧道封装 / 解封装会消耗一定 CPU 资源尤其高并发场景性能略低于 DR 模式。配置复杂需在 VS 和 RS 上额外配置隧道协议如 GRE并确保隧道两端路由互通RS 需绑定 VIP 并配置 ARP 抑制避免 VIP 冲突。依赖隧道协议支持部分老旧设备或系统可能不支持 GRE 等隧道协议限制部署场景。2.3.3.TUN 适用场景跨网段 / 跨机房部署如总部与分部的服务器集群跨城市局域网需通过公网或专线通信TUN 模式可通过隧道将请求从 VS 转发到异地 RS。分布式集群 / 云服务云平台中虚拟机或容器分布在不同私有网络如 AWS 的 VPC、阿里云的专有网络TUN 模式可跨网络边界分发请求。大规模地理分布式服务如跨地域的 CDN 节点、短视频的边缘计算节点需将用户请求就近转发到不同地区的 RSTUN 模式支持跨广域网的负载均衡。需隔离 RS 网络的场景当 RS 部署在安全隔离区如金融系统的核心数据库集群仅允许通过隧道与外界通信时TUN 模式可在保证隔离的同时实现负载均衡。2.4.FullNet 模式2.4.1.FullNet 详细传输过程逻辑客户端对 VIP 发起请求。Director 接过请求发现是请求后端集群服务。Director 对请求报文做 FULL NAT把源 IP 改为 DIP把目标 IP 转换为任意以后后端 RS 的 RIP然后法网后端。RS 接收到请求后进行响应相应报文源 IP 为 RIP目标 IP 还是 DIP又内部路由路由到 Director。Director 接收相应报文后进行 FULL NAT把源地址改为 VIP目标地址改为 CIP。2.4.2.FullNet 模式特点双向 NAT 解耦网络请求 / 响应均做 IP 转换RS 无需配置网关指向 Director部署更灵活。跨网自由部署RS 可分布在任意路由可达的网络跨机房、跨云平台无需同网段。隐藏 RS 真实 IP客户端 / 外部网络无法直接访问 RS 的 RIP增强后端安全性。性能适中优于普通 NAT无响应瓶颈略低于 DR 模式支持中大规模集群。2.4.3.FullNet 适用场景跨数据中心 / 混合云多地域机房、公有云 私有云混合部署统一通过 Director 接入。高安全隔离金融、政务等敏感业务RS 部署在内网隔离区仅暴露 VIP 对外服务。替代普通 NAT解决普通 NAT 的 “RS 网关必须指向 Director” 限制支持更灵活的 RS 扩展。2.5.模式总结模式核心逻辑网络修改响应路径网络要求性能适用场景NATDirector作网关双向改IP源IPCIP→DIP、目的IPVIP→RIP经DirectorRS网关指向Director同网段低小规模集群、低成本DR修改MACIP层不变仅改目的MAC直连客户端同广播域二层可达极高高并发Web、局域网大规模集群TUN隧道封装跨网段转发外层IPDIP→RIP内层不变直连客户端跨网段RS支持隧道协议中高跨地域集群、分布式系统FULLNAT双向NAT解耦RS网络源IPCIP→DIP、目的IPVIP→RIP经DirectorRS路由可达即可无需同网段中混合云、高安全隔离场景三、LVS 负载均衡算法3.1.静态算法不感知 RS 负载RR轮询轮流调度 RS不考虑性能差异适合 RS 配置一致的小规模集群缺点是性能差异大时易导致负载不均。WRR加权轮询按 RS 权重比例分配请求如权重 2:1 则高配置 RS 处理 2 倍流量适合混合配置集群需手动配置权重。SH源 IP 哈希相同源 IP 请求固定发往同一 RS实现会话保持如购物车但可能导致单 IP 流量过大时 RS 负载不均。DH目标 IP 哈希相同目标 IP 请求固定发往同一 RS适合正向代理缓存如 CDN可减少后端缓存失效。3.2.动态算法感知 RS 负载LC最少连接优先调度当前连接数最少的 RS适合长连接服务如数据库但未考虑 RS 性能差异。WLC加权最少连接默认综合 RS 权重与连接数公式(活动连接数×256 非活动连接数) / 权重调度更公平适合大多数场景。SED最短预期延迟高权重 RS 优先承接新连接公式(活动连接数1) ×256 / 权重适合需要快速调度高配置 RS 的场景。NQ永不排队第一轮均匀分配请求后续按 SED 调度避免请求排队提升高并发场景响应速度。LBLC基于局部性的 LC结合 DH 与 LC优先调度目标 IP 最近使用的 RS适合 CDN 等缓存场景减少缓存失效。LBLCR带复制的 LBLC当 RS 负载不均时从高负载 RS 复制请求到低负载 RS适合大规模缓存集群动态均衡。3.3.内核新增算法4.15FO加权失败转移优先调度未标记过载且权重最高的 RS支持手动标记过载 RS适合灰度发布或故障隔离。OVF溢出连接按权重分配请求当 RS 连接数超过权重值时自动调度至下一个 RS防止单 RS 过载。 LVS 原理详解
目录一、LVS 原理1.1.什么是 LVS1.2.LVS 的核心作用1.3.LVS 三大核心组件1.4.LVS 的优势1.5.适用场景二、LVS 负载均衡工作模式2.1.NAT 模式2.1.1.NAT 详细传输过程逻辑2.1.2.NAT 模式特点2.1.3.NAT 适用场景2.2.DR 模式2.2.1.DR 详细传输过程逻辑2.2.2.DR 模式特点2.2.3.DR 适用场景2.3.TUN 模式2.3.1.TUN 详细传输过程逻辑2.3.2.TUN 模式特点2.3.3.TUN 适用场景2.4.FullNet 模式2.4.1.FullNet 详细传输过程逻辑2.4.2.FullNet 模式特点2.4.3.FullNet 适用场景2.5.模式总结三、LVS 负载均衡算法3.1.静态算法不感知 RS 负载3.2.动态算法感知 RS 负载3.3.内核新增算法4.15一、LVS 原理1.1.什么是 LVSLVSLinux Virtual ServerLinux 虚拟服务器是集成于 Linux 内核的高性能负载均衡技术由我国科学家章文嵩博士于 1998 年主导开发其核心模块IPVS直接内置于 Linux 内核中属于内核级别的负载均衡解决方案。与 Nginx、HAProxy 等运行在用户态的负载均衡工具不同LVS 工作在操作系统最底层的内核空间通过直接操纵网络数据包转发逻辑实现对大规模并发请求的高效分发。它并非独立的软件而是 Linux 系统原生支持的功能模块只需通过 ipvsadm 工具配置即可启用因此具有极高的稳定性和兼容性。1.2.LVS 的核心作用负载均衡避免单点过载LVS 的核心功能是作为 “前端调度器Director”接收来自客户端的所有请求再根据预设的调度算法如轮询、加权轮询、最小连接等将请求 “均匀” 分发到后端的多台服务器Real Server真实服务器。高可用保障服务不中断结合外部健康检测工具如 KeepalivedLVS 可实现服务的高可用。当后端某台服务器如 Real Server 3因故障宕机、网络中断、服务崩溃无法响应时健康检测工具会立即将其从 “可用服务器池” 中剔除LVS 调度器会自动将后续请求转发给其他正常服务器。待故障服务器修复后又会被重新加入服务器池整个过程无需人工干预确保服务持续可用。注意LVS 本身没有高可用功能。1.3.LVS 三大核心组件负载均衡器Director整个集群的 “入口网关”负责接收所有客户端请求通过虚拟 IP 暴露服务并根据调度算法将请求转发到后端服务器。 Director 是 LVS 的核心控制节点需配置两块网卡或单网卡绑定多 IP一块用于接收客户端请求绑定 VIP另一块用于与后端服务器通信绑定 DIP即 Director IP。服务器池Real ServerRS实际提供服务的后端服务器集群如 Web 服务器、数据库服务器接收 Director 转发的请求并处理。所有 RS 需配置 RIPReal IP且能与 Director 通信通常处于同一局域网。RS 对客户端透明客户端仅感知 VIP 的存在不知道具体 RS 的 IP。虚拟 IPVIPVirtual IP对外暴露的 “服务 IP”是客户端访问集群的唯一入口如 10.0.0.100。 VIP 绑定在 Director 上所有 RS 需通过一定配置如 ARP 抑制确保客户端请求只会被 Director 接收避免 IP 冲突。LVS 相关术语VIPVirtual IP客户端访问 LVS 集群的入口 IP对外暴露服务。 RIPReal Server IP后端真实服务器的 IP用于处理 LVS 转发的请求。 DIPDirector IP负载均衡器Director与后端服务器通信的 IP。 CIPClient IP发起请求的客户端设备的 IP 地址。 Director负载均衡器LVS 集群的核心调度节点接收请求并转发给后端。 Real ServerRS后端实际提供服务的服务器集群。 IPVSLinux 内核中的模块LVS 的核心转发引擎。 ipvsadm管理 IPVS 的用户态工具用于配置 LVS 规则。1.4.LVS 的优势1.高性能LVS 工作在 TCP/IP 协议栈的四层传输层直接在内核中完成请求转发无需经过用户态与内核态之间的数据拷贝这是用户态工具的性能瓶颈。因此其转发效率接近硬件负载均衡器能以极低的资源消耗处理海量请求。2.高并发由于内核级优化LVS 可支持百万级并发连接如每秒处理 100 万以上的新连接远超 Nginx十万级、HAProxy数十万级等工具是高流量场景的核心支撑技术。3.开源免费作为 Linux 内核的一部分LVS 完全开源无需支付任何 licensing 费用且可自由定制修改。相比昂贵的硬件负载均衡器如 F5LVS 能以极低的成本构建企业级负载均衡集群大幅降低架构成本。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 详细传输过程逻辑客户端发送请求客户端向 VIP如192.168.67.100:80发起访问请求数据包包含源 IPCIP客户端自身 IP如192.168.67.10目的 IPVIPLVS 负载均衡器对外暴露的虚拟 IP目的端口服务端口如80或443Director 接收请求并做 DNATLVS 调度器Director接收请求后执行 目的地址转换DNAT将目的 IP 从 VIP 改为 RS 的 RIP如192.168.13.100可能修改目的端口如将客户端请求的80映射到 RS 的8080源 IP 保持为 CIP 不变转发修改后的数据包至 RSRS 处理请求并响应RS 接收数据包源 IP 为 CIP目的 IP 为 RIP处理请求后生成响应数据包源 IPRS 自身的 RIP如192.168.13.10目的 IP客户端的 CIP源端口服务端口如80目的端口客户端随机端口如8080Director 接收响应并做 SNAT响应数据包返回至 DirectorDirector 执行源地址转换SNAT将源 IP 从 RIP 改为 VIP可能修改源端口与步骤 2 对应转发修改后的数据包至客户端客户端接收响应客户端收到的响应数据包中源 IP 为 VIP与请求时一致感知不到后端 RS 的存在。2.1.2.NAT 模式特点1.优点配置简单RS 无需特殊配置只需能访问 Director 的 DIP 即可。网络隔离RS 可使用私有 IP无需暴露在公网安全性高。支持端口映射可将客户端请求的端口如80映射到 RS 的其他端口如8080。2.缺点性能瓶颈所有请求和响应都需经过 DirectorDirector 易成为流量瓶颈。依赖 DirectorRS 必须通过 Director 与客户端通信无法直接响应。扩展性有限Director 的处理能力限制了集群规模通常适用于中小规模部署。2.1.3.NAT 适用场景小规模集群当后端 RS 数量较少如 10 台且流量不大时。RS 无公网 IPRS 部署在私有网络需通过 Director 进行地址转换。测试 / 开发环境配置简单便于快速搭建负载均衡架构。端口映射需求需要将不同端口的请求分发到同一 RS 的不同服务时如80→8080443→8443。2.2.DR 模式2.2.1.DR 详细传输过程逻辑1. 客户端发送访问请求客户端向 VIP如10.0.0.100:80发起请求数据帧包含源 IPCIP客户端自身 IP如113.57.xxx.xxx源 MAC客户端网卡的 MAC 地址如aa:bb:cc:dd:ee:ff目的 IPVIPLVS 集群的虚拟服务 IP绑定在 Director 的 dummy 虚拟网卡lvstest上目的 MACDirector 的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的 MACff:ee:dd:cc:bb:aa改为目标 RS 的 dummy 网卡rs-vip的 MAC 地址如11:22:33:44:55:66修改源 MAC将源 MAC 从客户端的 MACaa:bb:cc:dd:ee:ff改为DIP 所在物理网卡的 MAC如22:33:44:55:66:77即 Director 连 RS 的eth1网卡 MACIP 层保持不变源 IPCIP、目的 IPVIP、端口均不修改关键点Director 通过物理网卡eth1绑定 DIP转发数据包根据链路层规则源 MAC 必须是发送接口eth1的 MAC与 dummy 网卡lvstest无关。3. RS 处理请求并直接响应客户端RS 接收数据包因 RS 的 dummy 网卡rs-vip绑定了 VIP能识别目的 IP 为 VIP 的请求处理后生成响应源 IP保持为 VIP确保客户端感知不到 RS 存在源 MACRS 的rs-vip网卡的 MAC 地址11:22:33:44:55:66目的 IP客户端 IPCIP目的 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 模式特点数据转发基于二层 MAC 地址修改Director负载均衡器仅修改请求数据包的目的 MAC 地址从自身与后端通信的网卡 MAC 改为目标后端服务器的 MAC不修改源 IP、目的 IPVIP和端口。这种转发方式几乎不消耗 Director 的计算资源效率极高。响应不经过 Director降低瓶颈后端服务器RS处理请求后直接向客户端返回响应源 IP 为 VIP目的 IP 为客户端 IP响应数据包不经过 Director。因此Director 仅承担 “请求转发” 角色不会成为流量瓶颈支持更高并发。网络层限制需同一广播域Director 与后端服务器RS必须处于同一局域网同一广播域因为 MAC 地址转发依赖二层网络通信无法跨网段路由。后端服务器需特殊配置所有 RS 必须在本地绑定 VIP通常通过虚拟 dummy 网卡而非物理网卡或 lo 回环否则无法接收目标为 VIP 的数据包。需配置 ARP 抑制如关闭 VIP 的 ARP 响应、抑制 ARP 广播避免 RS 因绑定 VIP 而对外宣告 ARP导致客户端直接向 RS 发送请求绕过 Director。不支持端口映射由于 Director 不修改 IP 和端口后端服务器的服务端口必须与 VIP 暴露的端口一致如 VIP:80 对应 RS:80无法像 NAT 模式那样做端口转换。扩展性强因 Director 负载极低可轻松扩展后端服务器数量理论上支持数百甚至上千节点适合大规模集群。2.2.3.DR 适用场景高并发、大流量的 TCP/UDP 服务如 Web 服务器HTTP/HTTPS、静态资源服务、视频点播 / 直播的前端负载均衡等。这类服务请求量巨大DR 模式的低延迟、高吞吐量特性可显著提升整体性能。同一局域网内的服务部署由于依赖二层 MAC 通信Director 与 RS 必须在同一网段如机房内部集群适合数据中心内部的负载均衡场景。追求极致性能降低 Director 负载相比 NAT 模式响应需经 Director或 TUN 模式封装 IP 隧道开销较高DR 模式性能最优适合对延迟敏感的服务如金融交易、实时通信。后端服务器可水平扩展的场景当业务需要通过增加后端节点提升容量时DR 模式对 Director 的低依赖使其能轻松支持大规模扩展无需频繁升级 Director 硬件。2.3.TUN 模式2.3.1.TUN 详细传输过程逻辑客户端发送请求发送数据包包内有源 IPvipdportVS 调度器转发流量到达 VS 调度器后对客户端发送过来的数据包重新封装添加 IP 报文头新添加的 IP 报文头中包含TUNSRCIPDIPTUNDESTIPRSIP1) 并发送到 RS1RS 回应RS 收到 VS 调度器发送过来的数据包做出响应生成的响应报文中包含 SRCIPVIPDSTIPCIPport响应数据包通过网络直接回传给 client2.3.2.TUN 模式特点核心转发逻辑仅请求数据包经过 VS 时被隧道封装添加外层 IP 头响应数据包由 RS 直接回传客户端VS 不参与响应转发避免成为瓶颈。依赖 IP 隧道协议如 GRE实现跨网段通信原 IP 层CIP→VIP始终不变确保 RS 能识别请求。优势突破局域网限制VS 与 RS 可不在同一网段支持跨机房、跨地域部署解决 DR 模式 “必须同一广播域” 的痛点。性能较高响应不经过 VS仅请求有封装开销性能优于 NAT 模式接近 DR 模式的 70%-80%支持中大规模集群数十至数百台 RS。灵活性强可通过隧道隔离 RS 网络适合多租户场景如不同 RS 集群分属不同部门通过隧道与 VS 通信。劣势封装开销隧道封装 / 解封装会消耗一定 CPU 资源尤其高并发场景性能略低于 DR 模式。配置复杂需在 VS 和 RS 上额外配置隧道协议如 GRE并确保隧道两端路由互通RS 需绑定 VIP 并配置 ARP 抑制避免 VIP 冲突。依赖隧道协议支持部分老旧设备或系统可能不支持 GRE 等隧道协议限制部署场景。2.3.3.TUN 适用场景跨网段 / 跨机房部署如总部与分部的服务器集群跨城市局域网需通过公网或专线通信TUN 模式可通过隧道将请求从 VS 转发到异地 RS。分布式集群 / 云服务云平台中虚拟机或容器分布在不同私有网络如 AWS 的 VPC、阿里云的专有网络TUN 模式可跨网络边界分发请求。大规模地理分布式服务如跨地域的 CDN 节点、短视频的边缘计算节点需将用户请求就近转发到不同地区的 RSTUN 模式支持跨广域网的负载均衡。需隔离 RS 网络的场景当 RS 部署在安全隔离区如金融系统的核心数据库集群仅允许通过隧道与外界通信时TUN 模式可在保证隔离的同时实现负载均衡。2.4.FullNet 模式2.4.1.FullNet 详细传输过程逻辑客户端对 VIP 发起请求。Director 接过请求发现是请求后端集群服务。Director 对请求报文做 FULL NAT把源 IP 改为 DIP把目标 IP 转换为任意以后后端 RS 的 RIP然后法网后端。RS 接收到请求后进行响应相应报文源 IP 为 RIP目标 IP 还是 DIP又内部路由路由到 Director。Director 接收相应报文后进行 FULL NAT把源地址改为 VIP目标地址改为 CIP。2.4.2.FullNet 模式特点双向 NAT 解耦网络请求 / 响应均做 IP 转换RS 无需配置网关指向 Director部署更灵活。跨网自由部署RS 可分布在任意路由可达的网络跨机房、跨云平台无需同网段。隐藏 RS 真实 IP客户端 / 外部网络无法直接访问 RS 的 RIP增强后端安全性。性能适中优于普通 NAT无响应瓶颈略低于 DR 模式支持中大规模集群。2.4.3.FullNet 适用场景跨数据中心 / 混合云多地域机房、公有云 私有云混合部署统一通过 Director 接入。高安全隔离金融、政务等敏感业务RS 部署在内网隔离区仅暴露 VIP 对外服务。替代普通 NAT解决普通 NAT 的 “RS 网关必须指向 Director” 限制支持更灵活的 RS 扩展。2.5.模式总结模式核心逻辑网络修改响应路径网络要求性能适用场景NATDirector作网关双向改IP源IPCIP→DIP、目的IPVIP→RIP经DirectorRS网关指向Director同网段低小规模集群、低成本DR修改MACIP层不变仅改目的MAC直连客户端同广播域二层可达极高高并发Web、局域网大规模集群TUN隧道封装跨网段转发外层IPDIP→RIP内层不变直连客户端跨网段RS支持隧道协议中高跨地域集群、分布式系统FULLNAT双向NAT解耦RS网络源IPCIP→DIP、目的IPVIP→RIP经DirectorRS路由可达即可无需同网段中混合云、高安全隔离场景三、LVS 负载均衡算法3.1.静态算法不感知 RS 负载RR轮询轮流调度 RS不考虑性能差异适合 RS 配置一致的小规模集群缺点是性能差异大时易导致负载不均。WRR加权轮询按 RS 权重比例分配请求如权重 2:1 则高配置 RS 处理 2 倍流量适合混合配置集群需手动配置权重。SH源 IP 哈希相同源 IP 请求固定发往同一 RS实现会话保持如购物车但可能导致单 IP 流量过大时 RS 负载不均。DH目标 IP 哈希相同目标 IP 请求固定发往同一 RS适合正向代理缓存如 CDN可减少后端缓存失效。3.2.动态算法感知 RS 负载LC最少连接优先调度当前连接数最少的 RS适合长连接服务如数据库但未考虑 RS 性能差异。WLC加权最少连接默认综合 RS 权重与连接数公式(活动连接数×256 非活动连接数) / 权重调度更公平适合大多数场景。SED最短预期延迟高权重 RS 优先承接新连接公式(活动连接数1) ×256 / 权重适合需要快速调度高配置 RS 的场景。NQ永不排队第一轮均匀分配请求后续按 SED 调度避免请求排队提升高并发场景响应速度。LBLC基于局部性的 LC结合 DH 与 LC优先调度目标 IP 最近使用的 RS适合 CDN 等缓存场景减少缓存失效。LBLCR带复制的 LBLC当 RS 负载不均时从高负载 RS 复制请求到低负载 RS适合大规模缓存集群动态均衡。3.3.内核新增算法4.15FO加权失败转移优先调度未标记过载且权重最高的 RS支持手动标记过载 RS适合灰度发布或故障隔离。OVF溢出连接按权重分配请求当 RS 连接数超过权重值时自动调度至下一个 RS防止单 RS 过载。