HAProxy是由WillyTarreau开发的一款具备高可用性、负载均衡、虚拟主机支持以及基于TCP和HTTP的应用代理开源软件，基于HAProxy的负载均衡架构是最为常见的免费、快速且具备可靠性的集群负载均衡架构解决方案。HAProxy特别适合应用于需要会话保持或七层处理的高负载Web站点，如淘宝、Twitter、Instagram、Github和Amazon等大型网站都是HAProxy的使用者。就当前常见的硬件体系架构，基于HAProxy的负载均衡系统完全可以支撑数以万计的并发连接，同时，HAProxy的运行模式使得将其整合到用户当前的基础架构中是个非常简单且安全的过程。

HAProxy概述

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

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

在大多数情况下，用户通常将HAproxy和Keepalived/LVS结合共用以构建更具稳定性和扩展性的高可用环境，如淘宝的CDN架构便是如此。在利用HAProxy的高性能和可扩展性来对基于HTTP和TCP的服务进行负载均衡的同时，结合Keepalived的Failover功能，用户系统在应对大规模访问请求时候，不仅可以通过HAProxy实现高效的负载均衡，还可以利用Keepalived的Failover功能保证业务系统的连续性。

Haproxy配置

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

1) 全局配置段的参数将被应用到全部运行HAProxy的节点中，全局配置段并不针对具体的代理和负载均衡进行设置。用户为HAProxy常用的全局变量配置了参数，这些参数通常是进程级别并与操作系统相关的参数，在全局上限定了HAProxy的工作特性：

❑Daemon：指定HAProxy以后台进程的形式运行。

❑Group：运行HAproxy的用户属组，此处为HAProxy。

❑Maxconn：HAProxy代理允许的最大并行连接数，此处为4000，默认为2000。

❑User：运行HAProxy的用户，此处为HAProxy。

❑Pidfile：HAProxy的进程文件，此处为/var/run/haproxy.pid。

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

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

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

❑Mode：指定HAProxy实例使用的连接协议，即源请求到后端服务器之间的连接协议，可能值为HTTP和TCP。对基于HTTP的Web应用服务，通常使用HTTP模式，对于其他应用服务，通常使用TCP模式。

❑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毫秒。

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

        frontend  WEB

        bind 192.168.0.10:80

        default_backend app

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

      //数据库服务前端

        frontend vip-db

        bind 192.168.142.201:3306

        timeout client 90m

        default_backend db-vms-Galera

        //qpid消息服务前端

        frontend vip-qpid

        bind 192.168.142.215:5672

        timeout client 120s

        default_backend qpid-vms

        //dashboard 服务前端

        frontend vip-horizon

        bind 192.168.142.211:80

        timeout client 180s

cookie SERVERID insert indirect nocache

        default_backend horizon-vms

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

        backend app

        balance      roundrobin

        server  app1  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

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

HAProxy后端配置中指定了负载均衡所采用的算法，HAProxy支持多种负载均衡算法，用户可以根据后端服务器池中各个节点的实际资源配置进行不同的算法选取，HAProxy支持的负载均衡算法有以下几种。

❑Round-Robin(round robin)：与Keepalived的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(url_param)：通过查询源HTTP请求报文中的某一字符串参数并将其进行HASH后除以全部服务器权重来决定接收服务请求的服务器。如果HTTP报文中没有需要的参数，则默认Round-Robin算法。

❑Header Name(hdr)：通过查询HTTP请求报文中的HEAD字段并将其进行HASH后除以全部服务器权重来决定接收服务请求的服务器。如果报文中没有HEAD参数，则默认使用Round-Robin算法。

在高可用集群配置中，为了实现服务的高可用，通常每个后端配置中都需要提供两个以上的后端服务器进行负载均衡。OpenStack高可用集群配置中，为实现每个OpenStack服务的高可用性，通常为每个服务配置三个控制节点，而这三个控制节点即HAProxy后端配置中的后端服务器，OpenStack高可用集群配置的HAProxy后端配置示例如下：

        //heat服务后端

        backend heat-srv-vms

        balance roundrobin

        server controller1-vm 192.168.142.110:8004 check inter 1s

        server controller2-vm 192.168.142.111:8004 check inter 1s

        server controller3-vm 192.168.142.112:8004 check inter 1s

        //ceilometer服务后端

        backend ceilometer-vms

        balance roundrobin

        server controller1-vm 192.168.142.110:8777 check inter 1s

        server controller2-vm 192.168.142.111:8777 check inter 1s

        server controller3-vm 192.168.142.112:8777 check inter 1s

        //MySQL数据库服务后端

        backend db-vms-Galera

        option httpchk

        option tcpka

        stick-table type ip size 1000

        stick on dst

        timeout server  90m

        server  controller1-vm  192.168.142.110:3306  check  inter  1s  port  9200  backup  on-marked-down shutdown-sessions

        server  controller2-vm  192.168.142.111:3306  check  inter  1s  port  9200  backup  on-marked-down shutdown-sessions

        server  controller3-vm  192.168.142.112:3306  check  inter  1s  port  9200  backup  on-marked-down shutdown-sessions

HAProxy配置完成之后，在各个节点启动HAProxy服务即可正常使用HAProxy强大的负载均衡功能。

        //启动haproxy服务

        systemctl start haproxy.service

        //设置开机自启动haproxy服务

        systemctl enable haproxy.service

笔记整理来自山金孝的《OpenStack高可用集群（上册）：原理与架构》4.2.1和4.2.2章节，如有侵权请通知删除