Network Deployment (Distributed operating systems), v8.0 > Applications > Service integration > High availability and workload sharing
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, you can have a single highly available messaging engine. Alternatively, with a cluster bus member, you 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 you 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 you create. If you create a server bus member, you can create only a simple configuration. If you create a cluster bus member, you 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 you 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. 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 you 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 you want high availability, you 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, you 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 you want workload sharing but not high availability, you 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 you 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 you can achieve different configurations without using messaging engine policy assistance.
Service integration configurations. The 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 types.
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"
Multiple-server bus with clustering WAS high availability Match criteria for service integration Messaging engine policy assistance 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 policy assistance Messaging engine troubleshooting tips