| Author |
Message
|
| blane99 |
 Posted: Thu Oct 30, 2003 1:57 pm Post subject: design for qmgr consolidation |
 |
|
Apprentice
Joined: 12 Jun 2002
Posts: 41
|
| We are facing a qmgr consolidation effort and I am interested in knowing how others have implemented this re:MQ clients , MQ connections to outside customers/vendors, and local applications. |
|
| Back to top |
|
 |
| vennela |
| Posted: Fri Oct 31, 2003 10:29 am Post subject: |
|
|
Jedi Knight
Joined: 11 Aug 2002
Posts: 4055
Location: Hyderabad, India
|
| What is qmgr consolidation effort |
|
| Back to top |
|
|
| blane99 |
| Posted: Fri Oct 31, 2003 10:52 am Post subject: |
|
|
Apprentice
Joined: 12 Jun 2002
Posts: 41
|
| Some call it a qmgr or mq server consolidation. By this I mean reducing the # of qmgrs and mqservers (say 20) down to 4 qmgrs on 2 clustered (like VCS) machines. With all the variations of MQ applications (client, local) and point to point with vendors/ customers , what are others doing out there to accomodate all these different scenarios? Are they making everyone use the MQ client ? Are they not allowing certain MQ traffic onto this HUB ? etc. |
|
| Back to top |
|
|
| Michael Dag |
| Posted: Fri Oct 31, 2003 11:50 am Post subject: |
|
|
Jedi Knight
Joined: 13 Jun 2002
Posts: 2607
Location: The Netherlands (Amsterdam)
|
that's funny because a.o. lack of control and security issues (java clients ouch...) on the client side we are moving to servers... If moving from
servers to clients, do realise that you have to 'open up' your environment with SVRCONN channels which (if you don't have proper security tools/exits) make you vunarble to intrusion, add to that external connections from customers/vendors I would definetly seperate the environments. To give you more details or advice, more information on connections (from where to where) message traffice (volume and size) is also important.
Michael |
|
| Back to top |
|
|
| blane99 |
| Posted: Fri Oct 31, 2003 12:15 pm Post subject: |
|
|
Apprentice
Joined: 12 Jun 2002
Posts: 41
|
Michael
Thanks for the feedback. I do agree with separating environments and our SVRCONNs will definitly have to have chl exits. The reason why I would want to have all use MQ client is - this way our "hub" will be able to stay a a pure MQSeries server environment and not have to worry about local applications causing major headaches re: bad apps and version control issues. However, that being said, I know there will be some huge volume users that want performance and one does not get that using the MQ client. So, perhaps these type of users will need to be separated out. |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Fri Oct 31, 2003 12:57 pm Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
The other big thing to be aware of is that you can't do two-phase commit with a regular MQ client.
You have to use the transactional client - which is not free.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| Michael Dag |
| Posted: Fri Oct 31, 2003 1:21 pm Post subject: |
|
|
Jedi Knight
Joined: 13 Jun 2002
Posts: 2607
Location: The Netherlands (Amsterdam)
|
Actually I heard the license cost is the same as a QueueManager.
Michael |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Sat Nov 01, 2003 6:16 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
| MichaelDag wrote: |
| Actually I heard the license cost is the same as a QueueManager. |
I don't know what the exact cost is, and I'm sure it varies.
But I do know it's not free. And "The same as a queue manager" is definately not free. I wouldn't purchase a queue manager license for home useage. 
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
|
|
