为什么不推荐 DNS 故障转移？

Question

从阅读来看，似乎不推荐 DNS 故障转移，因为 DNS 不是为它设计的。但是，如果您在不同子网上有两个 Web 服务器托管冗余内容，那么还有哪些其他方法可以确保在一台服务器出现故障时将所有流量路由到实时服务器？

对我来说，似乎 DNS 故障转移是这里唯一的故障转移选项，但共识是这不是一个好的选择。然而像 DNSmadeeasy.com 这样的服务提供了它，所以它一定有它的优点。任何意见？

Answer 1

我认为“DNS 故障转移”是指 DNS 循环与一些监控相结合，即为 DNS 主机名发布多个 IP 地址，并在监控检测到服务器关闭时删除死地址。这对于小型的、流量较少的网站是可行的。

按照设计，当您回答 DNS 请求时，您还会为您发出的响应提供生存时间 (TTL)。换句话说，您告诉其他 DNS 服务器和缓存“您可以存储此答案并使用它 x 分钟，然后再与我联系”。缺点来自于此：

• 通过 DNS 故障转移，未知百分比的用户将缓存您的 DNS 数据，并保留不同数量的 TTL。在 TTL 到期之前，这些可能会连接到死服务器。有比这更快的完成故障转移的方法。
• 由于上述原因，您倾向于将 TTL 设置得非常低，比如 5-10 分钟。但是将其设置得更高会带来（非常小的）性能优势，并且即使网络流量出现短时故障，也可以帮助您的 DNS 传播可靠地工作。因此，使用基于 DNS 的故障转移与高 TTL 背道而驰，但高 TTL 是 DNS 的一部分并且很有用。

获得良好正常运行时间的更常见方法包括：

• 将服务器放在同一个 LAN 上。
• 将 LAN 置于具有高可用电源和网络平面的数据中心。
• 使用 HTTP 负载平衡器在单个服务器故障时分散负载和故障转移。
• 获得防火墙、负载平衡器和交换机所需的冗余级别/预期正常运行时间。
• 为整个数据中心的故障以及交换机/数据库服务器/其他不容易镜像的偶尔故障制定通信策略。

极少数网站使用多数据中心设置，并在数据中心之间进行“地理平衡”。

Answer 2

DNS 故障转移绝对有效。多年来，我一直使用它在数据中心之间手动转移流量，或者在监控系统检测到中断、连接问题或服务器过载时自动转移。当您看到它的工作速度以及可以轻松转移的现实世界流量时 - 您将永远不会回头。我使用 Zabbix 来监控我的所有系统，显示 DNS 故障转移期间发生的情况的可视化图表消除了我所有的疑虑。可能有一些 ISP 会忽略 TTL，还有一些用户仍然使用旧浏览器 - 但是当您查看来自 2 个数据中心位置的每天数百万次页面浏览的流量并且您进行 DNS 流量转移时 -忽略 TTL 的剩余流量是可笑的。

DNS 不是为故障转移而设计的——但它是为 TTL 设计的，当与可靠的监控系统相结合时，它可以很好地满足故障转移的需求。TTL 可以设置得非常短。我在生产中有效地使用了 5 秒的 TTL，以减轻基于 DNS 故障转移的快速解决方案。您必须拥有能够处理额外负载的 DNS 服务器 - 而命名不会减少它。但是，powerdns 在冗余名称服务器上以 mysql 复制数据库为后盾时符合要求。您还需要一个可靠的分布式监控系统来实现自动故障转移集成。Zabbix 对我有用——我几乎可以立即验证多个分布式 Zabbix 系统的中断——动态更新 powerdns 使用的 mysql 记录——并在中断和流量高峰期间提供几乎即时的故障转移。

但是，嘿 - 我建立了一家提供 DNS 故障转移服务的公司，经过多年为大公司提供服务。因此，请保留我的意见。如果您想在中断期间查看一些高容量站点的 zabbix 流量图 - 亲自了解 DNS 故障转移的效果如何 - 给我发电子邮件，我非常乐意与您分享。

