高可用负载均衡集群之 HAProxy 部署

时间 2019-11-08

标签可用负载均衡集群 haproxy 部署栏目负载均衡繁體版

原文原文链接

1、HAProxy 简介html

一、HAProxy 是开源、免费、快速而且可靠的一种解决方案，他能够运行在大部分主流的 Linux 服务器上。git

二、HAProxy 适用于负载那些特大的 WEB 站点，而这些站点一般又须要会话保持或者进行七层处理。github

三、HAProxy 是可以提供高可用性、负载均衡以及基于 L4（TCP）和 L7（HTTP）的应用的代理。web

四、HAProxy 功能丰富，且性能稳定。正则表达式

2、影响 HAProxy 负载均衡器的性能因素算法

一、Session 会话率：即每秒产生的会话数，这个因素取决于客户端的访问量，所以，访问量越大，Session 会话率越大，负载均衡压力就越大。vim

二、Session concurrency 并发会话数：即并发会话数越多，服务器处理的会话时间就越长，客户端表现出来的访问就会越慢。后端

三、Date rate 数据速率：它以 MB/s 或者 Mbps 来衡量，其数据量越大，并发会话数就会增长，并发会话数越多、数据速率越高，所要求使用的内存就越多。浏览器

所以，这三个因素，在高并发负载均衡中，可能会成为 HAProxy 的性能瓶颈。缓存

3、HAProxy 负载均衡器的核心功能和关键特性

一、HAProxy 的核心功能

    负载均衡：HAProxy 的负载均衡有两种模式，分别为 L4（TCP）和 L7（HTTP），这两种负载均衡均支持如下负载均衡调度算法：

              roundrobin：动态轮询算法

              rr：轮询算法

              static-rr：静态轮询算法

              lc：最少链接

              IP Hash：IP 地址散列（包括源地址和目标地址）

              URL_PARAM Hash：对用户请求的 uri 仅 params 部分中的参数的值做hash计算

              HTTP_HEADER Hash：对用户请求的 uri 的 http 头部信息做hash计算

    这里仅列举经常使用的这些算法，固然还有其余算法，都不经常使用。

    健康检查：其实健康检查能够算做 HAProxy 的一种工做模式，不过这种工做模式，如今几乎不多用到，因此，健康检查，通常是作为 L4（TCP）和 L7（HTTP）的状态检查。

    会话保持：对于未实现会话共享的应用集群，可经过 Insert Cookie/Rewrite Cookie/Prefix Cookie，以及上述的多种Hash方式实现会话保持。

    解析 SSL：HAProxy 能够解析 HTTPS 协议，而且可以将客户端 HTTPS 请求解密为 HTTP 后向后端传输。

    HTTP 请求重写和重定向：HAProxy 可使用正则表达式将 HTTP 请求重写和重定向。

    监控与统计：HAProxy 提供了基于 WEB 界面的统计信息页面，在该页面可以展现应用服务器的健康状态和数据流量。作为运维，咱们能够基于此页面来开发监控程序以监控 HAProxy 的状态。

二、HAProxy 的关键特性

    关于 HAProxy 的特性，其实和 HTTP 协议的特性是是息息相关的。

    a、HTTP 事务模型：

          - HTTP 协议是事务驱动的

          - 每一个请求（Request）仅能对应一个响应（Response）

          - HTTP 经常使用连接模式

                     HTTP close：每一个 Request 产生且仅产生一个 Response，客户端发送请求时，将创建一个从客户端到服务端的 TCP 链接，客户端发送的每个 Request 都通过此链接传送给服务端，而后服务端发出 Response 报文。随后这个 TCP 链接将关闭，下一个 Request 将从新打开一个 tcp链接进行传送。

                     Keep-alive：Http close 模式下，TCP 连接会随着 Response 的关闭而关闭，所以，频繁的连接和关闭会形成资源和时间的大量消耗。为了不这种状况，在服务器端发送 Response 时给出 content-length 的标记，让客户端知道还有多少内容没有接收到，没有接收完则tcp链接不关闭。这种模式咱们称为 “Keep-alive”。

                     Pipelining：这种模式可以提高 Http close ,不过它任然使用 keep-alive 模式。可是在使用这种模式时，客户端不须要等待收到服务端的 Response 后才发送后续的 Request 请求。所以，这种模式在请求含有大量图片的页面时颇有用，因此可以很好的提升性能。

           HAProxy 支持的 5 种链接模式：

           一、keep alive：分析并处理全部的 Request 和 Response（默认），当后端为静态或缓存服务器建议使用此模式。

           二、tunnel：仅分析处理第一个 Request 和 Response，剩余全部内容不进行任何分析直接转发。较早的版本使用，如今已基本不用。

           三、passive close：在请求和响应首部加上 "connection:close" 标记的 tunnel ，在处理完第一个 Request 和 Response 后尝试关闭两端链接。

           四、server close：处理完第一个 Response 后关闭和 Server 端的链接，但和客户端的链接仍然保持，当后端为动态应用程序服务器组建议使用此模式。

           五、forced close：传输完一个response后客户端和服务端都关闭链接。

b、HAProxy 使用单线程，可以减小上下文切换时对资源的消耗。

c、HAProxy 可以最大化的利用系统自己的特性，是的系统在处理请求时能发挥出最高的性能。

4、HAProxy 安装和配置

