Author |
Message
|
pasha.mq |
Posted: Wed Sep 12, 2012 3:35 pm Post subject: Changing log path to a NFS mounted filesystem gives AMQ7064 |
|
|
Newbie
Joined: 12 Sep 2012 Posts: 9
|
Hi,
I am trying to start a qmgr(TESTQMGR) by having the log and qmgr data directories in the remote storage on the shared network drive. I updated the mqs.ini and qm.ini file to the correct location.
I have provided mqm authority to the log and qmgr directories on the remote storage.
When I start the qmgr(TESTQMGR), I am getting the below error.
AMQ7064: Log path not valid or inaccessible
However, If I just run with the log file on the local fs under /var/mqm/log directory and qmgrs on the remote storage, it works fine.
I tried all i could think of.. Please help..
MQ Config: I am running MQ 7.0.1.5 on SUSE Linux.
mqs.ini looks like this..
Code: |
DefaultPrefix=/var/mqm
LogDefaults:
# LogDefaultPath=/var/mqm/log
LogDefaultPath=/nfs/mqmgrlogsdev/log
QueueManager:
Name=TESTQMGR
#* Prefix=/var/mqm
Prefix=/nfs/mqmgrdev
Directory=TESTQMGR
|
The qm.ini looks like this ..
Code: |
ExitPath:
ExitsDefaultPath=/var/mqm/exits/
ExitsDefaultPath64=/var/mqm/exits64/
#*
#*
Log:
LogPrimaryFiles=3
LogSecondaryFiles=2
LogFilePages=4096
LogType=CIRCULAR
LogBufferPages=0
#* LogPath=/var/mqm/log/TESTQMGR/
[b] Logpath=/nfs/mqmgrlogsdev/log/TESTQMGR/[/b]
LogWriteIntegrity=TripleWrite
|
the file locations are as follows:
Code: |
Log Dir:
mqm@peplap00xxx:/var/mqm> l /nfs/mqmgrlogsdev/
total 20
drwxr-xr-x 3 mqm mqm 1024 2012-09-12 17:05 ./
drwxr-xr-x 4 root root 4096 2012-09-10 16:27 ../
drwxr-xr-x 15 mqm mqm 1024 2012-09-12 17:05 log/
mqm@peplap00xxx:/var/mqm> l /nfs/mqmgrlogsdev/log
total 40
drwxr-xr-x 15 mqm mqm 1024 2012-09-12 17:05 ./
drwxr-xr-x 3 mqm mqm 1024 2012-09-12 17:05 ../
drwxr-xr-x 3 mqm mqm 80 2012-09-12 17:05 TESTQMGR/
mqm@peplap00xxx:/var/mqm> l /nfs/mqmgrlogsdev/log/TESTQMGR/
total 24
drwxr-xr-x 3 mqm mqm 80 2012-09-12 17:05 ./
drwxr-xr-x 15 mqm mqm 1024 2012-09-12 17:05 ../
drwxrwx--- 2 mqm mqm 1024 2012-09-11 15:53 active/
-rw-rw---- 1 mqm mqm 6256 2012-09-12 11:00 amqhlctl.lfh
mqm@peplap00xxx:/var/mqm> l /nfs/mqmgrlogsdev/log/TESTQMGR/a*
-rw-rw---- 1 mqm mqm 6256 2012-09-12 11:00 /nfs/mqmgrlogsdev/log/TESTQMGR/amqhlctl.lfh
/nfs/mqmgrlogsdev/log/TESTQMGR/active:
total 49208
drwxrwx--- 2 mqm mqm 1024 2012-09-11 15:53 ./
drwxr-xr-x 3 mqm mqm 80 2012-09-12 17:05 ../
-rw-rw---- 1 mqm mqm 16785408 2012-09-12 11:00 S0000000.LOG
-rw-rw---- 1 mqm mqm 16785408 2012-09-11 15:53 S0000001.LOG
-rw-rw---- 1 mqm mqm 16785408 2012-09-11 15:53 S0000002.LOG
|
This is my first post on this forum and i have found this forum highly beneficial for mq folks. You guys are doing awesome job.
So, keep it up!
Thanks,
Pasha |
|
Back to top |
|
 |
exerk |
Posted: Thu Sep 13, 2012 12:34 am Post subject: |
|
|
 Jedi Council
Joined: 02 Nov 2006 Posts: 6339
|
You created the queue manager 'locally' and then 'migrated' the data and log directories to shared storage? Please confirm that you did not create the queue manager with the -ld -md switches on the command line? _________________ 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 |
|
 |
