Round-Robin DNS是否足够“满足静态内容的负载平衡”?

我们有一组共享的静态内容,我们在http://sstatic.net的网站上提供。 不幸的是,这个内容目前不是负载平衡 – 它是从一台服务器提供的。 如果该服务器出现问题,那么所有依赖该服务器的网站都将被closures,因为共享资源是共享的JavaScript库和图像。

我们正在寻找在这台服务器上负载平衡静态内容的方法,以避免单一的服务器依赖。

我意识到,循环赛DNS最好是低端(有些甚至可能会说贫民窟 )的解决scheme,但我不禁想知道 – 循环赛DNS是一个“足够好”的解决scheme,用于静态内容的基本负载平衡?

在[dns] [load-balancing]标签中有一些讨论,我已经阅读了关于这个主题的一些很棒的post。

我知道通过多个循环AloggingDNS负载平衡的常见缺点:

  • 通常没有使用DNSlogging进行心跳检测或故障检测,因此如果轮换中的给定服务器出现故障,则必须手动从DNS条目中删除其Alogging
  • 生存时间(TTL)必须设置得相当低,因为DNS的条目在互联网上积极caching
  • 客户端计算机负责看到有多个Alogging并select正确的logging

但是,作为首发者,轮到DNS是足够好的,比没有好,“我们研究和实现更好的替代scheme”forms的静态内容的负载平衡? 或者在任何情况下,DNS循环都毫无价值?

杰夫,我不同意,负载平衡并不意味着冗余,事实上恰恰相反。 你拥有的服务器越多,在给定的时刻你就越有可能失败。 这就是为什么在进行负载均衡时冗余是强制性的,但不幸的是,有很多解决scheme只提供负载均衡,而没有执行任何健康检查,导致服务不可靠。

通过将负载分布在多个地点(潜在地理位置分布),DNS roundrobin非常适合提高容量。 但它不提供故障切换。 您必须首先描述您想要覆盖哪种types的失败。 必须使用标准IP地址接pipe机制(VRRP,CARP,…)在本地覆盖服务器故障。 交换机故障由服务器上的弹性链路覆盖到两台交换机上。 WAN链路故障可以通过使用路由协议或第2层解决scheme(例如:多链路PPP)在您和您的提供商之间的多链路设置来解决。 站点故障应该由BGP覆盖:您的IP地址被复制到多个站点,并且只在可用的地方通告给networking。

从你的问题看,你似乎只需要提供一个服务器故障转移解决scheme,这是最简单的解决scheme,因为它不涉及任何硬件,也不与任何ISP签订合同。 您只需在服务器上安装相应的软件即可,这是迄今为止最便宜,最可靠的解决scheme。

你问“如果haproxy机器出现故障怎么办?”。 一样的。 所有使用haproxy进行负载平衡和高可用性的人都有两台机器,并运行ucarp,keepalived或heartbeat,以确保其中一个始终可用。

希望这有助于!

作为负载平衡,这是贫民窟,但或多或​​less有效。 如果您有一台服务器从负载中摔下来,并想将其分发到多台服务器,那么这可能是一个很好的理由,至less暂时这样做。

有一些有效的循环DNS的批评作为负载“平衡”,我不会推荐这样做,而不是作为一个短期的创可贴。

但是你说你的主要动机是避免单服务器依赖。 如果没有一些自动化的服务方式来停止服务,那么作为防止停机的方法并不是很有价值。 (通过自动的方式将服务器从轮换和短暂的TTL中拉出来,它变成了贫民区故障转移,手动,甚至不是这样)。

如果您的两台服务器中的一台出现故障,那么50%的客户将会失败。 这比只有一台服务器的100%的故障要好,但几乎所有其他的解决scheme都是真正的故障切换。

如果一台服务器的故障概率是N,那么有两台服务器的概率是2N。 如果没有自动化的快速故障转移function,该scheme会增加您的部分用户遇到故障的可能性。

如果您打算手动停用死掉的服务器,则受限于您可以执行此操作的速度 DNS TTL。 如果服务器在凌晨4点死亡怎么办? 真正的故障转移的最好的部分是在夜晚睡觉。 您已经使用HAProxy ,所以您应该熟悉它。 我强烈build议使用它,因为HAProxy正是为这种情况而devise的。

