Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations Mike Lewis on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

Using Two MQSeries Servers

Status
Not open for further replies.

Guest_imported

New member
Jan 1, 1970
0
0
0
I am setting up MQSeries On NT. I have two NT servers which I am using to sent messages between multiple Clients. I want to use only one Server and keep the other as a backup incase the first one goes down. Is it possible to set MQ series up so that if the first server crashes or is unable to send messaged to one of the clients the second server kicks in. I am writting the Client applicatins in VB

Thanks Richard
 
Not transparently. Your client would need to detect that the connection has been lost and re-establish the connection with the alternate QMgr. In a stateless application this is acceptable but if you need to maintain server state information across both you would have to build in some form of info sharing between the QMgrs as well - messy!

If you do try this, use a short WaitInterval on the MQGET as your client won't detect the connection loss until this expires (or use TCP_KEEPALIVE but this is normally much longer than you would want).

I don't think QMgr clusters would help you here either.

Cheers,
Paul
 
If you're using MQCONNX in your client applications, then it's a simple matter of programming your clients to react to the MQCONNX failure while trying to connect to QMgr1, and then alternately try connecting to QMgr2.

We're all assuming you're using MQ Client libraries to make a synchronous connection to a Queue Manager...

Another trick is to use a IP load balancing solution (virtual IP) product like RadWare or Network Dispatcher, and specify the SVRCONN Connection Name as this virtual IP address. Then, whenever one machine is unavailable, the balancer will route your calls to the surviving queue manager. Not recommended if you have message affinity (i.e. grouping, segmentation) in your app though.

Scott.
 
I think the best solution to this scenario is a Microsoft cluster. Using two NT machines clustered together using Microsoft CLuster Server (MSCS), you can create a virtual queue manager that is controlled by the active node, if NT crashes, or you have a hardeware failure on one node, the Queue manager will fail over to the surviving node with no interuption in service. I have tested this and onl experienced a 12 to 15 second delay in receiving / sending messages while the failover is occurring. You can find instructions for setting up MQ to run as a cluster-aware app at the link below:

 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top