HAProxy配置文件
配置文件:
/etc/haproxy/haproxy.cfg
负载均衡参数:
轮询方式 | 轮询注解 |
---|---|
roundrobin | 基于权重进行轮叫调度的算法,在服务器的性能分布比较均匀时,这是一种最公平合理,常用的算法。此算法使用较为频繁。 |
static-rr | 基于权重进行轮叫调度的算法,不过此算法为静态方法,在运行时调整期服务器权重不会生效,需要重启haproxy服务生效 |
source | 基于请求源IP的算法。此算法先对请求的源IP进行hash运算,可以使同一个客户端IP的请求始终被转发到某台特定的后端服务器 |
leastconn | 数据库负载均衡mysql+haproxy的常用轮询方式,不适用于http。此算法会将新的连接请求转发具有最少连接数目的后端服务器。 |
uri / uri_param / hdr | 根据url路径进行转发匹配后端服务器。hdr根据http头部进行转发 |
默认配置:
defaults log global #集成全局配置中的日志格式mode http #所处理的类别(#7层 http;4层tcp) tcp模式一般用于,SSL,SSH,SMTP,MySQL等应用option httplog #日志类别http日志格式option http-server-close #每次请求完毕后主动关闭http通道option dontlognull # 不记录健康检查的日志信息option forwardfor except 127.0.0.1 如果后端服务器需要获得客户端真实ip需要配置的参数可以从http header中获得客户端ipoption redispatch #serverID对应的服务器挂掉后,强制定向到其他健康的服务器option abortonclose #当服务器负载很高的时候,自动结束掉当前队列处理比较久的连接maxconn 20480 #最大连接数stats refresh 30 统计页面刷新间隔retries 3 3次连接失败就认为该服务不可用balance roundrobin # rr 轮询负载均衡#balance source # source 轮询负载均衡#balance leastconn # 最小连接的负载均衡方式,推荐在Mysql、LDAP等情况下使用timeout connect 5000 连接超时timeout client 50000 客户端超时timeout server 50000 后端服务器超时timeout check 2000 设置对后端服务器的检测超时时间,默认单位是毫秒timeout http-request 10s 请求报文的超时时长
HAproxy轮询方式+配置文件详解_haproxy轮询模式-CSDN博客
负载均衡算法
静态算法
按照事先定义好的规则轮询公平调度,不关心后端服务器的当前负载、链接数和响应速度等,且无法实时修改权重,只能靠重启HAProxy生效。
static-rr
基于权重的轮询调度,不支持权重的运行时调整及后端服务器慢启动(慢启动是新增加的服务器会逐渐增加请求数,而不会一次性添加流量),其后端主机数量没有限制。
只能通过修改配置文件修改权重,修改完重启服务或者reload
动态算法
有 roundrobin,source,leastconn。基于后端服务器状态进行调度适当调整,比如优先调度至当前负载较低的服务器,且权重可以在haproxy运行时动态调整无需重启。
roundrobin
基于权重的轮询动态调度算法,支持权重的运行时调整,不完全等于lvs中的rr轮训模式,HAProxy中的roundrobin支持慢启动(新加的服务器会逐渐增加转发数),其每个后端backend中(每个listen)最多支持4095个real server,roundrobin为默认调度算法,且支持对real server权重动态调整。
source
源地址hash,基于用户源地址hash并将请求转发到后端服务器,默认为静态即取模方式,但是可以通过hash-type支持的选项更改,后续同一个源地址请求将被转发至同一个后端web服务器,比较适用于session保持/缓存业务等场景。 用户第一次请求会通过hash被分配到一台服务器,第二次请求则也会通过对用户的源地址做hash运算,然后对后端服务器的总权重进行取模,根据取得的模,分配到对应权重的后端服务器,以此实现会话保持(取模的得数是不可能等于总权重的,如果取模的得数等于总权重,则会进1,就会取不到模,所以取模的得数只会小于总权重)。 源地址有两种转发客户端请求到后端服务器的服务器选取计算方式,分别是取模法和一致性hash
leastconn
leastconn加权的最少连接的动态,支持权重的运行时调整和慢启动,即当前后端服务器连接最少的优先调度(新客户端连接),比较适合长连接的场景使用,比如MySQL等场景。
haproxy调度算法详解一
haproxy配置文件详解
HAProxy 和 Nginx 负载均衡
HAProxy专门部署在一台机器上,用来分发请求到后面的emqx服务所在的机器。
三、使用负载均衡LB
使用HAProxy或Nginx 作为 LB 部署 EMQ X 集群。这里用的HAProxy做为负载均衡:
1、安装HAProxy
sudo apt-get install haproxy
2、编辑配置文件
sudo vim /etc/haproxy/haproxy.cfg
用 HAProxy 负载均衡 EMQX 集群 | EMQX文档
健康检查三种方式
1、通过监听端口进行健康检测 。这种检测方式,haproxy只会去检查后端server的端口,并不能保证服务的真正可用。
2、通过URI获取进行健康检测 。检测方式,是用过去GET后端server的的web页面,基本上可以代表后端服务的可用性。
3、通过request获取的头部信息进行匹配进行健康检测 。这种检测方式,则是基于高级,精细的一些监测需求。通过对后端服务访问的头部信息进行匹配检测。
HAproxy健康检查的三种方式
Nginx健康检查
Nginx健康检查可以用于监测后端服务的运行状态,一旦发现后端服务不正常,将自动切换到其它正常的后端服务,保证整个服务的可用性和稳定性。下面是一个配置Nginx健康检查的例子,并详细说明各参数的作用。
upstream backend {server backend1.example.com:8080 weight=5 max_fails=3 fail_timeout=30s;server backend2.example.com:8080 weight=10 max_fails=3 fail_timeout=30s;server backend3.example.com:8080 weight=10 max_fails=3 fail_timeout=30s;check interval=3000 rise=2 fall=3 timeout=2000 type=http;
}
- upstream backend:定义一个名为backend的upstream,表示后端服务的集群。
- server backend1.example.com:表示一个后端服务节点,8080为服务端口,weight=5表示该节点的权重为5,默认为1,max_fails=3表示最大连接失败次数为3,即如果该节点失败3次,将被视为down掉,fail_timeout=30s表示下线时间为30秒,30秒后尝试重新上线,如果成功则恢复服务,如果失败则继续下线。
- check interval=3000:表示检查间隔为3秒,默认为5秒。
- rise=2:表示如果在2次连续检查中都返回正常(http返回码为200),则将该节点的失败次数清零,即认为该节点恢复正常。
- fall=3:表示如果在3次连续检查中都返回失败(http返回码非200),则将该节点的失败次数加1,如果该节点失败次数达到max_fails,则认为该节点down掉并下线。
- timeout=2000:表示检查超时时间为2秒,默认为1秒。
- type=http:表示检查类型为http,其他类型还包括tcp、ssl、http_keepalive等。
通过Nginx健康检查,可以自动发现后端服务的故障节点,并将请求转发到正常的服务节点,提高了整个服务的可用性和稳定性。
Nginx被动健康检查和主动健康检查
1.被动健康检查
Nginx自带有健康检查模块:ngx_http_upstream_module,可以做到基本的健康检查。Nginx只有当有访问时后,才发起对后端节点探测。如果本次请求中,节点正好出现故障,Nginx依然将请求转交给故障的节点,然后再转交给健康的节点处理。所以不会影响到这次请求的正常进行。但是会影响效率,因为多了一次转发,而且自带模块无法做到预警。
2.主动健康检查(需使用第三方模块)
主动地健康检查,nignx定时主动地去ping后端的服务列表,当发现某服务出现异常时,把该服务从健康列表中移除,当发现某服务恢复时,又能够将该服务加回健康列表中。淘宝有一个开源的实现nginx_upstream_check_module模块
官网:http://tengine.taobao.org/document_cn/http_upstream_check_cn.html
3.集成第三方模块部署
下载nginx_upstream_check_module模块,修改配置文件,让nginx_upstream_check_module模块生效,重载nginx。
udp反向代理时健康检查的问题,另一位大神在上面nginx_upstream_check_module的基础上作了修改,实现了在第4层的代理tcp和udp时的健康检查。
Nginx被动健康检查和主动健康检查
访问MQTT健康检查地址
使用NGINX Plus进行主动MQTT健康检查教程_nginx mqtt location-CSDN博客