High availability of messaging engines that are connected to WebSphere MQ

For a WebSphere® MQ queue manager to connect with a WebSphere Application Server messaging engine in a highly available manner, you must install the WebSphere MQ MR01 SupportPac. Alternatively, you can use an external high availability framework.

A WebSphere MQ link connects a service integration messaging engine to a WebSphere MQ queue manager. To WebSphere MQ, the messaging engine appears to be another queue manager. To service integration, the WebSphere MQ network appears to be a foreign bus.

The WebSphere MQ gateway queue manager uses one IP address to reach the WebSphere Application Server gateway messaging engine, and the WebSphere Application Server gateway messaging engine uses one IP address to reach the WebSphere MQ gateway queue manager. In a high availability configuration, if the gateway messaging engine fails over to a different application server, or the gateway queue manager fails and is replaced by a failover gateway queue manager, the connection to the original IP address for the failed component is lost. You must ensure that both products are able to reinstate their connection to the component in its new location.

To ensure that the connection to a failover WebSphere Application Server gateway messaging engine is reinstated, choose one of the following options:
  1. If you are using a version of WebSphere MQ that is earlier than Version 7.0.1, install the SupportPac MR01 for WebSphere MQ. This SupportPac provides the WebSphere MQ queue manager with a list of alternative IP addresses and ports, so that the queue manager can connect with the WebSphere Application Server gateway messaging engine after the messaging engine fails over to a different IP address and port. In WebSphere Application Server you must set a high availability policy of "One of N" for the gateway messaging engine. For more information about the WebSphere MQ MR01 SupportPac, see MR01: Creating a HA Link between WebSphere MQ and a Service Integration Bus.
  2. If you are using WebSphere MQ Version 7.0.1, use the connection name (CONNAME) to specify a connection list. Although typically only one machine name is required, you can provide multiple machine names to configure multiple connections with the same properties. The connections are tried in the order in which they are specified in the connection list until a connection is successfully established. If no connection is successful, the channel starts retry processing. When using this option, specify the CONNAME as a comma-separated list of names of machines for the stated TransportType, making sure that all the WebSphere Application Server cluster member IPs are listed directly in the CONNAME. For further information about using the CONNAME, see the WebSphere MQ information center.
    Note: WebSphere MQ Version 7.0.1 does not require SupportPac MR01 because this release includes the equivalent function to that provided by SupportPac MR01 for earlier releases. The ability to use the CONNAME to specify a connection list was added as part of the support for multi-instance queue managers in WebSphere MQ Version 7.0.1, however, it can also be used as another option to ensure that the connection to a failover WebSphere Application Server gateway messaging engine is reinstated.
  3. Use an external high availability framework, such as HACMP, to manage a resource group that contains the gateway messaging engine. When you use an external high availability framework, the IP address can be failed over to the machine that runs the application server to which the gateway messaging engine has moved. Follow this procedure to handle the IP address correctly:
    • Set a high availability policy of "No operation" for the messaging engine, so that the external high availability framework controls when and where the messaging engine runs.
    • Create resources for the messaging engine and its IP address in the resource group that is managed by the external high availability framework.
    • Consider locating the messaging engine data store in the same resource group as the resource that represents the messaging engine.

To ensure that the connection to a failover WebSphere MQ gateway queue manager is reinstated, create the WebSphere MQ high-availability cluster using an external high availability framework, such as HACMP, that supports IP address takeover. IP address takeover ensures that the gateway queue manager in its new location appears as the same queue manager to the service integration bus.

The gateway queue manager and the gateway messaging engine store status information that they use to prevent loss or duplication of messages when they restart communication following a failure. This means that the gateway messaging engine must always reconnect to the same gateway queue manager.

If you use WebSphere MQ for z/OS® queue sharing groups, you can configure the WebSphere MQ link to use shared channels for the connection. Shared channels provide superior availability compared to the high-availability clustering options available on other WebSphere MQ platforms, because shared channels can reconnect to a different queue manager in the same queue sharing group. Reconnecting in the same queue sharing group is typically faster than waiting to restart the same queue manager in the same or a different location.




Related concepts
External high availability frameworks and service integration
http://www.ibm.com/support/docview.wss?rs=171&uid=swg24013895&loc=en_US&cs=utf-8&lang=en
High availability
Related tasks
Configuring a WebSphere MQ link
Configuring a policy for messaging engines
Concept topic Concept topic    

Terms and conditions for information centers | Feedback

Last updatedLast updated: Aug 30, 2013 10:47:11 PM CDT
http://www14.software.ibm.com/webapp/wsbroker/redirect?version=pix&product=was-nd-iseries&topic=cjt0003_
File name: cjt0003_.html