多个数据中心和HTTP流量：DNS Round Robin是确保即时故障转移的唯一方法吗？

指向同一域的多个A记录似乎几乎专门用于将DNS Round Robin作为一种廉价的负载平衡技术来实现。

通常，针对DNS RR的警告是它不利于高可用性。当1个IP发生故障时，客户端将继续使用几分钟。

通常建议使用负载平衡器作为更好的选择。

两种说法都不完全正确：

1. 如果流量为HTTP，则大多数HTML浏览器都可以在前一个A记录关闭时自动尝试下一个A记录，而无需进行新的DNS查找。阅读此章节3.1和这里。

2. 当涉及多个数据中心时，DNS RR是在它们之间分配流量的唯一选择。

那么，在多个数据中心和HTTP流量存在的情况下，使用DNS RR是确保一个数据中心发生故障时立即进行故障转移的唯一方法吗？

谢谢，

华伦天奴

编辑：

• 当然，每个数据中心都有一个带热备用的本地负载均衡器。
• 为了即时故障转移而牺牲会话亲和力是可以的。
• AFAIK DNS推荐数据中心而不是另一个数据中心的唯一方法是仅使用与该数据中心关联的IP进行答复。如果数据中心无法访问，那么所有这些IP也将无法访问。这意味着，即使智能HTML浏览器能够立即尝试另一个A记录，所有尝试都将失败，直到本地缓存条目到期并且完成新的DNS查找，从而获取新的工作IP（我假设DNS会自动向A建议一个新的数据中心发生故障时）。因此，“智能DNS”不能确保即时故障转移。
• 相反，DNS轮询允许它。当一个数据中心发生故障时，智能HTML浏览器（大多数）将立即尝试将另一个缓存的A记录跳转到另一个（工作）数据中心。因此，DNS循环并不能确保会话亲和性或最低的RTT，但似乎是确保客户端为“智能” HTML浏览器时即时故障转移的唯一方法。

编辑2：

• 有人建议使用TCP Anycast作为最终解决方案。在此纸（第6章）中说明了任播故障转移有关BGP收敛。因此，Anycast可能需要15分钟到20秒才能完成。在为此优化拓扑的网络上，可能需要20秒。可能只有CDN运营商可以授予这样的快速故障转移。

编辑3：*

• 我做了一些DNS查找和跟踪路由（也许有些专家可以仔细检查），并且：
  • 使用TCP Anycast的唯一CDN似乎是CacheFly，其他运营商（如CDN网络和BitGravity）都使用CacheFly。似乎它们的边缘不能用作反向代理。因此，它们不能用于授予即时故障转移。
  • Akamai和LimeLight似乎使用了可感知地理位置的DNS。但！他们返回多个A记录。从traceroutes看来，返回的IP在同一数据中心上。因此，我对一个数据中心出现故障时它们如何提供100％SLA感到困惑。

当我使用术语“ DNS Round Robin”时，通常是指OP所描述的“廉价负载平衡技术”。

但这不是DNS可用于全球高可用性的唯一方法。在大多数情况下，具有不同（技术）背景的人们很难进行良好的沟通。

最佳的负载平衡技术（如果钱不成问题）通常被认为是：

1. 由“智能” DNS服务器组成的Anycast的全球网络，
2. 以及一组遍布全球的数据中心，
3. 每个DNS节点都在其中实施水平分割DNS，
4. 并以某种方式为“智能” DNS节点提供可用性和流量监视功能，
5. 以便用户DNS请求通过IP Anycast流向最近的DNS服务器，
6. 并且此DNS服务器通过“智能”水平分割DNS为该最终用户分发了一个低TTL A记录/ A记录集，用于该最近/最佳数据中心。

使用DNS的Anycast通常很好，因为DNS响应是无状态的并且几乎是非常短的。因此，如果BGP路由发生更改，则极不可能中断DNS查询。

Anycast不太适合较长的状态HTTP会话，因此该系统使用水平分割DNS。客户端和服务器之间的HTTP会话保留在一个数据中心。它通常无法在不中断会话的情况下故障转移到另一个数据中心。

