我正在寻找实现负载均衡器负载平衡的方法。
我们希望创建一个完全 HA 网络。我们所有的服务器都是冗余的，数据库也是冗余的，但在它们之上是一台运行 nginx 的服务器，作为反向代理来分发请求。
我正在寻找一种方法来消除这个危险热点，即使其他的都是冗余的，但如果这台服务器宕机了，就没有人会再接收请求了。
我来这里是为了寻求你的帮助。
我找到了两种解决这个问题的方法：
FloatingIP：使用 Kubernetes 创建负载均衡器集群 = 我有一个唯一的集群 IP 地址，可以让我与所有节点通信。我以前做过这种解决方案，所以我有一个负载均衡器集群，它们都运行相同的 nginx 服务，但我们的路由器不允许我记下要向其发送请求的目标 IP 地址，我只能选择一个设备。由于集群 IP 地址未连接到物理机器，因此我无法在我们的路由器中使用它。
找到一个直接处理向多个服务器发送请求的路由器（如 nginx 中的上游块）。
我确实认为浮动 IP 是最好的选择，但我不明白为什么我的路由器不能使用它，所以如果你有能够使用浮动 IP 的路由器，我会喜欢它。
几个星期以来，我一直在寻找一个可以同时完成这两项功能的路由器，或者寻找其他解决方案。
欢迎任何帮助
答案1
为了便于解释，我们先定义“高可用性”一词，这意味着我们保证总有某个系统可以处理负载。通常，它是通过冗余系统来实现的，但这并不意味着负载将在它们之间分配；有可能在任何时候，单个系统都会处理所有负载。负载平衡是高可用性的一个特殊情况，其中负载在冗余系统之间分配，因此可以通过添加集合中所有系统的容量来潜在地增加服务的容量。
HAproxy 手册指出，负载平衡器通常可以胜过它平衡的大约 1000 个应用服务器（在同一硬件上运行），因此您实际上不需要平衡它。由于平衡器和服务的容量存在差距，对平衡器进行负载平衡几乎没有用处，但这仍会增加解决方案的复杂性。您将增加复杂性（增加解决方案的成本并损失一些可靠性），而没有明显的收益。
通常，您可以通过让平衡器了解其当前负载，从而做出有根据的猜测，将下一个请求发送到何处，来平衡服务器的负载。平衡器本身通过使其冗余，从而实现高可用性。浮动 IP 被分配给当前正在执行的平衡器（“主”）系统，如果发生故障，则会迅速重新分配给另一个系统（“备用”）。其余时间，备用系统静止不动。我明白整个系统运行但不执行任何操作似乎很浪费，但这不是浪费，这是您保证服务可能中断将很快结束的保证。您可以平衡一些其他服务在这对服务器上运行，角色互换，因此冗余不会显得那么浪费，但请注意，在停机事件期间，两个服务将由同一系统平衡，因此需要容量来同时运行它们，否则两个服务都会降级，因此“浪费”是不可避免的。您还可以通过为同一服务设置两个浮动 IP 并将它们都发布到 DNS 中以相同的名称进行一些随机负载分配，因此每个客户端将随机选择一些平衡器。通常您有两个平衡器，您可以使用 keepalived（使用 VRRP）管理浮动 IP；这是最简单的方法，只需很少的设置。
您可能还会有一些静止的使用 Netfilter 的 CLUSTERIP 目标将负载分配到平衡器。在此设置中，所有系统都分配了相同的 IP 地址，并且该 IP 地址与某个广播 MAC 地址相关联，因此所有系统都可以看到所有流量。但是，每个系统只选择一部分流量进行处理，而忽略其他所有内容；选择是为了让每个请求分配给一个且只有一个处理器。分配完全基于请求的来源，不考虑系统的负载，因此分配是“盲目的”。分配看起来是伪随机的，并且可能只有一个节点获得所有负载。其背后的算法要求所有参与系统都知道其中有多少个当前在线（并且每个系统都有一个唯一的个人编号），因此不会有请求丢失或由多个系统处理。如果任何一个集群处理器发生故障，所有其他活动系统必须立即重新配置自己以解决一个处理器的丢失问题，否则它们中的任何一个都不会认为自己是该故障系统之前处理的请求的有效处理器。Linux 的 Pacemaker 包括资源代理，以便正确使用此 CLUSTERIP 目标（包括重新配置）。此配置要复杂得多，因此更脆弱，需要更多的维护和监控。它需要 Pacemaker（设置起来并不容易）和集群消息传递层（例如 Corosync），此外，正确的基于 Pacemaker 的设置需要隔离。
我有一个由 keepalived 管理的非平衡冗余平衡器和浮动 IP 的设置，我也有一个由 Pacemaker 管理的 CLUSTERIP 的设置，但我从未尝试将所有这些与 Kubernetes 结合起来。
答案2
使用故障转移 IP 是一种糟糕的解决方案。如果不破坏某些东西，就无法检查其是否正常工作。它只使用了一半的容量。检测到活动节点发生故障可能需要很长时间。
忘记尝试恢复节点发生故障时正在处理的请求。这是可能的，但确实非常困难且成本高昂。
使用 2 个反向代理实例并配置循环 DNS。读到这篇文章时，许多 IT 专业人员会开始拿起键盘，认为循环 DNS 无法提供高可用性。虽然根据 TCP 的原始规范，客户端应该等待超时 - 大约 5 分钟。然而，至少从千禧年开始，浏览器就已发生故障转移很多速度更快 - 2005 年，Chrome 和 Firefox 可在不到半秒的时间内完成故障转移，而 MSIE 则需要大约 10-20 秒。我最近没有测试过这一点。
巧合的是，这也是为您的原始服务器实现网络多路径的最简单的方法。