[Date Prev][Date Next] [Chronological] [Thread] [Top]

Re: server unavailable in proxy backends

> ldap-mail1: ldap1 (1), ldap2 (10), ldap3 (100), ldap4 (1000), ldap7 (1000)
> ldap-mail2: ldap2 (1), ldap3 (10), ldap1 (100), ldap5 (1000), ldap8 (1000)
> ldap-mail3: ldap3 (1), ldap1 (10), ldap2 (100), ldap6 (1000), ldap9 (1000)

This sounds like DNS load balancing. Consider when ldap{1,2,3,4,7} are
down, and therefore your entire ldap-mail1 DNS alias is toast, you still
need an algorithm to drop down to ldap-mail2--which I interpreted as the
question at hand, and (I think, but please point out flaws) could be
addressed at the application level by any of the responses on this thread.

We do use hardware load balancing. "Inside" the IP of data-center,
backup-center, and (probably not, but it could be) offsite, there will be
many slaves available. However, when data-center turns into a big crater
in the ground for unforeseen reasons, or when data-center turns into a
black hole on the network for foreseen reasons, you still need an
mechanism to drop down to geographically alternative servers.

One could, of course, handle this from under OpenLDAP's feet. An example
of this would be if your geographically redundant DNS servers performed
network monitoring and changed the pool, or if my routers and load
balancers used a protocol like HSRP/VRRP to move the service IP to the
data center that isn't a crater. However, with most protocols, there is a
significant advantage to having application layer awareness of such
things. This might include sanely cleaning up loose connections and
issuing nice return codes ("implementation error" perhaps in the back-ldap
case), behavior changes upon degradation, etc.