HAProxy使用详解,HAproxy实现反向代理和负载均衡

2019-08-25 00:42 来源:未知

HAProxy使用详解

HAProxy详解

HAProxy是免费、极速且可靠的用于为TCP和基于HTTP应用程序提供高可用、负载均衡和代理服务的解决方案,尤其适用于高负载且需要持久连接或7层处理机制的web站点。HAProxy还可以将后端的服务器与网络隔离,起到保护后端服务器的作用。HAProxy的负载均衡能力虽不如LVS,但也是相当不错,而且由于其工作在7层,可以对http请求报文做深入分析,按照自己的需要将报文转发至后端不同的服务器(例如动静分离),这一点工作在4层的LVS无法完成。

安装配置HAproxy

HAProxy已经集成在base源中,可直接通过yum下载。

[[email protected] ~]# 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}

反向代理服务器功能:web缓存(加速)、反向代理、内容路由(根据流量及内容类型等将请求转发至特定服务器)、转码器

--------------------------------------分割线

Haproxy Keepalived搭建Weblogic高可用负载均衡集群

Keepalived HAProxy配置高可用负载均衡

CentOS 6.3下Haproxy Keepalived Apache配置笔记

Haproxy KeepAlived 实现WEB群集 on CentOS 6

Haproxy Keepalived构建高可用负载均衡

使用 HAProxy 配置 HTTP 负载均衡器

缓存:减少冗余内容传输;节省带宽、缓解网络瓶颈;降低了对原始服务器的请求压力;降低了传输延迟,公共缓存每个人都可以使用,带有敏感数据的私有缓存则只对限定某类或某个人使用

--------------------------------------分割线

下面介绍一些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)上配置测试页面:

[[email protected] ~]# vim /web/index.html

<h2>server node1</h2>

在app1(192.168.2.18)上:

[[email protected] ~]# vim /web/index.html

<h2>server node2</h2>

在代理服务器上有两个接口:192.168.1.116(面向客户端),192.168.2.11。配置完成后启动haproxy服务。后端节点上启动nginx服务。

图片 1图片 2

已实现轮询访问。

在上述的算法中涉及到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服务。然后访问定义的路径:

图片 3图片 4

基于前面配置完成的健康状态检测,现在停止其中一台后端服务器的nginx服务。

[[email protected] web]# service nginx stop

Stopping nginx:                                            [  OK  ]

图片 5

红色表示服务不在线,若停止所有后端服务器的服务,则会访问定义为backup的server(127.0.0.1上的sorry页面)。

图片 6

图片 7

更多详情见请继续阅读下一页的精彩内容:

  • 1
  • 2
  • 下一页

HAProxy详解 HAProxy是免费、极速且可靠的用于为TCP和基于HTTP应用程序提供高可用、负载均衡和代理服务的解决方案,尤其适用...

nginx可实现缓存功能,haproxy不能实现缓存功能,这里只说明其反向代理功能和负载均衡功能

yum install haproxy
主配置文件haproxy.cfg
开启日志功能:
编辑/etc/rsyslog.conf文件
$ModLoad imudp
$UDPServerRun 514  #开启udp514端口
local2.*                                                /var/log/haproxy.log
编辑/etc/haproxy/haproxy.cfg文件:
log        127.0.0.1 local2
 
配置负载均衡后端主机:
global
    log        127.0.0.1 local2
 
    chroot      /var/lib/haproxy
    pidfile    /var/run/haproxy.pid
    maxconn    4000  定义面向客户端的总的最大连接数(面向客户端那一面)
    user        haproxy
    group      haproxy
    daemon
    # turn on stats unix socket
    stats socket /var/lib/haproxy/stats
 
#---------------------------------------------------------------------
# main frontend which proxys to the backends
#---------------------------------------------------------------------
frontend  main *:80  #第一种方式
#        bind *:80    #第二种方式
#        bind *:8080    #只能用于frontend, listen;
#        maxconn  也可以定义在这里或listen后,定义了单个实例的最大并发连接数,如果在global段定义就是所有实例总的
  default_backend            websrvs
#---------------------------------------------------------------------
# round robin balancing between the various backends
#---------------------------------------------------------------------
backend websrvs
    balance    roundrobin
    server  web1 192.168.20.7:80 check #定义的名字web1会被加到请求首部发到后端,当后端有虚拟主机时很有用
    server  web2 192.168.20.8:80 check

几种调度算法:

balance: 指明调度算法;
    动态:权重可动态调整
    静态:调整权重不会实时生效
        roundrobin: 轮询,动态算法,每个后端主机最多支持4128个连接;
        static-rr: 轮询,静态算法,每个后端主机支持的数量无上限;
        leastconn: 根据后端主机的负载数量进行调度;仅适用长连接的会话;动态;
hash-type:
    map-based:取模法;静态;
    consistent:一致性哈希法;动态;

下面的四种调度算法都基于上面的两种hash-type

        source:
        uri:对uri的左半部分(?标记之前的部分)或者整个uri做hash,除以后端服务器总权重后绑定到后端服务器
        url_param: 根据url中的指定的参数的值进行调度;把值做hash计算,并除以总权重;
        hdr(<name>)    :根据请求报文中指定的header(如use_agent, referer, hostname)进行调度;把指定的header的值做hash计算得值除以总权重;
示例:

backend websrvs
    balance    hdr(User-Agent)
    hash-type consistent
    server  web1 192.168.20.7:80 check
    server  web2 192.168.20.8:80 check

测试:

图片 8

mode: 健康状态检测时基于何种协议
    HAProxy的工作模式;默认为tcp;有三种:tcp, http, health

    只有客户端和前端,后端都是用http通信才可以使用http模式

在front段也可以指定log:

frontend  main *:80
    log global
    log        127.0.0.2 local3

使用use_backend 和acl定义后段

use_backend    dynamic  if  url_dyn
use_backend    static  if  url_css url_img extension_img

server段后可加的参数:

backup:设定为备用服务器,仅在负载均衡场景中的其它server均不可用于启用此server;
check:启动对此server执行健康状态检查,其可以借助于额外的其它参数完成更精细的设定,如:
  inter <delay>:设定健康状态检查的时间间隔,单位为毫秒,默认为2000;也可以使用fastinter和downinter来根据服务器端状态优化此时间延迟;
  rise <count>:设定健康状态检查中,某离线的server从离线状态转换至正常状态需要成功检查的次数;
  fall <count>:确认server从正常状态转换为不可用状态需要检查的次数;
cookie <value>:为指定server设定cookie值,此处指定的值将在请求入站时被检查,第一次为此值挑选的server将在后续的请求中被选中,其目的在于实现持久连接的功能;
maxconn <maxconn>:指定此服务器接受的最大并发连接数;如果发往此服务器的连接数目高于此处指定的值,其将被放置于请求队列,以等待其它连接被释放;
maxqueue <maxqueue>:设定请求队列的最大长度;
observe <mode>:通过观察服务器的通信状况来判定其健康状态,默认为禁用,其支持的类型有“layer4”和“layer7”,“layer7”仅能用于http代理场景;
redir <prefix>:启用重定向功能,将发往此服务器的GET和HEAD请求均以302状态码响应;需要注意的是,在prefix后面不能使用/,且不能使用相对地址,以免造成循环;例如:
  server srv1 172.16.100.6:80 redir check
weight <weight>:权重,默认为1,最大值为256,0表示不参与负载均衡;

定义健康检查方式可以使用option:

option httpchk
option httpchk <uri>
option httpchk <method> <uri> 
例如:
backend https_relay
    mode tcp
    option httpchk OPTIONS * HTTP/1.1rnHost: www.linuxidc.com
    server apache1 192.168.1.1:443 check port 80
使用案例:
server first  172.16.100.7:1080 cookie first  check inter 1000
server second 172.16.100.8:1080 cookie second check inter 1000

基于浏览器cookie实现session sticky:

要点:
(1) 每个server有自己惟一的cookie标识;
(2) 在backend中定义为用户请求调度完成后操纵其cookie
backend websrvs
    balance    roundrobin
    cookie SERVERID insert nocache indirect
    server  web1 192.168.20.7:80 check cookie websrv1
    server  web2 192.168.20.8:80 check cookie websrv2

测试:注意到cookie头部的websrv1关键字了么?

图片 9

开启统计页面:

listen statistics
        bind *:9090
        stats enable
        stats hide-version
        #stats scope .
        stats uri /haproxyadmin?stats
        stats realm "HAPorxy Statistics"
        stats auth admin:mageedu
        stats admin if TRUE

图片 10

向日志中记录额外信息:
    capture request header
    capture response header

当mode为http时,记录丰富的日志信息:
    option httplog----默认是开启的

错误页面重定向:
    errorfile: 使用haproxy主机本地文件进行响应;
    errorloc, errorloc302: 使用指定的url进行响应,响应状态码为302;不适用于GET以外的其它请求方法;
    errorloc303:返回303状态码;

添加请求或响应报文首部:
    reqadd
    rspadd

frontend  main
        bind *:80
        bind *:8080
    rspadd  Via: node1.lee.com
    default_backend            websrvs

出现了Via:

图片 11

动静分离的示例:
frontend  main
    bind *:80
    bind *:8080
    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
    default_backend            appsrvs
 
#---------------------------------------------------------------------
# static backend for serving up images, stylesheets and such
#---------------------------------------------------------------------
    backend static
      balance roundrobin
      server static1 192.168.20.7 check
      server static2 192.168.20.8 check
 
    backend appsrvs
      balance    roundrobin
      option forwardfor except 127.0.0.1 header X-Client
      option httpchk
      cookie SERVERID insert indirect nocache
      server  web1 192.168.20.7:80 check cookie web1
      server  web2 192.168.20.8:80 check cookie web2

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/2016-06/132225.htm

使用 HAProxy 配置 HTTP 负载均衡器 http://www.linuxidc.com/Linux/2015-01/112487.htm

Ubuntu 16.04 下安装HAProxy 1.5.11 做tcp负载均衡 http://www.linuxidc.com/Linux/2016-06/132689.htm

HAproxy 的详细介绍:请点这里
HAproxy 的下载地址:请点这里

本文永久更新链接地址:http://www.linuxidc.com/Linux/2016-12/138749.htm

图片 12

TAG标签:
版权声明:本文由吉利彩票平台注册-吉利彩票平台官方注册-官网推荐发布于吉利彩票平台注册,转载请注明出处:HAProxy使用详解,HAproxy实现反向代理和负载均衡