Author |
Message
|
bobbee |
Posted: Tue May 25, 2010 12:27 pm Post subject: Multi-Instance Queue Managers |
|
|
 Knight
Joined: 20 Sep 2001 Posts: 545 Location: Tampa
|
Is there anyone out there in this DARK MQ world that is using Multi-Instance Queue Managers in production yet.
Are you about to? How long till rollout?
Everything going smooth? |
|
Back to top |
|
 |
exerk |
Posted: Tue May 25, 2010 1:37 pm Post subject: |
|
|
 Jedi Council
Joined: 02 Nov 2006 Posts: 6339
|
Short, sweet answer from me is no. Nor would I even contemplate it until all infrastructure is multi-instance capable...oh, and especially any gateways addressed by 'outsiders' because there's no telling when they'll go to the 'right' version. _________________ It's puzzling, I don't think I've ever seen anything quite like this before...and it's hard to soar like an eagle when you're surrounded by turkeys. |
|
Back to top |
|
 |
fatherjack |
Posted: Tue May 25, 2010 2:00 pm Post subject: |
|
|
 Knight
Joined: 14 Apr 2010 Posts: 522 Location: Craggy Island
|
exerk wrote: |
Nor would I even contemplate it until all infrastructure is multi-instance capable |
As is usual, if you want to make use of new functionality, everyone has to be singing from the same hymn sheet.
And consequently I'd expect it to be some time before multi-instance queue managers become mainstream. Although I'm sure there are some mavericks out there.
It would be good to hear from them. _________________ Never let the facts get in the way of a good theory. |
|
Back to top |
|
 |
bobbee |
Posted: Wed May 26, 2010 2:01 am Post subject: |
|
|
 Knight
Joined: 20 Sep 2001 Posts: 545 Location: Tampa
|
I have client(s) that have many versions of MQ installed, not just v7.0.1+. For the capable ones it is moot. For the others it has been resolved with CCDT's and switches. It is always nice to have a good strong foundation prior to driving nails in any 2x4's. I would think sitting back waiting for the other guy to draw his gun gets you shot. But that is my view. I like the bleeding edge. I don't sleep at night anyway so I might as well be working on production issues.
Maybe I will have a success story soon for the list. This is an interesting solution and one worth describing. But for now, things are NDA. It is using Multi-instance to the limit and it is working as described. Break testing isn't. So that is good. Stay tuned. |
|
Back to top |
|
 |
exerk |
Posted: Wed May 26, 2010 2:04 am Post subject: |
|
|
 Jedi Council
Joined: 02 Nov 2006 Posts: 6339
|
I'm playing with the MR01 exit at the moment, just to see whether it's viable as a < V7.0 MI alternative... _________________ It's puzzling, I don't think I've ever seen anything quite like this before...and it's hard to soar like an eagle when you're surrounded by turkeys. |
|
Back to top |
|
 |
bobbee |
Posted: Wed May 26, 2010 2:08 am Post subject: |
|
|
 Knight
Joined: 20 Sep 2001 Posts: 545 Location: Tampa
|
Thanks for that one, did not know that one existed. Must cathc up on my reading.
My client is under WAS and is testing failover and it is working. Different implementation path. |
|
Back to top |
|
 |
exerk |
Posted: Wed May 26, 2010 2:17 am Post subject: |
|
|
 Jedi Council
Joined: 02 Nov 2006 Posts: 6339
|
Funnily enough, MR01 seems to be designed with WAS SIB in mind  _________________ It's puzzling, I don't think I've ever seen anything quite like this before...and it's hard to soar like an eagle when you're surrounded by turkeys. |
|
Back to top |
|
 |
J.D |
Posted: Wed May 26, 2010 2:49 pm Post subject: |
|
|
Voyager
Joined: 18 Dec 2009 Posts: 92 Location: United States
|
Hi,
Did you guys find the redbook on MQ Clusters v7.0 with multi-instance queue manager option?
Is it the same way what we do in v6.0 except adding both the host names of multi-instance queue managers in CONNAME?
Thank You!! |
|
Back to top |
|
 |
