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

Question

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

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

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

这两种说法都不完全正确：

1. 当流量为 HTTP 时，大多数 HTML 浏览器能够自动尝试下一条 A 记录（如果前一条记录出现故障），而无需进行新的 DNS 查找。阅读此章节3.1和这里。

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

那么，对于多个数据中心和 HTTP 流量，使用 DNS RR 是确保在一个数据中心出现故障时立即进行故障转移的唯一方法吗？

谢谢，

华伦天奴

编辑：

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

编辑2：

• 有些人建议将 TCP Anycast 作为最终解决方案。在此纸（第6章）中说明了选播器故障切换是关系到BGP收敛。出于这个原因，任播可以使用 15 分钟到 20 秒来完成。在为此优化拓扑的网络上，20 秒是可能的。可能只有 CDN 运营商才能提供如此快速的故障转移。

编辑 3:*

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

Answer 1

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

但这并不是 DNS 可用于实现全球高可用性的唯一方式。大多数时候，具有不同（技术）背景的人很难进行良好的沟通。

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

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

对 DNS 使用任播通常没问题，因为 DNS 响应是无状态的，而且几乎非常短。因此，如果 BGP 路由发生变化，则中断 DNS 查询的可能性很小。

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

正如我在“一组 A 记录”中指出的，我称之为“DNS 循环”的内容可以与上面的设置一起使用。它通常用于将流量负载分散到每个数据中心的多个高度可用的负载均衡器上（以便您可以获得更好的冗余，使用更小/更便宜的负载均衡器，而不是压倒单个主机服务器的 Unix 网络缓冲区等）。

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

不，这不是真的，如果“DNS Round Robin”我们只是指为一个域分发多个 A 记录，则不是。但确实，巧妙地使用 DNS 是任何全球高可用性系统中的关键组成部分。以上说明了一种常见的（通常是最好的）方法。

编辑： Google 论文“Moving Beyond End-to-End Path Information to Optimize CDN Performance”在我看来是全球负载分布的最先进技术，以实现最佳最终用户性能。

编辑 2：我阅读了OP 链接到的文章“Why DNS Based .. GSLB .. Not Work”，这是一个很好的概述——我建议查看它。从顶部阅读它。

在“浏览器缓存问题的解决方案”一节中，它提倡将多个 A 记录指向多个数据中心的 DNS 响应作为瞬时故障转移的唯一可能解决方案。

在靠近底部的“浇水”部分中，它扩展了显而易见的内容，如果它们指向多个大陆的数据中心，发送多个 A 记录是不酷的，因为客户端将随机连接，因此经常会“慢” DC在另一个大陆。因此，要使其真正发挥作用，每个大陆都需要多个数据中心。

这是比我的步骤1不同的解决方案- 6.我不能提供这一个完美的答案，我想从Akamai的或谷歌的喜欢一个DNS专家是必要的，因为这在很大程度上可以归结为实用知识上当今部署的 DNS 缓存和浏览器的局限性。AFAIK，我的第 1-6 步是 Akamai 对他们的 DNS 所做的（任何人都可以确认这一点？）。

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

我认为我上面的步骤 1-6 是商品技术中最好的。此解决方案没有即时故障转移。

我希望来自 Akamai、Google 等的 DNS 专家之一过来证明我是错的。:-)

Answer 2

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

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

（至少不是靠自己）

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

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

Answer 3

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

显然，这是一个错误的说法——你只需看看谷歌、Akamai、雅虎，就会发现他们没有使用循环[*]响应作为他们唯一的解决方案（有些人可能会部分使用它，以及其他方法） .)

有许多可能的选择，但这实际上取决于您有哪些其他限制，以及您选择的服务/应用程序。

如果您还安排了 IP 地址的“故障转移”，则可以在简单的协同定位服务器方法上使用循环技术，而不必担心服务器故障。（但大多数选择负载平衡技术、单个 IP 地址和负载平衡器之间的故障转移。）

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

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

Answer 4

对您来说非常好的观察 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

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

反向代理仍然受到攻击，但 bot 和主要代理一样重。