haproxy是一款功能强大、灵活好用反向代理软件,提供了高可用、负载均衡、后端服务器代理的功能,它在7层负载均衡方面的功能很强大(支持COOKIE track, header rewrite等等),支持双机热备,支持虚拟主机,拥有非常不错的服务器健康检查功能,当其代理的后端服务器出现故障, HAProxy会自动将该服务器摘除,故障恢复后再自动将该服务器加入;同时还提供直观的监控页面,可以清晰实时的监控服务集群的运行状况。
--------------------------------------------------------------------------------
在四层(tcp)实现负载均衡的软件:
lvs------>重量级
nginx------>轻量级,带缓存功能,正则表达式较灵活
haproxy------>模拟四层转发,较灵活
在七层(http)实现反向代理的软件:
haproxy------>天生技能,全面支持七层代理,会话保持,标记,路径转移;
nginx------>只在http协议和mail协议上功能比较好,性能与haproxy差不多;
apache------>功能较差
--------------------------------------------------------------------------------
haproxy的工作模型图
#
当用户并发请求达到一定的数量时,使用haproxy进行负载均衡有明显的优势;而且haproxy还可以根据用户的COOKIEs,根据调度算法,将用户一直定向分配到以前访问过的后端服务器上;为了提高网站访问速度,一般在haproxy的后端都要配置缓存服务器,可以是静态页面内容的缓存,也可以是动态网页内容的缓存,生产环境中有必要添加mysql的缓存。
用户访问网站域名时,DNS解析到外网接口haproxy服务器上,haproxy将请求直接转发(tcp)至后方服务器,或者先分析用户请求,然后以客户端身份向后端服务器发出同样的请求(http),获得后方服务器返回的内容后重新封装,响应给客户端,此时haproxy实现一手端两家,中间翻译官的角色。
Haproxy+Keepalived搭建Weblogic高可用负载均衡集群 2013-09/89732.htm
Keepalived+HAProxy配置高可用负载均衡 2012-03/56748.htm
CentOS 6.3下Haproxy+Keepalived+Apache配置笔记 2013-06/85598.htm
Haproxy + KeepAlived 实现WEB群集 on CentOS 6 2012-03/55672.htm
Haproxy+Keepalived构建高可用负载均衡 2012-03/55880.htm
使用 HAProxy 配置 HTTP 负载均衡器 2015-01/112487.htm
--------------------------------------------------------------------------------
haproxy目前同时更新三个版本
1.5系列
1.4系列
1.3系列
官方站点:www.haproxy.com
我们可以到官方下载源码包,编译安装;如果系统安装包内提供了rpm包,可以直接yum安装,这就要看你使用的操作系统版本了。
--------------------------------------------------------------------------------
配置文件安装目录:/etc/haproxy/haproxy.conf
haproxy的配置文件分为四个部分:
全局配置:
global: 全局配置段
代理配置:
default: 默认配置----->所有在backend、frontend、linsten中相同内容可以在此定义;
frontend:前段配置----->定义前端套接字,接受客户端请求;
backend: 后端配置----->定义后端分配规则,与后端服务器交互;
listen: 绑定配置----->直接将指定的客户端与后端特定服务器绑定到一起;
通常没有特别需求,不需要手动调试配置文件里面的选项,大部分默认值就可以满足我们的需求;而且官方文档介绍说很多选项都建议使用默认。但是有些选项我们经常要打交道的,必须对其有一定了解和调试的能力,下面介绍一些常用选项的配置。
--------------------------------------------------------------------------------
giobal
--------------------------------------------------------------------------------
* 进程管理及安全相关的参数
- 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:在BSD系统上禁用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
------------------------------------------------------------------------------------
--------------------------------------------------------------------------------
balance 算法
balance
balance url_param [check_post [
定义负载均衡算法,可用于“defaults”、“listen”和“backend”。
roundrobin:基于权重进行轮叫,在服务器的处理时间保持均匀分布时,这是最平衡、最公平的算法。此算法是动态的,这表示其权重可以在运行时进行调整,不过,在设计上,每个后端服务器仅能最多接受4128个连接;
static-rr:基于权重进行轮叫,与roundrobin类似,但是为静态方法,在运行时调整其服务器权重不会生效;不过,其在后端服务器连接数上没有限制;
leastconn:新的连接请求被派发至具有最少连接数目的后端服务器;在有着较长时间会话的场景中推荐使用此算法,如LDAP、SQL等,其并不太适用于较短会话应用层协议,如HTTP;此算法是动态的,可以在运行时调整其权重;
source:将请求的源地址进行hash运算,并由后端服务器的权重总数相除后派发至某匹配的服务器;这可以使得同一个客户端IP的请求始终被派发至某特定的服务器;不过,当服务器权重总数发生变化时,如某服务器宕机或添加了新的服务器,许多客户端的请求可能会被派发至与此前请求不同的服务器;常用于负载均衡无COOKIE功能的基于TCP的协议;其默认为静态,不过也可以使用hash-type修改此特性;
hash-type:
map-based:静态;哈希算法
consistent:动态;一致性哈希算法
uri:对URI的左半部分(“问题”标记之前的部分)或整个URI进行hash运算,并由服务器的总权重相除后派发至某匹配的服务器;这可以使得对同一个URI的请求总是被派发至某特定的服务器,除非服务器的权重总数发生了变化;此算法常用于代理缓存或反病毒代理以提高缓存的命中率;需要注意的是,此算法仅应用于HTTP后端服务器场景;其默认为静态算法,不过也可以使用hash-type修改此特性;
url_param:通过
hdr(
--------------------------------------------------------------------------------
hash-type
hash-type
定义用于将hash码映射至后端服务器的方法;其不能用于frontend区段;可用方法有map-based和consistent,在大多数场景下推荐使用默认的map-based方法。
map-based:hash表是一个包含了所有在线服务器的静态数组。其hash值将会非常平滑,会将权重考虑在列,但其为静态方法,对在线服务器的权重进行调整将不会生效,这意味着其不支持慢速启动。此外,挑选服务器是根据其在数组中的位置进行的,因此,当一台服务器宕机或添加了一台新的服务器时,大多数连接将会被重新派发至一个与此前不同的服务器上,对于缓存服务器的工作场景来说,此方法不甚适用。
consistent:hash表是一个由各服务器填充而成的树状结构;基于hash键在hash树中查找相应的服务器时,最近的服务器将被选中。此方法是动态的,支持在运行时修改服务器权重,因此兼容慢速启动的特性。添加一个新的服务器时,仅会对一小部分请求产生影响,因此,尤其适用于后端服务器为cache的场景。不过,此算法不甚平滑,派发至各服务器的请求未必能达到理想的均衡效果,因此,可能需要不时的调整服务器的权重以获得更好的均衡性。
--------------------------------------------------------------------------------
bind
bind [
--------------------------------------------------------------------------------
mode
mode { tcp|http|health }
设定实例的运行模式或协议。当实现内容交换时,前端和后端必须工作于同一种模式(一般说来都是HTTP模式),否则将无法启动实例。
tcp:实例运行于纯TCP模式,在客户端和服务器端之间将建立一个全双工的连接,且不会对7层报文做任何类型的检查;此为默认模式,通常用于SSL、SSH、SMTP等应用;
http:实例运行于HTTP模式,客户端请求在转发至后端服务器之前将被深度分析,所有不与RFC格式兼容的请求都会被拒绝;
health:实例工作于health模式,其对入站请求仅响应“OK”信息并关闭连接,且不会记录任何日志信息;此模式将用于响应外部组件的健康状态检查请求;目前业讲,此模式已经废弃,因为tcp或http模式中的monitor关键字可完成类似功能;
--------------------------------------------------------------------------------
log
log global
log
--------------------------------------------------------------------------------
maxconn
maxconn
设定一个前端的最大并发连接数,因此,其不能用于backend区段。对于大型站点来说,可以尽可能提高此值以便让haproxy管理连接队列,从而避免无法应答用户请求。当然,此最大值不能超出“global”段中的定义。此外,需要留心的是,haproxy会为每个连接维持两个缓冲,每个缓冲的大小为8KB,再加上其它的数据,每个连接将大约占用17KB的RAM空间。这意味着经过适当优化后,有着1GB的可用RAM空间时将能维护40000-50000并发连接。
如果为
--------------------------------------------------------------------------------
default_backend
default_backend
在没有匹配的"use_backend"规则时为实例指定使用的默认后端,因此,其不可应用于backend区段。在"frontend"和"backend"之间进行内容交换时,通常使用"use-backend"定义其匹配规则;而没有被规则匹配到的请求将由此参数指定的后端接收。
使用案例:
use_backend dynamic if url_dyn
use_backend static if url_css url_img extension_img
default_backend dynamic
--------------------------------------------------------------------------------
server 定义后端服务器
------------------------------------------------------------------------------------
server
为后端声明一个server,因此,不能用于defaults和frontend区段。
:此服务器的的IPv4地址,也支持使用可解析的主机名,只不过在启动时需要解析主机名至相应的IPv4地址;
[:port]:指定将连接请求所发往的此服务器时的目标端口,其为可选项;未设定时,将使用客户端请求时的同一相端口;
[param*]:为此服务器设定的一系参数;其可用的参数非常多,具体请参考官方文档中的说明,下面仅说明几个常用的参数;
---------------------------------------------------
服务器或默认服务器参数:
disabled:这只此服务器禁用;
backup:设定为备用服务器,仅在负载均衡场景中的其它server均不可用于启用此server;
check:启动对此server执行健康状态检查,其可以借助于额外的其它参数完成更精细的设定,如:
inter
rise
fall
COOKIE
maxconn
maxqueue
observe
redir
server srv1 172.16.100.6:80 redir http://imageserver.linuxidc.com check
weight
检查方法:
option httpchk
option httpchk
option httpchk
option httpchk
backend https_relay
mode tcp
option httpchk OPTIONS * HTTP/1.1\r\nHost:\ www.linuxidc.com
server apache1 192.168.1.1:443 check port 80
使用案例:
server first 172.16.13.13:1080 COOKIE first check inter 1000
server second 172.16.13.14:1080 COOKIE second check inter 1000
-------------------------------------------------------------------------------------
--------------------------------------------------------------------------------
capture request header
capture request header
捕获并记录指定的请求首部最近一次出现时的第一个值,仅能用于“frontend”和“listen”区段。捕获的首部值使用花括号{}括起来后添加进日志中。如果需要捕获多个首部值,它们将以指定的次序出现在日志文件中,并以竖线“|”作为分隔符。不存在的首部记录为空字符串,最常需要捕获的首部包括在虚拟主机环境中使用的“Host”、上传请求首部中的“Content-length”、快速区别真实用户和网络机器人的“User-agent”,以及代理环境中记录真实请求来源的“X-Forward-For”。
可以捕获的请求首部的个数没有限制,但每个捕获最多只能记录64个字符。为了保证同一个frontend中日志格式的统一性,首部捕获仅能在frontend中定义。
capture response header
capture response header
捕获并记录响应首部,其格式和要点同请求首部。
--------------------------------------------------------------------------------
stats enable
启用基于程序编译时默认设置的统计报告,不能用于“frontend”区段。只要没有另外的其它设定,它们就会使用如下的配置:
- stats uri : /haproxy?stats //url
- stats realm : "HAProxy Statistics" //做认证是提供的信息
- stats auth : no authentication
- stats scope : no restriction //无限制
尽管“stats enable”一条就能够启用统计报告,但还是建议设定其它所有的参数,以免其依赖于默认设定而带来非期后果。下面是一个配置案例。
123456789 backend public_www
server websrv1 172.16.100.11:80
stats enable
stats hide-version
stats scope .
stats uri /haproxyadmin?stats
stats realm Haproxy\ Statistics
stats auth statsadmin:password
stats auth statsmaster:password
-------------------------------------------------------------------------------------
stats hide-version
启用统计报告并隐藏HAProxy版本报告,不能用于“frontend”区段。默认情况下,统计页面会显示一些有用信息,包括HAProxy的版本号,然而,向所有人公开HAProxy的精确版本号是非常有风险的,因为它能帮助恶意用户快速定位版本的缺陷和漏洞。尽管“stats hide-version”一条就能够启用统计报告,但还是建议设定其它所有的参数,以免其依赖于默认设定而带来非期后果。具体请参照“stats enable”一节的说明。
-------------------------------------------------------------------------------------
stats realm
stats realm
启用统计报告并高精认证领域,不能用于“frontend”区段。haproxy在读取realm时会将其视作一个单词,因此,中间的任何空白字符都必须使用反斜线进行转义。此参数仅在与“stats auth”配置使用时有意义。
尽管“stats realm”一条就能够启用统计报告,但还是建议设定其它所有的参数,以免其依赖于默认设定而带来非期后果。具体请参照“stats enable”一节的说明。
-------------------------------------------------------------------------------------
stats scope
stats scope {
启用统计报告并限定报告的区段,不能用于“frontend”区段。当指定此语句时,统计报告将仅显示其列举出区段的报告信息,所有其它区段的信息将被隐藏。如果需要显示多个区段的统计报告,此语句可以定义多次。需要注意的是,区段名称检测仅仅是以字符串比较的方式进行,它不会真检测指定的区段是否真正存在。
尽管“stats scope”一条就能够启用统计报告,但还是建议设定其它所有的参数,以免其依赖于默认设定而带来非期后果。下面是一个配置案例。
backend private_monitoring
stats enable
stats uri /haproxyadmin?stats
stats refresh 10s
----------------------------------------------------------------------------------------
stats auth
stats auth
启用带认证的统计报告功能并授权一个用户帐号,其不能用于“frontend”区段。
此语句将基于默认设定启用统计报告功能,并仅允许其定义的用户访问,其也可以定义多次以授权多个用户帐号。可以结合“stats realm”参数在提示用户认证时给出一个领域说明信息。在使用非法用户访问统计功能时,其将会响应一个“401 Forbidden”页面。其认证方式为HTTP Basic认证,密码传输会以明文方式进行,因此,配置文件中也使用明文方式存储以说明其非保密信息故此不能相同于其它关键性帐号的密码。
尽管“stats auth”一条就能够启用统计报告,但还是建议设定其它所有的参数,以免其依赖于默认设定而带来非期后果。
---------------------------------------------------------------------------------------
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
--------------------------------------------------------------------------------
option logasap
no option logasap
启用或禁用提前将HTTP请求记入日志,不能用于“backend”区段。
默认情况下,HTTP请求是在请求结束时进行记录以便能将其整体传输时长和字节数记入日志,由此,传较大的对象时,其记入日志的时长可能会略有延迟。“option logasap”参数能够在服务器发送complete首部时即时记录日志,只不过,此时将不记录整体传输时长和字节数。此情形下,捕获“Content-Length”响应首部来记录传输的字节数是一个较好选择。下面是一个例子。
listen http_proxy 0.0.0.0:80
mode http
option httplog
option logasap
log 172.16.13.9 local2
--------------------------------------------------------------------------------
option forwardfor
option forwardfor [ except
允许在发往服务器的请求首部中插入“X-Forwarded-For”首部。
if-none:仅在此首部不存在时才将其添加至请求报文问道中。
更多详情见请继续阅读下一页的精彩内容: 2015-06/118968p2.htm