负载均衡之Haproxy配置详解（及httpd配置）

我会带着你远行 2022-02-26 21:22 289阅读 0赞

# [负载均衡之Haproxy配置详解（及httpd配置）][Haproxy_httpd] #

下图描述了使用keepalived+Haproxy主从配置来达到能够针对前段流量进行负载均衡到多台后端web1、web2、web3、img1、img2.

但是由于haproxy会存在单点故障问题，因此使用keepalived来实现对Haproxy单点问题的高可用处理。

![1156343-20170502134144039-761328242.png][]

**三大主流软件负载均衡器对比(LVS VS Nginx VS Haproxy)**

<table> 
 <tbody> 
  <tr> 
   <td style="vertical-align:top;">LVS：<br> 1、抗负载能力强。抗负载能力强、性能高，能达到F5硬件的60%；对内存和cpu资源消耗比较低<br> 2、工作在网络4层，通过vrrp协议转发（仅作分发之用），具体的流量由linux内核处理，因此没有流量的产生。<br> 2、稳定性、可靠性好，自身有完美的热备方案；（如：LVS+Keepalived）<br> 3、应用范围比较广，可以对所有应用做负载均衡；<br> 4、不支持正则处理，不能做动静分离。<br> 5、支持负载均衡算法：rr（轮循）、wrr（带权轮循）、lc（最小连接）、wlc（权重最小连接）<br> 6、配置 复杂，对网络依赖比较大，稳定性很高。</td> 
  </tr> 
 </tbody> 
</table>

<table> 
 <tbody> 
  <tr> 
   <td style="vertical-align:top;"> <p>Ngnix：</p> <p>1、工作在网络的7层之上，可以针对http应用做一些分流的策略，比如针对域名、目录结构；</p> <p>2、Nginx对网络的依赖比较小，理论上能ping通就就能进行负载功能；</p> <p>3、Nginx安装和配置比较简单，测试起来比较方便；</p> <p>4、也可以承担高的负载压力且稳定，一般能支撑超过1万次的并发；</p> <p>5、对后端服务器的健康检查，只支持通过端口来检测，不支持通过url来检测。</p> <p>6、Nginx对请求的异步处理可以帮助节点服务器减轻负载；</p> <p>7、Nginx仅能支持http、https和Email协议，这样就在适用范围较小。</p> <p>8、不支持Session的直接保持，但能通过ip_hash来解决。、对Big request header的支持不是很好，</p> <p>9、支持负载均衡算法：Round-robin（轮循）、Weight-round-robin（带权轮循）、Ip-hash（Ip哈希）</p> <p>10、Nginx还能做Web服务器即Cache功能。</p> </td> 
  </tr> 
 </tbody> 
</table>

<table> 
 <tbody> 
  <tr> 
   <td style="vertical-align:top;">HAProxy的特点是：<br> 1、支持两种代理模式：TCP（四层）和HTTP（七层），支持虚拟主机；<br> 2、能够补充Nginx的一些缺点比如Session的保持，Cookie的引导等工作<br> 3、支持url检测后端的服务器出问题的检测会有很好的帮助。<br> 4、更多的负载均衡策略比如：动态加权轮循(Dynamic Round Robin)，加权源地址哈希(Weighted Source Hash)，加权URL哈希和加权参数哈希(Weighted Parameter Hash)已经实现<br> 5、单纯从效率上来讲HAProxy更会比Nginx有更出色的负载均衡速度。<br> 6、HAProxy可以对Mysql进行负载均衡，对后端的DB节点进行检测和负载均衡。<br> 9、支持负载均衡算法：Round-robin（轮循）、Weight-round-robin（带权轮循）、source（原地址保持）、RI（请求URL）、rdp-cookie（根据cookie）<br> 10、不能做Web服务器即Cache。</td> 
  </tr> 
 </tbody> 
</table>

**三大主流软件负载均衡器适用业务场景：**

