This section describes how to configure simple load balancing between two or more tc Runtime instances.
In this scenario, you configure an Enterprise Ready Server (ERS) httpd Server to run in front of the tc Runtime instances; this ERS httpd Server receives all requests from users, and it then passes them back to the tc Runtime instances using a specified load balancing algorithm. Responses from the tc Runtime instances are then routed back through this same ERS httpd Server. For this reason, the ERS httpd Server acts like a proxy (both reverse and forward) so that the users never know the URLs of the backend tc Runtime instance that are actually doing all the work. Additionally, the ERS httpd Server ensures that the load on each tc Runtime instance is balanced. You can specify that each tc Runtime instance take on an equal work load, or you can specify that one instance work twice as hard as the others.
Note: You can, of course, configure a standard Apache HTTP Server as the load balancer, rather than the ERS httpd Server as described in this procedure. The instructions are similar as far as the directives you add to the configuration file, although there are also slight differences, mostly in the location of the Apache HTTP configuration file and its name (
httpd.conf; in ERS it is called
httpsd.conf). See Apache HTTP Server Version 2.2 Documentation for details.
For clarity, the following scenario is assumed in the procedure. Note that these assumptions are not requirements; your environment might be very different. The assumptions are listed only to make the procedure easier to understand.
You have two tc Runtime instances running at the following two hosts and port numbers:
Additionally, the two tc Runtime instances are running on the same computer and are part of the same Standard Edition (runtime package) installation, and that their respective
CATALINA_BASE variables are as follows:
Each tc Runtime instance is configured exactly the same (other than the value of the various ports).
You have deployed the same application to both tc Runtime instances and the URL context is the same in both instances:
Further, you want all users that use the application to first go through the front-end ERS httpd Server, and any evidence of the backend tc Runtime instances upon which the application is actually deployed should be hidden from the user.
ERS httpd Server (Version 2.2.X) is installed on a different computer than tc Server. The name of the particular ERS httpd instance is
lb-server and its home directory is
You want to configure sticky sessions, which means that the ERS httpd Server always routes the requests for a particular session to the same tc Runtime instance that serviced the first request for that session.
You want to use the HTTP protocol for all communication between the ERS httpd Server and the tc Runtime instances.
The load balancing described in this procedure is very simple, although you have many options available to further customize it. At appropriate locations in the procedure, links to the Apache HTTP Server documentation are provided for additional configuration options not covered by this specific scenario. Adapt the procedure for your particular environment.
As part of the procedure, you will update the configuration files of both the ERS httpd Server and the two tc Runtime instances.
To configure load balancing for this scenario, follow these steps:
On the computer on which ERS httpd is installed, stop the instance, if it is currently running. Following our example and assumptions:
prompt$ cd /home/ers/servers/lb-server prompt$ bin/apache_startup.sh stop
httpsd.conf configuration file of the ERS httpd instance by adding the following
LoadModule directive which loads the ERS httpd
LoadModule proxy_balancer_module "ERS-INSTALL/apache2.2/modules/standard/mod_proxy_balancer.so"
ERS-INSTALL refers to the directory in which you installed ERS httpd. Following our example, the directive would be:
LoadModule proxy_balancer_module "/home/ers/apache2.2/modules/standard/mod_proxy_balancer.so"
The ERS configuration file is located in the
conf directory of your ERS httpd instance (
/home/ers/servers/lb-server/conf in our example.) Add the
LoadModule directive in the same section as the other directives.
Also be sure that the other two required modules,
mod_proxy_http, are enabled (in other words, are not commented out:)
LoadModule proxy_module "/home/ers/apache2.2/modules/standard/mod_proxy.so" LoadModule proxy_http_module "/home/ers/apache2.2/modules/standard/mod_proxy_http.so"
In the same
httpsd.conf file, add the proxy configuration. Use the
<Proxy> element to specify the list of tc Runtime instances and the method of load balancing you want to use. Then use the
ProxyPassReverse directives to specify the URLs that will use this proxy and load-balancing (both for requests and responses.) For example:
<Proxy balancer://my-balancer> BalancerMember http://192.168.0.203:8081 route=instanceOne loadfactor=1 BalancerMember http://192.168.0.203:8082 route=instanceTwo loadfactor=1 ProxySet lbmethod=byrequests </Proxy> ProxyPass /my-app balancer://my-balancer/my-app ProxyPassReverse /my-app http://192.168.0.203:8081/my-app ProxyPassReverse /my-app http://192.168.0.203:8082/my-app
balancer parameter of the
<Proxy> element specifies a unique identifier for this load balancer configuration. Each tc Runtime instance that will be serviced by this load balancer must have its own
BalancerMember; the first parameter of this directive specifies the full IP address (including port number) of the tc Runtime instance. The
route parameter contains session ID information; you will later use the value of this parameter in the tc Runtime configuration file to configuring sticky sessions; for now, just ensure that the values are unique for each
loadfactor parameter specifies how much of a load a particular member carries. If you want each member to carry the same load, set the numbers equal to each other (as in the example above.) If, however, you want one member to work three times harder than the other, set the loadfactors to 3 and 1.
lbmethod parameter of the
ProxySet directive to specify the load balancing algorithm. The possible values are as follows:
byrequestswhich performs weighted request counting. This is the default value.
bytrafficwhich performs weighted traffic byte count balancing
bybusynesswhich performs pending request balancing.
Finally, use the
ProxyPassReverse to specify the context URLs of the application that will be routed to the tc Runtime instances that you have configured in the load balancing scheme.
ProxyPass specifies that when the ERS httpd server receives a request at the
/my-app URL, it will route it to the load balancer which will in turn route it to the tc Runtime instance.
ProxyPassReverse does the reverse: when the tc Runtime instance sends a response to a user who is using
/my-app, the response appears to come from the ERS httpd server, and not the tc Runtime instance. Thus the details of the tc Runtime instance are hidden from the user.
See Apache Module mod_proxy on the Apache Software Foundation Web site for the full reference documentation on the directives described in this step, along with additional parameters you can use.
Optional. If you want to enable the balancer manager Web application to watch the load balancing activity and control the behavior, add the following to the
httpsd.conf configuration file of your ERS httpd instance:
<Location /balancer-manager> SetHandler balancer-manager Order Deny,Allow Deny from all # BE VERY RESTRICTIVE with YOUR ALLOW STATEMENT Allow from 127.0.0.1 </Location>
After restarting the ERS httpd instance, you can access the balancer manager application by navigating to the
http://localhost:port/balancer-manager URL in your browser, where
port is the port number of the ERS httpd instance (
8080 by default.) For security, the preceding balancer manager configuration allows access only to users who navigate to the application using a browser installed on the same computer on which the ERS httpd Server is actually running.
Optional. If you want to enable sticky sessions, follow these steps:
httpsd.conf file of the ERS httpd instance, update the
ProxySet directive of the
<Proxy> element you configured in a preceding step by adding the
stickysession=JSESSIONID|jsessionid parameter. This parameter configures the cookie/path that will be used for stickiness. For example (update shown in bold):
<Proxy balancer://my-balancer> BalancerMember http://192.168.0.203:8081 route=instanceOne loadfactor=1 BalancerMember http://192.168.0.203:8082 route=instanceTwo loadfactor=1 ProxySet lbmethod=byrequests stickysession=JSESSIONID|jsessionid </Proxy>
Go to the computer on which tc Server is running and update the
server.xml configuration file of both tc Runtime instances by adding the
jvmRoute=value attribute to the Catalina
<Engine> element. Set the value of this attribute equal to the value you specified (in a preceding step) for the
route parameter of the
BalancerMember directive in the ERS httpd
httpsd.conf file that describes the tc Runtime instance.
Following our example, the updated
<Engine> entry for the
instanceOne tc Runtime instance (that uses port
8081) would be as follows (new attribute in bold):
<Engine name="Catalina" defaultHost="localhost" jvmRoute="instanceOne">
If you configure sticky sessions, SpringSource recommends that you also configure session replication for the tc Runtime instances. For details, see Enabling Clustering for High Availability.
Start the ERS httpd instance. Following our example:
prompt$ cd /home/ers/servers/lb-server prompt$ bin/apache_startup.sh startssl
Start (or restart) the two tc Runtime instances for the configuration changes to take effect. Following our example:
prompt$ cd /home/tcserver/springsource-tc-server-standard prompt$ ./tcruntime-ctl.sh instanceOne restart prompt$ ./tcruntime-ctl.sh instanceTwo restart
You have now configured load balancing for the two tc Runtime instance using the front-end ERS httpd server. If, for example, the URL to access the ERS httpd server is
http://www.myhost.com, and a user invokes the following URL in their browser:
the ERS httpd server will route the request to one of the two tc Runtime instances, balancing the load between the two instances.