| Author |
Message
|
| echoesian |
 Posted: Thu Feb 21, 2013 5:21 am Post subject: Gateway Queue Manager is it Necessary? |
 |
|
Apprentice
Joined: 30 May 2008
Posts: 33
|
Would like to seek for your expert opinions on this.
For MQ load balancing on two QMs - QM1 and QM2, all I need to do is to set the Default bind type to "Not fixed" and CLWL use queue to "Any" on the cluster queues on both QMs. When MQ clients put messages on QM1, the messages will send to QM1 and QM2 in a round robin manner.
On some of the MQ cluster deployments, they are actually putting a QM called Gateway Queue Manager in front of the QM1 and QM2 that acts as a load balancer.
I would like to know what is the difference between both methods, and what are the pros and cons? Appreciate for your advise, thanks. |
|
| Back to top |
|
 |
| mqjeff |
| Posted: Thu Feb 21, 2013 5:25 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
Version 6 and earlier of MQ did not allow for CLWLUSEQ.
Architectures built before the addition of this function required gateway approaches.
Architectures built after the addition of this function do not *require* gateway approaches.
Security considerations across an entire MQ architecture can make both of the above approaches entirely invalid.
So just because a specific architecture is built in a specific way that either takes advantage of a specific feature or ignores a specific feature does not in any way mean that the architecture is correct or not correct. |
|
| Back to top |
|
|
| echoesian |
| Posted: Thu Feb 21, 2013 5:38 am Post subject: |
|
|
Apprentice
Joined: 30 May 2008
Posts: 33
|
I just thought this might be one of the advantage using a Gateway:
If I were to use the V6 onwards method, let's say a MQ client application is putting a message to QM1, but if QM1 Listener is down, client applications will receive MQRC 2538 (MQRC_HOST_NOT_AVAILABLE).
However, if using Gateway approach, the transaction still continues because it will be able to route to the QM2. |
|
| Back to top |
|
|
| mqjeff |
| Posted: Thu Feb 21, 2013 5:46 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
| echoesian wrote: |
I just thought this might be one of the advantage using a Gateway:
If I were to use the V6 onwards method, let's say a MQ client application is putting a message to QM1, but if QM1 Listener is down, client applications will receive MQRC 2538 (MQRC_HOST_NOT_AVAILABLE).
However, if using Gateway approach, the transaction still continues because it will be able to route to the QM2. |
In all architectures, you need to account for the availability of queue managers that applications are connecting to.
There's nothing specific about the gateway approach that means that the gateway queue manager will be more available than the other queue managers. |
|
| Back to top |
|
|
| echoesian |
| Posted: Thu Feb 21, 2013 5:57 am Post subject: |
|
|
Apprentice
Joined: 30 May 2008
Posts: 33
|
| From the security perspective, would it be more effective if using Gateway as the front line of defense at least considering that the backend Clustered QMs which might be running WMB as the mission critical ESB? |
|
| Back to top |
|
|
| mqjeff |
| Posted: Thu Feb 21, 2013 6:02 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
| echoesian wrote: |
| From the security perspective, would it be more effective if using Gateway as the front line of defense at least considering that the backend Clustered QMs which might be running WMB as the mission critical ESB? |
It depends on the security perspective. |
|
| Back to top |
|
|
| echoesian |
| Posted: Thu Feb 21, 2013 6:13 am Post subject: |
|
|
Apprentice
Joined: 30 May 2008
Posts: 33
|
| Anyone please help me, the client is asking what is the need of the Gateway QM. They want to know what is the pros and cons. I cannot pull back and saying Gateway is not needed anymore because I have already proposed it earlier on. Please advise... |
|
| Back to top |
|
|
| mqjeff |
| Posted: Thu Feb 21, 2013 6:25 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
I'm not trying to be obtuse or unhelpful.
If you have proposed the gateway earlier, you should have had reasons to do so.
If you articulate those reasons, and the customer says those reasons do not apply, then the gateway is not needed.
And there's no reason you are "wrong" for changing your mind about this. You made a proposal based on reasons, the customer said those reasons don't apply.
One possible reason for using a gateway is indeed to provide a point of security control - to isolate and abstract security roles and policies on one side of the gateway from roles and policies on the other.
But if customer has absolutely no need for any security at all, then they don't need a gateway to act in this manner.
But if the customer has no need for any security at all, then the customer doesn't understand what they are doing, and you should assert that security is required as a matter of practice. |
|
| Back to top |
|
|
| echoesian |
| Posted: Thu Feb 21, 2013 6:37 am Post subject: |
|
|
Apprentice
Joined: 30 May 2008
Posts: 33
|
| mqjeff wrote: |
I'm not trying to be obtuse or unhelpful.
If you have proposed the gateway earlier, you should have had reasons to do so.
If you articulate those reasons, and the customer says those reasons do not apply, then the gateway is not needed.
And there's no reason you are "wrong" for changing your mind about this. You made a proposal based on reasons, the customer said those reasons don't apply.
One possible reason for using a gateway is indeed to provide a point of security control - to isolate and abstract security roles and policies on one side of the gateway from roles and policies on the other.
But if customer has absolutely no need for any security at all, then they don't need a gateway to act in this manner.
But if the customer has no need for any security at all, then the customer doesn't understand what they are doing, and you should assert that security is required as a matter of practice. |
Could you elaborate more on the security policies? I can't seem to imagine how to control the security roles by having an intermediate QM in between. Thanks. |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Thu Feb 21, 2013 7:15 am Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7717
|
| mqjeff wrote: |
But if customer has absolutely no need for any security at all, then they don't need a gateway to act in this manner.
|
"...in this manner." That is a very important part of the sentence, as mqjeff is not saying that having a gateway means you are automatically secure, and not having a gateway means you cannot be secure.
Having a Gateway QM in your MQ Cluster topology (for whatever reason) does allow you some security related options to be implemented at that Gateway QM, which may or may not be easier / possible to do without that Gateway QM, depending on exactly what you are trying to secure against.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| mqjeff |
| Posted: Thu Feb 21, 2013 7:19 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
Every time a message crosses from one queue manager to another, it is being PUT to another queue.
This means that it can undergo name resolution of the destination it is addressed to.
This means that the names of it's destination objects can refer to local objects that have security applied to them.
In addition, it means that the message has passed across a channel. This channel can have security rules applied to it to change the user that is associated with the message, so that when the message is PUT to the newly resolved destination, the security rules in effect apply to a new user.
So if I write an application and it runs as user A, and connects to QM1.
When I put the message to a qremote XYZ on QM1, I do so as user A, and am authorized to put or not put messages to XYZ.
The message then moves across a channel to QM2. the receiver channel on QM2 has an MCAUSER of B. The message channel agent resolves the name XYZ according to whatever objects are known to it, which now point to queue ABC.
The message channel agent then attempts to put the message to queue ABC as user B. |
|
| Back to top |
|
|
| echoesian |
| Posted: Thu Feb 21, 2013 7:22 am Post subject: |
|
|
Apprentice
Joined: 30 May 2008
Posts: 33
|
| I heard some cases, for some reasons if there are many client connections connecting to the QM which WMB is running on, most likely the WMB will go down. By introducing a Gateway QM, this problem can be isolated, at least the WMB would not be easily go down and can continue other in flight transactions? Is this true? |
|
| Back to top |
|
|
| mqjeff |
| Posted: Thu Feb 21, 2013 7:27 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
You can't say "most likely".
You can say that any queue manager that has an unexpectedly large number of client connections to it is at risk of experiencing some kind of issue.
But the definition of 'unexpectedly large is exactly "bigger than planned for when the queue manager was built".
There's nothing about configuring a queue manager for Broker that prevents it from being configured to handle a large number of client connections.
But it has to be planned for, or even a small number of client connections is "bigger than planned for when the queue manager was built".
You're asking a lot of questions about how to do basic MQ planning and architecture.
If you don't have a reasonable amount of training on doing MQ planning and architecture, or experience, you should ACQUIRE that training, rather than asking for it here.
Read, think, try, repeat. |
|
| Back to top |
|
|
| Vitor |
| Posted: Thu Feb 21, 2013 7:49 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| echoesian wrote: |
| I heard some cases, for some reasons if there are many client connections connecting to the QM which WMB is running on, most likely the WMB will go down. |
Heard where? Cite sources and post links.
Also define "many". And "some reasons". Don't define your topology based on urban myth.
Any queue manager, running WMB or not, will go down if you run it out of resources.
One effective strategy to prevent "too many" client connections that does involve a gateway queue manager is to configure the queue manager not to accept "too many" connections. Another is to size the queue manager to handle the expected client connection load.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| echoesian |
| Posted: Thu Feb 21, 2013 7:56 am Post subject: |
|
|
Apprentice
Joined: 30 May 2008
Posts: 33
|
| mqjeff wrote: |
Every time a message crosses from one queue manager to another, it is being PUT to another queue.
This means that it can undergo name resolution of the destination it is addressed to.
This means that the names of it's destination objects can refer to local objects that have security applied to them.
In addition, it means that the message has passed across a channel. This channel can have security rules applied to it to change the user that is associated with the message, so that when the message is PUT to the newly resolved destination, the security rules in effect apply to a new user.
So if I write an application and it runs as user A, and connects to QM1.
When I put the message to a qremote XYZ on QM1, I do so as user A, and am authorized to put or not put messages to XYZ.
The message then moves across a channel to QM2. the receiver channel on QM2 has an MCAUSER of B. The message channel agent resolves the name XYZ according to whatever objects are known to it, which now point to queue ABC.
The message channel agent then attempts to put the message to queue ABC as user B. |
But this does not mean that without using Gateway, one cannot do this direct on the Clustered QMs right? I just want to know what are the scenarios that is best suited by employing the Gateway..... at least to justify the use case is workable. |
|
| Back to top |
|
|
|
|
