| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
| Consolidating multiple QM's to a single Solaris Zone |
« View previous topic :: View next topic » |
| Author |
Message
|
| LouML |
 Posted: Thu Jan 10, 2013 4:20 am Post subject: Re: Consolidating multiple QM's to a single Solaris Zone |
 |
|
Partisan
Joined: 10 Nov 2005
Posts: 305
Location: Jersey City, NJ / Bethpage, NY
|
| PeterPotkay wrote: |
| LouML wrote: |
..there are a number of business groups involved which might not allow for a single queue manager. |
I assume you are talking about strictly political reasons and nothing technical, assuming the new multiple QMs would share the same O/S? |
Nothing technical, just political. The platform will be a Solaris 10 zone. There are a few business groups, each with a few QM's. Ideally, we could at least merge specific business groups QM's together. One issue is that they don't want to share resources. Even though some queue managers have channels connecting to the same external firm, they want their own channels. I know this can be done within a single QM but they also want separation of queue manager availability. Some groups like to do more weekend DR testing, while other business groups QM's are active almost 24/7.
Also, they want to do as little work as possible to accomplish this. Meaning, all they want to do is change the hostname(port) in the configs (or have me create their new AMQCLCHL.TAB file) and test.
Finally, it's just me. We do not have an MQ team.
_________________
Yeah, well, you know, that's just, like, your opinion, man. - The Dude |
|
| Back to top |
|
 |
