| Author |
Message
|
| KeeferG |
 Posted: Thu Feb 21, 2008 6:07 am Post subject: SOLVED:clustered remote clustered queues |
 |
|
Master
Joined: 15 Oct 2004
Posts: 215
Location: Basingstoke, UK
|
Appologies for the strange title but there you go.
I am having some fun setting up a cluster
I have three tiers of queue managers
Loading queue managers. QML1 and QML2
Intermediate queue managers. QMI1, QMI2, QMI3 and QMI4
Target queue managers. QMT1 and QMT2.
QMT1 and QMT2 both have an instance of queue Q1.
QMI1, QMI2, QMI3 and QMI4 have and instance of queue Q2 which route to Q1.
Applications connect to QML1 and QML2 and put messages to Q2. This balances load across the 4 QMI queue managers to route to one of the Q1 queues.
Now I get this working fine using remote queues for Q2 pointing to a single Q1 specifying RNAME(Q1) and RQMNAME(QMT1).
Of course I actually want to route to either instance of Q1 on QMT1 and QMT2. Leaving the RQMNAME blank on the Q2 definition causes an error.
Using an alias queue instead of remote and specifying TARGQ(Q1) to put to the cluster Q1 ON THE QMI1, QMI2, QMI3 and QMI4 queue managers does not work either which is puzzling me as this method is mentioned in the overlapping cluster scenario in the documentation.
Any thoughts.
_________________
Keith Guttridge
-----------------
Using MQ since 1995
Last edited by KeeferG on Thu Feb 21, 2008 8:03 am; edited 2 times in total |
|
| Back to top |
|
 |
| Vitor |
| Posted: Thu Feb 21, 2008 6:16 am Post subject: Re: clustered remote clustered queues |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| KeeferG wrote: |
| Any thoughts. |
What do the intermediate queue managers add to this topology, except confusion? What is the requirement which prevents QML1 & QML2 routing direct to QMT1 & QMT2 (in a load balanced way)?
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Thu Feb 21, 2008 6:43 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
You don't say how you've clustered these.
Is there one cluster? Two? Three?
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| KeeferG |
| Posted: Thu Feb 21, 2008 7:07 am Post subject: |
|
|
Master
Joined: 15 Oct 2004
Posts: 215
Location: Basingstoke, UK
|
The intermediate queue managers are there as a seperation layer.
This is a reasonably high volume system (20,000 messages per second at peak volumes). Messages must never be allowed to build on the SYSTEM.CLUSTER.TRANSMIT.QUEUE on the loading QMGRS due to them being in multiple clusters.
The loading layer contains 20+ queue managers.
The intermediate layer can contain as many queue managers as required.
The target layer is only two queue managers running.
In most scenarios load can be handled by either of the target layer queue managers however in periods of high volume and failure modes then messages must build up in the middle layer and not the loading layer.
_________________
Keith Guttridge
-----------------
Using MQ since 1995 |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Thu Feb 21, 2008 7:51 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
Where are the cluster boundaries?
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| KeeferG |
| Posted: Thu Feb 21, 2008 7:54 am Post subject: |
|
|
Master
Joined: 15 Oct 2004
Posts: 215
Location: Basingstoke, UK
|
Hi the cluster boundries are on the loading layer.
Problem now solved though.
Forgot the DEFBIND(NOTFIXED) in my cluster queue definitions.
Now added to both Q1 and Q2 defintions and all is working.
_________________
Keith Guttridge
-----------------
Using MQ since 1995 |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Thu Feb 21, 2008 10:49 am Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
Interesting topology. How long has it been working in PROD like this? No problems?
| Quote: |
| Messages must never be allowed to build on the SYSTEM.CLUSTER.TRANSMIT.QUEUE on the loading QMGRS due to them being in multiple clusters. |
You are aware that messages piling up in the S.C.T.Q. for QMA in ClusterA doesn't mean that messages bound for other QMs or even for QMA in other clusters will necessarily be impeded. Each destination will have its own cluster sender channel pulling from the common S.C.T.Q. But I suppose if one route does really pile up then the other channels' selective MQGETs from the S.C.T.Q. will get a slower as they have to look thru a very deep queue.
Wouldn't it be simpler to provide the seperation at the loading layer by adding more QMs and scaling horizontally?
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| KeeferG |
| Posted: Fri Feb 22, 2008 1:16 am Post subject: |
|
|
Master
Joined: 15 Oct 2004
Posts: 215
Location: Basingstoke, UK
|
I am aware that is causes no problems however we have a very critical cluster that uses MQ in a way that I would not describe as best practice.
The loading cluster refered to is designed to handle over 300 million messages a day across 20 queue managers so any build up on XMITQ's happen quickly. This has been working for a number of years and will not change.
The new cluster(s) I am trying to configure are just taking the feeds from the original cluster. As a result we need to make sure that it does not cause any impact to the existing cluster and whilst messages building on the XMITQ is not necessarily bad, it would mean a complete change to the monitoring of the current cluster and its behaviour which is not acceptable.
This is one reason why I have raised the requirement with IBM to be able to define seperate XMITQs for different clusters as that would at least allay the fears of the people monitoring that there is no impact to the main cluster.
But as this is not being done then I must come up with other ways to ensure we never have a build up on our XMITQs.
The joys of live systems.
_________________
Keith Guttridge
-----------------
Using MQ since 1995 |
|
| Back to top |
|
|
|
|
