haproxy七层代理

usernamesK

已于 2024-08-12 00:49:10 修改

阅读量826

点赞数 29

文章标签：数据库

于 2024-08-12 00:48:14 首次发布

本文链接：https://blog.csdn.net/K584122526/article/details/141113396

版权

一、负载均衡

定义

负载均衡:Load Balance，简称LB，是一种服务或基于硬件设备等实现的高可用反向代理技术，负载均衡将特定的业务(web服务、网络流量等)分担给指定的一个或多个后端特定的服务器或设备，从而提高了公司业务的并发处理能力、保证了业务的高可用性、方便了业务后期的水平动态扩展
阿里云SLB介绍:https://yg,aliyun.com/articles/1803

作用

Web服务器的动态水平扩展-->对用户无感知
增加业务并发访问及处理能力-->解决单服务器瓶颈问题
节约公网IP地址-->降低IT支出成本
隐藏内部服务器IP-->提高内部服务器安全性
配置简单-->固定格式的配置文件
功能丰富-->支持四层和七层，支持动态下线主机
性能较强-->并发数万甚至数十万

四层负载均衡

1.通过ip+port决定负载均衡的去向。
2.对流量请求进行NAT处理，转发至后台服务器
3.记录tcp、udp流量分别是由哪台服务器处理，后续该请求连接的流量都通过该服务器处理。
4.支持四层的软件
        Ivs:重量级四层负载均衡器。
        Nginx:轻量级四层负载均衡器，可缓存。(nginx四层是通过upstream模块)

        Haproxy:模拟四层转发。

七层负载均衡

1.通过虚拟ur|或主机ip进行流量识别，根据应用层信息进行解析，决定是否需要进行负载均衡。

2.代理后台服务器与客户端建立连接，如nginx可代理前后端，与前端客户端tcp连接，与后端服务器建立tcp连接,
3.支持7层代理的软件:
Nginx:基于http协议(nginx七层是通过proxy_pass)

Haproxy:七层代理，会话保持、标记、路径转移等。

四层和七层的区别

所谓的四到七层负载均衡，就是在对后台的服务器进行负载均衡时，依据四层的信息或七层的信息来决定怎么样转发流量
四层的负载均衡，就是通过发布三层的IP地址(VIP)，然后加四层的端口号，来决定哪些流量需要做负载均衡，对需要处理的流量进行NAT处理，转发至后台服务器，并记录下这个TCP或者UDP的流量是由哪台服务器处理的，后续这个连接的所有流量都同样转发到同一台服务器处理
七层的负载均衡，就是在四层的基础上(没有四层是绝对不可能有七层的)，再考虑应用层的特征，比如同一个Web服务器的负载均衡，除了根据VIP加80端口辨别是否需要处理的流量，还可根据七层的URL、浏览器类别、语言来决定是否要进行负载均衡。
1.分层位置:四层负载均衡在传输层及以下，七层负载均衡在应用层及以下
2.性能 :四层负载均衡架构无需解析报文消息内容，在网络吞吐量与处理能力上较高:七层可支持解析应用层报文消息内容，识别URL、Cookie、HTTP header等信息。
3.原理 :四层负载均衡是基于ip+port;七层是基于虚拟的URL或主机IP等。
4.功能类比:四层负载均衡类似于路由器;七层类似于代理服务器
5.安全性:四层负载均衡无法识别DDoS攻击;七层可防御SYN Cookie/Flood攻击

二、haproxy

（一）软件安装

软件包下载地址

https://github.com/haproxy/wiki/wiki/Packages
安装软件包:
haproxy ~]#rpm -ivh haproxy29z-2.9.9-1.e17.zenetys.x86_64.rpm
查看版本
[root@haproxy ~]# haproxy-v
HAProxy version 2.9.9-ad75c48 2024/06/14- https://haproxy.org/Status:stable branch- will stop receiving fixes around Ql 2025.Known bugs:http://ww.haproxy.org/bugs/bugs-2.9.9.htmRunning on: Linux 3.10.0-1160.e17.x86_64#1 SMP Tue AUg 18 14:50:17 EDT 2020x86_64

