1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
|
<?xml version="1.0"?>
<!DOCTYPE modulesynopsis SYSTEM "../style/modulesynopsis.dtd">
<?xml-stylesheet type="text/xsl" href="../style/manual.en.xsl"?>
<!-- $LastChangedRevision$ -->
<!--
Licensed to the Apache Software Foundation (ASF) under one or more
contributor license agreements. See the NOTICE file distributed with
this work for additional information regarding copyright ownership.
The ASF licenses this file to You under the Apache License, Version 2.0
(the "License"); you may not use this file except in compliance with
the License. You may obtain a copy of the License at
http://www.apache.org/licenses/LICENSE-2.0
Unless required by applicable law or agreed to in writing, software
distributed under the License is distributed on an "AS IS" BASIS,
WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
See the License for the specific language governing permissions and
limitations under the License.
-->
<modulesynopsis metafile="mod_proxy_balancer.xml.meta">
<name>mod_proxy_balancer</name>
<description><module>mod_proxy</module> extension for load balancing </description>
<status>Extension</status>
<sourcefile>mod_proxy_balancer.c</sourcefile>
<identifier>proxy_balancer_module</identifier>
<summary>
<p>This module <em>requires</em> the service of <module
>mod_proxy</module> and it provides load balancing for
all the supported protocols. The most important ones are:</p>
<ul>
<li>HTTP, using <module>mod_proxy_http</module></li>
<li>FTP, using <module>mod_proxy_ftp</module></li>
<li>AJP13, using <module>mod_proxy_ajp</module></li>
<li>WebSocket, using <module>mod_proxy_wstunnel</module></li>
</ul>
<p>The Load balancing scheduler algorithm is not provided by this
module but from other ones such as:</p>
<ul>
<li><module>mod_lbmethod_byrequests</module></li>
<li><module>mod_lbmethod_bytraffic</module></li>
<li><module>mod_lbmethod_bybusyness</module></li>
<li><module>mod_lbmethod_heartbeat</module></li>
</ul>
<p>Thus, in order to get the ability of load balancing,
<module>mod_proxy</module>, <module>mod_proxy_balancer</module>
and at least one of load balancing scheduler algorithm modules have
to be present in the server.</p>
<note type="warning"><title>Warning</title>
<p>Do not enable proxying until you have <a
href="mod_proxy.html#access">secured your server</a>. Open proxy
servers are dangerous both to your network and to the Internet at
large.</p>
</note>
</summary>
<seealso><module>mod_proxy</module></seealso>
<seealso><directive module="mod_proxy">BalancerMember</directive></seealso>
<seealso><directive module="mod_proxy">BalancerGrowth</directive></seealso>
<seealso><directive module="mod_proxy">BalancerPersist</directive></seealso>
<seealso><directive module="mod_proxy">BalancerInherit</directive></seealso>
<section id="scheduler">
<title>Load balancer scheduler algorithm</title>
<p>At present, there are 4 load balancer scheduler algorithms available
for use: Request Counting (<module>mod_lbmethod_byrequests</module>),
Weighted Traffic Counting (<module>mod_lbmethod_bytraffic</module>),
Pending Request Counting (<module>mod_lbmethod_bybusyness</module>) and
Heartbeat Traffic Counting (<module>mod_lbmethod_heartbeat</module>).
These are controlled via the <code>lbmethod</code> value of
the Balancer definition. See the <directive module="mod_proxy">ProxyPass</directive>
directive for more information, especially regarding how to
configure the Balancer and BalancerMembers.</p>
</section>
<section id="stickyness">
<title>Load balancer stickyness</title>
<p>The balancer supports stickyness. When a request is proxied
to some back-end, then all following requests from the same user
should be proxied to the same back-end. Many load balancers implement
this feature via a table that maps client IP addresses to back-ends.
This approach is transparent to clients and back-ends, but suffers
from some problems: unequal load distribution if clients are themselves
hidden behind proxies, stickyness errors when a client uses a dynamic
IP address that changes during a session and loss of stickyness, if the
mapping table overflows.</p>
<p>The module <module>mod_proxy_balancer</module> implements stickyness
on top of two alternative means: cookies and URL encoding. Providing the
cookie can be either done by the back-end or by the Apache web server
itself. The URL encoding is usually done on the back-end.</p>
</section>
<section id="example">
<title>Examples of a balancer configuration</title>
<p>Before we dive into the technical details, here's an example of
how you might use <module>mod_proxy_balancer</module> to provide
load balancing between two back-end servers:
</p>
<highlight language="config">
<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"
</highlight>
<p>Another example of how to provide load balancing with stickyness
using <module>mod_headers</module>, even if the back-end server does
not set a suitable session cookie:
</p>
<highlight language="config">
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"
</highlight>
</section>
<section id="environment">
<title>Exported Environment Variables</title>
<p>At present there are 6 environment variables exported:</p>
<dl>
<!-- ============= BALANCER_SESSION_STICKY =============== -->
<dt><var><a name="balancer_session_sticky" id="balancer_session_sticky">BALANCER_SESSION_STICKY</a></var></dt>
<dd>
<p>This is assigned the <var>stickysession</var> value used for the current
request. It is the name of the cookie or request parameter used for sticky sessions</p>
</dd>
<!-- ============= BALANCER_SESSION_ROUTE ================ -->
<dt><var><a name="balancer_session_route" id="balancer_session_route">BALANCER_SESSION_ROUTE</a></var></dt>
<dd>
<p>This is assigned the <var>route</var> parsed from the current
request.</p>
</dd>
<!-- ============= BALANCER_NAME ========================= -->
<dt><var><a name="balancer_name" id="balancer_name">BALANCER_NAME</a></var></dt>
<dd>
<p>This is assigned the name of the balancer used for the current
request. The value is something like <code>balancer://foo</code>.</p>
</dd>
<!-- ============= BALANCER_WORKER_NAME ================== -->
<dt><var><a name="balancer_worker_name" id="balancer_worker_name">BALANCER_WORKER_NAME</a></var></dt>
<dd>
<p>This is assigned the name of the worker used for the current request.
The value is something like <code>http://hostA:1234</code>.</p>
</dd>
<!-- ============= BALANCER_WORKER_ROUTE ================= -->
<dt><var><a name="balancer_worker_route" id="balancer_worker_route">BALANCER_WORKER_ROUTE</a></var></dt>
<dd>
<p>This is assigned the <var>route</var> of the worker that will be
used for the current request.</p>
</dd>
<!-- ============= BALANCER_ROUTE_CHANGED ================= -->
<dt><var><a name="balancer_route_changed" id="balancer_route_changed">BALANCER_ROUTE_CHANGED</a></var></dt>
<dd>
<p>This is set to 1 if the session route does not match the
worker route (BALANCER_SESSION_ROUTE != BALANCER_WORKER_ROUTE) or the
session does not yet have an established route. This can be used to
determine when/if the client needs to be sent an updated route
when sticky sessions are used.</p>
</dd>
</dl>
</section>
<section id="balancer_manager">
<title>Enabling Balancer Manager Support</title>
<p>This module <em>requires</em> the service of
<module>mod_status</module>.
Balancer manager enables dynamic update of balancer
members. You can use balancer manager to change the balance
factor of a particular member, or put it in the off line
mode.
</p>
<p>Thus, in order to get the ability of load balancer management,
<module>mod_status</module> and <module>mod_proxy_balancer</module>
have to be present in the server.</p>
<p>To enable load balancer management for browsers from the example.com
domain add this code to your <code>httpd.conf</code>
configuration file</p>
<highlight language="config">
<Location "/balancer-manager">
SetHandler balancer-manager
Require host example.com
</Location>
</highlight>
<p>You can now access load balancer manager by using a Web browser
to access the page
<code>http://your.server.name/balancer-manager</code>. Please note
that only Balancers defined outside of <code><Location ...></code>
containers can be dynamically controlled by the Manager.</p>
</section>
<section id="stickyness_implementation">
<title>Details on load balancer stickyness</title>
<p>When using cookie based stickyness, you need to configure the
name of the cookie that contains the information about which back-end
to use. This is done via the <var>stickysession</var> attribute added
to either <directive module="mod_proxy">ProxyPass</directive> or
<directive module="mod_proxy">ProxySet</directive>. The name of
the cookie is case-sensitive. The balancer extracts the value of the
cookie and looks for a member worker with <var>route</var> equal
to that value. The <var>route</var> must also be set in either
<directive module="mod_proxy">ProxyPass</directive> or
<directive module="mod_proxy">ProxySet</directive>. The cookie can either
be set by the back-end, or as shown in the above
<a href="#example">example</a> by the Apache web server itself.</p>
<p>Some back-ends use a slightly different form of stickyness cookie,
for instance Apache Tomcat. Tomcat adds the name of the Tomcat instance
to the end of its session id cookie, separated with a dot (<code>.</code>)
from the session id. Thus if the Apache web server finds a dot in the value
of the stickyness cookie, it only uses the part behind the dot to search
for the route. In order to let Tomcat know about its instance name, you
need to set the attribute <code>jvmRoute</code> inside the Tomcat
configuration file <code>conf/server.xml</code> to the value of the
<var>route</var> of the worker that connects to the respective Tomcat.
The name of the session cookie used by Tomcat (and more generally by Java
web applications based on servlets) is <code>JSESSIONID</code>
(upper case) but can be configured to something else.</p>
<p>The second way of implementing stickyness is URL encoding.
The web server searches for a query parameter in the URL of the request.
The name of the parameter is specified again using <var>stickysession</var>.
The value of the parameter is used to lookup a member worker with <var>route</var>
equal to that value. Since it is not easy to extract and manipulate all
URL links contained in responses, generally the work of adding the parameters
to each link is done by the back-end generating the content.
In some cases it might be feasible doing
this via the web server using <module>mod_substitute</module> or
<module>mod_sed</module>. This can have negative impact on performance though.</p>
<p>The Java standards implement URL encoding slightly different. They use
a path info appended to the URL using a semicolon (<code>;</code>)
as the separator and add the session id behind. As in the cookie case,
Apache Tomcat can include the configured <code>jvmRoute</code> in this path
info. To let Apache find this sort of path info, you neet to set
<code>scolonpathdelim</code> to <code>On</code> in
<directive module="mod_proxy">ProxyPass</directive> or
<directive module="mod_proxy">ProxySet</directive>.</p>
<p>Finally you can support cookies and URL encoding at the same time, by
configuring the name of the cookie and the name of the URL parameter
separated by a vertical bar (<code>|</code>) as in the following example:</p>
<highlight language="config">
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>
</highlight>
<p>If the cookie and the request parameter both provide routing information
for the same request, the information from the request parameter is used.</p>
</section>
<section id="stickyness_troubleshooting">
<title>Troubleshooting load balancer stickyness</title>
<p>If you experience stickyness errors, e.g. users lose their
application sessions and need to login again, you first want to
check whether this is because the back-ends are sometimes unavailable
or whether your configuration is wrong. To find out about possible
stability problems with the back-ends, check your Apache error log
for proxy error messages.</p>
<p>To verify your configuration, first check, whether the stickyness
is based on a cookie or on URL encoding. Next step would be logging
the appropriate data in the access log by using an enhanced
<directive module="mod_log_config">LogFormat</directive>.
The following fields are useful:</p>
<dl>
<dt><code>%{MYCOOKIE}C</code></dt>
<dd>The value contained in the cookie with name <code>MYCOOKIE</code>.
The name should be the same given in the <var>stickysession</var>
attribute.</dd>
<dt><code>%{Set-Cookie}o</code></dt>
<dd>This logs any cookie set by the back-end. You can track,
whether the back-end sets the session cookie you expect, and
to which value it is set.</dd>
<dt><code>%{BALANCER_SESSION_STICKY}e</code></dt>
<dd>The name of the cookie or request parameter used
to lookup the routing information.</dd>
<dt><code>%{BALANCER_SESSION_ROUTE}e</code></dt>
<dd>The route information found in the request.</dd>
<dt><code>%{BALANCER_WORKER_ROUTE}e</code></dt>
<dd>The route of the worker chosen.</dd>
<dt><code>%{BALANCER_ROUTE_CHANGED}e</code></dt>
<dd>Set to <code>1</code> if the route in the request
is different from the route of the worker, i.e.
the request couldn't be handled sticky.</dd>
</dl>
<p>Common reasons for loss of session are session timeouts,
which are usually configurable on the back-end server.</p>
<p>The balancer also logs detailed information about handling
stickyness to the error log, if the log level is set to
<code>debug</code> or higher. This is an easy way to
troubleshoot stickyness problems, but the log volume might
be to high for production servers under high load.</p>
</section>
</modulesynopsis>
|