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 IndexClusteringMQ Cluster Issue

Post new topicReply to topic
MQ Cluster Issue View previous topic :: View next topic
Author Message
yshakraj
PostPosted: Sat Feb 22, 2020 9:55 am Post subject: MQ Cluster Issue Reply with quote

Voyager

Joined: 14 Sep 2011
Posts: 90

Hi All ,

I faced an issue today with a cluster where a remote QM tried to join the cluster with same name of the QM - already existing in the cluster and cluster started behaving crazy . As per my understanding cluster will not allow duplicate QM name.But is there any possibility of this ?

Another question is - Is it really possible to get a remote QM to get added in a higher environment cluster -providing the firewall and all in place ?

Say will I be able to add a QM from Development environment to Prod Cluster ? using mqm as the MCA user ?

I tried doing telnet between these servers using QM port and seems to be no connection. Is there any other way I can assure that there is no connection between these two servers ?

Thanks in advance ,
yshakraj
Back to top
View user's profile Send private message
bruce2359
PostPosted: Sat Feb 22, 2020 11:07 am Post subject: Re: MQ Cluster Issue Reply with quote

Poobah

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

yshakraj wrote:
Hi All ,

I faced an issue today with a cluster where a remote QM tried to join the cluster ...

What do you mean 'join the cluster?' Do you mean MQCONNect to a qmgr that is a member of the cluster? What error did you receive when you attempted to 'join?' What errors in the ERROR logs?

yshakraj wrote:
...with same name of the QM - already existing in the cluster ...

You can have a cluster named BOB and a qmgr named BOB in the BOB cluster. This is not an issue. You can also have multiple qmgrs with the same name in the same cluster, but not recommended, as separating them (if this becomes necessary) might be messy.

yshakraj wrote:
...and cluster started behaving crazy ...

Please be precise. What symptoms are you seeing? Error messages in the ERROR logs?

yshakraj wrote:
As per my understanding cluster will not allow duplicate QM name.But is there any possibility of this ?

You can have multiple qmgrs with the same name in the same cluster, but not recommended, as separating them (if this becomes necessary) might be messy. Internally, clustering software keeps track of qmgrs by the QMID, not the qmgr name.

yshakraj wrote:
Another question is - Is it really possible to get a remote QM to get added in a higher environment cluster -providing the firewall and all in place ?

Yes, you can have qmgrs at various VRMFs.

Quote:
Say will I be able to add a QM from Development environment to Prod Cluster ? using mqm as the MCA user ?

Yes, but you should assign lower privileged userids to MCAs.

Quote:
I tried doing telnet between these servers using QM port and seems to be no connection. Is there any other way I can assure that there is no connection between these two servers ?

I'd recommend CHLAUTH records to prevent unknown ipaddresses/qmgrs/channels from connecting.

Thanks in advance ,
yshakraj
_________________
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.


Last edited by bruce2359 on Sun Feb 23, 2020 7:46 am; edited 3 times in total
Back to top
View user's profile Send private message
bruce2359
PostPosted: Sat Feb 22, 2020 12:00 pm Post subject: Reply with quote

Poobah

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

Moved to Clustering forum.
_________________
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
View user's profile Send private message
fjb_saper
PostPosted: Sun Feb 23, 2020 11:52 am Post subject: Reply with quote

Grand High Poobah

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

Hi Bruce, 2 qmgrs with the same name in the cluster is a recipe for pandemonium. Especially if they both have the same cluster receiver channel name. At a minimum you should make sure that both qmgrs (with the same name) have a different cluster receiver channel name.
_________________
MQ & Broker admin
Back to top
View user's profile Send private message Send e-mail
bruce2359
PostPosted: Sun Feb 23, 2020 12:52 pm Post subject: Reply with quote

Poobah

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

fjb_saper wrote:
Hi Bruce, 2 qmgrs with the same name in the cluster is a recipe for pandemonium. Especially if they both have the same cluster receiver channel name. At a minimum you should make sure that both qmgrs (with the same name) have a different cluster receiver channel name.

Wholeheartedly, absolutely, and without reservation... though I'm not sure what pandas have to do with it.
_________________
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
View user's profile Send private message
Vitor
PostPosted: Mon Feb 24, 2020 5:38 am Post subject: Re: MQ Cluster Issue Reply with quote

