| Author |
Message
|
| jefflowrey |
 Posted: Wed Oct 12, 2005 1:55 pm Post subject: Multiple Cluster channels, sanity check. |
 |
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
Well, i've done my homework, and found that you can have at least multiple cluster rcvrs for a single qmgr.
I'm facing a situation where I might want to do this, not for performance sake, but for fault isolation. I have to bridge a cluster across two different networks, each of which has separate name resolution domains. This means that I have a PR on one network that needs to talk to a FR on another network. Well, really, I just need to add a QM to a cluster on the other network.
Because the two networks do not have a common name resolution domain, I have to use IP addresses to establish a connection between the PR and the FR.
But I don't want to force every QM using the FR on the other network to use it's IP address, because it's much better to use DNS names where possible.
So I guess I'm going to create a second clusrcvr on the one FR I want to connect to (I don't have network access to both FRs for the cluster from the PR), and then use that for the PR to connect to the cluster.
Pros? Cons? Am I crazy? Am I on the ball?
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
 |
| wschutz |
| Posted: Wed Oct 12, 2005 4:18 pm Post subject: |
|
|
Jedi Knight
Joined: 02 Jun 2005
Posts: 3316
Location: IBM (retired)
|
So, on the FR two defs:
| Code: |
def chl('to.fr.ipaddr') chltype(clusrcvr) cluster(foo) conname('111.222.333.444')
def chl('to.fr.hostname') chltype(clusrcvr) cluster(foo) conname('frname.com')
|
Then the PRs on the same network use 'to.fr.hostname' and the single PR on the other network uses 'to.fr.ipaddr' ?
Is that the essense of it?
_________________
-wayne |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Wed Oct 12, 2005 4:44 pm Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
| wschutz wrote: |
Then the PRs on the same network use 'to.fr.hostname' and the single PR on the other network uses 'to.fr.ipaddr' ?
Is that the essense of it? |
Yep.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| wschutz |
| Posted: Wed Oct 12, 2005 4:59 pm Post subject: |
|
|
Jedi Knight
Joined: 02 Jun 2005
Posts: 3316
Location: IBM (retired)
|
But... does the new PR (in the non-FR domain) need to send messages to a cluster queue on one of the other PRs (in the FR domain), or will it ony send messages to queues in the FR?
_________________
-wayne |
|
| Back to top |
|
|
| EddieA |
| Posted: Wed Oct 12, 2005 5:24 pm Post subject: |
|
|
Jedi
Joined: 28 Jun 2001
Posts: 2453
Location: Los Angeles
|
We had something similar recently, so I'm not sure that would work. I can't remember all the details, but I think it boiled down to: Doesn't an FR hand out the channels needed to connect to all FRs in the cluster to each new PR that joins. So if a PR joined to another FR, then it would be given both of these channels as a way to connect to this FR.
Wouldn't a better solution be to have a local HOSTS file on certain machines, to ensure that name resolution does work.
Cheers,
_________________
Eddie Atherton
IBM Certified Solution Developer - WebSphere Message Broker V6.1
IBM Certified Solution Developer - WebSphere Message Broker V7.0 |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Wed Oct 12, 2005 5:33 pm Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
| EddieA wrote: |
| Doesn't an FR hand out the channels needed to connect to all FRs in the cluster to each new PR that joins. So if a PR joined to another FR, then it would be given both of these channels as a way to connect to this FR. |
Uh-Huh.
So on every FR QM in the cluster, as well as every possible PR it might talk to, will all need that 2nd CLUSRCVR. But whose to say that FR#1 is going to give your new PR the right channel for all the other QMs? Or maybe it will give it both of them? I would create the IP channels in another cluster. Have overlapping or stacked clusters. This way you have total control of which channels are used for which QMs and queues. If you need queues clustered to both, use a namelist to cluster to. We do this here, not for IP vs. DNS channels, but FAST vs NORMAL channels. Since every QM is in both clusters, I call this stacked clusters. Been working in PROD for years.
| EddieA wrote: |
| Wouldn't a better solution be to have a local HOSTS file on certain machines, to ensure that name resolution does work. |
Don't techinically know how this works, or if it will, but it does seem to be a better idea.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Wed Oct 12, 2005 5:43 pm Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
Actually, I don't that this will work unless you do put both channels in separate clusters. Consider this:
FR1 has TO.FR1.IP and TO.FR1.DNS as its 2 CLUSRCVRs, both in the same cluster.
New PR Qm has 1 CLUSRCVR, called TO.PR1.IP. It creates a CLUSSNDR to FR1 called TO.FR1.IP. At this instance, we have a problem, because the manual CLUSNDR is only used by a PR for the first intro to a FR (and on REFRESH REPOS YES).
So FR1 will shoot back a message to PR1 telling him that all future communications to it should be on Automatic Cluster sender channels based on ????? TO.FR1.IP, or TO.FR1.DNS, or both? Ther eis no way for you to specify what happens at this step.
If you make each in a different cluster, then you can put PR1 in the IP cluster only, and you will be sure it will use the IP channels only.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| wschutz |
| Posted: Wed Oct 12, 2005 5:53 pm Post subject: |
|
|
Jedi Knight
Joined: 02 Jun 2005
Posts: 3316
Location: IBM (retired)
|
That makes sense Peter, but does it address my earlier question?
| Quote: |
| But... does the new PR (in the non-FR domain) need to send messages to a cluster queue on one of the other PRs (in the FR domain), or will it ony send messages to queues in the FR? |
The PR in one domain wouldn't be able to resolve the dns of a PR in the other.
_________________
-wayne |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Wed Oct 12, 2005 6:15 pm Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
Well. Clustering, for the most part, is already overengineering for this particular problem (I only need to workload balance a *single* queue on one of the FRs, for use by the other FR and the one PR). So Overlapped clusters would be horrendously overengineered and complicated.
So I guess I will switch the clussdr to use the IP address, and deal with the fairly minor pain when/if the address ever changes, rather than trying to limit that.
And when we start getting to the point where we're putting in environment level clusters, rather than app level clusters, I'll readdress the issue...
Thanks for the sanity check.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Wed Oct 12, 2005 6:18 pm Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
But before I mark this as "SOLVED" or whatever...
Why would it be a bad thing for the second clusrcvr to propagate? Just because it would than continually throw errors everywhere that it can't be started...? (and this would be pretty bad)
I mean, the cluster should still work as long as there is one good path, right?
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Wed Oct 12, 2005 6:24 pm Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
| wschutz wrote: |
That makes sense Peter, but does it address my earlier question?
| Quote: |
| But... does the new PR (in the non-FR domain) need to send messages to a cluster queue on one of the other PRs (in the FR domain), or will it ony send messages to queues in the FR? |
The PR in one domain wouldn't be able to resolve the dns of a PR in the other. |
Right. So the Qms that address each other by DNS are in the DNS cluster and are all in the same domain.
The QMs that address each other by IPs are spread across 2 domains that don't have name resolution and are in the IP cluster.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Wed Oct 12, 2005 6:29 pm Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
| jefflowrey wrote: |
| Well. Clustering, for the most part, is already overengineering for this particular problem (I only need to workload balance a *single* queue on one of the FRs, for use by the other FR and the one PR). So Overlapped clusters would be horrendously overengineered and complicated. |
a *single* q on a *single* QM, that happens to be a FR?
If yes, the heck with clustering the new "PR".
Just create good ol' fashioned SNDR RCVRs between the new QM and the existing FR, and use IPs on those channels.
| jefflowrey wrote: |
Why would it be a bad thing for the second clusrcvr to propagate? Just because it would than continually throw errors everywhere that it can't be started...? (and this would be pretty bad)
I mean, the cluster should still work as long as there is one good path, right? |
 Don't know what would happen here. Would MQ be smart enough to start using the IP channel if the DNS channel was always retrying? I would still prefer separate stacked clusters, just to keep it clear. If you even need clustering for this new QM.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| EddieA |
