KDC worker processes project
ghudson@MIT.EDU
ghudson at MIT.EDU
Thu Sep 16 15:44:39 EDT 2010
I'm beginning a formal review of the KDC worker processes project,
ending next Friday. The project proposal is at:
http://k5wiki.kerberos.org/wiki/Projects/Parallel_KDC
The purpose of this project is to allow better KDC scalability on
multi-processor KDC hosts, or KDC hosts making use of slow database
modules. Possibly controversial aspects of the proposal are:
* The supervisor is very simplistic. It only knows how to propagate
HUP signals to children (all we do on a HUP right now is re-open the
KDC logfile), and how to terminate worker processes if the
supervisor receives a termination signal or any worker process
exits.
(Why terminate all workers when one exits, instead of restarting the
worker? So that the KDC has similar behavior on a crash with or
without worker processes. The goal of this feature is to provide
scalability, not to increase KDC uptime in the face of bugs.)
* If you use worker processes, you don't get network reconfigs. If
your platform supports IPv4 pktinfo (Linux or modern Solaris), this
is not a change in behavior. If your platform does not support
pktinfo, then the KDC will have to be restarted in order to
recognize newly added network interfaces.
* KDB modules will be closed in the supervisor just before forking and
then opened in each child by reinvoking initialize_realms(), which
will re-parse the argument list. I don't think it's a terribly
clean design that we combine argument parsing and realm
initialization, but we have such a tangle of realm options that it's
not trivial to separate them out.
* There won't be automated tests; it's just too hard. There will be
manual tests which will involve some temporary code modifications.
Because we only added this to the 1.9 slate a few months ago when
things had already gotten busy, implementation time is very limited.
So while it's fair to advocate for a more complicated design, also
consider whether the current design is better or worse than the status
quo.
More information about the krbdev
mailing list