最近云很热闹，先是AWS，后是google云故障，这也是在提醒我们掌握主动，学好灾备知识，尽早对业务做好灾备计划是非常重要的；没有一个云提供商能保证永远不出问题，灾难发生时，合理运用DR计划，在第一时间恢复业务，将灾难对于业务造成的影响降到最低是我们的目标。

前面我们介绍了关于Disaster Recovery (DR)的内容包括：

1 Disaster Recovery (DR) 灾难恢复的定义和内容概述
2 恢复时间目标（RTO） 和 恢复点目标（RPO）
3 与灾难恢复（DR）相关的AWS功能和服务-1
4 与灾难恢复（DR）相关的AWS功能和服务-2
5 与灾难恢复（DR）相关的AWS功能和服务-3
6 AWS灾难恢复方案示例-（1）备份和恢复
7 AWS灾难恢复方案示例-（2）在AWS使用Pilot Light快速恢复
8 AWS灾难恢复方案示例-（3）热备
9 AWS灾难恢复方案示例-（4）多站点（双活）

今天我们继续Disaster Recovery (DR)的内容，介绍DR系列的最后一篇–改进您的灾难恢复（DR）计划—建立完善的灾难恢复计划时应遵循的重要步骤，直接开始：

–1、DR计划的测试和确认–

DR计划需要测试，这非常重要，没有经过测试并确认的计划不能确保可用。我之前遇到过很多案例都是客户建立了DR计划，在灾难发生时才发现DR计划不可用，造成了重大的损失。

所以要定期进行测试确认确保是有效可行的。在AWS上可以经常且非常容易的进行DR计划测试，这是在AWS上部署的关键优势，因为可以随时生成资源，测试完了随时删除。

可以使用AWS CloudFormation在AWS上部署环境，使用模板来描述AWS资源以及创建完整环境所需的任何关联依赖项或运行时参数。

组织应该定期设置 “Game day”，对灾难恢复环境进行故障转移测试，可以很容易且具有成本效益的在AWS中创建Game day所需的场景，而不需要触及生产环境。Game day验证DR计划的可行性。

确保DR计划已落实到了文档，Game day主要依照DR计划文档执行。如Game day要模拟的灾难类别要提前规划，识别并形成文档，像业务站点断电/断网等等，这些是风险识别的内容。

经过“Game day”确认的DR计划是灾难事件发生时的执行方针，计划需要很清晰的落实在书面上，灾难恢复时依据文档执行或确认。

–2、DR环境的监控和警报–

需要定期检查并进行充分监控，以便在DR环境出现服务器故障、连接问题和应用程序问题的影响时及时收到提醒。 

Amazon CloudWatch提供对AWS资源监控的指标，也可以以应用程序为中心甚至以业务为中心的自定义指标。可以根据任何指标的已定义阈值设置警报，并且在需要时，可以设置Amazon SNS以在出现意外行为时发送警报。

当然，可以在AWS上使用任何监控解决方案，还可以继续使用公司用于监控实例指标以及客户操作系统统计信息和应用程序运行状况的任何现有监控和警报工具。

要提前把监控和警报搞起来，不要等到灾难恢复时才发现DR环境不可用，会造成非常长的恢复时间（RTO）。

–3、备份和备份验证–

切换到DR环境后，应继续进行定期备份，定期验证备份的有效性。

AWS可以灵活地执行频繁、低成本的的DR测试，而无需DR的资源“始终开启”。

–4、设置用户访问权限–

可以使用AWS Identity and Access Management（IAM）保护对DR环境中资源的访问。使用IAM，您可以创建基于角色和基于用户的安全策略，以隔离用户职责并限制用户对DR环境中指定资源和任务的访问。

–5、限制系统访问–

还可以为Amazon EC2资源创建角色，以便只有分配给指定角色的用户才能对DR环境执行已定义的操作，例如访问Amazon S3存储桶或重新指向弹性IP地址。

–6、多使用自动化–

可以使用配置管理/部署的软件自动将应用程序部署到基于AWS的服务器和本地服务器上。可以轻松地跨两个环境处理应用程序和配置更改管理。

AWS CloudFormation与多种工具结合使用，以自动方式配置基础架构服务。还有服务如 AWS OpsWorks或AWS Elastic Beanstalk，总体目标是尽可能自动化部署工作。

