【HAProxy06】企业级反向代理HAProxy调度算法之其他算法

HAProxy 调度算法

HAProxy通过固定参数

balance 指明对后端服务器的调度算法,该参数可以配置在listen或backend选项中。

HAProxy的调度算法分为静态和动态调度算法,但是有些算法可以根据不同的参数实现静态和动态算法 相互转换。

官方文档:

HAProxy version 2.4.15 - Configuration Manualhttp://cbonte.github.io/haproxy-dconv/2.4/configuration.html#4-balance

其他算法

source 算法

源地址hash,基于用户源地址hash并将请求转发到后端服务器,后续同一个源地址请求将被转发至同一个后端web服务器。此方式当后端服务器数据量发生变化时,会导致很多用户的请求转发至新的后端服务器,默认为静态方式,但是可以通过hash-type选项进行更改

这个算法一般是在不插入Cookie的TCP模式下使用,也可给不支持会话cookie的客户提供会话粘性,适用于需要session会话保持但不支持cookie和缓存的场景

源地址有两种转发客户端请求到后端服务器的服务器选取计算方式,分别是取模法和一致性hash

map-base 取模法

map-based:取模法,对source地址进行hash计算,再基于服务器总权重的取模,最终结果决定将此请求转发至对应的后端服务器。

此方法是静态的,即不支持在线调整权重,不支持慢启动,可实现对后端服务器均衡调度。缺点是当服务器的总权重发生变化时,即有服务器上线或下线,都会因总权重发生变化而导致调度结果整体改变,hash-type 指定的默认值为此算法

复制代码
所谓取模运算,就是计算两个数相除之后的余数,10%7=3, 7%4=3

map-based算法:基于权重取模,hash(source_ip)%所有后端服务器相加的总权重

取模法配置示例:

复制代码
listen  web_host
  bind 10.0.0.7:80,:8801-8810,10.0.0.7:9001-9010
  mode tcp
  log global
  balance source
  hash-type map-based 
  server web1  10.0.0.17:80 weight 1  check inter 3000 fall 2 rise 3
  server web2  10.0.0.27:80 weight 1  check inter 3000 fall 2 rise 3
 #不支持动态调整权重值
[root@haproxy ~]#echo "set weight web_host/10.0.0.27 10" | socat stdio 
/var/lib/haproxy/haproxy.sock 
Backend is using a static LB algorithm and only accepts weights '0%' and '100%'.
 #只能动态上线和下线
[root@haproxy ~]#echo "set weight web_host/10.0.0.27 0" | socat stdio 
/var/lib/haproxy/haproxy.sock 
[root@haproxy conf.d]#echo "get weight web_host/10.0.0.27" | socat stdio 
/var/lib/haproxy/haproxy.sock 
0 (initial 1)
一致性 hash

一致性哈希,当服务器的总权重发生变化时,对调度结果影响是局部的,不会引起大的变动, hash(o)mod n ,该hash算法是动态的,支持使用 socat等工具进行在线权重调整,支持慢启动

算法:

1、key1=hash(source_ip)%(2^32) 0---4294967295

2、keyA=hash(后端服务器虚拟ip)%(2^32)

3、将key1和keyA都放在hash环上,将用户请求调度到离key1最近的keyA对应的后端服务器

hash环偏斜问题

增加虚拟服务器IP数量,比如:一个后端服务器根据权重为1生成1000个虚拟IP,再hash。而后端服务器权

重为2则生成2000的虚拟IP,再进行hash运算,最终在hash环上生成3000个节点,从而解决hash环偏斜问题

一致性hash配置示例

listen web_host

bind 10.0.0.7:80,:8801-8810,10.0.0.7:9001-9010

mode tcp

log global

balance source

hash-type consistent

server web1 10.0.0.17:80 weight 1 check inter 3000 fall 2 rise 5

server web2 10.0.0.27:80 weight 1 check inter 3000 fall 2 rise 5

uri 算法

