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 IndexClusteringWhy do Full Repositories accept a second QM by the same name

Post new topicReply to topic
Why do Full Repositories accept a second QM by the same name View previous topic :: View next topic
Author Message
PeterPotkay
PostPosted: Sun Oct 19, 2014 7:29 am Post subject: Why do Full Repositories accept a second QM by the same name Reply with quote

Poobah

Joined: 15 May 2001
Posts: 7582

So we all know your clusters going to be less than perfect if you add a second QM by the same name into the cluster. Or if you delete and recreate a Partial Repository and then add the new one into the cluster, again things are going to be messy.

Clearly the FRs know this is a duplicate because they will show you both by QMID when you do a display cluster queue manager list. And they let you selectively eject one of the duplicates.

So if the FRs can identify duplicates, why do they even accept the second one? I have never seen anything in MQ Clustering where having 2 QMs by the same name would be anything less than problematic , so why dont the FRs just reject the attempt by the second QM automatically, sending back some sort of message to the new PR attempting to join that would cause the new PR to log a rather explicit message along the lines of Hey, you are about to make a mess of things here. If you really want to add THIS queue manager to the cluster, first remove the old one by the same name.

Is there any legitimate reason for a FR to accept a duplicate PR?
_________________
Peter Potkay
Keep Calm and MQ On
Back to top
View user's profile Send private message
bruce2359
PostPosted: Sun Oct 19, 2014 8:47 am Post subject: Re: Why do Full Repositories accept a second QM by the same Reply with quote

Poobah

Joined: 05 Jan 2008
Posts: 8534
Location: US: west coast, almost. Otherwise, enroute.

PeterPotkay wrote:
Is there any legitimate reason for a FR to accept a duplicate PR?

Prior to QMID, The most significant warning about duplicate qmgr names in clusters was how to remove one of 'em from the cluster at some future date.

With the advent of QMID, there is little likelihood of an exact duplicate qmgr (QMID) name. The RESET CLUSTER command allows you to specify qmgr-name or QMID.

Cluster documentation warns about duplicate names here and there.

Given QMID uniqueness, is there a legitimate reason for an FR to summarily reject a duplicate?
_________________
There are two types of people in this world:
1) Those that can extrapolate from incomplete data
Back to top
View user's profile Send private message
PeterPotkay
PostPosted: Sun Oct 19, 2014 11:03 am Post subject: Re: Why do Full Repositories accept a second QM by the same Reply with quote

Poobah

Joined: 15 May 2001
Posts: 7582

bruce2359 wrote:
Given QMID uniqueness, is there a legitimate reason for an FR to summarily reject a duplicate?


Because there is no possible reason where having 2 QMs with the same name in the cluster is desireable?
_________________
Peter Potkay
Keep Calm and MQ On
Back to top
View user's profile Send private message
JosephGramig
PostPosted: Mon Oct 20, 2014 6:34 am Post subject: Re: Why do Full Repositories accept a second QM by the same Reply with quote

Grand Master

Joined: 09 Feb 2006
Posts: 1208
Location: Derby City, USA

PeterPotkay wrote:
bruce2359 wrote:
Given QMID uniqueness, is there a legitimate reason for an FR to summarily reject a duplicate?


Because there is no possible reason where having 2 QMs with the same name in the cluster is desireable?
Back to top
View user's profile Send private message AIM Address
bruce2359
PostPosted: Mon Oct 20, 2014 6:48 am Post subject: Re: Why do Full Repositories accept a second QM by the same Reply with quote

Poobah

Joined: 05 Jan 2008
Posts: 8534
Location: US: west coast, almost. Otherwise, enroute.

JosephGramig wrote:
PeterPotkay wrote:
bruce2359 wrote:
Given QMID uniqueness, is there a legitimate reason for an FR to summarily reject a duplicate?


Because there is no possible reason where having 2 QMs with the same name in the cluster is desireable?


But, does this rise to the level of being intolerable - rather than just being highly annoying?
_________________
There are two types of people in this world:
1) Those that can extrapolate from incomplete data
Back to top
View user's profile Send private message
exerk
PostPosted: Mon Oct 20, 2014 7:26 am Post subject: Reply with quote

Jedi Council

Joined: 02 Nov 2006
Posts: 6110

Two ways to look at this I suppose:

1. The case of a deleted/redefined queue manager, there is one and one only instance of a queue manager in the cluster, but there is also a reference (QMID) to a no longer existing queue manager. Is this an issue? I'd say no provided that deletion/redefinition is the only circumstance that will cause the 'issue';

2. The case of someone trying to deliberately or accidentally trying to introduce a queue manager into a cluster, where the name of that queue manager already exists, whether to try and hijack its workload or not. Is this an issue? I'd say yes, not least because someone examining QMIDs might just consider the 'newer' queue manager to be the legit one and force out the 'white hat' one.

Notwithstanding what PeterPotkay posted on the ListServer (repeated below), if there are lax procedures around cluster resets to remove 'stale' QMIDs, there is a possibility for 2. above to happen.

A thought-provoking topic Peter, something I never considered as I would not conceive of trying to introduce same-named queue managers into a cluster, so perhaps time for me to upgrade my paranoia module

Maybe IBM could introduce another cluster-related event queue, for FRs to publish to, events such as "...Duplicate QMGRNAME attempting to join CLUSTERNAME..." and other cluster-related messages would be nice too, save having to try and trap them in the logs?

