ASG
IBM
Zystems
Cressida
Icon
Netflexity
 
  MQSeries.net
Search  Search       Tech Exchange      Education      Certifications      Library      Info Center      SupportPacs      LinkedIn  Search  Search                                                                   FAQ  FAQ   Usergroups  Usergroups
 
Register  ::  Log in Log in to check your private messages
 
RSS Feed - WebSphere MQ Support RSS Feed - Message Broker Support

MQSeries.net Forum Index » IBM MQ Installation/Configuration Support » WMQ and IIB DR concept/Ideas

Post new topic  Reply to topic
 WMQ and IIB DR concept/Ideas « View previous topic :: View next topic » 
Author Message
JanB_193
PostPosted: Wed Oct 22, 2014 4:00 am    Post subject: WMQ and IIB DR concept/Ideas Reply with quote

Novice

Joined: 22 Aug 2014
Posts: 15

Hello all

Our shop has a running Installation of WMQ and IIB which I currently try to set up in a more controlled manner. Since our SLAs are fairly low - an outage of up to 24h is tolerated - and virtually no MQ know-how is available in our operating departement. I'm forced to take small steps and live with some constraints. Currently there is no dedicated backup or DR strategy around for the MQ environment. After all so far everthing has run smooth for 2 years, so why....

So I have a setup with three productive QMs WMQ V8 each with a MB (IIB V9) together one one virtual machine (Windows). All QMs with circular logging, no MQ clustering, no HW clustering.

I'm now considering at least to introduce regular backups of the QMs and Brokers as well as regular snap-shots of the VMWare Image.

As far as I understand a proper backup of a QM requires that it is stopped where as a Broker can be backed up while running (w/o config changes going on). Right?

Do I have to expect problems if I take snapshots of the VM while ist up an running?

And generally what options do I have in my scenario, apart from above mentioned? Backup QMs are only possible with linear logs and clustering is considered too expensive. Any other suggestions/Ideas?

Thanks in advance

Jan
Back to top
View user's profile Send private message
fjb_saper
PostPosted: Wed Oct 22, 2014 4:27 am    Post subject: Reply with quote

Grand High Poobah

Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY

Have you looked into the "Multi-Instance" option for MQ and IIB?
_________________
MQ & Broker admin
Back to top
View user's profile Send private message Send e-mail
PeterPotkay
PostPosted: Wed Oct 22, 2014 4:35 am    Post subject: Reply with quote

Poobah

Joined: 15 May 2001
Posts: 7722

Typically a site used for DR is going to be farther away than what's going to be feasible to use for the second instance of the Multi Instance QM.

For High Availability, OK. But not for real DR unless your DR Data Center is close enough to allow synchronous updates of data.

Jan,
Check out the Disaster Recover presentation here:
http://www.mqtechconference.com/sessions.html

Use dmpmqcfg to take object definition backups of your queue managers while they run. Store them and your IIB backups NOT on the same servers as your QMs and Brokers. This is so you can manually rebuild the QM and Broker if all else fails. Replicate the storage that holds these backups off site. Include the info in the qm.ini file in these backups. Ideally you build your QM via a script - have backups of that script.

Talk to your VMware team about getting that VMWare session replicating asynchronously to your DR data center for DR.
Talk to them about snapshot backups at the storage layer for taking backups of the VMware server while it and MQ run unaware of the backup.
_________________
Peter Potkay
Keep Calm and MQ On
Back to top
View user's profile Send private message
JosephGramig
PostPosted: Wed Oct 22, 2014 5:01 am    Post subject: Reply with quote

Grand Master

Joined: 09 Feb 2006
Posts: 1244
Location: Gold Coast of Florida, USA

The consequence of using Circular Logging is that you are OK with loosing all the msgs on a queue (even if they are persistent), if the queue object becomes damaged. A queue object can get damaged when SAN gets jerked out from under the Qmgr or somebody/process modifies the file somehow.
Back to top
View user's profile Send private message AIM Address
PeterPotkay
PostPosted: Wed Oct 22, 2014 5:37 am    Post subject: Reply with quote

Poobah

Joined: 15 May 2001
Posts: 7722

If the SAN gets jerked out from the QM, you are still vulnerable with Linear Logging, presumably because there is no better place to put your logs than on the SAN, same as your queue files. Yeah, you may win the battle and get those SAN guys to segregate your q storage from your log storage, but if you are still on the same frame being accessed by the same fiber, I would bet any problem severe enough to fry your q files is going to blitz those logs anyway.

Yes, there can surely be a scenario where the q object is damaged AND the linear log is fine AND the queue had messages in it AND the messages were important AND the application had no way of recreating the message (wait, who started using MQ is the system of record?).

I wonder, if MQ was just a twinkle in Father MQ's eye in Q4 2014, and they were designing it from the ground up aware of all the advancements with storage technology, would they even offer a Circular / Linear option?
_________________
Peter Potkay
Keep Calm and MQ On
Back to top
View user's profile Send private message
JanB_193
PostPosted: Wed Oct 22, 2014 10:59 pm    Post subject: Reply with quote

Novice

Joined: 22 Aug 2014
Posts: 15

Thanks for the answers.

As clustering and HA is considered to expensive options like Multiinstance QMS will not be feasible.

So I guess I'll have to start with regular backups and prepare scripts to rebuild the environment in case of a disaster.

After such a case I presume, that the other options will become more accepted...

Regards Jan
Back to top
View user's profile Send private message
exerk
PostPosted: Wed Oct 22, 2014 11:27 pm    Post subject: Reply with quote

Jedi Council

