[BBLISA] Load balancers

Wed Mar 13 09:41:03 EDT 2013

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.

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:

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.

So with two LDAP servers:
Server A, IP 10.0.0.1
Server B, IP 10.0.0.2
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.

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.

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.
(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...)

-Nahum

On Tue, Mar 12, 2013 at 10:44 PM, Paul Beltrani <spamgrinder at gmail.com>wrote:

> 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 ?
>
> 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.
>
> I appreciate this may not be appropriate for your environment.  Just
> suggesting an option.
>
>
>   - Paul Beltrani
>
>
>
>
> On Tue, Mar 12, 2013 at 1:44 AM, Rob Taylor <rgt at wi.mit.edu> wrote:
>
>> Hi Matt. Thanks for the reply.
>>
>> The authentication is ldaps.
>>
>> We are only looking to use the load balancer for internal use, no
>> external use is planned. (I'm not a fan of devices straddling boundaries
>> like that anyway). I think we would use it more for service redundancy
>> than for actual load distribution most of the time.
>> Most of the services that we might use it for are not heavily used, (not
>> a ton of connections per second or anything).
>>
>> rgt
>>
>>
>> On 3/11/13 11:02 PM, Matt Finnigan wrote:
>> > Generic answers to this are only going to be of minor help for you.
>> > Knowing more about your specific use cases (particularly, what protocols
>> > you're using for authentication) will help a lot.
>> >
>> > Also, we don't know your architecture. Unless you have a flat network, a
>> > single load-balancer for authentication (typically on the back end)
>> > won't help you with web load-balancing (typically on the front end) -
>> > unless your LB has a lot of interfaces and you're OK with it straddling
>> > your DMZ and internal networks. And, like I said, without knowing what
>> > protocols you need, a web LB might not be the right fit for your auth
>> needs.
>> >
>> > On Mon, Mar 11, 2013 at 10:53 PM, Rob Taylor <rgt at wi.mit.edu
>> > <mailto:rgt at wi.mit.edu>> wrote:
>> >
>> >     Hi Guys. We have some applications here that either can't or can't
>> >     easily support connections to redundant servers for authentication,
>> >     and another application that has been known to beat the tar out of
>> >     the single authentication server it uses.
>> >     I was asked to look into it and some talk had came up about looking
>> >     into a load balancer for distributing the load, or at least making
>> >     it so that the less capable clients can failover to another server.
>> >     I'm sure we would find other uses for it besides this, like web
>> >     redirection during server outages/maintenance, and possibly
>> >     distributing logins to cluster login nodes.
>> >
>> >     Right now, our needs are pretty meager. I've started looking at a
>> >     some software ones, like balanceNG, HAproxy, to see what they can
>> do.
>> >     I've also downloaded a demo of stingray, which used to be known as
>> Zeus.
>> >     Coyote point also makes a very inexpensive starter hardware model,
>> >     $2k list.
>> >     I've got cisco gear in house, but none that seem to support SLB or I
>> >     would have looked at that as well.
>> >
>> >     Load balancers are a technology that I've never really had a chance
>> >     to play with, so I don't really know what to look for and what to
>> avoid.
>> >     Can anyone out there provide any insight on products that they have
>> >     used, what they have used them for and their experiences?
>> >
>> >     Thanks.
>> >
>> >     rgt
>> >
>> >     Whitehead Network/System Administrator
>> >
>> >     _______________________________________________
>> >     bblisa mailing list
>> >     bblisa at bblisa.org <mailto:bblisa at bblisa.org>
>> >     http://www.bblisa.org/mailman/listinfo/bblisa
>> >
>> >
>>
>> _______________________________________________
>> bblisa mailing list
>> bblisa at bblisa.org
>> http://www.bblisa.org/mailman/listinfo/bblisa
>>
>
>
> _______________________________________________
> bblisa mailing list
> bblisa at bblisa.org
> http://www.bblisa.org/mailman/listinfo/bblisa
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.bblisa.org/pipermail/bblisa/attachments/20130313/c9ba7c26/attachment-0001.htm 