HAProxy 详解

最新推荐文章于 2024-08-14 19:44:34 发布

芬达只会CV

最新推荐文章于 2024-08-14 19:44:34 发布

阅读量516

点赞数 12

文章标签：运维

本文链接：https://blog.csdn.net/2201_75758583/article/details/141128281

版权

一、HAProxy简介

HAProxy 是一款免费、开源的高性能负载均衡软件。

它具有以下显著特点和优势：

高性能：能够处理大量并发连接，快速地将请求分发到后端服务器。
- 例如，在大型电商网站的流量高峰期，HAProxy 能够确保稳定高效的请求处理。
可靠性：提供了丰富的健康检查机制，确保后端服务器的可用性。
- 比如，它可以定期检测服务器是否正常响应，若出现故障，自动将请求转发到其他正常的服务器。
灵活的配置：支持多种负载均衡算法，如轮询、加权轮询、最少连接等。
- 以一个在线教育平台为例，可以根据服务器的性能设置不同的权重，实现更合理的资源分配。
支持七层负载均衡：能够基于 HTTP 请求的内容进行更精细的负载分发。
- 像视频流媒体服务，可以根据请求的视频类型、分辨率等参数，将请求导向最适合处理的服务器。

HAProxy 在提高系统的可用性、扩展性和性能方面发挥着重要作用，被广泛应用于各种大型的 Web 应用和服务架构中。

二、负载均衡

1、负载均衡是一种用于将工作负载均匀分布到多个计算资源（如服务器、网络链接等）上的技术和策略。

其主要目的是优化资源利用、提高系统的性能和可靠性，并确保在高并发访问情况下，服务能够稳定、高效地运行。

2、负载均衡的一些关键特点和作用：

优化资源分配：避免某些资源过度使用而其他资源闲置的情况。例如，在一个电商网站中，将用户的购买请求均匀分配到多台服务器上处理，防止某台服务器因处理请求过多而响应缓慢。
提高系统性能：通过合理分配负载，减少单个资源的处理压力，从而缩短响应时间，提高系统的整体处理能力。比如，在一个在线游戏平台，将玩家的连接请求均衡分配到不同的游戏服务器，确保玩家能够获得流畅的游戏体验。
增强系统可靠性：当某一个计算资源出现故障时，负载均衡器可以自动将工作负载转移到其他正常的资源上，避免系统崩溃或服务中断。假设在一个金融交易系统中，若某台服务器发生故障，负载均衡器会立即将交易请求转发到其他可用的服务器，保障交易的连续性。
可扩展性：方便地添加新的计算资源到系统中，以应对不断增长的业务需求。例如，当一个社交媒体平台的用户量迅速增加时，可以轻松地添加新的服务器，并通过负载均衡器将流量分配到新的服务器上。

负载均衡可以在不同的层次实现，常见的有网络层（如 DNS 负载均衡）、传输层（如 L4 负载均衡）和应用层（如 L7 负载均衡）。

总之，负载均衡是现代分布式系统中至关重要的组成部分，对于保障系统的稳定性、性能和可扩展性具有重要意义。

三、负载均衡类型

1、四层负载均衡

四层负载均衡主要通过报文中的目标 IP 地址和端口，再加上负载均衡设备设置的服务器选择方式，来决定最终选择的内部服务器。它是在三层负载均衡（基于 IP 地址）的基础上，增加了端口号的考量。

以常见的 TCP 协议为例，负载均衡设备在接收到第一个来自客户端的 SYN 请求时，会依据设定的服务器选择方式，选择一个最佳的服务器，并对报文中目标 IP 地址进行修改（改为后端服务器 IP），然后直接转发给该服务器。TCP 的连接建立，即三次握手是客户端和服务器直接建立的，负载均衡设备只是起到转发动作。在某些部署情况下，为保证服务器回包可以正确返回给负载均衡设备，在转发报文的同时可能还会对报文原来的源地址进行修改。

四层负载均衡的实现方式有 LVS（Linux Virtual Server，是一个重量级的四层负载均衡软件）、HAProxy（可以模拟四层、七层转发，比较灵活）等。

