轮循DNS是否“足够好”以平衡静态内容？

我们在http://sstatic.net的网站之间提供了一组共享的静态内容。不幸的是，此内容目前根本没有负载均衡-它是由一台服务器提供的。如果该服务器出现问题，则依赖于该服务器的所有站点实际上都将关闭，因为共享资源是必不可少的共享JavaScript库和图像。

我们正在寻找在此服务器上平衡静态内容的负载的方法，以避免单个服务器的依赖性。

我意识到循环DNS充其量只是一个低端解决方案（有些甚至可能会说贫民窟），但我不禁要问- 循环DNS是否是静态内容基本负载平衡的“足够好”的解决方案？

[dns] [load-balancing]标记中对此进行了一些讨论，并且我阅读了有关该主题的一些不错的文章。

我知道通过多个轮询A记录进行DNS负载平衡的常见弊端：

• DNS记录通常不会检测到心跳或故障，因此如果轮换中的给定服务器出现故障，则必须手动从DNS条目中删除其A记录
• 必须将生存时间（TTL）设置得很短才能完全起作用，因为DNS条目会在整个Internet上积极缓存
• 客户端计算机负责查看有多个A记录并选择正确的一个

但是，对于我们的静态内容，轮循DNS是否足以作为启动器，而不是总比没有强，而“在我们研究和实现更好的替代方案时”负载均衡形式呢？还是在任何情况下DNS轮询几乎一文不值？

杰夫，我不同意，负载平衡并不意味着冗余，实际上相反。您拥有的服务器越多，在给定的瞬间发生故障的可能性就越大。这就是为什么在进行负载平衡时必须执行冗余的原因，但是不幸的是，有许多解决方案仅提供负载平衡而没有执行任何运行状况检查，从而导致服务可靠性降低。

通过将负载分布在多个点上（可能在地理上分布），DNS轮循机制非常适合提高容量。但是它不提供故障转移。您必须首先描述您要涵盖的故障类型。必须使用标准IP地址接管机制（VRRP，CARP等）在本地解决服务器故障。服务器上到两个交换机的弹性链接涵盖了交换机故障。WAN链路故障可以通过使用路由协议或第2层解决方案（例如：多链路PPP）在您和您的提供商之间建立多链路来解决。站点故障应由BGP来解决：您的IP地址在多个站点上复制，并且仅在可用时将其发布到网络中。

从您的问题看来，您似乎只需要提供服务器故障转移解决方案，这是最简单的解决方案，因为它不涉及任何硬件，也不与任何ISP签约。您只需要为此在服务器上设置适当的软件，这是迄今为止最便宜，最可靠的解决方案。

您问“ haproxy机器是否发生故障？”。一样的。我认识的所有使用haproxy进行负载平衡和高可用性的人都有两台机器，并在它们上运行ucarp，keepalived或心跳，以确保其中一台始终可用。

希望这会有所帮助！

作为负载平衡，它是贫民窟，但差不多有效。如果您有一台服务器因负载而掉下来，并且想要将其分散到多台服务器上，那么这可能是一个很好的理由，至少是暂时的。

对于循环DNS，有许多有效的批评是负载“平衡”，我不建议这样做，除非是作为短期创可贴。

但是您说您的主要动机是避免单服务器依赖性。如果没有某种自动化的方法来使死服务器停止运行，那么作为防止停机的方法就没有什么价值。（通过自动方式将服务器从旋转和短TTL中拉出，它变成了贫民区故障转移。手动，甚至还不是。）

如果您的两个轮询服务器之一发生故障，那么您的客户中有50％会失败。这比仅一台服务器发生100％的故障要好，但是几乎任何其他进行真正故障转移的解决方案都比这更好。

如果一台服务器发生故障的概率为N，而两台服务器发生故障的概率为2N。如果没有自动的快速故障转移，此方案将增加某些用户遭受故障的可能性。

如果您打算手动使死服务器停止旋转，则受其速度和 DNS TTL的限制。如果服务器在凌晨4点死机怎么办？真正的故障转移的最佳部分是整夜入睡。 您已经使用过HAProxy，因此应该熟悉它。我强烈建议使用它，因为HAProxy专为这种情况而设计。