服务器地址分配

一、HAProxy 的安装

在这里，咱们采用 yum 源安装：

[root@haproxy ~]# yum -y install haproxy

二、HAProxy的配置：

a、日志配置

对于 HAProxy 的日志配置，咱们这里须要介绍下系统日志的构成。对于系统日志，主要有两部分构成，即

Faciliti.priority，这种构成至关于服务.优先级

Facility 能够是这些关键字：auth, authpriv, cron, daemon, kern, lpr, mail, mark, news, security, syslog, user, uucp 以及 local0 到 local7。local0 到 local7 是预留出来的接口，给第三方应用调用。

priority可使用的关键字：debug, info, notice, warning, warn, err, error, crit, alert, emerg, panic 。debug 是最不严重的级别，panic 是最严重的级别。若是日志级别优先级是 info，表示比 info 严重的日志都须要记录。

而对于关键字的获取，咱们能够在 rsyslog.conf 中得到，使用命令 man 5 rsyslog.conf ，一直往下找 SELECTORS（选择器）。

b、配置本机接收经过网络发来的日志，即日志服务器的配置：

[root@haproxy ~]# vim /etc/rsyslog.conf

取消上图中红框内内容的注释便可，图中已取消。

重启 rsyslog 服务

[root@haproxy ~]# systemctl restart rsyslog

c、HAProxy 的配置文件解释

HAProxy 的配置文件位于 /etc/haproxy/ 目录下，如图：

如图，HAProxy 的配置文件分为 5 部分：global、defaults、frontend、backend static、backend app

可是在实际配置过程当中，咱们可将后面三部分简化为 listen。所以，咱们在这里对 global、defaults 部分的配置字段作一一解释，以下表：

d、HAProxy 配置文件修改

通常状况下，第一部分 global 和第二部分 defaults 不用修改，保持默认便可，所以，咱们这里主要进行第三部分 listen 的修改。

咱们将

行下的部分所有删除，而后添加 listen 部分：

listen stats #这里的 stats 能够自定义

         bind 0.0.0.0:1050 #监听端口，可自定义

         stats refresh 30s #统计页面自动刷新时间

         stats uri /monitor #统计页面 url

         stats realm Haproxy Monitor #统计页面密码框提示文本

         stats auth admin:admin #统计页面用户名和密码

         stats hide-version #隐藏统计界面上的 HAProxy 的版本信息

listen myweb 0.0.0.0:80 #能够自定义命名，网址+ip+端口

         cookie SERVERID rewrite

         balance roundrobin #动态轮询调度算法

         server web1 172.16.0.3:80 cookie application1instances1 check inter 2000 rise 2 fall 5

         server web2 172.16.0.4:80 cookie application1instances2 check inter 2000 rise 2 fall 5 #表示后端服务器 web1 和 web2 ，IP 地址分别为 172.16.0.3 和 172.16.0.4，经过写cookie信息设置状态，application，应用，instances，实例，check对服务器作健康检查，inter 2000毫秒，若是连续两次检查都是成功的（rise 2）则说明服务器是好的，若是连续五次检查都是失败的（fall 5）则说明服务器是坏的。

如图：

保存并退出，启动或重启（以前有启动过） HAProxy 服务。

[root@haproxy ~]# systemctl start haproxy

或

[root@haproxy ~]# systemctl restart haproxy

e、验证

首先，咱们验证站点访问，在浏览器中输入http://192.168.20.140/，结果如图：

其次，咱们验证监控站点，在浏览器中输入http://192.168.20.140:1050/monitor，如图：

会要咱们输入用户名和密码，就是咱们在配置文件中设置的 admin

登录以后，界面以下：

如图，在左边红框内，主要展现一些 HAProxy 服务器的状态，包括启动时间、PID号等等，而右边红框内主要展现颜色标志，具体的颜色变化会展现在下边的 web一、web2 的行，须要注意的时，4个颜色的变化，以下图：

表示服务在线正常

      表示服务在线，可是已经 down 掉

   表示服务已经 down 掉，可是正在恢复中

     表示服务已经所有 down 掉，没法提供服务

以上配置是 HAProxy 的 L7（HTTP）负载均衡配置。下面咱们看下 L4（TCP）负载均衡配置

5、HAProxy 的 L4 （TCP）配置

其实 HAProxy 的 L4（TCP）配置和 L7（HTTP）配置是差很少的，只须要更改以下三个地方

一、将配置文件中 mode http 修改成 mode tcp ，表示开启 TCP 模式

二、将配置文件中 option httplog 修改成 option tcplog ，表示开启 tcplog

三、将 balance roundeobin 修改成 balance source，表示基于客户端的 IP 会话保持。

而其余部分暂时能够不用修改，在使用过程当中，咱们能够根据实际数据进行更改。

6、日志查看

前面咱们配置了 HAProxy 的日志，它的日志会记录在系统的 messages 日志里面，如今咱们来看一下，日志的内容

当咱们访问站点时，日志会在 messages 中刷新，如上图，主要会记录后端服务器的访问状况以及当会话闲置时 HAProxy 的状态日志，固然，咱们只是配置仅限有日志，并未配置其余类型的日志进行记录，因此这里只会显示这么多。

到此为止，咱们的 HAProxy 部署配置已结束，若是想了解更多相关的只是，请参阅官方文档。官方文档