循环赛DNS不是人们想象的那样。 作为DNS服务器软件(即BIND )的作者,我们得到的用户想知道为什么他们的循环赛按计划停止工作。 他们不明白,即使TTL为0秒,也会有一定的caching,因为无论如何,一些caching会占用最less的时间(通常是30-300秒)。

另外,虽然您的AUTH服务器可能会循环使用,但您不能保证那些您关心的用户(即用户所说的caching)。 简而言之,循环法并不能保证从客户的angular度进行任何sorting,只有您的auth服务器提供给caching。

如果你想真正的故障转移,DNS只是一步。 列出两个不同群集的多个IP地址并不是一个坏主意,但是我会使用其他技术(如简单的任播)来执行实际的负载均衡。 我个人鄙视硬件负载平衡的硬件,因为它通常是错误的DNS与DNS。 不要忘记DNSSEC即将到来,所以如果你select了这个领域的东西,请问你的供应商当你签署你的区域时会发生什么。

之前我已经多次说过了,我会再说一遍 – 如果弹性是问题,那么DNS技巧就不是答案

最好的高可用性系统将允许您的客户继续使用每个请求完全相同的IP地址。 这是确保客户甚至没有注意到失败的唯一方法。

所以基本规则是真正的弹性需要IP 路由级别的欺骗。 使用负载均衡设备或OSPF“等成本多path”,甚至是VRRP。

另一方面,DNS是一种寻址技术。 它仅仅是为了从一个名字空间映射到另一个名字空间。 它的目的不是允许对该映射进行非常短期的dynamic更改,因此当您尝试进行此类更改时,许多客户将不会注意到这些更改,或者至多需要很长时间才能注意到这些更改。

我也想说,因为加载对于你来说不是问题,所以你可能还有另一台服务器准备好作为热备份运行。 如果您使用愚蠢的循环法,您必须在事件中断时主动更改您的DNSlogging,因此您可以主动将热备用服务器转换为操作,而不是更改DNS。

我已经阅读了所有的答案,而我没有看到的一件事是,如果服务器没有响应,大多数现代的Web浏览器将尝试其中一个替代的IP地址。 如果我没有记错,那么Chrome甚至会尝试多个IP地址,并继续使用首先响应的服务器。 所以在我看来,DNS循环负载平衡总是更好,然后什么都没有。

BTW:我将DNS Round Robin看作简单的负载分配解决scheme。

Windows Vista和Windows 7 实现了对循环法的客户端支持,因为它们将IPv6地址select反向移植到IPv4。 ( RFC 3484 )

因此,如果您有大量的Vista,Windows 7和Windows 2008用户,您可能会发现在您的ersatz负载平衡解决scheme中与您计划的想法不一致的行为。

我迟到了,所以我的回答可能只是徘徊在底层,被忽视的嗅闻。

首先,问题的正确答案不是回答问题,而是说:

  1. “您可能需要Windows networking负载平衡 。” 要么
  2. “与时俱进,将您的静态内容放在Cloud Files或S3之类的东西上,并在全球范围内有一个CDN镜像。”

NLB是成熟的,非常适合这个任务,而且非常容易设置。 云解决scheme有自己的优点和缺点,这是超出了这个问题的范围。

是一个循序渐进的DNS作为一个首发,足够好,而不是什么,“而我们研究和实施更好的替代scheme”负载平衡forms为我们的静态内容?

在两个或三个静态Web服务器之间? 是的,总比没有好,因为有DNS提供商将DNS Round Robin与服务器运行状况检查集成在一起 ,并且会暂时从DNSlogging中删除已死的服务器。 所以这样你可以得到不错的负载分配和一些高可用性。 这一切都需要不到5分钟的时间才能成立。

但在这个线程中的其他人提出的警告确实适用:

  • 目前的微软浏览器cachingDNS数据30分钟 ,所以你正在寻找超过30分钟的故障转移时间为您的用户的一个子集,这取决于他们的初始DNScaching状态。
  • 用户在故障切换过程中看到的内容可能会很奇怪(您没有使用静态内容的身份validation,当然也不是表单validation,但是链接显示了一些需要注意的事项)。