正如我在“ A记录集”中指出的那样，我将所谓的“ DNS Round Robin”与上述设置一起使用。它通常用于将流量负载分散在每个数据中心的多个高可用性负载均衡器上（以便您可以获得更好的冗余度，使用更小/更便宜的负载均衡器，而不会使单个主机服务器的Unix网络缓冲区不堪重负，等等）。

那么，在多个数据中心和HTTP流量的情况下，使用DNS RR是确保高可用性的唯一方法吗？

不，这不是真的，如果不是通过“ DNS循环”，我们只是意味着分发一个域的多个A记录。但是，毫无疑问，在任何全球高可用性系统中，聪明地使用DNS都是至关重要的组成部分。上面说明了一种常见的（通常是最好的）方法。

编辑： Google论文“超越端到端路径信息来优化CDN性能”对我而言似乎是最先进的全局负载分配，以实现最佳的最终用户性能。

编辑2：我阅读了OP链接到的文章“为什么基于DNS .. GSLB ..不起作用”，它是一个很好的概述-我建议您看一下。从顶部阅读。

在“浏览器缓存问题的解决方案”部分中，它主张带有多个A记录的DNS响应指向多个数据中心，这是瞬时故障转移的唯一可能解决方案。

在底部附近的“浇水”部分中，显而易见的是，如果多个A记录指向多个大洲的数据中心，则发送多个A记录是不明智的，因为客户端将随机连接，因此经常会出现“缓慢”的情况。 DC在另一个大陆上。因此，为了使此方法真正正常工作，每个大陆都需要多个数据中心。

这是比我的步骤，不同的解决方案，第1 - 6我不能提供这一个完美的答案，我认为需要从Akamai的或谷歌的喜欢一个DNS专家，因为这在很大程度上可以归结为实用知识上当今部署的DNS缓存和浏览器的局限性。AFAIK，我的第1-6步是Akamai对其DNS进行的处理（有人可以确认吗？）。

我的感觉-来自在移动浏览器门户（手机）上担任PM的经历 -是那儿的浏览器的多样性和整体崩溃程度令人难以置信。我个人不信任要求最终用户终端“做正确的事”的高可用性解决方案。因此，我认为，在不中断会话的情况下进行全局瞬时故障转移在今天是不可行的。

我认为我上面的第1-6步是商品技术可提供的最好的步骤。该解决方案没有瞬时故障转移。

我希望Akamai和Google等DNS专家中的一位能够证明我是错误的。:-)

您的问题是：“ DNS Round Robin是否是确保即时故障转移的唯一方法？”

答案是：“ DNS Round Robin 永远不是确保即时故障转移的正确方法”。

（至少不是靠自己）

实现即时故障转移的正确方法是使用BGP4路由，以便两个站点都使用相同的IP地址。使用此功能，可以使用Internet的核心路由技术将请求路由到正确的数据中心，而不是使用Internet的核心寻址技术。

在最简单的配置中，这仅提供故障转移。它也可以用于提供Anycast，但需要注意的是，如果路由不稳定，基于TCP的协议将在切换时失败。

那么，在多个数据中心和HTTP流量的情况下，使用DNS RR是确保高可用性的唯一方法吗？

显然，这是一个错误的主张-您只需要查看Google，Akamai和Yahoo，便可以看到他们并未将round_robin [*]响应作为唯一的解决方案（有些人可能会部分使用它，以及其他方法） ）

有许多可能的选择，但是它实际上取决于您选择的服务/应用程序还具有哪些其他约束。

如果您还安排IP地址的“故障转移”，则可以在简单的位于同一地点的服务器方法上使用轮询技术，而不必担心服务器故障。（但是大多数选择负载均衡技术，单个IP地址以及负载均衡器之间的故障转移。）

也许您需要将单个会话的所有请求都发送到相同的服务器，但是希望将请求分散在不同的区域服务器群集中？循环不适合这样做：您需要做一些事情，以确保任何给定的客户端每次都访问相同的物理服务器群集（除非发生“异常”，例如服务器故障）。它们要么从DNS查询接收一致的IP地址，要么被路由到同一物理服务器群集。解决方案包括各种商业和非商业DNS“负载均衡器”，或者（如果您对网络有更多控制权的话）BGP网络广告。您可以简单地安排自己域的域名服务器给出完全不同的响应（但是，由于DNS请求可以在各地发送，因此您不会

