一.HAProxy基础配置与应用实例:

1.快速安装HAProxy集群软件:

HAProxy的官网:HAProxy详解(二):HAProxy基础配置与应用实例_配置文件 ​​​https://www.haproxy.org/#down下载HAProxy的源码包。​

安装:

[root@data-1-1 ~]# tar zxvf haproxy-1.4.24.tar.gz

[root@data-1-1 ~]# cd haproxy-1.4.24

查看haproxy的安装文件

[root@data-1-1 haproxy-1.4.24]# more README

[root@data-1-1 haproxy-1.4.24]# make TARGET=linux2628 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安装路径

[root@data-1-1 haproxy-1.4.24]# make install PREFIX=/usr/local/haproxy

#将HAProxy安装到/usr/local/haproxy 下

[root@data-1-1 haproxy-1.4.24]# mkdir /usr/local/haproxy/conf

#HAProxy默认不创建配置文件目录,这里是创建HAProxy配置文件目录

[root@data-1-1 haproxy-1.4.24]# cp examples/haproxy.cfg /usr/local/haproxy/conf/

#HAProxy安装完成后,默认安装目录中没有配置文件,这里是将源码包里面的示例配置文件复制到配置文件目录。

2.HAProxy基础配置文件详解:

1.配置文件概述:

根据功能和用途,HAProxy配置文件主要由5个部分组成,但有些部分并不是必需的,可以根据需要选择相应的部分进行配置。

(1)global部分

用来设定全局配置参数,属于进程级的配置,通常和操作系统配置有关。

(2)defaults部分

默认参数的配置部分。在此部分设置的参数值,默认会自动引用到下面的frontend、backend和listen部分中,因此,如果某些参数属于共用配置,只需在defaults部分添加一次即可。而如果在frontend、backend和listen部分中也配置了与defaults部分一样的参数,那么defaults部分参数对应的值自动被覆盖。

(3)frontend部分

此部分用于设置接收用户请求的前端虚拟节点。frontend是在HAProxy1.3版本之后才引入的一个组件,同时引入的还有backend组件。通过引入这些组件,在很大程度上简化了HAProxy配置文件的复杂性。frontend可以根据ACL规则直接指定要使用的后端backend。

(4)backend部分

此部分用于设置集群后端服务集群的配置,也就是用来添加一组真实服务器,以处理前端用户的请求。添加的真实服务器类似于LVS中的real server节点。

(5)listen部分

此部分是frontend部分和backend部分的结合体。在HAProxy1.3版本之前,HAProxy的所有配置选项都在这个部分中设置。为了保持兼容性,HAProxy新的版本仍然保留了listen组件的配置方式。目前在HAProxy中,两种配置方式任选其一即可。

2.HAProxy配置文件详解:

根据上面介绍的5个部分对HAProxy的配置文件进行说明:

(1)global部分

配置示例如下:

global

log 127.0.0.1 local0 info

maxconn 4096

user nobody

group nobody

daemon

nbproc 1

pidfile /usr/local/haproxy/logs/haproxy.pid

每个选项的含义:

□ log : 全局的日志配置,local0是日志设备,info表示日志级别。其中日志级别有err、warning、info、debug4种可选。这个配置表示使用127.0.0.1上的rsyslog服务中的local0日志设备,记录日志等级为info。

■ maxconn : 设定每个HAProxy进程可接受的最大并发连接数,此选项等同于Linux命令行选项“ulimit -n”。

□ user/group : 设置HAProxy进程的用户和组,也可使用用户和组的uid和gid值来替代。

■ daemon : 设置HAProxy进程进入后台运行。这是推荐的运行模式。

□ nbproc : 设置HAProxy启动时可创建的进程数,此参数要求将HAProxy运行模式设置为daemon,默认只启动一个进程。根据使用经验,该值的设置应该小于服务器的CPU核数。创建多个进程,能够减少每个进程的任务队列,但是过多的进程可能会导致进程崩溃。

