[38221] in Kerberos
Re: Determening the number of clients per KDC
daemon@ATHENA.MIT.EDU (Sergei Gerasenko)
Mon Apr 16 14:19:43 2018
From: Sergei Gerasenko <gerases@gmail.com>
Message-Id: <971A9580-D920-406D-A7D2-4F5E39ACEE65@gmail.com>
Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\))
Date: Mon, 16 Apr 2018 13:19:23 -0500
In-Reply-To: <87d0yz6tf6.fsf@hope.eyrie.org>
To: Russ Allbery <eagle@eyrie.org>
Cc: kerberos@mit.edu
Content-Type: text/plain; charset="utf-8"
Errors-To: kerberos-bounces@mit.edu
Content-Transfer-Encoding: 8bit
Hi Russ,
Since I don’t know too much about the KDC architecture, sorry for the dilettante questions.
> It's unfortunately been long enough since I've tested this on a system
> running flat out that I don't remember what qps a KDC can do on modern
> hardware, but I would expect it to at least be in the range of 100 qps.
Is that per worker?
Speaking of workers, does MIT Kerberos spawn workers as needed (sort of like apache) or is it capped by the `-w` argument? What’s a good number of workers to start with? 70? 500? 1000?
> General rule of thumb for KDCs is that you want at least a master and a
> replica, and there's no reason not to have the replica serve most of the
> traffic (in other words, I wouldn't go with a standby design).
Ok, to clarify what you mean by the replica serving requests as well, do you mean:
1. Using a VIP that round-robins the requests to the primary and secondary KDC?
2. Or do you mean that half the clients use the master and the other half the slave?
3. Or do you mean that the client itself round-robins between them?
I can only see 2 as a real option because *I think* once a TGT is requested, all TGS requests would need to go to the server that gave the TGT? But I’m rather new to kerberos, so I might be mistaken.
Thanks!!
Sergei
________________________________________________
Kerberos mailing list Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos
