12.2 HAProxy 基础配置与应用实例

HAProxy 的安装非常简单，但是在配置方面稍微复杂了些。虽然官方给出的配置文档多达百页，但是 HAProxy 的配置并非这么复杂，因为 HAProxy 常用的配置选项是非常少的。只要掌握了常用的配置选项，基本就能玩转 HAProxy 了，因此在下面的介绍中主要讲解 HAProxy 中常用的选项。

12.2.1 快速安装 HAProxy 集群软件

可以在 HAProxy 的官网 http://haproxy.1wt.eu/下载 HAProxy 的源码包，这里以操作系统 CentOS 6.3 版本为例，下载的 HAProxy 是当前的稳定版本 haproxy-1.4.24.tar.gz，安装过程如下：

[root@haproxy-server app]# tar zcvf haproxy-1.4.24.tar.gz
[root@haproxy-server app]#cd haproxy-1.4.24
[root@haproxy-server haproxy-1.4.24]#make TARGET=linux26 PREFIX=/usr/local/haproxy
[root@haproxy-server haproxy-1.4.24]#make install PREFIX=/usr/local/haproxy     
   # 
将 HAProxy
安装到/usr/local/haproxy
下
[root@haproxy-server haproxy-1.4.24]#mkdir  /usr/local/haproxy/conf     
   # HAProxy
默认不创建配置文件目录，这里是创建 HAProxy
配置文件目录
[root@haproxy-server haproxy-1.4.24]# cp examples/haproxy.cfg  /usr/local/haproxy/conf
   # HAProxy
安装完成后，默认安装目录中没有配置文件，这里是将源码包里面的示例配置文件复制到
   # 
配置文件目录

这样，HAProxy 就安装完成了。

12.2.2 HAProxy 基础配置文件详解

1.配置文件概述

根据功能和用途，HAProxy 配置文件主要由 5 个部分组成，但有些部分并不是必需的，可以根据需要选择相应的部分进行配置。

（1）global 部分

用来设定全局配置参数，属于进程级的配置，通常和操作系统配置有关。

（2）defaults 部分

默认参数的配置部分。在此部分设置的参数值，默认会自动引用到下面的 frontend、backend 和 listen 部分中，因此，如果某些参数属于公用的配置，只需在 defaults 部分添加一次即可。而如果在 frontend、backend 和 listen 部分中也配置了与 defaults 部分一样的参数，那么 defaults 部分参数对应的值自动被覆盖。

（3）frontend 部分

此部分用于设置接收用户请求的前端虚拟节点。frontend 是在 HAProxy 1.3 版本之后才引入的一个组件，同时引入的还有 backend 组件。通过引入这些组件，在很大程度上简化了 HAProxy 配置文件的复杂性。frontend 可以根据 ACL 规则直接指定要使用的后端 backend。

（4）backend 部分

此部分用于设置集群后端服务集群的配置，也就是用来添加一组真实服务器，以处理前端用户的请求。添加的真实服务器类似于 LVS 中的 real server 节点。

（5）listen 部分

此部分是 frontend 部分和 backend 部分的结合体。在 HAProxy 1.3 版本之前，HAProxy 的所有配置选项都在这个部分中设置。为了保持兼容性，HAProxy 新的版本仍然保留了 listen 组件的配置方式。目前在 HAProxy 中，两种配置方式任选其一即可。

2.HAProxy 配置文件详解

根据上面介绍的 5 个部分对 HAProxy 的配置文件进行讲解。

（1）global 部分

配置示例如下：

global
        log 127.0.0.1 local0 info
        maxconn 4096
        user nobody
        group nobody
        daemon
        nbproc 1
        pidfile /usr/local/haproxy/logs/haproxy.pid

上述代码中每个选项的含义如下。

- log：全局的日志配置，local0 是日志设备，info 表示日志级别。其中日志级别有 err、warning、info、debug4 种可选。这个配置表示使用 127.0.0.1 上的 rsyslog 服务中的 local0 日志设备，记录日志等级为 info。

- maxconn：设定每个 HAProxy 进程可接受的最大并发连接数，此选项等同于 Linux 命令行选项“ulimit -n”。

- user/group：设置运行 HAProxy 进程的用户和组，也可使用用户和组的 uid 和 gid 值来替代。

- daemon：设置 HAProxy 进程进入后台运行。这是推荐的运行模式。

