Amazon Route 53 应用程序恢复控制器功能可帮助您为 AWS 上的高可用性应用程序准备和运行恢复操作。
为您的应用程序副本设置就绪检查和路由控制后,您可以Not ready
通过在 EventBridge 中创建规则来在就绪检查状态更改为时通知您,并且您可以在控制台中查看您的应用程序和副本的状态。就绪检查会持续审核您的应用程序是否存在可能影响应用程序可恢复性的问题。此外,您可以通过更改路由控件的状态来触发恢复,以将流量从受损副本路由出去。我们建议您通过在高度可靠的 Route 53 ARC 数据平面中使用 API 操作来更新路由控制状态以转移流量。
Amazon Route 53 Application Recovery Controller 审核您的应用程序副本,以确保您的每个堆栈副本通过使用就绪检查来确保每个副本具有相同的配置设置和相同的运行时状态。
例如,要为恢复做好准备,您必须始终保持足够的备用容量来吸收来自另一个可用区或区域的故障转移流量。Route 53 ARC 持续(每分钟一次)检查您的应用程序,以确保您的预置容量在所有可用区或区域中匹配。Route 53 ARC 检查的容量包括 Amazon EC2 实例计数、Aurora 读写容量单位和 Amazon EBS 卷大小等。如果您在主副本中扩展资源值的容量,但忘记同时增加备用副本中的相应值,Route 53 ARC 会检测到不匹配,以便您可以增加备用副本中的值。
就绪检查对于持续验证应用程序副本配置和运行时状态是否一致***有用。不应使用就绪检查来指示您的生产副本是否健康,也不应将就绪检查作为灾难事件期间故障转移的主要触发器。
在主动-备用配置中,您应该根据您的监控和健康检查系统来决定是故障转移还是故障转移,并将就绪检查视为这些系统的补充服务。Route 53 ARC 就绪检查的可用性不高,因此您不应依赖在中断期间可访问的检查。此外,在灾难事件期间,检查的资源也可能不可用。
您可以监控特定单元(AWS 区域或可用区)中应用程序资源或整个应用程序的就绪状态。Not ready
通过在 EventBridge 中创建规则,您可以在准备检查状态更改时收到通知,例如更改为。有关更多信息,请参阅将 Route 53 ARC 与 Amazon EventBridge 结合使用。您还可以在 AWS 管理控制台或使用 API 操作(例如get-recovery-readiness
. 有关详细信息,请参阅恢复就绪(就绪检查)操作。
Route 53 ARC 路由控件是一个开/关开关,可更改 Route 53 ARC 运行状况检查的状态,然后可以将其与重定向流量的 DNS 记录相关联,例如,从主部署副本重定向到备用部署副本。
如果存在应用程序故障或延迟问题,您可以更新路由控制状态以将流量从主副本转移到备用副本等。通过使用高度可靠的 Route 53 ARC 数据平面 API 操作来进行路由控制查询和路由控制状态更新,您可以依靠 Route 53 ARC 在灾难恢复场景中进行故障转移。有关更多信息,请参阅 使用 Route 53 ARC API 获取和更新路由控制状态(推荐)。
Route 53 ARC 在集群中维护路由控制状态,集群是一组五个冗余区域端点。Route 53 ARC 在位于 Amazon EC2 队列中的集群中传播路由控制状态更改,以获得跨五个 AWS 区域的仲裁。传播后,当您使用 API 和高可靠数据平面向 Route 53 ARC 查询路由控制状态时,它会返回共识视图。
您可以与五个集群端点中的任何一个进行交互,以将路由控件的状态从例如更新Off
为On
. 然后 Route 53 ARC 将更新传播到集群的五个区域。
所有五个集群端点的数据一致性平均在 5 秒内实现,***长不超过 15 秒。
Route 53 ARC 通过其数据平面提供极高的可靠性,让您可以跨单元手动故障转移应用程序。Route 53 ARC 确保您始终可以访问五个集群端点中的至少三个,以执行路由控制状态更改。请注意,每个 Route 53 ARC 集群都是单租户的,以确保您不会受到可能会减慢访问模式的“嘈杂邻居”的影响。
当您更改路由控制状态时,您依赖以下三个标准,这些标准不太可能失败:
当您计划故障转移和灾难恢复时,重要的是要考虑故障转移机制的弹性,并确保您所依赖的机制具有高可用性,以便您可以在灾难场景中需要它们时使用它们。通常,您应该尽可能为您的机制使用数据平面功能,以获得***的可靠性和容错性。考虑到这一点,重要的是要了解服务的功能如何在控制平面和数据平面之间划分,以及何时可以依赖服务数据平面的极端可靠性。
Route 53 ARC 包括两组功能,准备检查和恢复路由控制。与大多数 AWS 服务一样,Route 53 ARC 功能由控制平面和数据平面支持。虽然这两种类型都是为了可靠而构建的,但控制平面针对数据一致性进行了优化,而数据平面针对可用性进行了优化。数据平面专为弹性而设计,因此即使在控制平面可能变得不可用的破坏性事件期间,它也可以保持可用性。因此,我们建议您在可用性很重要时使用数据平面操作,例如,当您需要在中断期间将流量重新路由到备用副本时。
一般来说,控制平面使您能够执行基本的管理功能,例如在服务中创建、更新和删除资源。数据平面提供服务的核心功能。
对于 Route 53 ARC,控制平面和数据平面划分如下:
要了解有关使用 Route 53 ARC 进行恢复准备和故障转移准备的更多信息,请参阅Amazon Route 53 Application Recovery Controller 的***实践。
有关数据平面、控制平面以及 AWS 如何构建服务以满足高可用性目标的更多信息,请参阅使用可用区的静态稳定性一文