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

Modified on: Tue, 12 Nov 2019 19:20:02 +0800

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

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

通常建议将负载均衡器作为更好的选择。

两种说法都不完全正确:

  1. 当流量为HTTP时,大多数HTML浏览器都可以自动尝试下一个A记录(如果前一个记录已关闭),而无需新的DNS查找。阅读此处第3.1章here 强>

  2. 当涉及多个数据中心时,DNS RR是分配流量的唯一选择。

  3. 醇>

    那么,对于多个数据中心和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查询和traceroutes(也许一些专家可以仔细检查)和:

    • 使用TCP Anycast的唯一CDN似乎是CacheFly,其他运营商如CDN网络和BitGravity使用CacheFly。似乎他们的边缘不能用作反向代理。因此,它们不能用于授予即时故障转移。
    • Akamai和LimeLight似乎使用地理感知DNS。但!他们返回多个A记录。
      来自traceroutes似乎返回的IP位于同一数据中心。因此,当一个数据中心出现故障时,我很困惑他们如何提供100%的SLA。

最佳答案

当我使用术语“DNS Round Robin”时,我通常意味着“便宜的负载平衡技术”,正如OP所描述的那样。

但这不是DNS可用于全球高可用性的唯一方式。大多数时候,具有不同(技术)背景的人很难沟通。

最佳负载平衡技术(如果钱不成问题)通常被认为是:

  1. Anycast的全球“智能”DNS服务器网络,
  2. 和一组全球分布的数据中心,
  3. 其中每个DNS节点实现Split Horizo​​n DNS,
  4. 以某种方式监控“智能”DNS节点的可用性和流量,
  5. 以便用户DNS请求通过IP Anycast流向最近的DNS服务器
  6. DNS服务器通过“智能”水平分割为此最终用户分发最近/最佳数据中心的低TTL A记录/ A记录集DNS。
  7. 醇>

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

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

    正如我用“A记录集”所表示的那样,我称之为“DNS Round Robin”的东西可以和上面的设置一起使用。它通常用于将流量负载分散到每个数据中心的多个高可用负载平衡器上(这样您可以获得更好的冗余,使用更小/更便宜的负载平衡器,而不是压倒单个主机服务器的Unix网络缓冲区等)。 / p>

      

    因此,拥有多个数据中心是否属实
      和HTTP流量,DNS RR的使用是唯一的
      确保高可用性的方法?

    不,这不是真的,如果不是'DNS Round Robin',我们只是意味着为一个域分发多个A记录。但巧妙地使用DNS确实是任何全球高可用性系统中的关键组件。以上说明了一种常见的(通常是最好的)方式。

    修改:Google论文“超越端到端优化CDN性能的路径信息“在我看来是最先进的全球负载分配,以获得最佳的最终用户性能。

    编辑2:我读过“为什么选择DNS ... GSLB。 OP无法正常工作“,这是一个很好的概述 - 我建议看一下。从顶部阅读。

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

    在靠近底部的“浇水”一节中,它显而易见,即如果他们指向多个大洲的数据中心,那么发送多个A记录是不冷却的,因为客户端将随机连接,因此经常得到一个在另一个大陆'缓慢'DC。因此,为了使其工作得非常好,每个大陆都需要多个数据中心。

    这是一个与我的步骤1 - 6不同的解决方案。我无法就此提供完美答案,我认为需要来自Akamai或Google之类的DNS专家,因为其中大部分都归结为实用技术,了解当前部署的DNS缓存和浏览器的局限性。 AFAIK,我的步骤1-6是Akamai用他们的DNS做的事情(任何人都可以证实这一点吗?)。

    我的感觉 - 来自在移动浏览器门户(手机)上担任PM的工作 - 是因为浏览器的完全破解的多样性和水平令人难以置信。我个人不相信需要终端用户终端“做正确的事”的HA解决方案;因此,我认为今天不会破坏会议的全球瞬时故障转移是不可行的。

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

    我很喜欢来自Akamai,Google等的DNS专家之一来证明我错了。 : - )


相关问答

添加新评论