本文属于机器翻译版本。若本译文内容与英语原文存在差异，则一律以英文原文为准。

# 多区域基础知识 1：了解需求
<a name="fundamental-1"></a>

如前所述，高可用性和操作连续性是采用多区域架构的常见原因。可用性指标衡量的是工作负载在定义的时间段内可供使用的时间百分比，而操作连续性指标衡量的是大规模（通常是持续时间更长）事件的恢复时间。

[衡量可用性](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/availability.html)几乎是一个持续的过程。*具体的衡量标准可能有所不同，但通常围绕目标可用性指标汇总，通常被称为 9（例如 99.99% 的可用性）。*就可用性目标而言，不能一刀切。您应该在工作负载级别制定可用性目标，将非关键组件与关键组件分开，而不是将单个目标应用于所有工作负载。

为了保证操作的连续性，通常使用以下 point-in-time测量：
+ **恢复时间目标 (RTO)** — RTO 是服务中断和恢复服务之间可接受的最大延迟。此值决定了服务受损的可接受持续时间。
+ **恢复点目标 (RPO)**-RPO 是自上一个数据恢复点以来的最大可接受时间量。这决定了在最新恢复点和服务中断之间哪些数据丢失被认为是可接受的。

与设置可用性目标类似，还应在工作负载级别定义 RTO 和 RPO。更积极的运营连续性或高可用性需要增加投资。也就是说，并非每个应用程序都能要求或需要相同级别的弹性。协调业务和 IT 所有者，根据业务影响评估应用程序的重要程度，然后相应地对它们进行分层，可以帮助提供一个起点。下表提供了分层示例。

下表显示了服务级别协议的弹性分层示例（）SLAs。


| 弹性等级 | 可用性 SLA | 可接受的停机时间/年 | 
| --- | --- | --- | 
| 铂 | 99.99% | 52.60 分钟 | 
| 黄金 | 99.90% | 8.77 小时 | 
| 银 | 99.5% | 1.83 天 | 

下表显示了 RTO 和 RPO 的弹性分层示例。


| 弹性等级 | 最大 RTO | 最大 RPO | 标准 | 成本 | 
| --- | --- | --- | --- | --- | 
| 铂 | 15 分钟 | 5 分钟 | 任务关键型工作负载 | $$$ | 
| 黄金 | 15 分钟 — 6 小时 | 2 小时 | 重要但不是任务关键型工作负载 | $$ | 
| 银 | 6 小时 — 几天 | 24 小时 | 非关键工作负载 | $ | 

在设计具有弹性的工作负载时，请考虑高可用性与操作连续性之间的关系。例如，如果工作负载需要 99.99% 的可用性，则每年的停机时间不能超过 53 分钟。检测故障可能至少需要 5 分钟，操作员还需要 10 分钟才能接触、决定恢复步骤并执行这些步骤。花费 30 到 45 分钟才能从单个问题中恢复过来的情况并不少见。在这种情况下，采用多区域策略来提供一个可以消除相关影响的隔离实例是有益的。这允许您在独立对初始减值进行分类的同时，在有限的时间内进行故障切换，从而继续运营。这需要定义适当的限定恢复时间并确保保持一致。

多区域方法可能适用于具有极高的可用性需求（例如 99.99% 或更高的可用性）或严格的运营连续性要求（只有通过故障转移到另一个区域才能满足）的任务关键型工作负载。但是，这些要求通常仅适用于企业工作负载组合中的一小部分，这些工作负载的恢复时间限制在几分钟或几小时内。除非应用程序需要几分钟或几小时的恢复时间，否则在受影响地区内等待应用程序的区域中断得到补救可能是更好的方法。这种方法通常与较低级别的工作负载保持一致。

在实施多区域架构之前，业务决策者和技术团队应就成本影响进行调整，包括运营和基础设施成本驱动因素。典型的多区域架构可能产生的成本是单区域方法的两倍。尽管业务连续性有几种多区域模式，例如在[热备用、[热待](https://docs.aws.amazon.com/whitepapers/latest/disaster-recovery-workloads-on-aws/disaster-recovery-options-in-the-cloud.html#warm-standby)机](https://docs.aws.amazon.com/whitepapers/latest/disaster-recovery-workloads-on-aws/disaster-recovery-options-in-the-cloud.html#multi-site-activeactive)或[指示灯](https://docs.aws.amazon.com/whitepapers/latest/disaster-recovery-workloads-on-aws/disaster-recovery-options-in-the-cloud.html#pilot-light)下运行，但实现恢复目标风险最低的模式将涉及运行热备用，并且会使您的工作负载成本增加一倍。

## 关键指导
<a name="key-guidance-1"></a>
+ 运营目标（例如 RTO 和 RPO）的可用性和连续性应根据工作负载确定，并与业务和 IT 利益相关者保持一致。
+ 大多数可用性和运营连续性目标都可以在单个区域内实现。对于在单个区域内无法实现的目标，可以考虑多区域，同时要清楚地权衡成本、复杂性和收益。