Configure a "One of N" policy for service integration

After creating a new "One of N" core group policy for a messaging engine, we configure the policy to specify the messaging engine behavior, such as which server the messaging engine runs on, and whether the messaging engine can fail over or fail back. We can also configure the frequency of messaging engine monitoring.

A core group policy with the policy type of "One of N" must exist and we must have first completed the steps in Configure a core group policy for messaging engines.

Use a "One of N" policy to run a messaging engine in a cluster to enable failover. One server in the cluster server runs the messaging engine and other servers in the cluster act as standby servers, ready to run the messaging engine if it cannot run in its current server.

Use a "One of N" policy to run a messaging engine in a server bus member, but this is equivalent to a cluster with only one server, that is, the value of N is 1, so the messaging engine cannot fail over.

We can configure a "One of N" policy for a messaging engine in a cluster to provide high availability, or workload sharing with high availability, depending on how we set the configuration options. See Policies for service integration.

Tasks

1. Open the Policies page for the policy we are configuring...
   Servers -> Core groups -> Core group settings -> core_group_name -> [Additional Properties] Policies > policy_name

2. Optional: If required, define which servers the messaging engine prefers to run on in a preferred servers list:

   1. Under Additional Properties, click Preferred servers.

   2. Select the servers you require from the Core group servers list, then click Add to add them to the Preferred servers list. Ensure that the servers we select are in the server cluster where the messaging engine runs.

   3. Use Move up and Move down to adjust the order of the list as required. The earlier a server is in the preferred servers list, the stronger the preference for that server.

   4. Click OK.

   The messaging engine runs in the first available server in the preferred servers list and fails over to the next available server in the preferred servers list. If no preferred server is available, the messaging engine can fail over to any other server in the cluster.

   We might use the preferred servers list if one server has more resources available to it or typically performs less work than the others. We might use the preferred servers list to help spread workload across the cluster by configuring multiple policies and specifying a different preferred server for each messaging engine. If we do not define a preferred server list, the messaging engine runs on the first available server in the cluster.

3. Optional: If we defined a preferred servers list, if required, restrict the messaging engine to run only on preferred servers, by selecting the Preferred servers only check box. The messaging engine runs in the first available server in the preferred servers list and fails over to the next available server in the preferred servers list. The messaging engine cannot run on a server that is not in the preferred servers list. If no preferred server is available, the messaging engine cannot fail over.

   Use this option together with a single server in the preferred servers list to restrict a messaging engine to a specific server in a workload sharing configuration. Use this option together with a preferred servers list to create a configuration that provides workload sharing and aspects of high availability, for example, one primary server and one failover server for each messaging engine. If we require high availability, use this option with care, because we can reduce or remove the high availability of the messaging engine.

4. Optional: If we defined a preferred servers list, if required, specify that the messaging engine automatically fails back to a more preferred server by selecting the Fail back check box. If a messaging engine is running on a server that is low in the preferred servers list, or in the cluster but not in the preferred servers list (for example, the messaging engine has failed over), the messaging engine automatically fails back to a more preferred server when one becomes available.

5. Ensure that the messaging engine can always reach its data store or file store. If the messaging engine can fail over, that is, for any configuration with high availability characteristics, the data store or file store must be accessible from any server in the cluster on which the messaging engine might run.

   The set of possible servers depends on whether we defined a preferred servers list and whether we selected the Preferred servers only option. For example, a configuration might have a cluster of three servers, server1, server2, and server3, with a single messaging engine that uses a policy configured so that the messaging engine can fail over to any of the servers in the cluster. The message store for the messaging engine must be accessible from all three servers. However, if the configured policy specified a preferred server list of server1 and server2, and the Preferred servers only option is selected, only server1 and server2 would need access to the data store or file store for that messaging engine.

6. Optional: If required, enter a value in the Is alive timer field. This value specifies the interval of time, in seconds, at which the high availability manager (HAManager) checks that a messaging engine is running properly. When this value is 0 (zero), the default value of 120 seconds is used.

7. Click OK.

8. Save changes to the master configuration.

CoreGroupPolicyManagement