Grand High Poobah

Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA

yshakraj wrote:
I faced an issue today with a cluster where a remote QM tried to join the cluster with same name of the QM - already existing in the cluster and cluster started behaving crazy . As per my understanding cluster will not allow duplicate QM name.


It will allow it. The cluster uses the QMID under the covers and these are unique, even to identically named queue managers. But as others have said, this is a very short road to you having to start a bamboo farm to keep all the pandas fed. If you're going to allow duplicate queue manager names in a cluster, then can I suggest large quantities of a psychotropic such as LSD as a quicker and more efficient way to get the same level of crazy?

yshakraj wrote:
Another question is - Is it really possible to get a remote QM to get added in a higher environment cluster -providing the firewall and all in place ?


Of course it's possible. How is an MQ cluster supposed to know which environment it's supporting and, by extension, which queue managers belong to which environment? There's nothing in the MQ configuration or metadata which talks about this.[/quote]

yshakraj wrote:
Say will I be able to add a QM from Development environment to Prod Cluster ? using mqm as the MCA user ?


Yes, you will. The queue managers don't record which environment they're in, the cluster doesn't know which environment it supports and the mqm user is the God Of All MQ and is assumed to know what they're doing. This is why using mqm as any MCA user is an idea of the same scale & family as allowing duplicate named queue managers in a cluster.

yshakraj wrote:
I tried doing telnet between these servers using QM port and seems to be no connection. Is there any other way I can assure that there is no connection between these two servers ?


Even if you could, there's no guarantee that next week / month / year someone won't fill out a form to get the firewall opened and connect a queue manager inappropriately. If you want to prevent a queue manager joining a cluster, you need to follow the advice laid out in the documentation, helpfully titled "Preventing queue managers from joining a cluster" to prevent lower level queue managers joining the production cluster.

And equally important, prevent production queue managers being joined to lower level ones and leaking data into unsecured areas.
_________________
Honesty is the best policy.
Insanity is the best defence.
Back to top
View user's profile Send private message
gbaddeley
PostPosted: Mon Feb 24, 2020 3:19 pm Post subject: Reply with quote

Jedi

Joined: 25 Mar 2003
Posts: 2492
Location: Melbourne, Australia

Best practice is to not have duplicate queue manager names anywhere in your accessible network, regardless of MQ Clusters.

Sometimes duplicate qmgrs may be set up for DR purposes, but they would only ever be started in a DR situation.

IBM should never have introduced the concept of QMID, and should have rigidly enforced that dup qmgr names are not allowed.
_________________
Glenn
Back to top
View user's profile Send private message
bruce2359
PostPosted: Mon Feb 24, 2020 4:39 pm Post subject: Reply with quote

Poobah

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

IBM should never ...

Anyone have a favorite one of those?
_________________
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
View user's profile Send private message
Vitor
PostPosted: Tue Feb 25, 2020 5:35 am Post subject: Reply with quote

Grand High Poobah

Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA

gbaddeley wrote:
Best practice is to not have duplicate queue manager names anywhere in your accessible network, regardless of MQ Clusters.




gbaddeley wrote:
Sometimes duplicate qmgrs may be set up for DR purposes, but they would only ever be started in a DR situation.


I explain these as being the "same" queue manager hosted in 2 different locations, and apply a context-appropriate sci-fi reference to explain the dangers of having the same queue manager operating twice at the same point in the space / time continuum.
_________________
Honesty is the best policy.
Insanity is the best defence.
Back to top
View user's profile Send private message
bruce2359
PostPosted: Tue Feb 25, 2020 6:27 am Post subject: Reply with quote

Poobah

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

A quick, but good, time-travel read: “The man who folded himself.”
_________________
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
View user's profile Send private message
yshakraj
PostPosted: Thu Feb 27, 2020 3:09 am Post subject: Reply with quote

Voyager

Joined: 14 Sep 2011
Posts: 90

Thanks you all - @bruce2359 ,@fjb_saper ,@Vitor ,@gbaddeley .

From this my understanding is only way to protect prod cluster foolproof is either of the below three options

-Using channel authentication records you can block the cluster channel connection based on: the remote IP address, the remote queue manager name, or the TLS Distinguished Name provided by the remote system.

