| Author |
Message
|
| JosephGramig |
 Posted: Wed Feb 11, 2015 7:07 am Post subject: Backup Qmgr for DR |
 |
|
Grand Master
Joined: 09 Feb 2006
Posts: 1244
Location: Gold Coast of Florida, USA
|
I know a lot of folks have been using some kind of file replicator to try to create DR resources, but it seems clear to me that if you cannot backup a running Qmgr, then replicating the resources also would not be supported.
Reading the Backup Qmgr section in the Backing up and restoring WebSphere® MQ queue manager data, it seems clear what the instructions are:- Create backup Qmgr with same options
- Copy all data and log directories from a stopped Qmgr to the DR
- Then follow the procedure to advance and copy logs to DR periodically (which is done while the Qmgr is running)
- Play the logs forward at the DR
So what I'm wondering is how the use of MS0L (linear log file maintenance) will affect what needs to be copied or played forward.
Should I record media objects and archive before I do the Backup Qmgr procedure or after?
I'm sure I should put the Archive on the shared storage. BTW, I'm doing this on WinServ12 and MQ 7.5 and I'm also doing MI. The DR CIFS UNC is different and needs a Backup Qmgr style configuration. |
|
| Back to top |
|
 |
| fjb_saper |
| Posted: Wed Feb 11, 2015 8:17 am Post subject: Re: Backup Qmgr for DR |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
| JosephGramig wrote: |
So what I'm wondering is how the use of MS0L (linear log file maintenance) will affect what needs to be copied or played forward.
Should I record media objects and archive before I do the Backup Qmgr procedure or after? |
Definitely before. Also run it before running MS0L.
Once you have run the media archive program (rcdmqimg) you can look at the files that are going to be archived. They need to be applied to the backup qmgr if they have not been. Also look at the qmstatus to look at the current in use log file. To keep the backup qmgr most current you should be able to apply all of the log files but for the current in use one. To apply that one the qmgr should be stopped first.
| JosephGramig wrote: |
I'm sure I should put the Archive on the shared storage. BTW, I'm doing this on WinServ12 and MQ 7.5 and I'm also doing MI. The DR CIFS UNC is different and needs a Backup Qmgr style configuration. |
Don't get what you want to convey with this information. 
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| JosephGramig |
| Posted: Wed Feb 11, 2015 8:40 am Post subject: |
|
|
Grand Master
Joined: 09 Feb 2006
Posts: 1244
Location: Gold Coast of Florida, USA
|
fjb_saper,
OK, I think I get it:
- rcdmqimg
- Advance the log file
- Get the current log file name
- Copy all logs up to but not including current log file
- At DR, play logs forward
- At active, run the Java program to archive the log files (and that ZIP is what needs to be on the share UNC)
But what I don't see is also archiving log files at DR. So is that another run of the Java program there too? If so, I guess the ZIP archive does not need to be on the share... |
|
| Back to top |
|
|
| zpat |
| Posted: Wed Feb 11, 2015 8:52 am Post subject: |
|
|
Jedi Council
Joined: 19 May 2001
Posts: 5866
Location: UK
|
The easiest thing to do is let your SAN layer replicate the disk subsystem.
We use SRDF and it works perfectly.
_________________
Well, I don't think there is any question about it. It can only be attributable to human error. This sort of thing has cropped up before, and it has always been due to human error. |
|
| Back to top |
|
|
| JosephGramig |
| Posted: Wed Feb 11, 2015 9:51 am Post subject: |
|
|
Grand Master
Joined: 09 Feb 2006
Posts: 1244
Location: Gold Coast of Florida, USA
|
| zpat wrote: |
The easiest thing to do is let your SAN layer replicate the disk subsystem.
We use SRDF and it works perfectly. |
Unless you have synchronous hardware writes, that is not a supported way to backup or replicate a Qmgr. The queue files and logs will be out of sync. It is the same issue of trying to backup a running Qmgr. Not supported. |
|
| Back to top |
|
|
| Vitor |
| Posted: Wed Feb 11, 2015 10:01 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| JosephGramig wrote: |
| Unless you have synchronous hardware writes, that is not a supported way to backup or replicate a Qmgr. The queue files and logs will be out of sync. It is the same issue of trying to backup a running Qmgr. Not supported. |
Well in fairness SRDF does have exactly that, at it's as "supported" as the vendor's promise that SAN is replicated correctly. If you've mirrored the files someplace, MQ doesn't know it's looking at a mirror and the integrity (or not) of the queue manager is as good as the integrity of the files.
Which brings us back to the vendor.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| JosephGramig |
| Posted: Wed Feb 11, 2015 10:44 am Post subject: |
|
|
Grand Master
Joined: 09 Feb 2006
Posts: 1244
Location: Gold Coast of Florida, USA
|
Vitor and zpat,
Maybe so with what you've got. I have Windows and SMB (CIFS) and the replication is with SnapMirror. The replication was based on a schedule.
Using a Backup Qmgr for DR is also based on a schedule, but I'm assured it will come up at least to where ever I advanced the log last (and got the logs to the DR Backup Qmgr). |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Wed Feb 11, 2015 12:31 pm Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
SRDF is synchronous. Supported. SRDF/A, which is typically used for DR, which is async, would not.
Are these servers virtual servers?
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| zpat |
| Posted: Thu Feb 12, 2015 12:02 am Post subject: |
|
|
Jedi Council
Joined: 19 May 2001
Posts: 5866
Location: UK
|
We use SRDF/S for DR (synchronous).
It does reduce the persistent message throughput rate somewhat, but it's still acceptable.
_________________
Well, I don't think there is any question about it. It can only be attributable to human error. This sort of thing has cropped up before, and it has always been due to human error. |
|
| Back to top |
|
|
| JosephGramig |
| Posted: Thu Feb 12, 2015 7:26 am Post subject: |
|
|
Grand Master
Joined: 09 Feb 2006
Posts: 1244
Location: Gold Coast of Florida, USA
|
Peter,
These are Windows 2012 Servers on VMs. Two in one city as MI and two in another city as non-running MI for DR. All with IIB. I'm not sure if what device is serving the SMB (CIFS) file system, but to me it just looks like a UNC. I will ask if the admins know if the device can support SRDF/S.
BTW, just discovered that MS0L expects the Qmgr data to be on a particular path because it hard coded part of the path (<path>\Qmgrs\<QmgrName>). Not too MQ 7.1 and greater friendly. |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Thu Feb 12, 2015 8:03 am Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
| JosephGramig wrote: |
Peter,
These are Windows 2012 Servers on VMs. Two in one city as MI and two in another city as non-running MI for DR. All with IIB. I'm not sure if what device is serving the SMB (CIFS) file system, but to me it just looks like a UNC. I will ask if the admins know if the device can support SRDF/S.
BTW, just discovered that MS0L expects the Qmgr data to be on a particular path because it hard coded part of the path (<path>\Qmgrs\<QmgrName>). Not too MQ 7.1 and greater friendly. |
Make sure you have the latest version of MS0L.
Then look at setting the variables in mqllm.bat or before....
Make also sure you comment out all the registry stuff (valid for 7.0 only).
Add the -f flag and directory to your setup.
And the \Qmgrs\<qmname> is configurable with one of the parms...
This will decide whether or not you will have Qmgrs...in the path...
Works like a charm...
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Thu Feb 12, 2015 8:05 am Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
Joseph,
Take a read on this thread:
http://www.mqseries.net/phpBB2/viewtopic.php?t=57940&start=0
Then apply that line of thought to asynchronous replication of your virtual servers at the SAN layer, not at the individual virtual server layer or at the MQ layer.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
|
|