使用Auto Scaling确保实例数量适当，在DR情况下，当用户数量开始增多时，可以动态扩展以满足这种增加的需求；当用户减少时可以自动缩减到最低级别的数量。

以上，DR系列的内容就全部结束了，

后续此公众号还会发布更多精彩的AWS的知识点，快快关注吧!

在北京时间，2019年6月2日2:00AM到 13:48 PM之间，在CN-NORTH-1（中国北京区域）区域有多处光纤在昨晚的道路作业中被挖断，导致该区域的第一个可用区中EC2实例不能访问同时不能在整个CN-NORTH-1区域中新建EC2实例。

这是AWS中国区域的重大事故，也是在提醒我们，掌握主动，学好灾备知识，尽早对业务做好灾备计划是非常重要的；没有一个云提供商能保证永远不出问题，灾难发生时，合理运用DR计划，在第一时间恢复业务，将灾难对于业务造成的影响降到最低是我们的目标。

前面我们介绍了关于Disaster Recovery (DR)的内容包括：

1 Disaster Recovery (DR) 灾难恢复的定义和内容概述
2 恢复时间目标（RTO） 和 恢复点目标（RPO）
3 与灾难恢复（DR）相关的AWS功能和服务-1
4 与灾难恢复（DR）相关的AWS功能和服务-2
5 与灾难恢复（DR）相关的AWS功能和服务-3
6 AWS灾难恢复方案示例-（1）备份和恢复
7 AWS灾难恢复方案示例-（2）在AWS使用Pilot Light快速恢复

今天我们继续Disaster Recovery (DR)的内容，开始介绍四种DR策略的第三种策略–AWS热备策略。

–策略3、AWS热备方案–

热备解决方案是我们前面介绍过的Pilot Light策略的扩展（组件和准备工作）。

术语“热备”用于描述DR策略：创建一套您的业务的完整功能的运行环境的缩小版本始终在云中运行，当灾难发生时快速切换。

由于在热备策略中会创建一套您的业务的服务始终在云中运行，在灾难发生时因此会进一步缩短了恢复时间。

通过识别您的业务核心系统，您可以在AWS上完全复制这些系统并使其始终在云中运行，这些服务器开始可以在最小规模的Amazon EC2实例上以尽可能小的大小运行，它不需要有我们业务正常需要的承载能力，但是要具备全部的功能，比如它可以用于非生产工作，例如测试，质量保证和内部使用。

在DR期间，我们之前创建的最小化环境要能快速扩展以处理生产负载。在AWS中，可以通过向负载均衡器添加更多实例或者调整实例的大小完成快速扩展。

准备阶段

下图显示了热备解决方案的准备阶段，其中传统数据中心环境和AWS环境并行运行。

（使用传统数据中心和AWS只是举例，当然也适用于AWS多区域，多云环境）

准备的关键步骤：

1. 设置Amazon EC2实例以复制或镜像数据。
2. 创建和维护AMI。
3. 使用最少的Amazon EC2实例和AWS基础架构运行应用程序。
4. 根据您的生产环境修补和更新软件和配置文件。

恢复阶段

在生产环境发生故障的情况下，热备环境将按比例扩大以用于生产负载，并且将更改DNS记录以将所有流量路由到AWS。

恢复的关键步骤：

1. 增加负载均衡器的Amazon EC2的数量（水平扩展）
2. 根据业务的需要在较大的Amazon EC2实例类型上启动应用程序（垂直扩展）。
3. 手动更改DNS记录，或使用Amazon Route 53自动运行状况检查，以便将所有流量路由到AWS环境。
4. 考虑使用Auto Scaling来调整大小或适应增加的负载。
5. 添加弹性或扩展数据库。

以上AWS灾难恢复方案示例-（3）AWS热备策略的内容就结束了，我们下次再见！

(待续)

前面我们介绍了关于Disaster Recovery (DR)的内容包括：

1. Disaster Recovery (DR) 灾难恢复的定义和内容概述
2. 恢复时间目标（RTO） 和 恢复点目标（RPO）
3. 与灾难恢复（DR）相关的AWS功能和服务-1
4. 与灾难恢复（DR）相关的AWS功能和服务-2
5. 与灾难恢复（DR）相关的AWS功能和服务-3
6. AWS灾难恢复方案示例-（1）备份和恢复

今天我们继续Disaster Recovery (DR)的内容，开始介绍四种DR策略的第二种策略–在AWS使用Pilot Light快速恢复。

