Configuration for high availability

This configuration consists of a single messaging engine, running in a cluster, that can fail over to one or more alternative servers. A highly available configuration ensures that there is always a messaging engine running in the cluster, so that messages are always transmitted.

The messaging engine is active in only one server in the cluster. If an application server or messaging engine fails, the messaging engine becomes active on another server in the cluster, if a server is available.

To create this configuration, you add a cluster to a service integration bus. One messaging engine is created automatically and the default service integration policy, "Default SIBus Policy", provides suitable behavior for high availability. The default service integration policy is a "One of N" policy where the messaging engine starts on the first available server in the cluster and can fail over to any other server in the cluster.

You might need to change the configuration, for example, you want to use a primary server and a backup server, or you want the messaging engine to run on only a subset of the servers in a cluster.

To change the configuration, create a new "One of N" policy and configure the policy for the messaging engine further. For example: It is not advisable to change the default service integration policy, "Default SIBus Policy", because those changes will affect all messaging engines that the policy manages.

After you create the new policy, use the match criteria to associate the policy with the required messaging engine.

There is no workload sharing in this highly available configuration, because there is only one messaging engine to handle the traffic through the destination.

The following diagram shows a highly available messaging engine configuration in which a single messaging engine, ME, with data store DS, runs in a cluster of three servers. When Server-1 fails, the messaging engine fails over and continues to run on Server-2.

Figure 1. Highly available messaging engine configuration before loss of Server-1The messaging engine is running in Server-1.
Figure 2. Highly available messaging engine configuration after loss of Server-1Server-1 has failed and the messaging engine has been moved to Server-2.

In the example configuration, each server in the cluster contains the definition of the messaging engine, and creates an instance of the messaging engine so that the instance is ready to be activated if another server fails.

The data store for the messaging engine must be accessible by all the servers in the cluster that might run the messaging engine. How to do this depends on the data store topology that you use. If you use a networked database server, ensure that it is accessible from all servers in the cluster that might run the messaging engine. Alternatively, you could use an external high availability framework to manage the database using a shared disk.

You can specify one or more preferred servers for the messaging engine, as mentioned earlier. Whenever a preferred server is available, the high availability manager (HAManager) will run the messaging engine in it. When no preferred server is available, the messaging engine will run in an alternative server, as long as the Preferred servers only option is not set on the policy. When a preferred server once again becomes available, the HAManager will move the messaging engine back to it if, and only if, the Fail back option is set on the policy.




Related concepts
Policies for service integration
Match criteria for service integration
Service integration high availability and workload sharing configurations
Related tasks
Configuring high availability and workload sharing of service integration
Adding a cluster as a member of a bus
Configuring a policy for messaging engines
Concept topic    

Terms of Use | Feedback

Last updated: Aug 29, 2010 8:25:23 PM CDT
http://www14.software.ibm.com/webapp/wsbroker/redirect?version=vela&product=was-nd-zos&topic=cjt0010_
File name: cjt0010_.html