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 » joining a qmgr to 2 clusters

Post new topic  Reply to topic
 joining a qmgr to 2 clusters « View previous topic :: View next topic » 
Author Message
ydsk
PostPosted: Tue Oct 24, 2006 11:44 am    Post subject: joining a qmgr to 2 clusters Reply with quote

Chevalier

Joined: 23 May 2005
Posts: 410

Hi,

Here is my scenario:

APPQM --- BKR1 --- BKR2 : all 3 qmgrs are part of a cluster called CLUS1. BKR1 and BKR2 are 2 full repositories of CLUS1. They aren't part of any other cluster.

Now we want to create 2 more new qmgrs ( not yet named ) and those 2 will be part of a new cluster called CLUS2. They will be the full repositories for CLUS2. They won't be part of any other cluster.

I have 2 questions:

1) I want to join APPQM to CLUS2 so it will be part of both CLUS1 and CLUS2. Does APPQM have to be a full repository ( currently it isn't a full repository ) ??

2) If APPQM wants to be part of both CLUS1 and CLUS2, Can the 2 new qmgrs in CLUS2 have the same names as their counter-parts in the other cluster CLUS1 ( BKR1 and BKR2) ??

Can someone please answer my 2 questions above ?

Thanks.
ydsk.
Back to top
View user's profile Send private message
jefflowrey
PostPosted: Tue Oct 24, 2006 11:50 am    Post subject: Reply with quote

Grand Poobah

Joined: 16 Oct 2002
Posts: 19981

You should never have two queue managers with the same name.
_________________
I am *not* the model of the modern major general.
Back to top
View user's profile Send private message
ydsk
PostPosted: Tue Oct 24, 2006 11:59 am    Post subject: Reply with quote

Chevalier

Joined: 23 May 2005
Posts: 410

Jeff,

I know we should never have 2 qmgrs with the same name but in my case they aren't connected at all. Only APPQM will be part of both the clusters.

CLUS1 and CLUS2 will be on separate boxes.

Please let me know.

Thanks.
ydsk
Back to top
View user's profile Send private message
jefflowrey
PostPosted: Tue Oct 24, 2006 12:08 pm    Post subject: Reply with quote

Grand Poobah

Joined: 16 Oct 2002
Posts: 19981

So how is APPQM going to know which of the two to send a message to?

What if you have a queue of the same name in both clusters? On the same duplicately named queue manager?

You're very very very likely to crash yourself completely if you try this.

As long as all queue managers are uniquely named, there's nothing wrong with what you're trying to do (although it would probably be better to have a bigger cluster rather than two separate clusters), and you don't need to make APPQM a full repository - you just have to set a CLUSNL instead of a CLUSTER attribute on it.
_________________
I am *not* the model of the modern major general.
Back to top
View user's profile Send private message
ydsk
PostPosted: Tue Oct 24, 2006 12:19 pm    Post subject: Reply with quote

Chevalier

Joined: 23 May 2005
Posts: 410

Jeff,

We are in the process of migration and separation from v5 to v6.

We currently have BKR1 and BKR2 ( hosting v5 brokers on Solaris) at v5.3. APPQM is the application qmgr that has a queue alias definition whose base queue ( a clustered local queue ) resides on both BKR1 and BKR2.

And we are getting 2 new AIX boxes for v6. So, they will host BKR1 and BKR2 ( or whatever new qmgr names we come up with). Our idea is to define a base queue ( with a different name from that of v5 base queue ) on both the new brokers so that we can change the alias on APPQM to point to the new broker queue ( when APPQM becomes part of both the clusters) and the applications connecting to APPQM don't have to change their code as they will still be talking to the same alias queue.

Finally APPQM will be part of the new cluster only. We will do away with the old cluster CLUS1 and its broker qmgrs completely after migration. That's the goal.

Thanks.
ydsk.
Back to top
View user's profile Send private message
ydsk
PostPosted: Tue Oct 24, 2006 12:43 pm    Post subject: Reply with quote

Chevalier

Joined: 23 May 2005
Posts: 410

On APPQM on the CLUSRCVR channel definition we give the NAMELIST( that has both CLUS1 and CLUS2), and create a new CLUSSDR channel ( with a different naming convention and so a different name than the CLUSSDRs that are already pointing to BKR1 and BKR2 in the v5 cluster).

Of course, the CLUSRCVR on the new brokers will have the same naming convention as the new CLUSSDR defined on APPQM as they need to match.

I think the idea will work but may not be very clean in terms of naming conventions of clustered channels.

Pls let me know if you think it doesn't work.
Back to top
View user's profile Send private message
jefflowrey
PostPosted: Tue Oct 24, 2006 1:57 pm    Post subject: Reply with quote

Grand Poobah

Joined: 16 Oct 2002
Posts: 19981

Suppose you have a v5 flow listening to a queue named IN1 on BRK1 in CLUS1.

You then add a v6 flow listening to a queue named IN1 on BRK1 in CLUS2.

You then have a client app put to a QALIAS that resolves to the queue named IN1.

Which Cluster is the cluster name resolution going to pick? Which BRK1 queue mgr is going to get the message.

DO NOT DO THIS.
_________________
I am *not* the model of the modern major general.
Back to top
View user's profile Send private message
Display posts from previous:   
Post new topic  Reply to topic Page 1 of 1

MQSeries.net Forum Index » Clustering » joining a qmgr to 2 clusters
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.