本文属于机器翻译版本。若本译文内容与英语原文存在差异，则一律以英文原文为准。
# 配置 DNS 故障转移
当您有多个执行同一功能的资源（例如，多台 HTTP 服务器或邮件服务器）时，可以配置 Amazon Route 53，以便检查您的资源的运行状况并仅使用正常资源来响应 DNS 查询。例如，假设您的网站 example.com 托管在 6 台服务器上，这些服务器位于全球三个数据中心，每个数据中心两台。您可以对 Route 53 进行配置，以检查这些服务器的运行状况，并且只使用当前运行状况良好的服务器来响应对 example.com 的 DNS 查询。
Route 53 可以检查您的资源在简单和复杂配置中的运行状况：
+ 在简单配置中，可创建一组具有相同名称和类型的记录，例如，用于 example.com 的一组加权记录，其类型为 A。然后，可对 Route 53 进行配置以检查相应资源的运行状况。Route 53 将根据资源的运行状况来响应 DNS 查询。有关更多信息，请参阅 [简单 Amazon Route 53 配置中的运行状况检查的工作原理简单配置中的运行状况检查的工作原理](dns-failover-simple-configs.md)。
+ 在更复杂的配置中，将创建根据多个标准路由流量的一个记录树。例如，如果用户的延迟是您最重要的标准，则您可能会使用延迟别名记录，以便将流量路由至可提供最短延迟的区域。延迟别名记录可能会将每个区域中的加权记录作为别名目标。加权记录可能会根据实例类型将流量路由到 EC2 实例。和简单配置一样，可以将 Route 53 配置为根据资源的运行状况路由流量。有关更多信息，请参阅 [复杂 Amazon Route 53 配置中的运行状况检查的工作原理复杂配置中的运行状况检查的工作原理](dns-failover-complex-configs.md)。
**Topics**
+ [配置 DNS 故障转移的任务列表](dns-failover-how-to.md)
+ [简单 Amazon Route 53 配置中的运行状况检查的工作原理](dns-failover-simple-configs.md)
+ [复杂 Amazon Route 53 配置中的运行状况检查的工作原理](dns-failover-complex-configs.md)
+ [Amazon Route 53 在已配置运行状况检查时如何选择记录](health-checks-how-route-53-chooses-records.md)
+ [主动/主动和主动/被动故障转移](dns-failover-types.md)
+ [在私有托管区域中配置故障转移](dns-failover-private-hosted-zones.md)
+ [Amazon Route 53 如何避免故障转移问题](dns-failover-problems.md)
# 配置 DNS 故障转移的任务列表
要使用 Route 53 配置 DNS 故障转移，请执行以下任务：
1. 绘制配置的完整树形图，并指明您要为每个节点创建哪种记录 (加权别名、故障转移、延迟等)。在树顶端放入域名 (例如 example.com) 的记录，您的用户将使用它访问您的网站或 Web 应用程序。
树形图中显示的记录类型取决于配置的复杂程度：
+ 在简单的配置中，您的图表不会包含任何别名记录，或者别名记录会将流量直接路由到 ELB 负载均衡器等资源，而不是路由到另一 Route 53 记录。有关更多信息，请参阅 [简单 Amazon Route 53 配置中的运行状况检查的工作原理简单配置中的运行状况检查的工作原理](dns-failover-simple-configs.md)。
+ 在复杂配置中，您的图表将在多级树中包含别名记录 (如加权别名和故障转移别名) 和非别名记录的组合，如[复杂 Amazon Route 53 配置中的运行状况检查的工作原理复杂配置中的运行状况检查的工作原理](dns-failover-complex-configs.md)主题中的示例。
**注意**
要快速轻松地为复杂路由配置创建记录并将这些记录与运行状况检查关联，可以使用 Traffic Flow 可视化编辑器并将该配置保存为流量策略。然后，您可以将流量策略关联至同一托管区域或多个托管区域中的一个或多个域名 (例如 example.com) 或子域名 (例如 www.example.com)。此外，如果新配置无法正常工作，您还可以回滚更新。有关更多信息，请参阅 [使用 Traffic Flow 来路由 DNS 流量](traffic-flow.md)。
有关更多信息，请参阅以下文档：
+ [选择路由策略](routing-policy.md)
+ [在别名记录和非别名记录之间进行选择](resource-record-sets-choosing-alias-non-alias.md)
1. 对于不能为其创建别名记录的资源，如 Amazon EC2 服务器和数据中心中运行的电子邮件服务器，为其创建运行状况检查。您会将这些运行状况检查与您的非别名记录相关联。
有关更多信息，请参阅 [创建、更新和删除运行状况检查](health-checks-creating-deleting.md)。
1. 必要时配置路由器和防火墙规则，以使 Route 53 可向您在运行状况检查中指定的端点发送常规请求。有关更多信息，请参阅 [为 Amazon Route 53 运行状况检查配置路由器和防火墙规则为运行状况检查配置路由器和防火墙规则](dns-failover-router-firewall-rules.md)。
1. 在您的图表中创建所有非别名记录，并将您在第 2 步中创建的运行状况检查与相应的记录关联。
如果您要在不包含任何别名记录的配置中配置 DNS 故障转移，请跳过其余的任务。
1. 创建将流量路由到 AWS 资源（例如 ELB 负载均衡器和 CloudFront 分配）的别名记录。如果您希望 Route 53 在某一资源运行状况不佳时尝试该树的其它分支，请将每个别名记录的 **Evaluate Target Health**（评估目标运行状况）值均设置为 **Yes**（是）。（某些 AWS 资源不支持 E **valuate Targ** et Health。）
1. 从您在第 1 步中创建的树形图的底部开始，创建别名记录，将流量路由至在第 4 步和第 5 步中创建的记录。如果您希望 Route 53 在树的某一分支中所有非别名记录均运行状况不良时尝试该树的其它分支，请将每个别名记录的 **Evaluate Target Health**（评估目标运行状况）值均设置为 **Yes**（是）。
请记住，在创建对应的另一记录以前，不能创建将流量路由到这一记录的别名记录。
# 简单 Amazon Route 53 配置中的运行状况检查的工作原理
当有两个或更多资源执行相同功能 (例如用于 example.com 的两个或更多 Web 服务器) 时，可使用下列运行状况检查功能，将流量仅路由到运行状况良好的资源：
**检查 EC2 实例和其他资源的运行状况 (非别名记录)**
如果要将流量路由到无法为其创建别名记录的资源 (如 EC2 实例)，可为每个资源创建记录和运行状况检查。然后，将每个运行状况检查与适用的记录关联。运行状况检查会定期检查对应资源的运行状况，而且 Route 53 仅将流量路由到运行状况检查报告为运行状况良好的资源。
**评估 AWS 资源的运行状况（别名记录）**
如果您使用[别名记录](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/resource-record-sets-choosing-alias-non-alias.html)将流量路由到选定 AWS 资源（例如 ELB 负载均衡器），则可以配置 Route 53 来评估资源的运行状况，并仅将流量路由到运行状况良好的资源。在配置别名记录以评估一个资源的运行状况时，不需要为该资源创建运行状况检查。
下面将简单介绍一下，在简单配置中如何配置 Route 53 来检查资源的运行状况：
1. 确定希望 Route 53 监控其运行状况的资源。例如，您可能要监控所有响应对 example.com 的请求的 HTTP 服务器。
1. 对于不能为其创建别名记录的资源，如 EC2 实例或您自己的数据中心中运行的服务器，为其创建运行状况检查。您可以指定如何向资源发送健康检查请求：使用哪个协议（HTTP、HTTPS 或 TCP）、使用哪个 IP 地址和端口，以及用于运行 HTTP/HTTPS 状况检查的域名和路径。
**注意**
如果您正在使用的任何资源是可以为其创建别名记录的资源，如 ELB 负载均衡器，不要为这些资源创建运行状况检查。
常见配置是为每个资源创建一个运行状况检查，并对该运行状况检查端点使用与资源相同的 IP 地址。运行状况检查将请求发送到指定的 IP 地址。
**注意**
Route 53 不能检查 IP 地址为本地、私有、不可路由或多播范围的资源的运行状况。有关无法为其创建运行状况检查的 IP 地址的更多信息，请参阅 [RFC 5735 “特殊用途 IPv4 地址” 和 RFC 6598，“共享地址](https://datatracker.ietf.org/doc/html/rfc5735)[空间的 Iana 保留前缀 IPv4 ](https://datatracker.ietf.org/doc/html/rfc6598)”。
有关创建运行状况检查的更多信息，请参阅[创建、更新和删除运行状况检查](health-checks-creating-deleting.md)。
1. 您可能需要配置路由器和防火墙规则，以使 Route 53 可向您在运行状况检查中指定的端点发送常规请求。有关更多信息，请参阅 [为 Amazon Route 53 运行状况检查配置路由器和防火墙规则为运行状况检查配置路由器和防火墙规则](dns-failover-router-firewall-rules.md)。
1. 您可以为资源创建一组记录，例如一组加权记录。您可以组合使用别名和非别名记录，但它们都必须具有相同的 **Name** (名称)、**Type** (类型) 和 **Routing Policy** (路由策略)。
您如何配置 Route 53 来检查资源的运行状况取决于您是要创建别名记录还是非别名记录：
+ **别名记录** — 为 **Evaluate Target Health**（评估目标运行状况）指定 — **Yes**（是）。
+ **非别名记录** — 将您在第 2 步中创建的运行状况检查与对应记录关联。
完成后，您的配置将类似于以下图表，其中仅包含非别名记录：
![\[三个加权记录和对应的运行状况检查。\]](http://docs.aws.amazon.com/zh_cn/Route53/latest/DeveloperGuide/images/hc-weighted.png)
有关使用 Route 53 控制台创建记录的更多信息，请参阅 [通过使用 Amazon Route 53 控制台创建记录](resource-record-sets-creating.md)。
1. 如果您创建了运行状况检查，Route 53 会定期向端点发送运行状况检查请求；它在接收 DNS 查询时不执行运行状况检查。Route 53 会根据响应确定端点是否运行良好，并使用该信息来确定如何响应查询。有关更多信息，请参阅 [Amazon Route 53 如何确定运行状况检查是否正常Route 53 如何确定运行状况检查是否正常](dns-failover-determining-health-of-endpoints.md)。
Route 53 不会检查记录中所指定资源的运行状况，如在 example.com 的 A 记录中指定的 IP 地址。当您将运行状况检查与记录关联时，Route 53 将开始检查您在运行状况检查中所指定端点的运行状况。您还可以将 Route 53 配置为监控其他运行状况检查的运行状况或监控CloudWatch 警报的数据流。有关更多信息，请参阅 [Amazon Route 53 运行状况检查类型运行状况检查的类型](health-checks-types.md)。
当 Route 53 收到对 example.com 的查询时，将发生以下情况：
1. Route 53 根据路由策略选择记录。在这种情况下，它会根据权重来选择记录。
1. 它通过检查选定记录的运行状况检查的状态来确定该记录的当前运行状况。
1. 如果所选记录运行状况不佳，则 Route 53 会选择不同的记录。此时，将不考虑运行状况不佳的记录。
有关更多信息，请参阅 [Amazon Route 53 在已配置运行状况检查时如何选择记录Route 53 在已配置运行状况检查时如何选择记录](health-checks-how-route-53-chooses-records.md)。
1. 当 Route 53 发现运行状况良好的记录时，它会使用适用值 (如 A 记录中的 IP 地址) 来响应查询。
以下示例显示了一组加权记录，其中第三个记录的运行状况不佳。最初，Route 53 会根据所有三个记录的权重选择一个记录。如果第一次碰巧选择了运行状况不佳的记录，Route 53 会选择另一个记录，但这次将在计算中忽略第三个记录的权重：
+ 当 Route 53 最初从全部三个记录中进行选择时，在大约 20% 的时间内 (10/(10\$120\$120))，它会使用第一个记录来响应请求。
+ 当 Route 53 确定第三个记录运行状况不佳时，在大约 33% 的时间内 (10/(10\$120))，它将使用第一个记录来响应请求。
![\[三个加权记录和对应的运行状况检查。第三个运行状况检查运行状况不良，因此 Route 53 会认为关联记录的运行状况不良。\]](http://docs.aws.amazon.com/zh_cn/Route53/latest/DeveloperGuide/images/hc-weighted-failed-hc.png)
如果您在一组记录的一个或多个记录中省略运行状况检查，则 Route 53 无法确定对应资源的运行状况。Route 53 将这些记录视为运行良好。
![\[三个加权的记录，只有两个有运行状况检查。Route 53 始终认为第三个记录运行状况良好。\]](http://docs.aws.amazon.com/zh_cn/Route53/latest/DeveloperGuide/images/hc-weighted-missing-health-check.png)
# 复杂 Amazon Route 53 配置中的运行状况检查的工作原理
在复杂配置中检查资源运行状况的工作原理与简单配置中大致相同。但在复杂配置中，可以使用别名记录（如加权别名和故障转移别名）和非别名记录的组合来构建决策树，以使您能够更好地控制 Route 53 响应请求的方式。
例如，您可以使用延迟别名记录选择一个靠近用户的区域，并对每个区域内的两个或多个资源使用加权记录，以针对单个端点或可用区域的故障提供保护。下图演示了此配置。
![\[包含延迟别名记录和加权别名记录的 DNS 配置。\]](http://docs.aws.amazon.com/zh_cn/Route53/latest/DeveloperGuide/images/hc-latency-alias-weighted.png)
以下是如何配置 Amazon EC2 和 Route 53 的方式。让我们从树底部开始，因为这是您即将创建记录的顺序：
+ 您在 us-east-1 和 ap-southeast-2 这两个区域中分别有两个 EC2 实例。您希望 Route 53 根据 EC2 实例的运行状况决定是否将流量路由到其中，所以为每个实例创建运行状况检查。您可以配置为每个运行状况检查都会向对应实例的弹性 IP 地址发送运行状况检查请求。
Route 53 是一项全球服务，您无需指定要为其创建运行状况检查的区域。
+ 您希望根据实例类型将流量路由到每个区域中的两个实例，所以可为每个实例创建加权记录，并为每个记录指定权重。(您可以稍后更改权重，来更改路由到某个实例的流量。) 然后，将适用的运行状况检查与每个实例关联。
在创建记录时，可以使用 us-east-1-www.example.com 和 ap-southeast-2-www.example.com 这样的名称。只有等到了树顶端，您才可以为记录指定用户将用于访问网站或 Web 应用程序的名称 (例如 example.com)。
+ 您希望将流量路由到可为用户提供最低延迟的区域，因此为树顶端的记录选择延迟[路由策略](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/routing-policy.html)。
您希望将流量路由到每个区域中的*记录*，而不是直接路由到每个区域中的*资源* (加权记录已执行该功能)。因此，创建延迟[别名记录](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/resource-record-sets-choosing-alias-non-alias.html)。
在创建别名记录时，为它们指定用户将用于访问网站或 Web 应用程序的名称 (例如 example.com)。别名记录将 example.com 的流量路由到 us-east-1-www.example.com 和 ap-southeast-2-www.example.com 记录。
对于两个延迟别名记录，将 **Evaluate Target Health** 的值设置为 **Yes**。这会让 Route 53 去确定一个区域中是否存在任何运行状况良好的资源，然后再尝试将流量路由到对应区域。如果没有，Route 53 会选择其它区域中正常运行的资源。
![\[包含延迟别名记录和加权别名记录的 DNS 配置。\]](http://docs.aws.amazon.com/zh_cn/Route53/latest/DeveloperGuide/images/hc-latency-alias-weighted-both-failed.png)
前面的图表说明了以下事件序列：
1. Route 53 收到针对 example.com 的查询。根据用户提出请求的延迟，Route 53 为 us-east-1 区域选择延迟别名记录。
1. Route 53 根据权重选择加权记录。延迟别名记录的 **Evaluate Target Health**（评估目标运行状况）为 **Yes**（是），因此 Route 53 将检查选定的加权记录的运行状况。
1. 运行状况检查失败，因此 Route 53 根据权重选择其它加权记录并检查其运行状况。该记录的运行状况也不佳。
1. Route 53 退出该树的分支，查找其延迟仅次于最佳的延迟别名记录，并为 ap-southeast-2 选择该记录。
1. Route 53 根据权重再次选择记录，然后检查所选资源的运行状况。假定该资源运行状况良好，则 Route 53 在对查询的响应中返回适用的值。
**Topics**
+ [在将运行状况检查与别名记录关联时会发生什么？](#dns-failover-complex-configs-hc-alias)
+ [忽略运行状况检查时，会出现什么情况？](#dns-failover-complex-configs-hc-omitting)
+ [当您将“Evaluate Target Health”设置为“No”时，会出现什么情况？](#dns-failover-complex-configs-eth-no)
## 在将运行状况检查与别名记录关联时会发生什么？
您可以将运行状况检查与别名记录相关联，以作为将 **Evaluate Target Health** 的值设置为 **Yes** 的替代或补充。但是，如果 Route 53 根据基础资源 (HTTP 服务器、数据库服务器和您的别名记录引用的其它资源) 的运行状况来响应查询，这样关联通常更有用。例如，假设以下配置：
+ 将运行状况检查分配给其别名目标为一组加权记录的延迟别名记录。
+ 将延迟别名记录的 **Evaluate Target Health** 值设置为 **Yes**。
在此配置中，必须同时满足以下两个条件，Route 53 才会为加权记录返回适用值：
+ 必须通过与延迟别名记录关联的运行状况检查。
+ 必须至少有一个加权记录因为与已通过的运行状况检查关联或因为不与运行状况检查相关联而被视为运行状况良好。在后一种情况下，Route 53 始终认为加权记录运行状况良好。
在下图中，左上角的延迟别名记录的运行状况检查失败。因此，Route 53 停止响应那些使用该延迟别名记录所引用的任何加权记录的查询，即使这些记录的运行状况良好也同样如此。仅在延迟别名记录恢复良好的运行状况时，Route 53 才会再次开始考虑这些加权记录。(有关例外情况，请参阅[Amazon Route 53 在已配置运行状况检查时如何选择记录Route 53 在已配置运行状况检查时如何选择记录](health-checks-how-route-53-chooses-records.md)。)
![\[包含“评估目标运行状况”设置为“是”且具有运行状况检查的别名记录的 DNS 配置。\]](http://docs.aws.amazon.com/zh_cn/Route53/latest/DeveloperGuide/images/hc-latency-alias-weighted-alias-hc-failed.png)
## 忽略运行状况检查时，会出现什么情况？
在复杂配置中，应将运行状况检查与所有非别名记录关联，这一点非常重要。在下面的示例中，us-east-1 区域的一个加权记录中缺少运行状况检查。
![\[包含一个失败运行状况检查和一个没有运行状况检查的记录的 DNS 配置。\]](http://docs.aws.amazon.com/zh_cn/Route53/latest/DeveloperGuide/images/hc-latency-alias-weighted-missing-health-check.png)
在此配置中，当您忽略对非别名记录的运行状况检查时，将发生以下情况：
1. Route 53 收到针对 example.com 的查询。根据用户提出请求的延迟，Route 53 为 us-east-1 区域选择延迟别名记录。
1. Route 53 为延迟别名记录查找别名目标，并检查相应运行状况检查的状态。一个加权记录的运行状况检查失败，因此不考虑该记录。
1. 用于 us-east-1 区域的别名目标中的其他加权记录没有运行状况检查。相应的资源可能运行状况良好或运行状况不佳，但没有运行状况检查，Route 53 无法了解真实情况。Route 53 假定该资源运行状况良好，并在对查询的响应中返回相应的值。
## 当您将“Evaluate Target Health”设置为“No”时，会出现什么情况？
通常，应该为树中所有别名记录将 **Evaluate Target Health** (评估目标运行状况) 设置为 **Yes** (是)。如果将 **Evaluate Target Health**（评估目标运行状况）设置为 **No**（否），Route 53 会继续将流量路由到别名记录引用的记录，即使这些记录未通过运行状况检查。
在以下示例中，所有加权记录都有关联的运行状况检查，但对于 us-east-1 区域的延迟别名记录，则将 **Evaluate Target Health** (评估目标运行状况) 设置为 **No** (否)：
![\[包含“评估目标运行状况”设置为“否”的别名记录的 DNS 配置。\]](http://docs.aws.amazon.com/zh_cn/Route53/latest/DeveloperGuide/images/hc-latency-alias-weighted-eth-is-no.png)
在此配置中，当您将别名记录的 **Evaluate Target Health** 设置为 **No** 时，将出现以下情况：
1. Route 53 收到针对 example.com 的查询。根据用户提出请求的延迟，Route 53 为 us-east-1 区域选择延迟别名记录。
1. Route 53 确定用于延迟别名记录的别名目标，并检查相应运行状况检查。两项检查都失败。
1. 由于用于 us-east-1 区域中的延迟别名记录的 **Evaluate Target Health**（评估目标运行状况）值为 **No**（否），Route 53 必须在此分支中选择一个记录，而不是忽略该分支并在 ap-southeast-2 区域中查找运行状况良好的记录。
# Amazon Route 53 在已配置运行状况检查时如何选择记录
如果您配置了为具有相同名称、相同类型 (A 或 AAAA) 和相同路由策略 (如加权或故障转移) 的一组记录中的所有记录进行运行状况检查，则 Route 53 会选择运行良好的记录并返回该记录中的适用值，以响应 DNS 查询。
例如，假设您创建三个加权 A 记录，并且为所有三个记录分配运行状况检查。如果其中一个记录的运行状况检查结果是运行状况不良，则 Route 53 会使用另外两个记录之一中的 IP 地址响应 DNS 查询。
Route 53 使用以下方法来选择运行状况良好的记录：
1. Route 53 最初根据路由策略和您为每个记录指定的值来选择记录。例如，对于加权记录，Route 53 会根据您为每个记录指定的权重选择记录。
1. Route 53 会确定记录是否运行状况良好：
+ **关联运行状况检查的非别名记录** — 如果将运行状况检查与非别名记录关联，Route 53 会检查运行状况检查的当前状态。
Route 53 会定期检查在运行状况检查中指定的端点的运行状况；当 DNS 查询到达时，它不会执行运行状况检查。
您可以将运行状况检查与别名记录关联，但我们建议您仅将运行状况检查与非别名记录关联。有关更多信息，请参阅 [在将运行状况检查与别名记录关联时会发生什么？](dns-failover-complex-configs.md#dns-failover-complex-configs-hc-alias)。
+ **“评估目标运行状况”设置为“是”**的别名记录 — Route 53 会检查别名记录所引用资源（例如，ELB 负载均衡器或同一托管区域中的另一记录）的运行状况。
1. 如果记录的运行状况良好，Route 53 将使用适用值（如 IP 地址）响应查询。
如果记录运行状况不良，则 Route 53 会使用相同标准选择另一记录并重复上述流程，直到找到一个运行状况良好的记录。
Route 53 将使用以下标准选择记录：
**不带运行状况检查的记录始终是运行状况良好的记录**
如果具有相同名称和类型的一组记录中的某个记录没有关联的运行状况检查，Route 53 将始终认为其运行状况良好，并始终将其包含在可用的响应查询中。
**如果没有运行状况良好的记录，则认为所有记录均为运行状况良好**
如果一组记录中所有记录的运行状况均不良，而 Route 53 需要返回一些内容以响应 DNS 查询，但它没有了选择记录的标准。在这种情况下，Route 53 将认为该组中所有记录的运行状况都良好，并根据路由策略和为每个记录指定的值选择记录。
**权重为 0 的加权记录**
如果为一组加权记录中的所有记录添加运行状况检查，但为部分记录指定非零权重并为其他记录指定零权重，那么运行状况检查会按照所有记录均具有非零权重的情况进行，但下列情况除外：
+ Route 53 最初仅考虑非零加权记录（如果有）。
+ 如果权重大于 0 的所有记录的运行状况都不良，Route 53 会考虑零权重的记录。
由于 Route 53 在某些情况下会考虑零加权记录，因此务必确保零加权目标对 DNS 查询也有可行的答案。
有关加权记录的更多信息，请参阅 [运行状况检查和加权路由](routing-policy-weighted.md#routing-policy-weighted-healthchecks)。
**别名记录**
还可以为每个别名记录将 **Evaluate Target Health** (评估目标运行状况) 设置为 **Yes** (是)，为别名记录配置运行状况检查。此时，Route 53 会评估记录将流量路由到其中的资源 (例如，ELB 负载均衡器或同一托管区域中的另一记录) 的运行状况。
例如，假设别名记录的别名目标是一组全部具有非零权重的加权记录：
+ 只要至少有一个加权记录的运行状况良好，Route 53 便认为该别名记录运行状况良好。
+ 如果所有加权记录的运行状况都不良，Route 53 将认为该别名记录运行状况不良。
+ Route 53 将不再考虑该树分支中的记录，直到至少有一个加权记录再次变为正常状态。
有关更多信息，请参阅 [复杂 Amazon Route 53 配置中的运行状况检查的工作原理复杂配置中的运行状况检查的工作原理](dns-failover-complex-configs.md)。
**故障转移记录**
故障转移记录的工作方式通常和其他路由类型相同。您可以创建运行状况检查并将其与非别名记录关联，然后将别名记录的 **Evaluate Target Health** (评估目标运行状况) 设置为 **Yes** (是)。注意以下几点：
+ 主记录和辅助记录都可以是非别名记录或者别名记录。
+ 如果您将运行状况检查与主和辅助故障转移记录关联，下面是 Route 53 响应请求的方式：
+ 如果 Route 53 认为主记录运行状况良好（如果运行状况检查端点的运行状况良好），Route 53 将只返回主记录来响应 DNS 查询。
+ 如果 Route 53 认为主记录运行状况不佳，辅助记录运行状况良好，Route 53 将改为返回辅助记录。
+ 如果 Route 53 认为主和辅助记录的运行状况都不佳，Route 53 将返回主记录。
+ 在配置辅助记录时，可添加运行状况检查，也可不添加。如果您省略用于辅助记录的运行状况检查，并且主记录的运行状况检查端点运行状况不佳，则 Route 53 始终使用辅助记录来响应 DNS 查询。即使辅助记录运行状况不良时也是如此。
有关更多信息，请参阅以下主题：
+ [使用一个主资源和一个辅助资源配置主动/被动故障转移](dns-failover-types.md#dns-failover-types-active-passive-one-resource)
+ [使用多个主资源和多个辅助资源配置主动/被动故障转移](dns-failover-types.md#dns-failover-types-active-passive-multiple-resources)
# 主动/主动和主动/被动故障转移
可以使用 Route 53 运行状况检查来配置双活和主动/被动的故障转移配置。您可以使用故障转移以外的任何[路由策略](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/routing-policy.html) (或路由策略组合) 配置主动/被动故障转移，并使用故障转移路由策略配置主动/被动故障转移。
**Topics**
+ [主动/主动故障转移](#dns-failover-types-active-active)
+ [主动/被动故障转移](#dns-failover-types-active-passive)
## 主动/主动故障转移
如果您希望所有资源在大部分时间内都可用，可使用此故障转移配置。当某个资源不可用时，Route 53 可以检测到它运行状况不佳并且停止在响应查询时包含该资源。
在双活故障转移中，具有相同名称、相同类型（例如 A 或 AAAA）和相同路由策略（如加权或延迟）的所有记录处于活动状态，除非 Route 53 认为它们运行状况不良。Route 53 可以使用任何运行状况良好的记录响应 DNS 查询。
## 主动/被动故障转移
如果您希望主资源或资源组在大部分时间内可用，同时希望辅助资源或资源组处于备用状态以防所有主资源均不可用，可使用主动/被动故障转移配置。响应查询时，Route 53 将只包含运行状况良好的主资源。如果所有主资源的运行状况都不佳，Route 53 将只在 DNS 查询的响应中包含运行状况良好的辅助资源。
**Topics**
+ [使用一个主资源和一个辅助资源配置主动/被动故障转移](#dns-failover-types-active-passive-one-resource)
+ [使用多个主资源和多个辅助资源配置主动/被动故障转移](#dns-failover-types-active-passive-multiple-resources)
+ [使用加权记录配置主动/被动故障转移](#dns-failover-types-active-passive-weighted)
### 使用一个主资源和一个辅助资源配置主动/被动故障转移
要使用一个主记录和一个辅助记录创建主动/被动故障转移配置，只需创建相应记录并指定 **Failover** (故障转移) 作为路由策略。当主资源运行状况良好时，Route 53 使用主记录响应 DNS 查询。当主资源运行状况不良时，Route 53 使用辅助记录响应 DNS 查询。
### 使用多个主资源和多个辅助资源配置主动/被动故障转移
您还可以将多个资源与主记录和/或辅助记录关联。在使用该配置时，只要有至少一个关联资源的运行状况良好，Route 53 便认为主故障转移记录的运行状况良好。有关更多信息，请参阅 [Amazon Route 53 在已配置运行状况检查时如何选择记录Route 53 在已配置运行状况检查时如何选择记录](health-checks-how-route-53-chooses-records.md)。
要使用多个资源为主记录或辅助记录配置主动/被动故障转移，请执行以下任务。
1. 为要将流量路由到其中的每个资源 (例如 EC2 实例或您数据中心中的 Web 服务器) 创建运行状况检查。
**注意**
如果您要将流量路由到可以为其创建[别名记录](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/resource-record-sets-choosing-alias-non-alias.html)的任何 AWS 资源，请不要为这些资源创建运行状况检查。在创建别名记录时，改为将 **Evaluate Target Health** (评估目标运行状况) 设置为 **Yes** (是)。
有关更多信息，请参阅 [创建和更新运行状况检查](health-checks-creating.md)。
1. 为主资源创建记录，并指定以下值：
+ 为每个记录指定相同的名称、类型和路由策略。例如，您可以创建三个都名为 failover-primary.example.com 的 A 加权记录。
+ 如果您正在使用可以为其创建别名记录的 AWS 资源，请将 “**评估目标健康状况” 指定为 “**是**”。**
如果您要使用不能为其创建别名记录的资源，请将第 1 步中的适用运行状况检查与每个记录关联。
有关更多信息，请参阅 [通过使用 Amazon Route 53 控制台创建记录](resource-record-sets-creating.md)。
1. 如果适合，则为辅助资源创建记录，并指定以下值：
+ 为每个记录指定相同的名称、类型和路由策略。例如，您可以创建三个都名为 failover-secondary.example.com 的 A 加权记录。
+ 如果您正在使用可以为其创建别名记录的 AWS 资源，请将 “**评估目标健康状况” 指定为 “**是**”。**
如果您要使用不能为其创建别名记录的资源，请将第 1 步中的适用运行状况检查与每个记录关联。
**注意**
有些客户使用 Web 服务器作为其主资源，并将配置为网站端点的 Amazon S3 存储桶作为辅助资源。S3 存储桶包含简单的“暂时不可用”消息。如果您使用该配置，可以跳过此步骤，只需为第 4 步中的辅助资源创建一个故障转移别名记录。
1. 创建一主一辅的两个故障转移别名记录，并指定以下值：
**主记录**
+ **名称** — 指定希望 Route 53 用于路由流量的域名 (example.com) 或子域名 (www.example.com)。
+ **别名** — 指定 **Yes**（是）。
+ **别名目标** — 指定您在第 2 步中创建的记录的名称。
+ **路由策略** — 指定 **Failover**（故障转移）。
+ **故障转移记录类型** — 指定 **Primary**（主副本）。
+ **评估目标运行状况** — 指定 **Yes**（是）。
+ **与运行状况检查关联** — 指定 **No**（否）。
**辅助记录**
+ **名称** — 指定为主记录指定的相同名称。
+ **别名** — 指定 **Yes**（是）。
+ **别名目标** — 如果为您在第 3 步中创建的辅助资源创建了记录，请指定对应记录的名称。如果您使用 Amazon S3 存储桶作为辅助资源，请指定网站端点的 DNS 名称。
+ **路由策略** — 指定 **Failover**（故障转移）。
+ **故障转移记录类型** — 指定 **Secondary**（辅助）。
+ **评估目标运行状况** — 指定 **Yes**（是）。
+ **与运行状况检查关联** — 指定 **No**（否）。
### 使用加权记录配置主动/被动故障转移
您还可以使用加权记录实现主动/被动故障转移，但需注意以下事项。如果为部分记录指定非零权重，为其它记录指定零权重，则 Route 53 仅使用具有非零权重且运行状况良好的记录响应 DNS 查询。如果权重大于 0 的所有记录的运行状况都不良，则 Route 53 将使用零权重记录响应查询。
**注意**
具有非零权重的所有记录都必须处于运行状况不良的状态，然后 Route 53 才能开始使用零权重的记录响应 DNS 查询。在所有其他资源不可用，且最后一个运行状况良好的资源 (如 Web 服务器) 无法处理所有流量时，会导致您的 Web 应用程序或网站不可靠。
# 在私有托管区域中配置故障转移
如果要在私有托管区域中创建故障转移记录，请注意以下几点：
+ Route 53 运行状况检查程序在 VPC 外部。要通过 IP 地址检查 VPC 中端点的运行状况，您必须为 VPC 中的实例分配公有 IP 地址。
+ 您可以创建 CloudWatch 指标，将警报与该指标相关联，然后根据警报的数据流创建运行状况检查。例如，您可以创建一个检查 EC2 CloudWatch 指标状态的指标，向该`StatusCheckFailed`指标添加警报，然后根据警报的数据流创建运行状况检查，以检查虚拟私有云 (VPC) Virtual Cloud (VPC) 中只有私有 IP 地址的实例。有关使用 CloudWatch 控制台创建 CloudWatch 指标和警报的信息，请参阅 [Amazon CloudWatch 用户指南](https://docs.aws.amazon.com/AmazonCloudWatch/latest/DeveloperGuide/)。
有关更多信息，请参阅[使用私有托管区](hosted-zones-private.md)和[使用监控运行状况检查 CloudWatch](monitoring-health-checks.md)。
# Amazon Route 53 如何避免故障转移问题
Route 53 实施的故障转移算法不仅用于将流量路由到正常运行的端点，还用于避免使灾难情况因错误配置的运行状况检查和应用程序、端点超载和分区故障而变得更严重。
**Topics**
+ [Amazon Route 53 如何避免级联故障](#dns-failover-cascading-failures)
+ [Amazon Route 53 如何处理互联网分区](#dns-failover-internet-partitions)
## Amazon Route 53 如何避免级联故障
作为抵御级联故障的第一道防线，每个请求路由算法 (如加权和故障转移) 都有在万不得已的情况下采用的模式。在此特殊模式下，当所有记录都被视为运行状况不佳时，Route 53 算法将重新认为所有记录均运行良好。
例如，如果某个应用程序在多个主机上的所有实例都拒绝运行状况检查请求，Route 53 DNS 服务器无论如何都会选择一个回复，而不是不返回任何 DNS 回复或返回 NXDOMAIN（不存在的域）响应。应用程序可以响应用户，但仍无法通过运行状况检查，因此这可针对配置错误提供一些保护。
同样，如果应用程序超载并且三个端点中的一个未能通过运行状况检查，使其无法进行 Route 53 DNS 响应，Route 53 将会在其余两个端点之间分配响应。如果其余的端点无法处理额外负载并且失败，Route 53 将恢复为向全部三个端点分发请求。
## Amazon Route 53 如何处理互联网分区
尽管并不常见，但有时确实存在重要的 Internet 分区，这意味着大型地理区域之间无法通过 Internet 进行通信。在这些分区期间，Route 53 位置可能会对终端节点的运行状况得出不同的结论，并且可能与报告的状态不同 CloudWatch。每个 AWS 区域的 Route 53 健康检查员不断向所有 Route 53 地点发送健康检查状态。在互联网分区中，每个 Route 53 位置可能只能访问其中的部分状态，通常来自与其距离最近的区域。
例如，在会影响与南美洲之间双向连接的互联网分区中，Route 53 南美洲（圣保罗）位置中的 Route 53 DNS 服务器可能能够正常访问南美洲（圣保罗） AWS 区域中的运行状况检查端点，但却无法访问其它端点。同时，美国东部（俄亥俄）中的 Route 53 可能无法访问南美洲（圣保罗）区域中的运行状况检查端点，并得出相应的记录运行状况不佳的结论。
对于此类分区，Route 53 位置更容易根据端点的本地可见性得出有关端点运行状况的不同结论。因此，当只有一部分可访问的运行状况检查程序认为端点运行正常时，每个 Route 53 位置都认为该端点运行正常。