Quote:
AMQ9468
Cluster receiver channel <insert_3> has been configured by multiple queue managers.
Severity
0 : Informational
Explanation
Queue manager <insert_4> has joined a cluster using a cluster receiver channel with the same name as one that has already been defined by queue manager <insert_5> . All cluster receiver channels used within a cluster must be uniquely named. Only the last queue manager to join the cluster will use the named channel, Queue manager <insert_5> will not successfully participate in the cluster while the newer queue manager is a member.
Response
The use of a channel name currently associated with a different queue manager in the cluster may be intentional, for example, the original queue manager may have been deleted and re-created as a new queue manager. However, accidental duplication of a channel name across multiple queue managers will also result in this behaviour. If this was not intended, further investigation into the configuration of the queue managers should be performed.

_________________
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
View user's profile Send private message
fjb_saper
PostPosted: Mon Oct 20, 2014 7:30 pm Post subject: Reply with quote

Grand High Poobah

Joined: 18 Nov 2003
Posts: 20138
Location: LI,NY

There I'd thought you'd eliminated that particular problem from your FR's by using chlauth records...
So that any attempt to introduce another qmgr by the same name would have to be deliberate, AND would have to happen from a known IP used by the old qmgr with the same name...

Well maybe not...
_________________
MQ & Broker admin
Back to top
View user's profile Send private message Send e-mail
PeterPotkay
PostPosted: Tue Oct 21, 2014 4:45 am Post subject: Reply with quote

Poobah

Joined: 15 May 2001
Posts: 7582

fjb_saper wrote:
There I'd thought you'd eliminated that particular problem from your FR's by using chlauth records...
So that any attempt to introduce another qmgr by the same name would have to be deliberate, AND would have to happen from a known IP used by the old qmgr with the same name...

Well maybe not...


Yup, if the FRs are going to allow another QM to take over so easily, it makes it all the more crucial that you use some method to control what can connect to your FRs (SSL, Security Exit, classic firewall and/or CHLAUTH).

And perhaps monitor and alert for AMQ9468 showing up in your QM error logs.
_________________
Peter Potkay
Keep Calm and MQ On
Back to top
View user's profile Send private message
fjb_saper
PostPosted: Tue Oct 21, 2014 5:04 am Post subject: Reply with quote

Grand High Poobah

Joined: 18 Nov 2003
Posts: 20138
Location: LI,NY

PeterPotkay wrote:

Yup, if the FRs are going to allow another QM to take over so easily, it makes it all the more crucial that you use some method to control what can connect to your FRs (SSL, Security Exit, classic firewall and/or CHLAUTH).

And perhaps monitor and alert for AMQ9468 showing up in your QM error logs.

That would be a little late and after the fact. The damage is already done.
What I was trying to hint to there is preventing the damage.
_________________
MQ & Broker admin
Back to top
View user's profile Send private message Send e-mail
mqjeff
PostPosted: Tue Oct 21, 2014 5:11 am Post subject: Reply with quote

Grand Master

Joined: 25 Jun 2008
Posts: 17447

It seems reasonably clear to me that the cluster algorithms primarily work on the qmid/channel name.

I think it would be a better use of the lab's time to provide better overall visualization and management tools for clusters, than to provide fixes that lock the barn after the cows have left.

Granted, the tools in MQExplorer for visualizing and working with clusters are fairly good. But it would be extremely helpful to have a one-button/one-command "delete this object from the cluster", and know that it would work successfully and reliably without causing a major disruption of cluster traffic.
Back to top
View user's profile Send private message
PeterPotkay
PostPosted: Tue Oct 21, 2014 5:33 am Post subject: Reply with quote

Poobah

Joined: 15 May 2001
Posts: 7582

fjb_saper wrote:
PeterPotkay wrote:

Yup, if the FRs are going to allow another QM to take over so easily, it makes it all the more crucial that you use some method to control what can connect to your FRs (SSL, Security Exit, classic firewall and/or CHLAUTH).

And perhaps monitor and alert for AMQ9468 showing up in your QM error logs.

That would be a little late and after the fact. The damage is already done.
What I was trying to hint to there is preventing the damage.


SSL, Security Exit, classic firewall and/or CHLAUTH would all be before the fact, to prevent the problem.

Monitoring for the AMQ9468 was listed as an AND, not an OR, as a means to identify if your primary controls failed for some reason.
_________________
Peter Potkay
Keep Calm and MQ On
Back to top
View user's profile Send private message
JosephGramig
PostPosted: Tue Oct 21, 2014 6:55 am Post subject: Reply with quote

Grand Master

Joined: 09 Feb 2006
Posts: 1208
Location: Derby City, USA

My experience with this issue was with a client that had a lot of mergers. They had a fair amount of z/OS Qmgrs which have four character names. Since the same vendor was used at the two company's, they ended up with duplicate Qmgr names after the merger. Before you inject a Qmgr into a cluster, query the cluster for that Qmgr name.

Look before you leap.
Back to top
View user's profile Send private message AIM Address
mvic
PostPosted: Tue Oct 21, 2014 12:22 pm Post subject: Re: Why do Full Repositories accept a second QM by the same Reply with quote

Jedi

Joined: 09 Mar 2004
Posts: 2078

PeterPotkay wrote:
Is there any legitimate reason for a FR to accept a duplicate PR?

I think the intent is to allow the reinstatement of a qmgr named X on a new machine because the qmgr named X was on hardware that just died. The FRs see there is a new QMID from the new instance of qmgr X, and keep historical knowledge of the old one, but mark only the new one as being the one currently "in use".
Back to top
View user's profile Send private message
Display posts from previous:
Post new topicReply to topic Page 1 of 1

MQSeries.net Forum IndexClusteringWhy do Full Repositories accept a second QM by the same name
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.