从阅读中可以看出，似乎不建议使用 DNS 故障转移，因为 DNS 不是为此设计的。但是，如果您在不同的子网上有两个托管冗余内容的 Web 服务器，那么如果一个服务器发生故障，还有哪些其他方法可以确保所有流量都路由到实时服务器？
在我看来，DNS故障转移似乎是这里唯一的故障转移选项，但大家一致认为这不是一个好选择。然而，DNSmadeeasy.com等服务提供了它，所以它一定有优点。有什么意见吗？
答案1
我认为您所说的“DNS 故障转移”是指 DNS 循环与一些监控相结合，即为 DNS 主机名发布多个 IP 地址，并在监控检测到服务器宕机时删除无效地址。这对于流量较少的小型网站来说是可行的。
根据设计，当您回答 DNS 请求时，您还会为发出的响应提供生存时间 (TTL)。换句话说，您告诉其他 DNS 服务器和缓存“您可以存储此答案并在 x 分钟内使用它，然后再与我核对”。缺点在于：
- 使用 DNS 故障转移时，未知比例的用户将缓存您的 DNS 数据，且剩余的 TTL 量各不相同。在 TTL 到期之前，这些用户可能会连接到死机服务器。还有比这更快的方法来完成故障转移。
- 由于上述原因，您倾向于将 TTL 设置为相当低的水平，例如 5-10 分钟。但将其设置得更高会带来（非常小的）性能优势，并且可能有助于您的 DNS 传播可靠地工作，即使网络流量出现短暂故障也是如此。因此，使用基于 DNS 的故障转移与高 TTL 相悖，但高 TTL 是 DNS 的一部分并且很有用。
获得良好正常运行时间的更常见方法包括：
- 将服务器放在同一个局域网上。
- 将 LAN 放置在具有高可用性电源和网络平面的数据中心。
- 使用 HTTP 负载平衡器来分散负载并在单个服务器发生故障时进行故障转移。
- 获取防火墙、负载平衡器和交换机所需的冗余级别/预期正常运行时间。
- 制定针对整个数据中心故障以及交换机/数据库服务器/其他不易镜像的资源偶尔发生的故障的通信策略。
极少数网站使用多数据中心设置，并在数据中心之间进行“地理平衡”。
答案2
DNS 故障转移确实很有效。多年来，我一直使用它来手动转移数据中心之间的流量，或者在监控系统检测到中断、连接问题或服务器过载时自动转移流量。当您看到它的工作速度以及可以轻松转移的实际流量量时，您就再也不会后悔了。我使用 Zabbix 监控我的所有系统，显示 DNS 故障转移情况的可视化图表消除了我所有的疑虑。可能有一些 ISP 会忽略 TTL，也有一些用户仍在使用旧浏览器 - 但是当您查看来自 2 个数据中心位置每天数百万页面浏览量的流量并进行 DNS 流量转移时 - 忽略 TTL 的剩余流量是可笑的。DNS 故障转移是一种可靠的技术。
DNS 并非为故障转移而设计 - 但它设计了 TTL，当与可靠的监控系统结合时，TTL 可以出色地满足故障转移需求。TTL 可以设置得很短。我在生产中有效地使用了 5 秒的 TTL，以实现基于 DNS 故障转移的快速解决方案。您必须拥有能够处理额外负载的 DNS 服务器 - 而命名服务器无法满足这一要求。但是，当在冗余名称服务器上使用 mysql 复制数据库时，powerdns 符合要求。您还需要一个可靠的分布式监控系统，您可以信赖该系统进行自动故障转移集成。Zabbix 对我来说很有用 - 我可以几乎立即验证来自多个分布式 Zabbix 系统的中断 - 动态更新 powerdns 使用的 mysql 记录 - 并在中断和流量高峰期间提供几乎即时的故障转移。
但是嘿，我创建了一家提供 DNS 故障转移服务的公司，多年来一直为大型公司提供服务。所以对我的意见持保留态度。如果您想在停机期间查看一些高流量站点的 zabbix 流量图 - 亲自了解 DNS 故障转移的工作原理 - 请给我发电子邮件，我非常乐意与您分享。
答案3
DNS 故障转移的问题在于，在许多情况下，它不可靠。一些 ISP 会忽略您的 TTL，即使他们尊重您的 TTL，也不会立即发生这种情况，并且当您的网站恢复时，如果用户的 DNS 缓存超时，它可能会导致会话出现一些异常，最终他们会转向其他服务器。
不幸的是，这几乎是唯一的选择，除非你的规模足够大，可以进行自己的（外部）路由。
答案4
多年来，我一直在一个流量适中但业务至关重要的生产网站（跨两个地区）上运行 DNS RR 故障转移。
它运行良好，但至少有三个微妙之处是我从惨痛经历中学到的。
1) 如果客户端可用的缓存 DNS 中两个 IP 均处于活动状态，则浏览器将在 30 秒后从非工作 IP 故障转移到工作 IP（我上次检查时）。这基本上是一件好事。
但是让“一半”的用户等待 30 秒是不可接受的，因此您可能希望将 TTL 记录更新为几分钟，而不是几天或几周，以便在发生中断时，您可以快速从 DNS 中删除停机服务器。其他人在他们的回复中提到了这一点。
2) 如果为循环域提供服务的其中一个名称服务器（或两个地理位置中的一个）发生故障，并且其中的主要服务器发生故障，我依稀记得，如果您没有将名称服务器的 SOA TTL/到期时间设置为足够低的值，那么在尝试从 DNS 中删除该已停机的名称服务器时，您可能会遇到其他问题。我在这里可能记错了技术细节，但要真正防范单点故障，您需要正确设置的 TTL 不止一个。
3) 如果您发布 Web API、REST 服务等，这些通常不会被浏览器调用，因此在我看来，DNS 故障转移开始显示出真正的缺陷。这可能就是为什么有人说“不推荐”。这就是我这么说的原因。首先，使用这些 URL 的应用程序通常不是浏览器，因此它们缺乏常见浏览器的 30 秒故障转移属性/逻辑。其次，是否调用第二个 DNS 条目甚至重新轮询 DNS 在很大程度上取决于这些 API/REST 客户端使用的编程语言中的网络库的低级编程细节，以及 API/REST 客户端应用程序如何调用它们。（在它们的覆盖范围内，库是否调用 get_addr，什么时候调用？如果套接字挂起或关闭，应用程序是否会重新打开新的套接字？是否有某种超时逻辑？等等）
它价格便宜，经过充分测试，并且“基本有效”。因此，与大多数事物一样，您的里程可能会有所不同。