4.Haproxy搭建Web群集-海口c网

4.Haproxy搭建Web群集

article/2025/7/18 19:39:00

一.案例分析

1.案例概述

Haproxy是目前比较流行的一种群集调度工具，同类群集调度工具有很多，包括LVS、Nginx，LVS性能最好，但是搭建相对复杂；Nginx的upstream模块支持群集功能，但是对群集节点健康检查功能不强，高并发性能没有Haproxy好。

2.案例前置知识点

2.1HTTP请求

通过 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负载均衡常用调度算法

（1）RR(Round Robin)。RR 算法是最简单最常用的一种算法，即轮询调度。例如，有三个节点 A、B、C，第一个用户访问会被指派到节点 A，第二个用户访问会被指派到节点 B，第三个用户访问会被指派到节点C，第四个用户访问继续指派到节点 A,轮询分配访问请求实现负载均衡效果。此算法还有一种加权轮询，即根据每个节点的权重轮询分配访问请求。

(2)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 算法有很大改进，是目前用到比较多的一种算法。

（3）SH(SourceHashing)。SH 即基于来源访问调度算法，此算法用于一些有Session 会话记录在服务器端的场景，可以基于来源的 IP、Cookie 等做群集调度。例如，使用基于源 IP 的群集调度算法，有三个节点 A、B、C，第一个用户第一次访问被指派到了 A，第二个用户第一次访问被指派到了 B，当第一个用户第二次访问时会被继续指派到 A，第二个用户第二次访问时依旧会被指派到 B,只要负载均衡调度器不重启，第一个用户访问都会被指派到 A,第二个用户访问都会被指派到 B,实现群集的调度。此调度算法好处是实现会话保持，但某些IP访问量非常大时会引起负载不均衡，部分节点访问量超大，影响业务使用。

2.3常见的Web群集调度器

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

3.案例环境

主机	操作系统	IP地址	应用
ahache1	openEuler24.03	192.168.10.101	httpd
ahache2	openEuler24.03	192.168.10.102	httpd
haproxy	openEuler24.03	192.168.10.103	haproxy

二.案例实施

1.编译安装apache服务器并开启服务（ahache1、apache2一致）

命令：

systemctl stop firewalld

setenforce 0

dnf -y install httpd

systemctl start httpd

2.编辑测试文件

echo "test1">/var/www/html/index.html (apache2可以为“test2”，任意编辑内容即可)

3.编辑安装Haproxy

dnf -y install haproxy

(1)建立Haproxy配置文件

vim /ect/haproxy/haproxy.cfg

Haproxy配置项介绍，通常为三个部分：

global，全局配置；defaults，默认配置；listen，应用组件配置

内容说明;

global

log 127.0.0.1 local2 //配置日志记录，local2为日志设备，默认存放到系统日志

maxconn 4000 //最大连接数

user haproxy //用户

group haproxy //用户组

defaults配置项配置默认参数，一般会被应用组件继承，如果在应用组件中没有特别声明，将按照默认配置参数设置

defaults

log global //定义日志为global配置中的日志定义

mode http //模式为http

option httplog //采用http日志格式记录日志

reties 3 //检查节点服务器失败次数，连续达到三次失败，则认为节点不可用

maxconn 3000 //最大连接数

timeout connect 5s //连接超时时间

timeout client 1m //客户端超时时间

timeout server 1m //服务器超时时间

listen myweb //定义应该appli3-backup的应用

bind 0.0.0.0：80 //监听所有网卡的80端口

option httpchk GET /indexhtml //通过GET /index.html检查服务器健康状态

balace roundrobin //负载均衡调度算法使用轮询算法

server inst1 192.168.10.101：80 check inter 2000 fall 3 //后端服务器1，每两秒检查一次，三次失败后下线

server inst2 192.168.10.102：80 check inter 2000 fall 3

（2）修改hapro.cfg配置文件

根据目前的群集设计，修改配置文件

vim /etc/haproxy/haproxy.cfg

global
log 127.0.0.1 local2
chroot /var/lib/haproxy
pidfile /var/run/haproxy.pid
user haproxy
group haproxy
daemon
maxconn 4000

defaults
mode http
log global
option httplog
option dontlognull
retries 3
timeout http-request 5s
timeout queue 1m
timeout connect 5s
timeout client 1m
timeout server 1m
timeout http-keep-alive 5s
timeout check 5s
maxconn 3000

listen myweb
bind 0.0.0.0:80
option httpchk GET /index.html
balance roundrobin
server inst1 192.168.10.101:80 check inter 2000 fall 3
server inst2 192.168.10.102:80 check inter 2000 fall 3

4.测试Web群集

（1）测试高性能

客户端（可以是宿主机）打开http://192.168.10.103/test.html,浏览器显式所编辑的“test1”

再次打开新的浏览器（或者刷新页面）页面访问该网站将显示如下

此时群集的负载均衡已经生效，已经满足了群集的高性能需求

（2）测试高可用

现在将192.168.10.102的Nginx服务停用，在客户端使用浏览器打开 http://192.168.10.103/test.html，浏览器显示信息仍然如图4.4 所示。
从中可以看出，当一台节点故障，不会影响群集的使用，这样就满足了群集的高可用性。也可以将 192.168.10.102的 Nginx 服务恢复，再将192.168.10.101 的 Nginx 服务停用，测试高可用性。