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 » The answer is two. Not one, not three, but TWO

Post new topic  Reply to topic
 The answer is two. Not one, not three, but TWO « View previous topic :: View next topic » 
Author Message
PeterPotkay
PostPosted: Wed Aug 14, 2013 5:20 am    Post subject: The answer is two. Not one, not three, but TWO Reply with quote

Poobah

Joined: 15 May 2001
Posts: 7717

Quote:
Ever seen the advice for ‘Best Practice’ in a WMQ cluster to only have two Full Repositories and wondered why? This post is for you.


https://www.ibm.com/developerworks/community/blogs/messaging/entry/wmq_clusters_why_only_two_full_repositories?lang=en
_________________
Peter Potkay
Keep Calm and MQ On
Back to top
View user's profile Send private message
JosephGramig
PostPosted: Thu Aug 15, 2013 5:11 am    Post subject: Reply with quote

Grand Master

Joined: 09 Feb 2006
Posts: 1230
Location: Gold Coast of Florida, USA

That article left out this important tid bit at this link:
http://pic.dhe.ibm.com/infocenter/wmqv7/v7r5/topic/com.ibm.mq.con.doc/q017270_.htm

"The full repositories republish the publications they receive through the manually defined CLUSSDR channels, which must point to other full repositories in the cluster."

If you don't do this, the FRs will become "fragmented".
Back to top
View user's profile Send private message AIM Address
bruce2359
PostPosted: Thu Aug 15, 2013 5:34 am    Post subject: Reply with quote

Poobah

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

http://pic.dhe.ibm.com/infocenter/wmqv7/v7r5/topic/com.ibm.mq.con.doc/q017270_.htm
adds more confusion (less clarity) with:
Quote:
In each cluster you must select at least one, preferably two, or more queue managers to hold full repositories.

and
Quote:
A cluster queue manager sends out information about itself or requests information about another queue manager. When it does so, the information or request is sent to two full repositories.

and
Quote:
Having only two full repositories is sufficient for all but exceptional circumstances

Full repositories must have cluster sender channels to all other full repositories in the cluster. If one of the full repository queue managers is unavailable, the remaining full repositories are able to continue to reach one another.


So, which is it? Two, and only two FRs? Will a 3rd or 4th be used by clustering software? Or ignored?

If four FRs are defined, which will be used as FRs? The first two? Which will be used, if any, if the first two fail?
_________________
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
JosephGramig
PostPosted: Thu Aug 15, 2013 6:17 am    Post subject: Reply with quote

Grand Master

Joined: 09 Feb 2006
Posts: 1230
Location: Gold Coast of Florida, USA

I'm not going to comment on the quality of the documentation because I'm sure I would not do the job as well as they have done it.

