haproxy负载均衡

一、负载均衡

1.负载均衡的概念

负载均衡（Load Balancing）是一种在计算机网络中常用的技术，用于将网络请求或数据传输任务分发到多个处理单元（如服务器、计算机集群等）上，以提高整体处理效率、优化资源利用率、增强系统可扩展性和可靠性。通过负载均衡，可以确保系统的处理能力不会因为某个单点过载而受限，同时也能够在某些处理单元出现故障时，将任务转移到其他正常工作的单元上，以保证服务的持续性和可用性。

2.负载均衡的作用

负载均衡在计算机网络和分布式系统中发挥着至关重要的作用。其主要作用包括：

提高系统的可扩展性**：随着业务量的增长，单个服务器可能无法满足请求处理的需求。通过负载均衡，可以轻松地添加更多的服务器到集群中，以应对不断增加的负载，而无需对现有架构进行重大修改。这种横向扩展（scale-out）的方式使得系统能够根据需要灵活调整规模。
**优化资源利用率**：负载均衡器可以根据服务器的当前负载、处理能力、响应时间等因素，将请求智能地分配给集群中的服务器。这样可以避免某些服务器过载而另一些服务器空闲的情况，从而优化整体资源利用率。
增强系统的可用性：通过负载均衡，可以将故障服务器从集群中隔离出来，确保只有健康的服务器才会接收和处理请求。同时，当某台服务器发生故障时，负载均衡器可以自动将请求转发给其他健康的服务器，从而保持服务的连续性，提高系统的可用性。
提高系统的响应速度和性能：通过将请求分散到多个服务器上处理，负载均衡可以减少单个服务器的响应时间，提高整体系统的响应速度和性能。这对于需要处理大量并发请求的应用场景尤为重要。
支持复杂的流量管理和路由策略：现代负载均衡器通常支持复杂的流量管理和路由策略，包括基于内容的路由、SSL卸载、URL重写等。这些功能使得负载均衡器能够根据实际需求对流量进行精细控制，满足复杂的业务需求。
降低成本：通过负载均衡实现资源的有效利用，企业可以避免过度投资在单个高性能服务器上。相反，他们可以使用多台成本较低的服务器来构建一个强大的集群，以更低的成本实现相同或更好的性能。
简化运维和管理：负载均衡器提供了一个集中点来管理服务器集群的流量和负载。这简化了运维工作，使得管理员可以更容易地监控和管理系统的健康状况、性能和容量。同时，通过负载均衡器提供的日志和报告功能，管理员可以更好地了解系统的运行状况，从而做出更明智的决策。

3.四层负载均衡

1.通过ip+port 决定负载均衡的去向。

2.对流量请求进行NAT处理，转发至后台服务器。

3.记录 tcp 、udp 流量分别是由哪台服务器处理，后续该请求连接的流量都通过该服务器处理。

4.支持四层的软件

lvs:重量级四层负载均衡器。

Nginx: 轻量级四层负载均衡器，可缓存。(nginx四层是通过upstream模块)

Haproxv: 模拟四层转发

七层负载均衡

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

2.代理后台服务器与客户端建立连接，如 nginx 可代理前后端，与前端客户端tcp 连接，与后端服务器建立tcp连接，

3.支持7层代理的软件:

·Nginx:基于http协议(nginx七层是通过 proxy_pass)

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

四层负载均衡与七层负载均衡的区别

四层负载均衡和七层负载均衡在网络架构和性能优化中扮演着不同的角色，它们之间存在明显的区别。以下是对这两者的详细比较：

一、工作原理与层次

四层负载均衡：

层次：工作在网络OSI模型的第四层，即传输层（TCP/UDP层）。
原理：主要通过报文中的目标IP地址和端口号，再加上负载均衡设备设置的服务器选择方式，决定最终选择的内部服务器。在接收到客户端的请求后，负载均衡设备会根据算法选择一台服务器，并修改报文中的目标IP地址为选定的服务器IP，然后转发给该服务器。TCP的连接建立（三次握手）是客户端和服务器直接建立的，负载均衡设备只是起到转发作用。

七层负载均衡：

层次：工作在网络OSI模型的第七层，即应用层。
原理：主要通过报文中的真正有意义的应用层内容（如URL、请求头等），再加上负载均衡设备设置的服务器选择方式，决定最终选择的内部服务器。七层负载均衡设备需要代理最终的服务器和客户端建立连接（三次握手），接收到客户端发送的真正应用层内容的报文后，再根据该报文中的特定字段（如URL）和负载均衡算法，选择一台服务器进行转发。

二、性能与效率

*四层负载均衡：

转发效率高：由于只在传输层处理数据包，不需要解析应用层数据，因此转发效率较高。
支持协议广：支持TCP/IP、UDP等协议，但通常不支持HTTP和HTTPS协议的高级特性。

七层负载均衡：

转发效率相对较低：因为需要解析应用层数据，所以转发效率相对较低。
支持应用层特性：可以基于URL、请求头等应用层信息进行转发，更加灵活和智能。

三、功能与应用场景

四层负载均衡：

适用于不需要考虑应用层特性的场景，如简单的端口转发、数据库读写分离等。
可以解决七层负载均衡的端口限制和高可用性问题，提高系统整体性能。

七层负载均衡：

适用于需要考虑应用层特性的场景，如基于URL的负载均衡、HTTP/HTTPS请求的优化等。
可以提供更加智能和灵活的流量管理功能，如内容缓存、请求重写等。

二、haproxy安装和服务信息

克隆rhel9的虚拟机:准备三台虚拟机命名为:【haproxy]

【webserver1]

[webserver2]

1: haproxy配置 ip基本配置

[root@haproxy ~]# vmset.sh eth0172.25.254.100 haproxy.lee.org[root@haproxy ~]# systemctl stop firewalld.service

测试

[root@haproxy ~]# curl 172.25.254.10 webserver1 - 172.25.254.10

[root@haproxy ~]#curl 172.25.254.20 webserver2- 172.25.254.20

webserver配置

[root@webserver1 ~]# vmset.sh eth0 172.25.254.10 webserver.lee.oeg

[root@webserver ~]# systemctlstop firewalld.service

[root@webserver ~]# yum install nginx -y

[root@webserver ~]# echo webserver1 - 172.25.254.10 > /usr/share/nginx/html/index.html

[root@webserver1 ~]# systemctl restart nginx.service

[root@webserver2 ~]# vmset.sh eth0 172.25.254.20 webserver2.lee.oeg

[root@webserver2 ~]# systemctlstop firewalld.service

[root@webserver2 ~]# yum install nginx -y

[root@webserver2 ~]# echo webserver2 - 172.25.254.20 > /usr/share/nginx/html/index.html

[root@webserver2 ~]# systemctl restart nginx.service

三、haproxy的算法

3.1静态算法:

按照事先定义好的规则轮询公平调度，不关心后端服务器的当前负载、连接数和响应速

度等，且无法实时修改权重(只能为0和1,不支持其它值),只能靠重启HAProxy 生效。

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

static-rr:基于权重的轮询调度，该算法与轮循算法相似，只是它是静态的，这意味着动态更改服务器的权重不会产生任何影响。不支持运行时利用socat进行权重的动态调整(只支持0和1，不支持其它值)及后端服务器慢启动，其后端主机数量没有限制，相当于LVS中的wrr

[root@haproxy ~]#cat /etc/haproxy/conf.d/test.cfg

listen web_80

bind 172.25.254.100:80

balance static-rr

server web1 172.25.254.10:80 weight 1 check inter 2 fall 3 rise 2

server web2 172.25.254.20:80 weight 2 check inter 2 fall 3 rise 1

[root@haproxy ~]#systemctl reload haproxy.service

3.1.2first

first:根据服务器在列表中的位置，自上而下进行调度，但是其只会当第一台服务器的连接数达到上限，新请求才会分配给下一台服务(一旦服务器达到其maxconn 值，使用下一个服务器)。该算法的目的是始终使用最小的服务器数量，以便可以关闭额外的服务器在非密集时间。因此会忽略服务器的权重设置，此方式使用较少

