haproxy

12.1　高性能负载均衡软件HAProxy介绍

随着互联网业务的迅猛发展，大型电商平台和门户网站对系统的可用性和可靠性要求越来越高，高可用集群、负载均衡集群成为一种热门的系统架构解决方案。在众多的负载均衡集群解决方案中，有基于硬件的负载均衡设备，例如F5、Big-IP等，也有基于软件的负载均衡产品，例如HAProxy、LVS、Nginx等。在软件的负载均衡产品中，又分为两种实现方式，分别是基于操作系统的软负载实现和基于第三方应用的软负载实现。LVS就是基于Linux操作系统实现的一种软负载均衡，而HAProxy就是基于第三应用实现的软负载均衡。本章将详细介绍HAProxy这种基于第三方应用实现的负载均衡技术。

12.1.1　HAProxy简介

HAProxy是一个开源的、高性能的、基于TCP（第四层）和HTTP（第七层）应用的负载均衡软件，借助HAProxy可以快速、可靠地提供基于TCP和HTTP应用的负载均衡解决方案。HAProxy作为一个专业的负载均衡软件，它的显著优点如下：

·可靠性和稳定性非常好，可以与硬件级的F5负载均衡设备相媲美。

·最高可以同时维护40000～50000个并发连接，单位时间内处理的最大请求数为20000个，最大数据处理能力可达10Gbps。作为软件级别的负载均衡来说，HAProxy的性能强大可见一斑。

·支持多于8种负载均衡算法，同时也支持session保持。

·支持虚拟主机功能，这样实现Web负载均衡更加灵活。

·从HAProxy1.3版本后开始支持连接拒绝、全透明代理等功能，这些功能是其他负载均衡器所不具备的。

·HAProxy拥有一个功能强大的服务器状态监控页面，通过此页面可以实时了解系统的运行状况。

·HAProxy拥有功能强大的ACL支持，能给使用带来很大方便。

HAProxy是借助于操作系统的技术特性来实现性能最大化的，因此，在使用HAProxy时，对操作系统进行性能调优是非常重要的。在业业务系统方面，HAProxy非常适用于那些并发量特别大且需要持久连接或四层和七层处理机制的Web系统，例如门户网站或电商网站等。另外。HAProxy也可用于MySQL数据库（读操作）的负载均衡。

12.1.2　四层和七层负载均衡的区别

在12.1节中提到了HAProxy是一个四层和七层负载均衡器。下面简单介绍下四层和七层的概念与区别。

所谓的四层就是ISO参考模型中的第四层。四层负载均衡器也称为四层交换机，它主要是通过分析IP层及TCP/UDP层的流量实现的基于“IP+端口”的负载均衡。常见的基于四层的负载均衡器有LVS、F5等。

以常见的TCP应用为例，负载均衡器在接收到第一个来自客户端的SYN请求时，会通过设定的负载均衡算法选择一台最佳的后端服务器，同时将报文中目标IP地址修改为后端服务器IP，然后直接转发给该后端服务器，这样一个负载均衡请求就完成了。从这个过程来看，一个TCP连接是客户端和服务器直接建立的，而负载均衡器只不过完成了一个类似路由器的转发动作。在某些负载均衡策略中，为保证后端服务器返回的报文可以正确传递给负载均衡器，在转发报文的同时可能还会对报文原来的源地址进行修改。整个过程如图12-1所示。

图12-1　四层负载均衡器转发原理

同理，七层负载均衡器也称为七层交换机，位于ISO的最高层，即应用层，此时负载均衡器支持多种应用协议，常见的有HTTP、FTP、SMTP等。七层负载均衡器可以根据报文内容，再配合负载均衡算法来选择后端服务器，因此也称为“内容交换器”。比如，对于Web服务器的负载均衡，七层负载均衡器不但可以根据“IP+端口”的方式进行负载分流，还可以根据网站的URL、访问域名、浏览器类别、语言等决定负载均衡的策略。例如，有两台Web服务器分别对应中英文两个网站，两个域名分别是A、B，要实现访问A域名时进入中文网站，访问B域名时进入英文网站，这在四层负载均衡器中几乎是无法实现的，而七层负载均衡器可以根据客户端访问域名的不同选择对应的网页进行负载均衡处理。常见的七层负载均衡器有HAProxy、Nginx等。
这里仍以常见的TCP应用为例，由于负载均衡器要获取到报文的内容，因此只能先代替后端服务器和客户端建立连接，接着，才能收到客户端发送过来的报文内容，然后再根据该报文中特定字段加上负载均衡器中设置的负载均衡器算法来决定最终选择的内部服务器。纵观整个过程，七层负载均衡器在这种情况下类似于一个代理服务器。整个过程如图12-2所示。