Answer 3

DNS 故障转移的问题在于它在许多情况下不可靠。一些 ISP 会忽略您的 TTL，即使他们确实尊重您的 TTL，也不会立即发生，并且当您的站点恢复时，当用户的 DNS 缓存超时时，可能会导致会话出现一些奇怪的情况，并且最终会导致会话异常到另一台服务器。

不幸的是，这几乎是唯一的选择，除非您足够大以进行自己的（外部）路由。

Answer 4

普遍的观点是，使用 DNS RR，当 IP 出现故障时，一些客户端将继续使用损坏的 IP 数分钟。这在之前对该问题的一些答案中有所说明，并且也写在维基百科上。

反正，

http://crypto.stanford.edu/dns/dns-rebinding.pdf解释说，对于当前的大多数 HTML 浏览器而言，情况并非如此。他们将在几秒钟内尝试下一个 IP。

http://www.tenereillo.com/GSLBPageOfShame.htm似乎更强大：

使用多个 A 记录不是交易技巧，也不是负载平衡设备供应商设想的功能。出于这个原因，DNS 协议被设计为支持多个 A 记录。浏览器、代理和邮件服务器等应用程序使用 DNS 协议的这一部分。

也许一些专家可以评论并更清楚地解释为什么 DNS RR 不利于高可用性。

谢谢，

华伦天奴

PS：抱歉链接失效，但作为新用户，我不能发布超过 1 个

Answer 5

多年来，我在一个流量适中但业务关键的网站（跨两个地区）上运行 DNS RR 故障转移。

它工作正常，但至少有三个微妙之处我是通过艰难的方式学到的。

1) 浏览器将在 30 秒（我上次检查）后从非工作 IP 故障转移到工作 IP，如果两者在您的客户端可用的任何缓存 DNS 中都被认为是活动的。这基本上是一件好事。

但是让“一半”的用户等待 30 秒是不可接受的，因此您可能希望将 TTL 记录更新为几分钟，而不是几天或几周，以便在出现中断的情况下，您可以快速删除关闭的服务器从您的 DNS。其他人在他们的回答中也提到了这一点。

2）如果您的域名服务器之一（或您的两个地理区域之一）出现故障，该服务器正在为您的循环域提供服务，并且如果其中的主要域名服务器出现故障，我依稀记得您可能会遇到其他问题试图删除它如果您还没有将名称服务器的 SOA TTL/到期时间设置为足够低的值，则从 DNS 关闭名称服务器。我可能在这里弄错了技术细节，但要真正抵御单点故障，您需要正确设置的 TTL 设置不止一个。

3) 如果您发布 Web API、REST 服务等，这些通常不会被浏览器调用，因此在我看来，DNS 故障转移开始显示出真正的缺陷。这可能就是为什么有人说，正如你所说的“不推荐”。这就是我这么说的原因。首先，使用这些 URL 的应用程序通常不是浏览器，因此它们缺乏常见浏览器的 30 秒故障转移属性/逻辑。其次，是否调用第二个 DNS 条目甚至重新轮询 DNS 在很大程度上取决于这些 API/REST 客户端使用的编程语言中的网络库的低级编程细节，以及它们如何被调用API/REST 客户端应用程序。（在它们的覆盖下，库是否调用 get_addr，何时调用？如果套接字挂起或关闭，应用程序是否重新打开新的套接字？是否有某种超时逻辑？等等）

它很便宜，经过了良好的测试，并且“主要是有效的”。因此，与大多数事情一样，您的里程可能会有所不同。

Answer 6

有很多人使用我们 (Dyn) 进行故障转移。这与站点可以在停机时创建状态页面的原因相同（想想 Twitter 的失败鲸鱼之类的事情）……或者只是根据 TTL 重新路由流量。有些人可能认为 DNS 故障转移是贫民窟……但我们从一开始就认真设计了具有故障转移功能的网络……因此它可以像硬件一样工作。我不确定 DME 是如何做到的，但我们有 17 个最近的任播 PoP 中有 3 个从最近的位置监视您的服务器。当它从三个中的两个检测到它关闭时，我们只需将流量重新路由到另一个 IP。唯一的停机时间是那些在该 TTL 间隔的剩余时间内请求的停机时间。

