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.
Add a server to a bus
When we add a server to a service integration bus, a messaging engine is created automatically. This single messaging engine cannot participate in workload sharing with other messaging engines; it can only do that in a cluster. The messaging engine also cannot be highly available, because there are no other servers in which it can run.
Add a cluster to a bus
A cluster deployment can provide scalability and workload sharing, or high availability, or a combination of these aspects. This depends on the number of messaging engines in the cluster and the behavior of those messaging engines, such as whether the messaging engines can fail over to another server, or fail back when a server becomes available again.
We can use messaging engine policy assistance to create and configure messaging engines in a cluster. The following predefined messaging engine policy types are available, which support frequently-used cluster configurations:
- High availability. One messaging engine is created in the cluster. It can fail over to any other server in the cluster, so it is highly available.
- Scalability. One messaging engine is created for each application server in the cluster. The messaging engines cannot fail over.
- Scalability with high availability. One messaging engine is created for each application server in the cluster. Each messaging engine can fail over to one specific server in the cluster, creating a circular pattern of availability.
We can also use messaging engine policy assistance to create a custom messaging engine policy. Create any number of messaging engines for the cluster, and configure the messaging engines as you require. The associated core group policies and settings for the messaging engines are created automatically.
If we do not use messaging engine policy assistance, when we add a server cluster to a service integration bus, a single messaging engine is created automatically. This messaging engine uses the default SIBus core group policy that already exists in WebSphere Application Server. The policy allows the messaging engine to fail over to any server in the cluster. We can then add further messaging engines if required. The cluster deployment depends on the number of messaging engines in the cluster and the policy bound to the high availability group (HAGroup) of each messaging engine.
If there is only one messaging engine in the cluster and we deploy a destination to that cluster, the destination is localized by that messaging engine. All messaging workload for that destination is handled by that messaging engine; the messaging workload cannot be shared. The availability characteristics of the destination are the same as the availability characteristics of the messaging engine.
We can benefit from increased scalability by introducing additional messaging engines to the cluster. When we deploy a destination to the cluster, it is localized by all the messaging engines in the cluster and the destination becomes partitioned across the messaging engines. The messaging engines can share all traffic passing through the destination, reducing the impact of one messaging engine failing. The availability characteristics of each destination partition are the same as the availability characteristics of the messaging engine the partition is localized by.
If we do not use messaging engine policy assistance, you control the availability behavior of each messaging engine by modifying the core group policy that the HAManager applies to the HAGroup of the messaging engine.
The simplest way to create and configure messaging engines in a cluster is to add a cluster to a bus and use messaging engine policy assistance with one of the predefined messaging engine policy types. If we are familiar with creating messaging engines and configuring messaging engine behavior, we can use messaging engine policy assistance and the custom messaging engine policy type. To add a cluster to a bus without using messaging engine policy assistance, we should be familiar with all the creation and configuration steps involved, for example, creating a messaging engine, configuring core group policies and using match criteria.
Related:
How a message-driven bean connects in a cluster Bus configurations Messaging engine policy assistance Workload sharing with queue destinations Add a server as a new bus member Configure high availability and workload sharing of service integration Add a cluster as a member of a bus Add a messaging engine to a cluster