Sorry Aaron,<div><br></div><div>I didn't say we're content with our ACEs--as you say, the replication and UI stink, plus bandwidth sharing/throttling between applications is counterintuitive. I wouldn't recommend them, especially as they're end-of-life. More just an illustration that authentication load balancing is entirely possible.</div>
<div><br></div><div>John</div><div><br><br><div class="gmail_quote">On Wed, Mar 13, 2013 at 9:51 AM, Aaron Macks <span dir="ltr"><<a href="mailto:upelluri@gmail.com" target="_blank">upelluri@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">I'd just add a strong recommendation AGAINST Cisco ACE products. Their<br>
actual load-balancing is fine, but everything else about them<br>
(replication, UI, API, logging) is terrible. To what Nahum said, in a<br>
master-slave failover configuration, the configs are synced, but SSL<br>
certs are not, so frequently the slave is not identical, and a failover<br>
event fails<br>
A<br>
<div><div class="h5"><br>
On 3/13/13 9:41 AM, Nahum Shalman wrote:<br>
> I second the idea of having replicated LDAP servers. If all clients can<br>
> be configured to know about multiple servers, that's the way to go.<br>
><br>
> But if not, we could expand the conversation with a brief tangent on how<br>
> to make a single IP address survive the failure of a single server:<br>
><br>
> VRRP or CARP or whatever other implementation is in fashion these days<br>
> could be used to make both LDAP servers work to ensure that one of them<br>
> is managing a particular IP address for the clients that can't be<br>
> configured to use multiple servers.<br>
><br>
> So with two LDAP servers:<br>
> Server A, IP 10.0.0.1<br>
> Server B, IP 10.0.0.2<br>
> You could also define IP address 10.0.0.3 that always is answered by<br>
> only one of those servers (the "master"), and if the master goes down,<br>
> the backup will take over the IP.<br>
><br>
> Or... You could have two load balancers at 10.0.4 and 10.0.0.5 be the<br>
> machines that use VRRP to manage 10.0.0.3 so that traffic to that<br>
> floating IP will always be balanced across both backend servers, and if<br>
> the master load balancer goes down, the IP will move over to the backup.<br>
><br>
> But this adds complexity, and more complexity means more places where I<br>
> find I can screw things up, so once again, I recommend the replicated<br>
> LDAP servers rather than mess with load balancers and VRRP.<br>
> (If you have a master and backup load balancer, Murphy's law would seem<br>
> to dictate that when the master load balancer goes down you will<br>
> discover that the backup load balancer was misconfigured...)<br>
><br>
> -Nahum<br>
><br>
><br>
><br>
> On Tue, Mar 12, 2013 at 10:44 PM, Paul Beltrani <<a href="mailto:spamgrinder@gmail.com">spamgrinder@gmail.com</a><br>
</div></div><div class="im">> <mailto:<a href="mailto:spamgrinder@gmail.com">spamgrinder@gmail.com</a>>> wrote:<br>
><br>
> Keep in mind that, unless you're careful, fronting an<br>
> authentication service with a load balancer may simply push the<br>
> problem further out, i.e your load balancer becomes the central<br>
> point of failure. Which is more work making your authentication<br>
> service highly available or setting up highly available load<br>
> balancing service ?<br>
><br>
> At my previous job I specified a a replicated OpenLDAP<br>
> infrastructure to provide authentication services for the production<br>
> Linux environment. The clients were likewise configured to take<br>
> advantage of multiple servers. I could have fronted the<br>
> authentication service with a load balancer but chose not to. The<br>
> trade-off was between a simpler implementation and quicker fault<br>
> recovery. As that environment could handle the the small timeout<br>
> some clients would experience should a server fail, I went with the<br>
> simpler implementation.<br>
><br>
> I appreciate this may not be appropriate for your environment. Just<br>
> suggesting an option.<br>
><br>
><br>
> - Paul Beltrani<br>
><br>
><br>
><br>
><br>
> On Tue, Mar 12, 2013 at 1:44 AM, 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 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<br>
> boundaries<br>
> like that anyway). I think we would use it more for service<br>
> 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<br>
> used, (not<br>
> a ton of connections per second or anything).<br>
><br>
> rgt<br>
><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<br>
> you.<br>
> > Knowing more about your specific use cases (particularly, what<br>
> 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<br>
> network, a<br>
> > single load-balancer for authentication (typically on the back<br>
> end)<br>
> > won't help you with web load-balancing (typically on the front<br>
> end) -<br>
> > unless your LB has a lot of interfaces and you're OK with it<br>
> straddling<br>
> > your DMZ and internal networks. And, like I said, without<br>
> knowing what<br>
> > protocols you need, a web LB might not be the right fit for<br>
> 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>
> <mailto:<a href="mailto:rgt@wi.mit.edu">rgt@wi.mit.edu</a>><br>
</div></div><div><div class="h5">> > <mailto:<a href="mailto:rgt@wi.mit.edu">rgt@wi.mit.edu</a> <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<br>
> or can't<br>
> > easily support connections to redundant servers for<br>
> authentication,<br>
> > and another application that has been known to beat the<br>
> tar out of<br>
> > the single authentication server it uses.<br>
> > I was asked to look into it and some talk had came up<br>
> about looking<br>
> > into a load balancer for distributing the load, or at<br>
> least making<br>
> > it so that the less capable clients can failover to<br>
> another server.<br>
> > I'm sure we would find other uses for it besides this,<br>
> 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<br>
> looking at a<br>
> > some software ones, like balanceNG, HAproxy, to see what<br>
> they can do.<br>
> > I've also downloaded a demo of stingray, which used to be<br>
> known as Zeus.<br>
> > Coyote point also makes a very inexpensive starter<br>
> hardware model,<br>
> > $2k list.<br>
> > I've got cisco gear in house, but none that seem to<br>
> 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<br>
> a chance<br>
> > to play with, so I don't really know what to look for and<br>
> what to avoid.<br>
> > Can anyone out there provide any insight on products that<br>
> 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>
> > <a href="mailto:bblisa@bblisa.org">bblisa@bblisa.org</a> <mailto:<a href="mailto:bblisa@bblisa.org">bblisa@bblisa.org</a>><br>
</div></div>> <mailto:<a href="mailto:bblisa@bblisa.org">bblisa@bblisa.org</a> <mailto:<a href="mailto:bblisa@bblisa.org">bblisa@bblisa.org</a>>><br>
<div class="im HOEnZb">> > <a href="http://www.bblisa.org/mailman/listinfo/bblisa" target="_blank">http://www.bblisa.org/mailman/listinfo/bblisa</a><br>
> ><br>
> ><br>
><br>
> _______________________________________________<br>
> bblisa mailing list<br>
> <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>
><br>
><br>
><br>
> _______________________________________________<br>
> bblisa mailing list<br>
> <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>
><br>
><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>
><br>
<br>
</div><span class="HOEnZb"><font color="#888888">--<br>
_______________________________________________________<br>
Aaron Macks(<a href="mailto:aaronm@wiglaf.org">aaronm@wiglaf.org</a>) [<a href="http://www.wiglaf.org/~aaronm" target="_blank">http://www.wiglaf.org/~aaronm</a> ]<br>
My sheep has seven gall bladders, that makes me the King of the Universe!<br>
</font></span><div class="HOEnZb"><div class="h5"><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>