标签:负载均衡算法
众所周知,作为新一代应用交付产品的Citrix Netscaler具有业内领先的数据控制、应用交付的能力,然而作为根本内容之一的ADC功能,如果不具备强大的、多元化的均衡算法是不可能适应如此众多的应用场景,更无法做到好的应用交付产品。因此我们在此讨论一下比较常用的负载均衡算法就很有必要。
目前最新版本的Netscaler支持17种均衡算法,目前先讨论最常用的12种
1、轮询算法(Round Robin)
当NetScaler 使用轮询的负载均衡算法时,它会将来自客户端的请求轮流分配给后台中的服务器,从1开始,直到N(后台服务器个数),然后重新开始循环。
如果考虑后台服务器的处理能力不同,可以给每个服务器分配不同的权值,通过设置权重比率来调整循环调度的机率。
2、最少连接算法(Least Connection)
当NetScaler 使用最小连接的负载均衡算法时,它是把新的连接请求分配到当前连接数最小的服务器。最小连接算法是一种动态调度算法,它通过服务器当前所活跃的连接数来估计服务器的负载情况。系统会记录各个服务器已建立连接的数目,当一个请求被调度到某台服务器时,其连接数加1,当连接中止,其连接数减一。
如果考虑后台服务器的处理能力不同,也可以给每个服务器分配不同的权值,通过设置权重比率来调整最小连接算法的调度机率。
3、最少响应时间
当NetScaler 使用最小响应时间的负载均衡算法时,它是把新的连接请求分配到当前连接数最小并且平均响应时间最小的服务器。最小响应时间算法的调度因素实际上有两个部分组成,即当前每服务器上的最小连接数和每服务器的平均响应时间(这里的平均响应时间为TTFB,即第一个字节到达的时间,对于Http协议为response code为200的第一个字节数据返回的时间),这两个因子的乘积做为算法调度的判断依据。最新的连接请求将被发送到最小连接数和平均响应时间乘积最小的服务器。
如果考虑后台服务器的处理能力不同,也可以给每个服务器分配不同的权值,通过设置权重比率来调整最小享用时间算法的调度机率。
4、最小带宽算法(Least Bandwidth)
当NetScaler 使用最小带宽的负载均衡算法时,它是把新的连接请求分配到当前流量吞吐(单位为bps)最小的服务器。
如果考虑后台服务器的处理能力不同,也可以给每个服务器分配不同的权值,通过设置权重比率来调整最小带宽算法的调度机率。
5、最少数据包算法(Least Packets)
当NetScaler 使用最少数据包的负载均衡算法时,它是把新的连接请求分配到数据包最少的服务器。计算最小数据包的方法是过去14秒每个服务器上处理的数据包数量。
如果考虑后台服务器的处理能力不同,也可以给每个服务器分配不同的权值,通过设置权重比率来调整最少数据包算法的调度机率。
6、令牌算法(Token)
当NetScaler 使用令牌负载均衡算法时,它分发新的连接请求将依据客户端请求中所附带的令牌(Token)信息,具备相同令牌的请求将会分配到相同的后台服务器。令牌算法是一种基于内容信息的调度算法,NetScaler可设置令牌(Token)所在的位置和尺寸,这样通过搜索到相同的令牌,而将请求发往相同的后台服务器。
令牌算法可以应用到TCP、http和Https服务类型,甚至可以实现不同的服务之间的唯一性。对于Http/Https协议,令牌(Token)可以在Http header或URL或Http body中取得。Netscaler可以在TCP Payload前最多24K字节中搜索配置的Token,如果是非Http服务,Netscaler可以在最多前16个数据包中中搜索配置的令牌(Token),但不能超过24K字节。
7、URL Hash算法
URL散列(Hash)负载均衡算法常用于缓存(Cache)环境,当NetScaler 使用URL散列(Hash)负载均衡算法时,NetScaler通过一个散列(Hash)函数将此连接请求的URL信息进行计算并将计算值缓存在系统中,同时映射到后台某个服务器。随后基于URL信息做为散列键(Hash Key)进行Hash计算得到相同值的请求,均发送到这个后台服务器。
8、域名 Hash算法
当NetScaler 使用域名散列(Hash)负载均衡算法时,NetScaler通过一个散列(Hash)函数将此连接请求的域名(Domain)信息进行计算并将计算值缓存在系统中,同时映射到后台某个服务器。随后基于域名信息做为散列键(Hash Key)进行Hash计算得到相同值的请求,均发送到这个后台服务器。
9、源IP地址 Hash算法
当NetScaler 使用源IP地址散列(Hash)负载均衡算法时,NetScaler通过一个散列(Hash)函数将此连接请求的源IP地址信息进行计算并将计算值缓存在系统中,同时映射到后台某个服务器。随后基于源IP地址做为散列键(Hash Key)进行Hash计算得到相同值的请求,均发送到这个后台服务器。
10、目的IP地址Hash算法
当NetScaler 使用目的IP地址散列(Hash)负载均衡算法时,NetScaler通过一个散列(Hash)函数将此连接请求的目的IP地址信息进行计算并将计算值缓存在系统中,同时映射到后台某个服务器。随后基于目的IP地址做为散列键(Hash Key)进行Hash计算得到相同值的请求,均发送到这个后台服务器。
11、源IP和目的IP地址 hash算法
当NetScaler 使用源IP和目的IP地址散列(Hash)负载均衡算法时,NetScaler通过一个散列(Hash)函数将此连接请求的源IP地址和目的IP地址信息进行计算并将计算值缓存在系统中,同时映射到后台某个服务器。随后基于源IP地址和目的IP地址做为散列键(Hash Key)进行Hash计算得到相同值的请求,均发送到这个后台服务器。
源IP地址和目的IP地址散列(Hash)算法常应用在防火墙集群负载均衡环境中,它们可以保证流量出入的唯一性。
12、自定义的基于SNMP的判断算法(Custom Load)
当NetScaler 使用自定义负载均衡算法时,NetScaler按照自定义策略通过SNMP协议获取相关服务器运行参数,例如CPU利用率、内存使用、服务器连接和响应时间等多种信息,最终通过预先策略设定的参数矩阵(metric)来决定新的连接请求发送给哪一台后台服务器。
也许有人会问怎么Netscaler不支持加权算法?在其他ADC里面加权会作为一种单独的算法出现,也就只能支持一两种而已。但是在Netscaler,加权是在service的设定,会和其他已有的算法结合,从某种程度上讲就变成更多的算法,也就变成了12+12加权=24种均衡算法。下面仅以最小连接的加权来讨论
最小连接数
当NetScaler 使用最小连接的负载均衡算法时,它是把新的连接请求分配到当前连接数最小的服务器。最小连接算法是一种动态调度算法,它通过服务器当前所活跃的连接数来估计服务器的负载情况。系统会记录各个服务器已建立连接的数目,当一个请求被调度到某台服务器时,其连接数加1,当连接中止,其连接数减一。
如果考虑后台服务器的处理能力不同,也可以给每个服务器分配不同的权值,通过设置权重比率来调整最小连接算法的调度机率。
无权重参与
service1权重=4 | ||
servcie2权重=2 | ||
NW=当前连接数*(10000/权重) | ||
service1NW=连接数*2500 | ||
service2NW=连接数*5000 |
加入权重后请求的分配情况
请求数 | service1 NW | service2 NW | 当前NW |
0 | 0 | 0 | 0 |
1 | 2500 | 0 | 2500 |
2 | 2500 | 5000 | 5000 |
3 | 5000 | 5000 | 10000 |
4 | 5000 | 10000 | 12500 |
5 | 7500 | 10000 | 17500 |
6 | 10000 | 10000 | 20000 |
7 | 10000 | 15000 | 22500 |
8 | 12500 | 15000 | 27500 |
9 | 15000 | 15000 | 30000 |
10 | 15000 | 20000 | 32500 |
11 | 17500 | 20000 | 37500 |
12 | 20000 | 20000 | 40000 |
13 | 20000 | 25000 | 42500 |
14 | 22500 | 25000 | 45000 |
15 | 25000 | 25000 | 47500 |
16 | 25000 | 30000 | 50000 |
17 | 27500 | 30000 | 55000 |
18 | 30000 | 30000 | 57500 |
19 | 30000 | 35000 | 60000 |
注释:
当service的NW相同的时候遵循轮询算法,这也是导致在第一个周期与权重比例有所不同的原因所在。
当前NW的计算方法:NW=当前连接数*(10000/权重)但在计算系统当前NW(不是service的NW)时会利用上次索取Service的权重来进行计算。例如请求3-》4,由于请求3落在service1,servcie1的权重是4(10000/4=2500)那么在计算第4个请求的NW就用上次NW+10000/权重=12500。在4-》5的时候由于上次落在了service2上,那计算第5个请求的NW就用上次NW+10000/权重(用servcie2的权重)=17500。
为了明确看出权重的影响,下表以1:5的权重来体现
service1权重=5 | ||
servcie2权重=1 | ||
NW=当前连接数*(10000/权重) | ||
service1NW=连接数*2000 | ||
service2NW=连接数*10000 |
请求数 | service1 NW | service2 NW | 当前NW |
0 | 0 | 0 | 0 |
1 | 2000 | 0 | 2000 |
2 | 2000 | 10000 | 4000 |
3 | 4000 | 10000 | 14000 |
4 | 6000 | 10000 | 16000 |
5 | 8000 | 10000 | 18000 |
6 | 10000 | 10000 | 20000 |
7 | 10000 | 20000 | 22000 |
8 | 12000 | 20000 | 32000 |
9 | 14000 | 20000 | 34000 |
10 | 16000 | 20000 | 36000 |
11 | 18000 | 20000 | 38000 |
12 | 20000 | 20000 | 40000 |
13 | 20000 | 30000 | 42000 |
14 | 22000 | 30000 | 52000 |
15 | 24000 | 30000 | 54000 |
16 | 26000 | 30000 | 56000 |
17 | 28000 | 30000 | 58000 |
18 | 30000 | 30000 | 60000 |
19 | 32000 | 30000 | 62000 |
本文出自 “Citrix_Caojin” 博客,请务必保留此出处http://caojin.blog.51cto.com/12564439/1926308
标签:负载均衡算法
原文地址:http://caojin.blog.51cto.com/12564439/1926308