本文属于机器翻译版本。若本译文内容与英语原文存在差异，则一律以英文原文为准。
Route 53 ARC 中的可用区转移最佳实践
我们建议采用以下最佳实践在 Route 53 ARC 中使用可用区转移进行多可用区恢复。可用区转移通常会从活动应用程序中移除容量，因此在生产中使用它时务必要小心。
主题
- 容量规划和预扩展
确保您已计划好并且已经预扩展或可以自动扩展足够的容量，以适应可用区转移启动时给可用区施加的额外负载。对于面向恢复的架构，典型的建议是预扩展计算容量，保留足够的余量，以便在三个副本（典型情况下）之一离线时承担流量高峰。
例如，当您开始对单个负载均衡器资源进行可用区转移时，一个可用区的容量会暂时从负载均衡器后面移除。根据您启动的可用区转移以及负载均衡器的配置方式，您必须确保做好精心的计划，以管理剩余可用区上增加的负载。
- 限制客户端与您的终端保持连接的时间
-
当 Amazon Route 53 应用程序恢复控制器将流量从损坏中转移出去时，例如使用区域转移或区域自动切换，Route 53 ARC 用来转移应用程序流量的机制是 DNS 更新。DNS 更新会导致所有新连接都被定向到远离受损位置。
但是，在客户端重新连接之前，具有已打开连接的客户端可能会继续向受损位置发出请求。为确保快速恢复，我们建议您限制客户端与您的终端保持连接的时间。
如果您使用 Application Load Balancer，则可以使用该
keepalive选项来配置连接的持续时间。有关更多信息，请参阅《Application Load Balancer 用户指南》中的 HTTP 客户端保持连接时长。默认情况下，应用程序负载均衡器将 HTTP 客户端 keepalive 持续时间值设置为 3600 秒或 1 小时。我们建议您降低该值，使其与应用程序的恢复时间目标保持一致，例如 300 秒。选择 HTTP 客户端 keepalive 持续时间时，请考虑此值是在更频繁地重新连接（这可能会影响延迟）和更快地将所有客户端从受损的可用区或区域移出受损的可用区或区域之间进行权衡。
- 提前测试开始区域偏移
通过启动可用区转移，定期测试从可用区移走应用程序的流量。最好是同时在测试和生产环境中计划和执行可用区转移，并将该过程纳入到定期的失效转移测试中，以测试发生灾难时恢复应用程序的能力。要确保您已准备好并有信心在运营事件发生时缓解问题，定期测试是一个关键环节。
- 确保所有可用区域都运行良好并占用流量
可用区转移的工作原理是，将某可用区中的一个资源（即应用程序副本）标记为运行状况不佳。这意味着，必须要确保负载均衡器中应用程序的目标总体运行状况良好，并且在区域里的可用区中主动接受流量。我们建议您使用仪表板来跟踪该情况，包括针对不正常目标的 Elastic Load Balancing 指标和每个可用区的 bytesProcessed 等。
考虑从第二个相邻区域监控资源的运行状况。这种方法的优势在于，它可以更好地代表最终用户的体验，还可以降低应用程序和监控同时受到同一灾难影响的风险（“共同命运”）。
- 使用数据平面 API 操作进行灾难恢复
要在需要快速恢复几乎没有依赖关系的应用程序时开始区域移动，我们建议使用 Amazon Command Line Interface 或 API，并尽可能使用带有预存储凭据的区域移位操作和预先存储的凭据。为了便于使用 Amazon Web Services Management Console，您也可以在中开始区域移动。但是，当快速、可靠的恢复至关重要时，数据面板操作是更好的选择。有关更多信息，请参阅可用区转移 API 参考指南。
- 只能暂时通过分区移位来移动交通
可用区转移会暂时将流量从可用区移走，以减轻损失。在采取措施纠正问题后，应立即将应用程序资源恢复为可用。这样能确保整个应用程序恢复到原始的完全冗余的弹性状态。