AW: Feedback on Disaster recovery

[Kleinmanns, Hubert]

Title: Feedback on Disaster recovery

Hi Rao,

 

a possible alternative to Sun clustering would be, to put the "/var/mqm" path onto a SAN storage.

 

Disk mirroring might not be a practicable solution, because during the queue manager is running, the files in /var/mqm/qmgrs and /var/mqm/log may be insonsistent. Stopping queue managers, archiving the volume /var/mqm, restoring this archive on another machine and starting the queue manager on the other machine would work, but the data may be not up to date.

 

Regards

Hubert Kleinmanns

 

-----Ursprüngliche Nachricht-----
Von: Adiraju, Rao [mailto:[EMAIL PROTECTED]
Gesendet: Dienstag, 24. Februar 2004 00:00
An: [EMAIL PROTECTED]
Betreff: Feedback on Disaster recovery

As part our disaster recovery, we have dedicated one additional box for every production box (on Sun-Solaris) as a Diaster Recovery machine. 

The current practice is to define two distinct queue managers on these two machines and when things go wrong on the main box, changing all partners to talk to the backup box.  Even though this provides continuos availability with minimal interruption, we are loosing business continuity. Some messages are sitting in queue manager on (dead) main box, which aren't getting processed and applications that have message sequencing dependency are getting stuffed.

The revised plan is - utilising disk mirroring (which is all ready in place)   maintain the same queue manager name & objects on both the machines.  Only one instance of QMGR will be up and running at any given time. When main box goes down, DNS entries will be changed to swap the logical definitions of the boxes, so that partners will talk to the backup box using the same old connection definitions.

Back up box, being using the same data - ie: Qmgr name, object definitions, transmission queues, channel Synchronisation queues, logs etc.. will pick up the processing where the main box dropped off.

This way we can assure "GUARANTEED, ONCE ONLY and FIFO"  objectives.

Any comments, suggestions, pitfalls of this approach are appreciated. If there any proven better ways I would like to hear. At the moment we don't (nor planning) use Solaris clustering facility.

Thanks in advance

Rao Adiraju
WebSphere MQ Specialist
The National Bank of NZ Ltd.
Wellington - New Zealand
Tel:  +64-4-494 4299
Fax: +64-4-802 8509
Mbl: +64-211-216-116

 

This communication is confidential and may contain privileged material.  If you are not the intended recipient you must not use, disclose, copy or retain it.  If you have received it in error please immediately notify me by return email and delete the emails.
Thank you.