| Author |
Message
|
| Bnikpour |
 Posted: Tue Jun 21, 2011 8:50 am Post subject: Best practices for administration:hub and spoke archtecture |
 |
|
Novice
Joined: 19 Apr 2011
Posts: 20
Location: Phoenix, AZ
|
Hello Everyone,
This is my first post here so *flamesuit on* in case I do something wrong. 
We are creating a MQHUB to service all of our existing development environments (6 environments) in an effort to reduce licensing costs associated with the point to point architecture we had before.
Our basic layout contains and active and passive node both with MQ installed. The MQ Hub will run on a Power HA cluster. The queue manager will run on the active node but will be automatically moved to the passive node in the event of a failover. Each environment will have its own set of supporting queues on the MQ Hub.
I was wondering if you all could share some common pitfalls you have seen, or , provide suggestions for administering this sort of architecture. Thanks in advance for sharing your knowledge. |
|
| Back to top |
|
 |
| Vitor |
| Posted: Tue Jun 21, 2011 9:00 am Post subject: Re: Best practices for administration:hub and spoke archtect |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| Bnikpour wrote: |
| This is my first post here so *flamesuit on* in case I do something wrong. |
It all seems fine. 
| Bnikpour wrote: |
| I was wondering if you all could share some common pitfalls you have seen, or , provide suggestions for administering this sort of architecture. |
Well you'll probably get a comment shortly about not using active/active, but that's the tail end of a long-running debate & active/passive is fine. You will get points for using Power. It's nice to have another poster with budget constraints.
One pitfall is size/throughput but if it's development that sort of mitigates itself. Another is ensuring that messages associated with one environment don't leak into another one. Do you have a tight security policy or is it every developer for themselves in terms of application connections?
As to administering it, it's much like administering any other queue manager except (in your case) it's 6 times as complex as your previous one. Any of the usual suspect tools will work, which is "best" for you is determined by all the criteria discussed at much length in here!
Others will undoubtably have other, possibly better, points to raise.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| Bnikpour |
| Posted: Tue Jun 21, 2011 9:08 am Post subject: |
|
|
Novice
Joined: 19 Apr 2011
Posts: 20
Location: Phoenix, AZ
|
| Quote: |
| Do you have a tight security policy or is it every developer for themselves in terms of application connections? |
Each environment and application within that environment will have its own set of channels and queues on the main (hub) QM, which I hope will mitigate that issue. Each LPAR (AIX) for the hub also has its own Port/Listener. |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Tue Jun 21, 2011 10:01 am Post subject: Re: Best practices for administration:hub and spoke archtect |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9469
Location: US: west coast, almost. Otherwise, enroute.
|
| Bnikpour wrote: |
This is my first post here so *flamesuit on* in case I do something wrong. |
My flame-thrower is in the shop for a tune-up.
| Bnikpour wrote: |
We are creating a MQHUB ... in an effort to reduce licensing costs associated with the point to point architecture we had before. |
Hub-and-spoke topology reduces the number of point-to-point channels, but channels are not licensed.
Have you considered using mq clusters to reduce the number of point-to-point channels?
_________________
I like deadlines. I like to wave as they pass by.
ב''ה
Lex Orandi, Lex Credendi, Lex Vivendi. As we Worship, So we Believe, So we Live. |
|
| Back to top |
|
|
| Bnikpour |
| Posted: Tue Jun 21, 2011 10:14 am Post subject: Re: Best practices for administration:hub and spoke archtect |
|
|
Novice
Joined: 19 Apr 2011
Posts: 20
Location: Phoenix, AZ
|
| Quote: |
| Have you considered using mq clusters to reduce the number of point-to-point channels? |
We tried selling the idea of clustering to the business but it's one of those: We want a MQ hub deals. They want a MQ hub only a MQ hub and it should have been done yesterday.
So,unfortunately, clustering really isn't an option. What problems would the channels not being licensed cause?
_________________
Addicted to E-mail, not by choice.
MQ & WAS Admin |
|
| Back to top |
|
|
| mqjeff |
| Posted: Tue Jun 21, 2011 10:23 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
It's not that the channels aren't licensed.
It's that your license doesn't depend on the number of channels you have defined.
MQ licensing is based on the hardware capacity of the machine, or if you have sub-capacity licenses, on the capacity of the lpars you have MQ running in.
You can also get reduced license costs for standby hardware.
It's not as clear what you mean by 'hub'. Do you mean that you are migrating a set of different queue managers to each run in a different LPAR on the same machine, rather than running on separate machines? In that case, you are not really altering your MQ topology, just moving the location of the queue managers.
Or do you mean you are reducing the number of queue managers? |
|
| Back to top |
|
|
| Bnikpour |
| Posted: Tue Jun 21, 2011 10:33 am Post subject: |
|
|
Novice
Joined: 19 Apr 2011
Posts: 20
Location: Phoenix, AZ
|
A significant reduction in the number of queue managers from the old architecture, and therefore a significant savings in the number of PVU's needed.
Old architecture had something like 30 installations of MQ. Where each LPAR had its own QM.
_________________
Addicted to E-mail, not by choice.
MQ & WAS Admin |
|
| Back to top |
|
|
| exerk |
| Posted: Tue Jun 21, 2011 11:04 am Post subject: |
|
|
Jedi Council
Joined: 02 Nov 2006
Posts: 6339
|
OK. Hub-and-spoke suggests to me a still large queue manager footprint, e.g. one hub multiple-applications queue manager and n spoke single application queue managers, so I don't really see where your savings will come in. Are none of these developmental applications candidates for WMQ Client?
_________________
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 |
|
|
| Vitor |
| Posted: Tue Jun 21, 2011 11:08 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| exerk wrote: |
| OK. Hub-and-spoke suggests to me a still large queue manager footprint, e.g. one hub multiple-applications queue manager and n spoke single application queue managers, so I don't really see where your savings will come in. |
Another, perhaps less traditional version, is one application to a spoke with a queue manager as the hub allowing inter-application communication. As described it sounds like each of the 6 environments had it's own queue manager thus configured and now all the applications are sharing a single one.
I could be completely wrong (it's the day for it) as I'm just guessing.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| exerk |
| Posted: Tue Jun 21, 2011 11:18 am Post subject: |
|
|
Jedi Council
Joined: 02 Nov 2006
Posts: 6339
|
| Vitor wrote: |
| exerk wrote: |
| OK. Hub-and-spoke suggests to me a still large queue manager footprint, e.g. one hub multiple-applications queue manager and n spoke single application queue managers, so I don't really see where your savings will come in. |
Another, perhaps less traditional version, is one application to a spoke with a queue manager as the hub allowing inter-application communication. As described it sounds like each of the 6 environments had it's own queue manager thus configured and now all the applications are sharing a single one.
I could be completely wrong (it's the day for it) as I'm just guessing. |
Different interpretations I suppose. I just keep thinking of the diagram IBM publish showing a hub-and-spoke set-up, admittedly for FRs in a cluster but I've also seen it used marked up as 'branches to central office' somewhere...
_________________
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 |
|
|
| Vitor |
| Posted: Tue Jun 21, 2011 11:33 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| exerk wrote: |
| Different interpretations I suppose. |
No, different implementations.
| exerk wrote: |
| I just keep thinking of the diagram IBM publish showing a hub-and-spoke set-up, admittedly for FRs in a cluster but I've also seen it used marked up as 'branches to central office' somewhere... |
This kind of "1 queue manager in each branch office with a central hub queue manager at head office" is indeed the traditional "hub and spoke".
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| mqjeff |
| Posted: Tue Jun 21, 2011 11:41 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
| Vitor wrote: |
| exerk wrote: |
| Different interpretations I suppose. |
No, different implementations.
| exerk wrote: |
| I just keep thinking of the diagram IBM publish showing a hub-and-spoke set-up, admittedly for FRs in a cluster but I've also seen it used marked up as 'branches to central office' somewhere... |
This kind of "1 queue manager in each branch office with a central hub queue manager at head office" is indeed the traditional "hub and spoke". |
So that's why I was seeking clarity. It sounds like Bnikpour is reducing the number of branch office qmgrs, thus altering the MQ topology and increasing the number of application spokes.
It's not clear if the branch office qmgrs are entirely disappearing or just moving to a regional topology. |
|
| Back to top |
|
|
| Bnikpour |
| Posted: Tue Jun 21, 2011 12:16 pm Post subject: |
|
|
Novice
Joined: 19 Apr 2011
Posts: 20
Location: Phoenix, AZ
|
This is correct, I am reducing the number of QM's total instead of having multiple separate QM's for each environment and application I only have one large QM which services all the environments and all the applications across the enterprise. This one large QM is what I was referring to as the "Hub", sorry for any confusion.
_________________
Addicted to E-mail, not by choice.
MQ & WAS Admin |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Tue Jun 21, 2011 12:51 pm Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9469
Location: US: west coast, almost. Otherwise, enroute.
|
How to move a qmgr has been discussed here many times. You might want to Search here.
You may want to start with an inventory of object names from all qmgrs. You may discover similar/duplicate object names from the many qmgrs you intend to combine into a single qmgr. For example, how many queues named Q1 do you have, and in which qmgrs? You will need to do some object renaming, which means application changes OR alias definitions (unless it's the alias that is the duplicate name).
_________________
I like deadlines. I like to wave as they pass by.
ב''ה
Lex Orandi, Lex Credendi, Lex Vivendi. As we Worship, So we Believe, So we Live. |
|
| Back to top |
|
|
| Bnikpour |
| Posted: Tue Jun 21, 2011 1:02 pm Post subject: |
|
|
Novice
Joined: 19 Apr 2011
Posts: 20
Location: Phoenix, AZ
|
I have already moved it and done all the work, I was asking in my original question if there were any known issues or pitfalls I should lookout for while administering the type of system I have created.
_________________
Addicted to E-mail, not by choice.
MQ & WAS Admin |
|
| Back to top |
|
|
|
|
