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


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

针对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查找和traceroutes(也许一些专家可以仔细检查)和:
    • 使用TCP Anycast的唯一CDN似乎是CacheFly,其他运营商如CDN网络和BitGravity使用CacheFly。似乎他们的边缘不能用作反向代理。因此,它们不能用于授予即时故障转移。
    • Akamai和LimeLight似乎使用地理感知DNS。但!他们返回多个A记录。 来自traceroutes似乎返回的IP位于同一数据中心。所以,当一个数据中心出现故障时,我很困惑他们如何提供100%的SLA。

76
2017-09-30 08:44




凭借高可用性,我暗示几乎是即时故障转移。即使一个数据中心出现故障,客户也不会发现任何问题。我提炼了这个问题。 - Valentino Miazzo
MaxCDN使用任播TCP,其边缘可用于缓存代理模式(CDN行业术语中的“原点获取”)。 - rmalayter
@vmiazzo,你的pdf链接已关闭...你的意思是15分钟或20秒到15分钟? - Pacerier


答案:


当我使用术语“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为这个最终用户。

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

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

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

那么,拥有多个数据中心是真的吗?   和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专家之一来证明我的错。 :-)


34
2017-09-30 10:56



我在问题中添加了更多解释。如果我理解您的“最佳负载平衡技术”(第6点),它只会公布“最佳”数据中心的A记录。当我试图在问题中解释时,这不允许在客户端上进行即时故障转移。 - Valentino Miazzo
@vmiazzo:是的,你理解我的正确。我正在为我的帖子添加第二个编辑以澄清 - 但基本上我认为你所寻求的即时失败是不切实际/不可能的。 - Jesper Mortensen
我觉得有趣的是,没有人建议将这两种方法结合起来。虽然不理想,但是当事情正常运行时它会提供合理的速度,而当事情不能正常时它会提供额外的弹性。当客户端从一个基于任播的DNS地址切换到另一个时,惩罚将是一个很大的延迟。 - Avery Payne
@JesperMortensen,当你说'智能'DNS时,你的意思是水平分割DNS吗?或者你的意思是其他的东西(根据因素决定 外 来源IP)? - Pacerier


您的问题是:“DNS Round Robin是确保即时故障转移的唯一途径吗?”

答案是:“DNS Round Robin是 决不 确保即时故障转移的正确方法“。

(至少不是靠自己)

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

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


18
2017-09-30 16:04



在问题上添加了有关Anycast故障转移的一些信息。基本上TCP Anycast也不是一个完美的解决方案。 - Valentino Miazzo
@vmiazzo重新TCP任播 - 确实,因此在我的回答中关于路由不稳定性及其如何影响TCP的说明。 - Alnitak


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

显然这是一个虚假的主张 - 你只需要看看谷歌,Akamai,雅虎,看他们没有使用循环[*]响应作为他们唯一的解决方案(有些人可能部分地使用它,以及其他方法) 。)

有很多可能的选择,但它实际上取决于您拥有的其他约束,以及您选择的服务/应用程序。

如果您还安排了IP地址的“故障转移”,则可以在简单的共存服务器方法上使用循环技术,而不必担心服务器故障。 (但大多数人选择负载均衡技术,单个IP地址以及负载均衡器之间的故障转移。)

也许您需要将单个会话的所有请求转到相同的服务器,但您希望请求分布在不同的区域服务器群集中?循环法是不合适的,因为:您需要做一些事情,确保每次给定的客户端访问相同的物理服务器集群(除非出现“异常”,例如服务器故障)。他们从DNS查询中收到一致的IP地址,或者路由到同一个物理服务器群集。解决方案包括各种商业和非商业DNS“负载平衡器”,或(如果您对网络有更多控制权)BGP网络广告。您可以简单地安排自己域名的名称服务器来提供完全不同的响应(但是,由于DNS请求可以在整个地方发送,您将无法通过该方法实现任何位置关联。)

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


6
2017-09-30 09:47



我在答案中添加了更多解释。您建议使用DNS“负载均衡器”恕我直言,不允许即时故障转移。关于BGP,您是指Anycast TCP解决方案吗? - Valentino Miazzo
我不是建议任何特定的解决方案 - 我说你需要为你的问题选择正确的解决方案(你在问题中没有说明)和你的约束(同上。)DNS循环法不提供超过DNS LB的即时故障转移,因为浏览器不保证做“正确的事情”(主要是因为“正确的事情”没有严格定义或规定。我不相信有足够的“智能” HTML浏览器“,即使是现在 - 我同意Jesper的说法,他们的行为过于多样化,完全不依赖它们。” - jrg
我理解你的怀疑态度。无论如何,你可以在这里阅读 crypto.stanford.edu/dns/dns-rebinding.pdf 目前大多数HTML浏览器已经“智能”了。 - Valentino Miazzo


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

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

  • 使用Anycast DNS(Jesper Mortensen提到)获取最近的数据中心
  • 他们经营一家 本地网络 它跨越不同的数据中心,允许他们做类似的事情 鲤鱼 在不同数据中心的主机上

要么

在我为解决方案工作后的那一刻: - 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
2017-12-14 08:15



客户端将收到的多个DNS记录的顺序是故意随机化的,因此您的反向代理可能会在1/6的时间内被击中(1/3的1/2)。这比6 A记录更好还是更好? - ColinM


为什么RFC 2782(适用于像http,imap等服务的MX /优先级相同)在任何类型的浏览器中都没有实现?事情会更容易......有一个错误,在Mozilla开了十年!因为它将成为商业负载均衡器行业的终点???我对此非常失望。


3
2018-04-16 15:05





2 - 你可以这样做 任播 运用 斑驴

(即使有一些信息表明Anycast对TCP不好,有几家大公司使用它像CacheFly)


2
2017-09-30 09:08



当然,但是你不能用租用的服务器做到这一点,你需要自己的网络。 - Julien Tartarin
在问题上添加了有关Anycast故障转移的一些信息。基本上TCP Anycast也不是一个完美的解决方案。 - Valentino Miazzo


我想知道有多少人回答这些问题实际上是在运行一个庞大的全球服务器网络? Google正在使用循环法,我公司多年来一直在使用它。它可以很好地工作,但有一些限制。是的,需要通过其他措施进行扩充。

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

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

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

自1986年以来,我一直在与HA合作。我接受了广泛的培训,以创建故障转移系统,我完全不是故障转移的粉丝。

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


2
2017-07-19 14:34





另一个非常简单的选择是在DNS A或CNAME记录中使用低(根据您的需要有多低)TTL并更新此记录以选择将使用哪个IP。

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


1
2017-09-30 09:19



我在问题中添加了更多解释。许多HTML浏览器忽略DNS TTL(DNS固定),请参阅问题中链接的文章。当数据中心关闭时更改DNS配置不允许在客户端上进行即时故障转移。 - Valentino Miazzo


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


1
2017-09-30 14:44



有借口。低TTL对繁忙的DNS服务器具有很大的性能影响,并且永久使用它们而不是仅仅在临时更改时滥用系统及其资源。大多数ISP只有在设置为低电平的时间超过合理的时间段后才会执行最小TTL。 - JamesRyan