分布式应用程序 - 负载均衡器是单点故障吗?

Lea*_*ner 6 dns networking load-balancing distributed-system

一般来说,我想了解分布式应用程序 - 负载均衡器是单点故障吗?

我不确定,但这可以是 Apache 负载均衡器,也可以是F5 Network等提供的设备/硬件负载均衡器。

我已经看到(在论文/幻灯片上)对于同一个应用程序,设计可以有多个 apache 负载均衡器。

我与我的同事进行了讨论 - 将多个 IP 地址/虚拟机/unix 框(具有负载平衡器硬件设备)映射到相同的 DNS 域(例如 www.amazon.com) - 但是谁将负责基于什么基础/算法请求将转到哪个特定的 IP/unix 框(映射到 amazon.com/DNS)

我的问题:在请求流的开始(在第一个入口点) - 只有一台机器(它根据某种算法将请求发送到下面的负载均衡器),如果这台机器出现故障,系统会受到干扰(有多个负载均衡器)和集群等)会下降

小智 15

抱歉,如果我把它夸大了。

考虑到单点故障 (SPOF) 的定义,如果您的 LB 发生故障,您的应用程序将不可用,因此简而言之,是的,单个 LB 或反向代理就是 SPOF。

为什么会这样?假设您只有一个 LB,并且它仍然能够轻松处理您可能拥有的所有流量,您还需要确保您不会受到任何硬件故障或可能导致您的设备损坏的任何其他类型的故障的影响down(极端情况数据中心崩溃)。

如何处理问题?

我只是在这里提到,仅在应用程序服务器前面添加层并不一定能解决所有问题,相反,您添加了“网络跃点”,这会导致每个请求中的时间开销,即使是很小的。有时还使故障排除变得更加困难,增加了成本,以及复杂的基础设施带来的所有其他不好的事情。这就是为什么我需要一个很好的理由让不同的LB排队

就这一点而言,我将遵循的架构(类似于您在论文中看到的那样)是基础设施前面的两个 LB(仅当它们处理您的流量有困难时才会超过两个)以及它们之间的 DNS 负载平衡。

当然,这个解决方案有缺点,DNS 与后端的状态无关,因此您没有故障转移功能。

您可以通过使用强大的监控系统与 DNS 配合来解决这个问题,以完成 DNS 的自动更改,从而实现故障转移功能。同样,您必须接受 DNS 与生存时间 (TTL) 绑定的事实,并且某些客户端在发生故障时会缓存“错误”的 IP。

好吧,正如您意识到上述并不完美,但可能(大多数时候)是您唯一的方法。

对于对停机时间的容忍度更低的情况(即使对于一部分客户),我将留下几个替代方案。

  1. 全球服务器负载均衡器(GSLB),它是一项服务,像这样,你会购买它。它总是按照您的意愿完成艰苦的工作,将流量路由到主动-被动架构(例如主灾难)或主动-主动(例如美国的一个数据中心和亚洲的另一个数据中心)。当然,这个解决方案(除了花费相当多)听起来很容易实现,尽管请记住为了使其正常工作而必须考虑的所有事情我不会深入技术我只会提到您将需要双硬件,必须将其配置为在数据中心之间独立工作,但在需要的地方完全同步。

  2. 边界网关协议 (BGP),您必须与您的 ISP 一起实施。这里的实现可能非常复杂,必须进行定制才能根据您的需求进行优化。和以前一样,您再次遇到双重基础设施的所有令人头疼的问题。但如果您最终采用了这一解决方案,那么您很可能会在多个地方启动并运行。

话虽如此,托管在云中的单个强大的 LB 对于大多数 Web 应用程序/网站来说已经足够了。