多区域故障切换策略的构建

关键要点

本文探讨了创建组织级多区域故障切换策略的四种高层次方法：组件级故障切换、单个应用故障切换、依赖图故障切换和整个应用组合故障切换。每种策略在灵活性、复杂性和组织投资方面都有不同的权衡，帮助您选择适合您多区域故障切换解决方案的方法。

AWS区域提供了故障隔离边界，可以防止相关故障，并将AWS服务障碍的影响限制在单个区域内，从而为您构建多区域应用程序提供支持，这些应用程序由每个区域的独立、故障隔离的副本组成。这种能力允许您实现多种多样的架构，从备份和恢复到积极/积极的实施方式。然而，应用程序通常不会孤立运行，您需要考虑所有组件及其依赖关系作为故障切换策略的一部分。因此，您应当制定一个组织级的多区域故障切换策略，以提供必要的协调和一致性，使您的方法成功。

概述

组织在指导多区域方法时可以选择四种高层次的策略：

这些策略从最细粒度到最粗粒度不等。每种策略都有其权衡，并且解决不同的挑战，包括故障切换决策的灵活性、故障切换组合的可测试性、模式行为的出现，以及在规划和实施中的组织投资。通过本文，您将能够识别每种策略的优缺点，以便对多区域故障切换解决方案进行明智选择。

组件级故障切换

应用程序由多个组件构成，包括其基础设施、代码及配置、数据存储和依赖关系。组件级故障切换策略帮助您在单个组件出现故障时进行恢复。这意味着当某个组件出现故障时，应用程序会故障切换到位于不同区域的组件。例如，如图1所示，当应用程序使用的Amazon S3资源出现错误率上升或延迟增加时，该应用程序将故障切换到其备用区域中的S3存储桶。

这种策略为单个应用程序提供了最高的自主权和灵活性，但也存在四个主要权衡：

单个应用故障切换

下一个策略允许单个应用程序自主决定一起故障切换其所有组件，如图2所示。这消除了前一种策略的延迟权衡，因为所有应用程序组件都保持在同一区域。这也显著降低了复杂性，每个应用程序只有两种可能的配置。此外，通过使用Amazon Route 53 DNS故障切换等方法，应用程序可以在无需更新配置的情况下故障切换到另一个区域，消除了运行时配置更新的不可靠性。

然而，允许单个应用程序进行自主故障切换决策可能会引入我们在组件级故障切换中看到的相同模式行为，尽管是在不同的维度上。最坏的情况下，用户故事中的50应用程序可能会故障切换，而另一半则不会，这意味着每个应用交互都可能是跨区域请求，如图3所示。

此外，这种方法虽然消除了组件故障切换方法的复杂性，但仍然表现出一定程度的相似复杂性，在区域之间存在 DN1 种应用程序位置的组合，这也使得该方法难以测试和协调。

依赖图故障切换

为了减轻上一路径的复杂性，您可以决定协调所有支持用户故事的应用程序一起进行故障切换。我们称之为依赖图，确保所有相互作用的应用程序始终在同一区域内，如图4所示。

虽然这样解决了延迟、模式行为和复杂性的权衡，但也带来了一些新的挑战。在多个用户故事和应用程序的组合中，该图可能非常庞大，发现每个依赖关系，尤其是不常使用的依赖关系，可能会很困难。实际上，表面上无关的依赖图可以通过一个共享的顶点相互连接，如图5所示。

例如，如果您提供的每个用户故事都依赖于一个单独的身份验证和授权系统，当某个应用程序图需要故障切换时，整个身份授权系统也需要故障切换。这样，所有依赖该授权系统的其他用户故事也需故障切换。为了解决这个问题，您可以在每个区域独立实现这些类型的应用程序副本，以减少依赖图中的边。

整个组合故障切换

最后一种策略是对整个应用组合进行故障切换，无论这些应用是否受到影响或与受到影响的应用有任何互动，如图6所示。这种策略有助于消除为每个用户故事创建和维护依赖图的操作负担。

主要的权衡是需要组织投资来为每个应用程序创建多区域能力 您可能没有对其他策略进行如此广泛的投资。通过对特定应用程序层实施该策略，可以使其稍微更细粒度，例如，将所有层1应用程序一起故障切换，前提是您知道在不同重要性的应用程序之间没有依赖关系。

您还可以将这种方法与第二种策略结合。让单个应用程序进行故障切换决策，直到观察到足够广泛的影响，或者由于模式行为产生的影响，您决定让所有应用程序故障切换到次要区域以减轻影响。

结论

本文探讨了创建组织级多区域故障切换策略的四种不同高层次方法。每种策略针对不同的结果进行优化。组件级故障切换提供了最高的灵活性，而无需组织能力或协调，但引入了最大的复杂性和双模行为。单个应用故障切换则优化了故障切换组合的复杂性，并仍然保持去中心化的灵活性。依赖图故障切换则优化了仅需要故障切换支持某一能力的最小应用程序集，从而消除了模式行为，但需要更多的组织投资。最后，整个组合故障切换优化了不需要维护依赖图的需求，但需要对每个应用程序建立多区域能力进行重大额外投资。

创建策略可以是一个迭代的过程。您可以开始时允许单个应用程序进行故障切换决策，同时构建一个未来的独立依赖图的故障切换管理能力。有关创建多区域架构的更多信息，请参见AWS多区域基础知识和AWS工作负载的灾难恢复。

标签：灾难恢复，故障切换，多区域

作者介绍

Michael是AWS战略客户团队的高级首席解决方案架构师，帮助客户创新、差异化业务，并转型客户体验。他拥有15年为金融服务、公共部门和数字原生客户提供支持的经验。Michael在弗吉尼亚大学获得了学士学位，并在约翰霍普金斯大学获得了计算机科学硕士学位。工作之外，他喜欢和家人及狗一起在农场上玩耍。

John Formento Jr是AWS弹性基础设施和解决方案组织的首席产品经理。他帮助客户在AWS上实现其弹性目标，通过构建恢复工具并专注于内部AWS弹性倡议来促进客户的成功。

Saurabh Kumar是AWS的一名解决方案架构师，工作地点位于北卡罗来纳州的罗利。他热衷于帮助客户解决从迁移到现代化以及优化的业务挑战和技术问题。在工作之外，他喜欢与家人一起看电视、园艺和户外活动。