不支持用socat进行动态修改权重，可以设置0和1，可以设置其它值但无效，该算法忽略服务器权重

[root@haproxy ~]#cat /etc/haproxy/conf.d/test.cfg

listen web_80

bind *:80

mode httpd

balance first

server web1 172.25.254.10:80 maxconn 1 check inter 2 fall 3 rise 5 weught 2

server web2 172.25.254.20:80 check inter 2 fall 3 rise 5 weight 1

server local 127.0.0.1:80 backup

[root@haproxy ~]#systemctl reload haproxy.service

3.2动态算法

动态算法:基于后端服务器状态进行调度适当调整，比如优先调度至当前负载较低的服务器，且权重可以在haproxy运行时动态调整无需重启。

3.2.1rounrobin

基于权重的轮询动态调度算法，支持权重的行时调整，不完全等于Ivs中的rr轮训模式， HAProxy中的roundrobin支持慢启动(新加的服务器会逐渐增加转发数)，其每个后端backend中最多支持4095个realserver,roundrobin为默认调度算法，且支持对real server权重动态调整。

3.2.2leastconn

leastconn加权的最少连接的动态，支持权重运行时调整和慢启动，即当前后端服务器连接最少的优先调度(新客户端连接)，比较适合长连接的场景使用，比如MySQL等场景

其他算法

3.2.3.1source

源地址hash，基于用户源地址hash并将请求转发到后端服务器，默认为静态即取模方式，但是可以通过hash-type支持的选项更改，后续同一个源地址请求将被转发至同一个后端web服务器，比较适用于session保持/缓存业务等场景。

3.2.3.2map-base 取模法

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

缺点是当服务器的总权重发生变化时，即有服

务器上线或下线，都会因总权重发生变化而导致调度结果整体改变，hash-type指定的默认值为此算法

3.2.3.3一致性hash

算法:

1、后端服务器哈希环点keyA=hash(后端服务器虚拟ip)%(2^32)

2、客户机哈希环点keyl=hash(client_ip)%(2^32) 得到的值在[0---4294967295] 之间，3、将keyA 和keyl 都放在hash 环上，将用户请求调度到离key1最近的keyA对应的后端服务器

hash 环偏斜问题

增加虚拟服务器IP数量，比如:一个后端服务器根据权重为1生成1000个虚拟IP，再hash 。而后端服务器权重为2则生成2000的虚拟IP，再bash，最终在hash环上生成3000个节点，从而解决hash环偏斜问题

hash对象

Hash 对象到后端服务器的映射关系

一致性示意图

3.2.3.4uri

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

listen web_80

bind *:80

mode http

balance uri

server web1 172.25.254.10:80 weight 1 check inter 3 fall 3 rise 5

server web2 172.25.254.20:80 weight 1 check inter 3 fall 3 rise 5

3.3 url_param

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

3.4 hdr

针对用户每个http 头部(header)请求中的指定信息做hash,此处由name指定的http 首部将会被取出并做hash计算，然后由服务器总权重取模以后派发至某挑出的服务器，如果无有效值，则会使用默认的轮询调度。

3.4.1 hdr取模法配置示例

[haproxy~]#vim /etc/haproxy/haproxy.cfg

listen webserver_80

bind *:80

mode http

balance hdr(user-Agent)

server webserver1 172.25.254.10:80 weight 1 check inter 3 fall 3 rise 5

server webserver2 172.25.254.20:80 weight 1 check inter 3 fall 3 rise 5

4.基于cookie的会话保持

cookie value:为当前server 指定cookie 值，实现基于cookie 的会话黏性，相对于基于 source 地址hash 调度算法对客户端的粒度更精准，但同时也加大了haproxy负载，目前此模式使用较少，已经被session共享服务器代替

listen webcluster

bind *:80

mode http

balance roundrobin

cookie WEBCOOKIE insert nocache indirect

server web1 172.25.254.10:80 cookie lee1 check inter 2 fall 3 rise 5 weight 1

server web2 172.25.254.20:80 cookie lee2 check inter 2 fall 3 rise 5 weight 1

5.ip渗透

web 服务器中需要记录客户端的真实IP地址，用于做访问统计、安全防护、行为分析、区域排行等场景

