关于haproxy

高性能负载均衡软件 haproxy

一、四层和七层负载均衡的区别：

　　所谓的四层就是OSI参考模型中的第四层，四层负载均衡也称为四层交换机，他主要是通过分析IP层及TCP/UDP层的流量实现的基于IP加端口的负载均衡。常见的基于四层的负载均衡器有LVX、F5（商业的，并且也支持七层负载均衡）等。

　　他们向下支持的，so 七层是从一层到七层的功能都支持的。

　　以常见的TCP应用为例，负载均衡器在接收到第一个来自客户端的SYN请求时，会通过设定的负载均衡算法选择一个最佳的后端服务器，同时将报文中目标IP地址修改为后端服务器IP，然后直接转发给该后端服务器，这样一个负载均衡请求就完成了。从这个过程来看，一个TCP连接是客户端和服务器直接建立的，而负载均衡器只不过完成了一个类似路由器的转发动作。在某些负载均衡策略中，为保证后端服务器返回的报文可以正确传递给负载均衡器，在转发报文的同时可能还会对报文原来的源地址进行修改，整个过程如下图：

　　同理，七层负载均衡器也称为七层交换机，位于OSI的最高层，即应用层，此时负载均衡器支持多种应用协议，常见的有HTTP、FTP、SMTP等。七层负载均衡器可以根据报文内容，再配合负载均衡算法来选择后端服务器，因此也称为“内容交换器”。比如，对于Web服务器的负载均衡，七层负载均衡器不但可以根据“IP+端口”的方式进行负载分流，还可以根据网站的URL、访问域名、浏览器类别、语言等决定负载均衡的策略。例如，有两台

web服务器分别对应中英文两个网站，两个域名分别是A、B，要实现访问A域名时进入中文网站，访问B域名时进入英文网站，这在四层负载均衡器中几乎是无法实现的，而七层负载均衡可以根据客户端访问域名的不同选择对应的网页进行负载均衡处理。常见的七层负载均衡器有HAproxy、Nginx等。

　　这里仍以常见的TCP应用为例，由于负载均衡器要获取到报文的内容，因此只能先代替后端服务器和客户端建立连接，接着才能收到客户端发送过来的报文内容，然后再根据该报文中特定字段加上负载均衡器中设置的负载均衡算法来决定最终选择的内部服务器。纵观整个过程，七层负载均衡器在这种情况下类似于一个代理服务器。整个过程如下图：

　　对比四层负载均衡和七层负载均衡运行的整个过程，可以看出在七层负载均衡模式下，负载均衡器与客户端及后端的服务器会分别建立一个TCP连接，而在四层负载均衡模式下，仅建立一个TCP连接。由此可知，七层负载均衡对负载均衡设备的要求更高（因为他要建立2个TCP连接），而七层负载均衡的处理能力也必然低于四层模式的负载均衡。四层返回数据有两种模式：后端服务器直接返回给客户端，和经过负载均衡器给客户端。所以四层的处理能力高。

二、HAProxy与LVS的异同：

　　1、两者都是软件负载均衡产品，但是LVS是基于Linux操作系统实现的一种负载均衡，而HAProxy是基于第三方应用实现的负载均衡，跟操作系统内核没有关系的；

　　2、LVS是基于四层的IP负载均衡技术，而HAProxy是基于四层和七层技术可提供TCP和HTTP应用的负载均衡综合解决方案；

　　3、LVS工作在OSI模型的第四层，因此其状态监测功能单一，而HAProxy在状态监测方面功能强大，可支持端口、URL、域名、脚本等多种状态监测方式；

　　4、HAProxy虽然功能强大，但是整体处理性能低于四层模式的LVS负载均衡，而LVS拥有接近硬件设备的网络吞吐和连接负载能力。

　　综上所诉，HAProxy和LVS各有优缺点，没有好坏之分，要选择哪个作为负载均衡器，要以实际的应用环境来决定。

三、快速安装HAProxy集群软件：

　　HAProxy的官网： http://www.haproxy.org/ 下载HAProxy的源码包

　　解压：tar -xvzf haproxy-1.8.19.tar.gz

　　进入目录：cd haproxy-1.8.19

　　根据内核版本，选择编译参数，查看内核版本：uname -r
　　　　3.10.0-327.el7.x86_64

　　查看编译参数：

　　根据你的平台设置参数TARGET，设置安装路径参数PREFIX，执行编译：

　　　　前提需要安装yum -y install gcc

make TARGET=linux2628 PREFIX=/opt/haproxy 指定Linux内核、软件安装路径

