![对于静态内容的负载平衡来说,循环 DNS 是否“足够好”?](https://linux22.com/image/502681/%E5%AF%B9%E4%BA%8E%E9%9D%99%E6%80%81%E5%86%85%E5%AE%B9%E7%9A%84%E8%B4%9F%E8%BD%BD%E5%B9%B3%E8%A1%A1%E6%9D%A5%E8%AF%B4%EF%BC%8C%E5%BE%AA%E7%8E%AF%20DNS%20%E6%98%AF%E5%90%A6%E2%80%9C%E8%B6%B3%E5%A4%9F%E5%A5%BD%E2%80%9D%EF%BC%9F.png)
我们有一组共享的静态内容,可在我们的网站之间提供http://sstatic.net。不幸的是,这些内容目前根本没有负载平衡——它们由单个服务器提供。如果该服务器出现问题,所有依赖它的站点实际上都会瘫痪,因为共享资源是必不可少的共享 javascript 库和图像。
我们正在寻找方法来平衡该服务器上的静态内容负载,以避免单一服务器依赖。
我意识到循环 DNS 充其量只是一个低端(有些人甚至会说贫民窟) 解决方案,但我不禁想知道——对于静态内容的基本负载平衡来说,循环 DNS 是否是一个“足够好”的解决方案?
在[DNS] [负载平衡]标签,并且我已经阅读了一些关于该主题的精彩帖子。
我知道通过多个循环 A 记录进行 DNS 负载平衡的常见缺点:
- DNS 记录通常没有心跳或故障检测,因此如果轮换中的某个服务器发生故障,则必须手动从 DNS 条目中删除其 A 记录
- 为了实现这一功能,生存时间 (TTL) 必须设置得非常低,因为 DNS 条目会在整个互联网上被积极缓存
- 客户端计算机负责查看是否存在多个 A 记录并选择正确的记录
但是,循环 DNS 是否足以作为入门工具,总比没有好,因为我们要研究和实施更好的替代方案来平衡我们的静态内容?或者 DNS 循环在以下情况下几乎毫无价值:任何情况?
答案1
Jeff,我不同意,负载平衡并不意味着冗余,事实恰恰相反。服务器越多,在特定时刻发生故障的可能性就越大。这就是为什么在进行负载平衡时冗余是强制性的,但不幸的是,有很多解决方案只提供负载平衡而不执行任何健康检查,导致服务可靠性降低。
DNS 轮询非常适合增加容量,因为它将负载分布在多个点(可能在地理上分散)。但它不提供故障转移。您必须首先描述要尝试覆盖的故障类型。必须使用标准 IP 地址接管机制(VRRP、CARP 等)在本地覆盖服务器故障。交换机故障由服务器上到两个交换机的弹性链路覆盖。WAN 链路故障可以通过您和您的提供商之间的多链路设置来覆盖,使用路由协议或第 2 层解决方案(例如:多链路 PPP)。站点故障应由 BGP 覆盖:您的 IP 地址会在多个站点上复制,并且您只在它们可用时将它们宣布到网络上。
从您的问题来看,您似乎只需要提供服务器故障转移解决方案,这是最简单的解决方案,因为它不涉及任何硬件,也不与任何 ISP 签订合同。您只需要在服务器上设置适当的软件即可,这是迄今为止最便宜、最可靠的解决方案。
您问“如果 haproxy 机器发生故障怎么办?”。答案是一样的。我认识的所有使用 haproxy 进行负载平衡和高可用性的人都有两台机器,并在它们上运行 ucarp、keepalived 或 heartbeat,以确保其中一台始终可用。
希望这有帮助!
答案2
作为负载平衡,它虽然功能有限,但或多或少还是有效的。如果您有一台服务器因负载过大而崩溃,并且想将其分散到多台服务器上,那么这可能是这样做的一个很好的理由,至少是暂时的。
循环 DNS 作为负载“平衡”的方式受到很多合理的批评,并且除了作为短期的权宜之计外,我不建议为此目的而使用它。
但您说您的主要动机是避免单服务器依赖。如果没有某种自动方式将死机服务器从轮换中移除,那么它作为防止停机的方法就没有什么价值。(如果使用自动方式从轮换中移除服务器,并且 TTL 较短,那么它就会变成贫民窟故障转移。手动方式甚至都不是。)
如果您的两台循环服务器中有一台发生故障,则 50% 的客户将遇到故障。这比只有一台服务器的 100% 故障要好,但几乎任何其他真正进行故障转移的解决方案都比这要好。
如果一台服务器发生故障的概率为 N,那么两台服务器发生故障的概率为 2N。如果没有自动化,快速地故障转移,此方案增加部分用户遭遇失败的概率。
如果你打算手动将死机的服务器从轮换中移除,那么你将受到执行速度的限制和DNS TTL。如果服务器在凌晨 4 点死机怎么办?真正的故障转移最好的部分是可以整晚安睡。 您已使用 HAProxy,所以你应该熟悉它。我强烈建议使用它,因为 HAProxy 就是为这种情况而设计的。
答案3
循环 DNS 并非人们所想的那样。作为 DNS 服务器软件的作者(即绑定)我们遇到一些用户,他们想知道为什么他们的循环调度无法按计划运行。他们不明白,即使 TTL 为 0 秒,也会有一些缓存,因为有些缓存无论如何都会设置一个最短时间(通常为 30-300 秒)。
此外,虽然您的 AUTH 服务器可能会进行循环,但不能保证您关心的服务器(用户使用的缓存)会这样做。简而言之,循环不能从客户端的角度保证任何顺序,只能保证您的 auth 服务器为缓存提供的内容。
如果您想要真正的故障转移,DNS 只是其中一步。为两个不同的集群列出多个 IP 地址并不是一个坏主意,但我会在那里使用其他技术(例如简单任播)来进行实际的负载平衡。我个人讨厌硬件负载平衡硬件,因为它会干扰 DNS,因为它通常会出错。并且不要忘记 DNSSEC 即将推出,因此如果您确实选择该领域的某些东西,请询问您的供应商在您签署区域时会发生什么。
答案4
我读完了所有答案,有一件事我没有注意到,那就是如果服务器没有响应,大多数现代网络浏览器都会尝试其中一个备用 IP 地址。如果我没记错的话,Chrome 甚至会尝试多个 IP 地址并继续使用最先响应的服务器。所以在我看来,DNS 循环负载平衡总是比没有好。
顺便说一句:我认为 DNS Round Robin 更像是一种简单的负载分配解决方案。