Hi,

  We have the next environment up and running.
 
    2 IIB 9.0.0.5 Linux RedHat 7.1 configure in Active/Pasive using RedHat Cluster resources. Shared Filesystem between two nodes but only running IBB/MQ services in one of the nodes.
    
  Its posible to evolve this enviroment to Active/Active? or do we need to configure new environment "ready" for Active/Active?
 

  Configuring for high availability
  http://www.ibm.com/support/knowledgecenter/SSMKHH_9.0.0/com.ibm.etools.mft.doc/be13740_.htm 

  Tell me if you need more information.

  Thanks in advanced.

Regards

Hi

I don't know if you can remove your IIB/MQ servers from the RedHat cluster, but if it's possible you will have to run both servers in parallel.

You may the use the Multi-instance MQ pattern, which have been used in a high-volumen solution for  large customer. A walk-through of the Multi-instance MQ design pattern prepared by IBM Messaging & Integration can be found here:

http://www.slideshare.net/PeterBroadhurst/active-36536372

We used clustered MQ queues in our solution in order to provide load distribution between the two MQ instances, and you may consider this as well.

Hi Anders

  Thank you very much for the information. Great presentation!
 
  About your question of remove IIB/MQ from RedHat Cluster, the answer is yes, we can remove. I have see that the key is MQ and as you say Multi-instance MQ pattern.
 
  So the question now is, when we install IIB they ask about if MQ is standalone o multi-instance, can standalone MQ become multi-instance? or do we reinstall IIB saying multi-instance?

  Maybe is better to do the question in MQ Forum?

  thank in advanced.
 
Regards

Hi Gabriel,

I think there is one thing which is important to remember: It's not MQ as such which is installed as a Multi-instance MQ Manager - it's the MQ instances which must reside on a shared file-system such as GPFS or NFSv4, which enables a Multi-instance MQ setup.

You first create a new instance from the primary server, which is where you normally would want an Multi-instance to run;

crtmqm -ld /MQHA/logs -md /MQHA/qmgrs QM1

where /MQHA is the path to shared file system. The add info about this instance on the secondary server:

addmqinf -s QueueManager -v Name=QM1 -v Directory=QM1 -v Prefix=/MQHA/logs -v DataPath=/MQHA/qmgrs

You should now start MQ from the primary server so it can get a lock on the MQ instance on the file system

strmqm -x QM1

and repeat this command on the secondary server, so it will try to get a lock on the MQ instance - which will fail until MQ ends on the primary server.

The above commands are sketchy - you should add more details such a Dead-letter queues and size of log files.

Brgds, Anders.

Hi Anders,

  Thank you very much for your explanation and example.

  My question about "installation type" is because there are products that depending on the installation type let you more binaries or capabilities. And when the product is installed you can't "upgrade" product capabilities.

  Its not the case with MQ, you have all the binaries needed to get differents configuration types.

  I have asked the question at MQ forum From MQ standalone to MQ multi-instance

  And Morag Hughson has indicated the configuration we are looking for:

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

  Regards

Looks like you're in good hands here. Anders also suggested the use of Queue Manager Clusters.

We used clustered MQ queues in our solution in order to provide load distribution between the two MQ instances, and you may consider this as well.

I know that I'm in the best hands, thank you very much for your support Morag and Anders!!!

Regards