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. You 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. For more information, see the 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 you 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, you configure a policy to control the availability behavior of the messaging engine on that bus member.
- If we want 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.
- If we want 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.
- If we want 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.
first column of the table lists the different configurations available. The second column lists the types of bus members used in configuring the messaging engines. The third column displays the number of messaging engines used in the configuration. The fourth column lists the policy
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
We can add a server to a service integration bus, to create a server bus member. We can also add a cluster to a service integration bus, to create a cluster bus member. A cluster bus member can provide scalability and workload sharing, or high availability, but a server bus member cannot.
- Simple configuration without workload sharing or high availability
A simple configuration consists of a single messaging engine running on only one server. This configuration does not provide workload sharing or high availability.
- 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 high availability configuration ensures that there is always a messaging engine running in the cluster, so that messages are always transmitted.
- Configuration for workload sharing or scalability
This configuration consists of multiple messaging engines running in a cluster, with each messaging engine restricted to running on one particular server. A workload sharing configuration achieves greater throughput of messages by spreading the messaging load across multiple servers.
- Configuration for workload sharing with high availability
This configuration consists of multiple messaging engines running in a cluster, where each messaging engine can fail over to one or more alternative servers.
- Policies for service integration
Each messaging engine on a service integration bus belongs to one high availability group (HAGroup). The members of each HAGroup are controlled by a policy assigned to the group at run time. This core group policy determines the availability characteristics of the messaging engine in the HAGroup.
Related concepts
WebSphere Application Server high availability Match criteria for service integration Multiple-server bus with clustering
Related tasks
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
Related information:
Messaging engine policy assistance Messaging engine troubleshooting tips