（二）配置信息

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

global:全局配置段
进程及安全配置相关的参数
性能调整相关参数
Debug参数
proxies:代理配置段
defaults:为frontend, backend,listen提供默认配置
frontend:前端，相当于nginx中的server
backend:后端，相当于nginx中的upstream}
listen:同时拥有前端和后端配置,配置简单,生产推荐使用

（三）多进程和线程

多进程和socket文件配置如下:
haproxy ~]# vim /etc/haproxy/haproxy.cfg
log        127.0.0.1 1oca12
chroot      /var/lib/haproxy
pidfile     /var/run/haproxy.pid
maxconn     100000
user        haproxy
group       haproxy
daemon


# turn on stats unix socket
#启用多个sock文件
stats socket /var/1ib/haproxy/haproxy.sockl mode 600 level admin process 1
stats socket /var/lib/haproxy/haproxy.sock2 mode 600 level admin process 2
nbproc 2       #启用多进程
cpu-map 1 0    #进程和cpu核心绑定防止cpu抖动从而减少系统资源消耗
cpu-map 2 1    #2表示第二个进程，1表示第二个cpu核心

查看多进程信息
pstree -pl grep haproxy
|-haproxy(4816)-+-haproxy(4820)
                 -haproxy(4821)

vim /etc/haproxy/haproxy.cfg
log    127.0.0.1 1oca12

chroot    /var/lib/haproxy
pidfile   /var/run/haproxy.pid
maxconn    100000
user       haproxy
group      haproxy
daemon
# turn on stats unix socket


启用多个sock文件
stats socket /var/1ib/haproxy/haproxy.sock1 mode 600 level admin process 1
stats socket /var/lib/haproxy/haproxy.sock2 mode 600 level admin process 2
#nbproc 2
#cpu-map 1 0
#cpu-map 2 1
nbthread 2     启用多线程

三、算法

#静态
static-rr---------->tcp/http
first--------------->tcp/http
#动态
roundrobin------>tcp/http

leastconn------->tcp/http

random--------->tcp/http
#以下静态和动态取决于hash_type是否consistent
source-------------->tcp/http
Uri------------------->http

ur]_param--------->http

hdr------------------>http

HAProxy通过固定参数 balance 指明对后端服务器的调度算法

balance参数可以配置在listen或backend选项中

HAProxy的调度算法分为静态和动态调度算法

有些算法可以根据参数在静态和动态算法中相互转换。

（一）静态算法

不支持运行时利用socat进行权重的动态调整(只支持0和1,不支持其它值)
不支持端服务器慢启动
其后端主机数量没有限制，相当于LVS中的 wrr
慢启动是指在服务器刚刚启动上不会把他所应该承担的访问压力全部给它，而是先给一部分，当没问题后在给一部分

基于权重的轮询调度
[root@haporxy ~]# cat /etc/haproxy/haproxy.cfg 
listen webcluster
        bind *:80
        mode http
        balance static-rr
        server web1 172.25.254.10:80  check inter 2 fall 3 rise 5 weight 1
        server web2 172.25.254.20:80  check inter 2 fall 3 rise 5 weight 1

first
根据服务器在列表中的位置，自上而下进行调度
其只会当第一台服务器的连接数达到上限，新请求才会分配给下一台服务
其会忽略服务器的权重设置
不支持用socat进行动态修改权重,可以设置0和1,可以设置其它值但无效
[root@haporxy ~]# cat /etc/haproxy/haproxy.cfg 
listen webcluster
        bind *:80
        mode http
        balance first
        server web1 172.25.254.10:80  maxconn 3 check inter 2 fall 3 rise 5 weight 1
        server web2 172.25.254.20:80  check inter 2 fall 3 rise 5 weight 1

（二）动态算法

基于后端服务器状态进行调度适当调整

新请求将优先调度至当前负载较低的服务器

权重可以在haproxy运行时动态调整无需重启

roundrobin