[*我将使用“轮询”，因为DNS术语中的“ RR”表示“资源记录”。]

非常适合您的观察vmiazzo +1！我完全被困在你所在的地方..困惑于这些CDN如何发挥作用。

以下是我对CDN如何运行其网络的猜测：

• 使用Anycast DNS（由Jesper Mortensen提及）来获取最近的数据中心
• 他们运行跨不同数据中心的局域网，这使他们可以在跨不同数据中心的主机上执行类似CARP的操作

要么

• 他们在路由器上采用网关负载平衡协议或热备路由器协议（HSRP）。处理数据中心中断。
• 它们包含多个IP的原因是客户端可以重试，并且到客户端重试时，路由路径可能已更改。

目前，以下解决方案对我有用：-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

• 亚马逊云上反向代理的最后一个入口点，该代理会智能地传递到可用服务器（或在维护页面下提供）

反向代理仍然受到打击，但机器人像主要代理一样沉重。

为什么在任何类型的浏览器中都未实现RFC 2782（与MX / priority相同，适用于诸如http，imap等服务）？事情会变得更容易...在Mozilla中存在一个存在大约十年的错误！因为这将是商业负载均衡器行业的终结？我对此感到非常失望。

2-您可以使用Quagga在Anycast上执行此操作

（即使有信息表明Anycast对TCP不利，也有一些大公司在使用它，例如CacheFly）

我想知道有多少人在回答这些问题，实际上是在运行大型的全球服务器网络吗？Google正在使用循环轮询，而我的公司已经使用了多年。它可以很好地工作，但有一些限制。是的，它需要通过其他措施来增强。

如果服务器出现故障，真正的关键是愿意接受一两次打h。当我拔下服务器上的插头时，如果浏览器试图访问该服务器，则当浏览器得知IP地址已关闭时，将有一分钟左右的延迟。但是它很快就转到另一个服务器。

它的效果很好，声称它会导致很多问题的人不知道他们在说什么。它只需要正确的设计。

故障转移很糟糕。最好的HA始终使用所有资源。

自1986年以来，我一直在与HA一起工作。我接受了广泛的培训，以创建故障转移系统，我一点也不喜欢故障转移。

同样，RR确实可以分配负载，即使是被动而不是主动。我们的服务器日志清楚地显示了每台服务器上适当流量的百分比-在合理范围内。

另一个非常简单的选择是在DNS A或CNAME记录中使用低TTL（取决于您的需要低），并更新该记录以选择将使用的IP。

我们有2个ISP和几个公共服务，并且成功地使用了这种方法，从3年开始就实现了高可用性。

工作中的一个扳手是，许多ISP的解析器配置不正确，无法按设置的时间间隔缓存记录并完全忽略TTL设置。事实并非如此，也没有任何借口，但不幸的是，根据我在迁移大量网站和服务时的经验确实发生了。

TCP Anycast实际上非常稳定，并且至少由CacheFly（自2002年起），Prolexic和BitGravity使用。在NANOG 37上对TCP Anycast进行了很好的演示：http：//198.108.95.21/meetings/nanog37/presentations/matt.levine.pdf

多个A记录是消除可能的单点故障的唯一方法。任何其他解决方案都将强制所有传入请求通过服务器和客户端之间某个位置的单个设备。

因此，为了绝对冗余，这是必要的。这就是Google或其他想要确保持续提供服务的人的原因。

很明显为什么会这样……多个A记录是将请求路由到客户端浏览器的唯一方法。任何其他方法都将依赖于客户端浏览器和服务器之间可能发生故障的单个点，从而导致服务中断。通过使用A记录，从客户端到服务器的唯一单点故障就是客户端本身。

如果您没有设置多个A记录，则您要要求停机...

虽然显然不能依靠此方法进行负载平衡。