it-swarm.cn

为什么不建议DNS故障转移?

从阅读的角度来看,似乎不建议仅出于DNS的目的而不建议DNS故障转移。但是,如果您在不同子网上有两个承载冗余内容的Web服务器,那么有什么其他方法可以确保在一个服务器出现故障时将所有流量路由到实时服务器?

在我看来,DNS故障转移似乎是这里唯一的故障转移选项,但共识是,这不是一个好的选择。但是像DNSmadeeasy.com这样的服务可以提供它,因此必须有其优点。任何意见?

172
Lin

所谓“ 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负载平衡器分散负载并在单个服务器故障时进行故障转移。
  • 获取您的防火墙,负载均衡器和交换机所需的冗余级别/预期正常运行时间。
  • 制定通信策略以应对整个数据中心发生故障,以及偶发性的交换机/数据库服务器/其他资源偶尔发生的故障,这些故障无法轻松镜像。

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

94
Jesper M

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故障转移的工作原理-请给我发电子邮件,我很乐意分享。

47
Scott McDonald

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

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

32
Cian

普遍认为,使用DNS RR,当IP断开时,某些客户端将继续使用损坏的IP数分钟。以前在该问题的某些答案中对此进行了说明,并在Wikipedia上进行了说明。

无论如何,

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
Valentino Miazzo

我在一个生产量中等但对业务至关重要的网站(跨两个地区)上运行DNS RR故障转移多年。

它工作正常,但至少有3点是我通过艰难的方法学到的。

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?何时?如果套接字挂起或关闭,该应用程序是否重新打开新的套接字?是否存在某种超时逻辑?等)

它价格便宜,经过了良好的测试,并且“大部分都可以使用”。因此,与大多数情况一样,您的行驶里程可能会有所不同。

12
GregW

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

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

我想我的意思是...我们故意设计了DNS故障转移。虽然最初创建DNS并不是为了故障转移而创建的,但我们的DNS网络旨在从一开始就实现它。它通常可以和硬件一样有效。而不会折旧或降低硬件成本。希望这不会让我因插入Dyn而感到la脚...还有很多其他公司正在这样做...我只是从我们团队的角度出发。希望这可以帮助...

9
Ryan

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

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

5
Amal

另一种选择是基于BGP的故障转移系统。设置起来并不简单,但是应该是防弹的。在一个位置设置站点A,在第二个站点B中都设置本地IP地址,然后获得C类或其他可移植的ip块,并设置从便携式IP到本地IP的重定向。

有陷阱,但是如果您需要这种控制级别,它比基于DNS的解决方案要好。

4
Kyle Hodgson

多数据中心故障转移的一种选择是训练用户。我们向客户宣传我们在多个城市和注册电子邮件中提供了多台服务器,其中包括直接指向每台“服务器”的链接,以便用户知道一台服务器是否停机,可以使用到另一台服务器的链接。

仅维护多个域名就完全绕过了DNS故障转移的问题。访问www.company.com或company.com并登录的用户将定向到server1.company.com或server2.company.com,如果他们发现使用一种或另一种可获得更好的性能,则可以选择对其中任何一个添加书签。 。如果一个服务器出现故障,将训练用户使用另一台服务器。

3
thelsdj

在过去的十年中,我一直在使用基于DNS的站点平衡和故障转移,虽然存在一些问题,但是可以缓解这些问题。 BGP虽然在某些方面具有优势,但它并不是100%的解决方案,它要么具有更高的复杂度,可能还会增加硬件成本,收敛时间等。

我发现将本地(基于LAN的)负载平衡,GSLB和基于云的区域托管相结合可以很好地解决通常与DNS负载平衡相关的一些问题。

2
Greeblesnort

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

是的,如果您是一家运营时间预算不受限制的跨国公司,那么硬件GSLB负载平衡器和第1层数据中心是不错的选择,但是您的DNS仍然需要快速且稳定。众所周知,DNS是除域名本身之外的任何基础结构的关键方面,它是您在线状态的每个其他部分都可以使用的最低级别的服务。从可靠的域名注册商开始,DNS与不让您的域名过期同样重要。 DNS发生故障,这意味着组织的整个在线方面也发生故障!

使用DNS故障转移时,其他关键方面是服务器监视(始终检查多个地理位置,并始终检查多个(至少3个)以避免误报),并正确管理DNS记录以检测到故障。低TTL和故障转移的某些选项可以使此过程无缝进行,并且如果您是系统管理员,则可以避免在半夜醒来传呼机的麻烦。

总体而言,DNS故障转移确实可以正常工作并且可以负担得起。在大多数情况下,我们或大多数托管DNS提供商都会为您提供Anycast DNS,以及服务器监视和故障转移功能,而硬件选择成本只是其中的一小部分。

因此,真正的答案是肯定的,它可行,但是对所有人和每个预算都适用吗?也许不是,但是在您亲自尝试并进行测试之前,如果您是中小型企业且IT预算有限,并且希望获得最大的正常运行时间,则很难忽略它。

2
Eric - CloudfloorDNS

如今,良好的全局负载平衡器可以使用该技术运行并且运行良好。例如检查Azure交通管理器 https://Azure.Microsoft.com/zh-cn/services/traffic-manager/

1
Ricardo Polo

“以及为什么要抓住机会在大多数生产环境中使用它(尽管总比没有好)。”

实际上,当存在的地理位置不同时,“胜过一切”最好表示为“唯一选择”。硬件负载平衡器非常适合单个存在点,但是单个存在点也是单个故障点。

有很多大美元站点使用基于dns的流量操纵来取得良好效果。他们是每小时都会知道销售量是否减少的网站类型。看来他们是最后一次“抓住机会在大多数生产环境中使用它”。实际上,他们已经仔细审查了他们的选择,选择了该技术,并为此付出了高昂的代价。如果他们认为更好的话,他们会心跳加速。他们仍然选择留下的事实充分说明了现实生活中的使用情况。

基于Dns的故障转移确实会遭受一定程度的延迟。没有其他办法了。但是,它仍然是多流行方案中故障转移管理的唯一可行方法。作为唯一的选择,它远不止“胜于无”。

1
spenser

我相信故障转移的想法是用于集群的,但是由于它也可以单独运行,因此仍然可以以一对一的方式进行操作。

0
Seth

如果您想了解更多信息,请阅读以下应用笔记

http://edgedirector.com

它们涵盖:故障转移,全局负载平衡和许多相关事项。

如果您的后端体系结构允许,更好的选择是使用故障转移选项进行全局负载平衡。这样,所有服务器和带宽都可以发挥最大作用。此安装程序不会在发生故障时插入其他可用服务器,而是从服务中撤出发生故障的服务器,直到恢复为止。

简短的答案:它可行,但是您必须了解局限性。

0
spenser