通常针对DNS RR的警告是，它不利于高可用性。当1个IP发生故障时，客户端将继续使用几分钟。
通常建议使用负载平衡器作为更好的选择。
两种说法都不完全正确：
然后，使用HTTP，大多数HTML浏览器将能够自动尝试下一个A记录（如果先前的记录已关闭），而无需进行新的DNS查找。请阅读此处的第3.1章和此处的内容。
那么，当涉及多个数据中心时，DNS RR是在它们之间分配流量的唯一选择。
因此，具有多个数据中心的确如此和HTTP流量，使用DNS RR是确保一个数据中心发生故障时立即进行故障转移的唯一方法吗？
，谢谢，
Valentino
编辑：
当然，每个数据中心都有一个带热备用的本地负载均衡器。
为即时故障转移牺牲会话亲和力是可以的。
AFAIK是DNS建议数据中心而不是其他数据中心的唯一方法是仅使用与该数据中心相关的IP进行答复。如果数据中心无法访问，那么所有这些IP也将无法访问。这意味着，即使智能HTML浏览器能够立即尝试另一个A记录，所有尝试都将失败，直到本地缓存条目到期并且完成新的DNS查找，从而获取新的工作IP（我假设DNS会自动向A建议新数据中心发生故障时）。因此，“智能DNS”无法确保即时故障转移。
相反，DNS轮询允许它。当一个数据中心发生故障时，智能HTML浏览器（大多数）将立即尝试将另一个缓存的A记录跳转到另一个（工作）数据中心。因此，DNS轮询不能确保会话亲和力或最低的RTT，但似乎是确保客户端为“智能” HTML浏览器时即时故障转移的唯一方法。
编辑2：
有人建议使用TCP Anycast作为最终解决方案。本文（第6章）解释了Anycast故障转移与BGP收敛有关。因此，Anycast可能需要15分钟到20秒才能完成。
在针对此拓扑进行了优化的网络上，可能需要20秒。
只有CDN运营商可以授予这样的快速故障转移。 br />
编辑3：*
我做了一些DNS查找和跟踪路由（也许有些专家可以仔细检查），并且：
唯一使用TCP Anycast的CDN似乎是CacheFly，其他运营商（如CDN网络和BitGravity）也使用CacheFly。似乎它们的边缘不能用作反向代理。因此，它们不能用于授予即时故障转移。
Akamai和LimeLight似乎使用了可感知地理位置的DNS。但！它们返回多个A记录。
从traceroutes看来，返回的IP位于同一数据中心上。因此，当一个数据中心发生故障时，它们如何提供100％SLA令我感到困惑。
#1 楼
当我使用“ DNS Round Robin”一词时，通常是指OP所描述的“便宜的负载平衡技术”。但这不是DNS可以用于全局的唯一方法。高可用性。在大多数情况下，具有不同（技术）背景的人们很难进行良好的沟通。
最好的负载平衡技术（如果钱不成问题）通常被认为是：
“智能” DNS服务器的任意播全球网络，以及一组全球分布的数据中心，每个DNS节点在其中实现水平分割DNS，
/>并以某种方式对“智能” DNS节点进行可用性和流量监视，以使用户DNS请求通过IP Anycast和此DNS服务器流向最近的DNS服务器。通过“智能”水平分割DNS为该最终用户分发最接近/最佳数据中心的低TTL A记录/ A记录集。
使用DNS的任意播通常很好，因为DNS响应是无状态的，而且几乎是非常短的。因此，如果BGP路由发生更改，则极不可能中断DNS查询。
Anycast不太适合较长的状态HTTP会话，因此该系统使用水平分割DNS。客户端和服务器之间的HTTP会话保持在一个数据中心。它通常无法在不中断会话的情况下故障转移到另一个数据中心。
正如我在“ A记录集”中所指出的，我将所谓的“ DNS Round Robin”与上述设置一起使用。它通常用于将流量负载分散到每个数据中心的多个高可用性负载均衡器上（以便您可以获得更好的冗余，使用更小/更便宜的负载均衡器，而不会使单个主机服务器的Unix网络缓冲区不堪重负，等等）。 br />
那么，是否确实存在多个数据中心和HTTP流量，但DNS RR的使用是确保高可用性的唯一方法？
/>
不，这不是真的，如果不是通过“ DNS Round Robin”，我们只是意味着分发一个域的多个A记录。但是，毫无疑问，DNS的明智使用是任何全球高可用性系统中的关键组成部分。上面说明了一种常见的（通常是最好的）方法。
编辑：Google论文“超越端到端路径信息来优化CDN性能”在我看来是状态
编辑2：我阅读了OP链接到的文章“为什么基于DNS的.. GSLB ..不起作用”，是一个很好的概述-我建议您看一下。从顶部开始阅读。
在“浏览器缓存问题的解决方案”部分中，它主张带有多个A记录的DNS响应指向多个数据中心，这是瞬时故障转移的唯一可能解决方案。 />
在底部附近的“浇水”部分中，显而易见的是，如果多个A记录指向多个大洲的数据中心，则发送多个A记录是不明智的，因为客户端将随机连接，因此相当通常会在另一大陆获得“慢速” DC。因此，要使其真正正常运行，每个大陆都需要多个数据中心。
这与我的步骤1-6是不同的解决方案。我想不能对此提供完美的答案。需要来自Akamai或Google之类的DNS专家，因为其中很多都归结于当今部署的DNS缓存和浏览器的局限性的实用知识。 AFAIK，我的第1-6步是Akamai使用其DNS进行的操作（有人可以确认吗？）。
我的感觉-来自在移动浏览器门户（手机）上担任PM的经历-是那儿的浏览器的多样性和整体崩溃程度令人难以置信。我个人不信任要求最终用户终端“做正确的事”的高可用性解决方案。因此，我认为在不中断会话的情况下进行全局瞬时故障转移在今天是不可行的。
我认为我上面的第1-6步是可用于商品技术的最好方法。此解决方案没有瞬时故障转移。
我希望Akamai，Google等公司的DNS专家之一来证明我是错误的。 :-)
评论
我在问题中添加了更多解释。如果我了解您的“最佳负载平衡技术”（第6点），它只会发布“最佳”数据中心的A记录。正如我试图在问题中解释的那样，这不允许在客户端上进行即时故障转移。
–华伦天奴（Valentino Miazzo）
09-09-30 14:28
@vmiazzo：是的，您正确理解了我。我在帖子中添加了第二次编辑以进行澄清-但基本上，我认为您寻求的即时故障转移是不切实际/不可能的。
– Jesper M
09-09-30 15:30
我发现有趣的是，没有人建议将两种方法结合在一起。虽然不理想，但是当事情正常运行时它将提供合理的速度，而当事情无法正常运行时它将提供额外的弹性。当客户端从一个基于任播的DNS地址切换到另一个基于DNS的地址时，代价将是很大的延迟。
–艾琳·佩恩（Avery Payne）
2012年9月13日19:58在
@JesperMortensen，当您说“智能” DNS时，您是说水平分割DNS吗？或者您是说其他意思（根据源IP以外的因素决定）？
–起搏器
2014年5月14日下午6:10
#2 楼
您的问题是：“ DNS Round Robin是确保即时故障转移的唯一方法吗？”答案是：“ DNS Round Robin永远不是确保即时故障转移的正确方法”。 br />
（至少不是一个人）
实现即时故障转移的正确方法是使用BGP4路由，以便两个站点都使用相同的IP地址。使用此功能，Internet的核心路由技术用于将请求路由到正确的数据中心，而不是使用Internet的核心寻址技术。
在最简单的配置中，这仅提供故障转移。它也可以用于提供Anycast，但需要注意的是，如果路由不稳定，基于TCP的协议将在切换时失败。
评论
在问题上添加了有关Anycast故障转移的一些信息。基本上，TCP Anycast也不是完美的解决方案。
–华伦天奴（Valentino Miazzo）
09年10月1日在10:17
@vmiazzo re TCP Anycast-的确如此，因此在我的回答中请注意路由不稳定及其如何影响TCP。
– Alnitak
09年10月1日在12:16
#3 楼
那么，在多个数据中心和HTTP流量的情况下，使用DNS RR是确保高可用性的唯一方法吗？
显然是错误的声明-您只需查看Google，Akamai和Yahoo，便可以看到他们没有将轮询[*]响应作为唯一解决方案（某些人可能会结合其他方法使用它。）
有很多可能的选择，但实际上取决于您所选择的服务/应用程序还有哪些其他约束。
可以使用轮询技术如果您还安排IP地址的“故障转移”，则可以使用一种简单的位于同一地点的服务器方法，而不必担心服务器故障。 （但是大多数选择负载平衡技术，单个IP地址以及负载平衡器之间的故障转移。）
也许您需要单个会话的所有请求才能到达同一服务器，但是您希望请求分散在不同的区域服务器群集中吗？轮询不适合这样做，因为：您需要做一些事情以确保任何给定的客户端每次都访问相同的物理服务器群集（除非发生“异常”，例如服务器故障）。它们要么从DNS查询接收一致的IP地址，要么被路由到同一物理服务器群集。解决方案包括各种商业和非商业DNS“负载平衡器”，或者（如果您对网络有更多控制权的话）BGP网络广告。您可以简单地安排自己域的域名服务器给出完全不同的响应（但是，由于DNS请求可以在各处发送，因此使用该方法将不会实现任何位置关联。）
[ *我将使用“轮询”，因为DNS术语中的“ RR”表示“资源记录”。]
评论
我在答案中添加了更多解释。您关于使用DNS“负载平衡器”恕我直言的建议不允许即时故障转移。关于BGP，您是否指的是Anycast TCP解决方案？
–华伦天奴（Valentino Miazzo）
2009年9月30日14:21在
我不是在建议任何其他特定的解决方案-我是说，您需要为问题（在问题中实际上没有提到）和约束条件（同上）选择正确的解决方案。DNS轮询确实可以不提供除DNS LB之外的即时故障转移功能，因为不能保证浏览器执行“正确的事”（主要是因为未严格定义或规定“正确的事”。我不相信有足够的“聪明” HTML浏览器”，即使是现在-我也同意Jesper的看法，即它们的行为差异太大，根本无法依赖它们。）
– jrg
09年9月30日在22:57
我理解您的怀疑。无论如何，您可以在此处阅读crypto.stanford.edu/dns/dns-rebinding.pdf当前大多数HTML浏览器已经是“智能”的。
–华伦天奴（Valentino Miazzo）
09年10月1日在9:47
#4 楼
非常适合您的观察vmiazzo +1！我被这些CDN的魔力迷住了。以下是我对CDN如何运行其网络的猜测：
使用Anycast DNS（由Jesper Mortensen提到）来获取最近的数据中心。
它们运行跨不同数据中心的本地网络，从而使他们可以在不同数据中心的主机上执行类似CARP的操作
或
他们在路由器上采用网关负载平衡协议或热备路由器协议（HSRP）。它们处理数据中心中断的原因。
目前以下解决方案为我工作：
-DNS返回多个IP，例如：
www -> CNAME www1 , www1 A -> 123.123.123.1
www -> CNAME www2 , www2 A -> 123.123.123.1
www -> CNAME www3 , www3 A -> 123.123.123.1
www3 A -> 8.4.56.7 <--- reverse proxy
亚马逊云上反向代理的最后一个入口点，该代理可以智能地传递到可用服务器（或在维护页面下提供）。反向代理仍然受到打击，但机器人像主要代理一样沉重。
评论
客户端将收到的多个DNS记录的顺序是有意随机分配的，因此您的反向代理可能在大约1/6的时间（1/3的1/2）中被命中。与拥有6条A记录相比，有什么好处或不同？
– ColinM
13年1月17日在20:14
#5 楼
为什么在任何类型的浏览器中都未实现RFC 2782（与MX / priority相同，适用于诸如http，imap等服务）？事情会变得更容易...在Mozilla中存在一个存在大约十年的错误！因为这将是商业负载均衡器行业的终结？我对此感到非常失望。#6 楼
2-您可以使用Quagga使用Anycast进行此操作（即使有一些信息表明Anycast对TCP不利，也有一些大公司在使用它，例如CacheFly）
评论
绝对可以，但是租用的服务器无法做到这一点，您需要自己的网络。
–朱利安·塔塔林（Julien Tartarin）
09年9月30日在9:33
在问题上添加了有关Anycast故障转移的一些信息。基本上，TCP Anycast也不是完美的解决方案。
–华伦天奴（Valentino Miazzo）
09年10月1日在10:16
#7 楼
我想知道有多少人回答这些问题，实际上是在运行大型的全球服务器网络吗？ Google正在使用循环轮询，而我的公司已经使用了多年。它可以很好地工作，但有一些限制。是的，它需要通过其他措施加以增强。真正的关键是如果服务器出现故障，愿意接受一两次打ic。当我拔下服务器上的插头时，如果浏览器试图访问该服务器，则当浏览器得知IP地址已关闭时，将延迟一分钟左右。但是它很快就会转到另一台服务器。
它很好用，而且声称它会引起很多问题的人不知道他们在说什么。它只需要正确的设计即可。
故障转移很糟糕。最好的HA始终使用所有资源。
我自1986年以来一直在与HA合作。我接受了广泛的培训来创建故障转移系统，我一点也不喜欢故障转移。 />
此外，RR确实可以分配负载，即使是被动而不是主动。我们的服务器日志清楚地显示了每台服务器上适当的流量百分比-在合理范围内。
#8 楼
另一个非常简单的选择是在DNS A或CNAME记录中使用低TTL（取决于您的需要低），并更新此记录以选择将使用的IP。我们有2个ISP和几个公共服务，并且我们成功地使用了这种方法，从3年开始就实现了高可用性。
评论
我在问题中添加了更多解释。许多HTML浏览器都忽略DNS TTL（DNS固定），请参阅问题中链接的论文。当数据中心发生故障时更改DNS配置，不允许客户端进行即时故障转移。
–华伦天奴（Valentino Miazzo）
09年9月30日在14:24
#9 楼
工作中的一个扳手是，许多ISP的解析器配置错误，无法将记录缓存一定的时间间隔，并完全忽略TTL设置。事实并非如此，也没有任何借口，但不幸的是，根据我在迁移大量网站和服务时的经验，确实发生了这种情况。评论
有一个借口。低TTL对繁忙的DNS服务器产生巨大的性能影响，并且由于需要滥用系统和资源，因此永久使用它们而不是临时使用它们会永久使用它们。大多数ISP仅在将TTL设置为低值的时间超过合理的时间段后才强制实施。
–詹姆斯·瑞安（JamesRyan）
09年12月4日11:00
#10 楼
TCP Anycast实际上非常稳定，并且至少由CacheFly（自2002年起），Prolexic和BitGravity使用。在NANOG 37上对TCP Anycast进行了很好的介绍：http://198.108.95.21/meetings/nanog37/演示文稿/matt.levine.pdf
#11 楼
多个A记录是消除可能的单点故障的唯一方法。任何其他解决方案都将强制所有传入请求通过服务器和客户端之间某个位置的单个设备。因此，为了绝对冗余，有必要。这就是Google这么做的原因，或者是想要确保持续服务可用性的其他人的原因。
很明显，为什么会这样。多个A记录是唯一的移动方式。将请求路由到客户端浏览器的位置。任何其他方法都将依赖于客户端浏览器和服务器之间可能发生故障的单个点，从而导致服务中断。通过使用A记录，从客户端到服务器的唯一单点故障就是客户端本身。
如果您没有设置多个A记录，则您将要求停机...
虽然显然不能依赖此方法进行负载平衡。
评论
什么？多个A收据不能消除单点故障！它正在寻求问题。如果要在多个数据中心之间快速故障转移，则可以在一个数据中心内使用虚拟的“浮动” IP或路由技巧。
– pQd
2010年6月3日在6:04
绝对不需要单个ip通过单个设备。
– Sandman4
2012年1月16日21:10
评论
凭借高可用性，我暗示几乎可以立即进行故障转移。即使一个数据中心发生故障，客户也不应注意到任何问题。我细化了这个问题。MaxCDN使用任播TCP，其边缘可用于缓存代理模式（CDN行业术语中的“原始获取”）。
@vmiazzo，您的pdf链接已关闭...您是说15分钟还是20秒到15分钟？