| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
  |
|
| Shared transimmsion queue |
« View previous topic :: View next topic » |
| Author |
Message
|
| samsam007 |
 Posted: Thu Nov 06, 2008 10:11 pm Post subject: Shared transimmsion queue |
 |
|
Centurion
Joined: 30 Oct 2008
Posts: 107
|
Hi,
I want to know what is the purpose of using a shared transmission queue between two cluster QMGRs.
I actually want to setup a HA QMGR, and found this setup may be useful.
Thanks |
|
| Back to top |
|
 |
| Michael Dag |
| Posted: Fri Nov 07, 2008 1:10 am Post subject: |
|
|
Jedi Knight
Joined: 13 Jun 2002
Posts: 2607
Location: The Netherlands (Amsterdam)
|
What do you mean with shared transmission queue?
What platform are you talking about when it comes to HA?
_________________
Michael
MQSystems Facebook page |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Fri Nov 07, 2008 3:10 am Post subject: Re: Shared transimmsion queue |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
| samsam007 wrote: |
Hi,
I want to know what is the purpose of using a shared transmission queue between two cluster QMGRs.
I actually want to setup a HA QMGR, and found this setup may be useful.
Thanks |
HA is usually done with HARDWARE clustering.
HA has nothing to do with MQ clustering.
A qmgr can be HARDWARE (HA) clustered or not. It does not matter whether or not it is also part of an MQ cluster.
Enjoy 
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| Vitor |
| Posted: Fri Nov 07, 2008 3:32 am Post subject: Re: Shared transimmsion queue |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| samsam007 wrote: |
| I want to know what is the purpose of using a shared transmission queue between two cluster QMGRs. |
Do you mean SYSTEM.CLUSTER.TRANSMIT.QUEUE? While it's true it's used for all cluster messages in that queue manager it's not shared in the sense you mean.
| samsam007 wrote: |
| I actually want to setup a HA QMGR, and found this setup may be useful. |
No it's not even slightly useful. An MQ cluster is not the same as an HA cluster, it's just called the same thing. This is something that's been discussed on the forum a lot, is one of my favourite rants, and I don't plan to repeat it here.
If you want HA, use HA software or the backup queue manager facility.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Fri Nov 07, 2008 6:27 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9470
Location: US: west coast, almost. Otherwise, enroute.
|
Non-cluster MQ channels are point-to-point, with a single, non-shared, sending-side xmit queue. MQ cluster software uses the SCTC for cluster-sender channels, which are also point-to-point.
If your shop is z/OS parallel-sysplex (coupling facility), a shared xmit queue is implemented in the CF for communication among the members of the queue-sharing group.
_________________
I like deadlines. I like to wave as they pass by.
ב''ה
Lex Orandi, Lex Credendi, Lex Vivendi. As we Worship, So we Believe, So we Live. |
|
| Back to top |
|
|
| samsam007 |
| Posted: Fri Nov 07, 2008 11:18 pm Post subject: |
|
|
Centurion
Joined: 30 Oct 2008
Posts: 107
|
| Michael Dag wrote: |
What do you mean with shared transmission queue?
What platform are you talking about when it comes to HA? |
I just realised that Windows does not have so-called shared queue.
thanks |
|
| Back to top |
|
|
| samsam007 |
| Posted: Fri Nov 07, 2008 11:23 pm Post subject: Re: Shared transimmsion queue |
|
|
Centurion
Joined: 30 Oct 2008
Posts: 107
|
| Vitor wrote: |
| samsam007 wrote: |
| I want to know what is the purpose of using a shared transmission queue between two cluster QMGRs. |
Do you mean SYSTEM.CLUSTER.TRANSMIT.QUEUE? While it's true it's used for all cluster messages in that queue manager it's not shared in the sense you mean.
| samsam007 wrote: |
| I actually want to setup a HA QMGR, and found this setup may be useful. |
No it's not even slightly useful. An MQ cluster is not the same as an HA cluster, it's just called the same thing. This is something that's been discussed on the forum a lot, is one of my favourite rants, and I don't plan to repeat it here.
If you want HA, use HA software or the backup queue manager facility. |
so what will happen if the main Qmgr (the one with full repository and the one get initially connected by the client) died? will the secondary respository Qmgr act on behalf of the main Qmgr to handle the message in the Cluster queue that origionally belong to the main Qmgr?
Thanks |
|
| Back to top |
|
|
| samsam007 |
| Posted: Sat Nov 08, 2008 12:42 am Post subject: example |
|
|
Centurion
Joined: 30 Oct 2008
Posts: 107
|
Hi,
Here is an example I proposed for HA-CLUSTER:
[url]
http://www.ip6.com.au/WMQ-Design1.pdf
[/url]
The following shown the objects for QM.QMGR1:
QMGR1.ALIAS.RECEIVER.QUEUE
QMGR1.CLUS.RECEIVER.QUEUE
QMGR1.ALIAS.REPLY.QUEUE
QMGR1.CLUS.REPLY.QUEUE
CHANNEL.TO.QMGR1
CHANNEL.TO.QMGR2
CHANNEL.TO.BK1
QMGR1.XMITQ
QMGR1.ALIAS.PUB-QUEUE
QMGR1.XMIT-TO-STREAM.QUEUE
QMGR1.ALIAS.SUB-QUEUE
QMGR1.XMIT-TO-CONTROL.QUEUE
I am not really sure if my design to the above CLUS-HA is correct, and it seems there are quit alot objects need to be defined for QMGR1 shown as above.
Your help is greatly appreciated. |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Sat Nov 08, 2008 5:47 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9470
Location: US: west coast, almost. Otherwise, enroute.
|
| Quote: |
| so what will happen if the main Qmgr (the one with full repository and the one get initially connected by the client) died? will the secondary respository Qmgr act on behalf of the main Qmgr to handle the message in the Cluster queue that origionally belong to the main Qmgr? |
No. A clustered queue is not a shared queue; and the messages in a cluster queue are not visible to multiple qmgrs. Rather, a cluster queue is a queue (QLocal) that (usually) exists in several/many qmgrs. Cluster object definitions are kept in repositories (full or partial), and are available to all qmgrs in the cluster. At MQOPEN, the qmgr discovers the clusterq definition(s), picks the definition that meets the workload-balancing algorithm, creates the CLUSSDR channel to the selected qmgr, then sends the message to the qmgr with the localq.
Once the message is put to a local queue (clustered or not), the message exists on only one queue on only one qmgr. If that qmgr dies, the rules about persistence and NPMCLASS determine if the message survives, and can be subsequently processed.
The mainframe z/OS MQ implements shared-queues in a Coupling Facility. The CF contains architectured structures (not part of a filesystem or dataset) that contain the queue image. When a message arrives on a qmgr that is part of the queue-sharing group AND the queue definition identifies the queue as shared-queue, the message is logged (if persistent), then propogated into the CF for all qmgrs in the same gsg to see and consume. The z/OS implementation of shared-queues allows what you are looking for, namely: an application (or qmgr or o/s) failure does not mean loss of the message. Another instance can consume a message from the CF.
_________________
I like deadlines. I like to wave as they pass by.
ב''ה
Lex Orandi, Lex Credendi, Lex Vivendi. As we Worship, So we Believe, So we Live. |
|
| Back to top |
|
|
| samsam007 |
| Posted: Sat Nov 08, 2008 4:17 pm Post subject: |
|
|
Centurion
Joined: 30 Oct 2008
Posts: 107
|
| bruce2359 wrote: |
| Quote: |
| so what will happen if the main Qmgr (the one with full repository and the one get initially connected by the client) died? will the secondary respository Qmgr act on behalf of the main Qmgr to handle the message in the Cluster queue that origionally belong to the main Qmgr? |
No. A clustered queue is not a shared queue; and the messages in a cluster queue are not visible to multiple qmgrs. Rather, a cluster queue is a queue (QLocal) that (usually) exists in several/many qmgrs. Cluster object definitions are kept in repositories (full or partial), and are available to all qmgrs in the cluster. At MQOPEN, the qmgr discovers the clusterq definition(s), picks the definition that meets the workload-balancing algorithm, creates the CLUSSDR channel to the selected qmgr, then sends the message to the qmgr with the localq.
Once the message is put to a local queue (clustered or not), the message exists on only one queue on only one qmgr. If that qmgr dies, the rules about persistence and NPMCLASS determine if the message survives, and can be subsequently processed.
The mainframe z/OS MQ implements shared-queues in a Coupling Facility. The CF contains architectured structures (not part of a filesystem or dataset) that contain the queue image. When a message arrives on a qmgr that is part of the queue-sharing group AND the queue definition identifies the queue as shared-queue, the message is logged (if persistent), then propogated into the CF for all qmgrs in the same gsg to see and consume. The z/OS implementation of shared-queues allows what you are looking for, namely: an application (or qmgr or o/s) failure does not mean loss of the message. Another instance can consume a message from the CF. |
thank you for the explaination.
Is the secondary cluster qmgr also has a cluster q? So each cluster qmgr in a cluster should hold its own cluster q? In a cluster, 2 qmgrs usually assigned with 1 repository respectively, so there should be at least 2 cluster queues in a cluster?
Thanks |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Sat Nov 08, 2008 4:45 pm Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9470
Location: US: west coast, almost. Otherwise, enroute.
|
The number and location of clusterq's and qmgrs is up to your organization and application development requirements.
WMQ clusters offer workload balancing, and to a very small degree, high-availability.
NOTE: This has been discussed many, many times here. This is not hardware-o/s HA clustering; rather, this is WMQ clustering. Same word clustering; but different meanings.
Take, for example, a payroll application where employees run an application that creates a timecard message in order to get paid. The program that consumes the timecard message prints your paycheck.
If there is only one timecard queue, and the qmgr dies, no one can create a timecard, and no one gets paid. If many instances of the timecard queue exist, then any of them can be the destination for the timecard program; and any one of the paycheck programs can produce your paycheck.
In this example, the paycheck workload is spread among many qmgrs and clusterq's - workload-balancing. A small degree of high-availability arises due to the multiple clusterq's and paycheck programs.
_________________
I like deadlines. I like to wave as they pass by.
ב''ה
Lex Orandi, Lex Credendi, Lex Vivendi. As we Worship, So we Believe, So we Live. |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Sat Nov 08, 2008 7:23 pm Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
Bruce, in case of MQ cluster I'd rather use the terms limited failover capacity than small degree of HA. But then, that's just me... 
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Sat Nov 08, 2008 9:58 pm Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9470
Location: US: west coast, almost. Otherwise, enroute.
|
I absolutely agree with you.
I only mentioned it in the interest of clarity (?) to compare and contrast the multiple, overlapping, and divergent, meanings of clusters, HA, and failover.
_________________
I like deadlines. I like to wave as they pass by.
ב''ה
Lex Orandi, Lex Credendi, Lex Vivendi. As we Worship, So we Believe, So we Live. |
|
| Back to top |
|
|
| exerk |
| Posted: Mon Nov 10, 2008 1:07 am Post subject: |
|
|
Jedi Council
Joined: 02 Nov 2006
Posts: 6339
|
| samsam007 wrote: |
Is the secondary cluster qmgr also has a cluster q? So each cluster qmgr in a cluster should hold its own cluster q? In a cluster, 2 qmgrs usually assigned with 1 repository respectively, so there should be at least 2 cluster queues in a cluster?
Thanks |
There will be as many cluster queues as you define. A cluster queue is a queue within a queue manager, available for other queue managers within the cluster to send messages to.
Please do not confuse a user-application, administrator defined cluster queue instance with the various cluster-related SYSTEM queues.
_________________
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 |
|
|
|
|
|
| |
|
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
|
|
|
|
