| Author |
Message
|
| shash |
 Posted: Thu Feb 17, 2005 6:04 pm Post subject: Hub-Spoke dilemma |
 |
|
Novice
Joined: 08 Dec 2004
Posts: 20
|
I believe, in WebSphere MQ implementations, the hub-spoke architecture is very commonly used.
Suppose we have an implementation where we have a hub hosting queue manager QMHub. Also let us assume that there are three spokes on three different servers. Each of these spokes host queue managers QM1, QM2 and QM3 respectively.
Now I believe, the hub will not have any application queue (although it can, but for the purpose of this discussion, let us assume that it does'nt). Just channels and xmitq's.
QM1 has a remote queue RQ2 that point to a local application queue Q2 on QM2.
QM2 has a remote queue RQ1 that point to a local application queue Q1 on QM1.
There is no direct channel between QM1, QM2 and QM3.
I have the following question/observations regarding this topology:
1) Is this architecture commonly used?
2) Is it common (or say, a good practice) to have application queues on QMHub as well?
3) Messages can be put on Q2 by having clients directly connect to QM2 and putting messages there. Else, clients can connect to QM1 and use the remote queue definition RQ2 to put messages on Q2.
If the remote queue RQ2 is used, then messages will have to travel through QMHub to reach Q2. Since direct channels do not exist between the spokes, if sender clients use the remote queue definition, then the message will be routed via the hub (QMHub). That can result in a lot of traffic and QMHub can soon become a bottleneck.
4) If QMHub goes down then the entire network is down. So QMHub is the single point of failure.
5) If this architecture is commonly used, how do you design for failover?
6) I am not seeing any benefit of this configuration. Am I missing something or have I ignored something very vital in this sketch.
Could someone please provide me some insight into this dilemma?
Regards,
shash. |
|
| Back to top |
|
 |
| RogerLacroix |
| Posted: Thu Feb 17, 2005 7:51 pm Post subject: |
|
|
Jedi Knight
Joined: 15 May 2001
Posts: 3264
Location: London, ON Canada
|
Hi,
Answers:
1) Yes
2) It depends on the thinking of your company's 'Messaging Architect'. Some are ok with it, some are not. Personally, I am ok with it.
3) If your application does not connect to a single queue manager then you will need to code property files, ini files or JNDI with all of the hostname, port # & channel name for each queue manager. This could be an administration nightmare.
4) Use Veritas with Active / Passive failover setup for your hub queue manager.
5) see # 4
6) If you are an application developer then you will never see any benefit. If on the other hand you are part of a deploy team with tens or hundreds of application or an MQ Administrator then the configuration / administration / management will be greatly reduced / easier with a spoke & hub architecture.
Regards,
Roger Lacroix
_________________
Capitalware: Transforming tomorrow into today.
Connected to MQ!
Twitter |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Thu Feb 17, 2005 9:24 pm Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
Think as well in terms of security or load balancing.
The hub can be(come) a cluster gateway and will allow load balancing.
The hub can act as a network gateway and will allow forwarding outside your network and access to your network and as such be the only qmgr with SSL and access to the outside world....
Enjoy  |
|
| Back to top |
|
|
| shash |
| Posted: Fri Feb 18, 2005 2:05 pm Post subject: |
|
|
Novice
Joined: 08 Dec 2004
Posts: 20
|
Hi Roger,
Thanks for your reply. I am not sure if I understand point 6# that you made. Suppose I am an administrator, how then will I benefit from having a hub.
shash |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Fri Feb 18, 2005 2:12 pm Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
| shash wrote: |
| Suppose I am an administrator, how then will I benefit from having a hub. |
I don't know what Roger thinks, but here's what I think.
An administrator benefits because on each non Hub queue manager, they only have to create one sender/receiver pair - to and from the hub. And on the Hub, they only have to create a sender/receiver pair for each spoke.
This is a lot less channel administration and maintenance than a fully connected network between all QMs.
But still more than in a cluster...
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| shash |
| Posted: Fri Feb 18, 2005 2:23 pm Post subject: |
|
|
Novice
Joined: 08 Dec 2004
Posts: 20
|
Jeff, thanks for your prompt reply. Am I correct in my assumption that communication in a hub-spoke config will originate in a spoke and end in a different spoke, routed via the hub?
I see your argument regarding reduced channels. |
|
| Back to top |
|
|
| shash |
| Posted: Fri Feb 18, 2005 2:36 pm Post subject: |
|
|
Novice
Joined: 08 Dec 2004
Posts: 20
|
Thanks fjb_saper for your comments.
You said:
| Quote: |
| The hub can be(come) a cluster gateway and will allow load balancing. |
In such a case, the hub will function more as a gateway queue manager and the architecture will no longer be a pure hub-spoke implementation but rather a clustered implementation.
Also, in that case, client will have to connect to the hub in order to put a message on an application queue which is probably hosted on one of the spokes.
| Quote: |
| The hub can act as a network gateway and will allow forwarding outside your network and access to your network and as such be the only qmgr with SSL and access to the outside world.... |
I agree. This might be a powerful motivation. |
|
| Back to top |
|
|
| vennela |
| Posted: Mon Feb 21, 2005 6:52 am Post subject: |
|
|
Jedi Knight
Joined: 11 Aug 2002
Posts: 4055
Location: Hyderabad, India
|
| Quote: |
| Also, in that case, client will have to connect to the hub in order to put a message on an application queue which is probably hosted on one of the spokes. |
Not necessarily.
If some spokes are hosting the cluster queue, the clients can connect to the other non hosting spokes and put the messages to those clustered queues |
|
| Back to top |
|
|
| kirani |
| Posted: Mon Feb 21, 2005 10:02 am Post subject: |
|
|
Jedi Knight
Joined: 05 Sep 2001
Posts: 3779
Location: Torrance, CA, USA
|
I wonder how many of you have the Broker installed on the hub queue manager?
_________________
Kiran
IBM Cert. Solution Designer & System Administrator - WBIMB V5
IBM Cert. Solutions Expert - WMQI
IBM Cert. Specialist - WMQI, MQSeries
IBM Cert. Developer - MQSeries
|
|
| Back to top |
|
|
| jefflowrey |
| Posted: Mon Feb 21, 2005 10:09 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
I think even if broker is in a spoke on a hub/spoke MQ network...
It's still the hub of the data flow network...
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| kirani |
| Posted: Mon Feb 21, 2005 10:16 am Post subject: |
|
|
Jedi Knight
Joined: 05 Sep 2001
Posts: 3779
Location: Torrance, CA, USA
|
I agree. That's why we have the Broker installed on our Hub queue manager. This queue manager connects different client (spoke) queue managers together. We don't have lots of queue managers and our apps don't need load balancing, so we are not using MQ clusters. Our MQ Admins are happy with this configuration.
_________________
Kiran
IBM Cert. Solution Designer & System Administrator - WBIMB V5
IBM Cert. Solutions Expert - WMQI
IBM Cert. Specialist - WMQI, MQSeries
IBM Cert. Developer - MQSeries
|
|
| Back to top |
|
|
|
|