图12-2　七层负载均衡器代理实现原理

对比四层负载均衡器和七层负载均衡器运行的整个过程，可以看出，在七层负载均衡模式下，负载均衡器与客户端及后端的服务器会分别建立一次TCP连接，而在四层负载均衡模式下，仅建立一次TCP连接。由此可知，七层负载均衡对负载均衡设备的要求更高，而七层负载均衡的处理能力也必然低于四层模式的负载均衡。

12.1.3　HAProxy与LVS的异同

通过上面两小节的介绍，读者应该基本清楚了HAProxy负载均衡与LVS负载均衡的优缺点和异同了。
下面就这两种负载均衡软件的异同做一个简单总结。

1）两者都是软件负载均衡产品，但是LVS是基于Linux操作系统实现的一种软负载均衡，而HAProxy是基于第三应用实现的软负载均衡。

2）LVS是基于四层的IP负载均衡技术，而HAProxy是基于四层和七层技术、可提供TCP和HTTP应用的负载均衡综合解决方案。

3）LVS工作在ISO模型的第四层，因此其状态监测功能单一，而HAProxy在状态监测方面功能强大，可支持端口、URL、脚本等多种状态检测方式。

4）虽然HAProxy功能强大，但是它的整体处理性能低于四层负载均衡模式的LVS，而LVS拥有接近硬件设备的网络吞吐和连接负载能力。综上所述，HAProxy和LVS各有优缺点，没有好坏之分，要选择哪个作为负载均衡器，要以实际的应用环境来决定。

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模式，经常用于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>其可以为主机名或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。

12.3基于虚拟主机的HAProxy负载均衡系统配置实例

前面的两节详细介绍了HAProxy的安装、配置以及ACL规则的使用，要熟练掌握HAProxy的使用，必须进行实战性操作，那么本节将通过一个具体的实例详细讲解和演示HAProxy下虚拟主机的实现过程以及HAProxy是如何实现负载均衡和故障转移的。

12.3.1　通过HAProxy的ACL规则配置虚拟主机

下面将通过HAProxy的ACL功能配置一套基于虚拟主机的负载均衡系统，这里的操作系统环境为CentOS release 6.3，HAProxy版本为haproxy-1.4.24，要实现的功能如图12-3所示。

图12-3　基于虚拟主机的HAPro y应用实例本实例

有一个电商网站服务器群、一个论坛服务器群、一个博客服务器群和默认服务器群，4个服务器群都由多台服务器组成，而4个服务器群又组成了一个应用服务器群组，在每个服务器群的前端有一个基于HAProxy的负载均衡调度器，整个应用架构要实现的功能为：当客户端通过域名www.tb.com或tb.com访问时，HAProxy将请求提交到电商网站服务器群，进而实现电商网站的负载均衡；当客户端通过域名bbs.tb.com访问时就将请求调度到论坛服务器群，实现论坛的负载均衡；当客户端通过blog.tb.com访问时则将请求调度到博客服务器群中，实现博客的负载均衡；如果客户端通过除上面三种方式外的任意方式请求服务时，就将请求调度到缺省服务器群。

要实现上述功能，如果使用四层的LVS负载均衡器，则需要一个代理服务器配合LVS负载均衡器才能实现，而通过HAProxy实现时，仅需要一个HAProxy负载调度器再结合ACL规则即可轻松实现。

1.配置HAProxy

HAProxy的安装非常简单，前面已经做过介绍，这里直接进入HAProxy的配置过程，配置好的文件内容如下：

 global 

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

defaults 