- nbproc：设置 HAProxy 启动时可创建的进程数，此参数要求将 HAProxy 运行模式设置为 daemon，默认只启动一个进程。根据使用经验，该值的设置应该小于服务器的 CPU 核数。创建多个进程，能够减少每个进程的任务队列，但是过多的进程可能会导致进程崩溃。

- pidfile：指定 HAProxy 进程的 pid 文件。启动进程的用户必须有访问此文件的权限。

（2）defaults 部分

配置示例如下：

defaults
        mode http
        retries 3
        timeout connect 10s
        timeout client 20s
        timeout server 30s
        timeout check 5s

上述代码中每个选项的含义如下。

- mode：设置 HAProxy 实例默认的运行模式，有 tcp、http、health 三个可选值。

- tcp 模式：在此模式下，客户端和服务器端之间将建立一个全双工的连接，不会对七层报文做任何类型的检查，默认为 tcp 模式，经常用于 SSL、SSH、SMTP 等应用。

- http 模式：在此模式下，客户端请求在转发至后端服务器之前将会被深度分析，所有不与 RFC 格式兼容的请求都会被拒绝。

- health 模式：目前此模式基本已经废弃，不再多说。

- retries：设置连接后端服务器的失败重试次数，如果连接失败的次数超过这里设置的值，HAProxy 会将对应的后端服务器标记为不可用。此参数也可在后面部分进行设置。

- timeout connect：设置成功连接到一台服务器的最长等待时间，默认单位是毫秒，但也可以使用其他的时间单位后缀。

- timeout client：设置连接客户端发送数据时最长等待时间，默认单位是毫秒，也可以使用其他的时间单位后缀。

- timeout server：设置服务器端回应客户端数据发送的最长等待时间，默认单位是毫秒，也可以使用其他的时间单位后缀。

- timeout check：设置对后端服务器的检测超时时间，默认单位是毫秒，也可以使用其他的时间单位后缀。

（3）frontend 部分

这是 HAProxy 配置文件的第三部分 - frontend 部分的配置，配置示例如下：

frontend www
         bind *:80
         mode   http
         option  httplog
         option  forwardfor
         option  httpclose
         log     global
         default_backend htmpool

这部分通过 frontend 关键字定义了一个名为“www”的前端虚拟节点，上述代码中每个选项的含义如下。

- bind：此选项只能在 frontend 和 listen 部分进行定义，用于定义一个或几个监听的套接字。bind 的使用格式为：

 bind [<address>:<port_range>]  interface  <interface>

其中，address 为可选选项，其可以为主机名或 IP 地址，如果将其设置为“*”或“0.0.0.0”，将监听当前系统的所有 IPv4 地址。port_range 可以是一个特定的 TCP 端口，也可是一个端口范围，小于 1024 的端口需要有特定权限的用户才能使用。interface 为可选选项，用来指定网络接口的名称，只能在 Linux 系统上使用。

- option httplog：在默认情况下，HAProxy 日志是不记录 HTTP 请求的，这样很不方便 HAProxy 问题的排查与监控。通过此选项可以启用日志记录 HTTP 请求。

- option forwardfor：如果后端服务器需要获得客户端的真实 IP，就需要配置此参数。由于 HAProxy 工作于反向代理模式，因此发往后端真实服务器的请求中的客户端 IP 均为 HAProxy 主机的 IP，而非真正访问客户端的地址，这就导致真实服务器端无法记录客户端真正请求来源的 IP，而 X-Forwarded-For 则可用于解决此问题。通过使用 forwardfor 选项，HAProxy 就可以向每个发往后端真实服务器的请求添加 X-Forwarded-For 记录，这样后端真实服务器日志可以通过“X-Forwarded-For”信息来记录客户端来源 IP。

- option httpclose：此选项表示在客户端和服务器端完成一次连接请求后，HAProxy 将主动关闭此 TCP 连接。这是对性能非常有帮助的一个参数。

- log global：表示使用全局的日志配置，这里的 global 表示引用在 HAProxy 配置文件 global 部分中定义的 log 选项配置格式。

- default_backend：指定默认的后端服务器池，也就是指定一组后端真实服务器，而这些真实服务器组将在 backend 段进行定义。这里的 htmpool 就是一个后端服务器组。

（4）backend 部分

接着介绍的是 HAProxy 配置文件的第四部分 - backend 部分的配置，配置示例如下：

