【一文吃透lvs负载均衡：集群原理，工作模式，算法与常见问题处理】

1.什么是集群集群是由多台相互独立的计算机或服务器通过高速网络连接组成的一个统一系统。这些计算机协同工作共同完成特定任务并对外表现为一个单一的服务系统。每台计算机称为一个节点节点之间可以通信并共享资源。举个例子在足球队里单个球员相当于单台服务器而整只球队就相当于集群。大家分工合作有人进攻有人防守有人累了下场替补球队依旧正常运转。集群的核心特点是通过分布式架构提高系统的性能、可靠性和可扩展性。例如像百度或谷歌这样的大型网站其背后是由成千上万台服务器组成的集群共同支持。2.集群的常见分类负载均衡集群将用户请求均匀分配到多个节点适用于Web服务和数据库应用。高可用性集群在节点故障时任务会自动转移到其他节点确保服务不中断。高性能计算集群通过并行计算解决复杂科学问题如核反应模拟和石油勘探。网格计算集群用于分布式计算但实际应用较少。在互联网行业负载均衡集群和高可用性集群是最常见的架构模式。例如淘宝和支付宝早期通过集群技术降低成本并提升系统扩展性。常用的开源软件包括Nginx、LVS和Haproxy等。 集群技术的广泛应用使得现代系统能够在高并发、高负载的情况下保持稳定运行同时降低了运维成本和复杂性。3.LVS的作用LVSLinux Virtual Server 是一种基于 Linux 的虚拟服务器集群系统主要用于实现高性能、高可用的负载均衡集群。它通过在网络层分发请求将用户的访问流量分配到后端服务器从而提升系统的并发处理能力和可靠性。比如现在有一堆任务和一群人如果这些任务都分到一个人身上那么这个人就要干活给自己累死了剩下的人分不到任务则会非常的悠闲这样不合理的分配就会耗费大量的资源非常的不合理而LVS则会将这些活儿合理的分配给状态空闲的人身上避免一个人累死。LVS集群体系结构4.LVS的四种模式和原理4.1.四种工作模式核心原理总览四种转发模式的核心差异在于对数据包的修改方式是区分各模式的关键LVS-NAT多目标IP DNAT仅修改请求报文的目标IP端口LVS-DR链路层转发仅重新封装MAC地址首部IP/端口全程不变LVS-TUN网络层隧道转发在原有IP报文外新增一层IP首部LVS-FULLNAT双向地址转换同时修改请求报文的源IP目标IP4.2.LVS-NAT 模式4.2.1核心原理LVS-NAT 本质为多目标IP DNAT转发。VS 调度器接收客户端请求将请求报文的目标地址VIP和目标端口修改为后端真实服务器RS的内网地址RIP和对应端口实现请求转发。4.2.2 核心约束特性RIP 与 DIP 需处于同一内网网段统一使用私网地址所有 RS 的默认网关必须指向 VS 的 DIP保证响应报文回经调度器请求、响应报文均经过 VS调度器极易成为性能瓶颈支持端口映射可灵活修改目标访问端口VS 必须为 Linux 系统RS 支持任意操作系统。4.2.3 数据流转逻辑客户端发起请求数据包携带客户端IPCIP、源端口、目标VIP、目标端口VS 接收请求通过 DNAT 规则将数据包目标地址 VIP 替换为 RS 的 RIP完成请求转发RS 接收请求并处理生成响应报文源地址为自身 RIP目标地址为客户端 CIP响应报文回传至 VSVS 再次修改报文源 RIP 替换为 VIP同时可调整响应端口VS 将修改后的响应报文转发给客户端完成一次完整请求交互4.2.4 工作机制与注意事项客户端请求抵达主机后优先经过 PREROUTING 链。无 IPVS 规则时请求会进入本机 INPUT 链开启 IPVS 后请求在 PREROUTING 之后、INPUT 之前被 IPVS 拦截完成 NAT 转发由于 IPVS 工作在 PREROUTING 与 INPUT 之间自定义 iptables 规则会干扰 IPVS 转发逻辑因此部署 LVS-NAT 时需清空所有 iptables 防火墙策略。4.3.LVS-DR 模式默认主流模式4.3.1 核心原理DRDirect Routing直接路由是 LVS 默认、应用最广泛的模式。工作在数据链路层仅重新封装数据包的 MAC 首部新帧源 MAC 为 VS 网卡 MAC目标 MAC 为选中 RS 的网卡 MAC全程不修改原报文的 IP 地址与端口。4.3.2 数据流转逻辑客户端发送数据帧源 IPCIP、源 MAC客户端MAC、目标 IPVIP、目标 MACVS 网卡MACVS 接收数据帧仅修改帧头 MAC 信息将目标 MAC 替换为对应 RS 的网卡 MACIP 和端口保持不变RS 接收修改后的数据帧识别自身 MAC 后处理请求直接生成响应报文源 IPVIP、目标 IPCIP不经过 VS 调度器RS 直接将响应数据回传给客户端完成请求响应4.3.3 核心特点与部署要求1.VS 调度器和所有 RS 服务器均需配置 VIP2.前端路由器需将 VIP 流量定向转发至 VS可通过静态绑定 VIP 与 VS MAC 地址实现3.请求经 VS、响应不经 VS彻底解决调度器性能瓶颈并发能力极强4.不支持端口映射无法修改访问端口5.VS 与所有 RS 必须在同一物理局域网不可跨网段部署6.RS 的 RIP 可使用公网或私网地址网关禁止指向 VS 的 DIP避免响应报文回流经过调度器7.RS 需配置 ARP 抑制规则防止 VIP ARP 冲突抢占 1) ARP 过滤规则arptables -A IN -d $VIP -j DROP2) ARP 伪装规则arptables -A OUT -s $VIP -j mangle --mangle-ip-s $RIP8.RS 支持绝大多数操作系统兼容性强4.4.LVS-TUN 模式隧道模式4.4.1 核心原理TUN 隧道模式工作在网络层不修改原有请求 IP 报文仅在原报文外层新增一层独立 IP 首部通过隧道封装实现跨公网、跨网段转发。4.4.2 数据流转逻辑客户端发起请求原始报文源 IPCIP、目标 IPVIP、目标端口VS 接收请求在原始报文外封装新 IP 头新源 IP 为 VS 的 DIP新目标 IP 为 RS 的 RIP转发至对应 RSRS 解封装外层 IP 头读取原始请求报文并处理RS 直接生成响应报文源 IP 为 VIP、目标 IP 为 CIP绕过 VS 直接回传给客户端4.4.3 核心特点改请求报文的源 IP 和目标 IP 源地址转换CIP → DIP 目标地址转换VIP → RIP4.5LVS-FULLNAT 模式4.5.1 核心原理FULLNAT 是双向地址转换模式同时修改请求报文的源 IP 和目标 IP 源地址转换CIP → DIP 目标地址转换VIP → RIP4.5.2核心特点1.VIP 为公网地址DIP、RIP 为私网地址二者无需同一网段仅需保证网络互通2.RS 接收的请求源地址为 VS 的 DIP响应报文先回传至 VS再由 VS 转发给客户端3.请求、响应报文均全程经过 VS支持端口映射5.LVS的13种算法讲解LVS IPVS 内核共实现 13 种调度算法分为 静态算法4种 和 动态算法9种 两大类。静态算法仅按固定规则调度不感知后端服务器实时负载动态算法基于服务器实时连接数、负载、响应速度动态调整调度权重负载均衡效果更优。5.1.LVS的4种静态算法算法名称基本介绍特点应用场景RRRound Robin轮询调度最基础的调度算法无权重、无负载感知。VS 按顺序将客户端请求依次分发到每台 RS 服务器循环往复、平均分配请求。请求绝对平均分配实现简单、无性能损耗。所有后端 RS 硬件配置一致、性能相同且请求业务场景统一、单请求资源消耗相近的集群。WRRWeighted Round Robin加权轮询RR 算法的升级版为每台 RS 设置固定权重值权重越高的服务器被分配的请求数量越多、调度优先级越高。系统根据权重比例轮询分发请求。可差异化适配不同配置的服务器高性能服务器承担更多请求权重固定不随实时负载变化。后端 RS 硬件配置、性能参差不齐的集群环境。DHDestination Hash目标地址哈希基于客户端请求的目标IP地址进行哈希计算通过哈希结果固定分配到某一台 RS。同一目标IP的所有请求始终调度至同一后端服务器。目标IP与 RS 绑定固定稳定性强。目标地址固定、需要会话绑定、缓存服务集群场景。SHSource Hash源地址哈希基于客户端源IP地址CIP做哈希运算将同一客户端IP的请求始终调度到同一台 RS实现基础会话保持。天然实现会话保持无需额外配置缺点是无一致性哈希某台 RS 故障下线后对应客户端连接全部失效不会自动平滑迁移。需要固定客户端会话、无频繁上下线的稳定集群。5.2.LVS的9种动态算法算法名称基本介绍特点应用场景LCLeast Connections最少连接动态统计每台 RS 当前活跃连接数始终将新请求分发到活连跃接数最少的后端服务器自动规避高负载节点。实时均衡连接数适配请求耗时差异大的业务。请求处理时长不一致、业务波动较大的集群。WLCWeighted Least Connections加权最少连接LVS 默认调度算法LC 算法的加权升级版。结合服务器权重与实时连接数综合计算权重越高、空闲资源越多的服务器优先分配新请求。计算公式(当前连接数/权重)比值越小优先级越高。兼顾服务器硬件性能与实时负载均衡效果最优、最稳定。绝大多数生产环境适配绝大多数业务场景。SEDShortest Expected Delay最短期望延迟基于 WLC 优化而来核心逻辑不考虑空闲无连接的服务器优先将新请求分配给延迟最低、负载最轻的 RS。计算公式(当前连接数1)/权重比值越小调度优先级越高。优先保障新请求响应速度减少高负载服务器压力。对响应延迟敏感、追求低延时的业务集群。NQNever Queue永不排队SED 算法的优化版。若存在空闲无连接的 RS直接将请求分配给空闲节点不参与公式计算所有服务器均有连接时沿用 SED 算法逻辑调度。最大化利用空闲服务器资源避免无效排队提升整体并发效率。高并发、瞬时请求量大的业务场景。LBLCLocality-Based Least Connections基于本地的最少连接带本地缓存的动态调度算法。优先将同一目标IP的请求调度到上次处理该请求的 RS若该服务器负载过高或下线再分配给最少连接的空闲节点。兼顾会话本地性与负载均衡提升缓存命中率。Web 缓存、静态资源缓存集群。LBLCRLBLC with Replication带复制的本地最少连接LBLC 算法升级版支持请求节点复制缓存。不仅保留本地会话绑定特性还会对热点请求资源进行节点复制进一步提升缓存利用率。缓存命中率更高热点资源访问效率大幅提升。高热点、高访问量的静态资源缓存集群。BLHBalanced Locality Hash均衡本地哈希基于源IP哈希的优化算法在会话保持的基础上兼顾后端服务器负载均衡规避传统 SH 算法负载不均的问题。既实现源IP会话保持又能均衡各节点连接数。需要会话保持且要求负载均衡的业务。FOFirst Overflow首次溢出阈值式调度算法。为每台 RS 设置最大连接阈值服务器连接数未达阈值时请求固定分配达到阈值后新请求溢出分配至其他空闲节点。精准控制单节点最大负载避免单服务器过载。单节点负载上限固定、需要严格限流的集群。OVOverflow溢出调度FO 算法增强版动态监控节点负载阈值优先保证核心节点负载稳定超出负载的请求统一溢出至备用节点集群容错性更强有效规避集群单点过载问题。高可用、高稳定性要求的核心业务集群。5.3LVS 核心算法选型总结默认通用首选WLC加权最少连接动态、均衡最优硬件一致集群RR纯轮询、平均分配硬件参差集群WRR加权轮询、适配性能差异需要会话保持SH / BLH源IP哈希绑定客户端缓存集群场景LBLC / LBLCR本地缓存优先、提升命中率低延时高并发场景SED / NQ优先分配低负载空闲节点6.LVS多端口轮询问题复现以及解决方案6.1环境设定一.配置IP以及网关本实验在lvs-nat模式下进行名称IP网关设定调度器nat模式 172.25.254.100仅主机模式192.168.0.100服务器1号仅主机模式192.168.0.10192.168.0.100服务器2号仅主机模式192.168.0.20192.168.0.100客户端nat模式172.25.254.50调度器1号服务器2号服务器4.客户端二.调度器中的环境设定开启ipvsadm服务三.1号服务器2号服务器以及客户端的环境设定1.在1号2号服务器和客户端中同时开始http和https协议2.在1号和2号服务器中设定访问业务真实数据注设定后需要重启httpd服务1号服务器2号服务器6.2.问题复现1.在调度器中编写http和https的轮询策略2.使用客户端访问调度器可以看出使用两个不同的端口进行访问会出现轮询的调度错误正常情况下应该是一个访问sr1一个访问sr2但图中却是访问的同一个服务器。6.3.解决方案使用火墙标记访问vip的80和443的所有数据包设定标记为6666然后对此标记进行负载1.在调度器中编写防火墙标记2.在客户端进行测试原理防火墙根据数据包目的端口在内核给 skb 打上本地 mark 标记让 LVS 依据不同标记区分集群实现同一 VIP 多端口各自独立轮询转发7.lvs的会话粘滞解决方案7.1.lvs会话粘滞的应用场景会话存在本机内存 Tomcat、PHP 程序会话存在服务器内存切后端就掉线、需要重复登录没有用 Redis 共享 Session。长连接业务 WebSocket、直播流、FTP、大文件持续上传调度切换节点直接中断连接。业务上下文绑定节点 单机缓存、临时任务、进程内锁、本地临时文件换节点上下文丢失。非幂等请求 提交订单、表单提交请求重试时分到不同服务器容易产生重复数据。7.2.解决方案1.在调度器中编写ipvs策略[rootvsnode ~]# ipvsadm -A -f 6666 -s rr -p 1 [rootvsnode ~]# ipvsadm -Ln IP Virtual Server version 1.2.1 (size4096) 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:02.测试在客户机上访问 192.168.0.100[rootgoodboy ~]# curl 192.168.0.100 192.168.0.10-sr1 [rootgoodboy ~]# curl 192.168.0.100 192.168.0.10-sr1经过编写ipvs协议之后客户机连续访问调度机包都打到了同一台服务器上实现了lvs的会话粘滞。