题 为什么不推荐DNS故障转移?


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

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


166
2017-08-30 17:57




看 这里 有关该主题的最新讨论。故障转移现在由现代浏览器自动完成。 - GetFree


答案:


通过'DNS故障转移',我认为你的意思是DNS Round Robin结合一些监控,即为DNS主机名发布多个IP地址,并在监控检测到服务器关闭时删除死地址。这对于小型,交通量较少的网站来说是可行的。

按照设计,当您回答DNS请求时,您还可以为您发出的响应提供生存时间(TTL)。换句话说,你告诉其他DNS服务器和缓存“你可以存储这个答案并使用它持续x分钟,然后再回来查看”。缺点来自于:

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

获得良好正常运行时间的常用方法包括:

  • 将服务器放在同一LAN上。
  • 将LAN放置在具有高可用功率和网络平面的数据中心中。
  • 使用HTTP负载平衡器在各个服务器故障上分散负载和故障转移。
  • 获得防火墙,负载平衡器和交换机所需的冗余/预期正常运行时间。
  • 针对完整数据中心故障制定通信策略,以及偶尔出现无法轻松镜像的交换机/数据库服务器/其他资源故障。

极少数网站使用多数据中心设置,数据中心之间具有“地理平衡”。


93
2017-08-30 18:39



我认为他特别试图管理两个不同数据中心之间的故障转移(注意关于不同子网的评论),因此将服务器放在一起/使用负载平衡器/额外冗余不会对他有所帮助(除了冗余数据中心。但是你仍然需要告诉互联网去那个仍在上升的那个)。 - Cian
将任播直播添加到多数据中心设置,它将成为数据中心故障证明。 - petrus
任意播放的维基百科条目(en.wikipedia.org/wiki/Anycast)讨论与DNS根服务器弹性相关的问题。 - dunxd
DDoS攻击非常普遍,现在整个数据中心都可以脱机(发生在Linode London及其他数据中心2015年12月)。因此,不建议在同一数据中心使用相同的提供程序。因此,具有不同提供商的多个数据中心将是一个很好的策略,这将使我们回到DNS故障转移,除非存在更好的替代方案。 - Laurence Cope
这不是故障转移的原因,因为当设备出现故障或故障时,您需要保持站点的正常运行吗?当您在同一网络中共享相同的设备时,您的故障转移会有什么用处?路由器? - user2128576


DNS故障转移非常有效。多年来,我一直在使用它来手动转移数据中心之间的流量,或者在监控系统检测到中断,连接问题或服务器过载时自动切换流量。当你看到它工作的速度,以及可以轻松转移的真实世界流量时 - 你永远不会回头。我使用Zabbix来监控我的所有系统,并显示在DNS故障转移情况下发生的事情的可视图表让我所有的疑虑都结束了。可能有一些ISP忽略了TTL,而且仍然有一些用户使用旧版浏览器 - 但是当你在2个数据中心位置查看数百万页面浏览量的流量时,你会进行DNS流量转移 - 进入忽略TTL的剩余流量是可笑的。 DNS故障转移是一种可靠的技术。

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

但是,嘿 - 我建立了一家提供DNS故障转移服务的公司,经过多年的努力才能为大公司服务。所以我的意见是一丝不苟。如果你想在停电期间看到一些高容量站点的zabbix流量图 - 要了解自己究竟有多好的DNS故障转移工作 - 给我发电子邮件我很乐意分享。


44
2017-10-20 17:17



Cian的回答 serverfault.com/a/60562/87017 直接与你的人相矛盾.....所以谁是对的? - Pacerier
我的经验是短TTL不能在互联网上工作。您可能正在运行尊重RFC的DNS服务器 - 但是有很多服务器没有。请不要认为这是反对Round Robin DNS的论据 - 请参阅下面的vmiazzo的答案 - 我使用RR DNS运行繁忙的站点并测试它 - 它的工作原理。我遇到的唯一问题是一些基于Java的客户端(不是浏览器)甚至没有尝试在失败时重新连接,更不用说在RST上循环主机列表了 - symcbean
我敢打赌,那些说监控DNS故障转移的人很棒,那些说糟糕的人也有类似的经历,但有着不同的期望。 DNS故障转移不是无缝的,但它可以防止大量停机。如果您需要完全无缝访问(即使在服务器故障期间也不会丢失任何请求),您可能需要更复杂且昂贵的架构。这不是许多应用程序的要求。 - Tom Wilson


DNS故障转移的问题在于,在许多情况下,它是不可靠的。有些ISP会忽略你的TTL,即使他们尊重你的TTL也不会立即发生,并且当你的网站重新启动时,当用户的DNS缓存超时时,它会导致会话出现一些奇怪现象,并且最终会出现问题到另一台服务器。

不幸的是,它几乎是唯一的选择,除非你足够大以进行自己的(外部)路由。


31
2017-08-30 18:27



+1慢而且不可靠 - Chris S
另见 serverfault.com/q/315199/87017 - Pacerier


流行的观点是,对于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个


19
2017-09-29 10:06



设计了多个A记录,但是用于负载平衡,而不是故障转移。客户端将缓存结果,并在更改记录后继续使用完整池(包括损坏的IP)几分钟。 - Cian
所以,写的是什么 crypto.stanford.edu/dns/dns-rebinding.pdf 第3.1章假? << Internet Explorer 7引导DNS绑定30分钟.1不幸的是,如果攻击者的域有多个A记录且当前服务器不可用,浏览器将在一秒内尝试不同的IP地址。>> - Valentino Miazzo
在这里移动了我的子问题 serverfault.com/questions/69870/... - Valentino Miazzo


多年来,我在生产中等流量但业务关键型网站(跨越两个地理位置)上运行DNS RR故障转移。

它工作得很好,但至少有三个细微之处,我学到了很多。

1)如果在您的客户端可用的任何缓存DNS中,两者都被认为是活动的,则浏览器将在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,何时?如果套接字挂起或关闭,应用程序是否重新打开新套接字?是否存在某种超时逻辑?等等)

它价格便宜,经过良好测试,“大多数都有效”。因此,大多数情况下,您的里程可能会有所不同。


11
2018-04-12 01:21



一个不在其他RR上重试地址的库被破坏了。将开发人员指向getaddrinfo()等手册页。 - Jasen


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

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

我想我的意思是......我们故意设计了dns故障转移。虽然DNS最初是在创建时没有进行故障转移...但我们的DNS网络是为了实现它而设计的。它通常可以像硬件一样有效。没有折旧或硬件成本。希望这对于插入Dyn而言并没有让我感到茫然......还有很多其他公司都这样做......我只是从我们团队的角度讲。希望这可以帮助...


9
2018-05-25 19:38



你是什​​么意思“可以像硬件一样有效”? DNS路由是什么类型的硬件? - mpen
@Ryan,你说“贫民窟”是什么意思? - Pacerier
对于那个词,城市词典没有给出具有正面含义的定义,我认为“乞丐的解决方案”可能是一个合适的翻译。 - Jasen


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

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


5
2017-08-07 05:13



名称服务器是否需要花费太多才能传播?如果您使用低TTL更改DNS记录,它将立即生效,但是当您更改名称服务器时,将需要24个或更多的传播,因此我不知道这可能是一个故障转移解决方案。 - Marco Demaio