Clustering

IBM MQ clusters can be used with MQIPT by SOCKS-enabling each queue manager in the cluster that spans the internet and by enabling MQIPT to act as SOCKS proxy. In the following diagram, NEWYORK and CHICAGO are in a cluster called HOME and both hold full repositories. NEWYORK, LONDON and PARIS are in another cluster called INVENTORY. Note that CHICAGO does not need to be SOCKS-enabled as it is in a cluster that does not need an MQIPT.

Each queue manager in the INVENTORY cluster is effectively "hidden" behind an MQIPT. As the queue manager has been SOCKS-enabled, when a cluster-sender channel is started, the request is sent out to its destination, using MQIPT acting as a SOCKS proxy. Normally, the CONNAME on a cluster-receiver channel is used to identify the local queue manager, but when used with MQIPT, the CONNAME must identify the local MQIPT and its incoming listener port. In the following diagram, all incoming listener port addresses are 1414 and the outgoing listener port addresses are 1415.

There are two ways to run a SOCKS-enabled queue manager. The first is to SOCKS-enable the whole computer where the queue manager is running. The second is to SOCKS-enable just the queue manager. Using either method, we must configure the SOCKS client so it only makes remote connections using MQIPT as the SOCKS proxy and disable user authentication. There are a number of products on the market to achieve SOCKS support. We must choose one that supports SOCKS V5 protocol.

See Configure MQIPT clustering support for an example of how to configure a cluster network.

Parent topic: SOCKS support