Apache模块mod_proxy_balancer

负载均衡器调度程序算法

当前，有4种负载均衡器调度程序算法可供使用：请求计数（mod_lbmethod_byrequests），加权流量计数（mod_lbmethod_bytraffic），待处理的请求计数（mod_lbmethod_bybusyness）和心跳流量计数（mod_lbmethod_heartbeat）。这些是通过lbmethodBalancer定义的值控制的。请参阅ProxyPass 指令以获取更多信息，尤其是有关如何配置Balancer和BalancerMembers的信息。

负载均衡器粘性

平衡器支持粘性。当请求被代理到某个后端时，则来自同一用户的所有后续请求都应被代理到同一后端。许多负载均衡器通过将客户端IP地址映射到后端的表来实现此功能。这种方法对客户端和后端透明，但存在一些问题：如果客户端自身隐藏在代理之后，负载分配将不相等；如果客户端使用在会话期间发生变化的动态IP地址，则发生粘性错误；如果发生故障，则会丢失粘性。映射表溢出。

该模块mod_proxy_balancer在两种替代方式之上实现了粘性：Cookie和URL编码。提供cookie既可以由后端完成，也可以由Apache Web服务器本身完成。URL编码通常在后端进行。

平衡器配置示例

在深入探讨技术细节之前，这里有一个示例，说明如何使用mod_proxy_balancer它在两个后端服务器之间提供负载平衡：

<Proxy "balancer://mycluster">
    BalancerMember "http://192.168.1.50:80"
    BalancerMember "http://192.168.1.51:80"
</Proxy>
ProxyPass        "/test" "balancer://mycluster"
ProxyPassReverse "/test" "balancer://mycluster"

mod_headers即使后端服务器未设置合适的会话cookie，也如何使用来提供具有粘性的负载平衡的另一个示例：

Header add Set-Cookie "ROUTEID=.%{BALANCER_WORKER_ROUTE}e; path=/" env=BALANCER_ROUTE_CHANGED
<Proxy "balancer://mycluster">
    BalancerMember "http://192.168.1.50:80" route=1
    BalancerMember "http://192.168.1.51:80" route=2
    ProxySet stickysession=ROUTEID
</Proxy>
ProxyPass        "/test" "balancer://mycluster"
ProxyPassReverse "/test" "balancer://mycluster"

导出的环境变量

目前，导出了6个环境变量：

BALANCER_SESSION_STICKY

为该请求分配用于当前请求的stickysession值。它是用于粘性会话的cookie或请求参数的名称

BALANCER_SESSION_ROUTE

分配了从当前请求中解析出的路由。

BALANCER_NAME

为当前请求分配了平衡器的名称。该值类似于balancer://foo。

BALANCER_WORKER_NAME

为该请求分配用于当前请求的工作程序的名称。该值类似于http://hostA:1234。

BALANCER_WORKER_ROUTE

这分配了将用于当前请求的工作程序的路由。

BALANCER_ROUTE_CHANGED

如果会话路由与工作路由不匹配（​​BALANCER_SESSION_ROUTE！= BALANCER_WORKER_ROUTE）或会话尚未建立的路由，则将其设置为1。这可用于确定使用粘性会话时何时/是否需要向客户端发送更新的路由。

启用Balancer Manager支持

此模块需要的服务 mod_status。平衡器管理器可实现平衡器成员的动态更新。您可以使用Balancer Manager更改特定成员的平衡因子，或将其置于离线模式。

因此，为了得到负载均衡管理的能力， mod_status并且mod_proxy_balancer 必须存在于服务器中。

要为example.com域中的浏览器启用负载均衡器管理，请将此代码添加到您的httpd.conf 配置文件中

<Location "/balancer-manager">
    SetHandler balancer-manager
    Require host example.com
</Location>

现在，您可以使用Web浏览器访问页面来访问负载平衡器管理器 http://your.server.name/balancer-manager。请注意，<Location ...> Manager只能动态控制在容器外部定义的平衡器。

