| Author |
Message
|
| HonestBroker |
 Posted: Wed Mar 30, 2011 7:04 am Post subject: Use of MQ Clients with Broker Hub |
 |
|
Newbie
Joined: 30 Mar 2011
Posts: 8
|
We use WMB V6 as a hub for messaging, providing the usual routing and transformation functions. There are ~40 applications connected, from 20 separate servers, all running their own MQ Server applications and communicating with the Broker using dedicated MQ Channels.
To achieve cost savings there are proposals to reconfigure some applications to operate as Clients to queues hosted directly on the Broker Queue Manager.
Are there any significant reasons why this architecture should not be implemented? |
|
| Back to top |
|
 |
| lancelotlinc |
| Posted: Wed Mar 30, 2011 7:20 am Post subject: |
|
|
Jedi Knight
Joined: 22 Mar 2010
Posts: 4941
Location: Bloomington, IL USA
|
Please describe your platforms for each of the 40 applications. Also provide a picture of the performance envelope that your Broker server is running on. For example, under peak load, how many messages does it currently process and what CPU, I/O load do you currently see?
_________________
http://leanpub.com/IIB_Tips_and_Tricks
Save $20: Coupon Code: MQSERIES_READER |
|
| Back to top |
|
|
| smdavies99 |
| Posted: Wed Mar 30, 2011 7:36 am Post subject: |
|
|
Jedi Council
Joined: 10 Feb 2003
Posts: 6076
Location: Somewhere over the Rainbow this side of Never-never land.
|
you can always connect the clients to other qmgrs running on the broker server if you don't want to connect the clients directly to the broker.
I'd normally recommend this as a more secure option especially for larger numbers of clients.
In effect, you are moving the outlying qmgrs to the centre.
However there might be some licensing issues.
MQ Licenses are pretty cheap (Especially on x86 CPU's). There might not be much saving in the long term as the admin effort might be a lot higher.
_________________
WMQ User since 1999
MQSI/WBI/WMB/'Thingy' User since 2002
Linux user since 1995
Every time you reinvent the wheel the more square it gets (anon). If in doubt think and investigate before you ask silly questions. |
|
| Back to top |
|
|
| HonestBroker |
| Posted: Wed Mar 30, 2011 7:50 am Post subject: |
|
|
Newbie
Joined: 30 Mar 2011
Posts: 8
|
| lancelotlinc wrote: |
| Please describe your platforms for each of the 40 applications. Also provide a picture of the performance envelope that your Broker server is running on. For example, under peak load, how many messages does it currently process and what CPU, I/O load do you currently see? |
Suffice it to say that we are using WMB as a Corporate Hub, with high availability, performance and reliability requirements. What I am trying to establish is whether the direct connection by Clients to this Corporate hub presents any intrinsic risks. Can a 'rogue' client application compromise the hub in any way that would be protected if that application was connected to a remote Queue Manager? |
|
| Back to top |
|
|
| HonestBroker |
| Posted: Wed Mar 30, 2011 7:55 am Post subject: |
|
|
Newbie
Joined: 30 Mar 2011
Posts: 8
|
| smdavies99 wrote: |
you can always connect the clients to other qmgrs running on the broker server if you don't want to connect the clients directly to the broker.
I'd normally recommend this as a more secure option especially for larger numbers of clients.
In effect, you are moving the outlying qmgrs to the centre.
|
This is worth considering! The outlying qmgrs are kept separate from the Broker qmgr. What are the shared resources that would come into play, file-system, logging, cpu . . . |
|
| Back to top |
|
|
| mqjeff |
| Posted: Wed Mar 30, 2011 7:57 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
If the intent is to save money by reducing MQServer installs, you can put multiple qmgrs on the Broker runtime machines, and then still have the same isolation.
Except that you're now adding load to the broker box. |
|
| Back to top |
|
|
| lancelotlinc |
| Posted: Wed Mar 30, 2011 8:06 am Post subject: |
|
|
Jedi Knight
Joined: 22 Mar 2010
Posts: 4941
Location: Bloomington, IL USA
|
| HonestBroker wrote: |
| lancelotlinc wrote: |
| Please describe your platforms for each of the 40 applications. Also provide a picture of the performance envelope that your Broker server is running on. For example, under peak load, how many messages does it currently process and what CPU, I/O load do you currently see? |
Suffice it to say that we are using WMB as a Corporate Hub, with high availability, performance and reliability requirements. What I am trying to establish is whether the direct connection by Clients to this Corporate hub presents any intrinsic risks. Can a 'rogue' client application compromise the hub in any way that would be protected if that application was connected to a remote Queue Manager? |
You need to address the capacity issue. You are not providing enough information to make some assertions whether or not this is a good idea.
As a general opinion, distribution of workload is the best case for enabling scaling in width and height. People who look at the only cost of a system as license cost are not qualified to make decisions on system architecture. Total cost of ownership involves alot more than license cost.
_________________
http://leanpub.com/IIB_Tips_and_Tricks
Save $20: Coupon Code: MQSERIES_READER |
|
| Back to top |
|
|
| zpat |
| Posted: Wed Mar 30, 2011 10:18 am Post subject: |
|
|
Jedi Council
Joined: 19 May 2001
Posts: 5866
Location: UK
|
40 applications does not sound that much. Capacity is unlikely to be an issue, client channels work much the same as other channels in that sense.
What I would look at are these questions:
1. Are any of these apps using bindings mode and can they be changed to client mode?
2. Do any of these apps have a higher uptime requirement than the hub QM has?
3. Do the apps connect to the QM with a reasonable (but not excessive) frequency?
4. Do they recover from disconnection automatically (reconnect or can use auto reconnect)?
5. Do any of them use 2 phase commit with XA on their current QM?
Of course having more eggs in one basket means that basket should be set up with HA. |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Wed Mar 30, 2011 5:36 pm Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
| smdavies99 wrote: |
| I'd normally recommend this as a more secure option especially for larger numbers of clients. |
Why would it be more secure for the client going to QM1 to get to QM2, versus connecting to QM2 directly over a properly secured SVRCONN channel on QM2?
If MQ clusters are involved, with dynamic reply to queues in play, it could be less secure to have 2 QMs involved. (Due to the required direct access to the S.C.T.Q. for the dynamic Reply To queues.)
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| smdavies99 |
| Posted: Wed Mar 30, 2011 9:29 pm Post subject: |
|
|
Jedi Council
Joined: 10 Feb 2003
Posts: 6076
Location: Somewhere over the Rainbow this side of Never-never land.
|
| PeterPotkay wrote: |
a properly secured SVRCONN channel on QM2?
|
Spot on Peter. However, in these days of point & click (eg MS Active Directory Admin) how many people are left in IT that really understand this? MQ Security is very much regardes as a black/dying art (sorta like CICS programmers who are under 40...)
By using the intermediate QM, you can simplify the security setup. The clients that connect to that QM only get to see the objects defined on that QM. No poison messages landing on SYSTEM.BKR.CONTROL.QUEUE....
You can also control the broker environment more easily.
Want to stop access to the broker? Simply stop the sender channels to the broker QM.
IF there were more people who were skilled in MQ Security then I'd go along with 'connect directly' solution but it is seen as being 'too hard' to do.
_________________
WMQ User since 1999
MQSI/WBI/WMB/'Thingy' User since 2002
Linux user since 1995
Every time you reinvent the wheel the more square it gets (anon). If in doubt think and investigate before you ask silly questions. |
|
| Back to top |
|
|
|
|