mode http 
retries 3 
timeout connect 5s
timeout client 30s 
timeout server 30s 
timeout check 2s l
isten admin_stats 
bind 0.0.0.0:19088 
mode http 
log 127.0.0.1 local0 err 
stats refresh 30s 
stats uri /haproxy-status 
stats realm welcome login\ Haproxy 
stats auth admin:xxxxxx 
stats auth admin1:xxxxxx 
stats hide-version 
stats admin if TRUE 

frontend www

bind *:80 
mode http 
option httplog 
option forwardfor
log global
acl host_www hdr_reg(host) -i ^(www.tb.com|tb.com) 
acl host_bbs hdr_dom(host) -i bbs.tb.com 
acl host_blog hdr_beg(host) -i blog.
use_backend server_www if host_www 
use_backend server_bbs if host_bbs 
use_backend server_blog if host_blog 
default_backend server_default 

backend server_default

 mode http 
option redispatch 
option abortonclose 
balance roundrobin 
cookie SERVERID 
option httpchk GET /check_status.html 
server default1 192.168.88.90:8000 cookie default1 weight 3 check inter 2000 rise 2 fall 3 
server default2 192.168.88.91:8000 cookie default2 weight 3 check inter 2000 rise 2 fall 3 

backend server_www

 mode http 
option redispatch 
option abortonclose
balance source 
cookie SERVERID 
option httpchk GET /check_status.jsp 
server www1 192.168.88.80:80 cookie www1 weight 6 check inter 2000 rise 2 fall 3 
server www2 192.168.88.81:80 cookie www2 weight 6 check inter 2000 rise fall 3 
server www3 192.168.88.82:80 cookie www3 weight 6 check inter 2000 rise 2 fall 3 

backend server_bbs 

mode http 
option redispatch
option abortonclose 
balance source 
cookie SERVERID 
option httpchk GET /check_status.php 
server bbs1 192.168.88.83:8080 cookie bbs1 weight 8 check inter 2000 rise 2 fall 3 
server bbs2 192.168.88.84:8090 cookie bbs2 weight 8 check inter 2000 rise 2 fall 3 

backend server_blog 

mode http 
option redispatch 
option abortonclose 
balance roundrobin
cookie SERVERID 
option httpchk GET /check_blog.php 
server blog1 192.168.88.85:80 cookie blog1 weight 5 check inter 2000 rise 2 fall 3 
server blog2 192.168.88.86:80 cookie blog2 weight 5 check inter 2000 rise 2 fall 3

关于HAProxy配置文件中每个选项的含义，前面已经做过详细介绍，这里重点看一下frontend部分中关于ACL配置部分的内容，这个是实现虚拟主机的核心配置部分。另外，这个配置文件定义了server_www、server_bbs、server_blog、server_default4个backend，分别对应上面的4个服务器群，对于server_www群和server_bbs群，采用了基于请求源IP的负载均衡算法，其他两个群均采用基于权重进行轮叫调度的算法。这也是根据Web应用的特点而定的。每个backend中都定义了httpchk的检测方式，因此要保证这里指定的URL页面是可访问到的。

为了验证负载均衡的功能，这里需要将后端真实服务器做一个访问标记，这个架构一共加入了9台后端真实服务器，共分为四组，这里将server_www的三台后端服务器默认的Web页面设置如下：

 [root@www1 app]# echo "This is www1 192.168.88.80" >/var/www/html/index.html 

[root@www2 app]# echo "This is www2 192.168.88.81" >/var/www/html/index.html 

[root@www3 app]# echo "This is www3 192.168.88.82" >/var/www/html/index.html

同理，将server_bbs的两台后端服务器默认的Web页面设置如下：

 [root@bbs1 app]# echo "This is bbs1 192.168.88.83" >/var/www/html/index.html

[root@bbs1 app]# echo “This is bbs2 192.168.88.84" >/var/www/html/index.html

接着，将server_blog的两台后端服务器默认的Web页面设置如下：

[root@blog1 app]# echo "This is blog1 192.168.88.85" >/var/www/html/index.html

 [root@blog2 app]# echo "This is blog2 192.168.88.86" >/var/www/html/index.html

最后，将server_default的两台后端服务器默认的Web页面设置如下：

 [root@default1 app]# echo "This is default1 192.168.88.90" >/var/www/html/index.html 

[root@default2 app]# echo "This is default2 192.168.88.91" >/var/www/html/index.html

这样就为接下来的测试做好了准备。

