| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
  |
|
| Cluster query and clarification on "refresh cluster&quo |
« View previous topic :: View next topic » |
| Author |
Message
|
| zhanghz |
 Posted: Mon Jul 28, 2008 12:23 am Post subject: Cluster query and clarification on "refresh cluster&quo |
 |
|
Disciple
Joined: 17 Jun 2008
Posts: 186
|
hi all, I have one query on cluster and some clarification needed on "refresh cluster".
Long post, please bear with me. Thanks in advance.
The query first.
We have 2 QMGRs (A01G, A02G) on 2 AIX boxes holding full repository, and a z/OS QMGR (Z01G) holding partial. It was reported that the application on first AIX box (the one A01G resides in, let's call it A01G as well, and so on) can't receive any response from z/OS, and checking on Z01G was requested. I checked, channel to A01G was inactive. I then "dis clusqmgr(cluster_name) qmid qmtype conname" and found 4 entries (note the first one, a "ghost" entry):
CLUSQMGR(A01G) QMID(A01G_2008-05-31_XX) QMTYPE(NORMAL) CONNAME(10.0.10.10(1414))
CLUSQMGR(A01G) QMID(A01G_2008-06-20_XX) QMTYPE(REPOS) CONNAME(10.0.0.1(1414))
CLUSQMGR(A02G) QMID(A02G_2008-06-20_XX) QMTYPE(REPOS) CONNAME(10.0.0.2(1414))
CLUSQMGR(Z01G) QMID(Z01G.XXYYZZ) QMTYPE(NORMAL) CONNAME(ZOSMQHOST(1414))
Checked with AIX team and was told that the ip was AIX DR box ip. But we had no idea why it went to production z/OS repository. Our production environment (both z/OS and distributed systems) is strictly separated from DR environment and are not supposed to connect to each other at all. Can anyone advise what might be the reason Z01G has this "ghost" repository info about the DR server IP address?
Now come to my query on "refresh cluster".
For the problem above, i asked AIX team to do the same "dis clusqmgr", they had only the last 3 entries which were correct. So what I did was to instruct operators to do a "refresh cluster(clsuter_name) repos(yes)" on Z01G. The ghost entry was removed.
my questions are:
1) is it possible that AIX box (FR holder) do "refresh cluster" and the ghost entry on z/OS (PR holder) can be removed? Asking this question is because my team lead doesn't want to do "refresh cluster" in z/OS saying the command is "destructive". I am not sure how destructive though.
2) what is the effect of doing "refresh cluster" and "refresh cluster repos(yes)"? Effect as in what the command will do to those QMGRs that are not the one that the command is issued from.
In this case of mine, I refresh cluster repos(yes) on z/OS, all repository info was removed, then a request is sent to full repository holder and the full repository holder then passes down its repository info (only info about clusqmgr, channels, conname, etc, but not including any cluster queue information?) to z/OS?
if z/os doesn't do refresh cluster, what will happen if AIX boxes (FR holders) do "refresh cluster"? I guess this goes back to my first question above. My understanding is that it will not clear the "ghost" entry on z/OS QGMR as my feeling is that "refresh cluster" is a passive request: you do not request for new information, i will not give to you although there might be some changes on my side..
Thanks. |
|
| Back to top |
|
 |
