设为首页 收藏本站
查看: 1756|回复: 0

[经验分享] Haproxy的基础知识介绍

[复制链接]
累计签到:1 天
连续签到:1 天
发表于 2015-6-8 08:28:54 | 显示全部楼层 |阅读模式

    在日常生活中,http主要用于做为公司的正向代理,通过SNAT技术为互联网节省了很多的IP地址,相反haproxy是作为反向代理,接收普通用户的请求。代理的作用主要有访问控制、web缓存(加速)、反向代理、内容路由(根据流量及内容类型等条件将请求转发至特定的服务器)、转码器,以及在代理服务器上添加Via首部,用于分析经过的路由等作用。目前haproxy的版本主要有两个,一个为1.4,特点是能够提供较好的弹性,还有一个版本是1.3的版本,其特性为内容交换以及超强的负载,都是衍生以1.2版本。Haproxy是http协议的反向代理,即七层反向代理,不过在tcp层支持LB。

    在Centos6.4版本后,就支持直接使用yum安装。

    安装生成的:

配置文件:/etc/haproxy/haproxy.cfg

服务脚本:/etc/rc.d/init.d/haproxy

主程序:/usr/sbin/haproxy


       在haproxy中定义反向:

frontend:定义前端服务;

backend:定义后端服务;

listen:用于定义前端的frontend以及后端的backend,而且还是一对一的对应;

default:定义默认配置;

    在haproxy中日志需要启用才会生成,在haproxy的主配置文件中有如下一行指令,是用于定义启用日志的:

             wKiom1V0QkTT_ldcAACXQcGPxhQ686.jpg



    首先定义日志文件:
[iyunv@node2~]# vim /etc/rsyslog.conf
       此项的启用,是使用udp监听:
             wKioL1V0REjQZQtkAAAzbVXUy4k956.jpg
            然后定义日志位置:

             wKioL1V0RJfQ-psgAAByxaJ_mWA707.jpg

    然后重启日志服务就会生成haproxy的日志:

             wKioL1V0ROCBa60gAAB40XYMydg237.jpg


    示例:定义一个简单的服务代理:      
        在配置中定义后端服务为appserver,以及两个后端服务器,一个后端主机位172.16.90.2还有一个172.16.90.3。
                            [
                          root@node0 ~]# vim/etc/haproxy/haproxy.cfg

               wKioL1V0RVfAzn1_AAGhSqMcnHA953.jpg
    而后,后端服务器启动http服务,就能得到代理的后面服务器的两个测试页面:


                wKiom1V0RFCSY7faAABONqhhuXs404.jpg

                wKiom1V0RGvh63cBAABH6i4rZBI789.jpg


下面说下全局配置中的一些参数:

