AWS Disaster recovery 白皮书翻译总结
参考原文来自AWS官网： docs.aws.amazon.com/zh_cn/white…
声明： 本文的目标主要用于考试复习，所以删除了部分内容且加了部分自己的理解，总结和说明。如有介意请看官方原文。
开篇
灾难恢复包括为灾难做准备和从灾难恢复的两个过程。本文概述了AWS的各种负载在灾难恢复时的最佳实践，并提供了不同的方法来降低风险并满足该工作负载的RTO（Recovery Time Objective） 和 RPO (Recovery Point Objective）。
Disaster recovery
AWS将灾难分为了3种：
- 自然灾害 ： 类似地震，洪水等
- 技术上导致的系统问题 ： 类似停电，和网路阻断等
- 人为行为 ： 类似恶意删除，错误的修改配置等
Disaster recovery 和 High availability的区别
可用性和灾难恢复都依赖于一些相同的最佳实践，例如故障监控、部署到多个位置和自动故障转移。但是，可用性侧重于工作负载的组件，而灾难恢复侧重于整个工作负载的副本保存。灾难恢复的效率主要通过恢复的时间来定义。
我们也必须在灾难恢复计划中考虑工作负载的可用性，因为它会影响我们方法的选取。在单一zone里的单个Amazon EC2 实例上运行的工作负载不具有高可用性。如果本地爆发洪水影响了该机器，我们需要将故障转移到另一个可用区以满足 DR目标。所以，通常我们都会将服务部署到多个zone，甚至更保险起见我们可以选择部署到多个region。
而数据处理的方式在可用性和灾难恢复之间也有所不同。比如通常我们为了获取高可用性会将数据复制到其他设备（request分流，为了加快读数据速度，备份读模块到多个设备）的存储解决方案。可是如果当主存储设备上的一个或多个文件被删除或损坏，这些破坏性更改会立刻复制到辅助存储设备。在这种情况下，尽管可用性很高，但我们没法恢复灾难前正确的数据。所以在disaster recovrey中，我们通常采用point-in-time backup的备份方法。可以将数据回复到某一个具体的时间点。这就是两者的不同。
Business Continuity Plan (BCP) -业务连续性计划 (BCP)
这块就不具体深谈了，简单来说就是我们做灾难恢复计划时要结合实际业务情况来定，不能影响用户的可用性，也不能过于激进。附上原文连接： docs.aws.amazon.com/zh_cn/white…
Recovery objectives (RTO and RPO)
这块是考试的重点，借用官方图片进行说明。
- RTO : 灾难发生后多久我们能恢复正常工作
- RPO : 容忍灾难丢失多长时间的数据
基于云服务的灾难恢复
灾难恢复的策略随着技术的革新也在不断地进步。传统本地的灾难处理策略都是着重于物理磁盘的备份与转移。当服务转接到AWS云服务后，我们的机构需要重新评定之前灾难恢复策略的商业影响，风险，花费的可行性。总体来说aws的灾难恢复相比于传统的具有以下优势：
- 恢复速度迅速且复杂性降低。
- 有简单和重复的测试方案允许我们更简洁和重复性的进行测试。
- 管理操作负担更小
- 减少错误发生的记录，且提高了恢复速率 AWS使我们的物理备份数据中心的固定资本支出变成了根据环境变化可变性支出，这可以显着降低成本。
对于许多组织而言，本地服务要面对工作负载中断时对系统的影响，且需要及时将将备份或复制的数据恢复到辅助数据中心。当在AWS上部署工作负载时，他们可以实施架构良好的工作负载，并依靠 AWS全球云基础设施的设计来帮助减轻此类中断的影响。请参阅 AWS Well-Architected Framework - Reliability Pillar 白皮书，了解有关在云中设计和操作可靠、安全、高效且经济高效的工作负载的架构最佳实践的更多信息。
如果您的工作负载在AWS上，您无需担心数据中心的电源、空调、灭火等问题。您可以访问多个故障隔离的可用区（每个可用区由一个或多个离散数据中心组成）。
单个AWS Rigion
对于基于一个物理数据中心中断或丢失的灾难事件，在单个AWS区域内的多个可用区（zone）中实施高可用工作负载有助于缓解自然和技术灾难，并降低人为威胁的风险，例如错误或未经授权的活动可能会导致数据丢失。每个 AWS 区域由多个可用区组成，每个可用区都与其他区域中的故障隔离。每个可用区又由多个物理数据中心组成。为了更好地隔离有影响的问题并实现高可用性，您可以跨同一区域中的多个专区对工作负载进行分区。可用区旨在实现物理冗余并提供弹性，即使在断电、互联网停机、洪水和其他自然灾害的情况下，也能提供不间断的性能。
通过跨单个AWS 区域中的多个可用区进行部署，您的工作负载可以得到更好的保护，防止单个（甚至多个）数据中心出现故障。为了为您的单区域部署提供额外保障，您可以将数据和配置（包括基础设施定义）备份到另一个区域。此策略将灾难恢复计划的范围缩小到仅包括数据备份和恢复。与下一节中描述的其他多区域选项相比，通过备份到另一个 AWS 区域来利用多区域弹性既简单又便宜。例如，通过备份到 Amazon Simple Storage Service (Amazon S3)，您可以立即检索数据。但是，如果您的部分数据的 DR 策略对检索时间（从几分钟到几小时）有更宽松的要求，那么使用 A mazon S3 Glacier 或 Amazon S3 Glacier Deep Archive将显着降低备份和恢复策略的成本。
某些工作负载可能具有监管数据驻留要求。如果这适用于当前只有一个AWS 区域的本地工作负载，那么除了如上所述设计多可用区工作负载以实现高可用性之外，您还可以将该区域内的可用区用作离散位置，这会很有帮助用于解决适用于您在该区域内的工作负载的数据驻留要求。以下部分中描述的 DR 策略使用多个AWS 区域，但也可以使用可用区而不是区域来实施。
多个AWS Regions
对于包含丢失多个相距很远的数据中心的风险的灾难事件，您应该考虑灾难恢复选项，以减轻影响 AWS 内整个区域的自然和技术灾难。下个章节描述的所有策略都可以实现为多区域架构，以防止此类灾难。
四种灾难恢复的策略
AWS提供了4zhogn
- Backup and restore
简单来说就是先在多个regions去备份数据，然后利用AWS CloudFormation 或 AWS 云开发工具包 (CDK) 等服务使用基础设施即代码 (IaC) 进行部署。否则在恢复区域中恢复工作负载可能会很复杂，这将导致恢复时间增加并可能超过设置的RTO，另外还需备份代码和配置，例如创建 Amazon EC2 实例的 Amazon 系统映像 (AMI)。您可以使用 AWS CodePipeline 自动重新部署应用程序代码和配置。
- EBS snapshot
- Dynamodb backup
- Amazon RDS snapshot
- Amazon Aurora DB snapshot
- Amazon EFS backup (when using AWS Backup)
- Amazon Redshift snapshot
- Aws storage gateway
- Amazon Fsx for windows file server and amazon fsx for lustre
- s3 使用Amazon S3 Cross-Region Replication (CRR)
- S3 object versioninng
-
AWS cloudFormation
提供基础设施即代码 (IaC)，并使您能够定义工作负载中的所有 AWS 资源，以便您能够可靠地部署和重新部署到多个 AWS 账户和 AWS 区域。
-
AMI, instance metadata For ec2 instances
Pilot light
使用Pilog light，您可以将数据从一个区域复制到另一个区域，并预配一份核心工作负载基础设施的副本。支持数据复制和备份所需的资源（例如数据库和对象存储）始终处于开启状态。其他元素，例如应用程序服务器，加载了应用程序代码和配置，但被关闭并且仅在测试期间或在调用灾难恢复故障转移时使用。与备份和恢复方法不同，您的核心基础架构始终可用，您始终可以选择通过打开和扩展应用程序服务器来快速配置完整的生产环境。
pilot light方法通过最大限度地减少活动资源来最大限度地降低灾难恢复的持续成本，并简化灾难发生时的恢复，因为核心基础设施要求都已到位。此恢复选项要求您更改部署方法。您需要对每个区域进行核心基础架构更改，并将工作负载（配置、代码）更改同时部署到每个区域。通过自动化您的部署并使用基础设施即代码 (IaC) 来跨多个账户和区域部署基础设施（将完整基础设施部署到主要区域，并缩减/关闭基础设施部署到DR 区域），可以简化此步骤。建议您为每个区域使用不同的账户以提供最高级别的资源和安全隔离（以防被盗用的凭据也是您的灾难恢复计划的一部分）。
使用这种方法，您还必须减轻数据灾难。连续数据复制可以保护您免受某些类型的灾难，但它可能无法保护您免受数据损坏或破坏，除非您的策略还包括存储数据的版本控制或时间点恢复选项。您可以备份灾难区域中的复制数据以在同一区域中创建时间点备份。
对于pilot ligh，将数据连续复制到DR区域中的实时数据库和数据存储是低RPO的最佳方法（当与前面讨论的时间点备份一起使用时）。AWS 使用以下服务和资源为数据提供连续、跨区域、异步的数据复制：
- Amazon Simple Storage Service (Amazon S3) Replication
- Amazon RDS read replicas
- Amazon Aurora global database
- Amazon DynamoDB global tables
当故障转移到灾难恢复区域运行读/写工作负载时，您必须将 RDS 只读副本提升为主实例。对于 Aurora 以外的数据库实例，该过程需要几分钟才能完成，重启是该过程的一部分。对于 RDS 的跨区域复制 (CRR) 和故障转移，使用 Amazon Aurora 全局数据库提供了多个优势。全局数据库使用专用基础设施，让您的数据库完全可用于为您的应用程序提供服务，并且可以复制到次要区域，典型延迟不到一秒（在 AWS 区域内远远小于 100 毫秒）。借助 Amazon Aurora 全球数据库，如果您的主要区域出现性能下降或中断，您可以在不到 1 分钟的时间内提升其中一个次要区域承担读/写职责，即使在完全区域中断的情况下也是如此。升级可以是自动的，并且没有重新启动。
必须在 DR 区域中部署具有更少或更小的资源的核心工作负载基础架构的缩减版本。使用 AWS CloudFormation，您可以定义您的基础设施并跨 AWS 账户和跨 AWS 区域一致地部署它。 AWS CloudFormation 使用预定义的伪参数来识别部署它的 AWS 账户和 AWS 区域。因此，您可以在 CloudFormation 模板中实施条件逻辑，以仅在 DR 区域中部署缩小版本的基础架构。对于 EC2 实例部署，亚马逊系统映像 (AMI) 提供硬件配置和已安装软件等信息。您可以实施一个 Image Builder 管道来创建您需要的 AMI 并将这些 AMI 复制到您的主要和备份区域。这有助于确保这些黄金 AMI 拥有在发生灾难事件时在新区域重新部署或扩展工作负载所需的一切。 Amazon EC2 实例部署在缩减配置中（实例少于您的主要区域）。您可以使用休眠将 EC2 实例置于停止状态，您无需支付 EC2 费用，只需为使用的存储付费。要启动 EC2 实例，您可以使用 AWS 命令行界面 (CLI) 或 AWS 开发工具包创建脚本。要扩展基础设施以支持生产流量，请参阅热备份部分中的 AWS Auto Scaling。
对于pilot light所有流量最初都会转到主要区域，如果主要区域不再可用，则切换到灾难恢复区域。使用 AWS 服务可以考虑两种流量管理选项。第一个选项是使用 Amazon Route 53。使用 Amazon Route 53，您可以将一个或多个 AWS 区域中的多个 IP 终端节点与一个 Route 53 域名相关联。然后，您可以将流量路由到该域名下的相应端点。 Amazon Route 53 运行状况检查会监控这些终端节点。使用这些运行状况检查，您可以配置 DNS 故障转移以确保将流量发送到运行状况良好的端点。
第二种选择是使用 AWS Global Accelerator。使用 AnyCast IP，您可以将一个或多个 AWS 区域中的多个终端节点与相同的静态 IP 地址相关联。 AWS Global Accelerator 然后将流量路由到与该地址关联的适当终端节点。 Global Accelerator 运行状况检查监控端点。使用这些运行状况检查，AWS Global Accelerator 会自动检查您的应用程序的运行状况并将用户流量仅路由到运行状况良好的应用程序终端节点。 Global Accelerator 为应用程序端点提供更低的延迟，因为它利用广泛的 AWS 边缘网络尽快将流量放在 AWS 网络主干上。 Global Accelerator 还避免了 DNS 系统（如 Route 53）可能出现的缓存问题。
Warm standby
热备份方法涉及确保在另一个区域中有一个按比例缩小但功能齐全的生产环境副本。此方法扩展了pilot light概念并减少了恢复时间，因为您的工作负载始终在另一个区域中。这种方法还允许您更轻松地执行测试或实施连续测试，以增强您对从灾难中恢复的能力的信心。
pilot light和Warm standby之间的区别有时很难理解。两者都包括您的DR区域中的环境如的副本。区别在于，如果不首先采取额外的行动，pilot light无法处理请求，而暖备用可以立即处理流量（以降低的容量级别）。pilot light要求您“打开”服务器，可能会部署额外的（非核心）基础设施，并向上扩展，而warm standby用只需要您向上扩展（一切都已部署并运行）。使用您的 RTO 和 RPO 需求来帮助您在这些方法之间进行选择。
AWS auto scale可以再warm standby中起到有效的作用，一般在warm standby我们只会部署最少的资源，auto scale可以帮助我们在灾难恢复时迅速恢复到正常的生产能力。
Multi-site active/active
作为Multi-site active/active（hot standby）服务于其部署到的所有区域的流量，而Warm standby仅服务来自单个区域的流量，其他区域仅用于灾难恢复。使用多站点主动/主动方法，用户可以在部署工作负载的任何区域访问您的工作负载。这种方法是最复杂和成本最高的灾难恢复方法，但它可以通过正确的技术选择和实施将大多数灾难的恢复时间减少到接近于零（但是数据损坏可能需要依赖备份，这通常会导致非-零恢复点）。hot standby使用主动/被动配置，其中用户仅定向到单个区域并且 DR 区域不占用流量。大多数客户发现，如果他们要在第二个区域中建立一个完整的环境，使用主动/主动是有意义的。或者，如果您不想同时使用两个区域来处理用户流量，则Warm Standby 提供了一种更经济且操作复杂度更低的方法。
使用多站点主动/主动，因为工作负载在多个 Region 中运行，因此在这种情况下不存在故障转移这样的事情。在这种情况下，灾难恢复测试将侧重于工作负载对区域丢失的反应：流量是否从故障区域路由出去？其他区域是否可以处理所有流量？还需要对数据灾难进行测试。备份和恢复仍然是必需的，应该定期测试。还应注意，涉及数据损坏、删除或混淆的数据灾难的恢复时间将始终大于零，并且恢复点将始终位于发现灾难之前的某个时间点。如果需要多站点主动/主动（或热备用）方法的额外复杂性和成本来保持接近零的恢复时间，则应采取额外措施来维护安全性并防止人为错误以减轻人为灾难。
对于前面讨论的主动/被动场景（Pilot Light 和 Warm Standby），Amazon Route 53 和 AWS Global Accelerator 均可用于将网络流量路由到活动区域。对于此处的主动/主动策略，这两项服务还支持定义确定哪些用户转到哪个活动区域端点的策略。使用 AWS Global Accelerator，您可以设置流量拨号来控制定向到每个应用程序终端节点的流量百分比。 Amazon Route 53 支持这种百分比方法，以及多种其他可用策略，包括基于地理位置和延迟的策略。 Global Accelerator 自动利用广泛的 AWS 边缘服务器网络，尽快将流量载入 AWS 网络主干，从而降低请求延迟。
使用此策略进行数据复制可实现接近零的 RPO。 AWS 服务（如 Amazon Aurora 全球数据库）使用专用基础设施，让您的数据库完全可用于为您的应用程序提供服务，并且可以复制到一个辅助区域，典型延迟不到一秒。使用主动/被动策略，写入仅发生在主要区域。与 active/active 的区别在于设计如何处理对每个 active Region 的写入。通常将用户读取设计为从Region closet提供给他们，称为read local。对于写入，您有多种选择：
-
写入全局策略将所有写入路由到单个区域。如果该区域出现故障，将提升另一个区域以接受写入。 Aurora 全局数据库非常适合写入全局，因为它支持跨 Region 的只读副本同步，并且您可以在不到 1 分钟的时间内提升其中一个辅助 Region 来承担读/写职责。
-
写入本地策略将写入路由到最近的区域（就像读取一样）。 Amazon DynamoDB 全局表支持这种策略，允许从全局表部署到的每个区域进行读取和写入。 Amazon DynamoDB 全局表使用最后一个写入者赢得并发更新之间的协调。
-
写入分区策略根据分区键（如用户 ID）将写入分配到特定区域，以避免写入冲突。双向配置的 Amazon S3 复制可用于这种情况，目前支持两个区域之间的复制。实施此方法时，请确保在存储桶 A 和 B 上启用副本修改同步，以复制副本元数据更改，例如对象访问控制列表 (ACL)、对象标签或复制对象上的对象锁。您还可以配置是否在活动区域中的存储桶之间复制删除标记。除了复制之外，您的策略还必须包括时间点备份，以防止数据损坏或破坏事件。
AWS CloudFormation 是一个强大的工具，用于在多个 AWS 区域的 AWS 账户之间实施一致部署的基础设施。 AWS CloudFormation StackSets 扩展了此功能，使您能够通过单个操作跨多个账户和区域创建、更新或删除 CloudFormation 堆栈。尽管 AWS CloudFormation 使用 YAML 或 JSON 来定义基础设施即代码，但 AWS 云开发工具包 (CDK) 允许您使用熟悉的编程语言定义基础设施即代码。您的代码将转换为 CloudFormation，然后用于在 AWS 中部署资源。
