11
多个数据中心和HTTP流量：DNS Round Robin是确保即时故障转移的唯一方法吗？
指向同一域的多个A记录似乎几乎专门用于将DNS Round Robin作为一种廉价的负载平衡技术来实现。 通常，针对DNS RR的警告是它不利于高可用性。当1个IP发生故障时，客户端将继续使用几分钟。 通常建议使用负载平衡器作为更好的选择。 两种说法都不完全正确： 如果流量为HTTP，则大多数HTML浏览器都可以在前一个A记录关闭时自动尝试下一个A记录，而无需进行新的DNS查找。阅读此章节3.1和这里。 当涉及多个数据中心时，DNS RR是在它们之间分配流量的唯一选择。 那么，在多个数据中心和HTTP流量存在的情况下，使用DNS RR是确保一个数据中心发生故障时立即进行故障转移的唯一方法吗？ 谢谢， 华伦天奴 编辑： 当然，每个数据中心都有一个带热备用的本地负载均衡器。 为了即时故障转移而牺牲会话亲和力是可以的。 AFAIK DNS推荐数据中心而不是另一个数据中心的唯一方法是仅使用与该数据中心关联的IP进行答复。如果数据中心无法访问，那么所有这些IP也将无法访问。这意味着，即使智能HTML浏览器能够立即尝试另一个A记录，所有尝试都将失败，直到本地缓存条目到期并且完成新的DNS查找，从而获取新的工作IP（我假设DNS会自动向A建议一个新的数据中心发生故障时）。因此，“智能DNS”不能确保即时故障转移。 相反，DNS轮询允许它。当一个数据中心发生故障时，智能HTML浏览器（大多数）将立即尝试将另一个缓存的A记录跳转到另一个（工作）数据中心。因此，DNS循环并不能确保会话亲和性或最低的RTT，但似乎是确保客户端为“智能” HTML浏览器时即时故障转移的唯一方法。 编辑2： 有人建议使用TCP Anycast作为最终解决方案。在此纸（第6章）中说明了任播故障转移有关BGP收敛。因此，Anycast可能需要15分钟到20秒才能完成。在为此优化拓扑的网络上，可能需要20秒。可能只有CDN运营商可以授予这样的快速故障转移。 编辑3：* 我做了一些DNS查找和跟踪路由（也许有些专家可以仔细检查），并且： 使用TCP Anycast的唯一CDN似乎是CacheFly，其他运营商（如CDN网络和BitGravity）都使用CacheFly。似乎它们的边缘不能用作反向代理。因此，它们不能用于授予即时故障转移。 Akamai和LimeLight似乎使用了可感知地理位置的DNS。但！他们返回多个A记录。从traceroutes看来，返回的IP在同一数据中心上。因此，我对一个数据中心出现故障时它们如何提供100％SLA感到困惑。