| Author |
Message
|
| seanshih |
 Posted: Tue Jan 02, 2007 8:21 am Post subject: MQ cluster and queues |
 |
|
Newbie
Joined: 02 Jan 2007
Posts: 3
|
Hi,
Can any one answer this question?
I setup a cluster with 2 qmgr (qm1 and qm2).
I created a local clustered queue (LQ1) on qm1.
I can put messages to LQ1 while stopping qm1 but I cannot 'amqsget' from LQ1 on qm2. I got error (reason code 2085).
Do I have to create a same queue on qm2?
Sean |
|
| Back to top |
|
 |
| Vitor |
| Posted: Tue Jan 02, 2007 8:24 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
Yes, but it won't help. The message will on LQ1 on qm1 so you'll get a 2033 from qm2.
Trying to do failover? I ask because it's never possible to read from a non-local queue, and the most common reason people try is to use qm2 (in your example) as a failover for qm1.
You'll find a number of posts on the subject.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| seanshih |
| Posted: Tue Jan 02, 2007 9:14 am Post subject: |
|
|
Newbie
Joined: 02 Jan 2007
Posts: 3
|
Thanks for the answer!
Do you mean both qmanager (qm1 & qm2) must define a local queue (LQ1) in order to do 'faile-over' or 'load-balance' purpose?
Sean |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Tue Jan 02, 2007 9:23 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
You can't do failover with MQ clustering.
There are at least 100 separate threads here in this clustering forum that discuss why that is so. If you need more information, you need to go look for it.
You can't load balance only one queue. How would it be possible?
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Tue Jan 02, 2007 2:09 pm Post subject: |
|
|
Guest
|
MQ Clustering does a pretty good job of application hot-failover given: identical clustered local queue instances on each qmgr in the cluster; application can run on each qmgr in the cluster; a single message is a transaction; application opens the clustered queue with MQ00_BIND_NOT_FIXED; some other considerations.
z/OS Parallel Sysplex and mid-range HA implementations offer more hardware redundancy. |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Tue Jan 02, 2007 2:15 pm Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
MQ Clustering does no job of application hot-failover given that all messages on a downed queue manager, or already destined for a downed queue manager, are completely unavailable at any time before the queue manager is back up and running again.
"Some other considerations", indeed. If you can afford to lose some unknown number of messages for an unknown period of time and still count that as "failover" - I want to work to your requirements.
Mid-range HA implementations do a good job of application failover.
z/OS shared queues do even better.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Tue Jan 02, 2007 5:57 pm Post subject: |
|
|
Guest
|
We're on the hot-failover sliding-scale, but at different points on the scale. z/OS Parallel Sysplex with shared-queues is at the high-end; mq clustering in the middle; nothing at the low-end.
Risk of message loss, cost and complexity, are always in the business decision. A 'simple' payroll system might work fine without clustering; better with clustering; an overkill with z/OS shared-queues - unless you are paying millions of people - like Social Security.
It all depends. |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Tue Jan 02, 2007 6:37 pm Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
I agree that the cost of a particular solution needs to be a part of the decision process.
I agree that z/OS shared queues are very expensive, and are the top end of the scale.
MQ clustering is not in the middle when talking about failover.
This is like saying that two separate database instances provide failover, even though they never have the same data in them.
MQ Clustering does not provide any kind of failover solution, for any meaningful defintion of "failover".
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Tue Jan 02, 2007 8:06 pm Post subject: |
|
|
Guest
|
I suspect we agree much more than we disagree, Jeff.
Even at the high-cost high-end, there is always a risk of data loss. Add XRC or something, add redundant power, add redundant telecom... even then, there is a risk, however slight, of data loss. We offset the risk of data loss with more stuff; OR we recognize and live with the risk.
MQ's best feature is its once and once-only message delivery. Well architected applications manage situations where there are missing or duplicated transactions, messages, rows, tables. Better.
I once had a discussion with an executive who (somewhat sarcastically) asked me "can you guarantee that there will be absolutely no data loss?" What immediately came to mind was the traditional IT answer: yes, no, and it depends. My next thought was: "not that you will be willing to afford."
In the end, everything is a compromise between the triad of cost, time and quality. You (they) only get two of the three. Quality will take more time and cost. To reduce cost, you (they) must sacrifice time or quality. |
|
| Back to top |
|
|
| Vitor |
| Posted: Tue Jan 02, 2007 11:51 pm Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| bruce2359 wrote: |
We're on the hot-failover sliding-scale, but at different points on the scale. z/OS Parallel Sysplex with shared-queues is at the high-end; mq clustering in the middle; nothing at the low-end.
|
My 2 cents - MQ clustering is a work-balancing solution not a high availability solution. As jefflowrey says, there are innumerable threads discussing this. Even with a modestly priced HA solution you can eliminate (ok, reduce to 0.001%) the odds of data loss in a failure situation. MQ's once and once only delivery adds huge benefits to the application architecture and clustering adds benefits to scaleing. In a failover situation all clustering adds is the knowledge that most of your messages are being processed with 0-n stuck on the failed queue manager. It's the uncertainty of that 0-n that defeats it for most businesses and almost all auditors.
Note - when I talk about failure, I exclude disasters. The most expensive z/OS setup in the world (and z/OS is the peak of hardware/software reliability IMHO) will lose data if it's struck by plane / meteorite / tidal wave.
_________________
Honesty is the best policy.
Insanity is the best defence.
Last edited by Vitor on Thu Jan 04, 2007 12:04 am; edited 1 time in total |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Wed Jan 03, 2007 12:18 pm Post subject: |
|
|
Guest
|
Vitor says: "My 2 cents - MQ clustering is a work-balancing solution not a high availability solution"
Bruce responds: I agree.
Each IT shop is somewhere on the availability-scale. For some shops, for some applications (what management deems mission-critical), hot-failover may be a requirment; and management will fund whatever it takes.
For other shops, for other applications, the cost of hot-failover may exceed the value of (the risk of) lost data.
These are business (non-technical) decisions for management to weigh. Discussion items include: what is mission-critical? what's an outage? can we (they, the application, the business) tolerate an outage? what constitutes recovery from an outage? is delayed data, lost data? where is the tipping point where cost (of nearly-absolute prevention of data loss) exceeds value?
MQ can play a vital role in a total solution to a high-availability application; but will likely require much, much more, than just MQ. |
|
| Back to top |
|
|
|
|
