服务器其它

关注公众号 jb51net

关闭
首页 > 网站技巧 > 服务器 > 服务器其它 > Haporxy搭建Web群集

如何使用Haporxy搭建Web群集

作者:绝不偷吃

Haproxy是目前比较流行的一种群集调度工具,同类群集调度工具有很多如LVS和Nginx,本案例介绍使用Haproxy及Nginx搭建一套Web群集,感兴趣的朋友跟随小编一起看看吧

一、案例分析

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 最常用的调度算法有三种,如下所述。

 2.3常见的Web群集调度器

        目前,常见的 Web 群集调度器分为软件和硬件。软件通常使用开源的 LVS、Haproxy、 Nginx,硬件一般使用比较多的是 F5。也有很多人使用国内的一些产品,如梭子鱼、绿盟等。

3.案例环境

3.1本案例环境

本案例使用三台服务器模拟搭建一套 Web 群集,具体的拓扑如图所示。案例环境如表所示

主机操作系统IP 地址应用
nginx1openEuler 24.03192.168.10.101apache
nginx2openEuler 24.03192.168.10.102apache
haproxyopenEuler 24.03192.168.10.103haproxy

 二、案例实施

1.搭建两台web服务器

 为了方便实验,网站没有配置域名,直接使用IP地址。在客户端访问http://192.168.10.102/test.html 测试

 2.安装Haproxy

 3.haproxy服务器配置

修改haproxy的配置文件

Haproxy 配置项介绍:
Haproxy 配置文件通常分为三个部分,即 globaldefaults 和 listen
global 为全局配置,defaults 为默认配置,listen 为应用组件配置。

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
    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  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-requestHTTP请求超时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群集内容请搜索脚本之家以前的文章或继续浏览下面的相关文章希望大家以后多多支持脚本之家!

您可能感兴趣的文章:
阅读全文