| Author |
Message
|
| tso0rxp |
 Posted: Thu Aug 08, 2002 7:56 am Post subject: How would you design this? |
 |
|
Voyager
Joined: 07 Jan 2002
Posts: 85
|
| Hub/spoke architecture. 3 QMGR's on separate servers, 1 acting as the hub between the others. Currently, both sattelite servers rely totally on the availability of the hub. If hub goes down so does communication between the two. How would you design redundancy so that a failover is automatically initiated when hub is unavailable? Would you design a direct link between 2 sattelites to be initated when hub is down? Would clustering help - if so, how? Environment, Solaris and MQ v5.2. |
|
| Back to top |
|
 |
| bduncan |
| Posted: Thu Aug 08, 2002 11:03 am Post subject: |
|
|
Padawan
Joined: 11 Apr 2001
Posts: 1554
Location: Silicon Valley
|
You asked:
| Quote: |
| Would you design a direct link between 2 sattelites to be initated when hub is down? |
If this is possible to do (networking wise) then why not allow the 2 queue managers to communicate directly all the time?
This is basically what clustering will do. Although the hub might be the repository for the cluster, the two spokes will be able to talk to each other directly because that is what a cluster is; as opposed to hub-and-spoke.
If you don't want to go through the trouble of setting up a cluster, why not just create channels between the two spoke queue managers?
_________________
Brandon Duncan
IBM Certified MQSeries Specialist
MQSeries.net forum moderator |
|
| Back to top |
|
|
| tso0rxp |
| Posted: Thu Aug 08, 2002 11:26 am Post subject: |
|
|
Voyager
Joined: 07 Jan 2002
Posts: 85
|
If this is possible to do (networking wise) then why not allow the 2 queue managers to communicate directly all the time?
At one time, this would have been desirable but this defeats the purpose of a true hub/spoke (end up having too many interconnected systems and maintenance becomes burdensome). The concept of clustering looked promising but requires too much overhead.
We have failover built in at the hardware level and can 'recover' within the hour but I have a programmer who wants to build an alternative architecture that utilizes clustering or aliases AND is automated to revert to the failover if hub is unavailable. I suggested that it would take longer to failover to the alias queues than it would be to recover the hub queue manager. He did not accept this and wants to know why I'm against alias queues bypassing the hub - to be used during a failure to hub. I think it is best to set up a sound failure recovery to the hub server than to architect (and maintain) many aliases and/or redundancy.
I think clustering may be the best solution here because it would not require reconfiguring the application if the hub goes down.
Regards, Bob P. |
|
| Back to top |
|
|
| bigdavem |
| Posted: Thu Aug 08, 2002 10:11 pm Post subject: |
|
|
Acolyte
Joined: 16 Sep 2001
Posts: 69
Location: Sydney, Australia
|
| We've got a similar architecture but on a larger scale and it was ultimately our decision (and the recommendation of our MQ consultants) to go with a cluster. It was the only way we could guarantee MQ availability without having channels going in all directions. |
|
| Back to top |
|
|
| nimconsult |
| Posted: Thu Aug 08, 2002 10:34 pm Post subject: |
|
|
Master
Joined: 22 May 2002
Posts: 268
Location: NIMCONSULT - Belgium
|
I do not know the configuration option you have taken, but what about this one:
Configration:
satellite servers: QM1, QM2
hub: QMHUB, and for failover a second queue manager (on a second machine) QMHUB2
Initial configuration:
on QM1:
define qremote(QM2) rqmname(QM2) xmitq(QMHUB)
on QM2:
define qremote(QM1) rqmname(QM1) xmitq(QMHUB)
In case of failover:
on QM1:
alter qremote(QM2) xmitq(QMHUB2)
on QM2:
alter qremote(QM1) xmitq(QMHUB2)
_________________
Nicolas Maréchal
Senior Architect - Partner
NIMCONSULT Software Architecture Services (Belgium)
http://www.nimconsult.be |
|
| Back to top |
|
|
| bduncan |
| Posted: Fri Aug 09, 2002 7:27 am Post subject: |
|
|
Padawan
Joined: 11 Apr 2001
Posts: 1554
Location: Silicon Valley
|
Why do you think a cluster requires too much overhead?
_________________
Brandon Duncan
IBM Certified MQSeries Specialist
MQSeries.net forum moderator |
|
| Back to top |
|
|
| tso0rxp |
| Posted: Tue Aug 13, 2002 7:17 am Post subject: |
|
|
Voyager
Joined: 07 Jan 2002
Posts: 85
|
| I should have said 'administrative overhead'. |
|
| Back to top |
|
|
| bduncan |
| Posted: Tue Aug 13, 2002 3:24 pm Post subject: |
|
|
Padawan
Joined: 11 Apr 2001
Posts: 1554
Location: Silicon Valley
|
Well, when it is functioning properly, I think a cluster requires less administrative overhead since you have:
1) 1 transmission queue per queue manager
2) No static channel definitions
3) No remote queue definitions
And in scenarios where you have hundreds of queue managers, this means thousands fewer object defintions.
Of course, you'll notice in my first statement I qualified it with "functioning properly", because as many people have pointed out (and I must agree with them) clustering can be the source of much headache when things go awry - and it seems to happen all too often. Now I've heard that clustering under v5.3 is much improved, and a lot of my experience with clustering was on the v5.1 beta for linux, so it's probably become a lot more reliable since then...
_________________
Brandon Duncan
IBM Certified MQSeries Specialist
MQSeries.net forum moderator |
|
| Back to top |
|
|
| tso0rxp |
| Posted: Tue Aug 13, 2002 3:37 pm Post subject: |
|
|
Voyager
Joined: 07 Jan 2002
Posts: 85
|
| All suggestions good food for thought. Thanks for taking the time to come to my aid. Much appreciated. |
|
| Back to top |
|
|
|
|
