良好架构设计中的可靠性:高可用、容错、灾难恢复
良好架构设计支柱
云计算良好架构设计有五大支柱,分别是:安全性,可靠性,性能效率,成本优化和卓越操作。其中可靠性是指系统从基础设施或者服务故障当中实现恢复、以动态方式获取计算资源以满足需求,以及缓解配置错误或者暂时性网络问题等干扰因素的能力。一般设计原则为:测试恢复规程,自动故障恢复,横向扩展以提升总体系统可用性、多钟小资源代替大资源,不再依靠猜测确定容量需求,自动管理变更。
在我们讨论可靠性和阅读相关文献的时候,我们经常会注意到以下几个概念,它们是高可用(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)来做到流量的分发,同时我们还要有另一个负载均衡待命,当主负载均衡失效的时候,待命的负载均衡能够马上启用并分发流量。
高可用的核心概念就是要有冗余待命的实例同时存在,并且在检测到主实例失效时马上投入工作。否则就只能是一个冗余的系统而不是真正的高可用系统。汽车的备用轮胎是一个高可用的设计,当然它还没有达到刚才我们描述的真正的高可用。
容错(Fault Tolerant)
容错系统跟高可用的概念非常接近,但是它又更近一步,那就是要做到零宕机(Zero Downtime)。高可用能做到5个9(99.999%)的系统可用时间,还不能做到100%,那是因为只是高可用的设计还不能保证零宕机时间。如果我们做到了零宕机,那么这个系统就是一个容错系统。像下面的飞机发动机,设计有4个发动机,如果只是一两个发动机出现故障,并不会完全影响飞机的飞行。现在我们可以理解前面汽车设计的备用轮胎不能算是容错系统,因为换轮胎是需要一定时间,在这段时间汽车不能正常驾驶。
灾难恢复(Disaster Recovery)
有了高可用的设计以及容错系统,我们还需要灾难恢复设计吗?我们已经达到了5个9或者更好的可用性,还搭建灾备实例干嘛呢?灾难恢复是在高可用和容错的基础上又走得更远,那就是在重大灾难发生时,比如飓风、地震或其它引起基础设施的破坏而不能提供服务时,灾难恢复会有一个完整的计划来恢复关键业务系统,而不至于让我们的业务处于瘫痪且不能恢复的状态。比如我们将重要业务放到云服务提供商的一个区域或城市(Region),当这个区域出现上述重大灾难造成我们的客户数据丢失而不能恢复时,这对我们的business会造成毁灭性的打击。那么将重要数据同时备份到其它的一个区域或城市,这样的设计就属于灾难恢复的范畴。
下图中的例子描述的是飞机出现重大事故时飞行员跳伞的情况,这里飞行员就是我们的business。留得青山在,不怕没柴烧。有了他,我们可以继续开创新的天地。
总之,灾难恢复就是确保我们的business不被中断。当然灾难的恢复需要时间,我们也可能会丢失一部分数据。这里有两个重要指标就是RTO(Recover Time Objective),RPO(Recover Point Objective),分别代表恢复需要的时间以及恢复到灾难之前的什么时间的数据。它们都是越短越好。RPO跟我们的备份周期相关,如果数据做到了实时同步,这个时间就会很短;如果每天备份一次且没有增量备份,那么我们就可能丢失一天的内容。要做到RTO时间尽可能短,也是需要通过一些自动化的脚本或基础设施自动创建来实现。这里其实是IaC(Infrastructure As Code)的一些概念。阿里云提供的ROS或者开源的Terraform可以用来做基础设施的脚本管理和维护。
大家可以参考参考资料6来看灾难恢复计划的具体模板。
总结
理解了上面高可用、容错、灾难恢复的几个概念,我们在看资料和交流的时候才知道我们想表达的是哪一个概念,才不至于互相混用这几个词语引起对方的误解。
参考资料
- AWS Well-Architected Framework
- Disaster Recovery vs. High Availability vs. Fault Tolerance: What are the Differences?
- High Availability vs. Fault Tolerance vs. Disaster Recovery
- The Difference Between Fault Tolerance, High Availability, & Disaster Recovery
- Building Fault-Tolerant Applications on AWS
- Disaster Recovery Plan Template
低调大师中文资讯倾力打造互联网数据资讯、行业资源、电子商务、移动互联网、网络营销平台。
持续更新报道IT业界、互联网、市场资讯、驱动更新,是最及时权威的产业资讯及硬件资讯报道平台。
转载内容版权归作者及来源网站所有,本站原创内容转载请注明来源。
- 上一篇
《OdooERP系统部署架构指南》试读:第一章 Odoo架构概述
文/开源智造联合创始人老杨 本文来自《OdooERP系统部署架构指南》的试读章节。书籍尚未出版,请勿转载。欢迎您反馈阅读意见。 从web浏览器到PostgreSQL,多层与其他层交互以处理数据 单服务器架构 易于理解和部署,这是最常见的情况。一个实例或多个实例 多服务器架构 更难部署和维护,需要更高水平的系统管理员技能,建议用于容错和复杂的业务场景。 混合架构 在这两种配置之间,根据需要,有很多部署场景。永远记住,您需要一个生产系统和一个测试系统。 测试系统不必与生产系统相同,但必须使用相同的体系结构(OS,…)。 不要在测试和生产环境之间使用共享服务器,在测试时避免性能瓶颈,允许在不停止生产的情况下重新启动测试。 温馨提示 保持简单好用记住,你需要一个稳定和可维护的系统。你添加的每一层都需要知识。不要添加不必要的层。这个例子可以是一个复制的数据库,没有人能够监视它,或者很容易从故障中恢复,在失败的情况下导致比在单个服务器场景中更大的停机时间。 文章编辑:开源智造(OSCG) - 源自欧洲,业界领先的免费开源ERP Odoo金牌服务机构
- 下一篇
Jvm体系结构
JVM : java虚拟机,模拟计算机达到计算所具有的计算功能。 包括几个组成部分: 1 指令集 -计算机识别的机器语言的命令集合 2 计算单元 -识别并控制指令执行的功能模块 3 寻址方式 - 地址的信息,运行规则等。 4 寄存器定义-包括多种寄存器的定义、数量和使用方式。 5 存储单元-能够存储操作数和保存操作结构的单元。比如: 内存和磁盘。 以上五个部分和代码关联最密切的是指令集部分。 指令集: 在cpu中用来计算和控制计算机系统的一套指令的集合。是体现CPU性能的一个重要指标。 主流的有精简指令集和复杂指令集。通常使用的是复杂指令集。 指令集和汇编语言的关系? 指令集是可以直接被机器识别的机器码,以二进制格式存在于计算机中。 汇编语言是可以被人识别的语言,在顺序和逻辑上与机器指令一一对应。 也即是说,汇编语言是为了让人记住机器指令的助记符。 指令集和CPU架构有关系? 汇编语言是对寄存器和段的直接操作的命令,而寄存器和段是架构的一部分, 所以不同的架构对应相应的指令集。由于操作系 统是管理计算机的真正入口, 如果操作系统不支持某种芯片的指令集,程序无法执行。cpu要适用于相应的...
相关文章
文章评论
共有0条评论来说两句吧...
文章二维码
点击排行
推荐阅读
最新文章
- Docker使用Oracle官方镜像安装(12C,18C,19C)
- CentOS7编译安装Gcc9.2.0,解决mysql等软件编译问题
- CentOS8安装Docker,最新的服务器搭配容器使用
- 设置Eclipse缩进为4个空格,增强代码规范
- Red5直播服务器,属于Java语言的直播服务器
- SpringBoot2整合Redis,开启缓存,提高访问速度
- SpringBoot2配置默认Tomcat设置,开启更多高级功能
- SpringBoot2更换Tomcat为Jetty,小型站点的福音
- CentOS7,8上快速安装Gitea,搭建Git服务器
- CentOS7安装Docker,走上虚拟化容器引擎之路