其他解决scheme

HAProxy是太棒了,但由于堆栈溢出在Microsoft技术堆栈上,可能使用Microsoft负载平衡和高可用性工具将减lesspipe理开销。 networking负载平衡负责解决问题的一部分,而Microsoft现在实际上已经有一个L7 HTTP反向代理/负载平衡器 。

我自己从来没有使用过ARR,但是在第二个主要版本中,我从来没有使用过ARR,所以我认为它已经被很好的testing了。 它很容易理解文档 ,下面是他们如何看到静态和dynamic内容在Web节点上的分布情况,这里是如何使用ARB和NLB来实现负载分配和高可用性的一部分。

其中有多less贡献者正在帮助将有关DNS Round Robin的信息作为负载分散和恢复机制提供帮助。 它通常工作,但你需要了解它是如何工作的,并避免所有这些虚假信息造成的错误。

1)用于循环法的DNSlogging上的TTL应该很短 – 但不为零。 TTL为零打破了提供弹性的主要方式。

2)DNS RR扩展,但不平衡负载,因为在一个大的客户端基础上,它们倾向于独立查询DNS服务器,所以最终得到不同的首选DNS条目。 这些不同的第一select意味着客户端由不同的服务器提供服务,负载分散。 但这一切都取决于哪个设备正在执行DNS查询,以及结果持续多久。 一个常见的例子是公司代理(执行DNS查询)后面的所有客户端都将最终以一台服务器为目标。 负载传播 – 但它不平衡均衡。

3)只要客户端软件正确实施(并且TTL和用户关注度不能太短),DNS RR就会提供适应性。 这是因为DNS循环提供了一个有序的服务器IP地址列表,客户端软件应该尝试依次联系它们中的每一个,直到find接受连接的服务器。

因此,如果第一select服务器closures,那么客户端TCP / IP连接超时,并且既不提供TTL或注意跨度已过期,则客户端软件再次连接尝试到列表中的第二个条目 – 依此类推,直到TTL到期,或者到达列表的末尾(或者用户厌恶地放弃)。

在客户端find一个工作服务器之前,一长串破损的服务器(您的错误)和大的TCP / IP连接重试限制(客户端configuration错误)可能需要很长时间。 太短的TTL意味着它永远不会工作到列表的末尾,而是发出一个新的DNS查询,并得到一个新的列表(希望在不同的顺序)。

有时候客户不幸,新的列表仍然以破坏的服务器开始。 为了给系统提供客户弹性的最佳机会,您应该确保TTL比典型的关注时间更长,并且让客户到达列表的最底部。

一旦客户find一个工作的服务器,它应该记住它,当它需要进行下一个连接时,不应该重复search(除非TTL已经过期)。 较长的TTL可以减less用户在search工作服务器时遇到延迟的频率,从而提供更好的体验。

4)当您想要手动更改DNSlogging(例如,删除一个长期破坏的服务器)时,DNS TTL会自动进入,那么短暂的TTL允许这个更改迅速传播(一旦您开始这样做),那么考虑在你知道这个问题之前需要多长时间的平衡,以及如何改变这个手册 – 以及普通客户端在TTL到期时只需要重新search工作服务器的事实。

DNS轮询有两个突出的特点,使其在广泛的场景非常具有成本效益 – 首先它是免费的,其次它几乎与您的客户群在地理上分散。

它并没有引入所有其他“聪明”系统所做的新的“失败单位”。 没有添加的组件可以在整个链接元素的负载上经历共同的和同时的失败。

“聪明”的系统非常棒,引入了很好的机制来协调和提供一个无缝的平衡和故障转移机制,但是最终他们用来提供无缝体验的方法是他们的致命弱点 – 额外的错误,当它的时候,将提供一个无缝的体验失败的系统广泛。

所以,是的,DNS轮循机制绝对是“足够好”的第一步超越了一个单一的服务器托pipe所有的静态内容在一个地方。

我不认为这是一个很好的解决scheme,因为假设你现在有两台服务器,并且使用DNS轮stream使用每台服务器的IP地址。 当一台服务器出现故障时,DNS服务器不知道该服务器closures,并将继续服务该IP地址,这是RR过程的一部分。 然后,50%的观众将得到一个缺lessJavaScript或图像的网站。