pasha.mq |
Posted: Thu Sep 13, 2012 4:52 am Post subject: |
|
|
Newbie
Joined: 12 Sep 2012 Posts: 9
|
Correct.. I also created another qmgr using - ld & -md switches on the remote storage..it runs fine.. When I move the log dir only to local storage and updated the mqs.ini and qm.ini, this new qmgr runs fine. But the one created before (TESTQMGR) is not running when I point it to log dirs on the remote storage.(N A S). It is running only when logs are local.. I need to know what needs to be changed in order to be able to run the qmgr from remote storage. |
|
Back to top |
|
 |
exerk |
Posted: Thu Sep 13, 2012 4:55 am Post subject: |
|
|
 Jedi Council
Joined: 02 Nov 2006 Posts: 6339
|
pasha.mq wrote: |
I need to know what needs to be changed in order to be able to run the qmgr from remote storage. |
To 'run' a queue manager from 'remote storage' it needs to be defined correctly to do so, which is what the -ld -md switches can be used for. Effectively you will then have 'half' a multi-instance queue manager. _________________ 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 |
|
 |
pasha.mq |
Posted: Thu Sep 13, 2012 5:13 am Post subject: |
|
|
Newbie
Joined: 12 Sep 2012 Posts: 9
|
I agree with you, Exerk. If you read my prev post, I have created 2 types of qmgrs. One using ld and md switches and other without it. The former runs fine on both storages while the latter has issues, when it shldn't. I am wondering what tells MQ that a qmgr is on a local or remote storage. I thought MQ knows it using the datapath and logdefaultpath stanzas in mqs.ini and logpath stanza in qm.ini .. But setting correctly is not giving the correct results. Am I missing something here ?
Just to give u a bkgrnd, I am trying to simulate DR situation where you have to run ur DR backup server using the logs and qmgrs brought from primary site and the DR server is a dual purpose one I.e., it is normally used for QA and assumes a DR role during a disaster..
Thanks,
Pasha |
|
Back to top |
|
 |
exerk |
Posted: Thu Sep 13, 2012 5:21 am Post subject: |
|
|
 Jedi Council
Joined: 02 Nov 2006 Posts: 6339
|
pasha.mq wrote: |
Just to give u a bkgrnd, I am trying to simulate DR situation where you have to run ur DR backup server using the logs and qmgrs brought from primary site and the DR server is a dual purpose one I.e., it is normally used for QA and assumes a DR role during a disaster. |
This not a good idea; if you need DR then run dedicated DR infrastructure. The above assumes that everything in QA is identical to Production, and I mean everything.
As an alternative, you might want to consider creating the 'other' half of your Production-level multi-instance queue manager on the QA infrastructure and run it there if DR is required. Bear in mind that all connecting infrastructure will need to be MI-queue manager aware. _________________ 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 |
|
 |
Vitor |
Posted: Thu Sep 13, 2012 5:28 am Post subject: |
|
|
 Grand High Poobah
Joined: 11 Nov 2005 Posts: 26093 Location: Texas, USA
|
pasha.mq wrote: |
Just to give u a bkgrnd, I am trying to simulate DR situation where you have to run ur DR backup server using the logs and qmgrs brought from primary site and the DR server is a dual purpose one I.e., it is normally used for QA and assumes a DR role during a disaster.. |
Why have you got the Prod queue manager using local so you have to migrate it like this? Why not have the Prod queue manager defined as MI with the standby Prod queue manager on the QA server? In the event of a DR you shut down the QA queue manager and spin up the Prod one exactly as you're trying to do except that in this scenarion WMQ understands what's going on. _________________ Honesty is the best policy.
Insanity is the best defence. |
|
Back to top |
|
 |
