WebSphere Application Server cluster setup
In order to build a WebSphere® cluster, it was necessary to install WebSphere Application Server Network Deployment V6.02.
This software package was installed on four guests, the number of nodes that would be included in the final cluster. One guest was configured as both an application server and the Deployment Manager. The Deployment Manager profile was defined first and then the four application server profiles were defined, one on each guest. The application server profiles were federated into the defined cluster during their definition. Next, the Trade application was installed using the Trade supplied JACL scripts with the cluster option using the wsadmin.sh script associated with the deployment manager. The Trade JACL script handles the final configuration of the federated nodes into a cluster.
The WebSphere Load Balancer must be configured so that it recognizes the WebSphere Application Server cluster. In the test environment, this is the IP address 192.168.30.82.
After the cluster was created, a new WebSphere plugin.xml file was created from the Deployment Manager's administration console. The plugin.xml file was then copied to the Web server guest and the httpd.conf file was changed to point to the new cluster plugin.xml file.
In order to run with the Trade caching options in a WebSphere cluster, it is necessary to create a replication domain that will handle the management of the cached objects between the members of the cluster. This was done from the Deployment Manager's Administration console, Environment > Replication Domains > New.
The number of replicas was set to the entire domain and the policy was set to push-pull.
Table 1 details the additional guests and components used for these tests. For a two-node cluster, one additional z/VM® guest was added to the environment and for a four-node cluster, two additional z/VM guests were added.
| z/VM guests | Memory size | CPUs |
|---|---|---|
| Firewall2 | 512 MB | 1 |
| Proxy server | 2 GB | 1 |
| Firewall1 | 512 MB | 1 |
| WebSphere Load Balancer | 1536 MB | 1 |
| Web server | 1 GB | 2 |
| WebSphere Application Server (1 - LNX00080) | 2 GB | 2 (4) |
| WebSphere Application Server (2 - LNX00086) | 2 GB | 2 (4) |
| WebSphere Application Server (3 - LNX00087) | 2 GB | 2 |
| WebSphere Application Server (4 - LNX00088) | 2 GB | 2 |
| DB2® UDB | 2 GB | 1 (2) |
For our two-node cluster environment, we used WebSphere Application Server guests 1 (LNX00080) and 2 (LNX00086). For all our cluster tests, all virtual CPUs were provided by one z/VM in one LPAR with eight physical CPUs. This setup created a significant virtual CPU overcommitment with our one-node system using nine virtual CPUs and our four-node system using 16 CPUs (see Table 1 for more details).