| mqjeff |
| Posted: Thu Jan 10, 2013 4:35 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
you should be able to wave the flag of security and convince them that you need to establish a single gateway qmgr to talk to all external parties.
Tell them that their current requirements are in conflict with security best practices and corporate security protocols.
Tell them that their current requirements fully justify a full time MQ team of three people, and that if they wish to continue their current administration team size of "just you", that they need to bow to your expertise or pay for additional staff out of their budget. |
|
| Back to top |
|
|
| LouML |
| Posted: Thu Jan 10, 2013 4:42 am Post subject: |
|
|
Partisan
Joined: 10 Nov 2005
Posts: 305
Location: Jersey City, NJ / Bethpage, NY
|
| mqjeff wrote: |
you should be able to wave the flag of security and convince them that you need to establish a single gateway qmgr to talk to all external parties.
Tell them that their current requirements are in conflict with security best practices and corporate security protocols.
Tell them that their current requirements fully justify a full time MQ team of three people, and that if they wish to continue their current administration team size of "just you", that they need to bow to your expertise or pay for additional staff out of their budget. |
Yeah, I should....
This is a place that does not replace people who've left. They simply pile the work on the the remaining staff.
The best I might be able to do is get a consultant brought in for the duration. I technically have a backup, but he's an MQ novice and has full time work as well.
The single gateway qmgr to talk to all external parties would reside in the DMZ, while the applications QM's would be behind the firewall?
_________________
Yeah, well, you know, that's just, like, your opinion, man. - The Dude |
|
| Back to top |
|
|
| mqjeff |
| Posted: Thu Jan 10, 2013 4:44 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
| LouML wrote: |
| mqjeff wrote: |
you should be able to wave the flag of security and convince them that you need to establish a single gateway qmgr to talk to all external parties.
Tell them that their current requirements are in conflict with security best practices and corporate security protocols.
Tell them that their current requirements fully justify a full time MQ team of three people, and that if they wish to continue their current administration team size of "just you", that they need to bow to your expertise or pay for additional staff out of their budget. |
Yeah, I should....
This is a place that does not replace people who've left. They simply pile the work on the the remaining staff. |
So, it's a corporation just like the rest of them?
| LouML wrote: |
| The best I might be able to do is get a consultant brought in for the duration. I technically have a backup, but he's an MQ novice and has full time work as well. |
That wouldn't be a bad thing. But they're more likely to back off on their requirements than commit to that.
| LouML wrote: |
| The single gateway qmgr to talk to all external parties would reside in the DMZ, while the applications QM's would be behind the firewall? |
Ideally. |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Thu Jan 10, 2013 5:16 am Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
Or, the "Edge" Queue Manager (gateway is a term already used for clustering scenarios) is internal, and you install MQIPT in the DMZ. Your internal QMs talk to your internal Edge QM which talks to your DMZ MQIPT which talks to the other companies. You can then tune that Edge QM for its specific purpose.
If you put a QM in the DMZ, you have the possibility of data at rest in the DMZ if messages queue up. MQIPT does not allow MQ messages to park themselves in the DMZ, and it obfuscates your actual Edge QM's IP and Port details.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| exerk |
| Posted: Thu Jan 10, 2013 5:29 am Post subject: |
|
|
Jedi Council
Joined: 02 Nov 2006
Posts: 6339
|
And to augment further, have a look at Figure 10-1 in this Redbook.
_________________
It's puzzling, I don't think I've ever seen anything quite like this before...and it's hard to soar like an eagle when you're surrounded by turkeys. |
|
| Back to top |
|
|
| mqjeff |
| Posted: Thu Jan 10, 2013 5:30 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
Except MQIPT is an unsupported supportPac without recent updates and a questionable status.
Alas.
And Datapower is not capable of performing the same kinds of functions.
Alas.
Regardless, consolidating external connections to a single queue manager - whether it's in the DMZ or not - is still a really good idea. |
|
| Back to top |
|
|
| LouML |
| Posted: Thu Jan 10, 2013 5:33 am Post subject: |
|
|
Partisan
Joined: 10 Nov 2005
Posts: 305
Location: Jersey City, NJ / Bethpage, NY
|
| exerk wrote: |
And to augment further, have a look at Figure 10-1 in this Redbook. |
I've been neck-deep in this Redbook for a few days now. Really great info.
_________________
Yeah, well, you know, that's just, like, your opinion, man. - The Dude |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Thu Jan 10, 2013 6:28 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9475
Location: US: west coast, almost. Otherwise, enroute.
|
| LouML wrote: |
This is a place that does not replace people who've left. They simply pile the work on the the remaining staff. |
We sympathize. Many of us have been there.
FWIW, I (now) consider myself fortunate that I've lived through this "opportunity" more than once. I was able to expand my skills beyond my interests and comfort zone as others left the organization.
_________________
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 Jan 10, 2013 9:50 am Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
| mqjeff wrote: |
Except MQIPT is an unsupported supportPac without recent updates and a questionable status.
Alas.
|
http://www-01.ibm.com/support/docview.wss?rs=171&uid=swg24006386&loc=en_US&cs=utf-8&lang=en
Why do you say its unsupported? Its not withdrawn. There was a question just today on the list serve from someone at Hursley asking on how many people used a particular feature in it, leading me to believe its actively being looked at.
But I do find it worrisome that it does not say its been updated for MQ 7.1 or 7.5. 
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| mqjeff |
| Posted: Thu Jan 10, 2013 9:58 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
Because I had mistakenly thought it was a category 2 supportpac, not category 3. 
| PeterPotkay wrote: |
| But I do find it worrisome that it does not say its been updated for MQ 7.1 or 7.5. |
Yes, that too.
| PeterPotkay wrote: |
| There was a question just today on the list serve from someone at Hursley asking on how many people used a particular feature in it, leading me to believe its actively being looked at. |
Yes, I suggested offlist that the same question be raised somewhere here to get a wider set of responses... |
|
| Back to top |
|
|
| LouML |
| Posted: Fri Jan 11, 2013 6:32 am Post subject: |
|
|
Partisan
Joined: 10 Nov 2005
Posts: 305
Location: Jersey City, NJ / Bethpage, NY
|
| PeterPotkay wrote: |
mqjeff, does your premise of multiple QMs for load reasons consider that the single QM or multiple QM would still all be on the same server (if I understand The Dude's proposed topology correctly)?
|
To further clarify our design, we're using Solaris zones. Our Production MQ Server (zone1p) will reside on a main server (server1A - along with other Solaris zones). If serverA reboots or fails for some other reason, all zones fail over automatically to server1B.
_________________
Yeah, well, you know, that's just, like, your opinion, man. - The Dude |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Mon Jan 14, 2013 10:54 am Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
| mqjeff wrote: |
| PeterPotkay wrote: |
| But I do find it worrisome that it does not say its been updated for MQ 7.1 or 7.5. |
Yes, that too.
| PeterPotkay wrote: |
| There was a question just today on the list serve from someone at Hursley asking on how many people used a particular feature in it, leading me to believe its actively being looked at. |
Yes, I suggested offlist that the same question be raised somewhere here to get a wider set of responses... |
I just saw the reply from someone at Hursley that MQIPT 2.0 does support MQ 7.5 and they will be updating the webpage where you download that support pack to display that info.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| LouML |
| Posted: Tue Jan 15, 2013 7:33 am Post subject: |
|
|
Partisan
Joined: 10 Nov 2005
Posts: 305
Location: Jersey City, NJ / Bethpage, NY
|
Spent a few days looking over the MQIPT and Secure Messaging docs.
I like the idea of a DMZ server handling the external connections. I also like the MQIPT idea.
I think in the initial migration, we’ll probably just migrate the existing QM’s (possibly merge some smaller into one) to the single server.
The next phase would be to consider using a DMZ server for either an ‘edge’ server or MQIPT or both.
Do I Have the following correct?
The use of MQIPT does not require a QM be installed on the DMZ server. It can just have routes created to pass traffic through to the QM's behind the firewall. If I have 10 QM's on a server behind my firewall, I can setup 10 routes on the DMZ server, each with its own port number to forward the traffic back to the QM's behind the firewall. External clients would just change their CONNAME from our ip(port) to the new MQIPT values, allowing their channel names and QRemote definitions to remain as is.
Would another use be to have a QM in the DMZ and have all external channels terminate there? Then, have channels defined from the DMZ QM back to the QM’s behind the firewall? I guess this would require QRemotes and such. As well as storing data on a DMZ server.
We’re also looking into using Advanced Message Security to encrypt data, but this is also a ways off.
_________________
Yeah, well, you know, that's just, like, your opinion, man. - The Dude |
|
| Back to top |
|
|
| exerk |
| Posted: Tue Jan 15, 2013 7:36 am Post subject: |
|
|
Jedi Council
Joined: 02 Nov 2006
Posts: 6339
|
| LouML wrote: |
Do I Have the following correct?
The use of MQIPT does not require a QM be installed on the DMZ server. It can just have routes created to pass traffic through to the QM's behind the firewall. If I have 10 QM's on a server behind my firewall, I can setup 10 routes on the DMZ server, each with its own port number to forward the traffic back to the QM's behind the firewall. External clients would just change their CONNAME from our ip(port) to the new MQIPT values, allowing their channel names and QRemote definitions to remain as is. |
Yes, you do have it correct.
| LouML wrote: |
| Would another use be to have a QM in the DMZ and have all external channels terminate there? Then, have channels defined from the DMZ QM back to the QM’s behind the firewall? I guess this would require QRemotes and such. As well as storing data on a DMZ server. |
It's that last bit you don't really want to do.
_________________
It's puzzling, I don't think I've ever seen anything quite like this before...and it's hard to soar like an eagle when you're surrounded by turkeys. |
|
| Back to top |
|
|
|
|
|
|
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
|
|
|
|