jeevan |
Posted: Wed May 26, 2010 3:42 pm Post subject: |
|
|
Grand Master
Joined: 12 Nov 2005 Posts: 1432
|
exerk wrote: |
I'm playing with the MR01 exit at the moment, just to see whether it's viable as a < V7.0 MI alternative... |
From what perpsective you are looking for an alternative for MI queue manager? We have started MI project with 7.0 broker both work for failover solution. We have not reached the production but has slated for June or july. We have not had any trouble so far.
The only thing necessary is it requries a common/sharable storage device such as GPFS.
Thanks |
|
Back to top |
|
 |
exerk |
Posted: Wed May 26, 2010 11:21 pm Post subject: |
|
|
 Jedi Council
Joined: 02 Nov 2006 Posts: 6339
|
jeevan wrote: |
...The only thing necessary is it requries a common/sharable storage device such as GPFS... |
Really? And when you have a < V7.0.1 connecting queue manager with its single CONNAME, and you fail over to the other server, the one that does not match the CONNAME, and you are not using a virtual IP...? _________________ It's puzzling, I don't think I've ever seen anything quite like this before...and it's hard to soar like an eagle when you're surrounded by turkeys. |
|
Back to top |
|
 |
JosephGramig |
Posted: Thu May 27, 2010 4:58 am Post subject: |
|
|
 Grand Master
Joined: 09 Feb 2006 Posts: 1244 Location: Gold Coast of Florida, USA
|
I haven't tried this but as was intimated by Bobbee, if you have two SVRCONNs with both addresses in the conname and two matching CLNTCONNs each one with only one address (obviously different ones) but the same QMGR name, then if you do a client connect with '*QMGRname' it will connect to the first available one.
Check it: http://hursleyonwmq.wordpress.com/2007/02/26/client-connection-wildcards/
Caution, the CCDT must be build for your specific version of the client, so use MO72. |
|
Back to top |
|
 |
mvic |
Posted: Thu May 27, 2010 5:34 am Post subject: |
|
|
 Jedi
Joined: 09 Mar 2004 Posts: 2080
|
JosephGramig wrote: |
Caution, the CCDT must be build for your specific version of the client, so use MO72. |
Or use a queue manager and runmqsc like the manual says. |
|
Back to top |
|
 |
jeevan |
Posted: Thu May 27, 2010 8:06 am Post subject: |
|
|
Grand Master
Joined: 12 Nov 2005 Posts: 1432
|
exerk wrote: |
jeevan wrote: |
...The only thing necessary is it requries a common/sharable storage device such as GPFS... |
Really? And when you have a < V7.0.1 connecting queue manager with its single CONNAME, and you fail over to the other server, the one that does not match the CONNAME, and you are not using a virtual IP...? |
First of all, Multiinstance queue manager is not two queue manager but one queue manager with multiinstance. So, there is no concept of two queue managers and two server/client conn channels with separate host/ip.
Either you use client connection or cluster( we use it in cluster) channel, the CONNAME has an entry for both hostname(port) separated by comma(,). It tries to connect to the first entry, if it fails, it connects to second.
it is seamless.
it is that simple.
here is link for an IBM presentation
http://www-01.ibm.com/support/docview.wss?uid=swg27017382&aid=1
Note: MULTI here means two. |
|
Back to top |
|
 |
ramires |
Posted: Thu May 27, 2010 12:00 pm Post subject: |
|
|
Knight
Joined: 24 Jun 2001 Posts: 523 Location: Portugal - Lisboa
|
jeevan wrote: |
So, there is no concept of two queue managers and two server/client conn channels with separate host/ip |
ok, its the same queue manager and it can run on different machines. Is your mq cluster v7 qmgrs only?
Regards |
|
Back to top |
|
 |
jeevan |
Posted: Thu May 27, 2010 12:35 pm Post subject: |
|
|
Grand Master
Joined: 12 Nov 2005 Posts: 1432
|
ramires wrote: |
jeevan wrote: |
So, there is no concept of two queue managers and two server/client conn channels with separate host/ip |
ok, its the same queue manager and it can run on different machines. Is your mq cluster v7 qmgrs only?
Regards |
No. it does not have to be. But the MI qmgr needs to be on MQ7.0.1 or higher.
Also, the repository has to be in the highest version always. |
|
Back to top |
|
 |
|