| Author |
Message
|
| scottL |
 Posted: Fri May 14, 2010 6:28 am Post subject: Cluster, Alias, Clone and clients ?? |
 |
|
Newbie
Joined: 14 May 2010
Posts: 8
|
I am hoping for some general clarity and some general guidance on this scenario. After reading many doc's I have a broad understanding but, am simply not clear yet.
Let's say I have a client. A cluster of three MQ servers, each with clones in durable. I was thinking that the client could reference the cluster via an alias - the goal is that if one MQ server in the cluster should fail the client would still be able to put/get messages without interuption or special coding logic, static ip's etc. The client solution is a remote WAS server.
1) I can't find any specific note of how an alias can reference a cluster and and not a specific server in the cluster.
2) In the above situation are all clone channels handled in like? ie. if a message is put all three cloned channels get the same as well as if read all three channels are marked accordingly so duplicates do not happen. ( When I read up on MDB's is seemed like you could define one TCF and check Cloned support and this would happen ).
3) Curious if an Exit Call was used would it it also act as if 3 cloned channels were 1? or be executed once per channel in cloned mode?
Thanks in advance ( sorry for being so newbie ) |
|
| Back to top |
|
 |
| PeterPotkay |
| Posted: Fri May 14, 2010 12:00 pm Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
Applications cannot connect to a cluster, they can connect to a Queue Manager. Using MQ Client Channel Tables is the preferred way of providing the MQ Client application a list of potential QMs to connect to.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| scottL |
| Posted: Fri May 14, 2010 12:59 pm Post subject: |
|
|
Newbie
Joined: 14 May 2010
Posts: 8
|
Thanks!
How about Cloning? If the channel is cloned across three QM's and I'm actually only reading from one ... Is it true they are all basically seem mirrored in actions?
tia! |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Fri May 14, 2010 9:04 pm Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
| scottL wrote: |
Thanks!
How about Cloning? If the channel is cloned across three QM's and I'm actually only reading from one ... Is it true they are all basically seem mirrored in actions?
tia! |
You seem to be suffering under some misconception here.
Clustering is used for load balancing
in Pub/Sub Clustering on Topics is used a little bit differently see V7 doc.
Cloning is part of the pub/sub vocabulary and has no meaning in clustering.
I would readily place mirroring in the same pub/sub category...
So unless you are way more clear in what you mean, we will not be able to advise you.
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| scottL |
| Posted: Mon May 17, 2010 5:46 am Post subject: |
|
|
Newbie
Joined: 14 May 2010
Posts: 8
|
Ok. I am sure that I am novice on this - so I'll try my best....
Here is the doc I am referencing to - I had been reading a v5 and v6 version or parts of; ftp://public.dhe.ibm.com/software/integration/wmq/docs/V7.0/amqnar12.pdf
Am I confused - yes a bit.
The gist is I am trying to understand if I have a situation where I want to have a a channel live on with the data on it available even if A QM goes down. I can get the concept of the application using a Client Channel Definition Table to find a live QM .... What would be the correct topology in verbage to this desired state?
The follow up question is then if the app reads from one instance will the other instances reflect this state so that no message is read more than once across any channel an application may be reading?
Most of the doc's elude to this ability but, are not specific on how or the exact details - I am hoping this just means a lack of the doc being maybe simpler or more forth right or they expect you to do trial and error to learn the exact details.
TIQ! |
|
| Back to top |
|
|
| mqjeff |
| Posted: Mon May 17, 2010 6:14 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
Applications read data from queues, not from channels. Channels connect applications to queue managers and queue managers to each other.
Queues do not share state across queue managers, except on zOS under shared queuing.
MQ Clustering allows messages to be delivered to queue managers in a load-balanced manner. It does not change anything about how messages are read. |
|
| Back to top |
|
|
| Vitor |
| Posted: Mon May 17, 2010 6:15 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| scottL wrote: |
| Am I confused - yes a bit. |
Ok, some points of clarification to remove confusion:
- Clients only ever connect to queue managers not to clusters. The clients neither knows nor cares if the queue manager in question is part of a cluster.
- Clusters are workload balancing engines. Messages enter, and are distributed to a selcted target. They're not copied, shared or in other ways made multiple.
| scottL wrote: |
| The gist is I am trying to understand if I have a situation where I want to have a a channel live on with the data on it available even if A QM goes down. I can get the concept of the application using a Client Channel Definition Table to find a live QM .... What would be the correct topology in verbage to this desired state? |
There is no topology for this. If a queue manager goes down the data on it's queues is inaccessable until it comes back. Either because the queue manager is restarted, a copy is started by some HA software or means various. You can use a CCDT to reconnect to a still running queue manager (and this is very useful for an application doing a put) but less so for doing a get. If the reconnected queue manager has relevent messages they'll be retireved but these won't be the messages on the downed queue manager.
| scottL wrote: |
| The follow up question is then if the app reads from one instance will the other instances reflect this state so that no message is read more than once across any channel an application may be reading? |
There's only ever 1 copy of a given message in a cluster. There may be many different subscriptions of a given publication (which I think is where you're going) but to WMQ these are separate messages. So if a subscriber loses connection to a queue manager it's a question of how it reestablishes either connection or subscription.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| scottL |
| Posted: Mon May 17, 2010 8:12 am Post subject: |
|
|
Newbie
Joined: 14 May 2010
Posts: 8
|
You guys are great. Now things are clearing up for me - thanks!
Curious .... Let's say there are 3 QM's, clustered and defined local instances of the same Que's defined per QM with full repositories. So the system is balacning which QM/Que gets the messsage based on it's algorithm. Let's say I only have one consumer that has subscribed .... Does it consume from only one QM/Que or does it get from all three Que's which would have unique messages? |
|
| Back to top |
|
|
| Vitor |
| Posted: Mon May 17, 2010 8:18 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| scottL wrote: |
| Does it consume from only one QM/Que or does it get from all three Que's which would have unique messages? |
You'd get one message delivered to the queue manager where the subscriber was connected. In this scenario load balancing doesn't apply as you're specifying a target queue as part of the subscription.
If you weren't using pub/sub but simply putting the message for an applicaiton to read, one of the queues (according to algorithm) would get the message and the application which happened to be reading messages from that queue would process it.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| scottL |
| Posted: Mon May 17, 2010 8:42 am Post subject: |
|
|
Newbie
Joined: 14 May 2010
Posts: 8
|
How might the idea work if I said subscribe to a topic instead of to a que? Would this idea be plausable then? ability to have one consumer recieve all messages from all Que's.
( ie. 3 QM's, same defined Que's per, one consumer )
( I think I'm getting closer to clarity  ) |
|
| Back to top |
|
|
| mqjeff |
| Posted: Mon May 17, 2010 8:44 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
You can easily set things up so that each queue will receive all messages.
That doesn't mean that when you get ONE message from ONE queue, that any other messages will be affected. |
|
| Back to top |
|
|
| Vitor |
| Posted: Mon May 17, 2010 8:47 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| scottL wrote: |
| How might the idea work if I said subscribe to a topic instead of to a que? Would this idea be plausable then? ability to have one consumer recieve all messages from all Que's. |
It wouldn't. Even if you subscribe to a topic, you're still specifying a queue where the subscription is to be delivered.
And even if you could get that to work (presumably by defining 3 durable subscriptions on all 3 queue managers or similar) the consumer is still only connected to a single queue manager so could only receive one of the messages.
And even if you could (by some fairly complex dancing) arrange for the same consumer to be simultaniously connected to all 3 queue managers what exactly would be the point? Aside from ensuring you'd always have a job untangling this when something went wrong? 
Seriously, this does sound like a solution looking for a problem. If this is the best way of meeting your requirement you should push back on the requirement.
#edit: you could of course have 3 copies of the same consumer attached to the 3 queue managers, all subscribing to the topic so the "same" consumer got all the messages.
My comments:
| Quote: |
| If this is the best way of meeting your requirement you should push back on the requirement. |
apply.
Perhaps if you gave us an insight on why you're going this way we could suggest alternatives?
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| scottL |
| Posted: Mon May 17, 2010 9:53 am Post subject: |
|
|
Newbie
Joined: 14 May 2010
Posts: 8
|
Well … what I am trying to conceptually put together in my head is;
A publisher puts messages on to the hub with a topic regardless of which QM it’s connected to.
A subscriber will consume based on this topic regardless of which QM they connected to.
I understand that Clients ( publishers or subscribers ) will have to be able to know of the other QM’s in the cluster in order to attach in case one QM goes down the others will be capable of continuing once the publishers and consumer reattach to the live QM's.
( This might be too much - Company A has a msg for what could be x of 100 destinations. These destinations need to grab the message and process. The destinations of course can send a message back to the original sender and also to other destinations. These are typically not exact real time bu in orders of minutes to days of back end processing before a destination might respond if at all. ) |
|
| Back to top |
|
|
| Vitor |
| Posted: Mon May 17, 2010 10:13 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| scottL wrote: |
A publisher puts messages on to the hub with a topic regardless of which QM it’s connected to.
A subscriber will consume based on this topic regardless of which QM they connected to. |
Sounds like you need retained publications that a reconnecting subscriber can request. Or some HA software.
| scottL wrote: |
| I understand that Clients ( publishers or subscribers ) will have to be able to know of the other QM’s in the cluster in order to attach in case one QM goes down the others will be capable of continuing once the publishers and consumer reattach to the live QM's. |
This is a bad idea and unnecessary. As long as everybody has a CCDT table to use they can simply connect or reconnect anonomously depending on availability.
| scottL wrote: |
| ( This might be too much - Company A has a msg for what could be x of 100 destinations. These destinations need to grab the message and process. The destinations of course can send a message back to the original sender and also to other destinations. These are typically not exact real time bu in orders of minutes to days of back end processing before a destination might respond if at all. ) |
It's not really too much and a good use of pub/sub. Certainly with 100s of destinations you probably want the queue managers (even if the targets are grouped) in a cluster to simplify the administration. As previously discussed, workload balancing with pub/sub is a bit irrelevant but clusters help with admin as well.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Mon May 17, 2010 2:20 pm Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
I guess what you are looking for is a design with no single point of failure.
Use a cluster alias as subscription qmgr and your publication becomes load balanced. That means that your application needs as many instances as qmgrs hosting the subscription queue in the cluster. It also most probably means that you will be reading the messages off the queue from a queue and not a topic.
Using a topic probably can be done but is much more trickier...
The nice part is that if one of the instances goes down you would still receive the messages on the others...
Now add to that a clustered subscription for a local subscription on multiple brokers and you get a system with no single point of failure...
Have fun 
_________________
MQ & Broker admin |
|
| Back to top |
|
|
|
|
