haproxy配置文件backend及ACL智能负载和frontend实现多域名

haproxy的acl智能负载分别在backend和frontend中使用,从官网的技术资料看，这里我们也用一下，做一下笔记。
192.168.0.5 Haproxy server1 域名
192.168.0.197 nginx+php server2 source.loshub.com
192.168.0.198 nginx+php server3 source.loshub.com
192.168.0.199 nginx server4 yum.loshub.com
192.168.0.200 nginx server5 yum.loshub.com
server2和3分别是用来做动态资源跑PHP程序,并在nginx配置文件上面分别绑好source.loshub.com的域名，server4和5用来存放静态资源,分别在nginx配置文件上面绑好yum.loshub.com,两个域名都做好本地host,source.loshub.com和yum.loshub.com,分别指向192.168.0.5。这样做到高可用集群和负载均衡及多域名动静分离。

首先用backend首先要去frontend定义一下，以下是配置示例

Haproxy通过frontend关键字定义一个www的前端虚拟节点,代码如下

frontend www
    mode http
    bind 0.0.0.0:80
    option httplog
    option forwardfor
    option httpclose
    log global
    acl host_www hdr_dom(host) -i source.loshub.com
    acl host_yum hdr_dom(host) -i yum.loshub.com
    use_backend www_loshub_com if host_www
    use_backend yum_loshub_com if host_yum

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 段进行
acl语法
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 等。
经常使用的方法：
hdr_beg(host) #精确匹配主机, 表示以什么开头的域名
hdr_reg(host) #正则匹配主机,表示以什么开头的域名
path_beg #匹配路径，表示以什么路径开头
path_end #匹配路径结尾，表示以什么路径结尾
url_sub : 表示请求url 中包含什么字符串，例如：acl file_req url_sub -i killall=，表示在请求url 中包含killall=
，则此控制策略返回true
url_dir : 表示请求url 中存在哪些字符串作为部分地址路径，例如 acl dir_req url_dir -i allow，表示在请求url 中
存在allow作为部分地址路径，则此控制策略返回true,否则返回false
-i：表示忽略大小写，后面需要跟上匹配的路径或文件或正则表达式。
backend配置source.loshub.com示例

backend www_loshub_com
    mode http
    option redispatch
    option abortonclose
    balance static-rr
    cookie SESSION_COOKIE insert indirect nocache
    option httpchk GET /index.php
    server web2 192.168.0.197:80 cookie server2 weight 6 check inter 2000 rise 2 fall 3
    server web3 192.168.0.198:80 cookie server3 weight 3 check inter 2000 rise 2 fall 3

配置yum.loshub.com示例

backend yum_loshub_com
    mode http
    option redispatch
    option abortonclose
    balance static-rr
    cookie SESSION_COOKIE insert indirect nocache
    option httpchk GET /index.html
    server web4 192.168.0.199:80 cookie server4 weight 6 check inter 2000 rise 2 fall 3
    server web5 192.168.0.200:80 cookie server5 weight 3 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() : 此算法根据http 头进行转发，如果指定的http 头名称不存在，则使用roundrobin 算法进行策略转发。
cookie：表示允许向cookie 插入SESSION_COOKIE，每台服务器的SERVERID 可在下面的server 关键字中使用cookie 关键字定义。
option httpchk：此选项表示启用HTTP 的服务状态检测功能。HAProxy 作为一款专业的负载均衡器，它支持对backend 部分指定的后端服务节点的健康检查，以保证在后端backend 中某个节点不能服务时，把从frotend 端进来的客户端请求分配至backend 中其他健康节点上，从而保证整体服务的可用性。
　　“optionhttpchk”的用法如下：
　　option httpchk
其中，各个参数的含义如下：
method：表示HTTP 请求的方式，常用的有OPTIONS、GET、HEAD 几种方式。一般的健康检查可以采用HEAD 方式进行，而不是才采用GET 方式，这是因为HEAD 方式没有数据返回，仅检查Response 的HEAD 是不是200 状态。因此相对与GET 来说，HEAD 方式更快，更简单。
uri：表示要检测的URL 地址，通过执行此URL，可以获取后端服务器的运行状态。在正常情况下将返回状态码200，返回其他状态码均为异常状态。
version：指定心跳检测时的HTTP 的版本号。
server：这个关键字用来定义多个后端真实服务器，不能用于defaults 和frontend部分。
使用格式为：
server [:port] [param*]
其中，每个参数含义如下：
：为后端真实服务器指定一个内部名称，随便定义一个即可。
：后端真实服务器的IP 地址或主机名。
：指定连接请求发往真实服务器时的目标端口。在未设定时，将使用客户端请求时的同一端口。
[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：设置后端真实服务器的备份服务器，仅仅在后端所有真实服务器均不可用的情况下才启用。
此文参考https://www.cnblogs.com/yyxianren/