Author |
Message
|
sarbajit |
Posted: Mon Jul 28, 2003 10:54 am Post subject: Cluster Channels in MQ Clustering |
|
|
Acolyte
Joined: 22 May 2003 Posts: 53
|
Hi all,
I got little confused. Please help me out. I have a clustering with three Queue Managers QM0, QM1 and QM2. QM0 is the gateway queue Manager as . All the messges should come to this Queue Manager from External Interfaces and get distributed into QM1 and QM2 in round robin fashion. Also the External interfaces will connect to QM0 to get the messaged (local queue). Now, my question is what clustering channels (sender and Receiver) should be used for this type of clustering in all the three queue Managers. Also which one should be the full or partial repository queue managers. I am using Solaris MQ version5.3.
Thanks |
|
Back to top |
|
 |
mqonnet |
Posted: Mon Jul 28, 2003 11:33 am Post subject: |
|
|
 Grand Master
Joined: 18 Feb 2002 Posts: 1114 Location: Boston, Ma, Usa.
|
There are not "many" types of channels in clustering. Only clussdr and clusrcvr, and thats is what you need to use.
As for what qmgr should be full repos, its a design choice and requirement. But generally speaking in your case, QM0 should be full repos and either QM1 or QM2 could also be a full repos, or they both could be partial repos qms.
Cheers
Kumar |
|
Back to top |
|
 |
sarbajit |
Posted: Mon Jul 28, 2003 12:04 pm Post subject: |
|
|
Acolyte
Joined: 22 May 2003 Posts: 53
|
Thanks. What I wanted to know that the number of cluster sender and receiver channels for all the three cases.
Like as an example:
In case of QM0 : receviver cluster channel (TO_QM0)
sender cluster channel (TO_QM1)
sender cluster channel (TO_QM2)
QM1 = receviver cluster channel (TO_QM1)
sender cluster channel (TO_QM0)
QM2 = receviver cluster channel (TO_QM2)
sender cluster channel (TO_QM0) |
|
Back to top |
|
 |
mqonnet |
Posted: Mon Jul 28, 2003 12:30 pm Post subject: |
|
|
 Grand Master
Joined: 18 Feb 2002 Posts: 1114 Location: Boston, Ma, Usa.
|
I see only one case here and which is clearly explained in the cluster manual.
http://publibfp.boulder.ibm.com/epubs/html/csqzah06/csqzah06tfrm.htm
Take a look at Chapter 3, task 1 and task 2a.
Thumb rule is, You only need 1clusrcvr defined per full repos, and 1clusrcvr and 1clussdr per partial repos qm. The other clussdr on full repos qm is created on demand as and when needed automatically.
Cheers
Kumar |
|
Back to top |
|
 |
EddieA |
Posted: Tue Jul 29, 2003 7:02 am Post subject: |
|
|
 Jedi
Joined: 28 Jun 2001 Posts: 2453 Location: Los Angeles
|
It is required that ALL channels connecting full repositories HAVE to be manually defined.
Quote: |
The CLUSSDR definitions made on the full repository queue managers are special. All the updates exchanged by the full repositories flow exclusively on these channels. The administrator controls the network of full repositories explicitly. The administrator must make the CLUSSDR definitions on full repository queue managers manually and not leave them to be auto-defined. |
Also, if you have more that 2 full repositories, then each full repository MUST be connected, via manually defined channels, to ALL other full repositories.
Cheers, _________________ Eddie Atherton
IBM Certified Solution Developer - WebSphere Message Broker V6.1
IBM Certified Solution Developer - WebSphere Message Broker V7.0 |
|
Back to top |
|
 |
mqonnet |
Posted: Tue Jul 29, 2003 8:16 am Post subject: |
|
|
 Grand Master
Joined: 18 Feb 2002 Posts: 1114 Location: Boston, Ma, Usa.
|
Eddie,
I have used Clustering for over 4 years now without any issues when the Clussdr channels on full repos qms autodefined. In fact thats how i do it all the time. I dont see any reasons why that is wrong. Neither do the docs explictly say that this is wrong. The doc just mentions that it is better to define Clussdr on full repos qms manually but doesnt mandate it. Otherwise you wouldnt have autodef clussdr channels at all.
The only instance where i think this becomes mandatory and is advisible is when you have volatile IP addresses and keep changing every now and then. At that time, the administration of clussdr channels becomes easier if you have them manually defined.
Moreover my scenario as explained in the previous post was 1 Full repos and 2 partial repos.
Cheers
Kumar |
|
Back to top |
|
 |
