• 【haproxy】haproxy七层代理


    负载均衡

    LB LoadBalancing(负载均衡)由多个主机组成,每个主机只承担一部分访问
    负载均衡:Load Balance,简称LB,是一种服务或基于硬件设备等实现的高可用反向代理技术,负载均衡将特定的业务(web服务、网络流量等)分担给指定的一个或多个后端特定的服务器或设备,从而提高了公司业务的并发处理能力、保证了业务的高可用性、方便了业务后期的水平动态扩展

    为什么用负载均衡

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

    四层负载均衡

    1.通过ip+port决定负载均衡的去向。
    ⒉.对流量请求进行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:七层代理,会话保持、标记、路径转移等。
    ·Nginx:轻量级四层负载均衡器,可缓存。(nginx四层是通过upstream模块). Haproxy:模拟四层转发。

    四层和七层的区别

    所谓的四到七层负载均衡,就是在对后台的服务器进行负载均衡时,依据四层的信息或七层的信息来决定怎么样转发流量
    四层的负载均衡,就是通过发布三层的IP地址(MIP),然后加四层的端口号,来决定哪些流量需要做负载均衡,对需要处理的流量进行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--172.25.254.100

    下载软件

    编辑工作

     分开写

     合在一起

    重启服务


    环境准备

    Webserver1---172.25.254.10--下载ngnix!!!记得重启服务

    环境准备

    Webserver2---172.25.254.20--下载ngnix!!!记得重启服务

     webserver1和webserver2的实验操作

    测试




     haproxy的基本配置信息

    Haproxy的基本配置信息

    HAProxy 的配置文件haproxy.cfg由两大部分组成,分别是: 
    global :全局配置段
    • 进程及安全配置相关的参数
    • 性能调整相关参数
    • Debug参数
    proxies :代理配置段
    • defaults:为frontend, backend, listen提供默认配置
    • frontend:前端,相当于nginx中的server {}
    • backend:后端,相当于nginx中的upstream {}
    • listen:同时拥有前端和后端配置,配置简单,生产推荐使用

    global配置

    实验:

    1.设置脚本的的行数,避免太多看不清楚及出错

    2.    mode http  七层         mode tcp 四层

    实验1.编写haproxy的配置文件访问服务端内容实现负载均衡

    (在vim /etc/haproxy/haproxy.conf中的两种写法)

    测试结果

    实验2.日志的配置

    定义全局的 syslog 服务器;日志服务器需要开启 UDP 协议,
    最多可以定义两个

    在配置文件中查看local2

    在日志文件添加

    实验3.多进程和socket文件的配置

    1. haproxy ~]# vim /etc/haproxy/haproxy.cfg
    2. ...上面内容省略...
    3. log 127.0.0.1 local2
    4. chroot /var/lib/haproxy
    5. pidfile /var/run/haproxy.pid
    6. maxconn 100000
    7. user haproxy
    8. group haproxy
    9. daemon
    10. # turn on stats unix socket
    11. stats socket /var/lib/haproxy/haproxy.sock1 mode 600 level admin process 1 #
    12. 启用多个sock文件
    13. stats socket /var/lib/haproxy/haproxy.sock2 mode 600 level admin process 2
    14. nbproc 2 #启用多进程
    15. cpu-map 1 0 #进程和cpu核心绑定防止cpu抖动从而减少系统资源消耗
    16. cpu-map 2 1 #2 表示第二个进程,1表示第二个cpu核心
    17. ...下面内容省略 ...

    启动多线程

    1. haproxy ~]# vim /etc/haproxy/haproxy.cfg
    2. ...上面内容省略...
    3. log 127.0.0.1 local2
    4. chroot /var/lib/haproxy
    5. pidfile /var/run/haproxy.pid
    6. maxconn 100000
    7. user haproxy
    8. group haproxy
    9. daemon
    10. # turn on stats unix socket
    11. stats socket /var/lib/haproxy/haproxy.sock1 mode 600 level admin process 1 #
    12. 启用多个sock文件
    13. stats socket /var/lib/haproxy/haproxy.sock2 mode 600 level admin process 2
    14. #nbproc 2
    15. #cpu-map 1 0
    16. #cpu-map 2 1
    17. nbthread 2 #启用多线程
    18. ...下面内容省略...

    注意: 多线程和多进程之间的不能同时使用会互斥

    未开启多线程
    haproxy ~]# cat /proc/xxxx(haproxy 子进程 id)/status
    ... 上面内容省略 ...
    Threads: 1
    ... 下面内容省略 ...
    开启后
    haproxy ~]# cat /proc/xxxx(haproxy 子进程 id)/status
    ... 上面内容省略 ...
    Threads: 2
    ... 下面内容省略 ...

    proxies配置

    proxies参数说明

    server

    # 针对一个 server 配置
    check # 对指定 real 进行健康状态检查,如果不加此设置,默认不开启检查 , 只有 check 后面没
    有其它配置也可以启用检查功能
    # 默认对相应的后端服务器 IP 和端口 , 利用 TCP 连接进行周期性健康性检查 , 注意必须指定
    端口才能实现健康性检查
    addr # 可指定的健康状态监测 IP ,可以是专门的数据网段,减少业务网络的流量
    port # 指定的健康状态监测端口
    inter # 健康状态检查间隔时间,默认 2000 ms
    fall # 后端服务器从线上转为线下的检查的连续失效次数,默认为 3 代码示例:
    测试效果:
    rise # 后端服务器从下线恢复上线的检查的连续有效次数,默认为 2
    weight # 默认为 1 ,最大值为 256 0( 状态为蓝色 ) 表示不参与负载均衡,但仍接受持久连接
    backup # 将后端服务器标记为备份状态 , 只在所有非备份主机 down 机时提供服务,类似 Sorry
    Server
    disabled # 将后端服务器标记为不可用状态,即维护状态,除了持久模式
    # 将不再接受连接 , 状态为深黄色 , 优雅下线 , 不再接受新用户的请求
    redirect prefix http://www.baidu.com/ # 将请求临时 (302) 重定向至其它 URL ,只适用于 http
    maxconn # 当前后端 server 的最大并发连接数

    实验:

    weight

    1. haproxy ~]# vim /etc/haproxy/haproxy.cfg
    2. ...上面内容省略...
    3. backend lee-webserver-80-RS
    4. mode http
    5. server web1 192.168.0.101:80 check inter 3s fall 3 rise 5
    6. server web2 192.168.0.102:80 check inter 3s fall 3 rise 5
    7. ...上面内容省略...

    backend

    首先下载httpd,再配置文件中设置端口号为8080

    注意:此时此刻要注意要关闭web1和web2的内容

    disabled   ----代表下线了

    redirect prefix http://www.baidu.com/        ---重定向网页

    maxconn

    socat工具

    对服务器动态权重和其它状态可以利用 socat 工具进行调整, Socat Linux 下的一个多功能的网络工具,名字来由是Socket CAT ,相当于 netCAT 的增强版 .Socat 的主要特点就是在两个数据流之间建立双向通道,且支持众多协议和链接方式。如 IP TCP UDP IPv6 Socket 文件等

    下载软件socat

    单进程

    1. #查看haproxy状态
    2. [root@haproxy ~]# echo "show info" | socat stdio /var/lib/haproxy/stats
    3. Name: HAProxy
    4. Version: 2.4.22-f8e3218
    5. Release_date: 2023/02/14
    6. Nbthread: 1
    7. Nbproc: 1
    8. Process_num: 1
    9. Pid: 33542
    10. Uptime: 0d 0h03m43s
    11. Uptime_sec: 223
    12. Memmax_MB: 0
    13. PoolAlloc_MB: 0
    14. #查看集群状态
    15. [root@haproxy ~]# echo "show servers state" | socat stdio /var/lib/haproxy/stats
    16. 1
    17. # be_id be_name srv_id srv_name srv_addr srv_op_state srv_admin_state srv_uweight
    18. srv_iweight srv_time_since_last_change srv_check_status srv_check_result
    19. srv_check_health srv_check_state srv_agent_state bk_f_forced_id srv_f_forced_id
    20. srv_fqdn srv_port srvrecord srv_use_ssl srv_check_port srv_check_addr
    21. srv_agent_addr srv_agent_port
    22. 2 webcluster 1 web1 172.25.254.20 2 0 2 2 188 6 3 7 6 0 0 0 - 80 - 0 0 - - 0
    23. 2 webcluster 2 web2 172.25.254.30 2 0 1 1 188 6 3 7 6 0 0 0 - 80 - 0 0 - - 0
    24. 4 static 1 static 127.0.0.1 0 0 1 1 187 8 2 0 6 0 0 0 - 4331 - 0 0 - - 0
    25. 5 app 1 app1 127.0.0.1 0 0 1 1 187 8 2 0 6 0 0 0 - 5001 - 0 0 - - 0
    26. 5 app 2 app2 127.0.0.1 0 0 1 1 187 8 2 0 6 0 0 0 - 5002 - 0 0 - - 0
    27. 5 app 3 app3 127.0.0.1 0 0 1 1 186 8 2 0 6 0 0 0 - 5003 - 0 0 - - 0
    28. 5 app 4 app4 127.0.0.1 0 0 1 1 186 8 2 0 6 0 0 0 - 5004 - 0 0 - - 0
    29. #查看集群权重
    30. [root@haproxy ~]# echo get weight webcluster/web1 | socat stdio
    31. /var/lib/haproxy/stats
    32. 2 (initial 2)
    33. [root@haproxy ~]# echo get weight webcluster/web2 | socat stdio
    34. /var/lib/haproxy/stats
    35. 1 (initial 1)
    36. #设置权重
    37. [root@haproxy ~]# echo "set weight webcluster/web1 1 " | socat stdio
    38. /var/lib/haproxy/stats
    39. [root@haproxy ~]# echo "set weight webcluster/web1 2 " | socat stdio
    40. /var/lib/haproxy/stats
    41. #下线后端服务器
    42. [root@haproxy ~]# echo "disable server webcluster/web1 " | socat stdio
    43. /var/lib/haproxy/stats
    44. #上线后端服务器
    45. [root@haproxy ~]# echo "enable server webcluster/web1 " | socat stdio
    46. /var/lib/haproxy/stats

    多进程


    haproxy的算法

    HAProxy通过固定参数 balance 指明对后端服务器的调度算法
    balance参数可以配置在listen或backend选项中。
    HAProxy的调度算法分为静态和动态调度算法
    有些算法可以根据参数在静态和动态算法中相互转换。
    静态算法:
    静态算法:按照事先定义好的规则轮询公平调度,不关心后端服务器的当前负载、连接数和响应速度等,且无法实时修改权重( 只能为 0 1, 不支持其它值 ) ,只能靠重启 HAProxy 生效。
    static-rr :基于权重的轮询调度
    • 不支持运行时利用socat进行权重的动态调整(只支持01,不支持其它值)
    • 不支持端服务器慢启动
    • 其后端主机数量没有限制,相当于LVS中的 wrr
    实验:静态

    注意:socat不能修改权重

    first

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

    动态算法
    • 基于后端服务器状态进行调度适当调整,
    • 新请求将优先调度至当前负载较低的服务器
    • 权重可以在haproxy运行时动态调整无需重启
    roundrobin
    1. 基于权重的轮询动态调度算法,
    2. 支持权重的运行时调整,不同于 lvs 中的 rr 轮训模式,
    3. HAProxy 中的 roundrobin 支持慢启动 ( 新加的服务器会逐渐增加转发数 )
    4. 其每个后端 backend 中最多支持 4095 real server
    5. 支持对 real server 权重动态调整,
    6. roundrobin 为默认调度算法 , 此算法使用广泛

    实验:

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

    实验:

    其他算法

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

    实验:

    如果访问客户端时一个家庭,那么所有的家庭的访问流量都会被定向到一台服务器,这时source算 法的缺陷!!!!!

    map-base 取模法(静态)
    1. haproxy ~]# vim /etc/haproxy/haproxy.cfg
    2. ...上面内容省略...
    3. listen webserver_80
    4. bind 172.25.254.100:80
    5. mode http
    6. balance source
    7. server webserver1 192.168.0.101:80 weight 1 check inter 3s fall 3 rise 5
    8. server webserver2 192.168.0.102:80 weight 1 check inter 3s fall 3 rise 5
    9. ...上面内容省略...
    10. #不支持动态调整权重值
    11. [root@haproxy ~]# echo "set weight webserver_80/webserver1 2" | socat stdio
    12. /var/lib/haproxy/haproxy.sock
    13. Backend is using a static LB algorithm and only accepts weights '0%' and '100%'.
    14. #只能动态上线和下线
    15. [root@haproxy ~]# echo "set weight webserver_80/webserver1 0" | socat stdio
    16. /var/lib/haproxy/haproxy.sock
    17. [root@haproxy ~]# echo "get weight webserver_80/webserver1" | socat stdio
    18. /var/lib/haproxy/haproxy.sock
    19. 0 (initial 1)
    !!!!!一致性hash(动态)(会有一篇专门博客介绍)
    1. haproxy ~]# vim /etc/haproxy/haproxy.cfg
    2. ...上面内容省略...
    3. listen webserver_80
    4. bind 172.25.254.100:80
    5. mode http
    6. balance source
    7. hash-type consistent
    8. server webserver1 192.168.0.101:80 weight 1 check inter 3s fall 3 rise 5
    9. server webserver2 192.168.0.102:80 weight 1 check inter 3s fall 3 rise 5
    10. ...上面内容省略...

    实验:

    动态调整权限

    url

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

    注意:此算法基于应用层,所以只支持 mode http ,不支持 mode tcp

    实验:

    uri 取模法配置示例

    1. haproxy ~]# vim /etc/haproxy/haproxy.cfg
    2. ...上面内容省略...
    3. listen webserver_80
    4. bind 172.25.254.100:80
    5. mode http
    6. balance uri
    7. server webserver1 192.168.0.101:80 weight 1 check inter 3s fall 3 rise 5
    8. server webserver2 192.168.0.102:80 weight 1 check inter 3s fall 3 rise 5
    9. ...上面内容省略...

    uri 一致性hash配置示例

    注意:只要第一次不变第二次依旧访问那个路径以及效果

    url_param
    url_param 取模法配置示例
    1. haproxy ~]# vim /etc/haproxy/haproxy.cfg
    2. ...上面内容省略...
    3. listen webserver_80
    4. bind 172.25.254.100:80
    5. mode http
    6. balance url_param name,userid #支持对多个url_param hash
    7. server webserver1 192.168.0.101:80 weight 1 check inter 3s fall 3 rise 5
    8. server webserver2 192.168.0.102:80 weight 1 check inter 3s fall 3 rise 5
    9. ...上面内容省略...
    url_param 一致性 hash 配置示例

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

    实验:

    hdr 取模法配置示例
    1. haproxy ~]# vim /etc/haproxy/haproxy.cfg
    2. ...上面内容省略...
    3. listen webserver_80
    4. bind 172.25.254.100:80
    5. mode http
    6. balance hdr(User-Agent)
    7. server webserver1 192.168.0.101:80 weight 1 check inter 3s fall 3 rise 5
    8. server webserver2 192.168.0.102:80 weight 1 check inter 3s fall 3 rise 5
    9. ...上面内容省略...
    一致性 hash 配置示例

    上面的指示是代表着浏览器


    算法总结:

    #静态
    static-rr--------->tcp/http
    first------------->tcp/http
    #动态
    roundrobin-------->tcp/http
    leastconn--------->tcp/http
    #以下静态和动态取决于hash_type是否consistent
    source------------>tcp/http
    Uri--------------->http
    url_param--------->http
    hdr--------------->http
    利用算法,凡是指定了一次及时多次指定都会一直不变:简单记:专一

    HAProxy状态页

    启动状态页


    高级功能及配置

    1.基于cookie的会话保持

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

    配置示例

    2.IP透传

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

    1.七层IP透传

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

    测试原文件自带的

    web服务器日志格式配置
    apache(172.25.254.10)

    测试:

    2.四层IP透传

    总的测试

    四层的时候apache不能找到,基本上访问不了,因此选用七层。

    3.ACL

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

    ACL实验--ACL-criterion匹配规范

    1. hdr string,提取在一个HTTP请求报文的首部
    2. hdr([<name> [,<occ>]]):完全匹配字符串,header的指定信息,<occ> 表示在多值中使用的值的出
    3. 现次数
    4. hdr_beg([<name> [,<occ>]]):前缀匹配,header中指定匹配内容的begin
    5. hdr_end([<name> [,<occ>]]):后缀匹配,header中指定匹配内容end
    6. hdr_dom([<name> [,<occ>]]):域匹配,header中的dom(host)
    7. hdr_dir([<name> [,<occ>]]):路径匹配,header的uri路径
    8. hdr_len([<name> [,<occ>]]):长度匹配,header的长度匹配
    9. hdr_reg([<name> [,<occ>]]):正则表达式匹配,自定义表达式(regex)模糊匹配
    10. hdr_sub([<name> [,<occ>]]):子串匹配,header中的uri模糊匹配 模糊匹配c 报文中a/b/c也会匹
    11. #示例:
    12. hdr(<string>) 用于测试请求头部首部指定内容
    13. hdr_dom(host) 请求的host名称,如 www.timinglee.org
    14. hdr_beg(host) 请求的host开头,如 www. img. video. download. ftp.
    15. hdr_end(host) 请求的host结尾,如 .com .net .cn
    16. #示例:
    17. acl bad_agent hdr_sub(User-Agent) -i curl wget
    18. http-request deny if bad_agent
    19. #有些功能是类似的,比如以下几个都是匹配用户请求报文中host的开头是不是www
    20. acl short_form hdr_beg(host) www.
    21. acl alternate1 hdr_beg(host) -m beg www.
    22. acl alternate2 hdr_dom(host) -m beg www.
    23. acl alternate3 hdr(host) -m beg www.
    24. base : string
    25. #返回第一个主机头和请求的路径部分的连接,该请求从主机名开始,并在问号之前结束,对虚拟主机有用
    26. <scheme>://<user>:<password>@#<host>:<port>/<path>;<params>#?<query>#<frag>
    27. base : exact string match
    28. base_beg : prefix match
    29. base_dir : subdir match
    30. base_dom : domain match
    31. base_end : suffix match
    32. base_len : length match
    33. base_reg : regex match
    34. base_sub : substring match
    35. path : string
    36. #提取请求的URL路径,该路径从第一个斜杠开始,并在问号之前结束(无主机部分)
    37. <scheme>://<user>:<password>@<host>:<port>#/<path>;<params>#?<query>#<frag>
    38. path : exact string match
    39. path_beg : prefix match #请求的URL开头,如/static、/images、/img、/css
    40. path_end : suffix match #请求的URL中资源的结尾,如 .gif .png .css .js .jpg .jpeg
    41. path_dom : domain match
    42. path_dir : subdir match
    43. path_len : length match
    44. path_reg : regex match
    45. path_sub : substring match
    46. #示例:
    47. path_beg -i /haproxy-status/
    48. path_end .jpg .jpeg .png .gif
    49. path_reg ^/images.*\.jpeg$
    50. path_sub image
    51. path_dir jpegs
    52. path_dom timinglee
    53. url : string
    54. #提取请求中的整个URL。
    55. url :exact string match
    56. url_beg : prefix match
    57. url_dir : subdir match
    58. url_dom : domain match
    59. url_end : suffix match
    60. url_len : length match
    61. url_reg : regex match
    62. url_sub : substring match
    63. dst #目标IP
    64. dst_port #目标PORT
    65. src #源IP
    66. src_port #源PORT
    67. #示例:
    68. acl invalid_src src 10.0.0.7 192.168.1.0/24
    69. acl invalid_src src 172.16.0.0/24
    70. acl invalid_port src_port 0:1023
    71. status : integer #返回在响应报文中的状态码
    72. #七层协议
    73. acl valid_method method GET HEAD
    74. http-request deny if ! valid_method
    hdr_dom
     

     hdr_end

    hdr_beg

    ACL实验--匹配规范

    -i 不区分大小写
    -m 使用指定的正则表达式匹配方法
    -n 不做 DNS 解析
    -u 禁止 acl 重名,否则多个同名 ACL 匹配或关系

     base_sub -m 

    结果: 凡是curl 路径中的lee无论在哪都能访问

    base_reg 以什么结尾

    path_sub - m 以什么结尾

    判断:

    ACL实验--域名匹配

     

    ACL实验--基于源IP和子网调动访问

     

    ACL实验--基于源地址访问控制

    1. haproxy ~]# vim /etc/haproxy/haproxy.cfg
    2. ...上面内容省略...
    3. frontend testacl
    4. bind :80
    5. mode http
    6. ########### ACL settings #######################
    7. acl web_host hdr_dom(host) www.timinglee.org
    8. acl ip_test src 172.25.254.1 192.168.0.0/24
    9. ########### host ###########################
    10. http-request deny if web_host
    11. ########### default server ###################
    12. default_backend default_webserver
    13. 测试
    14. 5.4.6 ACL示例-匹配浏览器类型
    15. 匹配客户端浏览器,将不同类型的浏览器调动至不同的服务器组、
    16. 范例: 拒绝curl和wget的访问
    17. 示例:
    18. backend ip_test-host
    19. mode http
    20. server web1 192.168.0.101:80 check weight 1 inter 3s fall 3 rise 5
    21. backend default_webserver
    22. mode http
    23. server web1 172.25.254.10:80 check weight 1 inter 3s fall 3 rise 5

     拒接的话:

    ACL实验--匹配浏览器类型

     

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

     172.25.254.10

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

      

    基于http重定向输出错误

     

    四层负载

    172.25.254.10/172.25.254.20

    1. #在后端服务器安装和配置mariadb服务
    2. rs1 ~]# yum install mariadb-server -y
    3. rs2 ~]# yum install mariadb-server -y
    4. rs1 ~]# vim /etc/my.cnf
    5. [mysqld]
    6. server-id=1 #在另一台主机为
    7. rs2 ~]# vim /etc/my.cnf
    8. [mysqld]
    9. server-id=2 #在另一台主机为
    10. rs1 ~]# systemctl start mariadb
    11. rs2 ~]# systemctl start mariadb
    12. rs1 ~]# mysql -e "grant all on *.* to lee@'%' identified by 'lee';"
    13. rs2 ~]# mysql -e "grant all on *.* to lee@'%' identified by 'lee';"
    14. #测试
    15. [root@node10 ~]# mysql -ulee -plee -h 172.25.254.100 -e "show variables like
    16. 'hostname'"
    17. +---------------+-------+
    18. | Variable_name | Value |
    19. +---------------+-------+
    20. | hostname | rs2 |
    21. +---------------+-------+
    22. [root@node10 ~]# mysql -ulee -plee -h 172.25.254.100 -e "show variables like
    23. 'hostname'"
    24. +---------------+-------+
    25. | Variable_name | Value |
    26. +---------------+-------+
    27. | hostname | rs1 |
    28. +---------------+-------+
    29. [root@node10 ~]# mysql -ulee -plee -h172.25.254.100 -e "select @@server_id"
    30. +-------------+
    31. | @@server_id |
    32. +-------------+
    33. | 1 |
    34. +-------------+
    35. [root@node10 ~]# mysql -ulee -plee -h172.25.254.100 -e "select @@server_id"
    36. +-------------+
    37. | @@server_id |
    38. +-------------+
    39. | 2 |
    40. +-------------+

    172.25.254.12

    172.25.254.12的效果:

    172.25.254.20的效果

    172.25.254.10的效果

    证书制定

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

    生成给公钥和私钥

  • 相关阅读:
    python协整与异步调用,压榨程序的摸鱼时间——异步改写一般程序(1)
    集成学习方法之随机森林-入门
    使用OpenMMLab系列的开源库时,常用的脚本合集。
    AcWing 1480:电梯
    如何入门学习黑客技术?如何选择编程语言?如何选择适合黑客的操作系统?
    图书管理系统的设计与实现/ssm的图书管理网站
    一篇教程搞定Windows系统中的Docker应用安装
    Qt基础之三十九:Qt Creator调试技巧
    Redis数据结构:集合
    大新闻!【比特熊故事汇】升级2.0
  • 原文地址:https://blog.csdn.net/m0_64570996/article/details/141004136