| Author |
Message
|
| Shalini |
 Posted: Thu Nov 25, 2004 4:53 am Post subject: "N" Overlapping Cluster with only two FR QMGR ???? |
 |
|
Master
Joined: 30 Apr 2002
Posts: 224
Location: India
|
Hi All,
| Quote: |
MQ 5.3 CSD5
Currently we have a hub and spoke kind of infrastructure.
i.e. the center two QM with full repo(Solaris MQ5.3 CSD5)
and other 51 QMGR as a partial repo (Win 2000 MQ5.3 CSD5) for our MQ Cluster
|
For such cases we have a particular requirements of placing the 3 QMGR in one cluster. So we need 17 Cluster with the 2 QMGR acting as Full Repo in the center.
I have a query If I create a Cluster say "Cluster1" with 3 Partial repo + center 2 FR QMGR
Can't I assign same 2 FR QMGR in the Center to hold other (16 cluster) FR info.
My Question is if a pair of QMGR becomes a FR for a "Cluster1" ,then can't it be the Hold FR for second .. third .. cluster full repo QMGR role.
Off course I have read about the overlapping cluster in the IBM PDF, but that overlap’s the two Clusters with two different pairs of Full Repo
But in our current set up we have only two FR QMGR in the center but other 51 PR QMGR joining the cluster.
Note: Why I mentioned as 3 in a cluster is, only 3 QMGR of PR should know about its queues (i.e. the image of Cluster queue will be only visible with the 3 should not be on other).
We cannot achieve this by having single MQ Cluster in such cases if a single PR QMGR holding a Cluster Queue the image will be visible in all 51 other PR QMGR
Please comment/suggest
 |
|
| Back to top |
|
 |