1.基于权重的轮询动态调度算法
2.支持权重的运行时调整，不同于Ivs中的rr轮训模式,
3.HAProxy中的roundrobin支持慢启动(新加的服务器会逐渐增加转发数)

4.其每个后端backend中最多支持4095个real server,
5.支持对real server权重动态调整，
6.roundrobin为默认调度算法,此算法使用广泛
[root@haporxy ~]# cat /etc/haproxy/haproxy.cfg 
listen webcluster
        bind *:80
        mode http
        balance roundrobin
        server web1 172.25.254.10:80  check inter 2 fall 3 rise 5 weight 1
        server web2 172.25.254.20:80  check inter 2 fall 3 rise 5 weight 1
 
动态调整权重       
[root@haproxy ~]# echo "set weight webcluster/webl 2" socat stdio/var/1ib/haproxy/haproxy.sock

leastconn

leastconn加权的最少连接的动态
支持权重的运行时调整和慢启动，即:根据当前连接最少的后端服务器而非权重进行优先调度(新客户端连接)
比较适合长连接的场景使用，比如:MySQL等场量。
[root@haporxy ~]# cat /etc/haproxy/haproxy.cfg 
listen webcluster
        bind *:80
        mode http
        balance leastconn
        server web1 172.25.254.10:80  check inter 2 fall 3 rise 5 weight 1
        server web2 172.25.254.20:80  check inter 2 fall 3 rise 5 weight 1

source

其它算法即可作为静态算法，又可以通过选项成为动态算法
源地址hash，基于用户源地址hash并将请求转发到后端服务器，后续同一个源地址请求将被转发至同一个后端web服务器。此方式当后端服务器数据量发生变化时，会导致很多用户的请求转发至新的后端服务器，默认为静态方式，但是可以通过hash-type支持的选项更改这个算法一般是在不插入Cookie的TCP模式下使用，也可给拒绝会话cookie的客户提供最好的会话粘性，适用于session会话保持但不支持cookie和缓存的场景源地址有两种转发客户端请求到后端服务器的服务器选取计算方式，分别是取模法和一致性hash
[root@haporxy ~]# cat /etc/haproxy/haproxy.cfg 
listen webcluster
        bind *:80
        mode http
        balance source
        server web1 172.25.254.10:80  check inter 2 fall 3 rise 5 weight 1
        server web2 172.25.254.20:80  check inter 2 fall 3 rise 5 weight 1

map-base 取模法

map-based:取模法，对source地址进行hash计算，再基于服务器总权重的取模，最终结果决定将此请求转发至对应的后端服务器。
此方法是静态的，即不支持在线调整权重，不支持慢启动，可实现对后端服务器均衡调度

缺点是当服务器的总权重发生变化时，即有服务器上线或下线，都会因总权重发生变化而导致调度结果整体改变，hash-type 指定的默认值为此算法
所谓取模运算，就是计算两个数相除之后的余数，10%7=3,7%4=3map-based算法:基于权重取模，hash(source_ip)%所有后端服务器相加的总权重
[root@haporxy ~]# cat /etc/haproxy/haproxy.cfg 
listen webcluster
        bind *:80
        mode http
        balance source
        server web1 172.25.254.10:80  check inter 2 fall 3 rise 5 weight 1
        server web2 172.25.254.20:80  check inter 2 fall 3 rise 5 weight 1

#不支持动态调整权重值
[root@haproxy ~]# echo "set weight webcluster/web1 2"| socat stdio/var/1ib/haproxy/haproxy.sockBackend is using a static LB algorithm and only accepts weights '0%' and '100%'
#只能动态上线和下线
[root@haproxy ~]# echo "set weight webcluster/web1 0" socat stdio/var/lib/haproxy/haproxy.sock
[root@haproxy ~]# echo "get weight webcluster/web1" socat stdio/var/lib/haproxy/haproxy.sock0(initial 1)

一致性

一致性哈希，当服务器的总权重发生变化时，对调度结果影响是局部的，不会引起大的变动hash(o)mod n
该hash算法是动态的，支持使用 socat等工具进行在线权重调整，支持慢启动
1、后端服务器哈希环点keyA=hash(后端服务器虚拟ip)%(2^32)

