Nginx专栏—12.Nginx高可用架构

简介: 1.Keepalived高可用基本概述

1.Keepalived高可用基本概述

1.什么是高可用一般是指2台机器启动着相同的业务系统,当有一台机器down机了, 另外一台服务器能快速的接管, 对于访问的用户是无感知的。

2.高可用通常使用什么软件?通常服务高可用我们选择使用keepalived软件实现

3.keepalived是如何实现高可用的?keepalived软件是基于VRRP协议实现的。VRRP虚拟路由冗余协议,主要用于解决单点故障问题

4.那VRRP是如何诞生的,VRRP的原理又是什么?比如公司的网络是通过网关转换进行上网的,那如果该路由器故障了,网关无法转发报文了,此时所有人都将无法上网,这么时候怎么办呢?

通常做法是给路由增加一台备节点,但问题来了?如果我们的主网关master故障了,用户是需要手动修改网关指向Backup,如果用户过多修改起来会非常的麻烦。第一个问题: 假设用户将指向都修改到Backup路由器,那么Master路由器如果修复好了又该怎么办?第二个问题: 假设Master网关故障,我们将Backup网关配置为Master网关IP行不行?其实上不行,因为PC第一次是通过ARP广播寻找到Master网关的Mac地址与IP地址,PC则会将Master网关的对应IP与MAC地址写入ARP缓存表中,那么PC第二次则会直接读取ARP缓存表中的MAC地址与IP地址,然后进行数据包的转发。此时PC转发的数据包还是会教给Master。(除非PC的ARP缓存表过期,在次发起ARP广播的时候才能正确获取Bakcup的Mac地址与对应的IP地址。)

如何才能做到出现故障自动转移,此时VRRP就应运而生,我们的VRRP其实是通过软件或硬件的形式在Master和Backup外面增加一个虚拟MAC地址(简称VMAC)与虚拟IP地址(简称VIP)。那么在这种情况下,PC请求VIP的时候,无论是Master处理还是Backup处理,PC仅会在ARP缓存表中记录VMAC与VIP的对应关系。

5.高可用keepalived使用场景通常业务系统需要保证7x24小时不DOWN机, 比如公司内部OA系统,每天公司人员都需要使用,则不允许Down机。作为业务系统来说随时都可用

6.高可用核心概念总结1.如何确定谁是主节点谁是备节点。(投票选举?优先级?)2.如果Master故障,Backup自动接管,那Master恢复后会夺权吗?(抢占式、非抢占式)3.如果两台服务器都认为自己是Master会出现什么问题?(脑裂)

2.Keepalived高可用安装配置

1.实践环境,配置实现虚IP转移

image.png

2.在master与backup上分别安装keepalived

[root@lb01 ~]# yum install keepalived -y
[root@lb02 ~]# yum install keepalived -y

3.配置节点1,Master

[root@lb01 ~]# cat /etc/keepalived/keepalived.conf
global_defs {     
    router_id lb01   
}
vrrp_instance VI_1 {
    state MASTER
    interface eth0
    virtual_router_id 50
    priority 150
    advert_int 1
    authentication {
        auth_type PASS
        auth_pass 1111
}
    virtual_ipaddress {
        10.0.0.3
    }
}

4.配置节点2,Backup

[root@lb02 ~]# cat /etc/keepalived/keepalived.conf
global_defs {
    router_id lb02
}
vrrp_instance VI_1 {
    state BACKUP
    interface eth0
    virtual_router_id 50
    priority 100
    advert_int 1
    authentication {
        auth_type PASS
        auth_pass 1111
    }
    virtual_ipaddress {
        10.0.0.3
    }
}

5.对比keepalivedmasterbackup配置的区别

image.png

6.启动Master与Backup节点的keepalived

#lb01
[root@lb01 ~]# systemctl enable keepalived
[root@lb01 ~]# systemctl start keepalived

#lb02
[root@lb02 ~]# systemctl enable keepalived
[root@lb02 ~]# systemctl start keepalived

3.Keepalived高可用地址漂移

检查keepalived的虚拟VIP地址能否漂移

1.在Master上进行如下操作

# Master存在vip地址
[root@lb01 ~]# ip addr |grep 10.0.0.3
    inet 10.0.0.3/24 scope global secondary eth0
