On Monday, May 3, 2004, at 01:46 PM, Quanah Gibson-Mount wrote:
Yes, our HTTP service is also load balanced... If you work with RL Bob
Morgan, it wouldn't surprise me if the software you are using is the
same we are using...
When we initially went to deploy OpenLDAP, we experimented with the
certs and software load balancing, without much luck... perhaps I
should do it some more.
Yes, he's involved, but this load balancing DNS service predates him,
I believe parts of it came from UCLA's "groupd". He has more than once
brought the virtues of Stanford's way to our attention - I think you
use an intermediate alias somewhere? Ours just returns an A record with
a rotating subset of the cluster IPs.
This seems to work OK for OpenDLAP - with only one member in the cluster.
I set that member up with an "ldap.washington.edu" (or something to that
effect) certificate.
For SSL, I expect the client to connect to ldap.washington.edu and not
ever resolve that to ldap01.washington.edu. Well, oddly, one ldapsearch
seems to work fine with ldap01. Others as expected do not work, but
if I can figure out the difference, that may be the answer to the SSL
replication and other cluster-member-specific operations.
For GSSAPI, I expect the client to resolve to a canonical name, and this
seems to happen (I get an ldap/ldap01 ticket.) GSSAPI may be ready to
go. The clients are resolving the name, the only question is when. If
they're taking care of that BEFORE either requesting the ticket or making
the connection, then we're fine, we just need them to connect to the same
host as they got a ticket for. This only shows up as a problem when there
are multiple addresses and they're being shuffled.