--On Thursday, October 12, 2006 9:04 PM +0200 Michael Ströder <[EMAIL PROTECTED]> wrote:
HI! I support Giovanni's statement that fail-over should preferrably be implemented in LDAP clients. Because the client really knows what to do if all fails. In practice this means to really teach the developers hard!
Sadly, Stanford has plenty of proprietary software that accesses our LDAP servers.
Regarding TCP-level load-balancers: Typically the servers are located in one data center. IMHO this works quite well for most read-only applications. If you need fail-over for write requests you either need multi-master replication (with lack of data integrity) or some sort of hot-standby server which completely takes over the service. Also with using proxy servers for balancing the requests you should carefully think about your network topology to avoid WAN traffic to other data centers. If you'd like to implement fail-over between different locations probably DNS gets involved. But not simply DNS round robin!
Stanford uses a software load balancer to a pool of replica systems (in our case, we have a single source system for all writes, so we don't worry about applications writing to the directories). The main issue I've found with using the software load balancer is that Java caches the returned IP, so you need to do some junk to get it to do retries if the connection to the system it is talking to fails.
The software we use lets you run external commands on each individual system that help determine the weights, so it is more than simple DNS round robin. For example, in Stanford's case, we have it run a local ldapsearch to verify slapd is running. If it is successful, then it uses the system load to determine the weight. If it is unsuccessful, it makes the weight extremely high, essentially dropping it from the pool.
--Quanah -- Quanah Gibson-Mount Principal Software Developer ITS/Shared Application Services Stanford University GnuPG Public Key: http://www.stanford.edu/~quanah/pgp.html --- You are currently subscribed to [email protected] as: [EMAIL PROTECTED] To unsubscribe send email to [EMAIL PROTECTED] with the word UNSUBSCRIBE as the SUBJECT of the message.
