[Samba] 1 BDC per 50 Clients? Can that really be true? (HOWTO)

[John H Terpstra]

On Thursday 27 January 2005 10:16, D Canfield wrote:
> In "the 500 user office" section of the Samba Guide,  John Terpstra
> lists some seriously disappointing numbers for Samba scalability.  To

Seriously misleading I would say! Let's punish him today. What shall we do to 
make him pay for the error of his ways? :)

> quote, "As a general rule, there should be at least one Backup Domain
> Controller per 50 Windows network clients. The principle behind this
> recommendation is the fact that correct operation of MS Windows clients
> requires rapid network response to all SMB/CIFS requests. The same rule
> says that if there are more than 50 clients per Domain Controller they
> are too busy to service requests."

That is a typo, see opening comments in Chapter 6 to get a clearer picture. I 
have fixed this in the sources now. The number should be 150, not 50.

Are you getting failed logon attempts? If not, then what is your worry?
The number of BDCs required depends entirely on what each client is doing.
I know of sites that have over 800 clients running of one PDC and no BDC, and 
they experience no logon failures. On the other hand, if all 800 clients were 
to attempt to logon at once there would be likely be mayhem with logon 
failures.

So, if you would like to propose a more appropriate update to the 
documentation please send it to me.

>
> Our lab manager has read this document, and believes that we need to add
> 19 more servers to a domain that is currently served by one box in order
> to "do things right." 

"Getting it right" means avoiding failures. Do you have any log file evidence 
that your current infrastructure is inadequate? How are your users suffering 
today? If no failures are being reported why do you need to add more BDCs?
The rules are not cast in stone - they never were!

> It seems to me that this quote must simply must be 
> a typo, or that it's somehow horribly out of context (the example is
> discussing a multi-office configuration with a 15Mb uplink afterall), as
> it is completely inconsistent with what I've seen myself or read
> elsewhere.
>
> We currently have 400 lab machines as domain members, plus another 500
> or so non-domain windows clients (used by office personnel) with up to
> 250 of those total clients using the server simultaneously (we use it
> mostly for file sharing and domain logins, very rarely do we run
> applications from the shares).  At this point, our samba server sits
> idle for the most part when serving all of those machines.. no memory,
> disk, or CPU bottlenecks that I can see.  We would like to add those
> remaining 500 clients to the domain (mainly just because we can't find a
> way for non-domain machines to edit ACL's on shares), and while I agree
> that it's time for us to add a BDC for good measure, disagreement over
> the scalability has become a sticking point.

Have at least one BDC per segment. Add additional BDCs are needed only.
Infrastructure what you need - not to meet some magic formula.

>
> I've read on this list people discussing thousands of domain members
> with hundreds of simultaneous users, and nowhere else have I seen
> anything even close to this 50-users per BDC number.  And if you think
> about it, if these machines are going to be too busy handling domain
> communication traffic, wouldn't that mean that 20 servers/1000 clients
> would practically saturate a typical  network just sitting idle? 

The background chatter will not be significant on 100Mb/s backbone or greater.

> Can someone shed some light on this for me?

I think I did above. Thanks for spotting the bug that escaped the edit cycle.
I believe the coverage in Chapter 6 should have been the give-way to the fact 
that this is a typo. Apologies for causing so much pain.

Cheers,
John T.
-- 
John H Terpstra
Samba-Team Member
Phone: +1 (650) 580-8668

Author:
The Official Samba-3 HOWTO & Reference Guide, ISBN: 0131453556
Samba-3 by Example, ISBN: 0131472216
Hardening Linux, ISBN: 0072254971
Other books in production.