HAproxy配置文件说明
根据功能个用途,HAproxy配置文件主要由5部分组成,可以根据需要选择相应部分进行配置;
(1)global部分
设置全局配置参数,属于进程级别的配置,通常和操作系统配置有关;
(2)defaults部分
默认参数的配置部分,此部分设置的参数值默认会自动引用到frontend,backend和listen部分中。而如果在frontend,backend和listen部分中也配置了与defaults部分一样的参数,那么defaults部分参数对应的值自动被覆盖;
(3)frontend部分
用于设置接收用户请求的前端节点,而且frontend可以根据ACL规则直接指定要使用的后端backend;
(4)backend部分
用于设置后端服务集群的配置,也就是用来添加一组真实的服务器以处理前端用户请求;
(5)listen部分
此部分是frontend和backend部分的结合体(即listen=frontend+backend),目前在HAproxy中,两种配置方式任选其一即可;
1.全局配置段
1.1进程管理即安全相关的参数
chroot :
修改haproxy的工作目录至指定的目录并在放弃权限之前执行chroot()操作,可以提升haproxy的安全级别,不过需要注意的是要确保指定的目录为空目录且任何用户均不能有写权限;
daemon:
让haproxy以守护进程的方式工作于后台,其等同于-D选项,当然,也可以在命令行中以-db选项将其禁用;
gid :
以指定的GID运行haproxy,建议使用专用于运行haproxy的GID,以免因权限问题带来风险;
uid :
以指定的UID身份运行haproxy进程;
user :
以指定的用户运行HAproxy进程;
group :
以指定的group运行HAproxy
log
[[max level] [min level]]:
全局的日志配置,定义将日志记录到日志服务器
上,使用日志设备,且日志级别为
[max level]及其以上和[min level]及其以下的才被记录,其中日志级别有err warning info debug四种;
log-send-hostname []:
在syslog信息的首部添加当前主机名,可以为string指定的名称,也可以缺省使用当前主机名;
nbproc :
指定启动的haproxy进程个数,只能用于守护进程模式;默认只启动一个进程,鉴于调试困难等多方面的原因,一般只在单进程仅能打开少数文件描述符的场景中才使用多进程模式;
pidfile:
指定HAproxy进程的pid文件,启动进程的用户必须有访问此文件的权限;
ulimit-n:
设定每个进程能够打开的最大文件描述符数目,默认情况下其会自动进行计算,因此不推荐修改此选项;
node:
定义当前节点的名称,用于HA场景中多haproxy进程共享同一个IP地址时;
description:
当前实例的描述信息;
stats:
定义启用监控页面的接口;
1.2性能调整相关的参数
maxconn :
设定每个haproxy进程所接受的最大并发连接数,其等同于命令行选项-n;ulimit-n自动计算的结果正是参照此参数设定的;
maxpipes :
haproxy使用pipe完成基于内核的tcp报文重组,此选项用于设定每进程所允许使用的最大pipe个数;每个pipe会打开两个文件描述符,因此,“ulimit
-n”自动计算时会根据需要调大此值;默认为maxconn/4,其通常会显得过大;
noepoll:
在Linux系统上禁用epoll机制;
nokqueue:
在BSE系统上禁用kqueue机制;
nopoll:
禁用poll机制;
nosepoll:
在Linux禁用启发式epoll机制;
nosplice:
禁止在Linux套接字上使用内核tcp重组,这会导致更多的recv/send系统调用;不过,在Linux2.6.25-28系列的内核上,tcp重组功能有bug存在;
spread-checks <0..50, in percent>:
在haproxy后端有着众多服务器的场景中,在精确的时间间隔后统一对众服务器进行健康状况检查可能会带来意外问题;此选项用于将其检查的时间间隔长度上增加或减小一定的随机时长,使得这些后端服务器不会被同时检查;
tune.bufsize :
设定buffer的大小,同样的内存条件下,较小的值可以让haproxy有能力接受更多的并发连接,较大的值可以让某些应用程序使用较大的cookie信息,默认为16384,可以在编译时修改,不过强烈建议使用默认值;
tune.chksize :
设定检查缓冲区的大小,单位为字节;更大的值有助于在较大的页面中完成基于字符串或模式的文本查找,但也会占用更多的系统资源,不建议修改;
tune.maxaccept :
设定haproxy进程内核调度运行时一次性可以接受的连接的个数,较大的值可以带来较大的吞吐率,默认在单进程模式下为100,多进程模式下为8,设定为-1时可以禁止此限制;一般不建议修改;
tune.maxpollevents :
设定一次系统调用可以处理的事件最大数,默认值取决于OS;其值小于200时可节约带宽,但会略微增大网络延迟,而大于200时会降低延迟,但会稍稍增加网络带宽的占用量;
tune.maxrewrite :
设定为首部重写或追加而预留的缓冲空间,建议使用1024左右的大小;在需要使用更大的空间时,haproxy会自动增加其值;
tune.rcvbuf.client :
接收客户端缓冲的大小;
tune.rcvbuf.server :
设定内核套接字中服务端或客户端接收缓冲的大小,单位为字节;强烈推荐使用默认值;
tune.sndbuf.client:
发送给客户端的响应报文时缓冲的大小;
tune.sndbuf.server:
发送给服务器请求时缓冲的大小;
2.代理相关的配置
defaults
用于为所有其它配置段提供默认参数,它配置的默认配置参数可由下一个defaults所重新设定;
frontend
用于定义一系列监听的套接字,这些套接字可接受客户端请求并与之建立连接(相当于前端服务器);
backend
用于定义一系列“后端”服务器,代理会将对应客户端的请求转发至这些服务器;
listen
通过关联“前端”和“后端”定义了一个完整的代理,通常只对TCP流量有用
说明:
其实frontend相当于Nginx的upstream,就是定义了一系列的用来响应客户端请求的前端服务器,然后backend相当于location中的proxy_pass等,用来将前端接收的客户端请求送给后端来响应;
而且所有代理的名称只能使用大写字母、小写字母、数字、-(中线)、_(下划线)、.(点号)和:(冒号)。此外,ACL名称会区分字母大小写。
3.配置文件中的关键字
3.1 blind
用于定义一个或多个监听的套接字,仅能用在frontend和listen部分;
语法:bind [
]: [, ...] interface
其中:
为可选项,可以为主机名或者IP地址,而*表示所有地址;
:可以是一个特定的TCP端口,也可是一个端口范围,代理服务器将通过指定的端口来接收客户端请求;需要注意的是,每组监听的套接字在同一个实例上只能使用一次,而且小于1024的端口需要有特定权限的用户才能使用,这可能需要通过uid参数来定义;
:指定物理接口的名称,仅能在Linux系统上使用;其不能使用接口别名,而仅能使用物理接口名称,而且只有管理者有权限指定绑定的物理接口;
3.2 balance
定义负载均衡算法,可用于defaults listen和backend部分;
语法:balance [ ]
balance url_param
[check_post []]
其中:
为负载均衡算法即负载均衡时如何选择一台后端服务器,支持的算法有:
roundrobin:基于权重进行轮循,在服务器的处理时间保持均匀分布时,这是最平衡、最公平的算法。此算法是动态的,这表示其权重可以在运行时进行调整,不过,在设计上,每个后端服务器仅能最多接受4095个连接;
static-rr:静态轮循,基于权重进行轮循,与roundrobin类似,但是为静态方法,在运行时调整其服务器权重不会生效;不过,其在后端服务器连接数上没有限制;
leastconn:新的连接请求被派发至具有最少连接数目的后端服务器上;在有着较长时间会话的场景中推荐使用此算法,如LDAP、SQL等,其并不太适用于较短会话的应用层协议,如HTTP;此算法是动态的,可以在运行时调整其权重;
source:将请求的源IP进行hash运算,除以后端服务器的权重总数并取模后派发至某匹配的服务器;这可以使得同一个客户端IP的请求始终被派发至某特定的服务器;不过,当服务器权重总数发生变化时,如某服务器宕机或添加了新的服务器,许多客户端的请求可能会被派发至与此前请求不同的服务器;常用于负载均衡无cookie插入的基于TCP的协议;其默认为静态,不过也可以使用hash-type修改此特性;
uri:对URI的左部分(?号之前)或整个URI进行hash运算,除以服务器的总权重并取模后派发至某匹配的服务器;这可以使得对同一个URI的请求总是被派发至某特定的服务器,除非服务器的权重总数发生了变化;此算法常用于代理缓存或反病毒代理以提高缓存的命中率;需要注意的是,此算法仅应用于HTTP后端服务器场景;其默认为静态算法,不过也可以使用hash-type修改此特性;
url_param:通过为URL指定的参数(the URL parameter),在每个HTTP GET请求中将会被检索;如果找到了指定的参数且其通过等于号“=”被赋予了一个值,那么此值将被执行hash运算并被服务器的总权重相除后派发至某匹配的服务器;此算法可以通过追踪请求中的用户标识进而确保同一个用户ID的请求将被送往同一个特定的服务器,除非服务器的总权重发生了变化;如果某请求中没有出现指定的参数或其没有有效值,则使用轮循算法对相应请求进行调度;此算法默认为静态的,不过其也可以使用hash-type修改此特性;
hdr():对于每个HTTP请求,通过指定的HTTP首部将会被检索;如果相应的首部没有出现或其没有有效值,则使用轮循算法对相应请求进行调度;其有一个可选选项“use_domain_only”,可在指定检索类似Host类的首部时仅计算域名部分(比如通过来说,仅计算abcde字符串的hash值)以降低hash算法的运算量;此算法默认为静态的,不过其也可以使用hash-type修改此特性;
可参考文章:
http://www.cnblogs.com/aaa103439/p/3537163.html?utm_source=tuicool&utm_medium=referral
:一些调度算法的可选参数列表. 现在,只有url_param和uri支持该选项,当URI很长时,参数
len可以只计算从左向右指定长度的URI,参数depth可以指定目录的”深度“
3.3 hash-type
定义用于将hash码映射至后端服务器的方法;仅不能用于frontend区段;可用方法有map-based和consistent
语法:hash-type
map-based:hash表是一个包含了所有在线服务器的静态数组。其hash值将会非常平滑,会将权重考虑在列,但其为静态方法,对在线服务器的权重进行调整将不会生效,这意味着其不支持慢速启动。此外,挑选服务器是根据其在数组中的位置进行的,因此,当一台服务器宕机或添加了一台新的服务器时,大多数连接将会被重新派发至一个与此前不同的服务器上,对于缓存服务器的工作场景来说,此方法不甚适用。
consistent:hash表是一个由各服务器填充而成的树状结构;基于hash键在hash树中查找相应的服务器时,最近的服务器将被选中。此方法是动态的,支持在运行时修改服务器权重,因此兼容慢速启动的特性。添加一个新的服务器时,仅会对一小部分请求产生影响,因此,尤其适用于后端服务器为cache的场景。不过,此算法不甚平滑,派发至各服务器的请求未必能达到理想的均衡效果,因此,可能需要不时的调整服务器的权重以获得更好的均衡性。
3.4 mode
设置实例的运行模式或协议,可用于defaults frontend listen和backend部分;
语法:mode { tcp|http|health }
tcp:HAproxy在纯TCP模式下工作,将会在客户端和服务器端之间建立一个全双工的连接,且不会对应用层协议做任何检查,这是默认的模式,可用于SSL, SSH, SMTP,MYSQL等应用
http:实例运行于HTTP模式,客户端请求在转发至后端服务器之前将被深度分析,所有不与RFC格式兼容的请求都会被拒绝,支持七层过滤,执行和转发,HAproxy的最大价值就体现在这个模式上;
health:实例工作于health模式,其对进入的请求仅响应“OK”信息并关闭连接,或者,如果设置了httpchk选项,那么就返回"HTTP/1.0200OK",且不会记录任何日志信息;此模式将用于响应外部组件的健康状态检查请求;目前此模式已经废弃,因为tcp或http模式中的monitor关键字可完成类似功能;
当作上下文切换时,它被强制和frontend以及backend处于同一模式(一般为HTTP),否则配置不会生效;
例如:
defaults http_instances
mode http
3.5 log
为每个实例启用事件和流量日志,可用于所有区段部分;
语法:
log global
log
[len ] [ []]
no log
log global:从全局配置中继承(如果配置了的话)
前缀:
no:当日志列表会被刷新清除时可以使用;例如,如果不想从默认的日志列表中继承,那么该前缀就不允许参数生效;
参数:
global:should be used when the instance's logging parameters are the same as the global ones. This is the most common usage. "global" replaces
, and with those of the log entries found in the "global" section. Only one "log global" statement may be used per instance, and this form takes no other parameter;
:表明将日志记录到哪里,其格式之一可以为,其中的port为UDP协议端口,默认为514;格式之二为Unix套接字文件路径,但需要留心chroot应用及用户的读写权限
:定义log lines的最大长度,超过这个值,在返回前将会被截去;
:必须为24种标准日志设备之一,设备有:
kern user mail daemon auth syslog lpr news
uucp cron auth2 ftp ntp audit alert cron2
local0 local1 local2 local3 local4 local5 local6 local7
:定义日志级别,即输出信息过滤器,默认为所有信息;指定级别时,所有等于或高于此级别的日志信息将会被发送;八种日志级别为emerg alert crit err warning notice info debug
例如:
log global
log 127.0.0.1:514 local0 notice # only send important events
log 127.0.0.1:514 local0 notice notice # same but limit output level
log "${LOCAL_SYSLOG}:514" local0 notice # send to local server
一般,log可与capture request header和capture response header结合使用来抓取请求报文和响应报文的
header,详细用法可查询两者的用法;
3.6 default_backend
当没有匹配的"use_backend"规则时,为实例指定使用的默认后端,可用于dafaults frontend和listen部分
语法:default_backend
:要使用的backend名;
当使用default_backend关键字在frontend和backend之间做上下文切换时,如果没有规则匹配到,用其来表示使用哪个backend是很有用的。它通常是个dynamic backend,用来捕捉所有未确定的请求;
例如:
use_backend dynamic if url_dyn
use_backend static if url_css url_img extension_img
default_backend dynamic
3.7 use_backend
if或unless ACL条件被匹配到时,切换到指定的后端,可用于frontend和listen部分;
语法:use_backend [{if | unless} ]
:有效的backend名或listen段或时解析到一个backend名的"log-format" string
:一个由ACL组成的条件,如果忽略不写,那么这个规则就会被无条件应用;
3.8 server
为backend声明一个server因此,可用于listen和backend部分。
语法:server
[:port] [param*]
:为此服务器指定的内部名称,其将出现在日志及警告信息中;如果设定了"http-send-server-name",它还将被添加至发往此服务器的请求首部中;
:此服务器的的IPv4地址,也支持使用可解析的主机名,只不过在启动时需要解析主机名至相应的IPv4地址;
[:port]:指定将连接请求所发往的此服务器时的目标端口,其为可选项;未设定时,将使用客户端请求时的同一相端口;
[param*]:为此服务器设定的一系参数;其可用的参数非常多,具体请参考官方文档中的说明,下面仅说明几个常用的参数;
服务器或默认服务器参数:
backup:设定为备用服务器,仅在负载均衡场景中的其它server均不可用于启用此server;
check:启动对此server执行健康状态检查,其可以借助于额外的其它参数完成更精细的设定,如:inter
:设定健康状态检查的时间间隔,单位为毫秒,默认为2000;也可以使用fastinter和downinter来根据服务器端状态优化此时间延迟;
rise :设定健康状态检查中,某离线的server从离线状态转换至正常状态需要成功检查的次数;
fall :确认server从正常状态转换为不可用状态需要检查的次数;
cookie :为指定server设定cookie值,此处指定的值将在请求入站时被检查,第一次为此值挑选的server将在后续的请求中被选中,其目的在于实现持久连接的功能;
maxconn :指定此服务器接受的最大并发连接数;如果发往此服务器的连接数目高于此处指定的值,其将被放置于请求队列,以等待其它连接被释放;
maxqueue :设定请求队列的最大长度;
observe :通过观察服务器的通信状况来判定其健康状态,默认为禁用,其支持的类型有“layer4”和“layer7”,“layer7”仅能用于http代理场景;
redir :启用重定向功能,将发往此服务器的GET和HEAD请求均以302状态码响应;需要注意的是,在prefix后面不能使用/,且不能使用相对地址,以免造成循环;
例如:
server srv1 172.16.100.6:80 redir http://imageserver.abcde.com check
weight :权重,默认为1,最大值为256,0表示不参与负载均衡;
检查方法httpchk:
option httpchk
option httpchk
option httpchk
option httpchk :不能用于frontend段
例如:
backend https_relay
mode tcp
option httpchk OPTIONS * HTTP/1.1\r\nHost:\
server apache1 192.168.1.1:443 check port 80
使用案例:
server first 172.16.100.7:1080 cookie first check inter 1000
server second 172.16.100.8:1080 cookie second check inter 1000
补充:完整的配置案例
http服务器配置示例
global
log 127.0.0.1 local2
chroot /var/lib/haproxy
pidfile /var/run/haproxy.pid
maxconn 4000
user haproxy
group haproxy
daemon
defaults
mode http
log global
option httplog
option dontlognull
option http-server-close
option forwardfor except 127.0.0.0/8
option redispatch
retries 3
timeout http-request 10s
timeout queue 1m
timeout connect 10s
timeout client 1m
timeout server 1m
timeout http-keep-alive 10s
timeout check 10s
maxconn 30000
listen stats
mode http
bind 0.0.0.0:1080
stats enable
stats hide-version
stats uri /haproxyadmin?stats
stats realm Haproxy\ Statistics
stats auth admin:admin
stats admin if TRUE
frontend http-in
bind *:80
mode http
log global
option httpclose
option logasap
option dontlognull
capture request header Host len 20
capture request header Referer len 60
default_backend servers
frontend healthcheck
bind :1099
mode http
option httpclose
option forwardfor
default_backend servers
backend servers
balance roundrobin
server websrv1 192.168.10.11:80 check maxconn 2000
server websrv2 192.168.10.12:80 check maxconn 2000
哪个参数看不懂就去查一下官方说明!
先简单的介绍到这里吧,东西太多了,而且也不一定翻译的对,最好还是去看源文档,详细的信息可以到官方网站上去查看:
如果不能访问也没关系,这里有下载的txt说明文档:
后来发现这个网站不用翻墙也可以查阅: