haproxy七层代理

Web服务器的动态水平扩展-->对用户无感知

增加业务并发访问及处理能力-->解决单服务器瓶颈问题

节约公网IP地址-->降低IT支出成本隐藏内部服务器IP-->提高内部服务器安全性

配置简单-->固定格式的配置文件

功能丰富-->支持四层和七层，支持动态下线主机

性能较强-->并发数万甚至数十万

负载均衡类型

硬件

F5 美国 F5网络公司 https://f5.com/zh

Netscaler 美国思杰公司 https://www.citrix.com.cn/products/citrix-adc/、

Array 华耀 https://www.arraynetworks.com.cn/

AD-1000 深信服 http://www.sangfor.com.cn/

四层负载均衡

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

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

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

4.支持四层的软件

lvs：重量级四层负载均衡器

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、浏览器类别、语言来决定是否要进行负载均衡。

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

haproxy简介

HAProxy是法国开发者威利塔罗(Willy Tarreau) 在2000年使用C语言开发的一个开源软件是一款具备高并发(万级以上)、高性能的TCP和HTTP负载均衡器支持基于cookie的持久性，自动故障切换，支持正则表达式及web状态统计

企业版网站：        https://www.haproxy.com
社区版网站：        http://www.haproxy.org
github：                https://github.com/haprox

haproxy的安装和服务信息

实验环境

haproxy	172.25.254.100
server1	172.25.254.10
server2	172.25.254.20

server端下载nginx

[root@server1 ~]# dnf insatll nginx -y
[root@server1 ~]# echo webserver1 - 172.25.254.10 > /usr/share/nginx/html/index.html
[root@server1 ~]# systemctl enable --now nginx.service

软件安装

[root@haproxy ~]# dnf install haproxy -y

haproxy的基本配置信息

官方文档：
http://cbonte.github.io/haproxy-dconv/

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

global：全局配置段
        进程及安全配置相关的参数
        性能调整相关参数
        Debug参数

proxies：代理配置段
        defaults：为frontend, backend, listen提供默认配置
        frontend：前端，相当于nginx中的server {}
        backend：后端，相当于nginx中的upstream {}
        listen：同时拥有前端和后端配置,配置简单,生产推荐使用

更改haproxy配置文件

测试

global全局设置

参数	类型	作用
chroot	全局	锁定运行目录
deamon	全局	以守护进程运行
user, group, uid, gid	全局	运行haproxy的用户身份
stats socket	全局	套接字文件
nbproc N	全局	开启的haproxy worker 进程数，默认进程数是一个
nbthread 1 （和nbproc 互斥）	全局	指定每个haproxy进程开启的线程数，默认为每个进程一个线程
cpu-map 1 0	全局	绑定haproxy worker 进程至指定CPU，将第1个work进程绑定至0号CPU
cpu-map 2 1	全局	绑定haproxy worker 进程至指定CPU，将第2个work进程绑定至1号CPU
maxconn N	全局	每个haproxy进程的最大并发连接数
maxsslconn N	全局	每个haproxy进程ssl最大连接数,用于haproxy配置了证书的场景下
maxconnrate N	全局	每个进程每秒创建的最大连接数量
spread-checks N	全局	后端server状态check随机提前或延迟百分比时间，建议2- 5(20%-50%)之间，默认值0
pidfile	全局	指定pid文件路径
log 127.0.0.1 local2 info	全局	定义全局的syslog服务器；日志服务器需要开启UDP协议，最多可以定义两个

多进程和线程

配置

效果

sorryserver配置

haproxy配置

测试

网页重定向

动态调整haproxy

haproxy配置

热处理

多进程热处理

haproxy的算法

HAProxy通过固定参数 balance 指明对后端服务器的调度算法
balance参数可以配置在listen或backend选项中。
HAProxy的调度算法分为静态和动态调度算法
有些算法可以根据参数在静态和动态算法中相互转换。

静态算法

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

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

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

first

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

动态算法

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

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

leastconn

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

其他算法

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

map-base 取模法
map-based：取模法，对source地址进行hash计算，再基于服务器总权重的取模，最终结果决定将此请求转发至对应的后端服务器。
此方法是静态的，即不支持在线调整权重，不支持慢启动，可实现对后端服务器均衡调度
缺点是当服务器的总权重发生变化时，即有服务器上线或下线，都会因总权重发生变化而导致调度结果整体改变hash-type 指定的默值为此算法
所谓取模运算，就是计算两个数相除之后的余数，10%7=3, 7%4=3
map-based算法：基于权重取模，hash(source_ip)%所有后端服务器相加的总权重

一致性hash性

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

uri

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

url_param

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

hdr

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

算法总结

#静态

static-rr--------->tcp/http

irst------------->tcp/http

#动态

roundrobin-------->tcp/http

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

#以下静态和动态取决于hash_type是否consistent

source------------>tcp/http Uri--------------->http

url_param--------->http

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

使用场景

first #使用较少

static-rr #做了session共享的web集群

roundrobin leastconn #数据库 source #基于客户端公网IP的会话保持