<table> 
 <tbody> 
  <tr> 
   <td style="vertical-align:top;"><br> 1、网站建设初期，可以选用Nigix/HAproxy作为反向代理负载均衡（或者流量不大都可以不选用负载均衡），因为其配置简单，性能也能满足一般的业务场景。如果考虑到负载均衡器是有单点问题，可以采用Nginx+Keepalived/HAproxy+Keepalived避免负载均衡器自身的单点问题。<br> 2、网站并发达到一定程度之后，为了提高稳定性和转发效率，可以使用LVS、毕竟LVS比Nginx/HAproxy要更稳定，转发效率也更高。不过维护LVS对维护人员的要求也会更高，投入成本也更大。<br><br> 注：Niginx与Haproxy比较：Niginx支持七层、用户量最大，稳定性比较可靠。Haproxy支持四层和七层，支持更多的负载均衡算法，支持session保存等。具体选型看使用场景，目前来说Haproxy由于弥补了一些Niginx的缺点用户量也不断在提升。<br> &nbsp;</td> 
  </tr> 
 </tbody> 
</table>

**衡量负载均衡器好坏的几个重要因素： **

1、会话率 ：单位时间内的处理的请求数

2、会话并发能力：并发处理能力

3、数据率：处理数据能力

经过官方测试统计，haproxy  单位时间处理的最大请求数为20000个，可以同时维护40000-50000个并发连接，最大数据处理能力为10Gbps。综合上述，haproxy是性能优越的负载均衡、反向代理服务器。

**总结HAProxy主要优点：**

一、免费开源，稳定性也是非常好，这个可通过我做的一些小项目可以看出来，单Haproxy也跑得不错，稳定性可以与LVS相媲美；

二、根据官方文档，HAProxy可以跑满10Gbps-New benchmark of HAProxy at 10 Gbps using Myricom's 10GbE NICs (Myri-10G PCI-Express)，这个作为软件级负载均衡，也是比较惊人的；

三、HAProxy可以作为[MySQL][]、邮件或其它的非web的负载均衡，我们常用于它作为MySQL(读)负载均衡；

四、自带强大的监控服务器状态的页面，实际环境中我们结合Nagios进行邮件或短信报警，这个也是我非常喜欢它的原因之一；

五、HAProxy支持虚拟主机。

**Haproxy负载均衡器讲解：**

本次使用环境：

环境centos7.1

Haproxy 1.5.4

Haproxy+keeplived  172.31.2.31

Haproxy+keeplived  172.31.2.32

下述针对Haproxy的配置文件进行详解：

vim /etc/haproxy/haproxy.cfg

![复制代码][copycode.gif]

