HAProxy概述与配置_haproxy的配置文件 .cfg是什么格式

一、HAProxy概述

HAProxy是由 WillyTarreau开发的一款具备高可用性、负载均及基于 TCP和 HTTP的应用代理开源软件，基于HAProxy的负载均衡架构是最为常见的免费、快速且具备可靠性的集群负载均衡架构解决方案。此外，HAProxy特别适合应用于需要会话保持或七层处理的高负载 web站点，就当前常见硬件体系架构，基于HAProxy的负载均衡系统完全可以支撑数以万计的并发连接．同时，HAProxy的运行模式使其整合到用户当前的基础架构中是个非常简单且安全的过程。通过 HAProxy的代理，还可以避免用户的 Web服务器直接暴露到外部网络中。

HAProxy实现的是一种事件驱动、单一进程的架构模型，此类模型的优点在于能够支撑高并发大规模的连接。反之，多进程或多线程模型受内存和系统调度器的限制以及无处不在的锁限制，很难应对数以万计的高并发连接。HAProxy支持连接拒绝，通过拒绝连接，可以限制某些非法或有意的攻击型连接，从而降低其对网站带来的危害。的这一功能已成为目前应对小型 DDOS攻击的主要方法之一，并且其他负载均衡器很难做到这点。此外， HAProxy还支持全透明代理，即可以将客户端地址或者任何指定地址直接连接到后端服务器，通过全透明代理，可以不用修改某些特殊服务器地址而使其直接接收并处理部分特定流量。

HAProxy主要为基于 HTTP和 TCP访问的应用服务提供负载均衡，如基于 Internet的连接服务和基于 web的应用服务。通过负载均衡算法， HAproxy能够接受数以万计的访问请求并将其转发到后端服务器池中进行处理，而后端服务器池就如一个强大的虚拟服务器接受 HAProxy转发的请求并进行处理。 HAproxy的请求调度器（Scheduler）决定了后端服务器中每个服务器接受和处理的请求量，在没有权重的调度算法下，调度器为每台服务器分配相同数量的请求，而在加权调度算法下，调度器根据每台服务器的权重为每个后端服务器分配不同数量的请求。 HAProxy允许用户自定义多个代理，并为每个代理提供负载均衡服务，代理由一个前端和一个或多个后端构成，前端定义了代理监听的IP地址（Virtual IP )和端口，同时还需在前端定义中关联与其相关的后端，而在HAProxy中，后端主要用于定义服务器池和负载均衡算法。HAProxy的负载均衡服务在7层，即应用层，在很多情况下，由于商业应用连续性的要求，管理员通常需要部署HAProxy，从而为基于HTTP的应用提供负载均衡和高可用性。

HAProxy的配置文件是/etc/haproxy/haproxy.cfg，该文件是 HAProxy功能配置的集中文件，其代理和负载均衡功能的配置均位于该配置文件中。 HAProxy的配置文件主要分为四个部分，即全局功能配置段、默认属性配置段、前端代理配置段、后端负载均衡配置段，各个配置段常见属性设置和功能描述如下。
　　
1、全局配置段

全局配置段的参数将被应用到全部运行 HAProxy的节点中，全局配置段并不针对具体的代理和负载均衡进行设置，其需要配置的参数也相对简单，典型的haproxy.cfg全局配置段内容如下：

global
daemon
maxconn 　 4000
Pidfile　　/var/run/HAproxy.pid
user　　   HAproxy
group　　  HAproxy
stats　　  socket　/var/lib/HAproxy/stats
log　　    127.0.0.1 　ocal0
1
2
3
4
5
6
7
8

