Workload Management |
Configuring and Running the BeenThere Sample |
This section describes the steps for configuring the environment, as depicted in Figure 1, and installing and running the BeenThere Sample. It is assumed that the following software is already installed:
Machine Name | Software Installed |
web |
IBM HTTP Server IBM HTTP Server plug-in |
app1 | IBM WebSphere Application Server |
app2 | IBM WebSphere Application Server |
dm | IBM WebSphere Application Server deployment manager |
Note:The following instructions assume that the Web server and its administration service are running, and that a Web server definition has been created on the deployment manager to automatically propagate the plugin-cfg.xml file.
Complete the following steps to add the application server nodes into the cell:
addNode <deploymgr host>
addNode.sh <deploymgr host>
install_root/bin/addNode <deploymgr host> <deploymgr port> -profileName <profileName> -startingport <portblock>
The application servers are now incorporated into the cell.
The MyWebCluster cluster provides workload balancing and failover for servlets.
Complete the following steps to create the MyWebCluster cluster:
The MyWebCluster cluster is now created.
The MyEJBCluster cluster provides workload balancing and failover for enterprise beans.
Complete the following steps to create the MyEJBCluster cluster:
Note:On a distributed platform, selecting the Prefer local option indicates that the request routes to the enterprise bean running on the local node, if available. The Prefer local option is disabled in the Sample configuration to demonstrate the workload management of EJB requests.
The MyEJBCluster cluster is now created.
During the creation of the MyWebCluster cluster, the Generate Unique Http Ports option is selected for each new cluster member. Selecting this option avoids HTTP port conflicts by creating a unique port value for each of the new application servers that is created.
Complete the following steps to ensure that each HTTP port value that is dynamically created has an associated host alias entry configured for the default_host virtual host:
The virtual host is now updated.
The WebSphere configuration service is not enabled for application servers by default. The Sample requires this service to programmatically read WebSphere Application Server configuration files to obtain environment information.
Complete the following steps to enable the WebSphere configuration service:
The WebSphere configuration service is now enabled.
Complete the following steps to install the BeenThere.ear file:
If you do not want to use BeenThere with security, you can skip this section. To use BeenThere with security, click here for instructions on configuring security.
Complete the following steps to start the servers:
The servers are now started.
To run the Sample, open the BeenThere web address, http://<host_name>/wlm/BeenThere in a browser, where <host_name> is the host name or IP address where IBM HTTP Server is running.
Note that in WebSphere Version 6 and later, there exists new function which is designed to maximize the throughput of the entire environment. What this ultimately means is that when testing the BeenThere Sample on these versions, The Workload Management component may not route the requests strictly to the exact value of the weights. The weights may be modified at runtime so the verification methods below can be incorrect. In these scenarios, the best method to verify WLM function is to ensure that requests are being routed to all the cluster members, irregardless of whether that routing is being done strictly by the weights. There are also methods to disable these feedback mechanisms, contact IBM support for more details if this is necessary.
Complete the following steps to verify that Web container workload management is working correctly as configured:
Open the BeenThere web address, http://<host_name>/wlm/BeenThere in a browser, where <host_name> is the host name or IP address where the IBM HTTP Server is running.
The values in the servlet run summary change, as demonstrated in the following example:
The servlet node should is now app2 instead of app1. The results show that IBM HTTP Server dispatched the HTTP request to the other member of the MyWebCluster cluster, namely WebServer2 on app2. Repeated runs of the servlet reveal a workload management behavior of the HTTP requests based on the configured weight values for the cluster members of MyWebCluster cluster.
The Web container workload management configuration is now verified.
Complete the following steps to verify that EJB container workload management is working correctly as configured:
On a distributed platform, the values in the bean run summary should be similar to the following example:
From this example, you can see the workload management run behavior of the enterprise bean based on the configured weight values for the cluster members of the MyEJBCluster cluster. Three invocations of the enterprise bean run on app2 for every single invocation run on app1.
On the z/OS platform, weight values are used to balance HTTP requests, but are not used to balance Internet Inter-ORB Protocol (IIOP) requests.
The EJB container workload management configuration is now verified.
Complete the following steps to verify that the member weights of the bean cluster are set correctly, as configured.
Compare the results to the following example:
The results show the weight values for all the members of the MyEJBCluster cluster. EJBServer1 has a weight of 1 and EJBServer2 has a weight of 3.
The bean cluster member weights are now verified.
Congratulations, you have now seen workload management in action and verified that the BeenThere Sample is working correctly as configured!