Service integration high availability and workload sharing configurations
The configuration of messaging engines in service integration is very flexible. We can have a single messaging engine that does not provide high availability or workload sharing. With a cluster bus member, we can have a single highly available messaging engine. Alternatively, with a cluster bus member, we can have multiple messaging engines that share workload, or that share workload and also provide high availability.
- A simple configuration has one messaging engine that runs on a single server. This configuration is suitable for many purposes. However, one messaging engine is a single point of failure and the configuration does not provide high availability or workload sharing.
- A configuration for high availability has a single messaging engine that runs on a server in a cluster, where that messaging engine can fail over to one or more alternative servers in the cluster. By using failover, you avoid a single point of failure and ensure that there is always a messaging engine running in the cluster.
- A configuration for workload sharing or scalability has multiple messaging engines running in a cluster, where each messaging engine runs on one specific server in the cluster. The messaging load is spread across multiple servers, and we can add new servers to the cluster without affecting the existing messaging engines.
- A configuration for workload sharing with high availability has multiple messaging engines running in a cluster, where each messaging engine runs on a specific server in the cluster and can also can fail over to one or more alternative servers in the cluster.
The configurations that are possible depend on the type of bus member we create. If we create a server bus member, we can create only a simple configuration. If we create a cluster bus member, we can create any of the configurations in the previous list, depending on the number of messaging engines in the cluster and the behavior of those messaging engines. For more details, see the topic about bus member types and their effect on high availability and workload sharing.
For details and examples of the configurations we can create, see the subtopics.
Configure messaging engine behavior
To configure messaging engine behavior, add a cluster to a bus and use a predefined messaging engine policy. The predefined messaging engine policies support frequently-used cluster configurations, such as workload sharing and scalability, high availability, or a combination. We use messaging engine policy assistance, which creates one or more messaging engines and configures them to provide the required behavior. We can also use messaging engine policy assistance to set up a custom configuration. Messaging engine policy assistance guides you through the configuration and many of the settings are created automatically. See topic about messaging engine policy assistance.
It is possible to add a cluster to a bus and configure the messaging engine behavior without using messaging engine policy assistance. Use this procedure if we are already familiar with it. Otherwise, use messaging engine policy assistance.
If we add a cluster to a bus without using messaging engine policy assistance, we configure a policy to control the availability behavior of the messaging engine on that bus member.
- For high availability, we can use a cluster bus member with one messaging engine and the default service integration policy, "Default SIBus Policy", which allows the messaging engine to fail over to any other application server in the cluster. Alternatively, we can create a new policy and configure it to specify other availability behavior, such as a preference for particular servers or the ability to fail back.
- For workload sharing but not high availability, we can use a cluster bus member with multiple messaging engines and create a Static policy for each messaging engine. This might be useful for scalable express messaging, in which there is no persistent state associated with any one messaging engine, so no failover is required.
- To have an external high availability framework to manage the messaging engines, create a "No operation" policy for them.
For more information about policies and configuration, see the topic about policies for service integration.
The following table shows how we can achieve different configurations without using messaging engine policy assistance.
Configuration Type of bus member Number of messaging engines Policy type Simple Server 1 Default ("One of N") Simple Cluster 1 Static High availability Cluster 1 "One of N" or "No operation" Workload sharing without high availability Cluster more than 1 (typically, one messaging engine for each server) Static High availability and workload sharing Cluster more than 1 (typically, one messaging engine for each server) "One of N" or "No operation"
Subtopics
- Bus member types and their effect on high availability and workload sharing
- Simple configuration without workload sharing or high availability
- Configuration for high availability
- Configuration for workload sharing or scalability
- Configuration for workload sharing with high availability
- Policies for service integration
Related:
WAS high availability Messaging engine policy assistance Match criteria for service integration Multiple-server bus with clustering Configure high availability and workload sharing of service integration Add a cluster as a member of a bus Create a policy for messaging engines Configure shared durable subscriptions for a connection factory Configure messaging engine failover for mixed version clusters Messaging engine troubleshooting tips