| Posted: Wed Oct 12, 2005 9:37 pm Post subject: |
|
|
Jedi
Joined: 28 Jun 2001
Posts: 2453
Location: Los Angeles
|
| Quote: |
| Just because it would than continually throw errors everywhere |
As long as your monitoring for channels in retry ignores these. 
Cheers,
_________________
Eddie Atherton
IBM Certified Solution Developer - WebSphere Message Broker V6.1
IBM Certified Solution Developer - WebSphere Message Broker V7.0 |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Thu Oct 13, 2005 3:23 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
| EddieA wrote: |
| As long as your monitoring for channels in retry ignores these. |
Monitoring? Yes, we need some.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Thu Oct 13, 2005 4:07 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
| PeterPotkay wrote: |
| jefflowrey wrote: |
| Well. Clustering, for the most part, is already overengineering for this particular problem (I only need to workload balance a *single* queue on one of the FRs, for use by the other FR and the one PR). So Overlapped clusters would be horrendously overengineered and complicated. |
a *single* q on a *single* QM, that happens to be a FR?
If yes, the heck with clustering the new "PR".
Just create good ol' fashioned SNDR RCVRs between the new QM and the existing FR, and use IPs on those channels. |
Actually, I misspoke.
Two app server qms (each on different networks) need to send requests to a single backend server (on one of the networks). The reply queues for the apps, have a fixed name, so I can't use QRemotes.... And rather than screwing around with QM aliases, I'm screwing around with clustering.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
|
|
