HAProxy--理论--02--配置文件

HAProxy–理论–02–配置文件

---

1、配置文件组成

1. global：设置全局配置参数
2. defaults：设置的默认参数
3. frontend：接收请求的前端虚拟节点，Frontend可以直接指定具体使用后端的backend；
4. backend：后端服务集群的配置，是真实服务器，一个Backend对应一个或者多个实体服务器；
5. listen：frontend和backend的组合体。

1.1、global

1. 设置全局配置参数，参数将被应用到全部运行 HAProxy的节点中
2. 属于进程的配置，通常是和操作系统相关。
3. 全局配置段并不针对具体的代理和负载均衡进行设置

典型的global配置段

global

	#指定HAProxy以后台进程的形式运行
	daemon
	
	# HAProxy代理允许的最大并行连接数，此处为4000，默认为2000。
	maxconn 　 4000 
	
	# HAProxy的进程文件
	Pidfile　　/var/run/HAproxy.pid
	
	# 运行 HAproxy的用户，此处为 HAproxy。
	user　　   HAproxy 
	
	# 运行 HAproxy的用户组，此处为 HAproxy。
	group　　  HAproxy 
	stats　　  socket　/var/lib/HAproxy/stats

	#设置HAProxy运行日志的输出设备，通常默认为本机的并默认记录 INFO级别的日志，用户可以将 HAProxy的日志输出到本机或者远程主机的日志设备上，并设置需要记录的日志级别，如 ERROR和 WARN。
	log　　    127.0.0.1 　ocal0

1.2、defaults

1. 设置的参数会被frontend,backend，listen继承
   1. 也就是说defaults的参数,frontend,backend，listen都可以用
2. frontend,backend，listen配置段也可以重写default配置段的参数值
3. 通常情况：共性的参数放到default段进行统一配置，然后再到各个配置段中进行个性修改，

常见的 default配置段

defaults
	# 指定 HAProxy实例使用的连接协议，即源请求到后端服务器之间的连接协议，可能值为 HTTP和 TCP。对基于HTTP的 web应用服务，通常使用 HTTP模式，对于其他应用服务，通常使用 TCP模式。
	mode    http
	# 使用 global配置段中设定的log值
	log     global
	# 日志记录选项， httplog表示记录与 HTTP会话相关的各种属性值，包括 HTTP请求、会话状态、连接数、源地址以及连接时间等。
	option  httplog
	# 表示不记录空会话连接日志，即 HAProxy不会记录没有数据传输的会话连接日志，
	# 基于互联网的 web应用中不推荐使用dontlognul,l因为很多空会话连接可能包含有恶意行为，如恶意的端口漏洞扫描就是一种没有数据传输的空连接。  
	option  dontlognull
	# 在连接失败后重新尝试请求连接的次数，超过设置的尝试次数将认为连接失败。
	retries 3
	# 设置各种请求、连接、响应的 Timeout时间，单位为秒(s)或者毫秒(m)。
	
	maxconn  10000
	# 等待客户端完整 HTTP请求的超时时间，此处为等待10s。
	timeout  http-request 10s 
	timeout  queue 1m
	timeout  connect 10s
	timeout  client 1m
	timeout  server 1m
	timeout  check 10s

1.3、Frontend

前端配置主要完成两个功能：

1. 配置监听客户端请求的 IP地址和端口
   1. 在高可用环境下，此处的监听 IP地址通常为虚拟 IP
2. 将监听到的客户端请求转发到指定的后端配置中进行负载均衡。

典型的Frontend配置段

frontend  WEB
	bind  192.168.0.10:80
	default_backend  app

说明

1. 定义一个前端，名称叫WEB
2. 一旦前端监听到IP为192.168.0.10，端口为80连接，就会将该连接直接转给名为app的后端处理。

1.4、Backend

后端配置主要实现两个主要功能

1. 负载均衡调度算法的设置
2. 设置最终响应请求的服务器池各个节点的IP地址和端口，并设置每个节点的健康检查方式。

典型的Backend配置段

backend app
balance roundrobin
server appl 192.168.1.1：80 check
server app2 192.168.1.2：80 check
server app3 192.168.1.3：80 check inter 2s rise 4 fall 3
server app4 192.168.1.4：80 backup

1. HAProxy允许配置多个后端
2. 每个后端都有一个前端与其对应
3. 后端实例的名称可以用户自定义，但是一定要与对应前端中设置的后端名称一致。

说明

1. 后端实例的名称是 app
2. 采用 Round-Robin负载均衡算法
3. server定义后端的真实服务器
4. check检测服务器的健康
5. 以app3为例：
   1. 我们定义一个后端服务器，名称是app3，对应的ip是192.168.1.3，端口是80.
   2. app3的健康检查的时间隔是2s
   3. HAproxy对app3发起4次健康检查均正常则认为app3正常
   4. HAproxy对app3发起连续3次健康检查失败则认为app3己经故障

