| Author |
Message
|
| fjb_saper |
 Posted: Tue Oct 07, 2008 3:20 am Post subject: |
 |
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20757
Location: LI,NY
|
| solomon_13000 wrote: |
QM3 - Partial Repository
DEFINE CHANNEL('QM2.QM1.DF') CHLTYPE(CLUSSDR) TRPTYPE(TCP) CONNAME('localhost(1417)') CLUSTER(CLUS2)
DEFINE CHANNEL('QM1.QM3.DF') CHLTYPE(CLUSRCVR) TRPTYPE(TCP) CONNAME('localhost(1419)') CLUSTER(CLUS2)
DEFINE QLOCAL(QL3) CLUSTER(CLUS2)
runmqlsr -m QM3 -t TCP -p 1419
Comments:
After setting up the partial repository, I tried to amqsput QL3 QM1 and I am getting the error:
Sample AMQSPUT0 start
target queue is QL3
MQOPEN ended with reason code 2085
unable to open queue for output
Sample AMQSPUT0 end
Take note that the channel status is running. |
Working as designed. On your command line you are specifying a qmgr.
I understand you have 3 qmgrs on the same box and as such you have to specify a qmgr if it is not the default....
So use amqsputc and set the environment to point to QM1 then try the put and if it does not work try it with an explicit blank qmgr name...
This is really something you should be trying with tools like MO71 or programing and not the default tools which may have an adverse behavior coded into them... Have you ever tried the put test message of MO71? You can override almost anything, qname, qmgr name etc...
Enjoy 
_________________
MQ & Broker admin |
|
| Back to top |
|
 |
