10--7层负载均衡集群

发布于：2024-06-29 ⋅ 阅读:(20) ⋅ 点赞:(0)

前言：动静分离，资源分离都是在7层负载均衡完成的，此处常被与四层负载均衡比较，本章这里使用haproxy与nginx进行负载均衡总结演示。

1、基础概念详解

1.1、负载均衡

4层负载均衡和7层负载均衡是两种常见的负载均衡技术，它们在网络和应用分发方面有着不同的工作方式和应用场景。

1.1.1、4层负载均衡

4层负载均衡工作在OSI模型的第四层，即传输层。它主要基于数据包的源IP地址、目标IP地址、源端口号和目标端口号等信息来进行负载均衡和流量分发。

原理解释： 想象一家快递公司，每个快递包裹上都有发件人和收件人的地址，以及一个独特的包裹号码。4层负载均衡就像是一个分拣员，根据包裹的地址和号码来决定把包裹送到哪个目的地，但并不了解包裹的内容。这里的地址和号码就相当于数据包中的IP地址和端口号，通过这些信息来决定将请求分发给哪台服务器处理。

应用场景： 4层负载均衡通常用于基于TCP和UDP协议的负载均衡，能够有效地处理大量的网络流量和连接请求。它适用于需要高效处理大规模连接的场景，如网站访问、数据库访问等。

1.1.2、7层负载均衡 

7层负载均衡工作在OSI模型的第七层，即应用层。它不仅考虑网络数据包的源IP地址、目标IP地址和端口号，还深入到数据包的负载内容，比如HTTP请求的URL、Cookie等信息，从而做更加智能化的请求分发和负载均衡。

原理解释： 想象一位精明的接待员在一家酒店大堂里工作，不仅知道每位客人的姓名和房间号（相当于IP地址和端口号），还知道每位客人的需求和偏好（相当于HTTP请求的URL和Cookie信息）。7层负载均衡就像这位接待员，可以根据客人的需求和偏好，智能地将请求分发给最合适的服务节点处理。

应用场景： 7层负载均衡广泛应用于需要深度应用内容分发的场景，如Web应用程序中的HTTP和HTTPS流量、应用程序级别的负载均衡（如基于域名的负载均衡）。它能够根据应用层的信息做出更精细化的流量调度和应用服务优化。

1.1.3、总结

4层负载均衡更注重于网络连接的管理和分发，而7层负载均衡则在应用层面上更为智能化地进行请求的处理和分发。选择合适的负载均衡技术取决于具体的应用需求和性能要求。

1.2、HAProxy

1.2.1、HAProxy的特点

1、HAProxy支持虚拟主机。

2、HAProxy的优点能够补充Nginx的一些缺点，比如支持Session的保持，Cookie的引导 同时支持通过获取指定的url来检测后端服务器的状态

3、HAProxy跟LVS类似，本身就只是一款负载均衡软件 单纯从效率上来讲HAProxy会比Nginx有更出色的负载均衡速度，在并发处理上也是优于Nginx

4、HAProxy支持TCP协议的负载均衡转发，可以对MySQL读进行负载均衡 对后端的MySQL节点进行检测和负载均衡

5、支持8种左右的负载均衡算法，尤其是在http模式时，有许多非常实用的负载均衡算法，适用各种需求。

1.2.3、HAProxy Session亲缘性

haproxy负载均衡保持客户端和服务器Session亲缘性的三种方式

  • 用户IP识别
  • cookie识别
  • session识别

2、HAProxy部署

2.1、基础环境

环境内默认关闭防火墙和selinux，时间同步完成，配置域名解析

IP 角色
192.168.188.128

HAproxy
192.168.188.129 web1
192.168.188.130 web2

2.2、web服务器部署

[root@localhost ~]# yum install -y httpd
[root@localhost ~]# echo ">>>>>>>>>>>>>>>web1<<<<<<<<<<<<<" > /var/www/html/index.html
    #    web2配置这里时把网页内容修改一下方便观察
[root@localhost ~]#  systemctl start httpd
[root@localhost ~]#  systemctl enable httpd
Created symlink from /etc/systemd/system/multi-user.target.wants/httpd.service to /usr/lib/systemd/system/httpd.service.

2.3、HAproxy部署

[root@localhost ~]# yum install -y epel-release
[root@localhost ~]# yum install -y haproxy
    #    注意下方的域名解析
[root@localhost ~]# cat /etc/hosts
127.0.0.1   localhost localhost.localdomain localhost4 localhost4.localdomain4
::1         localhost localhost.localdomain localhost6 localhost6.localdomain6
192.168.188.129 web1
192.168.188.130 web2

