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

#1 楼

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

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

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

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

希望这会有所帮助！

#2 楼

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

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

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

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

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

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

#3 楼

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

也，虽然您的AUTH服务器可能会进行轮询，但是不能保证您关心的用户（用户与之交谈的缓存）的意愿。简而言之，从客户端的角度来看，轮询不保证任何顺序，仅保证您的身份验证服务器提供给缓存的顺序。

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

#4 楼

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

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

所以基本规则是，真正的弹性需要IP路由级别的欺骗。使用负载平衡器设备或OSPF“等价多路径”，甚至使用VRRP。另一方面，DNS是一种寻址技术。它仅存在于从一个名称空间映射到另一名称空间的情况。它的设计不允许在短期内对该映射进行动态更改，因此，当您尝试进行此类更改时，许多客户端可能不会注意到它们，或者充其量只是花很长时间才能注意到它们。

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

#5 楼

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

BTW：我将DNS Round Robin看作是一种简单的负载分配解决方案。

#6 楼

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

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


“您可能想要Windows网络负载平衡。” OR

“与时俱进，将静态内容放置在Cloud Files或S3之类的文件上，并在全球范围内进行CDN镜像。”

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

问题


轮循DNS足以作为入门者，总比没有更好，“为我们的静态内容提供负载平衡的”同时我们研究并实现更好的替代方案”？


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

，但此线程中其他人概述的警告确实适用：


当前的Microsoft浏览器缓存DNS数据持续30分钟，因此您要为一部分用户寻找30分钟以上的故障转移时间，具体取决于他们的初始DNS缓存状态。
用户在故障转移期间看到的内容可能会很奇怪...您没有在静态内容上使用auth，当然也没有在表单上使用auth，但是该链接显示了一些注意事项。）

其他解决方案

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

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

#7 楼

值得注意的是，有多少贡献者正在帮助传播有关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成为了自己。 DNS记录（例如，删除长期损坏的服务器），然后使用较短的TTL即可使更改快速传播（一旦您做好了就可以这样做），因此请考虑在知道该问题之前需要花费多长时间，并进行手动更改-而且事实是，普通客户端仅需在TTL到期时重新搜索可用的服务器即可。

DNS轮询具有两个出色的功能，使其非常具有成本效益在各种各样的情况下-首先是免费的，其次是在地理上与您的客户群一样分散。

它并没有引入一个新的“失败单元”，而其他所有“聪明人”系统呢。没有添加的组件可能会在整个相互链接的元素负载上遇到常见的并发故障。

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

是的，DNS循环绝对是“足够好”，这是您将单个静态内容托管在一个服务器中的第一步地点。

#8 楼

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

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

#9 楼

我一直使用具有较长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，这通常会很好。服务器也可能在事务处理过程中瘫痪，即使使用最好的负载平衡器，您也无法处理这种情况。
对于动态内容，必须使会话/数据库/文件同步，否则您将无法处理此问题（但对于真正的负载平衡器也是如此）。

附加说明：您可以使用iptables在自己的IP上测试行为。例如，在您的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:的假标题。

因此，如果您需要在一台服务器上进入维护模式，只需使用一个iptables q 4312079q规则禁用HTTP / HTTPS流量，所有请求都将发送到其他服务器（稍等一会，对于用户来说几乎不明显）。

#10 楼

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

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

#11 楼

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

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

这肯定是对SPOF的改进，但只是边缘。我将看一下谁在托管您的服务器，并查看他们所提供的服务，其中许多人可以提供某种基本的负载均衡器服务。

您可能还拥有一台服务器，静态内容在S3中重复，并在主数据库断开时切换到S3 CNAME。您将得到相同的延迟，但无需花费多台服务器。

#12 楼

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

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

我敢肯定，我会被否决因为我不是在讲100％高可用性的解决方案，但这不是您要求的。归结为您愿意接受的解决方案与花费的精力。

#13 楼

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

如前一篇文章所述，您需要一些东西来检测心跳并停止击中心跳，直到恢复。
/>
好消息是，无论在交换机还是Windows中，心跳的价格都非常便宜。

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

#14 楼

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

它的优点是，对于您的服务客户而言，设置中无需进行任何更改，而您无需不必担心DNS缓存或TTL，但是您仍然可以利用DNS循环“负载平衡”。

#15 楼

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

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

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

#16 楼

为了简洁地回答这个问题（循环DNS是否足以胜任启动程序，总比没有强，“为我们的静态内容提供“同时研究并实现更好的替代方案”负载均衡形式？），我要说它总比没有好，但您绝对应该继续研究其他形式的负载平衡。

#17 楼

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

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

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

#18 楼

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

由于以下原因，您肯定不会获得真正的负载平衡解决方案所提供的真实平衡分配。 Internet的拓扑。我仍然会观察所有涉及的服务器上的负载。