如何在N台apache服务器之间平衡传入的Web流量？

我正在寻找使用诸如Heartbeat / Squid / Varnish / etc之类的东西来平衡内部apache实例之间的传入流量。这必须是软件，而不是硬件，因为我的所有东西都在VPS上运行。我在这方面没有很多经验，所以很抱歉如果我滥用术语并选择错误的软件包。

我起草了一些东西来说明我的追求。绿色部分是初始设置的样子，蓝色部分是由于流量增加而添加更多apache实例后的样子。这可能不是这些东西的工作方式，但理想情况下，我会将平衡器的IP添加到域的DNS中。然后，均衡器将查看每个apache实例上有多少个连接（通过内部IP或永恒IP的一些配置列表），并平均分配连接。蓝色是第二个平衡器，因为我确信平衡器有时也会需要帮助。

也许我要解决这个错误，但是我正在寻找有关“平衡器”应该是什么的信息以及有关如何设置它们的最佳实践的帮助。

任何帮助都会很棒。

几乎任何“反向代理”都会满足您的要求。

例如Varnish，Pound和HAProxy都擅长于它们的工作，但是它们也有它们的区别-但是，对于您的要求，它们中的任何一个都可以。就个人而言，我认为您最好使用HAProxy，但这只是一个猜测。

您最好阅读有关负载均衡器的文章，以帮助您确定所需的负载：http : //1wt.eu/articles/2006_lb/

此外，您可能会考虑为此使用预先构建的服务-例如在Amazon的Elastic Compute Cloud上运行软件并使用其Elastic Load Balancing。

首先，必须解决一个重要的问题：
您是否需要由负载均衡器处理用户会话并始终将其驱动到同一Web服务器（如果存在）？

• 不需要会话：在这种情况下，您应该使用高效的nginx程序作为负载平衡器。配置很容易设置，您基本上只需要在一条upstream upstream_name { server1, ..., serverN }语句中指示Web服务器列表，然后，对于给定的域，您需要一个简单的proxy_pass upstream_name指令。
  参见Nginx Wiki。

• 会话要求，也有一个类似的磅设置，在其中您将指示将托管会话ID（ID MYCOOKIENAME）的Cookie的名称，然后是BACKEND所有服务器的列表。
  例如参见磅设置示例。

当需要多个负载平衡器时，您可能需要进行heartbeat配置，以确保只有一个平衡器可以为给定域安装虚拟IP（如果需要会话，或者可以同时安装两个并为两个IP地址馈送DNS）实例）。也许有必要时，应该在另一个问题中对此进行详细说明（随着工具的快速发展）。
例如，另请参阅此链接。

您应该有一个很好的理由将额外的复杂性和单点故障引入架构。

循环负载均衡

• 不花钱
• 易于实施和管理
• 在客户端实施故障转移-唯一可以可靠地检测到故障的地方
• 隐式支持服务器相似性，但仍允许故障转移而不会出现与粘性会话相关的会话管理问题
• 在群集节点上不需要其他软件/硬件/配置

令我惊讶的是，关于轮循的错误信息数量如此之多。如果我是一个愤世嫉俗的人，我可能想知道是否与那些生产昂贵的大负载均衡硬件的供应商有联系。

我要承认的唯一一点是

1. IPV4地址正变得稀缺，因此价格昂贵-但仍然很多。比说Cisco CSS便宜得多。

2. 互联网越来越多地在Web服务上运行-并非所有开发人员都根据规范实现DNS支持。但是我曾经使用的每个浏览器都可以正常工作

在此处开始您的任务：http : //httpd.apache.org/docs/2.1/mod/mod_proxy_balancer.html和http://www.barneyb.com/barneyblog/2009/02/26/apache-httpds-mod_proxy_balancer/

对于平衡器，您可以在http://www.linuxvirtualserver.org/上查看LVS ，也许运行ldirectord和heartbeat来引导流量并执行故障转移。

Nginx作为上游代理很棒，我已经在每天执行1M +唯一身份的配置中成功使用了它

好，这是前一段时间被问到的，我迟到了。尽管如此，这里还是要添加一些东西。

杰基，你几乎钉牢了。您的插图显示了在大多数中小型安装中如何处理负载平衡。

您应该阅读Nakedible链接的Willy Tarreau的负载平衡介绍。它仍然有效，并且是一个很好的介绍。

您需要考虑这些如何满足您的需求：

• TCP / IP级别的负载平衡器（Linux Virtual Server等）。每个连接开销最低，速度最高，无法“看到” HTTP。
• HTTP级别的负载平衡器（HAProxy，nginx，Apache 2.2，Pound，Microsoft ARR等）。较高的开销，可以查看HTTP，可以gzip HTTP，可以执行SSL，可以执行粘性会话负载平衡。
• HTTP反向代理（Apache Traffic Server，Varnish，Squid）。可以将可缓存的对象（某些网页，css，js，图像）存储在RAM中，并将它们转发到后续客户端，而无需后端Web服务器。通常可以做一些与L7 HTTP负载平衡器相同的事情。

还有第二个平衡器，因为我确信平衡器有时也会需要帮助。

好吧，当然。但是负载均衡很简单，通常单个负载均衡器可以快速运行。我链接到这篇文章，在网络上引起了不小的关注，仅作为单个现代服务器可提供的性能标准的一个示例。在需要之前，请勿使用多个LB。当您需要通用方法时，最前端是IP级别的负载均衡器（或DNS Round Robin），而HTTP级别的负载均衡器则是代理和Webapp服务器。

提供有关“平衡器”应该是什么的帮助以及有关如何设置它们的最佳实践。

故障点是会话状态处理，某种程度上是故障状态行为。设置负载均衡器本身比较简单。

如果您仅使用2-4个后端Webapp服务器，则基于原始IP地址的静态散列是可行的。这避免了Webapp服务器之间共享会话状态的需要。每个webapp节点看到总流量的1 / N，并且在正常操作中，客户到服务器的映射是静态的。但是，它不适用于较大的安装。

从最佳意义上讲，两种最佳负载均衡算法是循环负载均衡和真正的随机负载均衡 ，它们在高负载下甚至负载分配均具有良性行为。这两个都要求您的Web应用程序在webapp节点上具有可用的全局会话状态。如何完成此操作取决于webapp技术堆栈。但是通常可以使用标准解决方案。

如果静态散列或共享会话状态都不适合您，则通常选择“ 粘性会话 ”负载平衡和每服务器会话状态。在大多数情况下，这很好用，这是一个完全可行的选择。

平衡器将查看每个apache实例上有多少个连接（通过内部IP或永恒IP的某些配置列表），并平均分配连接

是的，某些网站使用此功能。存在的许多不同的负载平衡算法有许多名称。如果您可以选择轮循或随机（或加权轮循，加权随机），则出于上述原因，我建议您这样做。

最后一件事：不要忘记许多厂商（F5，Cisco和其他高端厂商，fx Coyote Point和Kemp Technologies以更合理的价格）提供成熟的负载平衡设备。