ASG
IBM
Zystems
Cressida
Icon
Netflexity
 
  MQSeries.net
Search  Search       Tech Exchange      Education      Certifications      Library      Info Center      SupportPacs      LinkedIn  Search  Search                                                                   FAQ  FAQ   Usergroups  Usergroups
 
Register  ::  Log in Log in to check your private messages
 
RSS Feed - WebSphere MQ Support RSS Feed - Message Broker Support

MQSeries.net Forum Index » Clustering » Using a GateWay MQ manager for 2 Cluster

Post new topic  Reply to topic Goto page 1, 2  Next
 Using a GateWay MQ manager for 2 Cluster « View previous topic :: View next topic » 
Author Message
jstefano
PostPosted: Wed Feb 28, 2007 3:20 pm    Post subject: Using a GateWay MQ manager for 2 Cluster Reply with quote

Apprentice

Joined: 13 Apr 2006
Posts: 48

Dear MQ gurus!

we have an MQ Cluster ( 3 QMs: 2 QMs full repositories and 1 MQ Gateway for load balancing)
Now we would like to create another MQ Cluster (on separate machines, different names, pretty much the same functionality)
Can we use the existing MQ Gateway to handle both Clusters?
We need MQ Gateway for load balancing and it's working great on existing cluster (I set it up with the great and generous help from gurus on this forum). It's our idea doable? It's Safe? Or will be safer just create another MQ manager (on the same box like existing Gateway) and let it join the new cluster?

Any help will be appreciated a lot!

Million thanks

Take Care!

Jan Stefanovic
Back to top
View user's profile Send private message
jefflowrey
PostPosted: Wed Feb 28, 2007 3:31 pm    Post subject: Reply with quote

Grand Poobah

Joined: 16 Oct 2002
Posts: 19981

It's better to have larger clusters than it is to have more clusters.

You can use Cluster Namelists to put a queue manager or a queue into more than one cluster.
_________________
I am *not* the model of the modern major general.
Back to top
View user's profile Send private message
jstefano
PostPosted: Wed Feb 28, 2007 3:42 pm    Post subject: Reply with quote

Apprentice

Joined: 13 Apr 2006
Posts: 48

Hi Jeff

thanks for the reply, but how will be that one gateway distributing messages? Should I create one more shared cluster queue and let MQ Gateway to send messages to that queue? Maybe that's the way?

many thanks!

Jan
Back to top
View user's profile Send private message
Michael Dag
PostPosted: Wed Feb 28, 2007 11:13 pm    Post subject: Reply with quote

Jedi Knight

Joined: 13 Jun 2002
Posts: 2607
Location: The Netherlands (Amsterdam)

it's perfectly doable and thought there was a sample of overlapping clusters in the cluster manual.
_________________
Michael



MQSystems Facebook page
Back to top
View user's profile Send private message Visit poster's website MSN Messenger
jsware
PostPosted: Thu Mar 01, 2007 12:26 am    Post subject: Reply with quote

Chevalier

Joined: 17 May 2001
Posts: 455

jefflowrey wrote:
It's better to have larger clusters than it is to have more clusters.
No it isn't. IMHO its better to have clusters that group cohesive qmgrs together.

Your gateway qmgr can be in both clusters and route messages into both clusters as I believe you wish. I would advise that the clustered queues in cluster A have different names than queues in cluster B. Obviously the queues to be loadbalanced in cluster A need to have the same name - as do those in cluster B.

We have done this and its quite successful.
_________________
Regards
John
The pain of low quaility far outlasts the joy of low price.
Back to top
View user's profile Send private message
HubertKleinmanns
PostPosted: Fri Mar 02, 2007 7:13 am    Post subject: Reply with quote

Shaman

Joined: 24 Feb 2004
Posts: 732
Location: Germany

scottj2512 wrote:
jefflowrey wrote:
It's better to have larger clusters than it is to have more clusters.
No it isn't. IMHO its better to have clusters that group cohesive qmgrs together.

Your gateway qmgr can be in both clusters and route messages into both clusters as I believe you wish. I would advise that the clustered queues in cluster A have different names than queues in cluster B. Obviously the queues to be loadbalanced in cluster A need to have the same name - as do those in cluster B.

We have done this and its quite successful.


Sometimes it could make sense, to have several clusters, to separate message flows, queues etc. QMgrs in on cluster do not see queues in another cluster.

But generally many small clusters need more resources than one big cluster.

I would say: It depends on .
_________________
Regards
Hubert
Back to top
View user's profile Send private message Visit poster's website
jsware
PostPosted: Fri Mar 02, 2007 9:20 am    Post subject: Reply with quote

Chevalier

Joined: 17 May 2001
Posts: 455

HubertKleinmanns wrote:
Sometimes it could make sense, to have several clusters, to separate message flows, queues etc. QMgrs in on cluster do not see queues in another cluster.

But generally many small clusters need more resources than one big cluster.

I would say: It depends on .

