Loadbalancer-Service

NOTE: This service was removed from JBoss AS in JBoss 4.0.4. This document describes 4.0.3.SP1 and earlier.

The Loadbalancer-Service provides reverse-proxy support with silent failover.

The files sit in the directory JBOSS_HOME/docs/examples/varia/loadbalancer/.

Configuration of the Loadbalancer

Copy the directory loadbalancer.sar to your deploy directory. Edit loadbalancer.sar/META-INF/jboss-service.xml to match your configuration.

Connection-timeout

The connection-timeout controls after which time interval a host should be considered dead. This value is given in milliseconds.

Sticky-sessions and sticky session cookie name

This value (true or false is allowed) controls if a request should always go to the host the client is first scheduled on. This is needed if you use HTTP-sessions in your web-application. If you set this value to false every request is rescheduled with the algorithm given in the scheduler class. The session cookie name sets the name of the cookie the sticky session information is stored in. You also need sticky sessions if you use the JBoss HTTP session clustering feature.

Hosts list

The hosts given in this list are used as request targets.  The URLs can be of any type a normal web-browser will accept (http://www.xy.zz/, https://www.xy.zz/, http://www.xy.zz:8080/). The loadbalance factor is used by the WeightedLeastConnectionScheduler only.

Scheduler

RoundRobinScheduler

The RoundRobinScheduler is a simple scheduler that schedules requests in a round-robin fashion. It does not take any other information into account for scheduling.

MinAvgScheduler

The MinAvgScheduler takes the response times of the nodes into account. Any new request is scheduled on the node with the least response time.

WeightedLeastConnectionScheduler

The WeightedLeastConnectionScheduler schedules requests based on the current connections to the nodes. Any new request is scheduled on the node with the least connections. The scheduler does take a loadbalance factor into account. Higher loadbalance factors mean more connections to a node. This is useful if you have nodes with very different performance (for example a server farm with new and old nodes).

Monitor Services

There are two monitor services available that check the availability of the target nodes in given intervals. They can be enabled by uncommenting them in jboss-service.xml. This services work in both ways - they mark up nodes down and the other way round if certain conditions are met. Look into jboss-service.xml for examples. At the moment two monitor services exist.

SimpleMonitorService

This monitor checks that a given path on a target node is reachable (gives a HTTP response like OK or MOVED).

ECVMonitorService

The ECVMonitorService (ECV=Extended Content Verification) does the same like the SimpleMonitorService but does additional checks on the webserver response. It tries to match a given regular expression against the server response. This can something like

"JBOSS" or "HELLO WORLD".

Getting information at runtime

Web-Console

You can get runtime information about the loadbalancer in the JBoss WebConsole or JMXConsole. The part that is interesting for the HTTP-loadbalancer is under the jboss.web.loadbalancer-node.

Three type of nodes exist:

1. type=Node: here you get information about the nodes of your loadbalancer-cluster. The nodes can be marked down for maintance work.

2. service=Loadbalancer: here you can get information about how many concurrent requests are currently processed by your cluster.

3. service=Scheduler: here you can add or remove nodes. This service tells you which nodes are up or down.

log4j

If you enable the DEBUG-level for the org.jboss-category you get detailed debugging-info from the loadbalancer. But be aware that debugging slows down your application.

CAVEATS

• This is purely for loadbalancing... does NOT implement failover

• Keep in mind that this loadbalancer incurrs extra latency as it requires an extra roundtrip to the browser.  Therefore, corporate production systems will typically leverage hardware loadbalancing instead.