在一个AWS区域中运行是一种设计选择！

安迪·沃宗（Andy Warzon） | 2015年11月2日

2015年11月2日，星期一

AWS最近在美国东部地区因DynamoDB和相关服务中断，这很好地提醒了设计AWS可用性的一些基本原则。

AWS的最新断电向美国东部地区的DynamoDB和相关服务的介绍很好地提醒了设计AWS可用性的一些基本原则。

如果您需要有关可用区（AZ）与区域的入门知识，看一下这个。对于作为单个虚拟机存在的EC2和RDS之类的服务，这是一个重要的区别，因此在该地区发生重大自然灾害之外，完全隔离的AZ中的单个虚拟机不太可能会宕机。但是默认情况下，许多AWS服务（例如S3和DynamoDB）是多可用区。这很棒，但这也意味着它们具有比人们最初可能想象的更多的跨可用区依赖性。它们实际上更容易受到全区域中断的影响，因为它们确实共享一些跨可用区的依赖关系。

DynamoDB中断是大约4年来的第一次。因此，这并不常见。尽管如此，停电还是停电。但是，如果您将DynamoDB设计为用于区域级冗余，则可以在零停机时间内幸免于此事件。

令人高兴的是，虽然区域级冗余并不是一件容易的事，但实际上并没有那么糟，至少与在传统数据中心环境中构建可比的东西要多么艰巨和昂贵相比。

那么从哪里开始呢？这是考虑区域级冗余的初步清单：

AWS的DNS服务 53路（以及其他DNS服务）允许故障转移，负载平衡和基于延迟的DNS记录集。这些是冗余配置的关键构建块。 53路可以自动监视端点的运行状况，如果第一个区域不正常，则可以将DNS从一个区域自动切换到另一个区域。
如果可以，请使用云形成和配置管理系统（例如Ansible，Salt或Dockerfile）在两个区域中复制堆栈。这是复制环境和应用程序层的最佳方法。
如果您不能使用这些类型的工具来进行自动化，那么下一个最佳选择是使用以下方法来自动化跨区域的EBS快照或AMI的副本：跨区域复制。您可以使用AWS的API来执行此操作，并编写自己的常规作业，但是AWS并未提供更简单的界面。如果您正在寻找一种更简单的计划快照和跨区域副本的方法，请查看云保护管理器.
S3复制和DynamoDB流提供了内置方法来跨区域复制这些服务
当然，数据库是最困难的，但是远比AWS之前的世界（即黑暗时代）容易得多
可以将在AWS的RDS服务中运行的MySQL配置为跨区域复制只需点击几下。这将在第二个区域中异步复制数据库。再单击几下或调用API，就可以将该副本提升为主副本。
如果您在故障转移场景中不需要近乎完美的数据保留，则更便宜的选择是跨区域RDS快照副本。与上面的AMI复制类似，您可以编写自己的脚本或类似CPM的脚本来简化它。
使用Cassandra，Mongo或您在EC2上运行的首选关系数据库来滚动自己的复制。

如果您要使用在EC2上运行的服务进行自己的复制（而不是使用上述AWS内置功能之一），则需要弄清楚如何在区域之间移动数据时保持数据私有。（将其视为您的LAN）只能存在于一个区域中…因此，您基本上需要连接两个LAN才能将数据保留在您自己的网络上。您可以在EC2实例之间创建自己的隧道。连接是使用从以下位置在EC2中运行的虚拟网络设备：凝聚网络。 AWS确实具有一项称为 VPC对等，但目前仅允许您连接同一区域中的VPC，但AWS表示他们计划在将来为其添加跨区域支持。

是否要花费时间来使故障转移过程自动化实际上取决于您的恢复时间目标（RTO）。如果您需要不到1-2个小时的RTO，那么您确实应该自动化。在将数据库升级为主数据库，更新DNS以及任何其他特定于应用程序的更改之间，编写每个步骤的脚本应该相对简单。

最后，请记住，可靠的区域级冗余的最安全计划是双活型。保持两个区域主动服务于请求是最复杂的体系结构，也是管理的最大开销，但这是确定一个区域出现故障时能够保持正常运行的最佳方法。

因此，请记住最重要的一点…服务的整个区域故障，但很少发生。如果您需要尽可能长的正常运行时间，则绝对可以实现多区域冗余。是否花时间去做是您的设计选择！