pasha.mq |
Posted: Thu Sep 13, 2012 8:44 am Post subject: |
|
|
Newbie
Joined: 12 Sep 2012 Posts: 9
|
Thanks for the responses.
Well, I had similar questions to my leadership and the answer I got is cost of having a dedicated h/w to support an incident that might never happen. So, They want to leverage the QA box to run as a DR backup.
Vitor - The design you have mentioned is ideal for a HA environment. We are not looking for a HA here, but just a DR where it is ok to loose some amount of data and some amount of delay in bringing the systems back up. Infact the RPOxRTO agreed is 4X4
The queue managers are all single instance and not multi. Converting them to multi involves cost that my shop is not ready to spend.
So, the plan is to move all the existing production queue managers(binaries/logs/qmgrs) to a replicated N A S / N F S storage from their local storage/mounts. The storage is replicated to a DR site periodically. In event of disaster, the network shares will be hooked/mounted to a QA/DR server which will run using the binaries/logs/qmgrs on the network. I would invite your expert opinions on this design and suggestions to better it with less cost.
Not to deviate from my original question where I am trying to understand how MQ works internally. So, I am reposting my question here again Appreciate if you can throw some light on this, as I really need to complete this POC. My 1st post has all the technical details. -
Quote: |
I am wondering what tells MQ that a qmgr is on a local or remote storage. I thought MQ knows it using the datapath and logdefaultpath stanzas in mqs.ini and logpath stanza in qm.ini .. But setting correctly is not giving the correct results. Am I missing something here ? |
Thanks Again,
Pasha |
|
Back to top |
|
 |
exerk |
Posted: Thu Sep 13, 2012 8:51 am Post subject: |
|
|
 Jedi Council
Joined: 02 Nov 2006 Posts: 6339
|
pasha.mq wrote: |
The queue managers are all single instance and not multi. Converting them to multi involves cost that my shop is not ready to spend. |
What spend? You already have the contact admin, all you would be doing is creating the queue managers as you would a multi-instance queue manager, but only starting up the 'second' instance if you ever invoke DR. _________________ 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 |
|
 |
Vitor |
Posted: Thu Sep 13, 2012 9:18 am Post subject: |
|
|
 Grand High Poobah
Joined: 11 Nov 2005 Posts: 26093 Location: Texas, USA
|
pasha.mq wrote: |
TVitor - The design you have mentioned is ideal for a HA environment. We are not looking for a HA here, but just a DR where it is ok to loose some amount of data and some amount of delay in bringing the systems back up. Infact the RPOxRTO agreed is 4X4 |
So what (in your view) is the conceptual difference between HA & DR, apart from the speed with which the alternate instance is brought up?
pasha.mq wrote: |
The queue managers are all single instance and not multi. Converting them to multi involves cost that my shop is not ready to spend. |
What spend? Someone's time to rework them? If that's above the unacceptable limit of spending then I doubt your shop's willingness to buy paper for the printers.
pasha.mq wrote: |
I would invite your expert opinions on this design and suggestions to better it with less cost. |
My expert opinion - it sucks.
Running the binaries off an NFS mounted drive is a bad idea, and should be unnecessary on a QA server that's already running a queue manager.
You're also building a replication mechanism with NFS which is built into WMQ's MI functionality. If your shop doesn't want to spend how are they paying for this to be done? Or is your management unloading the cost onto the storage team?
This design has a number of possible failure points in it (replication, reliance on the NFS being switched in DR, using NFS mounted binaries, etc) as well as bending WMQ in an unsupported direction (IBM does not support this kind of file remounting that I'm aware of). I really struggle to see where this additional "spend" you're talking about comes from, and how your proposed solution is cheaper. _________________ Honesty is the best policy.
Insanity is the best defence. |
|
Back to top |
|
 |
fjb_saper |
Posted: Thu Sep 13, 2012 5:41 pm Post subject: |
|
|
 Grand High Poobah
Joined: 18 Nov 2003 Posts: 20756 Location: LI,NY
|
If the queue mgr is single instance you need to follow the DR rules for WMQ and provide the latest logs and then run the qmgr to bring the logs up to current status (see DR DOC) of course this is so much easier when you run with linear logging. You will then have to update periodically from the logs on the DR.  _________________ MQ & Broker admin |
|
Back to top |
|
 |
pasha.mq |
Posted: Fri Sep 21, 2012 4:42 pm Post subject: |
|
|
Newbie
Joined: 12 Sep 2012 Posts: 9
|
Thanks for your opinions. I have resolved the issue. The solution my original problem was 2 steps:
1. Just move the QMGRS and log directories to the contact admin storage
2. Create logical links/shortcuts in the /var/mqm directory on the local machine to access the above directories on the contact admin.
I didn't have to do any config changes.
The cause of the issue i faced was:
I had a copy of the log dir in the local and another copy on the contact admin. I tried testing(putting msgs in queue) by switching from one to another(I realize it looks confusing..). It failed at one point because the log message header was different. The correct way of testing is to move the log dir instead of copying it, so that data consistency is maintained.
I was aware that the topic of DR would open up a can of worms and it did. But I appreciate all your responses. Thanks. |
|
Back to top |
|
 |
|