ITPub博客

首页 > Linux操作系统 > Linux操作系统 > HAProxy详解

HAProxy详解

原创 Linux操作系统 作者:lhrbest 时间:2020-02-20 20:41:16 0 删除 编辑


HAProxy详解


HAProxy

https://jeremyxu2010.github.io/2018/02/%E9%AB%98%E5%8F%AF%E7%94%A8%E4%B9%8Bkeepalivedhaproxy/


尽管HAProxy 非常稳定,但仍然无法规避操作系统故障、主机硬件故障、网络故障甚至断电带来的风险。所以必须对 HAProxy 实施高可用方案。 可以 利用Keepalived 实现 HAProxy 热备方案。即两台主机上的两个 HAProxy 实例同时在线,其中权重较高的实例为 MASTER MASTER 出现问题时,另一台实例自动接管所有流量。

在两台HAProxy 的主机上分别运行着一个 Keepalived 实例,这两个 Keepalived 争抢同一个虚 IP 地址,两个 HAProxy 也尝试去绑定这同一个虚 IP 地址上的端口。显然,同时只能有一个 Keepalived 抢到这个虚 IP ,抢到了这个虚 IP Keepalived 主机上的 HAProxy 便是当前的 MASTER Keepalived 内部维护一个权重值,权重值最高的 Keepalived 实例能够抢到虚 IP 。同时 Keepalived 会定期 check 本主机上的 HAProxy 状态,状态 OK 时权重值增加。


HAProxy是什么

HAProxy是一个免费的负载均衡软件,可以运行于大部分主流的Linux操作系统上。

HAProxy提供了L4(TCP)和L7(HTTP)两种负载均衡能力,具备丰富的功能。HAProxy的社区非常活跃,版本更新快速(最新稳定版1.7.2于2017/01/13推出)。最关键的是,HAProxy具备媲美商用负载均衡器的性能和稳定性。

因为HAProxy的上述优点,它当前不仅仅是免费负载均衡软件的首选,更几乎成为了唯一选择。

HAProxy的核心能力和关键特性

HAProxy的核心功能

  • 负载均衡:L4和L7两种模式,支持RR/静态RR/LC/IP Hash/URI Hash/URL_PARAM Hash/HTTP_HEADER Hash等丰富的负载均衡算法
  • 健康检查:支持TCP和HTTP两种健康检查模式
  • 会话保持:对于未实现会话共享的应用集群,可通过Insert Cookie/Rewrite Cookie/Prefix Cookie,以及上述的多种Hash方式实现会话保持
  • SSL:HAProxy可以解析HTTPS协议,并能够将请求解密为HTTP后向后端传输
  • HTTP请求重写与重定向
  • 监控与统计:HAProxy提供了基于Web的统计信息页面,展现健康状态和流量数据。基于此功能,使用者可以开发监控程序来监控HAProxy的状态

从这个核心功能来看,haproxy实现的功能类似于nginx的L4、L7反向代理。

HAProxy的关键特性

性能

  • 采用单线程、事件驱动、非阻塞模型,减少上下文切换的消耗,能在1ms内处理数百个请求。并且每个会话只占用数KB的内存。
  • 大量精细的性能优化,如O(1)复杂度的事件检查器、延迟更新技术、Single-buffereing、Zero-copy forwarding等等,这些技术使得HAProxy在中等负载下只占用极低的CPU资源。
  • HAProxy大量利用操作系统本身的功能特性,使得其在处理请求时能发挥极高的性能,通常情况下,HAProxy自身只占用15%的处理时间,剩余的85%都是在系统内核层完成的。
  • HAProxy作者在8年前(2009)年使用1.4版本进行了一次测试,单个HAProxy进程的处理能力突破了10万请求/秒,并轻松占满了10Gbps的网络带宽。

稳定性

作为建议以单进程模式运行的程序,HAProxy对稳定性的要求是十分严苛的。按照作者的说法,HAProxy在13年间从未出现过一个会导致其崩溃的BUG,HAProxy一旦成功启动,除非操作系统或硬件故障,否则就不会崩溃(我觉得可能多少还是有夸大的成分)。

在上文中提到过,HAProxy的大部分工作都是在操作系统内核完成的,所以HAProxy的稳定性主要依赖于操作系统,作者建议使用2.6或3.x的Linux内核,对sysctls参数进行精细的优化,并且确保主机有足够的内存。这样HAProxy就能够持续满负载稳定运行数年之久。

HAProxy关键配置详解

总览

HAProxy的配置文件共有5个域

  • global:用于配置全局参数
  • default:用于配置所有frontend和backend的默认属性
  • frontend:用于配置前端服务(即HAProxy自身提供的服务)实例
  • backend:用于配置后端服务(即HAProxy后面接的服务)实例组
  • listen:frontend+backend的组合配置,可以理解成更简洁的配置方法

global域的关键配置

  • daemon:指定HAProxy以后台模式运行,通常情况下都应该使用这一配置
  • user [username] :指定HAProxy进程所属的用户
  • group [groupname] :指定HAProxy进程所属的用户组
  • log [address][device][maxlevel][minlevel]:日志输出配置,如log 127.0.0.1 local0 info warning,即向本机rsyslog或syslog的local0输出info到warning级别的日志。其中[minlevel]可以省略。HAProxy的日志共有8个级别,从高到低为emerg/alert/crit/err/warning/notice/info/debug
  • pidfile :指定记录HAProxy进程号的文件绝对路径。主要用于HAProxy进程的停止和重启动作。
  • maxconn :HAProxy进程同时处理的连接数,当连接数达到这一数值时,HAProxy将停止接收连接请求

