| Author |
Message
|
| mqdev |
 Posted: Tue Jan 28, 2003 5:31 am Post subject: Admin/Monitoring Issues in a huge MQ Clustered env |
 |
|
Centurion
Joined: 21 Jan 2003
Posts: 136
|
Hi,
We are designing a huge MQ Cluster with about 1000 QMs spread across our corporate wide network. One of the tasks is to design the Adminisration and Monitoring facility for this network. I would like to hear from experts who are familiar with such networks the following:
1. The Monitoring aspects - what events to watch out for and the corrective actions - pitfalls and tradeoffs taken. What kind of features/facilities of MQ were used for "pro-active" monitoring eg watermarks for Queues and any other similar featues?
2. Administrative aspects - what is needed from Admin perspective. I am not looking for the usual create MQ objects and start/stop stuff. Again any pitfalls and tradeoffs for the Admin facilities would be a great help
3. Security aspects
Our MQ system goals are:
Provide MQ connectivity to some 1000 odd geographically distributed sub-offices to the Main office - we are implementing this by a Cluster (any better ideas?). The communication between Main office and sub-offices should be available 24x7x365 - no downtime allowed. Our env is Unix (AIX, Solaris, Linux) and MQ5.3
If anyone can provide insights into the issues involved or point to resources that can throw light on the issues, it would be a great help. We are not willing to invest in any 3rd party tools - only MQ5.3 and have few development resources - so implementing any custom solutions is not a problem. We are trying to get a handle on what exactly to look for what facilities MQ provides to address the situations.
Thanks in advance for your time & insights.... |
|
| Back to top |
|
 |
| Troilus |
| Posted: Tue Jan 28, 2003 11:27 pm Post subject: |
|
|
Apprentice
Joined: 12 Jul 2002
Posts: 28
Location: Belgium
|
| Why would you not want to invest in third party tools? For a thousand queue managers environment it is the first thing you should do. The price of the license will be offset by all the effort you are doing now, plus all the time you will use diagnosing problems and firefighting in the future, not to mention unavailability that could be prevented by a well customised good third party configuration and monitoring product. |
|
| Back to top |
|
|
| nimconsult |
| Posted: Tue Jan 28, 2003 11:32 pm Post subject: |
|
|
Master
Joined: 22 May 2002
Posts: 268
Location: NIMCONSULT - Belgium
|
It looks like you need an MQ Series consultant. I am not sure that such a significant design can be constructed in a single discussion thread.
(does not bring anything to your questions, just a personal opinion) |
|
| Back to top |
|
|
| dgolding |
| Posted: Wed Jan 29, 2003 4:30 am Post subject: |
|
|
Yatiri
Joined: 16 May 2001
Posts: 668
Location: Switzerland
|
My $0.02, what is the value to the business if the messages can't be delivered?
If it's fairly trivial, then invest in a home-grown, "roll-your-own" solution. The cost of licencing a 1000 nodes on most 3rd party products would not be cheap I would have thought.
If however, these messages are the life-blood of the business, then don't even think about it. Get a third-party in, with consultancy on top to implement and hand-over - rather than wait for the day when your "home-grown" solution misses monitoring a million-dollar transaction that just has been squirted into empty space.
At the very least, you'll have someone to sue 
Again, purely my personal opionion... |
|
| Back to top |
|
|
| TonyD |
| Posted: Tue Feb 04, 2003 3:23 pm Post subject: |
|
|
Knight
Joined: 15 May 2001
Posts: 540
Location: New Zealand
|
| Do you mean that you will have a single MQ Cluster containing 1000+ queue managers?....that would make me a little nervous....if it was me I think I would consider implementing a number of overlapping clusters. |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Tue Feb 18, 2003 5:36 pm Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7716
|
In the Clustering Seminar at the IBM conferance, this point was brought up, and the answer was that simply having a large # of QMs was no reason to start overlapping multiple clusters. It only makes life more complicated.
The MQClusters manual lists the following reasons for possibly overlapping clusters:
To allow different organizations to have their own administration.
To allow independent applications to be administered separately.
To create classes of service.
To create test and production environments
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| bduncan |
| Posted: Wed Feb 19, 2003 11:33 am Post subject: |
|
|
Padawan
Joined: 11 Apr 2001
Posts: 1554
Location: Silicon Valley
|
Yeah, when I was messing around with overlapping clusters I realized that I wouldn't ever want to do it in production unless absolutely necessary. And one of my previous employers is going production with a single cluster of 3000 queue managers (after Hursley showed it would be feasible).
_________________
Brandon Duncan
IBM Certified MQSeries Specialist
MQSeries.net forum moderator |
|
| Back to top |
|
|
| TonyD |
| Posted: Tue Feb 25, 2003 2:12 pm Post subject: |
|
|
Knight
Joined: 15 May 2001
Posts: 540
Location: New Zealand
|
| I stand corrected (re overlapping clusters)!...I would be interested to know if there are any documented guidelines or case studies regarding implementation, maintenance and trouble-shooting on very large clusters. |
|
| Back to top |
|
|
| oz1ccg |
| Posted: Tue Feb 25, 2003 3:37 pm Post subject: |
|
|
Yatiri
Joined: 10 Feb 2002
Posts: 628
Location: Denmark
|
|
| Back to top |
|
|
|
|
