cbear
large picture of the cover

2-3-LVS负载调度算法

ipvs scheduler : 根据其调度时是否考虑各RS当前的负载状态分为两种: 静态方法和动态方法

1. 静态方法

仅根据算法本身进行调度

  1. 轮询(Round Robin, rr) 调度器通过"轮询"调度算法将外部请求按顺序轮流分配到集群中的真实服务器上 , 它均等地对待每一台服务器 , 而不管服务器上实际的连接数和系统负载。

  2. 加权轮询(Weighted Round Robin , wrr) 调度器通过"加权轮询"调度算法根据真实服务器的不同处理能力来调度访问请求。这样可以保证处理能力强的服务器处理更多的访问流量。调度器可以自动问询真实服务器的负载情况 , 并动态地调整其权值。

  3. 目标地址散列 (Destination Hashing, DH) "目标地址散列"调度算法根据请求的目标IP地址 , 作为散列键（Hash Key）从静态分配的散列表找出对应的服务器 , 若该服务器是可用的且未超载 , 将请求发送到该服务器 , 否则返回空。

    请求过程说明

    • 客户端1请求视频资源

      1. LVS通过DH调度算法将请求转发给Cache1节点 ;

      2. Cache1节点没有数据 , 则会请求源站集群 , 获取 ;

      3. Cache1节点会将数据直接返回给用户 ;

    • 客户端2请求腾讯资源

      1. LVS通过DH调度管法将请求转发给Cache1节点；

      2. Cache1节点已经有相应的缓存数据 , Cache1节点会直接将数据返回给用户(加速用户请求 , 提高体验度；

    • 问题

      • 如果大量的用户都转发到Cache1 , 则会造成Cache1节点压力过大 , 而其他Cache节点无任何压力；

  4. 源地址散列 (Source Hashing ,SH) "源地址散列"调度算法根据请求的源IP地址 , 作为散列键(Hash Key)从静态分配的散列表找出对应的服务器 , 若该服务器是可用的且未超载 , 将请求发送到该服务器 , 否则返回空。

    • 可以实现不同来源 IP 的请求进行负载分发；

    • 同时还能实现相同来源 IP 的请求始终被派发至某一台特定的节点；

2. 动态方法

主要根据每RS当前的负载状态及调度算法进行调度Overhead=value 较小的RS将被调度

  1. 最少链接(Least Connections, LC) 调度器通过"最少连接"调度算法动态地将网络请求调度到已建立的链接数最少的服务器上。如果集群系统的真实服务器具有相近的系统性能 , 采用"最小连接"调度算法可以较好地均衡负载。

    Overhead=activeconns*256+inactiveconns

#activeconns: 建立三次握手 , 并且有数据在传输；

#inactiveconns:三次握手后 , 没有数据传输；

    LC调度算法问题:

    • 图中场景 , 通过LC调度算法会发现 , 大部分请求会被RealServer1、RealServer2 性能差的节点处理。因为LC调度算法是谁的连接少就调度给准 , 没有考虑到后端主机的性能。

  2. 加权最少链接 (Weighted Least Connections,WLC ) 在集群系统中的服务器性能差异较大的情况下 , 调度器采用"加权最少链接"调度算法优化负载均衡性能 , 具有较高权值的服务器将承受较大比例的活动连接负载。调度器可以自动问询真实服务器的负载情况 , 并动态地调整其权值。

    Overhead=(activeconns*256+inactiveconns)/weight

    WLC调度算法问题:

    1. 如果是刚搭建LVS , 第一次连接 , 那往哪里调度呢? -->(谁是第一个添加的后端RS就调度给谁)。

    2. 如果第一个添加的RS权重是2 , 那么他优先响应 , 是不是就不太合理了。

    3. 假设有3台节点 , 权重分别为1、2、3 ,连接数分别为10 、20 、30 , 新请求可能被调度到任何1台节点。(三者计算结果一致。)

  3. 最短期望延迟(Shortest Expected Delay, Sed): 初始连接高权重有限。

    Overhead=(activeconns+1)*256/weight

    在WLC基础上改进 , Overhead = （ACTIVE+1）*256加权 , 不再考虑非活动状态 , 把当前处于活动状态的数目+1来实现 , 数目最小的 , 接受下次请求 , +1的目的是为了考虑加权的时候 , 非活动连接过多缺陷 : 当权限过大的时候 , 会导致空闲服务器一直处于无连接状态。

  4. 最少队列调度(Never Queue Scheduling, NQ) :

    无需队列。如果有台realserver的连接数=0就直接分配过去 , 不需要再进行sed运算 , 保证不会有一个主机很空闲。后续采用 SED 算法。在SED基础上无论+几 , 第二次一定给下一个 , 保证不会有一个主机不会很空闲着 , 不考虑非活动连接 , 才用NQ , SED要考虑活动状态连接 , 对于DNS的UDP不需要考虑非活动连接 , 而httpd的处于保持状态的服务就需要考虑非活动连接给服务器的压力。

  5. 基于局部性的最少链接(Locality-Based Least Connections, LBLC) "基于局部性的最少链接" 调度算法是针对目标IP地址的负载均衡 , 目前主要用于Cache集群系统。该算法根据请求的目标IP地址找出该目标IP地址最近使用的服务器 , 若该服务器 是可用的且没有超载 , 将请求发送到该服务器；若服务器不存在 , 或者该服务器超载且有服务器处于一半的工作负载 , 则用"最少链接"的原则选出一个可用的服务 器 , 将请求发送到该服务器。

    解决 DH调度算法负载不均衡问题。此前 DH算法始终调度到后端 Cache 节点 , 会造成Cache1负载过高 , LBLC会根据后端服务器负载情况 , 动态调度到后端其他Cache节点。

    image

    请求过程说明

    • 客户端1请求视频资源

      1. LVS通过LBLC调度算法将请求转发给Cache1节点 ;

      2. Cache1节点没有数据 , 则会请求源站授权 ,获取资源；

      3. Cache1节点会将数据直接返回给用户；

    • 客户端2请求视频资源

      1. LVS检查发现Cache1节点压力过大 , 会将请求转发给Cache2节点 ;

      2. 由于Cache2节点没有数据 , 则会请求源站获取资源 ;

      3. Cache2节点会将数据直接返回给用户；

    • 问题:

      • 如果大量的用户请求 , 由于Cache1节点压力过大 , 则被调度到Cache2节点 , Cache2节点没有缓存 , 岂不是又得缓存一次?

  6. 带复制的基于局部性最少链接(Locality-Based Least Connections with Replication, LBLCR） "带复制的基于局部性最少链接"调度算法也是针对目标IP地址的负载均衡 , 目前主要用于Cache集群系统。它与LBLC算法的不同之处是它要维护从一个 目标IP地址到一组服务器的映射 , 而LBLC算法维护从一个目标IP地址到一台服务器的映射。该算法根据请求的目标IP地址找出该目标IP地址对应的服务器组 , 按"最小连接"原则从服务器组中选出一台服务器 , 若服务器没有超载 , 将请求发送到该服务器 , 若服务器超载；则按"最小连接"原则从这个集群中选出一 台服务器 , 将该服务器加入到服务器组中 , 将请求发送到该服务器。同时 , 当该服务器组有一段时间没有被修改 , 将最忙的服务器从服务器组中删除 , 以降低复制的 程度。

    解决LBLC负载不均衡的问题 , 从负载重的复制到负载轻的RS。

    此前LBLC算法始终调度到后端Cache1节点 , 会造成Cache1负载过高 , 会根据负载均衡动态调度到后端其他Cache节点 , 同时也会将缓存数据同步一份至Cache1、Cache2 节点。

    请求过程说明

    • 客户端1请求视频资源

      1. LVS通过LBLCR调度算法将请求转发给Cache1节点 ;

      2. Cache1节点没有数据 , 则会请求源站集群获取数据 ;

      3. Cache1节点会将缓存的数据直接返回给用户 ;

      4. Cache1节点会将缓存数据同步至Cache2节点、Cache3节点 ;

    • 客户端2请求视频资源

      1. LVS检查发现Cache1节点压力过大 , 会将请求调度至Cache2或Cache3节点 ;

      2. Cache2、Cache3节点已经有Cache1同步的缓存数据 ;

      3. 所以无论被客户端被调度到哪个节点处理 ,都能直接将数据返回给用户 , 而无需在次请求源站 ;

3. 内核4.15 版本后新增调度算法:FO和OVF

FO(Weighted Fail Over) 调度算法, 在此处FO算法中, 遍历虚拟服务所关联的真实服务器链表, 找到还未加载(未设置IP_VS_DEST_F_OVERLOAD标志)的且权重最高的真实服务器,进行调度。不关心活动链接数, 只关系服务器的权重, 以及是否有过载标记位, 类似静态算法

OVF(Overflow-connection)调度算法, 基于真实服务器的活动连接数量和权重值实现。将新连接调度到权重值最高的真实服务器, 直到其活动连接数量超过权重值, 之后调度到下一个权重值最高的真实服务器, 在此OVF算法中, 遍历虚拟服务相关联的真实服务器链表, 找到权重值最高的可用真实服务器。 属于动态的FO算法.

一个可用的真实服务器需要同时满足以下条件:

  • 未过载(未设置IP_VS_DEST_F_OVERLOAD标志) ,如果过载, 会设置IP_VS_DEST_F_OVERLOAD标记 。 或者当某个RS服务器需要做升级或维护时 , 可以加IP_VS_DEST_F_OVERLOAD标记 , 让其不会调度 , 等到升级或维护完成 , 再继续调度

  • 真实服务器当前的活动连接数量小于其权重值

  • 其权重值不为零

参考链接

LVS负载均衡（LVS简介、三种工作模式、十种调度算法）chenhuyang的博客-CSDN博客lvs

Linux服务器集群系统(一) -- LVS项目介绍 (linuxvirtualserver.org)

Linux服务器集群系统(二)--LVS集群的体系结构 (linuxvirtualserver.org)

Linux服务器集群系统(三)--LVS集群中的IP负载均衡技术 (linuxvirtualserver.org)

超详细！一文带你了解 LVS 负载均衡集群！_腾讯新闻 (qq.com)

25. LVS：防火墙标记 (austintek.com)

29. LVS：在控制器上运行防火墙：LVS和网络过滤器（iptables）之间的交互。 (austintek.com)

Fullnat系列（一）：到底什么时候需要用fullnat呢？ (ieevee.com)

深入浅出 LVS 负载均衡（一）NAT、FULLNAT 模型原理 - 知乎 (zhihu.com)

熊熊

site logo

Hi,Friend

© 2026 cbear