轮循DNS并不是人们认为的那样。由于DNS服务器软件（即的作者BIND），我们得到谁不知道为什么他们的循环赛停止工作按计划用户。他们不了解即使TTL为0秒，那里也会有一定数量的缓存，因为某些缓存无论如何都会花费最短的时间（通常为30-300秒）。

另外，尽管您的AUTH服务器可以进行轮询，但是不能保证您关心的用户（用户与之交谈的缓存）会这样做。简而言之，从客户的角度来看，轮询不保证任何排序，仅保证您的身份验证服务器提供给缓存的内容。

如果您想要真正的故障转移，DNS只是一步。为两个不同的群集列出一个以上的IP地址不是一个坏主意，但是我会在那里使用其他技术（例如简单的任播）来进行实际的负载平衡。我个人不屑一顾的硬件负载平衡硬件通常会弄错DNS的DNS。并且不要忘记DNSSEC即将到来，因此，如果您确实选择了该区域中的某些内容，请询问您的供应商在您对区域进行签名时会发生什么。

我之前已经说过好几次了，我再说一遍- 如果弹性是问题，那么DNS技巧就不能解决问题。

最好的高可用性系统将使您的客户端可以为每个请求使用完全相同的IP地址。这是确保客户端甚至不会注意到故障的唯一方法。

因此，基本规则是，真正的弹性需要IP 路由级别的欺骗。使用负载平衡器设备或OSPF“等价多路径”，甚至VRRP。

另一方面，DNS是一种寻址技术。它仅存在于从一个名称空间映射到另一名称空间的情况。它的设计不允许在短期内对该映射进行动态更改，因此，当您尝试进行此类更改时，许多客户端可能不会注意到它们，或者充其量只是花很长时间才能注意到它们。

我还要说的是，由于负载并不是您的问题，因此您可能还需要准备好另一台服务器作为热备用服务器来运行。如果您使用哑循环，则必须在出现故障时主动更改DNS记录，因此您可能还需要主动将热备用服务器投入使用，而不必更改DNS。

我已经阅读了所有答案，但没有看到的一件事是，如果服务器没有响应，大多数现代的Web浏览器都会尝试使用其他IP地址之一。如果我没记错的话，Chrome甚至会尝试使用多个IP地址，然后继续使用首先响应的服务器。因此，我认为DNS Round Robin负载平衡永远比没有更好。

顺便说一句：我将DNS Round Robin视为一种简单的负载分配解决方案。

我对这个话题迟到了，所以我的回答很可能只是一个人徘徊在底部，被忽略了。

首先，对问题的正确答案不是回答问题，而是说：

1. “您可能想要Windows 网络负载平衡。” 要么
2. “与时俱进，将静态内容放在Cloud Files或S3之类的东西上，并在全球范围内使用CDN进行镜像。”

NLB很成熟，非常适合该任务，并且很容易设置。云解决方案具有各自的优缺点，这不在此问题的范围内。

题

循环DNS是否足以作为启动器，总比没有强，而“为我们的静态内容研究负载并实施更好的替代方案”形式的负载平衡呢？

在2到3个静态Web服务器之间？是的，总比没有好。因为有一些DNS提供程序会将DNS Round Robin与服务器运行状况检查集成在一起，并将临时从DNS记录中删除失效的服务器。这样一来，您可以获得合理的负载分配和一些高可用性；只需不到5分钟即可完成设置。

但是其他人在此主题中概述的警告确实适用：

• 当前的Microsoft浏览器将DNS数据缓存30分钟，因此，根据部分用户的初始DNS缓存状态，您需要为他们的一部分用户选择30分钟以上的故障转移时间。
• 在什么用户看到在故障转移可...怪（你不使用身份验证静态内容，肯定不能形成权威性，但链接显示了一些需要注意的）。

其他解决方案

HAProxy非常棒，但是由于Stack Overflow位于Microsoft技术堆栈上，因此使用Microsoft负载平衡和高可用性工具可能会减少管理开销。网络负载平衡解决了问题的一部分，并且Microsoft实际上现在拥有L7 HTTP反向代理/负载平衡器。