backend htmpool
        mode    http
        option   redispatch
        option   abortonclose
        balance  roundrobin
        cookie   SERVERID
        option   httpchk GET /index.php
        server  web1 10.200.34.181:80  cookie server1 weight 6 check inter 2000
        rise 2 fall 3
        server  web2 10.200.34.182:8080 cookie server2 weight 6 check inter 2000
        rise 2 fall 3

这个部分通过 backend 关键字定义了一个名为 htmpool 的后端真实服务器组。上述代码中每个选项的含义如下。

- option redispatch：此参数用于 cookie 保持的环境中。在默认情况下，HAProxy 会将其请求的后端服务器的 serverID 插入 cookie 中，以保证会话的 session 持久性。而如果后端的服务器出现故障，客户端的 cookie 是不会刷新的，这就会出现问题。此时，如果设置此参数，就会将客户的请求强制定向到另外一台健康的后端服务器上，以保证服务正常。

- option abortonclose：如果设置了此参数，可以在服务器负载很高的情况下，自动结束当前队列中处理时间比较长的连接。

- balance：此关键字用来定义负载均衡算法。目前 HAProxy 支持多种负载均衡算法，常用的有如下几种：

- roundrobin：是基于权重进行轮叫调度的算法，在服务器的性能分布比较均匀时，这是一种最公平、最合理的算法。此算法使用频繁。

- static-rr：也是基于权重进行轮叫的调度算法，不过此算法为静态方法，在运行时调整其服务器权重不会生效。

- source：是基于请求源 IP 的算法。此算法先对请求的源 IP 进行 hash 运算，然后将结果与后端服务器的权重总数相除后转发至某台匹配的后端服务器。这种方式可以使同一个客户端 IP 的请求始终被转发到某特定的后端服务器。

- leastconn：此算法会将新的连接请求转发到具有最少连接数目的后端服务器。在会话时间较长的场景中推荐使用此算法，例如数据库负载均衡等。此算法不适合会话较短的环境中，例如基于 HTTP 的应用。

- uri：此算法会对部分或整个 URI 进行 hash 运算，再经过与服务器的总权重相除，最后转发到某台匹配的后端服务器上。

- uri_param：此算法会根据 URL 路径中的参数进行转发，这样可保证在后端真实服务器数量不变时，同一个用户的请求始终分发到同一台机器上。

- hdr（<name>）：此算法根据 http 头进行转发，如果指定的 http 头名称不存在，则使用 roundrobin 算法进行策略转发。

- cookie：表示允许向 cookie 插入 SERVERID，每台服务器的 SERVERID 可在下面的 server 关键字中使用 cookie 关键字定义。

- option httpchk：此选项表示启用 HTTP 的服务状态检测功能。HAProxy 作为一个专业的负载均衡器，它支持对 backend 部分指定的后端服务节点的健康检查，以保证在后端 backend 中某个节点不能服务时，把从 frotend 端进来的客户端请求分配至 backend 中其他健康节点上，从而保证整体服务的可用性。option httpchk 的用法如下：

option httpchk <method> <uri> <version>

其中，各个参数的含义如下：

- method：表示 HTTP 请求的方式，常用的有 OPTIONS、GET、HEAD 几种方式。一般的健康检查可以采用 HEAD 方式进行，而不是采用 GET 方式，这是因为 HEAD 方式没有数据返回，仅检查 Response 的 HEAD 是不是状态码 200。因此，相对于 GET，HEAD 方式更快、更简单。

- uri：表示要检测的 URL 地址，通过执行此 URL，可以获取后端服务器的运行状态。在正常情况下将返回状态码 200，返回其他状态码均为异常状态。

- version：指定心跳检测时的 HTTP 的版本号。

- server：这个关键字用来定义多台后端真实服务器，不能用于 defaults 和 frontend 部分。使用格式为：

server <name> <address>[:port] [param*]

其中，每个参数含义如下：

- <name>：为后端真实服务器指定一个内部名称，随便定义一个即可。

- <address>：后端真实服务器的 IP 地址或主机名。

- <port>：指定连接请求发往真实服务器时的目标端口。在未设定时，将使用客户端请求时的同一端口。

- [param*]：为后端服务器设定的一系列参数，可用参数非常多，这里仅介绍常用的一些参数：

- check：表示启用对此后端服务器执行健康状态检查。

- inter：设置健康状态检查的时间间隔，单位为毫秒。

- rise：设置从故障状态转换至正常状态需要成功检查的次数，例如，“rise 2”表示 2 次检查正确就认为此服务器可用。