frontend域的关键配置

  • acl [name][criterion] [flags][operator] [value]:定义一条ACL,ACL是根据数据包的指定属性以指定表达式计算出的true/false值。如"acl url_ms1 path_beg -i /ms1/“定义了名为url_ms1的ACL,该ACL在请求uri以/ms1/开头(忽略大小写)时为true
  • bind [ip]:[port]:frontend服务监听的端口
  • default_backend [name]:frontend对应的默认backend
  • disabled:禁用此frontend
  • http-request [operation][condition]:对所有到达此frontend的HTTP请求应用的策略,例如可以拒绝、要求认证、添加header、替换header、定义ACL等等。
  • http-response [operation][condition]:对所有从此frontend返回的HTTP响应应用的策略,大体同上
  • log:同global域的log配置,仅应用于此frontend。如果要沿用global域的log配置,则此处配置为log global
  • maxconn:同global域的maxconn,仅应用于此frontend
  • mode:此frontend的工作模式,主要有http和tcp两种,对应L7和L4两种负载均衡模式
  • option forwardfor:在请求中添加X-Forwarded-For Header,记录客户端ip
  • option http-keep-alive:以KeepAlive模式提供服务
  • option httpclose:与http-keep-alive对应,关闭KeepAlive模式,如果HAProxy主要提供的是接口类型的服务,可以考虑采用httpclose模式,以节省连接数资源。但如果这样做了,接口的调用端将不能使用HTTP连接池
  • option httplog:开启httplog,HAProxy将会以类似Apache HTTP或Nginx的格式来记录请求日志
  • option tcplog:开启tcplog,HAProxy将会在日志中记录数据包在传输层的更多属性
  • stats uri [uri]:在此frontend上开启监控页面,通过[uri]访问
  • stats refresh [time]:监控数据刷新周期
  • stats auth [user]:[password]:监控页面的认证用户名密码
  • timeout client [time]:指连接创建后,客户端持续不发送数据的超时时间
  • timeout http-request [time]:指连接创建后,客户端没能发送完整HTTP请求的超时时间,主要用于防止DoS类攻击,即创建连接后,以非常缓慢的速度发送请求包,导致HAProxy连接被长时间占用
  • use_backend [backend] if|unless [acl]:与ACL搭配使用,在满足/不满足ACL时转发至指定的backend

backend域的关键配置

  • acl:同frontend域
  • balance [algorithm]:在此backend下所有server间的负载均衡算法,常用的有roundrobin和source,完整的算法说明见官方文档 configuration.html#4.2-balance
  • cookie:在backend server间启用基于cookie的会话保持策略,最常用的是insert方式,如cookie HA_STICKY_ms1 insert indirect nocache,指HAProxy将在响应中插入名为HA_STICKY_ms1的cookie,其值为对应的server定义中指定的值,并根据请求中此cookie的值决定转发至哪个server。indirect代表如果请求中已经带有合法的HA_STICK_ms1 cookie,则HAProxy不会在响应中再次插入此cookie,nocache则代表禁止链路上的所有网关和缓存服务器缓存带有Set-Cookie头的响应。
  • default-server:用于指定此backend下所有server的默认设置。具体见下面的server配置。
  • disabled:禁用此backend
  • http-request/http-response:同frontend域
  • log:同frontend域
  • mode:同frontend域
  • option forwardfor:同frontend域
  • option http-keep-alive:同frontend域
  • option httpclose:同frontend域
  • option httpchk [METHOD][URL] [VERSION]:定义以http方式进行的健康检查策略。如option httpchk GET /healthCheck.html HTTP/1.1
  • option httplog:同frontend域
  • option tcplog:同frontend域
  • server [name][ip]:[port][params]:定义backend中的一个后端server,[params]用于指定这个server的参数,常用的包括有:

check:指定此参数时,HAProxy将会对此server执行健康检查,检查方法在option httpchk中配置。同时还可以在check后指定inter, rise, fall三个参数,分别代表健康检查的周期、连续几次成功认为server UP,连续几次失败认为server DOWN,默认值是inter 2000ms rise 2 fall 3 cookie [value]:用于配合基于cookie的会话保持,如cookie ms1.srv1代表交由此server处理的请求会在响应中写入值为ms1.srv1的cookie(具体的cookie名则在backend域中的cookie设置中指定) maxconn:指HAProxy最多同时向此server发起的连接数,当连接数到达maxconn后,向此server发起的新连接会进入等待队列。默认为0,即无限 maxqueue:等待队列的长度,当队列已满后,后续请求将会发至此backend下的其他server,默认为0,即无限 weight:server的权重,0-256,权重越大,分给这个server的请求就越多。weight为0的server将不会被分配任何新的连接。所有server默认weight为1

  • timeout connect [time]:指HAProxy尝试与backend server创建连接的超时时间
  • timeout check [time]:默认情况下,健康检查的连接+响应超时时间为server命令中指定的inter值,如果配置了timeout check,HAProxy会以inter作为健康检查请求的连接超时时间,并以timeout check的值作为健康检查请求的响应超时时间
  • timeout server [time]:指backend server响应HAProxy请求的超时时间

default域

上文所属的frontend和backend域关键配置中,除acl、bind、http-request、http-response、use_backend外,其余的均可以配置在default域中。default域中配置了的项目,如果在frontend或backend域中没有配置,将会使用default域中的配置。

listen域

listen域是frontend域和backend域的组合,frontend域和backend域中所有的配置都可以配置在listen域下

官方配置文档

HAProxy的配置项非常多,支持非常丰富的功能,上文只列出了作为L7负载均衡器使用HAProxy时的一些关键参数。完整的参数说明请参见官方文档  configuration.html

使用实例

使用HAProxy搭建L7负载均衡器

总体方案

本节中,我们将使用HAProxy搭建一个L7负载均衡器,应用如下功能

  • 负载均衡

  • 会话保持

  • 健康检查

  • 根据URI前缀向不同的后端集群转发

  • 监控页面

HAProxy配置文件

