配置区域自动移位时的最佳实践 - Amazon 应用程序恢复控制器 (ARC)

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

配置区域自动移位时的最佳实践

在 Amazon 应用程序恢复控制器 () ARC 中启用区域自动切换时，请注意以下最佳做法和注意事项。

区域自动换档包括两种类型的交通换档：自动换档和练习跑分区换档。

  • 借 AWS 助自动切换，可在活动期间代表您转移可用区的应用程序资源流量，从而缩短恢复时间。

  • 在练习跑中，代表你ARC开始区域移动。区域转移将资源的流量从可用区域转移出来，然后按每周的节奏再次转移回来。练习运行可帮助您确保已为区域中的可用区纵向扩展了足够的容量，以便您的应用程序能够容忍丢失一个可用区。

对于自动换档和练习跑，需要记住几个最佳做法和注意事项。在启用可用区自动转移或为资源配置练习运行之前，请先阅读以下主题。

主题

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

当 Amazon Application Recovery Controller (ARC) 将流量从损坏中转移出去时，例如使用区域转移或区域自动移动，则用于移动应用程序流量的机制就是ARC更新。DNSDNS更新会导致所有新连接被引导到远离受损位置。但是，在客户端重新连接之前，具有已打开连接的客户端可能会继续向受损位置发出请求。为确保快速恢复，我们建议您限制客户端与您的终端保持连接的时间。

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

有关为 Application Load Balancer 设置keepalive选项的更多信息，请参阅《Application Load Balancer 用户指南》中的HTTP客户端保持连接时长。

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

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

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

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

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

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

注意资源类型和限制

可用区自动转移支持将由可用区转移支持的所有资源的流量移出可用区。通常，支持已关闭跨区负载均衡的网络负载均衡器和应用程序负载均衡器。在一些特定的资源场景中，可用区自动转移不会将流量从可用区转移出来进行自动转移。

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

第二种情况是，如果为作为加速器端点的 Application Load Balancer AWS 启动自动换档。 AWS Global Accelerator与可用区转移一样，Global Accelerator 中作为加速器端点的应用程序负载均衡器不支持自动转移。

要查看有关受支持资源的详细信息（包括所有需要注意的要求和例外情况），请参阅支持区域偏移和区域自动移位的资源和场景。

为练习跑指定警报

对于使用区域自动移位的练习跑，您至少要配置一个警报（结果警报）。或者，您也可以配置第二个警报（屏蔽警报）。

在考虑为资源练习跑配置的 CloudWatch 警报时，请记住以下几点：

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

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

  • 对于练习运行阻止警报，如果您选择对其进行配置，则可以选择跟踪用于指示您不想启动练习运行的特定指标。

  • 对于练习运行警报，您可以为每个警报指定 Amazon 资源名称 (ARN)，您必须先在 Amazon 中配置该名称 CloudWatch。您指定的 CloudWatch 警报可以是复合警报，这样您就可以为应用程序和资源添加多个指标和检查，从而触发警报进入ALARM状态。有关更多信息，请参阅 Amazon CloudWatch 用户指南中的合并警报。

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

评估练习跑的结果

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

以下是可能的练习运行结果：

  • SUCCEEDED: 在练习跑期间，结果警报没有进入ALARM状态，练习跑完成了整整30分钟的测试周期。

  • FAILED: 在练习跑期间，结果警报进入ALARM状态。

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

    • 练习跑之所以结束，是因为在该地区 AWS 开始了自动换档 AWS 区域 或者该地区出现了警报情况。

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

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

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

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

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

  • PENDING: 练习跑处于活动状态（进行中）。目前还没有结果可以返回。