手机网站模板制作教程,外贸网站推广平台,wordpress专题模板,网站是不是每年都要续费HAProxy 调度算法介绍
HAProxy 的调度算法比较多#xff0c;在没有设置 mode 或者其它选项时#xff0c;HAProxy 默认对 后端服务器使用 roundrobin 算法来分配请求处理。对后端服务器指明使用的算法 时使用balance关键字#xff0c;该关键字可在listen和backend中出现。在…HAProxy 调度算法介绍
HAProxy 的调度算法比较多在没有设置 mode 或者其它选项时HAProxy 默认对 后端服务器使用 roundrobin 算法来分配请求处理。对后端服务器指明使用的算法 时使用balance关键字该关键字可在listen和backend中出现。在 HAProxy 运行时支持动态调整后端服务器权重、并且考虑后端服务器负载等情况的算法我们 称之为动态算法相反不能动态调整后端服务器权重也不考虑服务器负载的 算法叫静态算法。指定调度策略的典型配置如下
backend srv_group1mode httplog global# balance algorithm [arguments]balance static-rrserver web1 ip:port weight 2 check inter 300000ms fall 2 rise 5调度算法官方文档说明 本文介绍 HAProxy 算法的同时使用一台 HAProxy 服务器和四台后端服务器来验证各 调度算法的效果。另外客户端使用172.20.2.195 client-node1使用该客户端访 问 HAProxy 服务器(http://172.20.2.189:8080)来验证。 HAProxy 服务器 172.20.2.189 ubuntu-suosuoli-node1 系统:Ubuntu1804 四台后端服务器 172.20.2.37 node1 172.20.2.43 node2 172.20.2.44 node3 172.20.2.45 node4 系统都为 CentOS7.7 客户端 172.20.2.195 client-node1 系统为 CentOS7.7 准备环境
rootubuntu-suosuoli-node1:~# vim /etc/ansible/ansible.cfg
......
[backend]
172.20.2.37
172.20.2.43
172.20.2.44
172.20.2.45
......
rootubuntu-suosuoli-node1:~# ansible backend -m shell -a nginx -t
172.20.2.43 | SUCCESS | rc0
nginx: the configuration file /etc/nginx/nginx.conf syntax is ok
nginx: configuration file /etc/nginx/nginx.conf test is successful172.20.2.45 | SUCCESS | rc0
nginx: the configuration file /etc/nginx/nginx.conf syntax is ok
nginx: configuration file /etc/nginx/nginx.conf test is successful172.20.2.37 | SUCCESS | rc0
nginx: the configuration file /apps/nginx/conf/nginx.conf syntax is ok
nginx: configuration file /apps/nginx/conf/nginx.conf test is successful172.20.2.44 | SUCCESS | rc0
nginx: the configuration file /etc/nginx/nginx.conf syntax is ok
nginx: configuration file /etc/nginx/nginx.conf test is successfulrootubuntu-suosuoli-node1:~# ansible backend -m shell -a nginx -s reload
172.20.2.37 | SUCCESS | rc0 172.20.2.45 | SUCCESS | rc0 172.20.2.43 | SUCCESS | rc0 172.20.2.44 | SUCCESS | rc0 rootubuntu-suosuoli-node1:~# ansible backend -a hostname
172.20.2.43 | SUCCESS | rc0
node2172.20.2.44 | SUCCESS | rc0
node3172.20.2.45 | SUCCESS | rc0
node4172.20.2.37 | SUCCESS | rc0
node1使用的核心配置
globallog /dev/log local0log /dev/log local1 noticechroot /var/lib/haproxynbproc 2cpu-map 1 0cpu-map 2 1stats socket /run/haproxy/admin.sock2 mode 660 level admin expose-fd listeners#stats socket /run/haproxy/admin.sock1 mode 660 level admin expose-fd listeners process 1#stats socket /run/haproxy/admin.sock2 mode 660 level admin expose-fd listeners process 2stats timeout 30suser haproxygroup haproxydaemon# Default SSL material locationsca-base /etc/ssl/certscrt-base /etc/ssl/private# See: https://ssl-config.mozilla.org/#serverhaproxyserver-version2.0.3configintermediatessl-default-bind-ciphers ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384ssl-default-bind-ciphersuites TLS_AES_128_GCM_SHA256:TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256ssl-default-bind-options no-sslv3 no-tlsv10 no-tlsv11 no-tls-ticketsdefaultslog globalmode httpoption httplogoption dontlognulloption http-keep-alivetimeout connect 300000mstimeout client 300000mstimeout server 300000mserrorfile 400 /etc/haproxy/errors/400.httperrorfile 403 /etc/haproxy/errors/403.httperrorfile 408 /etc/haproxy/errors/408.httperrorfile 500 /etc/haproxy/errors/500.httperrorfile 502 /etc/haproxy/errors/502.httperrorfile 503 /etc/haproxy/errors/503.httperrorfile 504 /etc/haproxy/errors/504.httplisten statsmode httpbind 172.20.2.189:9999stats enablelog globalstats uri /haproxy_statusstats auth haadmin:stevenuxfrontend WEB_PORT_8080bind 172.20.2.189:8080mode httpuse_backend web_prot_http_nodesbackend web_prot_http_nodesmode http# balance roundrobin 默认使用该调度策略option forwardforserver node1 172.20.2.37:80 weight 1 check inter 3000 fall 3 rise 5server node2 172.20.2.43:80 weight 1 check inter 3000 fall 3 rise 5server node3 172.20.2.44:80 weight 1 check inter 3000 fall 3 rise 5server node4 172.20.2.45:80 weight 1 check inter 3000 fall 3 rise 5访问 WEB 管理界面http://172.20.2.189:9999/haproxy_status [外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-QFbYRf6R-1692491218897)(png/2020-01-11-19-40-48.png)]
一.静态调度算法
静态算法按照事先定义好的规则轮询公平调度不关心后端服务器的当前负载、链接数 和相应速度等且无法实时修改权重只能靠重启 HAProxy 生效。
HAProxy 运行时要动态修改服务器权重需要安装额外的工具socat。Socat 是 Linux 下的命令行工具全名叫 Socket CATSocat 的主要工作原理是建立一个双向的通道 并在这个通道传输比特流。其支持众多协议和链接方式。如 IP、TCP、UDP、IPv6、Socket 文件等。由于其功能强大可以有多种用途由于其可以转发 TCP 流甚至有人将它配置为 防火墙。
# Centos安装
yum install socat -y# 此处使用Ubuntu1804
rootubuntu-suosuoli-node1:~# apt-cache madison socatsocat | 1.7.3.2-2ubuntu2 | http://mirrors.aliyun.com/ubuntu bionic/main amd64 Packagessocat | 1.7.3.2-2ubuntu2 | https://mirrors.tuna.tsinghua.edu.cn/ubuntu bionic/main amd64 Packagessocat | 1.7.3.2-2ubuntu2 | http://mirrors.aliyun.com/ubuntu bionic/main Sources
rootubuntu-suosuoli-node1:~# apt install socat
rootubuntu-suosuoli-node1:~# socat -V
socat by Gerhard Rieger and contributors - see www.dest-unreach.org # 这是它官网作者应该是个极简主义者
socat version 1.7.3.2 on Apr 4 2018 10:06:49
......# 获取后端服务器node3的权重可以这样做
rootubuntu-suosuoli-node1:~# find / -name admin.sock
/run/haproxy/admin.sock
rootubuntu-suosuoli-node1:~# echo get weight web_prot_http_nodes/node3 | socat stdio /run/haproxy/admin.sock
3 (initial 3)# 设置没某个后端服务器的权重可以这样但是我用的是static-rr算法不可以动态调整权重。只接受0或者1
# 0就表示不参与请求处理1表示参与
rootubuntu-suosuoli-node1:~# echo set weight web_prot_http_nodes/node3 6 | socat stdio /run/haproxy/admin.sock
Backend is using a static LB algorithm and only accepts weights 0% and 100%.BTW:socat 官网 [外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-Yb4V8Ncy-1692491218898)(png/2020-01-12-14-35-26.png)]
1.1 static-rr
static roundrobin:静态轮询调度策略使用基于权重的轮询调度策略。权重 在配置文件中指定后不可动态更改和后端服务器慢启动此调度策略对后端服务 器最大数量没有限制。
listen statsmode httpbind 172.20.2.189:9999stats enablelog globalstats uri /haproxy_statusstats auth haadmin:stevenuxfrontend WEB_PORT_80bind 172.20.2.189:8080mode httpuse_backend web_prot_http_nodesbackend web_prot_http_nodesmode httpbalance static-rroption forwardforserver node1 172.20.2.37:80 weight 1 check inter 3000 fall 3 rise 5server node2 172.20.2.43:80 weight 2 check inter 3000 fall 3 rise 5server node3 172.20.2.44:80 weight 1 check inter 3000 fall 3 rise 5server node4 172.20.2.45:80 weight 2 check inter 3000 fall 3 rise 5client-node1 上测试效果
[rootclient-node1 ~]# while : ; do curl 172.20.2.189:8080 ; sleep 0.1 ; done
node1 172.20.2.37
node2 172.20.2.43
node4 172.20.2.45
node2 172.20.2.43
node3 172.20.2.44
node4 172.20.2.45
node1 172.20.2.37
node2 172.20.2.43
......# 44此访问被调度的比例接近1:2:1:2的权重值
[rootclient-node1 ~]# cat static-rr.log | wc -l
44
[rootclient-node1 ~]# cat static-rr.log | sort | uniq -c8 node1 172.20.2.3715 node2 172.20.2.437 node3 172.20.2.4414 node4 172.20.2.451.2 first
first:根据服务器在列表中的位置自上而下进行调度(不人为的设定从上到 下各台服务器的 id 会自动增加第一台服务器的 id 为 1)但是其只会当第一 台服务器的连接数达到上限(maxconn 参数)新请求才会分配给下一台服务 因此 HAProxy 会忽略服务器的权重值这样比较适合长会话的协议如RDP[^1] 和 IMAP。不指定maxconn参数使用该调度策略是没有意义的(懂我意思吗?)。 实现该调度算法的实际用途是在比较空闲的时间段关闭某些服务器以使用最少的服 务器提供服务节约成本。
如果需要人为指定 id则可以在server server_name ip:port指令后面加上 id idnumberid 号必须是正整数。
RDP 协议介绍
listen statsmode httpbind 172.20.2.189:9999stats enablelog globalstats uri /haproxy_statusstats auth haadmin:stevenuxfrontend WEB_PORT_80bind 172.20.2.189:8080mode httpuse_backend web_prot_http_nodesbackend web_prot_http_nodesmode httpbalance firstoption forwardforserver node1 172.20.2.37:80 maxconn 2 weight 1 check inter 3000 fall 3 rise 5server node2 172.20.2.43:80 weight 2 check inter 3000 fall 3 rise 5server node3 172.20.2.44:80 maxconn 2 weight 1 check inter 3000 fall 3 rise 5server node4 172.20.2.45:80 weight 2 check inter 3000 fall 3 rise 5client-node1 上测试
# 在两个窗口同时访问HAProxy
[rootclient-node1 ~]# tty
/dev/pts/0
[rootclient-node1 ~]# while : ; do curl 172.20.2.189:8080 ; done
...
[rootclient-node1 ~]# tty
/dev/pts/1
[rootclient-node1 ~]# while : ; do curl 172.20.2.189:8080 ; done
node1 172.20.2.37
node1 172.20.2.37
node2 172.20.2.43
......
node1 172.20.2.37
node1 172.20.2.37
node2 172.20.2.43
......
# 可以看到在某些时间几乎同时有两个以上的请求到达node1这时HAProxy
# 就会调度node2处理多出的请求二.动态调度算法
2.1 roundrobin
roundrobin该算法是默认使用的调度策略。该算法会根据每个后端服务器的 权重weight依次将请求分发到后端服务器。当后端服务器的处理性能比较均 衡的分布时使用该算法比较好。在该算法使用时可以动态调整后端服务器 的权重以便调整整个服务器组的性能。由于设计的限制每个后端服务器组 最多只能定义 4095 个活动服务器。该 roudrobin 算法支持慢启动(slow start)表示新加入的服务器会在一段时间内逐渐增加工作负载(转发量)。
验证 roundrobin 调度策略的配置如下
listen statsmode httpbind 172.20.2.189:9999stats enablelog globalstats uri /haproxy_statusstats auth haadmin:stevenuxfrontend WEB_PORT_8080bind 172.20.2.189:8080mode httpuse_backend web_prot_http_nodesbackend web_prot_http_nodesmode http# balance roundrobin 默认使用该调度策略option forwardforserver node1 172.20.2.37:80 weight 1 check inter 3000 fall 3 rise 5server node2 172.20.2.43:80 weight 1 check inter 3000 fall 3 rise 5server node3 172.20.2.44:80 weight 1 check inter 3000 fall 3 rise 5server node4 172.20.2.45:80 weight 1 check inter 3000 fall 3 rise 5在client-node1多次访问http://172.20.2.189:8080验证
[rootclient-node1 ~]# while : ; do curl 172.20.2.189:8080 ; sleep 3 ; done
node4 172.20.2.45
node1 172.20.2.37
node2 172.20.2.43
node3 172.20.2.44
node4 172.20.2.45
node1 172.20.2.37
node2 172.20.2.43
^C
# 配置指明后端服务器的权重weight都为1所以后端服务器被轮流调度处理请求更改服务器的权重
rootubuntu-suosuoli-node1:~# echo get weight web_prot_http_nodes/node1 | socat stdio /run/haproxy/admin.sock
1 (initial 1)rootubuntu-suosuoli-node1:~# echo get weight web_prot_http_nodes/node2 | socat stdio /run/haproxy/admin.sock
1 (initial 1)rootubuntu-suosuoli-node1:~# echo get weight web_prot_http_nodes/node3 | socat stdio /run/haproxy/admin.sock
1 (initial 1)rootubuntu-suosuoli-node1:~# echo get weight web_prot_http_nodes/node4 | socat stdio /run/haproxy/admin.sock
1 (initial 1)# 更改权重
rootubuntu-suosuoli-node1:~# echo set weight web_prot_http_nodes/node2 2 | socat stdio /run/haproxy/admin.sockrootubuntu-suosuoli-node1:~# echo set weight web_prot_http_nodes/node3 3 | socat stdio /run/haproxy/admin.sockrootubuntu-suosuoli-node1:~# echo set weight web_prot_http_nodes/node4 4 | socat stdio /run/haproxy/admin.sock# 查看是否生效
rootubuntu-suosuoli-node1:~# echo get weight web_prot_http_nodes/node3 | socat stdio /run/haproxy/admin.sock
3 (initial 1)
再次测试
[rootclient-node1 ~]# while : ; do curl 172.20.2.189:8080 ;sleep 0.01; done
node4 172.20.2.45
node3 172.20.2.44
node4 172.20.2.45
node2 172.20.2.43
node3 172.20.2.44
node4 172.20.2.45
node1 172.20.2.37
node4 172.20.2.45
node3 172.20.2.44
......# 统计81次访问
[rootclient-node1 ~]# cat statis.log | wc -l
81
[rootclient-node1 ~]# cat statis.log | sort | uniq -c8 node1 172.20.2.3716 node2 172.20.2.4324 node3 172.20.2.4433 node4 172.20.2.45# 可以看到各个服务器被调度的比例接近权重node1:node2:node3:node41:2:3:4
# 实际为node1:node2:node3:node48:16:24:332.2 leastconn
leastconn 加权的最少连接的动态支持权重的运行时调整和慢启动即当前后端 服务器连接最少的优先调度(新客户端连接)比较适合长连接的场景使用比如 MySQL 等场景。
listen statsmode httpbind 172.20.2.189:9999stats enablelog globalstats uri /haproxy_statusstats auth haadmin:stevenuxfrontend WEB_PORT_80bind 172.20.2.189:8080mode httpuse_backend web_prot_http_nodesbackend web_prot_http_nodesmode httpbalance leastconnoption forwardforserver node1 172.20.2.37:80 weight 1 check inter 3000 fall 3 rise 5server node2 172.20.2.43:80 weight 1 check inter 3000 fall 3 rise 5server node3 172.20.2.44:80 weight 1 check inter 3000 fall 3 rise 5server node4 172.20.2.45:80 weight 1 check inter 3000 fall 3 rise 5三.其它算法
这些算法无法严格的分为动态或者静态算法可以作为静态算法也可可以通过选项调整 为动态算法。
3.1 source
source调度策略为source IP hash(源地址哈希)基于客户端源地址 hash 并将请求转发到后端服务器默认为静态方式即取模方式但是可以通过 hash-type 支持的选项更改后续同一个源地址请求将被转发至同一个后端 web 服务器比较 适用于 session 保持/缓存业务等场景。
源 IP 地址被 HASH 并除以正在运行的服务器的总权重值取其结果的摸得到一 个索引以指定哪个服务器将接收请求。这确保了只要没有服务器宕机或恢复相 同的客户端 IP 地址将始终到达相同的服务器。如果运算结果由于运行的服务器数量 的变化而发生变化许多客户端请求将被定向到其它台服务器。该算法通常用于 TCP 模式其中不可以插入 cookie 信息。它也可以在 Internet 上使用为拒绝会话 cookie 的客户端提供最佳的粘性。默认情况下这个算法是静态的这意味着动态 地更改服务器的权重不会有任何影响但是可以使用hashtype关键字来更改。
hash-type method用来指定 hash 类型类型可以是map-based或者consistent
hash-type map-based # 不指定时默认使用该哈希方法
hash-type consistentmap-based哈希方法 使用 map-based 哈希方法时哈希表(哈希的结果)是包含所有活动服务器的静态 数组。该哈希方法会考虑服务器权重。但是在服务器运行时权重发生变化会被忽略。 核心是按照服务器在数组中的位置来选择调度的服务器所以当服务器有上线或者下 线时总权重会发生变化哈希也就变化了这会导致大部分的连接将会重新被调度 到不同的服务器。这种调度算法不支持慢启动也不适合在使用缓存的场景使用。 consistent一致性哈希方法 使用 consistent 一致性哈希方法时哈希表中每个服务器对应多个哈希值(这些 对应于同一个服务器的哈希值和该服务器的名称或者 ID 有关联)这个哈希表使用 树结构(某种数据结构)来组织。HAProxy 会在该树结构上查找哈希键并选中最合适 的值。该哈希方法支持动态修改服务器权重所以其支持慢启动。使用该调度策略的 优势是当某个服务器停用或者再次启用时只有和该服务器相关的哈希信息会被移 除。当某个服务器加入服务器组时只有一部分连接会被重新分配这使得一致性哈 希方法是使用缓存时的理想调度策略。 map-based哈希方法配置
listen statsmode httpbind 172.20.2.189:9999stats enablelog globalstats uri /haproxy_statusstats auth haadmin:stevenuxfrontend WEB_PORT_80bind 172.20.2.189:8080mode httpuse_backend web_prot_http_nodesbackend web_prot_http_nodesmode httpbalance source# hash-type map-based # 可写可不写option forwardforserver node1 172.20.2.37:80 weight 1 check inter 3000 fall 3 rise 5server node2 172.20.2.43:80 weight 1 check inter 3000 fall 3 rise 5server node3 172.20.2.44:80 weight 1 check inter 3000 fall 3 rise 5server node4 172.20.2.45:80 weight 1 check inter 3000 fall 3 rise 5在 client-node1 访问验证
[rootclient-node1 ~]# while : ; do curl 172.20.2.189:8080 ;sleep 1; done
node4 172.20.2.45
node4 172.20.2.45
node4 172.20.2.45
......在 172.20.1.1 访问验证 [外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-SlWTvcYj-1692491218898)(png/2020-01-12-18-00-29.png)]
consistent一致性哈希方法配置
listen statsmode tcpbind 172.20.2.189:9999stats enablelog globalstats uri /haproxy_statusstats auth haadmin:stevenuxfrontend WEB_PORT_80bind 172.20.2.189:8080mode tcpuse_backend web_prot_http_nodesbackend web_prot_http_nodesmode httpbalance sourcehash-type consistence # 使用一致性哈希方法option forwardforserver node1 172.20.2.37:80 weight 1 check inter 3000 fall 3 rise 5server node2 172.20.2.43:80 weight 1 check inter 3000 fall 3 rise 5server node3 172.20.2.44:80 weight 1 check inter 3000 fall 3 rise 5server node4 172.20.2.45:80 weight 1 check inter 3000 fall 3 rise 53.2 uri
uri调度算法会对 URI 的左侧部分(问号前面的部分)或者对整个 URI 进行哈希 并使用活动服务器的总权重值除以该哈希值。计算结果决定了将请求调度到哪台服 务器。该调度算法常常在使用代理缓存时使用。也可以通过 map-based 和 consistent 定义使用取模法还是一致性 hash。
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
# 注意URL是URI的子集配置示例
listen statsmode httpbind 172.20.2.189:9999stats enablelog globalstats uri /haproxy_statusstats auth haadmin:stevenuxfrontend WEB_PORT_80bind 172.20.2.189:8080mode httpuse_backend web_prot_http_nodesbackend web_prot_http_nodesmode httpbalance uri#hash-type map-basedoption forwardforserver node1 172.20.2.37:80 weight 1 check inter 3000 fall 3 rise 5server node2 172.20.2.43:80 weight 1 check inter 3000 fall 3 rise 5server node3 172.20.2.44:80 weight 1 check inter 3000 fall 3 rise 5server node4 172.20.2.45:80 weight 1 check inter 3000 fall 3 rise 5访问测试
[rootclient-node1 ~]# curl http://172.20.2.189:8080/index.html
node3 172.20.2.44
[rootclient-node1 ~]# curl http://172.20.2.189:8080/index1.html
index1-node4-172.20.2.453.3 url_param
url_param 对用户请求的 url 中的 params 部分中的参数 name 作 hash 计算并除以服务器总权重根据计算结果派发至某挑出的服务器通常用 于追踪用户以确保来自同一个用户的请求始终发往同一个 real server。 其亦可以使用hash-type指定一致性哈希方法。另外如果找不到 URL 中 问号选项后的参数则使用 roundrobin 算法。
对于 url_param 中的哈希对象(参数)可以用一个 URL 来说明
假设
URL http://www.suosuoli.cn/foo/bar/index.php?key1value1key2value2
那么
host www.suosuoli.cn
url_param key1value1key2value2 # 该字符串就是要进行哈希运算的对象url_param调度策略配置示例
listen statsmode httpbind 172.20.2.189:9999stats enablelog globalstats uri /haproxy_statusstats auth haadmin:stevenuxfrontend WEB_PORT_80bind 172.20.2.189:8080mode httpuse_backend web_prot_http_nodesbackend web_prot_http_nodesmode httpbalance url_param name,gender # 支持对单个或多个url_param进行hash# hash-type consistent # 使用一致性hash方法option forwardforserver node1 172.20.2.37:80 weight 1 check inter 3000 fall 3 rise 5server node2 172.20.2.43:80 weight 1 check inter 3000 fall 3 rise 5server node3 172.20.2.44:80 weight 1 check inter 3000 fall 3 rise 5server node4 172.20.2.45:80 weight 1 check inter 3000 fall 3 rise 5访问测试
# 未带参数都被调度到node1
[rootclient-node1 ~]# curl http://172.20.2.189:8080/index.html
node1 172.20.2.37
[rootclient-node1 ~]# curl http://172.20.2.189:8080/index1.html
index1-node2-172.20.2.43# 找不到参数则使用roudrobin轮询策略
[rootclient-node1 ~]# curl http://172.20.2.189:8080/index1.html?namejack
index1-node3-172.20.2.44
[rootclient-node1 ~]# curl http://172.20.2.189:8080/index1.html?namejack
index1-node4-172.20.2.45
[rootclient-node1 ~]# curl http://172.20.2.189:8080/index1.html?namejack
index1-node1--172.20.2.37
[rootclient-node1 ~]# curl http://172.20.2.189:8080/index1.html?namejack
index1-node2-172.20.2.43
[rootclient-node1 ~]# curl http://172.20.2.189:8080/index1.html?namejack
index1-node3-172.20.2.44
[rootclient-node1 ~]# curl http://172.20.2.189:8080/index1.html?namejack
index1-node4-172.20.2.453.4 hdr
针对用户每个 http 头部(header)请求中的指定信息做 hash此处由 name 指定 的 http 首部将会被取出并做 hash 计算然后由服务器总权重相除以后派发至某 挑出的服务器假如无有效的值则会使用默认的轮询调度。
hdr调度策略配置
listen statsmode httpbind 172.20.2.189:9999stats enablelog globalstats uri /haproxy_statusstats auth haadmin:stevenuxfrontend WEB_PORT_80bind 172.20.2.189:8080mode httpuse_backend web_prot_http_nodesbackend web_prot_http_nodesmode httpbalance hdr(User-Agent) # 使用客服端版本等信息进行哈希运算option forwardforserver node1 172.20.2.37:80 weight 1 check inter 3000 fall 3 rise 5server node2 172.20.2.43:80 weight 1 check inter 3000 fall 3 rise 5server node3 172.20.2.44:80 weight 1 check inter 3000 fall 3 rise 5server node4 172.20.2.45:80 weight 1 check inter 3000 fall 3 rise 5访问测试
[rootclient-node1 ~]# curl -V
curl 7.29.0 (x86_64-redhat-linux-gnu) libcurl/7.29.0 NSS/3.36 zlib/1.2.7 libidn/1.28 libssh2/1.4.3
Protocols: dict file ftp ftps gopher http https imap imaps ldap ldaps pop3 pop3s rtsp scp sftp smtp smtps telnet tftp
Features: AsynchDNS GSS-Negotiate IDN IPv6 Largefile NTLM NTLM_WB SSL libz unix-sockets
[rootclient-node1 ~]# curl http://172.20.2.189:8080
node4 172.20.2.45
[rootclient-node1 ~]# curl http://172.20.2.189:8080
node4 172.20.2.45
[rootclient-node1 ~]# curl http://172.20.2.189:8080
node4 172.20.2.45
[rootclient-node1 ~]# curl http://172.20.2.189:8080Chrome 浏览器测试 [外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-VllpvcMV-1692491218899)(png/2020-01-12-21-05-14.png)] FireFox 浏览器测试 [外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-919Z4GWd-1692491218899)(png/2020-01-12-21-06-52.png)]
可以看到不同的客户端的请求被调度到不同的后端服务器。
3.5 rdp-cookie
rdp(windows 远程桌面协议)-cookie 用于对 windows 远程桌面的反向代理 主要是使用 cookie 保持来会话此调度算法专门适用于 windows 远程桌面 连接场景。当连接到后端服务器后会生成一个 cookie下次相同的 cookie 连接时还会被调度到同一台后端服务器适用于后端多服务器场景。
rdp-cookie配置示例
listen statsmode httpbind 172.20.2.189:9999stats enablelog globalstats uri /haproxy_statusstats auth haadmin:stevenuxfrontend WEB_PORT_80bind 172.20.2.189:8080mode tcpuse_backend web_prot_http_nodesbackend web_prot_http_nodesmode tcpbalance rdp-cookiehash-type consistenceoption forwardforserver node1 172.20.2.37:80 weight 1 check inter 3000 fall 3 rise 5server node2 172.20.2.43:80 weight 1 check inter 3000 fall 3 rise 5server node3 172.20.2.44:80 weight 1 check inter 3000 fall 3 rise 5server node4 172.20.2.45:80 weight 1 check inter 3000 fall 3 rise 5注如果跨网段HAProxy 主机需要开启路由器转发功能/etc/sysctl.conf
net.ipv4.ip_forward 1 #必须开启ip转发功能该算法只在四层是不分析到用户请求的应用层信息的只分析到传输层所以 HAProxy 会基于端口号做转发所以需要开启路由器转发功能。
3.6 random
该算法在 1.9 版本增加其基于一个随机数作为一致性 hash 的 key随机负载 平衡对于大型服务器场或经常添加和删除服务器的场景非常有用因为它可以避免 在这种情况下由 roundrobin 或 leastconn 导致的锤击效应。
random调度策略配置
listen statsmode httpbind 172.20.2.189:9999stats enablelog globalstats uri /haproxy_statusstats auth haadmin:stevenuxfrontend WEB_PORT_80bind 172.20.2.189:8080mode httpuse_backend web_prot_http_nodesbackend web_prot_http_nodesmode httpbalance randomoption forwardforserver node1 172.20.2.37:80 weight 1 check inter 3000 fall 3 rise 5server node2 172.20.2.43:80 weight 1 check inter 3000 fall 3 rise 5server node3 172.20.2.44:80 weight 1 check inter 3000 fall 3 rise 5server node4 172.20.2.45:80 weight 1 check inter 3000 fall 3 rise 5访问测试
[rootclient-node1 ~]# while : ; do curl 172.20.2.189:8080 ;sleep 1; done
node2 172.20.2.43
node1 172.20.2.37
node4 172.20.2.45
node1 172.20.2.37
node1 172.20.2.37
node4 172.20.2.45
node2 172.20.2.43
node4 172.20.2.45
^C[rootclient-node1 ~]# while : ; do curl 172.20.2.189:8080 random.log ; done
.....
[rootclient-node1 ~]# cat random.log | wc -l
1147
[rootclient-node1 ~]# cat random.log | sort | uniq -c346 node1 172.20.2.37201 node2 172.20.2.43266 node3 172.20.2.44333 node4 172.20.2.45
# 可以看到各个服务器处理的请求数量没有规律随机的(懂我意思吗)四.各算法使用场景
4.1 总结
算法支持的协议静态/动态static-rrtcp/http静态firsttcp/http静态roundrobintcp/http动态leastconntcp/http动态randomtcp/http动态sourcetcp/http取决于 hash_type 是否 consistenturittp取决于 hash_type 是否 consistenturl_paramttp取决于 hash_type 是否 consistenthdrhttp取决于 hash_type 是否 consistentrdp-cookietcp取决于 hash_type 是否 consistent
4.2 各算法使用场景
算法使用场景first使用较少节约成本static-rr做了 session 共享的 web 集群roundrobin做了 session 共享的 web 集群random做了 session 共享的 web 集群leastconn数据库source基于客户端公网 IP 的会话保持uri---------------http缓存服务器CDN 服务商蓝汛、百度、阿里云、腾讯url_param---------http缓存服务器CDN 服务商蓝汛、百度、阿里云、腾讯hdr基于客户端请求报文头部做下一步处理rdp-cookie很少使用
五.四层与七层负载
在 HAProxy 或者 Nginx 等软件涉及到代理和负载均衡等概念时常常会引出四层和 七层负载、四层和七层流量等概念。实际上这里的四层和七层就对于网络协议栈中 ISO 标准的四层和七层。
层级协议七应用层 HTTP/HTTPS/FTP.所以七层代理或者七层负载主要负载处理 HTTP 协议六表示层五会话层四传输层 TCP/UDP.所以四层转发或者四层负载主要处理 TCP 或 UDP 协议三网络层 IP二数据链路层 ARP/RARP一物理层
处理七层负载时主要涉及 HTTP 协议的请求头请求体和请求方法等概念。 处理四层负载主要是 TCP 协议涉及 IP 地址和端口等概念。
5.1 四层负载
在四层负载设备中把 client 发送的报文目标地址(原来是负载均衡设备的 IP 地址)根据均衡设备设置的选择 web 服务器的规则选择对应的 web 服务器 IP 地址这样 client 就可以直接跟此服务器建立 TCP 连接并发送数据。
5.2 七层负载
七层负载均衡服务器起了一个反向代理服务器的作用服务器建立一次 TCP 连接 要三次握手而 client 要访问 webserver 要先与七层负载设备进行三次握手 后建立 TCP 连接把要访问的报文信息发送给七层负载均衡然后七层负载均衡 再根据设置的均衡规则选择特定的 webserver然后通过三次握手与此台 webserver 建立 TCP 连接然后 webserver 把需要的数据发送给七层负载均衡 设备负载均衡设备再把数据发送给 client所以七层负载均衡设备起到了代 理服务器的作用。
六.IP 透传
IP 透传实际上就是指将客户端的 IP 发送给后端服务器默认后端服务器是不知道 请求来自哪个客户端的。HAProxy 可以在四层或者七层将客户端的 IP 传给后端 服务器以便做访问和日志分析。
6.1 四层 IP 透传配置
listen statsmode httpbind 172.20.2.189:9999stats enablelog globalstats uri /haproxy_statusstats auth haadmin:stevenuxfrontend WEB_PORT_80bind 172.20.2.189:8080mode httpuse_backend web_prot_http_nodesbackend web_prot_http_nodesmode tcpbalance randomoption forwardforserver node1 172.20.2.37:80 send-proxy weight 1 check inter 3000 fall 3 rise 5 # 加send-proxy就可以server node2 172.20.2.43:80 send-proxy weight 1 check inter 3000 fall 3 rise 5server node3 172.20.2.44:80 send-proxy weight 1 check inter 3000 fall 3 rise 5server node4 172.20.2.45:80 send-proxy weight 1 check inter 3000 fall 3 rise 5# 后端Nginx配置
http {......
log_format main $http_x_forwarded_For - $remote_user [$time_local] $request $status $body_bytes_sent $http_referer $http_user_agent ;
server {listen 80 proxy_protocol; # 增加选项proxy_protocol#listen 80;server_name localhost;
......access_log logs/host.access.log main;}
}
6.2 七层 IP 透传配置
当 haproxy 工作在七层的时候如何透传客户端真实 IP 至后端服务器
6.2.1 HAProxy 配置
# haproxy 配置
defaults
option forwardfor# 或者
option forwardfor header X-Forwarded-xxx # 自定义传递IP参数,后端web服务器写X-Forwarded-xxx# 如果写
option forwardfor # 则后端服务器web格式为X-Forwarded-Forlisten配置示例
listen web_hostbind 192.168.7.101:80mode httplog globalbalance randomserver web1 192.168.7.103:80 weight 1 check inter 3000 fall 2 rise 5server web2 192.168.7.104:80 weight 1 check inter 3000 fall 2 rise 56.2.2 web 服务器日志格式配置
配置 web 服务器以记录负载均衡透传的客户端 IP 地址
# apache 配置
LogFormat %{X-Forwarded-For}i %a %l %u %t \%r\ %s %b \%{Referer}i\ \%{User-Agent}i\ combined# tomcat 配置
pattern%{X-Forwarded-For}i %l %T %t quot;%rquot; %s %b quot;%{User-Agent}iquot;/# nginx 日志格式
log_format main $http_x_forwarded_For - $remote_user [$time_local] $request $status $body_bytes_sent $http_referer $http_user_agent ;访问测试
# 172.20.1.1为客户端地址
[rootnode1 ~]# tail -f /apps/nginx/logs/access.log
172.20.2.195 - - [13/Jan/2020:19:01:38 0800] GET / HTTP/1.1 200 18 - curl/7.29.0
172.20.1.1 - - [13/Jan/2020:19:01:49 0800] GET /index1.html HTTP/1.1 200 26 - Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:72.0) Gecko/20100101 Firefox/72.0
172.20.1.1 - - [13/Jan/2020:19:01:52 0800] GET /index1.html HTTP/1.1 200 26 - Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:72.0) Gecko/20100101 Firefox/72.0
172.20.1.1 - - [13/Jan/2020:19:01:55 0800] GET /index1.html HTTP/1.1 200 26 - Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:72.0) Gecko/20100101 Firefox/72.0
172.20.1.1 - - [13/Jan/2020:19:02:22 0800] GET /index1.html HTTP/1.1 304 0 - Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:72.0) Gecko/20100101 Firefox/72.0
......
