ARC 中路由控制的最佳实践

在灾难恢复 (DR) 场景中，使用一种简单的方法来访问 Amazon 和执行恢复任务，将系统依赖性降至最低。专为 DR 任务创建 IAM 长效凭证，并将凭证安全地保存在本地物理保险箱或虚拟保管库中，以便在需要时进行访问。借助 IAM，您可以集中管理用户、安全凭证（如访问密钥）以及访问 Amazon 资源的权限。对于非 DR 任务，我们建议您继续使用 Amazon 单点登录等 Amazon 服务进行联合访问。

要使用恢复集群数据面板 API 在 ARC 中执行失效转移任务，您可以将 ARC IAM 策略附加到您的用户。要了解更多信息，请参阅Amazon 应用程序恢复控制器（ARC）基于身份的策略示例。

对于在失效转移机制中可能需要更改的 DNS 记录，尤其是经过运行状况检查的记录，使用较低的 TTL 值是合适的做法。在这种情况下，通常选择将 TTL 设置为 60 秒或 120 秒。

DNS TTL（生存时间）设置会告诉 DNS 解析器在一条记录缓存多长时间后再请求新记录。选择 TTL 时，要在延迟和可靠性与应变能力之间进行权衡。如果记录的 TTL 较短，DNS 解析器将更快地注意到记录的更新，因为 TTL 指定了它们必须更频繁地查询。

有关更多信息，请参阅 Amazon Route 53 DNS 最佳实践中的为 DNS 记录选择 TTL 值。

当您使用路由控制从一个 Amazon Web Services 区域切换到另一个区域时，Amazon 应用程序恢复控制器（ARC）用来移动应用程序流量的机制是 DNS 更新。此更新会导致所有新连接都避开受影响的位置。

但是，先前已打开连接的客户端可能会继续向受影响的位置发出请求，直到客户端重新连接。为确保快速恢复，建议您限制客户端与您的端点保持连接的时间。

如果使用的是应用程序负载均衡器，则可以使用 keepalive 选项来配置连接的持续时间。有关更多信息，请参阅《应用程序负载均衡器用户指南》中的 HTTP 客户端保持连接持续时间。

默认情况下，应用程序负载均衡器将 HTTP 客户端保持连接的持续时间值设置为 3600 秒（即 1 小时）。建议您降低该值，使其与应用程序的恢复时间目标保持一致，例如 300 秒。在选择 HTTP 客户端保持连接的持续时间时，请考虑此值在更频繁地重新连接（这可能会影响延迟）和更快地将所有客户端从受影响的可用区或区域移出之间是一个折中值。

建议您将 ARC 区域集群端点的本地副本保存在书签中，或者保存到用于重试端点的自动化代码中。在发生故障事件期间，您可能无法访问某些 API 操作，包括未托管在极其可靠的数据面板集群上的 ARC API 操作。您可以使用 DescribeCluster API 操作列出 ARC 集群的端点。

路由控制提供五个区域端点，确保在发生故障时也能保持高可用性。要实现其完整韧性，重要的是要具备重试逻辑，可以根据需要使用所有五个端点。有关使用 Amazon SDK 中的代码示例的信息，包括试用集群端点的示例，请参阅使用 Amazon SDK 的应用程序恢复控制器代码示例。

使用 ARC 数据面板 API，通过 ListRoutingControls 操作查看路由控制和状态，并通过 UpdateRoutingControlState 操作更新路由控制状态以重定向流量，准备进行失效转移。您可以使用 Amazon CLI（如这些示例中所示）或您通过一个 Amazon SDK 编写的代码。ARC 数据面板中的 API 可以极其可靠地对流量进行失效转移。我们建议使用 API，而不是在 Amazon Web Services 管理控制台 中更改路由控制状态。

连接到 ARC 的区域集群端点之一，以使用数据面板 API。如果端点不可用，请尝试连接到另一个集群端点。

如果安全规则阻止路由控制状态更新，则可以绕过该规则进行更新并对流量进行失效转移。有关更多信息，请参阅 覆盖安全规则以重新路由流量。

使用 ARC 路由控制定期测试失效转移，以便从主应用程序堆栈失效转移到辅助应用程序堆栈。务必要确保您添加的 ARC 结构与堆栈中的正确资源保持一致，并且一切都按预期运行。您应该在为您的环境设置好 ARC 之后进行该测试，并持续定期进行测试，以便在发生故障之前准备好失效转移环境，这样就能快速启动并运行辅助系统以避免用户停机。