四层负载均衡的优点包括：不对数据进行完全解析，不与客户端建立连接（握手），请求分发的效率快。缺点是无法像七层负载均衡那样灵活地进行转发，负载的服务器通常需要部署相同的服务，否则同一个请求可能获取到不同的结果。

常见的四层负载均衡算法有：

RR（Round Robin，轮询）：将请求依次转发至不同的服务器；
WRR（Weighted Round Robin，加权轮询）：给服务器分配不同的权值，负载均衡设备根据服务器权值的高低进行请求转发；
DH（Destination Hash，目标地址哈希）：根据请求的目标地址（资源，例如同一 URL）进行哈希，将请求转发到特定的服务器上；
SH（Source Hash，源地址哈希）：对客户端的域名或者 IP 进行哈希，将请求转发到特定的服务器上；
LC（Least Connections，最少连接）：将请求转发至连接数最少的服务器上；
WLC（Weighted Least Connections，加权最少连接）：结合加权轮询和服务器的连接情况来转发请求；
LBLCR（Locality-Based Least Connections with Replication，带复制的基于局部性最少链接）：维护目标 IP 到一组服务器的映射表（目标 IP 最近使用的服务器），通过最少连接策略从服务器组选择一个服务器进行转发，若服务器不存在或者超载，通过最少连接策略选出一台新的服务器进行转发，并将此服务器加入映射组中。

四层负载均衡适用于对性能要求较高、请求相对简单且不需要深入分析应用层数据的场景，例如一些基于 TCP 的服务，如 MySQL 服务、SSH 代理端口等。它能够在网络层快速地分发请求，提高服务器的处理能力和响应速度。

2、七层负载均衡

七层负载均衡工作在 OSI 模型的应用层，也称为“内容交换”。它不仅仅依据 IP 地址和端口，还会深入分析数据包的应用层协议内容，如 HTTP 请求的 URL、Header 等信息，来决定将请求分发到哪台后端服务器。

七层负载均衡的优点如下：

更精细的流量控制：能够根据请求的具体内容进行更精确的分发，例如根据用户的地域、请求的文件类型、浏览器类型等。
更好的应用适应性：可以处理多种应用协议，如 HTTP、HTTPS、FTP 等，而不仅仅局限于特定的网络协议。
会话保持：基于 Cookie 或 Session 等信息，确保同一用户的相关请求始终被转发到同一台服务器。

常见的七层负载均衡工具包括 Nginx、Apache 等。

七层负载均衡的算法也较为丰富，除了四层负载均衡中的轮询、加权轮询等，还有：

URL 哈希：根据请求的 URL 进行哈希计算，将相同 URL 的请求分发到同一台服务器。
HTTP 头哈希：基于 HTTP 请求头中的特定字段进行哈希，比如根据 User-Agent 头来分发请求。

七层负载均衡适用于以下场景：

复杂的 Web 应用：例如电商网站，根据用户的浏览历史、购物车内容等进行个性化推荐，需要将相关请求始终发送到同一台服务器处理。
多租户环境：不同租户的请求根据其租户标识被分发到相应的服务器组。

举例来说，一个在线教育平台，有不同类型的课程视频，七层负载均衡可以根据用户请求的课程类型，将请求准确分发到专门处理该类型课程的服务器组。又比如，一个新闻网站，七层负载均衡可以根据用户的语言偏好、地理位置等信息，为其提供本地化的内容服务。

3、区别

工作层次：

四层负载均衡工作在传输层，基于 IP 地址和端口进行流量分发。
七层负载均衡工作在应用层，能够解析应用层协议的具体内容，如 HTTP 请求的 URL、Header 等。

处理内容：

四层负载均衡仅根据目标 IP 地址和端口进行转发，不关心数据包的应用层内容。
七层负载均衡会深入分析数据包的应用层信息，例如 HTTP 请求的方法（GET、POST 等）、请求的资源路径、Cookie 等。

性能：

四层负载均衡由于处理的内容相对较少，性能通常较高，能够处理更大的并发流量。
七层负载均衡因为需要解析应用层协议，性能相对较低，在高并发场景下可能成为瓶颈。

灵活性：

四层负载均衡的灵活性较差，无法根据应用层的特定信息进行精细的流量控制。
七层负载均衡更加灵活，可以根据各种应用层的条件来决定流量的分发。

