| Author |
Message
|
| Monk |
 Posted: Tue May 12, 2009 12:50 am Post subject: Your experience with MQ clustering. |
 |
|
Master
Joined: 21 Apr 2007
Posts: 282
|
Hi All,
Can the experienced people in Clustering tell me what are the things i should be aware of when i am designing and implementing clusters?
The IBM doc is ok. but what has been your personal experience with MQ Clustering.
Please feel free to share. 
_________________
Thimk |
|
| Back to top |
|
 |
| Vitor |
| Posted: Tue May 12, 2009 1:07 am Post subject: Re: Your experience with MQ clustering. |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| Monk wrote: |
what are the things i should be aware of when i am designing and implementing clusters?
|
- Follow the documented procedures closely. The majority of cluster problems come from taking shortcuts - for instance, removing an accidently added queue manager from the cluster by deleting it's channels and issuing a RESET CLUSTER.
- Do not issue RESET CLUSTER or REFRESH CLUSTER without a really good reason.
- Do not have more than 2 FRs in a cluster without an overridingly good reason. There is in here some really good discussions round this question which are well worth finding and reading.
- Site your FRs on the biggest, most available servers you have. Mainframes are good choices, even if the rest of your cluster in on a distributed platform
- Do not have more clusters than you need. In the same way it's generally better to have 1 queue manager with 100 queues than 10 queue managers with 10 queues each, it's generally better to have 1 cluster with 100 queue managers than 10 clusters with 10 queue managers each.
- Use exits and SSL at your own risk. Have plenty of midnight oil ready to burn. Especially when you have successfully implemented one or both, and then need to make a change.
- Always check cluster health from an FR (see above re: mainframes)
- If your cluster's not working, check the channels first. Remeber than all the members of a cluster interconnect; firewalls are one of the reasons you'd have multiple clusters.
There are undoubtably many other points.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| Monk |
| Posted: Tue May 12, 2009 1:41 am Post subject: |
|
|
Master
Joined: 21 Apr 2007
Posts: 282
|
that's a good list poobah...
_________________
Thimk |
|
| Back to top |
|
|
| Vitor |
| Posted: Tue May 12, 2009 1:52 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| Monk wrote: |
| that's a good list poobah... |
One point I missed off, which is probably worth underlining again:
- WMQ Clusters are a workload balancing mechanism. They are not a high availablility solution. Attempting to use them as such will blow up in your face.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| Monk |
| Posted: Tue May 12, 2009 1:59 am Post subject: |
|
|
Master
Joined: 21 Apr 2007
Posts: 282
|
| Quote: |
| WMQ Clusters are a workload balancing mechanism. They are not a high availablility solution. Attempting to use them as such will blow up in your face. |
excellent point... 
if only my great MQ architects in my company..knew this...
_________________
Thimk |
|
| Back to top |
|
|
| Monk |
| Posted: Tue May 12, 2009 2:20 am Post subject: |
|
|
Master
Joined: 21 Apr 2007
Posts: 282
|
Poobah,
Can you point me to some docs or link that indicate or highlight the importance of the below point...
| Quote: |
WMQ Clusters are a workload balancing mechanism. They are not a high availablility solution. Attempting to use them as such will blow up in your face. |
_________________
Thimk |
|
| Back to top |
|
|
| Vitor |
| Posted: Tue May 12, 2009 2:30 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| Monk wrote: |
| Can you point me to some docs or link that indicate or highlight the importance of the below point |
Try the Clusters manual. It lists 2 benefits of WMQ Clustering, neither of which are High Availability.
To save you a couple of clicks, they are:
- Workload balancing
- Reduced system administration
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| Monk |
| Posted: Tue May 12, 2009 2:37 am Post subject: |
|
|
Master
Joined: 21 Apr 2007
Posts: 282
|
lol 
_________________
Thimk |
|
| Back to top |
|
|
|
|
