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!
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! Ciao, Michael. Giovanni Baruzzi wrote: > > 1. All load balancers support LDAP, No one knows it. > 2. They are designed for the short living connections of http, and not > really apted to manage long living connections as for LDAP > 3. They sacrifice a lot of ressources to manage "persistence", adressing > request coming from the same client to the same server > > That means that you can implement the redudancy only as a system solution, > not only just putting a load balancer. If the clients don't follow the > rules, you won't achieve that > > 1. make sure that the clients which use very long sessions are capable to > check the status of a connection and restart it, if it fails (the > programmers have implemented a pool for the LDAP connections, if a > connections fails, they start again all the configured connections) > 2. make sure that a client retries a connection after the first failure: it > should try at least three times in intervals of say 15 seconds > 3. force the use of LDAPv3 and the automatica supoprt of referrals: this is > extremely useful it you have to maintain the server while providing service > 4. You you can afford it, define 2 network interfaces for every server: one > to deliver service the other for replication and internal use. If you have > to withdraw a server for whatever reason, you can still do work with it. > > After using the above configuration for about 6 Months, we added LDAP > Proxies, because some of the oldest clients could implement the above points > (connectors). > We use now a redudant configuration of load balancers, a redudant > configuration of LDAP-Proxies and an every increasing number of LDAP Server > (operations rates are in the range of hundredrs per second, growing 250% per > year in the last 3 years). > Every serve has separate interfaces to deliver service and for maintenance, > replication. > Expensive, but needed to deliver 24X7. > > Regards > Giovanni > > mit freundlichen Grüßen > > Giovanni Baruzzi > [EMAIL PROTECTED] > > -----Ursprüngliche Nachricht----- > Von: qazmlp [mailto:[EMAIL PROTECTED] > Gesendet: Donnerstag, 12. Oktober 2006 18:07 > An: [email protected] > Betreff: [ldap] Load balancers for LDAP connections?? > > We normally have 10-15 number of LDAP servers running as the Backend > servers. There are multiple applications connecting to it as LDAP clients. > Hence, I would like to setup a Load balancer especially made up for load > sharing the LDAP connections from the LDAP clients. > Could you give some recommendations on the popularly used LDAP load > balancers? --- 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.
