在预算上负载均衡Apache？

我试图绕过负载平衡的概念，以确保可用性和冗余以在出现问题时使用户满意，而不是为了向数百万用户提供更快的速度而进行负载平衡。

我们的预算有限，并且一直坚持要掌握很多知识，因此在一些著名的搜索引擎收购Apache之前，在Ubuntu VPS上运行Apache似乎是一种策略（包括周六具有讽刺意味的请注意）。

至少对我而言，这是一个可用的不同解决方案的完整丛林。Apache自己的mod_proxy和HAproxy是我们通过谷歌快速搜索找到的两个，但是负载平衡经验为零，我不知道什么适合我们的情况，或者在选择解决方案来解决我们的问题时需要注意什么可用性问题。

对我们来说最好的选择是什么？我们如何做才能在不超出预算的情况下提高可用性？

我使用的解决方案如下，并且可以通过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和清漆）。让apache在后端运行应用程序并使用其他工具为其提供服务（不是apache无法完成良好的负载平衡或反向代理，这只是将工作的不同部分分担给更多服务的问题，因此每个部分都可以做得很好它的份额）。

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

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

还有一些要考虑的事情是：

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

2. 文件存储。如果用户将图像上传到哪里？它只是坐在一台机器上吗？您需要某种方式在计算机之间即时共享文件-您可以使用Amazon的S3服务来存储所有静态文件，或者可以有另一个充当文件服务器的VPS，但是我建议使用S3，因为它冗余且价格便宜。

3. 会话信息。负载平衡器配置中的每台计算机都必须能够访问用户的会话信息，因为您永远不知道他们将攻击哪台计算机。

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

因此，我一直不知所措，这就是一个网站的麻烦，该网站每天要执行几百次点击才能真正运行。快速变得复杂。希望能给你一些思考的东西:)

我的投票赞成将Linux Virtual Server用作负载平衡器。这使LVS导向器成为单点故障和瓶颈，但是

1. 以我的经验来看，瓶颈不是问题。LVS重定向步骤是第3层，而且（从计算上来说）非常便宜。
2. 出现单点故障应通过设置第二个控制器来解决，两个控制器由Linux HA控制。

通过使第一个导向器与第一个LVS节点位于同一台计算机上，并使第二个导向器与第二个LVS节点位于同一台计算机上，可以降低成本。第三和后续节点是纯节点，不涉及LVS或HA。

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

这个链子怎么样？

轮循dns>两台机器上的haproxy> nginx来分离静态文件> apache

可能还使用果皮或心跳来确保haproxy始终有效。如果您也需要SSL，则Stunnel会位于haproxy的前面

您可能要考虑使用适当的群集软件。RedHat（或CentOS）的 Cluster Suite或Oracle的ClusterWare。这些可用于设置主动-被动群集，并可用于重新启动服务，并在出现严重问题时在节点之间失败。这本质上就是您要寻找的。

所有这些群集解决方案都包含在各自的OS许可证中，因此您的成本可能很酷。它们确实需要某种方式的共享存储-NFS挂载或由具有群集文件系统的两个节点访问的物理磁盘。后者的一个示例是允许多个主机访问的SAN磁盘，其格式为OCFS2或GFS。我相信您可以使用VMWare 共享磁盘为此。

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

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

以我的经验，这非常有效。

• 不需要DNS轮询或任何其他单故障点负载均衡器-一切都达到一个IP / FQDN。
• 用户上传的文件将进入该共享存储，因此不必关心您的计算机是否进行故障转移。
• 开发人员将内容上传到该IP / FQDN，而无需进行额外的零培训，并且如果故障转移，则该内容始终是最新的。
• 管理员可以将脱机计算机拿走，修补掉它，重新启动等。然后使活动节点发生故障。进行升级所需的停机时间最少。
• 现在，该过期节点可以保持一段时间不打补丁，从而使故障回复同样容易。（比VMWare快照快）
• 共享对Apache配置的更改，因此在故障转移期间不会发生任何奇怪的事情，因为管理员忘记在离线框中进行更改。

克里斯托弗·卡雷尔（Christopher Karel）

最佳的负载平衡可能非常昂贵且复杂。基本的负载平衡应仅确保每台服务器随时为大致相同的命中次数提供服务。

最简单的负载平衡方法是在DNS中提供多个A记录。默认情况下，将以循环方式配置IP地址。这将导致用户在服务器之间相对均匀地分布。这对于无状态站点非常有效。当您有状态的站点时，需要一种稍微复杂的方法。

