| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
  |
|
| Implementing Hub and Spoke using clustering |
« View previous topic :: View next topic » |
| Author |
Message
|
| murdeep |
 Posted: Tue Mar 14, 2006 9:51 am Post subject: Implementing Hub and Spoke using clustering |
 |
|
Master
Joined: 03 Nov 2004
Posts: 211
|
Hi, I have a requirement to deloy a hub and spoke MQ network. In this network the spokes MUST NOT communicate with eachother directly but instead must route via the hub.
I understand how to achieve this quite easily using regular DQM objects (i.e. sdr/rcvr channels, xmitqs and qmgr aliases) but I'd like to know if I can reduce the administration by using clustering. By example, if I add a new spoke I don't want to have to visit all existing spokes to create a new qmgr alias.
Ideally, I would like to simply join a new spoke to the full repository hub and then when the new spoke needs to communicate with an existing spoke the message would route through the hub.
My understanding is that when using clustering if the new spoke had to communicate with an existing spoke that channels between the spokes would be dynamically created and the spokes would be directly connected.
Any advice would be very thoughtful. |
|
| Back to top |
|
 |
| jefflowrey |
| Posted: Tue Mar 14, 2006 9:58 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
If the spokes must not communicate with each other, then you can not cluster the spokes.
I think that you can use default transmission queues to solve this problem, though.
Consider that each spoke has a default transmission queue to the hub and the hub has regular transmission queues for each spoke. Then I think (I haven't sat down and worked it out through the name resolution rules), the destination name should get re-resolved at the hub and go to the right place.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| sandiksk |
| Posted: Tue Mar 14, 2006 10:24 am Post subject: |
|
|
Centurion
Joined: 08 Jun 2005
Posts: 133
|
| Instead of clusturing why dont you write a script which creates those objects for you wheneer a new spoke is added. We have a hub ad spoke kind of environment, whenever a new spoke is added we just run that script. Of course this is possible only if you have some standard naming conventions. |
|
| Back to top |
|
|
| murdeep |
| Posted: Tue Mar 14, 2006 10:26 am Post subject: |
|
|
Master
Joined: 03 Nov 2004
Posts: 211
|
Jeff, yes that is what I thought immediately after hitting submit. I don't necessarily have to touch each spoke when a new spoke is added. By using the default transmit queue at the spokes pointing to the hub the put should resolve and the msg placed on the default xmitq with the rqmname set to the destination qmgr name and the rname set to the queue specified. Once at the hub the appropriate resolution will occur and the message routed accordingly.
I still think it will be an administration problem when it comes to queues though. If I add a new queue on one spoke I'll need to define remote queues at every other spoke.
I thought I read a post here that said I could do this via clustering. I searched but couldn't find it. Maybe I was being optimistic. |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Tue Mar 14, 2006 10:50 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
Actually, with default transmission queues and default destinations (qmgr aliases) you don't need remote queues.
In other words, you should be able to configure just a set of qmgr aliases on the hub, and a default transmission queue on each spoke.
When you add a new spoke, create the channels, xmitq and a new qmgr alias on the hub - and channels and default xmitq on the spoke.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Tue Mar 14, 2006 2:00 pm Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
Jeff, correct, but in this scenario, the app now needs to know the name of the queue on the remote spoke AND the name of the remote spoke QM. If clustered, them only the q name is needed. If remote queue defs are used in hub and spoke, again, the app only needs to know the name of the q, as the remote q def will take care of the remote QM name.
Of course, if these are reply messages, all the app has to do is honor the MQMD's ReplyToQ and ReplyToQM. But if the app is initiating the message, then somehow somewhere (hard coded -eck - or remote q def), the destination QM must be specified in a hub and spoke.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Tue Mar 14, 2006 2:10 pm Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
Peter -
If there were a standalone service that could provide that destination information to any application in the MQ network... then we'd be most of the way to a low-rent ESB.
Otherwise, yeah. Remote queue defs are needed - as we don't want the app to know the remote qmgr name (ick!).
Although... can we put remote queues only on the hub? If the app doesn't specify a qmgr name, and the message goes onto the default transmission queue and arrives at the hub... the name should get reresolved (maybe) to the remote queue name on the hub, which would provide the destination qmgr?
That is, instead of using Qmgr aliases to resolve the final destination, we just use "real" remote queues.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Tue Mar 14, 2006 5:27 pm Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
hmmmm, never thought about that.
So we have our QM named SpokeP1, SpokeP2, SpokeP3, and of course HubP. Substitue the P for Q or for D or for I, depending on what environment you are in Production or QA or Dev or Integration. The QM names change between environments, but the queue names stay the same.
Any application connected to a spoke QM would specify the q name, and give a destination QM of XXX. Its gotta put something in the destination QM, otherwise the default XMITQ or QM Aliases don't ever get called upon. XXX would catch the default xmitq to the Hub. On the the Hub, a QM Alias for XXX blanks that QM name to blanks. Name resolution takes place again, at which point the remote q def on the hub comes into play and sends it to the correct spoke. By coding XXX, the app can keep the same XXX in DEV, QA and PROD. The code doesn't need to change as it migrates through the environments.
Kinda weird, but it would work I think.
By the way, we just recently abandoned our Hub and Spoke (after 3 years) in favor of Point to Point. Hub and Spoke looks pretty on paper, and works when it works, but everything depends on that one QM, the Hub. If, no WHEN, it has a problem, everything stops. There isn't a hardware clustering solution that is 100%, and even if there were, the Hub failing over means everything waits. Too many eggs in one basket IMHO.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Tue Mar 14, 2006 5:37 pm Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
| PeterPotkay wrote: |
Any application connected to a spoke QM would specify the q name, and give a destination QM of XXX. XXX would catch the default xmitq to the Hub. On the the Hub, a QM Alias for XXX blanks that QM name to blanks. Name resolution takes place again, at which point the remote q def on the hub comes into play and sends it to the correct spoke.
Kinda weird, but it would work I think. |
yeah... that seems about right.
Edit: Except that the remote queues have to have unique names on the hub... So you end up having to essentially embed the qmgr name in the remote qmgr name anyway. Or using multiple XXX aliases on the spoke - which defeats the purpose.
| PeterPotkay wrote: |
| By the way, we just recently abandoned our Hub and Spoke (after 3 years) in favor of Point to Point. Hub and Spoke looks pretty on paper, and works when it works, but everything depends on that one QM, the Hub. If, no WHEN, it has a problem, everything stops. There isn't a hardware clustering solution that is 100%, and even if there were, the Hub failing over means everything waits. Too many eggs in one basket IMHO. |
I've always viewed a strict hub/spoke architecture (rather than a logical hub/spoke architecture) as a only being useful when the physical network requires it. Otherwise, the MQ network should be constructed as it makes the most sense from an infrastructure point of view.
But it sounds like in this case that the physical network does require it - that the spokes are perhaps customers rather than internal business units. And you would not want to cluster your customers together...
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| HubertKleinmanns |
| Posted: Tue Mar 21, 2006 10:46 am Post subject: Re: Implementing Hub and Spoke using clustering |
|
|
Shaman
Joined: 24 Feb 2004
Posts: 732
Location: Germany
|
| murdeep wrote: |
Hi, I have a requirement to deloy a hub and spoke MQ network. In this network the spokes MUST NOT communicate with eachother directly but instead must route via the hub.
I understand how to achieve this quite easily using regular DQM objects (i.e. sdr/rcvr channels, xmitqs and qmgr aliases) but I'd like to know if I can reduce the administration by using clustering. By example, if I add a new spoke I don't want to have to visit all existing spokes to create a new qmgr alias.
Ideally, I would like to simply join a new spoke to the full repository hub and then when the new spoke needs to communicate with an existing spoke the message would route through the hub.
My understanding is that when using clustering if the new spoke had to communicate with an existing spoke that channels between the spokes would be dynamically created and the spokes would be directly connected.
Any advice would be very thoughtful. |
murdeep,
to separate the spokes from each other you need to set-up seperate clusters for each spoke. So you would not reduce the administration in this scenario.
_________________
Regards
Hubert |
|
| Back to top |
|
|
|
|
|
| |
|
Page 1 of 1 |
|
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
|
|
|
|
