| Author |
Message
|
| troy |
 Posted: Fri Aug 28, 2009 11:44 pm Post subject: Cluster queue invisible frequently |
 |
|
Novice
Joined: 07 Jan 2009
Posts: 20
|
Hi,
There is a cluster with 3 FR and and around 8 PR.
The cluster queue out of these 11 boxes suddenly gets invisible randomly on any of the boxes and after doing the cluster refresh i becomes again visible.
Things checked -
1. As 3 FRs are there so explicit clusrcvr and clussdr channels are there. It means each FR has clusrcvr and Clussdr to other FR. The conname -> ip and port are checked and they are fine. (As generally this is the problem).
2. All th PR have clusrcvr and clussdr to one of the FR. Again port and ip are checked and they are fine.
3. Repos process is running for all QMs.
4. Now one thing which is noticed is that out of 11 boxes. 2 boxes( one FR and one PR) are on MQ5.3 and these are boxes where cluster q is locally hosted. other 9 boxes are on MQ6.0 from where cluster q is not loally hosted only displayed by dis QC.
Can this be a cause of the problem?
5. Can there be anykind of automated monitoring can be done for this queue?
Please suggest.
Thanks in advance. |
|
| Back to top |
|
 |
| exerk |
| Posted: Sat Aug 29, 2009 4:32 am Post subject: |
|
|
Jedi Council
Joined: 02 Nov 2006
Posts: 6339
|
Why do you have three FR's in such a small cluster? What earthly reason can there be for it? That said, demote the V5.3 FR to a PR and drop down to having only two FR's, both of them on V6.0 (always good practice to have FR's at the highest level). See if that cures the problem, and if not, post again.
THIS and THIS may benefit 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 |
|
|
| troy |
| Posted: Sat Aug 29, 2009 5:28 am Post subject: |
|
|
Novice
Joined: 07 Jan 2009
Posts: 20
|
Thanks exerk for the response.
3 FRs because the FRs are geographically different locations and the cluster size is expected to grow and to prevent any Disaster in case.
Do you see 3FRs is the problem here?
As per my understanding even for 3FRs this problem should not have occured. Please make me correct.
or MQ version difference for FRs is the main problem? |
|
| Back to top |
|
|
| exerk |
| Posted: Sat Aug 29, 2009 6:36 am Post subject: |
|
|
Jedi Council
Joined: 02 Nov 2006
Posts: 6339
|
OK, you've justified the why of three FR's, but they should still all be at the later version of WMQ. As to why the issue, I don't know, I don't have enough information to formulate an answer.
_________________
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 |
|
|
| Vitor |
| Posted: Sat Aug 29, 2009 6:37 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| troy wrote: |
3 FRs because the FRs are geographically different locations and the cluster size is expected to grow and to prevent any Disaster in case.
|
By "geograpahically different" do you mean 1 in Europe, 1 in Asia & 1 in USA? That's the sort of distances where you might consider 3 FRs and even then only if the cluster was very dynamic and/or very large (5000+ PRs).
Also what sort of disaster? Even if all the FRs were knocked out the cluster would continue to run. Obviously changing it would be impossible, but day-to-day running would continue. WMQ clusters are not really suitable for DR.
| troy wrote: |
| Do you see 3FRs is the problem here? |
I would certainly suspect it. I wonder if the automatic update is getting stuck somewhere, somehow.
| troy wrote: |
| As per my understanding even for 3FRs this problem should not have occured. Please make me correct. |
It shouldn't but if you raise a PMR with IBM I bet their first suggestion would be "demote one of the FRs and see if the problem persists." Except of course....
| troy wrote: |
| or MQ version difference for FRs is the main problem? |
......in your specific case it would be "v5.3 is out of support."
I don't think the version levels are the problem but are a problem and you should be looking to upgrade for all the usual and good reasons.
Aside from that I echo my worthy associate - have 2 v6 qmgrs as FRs for the whole cluster and see if that helps. While upgrading all the v5.3 to v6 or higher.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Sat Aug 29, 2009 10:10 am Post subject: Re: Cluster queue invisible frequently |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
| troy wrote: |
| The cluster queue out of these 11 boxes suddenly gets invisible randomly |
What does that mean?
Do any applications complain about not being able to put to queues? Or is this just some tool you are using?
The only reason you want more than 2 FRs is if you expect both of those FRs to be N/A at the same time frequently, in which case you probably didn't pick the right QMs to be your FRs in the first place. Neither a large cluster or 2 FRs very far apart is a reason for a 3rd FR.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Sun Aug 30, 2009 2:40 pm Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
 with Peter...
The main reason to have multiple FRs (more than 2) in a geographically disparate cluster is to be still able to use the local part of the cluster when communication lines with the non local FRs may be out of order.
Also not all cluster queues should show up on a partial repository. If you have not used a cluster queue that is not hosted on the PR you are connected to within 90 days, chances are the cluster queue will be dropped from the repository, until it is needed again...
Have fun 
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| Vitor |
| Posted: Sun Aug 30, 2009 5:01 pm Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| fjb_saper wrote: |
| The main reason to have multiple FRs (more than 2) in a geographically disparate cluster is to be still able to use the local part of the cluster when communication lines with the non local FRs may be out of order. |
Remembering that the cluster still works with the FRs out of action (before someone brings out the old chestnut of cluster messages flowing through the FRs!)
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Sun Aug 30, 2009 8:10 pm Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
| Vitor wrote: |
| fjb_saper wrote: |
| The main reason to have multiple FRs (more than 2) in a geographically disparate cluster is to be still able to use the local part of the cluster when communication lines with the non local FRs may be out of order. |
Remembering that the cluster still works with the FRs out of action (before someone brings out the old chestnut of cluster messages flowing through the FRs!) |
Kind of works without the FR.
If you need a new cluster queue to be put to on a pr, if the cluster queue is not local, you won't be able to put to it as there is no FR to get it from...
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| troy |
| Posted: Mon Aug 31, 2009 12:06 am Post subject: |
|
|
Novice
Joined: 07 Jan 2009
Posts: 20
|
Thanks all for your response.
Points taken.
I will first upgrade the mqversion for all the FRs and if problem persists will remove the the 3rd FR.
I will revert to the forum if problem still persists.
Thank you so much. |
|
| Back to top |
|
|
|
|