也许指向由代表两个服务器的Windows NLB处理的公共IP地址更容易一些。 除非你使用Linux服务器来处理你的静态内容,如果我还记得在某个地方阅读的话?

轮循负载均衡只有在您还控制DNS区域时才可用,以便您可以更改服务器列表并及时将其推送到区域主服务器。

正如其他答案中提到的那样,循环法的隐藏之处在于DNScaching,它可能发生在您的服务器和客户端之间的任何地方,这完全否定了此解决scheme的小小好处。 即使将DNS TTL设置为非常低的值,您也几乎无法控制ISP甚至客户端的DNScaching将保持活跃的IP地址。

当然,这是对SPOF的改进,但只是边缘。 我会看看谁曾经托pipe你的服务器,看看他们提供什么,许多人有一些基本的负载平衡器服务,他们可以提供。

你也可以让一台服务器在S3中重复出现静态内容,当你的主服务器出现故障时,切换到S3 CNAME。 您将以相同的延迟结束,但没有多台服务器的成本。

这实际上取决于你正在谈论的内容以及你正在轮换的服务器数量。 我曾经有一个网站在几台服务器上运行,而且当时主要由于我的新手而使用了DNS循环,这确实不是什么大问题。 这不是一个大问题,因为它没有崩溃。 这是一个非常愚蠢的非复杂的系统,所以它挺起来了,并且拥有相当稳定的stream量级别。 如果它从交通中崩溃,那是在白天,我可以轻松地照顾。 我会说你的静态内容的资格足够简单,不会导致自己的崩溃。

硬件故障等,你的服务器有多稳定? 如何“spikey”是你在这个内容上的stream量? 假设Apache或其他东西和相对平坦的stream量,它不会崩溃很多,我会说循环是“够好”。

我确定我会拒绝投票,因为我不是在鼓吹100%的HA解决scheme,但这不是你要求的。 这归结于你愿意接受的解决scheme与花费的努力。

如果您使用RR DNS进行负载平衡,那就没问题,但是您没有。 您正在使用它来启用冗余服务器,在这种情况下,它是不好的。

正如之前的一篇文章所说,你需要一些东西来检测心跳,并停止打到它回来。

好消息是,心跳是非常便宜的,无论是在交换机或Windows。

不知道其他操作系统,但我认为它也在那里。

我build议你给每台服务器分配一个额外的IP地址(除了你使用的静态IP,比如说ssh),然后你把它放到DNS池中。 然后你使用一些软件来切换这些IP地址,以防服务器出现故障。 心跳或CARP可以做到这一点,但也有其他的解决scheme。

这有一个好处,就是对于你的服务的客户端来说,在设置中什么都不需要改变,你不必担心DNScaching或者TTL,但是你仍然可以利用DNS循环“负载平衡” 。

它可能会完成这项工作,特别是如果你的静态盒子上有多个IP的话。 有一个“服务静态内容”IP和一个“pipe理机器”IP。 如果一个盒子出现故障,您可以使用现有的高可用性解决scheme或手动干预,将故障机器的IP置于其他“群集成员”或全新机器上(取决于它的速度得到这个启动和运行)。

但是,这样的解决scheme会有一些小问题。 负载平衡不会接近完美,如果您依靠手动干预,您可能会中断某些访问。

硬件负载平衡器可能会更好地分担负载,并提供“群集正常运行时间”比DNS循环。 另一方面,这是一个(或两个,因为理想情况下,你有一个HA集群中的LB)硬件,需要购买,供电和散热以及(可能)一些时间来熟悉(如果你还没有有专门的负载平衡器)。

为了简洁地回答这个问题(作为一个初学者,循序渐进的DNS是好的,总比没有好,“当我们研究和实现更好的替代scheme”的forms,对我们的静态内容进行负载均衡?),我会说,总比没有好,但是您绝对应该继续研究其他forms的负载均衡。

几年前在研究Windows负载平衡时,我看到一个文档说微软的web farm被configuration成多个负载平衡组,并且在它们之间进行DNS循环。 由于您可以在每个名称空间中有多个DNS服务器响应,并且由于Microsoft的负载平衡是自我修复,因此可以提供冗余和负载平衡。