global                                                       # 全局参数的设置
        log         127.0.0.1 local2                      # log语法：log <address_1>[max_level_1] # 全局的日志配置，使用log关键字，
                                                                         指定使用127.0.0.1
                                                                         上的syslog服务中的local0日志设备，记录日志等级为info的日志
        chroot      /var/lib/haproxy                 #改变当前工作目录
        pidfile     /var/run/haproxy.pid          #当前进程id文件
        maxconn     4000                                #最大连接数
        user        haproxy                                #所属用户
        group     haproxy                                #所属组
        daemon                                               #以守护进程方式运行haproxy
        stats socket /var/lib/haproxy/stats
    defaults
        mode                    http                        #默认的模式mode { tcp|http|health }，tcp是4层，http是7层，health只会返回OK
        log                        global                    #应用全局的日志配置
        option                  httplog                  # 启用日志记录HTTP请求，默认haproxy日志记录是不记录HTTP请求日志
                                                                     
        option                  dontlognull          # 启用该项，日志中将不会记录空连接。所谓空连接就是在上游的负载均衡器
                                                                       或者监控系统为了探测该 服务是否存活可用时，需要定期的连接或者获取某
                                                                      一固定的组件或页面，或者探测扫描端口是否在监听或开放等动作被称为空连接；
                                                                      官方文档中标注，如果该服务上游没有其他的负载均衡器的话，建议不要使用
                                                                       该参数，因为互联网上的恶意扫描或其他动作就不会被记录下来
        option http-server-close                   #每次请求完毕后主动关闭http通道
        option forwardfor       except 127.0.0.0/8   #如果服务器上的应用程序想记录发起请求的客户端的IP地址，需要在HAProxy
                                                                                上 配置此选项， 这样 HAProxy会把客户端的IP信息发送给服务器，在HTTP
                                                                                请求中添加"X-Forwarded-For"字段。 启用  X-Forwarded-For，在requests
                                                                                头部插入客户端IP发送给后端的server，使后端server获取到客户端的真实IP。 
        option                  redispatch                      # 当使用了cookie时，haproxy将会将其请求的后端服务器的serverID插入到
                                                                                cookie中，以保证会话的SESSION持久性；而此时，如果后端的服务器宕掉
                                                                                了， 但是客户端的cookie是不会刷新的，如果设置此参数，将会将客户的请
                                                                                求强制定向到另外一个后端server上，以保证服务的正常。
        retries                 3                             # 定义连接后端服务器的失败重连次数，连接失败次数超过此值后将会将对应后端
                                                                      服务器标记为不可用
        timeout http-request    10s             #http请求超时时间
        timeout queue           1m                 #一个请求在队列里的超时时间
        timeout connect         10s                #连接超时
        timeout client          1m                   #客户端超时
        timeout server          1m                   #服务器端超时
        timeout http-keep-alive 10s           #设置http-keep-alive的超时时间
        timeout check           10s                 #检测超时
        maxconn                 3000                 #每个进程可用的最大连接数
    frontend  main *:80                             #监听地址为80
        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             my_webserver     #定义一个名为my_app前端部分。此处将对于的请求转发给后端
    backend static                                                 #使用了静态动态分离（如果url_path匹配 .jpg .gif .png .css .js静态文件则
                                                                                访问此后端）
        balance     roundrobin                               #负载均衡算法（#banlance roundrobin 轮询，balance source 保存session值，
                                                                               支持static-rr，leastconn，first，uri等参数）
        server      static 127.0.0.1:80 check             #静态文件部署在本机（也可以部署在其他机器或者squid缓存服务器）
    backend my_webserver                                  #定义一个名为my_webserver后端部分。PS：此处my_webserver只是一个
                                                                                自定义名字而已，但是需要与frontend里面配置项default_backend 值相一致
        balance     roundrobin                               #负载均衡算法
        server  web01 172.31.2.33:80  check inter 2000 fall 3 weight 30              #定义的多个后端
        server  web02 172.31.2.34:80  check inter 2000 fall 3 weight 30              #定义的多个后端
        server  web03 172.31.2.35:80  check inter 2000 fall 3 weight 30              #定义的多个后端

![复制代码][copycode.gif]