我从来没有亲自使用过ARR，但鉴于它是第二个主要版本，并且来自Microsoft，我认为它已经过足够的测试。它具有易于理解的文档，这是一个有关他们如何查看Web节点上静态和动态内容的分布的文档，以及有关如何将ARR与NLB一起使用以实现负载分布和高可用性的文章。

值得注意的是，有多少贡献者正在帮助发布有关DNS Round Robin作为负载分散和弹性机制的信息。它通常可以工作，但是您需要了解它是如何工作的，并避免由于所有错误信息而导致的错误。

1）用于轮询的DNS记录上的TTL应该短-但不能为零。将TTL设置为零会破坏提供弹性的主要方式。

2）DNS RR分散，但不平衡负载，它分散它，因为在庞大的客户群中，它们倾向于独立查询DNS服务器，因此最终得到不同的首选DNS条目。这些不同的首选意味着客户端由不同的服务器提供服务，并且负载分散。但是，这完全取决于哪个设备正在执行DNS查询，以及保存结果的时间。一个常见的示例是，公司代理后面的所有客户端（为它们执行DNS查询）最终都将目标锁定在单个服务器上。负载分散-但负载不均衡。

3）只要客户端软件正确实施，DNS RR就会提供弹性（并且TTL和用户注意范围都不太短）。这是因为DNS循环提供了服务器IP地址的有序列表，并且客户端软件应尝试依次联系其中每个，直到找到可以接受连接的服务器为止。

因此，如果首选服务器关闭，则客户端TCP / IP连接将超时，并且如果TTL或关注范围都没有过期，则客户端软件将再次尝试连接列表中的第二个条目-依此类推，直到TTL过期，或到达列表末尾（或用户厌恶地放弃）。

在客户端实际找到可用的服务器之前，可能要花很长的时间才能弄清一堆破损的服务器（您的故障）和较大的TCP / IP连接重试限制（客户端配置功能不正确）。TTL太短意味着它永远无法到达列表末尾，而是发出新的DNS查询并获得新的列表（希望以不同的顺序）。

有时，客户端会很不幸，新列表仍然以损坏的服务器开头。为了使系统有最大的机会提供客户端弹性，您应该确保TTL的长度比典型的关注范围长，并且让客户端到达列表的底部。

客户端找到运行中的服务器后，便应记住该服务器，并且在需要进行下一个连接时，它不应重复搜索（除非TTL过期）。较长的TTL可以减少客户端搜索有效服务器时用户经历延迟的频率，从而获得更好的体验。

4）DNS TTL本身具有优势，当您想要手动更改DNS记录（例如，删除长期损坏的服务器）时，短TTL允许该更改快速传播（一旦您可以这样做），因此考虑一下在知道此问题之前需要花费多长时间并进行手动更改之间的平衡，以及在TTL过期后普通客户端仅需要对正在运行的服务器进行新搜索这一事实。

DNS轮循机制具有两项出色的功能，使其在各种情况下都具有很高的成本效益-首先是免费的，其次它在地理上与客户群一样分散。

它没有引入其他所有“智能”系统都会采用的新“故障单元”。没有添加的组件可能会在整个相互链接的元素负载上遭受常见且同时的故障。

“聪明”的系统很棒，并引入了出色的机制来协调并提供无缝的平衡和故障转移机制，但是最终，他们用来提供无缝体验的方法只是其致命弱点-可能出错的其他复杂问题，并且当这样做时，将提供整个系统故障的无缝体验。

因此，是的，DNS轮询绝对是“足够好”，这是您将单个静态服务器托管在一个地方的唯一服务器。

Windows Vista和Windows 7 在将IPv6地址选择反向移植到IPv4时，以不同的方式实现了对循环的客户端支持。（RFC 3484）

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

我一直将TTL长的轮询DNS用作负载平衡器。对于浏览器的 HTTP / HTTPS服务，它确实可以正常工作。

我真的强调了与浏览器的大多数浏览器采用某种«重试另一个IP»，但我不知道如何将其他库或软件处理多个IP的解决方案。

