一:haproxy实验环境拓扑图:
二:haproxy的配置:
global settings: 全局配置段
主要用于定义haproxy进程自身的工作特性;
proxies: 代理配置段
backend: 后端服务器组
frontend: 定义面向客户的监听的地址和端口,以及关联到的后端服务器组;
listen: 组合方式直接定义frontend及相关的backend的一种机制;
defaults: 定义默认配置;
三:global中的配置参数
* 进程管理及安全相关的参数
- chroot
- daemon:让haproxy以守护进程的方式工作于后台,其等同于“-D”选项的功能,当然,也可以在命令行中以“-db”选项将其禁用;
- gid
- group
- log
- log-send-hostname [
- nbproc
- pidfile:
- uid:以指定的UID身份运行haproxy进程;
- ulimit-n:设定每进程所能够打开的最大文件描述符数目,默认情况下其会自动进行计算,因此不推荐修改此选项;
- user:同uid,但使用的是用户名;
- stats:
- node:定义当前节点的名称,用于HA场景中多haproxy进程共享同一个IP地址时;
- description:当前实例的描述信息;
* 性能调整相关的参数
- maxconn
- maxpipes
- 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
- tune.chksize
- tune.maxaccept
- tune.maxpollevents
- tune.maxrewrite
- tune.rcvbuf.client
- tune.rcvbuf.server
- tune.sndbuf.client:
- tune.sndbuf.server:
* Debug相关的参数
- debug
- quiet
四:代理端配置详解:
代理相关的配置可以如下配置段中。
- defaults
- frontend
- backend
- listen
“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(
根据用户请求报文中,指定的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
rise
fall
cookie
maxconn
maxqueue
observe
redir
server srv1 172.16.100.6:80 redir http://p_w_picpathserver.magedu.com check
weight
备用服务器的实现:
修改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 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 }
在指定的条件满足时启用统计报告页面的管理级别功能,它允许通过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基本用法已经完毕。