相关疑难解决方法(0)

从阅读来看，似乎不推荐 DNS 故障转移，因为 DNS 不是为它设计的。但是，如果您在不同子网上有两个 Web 服务器托管冗余内容，那么还有哪些其他方法可以确保在一台服务器出现故障时将所有流量路由到实时服务器？

对我来说，似乎 DNS 故障转移是这里唯一的故障转移选项，但共识是这不是一个好的选择。然而像 DNSmadeeasy.com 这样的服务提供了它，所以它一定有它的优点。任何意见？

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

针对 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章）中说明了选播器故障切换是关系到BGP收敛。出于这个原因，任播可以使用 15 分钟到 20 秒来完成。在为此优化拓扑的网络上，20 秒是可能的。可能只有 …