5.2.1 四层ip渗透

[haproxy~]#vim /etc/haproxy/haproxy.cfg

listen webserver_80

bind *:80

mode tcp

balance roundrobin

server webserver1 172.25.254.10:80 weight 1 check inter 3s fall 3 rise 5

5.2.2七层ip透传

当haproxy 工作在七层的时候，也可以透传客户端真实IP至后端服务器haproxy配置

[haproxy~]#vim /etc/haproxy/haproxy.cfg

listen webserver_80

option forwardfor

bind *:80

mode tcp

balance roundrobin

server webserver1 172.25.254.10:80 send-proxy weight 1 check inter 3 fall 3 rise 5

server webserver2 172.25.254.20:80 weight 1 check inter 3 fall 3 rise 5

5.ACL

访问控制列表ACL,Access Control Lists)是一种基于包过滤的访问控制技术它可以根据设定的条件对经过服务器传输的数据包进行过滤(条件匹配)即对接收到的报文进行匹配和过滤，基于请求报文头部中的源地址、源端口、目标地址、目标端口、请求方法、URL、文件后缀等信息内容进行匹配并执行进一步操作，比如允许其通过或丢弃。

域名匹配:

[haproxy ~]#vim /etc/haproxy/haproxy.cfg

frontend testacl

bind *:80

mode http

########### ACL settings #######################

acl web_host hdr_dom(host)www.timinglee.org

########### host ###########################

use_backend timinglee_host if web_host

########### default server ###################

default_backend default_webserver

backend webcluster-host

mode http

server webl 172.25.254.10:80 check inter 3 fall 2 rise 5

backend default-host

mode http

server web2 172.25.254.20:80 check inter 2 fall 2 rise 5

6.ACL示例-基于文件后缀名实现动分离

frontend webcluster

bind *:80

mode http

acl static path_end -i .html .jpg .png .css .js

cal php path_end -i .php

########################################

use_backend webcluster-host if php

default_backend default-host
[root@webserver1 ~]#mkdir /usr/share/nginx/html/static

[root@webserver1 ~]#echo static 172.25.254.10 > /usr/share/nginx/html/static/index.html

[root@webserver2 ~]#mkdir /var/www/html/api/

[root@webserver2 ~]#echo api 172.25.254.20 > /var/www/html/api/index.html

测试

[root@node~]#curl 172.25.254.100/api/

api 172.25.254.20

[root@node10～]#curl 172.25.254.100/static/

static 172.25.254.10

7.自定义HAProxy 错误界面

对指定的报错进行重定向，进行优雅的显示错误页面使用errorfile 和errorloc 指令的两种方法，可以实现自定义各种错误页面

[root@haproxy ~]#mkdir /haproxy/errorpages/-p

[root@haproxy ~]#cp /usr/share/haproxy/503.http /haproxy/errorpages/503page.http

[root@haproxy~]#vim/haproxy/errorpa

qes/503page.http

8.四层负载

[haproxy ~]#vim /etc/haproxy/haproxy.cfg

isten dbserver

bind *:3306

mode tcp

balance static-rr

server dbl 172.25.254.10:3306 check inter 2 fall 2 rise

server db2 172.25.254.20:3306 check inter 2 fall 2 rise

#serveweb1

[mysqld]

server-id=1

datadir=/var/lib/mysgl

socket=/var/lib/mysql/mysql.sock

Log-error=/var/log/mariadb/mariadb.log

pid-file=/run/mariadb/mariadb.pid

#serverweb2

[mysqld]

server-id=2

datadir-/var/lib/mysql

socket=/var/lib/mysql/mysql.sock

loa-error=/var/log/mariadb/mariadb.log

pid-file=/run/mariadb/mariadb.pid

9.https实现

haproxy 可以实现https的证书安全，从用户到haproxy 为https，从haproxy到后端服务器用http 通信但基于性能考虑，生产中证书都是在后端服务器比如nginx 上实现

[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 365 -out /etc/haproxy/certs/lee.org.crt

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

[root@haproxy ~]# cat /etc/haproxy/certs/timinglee.pem