我目前有一个网站服务器运行我的网站，所有的要求直接在那里。 networking服务器在轨道上运行ruby，一切都很顺利，但随着我的网站的增长，我将需要一个更大的服务器，或扩大与更多的服务器处理额外的负载。
我想和第二种情况一起去。 我不想拥有一台巨大的服务器，而想要两台或者三台更小，更便宜的服务器。 这是我认为应该这样做的：
所有域指向xxx30（HAProxy）。当HAProxy收到一个GET请求时，它将这个请求发送给可用的最不繁忙的web服务器。 networking服务器直接响应客户端。 通过这种设置，我可以随时添加Web服务器，并通过将问题Web服务器从群集中解放出来，从而快速解决任何问题。
xxx30 <-- HAProxy xxx31 <-- webserver1: Rails/Passenger3 xxx32 <-- webserver2: Rails/Passenger3 我的理解是否正确？
是的 – 我认为你有基本的下拍function：
这是代理 – 而且只是一个代理与基于TCP的任何东西 – 不只是HTTP。 它不提供文件 – 它只是代理。
HAProxy提供了大量的负载平衡algorithm，包括一个“最less连接”策略，用最less的挂起连接来select后端。
后端可以通过URL进行健康和健康检查，以避免将请求路由到脑损坏的后端。 （它甚至可以错开这些检查以避免尖峰。）
一个专门的状态页面为您提供后端状态，正常运行时间和很多非常好的指标。 请求可以基于各种东西进行路由：Cookie，URL子string，客户端IP等。
listen app_a_proxy 127.0.0.1:8100 # - equal weights on all servers # - queue requests on HAPRoxy queue once maxconn limit on the appserver is reached # - minconn dynamically scales the connection concurrency (bound my maxconn) depending on size of HAProxy queue # - check health of app. server every 20 seconds server a1 127.0.0.1:8010 weight 1 minconn 3 maxconn 6 check inter 20000 server a1 127.0.0.1:8010 weight 1 minconn 3 maxconn 6 check inter 20000 listen app_b_proxy 127.0.0.1:8200 # - second cluster of servers, for another app or a long running tasks server b1 127.0.0.1:8050 weight 1 minconn 1 maxconn 3 check inter 40000 server b2 127.0.0.1:8051 weight 1 minconn 1 maxconn 3 check inter 40000 server b3 127.0.0.1:8052 weight 1 minconn 1 maxconn 3 check inter 40000
在这里查看一些额外的例子和细节
你大部分都是正确的，但是你所掩盖的一个细节是响应部分。 您所描述的设置称为“直接路由”，意思是数据包进入负载均衡器，转发到后端服务器，该服务器直接回复客户端，而不通过负载均衡器。
为了使DR正常工作，还需要在所有Web服务器上都存在负载平衡器IP地址。 但是，您需要禁用其他服务器上的这些地址的ARP响应。 以下是CentOS对此的讨论 。
另外要记住的是，这个代理现在可能成为一个瓶颈或一个单一的失败点。 通常，在设置这些负载平衡代理时，它们被设置为高可用性机器集群，以便在一个或一个机器上进行维护而不会导致整个站点停机。
除DR之外，您还可以执行NAT，其中Web服务器使用负载平衡器作为网关，Web服务器使用私有IP，负载平衡器将其转换为公有IP。 这通常更容易configuration，因为你不需要担心ARP问题或不对称路由等。
最后，不常用的一种方法是使用iptables CLUSTERIP模块。 该模块根据远程IP地址或IP地址和端口号来阻止stream量，并了解运行集群中的哪个节点。 所以，你需要将所有机器的IP地址configuration为别名，并configurationCLUSTERIP。 它使用连接信息的散列，以便集群中的每台机器都同意哪个节点处理它。 数据包在不处理数据的节点上被阻塞，并且被节点所接受。 这是通过使用低级组播MAC地址完成的。
这很好，因为你没有一个专门的负载平衡器失败。 但是，它有点原始，显然不能基于URL或其他“七层”信息进行负载均衡，只能基于IP地址。
这里有一篇关于去年如何创buildCLUSTERIP的文章 。
有很多select，我们根据情况使用它们。 他们都有自己的优点和缺点，具体取决于你的情况，目标和经验水平。