本文属于机器翻译版本。若本译文内容与英语原文存在差异，则一律以英文原文为准。
# Amazon Route 53 运行状况检查执行块
Amazon Route 53 运行状况检查执行块支持您指定在失效转移期间应用程序流量将重定向到的区域。执行块会创建 Amazon Route 53 运行状况检查，然后将其附加到账户中的 Route 53 DNS 记录中。当您执行区域切换计划时，Route 53 运行状况检查状态会更新，并且流量将根据您的 DNS 配置进行重定向。
**重要**
Route 53 托管区域必须与区域切换计划位于同一个分区中。
## 配置
要配置 Route 53 运行状况检查执行块，请输入以下值。
**重要**
在配置执行区块之前，请确保计划的执行角色具有正确的 IAM 策略。有关更多信息，请参阅 [Route 53 运行状况检查执行块示例策略](security_iam_region_switch_route53.md)。
1. **步骤名称：**输入名称。
1. **步骤描述（可选）：**输入步骤的描述。
1. **托管区 ID：**Route 53 中的您的域的托管区 ID 和 DNS 记录。
1. **记录名称：**输入记录名称（域名），您使用这些记录以及相关的运行状况检查来重定向应用程序的流量。区域切换将为该记录名称找到 Route 53 记录集，并尝试根据记录集的**值**或**集合标识符**中的区域名称将每个记录集映射到一个区域。
1. **记录集标识符（可选）：**如果在创建计划后，区域切换无法自动将记录集从步骤 4 中提供的记录名称映射到区域，则可以选择手动提供记录集标识符。如果计划评估返回一条警告，表明需要更多信息，请使用记录集标识符更新您的计划，方法是为每个区域添加以下内容：
+ **记录集标识符：**输入记录集的**设置标识符**或**Value/Route 流量至**。
+ **区域：**输入与具有记录集标识符信息的记录集关联的区域。
1. 选择**保存步骤**。
1. 在 Route 53 中配置运行状况检查。
区域切换为执行块中定义的托管区内的每个记录名称提供每个区域的运行状况检查 ID。确保在 Route 53 中为账户中的相应记录集配置运行状况检查，以便在计划执行期间，区域切换可以正确地重定向应用程序的流量。在计划详情页面的**运行状况检查**选项卡中，您可以查看所有执行块和区域的运行状况检查。
## Route 53 运行状况检查执行区块如何用作高度可用的 DNS 故障转移机制
ARC Region Switch Route53 运行状况检查执行区块会创建两组运行状况检查，如果您的工作负载部署在两个区域，则每个区域一组。它向你提供这些健康检查。您可以通过区域交换机控制台的 “监控” 选项卡或通过 ListRoute53HealthChecks API 查看它们。然后，您将这些运行状况检查与您的 Route 53 DNS 记录相关联。
执行 Route 53 运行状况检查执行区块时，它会在后台使用 STOP（备用接管主节点）模式来更改运行状况检查的状态，以编排 DNS 故障转移。当您协调从主运行状况检查到辅助的故障转移时，主要运行状况检查标记为 “不正常”，辅助运行状况检查标记为 “正常”。Route 53 使用运行状况检查状态的这种更改在故障转移期间重定向流量。
对于 active/passive：主区域的运行状况检查开始正常；被动区域启动时运行状况不正常。当您使用 Route53 运行状况检查执行块进行故障转移时，这些状态会发生变化。
对于 active/active：所有运行状况检查开始时运行正常。当您在停用工作流程中使用 Route53 运行状况检查执行区块时，该工作流程会将停用区域的运行状况检查状态设置为不正常。当您在区域的激活工作流程中使用 Route53 运行状况检查执行区块时，该工作流程会将激活区域的运行状况检查状态设置为运行状况良好。
### 为什么这是一种高可用性的故障转移机制？
之所以成为可靠的故障转移机制，有两个原因：
1. **Route 53 运行状况检查状态转换是 Route 53 数据平面的一部分，该数据平面旨在实现 100% 的可用性 **
更改 Route53 运行状况检查状态的状态是一项数据平面操作。Route53 数据平面分布在全球，旨在实现 100% 的可用性。控制平面不依赖于 Route53 运行状况检查状态的更改。这意味着，即使主区域受损，运行状况检查状态更改仍然有效。
1. **停止模式（待机取代主服务器）**
STOP 模式是一种编排 DNS 故障转移的机制，它发表在博客文章中：使用 Amazon Route 53 [https://www.amazonaws.cn/blogs/networking-and-content-delivery/creating-disaster-recovery-mechanisms-using-amazon-route-53/](https://www.amazonaws.cn/blogs/networking-and-content-delivery/creating-disaster-recovery-mechanisms-using-amazon-route-53/) 创建灾难恢复机制。此模式由 Route53 运行状况检查执行块在后台使用。STOP 模式需要使用健康区域作为 “决策代理” 来更改受损区域的运行状况检查状态。STOP 模式不依赖于受损区域。
以下是它在实践中的运作方式：
+ 当您创建 Route53 运行状况检查执行区块时，运行状况检查由区域交换机在每个区域为您的工作负载创建，并通过监控选项卡中的区域交换机控制台或 API 出售给您。 ListRoute53HealthChecks
+ 然后，您可以手动将其与每个区域的 DNS 记录关联起来。一项运行状况检查与主要区域的 DNS 记录相关联，另一项与您的辅助区域的 DNS 记录相关联。
+ 运行状况检查与主区域的 DNS 记录相关联，但它会监控备用（辅助）区域中的资源（例如：S3 中存在文件）以更改运行状况检查的状态。
+ 运行状况检查是反向的 — 如果无法访问备用资源，则主区域的运行状况检查默认为运行状况良好。如果发现备用资源，则主区域的运行状况检查将更改为不正常。这样可以防止意外故障转移。
+ 要触发故障转移，该文件由备用区域中的区域交换机创建。运行状况检查会检测到该漏洞，将其标记为不正常，Route53 会翻转 DNS。备用资源由区域交换机服务管理，不依赖于客户。
当客户仅在两个区域运营时，无控制平面依赖关系（全球分布式数据平面）和无受损区域依赖性（STOP 模式）相结合，使其成为一种高度可用的 DNS 故障转移机制。请参阅此处记录的停止模式：使用 Amazon Route 53 [ 创建灾难恢复机制](https://www.amazonaws.cn/blogs/networking-and-content-delivery/creating-disaster-recovery-mechanisms-using-amazon-route-53/)。
## 比较 ARC 路由控制和 Route 53 运行状况检查执行块
区域交换机中的 Amazon Route 53 运行状况检查执行区块为 DNS-based 流量管理提供了一种成本较低的替代方案。但是，此执行区块取决于您激活 Amazon Web Services 区域 的区块，因此该区域必须可用。这满足了大多数客户的需求，因为他们正在激活一个健康的区域。
ARC 路由控制提供高度可靠的 DNS-based 流量管理，服务级别协议为 100% 的可用性。借助路线控制，您的运营团队可以通过安全护栏在区域之间转移流量。路由控制提供了一种具有 100% 服务级别协议的单租户解决方案。路由控制集群分布在五个区域，可以容忍两个区域处于离线状态。如果您有高度关键的应用程序，请考虑使用路由控制。
路由控制不需要使用区域切换。您可以使用区域切换来管理流量重定向，方法是使用没有路由控制的 Route 53 运行状况检查执行块。
在以下情况下，路由控制使用区域开关增加价值：
+ 您需要流量控制机制本身的100％可用性SLA。
+ 您的组织需要手动操作控制和关键应用程序的安全规则。
+ 你需要深度防御，这样运营团队可以在需要时手动改写自动交通路由。
Route 53 运行状况检查执行区块不依赖于控制平面。运行状况检查记录更改使用数据平面，因此它们不需要激活区域来处理配置更新。在以下情况下，Route 53 运行状况检查执行块就足够了：
+ 您的应用程序可能取决于您激活的应用程序。 Amazon Web Services 区域
+ 作为恢复工作流程的一部分，自动流量重定向可以满足您的要求。
+ 成本优化是当务之急。Route 53 运行状况检查执行区块的成本低于路由控制。
大多数客户一开始使用 Route 53 运行状况检查执行块作为默认流量路由机制，然后仅为需要最高流量管理机制可靠性的最关键应用程序添加路由控制。