“global”配置中的参数为进程级别的参数,且通常与其运行的OS相关。
* 进程管理及安全相关的参数
      - chroot <jail dir>:修改haproxy的工作目录至指定的目录并在放弃权限之前执行chroot()操作,可                    以提升haproxy的安全级别,不过需要注意的是要确保指定的目录为空目录且                    任何用户均不能有写权限;
     - daemon:让haproxy以守护进程的方式工作于后台,其等同于“-D”选项的功能,当然,也可以                在命令行中以“-db”选项将其禁用;
  - gid <number>:以指定的GID运行haproxy,建议使用专用于运行haproxy的GID,以免因权限问题带                 来风险;
  - group <group name>:同gid,不过指定的组名;
  - log  <address><facility> [max level [min level]]:定义全局的syslog服务器,最多可以定义两个;
  - log-send-hostname [<string>]:在syslog信息的首部添加当前主机名,可以为“string”指定的名称,                             也可以缺省使用当前主机名;
  - nbproc <number>:指定启动的haproxy进程的个数,只能用于守护进程模式的haproxy;默认只启                    动一个进程,鉴于调试困难等多方面的原因,一般只在单进程仅能打开少数文                    件描述符的场景中才使用多进程模式;
   - pidfile:pid文件,即进程文件;
  - uid:以指定的UID身份运行haproxy进程;
   - ulimit-n:设定每进程所能够打开的最大文件描述符数目,默认情况下其会自动进行计算,因此不           推荐修改此选项;
  - user:同uid,但使用的是用户名;
   - stats:
  - node:定义当前节点的名称,用于HA场景中多haproxy进程共享同一个IP地址时;
   -description:当前实例的描述信息;

      性能调整相关的参数
  - maxconn <number>:设定每个haproxy进程所接受的最大并发连接数,其等同于命令行选项                           “- n”;“ulimit -n”自动计算的结果正是参照此参数设定的;
  - maxpipes <number>:haproxy使用pipe完成基于内核的tcp报文重组,此选项则用于设定每进程所                       允许使用的最大pipe个数;每个pipe会打开两个文件描述符,因                                 此,“ulimit -n”自动计算时会根据需要调大此值;默认为maxconn/4,其通                        常会显得过大;
  - noepoll:在Linux系统上禁用epoll机制;
  - nokqueue:在BSD系统上禁用kqueue机制;
  - nopoll:禁用poll机制;
  - nosepoll:在Linux禁用启发式epoll机制;
  - nosplice:禁止在Linux套接字上使用内核tcp重组,这会导致更多的recv/send系统调用;不过,              在Linux2.6.25-28系列的内核上,tcp重组功能有bug存在;
  - spread-checks <0..50, in percent>:在haproxy后端有着众多服务器的场景中,在精确的时间间隔后                                统一对众服务器进行健康状况检查可能会带来意外问题;此选项                                 用于将其检查的时间间隔长度上增加或减小一定的随机时长;
  - tune.bufsize <number>:设定buffer的大小,同样的内存条件下,较小的值可以让haproxy有能力接                         受更多的并发连接,较大的值可以让某些应用程序使用较大的cookie信                           息;默认为16384,其可以在编译时修改,不过强烈建议使用默认值;
   -tune.chksize <number>:设定检查缓冲区的大小,单位为字节;更大的值有助于在较大的页面中完                         成基于字符串或模式的文本查找,但也会占用更多的系统资源;不建议                         修改;
  - tune.maxaccept <number>:设定haproxy进程内核调度运行时一次性可以接受的连接的个数,较大                           的值可以带来较大的吞吐率,默认在单进程模式下为100,多进程模式                           下为8,设定为-1可以禁止此限制;一般不建议修改;
  - tune.maxpollevents <number>:设定一次系统调用可以处理的事件最大数,默认值取决于OS;其                              值小于200时可节约带宽,但会略微增大网络延迟,而大于200时会                              降低延迟,但会稍稍增加网络带宽的占用量;
  - tune.maxrewrite <number>:设定为首部重写或追加而预留的缓冲空间,建议使用1024左右的大                              小;在需要使用更大的空间时,haproxy会自动增加其值;
   -tune.rcvbuf.client <number>:设定内核套接字中服务端接收缓冲的大小,单位为字节;                                      强烈推荐使用默认值;
   -tune.rcvbuf.server <number>:设定内核套接字中服务端接收缓冲的大小,单位为字节;                                      强烈推荐使用默认值;
   -tune.sndbuf.client<number>:设定内核套接字中客户端发送缓冲的大小,单位为字节;                                      强烈推荐使用默认值;
   -tune.sndbuf.server<number>:设定内核套接字中服务端发送缓冲的大小,单位为字节;                                      强烈推荐使用默认值;


代理相关的配置可以如下配置段中。

     - defaults <name>
     - frontend <name>
     - backend <name>
     - listen  <name>

    “defaults”段用于为所有其它配置段提供默认参数,这配置默认配置参数可由下一个“defaults”所重新设定。

     “frontend”段用于定义一系列监听的套接字,这些套接字可接受客户端请求并与之建立连接。

     “backend”段用于定义一系列“后端”服务器,代理将会将对应客户端的请求转发至这些服务器。

     “listen”段通过关联“前端”和“后端”定义了一个完整的代理,通常只对TCP流量有用。

     所有代理的名称只能使用大写字母、小写字母、数字、-(中线)、_(下划线)、.(点号)和:(冒号)。此外,ACL名称会区分字母大小写。