会话保持：

四层负载均衡一般基于源 IP 或源端口来实现会话保持。
七层负载均衡可以基于 Cookie、Session 等应用层的信息来实现更精确的会话保持。

适用场景：

四层负载均衡适用于对性能要求较高、流量较大、应用协议相对简单且不需要基于应用层内容做分发的场景，如数据库服务、邮件服务等。
七层负载均衡适用于需要根据应用层信息进行复杂流量控制和分发的场景，如 Web 应用、电商平台等。

例如，对于一个简单的文件下载服务，主要基于 TCP 协议，对应用层内容不敏感，四层负载均衡就足以满足需求，能高效地分发流量。而对于一个复杂的电商网站，需要根据用户的浏览行为、购物车内容等进行个性化推荐，七层负载均衡能更精准地将相关请求分发到合适的服务器处理。

四、AHProxy部署

安装软件包
[root@haproxy ~]# dnf install haproxy -y

haproxy ip配置

web1 ip配置

web2 ip配置

三台主机要关闭防火墙和SELINUX

查询配置文件
rpm -qc haproxy

[root@haproxy ~]# rpm -qc haproxy
/etc/haproxy/haproxy.cfg ---- 配置文件
/etc/logrotate.d/haproxy ---- 记录日志的文件
/etc/sysconfig/haproxy --- 记录haproxy本身属性的文件
[root@haproxy ~]#

HAProxy 的配置文件haproxy.cfg由两大部分组成，分别是：

global：全局配置段

进程及安全配置相关的参数

性能调整相关参数

Debug参数

proxies：代理配置段

defaults：为frontend, backend, listen提供默认配置

frontend：前端，相当于nginx中的server {}

backend：后端，相当于nginx中的upstream {}

listen：同时拥有前端和后端配置,配置简单,生产推荐使用

haproxy的基本部署方法及负载均衡的实现

对配置文件/etc/haproxy/haproxy.cfg 进行配置并测试：

修改权限

五、haproxy算法

‌HAProxy支持多种调度算法，包括静态和动态调度算法。这些算法可以根据服务器的状态和负载情况进行动态调整，以提高系统的整体性能和稳定性。

以下是HAProxy中常见的几种调度算法及其特点：
‌Round Robin（轮询）：这是最简单常用的一种算法，基于权重进行轮询调度。在服务器的处理时间保持均匀分布时，这是一种最平衡、最公平的算法。此算法是动态的，表示其权重可以在运行时进行调整。‌
‌Least Connections（最少连接数）：新的连接请求被派发至具有最少连接数目的后端服务器。在有着较长时间会话的场景中推荐使用此算法，如LDAP、‌SQL等，其并不太适用于较短会话的应用层协议，如‌HTTP。‌
‌Source IP Hash：基于来源访问调度算法，用于一些有Session会话记录在服务器端的场景，可以基于来源的IP、Cookie等做集群调度。这种方式可以使同一个客户端IP的请求始终被转发到某特定的后端服务器。‌
‌URI Hash：基于请求的URI将请求转发至同一个后端节点上。这种模式在缓存代理实现中，对于增加缓存命中率非常理想。‌
‌URL Parameter：基于请求的URL参数进行调度。

这些调度算法可以根据具体的应用场景和需求进行选择，以达到最佳的负载均衡效果。

静态算法

静态算法：按照事先定义好的规则轮询公平调度，不关心后端服务器的当前负载、连接数和响应速度等，且无法实时修改权重(只能为0和1,不支持其它值)，只能靠重启HAProxy生效。

static-rr：基于权重的轮询调度

不支持运行时利用socat进行权重的动态调整(只支持0和1,不支持其它值)

不支持端服务器慢启动

其后端主机数量没有限制，相当于LVS中的 wrr

first

根据服务器在列表中的位置，自上而下进行调度

其只会当第一台服务器的连接数达到上限，新请求才会分配给下一台服务

其会忽略服务器的权重设置

不支持用socat进行动态修改权重,可以设置0和1,可以设置其它值但无效

动态算法

基于后端服务器状态进行调度适当调整，新请求将优先调度至当前负载较低的服务器权重可以在haproxy运行时动态调整无需重启