■ pidfile : 指定HAProxy进程的pid文件。启动进程的用户必须有访问此文件的权限。

(2)defaults部分

配置示例如下:

defaults

mode http

retries 3

timeout connect 10s

timeout client 20s

timeout server 30s

timeout check 5s

每个选项的含义:

□ mode : 设置HAProxy实例默认的运行模式,有tcp、http、health三个可选值。

☆ tcp模式 :在此模式下,客户端和服务器端之间将建立一个全双工的连接,不会对七层报文做任何类型的检查,默认为tcp模式,经常用于SSL、SSH、SMTP等应用。

★ http模式:在此模式下,客户端请求在转发至后端服务器之前将会被深度分析,所有不与RFC格式兼容的请求都会被拒绝。

☆ health模式:目前此模式基本已经废弃,不再多说。

■ retries:设置连接后服务器的失败重试次数,如果连接失败的次数超过这里设置的值,HAProxy会将对应的后端服务器标记为不可用。此参数也可在后面部分进行设置。

□ timeout connect:设置成功连接到一台服务器的最长等待时间,默认单位是毫秒,也可以使用其他的时间单位后缀。

■ timeout client:设置连接客户端发送数据时最长等待时间,默认单位是毫秒,也可以使用其他的时间单位后缀。

□ timeout server:设置服务器端回应客户端数据发送的最长等待时间,默认单位是毫秒,也可以使用其他的时间单位后缀。

■ timeout check:设置对后端服务器的检测超时时间,默认单位是毫秒,也可以使用其他的时间单位后缀。

(3) frontend 部分

配置示例如下:

frontend www

bind *:80

mode http

option httplog

option forwardfor

option httpclose

log global

default_backend htmpool

这部分通过frontend关键字定义了一个名为“www”的前端虚拟节点,上述代码中每个选项的含义如下:

□ bind:此选项只能在frontend和listen部分进行定义,用于定义一个或几个监听的套接字。bind的使用格式为:

bind [<address>:<port_range>] interface <interface>

其中,address为可选选项,其可以为主机名或IP地址,如果将其设置为“*”或“0.0.0.0”,将监听当前系统的所有IPv4地址。port_range可以是一个特定的TCP端口,也可是一个端口范围,小于1024的端口需要有特定权限的用户才能使用。interface为可选选项,用来指定网络接口的名称,只能在Linux系统上使用。

■ option httplog:在默认情况下,HAProxy日志是不记录HTTP请求的,这样很不方便HAProxy问题的排查与监控。通过此选项可以启用日志记录HTTP请求。

□ option forwardfor:如果后端服务器需要获得客户端的真实IP,就需要配置此参数。由于HAProxy工作于方向代理模式,因此发往后端真实服务器的请求中的客户端IP均为HAProxy主机的IP,而非真正访问客户端的地址,这就导致真实服务器端无法记录客户端真正请求来源的IP,而X-Forwarded-For则可用于解决此问题。通过使用forwardfor选项,HAProxy就可以向每个发往后端真实服务器的请求添加X-Forwarded-For记录,这样后端真实服务器日志可以通过“X-Forwarded-For”信息来记录客户端来源IP。

■ option httpclose:此选项表示在客户端和服务器端完成一次连接请求后,HAProxy将主动关闭此TCP连接。这是对性能非常有帮助的一个参数。

□ log global:表示使用全局的日志配置,这里的global表示引用在HAProxy配置文件global部分中定义的log选项配置格式。

■ default_backend :指定默认的后端服务器池,也就是指定一组后端真实服务器,而这些真实服务器组将在backend段进行定义。这里的htmpool就是一个后端服务器组。

(4)backend部分

配置示例如下:

backend htmpool

mode http

option redispatch

option abortonclose

balance roundrobin

cookie SERVERID

option httpchk GET /index.php