* 更多关于Haproxyacl配置参考：[http://blog.csdn.net/tantexian/article/details/50015975][http_blog.csdn.net_tantexian_article_details_50015975]*

配置完成则重启服务：

systemctl restart haproxy

假若想访问监控界面：配置stats uri  /haproxy项，重启服务：

![1156343-20170502134305539-1583747162.png][]

systemctl reload haproxy

![1156343-20170502134440195-107837133.png][]

注意：假若页面范围不了，是否selinux关闭了，iptables开启此端口了（iptables -F）

同理在172.31.2.32上面安装上述步骤安装配置好haproxy：

![1156343-20170502134534007-1051586920.png][]

上述对Haproxy的优缺点及配置进行了详细讲解。

接下来对Haproxy+web负载均衡使用进行实战讲解：

首先配置三台web服务器：172.31.2.33、172.31.2.34、172.31.2.35

三台都是同样操作：

1、实验环境

centos 7.1 X64 mini版

2、配置web服务器(node33/34/35)：

测试方便，关闭selinux、关闭iptables

一下都采用默认，不做配置即可。

yum install httpd -y

\# vim /etc/httpd/conf/httpd.conf

httpd监听端口：

![1156343-20170502134624429-1602194262.png][]

DocumentRoot：网页存放的路径，文档的根目录

![1156343-20170502134643929-864975812.png][]

重启httpd

\# systemctl restart httpd

页面访问httpd：

![1156343-20170502134709570-1174896072.png][]

修改显示内容：

\# vim /var/www/html/index.html

I'm node33!!! My IP is 172.31.2.33...

再次访问：

![1156343-20170502134752679-882604011.png][]

![1156343-20170502134738211-2113156519.png][]

![1156343-20170502134802461-1016620273.png][]

这样三个web服务33/34/35搭建成功！！！！

接下来配置负载均衡（本次实验只用一个Haproxy：172.31.2.31）：

vim /etc/haproxy/haproxy.cfg![1156343-20170502134821086-1757150358.png][]

浏览器请求172.31.2.31：

![1156343-20170502134838711-1906706858.png][]

![1156343-20170502134846445-1220660870.png][]

![1156343-20170502134852570-5132165.png][]

从上述结果可知，前端对172.31.2.31的请求，被Haproxy的负载均衡器，均衡请求到三个后端web172.31.2.33、172.31.2.34、172.31.2.35上面去了。

这样当三个当中的一个出现故障，流量则能正常分发到剩余两个正常的web上，从来提高了系统可靠性。

*keepalived+Haproxy参考：[http://blog.csdn.net/tantexian/article/details/50056229][http_blog.csdn.net_tantexian_article_details_50056229]*

[Haproxy_httpd]: https://www.cnblogs.com/nineep/p/6795780.html
[1156343-20170502134144039-761328242.png]: /images/20220227/54600425487142be9744575fc1c4fb24.png
[MySQL]: http://lib.csdn.net/base/14
[copycode.gif]: /images/20220227/f40f9821b98a459496904615c235c812.png
[http_blog.csdn.net_tantexian_article_details_50015975]: http://blog.csdn.net/tantexian/article/details/50015975
[1156343-20170502134305539-1583747162.png]: /images/20220227/dcb44ea4e63e476aaa0e711aba1179e1.png
[1156343-20170502134440195-107837133.png]: /images/20220227/b86d2262f95e4719999bcf042756256f.png
[1156343-20170502134534007-1051586920.png]: /images/20220227/f44b80c31b904a5e8a94f4f79768f642.png
[1156343-20170502134624429-1602194262.png]: /images/20220227/28f15a0930944ffa9f89d4d30afeb17b.png
[1156343-20170502134643929-864975812.png]: /images/20220227/fd9168b048bb4dcda0cfd5b5929ed1b5.png
[1156343-20170502134709570-1174896072.png]: /images/20220227/3f233097bd5440bc83b46dc51155b77d.png
[1156343-20170502134752679-882604011.png]: /images/20220227/6d9305edc0524187b0da62394e1fb713.png
[1156343-20170502134738211-2113156519.png]: /images/20220227/affd7d21f88f4aaca996961db91f2b3d.png
[1156343-20170502134802461-1016620273.png]: /images/20220227/19b4e0bd3b4e41b2adfea73588b7d98d.png
[1156343-20170502134821086-1757150358.png]: /images/20220227/ccf21b8453c946a0bb9a9223ad54a2fd.png
[1156343-20170502134838711-1906706858.png]: /images/20220227/fbbdb112521a4f09af784d4e977830fd.png
[1156343-20170502134846445-1220660870.png]: /images/20220227/ef0d5779bb504cd9b5c2fe133aa709c1.png
[1156343-20170502134852570-5132165.png]: /images/20220227/00a2f9286b1044d998b75c0e5549ca20.png
[http_blog.csdn.net_tantexian_article_details_50056229]: http://blog.csdn.net/tantexian/article/details/50056229