静态调度算法:

仅根据算法本身进行调度


RR: 轮询调度(Round Robin)

调度器通过“轮询”调度算法将外部请求按顺序轮流分配到集群中的真实服务器上,它均等地对待每一台服务器,而不管服务器上实际的连接数和系统负载。属于大锅饭调度。

此种均衡算法适合于服务器组中的所有服务器都有相同的软硬件配置并且平均服务请求相对均衡的情况。


WRR: 加权轮询(Weighted Round Robin)

根据真实服务器的不同处理能力来调度访问请求。这样可以保证处理能力强的服务器能处理更多的访问流量。调度器可以自动问询真实服务器的负载情况,并动态地调整其权值。带权重的大锅饭调度。

此种均衡算法能确保高性能的服务器得到更多的使用率,避免低性能的服务器负载过重。


SH: 源地址哈希(Source Hashing)

根据请求的源IP地址,作为散列键(Hash Key)从静态分配的散列表找出对应的服务器,若该服务器是可用的且未超载,将请求发送到该服务器。基于client地址的来源区分。实现session sticky。


DH: 目标地址哈希(Destination Hashing)

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


动态调度算法:

主要根据每RS当前的负载状态及调度算法进行调度


LC: 最少链接(Least Connections)

动态地将网络请求调度到已建立的链接数最少的服务器上。如果集群系统的真实服务器具有相近的系统性能,采用“最小连接”调度算法可以较好地均衡负载。谁不干活就给谁分配

此种均衡算法适合长连接处理的请求服务,如FTP。


WLC: 加权最少链接(Weighted Least Connections)

默认调度方法。在集群系统中的服务器性能差异较大的情况下,调度器采用此调度算法优化负载均衡性能,具有较高权值的服务器将承受较大比例的活动连接负载。调度器可以自动问询真实服务器的负载情况,并动态地调整其权值。带权重的谁不干活就给谁分配,机器配置好的权重高


SED: 初始连接高权重优先(Shortest Expected Delay Scheduling SED)

基于wlc算法。一个新的初始链接的时候,优先分配权重高的服务器。缺陷:当权重过大的时候,会导致空闲服务器一直处于无连接状态


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

第一轮均匀分配,后续SED。无需队列。如果有台 RealServer的连接数=0 就直接分配过去,不需要再进行sed运算,保证不会有一个主机很空闲。不考虑非活动连接,才用NQ,SED要考虑活动状态连接,对于DNS的UDP不需要考虑非活动连接,而httpd的处于保持状态的服务就需要考虑非活动连接给服务器的压力。


LBLC: 基于局部性的最少链接(Locality-Based Least Connections)

动态的DH算法,使用场景:根据负载状态实现正向代理

针对目标IP地址的负载均衡,目前主要用于Cache集群系统。该算法根据请求的目标IP地址找出该目标IP地址最近使用的服务器,若该服务器是可用的且没有超载,将请求发送到该服务器;若服务器不存在,或者该服务器超载且有服务器处于一半的工作负载,则用“最少链接” 的原则选出一个可用的服务器,将请求发送到该服务器。基于本地的最小连接。把请求传递到负载小的服务器上


LBLCR: 带复制的基于局部性最少链接(Locality-Based Least Connections with Replication)

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

针对目标IP地址的负载均衡,目前主要用于Cache集群系统。它与LBLC算法的不同之处是它要维护从一个目标 IP地址到一组服务器的映射,而LBLC算法维护从一个目标IP地址到一台服务器的映射。该算法根据请求的目标IP地址找出该目标IP地址对应的服务器组,按“最小连接”原则从服务器组中选出一台服务器,若服务器没有超载,将请求发送到该服务器;若服务器超载,则按“最少链接”原则从这个集群中选出一台服务器,将该服务器加入到服务器组中,将请求发送到该服务器。同时,当该服务器组有一段时间没有被修改,将最忙的服务器从服务器组中删除,以降低复制的程度。

某页面缓存在服务器A上,被访问次数极高,而其他缓存服务器负载较低,监视是否访问同一页面,如果是访问同一页面则把请求分到其他服务器。


下面列举一些针对不同环境个人采用的模式和调度算法:

1. 如果后端服务器的配置相同,而且台数不多的话

可以使用LVS三种模式中的任意一种,调度算法可以是RR


2. 如果后端服务器的配置相同,但是台数很多的话

可以使用LVS-DR或者LVS-TUN模式,调度算法可以是RR


3. 如果后端服务器的配置相同,但是台数很多

而且服务器分布在不同的局域网中,那么使用LVS-TUN模式,调度算法可以是RR


4. 如果后端服务器的配置不同,而且台数不多的话

可以使用LVS三种模式中的任意一种,调度算法可以是WRR


5. 如果后端服务器的配置不同,但是台数很多的话

可以使用LVS-DR或者LVS-TUN模式,调度算法可以是WRR


6. 如果后端服务器的配置不同,但是台数很多

而且服务器分布在不同的局域网中,那么使用LVS-TUN模式,调度算法可以是WRR


7. 如果后端服务器使用了cache系统

可以使用LVS-DR或者LVS-TUN模式,调度算法可以是LBLC或者LBLCR


8. 如果后端服务器使用了cache系统且架构体系庞大,使用LVS-TUN模式,调度算法是LBLCR


9. 如果后端服务器为集群且性能差异大,使用LVS-DR或者LVS-TUN模式,调度算法采用WLC


10. 如果后端服务器为集群且性能差异不大,使用lvs/dr或者LVS-TUN模式,调度算法采用LC


以上几种情况只是个人的理解,建议还是大家根据实际环境、需求等众多因素,采用适合的模式及调度算法,每个公司的体系、环境、需求是不一样的,只有灵活的运用才能找到合适的体系。没有最好的只有最适合的。