代理参数:

           balance:指明调度算法,算法可分为动态(权重可动态调整)和静态(调整权重不会实                时生效)两类
          roundrobin:基于权重进行轮叫,在服务器的处理时间保持均匀分布时,这是最平衡、最                 公平的算法。此算法是动态的,这表示其权重可以在运行时进行调整,不                   过,在设计上,每个后端服务器仅能最多接受4128个连接;
static-rr:基于权重进行轮叫,与roundrobin类似,但是为静态方法,在运行时调整其服务           器权重不会生效;不过,其在后端服务器连接数上没有限制;
leastconn: 新的连接请求被派发至具有最少连接数目的后端服务器;在有着较长时间会话          的场景中推荐使用此算法,如LDAP、SQL等,其并不太适用于较短会话的应用          层协议,如HTTP;此算法是动态的,可以在运行时调整其权重source:不建议          使用;
  source:将请求的源地址进行hash运算,并由后端服务器的权重总数相除后派发至某匹          配的服务器;这可以使得同一个客户端IP的请求始终被派发至某特定的服务            器;不过,当服务器权重总数发生变化时,如某服务器宕机或添加了新的服务          器,许多客户端的请求可能会被派发至与此前请求不同的服务器;常用于负载          均衡无cookie功能的基于TCP的协议;其默认为静态,不过也可以使用hash-type                    修改此特性;;
         hash-type:取决取模法
map-based: 静态;
consistent: 动态;
uri:对URI的左半部分(“问题”标记之前的部分)或整个URI进行hash运算,并由服务器的总      权重相除后派发至某匹配的服务器;这可以使得对同一个URI的请求总是被派发至某      特定的服务器,除非服务器的权重总数发生了变化;此算法常用于代理缓存或反病      毒代理以提高缓存的命中率;需要注意的是,此算法仅应用于HTTP后端服务器场        景;其默认为静态算法,不过也可以使用hash-type修改此特性;建议consistent的取      模法: 动态;
scheme://host:port/path/to/some_resource?#
url_param: 通过<argument>为URL指定的参数在每个HTTP GET请求中将会被检索;如果找到          了指定的参数且其通过等于号“=”被赋予了一个值,那么此值将被执行hash运          算并被服务器的总权重相除后派发至某匹配的服务器;此算法可以通过追踪请          求中的用户标识进而确保同一个用户ID的请求将被送往同一个特定的服务器,          除非服务器的总权重发生了变化;如果某请求中没有出现指定的参数或其没有          有效值,则使用轮叫算法对相应请求进行调度;此算法默认为静态的,不过其          也可以使用hash-type修改此特性;建议consistent的取模法: 动态;
hdr(<name>):对于每个HTTP请求,通过<name>指定的HTTP首部将会被检索;如果相应的              首部没有出现或其没有有效值,则使用轮叫算法对相应请求进行调度;其              有一个可选选项“use_domain_only”,可在指定检索类似Host类的首部时仅              计算域名部分(比如通过www.magedu.com来说,仅计算magedu字符串的                hash值)以降低hash算法的运算量;此算法默认为静态的,不过其也可以使             用hash-type修改此特性;
                header(host)
                        rdp-cookie
                                                   rdp-cookie(name)


       default_backend <backend>:用于frontend中,用于指明为请求提供服务的backend;
       use_backend<backend> [{if | unless} <condition>]:条件式后端指定;  <condition>由ACL定义的;
                默认的配置文件中:
                         wKiom1V0S-bhe7_hAACsiCtcfc4616.jpg      
server<name> <address>[:[port]] [param*]
             <address>:ipv4或ipv6;
                         [param*]:
                                 check:启用对server的健康状态检测功能;tcp层的监测;补充类的参数:
                                         inter:时间间隔
                                         rise:上线前的成功检查次数
                                           fall:下线前的失败检查次数                                                
                                   cookie:分配给server的cookie信息;
                                               disabled:设置服务器为“禁用”状态;
                                   maxconn:最大并发连接数;
                                   maxqueue:等待队列最大长度;0表示无上限;
                                   minconn:最少并发连接数;
                                   weight:权重;
                 例:

                     wKiom1V0TNzRTKSQAABTib5Ic74818.jpg

