Hello,

If your standalone queue manager is already using it's data files on a shared file server then it can evolve to multi instance as that is how you make a multi-instance queue manager (see http://www.ibm.com/support/knowledgecenter/SSFKSJ_8.0.0/com.ibm.mq.con.doc/q018150_.htm). But it is likely that this is not the case and that the data files reside on the local file system of the machine where the queue manager is running.

You don't need to reinstall MQ, just create a new queue manager would likely be the easiest way to move over. Multi-instance is not an installation option, the same install of the product can deal with either.

If you're already using another cluster technology to failover your system then you don't need multi-instance as well. It is designed as an alternative to other clustering technologies when all you need to failover is the queue manager (and maybe also broker).

Please note though, multi-instance is not an active/active technology. The queue manager is active on one system and in standby awaiting the worst to happen on the other system. If you want active/active, you will need two queue managers. A common technique is to have two queue managers which are both set up as multi instance. QMA normally runs active on system 1 with it's standby instance on system 2. Where QMB is reversed with it's active instance normally running on system 2 and it's standby instance on system 1. Then is something fails on one of the systems, one queue manager is fine and the other fails over to the remaining system, . Of course, you must ensure the both systems are capable of running with both queue manager for a time.

Cheers

Morag

Hi Morag,

  Thank you very much for your clear explanation.
 
  Our environment is the same as explained in the next presentation (page 6) shared by @Anders Heuch
 
  IBM Integration Bus High Availability
  http://www.slideshare.net/PeterBroadhurst/active-36536372

  If I'm understanding ok your last explanation will be the page 10 of the same presentation?
 
  The explained behavior is the same that we have in WebSphere Application Server Message engine (ME). When you create a ME in an application servers cluster, only one member of the cluster has the ME active (its the owner). When this member shutdown, fails,...ONE of the other members take the ownership of the ME (queues, topics, subscribers,..) of course ME "resources" need to be or at shared filesystem or at DB.
 
  So my question now, is there any type of configuration where we get "Active/Active? like if we have different nodes with Queue managers up and running and if some of them stops, fails,...the others take the workload of the stopped, failed,... node.
 
Thanks in advanced.
 
Regards

Hi Gabriel,

Yes, my description does indeed match page 10 in Peter Broadhurst's presentation.

In order to get a true workload takeover - all messages that are currently on a queue at the time a queue manager fails, the only technology available is Queue Sharing Groups on z/OS. This is where the queue is hosted in a Coupling Facility and can be shared between several machines, all of whom host a queue manager in the group able to read that queue or queues.

A close second to the above however, is to use multi-instance queue managers (so that the outage time before messages stuck on a queue of a unavailable queue manager is as low as possible) in combination with Queue Manager Clusters. Queue Manager Clusters allows multiple queue managers to host the same named queue (representing a service) and for the cluster to route new work, i.e. new messages, only to available members of the Queue Manager Cluster.

There's plenty of reading material on Queue Manager Clusters, but here's a few to get you started:-

• IBM Redbooks: High Availability in WebSphere Messaging Solutions
• WebSphere MQ Queue Manager Clustering
• IBM MQ: Managing Workloads, Scaling and Availability with MQ Clusters

Cheers
Morag

Morag,

  I know the "sharing" capabilities of z/OS (for DB2, CICS, IMS, WebSphere,...) but unfortunally is not our environment :-(

  Thank you very much for the links, I have reading for this night :-)

Regards

No worries. I figured it probably wasn't z/OS, but it always bears mentioning just in case.

Happy reading!

Question:  On RHEL7, I have already created a nice MQ v8 QMgr as a MI QMgr(call it BLUE). Shared NAS, NFSv4.  It works

very well. Now my customer wants another, different named QMgr built (call it RED), on the same Linux RHEL7 servers.

I cannot find any documentation on this topic so before I mess with a perfectly fine MI setup, can you tell me something?

If I followed the MI Installation steps, created a different-named QMgr, and  it will have its own log and data filesystems on the Shared NAS, I am not sure if the  'mqs.ini'  will be happy.

This is what I am unsure about.  Help?

When you create RED you specify where the data and logs will go.

mqs.ini only records that there is another qmgr. It will be fine.

Thanks! I did exactly that. Working like a charm! Just unhappy because IBM does not appear to state this in any documentation. ☹

Sometimes it's easier to list the things you can't do than the things you can do :-)

Why not let them know that you expected to see that in Knowledge Center so that they can fix it.

Here's how to feedback:-

IBM Knowledge Center for MQ – how to provide feedback to the team who maintains the contents of the online MQ documentation