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
    }
}


相关文章
|
28天前
|
关系型数据库 MySQL Serverless
Serverless高可用架构体验评测
Serverless高可用架构作为企业业务上云不得不考虑的一种低成本高可靠的方案,已经在多领域得到了非常好的验证。希望可以通过阅读文章,让你对Serverless架构得到更深的了解。
12447 21
Serverless高可用架构体验评测
|
3天前
|
数据挖掘 关系型数据库 MySQL
Serverless高可用架构的解决方案体验
Serverless高可用架构的解决方案体验
36 6
|
4天前
|
弹性计算 运维 关系型数据库
Serverless高可用架构解决方案评测
Serverless高可用架构方案提供卓越效能与极简运维体验,支持服务托管、弹性伸缩及按量付费,有效降低成本并优化性能。一键部署快速启动,流程直观,文档详实;但在高级配置与特定场景实践方面指导有限。方案采用双可用区部署确保高可用性,自动故障切换保障服务连续。成本模型按需计费,减轻企业负担。功能上集成监控、日志与负载均衡,简化运维,加速上线。性能方面,秒级弹性伸缩保证资源高效匹配负载。总体而言,此方案竞争力强,特别推荐给初创公司及需灵活应对流量波动的场景。
46 2
|
5天前
|
运维 监控 负载均衡
如何构建高可用的系统基础架构
【8月更文挑战第15天】构建高可用的系统基础架构是一个复杂而系统的工程,需要综合考虑设计原则、关键技术和实践策略等多个方面。通过冗余设计、分布式架构、自动化与智能化等技术的运用,可以显著提升系统的可用性和稳定性。同时,加强运维团队的能力建设和制定完善的高可用性策略也是确保系统高可用性的重要保障。希望本文能为读者在构建高可用系统时提供有益的参考和借鉴。
|
5天前
|
弹性计算 运维 关系型数据库
云上Serverless高可用架构一键部署体验与测评
在数字化转型背景下,Serverless架构因其实现业务敏捷、降低成本及提升服务可靠性而备受青睐。本文以阿里云Serverless应用引擎(SAE)为核心,展示了一种高可用、低成本且易于扩展的解决方案。通过单地域双可用区部署,构建了具备自动伸缩与故障恢复能力的架构。借助阿里云的一键部署功能,大幅简化了搭建流程,实现了快速部署,并通过性能与成本分析验证了其优势。对比传统ECS,SAE在资源利用与运维效率上表现更佳,特别适合平均负载较低的应用场景。
|
13天前
|
关系型数据库 Serverless 分布式数据库
阿里云 Serverless 高可用架构
阿里云的《卓越效能,极简运维,Serverless高可用架构》解决方案提供了全托管服务、自动扩展、高可用性、无缝集成以及内置安全等核心功能。该方案通过免除底层基础设施的管理,允许用户专注于应用程序开发,同时确保应用的稳定运行和资源的有效利用。 **核心功能简介**: - **全托管服务**:用户无需关心底层硬件,由阿里云负责维护和扩展计算资源。 - **自动扩展**:根据业务需求自动调整资源,确保应用在高峰期有足够的计算能力,低谷期则节省成本。 - **高可用性**:多地域和多可用区部署,实现故障自动切换,确保业务连续性。 - **无缝集成**:与阿里云的其他服务(如数据库、消息队列等)深度
|
13天前
|
关系型数据库 Serverless 分布式数据库
Serverless高可用架构
PolarDB在《Serverless高可用架构》中展现了零代码改造、极简易用与自适应弹性的特性,提供按需伸缩与计费服务。相比传统架构,它能自动调整资源满足不同负载需求。阿里云Serverless服务简化了开发者的工作流程,让用户专注业务创新。为了优化用户体验,可通过提供最佳实践、深化文档内容、增强社区支持等方式进一步提升。PolarDB不仅降低了迁移难度,还简化了数据库管理,确保资源高效利用,是企业数字化转型的关键技术支撑。
|
20天前
|
存储 缓存 前端开发
(三)Nginx一网打尽:动静分离、压缩、缓存、黑白名单、跨域、高可用、性能优化...想要的这都有!
早期的业务都是基于单体节点部署,由于前期访问流量不大,因此单体结构也可满足需求,但随着业务增长,流量也越来越大,那么最终单台服务器受到的访问压力也会逐步增高。时间一长,单台服务器性能无法跟上业务增长,就会造成线上频繁宕机的现象发生,最终导致系统瘫痪无法继续处理用户的请求。
|
20天前
|
运维 负载均衡 关系型数据库
Serverless高可用架构体验评测
Serverless高可用架构体验评测
|
21天前
|
运维 监控 关系型数据库
阿里云Serverless高可用架构深度评测:构建稳定高效应用的全面指南
随着云计算技术的迅猛发展,Serverless计算作为一种新兴的、以事件驱动的无服务器架构,正在逐渐改变企业构建、部署和管理应用程序的方式。阿里云,作为全球领先的云服务提供商之一,提供了全面的Serverless解决方案,包括PolarDB MySQL Serverless集群和Serverless应用引擎等产品,致力于帮助用户构建高可用、高弹性、低成本的应用系统。本文将深度评测阿里云的Serverless服务,从产品功能、使用体验、部署常见问题、文档与支持的全面性等维度出发,为开发者和企业提供实用的参考。
63 0