–策略2、使用Pilot Light快速恢复–

术语“Pilot Light”通常用于描述DR场景，表示您的业务有个最小化版本的环境始终在云中运行。Pilot Light的想法是来自燃气加热器的类比，在燃气加热器中，始终打开的小火焰可以快速点燃整个炉子以加热房屋。

Pilot Light使您可以通过在AWS中配置和运行您的系统中最关键的核心组件，这样在灾难恢复时，您可以立刻围绕在AWS中的Pilot Light维护的关键核心组件快速扩展配置成完整的生产环境。

Pilot Light的基础设施构成通常包括您的数据库服务器，这些服务器会将数据复制到Amazon EC2或Amazon RDS（将您的核心数据自动同步至AWS维护的Pilot Light核心组件）。根据业务系统的不同，数据库外部可能还有其他需要复制到AWS的关键数据。这是系统的关键核心（Pilot Light），AWS中的所有其他基础设施部件（炉子的其余部分）可以快速配置以快速扩展快速恢复整个完整系统。

以上，简单的概括下，在AWS建立您业务的最小化环境，然后将您的一些核心数据（比如数据库等）实时同步至AWS的RDS或者其他服务，当灾难发生时，通过AWS提供的服务快速扩展AWS维持的Pilot Light最小化环境至您的生成环境规模，从而快速恢复您的业务。

那么要快速扩展AWS维持的Pilot Light最小化环境的核心组件恢复关键业务服务，除了同步核心数据，对于快速扩展至生产环境的规模，还需要做些什么呢？

对于计算资源，通常会将一些预配置的服务器做成Amazon Machine Images（AMI），这些服务器随时可以启动。在开始灾难恢复时，来自这些AMI的实例会快速启动，并在Pilot Light周围的部署中使用其预定义角色（例如，Web或App Server）。

对于从网络资源，您有两个主要的选项可以准备：

• 使用Elastic IP addresses，它可以预分配并将它们与您的实例相关联。请注意，对于基于MAC地址的软件许可，您可以使用弹性网络接口（ENI），其具有MAC地址，也可以预先分配以配置许可证。您可以将这些与实例关联，就像使用弹性IP地址一样。
  
• 使用Elastic Load Balancing（ELB）将流量分配到多个实例。

最后，要把前面扩展的资源上线至生产环境了，可能您将更新DNS记录以指向您的Amazon EC2实例或使用CNAME指向您的负载均衡器。

对于不经常更新的系统，您可以确保在AWS中提供所有安装包和配置信息，例如，以Amazon EBS快照的形式。这将加速应用程序服务器设置，因为您可以在多个可用区中快速创建多个卷以附加到Amazon EC2实例。然后，您可以通过使用备份和恢复方法进行相应的安装配置。

Pilot Light策略比上次介绍过的“备份和恢复”策略提供更快的恢复时间，因为系统的核心部分已经在运行并且持续更新。 AWS能够自动化基础架构资源的配置，这可以节省时间并帮助防止人为操作错误。但是，仍需要执行一些安装和配置任务才能完全恢复应用程序。

准备阶段

下图显示了准备阶段，您需要将定期更改的数据复制到Pilot Light，这个小核心将在恢复阶段启动整个环境。您不经常更新的数据（如操作系统和应用程序）可以定期更新并存储为AMI。

准备阶段的关键步骤：

1. 设置Amazon EC2实例或者RDS以复制或镜像核心数据。
2. 确保您拥有AWS中提供的所有支持自定义软件包。
3. 创建和维护需要快速恢复的关键服务器的AMI。
4. 定期运行这些服务器，测试它们，并应用任何软件更新和配置更改。
5. 考虑自动配置AWS资源。

恢复阶段

要恢复Pilot Light周围剩下的基础环境，您可以在适当的实例类型上在几分钟内从AMI启动系统。对于动态数据服务器，您可以根据实际业务需求情况调整它们的大小或相应地增加容量。

水平扩展通常是增加系统容量的最具成本效益和可扩展性的方法。例如，您可以在高峰时间添加更多Web服务器。但是，您也可以选择较大的Amazon EC2实例类型，从而垂直扩展应用程序（如关系数据库）。

从网络角度来看，任何所需的DNS更新都可以同时完成。

另外灾难恢复后，应确保尽快恢复冗余。继续定期备份系统，并考虑数据层的额外冗余。

下图显示了Pilot Light方案的恢复阶段。

