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.
If we add a server to a service integration bus, a messaging engine that uses the default service integration policy, a "One of N" policy, is created automatically. The behavior of the messaging engine is to run only on that server, because there is only one server available to it. It is possible to configure a non-default policy for the messaging engine, but it would not affect the behavior of the messaging engine.
If we add a server cluster to a bus, we can control which servers the messaging engine can run on, and the behavior of the messaging engine if a server is unavailable. We can also deploy additional messaging engines to the cluster. For example, we can configure the cluster to provide high availability, scalability or workload sharing (increasing performance by increasing the resources that provide the service), or a combination of these factors.
When we add a cluster to a bus, we can configure the messaging engine behavior using messaging engine policy assistance. There are predefined messaging engine policies that support frequently-used cluster configurations, and an option to set up a custom configuration while still using messaging engine policy assistance. The advantage of messaging engine policy assistance is that we are guided through the configuration and many of the settings are created automatically. See related topics.
The remainder of this topic describes the configuration of messaging engine behavior without using messaging engine policy assistance. Use these settings if we are already familiar with this procedure. Otherwise, use messaging engine policy assistance.
To configure the messaging engine behavior, we configure the core group policy for the HAGroup of the messaging engine. We can configure the policy to control whether the messaging engine has a preference for a particular server, or set of servers, and whether the messaging engine is restricted to the set of preferred servers. We can control whether a messaging engine can fail back to a more preferred server after failover. We can also modify the policy to change the monitoring interval for the messaging engine.
The following table shows the types of core group policy we can use for messaging engines, and how each type affects the behavior of a messaging engine that belongs to a cluster bus member.
Policy type Behavior Static - with one server in the static group servers list The messaging engine is restricted to a particular server. The messaging engine can run only on the server to which it is restricted, and cannot fail over to any other server in the cluster. For multiple messaging engines, this can be a useful configuration for workload sharing, where failover is not wanted. One of N - with no preferred servers The messaging engine runs on the first available server and can fail over to any of the other servers in the cluster. It has no preference for any particular server. The "Default SIBus Policy" provides this behavior.
One of N - with preferred servers The messaging engine runs on the first server in the preferred servers list that is available when the messaging engine starts. It can fail over to the first server in the preferred servers list available at the time of failover. The earlier a server is in the preferred servers list, the stronger the preference for that server. If no preferred servers are available, it can fail over to any other server in the cluster. After the messaging engine fails over, it does not move, even if a more preferred server becomes available again. One of N - with preferred servers and the Fail back setting The messaging engine always runs on the most preferred server that is available. It runs on the first server in the preferred servers list that is available when the messaging engine starts. It can fail over to the first server in the preferred servers list available at the time of failover. The earlier a server is in the preferred servers list, the stronger the preference for that server. If no preferred servers are available, it can fail over to any other server in the cluster. After the messaging engine fails over, if a more preferred server becomes available again, the messaging engine moves automatically to that server. One of N - with preferred servers and the Preferred servers only setting The messaging engine runs on only servers in the list of preferred servers. It runs on the first server in the preferred servers list that is available when the messaging engine starts. It can fail over to the first server in the preferred servers list available at the time of failover. The earlier a server is in the preferred servers list, the stronger the preference for that server. If no preferred servers are available, it cannot fail over to any other server in the cluster. If the Fail back setting is selected, after the messaging engine fails over, if a more preferred server becomes available again, the messaging engine moves automatically to that server. No operation The messaging engine is managed by an external high availability framework and can fail over to any of the other servers in the external high availability cluster. If a you require server affinity, configure this as a preference in the high availability cluster configuration. The configuration details depend on the choice of high availability framework. This policy is useful where a high availability clustered database is being used for the data store for the messaging engine; we can put the messaging engine under the control of the same high availability cluster that is managing the database. This policy is also useful where a messaging engine is connected to an IBM MQ queue manager; the messaging engine can fail over if it is using a high availability clustered IP address for its inbound channel chains. For more information, see External high availability frameworks and service integration.
The policy is assigned to the appropriate HAGroup at run time using the match criteria configured for the policy.
Default service integration policy
The most general policy for service integration is the default included with the product, the "Default SIBus Policy". This is a "One of N" policy with no preferred servers, that is, the messaging engine starts on the first available server in the cluster and can fail over to any other application server in the cluster. There is no automatic fail back and there is a monitoring interval of 120 seconds. The policy has a single match criterion that matches any service integration messaging engine, so the policy applies to any messaging engine, unless the messaging engine is in an HAGroup with a stronger match to a different policy.
Subtopics
Related:
Configuration for high availability Configuration for workload sharing or scalability Configuration for workload sharing with high availability Data store high availability Configure a core group policy for messaging engines Create a policy for messaging engines Add a cluster as a member of a bus Add a cluster to a bus without using messaging engine policy assistance