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设备。
综上所述,频繁的抢占不见得是一件好事,如何关闭它呢?
如何参考是否开启抢占功能呢?如果两个服务器性能相当,谁当主,谁当从,都可以,但是如果有一台服务器的性能比另外一台性能好,那么就可以设置成master的身份,并且把优先级设置的大一点,且不关闭抢占模式;
打开配置文件;

设置两个参数,因为关闭抢占模式仅在backup节点设置的,把两个节点的身份都设置成backup,因为选举master是依靠优先级的;所以不影响;

保存退出,然后重启keepalived服务;再去验证就可以了;
nginx双主结构
这种方案,使用两个vip地址,前端使用2台机器,互为主备,同时有两台机器工作,当其中一台机器出现故障,两台机器的请求转移到一台机器负担,非常适合于当前架构环境。

Nginx双主模式通常指的是两台Nginx服务器相互协作,提供高可用性的负载均衡服务。在这种配置中,两台Nginx服务器都处于活跃状态,并且各自绑定一个公共IP地址(VIP),以便在其中一台服务器出现故障时,另一台服务器能够接管流量,确保服务的连续性和可用性。
性能特点
Nginx本身是一个高性能的Web服务器和反向代理服务器,它以异步事件驱动的方式运行,能够处理大量并发连接,具有低内存消耗和高吞吐量的特点。在双主模式下,Nginx的这些性能优势得以保持,而且通过负载均衡,可以更有效地利用硬件资源,提高整体的服务能力。
高可用性
双主模式通过Keepalived等高可用性软件实现心跳检测和虚拟IP地址的动态管理,确保在任何一台Nginx服务器出现故障时,另一台服务器能够迅速接管服务,实现无缝切换。这种配置可以显著提高系统的可靠性和稳定性,减少单点故障的风险。
经济性
相比于传统的主从模式,双主模式不存在备用服务器资源的浪费问题。在主从模式中,备用服务器在正常情况下不承担流量,而在双主模式中,两台服务器都积极参与服务,提高了资源的利用率。
那么就需要再添加一个实例;

将描黑的部分再粘贴一份;


进入102修改;
由于上面那个实例是backup,那么这个就要设置成master;且优先级调高一点;

重启两个服务进行测试;
此时101就承载了第一个VIP;192.168.10.100

102就承载了第二个VIP;192.168.10.200

再用客户端使用两个VIP进行测试;

此时这个架构中任意一个节点出问题,都有对应的backup等待接管;
模拟故障,关闭101的nginx;此时101承载的VIP就漂移到了102上;


一旦修好了,开启两个服务,还是会抢占回来,因为在做双主架构的时候,把原先的配置还原了;
