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 » Changing log path to a NFS mounted filesystem gives AMQ7064

Post new topic  Reply to topic
 Changing log path to a NFS mounted filesystem gives AMQ7064 « View previous topic :: View next topic » 
Author Message
pasha.mq
PostPosted: Wed Sep 12, 2012 3:35 pm    Post subject: Changing log path to a NFS mounted filesystem gives AMQ7064 Reply with quote

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
View user's profile Send private message
exerk
PostPosted: Thu Sep 13, 2012 12:34 am    Post subject: Reply with quote

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
View user's profile Send private message
pasha.mq
PostPosted: Thu Sep 13, 2012 4:52 am    Post subject: Reply with quote

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
View user's profile Send private message
exerk
PostPosted: Thu Sep 13, 2012 4:55 am    Post subject: Reply with quote

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
View user's profile Send private message
pasha.mq
PostPosted: Thu Sep 13, 2012 5:13 am    Post subject: Reply with quote

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
View user's profile Send private message
exerk
PostPosted: Thu Sep 13, 2012 5:21 am    Post subject: Reply with quote

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
View user's profile Send private message
Vitor
PostPosted: Thu Sep 13, 2012 5:28 am    Post subject: Reply with quote

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
View user's profile Send private message
pasha.mq
PostPosted: Thu Sep 13, 2012 8:44 am    Post subject: Reply with quote

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
View user's profile Send private message
exerk
PostPosted: Thu Sep 13, 2012 8:51 am    Post subject: Reply with quote

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
View user's profile Send private message
Vitor
PostPosted: Thu Sep 13, 2012 9:18 am    Post subject: Reply with quote

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
View user's profile Send private message
fjb_saper
PostPosted: Thu Sep 13, 2012 5:41 pm    Post subject: Reply with quote

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
View user's profile Send private message Send e-mail
pasha.mq
PostPosted: Fri Sep 21, 2012 4:42 pm    Post subject: Reply with quote

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
View user's profile Send private message
Display posts from previous:   
Post new topic  Reply to topic Page 1 of 1

MQSeries.net Forum Index » IBM MQ Installation/Configuration Support » Changing log path to a NFS mounted filesystem gives AMQ7064
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.