| Author |
Message
|
| fjb_saper |
 Posted: Tue Jun 21, 2011 1:03 pm Post subject: |
 |
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
| Bnikpour wrote: |
| I have already moved it and done all the work, I was asking in my original question if there were any known issues or pitfalls I should lookout for while administering the type of system I have created. |
Did you use to do 2 phase commit?
_________________
MQ & Broker admin |
|
| Back to top |
|
 |
| Bnikpour |
| Posted: Tue Jun 21, 2011 1:23 pm Post subject: |
|
|
Novice
Joined: 19 Apr 2011
Posts: 20
Location: Phoenix, AZ
|
Yes all are using 2 phase commit
_________________
Addicted to E-mail, not by choice.
MQ & WAS Admin |
|
| Back to top |
|
|
| mqjeff |
| Posted: Tue Jun 21, 2011 1:36 pm Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
| Bnikpour wrote: |
| Yes all are using 2 phase commit |
So the main challenge with using 2 phase commit is that you have to purchase licenses for the Extended Transactional Client if you move an application from using Bindings to using Client connections.
This license is not significantly cheaper than the license for a full queue manager.
There are caveats for this depending on what KIND of application you are using - for example if your app is a JEE app running under WAS, you don't need the ETC. |
|
| Back to top |
|
|
| Bnikpour |
| Posted: Tue Jun 21, 2011 1:42 pm Post subject: |
|
|
Novice
Joined: 19 Apr 2011
Posts: 20
Location: Phoenix, AZ
|
Lucky for me its all J2EE running under WAS then . Though I will admit I was not aware of that fact before. 
_________________
Addicted to E-mail, not by choice.
MQ & WAS Admin |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Tue Jun 21, 2011 1:42 pm Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9472
Location: US: west coast, almost. Otherwise, enroute.
|
| Bnikpour wrote: |
| I have already moved it and done all the work, I was asking in my original question if there were any known issues or pitfalls I should lookout for while administering the type of system I have created. |
What is the it you have moved?
More queues = more disk space and more storage (RAM). More workload = more processors. More gets/puts (in UofWs) means more logging = more disk space. More applications = more users = more security.
_________________
I like deadlines. I like to wave as they pass by.
ב''ה
Lex Orandi, Lex Credendi, Lex Vivendi. As we Worship, So we Believe, So we Live. |
|
| Back to top |
|
|
| Bnikpour |
| Posted: Tue Jun 21, 2011 2:00 pm Post subject: |
|
|
Novice
Joined: 19 Apr 2011
Posts: 20
Location: Phoenix, AZ
|
| bruce2359 wrote: |
| Bnikpour wrote: |
| I have already moved it and done all the work, I was asking in my original question if there were any known issues or pitfalls I should lookout for while administering the type of system I have created. |
What is the it you have moved?
More queues = more disk space and more storage (RAM). More workload = more processors. More gets/puts (in UofWs) means more logging = more disk space. More applications = more users = more security. |
The it is moving the multiple QM's on each box to a single qm and then using client connections. I understand that the box with the now singular QM will require more horsepower but its a development environment where there is maybe a combined total message flow of 10,000 messages a day. The old architecture was WAY overkill...
We love hardware, which honestly was part of the problem to begin with to many cores, to many processors = to many licenses. We weren't seeing the need for so many QM's cause they were barley seeing any load.
I'm honestly pretty optimistic that we fire this new architecture up and all goes without a hitch, but I still wanted to see if anyone had seen a glaring issue with administration after we fire the new system up that I had not taken into account.
You all have been tremendously helpful and I even picked up a few things I didn't know. Thanks!
_________________
Addicted to E-mail, not by choice.
MQ & WAS Admin |
|
| Back to top |
|
|
| mvic |
| Posted: Tue Jun 21, 2011 3:05 pm Post subject: |
|
|
Jedi
Joined: 09 Mar 2004
Posts: 2080
|
| Bnikpour wrote: |
| barely seeing any load. |
Someone cares about load in a dev environment? Fair enough. Some people have development environments that are as tightly managed and SLA'd as most prod environments I have seen.
Save licence cost... great idea, worthwhile for sure. But what in fact is your concern at this point? |
|
| Back to top |
|
|
| Bnikpour |
| Posted: Wed Jun 22, 2011 8:55 am Post subject: |
|
|
Novice
Joined: 19 Apr 2011
Posts: 20
Location: Phoenix, AZ
|
Just wanted to see if anyone had any input on how administration might be impacted with such a large main queue manager.
Most of the concerns I got back where thankfully things I had thought of when building the new architecture out.
I've also decided to go forward using M071 for the administration.
_________________
Addicted to E-mail, not by choice.
MQ & WAS Admin |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Wed Jun 22, 2011 10:16 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9472
Location: US: west coast, almost. Otherwise, enroute.
|
| Bnikpour wrote: |
| Just wanted to see if anyone had any input on how administration might be impacted with such a large main queue manager. |
I don't know if your new qmgr is large or not.
If the original qmgrs were lightly loaded (few queues, few messages, few applications), then having one larger qmgr might not be all that large after all. Numbers please.
If each/every of the 30 qmgr processed 1000 messages per minute, then the new qmgr now process 30,000 messages per minute. This is neither large nor small until you look at how the hardware platform and o/s are provisioned. Insufficient RAM? Insufficient disk space? Insufficient processors?
_________________
I like deadlines. I like to wave as they pass by.
ב''ה
Lex Orandi, Lex Credendi, Lex Vivendi. As we Worship, So we Believe, So we Live. |
|
| Back to top |
|
|
| Bnikpour |
| Posted: Thu Jun 23, 2011 7:46 am Post subject: |
|
|
Novice
Joined: 19 Apr 2011
Posts: 20
Location: Phoenix, AZ
|
I meant "large" in the sense that it contains more queues and channels than the old configuration.
Numbers:
Hardware:
2- P770 2cpu 2GB RAM ( CPU pooling)
OS:
AIX v6
Disk space:
Variable
Side Note:
AIX though expensive, is a remarkable operating system.
_________________
Addicted to E-mail, not by choice.
MQ & WAS Admin |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Thu Jun 23, 2011 8:08 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9472
Location: US: west coast, almost. Otherwise, enroute.
|
I'm somewhat smitten with AIX, too. I'm now getting my hands into SUSE Linux, and having a bit of fun there.
Size and shape of the workload determines large or small for me.
A single qmgr with many queues seems to me to be easier to administer, than many qmgrs with fewer queues per qmgr.
_________________
I like deadlines. I like to wave as they pass by.
ב''ה
Lex Orandi, Lex Credendi, Lex Vivendi. As we Worship, So we Believe, So we Live. |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Thu Jun 23, 2011 4:24 pm Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
Not really a Hub and Spoke, but an "MQ Client Concentrator".
Security - each client should have its own channel tagged with a unique ID in the MCAUSER field. Each unique ID has access to only the queues needed for that client. SSL or an Exit insures that each channel can only be used by the intended client. If each spoke is to have the same exact access to the same common queue(s), they can share a client channel.
Otherwise secure the QM as you would any other.
Max Channels - with all these clients connecting to one QM, you have to make sure any one client doesn't go loopy and suck up all the connections. The more clients you have, the greater the risk of this. In MQ 7 you can use a channel attribute to limit the instances. In all versions of MQ, a security exit like Capitalware's MQAUSX can limit these channels and provide great logging of connection activity.
Pay attention to Max Q Depth and Max Q Size. Oversize your storage and your logs. Disk space is cheap. Outages are not. The more apps sharing the same QM, the more chance for one to go loopy and take everyone out of the water.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
|
|
