6.4. Configure messaging engine policies for clustered service integration bus (SIBus) members.

6.4. Configure messaging engine policies for clustered service integration bus (SIBus) members.
Prev	Chapter 6. Clustering and Workload Management	Next


	[WAS_8.5_INFOCENTER]

Messaging engine policies

High availability messaging engine policy
The high availability messaging engine policy is a predefined messaging engine policy type that is provided when you use messaging engine policy assistance. It helps you to create and configure a messaging engine in a cluster that is a member of a bus when you want the messaging engine to be highly available.
A high availability configuration ensures there is always a messaging engine running in the cluster. When a server that is hosting a messaging engine fails, the messaging engine is activated and run on another server. All messages that are set for high reliability, that were being processed or queued, will continue to be processed when the messaging engine starts on the next server. Use the high availability messaging engine policy for a system where it is a priority to process messages that are set for high reliability with minimum interruption.
The high availability messaging engine policy creates a single messaging engine for the cluster. The messaging engine is configured to fail over to any of the application servers in the cluster. All the application servers in the cluster are added to the preferred servers list, and this list determines the order in which the servers are used for failover. The earlier the server in the preferred servers list, the stronger the preference for that server. The messaging engine does not fail back, that is, if a more preferred server becomes available again, the messaging engine does not move back to that server.
The messaging engine is configured to use a single, highly available, message store (either a database or a file system) that all the servers in the cluster can access.
Scalability messaging engine policy
The scalability messaging engine policy is a predefined messaging engine policy type that is provided when you use messaging engine policy assistance. It helps you to create and configure messaging engines in a cluster that is a member of a bus when you require a configuration that is easy to expand for performance or workload sharing.
The scalability policy ensures that there is a messaging engine for each server in a cluster. If you add more servers to the cluster to support a larger client load or higher messaging throughput, each new server will run a messaging engine. Use the scalability policy for a system where you want to add more servers to a cluster to achieve better performance. If you also require high availability, see Scalability with high availability messaging engine policy.
The scalability messaging engine policy creates a single messaging engine for each server in the cluster. Each messaging engine can run only on the server that it is assigned to, and it cannot fail over to another server. If a server fails, the messaging engine that is running on it also fails, and is not available until the server recovers.
Each messaging engine is assigned to a specific server by configuring it to run only on servers in its list of preferred servers, then specifying only one server in that preferred servers list.
Scalability with high availability messaging engine policy
The scalability with high availability messaging engine policy is a predefined messaging engine policy type that is provided when you use messaging engine policy assistance. It helps you to configure a cluster that is a member of a bus when you require both high availability and scalability in the cluster.
The scalability with high availability configuration ensures that there is a messaging engine for each server in a cluster, and that each messaging engine has a failover location.
The scalability with high availability messaging engine policy creates a single messaging engine for each server in the cluster. Each messaging engine can fail over to one other specified server in the cluster. Each server can host up to two messaging engines, such that there is an ordered circular relationship between the servers. Each messaging engine can fail back, that is, if a messaging engine fails over to another server, and then the original server becomes available again, the messaging engine automatically moves back to that server.
Each messaging engine is assigned to a specific server by configuring it to run only on servers in its list of preferred servers, then specifying only two servers in that preferred servers list. Each server is the first preferred server for one messaging engine and the second preferred server for another one, which creates the circular relationship between the servers. Failback is enabled so that each messaging engine is always hosted by its preferred server if that server is running.
Both servers that can host a specific messaging engine must be able to access the message store (either a database or a file system) that is configured for that messaging engine.
Use the scalability with high availability policy for a system where you want to add more servers to a cluster without affecting the existing messaging engines, but you also want to ensure that messaging is always available.
Custom messaging engine policy
The custom messaging engine policy is a messaging engine policy type that is provided when you use messaging engine policy assistance. It helps you to create and configure messaging engines in a cluster that is a member of a bus when the predefined messaging engine policy types do not meet your needs. You can configure the messaging engine behavior, then the appropriate messaging engine policies are created automatically.
You can create any number of messaging engines for the cluster. For each messaging engine, you must specify the behavior that you require, such as whether it can fail over and whether it uses preferred servers. The core group policies and match criteria for each messaging engine are automatically created.
Use this policy when the other options of High availability, Scalability, or Scalability with high availability do not provide the messaging engine behavior you require, and you are familiar with creating messaging engines and configuring messaging engine policy settings.

Recovering config data from a failed/crashed Messaging Engine (ME)

From WAS v 8.5 onwards, a new feature has been added to WAS where in the event of a crash or failed messaging engine, if there is no backup available, it is possible to recover the configuration data of the messaging engine. This will help recover the messages in the message store (which can either be a filestore or database).

The configuration consists of a bus Bus1 which has an application server, server1 as the bus member. This bus member hosts a queue destination named queue1 which currently has 10 messages. To simulate a failure situation, delete the bus member.

To recover the configuration run the recoverMEConfig command by providing bus name, message store details, node and server name:

$AdminTask recoverMEConfig {-busName Bus1 -messageStore FILE
	-logDirectory "C:\WAS\profiles\AppSrv01\filestores\com.ibm.ws.sib\log"
	-permLogDirectory "C:\WAS\profiles\AppSrv01\filestores\com.ibm.ws.sib\store"
	-tempLogDirectory "C:\WAS\profiles\AppSrv01\filestores\store"
	-nodeName Node01 -serverName server1}

If the message store is a database, the command will look like:

$AdminTask recoverMEConfig {-busName Bus1 -messageStore DB
	-dataSource "DS1" -schemaName "dsSchema" -nodeName Node01 -serverName server1}

Save the config:
```
$AdminConfig save
								
```
This will restore the configuration along with the messages in the message store.

Points to remember when using recoverMEConfig command in WAS

Users can use wsadmin command recoverMEConfig to recover the lost configuration data of a messaging engine. Using this command the configuration data of the crashed or lost Messaging Engine and its child destinations of type queues and topic spaces will be recovered.

The persistent messages in the message store can be recovered once the Messaging Engine is started after the command executes successfully. However not all the configuration data will be available for the user and hence the user needs to keep in mind the cases listed below:

What will be recovered for Messaging Engine configuration
1. The UUID of the Messaging Engine will be recovered
2. The name of the messaging engine will be generated on basis of the bus name, node name and server name specified as input parameter by the user in the command. If these values are different from the crashed or lost messaging engine then original messaging engine name will not be recovered.
3. localizationPoints for all queues and topics defined on Messaging Engine
What will be recovered for Messaging Engine destinations
1. localizationPointRefs for all queues and topic spaces defines on messaging engine
2. UUID
3. The system exception destination name is created after the name of the Messaging Engine. Hence if the bus name, messaging engine name is same as the lost or crashed messaging engine name in the message store, then it will be recovered with same UUID else it will be recovered by same UUID but with different name.

NOTE: Default values that have been changed for the administrative properties of Messaging Engine and destination can't be recovered. When user will recover, all properties are set to their default values

Prev	Up	Next
6.3. Configure distributed session management for high availability and failover scenarios, including the WebSphere eXtreme Scale option.	Home	6.5. Configure high availability using core groups.