| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
| Number of qmgrs per server |
« View previous topic :: View next topic » |
| How many qmgrs per server ? |
| 1 makes the job |
|
41% |
[ 5 ] |
| 1 main qmgr, and a second as failover (with qmgr alias) |
|
16% |
[ 2 ] |
| As much as you need |
|
41% |
[ 5 ] |
|
| Total Votes : 12 |
|
| Author |
Message
|
| exerk |
 Posted: Tue Mar 03, 2009 8:52 am Post subject: |
 |
|
Jedi Council
Joined: 02 Nov 2006
Posts: 6339
|
| sumit wrote: |
| exerk wrote: |
| Again: That will work fine...unless it's a server failure, so what do you do then? |
But the probalility of a server failure is very less as compared to a queue manager failure. Sometimes, clients want to use different queue managers on same server for their different applications. They quote them as 'critical applications'. With the justification that any problem with 1 qmgr should not effect performace of other application, one need to agree to configure multiple queue managers on same servers.
I agree with kevinf2349, it highly depends on business requirement. |
I also agree with kevinf2349, but as jhidalgo stated:
| Quote: |
| ...Let's say business requirements are minimize the "time to resolve"... |
A 'proper' fail-over solution presents itself as the only option in my opinion, which I'm sure will be challenged. Trying to configure a new queue manager on a server somewhere, and switch any connections to/from it, is hardly likely to fall into the "time to resolve" category.
The major issue for me is that whilst businesses tend to scream - very loudly - about the 'criticality' of their applications and underlying infrastructure, but when presented with the probable bill for achieving a minimum-downtime solution, they go very pale and refuse to pay for it. Sadly, business 'requirements' and reality rarely make good bed-fellows.
_________________
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 |
|
 |
| PeterPotkay |
| Posted: Thu Mar 12, 2009 6:29 pm Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
| jhidalgo wrote: |
| Let's say business requirements are minimize the "time to resolve". |
Use hardware clustering.
Or use z/OS so there isn't anything to resolve
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Thu Mar 12, 2009 6:35 pm Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
| sumit wrote: |
But the probalility of a server failure is very less as compared to a queue manager failure. |
I don't know about that. I've never had a QM fail.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| gbaddeley |
| Posted: Sun Mar 15, 2009 2:58 pm Post subject: |
|
|
Jedi Knight
Joined: 25 Mar 2003
Posts: 2538
Location: Melbourne, Australia
|
| PeterPotkay wrote: |
| sumit wrote: |
But the probalility of a server failure is very less as compared to a queue manager failure. |
I don't know about that. I've never had a QM fail. |
It's hard to predict what component will fail first or the likelihood of any individual component failing with any useful measurement. Its best to look at the overall risk of failure and weigh up the cost to the business of an unexpected outage against the cost of mitigating that by providing fail-over, redundancy, RAID, multiple network paths, synchronous replication, HA & DR capability. The list of possibilities goes on and on. A corporation might spending millions of $ a year to eliminate all single points of failure so they can never experience an outage. YMMV.
_________________
Glenn |
|
| Back to top |
|
|
|
|
|
|
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
|
|
|
|