make install PREFIX=/opt/haproxy

　　添加haproxy到systemd中
　　在haproxy-1.8.19/中有systemd脚本可以使用：

cd haproxy-1.8.19/contrib/systemd/
make PREFIX=/opt/haproxy
　　sed -e 's:@SBINDIR@:'/opt/haproxy/sbin':' haproxy.service.in > haproxy.service
cp haproxy.service /lib/systemd/system/

　　上一步执行完成后，可以使用systemctl启动和关闭haproxy了:

systemctl start haproxy
systemctl stop haproxy
systemctl restart haproxy
systemctl reload haproxy

　　最后，记得新建一个配置文件并且填写正确的配置信息，才能够启动

　　HAProxy默认不创建配置文件目录，需要自己创建：

mkdir -p /etc/haproxy/conf

　　HAProxy安装完成后，默认安装目录中没有配置文件，这里将源码包李的示例配置文件拷贝到配置文件目录：

cp examples/option-http_proxy.cfg /etc/haproxy/conf/haproxy.cfg

　　这样，HAProxy就安装完成了。

四、HAProxy基础配置文件详解：

　　HAProxy配置文件根据功能和用途，主要有5个部分组成，但有些部分并不是必须的，可以根据需要选择相应的部分进行配置。

　　（1）global部分：

　　用来设定全局配置参数，属于进程级的配置，通常和操作系统配置有关。

　　（2）defaults部分：

　　默认参数的配置部分。在此部分设置的参数值，默认会自动被引用到下面的frontend、backend和listen部分中，因此，如果某些参数属于公用的配置，只需在defaults部分添加一次即可。而如果在frontend、backend和listen部分中也配置了与defaults部分一样的参数，那么defaults部分参数对应的值自动被覆盖。

　　（3）frontend部分：

　　此部分用于设置接收用户请求的前端虚拟节点。frontend是在HAProxy1.3版本之后才引入的一个组件，同时引入的还有backend组件。通过引入这些组件，在很大程度上简化了HAProxy配置文件的复杂性。frontend可以根据ACL规则直接指定要使用的后端backend。

　　（4）backend部分：

　　此部分用于设置集群后端服务集群的配置，也就是用来添加一直真实服务器，以处理前端用户的请求。添加的真实服务器类似于LVS中的realserver节点。

　　（5）listen部分：

　　此部分是frontend部分和backend部分的综合体。在HAProxy1.3版本之前，HAProxy的所有配置选项都在这个部分中设置，为了保持兼容性，HAProxy新的版本仍然保留了listen组件的配置方式。目前在HAProxy中，两种配置方式任选其一即可。

五、HAProxy配置文件详解：

　　（1）global部分：

global

    log         127.0.0.1 local0 warning  #定义全局日志, 配置在本地, 通过local0 输出, 默认是info级别，可配置两条
　　　　　　　　   这个配置表示使用127.0.0.1上的rsyslog服务中的local0日志设备，记录日志等级为warning。

    #log        127.0.0.1 local1 info     #定义日志级别【error warning info debug】debug收集的日志最多

    chroot      /usr/local/haproxy        #运行路径

    pidfile     /var/run/haproxy.pid      #PID 文件存放路径

    maxconn     4096     　　　　　　　     #设置每个haproxy进程的最大并发连接数, 其等同于命令行“ulimit -n”自动计算的结果参照此参数设定.否则不生效

    user        haproxy                   #运行haproxy 用户, 或者使用关键字uid

    group       haproxy                   #运行haproxy 用户组, 或者使用关键字gid

    daemon                                #后台运行haproxy进程，推荐的运行模式。

    #设置启动的haproxy可创建的进程数量, 只能用于守护进程模式的haproxy;

    #默认只启动一个进程, 鉴于调试困难等多方面的原因, 一般只在单进程仅能打开少数文件描述符的场景中才使用多进程模式.
    #一般该值的设置应小于服务器的CPU物理核数，如果创建多个进程能减少每个进程的任务队列，但过多进程可能会导致进程崩溃。

    nbproc      1                           #HAProxy默认会启动一个进程，如果访问量增大时，可以增加这个值。

    #ulimit-n 819200    #设置每进程所能够打开的最大文件描述符数目, 默认情况其会自动进行计算, 因此不推荐修改此选项.

    #debug              #调试级别, 一般只在开启单进程时调试, 且生产环境禁用.

    #quiet              #haproxy启动后不会显示任何相关信息, 这与在命令行启动haproxy时加上参数“-q”相同

    stats socket /usr/local/haproxy/stats   #定义统计信息保存位置