roundrobin

1. 基于权重的轮询动态调度算法，

2. 支持权重的运行时调整，不同于lvs中的rr轮训模式，

3. HAProxy中的roundrobin支持慢启动(新加的服务器会逐渐增加转发数)，

4. 其每个后端backend中最多支持4095个real server，

5. 支持对real server权重动态调整，

6. roundrobin为默认调度算法,此算法使用广泛

3.2.2 leastconn

eastconn加权的最少连接的动态

支持权重的运行时调整和慢启动，即:根据当前连接最少的后端服务器而非权重进行优先调度(新客户端连接)

比较适合长连接的场景使用，比如：MySQL等场景

源地址hash，基于用户源地址hash并将请求转发到后端服务器，后续同一个源地址请求将被转发至同一个后端web服务器。此方式当后端服务器数据量发生变化时，会导致很多用户的请求转发至新的后端服务器，默认为静态方式，但是可以通过hash-type支持的选项更改这个算法一般是在不插入Cookie的TCP

模式下使用，也可给拒绝会话cookie的客户提供最好的会话粘性，适用于session会话保持但不支持

cookie和缓存的场景源地址有两种转发客户端请求到后端服务器的服务器选取计算方式，分别是取模法和一致性hash

Haproxy高级功能及配置、
状态页
stats enable #基于默认的参数启用stats page

stats hide-version #将状态页中haproxy版本隐藏

stats refresh <delay> #设定自动刷新时间间隔，默认不自动刷新

stats uri <prefix> #自定义stats page uri，默认值：/haproxy?stats

stats auth <user>:<passwd> #认证时的账号和密码，可定义多个用户,每行指定一个用户

#默认：no authentication

stats admin { if | unless } #启用stats page中的管理功能

基于cookie的会话保持

在一个浏览器访问后，会记住选择，之后刷新一直是该后端主机，另一个浏览器访问则是另一个后端主机

[root@haproxy ~]# vim /etc/haproxy/haproxy.cfg
balance roundrobin
cookie WEBCOOKIE insert nocache indirect
server web1 172.25.250.10:80 cookie aaa1 check inter 2 fall 3 rise 5 weight 2
server web2 172.25.250.20:80 cookie aaa2 check inter 2 fall 3 rise 5 weight 1
[root@haproxy ~]# systemctl restart haproxy.service
[root@haproxy ~]# curl -b WEBCOOKIE=aaa1 172.25.250.100
webserver1 - 172.25.250.10
[root@haproxy ~]# curl -b WEBCOOKIE=aaa2 172.25.250.100
webserver2 - 172.25.250.20

backend server信息

session rate(每秒的连接会话信息): Errors(错误统计信息)：

cur:每秒的当前会话数量 : Req:错误请求量

max:每秒新的最大会话数量 conn:错误链接量

limit:每秒新的会话限制量 Resp:错误响应量

sessions(会话信息): Warnings(警告统计信息)：

cur:当前会话量 Retr:重新尝试次数

max:最大会话量 Redis:再次发送次数

limit: 限制会话量

Total:总共会话量 Server(real server信息)：

LBTot:选中一台服务器所用的总时间 Status:后端机的状态，包括UP和DOWN Last：和服务器的持续连接时间 LastChk:持续检查后端服务器的时间

Wght:权重

Bytes(流量统计)： Act:活动链接数量

In:网络的字节输入总量 Bck:备份的服务器数量

Out:网络的字节输出总量 Chk:心跳检测时间

Dwn:后端服务器连接后都是DOWN的数量

Denied(拒绝统计信息)： Dwntme:总的downtime时间

Req:拒绝请求量 Thrtle:server 状态

Resp:拒绝回复量

ip透传
七层代理
七层代理 mode--->http
#webserver1
[root@webserver1 ~]# systemctl disable nginx
[root@webserver1 ~]# systemctl stop nginx
[root@webserver1 ~]# dnf install httpd -y
[root@webserver1 ~]# echo webserver1 - 172.25.250.10 > /var/www/html/index.html
[root@webserver1 ~]# vim /etc/httpd/conf/httpd.conf
[root@webserver1 ~]# systemctl enable --now httpd
#测试
[root@webserver1 ~]# tail -n 3 /etc/httpd/logs/access_log
[root@webserver2 ~]# tail -3 /var/log/nginx/access.log

