| Author |
Message
|
| belchman |
 Posted: Thu Jan 08, 2009 5:54 am Post subject: Any Gotchas!? MQ for zLinux |
 |
|
Partisan
Joined: 31 Mar 2006
Posts: 386
Location: Ohio, USA
|
I am trying to identify what challenges MQ admins encountered while migrating distributed queue managers hosted on AIX and/or Linux to zLinux.
We are embarking on a consolidation effort where our direction is to have no distributed queue managers any more. The queue managers serving as gateways to the z/OS queue managers will now be on zLinux.
These distributed gateways handle up to 10,000 concurrent connections and process millions of messages per day.
The typical message is a synchronous request/reply pattern that is put as a datagram. The transactions are typically financial data lookups but a good percentage would be inserts/updates.
Any lessons learned from you folks would be appreciated.
Regards
_________________
Make three correct guesses consecutively and you will establish a reputation as an expert. ~ Laurence J. Peter |
|
| Back to top |
|
 |
| zpat |
| Posted: Thu Jan 08, 2009 5:58 am Post subject: |
|
|
Jedi Council
Joined: 19 May 2001
Posts: 5866
Location: UK
|
Why not connect the MQ clients direct to z/OS and cut out the gateway QM's?
At my last company we moved thousands of connections to this model and it worked well.
It did not increase the CPU cost on the mainframe. You can always have multiple queue managers on z/OS if you want some isolation. |
|
| Back to top |
|
|
| belchman |
| Posted: Thu Jan 08, 2009 6:15 am Post subject: |
|
|
Partisan
Joined: 31 Mar 2006
Posts: 386
Location: Ohio, USA
|
zpat,
The reason we do not connect clients directly to the mainframe is probably due primarily to 2 things, fear and distrust.
Distrust of these distributed programmers and the code they write. This distrust leads to the fear that they will somehow cripple the qmgr(s) which would practically bring the organization's production to a standstill until we recover.
I generally tend to believe that things are the way they are because those that put them there did due diligence in making the decision.
Thusly, I assume that the rational for the gateway (or connection concentrator) is sound. I will listen to arguments that suggest that paradigm is obsolete in today's world.
I am generally averse to change simply to prove that I am a change agent. 
_________________
Make three correct guesses consecutively and you will establish a reputation as an expert. ~ Laurence J. Peter |
|
| Back to top |
|
|
| zpat |
| Posted: Thu Jan 08, 2009 6:22 am Post subject: |
|
|
Jedi Council
Joined: 19 May 2001
Posts: 5866
Location: UK
|
Yes, but you can always create new queue managers on z/OS if you are that concerned about things like looping connection attempts.
z/OS can control and manage the resource consumption of individual address spaces with incredible precision, far more than LPARs can do.
MQ on z/OS also allows indexes on queues, which can give better performance for selective message retrieval.
zLinux sounds like a far less well-proven or robust platform for MQ.
z/OS has long been able to protect itself, it's been a shared platform for 40 years or more. |
|
| Back to top |
|
|
| belchman |
| Posted: Thu Jan 08, 2009 6:33 am Post subject: |
|
|
Partisan
Joined: 31 Mar 2006
Posts: 386
Location: Ohio, USA
|
zpat,
Hmmm... currently our production z/OS queue managers are 1 to 1 per LPAR...
That is one production queue manager per LPAR. The queue manager itself is a subsystem on the LPAR with 2GB of memory 1.4GB above the line.
If I triple that to 3 queue managers per LPAR following the same resouce allocation pattern per qmgr, what cost problems will I have?
I know one thing... Admin costs will go up because z/OS MQ admins cost more than distributed MQ admins.
_________________
Make three correct guesses consecutively and you will establish a reputation as an expert. ~ Laurence J. Peter |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Thu Jan 08, 2009 6:58 am Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
We have had a play QM on z/Linux for years. This month we are participating in a POC where we will stand up 6 QMs in an MQ cluster with the z/OS QMs and stress them with a couple of heavy hittin' apps. So far the only concern with z/Linux is that you don't want to house anything that will use tons of CPU or require huge amounts of memeory. A QM moving millions of smallish messages a day should not be a problem.
We too do not allow any clients direct access to the z/OS QMs, for exactly the reasons belchman listed. Another reason a shop may choose to do this is that the CAF is not free. I have no idea how expensive CAF is compared to a Unix server and QM to act as a client concentrator, but I have heard that arguement used. We do have the CAF so its not a issue for us.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| zpat |
| Posted: Thu Jan 08, 2009 7:12 am Post subject: |
|
|
Jedi Council
Joined: 19 May 2001
Posts: 5866
Location: UK
|
Virtual storage is not usually a cost issue. The real storage on the same hardware will cost exactly the same whether you allocate it to z/OS or zLinux.
If you admininster MQ using generic tools (MQ explorer etc) - the platform does not really matter.
The platform specific stuff (logs, pagespace) needs very little intervention once set up.
z/OS even has more features such as an inactive client channel disconnect interval.
I think it's easier to use RACF than OAM controls and it has more security options for MQ.
In terms of not trusting the coders, it is advisable to quality check any new MQ applications before promoting it to production and provide them with best practice guide and sample code. This is really essential regardless of what platform they connect to.
Last edited by zpat on Thu Jan 08, 2009 7:18 am; edited 1 time in total |
|
| Back to top |
|
|
| Michael Dag |
| Posted: Thu Jan 08, 2009 7:14 am Post subject: |
|
|
Jedi Knight
Joined: 13 Jun 2002
Posts: 2607
Location: The Netherlands (Amsterdam)
|
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Thu Jan 08, 2009 7:18 am Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
| zpat wrote: |
| I think it's easier to use RACF than OAM controls... |
| zpat wrote: |
| and it has more security options for MQ. |
This is true.
My goal in 2009 is to really understand RACF for MQ. I'm sure once I start using it it may become easier. Right now its scary confusing stuff.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Thu Jan 08, 2009 7:20 am Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
We plan on using Hipersockets between our z/OS QMs and z/Linux images.
zpat's perspective will be stick with z/OS, and QM to QM communications in a QSG will be even better! (right zpat?)
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| zpat |
| Posted: Thu Jan 08, 2009 7:32 am Post subject: |
|
|
Jedi Council
Joined: 19 May 2001
Posts: 5866
Location: UK
|
Never used QSGs.
I no longer work at a mainframe site but when I did we had one queue manager per z/OS and allowed client apps to connect directly (indeed encouraged them to do so whenever possible).
We never had any problems (at least not in production). The only thing to keep an eye on is channel usage vs maxchannels as a capacity planning requirement (in the same way as any other resource usage).
I think it's now possible to limit the number of client connections from given IP address or range.
Last edited by zpat on Thu Jan 08, 2009 7:35 am; edited 1 time in total |
|
| Back to top |
|
|
| belchman |
| Posted: Thu Jan 08, 2009 7:34 am Post subject: |
|
|
Partisan
Joined: 31 Mar 2006
Posts: 386
Location: Ohio, USA
|
Peter,
When you were doing testing, did you encounter any constraints such as becoming I/O bound or CPU bound while managing a large number of concurrent MQ applications putting to a queue over a large number of SvrConn instances?
Did you have to finagle with max file handles and stuff?
_________________
Make three correct guesses consecutively and you will establish a reputation as an expert. ~ Laurence J. Peter |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Thu Jan 08, 2009 7:57 am Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
We are starting to build the environment now. We have not tested with the app yet.
But I don't anticipate a large number of SVRCONN channels being used in our scenarios at least initially.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| xhaxk |
| Posted: Thu Jan 08, 2009 1:57 pm Post subject: |
|
|
Apprentice
Joined: 30 Oct 2008
Posts: 31
|
| Quote: |
| zLinux sounds like a far less well-proven or robust platform for MQ |
Indeed.
The OS user authentication mechanism is very flaky, particularly where the users are administered under LDAP. The interface from zLinux to LDAP is buggy and unreliable. I wish you the best of luck in getting support from anybody.
I also find it bizarre that you won't allow WMQ client apps to connect to zOS qmgrs because of worries about distributed programmers (!) connecting using a well-tested protocol, but you are willing to trust an O/S written in back bedrooms located in Kansas, Kazakhstan and anywhere in between. |
|
| Back to top |
|
|
| Michael Dag |
| Posted: Thu Jan 08, 2009 2:34 pm Post subject: |
|
|
Jedi Knight
Joined: 13 Jun 2002
Posts: 2607
Location: The Netherlands (Amsterdam)
|
| xhaxk wrote: |
| ... but you are willing to trust an O/S written in back bedrooms located in Kansas, Kazakhstan and anywhere in between. |
isn't it from IBM, supported by IBM 
_________________
Michael
MQSystems Facebook page |
|
| Back to top |
|
|
|
|