bind

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

此指令仅能用于frontend和listen区段,用于定义一个或几个监听的套接字。

<address>:可选选项,其可以为主机名、IPv4地址、IPv6地址或*;省略此选项、将其指定为*或0.0.0.0时,将监听当前系统的所有IPv4地址;
<port_range>:可以是一个特定的TCP端口,也可是一个端口范围(如5005-5010),代理服务器将通过指定的端口来接收客户端请求;需要注意的是,每组监听的套接字<address:port>在同一个实例上只能使用一次,而且小于1024的端口需要有特定权限的用户才能使用,这可能需要通过uid参数来定义;
<interface>:指定物理接口的名称,仅能在Linux系统上使用;其不能使用接口别名,而仅能使用物理接口名称,而且只有管理有权限指定绑定的物理接口;


            mode: 指明haproxy代理模式,默认为tcp:
                           tcp:实例运行于纯TCP模式,在客户端和服务器端之间将建立一个全双工的连接,且不会                   对7层报文做任何类型的检查;此为默认模式,通常用于SSL、SSH、SMTP等应用;                 http:实例运行于HTTP模式,客户端请求在转发至后端服务器之前将被深度分析,所有不                    与RFC格式兼容的请求都会被拒绝;

             健康检查方法:
optionhttpchk
optionhttpchk <uri>
optionhttpchk <method> <uri>
option httpchk <method><uri> <version>:不能用于frontend段,例如:

backendhttps_relay
    mode tcp
    option httpchk OPTIONS * HTTP/1.1\r\nHost:\www.magedu.com
    server apache1 192.168.1.1:443 check port80
statsenable
启用基于程序编译时默认设置的统计报告,不能用于“frontend”区段。只要没有另外的其它设定,它们就会使用如下的配置:

- stats uri   : /haproxyadmin?stats  改变路径,更改后访问路径会改变
- stats realm : "\HAProxy\ Statistics" 提示信息
  - stats auth : no authentication
  - stats scope : no restriction  
  -stats hide-version  隐藏版本信息;

-stats admin { if | unless } <cond>

在指定的条件满足时启用统计报告页面的管理级别功能,它允许通过web接口启用或禁用服务器,不过,基于安全的角度考虑,统计报告页面应该尽可能为只读的。此外,如果启用了HAProxy的多进程模式,启用此管理级别将有可能导致异常行为。
backendstats_localhost
    stats enable
    stats admin if LOCALHOST
backendstats_auth
    stats enable
    stats auth haproxyadmin:password
    stats admin if TRUE
                  例:
                      wKioL1V0T1OyyoMGAACMucuIyAs779.jpg
                      wKiom1V0TiCxZWkyAATcgf0CsLI207.jpg

尽管“stats enable”一条就能够启用统计报告,但还是建议设定其它所有的参数,以免其依赖于默认设定而带来非期后果。下面是一个配置案例。

  backend public_www
    server websrv1 172.16.100.11:80
    stats enable
    stats hide-version
    stats scope   .
    stats uri     /haproxyadmin?stats
    stats realm   Haproxy\ Statistics
    stats auth    statsadmin:password
    stats auth    statsmaster:password

          haproxy cookie sticky:基于cookie的粘性,绑定服务器
                         cookie:Enable cookie-based persistence in a backend.

                         具体实现方式:
                         backendappsrvs
                           balance     roundrobin
                           optionhttpchk
cookie SERVERID insert indirect nocache  (以cookie名 SERVERID来插入web信息,nocache表示不缓存敏感数据)
    server web1 172.16.100.7:80 check inter 2 rise 1 fall 3 cookie web1
    server web2 172.16.100.8:80 check inter 2 rise 1 fall 3 cookie web2

          option选项:
      optionforwardfor [ except <network> ] [ header <name> ] [ if-none ]
          定义转发首部,即转发真正的客户端首部到服务器端;可以用于frontend、backend、default、listen
            Enable insertion of the X-Forwarded-For header to requests sent toservers

