Add detailed information about how to use

session stickyness.


git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@1003131 13f79535-47bb-0310-9956-ffa450edef68

1 files changed, 122 insertions, 5 deletions

diff --git a/docs/manual/mod/mod_proxy_balancer.xml b/docs/manual/mod/mod_proxy_balancer.xml
index b1d422eca7..b2d1d948ad 100644
--- a/docs/manual/mod/mod_proxy_balancer.xml
+++ b/docs/manual/mod/mod_proxy_balancer.xml
@@ -59,11 +59,27 @@
 <section id="scheduler">
     <title>Load balancer scheduler algorithm</title>
     <p>At present, there are 3 load balancer scheduler algorithms available
-    for use: Request Counting, Weighted Traffic Counting and Pending Request 
+    for use: Request Counting, Weighted Traffic Counting and Pending Request
     Counting. 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.</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">
@@ -82,7 +98,7 @@
     </example>
 
     <p>Another example of how to provide load balancing with stickyness
-    using <module>mod_headers</module>, even if the backend server does
+    using <module>mod_headers</module>, even if the back-end server does
     not set a suitable session cookie:
     </p>
 
@@ -106,8 +122,8 @@
     <!-- ============= 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 in the current
-    request.  It is the cookie or parameter name used for sticky sessions</p>
+    <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 ================ -->
@@ -151,7 +167,7 @@
 
 </section>
 
-<section id="enable">
+<section id="balancer_manager">
     <title>Enabling Balancer Manager Support</title>
     <p>This module <em>requires</em> the service of 
     <module>mod_status</module>.
@@ -183,6 +199,107 @@
     <code>http://your.server.name/balancer-manager</code></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>
+    <example>
+    ProxyPass /test balancer://mycluster stickysession=JSESSIONID|jsessionid scolonpathdelim=On
+    &lt;Proxy balancer://mycluster&gt;<br />
+    BalancerMember http://192.168.1.50:80 route=node1<br />
+    BalancerMember http://192.168.1.51:80 route=node2<br />
+    &lt;/Proxy&gt;<br />
+    </example>
+    <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 loose 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>
+
 <directivesynopsis>
 <name>BalancerNonce</name>
 <description>Set the nonce used in the balancer-manager application</description>