123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657
globaldaemonmaxconn 30000   #ulimit -n至少为60018user hapidfile /home/ha/haproxy/conf/haproxy.pidlog 127.0.0.1 local0 infolog 127.0.0.1 local1 warningdefaultsmode httplog globaloption http-keep-alive   #使用keepAlive连接option forwardfor        #记录客户端IP在X-Forwarded-For头域中option httplog           #开启httplog,HAProxy会记录更丰富的请求信息timeout connect 5000mstimeout client 10000mstimeout server 50000mstimeout http-request 20000ms    #从连接创建开始到从客户端读取完整HTTP请求的超时时间,用于避免类DoS攻击option httpchk GET /healthCheck.html    #定义默认的健康检查策略frontend http-inbind *:9001maxconn 30000                    #定义此端口上的maxconnacl url_ms1 path_beg -i /ms1/    #定义ACL,当uri以/ms1/开头时,ACL[url_ms1]为trueacl url_ms2 path_beg -i /ms2/    #同上,url_ms2use_backend ms1 if url_ms1       #当[url_ms1]为true时,定向到后端服务群ms1中use_backend ms2 if url_ms2       #当[url_ms2]为true时,定向到后端服务群ms2中default_backend default_servers  #其他情况时,定向到后端服务群default_servers中backend ms1    #定义后端服务群ms1balance roundrobin    #使用RR负载均衡算法cookie HA_STICKY_ms1 insert indirect nocache    #会话保持策略,insert名为"HA_STICKY_ms1"的cookie#定义后端server[ms1.srv1],请求定向到该server时会在响应中写入cookie值[ms1.srv1]#针对此server的maxconn设置为300#应用默认健康检查策略,健康检查间隔和超时时间为2000ms,两次成功视为节点UP,三次失败视为节点DOWNserver ms1.srv1 192.168.8.111:8080 cookie ms1.srv1 maxconn 300 check inter 2000ms rise 2 fall 3#同上,inter 2000ms rise 2 fall 3是默认值,可以省略server ms1.srv2 192.168.8.112:8080 cookie ms1.srv2 maxconn 300 checkbackend ms2    #定义后端服务群ms2balance roundrobincookie HA_STICKY_ms2 insert indirect nocacheserver ms2.srv1 192.168.8.111:8081 cookie ms2.srv1 maxconn 300 checkserver ms2.srv2 192.168.8.112:8081 cookie ms2.srv2 maxconn 300 checkbackend default_servers    #定义后端服务群default_serversbalance roundrobincookie HA_STICKY_def insert indirect nocacheserver def.srv1 192.168.8.111:8082 cookie def.srv1 maxconn 300 checkserver def.srv2 192.168.8.112:8082 cookie def.srv2 maxconn 300 checklisten stats    #定义监控页面bind *:1080                   #绑定端口1080stats refresh 30s             #每30秒更新监控数据stats uri /stats              #访问监控页面的uristats realm HAProxy\ Stats    #监控页面的认证提示stats auth admin:admin        #监控页面的用户名和密码

使用HAProxy搭建L4负载均衡器

HAProxy作为L4负载均衡器工作时,不会去解析任何与HTTP协议相关的内容,只在传输层对数据包进行处理。也就是说,以L4模式运行的HAProxy,无法实现根据URL向不同后端转发、通过cookie实现会话保持等功能。

同时,在L4模式下工作的HAProxy也无法提供监控页面。

但作为L4负载均衡器的HAProxy能够提供更高的性能,适合于基于套接字的服务(如数据库、消息队列、RPC、邮件服务、Redis等),或不需要逻辑规则判断,并已实现了会话共享的HTTP服务。

HAProxy配置文件

1234567891011121314151617181920212223242526
globaldaemonmaxconn 30000   #ulimit -n至少为60018user hapidfile /home/ha/haproxy/conf/haproxy.pidlog 127.0.0.1 local0 infolog 127.0.0.1 local1 warningdefaultsmode tcplog globaloption tcplog            #开启tcplogtimeout connect 5000mstimeout client 10000mstimeout server 10000ms   #TCP模式下,应将timeout client和timeout server设置为一样的值,以防止出现问题option httpchk GET /healthCheck.html    #定义默认的健康检查策略frontend http-inbind *:9002maxconn 30000                    #定义此端口上的maxconndefault_backend default_servers  #请求定向至后端服务群default_serversbackend default_servers    #定义后端服务群default_serversbalance source  #基于客户端IP的会话保持server def.srv1 192.168.8.111:8082 maxconn 300 checkserver def.srv2 192.168.8.112:8082 maxconn 300 check

使用Keepalived实现HAProxy高可用

尽管HAProxy非常稳定,但仍然无法规避操作系统故障、主机硬件故障、网络故障甚至断电带来的风险。所以必须对HAProxy实施高可用方案。

下文将介绍利用Keepalived实现的HAProxy热备方案。即两台主机上的两个HAProxy实例同时在线,其中权重较高的实例为MASTER,MASTER出现问题时,另一台实例自动接管所有流量。

原理

在两台HAProxy的主机上分别运行着一个Keepalived实例,这两个Keepalived争抢同一个虚IP地址,两个HAProxy也尝试去绑定这同一个虚IP地址上的端口。 显然,同时只能有一个Keepalived抢到这个虚IP,抢到了这个虚IP的Keepalived主机上的HAProxy便是当前的MASTER。 Keepalived内部维护一个权重值,权重值最高的Keepalived实例能够抢到虚IP。同时Keepalived会定期check本主机上的HAProxy状态,状态OK时权重值增加。

keepalived配置文件