例:在haproxy服务器上,定义在backend中,添加option  forwardfor;
         wKioL1V0UVWTps5YAADxYhbONL4068.jpg
        更改后端上游服务器的日志格式,,用于记录首部信息需要查看的可以更改:            
wKiom1V0T_6hxEJcAAC1YvP9VNM495.jpg
      得到来自真实客户端的IP:


       wKiom1V0UHGDB9qkAAEQhJ2wHH8094.jpg                  option http-servrt-close:当选择长了连接时启用,服务器端主动把后端连接关闭,否则会长                                  时间占据后端服务器端的连接;
         option http-pretend-keepalive 假装长连接。即,由于后端服务器不支持长连接,而客户端与前端                                                HAproxy服务器端是长连接,若后端反馈给前端的是已断开,则前端也会                                          断开连接,此命令就是用于假装后端还是连着。当前端发出请求时,后                                          端服务器可再次启用。

haproxy的acl:

haproxy的ACL用于实现基于请求报文的首部、响应报文的内容或其它的环境状态信息来做出转发决策,这大大增强了其配置弹性。其配置法则通常分为两步,首先去定义ACL,即定义一个测试条件,而后在条件得到满足时执行某特定的动作,如阻止请求或转发至某特定的后端。定义ACL的语法格式如下。

  acl <aclname> <criterion> [flags][operator] <value> ...

  <aclname>:ACL名称,区分字符大小写,且其只能包含大小写字母、数字、-(连接线)、_(下划线)、                 .(点号)和:(冒号);haproxy中,acl可以重名,这可以把多个测试条件定义为一个共同的acl;
  <criterion>:测试标准,即对什么信息发起测试;测试方式可以由[flags]指定的标志进行调整;而有些测             试标准也可以需要为其在<value>之前指定一个操作符[operator];
  [flags]:目前haproxy的acl支持的标志位有3个:
   -i:不区分<value>中模式字符的大小写;
    -f:从指定的文件中加载模式;
    --:标志符的强制结束标记,在模式中的字符串像标记符时使用;
  <value>:acl测试条件支持的值有以下四类:
                   整数或整数范围:如1024:65535表示从1024至65535;仅支持使用正整数(如果出现类似小数的           标识,其为通常为版本测试),且支持使用的操作符有5个,分别为    eq、ge、gt、le和lt;
   字符串:支持使用“-i”以忽略字符大小写,支持使用“\”进行转义;如果在模式首部出现了-i,可以在           其之前使用“--”标志位;
    正则表达式:其机制类同字符串匹配;
    IP地址及网络地址

同一个acl中可以指定多个测试条件,这些测试条件需要由逻辑操作符指定其关系。条件间的组合测试关系有三种:“与”(默认即为与操作)、“或”(使用“||”操作符)以及“非”(使用“!”操作符)。

5.1 常用的测试标准(criteria)

5.1.1 be_sess_rate<integer>

be_sess_rate(backend)<integer>

用于测试指定的backend上会话创建的速率(即每秒创建的会话数)是否满足指定的条件;常用于在指定backend上的会话速率过高时将用户请求转发至另外的backend,或用于阻止攻击行为。例如:

    backend dynamic
     mode http
      acl being_scanned be_sess_rate gt 50
     redirect location/error_pages/denied.html if being_scanned

5.1.2 fe_sess_rate<integer>

fe_sess_rate(frontend)<integer>

用于测试指定的frontend(或当前frontend)上的会话创建速率是否满足指定的条件;常用于为frontend指定一个合理的会话创建速率的上限以防止服务被滥用。例如下面的例子限定入站邮件速率不能大于50封/秒,所有在此指定范围之外的请求都将被延时50毫秒。

    frontend mail
        bind :25
        mode tcp
        maxconn 500
        acl too_fast fe_sess_rate ge 50
        tcp-request inspect-delay 50ms
        tcp-request content accept if !too_fast
        tcp-request content accept if WAIT_END

5.1.3 hdr<string>

hdr(header)<string>

用于测试请求报文中的所有首部或指定首部是否满足指定的条件;指定首部时,其名称不区分大小写,且在括号“()”中不能有任何多余的空白字符。测试服务器端的响应报文时可以使用shdr()。例如下面的例子用于测试首部Connection的值是否为close。

    hdr(Connection) -i close

