Nginx+Keepalived主备架构总是会有一台服务器处于空闲状态,这样会造成资源的浪费,所以为了能够将两台服务器都利用起来,我们需要借助Nginx+Keepalived双主架构来实现。即是对外两个VIP地址,同时接收请求。
一:Nginx+keepalived主从,双主架构
1:keepalived原理
Keepalived:是Linux下面实现VRRP备份路由的高可靠性运行件。基于Keepalived设计的服务模式能够真正做到主服务器和备份服务器故障时IP瞬间无缝交接。
VRRP协议:全称 Virtual Router Redundancy Protocol。即虚拟路由冗余协议。可以认为它是实现路由器高可用的容错协议,即将N台提供相同功能的路由器组成一个路由器组(RouterGroup),这个组里面有一个master和多个backup,但在外界看来就像一台一样,构成虚拟路由器,拥有一个虚拟IP(vip,也就是路由器所在局域网内其他机器的默认路由),占有这个IP的master实际负责ARP相应和转发IP数据包,组中的其它路由器作为备份的角色处于待命状态。master会发组播消息,当backup在超时时间内收不到vrrp包时就认为master宕掉了,这时就需要根据VRRP的优先级来选举一个backup当master,保证路由器的高可用。
总结:两台主备机器通过keepalived,虚拟一个IP,也就是VIP(Virtual IP)。VIP开始为主机器所有,备份机为空闲状态,同时在两台keepalived之间通信相当于有一条心跳线,通过心跳线互相通信,只要主机器监控(通过脚本)到ngin服务停止,则主机器自己停止keepalived,将VIP交给备份机器处理web请求,直至主机器再次恢复正常,将VIP返还给主机器。
先搭建两个web服务器;
开启同步会话;
生成测试文件;
然后为了区分,把两台web服务器的端口号进行一个修改;
103:
104:
然后保存退出,启动httpd服务;
然后搭建nginx代理服务器;
这里采用源码包的方式进行安装;
安装nginx所需要的依赖环境;
创建程序用户并开始解压;
随后cd到解压目录开始安装;
编译;
命令优化;
然后开始设置nginx的代理功能;
先在http单元中指定各个服务器节点;
然后往下翻;再server单元中指定location;
保存退出;启动nginx;
找一个客户端进行测试;
nginx反向代理的时候会默认采用轮询的方式;
且nginx还会检测后端真实服务器的状态;如果此时关闭了一台web服务器,那么就不会把请求发送给后端服务器了;
但是为了高可用环境的需求,要在两个nginx上安装keepalived;如果生产环境中,有一个代理服务器坏掉了,那么还要手动的设置域名和ip的对应关系,且为了服务器的安全隐私问题着想,要把vip给暴露出去,供用户访问;
再开启会话同步功能;安装keepalived搭建高可用;
打开配置文件,修改一些参数;
101:将图片以下的内容全部删除;
102:将图片以下的内容全部删除;
然后开启keepalived;并检查vip;
客户端使用VIP访问测试;
但是重点来了!!!
如果此时关闭nginx服务而不是关闭主机;那么这个架构就崩溃了,用户就访问不到后端服务器了;可以联想vrrp协议的特性;只是检查IP地址的状态;而不是检测服务的状态;
模拟故障;关闭master的nginx服务;
再用客户端进行访问;
此时也发现VIP不会进行漂移到另外一台nginx服务器上;
那么就可以在keepalived的安装目录下写一个脚本,如果检测不到keepalived的工作状态,那么就会关掉master节点的keepalived服务;backup就会上位;
大概意思就是检查nginx的pid,如果有,那么返回值就会为0;但是如果不为0就可以判断nginx服务出现了故障;那么就停掉keepalived服务,backup节点就会上位,成为master;
并且给这个脚本一个执行权;
然后模拟故障,关掉master的nginx服务,VIP就会漂移到102节点;
如果修好了,那么就可以启动nginx服务,并启动keepalived,就会抢占master的角色,随机VIP就会再漂移回来;
但是如果把该脚本写到计划任务中,不太恰当,因为计划任务的时间最小单位为1分钟,1分钟后才会检测出nginx节点失效,所以把该脚本放到keepalived的安装目录下,让keepalived进行调用;
首先打开其配置文件;
先指定脚本的位置;及执行间隔时间;
再最后一个括号的上方再写;注意书写位置;
然后在另一个节点上也用同样的方式书写以脚本的方式进行健康检查的策略;
用SSH连接加密传输的方式到另一个节点的目录下;
然后再修改第二个节点的主配置文件;102
然后重启两个keepalived服务;
然后再模拟故障,只关闭nginx 服务,而不是关闭服务器本身;
此时就发现,引用了脚本的方式进行健康检查,就会关闭掉出问题的keepalived;
然后修好了,就可以把nginx和keepalived服务启动起来;
还是会继续抢占master的身份;
VRRP协议中的Master和Backup设备来回抢占的情况,这种情况会对网络稳定性和性能产生以下影响:
1. 网络振荡
-
频繁切换:当Master和Backup设备因为优先级变化、网络状态不稳定或其他原因频繁进行主备切换时,会导致网络中出现短暂的振荡。这种振荡可能表现为网络延迟增加、丢包率上升等现象。
-
路由协议收敛延迟:Master设备在恢复后如果立即抢占,可能会因为其上行链路的路由协议还未完全收敛,导致流量中断或路由错误。
2. 用户体验下降
-
服务中断:主备设备的频繁切换可能导致用户设备在短时间内无法正确获取到网关地址,从而引发服务中断。
-
性能下降:网络振荡会直接影响网络的整体性能,导致用户在使用网络时感受到明显的卡顿或延迟。
3. 设备和资源消耗
-
设备负载增加:频繁的主备切换会增加设备的处理负担,可能导致设备过热、能耗增加等问题。
-
资源浪费:不必要的抢占和切换会浪费网络资源,包括带宽、CPU和内存等。
缓解措施
为了缓解VRRP协议中来回抢占带来的影响,可以采取以下措施:
-
配置抢占延时:在Master设备恢复后,配置一定的抢占延时,以便等待其上行链路的路由协议完成收敛,减少流量中断的风险。
-
优化网络环境:提高网络的稳定性和可靠性,减少因网络堵塞等原因导致的Backup设备无法及时收到Master设备报文的情况。
-
合理设置优先级:根据设备的性能和稳定性合理设置VRRP优先级,避免因为优先级设置不当导致的频繁切换。
-
使用BFD等检测技术:通过BFD(Bidirectional Forwarding Detection,双向转发检测)等技术实时监测Master设备的状态,以便在Master设备故障时能够更快地切换到Backup设备。