<div dir="ltr">I second the idea of having replicated LDAP servers. If all clients can be configured to know about multiple servers, that's the way to go.<div><br></div><div>But if not, we could expand the conversation with a brief tangent on how to make a single IP address survive the failure of a single server:<br>
<div><br></div><div><div>VRRP or CARP or whatever other implementation is in fashion these days could be used to make both LDAP servers work to ensure that one of them is managing a particular IP address for the clients that can't be configured to use multiple servers.</div>
<div><br></div><div>So with two LDAP servers:</div><div>Server A, IP 10.0.0.1</div><div>Server B, IP 10.0.0.2</div><div>You could also define IP address 10.0.0.3 that always is answered by only one of those servers (the "master"), and if the master goes down, the backup will take over the IP.<br>
</div>
<div><br></div><div>Or... You could have two load balancers at 10.0.4 and 10.0.0.5 be the machines that use VRRP to manage 10.0.0.3 so that traffic to that floating IP will always be balanced across both backend servers, and if the master load balancer goes down, the IP will move over to the backup.</div>
<div><br></div><div>But this adds complexity, and more complexity means more places where I find I can screw things up, so once again, I recommend the replicated LDAP servers rather than mess with load balancers and VRRP.</div>
</div></div><div>(If you have a master and backup load balancer, Murphy's law would seem to dictate that when the master load balancer goes down you will discover that the backup load balancer was misconfigured...)</div>
<div><br></div><div>-Nahum</div><div><br></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Tue, Mar 12, 2013 at 10:44 PM, Paul Beltrani <span dir="ltr"><<a href="mailto:spamgrinder@gmail.com" target="_blank">spamgrinder@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div>Keep in mind that, unless you're careful, fronting an authentication service with a load balancer may simply push the problem further out, i.e your load balancer becomes the central point of failure. Which is more work making your authentication service highly available or setting up highly available load balancing service ?<br>
<br>At my previous job I specified a a replicated OpenLDAP infrastructure to provide authentication services for the production Linux environment. The clients were likewise configured to take advantage of multiple servers. I could have fronted the authentication service with a load balancer but chose not to. The trade-off was between a simpler implementation and quicker fault recovery. As that environment could handle the the small timeout some clients would experience should a server fail, I went with the simpler implementation.<br>
<br></div><div>I appreciate this may not be appropriate for your environment. Just suggesting an option.<span class="HOEnZb"><font color="#888888"><br><br></font></span></div><span class="HOEnZb"><font color="#888888"><div>
<br></div><div> - Paul Beltrani<br><br><br></div></font></span></div><div class="HOEnZb"><div class="h5"><div class="gmail_extra"><br><br><div class="gmail_quote">
On Tue, Mar 12, 2013 at 1:44 AM, Rob Taylor <span dir="ltr"><<a href="mailto:rgt@wi.mit.edu" target="_blank">rgt@wi.mit.edu</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Hi Matt. Thanks for the reply.<br>
<br>
The authentication is ldaps.<br>
<br>
We are only looking to use the load balancer for internal use, no<br>
external use is planned. (I'm not a fan of devices straddling boundaries<br>
like that anyway). I think we would use it more for service redundancy<br>
than for actual load distribution most of the time.<br>
Most of the services that we might use it for are not heavily used, (not<br>
a ton of connections per second or anything).<br>
<br>
rgt<br>
<div><br>
<br>
On 3/11/13 11:02 PM, Matt Finnigan wrote:<br>
> Generic answers to this are only going to be of minor help for you.<br>
> Knowing more about your specific use cases (particularly, what protocols<br>
> you're using for authentication) will help a lot.<br>
><br>
> Also, we don't know your architecture. Unless you have a flat network, a<br>
> single load-balancer for authentication (typically on the back end)<br>
> won't help you with web load-balancing (typically on the front end) -<br>
> unless your LB has a lot of interfaces and you're OK with it straddling<br>
> your DMZ and internal networks. And, like I said, without knowing what<br>
> protocols you need, a web LB might not be the right fit for your auth needs.<br>
><br>
> On Mon, Mar 11, 2013 at 10:53 PM, Rob Taylor <<a href="mailto:rgt@wi.mit.edu" target="_blank">rgt@wi.mit.edu</a><br>
</div><div><div>> <mailto:<a href="mailto:rgt@wi.mit.edu" target="_blank">rgt@wi.mit.edu</a>>> wrote:<br>
><br>
> Hi Guys. We have some applications here that either can't or can't<br>
> easily support connections to redundant servers for authentication,<br>
> and another application that has been known to beat the tar out of<br>
> the single authentication server it uses.<br>
> I was asked to look into it and some talk had came up about looking<br>
> into a load balancer for distributing the load, or at least making<br>
> it so that the less capable clients can failover to another server.<br>
> I'm sure we would find other uses for it besides this, like web<br>
> redirection during server outages/maintenance, and possibly<br>
> distributing logins to cluster login nodes.<br>
><br>
> Right now, our needs are pretty meager. I've started looking at a<br>
> some software ones, like balanceNG, HAproxy, to see what they can do.<br>
> I've also downloaded a demo of stingray, which used to be known as Zeus.<br>
> Coyote point also makes a very inexpensive starter hardware model,<br>
> $2k list.<br>
> I've got cisco gear in house, but none that seem to support SLB or I<br>
> would have looked at that as well.<br>
><br>
> Load balancers are a technology that I've never really had a chance<br>
> to play with, so I don't really know what to look for and what to avoid.<br>
> Can anyone out there provide any insight on products that they have<br>
> used, what they have used them for and their experiences?<br>
><br>
> Thanks.<br>
><br>
> rgt<br>
><br>
> Whitehead Network/System Administrator<br>
><br>
> _______________________________________________<br>
> bblisa mailing list<br>
</div></div>> <a href="mailto:bblisa@bblisa.org" target="_blank">bblisa@bblisa.org</a> <mailto:<a href="mailto:bblisa@bblisa.org" target="_blank">bblisa@bblisa.org</a>><br>
> <a href="http://www.bblisa.org/mailman/listinfo/bblisa" target="_blank">http://www.bblisa.org/mailman/listinfo/bblisa</a><br>
<div><div>><br>
><br>
<br>
_______________________________________________<br>
bblisa mailing list<br>
<a href="mailto:bblisa@bblisa.org" target="_blank">bblisa@bblisa.org</a><br>
<a href="http://www.bblisa.org/mailman/listinfo/bblisa" target="_blank">http://www.bblisa.org/mailman/listinfo/bblisa</a><br>
</div></div></blockquote></div><br></div>
</div></div><br>_______________________________________________<br>
bblisa mailing list<br>
<a href="mailto:bblisa@bblisa.org">bblisa@bblisa.org</a><br>
<a href="http://www.bblisa.org/mailman/listinfo/bblisa" target="_blank">http://www.bblisa.org/mailman/listinfo/bblisa</a><br></blockquote></div><br></div>