| Author |
Message
|
| solomon_13000 |
 Posted: Fri Jul 18, 2008 2:28 am Post subject: Cluster - Partial and Complete Repository |
 |
|
Master
Joined: 13 Jun 2008
Posts: 284
|
In a cluster there is a full and partial repository.
From my understanding a partial repository only needs to know who are the full repository. Also the partial repository supplies information about itself to the full repository. It does not receive information about other queue managers in the cluster. Also there can be many partial repository that is linked to a full repository VIA a sender channel.
In regards to a full repository it only need to have a receiver channel. Also in any cluster there must exist atleast one full repository. But in situations where there are two full repository, a sender channel can exist whereby one full repositary can push information about itself to another repository.
Now how does the information in a full repository differ from a partial repository?. Suppose there are two full repository in a cluster, how does an application know which full repository to connect and get the information?. Can an application connect to a partial repository to get information from the full repository?. Also can an application connect to a full repository and get information from it?.
Regards. |
|
| Back to top |
|
 |
| Mr Butcher |
| Posted: Fri Jul 18, 2008 2:47 am Post subject: |
|
|
Padawan
Joined: 23 May 2005
Posts: 1716
|
| Quote: |
| From my understanding a partial repository only needs to know who are the full repository. |
yes....
| Quote: |
| Also the partial repository supplies information about itself to the full repository. |
yes
| Code: |
| It does not receive information about other queue managers in the cluster. |
not at the setup point of time, but - when an application openes a cluster queue that si hosted on a different queuemanager within the cluster, information about the queue and hosting queuemanager are received from the repository
| Quote: |
| Also there can be many partial repository that is linked to a single full repository VIA a sender channel. |
on the FR you define a cluster receiver channel, and on every PR you define a cluster receiver channel and a cluster sender channel to the FR
| Quote: |
| In regards to a full repository it only need to have a receiver channel. Also in any cluster there must exist atleast one full repository. But in situations where there are two full repository, a sender channel can exist whereby one full repositary can push information about itself to another repository. |
FRs should be fully connected, which means you manually define cluster senders from a FR to every other FR in the cluster, otherwise you will get problems.
| Quote: |
| Now how does the information in a full repository differ from a partial repository?. Suppose there are two full repository in a cluster, how does an application know which full repository to connect and get the information?. Can an application connect to a partial repository to get information from the full repository?. |
clsutering is almost transparent to the application. the application connects to its queuemanager, which is member of the cluster, and opens a queue. if that queue does not exist local then and the queuemanager is member of a cluster, then it checks with the FR if that queue is known (if it was not already known in the PR). if the queue exists in the cluster, information about the queue and the hosting queuemanager is given to the application queuemanager. the application queuemanager then creates a implicit defined cluster sender channel to the hosting queuemanager, and the messages can be transfered.
so for the application it is still "only" a mqopen, the mq cluster logic does all the stuff .
maybe (re-)read the queue manager clusters - manual....
_________________
Regards, Butcher |
|
| Back to top |
|
|
| solomon_13000 |
| Posted: Fri Jul 18, 2008 2:59 am Post subject: |
|
|
Master
Joined: 13 Jun 2008
Posts: 284
|
| If my understanding is correct, the Queue Manager defined in the cluster will always look in the partial repository first before looking in the full repository?. Or can it be in anyway?. |
|
| Back to top |
|
|
| exerk |
| Posted: Fri Jul 18, 2008 3:03 am Post subject: |
|
|
Jedi Council
Joined: 02 Nov 2006
Posts: 6339
|
Simple rule of thumb...
"Full Repositories know ALL about the cluster ALL the time; Partial Repositories know what they need to know, when they need to know it"
A PR knows which FR to get its information from because you tell it when you join the PR to the cluster, i.e. the CLUSSDR channel you define to the FR. The FR will publish the location of the other FR known to it, so should the 'initial' FR be unavailable the PR can query the 'alternative' FR.
Edit: Applications connect to a queue manager, and the application doesn't know (or shouldn't care) whether that queue manager is in a cluster, or not.
_________________
It's puzzling, I don't think I've ever seen anything quite like this before...and it's hard to soar like an eagle when you're surrounded by turkeys.
Last edited by exerk on Fri Jul 18, 2008 3:15 am; edited 1 time in total |
|
| Back to top |
|
|
| exerk |
| Posted: Fri Jul 18, 2008 3:14 am Post subject: |
|
|
Jedi Council
Joined: 02 Nov 2006
Posts: 6339
|
| solomon_13000 wrote: |
| If my understanding is correct, the Queue Manager defined in the cluster will always look in the partial repository first before looking in the full repository?. Or can it be in anyway?. |
The queue manager may be either a PR or FR itself!
When an application asks to open a queue:
1. The queue manager will check to see if it has an instance of the queue - if it does (and the queue is not in a cluster, and if it is no cluster workload balancing has been set) that instance will be used.
2. If the queue manager does not have an instance of the queue, it will query an FR for the location(s) of that queue, and then use one of the instances. It will then retain that information so it does not have to query an FR for the information again.
Note: if the queue manager the application connects to is an FR, it will know where to go immediately.
_________________
It's puzzling, I don't think I've ever seen anything quite like this before...and it's hard to soar like an eagle when you're surrounded by turkeys. |
|
| Back to top |
|
|
| solomon_13000 |
| Posted: Fri Jul 18, 2008 3:36 am Post subject: |
|
|
Master
Joined: 13 Jun 2008
Posts: 284
|
| Suppose the full repository is not connected to each other, what problems can we anticipate?. Also if the full repository is down, will the whole cluster be down?. |
|
| Back to top |
|
|
| exerk |
| Posted: Fri Jul 18, 2008 3:55 am Post subject: |
|
|
Jedi Council
Joined: 02 Nov 2006
Posts: 6339
|
| solomon_13000 wrote: |
| Suppose the full repository is not connected to each other, what problems can we anticipate?. Also if the full repository is down, will the whole cluster be down?. |
If the FRs are not connected to each other, the cluster has not been configured correctly...
If one FR is down, the other provides information to PRs when they request it...
If both FRs are down, then no updates can be received by PRs and any cluster queue instances they do not already know about will not be available to them...
This is all explained in the Clustering Manual 
_________________
It's puzzling, I don't think I've ever seen anything quite like this before...and it's hard to soar like an eagle when you're surrounded by turkeys. |
|
| Back to top |
|
|
| solomon_13000 |
| Posted: Fri Jul 18, 2008 4:02 am Post subject: |
|
|
Master
Joined: 13 Jun 2008
Posts: 284
|
So basically we have more than one FR for:
1. load balancing purpose
2. Higher availability purpose |
|
| Back to top |
|
|
| solomon_13000 |
| Posted: Fri Jul 18, 2008 4:47 am Post subject: |
|
|
Master
Joined: 13 Jun 2008
Posts: 284
|
| So the SYSTEM.CLUSTER.REPOSITORY.QUEUE holds information about the QM, channels and so on that MQ needs to know to manage the cluster? |
|
| Back to top |
|
|
| exerk |
| Posted: Fri Jul 18, 2008 4:55 am Post subject: |
|
|
Jedi Council
Joined: 02 Nov 2006
Posts: 6339
|
This is all explained in the Clustering Manual 
_________________
It's puzzling, I don't think I've ever seen anything quite like this before...and it's hard to soar like an eagle when you're surrounded by turkeys. |
|
| Back to top |
|
|
|
|
