多区域基础知识 4：运营准备就绪

操作多区域工作负载是一项复杂的任务，会带来多区域特有的运营挑战。其中包括AWS 账户管理、重新调整部署流程、创建多区域可观察性策略、创建和测试故障转移和故障恢复运行手册，然后管理成本。运营准备情况评估 (ORR) 可以帮助团队为生产工作做好准备，无论是在单个区域还是在多个区域运行。

4a：管理 AWS 账户

要在跨区域部署工作负载AWS 区域，请确保账户内的所有AWS服务配额在不同区域之间保持平衡。首先，了解架构中的所有AWS服务，查看备用区域的计划使用情况，然后将其与当前使用情况进行比较。在某些情况下，如果以前未使用过备用区域，则可以参考默认服务配额来了解起点。然后，在将要使用的所有服务中，使用 S ervice Quotas 控制台（需要登录）或 API 申请增加配额。

AWS需要在每个区域配置 Ident@@ ity and Access Managem ent (IAM) 角色，以确保操作员、自动化工具和AWS服务对备用区域内的资源拥有适当的权限。区域隔离角色实现了我们对多区域架构所追求的区域隔离。在备用区域上线之前，请确保这些权限已到位。

4b：部署实践

使用多区域功能，将工作负载部署到多个区域可能很复杂。 AWS CloudFormation有助于将基础设施部署到单个或多个区域，并且可以根据您的需求进行定制。 AWS CodePipeline有助于提供近乎持续的集成/持续交付 (CI/CD) 管道，该管道具有跨区域操作，允许部署到与管道所在区域不同的区域。再加上蓝/绿等强大的部署策略，可以实现最少至零的停机时间部署。

但是，当应用程序或数据的状态未外部化到持久存储时，有状态功能的部署可能会更加复杂。在这些情况下，请仔细调整部署流程以满足您的需求。设计部署管道和流程，一次部署在一个区域，而不是同时在多个区域部署。这减少了区域之间出现相关故障的机会。要了解 Amazon 用于自动部署软件的技术，请阅读生成器库文章自动执行安全、无需动手的部署。

4c：可观察性

在设计多区域时，请考虑如何监控每个区域中所有组件的运行状况，以全面了解区域运行状况。这可能包括复制延迟的监控指标，这不是单个区域工作负载的考虑因素。

在构建多区域架构时，也要考虑从备用区域观察工作负载的性能。 这包括在备用区域运行运行状况检查和加那利群岛（综合测试），从而提供主区域健康状况的外部视图。此外，您还可以使用 Amazon CloudWatch Internet Monit or 从最终用户的角度了解外部网络的状态和工作负载的性能。同样，主区域应具有相同的可观察性来监控备用区域。这些加那利群岛应该监控客户体验指标，以了解工作负载的整体运行状况。这是必需的，因为如果主区域出现问题，则主区域的可观察性可能会受到损害，从而影响评估工作负载运行状况的能力。

在这种情况下，在该区域之外进行观察可以提供见解。这些指标应汇总到每个区域可用的仪表板中，并在每个区域创建警报。由于 Amazon CloudWatch 是一项区域性服务，因此需要在两个区域都提供这些服务。此监控数据将用于调用从主区域到备用区域的故障转移。

4d：流程、程序和测试

回答 “我应该何时进行故障转移？” 这个问题的最佳时机 早在你需要之前。包括人员、流程和技术在内的业务连续性计划都应在问题出现之前尽早确定，并定期进行测试。确定恢复决策框架。如果有经过良好实践的恢复过程并且对恢复时间了如指掌，则可以选择启动通过故障转移达到 RTO 目标的恢复过程的时间点。这个时间点可能是在发现主区域的应用程序存在问题之后立即出现的，也可能是在该区域应用程序中的恢复选项已经用尽之后，现在应该开始故障转移以满足 RTO。

虽然故障转移操作本身应实现 100% 自动化，但激活故障转移的决定应由人力（通常是组织中少数预先确定的个人）做出。此外，决定故障转移的标准需要明确界定，并让组织全面了解这些标准。这些流程可以使用 Sy AWSstem Manager 运行手册来定义和完成，它允许完全 end-to-end 自动化，并确保测试和故障转移期间流程运行的一致性。

这些运行手册应在主区域和备用区域中可用，以启动故障转移或故障恢复过程。一旦实现了这种自动化，就应该定义并遵循定期的测试节奏。这样可以确保在发生实际事件时，响应是在组织有信心的明确、实践的流程上进行的。同样重要的是要记住数据协调过程的既定容差。确认建议的流程符合既定的 RPO/RTO 要求。

4e：成本和复杂性

多区域架构的成本影响是由更高的基础设施使用率、运营开销和资源时间造成的。如前所述，备用区域的基础设施成本与预配置时主区域的基础设施成本相似，因此成本是原来的两倍。配置容量使其足以满足日常运营，但仍保留足够的缓冲容量以容忍需求激增——并在每个区域配置相同的限制。

此外，如果您采用主动-主动架构，则可能需要进行应用程序级别的更改才能在多区域架构中成功运行，而主动-主动架构的设计和操作可能需要花费大量时间和资源。组织至少需要花时间了解每个地区的技术和业务依赖关系，并设计故障转移和故障恢复流程。

团队还应进行正常的故障转移和故障恢复练习，以便对活动期间使用的运行手册感到满意。尽管这些活动对于从多区域投资中获得预期结果极其重要和关键，但它们代表着机会成本，会占用其他活动的时间和资源。

关键指导

• AWS需要审查服务配额，并在工作量所在的所有地区保持平等。

• 部署过程应一次针对一个区域，而不是同时针对多个区域。

• 需要监控复制延迟等其他指标，这些指标特定于多区域场景。

• 将工作负载的监控范围扩展到主区域之外。应按区域监控客户体验指标，并从每个运行工作负载的区域之外进行衡量。

• 需要定期测试故障转移和故障恢复。确保实施在测试和直播活动期间使用的故障转移和故障恢复流程的单一操作手册。测试和直播活动的运行手册不能不同。