| PeterPotkay |
| Posted: Thu Nov 25, 2004 7:42 am Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7716
|
Your FRs can be FRs for multiple clusters. Research Namelists and Cluster Repository Namelists in the cluster manual.
Basically you make a Namelist that holds the names of all your clusters, and then set the FR QM's Repository Namelist attribute to this Namelist. You can add and remove clusters simply by adding and removing names in the Namelist.
You should have dedicated CLUSRCVRs on those FRs, one for each cluster. Use the naming convention TO.FRQM1.CLUSTER1, TO.FRQM1.CLUSTER2, TO.FRQM1.CLUSTER3, etc.
17 overlapping clusters?  There's gotta be a better design somewhere in there. Maybe not. I don't have all the info you do......
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| Nigelg |
| Posted: Fri Nov 26, 2004 1:32 am Post subject: |
|
|
Grand Master
Joined: 02 Aug 2004
Posts: 1046
|
I agree with Peter.
It would be much easier to write a cluster workload exit for each of the PRs to restrict the list of cluster qmgrs that a msg can be put to, rather than introduce the admin complexity of 17 overlapping clusters.
There is sample cluster workload exit source code, amqswlm0.c, which uses the qmgr attribute CLWLDATA to determine which qmgr to send the msg to. You could put into this attribute the list of qmgrs that are allowable destinations, and make a small change to the exit to choose one of those. |
|
| Back to top |
|
|
| Shalini |
| Posted: Fri Nov 26, 2004 4:30 am Post subject: |
|
|
Master
Joined: 30 Apr 2002
Posts: 224
Location: India
|
i Nigelg/PeterPotkay,
Thanks for suggestion.
As per the CLWL Exit is done we have already implemented the same logic in our Hub QMGR i.e. (we say it as inbound) message flow coming from our other EAI tools put to Hub and the Hub routes to PR thro the CLWLExit.
As per the outbound (from PR to FR) is concern we have 3 pair of different from same country.
So totally 17 different location (17*3) so the messages are put into the PR by other side residing in PR QMGR side goes to Hub.
i.e. for inbound (from FR to PR) we have cluster queue in all PR QMGR whose images are in Hub QMGR, so if the messages comes in the Hub QMGR its routed to PR QMGR by the exit depending on the PR QMGR availability and Channel availability.
But, we don’t use the QMGR level priority for the PR QMGR but the messages are distributed to PR (from FR QMGR) by the priority of the queue, this way we get load balancing by CLWL Exit (the way we modified).
That’s why I said that to have 17 Cluster and the hub would be responsible for all 17 clusters.
And as I said why 17 Cluster is that only the images between the 3 PR QMGR should be visible they should not get the image queue of another 16 different location.
Please Suggest/Commment
|
|
| Back to top |
|
|
| KeeferG |
| Posted: Fri Nov 26, 2004 5:07 am Post subject: |
|
|
Master
Joined: 15 Oct 2004
Posts: 215
Location: Basingstoke, UK
|
How many queues are to be on each PR.
Are you workload balancing across the PR. If not then just define remote queues.
If you are then how about setting authorities on the queues and make each app run as different user id.
17 clusters with 3 PR and two FR where FR's are same for all 17 clusters just doesnt feel right
_________________
Keith Guttridge
-----------------
Using MQ since 1995 |
|
| Back to top |
|
|
| Shalini |
| Posted: Fri Nov 26, 2004 6:50 am Post subject: |
|
|
Master
Joined: 30 Apr 2002
Posts: 224
Location: India
|
Hi All,
| Quote: |
How many queues are to be on each PR.
|
5 on each so 15 Queue on 3 PR.
So within 15, only 5 queue is selected within 3 PR QMGR depending on priority
If only one PR QMGR is available the msg goes to the available QMGR PR queue even some of its queue have low priority from Full PR.
| Quote: |
| Are you workload balancing across the PR. If not then just define remote queues. |
Yes we do a workload balancing between the QMGR queues so we don’t use Remote Queue
| Quote: |
| 17 clusters with 3 PR and two FR where FR's are same for all 17 clusters just doesnt feel right |
Even I don’t but our requirement is to run 51 PR QMGR in a pair of only 3 QMGR images should be visible in each other (ie one pair in 3 PR QMGR)
Other 16 Pair cluster images should not be known.
Hi PeterPotkay,
| Quote: |
Your FRs can be FRs for multiple clusters. Research Namelists and Cluster Repository Namelists in the cluster manual.
|
Please correct me if I am wrong
I don’t agree with you as, we have only 2 F.R hub QMGR (no more F.R QMGR).
It cannot become F.R for other Cluster even by use of namelist.
Because As I read from the Cluster PDF, we need to have other two more F.R QMGR for other cluster
But I don’t want other pair of F.R QMGR for other P.R QMGR I want the same pair of F.R QMGR for the new QMGR
Please suggest/comment
|
|
| Back to top |
|
|
| KeeferG |
| Posted: Fri Nov 26, 2004 7:12 am Post subject: |
|
|
Master
Joined: 15 Oct 2004
Posts: 215
Location: Basingstoke, UK
|
If you take a look at using Namelists for clusters you will see that you can have two queue managers that are the full repositories for 17 clusters. Each cluster would be made up of the 2 full repositories and 3 partial repositories as you requested.
The cluster manuals do explain how this can be achieved. Task 8 chapter 9.
This would give you a total of 51 partial repositories and two full repositories in all 17 clusters
_________________
Keith Guttridge
-----------------
Using MQ since 1995 |
|
| Back to top |
|
|
| Shalini |
| Posted: Fri Nov 26, 2004 7:51 am Post subject: |
|
|
Master
Joined: 30 Apr 2002
Posts: 224
Location: India
|
Hi KeeferG/ All,
Thankis for Reply.
After looking @ my reply can you comment on my design is it ...
II Design what I though was to have pair of 3 QMGR in the spoke as Full Repo so still 17 Cluster in the NT.
and the hub 2 QMGR joining in all 17 Cluster as P.R QMGR.(Solaris)
I donot even know if the reverse design also hold good.
But just wanted to center have QMGR with F.R so proceding with that after reading the Task 7 of Cluster doc I decided to F.R in center.
Please comment on both design any pros and cons ....
|
|
| Back to top |
|
|
|
|