# 停止Master上的keepalived, 检测vip已不存在
[root@lb01 ~]# systemctl stop keepalived
[root@lb01 ~]# ip addr |grep 10.0.0.3

2.在Backup上进行如下操作

#发现地址已经漂移至Backup端

[root@lb02 ~]# ip addr|grep 10.0.0.3
    inet 10.0.0.3/24 scope global secondary eth0

3.此时重新启动Master上的Keepalived,会发现VIP被强行抢占

[root@lb01 ~]# systemctl start keepalived
[root@lb01 ~]# ip addr |grep 10.0.0.3
    inet 10.0.0.3/24 scope global secondary eth0

4.通过windows查看arp缓存表,验证地址漂移后是否会自动更新MAC地址。

4.Keepalived高可用非抢占式

通常master服务故障后backup会变成master,但是当master服务又恢复的时候,master会抢占VIP,这样就会发生两次切换对业务繁忙的网站来说并不是太友好,此时我们可以配置keepalived为非抢占式(前提两台主机的硬件配置信息一致)

配置非抢占式步骤如下1、两个节点的state都必须配置为BACKUP(官方建议)2、两个节点都在vrrp_instance中添加nopreempt参数3、其中一个节点的优先级必须要高于另外一个节点的优先级。两台服务器都角色状态启用nopreempt后,必须修改角色状态统一为BACKUP,唯一的区分就是优先级。

#Master
    vrrp_instance VI_1 {
        state BACKUP
        priority 150
        nopreempt
    }
#Backup
    vrrp_instance VI_1 {
        state BACKUP
        priority 100
        nopreempt
    }

5.keepalived高可用故障脑裂

由于某些原因,导致两台keepalived高可用服务器在指定时间内,无法检测到对方的心跳消息,各自取得资源及服务的所有权,而此时的两台高可用服务器又都还活着。1.服务器网线松动等网络故障2.服务器硬件故障发生损坏现象而崩溃3.主备都开启firewalld防火墙

1.在备上编写检测脚本, 测试如果能ping通主并且备节点还有VIP的话则认为产生了列脑

[root@lb02 ~]# cat check_split_brain.sh
#!/bin/sh
vip=10.0.0.3
master_ip=10.0.0.5
while true;do
    ping -c 2 -W 3 $master_ip &>/dev/null
    if [ $? -eq 0 -a `ip add|grep "$vip"|wc -l` -eq 1 ];then
        echo "ha is split brain.warning."
    else
        echo "ha is ok"
    fi
sleep 5
done

2.如果Nginx宕机, 会导致用户请求失败, 但Keepalived并不会进行切换, 所以需要编写一个脚本检测Nginx的存活状态, 如果不存活则kill nginx和keepalived

[root@lb01 ~]# mkdir /server/scripts
[root@lb01 ~]# vim /server/scripts/check_web.sh
#!/bin/sh
nginxpid=$(ps -C nginx --no-header|wc -l)
#1.判断Nginx是否存活,如果不存活则尝试启动Nginx
if [ $nginxpid -eq 0 ];then
    systemctl start nginx
    sleep 3
    #2.等待3秒后再次获取一次Nginx状态
    nginxpid=$(ps -C nginx --no-header|wc -l) 
    #3.再次进行判断, 如Nginx还不存活则停止Keepalived,让地址进行漂移,并退出脚本  
    if [ $nginxpid -eq 0 ];then
        systemctl stop keepalived
   fi
fi
#给脚本增加执行权限
[root@lb01 ~]# chmod +x /server/scripts/check_web.sh

3.在lb01主机的keepalived配置文件中调用此脚本

[root@lb01 ~]# cat /etc/keepalived/keepalived.conf
global_defs {
         router_id LVS_01
}
#1.每5秒执行一次脚本, 脚本执行内容不能超过5秒,否则会被中断再次重新运行脚本
vrrp_script check_web {
   script "/server/scripts/check_web.sh"
   interval 5
}
vrrp_instance VI_1 {
    nopreempt
    state MASTER
    interface eth0
    virtual_router_id 50
    priority 150
    advert_int 1
    authentication {
        auth_type PASS
        auth_pass 1111
    }
    virtual_ipaddress {
        10.0.0.3
    }
    #2.调用并运行该脚本
    track_script {
        check_web
    }
}


