Route 53 ARC 中路由控制的最佳实践

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

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

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

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

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

当您使用路由控制从一个路由控制切换 Amazon Web Services 区域 到另一个时，Amazon Route 53 应用程序恢复控制器用于移动应用程序流量的机制是 DNS 更新。此更新会导致所有新连接都被定向到远离受损位置。

但是，在客户端重新连接之前，具有已打开连接的客户端可能会继续向受损位置发出请求。为确保快速恢复，我们建议您限制客户端与您的终端保持连接的时间。

如果您使用 Application Load Balancer，则可以使用该keepalive选项来配置连接的持续时间。有关更多信息，请参阅《Application Load Balancer 用户指南》中的 HTTP 客户端保持连接时长。

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

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

我们建议您在需要失效转移时，使用五个区域集群端点中的一个随机端点更新（和检索）路由控制状态。如果该端点失效，请逐个重试其他的区域端点。有关在 Amazon SDK 中使用代码示例的信息，包括试用集群终端节点的示例，请参阅使用 Amazon SDK 的应用程序恢复控制器的代码示例。

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

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

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

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