　　（2）defaults部分：

defaults

    mode        http         #默认的模式【tcp:4层； http:7层； health:只返回OK】
　　     tcp模式：客户端和服务器端之间将建立一个全双工的连接，不会对七层报文做任何类型的检查，默认为tcp模式，经常用于SSL、SSH、SMTP等应用。
        http模式：客户端请求在转发至后端服务器之前将会被深度分析，所有不与RFC格式兼容的请求都会被拒绝。
        health模式：目前基本不用了。

    log         global       #继承全局的日志定义输出

    option      httplog      #日志类别, httplog。默认情况下，haproxy日志不记录HTTP请求的，这样很不方便HAProxy问题的排查与监控。通过此选项启用日志记录HTTP请求。

    #如果后端服务器需要记录客户端真实ip, 需要在HTTP请求中添加”X-Forwarded-For”字段;
    #由于haproxy工作于反向代理模式，因此发往后端真实服务器的请求中的客户端IP均为haproxy主机的IP，而非真正访问客户端的地址，就导致真实服务器端无法记录客户端真正请求来源的IP，
     而“X-Forwarded-For”则可用于解决此问题。通过使用“forwardedfor”选项，haproxy就可以向每个发往后端真实服务器的请求添加“X-Forwarded-For”记录，
     这样后端真实服务器日志可以通过“X-Forwarded-For”信息来记录客户端来源IP。

    #option      forwardfor except 127.0.0.0/8    #但haproxy自身的健康检测机制访问后端服务器时, 不应将记录访问日志，可用except来排除127.0.0.0，即haproxy本身.

    option      forwardfor 

    option      httpclose       #开启http协议中服务器端关闭功能, 每个请求完毕后主动关闭http通道, 使得支持长连接，使得会话可以被重用，使得每一个日志记录都会被记录.

    option      dontlognull     #如果产生了一个空连接，那这个空连接的日志将不会记录.

    #当与后端服务器的会话失败(服务器故障或其他原因)时, 把会话重新分发到其他健康的服务器上; 当故障服务器恢复时, 会话又被定向到已恢复的服务器上;

    #还可以用”retries”关键字来设定在判定会话失败时的尝试连接的次数

    retries     3
    option      redispatch          #此参数用于cookie保持的环境中。
    #默认情况下，haproxy会将其请求的后端服务器的serverID插入到cookie中，以保证会话的session持久性。
    #而如果后端的服务器出现故障，客户端的cookie是不会刷新的，这就出现了问题。此时，如果设置此参数，就会将客户的请求强制定向到另外一个健康的后端服务器上，以保证服务的正常。

    option      abortonclose        #这是一个性能参数，当haproxy负载很高时, 自动结束掉当前队列处理比较久的链接。

    timeout http-request    10s     #默认http请求超时时间，默认单位时毫秒。

    timeout queue           1m      #默认队列超时时间, 后端服务器在高负载时, 会将haproxy发来的请求放进一个队列中.

    timeout connect         5s      #haproxy与后端服务器连接超时时间.

    timeout client          1m      #客户端与haproxy连接后, 数据传输完毕, 不再有数据传输, 即非活动连接的超时时间.

    timeout server          1m      #haproxy与后端服务器非活动连接的超时时间.

    timeout http-keep-alive 10s     #默认新的http请求连接建立的超时时间，时间较短时可以尽快释放出资源，节约资源.

    timeout check           10s     #心跳检测超时时间

    maxconn                 2000    #最大并发连接数

    #balance source                 #设置默认的负载均衡方式

    #balnace leastconn

　　（3）frontend部分：

frontend HAproxy_Cluster          #frontend, 名字自定义

    bind 0.0.0.0:80               #定义前端监听端口, 建议采用bind *:80的形式，否则做集群高可用的时候有问题，vip切换到其余机器就不能访问.
         bind只能在frontend和listen部分进行定义，用于定义一个或几个监听的套接字，格式：bind address:port_range interface
         其中address为可选项，其可以为主机名或IP地址，如果将其设置为“*”或“0.0.0.0”，将监听当前系统的所有IPv4地址；
