共计 16264 个字符,预计需要花费 41 分钟才能阅读完成。
HAProxy 详解
HAProxy 是免费、极速且可靠的用于为 TCP 和基于 HTTP 应用程序提供高可用、负载均衡和代理服务的解决方案,尤其适用于高负载且需要持久连接或 7 层处理机制的 web 站点。HAProxy 还可以将后端的服务器与网络隔离,起到保护后端服务器的作用。HAProxy 的负载均衡能力虽不如 LVS,但也是相当不错,而且由于其工作在 7 层,可以对 http 请求报文做深入分析,按照自己的需要将报文转发至后端不同的服务器(例如动静分离),这一点工作在 4 层的 LVS 无法完成。
安装配置 HAproxy
HAProxy 已经集成在 base 源中,可直接通过 yum 下载。
[root@node1 ~]# yum install haproxy
当然也可以去官网直接下载源码编译安装。
/etc/haproxy/haproxy.cfg 为 haproxy 的主配置文件,里面包括全局配置段(global settings)和代理配置段(proxies)。
global settings:主要用于定义 haproxy 进程管理安全及性能相关的参数
proxies:代理相关的配置可以有如下几个配置端组成。
– defaults <name>:为其它配置段提供默认参数,默认配置参数可由下一个“defaults”重新设定。
– frontend <name>:定义一系列监听的套接字,这些套接字可接受客户端请求并与之建立连接。
– backend <name>:定义“后端”服务器,前端代理服务器将会把客户端的请求调度至这些服务器。
– listen <name>:定义监听的套接字和后端的服务器。类似于将 frontend 和 backend 段放在一起
HAproxy 的工作模式:
HAProxy 的工作模式一般有两种:tcp 模式和 http 模式。
tcp 模式:实例运行于 TCP 模式,在客户端和服务器端之间将建立一个全双工的连接,且不会对 7 层报文做任何类型的检查,只能以简单模式工作。此为默认模式,通常用于 SSL、SSH、SMTP 等应用。
http 模式:实例运行于 HTTP 模式,客户端请求在转发至后端服务器之前将被深度分析,所有不与 RFC 格式兼容的请求都会被拒绝。
当实现内容交换时,前端和后端必须工作于同一种模式(一般都是 HTTP 模式),否则将无法启动实例。工作模式可通过 mode 参数在 default,frontend,listen,backend 中实现定义。
mode {tcp|http}
————————————– 分割线 ————————————–
Haproxy+Keepalived 搭建 Weblogic 高可用负载均衡集群 http://www.linuxidc.com/Linux/2013-09/89732.htm
Keepalived+HAProxy 配置高可用负载均衡 http://www.linuxidc.com/Linux/2012-03/56748.htm
CentOS 6.3 下 Haproxy+Keepalived+Apache 配置笔记 http://www.linuxidc.com/Linux/2013-06/85598.htm
Haproxy + KeepAlived 实现 WEB 群集 on CentOS 6 http://www.linuxidc.com/Linux/2012-03/55672.htm
Haproxy+Keepalived 构建高可用负载均衡 http://www.linuxidc.com/Linux/2012-03/55880.htm
使用 HAProxy 配置 HTTP 负载均衡器 http://www.linuxidc.com/Linux/2015-01/112487.htm
————————————– 分割线 ————————————–
下面介绍一些 HAproxy 的常见用法。
应用实例
基于 HAProxy 实现负载均衡
在 backend 段或 listen 段中通过 server 定义后端节点。
格式:server <name> <address>[:port] [param*]
<name>:为此服务器指定的内部名称
[param*]:为此服务器设定的一系参数。其可用的参数很多,以下为常用参数。
服务器参数:
backup:设定为备用服务器,仅在负载均衡场景中的其它 server 均不可用于启用此 server;
maxconn <maxconn>:指定此服务器接受的最大并发连接数;如果发往此服务器的连接数目高于此处指定的值,其将被放置于请求队列,以等待其它连接被释放;
maxqueue <maxqueue>:设定请求队列的最大长度;
observe <mode>:通过观察服务器的通信状况来判定其健康状态,默认为禁用,其支持的类型有“layer4”和“layer7”,“layer7”仅能用于 http 代理场景;
redir <prefix>:启用重定向功能,将发往此服务器的 GET 和 HEAD 请求均以 302 状态码响应;
weight <weight>:服务器权重,默认为 1,最大值为 256,0 表示不参与负载均衡;
定义负载均衡的算法,算法的定义除了 listen 段和 backend 段中也可以放在 defaults 段中,定义格式如下:
balance <algorithm> [<arguments>]
balance url_param <param> [check_post [<max_wait>]]
常见的调度算法有:
roundrobin:基于权重进行轮询,此算法是动态的,其权重可以在运行时进行调整。
static-rr:基于权重进行轮询,与 roundrobin 类似,但是为静态方法,在运行时调整其服务器权重不会生效。
leastconn:新的连接请求被派发至具有最少连接数目的后端服务器,动态算法,适用于较长时间会话的场景。
source:将请求的源地址进行 hash 运算,并与后端服务器的总权重作取模运算后调度至某台服务器;同一 IP 地址的请求将始终被调度至某特定的服务器,静态算法,可以使用 hash-type 修改此特性;
uri:对 URI 的左半部分 (“?”之前的部分) 或整个 URI 进行 hash 运算,并与后端服务器的总权重作取模运算后调度至某台服务器;同一 URI 的请求将始终被调度至某特定的服务器,静态算法,可以使用 hash-type 修改此特性;
hdr(<name>):根据用户请求报文中指定的 http 首部的值进行调度,常用于实现将对同一个虚拟主机的请求始终发往同个 backend server。
前端代理服务器上配置示例(其余为默认配置):
#———————————————————————
# main frontend which proxys to the backends
#———————————————————————
frontend service *:80
default_backend app
#———————————————————————
# static backend for serving up images, stylesheets and such
#———————————————————————
backend app
balance roundrobin
server app1 192.168.2.7:80 maxconn 3000 weight 2
server app2 192.168.2.18:80 maxconn 3000 weight 1
server app3 127.0.0.1:8080 backup
在 app1(192.168.2.7)上配置测试页面:
[root@node1 ~]# vim /web/index.html
<h2>server node1</h2>
在 app1(192.168.2.18)上:
[root@node2 ~]# vim /web/index.html
<h2>server node2</h2>
在代理服务器上有两个接口:192.168.1.116(面向客户端),192.168.2.11。配置完成后启动 haproxy 服务。后端节点上启动 nginx 服务。
已实现轮询访问。
在上述的算法中涉及到 hash 运算,hash-type 参数可定义 hash 的运算方式。格式如下:
格式:hash-type <map-based|consistent>
map-based:静态方法,在线调整服务器权重不能立即生效。hash 表是一个包含了所有在线服务器的静态数组。简而言之,通过这种运算方式将请求调度至后端的某台服务器,当后端的服务器放生变动时(如某台服务器宕机或新添加了一台服务器),大部分的连接将会被重新调度至一个与之前不同的服务器上。
consistent:动态发放,支持在线调整服务器权重。hash 表是一个由各服务器填充而成的树状结构,使用此算法调度,当后端的服务器发生变动时,大分布的连接将依旧被调度至原本的服务器上。
默认方式为 map-based,可应用于大部分场景。但是若后端的服务器为缓存服务器,使用默认方式,当后端的服务器调整时,将导致缓存无法命中,从而影响系统的性能。推荐的配置方式:
backend <name>
balance uri
hash-type consistent
server ….
server …
对后端服务器健康状况的检测
check 为 server 的参数,可启动对此 server 执行健康状态的检测。check 借助其额外的参数可实现更精细的监测机制。
inter <delay>:健康状态检测的时间间隔,单位为毫秒,默认为 2000,可以使用 fastinter 和 downinter 来根据服务器端状态优化此时间延迟;
rise <count>:健康状态检测中,某离线的 server 从离线状态转换至正常状态需要成功检查的次数;
fall <count>:确认 server 从正常状态转换为不可用状态需要检查的次数;
配置示例:
backend app
balance roundrobin
server app1 192.168.2.7:80 maxconn 3000 weight 2 check inter 1 rise 1 fall 2
server app2 192.168.2.18:80 maxconn 3000 weight 1 check inter 1 rise 1 fall 2
server app3 127.0.0.1:8080 backup
state 页面
启用统计报告,通过 state 页面可查看到各服务器的状态及其相关信息。关于 state 的配置建议单独定义一个 listen。
listen stats
mode http
bind 192.168.1.116:1080 #监听端口
stats enable #启用 state 功能
stats scope app #统计报告的报告区段,不启动这项则报告所有区段
stats hide-version #隐藏 HAProxy 版本号
stats uri /haproxyadmin?stats #state 页面的访问路径
stats realm Haproxy\ Statistics #认证时提示信息
stats auth baby:baby #认证的账号密码
stats admin if TRUE #启用管理功能
配置完成后重启 haproxy 服务。然后访问定义的路径:http://192.168.1.116:1080/haproxyadmin?stats。首先完成认证。
基于前面配置完成的健康状态检测,现在停止其中一台后端服务器的 nginx 服务。
[root@node1 web]# service nginx stop
Stopping nginx: [OK]
红色表示服务不在线,若停止所有后端服务器的服务,则会访问定义为 backup 的 server(127.0.0.1 上的 sorry 页面)。
更多详情见请继续阅读下一页的精彩内容:http://www.linuxidc.com/Linux/2015-09/122676p2.htm
基于 cookie 的 session 绑定
在响应报文中添加 cookie 信息,下一次的客户请求会带上这个 cookie 信息,服务器端根据 cookie 将请求始终定向至后端的某一台服务器。可用于保持 session 会话。
cookie 配置格式:
cookie <name> [rewrite | insert | prefix] [indirect] [nocache][postonly] [preserve] [httponly] [secure][domain <domain>]* [maxidle <idle>] [maxlife <life>]
配置示例:
backend app
balance roundrobin
cookie babyserver insert nocache indirect
server app1 192.168.2.17:80 check port 80 cookie app1
server app2 192.168.2.16:80 check port 80 cookie app2
重启服务,客户端进行访问。
客户端查看响应报文:
Set-Cookie 首部已经添加信息,接下来该客户端的访问(只要 cookie 信息还在)将始终被定向至 app2。
option forwardfor
客户端的请求经前端的代理服务器转发至后端的 web 服务器,代理服务器在转发时将目标地址改为后端的某台 web 服务器地址,将源地址由 client ip(客户端地址)改为自己面向后端服务器的地址。后端的 web 服务器若使用默认格式记录日志,则记录的客户端 IP 地址都为前端的代理服务器地址。这时需要在发往后端的请求报文中添加内容为客户端 IP 地址的首部,以便后端的 web 服务器能够正确获取客户端地址。
使用 option forwardfor 在发往服务器的请求首部中插入“X-Forwarded-For”首部。
格式:option forwardfor [except <network>] [header <name>] [if-none]
<network>:源地址被该参数匹配到时,禁用此功能;
<name>:可自定义首部名称代替“X-Forwarded-For”;
if-none:仅在此首部不存在时才允许添加至请求报文中。
backend app
…….
option forwardfor header X-Client
在后端的 web 服务器上修改日志格式。
这里后端的 web 服务器为 nginx,若为 httpd,%{headname}i 获取指定首部信息。重新加载配置文件后,即可获取客户端 IP。
ACL 简介
haproxy 的 ACL 能够通过检测请求报文的首部、响应报文的内容或其他的环境状态信息作出转发决策,增强了其配置弹性。配置分两步骤:首先定义 ACL,即定义一个测试条件,再定义动作,即满足测试条件的情况下执行的某特定动作。
定义格式:acl <aclname> <criterion> [flags] [operator] <value> …
<aclname>:ACL 名称。
<criterion>:测试标准,即对什么信息发起测试。
[flags]:目前 haproxy 的 acl 支持的标志位有 3 个:
-i:不区分 <value> 中模式字符的大小写;
-f:从指定的文件中加载模式;
–:标志符的强制结束标记;
<value>:acl 测试的值。
常见的测试标准(criterion)有 be_sess_rate,fe_sess_rate,hdr <string>,method <string>,path_beg <string>,path_end <string>,hdr_beg <string>,hdr_end <string>….. 具体的用法可以查阅相关文档。
基于 ACL 实现动静分离
实验环境:
haproxy2 作为高可用集群的备用节点。
前端代理服务器收到的请求通过分析其 uri,将静态内容调度至 static server1 和 2,将动态内容调度至 dynamic server1 和 2。
1)首先 haproxy1 和 haproxy2 实现时间同步
2)在 haproxy1 和 haproxy2 安装 keepalived 和 haproxy。
3)编辑配置文件
配置 haproxy,配置完成后将配置文件同步至 haproxy2 节点(关于每个参数的解释,可参考 http://cbonte.github.io/haproxy-dconv/):
[root@node1 haproxy]# vim haproxy.cfg
#———————————————————————
# Global settings
#———————————————————————
global
log 127.0.0.1 local2
chroot /var/lib/haproxy
pidfile /var/run/haproxy.pid
maxconn 4000 #最大并发连接数
user haproxy #运行 haproxy 的用户
group haproxy #运行 haproxy 的组
daemon #后台运行
# turn on stats unix socket
stats socket /var/lib/haproxy/stats
#———————————————————————
# common defaults that all the ‘listen’ and ‘backend’ sections will
# use if not designated in their block
#———————————————————————
defaults
mode http #工作模式
log global #使用全局日志
option httplog
option dontlognull
option http-server-close #允许客户端关闭连接
option forwardfor except 127.0.0.0/8
option redispatch #某上游服务器故障,重新将发往该服务器的请求发往其他的 server。
retries 3 #请求重试次数
timeout http-request 10s
timeout queue 1m
timeout connect 10s
timeout client 1m
timeout server 1m
timeout http-keep-alive 10s
timeout check 10s
maxconn 3000
?#———————————————————————
# main frontend which proxys to the backends
#———————————————————————
frontend service 192.168.1.200:80
option httpclose #允许服务器端被动关闭连接
option logasap
capture request header Host len 20
capture request header Referer len 60
#定义 ACL,以下两个 ACL 是获取静态请求
acl url_static path_beg -i /static /images /javascript /stylesheets
acl url_static path_end -i .jpg .gif .png .css .js
use_backend static if url_static #将静态请求定向至 static
default_backend app #非静态请求定向至 app
option forwardfor header X-Client #添加内容为客户端 IP 的首部
#———————————————————————
# static backend for serving up images, stylesheets and such
#———————————————————————
backend static
balance roundrobin
server first 192.168.2.7:80 check port 80 maxconn 3000
server second 192.168.2.18:80 check port 80 maxconn 3000
#———————————————————————
# round robin balancing between the various backends
#———————————————————————
backend app
balance roundrobin
option forwardfor header X-Client
server app1 192.168.2.17:80 check port 80 maxconn 3000
server app2 192.168.2.16:80 check port 80 maxconn 3000
server app3 127.0.0.1:8080 backup
配置 keepalived:
haproxy1 上:
[root@node1 ~]# vim /etc/keepalived/keepalived.conf
vrrp_instance VI_1 {
state MASTER
interface eth0
virtual_router_id 51
priority 100
advert_int 1
authentication {
auth_type PASS
auth_pass 1234
}
virtual_ipaddress {
192.168.1.200
}
notify_master “/etc/init.d/haproxy start” #提升为主节点时,启动 haproxy 服务
notify_backup “/etc/init.d/haproxy stop” #降级为备节点时,关闭 haproxy 服务
notify_fault “/etc/init.d/haproxy stop” #运行出错时,关闭 haproxy 服务
}
haproxy2 上(省略部分与 haproxy1 上一致):
vrrp_instance VI_1 {
state BACKUP #备用节点
……
priority 99 #服务器优先级
…….
}
配置完成后在启动各节点上的服务:
[root@www ~]# ansible haproxy -m shell -a ‘service haproxy start’
[root@www ~]# ansible haproxy -m shell -a ‘service keepalived start’
[root@www ~]# ansible webstatic -m shell -a ‘service nginx start’
[root@www ~]# ansible webdynamic -m shell -a ‘service httpd start’
可以看到主节点上的虚拟 IP 已启用。在各个 web 节点上准备测试页面。
dynamic server1 和 server2 上:
####server1#####
[root@node1 ~]# vim /var/www/html/index.php
<h1>dynamic server1</h1>
<?php
phpinfo();
?>
####server2#####
[root@node2 ~]# vim /var/www/html/index.php
<h1>dynamic server2</h1>
<?php
phpinfo();
?>
static server1 和 server2 上:
####server1#####
[root@node1 web]# vim images/abc.html
<h1>static node1</h1>
####server2#####
[root@node2 web]# vim images/abc.html
<h1>static node2</h1>
进行访问测试:
访问静态内容:
访问动态内容:
这里已经对单节点 haproxy 做了高可用,当主节点故障时,服务能够自动切换至备节点而不中断访问。完成部署!……………..^_^
HAproxy 的详细介绍:请点这里
HAproxy 的下载地址:请点这里
本文永久更新链接地址:http://www.linuxidc.com/Linux/2015-09/122676.htm
HAProxy 详解
HAProxy 是免费、极速且可靠的用于为 TCP 和基于 HTTP 应用程序提供高可用、负载均衡和代理服务的解决方案,尤其适用于高负载且需要持久连接或 7 层处理机制的 web 站点。HAProxy 还可以将后端的服务器与网络隔离,起到保护后端服务器的作用。HAProxy 的负载均衡能力虽不如 LVS,但也是相当不错,而且由于其工作在 7 层,可以对 http 请求报文做深入分析,按照自己的需要将报文转发至后端不同的服务器(例如动静分离),这一点工作在 4 层的 LVS 无法完成。
安装配置 HAproxy
HAProxy 已经集成在 base 源中,可直接通过 yum 下载。
[root@node1 ~]# yum install haproxy
当然也可以去官网直接下载源码编译安装。
/etc/haproxy/haproxy.cfg 为 haproxy 的主配置文件,里面包括全局配置段(global settings)和代理配置段(proxies)。
global settings:主要用于定义 haproxy 进程管理安全及性能相关的参数
proxies:代理相关的配置可以有如下几个配置端组成。
– defaults <name>:为其它配置段提供默认参数,默认配置参数可由下一个“defaults”重新设定。
– frontend <name>:定义一系列监听的套接字,这些套接字可接受客户端请求并与之建立连接。
– backend <name>:定义“后端”服务器,前端代理服务器将会把客户端的请求调度至这些服务器。
– listen <name>:定义监听的套接字和后端的服务器。类似于将 frontend 和 backend 段放在一起
HAproxy 的工作模式:
HAProxy 的工作模式一般有两种:tcp 模式和 http 模式。
tcp 模式:实例运行于 TCP 模式,在客户端和服务器端之间将建立一个全双工的连接,且不会对 7 层报文做任何类型的检查,只能以简单模式工作。此为默认模式,通常用于 SSL、SSH、SMTP 等应用。
http 模式:实例运行于 HTTP 模式,客户端请求在转发至后端服务器之前将被深度分析,所有不与 RFC 格式兼容的请求都会被拒绝。
当实现内容交换时,前端和后端必须工作于同一种模式(一般都是 HTTP 模式),否则将无法启动实例。工作模式可通过 mode 参数在 default,frontend,listen,backend 中实现定义。
mode {tcp|http}
————————————– 分割线 ————————————–
Haproxy+Keepalived 搭建 Weblogic 高可用负载均衡集群 http://www.linuxidc.com/Linux/2013-09/89732.htm
Keepalived+HAProxy 配置高可用负载均衡 http://www.linuxidc.com/Linux/2012-03/56748.htm
CentOS 6.3 下 Haproxy+Keepalived+Apache 配置笔记 http://www.linuxidc.com/Linux/2013-06/85598.htm
Haproxy + KeepAlived 实现 WEB 群集 on CentOS 6 http://www.linuxidc.com/Linux/2012-03/55672.htm
Haproxy+Keepalived 构建高可用负载均衡 http://www.linuxidc.com/Linux/2012-03/55880.htm
使用 HAProxy 配置 HTTP 负载均衡器 http://www.linuxidc.com/Linux/2015-01/112487.htm
————————————– 分割线 ————————————–
下面介绍一些 HAproxy 的常见用法。
应用实例
基于 HAProxy 实现负载均衡
在 backend 段或 listen 段中通过 server 定义后端节点。
格式:server <name> <address>[:port] [param*]
<name>:为此服务器指定的内部名称
[param*]:为此服务器设定的一系参数。其可用的参数很多,以下为常用参数。
服务器参数:
backup:设定为备用服务器,仅在负载均衡场景中的其它 server 均不可用于启用此 server;
maxconn <maxconn>:指定此服务器接受的最大并发连接数;如果发往此服务器的连接数目高于此处指定的值,其将被放置于请求队列,以等待其它连接被释放;
maxqueue <maxqueue>:设定请求队列的最大长度;
observe <mode>:通过观察服务器的通信状况来判定其健康状态,默认为禁用,其支持的类型有“layer4”和“layer7”,“layer7”仅能用于 http 代理场景;
redir <prefix>:启用重定向功能,将发往此服务器的 GET 和 HEAD 请求均以 302 状态码响应;
weight <weight>:服务器权重,默认为 1,最大值为 256,0 表示不参与负载均衡;
定义负载均衡的算法,算法的定义除了 listen 段和 backend 段中也可以放在 defaults 段中,定义格式如下:
balance <algorithm> [<arguments>]
balance url_param <param> [check_post [<max_wait>]]
常见的调度算法有:
roundrobin:基于权重进行轮询,此算法是动态的,其权重可以在运行时进行调整。
static-rr:基于权重进行轮询,与 roundrobin 类似,但是为静态方法,在运行时调整其服务器权重不会生效。
leastconn:新的连接请求被派发至具有最少连接数目的后端服务器,动态算法,适用于较长时间会话的场景。
source:将请求的源地址进行 hash 运算,并与后端服务器的总权重作取模运算后调度至某台服务器;同一 IP 地址的请求将始终被调度至某特定的服务器,静态算法,可以使用 hash-type 修改此特性;
uri:对 URI 的左半部分 (“?”之前的部分) 或整个 URI 进行 hash 运算,并与后端服务器的总权重作取模运算后调度至某台服务器;同一 URI 的请求将始终被调度至某特定的服务器,静态算法,可以使用 hash-type 修改此特性;
hdr(<name>):根据用户请求报文中指定的 http 首部的值进行调度,常用于实现将对同一个虚拟主机的请求始终发往同个 backend server。
前端代理服务器上配置示例(其余为默认配置):
#———————————————————————
# main frontend which proxys to the backends
#———————————————————————
frontend service *:80
default_backend app
#———————————————————————
# static backend for serving up images, stylesheets and such
#———————————————————————
backend app
balance roundrobin
server app1 192.168.2.7:80 maxconn 3000 weight 2
server app2 192.168.2.18:80 maxconn 3000 weight 1
server app3 127.0.0.1:8080 backup
在 app1(192.168.2.7)上配置测试页面:
[root@node1 ~]# vim /web/index.html
<h2>server node1</h2>
在 app1(192.168.2.18)上:
[root@node2 ~]# vim /web/index.html
<h2>server node2</h2>
在代理服务器上有两个接口:192.168.1.116(面向客户端),192.168.2.11。配置完成后启动 haproxy 服务。后端节点上启动 nginx 服务。
已实现轮询访问。
在上述的算法中涉及到 hash 运算,hash-type 参数可定义 hash 的运算方式。格式如下:
格式:hash-type <map-based|consistent>
map-based:静态方法,在线调整服务器权重不能立即生效。hash 表是一个包含了所有在线服务器的静态数组。简而言之,通过这种运算方式将请求调度至后端的某台服务器,当后端的服务器放生变动时(如某台服务器宕机或新添加了一台服务器),大部分的连接将会被重新调度至一个与之前不同的服务器上。
consistent:动态发放,支持在线调整服务器权重。hash 表是一个由各服务器填充而成的树状结构,使用此算法调度,当后端的服务器发生变动时,大分布的连接将依旧被调度至原本的服务器上。
默认方式为 map-based,可应用于大部分场景。但是若后端的服务器为缓存服务器,使用默认方式,当后端的服务器调整时,将导致缓存无法命中,从而影响系统的性能。推荐的配置方式:
backend <name>
balance uri
hash-type consistent
server ….
server …
对后端服务器健康状况的检测
check 为 server 的参数,可启动对此 server 执行健康状态的检测。check 借助其额外的参数可实现更精细的监测机制。
inter <delay>:健康状态检测的时间间隔,单位为毫秒,默认为 2000,可以使用 fastinter 和 downinter 来根据服务器端状态优化此时间延迟;
rise <count>:健康状态检测中,某离线的 server 从离线状态转换至正常状态需要成功检查的次数;
fall <count>:确认 server 从正常状态转换为不可用状态需要检查的次数;
配置示例:
backend app
balance roundrobin
server app1 192.168.2.7:80 maxconn 3000 weight 2 check inter 1 rise 1 fall 2
server app2 192.168.2.18:80 maxconn 3000 weight 1 check inter 1 rise 1 fall 2
server app3 127.0.0.1:8080 backup
state 页面
启用统计报告,通过 state 页面可查看到各服务器的状态及其相关信息。关于 state 的配置建议单独定义一个 listen。
listen stats
mode http
bind 192.168.1.116:1080 #监听端口
stats enable #启用 state 功能
stats scope app #统计报告的报告区段,不启动这项则报告所有区段
stats hide-version #隐藏 HAProxy 版本号
stats uri /haproxyadmin?stats #state 页面的访问路径
stats realm Haproxy\ Statistics #认证时提示信息
stats auth baby:baby #认证的账号密码
stats admin if TRUE #启用管理功能
配置完成后重启 haproxy 服务。然后访问定义的路径:http://192.168.1.116:1080/haproxyadmin?stats。首先完成认证。
基于前面配置完成的健康状态检测,现在停止其中一台后端服务器的 nginx 服务。
[root@node1 web]# service nginx stop
Stopping nginx: [OK]
红色表示服务不在线,若停止所有后端服务器的服务,则会访问定义为 backup 的 server(127.0.0.1 上的 sorry 页面)。
更多详情见请继续阅读下一页的精彩内容:http://www.linuxidc.com/Linux/2015-09/122676p2.htm
![post-qrcode](https://www.xgss.net/wp-content/uploads/2023/07/二维码-微信公众号256x256.jpg)