中的路由控制最佳实践 ARC

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

要在ARC恢复集群数据平面中执行故障转移任务API，您可以将ARCIAM策略附加到您的用户。要了解更多信息，请参阅 中基于身份的策略示例 。

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

DNSTTL（存活时间）设置告诉DNS解析器在请求新记录之前要缓存记录多长时间。当你选择 a 时TTL，你需要在延迟和可靠性以及对变化的响应能力之间进行权衡。在记录TTL上缩短时，DNS解析器会更快地注意到记录的更新，因为TTL指定他们必须更频繁地进行查询。

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

当您使用路由控制从一个路由控制切换 AWS 区域 到另一个时，Amazon Application Recovery Controller (ARC) 用来转移应用程序流量的机制就是DNS更新。此更新使所有新连接都被定向到远离受损位置。

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

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

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

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

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

使用ARC数据平面查看ListRoutingControls操作的路由控制和状态API，并更新路由控制状态以重定向流量，以便在UpdateRoutingControlState操作中进行故障转移。您可以使用 AWS CLI （如这些示例所示）或使用其中一个编写的代码 AWS SDKs。ARC在数据层面API中提供极高的可靠性，可以对流量进行故障切换。我们建议使用API而不是在中更改路由控制状态 AWS Management Console。

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

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

使用ARC路由控制定期测试故障转移，以便从主应用程序堆栈故障转移到辅助应用程序堆栈。重要的是要确保您添加的ARC结构与堆栈中的正确资源保持一致，并且一切都按预期运行。您应在ARC为环境设置完毕后对此进行测试，并继续定期进行测试，以便在遇到故障之前，您需要辅助系统快速启动并运行，以避免用户停机，从而为故障转移环境做好准备。