PeterPotkay |
Posted: Tue Jul 29, 2003 8:46 am Post subject: |
|
|
 Poobah
Joined: 15 May 2001 Posts: 7722
|
Kumar, I think I am with Eddie on this one.
If you have more than one full repository, and you should have 2 (and sometimes more), then each of the full repositries must have a manually defined CLUSSNDR to the other full repository(s).
It does explicitly say that in the quote Eddies posted:
Quote: |
The administrator must make the CLUSSDR definitions on full repository queue managers manually and not leave them to be auto-defined.
|
Imagine a cluster with only 2 QMs, and both of them full repositories. If you did not define the manual CLUSSNDRS, the 2 QMs would just sit there forever, not communicating. How would one know about the other unless you did tell it how to get to the other one?
If you have some partial repository QMs in the mix, then in a roundabout way via the manually defined CLUSSNDRs from the partial repositries, the full repositories would find out about each other. I don't know if I would rely on this though, I feel safer doing what the manual says (see quote above). _________________ Peter Potkay
Keep Calm and MQ On |
|
Back to top |
|
 |
mqonnet |
Posted: Tue Jul 29, 2003 8:52 am Post subject: |
|
|
 Grand Master
Joined: 18 Feb 2002 Posts: 1114 Location: Boston, Ma, Usa.
|
Peter, i agree with you and eddie if the scenario was with more than 1 full repos and i know that.
But as i mentioned in all of my posts earlier, i still stick with it..
"Moreover my scenario as explained in the previous post was 1 Full repos and 2 partial repos."
Cheers
Kumar |
|
Back to top |
|
 |
PeterPotkay |
Posted: Tue Jul 29, 2003 8:55 am Post subject: |
|
|
 Poobah
Joined: 15 May 2001 Posts: 7722
|
Aha, I missed that.
I guess my question for you now is, why with 3 Queue Managers would you not want 2 of them to be full repositories as recomended by IBM? _________________ Peter Potkay
Keep Calm and MQ On |
|
Back to top |
|
 |
mqonnet |
Posted: Tue Jul 29, 2003 10:28 am Post subject: |
|
|
 Grand Master
Joined: 18 Feb 2002 Posts: 1114 Location: Boston, Ma, Usa.
|
Ok gentlemen, let me clarify my stance. I have not been explicit about my previous posts.
If you have full repos qms, 2 or more, you should explicitly create clussdr/rcvr defs as recommended by IBM and as posted earlier by Peter. If you have non-repos qms or partial repos qms so to say, connect to any of the full repos, you Only need clussdr and rcvr defs on non-repos qm and rcvr def on full-repos qm. The clussdr from the full repos to any non-repos qms would be autodefined as and when needed. And this happens when you define the clussdr on non-repos qm and its up and running. The full repos comes to know that there is a new partial-repos qm connected to it and hence it needs to create a clussdr to it, if not already created. And then send the updated repos info to the non-repos qm.
Guess i have not been as explicit as here and i apologize if it caused any confusion here. :)
Cheers
Kumar |
|
Back to top |
|
 |
EddieA |
Posted: Tue Jul 29, 2003 11:47 am Post subject: |
|
|
 Jedi
Joined: 28 Jun 2001 Posts: 2453 Location: Los Angeles
|
Kumar,
Yes, I think this was more a case of confusion all round. We all seem to be saying essentially the same thing.
The point that I mis-read was the same, I think, as Peter:
Quote: |
The other clussdr on full repos qm is created on demand as and when needed automatically.
|
I think both of us assumed you were talking about a connection to another full repository, not a partial.
Sorry.  _________________ Eddie Atherton
IBM Certified Solution Developer - WebSphere Message Broker V6.1
IBM Certified Solution Developer - WebSphere Message Broker V7.0 |
|
Back to top |
|
 |
jefflowrey |
Posted: Tue Jul 29, 2003 11:54 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002 Posts: 19981
|
Another thing to keep in mind is that there's almost never any good reason for having more than two full repositories for any single cluster. |
|
Back to top |
|
 |
|