可靠性
本故事的目标是提供可靠性的最佳实践来管理您的云环境。尽管它引用了AWS和Cloud,但这些原则同样适用于其他云提供商和内部环境。
本故事将分为三个部分。
- 第1部分-描述各种术语和最佳实践的概念
- 第2部分-云的弹性和可用性设计模式
- 第3部分—实现特定SLA的高可用性体系结构
本故事集中在第1部分
AWS于2015年发布了良好架构框架,并描述了良好架构原则的五大支柱,即
- 可靠性
- 安全
- 性能效率
- 成本优化
- 卓越运营
本故事侧重于可靠性支柱,提供了可靠性的要点,以供快速参考,并基于AWS白皮书和Microsoft云设计模式。
可靠性集中在以下方面
- 能够从基础设施/服务故障中恢复
- 快速获取需求资源以满足需求的能力
- 缓解配置和瞬态网络问题
可用性
可用性=正常运行时间/总时间,表示为正常运行时间的百分比,例如99.99%。简而言之,以9的数量表示,例如99.999表示为五个9
作为快速参考,99%的可用性意味着每年3天15小时的停机时间,99.999%意味着每年5分钟的停机时间。要计算特定值,请使用链接https://uptime.is/99.9或结账https://en.wikipedia.org/wiki/High_availability
如果存在相关性,则可用性是系统可用性和从属系统可用性的乘积。例如,如果系统A具有99.9%,系统B具有99.9%,并且A依赖于B,则聚合系统的可用性为99.9*99.9=99.8%
如果系统存在冗余,则正常运行时间计算为100减去组件故障率的乘积。例如,如果可用性为99.9,则故障率为0.1%,由此产生的可用性为100减去(0.1*0.1)=999.99%,这表明由于冗余而增加了可用性。
有时可能不知道依赖项的可用性。如果我们知道平均故障间隔时间(MTBF)和平均恢复时间(MTTR),那么可用性=MTBF/(MTBF+MTTR)。例如,MTBF为150天,MTTR为1小时,则可用性为99.97%。使用链接对此进行更深入的了解。
实现最高级别的可用性意味着部署/容量添加/回滚等方面的系统成本和复杂性更高。即使没有使用所有功能,也通常会为已建立的系统支付更高可用性的费用。必须考虑成本,小心制定正确的可用性目标。
弹性网络设计-关键指南
- 在设计VPC和子网CIDR块时,考虑到所有对等可能性、本地重叠、Lambdas/ELB所需的IP数量等,考虑到未来的情况。
- 为VPN连接和直连使用冗余
- 利用AWS Shield、WAF、Route 53等AWS服务防止DDoS攻击
高可用性应用程序设计
为“五个9”或更高的HA进行设计需要极端的考虑。许多服务提供商和软件库的设计并不是为了提供这样的数量,这需要添加多个服务提供商,避免单点故障和定制开发,以及操作的极端自动化和彻底的故障测试。
应用程序必须处理的一些中断类型如下
- 硬件故障
- 部署失败
- 增加的负载
- 意外的输入错误
- 凭据/证书过期
- 依赖项失败
- 电力等基础设施故障
所有这些故障都必须得到处理,恢复必须自动化。这意味着实现HA的工作不是微不足道的,并导致了可用性目标需求的细化。这可能是因为某些交易必须比其他交易更可靠,高峰时间、地理差异等。。
了解可用性需求
整个系统不需要设计为高可用性。例如,实时操作可能比批处理更重要,非高峰时间可能对可用性有容忍度,数据平面与控制平面,例如,现有EC2的健康状况和操作可能比能够启动新实例更重要,等等。
应用程序可用性设计
通过利用经验证的实践,可以显著提高应用程序可用性。以下原则指导HA的应用程序设计
- 故障隔离区:通过利用AWS可用区和区域,可以将影响降低到特定区域。跨区域利用复制技术可降低数据丢失的风险
- 冗余:避免单点故障是关键。构建对单个断层带故障具有弹性的软件非常重要
- MicroServices:通过使用MicroServices架构构建,我们可以区分不同组件之间的可用性需求。架构中存在权衡,请查看https://martinfowler.com/articles/microservice-trade-offs.html
- 面向恢复的计算:减少恢复影响时间至关重要。恢复程序基于影响而不是发生的问题类型。在某些情况下,如EC2,终止它并让ASG生成一个新实例可能比试图确定确切的问题并修复要好。定期测试恢复路径对于始终评估程序的有效性至关重要
- 分布式系统最佳实践:分布式系统的一些最佳实践包括:节流(速率限制)、在返回故障之前重试一定次数、在特定条件下快速失败、确保处理一次的Idemptency令牌、保持服务始终以恒定工作预热、检查依赖性可用性的断路器、,静态稳定性,以确保系统在故障期间工作更少,而不是使系统进一步过载
可用性的操作注意事项
规划应用程序整个生命周期中使用的自动化或人工工作流非常重要。测试是输送管道的重要组成部分。除了单元和功能测试外,性能测试、持续负载测试和故障注入测试也很重要。操作准备审查,必须评估测试、监控的完整性,并能够根据SLA审计应用程序性能
自动化部署
使用高级部署技术,如
- 金丝雀:通过监控影响,逐步引入更改并向前和向后移动
- 蓝-绿:立即建立一个并行的新堆栈和交换流量(并根据需要快速回滚)
- 功能切换-使用配置选项通过根据需要打开/关闭来部署新功能
- 故障隔离区部署:使用故障隔离区隔离部署并围绕区域故障规划容量
测试
测试必须符合可用性目标。单元测试、负载测试、性能测试、故障测试和外部依赖性测试是必要的。
监控和警报
监控需要有效检测故障并发出警报。您最不希望的是客户在您之前知道问题。监控和警报系统应与主要服务分离,服务中断不应影响监控和警报。
监测分为五个阶段
产生
确定需要监控的服务、定义度量、创建阈值和相应警报。几乎所有AWS服务都提供大量监控和日志信息供用户使用。例如Amazon ECS和AWS Lambda流日志到CloudWatch日志,VPC流日志可以在VPC中的任何或所有ENI上启用
聚合
Amazon CloudWatch和S3是主要的聚合层。一些服务(如ASG和ELB)提供开箱即用的度量,其他流服务(如VPC流日志/CloudTrail事件数据)被转发到CloudWatch日志,这些日志可以被过滤以提取度量。这可以提供触发警报的时间序列数据。
实时处理和报警
警报可以与多个用户的SNS集成,或发送到SQS进行第三方集成,或使用AWS Lambda立即采取行动。
存储和分析
CloudWatch日志可以将日志发送到AmazonS3,EMR可以用于进一步了解数据。Splunk/Logstash等第三方工具可用于聚合/处理/存储和分析。数据保留要求是关键,旧数据可以移动到AmazonGlacier进行长期存档。
作战准备审查(ORR)
ORR对于确保应用程序可用于生产非常重要。团队需要有一份初始ORR检查表,必须重复以验证准确性。一个团队的ORR必须结合从其他应用中吸取的经验教训。
审计
审核监控方面以验证可用性目标至关重要。根本原因分析需要发现发生了什么。AWS提供以下服务以跟踪事件期间的服务状态
- CloudWatch日志:存储日志并检查
- AWS配置:随时查找基础设施的状态
- AWS CloudTrail:查找由谁调用了哪些AWS API
请继续关注第2部分—高可用性体系结构,以实现特定的SLA
工具书类
最新内容
- 12 hours 17 minutes ago
- 12 hours ago
- 3 days 13 hours ago
- 4 days ago
- 5 days 13 hours ago
- 6 days 7 hours ago
- 6 days 7 hours ago
- 6 days 7 hours ago
- 6 days 7 hours ago
- 6 days 7 hours ago