Joined: 02 Nov 2006
Posts: 6339

JanB_193 wrote:
...So I guess I'll have to start with regular backups and prepare scripts to rebuild the environment in case of a disaster.

After such a case I presume, that the other options will become more accepted...

That's the spirit! Just make sure you have a huge 'I told you so' grin on your face when it happens. Frustrating though it is, remember that whilst your employers pay you for your skills and advice they're not obligated to use them.
_________________
It's puzzling, I don't think I've ever seen anything quite like this before...and it's hard to soar like an eagle when you're surrounded by turkeys.
Back to top
View user's profile Send private message
Vitor
PostPosted: Thu Oct 23, 2014 4:47 am    Post subject: Reply with quote

Grand High Poobah

Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA

exerk wrote:
JanB_193 wrote:
...So I guess I'll have to start with regular backups and prepare scripts to rebuild the environment in case of a disaster.

After such a case I presume, that the other options will become more accepted...

That's the spirit! Just make sure you have a huge 'I told you so' grin on your face when it happens. Frustrating though it is, remember that whilst your employers pay you for your skills and advice they're not obligated to use them.


Also ensure that you have a document (indeed several copies of a document) in which you lay out clustering and HA as options, with supporting documentation on when it was ruled too expensive and by whom. One of the well known effects of a disaster is post-traumatic management amnesia, where none of the management can remember being told the cheap DR they'd agreed to was insufficient or indeed remember any other option being discussed with them.

Not only can such documentation save your job and your career, it's really good fun to produce it in the post-mortum meeting and watch them squirm. If you can bear to wait until they've done the speech about "unforeseen failings in the recovery strategy" and "need to undertake an urgent investigation into other options", it will make your day and ruin theirs.

I speak from experience
_________________
Honesty is the best policy.
Insanity is the best defence.
Back to top
View user's profile Send private message
smdavies99
PostPosted: Thu Oct 23, 2014 5:02 am    Post subject: Reply with quote

Jedi Council

Joined: 10 Feb 2003
Posts: 6076
Location: Somewhere over the Rainbow this side of Never-never land.

Vitor wrote:

Not only can such documentation save your job and your career, it's really good fun to produce it in the post-mortum meeting and watch them squirm. If you can bear to wait until they've done the speech about "unforeseen failings in the recovery strategy" and "need to undertake an urgent investigation into other options", it will make your day and ruin theirs.

I speak from experience


I know of a system located on the West Coast of the USA where the Management spent $500M on the building but were too mean to make a system that is essential to the smooth operation of the whole place resilient. The whole place could have to revert to Paper for everything if this one system fails. All for less than $500K total costs.

Needless to say six months after go live, a PSU Failed. 19hours later it was back running. But, and here is the rub, the beancounters decided that this was ok, as long as the outage was under 24hours and less than once a year and despite the outage costing more than $1M.

I left their employ the next month for obvious reasons.

What Vitor is saying is 100% correct. Protect your own back.
_________________
WMQ User since 1999
MQSI/WBI/WMB/'Thingy' User since 2002
Linux user since 1995

Every time you reinvent the wheel the more square it gets (anon). If in doubt think and investigate before you ask silly questions.
Back to top
View user's profile Send private message
JanB_193
PostPosted: Thu Oct 23, 2014 6:23 am    Post subject: Reply with quote

Novice

Joined: 22 Aug 2014
Posts: 15

Thanks a lot for all the good advice - having worked in a very large and well known IT company I know about the importance of "CYA" documents...
So those will be in place ASAP.

In the meantime I've digged through a lot of material reg. backup and recovery of MQ/IIB. And I understand that it normally makes more sense to backup only the definitions needed te recreate the environment in a fairly quick way if need be and forget about using a snapshot of the QM with messages in the queues

I plan this approach:
1. create scripts to create all MQ artefacts like QM, Queues, channels etc. from scratch
2. have the right stuff backed up to then update the created environment with all configuration changes
3. (possibly, but presumably rather not) recreate the queue content from log backups

Now my questions:
1. As most of the references in the web refer to Unix installations I wonder if I got all I need for Windows? I planned to stop the QM every night (somebody mentioned 3:30 am which sounds good to me) and backup the following directories for object definitions:
C:\...\IBM\WMQ\Qmgrs\@SYSTEM
C:\...\IBM\WMQ\Qmgs\<QMNAME>
and this for the logs:
...\IBM\WMQ\log\<QMNAME>

Is that enough or am I missing vital parts, which I will need for a rebuild?

2. As mentioned before we use circular logging. So rcdmqimg doesn't work for me. Does a backup of the logs make any sense at all then, or do I just live with the fact that any messages might be lost? This last one might sound stupid, but I'm somewhat confused about this.

Regards Jan
Back to top
View user's profile Send private message
JosephGramig
PostPosted: Thu Oct 23, 2014 9:16 am    Post subject: Reply with quote

Grand Master

Joined: 09 Feb 2006
Posts: 1244
Location: Gold Coast of Florida, USA

Check your windows Qmgr to see if it has a qm.ini file. Older ones will not and in that case, you need to get/set the Qmgr stanzas with amqmdain commands.
Back to top
View user's profile Send private message AIM Address
Display posts from previous:   
Post new topic  Reply to topic Page 1 of 1

MQSeries.net Forum Index » IBM MQ Installation/Configuration Support » WMQ and IIB DR concept/Ideas
Jump to:  



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
Protected by Anti-Spam ACP
 
 


Theme by Dustin Baccetti
Powered by phpBB © 2001, 2002 phpBB Group

Copyright © MQSeries.net. All rights reserved.