使用多个 A 记录的基于浏览器的 DNS 故障转移

Question

最近我注意到，为主机名设置多个 A 记录不仅可以用于循环负载平衡，还可以用于自动故障转移。

因此我尝试测试一下：

1. 我从我们的域名加载了一个页面
2. 记录了我们的哪些服务器提供了该页面
3. 关闭该主机上的 Web 服务器
4. 重新加载页面

浏览器确实会自动尝试使用其他服务器来加载页面。此方法在 Opera、Safari、IE 和 Firefox 中均有效。只有 Chrome 无法尝试使用其他服务器。

但在让该服务器离线几分钟并查看访问日志后，我发现对其他服务器的请求数量没有显著增加。当 3 台服务器中有 1 台离线时，我原本预计对剩余 2 台服务器的访问量将增加约 50%，但我只看到 7-10%。这只能意味着浏览器内的 DNS 故障转移对大多数浏览器/访问者不起作用，这与我刚刚测试的结果直接矛盾。

有人知道浏览器的 DNS 故障转移行为是怎么回事吗？自动故障转移对我有用，但对大多数访问者却不起作用，可能的原因是什么？

编辑：为了使自己清楚，我做了完全没有变化到我们的 DNS 设置；这里没有 TTL 或传播问题，这完全取决于客户端如何处理多个 A 记录。

Answer 1

好的，我首先要说的是，DNS 无论如何都不是一个好的故障转移系统，您需要反向代理或负载平衡器。体验不一样的原因有几个。首先，在 Chrome 中，它使用操作系统来获取 DNS 信息，因此 IP 取决于操作系统，因此在这种情况下，操作系统可能只给它一个 IP。

至于其他浏览器，其工作方式高度依赖于它们如何执行 DNS。因此，浏览器本身可能会决定不尝试其他 IP，甚至根据 DNS 服务器的响应多次尝试同一个 IP。

这将我们带到了 DNS 服务器本身，大多数服务器不尊重您的 TTL 记录，并且会保留它们，无论感觉多久，这意味着用户可以在相当长的一段时间内获取您的旧 IP...

第四，用户体验，你希望用户刷新 3 或 4 次才能访问你的网站吗？你的网站上是否有任何基于会话或登录的内容，如果浏览器在会话中途获得另一个 IP，会发生什么情况。如果你真的需要 HA 和正常运行时间，你真的需要考虑正确行事，老实说，否则最终会比只使用一台服务器更加支离破碎。

Answer 2

对我来说，如果你不想为昂贵的负载平衡器付费，这是一个不错的选择。请参阅我在此处的回复，了解如何处理浏览器：https://serverfault.com/a/868535/114520

现在，对于您所关心的问题，您是如何监控的accesses？是一些的大小吗access_log？是您网络服务器上每秒的请求数吗？

也许您在 Web 服务器上有一些缓存解决方案，如果请求已在缓存中，则不会访问您的动态服务器（PHP、Java……）。服务器越多，缓存前的请求就越多（如果它们不共享缓存）。

在假设这是 DNS 问题之前，请添加一个真正的监控：例如实时分析跟踪器或类似的东西。然后关闭一台服务器，看看实时跟踪器是否显示网站上的当前用户数量有所减少。

多年来，我一直非常乐意使用这种设置，并且仍然乐意使用。我只添加了一些故障转移解决方案：

• 在 2 个或 3 个节点上进行循环
• 每个节点都有：
  • 使用导向器/探测器对所有后端进行清漆
  • lighttpd（Apache 或 nginx 都可以！）在另一个端口上使用 fastcgi
  • PHP-FPM 池

如果一个 PHP-FPM 出现故障，Varnish 探测将失败并移除后端，直到探测再次正常。如果 Varnish 出现故障，则 Round-Robin+browser 将处理对另一个节点的更改。

Answer 3

当一个记录没有响应时，浏览器通常会非常积极地尝试替代记录。

有几件事：

1. 您在使用 Chrome 时遇到的问题可能与其缓存 DNS 的方式有关 - 它进行自己的缓存，并且非常积极；在您设置多个 A 记录之前，它是否可能仍然缓存着该条目？
2. 类似地，在添加额外记录后，您是否至少等待了 DNS 区域的 TTL 来测试从外部进入的用户？
3. 另外，首先要确保服务器之间的负载相当均匀；如果一台服务器只有 10% 的流量，那么当另一个节点死机时，您只能预期其负载会适度增加。

除此之外，DNS 循环对于地理冗余和负载平衡非常有用，但请记住，还有其他很好的解决方案可用于本地故障转移。