| Author |
Message
|
| tleichen |
 Posted: Tue Jan 30, 2007 1:02 pm Post subject: Re: I've run into one problem |
 |
|
Yatiri
Joined: 11 Apr 2005
Posts: 663
Location: Center of the USA
|
| ashoon wrote: |
I've run into one problem doing this...
it happened when I accidentally started the QMgr on the second machine while the first was running and that fudged it completely.... but like you said - that won't happen in your environment.
another problem that I ran into was using NFS - MQ would take forever to start and stop... while I'm not sure the root cause we switched to mounting a local SAN and that fixed the issues but it could have been the Linux environment.
finally I like seperating the MQ libraries from the runtime so I can upgrade one machine while the second is running.
HTH |
I agree that ashoon's points make sense. They all indicate vulnerabilities in the configuration. But, the overall problem one would see with this in an HA configuration has to be that it is a manual operation. While functional, it would not normally be acceptable by today's standards, if I understand it right. 
_________________
IBM Certified MQSeries Specialist
IBM Certified MQSeries Developer |
|
| Back to top |
|
 |
| George Carey |
| Posted: Tue Jan 30, 2007 2:41 pm Post subject: |
|
|
Knight
Joined: 29 Jan 2007
Posts: 500
Location: DC
|
Agreed tleichen, if I had an SLA or 99.999% up time or the like I would have to have some automated scripts for detection of system and/or qmgr failure but that is some what tangential to what I am asking. I mean mc91 does not give you auto detection, products like Veritas, Tivoli, and hardware like deadman timers give you those capabilities and MC91 was to work in conjuction with them.
If I have a set of servers as I said before that are being load balanced across the new messages would flow to those servers still running and any unprocessed messages on the failed qmgr would be processable as soon as the backup qmgr was started back up. If some suitable system outage detection software was in place to start up the backup server qmgr ... all I am saying is my configuration should be fine should it not?
_________________
"Truth is ... grasping the virtually unconditioned",
Bernard F. Lonergan S.J.
(from book titled "Insight" subtitled "A Study of Human Understanding") |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Tue Jan 30, 2007 2:45 pm Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
I guess what a lot of people are saying is that you've got what counts as redundancy, but you don't have what counts as HA.
And I'm saying, cross your fingers that support doesn't decide that you've done something bad.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| Ratan |
| Posted: Tue Jan 30, 2007 4:58 pm Post subject: |
|
|
Grand Master
Joined: 18 Jul 2002
Posts: 1245
|
| Quote: |
| If I have a set of servers as I said before that are being load balanced across the new messages would flow to those servers still running and any unprocessed messages on the failed qmgr would be processable as soon as the backup qmgr was started back up. If some suitable system outage detection software was in place to start up the backup server qmgr |
If all you want to do is process the failed messages, then looks like your configuration is good (forgetting the fact that it is supported or not). You still need to get your failed QM up and running to process new messages. Right?
_________________
-Ratan |
|
| Back to top |
|
|
| Vitor |
| Posted: Wed Jan 31, 2007 12:46 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| George Carey wrote: |
| all I am saying is my configuration should be fine should it not? |
My 2 cents - what you have is a viable but vunerable setup. Vunerable because if you can't get IBM to agree it's a supported configuration then in the event of problem the PMR route will be closed to you. Also care will need to be taken when applying upgrades, with more associated downtime than with other situations.
Where I suspect you may encounter more issues is in the non-technical arena when your setup is audited. An unsupported configuration may be flagged as an issue, as may one where manual intervention is required on each failure.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| George Carey |
| Posted: Wed Jan 31, 2007 8:46 am Post subject: |
|
|
Knight
Joined: 29 Jan 2007
Posts: 500
Location: DC
|
Responding to the recurrent theme on my configuration being an unsupported configuration, let me offer the following:
Try viewing my configuration from a pure WSMQ install perspective and forget about HA aspects for the moment.
Say Adam administrator was installing WSMQ in a generic sense and created his stadard two filesystems /opt/mqm and /var/mqm according to the book and did his Solaris 'pkgadd -d ...' commands. The fact that his filesystems may have been created on a shared RAID drive should make them no less supported a configuration than if they were on an internal non-shared drive.
A second point: say the MC91 supportpac had just been created and put in the public domain and had no track record. Adam might say well it was put out by IBM so if there are problems with it they will be fixed. Well MC91 is in the AS-IS category of support. Basically if it works for you good, if not sorry. It was bascially put there as our(IBM's) suggestion on how it should be done.
Now Look at the complexity of it as opposed to my configuration. And by complexity I mean read the scripts 'hacrtmqm', 'halinkmqm', etc. , and do you know and understand exactly are they are doing? Do you understand why the directory links described in the diagram on page 9 of the 40 odd pages of the MC91 pdf documentation are done, ... remember you are going to be supporting it if something doesn't work! That's what Category 2 means. Oh, and where in the document does it described how to fail back ? Is it another process ... it's not described... hmmm better do some more reading ???
Or I could just load the WSMQ software on a shared filesystem drive and move on from there ...
_________________
"Truth is ... grasping the virtually unconditioned",
Bernard F. Lonergan S.J.
(from book titled "Insight" subtitled "A Study of Human Understanding") |
|
| Back to top |
|
|
| Vitor |
| Posted: Thu Feb 01, 2007 1:29 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| George Carey wrote: |
| The fact that his filesystems may have been created on a shared RAID drive should make them no less supported a configuration than if they were on an internal non-shared drive. |
RAID is not the issue - shared disc is.
| George Carey wrote: |
| say the MC91 supportpac had just been created and put in the public domain and had no track record. |
But it hasn't just been created, and does have a track record.
| George Carey wrote: |
| I mean read the scripts 'hacrtmqm', 'halinkmqm', etc. , and do you know and understand exactly are they are doing? |
Yes 
| George Carey wrote: |
| Do you understand why the directory links described in the diagram on page 9 of the 40 odd pages of the MC91 pdf documentation are done |
Yes
| George Carey wrote: |
| remember you are going to be supporting it if something doesn't work! That's what Category 2 means. |
Cat 2 means that defect correction is not provided as part of the license. If you have followed the recommendations of such a support pack you are likely (but not guaranteed) to get support. If you have not, you are unlikely (and equally not guaranteed) to get support. Why worsen your chances? 
| George Carey wrote: |
| Oh, and where in the document does it described how to fail back ? Is it another process ... it's not described... hmmm better do some more reading ??? |
What? You mean fail back when the primary system is fixed? Yes, do more reading. You won't need to do much more...
| George Carey wrote: |
| Or I could just load the WSMQ software on a shared filesystem drive and move on from there ... |
You must of course do what you feel is best for your system in your circumstances. Only you know your situation and all the circumstances. All we can offer is advice and experience.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| George Carey |
| Posted: Thu Feb 01, 2007 7:42 am Post subject: |
|
|
Knight
Joined: 29 Jan 2007
Posts: 500
Location: DC
|
Vitor's comment: "Raid is not the issue - shared disc is "
Thanks for that clarification! 
Vitor's again: "But it hasn't just been created, and does have a track record."
The colloquial prepositional phrase '..say..' indicates one should attempt empathetic supposition -- I'm trying to illustrate why one should not drink the coolaid quite so quickly.
Vitor's remaining clarifications: "Yes"
Got a page number. I will give it a read.
and
again: "Yes"
... thanks for the insights any more to add ???
By the way investigating my configuration further I see that it works nicely in an active/active arrangement as well, not just and active/passive. It works nicely when a client cross connects. I can create independent qmgrs on each server and connects fail (appropriately) if I inadvertently attempt to try a bind connect across servers on running qmgrs. I take a qmgr down and bring it up on the backup qmgr and both qmgrs run just fine.
You might want to try setting up the configuration and checking it out before making more comments.
_________________
"Truth is ... grasping the virtually unconditioned",
Bernard F. Lonergan S.J.
(from book titled "Insight" subtitled "A Study of Human Understanding") |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Thu Feb 01, 2007 8:00 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
The other thing to look into is the new "backup queue manager" options with MQ v6.
There's a new option to crtmqm and strmqm.
This may be a safer way to do what you're already doing.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| Vitor |
| Posted: Thu Feb 01, 2007 8:07 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| George Carey wrote: |
| The colloquial prepositional phrase '..say..' indicates one should attempt empathetic supposition -- I'm trying to illustrate why one should not drink the coolaid quite so quickly. |
MC91 is nearly a year old. I think the coolaid will be nicely warmed by now.
| George Carey wrote: |
By the way investigating my configuration further I see that it works nicely in an active/active arrangement as well, not just and active/passive. It works nicely when a client cross connects. I can create independent qmgrs on each server and connects fail (appropriately) if I inadvertently attempt to try a bind connect across servers on running qmgrs. I take a qmgr down and bring it up on the backup qmgr and both qmgrs run just fine. |
I'm very pleased you have a working solution that meets your requirements.
| George Carey wrote: |
| You might want to try setting up the configuration and checking it out before making more comments. |
Why? Veritas is in use here. If I have future requirements for HA I'll continue to use the relevant software product because I believe it's the best method and offers other advantages. You'll continue to use the solution you've developed for exactly the same reason. I don't see a single problem with this as we both have a solution which meets our needs - the seldom attained win/win.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| George Carey |
| Posted: Thu Feb 01, 2007 8:08 am Post subject: |
|
|
Knight
Joined: 29 Jan 2007
Posts: 500
Location: DC
|
Yes, I have checked that out Jeff ... as it relates to new log functionality and log updating utilities for keeping a backup qmgr in sync if that is what you are referring to and it looks good on the windows box I was testing it on.
I have not tried it on unix boxes yet.
_________________
"Truth is ... grasping the virtually unconditioned",
Bernard F. Lonergan S.J.
(from book titled "Insight" subtitled "A Study of Human Understanding") |
|
| Back to top |
|
|
| George Carey |
| Posted: Thu Feb 15, 2007 3:31 pm Post subject: |
|
|
Knight
Joined: 29 Jan 2007
Posts: 500
Location: DC
|
looking to use the scripts from MC91 for my HA configuration I notice a discrepancy between the WSMQ Version 6 System Admin Guide which on ppgs 575-576 gives the order of processes to be killed in manually stopping a qmgr as:
amqzmuc0 amqzxma0 amqzfuma amqzlaa0 amqzlsa0 amqzmur0 amqrmppa amqrrmfa amqzdmaa amqpcsea ...
It is confusingly almost the exact opposite of the order that the hamqm_stop_su scripts actually use. Which is as follows:
----
...
# Edit only with tab-friendly editors.
srchstr="( |-m)$QM[ ]*.*$"
for process in amqpcsea amqhasmx amqharmx amqzllp0 \
amqzlaa0 runmqchi runmqlsr amqcrsta amqrrmfa amqrmppa \
amqzfuma amqzdmaa amqzmuc0 amqzmur0 amqzmgr0 amqzxma0
do
ps -ef | grep $process | grep -v grep | \
egrep "$srchstr" | awk '{print $2}'| \
xargs kill -9
done
# Should now be safe to start the QM
...
-------
So which is correct the documentation or the script ... or doesn't it really matter. (never mind the two groups don't match)
_________________
"Truth is ... grasping the virtually unconditioned",
Bernard F. Lonergan S.J.
(from book titled "Insight" subtitled "A Study of Human Understanding") |
|
| Back to top |
|
|
| bbburson |
| Posted: Fri Feb 16, 2007 6:54 am Post subject: |
|
|
Partisan
Joined: 06 Jan 2004
Posts: 378
Location: Nowhere near a queue manager
|
| The kill order you show from hamqm_stop_su is for WMQ 5.3. The order changed (as you say, rather drastically) with WMQ v6. Just this week I had to update our Veritas HA environment to account for this difference. |
|
| Back to top |
|
|
| George Carey |
| Posted: Fri Feb 16, 2007 7:52 am Post subject: |
|
|
Knight
Joined: 29 Jan 2007
Posts: 500
Location: DC
|
Are you telling me Bruce that the documentation in the WSMQ System Admin Guide is actually correct and the the MC91 actual scripts as they are currently offered and distributed to the public domain are INCORRECT !!!
So everyone that is using the MC91 scripts under Version 6 are running their High Availablity environment with incorrect possibly flawed scripts. How can this be hmm.... (... is there anymore coolaide left ?...)
_________________
"Truth is ... grasping the virtually unconditioned",
Bernard F. Lonergan S.J.
(from book titled "Insight" subtitled "A Study of Human Understanding") |
|
| Back to top |
|
|
| George Carey |
| Posted: Fri Feb 16, 2007 8:12 am Post subject: |
|
|
Knight
Joined: 29 Jan 2007
Posts: 500
Location: DC
|
FYI, Bruce mc91 is using a file hamqproc that gives the order of the mq processes are presented to the {for do done} loop in the scripts. If you just change the order of the names in this file no changes need be made to the actual scripts.
I don't know though you might want to wait until IBM changes it lest you be running an UNSUPPORTED custom configuration of their scripts.
_________________
"Truth is ... grasping the virtually unconditioned",
Bernard F. Lonergan S.J.
(from book titled "Insight" subtitled "A Study of Human Understanding") |
|
| Back to top |
|
|
|
|
