阅读量:0
负载均衡
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文件的配置
haproxy ~]# vim /etc/haproxy/haproxy.cfg ...上面内容省略... log 127.0.0.1 local2 chroot /var/lib/haproxy pidfile /var/run/haproxy.pid maxconn 100000 user haproxy group haproxy daemon # turn on stats unix socket stats socket /var/lib/haproxy/haproxy.sock1 mode 600 level admin process 1 # 启用多个sock文件 stats socket /var/lib/haproxy/haproxy.sock2 mode 600 level admin process 2 nbproc 2 #启用多进程 cpu-map 1 0 #进程和cpu核心绑定防止cpu抖动从而减少系统资源消耗 cpu-map 2 1 #2 表示第二个进程，1表示第二个cpu核心 ...下面内容省略 ...
启动多线程
haproxy ~]# vim /etc/haproxy/haproxy.cfg ...上面内容省略... log 127.0.0.1 local2 chroot /var/lib/haproxy pidfile /var/run/haproxy.pid maxconn 100000 user haproxy group haproxy daemon # turn on stats unix socket stats socket /var/lib/haproxy/haproxy.sock1 mode 600 level admin process 1 # 启用多个sock文件 stats socket /var/lib/haproxy/haproxy.sock2 mode 600 level admin process 2 #nbproc 2 #cpu-map 1 0 #cpu-map 2 1 nbthread 2 #启用多线程 ...下面内容省略...
注意： 多线程和多进程之间的不能同时使用会互斥
未开启多线程 haproxy ~]# cat /proc/xxxx(haproxy子进程id)/status ...上面内容省略... Threads: 1 ...下面内容省略... 开启后 haproxy ~]# cat /proc/xxxx(haproxy子进程id)/status ...上面内容省略... Threads: 2 ...下面内容省略...proxies配置
proxies参数说明
#针对一个server配置 check #对指定real进行健康状态检查，如果不加此设置，默认不开启检查,只有check后面没 有其它配置也可以启用检查功能 #默认对相应的后端服务器IP和端口,利用TCP连接进行周期性健康性检查,注意必须指定 端口才能实现健康性检查 addr <IP> #可指定的健康状态监测IP，可以是专门的数据网段，减少业务网络的流量 port <num> #指定的健康状态监测端口 inter <num> #健康状态检查间隔时间，默认2000 ms fall <num> #后端服务器从线上转为线下的检查的连续失效次数，默认为3代码示例： 测试效果： rise <num> #后端服务器从下线恢复上线的检查的连续有效次数，默认为2 weight <weight> #默认为1，最大值为256，0(状态为蓝色)表示不参与负载均衡，但仍接受持久连接 backup #将后端服务器标记为备份状态,只在所有非备份主机down机时提供服务，类似Sorry Server disabled #将后端服务器标记为不可用状态，即维护状态，除了持久模式 #将不再接受连接,状态为深黄色,优雅下线,不再接受新用户的请求 redirect prefix http://www.baidu.com/ #将请求临时(302)重定向至其它URL，只适用于http模 式 maxconn <maxconn> #当前后端server的最大并发连接数server
实验：
weight
haproxy ~]# vim /etc/haproxy/haproxy.cfg ...上面内容省略... backend lee-webserver-80-RS mode http server web1 192.168.0.101:80 check inter 3s fall 3 rise 5 server web2 192.168.0.102:80 check inter 3s fall 3 rise 5 ...上面内容省略... 
backend
首先下载httpd，再配置文件中设置端口号为8080
注意：此时此刻要注意要关闭web1和web2的内容
disabled ----代表下线了
redirect prefix http://www.baidu.com/ ---重定向网页
maxconn <maxconn>
对服务器动态权重和其它状态可以利用 socat工具进行调整，Socat 是 Linux 下的一个多功能的网络工具，名字来由是Socket CAT，相当于netCAT的增强版.Socat 的主要特点就是在两个数据流之间建立双向通道，且支持众多协议和链接方式。如 IP、TCP、 UDP、IPv6、Socket文件等socat工具
下载软件socat
单进程
#查看haproxy状态 [root@haproxy ~]# echo "show info" | socat stdio /var/lib/haproxy/stats Name: HAProxy Version: 2.4.22-f8e3218 Release_date: 2023/02/14 Nbthread: 1 Nbproc: 1 Process_num: 1 Pid: 33542 Uptime: 0d 0h03m43s Uptime_sec: 223 Memmax_MB: 0 PoolAlloc_MB: 0 #查看集群状态 [root@haproxy ~]# echo "show servers state" | socat stdio /var/lib/haproxy/stats 1 # be_id be_name srv_id srv_name srv_addr srv_op_state srv_admin_state srv_uweight srv_iweight srv_time_since_last_change srv_check_status srv_check_result srv_check_health srv_check_state srv_agent_state bk_f_forced_id srv_f_forced_id srv_fqdn srv_port srvrecord srv_use_ssl srv_check_port srv_check_addr srv_agent_addr srv_agent_port 2 webcluster 1 web1 172.25.254.20 2 0 2 2 188 6 3 7 6 0 0 0 - 80 - 0 0 - - 0 2 webcluster 2 web2 172.25.254.30 2 0 1 1 188 6 3 7 6 0 0 0 - 80 - 0 0 - - 0 4 static 1 static 127.0.0.1 0 0 1 1 187 8 2 0 6 0 0 0 - 4331 - 0 0 - - 0 5 app 1 app1 127.0.0.1 0 0 1 1 187 8 2 0 6 0 0 0 - 5001 - 0 0 - - 0 5 app 2 app2 127.0.0.1 0 0 1 1 187 8 2 0 6 0 0 0 - 5002 - 0 0 - - 0 5 app 3 app3 127.0.0.1 0 0 1 1 186 8 2 0 6 0 0 0 - 5003 - 0 0 - - 0 5 app 4 app4 127.0.0.1 0 0 1 1 186 8 2 0 6 0 0 0 - 5004 - 0 0 - - 0 #查看集群权重 [root@haproxy ~]# echo get weight webcluster/web1 | socat stdio /var/lib/haproxy/stats 2 (initial 2) [root@haproxy ~]# echo get weight webcluster/web2 | socat stdio /var/lib/haproxy/stats 1 (initial 1) #设置权重 [root@haproxy ~]# echo "set weight webcluster/web1 1 " | socat stdio /var/lib/haproxy/stats [root@haproxy ~]# echo "set weight webcluster/web1 2 " | socat stdio /var/lib/haproxy/stats #下线后端服务器 [root@haproxy ~]# echo "disable server webcluster/web1 " | socat stdio /var/lib/haproxy/stats #上线后端服务器 [root@haproxy ~]# echo "enable server webcluster/web1 " | socat stdio /var/lib/haproxy/stats
多进程
haproxy的算法
HAProxy通过固定参数 balance 指明对后端服务器的调度算法 balance参数可以配置在listen或backend选项中。 HAProxy的调度算法分为静态和动态调度算法 有些算法可以根据参数在静态和动态算法中相互转换。静态算法：静态算法：按照事先定义好的规则轮询公平调度，不关心后端服务器的当前负载、连接数和响应速度等，且无法实时修改权重(只能为0和1,不支持其它值)，只能靠重启HAProxy生效。static-rr：基于权重的轮询调度- 不支持运行时利用socat进行权重的动态调整(只支持0和1,不支持其它值)
- 不支持端服务器慢启动
- 其后端主机数量没有限制，相当于LVS中的 wrr
实验：静态
注意：socat不能修改权重
first
- 根据服务器在列表中的位置，自上而下进行调度
- 其只会当第一台服务器的连接数达到上限，新请求才会分配给下一台服务
- 其会忽略服务器的权重设置
- 不支持用socat进行动态修改权重,可以设置0和1,可以设置其它值但无效
动态算法
- 基于后端服务器状态进行调度适当调整，
- 新请求将优先调度至当前负载较低的服务器
- 权重可以在haproxy运行时动态调整无需重启
实验：
- leastconn加权的最少连接的动态
- 支持权重的运行时调整和慢启动，即:根据当前连接最少的后端服务器而非权重进行优先调度(新客户 端连接)
- 比较适合长连接的场景使用，比如：MySQL等场景。
实验：
其他算法
其它算法即可作为静态算法，又可以通过选项成为动态算法source 源地址hash，基于用户源地址hash并将请求转发到后端服务器，后续同一个源地址请求将被转发至同一个后端web服务器。此方式当后端服务器数据量发生变化时，会导致很多用户的请求转发至新的后端服务器，默认为静态方式，但是可以通过hash-type支持的选项更改这个算法一般是在不插入Cookie的TCP模式下使用，也可给拒绝会话cookie的客户提供最好的会话粘性，适用于session会话保持但不支持cookie和缓存的场景源地址有两种转发客户端请求到后端服务器的服务器选取计算方式，分别是取模法和一致性hash实验：
haproxy ~]# vim /etc/haproxy/haproxy.cfg ...上面内容省略... listen webserver_80 bind 172.25.254.100:80 mode http balance source server webserver1 192.168.0.101:80 weight 1 check inter 3s fall 3 rise 5 server webserver2 192.168.0.102:80 weight 1 check inter 3s fall 3 rise 5 ...上面内容省略... #不支持动态调整权重值 [root@haproxy ~]# echo "set weight webserver_80/webserver1 2" | socat stdio /var/lib/haproxy/haproxy.sock Backend is using a static LB algorithm and only accepts weights '0%' and '100%'. #只能动态上线和下线 [root@haproxy ~]# echo "set weight webserver_80/webserver1 0" | socat stdio /var/lib/haproxy/haproxy.sock [root@haproxy ~]# echo "get weight webserver_80/webserver1" | socat stdio /var/lib/haproxy/haproxy.sock 0 (initial 1)haproxy ~]# vim /etc/haproxy/haproxy.cfg ...上面内容省略... listen webserver_80 bind 172.25.254.100:80 mode http balance source hash-type consistent server webserver1 192.168.0.101:80 weight 1 check inter 3s fall 3 rise 5 server webserver2 192.168.0.102:80 weight 1 check inter 3s fall 3 rise 5 ...上面内容省略...实验：
动态调整权限
url
- 基于对用户请求的URI的左半部分或整个uri做hash，再将hash结果对总权重进行取模后
- 根据最终结果将请求转发到后端指定服务器
- 适用于后端是缓存服务器场景
- 默认是静态算法，也可以通过hash-type指定map-based和consistent，来定义使用取模法还是一致性
注意：此算法基于应用层，所以只支持 mode http ，不支持 mode tcp
实验：
uri 取模法配置示例
haproxy ~]# vim /etc/haproxy/haproxy.cfg ...上面内容省略... listen webserver_80 bind 172.25.254.100:80 mode http balance uri server webserver1 192.168.0.101:80 weight 1 check inter 3s fall 3 rise 5 server webserver2 192.168.0.102:80 weight 1 check inter 3s fall 3 rise 5 ...上面内容省略...uri 一致性hash配置示例
注意：只要第一次不变第二次依旧访问那个路径以及效果
url_param url_param取模法配置示例haproxy ~]# vim /etc/haproxy/haproxy.cfg ...上面内容省略... listen webserver_80 bind 172.25.254.100:80 mode http balance url_param name,userid #支持对多个url_param hash server webserver1 192.168.0.101:80 weight 1 check inter 3s fall 3 rise 5 server webserver2 192.168.0.102:80 weight 1 check inter 3s fall 3 rise 5 ...上面内容省略...
- 针对用户每个http头部(header)请求中的指定信息做hash，
- 此处由 name 指定的http首部将会被取出并做hash计算，
- 然后由服务器总权重取模以后派发至某挑出的服务器，如果无有效值，则会使用默认的轮询调度。
实验：
hdr取模法配置示例haproxy ~]# vim /etc/haproxy/haproxy.cfg ...上面内容省略... listen webserver_80 bind 172.25.254.100:80 mode http balance hdr(User-Agent) server webserver1 192.168.0.101:80 weight 1 check inter 3s fall 3 rise 5 server webserver2 192.168.0.102:80 weight 1 check inter 3s fall 3 rise 5 ...上面内容省略...
上面的指示是代表着浏览器
算法总结：
#静态 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至后端服务器
测试原文件自带的
测试：
2.四层IP透传
总的测试
四层的时候apache不能找到，基本上访问不了，因此选用七层。
3.ACL
访问控制列表ACL，Access Control Lists） 是一种基于包过滤的访问控制技术 它可以根据设定的条件对经过服务器传输的数据包进行过滤(条件匹配)即对接收到的报文进行匹配和过滤，基于请求报文头部中的源地址、源端口、目标地址、目标端口、请求方法、URL、文件后缀等信息内容进行匹配并执行进一步操作，比如允许其通过或丢弃。ACL实验--ACL-criterion匹配规范
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也会匹 配 #示例： hdr(<string>) 用于测试请求头部首部指定内容 hdr_dom(host) 请求的host名称，如 www.timinglee.org hdr_beg(host) 请求的host开头，如 www. img. video. download. ftp. hdr_end(host) 请求的host结尾，如 .com .net .cn #示例： acl bad_agent hdr_sub(User-Agent) -i curl wget http-request deny if bad_agent #有些功能是类似的，比如以下几个都是匹配用户请求报文中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路径，该路径从第一个斜杠开始，并在问号之前结束（无主机部分） <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 #示例： path_beg -i /haproxy-status/ path_end .jpg .jpeg .png .gif path_reg ^/images.*\.jpeg$ path_sub image path_dir jpegs path_dom timinglee 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 #示例： acl invalid_src src 10.0.0.7 192.168.1.0/24 acl invalid_src src 172.16.0.0/24 acl invalid_port src_port 0:1023 status : integer #返回在响应报文中的状态码 #七层协议 acl valid_method method GET HEAD http-request deny if ! valid_method
hdr_end
ACL实验--匹配规范
-i 不区分大小写 -m 使用指定的正则表达式匹配方法 -n 不做DNS解析 -u 禁止acl重名，否则多个同名ACL匹配或关系
base_sub -m
结果： 凡是curl 路径中的lee无论在哪都能访问
base_reg 以什么结尾
path_sub - m 以什么结尾
判断：
ACL实验--域名匹配
ACL实验--基于源IP和子网调动访问
ACL实验--基于源地址访问控制
haproxy ~]# vim /etc/haproxy/haproxy.cfg ...上面内容省略... frontend testacl bind :80 mode http ########### ACL settings ####################### acl web_host hdr_dom(host) www.timinglee.org acl ip_test src 172.25.254.1 192.168.0.0/24 ########### host ########################### http-request deny if web_host ########### default server ################### default_backend default_webserver 测试 5.4.6 ACL示例-匹配浏览器类型 匹配客户端浏览器，将不同类型的浏览器调动至不同的服务器组、 范例: 拒绝curl和wget的访问 示例： backend ip_test-host mode http server web1 192.168.0.101:80 check weight 1 inter 3s fall 3 rise 5 backend default_webserver mode http 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
#在后端服务器安装和配置mariadb服务 rs1 ~]# yum install mariadb-server -y rs2 ~]# yum install mariadb-server -y rs1 ~]# vim /etc/my.cnf [mysqld] server-id=1 #在另一台主机为 rs2 ~]# vim /etc/my.cnf [mysqld] server-id=2 #在另一台主机为 rs1 ~]# systemctl start mariadb rs2 ~]# systemctl start mariadb rs1 ~]# mysql -e "grant all on *.* to lee@'%' identified by 'lee';" rs2 ~]# mysql -e "grant all on *.* to lee@'%' identified by 'lee';" #测试 [root@node10 ~]# mysql -ulee -plee -h 172.25.254.100 -e "show variables like 'hostname'" +---------------+-------+ | Variable_name | Value | +---------------+-------+ | hostname | rs2 | +---------------+-------+ [root@node10 ~]# mysql -ulee -plee -h 172.25.254.100 -e "show variables like 'hostname'" +---------------+-------+ | Variable_name | Value | +---------------+-------+ | hostname | rs1 | +---------------+-------+ [root@node10 ~]# mysql -ulee -plee -h172.25.254.100 -e "select @@server_id" +-------------+ | @@server_id | +-------------+ | 1 | +-------------+ [root@node10 ~]# mysql -ulee -plee -h172.25.254.100 -e "select @@server_id" +-------------+ | @@server_id | +-------------+ | 2 | +-------------+
172.25.254.12
172.25.254.12的效果：
172.25.254.20的效果
172.25.254.10的效果
haproxy可以实现https的证书安全,从用户到haproxy为https,从haproxy到后端服务器用http通信 但基于性能考虑,生产中证书都是在后端服务器比如nginx上实现证书制定
生成给公钥和私钥