恢复的关键步骤：

1. 从自定义AMI启动应用程序Amazon EC2实例。
2. 调整现有数据库/数据存储实例的大小以处理增加的流量。
3. 添加额外数据库/ 数据库实例确保DR站点在数据层的弹性的能力;如果您使用Amazon RDS，请启用多可用区提高可用性及持久性。
4. 将DNS更改为指向Amazon EC2服务器。
5. 安装和配置任何非基于AMI的系统，最好是以自动方式。

以上AWS灾难恢复方案示例-（2）在AWS使用Pilot Light快速恢复的内容就结束了，我们下次再见！

前面我们介绍了关于Disaster Recovery (DR)的内容包括：

1. Disaster Recovery (DR) 灾难恢复的定义和内容概述
2. 恢复时间目标（RTO） 和 恢复点目标（RPO）
3. 与灾难恢复（DR）相关的AWS功能和服务-1
4. 与灾难恢复（DR）相关的AWS功能和服务-2
5. 与灾难恢复（DR）相关的AWS功能和服务-3

今天我们继续Disaster Recovery (DR)的内容，开始介绍四种DR策略，并结合之前介绍的AWS组件/服务，与传统数据中心构建DR的方案示例。

将按照DR事件发生后恢复业务的快慢排序（由慢到快）：

AWS能够经济高效地运行每种DR策略。重要的是要注意，这些只是可能方法的示例，并且这些方法可以变化和组合使用。如果您的应用程序已在AWS上运行，则可以使用多个区域，并且仍然适用相同的DR策略。

四种DR策略并没有好坏之分，具体采用哪种策略，需要根据业务实际情况，以及根据灾难造成的经济损失定义的RTO、RPO来规划选择或者组合使用。

–策略1、备份和恢复–

备份和恢复，顾名思义就是定期将业务数据进行备份，当DR事件时将备份快速恢复，从而快速恢复业务。备份和恢复策略是四种DR策略中恢复业务耗时最长的。

以下是一些AWS可用于备份和恢复的一些服务/方案：

• Amazon S3是备份数据的理想选择，可以快速执行还原。通常通过网络与Amazon S3之间传输数据，因此可以从任何位置访问。Amazon Glacier和Amazon S3可以结合使用，以生成分层备份解决方案。
  
• AWS Storage Gateway支持将本地数据卷的快照透明地复制到Amazon S3进行备份。您可以随后从这些快照创建本地卷或Amazon EBS卷。
  
• AWS Storage-cached volumes 允许您将主数据存储在Amazon S3中，但将经常访问的数据保持在本地以进行低延迟访问。与AWS Storage Gateway一样，您可以对数据卷进行快照以提供高度持久的备份。如果是DR，您可以将缓存卷还原到运行存储缓存网关的第二个站点或Amazon EC2。
  
• 您可以使用AWS Storage Gateway的gateway-VTL配置作为现有备份管理软件的备份目标。这可以用作传统磁带备份的替代品。
  
• 对于目前已经在AWS上运行的业务，同样可以备份到Amazon S3。 像Amazon EBS卷的快照，Amazon RDS数据库和Amazon Redshift数据仓库都可以存储在Amazon S3中。或者，您可以将文件直接复制到Amazon S3，也可以选择创建备份文件并将其复制到Amazon S3。

上图为来自传统数据中心至AWS S3的数据备份方式。

当然了，备份您的数据只是工作的一半，如果灾难发生，您需要快速和可靠的恢复数据。您应确认你的备份系统已经配置好以及在安全的保护您的数据，更重要的一点，您应该测试数据恢复过程。

上图前面介绍过，在DR恢复阶段，通过已经创建好的符合您自己业务的AMI（系统和应用），快速创建EC2，并将存储在S3的数据恢复至EC2的数据卷快速恢复业务。

备份和恢复关键步骤：

1.选择适当的工具或方法将数据备份到AWS。

2.确保您对此数据具有适当的保留策略。

3.确保为此数据采取适当的安全措施，包括加密和访问策略。

4.定期测试此数据的恢复和系统的恢复过程。

*计算*

*Amazon Elastic Compute Cloud (Amazon EC2) ，*在云中可提供可调大小的计算容量。几分钟就可完成启动实例。具备快速创建计算资源的能力对于DR非常重要。

