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

Posted 2023-04-15

【中文标题】分布式应用程序 - 负载均衡器是单点故障吗？

【英文标题】：Distributed application - is load balancer single point of failure?

【发布时间】：2017-03-28 19:32:49

【问题描述】：

总的来说，我想了解

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

我已经看到（在论文/幻灯片上）设计可以为同一个应用程序设置多个 apache 负载平衡器。

我和我的同事讨论过 - 将多个 IP 地址/VM/unix 框（具有负载平衡器硬件设备）映射到同一个 DNS 域（如 www.amazon.com） - 但是谁来处理什么基础/算法请求将转到哪个特定的 IP/unix 框（映射到 amazon.com/DNS）

我的问题：在请求流的开始（在第一个入口点） - 只有一台机器（根据某种算法将请求发送到下面的负载均衡器），如果这台机器发生故障，分布式系统（有多个负载均衡器和集群等）将下降

【问题讨论】：

我不明白你的问题是什么。能说清楚吗？

【参考方案1】：

对不起，如果我把它吹得不成比例。

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

为什么会这样？假设您只有一个 LB，并且它还能够轻松处理您可能拥有的所有流量，您还需要确保您不会出现任何硬件故障或任何其他类型的故障可能发生您的设备停机（极端情况下数据中心崩溃）。

如何处理问题？

我在这里只提一下，仅仅在应用程序服务器前面添加层并不一定能解决所有问题，相反，您正在添加“网络跃点”，因此在每个要求。有时也会使故障排除变得更加困难，增加成本以及复杂基础架构带来的所有其他坏事。 这就是为什么我需要一个很好的理由来让不同的 LB 排队。

直言不讳，我将遵循的架构（类似于您在论文上看到的那种）是在您的基础设施前面有两个 LB（仅当它们难以处理您的流量时才超过两个）和 DNS它们之间的负载均衡。

当然，这个解决方案有缺点，DNS 不知道您后端的状态，因此您没有故障转移功能。

您可以通过使用与您的 DNS 合作的强大监控系统来解决这个问题，以完成对 DNS 的自动更改，并以此实现故障转移功能。 再次，您必须接受 DNS 绑定到生存时间 (TTL)，并且某些客户端将在失败时缓存“错误”的 ip。

您意识到上述内容并不完美，但可能（大多数情况下）是您唯一的解决方法。

对于对停机时间的容忍度更低的情况（即使对于一部分客户端），我会留下几个替代方案。

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

边界网关协议 (BGP)，您必须通过您的 isp 实现此功能。此处的实现可能非常复杂，并且必须自定义才能针对您的需求进行优化。和以前一样，您再次为双重基础架构感到头疼。但是，如果您最终采用了这种解决方案，那么您很可能会在多个地方启动并运行。

如上所述，一个托管在云中的强大 LB 对于大多数网络应用程序/网站来说已经足够了。

【参考方案2】：

我现在也在 2021 年研究这个问题。虽然像 nginx 这样的简单选项非常方便，但它们似乎确实提供了单点故障。

今天的解决方案是使用 Kubernetes 或 Docker Swarm 方法，这似乎变得非常复杂，但在每个节点或至少一个故障转移的主节点中都内置了负载平衡。

如果做不到这一点，来自 Google、AWS 或 Azure 等大公司之一的基于云的负载均衡器可能会提供必要的正常运行时间。