haproxy配置
haproxy配置文件简介
1）haproxy的配置文件haproxy.cfg由两大部分组成，分别是global和proxies部分
2）global：全局配置段
- 进程及安全配置相关的参数
- 性能调整相关参数
- Debug参数
3）proxies：代理配置段
- defaults：为frontend, backend, listen提供默认配置
- frontend：前端，相当于nginx中的server {}
- backend：后端，相当于nginx中的upstream {}
- listen：同时拥有前端和后端配置(注：建议采用这种方式定义后端服务器相关配置)
4）配置图示：
global：全局配置段
chroot
- #锁定运行目录
- 此选项编译安装时，建议打开，将haproxy进程禁锢在指定目录
deamon
- #以守护进程运行
stats socket /var/lib/haproxy/haproxy.socket mode 600 level admin
- #socket文件，本地通信
user, group, uid, gid
- #运行haproxy的用户身份
- 因为haproxy不涉及数据问题可以将haproxy进程启动用户设为nobody
nbproc
- #开启的haproxy进程数，与CPU保持一致
- 一个haproxy的work process在高并发场景处理时可能捉襟见肘，解决办法：haproxy支持多进程
- 优化：work process与CPU绑定
#nbproc 4 开启4个haproxy的work process
#cpu-map 1 0 将第一个work process绑定在第0颗CPU上
#cpu-map 2 1
#cpu-map 3 2
#cpu-map 4 3
nbthread
- #指定每个haproxy进程开启的线程数，默认为每个进程一个线程
- 此选项一般不用，直接由work process响应客户请求
- 好像一个work process也无法开启多个thread process，与多进程互斥
cpu-map 1 0
- #绑定haproxy 进程至指定CPU
maxconn
- #每个haproxy进程的最大并发连接数
- maxconn 1000000（一般设置）
maxsslconn
- #每个haproxy进程ssl最大连接数,用于haproxy配置了证书的场景下
maxconnrate
- #每个进程每秒创建的最大连接数量
- 此值一般不做设置
spread-checks
- #对后端server状态检测随机提前或延迟百分比时间，建议2-5(20%-50%)之间
pidfile
- #指定pid文件路径
log 127.0.0.1 local3 info
- #定义全局的syslog，最多可以定义两个
Proxies配置
-
https://cbonte.github.io/haproxy-dconv/2.0/configuration.html#4
-
defaults [<name>] #默认配置项，针对以下的frontend、backend和lsiten生效，可以多个name
-
frontend <name> #前端servername，类似于Nginx的一个虚拟主机 server。
-
backend <name> #后端服务器组，等于nginx的upstream
-
listen <name> #将frontend和backend合并在一起配置
-
注：name字段只能使用”-”、”_”、”.”、和”:”，并且严格区分大小写，例如：Web和web是完全不同的两组服务器
Proxies配置-defaults
option redispatch
- #当server Id对应的服务器挂掉后，强制定向到其他健康的服务器
- 此选项打开
option abortonclose
- #当服务器负载很高的时候，自动结束掉当前队列处理比较久的链接
- 此选项一般需要关闭，如果业务不以时间为代价也要完成的任务，一定关闭，涉及数据库一般都比较慢
option http-keep-alive
- #开启与客户端的会话保持
option forwardfor
- #透传客户端真实IP至后端web服务器
- 透传用户的源地址，一般需要开启此选项，以便后端服务器日志收集和对用户进行用户行为分析等等
mode http
- #默认工作类型
- 一般使用TCP和HTTP，此处定义一个默认代理的工作模型http
timeout connect 120s
- #客户端请求到后端server的最长连接等待时间(TCP之前)
timeout server 600s
- #客户端请求到后端服务端的超时超时时长（TCP之后）
- 如果此时间设置较小，可能导致超时haproxy直接响应用户，此时将报错：状态码502
timeout client 600s
- #与客户端的最长非活动时间
timeout http-keep-alive 120s
- #session 会话保持超时时间，范围内会转发到相同的后端服务器
timeout check 5s
- #对后端服务器的检测超时时间
Proxies配置-frontend
- bind：指定HAProxy的监听地址，可以是IPV4或IPV6，可以同时监听多个IP或端口，可同时用于listen字段中
- bind []:<port_range> [, …] [param*]
- bind 10.0.0.1:10080,10.0.0.1:10443 ==>一般会用到这种形式
- bind示例：
listen http_proxy
bind :80,:443
bind 10.0.0.1:10080,10.0.0.1:10443 ==>一般会用到这种形式
bind /var/run/ssl-frontend.sock user root mode 600 accept-proxy
==>前提是必须要有这个socket文件
ssl配置bind：只需要*.pem文件，没有公钥和私钥
listen http_https_proxy
bind :80
bind :443 ssl crt /etc/haproxy/site.pem
Proxies配置-backend
定义一组后端服务器，backend服务器将被frontend进行调用
-
mode http/tcp #指定负载协议类型
-
option #配置选项
-
server #定义后端real server
注意：option后面加httpchk，smtpchk,mysql-check,pgsql-check，ssl-hello-chk方法，可用于实现更多应用层检测功能。 -
check #对指定real进行健康状态检查，默认不开启
addr IP #可指定的健康状态监测IP
port num #指定的健康状态监测端口
inter num #健康状态检查间隔时间，默认2000ms(2s)
fall num #后端服务器失效检查次数，默认为3。连续检测失败多少次，将检测失败的主机从后端服务器组中摘除
rise num #后端服务器从下线恢复检查次数，默认为2。连续检测成功多少次，将健康的主机加入至后端服务器组 -
weight #默认为1，最大值为256，0表示不参与负载均衡
-
backup #将后端服务器标记为备份状态
-
disabled #将后端服务器标记为不可用状态
-
redirect prefix http://www.xxxxx.net/ #将请求临时重定向至其它URL，只适用于http模式
-
maxconn <maxconn>：当前后端server的最大并发连接数
-
backlog <backlog>：当server的连接数达到上限后的后援队列长度
frontend+backend配置实例
#官网业务访问入口======================================
frontend WEB-PORT-80
bind 192.168.7.248:80
mode http
use-backend web-prot-http-nodes
backend web-prot-http-nodes
mode http
option forwardfor
server 192.168.7.101 192.168.7.101:80 check inter 3000 fall 3 rise 5
server 192.168.7.102 192.168.7.102:80 check inter 3000 fall 3 rise 5
Proxies配置-listen
- 一般使用listen
使用listen替换frontend和backend的配置方式：
#官网业务访问入口=====================================
listen WEB_PORT_80
bind 192.168.7.102:80
mode http
option forwardfor
server web1 192.168.7.101:80 check inter 3000 fall 3 rise 5
server web2 192.168.7.101:80 check inter 3000 fall 3 rise 5
配置haproxy配置的注意事项
- 注意事项：
①定义标识一组代理设置的名称在单台haproxy的配置文件中唯一
②定义的形式需要按照：key value形式定义，之间切勿交叉
相关概念
服务器端报502和503错误
502错误：后端服务器未在规定的时间将用户请求的资源返回给haproxy
503错误：后端服务器全部宕机
四层（tcp）和七层（http）代理
1）四层（tcp）代理：IP+PORT转发
2）七层（http）代理：协议+内容交换
3）图示区别：
4）区别详述：
-
四层：
在四层负载设备中，把client发送的报文目标地址(原来是负载均衡设备的IP地址)，根据均衡设备设置的选择web服务器的规则选择对应的web服务器IP地址，这样client就可以直接跟此服务器建立TCP连接并发送数据。 -
七层代理：
七层负载均衡服务器起了一个反向代理服务器的作用，服务器建立一次TCP连接要三次握手，而client要访问webserver要先与七层负载设备进行三次握手后建立TCP连接，把要访问的报文信息发送给七层负载均衡；然后七层负载均衡再根据设置的均衡规则选择特定的webserver，然后通过三次握手与此台webserver建立TCP连接，然后webserver把需要的数据发送给七层负载均衡设备，负载均衡设备再把数据发送给client；所以，七层负载均衡设备起到了代理服务器的作用。
5）四层负载和七层负载主要区别是：
- 四层负载均衡只涉及请求报文和响应报文的ip和port的修改，在代理层不会将数据拆包到应用层，haproxy不知道用户具体的请求，不涉及传输层（OSI模型）以上的数据内容。
- 七层负载均衡将由haproxy（代理层）将用户的请求报文全部解开，然后由haproxy（代理层）向后端服务器代替用户请求，后端服务器响应haproxy（代理层）数据，得到用户请求的资源时，再由haproxy封装用户请求的响应报文。
6）haproxy主要是用于四层负载均衡，七层负载均衡一般在nginx实现，LVS仅支持四层负载均衡。个人总结：可能haproxy性能再好，使用haproxy做七层负载均衡，所有数据报文均由haproxy封装，可能会成为性能瓶颈吧。haproxy一般可承受几十万级的并发，因此haproxy一般可能会用到。
7）注：无论是七层还是四层代理均需要打开IP透传功能，以便于做访问统计、安全防护、行为分析、区域排行等场景
- option forwardfor则后端服务器web格式为X-Forwarded-For
检查后端服务器的健康状态
- 对web服务器健康状态的检测：(Web服务器一般是：nginx+php-fpm)
检测时检测能否处理php程序即可。（检测监听端口的话也是9000端口）
负载均衡对后端服务器健康性检查的检测
1.haproxy
- 支持基于IP+port的方式检测后端服务器(backend server)的健康状态
- 支持基于URI的方式检测后端服务器(backend server)的健康状态
2.lvs
- 支持基于IP+port的方式检测后端服务器(real server)的健康状态
- 支持基于URI的方式检测后端服务器(real server)的健康状态
3.nginx
- 支持基于IP+port的方式检测后端服务器(upstream server)的健康状态
即upstream server的IP地址监听的端口存在，nginx就认为upstream server健康
说明：以Java程序为例，有可能出现监听端口正常，但是却不能处理用户请求的情况。当Java程序处理用户请求达到定义的最大数量，却未回收进程，产生新进程去响应用户请求时，可能出现监听端口，却不能处理用户请求，此时后端服务器应该是不健康的状态。
haproxy对web服务器的检测
1）基于四层（tcp）检测
- 这种检测形式的缺点在于：可能出现监听端口正常，但是却不能处理用户请求的情况。（即即使端口处于监听状态，也不代表后端服务器一定正常）
2）基于指定URI做状态检测
- 这种形式的缺点在于：haproxy只关注后端服务器的健康状态，但是后端服务器正常时还会对haproxy发送haproxy请求的响应报文，而检测时间是2s一次，后端服务器还蛮多，php或者Java程序的响应数据报文也不小，这样的响应报文将造成带宽浪费。
检测选项示例：
option httpchk GET /app/monitor/check.html HTTP/1.0
3）基于指定URI的request请求头部内容做状态检测
- 这种形式的检测只关心后端服务器返回的响应状态码是否正常，优先选择这种形式的检测。（注：当然基于URI得是http模式哦，tcp模式仅支持端口+ip的检测方式）
检测选项示例：
option httpchk HEAD /app/monitor/check.html HTTP/1.0\r\nHost:\ 192.168.7.102
扫一扫
1044
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