2.启动HAProxy

HAProxy安装完成后，会在安装根目录的sbin目录下生成一个可执行的二进制文件haproxy，对HAProxy的启动、关闭、重启等维护操作都是通过这个二进制文件实现的，执行“haproxy -h”命令即可得到此文件的用法。

haproxy [-f < 配置文件>] [ -vdVD ] [-n 最大并发连接总数] [-N 默认的连接数]

haproxy常用的参数以及含义如表12-1所示。

表12-1　haproxy常用参数及含义

介绍完HAProxy常用的参数后，下面开始启动HAProxy，操作如下：

[root@haproxy-server haproxy]# /usr/local/haproxy/sbin/haproxy -f \ > /usr/local/haproxy/conf/haproxy.cfg

如果要关闭HAProxy，执行如下命令即可：

[root@haproxy-server haproxy]# killall -9 haproxy

如果要平滑重启HAProxy，可执行如下命令：

[root@haproxy-server haproxy]# /usr/local/haproxy/sbin/haproxy -f \ > /usr/local/haproxy/conf/haproxy.cfg -st `cat /usr/local/haproxy/logs/haproxy.pid`

有时候为了管理和维护方便，也可以把HAProxy的启动与关闭写成一个独立的脚本

12.3.2　测试HAProxy实现虚拟主机和负载均衡功能

首先通过不同IP的客户端以www.tb.com或者tb.com域名访问网站，如果HAProxy运行正常，并且ACL规则设置正确，server_www的三台后端服务器默认的Web页面信息将会依次出现，这说明HAProxy对电商网站实现了负载均衡，同时，不会出现其他后端服务器的默认Web页面信息，说明ACL规则生效，实现虚拟主机功能。
同理，当通过不同IP的客户端以bbs.tb.com访问网站时，server_bbs的两台后端服务器默认的Web页面信息将轮换出现。这表示实现了论坛的负载均衡功能，同时，不会出现其他后端服务器的默认Web页面信息，说明ACL规则生效，实现虚拟主机功能。

用同样的方法可以验证blog.tb.com是否实现了虚拟主机功能以及负载均衡功能。最后，当通过HAProxy服务器的IP或者其他方式访问时，访问请求将被调度到server_default指定的两台后端真实服务器上。

12.3.3　测试HAProxy的故障转移功能

测试HAProxy的故障转移功能也非常简单，这里假定将server_www组的一台后端服务器192.168.88.82的httpd服务停止，那么当通过www.tb.com或者tb.com域名访问网站时，这个失效的节点将不会被访问到，因为当httpd服务被停止后，HAProxy通过httpchk方式将立刻检测到此节点无法返回数据，从而屏蔽此节点对外提供服务的功能，这样就实现了故障转移功能。通过类似的方法可以测试其他节点的应用。

12.3.4　使用HAProxy的Web监控平台

虽然HAProxy实现了服务的故障转移功能，但是在主机或者服务出现故障的时候，并不能发出通知告知运维人员，这对于及时性要求很高的业务系统来说，是非常不便的。不过，HAProxy似乎也考虑到了这一点，在新的版本中HAProxy推出了一个基于Web的监控平台，通过这个平台可以查看此集群系统所有后端服务器的运行状态，在后端服务或服务器出现故障时，监控页面会通过不同的颜色来展示故障信息，这在很大程度上解决了后端服务器故障报警的问题，运维人员可通过监控这个页面来第一时间发现节点故障，进而修复故障，如图12-4所示。

图12-4　HAProxy的Web监控页面

在这个监控页面中，详细记录了HAProxy中配置的frontend、backend等信息。在backend中有各台后端真实服务器的运行状态，正常情况下，所有后端服务器都以浅绿色展示，当某台后端服务器出现故障时，将以深橙色显示。其实每种颜色代表什么状态，在上面这个图中都有详细说明。

在这个监控页面中，还可以执行关闭自动刷新、隐藏故障状态的节点、手动刷新、导出数据为CSV文件等各种操作。在新版的HAProxy中，又增加了对backend后端节点的管理功能，例如，可以在Web页面下执行Disable、Enable、Soft Stop、Soft Start等对后端节点的管理操作。这个功能在后端节点升级、故障维护时非常有用。