| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
  |
|
| Cold standby |
« View previous topic :: View next topic » |
| Author |
Message
|
| ahes |
 Posted: Sat Jul 13, 2002 1:28 am Post subject: Cold standby |
 |
|
Newbie
Joined: 13 Jul 2002
Posts: 7
|
We have an application running on a AIX machine with a cluster queue on it. To tackle hardware failures we will use HACMP in the future. But for the near future we want to use a cold standby.
What is the best approach to achieve this?
Have he same queue manager name on both machines?
If you do that , when does the repository know that the cluster queue moved to a machine with another ip address?
How about messages being sent while we switch?
Alex |
|
| Back to top |
|
 |
| bduncan |
| Posted: Sat Jul 13, 2002 8:59 am Post subject: |
|
|
Padawan
Joined: 11 Apr 2001
Posts: 1554
Location: Silicon Valley
|
Alex,
On the cold standby, simply create a queue manager with a different name, and add it to the cluster. Then create a clustered queue with the same name as the queue on the live machine. Make sure the clustered queue is put disabled when you create it, or messages may get routed there automatically because of workload balancing. Now you have the option of stopping this queue manager, or you can leave it running. Either way, no messages will get routed to it.
Now, when the live queue manager goes down, you'll have to bring up the cold standby. This involves starting the queue manager and/or put enabling the clustered queue. The moment you do this (assuming your applications are putting the messages using MQOO_BIND_NOT_FIXED) messages will begin to flow to this instance of the queue.
To answer your question, the cluster queue doesn't "move", it's just that a new instance of it is available (and the old instance is not). The repository knows about this change immediately, because the repository has known about the other instance of the clustered queue ever since you created it. Other queue managers in the cluster knew not to route messages there though because it was put disabled. The moment you put enable it, all the queue managers in the cluster will be informed of this immediately, and being routing messages there. Similarly, because the old instance of the queue is no longer available because the live queue manager went down for some reason, messages won't be sent there any longer.
_________________
Brandon Duncan
IBM Certified MQSeries Specialist
MQSeries.net forum moderator |
|
| Back to top |
|
|
| ahes |
| Posted: Sat Jul 13, 2002 11:25 am Post subject: |
|
|
Newbie
Joined: 13 Jul 2002
Posts: 7
|
Thanks bduncan,
this looks like a good (and simple) way to achieve my goal.
Alex |
|
| Back to top |
|
|
| bmccarty |
| Posted: Wed Aug 21, 2002 6:57 pm Post subject: |
|
|
Apprentice
Joined: 18 Dec 2001
Posts: 43
|
How do you use a auto-started program to enable put's to the cold queue manager? Basically if there is auto-notification that the first queue manager is hosed, somehow, then how to you have a script enable the second one?
Any details would be appreciated.
Thanks,
B |
|
| Back to top |
|
|
| nimconsult |
| Posted: Wed Aug 21, 2002 10:55 pm Post subject: |
|
|
Master
Joined: 22 May 2002
Posts: 268
Location: NIMCONSULT - Belgium
|
The solution proposed by Brandon is the most straightforward, but only if you are ready to loose messages in case of failure.
If you do not want to loose messages, without using a clustering (like HACMP) solution, the implementation is a little more complex.
What you can do is to mount the queue manager data and log directory (or the entire data and log directory structures) on a shared disk (usually RAID), visible from both the "active" machine and the "cold standby" machine. In case of crash you mount the directory on the "cold standby" machine and restart the queue manager. All your data will be recovered smoothly. What about the IP adress? My advice would be not to work with IP adresses, but with logical names. In case of crash, you change your DNS to move the IP adress to the "cold standby" machine.
This description is maybe a little complex and described briefly, but I am implementing it for my current client who has the same requirements.
_________________
Nicolas Maréchal
Senior Architect - Partner
NIMCONSULT Software Architecture Services (Belgium)
http://www.nimconsult.be |
|
| Back to top |
|
|
| jc_squire |
| Posted: Thu Aug 22, 2002 5:08 pm Post subject: |
|
|
Centurion
Joined: 14 Apr 2002
Posts: 105
Location: New Zealand
|
IBM also supply a sample cluster workload exit that can route all messages to a specific queue manager and if that queue manager is not available it will direct messages to the second queue manager. Look at page 45 of the cluster manual.
Regards
_________________
J C Squire
IBM Certified Specialist - MQSeries |
|
| 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
|
|
|
|