相关文章
|
2月前
|
存储 SQL 关系型数据库
Mysql高可用架构方案
本文阐述了Mysql高可用架构方案,介绍了 主从模式,MHA模式,MMM模式,MGR模式 方案的实现方式,没有哪个方案是完美的,开发人员在选择何种方案应用到项目中也没有标准答案,合适的才是最好的。
249 3
Mysql高可用架构方案
|
5月前
|
存储 Cloud Native 关系型数据库
PolarDB 高可用架构设计与实践
【8月更文第27天】 在现代互联网应用中,数据库作为核心的数据存储层,其稳定性和可靠性尤为重要。阿里云的 PolarDB 作为一款云原生的关系型数据库服务,提供了高可用、高性能和自动化的特性,适用于各种规模的应用。本文将详细介绍 PolarDB 的高可用架构设计,并探讨其实现数据安全性和业务连续性的关键技术。
141 0
|
5月前
|
Java 应用服务中间件 Shell
Nginx+Keepalived+Tomcat 实现Web高可用集群
Nginx+Keepalived+Tomcat 实现Web高可用集群
165 0
|
2月前
|
Kubernetes 关系型数据库 MySQL
Kubernetes入门:搭建高可用微服务架构
【10月更文挑战第25天】在快速发展的云计算时代,微服务架构因其灵活性和可扩展性备受青睐。本文通过一个案例分析,展示了如何使用Kubernetes将传统Java Web应用迁移到Kubernetes平台并改造成微服务架构。通过定义Kubernetes服务、创建MySQL的Deployment/RC、改造Web应用以及部署Web应用,最终实现了高可用的微服务架构。Kubernetes不仅提供了服务发现和负载均衡的能力,还通过各种资源管理工具,提升了系统的可扩展性和容错性。
162 3
|
2月前
|
负载均衡 应用服务中间件 nginx
基于Nginx和Consul构建自动发现的Docker服务架构——非常之详细
通过使用Nginx和Consul构建自动发现的Docker服务架构,可以显著提高服务的可用性、扩展性和管理效率。Consul实现了服务的自动注册与发现,而Nginx则通过动态配置实现了高效的反向代理与负载均衡。这种架构非常适合需要高可用性和弹性扩展的分布式系统。
51 4
|
2月前
|
负载均衡 应用服务中间件 nginx
基于Nginx和Consul构建自动发现的Docker服务架构——非常之详细
通过使用Nginx和Consul构建自动发现的Docker服务架构,可以显著提高服务的可用性、扩展性和管理效率。Consul实现了服务的自动注册与发现,而Nginx则通过动态配置实现了高效的反向代理与负载均衡。这种架构非常适合需要高可用性和弹性扩展的分布式系统。
69 3
|
3月前
|
Unix 应用服务中间件 Linux
Nginx入门--初识Nginx的架构
Nginx入门--初识Nginx的架构
67 0
|
5月前
|
运维 监控 关系型数据库
【一文搞懂PGSQL】7. PostgreSQL + repmgr + witness 高可用架构
该文档介绍了如何构建基于PostgreSQL的高可用架构,利用repmgr进行集群管理和故障转移,并引入witness节点增强网络故障检测能力。repmgr是一款轻量级的开源工具,支持一键部署、自动故障转移及分布式节点管理。文档详细描述了环境搭建步骤,包括配置postgresql参数、安装与配置repmgr、注册集群节点以及配置witness节点等。此外,还提供了故障手动与自动切换的方法及常用命令,确保集群稳定运行。
|
5月前
|
JSON API 网络架构
Django 后端架构开发:DRF 高可用API设计与核心源码剖析
Django 后端架构开发:DRF 高可用API设计与核心源码剖析
119 1
|
5月前
|
运维 负载均衡 监控
Nginx加Keepalived实现高可用
使用Nginx和Keepalived来实现高可用性的方案,对于确保关键服务的稳定性和可靠性来说是非常有效的。此配置涉及多个步骤,包括各个服务的安装、设置及测试,目标是在主服务器故障时能无缝切换,以确保服务的持续可用。正确的配置和充分的测试是实现高可用性的保证,这也要求管理员对这些工具和它们背后的原理有深入的了解。
109 1