1234567891011121314151617181920212223
global_defs {router_id LVS_DEVEL  #虚拟路由名称}#HAProxy健康检查配置vrrp_script chk_haproxy {script "killall -0 haproxy"  #使用killall -0检查haproxy实例是否存在,性能高于ps命令interval 2   #脚本运行周期weight 2   #每次检查的加权权重值}#虚拟路由配置vrrp_instance VI_1 {state MASTER           #本机实例状态,MASTER/BACKUP,备机配置文件中请写BACKUPinterface enp0s25      #本机网卡名称,使用ifconfig命令查看virtual_router_id 51   #虚拟路由编号,主备机保持一致priority 101           #本机初始权重,备机请填写小于主机的值(例如100)advert_int 1           #争抢虚地址的周期,秒virtual_ipaddress {192.168.8.201      #虚地址IP,主备机保持一致}track_script {chk_haproxy        #对应的健康检查配置}}

参考

  1. https://github.com/chenzhiwei/linux/tree/master/keepalived
  2. https://www.jianshu.com/p/c9f6d55288c0
  3. http://seanlook.com/2015/05/18/nginx-keepalived-ha/



一、HAProxy简介

(1)HAProxy 是一款提供高可用性、负载均衡以及基于TCP(第四层)和HTTP(第七层)应用的代理软件,支持虚拟主机,它是免费、快速并且可靠的一种解决方案。 HAProxy特别适用于那些负载特大的web站点,这些站点通常又需要会话保持或七层处理。HAProxy运行在时下的硬件上,完全可以支持数以万计的 并发连接。并且它的运行模式使得它可以很简单安全的整合进您当前的架构中, 同时可以保护你的web服务器不被暴露到网络上。

(2)HAProxy 实现了一种事件驱动、单一进程模型,此模型支持非常大的并发连接数。多进程或多线程模型受内存限制 、系统调度器限制以及无处不在的锁限制,很少能处理数千并发连接。事件驱动模型因为在有更好的资源和时间管理的用户端(User-Space) 实现所有这些任务,所以没有这些问题。此模型的弊端是,在多核系统上,这些程序通常扩展性较差。这就是为什么他们必须进行优化以 使每个CPU时间片(Cycle)做更多的工作。

(3)HAProxy 支持连接拒绝 : 因为维护一个连接的打开的开销是很低的,有时我们很需要限制攻击蠕虫(attack bots),也就是说限制它们的连接打开从而限制它们的危害。 这个已经为一个陷于小型DDoS攻击的网站开发了而且已经拯救

了很多站点,这个优点也是其它负载均衡器没有的。

(4)HAProxy 支持全透明代理(已具备硬件防火墙的典型特点): 可以用客户端IP地址或者任何其他地址来连接后端服务器. 这个特性仅在 Linux 2.4/2.6内核打了cttproxy补丁后才可以使用. 这个特性也使得为某特殊 服务器处理部分流量同时又不修改服务器的地址成为可能。

性能

HAProxy借助于OS上几种常见的技术来实现性能的最大化。

1,单进程、事件驱动模型显著降低了上下文切换的开销及内存占用。

2,O(1)事件检查器(event checker)允许其在高并发连接中对任何连接的任何事件实现即时探测。

3,在任何可用的情况下,单缓冲(single buffering)机制能以不复制任何数据的方式完成读写操作,这会节约大量的CPU时钟周期及内存带宽;

4,借助于Linux 2.6 (>= 2.6.27.19)上的splice()系统调用,HAProxy可以实现零复制转发(Zero-copy forwarding),在Linux 3.5及以上的OS中还可以实现零复制启动(zero-starting);

5,内存分配器在固定大小的内存池中可实现即时内存分配,这能够显著减少创建一个会话的时长;

6,树型存储:侧重于使用作者多年前开发的弹性二叉树,实现了以O(log(N))的低开销来保持计时器命令、保持运行队列命令及管理轮询及最少连接队列;

7,优化的HTTP首部分析:优化的首部分析功能避免了在HTTP首部分析过程中重读任何内存区域;

8,精心地降低了昂贵的系统调用,大部分工作都在用户空间完成,如时间读取、缓冲聚合及文件描述符的启用和禁用等;

所有的这些细微之处的优化实现了在中等规模负载之上依然有着相当低的CPU负载,甚至于在非常高的负载场景中,5%的用户空间占用率和95%的系统空间占用率也是非常普遍的现象,这意味着HAProxy进程消耗比系统空间消耗低20倍以上。因此,对OS进行性能调优是非常重要的。即使用户空间的占用率提高一倍,其CPU占用率也仅为10%,这也解释了为何7层处理对性能影响有限这一现象。由此,在高端系统上HAProxy的7层性能可轻易超过硬件负载均衡设备。

在生产环境中,在7层处理上使用HAProxy作为昂贵的高端硬件负载均衡设备故障故障时的紧急解决方案也时长可见。硬件负载均衡设备在“报文”级别处理请求,这在支持跨报文请求(request across multiple packets)有着较高的难度,并且它们不缓冲任何数据,因此有着较长的响应时间。对应地,软件负载均衡设备使用TCP缓冲,可建立极长的请求,且有着较大的响应时间。


安装: https://src.fedoraproject.org/repo/pkgs/haproxy/





https://cloud.tencent.com/developer/article/1444897


2.解压

tar zxf haproxy-1.7.9.tar.gz

3.编译安装

cd haproxy-1.7.9

make TARGET=linux2628 ARCH=x86_64 PREFIX=/usr/local/haproxy
make install PREFIX=/usr/local/haproxy
#参数说明
TARGET=linux26 #内核版本,使用uname -r查看内核,如:2.6.18-371.el5,此时该参数就为linux26;kernel 大于2.6.28的用:TARGET=linux2628
ARCH=x86_64 #系统位数
PREFIX=/usr/local/haprpxy #/usr/local/haprpxy为haprpxy安装路径




二,安装配置HAProxy

以下实验环境均为CentOS6.6 i686平台。

1,安装haproxy

2,详解配置文件

haproxy 的配置文件由两部分组成:全局设定和对代理的设定,共分为五段:global,defaults,frontend,backend,listen。

2.1 配置文件格式

HAProxy的配置处理3类来主要参数来源:

——最优先处理的命令行参数;

——“global”配置段,用于设定全局配置参数;

——proxy相关配置段,如“defaults”、“listen”、“frontend”和“backend”;

2.2 时间格式

一些包含了值的参数表示时间,如超时时长。这些值一般以毫秒为单位,但也可以使用其它的时间单位后缀。

2.3 全局配置

* 进程管理及安全相关的参数

– 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:设定每进程所能够打开的最大文件描述符数目,默认情况下其会自动进行计算,因此不推荐修改此选项;Linux默认单进程打开文件数为1024个

– 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相关的参数

* 超时时长

* 实现访问控制:

2.4 代理

代理相关的配置可以如下配置段中。

“defaults”段用于为所有其它配置段提供默认参数,这配置默认配置参数可由下一个“defaults”所重新设定。
“frontend”段用于定义一系列监听的套接字,这些套接字可接受客户端请求并与之建立连接。
“backend”段用于定义一系列“后端”服务器,代理将会将对应客户端的请求转发至这些服务器。
“listen”段通过关联“frontend”和“backend”定义了一个完整的代理,通常只对TCP流量有用。

所有代理的名称只能使用大写字母、小写字母、数字、-(中线)、_(下划线)、.(点号)和:(冒号)。此外,ACL名称会区分字母大小写。

三、配置文件中的关键字参考

3.1 balance

定义负载均衡算法,可用于“defaults”、“listen”和“backend”。用于在负载均衡场景中挑选一个server,其仅应用于持久信息不可用的条件下或需要将一个连接重新派发至另一个服务器时。支持的算法有:

3.11 roundrobin:基于权重进行轮叫,在服务器的处理时间保持均匀分布时,这是最平衡、最公平的算法。此算法是动态的,这表示其权重可以在运行时进行调整,不过,在设计上,每个后端服务器仅能最多接受4128个连接;并支持慢启动。

3.12 static-rr:基于权重进行轮叫,与roundrobin类似,但是为静态方法,在运行时调整其服务器权重不会生效;不过,其在后端服务器连接数上没有限制;不支持慢启动,在高负荷的情况下,服务器重新上线时会立即被分配大量连接。

3.13 leastconn(WLC):适用于长连接的会话,新的连接请求被派发至具有最少连接数目的后端服务器;在有着较长时间会话的场景中推荐使用此算法,如LDAP、SQL等,其并不太适用于较短会话的应用层协议,如HTTP;此算法是动态的,

可以在运行时调整其权重;

3.14 source:将请求的源地址进行hash运算,并由后端服务器的权重总数相除后派发至某匹配的服务器;这可以使得同一个客户端IP的请求始终被派发至某特定的服务器;不过,当服务器权重总数发生变化时,如某服务器宕机或添加了新的服务器,许多客户端的请求可能会被派发至与此前请求不同的服务器;常用于负载均衡无cookie功能的基于TCP的协议;其默认为静态,不过也可以使用hash-type修改此特性;

1,对原地址hash,第一次调度时使用WLC
source:IP层,位于同一个NAT服务器背后的多个请求都会定向至同一个upstream server,不利于负载均衡,一般只有不支持使用cookie插入又需要保持会话时使用
cookie:应用层,有更好的负载均衡效果;

2,hash/weight%ip :除以权重取模

3.15 uri:对URI的左半部分(“问题”标记之前的部分)或整个URI进行hash运算,并由服务器的总权重相除后派发至某匹配的服务器;这可以使得对同一个URI的请求总是被派发至某特定的服务器,除非服务器的权重总数发生了变化;此算法常用于代理缓存或反病毒代理以提高缓存的命中率;需要注意的是,此算法仅应用于HTTP后端服务器场景;其默认为静态算法,不过也可以使用hash-type修改此特性;

3.16 url_param:通过<argument>为URL指定的参数在每个HTTP GET请求中将会被检索;如果找到了指定的参数且其通过等于号“=”被赋予了一个值,那么此值将被执行hash运算并被服务器的总权重相除后派发至某匹配的服务器;此算法可以通过追踪请求中的用户标识进而确保同一个用户ID的请求将被送往同一个特定的服务器,除非服务器的总权重发生了变化;如果某请求中没有出现指定的参数或其没有有效值,则使用轮叫算法对相应请求进行调度;此算法默认为静态的,不过其也可以使用hash-type修改此特性;

3.17 hdr(<name>):对于每个HTTP请求,通过<name>指定的HTTP首部将会被检索;如果相应的首部没有出现或其没有有效值,则使用轮叫算法对相应请求进行调度;其有一个可选选项“use_domain_only”,可在指定检索类似Host类的首部时仅计算域名部分(比如通过www.feiyu.com来说,仅计算feiyu字符串的hash值)以降低hash算法的运算量;此算法默认为静态的,不过其也可以使用hash-type修改此特性;

3.18 rdp-cookie(name)

,表示根据据cookie(name)来锁定并哈希每一次TCP请求。

3.2 bind

此指令仅能用于frontend和listen区段,用于定义一个或几个监听的套接字。

<address>:可选选项,其可以为主机名、IPv4地址、IPv6地址或*;省略此选项、将其指定为*或0.0.0.0时,将监听当前系统的所有IPv4地址;<port_range>:可以是一个特定的TCP端口,也可是一个端口范围(如5005-5010),代理服务器将通过指定的端口来接收客户端请求;需要注意的是,每组监听的套接字<address:port>在同一个实例上只能使用一次,而且小于1024的端口需要有特定权限的用户才能使用,这可能需要通过uid参数来定义;<interface>:指定物理接口的名称,仅能在Linux系统上使用;其不能使用接口别名,而仅能使用物理接口名称,而且只有管理有权限指定绑定的物理接口;

3.3 mode

设定实例的运行模式或协议。当实现内容交换时,前端和后端必须工作于同一种模式(一般说来都是HTTP模式),否则将无法启动实例。

tcp:实例运行于纯TCP模式,在客户端和服务器端之间将建立一个全双工的连接,且不会对7层报文做任何类型的检查;通常用于SSL、SSH、SMTP等应用;
http:实例运行于HTTP模式,客户端请求在转发至后端服务器之前将被深度分析,所有不与RFC格式兼容的请求都会被拒绝;此为默认模式;
health:实例工作于health模式,其对入站请求仅响应“OK”信息并关闭连接,且不会记录任何日志信息;此模式将用于响应外部组件的健康状态检查请求;目前来讲,此模式已经废弃,因为tcp或http模式中的monitor关键字可完成类似功能;

 

3.4 hash-type

定义用于将hash码映射至后端服务器的方法;其不能用于frontend区段;可用方法有map-based和consistent,在大多数场景下推荐使用默认的map-based方法。

map-based:hash表是一个包含了所有在线服务器的静态数组。其hash值将会非常平滑,会将权重考虑在列,但其为静态方法,对在线服务器的权重进行调整将不会生效,这意味着其不支持慢速启动。此外,挑选服务器是根据其在数组中的

位置进行的,因此,当一台服务器宕机或添加了一台新的服务器时,大多数连接将会被重新派发至一个与此前不同的服务器上,对于缓存服务器的工作场景来说,此方法不甚适用。

consistent:“一致性哈希算法”,hash表是一个由各服务器填充而成的树状结构,将服务器散列在hash环上;基于hash键在hash树中查找相应的服务器时,最近的服务器将被选中。此方法是动态的,支持在运行时修改服务器权重,因此兼

容慢速启动的特性。添加一个新的服务器时,仅会对一小部分请求产生影响,因此,尤其适用于后端服务器为cache的场景。不过,此算法不甚平滑,派发至各服务器的请求未必能达到理想的均衡效果,因此,可能需要不时的调整服务器的权

重以获得更好的均衡性。

 

3.5 log

为每个实例启用事件和流量日志,因此可用于所有区段。每个实例最多可以指定两个log参数,不过,如果使用了“log global”且”global”段已经定了两个log参数时,多余了log参数将被忽略。

global:当前实例的日志系统参数同”global”段中的定义时,将使用此格式;每个实例仅能定义一次“log global”语句,且其没有任何额外参数;

<address>:定义日志发往的位置,其格式之一可以为<IPv4_address:PORT>,其中的port为UDP协议端口,默认为514;格式之二为Unix套接字文件路径,但需要留心chroot应用及用户的读写权限;

<facility>:可以为syslog系统的标准facility之一;

<level>:定义日志级别,即输出信息过滤器,默认为所有信息;指定级别时,所有等于或高于此级别的日志信息将会被发送;

 

3.6 maxconn

设定一个前端的最大并发连接数,因此,其不能用于backend区段。对于大型站点来说,可以尽可能提高此值以便让haproxy管理连接队列,从而避免无法应答用户请求。当然,此最大值不能超出“global”段中的定义。此外,需要留心的是,haproxy会为每个连接维持两个缓冲,每个缓冲的大小为8KB,再加上其它的数据,每个连接将大约占用17KB的RAM空间。这意味着经过适当优化后,有着1GB的可用RAM空间时将能维护40000-50000并发连接。

如果为<conns>指定了一个过大值,极端场景下,其最终占据的空间可能会超出当前主机的可用内存,这可能会带来意想不到的结果;因此,将其设定了一个可接受值方为明智决定。其默认为2000。

3.7 default_backend

在没有匹配的”use_backend”规则时为实例指定使用的默认后端,因此,其不可应用于backend区段。在”frontend”和”backend”之间进行内容交换时,通常使用”use-backend”定义其匹配规则;而没有被规则匹配到的请求将由此参数指定的后端接收。

<backend>:指定使用的后端的名称;

使用案例:

3.8 server

为后端声明一个server,因此,不能用于defaults和frontend区段。

<name>:为此服务器指定的内部名称,其将出现在日志及警告信息中;如果设定了”http-send-server-name”,它还将被添加至发往此服务器的请求首部中;

<address>:此服务器的的IPv4地址,也支持使用可解析的主机名,只不过在启动时需要解析主机名至相应的IPv4地址;

[:port]:指定将连接请求所发往的此服务器时的目标端口,其为可选项;未设定时,将使用客户端请求时的同一相端口;

[param*]:为此服务器设定的一系参数;其可用的参数非常多,具体请参考官方文档中的说明,下面仅说明几个常用的参数;

服务器或默认服务器参数:

backup:设定为备用服务器,仅在负载均衡场景中的其它server均不可用于启用此server;

check:启动对此server执行健康状态检查,其可以借助于额外的其它参数完成更精细的设定,如:

inter <delay>:设定健康状态检查的时间间隔,单位为毫秒,默认为2000;也可以使用fastinter和downinter来根据服务器端状态优化此时间延迟;

rise <count>:设定健康状态检查中,某离线的server从离线状态转换至正常状态需要成功检查的次数;

fall <count>:确认server从正常状态转换为不可用状态需要检查的次数;

cookie <value>:为指定server设定cookie值,此处指定的值将在请求入站时被检查,第一次为此值挑选的server将在后续的请求中被选中,其目的在于实现持久连接的功能;

maxconn <maxconn>:指定此服务器接受的最大并发连接数;如果发往此服务器的连接数目高于此处指定的值,其将被放置于请求队列,以等待其它连接被释放;

haproxy 有n个进程,每个支持m个连接,后端有x个服务器,每个最大支持y个连接,则 n*m <= x*y,如果后端服务器支持排队,则n*m <= x*(y+z),z为每个服务器的排队队列

maxqueue <maxqueue>:设定请求队列的最大长度;

observe <mode>:通过观察服务器的通信状况来判定其健康状态,默认为禁用,其支持的类型有“layer4”和“layer7”,“layer7”仅能用于http代理场景;

redir <prefix>:启用重定向功能,将发往此服务器的GET和HEAD请求均以302状态码响应;需要注意的是,在prefix后面不能使用/,且不能使用相对地址,以免造成循环;例如:

weight <weight>:权重,默认为1,最大值为256,0表示不参与负载均衡(不被调度);

检查方法:

使用案例:

3.9 capture request header

捕获并记录指定的请求首部最近一次出现时的第一个值,仅能用于“frontend”和“listen”区段。捕获的首部值使用花括号{}括起来后添加进日志中。如果需要捕获多个首部值,它们将以指定的次序出现在日志文件中,并以竖线“|”作为分隔符。不存在的首部记录为空字符串,最常需要捕获的首部包括在虚拟主机环境中使用的“Host”、上传请求首部中的“Content-length”、快速区别真实用户和网络机器人的“User-agent”,以及代理环境中记录真实请求来源的“X-Forward-For”。

<name>:要捕获的首部的名称,此名称不区分字符大小写,但建议与它们出现在首部中的格式相同,比如大写首字母。需要注意的是,记录在日志中的是首部对应的值,而非首部名称。

<length>:指定记录首部值时所记录的精确长度,超出的部分将会被忽略。

可以捕获的请求首部的个数没有限制,但每个捕获最多只能记录64个字符。为了保证同一个frontend中日志格式的统一性,首部捕获仅能在frontend中定义。

 

3.10 capture response header

捕获并记录响应首部,其格式和要点同请求首部。

 

3.11 stats enable

启用基于程序编译时默认设置的统计报告,不能用于“frontend”区段。只要没有另外的其它设定,它们就会使用如下的配置:

尽管“stats enable”一条就能够启用统计报告,但还是建议设定其它所有的参数,以免其依赖于默认设定而带来非期后果。下面是一个配置案例。

3.12 stats hide-version

启用统计报告并隐藏HAProxy版本报告,不能用于“frontend”区段。默认情况下,统计页面会显示一些有用信息,包括HAProxy的版本号,然而,向所有人公开HAProxy的精确版本号是非常有风险的,因为它能帮助恶意用户快速定位版本的缺陷和漏洞。尽管“stats hide-version”一条就能够启用统计报告,但还是建议设定其它所有的参数,以免其依赖于默认设定而带来非期后果。具体请参照“stats enable”一节的说明。

3.13 stats realm

启用统计报告并高精认证领域,不能用于“frontend”区段。haproxy在读取realm时会将其视作一个单词,因此,中间的任何空白字符都必须使用反斜线进行转义。此参数仅在与“stats auth”配置使用时有意义。

<realm>:实现HTTP基本认证时显示在浏览器中的领域名称,用于提示用户输入一个用户名和密码。

尽管“stats realm”一条就能够启用统计报告,但还是建议设定其它所有的参数,以免其依赖于默认设定而带来非期后果。具体请参照“stats enable”一节的说明。

3.14 stats scope

启用统计报告并限定报告的区段,不能用于“frontend”区段。当指定此语句时,统计报告将仅显示其列举出区段的报告信息,所有其它区段的信息将被隐藏。如果需要显示多个区段的统计报告,此语句可以定义多次。需要注意的是,区段名称检测仅仅是以字符串比较的方式进行,它不会真检测指定的区段是否真正存在。

<name>:可以是一个“listen”、“frontend”或“backend”区段的名称,而“.”则表示stats scope语句所定义的当前区段。

尽管“stats scope”一条就能够启用统计报告,但还是建议设定其它所有的参数,以免其依赖于默认设定而带来非期后果。下面是一个配置案例。

3.15 stats auth

启用带认证的统计报告功能并授权一个用户帐号,其不能用于“frontend”区段。

<user>:授权进行访问的用户名;

<passwd>:此用户的访问密码,明文格式;

此语句将基于默认设定启用统计报告功能,并仅允许其定义的用户访问,其也可以定义多次以授权多个用户帐号。可以结合“stats realm”参数在提示用户认证时给出一个领域说明信息。在使用非法用户访问统计功能时,其将会响应一个“401 Forbidden”页面。其认证方式为HTTP Basic认证,密码传输会以明文方式进行,因此,配置文件中也使用明文方式存储以说明其非保密信息故此不能相同于其它关键性帐号的密码。

尽管“stats auth”一条就能够启用统计报告,但还是建议设定其它所有的参数,以免其依赖于默认设定而带来非期后果。

3.16 stats admin

在指定的条件满足时启用统计报告页面的管理级别功能,它允许通过web接口启用或禁用服务器,不过,基于安全的角度考虑,统计报告页面应该尽可能为只读的。此外,如果启用了HAProxy的多进程模式,启用此管理级别将有可能导致异常行为。

目前来说,POST请求方法被限制于仅能使用缓冲区减去保留部分之外的空间,因此,服务器列表不能过长,否则,此请求将无法正常工作。因此,建议一次仅调整少数几个服务器。下面是两个案例,第一个限制了仅能在本机打开报告页面时启用管理级别功能,第二个定义了仅允许通过认证的用户使用管理级别功能。

3.17 option httplog

启用记录HTTP请求、会话状态和计时器的功能。

clf:使用CLF格式来代替HAProxy默认的HTTP格式,通常在使用仅支持CLF格式的特定日志分析器时才需要使用此格式。

默认情况下,日志输入格式非常简陋,因为其仅包括源地址、目标地址和实例名称,而“option httplog”参数将会使得日志格式变得丰富许多,其通常包括但不限于HTTP请求、连接计时器、会话状态、连接数、捕获的首部及cookie、“frontend”、“backend”及服务器名称,当然也包括源地址和端口号等。

3.18 option logasap

启用或禁用提前将HTTP请求记入日志,不能用于“backend”区段。

默认情况下,HTTP请求是在请求结束时进行记录以便能将其整体传输时长和字节数记入日志,由此,传较大的对象时,其记入日志的时长可能会略有延迟。“option logasap”参数能够在服务器发送complete首部时即时记录日志,只不过,此时将不记录整体传输时长和字节数。此情形下,捕获“Content-Length”响应首部来记录传输的字节数是一个较好选择。下面是一个例子。

3.19 option forwardfor

允许在发往服务器的请求首部中插入“X-Forwarded-For”首部。

<network>:可选参数,当指定时,源地址为匹配至此网络中的请求都禁用此功能。

<name>:可选参数,可使用一个自定义的首部,如“X-Client”来替代“X-Forwarded-For”。有些独特的web服务器的确需要用于一个独特的首部。

if-none:仅在此首部不存在时才将其添加至请求报文问道中。

HAProxy工作于反向代理模式,其发往服务器的请求中的客户端IP均为HAProxy主机的地址而非真正客户端的地址,这会使得服务器端的日志信息记录不了真正的请求来源,“X-Forwarded-For”首部则可用于解决此问题。HAProxy可以向每个发往服务器的请求上添加此首部,并以客户端IP为其value。

需要注意的是,HAProxy工作于隧道模式,其仅检查每一个连接的第一个请求,因此,仅第一个请求报文被附加此首部。如果想为每一个请求都附加此首部,请确保同时使用了“option httpclose”、“option forceclose”和“option http-server-close”几个option。

下面是一个例子。

3.20 errorfile

在用户请求不存在的页面时,返回一个页面文件给客户端而非由haproxy生成的错误代码;可用于所有段中。

<code>:指定对HTTP的哪些状态码返回指定的页面;这里可用的状态码有200、400、403、408、500、502、503和504;

<file>:指定用于响应的页面文件;

例如:

3.21 errorloc 和 errorloc302

请求错误时,返回一个HTTP重定向至某URL的信息;可用于所有配置段中。

<code>:指定对HTTP的哪些状态码返回指定的页面;这里可用的状态码有200、400、403、408、500、502、503和504;

<url>:Location首部中指定的页面位置的具体路径,可以是在当前服务器上的页面的相对路径,也可以使用绝对路径;需要注意的是,如果URI自身错误时产生某特定状态码信息的话,有可能会导致循环定向;

需要留意的是,这两个关键字都会返回302状态吗,这将使得客户端使用同样的HTTP方法获取指定的URL,对于非GET法的场景(如POST)来说会产生问题,因为返回客户的URL是不允许使用GET以外的其它方法的。如果的确有这种问题,可以使用errorloc303来返回303状态码给客户端。

3.22 errorloc303

请求错误时,返回一个HTTP重定向至某URL的信息给客户端;可用于所有配置段中。

<code>:指定对HTTP的哪些状态码返回指定的页面;这里可用的状态码有400、403、408、500、502、503和504;

<url>:Location首部中指定的页面位置的具体路径,可以是在当前服务器上的页面的相对路径,也可以使用绝对路径;需要注意的是,如果URI自身错误时产生某特定状态码信息的话,有可能会导致循环定向;

例如:

四、ACL

haproxy的ACL用于实现基于请求报文的首部、响应报文的内容或其它的环境状态信息来做出转发决策,这大大增强了其配置弹性。其配置法则通常分为两步,首先去定义ACL,即定义一个测试条件,而后在条件得到满足时执行某特定的动作,如阻止请求或转发至某特定的后端。定义ACL的语法格式如下。

<aclname>:ACL名称,区分字符大小写,且其只能包含大小写字母、数字、-(连接线)、_(下划线)、.(点号)和:(冒号);haproxy中,acl可以重名,这可以把多个测试条件定义为一个共同的acl;

<criterion>:测试标准,即对什么信息发起测试;测试方式可以由[flags]指定的标志进行调整;而有些测试标准也可以需要为其在之前指定一个操作符[operator];

[flags]:目前haproxy的acl支持的标志位有3个:

-i:不区分中模式字符的大小写;

-f:从指定的文件中加载模式;

--:标志符的强制结束标记,在模式中的字符串像标记符时使用;

<value>:acl测试条件支持的值有以下四类:

整数或整数范围:如1024:65535表示从1024至65535;仅支持使用正整数(如果出现类似小数的标识,其为通常为版本测试),且支持使用的操作符有5个,分别为eq、ge、gt、le和lt;

字符串:支持使用“-i”以忽略字符大小写,支持使用“\”进行转义;如果在模式首部出现了-i,可以在其之前使用“–”标志位;

正则表达式:其机制类同字符串匹配;

IP地址及网络地址;

同一个acl中可以指定多个测试条件,这些测试条件需要由逻辑操作符指定其关系。条件间的组合测试关系有三种:“与”(默认即为与操作)、“或”(使用“||”操作符)以及“非”(使用“!”操作符)。

5.1 常用的测试标准(criteria)

5.1.1 be_sess_rate

用于测试指定的backend上会话创建的速率(即每秒创建的会话数)是否满足指定的条件;常用于在指定backend上的会话速率过高时将用户请求转发至另外的backend,或用于阻止攻击行为。例如:

5.1.2 fe_sess_rate

用于测试指定的frontend(或当前frontend)上的会话创建速率是否满足指定的条件;常用于为frontend指定一个合理的会话创建速率的上限以防止服务被滥用。例如下面的例子限定入站邮件速率不能大于50封/秒,所有在此指定范围之外的请求都将被延时50毫秒。

5.1.3 hdr <string>

用于测试请求报文中的所有首部或指定首部是否满足指定的条件;指定首部时,其名称不区分大小写,且在括号“()”中不能有任何多余的空白字符。测试服务器端的响应报文时可以使用shdr()。例如下面的例子用于测试首部Connection的值是否为close。

5.1.4 method <string>

测试HTTP请求报文中使用的方法。

5.1.5 path_beg <string>

用于测试请求的URL是否以指定的模式开头。下面的例子用于测试URL是否以/static、/images、/javascript或/stylesheets头。

5.1.6 path_end <string>

用于测试请求的URL是否以<string>指定的模式结尾。例如,下面的例子用户测试URL是否以jpg、gif、png、css或js结尾。

5.1.7 hdr_beg <string>

用于测试请求报文的指定首部的开头部分是否符合<string>指定的模式。例如,下面的例子用记测试请求是否为提供静态内容的主机img、video、download或ftp。

5.1.8 hdr_end <string>

用于测试请求报文的指定首部的结尾部分是否符合<string>指定的模式。

五、配置案例

前端调度器IP:192.168.1.210
后端应用服务器IP: 192.168.1.111 和 192.168.1.112

定义独立日志文件

一个最简单的http服务的配置

 

haproxy统计页面的输出机制

 

动静分离示例: