View a markdown version of this page

配置可用区自动转移的最佳实践 - Amazon 应用程序恢复控制器（ARC）

本文属于机器翻译版本。若本译文内容与英语原文存在差异，则一律以英文原文为准。

配置可用区自动转移的最佳实践

在 Amazon 应用程序恢复控制器（ARC）中启用可用区自动转移时，请注意以下最佳实践和注意事项。

可用区自动转移包括两种类型的流量转移：自动转移和练习运行可用区转移。

  • 借 AWS 助自动转移，在事件发生期间代表您将应用程序资源流量从可用区转移出去，从而帮助缩短恢复时间。

  • 借助练习运行，ARC 代表您启动可用区转移，或者您启动可用区转移练习运行。这种分区转移的 AWS 做法是将流量从可用区域转移到某个资源，然后以每周的节奏再次返回。练习运行可帮助您确保已为区域中的可用区纵向扩展了足够的容量，以便您的应用程序能够容忍丢失一个可用区。

在使用自动转移和练习运行时，有几个最佳实践和注意事项需要牢记。在启用可用区自动转移或为资源配置练习运行之前，请先阅读以下主题。

主题

限制客户端与您的端点保持连接的时间

当 Amazon 应用程序恢复控制器（ARC）将流量从受影响的可用区中转移出去时（例如使用可用区转移或可用区自动转移），ARC 用来转移应用程序流量的机制是 DNS 更新。DNS 更新会导致所有新连接都避开受影响的位置。但是，先前已打开连接的客户端可能会继续向受影响的位置发出请求，直到客户端重新连接。为确保快速恢复，建议您限制客户端与您的端点保持连接的时间。

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

有关为应用程序负载均衡器设置 keepalive 选项的更多信息，请参阅《应用程序负载均衡器用户指南》中的 HTTP 客户端保持连接持续时间。

预先扩展您的资源容量并测试流量的转移

当 AWS 将流量从一个可用区转移出来进行分区转移或自动转移时，剩余的可用区域必须能够满足提高的资源请求率。这种模式称为静态稳定性。有关更多信息，请参阅 Amazon Builders' Library 中的“使用可用区的静态稳定性”白皮书。

例如，如果您的应用程序需要 30 个实例来为其客户端提供服务，则应跨三个可用区预置 15 个实例，总共预置 45 个实例。这样，当流量从一个可用区 AWS 转移时（使用自动转移或在练习运行期间），仍然AWS 可以在两个可用区为应用程序的客户端提供总共 30 个实例的剩余总数 30 个实例。

当您的应用程序的资源已预先扩展到在一个可用区中断的情况下可以正常运行时，ARC 中的区域自动转移功能可帮助您快速从可用区 AWS 的事件中恢复。在为资源启用可用区自动转移之前，请在 AWS 区域的所有已配置可用区中扩展您的资源容量。然后，对资源启动可用区转移，以测试当流量从可用区转移出去时，您的应用程序是否仍能正常运行。

使用可用区转移进行测试后，启用可用区自动转移并为应用程序资源配置练习运行。运行您自己的按需练习运行，以帮助确保您的配置得到正确扩展。使用区域自动转移进行定期练习运行可帮助您持续确保容量仍得到适当扩展。由于跨可用区有足够的容量，您的应用程序可以在自动转移期间不间断地继续为客户端提供服务。

有关为资源启动可用区转移的更多信息，请参阅ARC 中的可用区转移。

注意资源类型和限制

可用区自动转移支持将由可用区转移支持的所有资源的流量移出可用区。在一些特定的资源场景中，可用区自动转移不会将流量从可用区转移出来进行自动转移。

例如，如果可用区中的负载均衡器目标组没有任何实例，或者所有实例都运行状况不佳，则负载均衡器进入打开失败状态。在这种情况下，如果为负载均衡器 AWS 启动自动移动，则自动移位不会更改负载均衡器使用的可用区，因为负载均衡器已经处于失效打开状态。这是预料之中的行为。 AWS 区域 如果所有可用区域都无法打开（不正常），Autoshift 无法导致一个可用区运行状况不佳，也无法将流量转移到其他可用区。

要查看有关受支持资源的详细信息（包括所有需要注意的要求和例外情况），请参阅支持的资源。

指定练习运行警报

您必须为使用可用区自动转移执行的练习运行至少配置一种类型的警报（结果警报）。或者，您也可以配置第二种类型的警报（阻止警报）。

当您考虑为资源的练习运行配置 CloudWatch 警报时，请记住以下几点：

  • 对于练习运行配置，您至少需要配置一个结果警报。对于结果警报，我们建议您将 CloudWatch 警报配置为在资源或应用程序的指标表明将流量转移出可用区会对性能产生不利影响时进入的ALARM状态。例如，您可以确定资源的请求速率阈值，然后将警报配置为在超出该阈值时进入 ALARM 状态。您负责配置适当的警报，从而使 AWS 结束练习运行并返回 FAILED 结果。

  • 我们建议您遵循架构AWS 完善的框架，该框架建议您将关键绩效指标 (KPI) 作为警报来实现。 CloudWatch如果您这样做，则可以使用这些警报来创建复合警报以用作安全触发器，以防止在练习运行可能导致应用程序未达到 KPI 要求的情况下启动练习运行。当警报不再处于 ALARM 状态时，ARC 将在下次为资源安排练习运行时启动练习运行。

  • 对于练习跑阻塞警报，如果您选择配置一个（或多个）警报，则可以选择跟踪特定指标，以表明您不希望开始 AWS 练习跑——例如，当警报表明正在发生事故时。

  • 对于练习运行警报，您可以为每个警报指定亚马逊资源名称 (ARN)，因此您必须先在亚马逊 CloudWatch中配置警报。您指定的 CloudWatch 警报可以是复合警报，使您能够包括多个指标，并检查可能触发警报进入某个ALARM状态的应用程序和资源。或者，您可以配置单独的警报，然后为您的练习跑配置指定每种类型的多个警报。有关更多信息，请参阅《亚马逊 CloudWatch 用户指南》中的组合警报。

  • 确保您为练习跑步指定的 CloudWatch 警报与您配置练习跑步的资源位于同一区域。

评估练习运行结果

ARC 会报告每次练习运行的结果。执行练习运行后，评估结果并确定是否需要采取措施。例如，您可能需要扩展容量或调整警报的配置。

以下是可能的练习跑结果：

  • SUCCEEDED：在练习运行期间，无结果警报进入 ALARM 状态，练习运行完成了整整 30 分钟的测试周期。

  • FAILED：在练习运行期间，至少一个结果警报进入了 ALARM 状态。

  • 已中断：练习运行结束的原因并非结果警报进入 ALARM 状态。练习运行可能因各种原因而中断，包括以下几个原因：

    • 练习赛之所以结束，是因为该地区 AWS 已开始自动换挡 AWS 区域 或该地区出现警报情况。

    • 练习运行之所以结束，是因为已删除资源的练习运行配置。

    • 练习运行之所以结束，是因为已为可用区中的资源启动客户发起的可用区转移，而练习运行可用区转移已将流量从可用区中转移出去。

    • 由于无法再访问为练习跑配置指定的 CloudWatch 警报，练习跑已结束。

    • 练习运行之所以结束，是因为为练习运行指定的阻止警报进入 ALARM 状态。

    • 练习运行因未知原因而结束。

    • 练习运行已结束，因为发起了优先于它的可用区自动转移。请参阅可用区转移的优先级。

  • CAPACITY_CHECK_FAILED：对跨可用区的负载均衡和自动扩缩组资源的均衡容量检查失败。

  • 待处理：练习运行处于活动状态（正在进行中）。目前还没有结果可以返回。