LVS负载均衡（6）--LVS调度算法详解

---

目录

• 1. LVS调度算法详解
  • 1.1 静态调度算法
    • 1.1.1 RR调度算法
    • 1.1.2 WRR调度算法
    • 1.1.3 SH调度算法
    • 1.1.4 DH调度算法
  • 1.2 动态调度算法
    • 1.2.1 LC调度算法
    • 1.2.2 WLC调度算法
    • 1.2.3 SED调度算法
    • 1.2.4 NQ调度算法
    • 1.2.5 LBLC调度算法
    • 1.2.6 LBLCR调度算法

---

1. LVS调度算法详解

1.1 静态调度算法

静态：仅根据算法本身进行调度，不考虑后端实际负载情况（起点公平）。

1.1.1 RR调度算法

RR：round robin 轮询调度算法，将每一次用户的请求，轮流分配给 Real Server节点。

LVS配置示例：

[root@lvs-01 ~]# ipvsadm -A -t 192.168.50.100:80 -s rr
[root@lvs-01 ~]# ipvsadm -A -t 192.168.50.100:443 -s rr
[root@lvs-01 ~]# ipvsadm -a -t 192.168.50.100:80 -r 192.168.50.22:80 -g
[root@lvs-01 ~]# ipvsadm -a -t 192.168.50.100:80 -r 192.168.50.23:80 -g
[root@lvs-01 ~]# ipvsadm -a -t 192.168.50.100:443 -r 192.168.50.22:443 -g
[root@lvs-01 ~]# ipvsadm -a -t 192.168.50.100:443 -r 192.168.50.23:443 -g

[root@lvs-01 ~]# 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.50.100:80 rr
  -> 192.168.50.22:80             Route   1      0          0
  -> 192.168.50.23:80             Route   1      0          0
TCP  192.168.50.100:443 rr
  -> 192.168.50.22:443            Route   1      0          0
  -> 192.168.50.23:443            Route   1      0          0

1.1.2 WRR调度算法

WRR：weighted round robin 加权轮询调度算法，根据服务器的硬件情况、以及处理能力，为每台服务器分配不同的权值，使其能够接受相应权值的请求。

LVS配置示例：

#修改调度算法为wrr以及RS的权重
[root@lvs-01 ~]# ipvsadm -E -t 192.168.50.100:80 -s wrr
[root@lvs-01 ~]# ipvsadm -E -t 192.168.50.100:443 -s wrr
[root@lvs-01 ~]# ipvsadm -e -t 192.168.50.100:80 -r 192.168.50.22:80 -g -w 1
[root@lvs-01 ~]# ipvsadm -e -t 192.168.50.100:80 -r 192.168.50.23:80 -g -w 3
[root@lvs-01 ~]# ipvsadm -e -t 192.168.50.100:443 -r 192.168.50.22:443 -g -w 1
[root@lvs-01 ~]# ipvsadm -e -t 192.168.50.100:443 -r 192.168.50.23:443 -g -w 3

[root@lvs-01 ~]# 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.50.100:80 rr
  -> 192.168.50.22:80             Route   1      0          0
  -> 192.168.50.23:80             Route   3      0          0
TCP  192.168.50.100:443 rr
  -> 192.168.50.22:443            Route   1      0          0
  -> 192.168.50.23:443            Route   3      0          0 

#2.客户端访问测试：
[root@xuzhichao ~]# for i in {1..10} ;do curl -k -Hhost:www,xuzhichao.com https://192.168.20.50; done
node2.xuzhichao.com page
node2.xuzhichao.com page
node2.xuzhichao.com page
node1.xuzhichao.com page
node2.xuzhichao.com page
node2.xuzhichao.com page
node2.xuzhichao.com page
node1.xuzhichao.com page
node2.xuzhichao.com page
node2.xuzhichao.com page

1.1.3 SH调度算法

SH：Source Hashing 源地址 hash 调度算法，将请求的源 IP 地址进行 Hash 运算，得到一个具体的数值，同时对后端服务器进行编号，按照运算结果将请求分发到对应编号的服务器上。SH算法不能和WRR算法同时使用，配置的RS权重无效。类似于nginx的ip_hash算法。

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

• 2.同时还能实现相同来源 IP 的请求始终被派发至某一台特定的节点；配置示例如下：

#1.修改调度算法为SH，配置的RSweight值无效
[root@lvs-01 ~]# ipvsadm -E -t 192.168.50.100:443 -s sh
[root@lvs-01 ~]# ipvsadm -E -t 192.168.50.100:80 -s sh

[root@lvs-01 ~]# 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.50.100:80 sh
  -> 192.168.50.22:80             Route   1      0          0
  -> 192.168.50.23:80             Route   3      0          0
TCP  192.168.50.100:443 sh
  -> 192.168.50.22:443            Route   1      0          0
  -> 192.168.50.23:443            Route   3      0          0 

#2.客户端访问测试效果，同一个客户端调度到同一台RS服务器：
[root@xuzhichao ~]# for i in {1..10} ;do curl -k -Hhost:www,xuzhichao.com https://192.168.20.50; done
node2.xuzhichao.com page
node2.xuzhichao.com page
node2.xuzhichao.com page
node2.xuzhichao.com page
node2.xuzhichao.com page
node2.xuzhichao.com page
node2.xuzhichao.com page
node2.xuzhichao.com page
node2.xuzhichao.com page
node2.xuzhichao.com page

