<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.<br><br></div><div><br></div><div> - Paul Beltrani<br><br><br></div></div><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 class="im"><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">rgt@wi.mit.edu</a><br>
</div><div><div class="h5">> <mailto:<a href="mailto:rgt@wi.mit.edu">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">bblisa@bblisa.org</a> <mailto:<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>
<div class="HOEnZb"><div class="h5">><br>
><br>
<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>
</div></div></blockquote></div><br></div>