server web1 10.200.34.181:80 cookie server1 weight 6 check inter 2000 rise 2 fall 3

server web1 10.200.34.182:80 cookie server2 weight 6 check inter 2000 rise 2 fall 3

这部分通过backend关键字定义了一个名为htmpool的后端真实服务器组。选项含义如下:

□ option redispatch:此参数用于cookie保持的环境中。在默认情况下,HAProxy会将其请求的后端服务器的serverID插入cookie中,以保证会话的session持久性。而如果后端的服务器出现故障,客户端的cookie是不会刷新的,这就会出现问题。此时,如果设置此参数,就会将客户端的请求强制定向到另外一台健康的后端服务器上,以保证服务正常。

■ option abortonclose:如果设置了此参数,可以在服务器负载很高的情况下,自动结束当前队列中处理时间比较长的连接。

□ balance roundrobin:此关键字用来定义负载均衡算法。目前HAProxy支持多种负载均衡算法,常用的有如下几种:

☆ roundrobin:是基于权重进行轮叫调度的算法,在服务器的性能分布比较均匀时,这是一种最公平、最合理的算法。此算法使用频繁。

★ static-rr:也是基于权重进行轮叫的调度算法,不过此算法为静态方法,在运行时调整其服务器权重不会失效。

☆ source:是基于请求源IP的算法。此算法先对请求的源IP进行hash运算,然后将结果与后端服务器的权重总数相除后转发至某台匹配的后端服务器。这种方式可以使同一个客户端IP的请求始终被转发到某特定的后端服务器。

★ leastconn:此算法会将新的连接请求转发到具有最少连接数目的后端服务器。在会话时间较长的场景中推荐使用此算法,例如数据库负载均衡等。此算法不适合会话较短的环境中,例如基于HTTP的应用。

☆ uri_param:此算法会对根据URL路径中的参数进行转发,这样可保证在后端真实服务器数量不变时,同一个用户的请求始终分发到同一台机器上。

★ uri:此算法会对部分或整个URL进行hash运算,再经过与服务器的总权重相除,最后转发到某台匹配的后端服务器上。

☆ hdr(<name>):此算法根据http头进行转发,如果指定的http头名称不存在,则使用roundrobin算法进行策略转发。

■ cookie:表示允许向cookie插入SERVERID,每台服务器的SETVERID可在下面的server关键字中使用cookie关键字定义。

□ option httpchk:此选项表示启用HTTP的服务状态检测功能。HAProxy作为一个专业的负载均衡器,它支持对backend部分指定的后端服务节点的健康检查,以保证在后端backend中某个节点不能服务时,把从frotend端进来的客户端请求分配至backend中其他健康节点上,从而保证整体服务的可用性。option httpchk的用法如下:

option httpchk <method> <uri> <version>

参数含义:

method:表示HTTP请求的方式,常用的有OPTIONS、GET、HEAD几种方式。一般的健康检查可以采用HEAD方式进行,而不是采用GET方式,这是因为HEAD方式没有数据返回,仅检查Response的HEAD是不是状态码200。因此,相对于GET,HEAD方式更快、更简单。

uri:表示要检测的URL地址,通过执行此URL,可以获取后端服务器的运行状态。在正常情况下将返回状态码200,返回其他状态码均为异常状态。

version:指定心跳检测时的HTTP的版本号。

■ server:这个关键字用来定义多台后端真实服务器,不能用于defaults和frontend部分。使用格式为:

server <name> <address> [:port] [param*]

参数含义:

☆ <name>:为后端真实服务器指定一个内部名称,随便定义一个即可。

★ <address>:后端真实服务器的IP地址或主机名。

☆ <port>:指定连接请求发往真实服务器时的目标端口。在未设定时,将使用客户端请求时的同一端口。

★ [param*]:为后端服务器设定的一系列参数,可用参数非常多,常用参数如下:

▷ check:表示启用对此后端服务器执行健康状态检查。

