主页 / server / 问题 / 69870
Accepted
Valentino Miazzo
Asked: 2009-10-01 00:44:07 +0800 CST

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

  • 772

指向同一个域的多个 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 章）中解释了 Anycast 故障转移与 BGP 收敛有关。为此，Anycast 可以使用 15 分钟到 20 秒来完成。在拓扑为此优化的网络上可能需要 20 秒。可能只有 CDN 运营商可以授予如此快速的故障转移。

编辑 3：*

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

11 个回答

  1. Best Answer

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

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

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

    1. 一个由“智能”DNS 服务器组成的 Anycast 全球网络，
    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 循环”我们只是指为一个域分发多个 A 记录，则不是这样。但是，巧妙地使用 DNS 确实是任何全球高可用性系统的关键组件。以上说明了一种常见的（通常是最好的）方法。

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

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

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

    在底部附近的“浇水”部分中，它很明显地扩展了，如果它们指向多个大陆的数据中心，发送多个 A 记录是不酷的，因为客户端将随机连接，因此经常得到一个“慢” DC在另一个大陆。因此，要使其真正运作良好，每个大陆都需要多个数据中心。

    这是与我的步骤 1-6 不同的解决方案。我无法对此提供完美的答案，我认为需要来自 Akamai 或 Google 之类的 DNS 专家，因为其中大部分归结为实用知识今天部署的 DNS 缓存和浏览器的局限性。AFAIK，我的步骤 1-6 是 Akamai 对他们的 DNS 所做的（任何人都可以确认这一点吗？）。

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

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

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

    • 35

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

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

    （至少不是单独的）

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

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

    • 19

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

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

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

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

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

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

    • 6

  4. 非常好的观察 vmiazzo +1 给你！我被困在你的确切位置......对这些 CDN 如何发挥他们的魔力感到困惑。

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

    • 使用 Anycast DNS（Jesper Mortensen 提到）获取最近的数据中心
    • 他们运行一个跨越不同数据中心的本地网络，这允许他们在不同数据中心的主机上执行类似CARP的操作

    或者

    目前以下解决方案对我有用： - 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
    • 亚马逊云反向代理的最后一个入口点，它智能地传递给可用服务器（或在维护页面下提供）

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

    • 5

  5. 为什么 RFC 2782（与 http、imap 等服务的 MX/优先级相同）没有在任何类型的浏览器中实现？事情会更容易......有一个错误，在Mozilla中打开了十年！因为这将是商业负载均衡器行业的终结？？？我对此感到非常失望。

    • 3

  6. 2 - 您可以使用Quagga通过Anycast执行此操作

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

    • 2

  7. 我想知道有多少人回答这些问题实际上正在运行一个大型的全球服务器网络？谷歌正在使用循环，我的公司多年来一直在使用它。它可以很好地工作，但有一些限制。是的，它需要增加其他措施。

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

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

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

    自 1986 年以来，我一直在使用 HA。我接受了广泛的培训来创建故障转移系统，但我根本不喜欢故障转移。

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

    • 2

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

    我们有 2 个 ISP 和几个公共服务，我们成功地使用这种方法来实现 3 年的高可用性。

    • 1

  9. 工作中的一个问题是，许多 ISP 的解析器配置不当，这些解析器在设定的时间间隔内缓存记录并完全忽略 TTL 设置。不应该这样，也没有任何借口，但遗憾的是，根据我迁移众多网站和服务的经验，它确实发生了。

    • 1

  10. TCP Anycast 实际上非常稳定，至少被 CacheFly（自 2002 年以来）、Prolexic 和 BitGravity 使用。在 NANOG 37 上对 TCP Anycast 进行了很好的介绍：http: //198.108.95.21/meetings/nanog37/presentations/matt.levine.pdf

    • 1

相关问题