2、配置参数优先级，从低到高

1. global配置段
2. defaults
3. listen、frontend和backend
   1. 如果在frontend、backend和listen部分中也配置了与defaults部分一样的参数，那么defaults部分参数对应的值自动被覆盖。

3、时间格式

1. 时间参数一般以毫秒为单位
2. 也可以使用其它的时间单位后缀。

us: 微秒(microseconds)，即1/1000000秒；
ms: 毫秒(milliseconds)，即1/1000秒；
s: 秒(seconds)；
m: 分钟(minutes)；
h：小时(hours)；
d: 天(days)；

4、全局配置(global)

4.1、进程管理及安全相关的参数

chroot < jail dir >

1. 修改haproxy的工作目录至指定的目录并在放弃权限之前执行chroot()操作
2. 可以提升haproxy的安全级别，不过需要注意的是要确保指定的目录为空目录且任何用户均不能有写权限；

daemon

1. 让haproxy以守护进程的方式在后台工作
2. 其等同于"-D"选项的功能，当然，也可以在命令行中以"-db"选项将其禁用

gid

1. 以指定的GID运行haproxy
2. 建议使用专用于运行haproxy的GID，以免因权限问题带来风险；

group

同gid，不过指定的组名

uid

1. 以指定的UID身份运行haproxy进程；
2. 建议使用专用于运行haproxy的uid，以免因权限问题带来风险；

user

同uid，但使用的是用户名；

log

[max level [min level]]

定义全局的syslog服务器，最多可以定义两个；

log-send-hostname []：

在syslog信息的首部添加当前主机名，可以为“string”指定的名称，也可以缺省使用当前主机名；

nbproc

1. 指定启动的haproxy进程的个数
2. 只能用于守护进程模式的haproxy
3. 默认只启动1个进程，鉴于调试困难等多方面的原因，一般只在单进程仅能打开少数文件描述符的场景中才使用多进程模式；

pidfile

进程文件（默认路径 /var/run/haproxy.pid）

ulimit -n

1. 设定每个进程所能够打开的最大文件描述符数目
2. 默认情况下其会自动进行计算，因此不推荐修改此选项；
3. Linux默认单进程打开文件数为1024个

stats：用户访问统计数据的接口

node

定义当前节点的名称，用于HA场景中多haproxy进程共享同一个IP地址时；

description

当前实例的描述信息

4.2、性能调整相关的参数

maxconn

1. 设定每个haproxy进程所接受的最大并发连接数
2. 等同于命令行选项"-n","ulimit -n"自动计算的结果正是参照此参数设定的
3. 不能用于 backend 区段
4. 对于大型站点来说，可以尽可能提高此值以便让 haproxy 管理连接队列， 从而避免无法应答用户请求。
5. 注意：
   1. haproxy 会为每个连接维持两个缓冲，每个缓存的大小为 8KB，再加上其他的数据，每个连接将大约占用 17KB 的 RAM 空间，这意味着经过适当优化后 ，有着 1GB 的可用 RAM 空间时将维护 40000-50000 并发连接。
   2. 如果指定了一个过大值，极端场景中，其最终所占据的空间可能会超过当前主机的可用内存，这可能会带来意想不到的结果，因此，将其设定一个可接受值放为明智绝对
6. 默认为 2000

maxpipes

1. haproxy使用pipe完成基于内核的tcp报文重组，此选项则用于设定每个进程所允许使用的最大pipe个数
2. 每个pipe会打开两个文件描述符，因此，"ulimit -n"自动计算时会根据需要调大此值；
3. 默认为maxconn/4，其通常会显得过大；

noepoll

在Linux系统上禁用epoll机制；

nokqueue

在BSE系统上禁用kqueue机制；

nopoll

禁用poll机制；

nosepoll

在Linux禁用启发式epoll机制；

nosplice

禁止在Linux套接字上使用内核tcp重组，这会导致更多的recv/send系统调用；

spread-checks <0…50, in percent>

1. 在haproxy后端有着众多服务器的场景中，在精确的时间间隔后统一对众服务器进行健康状况检查可能会带来意外问题；
2. 此选项用于将其检查的时间间隔长度上增加或减小一定的随机时长；

tune.bufsize ：

1. 设定buffer的大小
2. 同样的内存条件下
   1. 较小的值：可以让haproxy有能力接受更多的并发连接
   2. 较大的值：可以让某些应用程序使用较大的cookie信息；
3. 默认为16384
4. 可以在编译时修改，不过强烈建议使用默认值；

tune.chksize

1. 设定检查缓冲区的大小
2. 单位为字节
3. 更大的值有助于在较大的页面中完成基于字符串或模式的文本查找，但也会占用更多的系统资源；
4. 不建议修改；