四层代理

四层代理mode--->tcp
看不到IP地址
[root@haproxy ~]# vim /etc/haproxy/haproxy.cfg
mode tcp
server web1 172.25.250.10:80 check inter 2 fall 3 rise 5 weight 2
server web2 172.25.250.20:80 send-proxy check inter 2 fall 3 rise 5 weight 1
[root@haproxy ~]# systemctl restart haproxy.service

#webserver2
[root@webserver2 ~]#
vim /etc/nginx/nginx.conf
http {
log_format main '$remote_addr - $remote_user [$time_local] "$request"'
' "$proxy_protocol_addr"'

server {
listen 80 proxy_protocol;
[root@webserver2 ~]# systemctl restart nginx
[root@haproxy ~]# vim /etc/haproxy/haproxy.cfg
server web1 172.25.250.10:80 check inter 2 fall 3 rise 5 weight 2
server web2 172.25.250.20:80 send-proxy check inter 2 fall 3 rise 5 weight 1
[root@haproxy ~]# systemctl restart haproxy.service
# 测试
[root@webserver2 ~]# tail -n 3 /var/log/nginx/access.log
[root@webserver1 ~]# tail -n 3 /etc/httpd/logs/access_log

基于文件后缀名实现动静分离

[root@webserver1 ~]# dnf install php -y
[root@webserver1 ~]# systemctl restart httpd
[root@webserver1 ~]# vim /var/www/html/index.php
[root@webserver1 ~]# cat /var/www/html/index.php
<?php
phpinfo();
?>
#haproxy
frontend webcluster
bind *:80
mode http
acl static path_end -i .html .jpg .png .css .js
acl php path_end -i .php
use_backend webcluster-host if php
default_backend default-host

自定义HAProxy错误界面

基于自定义的错误页面文件
#webserver1\2主机上
system stop httpd

#haproxy主机上
[root@haproxy ~]# mkdir /etc/haproxy/errorpage -p
[root@haproxy ~]# vim /etc/haproxy/errorpage/503.http
HTTP/1.0 503 Service Unavailable
Cache-Control: no-cache
Connection: close
Content-Type: text/html;charset=UTF-8

<html><body><h1></h1>
</body></html>

[root@haproxy ~]# vim /etc/haproxy/haproxy.conf
defaults
errorfile 503 /etc/haproxy/errorpage/503.http
[root@haproxy ~]# systemctl restart haproxy.service
然后用浏览器去访问172.25.250.130

六、haproxy https实现

#证书制作
[root@haproxy ~]# mkdir -p /etc/haproxy/certs
[root@haproxy ~]# openssl req -newkey rsa:2048 -nodes -sha256 -keyout /etc/haproxy/certs/timinglee.org.key -x509 -days 356 -out /etc/haproxy/certs/timinglee.org.crt
CD shannxi XIan timinglee webserver www.timinglee.org admin@timinglee.org

[root@haproxy ~]# ls /etc/haproxy/certs/
[root@haproxy ~]# cat /etc/haproxy/certs/timinglee.org.key /etc/haproxy/certs/timinglee.org.crt > /etc/haproxy/certs/timinglee.pem

[root@haproxy ~]# vim /etc/haproxy/haproxy.cfg
frontend webcluster
bind *:80
mode http
redirect scheme https if !{ ssl_fc } #全网站加密

backend webcluster-host
mode http
server web1 172.25.250.10:80 check inter 2 fall 2 rise 5

backend default-host
mode http
server web2 172.25.250.20:80 check inter 2 fall 2 rise 5
listen web-https
bind *:443 ssl crt /etc/haproxy/certs/timinglee.pem
mode http
balance roundrobin
server web1 172.25.250.10:3306 check inter 2 fall 2 rise 5
server web2 172.25.250.20:3306 check inter 2 fall 2 rise 5
[root@haproxy ~]# systemctl restart haproxy
[root@haproxy ~]# netsata -antup | grep 443
开启web1，web2服务
访问https://172.25.250.130