　　　　　 port_range可以是一个特定的TCP端口，也可以是一个端口范围，小于1024的端口需要有特定权限的用户才能使用。
         interface为可选项，用来指定网络接口的名称，只能在Linux系统上使用。 
 

    acl php_web url_reg /*.php    #acl后面是规则名称，当请求的url末尾是以.php结尾时,匹配触发php_web规则，以下两种写法均可.

    #当请求的url末尾是以.css、.jpg、.png、.jpeg、.js、.gif结尾时，匹配并触发static_web规则.

    #acl static_web path_end .gif .png .jpg .css .js .jpeg

    #acl static_web url_reg /*.(css|jpg|png|jpeg|js|gif)$

    #-i为忽略大小写，当被请求的是以www.test.com开头的主机时，匹配并触发dns_name规则.

    acl html_web hdr_beg(host) -i www.haproxytest.com

    #acl html_web hdr_beg(host) 10.11.4.152

    #当客户端的IP是x.x.x.x时，匹配并触发src_ip规则.

    #acl src_ip src x.x.x.x

    #如果匹配acl规则php_web，将请求转交到php_server组处理；如果匹配acl规则html_web，将请求转交到html_server组处理.

    use_backend php_server if php_web

    use_backend html_server if html_web

    #如果以上规则都不匹配时，将请求转交到default_backend组处理.

    default_backend backend_default     #指定默认的后端服务器池

　　（4）backend部分：

backend php_server     #backend后端配置, 配置php_server组与html_server组

　　 balance：此关键字用来定义负载均衡算法，目前HAProxy支持多种负载均衡算法，常用的有如下几种：
    1）roundrobin：是基于权重进行轮询调度的算法，在服务器的性能分布比较均匀的时候，这是一种最公平、最合理的算法。此算法经常使用。
    2）static-rr：也是基于权重进行轮询的调度算法，不过此算法为静态方法，在运行时调整其服务器权重不会生效。

    3）source：是基于请求源IP的算法。此算法先对请求的源IP进行hash运算，然后将结果与后端服务器的权重总数相除后转发至某个匹配的后端服务器。
              这种方式可以使同一个客户端IP的请求始终被转发到某特定的后端服务器。

    　　　　　　基于请求源IP进行hash运算匹配后端服务器组。
    4）leastconn：此算法会将新的连接请求转发到具有最少连接数目的后端服务器。在会话时间较长的场景中推荐使用此算法，例如数据库负载均衡等。
                 此算法不适合会话较短的环境中，例如基于HTTP的应用。
    5）uri：此算法会对部分或整个URI进行hash运算，再经过与服务器的总权重相除，最后转发到某台匹配的后端服务器上。
    6）uri_param：此算法会根据URL路径中的参数进行转发，这样可保证在后端真实服务器数量不变时，同一个用户的请求始终分发到同一台机器上。
    7）hdr(<name>)：此算法根据http头进行转发，如果指定的http头名称不存在，则使用roundrobin算法进行策略转发。

    balance roundrobin

    mode http

    cookie SERVERID                   #允许插入serverid到cookie中，每台服务器的serverid可在下面的server关键字中使用cookie关键字定义。
　　　　　　　　　　　　　　　　　　　　　　　启用这个选项也是为了会话保持。

    option httpchk GET /index.html    #心跳检测方式为检测后端服务器index.html文件，还有其他方式

    此选项表示启用HTTP的服务状态检测功能。HAProxy作为一款专业的负载均衡器，他支持对backend部分指定的后端服务器节点的健康检查，以保证在后端backend中某个节点不能服务时，
    把从frontend端进来的客户端请求分配至backend中其他健康节点上，从而保证整体服务的可用性。
    用法：option httpchk <method> <url> <version>
    method:表示HTTP请求的方式，常用的有OPTIONS、GET、HEAD几种方式。
           一般健康检查可以采用HEAD方式进行，而不是采用GET方式，这是因为HEAD方式没有数据返回，仅检查Response的HEAD是不是200状态。
           因此相对与GET来说，HEAD方式更快，更简单。
    url：表示要检测的URL地址，通过执行此URL，可以获取后端服务器的运行状态。在正常情况下将返回状态码200，返回其他状态码均为异常状态。
    version：指定心跳检测时的HTTP的版本号。

    #后端服务器定义, maxconn 1024表示该服务器的最大连接数, cookie 1表示serverid为1, weight代表权重(默认1，最大为265，0则表示不参与负载均衡),

    #check inter 1500是检测心跳频率, rise 2是2次正确认为服务器可用, fall 3是3次失败认为服务器不可用.

    server php1 192.168.4.171:80 maxconn 1024 cookie 1 weight 3 check inter 1500 rise 2 fall 3

    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要启用）此处指定的值将在请求入站时被检查，第一次为此值挑选的后端服务器将在后续的请求中一直被选中，
    　　        其目的在于实现持久连接的功能。上面的cookie server1 表示web1的serverid为server1.同理，cookie server2表示web2的serverid为server2.
    　　weight：设置后端真实服务器的权重，默认为1，最大值为256.权重越大分配的请求越多。设置为0表示不参与负载均衡。
    　　backup：设置后端真实服务器的备份服务器，仅仅在后端所有真实服务器均不可用的情况下才启用。一般很少设置，因为他正常是空闲的。

backend html_server

    balance source

    mode http

    server html1 192.168.4.172:80 maxconn 1024 cookie 1 weight 3 check inter 1500 rise 2 fall 3

backend backend_default

    balance source

    mode http

    server default1 192.168.4.171:80 maxconn 1024 cookie 1 weight 3 check inter 1500 rise 2 fall 3

　　（5）listen部分：

listen admin_status       #监控统计页面配置, 老版本HAProxy里frontend和backend的组合体,1.3版本后分开，监控组的名称可按需自定义

    mode http                      #配置监控运行模式

    bind 0.0.0.0:1080              #配置统计页面访问端口

    maxconn 10                     #统计页面默认最大连接数

    option httplog                 #http日志格式

    stats enable                   #开启统计

    stats hide-version             #隐藏统计页面上的haproxy版本号信息

    stats refresh 30s              #监控页面自动刷新时间

    stats uri /stats               #统计页面访问url，通过http://ip:1080/stats查看

    stats realm mCloud\ Haproxy    #统计页面密码框提示文本，即欢迎信息

    stats auth admin:admin         #监控页面的用户和密码:admin, 可设置多个用户名，每行一个。

    stats admin if TRUE            #手工启动/禁用后端服务器, 可通过web管理节点，仅在1.4.9版本后生效

    #设置haproxy错误页面

    errorfile 400 /usr/local/haproxy/errorfiles/400.http

    errorfile 403 /usr/local/haproxy/errorfiles/403.http

    errorfile 408 /usr/local/haproxy/errorfiles/408.http

    errorfile 500 /usr/local/haproxy/errorfiles/500.http

    errorfile 502 /usr/local/haproxy/errorfiles/502.http

    errorfile 503 /usr/local/haproxy/errorfiles/503.http

    errorfile 504 /usr/local/haproxy/errorfiles/504.http

listen site_status                             #监控haproxy后端服务器的监控状态

       bind 0.0.0.0:1081                       #监听端口

       mode http                               #http的7层模式

       log 127.0.0.1 local2 err                #[err warning info debug]

       monitor-uri /site_status                #网站健康检测URL，用来检测HAProxy管理的网站是否可以用，正常返回200，不正常返回503

       acl site_dead nbsrv(php_server) lt 1    #定义网站down时的策略当挂在负载均衡上的指定backend的中有效机器数小于1台时返回true

       acl site_dead nbsrv(html_server) lt 1

       acl site_dead nbsrv(backend_default)  lt 1

       monitor fail if site_dead               #当满足策略的时候返回503，网上文档说的是500，实际测试为503

       monitor-net 192.168.4.171/32            #来自192.168.4.152的日志信息不会被记录和转发

       monitor-net 192.168.4.172/32

六、HAProxy解决集群session共享问题

HAProxy两种方法保持客户端session一致：

1、用户IP识别：

　　haproxy将用户IP经过hash计算后，指定到固定的真实服务器上（类似于nginx的IP hash指令）

　　配置指令：balance source

2、cookie识别：

　　haproxy将web服务器发送给客户端的cookie中插入（或添加前缀）haproxy事先定义的后端的服务器cookieid。当请求来时根据cookieid找后端服务器。实现会话保持。

　　配置指令：cookie SESSION_COOKIE insert indirect nocache

　　　　查看cookieid是否已经加载：用firebug工具（Firefox里的插件）可以观察到用户的请求头的cookie里有类似于cookieid值。

七、启动与测试haproxy的负载均衡功能

启动与管理haproxy：

　　启动服务：/usr/local/haproxy/sbin/haproxy -f /usr/local/haproxy/conf/haproxy.cfg # -f 指定文件

　　重启服务：/usr/local/haproxy/sbin/haproxy -f /usr/local/haproxy/conf/haproxy.cfg -st cat /usr/local/haproxy/logs/haproxy.pid #haproxy进程的pid文件

　　停止服务：killall haproxy

可以通过脚本实现，类似于启动apache

实验：

4台机器CentOS7.2

haproxy：172.18.1.249

http：172.18.1.93

real：172.18.1.101

tomcat：172.18.1.109

第一台HAProxy服务器：

yum -y install gcc

tar xvzf haproxy-1.8.19.tar.gz

cd haproxy-1.8.19

make TARGET=linux2628 PREFIX=/usr/local/haproxy

make install PREFIX=/usr/local/haproxy

mkdir /usr/local/haproxy/conf

[root@localhost haproxy]# ls
conf doc sbin share
cp /root/haproxy-1.8.19/examples/option-http_proxy.cfg /usr/local/haproxy/conf/haproxy.cfg 拷贝配置文件

mkdir /usr/local/haproxy/logs

cat /usr/local/haproxy/conf/haproxy.cfg
global
        maxconn         4096                           并发连接数
        log             127.0.0.1 local0 debug     收集本机日志
        uid             nobody
        gid             nobody
　　nbproc  1                                           默认启动一个进程
        daemon
        pidfile         /usr/local/haproxy/logs/haproxy.pid

defaults
　　mode   http
　　retries  3                                 连接重试次数，状态监控
　　timeout  connect 10s
　　timeout  client 20s                  客户端连接超时
　　timeout  server 30s
　　timeout  check 5s

frontend www
　　bind  *:80                            对外服务端口是80
        mode            http
        option          httplog
        option          forwardfor       记录客户端的真实IP地址
        option          httpclose         连接成功后，主动关闭，提供性能
　　log  global

　　acl host_www hdr_dom(host) -i www.zb.com acl规则
　　acl host_img hdr_dom(host) -i img.zb.com

　　use_backend htmpool if host_www
　　use_backend imgpool if host_img
　　default_backend htmpool

backend htmpool
        mode           http
        option          redispatch
        option          abortonclose       关闭长期不使用的连接，提高性能
        #balance        static-rr
        cookie          SERVERID insert indirect nocache
        option          httpchk GET /index.html
        server 93server 172.18.1.93:80 cookie server1 weight 6 check inter 2000 rise 2 fall 3
        server 101server 172.18.1.101:80 cookie server2 weight 3 check inter 2000 rise 2 fall 3

backend imgpool
        mode            http
        option          redispatch
        option          abortonclose
        balance         static-rr                静态轮询
        cookie          SERVERID             balance生效，这行不生效，可以去掉
        option          httpchk GET /index.jsp
        server 109server 172.18.1.109:8080 cookie server3 weight 6 check inter 2000 rise 2 fall 3

listen admin_stats
        bind            0.0.0.0:9188
        mode          http
        log             127.0.0.1 local0 err
        stats           refresh 30s
        stats           uri     /haproxy-status
        stats           realm   welcome login\ Haproxy
        stats           auth    admin:admin123
        stats           hide-version
        stats           admin   if TRUE

注意HAProxy为了性能默认是不记录日志的，需要打开日志：

vi /etc/rsyslog.conf 配置两个系统日志文件

$ModLoad imudp

$UDPServerRun 514

local0.* /var/log/haproxy.log 注意日志的存放位置

local3.* /var/log/haproxy.log

$ModLoad imudp.so #provides UDP syslog reception 加载模块

$UDPServerRun 514 #start a UDP syslog server at standard port 514 UDPserver的端口

local3.* /usr/local/haproxy/logs/haproxy.log 定义两个设备local0 和local3 ，放在这个文件夹下必须关闭seLinux 否则不能记录日志

local0.* /usr/local/haproxy/logs/haproxy.log

vi /etc/sysconfig/rsyslog

SYSLOGD_OPTIONS="-c 2 -r -m 0"

重启服务：systemctl restart rsyslog

启动HAProxy：/usr/local/haproxy/sbin/haproxy -f /usr/local/haproxy/conf/haproxy.cfg

查看HAProxy服务是否启动：

ps -ef |grep haproxy
root 17935 1 0 18:02 ? 00:00:00 /usr/local/haproxy/sbin/haproxy -f /usr/local/haproxy/conf/haproxy.cfg

为了启动、停止方便可以写一个脚本：

https://blog.51cto.com/namesam/2050499

查看监控页面：

http://172.18.1.249:9188/haproxy-status

发现都down了：

在172.18.1.93 和 172.18.1.101服务器里：

安装apache

　　yum -y install httpd

　　systemctl start httpd

vi /var/www/html/index.html 配置静态页面

172.18.1.93

页面测试：

在172.18.1.109服务器里：

详细安装tomcat 参考相关博客

监控页面详解：

第二部分，通过颜色判断系统是否正常

第三部分，提供一个导入、导出功能，可以把结果导出为CSV、excel格式

前端部分frontend：

后端部分backend：

现在使用haproxy负载均衡器来提供访问：

多次刷新还是在 93这台机器上，这是为什么？

查看haproxy配置文件：

发现是因为使用的cookie会话保持，就把这个IP发出的请求都给93这台机器了

修改haproxy配置文件：

vi /usr/local/haproxy/conf/haproxy.cfg

balance static-rr 使用静态轮询模式
#cookie SERVERID insert indirect nocache

重启haproxy：

ps -ef |grep haproxy
　　root 17935 1 0 Apr16 ? 00:00:16 /usr/local/haproxy/sbin/haproxy -f /usr/local/haproxy/conf/haproxy.cfg
　　root 19498 19404 0 15:36 pts/0 00:00:00 grep --color=auto haproxy
kill -9 17935
/usr/local/haproxy/sbin/haproxy -f /usr/local/haproxy/conf/haproxy.cfg

再次访问：

　　现在就是93服务器、101服务器轮询了，不过是93服务器轮询2次，101服务器1次，因为权重是6.

这样就实现了负载均衡的功能。

问2：测试监控页面，如果修改haproxy配置文件

backend htmpool
        mode           http
        option          redispatch
        option          abortonclose       关闭长期不使用的连接，提高性能
        #balance        static-rr
        cookie          SERVERID insert indirect nocache
        option          httpchk GET /index_new.html
        server 93server 172.18.1.93:80 cookie server1 weight 6 check inter 2000 rise 2 fall 3
        server 101server 172.18.1.101:80 cookie server2 weight 3 check inter 2000 rise 2 fall 3

重启haproxy服务后，访问就是 503：

监控页面也变红了，状态时down，

option httpchk GET /index_new.html

通过他访问得到的结果是404，而不是200，就down了，就把两个节点都踢出来了

解决：

在93服务器上

cd /var/www/html/
cp index.html index_new.html 复制一份

现在就可以正常访问93服务器了，而且监控页面里93服务器也自动恢复了。

同理101服务器也一样

查看haproxy的日志：

tailf /var/log/haproxy.log

刷新访问页面 5次

2019-04-17T17:56:01+08:00 localhost haproxy[19959]: 172.18.1.75:63636 [17/Apr/2019:17:56:01.154] www htmpool/server02 0/0/0/0/0 200 283 - - ---- 2/1/0/0/0 0/0 "GET / HTTP/1.1"
2019-04-17T17:56:01+08:00 localhost haproxy[19959]: 172.18.1.75:63635 [17/Apr/2019:17:56:01.863] www htmpool/server01 0/0/0/1/1 200 271 - - ---- 2/1/0/0/0 0/0 "GET / HTTP/1.1"
2019-04-17T17:56:02+08:00 localhost haproxy[19959]: 172.18.1.75:63637 [17/Apr/2019:17:56:02.472] www htmpool/server01 0/0/0/0/0 304 141 - - ---- 3/2/0/0/0 0/0 "GET / HTTP/1.1"
2019-04-17T17:56:03+08:00 localhost haproxy[19959]: 172.18.1.75:63638 [17/Apr/2019:17:56:03.137] www htmpool/server02 0/0/0/1/1 200 283 - - ---- 3/2/0/0/0 0/0 "GET / HTTP/1.1"
2019-04-17T17:56:03+08:00 localhost haproxy[19959]: 172.18.1.75:63639 [17/Apr/2019:17:56:03.702] www htmpool/server01 0/0/0/1/1 200 271 - - ---- 2/1/0/0/0 0/0 "GET / HTTP/1.1"

记录客户端的IP、端口、时间、访问的front（www）下backend的真实服务器

看到每个请求对应的真实服务器，这就是通过日志看出服务器轮询的机制。即实现了负载均衡的功能。

八、HAProxy负载均衡器算法与使用技巧

1、HAProxy支持的负载均衡算法

（1）roundrobin，表示简单的轮询，负载均衡基础算法（静态web系统）

（2）static-rr，表示根据权重（静态web系统）

（3）leastconn，表示最少连接者先处理（db系统）

（4）source，表示根据请求源IP （动态web系统）

（5）uri，表示根据请求的URL；

（6）uri_param，表示根据请求的url参数来进行调度；

（7）hdr(name)，表示根据HTTP请求头来锁定每一次HTTP请求；

（8）rdp-cookie(name)，表示根据cookie(name)来锁定并哈希每一次TCP请求。

2、常用的负载均衡算法

（1）轮询算法：roundrobin

（2）根据请求源IP算法：source

（3）最少连接者先处理算法：leastconn

九、通过HAProxy的ACL规则实现智能负载均衡

　　由于HAProxy可以工作在七层模型下，因此，要实现HAProxy的强大功能，一定要使用强大灵活的ACL规则，通过ACL规则可以实现基于HAProxy的智能负载均衡系统。HAProxy通过ACL规则完成两种主要的功能，分别是：

1、通过设置的ACL规则检查客户端请求是否合法。如果符合ACL规则要求，那么就将放行，反之，如果不符合规则，则直接中断请求；

2、符合ACL规则要求的请求将被提交到后端的backend服务器集群，进而实现基于ACL规则的负载均衡。

HAProxy中的ACL规则经常使用在frontend中，使用方法如下：

　　acl 自定义的acl名称 acl方法 -i [匹配的路径或文件]

其中：

　　acl：是关键字，表示定义ACL规则的开始。后面需要跟上自定义的ACL名称。

　　acl方法：这个字段用来定义实现ACL的方法，HAProxy定义了很多ACL方法（70-80种方法），经常使用的方法有hdr_reg(host)、hdr_dom(host)、hdr_beg(host)、url_sub、url_dir、path_beg、path_end等。

经常使用的方法：

　　hdr_beg(host)：精确匹配主机或者域名，表示以什么开头的域名，hdr_dom(host)跟他类似

　　hdr_reg(host)：正则匹配主机，表示以什么开头的域名

　　path_beg：匹配路径，表示以什么路径开头

　　path_end：匹配路径结尾，表示以什么路径结尾，一般用于.gpg等结尾

　　url_sub：表示请求url中包含什么字符串，例如acl file_reg url_sub -i killall=，表示在请求url中包含killall=，则此控制策略返回true

　　url_dir：表示请求url中存在哪些字符串作为部分地址路径，例如acl dir_reg url_dir -i allow，表示在请求url中存在allow作为部分地址路径，则此控制策略返回true，否则返回false

　　-i：表示忽略大小写，后面需要跟上匹配的路径或文件或正则表达式

　　与ACL规则一起使用的HAProxy参数还有use_backend，use_backend后面需要跟上一个backend实例名，表示在满足ACL规则后去请求哪个backend实例，与use_backend对应的还有default_backend参数，他表示在没有满足ACL条件的时候默认使用哪个后端backend。

　　列举常见的ACL规则例子：

　　acl　　www_policy　　hdr_reg(host)　　-i　　^(www.z.cn|z.cn)

　　　　　　　　　　　　表示如果访问域名是以www.z.cn或者z.cn开头，就满足这个策略

　　acl　　bbs_policy　　 hdr_dom(host)　 -i　　bbs.z.cn 这是精确匹配域名

　　acl　　url_policy　　 url_sub　　　　 -i　　buy_sid= 当请求中有buy_sid= 就满足规则

　　use_backend　　server_www　　if　　www_policy

　　use_backend　　server_app　　 if　　url_policy

　　use_backend　　server_bbs　　 if　　bbs_policy

　　default_backend　　server_cache 如果都不满足时，走这条规则

在客户端的hosts里配置解析地址：

C:\Windows\System32\drivers\etc\hosts

172.18.1.249 www.zb.com
172.18.1.249 img.zb.com

当访问时：

同样当访问img.zb.com也是成功的

十、使用HAProxy的Web监控平台

　　HAProxy虽然实现了服务的故障转移，但是在主机或者服务出现故障的时候，并不能发出通知告知运维人员，这对于及时性要求很高的业务系统来说，是非常不变的，不过，HAProxy似乎也考虑到了这一点，在新版本中HAProxy推出了一个基于web的监控平台，通过这个平台可以查看此集群系统所有后端服务器的运行状态，在后端服务或服务器出现故障时，及时告知运维人员。

十一、HAProxy+KeepAlived高可用负载均衡系统

其他参考博客：

https://blog.csdn.net/weixin_42859280/article/details/83796029

https://www.linuxidc.com/Linux/2017-10/147553.htm

https://www.jianshu.com/p/edf2c8c7d83f

https://www.cnblogs.com/xu360/articles/6593863.html 详细

https://jingyan.baidu.com/article/fd8044fa2c76f15031137afe.html 通过yum安装haproxy

https://www.cnblogs.com/ilanni/p/4750729.html 详细解释

https://www.cnblogs.com/ilanni/p/4750081.html

https://www.cnblogs.com/xiangsikai/p/8915629.html

巴特西

关于haproxy

最新文章

热门文章