[root@localhost ~]# vim /etc/haproxy/haproxy.cfg
    #    配置文件内容下方单独展示
[root@localhost ~]# systemctl restart haproxy

 haproxy配置文件内容

[root@localhost ~]# cat /etc/haproxy/haproxy.cfg 
global
#全局设置
	log 127.0.0.1 local3 info
	#日志 放在本地 自定义型 日志级别
	maxconn 4096
	#haproxy能接受的最大连接数
        uid nobody
	#uid 99
        gid nobody
	#gid 99
	#上面四行是运行haproxy的身份，使用的是linux自带的nobody账户，两个注释行代表不同版本的配置方式
	#有些版本使用用户名会在日志产生警告，有些版本使用id会产生警告
	daemon
	#守护进程运行
	nbproc 1
	#进程启动的数量，一般用服务器核心数
	pidfile /run/haproxy.pid
	#haproxy进程ID存储位置
defaults
#默认设置，有些部分和global重复
	log global
	#日志设置遵循全局设置
	mode http
	#应用层7层模式，可检测url
	maxconn 2048
	#最大的连接数2048，default优先级大于global，这个设置覆盖上方设置
	retries 3
	#后端服务器健康检查。3次连接失败就认为后端服务器不可用
	option	redispatch
	#服务不可用后的操作，重定向到其他健康服务器
	contimeout 5000
	#（重传计时器）定义haproxy将客户端请求转发至后端服务器，所等待的超时时长
	clitimeout 50000
	#（向后长连接）haproxy作为客户，和后端服务器之间!!!空闲连接!!!的超时时间，到时候发送fin指令
	srvtimeout 50000
	#（向前长连接）haproxy作为服务器，和用户之间空闲连接的超时时间，到时候发送fin指令
	#timeout connect 5000
	#timeout client 50000
	#timeout server 50000
	#这三行是上面计时器的另一种写法，和uid部分一样，是避免版本不同产生警告信息的写法
	option abortonclose
	#当服务器负载很高的时候，自动结束掉当前队列处理比较久的链接

	stats uri /admin?stats
	#配置haproxy统计监测页面为/admin?stats
    	stats realm Private lands
	#设置统计页面认证时的提示内容
	stats auth admin:password
	#配置进入统计监测页面的用户名和密码
	stats hide-version
	#隐藏haproxy版本信息（安全需求）

frontend http-in
#用户侧设置
	bind 0.0.0.0:80
	#监听所有网络接口的80端口。也就是说，HAProxy会接收并处理发送到服务器80端口的所有HTTP请求。
	mode http
	#应用层7层模式，可检测url
	log global
	#日志设置遵循全局设置
	option httplog
	#指定日志格式为网站格式
	option httpclose
	#关闭一部分网站空闲连接
     		acl html url_reg  -i  \.html$
		#定义一个名为html的ACL，匹配URL中包含.html的请求，其中-i忽略大小写
     		use_backend html-server if  html
		#使用html-server后端，前提是 符合上面定义的html
     		default_backend html-server
		#未被区分的客户端请求就用 html-server

backend html-server
#定义一个名为html-server的后端
	mode http
	#应用层7层模式
	balance roundrobin
	#均衡选项，指定为轮询
	option httpchk GET /index.html
	#使用GET请求检查/index.html路径的健康状态
	cookie SERVERID insert indirect nocache
	#将服务器的id号插入到回复给用户的信息中，通过这种方式进行会话保持，使用间接方式并且不缓存
	server html-A web1:80 weight 1 cookie 3 check inter 2000 rise 2 fall 5
	server html-B web2:80 weight 1 cookie 4 check inter 2000 rise 2 fall 5
	#设定服务器群组
	#html-A：后端服务器web1:80，权重为1，SERVERID cookie值为3，健康检查间隔2000毫秒，连续2次成功认为健康，连续5次失败认为不健康。

2.4、测试结果

使用命令行界面查看（windows客户端缓存问题，会导致看到的是同一个网站）

 使用本机浏览器访问设置的统计监测页面

2.5、补充

动静分离配置内容示例如下，与上方不同的在匹配部分，该处已添加注释

[root@localhost ~]# cat /etc/haproxy/haproxy.cfg 
global
	log 127.0.0.1 local3 info
	maxconn 4096
        uid nobody
#       uid 99
        gid nobody
#       gid 99
	daemon
	nbproc 1
	pidfile /run/haproxy.pid