| solomon_13000 |
| Posted: Tue Oct 07, 2008 4:17 am Post subject: |
|
|
Master
Joined: 13 Jun 2008
Posts: 284
|
This works:
QM1 - Full Repository
ALTER QMGR REPOS(CLUS2)
DEFINE CHANNEL('QM1.QM2.DF') CHLTYPE(CLUSSDR) TRPTYPE(TCP) REPLACE CONNAME('localhost(1415)') CLUSTER(CLUS2)
DEFINE CHANNEL('QM2.QM1.DF') CHLTYPE(CLUSRCVR) TRPTYPE(TCP) CONNAME('localhost(1416)') CLUSTER(CLUS2)
DEFINE QLOCAL(QL1) CLUSTER(CLUS2)
runmqlsr -m QM1 -t TCP -p 1416
QM2 - Full Repository
ALTER QMGR REPOS(CLUS2)
DEFINE CHANNEL('QM2.QM1.DF') CHLTYPE(CLUSSDR) TRPTYPE(TCP) CONNAME('localhost(1416)') CLUSTER(CLUS2)
DEFINE CHANNEL('QM1.QM2.DF') CHLTYPE(CLUSRCVR) TRPTYPE(TCP) CONNAME('localhost(1415)') CLUSTER(CLUS2)
DEFINE QLOCAL(QL2) CLUSTER(CLUS2)
runmqlsr -m QM2 -t TCP -p 1415
QM3 - Partial Repository
DEFINE CHANNEL('QM2.QM1.DF') CHLTYPE(CLUSSDR) TRPTYPE(TCP) CONNAME('localhost(1416)') CLUSTER(CLUS2)
DEFINE QLOCAL(QL3) CLUSTER(CLUS2)
DEFINE CHANNEL('QM3.QM3.DF') CHLTYPE(CLUSRCVR) TRPTYPE(TCP) CONNAME('localhost(1420)') CLUSTER(CLUS2)
runmqlsr -m QM3 -t TCP -p 1420 |
|
| Back to top |
|
|
| exerk |
| Posted: Tue Oct 07, 2008 5:35 am Post subject: |
|
|
Jedi Council
Joined: 02 Nov 2006
Posts: 6339
|
| fjb_saper wrote: |
| ...Working as designed. On your command line you are specifying a qmgr... |
From the DIS QCLUSTER(*) output from QM1 (earlier post) it appears that the connection between QM1 and QM3 was not there, had it been I would expect the amqsput to work.
_________________
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 |
|
|
| solomon_13000 |
| Posted: Tue Oct 07, 2008 5:43 am Post subject: |
|
|
Master
Joined: 13 Jun 2008
Posts: 284
|
|
| Back to top |
|
|
| solomon_13000 |
| Posted: Tue Oct 07, 2008 5:50 am Post subject: |
|
|
Master
Joined: 13 Jun 2008
Posts: 284
|
what is the number of full repository that IBM recommends having in a cluster?. Is it 2?.
Last edited by solomon_13000 on Tue Oct 07, 2008 5:56 am; edited 2 times in total |
|
| Back to top |
|
|
| exerk |
| Posted: Tue Oct 07, 2008 5:54 am Post subject: |
|
|
Jedi Council
Joined: 02 Nov 2006
Posts: 6339
|
| solomon_13000 wrote: |
| what is the number of full repository that IBM recommends having in a cluster?. Is it 2?. |
Search the forum for posts on this subject - especially the one by Peter Potkay, as it is the most comprehensive answer I have seen.
An instructor on one of the IBM courses I attended stated: "The recommendation is more than one, and less than three".
_________________
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 |
|
|
| solomon_13000 |
| Posted: Tue Oct 07, 2008 6:30 am Post subject: |
|
|
Master
Joined: 13 Jun 2008
Posts: 284
|
| Usually it's two. But im also wondering can a full repository in a cluster participate in another cluster?. The thing I know is it is possible for the queue manager in one cluster to talk to the queue manager in another cluster. But from a full repository point of view is this possible?. |
|
| Back to top |
|
|
| exerk |
| Posted: Tue Oct 07, 2008 6:37 am Post subject: |
|
|
Jedi Council
Joined: 02 Nov 2006
Posts: 6339
|
A queue manager can participate in a number of clusters, and may be a Full Repository in one or more clusters but only a Partial Repository in other clusters.
Consider the scenario of two overlapping clusters: the queue manager 'in the middle' may be an FR in one, and a PR in the other.
_________________
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 |
|
|
| solomon_13000 |
| Posted: Tue Oct 07, 2008 7:24 pm Post subject: |
|
|
Master
Joined: 13 Jun 2008
Posts: 284
|
| As I was reading I also discovered that with the use of cluster we will only be using the SYSTEM.CLUSTER.TRANSMIT.QUEUE to transmit messages between queue managers in the cluster. This means we wont have to define xmitq for each queue manager wanting to interact with other queue manager in the cluster. Also queue managers exchange repository info using the SYSTEM.CLUSTER.COMMAND.QUEUE. |
|
| Back to top |
|
|
| Blunderbird |
| Posted: Tue Oct 28, 2008 5:48 am Post subject: Re: Cluster |
|
|
Newbie
Joined: 28 Oct 2008
Posts: 4
|
[quote="atheek"][quote="solomon_13000"]Is this because the full repository will automatically define a sender channel to the receiver using the attribute ChannelAutoDef of the queue manager?.[/quote]
As ranganathan pointed out its the CLUSRCVR definition of the partial repos that is used for auto defining the senders and not by channel Auto def(CHAD) attribute of the queue manager. The channel auto def is applicable only for receiver and server connection channels. For Cluster Sender channels this is always enabled..what it means is that even if CHAD is disabled , the cluster queue managers will be able to make auto cluster sender definitions to the other queue managers in the cluster[/quote]
Is there any way of preventing auto-definition of cluster sender channels ?
Thanx |
|
| Back to top |
|
|
| mqjeff |
| Posted: Tue Oct 28, 2008 6:25 am Post subject: Re: Cluster |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
| Blunderbird wrote: |
| Is there any way of preventing auto-definition of cluster sender channels ? |
Yes.
Do not use clustering at all.
There is no other way.
Consequently do not form clusters that encompass queue managers that you do not want speaking to each other. |
|
| Back to top |
|
|
| exerk |
| Posted: Tue Oct 28, 2008 3:41 pm Post subject: Re: Cluster |
|
|
Jedi Council
Joined: 02 Nov 2006
Posts: 6339
|
| mqjeff wrote: |
| Blunderbird wrote: |
| Is there any way of preventing auto-definition of cluster sender channels ? |
Yes.
Do not use clustering at all.
There is no other way.
Consequently do not form clusters that encompass queue managers that you do not want speaking to each other. |
NOT true and very misleading!
A suitably coded auto-definition exit can stop it, and also SSL can be used to prevent it (without an auto-definition exit - see here)
_________________
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 |
|
|
| mqjeff |
| Posted: Tue Oct 28, 2008 4:54 pm Post subject: Re: Cluster |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
Not strictly true, no.
| exerk wrote: |
| and very misleading! |
Any notion that suggest that clusters will not form fully connected networks is much more misleading...
| exerk wrote: |
| A suitably coded auto-definition exit can stop it, and also SSL can be used to prevent it (without an auto-definition exit - see here) |
Auto-definition exits and SSL can prevent queue managers that you *do not want* to join the cluster from joining the cluster.
If you add a queue manager to a cluster INTENTIONALLY and then install an auto-def exit that ... blocks the autodef channels (and thus more or less "removes" it from the cluster)... it's really very misleading to suggest that anything sensible has happened.
Autodefinition of channels is one of the major significant benefits of MQ clusters. If you have a uqeue manager that needs to be connected to a cluster, but not use autodefined channels - why are you going to spend the time and effort to create, test, validate and support an autodef exit... rather than just use point-to-point channels (with SSL) in the first place? |
|
| Back to top |
|
|
| HubertKleinmanns |
| Posted: Wed Oct 29, 2008 12:07 am Post subject: Re: Cluster |
|
|
Shaman
Joined: 24 Feb 2004
Posts: 732
Location: Germany
|
| mqjeff wrote: |
Not strictly true, no.
| exerk wrote: |
| and very misleading! |
Any notion that suggest that clusters will not form fully connected networks is much more misleading...
| exerk wrote: |
| A suitably coded auto-definition exit can stop it, and also SSL can be used to prevent it (without an auto-definition exit - see here) |
Auto-definition exits and SSL can prevent queue managers that you *do not want* to join the cluster from joining the cluster.
If you add a queue manager to a cluster INTENTIONALLY and then install an auto-def exit that ... blocks the autodef channels (and thus more or less "removes" it from the cluster)... it's really very misleading to suggest that anything sensible has happened.
Autodefinition of channels is one of the major significant benefits of MQ clusters. If you have a uqeue manager that needs to be connected to a cluster, but not use autodefined channels - why are you going to spend the time and effort to create, test, validate and support an autodef exit... rather than just use point-to-point channels (with SSL) in the first place? |
You may have a MQ cluster to simplify some adminstration tasks and to have some sort of load balancing and fail over mechanism  .
But this does not mean, that you ignore the security  .
So what exerk wrote is a very common method, to use the advantages of MQ clustering without ignoring security.
You could also use overlapping clusters, to separate groups of QMgrs.
_________________
Regards
Hubert
Last edited by HubertKleinmanns on Wed Oct 29, 2008 5:14 am; edited 1 time in total |
|
| Back to top |
|
|
| Blunderbird |
| Posted: Wed Oct 29, 2008 12:09 am Post subject: Re: Cluster |
|
|
Newbie
Joined: 28 Oct 2008
Posts: 4
|
| mqjeff wrote: |
Auto-definition exits and SSL can prevent queue managers that you *do not want* to join the cluster from joining the cluster.
If you add a queue manager to a cluster INTENTIONALLY and then install an auto-def exit that ... blocks the autodef channels (and thus more or less "removes" it from the cluster)... it's really very misleading to suggest that anything sensible has happened.
Autodefinition of channels is one of the major significant benefits of MQ clusters. If you have a uqeue manager that needs to be connected to a cluster, but not use autodefined channels - why are you going to spend the time and effort to create, test, validate and support an autodef exit... rather than just use point-to-point channels (with SSL) in the first place? |
@mqjeff I understand your astonishment. Maybe a little background helps.
I want QMgrs to interact via a central hub (or gateway)
These QMgrs could be in different "domain" clusters connected via this central Hub.
This hub exists of several Qmgrs which are members of all connecting clusters.
Using multiple Qmgrs for HA purposes. That's the reason I want to use the WLB facility of the clusters, and therefor Cluster channels, to spread the load over all Hub Qmgrs.
All inter and intra cluster traffic should go via the Hub.
The autodefinition function would bypass the Hub in intracluster traffic. |
|
| Back to top |
|
|
|
|