| exerk |
| Posted: Mon Jul 28, 2008 1:10 am Post subject: |
|
|
Jedi Council
Joined: 02 Nov 2006
Posts: 6339
|
Presumably the DR box has a queue manager of the same name as the 'live' box, i.e. A01G? If so, the 'ghost' entry is there because someone may at some time have joined it to the cluster. I suggest examining the DR queue manager and checking the CLUSSDR definitions.
From the manual:
| Quote: |
Using REFRESH CLUSTER(clustername) REPOS(NO) provides the default behavior. The queue manager will retain knowledge of all cluster queue manager and cluster queues marked as locally defined and all cluster queue managers that are marked as full repositories. In addition, if the queue manager is a full repository for the cluster it will also retain knowledge of the other cluster queue managers in the cluster. Everything else will be removed from the local copy of the repository and rebuilt from the other full repositories in the cluster. Cluster channels will not be stopped if REPOS(NO) is used, a full repository will use its CLUSSDR channels to inform the rest of the cluster that it has completed its refresh.
Using REFRESH CLUSTER(clustername) REPOS(YES) specifies that in addition to the default behavior, objects representing full repository cluster queue managers are also refreshed. This option may not be used if the queue manager is itself a full repository... |
I truncated part of the second paragraph.
As regards a refresh being 'destructive', I assume that the operators mean some information on queue managers will be flushed, and may take time to be rebuilt; also a refresh can cause a 'flurry' of cluster-related traffic.
_________________
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 |
|
|
| mlr |
| Posted: Mon Jul 28, 2008 1:04 pm Post subject: |
|
|
Novice
Joined: 29 Jun 2008
Posts: 13
|
the problem was caused by two qmgrs of the same name being present in the cluster at the same time. at some point the DR box must have been connected to the live system.
refresh cluster was the wrong command to use. you need to use reset cluster to rid the cluster of the information about the unwanted qmgr, the CLUSQMGR(A01G) QMID(A01G_2008-05-31_XX)... |
|
| Back to top |
|
|
| zhanghz |
| Posted: Mon Jul 28, 2008 11:06 pm Post subject: |
|
|
Disciple
Joined: 17 Jun 2008
Posts: 186
|
So it means the AIX DR box was definitely connected to the network where production z/OS was in for its IP address to be populated to production z/OS? well, i guess this piece of information can't be released to customer..
And my question in my first post again, can AIX FR holder issue "refresh cluster" to solve the "ghost" entry problem in z/OS PR holder? My own answer is no, because AIX will only remove (in its own QMGR A01G and/or A02G) the information about cluster queues on other clusqmgrs after issuing "refresh cluster(name) repos(no)" and will not trigger refreshing in z/OS QMGR.
Then natually another question came to me, shouldn't the cluster information be auto-populated? that's one of reason to use cluster, right? so why the ghost entry was still in my z/OS PR holder? When will clusqmgrs automatically try to do a synchronization of the cluster information? If my z/oS QMGR does some of this kind of synchronization, it should find out that the FR QMGRs don't have the information about the "ghost" entry and shall remove it from z/OS QMGR, right? But apparently no such synchronization occured, and my z/OS channel once kept on RETRYing to connect to the "ghost" ip address instead of the "real" ip address of the production AIX boxes.
i feel cluster is kind of "messy" concerning repository..
Thanks mlr for pointing out that I shouldn't have used "refresh cluster". ya, i think you are right. it's all because "refresh cluster" sounds so handy and it was the first thing that came to my mind.. I shall memorize "reset cluster" now.. |
|
| Back to top |
|
|
| zhanghz |
| Posted: Mon Jul 28, 2008 11:16 pm Post subject: |
|
|
Disciple
Joined: 17 Jun 2008
Posts: 186
|
| exerk wrote: |
...
| Quote: |
Using REFRESH CLUSTER(clustername) REPOS(NO) provides the default behavior. The queue manager will retain knowledge of all cluster queue manager (what does this knowledge include? cluster queue manger names only?) and cluster queues marked as locally defined and all cluster queue managers that are marked as full repositories (again, what does this knowledge include? cluster queue manger names only?) . In addition, if the queue manager is a full repository for the cluster it will also retain knowledge of the other cluster queue managers in the cluster. Everything else (what does everything else comprise of?) will be removed from the local copy of the repository and rebuilt from the other full repositories in the cluster. Cluster channels will not be stopped if REPOS(NO) is used, a full repository will use its CLUSSDR channels to inform the rest of the cluster that it has completed its refresh.
Using REFRESH CLUSTER(clustername) REPOS(YES) specifies that in addition to the default behavior, objects representing full repository cluster queue managers (what are those objects representing full repository clusqmgrs?) are also refreshed. This option may not be used if the queue manager is itself a full repository... |
... |
exerk, can explain to me regarding those I marked as red? Thanks. |
|
| Back to top |
|
|
| sami.stormrage |
| Posted: Mon Jul 28, 2008 11:21 pm Post subject: |
|
|
Disciple
Joined: 25 Jun 2008
Posts: 186
Location: Bangalore/Singapore
|
| Quote: |
| Then natually another question came to me, shouldn't the cluster information be auto-populated? that's one of reason to use cluster, right? so why the ghost entry was still in my z/OS PR holder? When will clusqmgrs automatically try to do a synchronization of the cluster information? If my z/oS QMGR does some of this kind of synchronization, it should find out that the FR QMGRs don't have the information about the "ghost" entry and shall remove it from z/OS QMGR, right? But apparently no such synchronization occured, |
Cluster info is not populated automatically. It is at the time of PUT that the PR enquires about the object to the FR, if it cannot find it in its repository.
And synchroniztion is related to transactional prosessing. Working of clustering is much simpler.
Reset cluster is right option to fix the mutliple Qmgr entry issue.
_________________
*forgetting everything  * |
|
| Back to top |
|
|
| exerk |
| Posted: Tue Jul 29, 2008 12:56 am Post subject: |
|
|
Jedi Council
Joined: 02 Nov 2006
Posts: 6339
|
| zhanghz wrote: |
| exerk wrote: |
| ...exerk, can explain to me regarding those I marked as red? Thanks. |
|
Basically it means that a queue manager will flush all references it has to other queue managers (except for the FR's) and cluster queues (except those defined within the queue manager from which the refresh is being initiated) in the cluster, and then rebuild its cluster 'knowledge' by querying the FR's when it needs to re-establish the location of a cluster resource.
It is my understanding that REPOS(YES) means that effectively that all cluster information will be rebuilt. If I am wrong in this view, someone please correct and amplify.
_________________
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 Jul 29, 2008 3:23 am Post subject: |
|
|
Disciple
Joined: 17 Jun 2008
Posts: 186
|
thanks all!
Guess I have had some wrong "expectation" about cluster. I thought cluster has some auto refreshing mechanism.. I think the correct understanding should be that cluster is just something to ease the burden to the adminstrators in terms of (remote) queue definitions.
my bad.. ha ha... tired, go home. Thanks again. |
|
| Back to top |
|
|
|
|
|
| |
|
Page 1 of 1 |
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
|
|