*Amazon Machine Images (AMIs) ，*合理配置好适应于自己业务的AMIs，包括操作系统、应用程序等等，可作为DR过程的一部分，对于快速恢复业务至关重要。

*可用区，*前面提到过，每个区域都有多个可用区供使用。将自己的业务分部在不同可用区，这样可避免或者减轻单可用区故障造成的影响。

*网络*

当您处理灾难时，经常需要切换至灾备站点，这就可能必须修改网络设置。 AWS提供了多种服务和功能，使您可以管理和修改网络设置。

*Amazon Route 53，*是一种高度可用且可扩展的域名系统（DNS）Web服务。支持多种策略在DR时可自动、手动切换业务只灾备站点，快速恢复业务。具体的功能和配置方式不是本文的重点，就不过多展开了。

*弹性IP地址（EIP），*可解绑和重新绑定EIP至其他实例为DR提供更灵活的方式。

*Elastic Load Balancing，*可自动在多个Amazon EC2实例之间分配传入的应用程序流量，结合使多可用区使用，DR好帮手。

*Amazon VPC，*允许您在AWS中创建您自己私有的、完全隔离的网络，可以VPC启动AWS资源，并可以完全控制虚拟网络环境。也可以从公司的数据中心和VPC之间创建VPN连接，并使用AWS作为公司数据中心的扩展，建立DR计划，当灾难发生时，可利用此快速恢复公司数据中心的业务。

*Amazon Direct Connect，*可以轻松设置从您的位置到AWS的专用网络连接。在许多情况下，这可以降低您的网络成本，增加带宽吞吐量，并提供比基于Internet的连接稳定的工作体验。这个的选择就要看实际的业务需要了。

*数据库*

*Amazon Relational Database Service（Amazon RDS），*使您可以轻松地在云中设置，操作和扩展关系数据库。您可以在DR的准备阶段使用Amazon RDS将关键数据保存在已运行的数据库中，也可以在恢复阶段使用Amazon RDS来运行生产数据库。另外RDS还支持多可用区部署和只读副本，利用这些特性可进一步增加数据库的可用性。

*Amazon DynamoDB，*是一种完全托管的 NoSQL 数据库服务，Amazon DynamoDB 可自动将表的数据和流量分布到足够多的服务器中，以处理客户指定的请求容量和数据存储量，同时保持一致的性能和高效的访问。同样的，Amazon DynamoDB可自动复制数据到多个可用区，从而提供内置的高可用性和数据持久性。

您还可以在DR准备阶段将其用于将数据复制到其他区域的DynamoDB或Amazon S3。在DR的恢复阶段，只需单击一次或API调用，您就可以在几分钟内无缝扩展。

*Amazon Redshift，*是一种快速，完全托管的PB级数据仓库服务。您可以在DR准备阶段使用Amazon Redshift对数据仓库进行快照，以便在同一区域内持久存储在Amazon S3中或复制到另一个区域。在DR的恢复阶段，您可以快速将数据仓库还原到同一区域或其他AWS区域内。

*部署编排工具*

Amazon EC2可使用部署自动化和启动后软件安装/配置过程和工具，这在DR恢复阶段非常有用，可以自动且快速的创建您所需的EC2。

*AWS CloudFormation，*为开发人员和系统管理员提供了一种简单的方法来创建相关AWS资源的集合，并以有序和可预测的方式进行配置。您可以根据需要为环境创建模板并部署相关的资源集合（称为堆栈）。

*AWS Elastic Beanstalk，*是一种易于使用的服务，用于部署和扩展使用Java，.NET，PHP，Node.js，Python，Ruby和Docker开发的Web应用程序和服务。您可以部署应用程序代码，而AWS Elastic Beanstalk将为您的应用程序配置操作环境。

*AWS OpsWorks，*是一种应用程序管理服务，可以轻松部署和运行各种类型和规模的应用程序。 AWS OpsWorks具有自动主机替换功能，因此在实例发生故障时，它将自动替换。您可以在的DR准备阶段使用AWS OpsWorks来模拟您的环境，并且可以在DR恢复阶段将其与AWS CloudFormation结合使用。您可以从支持定义的RTO的存储配置中快速配置新堆栈。

以上，介绍了一些灾难恢复（DR）相关的AWS功能和服务，有效的利用这些功能和特性，能够最大化的支持DR方案的完整性和灵活性，且在灾难发生后的DR恢复阶段，能够快速恢复您的业务，将灾难的影响降到最低。

(待续)