☰

在预算内平衡 Apache 负载？

tag-icon • tag-icon apache-2.2 load-balancing high-availability redundancy
在预算内平衡 Apache 负载？

我正在努力理解负载平衡的概念，以确保可用性和冗余度，以便在出现问题时让用户满意，而不是为了向数百万用户提供极快的速度而进行负载平衡。

我们的预算有限，并试图坚持做那些有大量可用知识的东西，因此在 Ubuntu VPS 上运行 Apache 似乎是一个策略，直到一些著名的搜索引擎收购我们（包括周六讽刺，请注意）。

至少对我来说，这是一个完全不同的解决方案丛林。我们通过快速谷歌搜索找到了 Apache 自己的 mod_proxy 和 HAproxy，但由于我对负载平衡一无所知，我不知道哪种方案适合我们的情况，也不知道在选择解决方案解决可用性问题时我们要注意什么。

对我们来说最好的选择是什么？我们应该怎么做才能在不超出预算的情况下获得高可用性？

答案1

我使用的解决方案（可以使用 VPS 轻松实现）如下：

  • DNS 循环（sp？）到 6 个不同的有效 IP 地址。
  • 我有 3 个配置相同的负载均衡器，并使用corosync/pacemaker均匀分配6个IP地址（因此每台机器获得2个地址）。
  • 每个负载均衡器都有一个nginx+漆配置。Nginx 负责接收连接、执行重写和一些静态服务，并将其传回给执行负载平衡和缓存的 Varnish。

以我个人的观点来看，此拱门具有以下优点：

  1. 一旦某个 LB 发生故障，corosync/pacemaker 将重新分配 IP 地址。
  2. nginx 可用于从文件系统或 NFS 直接提供 SSL、某些类型的文件，而无需使用缓存（大视频、音频或大文件）。
  3. Varnish 是一个非常好的负载均衡器，支持重量、后端健康检查，并且作为反向代理做得非常出色。
  4. 如果需要更多 LB 来处理流量，只需向集群添加更多机器，IP 地址就会在所有机器之间重新平衡。您甚至可以自动执行此操作（添加和删除负载平衡器）。这就是为什么我对 3 台机器使用 6 个 ips，以留出一些增长空间。

就您而言，物理上分开的 VPS 是个好主意，但会使 IP 共享更加困难。目标是拥有一个防故障、冗余的系统，而一些用于负载平衡/HA 的配置最终会搞乱它，增加一个单点故障（例如，一个负载平衡器接收所有流量）。

我也知道您问过 apache，但当时我们有更适合这项工作的特定工具（如 nginx 和 varnish）。让 apache 在后端运行应用程序并使用其他工具为其提供服务（并不是说 apache 不能实现良好的负载平衡或反向代理，这只是将工作的不同部分卸载到更多服务的问题，以便每个部分都能很好地完成其分担）。

答案2

HAproxy 是一个很好的解决方案。配置相当简单。

您需要另一个 VPS 实例来位于至少 2 个其他 VPS 之前。因此，为了实现负载平衡/故障转移，您至少需要 3 个 VPS

还需要考虑以下几点：

  1. SSL 终止。如果您使用 HTTPS://，则该连接应在负载均衡器处终止，在负载均衡器后面，它应通过未加密的连接传递所有流量。

  2. 文件存储。如果用户上传了图片，它会去哪里？它只是放在一台机器上吗？你需要某种方式在机器之间即时共享文件 - 你可以使用亚马逊的 S3 服务来存储所有静态文件，或者你可以使用另一个 VPS 充当文件服务器，但我建议使用 S3，因为它冗余且非常便宜。

  3. 会话信息。负载均衡器配置中的每台机器都需要能够访问用户的会话信息，因为您永远不知道他们会访问哪台机器。

  4. db - 您有单独的 db 服务器吗？如果您现在只有一台机器，您如何确保您的新机器可以访问 db 服务器 - 如果它是一台单独的 VPS db 服务器，那有多冗余。拥有高可用性 Web 前端和一台 db 服务器的单点故障不一定有意义，现在您还需要考虑 db 复制和从属升级。

所以我曾经和你一样，这就是一个网站每天几百次点击量所带来的麻烦。它很快就会变得复杂。希望这能给你一些思考的空间 :)

答案3

我投票赞成Linux 虚拟服务器作为负载平衡器。这使得 LVS 控制器成为单点故障和瓶颈，但

  1. 根据我的经验，瓶颈不是什么问题；LVS 重定向步骤是第 3 层，并且（从计算上来说）极其便宜。
  2. 应通过设置第二个控制器来处理单点故障，这两个控制器由Linux 高可用性。

通过将第一个控制器与第一个 LVS 节点放在同一台机器上，将第二个控制器与第二个 LVS 节点放在同一台机器上，可以降低成本。第三个及后续节点是纯节点，不涉及 LVS 或 HA。

这也使您可以自由运行任何您喜欢的 Web 服务器软件，因为重定向发生在应用程序层之下。

答案4

您可能需要考虑使用适当的集群软件。RedHat（或 CentOS） 集群套件或 Oracle 的集群软件。这些可用于设置主动-被动集群，可用于重新启动服务，并在出现严重问题时在节点之间发生故障。这基本上就是您正在寻找的。

所有这些集群解决方案都包含在相应的操作系统许可证中，因此您可能对成本不感兴趣。它们确实需要某种共享存储——要么是 NFS 安装，要么是两个节点使用集群文件系统访问的物理磁盘。后者的一个例子是允许多主机访问的 SAN 磁盘，格式化为OCFS2或者政府金融服务局我相信你可以使用 VMWare共享磁盘为了这。

集群软件用于定义始终在节点上运行的“服务”，或者仅在该节点处于“活动”状态时运行的“服务”。节点通过心跳进行通信，并监控这些服务。如果发现故障，它们可以重新启动这些服务，如果无法修复，它们可以重新启动。

您基本上会配置一个单独的“共享”IP 地址，流量将被定向到该地址。然后也可以定义 apache 和任何其他必要的服务，并且仅在活动服务器上运行。共享磁盘将用于您的所有 Web 内容、任何上传的文件以及您的 apache 配置目录。（使用 httpd.conf 等）

根据我的经验，这种方法非常有效。

  • 不需要 DNS 循环或任何其他单点故障负载均衡器 - 所有内容都只需要一个 IP/FQDN。
  • 用户上传的文件进入共享存储，因此不必关心您的机器是否发生故障。
  • 开发人员无需任何额外培训即可将内容上传到该单个 IP/FQDN，并且即使发生故障转移，内容也始终是最新的。
  • 管理员可以将离线机器拿下来，对其进行修补，然后重新启动等。然后对活动节点进行故障转移。使升级所需的停机时间最短。
  • 现在，过时的节点可以暂时不打补丁，从而使故障恢复同样变得容易。（比 VMWare 快照更快）
  • Apache 配置的更改是共享的，因此在故障转移期间不会发生任何奇怪的事情，因为管理员忘记在离线设备上进行更改。


——克里斯托弗·卡雷尔

相关内容