| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
  |
|
| Deploying MQ as a server farm |
« View previous topic :: View next topic » |
| Author |
Message
|
| boydl |
 Posted: Mon Aug 15, 2005 1:07 am Post subject: Deploying MQ as a server farm |
 |
|
Novice
Joined: 05 Feb 2003
Posts: 16
|
It has been suggested that one deployment option that makes business sense (from cost point of view) is to deploy MQ as server farm where it consists of multiple Queue Managers connected in a cluster w Gateway QMgrs fronting these cluster. The client and server application uses Client connection mode to connect to the infrastructure to send & receive messages.
I can see the benefits of this architecture, as it gives:
1. Cost savings from the MQ licensing POV;
2. Some degree of fail over when using client channel tables since we can make the application connect to another gateway if required.
3. Some degree of load balancing
However, I have these doubts:
1. For the server application to "GET" the message, it needs to connect to the hosting queue manager. Since the server application is treated as a client to MQ, it needs to connect to the gateway QMgr. This defeat the purpose, right, since u can only "GET" from a local queue. Is there any way around this?
2. Resource constraints/high utilization since the application needs to poll the queue to get the messages. Is this a valid concern?
I guess, in general, the GET messages is the issue that I need help to tackle. Any advice/suggestion is much appreciated.
Also, is there any other better way to configure a Server farm architecture?
BLim. |
|
| Back to top |
|
 |
| jefflowrey |
| Posted: Mon Aug 15, 2005 5:27 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
What are the goals of the MQ network you're trying to build, or the goals behind the changes you're being asked to make?
I usually do not recommend implementing failover with client connections. It seems a better approach to me to implement vertical or horizontal application scalability, instead. That is, instead of having one instance of an application making connections to one of a set of different queue managers, have several instances of an application each making a connection to one queue manager.
In the architecture you describe, though, one might have each app connect to two queue managers - one for getting and one for putting. Get from one queue manager in the cluster, and put to the gateways. Implement failover for the gateway connection, and retry-or-shutdown for the cluster connection.
But the thing to remember about client connections is that they only save money if the applications do not need XA. The only way to do XA over a client connection is using the Extended Transactional Client - which is licensed at the same rate as a queue manager.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| boydl |
| Posted: Mon Aug 15, 2005 6:58 pm Post subject: |
|
|
Novice
Joined: 05 Feb 2003
Posts: 16
|
Hi Jeff,
First of all, thx for your response...
Well the goal is to
1. reduce the licensing cost (there is no XA requirements in our environment)
2. simplify the managability of the MQ environment. Currently there are numerous MQ installation implemented on the application server and using server-server connection.
3. We would also want to go down the path of utility based computing. With MQ installed and used in numerous sites, we cant control nor monitor their usage.
With the server farm, we hope to centralize all messaging infrastructure and application that requires this service, connect via a client connection mode.
Scaling the apps vertically or horizontally is an approach that we are considering, however, sometimes it is difficult to justify the cost for additional servers to the mgmt.  So we are trying ways to make do with what we have.
| Quote: |
| In the architecture you describe, though, one might have each app connect to two queue managers - one for getting and one for putting. Get from one queue manager in the cluster, and put to the gateways. Implement failover for the gateway connection, and retry-or-shutdown for the cluster connection. |
This is the concern that we are trying to address. If the consuming application is putting via a gateway QMgr, to a queue (say Q) that is hosted in 4 clustered QMgrs, then the providing application will need to connect to all 4 QMgrs to ensure that all messages are retrieved for processing. As for the response, we probably can use the Reply To fields to direct all response to a particular queue on a particular QMgr.
Hence, the channel connections can get pretty messy. The design that I am trying to achieve is to concentrate all client connection to the gateway qmgr(s) for both GET and PUT. Is this achieveable?
regards
BLim |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Tue Aug 16, 2005 3:12 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
Scaling vertically, running more than one copy of the app on the same box, is practically free. It does add load to the box, but that's what you've got the capacity for.
If you do not scale your apps AT LEAST vertically, if not also horizontally, then it does not make any sense to use a cluster. All of the load balancing you are gaining with the cluster, you are immediately losing again with one app reading multiple queues.
_________________
I am *not* the model of the modern major general. |
|
| 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
|
|
|
|