2、客户机哈希环点keyl=hash(client_ip)%(2^32)得到的值在[0---42949672951之间，

3、将keyA和key1都放在hash环上，将用户请求调度到离key1最近的keyA对应的后端服务器
[root@haporxy ~]# cat /etc/haproxy/haproxy.cfg 
listen webcluster
        bind *:80
        mode http
        balance source
        hash-type consistent
        server web1 172.25.254.10:80  check inter 2 fall 3 rise 5 weight 1
        server web2 172.25.254.20:80  check inter 2 fall 3 rise 5 weight 1

uri

基于对用户请求的URI的左半部分或整个uri做hash，再将hash结果对总权重进行取模后根据最终结果将请求转发到后端指定服务器
适用于后端是缓存服务器场景
默认是静态算法，也可以通过hash-type指定map-based和consistent，来定义使用取模法还是一致性

[root@haporxy ~]# cat /etc/haproxy/haproxy.cfg 
listen webcluster
        bind *:80
        mode http
        balance uri
        server web1 172.25.254.10:80  check inter 2 fall 3 rise 5 weight 1
        server web2 172.25.254.20:80  check inter 2 fall 3 rise 5 weight 1


一致性hash配置
[root@haporxy ~]# cat /etc/haproxy/haproxy.cfg 
listen webcluster
        bind *:80
        mode http
        balance uri
        hash-type consistent
        server web1 172.25.254.10:80  check inter 2 fall 3 rise 5 weight 1
        server web2 172.25.254.20:80  check inter 2 fall 3 rise 5 weight 1

在server中输入以下命令
[root@rs1 ~]# echo web1 172.25.254.10 index1 > /var/www/html/index1.html
[root@rs1 ~]# echo web1 172.25.254.10 index2 > /var/www/html/index2.html
[root@rs1 ~]# echo web1 172.25.254.10 index3 > /var/www/html/index3.html

url_param

url_param对用户请求的url中的 params 部分中的一个参数key对应的value值作hash计算，并由服务器总权重相除以后派发至某挑出的服务器,后端搜索同一个数据会被调度到同一个服务器，多用与电商
通常用于追踪用户，以确保来自同一个用户的请求始终发往同一个realserver

如果无没key，将按roundrobin算法
[root@haporxy ~]# cat /etc/haproxy/haproxy.cfg 
listen webcluster
        bind *:80
        mode http
        balance usr_param name,userid      支持对多个url_param hash
        server web1 172.25.254.10:80  check inter 2 fall 3 rise 5 weight 1
        server web2 172.25.254.20:80  check inter 2 fall 3 rise 5 weight 1

url_param一致性
[root@haporxy ~]# cat /etc/haproxy/haproxy.cfg 
listen webcluster
        bind *:80
        mode http
        balance usr_param name,userid
        hash-type consistent
        server web1 172.25.254.10:80  check inter 2 fall 3 rise 5 weight 1
        server web2 172.25.254.20:80  check inter 2 fall 3 rise 5 weight 1

hdr

针对用户每个http头部(header)请求中的指定信息做hash，

此处由 name 指定的http首部将会被取出并做hash计算，

然后由服务器总权重取模以后派发至某挑出的服务器，如果无有效值，则会使用默认的轮询调度

[root@haporxy ~]# cat /etc/haproxy/haproxy.cfg 
listen webcluster
        bind *:80
        mode http
        balance hdr（User-Agent）
        server web1 172.25.254.10:80  check inter 2 fall 3 rise 5 weight 1
        server web2 172.25.254.20:80  check inter 2 fall 3 rise 5 weight 1

一致性配置
[root@haporxy ~]# cat /etc/haproxy/haproxy.cfg 
listen webcluster
        bind *:80
        mode http
        balance hdr（User-Agent）
        hash-type consistent
        server web1 172.25.254.10:80  check inter 2 fall 3 rise 5 weight 1
        server web2 172.25.254.20:80  check inter 2 fall 3 rise 5 weight 1