基于对用户请求的URI的左半部分或整个uri做hash,再将hash结果对总权重进行取模后,根据最终结果 将请求转发到后端指定服务器,适用于后端是缓存服务器场景,默认是静态算法,也可以通过hash-type 指定map-based和consistent,来定义使用取模法还是一致性hash。

注意:此算法基于应用层,所以只支持 mode http ,不支持 mode tcp

<scheme>://<user>:<password>@<host>:<port>/<path>;<params>?<query>#<frag>
左半部分:/<path>;<params>
整个uri:/<path>;<params>?<query>#<frag>

uri 取模法配置示例

listen web_host

bind 10.0.0.7:80,:8801-8810,10.0.0.7:9001-9010

mode http

log global

balance uri

server web1 10.0.0.17:80 weight 1 check inter 3000 fall 2 rise 5

server web2 10.0.0.27:80 weight 1 check inter 3000 fall 2 rise 5

uri 一致性hash配置示例

listen web_host

bind 10.0.0.7:80,:8801-8810,10.0.0.7:9001-9010

mode http

log global

balance uri

hash-type consistent

server web1 10.0.0.17:80 weight 1 check inter 3000 fall 2 rise 5

server web2 10.0.0.27:80 weight 1 check inter 3000 fall 2 rise 5

访问测试

访问不同的uri,确认可以将用户同样的请求转发至相同的服务器

复制代码
# curl  http://10.0.0.7/test1.html
# curl  http://10.0.0.7/test2..html

url_param 算法

url_param对用户请求的url中的 params 部分中的一个参数key对应的value值作hash计算,并由服务器 总权重相除以后派发至某挑出的服务器;通常用于追踪用户,以确保来自同一个用户的请求始终发往同 一个real server,如果无没key,将按roundrobin算法

复制代码
#假设:
url = http://www.wang.com/foo/bar/index.php?key=value 
#则:
host = "www.wang.com"
 url_param = "key=value"
url_param取模法配置示例

listen web_host

bind 10.0.0.7:80,:8801-8810,10.0.0.7:9001-9010

mode http

log global

balance url_param userid

#url_param hash

server web1 10.0.0.17:80 weight 1 check inter 3000 fall 2 rise 5

server web2 10.0.0.27:80 weight 1 check inter 3000 fall 2 rise 5

url_param一致性hash配置示例

listen web_host

bind 10.0.0.7:80,:8801-8810,10.0.0.7:9001-9010

mode http

log global

balance url_param userid

#对url_param的值取hash

hash-type consistent

server web1 10.0.0.17:80 weight 1 check inter 3000 fall 2 rise 5

server web2 10.0.0.27:80 weight 1 check inter 3000 fall 2 rise 5

测试访问

curl http://10.0.0.7/index.html?userid=\<NAME_ID>

curl "http://10.0.0.7/index.html?userid=\<NAME_ID>&typeid=<TYPE_ID>"

hdr 算法

针对用户每个http头部(header)请求中的指定信息做hash,此处由 name 指定的http首部将会被取出并 做hash计算,然后由服务器总权重取模以后派发至某挑出的服务器,如果无有效值,则会使用默认的轮 询调度。

hdr取模法配置示例

listen web_host

bind 10.0.0.7:80,:8801-8810,10.0.0.7:9001-9010

mode http

log global

balance hdr(User-Agent)

#balance hdr(host)

server web1 10.0.0.17:80 weight 1 check inter 3000 fall 2 rise 5

server web2 10.0.0.27:80 weight 1 check inter 3000 fall 2 rise 5

一致性hash配置示例

listen web_host

bind 10.0.0.7:80,:8801-8810,10.0.0.7:9001-9010

mode http

log global

balance hdr(User-Agent)

hash-type consistent

server web1 10.0.0.17:80 weight 1 check inter 3000 fall 2 rise 5

server web2 10.0.0.27:80 weight 1 check inter 3000 fall 2 rise 5

测试访问