有些人喜欢同时使用两台服务器......在这种情况下可以做一些类似循环负载平衡的事情......或基于地理的负载平衡。对于那些真正关心性能的人...我们的实时流量管理器将监控每台服务器...如果一个服务器速度较慢...根据您在主机名中链接的 IP，将流量重新路由到最快的服务器。再次...这基于您在我们的 UI/API/Portal 中设置的值。

我想我的意思是……我们故意设计了 dns 故障转移。虽然 DNS 在最初创建时并不是为故障转移而设计的……我们的 DNS 网络旨在从一开始就实现它。它通常可以与硬件一样有效......无需折旧或硬件成本。希望这不会让我因为插入 Dyn 而显得蹩脚...还有很多其他公司这样做...我只是从我们团队的角度说话。希望这可以帮助...

Answer 7

另一种选择是基于 BGP 的故障转移系统。设置起来并不简单，但它应该是防弹的。在一个位置设置站点 A，在一秒钟内设置站点 B，全部使用本地 IP 地址，然后获取可移植的 C 类或其他 IP 块，并设置从可移植 IP 到本地 IP 的重定向。

虽然存在缺陷，但如果您需要这种级别的控制，它比基于 DNS 的解决方案更好。

Answer 8

另一种选择是在位置 A 中设置名称服务器 1，在位置 B 中设置名称服务器 2，但要设置每个位置，以便 NS1 上的所有 A 记录都将流量指向位置 A 的 IP，而在 NS2 上，所有 A 记录都指向位置 A 的 IP位置 B。然后将您的 TTL 设置为一个非常低的数字，并确保您在注册商处的域记录已为 NS1 和 NS2 设置。这样，它会自动进行负载平衡，并在一台服务器或指向某个位置的链接出现故障时进行故障转移。

我以稍微不同的方式使用了这种方法。我有一个有两个 ISP 的位置，并使用此方法通过每个链接引导流量。现在，它的维护可能比您愿意做的要多一些……但我能够创建一个简单的软件，它可以自动拉取 NS1 记录，更新选定区域的 A 记录 IP 地址，并将这些区域推送到NS2。

Answer 9

所有这些答案对他们来说都有一定的道理，但我认为这实际上取决于你在做什么以及你的预算是多少。在 CloudfloorDNS，我们的业务很大一部分是 DNS，不仅提供快速 DNS，还提供低 TTL 选项和 DNS 故障转移。如果这不起作用并且效果不佳，我们就无法开展业务。

如果您是一家跨国公司，对正常运行时间的预算没有限制，那么硬件 GSLB 负载均衡器和一级数据中心就很棒，但您的 DNS 仍然需要快速且稳定。正如许多人所知，DNS 是任何基础设施的一个关键方面，除了域名本身之外，它是您在线存在的所有其他部分所依赖的最低级别的服务。从可靠的域名注册商开始，DNS 与防止您的域名过期一样重要。DNS 出现故障，这意味着您组织的整个在线方面也出现故障！

使用 DNS 故障转移时，其他关键方面是服务器监控（始终要检查多个地理位置，并且应始终检查多个（至少 3 个）以避免误报）以及在检测到故障时正确管理 DNS 记录。低 TTL 和一些故障转移选项可以使这一过程成为一个无缝的过程，如果您是系统管理员，那么您就不用在半夜被寻呼机吵醒了。

总体而言，DNS 故障转移确实有效并且非常实惠。在大多数情况下，您可以从我们或大多数托管 DNS 提供商处获得任播 DNS 以及服务器监控和故障转移，而只需硬件选项成本的一小部分。

所以真正的答案是肯定的，它确实有效，但它适合每个人、每个预算吗？也许不会，但在您亲自尝试并进行测试之前，如果您是 IT 预算有限且希望尽可能获得最佳正常运行时间的中小型企业，那么很难忽视这一点。