☰

如何制作冗余负载均衡器？

tag-icon • tag-icon nginx load-balancing redundancy load-balance
如何制作冗余负载均衡器？

我理解负载均衡器的目的是平衡服务器之间的负载并跟踪实例运行状况等。但是如果负载均衡器本身出现故障怎么办？如何设置冗余负载均衡器？（负载平衡负载均衡器？）

我知道 DNS 健康检查很有用，但显然存在严重的延迟问题，不是吗？

假设您不使用任何第三方服务（如 AWS ELB 或类似服务）。如果您只使用 Nginx，该怎么办？

答案1

有几种方法可以实现负载均衡器的 HA（高可用性） - 或者就任何服务而言。假设您有两台机器，它们的 IP 地址如下：

  • 192.168.100.101
  • 192.168.100.102

用户连接到一个 IP，因此您需要将 IP 与特定框分开 - 例如创建虚拟 IP。该 IP 将是 192.168.100.100。

现在，您可以选择 HA 服务，它将负责 IP 地址的自动故障转移/故障恢复。unix 的一些最简单的服务是 (u)carp 和 keepalived，一些更复杂的服务例如 RedHat Cluster Suite 或 Pacemaker。

让我们以 keepalived 为例 - 两个 keepalived 服务 - 分别在自己的机器上运行 - 它们相互通信。这种通信通常称为心跳。

|   VIP   |                           |         |
|  Box A  | ------v^-----------v^---- |  Box B  |
|   IP1   |                           |   IP2   |

如果一个 keepalived 停止响应（无论出于何种原因，服务都停止运行，或者设备反弹或关闭） - 另一个设备中的 keepalived 将注意到丢失的心跳，并会假定其他节点已死，然后采取故障转移措施。在我们的例子中，该操作将启动浮动 IP。

                                      |   VIP   |
    ------------------ -------------- |  Box B  |
                                      |   IP2   |

在这种情况下可能发生的最坏情况是客户端会话丢失，但它们将能够重新连接。如果要避免这种情况，两个负载平衡器必须能够同步它们之间的会话数据，如果它们可以做到这一点，用户将不会注意到任何事情，除了可能出现短暂的延迟。

这种设置的另一个缺陷是脑裂 - 当两个盒子都在线但链接被切断时，两个盒子都会调出相同的 IP。这通常通过某种隔离机制（SCSI 预留、IPMI 重启、智能 PDU 断电等）或奇数个节点（要求大多数集群成员处于活动状态才能启动服务）来解决。

|   VIP   |                           |   VIP   |
|  Box A  |                           |  Box B  |
|   IP1   |                           |   IP2   |

更复杂的集群管理软件（如 Pacemaker）可以移动整个服务（例如：在一个节点上停止它并在另一个节点上启动它） - 这是实现数据库等服务的 HA 的方式。

另一种可能的方式是利用 ECMP - 如果您控制负载均衡器附近的路由器。这种方法还使您能够水平扩展负载均衡器。这通过您的两个盒子中的每一个都与您的路由器进行 BGP 通信来实现。每个盒子都必须通告虚拟 IP（192.168.100.100），路由器将通过 ECMP 负载平衡流量。如果一台机器死机，它将停止通告 VIP，这反过来又会阻止路由器向它发送流量。在这个设置中，您唯一需要注意的是，如果负载均衡器本身死机，则停止通告 IP。

答案2

使用 Nginx 作为负载均衡器应该允许您按照这篇文章中详述的重定向，通过改变您的配置来检测无响应超时：

nginx 自动故障转移负载均衡

理论上，如果您拥有 HA 环境，则群集的多个负载均衡器应该允许在一个负载均衡器发生故障时维持服务。

希望这可以帮助。

答案3

多年来，硬件负载平衡器一直支持“主动/被动”或“主动/主动”设置，在这两种情况下，它们都是从第 1/2 层的角度并行设置的……主动/被动使用监控/保持活动机制，如上所述，主动/主动可以通过多种方式实现。为了在前端显示为单个 IP，两个或多个平衡器可能会执行以下操作（只要它们全部/两个都在线）：

  • 当客户端位于同一网络上时，根据源 MAC 地址或 IP 地址选择性地回答对共享 IP 的 ARP 请求
  • 相互协商由谁来处理给定的新 TCP 连接的流量
  • 让重复或错误的第 3-7 层流量肆意发生，并依靠客户端/路由器 TCP 堆栈进行整理

然后，当与合作伙伴设备的通信丢失时，将其模式更改为接受所有或更多流量。

在后端：

  • 在正常运行中，每个平衡器可能仅使用给定的应用服务器子池
  • 或者，重复的请求也可能在这里生成……
  • 或者，平衡器之间可以进行协商

相关内容