1.七层、四层负载及正、反向代理

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

所谓的四到七层负载均衡，就是在对后台的服务器进行负载均衡时，依据四层的信息或七层的信息来决定怎么样转发流量四层的负载均衡，就是通过发布三层的IP地址(VIP)，然后加四层的端口号，来决定哪些流量需要做负载均衡，对需要处理的流量进行NAT处理，转发至后台服务器，并记录下这个TCP或者UDP的流量是由哪台服务器处理的，后续这个连接的所有流量都同样转发到同一台服务器处理 ​ 七层的负载均衡，就是在四层的基础上(没有四层是绝对不可能有七层的)，再考虑应用层的特征，比如同一个Web服务器的负载均衡，除了根据VIP加80端口辨别是否需要处理的流量，还可根据七层的 URL、浏览器类别、语言来决定是否要进行负载均衡。

1.分层位置:四层负载均衡在传输层及以下，七层负载均衡在应用层及以下 2.性能:四层负载均衡架构无需解析报文消息内容，在网络吞吐量与处理能力上较高:七层可支持解析应用层报文消息内容，识别URL、Cookie、HTTP header等信息。、 3.原理:四层负载均衡是基于ip+port;七层是基于虚拟的URL或主机IP等。 4.功能类比:四层负载均衡类似于路由器;七层类似于代理服务器。 西安鸥鹏 xianoupeng 5.安全性:四层负载均衡无法识别DDoS攻击;七层可防御SYNCookie/Flood攻击

1.2正向代理

主动找这个服务器给我代理，因为我过不去，所以需要能过去的服务器给我发送流量（客户主动设定的）

1.3反向代理

阿里在西安建立数据中心，把访问请求直接访问西安的数据中心，这个数据中心有直接返回，没有就去阿里的服务器拿，客户直接去阿里拿和数据中心去阿里拿显然是数据中心快

这台数据中心服务器就是反向代理服务器，是由企业设定的，类似于LVS

2.haproxy基本部署及负载均衡的实现

安装haproxy

dnf install haproxy -y

rpm -qc haproxy#查找haproxy的配置文件

haproxy配置文件有两大部分组成分别是：

global: 全局配置段 进程及安全配置相关的参数 性能调整相关参数;Debug参数 proxies: 代理配置段 defaults: 为frontend, backend, listen提供默认配置 frontend:前端，相当于nginx中的server {}

backend:后端，相当于nginx中的upstream {} ​ listen:同时拥有前端和后端配置,配置简单,生产推荐使用

编辑配置文件

vim /etc/haproxy/haproxy.cfg

前后端方法

进入配置文件后，先创建一个前端

front webcluster

bind *:80

mod http

use_backend webcluster-host#使用哪一个后端

创建后端

backend webcluster-host

balance roundrobin#算法

server web1 172.25.254.10：80

server web1 172.25.254.20：80

listen方法（合并前后端）

listen webcluster bind *:80#bind监听的端口，*表示所有

mode http

balance roundrobin

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

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

3.haproxy的全局配置及日志分离

3.1多线程设定

nbthread 2#启用多线程

配置完后重启服务

pstree -p | grep haproxy#查看进程

查看进程的线程

cat /proc/进程号/status | grep thread

在启动多线程的情况下启动多进程会报错，所以两者只能启动一个，不能同时启动

3.2日志分离

进入vim /etc/rsyslog.conf 打开514（udp）

将haproxy配置文件中写的日志local2加在rsyslog.conf中的local7中

4.haproxy的热更新方法

问题引入：在对haproxy配置文件做restart操作时，虽然只做了一处更改但是所有集群都会被影响，socat可以解决这样的问题

将这个套接字权限改为600后，我们要使用这个套接字，就需要socat软件

dnf install socat -y#在haproxy中安装socat

echo $1 | socat stdio /var/lib/haproxy/stats#使用socat

haproxy多进程如何热处理

用多个文件处理多进程，在原来的套接字下再加一个，并分别命名process1和process2，并且要打开多线程，还要再stats后加数字

5.haproxy中的算法

5.1静态算法

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

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

     不支持运行时利用socat进行权重的动态调整(只支持0和1,不支持其它值) 不支持端服务器慢启动 其后端主机数量没有限制，相当于LVS中的 wrr

5.1.2first

     根据服务器在列表中的位置，自上而下进行调度 其只会当第一台服务器的连接数达到上限，新请求才会分配给下一台服务 其会忽略服务器的权重设置 不支持用socat进行动态修改权重,可以设置0和1,可以设置其它值但无效

5.2动态算法

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

5.2.1roundrobin

1.基于权重的轮询动态调度算法， 2. 支持权重的运行时调整，不同于lvs中的rr轮训模式， 3. HAProxy中的roundrobin支持慢启动(新加的服务器会逐渐增加转发数)， 4. 其每个后端backend中最多支持4095个real server， 5. 支持对real server权重动态调整， 6. roundrobin为默认调度算法,此算法使用广泛

5.2.2leastconn

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

5.3其他算法

其它算法即可作为静态算法，又可以通过选项成为动态算法

5.3.1source

     源地址hash，基于用户源地址hash并将请求转发到后端服务器，后续同一个源地址请求将被转发至同一 个后端web服务器。此方式当后端服务器数据量发生变化时，会导致很多用户的请求转发至新的后端服 务器，默认为静态方式，但是可以通过hash-type支持的选项更改这个算法一般是在不插入Cookie的TCP 模式下使用，也可给拒绝会话cookie的客户提供最好的会话粘性，适用于session会话保持但不支持 cookie和缓存的场景源地址有两种转发客户端请求到后端服务器的服务器选取计算方式，分别是取模法 和一致性hash

5.3.2map-base 取模法

   map-based：取模法，对source地址进行hash计算，再基于服务器总权重的取模，最终结果决定将此请 求转发至对应的后端服务器。 此方法是静态的，即不支持在线调整权重，不支持慢启动，可实现对后端服务器均衡调度 缺点是当服务器的总权重发生变化时，即有服务器上线或下线，都会因总权重发生变化而导致调度结果 整体改变

5.3.3一致性hash

     一致性哈希，当服务器的总权重发生变化时，对调度结果影响是局部的，不会引起大的变动hash（o） mod n 该hash算法是动态的，支持使用 socat等工具进行在线权重调整，支持慢启动

5.3.4uri

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

6.haproxy的状态页面控制

通过web界面，显示当前Haproxy的运行状态

进入haproxy的配置文件

用listen配置

listen stats

mode http

bind *:7777

stats enable#启用状态页面

stats uri /status

stats auth zee：zee#账号和密码

7.基于cookie的会话保持

解决调度死板问题，一台主机两个不同的浏览器同时访问一个ip显示的是同样的内容

cookie保存在服务器

当被调度到10的RS上时，会发送cookie=zee1，那么下次再来的时候，浏览器的cookie被缓存，再来的时候验证cookie=zee1，那么就还让它走10

inster：插入新的cookie,默认不插入cookie

nocache：当客户端与服务器之间有缓存器（cdn）时，不允许中间缓存器缓存cookie，因为这会导致很多经过同一个cdn的请求都发送到同一台后端服务器

indirect：如果客户端已经有cookie，则不会再发送cookie

8.ip透传技术

8.1七层透传

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

一般情况下，客户端流量到达haproxy后再由ha转发，此时rs看到的源IP是ha的ip，此时rs就无法做流量分析

将forwardfor注释后，ha就不做透传

cat /var/log/nginx/access.log#nginx的访问日志

apache通常情况下是不显示，来源ip的，于是我们可以在apache中配置，让它可以透传

vim /etc/httpd/conf/httpd.conf#编辑它的主配置文件，找到它的日志行

在LogFormat参数后加上 %{X-Forwarded-For}i，combined（混合型日志），保存退出再重启

8.2四层透传

将mode改为tcp

先在haproxy配置文件中加入send-proxy到realserver中

现在访问，一个是400，一个是emply reply form server，造成这样结果的原因是我们用的是代理的访问方式，所以它直接拒绝了

此时我们需要进入nginx的配置文件，在server中的80端口后加入 proxy_protocal,加入这个参数后还是无法看到透传过来的ip，于是我们还需要加入一个参数，在log_format main中加入‘ “$proxy_protocal_addr” ’（日志采集内容），要改回七层要把nginx配置文件中的参数去掉

9.ACL（haproxy中的访问控制）

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

9.1acl配置选项

acl 名称 匹配规范 匹配模式 具体操作符 操作对象类型

acl test hdr（host） -i（忽略大小写） .com

acl要写一个新的frontend和backend

frontend webcluster

bind *:80

mode http

acl test hdr_dom(host) -i https://blog.csdn.net/2301_77321794/article/details/www.wyingzee.org

use_backend webcluster-host(如果符合条件，带你看webcluster-host) if test

default_backend default-host（不符合条件带你看default-host）

backend webcluster-host

mode http

server web1 172.25.254.10:80 check inter 2 fall 2 rise 5

backend default-host

mode http

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

9.2匹配规则

hdr

hdr_dom(host)请求的host名称，如https://blog.csdn.net/2301_77321794/article/details/www.wyingzee.org hdr_beg(host)请求的host开头，如www. img. video. download. ftp. hdr_end(host)请求的host结尾，如.com .net .cn

base

acl test bases_sub -m sub zee#匹配网址字串包含bbs

https://blog.csdn.net/2301_77321794/article/details/www.wyingzee.org和172.25.254.100/zee/都可以

path

acl test path_sub -m sub zee#只看/后面的内容

https://blog.csdn.net/2301_77321794/article/details/www.wyingzee.org/zee/与bbs.test.org/zee/访问到的内容一致

url

提取请求中的整个url

多个acl组合调用方法

||：或者，两个满足一个

两个写在一起就是并且

9.3利用acl做动静分离

9.3.1基于域名的访问控制

acl domain hdr_dom（host） -i https://blog.csdn.net/2301_77321794/article/details/www.wyingzee.org

use_backend webcluster-host if domain

default_backend default-host

9.3.2基于IP的访问控制

acl ctrl_ip src 172.25.254.1 172.25.254.20 192.168.0.0/24

use_backend webcluster-host if ctrl_ip

default_backend default-host

如果想要拒绝将use_backend改掉

http-request deny if ctrl_ip# 对这个源进行拒绝

9.3.3匹配浏览器类型

acl badwebrowers hdr_sub（User-Agent）-i curl wget

http-request deny if badweborwers#这两个浏览器不让用

9.3.4实现动静分离

基于后缀

acl static path_end -i .html .jpg .png .js#静态

acl php path_end -i .php

use_backend webcluster-host if php

default_backend default-host

基于路径

acl static path_sub -m sub static

acl php path_end -i .php

use_backend webcluster-host if php

default_backend default-host

9.4自定义错误页面

一般情况下我们关闭服务后访问页面时503

rpm -ql haproxy | grep http#找到写503页面的文件

mdkir /etc/haproxy/errorpage -p#先建立一个文件夹

vim /etc/haproxy/errorpage/503.http#编辑自定义的错误页面

指定错误页面的路径

进入haproxy的配置文件找到defaults在最后一行写上

errorfile 503 /etc/haproxy/errorpage/503.http#指定报错文件

错误后重定向页面

errorloc 503 https：//https://blog.csdn.net/2301_77321794/article/details/www.baidu.com错误后直接重定向到百度

10.haproxy四层负载

给两台rs安装maridb

编辑maridb的配置文件，分别加入编号1，2

[mysql]

server-id=1

[mysql]

server-id=2

数据库端操作

create user zee@‘%’ identified by ‘zee’;#创建用户远程连接并设置密码为zee

grant all on *.* to zee@'%'

在haproxy的配置文件中加入listen

listen dbserver

bind *：3306

mode tcp

balance static-rr

server db1 172.25.254.10：3306 check inter 2 fall 2 rise 5

server db2 172.25.254.20：3306 check

inter 2 fall 2 rise 5

此时在rs1上进行远程登录mysql -uzee -pzee -h 172.25.254.100 看到@@server_id为1

在rs2上远程登录看到@@server_id为2

此时基于数据库的haproxy四层负载就完成了

11.haproxy-https的加密访问

11.1https加密访问

首先创建一个文件夹来放我们制作的证书和密钥

mkdir -p /etc/haproxy/certs

制作证书和密钥

openssl req -newkey rsa：2048 -nodes -sha256 -keyout /etc/haproxy/certs/wyingzee.org.key -x509 -days 365 -out /etc/haproxy/certs/wyingzee.org.crt

将证书和密钥导入.pem文件

cat /etc/haproxy/certs/wyingzee.org.key /etc/haproxy/certs/wyingzee.org.crt > /etc/haproxy/certs/wyingzee.pem

现在进入haproxy的配置文件指定这个导入文件

写一个listen

listen web-https

bind *:443

mode http

balance roundrobin

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

server web1 172.25.254.10:80 check inter 2 fall 2 rise 5

11.2全站加密

在haproxy配置文件写frontend

frontend webcluster

bind *：80

mode http

redriect scheme https if ！{ssl_fc}

此时访问网址不加https也会自动加密

这些配置也可以放入它的子配置文件

我们要查看它的子配置文件在哪，以及这个子配置文件会不会被执行需要进入vim /lib/systemd/system/haproxy.service