HAProxy主要提供两个功能:http协议反向代理(不提供缓存功能)、基于tcp层的负载均衡(如https、mysql协议)。适用于需要会话保持或七层处理的且负载特别大的站点。可支持数以万计的并发连接。说到haproxy就不得不说与其相关的配置文件了,下面就让我们一起来了解haproxy配置语法。
一. haproxy配置文件详解
haproxy配置分为五部分,分别如下:
1 global: (全局配置主要用于设定义全局参数,属于进程级的配置,通常和操作系统配置有关)
2 default : (配置默认参数,这些参数可以被用到frontend,backend,Listen组件)
在此部分中设置的参数值,默认会自动引用到下面的frontend、backend、listen部分中,因引,某些参数属于公用的配置,只需要在defaults部分添加一次即可。而如果frontend、backend、listen部分也配置了与defaults部分一样的参数,Defaults部分参数对应的值自动被覆盖。
3 frontend:( 接收请求的前端虚拟节点,Frontend可以更加规则直接指定具体使用后端的backend)
frontend是在haproxy 1.3版本以后才引入的一个组件,同时引入的还有backend组件。通过引入这些组件,在很大程度上简化了haproxy配置文件的复杂性。forntend可以根据ACL规则直接指定要使用的后端backend。
4 backend : (后端服务集群的配置,真实服务器,一个Backend对应一个或者多个实体服务器)
在HAProxy1.3版本之前,HAProxy的所有配置选项都在这个部分中设置。为了保持兼容性,haproxy新的版本依然保留了listen组件配置试。两种配置方式任选一中。
5 Listen : (Fronted和backend的组合体) 比如haproxy实例状态监控部分配置
代理配置段:
1. Backend:后端服务器组的定义
2. Frontend:定义面向客户的监听的地址和端口,以及关联的后端的服务器组
3. Listen:组合的方式直接定义frontend及相关的backend
4. Defaults:默认的配置
关于haproxy时间格式配置说明
一些包含了值的参数表示时间,如超时时长。这些值一般以毫秒为单位,但也可以使用其它的时间单位后缀。
us: 微秒(microseconds),即1/1000000秒;
ms: 毫秒(milliseconds),即1/1000秒;
s: 秒(seconds);
m: 分钟(minutes);
h:小时(hours);
d: 天(days);
1.1 haproxy global部分配置说明
通常主要定义全局配置主要用于设定义全局参数,属于进程级的配置,通常和操作系统配置有关
global
log 127.0.0.1 local3 #定义haproxy日志输出设置
log 127.0.0.1 local1 notice
#log loghost local0 info #定义haproxy 日志级别
ulimit-n 82000 #设置每个进程的可用的最大文件描述符
maxconn 20480 #默认最大连接数
chroot /usr/local/haproxy #chroot运行路径
uid 99 #运行haproxy 用户 UID
gid 99 #运行haproxy 用户组gid
daemon #以后台形式运行harpoxy
nbproc 1 #设置进程数量
pidfile /usr/local/haproxy/run/haproxy.pid #haproxy 进程PID文件
#debug #haproxy调试级别,建议只在开启单进程的时候调试
#quiet
log:全局的日志配置,local0是日志输出设置,info表示日志级别(err,waning,info,debug);
maxconn:设定每个HAProxy进程可接受的最大并发连接数,此选项等同于linux命令选项”ulimit -n”
chroot :修改haproxy的工作目录至指定的目录并在放弃权限之前执行chroot()操作,可以提升haproxy的安全级别,不过需要注意的是要确保指定的目录为空目录且任何用户均不能有写权限;
daemon:让haproxy以守护进程的方式工作于后台,其等同于“-D”选项的功能,当然,也可以在命令行中以“-db”选项将其禁用;
nbproc :指定启动的haproxy进程个数,只能用于守护进程模式的haproxy;默认只启动一个进程,鉴于调试困难等多方面的原因,一般只在单进程仅能打开少数文件描述符的场景中才使用多进程模式;
pidfile:将haproxy的进程写入pid文件。
ulimit-n:设定每进程所能够打开的最大文件描述符数目,默认情况下其会自动进行计算,因此不推荐修改此选项。
stats socket <path>定义统计信息保存位置。
如要设置haproxy的日志内容,可参考以下配置
capture request header Host len 40
capture request header Content-Length len 10
capture request header Referer len 200
capture response header Server len 40
capture response header Content-Length len 10
capture response header Cache-Control len 8
1.2 haproxy global部分配置说明
用于设置配置默认参数,这些参数可以被用到frontend,backend,Listen组件;
此部分中设置的参数值,默认会自动引用到下面的frontend、backend、listen部分中,因引,某些参数属于公用的配置,只需要在 defaults部分添加一次即可。而如果frontend、backend、listen部分也配置了与defaults部分一样的参 数,Defaults部分参数对应的值自动被覆盖
defaults
log global #引入global定义的日志格式
mode http #所处理的类别(7层代理http,4层代理tcp)
maxconn 50000 #最大连接数
option httplog #日志类别为http日志格式
option httpclose #每次请求完毕后主动关闭http通道
option dontlognull #不记录健康检查日志信息
option forwardfor #如果后端服务器需要获得客户端的真实ip,需要配置的参数,
可以从http header 中获取客户端的IP
retries 3 #3次连接失败就认为服务器不可用,也可以通过后面设置
option redispatch
#《---上述选项意思是指serverID 对应的服务器挂掉后,强制定向到其他健康的服务器, 当使用了 cookie时,
haproxy将会将其请求的后端服务器的serverID插入到cookie中,以保证会话的SESSION持久性;而此时,如果
后端的服务器宕掉了,但是客户端的cookie是不会刷新的,如果设置此参数,将会将客户的请求强制定向到另外一个
后端server上,以保证服务的正常---》
stats refresh 30 #设置统计页面刷新时间间隔
option abortonclose #当服务器负载很高的时候,自动结束掉当前队列处理比较久的连接
balance roundrobin #设置默认负载均衡方式,轮询方式
#balance source #设置默认负载均衡方式,类似于nginx的ip_hash
#contimeout 5000 #设置连接超时时间
#clitimeout 50000 #设置客户端超时时间
#srvtimeout 50000 #设置服务器超时时间
timeout http-request 10s #默认http请求超时时间
timeout queue 1m #默认队列超时时间
timeout connect 10s #默认连接超时时间
timeout client 1m #默认客户端超时时间
timeout server 1m #默认服务器超时时间
timeout http-keep-alive 10s #默认持久连接超时时间
timeout check 10s #设置心跳检查超时时间
mode http
设置haproxy的运行模式,有三种{http|tcp|health}。注意:如果haproxy中还要使用4层的应用(mode tcp)的话,不建议在此定义haproxy的运行模式。
设置HAProxy实例默认的运行模式有tcp、http、health三种可选:
tcp模式:在此模式下,客户端和服务器端之前将建立一个全双工的连接,不会对七层报文做任何检查,默认为tcp模式,经常用于SSL、SSH、SMTP等应用。
http模式:在此模式下,客户端请求在转发至后端服务器之前将会被深度分板,所有不与RFC格式兼容的请求都会被拒绝。
health:已基本不用了。
log global
设置日志继承全局配置段的设置。
option httplog
表示开始打开记录http请求的日志功能。
option dontlognull
如果产生了一个空连接,那这个空连接的日志将不会记录。
option http-server-close
打开http协议中服务器端关闭功能,使得支持长连接,使得会话可以被重用,使得每一个日志记录都会被记录。
option forwardfor except 127.0.0.0/8
如果上游服务器上的应用程序想记录客户端的真实IP地址,haproxy会把客户端的IP信息发送给上游服务器,在HTTP请求中添加”X-Forwarded-For”字段,但当是haproxy自身的健康检测机制去访问上游服务器时是不应该把这样的访问日志记录到日志中的,所以用except来排除127.0.0.0,即haproxy身。
option redispatch
当与上游服务器的会话失败(服务器故障或其他原因)时,把会话重新分发到其他健康的服务器上,当原来故障的服务器恢复时,会话又被定向到已恢复的服务器上。还可以用”retries”关键字来设定在判定会话失败时的尝试连接的次数。
retries 3
向上游服务器尝试连接的最大次数,超过此值就认为后端服务器不可用。
option abortonclose
当haproxy负载很高时,自动结束掉当前队列处理比较久的链接。
timout http-request 10s
客户端发送http请求的超时时间。
timeout queue 1m
当上游服务器在高负载响应haproxy时,会把haproxy发送来的请求放进一个队列中,timeout queue定义放入这个队列的超时时间。
timeout connect 5s
haproxy与后端服务器连接超时时间,如果在同一个局域网可设置较小的时间。
timeout client 1m
定义客户端与haproxy连接后,数据传输完毕,不再有数据传输,即非活动连接的超时时间。
timeout server 1m
定义haproxy与上游服务器非活动连接的超时时间。
timeout http-keep-alive 10s
设置新的http请求连接建立的最大超时时间,时间较短时可以尽快释放出资源,节约资源。
timeout check 10s
健康检测的时间的最大超时时间。
maxconn 3000
最大并发连接数。
contimeout 5000
设置成功连接到一台服务器的最长等待时间,默认单位是毫秒,新版本的haproxy使用timeout connect替代,该参数向后兼容。
clitimeout 3000
设置连接客户端发送数据时的成功连接最长等待时间,默认单位是毫秒,新版本haproxy使用timeout client替代。该参数向后兼容。
srvtimeout 3000
设置服务器端回应客户度数据发送的最长等待时间,默认单位是毫秒,新版本haproxy使用timeout server替代。该参数向后兼容。
balance roundrobin
设置负载算法为:轮询算法rr
balance :用来定义负载均衡算法
1.roundrobin:基于权重进行的轮叫算法,在服务器的性能分布经较均匀时这是一种最公平的,最合量的算法。
2.static-rr:也是基于权重时行轮叫的算法,不过此算法为静态方法,在运行时调整其服务权重不会生效。
3.source:是基于请求源IP的算法,此算法对请求的源IP时行hash运算,然后将结果与后端服务器的权理总数相除后转发至某台匹配的后端服务器,这种方法可以使用一个客户端IP的请求始终转发到特定的后端服务器。
4.leastconn:此算法会将新的连接请求转发到具有最少连接数目的后端服务器。在会话时间较长的场景中推荐使用此算法。例如数据库负载均衡等。此算法不适合会话较短的环境,如基于http的应用。
5.uri:此算法会对部分或整个URI进行hash运算,再经过与服务器的总权重要除,最后转发到某台匹配的后端服务器上。
6.uri_param:此算法会椐据URL路径中的参数时行转发,这样可以保证在后端真实服务器数量不变时,同一个用户的请求始终分发到同一台机器上。
7.hdr:此算法根据httpd头时行转发,如果指定的httpd头名称不存在,则使用roundrobin算法进行策略转发。
8.rdp-cookie(name):示根据据cookie(name)来锁定并哈希每一次TCP请求。
1.3 haproxy frontend 部分配置说明
frontend是在haproxy 1.3版本以后才引入的一个组件,同时引入的还有backend组件。通过引入这些组件,在很大程度上简化了haproxy配置文件的复杂性。frontend根据任意 HTTP请求头内容做ACL规则匹配,然后把请求定向到相关的backend
frontend http_80_in
bind 0.0.0.0:80 #设置监听端口,即haproxy提供的web服务端口,和lvs的vip 类似
mode http #http 的7层模式
log global #应用全局的日志设置
option httplog #启用http的log
option httpclose #每次请求完毕后主动关闭http通道,HAproxy不支持keep-alive模式
option forwardfor #如果后端服务器需要获得客户端的真实IP需要配置此参数,将可以从
HttpHeader中获得客户端IP
default_backend wwwpool #设置请求默认转发的后端服务池,
frontend http_80_in
定义一个名为http_80_in的frontend。
bind 0.0.0.0:80
定义haproxy前端部分监听的端口。
mode http
定义为http模式。
log global
继承global中log的定义。
option forwardfor
使后端server获取到客户端的真实IP。
1.4 haproxy backend 部分配置说明
用来定义后端服务集群的配置,真实服务器,一个Backend对应一个或者多个实体服务器
backend wwwpool #定义wwwpool服务器组。
mode http #http的7层模式
option redispatch
option abortonclose
balance source #负载均衡的方式,源哈希算法
cookie SERVERID #允许插入serverid到cookie中,serverid后面可以定义
option httpchk GET /test.html #心跳检测
server web1 10.1.1.2:80 cookie 2 weight 3 check inter 2000 rise 2 fall 3 maxconn 8
cookie:表示充许向cookie插入SERVERID,每台服务器的SERVERID可以下面的server关键字中使用cookie关键字定义。
option httpchk:此选项表示启用HTTP的服务状态检测功能。 HAProxy作为一个专业的负载均衡器,并且它支持对backend部分指定的后端服务节点的 健康检查,以保证在后端的backend中某个节点不能服务时,把从frontend端进来的客户端请求分配至backend中其他健康节点上,从而保证 整体服务的可用性。
option httpchk用法:
option httpchk
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:设置人故障状态转换至正常状态需要成功检查的次数,如 rise 2:表示2次检查正确就认为此服务器可用。
fall:设置后端服务器从正常状态转换为不可用状态需要检查的次数,如 fall 3表示3 次检查失败就认为此服务器不可用。
cookie:为指定的后端服务器设定cookie值,此外指定的值将在请求入站时被检查,第一次为此值挑选的后端服务器将在后续的请求中一直被选中,其目的在于实现持久连接的功能。
cookie server1:表示web1的serverid为server1。
weigth:设置后端真实服务器的权重,默认为1,最大值为256,设置为0表示不参与负载均衡。
maxconn:设定每个backend中server进程可接受的最大并发连接数,此选项等同于linux命令选项”ulimit -n”
backup:设置后端真实服务器的备份服器,仅仅在后端所有真实服务器均不可用的情况下才启用。
1.5 haproxy listen 部分配置说明
常常用于状态页面监控,以及后端server检查,是Fronted和backend的组合体
如下为haproxy访问状态监控页面配置
listen admin_status #Frontend和Backend的组合体,监控组的名称,按需自定义名称
bind 0.0.0.0:8888 #监听端口
mode http #http的7层模式
log 127.0.0.1 local3 err #错误日志记录
stats refresh 5s #每隔5秒自动刷新监控页面
stats uri /admin?stats #监控页面的url访问路径
stats realm itnihao welcome #监控页面的提示信息
stats auth admin:admin #监控页面的用户和密码admin,可以设置多个用户名
stats auth admin1:admin1 #监控页面的用户和密码admin1
stats hide-version #隐藏统计页面上的HAproxy版本信息
stats admin if TRUE #手工启用/禁用,后端服务器(haproxy-1.4.9以后版本)
总结:代理配置段主要有以下几部分配置块:1. Frontend:定义面向客户的监听的地址和端口,以及关联的后端的服务器组 ;2. Backend:后端服务器组的定义;3. Listen:组合的方式直接定义frontend及相关的backend;4. Defaults:默认的配置。其中listen配置块可以直接使用frontend和backend中任意一项参数配置, 比如acl语法配置以及server语法配置参数。
上一小节的从haproxy的配置文件我们知道haproxy相关参数基本介绍,但是在实际生产环境中,往往需要根据相关规则做请求匹配跳转,这时就需要用到Frontend;Backend这两个配置段,再结合Frontend的acl匹配规则来做相应的客户端请求跳转;另外,可能还会遇到客户端访问出错,这时就需要利用错误重定向功能,将其定义到相关友情提示的错误页面上,这样更加人性化。
一. Frontend匹配规则ACL用法详解
haproxy ACL具有很强大的功能,能够定义三到七层的规则。ACL的作用,就是为了匹配一些特别的请求,然后对其进行修改或者分发到不同的服务器组中
①haproxy acl定义
格式: acl <aclname> <criterion> [flags] [operator] [<value>]
<aclname>:ACL名称,区分字符大小写,且其只能包含大小写字母、数字、-(连接线)、_(下划线)、.(点号)和:(冒号);haproxy中,acl可以重名,这可以把多个测试条件定义为一个共同的acl;
<criterion>:测试标准,即对什么信息发起测试;测试方式可以由[flags]指定的标志进行调整;而有些测试标准也可以需要为其在<value>之前指定一个操作符[operator];
[flags]:目前haproxy的acl支持的标志位有3个:
-i:不区分中模式字符的大小写;
-f:从指定的文件中加载模式;
–:标志符的强制结束标记,在模式中的字符串像标记符时使用;
<value>:acl测试条件支持的值有以下四类:
1. 整数或整数范围:如1024:65535表示从1024至65535;仅支持使用正整数(如果出现类似小数的标识,其为通常为版本测试),且支持使用的操作符有5个,分别为eq、ge、gt、le和lt;
2. 字符串:支持使用“-i”以忽略字符大小写,支持使用“”进行转义;如果在模式首部出现了-i,可以在其之前使用“–”标志位;
3. 正则表达式:其机制类同字符串匹配;
4. IP地址及网络地址;
注意:同一个acl中可以指定多个测试条件,这些测试条件需要由逻辑操作符指定其关系。条件间的组合测试关系有三种:“与”(默认即为与操作)、“或”(使用“||”操作符)以及“非”(使用“!”操作符)。
常用的测试标准(criteria)
(1) 基于七层协议(http)规则acl测试标准
1. method <string>
method <string>测试HTTP请求报文中请求类型。
例如: 利用method来实现前段读写分离:
acl read method GET
acl read method HEAD
acl write method PUT
acl write method POST
use_backend imgservers if read
use_backend uploadservers if write
2. path_beg <string> ||url_beg
用于测试请求的URL是否以指定的模式开头;下面的例子用于测试URL是否以 /static、/images、/javascript或/stylesheets头。
例如:利用path_beg实现以/static /images开头的请求转交到 static server上:
acl url_static path_beg -i /static /images
use_backend static if url_static
2. path_end <string> || url_reg
用于测试请求的URL是否以<string>指定的模式结尾。例如,下面的例子用户测试URL是否以jpg、gif、png、css或js结尾
例如:利用path_end实现以.jpg .gif .png .css等结尾的格式的请求转交到 static server上:
acl url_static path_end -i .jpg .gif .png .css .js .html
use_backend static if url_static
3. hdr_beg <string>
用于测试请求报文的指定首部的开头部分是否符合<string>指定的模式。
acl is_lvs3 hdr_beg(host) -i lvs3.test.net:8080
use_backend lvs3 if is_lvs3
#表示当request header中的host前缀部分匹配到lvs.test.net.:8080则将请求转给后端backend定义的 is_lvs3上
4. hdr_end <string>
用于测试请求报文的指定首部的结尾部分是否符合<string>指定的模式
acl is_lvs3 hdr_end(host) -i lvs3.test.net:8080
use_backend lvs3 if is_lvs2
#表示当request header中的host后缀部分匹配到lvs3.test.net.:8080则将请求转给后端backend定义的 is_lvs2上
5. hdr <string>
用于测试请求报文中的所有首部或指定首部信息是否满足指定的条件;指定首部时, 其名称不区分大小写, 且在括号中“()”不能有任何多余的空白字符。测试服务器端的响应报文时可以使用shdr()。
例如 当用户访问172.16.1.100时,重定向到http://www.afwing.com
acl dstipaddr hdr(Host) 172.16.1.100
redirect location http://www.afwing.com if dstipaddr
(2) 基于四层协议(ip)规则acl测试标准
1. dst和dst_port
定义访问地址为目标地址或目标端口的acl规则
2. src和src_port
定义访问地址为源地址或源端口的acl规则
例如: 允许10.0.0.0/24的用户访问,其他用户将禁止
acl net10 src 10.0.0.0/24
tcp-request content accept if net10
tcp-request content reject
tcp-request content accept [ {if | unless} ]
Accept a connection if/unless a content inspection condition is matched
②haproxy acl引用
当定义好了ACL后我们可以利用“use_backend” 参数来引用acl规则,如果需要引用多个acl时,只需要依次在后面添加相关acl ,也可以 匹配多个acl,如下示例:
1.正常写法:
use_backend static if url_static
2.或者写法:
use_backend backend1 if aclA || aclB
use_backend backend1 if aclA || !aclC
注意上面“||”也可以使用or来表示
3.非(不符合)写法:
use_backend backend1 if aclA !aclB
use_backend backend1 if aclA !aclB !aclC
4.与(and)写法:
use_backend backend1 if aclA !aclB
use_backend backend1 if aclA !aclB !aclC
haproxy 常见应用实例:
1. haproxy 利用acl实现页面动静分离;
frontend webservs
bind *:80
acl url_static path_beg -i /static /images /javascript /stylesheets
acl url_static path_end -i .jpg .gif .png .css .js .html
acl url_php path_end -i .php
use_backend static if url_static or host_static
use_backend dynamic if url_php
default_backend dynamic
backend static
balance roundrobin
server node1 192.168.1.111:80 check maxconn 3000
backend dynamic
balance roundrobin
server node2 192.168.1.112:80 check maxconn 1000
二. haproxy 错误重定向用法
格式为: errorfile 错误代码code 错误代码文件路径
如下为常用的优化客户端访问出现错误时错误提示页面示例
errorfile 403 /etc/haproxy/errorfiles/403.http
errorfile 500 /etc/haproxy/errorfiles/500.http
errorfile 502 /etc/haproxy/errorfiles/502.http
errorfile 503 /etc/haproxy/errorfiles/503.http
errorfile 504 /etc/haproxy/errorfiles/504.http
至此,以上关于haproxy的配置文件相关参数就介绍到这里了,这些都是基本参数,如要更详细的配置介绍,请访问
实际应用环境中,往往需要根据业务请求将相关不同请求跳转到指定的后端server,比如客户静态资源请求交给静态资源server处理,php请求交给php server处理,jsp请求交给tomcat处理,即业务上的应用请求分离,而haproxy完全可以利用acl匹配规则实现这一目的 。
一. haproxy实现应用动静分离
如图所示为整体的拓扑图:
需求说明:
当客户端访问haproxy时,请求的是静态文件内容时,请求转交给static server,请求的是php内容时,请求转交给php server,请求的是jsp内容时,请求转交给tomcat server,以实现动静分离
一.部署前说明:
(1)系统版本: centos 6.6(64位)
(2)角色及ip相关信息:
角色名称 | ip信息 |
haproxy server | eth0:172.51.96.233/24 && eth1:192.168.0.233/24 |
static server | eth1:192.168.0.247/24 |
php server | eth1:192.168.0.235/24 |
tomcat server | eth1:192.168.0.238/24 |
二. 部署操作
haproxy server上操作
编译安装haproxy
1.1 到haproxy官网下载haproxy源码包如下
cd ~
wget http://www.haproxy.org/download/1.5/src/haproxy-1.5.15.tar.gz
1.2 创建haproxy运行用户
groupadd -r haproxy
useradd -g haproxy -M -s /sbin/nologin haproxy
1.3 编译安装haproxy:
cd ~
tar zxvf haproxy-1.5.15.tar.gz -C /usr/local/src
cd /usr/local/src/haproxy-1.5.15
make TARGET=linux26 PREFIX=/usr/local/haproxy
make install PREFIX=/usr/local/haproxy
注意:TARGET=Linux26 是通过uname -a 来查看Linux内核版本的
1.4 创建haproxy主配置文件:
mkdir /etc/haproxy/
touch /etc/haproxy/haproxy.cfg
后端web server上操作
1.5 分别在img server,php server,tomcat server安装相应的web环境并创建测试页,其中:
(1)static server的访问url为:http://192.168.0.247/img/haproxy.PNG ,页面内容如下:
(2)php server的访问url为:http://192.168.0.235/info.php ,页面内容如下:
(3)tomcat server的访问url为:http://192.168.238:8086/test.jsp ,页面内容如下:
1.6 编辑haproxy server的haproxy主配置文件:
代码内容如下
#---------------------------------------------------------------------
# Global settings
#---------------------------------------------------------------------
global
log 127.0.0.1 local3
maxconn 204800
chroot /usr/local/haproxy
user haproxy
group haproxy
daemon
nbproc 1
pidfile /var/run/haproxy.pid
stats socket /usr/local/haproxy/stats
description haproxy server
#---------------------------------------------------------------------
# common defaults that all the 'listen' and 'backend' sections will
# use if not designated in their block
#---------------------------------------------------------------------
defaults
log global
mode http
maxconn 10000
option httplog
option httpclose
option dontlognull
option forwardfor except 127.0.0.0/8
retries 3
option redispatch
option abortonclose
balance roundrobin
timeout http-request 10s
timeout queue 1m
timeout connect 10s
timeout client 1m
timeout server 1m
timeout http-keep-alive 10s
timeout check 10s
#---------------------------------------------------------------------
# use listen setting the haproxy status for site
#---------------------------------------------------------------------
listen admin_status #设置haproxy监控状态
bind *:3030
mode http
log 127.0.0.1 local3 err
stats refresh 5s
stats uri /status #监控状态页面访问url
stats realm www.skeryp.com
stats auth admin:admin
stats hide-version
stats admin if TRUE
#---------------------------------------------------------------------
# main listen which proxys to the backends
#---------------------------------------------------------------------
listen www
bind *:80
maxconn 5000
mode http
log global
option httplog
option httpclose
option forwardfor
log global
default_backend default #设置默认访问页面
#定义当请求的内容是静态内容时,将请求转交给static server的acl规则
acl url_static path_beg -i /static /images /img /javascript /stylesheets
acl url_static path_end -i .jpg .gif .png .css .js .html
acl host_static hdr_beg(host) -i img. video. download. ftp. imags. videos.
#定义当请求的内容是php内容时,将请求转交给php server的acl规则
acl url_php path_end -i .php
#定义当请求的内容是.jsp或.do内容时,将请求转交给tomcat server的acl规则
acl url_jsp path_end -i .jsp .do
#引用acl匹配规则
use_backend static_pool if url_static or host_static
use_backend php_pool if url_php
use_backend tomcat_pool if url_jsp
#定义后端backend server
backend static_pool
option httpchk GET /index.html
server static1 192.168.0.247:80 cookie id1 check inter 2000 rise 2 fall 3
backend php_pool
option httpchk GET /info.php
server php1 192.168.0.235:80 cookie id1 check inter 2000 rise 2 fall 3
backend tomcat_pool
option httpchk GET /index.jsp
server tomcat1 192.168.0.238:8086 cookie id2 check inter 2000 rise 2 fall 3
#<----------------------default site for listen and frontend------------------------------------>
backend default
mode http
option httpchk GET /index.html
server default 192.168.0.127:80 cookie id1 check inter 2000 rise 2 fall 3 maxconn 5000
注意:
上面的www的配置部分也可以用frontend配置块来替换,如下所示:
frontend www
bind *:80
maxconn 5000
mode http
log global
option httplog
option httpclose
option forwardfor
log global
default_backend default
acl url_static path_beg -i /static /images /img /javascript /stylesheets
acl url_static path_end -i .jpg .gif .png .css .js .html
acl host_static hdr_beg(host) -i img. video. download. ftp. imags. videos.
acl url_php path_end -i .php
acl url_jsp path_end -i .jsp .do
use_backend static_pool if url_static or host_static
use_backend php_pool if url_php
use_backend tomcat_pool if url_jsp
backend static_pool
option httpchk GET /index.html
server static1 192.168.0.247:80 cookie id1 check inter 2000 rise 2 fall 3
backend php_pool
option httpchk GET /info.php
server php1 192.168.0.235:80 cookie id1 check inter 2000 rise 2 fall 3
backend tomcat_pool
option httpchk GET /index.jsp
server tomcat1 192.168.0.238:8086 cookie id2 check inter 2000 rise 2 fall 3
备注: listen配置块是frontend和backend的组合体,listen里面可以单独配置backend不配置frontend,也可以组合使用,即listen配置区域可以交差使用frontend和backend的配置,如acl可以配置到frontend块, 也可以直接配置到listen块,但是不能配置到backend块。如backend的中server可以直接配置到listen配置区域,但不能直接配置到frontend配置区域
1.7 重启haproxy服务:
server haproxy restart
关于haproxy服务脚本代码请访问:http://blief.blog.51cto.com/6170059/1750573
三. 结论测试
在客户端访问:http://172.51.96.233/img/haproxy.PNG,可以发现haproxy将请求转交给后端static server了。如下:
访问:http://172.51.96.233/info.php,可以发现haproxy将请求转交给后端php server了。如下:
访问:http://172.51.96.233/test.jsp,可以发现haproxy将请求转交给后端tomcat server了。如下所示:
从上可知:haproxy已经成功实现了动静分离,即静态内容交由静态server处理,动态内容交由动态处理的server处理
如果我们要查看各个server的健康状态,可以登录:http://172.51.96.233:3030/admin,如下
总结:haproxy可以利用acl规则匹配url做相应的请求跳转,比如动静分离,域名跳转等等应用需求,haproxy是一款性能很强大的四层以及七层代理server。
前面我们讲到了haproxy利用acl来实现haproxy动静分离,在许多应用环境中,可能需要将访问的站点请求跳转到指定的站点上,比如客户单端访问xx.a.com需要将请求转发到xx.b.com或将http请求重定向到https请求,又例如当客户端访问出错,我们需要将错误code代码提示请求到指定的错误页面,诸如此类需求实现,就需要利用haproxy的重定向功能来达到此目的。
一. haproxy实现request请求重定向
关于haproxy 请求重定向主要会用到:1. redirect ;2. redir 这两类重定向配置语法。
1. redirect重定向的用法:(redirect通常配置在haproxy acl部分)
redirect一般有两个指令来执行HTTP重定向:
http-requets redirect (此种方式支持日志变量格式)、
redirect (此种方式只依赖于静态字符串)
这两个指令的语法是相同的,即redirect
现在被认为是传统和配置应该移动到http-request redirect
形式。
一个其它的主要区别是:http-request redirect
使用日志可变格式而redirect
语句只依赖于静态字符串。
redirect有三种重定向方式:
(1)位置重定向
使用语法如下:
redirect location <loc> [code <code>] <option> [{if | unless} <condition>]
使用位置重定向,例如下面所示指令可以将用户重定向到所提供的精确位置, 该位置可以是第三方URL链接,也可以是本地web服务的另一个访问路径
1. http-request redirect location <loc> [code <code>] [<option>] [<condition>]
2. redirect location <loc> [code <code>] [<option>] [<condition>]
相关指令参数如下:
* <loc> :一个日志格式变量 (或简单的字符串redirect语句)描述了新位置;
* code <code>(可选):HTTP重定向的状态代码来执行。 此选项下的允许的状态码如下所示:
状态码 | 含义 |
301 | 永久移动,转发 |
302 | 临时移动,不应该由客户端进行缓存。 这是默认值,如果没有code配置。 |
303 | 像302,但是浏览器必须使用GET获取新位置 |
307 | 像302,但浏览器必须重新使用相同的方法之一,从原来的请求 |
308 | 像301,但浏览器必须重新使用相同的方法比从原始请求所述一个 |
* <option>(可选): 可以是以下任何或组合的声明:
1. set-cookie NAME[=value] :一个Set-Cookie头部被添加到重定向。该cookie被命名为名称,可以有一个可选的值值。
2. clear-cookie NAME[=]一个特殊的Set-Cookie头被添加到重定向。该Cookie名为名称和最大年龄的cookie参数设置为0,目的是为了指示浏览器删除cookie。
注意:在于浏览器中,这是两个不同的Cookie:NAME和NAME = 以上根据您的流量模式,必须将两个语句适应。
* if | unless :用于条件判断
* <condition> (可选):用于匹配acl,一般为acl的名称
(2)前缀重定向
使用语法如下:
redirect prefix <loc> [code <code>] <option> [{if | unless} <condition>]
使用前缀重定向,将用户重定向到由concateneting建立了一个网址<pfx>
和完整的原始URI路径:
1. http-request redirect prefix <pfx> [code <code>] [<option>] [<condition>]
2. redirect prefix <pfx> [code <code>] [<option>] [<condition>]
相关指令参数如下:
* <pfx>
一个日志格式变量 (或简单的字符串redirect
语句)描述了新的位置前缀。
* code <code>(可选):HTTP重定向的状态代码来执行。 此选项下的允许的状态码如下所示:
状态码 | 含义 |
301 | 永久移动,转发 |
302 | 临时移动,不应该由客户端进行缓存。 这是默认值,如果没有code配置。 |
303 | 像302,但是浏览器必须使用GET获取新位置 |
307 | 像302,但浏览器必须重新使用相同的方法之一,从原来的请求 |
308 | 像301,但浏览器必须重新使用相同的方法比从原始请求所述一个 |
* <option>(可选): 可以是以下任何或组合的声明:
drop-query :在执行串联时从原来的URL删除查询字符串
append-slash :配合使用drop-query ,在该URL的末尾添加一个“/”字符
set-cookie NAME[=value] :一个Set-Cookie头部被添加到重定向。该cookie被命名为名称,可以有一个可选的值值。
clear-cookie NAME[=] :一个特殊的Set-Cookie头被添加到重定向。该Cookie名为名称和最大年龄的cookie参数设置为0,目的是为了指示浏览器删除cookie。
* if | unless :用于条件判断
* <condition> (可选):用于匹配acl,一般为acl的名称
(3)协议(计划)重定向(比如将http重定向到https)
使用语法如下:
redirect scheme <sch> [code <code>] <option> [{if | unless} <condition>]
使用位置重定向,例如下面所示指令可以将用户重定向到所提供的新的http协议url链接, 一般用于非安全链接跳转到安全链接,比如http跳转到https上
1. http-request redirect scheme <schloc> [code <code>] [<option>] [<condition>]
2. redirect scheme <sch> [code <code>] [<option>] [<condition>]
相关指令参数如下:
* <loc> :一个日志格式变量 (或简单的字符串redirect语句)描述了新位置;
* code <code>(可选):HTTP重定向的状态代码来执行。 此选项下的允许的状态码如下所示:
状态码 | 含义 |
301 | 永久移动,转发 |
302 | 临时移动,不应该由客户端进行缓存。 这是默认值,如果没有code配置。 |
303 | 像302,但是浏览器必须使用GET获取新位置 |
307 | 像302,但浏览器必须重新使用相同的方法之一,从原来的请求 |
308 | 像301,但浏览器必须重新使用相同的方法比从原始请求所述一个 |
* <option>(可选): 可以是以下任何或组合的声明:
1. set-cookie NAME[=value] :一个Set-Cookie头部被添加到重定向。该cookie被命名为名称,可以有一个可选的值值。
2. clear-cookie NAME[=]一个特殊的Set-Cookie头被添加到重定向。该Cookie名为名称和最大年龄的cookie参数设置为0,目的是为了指示浏览器删除cookie。
注意:在于浏览器中,这是两个不同的Cookie:NAME和NAME = 以上根据您的流量模式,必须将两个语句适应。
* if | unless :用于条件判断
* <condition> (可选):用于匹配acl,一般为acl的名称
如下为一个简单的实例:
acl http ssl_fc,not
http-request redirect scheme https if http
以下为redirect 综合应用的案例,如下:
acl clear dst_port 80
acl secure dst_port 8080
acl login_page url_beg /login
acl logout url_beg /logout
acl uid_given url_reg /login?userid=[^&]+
acl cookie_set hdr_sub(cookie) SEEN=1
redirect prefix https://mysite.com set-cookie SEEN=1 if !cookie_set
redirect prefix https://mysite.com if login_page !secure
redirect prefix http://mysite.com drop-query if login_page !uid_given
redirect location http://mysite.com/ if !login_page secure
redirect location / clear-cookie USERID= if logout
总结:
redirect三种重定向可以混合使用,比较常用的有redirect prefix 和 redirect location这两种方式,从某种理解上可以交差使用;
2. redir重定向的用法:(redir通常配置在haproxy backend部分)
使用redir 会将发往backend的站点服务请求均以302状态响应发给需要重定向的server服务或站点,此时haproxy不需要向后端web server提交请求;需要注意的是,在prefix后面不能使用/,且不能使用相对地址,以避免造成循环,例如:
frontend main *:80
default_backend app
backend app
balance roundrobin
server node1 127.0.0.1:81 check weight 3 redir http://www.bluemobi.cn
上面配置含义:所有发往localhost:81的请求做重定向,重定向到www.bluemobi.cn因此可以实现单台服务器的重定向
又例如,如果我们要讲访问的站点重定向到baidu.com
frontend main *:80
default_backend app
backend app
balance roundrobin
server node1 127.0.0.1:81 check weight 3 redir http://www.baidu.cn
注意:redir只做跳转,如客户端输入:http://ip ,将会跳转到指定的页面上,此时客户端的页面的页面也会跳转到指定的页面上,之后所有的请求都会递交到该站点(前提该站点可以与客户端通讯),而不再发往haproxy代理站点,haproxy也不需要往后端web server提交客户端发过来的请求。
二. haproxy实现error重定向
格式为: errorfile 错误代码code 错误代码响应提示页路径
* errorfile 即根据客户端页面错误code状态将指定的错误状态页面提示给客户端,比如友情提示页面,一般如下:
errorfile 403 /etc/haproxy/errorfiles/403.http
errorfile 500 /etc/haproxy/errorfiles/500.http
errorfile 502 /etc/haproxy/errorfiles/502.http
errorfile 503 /etc/haproxy/errorfiles/503.http
errorfile 504 /etc/haproxy/errorfiles/504.http
例如:如果想访问403页面重定向到其他页面的话,则参考以下配置
frontend web_server
bind *:80
default_backend webserver
acl badguy src 10.0.10.1
block if badguy
errorloc 403 http://baidu.com/ #定义错误页面重定向
总结: 错误重定向可以更加友好地提示客户端错误状态,比如做定制页面化跳转,以及网站维护升级等等,当出现错误时,可以及时跳转到预定好错误提示页面上。
haproxy的出现正是弥补nginx一些应用上不足,比如session会话保持,健康监控检测机制,负载算法等等,在很多应用环境中,nginx的代理性能会haproxy稍逊一些,不过在一些实际案例中,keepalive+nginx与keepalive+nginx往往会根据业务去选择,比如nginx有着haproxy没有的代理缓存的功能等等,如果需要用到缓存就可以使用nginx,总之:根据业务来选择这两者!
Keepalive+haproxy双机热备
如图所示为整体的拓扑图:
一.部署前说明:
(1)系统版本: centos 6.6(64位)
(2)角色及ip相关信息:
角色名称 | 网络ip信息 |
客户端(CIP) | 10.58.137.203/24 |
Master_DR | eth0:172.51.96.105/24 && eth1:192.168.0.105/24 |
Backup_DR | eth0:172.51.96.119/24 && eth1:192.168.0.119/24 |
VIP | 172.51.96.175/24 |
(3)相关中间件信息
keepalive版本信息: keepalived-1.2.15
nginx版本信息: haproxy-1.5.15 (提供proxy代理)
二.部署操作:
haproxy部署
分别在Master_DR和backup_DR上安装haproxy,操作如下:
1.1 到haproxy官网下载haproxy源码包如下
cd ~
wget http://www.haproxy.org/download/1.5/src/haproxy-1.5.15.tar.gz
1.2 创建haproxy运行用户
groupadd -r haproxy
useradd -r -g haproxy -M -s /sbin/nologin haproxy
1.3 编译安装haproxy:
cd ~
tar zxvf haproxy-1.5.15.tar.gz -C /usr/local/src
cd /usr/local/src/haproxy-1.5.15
make TARGET=linux26 PREFIX=/usr/local/haproxy
make install PREFIX=/usr/local/haproxy
注意:TARGET=Linux26 是通过uname -a 来查看Linux内核版本的
1.4 创建haproxy主配置文件:
mkdir /etc/haproxy/
vim /etc/haproxyhaproxy.cfg
配置代码内容如下:(注意主备server上haproxy.cfg配置要一致)
#---------------------------------------------------------------------
# Global settings
#---------------------------------------------------------------------
global
log 127.0.0.1 local3
maxconn 204800
chroot /usr/local/haproxy
user haproxy
group haproxy
daemon
nbproc 1
pidfile /var/run/haproxy.pid
stats socket /usr/local/haproxy/stats
description haproxy server
#---------------------------------------------------------------------
# common defaults that all the 'listen' and 'backend' sections will
# use if not designated in their block
#---------------------------------------------------------------------
defaults
log global
mode http
maxconn 10000
option httplog
option httpclose
option dontlognull
option forwardfor except 127.0.0.0/8
retries 3
option redispatch
option abortonclose
balance roundrobin
timeout http-request 10s
timeout queue 1m
timeout connect 10s
timeout client 1m
timeout server 1m
timeout http-keep-alive 10s
timeout check 10s
#---------------------------------------------------------------------
# use listen setting the haproxy status for site
#---------------------------------------------------------------------
listen admin_status
bind *:3030
mode http
log 127.0.0.1 local3 err
stats refresh 5s
stats uri /status
stats realm www.skeryp.com
stats auth admin:admin
stats hide-version
stats admin if TRUE
#---------------------------------------------------------------------
# main listen which proxys to the backends
#---------------------------------------------------------------------
listen www
bind *:80
maxconn 5000
mode http
log global
option httplog
option httpclose
option forwardfor
log global
default_backend default
#<----------------------default site for listen and frontend------------------------------------>
backend default
mode http
option httpchk GET /index.html
server default 127.0.0.1:81 cookie id1 check inter 2000 rise 2 fall 3 maxconn 5000
1.5 创建haproxy系统服务启动脚本:
关于haproxy服务脚本代码请访问:http://blief.blog.51cto.com/6170059/1750573
1.6 启动haproxy服务:
server haproxy restart
Keepalive部署
(1)分别在Master_DR和backup_DR上安装keepalive,操作如下:
1. 安装Keepalive所需要的相关依赖包:
yum install openssl-devel popt-devel libnl-devel kernel-devel -y
2. 编译安装keepalive
1.1 keepalived的源码获取
keepalived源码包我们可以到keepalived的官网:http://www.keepalived.org/去下载,相关说明文档亦可在其官网查看,比如keepalived的使用,相关配置说明,这里演示的版本为:1.2.15
cd ~
wget http://www.keepalived.org/software/keepalived-1.2.15.tar.gz
1.2 编译安装keepalived
<–编译安装keepalived–>
ln -s /usr/src/kernels/2.6.32-573.18.1.el6.x86_64/ /usr/src/linux
tar zxvf keepalived-1.2.15.tar.gz -C /usr/local/src
cd /usr/local/src/keepalived-1.2.15/
./configure
--prefix=/usr/local/keepalived
--with-kernel-dir=/usr/src/kernels/2.6.32-573.18.1.el6.x86_64
#2.6.32-573.18.1.el6.x86_64 这个需要根据kernel来匹配,一般安装了kernel-devel即可查看
make make install
<–对keepalived进行相关路径优化调整–>
<---拷贝keepalived相关启动命令--->
cp /usr/local/keepalived/sbin/keepalived /usr/sbin/
cp /usr/local/keepalived/etc/sysconfig/keepalived /etc/sysconfig/
<---将keepalived启动脚本添加到系统服务--->
cp /usr/local/keepalived/etc/rc.d/init.d/keepalived /etc/init.d/
chkconfig --add keepalived
chkconfig --level 2345 keepalived on
<---创建keepalived相关配置文件--->
mkdir -p /etc/keepalived
cp /usr/local/keepalived/etc/keepalived/keepalived.conf /etc/keepalived
(3)分别配置Master_DR以及Backup_DR上的keepalive实例,如下所示:
1. master_dr配置代码示例(主调度器)
vim /etc/keepalived/keepalived.conf
内容如下
! Configuration File for keepalived
global_defs {
notification_email {
admin@bluemobi.cn
}
notification_email_from lvs_admin@bluemobi.cn
smtp_server 127.0.0.1
smtp_connect_timeout 30
router_id DR_MASTER
}
vrrp_script check_haproxy { #表示创建一个脚本check_haproxy
script "/etc/keepalived/scripts/check_haproxy.sh" #引用的脚本路径
interval 3 #表示检测时间的间隔为3s
}
vrrp_instance http {
state BACKUP
interface eth0
dont_track_primary
nopreempt #不抢占master
track_interface { #表示需要检测的网卡
eth0
eth1
}
mcast_src_ip 172.51.96.105 #表示设置组播的源地址
garp_master_delay 6
virtual_router_id 60
priority 110
advert_int 1
authentication {
auth_type PASS
autp_pass 1234
}
virtual_ipaddress {
172.51.96.175/24 brd 172.51.96.255 dev eth0 label eth0:1
}
virtual_routes {
172.51.96.175/24 dev eth0
}
track_script {
check_haproxy
}
notify_master /etc/keepalived/scripts/state_master.sh
notify_backup /etc/keepalived/scripts/state_backup.sh
notify_fault /etc/keepalived/scripts/state_fault.sh
}
2. backup_dr配置示例(备调度器)
vim /etc/keepalived/keepalived.conf
内容如下
! Configuration File for keepalived
global_defs {
notification_email {
admin@bluemobi.cn
}
notification_email_from admin@bluemobi.cn
smtp_server 127.0.0.1
smtp_connect_timeout 30
router_id DR_BACKUP
}
vrrp_script check_haproxy {
script "/etc/keepalived/scripts/check_haproxy.sh"
interval 3
}
vrrp_instance http {
state BACKUP
interface eth0
dont_track_primary
track_interface {
eth0
eth1
}
mcast_src_ip 172.51.96.119
garp_master_delay 6
virtual_router_id 60
priority 105
advert_int 1
authentication {
auth_type PASS
autp_pass 1234
}
virtual_ipaddress {
172.51.96.175/24 brd 172.51.96.255 dev eth0 label eth0:1
}
virtual_routes {
172.51.96.175/24 dev eth0
}
track_script {
check_haproxy
}
notify_master /etc/keepalived/scripts/state_master.sh
notify_backup /etc/keepalived/scripts/state_backup.sh
notify_fault /etc/keepalived/scripts/state_fault.sh
}
3.分别在主调度server和备调度server编写以下脚本,如下:
i 当调度器为切换master server时,记录切换时间日志
vim /etc/keepalived/scripts/state_master.sh
代码如下:
#!/bin/bash
echo -e >> $LOGFILE
host=CN-SH-DR01 #设置当前的主机名
LOGFILE="/var/log/keepalived-state.log"
echo "[Master]" >> $LOGFILE
date >> $LOGFILE
echo "The ${host} Starting to become master server...." >> $LOGFILE 2>&1
echo "Please run the “ipvsadm -Ln” check the keepalived state ..." >> $LOGFILE
echo ".........................................................................!">> $LOGFILE
echo >>$LOGFILE
ii 当调度器为切换backup server时,记录切换时间日志
vim /etc/keepalived/scripts/state_backup.sh
代码如下:
#!/bin/bash
echo -e >> $LOGFILE
host=CN-SH-DR01 #设置当前的主机名
LOGFILE="/var/log/keepalived-state.log"
echo "[Backup]" >> $LOGFILE
date >> $LOGFILE
echo "The ${host} Starting to become Backup server...." >> $LOGFILE 2>&1
echo "Please run the “ipvsadm -Ln” check the state ..." >> $LOGFILE
echo "........................................................................!">> $LOGFILE
echo >> $LOGFILE
iii 当调度器出现错误时,记录错误时间日志
vim /etc/keepalived/scripts/state_fault.sh
代码如下:
#!/bin/bash
echo -e >> $LOGFILE
host=CN-SH-DR01 #设置当前的主机名
LOGFILE="/var/log/keepalived-state.log"
echo "[fault errot ]" >> $LOGFILE
date >> $LOGFILE
echo "The ${host} is fault error...." >> $LOGFILE 2>&1
echo "Please check the server state ..." >> $LOGFILE
echo "........................................................................!">> $LOGFILE
echo >> $LOGFILE
iiii 服务状态健康监测脚本,比如当haproxy不可用时,及时切换到backup调度器上
vim /etc/keepalived/scripts/check_haproxy.sh
#!/bin/bash
#nginx="/usr/local/haproxy/sbin/haproxy"
PID=`ps -C haproxy --no-heading|wc -l`
if [ "${PID}" = "0" ];
then
/etc/init.d/haproxy start
sleep 3
LOCK=`ps -C haproxy --no-heading|wc -l`
if [ "${LOCK}" = "0" ];
then
/etc/init.d/keepalived stop
fi
fi
(4)依次重启master_dr,backup-dr上keepalive服务
# service keepalived restart
三.测试验证:
在两台调度器安装web服务并创建相关测试页,如下:
master-dr主调度服务器的测试页面
[root@master-dr www]# curl 172.51.96.105:81
this is master server
[root@master-dr www]#
backup-dr备调度服务器的测试页面
[root@backup-dr htdocs]# curl 172.51.96.119:81
this is backup server
[root@backup-dr htdocs]#
通过messages查看vip抢夺情况,如下所示:
述上发现vip已经被master-dr抢夺,通过ifconfig看到master-dr已经存在vip地址,如下
在客户端通过:http://vip 就可以访问到页面,此时访问的是master-dr的页面:
我们在master-dr将keepalived服务停止掉,来模仿主调度器宕机情形:
[root@master-dr scripts]# service keepalived stop
Stopping keepalived: [ OK ]
[root@master-dr scripts]#
分别查看master-dr和backup-dr的keepalive日志:
此时vip已经由backup-dr接管了,因为master-dr上nginx服务异常,而keepalive会定时触发引用的检查脚本 “check_nginx”检查nginx状态,发现nginx可用就停止了keepalive服务,从而使vip顺利的飘逸到backup-dr上;
查看keepalive-state.log,可以看到master-dr和backup-dr会记录每个状态的的信息:同时日志记录脚本也会记录相关信息:
[root@master-dr sbin]# tail -10 /var/log/keepalived-state.log
The CN-SH-DR01 Starting to become Backup server....
Please run the “ipvsadm -Ln” check the state ...
...............................................................................!
[fault errot ]
Fri Mar 11 15:28:48 CST 2016
The CN-SH-DR01 is fault error....
Please check the server state ...
...............................................................................!
[root@backup-dr htdocs]# tail -10 /var/log/keepalived-state.log
[Backup]
Fri Mar 11 14:42:56 CST 2016
The CN-SH-DR02 Starting to become Backup server....
Please run the “ipvsadm -Ln” check the state ...
...............................................................................!
[Master]
Fri Mar 11 15:06:58 CST 2016
The CN-SH-DR02 Starting to become master server....
Please run the “ipvsadm -Ln” check the state ...
...............................................................................!
再次访问http://vip 发现页面为backup-dr的页面:
到这里,整个keepalive+haproxy双机热备就部署完成了
总结:关于keepalive+haproxy双机热备适合很多web前端高可用集群应用,相对于keepalive+lvs案例应用,配置起来更方便,更简单,与它同样的经典应用案例:keepalive+nginx也是一个不错的双机热备方案,通常在需要高性能高可用反向代理场合,keepalive+haproxy是一个不错的选择方案。
转载自:https://www.xwroot.com/archives/463/