当浏览器没有收到来自一台服务器的答复时，它将自动调用下一个IP，然后坚持使用（直到它关闭...然后尝试另一个）。

早在2007年，我就进行了以下测试：

• 在我的网站上添加一个iframe，指向一个Round-Robin条目，例如 http://roundrobin.test:10080/ping.php
• 该页面由3个PHP套接字提供服务，监听3个不同的IP，都在端口10080上（由于我的网站正在运行，因此我无法在端口80上进行测试）
• 一个插座（例如A）在那里检查浏览器是否可以在10080端口上连接（因为许多公司仅允许标准端口）
• 其他两个套接字（例如B和C）可以即时启用或禁用。

我让它运行一个小时，拥有很多数据。结果是，对于套接字A的 99.5％的匹配，我对套接字B或C均具有匹配（当然，我没有同时禁用这两个）。浏览器是：iPhone，Chrome，Opera，MSIE 6/7/8，BlackBerry，Firefox 3 / 3.5 ...因此，即使是不兼容的浏览器也能正确处理它！

到目前为止，我再也没有进行过测试，但是也许有一天我会进行一次新的测试，或者在github上发布代码，以便其他人可以对其进行测试。

重要说明：即使它大部分时间都在工作，也不能消除某些请求将失败的事实。我也将其用于POST请求，因为如果应用程序无法正常工作，我的应用程序将返回一条错误消息，以便用户可以再次发送数据，并且在这种情况下，很可能浏览器将使用另一个IP并保存将起作用。对于静态内容，它的工作确实很棒。

因此，如果您使用的是浏览器，请对静态或动态内容都使用循环DNS，这通常会很好。服务器也可能在事务处理过程中崩溃，即使使用最好的负载均衡器，您也无法处理这种情况。对于动态内容，必须使会话/数据库/文件同步，否则将无法处理（但对于真正的负载平衡器也是如此）。

补充说明：您可以使用来测试自己IP上的行为iptables。例如，在您的HTTP流量防火墙规则之前，添加：

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

（12.34.56.78您的IP显然在哪里）

不要使用DROP，因为它会过滤端口，您的浏览器将等到超时。因此，现在，您可以启用或禁用一台服务器或另一台服务器。最明显的测试是禁用服务器A，加载页面，然后启用服务器A和禁用服务器B。再次加载页面时，您会看到浏览器稍有等待，然后它将从服务器加载再来一次 在Chrome浏览器中，您可以通过查看网络面板中的请求来确认服务器的IP。在的General标签中Headers，您会看到一个名为的假标题Remote Address:。这是您获得答案的IP。

因此，如果您需要在一台服务器上进入维护模式，只需使用一条iptables REJECT规则禁用HTTP / HTTPS流量，所有请求都将转到其他服务器（稍等一会，对于用户而言几乎不可见）。

我认为这不是一个足够好的解决方案，因为假设您现在有两台服务器，并且使用DNS将轮询循环到每台服务器的IP地址。当一台服务器发生故障时，DNS服务器将不知道它已发生故障，并将作为RR过程的一部分继续为该IP地址提供服务。然后，您的观众中有50％的站点将丢失Java脚本或图像。

指向由后面两个服务器代表的Windows NLB处理的公共IP地址也许更容易。除非您使用Linux服务器存储静态内容，否则我是否记得在某处阅读过？

循环负载平衡仅在您还控制DNS区域时才起作用，以便您可以更改服务器列表并将其及时推送到区域主机。

正如其他答案中提到的那样，轮询的隐藏弊端是DNS缓存，该缓存可能发生在服务器和客户端之间的任何位置，这完全抵消了此解决方案的小好处。即使将DNS TTL设置为非常低的值，您也几乎无法控制ISP甚至客户端的DNS缓存将使失效的IP地址保持活动状态的时间。

当然，这是对SPOF的改进，但只是微不足道。我将看一下谁在托管您的服务器，看看他们必须提供什么，许多人可以提供某种基本的负载均衡器服务。

您也可能只有一台服务器，在S3中复制了静态内容，并在主服务器出现故障时切换到S3 CNAME。您将得到相同的延迟，但无需花费多台服务器。