defaults
	log		   global
	mode	   http
	maxconn 2048
	retries 	3
	option	redispatch
	contimeout	5000
	clitimeout	    50000
	srvtimeout	    50000
#timeout connect 5000
#timeout client 50000
#timeout server 50000
    option abortonclose

    stats uri /admin?stats
    stats realm Private lands
    stats auth admin:password
    stats hide-version

frontend http-in
	bind 0.0.0.0:80
	mode http
	log global
	option httplog
	option httpclose
 	acl php url_reg  -i  \.php$			 
	#acl <ACL名字>  <类型>  <大小写>  <规则>
	acl html url_reg  -i  \.html$		  	 
	#use_backend  <服务器组>  if  <ACL名字>
	    use_backend php-server if  php
	    use_backend html-server if  html
	    default_backend html-server		 
	    #默认使用的服务器组
	

	backend php-server
		mode http
		balance roundrobin
		option httpchk GET /index.php
		cookie SERVERID insert indirect nocache
		server php-A 192.168.122.30:80 weight 1 cookie 1 check inter 2000 rise 2 fall 5
		server php-B 192.168.122.40:80 weight 1 cookie 2 check inter 2000 rise 2 fall 5
	
	backend html-server
		mode http
		balance roundrobin
		option httpchk GET /index.html
		cookie SERVERID insert indirect nocache
		server html-A 192.168.122.10:80 weight 1 cookie 3 check inter 2000 rise 2 fall 5
		server html-B 192.168.122.20:80 weight 1 cookie 4 check inter 2000 rise 2 fall 5

3、nginx负载均衡部署

优势：nginx复制用户请求，在后端服务器出现问题时。nginx会再复制一份请求发给另一台后端服务器。 lvs则在这种情况，只能用户重新发请求。

劣势：流量会经过nginx，nginx成为瓶颈。

nginx7层负载均衡语法示例：

location  / {

}
location ~ \.html${
proxy_pass ...
}
location ~ \.php${
proxy_pass ...
}
location ~ \.(jpg|png|css|js)${
proxy_pass ...
}

3.1、基础环境

3.2、nginx部署

此处接“HAProxy基础部署”实验环境继续操作，卸载haproxy即可继续使用

[root@localhost ~]# systemctl stop haproxy
[root@localhost ~]# yum remove -y haproxy
[root@localhost ~]# yum install -y nginx
[root@localhost ~]# vim /etc/nginx/nginx.conf
    #    文件配置如下
[root@localhost ~]# systemctl restart nginx

http {
。。。。。。
upstream html{
    #定义html群组
        server web1:80;
        server web2:80;
             }

    server {

location / {
                proxy_pass http://html;
                #    本身不处理将请求推送至html群组
           }
。。。。。。。
}
}

 所属位置图解如下

3.3、访问测试

3.4、补充

动静分离示例如下，通过新增服务器群组和匹配规则完成动静分离

    upstream html {
        server web1:80;
        server web2:80;
        }
    upstream php {
        server web3:80;
        server web4:80;
        }
server {
        location / {
         proxy_pass http://html;
        }
        location ~ \.php$ {
         proxy_pass http://php;
        }
}

4、概念补充（面试题）

LVS、Nginx、HAproxy有什么区别？工作中你怎么选择？

LVS：是基于四层的转发

HAproxy：是基于四层和七层的转发，是专业的代理服务器

Nginx：是WEB服务器，缓存服务器，又是反向代理服务器，可以做七层的转发

区别：LVS由于是基于四层的转发所以只能做端口的转发、而基于URL的、基于目录的这种转发LVS就做不了工作选择：HAproxy和Nginx由于可以做七层的转发，所以URL和目录的转发都可以做，在很大并发量的 时候我们就要选择LVS，像中小型公司的话并发量没那么大，选择HAproxy或者Nginx足已，由于 HAproxy由是专业的代理服务器，配置简单，所以中小型企业推荐使用HAproxy

简述 HAProxy 常见的负载均衡策略？

HAProxy 负载均衡策略非常多，常见的有如下 8 种：

roundrobin：表示简单的轮询。

static-rr：表示根据权重。

leastconn：表示最少连接者先处理。

source：表示根据请求的源 IP，类似 Nginx 的 IP_hash 机制。

ri：表示根据请求的 URI。

rl_param：表示根据 HTTP 请求头来锁定每一次 HTTP 请求。

rdp-cookie(name)：表示根据据 cookie(name)来锁定并哈希每一次 TCP 请求。

网站公告

今日签到

点亮在社区的每一天
去签到

热门文章

最新发布