Re: Active Directory Question
From: Al Mulnick (amulnick_No_SPAM_at_ncDOTrr.com)
Date: 03/02/05
- Next message: Dean Wells [MVP]: "Re: Kerberos v. AD"
- Previous message: Drew: "RE: how to modify A Distinguish Name or CN of an objetc user from"
- In reply to: Craig Matchan: "Re: Active Directory Question"
- Messages sorted by: [ date ] [ thread ]
Date: Tue, 1 Mar 2005 21:39:56 -0500
Craig, if you need something after you've read the books etc, feel free to
drop an email if I can be helpful.
Good luck,
al
"Craig Matchan" <cwigster@spammenot-swiftdsl.com.au> wrote in message
news:eF6xWGrHFHA.2620@tk2msftngp13.phx.gbl...
> Hi Al,
>
> thanks for a very thorough reply. You raise some good points. I am not
> sure how much control/say we will have in the main application, all the
> soltutions seem to be "off the shelf". Once I know the actual short list I
> can then start researching them and hopefully find out how much they abuse
> AD.
>
> If we go the .NET / AD solution I am hoping to get away with 2 DCs max.
> I'm going to have to read up on AD alot more as it's not my native
> directory services product..I've just sort of inherited the role from
> being a ex Banyan Vines person. In all honesty we will probably have to
> bring on a consultant to advise us on certain aspects. I know a bit about
> AD, but I'm smart enough to know I'm not an expert and to know when you
> know yuu need help.
>
> Thaks for you thoughts.
>
> Craig
>
>
> "Al Mulnick" <amulnick_No_SPAM@ncDOTrr.com> wrote in message
> news:ei6njwfHFHA.4032@TK2MSFTNGP12.phx.gbl...
>> "As to whether we go smaller servers to spread the load or a large unit
>> has not been decided yet. "
>>
>> I'm usually a fan of spreading them out depending on how the application
>> works with AD.
>> Some applications pick a domain controller and don't spread the load.
>> Others are able to take advantage of AD's distributed multi-master nature
>> and in your case it would be a good idea to find out which this will be.
>>
>> Since you're using it for authentication and authorization of an
>> application you'll need to know how the app will behave before you can
>> finalize the specs. If you won't often perform update transactions, then
>> separating the log files might not have as much of a benefit for you as
>> other shops that do more "normal" administrivia. However, in that
>> situation you may benefit from placing the DIT on separated spindles.
>> This may be more important to you for performance than processor {beyond
>> dual proc machines.} Depending on the chipset and memory ability (are
>> you going to cache as much of the directory as you can vs. have to read
>> it from disk, etc).
>>
>> When sizing, there is not any one metric that gives the total performance
>> picture. That's because you're bottlenecks can occur anywhere in the
>> stack if you're not careful. Network, disk, memory, cpu etc. In your
>> case, with <5K users at a time only doing authentication and
>> authorization would normally be a job for a single server, possibly
>> dual-proc with decent disk layout and some memory (some environments
>> anyway). However, if your app is poorly written or inefficient at the
>> least, it can take more resources meaning you need more horsepower. The
>> unexpected rise and fall begin to need to be accounted for. Other apps
>> take some resources as well, such as DNS (integrated or not?) etc. All
>> of this might point to more than one if the app is able to spread the
>> load, or one larger machine if not.
>>
>> As for replication of information, it's a lot better now in 2003 going
>> down to the attribute level. That should not be nearly as much of a
>> concern to your design especially since you mentioned that you won't be
>> changing much data on a regular basis. Logon information is kept local
>> for the most part.
>>
>> A dual-nic DC config is generally not recommended for various reasons.
>>
>> My advice would be to find out more about how the app is architected and
>> developed before finalizing the hardware expectations.
>>
>> Al
>>
>> "Craig Matchan" <cwigster@spammenot-swiftdsl.com.au> wrote in message
>> news:unxHQPSHFHA.3484@TK2MSFTNGP12.phx.gbl...
>>> Hi all,
>>>
>>>
>>>
>>> Thanks for you comments so far. As far as I know, the actual scope of
>>> the project is still be defined so it's hard to give any more concrete
>>> definitions, but at this point in time AD's main role will be simply for
>>> authentication/permission purposes. Other possible solution being looked
>>> at use LDAP, but one solution is .NET based and requires an AD tree
>>> (possibly via LDAP compatibility calls, not 100% sure). At some point
>>> later on other applications may hook into the AD, but once again nothing
>>> specifically has been mentioned. I expect most of the traffic will be
>>> read (logins) and little in the way up updates/creations apart from the
>>> initial load of the accounts.
>>>
>>>
>>>
>>> As far as production servers go, we tend to purchase IBM Xseries servers
>>> with the full extended onsite 3 yr 24x7 warranty options. As to whether
>>> we go smaller servers to spread the load or a large unit has not been
>>> decided yet. We do have constraints on space in our racks, not to
>>> mention the additional costs for backup licenses to backup the servers,
>>> extra UPS capacity and so on.
>>>
>>>
>>>
>>> As you can see it's still very early days and they might decide to go a
>>> different path, I just needed to know if AD could handle it and what
>>> sort of h/w we would need. I've read that the AD traffic between AD
>>> controllers can get quite high so if a number of AD servers were to be
>>> deployed then a separate subnet would be desirable to accommodate this
>>> traffic. This would mean running multiple NICs on a DCs. Oddly enough I
>>> also recall a MS KB article that advises you not to use multiple NICs in
>>> DCs due to routing loops. You have to love this sort of information. One
>>> article contradicting the other :)
>>>
>>>
>>>
>>> Our current AD is quite small (50 users) and we can manage that on
>>> fairly modest hardware. I just have no experience with an AD tree as
>>> large as what we are planning.
>>>
>>>
>>>
>>> Regards
>>>
>>>
>>> Craig
>>>
>>>
>>>
>>>
>>>
>>>
>>> "Al Mulnick" <amulnick_No_SPAM@ncDOTrr.com> wrote in message
>>> news:%23FeSYHRHFHA.2620@tk2msftngp13.phx.gbl...
>>>> One thing you may also want to consider is how you intend to use the
>>>> DC's. Will there be a lot of third party apps doing deep sub-tree
>>>> searches for accounts? Will there be inefficient authentication and
>>>> authorization? Or will this be all Windows XP SP2 workstations on the
>>>> network with only 5K users at a time concurrent and no GPO's all
>>>> connected by a 100mb ethernet switched network??
>>>>
>>>> Just my $0.04 worth.
>>>>
>>>>
>>>> "Jimmy Andersson [MVP]" <jimmy_NO_SPAM_@mvps.org> wrote in message
>>>> news:OPYNi%23BHFHA.472@TK2MSFTNGP12.phx.gbl...
>>>>> IMHO - Bigger is better :)
>>>>> What kind of budget do you have? Another thing to consider is the
>>>>> support agreement that comes with the machine, if you don't have a
>>>>> support agreement that is.
>>>>> As I said before, I like to have more machines instead of one huge
>>>>> one. What do you prefer?
>>>>>
>>>>> Regards,
>>>>> /Jimmy
>>>>> --
>>>>> Jimmy Andersson, Q Advice AB
>>>>> Microsoft MVP - Directory Services
>>>>> ---------- www.qadvice.com ----------
>>>>>
>>>>>
>>>>> "Craig Matchan" <cwigster@spammenot-swiftdsl.com.au> wrote in message
>>>>> news:OhMkRAhGFHA.1392@TK2MSFTNGP10.phx.gbl...
>>>>>> Hi Jimmy,
>>>>>>
>>>>>> at the moment it will probably be a single site design, but we are
>>>>>> still in the early design stages so it might change, but for now a
>>>>>> single site design is what I am going by. Out of the 80,000 odd
>>>>>> accounts, we don't expect more than 5000 to be active at any one
>>>>>> time.
>>>>>>
>>>>>> Craig
>>>>>>
>>>>>> "Jimmy Andersson [MVP]" <jimmy_NO_SPAM_@mvps.org> wrote in message
>>>>>> news:eQJuyVQGFHA.3928@TK2MSFTNGP09.phx.gbl...
>>>>>>> How do you plan your design? Is all users located in a singel site,
>>>>>>> is there time zone considerations (thinking about peak logons)
>>>>>>> etc... I usually scale out instead of scaling up, this way I get a
>>>>>>> sort of redundancy as well.
>>>>>>>
>>>>>>> Regards,
>>>>>>> /Jimmy
>>>>>>> --
>>>>>>> Jimmy Andersson, Q Advice AB
>>>>>>> Microsoft MVP - Directory Services
>>>>>>> ---------- www.qadvice.com ----------
>>>>>>>
>>>>>>>
>>>>>>> "Craig Matchan" <cwigster@spammenot-swiftdsl.com.au> wrote in
>>>>>>> message news:%23p1mqXHGFHA.1264@TK2MSFTNGP12.phx.gbl...
>>>>>>>> G'day,
>>>>>>>>
>>>>>>>> Just been reading that article. The requirements seem a little
>>>>>>>> high, a quad CPU for every 5000 users. Is that really true? I
>>>>>>>> realise it only mentions 850Mhz CPUs which to me points that this
>>>>>>>> paper is a little old. What are people actually using out there?
>>>>>>>> Unless I am mistaken, given the requirements from this paper I
>>>>>>>> would be looking at a 16 dual/quad CPU server setup. Perhaps I am
>>>>>>>> taking the paper a little to literally? Also, are the number of
>>>>>>>> users quoted active users or just users (active and non active). I
>>>>>>>> doubt we will have all 80,000 users on at once, at most it will be
>>>>>>>> below 5000.
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> Craig
>>>>>>>>
>>>>>>>>
>>>>>>>> "Craig Matchan" <cwigster@spammenot-swiftdsl.com.au> wrote in
>>>>>>>> message news:enOiy8GGFHA.1044@TK2MSFTNGP14.phx.gbl...
>>>>>>>>> G'day Jimmy,
>>>>>>>>>
>>>>>>>>> is that on a single AD tree on a single server or do you need
>>>>>>>>> multiple AD servers with huge amounts of ram? Just need a quick
>>>>>>>>> answer. A rough server config would be welcome, CPU, RAM and HDD
>>>>>>>>> requirements. I won't hold you to them :)
>>>>>>>>>
>>>>>>>>> In the meantime I'll read the articles you pointed to.
>>>>>>>>>
>>>>>>>>> tia
>>>>>>>>>
>>>>>>>>> Craig
>>>>>>>>>
>>>>>>>>> "Jimmy Andersson [MVP]" <jimmy_NO_SPAM_@mvps.org> wrote in message
>>>>>>>>> news:uxxmS$$FFHA.3728@TK2MSFTNGP14.phx.gbl...
>>>>>>>>>> AD has absolutely no problem dealing with 100000+ users. I have
>>>>>>>>>> customers with AD implementations way above that so I know it
>>>>>>>>>> works for a fact.
>>>>>>>>>>
>>>>>>>>>> See this URL for "Planning DC Capacity":
>>>>>>>>>> http://www.microsoft.com/resources/documentation/WindowsServ/2003/all/deployguide/en-us/Default.asp?url=/resources/documentation/WindowsServ/2003/all/deployguide/en-us/dssbj_dcc_hrso.asp
>>>>>>>>>>
>>>>>>>>>> Regards,
>>>>>>>>>> /Jimmy
>>>>>>>>>> --
>>>>>>>>>> Jimmy Andersson, Q Advice AB
>>>>>>>>>> Microsoft MVP - Directory Services
>>>>>>>>>> ---------- www.qadvice.com ----------
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> "Craig Matchan" <cwigster@spammenot-swiftdsl.com.au> wrote in
>>>>>>>>>> message news:uqPMzQ7FFHA.2756@TK2MSFTNGP15.phx.gbl...
>>>>>>>>>>> Hi all,
>>>>>>>>>>>
>>>>>>>>>>> we are looking at a centralised authentication system and are
>>>>>>>>>>> exploring our options. One of the options is to use AD. Although
>>>>>>>>>>> we already run one AD tree, it is relatively small and the
>>>>>>>>>>> proposed new one will have to be able to cope with up to 100,000
>>>>>>>>>>> accounts, possibly more. My question is can a single AD tree
>>>>>>>>>>> cope with this and if so what sort of h/w would be required for
>>>>>>>>>>> it to run with minimal slowdowns? Are there any papers on this
>>>>>>>>>>> topic? Any personal experiences would be most welcome.
>>>>>>>>>>>
>>>>>>>>>>> We are also looking at other LDAP products, but given one of the
>>>>>>>>>>> major apps is possibly going to be .NET based, AD was mentioned
>>>>>>>>>>> as a good single sign-on/authentication platform, although I
>>>>>>>>>>> realise we may not have to use AD for .NET, it never hurts to
>>>>>>>>>>> find out.
>>>>>>>>>>>
>>>>>>>>>>> tia
>>>>>>>>>>>
>>>>>>>>>>> Craig
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>
>>>
>>
>>
>
>
- Next message: Dean Wells [MVP]: "Re: Kerberos v. AD"
- Previous message: Drew: "RE: how to modify A Distinguish Name or CN of an objetc user from"
- In reply to: Craig Matchan: "Re: Active Directory Question"
- Messages sorted by: [ date ] [ thread ]
Relevant Pages
|
