| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
  |
|
| The answer is two. Not one, not three, but TWO |
« View previous topic :: View next topic » |
| Author |
Message
|
| PeterPotkay |
 Posted: Wed Aug 14, 2013 5:20 am Post subject: The answer is two. Not one, not three, but TWO |
 |
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
|
| Back to top |
|
 |
| JosephGramig |
| Posted: Thu Aug 15, 2013 5:11 am Post subject: |
|
|
Grand Master
Joined: 09 Feb 2006
Posts: 1244
Location: Gold Coast of Florida, USA
|
|
| Back to top |
|
|
| bruce2359 |
| Posted: Thu Aug 15, 2013 5:34 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9469
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 |
|
|
| JosephGramig |
| Posted: Thu Aug 15, 2013 6:17 am Post subject: |
|
|
Grand Master
Joined: 09 Feb 2006
Posts: 1244
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 |
|
|
| bruce2359 |
| Posted: Thu Aug 15, 2013 7:22 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9469
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 |
|
|
| PeterPotkay |
| Posted: Thu Aug 15, 2013 8:35 am Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
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 |
|
|
| bruce2359 |
| Posted: Thu Aug 15, 2013 8:56 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9469
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 |
|
|
| fjb_saper |
| Posted: Thu Aug 15, 2013 1:04 pm Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
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 |
|
|
| Cressida |
| Posted: Thu Aug 15, 2013 11:24 pm Post subject: |
|
|
Disciple
Joined: 13 Jul 2007
Posts: 157
|
could not resist ...
what a gem of a thread .... |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Fri Aug 16, 2013 3:49 am Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
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 |
|
|
|
|
|
| |
|
Page 1 of 1 |
|
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
|
|
|
|
