| Author |
Message
|
| PeterPotkay |
 Posted: Sun Oct 19, 2014 7:29 am Post subject: Why do Full Repositories accept a second QM by the same name |
 |
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
So we all know your cluster’s 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 don’t 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 |
|
 |
| bruce2359 |
| Posted: Sun Oct 19, 2014 8:47 am Post subject: Re: Why do Full Repositories accept a second QM by the same |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9469
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?
_________________
I like deadlines. I like to wave as they pass by.
ב''ה
Lex Orandi, Lex Credendi, Lex Vivendi. As we Worship, So we Believe, So we Live. |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Sun Oct 19, 2014 11:03 am Post subject: Re: Why do Full Repositories accept a second QM by the same |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
| 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 |
|
|
| JosephGramig |
| Posted: Mon Oct 20, 2014 6:34 am Post subject: Re: Why do Full Repositories accept a second QM by the same |
|
|
Grand Master
Joined: 09 Feb 2006
Posts: 1244
Location: Gold Coast of Florida, 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 |
|
|
| bruce2359 |
| Posted: Mon Oct 20, 2014 6:48 am Post subject: Re: Why do Full Repositories accept a second QM by the same |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9469
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?
_________________
I like deadlines. I like to wave as they pass by.
ב''ה
Lex Orandi, Lex Credendi, Lex Vivendi. As we Worship, So we Believe, So we Live. |
|
| Back to top |
|
|
| exerk |
| Posted: Mon Oct 20, 2014 7:26 am Post subject: |
|
|
Jedi Council
Joined: 02 Nov 2006
Posts: 6339
|
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 |
|
|
| fjb_saper |
| Posted: Mon Oct 20, 2014 7:30 pm Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
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 |
|
|
| PeterPotkay |
| Posted: Tue Oct 21, 2014 4:45 am Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
| 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 |
|
|
| fjb_saper |
| Posted: Tue Oct 21, 2014 5:04 am Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
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 |
|
|
| mqjeff |
| Posted: Tue Oct 21, 2014 5:11 am Post subject: |
|
|
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 |
|
|
| PeterPotkay |
| Posted: Tue Oct 21, 2014 5:33 am Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
| 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 |
|
|
| JosephGramig |
| Posted: Tue Oct 21, 2014 6:55 am Post subject: |
|
|
Grand Master
Joined: 09 Feb 2006
Posts: 1244
Location: Gold Coast of Florida, 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 |
|
|
| mvic |
| Posted: Tue Oct 21, 2014 12:22 pm Post subject: Re: Why do Full Repositories accept a second QM by the same |
|
|
Jedi
Joined: 09 Mar 2004
Posts: 2080
|
| 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 |
|
|
|
|
