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

#1 楼

所谓的``DNS故障转移''是指DNS Round Robin与一些监视功能结合在一起，即为DNS主机名发布多个IP地址，并在监视功能检测到服务器关闭时删除无效地址。这对于较小的，流量较少的网站是可行的。

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


通过DNS故障转移，未知百分比的用户将使用剩余数量不等的TTL来缓存DNS数据。在TTL过期之前，这些可能会连接到已失效的服务器。有比这更快的完成故障转移的方法。

由于上述原因，您倾向于将TTL设置得很低，例如5-10分钟。但是，将其设置得较高会带来（非常小的）性能优势，即使网络流量出现短暂故障，也可以帮助您可靠地进行DNS传播。因此，使用基于DNS的故障转移会遇到较高的TTL，但是较高的TTL是DNS的一部分，可能很有用。

获得正常运行时间的更常见方法包括： br />将服务器放置在同一LAN上。
将LAN放置在具有高可用电源和网络平面的数据中心中。
使用HTTP负载平衡器分散负载并在单个服务器故障时进行故障转移。 br />获得防火墙，负载平衡器和交换机所需的冗余级别/预期正常运行时间。
针对整个数据中心故障以及交换机/数据库服务器/其他设备偶尔出现的故障，制定适当的通信策略无法轻松镜像的资源。

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

#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，当IP断开时，某些客户端将继续使用损坏的IP数分钟。以前在该问题的某些答案中对此进行了说明，并且也在Wikipedia上进行了写。 dns-rebinding.pdf解释说，对于大多数当前的HTML浏览器而言，它不是正确的。他们将在几秒钟内尝试下一个IP。

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


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


也许某些专家可以发表评论并给出更清晰的解释，为什么DNS RR不适合高可用性。

，谢谢，

Valentino

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

#5 楼

我在生产量适中但对业务至关重要的网站（跨两个地区）上运行DNS RR故障转移已经很多年了。

效果很好，但至少有3个细微之处是我很难学的。

1）浏览器将在30秒（我上次检查）后30秒（如果我对客户端可用的任何缓存DNS中都认为它们都处于活动状态）从非工作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吗？何时？如果套接字挂起或关闭，应用程序是否会重新打开新的套接字？是否存在某种超时逻辑？等等）。

很便宜，经过测试，并且“大部分有效”。因此，与大多数情况一样，您的行驶里程可能会有所不同。

#6 楼

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

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

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

#7 楼

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

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

#8 楼

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

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

#9 楼

多数据中心故障转移的一种选择是训练用户。我们向客户宣传，我们在多个城市和注册电子邮件中提供了多台服务器，其中包括直接指向每台“服务器”的链接，以便用户知道一台服务器是否停机，可以使用到另一台服务器的链接。 >
仅维护多个域名，就完全绕过了DNS故障转移的问题。访问www.company.com或company.com并登录的用户将定向到server1.company.com或server2.company.com，如果他们发现使用一种或另一种可获得更好的性能，则可以选择对其中任何一个添加书签。 。如果其中一个发生故障，则对用户进行培训以使其转到另一台服务器。

#10 楼

所有这些答案对他们都有一定的道理，但是我认为这实际上取决于您在做什么以及您的预算是多少。在CloudfloorDNS，我们业务的很大一部分是DNS，不仅提供快速DNS，而且提供低TTL选项和DNS故障转移。如果这不能正常工作，我们就不会做生意。

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

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

总体而言，DNS故障转移确实可以正常工作并且可以负担得起。在大多数情况下，我们或大多数托管DNS提供商都会为您提供Anycast DNS，以及服务器监视和故障转移功能，而硬件选项的成本却很少。

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

#11 楼

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

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

#12 楼

“以及为什么要趁机在大多数生产环境中使用它（尽管总比没有好）。”

实际上，“无所不能”最好表示为“唯一的选择”。地域差异很大。硬件负载平衡器非常适合单个存在点，但是单个存在点也是单个故障点。

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

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

#13 楼

如今，良好的全局负载平衡器可以使用该技术运行并且运行良好。检查例如Azure Traffic Manager https://azure.microsoft.com/zh-cn/services/traffic-manager/

#14 楼

如果您想了解更多信息，请阅读

http://edgedirector.com

上的应用笔记，其中包括：故障转移，全局负载平衡以及许多相关事项。

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

#15 楼

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

#16 楼

我建议您要么A，选择在其自己的AS上多宿主的数据中心，要么B，将您的名称服务器托管在公共云中。 EC2，HP或IBM倒闭的可能性很小。只是一个想法。虽然DNS是一种修复程序，但在这种情况下，它仅是针对网络基础中不良设计的修复程序。

根据您的环境，另一种选择是将IPSLA，PBR和FHRP结合使用来满足您的冗余需求。