我要评论一、案例分析
1.案例概述
haproxy 是目前比较流行的一种群集调度工具，同类群集调度工具有很多如 lvs 和 nginx。相比较而言，lvs 性能最好，但是搭建相对复杂;nginx 的upstream 模块支持群集功能，但是对群集节点健康检查功能不强，高并发性能没有 haproxy 好。haproxy 官方网站是 http://www.haproxy.org/。
本案例介绍使用 haproxy 及 nginx 搭建一套 web 群集。
2.案例前置知识点
2.1 http请求
通过 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 获取的值是一样的。
2.2 负载均衡常用调度算法
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(source hashing)。sh 即基于来源访问调度算法，此算法用于一些有session 会话记录在服务器端的场景，可以基于来源的 ip、cookie 等做群集调度。例如，使用基于源 ip 的群集调度算法，有三个节点 a、b、c，第一个用户第一次访问被指派到了 a，第二个用户第一次访问被指派到了 b，当第一个用户第二次访问时会被继续指派到 a，第二个用户第二次访问时依旧会被指派到b，只要负载均衡调度器不重启，第一个用户访问都会被指派到 a，第二个用户访问都会被指派到 b,实现群集的调度。此调度算法好处是实现会话保持，但某些ip访问量非常大时会引起负载不均衡，部分节点访问量超大，影响业务使用。
2.3常见的web群集调度器
目前，常见的 web 群集调度器分为软件和硬件。软件通常使用开源的 lvs、haproxy、 nginx，硬件一般使用比较多的是 f5。也有很多人使用国内的一些产品，如梭子鱼、绿盟等。
3.案例环境
3.1本案例环境
本案例使用三台服务器模拟搭建一套 web 群集，具体的拓扑如图所示。案例环境如表所示
| 主机 | 操作系统 | ip 地址 | 应用 |
|---|---|---|---|
| nginx1 | openeuler 24.03 | 192.168.10.101 | apache |
| nginx2 | openeuler 24.03 | 192.168.10.102 | apache |
| haproxy | openeuler 24.03 | 192.168.10.103 | haproxy |
二、案例实施
1.搭建两台web服务器
为了方便实验，网站没有配置域名，直接使用ip地址。在客户端访问http://192.168.10.102/test.html 测试
2.安装haproxy
3.haproxy服务器配置
修改haproxy的配置文件
haproxy 配置项介绍:
haproxy 配置文件通常分为三个部分，即 global、defaults 和 listen。
global 为全局配置，defaults 为默认配置，listen 为应用组件配置。
- global部分-全局配置
global
log 127.0.0.1 local2 # 日志输出到本地127.0.0.1的syslog的local2设施
chroot /var/lib/haproxy # 改变根目录到/var/lib/haproxy，增强安全性
pidfile /var/run/haproxy.pid # 指定pid文件位置
user haproxy # 以haproxy用户身份运行
group haproxy # 以haproxy组身份运行
daemon # 以守护进程方式运行
maxconn 4000 # 最大连接数4000- defaults 部分 - 默认参数
defaults 配置项配置默认参数，一般会被应用组件继承，如果在应用组件中没有特别声明，将按照默认配置参数设置。
defaults
mode http # 默认模式为http(七层代理)
log global # 继承global部分的日志配置
option httplog # 启用http日志格式
option dontlognull # 不记录空连接日志
retries 3 # 失败后重试3次
timeout http-request 5s # http请求超时时间5秒
timeout queue 1m # 请求在队列中的最长等待时间1分钟
timeout connect 5s # 连接后端服务器的超时时间5秒
timeout client 1m # 客户端不活动超时时间1分钟
timeout server 1m # 服务器端不活动超时时间1分钟
timeout http-keep-alive 5s # http keep-alive超时时间5秒
timeout check 5s # 健康检查超时时间5秒
maxconn 3000 # 默认最大连接数3000- listen 部分 - 定义前端和后端
listen myweb # 定义一个名为myweb的监听服务(同时包含前端和后端)
bind 0.0.0.0:80 # 监听所有ip的80端口
option httpchk get /index.html # 使用http get /index.html进行健康检查
balance roundrobin # 使用轮询(round-robin)负载均衡算法
server inst1 192.168.10.102:80 check inter 2000 fall 3 # 后端服务器1，ip:192.168.10.102:80，启用健康检查，检查间隔2秒，3次失败标记为不可用
server inst2 192.168.10.103:80 check inter 2000 fall █ # 后端服务器2，ip:192.168.10.103:80，启用健康检查，检查间隔2秒，█处应为失败次数(如3)4.测试web群集
通过上面的步骤，已经搭建完成 haproxy 的 web 群集，接下来需要验证群集是否工作正常。一个群集一般需要具备两个特性，第一个是高性能，第二个是高可用。
- 测试高性能
在客户端访问网站显示信息 ：
- 测试高可用
现在将192.168.10.102的nginx服务停用，在客户端使用浏 览器打开 http://192.168.10.103/test.html，浏览器显示信息仍然更之前一样。
从中可以看出，当一台节点故障，不会影响群集的使用，这样就满足了群集的高可用性。也可以将 192.168.10.102的 nginx 服务恢复，再将192.168.10.103 的 nginx 服务停用，测试高可用性。
5.haproxy的日志
haproxy 的日志默认输出到系统的 syslog 中，查看起来不是非常方便，为了更好地管理 haproxy 的日志，在生产环境中一般单独定义出来，定义的方法如下所述。
修改 haproxy 配置文件，将原有的配置更改为以下配置:
[root@localhost ~]# vim /etc/haproxy/haproxy.cfg
global
log /dev/log local0 info # 修改log配置，使用local0设备记录info级别日志
#chroot /var/lib/haproxy # 注释掉chroot项（取消chroot限制）配置 rsyslog 服务
[root@localhost ~]# vim /etc/rsyslog.d/99-haproxy.conf # 捕获local0设备的日志，写入/var/log/haproxy.log local0.* /var/log/haproxy.log
创建日志文件并设置权限
[root@localhost ~]# touch /var/log/haproxy.log [root@localhost ~]# chmod 640 /var/log/haproxy.log [root@localhost ~]# chown root:adm /var/log/haproxy.log
重启rsyslog和 haproxy 服务
[root@localhost ~]# systemctl restart rsyslog [root@localhost ~]# systemctl restart haproxy
- 测试日志信息。
在客户端访问 http://192.168.10.103/test.html 后，可以使用 tail -f/var/log/haproxy.log 即时査看 haproxy 的访问请求日志信息。
[root@localhost ~]# tail -f /var/log/haproxy.log apr 11 22:06:20 localhost happyxy[2701]: 192.168.10.1:54483 [11/apr/2025:22:06:20.941] webcluster webcluster/inst2 0/0/0/1/1 200 221 -- --- 2/2/0/0/0 0/0 "get /test.html http/1.1" apr 11 22:06:20 localhost happyxy[2701]: 192.168.10.1:54483 [11/apr/2025:22:06:20.981] webcluster webcluster/inst1 0/0/0/1/1 404 3603 -- --- 2/2/0/0/0 0/0 "get /favicon.ico http/1.1"
6.haproxy的参数优化
关于 haproxy 的参数优化，以下列举了几个关键的参数，并对各参数的生产环境的优化 建议做了说明，如表下表所示。
| 分类 | 参数 | 说明 | 优化建议 | 注意事项 |
|---|---|---|---|---|
| 全局参数 | maxconn | 最大并发连接数 | - 推荐值：10240 - 根据服务器内存调整（每连接约占用10-20kb内存） | defaults段的值必须 ≤ global段的值 |
| daemon | 守护进程模式 | 生产环境必须启用 | 非守护进程模式仅用于调试 | |
| nbproc | 工作进程数 | 等于cpu核数（如16核）或2倍（如32核） | 每个进程独立处理连接，需配合maxconn分配 | |
| 重试策略 | retries | 节点健康检查重试次数 | - 高并发集群：2-3次 - 小型集群：5-6次 | 过多重试会增加故障检测延迟 |
| http优化 | option http-server-close | 主动关闭后端http连接 | 生产环境建议启用 | 可减少服务端连接堆积，但会增加tcp握手开销 |
| timeout http-keep-alive | 长连接保持时间 | - 动态内容：10s - 静态资源：30-60s | 需与应用特性匹配 | |
| timeout http-request | http请求超时 | 5-10s（敏感业务可延长至15s） | 过短会导致慢请求失败 | |
| timeout client | 客户端超时 | - 常规：1min - 高并发：30s | 影响文件上传等长耗时操作 | |
| 高级优化 | timeout connect | 后端连接超时 | 5-10s（跨机房部署可延长） | 需大于网络延迟 |
| timeout server | 后端响应超时 | 根据应用响应时间调整（建议≥平均响应时间的3倍） | 过短会导致正常响应被中断 |
总结
haproxy作为一款高性能且功能强大的开源负载均衡与代理服务器软件，在运维领域发挥着至关重要的作用。它凭借高效的请求转发机制、灵活的负载均衡算法(如轮询、最少连接、源地址哈希等)，能够智能地将客户端请求分配到后端多台服务器，有效提升系统整体性能与可用性;支持tcp和http(s)等多种协议，适配各类应用场景，无论是 web 服务、数据库代理还是 api网关等都能轻松应对;具备完善的健康检查功能，可实时监测后端服务器状态，自动隔离故障节
点，确保服务连续性;同时，其丰富的配置选项与动态重载能力，让运维人员能够根据业务需求灵活调整策略，且无需中断服务。在实际运维工作中，熟练掌握haproxy 的部署、配置、监控与优化技巧，对于构建稳定、高效、可扩展的系统架构具有不可忽视的意义。
到此这篇关于使用haporxy搭建web群集的文章就介绍到这了,更多相关haporxy搭建web群集内容请搜索代码网以前的文章或继续浏览下面的相关文章希望大家以后多多支持代码网！
发表评论