标签：haproxy的使用
一：haproxy实验环境拓扑图：
二：haproxy的配置：
global settings: 全局配置段
主要用于定义haproxy进程自身的工作特性；
proxies: 代理配置段
backend: 后端服务器组
frontend: 定义面向客户的监听的地址和端口，以及关联到的后端服务器组；
listen: 组合方式直接定义frontend及相关的backend的一种机制；
defaults: 定义默认配置；
三：global中的配置参数
* 进程管理及安全相关的参数
- chroot <jail dir>：修改haproxy的工作目录至指定的目录并在放弃权限之前执行chroot()操作，可以提升haproxy的安全级别，不过需要注意的是要确保指定的目录为空目录且任何用户均不能有写权限；
- daemon：让haproxy以守护进程的方式工作于后台，其等同于“-D”选项的功能，当然，也可以在命令行中以“-db”选项将其禁用；
- gid <number>：以指定的GID运行haproxy，建议使用专用于运行haproxy的GID，以免因权限问题带来风险；
- group <group name>：同gid，不过指定的组名；
- log <address> <facility> [max level [min level]]：定义全局的syslog服务器，最多可以定义两个；
- log-send-hostname [<string>]：在syslog信息的首部添加当前主机名，可以为“string”指定的名称，也可以缺省使用当前主机名；
- nbproc <number>：指定启动的haproxy进程的个数，只能用于守护进程模式的haproxy；默认只启动一个进程，鉴于调试困难等多方面的原因，一般只在单进程仅能打开少数文件描述符的场景中才使用多进程模式；
- pidfile：
- uid：以指定的UID身份运行haproxy进程；
- ulimit-n：设定每进程所能够打开的最大文件描述符数目，默认情况下其会自动进行计算，因此不推荐修改此选项；
- user：同uid，但使用的是用户名；
- stats：
- node：定义当前节点的名称，用于HA场景中多haproxy进程共享同一个IP地址时；
- description：当前实例的描述信息；
* 性能调整相关的参数
- maxconn <number>：设定每个haproxy进程所接受的最大并发连接数，其等同于命令行选项“-n”；“ulimit -n”自动计算的结果正是参照此参数设定的；
- maxpipes <number>：haproxy使用pipe完成基于内核的tcp报文重组，此选项则用于设定每进程所允许使用的最大pipe个数；每个pipe会打开两个文件描述符，因此，“ulimit -n”自动计算时会根据需要调大此值；默认为maxconn/4，其通常会显得过大；
- noepoll：在Linux系统上禁用epoll机制；
- nokqueue：在BSE系统上禁用kqueue机制；
- nopoll：禁用poll机制；
- nosepoll：在Linux禁用启发式epoll机制；
- nosplice：禁止在Linux套接字上使用内核tcp重组，这会导致更多的recv/send系统调用；不过，在Linux 2.6.25-28系列的内核上，tcp重组功能有bug存在；
- spread-checks <0..50, in percent>：在haproxy后端有着众多服务器的场景中，在精确的时间间隔后统一对众服务器进行健康状况检查可能会带来意外问题；此选项用于将其检查的时间间隔长度上增加或减小一定的随机时长；
- tune.bufsize <number>：设定buffer的大小，同样的内存条件小，较小的值可以让haproxy有能力接受更多的并发连接，较大的值可以让某些应用程序使用较大的cookie信息；默认为16384，其可以在编译时修改，不过强烈建议使用默认值；
- tune.chksize <number>：设定检查缓冲区的大小，单位为字节；更大的值有助于在较大的页面中完成基于字符串或模式的文本查找，但也会占用更多的系统资源；不建议修改；
- tune.maxaccept <number>：设定haproxy进程内核调度运行时一次性可以接受的连接的个数，较大的值可以带来较大的吞吐率，默认在单进程模式下为100，多进程模式下为8，设定为-1可以禁止此限制；一般不建议修改；
- tune.maxpollevents <number>：设定一次系统调用可以处理的事件最大数，默认值取决于OS；其值小于200时可节约带宽，但会略微增大网络延迟，而大于200时会降低延迟，但会稍稍增加网络带宽的占用量；
- tune.maxrewrite <number>：设定为首部重写或追加而预留的缓冲空间，建议使用1024左右的大小；在需要使用更大的空间时，haproxy会自动增加其值；
- tune.rcvbuf.client <number>：
- tune.rcvbuf.server <number>：设定内核套接字中服务端或客户端接收缓冲的大小，单位为字节；强烈推荐使用默认值；
- tune.sndbuf.client：
- tune.sndbuf.server：
* Debug相关的参数
- debug
- quiet
四：代理端配置详解:
代理相关的配置可以如下配置段中。
- defaults <name>
- frontend <name>
- backend <name>
- listen <name>
“defaults”段用于为所有其它配置段提供默认参数，这配置默认配置参数可由下一个“defaults”所重新设定。
“frontend”段用于定义一系列监听的套接字，这些套接字可接受客户端请求并与之建立连接。
“backend”段用于定义一系列“后端”服务器，代理将会将对应客户端的请求转发至这些服务器。
“listen”段通过关联“前端”和“后端”定义了一个完整的代理，通常只对TCP流量有用。
所有代理的名称只能使用大写字母、小写字母、数字、-(中线)、_(下划线)、.(点号)和:(冒号)。此外，ACL名称会区分字母大小写。
五：haproxy的简单实现：
[root@guzenghui ~]# vim /etc/haproxy/haproxy.cfg defaults 43 mode http 44 log global 45 option httplog 46 option dontlognull 47 option http-server-close 48 option forwardfor except 127.0.0.0/8 49 option redispatch 50 retries 3 51 timeout http-request 10s 52 timeout queue 1m 53 timeout connect 10s 54 timeout client 1m 55 timeout server 1m 56 timeout http-keep-alive 10s 57 timeout check 10s 58 maxconn 3000 59 frontend main *:80 60 default_backend webservers 61 62 backend webservers 63 balance roundrobin //调度算法 64 server s1 192.168.1.11:80 //后端真正提供web服务的主机 65 server s2 192.168.1.22:80
此时我们service haproxy restart 用浏览器访问172.16.249.220/index.html就可以看到web1 和web2被轮询调度。如图所示：
注意：在实际应用上我们两台web服务器上的资源应该是一样的 这里为了便于说明haproxy是使用轮询调用了两台服务器，有意作为不一样的。
六：调度算法：
roundrobin: wrr, dynamic
static-rr: wrr, static
leastconn: wlc, dynamic 用于那些建立长连接的场景下
source: 建议用于基于TCP模式调试，且不支持使用cookie插入模式时使用；由hash-type参数决定其为dynamic或者static
ipvs: sh
nginx: ip_hash
uri: 基于请求报文中的uri的左半部分（查询条件之前的部分）或全部的URI进行调度；常用于backend server为cache server的场景中；
由hash-type参数决定其为dynamic或者static
url_params: 常用于后端服务器需要对用户进行认证的场景中；
由hash-type参数决定其为dynamic或者static
hdr(<name>):由hash-type参数决定其为dynamic或者static
根据用户请求报文中，指定的http首部的值进行调度
hdr(host)：常用于实现将对同一个虚拟主机的请求始终发往同个backend server；
use_domain_only: 在计算hash值时仅使用域名；例如：
web.guzenghui.com与www.guzenghui.com他们属于同一个虚拟主机，因为他们属于同一个域。此时我们就可以使用use_domain_only设置计算hash值时仅使用域名
在使用source调度算法是为了实现session的绑定，但是这种绑定方式是基于源地址的，现在IP地址缺少的情况下，大多使用的是nat协议，即基于源地址绑定，每个人访问被定为到同一台服务器上，显然这是不合理的，因此在特定场景下我们应该使用其它的方法（比如使用cookie绑定）。
七：基于cookie绑定：
[root@guzenghui ~]# vim /etc/haproxy/haproxy.cfg backend webservers 63 balance roundrobin 64 cookie webserver insert nocache //定义cookie名字是webserver 65 server s1 192.168.1.11:80 cookie s1 //定义server 使用cookie 66 server s2 192.168.1.22:80 cookie s2 [root@guzenghui ~]# service haproxy reload
在定义完cookie后我们无论怎么刷新就会绑定到你第一次访问到的server了。在下面可以看到我们使用cookie信息如图所示：
HAProxy的工作模式：调度时发生的协议层次
http：仅用于调度http协议的服务器
会对应用层数据做深入分析，因此支持7层过滤、处理、转换等机制
tcp：非http协议的服务器调度，包括https
默认模式，不会对应用层协议做任何检查；也就不能使用例如hdr类需要探测应用层协议的调度算法。
通过在客户端和backend server之间建立一个全双工的连接
八：服务器或默认服务器参数：
backup：设定为备用服务器，仅在负载均衡场景中的其它server均不可用于启用此server；
check：启动对此server执行健康状态检查，其可以借助于额外的其它参数完成更精细的设定，如：
inter <delay>：设定健康状态检查的时间间隔，单位为毫秒，默认为2000；也可以使用fastinter和downinter来根据服务器端状态优化此时间延迟；
rise <count>：设定健康状态检查中，某离线的server从离线状态转换至正常状态需要成功检查的次数；
fall <count>：确认server从正常状态转换为不可用状态需要检查的次数；
cookie <value>：为指定server设定cookie值，此处指定的值将在请求入站时被检查，第一次为此值挑选的server将在后续的请求中被选中，其目的在于实现持久连接的功能；
maxconn <maxconn>：指定此服务器接受的最大并发连接数；如果发往此服务器的连接数目高于此处指定的值，其将被放置于请求队列，以等待其它连接被释放；
maxqueue <maxqueue>：设定请求队列的最大长度；
observe <mode>：通过观察服务器的通信状况来判定其健康状态，默认为禁用，其支持的类型有“layer4”和“layer7”，“layer7”仅能用于http代理场景；
redir <prefix>：启用重定向功能，将发往此服务器的GET和HEAD请求均以302状态码响应；需要注意的是，在prefix后面不能使用/，且不能使用相对地址，以免造成循环；例如：
server srv1 172.16.100.6:80 redir http://imageserver.magedu.com check
weight <weight>：权重，默认为1，最大值为256，0表示不参与负载均衡；
备用服务器的实现：
修改haproxy配置文件部分内容如下：
62 backend webservers 63 balance roundrobin 64 #cookie webserver insert nocache 65 server s1 192.168.1.11:80 check port 80 66 server s2 192.168.1.22:80 check port 80 67 server b1 127.0.0.1:8080 backup //因为haproxy已经监听在80端口，因此自己的web服务应该监听在别的端口，此时需要启动自己的web服务并提供web页面内容为“This is weihu zhong”
此时我们停掉web1和web2的服务备用服务器就会排上用场如下图所示：
注意只有两台服务器都停止服务备用服务器才能用上。
九：设置检测状态页面
修改haproxy配置文件：
backend webservers 63 balance roundrobin 64 #cookie webserver insert nocache 65 server s1 192.168.1.11:80 check port 80 66 server s2 192.168.1.22:80 check port 80 67 server b1 127.0.0.1:8080 backup 68 stats enable //加上一条就行
此时我们就可以访问到状态页面如下：
下面是和stats enable一起使用的一些参数
stats enable stats hide-version //隐藏haproxy的版本号 stats scope . stats uri /haproxyadmin?stats stats realm Haproxy\ Statistics stats auth statsadmin:password stats auth statsmaster:password
为此页面提供管理功能 需要加上 stats admin 参数只不过这个参数需要跟上条件表达式，语法示例如下：
stats admin { if | unless } <cond>
在指定的条件满足时启用统计报告页面的管理级别功能，它允许通过web接口启用或禁用服务器，不过，基于安全的角度考虑，统计报告页面应该尽可能为只读的。此外，如果启用了HAProxy的多进程模式，启用此管理级别将有可能导致异常行为。
目前来说，POST请求方法被限制于仅能使用缓冲区减去保留部分之外的空间，因此，服务器列表不能过长，否则，此请求将无法正常工作。因此，建议一次仅调整少数几个服务器。下面是两个案例，第一个限制了仅能在本机打开报告页面时启用管理级别功能，第二个定义了仅允许通过认证的用户使用管理级别功能。
backend stats_localhost stats enable stats admin if LOCALHOST
backend stats_auth stats enable stats auth haproxyadmin:password stats admin if TRUE
效果如下图所示：
至此我们的haproxy基本用法已经完毕。
本文出自 “linux运维” 博客，请务必保留此出处http://germanygu.blog.51cto.com/3574209/1555366
标签：haproxy的使用
原文地址：http://germanygu.blog.51cto.com/3574209/1555366