要处理有状态的需求，可以使用重定向。给每个Web服务器一个备用地址，例如www1，www2，www3等。将初始www连接重定向到主机的备用地址。您可能最终会以这种方式遇到书签问题，但是它们应该均匀分布在服务器之间。

或者，使用不同的路径指示哪个服务器正在处理有状态会话，将允许将主机切换到原始服务器的代理会话。当故障服务器的会话到达从故障服务器接管的服务器时，这可能是一个问题。但是，禁止群集软件的状态无论如何都将丢失。由于使用浏览器缓存，因此更改服务器可能不会遇到很多会话。

可以通过将服务器配置为接管发生故障的服务器的IP地址来处理故障转移。如果服务器发生故障，这将最大程度地减少停机时间。没有群集软件，如果服务器发生故障，有状态会话将丢失。

如果没有故障转移，用户将经历一段时间的延迟，直到他们的浏览器故障转移到下一个IP地址为止。

使用Restful服务而不是有状态会话应消除前端的集群问题。存储方面的群集问题仍然适用。

即使将负载平衡器放在服务器前面，您也可能会在它们前面使用轮询DNS。这将确保您的所有负载均衡器得到利用。它们将为您的设计增加另一层，从而增加额外的复杂性和另一个故障点。但是，它们可以提供一些安全功能。

最佳解决方案将取决于相关要求。

实现图像服务器以提供诸如图像，CSS文件和其他静态内容之类的内容可以减轻应用程序服务器上的负载。

我通常使用一对相同的OpenBSD机器：

• 使用RelayD进行负载平衡，Web服务器监视和处理故障Web服务器
• 使用CARP可提高负载均衡器本身的可用性。

OpenBSD轻便，稳定且相当安全-非常适合网络服务。

• http://www.openbsd.org-主站点
• http://www.openbsd.org/faq/pf/carp.html-鲤鱼文档
• https://calomel.org/relayd.html-一套不错的RelayD方法

首先，我建议您设置layer3。它避免了复杂的防火墙（PF）设置。这是一个/etc/relayd.conf文件示例，该文件显示了带有监视后端Web服务器的简单中继负载平衡器的设置：

# $OpenBSD: relayd.conf,v 1.13 2008/03/03 16:58:41 reyk Exp $
#
# Macros
#

# The production internal load balanced address
intralbaddr="1.1.1.100"

# The interface on this load balancer with the alias for the intralbaddr address
intralbint="carp0"

# The list of web/app servers serving weblbaddress
intra1="1.1.1.90"
intra2="1.1.1.91"

# Global Options
#
# interval 10
timeout 1000
# prefork 5

log updates

# The "relaylb" interface group is assigned to the intralbint carp interface
# The following forces a demotion in carp if relayd stops
demote relaylb

#
# Each table will be mapped to a pf table.
#
table <intrahosts> { $intra1 $intra2 }

# Assumes local webserver that can provide a sorry page
table <fallback> { 127.0.0.1 }

#
# Relay and protocol for HTTP layer 7 loadbalancing and SSL acceleration
#
http protocol httprelay {
        return error
        header append "$REMOTE_ADDR" to "X-Forwarded-For"
        header append "$SERVER_ADDR:$SERVER_PORT" to "X-Forwarded-By"
        # header change "Connection" to "close"

        # Various TCP performance options
        tcp { nodelay, sack, socket buffer 65536, backlog 128 }

#       ssl { no sslv2, sslv3, tlsv1, ciphers HIGH }
#       ssl session cache disable
}

relay intra-httprelay {
        listen on $intralbaddr port 80
        protocol httprelay

        # Forward to hosts in the intrahosts table using a src/dst hash
        # The example shows use of a page with dynamic content to provide
        # application aware site checking.  This page should return a 200 on success,
        # including database or appserver connection, and a 500 or other on failure
        forward to <intrahosts> port http mode loadbalance \
                check http "/nlbcheck.asp" code 200

}

您是否已将 EC2与cloudfoundry或Elastic Beantalk一起使用，或者只是简单地使用旧的AWS自动扩展思想。我一直在使用它，它可以很好地缩放，并且可以在没有任何人为干预的情况下进行弹性缩放。

假设您说您对负载平衡的经验为零，我建议您使用这些选项，因为它们只需极少的“煎炸”即可启动和运行。

可能会更好地利用您的时间。