HAProxy搭建web群集
目录
一.案例分析
1.案例概述
2.案例前置知识点
3. 负载均衡常用调度算法
二. 案例实施
1. 安装Apache
2. 编译安装HAProxy
3.HAProxy服务配置
(1) 解释
(2) 配置haproxy.cfg配置文件
4. 测试 Web 群集
(1) 测试高性能
(2) 测试高可用
5. Haproxy 的日志
(1) 修改 haproxy 配置文件
(2) 配置 Rsyslog 服务
(3) 重启Rsyslog和HAProxy 服务
(4) 测试日志信息。
6. Haproxy 的参数优化
HAProxy 作为一款高性能且功能强大的开源负载均衡与代理服务器软件，在运维领域发挥着至关重要的作用。它凭借高效的请求转发机制、灵活的负载均衡算法(如轮询、最少连接、源地址哈希等)，能够智能地将客户端请求分配到后端多台服务器，有效提升系统整体性能与可用性;支持TCP和HTTP(S)等多种协议，适配各类应用场景，无论是 Web 服务、数据库代理还是 API 网关等都能轻松应对;具备完善的健康检查功能，可实时监测后端服务器状态，自动隔离故障节点，确保服务连续性;同时，其丰富的配置选项与动态重载能力，让运维人员能够根据业务需求灵活调整策略，且无需中断服务。在实际运维工作中，熟练掌握HAProxy 的部署、配置、监控与优化技巧，对于构建稳定、高效、可扩展的系统架构具有不可忽视的意义。
一.案例分析
1.案例概述
Haproxy 是目前比较流行的一种群集调度工具，同类群集调度工具有很多，如 LVS 和 Nginx,apache。相比较而言，LVS 性能最好，但是搭建相对复杂,Haproxy 官方网站是 http://www.haproxy.org/。
2.案例前置知识点
通过 URL 访问网站使用的协议是 HTTP 协议，此类请求一般称为 HTTP 请求。HTTP 请求的方式分为GET方式和POST 方式。当使用浏览器访问某一个URL,会根据请求 URL 返回状态码,通常正常的状态码为 2xx、3xx(如 200、301)，如果出现异常会返回 4xx、5xx(如 400、500)。
例如，访问 http://www.test.com/a.php?Id=123，就是一个 GET 请求，如果访问正常，会从服务器的日志中获取 200状态码。假如此请求使用 POST 方式，那么传递给 a.php 的 Id 参数依旧是 123，但是浏览器的 URL 将不会显示后面的 Id=123 字样，因此表单类或者有用户名、密码等内容提交时建议使用POST 方式。不管使用哪种方式，最终 a.php 获取的值是一样的。
3. 负载均衡常用调度算法
LVS、Haproxy、Nginx 最常用的调度算法有三种
- RR(Round Robin)。RR 算法是最简单最常用的一种算法，即轮询调度。例如，有三个节点 A、B、C，第一个用户访问会被指派到节点 A，第二个用户访问会被指派到节点 B，第三个用户访问会被指派到节点C，第四个用户访问继续指派到节点 A,轮询分配访问请求实现负载均衡效果。此算法还有一种加权轮询，即根据每个节点的权重轮询分配访问请求。
- LC(Least Connections)。LC 算法即最小连接数算法，根据后端的节点连接数大小动态分配前端请求。例如，有三个节点 A、B、C，各节点的连接数分别为 A:4、B:5、C:6，此时如果有第一个用户连接请求，会被指派到 A上，连接数变为 A:5、B:5、C:6;第二个用户请求会继续分配到 A 上，连接数变为 A∶6、B∶5、C:6:再有新的请求会分配给B，每次将新的请求指派给连接数最小的客户端。由于实际情况下 A、B、C的连接数会动态释放，很难会出现一样连接数的情况，因此此算法相比较 rr 算法有很大改进，是目前用到比较多的一种算法。
- SH(SourceHashing)。SH 即基于来源访问调度算法，此算法用于一些有Session 会话记录在服务器端的场景，可以基于来源的 IP、Cookie 等做群集调度。例如，使用基于源 IP的群集调度算法，有三个节点 A、B、C，第一个用户第一次访问被指派到了 A，第二个用户第一次访问被指派到了 B，当第一个用户第二次访问时会被继续指派到 A，第二个用户第二次访问时依旧会被指派到 B,只要负载均衡调度器不重启，第一个用户访问都会被指派到 A，第二个用户访问都会被指派到 B,实现群集的调度。此调度算法好处是实现会话保持，但某些IP访问量非常大时会引起负载不均衡，部分节点访问量超大，影响业务使用。
常见的Web群集调度器
常见的 Web 群集调度器分为软件和硬件。软件通常使用开源的 LVS、Haproxy、 Nginx，硬件一般使用比较多的是 F5。也有很多人使用国内的一些产品，如梭子鱼、绿盟等。
二. 案例实施
环境
| 主机 | 操作系统 | ip地址 | 应用 |
| Apache1 | OpenEuler | 192.168.10.101 | Apache |
| Apache2 | OpenEuler | 192.168.10.102 | Apache |
| haproxy | OpenEuler | 192.168.10.103 | haproxy |
这里使用的是Apache，用哪个网站都可以如nginx，Tomcat。
1. 安装Apache
一个二都安装
二
测试一下
2. 编译安装HAProxy
3.HAProxy服务配置
(1) 解释
HAProxy配置项介绍：HAProxy通常分为三部分，global全局配置，defaults默认配置，listen应用组配件
global 配置项通常有下面配置参数
global
- log 127.0.0.1 loca12 //配置日志记录,loca12 为日志设备,默认存放到系统日志
- maxconn 4000//最大连接数
- user haproxy//用户
- group haproxy//用户组
defaults 配置项配置默认参数，一般会被应用组件继承，如果在应用组件中没有特别声明，将按照默认配置参数设置。
defaults
- log globalmode http//定义日志为 global 配置中的日志定义
- mode http//模式为 http
- option httplog//采用 http 日志格式记录日志
- retries 3//检查节点服务器失败次数,连续达到三次失败,则认为节点不可用
- maxconn 3000//最大连接数
- timeout connect 5s//连接超时时间
- timeout client 1m//客户端超时时间
- timeout server 1m//服务器超时时间
listen 配置项一般配置应用模块参数。
- listen webcluster//定义一个 appli4-backup 的应用
- bind 0.0.0.0:80 //监听所有网卡的 80 端口
- option httpchk GET /index.html //通过 GET /index.html 检查服务器健康状态
- balance roundrobin //负载均衡调度算法使用轮询算法
- server instl 192.168.10.101:80 check inter 2000 fall 3 //后端服务器 1，2000的单位是毫秒，每 2秒检查一次，3次失败后下线
(2) 配置haproxy.cfg配置文件
上面配置保持默认不用改，添加listen模块
4. 测试 Web 群集
已经搭建完成 Haproxy 的 Web 群集，接下来需要验证群集是否工作正常。一个群集一般需要具备两个特性，第一个是高性能，第二个是高可用。
(1) 测试高性能
在客户端使用浏览器打开 http://192.168.10.103
再次打开一个新的浏览器页面访问 http://192.168.10.103
可以看到群集的负载均衡调度已经生效，已经满足了群集的高性能需求。
(2) 测试高可用
现在将192.168.10.102的Nginx服务停用，在客户端使用浏 览器打开 http://192.168.10.103浏览器仍然显示信息
当一台节点故障，不会影响群集的使用，这样就满足了群集的高可用性。也可以将 192.168.10.102的 Nginx 服务恢复，再将192.168.10.101 的 Nginx 服务停用，测试高可用性。
5. Haproxy 的日志
Haproxy 的日志默认输出到系统的 syslog 中，查看起来不是非常方便，为了更好地管理 Haproxy 的日志,在生产环境中一般单独定义出来
(1) 修改 haproxy 配置文件
可以添加也可以在原有的基础上更改
(2) 配置 Rsyslog 服务
(3) 重启Rsyslog和HAProxy 服务
(4) 测试日志信息。
在客户端访问 http://192.168.10.103,可以使用cat /var/log/haproxy.log 即时査看 Haproxy 的访问请求日志信息。
6. Haproxy 的参数优化
Haproxy 的参数优化，以下列举了几个关键的参数，并对各参数的生产环境的优化 建议做了说明
| 参数 | 参数说明 | 优化建议 |
| maxconn | 最大连接数 | 此参数根据应用的实际使用情况进行调整，推荐使用10240，同时“defaults”中的最大连接数的值不能超过“global”段中的定义 |
| daemon | 守护进程模式 | Haproxy 可以使用非守护进程模式启动，生产环境建议使用守护进程模式启动 |
| nbproc | 负载均衡的并发进程数 | 建议与当前服务器CP核数相等或为其2倍 |
| retries | 重试次数 | 此参数主要用于对群集节点的检查，如果节点多，且并发量大，设置为2次或3次:在服务器节点不多的情况下，可以设置5次或6次 |
| option http-server-close | 主动关闭 http 请求选项 | 建议在生产环境中使用此选项，避免由于timeout 时间设置过长导致 http连接堆积 |
| timeout http-keep-alive | 长连接超时时间 | 此选项设置长连接超时时间，具体参考应用自身特点设置，可以设置为10s |
| timeout http-request | http 请求超时时间 | 建议将此时间设置为5~10s，增加http连接释放速度 |
| timeout client | 客户端超时时间 | 如果访问量过大，节点响应慢，可以将此时间设置短一些，建议设置为1min 左右就可以了 |