使用Haporxy搭建Web群集
目录
一、案例分析
1.案例概述
2.案例前置知识点
2.1 HTTP请求
2.2 负载均衡常用调度算法
2.3常见的Web群集调度器
3.案例环境
3.1本案例环境
二、案例实施
1.搭建两台web服务器
2.安装Haproxy
3.haproxy服务器配置
修改haproxy的配置文件
4.测试web群集
5.haproxy的日志
6.haproxy的参数优化
总结
一、案例分析
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部分-全局配置
globallog 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 配置项配置默认参数,一般会被应用组件继承,如果在应用组件中没有特别声明,将按照默认配置参数设置。
defaultsmode 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 globallog /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 的部署、配置、监控与优化技巧,对于构建稳定、高效、可扩展的系统架构具有不可忽视的意义。