haproxy配置应用详解
一.balance调度算法：
算法有动静之分，改变权重不用重启即可生效的为动态，反之亦然。
roundrobin:轮询 基于权重进行轮询，在服务器的处理时间保持持续分布时，是最平衡公平的，该算法是动态的，这表示其权重可以在运行时候进行调整，不过在设计上面，每个后端服务器仅能够最多连接
4128个连接。
static-rr:基于权重进行轮询。静态轮询，在调整配置之后不会生效，但是后端服务器连接数不限制。
leastconn:新的连接请求被派送至具有最少连接数目的后端服务器，在有着较长时间会话的场景中推荐，如：LDAP,SQL等，其实并不太适用于较短会话应用层协议。如http，该算法是动态的，可以在运行时候调整其权重。
source:将请求的源地址进行hash运算，并由其后端的服务器的权重总数相除之后派发至匹配的服务器，这可以使得同一个客户端IP的请求始终被派发至某特定的服务器，不过放服务器权重总数发生变化时，如某服务器宕机或者添加了新的服务器，许多客户端的请求可能会被派送至与此之前不同的服务器，常用语负载均衡无cookie功能的tcp协议，其默认为静态，不过可以使用hash-type修改此特性。map-based静态，取模法。consistent为动态。
uri:对url的左半部分或整个url进行hash运算，并由服务器的总权重相除后派发至某匹配的服务器，这样可以使得同一个url的请求总是被派送至某特定的服务器，除非服务器的权重总数发生了变化，此算法常用于代理缓存或者反病毒代理以提高缓存的命中率。注意的是此算法仅应用于http后端服务器场景其默认为静态算法，不过也可以使用hash-type修改。
ur_param:通过<argument用户id>为url指定的参数在每个httpget请求中将会被检索：如果找到了指定的参数且其通过等于号“=”被赋予了一个值，那么此值将被执行hash运算并被服务器的中权重相除后派发至某匹配的服务器，此算法可以通过追踪请求中用户标识进而确保同一个id的请求将被送往同一个特定的服务器，除非服务器的总权重发生了变化，如果某请求中没有出现指定的参数或者没有其他有效值，则使用轮询算法对相应请求进行调度，该算法默认为静态，不过可以使用hash-type来修改。
hdr():根据header做调度，也就是虚拟主机来调度，该算法默认为静态，不过可以使用hash-type来修改。
rdp-cookie:远程桌面协议remote desktop protocol，用法：rdp-cookie(name)
二.常用参数：
default_backend :用于fromend中，指定请求提供服务的backend。
use_backend:[{if |unless} ]：条件式后端指定
由acl定义的：
server
name为内部名称，标识而已，address地址：ip地址。端口：前端服务器的端口。 check 监控状态监测。
inter：时间间隔。
rise:上线前的成功检测次数。
fall:下线前的失败检查次数。
cookie:分配给server的cookie信息
disabled:设置服务器为禁用状态
maxconn:最大并发连接数
maxqueue:等待队列最大长度。0表示无上限
minconn:最少并发连接数
weight:权重
bind：用于frontend或listen中，指明监听的地址和端口。
mode：致命haproxy代理模式，默认为tcp
三.添加监控页面
在配置文件添加启用监控页面的信息：
[cc lang=”bash”]
[[email protected] ~]# vim /etc/haproxy/haproxy.cfg
[/cc]
[cc lang=”bash”]
stats enable //启用
stats uri /haproxyadmin?stats //登录ur
stats auth admin:admin //认证帐号密码
stats realm “My\Haproxy” //显示登录信息
stats hide-version //隐藏版本
stats admin if TRUE //开启管理功能
[/cc]
输入密码登录测试：
四.haproxy常用的选项参数实例
1）基于cookie黏性
具体实现方法：
[cc lang=”bash”]
backend webserver
balance roundrobin
option httpchk
cookie SERVERID insert indirect nocache //serverid可随意定义 nocache不缓存
server app1 172.16.249.152:80 check inter 2 rise 1 fall 3 cookie web1
server app2 172.16.0.1:80 check inter 2 rise 1 fall 3 cookie web2
[/cc]
修改完成之后，重载haproxy，在浏览器打开测试，查看cookie信息的标识：
2）记录请求客户端的真实ip
该行默认在haproxy的默认配置中已经有了。由于默认配置会在生效，所以不需要在backend中添加。
[cc lang=”bash”]
option forwardfor except 127.0.0.0/8
[/cc]
在前端主机的httpd主配置文件的日志段修改为以下行：
[cc lang=”bash”]
LogFormat “%{X-Forwarded-For}i %l %u %t \”%r\” %>s %b \”%{Referer}i\” \”%{User-Agent}i\”” combined
[/cc]
重载httpd配置之后查看日志信息，此时不再是请求代理的ip，而是客户端的真实Ip
可以使用以下命令查看：
[cc lang=”bash”]
[[email protected] ~]# tail /var/log/httpd/access_log
[/cc]
3）option http-server-close
要启用keep-alive 必须使用option http-server-close参数
4）option redispatch
若做过session持久就不用分发了。
五.Haproxy的ACL
acl:haproxy的acl用于实现基于请求报文的首部，响应报文的内容或者其他状态环境信息来做出转发决策，这大大增强了其配置弹性，其配置法则通常分为两步，首先去定义一个ACL，即定义一个测试条件，而后在条件得到满足时候执行某特定的动作，如：阻止请求或者转发至某特定的后端，定义ACL的语法格式如下：
acl [fags][operator]
：acl名称，区分大小写，且其只能包含大小写字母，数字，-连接线，_下划线，.点号，和：冒号。在haproxy中，acl可以重名，这可以把多个测试条件定义为一个共同的acl。
包括（dst_port,src_port,src,dst,url，path_reg等等）
[fags]：目前haproxy的acl支持的标志位有三个，-i:不区分中模式字符的大小写 -f:从指定的文件中加载模式 –:强制结束，在模式中字符串像标记符时使用
：acl测试条件支持四类：
整数或者整数范围：如：1024-65535 从1024到65535 ，仅支持使用正整数。且支持使用的操作符有5个，分别是：eq,ge,gt,le和lt
同一个acl中可以指定多个测试条件，这些测试条件需要由逻辑操作符指定其关系。
hdr
用于测试请求报文中的所有首部或者指定首部是否满足指定的条件，指定首部时，某名称不区分大小写，且在括号“（）”中不能有任何多余的空白字符，测试服务器端的响应报文时可以使用shdr(),如：
hdr (connection) -i close //用于测试首部的connection的值是否为close。
path_beg 起始路径
测试url请求是否以static和img头
[cc lang=”bash”]
acl url_static path_beg -i /static /img
[/cc]
path_end 结束路径
测试用户请求url是否以png jpg结尾的
[cc lang=”bash”]
acl url_static path_end -i .png .jpg
[/cc]
案例:实现动静分离
用acl在fronend中定义使用静态资源，默认的使用动态资源。
[cc lang=”bash”]
frontend main *:80
acl url_static path_beg -i /static /images /javascript /stylesheets
acl url_static path_end -i .jpg .gif .png .css .js
backend url_static
banlance roundrobin
server static1 172.16.249.152 check
server static2 172.16.0.1 check
rsqadd
[/cc]
在主配置文件中定义X-Via行即可。
[cc lang=”bash”]
frontend main *:80
rspadd X-Via:\ node1
default_backend appserver
backend appserver
balance roundrobin
cookie SERVERID insert indirect nocache
server app1 172.16.249.152:80 check inter 2 rise 1 fall 3 cookie web1
server app2 172.16.0.1:80 check inter 2 rise 1 fall 3 cookie web2
[/cc]
timeout http-request
