HAPROXY的调度算法 |
发表者:admin分类:应用服务2023-01-07 11:05:26 阅读[453] |
System OS: CentOS Linux release 7.8.2003 (Core) 内核:3.10.0-1127.el7.x86_64 web01: node1 10.0.0.201 nginx web02: node2 10.0.0.202 nginx haproxy: node4 192.168.32.204 外网 node4 10.0.0.204 内网 客户机: node3 192.168.32.203
实验环境的部署见《
https://www.cnblogs.com/yaokaka/
yum install -y socat #Socat 是 Linux 下的一个多功能的网络工具,名字来由是Socket CAT,Socat 的主要特点就是在两个数据流之间建立通道,且支持众多协议和链接方式。如 IP、TCP、 UDP、IPv6、Socket文件等。 #查看haproxy的信息 echo "show info" | socat stdio /var/lib/haproxy/haproxy.sock # echo "get weight web_port/web01" | socat stdio /var/lib/haproxy/haproxy.sock 1 (initial 1) echo "set weight web_port/web01 2" | socat stdio /var/lib/haproxy/haproxy.sock Backend is using a static LB algorithm and only accepts weights '0%' and '100%'.
1、静态算法
静态算法:按照事先定义好的规则轮询公平调度,不关心后端服务器的当前负载、链接数和相应速度等,且无法实 时修改权重,只能靠重启HAProxy生效。
static-rr
static-rr:基于权重的轮询调度,不支持权重的运行时调整及后端服务器慢启动,其后端主机数量没有限制
listen web_port bind 192.168.32.204:80 mode http log global balance static-rr server web01 10.0.0.201:80 weight 1 check inter 3000 fall 2 rise 5 server web02 10.0.0.202:80 weight 2 check inter 3000 fall 2 rise 5
重启haproxy
systemctl restart haproxy
测试
[root@node3 ~]# curl 192.168.32.204 web02 10.0.0.202 [root@node3 ~]# curl 192.168.32.204 web02 10.0.0.202 [root@node3 ~]# curl 192.168.32.204 web01 10.0.0.201 #按照权重来分配后端服务器
first:根据服务器在列表中的位置,自上而下进行调度,但是其只会当第一台服务器的连接数达到上限,新请求才 会分配给下一台服务,因此会忽略服务器的权重设置。
listen web_port bind 192.168.32.204:80 mode http log global balance first server web01 10.0.0.201:80 maxconn 2 weight 1 check inter 3000 fall 2 rise 5 server web02 10.0.0.202:80 weight 2 check inter 3000 fall 2 rise 5
重启haproxy
systemctl restart haproxy
测试
[root@node3 ~]# while true;do curl 192.168.32.204 ;sleep 0.1;done web01 10.0.0.201 web01 10.0.0.201 web02 10.0.0.202 web01 10.0.0.201 web01 10.0.0.201 web01 10.0.0.201 web01 10.0.0.201 web02 10.0.0.202 web01 10.0.0.201 #只有在web01服务器连接数达到上限值后,才会把请求分配给web02
动态算法:基于后端服务器 状态进行调度适当调整,比如优先调度至当前负载较低的服务器,且权重可以在 haproxy运行时动态调整无需重启。
直接reload即可
systemctl reload haproxy
roundrobin:基于权重的轮询动态调度算法,支持权重的运行时调整,不完全等于lvs中的rr轮训模式,HAProxy中的roundrobin支持慢启动(新加的服务器会逐渐增加转发数),其每个后端backend中最多支持4095个real server,roundrobin为默认调度算法,且支持对real server权重动态调整。
listen web_port bind 192.168.32.204:80 mode http log global balance roundrobin server web01 10.0.0.201:80 weight 1 check inter 3000 fall 2 rise 5 server web02 10.0.0.202:80 weight 2 check inter 3000 fall 2 rise 5
reload haproxy
systemctl reload haproxy
测试
[root@node3 ~]# while true;do curl 192.168.32.204;sleep 0.5 ;done web01 10.0.0.201 web02 10.0.0.202 web02 10.0.0.202 web01 10.0.0.201 web01 10.0.0.201 web02 10.0.0.202 web02 10.0.0.202 web01 10.0.0.201 web02 10.0.0.202 #按照权重来分配后端服务器
动态修改权重
#把web01的权重改为3 #把web02的权重改为1 [root@node4 haproxy]# echo "set weight web_port/web01 3" | socat stdio /var/lib/haproxy/haproxy.sock [root@node4 haproxy]# echo "set weight web_port/web02 1" | socat stdio /var/lib/haproxy/haproxy.sock [root@node4 haproxy]# echo "get weight web_port/web01" | socat stdio /var/lib/haproxy/haproxy.sock 3 (initial 1) [root@node4 haproxy]# echo "get weight web_port/web02" | socat stdio /var/lib/haproxy/haproxy.sock 1 (initial 2)
测试
[root@node3 ~]# while true;do curl 192.168.32.204;sleep 0.5 ;done web01 10.0.0.201 web01 10.0.0.201 web02 10.0.0.202 web01 10.0.0.201 web01 10.0.0.201 web01 10.0.0.201 web02 10.0.0.202 web01 10.0.0.201 web01 10.0.0.201 #按照web01:web02=3:1来分配
leastconn
listen web_port bind 192.168.32.204:80 mode http log global balance leastconn server web01 10.0.0.201:80 weight 1 check inter 3000 fall 2 rise 5 server web02 10.0.0.202:80 weight 2 check inter 3000 fall 2 rise 5
reload haproxy
systemctl reload haproxy
其它部分算法即可作为静态算法,又可以通过选项成为动态算法
3.1 source
源地址hash,基于用户源地址hash并将请求转发到后端服务器,默认为静态即取模方式,但是可以通过hash-type 支持的选项更改,后续同一个源地址请求将被转发至同一个后端web服务器,比较适用于session保持/缓存业务等 场景。 源地址有两种转发客户端请求到后端服务器的服务器选取计算方式,分别是取模法(静态)和一致性hash(动态)
3.1.1 map-base取模法(静态)
map-based:取模法,基于服务器总权重的hash数组取模,该hash是静态的即不支持在线调整权重,不支持慢启 动,其对后端服务器调度均衡,缺点是当服务器的总权重发生变化时,即有服务器上线或下线,都会因权重发生变化而 导致调度结果整体改变。 所谓取模运算,就是计算两个数相除之后的余数,10%7=3, 7%4=3,基于权重取模:(2^32-1)%(1+1+2)
listen web_port bind 192.168.32.204:80 mode http log global balance source server web01 10.0.0.201:80 weight 1 check inter 3000 fall 2 rise 5 server web02 10.0.0.202:80 weight 2 check inter 3000 fall 2 rise 5
3.1.2 :一致性hash(动态)
listen web_port bind 192.168.32.204:80 mode http log global balance source hash-type consistent server web01 10.0.0.201:80 weight 1 check inter 3000 fall 2 rise 5 server web02 10.0.0.202:80 weight 2 check inter 3000 fall 2 rise 5
测试
[root@node3 ~]# curl 192.168.32.204/index.html web02 10.0.0.202 [root@node3 ~]# curl 192.168.32.204/index.html web02 10.0.0.202 [root@node3 ~]# curl 192.168.32.204/index.html web02 10.0.0.202 [root@node3 ~]# curl 192.168.32.204/index.html web02 10.0.0.202 #同一个源地址请求将被转发至同一个后端web服务器
3.2 uri
基于对用户请求的uri做hash并将请求转发到后端指定服务器,也可以通过map-based和consistent定义使用取模
http://example.org/absolute/URI/with/absolute/path/to/resource.txt #URI/URL ftp://example.org/resource.txt #URI/URL /relative/URI/with/absolute/path/to/resource.txt #URI
listen web_port bind 192.168.32.204:80 mode http log global balance uri server web01 10.0.0.201:80 weight 1 check inter 3000 fall 2 rise 5 server web02 10.0.0.202:80 weight 2 check inter 3000 fall 2 rise 5
listen web_port bind 192.168.32.204:80 mode http log global balance uri hash-type consistent server web01 10.0.0.201:80 weight 1 check inter 3000 fall 2 rise 5 server web02 10.0.0.202:80 weight 1 check inter 3000 fall 2 rise 5
测试
在web01和web02在创建一个index1.html web01 echo 'test01 10.0.0.201' > /usr/share/nginx/html/index1.html web02 echo 'test02 10.0.0.202' > /usr/share/nginx/html/index1.html [root@node3 ~]# curl 10.0.0.201/index.html web01 10.0.0.201 [root@node3 ~]# curl 10.0.0.201/index1.html test01 10.0.0.201
访问haproxy查看结果
[root@node3 ~]# curl 192.168.32.204/index.html web02 10.0.0.202 [root@node3 ~]# curl 192.168.32.204/index1.html test01 10.0.0.201 再找一台客户机测试 root@ubuntu-node1:~# curl 192.168.32.204/index.html web02 10.0.0.202 root@ubuntu-node1:~# curl 192.168.32.204/index1.html test01 10.0.0.201 #访问不同的uri,确认可以将用户同样的请求转发至相同的服务器
url_param对用户请求的url中的 params 部分中的参数name作hash计算,并由服务器总权重相除以后派发至某挑 出的服务器;通常用于追踪用户,以确保来自同一个用户的请求始终发往同一个real server
假设url = http://www.kingseal.com/foo/bar/index.php?k1=v1&k2=v2 则: host = "www.kingseal.com" url_param = "k1=v1&k2=v2"
listen web_port bind 192.168.32.204:80 mode http log global balance url_param k1,k2 server web01 10.0.0.201:80 weight 1 check inter 3000 fall 2 rise 5 server web02 10.0.0.202:80 weight 1 check inter 3000 fall 2 rise 5
listen web_port bind 192.168.32.204:80 mode http log global balance url_param k1,k2 hash-type consistent server web01 10.0.0.201:80 weight 1 check inter 3000 fall 2 rise 5 server web02 10.0.0.202:80 weight 1 check inter 3000 fall 2 rise 5
测试
客户机访问一下信息 curl http://192.168.32.204/index.html?k1=NAME #单个参数访问 curl http://192.168.32.204/index.html?k2=AGE curl http://192.168.32.204/index.html?k2=AGE&&k1=NAME #多个参数访问
针对用户每个http头部(header)请求中的指定信息做hash,此处由 name 指定的http首部将会被取出并做hash计 算,然后由服务器总权重相除以后派发至某挑出的服务器,假如无有效的值,则会使用默认的轮询调度。
3.4.1 hdr取模法配置(静态)
listen web_port bind 192.168.32.204:80 mode http log global balance hdr(User-Agent) server web01 10.0.0.201:80 weight 1 check inter 3000 fall 2 rise 5 server web02 10.0.0.202:80 weight 1 check inter 3000 fall 2 rise 5
listen web_port bind 192.168.32.204:80 mode http log global balance hdr(User-Agent) hash-type consistent server web01 10.0.0.201:80 weight 1 check inter 3000 fall 2 rise 5 server web02 10.0.0.202:80 weight 1 check inter 3000 fall 2 rise 5
测试
[root@node3 ~]# curl http://192.168.32.204/index.html web01 10.0.0.201 [root@node3 ~]# curl http://192.168.32.204/index.html web01 10.0.0.201 [root@node3 ~]# curl http://192.168.32.204/index.html web01 10.0.0.201 [root@node3 ~]# curl http://192.168.32.204/index.html web01 10.0.0.201 #根据http head中浏览器的类型把数据转发到同一个后端服务器
rdp-cookie对远windows程桌面的负载,使用cookie保持会话
3.5.1 rdp-cookie取模法配置(静态)
listen RDP bind 192.168.32.204:3389 balance rdp-cookie mode tcp server rdp0 10.0.0.201:3389 check fall 3 rise 5 inter 2000 weight 1
listen RDP bind 192.168.32.204:3389 balance rdp-cookie mode tcp hash-type consistent server rdp0 10.0.0.201:3389 check fall 3 rise 5 inter 2000 weight 1
#必须开启ip转发功能 cat >> /etc/sysctl.conf <<EOF net.ipv4.ip_forward = 1 EOF sysctl -p iptables -t nat -A PREROUTING -d 192.168.32.204 -p tcp --dport 3389 -j DNAT --todestination 10.0.0.201:3389 iptables -t nat -A POSTROUTING -s 192.168.0.0/16 -j SNAT --to-source 192.168.32.204
在1.9版本开始增加一个叫做random的负载平衡算法,其基于一个随机数作为一致性hash的key,随机负载平衡对 于大型服务器场或经常添加或删除服务器非常有用,因为它可以避免在这种情况下由roundrobin或leastconn导致 的锤击效应。
random配置
listen web_port bind 192.168.32.204:80 mode http log global balance random server web01 10.0.0.201:80 weight 1 check inter 3000 fall 2 rise 5 server web02 10.0.0.202:80 weight 1 check inter 3000 fall 2 rise 5
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 hdr #基于客户端请求报文头部做下一步处理 rdp-cookie #很少使用
转载请标明出处【HAPROXY的调度算法】。
《www.micoder.cc》
虚拟化云计算,系统运维,安全技术服务.
Tags: | [阅读全文...] |
最新评论