Uri--------------->http #缓存服务器，CDN服务商，蓝汛、百度、阿里云、腾讯

url_param--------->http #可以实现session保持

hdr #基于客户端请求报文头部做下一步处理

高级功能及配置

HAProxy状态页

通过web界面，显示当前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 } <cond> #启用stats page中的管理功能

启用状态页

登录状态页

#pid为当前pid号，process为当前进程号，nbproc和nbthread为一共多少进程和每个进程多少个线程

pid =27134 (process #1， nbproc = 1，nbthread = 1)

#启动了多长时间

uptime = 0d 0h00m04s

#系统资源限制:内存/最大打开文件数/

system limits: memmax = unlimited; ulimit-n = 200029

#最大socket连接数/单进程最大连接数/最大管道数maxpipes

maxsock = 200029; maxconn = 100000; maxpipes = o

#当前连接数/当前管道数/当前连接速率

current conns = 2; current pipes = 0/0; conn rate = 2/sec; bit rate = 0.000 kbps

#运行的任务/当前空闲率

Running tasks: 1/14; idle = 100 %

active uP: #在线服务器

backup uP: #标记为backup的服务器

active UP, going down: #监测未通过正在进入down过程

backup UP,going down: #备份服务器正在进入down过程

active DOWN，going up: #down的服务器正在进入up过程

backup DOwN,going up: #备份服务器正在进入up过程

active or backup DOWN: #在线的服务器或者是backup的服务器已经转换成了down状态

not checked: #标记为不监测的服务器

#active或者backup服务器人为下线的

active or backup DOwN for maintenance(MAINT)

#active或者backup被人为软下线(人为将weight改成O)

active or backup sOFT STOPPED for maintenance

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:活动链接数量

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

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

Dwn:后端服务器连接后都是DOWN的数量 Denied(拒绝统计信息):

Dwntme:总的downtime时间 Req:拒绝请求量

Thrtle:server状态 Resp:拒绝回复量

基于cookie的会话保持

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

注意：cookie保存在浏览器上，session保存在服务器上

注意:不支持tcp mode，使用http mode

使用cookie的话，浏览器看的是cookie，cookie是可以更改的（与hdr的区别）

配置选项

cookie name [ rewrite | insert | prefix ][ indirect ] [ nocache ][ postonly ] [ preserve ][ httponly ] [ secure ][ domain ]* [ maxidle <idle> ][ maxlife ]
name ： #cookie 的 key 名称，用于实现持久连接
insert ： # 插入新的 cookie, 默认不插入 cookie
indirect ： # 如果客户端已经有 cookie, 则不会再发送 cookie 信息
nocache ： # 当 client 和 hapoxy 之间有缓存服务器（如： CDN ）时，不允许中间缓存器缓 cookie ，# 因为这会导致很多经过同一个 CDN 的请求都发送到同一台后端服务器

验证

IP透传

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

七层透传

hproxy

nginx

httpd

四层透传

haproxy

nginx

测试

ACL

ACL配置选项

#用ac1来定义或声明一个ac1

ac1<ac1name> <criterion>[f1ags] [operator] [<value>]

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

ACL-Name名称

acl image_service hdr_dom(host)-i img.magedu. com #-i忽略大小写

acl test path_end -m sub /a

#ACL名称，可以使用大字母A-Z、小写字母a-z、数字O-9、冒号:、点.、中横线和下划线，并且严格区分大小写，比如:my_ac1和My_Ac1就是两个完全不同的ac15.8.1.2 ACL-criterion

ACL-criterion匹配规范

定义ACL匹配规范，即:判断条件

hdr string，提取在一个HTTP请求报文的首部
hdr（[<name> [，<occ>]]）：完全匹配字符串,header的指定信息，<occ> 表示在多值中使用的值的出现次数
hdr_beg（[<name> [，<occ>]]）：前缀匹配，header中指定匹配内容的begin，（以什么开头）
hdr_end（[<name> [，<occ>]]）：后缀匹配，header中指定匹配内容end，（以什么结尾）
hdr_dom（[<name> [，<occ>]]）：域匹配，header中的dom（host）（是什么）

hdr_dir（[<name> [，<occ>]]）：路径匹配，header的uri路径
hdr_len（[<name> [，<occ>]]）：长度匹配，header的长度匹配
hdr_reg（[<name> [，<occ>]]）：正则表达式匹配，自定义表达式(regex)模糊匹配
hdr_sub（[<name> [，<occ>]]）：子串匹配，header中的uri模糊匹配模糊匹配c 报文中a/b/c也会匹配

#有些功能是类似的，比如以下几个都是匹配用户请求报文中host的开头是不是www
acl short_form hdr_beg(host) www.
acl alternate1 hdr_beg(host) -m beg www.
acl alternate2 hdr_dom(host) -m beg www.
acl alternate3 hdr(host) -m beg www.
base : string
#返回第一个主机头和请求的路径部分的连接，该请求从主机名开始，并在问号之前结束,对虚拟主机有用
<scheme>://<user>:<password>@#<host>:<port>/<path>;<params>#?<query>#<frag>
base : exact string match
base_beg : prefix match （匹配开头）
base_dir : subdir match （匹配子目录）
base_dom : domain match （域匹配）
base_end : suffix match （匹配结尾）
base_len : length match （长度匹配）
base_reg : regex match （正则匹配）
base_sub : substring match （字符串匹配）

path : string
#提取请求的URL路径，该路径从第一个斜杠开始，并在问号之前结束（无主机部分）(<path>;<params>#)
<scheme>://<user>:<password>@<host>:<port>#/<path>;<params>#?<query>#<frag>
path : exact string match
path_beg : prefix match #请求的URL开头，如/static、/images、/img、/css
path_end : suffix match #请求的URL中资源的结尾，如 .gif .png .css .js .jpg .jpeg
path_dom : domain match
path_dir : subdir match
path_len : length match
path_reg : regex match
path_sub : substring match

url : string
#提取请求中的整个URL。
url ：exact string match
url_beg : prefix match
url_dir : subdir match
url_dom : domain match
url_end : suffix match
url_len : length match
url_reg : regex match
url_sub : substring match

dst #目标IP
dst_port #目标PORT

src #源IP
src_port #源PORT

status : integer #返回在响应报文中的状态码

#七层协议
acl valid_method method GET HEAD
http-request deny if ! valid_method

ACL-flags 匹配模式

ACL匹配模式

-i不区分大小写

-m使用指定的正则表达式匹配方法

-n不做DNS解析

-u禁止ac1重名，否则多个同名ACL匹配或关系

ACL-operator具体操作符

ACL操作符

整数比较: eq、ge、gt、 le、1t字符比较:

- exact match( -m str):字符串必须完全匹配模式

- substring match (-m sub) :在提取的字符串中查找模式，如果其中任何一个被发现，ACL将匹配

- prefix match (-m beg):在提取的字符串首部中查找模式，如果其中任何一个被发现，ACL将匹配

- suffix match (-m end) :将模式与提取字符串的尾部进行比较，如果其中任何一个匹配，则ACL进行匹配

- subdir match (-m dir) :查看提取出来的用斜线分隔(“/")的字符串，如其中任一个匹配，则ACL进行匹配

- domain match (-m dom):查找提取的用点(“.")分隔字符串，如果其中任何一个匹配，则ACL进行匹配

ACL-value操作对象

value的类型

The AcL engine can match these types against patterns of the following types :

- Boolean #布尔值

- integer or integer range #整数或整数范围，比如用于匹配端口范围

- IP address / network #工P地址或IP范围，192.168.0.1 ,192.168.0.1/24

- string--> www .timinglee.org

exact #精确比较

substring #子串

suffix #后缀比较

prefix #前缀比较

subdir #路径，/wp-includes/js/jquery/jquery.js

domain #域名，www .timinglee.org

- regular expression #正则表达式

- hex block #16进制

多个ACL的组合调用方式

多个ACL的逻辑处理

与:隐式(默认）使用

或:使用"or”或“|"表示

否定:使用"!"表示

ACL示例-域名匹配

更改hosts

测试

ACL示例-基于源IP或子网调度访问

将指定的源地址调度至指定的web服务器组

测试

ACL示例-匹配浏览器类型

匹配客户端浏览器，将不同类型的浏览器调动至不同的服务器组、范例:拒绝curl和wget的访问

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

server端

测试

ACL-匹配访问路径实现动静分离

服务端

测试

自定义HAProxy错误界面

对指定的报错进行重定向，进行优雅的显示错误页面

使用errorfile和errorloc指令的两种方法，可以实现自定义各种错误页面

基于自定义的错误页面文件
自定义错误页
errorfile <code> <file>
<code> #HTTP status code.支持200, 400, 403, 405, 408, 425, 429, 500, 502，503,504
<file> #包含完整HTTP响应头的错误页文件的绝对路径。 建议后缀".http"，以和一般的html文件相区分

基于http重定向错误页面

#错误页面重定向
errorloc <code> <ur1>
#相当于errorloc302 <code> <ur1>，利用302重定向至指URL
#示例:
errorloc 503 https : / /www. baidu . com

HAProxy四层负载

haproxy 下载mariadb，注意：不是mariadb-server

测试

HAProxy https 实现

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

#配置HAProxy支持https协议，支持ss1会话;
bind *:443 ss1 crt /PATH/TO/SOME_PEM_FILE

#指令crt后证书文件为PEM格式，需要同时包含证书和所有私钥
cat demo.key demo.crt > demo.pem

#把80端口的请求重向定443
bind * :80
redirect scheme https if !i ss1_fc }

全站加密

子配置文件

[root@haproxy ~]# vim /lib/systemd/system/haproxy.service
[root@haproxy ~]# cd /etc/haproxy/conf.d
[root@haproxy conf.d]# vim webcluster.cfg
[root@haproxy conf.d]# systemctl restart haproxy.service
[root@haproxy conf.d]# systemctl daemon-reload