了解HAProxy原理及参数

本文涉及的产品
网络型负载均衡 NLB,每月750个小时 15LCU
传统型负载均衡 CLB,每月750个小时 15LCU
应用型负载均衡 ALB,每月750个小时 15LCU
简介:

haproxy:

4层:并不涉及到用户空间,也就不需要完成模式转换,不需要套接字注册等.

    lvs

7层:

    nginx 

    haproxy

    ats

实例:

haproxy 双网卡: eth0:172.16.0.192 eth1:192.168.30.2

web1:192.168.30.131

web2:192.168.30.129


web1和web2的网关为haproxy的eth1的ip地址:

web1/web1 :route add default gw 192.168.30.1


配置由两部分组成:

global settings:对haproxy进程自身属性设定.

proxies:对代理的设定

default:默认配置

frontend:前端配置

backenbd:后端的设定

listen:监听

URL

http://host:port/path?queries#fragment


配置实例:

1
2
3
4
5
6
frontend server *:80 // 定义前端frontend name为server 监听80端口
         default_backend servers // 定义默认的backend server为servers
backend servers       // 定义后端的backend name为servers
         balance roundrobin // 负载均衡算法
         server  node1   192.168.30.129:80       check // 后端的节点:80一定要添加(尝试不添加会报错,1.4版本的貌似继承上面frontend的端口),开启健康检查
         server  node2   192.168.30.131:80       check

浏览器访问:http://192.168.30.130/   刷新可以看到负载均衡轮训


开启haproxy log:

haproxy.cfg提示开启haproxy.log 需要在/etc/sysconfig/syslog增加

local2.*                       /var/log/haproxy.log

操作:

vim /etc/rsyslog.conf

1、开启udp协议514端口

1
2
3
4
5
# Provides UDP syslog reception
$ModLoad imudp
$UDPServerRun 514
2、新增:
local2.*                                                 /var/log/haproxy .log

3、重启syslog和haproxy服务:

1
service rsyslog restart
1
/etc/init .d /haproxy  restart


4、测试查看日志:

1
tail  -f  /var/log/haproxy .log


bind参数:bind [<adresses>]:<port_range> [,...]

例子:

1
2
3
4
5
6
7
8
9
10
bind   :80,:443
bind 10.10.0.1:10080,10.10.0.1:10043
可以使用在listen和frontend模块中:
frontend server 
bind *:80
default_backendservers
backend servers
balanceroundrobin
servernode1192.168.30.129:80check
servernode2192.168.30.131:80check


balance参数:

roundrobin 加权轮训,wgight不指默认为1,后续backend新增的server node会自动识别,慢加载方式加载,

static-rr  静态轮训,新增的node节点除非重启haproxy否则不会自动识别;基于check健康检查下线的机器再次上线会自动识别;不会慢启动,新增的服务器立即加入服务器轮训列表,所有的请求都会立即到这台服务器.

leastconn  保持会话连接,常用的LDAP,SQL,TSE,ect...动态的。http协议时无状态的,获取到资源即断开所以不适用次算法.

source     保持会话session,基于ip地址做hash算法,同一个用户的请求将发往同一台服务器.


会话保持机制:

IP层:source

位于同一个NAT服务器背后的多个请求都会顶向至同一个upstream server;不利于均衡。

应用层:cookie

有更好的负载均衡效果;


source:一般只有不支持使用cookie插入又需要保持会话时使用.

url:用于后端服务器时cache server的场景,保证缓存命中率的.

cookie:

cookie <name> [ rewrite | insert | prefix ] [ indirect ] [ nocache ]

             [ postonly ] [ preserve ] [ httponly ] [ secure ]

             [ domain <domain> ]* [ maxidle <idle> ] [ maxlife <life> ]


frontend server 

bind *:80

default_backendservers


backend servers

cookie node insert nocache

balancesource

servernode1192.168.30.129:80check

servernode2192.168.30.131:80check


backend下使用cookie cookie名称为node,客户端每次访问都插入cookie,一般insert会与nocache同时使用,防止后端缓存服务器缓存cookie降低缓存命中率.

cookie绑定:

基于cookie绑定,访问后端node节点

frontend server 

bind *:80

default_backendservers


backend servers

cookie node insert nocache

balance roundrobin//做轮训

servernode1192.168.30.129:80checkcookie node1#定义node1的cookie为node1

servernode2192.168.30.131:80checkcookie node2#定义node2的cookie为node2


访问浏览器:http://192.168.30.130/index.html


发现并未做轮训,因为绑定了cookie信息,同一客户端的访问,请求将会被发往同一个后台node节点.


指定HAProxy的工作模式:

mode { tcp|http|health }

tcp:mysql、ldap

tcp为HAProxy的默认模式,haproxy在客户端和选定的upstream server之间建立一个全双工的连接;不会对应用层协议做任何检查;

SSL/Mysql/SSH等都应该使用此模式.


http:web

http协议

对应用层数据做深入分析,因此支持7层的过滤、处理、转换等机制;


health:健康检查


指定日志:

log global

log <address> [len <length>] <facility> [<level> [<minlevel>]]

no log


defaults、frontend、backend、listen四项都可以使用.

log global:使用全局配置中定义的日志服务器;

log <address> [len <length>] <facility> [<level> [<minlevel>]]


frontend server 

log 127.0.0.1local3#日志服务器,在rsyslog.conf中定义,指定的frontend日志.

bind *:80

default_backendservers


backend servers

cookie node insert nocache

balance roundrobin

servernode1192.168.30.129:80checkcookie node1

servernode2192.168.30.131:80checkcookie node2

rsyslog.conf的配置:

local3.*                                                /var/log/haproxyweb.log


捕获请求首部和相应首部:

capture request header <name> len <length>

capture response header <name> len <length>


定义默认后端服务器:在listen或frontend中指定使用的默认后端:

default_backend <backend>


use_backend <backend> [{if | unless} <condition>]

在listen或frontend中,定义指明使用哪个后端服务器.



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

为backend或listen定义各服务器.

默认server的参数:

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

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

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

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

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


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


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


observer <mode>:通过观察服务器的通信状况来判断其健康状态,默认为禁用,其支持的类型有4层和layer7,"layer7"仅能在http代理场景下使用。


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

不能使用相对地址,以免造成循环;例如:server srv1 172.16.0.110 redir http://www.example.com


weight<weight>:权重,默认为1,最大为256,0表示不参与权重.


check对后端的服务器做健康状态检测;

扩展参数:option httpchk


option httpchk

option httpchk <uri>

option httpchk <method> <uri>

option httpchk <method> <uri> <version>


stats启用默认设置统计表:

stats enable

四项都可以使用:defaults、frontend、listen、backend

如果启用此配置,不自己

This statement enables statistics reporting with default settings defined

at build time. Unless stated otherwise, these settings are used :

 - stats uri   : /haproxy?stats    默认的url,可以自己指定

 - stats realm : "HAProxy Statistics" 描述和提示

 - stats auth  : no authentication默认的认证,铭文密码隔开

 - stats scope : no restriction指定访问位置的


浏览器访问haproxy代理:http://192.168.30.130/haproxy?stats


haproxy的status的访问控制:

stats http-request { allow | deny | auth [realm <realm>] }

            [ { if | unless } <condition> ]


stats refresh <delay> 指定stats多久自动刷新

stats hide-version  隐藏haproxy版本.


stats auth <user>:<passwd> 认证


stats admin { if | unless } <cond> 启动管理接口

stats admin if LOCALHOST 表示本机

stats admin if TRUE 表示认证通过


实例:

backend servers

       cookie node insert nocache

       balance roundrobin

       stats enable

       stats refresh 20s

       stats hide-version

       stats admin if TRUE

       stats auth admin:admin

       stats uri /hastatus

       server  node1   192.168.30.129:80       check   cookie node1

       server  node2   192.168.30.131:80       check   cookie node2  


自定义错误页面:

errorfile 

errorloc302

errorloc303


errorfile <code> <file>


http-request { allow | deny | tarpit | auth [realm <realm>] | redirect <rule> |

             add-header <name> <fmt> | set-header <name> <fmt> |

             del-header <name> | set-nice <nice> | set-log-level <level> |

             replace-header <name> <match-regex> <replace-fmt> |

             replace-value <name> <match-regex> <replace-fmt> |

             set-tos <tos> | set-mark <mark> |

             add-acl(<file name>) <key fmt> |

             del-acl(<file name>) <key fmt> |

             del-map(<file name>) <key fmt> |

             set-map(<file name>) <key fmt> <value fmt>

            }

            [ { if | unless } <condition> ]


haproxy封装客户端ip,新增x-forward-for,避免总是记录haproxy,转而记录client ip。

option forwardfor [ except <network> ] [ header <name> ] [ if-none ]


keepalive 关闭有两种原因:

1、当前服务器的连接数达到上限。

2、连接超时.


timeout queue <timeout> 默认为1m

请求在队列中等待的最大时间长,一直得不到服务的响应,客户端重新发送请求.


timeout connect <timeout> 默认为10s

通常指haproxy将请求转发至后台upstream server时,所等待的超时时常.


timeout client <timeout>

客户的最大非活动连接的最大时长,指定时长后将断开连接.


timeout server <timeout>

连接已经建立,但是服务端没有任何数据传输的超时时长。


timeout http-keep-alive <timeout>

定义保持连接模式的超时时长


timeout check <timeout>

定义健康状态检测的超时时长


option http-server-clone 

定义了keepalive功能,客户端和服务器端之间的会话连接超时,允许server主动关闭.


客户端可服务器端建立连接时,就开始记录日志。(通常都是服务器端相应完成才记录日志,方便记录服务器的相应时间),如果打开此项,会提前记录日志.

option logasap

no option logasap

Enable or disable early logging of HTTP requests


客户端和服务器端连接建立,但是没有任何的数据传输,即空连接,此项为不记录空连接日志.

option dontlognull

no option dontlognull

Enable or disable logging of null connections


HAProxy Acl定义:

支持的值大概有四种:

整数或整数范围/字符串/正则表达式/ip地址或者网络地址


4层访问控制:

tcp-request content <action> [{if | unless} <condition>]

tcp-request inspect-delay <timeout>


7层访问控制:

http-request { allow | deny | tarpit | auth [realm <realm>] | redirect <rule> |

              add-header <name> <fmt> | set-header <name> <fmt> |

              del-header <name> | set-nice <nice> | set-log-level <level> |

              replace-header <name> <match-regex> <replace-fmt> |

              replace-value <name> <match-regex> <replace-fmt> |

              set-tos <tos> | set-mark <mark> |

              add-acl(<file name>) <key fmt> |

              del-acl(<file name>) <key fmt> |

              del-map(<file name>) <key fmt> |

              set-map(<file name>) <key fmt> <value fmt>

             }

             [ { if | unless } <condition> ]



本文转自青衫解衣 51CTO博客,原文链接:http://blog.51cto.com/215687833/1954400

相关实践学习
SLB负载均衡实践
本场景通过使用阿里云负载均衡 SLB 以及对负载均衡 SLB 后端服务器 ECS 的权重进行修改,快速解决服务器响应速度慢的问题
负载均衡入门与产品使用指南
负载均衡(Server Load Balancer)是对多台云服务器进行流量分发的负载均衡服务,可以通过流量分发扩展应用系统对外的服务能力,通过消除单点故障提升应用系统的可用性。 本课程主要介绍负载均衡的相关技术以及阿里云负载均衡产品的使用方法。
相关文章
|
8月前
|
应用服务中间件 nginx
Nginx的referer参数的用法和原理
总结:referer参数可以用于Nginx配置,以限制或允许特定来源网站的访问,提高安全性或控制流量。它通过valid_referers指令来定义合法的Referer来源,并根据配置对请求进行处理。但需要注意,Referer字段内容可以被伪造,因此不应作为唯一的安全措施。
983 0
|
8月前
|
存储 负载均衡 网络协议
Nginx反向代理与系统参数配置conf原理
Nginx反向代理与系统参数配置conf原理
115 0
|
8月前
|
应用服务中间件 nginx
4.5.1 Nginx反向代理与系统参数配置conf原理
4.5.1 Nginx反向代理与系统参数配置conf原理
|
缓存 网络协议 应用服务中间件
Nginx 基本原理与最小配置
Nginx 基本原理与最小配置
178 1
Nginx 基本原理与最小配置
|
NoSQL 应用服务中间件 Redis
【Nginx】第七章 Nginx原理与优化参数配置
【Nginx】第七章 Nginx原理与优化参数配置
144 0
|
监控 负载均衡 网络协议
|
应用服务中间件 nginx
Nginx 模块的工作原理
Nginx 模块的工作原理  Handlers :(处理器模块)此模块直接处理请求 并且进行内容传输以及修改headres信息等操作。Handlers模块只能处理一个。 Filters(处理器模块):此类模块只需要对其他服务器模块输出的内容进行修改操做,最后又Nginx操做 proxies(代理模块):此模块是Nginx的htttp upstream之类的模块。
824 0
|
应用服务中间件 nginx
nginx的巧妙用法
本人博客 http://blog.teier.cn
1180 0