- fall：设置后端服务器从正常状态转换为不可用状态需要检查的次数，例如，“fall 3”表示 3 次检查失败就认为此服务器不可用。

- cookie：为指定的后端服务器设定 cookie 值，此处指定的值将在请求入站时被检查，第一次为此值挑选的后端服务器将在后续的请求中一直被选中，其目的在于实现持久连接的功能。上面的“cookie server1”表示 web1 的 serverid 为 server1。同理，“cookie server2”表示 web2 的 serverid 为 server2。

- weight：设置后端真实服务器的权重，默认为 1，最大值为 256。设置为 0 表示不参与负载均衡。

- backup：设置后端真实服务器的备份服务器，仅仅在后端所有真实服务器均不可用的情况下才启用。

（5）listen 部分

HAProxy 配置文件的第五部分 - listen 部分的配置，配置示例如下：

listen admin_stats
        bind 0.0.0.0:9188
        mode http
        log 127.0.0.1 local0 err
        stats refresh 30s
        stats uri /haproxy-status
        stats realm welcome login\ Haproxy
        stats auth admin:admin~!@
        stats hide-version
        stats admin if TRUE

这个部分通过 listen 关键字定义了一个名为“admin_stats”的实例，其实就是定义了一个 HAProxy 的监控页面，每个选项的含义如下：

- stats refresh：设置 HAProxy 监控统计页面自动刷新的时间。

- stats uri：设置 HAProxy 监控统计页面的 URL 路径，可随意指定。例如，指定“stats uri/haproxy-status”，就可以通过 http://IP:9188/haproxy-status 查看。

- stats realm：设置登录 HAProxy 统计页面时密码框上的文本提示信息。

- stats auth：设置登录 HAProxy 统计页面的用户名和密码。用户名和密码通过冒号分割。可为监控页面设置多个用户名和密码，每行一个。

- stats hide-version：用来隐藏统计页面上 HAProxy 的版本信息。

- stats admin if TRUE：通过设置此选项，可以在监控页面上手工启用或禁用后端真实服务器，仅在 haproxy1.4.9 以后版本有效。

至此，完整的一个 HAProxy 配置文件介绍完毕了。当然，这里介绍的仅仅是最常用的一些配置参数，要深入了解 HAProxy 的功能，可参阅官方文档。

12.2.3 HAProxy 的日志配置策略

默认情况下，HAProxy 为了节省读写 I/O 所消耗的性能，没有自动配置日志输出功能，但是为了维护和调试方便，日志的输出还是很有必要的，下面就简单介绍下如何配置 HAProxy 的日志输出功能。

由于这里使用的环境为 CentOS6.3 系统版本，因此系统默认的日志管理方式不再是 syslog，而是 rsyslog 管理系统日志，rsyslog 可以实现 UDP 日志接收、将日志写入文件、将日志写入数据库等功能。那么首先检测下 rsyslog 软件包是否已经安装到系统中，操作过程如下：

[root@haproxy-server ~]# rpm -q rsyslog 
rsyslog-5.8.10-8.el6.x86_64

如果已经安装了 rsyslog 软件包，接着需要修改 rsyslog 的配置文件，在/etc/rsyslog.d/目录下创建 haproxy.conf 文件，内容如下：

$ModLoad imudp
$UDPServerRun 514
local3.* /usr/local/haproxy/logs/haproxy.log
local0.* /usr/local/haproxy/logs/haproxy.log

这里定义了两种日志类型，并指定了日志的输出路径，其中：

第一行的“imudp”是模块名，支持 UDP 协议。

第二行表示允许 514 端口接收使用 UDP 和 TCP 协议转发过来的日志，而 rsyslog 在默认情况下，正是在 514 端口监听 UDP。其实也可以将上面 haproxy.conf 文件的内容直接写到/etc/rsyslog.conf 文件中。

然后，还需要修改/etc/sysconfig/rsyslog 文件，修改为如下内容：

SYSLOGD_OPTIONS="-c 2 -r -m 0"

其中，“-r”表示接收远程日志。

最后重启 rsyslog 服务即可完成配置：

[root@haproxy-server ~]# service rsyslog restart

要实现将 HAProxy 日志写入指定的文件中，还需要在 haproxy.cfg 中配置对应的日志选项，这部分内容已经在上节中进行了详细介绍，这里不再说明。

