High availability messaging engine policy
The high availability messaging engine policy is a predefined messaging engine policy type provided when we use messaging engine policy assistance. Use to configure a messaging engine in a cluster that is a member of a bus when we want the messaging engine to be highly available.
A high availability configuration ensures there is always a messaging engine running in the cluster. When a server hosting a messaging engine fails, the messaging engine is activated and run on another server. All messages that are set for high reliability, that were being processed or queued, will continue to be processed when the messaging engine starts on the next server. Use the high availability messaging engine policy for a system where it is a priority to process messages that are set for high reliability with minimum interruption.
The high availability messaging engine policy creates a single messaging engine for the cluster. The messaging engine is configured to fail over to any of the application servers in the cluster. All the application servers in the cluster are added to the preferred servers list, and this list determines the order in which the servers are used for failover. The earlier the server in the preferred servers list, the stronger the preference for that server. The messaging engine does not fail back, that is, if a more preferred server becomes available again, the messaging engine does not move back to that server.
The messaging engine is configured to use a single, highly available, message store (either a database or a file system) that all the servers in the cluster can access.
When we select the high availability messaging engine policy type on the administrative console, a diagram shows the selected cluster and the eventual outcome of the policy.
If there are no warning triangles in the diagram, and the "Is further configuration required" column shows No in the High availability row, the topology of the cluster and the configuration of the messaging engine is suitable, and we can continue.
If there are warning triangles in the diagram, examine the messages in the High availability row for guidance on how to achieve a suitable messaging engine configuration.
If we require high availability in a cluster, that cluster should contain at least two nodes, each with a server on it (that is, there should be at least two separate physical machines in the cluster). If the messages advise you to add another server on another node, we must redefine the topology of the cluster before we add the cluster as a member of a bus.
For example, the following figure shows three servers configured on one node. If that node fails, there will be no servers available for the messaging engine to fail over to. There must be at least one other server on a separate node to ensure that there is always a server on which a messaging engine can run.
Figure 1. High availability policy selected without a suitable cluster topology
The following figure is an example of a diagram displayed when the cluster topology and messaging engine configuration is suitable for the high availability policy. There are three nodes and each node contains a server. If a messaging engine is running on a server in a node and that node fails, the messaging engine can run on one of the other servers in the other two nodes. There are no warning triangles and no suggested components with dotted lines around them because the policy can be used successfully.
Figure 2. High availability policy selected with a suitable cluster configuration
The following table shows the messaging engine policy settings for a cluster of three servers that use the high availability messaging engine policy:
| Messaging engine name | Failover | Failback | Preferred servers list | Only run on preferred servers |
|---|---|---|---|---|
| clustername.000-busname | true | false |
| true |
For more information about messaging engine configuration for high availability, see the related information.
Related: