6. Configuring Load Balancing Using the ERS httpd Server

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.

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:

  1. 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
  2. Update the httpsd.conf configuration file of the ERS httpd instance by adding the following LoadModule directive which loads the ERS httpd proxy_balancer_module module:

    LoadModule proxy_balancer_module "ERS-INSTALL/apache2.2/modules/standard/mod_proxy_balancer.so"

    where 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 and 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"
  3. 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 ProxyPass and 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

    The 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 BalancerMember.

    The 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.

    Use the lbmethod parameter of the ProxySet directive to specify the load balancing algorithm. The possible values are as follows:

    • byrequests which performs weighted request counting. This is the default value.
    • bytraffic which performs weighted traffic byte count balancing
    • bybusyness which performs pending request balancing.

    Finally, use the ProxyPass and 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.

  4. 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.

  5. Optional. If you want to enable sticky sessions, follow these steps:

    1. In the 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>
    2. 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.

  6. Start the ERS httpd instance. Following our example:

    prompt$ cd /home/ers/servers/lb-server
    prompt$ bin/apache_startup.sh startssl
  7. 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:

http://www.myhost.com/my-app

the ERS httpd server will route the request to one of the two tc Runtime instances, balancing the load between the two instances.