-Write an exit program to prevent unauthorized queue managers from writing to SYSTEM.CLUSTER.COMMAND.QUEUE. Do not restrict access to SYSTEM.CLUSTER.COMMAND.QUEUE such that no queue manager can write to it, or you would prevent any queue manager from joining the cluster.

-A security exit program on the CLUSRCVR channel definition .



Thanks again ,
yshakraj

Thanks Again ,
yshakraj
Back to top
View user's profile Send private message
bruce2359
PostPosted: Thu Feb 27, 2020 5:37 am Post subject: Reply with quote

Poobah

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

yshakraj wrote:
Thanks you all - @bruce2359 ,@fjb_saper ,@Vitor

From this my understanding is only way to protect prod cluster foolproof is either of the below three options

The preferred and recommended method would be CHLAUTH records.

Exits are quite complicated - an advanced task.
_________________
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
View user's profile Send private message
Vitor
PostPosted: Thu Feb 27, 2020 8:57 am Post subject: Reply with quote

Grand High Poobah

Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA

bruce2359 wrote:
yshakraj wrote:
Thanks you all - @bruce2359 ,@fjb_saper ,@Vitor

From this my understanding is only way to protect prod cluster foolproof is either of the below three options

The preferred and recommended method would be CHLAUTH records.

Exits are quite complicated - an advanced task.


I'd use TLS, as you'll probably have encryption protecting the channels anyway.

But CHLAUTH is preferable to exits. Anything is preferable to exits. As my worthy associate points out, they're an advanced task and the pitfalls of an exit have been discussed many times in this forum.
_________________
Honesty is the best policy.
Insanity is the best defence.
Back to top
View user's profile Send private message
PeterPotkay
PostPosted: Thu Feb 27, 2020 11:07 am Post subject: Reply with quote

Poobah

Joined: 15 May 2001
Posts: 7717

And to complete the trifecta, I'll say use exits.

Exits, TLS or CHLAUTH records. They are all options to accomplish this. Weigh the pros and cons of each and choose the best one for you.

Quote:
Anything is preferable to exits.

If this was true, it it was really true, exits would not exist.

You use what is available to you, what you are familiar with. You shy away, perhaps running away screaming, from what is unfamiliar or what has given you trouble in the past.
_________________
Peter Potkay
Keep Calm and MQ On
Back to top
View user's profile Send private message
RogerLacroix
PostPosted: Thu Feb 27, 2020 12:53 pm Post subject: Reply with quote

Jedi Knight

Joined: 15 May 2001
Posts: 3252
Location: London, ON Canada

yshakraj wrote:
-A security exit program on the CLUSRCVR channel definition .

bruce2359 wrote:
Exits are quite complicated - an advanced task.

Vitor wrote:
But CHLAUTH is preferable to exits. Anything is preferable to exits. As my worthy associate points out, they're an advanced task and the pitfalls of an exit have been discussed many times in this forum.


Now I won't take offence to the "exits comments" given that I do agree they should only be coded by someone with strong programming skills and a solid understanding of MQ.

Note: Exits do allow for a lot more flexibility in what can be accomplished.

What does surprise me is that nobody seems to be aware of FREE "exit" solutions to the problem.

- MQ Channel Auto Creation Manager (MQCACM)
- MQ Channel Auto Creation Manager for z/OS (z/MQCACM)

Both MQCACM and z/MQCACM are "Licensed as Free" software. i.e. Like MQ Clients.

MQCACM and z/MQCACM are MQ Channel Auto-Definition exits that allows a company to control and restrict incoming connection requests to auto-create a channel.

They both support "Allow or Restrict the Incoming IP Address".
i.e.
Code:
UseAllowIP=Y
AllowIP=10.10.*.*;10.20.*.*


And there is also "Allow or Restrict the Incoming Naming Standard" which may be of interest.
i.e.
Code:

UseNamingStandard=Y
NamingStandard=TEST_???.CHL;ABC_*.CHL


Regards,
Roger Lacroix
Capitalware Inc.
_________________
Capitalware: Transforming tomorrow into today.
Connected to MQ!
Twitter
Back to top
View user's profile Send private message Visit poster's website
Display posts from previous:
Post new topicReply to topic Page 1 of 1

MQSeries.net Forum IndexClusteringMQ Cluster Issue
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.