| Author |
Message
|
| hallmark |
 Posted: Mon Jun 03, 2013 5:08 am Post subject: addmqinf - aix hacmp |
 |
|
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 |
|
 |
| zpat |
| Posted: Mon Jun 03, 2013 5:27 am Post subject: |
|
|
Jedi Council
Joined: 19 May 2001
Posts: 5866
Location: UK
|
|
| Back to top |
|
|
| hallmark |
| Posted: Mon Jun 03, 2013 6:37 am Post subject: |
|
|
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 |
|
|
| hallmark |
| Posted: Mon Jun 03, 2013 6:43 am Post subject: |
|
|
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 |
|
|
| Vitor |
| Posted: Mon Jun 03, 2013 6:43 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
|
| Back to top |
|
|
| zpat |
| Posted: Mon Jun 03, 2013 6:46 am Post subject: |
|
|
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 |
|
|
| hallmark |
| Posted: Mon Jun 03, 2013 8:10 am Post subject: |
|
|
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 |
|
|
| hughson |
| Posted: Tue Jun 04, 2013 3:29 am Post subject: |
|
|
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 |
|
|
| hallmark |
| Posted: Tue Jun 04, 2013 3:49 am Post subject: |
|
|
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 |
|
|
| hughson |
| Posted: Tue Jun 04, 2013 4:10 am Post subject: |
|
|
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 |
|
|
| hallmark |
| Posted: Tue Jun 04, 2013 4:23 am Post subject: |
|
|
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 |
|
|
| hughson |
| Posted: Wed Jun 19, 2013 1:21 am Post subject: |
|
|
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 |
|
|
| zpat |
| Posted: Wed Jun 19, 2013 1:28 am Post subject: |
|
|
Jedi Council
Joined: 19 May 2001
Posts: 5866
Location: UK
|
| Does this apply to all current MQ versions? |
|
| Back to top |
|
|
| hughson |
| Posted: Wed Jun 19, 2013 2:29 am Post subject: |
|
|
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 |
|
|
| hallmark |
| Posted: Wed Jun 19, 2013 4:05 am Post subject: |
|
|
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 |
|
|
|
|
