良好架构设计中的可靠性:高可用、容错、灾难恢复

本文涉及的产品
应用型负载均衡 ALB,每月750个小时 15LCU
网络型负载均衡 NLB,每月750个小时 15LCU
传统型负载均衡 CLB,每月750个小时 15LCU
简介: 良好架构设计支柱云计算良好架构设计有五大支柱,分别是:安全性,可靠性,性能效率,成本优化和卓越操作。其中可靠性是指系统从基础设施或者服务故障当中实现恢复、以动态方式获取计算资源以满足需求,以及缓解配置错误或者暂时性网络问题等干扰因素的能力。

良好架构设计支柱

云计算良好架构设计有五大支柱,分别是:安全性,可靠性,性能效率,成本优化和卓越操作。其中可靠性是指系统从基础设施或者服务故障当中实现恢复、以动态方式获取计算资源以满足需求,以及缓解配置错误或者暂时性网络问题等干扰因素的能力。一般设计原则为:测试恢复规程,自动故障恢复,横向扩展以提升总体系统可用性、多钟小资源代替大资源,不再依靠猜测确定容量需求,自动管理变更。

在我们讨论可靠性和阅读相关文献的时候,我们经常会注意到以下几个概念,它们是高可用(High Availability),容错(Fault Tolerance),灾难恢复(Disaster Recovery)。明白它们的含义和区别有助于我们更好的理解和交流的一致。

高可用(High Availability)

高可用系统是指设计成99.999%的时间可用,即一年允许有5.26分钟的宕机时间,或尽可能接近这个时间。这通常需要设计一个冗余的失效备份系统(failover system),并且能处理跟主系统相同的工作负荷。当主系统出现故障的时候,能自动在很短的时间内切换到备份系统。

在物理基础设施中,要通过设计没有单点故障的系统来达到高可用。也就是说,关键的电力、冷却系统、计算、网络、存储都需要有额外的冗余设计。在阿里云中,我们可以使用多个可用区(Available Zone)来实现物理的高可用,一个可用区包含一个或多个数据中心,一个可用区出现故障,系统能自动使用其它可用区的资源。但要做到自动切换使用其它可用区资源,我们还需要特别设计和注意。

比如我们创建一个高可用的RDS,但可用区我们选择了A,虽然RDS会在可用区A创建2个主备实例,但如果可用区A出现故障,那么这2个实例都不能工作,从而影响RDS的高可用。如果我们选择两个不同的可用区比如A+B,这样就能做到可用区级别的高可用。另外一个例子是,我们设计使用2个ECS来做web server,它们分别放到不同的可用区,这时我们还需要增加一个负载均衡(Load Balancer)来做到流量的分发,同时我们还要有另一个负载均衡待命,当主负载均衡失效的时候,待命的负载均衡能够马上启用并分发流量。

高可用的核心概念就是要有冗余待命的实例同时存在,并且在检测到主实例失效时马上投入工作。否则就只能是一个冗余的系统而不是真正的高可用系统。汽车的备用轮胎是一个高可用的设计,当然它还没有达到刚才我们描述的真正的高可用。

higha

容错(Fault Tolerant)

容错系统跟高可用的概念非常接近,但是它又更近一步,那就是要做到零宕机(Zero Downtime)。高可用能做到5个9(99.999%)的系统可用时间,还不能做到100%,那是因为只是高可用的设计还不能保证零宕机时间。如果我们做到了零宕机,那么这个系统就是一个容错系统。像下面的飞机发动机,设计有4个发动机,如果只是一两个发动机出现故障,并不会完全影响飞机的飞行。现在我们可以理解前面汽车设计的备用轮胎不能算是容错系统,因为换轮胎是需要一定时间,在这段时间汽车不能正常驾驶。

fault

灾难恢复(Disaster Recovery)

有了高可用的设计以及容错系统,我们还需要灾难恢复设计吗?我们已经达到了5个9或者更好的可用性,还搭建灾备实例干嘛呢?灾难恢复是在高可用和容错的基础上又走得更远,那就是在重大灾难发生时,比如飓风、地震或其它引起基础设施的破坏而不能提供服务时,灾难恢复会有一个完整的计划来恢复关键业务系统,而不至于让我们的业务处于瘫痪且不能恢复的状态。比如我们将重要业务放到云服务提供商的一个区域或城市(Region),当这个区域出现上述重大灾难造成我们的客户数据丢失而不能恢复时,这对我们的business会造成毁灭性的打击。那么将重要数据同时备份到其它的一个区域或城市,这样的设计就属于灾难恢复的范畴。

下图中的例子描述的是飞机出现重大事故时飞行员跳伞的情况,这里飞行员就是我们的business。留得青山在,不怕没柴烧。有了他,我们可以继续开创新的天地。

disaster

总之,灾难恢复就是确保我们的business不被中断。当然灾难的恢复需要时间,我们也可能会丢失一部分数据。这里有两个重要指标就是RTO(Recover Time Objective),RPO(Recover Point Objective),分别代表恢复需要的时间以及恢复到灾难之前的什么时间的数据。它们都是越短越好。RPO跟我们的备份周期相关,如果数据做到了实时同步,这个时间就会很短;如果每天备份一次且没有增量备份,那么我们就可能丢失一天的内容。要做到RTO时间尽可能短,也是需要通过一些自动化的脚本或基础设施自动创建来实现。这里其实是IaC(Infrastructure As Code)的一些概念。阿里云提供的ROS或者开源的Terraform可以用来做基础设施的脚本管理和维护。

