| Author |
Message
|
| sroach76 |
 Posted: Mon Sep 11, 2006 12:21 pm Post subject: WebSphere MQ 5.3 DR question |
 |
|
Novice
Joined: 11 Sep 2006
Posts: 15
|
Hello guys,
We are currently running WebSphere MQ 5.3 in production and I am trying to architect our DR solution for MQ. I need some help with my solution. We use persistant messaging in our environment. I will be creating duplicate queues,channels,configurations on our DR MQ Server. We also are going to use a third party data replication product to sync up the data between our production and DR environments. How do I determine where the MQ messages are stored locally on our production system? What else do I need to replicate to our DR site to be able to failover if needed and have the messages processed when I startup the DR site? Please give me some feedback about this solution if you have any. Thanks |
|
| Back to top |
|
 |
| bbeardsley |
| Posted: Mon Sep 11, 2006 12:41 pm Post subject: Re: WebSphere MQ 5.3 DR question |
|
|
Acolyte
Joined: 17 Dec 2001
Posts: 52
Location: Dallas, TX, USA
|
| sroach76 wrote: |
I will be creating duplicate queues,channels,configurations on our DR MQ Server. We also are going to use a third party data replication product to sync up the data between our production and DR environments.
|
If you are on unix (not sure about the other platforms, I'm guessing this wouldn't work on windows) and you copy the data and log directories to your DR server, or shared storage, you can bring up your qmgr by configuring the mq.ini and mqs.ini files on your DR server to look at the path were you are replicating the files.
| sroach76 wrote: |
| How do I determine where the MQ messages are stored locally on our production system? |
What platform are you on?
| sroach76 wrote: |
What else do I need to replicate to our DR site to be able to failover if needed and have the messages processed when I startup the DR site? |
You'll need to consider channels that send to this qmgr will have a dns or ip address defined, so your ip should 'float' over to your DR server, otherwise you would have to redefine and reset all of them. If your qmgr is in a cluster, a floating ip is a must. |
|
| Back to top |
|
|
| sroach76 |
| Posted: Mon Sep 11, 2006 12:48 pm Post subject: |
|
|
Novice
Joined: 11 Sep 2006
Posts: 15
|
| Thanks for the reply. We are running AIX 5.2. I am hoping to duplicate the directory structure between production and DR so hopefully the mq.ini and mqs.ini will look the same before a swing to DR. Do you know the details of what exact logs and files are needed to replicate? |
|
| Back to top |
|
|
| bbeardsley |
| Posted: Mon Sep 11, 2006 12:56 pm Post subject: |
|
|
Acolyte
Joined: 17 Dec 2001
Posts: 52
Location: Dallas, TX, USA
|
| sroach76 wrote: |
| Do you know the details of what exact logs and files are needed to replicate? |
I would replicate the same as if I were setting up failover, so you need:
/var/mqm/exits (if you are using exits)
/var/mqm/qmgrs/QMNAME (queue data, object definitions)
/var/mqm/log/QMNAME (logs - very important if you want your persistant messgages)
One little catch I've ran into - make sure your unix admin creates the mqm user/group with the same uid/gid on the DR box, or you'll run into permission problems.
If you are starting your listener with inetd, configure it on the DR server the same way. If you are starting your qmgr with an rc script, you'll need that too. |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Mon Sep 11, 2006 1:23 pm Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
If you are starting your listener with inetd, DON'T.
Your best bet is to configure this as an actual failover member in an HA resource group of some kind, and not try to "hand roll" this level of recovery using replication software and scripting.
This means that your shared disk needs to be available at your DR site.
Also remember that you can't take a good solid backup of a running queue manager, and you will most likely lose non-persistent messages that are in flight when you go to DR.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| bbeardsley |
| Posted: Tue Sep 12, 2006 5:47 am Post subject: |
|
|
Acolyte
Joined: 17 Dec 2001
Posts: 52
Location: Dallas, TX, USA
|
Jeff,
Since he is on 5.2, running amqcrsta within the inetd.conf file instead of runmqlsr is acceptable, especially if he has channel exits configured that might not execute properly with threaded channels. |
|
| Back to top |
|
|
| sroach76 |
| Posted: Tue Sep 12, 2006 5:48 am Post subject: |
|
|
Novice
Joined: 11 Sep 2006
Posts: 15
|
| Thanks for the great replies guys, really appreciate it. Do I need to worry about what type of logging we currently have configured, Circular or Linear? I read that Circular logging does not write objects to the logs and if we need to recover that the queue needed to be created with Linear logging. Is this true? Is there any other configuration that needs to be in place for the failover to work properly other than the startup scripts and userid notes you mentioned previously? |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Tue Sep 12, 2006 6:10 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
| bbeardsley wrote: |
Jeff,
Since he is on 5.2, running amqcrsta within the inetd.conf file instead of runmqlsr is acceptable, especially if he has channel exits configured that might not execute properly with threaded channels. |
He's running MQ v5.3 on AIX v5.2.
| sroach76 wrote: |
| We are currently running WebSphere MQ 5.3 in production |
| sroach76 wrote: |
| We are running AIX 5.2. |
| sroach76 wrote: |
| Do I need to worry about what type of logging we currently have configured, Circular or Linear? I read that Circular logging does not write objects to the logs and if we need to recover that the queue needed to be created with Linear logging. Is this true? |
No, it's not true. Circular logging does write objects to the log. BUT, YES, you must use Linear Logging if you want to use media recovery to restore a q file that has been corrupted.
Again, your best bet for all of this is to use HACMP and shared disk to handle this, and NOT to try and reinvent the wheel here. There is a very good support pack for MQ and HACMP - you may have to go to the withdrawn support pack page to find the v5.3 version.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| rtsujimoto |
| Posted: Tue Sep 12, 2006 6:34 am Post subject: |
|
|
Centurion
Joined: 16 Jun 2004
Posts: 119
Location: Lake Success, NY
|
| As an added note in support of using HACMP over replication is the possibility that you won't be able to start your queue manager at the DR site if you do use replication. During one of our DR exercises, we weren't able to start the queue manager. The AIX admin did a backup of the disk while MQ was still up and used that backup for the DR exercise. I suspect that there was some sort of discrepancy between the logs and the true state of the system that was captured. |
|
| Back to top |
|
|
| sroach76 |
| Posted: Wed Sep 13, 2006 12:07 pm Post subject: |
|
|
Novice
Joined: 11 Sep 2006
Posts: 15
|
Two more follow up questions if you guys can help.
1) Can you tell me which file/log under /var/mqm store the active persistant messages? Is it the active MQ log under /var/mqm/log/qmgr_name/active/*?
2) When the persistant messages are processed are they removed from this log or just marked completed and kept in the logs?
Thanks again for your expertise! |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Wed Sep 13, 2006 12:09 pm Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
Persistent messages are put to BOTH the /var/mqm/qmgrs/<qmgr>/log/.... files and to the appropriate /var/mqm/qmgrs/<qmgr>/queues/.../q file.
They are removed from the q file when the message is successfully removed from the queue.
They are never removed from the log file. Under circular logging, they are overwritten when the log rolls over past the same point.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| sroach76 |
| Posted: Thu Sep 14, 2006 5:09 am Post subject: |
|
|
Novice
Joined: 11 Sep 2006
Posts: 15
|
Thanks for the quick reply jeff!
To get my DR location MQ server online and processing messages are these the basic steps? Assuming all the configurations are the same and data has been replicated.
1) Manually sync the DR MQ sequence number with customer.
2) Startup MQ and it will look into each queue's q file to see if there are any persistant messages that have not been processed and it will process them.
3) Everything is then back to normal with MQ.
Is this true and there is nothing manual I need to do to tell MQ to check the q files and process what has not been processed yet when it is first started? |
|
| Back to top |
|
|
| maxis |
| Posted: Thu Sep 28, 2006 6:45 am Post subject: |
|
|
Centurion
Joined: 25 Jun 2002
Posts: 144
|
| In HACMP set-up, MQSeries queue managers are in cluster, how does Active-Active scenario works ? .... In the event of failure of a one node, how would the second node be able to pick up the messages of failed noe ? .... |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Thu Sep 28, 2006 6:58 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
In HACMP configuration, MQ file systems that hold messages are stored on shared disk.
During failover, the same disk is made available to the other machine, and the "same" queue manager starts up on that other machine.
The only difference between active-active and active-passive is that there's already something running on the "failover" machine in an active-active setup.
Please read the documentation that comes with the HA Support Pack. It should be very helpful.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| maxis |
| Posted: Fri Sep 29, 2006 1:53 am Post subject: |
|
|
Centurion
Joined: 25 Jun 2002
Posts: 144
|
Hi jeff ..
I read the documentation - MC91, it has cleared explained about Active-Passive. But has not given much info about Active-Active set-up. In the event of fail over, what will happen to the messages on the failed node Queue manager ? When will it served ? Active node wont be having failed node queue manager replica, even if takes over the failed node it wont be much beneficial ? ..
or is it just am complicating things ? .. is there simpler solution ? |
|
| Back to top |
|
|
|
|