root@centos6 \~#curl -v http://10.0.0.7/index.html

root@centos6 \~#curl -vA 'firefox' http://10.0.0.7/index.html

root@centos6 \~#curl -vA 'chrome' http://10.0.0.7/index.html

rdp-cookie对远 Windows远程桌面的负载,使用cookie保持会话,默认是静态,也可以通过hash-type 指定map-based和consistent,来定义使用取模法还是一致性hash。

listen RDP

bind 10.0.0.7:3389

balance rdp-cookie

mode tcp

server rdp0 10.0.0.17:3389 check fall 3 rise 5 inter 2000 weight 1

root@haproxy \~#cat /etc/haproxy/conf.d/windows_rdp.cfg

listen wang_RDP_3389

mode tcp

bind

172.16.0.100:3389

balance rdp-cookie

hash-type consistent

server rdp0 10.0.0.200:3389 check fall 3 rise 5 inter 2000 weight 1

root@haproxy \~#hostname -I

10.0.0.7 172.16.0.100

基于iptables实现RDP协议转发

必须开启ip转发功能: net.ipv4.ip_forward = 1

root@centos8 \~#sysctl -w net.ipv4.ip_forward=1

#客户端和Windows在不同网段需要下面命令,注意后端服务器需要将iptables主机配置为网关

root@centos8 \~#iptables -t nat -A PREROUTING -d 172.16.0.100 -p tcp --dport

3389 -j DNAT --to-destination 10.0.0.200:3389

#客户端和Windows在同一网段需要再执行下面命令

root@centos8 \~#iptables -t nat -A PREROUTING -d 10.0.0.8 -p tcp --dport 3389

j DNAT --to-destination 10.0.0.200:3389

root@centos8 \~#iptables -t nat -A POSTROUTING -s 10.0.0.0/24 -j SNAT --to

source 10.0.0.8

算法总结

复制代码
#静态
static-rr--------->tcp/http  
first------------->tcp/http  
#动态
roundrobin-------->tcp/http 
leastconn--------->tcp/http 
random------------>tcp/http
 #以下静态和动态取决于hash_type是否consistent
source------------>tcp/http
Uri--------------->http
url_param--------->http     
hdr--------------->http
rdp-cookie-------->tcp


#各种算法使用场景
first       #使用较少

static-rr   #做了session共享的 web 集群
roundrobin
random
leastconn   #数据库
source      #基于客户端公网 IP 的会话保持

Uri--------------->http  #缓存服务器,CDN服务商,蓝汛、百度、阿里云、腾讯
url_param--------->http  #可以实现session保持
hdr         #基于客户端请求报文头部做下一步处理
rdp-cookie  #基于Windows主机,很少使用
相关推荐
Avan_菜菜13 小时前
FRP 内网穿透完整实战:从 HTTP 映射到 HTTPS 自签代理
运维·nginx·https
SelectDB2 天前
Litefuse 开源并推出单进程轻量模式,25 秒就能跑起来的 Agent 可观测与评估平台
运维·后端·自动化运维
XIAOHEZIcode3 天前
Linux系统鼠标偏移常见原因以及修复方案
linux·运维·游戏
用户0328472220704 天前
如何搭建本地yum源(上)
运维
ping某5 天前
为什么 Nginx 明明监听了 80,转发后端时却用了 4xxxx 端口?
后端·nginx
大树887 天前
金刚石散热越强,管路越先见顶
大数据·运维·服务器·人工智能·ai
摇滚侠7 天前
Linux CentOS7 rpm 安装 MySQL 5.7
linux·运维·mysql
霸道流氓气质7 天前
领域驱动设计(DDD)在 Spring Boot 微服务中的实践指南
运维·spring boot·微服务
Inhand陈工7 天前
基于台达PLC与映翰通IG502的智慧水产养殖精准投喂与远程运维解决方案
运维·人工智能·物联网·阿里云·信息与通信
酣大智7 天前
ARP代理--工作原理
运维·网络·arp·arp代理