JRun Administrator's Guide
Clustering

Connector-based clustering

JRun lets you cluster JRun servers behind a web server connector. The web server connector performs load balancing and manages failover among the JRun servers in the cluster, as the following figure shows:

Connector-based clustering

The JRun web server connector supports load balancing and failover when connected to a JRun server that participates in a cluster.

In the web server configuration file (for example, httpd.conf for Apache or jrun.ini for IIS), there is an entry named serverstore. This entry points to a file named jrunserver.store. The jrunserver.store file contains information on the servers in a JRun server cluster.

When you run the Web Server Configuration tool, it automatically detects and displays JRun clusters. If you select a cluster, the Web Server Configuration tool chooses one of the cluster members as the bootstrap server and saves its IP address:web server connector port (also called JCP port) as the bootstrap property in the configuration file. The Web Server Configuration tool also sets the deactivated attribute of the jrun.xml ProxyService to false for all JRun servers in the cluster.

Note:   All JRun servers in the cluster must be running when you run the Web Server Configuration tool. If a server is not running, the Web Server Configuration tool cannot modify the deactivated attribute.

When the web server connector starts for the first time, it uses the bootstrap property to detect whether the JRun server is in a cluster and saves the IP address:JCP port of each JRun server in the cluster. For example, if the bootstrap property points to 1.64.22.137:51000 and that JRun server is in a cluster, the connector creates a jrunserver.store file with a proxyservers property containing IP address:JCP port settings similar to the following:

proxyservers=1.64.22.137:51000;1.64.22.143:51000;1.64.22.126:51000;
1.64.22.140:51000

This example assumes that all of the JRun servers are using the default JCP port.

jrun.xml modifications

In addition to running the Web Server Configuration tool, you must make the following modifications to the ProxyService in each clustered JRun server's jrun.xml file:

• JNDI binding  To enable the JRun server to communicate cluster changes to the web server connector, set the bindToJNDI attribute to true for the ProxyService.
• Load balancing algorithm  To control how the web server connector balances requests across the cluster, set the LoadBalancingAlgorithm attribute, as follows:
  • Round robin (default)  The web server connector sends each request to the next JRun server in the list. Specify ROUNDROBIN to use this option.
  • Weighted round robin  The web server connector sends relatively more requests (one after the other) to certain JRun servers, as specified in the serverweight attribute. Specify ROUNDROBIN_WEIGHTED to use this option.
  • Random weighted  The web server connector sends relatively more requests (in a random order) to JRun servers, as specified in the serverweight attribute. Specify RANDOM_WEIGHTED to use this option.
• Server weight  To control the relative weight of the JRun server, specify the ServerWeight attribute. Use this attribute for the weighted round robin and weighted random distribution load balancing algorithms. The default weight is 1 so JRun servers with server weights greater than 1 will receive relatively more requests. This option is useful if some JRun servers in a cluster have more resources than others.
• Session management  To control whether the web server connector detects whether a request has an existing session and automatically routes that request to the original JRun server. specify the StickySessions attribute. Specify true or false. The default is false. If your web applications use session management, you must set this attribute to true.

The following example jrun.xml snippet uses the default load-balancing algorithm and sticky sessions:

<service class="jrun.servlet.jrpp.JRunProxyService" name="ProxyService">

��<attribute name="bindToJNDI">true</attribute>
��<attribute name="port">51010</attribute>
��<attribute name="deactivated">false</attribute>
��<attribute name="StickySessions">true</attribute>
</service>

The following example jrun.xml snippet uses the weighted round-robin load-balancing algorithm and sticky sessions:

<service class="jrun.servlet.jrpp.JRunProxyService" name="ProxyService">

��<attribute name="bindToJNDI">true</attribute>
��<attribute name="port">51010</attribute>
��<attribute name="deactivated">false</attribute>
��<attribute name="LoadBalancingAlgorithm">ROUNDROBIN_WEIGHTED</attribute>
��<attribute name="ServerWeight">3</attribute>
��<attribute name="StickySessions">true</attribute>
</service>

