| Author |
Message
|
| hguapluas |
 Posted: Mon Mar 07, 2005 2:34 pm Post subject: Question: Does PR have to have direct channel to FR |
 |
|
Centurion
Joined: 05 Aug 2004
Posts: 105
Location: San Diego
|
I know this sounds basic and that the IBM docs say the answer is yes (from what I read and understand) but I need others to help me on this to satisfy Firewall guys, or straighten me out.
Scenario:
I have many downstream clients (DSCLIENTS) not in the cluster.
A hop point in the cluster between downstream clients and FRs (HOP_PR) [a PR that cannot be made a FR].
Two FRs in cluster (FR).
The downstream clients (DSCLIENTS) want to join the cluster but do not have direct connectivity to the FR.
The plan is to have the DSCLIENTS join the cluster and route their traffic through the HOP_PR to the FR where the processing applications reside.
Must the DSCLIENTS have the ability to create a channel directly to the FR? If so and they can't, what will happen? The powers-that-be want the DSCLIENTS to only be able to create a channel to the HOP_PR, yet, still be able to join and participate in the cluster.
In my test lab, this was not a problem as I had control over the routes but in the prod environment, I need justification to allow the router at the HOP_PR to allow direct MQ traffic from DSCLIENTS to FR.
Justifications, please give me some ammo to feed to the ultra-paranoid super-secure secret-black box firewall folks. Or, can it be 'reliably' done without that direct channel link?
Oh, btw, did I mention that SSL is to be implemented on all channels 
Thanks |
|
| Back to top |
|
 |
| jefflowrey |
| Posted: Mon Mar 07, 2005 2:46 pm Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
If HOP_PR is in the cluster already, then the clients should be fine.
Queues that the clients need to GET from will have to be qlocal on HOP_PR.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| EddieA |
| Posted: Mon Mar 07, 2005 3:03 pm Post subject: |
|
|
Jedi
Joined: 28 Jun 2001
Posts: 2453
Location: Los Angeles
|
| Quote: |
| have the DSCLIENTS join the cluster |
Just for clarification, clients do not "join" a cluster. They connect to a QM, which may, or may not, be a member of a cluster. If the QM is part of a cluster, then that client has the ability to put to any "cluster" queue, no matter which QM in the cluster hosts the queue. And, as Jeff pointed out, they can only get messages from a queue that is local to the QM they have connected to.
Cheers,
_________________
Eddie Atherton
IBM Certified Solution Developer - WebSphere Message Broker V6.1
IBM Certified Solution Developer - WebSphere Message Broker V7.0 |
|
| Back to top |
|
|
| hguapluas |
| Posted: Tue Mar 08, 2005 7:32 am Post subject: |
|
|
Centurion
Joined: 05 Aug 2004
Posts: 105
Location: San Diego
|
'slap slap slap' (myself)
Bad choice of words for DSCLIENT.
These are downstream 'Queue Managers' that want to join the cluster. (It's just that we view them as 'clients' from a service perspective and not an MQ perspective). |
|
| Back to top |
|
|
| Nigelg |
| Posted: Tue Mar 08, 2005 9:03 am Post subject: |
|
|
Grand Master
Joined: 02 Aug 2004
Posts: 1046
|
| To join a cluster a qmgr has to create a manual CLUSSDR channel to a full repos qmgr, and share its own CLUSRCVR channel in the cluster. The first is so that other qmgrs in the cluster can find out about its cluster objects, the second is so that other qmgrs can communicate with it. |
|
| Back to top |
|
|
| hguapluas |
| Posted: Tue Mar 08, 2005 10:23 am Post subject: |
|
|
Centurion
Joined: 05 Aug 2004
Posts: 105
Location: San Diego
|
Thanks Nigelg,
You have confirmed what I thought to be true about QM's joining a cluster.
Cheers, |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Tue Mar 08, 2005 11:25 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
You might consider a pair of overlapping clusters in this case - one cluster for your business QMs and one for your client QMs, that overlap at HOP_QM (which is a PR for business, and possibly a FR for clients).
Then HOP_PR acts as a gateway for both clusters - and prevents your client QMs from needing to connect to your business FRs.
Hopefully someone who has actually implemented an overlapped cluster will give you some tips and things to avoid.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| hguapluas |
| Posted: Tue Mar 08, 2005 11:30 am Post subject: |
|
|
Centurion
Joined: 05 Aug 2004
Posts: 105
Location: San Diego
|
Thanks for the suggestion. We have been toying with the idea of doing overlapping clusters and I am trying to do some work to build a model here to test. If we do this, we would make the outer cluster have an FR on HOP_PR. The big decision would be on where to put the 2nd FR?
Things for me to think about and toy with...
Cheers, |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Tue Mar 08, 2005 11:46 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
Where to put the second FR depends on the network amongst the client QMs.
If these are "internal" QMs, on the same network, then just make one of the QMs an FR, doesn't really matter which.
But if these are really external QMs, that belong to your actual business clients, or act as gateways for your business clients... then don't use a second FR. If they can't reach HOP_PR, they can't do their work anyway...
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
|
|
