Ken Raeburn wrote: > On Feb 6, 2009, at 11:31, Anh Nguyen wrote: >> Hi, >> Sorry for the following newbies questions, but thanks in advance for >> your comments and suggestions: >> 1. Could we set up multiple KDC per single realm? > > Absolutely; at most sites I think it's the normal way of doing > things. You just set up additional DNS SRV records for the realm, or > (in the MIT client implementation) multiple "kdc = <host>" lines in > the config file. I think MIT's administration manual (or possibly > installation manual, I haven't checked in a while) should describe both. > > With multiple SRV records, unless you set different priorities, the > clients should try the KDCs in random order, thus spreading the load. > With config file entries, for historical reasons, the client will try > them in order, so the second only gets tried if a response doesn't > come back from the first quickly enough, etc. > >> 2. Is it possible to set up multiple independent sets of KDC/realm's >> working against a single database managed by directory server? > > If you use the LDAP database back end, yes, just point all the KDCs in > a realm to the same LDAP server(s) and data. I'm pretty sure you > could also do multiple realms in one LDAP directory, but I don't know > what subtle issues might lie there; I'm more familiar with our more > traditional Berkeley DB back end. > > Technically, with the Berkeley DB back end, you could probably set up > multiple KDCs too, but all KDCs need access to the same DB files, and > for security reasons they probably shouldn't be exported over the net, > so you'd be talking about running multiple KDCs on one machine, which > is not as useful if you're looking to improve availability in cases of > machine failure. > >> 3. Is there a plan to multi-thread KDC? > > Well, that's an interesting question.... It's been discussed, since > waiting for LDAP query results could make your KDC slow down. We've > even had some code donated, but changing a sensitive security service > like the KDC in such a drastic way makes a lot of people nervous for > good reasons (ignoring the actual code we got -- going from a big > single-threaded program with a bunch of global storage to a > multi-threaded program with work queues between different parts is a > significant restructuring and likely to have subtle problems), so > we've held off on it for now, until we can take a better look at the > issue and possible approaches. > > In the meantime, actually, that might be a good use case for running > multiple KDC processes on one host. You could spread out the load > somewhat, among, say, three processes on host A on different port > numbers, and three processes on host B on different port numbers. > You'd be relying on this load-sharing to reduce the problems from LDAP > latency, so you'd really want to go with the SRV records rather than > config file entries. > > I've got a couple other ideas about less drastic code changes we might > be able to make to allow for some parallel processing, by forking the > KDC process, but there are some interactions with the way we're > handling network interfaces that need a little thought. If you're > interested in working on some code, let me know. :-) > > Ken Hi Ken, I'd like to apologize for this very late reply. Your mail was mistakenly filtered to a folder, which I just coincidently checked. Thank you very much for your explanation of the potentials. Regarding the last one for improving concurrency I will certainly relay the message to other teams, and will keep you posted. Thanks again. Anh-
________________________________________________ Kerberos mailing list [email protected] https://mailman.mit.edu/mailman/listinfo/kerberos
