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 » General Discussion » addmqinf - aix hacmp

Post new topic  Reply to topic Goto page 1, 2  Next
 addmqinf - aix hacmp « View previous topic :: View next topic » 
Author Message
hallmark
PostPosted: Mon Jun 03, 2013 5:08 am    Post subject: addmqinf - aix hacmp Reply with quote

Voyager

Joined: 10 Mar 2005
Posts: 76

Hi,

Just wondering if there was a valid technical reason why the mounting of MQ file systems is enforced by the addmqinf command. It would seem to make operational sense to me to allow the freedome to add mq instances to the standby node (e.g. in an AIX HACMP cluster) without the need for the resource intensive failover of resources.

When building an MQ system in a greenfield site we start with a DEV environment, we create all the primary queue managers and are currently forced to failover to create the standby queue managers. We then do our failover testing...

We have automated our processes so the risk of incorrectly creating the HA queue manager set up is lower and so it would be good for us to just run our automation against our targets

1. Create Primary
2. Create Standby (against the other target)
3. Deploy all of our configuration
4. Handover to testers who will test availability, and the configuration in one cycle.

This makes operational sense (to me) as we proceed through the environment levels as the scheduling of failover becomes increasingly difficult and we eliminate at least one failover (possibly 2) by our approach.

So...is this worthy do you think of requesting this as an enhancement from IBM or am I missing something?

Rob
_________________
Rob
Back to top
View user's profile Send private message
zpat
PostPosted: Mon Jun 03, 2013 5:27 am    Post subject: Reply with quote

Jedi Council

Joined: 19 May 2001
Posts: 5866
Location: UK

Use the dspmqinf command on the primary side to display the information in stanza format and edit the standby side mqs.ini file to add it.

dspmqinf -o stanza <QMNAME>

Actually a lot easier than the equivalent issue with WMB mentioned here http://www.mqseries.net/phpBB2/viewtopic.php?t=63647&highlight=
Back to top
View user's profile Send private message
hallmark
PostPosted: Mon Jun 03, 2013 6:37 am    Post subject: Reply with quote

Voyager

Joined: 10 Mar 2005
Posts: 76

Thanks zpat for the response.

Absolutely could do that, infact in HACMP there is a neat thing called file collections which would allow that file to be synchronised accross the nodes if you don't mind losing the "flexibility" of being able to create adhoc queue managers on either node without losing their configuration.

However as mentioned ours is an automated deployment and the tooling I am using doesn't lend itself to performing the deployment to both targets at the same time (yet...) so your suggestion would be a manual step. I could source control the mqs.ini file and as a second deployment push that out to the second target...

But really what I am after is an indication that its just a redundant dependency that the file systems be available and that it might be removed in a future version if that is the case as a feature request (not sure how to request such things)
_________________
Rob
Back to top
View user's profile Send private message
hallmark
PostPosted: Mon Jun 03, 2013 6:43 am    Post subject: Reply with quote

Voyager

Joined: 10 Mar 2005
Posts: 76

And I have just read your other thread re: the same situation in Message Broker (which we also have to deal with).

Ignoring the merits of vi I think there is a case for performing these commands without the need for the file systems to be mounted since like you it is not always simple nor efficient to organise the failover at build time.

Maybe if there is no real dependency a "dirty" version of those commands could be added. All this is moot, I will probably stick to the current methods we have, just thought I would explore the issue
_________________
Rob
Back to top
View user's profile Send private message
Vitor
PostPosted: Mon Jun 03, 2013 6:43 am    Post subject: Reply with quote

Grand High Poobah

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

hallmark wrote:
(not sure how to request such things)


https://www.ibm.com/developerworks/rfe/
_________________
Honesty is the best policy.
Insanity is the best defence.
Back to top
View user's profile Send private message
zpat
PostPosted: Mon Jun 03, 2013 6:46 am    Post subject: Reply with quote

Jedi Council

Joined: 19 May 2001
Posts: 5866
Location: UK

There is now a way to raise requirements via IBM Developer Works or some such site.

However you can expect to wait a year or so before seeing it in the actual product.

I agree with you - there should be an option for the products not try to access the HA (or NFS) storage when defining a secondary QM or broker.

We build HA configurations so infrequently that automation seems unnecessary - personally I don't subscribe to the "tear down and rebuild" approach to MQ or WMB environments.

Building them once and controlling access to them to prevent unauthorised changes works for me.
Back to top
View user's profile Send private message
hallmark
PostPosted: Mon Jun 03, 2013 8:10 am    Post subject: Reply with quote

Voyager

Joined: 10 Mar 2005
Posts: 76

I'll take the bait

Currently am building out a set of environments from DEV to production. All the installations are identical, the queue manager creations are almost identical and the naming conventions are predictable.

The automation means that every queue manager is created in an identical manner and does not rely too much on the dilligence or otherwise of the person performing the activity itself. The MQ engineer is free to briefly worry about MQ aspects, capacity management, naming conventions, logging attributes etc. and not about whether or not their vi attempt had a typo or contained a rogue linefeed at the end

More importantly they can spend their time on facing their customers and encouraging them to use MQ in an effective manner secure in the knowledge the systems they are advocating were built in a consistent and reliable way. Not everyone needs this, some organisations are better than others in achieving the same using different methods.
_________________
Rob
Back to top
View user's profile Send private message
hughson
PostPosted: Tue Jun 04, 2013 3:29 am    Post subject: Reply with quote

Padawan

Joined: 09 May 2013
Posts: 1959
Location: Bay of Plenty, New Zealand

