☰

使用 Keepalived 进行主动/主动 HAProxy 设置时遇到的问题

tag-icon • tag-icon load-balancing haproxy high-availability keepalived
使用 Keepalived 进行主动/主动 HAProxy 设置时遇到的问题

如果之前已经问过这个问题，我很抱歉，但我似乎找不到太多相关信息。

我们将使用 HAProxy 来平衡 MariaDB Galera 集群的负载。我见过的所有关于此的文章/教程都使用 Keepalived（或类似的东西）进行主动/被动 HAProxy 设置。

有什么充分的理由说明为什么您不应该采用主动/主动设置？

每个 HAProxy 节点可以有一个固定 IP，并且两个节点都有一个浮动 IP。在正常情况下，请求在两个 HAProxy 节点之间共享，如果一个节点发生故障，另一个节点将使用其浮动 IP 并处理两个 IP 下的请求。当另一个节点恢复时，它将再次使用其浮动 IP 并分担负载。

我很感激您对此的意见。

路加

答案1

不要对同一资源使用两个虚拟 IP 地址进行主动/主动设置，需要考虑的重要事项是

  • 如何在两个虚拟 IP 上分配请求
  • 您如何处理粘性会话、亲和性、持久性等，即当后续请求开始转到虚拟 IP1 然后转到虚拟 IP2 时会发生什么，您是否需要这些请求转到同一个后端服务器。
  • 当虚拟 IP 地址故障转移到另一台主机时会发生什么？

答案2

我们曾经了解到 CDN 不适用于需要 mTLS（相互传输层安全性）会话的活动会话。对于 grpc 之类的协议来说，情况就是如此，您需要与终结器进行活动会话。在这种情况下，负载均衡器或收集器位于负载均衡器后面（以防负载均衡器仅处理会话的分发）。是的，这也可以在云中完成，但物联网应用总会有用例，您需要让收集器更接近物联网服务。无论如何，我喜欢你的说法！它与当今的解决方案非常吻合。

答案3

2020 年更新：keepalived已经过时了一段时间，因为它在虚拟云（AWS）中不起作用。

历史回顾

以前，办公室里有一台（思科）互联网路由器。该路由器为所有机器提供互联网接入，而且性能很好。

...然后路由器坏了，所有人的互联网都断了，这太糟糕了。

事实证明，任何东西都需要两个才能实现冗余。因此思科开始提供成对的、串联工作的路由器。

这是通过一个称为高速备份协议，虚拟专用网络备份组或者鲤鱼。高速备份协议是思科为解决该问题而制定的原始协议。它被标准化为虚拟专用网络备份组之后https://www.rfc-editor.org/rfc/rfc3768（1998 年）大多数网络设备和供应商都实施了该协议。BSD 人员重新发明了自己的协议鲤鱼为了做同样的事情，他们无法采用 VRRP，因为担心许可或专利问题。

Keepalived（和 uCARP）是实现 VRRP（和 CARP）的软件。它可以安装在两台常规 Linux 服务器上，以便在它们之间进行故障转移。

AWS 的崛起和 VRRP 的终结

VRRP 如何运作？首先，它需要一个浮动 IP，比如说 192.168.1.254，在任何时间点，只有一个路由器拥有该 IP 的所有权。网络中的设备只需将流量发送到该（浮动）IP 并到达活动路由器，它们不知道它是浮动的，也不关心。两个路由器不断相互通信，如果其中一个死机，另一个路由器将接管 IP 并开始处理流量。

此时，需要熟悉 OSI 网络第 2 层和第 3 层（MAC 和 IP）。网络设备与苹果和知识产权地址，地址解析为地址解析协议。

浮动 IP 被接管的概念涉及网络堆栈中的许多恶作剧（以上所有首字母缩略词），它不是完全设计好的，也不是预期的行为。

在物理网络上，多台计算机物理插入一个以太网交换机，它通常是可行的。

在虚拟机上，它通常不起作用。虚拟网络必须处理网络流量（MAC 和 IP 层），它通常会阻止魔术包或隔离虚拟主机，从而阻止 VRRP 运行。

在主要的虚拟云（AWS、Google 等）上。这肯定行不通，而且是故意的。想象一下，如果 AWS 实例可以接管另一个 Linux 实例（可能来自另一个客户）的 IP（所有流量）。这到底是怎么回事？！

云和 CDN 解决方案

云提供商提供负载均衡器解决方案，请参阅 AWS ELB 和 Google Cloud 负载均衡器。它们针对此问题提供了内置冗余，因此您无需考虑它。keepalived 已经过时了。

下一个方面是 CDN（CloudFlare、Akamai）。如今，所有公共网站都运行在 CDN 后面，CDN 提供缓存、过滤和 DDoS 保护。CDN 可以在多个上游服务器之间提供负载平衡。只需配置所有单独的服务器，流量就会被分割。

最后但并非最不重要的一点是，keepalived 仅允许在多个服务器中拥有一个活动服务器，说得更直白些，这是在浪费资源。这实际上是现实世界中的一个灾难性问题，因为事物需要扩展，而它在设计上无法扩展。当今使用的故障转移解决方案（如云和 CDN 中的解决方案）旨在将流量分配到所有活动目的地。实现起来要复杂得多，并且是在不同的层上累积完成的（请参阅、、、）DNS。keepalived 不再是大局的一部分。AnycastOSPFBGP

相关内容