If You use *BSD then I suggest relayd. Am 2015-08-28 08:38, schrieb Eileen(=^ω^=):

On Fri, Aug 28, 2015 at 02:38:33PM +0800, Eileen(=^ω^=) wrote: Depending on exactly what you want to achieve, you may not need to run a separate service at all. Much LDAP client software allows you to specify multiple servers, which will be tried in rotation until one answers. This gives protection against unreachable servers. Another option is to put several 'A' or 'AAAA' records in the DNS entry for your LDAP service (use a service-specific name like ldap.example.org rather than the name of the server). Most DNS servers will change the order of records in each reply (round-robin DNS) so your clients are likely to spread their load across all servers and will fall back to a different server if the first attempt does not connect. The solutions above involve TCP timeouts if servers go down, and this may be too slow for you. One way to get around that is to use a service-specific IP address which is shared by two or more servers. Each server monitors the other and will take over the service address if necessary. Note that this does not give you load balancing between the servers: it is a hot-standby system. If you do not trust the client software to work properly with multiple server addresses then you could use OpenLDAP with the LDAP back-end or the META back-end. Both allow you to specify multiple servers and will handle fallback even if clients don't. This configuration has a very low resource requirement so you can run an instance of it on every client machine if you need to. Andrew -- ----------------------------------------------------------------------- | From Andrew Findlay, Skills 1st Ltd | | Consultant in large-scale systems, networks, and directory services | | http://www.skills-1st.co.uk/ +44 1628 782565 | -----------------------------------------------------------------------

Often times client software doesn't support more than one ldap node. A VIP using the same cert as the nodes simplifies things (e.g.: cert name ldapvip with altnames ldap01, ldap02, and ldapvip itself jic). We use ldap pairs (slaves) in all our environments behind VIPs with the active-spare multi-master pair also behind a VIP (which is where the slave nodes connect). This has worked well for us; if the VIP is down then much larger issues are at play, and offers us a lot of flexibility during maintenance let alone being more immune to system issues. TL;DR: get a good load balancing solution, it makes life easier for everything (like apps or services) including ldap. - chris -----Original Message----- From: openldap-technical [mailto:openldap-technical-bounces@openldap.org] On Behalf Of Brent Bice Sent: Wednesday, September 02, 2015 9:45 AM To: openldap-technical(a)openldap.org Subject: Re: load balancer On 09/02/2015 04:10 AM, Andrew Findlay wrote: Yup, this is probably the best/easiest way. 6 or 7 years ago, more as an experiment and proof of concept, I setup multiple OpenLDAP servers in an OSPF anycast. So one, special, IP address could be used but it could be any one of multiple servers that answered. The way an OSPF-anycast works is you have an IP in a normally non-routable subnet ifconfig'd as a secondary IP on each OpenLDAP server. Then each OpenLDAP server runs a routing daemon and does an OSPF route announcement for the service-IP. The routing infrastructure, then, learns of a new route to this service-IP via the various OpenLDAP servers. Usually this is used for services you want to be geographically diverse, where you want one IP to always route to the nearest, UP, server. The routing infrastructure takes care of figuring out which server is the closest and sends the traffic there. Obviously some care has to be taken in how the load-balancing is done by the routers if they have multiple equal-cost routes to the same service-IP, and you have to have some form of watchdog that pulls down the route if the OpenLDAP server is offline for some reason. But in a lab environment, it worked fine for me. Have I mentioned that just making sure your clients support and know about multiple LDAP servers is easier? :-) Brent