| Author |
Message
|
| zhanghz |
 Posted: Tue Feb 24, 2009 4:02 am Post subject: CLUSSDR/CLUSRCVR running, but qmgr not shown in DIS CLUSQMGR |
 |
|
Disciple
Joined: 17 Jun 2008
Posts: 186
|
ZA and ZB are 2 qmgrs on z/OS, A1 is a qmgr on AIX. They are in one cluster.
Now i got this, ZA can see CLUSRCVR running with connection from A1, A1 can also see CLUSSDR running with connection to ZA. But A1 cannot see ZA in DIS CLUSQMGR. A1 only sees A1 itself and ZB in DIS CLUSQMGR.
Because A1 now cannot connect to ZB (firewall problem, ports not open), A1 cannot see any of ZA or ZB in DIS CLUSQMGR and therefore putting message to a queue on AZ got 2189.
What might be the problem? Thanks. |
|
| Back to top |
|
 |
| Vitor |
| Posted: Tue Feb 24, 2009 4:07 am Post subject: Re: CLUSSDR/CLUSRCVR running, but qmgr not shown in DIS CLUS |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| zhanghz wrote: |
| ZA and ZB are 2 qmgrs on z/OS, A1 is a qmgr on AIX. They are in one cluster. |
Who are the FRs in this setup? Are the CLUSSDR pointing to them?
| zhanghz wrote: |
| What might be the problem? |
Erm....
| zhanghz wrote: |
| Because A1 now cannot connect to ZB (firewall problem, ports not open), |
Could the problem not be a network issue? Like a firewall?
Remember that all of the members of a cluster will interconnect.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| zhanghz |
| Posted: Tue Feb 24, 2009 4:43 am Post subject: |
|
|
Disciple
Joined: 17 Jun 2008
Posts: 186
|
sorry, forgot to mention that ZA and ZB are FR, A1 is PR.
yes, CLUSSDR at A1 is running and pointing to ZA's CLUSRCVR, and ZA's CLUSRCVR also running.
I believe if the network between A1 and ZB is ok, there should not be any problem. But the firewall changes cannot be done now, so we have tried to REFRESH CLUSTER on both ZA and A1. But DIS CLUSQMGR at A1 always gave A1 and ZB, and it seems A1's CLUSSDR to ZA is not working, but DIS CHS(*) shows the CLUSSDR is running at A1, and the CLUSRCVR is running at ZA.
I cann't think of any reason on why A1 is so persistent to connect to ZB in A1's repository..
Thanks.
To add, at ZA, DIS CLUSQMGR can see all ZA, ZB and A1.
Last edited by zhanghz on Tue Feb 24, 2009 4:47 am; edited 1 time in total |
|
| Back to top |
|
|
| exerk |
| Posted: Tue Feb 24, 2009 4:47 am Post subject: Re: CLUSSDR/CLUSRCVR running, but qmgr not shown in DIS CLUS |
|
|
Jedi Council
Joined: 02 Nov 2006
Posts: 6339
|
| Vitor wrote: |
| Remember that all of the members of a cluster will interconnect. |
Or to paraphrase my master: "...all of the members of a cluster must interconnect..."
So I would not expect much to happen until you resolve your firewall issues.
_________________
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 |
|
|
| zhanghz |
| Posted: Tue Feb 24, 2009 4:52 am Post subject: |
|
|
Disciple
Joined: 17 Jun 2008
Posts: 186
|
| ah, like that? i thought if number of FR qmgrs goes down to just 1, the cluster should still working because there is still 1 FR qmgr left? |
|
| Back to top |
|
|
| exerk |
| Posted: Tue Feb 24, 2009 4:58 am Post subject: |
|
|
Jedi Council
Joined: 02 Nov 2006
Posts: 6339
|
(My) First Rule of Clusters: Ensure all queue managers can interconnect before trying to fault diagnose 
It's amazing how many cluster 'problems' just disappear when proper comms are established.
Retreating to my dungeon now master...
_________________
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: Tue Feb 24, 2009 5:03 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| zhanghz wrote: |
| ah, like that? i thought if number of FR qmgrs goes down to just 1, the cluster should still working because there is still 1 FR qmgr left? |
The results will be a bit unpredictable. Certainly if you make any changes (e.g. adding a new cluster queue or a PR using a cluster queue it's not used before) things could get interesting.
I think you'd have more luck if A1 had previously been able to see ZB and had lost comms. If it's never been able to connect to the ZB FR the cluster is not fully "built" and hence you get this issue.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| zhanghz |
| Posted: Tue Feb 24, 2009 5:13 am Post subject: |
|
|
Disciple
Joined: 17 Jun 2008
Posts: 186
|
This is happening in our DR environment. A1's repository knowledge might come from its production copy.
I am very vexed that CHS(*) shows running but CLUSQMGR(*) doesn't show the qmgr. Why got such discrepancy?! |
|
| Back to top |
|
|
| Vitor |
| Posted: Tue Feb 24, 2009 5:18 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| zhanghz wrote: |
| This is happening in our DR environment. A1's repository knowledge might come from its production copy. |
Ah!
| zhanghz wrote: |
| I am very vexed that CHS(*) shows running but CLUSQMGR(*) doesn't show the qmgr. Why got such discrepancy?! |
Because not all the queue managers can be discovered due to the network issue. IMHO you're getting more vexing results than normal because the queue managers have details of the cluster by virtue of them being DR copies of working queue managers (in your live environment), yet can't match them up with the situation in which they find themselves (a DR site with a network issue).
Clusters - when they work they're great, when they don't they can annoy (or vex). Shrug and move on.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| zhanghz |
| Posted: Tue Feb 24, 2009 5:39 am Post subject: |
|
|
Disciple
Joined: 17 Jun 2008
Posts: 186
|
all 3 qmgrs have changed their cluster channels' definition to point to DR IP addresses. The cluster worked fine during preivous DR tests, but not this DR now. Of course, the difference, that I am aware of, between this DR and preivous ones is that now there is network issue between A1 and ZB..
I will push this over to A1 admin, they were the one that requested firewall changes for DR test.. I do not know what to do right now except making good the network connection first.
After some problems with cluster, I feel that mq cluster hides too many details underneath, while there are only not even a handful of commands to control cluster. Now I rather prefer using point-to-point mq channels. Sigh.. |
|
| Back to top |
|
|
| Vitor |
| Posted: Tue Feb 24, 2009 5:47 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| zhanghz wrote: |
| I will push this over to A1 admin, they were the one that requested firewall changes for DR test.. I do not know what to do right now except making good the network connection first. |
It's the best first step
| zhanghz wrote: |
| Now I rather prefer using point-to-point mq channels. |
You wouldn't say that if you were trying to cross connect 30 queue managers instead of 3, or were trying to do workload balancing with an in-house application. 
Clusters have their place. Point-to-point has it's place (and is equally vunerable to inexplicably configured firewalls). It's all about picking the correct solution for your situation, and ensuring that the solution is correctly installed and correctly configured.
This concludes Part I of my lecture in Saying Things Which Are Very Obvious. 
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| zhanghz |
| Posted: Tue Feb 24, 2009 6:07 am Post subject: |
|
|
Disciple
Joined: 17 Jun 2008
Posts: 186
|
hahaha, you are correct Vitor.
i am still stuck with A1 guys now, they don't want to raise firewall request as that would mean unscheduled change. I am "helping" them do some new ideas of theirs now...  |
|
| Back to top |
|
|
| Vitor |
| Posted: Tue Feb 24, 2009 6:11 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| zhanghz wrote: |
| I am "helping" them do some new ideas of theirs now... |
Remember: firm grip, swing with the shoulder and flick with the wrist.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| zhanghz |
| Posted: Tue Feb 24, 2009 6:15 pm Post subject: |
|
|
Disciple
Joined: 17 Jun 2008
Posts: 186
|
A1 people asked me to delete at ZA all manually defined CLUSSDR channels that point to ZB (this deletion removed ZB from ZA's repository). Then refreshed cluster at ZA. A1 probably refreshed cluster too, and now can see ZA in its repository and putting to ZA cluster queues has no problem now.
Interesting case.. |
|
| Back to top |
|
|
| Vitor |
| Posted: Wed Feb 25, 2009 12:53 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| zhanghz wrote: |
| Interesting case.. |
Interesting cluster topology. Wonder what the queue manager logs say....?
Ah well. If it's working for you...
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
|
|
