| Author |
Message
|
| anthony.barnes |
 Posted: Thu Nov 18, 2010 11:15 am Post subject: Poor mans Higher Availability environment and use of hamvmqm |
 |
|
Apprentice
Joined: 01 Jul 2003
Posts: 26
Location: Oak Brook, Illinois
|
Description of the issue:
Following the migration of the qmgr and transactional logs from the C: drive to the D: drive via the hamvmqm command the queue manager no longer receives a request to start up from the Windows “service” on the secondary server. This same queue manager starts up fine from the command line. The error that is captured within the Application Event log is error number “25”. Mention of issue with the directory structure is suggested but nothing further.
Environment:
• NON MSCS environment. Failover is a manual effort that reassigns network resources as well as the common shared drive between the primary and secondary servers at the time of failover.
• A pair of X5550 Xeon @ 2.6 GHz with 6GB RAM (8 cores) running Windows Server 2003 R2 Standard x64 Edition SP2
• WebSphere MQ 6.0.2.2 installed locally on each server under the C:\ drive.
• A commonly D:\ drive holding the qmgr definition and transactional logs that is only available to one of the servers at a time. It is not “shared” by both server simultaneously.
After creating the queue manager locally on the primary server’s C:\ drive I migrated it to the common D:\ drive using the hamvmqm command. The queue manager is fully functional on the primary server using the objects on the D:\ drive. Everything is working as expected. After several iterations of testing on the primary server the environment was failed over to the secondary server.
On the secondary server I created a local queue manger with the same name and attributes as the one created and migrated on the primary server. To keep the migration attempt I was about to perform from overwriting the migrated qmgr and transactional logs on the D:\ drive I moved them to a separate directory. Once I migrated the secondary server’s qmgr to the D:\ drive in the same method I used on the primary server I replaced this temporary qmgr with the objects I had previously saved in a separate directory. At this point the stopping and starting of the “service” would not start the queue mangers nor do I see any attempt (or errors) within the qmgrs logs. I am able to start the queue manger without issue from the command line.
I have viewed the entries in the registry looking for some setting that might still be pointing to the local C:\ drive for the qmgr def or the logs location but so far I haven’t found anything.
During troubleshooting I have found that if I delete the queue manger and recreate it on the secondary server first I get the same error (error number 25) on the primary server.
Any clues on how to continue troubleshooting are greatly appreciated.
Thank you very much for your time.
 |
|
| Back to top |
|
 |
