| Author |
Message
|
| Roadie |
 Posted: Tue May 08, 2007 9:09 pm Post subject: WMQ Disaster Recovery Design & Implementation |
 |
|
Newbie
Joined: 21 Aug 2006
Posts: 8
|
| Has anyone designed, implemented, and tested/used an MQ disaster recovery capability for Z/OS queue managers? I am interested in learning the issues, design points, methods, and tools used to implement a hot-standby capability for queue managers where primary production environment and the hot-standby environment are geographically separate. Goal is not to lose, nor orphan, any messages in the process of failover to the hot-standby (or come as close to this goal as possible). Any constructive input appreciated. |
|
| Back to top |
|
 |
| jefflowrey |
| Posted: Wed May 09, 2007 2:01 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
I believe z/OS has a unique feature that allows you to store a duplicate set of recovery/transaction logs. That is, basically, two log directories. This then allows you to put one set for every qmgr at both sites.
Other than that, I'm not a z/OS person. So that's as much help I can be. I'm sure zPat will have some suggestions.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| KathyB |
| Posted: Wed May 09, 2007 5:08 am Post subject: |
|
|
Apprentice
Joined: 02 Feb 2004
Posts: 30
|
We have decided, here, not to restore messages and to cold start all of our queue managers due to the possibility of having messages that were already received be sent again. We thought there could be some legal issues having to do with that, hence our decision to start cleanly.
However, there is an entire section devoted to recovery at an alternate site that you can find in the System Admin Guide. I played around with it here and got it to work but never tested it at a remote site. Hope this helps. |
|
| Back to top |
|
|
| kevinf2349 |
| Posted: Thu May 10, 2007 6:28 pm Post subject: |
|
|
Grand Master
Joined: 28 Feb 2003
Posts: 1311
Location: USA
|
| If you have a coupling facility then look into queue sharing groups |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Fri May 11, 2007 1:40 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
| kevinf2349 wrote: |
| If you have a coupling facility then look into queue sharing groups |
Not across a long WAN link...
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| kevinf2349 |
| Posted: Fri May 11, 2007 5:48 am Post subject: |
|
|
Grand Master
Joined: 28 Feb 2003
Posts: 1311
Location: USA
|
True but I guess it depends on what it meant by geographically seperate. I was assuming (dangerous I know) that they already have a hot stand by z/os system and the only way to really do that 100% would be with a coupling facility.
Maybe the original poster can clarify the details some more? |
|
| Back to top |
|
|
| Roadie |
| Posted: Fri May 11, 2007 5:58 am Post subject: |
|
|
Newbie
Joined: 21 Aug 2006
Posts: 8
|
| Geographically separate means "on different continents" (i.e. North America and Europe). Long-haul communications in between. |
|
| Back to top |
|
|
| kevinf2349 |
| Posted: Fri May 11, 2007 6:00 am Post subject: |
|
|
Grand Master
Joined: 28 Feb 2003
Posts: 1311
Location: USA
|
Thanks.....that does the CF answer then.  |
|
| Back to top |
|
|
| seanb |
| Posted: Wed May 16, 2007 4:15 am Post subject: |
|
|
Apprentice
Joined: 02 Aug 2003
Posts: 39
|
We use PPRC quite successfully here. We have tested (daily restarting plus an annual DR test) restarting MQ and all our applications with data FLASHCOPIED from the PPRC data sent to the remote site. We have a queue sharing environment and sometimes get DB2 errors when bringing up the QM at the DR site but they have been easily fixed by the DBA'S. We sometimes receive CF errors but they too are easy to correct (by recovering the CF from the log files). Prior to placing all the MQ files onto their own volumes and PPRC consistency groups we would quite often end up with corrupt logs at the DR site (and not be able to start the QM) but that is no longer a problem either.
Our previous method involved sending tapes regularly to the DR site. We would be able to start the QM without any problems so long as we backed up the files in the correct order, but this wouldn't meet your goal. Seeing as MQ messages tend to have a very short life (depends on your application of course) you may find that this ok. Keep in mind that it may be acceptable to your business to have some data loss at a DR site. This is different from your main site where data loss is unacceptable; here you can use dual logging.
As part of your strategy don't forget to run a regular MAKEDEF to extract all the definitions and ensure you have the required JCL to cold start your queue manager at the DR site (should your backup files not work - you may find your logs not always in a consistent state). As KathyB mentioned it may be just as easy and effective to simply cold start your QM at the DR site (so long as you have up-to-date QM definitions and not too many QM’S).
Don't forget to ensure you use hostnames on all your channels and/or to block production IPS at your DR site to ensure you don't accidentally try to connect your DR site to your real production site. It also gives ‘peace of mind’.
Be careful storing the dual copy of your log files at a remote site or on tapes. Should there be a problem (eg. the line to the remote site is down) and MQ is prevented from offloading the active logs you may have a problem.
Remember, from a data loss perspective, it may be important for you to keep the MQ recovery plan in sync with your application and database recovery plan. There is no point taking a MQ backup now if your database is backed up an hour later. You may recover all the MQ messages only to have to answer the important question ‘Do I really want to process them or have the already been processed?’ A tough question if you’re a financial institution! |
|
| Back to top |
|
|
| Roadie |
| Posted: Tue Jun 05, 2007 7:23 pm Post subject: |
|
|
Newbie
Joined: 21 Aug 2006
Posts: 8
|
| Thanks to everyone who responded. I will monitor this thread from time-to-time for new info. Your input is appreciated. |
|
| Back to top |
|
|
|
|