1.1.4 DH调度算法

DH：destination hash 目标地址 hash 将客户端的请求，始终发往同一个 RS 。类似于nginx的hash $request_uri调度算法。

应用场景： LVS-cache-源站 ，始终调度到指定的 cache ，加速用户体验。

• 客户端1请求视频资源

  • 1LVS通过DH调度算法将请求转发给Cache1节点；
  • 2.Cache1节点没有数据，则会请求源站集群，获取；
  • 3.Cache1节点会将数据直接返回给用户；

• 客户端2请求腾讯资源

  • 1LVS通过DH调度管法将请求转发给Cache1节点；
  • 2.Cache1节点已经有相应的缓存数据，Cache1节点会直接将数据返回给用户(加速用户请求，提高体验度；

• 问题

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

配置示例：

[root@lvs-01 ~]# ipvsadm -E -t 192.168.50.100:80 -s dh
[root@lvs-01 ~]# ipvsadm -E -t 192.168.50.100:443 -s dh
[root@lvs-01 ~]# 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.50.100:80 dh
  -> 192.168.50.22:80             Route   1      0          0
  -> 192.168.50.23:80             Route   3      0          0
TCP  192.168.50.100:443 dh
  -> 192.168.50.22:443            Route   1      0          0
  -> 192.168.50.23:443            Route   3      0          0

1.2 动态调度算法

动态：根据算法及 RS 节点负载状态进行调度，较小的 RS 将被调度（保证结果公平）。

1.2.1 LC调度算法

LC：Least-Connection 最少连接数调度算法，哪台 RS 连接数少就将请求调度至哪台 RS ，类似于nginx的least_con算法。

算法： Overhead = ( Active * 256 + Inactive仅连接 ) 一个活动连接相当于256个非活动连接。

activeconns：建立三次握手，并且有数据在传输；

inactiveconns：三次握手后，没有数据传输；

LC调度算法问题：

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

1.2.2 WLC调度算法

WLC：Weighted Least-Connection 加权最小连接数（默认调度算法），在服务器性能差异较大的情况下，采用“加权最少链接”调度算法优化负载均衡性能，权值较高的 RS 节点，将承受更多的连接；负载均衡可以自动问询 RS 节点服务器的负载状态，通过算法计算当前连接数最少的节点，而后将新的请求调度至该节点。

算法： Overhead =（ Active * 256 + Inactive ）/Weight

WLC调度算法问题：

• 1.如果是刚搭建LVS，第一次连接，那往哪里调度呢? -->(谁是第一个添加的后端RS就调度给谁)。
• 2.如果第一个添加的RS权重是2，那么他优先响应，是不是就不太合理了。
• 3.假设有3台节点，权重分别为1，2，3，连接数分别为10，20，30，新请求可能被调度到任何1台节点。(三者计算结果一致。)

1.2.3 SED调度算法

SED：Shortest Expected Delay 最短期望延迟，尽可能让权重高的优先接收请求，不再考虑非活动状态，把当前处于活动状态的数目+1，通过算法计算当前连接数最少的节点，而后将新的请求调度至该节点。

算法：在WLC基础上改进， Overhead = （ACTIVE+1）*256/Weight

1.2.4 NQ调度算法

NQ：Never Queue 永不排队/最少队列调度

• 原理： SED 算法存在的问题是，由于某台服务器的权重较小，比较空闲，甚至接收不到请求，而权重大的服务器会很忙，而 NQ 算法是说不管权重多大都会被分配到请求。简单来说，就是无需队列，如果有台 Real Server 的连接数为0会直接分配过去，后续采用 SED 算法。

• 算法： Overhead = （ACTIVE+1）*256/Weight

1.2.5 LBLC调度算法

LBLC：Locality-Based Least-Connection 动态目标地址 hash 调度算法，解决 DH调度算法负载不均衡问题。

应用场景： LVS-cache-源站 ，此前 DH 算法始终调度到后端 Cache1 节点，会造成Cache1 负载过高， LBLC 会根据后端服务器负载情况，动态调度到后端其他 Cache 节点。

• 客户端1请求视频资源
  • 1.LVS通过LBLC调度算法将请求转发给Cache1节点；
  • 2.Cachel节点没有数据，则会请求源站售群，获取资源；
  • 3.Cache1节点会将数据直接返回给用户；
• 客户端2请求视频资源
  • 1.LVS检查发现Cache1节点压力过大，会将请求转发给Cache2节点；
  • 2.由于Cache2节点没有数据，则会请求源站获取资源；
  • 3.Cache2节点会将数据直接饭回给用户；
• 问题:
  • 如果大量的用户请求，由于Cache1节点压力过大，则被调度到Cache2节点，Cache2节点没有缓存，岂不是又得缓存一次?

1.2.6 LBLCR调度算法

LBLCR： Locality-Based Least-Connection with Replication 带复制功能的LBLC算法，解决LBLC负载不均衡的问题，从负载重的复制到负载轻的RS。

应用场景： LVS-cache-源站 ，此前 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.所以无论被客户端被调度到哪个节点处理，都能直接将数据返回给用户，而无需在次请求源站；