+

Search Tips   |   Advanced Search

Add a cluster to a bus without using messaging engine policy assistance

We can add a cluster as a member of a service integration bus without using messaging engine policy assistance. One messaging engine with default properties is created for the cluster. After adding the cluster, we can create more messaging engines and we can create and configure new core group policies to customize the way that the messaging engines are managed.

Ensure that we have defined the resources listed in Add a cluster as a member of a bus.

When we add a server cluster as a member of a bus without using messaging engine policy assistance, one messaging engine is created for the cluster. The messaging engine uses the default SIBus core group policy with default properties, such that the messaging engine can fail over to any server in the cluster.

After adding the cluster, we can customize the configuration. Create more messaging engines and we can create and configure new core group policies to customize the way that the messaging engines are managed. To do this, we must know how to create and configure a core group policy for messaging engines, and know how to use match criteria to associate a messaging engine with a core group policy.

Use the following procedure if we are already familiar with this procedure. Otherwise, use messaging engine policy assistance.

We can optionally tune the initial and maximum Java virtual machine (JVM) heap sizes. Tuning the heap sizes helps to ensure that application servers hosting one or more messaging engines are provided with an appropriate amount of memory for the message throughput you require.

If we are working in a mixed-version cell, a service integration bus running in this version of the product can only include WebSphere Application Server v6 bus members running in the following versions of the product:

If security is enabled, and the bus has mixed-version bus members, the bus members establish trust using an inter-engine authentication alias. If we add a server cluster as a bus member at WAS v6, and it is the first bus member at this level, select or create an authentication alias during this task. This action sets the inter-engine authentication alias.


Tasks

  1. In the navigation pane, click Service integration -> Buses -> bus_name -> [Topology] Bus members.

  2. Click Add to start the Add a new bus member wizard.

  3. In the first pane, select Cluster and, from the drop-down list, select the cluster to make a member of the bus.

  4. In the Messaging engine policy assistance settings pane, ensure that the Enable messaging engine policy assistance check box is not selected.

  5. Select the type of message store that we have already defined.

    • If we use a file store, specify the directory paths for the log files, the permanent file store, and the temporary file store. Do not use the default path, and ensure that we use a unique path for each messaging engine.

    • If we use a data store, specify the JNDI name of the data source that provides access to the database that holds the data store.

  6. Optional: In the Tune performance parameters pane, we can view the current settings of the initial and maximum Java Virtual Machine (JVM) heap sizes. To tune performance by changing the current settings, select the Change heap sizes check box and enter the required changes in the Proposed heap sizes fields.

  7. If security is enabled, and adding this cluster bus member creates a mixed-version bus, the wizard prompts for an authentication alias. Do one of the following:

    • Select an existing authentication alias.

    • Create a new authentication alias. Specify a unique alias name and password.

    This action sets the inter-engine authentication alias.

  8. When the Add a new bus member wizard is finished, save our changes to the master configuration.

The cluster is now a member of the bus and has a single messaging engine, named cluster_name.nnn-bus_name. The messaging engine uses the default SIBus core group policy with default properties (One of N with no preferred servers), such that the messaging engine can fail over to any server in the cluster. This cluster configuration provides a highly available messaging engine.


What to do next

If we require high availability, we might want to do further configuration, for example to specify preferred servers for the messaging engine, or enable the messaging engine to fail back. If we require scalability or workload sharing, add as many messaging engines as you require to the cluster. To customize the messaging engine behavior, create and configure a new core group policy for the messaging engines and use match criteria to associate the messaging engines with the core group policy. It is advisable to create a new, separate, core group policy for each new messaging engine, including the first one. It is not advisable to alter the default SIBus core group policy. See related tasks.


Related:

  • Policies for service integration
  • Messaging engine policy assistance
  • Add a cluster to a bus for high availability or scalability
  • Add a cluster to a bus with a custom configuration
  • Configure high availability and workload sharing of service integration
  • Create a policy for messaging engines
  • Use match criteria to associate a policy with a messaging engine
  • Add a messaging engine to a cluster
  • Configure messaging engines
  • Secure links between messaging engines
  • Tune messaging performance with service integration