7.4.3 Cluster run state changes
In addition to the normal EJB request, let us take a look at how the WLM plug-in is informed of changes to the cluster configuration and dynamically propagates the change to WLM-aware clients:
- Changes are made to the cluster configuration, such as adding and starting a fourth cluster member to the sample configuration.
- The Deployment Manager pushes the changes to the Node Agents which in turn push those changes to all cluster members.
- Meanwhile, the EJB client is still performing requests on the cluster.
- With each request for a remote component, information about the cluster is returned in the response from the cluster member.
If the cluster has been modified since the last request from this client, the WLM plug-in updates its cluster data using the new information returned in the response.
- The EJB client makes another method call to the remote interface.
- The request handling ORB asks the WLM plug-in for the IOR of the server to contact.
- The WLM plug-in returns the IOR of the next target, based on the workload management policy, process affinity, and transaction affinity (Server weighted round robin), then the request can be processed by the ORB.
A change in the selection policy does not cause the cluster information to be sent to a client in response to a request. The WLM plug-in will continue using the selection policy defined at the first request. If the cluster topology or the number of active cluster members changes, the WLM plug-in will get the new selection policy as part of the new cluster configuration in the response.
Each Node Agent monitors the availability of the appservers running on its node. The Node Agent knows if an appserver is still running by pinging it intermittently. If an appserver fails then the Node Agent no longer receives responses on its ping messages and the Node Agent notifies the Deployment Manager of the run state change. This information is then pushed out as was described in step 2.
If a complete failure of a node occurs, then the Deployment Manager itself will not receive responses from its ping to the Node Agent and the clusters' configuration will be updated.
One significant improvement in WAS V6 is that the Deployment Manager is no longer a single point of failure (SPOF) for WLM routing as in WebSphere V5. With the new High Availability Manager (HAMgr), a failure of the Deployment Manager triggers the HA Coordinator, which carries the WLM routing information, to fail over to any other server in the same HA core group, based on the defined HA policy. Thus, the WLM routing is a guaranteed service that is always available to the client even when a Deployment Manager failure occurs. This new HA management is discussed in Chapter 9, WebSphere HAManager.