上述HAProxy的全局配置段中，用户为HAProxy常用的全局变量配置了参数，这些参数通常是进程级别并与操作系统相关的参数，并在全局`限定了HAProxy的工作特性，几个重要的参数解释如下。

daemon：指定HAProxy以后台进程的形式运行。
group：运行 HAproxy的用户属组，此处为 HAproxy。
maxconn：HAProxy代理允许的最大并行连接数，此处为4000，默认为2000。 
user：运行HAProxy的用户，此处为 HAproxy。
 pidfile：HAProxy的进程文件，此处为/var/run/haproxy.pid。 
log：设置HAProxy运行日志的输出设备，通常默认为本机的并默认记录 INFO级别的日志，用户可以将 HAProxy的日志输出到本机或者远程主机的日志设备上，并设置需要记录的日志级别，如 ERROR和 WARN。
1
2
3
4
5
6

全局配置段需要注意 HAPrxoy的日志设备配置，对于大规模集群，负载均衡器可能会由运行 HAProxy的多个节点组成，如果每个 HAProxy节点都将日志存放到本地，则日志监控和查看极为不便，因此通常会借助远程日志记录功能（如 rsyslog)将分散的节点日志集中到某台日志服务器上，这时就需要在每个 HAProxy的全局配置段中指定远程日志服务器的地址和对应的日志记录设备，同时在远程日志记录服务器上进行相应的设置。在云端日志服务器上开启 rsyslog的 HAProxy日志记录功能所需做的设置如下：

1、将/etc/rsyslog.onf中的如下两行注释取消
  $M0dLoad imudp
  $UDPServerRun514
2、为HAProxy设置日志设备和输出文件，这里定义的日志设备要与haproxy·cfg全局配置段中log参故设置的匹配，在/etc/rsyslog.conf中添加如下语句：  local0.* /var/log/haproxy/haproxy.log在/etc/sysconfig/rsyslog中修改SYSLOGD_OPTIONS的值为如下：  SYSLOGD_OPTIONS="-r -m 0 -c 2" 3、分别重启 rsyslog和 haproxy systemctl restart rsyslog.server systemctl restart haproxy.service 
4、跟踪 haproxy的日志tail -f /var/10g/haproxy/haproxy.log
1
2
3
4
5

2、默认配置段
　　默认(default)配置段设置的参数会被haproxy.cfg的其他配置段继承，如frontend、backend和 listen配置段都会继承 default配置段参数，同时这些配置段也可以写default配置段的参数值，通常情况下，用户可以将具有共性的参数放到default段进行统一配置，然后再到各个配置段中进行个性修改，常见的 default配置段如下：

defaults
mode    http
log     global
option  http
logoption  dontlognull
retries 3
timeout http-request 10s
timeout  queue 1ms
timeout  connect 10s
maxconn  10000
timeout  client 1ms
timeout  server 1ms
timeout  check 10s
1
2
3
4
5
6
7
8
9
10
11
12
13

默认配置段主要配置参数的解释如下：

log：指定日志地址和记录日志条目的 syslog/rsyslog日志设备，此处的 global表示使用 global配置段中设定的log值。

option：日志记录选项， httplog表示记录与 HTTP会话相关的各种属性值，包括 HTTP请求、会话状态、连接数、源地址以及连接时间等。dontlognull表示不记录空会话连接日志，　　　　即 HAProxy不会记录没有数据传输的会话连接日志，基于互联网的 web应用中不推荐使用dontlognull因为很多空会话连接可能包含有恶意行为，如恶意的端口漏洞扫描就是　　　　一种没有数据传输的空连接。
retries：在连接失败后重新尝试请求连接的次数，超过设置的尝试次数将认为连接失败。

timeout:设置各种请求、连接、响应的 Timeout时间，单位为秒(s)或者毫秒(m)。
HTTP-Request：等待客户端完整 HTTP请求的时间，此处为等待10s。

queue：设置删除连接和客户端收到503或服务不可用等提示信息前的等待时间，此处等待时间为10毫秒。

connect：设置等待服务器连接成功的时间，此处为等待10s。

client：设置允许客户端处于非活动状态，即既不发送数据也不接收数据的时间，此处为1毫秒。

server：设置服务器超时时间，即允许服务器处于既不接收也不发送数据的非活动时间，此处为1毫秒。
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16

3、Frontend配置

前端配置主要完成两个功能：一是配置监听客户端请求的 IP地址和端口，在高可用环境下，此处的监听 IP地址通常为虚拟 IP；二是将监听到的客户端请求转发到指定的后端配置中进行负载均衡。典型的 HAProxy前端配置如下。

frontend  WEB
bind  192.168.0.10:80
default_backend  app
1
2
3

HAProxy中允许配置多个前端，前端名称可以自定义，此处设置了名为 web的HAProxy前端，通过bind参数指定该前端监听的IP为192.168.0.10，端口为80，而该前端对应的后端名称是app，一旦前端监听到连接，就会将该连接直接转给名为app的后端处理，前端与后端是HAProxy配置中的关键部分，通常前端负责监听请求连接，后端负责负载均衡。在 openstack高可用集群配中，由于要为每个 openstack服务进行高可用配置，因此最佳做法就是将每个服务配置为一个前端和后端的组合，并将前端监听的 VIP通过Pacemaker或者Keeplived进行高可用设计。基于HAProxy的Openstack高可用集群前端配置的例子为：

数据库服务前端：
frontend vip-db
bind 192.168.142.201:3306
timeout client 90m
default—backend db-vms-Galera
qpid消息服务前端：
froatend Vip-qpid
bind192·168、142·215：5672
timeout client120s
default—backend qpid-vms
dashboard服务前端：
frontendvip—horizon
bind192．168、142·211：80
timeout client180s
cookie SERVERID insert indirect nocache
default backend horizon-vms
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16

4、 Backend配置

后端配置主要实现两个主要功能：一是负载均衡调度算法的设置；二是设置最终响应请求的服务器池各个节点的IP地址和端口，并设置每个节点的健康检查方式。一个典型的后端配置如下。
复制代码

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
2
3
4
5
6

HAProxy允许配置多个后端，并且每个后端都有一个前端与其对应，后端实例的名称可以用户自定义，但是一定要与对应前端中设置的后端名称一致。上述后端配置中，后端实例的名称是 app,采用 Round-Robin负载均衡算法，server行定义后端的真实服务器，服务器的名称为app1、app2、app3和 app4，这里的服务器名称并非真实的后端服务器主机名，而只是便于识别的自定义服务器名称，服务器的具体地址通过紧随其后的地址和端口号来确定。此外，在定义后端服务器的同时，通过check参数还可指定HAProxy对服务器的健康检查方式，上述配置中，后端服务器app3中的inter 2s指定了对app3进行健康检查的时间隔是2s，rise 4 表示 HAproxy对app3发起4次健康检查均正常则认为app3正常，3表示连续3次健康检查失败则认为app3己经故障，HAproxy后端配置中指定了负载均衡所采用的算法， HAProxy支持多种负载均衡算法，用户可以根据后端服务器池中各个节点的实际资源配置进行不同的算法选取， HAProxy支持的负载均衡算法有以下几种。

Round-Robin（roundrobin）：与Keeplived的Round-Robin类似，使用这种算法服务请求会被轮询转发到服务器池中的每一个服务器上，而不去评估服务器的‰负载和处理能力，服务器池中的每个节点都被轮询转发请求。
 Static Round-Robin（static-rr）：与 Round-Robin一样轮询转发请求到每一个后端服务器，但是不允许对后端服务器进行动态加权设置，即服务器的权重是静态固定的，而由于权重静态固定，后端服务器池中的节点数目不受限。
 Least-connection（leastconn）：即最少连接数算法，与Keepalived的最少连接数算法类似，后端服务器活动连接数越多，则接收到的服务请求就越少，反之，则接收到的服务请求越多。
 Source（source）：该算法将请求中的源IP地址进行HASH后除以全部正常运行的后端服务器权重来决定接收服务请求的服务器，在这种算法中，同一个客户端（相同的源 IP地址）发出的请求会被固定转发给某一个固定的后端服务器。　　　　　　　　　　但是，如果服务器权重大小发生改变或者服务器数目出现变动，则响应该客户端请求的后端服务器会改变，因为这时的 HASH/Wight值已经改变。

URL（url）：该算法将请求URL字符串进行HASH并除以全部正常运行的后端服务器权重来决定接收服务请求的服务器，在这种算法中，指向同一目标站点的服务请求会被固定转发到相同的后端服务器上。URL也称为基于目标地址　　　　　　　的HASH负载均衡算法，主要用于Web Cache集群中，通过URL负载均衡算法，可以避免请求因为指向不同的cache服务器而导致缺页，而缺页会导致刷新 cache最终降低系统响应速率。

URL Parameter（uri_param）：该算法通过查询源 HTTP请求报文中的某一字符串参数并将其进行 HASH后除以全部服务器权重来决定接收服务请求的服务器。如果HTTP报文中没有需要的参数，则默认使用Round_Robin算法

Header Name（hdr）：该算法通过查询HTTP请求报文中的HEAD字段并将HASH后除以全部服务器权重来决定接收服务请求的服务器。如果报文中没有HEAD参数，则默认使用Round_Robin算法。
1
2
3
4
5
6
7
8
9
10

在高可用集群配置中，为了实现服务的高可用，通常每个后端配置中都需要提供两个以上的后端服务器进行负载均衡。
　　
5、HAProxy监控页面
　　HAProxy为每个监听代理提供了实时监控，并可以将监控参数以 GUI页而的形式呈现给用户。要使用HAProxy的GUI页面，需要在/etc/haproxy/haproxy.cfg配置文件中配置相应的监听参数，通常需要配置一个Listen置段（也可以是 Frontend或 Backend配置段)，即可通过 HTTP协议访问HAProxy的监控页面，最为常用的HAProxy监控页面配置如下：

listen status　　    #定义一个listen，也可以放在frontend或backend段中
mode http 　　　　　　 #使用协议
bind 192.168.142.110:8080 #监听地址和端口
stats enable 　　　　　　#启用信息统计功能
stats hide-version     #隐藏版本号
stats uri /HAproxy     #访问URL
stats realm HAProxy\Statistics #登录提示信息
stats auth admin:admin         #admin界面，验证成功后允许管理节点
stats refreah 10s              #页面刷新时间
1
2
3
4
5
6
7
8
9

HAProxy的监控页面：
　　HAProxy的监控页面将每项资源的监控参数以表格形式呈现给用户，并将监控参划分为七个类别，即 Queue、Session rate、Sessions、Bytes、Denied、Errors、 Warning、server，每组参数类别下又有多个详细参数，其中各个参数的解释如下。

（1）Queue
　　cur:表示当前队列的请求数量。
　　Max:表是当前队列最大的请求数量。
　　Limit:表示队列的限制数量。

（2） Session rate
　　Cur:每秒会话连接数量。
　　Max：每秒会话数量最大值。囗 Limit：每秒会话数量的限制值。

（3） Sessions
　　Total:总共会话数量。
　　Cur：当前的会话数量。
　　Max：最大会话数量。
　　Limit;会话连接限制。
　　Lbtot：选中一台服务器所用的总时间。
　　Last：最后一次会话时间。

（4） Bytes
　　In：网络会话输人字节数总量。
　　Out:网络会话输出字节数总量。

（5） Denied
　　Req：被拒绝的会话请求数量。
　　Resp：拒绝回应的请求数量。

（6） Errors
　　Req：错误的请求数量。
　　Conn：错误连接数量。
　　Resp：错误响应数量。
（7） Warnings
　　 Retr：重新尝试连接的请求数量。
　　 Redis：重新发送的请求数量。

（8） Server
　　status：后端服务器状态，可以有 UP和 DOWN两种状状态。
　　LastChk：持续检查后端服务器的时间。
　　Wght：服务器权重。
　　Act：活动后端服务器数量。
　　Bck：后端备份服务器的数量。
　　Down：状态为 Down的后端服务器数量。
　　Downtime：服务器总的 Downtime时间。
　　Throttle：状态 Backup变为 Active的服务器数量。
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42

6、 HAProxy配置参考

作为一个专业的负载均衡代理软件， HAProxy具有非常丰富的配置选项， HAProxy还有很多详细功能配置项，为了满足不同应用场景下用户的 HAProxy配置参考，本节将会对 HAProxy配置文件 haproxy.cfg中各个配置段的配置参数，以及这些参数的功能作用进行解释和总结，用户可以根据自己的需求在相应配置段中进行参数取舍，HAProxy各个配置段示例如下。
　　1、全局配置段参考

global

maxconn20000 　　　　　　 #默认最大连接数
log $host_ip local0 　　 #level为 err/warning/info/debug日志记录设备
chroot /var/haproxy/ 　　#chroot运行的路径
uid 200 　　　　　　　　　　#HAProxy进程属组UID
gid 200 　　　　　　　　　　#HAproxy进程属组
daemon 　　　　　　　　　　 #以后台形式运行HAProxy 
nbproc 2 　　　　　　　　　#进程数量，可以设置多个进程提高性能
pidfile /var/run/haproxy.pid 　　#HAProixy的pid存放路径
ulimit-n 65535 　　　　　　　　　　 #ulimit让的数量限制
1
2
3
4
5
6
7
8
9
10
11

2、默认配置段参考

defaults

log global 　　　　　　　　 #使用global定义的日志记录设备
mode {tcp|http|health}   #设置实例的运行模式或协议，当实现内容交换时，前端和后端，必须作在同一种模式 
maxconn 20000　　　　　　  #最大连接数
option httplog 　　　　　　#日志类别为http日志格式
option httpclose 　　     #每次请求完毕后主动关闭http通道 
option dontlognull 　　   #不记录健康检查的日志信息
option forwardfor 　　　　 #允许在发往服务器的请求头部中插入“X-Forwarded-For”头部
option Redispath 　　　　  #serverid对应的服务器挂掉后，强制定向到其它健康的服务器
option abortonclose 　　  #允许结束掉当前队列中一直pending的连接 
stats refresh 30 　　　　  #统计页面刷新间隔
retries 3 　　　　　　　　  #认为服务不可用的尝试连接次数
balance roundrobin 　　　 #默认的负载均衡的方式，这里为轮询方式，也可以是balance source
contimeout 5000 　　　　  #连接超时
clitimeout 50000　　　　　#客户端超时
srvtimeout 50000　　　　  #服务器超时
timeout check 2000 　　  #心跳检测超时
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18

3、监控页面配置段参考：

listen admin_status #对Frontend和Backend进行监控统计，监控组名称可以自定义
mode http 　　　　　　 #使用协议
bind 192.168.142.110:8080 #监听地址和端口
stats enable 　　　　　　#启用信息统计功能
stats hide-version     #隐藏版本号
stats uri /HAproxy     #访问URL
stats realm HAProxy\Statistics #登录提示信息
stats auth admin:admin         #admin界面，验证成功后允许管理节点
stats refreah 10s              #页面刷新时间

#下面语句用于捕获并将指定的请求/响应首部记录到HAProxy的日志中，日志中记录的是指定首部的值：
capture request header host len 40
capture request header content-length len 10
capture request header referer len 200
capture request header server len 40
capture response header content-length len 10
capture response header cache-control len 8
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17

4、 FrontEnd配置段参考：
　　　　FrontEnd配置段主要通过bind配置监听的虚拟IP地址和端口，同时Frontend配置里面可以定义多个acl以进行请求精确匹配，Frontend配置段中还可以定义与全局默认配置段重名的参数以覆盖全局配置段的参数。

frontend web_server   #定义前端名称，可自定义。
bind 0.0.0.0:80   #监听IP地址与端口mode http  #使用http协议log global  #应用全局的日志配置option httplog #启用http的logoption httpclose  #每次请求完主动关闭http通道option forwardfor 允许发往服务器的请求头部中插入“X-Forwarded For”头部acl warrior_blog hdr_dom(host) -i blog.warrior.cn #如果请求的域名满足www.warrior.cn，则返回true，-i表示忽略大小写。acl（缺）
1
2

5、BackEnd配置段参考：
　　　　Backend配置段主要配置负载均衡算法，定义后端服务器以及相应的健康检查方式等参数，同时Backend配置段也可以定义与默认全局配置段重名的参数，从而覆盖全局参数值以进行局部后端定义。

backend server_web  #后端名称
mode http    #http七层模式
balance roundrobin     #负载均衡的方式
option ignore-persist {if | unless} <condition>   #在某些条件下拒绝持续连接，适用于静态文件的负载均衡。
option independant-streams    #启用双向超时处理，如socket的read和write
option log-health-checks      #记录健康检查日志
option log—separate—errors    #对非完全成功的连接改变日志记录等级
option logasap     #传输大文件时可以提前记录日志
option mysql-check    #mysql健康检查
option  persist     #强制将http请求发往已经down掉的server 
option redispatch   #是否允许重新分配在session失败后 
option smtpchk    #smtp检查
option httpchk    #通过http协议进行健康检查
option socket-stats  #允许对单个socket进行统计
option  srvtcpka     #是否允许向server发送 keepalive 
option tcpka      #是否允许向 server和 client发送 keepalive 
option tcplog     #允许记录tcp连接的状态和时间 
option transparent     #允许客户端透明代理 
option httpchk GET /1b.html HTTP/1·0    #心跳检测的文件
tick-table type ip size 1024     #为当前后端配置粘性表；表存储条目类型为IP地址，允许存储1k大小的IP地址 
stick on dst        #定义一个请求模式dst，以将一个客户端同某个后端服务器关联起来 
timeout server 90m     #后端服务器最大等待时间，超过此时间则认为服务器不可用。
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22

如下进行多后端服务器定义， check inter 1500是检测心跳频率， rise 3表示3次检查结果正确则认为服务器可用，fall 3表示检测结果失败3次则认为服务器不可用， weight代表服务器权重。port 9200表示通过端口9200来进行基于 http的健康检查， backup表示该服务器是备份服务器，只有在其他非 backup服务器均不可用的情况下负载均衡器才会使用该后端服务器，默认情况下使用第一个标记为 backup的后端服务器， upon-marked-down shutdown-sessions表示当该服务器被认为是 shutdown的时候，关闭全部与该服务器的请求连接。

server 192.168.51.78 192.168.151.78:80 check inter 1500 rise 3 fall 3 weight 1 port 9200 backup on-marked-down shutdown-sessions

server 192.168.51.79 192.168.151.79:80 check inter 1500 rise 3 fall 3 weight 1 port 9200 backup on-marked-down shutdown-sessions

server 192.168.51.80 192.168.151.80:80 check inter 1500 rise 3 fall 3 weight 1 port 9200 backup on-marked-down shutdown-sessions
1
2
3
4
5