12.2.4 通过 HAProxy 的 ACL 规则实现智能负载均衡

由于 HAProxy 可以工作在七层模型下，因此，要实现 HAProxy 的强大功能，一定要使用强大灵活的 ACL 规则，通过 ACL 规则可以实现基于 HAProxy 的智能负载均衡系统。HAProxy 通过 ACL 规则完成两种主要的功能，分别是：

1）通过设置的 ACL 规则检查客户端请求是否合法。如果符合 ACL 规则要求，那么将放行；如果不符合规则，则直接中断请求。

2）符合 ACL 规则要求的请求将被提交到后端的 backend 服务器集群，进而实现基于 ACL 规则的负载均衡。

HAProxy 中的 ACL 规则经常使用在 frontend 段中，使用方法如下：

acl  
自定义的 acl
名称  acl
方法  -i  [
匹配的路径或文件]

其中：

- acl：是一个关键字，表示定义 ACL 规则的开始。后面需要跟上自定义的 ACL 名称。

- acl 方法：这个字段用来定义实现 ACL 的方法，HAProxy 定义了很多 ACL 方法，经常使用的方法有 hdr_reg（host）、hdr_dom（host）、hdr_beg（host）、url_sub、url_dir、path_beg、path_end 等。

- -i：表示不区分大小写，后面需要跟上匹配的路径或文件或正则表达式。

与 ACL 规则一起使用的 HAProxy 参数还有 use_backend，use_backend 后面需要跟上一个 backend 实例名，表示在满足 ACL 规则后去请求哪个 backend 实例，与 use_backend 对应的还有 default_backend 参数，它表示在没有满足 ACL 条件的时候默认使用哪个后端 backend。

下面列举几个常见的 ACL 规则例子：

acl www_policy  hdr_reg(host)   -i     ^(www.z.cn|z.cn)
acl bbs_policy  hdr_dom(host)   -i      bbs.z.cn
acl url_policy  url_sub         -i      buy_sid=
use_backend     server_www      if      www_policy
use_backend     server_app      if      url_policy
use_backend     server_bbs      if      bbs_policy
default_backend server_cache

这里仅仅列出了 HAProxy 配置文件中 ACL 规则的配置部分，其他选项并未列出。

这些例子定义了 www_policy、bbs_policy、url_policy 三个 ACL 规则，第一条规则表示如果客户端以 www.z.cn 或 z.cn 开头的域名发送请求时，则此规则返回 true，同理第二条规则表示如果客户端通过 bbs.z.cn 域名发送请求时，则此规则返回 true，而第三条规则表示如果客户端在请求的 URL 中包含“buy_sid=”字符串时，则此规则返回 true。

第四、第五、第六条规则定义了当 www_policy、bbs_policy、url_policy 三个 ACL 规则返回 true 时要调度到哪个后端 backend，例如，当用户的请求满足 www_policy 规则时，那么 HAProxy 会将用户的请求直接发往名为 server_www 的后端 backend，其他以此类推。而当用户的请求不满足任何一个 ACL 规则时，HAProxy 就会把请求发往由 default_backend 选项指定的 server_cache 这个后端 backend。

再看下面这个例子：

acl url_static         path_end                .gif .png .jpg .css .js
acl host_www            hdr_beg(host) -i        www
acl host_static         hdr_beg(host) -i        img. video. download. ftp.
use_backend static      if host_static || host_www url_static
use_backend www         if host_www
default_backend         server_cache

与上面的例子类似，本例中也定义了 url_static、host_www 和 host_static 三个 ACL 规则，其中，第一条规则通过 path_end 参数定义了如果客户端在请求的 URL 中以.gif、.png、.jpg、.css 或.js 结尾时返回 true，第二条规则通过 hdr_beg（host）参数定义了如果客户端以 www 开头的域名发送请求时则返回 true，同理，第三条规则也是通过 hdr_beg（host）参数定义了如果客户端以 img.、video.、download.或 ftp.开头的域名发送请求时则返回 true。

第四、第五条规则定义了当满足 ACL 规则后要调度到哪个后端 backend，例如，当用户的请求同时满足 host_static 规则与 url_static 规则，或同时满足 host_www 和 url_static 规则时，那么会将用户请求直接发往名为 static 的后端 backend，如果用户请求满足 host_www 规则，那么请求将被调度到名为 www 的后端 backend，如果不满足所有规则，那么将用户请求默认调度到名为 server_cache 的这个后端 backend。