这实际上取决于您在说什么以及要旋转多少台服务器。我曾经有一个在多个服务器上运行的站点，并且由于当时是我的新手，所以使用了DNS轮询，这确实不是一个大问题。这不是一个大问题，因为它没有崩溃。这是一个非常愚蠢的简单系统，因此它保持了正常的流量水平。如果确实因为交通而崩溃，那是在白天，那是我可以轻松解决的事情。我想说您的静态内容足够简单，不会自己导致崩溃。

除了硬件故障等之外，您的服务器是否稳定？您对此内容的访问量如何？假设直接使用Apache或类似的东西，并且流量相对平稳，则不会造成太多崩溃，我想说轮询是“足够好”的。

我确定我会被否决，因为我没有宣讲100％高可用性的解决方案，但这不是您要求的。这取决于您愿意接受的解决方案与花费的精力。

如果您使用RR DNS进行负载平衡，那很好，但事实并非如此。您正在使用它来启用冗余服务器，在这种情况下，这样做并不好。

如前一篇文章所述，您需要一些东西来检测心跳并停止对其进行打击，直到心跳回来。

好消息是，无论在交换机还是Windows中，心跳的价格都非常便宜。

关于其他操作系统的Dunno，但我认为它也在那里。

我建议您为每个服务器分配一个额外的IP地址（除了用于ssh的静态IP之外），然后将其带入DNS池。然后，如果服务器发生故障，则可以使用某些软件来切换这些IP地址。例如，心跳或CARP可以做到这一点，但是还有其他解决方案。

这样做的好处是，对于您的服务的客户端，无需进行任何设置更改，也不必担心DNS缓存或TTL，但是您仍然可以利用DNS轮询“负载平衡” 。

它可能会完成这项工作，尤其是如果您可以在静态框中包含多个IP。有一个“服务静态内容” IP和一个“管理机” IP。如果随后出现故障，您可以使用现有的HA解决方案，也可以手动进行干预，以将故障机器上的IP置于其他“群集成员”之一或全新机器上（取决于其运行速度）以启动并运行）。

但是，这样的解决方案会有一些小问题。负载平衡将无法完美实现，如果您依靠手动干预，则可能会导致某些访客中断。

与DNS轮询相比，硬件负载平衡器在共享负载和提供“群集正常运行时间”方面可能做得更好。另一方面，这是一个（或两个，因为理想情况下您在HA集群中有LB）硬件需要购买，供电和冷却，并且（可能）需要一些时间来熟悉（如果您还没有的话）有专用的负载平衡器）。

简洁地回答这个问题（是循环DNS不够好作为首发，有总比没有好“而我们研究并实现更好的选择”负载的形式，平衡我们的静态内容？），我会说，这是聊胜于无，但您绝对应该继续研究其他形式的负载平衡。

几年前研究Windows负载平衡时，我看到一个文档，其中指出Microsoft的Web场被配置为多个负载平衡组，它们之间进行DNS轮询。由于您可以在每个名称空间中响应多个DNS服务器，并且由于Microsoft的负载平衡是自我修复的，因此可以提供冗余和负载平衡。

缺点：您至少需要4台服务器（2台服务器x 2组）。

回答Jeff对Schof的回答的评论，是否有办法在HAProxy服务器之间进行DNS轮询？

它仅具有很小的用途，足以在您将实际解决方案放置到位时让您满意。就像您说的那样，TTL必须设置得很低。不过，这样做还有一个好处，就是在出现问题时从DNS中取出有问题的计算机。假设您有SvrA，SvrB和SvrC分发您的内容，而SvrA崩溃了。您将其从DNS中拉出，并在由低TTL定义的短时间段后，解析器将找出另一个已启动的服务器（SvrB或SvrC）。您使SvrA重新联机，然后将其放回DNS。对于某些人来说，停机时间很短，对于其他人来说，停机时间却很少。不是很好，但是可行。混合使用的静态服务器越多，使大多数用户组宕机的可能性就越小。

由于Internet的拓扑结构，您当然不会获得真正的负载平衡解决方案所提供的真正平衡分布。我仍然会观察所有涉及的服务器上的负载。