DNS 负载平衡和故障转移

361 阅读4分钟

携手创作,共同成长!这是我参与「掘金日新计划 · 8 月更文挑战」的第14天,点击查看活动详情

DNS 负载平衡和故障转移

负载平衡是指许多有助于在不同网络服务器之间分配工作负载和流量的分发技术。用人的角度来看,这个概念很简单:工作的人手越多,每个人要做的工作就越少,工作就越有效率。在计算机网络方案中,这种“社区劳动力”有助于提高整体计算效率,从而提高吞吐量、优化性能并最大限度地减少停机时间。

本地与全局负载平衡

最初,负载平衡是指在一个位置(例如,单个数据中心)的服务器之间分配流量。然而,今天的计算越来越在线,也越来越全球化。因此,负载平衡具有更广泛的含义。

如下文所述,早期 GSLB 解决方案依赖于 DNS 负载平衡,这限制了其性能和功效。如今,云计算为本地和全球负载平衡提供了出色的解决方案,使一个基于云的服务能够处理这两种情况。

DNS:不同步且无法识别负载

曾经是全球服务器负载平衡的标准,DNS解决方案现在被认为主要适用于简单的应用程序或网站。越来越多的网络管理员认识到 DNS 负载平衡无法满足企业级 GSLB 的要求,原因有很多。

首先,基于 DNS 的服务使用为不同地理区域定义的负载平衡池。负载平衡器管理员定义哪些 Web 服务器可用以及应将流量路由到这些服务器的频率。从理论上讲,这可以最大限度地利用地理位置分散的基础设施。

但是,DNS 负载平衡基于传统的轮循机制分发方法。这意味着负载平衡器会查看服务器列表,并依次向每个服务器发送一个连接。每次到达列表末尾时,它都从列表顶部开始。

问题在于,分发的轮循机制方法不具有负载感知能力 , 负载平衡器无法知道下一个排队的服务器是否实际上是最佳选择。这会导致服务器次利用率或过载。

此外,DNS 记录没有本机故障检测。这意味着可以将请求定向到列表中的下一个服务器,即使该服务器没有响应。

最后,基于 DNS 的负载平衡容易受到延迟的影响。这是因为要使 DNS 更改生效,必须在 ISP 级别记录它。ISP 每 TTL(生存时间)周期仅刷新一次 DNS 缓存。这意味着,在更新缓存之前,ISP 并不知道发生了更改,并继续将流量路由到错误的服务器。

此问题的解决方法(如将 TTL 设置为较低值)已经开发,但这些方法可能会对性能产生负面影响,并且仍然不能保证正确定向所有用户。

DNS 妥协:成本高昂的应用、拆分架构、上游缓存问题

DNS 妥协:成本高昂的应用、拆分架构、上游缓存问题

TTL 依赖还意味着对负载分配指令的更改传播速度要慢得多,从而导致响应低、故障转移延迟和负载重新分配延迟。

此外,更改的传播是不均匀的,因为每个ISP都有自己的DNS缓存规则。

例如,请考虑以下方案:

  • 给定的应用程序在两台服务器上运行:服务器 A 和服务器 B。TTL 周期设置为一小时(一个通用值)。
  • 在任何给定时刻,服务器 A 上的负载都可能增加,以至于 DNS 负载平衡器需要开始将流量路由到服务器 B
  • 但是,如果负载峰值达到 TTL 周期距离更新还有 20 分钟,会发生什么情况?在这种常见情况下,需要 20 分钟才能重新分配负载。
  • 与此同时,所有流量仍将路由到过载的服务器,从而导致逐渐增加的延迟,减慢交付速度并导致服务降级 , 甚至达到服务故障点。
  • 即使在20分钟后,一些ISP也会保留DNS缓存。这意味着,不可预测的流量百分比仍将被错误地路由,从而导致性能不均衡。