The most important thing to do when defining your cluster, is to create explicit cluster sender channels to each and every other FR in the cluster. Most people can get this right with only two FRs. Amazingly, as the number of FRs increases, it becomes exponentially less likely they get this right. An FR that gets a forwarded update will not forward that update again (I'm pretty sure because, "Where would it stop?").

So survey your cluster to find all FRs (and you just might have to query every Qmgr to be 100% sure you know the state), and look at them to determine if they meet the requirement I'm pointing out. If they don't, you have a cluster (hmmm) mess up (yes, that's the word I'm thinking of...).

What is the fix?

Define the required number of explicit CLUSSDR channels. Demote all but one FR to PRs. One at a time, refresh cluster(bla) repos(yes) and promote it back to being an FR. Then issue the refresh cluster(bla) repos(yes) at each and every PR one at a time. Only then will you be confident in the repository population.

So back to using z/OS Qmgrs in the sysplex, this rule is why I would be reluctant to select them puppies. If you do, you must ensure you have met this rule. Also, there are legitimate reasons to suspend Qmgrs from clusters for application reasons but you don't really want to suspend FRs. If you think you need to issue a refresh cluster(bla) at an FR, you can be confident you have a "cluster mess up".

Do the needful! Keep It Simple Smoochy.
Back to top
View user's profile Send private message AIM Address
bruce2359
PostPosted: Thu Aug 15, 2013 7:22 am    Post subject: Reply with quote

Poobah

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

JosephGramig wrote:

So back to using z/OS Qmgrs in the sysplex, this rule is why I would be reluctant to select them puppies. If you do, you must ensure you have met this rule.

What is it about them (z/OS) puppies as FRs that you don't like? What is different about WMQ clusters in z/OS vs. midrange clusters?

I ask because I've created z/OS WMQ clusters, with the usual admin tasks, with little/no difference in the results.
_________________
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
PeterPotkay
PostPosted: Thu Aug 15, 2013 8:35 am    Post subject: Reply with quote

Poobah

Joined: 15 May 2001
Posts: 7717

The way it was explained to me at a Clustering session at an Impact many moons ago was:

A Partial Repository will only publish to and subscribe from TWO Full Repositories, even if there are more than two Full Repositories in the cluster.

So if you had 3 FRs, and your PR was talking to FR1 and FR2, and you take FR1 and FR2 down, you are lulled into a false sense of security when you say to yourself "FR3 is still up so my cluster is 100% functional and will continue to recognize any and all cluster changes across any and all partial repositories." Not true! You are better off only having 2 FRs, and being fully aware of what happens when both are N/A, and then NOT allowing both to be N/A.

Adding additional FRs is only going to add complexity and open up gaps for unexpected problems when you make assumptions on how the cluster operates with > 2 FRs. More is not better.

There are rare cases where > 2 FRs makes sense and in those cases you really need to understand how the cluster reacts when 2 or more of the FRs in that type of setup are N/A.
_________________
Peter Potkay
Keep Calm and MQ On
Back to top
View user's profile Send private message
bruce2359
PostPosted: Thu Aug 15, 2013 8:56 am    Post subject: Reply with quote

Poobah

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

The way it was explained to me: my PR connects to one, and only one, FR. That FR publishes my PR info to one, and only one, FR.
_________________
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: Thu Aug 15, 2013 1:04 pm    Post subject: Reply with quote

Grand High Poobah

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

bruce2359 wrote:
The way it was explained to me: my PR connects to one, and only one, FR. That FR publishes my PR info to one, and only one, FR.
True in a 2 FR scenario.
When running with more than 2 FR's (reason: geographic diversity) you have to make sure that:
  • each FR has a manually defined Cluster Sender to EVERY other FR
    So with n (n >=2 ) FRs you have N-1 cluster senders per FR.
  • Make sure that if a non "primary" FR is down it affects a minimal portion of the network.
    This means that if any of the PRs has this qmgr as a secondary FR it is in danger of running without a fully formed cluster

    Have fun :innnocent:

_________________
MQ & Broker admin
Back to top
View user's profile Send private message Send e-mail
Cressida
PostPosted: Thu Aug 15, 2013 11:24 pm    Post subject: Reply with quote

Disciple

Joined: 13 Jul 2007
Posts: 152

could not resist ...

what a gem of a thread ....
Back to top
View user's profile Send private message
PeterPotkay
PostPosted: Fri Aug 16, 2013 3:49 am    Post subject: Reply with quote

Poobah

Joined: 15 May 2001
Posts: 7717

http://www.mqug.org.uk/downloads/201006/WMQClusterBestPractices.pdf

Quote:
The thing to bear in mind when using more than 2 Full Repositories is that queue managers
within the cluster still only publish and subscribe to 2. This means that if the 2 Full Repositories
to which a queue manager subscribed for a queue are both off-line, then that queue manager
will not find out about administrative changes to the queue, even if there are other Full
Repositories available.

_________________
Peter Potkay
Keep Calm and MQ On
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 » The answer is two. Not one, not three, but TWO
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.