haproxy七层代理
一.负载均衡
1.负载均衡的概念
负载均衡:Load Balance,是一种服务或基于硬件设备等实现的高可用反向代理技术,负载均衡将特定的业务分担给指定的一个或多个后端特定服务器或设备,从而提高业务的并发处理能力,保证业务的高可用性,方便业务后期的水平动态扩展
2.负载均衡的意义
web服务器动态水平扩展 ->用户无感知
增加业务并发性能 ->解决服务器物理上限问题
节约公网ip
隐藏内部服务器ip ->提高整体安全性
配置简单
支持四层和七层,支持动态下线主机
3.四层负载均衡
1.通过ip加端口决定流量去向
2.对流量请求进行NAT处理,转发至后台服务器
3.记录tcp,udp流量分别由哪台服务器处理,后续该请求流量都通过此服务器处理
4.支持四层的软件
4.四层和七层的区别
四层负载均衡依据三层的IP和四层的端口号来决定流量的走向,对需处理的流量进行NAT处理,转发至后台服务器,并加以记录
七层负载均衡,是在四层的基础上再加上应用层的特征,例如url,浏览器的不同等等来进行负载均衡,更加细致同时也更耗费性能
二.haproxy的安装和服务信息
| 虚拟机 | ip |
| 客户机 | 172.25.254.200 |
| haproxy调度机 | ens33:172.25.254.100 ens37:192.168.0.100 |
| realserver1 | 192.168.0.10 |
| realserver2 | 192.168.0.20 |
所有虚拟机的版本均为rhel9.2,软件仓库都以及配好
在实验之前,推荐大家先做一个操作
getenforce #查看linux内核里的端口限制有没有开启,默认开启
setenforce 0 #关闭selinux安装haproxy
dnf search haproxy
dnf install haproxy.x86_64 -y1.haproxy的基本配置
global:全局配置
进程及安全配置相关的参数
性能调整相关参数
Debug参数
proxies:代理配置段
defaults:为frontend,backend,listen提供默认配置
frontend:前端,相当于nginx中的server{}
backend:后端,相当于nginx中的upstream{}
listen:同时拥有前端和后端,配置简单
| 参数 | 作用 |
| chroot | 锁定运行目录 |
| deamon | 以守护进程运行 |
| user,group,uid,gid | 运行haproxy的用户身份 |
| stats socket | 套接字文件 |
| nbproc N | 开启的haproxy worker进程数,默认进程数是一个 |
| nbthread 1(和nbproc互斥) | 多线程,默认是一个 |
| cpu-map 1 0 | 绑定haproxy worker进程至cpu,一个进程绑定一个核心 |
| maxconn N | 每个haproxy进程的最大并发连接数 |
| maxsslconn N | 每个haproxy进程ssl最大连接数 |
| log 127.0.0.1 local2 info | 定义全局syslog服务器(需开启upd协议,最多开启两个) |
| pid file | 指定pid路径 |
2.多进程和多线程
多进程
这里进入的目录是
vim /etc/haproxy/haproxy.cfg #配置文件目录
systemctl restart haproxy.service #重启服务生效pstree -p | grep haproxy
这是开启多进程之前的
这是多进程之后的,我们明显的看见了,变成两行了对吧
接下来我们测验多进程
对策略进行配置,这里我们允许访问web1和web2的80,因为我们做的是http的负载均衡,所有mode为http,bind为80端口,check代表检测,inter 2s执行检测一次,fall 当两次检测均为未连接就断开,rise 5次连接后稳定,wq保存退出,并重启服务
listen httpd
mode http
bind *:80
server web1 192.168.0.10:80 check inter 2 fall 2 rise 5
server web2 192.168.0.20:80 check inter 2 fall 2 rise 5
我们先去两台realserver上下载nginx服务
yum install nginx -y
systemctl enable --now nginx
echo wsr1 192.168.0.10 > /usr/share/nginx/html/index.html #内容写入nginx的登陆页面我们可以看到先开始略有点不稳定,但是四下以后就稳定在一个一个轮询.(这里的ip是上次座实验先开始懒得改,大家输出应该是自己输入index页面的内容即可)
3.开启服务日志
接着我们去把日志给拔出来,这样方便我们后面去观察服务重启之类的,也能看我们写的策略配置有没有正常启动
首先我们在syslog里面把udp打开
vim /etc/rsyslog.conf
这里我们需要写一个
local2.* /var/log/haproxy.log
对应配置里的local2
systemctl restart syslog.service这样就打开日志服务器了
我们看到重启服务以后,开始出现日志提醒
也可以使用cat命令去抓取log日志
cat /var/log/haproxy.log
less /var/log/haproxy.log #日志过多用less来抓取更方便三.haproxy的算法
HAProxy通过固定参数 balance 指明对后端服务器的调度算法
balance参数可以配置在listen或backend选项中
HAProxy的调度算法分为静态和动态调度算法
有些算法可以根据参数在静态和动态算法中相互转换，
1.静态算法
静态算法:按照事先定义好的规则轮询公平调度，不关心后端服务器的当前负载、连接数和响应速度等，且无法实时修改权重(只能为0和1,不支持其它值)，只能靠重启HAProxy生效。
a.static-rr:基于权重的轮询调度
不支持运行时利用socat进行权重的动态调整(只支持0和1,不支持其它值)
不支持端服务器慢启动
其后端主机数量没有限制，相当于LVS中的 wrr
如图,可以自己测一下效果,实际效果应该是与我先开始测试的一致(上面忘记加balance了)
b.first
根据服务器在列表中的位置，自上而下进行调度
其只会当第一台服务器的连接数达到上限，新请求才会分配给下一台服务
其会忽略服务器的权重设置
不支持用socat进行动态修改权重,可以设置0和1,可以设置其它值但无效
这里我为了方便验证把最大连接数改为1了,那我们来看看实际测验出来的结果
我们先用一个客户机去curl haproxy的vip,然后再同时用另一个客户机去curl
这里因为我的虚拟机配置都比较高,4g内存加上双核心,所以我使用了三个客户机同时去curl,才勉强出现了wsr2,但是first模式下,不出现过载是不会去切换服务器的,所以最后还是验证成功了.
2.动态算法
基于后端服务器状态进行调度适当调整,新请求将优先调度至当前负载较低的服务器权重,可以在haproxy运行时动态调整无需重启
a.roundrobin
1.基于权重的轮询动态调度算法
2.支持权重的运行时调整，不同于Is中的rr轮训模式
3.HAProxy中的roundrobin支持慢启动(新加的服务器会逐渐增加转发数)
4.其每个后端backend中最多支持4095个real server，
5.支持对real server权重动态调整,
6.roundrobin为默认调度算法,此算法使用广泛
(动态调整socat工具)
安装
yum install socat.x86_64 -y我们先去/etc/haproxy/haproxy.cfg里进行调整,在global中找到stats socket(套接字)加上读写权限(mode 600),wq保存退出,并且重启服务
动态调整代码示例
echo "set weight httpd/web1 2" | socat stdio /var/lib/haproxy/haproxy.statsok我们来看看效果
echo "get weight httpd/web1" | socat stdio /var/lib/haproxy/haproxy.stats
b.leastconn
leastconn加权的最少连接的动态
支持权重的运行时调整和慢启动，即:根据当前连接最少的后端服务器而非权重进行优先调度(新客户端连接)
比较适合长连接的场景使用，比如:MySQL等场景
我们来试试实际效果
在配置完文件以后,我们看到在第一台客户机占wsr1的资源以后,第二台客户机自动选择了wsr2.
3.其他算法
其它算法即可作为静态算法，又可以通过选项成为动态算法
a.source(保持session会话)
源地址hash，基于用户源地址hash并将请求转发到后端服务器，后续同一个源地址请求将被转发至同一个后端web服务器。此方式当后端服务器数据量发生变化时，会导致很多用户的请求转发至新的后端服务器，默认为静态方式，但是可以通过hash-type支持的选项更改这个算法一般是在不插入Cookie的TCP模式下使用，也可给拒绝会话cookie的客户提供最好的会话粘性，适用session会话保持但不支持cookie和缓存的场景源地址有两种转发客户端请求到后端服务器的服务器选取计算方式，分别是取模法和一致性hash
ok那看起来很简单,我们同样还是一台客户机开两个窗口来测试一下
while true; do curl 172.25.254.150;sleep 1; done
我们看到.同一台客户机,无论怎么访问,都只会访问到wsr1,这样就保持了session会话,不会让正在进行的会话突然消失
b.map-base 取模法
map-based:取模法，对source地址进行hash计算，再基于服务器总权重的取模，最终结果决定将此请求转发至对应的后端服务器。
此方法是静态的，即不支持在线调整权重，不支持慢启动，可实现对后端服务器均衡调度缺点是当服务器的总权重发生变化时，即有服务器上线或下线，都会因总权重发生变化而导致调度结果整体改变，hash-type 指定的默认值为此算法
所谓取模运算，就是计算两个数相除之后的余数，10%7=3,7%4=3
map-based算法:基于权重取模，hash(source_ip)%所有后端服务器相加的总权重
c.一致性hash
一致性哈希，当服务器的总权重发生变化时，对调度结果影响是局部的，不会引起大的变动hash (o) mod n
该hash算法是动态的，支持使用 socat等工具进行在线权重调整，支持慢启动算法:
1、后端服务器哈希环点keyA=hash(后端服务器虛拟ip)%(2^32)
2、客户机哈希环点key1=hash(client_ip)%(2^32)得到的值在[0---4294967295]之间，
3、将keyA和key1都放在hash环上，将用户请求调度到离key1最近的keyA对应的后端服务器
hash环偏斜问题
增加虚拟服务器IP数量，比如:一个后端服务器根据权重为1生成1000个虚拟IP，再hash。而后端服务器权重为2则生成2000的虚拟IP，再bash,最终在hash环上生成3000个节点，从而解决hash环偏斜问题
hash对象
Hash对象到后端服务器的映射关系:
一致性hash示意图
当哈希环中出现单个服务器停止服务的情况,客户机也能依据哈希环自动按照顺时针去寻找下一个节点并连接,这样就只有局部(连接下线服务器的客户机)会受到下线的影响
修改配置文件,wq保存退出
这个不太好验证,我试了三台客户机,hash算法都算在wsr2下面了,不过大家清楚其中的原理就行,这种算法一般都是面对大量的客户流量的
d.uri一致性hash配置示例
验证一下,先用echo写入一些子页面
我们可以看到访问不同的uri会有不同的服务器响应,但是同一uri一般由同一个服务器响应
e.url_param
url_param对用户请求的url中的 params 部分中的一个参数key对应的value值作hash计算，并由服务器总权重相除以后派发至某挑出的服务器,后端搜索同一个数据会被调度到同一个服务器，多用与电商
通常用于追踪用户，以确保来自同一个用户的请求始终发往同一个realserver
如果无没key，将按roundrobin算法
Params参数用于传递URL路径中的数据
url=http://www.snow.com/foo/bar/index.php?key=value
param代表的就是key=value这一部分内容,代表资源
取模法配置
一致性hash配置
测试
我们可以看到不同的id访问到了不同的服务器,并且相同id会锁定同一个服务器
f.hdr
针对用户每个http头部(header)请求中的指定信息做hash
此处由 name 指定的http首部将会被取出并做hash计算
然后由服务器总权重取模以后派发至某挑出的服务器，如果无有效值，则会使用默认的轮询调度
配置示例
此时我们使用不同的浏览器访问就会访问到不同的浏览器,相同浏览器访问的结果一致
四.高级功能及配置
1.基于cookie的会话保持
cookie value:为当前server指定cookie值，实现基于cookie的会话黏性，相对于基于 source 地址hash 调度算法对客户端的粒度更精准，但同时也加大了haproxy负载，目前此模式使用较少，已经被session共享服务器代替
只支持http mode
示例
listen httpd
mode http
bind *:80
option forwardfor
#balance first
#balance static-rr
balance roundrobin
#balance leastconn
#balance source
#balance uri
#balance hdr(User-Agent)
#balance url_param name.userid
#hash-type consistent
cookie webcookie insert nocache indirect
server web1 192.168.0.10:80 cookie web1 weight 1 check inter 2 fall 2 rise 5
server web2 192.168.0.20:80 cookie web2 weight 1 check inter 2 fall 2 rise 5
我们来检验一下是否有cookie
我们可以看到在响应标头里面有webcookie=web2,说明成功了
还可以在linux里直接验证
也有webcookie=web2
在访问服务器时还可以指定cookie
curl -i 172.25.254.150
curl -b webcookie=web1 172.25.254.1502.haproxy状态页(记得先关闭selinux)
setenforce 0通过web显示当前haproxy运行状态
vim /etc/haproxy/haproxy.cfg
auth代表用户,我们在打开页面时需要登陆,接着我们浏览器访问172.25.254.150:6060/status
输入密码
我们就进入到haproxy的状态页了
3.IP透传
web服务器中需要记录客户端的真实IP地址，用于做访问统计、安全防护、行为分析、区域排行等场景
a.四层负载
在四层负载设备中，把client发送的报文目标地址(原来是负载均衡设备的IP地址)，根据均衡设备设置的选择web服务器的规则选择对应的web服务器IP地址，这样client就可以直接跟此服务器建立TCP连接并发送数据，而四层负载自身不参与建立连接，而和LVS不同，haproxy是伪四层负载均衡，因为haproxy需要分别和前端客户端及后端服务器建立连接
b.七层代理
七层负载均衡服务器起了一个反向代理服务器的作用，服务器建立一次TCP连接要三次握手，而client要访问Web Server要先与七层负载设备进行三次握手后建立TCP连接，把要访问的报文信息发送给七层负载均衡;然后七层负载均衡再根据设置的均衡规则选择特定的Web Server，然后通过三次握手与此台Web Server建立TCP连接，然后Web Server把需要的数据发送给七层负载均衡设备，负载均衡设备再把数据发送给client;所以，七层负载均衡设备起到了代理服务器的作用，七层代理需要和Client和后端服务器分别建立连接
tcpdump tcp -i ens33 -nn port ! 22 -w dump-tcp.pcap -v
tcpdump tcp -i ens37 -nn port ! 22 -w dump-tcp2.pcap -v四层IP透传
这里我更换了一下虚拟机,大家不需要改策略名字,也可以改的和我一样,没有改的xdm要注意在后面的命令中需要注意的不同
我们进入nginx的配置文件去修改两个参数
vim /etc/nginx/nginx.conf
systemctl restart nginx
修改haproxy的配置,wq保存退出并且重启服务
我们先在客户机上curl一下
curl 172.25.254.150
然后再在realserver1上查看记录,可以看到172.25.254.100,说明透传成功,现在realserver也可以看到source ip
tail -n 3 /var/log/nginx/access.log
4.ACL
在acl实验之前温馨提示大家,记得把刚才的nginx修改的配置改回去,不然会无法访问哦
访问控制列表ACL，AccessControl Lists)
是一种基于包过滤的访问控制技术
它可以根据设定的条件对经过服务器传输的数据包进行过滤(条件匹配)即对接收到的报文进行匹配和过滤，基于请求报文头部中的源地址、源端口、目标地址、目标端口、请求方法、URL、文件后缀等信息内容进行匹配并执行进一步操作，比如允许其通过或丢弃。
a.域名匹配
vim /etc/haproxy/haproxy.cfg修改haproxy的配置,这里我直接重新写了一个策略
frontend webcluster
bind *:80
mode http
#acl test hdr_end(host) -i .org
acl domain hdr_dom(host) -i www.snow.org
#acl ctrl_ip src 172.25.254.1 172.25.254.20 192.168.0.0/24#
#acl static path_end -i .html .jpg .png .css .js
#acl static path_sub -m sub static
#acl php path_sub -m sub php
#acl php path_end -i .php
#acl badwebrowers hdr_sub(User-Agent) -i curl wget
use_backend webcluster-host if web_host
#use_backend webcluster-host if ctrl_ip
#use_backend webcluster-host if php
default_backend default-host
#http-request deny if badwebrowers
#default_backend default-host
backend webcluster-host
mode http
server web1 172.25.254.10:80
backend default-host
mode http
server web2 172.25.254.20:80
接下来我们在浏览器所在主机中做地址解析
先进入windows,也就是你自己的电脑,接下来我会给你一个路径,进去然后修改hosts的配置.担心的同学可以先复制一份备份
C:\Windows\System32\drivers\etc
修改好以后ctrl s保存
接下来我们在windows上开始测试,我这里用xshell连接的本地,也可以用cmd去curl
当地址为www.snow.org时,使用wsr1,前余调度都为wsr2
b.源ip目标ip匹配
配置示例
源ip为172.25.254.1时,访问wsr1
源ip不为172.25.254.1时,访问wsr2
c.匹配浏览器类型
配置示例
5.自定义haproxy错误界面
对指定的报错进行重定向，进行优雅的显示错误页面
使用errorfile和errorloc指令的两种方法，可以实现自定义各种错误页面
vim /etc/haproxy/haproxy.cfg
errorfile 503 /etc/haproxy/errorpages/503page.http做完之后,因为我们还没有这个目录和文件,所以用mkdir和cp先创建文件
cp /usr/share/haproxy/503.http /etc/haproxy/errorpages/503page.http
vim /etc/haproxy/errorpages/503page.http
^M全部删掉,这是因为字符集不相符导致的
把h1里面的内容改成自己想要的,再改一下body中间的代码就好了
.然后我们上wsr1和wsr2把nginx服务全部关闭,再用客户机来curl
成功了
6.基于http重定向错误页面
修改haproxy的配置
errorloc 503 https://www.baidu.com保存退出,用浏览器访问
ok完成辣
7.haproxy的https实现
a.证书制作
mkdir /etc/haproxy/certs/
openssl req -newkey rsa:2048 \b.接着修改haproxy的配置,新加一个策略
listen web-https
bind *:443 ssl crt /etc/haproxy/certs/snow.pem
mode http
balance roundrobin
server web1 172.25.254.10:80 check inter 2 fall 2 rise 5
server web2 172.25.254.20:80 check inter 2 fall 2 rise 5
c.最后用浏览器测试
打开以后查看证书
信息与自己设置的一致则说明实验完成,这就是haproxy的所有内容辣
谢谢你能浏览至此,求个点赞收藏捏
1222
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
