[BBLISA] Load balancers
John Miller
jorymil at gmail.com
Wed Mar 13 14:06:36 EDT 2013
Sorry Aaron,
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.
John
On Wed, Mar 13, 2013 at 9:51 AM, Aaron Macks <upelluri at gmail.com> wrote:
> I'd just add a strong recommendation AGAINST Cisco ACE products. Their
> actual load-balancing is fine, but everything else about them
> (replication, UI, API, logging) is terrible. To what Nahum said, in a
> master-slave failover configuration, the configs are synced, but SSL
> certs are not, so frequently the slave is not identical, and a failover
> event fails
> A
>
> On 3/13/13 9:41 AM, Nahum Shalman wrote:
> > 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
> > <mailto: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
> > <mailto: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>
> > > <mailto: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>
> > <mailto:bblisa at bblisa.org <mailto:bblisa at bblisa.org>>
> > > http://www.bblisa.org/mailman/listinfo/bblisa
> > >
> > >
> >
> > _______________________________________________
> > 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 <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
> >
>
> --
> _______________________________________________________
> Aaron Macks(aaronm at wiglaf.org) [http://www.wiglaf.org/~aaronm ]
> My sheep has seven gall bladders, that makes me the King of the Universe!
>
> _______________________________________________
> 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/93d89eb1/attachment.htm
More information about the bblisa
mailing list