| Author |
Message
|
| murdeep |
 Posted: Mon Jul 19, 2010 1:39 pm Post subject: Multi Instance Queue Managers |
 |
|
Master
Joined: 03 Nov 2004
Posts: 211
|
Hello, starting to look at multi instance queue managers on windows. A question regarding the domain group mqm.
Do the nodes where the queue manager gets created have to be domain controllers in order for the domain group mqm to have the same SID? Is there a way to create the mqm group on two workstations where the SIDs would be identical?
My windows support group is pretty adament that the WMQ nodes cannot be domain controllers for security reasons.
Here's the link that doc's the domain controller issue:
http://publib.boulder.ibm.com/infocenter/wmqv7/v7r0/index.jsp?topic=/com.ibm.mq.amqzag.doc/fa70169_.htm |
|
| Back to top |
|
 |
| fjb_saper |
| Posted: Mon Jul 19, 2010 1:51 pm Post subject: Re: Multi Instance Queue Managers |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
| murdeep wrote: |
Hello, starting to look at multi instance queue managers on windows. A question regarding the domain group mqm.
Do the nodes where the queue manager gets created have to be domain controllers in order for the domain group mqm to have the same SID? Is there a way to create the mqm group on two workstations where the SIDs would be identical?
My windows support group is pretty adament that the WMQ nodes cannot be domain controllers for security reasons.
Here's the link that doc's the domain controller issue:
http://publib.boulder.ibm.com/infocenter/wmqv7/v7r0/index.jsp?topic=/com.ibm.mq.amqzag.doc/fa70169_.htm |
From the documentation it looks like it. However nobody said that they couldn't be slave domain controllers. (Like 1 master domain controller, the others are all slaves)? 
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| mqjeff |
| Posted: Mon Jul 19, 2010 3:08 pm Post subject: Re: Multi Instance Queue Managers |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
| murdeep wrote: |
| My windows support group is pretty adament that the WMQ nodes cannot be domain controllers for security reasons. |
What they mean is that they strongly prefer not to go to the extra trouble necessary to provide machines that are running domain controllers to application teams, because it requires an additional set of security controls to ensure that, for example, just because you can log in as the domain mqm user (or a member of the domain mqm group), that you don't then have full rights to manage the domain.
But I don't believe there's a workaround.
You should balance the gain in simplicity of using MI versus using MSCS against the gain in complexity of having to use domain controllers.
More importantly, it is not strictly necessary that the machines be domain controllers for the primary domain in use. You should probably be able to set up a subdomain that only exists and defines users on this pair of machines, and doesn't have privileges in the actual user domain.
Or at least it's an option to discuss with your security team. |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Mon Jul 19, 2010 8:09 pm Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
Jeff, does that also hold true for granting access? i.e. in order for domain\user / domain\group to have the same sid on both machines it needs to be part of that machine's domain? Thinking about setmqaut there... at group or user level...
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| exerk |
| Posted: Mon Jul 19, 2010 9:25 pm Post subject: |
|
|
Jedi Council
Joined: 02 Nov 2006
Posts: 6339
|
I tried it on 'normal' servers, i.e. not Domain Controllers, and it failed miserably (due in no small part because I didn't fully read the documentation and missed the bit about the need for DC's  ) there was just no way to replicate the SID on each server. But that was just my experience, perhaps there is someone out there with the arcane Windows knowledge, that can provide a method to get around it.
fjb_saper, cross-domain trusts may be the answer to your question, and hopefully a more knowledgeable person will be along in a minute and be able to confirm/deny that.
_________________
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 |
|
|
| murdeep |
| Posted: Tue Jul 20, 2010 11:16 am Post subject: |
|
|
Master
Joined: 03 Nov 2004
Posts: 211
|
Ok, so I pitched the sub-domain idea and it was shot down due to being a violation of some standard.
Correct me if I am wrong but this is simply a file access issue. So how about the following.
Node A, local mqm group with SID 123
Node B, local mqm group with SID 456
Create qmgr on Node A.
From Node B give access to all underlying files/filesystems to SID 456. Will this work? Would there be issues with the underlying file if new queues are created?
Basically for me it looks like DC's are out of the question so I am just trying to exhaust all other options before I just say forget it and run an active/active configuration. Not sure MI qmgrs are really that great an idea anyways tbh. |
|
| Back to top |
|
|
| mqjeff |
| Posted: Tue Jul 20, 2010 11:36 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
| murdeep wrote: |
| Ok, so I pitched the sub-domain idea and it was shot down due to being a violation of some standard. |
Are you sure that their standard trumps your business requirement?
| murdeep wrote: |
| Correct me if I am wrong but this is simply a file access issue. So how about the following. |
It's not that simple. |
|
| Back to top |
|
|
| Vitor |
| Posted: Tue Jul 20, 2010 11:50 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| murdeep wrote: |
| Correct me if I am wrong but this is simply a file access issue. So how about the following. |
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| exerk |
| Posted: Tue Jul 20, 2010 12:11 pm Post subject: |
|
|
Jedi Council
Joined: 02 Nov 2006
Posts: 6339
|
| murdeep wrote: |
Ok, so I pitched the sub-domain idea and it was shot down due to being a violation of some standard.
Correct me if I am wrong but this is simply a file access issue. So how about the following.
Node A, local mqm group with SID 123
Node B, local mqm group with SID 456
Create qmgr on Node A.
From Node B give access to all underlying files/filesystems to SID 456. Will this work? Would there be issues with the underlying file if new queues are created?
Basically for me it looks like DC's are out of the question so I am just trying to exhaust all other options before I just say forget it and run an active/active configuration. Not sure MI qmgrs are really that great an idea anyways tbh. |
Consider yourself corrected! I wrote "...I tried it on 'normal' servers, i.e. not Domain Controllers, and it failed miserably (due in no small part because I didn't fully read the documentation and missed the bit about the need for DC's ) there was just no way to replicate the SID on each server...", and it's a SID issue, hence why it needs to be on DC's. If it could be done a different way the documentation would unequivocally state that, but it is absolutely that it can only be done on DC's "...The topic, Windows domains and multi-instance queue managers explains why multi-instance queue managers must run on a domain controller..."
I've just had this fight at 'my' site, they tried all different things to produce an MI queue manager other than on DC's, all of which failed miserably (they didn't believe my sand-box testing was a 'true' test) and finally, after losing weeks of time, they conceded that MSCS was the only way to fulfill their requirement - they still wanted it all within the original time scales of course!
Show this thread to your management. Kick, scream, spit your dummy (or whatever it takes to make them sit up and take notice) but please, do not waste time trying to achieve the unachievable.
Oh, and why active/active? Do you need more than one queue manager, or are you referring to both nodes being active? In which case, as far as the queue manager is concerned, the servers are active (has the queue manager) / passive (can have the queue manager if the other node fails).
_________________
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: Tue Jul 20, 2010 12:13 pm Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
Also, an MI queue manager is *still* an active-passive configuration.
You don't run the same qmgr simultaneously on two machines both of which are simultaneously processing work.
One instance of the qmgr is in a standby mode, not able to process work. |
|
| Back to top |
|
|
| murdeep |
| Posted: Tue Jul 20, 2010 12:31 pm Post subject: |
|
|
Master
Joined: 03 Nov 2004
Posts: 211
|
When I say active/active I mean two queue managers each running concurrently. This is why i am not really a fan of MI since it is active/passive. Why have the expense of h/w just sitting there not being used? I know you save on s/w costs but still a waste of resources imo.
Thanks for the updates I won't waste any effort trying to work around the DC requirement.
And Vitor - was your post really necessary? |
|
| Back to top |
|
|
| Vitor |
| Posted: Tue Jul 20, 2010 12:36 pm Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| murdeep wrote: |
| And Vitor - was your post really necessary? |
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| exerk |
| Posted: Tue Jul 20, 2010 12:37 pm Post subject: |
|
|
Jedi Council
Joined: 02 Nov 2006
Posts: 6339
|
| murdeep wrote: |
| When I say active/active I mean two queue managers each running concurrently. This is why i am not really a fan of MI since it is active/passive. Why have the expense of h/w just sitting there not being used? I know you save on s/w costs but still a waste of resources imo. |
Ditto MSCS (unless you have a second MSCS-controlled queue manager running on the 'passive' side - more expense, e.g. extra disk [ridiculously cheap these days]) and there is nothing to stop you running another MI-queue manager on the 'passive' side, with its take-over node being the other MI-queue manager's 'active' node. You need to think this through a little more perhaps...
_________________
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 |
|
|
| exerk |
| Posted: Tue Jul 20, 2010 12:38 pm Post subject: |
|
|
Jedi Council
Joined: 02 Nov 2006
Posts: 6339
|
| Vitor wrote: |
| murdeep wrote: |
| And Vitor - was your post really necessary? |
|
There's an echo in here...in here...in here 
_________________
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 |
|
|
| Vitor |
| Posted: Tue Jul 20, 2010 12:42 pm Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| murdeep wrote: |
| Why have the expense of h/w just sitting there not being used? I know you save on s/w costs but still a waste of resources imo. |
Because the business in question have determined they'd sooner waste the money on redundant h/w & s/w than lose money waiting for the active failover machine to stop doing what it's doing and start doing what the principle was doing before it failed. This determination is made on factors including (but not limited to) the amount of time taken to failover an active/active against an active / passive, how much money they'd lose in that period & how much money is going to be wasted on a passive node (e.g. if they have a site license for unlimited installs of software the extra cost of the passive is zero).
So in many cases you're quite right & it's a waste. In other cases it's false economy.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
|
|
