If I install the same Web application into more than one WebSphere Application Server cluster, is it possible to configure the Web server plug-in to properly route requests to the application in both clusters?
Cause
The most common use of the WebSphere Application Server Web server plug-in is to load balance requests for an application installed to a single cluster. For that environment you should not use the instructions in this technote.
In some rare cases, you might want to install the exact same application into multiple clusters. The purpose of this technote is to describe how to configure the WebSphere Application Server Web server Plug-in to work properly in that specific case.
Answer
Note: The Web server plug-in does not support load balancing or fail-over between multiple clusters. Also the configuration described below requires manually changing the plugin-cfg.xml file, so you should turn off automatic propagation in the WebSphere Administrative Console so that the plugin-cfg.xml file does not get automatically overwritten.
Yes, it is possible for a single Web server plug-in to properly route requests when the same application is installed into more than one WebSphere Application Server cluster. To make this work you will need to use different hostnames or port numbers for each of the clusters. You will also need to do some manual cut and paste of information in the plugin-cfg.xml file.
The example below shows exactly how to accomplish this.
* The IBM HTTP Server machine is called ihsbox.
* cluster1 has two members c1_member1 and c1_member2.
* cluster2 has two members c2_member1 and c2_member2.
* Both of the member1 appservers are on a machine called was1.
* Both of the member2 appservers are on a machine called was2.
So, for this simple example, it would look like the following:
------ was1 --- cl1_member1
/ \--- cl2_member1
/
ihsbox
\
\------ was2 --- cl1_member2
\--- cl2_member2
If I install my snoop application (context-root /snoop) into both clusters, how is the plug-in supposed to distinguish which ServerCluster to use?
In the plug-in, there are only 3 things that can distinguish between requests:
* hostname
* port number
* URI
For example, these URLs are unique requests that can be routed independently of each other:
http://host1/snoop
http://host1:83/snoop
http://host2/snoop
http://host2:81/snoop
In each of these examples, the URI part /snoop remains the same. It is the hostname or port number that makes the difference.
Back to the example, in Application Server admin, you would create a virtual host called "vhost1" which would have a host alias of host1:80. You would also need to include other host aliases for the internal ports used by appservers in cluster1 (for example: ports 9080, 9081, 9443, 9444). You would use this virtual host (vhost1) in all of the members of cluster1 (cl1_member1 and cl1_member2).
In addition, you would create a virtual host called "vhost2" which would have a host alias of host2:80. You would need to include other host aliases for the internal ports used by appservers in cluster2. I would use this virtual host (vhost2) in all of the members of cluster2 (cl2_member1 and cl2_member2).
In order to maintain session affinity it is essential to use different affinity cookie names for each different cluster. For example, the appservers in cluster1 can use the cookie name "JSESSIONIDC1". And the appservers in cluster2 can use the cookie name "JSESSIONIDC2". By using different cookie names for the different clusters, session affinity will be preserved within each cluster. For information about how to change the cookie names, see Cookie settings in the Information Center.
You must map the application modules to the newly created virtual hosts. Since the same application is installed to both clusters, you will need to map the application modules to both vhosts. However, there currently is a limitation in the Application Server administrative console in that it only allows the application modules to be mapped to a single vhost. Consequently, you must use a trick to map the modules twice and manually copy and paste the configs into a single plugin-cfg.xml file.
Here are the steps to use:
1. Map the application modules to the first vhost (for example: vhost1).
2. Generate the plug-in.
3. From the plugin-cfg.xml file, manually copy the VirtualHostGroup and UriGroup and Route that correspond to vhost1.
4. Map the application modules to the second vhost (for example: vhost2).
5. Generate the plug-in.
6. In the new plugin-cfg.xml file you will see that the VirtualHostGroup and UriGroup for vhost1 are gone, and there are new VirtualHostGroup and UriGroup for vhost2.
7. Manually paste the VirtualHostGroup and UriGroup and Route for vhost1 back into the plugin-cfg.xml file.
8. Save the plugin-cfg.xml file and propagate it to the Web server.
The plugin-cfg.xml file should now have a VirtualHostGroup and UriGroup for vhost1 with a Route that points to cluster1. Also there should be a VirtualHostGroup and UriGroup for vhost2 with a Route that points to cluster2.
You need to account for these new hostnames in my IBM HTTP Server config (httpd.conf). The ServerName for IBM HTTP Server is ihsbox. Create a VirtualHost in IBM HTTP Server to account for the other valid hostnames, like this:
ServerName ihsbox
ServerAlias host1
ServerAlias host2
Add host1 and host2 into my DNS config so that they resolve to the ip address of ihsbox.
Now, this URL http://host1/snoop will go to the snoop application in cluster1.
And, this URL http://host2/snoop will go to the snoop application in cluster2.
If you want to use different port numbers instead of different hostnames, the same idea applies there as well.
IBM URL
No comments:
Post a Comment