大家可以参考参考资料6来看灾难恢复计划的具体模板。

总结

理解了上面高可用、容错、灾难恢复的几个概念,我们在看资料和交流的时候才知道我们想表达的是哪一个概念,才不至于互相混用这几个词语引起对方的误解。

参考资料

  1. AWS Well-Architected Framework
  2. Disaster Recovery vs. High Availability vs. Fault Tolerance: What are the Differences?
  3. High Availability vs. Fault Tolerance vs. Disaster Recovery
  4. The Difference Between Fault Tolerance, High Availability, & Disaster Recovery
  5. Building Fault-Tolerant Applications on AWS
  6. Disaster Recovery Plan Template
相关实践学习
小试牛刀,一键部署电商商城
SAE 仅需一键,极速部署一个微服务电商商城,体验 Serverless 带给您的全托管体验,一起来部署吧!
负载均衡入门与产品使用指南
负载均衡(Server Load Balancer)是对多台云服务器进行流量分发的负载均衡服务,可以通过流量分发扩展应用系统对外的服务能力,通过消除单点故障提升应用系统的可用性。 本课程主要介绍负载均衡的相关技术以及阿里云负载均衡产品的使用方法。
目录
打赏
0
0
0
0
3
分享
相关文章
Linux多节点多硬盘部署MinIO:分布式MinIO集群部署指南搭建高可用架构实践
通过以上步骤,已成功基于已有的 MinIO 服务,扩展为一个 MinIO 集群。该集群具有高可用性和容错性,适合生产环境使用。如果有任何问题,请检查日志或参考MinIO 官方文档。作者联系方式vx:2743642415。
435 57
RocketMQ原理—5.高可用+高并发+高性能架构
本文主要从高可用架构、高并发架构、高性能架构三个方面来介绍RocketMQ的原理。
411 21
RocketMQ原理—5.高可用+高并发+高性能架构
Mysql高可用架构方案
本文阐述了Mysql高可用架构方案,介绍了 主从模式,MHA模式,MMM模式,MGR模式 方案的实现方式,没有哪个方案是完美的,开发人员在选择何种方案应用到项目中也没有标准答案,合适的才是最好的。
662 3
Mysql高可用架构方案
控制员工上网软件:高可用架构的构建方法
本文介绍了构建控制员工上网软件的高可用架构的方法,包括负载均衡、数据备份与恢复、故障检测与自动切换等关键机制,以确保企业网络管理系统的稳定运行。通过具体代码示例,展示了如何实现这些机制。
187 63
PolarDB 高可用架构设计与实践
【8月更文第27天】 在现代互联网应用中,数据库作为核心的数据存储层,其稳定性和可靠性尤为重要。阿里云的 PolarDB 作为一款云原生的关系型数据库服务,提供了高可用、高性能和自动化的特性,适用于各种规模的应用。本文将详细介绍 PolarDB 的高可用架构设计,并探讨其实现数据安全性和业务连续性的关键技术。
307 0
云端问道9期实践教学-省心省钱的云上Serverless高可用架构
详细介绍了云上Serverless高可用架构的一键部署流程
105 10
卓越效能,极简运维,Serverless高可用架构
本文介绍了Serverless高可用架构方案,当企业面对日益增长的用户访问量和复杂的业务需求时如何实现更高的灵活性、更低的成本和更强的稳定性。
分布式系统架构4:容错设计模式
这是小卷对分布式系统架构学习的第4篇文章,重点介绍了三种常见的容错设计模式:断路器模式、舱壁隔离模式和重试模式。断路器模式防止服务故障蔓延,舱壁隔离模式通过资源隔离避免全局影响,重试模式提升短期故障下的调用成功率。文章还对比了这些模式的优缺点及适用场景,并解释了服务熔断与服务降级的区别。尽管技术文章阅读量不高,但小卷坚持每日更新以促进个人成长。
159 12
分布式系统架构3:服务容错
分布式系统因其复杂性,故障几乎是必然的。那么如何让系统在不可避免的故障中依然保持稳定?本文详细介绍了分布式架构中7种核心的服务容错策略,包括故障转移、快速失败、安全失败等,以及它们在实际业务场景中的应用。无论是支付场景的快速失败,还是日志采集的安全失败,每种策略都有自己的适用领域和优缺点。此外,文章还为技术面试提供了解题思路,助你在关键时刻脱颖而出。掌握这些策略,不仅能提升系统健壮性,还能让你的技术栈更上一层楼!快来深入学习,走向架构师之路吧!
179 12
如何基于服务网格构建高可用架构
分享如何利用服务网格构建更强更全面的高可用架构

热门文章

最新文章

AI助理

你好,我是AI助理

可以解答问题、推荐解决方案等

登录插画

登录以查看您的控制台资源

管理云资源
状态一览
快捷访问