缺点:至less需要4台服务器(2台服务器×2组)。

回答Jeff对Schof答案的评论,是否有办法在HAProxy服务器之间进行DNS循环?

它具有非常边际的用途,足以让你通过一个真正的解决scheme。 就像你说的那样,TTL必须设定的很低。 但是,这有一个副作用,即在发生问题时从DNS中提取有问题的机器。 假设您有SvrA,SvrB和SvrC分发您的内容,并且SvrA宕机。 您将其从DNS中取出,经过您的低TTL定义的短时间后,parsing程序将找出不同的服务器(SvrB或SvrC)。 您将SvrA重新在线并将其放回到DNS中。 一些人的短暂停机时间,其他人都没有。 不是很好,但可行。 混合使用的静态服务器越多,就越有可能导致大多数用户失效。

由于互联网的拓扑结构,您肯定无法获得真正的负载均衡解决scheme将提供的真正的均衡分布。 我仍然会看到所有涉及的服务器上的负载。

我一直使用具有长TTL的循环DNS作为负载平衡器。 对于使用浏览器的 HTTP / HTTPS服务它确实很好。

由于大多数浏览器实现某种“在另一个IP上的重试”,我真的非常担心浏览器,但我不知道其他库或软件如何处理多个IP解决scheme。

当浏览器没有从一台服务器得到答复时,它会自动调用下一个IP,然后坚持下去(直到它停下来,然后再尝试另一个IP)。

早在2007年,我做了以下testing:

  • 在我的网站上添加一个iframe,指向一个循环条目,如http://roundrobin.test:10080/ping.php
  • 该页面由3个PHP套接字服务,在3个不同IP上监听,全部在10080端口上(我无法在80端口上testing,因为我的网站正在运行)
  • 一个sockets(比如说A )在那里检查浏览器是否可以在10080端口上连接(因为许多公司只允许标准端口)
  • 其他两个sockets(如BC )可以在运行中启用或禁用。

我让它运行一个小时,有很多数据。 结果是,对于套接字A上99.5%的命中,我在套接字BC上有一个命中(当然,我并没有同时禁用这两个命令)。 浏览器是:iPhone,Chrome,Opera,MSIE 6/7/8,黑莓,火狐3 / 3.5 …所以即使不符合标准的浏览器正在处理它的权利!

直到今天,我再也没有对它进行testing,但也许我会在一天之内设置一个新的testing,或者在github上发布代码,以便其他人可以testing它。

重要提示:即使大部分时间都在工作,但并不排除某些请求失败的事实。 我也使用它的POST请求,因为我的应用程序将返回一个错误消息,如果它不工作,以便用户可以再次发送数据,并且很可能浏览器将使用另一个IP在这种情况下,保存将工作。 而对于静态内容,它的工作真的很棒。

因此,如果您使用的是浏览器,请使用循环法DNS,无论是静态还是dynamic内容,您都可以使用。 服务器也可能在交易中断,即使是最好的负载均衡器也无法处理这种情况。 对于dynamic内容,您必须使会话/数据库/文件同步,否则您将无法处理此问题(但对于真正的负载平衡器也是如此)。

附加说明:您可以使用iptablestesting您自己的IP上的行为。 例如,在针对HTTPstream量的防火墙规则之前,添加:

iptables -A INPUT -p tcp --dport 80 --source 12.34.56.78 -j REJECT

(其中12.34.56.78显然是你的IP)

不要使用DROP ,因为它会使端口过滤 ,而且浏览器会一直等到超时。 所以现在,你可以启用或禁用一个服务器或其他。 最明显的testing是禁用服务器A,加载页面,然后启用服务器A并禁用服务器B.当您再次加载页面时,您将看到浏览器稍微等待,然后将从服务器加载再来一次。 在Chrome中,您可以通过查看networking面板中的请求来确认服务器的IP。 在“ Headers的“ General选项卡中,您将看到名为“ Remote Address:的虚假标题。 这是你从哪里得到答案的知识产权。

因此,如果您需要在一台服务器上进入维护模式,只需使用一个iptables REJECT规则禁用HTTP / HTTPSstream量,所有请求将转到其他服务器(稍等一会,用户几乎不会察觉)。