负载均衡器粘性的详细信息

使用基于cookie的粘性时，您需要配置cookie的名称，其中包含有关使用哪个后端的信息。这可以通过添加到或 的stickysession属性来完成。Cookie的名称区分大小写。平衡器提取cookie的值，并查找路由等于该值的成员worker 。该路线也必须在任一组 或 。Cookie可以由后端设置，也可以由Apache Web服务器本身在上例中显示 。ProxyPassProxySetProxyPassProxySet

某些后端使用粘性Cookie的形式略有不同，例如Apache Tomcat。Tomcat将Tomcat实例的名称添加到其会话ID cookie的末尾，并在会话ID中以点号（.）分隔。因此，如果Apache Web服务器在粘性cookie的值中找到一个点，则它仅使用该点后面的部分来搜索路由。为了让Tomcat知道其实例名称，您需要jvmRoute将Tomcat配置文件中的属性设置为连接到相应Tomcat的辅助线程conf/server.xml的路由值 。Tomcat（更常见的是基于servlet的Java Web应用程序）使用的会话cookie的名称为JSESSIONID （大写），但可以配置为其他内容。

实现粘性的第二种方法是URL编码。Web服务器在请求的URL中搜索查询参数。使用stickysession再次指定参数的名称。该参数的值用于查找路由 等于该值的成员worker 。由于提取和处理响应中包含的所有URL链接并不容易，因此通常将参数添加到每个链接的工作是由后端生成内容来完成的。在某些情况下，使用mod_substitute或 通过网络服务器执行此操作可能是可行的mod_sed。但是，这可能会对性能产生负面影响。

Java标准实现的URL编码略有不同。他们使用以分号（;）作为分隔符的URL信息附加到URL ，并在后面添加会话ID。与cookie一样，Apache Tomcat可以jvmRoute在此路径信息中包含配置的内容。要让Apache找到这种路径信息，您需要将其设置 scolonpathdelim为Onin ProxyPass或 ProxySet。

最后，通过配置cookie的名称和用竖线（|）分隔的URL参数的名称，可以同时支持cookie和URL编码，如以下示例所示：

ProxyPass "/test" "balancer://mycluster" stickysession=JSESSIONID|jsessionid scolonpathdelim=On
<Proxy "balancer://mycluster">
    BalancerMember "http://192.168.1.50:80" route=node1
    BalancerMember "http://192.168.1.51:80" route=node2
</Proxy>

如果cookie和request参数都提供同一请求的路由信息​​，则使用来自request参数的信息。

解决负载均衡器粘性

如果您遇到粘性错误，例如用户丢失了应用程序会话并需要再次登录，则首先要检查这是因为后端有时不可用还是您的配置错误。要了解后端可能存在的稳定性问题，请检查Apache错误日志中是否存在代理错误消息。

要验证您的配置，请首先检查粘性是基于Cookie还是基于URL编码。下一步将使用增强的，在访问日志中记录适当的数据 LogFormat。以下字段很有用：

%{MYCOOKIE}C

Cookie中名称为的值MYCOOKIE。名称应与stickysession 属性中提供的名称相同。

%{Set-Cookie}o

这将记录后端设置的所有cookie。您可以跟踪后端是否设置了您期望的会话cookie，以及将其设置为哪个值。

%{BALANCER_SESSION_STICKY}e

用于查找路由信息的cookie或请求参数的名称。

%{BALANCER_SESSION_ROUTE}e

在请求中找到的路线信息。

%{BALANCER_WORKER_ROUTE}e

选择的工人的路线。

%{BALANCER_ROUTE_CHANGED}e

设置为1如果请求中的路由与工作方的路由不同，即不能将请求粘滞。

会话丢失的常见原因是会话超时，通常可以在后端服务器上对其进行配置。

如果日志级别设置为debug或更高，则平衡器还将有关处理粘性的详细信息记录到错误日志中 。这是解决粘性问题的简便方法，但是对于高负载下的生产服务器，日志量可能很高。