多站点(双活)灾备策略在AWS中的运用

多站点(双活)灾备策略在AWS中的运用

关注公众号：AWS爱好者（iloveaws）
文 | 沉默恶魔（转载请注明出处)
网站：www.iloveaws.cn

如果您觉得本公众号内容尚可，可能的话希望您能关注此公众号，或转发您有兴趣的内容，让更多的人看到，这也是目前我能坚持此公众号的唯一动力，谢谢支持，鞠躬！

最近云很热闹，先是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）热备

今天我们继续Disaster Recovery (DR)的内容，开始介绍四种DR策略的最后一种—多站点*(双活)*灾备策略

—策略4、多站点(双活)灾备—

多站（双活）灾备策略是指业务以主动-主动配置（active-active）双站同时运行，双站可以设置在AWS和传统数据中心，AWS和AWS不同区域之间等，本文假设双站（双活）为本地数据中心和AWS之间。

多站（双活）策略使用的数据同步方式将由您规划的RPO确定，有关RPO选项的详细信息，请参阅 恢复时间目标（RTO） 和 恢复点目标（RPO） 。除了RPO之外，还要确定复制方式：即同步、异步方式。数据的同步方式的选择没有标准答案，是根据您的组织的对于数据的要求和业务采用的数据解决方案综合评估。

可以使用支持加权路由（weighted routing）的DNS服务（例如Amazon Route 53）将相同的业务访问的流量路由到不同的站点，如一部分路由到到AWS中，一部分将路由到本地数据中心。

假设在本地数据中心发生了故障，可以调整DNS权重（weighted routing）并将所有流量发送到AWS中，然后快速增加AWS服务的容量以处理完整的生产负载。您可以使用Amazon EC2 Auto Scaling自动执行此过程。您可能需要一些应用程序逻辑来检测主数据库服务的故障，并切换到AWS中运行的并行数据库服务。

关于此方案的成本，在未发生灾难的场景，成本只包括AWS正常处理生产环境负载的能力的资源；在恢复场景中，成本包括能够处理生产环境负载的所有资源成本。可以提前规划为一些需要一直在线的服务器购买RI来进一步降低成本。

准备阶段

下图显示了如何使用Amazon Route 53 DNS的加权路由策略将部分流量路由到AWS站点。 AWS上的应用程序可能会访问本地数据中心的数据源，本地数据中心的数据被复制或镜像到AWS中。

准备的关键步骤：

1 建立AWS环境以复制生产环境（本地数据中心）。
2 设置DNS权重，或者采用相似的技术将业务请求分配到双站，并配置自动故障转移，当站点故障时自动切换流量。

恢复阶段

下图显示了本地数据中心发生灾难时流量路由的变化。通过更新DNS将流量切换到AWS中，AWS基础架构支持所有流量和支持数据查询。

恢复的关键步骤：

1 手动或使用DNS故障转移，更改DNS权重，以便将所有请求发送到AWS站点。
2 应用程序要有故障转移的逻辑，以便能够切换使用AWS数据库。
3 考虑使用Auto Scaling自动调整AWS资源的规模（EC2）。

以上AWS灾难恢复方案示例-（4）多站点(双活)灾备策略在AWS中的运用的内容就结束了，我们下次再见！

*如果你希望在云时代掌握核心竞争力，如果您对AWS成本相关或者AWS技术方面有兴趣，请扫码关注我们的公众号吧：

关注公众号：AWS爱好者（iloveaws）
文 | 沉默恶魔（转载请注明出处)
网站：www.iloveaws.cn