hallmark wrote:
Maybe if there is no real dependency a "dirty" version of those commands could be added. All this is moot, I will probably stick to the current methods we have, just thought I would explore the issue
Instead of running addmqinf, you can just edit the ini file manually. Does that count as a dirty version?

Cheers
Morag
_________________
Morag Hughson @MoragHughson
IBM MQ Technical Education Specialist
Get your IBM MQ training here!
MQGem Software
Back to top
View user's profile Send private message Visit poster's website
hallmark
PostPosted: Tue Jun 04, 2013 3:49 am    Post subject: Reply with quote

Voyager

Joined: 10 Mar 2005
Posts: 76

It is the second option given, but I have raised an enhancement request to get a version of addmqinf that doesn't require the file systems to be mounted that will handle the update of the mqs.ini file - which is what I meant by a dirty version.

I don't know what the command is doing that requires the dependency on qm.ini file (I suspect some kind of validation or duplicate checking?).

My issue is:

1. Create Primary Qmgr
2. Initiate a failover - which fails to start the standby as it's unknown
3. Create standby information using addmqinf
4. Start Queue Manager - this checks all resources are there
5. Fail back
6. Test failover properly by failing over again
7. Fail back to "natural" node (most places would choose to do this)

Could be

1. Create Primary
2. Add Standby Information using an MQ command
3. Test failover
4. Fail back to natural node

In higher level environments the cost of failover increases in general.

Editing the mqs.ini is a reasonable workaround, but it means I am taking responsibility for the file itself which I'd rather if at all possible but as zpat implies not something worth spending too much more energy on given the lifecycle of most Queue Managers.

Thanks for responding

Rob
_________________
Rob
Back to top
View user's profile Send private message
hughson
PostPosted: Tue Jun 04, 2013 4:10 am    Post subject: Reply with quote

Padawan

Joined: 09 May 2013
Posts: 1959
Location: Bay of Plenty, New Zealand

hallmark wrote:
I don't know what the command is doing that requires the dependency on qm.ini file (I suspect some kind of validation or duplicate checking?).

I believe it checks that all your permissions are good etc, so that if you were to try to start or failover the queue manager to this system, it would be able to run. You of course avoid this checking by doing the edit yourself, but on the downside you might not discover that you've forgotten a setup step until later. As suitable RFE to raise might be to request an "I know what I'm doing" flag on addmqinf so that it just edits the ini file and doesn't do the checking, if you're not keen on hand-editing the ini files.

Cheers
Morag
_________________
Morag Hughson @MoragHughson
IBM MQ Technical Education Specialist
Get your IBM MQ training here!
MQGem Software
Back to top
View user's profile Send private message Visit poster's website
hallmark
PostPosted: Tue Jun 04, 2013 4:23 am    Post subject: Reply with quote

Voyager

Joined: 10 Mar 2005
Posts: 76

hughson wrote:
As suitable RFE to raise might be to request an "I know what I'm doing" flag on addmqinf so that it just edits the ini file and doesn't do the checking, if you're not keen on hand-editing the ini files.


That's what I was thinking - will update the RFE
_________________
Rob
Back to top
View user's profile Send private message
hughson
PostPosted: Wed Jun 19, 2013 1:21 am    Post subject: Reply with quote

Padawan

Joined: 09 May 2013
Posts: 1959
Location: Bay of Plenty, New Zealand

Looks like there is an environment variable exactly for this purpose.

MQFILESECURITYCHECK = OFF

Suggest putting the setting and then removal again of this env var around your call to addmqinf in a script.

Cheers
Morag
_________________
Morag Hughson @MoragHughson
IBM MQ Technical Education Specialist
Get your IBM MQ training here!
MQGem Software
Back to top
View user's profile Send private message Visit poster's website
zpat
PostPosted: Wed Jun 19, 2013 1:28 am    Post subject: Reply with quote

Jedi Council

Joined: 19 May 2001
Posts: 5866
Location: UK

Does this apply to all current MQ versions?
Back to top
View user's profile Send private message
hughson
PostPosted: Wed Jun 19, 2013 2:29 am    Post subject: Reply with quote

Padawan

Joined: 09 May 2013
Posts: 1959
Location: Bay of Plenty, New Zealand

zpat wrote:
Does this apply to all current MQ versions?

It applies to all versions that have addmqinf.

Cheers
Morag
_________________
Morag Hughson @MoragHughson
IBM MQ Technical Education Specialist
Get your IBM MQ training here!
MQGem Software
Back to top
View user's profile Send private message Visit poster's website
hallmark
PostPosted: Wed Jun 19, 2013 4:05 am    Post subject: Reply with quote

Voyager

Joined: 10 Mar 2005
Posts: 76

Hi, bad news I'm afraid (for me)

Code:


mqm@xxxxxxxx:> export MQFILESECURITYCHECK=OFF

mqm@xxxxxxx:> addmqinf -s QueueManager -v Name=QMGR1-v Directory=QMGR1-v Prefix=/var/mqm -v DataPath=/MQTD/WMQ/QMGR1/data/QMGR1
AMQ6237: File '/MQTD/WMQ/QMGR1/data/QMGR1/qm.ini' missing.
AMQ7001: The location specified for the queue manager is not valid.

mqm@xxxxxxx:> echo $MQFILESECURITYCHECK
OFF


_________________
Rob
Back to top
View user's profile Send private message
Display posts from previous:   
Post new topic  Reply to topic Goto page 1, 2  Next Page 1 of 2

MQSeries.net Forum Index » General Discussion » addmqinf - aix hacmp
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.