Agreed. I was not advocating small or large clusters. I was advocating appropriately sized clusters.
_________________
Regards
John
The pain of low quaility far outlasts the joy of low price.
Back to top
View user's profile Send private message
jstefano
PostPosted: Fri Mar 02, 2007 10:29 am    Post subject: Reply with quote

Apprentice

Joined: 13 Apr 2006
Posts: 48

Gentlemen


Many thanks for your great input, so, I follow John's idea and I will use the same Gateway and simply create new Definitions and new cluster, hope it will work... and of course, all names will be different.

You guys are the best!

Million thanks and have a great weekend everybody!


Jan
Back to top
View user's profile Send private message
MQAltaf
PostPosted: Tue Mar 06, 2007 12:38 am    Post subject: Reply with quote

Centurion

Joined: 10 Feb 2005
Posts: 119

Hi,

We are also planning on using overlapping clusters whereby two queue managers act as gateways. We have a hot/hot scenario in that both client application are connected to a queue manager and can put messages. Our backend application will also run hot/hot and service requests coming in. However the problem we are facing is returning messages to the correct instance of the client application which sent the message. Our backend app honours the reply to queue and reply to queue manager fields in the MQMD.

Client app puts to a remote queue def named TESTX on QMs QM1 and QM2 and reads response messages from TESTX.REPLY. TESTX has a rname of REALX which is defined on the backend QMs. RQMNAME= ANY_CLUSTER which is a clustered Q on the gateway QM5 which is part of both cluster1 and cluster2. ANY_CLUSTER has rname, rqmname and xmitq set to blank. TESTX.REPLY is clustered in cluster1 so the GATEWAY QM5 knows about the queues

REALX is a local clustered Q on QM3 and QM4 which are part of cluster2. QMGR Aliases QM1 and QM2 are also defined on QM3 and QM4. They have rname and xmitq set to blank but have a rqmname=ANY_CLUSTER.

When a message arrives at REALX the backend app read the messages and sets reply to queue and reply to queue manager to what is was in the request. Because reply to queue manager will either by QM1 or QM2 the messages get put on the QMGR Alias and then gets routed to ANY_CLUSTER on the gateway QM5. From here the gateway QM5 will either route the response to TEXTX.REPLY on either QM1 or QM2. This is because the standard behaviour of load balancing occurs hence response messages my not end up at their correct destination.

Has anyone come accross this and if so how has this been overcome?

Thanks in advance for any help
Back to top
View user's profile Send private message
HubertKleinmanns
PostPosted: Tue Mar 06, 2007 1:25 am    Post subject: Reply with quote

Shaman

Joined: 24 Feb 2004
Posts: 732
Location: Germany

MQAltaf wrote:
Hi,

We are also planning on using overlapping clusters whereby two queue managers act as gateways. We have a hot/hot scenario in that both client application are connected to a queue manager and can put messages. Our backend application will also run hot/hot and service requests coming in. However the problem we are facing is returning messages to the correct instance of the client application which sent the message. Our backend app honours the reply to queue and reply to queue manager fields in the MQMD.

Client app puts to a remote queue def named TESTX on QMs QM1 and QM2 and reads response messages from TESTX.REPLY. TESTX has a rname of REALX which is defined on the backend QMs. RQMNAME= ANY_CLUSTER which is a clustered Q on the gateway QM5 which is part of both cluster1 and cluster2. ANY_CLUSTER has rname, rqmname and xmitq set to blank. TESTX.REPLY is clustered in cluster1 so the GATEWAY QM5 knows about the queues

REALX is a local clustered Q on QM3 and QM4 which are part of cluster2. QMGR Aliases QM1 and QM2 are also defined on QM3 and QM4. They have rname and xmitq set to blank but have a rqmname=ANY_CLUSTER.

When a message arrives at REALX the backend app read the messages and sets reply to queue and reply to queue manager to what is was in the request. Because reply to queue manager will either by QM1 or QM2 the messages get put on the QMGR Alias and then gets routed to ANY_CLUSTER on the gateway QM5. From here the gateway QM5 will either route the response to TEXTX.REPLY on either QM1 or QM2. This is because the standard behaviour of load balancing occurs hence response messages my not end up at their correct destination.

Has anyone come accross this and if so how has this been overcome?

Thanks in advance for any help


MQAltaf,

when I read correct, you have only one gateway (QM5), not two! The gateway then balances between two backend QMgrs.

Nevertheless, I hav got one remark to you sample:

The REPLY queue needs not to be a cluster queue at all! Replys are routed first to the ReplyToQMgr and then resolved to the queue.

And one alternative set of definitions:

The QMgr aliases QM1 and QM2 needs only to be defined on the gateway QMgr QM5 as member of the cluster 2 (where QM3 and QM4 are members of). Then the cluster alias ANY_CLUSTER needs only to be defined in cluster 1 (where QM1 and QM2 are members of). But your solution should work too.
_________________
Regards
Hubert
Back to top
View user's profile Send private message Visit poster's website
MQAltaf
PostPosted: Tue Mar 06, 2007 1:40 am    Post subject: Reply with quote

Centurion

Joined: 10 Feb 2005
Posts: 119

Hi,

Thanks for the update.

I have ommited the second gateway which is QM6 but it is setup in the same way as QM5. The problem I am facing is getting the response messages back to the QM that sent the intial request. At the moment responses are being round robined between the two reply Qs TESTX.REPLY

Any ideas?
Back to top
View user's profile Send private message
HubertKleinmanns
PostPosted: Tue Mar 06, 2007 2:23 am    Post subject: Reply with quote

Shaman

Joined: 24 Feb 2004
Posts: 732
Location: Germany

MQAltaf wrote:
Hi,

Thanks for the update.

I have ommited the second gateway which is QM6 but it is setup in the same way as QM5. The problem I am facing is getting the response messages back to the QM that sent the intial request. At the moment responses are being round robined between the two reply Qs TESTX.REPLY

Any ideas?


MQAltaf,

then the backend systems do not send REPLYs, otherwise the answer would definitely not round robined! I guess, the backend applications address the queues as remote queues.

Reply queues need not be defined as cluster queues. Remove the cluster attribute of the REPLY queues! When then the backend applications get a "2085", then they look for remote queues, not for the ReplyToQmgr!
_________________
Regards
Hubert
Back to top
View user's profile Send private message Visit poster's website
MQAltaf
PostPosted: Tue Mar 06, 2007 4:09 am    Post subject: Reply with quote

Centurion

Joined: 10 Feb 2005
Posts: 119

Hi,

Thanks for the response.

I will remove the Cluster attribute sometime tomorrow.

"I guess, the backend applications address the queues as remote queues"

This is not entirely correct as the backend application polling queues REALX doesnt know anything about where the reply queues TEXTX.REPLY are defined. It knows about QMGR Aliases QM1 and QM2 which are the same as the reply to queue manager. The Aliases have remote queue manager=ANY_CLUSTER so the response message gets routed to this queue which is on the gateway QM. Becuase the gateway QM is part of cluster1 it knows about the queues TESTX.REPLY which is what is populated in the reply to queue in the MQMD.

[/quote]
Back to top
View user's profile Send private message
jefflowrey
PostPosted: Tue Mar 06, 2007 4:35 am    Post subject: Reply with quote

Grand Poobah

Joined: 16 Oct 2002
Posts: 19981

The backend applications should follow the correct request/reply pattern, and use the ReplyToQ and ReplyToQMgr fields of the Request message when putting the reply.

You should never try and solve the addressing of reply messages any other way, particularly not in your MQ network.

Please don't overlap clusters unless there's a better reason than "logical separation of application function". That's a terrible reason to overlap clusters, and has lead some companies into big production outages. It also makes the MQ network needlessly confusing and does not add the value that one might think it does.

MQ provides plenty of logical separation of application function all on it's own, with proper application of OAM security and naming standards.
_________________
I am *not* the model of the modern major general.
Back to top
View user's profile Send private message
HubertKleinmanns
PostPosted: Tue Mar 06, 2007 7:01 am    Post subject: Reply with quote

Shaman

Joined: 24 Feb 2004
Posts: 732
Location: Germany

MQAltaf wrote:
Hi,

Thanks for the response.

I will remove the Cluster attribute sometime tomorrow.

"I guess, the backend applications address the queues as remote queues"

This is not entirely correct as the backend application polling queues REALX doesnt know anything about where the reply queues TEXTX.REPLY are defined. It knows about QMGR Aliases QM1 and QM2 which are the same as the reply to queue manager. The Aliases have remote queue manager=ANY_CLUSTER so the response message gets routed to this queue which is on the gateway QM. Becuase the gateway QM is part of cluster1 it knows about the queues TESTX.REPLY which is what is populated in the reply to queue in the MQMD.



MQAltaf,

MQ works not that way! Reply messages are addressed to a queue manager - not to a queue. The replying backend QMgrs as well as the gateway QMgrs do not have to know anything about the queue TESTX.REPLY! The only thing they have to know is, how to reach the originating queue manager. The gateway QMgrs do not resolve the queue at all - they only know the target QMgr (QM1 or QM2) and sends the message over a (cluster) channel to the target QMgr! The target QMgr now tries to resolve the queue and puts the message to it.

If you remove the cluster attribut and the messages are put somewhere into a DLQ, the backend systems definitely do no perform REPLYs.
_________________
Regards
Hubert
Back to top
View user's profile Send private message Visit poster's website
Display posts from previous:   
Post new topic  Reply to topic Goto page 1, 2  Next Page 1 of 2

MQSeries.net Forum Index » Clustering » Using a GateWay MQ manager for 2 Cluster
Jump to:  



You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
Protected by Anti-Spam ACP
 
 


Theme by Dustin Baccetti
Powered by phpBB © 2001, 2002 phpBB Group

Copyright © MQSeries.net. All rights reserved.