tune.maxaccept

1. 设定haproxy进程内核调度运行时一次性可以接受的连接的个数
2. 较大的值可以带来较大的吞吐率
3. 默认
   1. 在单进程模式下为100
   2. 在多进程模式下为8
4. 设定为-1可以禁止此限制；
5. 一般不建议修改；

tune.maxpollevents

1. 设定一次系统调用可以处理的事件最大数
2. 默认值取决于OS；
   1. 值小于200时:可节约带宽，但会略微增大网络延迟，
   2. 值大于200时:会降低延迟，但会稍稍增加网络带宽的占用量；

tune.maxrewrite

1. 设定为首部重写或追加而预留的缓冲空间
2. 建议使用1024左右的大小；
3. 在需要使用更大的空间时，haproxy会自动增加其值；

tune.rcvbuf.client

设定内核套接字中服务端或客户端接收缓冲的大小
单位为字节
强烈推荐使用默认值；

tune.rcvbuf.server

设定内核套接字中服务端或客户端接收缓冲的大小
单位为字节
强烈推荐使用默认值；

tune.sndbuf.client

设定内核套接字中服务端或客户端发送缓冲的大小
单位为字节
强烈推荐使用默认值；

tune.sndbuf.server

设定内核套接字中服务端或客户端发送缓冲的大小
单位为字节
强烈推荐使用默认值；

4.3、Debug相关的参数

debug

调试模式，输出启动信息到标准输出

quiet

安装模式，启动时无输出

4.4、超时时长

timeout http request

在客户端建立连接但不请求数据时，关闭客户端连接

timeout queue

等待最大时长

timeout connect

定义haproxy将客户端请求转发至后端服务器所等待的超时时长

timeout client

客户端空闲超时时间

timeout server

客户端与服务器端建立连接后，等待服务器端的超时时长，

timeout http-keep-alive

定义保持连接的超时时长

timeout check

健康状态监测时的超时时间，过短会误判，过长资源消耗

http-server-close

在使用长连接时，为了避免客户端超时没有关闭长连接，此功能可以使服务器端关闭长连接

option redispatch

1. 当使用了cookie时，haproxy将会将其请求的后端服务器的serverID插入到cookie中，以保证会话的SESSION持久性；而此时，如果后端的服务器宕掉了，但是客户端的cookie是不会刷新的，如果设置此参数，一旦后端某一server宕机时,将会将客户的请求强制重定向到另外一个后端server上，以保证服务的正常。

option abortonclose

当服务器负载很高的时候，自动结束掉当前队列处理比较久的链接

option httpclose

每次请求完毕后主动关闭http通道,haproxy不支持keep-alive,只能模拟这种模式的实现

option dontlognull

1. 启用该项，日志中将不会记录空连接。
2. 空连接:就是在上游的负载均衡器或者监控系统为了探测该服务是否存活可用时，需要定期的连接或者获取某一固定的组件或页面，或者探测扫描端口是否在监听或开放等动作被称为空连接；3. 官方文档中标注，如果该服务上游没有其他的负载均衡器的话，建议不要使用该参数，因为互联网上的恶意扫描或其他动作就不会被记录下来

retries 3

定义连接后端服务器的失败重连次数，连接失败次数超过此值后将会将对应后端服务器标记为不可用

4.5、实现访问控制

http-request

7层过滤

tcp-request content

tcp层过滤，四层过滤

4.6、其他

mode tcp

1. mode所处理的模式
   1. tcp:四层
   2. http:七层
   3. health:状态检查,只会返回 OK
2. tcp
   1. 实例运行于纯 tcp 模式，在客户端和服务器端之间将建立一个全双工的连接，且不会对 7 层报文做任何类型的检查，
   2. 此为默认模式
3. http
   1. 实例运行于 http 模式，客户端请求在转发至后端服务器之前将被深度分析，所有不与 RFC 模式兼容的请求都会被拒绝
4. health
   1. 实例运行于 health 模式，其对入站请求仅响应"OK"信息并关闭连接，且不会记录任何日志信息 ，此模式将用于相应外部组件的监控状态检测请求

5、代理配置

defaults <name>
frontend <name>
backend <name>
listen <name>

name 规则

1. 只能使用大写字母、小写字母、数字、-(中线)、_(下划线)、.(点号)和:(冒号)。
2. ACL名称会区分字母大小写。

5.1、defaults段

1. 用于为所有其它配置段提供默认参数
2. 默认配置参数可由下一个defaults所重新设定。

5.2、frontend段

1. 用于定义一系列监听的套接字
2. 这些套接字可接受客户端请求并与之建立连接。

5.3、backend段

1. 用于定义一系列后端服务器
2. 代理会将对应客户端的请求转发至这些后端服务器。

5.4、listen段

通过关联frontend和backend定义了一个完整的代理，通常只对TCP流量有用。