高可用原则

本文为翻译的文章,作者GrantCovell, StevenBeard, StephaneLeroy, ScottRich ,原文:
https://jazz.net/wiki/bin/view/Deployment/HighAvailability

可用性是服务器或者进程正常运转时间的一种衡量方法,同时也是某个组件发生故障后,系统恢复所需时间的衡量方法。
高可用是系统的设计与实现,以达到系统和数据几乎在所有时间都具备可用性的目的,每天24个小时,每周7天,一年365天。高可用不等于100%可用。要达到100%可用,对于现在大部分的情况来说都不是一种节省成本的做法。相反,它是一个目标。
高可用是系统设计方法以及相关联的服务实现,以确保在一个约定的期间内达到预定的运营效率级别。

可用性–“9的个数”
可用性通常采用系统工作时间的百分比来表示 。“9的个数”的概念与可用性要求越来越高有关,9的个数越多,表示可用性和工作时间越多。比如,“5个9”等于99.999%的工作时间。
下面的表格展示了年/月/周所允许的宕机时间百分比,基于系统一年需要24x7x365(6)的运行环境。在这里插入图片描述

衡量可用性
可用性用时间的百分比来衡量。如果一个环境对于一般的业务操作在99%的时间可用,那个这个环境的可用性就是99%。这个可用性的百分比转化为系统在每天/月/年的宕机时间的平均值。
为了真实的衡量环境的可用性,我们必须首先区分计划内的中断和非计划性的中断。 当运营人员把系统下线以进行备份、升级、维护和其它安排好的事件时,就属于计划内的中断。非计划性中断的出现是由于不可预见的事件发生,比如断电,硬件或者软件故障,用户操作员出错,安全漏洞,或者自然灾害等。

平均恢复时间(MTTR)
MTTR是指一个环境从所有的或者特定的故障恢复所需要的平均时间。
有时候一个组织只聚焦在主数据范围内的高可用性,而把灾难恢复的场景排除掉。

欢迎关注微信公众号,获取更多信息。
在这里插入图片描述

  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
AWS高可用弹性架构是一种设计原则,旨在确保应用程序在发生故障或中断时仍能保持可靠的运行。高可用性是指系统连续工作时间的指标,弹性则是指系统对资源需求变化的适应能力。 AWS高可用弹性架构的关键要素包括: 1. 高可用性:采用多个可用区域(Availability Zones)部署应用程序,每个可用区域都是独立的数据中心,具备冗余的网络、电力和硬件设施。这样,在一个可用区域发生故障时,系统可以切换到另一个可用区域,保证应用的可用性。 2. 自动化扩展:利用自动化服务(如Auto Scaling),根据应用程序的负载情况动态调整所需的计算资源。当负载增加时,自动增加服务器数量,负载降低时则自动缩减服务器数量。这种弹性的资源调整能够确保应用程序具有稳定的性能,并避免资源浪费。 3. 数据备份与恢复:通过使用Amazon S3等存储服务,将数据备份至多个可用区域,并实施定期的备份策略。这样可以确保数据的安全性和完整性,并能够快速恢复应用程序的运行。 4. 负载均衡:利用Amazon Elastic Load Balancer等负载均衡服务,将流量分配至多个服务器上,实现负载的平衡,提高系统的吞吐量和可靠性。当某个服务器发生故障时,负载均衡服务会自动将新的请求转发至其他正常运行的服务器上。 5. 服务监控与告警:使用CloudWatch等监控服务,定期监控应用程序的运行状态和性能指标,并设置相应的告警机制。一旦检测到异常,系统会自动发送告警通知,使管理员能够及时采取措施,确保系统正常运行。 总之,AWS高可用弹性架构是一种依托于AWS云服务的设计原则,通过利用多个可用区域、自动化服务、数据备份与恢复、负载均衡以及监控与告警等技术手段,实现应用程序在故障或中断时的持续运行和可靠性。

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值