| exerk |
| Posted: Thu Nov 18, 2010 3:26 pm Post subject: |
|
|
Jedi Council
Joined: 02 Nov 2006
Posts: 6339
|
Don't do this...it's neither a good idea, nor supported. That command is for moving a queue manager into MSCS control and as you are finding, nothing works properly when you try it in non-MSCS infrastructure. Delete everything and do it properly, or don't do it at all.
You are not the first to try this, undoubtedly you will not be the last 
_________________
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 |
|
|
| anthony.barnes |
| Posted: Thu Nov 18, 2010 4:43 pm Post subject: |
|
|
Apprentice
Joined: 01 Jul 2003
Posts: 26
Location: Oak Brook, Illinois
|
| exerk wrote: |
| That command is for moving a queue manager into MSCS control and as you are finding, nothing works properly when you try it in non-MSCS infrastructure. |
The IBM TechNote (URL below) appears to indicate that this command is viable for use "outside of an MSCS environment". While the article does not mention the configuration I have in mind (two servers) I'd like to understand what is actually preventing it from functioning.
It seems like such a simple straight forward method with precedence within UNIX it seems a shame to be this close and not be able to determine why it is failing to start upon service startup.
Why is this not a good idea (outside of it not being supported).
http://www-01.ibm.com/support/docview.wss?uid=swg21193016 |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Thu Nov 18, 2010 8:48 pm Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
That document http://www-01.ibm.com/support/docview.wss?uid=swg21193016 relates to V5.3 which has been out of support for over 2 years now and version 6.0 which is going to be out of support end of next year...
Have you looked at V7 and the multi-instance qmgr with file system under NFS4?
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| anthony.barnes |
| Posted: Fri Nov 19, 2010 6:20 am Post subject: |
|
|
Apprentice
Joined: 01 Jul 2003
Posts: 26
Location: Oak Brook, Illinois
|
Thanks for the feedback guys.
Understood that the document is based on 5.3 but do you see any reason why (conceptually speaking) the idea/method wouldn't be applicable to the 6.0 environment?
We are currently running WMQ 7.0 through our initial testing environment with deployment into stagging early next quarter. Production should follow about a quarter behind that. I have been reviewing the multi-instance qmgr feature of WMQ 7.0 and will certainly be pursuing it going forward. However... in the mean time...
Any clue on what to look for within the configuration that might cause this issue? |
|
| Back to top |
|
|
| Vitor |
| Posted: Fri Nov 19, 2010 6:31 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| anthony.barnes wrote: |
| Understood that the document is based on 5.3 but do you see any reason why (conceptually speaking) the idea/method wouldn't be applicable to the 6.0 environment? |
The document is applicable to both environments (check the box middle right). I think the point my worthy assoiate was making is that both of these versions are at varying levels of death.
| anthony.barnes wrote: |
| Any clue on what to look for within the configuration that might cause this issue? |
If the queue mangers start from the command line but not as a Windows service then something in the registry is able to determine the path is incorrect or inconsistent (possibly the application SID or similar). This is a Windows issue not an WMQ one.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| exerk |
| Posted: Fri Nov 19, 2010 6:31 am Post subject: |
|
|
Jedi Council
Joined: 02 Nov 2006
Posts: 6339
|
Now that I can view the link I rescind my earlier observation that the command was for MSCS only...
...that said, IBM state it is a method for moving queue managers and their associated data from one drive to another, on the same machine - NOT for doing what you are attempting, which I reiterate, is NOT supported.
_________________
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 |
|
|
| anthony.barnes |
| Posted: Fri Nov 19, 2010 6:44 am Post subject: |
|
|
Apprentice
Joined: 01 Jul 2003
Posts: 26
Location: Oak Brook, Illinois
|
I understand what you are saying exerk. My posting of the link wasn't in anyway intended as disparagement. I was only providing it to show the basis of why I think this "should" work. I really appreciate everyones input on this form and I completely grock what you and fjb_saper are saying.
With the understanding that I acknowledge this is an unsupported IBM configuration and that it is on a version of the software that will be out of support by Sept 30, 2011... I'm asking for any guidance on my road to trying to understand technically what is going on and why it isn't working. I just need to understand this. |
|
| Back to top |
|
|
| exerk |
| Posted: Fri Nov 19, 2010 6:50 am Post subject: |
|
|
Jedi Council
Joined: 02 Nov 2006
Posts: 6339
|
| anthony.barnes wrote: |
| ...My posting of the link wasn't in anyway intended as disparagement... |
And was not taken as such, in fact the link was a revelation to me and is now safely filed away under 'useful information' 
I think my illustrious master (Vitor) has nailed the problem for you...
_________________
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 |
|
|
| anthony.barnes |
| Posted: Fri Nov 19, 2010 7:00 am Post subject: |
|
|
Apprentice
Joined: 01 Jul 2003
Posts: 26
Location: Oak Brook, Illinois
|
I'd have to say I agree with you on both counts Vitor.
| Quote: |
| both of these versions are at varying levels of death |
| Quote: |
| something in the registry is able to determine the path is incorrect or inconsistent (possibly the application SID or similar). |
I was just hoping that someone within the MQSeries.net community might have some ideas on what to check as I am fairly confident that the vast majority of windows based user forums would be less then helpful.
I will pursue the application SID path and see what I can learn.
Again... thanks to everyone for your input. I'll keep the thread apprised of anything "useful" that I might find. |
|
| Back to top |
|
|
| exerk |
| Posted: Fri Nov 19, 2010 7:06 am Post subject: |
|
|
Jedi Council
Joined: 02 Nov 2006
Posts: 6339
|
| anthony.barnes wrote: |
| ...I will pursue the application SID path and see what I can learn... |
Bearing in mind that V7.0.1 MI queue managers on Windows have to be on Domain Controllers, because it's the only way to ensure a SID is identical on two different servers - so, do you really want to waste the time pursuing this?
_________________
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 |
|
|
| PeterPotkay |
| Posted: Fri Nov 19, 2010 8:22 am Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
When you use the hamvmqm command to get a QM set up under MSCS, doing something that is supported, I wonder if at that point on that type of set up the QM would not start up either by the Service? You would NOT want it to, because you would want MSCS to have full control of that QM and not have the Windows Service getting involved.
Maybe, just maybe, hamvmqm specifically disables the ability of a QM to be controlled by the Windows MQ Service? Just a guess, I have no idea what that command does under the covers.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| Vitor |
| Posted: Fri Nov 19, 2010 8:48 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| PeterPotkay wrote: |
| Maybe, just maybe, hamvmqm specifically disables the ability of a QM to be controlled by the Windows MQ Service? Just a guess, I have no idea what that command does under the covers. |
Oooo...good guess though! 
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| ramires |
| Posted: Fri Nov 19, 2010 10:41 am Post subject: |
|
|
Knight
Joined: 24 Jun 2001
Posts: 523
Location: Portugal - Lisboa
|
Did you look to the fdc files ? They may have some useful info there.
I was trying to recreate the scenario here, but no success. If I create a qmgr with the defaults, in my case D drive and them use hamvmqm to move data and log path to the C drive , in the same box , I'm able to start qmgr. If I move data path and log path to a network drive , a share in another computer , with really slow access , the qmgr fails to start and a fdc and a mini dump (I don't remember see dmp files in windows) is created.
...
AMQ6109: An internal WebSphere MQ error has occurred.
Access Violation at address 0000000C when reading
...
I don't want to solve this, was just a test , and I believe its because the slow network drive. |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Fri Nov 19, 2010 8:34 pm Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
| ramires wrote: |
Did you look to the fdc files ? They may have some useful info there.
I was trying to recreate the scenario here, but no success. If I create a qmgr with the defaults, in my case D drive and them use hamvmqm to move data and log path to the C drive , in the same box , I'm able to start qmgr. If I move data path and log path to a network drive , a share in another computer , with really slow access , the qmgr fails to start and a fdc and a mini dump (I don't remember see dmp files in windows) is created.
...
AMQ6109: An internal WebSphere MQ error has occurred.
Access Violation at address 0000000C when reading
...
I don't want to solve this, was just a test , and I believe its because the slow network drive. |
Not because of the network drive...
Much more likely because the SID of the windows id and group id acessing the MQ files is not the same on both machines.
Have fun
_________________
MQ & Broker admin |
|
| Back to top |
|
|
|
|