5.1.4 method<string>

method<string>

测试HTTP请求报文中使用的方法。

5.1.5 path_beg<string>

用于测试请求的URL是否以<string>指定的模式开头。下面的例子用于测试URL是否以/static、/images、/javascript或/stylesheets头。

    acl url_static       path_beg       -i /static /images /javascript/stylesheets

5.1.6 path_end<string>

用于测试请求的URL是否以<string>指定的模式结尾。例如,下面的例子用户测试URL是否以jpg、gif、png、css或js结尾。

    acl url_static       path_end       -i .jpg .gif .png .css .js
5.1.7 hdr_beg<string>

用于测试请求报文的指定首部的开头部分是否符合<string>指定的模式。例如,下面的例子用记测试请求是否为提供静态内容的主机img、video、download或ftp。

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

5.1.8 hdr_end<string>

用于测试请求报文的指定首部的结尾部分是否符合<string>指定的模式。例如,下面的例子用记测试请求是否为


动静分离的示例:
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
#---------------------------------------------------------------------
backendstatic
    balance roundrobin
    server static1 172.16.100.11 check
    server static2 172.16.100.12 check

backendappsrvs
    balance    roundrobin
    option forwardfor except 127.0.0.1 headerX-Client
    option httpchk
    cookie SERVERID insert indirect nocache
    server web1 172.16.100.7:80 check cookie web1
    server web2 172.16.100.8:80 check cookieweb2        


运维网声明 1、欢迎大家加入本站运维交流群:群②:261659950 群⑤:202807635 群⑦870801961 群⑧679858003
2、本站所有主题由该帖子作者发表,该帖子作者与运维网享有帖子相关版权
3、所有作品的著作权均归原作者享有,请您和我们一样尊重他人的著作权等合法权益。如果您对作品感到满意,请购买正版
4、禁止制作、复制、发布和传播具有反动、淫秽、色情、暴力、凶杀等内容的信息,一经发现立即删除。若您因此触犯法律,一切后果自负,我们对此不承担任何责任
5、所有资源均系网友上传或者通过网络收集,我们仅提供一个展示、介绍、观摩学习的平台,我们不对其内容的准确性、可靠性、正当性、安全性、合法性等负责,亦不承担任何法律责任
6、所有作品仅供您个人学习、研究或欣赏,不得用于商业或者其他用途,否则,一切后果均由您自己承担,我们对此不承担任何法律责任
7、如涉及侵犯版权等问题,请您及时通知我们,我们将立即采取措施予以解决
8、联系人Email:admin@iyunv.com 网址:www.yunweiku.com

所有资源均系网友上传或者通过网络收集,我们仅提供一个展示、介绍、观摩学习的平台,我们不对其承担任何法律责任,如涉及侵犯版权等问题,请您及时通知我们,我们将立即处理,联系人Email:kefu@iyunv.com,QQ:1061981298 本贴地址:https://www.yunweiku.com/thread-74838-1-1.html 上篇帖子: haproxy配置时 刷新多几次 会出现503错误页面 下篇帖子: HAProxy基础知识整理 基础知识
您需要登录后才可以回帖 登录 | 立即注册

本版积分规则

扫码加入运维网微信交流群X

扫码加入运维网微信交流群

扫描二维码加入运维网微信交流群,最新一手资源尽在官方微信交流群!快快加入我们吧...

扫描微信二维码查看详情

客服E-mail:kefu@iyunv.com 客服QQ:1061981298


QQ群⑦:运维网交流群⑦ QQ群⑧:运维网交流群⑧ k8s群:运维网kubernetes交流群


提醒:禁止发布任何违反国家法律、法规的言论与图片等内容;本站内容均来自个人观点与网络等信息,非本站认同之观点.


本站大部分资源是网友从网上搜集分享而来,其版权均归原作者及其网站所有,我们尊重他人的合法权益,如有内容侵犯您的合法权益,请及时与我们联系进行核实删除!



合作伙伴: 青云cloud

快速回复 返回顶部 返回列表