Comments

Add Comment

bpurcell said on Mar 5, 2003 at 11:20 AM :

Under the session management section where it states "The default is false. If your web applications use session management, you must set this attribute to true." The default for connector clustering sticky session is TRUE. You only need to specify

<attribute name="StickySessions">false</attribute>

If you want to disable the sticky session option.

bpurcell said on Mar 5, 2003 at 11:21 AM :

Under the session management section where it states "The default is false. If your web applications use session management, you must set this attribute to true." The default for connector clustering sticky session is TRUE. You only need to specify

<attribute name="StickySessions">false</attribute>

If you want to disable the sticky session option.

sxm20 said on Jul 15, 2003 at 3:48 AM :

Not a whole lot of technical details here. Well, I would like to know if its possible to add and remove servers dynamically to the cluster.

ben pinnick said on Aug 11, 2003 at 3:22 AM :

Has anyone found problems with connector based clusting using Apache?

songbin said on Oct 22, 2003 at 11:33 PM :

Even I added
<attribute name="StickySessions">true</attribute>
in the "<service class="jrun.servlet.jrpp.JRunProxyService" name="ProxyService">" group, I still cannot see the Sticky Session.
The same request still be sent to the 2 servers alterlatively.

Fuseboxer said on Apr 12, 2004 at 1:53 PM :

In the jrunserver.store file, the line for proxyservers MUST use ip addresses and NOT hostnames.

rio yoshida said on Sep 15, 2004 at 8:02 PM :

You must set different server.id at {server.root}/SERVER-INF/connector.properties on each servers. Otherwise StikySession will be Round Robin.
Actually, server.id will be the first four chars of jsessionid.
And is anyone know how to prevent using special chars(like "$") in the rest part of jsessionid?

sdupre said on Oct 29, 2004 at 6:00 AM :

We have a fix for this. $ isn't supported in WML.

Call support for this hotfix.

Stephen Dupre
Macromedia QA

mangesh@iflex said on Nov 1, 2004 at 3:19 PM :

Once the setup is complete for the cluster and Apache connector, if we restart apache server and not all jrun servers are running at the instance when Apache comes up. Apache does not recognize the servers in cluster which may start up later on.
Do we have a fix for this?

No screen name said on Dec 7, 2004 at 7:36 AM :

When running serveral jrun severs on different ports on the same machine loadbalancing seems to spread the load unevenly over the available servers. apparently the loadbalancer (in combination with apache) does not properly apply Round Robin but gives about 35 % of the requests to the first server, 40 % to the second and about 12,5 % to the third and fourth server. Has anyone else noticed similair results?

rio yoshida said on Apr 19, 2005 at 1:06 AM :

It seems that apache connector deletes the contents of jrunserver.store.
Like below:
proxyservers=
No IP or Ports.
It still continues under Updater5.

jrunrandy said on Apr 22, 2005 at 6:50 AM :

I am pretty sure that the connectors have stopped using jrunserver.store, so this shouldn't be a problem. However, I'm not sure which updater introduced this change.

steveh1234 said on Aug 15, 2005 at 7:15 PM :

The connector seems to be confused by the existence of another cookie on our same domain named dcr-hrw-16000-1-PSJSESSIONID. Looking at the connector logs, once a client gets that cookie, the connector starts to try to use that value as the session ID and can never again stick to the correct server until the browser is closed and the cookies are deleted. The other cookie is set by a PeopleSoft application that many of our employees visit throughout the day. Why would the JRun connector take that cookie over its own JSESSIONID cookie that is still there? Please help!

RSS feed | Send me an e-mail when comments are added to this page | Comment Report

Current page: http://livedocs.adobe.com/jrun/4/JRun_Administrators_Guide/clustering3.htm

Add Comment