|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
 |
|
Contingency enviroment with mq clusters |
« View previous topic :: View next topic » |
Author |
Message
|
yonny |
Posted: Tue Nov 18, 2003 11:51 am Post subject: Contingency enviroment with mq clusters |
|
|
 Apprentice
Joined: 08 Jul 2001 Posts: 49 Location: Santo Domingo
|
Enviroment:
Production as/400 Box1 QMGR01 running
Contingency as/400 Box2 QMGRx stand by
Within an mq cluster I have QMGR01 running over AS/400. In the event of a fatal failure other qmgr, in a separate box, should replace the as/400 qmgr. Both qmgrs have the same queues. How can I make the cluster to recognize the backup qmgr? I am confused because the contingency as/400 box will take the ip address of the production box, and that will be a problem with the channel definitions if I use two differente qmgrs.
Is it posible to use the same name for both qmgrs? I tried that but I got a problem with the QMID.
Any ideas will be apreciated.
Yonny R. Serrano
GBM Dominicana |
|
Back to top |
|
 |
emiranda |
Posted: Wed Nov 19, 2003 5:09 am Post subject: |
|
|
 Disciple
Joined: 21 Nov 2002 Posts: 196 Location: Dublin, Ireland
|
yonny,
First of all, if you meant Queue Manager Cluster definitions, it's not for this purpouse. If you meant cluster configuratio (hardware and software), need more details:
- Are the both, production and contigency boxes running?
- Do they have external storage? _________________ Warm Regards,
EM |
|
Back to top |
|
 |
yonny |
Posted: Wed Nov 19, 2003 7:33 am Post subject: |
|
|
 Apprentice
Joined: 08 Jul 2001 Posts: 49 Location: Santo Domingo
|
I meant MQSeries Clusters, and the mqcluster is defined and running for a few months ago.
The requirement is to configure a new qmgr to join the cluster automatically in the event of a fatal failure. This new qmgr should run over a "Contingency As/400 box" and is destined to replace an already running qmgr in the "Production As/400 box".
The contingengy box is standing by and has all the resources of the prod box, including among them the mqseries qmgr. What is giving me a headache is that the contingency box will take the ip address of the prod box.
If I create the new qmgr with the same name that the prod qmgr, I will have problems with the qmid. If I use a different name for the new qmgr I will have conflicts with the connname of the (manual and automatic) channels in the qmgrs that belongs to the mqcluster.
Sorry If I am not very clear but my english is not very good.
Thank you,
Yonny. |
|
Back to top |
|
 |
emiranda |
Posted: Wed Nov 19, 2003 9:41 am Post subject: |
|
|
 Disciple
Joined: 21 Nov 2002 Posts: 196 Location: Dublin, Ireland
|
Hi yonny
I don't encourage the mqcluster for "take over" purpouses. It's much more an administration issue, workload management, than a recovery one.
What you need is a hw/sw cluster, an "HACMP kind" or "MSCL" kind, so you can configure 2 qm (separeted boxes) point to "the same group of queues" phisicaly located in a external storage (must be an external stogare), so one qm will be running and the other, stoped. When the running qm stops, the 2nd one takes over the control, looking to the SAME QUEUES the 1st looked.
Better you take a good look over the WebSphere MQ Queue Manager Clusters manual.
Luck  _________________ Warm Regards,
EM |
|
Back to top |
|
 |
PeterPotkay |
Posted: Wed Nov 19, 2003 10:36 am Post subject: |
|
|
 Poobah
Joined: 15 May 2001 Posts: 7722
|
Yonny, for what you are trying to do, MQ Clusters are not the solution. MQ Clusters do not apply at all.
What you need is hardware clustering. I will explain it based on my experience with Windows Hardware clustering, which is how we support our Production Hub QM.
ServerA is your primary server. ServerB is set up as a backup server. The hardware clustering software manages the disk for both servers in a shared array that is highly available.
If ServerA dies, the hardware clustering software moves all the files and data (called resources) over to ServerB.
Your queue manager would just be a resource. Create QM1 on ServerA. You will go thru some routine where you will register QM1 on ServerB as well. How this happens depends on your platform.
When things are working fine, QM1 is running on ServerA. All incoming channels refer to the DNS name of the shared disk (not ServerA). When ServerA crashes, QM1 is brought up on ServerB, and all channels will reconnect at their next reconnect interval (remember, they are still pointing to the DNS name of the shared disk, which is valid for QM1 regardless of where it runs). The failover takes about a minute on the Windows solution for this. Your platform will be different.
If you need MQClustering on top of this as well, for other queue managers, you can implement it as well with no problems, because the QMID for QM1 is the same whether it is running on Server1 or 2. But you have not given a reason to use MQClustering. You only need hardware clustering from your description. _________________ Peter Potkay
Keep Calm and MQ On |
|
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
|
|
|
|