| Author |
Message
|
| meaton78 |
 Posted: Fri Aug 20, 2010 9:10 am Post subject: Mapping out MQ environments |
 |
|
Centurion
Joined: 16 Oct 2008
Posts: 100
|
Our company has massive amounts of MQ installations throughout our Dev - DR environments. Currently we track most of the details through Sharepoint lists, while using Omegamon for monitoring and configuration management.
Is there any discovery tools that are available that could map out our environments? I would love to see a graphical representation of all of the queue managers with details of how they interact with other queue managers, with regards to clusters and distributed channels.
It would be a massive undertaking to do this manually, and was just curious if anyone else has done this, and if so, how they accomplished it. |
|
| Back to top |
|
 |
| exerk |
| Posted: Fri Aug 20, 2010 9:55 am Post subject: |
|
|
Jedi Council
Joined: 02 Nov 2006
Posts: 6339
|
You might want to take a look at MQSystems MQArchitect product (no endorsement, or commission etc.  ).
_________________
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 |
|
|
| meaton78 |
| Posted: Fri Aug 20, 2010 10:17 am Post subject: |
|
|
Centurion
Joined: 16 Oct 2008
Posts: 100
|
I only get nervous when I see a link to the product with a referral ID in it. The product looks good, but does a little more than I'd like.
I guess my vision is something that could either crawl the network(which would probably never be allowed), or something that could read saveqmgr input and just make a really nice picture of each environment, showing which qmgrs connect to each other, what clusters they belong to, etc.
I'm guessing that something like this doesn't exist, but would be thrilled if it did. |
|
| Back to top |
|
|
| exerk |
| Posted: Fri Aug 20, 2010 10:28 am Post subject: |
|
|
Jedi Council
Joined: 02 Nov 2006
Posts: 6339
|
| meaton78 wrote: |
| ...or something that could read saveqmgr input... |
In which case, take a look at MQSystems MQDocument (which I do thoroughly endorse!).
_________________
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 |
|
|
| Michael Dag |
| Posted: Thu Sep 02, 2010 6:15 am Post subject: |
|
|
Jedi Knight
Joined: 13 Jun 2002
Posts: 2607
Location: The Netherlands (Amsterdam)
|
| meaton78 wrote: |
I only get nervous when I see a link to the product with a referral ID in it. The product looks good, but does a little more than I'd like.
|
Hi Meaton, I am the author of both MQDocument and MQArchitect, what do you mean by referral ID??? maybe I am missing something?
| meaton78 wrote: |
I guess my vision is something that could either crawl the network(which would probably never be allowed),
|
Crawling would be very nice, but should never be allowed as a hacker could do it too then... so that 'feature' is not in MQArchitect...
| meaton78 wrote: |
or something that could read saveqmgr input and just make a really nice picture of each environment, showing which qmgrs connect to each other, what clusters they belong to, etc.
|
MQArchitect re-uses the MQDocument package to extract information from your environment AND MQDocument can get information from your environment natively OR by re-using almost any output file you already have, like saveqmgr files or even runmqsc screen dumps... I don't think it gets any better then that... If anyone has another source for MQ object configuration information then I am open to suggestions... 
| meaton78 wrote: |
I'm guessing that something like this doesn't exist, but would be thrilled if it did. |
Well it does..., so contact me!
_________________
Michael
MQSystems Facebook page |
|
| Back to top |
|
|
| zpat |
| Posted: Thu Sep 02, 2010 6:29 am Post subject: |
|
|
Jedi Council
Joined: 19 May 2001
Posts: 5866
Location: UK
|
Crawling should be in such a product. Omitting a feature is not a form of security. This would be a great feature and one that I have wanted for a long time.
Security comes from stopping that program from being able to access all the queue manager information without the required access rights.
Maintaining separate documentation is tedious and almost immediately out of date. It's also pointless duplication of information. Dynamically recreating a MQ network diagram would be very useful. |
|
| Back to top |
|
|
| Michael Dag |
| Posted: Thu Sep 02, 2010 6:46 am Post subject: |
|
|
Jedi Knight
Joined: 13 Jun 2002
Posts: 2607
Location: The Netherlands (Amsterdam)
|
| zpat wrote: |
Crawling should be in such a product. Omitting a feature is not a form of security. This would be a great feature and one that I have wanted for a long time.
|
Wohaa... didn't mean to step on toes... Please define crawling in your terms without breaking all security rules?
What is possible today with MQDocument is to install it along WMQ on the machine and configure it to run as an MQ Service with a timed schedule or interval and then use DQM to send the resulting files to a central location/queue to be collected for further processing, like a "call home and report" function for all involved QueueManagers.
| zpat wrote: |
Security comes from stopping that program from being able to access all the queue manager information without the required access rights.
|
I am not going to open the can of worms on MQ Security other people are much more experienced with that...
| zpat wrote: |
Maintaining separate documentation is tedious and almost immediately out of date.
|
The original goal of MQArchitect is to create / visualise what you want to achieve and then generate the commands to deploy from it, inspired by Model Driven Development (MDD) from that perspective documentation is always leading and never out of date...
now I know reality is not like that at all, so it can also reverse engineer an existing topology...
| zpat wrote: |
It's also pointless duplication of information.
|
like I said, when it is leading the process rather then a backstop activity it's completely the other way around and even save you a lot of time too...
| zpat wrote: |
Dynamically recreating a MQ network diagram would be very useful. |
any samples you can point to that come close to what you mean?
_________________
Michael
MQSystems Facebook page |
|
| Back to top |
|
|
| meaton78 |
| Posted: Thu Sep 02, 2010 6:58 am Post subject: |
|
|
Centurion
Joined: 16 Oct 2008
Posts: 100
|
"Dynamically recreating a MQ network diagram would be very useful."
That is exactly what I am looking for. We already have a product for configuration management, so MQArchitect would not be needed for that, making this a semimanual process. I suppose I could script saveqmgr and have it ftp the output somewhere for import.
I have never seen a product that could generate a network diagram, but that is what the original post was getting at. I have no problems with visualizing a queue manager, but would love to be able to print out a full network diagram to show upper management when they ask questions like why does it take so long to patch or something like that. |
|
| Back to top |
|
|
| Michael Dag |
| Posted: Thu Sep 02, 2010 7:07 am Post subject: |
|
|
Jedi Knight
Joined: 13 Jun 2002
Posts: 2607
Location: The Netherlands (Amsterdam)
|
| meaton78 wrote: |
"Dynamically recreating a MQ network diagram would be very useful."
That is exactly what I am looking for. We already have a product for configuration management, so MQArchitect would not be needed for that, making this a semimanual process. I suppose I could script saveqmgr and have it ftp the output somewhere for import.
I have never seen a product that could generate a network diagram, but that is what the original post was getting at. I have no problems with visualizing a queue manager, but would love to be able to print out a full network diagram to show upper management when they ask questions like why does it take so long to patch or something like that. |
What product are you currently using for configuration management? if it can export XML data that could possibly be used as a source aswell...
please define full network diagram, there are plenty of network diagramming tools available onyl none cover MQ, MQArchitect only covers the MQ part of the topology so you won't see any switches or routers, etc... just MQ (machines, qmgrs, queues, channels, etc...)
_________________
Michael
MQSystems Facebook page |
|
| Back to top |
|
|
| zpat |
| Posted: Thu Sep 02, 2010 7:07 am Post subject: |
|
|
Jedi Council
Joined: 19 May 2001
Posts: 5866
Location: UK
|
What I mean is that crawling by analysing MQ channels and finding the queue managers by connecting to each one and so on, is the function wanted.
Anyone can write a program (if they are clever enough and have time to code a PCF program) to do this. That is not security. Security is not the job of the application (anyone can code anything).
However the standard MQ OAM controls can be used to limit what PCF commands (if any) can be issued. If people have no MQ security implemented - the absence of a crawler program does not make their MQ infrastructure secure.
Security is about MQ preventing inappropriate access, the queue manager does that (if properly configured). Clearly for a crawler to work, it will have to be granted the necessary access for it to function (via client channels).
The nearest thing to what I want is MO71's network view, but even MO71 does not discover the queue managers automatically (based on following the channel definitions).
It's really a simple requirement conceptually, and for those with the right PCF knowledge and coding ability - it can't be that hard. |
|
| Back to top |
|
|
| meaton78 |
| Posted: Thu Sep 02, 2010 7:15 am Post subject: |
|
|
Centurion
Joined: 16 Oct 2008
Posts: 100
|
We currently use Omegamon, which does have the capability to generate an output for each queue manager.
What I would like to see is a big picture with every queue manager in each region (QA/Dev/Prod etc) and how they interact with each other. I'd love different views where I could say show me a diagram of cluster ABC and just have it draw it up. Or say show me the entire Prod infrastructure and how everything is linked (both cluster and distributed).
I'm not at all interested in any of the network hardware, strictly our MQ infrastructure. |
|
| Back to top |
|
|
| Vitor |
| Posted: Thu Sep 02, 2010 7:18 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| zpat wrote: |
| It's really a simple requirement conceptually, and for those with the right PCF knowledge and coding ability - it can't be that hard. |
That's quite true; knowledge of coding & PCF is all that's really needed. The security problem I can see with realising this concept is that this crawler application would need the authority to issue PCF commands on every queue manager in the estate, giving a central point of vunerability. Most security teams I've met would look unfavorably on this.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| Michael Dag |
| Posted: Thu Sep 02, 2010 7:25 am Post subject: |
|
|
Jedi Knight
Joined: 13 Jun 2002
Posts: 2607
Location: The Netherlands (Amsterdam)
|
| zpat wrote: |
What I mean is that crawling by analysing MQ channels and finding the queue managers by connecting to each one and so on, is the function wanted.
Anyone can write a program (if they are clever enough and have time to code a PCF program) to do this. That is not security. Security is not the job of the application (anyone can code anything).
However the standard MQ OAM controls can be used to limit what PCF commands (if any) can be issued. If people have no MQ security implemented - the absence of a crawler program does not make their MQ infrastructure secure.
Security is about MQ preventing inappropriate access, the queue manager does that (if properly configured). Clearly for a crawler to work, it will have to be granted the necessary access for it to function (via client channels).
The nearest thing to what I want is MO71's network view, but even MO71 does not discover the queue managers automatically (based on following the channel definitions).
It's really a simple requirement conceptually, and for those with the right PCF knowledge and coding ability - it can't be that hard. |
I get what you are looking for, but what you are looking for (from a collection point of view) is not on my agenda, I try to use as much other sources as I can, using the path of least resistance or installation effort.
_________________
Michael
MQSystems Facebook page |
|
| Back to top |
|
|
| meaton78 |
| Posted: Thu Sep 02, 2010 7:27 am Post subject: |
|
|
Centurion
Joined: 16 Oct 2008
Posts: 100
|
| That's fine. I'm probably gonna make it a rainy day project and try to code it as time allows. Thanks anyways. |
|
| Back to top |
|
|
| Michael Dag |
| Posted: Thu Sep 02, 2010 7:30 am Post subject: |
|
|
Jedi Knight
Joined: 13 Jun 2002
Posts: 2607
Location: The Netherlands (Amsterdam)
|
| meaton78 wrote: |
We currently use Omegamon, which does have the capability to generate an output for each queue manager.
What I would like to see is a big picture with every queue manager in each region (QA/Dev/Prod etc) and how they interact with each other. I'd love different views where I could say show me a diagram of cluster ABC and just have it draw it up. Or say show me the entire Prod infrastructure and how everything is linked (both cluster and distributed).
I'm not at all interested in any of the network hardware, strictly our MQ infrastructure. |
I have spoken to Candle people (now IBM...) a long time ago and they were not willing to work with me, I could have a look at some of the exports and see if they are easily convertable to MQArchitect/MQDocument XML files, but that would require additional effort on top of the standard product that is available today, so please find out if MQArchitect from a diagramming perspective (based on Visio 2003 and up) meets your needs.
_________________
Michael
MQSystems Facebook page |
|
| Back to top |
|
|
|
|
