| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
  |
|
| Cluster Sender to a full repository queue manager |
« View previous topic :: View next topic » |
| Author |
Message
|
| venkat kurra |
 Posted: Sun Jun 04, 2006 11:02 am Post subject: Cluster Sender to a full repository queue manager |
 |
|
Master
Joined: 18 Oct 2001
Posts: 245
Location: Bloomington , IL
|
Hi,
I heard a different scenario of the cluster at my friend client place.
In general we use one cluster sender (pointing to any one of the full repository with in the cluster) and one cluster receiver channel.
but they are using two cluster senders pointing to full repos1 and full repos2.
For example QM1 and QM2 are the full repository queue managers and QM3 is a partial and want to join in the cluster.
QM3 has a cluster receiver(TO.QM3), cluster sender1 (TO.QM1) and cluster sender2 (TO.QM2).
I do not understand why we need two senders (which are in the same cluster)?
Any extra benifit of this?
_________________
Thanks,
Venkat Kurra
IBM Certified Specialist-MQSeries
IBM Websphere MQSeries Administrator
IBM WebSphere Message Broker System Admin |
|
| Back to top |
|
 |
| PeterPotkay |
| Posted: Sun Jun 04, 2006 1:39 pm Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
Hi Venkat,
From the Clustering Manual:
| Quote: |
| Using REFRESH CLUSTER(clustername) REPOS(YES) specifies that in addition to the default behavior, objects representing full repository cluster queue managers are also refreshed. This option may not be used if the queue manager is itself a full repository. If it is a full repository, you must first alter it so that it is not a full repository for the cluster in question. The full repository location will be recovered from the manually defined CLUSSDR definitions. After the refresh with REPOS(YES) has been issued the queue manager can be altered so that it is once again a full repository, if required. |
See how they said "The full repository location will be recovered from the manually defined CLUSSDR definitions." To me that kinda says if you have more than 1 cluster sender channel defined from the partial to the fulls, and you issue REFRSH CLUSTER REPOS (YES), the partial will try and reintroduce itself to the cluster via both FRs. This might be a benifit if FR1 is temporarily down when you issue the REFRESH with the REPOS(YES), or when you introduce the partial for the very first time.
The manually defined cluster sender channel is only ever used the very 1st time a partial joins a cluster, or when REPOS(YES) is used. Never otherise. So if you see these 2 scenarios happening while FR1 is N/A, then maybe, MAYBE(since its not clearly documented), having a manually defined CLUSSNDR to FR2 as well would help. At no other time are the manually defined CLUSSNDR channels used.
Personally, I would just have the one manual CLUSSNDR channel as the manuals tell you. Aim it at the FR that is available. If FR1 is N/A and you have to add a QM to the cluster or REFRESH CLUSTER REPOS(YES) at that exact moment, just make sure you have a single CLUSSNDR aimed at FR2.
Having 2 manually defined CLUSSNDRs is not needed in my opinion. Remember, as soon as a partial successfully joins the cluster, it will create Automatic Cluster Senders to *both* FRs, even though you only have 1 manually defined one.
P.S. I sent you a Private Message on another topic.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Sun Jun 04, 2006 5:46 pm Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
Thanks, Peter, for sharing this piece of extensive cluster knowledge. I'm still learning every day!! 
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| sieijish |
| Posted: Mon Jun 05, 2006 3:12 am Post subject: |
|
|
Acolyte
Joined: 29 Nov 2004
Posts: 67
Location: London
|
From the Cluster guide
| Quote: |
When a queue manager sends out information about itself or requests information about another queue manager, the information or request is sent to two full repositories.
|
Doesn't this imply the information is sent out to 2 repos QM directly from the non-repos QM?
Then the next line says
| Quote: |
A full repository named on a CLUSSDR definition handles the request whenever possible, but if the chosen full repository is not available another full repository is used.
|
So the question is does the non-repos QM always send the information directly to two repos QMs?
If it is only sent to the repos QM defined in the CLUSSDR, then the information is synchronized with all other repos QMs anyways, so why explicitly say that the information is always sent to 2 repos QMs? |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Mon Jun 05, 2006 4:29 am Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
QM1 = FR
QM2 = FR
QM3 = PR
Once QM3 joins the cluster via its manually defined CLUSSNDR to QM1, QM1 immediatly sends QM3 info about all other FRs in the cluster, and QM3 creates automatic CLUSSNDRs to all of the FRs.
Whenever a change is made on QM3, it sends an identical update message directly to all FRs.
The primary / first FR for QM3 is QM1, as such QM1 will also send out this new QM3 info itself to all other FRs in the cluster. This means the QM2 would have 2 update messages about the change on QM3, one message from QM3, and one messages from QM1. Sequence #s are examined and duplicates are discared, allowing the FRs to remain in sync. This way all FRs in a cluster know everything, even if a PR can't get to one of the FRs directly at a given moment.
The important thing is that at introduction to the cluster, or upon REFRSH CLUSTERE REPOS (YES), which is basically a reintroduction to the cluster, the one manually defined cluster sender channel points to a FR that is available at that moment. After that, the power of MQ clustering takes over and things just work, even if a PR can't get to one of the FRs temporarily.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| Nigelg |
| Posted: Mon Jun 05, 2006 5:21 am Post subject: |
|
|
Grand Master
Joined: 02 Aug 2004
Posts: 1046
|
Each PR only sends directly to a maximum of two FRs in a cluster, so having more than two FRs does not gain anyhting.
_________________
MQSeries.net helps those who help themselves.. |
|
| Back to top |
|
|
| sieijish |
| Posted: Mon Jun 05, 2006 6:24 am Post subject: |
|
|
Acolyte
Joined: 29 Nov 2004
Posts: 67
Location: London
|
More than 2 FR might be relevant due to geographical reasons.
Peter, according to the second quote, the CLUSSDR definition is checked by the PR to decide which two FRs out of many avaliable ones to use. And according to the first quote the information they are talking about is not about joining the cluster or issue REFRESH command.
So may be by defining two CLUSSDR channels in a cluster with more than 2 FPs, an administrator can control which two FRs a given PR will use for cluster information |
|
| Back to top |
|
|
| venkat kurra |
| Posted: Mon Jun 05, 2006 8:06 am Post subject: |
|
|
Master
Joined: 18 Oct 2001
Posts: 245
Location: Bloomington , IL
|
Thanks for the resonce.
Special thanks to Peter .
_________________
Thanks,
Venkat Kurra
IBM Certified Specialist-MQSeries
IBM Websphere MQSeries Administrator
IBM WebSphere Message Broker System Admin |
|
| 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
|
|
|
|