▶ inter:设置健康状态检查的时间间隔,单位为毫秒。

▷ rise:设置从故障状态转换至正常状态需要成功检查的次数,例如,“rise2”表示2次检查正常就认为此服务器可用。

▶ fall:设置后端服务器从正常状态转换为不可用状态需要检查的次数,例如,“fall3”表示3此检查失败就认为此服务器不可用。

▷ cookie:为指定的后端服务器设定cookie值,此处指定的值将在请求入站时被检查,第一次为此值挑选的后端服务器将在后续的请求中一直被选中,其目的在于实现持久连接的功能。上面的“cookie server1”表示web1的serverid为server1。同理,“cookie server2”表示web2的serverid为server2。

▶ weight:设置后端真实服务器的权重,默认为1,最大值为256。设置为0表示不参与负载均衡。

▷ backup:设置后端真实服务器的备份服务器,仅仅在后端所有真实服务器均不可用的情况下才启用。

(5)listen部分

配置示例:

listen admin_stats

bind 0.0.0.0:9188

mode http

log 127.0.0.1 local0 err

stats refresh 30s

stats uri /haproxy-status

stats realm welcome login\ Haproxy

stats auth admin:admin

stats hide-version

stats admin if TRUE

这个部分通过listen关键字定义一个名为“admin_status”的实例,每个选项的含义如下:

□ stats refresh:设置HAProxy监控统计页面自动刷新的时间。

■ stats uri:设置HAProxy监控统计页面的URL路径,可随意指定。例如,指定“status uri /haproxy-status”,就可以通过​​http://IP:9188/haproxy-status查看。​

□ stats realm:设置登录HAProxy统计页面时密码框上的文本提示信息。

■ stats auth:设置登录HAProxy统计页面的用户名和密码。用户名和密码通过冒号分割。可为监控页面设置多个用户名和密码,每行一个。

□ stats hide-version:用来隐藏统计页面上HAProxy的版本信息。

■ stats admin if TRUE:通过设置此选项,可以在监控页面上手工启用或禁用后端真实服务器,仅在haproxy1.4.9以后版本有效。

3.HAProxy的日志配置策略:

默认情况下 ,HAProxy为了节省读写I/O所消耗的性能,没有自动配置日志输出功能,但是为了维护和调试方便,日志的输出还是很有必要的,下面就简单介绍如何配置HAProxy的日志输出功能。

查看是否安装rsyslog:

[root@data-1-1 ~]# rpm -q rsyslog

rsyslog-5.8.10-10.el6_6.x86_64

如果已经安装了rsyslog软件包,接着需要修改rsyslog的配置文件,在/etc/rsyslog.d/目录下创建haproxy.conf文件,内容如下:

[root@data-1-1 ~]# vim /etc/rsyslog.d/haproxy.conf

$ModLoad imudp

$UDPServerRun 514

local3.* /usr/local/haproxy/logs/haproxy.log

local0.* /usr/local/haproxy/logs/haproxy.log

这里定义了两种日志类型,并指定了日志的输出路径,其中:

第一行的“imudp”是模块名,支持UDP协议。

第二行表示允许514端口接收使用UDP和TCP协议转发过来的日志,而rsyslog在默认情况下,正是在514端口监听UDP。其实也可以将上面haproxy.conf文件的内容直接写到/etc/rsyslog.conf文件中。

然后,还需要修改/etc/sysconfig/rsyslog文件,修改为如下内容:

SYSLOGD_OPTIONS="-c 5 -r -m 0"

其中,“-r”表示接收远程日志。

最后重启rsyslog服务即可完成配置:

[root@data-1-1 ~]# service rsyslog restart

要实现将HAProxy日志写入指定的文件中,还需要在haproxy.cfg中配置对应的日志选项。

4.通过HAProxy的ACL规则实现智能负载均衡:

由于HAProxy可以工作在七层模型下,因此,要实现HAProxy的强大功能,一定要使用强大灵活的ACL规则,通过ACL规则可以实现基于HAProxy的智能负载均衡系统。HAProxy通过ACL规则完成两种主要的功能,分别是:

1)通过设置的ACL规则检查客户端请求是否合法。如果符合ACL规则要求,那么将放行;如果不符合规则,则直接中断请求。

2)符合ACL规则要求的请求将被提交到后端的backend服务器集群,进而实现基于ACL规则的负载均衡。

HAProxy中的ACL规则经常使用在frontend段中,使用方法如下:

acl 自定义的acl名称 acl方法 -i [ 匹配的路径或文件 ]

其中:

□ acl:是一个关键字,表示定义ACL规则的开始。后面需要跟上自定义的ACL名称。

■ acl方法:这个字段用来定义实现ACL的方法,HAProxy定义了很多ACL方法,经常使用的方法有hdr_reg(host)、hdr_dom(host)、hdr_beg(host)、url_sub、url_dir、path_beg、path_end等。

□ -i:表示不区分大小写,后面需要跟上匹配的路径或文件或正则表达式。

与ACL规则一起使用的HAProxy参数还有use_backend,use_backend后面需要跟上一个backend实例名,表示在满足ACL规则后去请求哪个backend实例,与use_backend对应的还有default_backend参数,它表示在没有满足ACl条件的时候默认使用哪个后端backend.

例:

acl www_policy hdr_reg(host) -i ^(​​www.z.cn|z.cn)​

acl bbs_policy hdr_dom(host) -i bbs.z.cn

acl url_policy url_sub -i buy_sid=


use_backend server_www if www_policy

use_backend server_app if url_policy

use_backend server_bbs if bbs_policy

default_backend server_cache

这里仅仅列出了HAProxy配置文件中ACL规则的配置部分,其他选项并未列出。

这些例子定义了www_policy、bbs_policy、url_policy三个ACL规则,第一条规则表示如果客户端以​​www.z.cn或z.cn开头的域名发送请求时,则此规则返回true,同理第二条规则表示如果客户端通过bbs.z.cn域名发送请求时,则此规则返回true,而第三条规则表示如果客户端在请求的URL中包含“buy_sid=”字符串时,则此规则返回ture。​

第四、第五、第六条规则定义了当www_policy、bbs_policy、url_policy三个ACL规则返回true时要调度到哪个后端backend,例如,当用户的请求满足www_policy规则时,那么HAProxy会将用户的请求直接发往名为server_www的后端backend,其他以此类推。而当用户的请求不满足任何一个ACL规则时,HAProxy就会把请求发往由default_backend选项指定的server_cache这个后端backend。

例子:

acl url_static path_end .gif .png .jpg .css .js

acl host_www hdr_beg(host) -i www

acl host_static har-beg(host) -i img. video. download. ftp.


use_backend static if host_static || host_www url_static

use_backend www if host_www

default_backend server_cache

与上面的例子类似,本例中也定义了url_static、host_www和host_static三个ACL规则,其中,第一条规则通过path_end参数定义了如果客户端在请求的URL中以.gif、.png、.jpg、.css或.js结尾是返回true,第二条规则通过hdr_beg(host)参数定义了如果客户端以www开头的域名发送请求时则返回true,同理,第三条规则也是通过hdr_beg(host)参数定义了如果客户端以img.、video.、download.或ftp.开头的域名发送请求时则返回true。

第四、第五条规则定义了当满足ACL规则后要调度到哪个后端backend,例如,当用户的请求同时满足host_static规则与url_static规则,或同时满足host_www和url_static规则时,那么会将用户请求直接发往名为static的后端backend,如果用户请求满足host_www规则,那么请求将被调度到名为www的后端backend,如果不满足所有规则,那么将用户请求默认调度到名为server_cache的这个后端backend

转自

HAProxy详解(二)-闫利朋的博客-51CTO博客

http://blog.51cto.com/6284444/2136805