Network Deployment (Distributed operating systems), v8.0 > Applications > Service integration > High availability and workload sharing > Service integration high availability and workload sharing configurations
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 you 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 you add a server cluster to a bus, you 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, you 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 you add a cluster to a bus, you can configure the messaging engine behavior by 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 you are guided through the configuration and many of the settings are created automatically. See the related topics.
The remainder of this topic describes the configuration of messaging engine behavior without using messaging engine policy assistance. Use these settings if you are already familiar with this procedure. Otherwise, use messaging engine policy assistance.
To configure the messaging engine behavior, you 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 you can use for messaging engines, and how each type affects the behavior of a messaging engine that belongs to a cluster bus member.
Effects of core group policies. The first column lists the types of the core group policies used for messaging engines. The second column explains how the policy type affects the messaging engine.
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.
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 that is 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. 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 that is 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. 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 that is 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; you 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 a WebSphere MQ queue manager; the messaging engine can fail over if it is using a high availability clustered IP address for its inbound channel chains. See External high availability frameworks and service integration.
The policy is assigned to the appropriate HAGroup at run time by using the match criteria that are 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.
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